From dmarkman at mac.com Mon Mar 20 00:20:43 2006 From: dmarkman at mac.com (Dmitry Markman) Date: Tue Mar 28 18:25:38 2006 Subject: [Rxtx] Mac OS X RXTX java installer In-Reply-To: References: <07D0DE29-BA32-4CFE-B036-66BC6423D385@buechse.de> <441AE3E0.2030503@willicon.de> <12531986.1142622114996.JavaMail.dmarkman@mac.com> <441B2674.9010409@willicon.de> <13577405.1142634732776.JavaMail.dmarkman@mac.com> <441B4182.8010407@willicon.de> <92CD0D6C-5BE8-426E-A46D-99452059FF49@mac.com> <441BBB2D.8030305@willicon.de> <441C4088.5090905@willicon.de> Message-ID: <64BC1E23-FDDE-4CE6-8863-CFC881CBC224@mac.com> Hi all I put RXTX installer that will install everything (and will create / var/lock if necessary and add user to the uucp group) for mac os x from Java into the rxtx's CVS repository it could be easily modified to install files for any platform it uses Greg Guerin's AuthKit for authentication and authorization Greg released that kit under artistic license, so Trent, please take a look we, probably, can negotiate license with Greg if it's necessary Greg's AuthKit could be downloaded from http://www.amug.org/~glguerin/ sw/#authkit Michael Hall (mikehall at spacestar dot net) had a suggestion to make implementation of the jaas LoginModule based on Greg's AuthKit (his modification of the Greg's AuthKit could be found at http:// www.spacestar.net/users/mikehall/authkit.dmg) but Michael's AuthKitLoginModule does only half a job: it does authenticate but it can not run any external unix process in privileged mode (at least I wasn't able to do so) possible explanation could be found in conversation between Greg and Michael at Apple's java-dev list (look for archives) so I didn't use jaas API for rxtxinstaller I created folder MacOSX in the contrib folder comment 1. if you want to run that installer as standalone application all you need that RXTXInstaller.jar 2. if you want to use webstart you have to add Greg's libAuthKit.jnilib to the mac os x's resources in theory RXTXInstaller.jar doesn't need it, but there is a problem with loading libAuthKit.jnilib from webstart authkit uses loadLibrary method to load library and it failed (from webstart) for standalone application I extract libAuthKit.jnilib from the RXTXInstaller.jar and put it into the /Library/Java/Extensions or ~/Library/Java/Extensions folder that file will be deleted after installer quit unfortunately I didn't have time to put documentation there but it is mostly self-explanatory I took installer code from my gl4java installer that I did about 3 years ago (with small modifications) it would be very nice if Apple will release LoginModule that really will do the job (com.apple.security.auth.module package????? ) (UnixLoginModule is pretty useless) From lyon at docjava.com Mon Mar 20 06:34:39 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Tue Mar 28 18:25:38 2006 Subject: [Rxtx] Mac OS X RXTX java installer In-Reply-To: <64BC1E23-FDDE-4CE6-8863-CFC881CBC224@mac.com> References: <07D0DE29-BA32-4CFE-B036-66BC6423D385@buechse.de> <441AE3E0.2030503@willicon.de> <12531986.1142622114996.JavaMail.dmarkman@mac.com> <441B2674.9010409@willicon.de> <13577405.1142634732776.JavaMail.dmarkman@mac.com> <441B4182.8010407@willicon.de> <92CD0D6C-5BE8-426E-A46D-99452059FF49@mac.com> <441BBB2D.8030305@willicon.de> <441C4088.5090905@willicon.de> <64BC1E23-FDDE-4CE6-8863-CFC881CBC224@mac.com> Message-ID: Hi Dimitry, This sounds like great work. Just a couple of questions; After the check out of the CVS files, using: setenv CVSROOT :pserver:anonymous@cvs.milestonesolutions.com:/usr/local/cvsroot 53 8:28 setenv PASSWORD mousy 54 8:29 cvs login 55 8:29 cvs checkout rxtx-devel I cd'd over to: rxtx-devel/MACOSX_IDE And found: CVS/ CW/ ForPackageMaker/ PB/ Where is the installer? Thanks! - Doug From tjarvi at qbang.org Mon Mar 20 06:39:37 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue Mar 28 18:25:38 2006 Subject: [Rxtx] Mac OS X RXTX java installer In-Reply-To: References: <07D0DE29-BA32-4CFE-B036-66BC6423D385@buechse.de> <441AE3E0.2030503@willicon.de> <12531986.1142622114996.JavaMail.dmarkman@mac.com> <441B2674.9010409@willicon.de> <13577405.1142634732776.JavaMail.dmarkman@mac.com> <441B4182.8010407@willicon.de> <92CD0D6C-5BE8-426E-A46D-99452059FF49@mac.com> <441BBB2D.8030305@willicon.de> <441C4088.5090905@willicon.de> <64BC1E23-FDDE-4CE6-8863-CFC881CBC224@mac.com> Message-ID: On Mon, 20 Mar 2006, Dr. Douglas Lyon wrote: > Hi Dimitry, > This sounds like great work. Just a couple of questions; > After the check out of the CVS files, using: > setenv CVSROOT > :pserver:anonymous@cvs.milestonesolutions.com:/usr/local/cvsroot > 53 8:28 setenv PASSWORD mousy > 54 8:29 cvs login > 55 8:29 cvs checkout rxtx-devel Hi Doug You want "cvs checkout -r commapi-0-0-1 rxtx-devel" to get RXTX 2.1 The default branch is rxtx 2.0 which isn't very active right now. -- Trent Jarvi tjarvi@qbang.org From lyon at docjava.com Mon Mar 20 07:05:44 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Tue Mar 28 18:25:38 2006 Subject: [Rxtx] Mac OS X RXTX java installer In-Reply-To: References: <07D0DE29-BA32-4CFE-B036-66BC6423D385@buechse.de> <441AE3E0.2030503@willicon.de> <12531986.1142622114996.JavaMail.dmarkman@mac.com> <441B2674.9010409@willicon.de> <13577405.1142634732776.JavaMail.dmarkman@mac.com> <441B4182.8010407@willicon.de> <92CD0D6C-5BE8-426E-A46D-99452059FF49@mac.com> <441BBB2D.8030305@willicon.de> <441C4088.5090905@willicon.de> <64BC1E23-FDDE-4CE6-8863-CFC881CBC224@mac.com> Message-ID: Hi Trent, Thanks for the info on the CVS checkout procedure. I did that and am still not sure where the installer is. Here is what I have: cd MACOSX_IDE/ p4.docjava.com{lyon}121: ls CVS/ ForPackageMaker/ PB/ p4.docjava.com{lyon}122: find . | more . ./ForPackageMaker ./ForPackageMaker/RXTX.pkg.sit.hqx ./ForPackageMaker/Resources ./ForPackageMaker/Resources/ReadMe.rtf ./ForPackageMaker/Resources/Welcome.rtf ./ForPackageMaker/Resources/CVS ./ForPackageMaker/Resources/CVS/Entries ./ForPackageMaker/Resources/CVS/Repository ./ForPackageMaker/Resources/CVS/Tag ./ForPackageMaker/Resources/CVS/Root ./ForPackageMaker/Resources/preinstall ./ForPackageMaker/Resources/License.rtf ./ForPackageMaker/Resources/preupgrade ./ForPackageMaker/RXTX.pmsp ./ForPackageMaker/CVS ./ForPackageMaker/CVS/Entries ./ForPackageMaker/CVS/Repository ./ForPackageMaker/CVS/Entries.Log ./ForPackageMaker/CVS/Tag ./ForPackageMaker/CVS/Root ./ForPackageMaker/RXTX_Tiger.pkg.sitx.hqx ./ForPackageMaker/RXTX_Jag.pkg.sit.hqx ./ForPackageMaker/Install ./ForPackageMaker/Install/CVS ./ForPackageMaker/Install/CVS/Entries ./ForPackageMaker/Install/CVS/Repository ./ForPackageMaker/Install/CVS/Tag ./ForPackageMaker/Install/CVS/Root ./ForPackageMaker/Install/Library ./ForPackageMaker/Install/Library/CVS ./ForPackageMaker/Install/Library/CVS/Entries ./ForPackageMaker/Install/Library/CVS/Repository ./ForPackageMaker/Install/Library/CVS/Tag ./ForPackageMaker/Install/Library/CVS/Root ./ForPackageMaker/Install/Library/Java ./ForPackageMaker/Install/Library/Java/Extensions ./ForPackageMaker/Install/Library/Java/Extensions/RXTXcomm.jar ./ForPackageMaker/Install/Library/Java/Extensions/CVS ./ForPackageMaker/Install/Library/Java/Extensions/CVS/Entries ./ForPackageMaker/Install/Library/Java/Extensions/CVS/Repository ./ForPackageMaker/Install/Library/Java/Extensions/CVS/Tag ./ForPackageMaker/Install/Library/Java/Extensions/CVS/Root ./ForPackageMaker/Install/Library/Java/Extensions/librxtxSerial.jnilib ./ForPackageMaker/Install/Library/Java/CVS ./ForPackageMaker/Install/Library/Java/CVS/Entries ./ForPackageMaker/Install/Library/Java/CVS/Repository ./ForPackageMaker/Install/Library/Java/CVS/Entries.Log ./ForPackageMaker/Install/Library/Java/CVS/Tag ./ForPackageMaker/Install/Library/Java/CVS/Root ./ForPackageMaker/RXTX_Tiger.pmproj.sitx.hqx ./CVS ./CVS/Entries ./CVS/Repository ./CVS/Entries.Log ./CVS/Tag ./CVS/Root ./PB ./PB/LibSerialUniversal.xcodeproj.sitx.hqx ./PB/CVS ./PB/CVS/Entries ./PB/CVS/Repository ./PB/CVS/Entries.Log ./PB/CVS/Tag ./PB/CVS/Root ./PB/LibSerial.pbproj.sit.hqx ./PB/startpoint.c ./PB/config.h What is the procedure to run this installer? Do we need a README in: /rxtx-devel/MACOSX_IDE Here is what we have: CVS/ ForPackageMaker/ PB/ Thanks! - DL >On Mon, 20 Mar 2006, Dr. Douglas Lyon wrote: > >>Hi Dimitry, >>This sounds like great work. Just a couple of questions; >>After the check out of the CVS files, using: >>setenv CVSROOT >>:pserver:anonymous@cvs.milestonesolutions.com:/usr/local/cvsroot >> 53 8:28 setenv PASSWORD mousy >> 54 8:29 cvs login >> 55 8:29 cvs checkout rxtx-devel > >Hi Doug > >You want "cvs checkout -r commapi-0-0-1 rxtx-devel" to get RXTX 2.1 >The default branch is rxtx 2.0 which isn't very active right now. > >-- >Trent Jarvi >tjarvi@qbang.org From tjarvi at qbang.org Mon Mar 20 07:25:30 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue Mar 28 18:25:38 2006 Subject: [Rxtx] Mac OS X RXTX java installer In-Reply-To: References: <07D0DE29-BA32-4CFE-B036-66BC6423D385@buechse.de> <441AE3E0.2030503@willicon.de> <12531986.1142622114996.JavaMail.dmarkman@mac.com> <441B2674.9010409@willicon.de> <13577405.1142634732776.JavaMail.dmarkman@mac.com> <441B4182.8010407@willicon.de> <92CD0D6C-5BE8-426E-A46D-99452059FF49@mac.com> <441BBB2D.8030305@willicon.de> <441C4088.5090905@willicon.de> <64BC1E23-FDDE-4CE6-8863-CFC881CBC224@mac.com> Message-ID: On Mon, 20 Mar 2006, Dr. Douglas Lyon wrote: > Hi Trent, > Thanks for the info on the CVS checkout procedure. > I did that and am still not sure where the installer is. Hi Doug It does look like it was not cvs committed. There is no rxtx-devel/contrib/MacOSX directory in there at the moment. It was mentioned that it was put under contrib. -- Trent Jarvi tjarvi@qbang.org From dmarkman at mac.com Mon Mar 20 07:29:56 2006 From: dmarkman at mac.com (Dmitry Markman) Date: Tue Mar 28 18:25:38 2006 Subject: [Rxtx] Mac OS X RXTX java installer In-Reply-To: References: <07D0DE29-BA32-4CFE-B036-66BC6423D385@buechse.de> <441AE3E0.2030503@willicon.de> <12531986.1142622114996.JavaMail.dmarkman@mac.com> <441B2674.9010409@willicon.de> <13577405.1142634732776.JavaMail.dmarkman@mac.com> <441B4182.8010407@willicon.de> <92CD0D6C-5BE8-426E-A46D-99452059FF49@mac.com> <441BBB2D.8030305@willicon.de> <441C4088.5090905@willicon.de> <64BC1E23-FDDE-4CE6-8863-CFC881CBC224@mac.com> Message-ID: <6054EB4E-F7E0-4A9C-BDDA-D582D6D8826F@mac.com> you can find it in the rxtx-devel/contrib folder On Mar 20, 2006, at 9:05 AM, Dr. Douglas Lyon wrote: > Hi Trent, > Thanks for the info on the CVS checkout procedure. > I did that and am still not sure where the installer is. > Here is what I have: > cd MACOSX_IDE/ > p4.docjava.com{lyon}121: ls > CVS/ ForPackageMaker/ PB/ > p4.docjava.com{lyon}122: find . | more > . > ./ForPackageMaker > ./ForPackageMaker/RXTX.pkg.sit.hqx > ./ForPackageMaker/Resources > ./ForPackageMaker/Resources/ReadMe.rtf > ./ForPackageMaker/Resources/Welcome.rtf > ./ForPackageMaker/Resources/CVS > ./ForPackageMaker/Resources/CVS/Entries > ./ForPackageMaker/Resources/CVS/Repository > ./ForPackageMaker/Resources/CVS/Tag > ./ForPackageMaker/Resources/CVS/Root > ./ForPackageMaker/Resources/preinstall > ./ForPackageMaker/Resources/License.rtf > ./ForPackageMaker/Resources/preupgrade > ./ForPackageMaker/RXTX.pmsp > ./ForPackageMaker/CVS > ./ForPackageMaker/CVS/Entries > ./ForPackageMaker/CVS/Repository > ./ForPackageMaker/CVS/Entries.Log > ./ForPackageMaker/CVS/Tag > ./ForPackageMaker/CVS/Root > ./ForPackageMaker/RXTX_Tiger.pkg.sitx.hqx > ./ForPackageMaker/RXTX_Jag.pkg.sit.hqx > ./ForPackageMaker/Install > ./ForPackageMaker/Install/CVS > ./ForPackageMaker/Install/CVS/Entries > ./ForPackageMaker/Install/CVS/Repository > ./ForPackageMaker/Install/CVS/Tag > ./ForPackageMaker/Install/CVS/Root > ./ForPackageMaker/Install/Library > ./ForPackageMaker/Install/Library/CVS > ./ForPackageMaker/Install/Library/CVS/Entries > ./ForPackageMaker/Install/Library/CVS/Repository > ./ForPackageMaker/Install/Library/CVS/Tag > ./ForPackageMaker/Install/Library/CVS/Root > ./ForPackageMaker/Install/Library/Java > ./ForPackageMaker/Install/Library/Java/Extensions > ./ForPackageMaker/Install/Library/Java/Extensions/RXTXcomm.jar > ./ForPackageMaker/Install/Library/Java/Extensions/CVS > ./ForPackageMaker/Install/Library/Java/Extensions/CVS/Entries > ./ForPackageMaker/Install/Library/Java/Extensions/CVS/Repository > ./ForPackageMaker/Install/Library/Java/Extensions/CVS/Tag > ./ForPackageMaker/Install/Library/Java/Extensions/CVS/Root > ./ForPackageMaker/Install/Library/Java/Extensions/librxtxSerial.jnilib > ./ForPackageMaker/Install/Library/Java/CVS > ./ForPackageMaker/Install/Library/Java/CVS/Entries > ./ForPackageMaker/Install/Library/Java/CVS/Repository > ./ForPackageMaker/Install/Library/Java/CVS/Entries.Log > ./ForPackageMaker/Install/Library/Java/CVS/Tag > ./ForPackageMaker/Install/Library/Java/CVS/Root > ./ForPackageMaker/RXTX_Tiger.pmproj.sitx.hqx > ./CVS > ./CVS/Entries > ./CVS/Repository > ./CVS/Entries.Log > ./CVS/Tag > ./CVS/Root > ./PB > ./PB/LibSerialUniversal.xcodeproj.sitx.hqx > ./PB/CVS > ./PB/CVS/Entries > ./PB/CVS/Repository > ./PB/CVS/Entries.Log > ./PB/CVS/Tag > ./PB/CVS/Root > ./PB/LibSerial.pbproj.sit.hqx > ./PB/startpoint.c > ./PB/config.h > > What is the procedure to run this installer? > Do we need a README in: > /rxtx-devel/MACOSX_IDE > Here is what we have: > CVS/ ForPackageMaker/ PB/ > > > Thanks! > - DL > >> On Mon, 20 Mar 2006, Dr. Douglas Lyon wrote: >> >>> Hi Dimitry, >>> This sounds like great work. Just a couple of questions; >>> After the check out of the CVS files, using: >>> setenv CVSROOT :pserver:anonymous@cvs.milestonesolutions.com:/usr/ >>> local/cvsroot >>> 53 8:28 setenv PASSWORD mousy >>> 54 8:29 cvs login >>> 55 8:29 cvs checkout rxtx-devel >> >> Hi Doug >> >> You want "cvs checkout -r commapi-0-0-1 rxtx-devel" to get RXTX 2.1 >> The default branch is rxtx 2.0 which isn't very active right now. >> >> -- >> Trent Jarvi >> tjarvi@qbang.org > > _______________________________________________ > Rxtx mailing list > Rxtx@qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx Dmitry Markman From mikehall at spacestar.net Mon Mar 20 05:25:25 2006 From: mikehall at spacestar.net (Michael Hall) Date: Tue Mar 28 18:25:38 2006 Subject: [Rxtx] Re: Mac OS X RXTX java installer In-Reply-To: <64BC1E23-FDDE-4CE6-8863-CFC881CBC224@mac.com> References: <07D0DE29-BA32-4CFE-B036-66BC6423D385@buechse.de> <441AE3E0.2030503@willicon.de> <12531986.1142622114996.JavaMail.dmarkman@mac.com> <441B2674.9010409@willicon.de> <13577405.1142634732776.JavaMail.dmarkman@mac.com> <441B4182.8010407@willicon.de> <92CD0D6C-5BE8-426E-A46D-99452059FF49@mac.com> <441BBB2D.8030305@willicon.de> <441C4088.5090905@willicon.de> <64BC1E23-FDDE-4CE6-8863-CFC881CBC224@mac.com> Message-ID: <247EB61F-5CD1-4132-89A2-FC105B6CF9A5@spacestar.net> On Mar 20, 2006, at 1:20 AM, Dmitry Markman wrote: > > Michael Hall (mikehall at spacestar dot net) had a suggestion to > make implementation of the jaas LoginModule > based on Greg's AuthKit > (his modification of the Greg's AuthKit could be found at http:// > www.spacestar.net/users/mikehall/authkit.dmg) > but Michael's AuthKitLoginModule does only half a job: > it does authenticate > but it can not run any external unix process in privileged mode (at > least I wasn't able to do so) If you got it working directly with Greg's the point is moot. But to clarify it anyhow. The login module does not allow you to do anything anything privileged on return as was explained by Greg. You need to work with a separate privileged process using the execPrivileged method of his API. I assume you did something similar although I haven't looked at how you are using it yet. I allowed instead for a action to be performed at the same time you login/authenticate,this... System.setProperty("authkit.action","/usr/bin/id"); just before this... lc.login(); To clarify, safely ignored as you are already complete. Mike Hall mikehall at spacestar dot net http://www.spacestar.net/users/mikehall http://sourceforge.net/projects/macnative -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2427 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20060320/f6e18202/smime-0002.bin From dmarkman at mac.com Mon Mar 20 07:36:47 2006 From: dmarkman at mac.com (Dmitry Markman) Date: Tue Mar 28 18:25:38 2006 Subject: [Rxtx] Re: Mac OS X RXTX java installer In-Reply-To: <247EB61F-5CD1-4132-89A2-FC105B6CF9A5@spacestar.net> References: <07D0DE29-BA32-4CFE-B036-66BC6423D385@buechse.de> <441AE3E0.2030503@willicon.de> <12531986.1142622114996.JavaMail.dmarkman@mac.com> <441B2674.9010409@willicon.de> <13577405.1142634732776.JavaMail.dmarkman@mac.com> <441B4182.8010407@willicon.de> <92CD0D6C-5BE8-426E-A46D-99452059FF49@mac.com> <441BBB2D.8030305@willicon.de> <441C4088.5090905@willicon.de> <64BC1E23-FDDE-4CE6-8863-CFC881CBC224@mac.com> <247EB61F-5CD1-4132-89A2-FC105B6CF9A5@spacestar.net> Message-ID: Hi, Michael all I have to do is to run some shell script I tried to use your action mechanism and it worked great so I just System.setProperty ("authkit.action","" ) and after that I even don't need to run anything like subject.doAs.... but after few thoughts I choose to use plain Greg's approach, because in that case I don't have to deal with various java's configurations files and therefore to use 2-3 -D parameters in the java command line especially it's useful for java web start (it's so fragile :-( ) thanks for the great job On Mar 20, 2006, at 7:25 AM, Michael Hall wrote: > > On Mar 20, 2006, at 1:20 AM, Dmitry Markman wrote: >> >> Michael Hall (mikehall at spacestar dot net) had a suggestion to >> make implementation of the jaas LoginModule >> based on Greg's AuthKit >> (his modification of the Greg's AuthKit could be found at http:// >> www.spacestar.net/users/mikehall/authkit.dmg) >> but Michael's AuthKitLoginModule does only half a job: >> it does authenticate >> but it can not run any external unix process in privileged mode >> (at least I wasn't able to do so) > > If you got it working directly with Greg's the point is moot. > > But to clarify it anyhow. > The login module does not allow you to do anything anything > privileged on return as was explained by Greg. You need to work > with a separate privileged process using the execPrivileged method > of his API. I assume you did something similar although I haven't > looked at how you are using it yet. > I allowed instead for a action to be performed at the same time you > login/authenticate,this... > System.setProperty("authkit.action","/usr/bin/id"); > just before this... > lc.login(); > To clarify, safely ignored as you are already complete. > > Mike Hall mikehall at spacestar dot net > http://www.spacestar.net/users/mikehall > http://sourceforge.net/projects/macnative > > > Dmitry Markman From dmarkman at mac.com Mon Mar 20 07:44:45 2006 From: dmarkman at mac.com (Dmitry Markman) Date: Tue Mar 28 18:25:38 2006 Subject: [Rxtx] Mac OS X RXTX java installer In-Reply-To: References: <07D0DE29-BA32-4CFE-B036-66BC6423D385@buechse.de> <441AE3E0.2030503@willicon.de> <12531986.1142622114996.JavaMail.dmarkman@mac.com> <441B2674.9010409@willicon.de> <13577405.1142634732776.JavaMail.dmarkman@mac.com> <441B4182.8010407@willicon.de> <92CD0D6C-5BE8-426E-A46D-99452059FF49@mac.com> <441BBB2D.8030305@willicon.de> <441C4088.5090905@willicon.de> <64BC1E23-FDDE-4CE6-8863-CFC881CBC224@mac.com> Message-ID: it's in the commapi-0-0-1 branch I tested it right now: cvs co -r commapi-0-0-1 rxtx-devel and I got everything On Mar 20, 2006, at 9:25 AM, Trent Jarvi wrote: > On Mon, 20 Mar 2006, Dr. Douglas Lyon wrote: > >> Hi Trent, >> Thanks for the info on the CVS checkout procedure. >> I did that and am still not sure where the installer is. > > Hi Doug > > It does look like it was not cvs committed. There is no rxtx-devel/ > contrib/MacOSX directory in there at the moment. It was mentioned > that it was put under contrib. > > -- > Trent Jarvi > tjarvi@qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx@qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx Dmitry Markman From tjarvi at qbang.org Mon Mar 20 07:52:57 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue Mar 28 18:25:38 2006 Subject: [Rxtx] Mac OS X RXTX java installer In-Reply-To: References: <07D0DE29-BA32-4CFE-B036-66BC6423D385@buechse.de> <441AE3E0.2030503@willicon.de> <12531986.1142622114996.JavaMail.dmarkman@mac.com> <441B2674.9010409@willicon.de> <13577405.1142634732776.JavaMail.dmarkman@mac.com> <441B4182.8010407@willicon.de> <92CD0D6C-5BE8-426E-A46D-99452059FF49@mac.com> <441BBB2D.8030305@willicon.de> <441C4088.5090905@willicon.de> <64BC1E23-FDDE-4CE6-8863-CFC881CBC224@mac.com> Message-ID: On Mon, 20 Mar 2006, Dmitry Markman wrote: > it's in the commapi-0-0-1 branch > > I tested it right now: > cvs co -r commapi-0-0-1 rxtx-devel > > and I got everything > A fresh checkout worked. Here is a copy of the tree (just the installer bits) ftp://ftp.qbang.org/pub/rxtx/MacOSX-installer.zip -- Trent Jarvi tjarvi@qbang.org From lyon at docjava.com Mon Mar 20 08:08:26 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Tue Mar 28 18:25:38 2006 Subject: [Rxtx] Mac OS X RXTX java installer In-Reply-To: References: <07D0DE29-BA32-4CFE-B036-66BC6423D385@buechse.de> <441AE3E0.2030503@willicon.de> <12531986.1142622114996.JavaMail.dmarkman@mac.com> <441B2674.9010409@willicon.de> <13577405.1142634732776.JavaMail.dmarkman@mac.com> <441B4182.8010407@willicon.de> <92CD0D6C-5BE8-426E-A46D-99452059FF49@mac.com> <441BBB2D.8030305@willicon.de> <441C4088.5090905@willicon.de> <64BC1E23-FDDE-4CE6-8863-CFC881CBC224@mac.com> Message-ID: Hi All, Is the Auth package able to work properly on non Mac OS's? It was not clear from the doc or download. Thanks! - Doug From dmarkman at mac.com Mon Mar 20 08:15:22 2006 From: dmarkman at mac.com (Dmitry Markman) Date: Tue Mar 28 18:25:38 2006 Subject: [Rxtx] Mac OS X RXTX java installer In-Reply-To: References: <07D0DE29-BA32-4CFE-B036-66BC6423D385@buechse.de> <441AE3E0.2030503@willicon.de> <12531986.1142622114996.JavaMail.dmarkman@mac.com> <441B2674.9010409@willicon.de> <13577405.1142634732776.JavaMail.dmarkman@mac.com> <441B4182.8010407@willicon.de> <92CD0D6C-5BE8-426E-A46D-99452059FF49@mac.com> <441BBB2D.8030305@willicon.de> <441C4088.5090905@willicon.de> <64BC1E23-FDDE-4CE6-8863-CFC881CBC224@mac.com> Message-ID: <217312D8-CCCA-4859-ABA6-32DF1CC817B9@mac.com> thanks Trent, for putting it on ftp server On Mar 20, 2006, at 9:52 AM, Trent Jarvi wrote: > A fresh checkout worked. Here is a copy of the tree (just the > installer bits) > > ftp://ftp.qbang.org/pub/rxtx/MacOSX-installer.zip > Dmitry Markman From dmarkman at mac.com Mon Mar 20 09:14:03 2006 From: dmarkman at mac.com (Dmitry Markman) Date: Tue Mar 28 18:25:38 2006 Subject: [Rxtx] Mac OS X RXTX java installer In-Reply-To: References: <07D0DE29-BA32-4CFE-B036-66BC6423D385@buechse.de> <441AE3E0.2030503@willicon.de> <12531986.1142622114996.JavaMail.dmarkman@mac.com> <441B2674.9010409@willicon.de> <13577405.1142634732776.JavaMail.dmarkman@mac.com> <441B4182.8010407@willicon.de> <92CD0D6C-5BE8-426E-A46D-99452059FF49@mac.com> <441BBB2D.8030305@willicon.de> <441C4088.5090905@willicon.de> <64BC1E23-FDDE-4CE6-8863-CFC881CBC224@mac.com> Message-ID: <4DEBA6F0-DA45-4E84-823E-1F1AC48BDCCC@mac.com> no it will work only on mac os x however it's harmless to run it on other platform if you want to use it for other platform you have to do the following (I'll do it for linux) 1. modify RXTXInstaller class method public static RXTXInstaller getInstance() public static RXTXInstaller getInstance() { String osName = System.getProperty("os.name").toLowerCase(); if(osName.startsWith("mac")){ return new gnu.io.installer.macosx.MACOSXRXTXInstaller(); } else if(osName.startsWith("windows")){ return new gnu.io.installer.windows.WindowsRXTXInstaller(); }else if(osName.startsWith("linux")){ return new gnu.io.installer.linux.LinuxRXTXInstaller(); } return null; } 2. create folder gnu/io/installer/linux/ 3. create class Linux386RXTXInstaller package gnu.io.installer.linux; import java.io.File; public class Linux386RXTXInstaller extends gnu.io.installer.RXTXInstaller{ public Linux386RXTXInstaller(){ createJarFolder(); createLibFolder(); addJarResource("RXTXcomm.jar","/gnu/io/installer/resources/ linux/jar/RXTXcomm.dat"); addLibResource("librxtxSerial.so","/gnu/io/installer/ resources/linux/lib/librxtxSerial.so"); } protected void createJarFolder(){ String javaHome = System.getProperty("java.home"); char separator = File.separatorChar; jarFolder = new File(javaHome+separator+"lib"+separator+"ext"); } protected void createLibFolder(){ String javaHome = System.getProperty("java.home"); char separator = File.separatorChar; libFolder = new File(javaHome+separator+"bin"); } public void runPreProcess() {} //put here some action you need public void runPostProcess() {} //put here some action you need } 4. create folder /gnu/io/installer/resources/linux/jar and put there linux's version of RXTXcomm.dat (which is renamed RXTXcomm.jar) 5. create folder /gnu/io/installer/resources/linux/lib and put there linux's version of librxtxSerial. so 6. make sure that RXTXInstaller.jar has the following items: /gnu/io/installer/resources/linux/jar/RXTXcomm.jar /gnu/io/installer/resources/linux/lib/librxtxSerial.so 7. modify file installer.pref: jar file RXTXInstaller.jar must have the following item /gnu/io/installer/installer.pref that's basically it for windows you have to do the similar things: just replace linux to windows and librxtxSerial.so to rxtxSerial.dll and create appropriate gnu.io.installer.windows.WindowsRXTXInstaller class package gnu.io.installer.windows; import java.io.File; public class WindowsRXTXInstaller extends gnu.io.installer.RXTXInstaller{ public WindowsRXTXInstaller(){ createJarFolder(); createLibFolder(); addJarResource("RXTXcomm.jar","/gnu/io/installer/resources/ windows/jar/RXTXcomm.dat"); addLibResource("librxtxSerial.so","/gnu/io/installer/ resources/windows/lib/rxtxSerial.dll"); } protected void createJarFolder(){ String javaHome = System.getProperty("java.home"); char separator = File.separatorChar; jarFolder = new File(javaHome+separator+"lib"+separator+"ext"); } protected void createLibFolder(){ String javaHome = System.getProperty("java.home"); char separator = File.separatorChar; libFolder = new File(javaHome+separator+"bin"); } public void runPreProcess() {} //put here some action you need public void runPostProcess() {} //put here some action you need } installer.pref will look like On Mar 20, 2006, at 10:08 AM, Dr. Douglas Lyon wrote: > Hi All, > Is the Auth package able to work properly on > non Mac OS's? > It was not clear from the doc or download. > > Thanks! > - Doug > _______________________________________________ > Rxtx mailing list > Rxtx@qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx Dmitry Markman From joachim at buechse.de Mon Mar 20 10:49:06 2006 From: joachim at buechse.de (Joachim Buechse) Date: Tue Mar 28 18:25:38 2006 Subject: [Rxtx] BUG: Lock file stays even if port opening fails Message-ID: This was only tested on MacOSX but looking at the code, it should be true for all systems that use lock_uucp. I am opening a port which can not be opened (dialup port of a telephone paired via bluetooth but currently not reachable). The lock file is created and stays arround, even though the port open failed. After looking a bit through the code (of 2.17), I really wonder if it wouldn't be a good idea to make the "locking" an explicit operation called from the java code. This would certainly simplify the generation of meaningfull exceptions (and java based debugging). Maybe even the handling of "preopened" ports should be in the Java part of the lib (again for java based debugging puposes). That beeing said, I have no idea if this would be possible for the 2.07 implementation. Regards, Joachim From tjarvi at qbang.org Mon Mar 20 11:24:22 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue Mar 28 18:25:38 2006 Subject: [Rxtx] BUG: Lock file stays even if port opening fails In-Reply-To: References: Message-ID: On Mon, 20 Mar 2006, Joachim Buechse wrote: > This was only tested on MacOSX but looking at the code, it should be true > for all systems that use lock_uucp. > > I am opening a port which can not be opened (dialup port of a telephone > paired via bluetooth but currently not reachable). The lock file is > created and stays arround, even though the port open failed. > > > After looking a bit through the code (of 2.17), I really wonder if it > wouldn't be a good idea to make the "locking" an explicit operation > called from the java code. This would certainly simplify the generation > of meaningfull exceptions (and java based debugging). > Maybe even the handling of "preopened" ports should be in the Java part > of the lib (again for java based debugging puposes). That beeing said, I > have no idea if this would be possible for the 2.07 implementation. > > Regards, Hi Joachim It should be possible in the 2.0-7 implementation too. The calls to RXTXPort.java would not change. We would just do more there Moving more of that logic into Java would be better as many people don't like to look at C code. There is a liblockdev on most Linux distros that can do most of the C code and would be easier to use. The problem is embeded devices will not have that library. The preopened port code has not been really tested. That was a last minute request in a product cycle. I expect it will be tested this year though. As I recall, some devices really do not like CD raising on open. The preopened ports then allow people to mess around in java without power cycling the devices or losing data. -- Trent Jarvi tjarvi@qbang.org From joachim at buechse.de Mon Mar 20 12:01:08 2006 From: joachim at buechse.de (Joachim Buechse) Date: Tue Mar 28 18:25:38 2006 Subject: [Rxtx] BUG: Lock file stays even if port opening fails In-Reply-To: References: Message-ID: Hi Trent, What is your general feeling about moving code to Java? The last days I have been reading quite a bit of the code and there are several things, that might not work as expected. I'll give you two examples from is_device_locked: if LOCKDIR == /var/spool/locks the directory /var/spool/lock will not be checked. LOCKDIR is not checked for lockfiles with unexpected pefixes While these things have probably never been discovered in production, they are still possibly incorrect implementations. If it was Java code, I would write some unit tests producing the errors that could later be corrected. PS: One could imagine to actually implement the whole lockfile handling in Java using some native routines to get the values required (pid, st_dev, st_rdev, ...). On 20.03.2006, at 19:24, Trent Jarvi wrote: > On Mon, 20 Mar 2006, Joachim Buechse wrote: > >> This was only tested on MacOSX but looking at the code, it should >> be true for all systems that use lock_uucp. >> >> I am opening a port which can not be opened (dialup port of a >> telephone paired via bluetooth but currently not reachable). The >> lock file is created and stays arround, even though the port open >> failed. >> >> >> After looking a bit through the code (of 2.17), I really wonder if >> it wouldn't be a good idea to make the "locking" an explicit >> operation called from the java code. This would certainly simplify >> the generation of meaningfull exceptions (and java based debugging). >> Maybe even the handling of "preopened" ports should be in the Java >> part of the lib (again for java based debugging puposes). That >> beeing said, I have no idea if this would be possible for the 2.07 >> implementation. >> >> Regards, > > Hi Joachim > > It should be possible in the 2.0-7 implementation too. The calls > to RXTXPort.java would not change. We would just do more there > Moving more of that logic into Java would be better as many people > don't like to look at C code. There is a liblockdev on most Linux > distros that can do most of the C code and would be easier to use. > The problem is embeded devices will not have that library. > > The preopened port code has not been really tested. That was a > last minute request in a product cycle. I expect it will be tested > this year though. As I recall, some devices really do not like CD > raising on open. The preopened ports then allow people to mess > around in java without power cycling the devices or losing data. > > -- > Trent Jarvi > tjarvi@qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx@qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Mon Mar 20 12:21:02 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue Mar 28 18:25:38 2006 Subject: [Rxtx] BUG: Lock file stays even if port opening fails In-Reply-To: References: Message-ID: On Mon, 20 Mar 2006, Joachim Buechse wrote: > Hi Trent, > > What is your general feeling about moving code to Java? The last days I > have been reading quite a bit of the code and there are several things, > that might not work as expected. > > I'll give you two examples from is_device_locked: > > if LOCKDIR == /var/spool/locks the directory /var/spool/lock will not be > checked. > LOCKDIR is not checked for lockfiles with unexpected pefixes > > While these things have probably never been discovered in production, > they are still possibly incorrect implementations. If it was Java code, I > would write some unit tests producing the errors that could later be > corrected. > > PS: One could imagine to actually implement the whole lockfile handling > in Java using some native routines to get the values required (pid, > st_dev, st_rdev, ...). Hi Joachim I like the idea of moving more of the code into java but there are some things to consider. If you break this into multiple JNI calls, the performance will drop considerably during enumeration of ports. We are looking for 256 ports per dev type vs (16? in Sun's 2.0 and fewer types). Its hard to make assumptions. I've seen virtual ports start at /dev/foo100 for instance. It works out to over 7500 ports on Linux if you enable them all. We already trim that back by default. See Linux-all-ports in RXTXCommDriver.java. There are also native libraries that rxtx can link to. If you move too much into Java, linking to 'standard' libraries with distros will break. "configure --enable-liblock=yes" will not be doable. This is probably a favorable way with RedHat, Debian, Suse and others. Thats the right thing to do if there will be rpms, dpkg, .. For those reasons, I think it still make sense to keep it to a minimal ~3 calls to JNI code that we can use for speed and versatility. lock() isLocked(), unlock() perhaps. When I say speed, its more about avoiding crossing the JNI layer multiple times than java vs C performance. With versatility I think liblock is the right way for most but not all (embeded) linux distros. -- Trent Jarvi tjarvi@qbang.org From joachim at buechse.de Mon Mar 20 12:42:04 2006 From: joachim at buechse.de (Joachim Buechse) Date: Tue Mar 28 18:25:38 2006 Subject: [Rxtx] BUG: Lock file stays even if port opening fails In-Reply-To: References: Message-ID: <82C19FE7-DDCB-45B6-B2C9-7606B66F0124@buechse.de> Ok, what about providing a default implementation in Java? The RXTXCommDriver would call a (native) function useNativeLocking and if it returns true, call the native functions for lock() isLocked (), unlock(), else is would use the Java based default implementation. This could possibly be overriden by a property (again for debugging). Joachim On 20.03.2006, at 20:21, Trent Jarvi wrote: > On Mon, 20 Mar 2006, Joachim Buechse wrote: > >> Hi Trent, >> >> What is your general feeling about moving code to Java? The last >> days I have been reading quite a bit of the code and there are >> several things, that might not work as expected. >> >> I'll give you two examples from is_device_locked: >> >> if LOCKDIR == /var/spool/locks the directory /var/spool/lock will >> not be checked. >> LOCKDIR is not checked for lockfiles with unexpected pefixes >> >> While these things have probably never been discovered in >> production, they are still possibly incorrect implementations. If >> it was Java code, I would write some unit tests producing the >> errors that could later be corrected. >> >> PS: One could imagine to actually implement the whole lockfile >> handling in Java using some native routines to get the values >> required (pid, st_dev, st_rdev, ...). > > Hi Joachim > > I like the idea of moving more of the code into java but there are > some things to consider. > > If you break this into multiple JNI calls, the performance will > drop considerably during enumeration of ports. We are looking for > 256 ports per dev type vs (16? in Sun's 2.0 and fewer types). Its > hard to make assumptions. I've seen virtual ports start at /dev/ > foo100 for instance. > > It works out to over 7500 ports on Linux if you enable them all. > We already trim that back by default. See Linux-all-ports in > RXTXCommDriver.java. > > There are also native libraries that rxtx can link to. If you move > too much into Java, linking to 'standard' libraries with distros > will break. "configure --enable-liblock=yes" will not be doable. > This is probably a favorable way with RedHat, Debian, Suse and > others. Thats the right thing to do if there will be rpms, dpkg, .. > > For those reasons, I think it still make sense to keep it to a > minimal ~3 calls to JNI code that we can use for speed and > versatility. lock() isLocked(), unlock() perhaps. When I say > speed, its more about avoiding crossing the JNI layer multiple > times than java vs C performance. With versatility I think liblock > is the right way for most but not all (embeded) linux distros. > > -- > Trent Jarvi > tjarvi@qbang.org > > _______________________________________________ > Rxtx mailing list > Rxtx@qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Mon Mar 20 12:44:47 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue Mar 28 18:25:38 2006 Subject: [Rxtx] BUG: Lock file stays even if port opening fails In-Reply-To: <82C19FE7-DDCB-45B6-B2C9-7606B66F0124@buechse.de> References: <82C19FE7-DDCB-45B6-B2C9-7606B66F0124@buechse.de> Message-ID: On Mon, 20 Mar 2006, Joachim Buechse wrote: > Ok, what about providing a default implementation in Java? > > The RXTXCommDriver would call a (native) function useNativeLocking and if > it returns true, call the native functions for lock() isLocked(), > unlock(), else is would use the Java based default implementation. This > could possibly be overriden by a property (again for debugging). > Hi Joachim That would be OK with me. -- Trent Jarvi tjarvi@qbang.org From dmarkman at mac.com Mon Mar 20 22:27:45 2006 From: dmarkman at mac.com (Dmitry Markman) Date: Tue Mar 28 18:25:38 2006 Subject: [Rxtx] binaries request Message-ID: <42702213-C222-4937-A585-7CFB17E47608@mac.com> Hi can somebody send me latest linux and windows binaries, please? or where I can find them (I didn't find them in the latest tareball) I gave up with my cygwin: something wrong I have no idea what java doesn't understand /cygwin/c syntax after I changed makefile it did java part but after that gcc 3.4.4 started to complain I set buffer length to 999 lines but I didn't get beginning of the story something wrong with my 1.4.2_09/include/jni.h gcc doesn't like it anyway I gave up thanks in advance Dmitry Markman -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060320/f8cbc57c/attachment-0002.html From tjarvi at qbang.org Mon Mar 20 22:36:48 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue Mar 28 18:25:38 2006 Subject: [Rxtx] binaries request In-Reply-To: <42702213-C222-4937-A585-7CFB17E47608@mac.com> References: <42702213-C222-4937-A585-7CFB17E47608@mac.com> Message-ID: On Tue, 21 Mar 2006, Dmitry Markman wrote: > Hi > can somebody send me latest linux and windows binaries, please? > > or where I can find them (I didn't find them in the latest tareball) > > I gave up with my cygwin: something wrong I have no idea what > java doesn't understand /cygwin/c syntax > after I changed makefile it did java part > but after that gcc 3.4.4 started to complain > I set buffer length to 999 lines but I didn't get beginning of the story > something wrong with my 1.4.2_09/include/jni.h gcc doesn't like it > anyway I gave up > > thanks in advance > Hi Dmitry The bins are here: ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7-bins-r2.zip Here are the files in the zip you want. Jar: rxtx-2.1-7-bins-r2/RXTXcomm.jar Windows: rxtx-2.1-7-bins-r2/Windows/i368-mingw32/rxtxSerial.dll Linux (x86) rxtx-2.1-7-bins-r2/Linux/i686-unknown-linux-gnu/librxtxSerial.so There are others in there including Parallel port support but those are the main ones for testing. -- Trent Jarvi tjarvi@qbang.org From dmarkman at mac.com Mon Mar 20 23:05:59 2006 From: dmarkman at mac.com (Dmitry Markman) Date: Tue Mar 28 18:25:38 2006 Subject: [Rxtx] binaries request In-Reply-To: References: <42702213-C222-4937-A585-7CFB17E47608@mac.com> Message-ID: thank you very much but windows's readme says: rxtxSerial.dll had to be recomopiled to link in missing native methods. should I ignore it? or what? thanks again also I understand that I should use mingw not cygwin I'll try to install mingw On Mar 21, 2006, at 12:36 AM, Trent Jarvi wrote: > On Tue, 21 Mar 2006, Dmitry Markman wrote: > >> Hi >> can somebody send me latest linux and windows binaries, please? >> >> or where I can find them (I didn't find them in the latest tareball) >> >> I gave up with my cygwin: something wrong I have no idea what >> java doesn't understand /cygwin/c syntax >> after I changed makefile it did java part >> but after that gcc 3.4.4 started to complain >> I set buffer length to 999 lines but I didn't get beginning of the >> story >> something wrong with my 1.4.2_09/include/jni.h gcc doesn't like it >> anyway I gave up >> >> thanks in advance >> > > Hi Dmitry > > The bins are here: > > ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7-bins-r2.zip > > Here are the files in the zip you want. > > Jar: > > rxtx-2.1-7-bins-r2/RXTXcomm.jar > > Windows: > > rxtx-2.1-7-bins-r2/Windows/i368-mingw32/rxtxSerial.dll > > Linux (x86) > > rxtx-2.1-7-bins-r2/Linux/i686-unknown-linux-gnu/librxtxSerial.so > > There are others in there including Parallel port support but those > are the main ones for testing. > > -- > Trent Jarvi > tjarvi@qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx@qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx Dmitry Markman From tjarvi at qbang.org Mon Mar 20 23:20:33 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue Mar 28 18:25:38 2006 Subject: [Rxtx] binaries request In-Reply-To: References: <42702213-C222-4937-A585-7CFB17E47608@mac.com> Message-ID: On Tue, 21 Mar 2006, Dmitry Markman wrote: > thank you very much > > but windows's readme says: > rxtxSerial.dll had to be recomopiled to link in missing native methods. > > should I ignore it? or what? > Hi Dmitry That dll should be OK. r2 is the recompile linked to the missing native method. The readme explains why it was recompiled; fuser.o was not linked into the dll in the first release. -- Trent Jarvi tjarvi@qbang.org From ariantristan at yahoo.com Mon Mar 20 23:55:24 2006 From: ariantristan at yahoo.com (Lambok Sianturi) Date: Tue Mar 28 18:25:38 2006 Subject: [Rxtx] jvm issue Message-ID: <20060321065524.94779.qmail@web50701.mail.yahoo.com> Hi All, This is my first time to join RxTx mailing list. I thank you all for allowing others to sign in in requests help. I use the latest RxTx lib in Fedora 3 with java version 1.4.2_09 b05. And I got this error: # # An unexpected error has been detected by HotSpot Virtual Machine: # # SIGSEGV (0xb) at pc=0x00bf27f3, pid=2633, tid=3086112448 # # Java VM: Java HotSpot(TM) Client VM (1.4.2_09-b05 mixed mode) # Problematic frame: # C [ld-linux.so.2+0xa7f3] # # An error report file with more information is saved as hs_err_pid2633.log # # If you would like to submit a bug report, please visit: # http://java.sun.com/webapps/bugreport/crash.jsp # ./run.sh: line 3: 2633 Aborted /usr/local/java/bin/java -Djava.library.path=/usr/local/java/jre/lib/ -Djsmsengine.debug=true -classpath jsmsengine.jar:smsgateway.jar:classes12.jar:RXTXcomm.jar:. com.api.sms.SMSServer What is the jvm depedency for the latest library? Can I use 1.4.2_09 b05? Thanks in advance. Arian --------------------------------- Yahoo! Mail Use Photomail to share photos without annoying attachments. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060320/83d58dd7/attachment-0002.html From f.frumento at ngi.it Tue Mar 21 00:21:47 2006 From: f.frumento at ngi.it (Fabio Frumento) Date: Tue Mar 28 18:25:38 2006 Subject: [Rxtx] Javadoc on the go Message-ID: <441FA98B.9050701@ngi.it> Hi Trent, sorry for the big delay but my job is running wild, i was out for some time but now i'm back and ready to continue the javadoc for Rxtx. Did you used the last javadoc patch i sent you ? let me know if i have to send it to you again or not. regards Fabio From lyon at docjava.com Tue Mar 21 00:51:18 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Tue Mar 28 18:25:38 2006 Subject: [Rxtx] lock files Message-ID: Hi All, You know, if the use of lock files were under Java control (rather than a build-time decision), it might enable a more unified binary distro. It might also facilitate quick prototyping of non-lock file approaches to resolving serial port contention issues (i.e., mac-like approaches vs. linux approaches, etc.). I realize that this is a radical overhaul of the lock file policy issue. Also, it may harm performance. On the other hand, our benchmarks on JNI overhead for modern processors indicate performance impact should be minimal. Perhaps it is more of an issue with the toybox systems. Suppose there were a class with a reasonable default...someone might write: SerialPortLockPolicy.setPolicy(SerialPortLockPolicy.UNIX_LOCK_FILE); SerialPortLockPolicy.setPolicy(SerialPortLockPolicy.NO_LOCK_CHECKING); SerialPortLockPolicy.setPolicy(SerialPortLockPolicy.MAC_STYLE); Thus, we could have a run-time reconfiguration of the serial port lock policy. A special NO_LOCK version of the binary would no longer be required. Any thoughts on this? Thanks! - Doug From joachim at buechse.de Tue Mar 21 03:09:09 2006 From: joachim at buechse.de (Joachim Buechse) Date: Tue Mar 28 18:25:38 2006 Subject: [Rxtx] lock files In-Reply-To: References: Message-ID: <8E12916A-1B9A-4FF2-B684-E2D1C794221B@buechse.de> This is pretty much what I thought about when I suggested, that the default behaviour could be overwritten with a property. I am very much in favor of this approach. In particular this allows much easier debugging for PC based java developers. I think big parts of the Java (and maybe some parts of the C code) could use a bit of a structural workover (unit tests, javadoc, synchronization, etc). Maybe there should be a CVS branch for this experimental version. I'd be happy to contribute a first workover for some of the Java code. Designing for testability and implementing a good bunch of unit tests has been a strategy that worked quite well in the Java projects I lead. And it ultimately allows more liberal change permission. Regards, Joachim On 21.03.2006, at 08:51, Dr. Douglas Lyon wrote: > Hi All, > You know, if the use of lock files were > under Java control (rather than a build-time decision), > it might enable a more unified binary distro. It might also > facilitate quick prototyping of non-lock file approaches > to resolving serial port contention issues (i.e., mac-like > approaches vs. linux approaches, etc.). > > I realize that this is a radical overhaul of the lock file policy > issue. Also, it may harm performance. On the other hand, > our benchmarks on JNI overhead for modern processors indicate > performance impact should be minimal. Perhaps it is more of > an issue with the toybox systems. > > Suppose there were a class with a reasonable default...someone > might write: > SerialPortLockPolicy.setPolicy(SerialPortLockPolicy.UNIX_LOCK_FILE); > SerialPortLockPolicy.setPolicy(SerialPortLockPolicy.NO_LOCK_CHECKING); > SerialPortLockPolicy.setPolicy(SerialPortLockPolicy.MAC_STYLE); > > Thus, we could have a run-time reconfiguration of the serial port lock > policy. A special NO_LOCK version of the binary would no longer > be required. > > Any thoughts on this? > > Thanks! > - Doug > _______________________________________________ > Rxtx mailing list > Rxtx@qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From joachim at buechse.de Tue Mar 21 06:23:08 2006 From: joachim at buechse.de (Joachim Buechse) Date: Tue Mar 28 18:25:38 2006 Subject: [Rxtx] PATCH: use of ioctl(fd, TIOCEXCL) instead of lockfiles Message-ID: <923AE774-EEA2-4911-92D8-32BB27802C8B@buechse.de> Here is the patch for the ioctl(fd, TIOCEXCL). I have verified this only for OSX 10.4.5, hence it is only defined for APPLE. However, it should work at least for Solaris as well. If a process has requested TIOEXCL further open calls by other user processes will fail. The patch also disables uucp style locking for APPLE. Obviously this is discussable. I think it is the way to go, as it eliminates creating the lock directory which doesnt exist on the standard installation and it eliminates messing with the system group definitions (adding users to group uucp). Regarding the possibility of root processes opening a device which is locked - I consider this a feature not a potential problem. It is highly unlikely, that somebody is crazy enough to run a JavaVM as root (unless he has no other means of getting a restricted IP port opened, ie doesnt understand ipfw). Anyway, even if the process runs as root, it fails when calling ioctl(fd, TIOCEXCL). It could however still open the port to listen for RING events. I.e. a fax server which needs to see incoming calls but otherwise doesnt want to block the port. So the only case where the proposed mechanism fails is, if an incorrectly implemented process running as root conflicts with a user process. I think this can be accepted. Regards, Joachim PS: If this patch is generally accepted, the installer and Mac doku should obviously be changed as well. Index: SerialImp.c =================================================================== RCS file: /usr/local/cvsroot/rxtx-devel/src/SerialImp.c,v retrieving revision 1.46.2.187 diff -u -r1.46.2.187 SerialImp.c --- SerialImp.c 29 Jan 2006 22:19:04 -0000 1.46.2.187 +++ SerialImp.c 21 Mar 2006 12:59:16 -0000 @@ -656,6 +656,25 @@ fd=OPEN (filename, O_RDWR | O_NOCTTY | O_NONBLOCK ); } while (fd < 0 && errno==EINTR); +#ifdef OPEN_EXCL + // Note that open() follows POSIX semantics: multiple open() calls to + // the same file will succeed unless the TIOCEXCL ioctl is issued. + // This will prevent additional opens except by root-owned processes. + // See tty(4) ("man 4 tty") and ioctl(2) ("man 2 ioctl") for details. + + if (fd >= 0 && (ioctl(fd, TIOCEXCL) == -1)) + { + sprintf( message, "open: exclusive access denied for % s\n", + filename ); + report( message ); + report_error( message ); + + close(fd); + goto fail; + } +#endif /* OPEN_EXCL */ + + if( configure_port( fd ) ) goto fail; (*env)->ReleaseStringUTFChars( env, jstr, filename ); sprintf( message, "open: fd returned is %i\n", fd ); Index: SerialImp.h =================================================================== RCS file: /usr/local/cvsroot/rxtx-devel/src/SerialImp.h,v retrieving revision 1.11.2.49 diff -u -r1.11.2.49 SerialImp.h --- SerialImp.h 5 Jul 2005 17:47:21 -0000 1.11.2.49 +++ SerialImp.h 21 Mar 2006 12:59:17 -0000 @@ -135,7 +135,8 @@ /*# define LOCKDIR "/var/spool/uucp"*/ # define LOCKDIR "/var/lock" # define LOCKFILEPREFIX "LK." -# define UUCP +/*# define UUCP*/ +# define OPEN_EXCL #endif /* __APPLE__ */ #if defined(__NetBSD__) # define DEVICEDIR "/dev/" From tjarvi at qbang.org Tue Mar 21 10:26:08 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue Mar 28 18:25:38 2006 Subject: [Rxtx] Javadoc on the go In-Reply-To: <441FA98B.9050701@ngi.it> References: <441FA98B.9050701@ngi.it> Message-ID: On Tue, 21 Mar 2006, Fabio Frumento wrote: > Hi Trent, > > sorry for the big delay but my job is running wild, i was out for some > time but now i'm back and ready to continue the javadoc for Rxtx. > > Did you used the last javadoc patch i sent you ? let me know if i have to > send it to you again or not. > > regards > > Fabio Hi Fabio The patch is in the rxtx mail-list archives. It will be going in soon. I did not see a time critical portion. I'll probably be going through the list since the last batch of patches this weekend and putting them into CVS. -- Trent Jarvi tjarvi@qbang.org From tjarvi at qbang.org Tue Mar 21 10:57:18 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue Mar 28 18:25:38 2006 Subject: [Rxtx] jvm issue In-Reply-To: <20060321065524.94779.qmail@web50701.mail.yahoo.com> References: <20060321065524.94779.qmail@web50701.mail.yahoo.com> Message-ID: On Mon, 20 Mar 2006, Lambok Sianturi wrote: > Hi All, > This is my first time to join RxTx mailing list. I thank you all for allowing others to sign in in requests help. > I use the latest RxTx lib in Fedora 3 with java version 1.4.2_09 b05. And I got this error: > > # > # An unexpected error has been detected by HotSpot Virtual Machine: > # > # SIGSEGV (0xb) at pc=0x00bf27f3, pid=2633, tid=3086112448 > # > # Java VM: Java HotSpot(TM) Client VM (1.4.2_09-b05 mixed mode) > # Problematic frame: > # C [ld-linux.so.2+0xa7f3] A native library loading error? What happens if you recompile rxtx on your system and install that? This sounds like an ABI problem? rxtx 2.1-7 was compiled with a gcc 2.96 toolchain as I recall. The hope is newer system will be backwards compatible. -- Trent Jarvi tjarvi@qbang.org From tjarvi at qbang.org Tue Mar 21 11:05:29 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue Mar 28 18:25:38 2006 Subject: [Rxtx] PATCH: use of ioctl(fd, TIOCEXCL) instead of lockfiles In-Reply-To: <923AE774-EEA2-4911-92D8-32BB27802C8B@buechse.de> References: <923AE774-EEA2-4911-92D8-32BB27802C8B@buechse.de> Message-ID: On Tue, 21 Mar 2006, Joachim Buechse wrote: > Here is the patch for the ioctl(fd, TIOCEXCL). I have verified this only > for OSX 10.4.5, hence it is only defined for APPLE. However, it should > work at least for Solaris as well. > > If a process has requested TIOEXCL further open calls by other user > processes will fail. > > The patch also disables uucp style locking for APPLE. Obviously this is > discussable. I think it is the way to go, as it eliminates creating the > lock directory which doesnt exist on the standard installation and it > eliminates messing with the system group definitions (adding users to > group uucp). > > Regarding the possibility of root processes opening a device which is > locked - I consider this a feature not a potential problem. It is highly > unlikely, that somebody is crazy enough to run a JavaVM as root (unless > he has no other means of getting a restricted IP port opened, ie doesnt > understand ipfw). Anyway, even if the process runs as root, it fails when > calling ioctl(fd, TIOCEXCL). It could however still open the port to > listen for RING events. I.e. a fax server which needs to see incoming > calls but otherwise doesnt want to block the port. So the only case where > the proposed mechanism fails is, if an incorrectly implemented process > running as root conflicts with a user process. I think this can be > accepted. > > Regards, > Joachim > > PS: If this patch is generally accepted, the installer and Mac doku > should obviously be changed as well. > > > Index: SerialImp.c > =================================================================== > RCS file: /usr/local/cvsroot/rxtx-devel/src/SerialImp.c,v > retrieving revision 1.46.2.187 > diff -u -r1.46.2.187 SerialImp.c > --- SerialImp.c 29 Jan 2006 22:19:04 -0000 1.46.2.187 > +++ SerialImp.c 21 Mar 2006 12:59:16 -0000 > @@ -656,6 +656,25 @@ > fd=OPEN (filename, O_RDWR | O_NOCTTY | O_NONBLOCK ); > } while (fd < 0 && errno==EINTR); > > +#ifdef OPEN_EXCL > + // Note that open() follows POSIX semantics: multiple open() > calls to > + // the same file will succeed unless the TIOCEXCL ioctl is > issued. > + // This will prevent additional opens except by root-owned > processes. > + // See tty(4) ("man 4 tty") and ioctl(2) ("man 2 ioctl") for > details. > + > + if (fd >= 0 && (ioctl(fd, TIOCEXCL) == -1)) > + { > + sprintf( message, "open: exclusive access denied for % > s\n", > + filename ); > + report( message ); > + report_error( message ); > + > + close(fd); > + goto fail; > + } > +#endif /* OPEN_EXCL */ > + > + > if( configure_port( fd ) ) goto fail; > (*env)->ReleaseStringUTFChars( env, jstr, filename ); > sprintf( message, "open: fd returned is %i\n", fd ); > Index: SerialImp.h > =================================================================== > RCS file: /usr/local/cvsroot/rxtx-devel/src/SerialImp.h,v > retrieving revision 1.11.2.49 > diff -u -r1.11.2.49 SerialImp.h > --- SerialImp.h 5 Jul 2005 17:47:21 -0000 1.11.2.49 > +++ SerialImp.h 21 Mar 2006 12:59:17 -0000 > @@ -135,7 +135,8 @@ > /*# define LOCKDIR "/var/spool/uucp"*/ > # define LOCKDIR "/var/lock" > # define LOCKFILEPREFIX "LK." > -# define UUCP > +/*# define UUCP*/ > +# define OPEN_EXCL > #endif /* __APPLE__ */ > #if defined(__NetBSD__) > # define DEVICEDIR "/dev/" > This looks like a good start. What do you think Dmitry? Perhaps all systems with TIOCEXCL defined should use that though. Even if they use lockfiles. It wont hurt anything. That would catch people hacking their own serial apps without checking lockfiles. Its a good idea to avoid C++ style comments in the C portions. Some older systems don't deal with them well. If it's just for Mac OS X, it isn't a big deal. I think it was the Irix compiler that was problematic? -- Trent Jarvi tjarvi@qbang.org From tjarvi at qbang.org Tue Mar 21 11:22:05 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue Mar 28 18:25:38 2006 Subject: [Rxtx] lock files In-Reply-To: <8E12916A-1B9A-4FF2-B684-E2D1C794221B@buechse.de> References: <8E12916A-1B9A-4FF2-B684-E2D1C794221B@buechse.de> Message-ID: We can try it. Maybe the JNI is much improved. The nice thing about linking into liblock is distros then worry about lockfiles on their systems. This way, we have to deal with any changes that may show up. On Tue, 21 Mar 2006, Joachim Buechse wrote: > This is pretty much what I thought about when I suggested, that the > default behaviour could be overwritten with a property. I am very much in > favor of this approach. In particular this allows much easier debugging > for PC based java developers. > > I think big parts of the Java (and maybe some parts of the C code) could > use a bit of a structural workover (unit tests, javadoc, synchronization, > etc). Maybe there should be a CVS branch for this experimental version. > I'd be happy to contribute a first workover for some of the Java code. > Designing for testability and implementing a good bunch of unit tests has > been a strategy that worked quite well in the Java projects I lead. And > it ultimately allows more liberal change permission. > > Regards, > Joachim > > > On 21.03.2006, at 08:51, Dr. Douglas Lyon wrote: > >> Hi All, >> You know, if the use of lock files were >> under Java control (rather than a build-time decision), >> it might enable a more unified binary distro. It might also >> facilitate quick prototyping of non-lock file approaches >> to resolving serial port contention issues (i.e., mac-like >> approaches vs. linux approaches, etc.). >> >> I realize that this is a radical overhaul of the lock file policy >> issue. Also, it may harm performance. On the other hand, >> our benchmarks on JNI overhead for modern processors indicate >> performance impact should be minimal. Perhaps it is more of >> an issue with the toybox systems. >> >> Suppose there were a class with a reasonable default...someone >> might write: >> SerialPortLockPolicy.setPolicy(SerialPortLockPolicy.UNIX_LOCK_FILE); >> SerialPortLockPolicy.setPolicy(SerialPortLockPolicy.NO_LOCK_CHECKING); >> SerialPortLockPolicy.setPolicy(SerialPortLockPolicy.MAC_STYLE); >> >> Thus, we could have a run-time reconfiguration of the serial port lock >> policy. A special NO_LOCK version of the binary would no longer >> be required. >> >> Any thoughts on this? >> >> Thanks! >> - Doug >> _______________________________________________ >> Rxtx mailing list >> Rxtx@qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx@qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From dmarkman at mac.com Tue Mar 21 16:05:17 2006 From: dmarkman at mac.com (Dmitry Markman) Date: Tue Mar 28 18:25:38 2006 Subject: [Rxtx] PATCH: use of ioctl(fd, TIOCEXCL) instead of lockfiles In-Reply-To: References: <923AE774-EEA2-4911-92D8-32BB27802C8B@buechse.de> Message-ID: <512AC70C-BB86-48F2-A83C-023F35C23BAB@mac.com> I think it's cool, but I'd like to have that property implementation when user can choose between locking mechanism about comments: it's easy to change comments to the C style or we can use extensions of the file to cpp so c++ compiler will be used On Mar 21, 2006, at 1:05 PM, Trent Jarvi wrote: > This looks like a good start. What do you think Dmitry? Perhaps > all systems with TIOCEXCL defined should use that though. Even if > they use lockfiles. It wont hurt anything. That would catch > people hacking their own serial apps without checking lockfiles. > > Its a good idea to avoid C++ style comments in the C portions. > Some older systems don't deal with them well. If it's just for Mac > OS X, it isn't a big deal. I think it was the Irix compiler that > was problematic? Dmitry Markman From dmarkman at mac.com Tue Mar 21 16:13:00 2006 From: dmarkman at mac.com (Dmitry Markman) Date: Tue Mar 28 18:25:38 2006 Subject: [Rxtx] PATCH: use of ioctl(fd, TIOCEXCL) instead of lockfiles In-Reply-To: References: <923AE774-EEA2-4911-92D8-32BB27802C8B@buechse.de> Message-ID: I'd like to add that creating locking folder isn't a big deal we never had a problem related to the lock folders, because we always used installer on mac os x from other hand I'm not very much familiar with iotcl locking approach and I'm not sure it's more efficient Joachim wrote "I think it is the way to go, as it eliminates creating the lock directory which doesnt exist on the standard installation and it eliminates messing with the system group definitions (adding users to group uucp)." but I really didn't have any problem with that 1. doesn't exist on the standard installation there are many-many things that don't exist in the standard installation so I don't think that argument is strong enough 2. messing with the system group definitions I don't think we're messing with the group definition mac os x provides very clear way to set up group's members and together with Greg Guerin AuthKit there is no problem to set those definitions so I don't think that argument is strong either but from other hand using iotcl is more promising and is more elegant On Mar 21, 2006, at 1:05 PM, Trent Jarvi wrote: > > This looks like a good start. What do you think Dmitry? Perhaps > all systems with TIOCEXCL defined should use that though. Even if > they use lockfiles. It wont hurt anything. That would catch > people hacking their own serial apps without checking lockfiles. Dmitry Markman From joachim at buechse.de Wed Mar 22 04:46:45 2006 From: joachim at buechse.de (Joachim Buechse) Date: Tue Mar 28 18:25:38 2006 Subject: [Rxtx] PATCH: use of ioctl(fd, TIOCEXCL) instead of lockfiles In-Reply-To: References: <923AE774-EEA2-4911-92D8-32BB27802C8B@buechse.de> Message-ID: Sorry, I was not very clear with my arguments, so I will try again;-) Please, don't take this as an attack against work that has been done. I think the contributions that have been made in the past were made in a good spirit. But I really believe, that the current solution for OSX has many shortcomings and should be changed as soon as possible. lock files --- The /var/lock folder does not exist on the standard OSX installation, however the standard installation includes several applications that use serial ports (i.e. the FAX capability). This indicates, that the lock folder approach will not work well with system components. Applications for OSX will generally try to live in harmony with system components (except for HP print drivers of course). I think RXTX should follow this approach as well. uucp group --- Accessing serial ports is not an admin privileged operation on OSX. Any user (world) has read/write privileges on /dev/tty*. So the system default is to not enforce any group membership to access these ports. The group uucp however is a system group on all unix systems I know. It exists for certain system processes. A non admin user should in general not be a member of this group. Quite arguably no user should ever be a member of this group. Installer --- My general opinion is, that - no Installer should touch user or group data without warning - no Application Installer should touch groups which are not specific to the very application installed - no Installer should ever add regular users to a system group The current installer injects the installing user in the group uucp without warning about this change and without giving the option to "opt out" of this change. This is a potential security risk (but not currently a real one, as OSX contains no folders belonging to group uucp). The current installer does not work for multi user systems. It puts the installing user in the uucp group. However the installing user is not necessarily the user that will use the application. Putting all users that may use a serial port application in the system group uucp seems like a very invasive approach to me. Besides that, newly created users will not automatically be in the group and hence, serial applications will "break" for new users without obvious reasons. Avoiding the lock files will allow self contained applications (i.e. drag&drop installation). In my eyes this is largely preferable over an installer that requests admin privileges. Adding up all these points indicates very strongly, that the lock-file implementation is not the way to go on OSX. Regards, Joachim On 22.03.2006, at 00:13, Dmitry Markman wrote: > I'd like to add that > > creating locking folder isn't a big deal > we never had a problem related to the lock folders, because we > always used installer on mac os x > from other hand I'm not very much familiar with iotcl locking > approach and I'm not sure it's more efficient > > Joachim wrote "I think it is the way to go, as it eliminates > creating the lock directory which doesnt exist on the standard > installation and it eliminates messing with the system group > definitions (adding users to group uucp)." but I really didn't have > any problem with that > > 1. doesn't exist on the standard installation > there are many-many things that don't exist in the standard > installation so I don't think that argument is strong enough > 2. messing with the system group definitions > I don't think we're messing with the group definition > mac os x provides very clear way to set up group's members and > together with Greg Guerin AuthKit there is no problem to set those > definitions > so I don't think that argument is strong either > but from other hand using iotcl is more promising and is more elegant > > > > On Mar 21, 2006, at 1:05 PM, Trent Jarvi wrote: > >> >> This looks like a good start. What do you think Dmitry? Perhaps >> all systems with TIOCEXCL defined should use that though. Even if >> they use lockfiles. It wont hurt anything. That would catch >> people hacking their own serial apps without checking lockfiles. > > Dmitry Markman > > _______________________________________________ > Rxtx mailing list > Rxtx@qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From dmarkman at mac.com Wed Mar 22 05:27:13 2006 From: dmarkman at mac.com (Dmitry Markman) Date: Tue Mar 28 18:25:38 2006 Subject: [Rxtx] PATCH: use of ioctl(fd, TIOCEXCL) instead of lockfiles In-Reply-To: References: <923AE774-EEA2-4911-92D8-32BB27802C8B@buechse.de> Message-ID: <83440CF3-DCD8-41C1-B941-F227232C27E3@mac.com> thanks for the very good explanation I didn't think that you were attacking any thing, so don't worry I just had feeling, that there were more aesthetic reasons for going to ioctl then real necessity now you explained everything quite well (BTW, asfar as I remember installer asks admin password so it wasn't quiet, but it really doesn't matter now) thanks On Mar 22, 2006, at 6:46 AM, Joachim Buechse wrote: > Sorry, I was not very clear with my arguments, so I will try again;-) > > Please, don't take this as an attack against work that has been > done. I think the contributions that have been made in the past > were made in a good spirit. But I really believe, that the current > solution for OSX has many shortcomings and should be changed as > soon as possible. > > lock files > --- > The /var/lock folder does not exist on the standard OSX > installation, however the standard installation includes several > applications that use serial ports (i.e. the FAX capability). This > indicates, that the lock folder approach will not work well with > system components. Applications for OSX will generally try to live > in harmony with system components (except for HP print drivers of > course). I think RXTX should follow this approach as well. > > uucp group > --- > Accessing serial ports is not an admin privileged operation on OSX. > Any user (world) has read/write privileges on /dev/tty*. So the > system default is to not enforce any group membership to access > these ports. The group uucp however is a system group on all unix > systems I know. It exists for certain system processes. A non admin > user should in general not be a member of this group. Quite > arguably no user should ever be a member of this group. > > Installer > --- > My general opinion is, that > - no Installer should touch user or group data without warning > - no Application Installer should touch groups which are not > specific to the very application installed > - no Installer should ever add regular users to a system group > > The current installer injects the installing user in the group uucp > without warning about this change and without giving the option to > "opt out" of this change. This is a potential security risk (but > not currently a real one, as OSX contains no folders belonging to > group uucp). > > The current installer does not work for multi user systems. It puts > the installing user in the uucp group. However the installing user > is not necessarily the user that will use the application. Putting > all users that may use a serial port application in the system > group uucp seems like a very invasive approach to me. Besides that, > newly created users will not automatically be in the group and > hence, serial applications will "break" for new users without > obvious reasons. > > > Avoiding the lock files will allow self contained applications > (i.e. drag&drop installation). In my eyes this is largely > preferable over an installer that requests admin privileges. Adding > up all these points indicates very strongly, that the lock-file > implementation is not the way to go on OSX. > > Regards, > Joachim > > > On 22.03.2006, at 00:13, Dmitry Markman wrote: > >> I'd like to add that >> >> creating locking folder isn't a big deal >> we never had a problem related to the lock folders, because we >> always used installer on mac os x >> from other hand I'm not very much familiar with iotcl locking >> approach and I'm not sure it's more efficient >> >> Joachim wrote "I think it is the way to go, as it eliminates >> creating the lock directory which doesnt exist on the standard >> installation and it eliminates messing with the system group >> definitions (adding users to group uucp)." but I really didn't >> have any problem with that >> >> 1. doesn't exist on the standard installation >> there are many-many things that don't exist in the standard >> installation so I don't think that argument is strong enough >> 2. messing with the system group definitions >> I don't think we're messing with the group definition >> mac os x provides very clear way to set up group's members and >> together with Greg Guerin AuthKit there is no problem to set those >> definitions >> so I don't think that argument is strong either >> but from other hand using iotcl is more promising and is more elegant >> >> >> >> On Mar 21, 2006, at 1:05 PM, Trent Jarvi wrote: >> >>> >>> This looks like a good start. What do you think Dmitry? Perhaps >>> all systems with TIOCEXCL defined should use that though. Even >>> if they use lockfiles. It wont hurt anything. That would catch >>> people hacking their own serial apps without checking lockfiles. >> >> Dmitry Markman >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx@qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx@qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx Dmitry Markman From lyon at docjava.com Wed Mar 22 06:12:18 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Tue Mar 28 18:25:38 2006 Subject: [Rxtx] sole of a new design pattern Message-ID: Hi All, I have been thinking about how we design the serial port software. I think we need a new design pattern. For lack of a better term, I shall call it: The Parametric Singleton Design Pattern By Douglas A. Lyon ABSTRACT The goal of the singleton design pattern is to make sure that there is one, and only one, instance of a given class. The goal of the parametric singleton design pattern is to make sure that there is one, and only one, instance of a given class with the given parametric values. We parametric singleton design pattern combines the singleton design pattern with a parameter that enables unique creation of instances of a class. These instances are cached. When a user asks for an instance with these parameters, the cache is checked. If the instance is in the cache, the instance is returned, otherwise it is created, added to the cache and then returned. We apply our parametric singleton design pattern to the retrieval of RMI registries bound to a given port. The goal of our system is to make sure that no two RMI registries are listening to the same socket and to make use of the RMI registries after they have been created. RMI registries are used in distributed computation. Introduction The singleton design pattern is meant to ensure that on a single instance of a class exists. It is also meant to provide a global point of access to it. The intent of the parametric singleton design pattern is to ensure that a class has only one instance for a given set of parameter values. It also provides a global point of access to it. Motivation A system cannot tolerate multiple instances of some classes with identical parameters. For example, you cannot have two instances making use of the same serial port, at the same time. You cannot have two instances that are trying to listen to the same socket connection. You cannot have two instances writing to the same file structure at the same time. As the operating system is often thought of as the arbiter of consumed resources (i.e., tape drives, serial ports, etc.) we frequently leave it to an operating system implementation to resolve these contention issues. Even for similar resources (like serial ports) there are few standards for handling contention. For example, serial ports on Linux are locked using a "/var/lock" file. POSIX, on the other hand, uses ioctl mechanisms to prevent contention. A better solution is to make a class that is responsible for keeping track of the instances created from the class. The class is declared final, so that it cannot be subclassed. The class also has a private constructor, so that other classes cannot instance it. The new design pattern is called the parametric singleton design pattern and it provides a way to access and create instances with given parameters. Applicability Use the Parametric Singleton Design Pattern when: 1. There must be exactly one instance of a class with the given parameters. 2. The instances must be accessible to clients from a well-known access point. Structure Insert UML diagram here. Participants The Parametric Singleton Clients that need instances 1. The Parametric Singleton defines an instance upon request from a client, if, and only if, the instance does not already exist. 2. The Parametric Singleton returns the instance to the client. 3. The Parametric Singleton is responsible for creating unique instances from given parameters. Collaborations Clients obtain a reference to a Parametric Singleton instance only through the parametric singleton design pattern. If the instance is left in an improper state (e.g., the serial port was left open) it is NOT the role of the Parametric Singleton Design Pattern to close the IO port. Nor is it the role of the Parametric Singleton Design Pattern to open the port. That role is delegate to some other part of the system. Further, it is not the role of the Parametric Singleton Design Pattern to check out resources. That is, multiple threads can have multiple references to the same resource at the same time. MUTEX locking is delegated to some other part of the system. Consequences The Parametric Singleton Design Pattern has several benefits: 1. Controlled access to parametrically defined instances. Since the Parametric Singleton class encapsulates its instances, there is control over how and when clients access it. 2. Reduced name space. The Parametric Singleton pattern avoids global variables that store instances created from the same parameter. Implementation Here are implementation issues to consider when using the Parametric Singleton pattern: 1. Unique mapping of parameters. The Parametric Singleton pattern requires that there be a mean to isomorphically map the parameter space into the instance space and back again. 2. Ensure unique instances. The Parametric Singleton pattern makes unique instances from parameters, and it does so only once. 3. Cache instances for fast retrieval. The Parametric Singleton pattern must be able to look up instances, given some set of parameters, and do so from some data structure. That is, there must be enough space to hold references to all the instances the program will need. Also, a mechanism is needed to look up and retrieve the instances quickly enough to satisfy the clients. Sample Code public final class ParametricSingletonRmiRegistry { private static Hashtable registry = new Hashtable(100); // use singleton pattern and??????????????????????????????????????????????? // prevent instantiation of RmiRegistryUtils.?????????????????????????????? private ParametricSingletonRmiRegistry() { } // the only instance of the Registry held by the RmiRegistryUtils?????????? public static void listNames(Integer port) { if (!isInCacheAndRunning(port)) return; Registry r = (Registry) registry.get(port); System.out.println("registry on port: " + port); System.out.println("registry: " + r); System.out.println("names: "); try { print(r.list()); } catch (RemoteException e) { In.message(e); } System.out.println("------------------------"); } /**???????????????????????????????????????????????????????????????????????? * Checks whether a Registry has been started on this host????????????????? * in the specified port.?????????????????????????????????????????????????? * If not, it tries to start one.?????????????????????????????????????????? * when it fails to start a Registry, it exits the program????????????????? * with exit code 1.??????????????????????????????????????????????????????? */ public static void restart(int port) { if (isInCacheAndRunning(port)) return; try { startRegistry(port); } catch (RemoteException e) { In.message(e); } } /**???????????????????????????????????????????????????????????????????????? * @param port????????????????????????????????????????????????????????????? * @return true if registry is in cache and running???????????????????????? */ private static boolean isInCacheAndRunning(Integer port) { if (!isRegistryRunning(port.intValue())) return false; if (!isRegistryInCache(port.intValue())) return false; return true; } /**???????????????????????????????????????????????????????????????????????? * @param port????????????????????????????????????????????????????????????? * @return true if we are able to locate a local registry on port.??????????????????????????????????????????????????????????????????????????? */ private static boolean isRegistryRunning(int port) { try { Registry r = LocateRegistry.getRegistry(port); if (r != null) return true; } catch (RemoteException e) { return false; } return false; } /**???????????????????????????????????????????????????????????????????????? * @param port????????????????????????????????????????????????????????????? * @return return true if registry is in cache????????????????????????????? */ private static boolean isRegistryInCache(int port) { if (registry.get(new Integer(port)) == null) return false; return true; } /**???????????????????????????????????????????????????????????????????????? * Restart the registry, if needed.???????????????????????????????????????? * Return the only instance of the registry for consistent global?????????? * using by making use of the Singleton Design Pattern????????????????????? *????????????????????????????????????????????????????????????????????????? * @return the internally held registry instance.?????????????????????????? */ public static Registry getRegistry(Integer port) { restart(port); return (Registry) registry.get(port); } private static void startRegistry(Integer port) throws RemoteException { Registry r; try { r = LocateRegistry.createRegistry(port.intValue()); registry.put(port, r); //r = new sun.rmi.registry.RegistryImpl???????????????????????????? /// (port.intValue());?????????????????????????????????????? // registry.put(port, r);?????????????????????????????????????????? } catch (Exception e) { //e.printStackTrace();????????????????????????????????????????????? r = LocateRegistry.getRegistry(port.intValue()); registry.put(port, r); } } public static void main(String args[]) throws RemoteException { //restart(port);??????????????????????????????????????????????????????? restart(5001); restart(5002); restart(5002); Registry r = LocateRegistry.getRegistry(5002); System.out.println("registry="+r); } } I would very much like to get your feedback on this new design pattern idea. Thank you for your time. Regards, - Doug From david.garnier at trusted-logic.com Wed Mar 22 07:36:10 2006 From: david.garnier at trusted-logic.com (David Garnier) Date: Tue Mar 28 18:25:38 2006 Subject: [Rxtx] sole of a new design pattern In-Reply-To: References: Message-ID: <442160DA.80107@trusted-logic.com> Hello, > The Parametric Singleton Design Pattern The Singleton is the most abused design pattern ever. Good use-cases for this pattern are extremely rare and mostly confined to problems related to hardware resources, like serial ports. > Applicability > > Use the Parametric Singleton Design Pattern when: > 1. There must be exactly one instance of a class with the given > parameters. OK. As I said above, this case this actually very unusual. The Singleton pattern is mostly used when : > 2. The instances must be accessible to clients from a well-known > access point. Using the singleton pattern in this case is just convenient for the programmer. Problems arises pretty quickly, especially if you attempt to unit-test your classes. 1) If your singleton is stateful, or hold on to stateful objects, it means that two different unit tests are not actually independent. Instead of starting with a brand new environment, the result of a test may be affected by the result of a previous test. This problem also arise when with your class relies on a database. In both cases, the solution is to reset your "unique" resource (Singleton or database) at the beginning of the test, which is a pain. Also, while most projects connect to a single database, projects that allow the use of Singletons usually contain several of thems, and new ones may cropped up unnoticed. You quickly end up with test cases that only pass in a certain order, which is a royal pain. 2) You cannot mockup a singleton. Once everyone calls the SomeSingleton class statically, you can't replace your class by SomeSingletonMockup. Furthermore, even for hardware services, the Singleton pattern does not really prevent concurrent accesses. If you start the same program in two different JVMs, unless they somehow shared the state of their "Singletons" (through lock files for example), the Singleton pattern will not prevent concurrent access. Our application uses RXTX, and we routinely encounter cases where another (native) application has already locked the port. Since we cannot modify the native application to recognize lock files, OS-level control is irreplaceable. > > Consequences > The Parametric Singleton Design Pattern has several benefits: > > 1. Controlled access to parametrically defined instances. Since > the Parametric Singleton class encapsulates its instances, there is > control over how and when clients access it. Not really. Once you've returned the instance to a client, you've lost control over it. The client can to whatever it wants with it. You cannot "recall" the instance or claim it back. > 2. Reduced name space. The Parametric Singleton pattern avoids > global variables that store instances created from the same parameter. Sure, but you don't have to rely on a Singleton for that. Just create a single Factory. > I would very much like to get your feedback on this new design > pattern idea. Well, it's nothing new. Some may say that it is the point of design patterns: formalizes the designs that occur again and again. However, this design is simply a combination of the Singleton and Factory patterns. I did use it in the past, but now I've been exposed to the shortcomings of the Singleton pattern, so I limit myself to Factories. Regards, David From sean_montgomery at baseview.com Wed Mar 22 08:35:28 2006 From: sean_montgomery at baseview.com (Sean Montgomery) Date: Tue Mar 28 18:25:38 2006 Subject: [Rxtx] sole of a new design pattern In-Reply-To: <442160DA.80107@trusted-logic.com> References: <442160DA.80107@trusted-logic.com> Message-ID: <05769CA7-A51B-4CF0-BAA0-E02DD905F5A4@baseview.com> On Mar 22, 2006, at 9:36 AM, David Garnier wrote: > Furthermore, even for hardware services, the Singleton pattern does > not really prevent concurrent > accesses. If you start the same program in two different JVMs, > unless they somehow shared the state > of their "Singletons" (through lock files for example), the > Singleton pattern will not prevent > concurrent access. > Multiple class loaders in a single JVM can be tricky, too. Then there's synchronization, lazy initialization and serialization of singletons to contend with. Bloch's Effective Java covers these, and here's a few articles: http://www.javaworld.com/javaworld/jw-04-2003/jw-0425-designpatterns- p3.html http://java.sun.com/developer/technicalArticles/Programming/singletons/ Just FYI :-) From lyon at docjava.com Wed Mar 22 08:50:48 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Tue Mar 28 18:25:38 2006 Subject: [Rxtx] sole of a new design pattern In-Reply-To: <442160DA.80107@trusted-logic.com> References: <442160DA.80107@trusted-logic.com> Message-ID: Hi All, First, I would like to thank David for his prompt and thoughtful remarks. I had no idea people that feel strongly about a design patterns! Wow! Feedback (particularly critical feedback) is greatly appreciated. Starting at the end, first: >I did use it in >the past, but now I've been exposed to the shortcomings of the >Singleton pattern, so I limit myself to Factories. David, if I understood your comments correctly, you suggested that Factories can be used in leu of the Singleton Design Pattern, or even the Parametric Singleton Design Pattern. As I see in [Gof]: Factory Method: Intent "Define an interface for creating an object, but let subclasses decide which class to instantiate. Factory Method lets a class defer instantiation to subclasses." The Singleton Design Pattern is a concrete class, which is rather different, right? Also, subclasses are not permitted with Singleton, as they are final. Naturally, I could use an abstract factory as a parent for a singleton. I could even design a facade that could be implemented with the singleton....but that is not the intention of the design. Unless you want a mock-up, as discussed, below: More below: >Hello, > >> The Parametric Singleton Design Pattern > >The Singleton is the most abused design pattern ever. Good use-cases >for this pattern are extremely >rare and mostly confined to problems related to hardware resources, >like serial ports. > > >> Applicability >> >> Use the Parametric Singleton Design Pattern when: >> 1. There must be exactly one instance of a class with the given >> parameters. >OK. As I said above, this case this actually very unusual. The >Singleton pattern is mostly used when : >> 2. The instances must be accessible to clients from a well-known >> access point. > >Using the singleton pattern in this case is just convenient for the >programmer. Problems arises >pretty quickly, especially if you attempt to unit-test your classes. > >1) If your singleton is stateful, or hold on to stateful objects, it >means that two different unit >tests are not actually independent. Instead of starting with a brand >new environment, the result of >a test may be affected by the result of a previous test. This >problem also arise when with your >class relies on a database. In both cases, the solution is to reset >your "unique" resource >(Singleton or database) at the beginning of the test, which is a >pain. Also, while most projects >connect to a single database, projects that allow the use of >Singletons usually contain several of >thems, and new ones may cropped up unnoticed. You quickly end up >with test cases that only pass in a >certain order, which is a royal pain. There are basic problems with communicating finite state machines that include reachability and deadlock analysis. These are addressed with petri net analysis and are beyond the scope of the design pattern. As you quite rightly pointed out; the parametric singleton pattern (or the singleton pattern, for that matter) enable multiple threads to gain access to the same instance. The only way that I can see to block others from gaining access to the reference is the synchronize keyword. This is putting a spin-lock (or MUTEX) on the reference. The question of how to unit-test a design pattern like the parametric singleton remains open. Perhaps this is a deficiency. > >2) You cannot mockup a singleton. Once everyone calls the >SomeSingleton class statically, you can't >replace your class by SomeSingletonMockup. Acutally, I am not sure that this is true. If the Singleton implements a Facade interface, it should be possible to make the replacement. Right? > >Furthermore, even for hardware services, the Singleton pattern does >not really prevent concurrent >accesses. If you start the same program in two different JVMs, >unless they somehow shared the state >of their "Singletons" (through lock files for example), the >Singleton pattern will not prevent >concurrent access. Good Point!! You have sharp eyes! The singleton design pattern should/could take responsibility for this. In fact, you may notice that my code does have an implementation (LocateRegistry) that can work across JVM's. The LocateRegistry will even work across the Internet! LocateRegistry takes both a host name and a Port (lock files just don't do this). I did not think to implement this beyond the local machine, but, in its present form, it will work across different processes. > >Our application uses RXTX, and we routinely encounter cases where >another (native) application has >already locked the port. Since we cannot modify the native >application to recognize lock files, >OS-level control is irreplaceable. The singleton design pattern is not meant to replace OS-level control, but to centralize the Java programmers access to it. If lock files, for example, are used for serial ports, the Singleton Design Pattern should be able to work with them. > > >> >> Consequences >> The Parametric Singleton Design Pattern has several benefits: >> > > 1. Controlled access to parametrically defined instances. Since >> the Parametric Singleton class encapsulates its instances, there is >> control over how and when clients access it. > >Not really. Once you've returned the instance to a client, you've >lost control over it. The client >can to whatever it wants with it. You cannot "recall" the instance >or claim it back. Good point, this should read: > 1. Controll when parametrically defined instances are created. Since > > the Parametric Singleton class encapsulates its instances, there is > > control over how and when they are instanced. > >> 2. Reduced name space. The Parametric Singleton pattern avoids >> global variables that store instances created from the same parameter. > >Sure, but you don't have to rely on a Singleton for that. Just >create a single Factory. > > Thank you for your thoughtful and prompt response! Regards, - Doug From dmarkman at mac.com Wed Mar 22 21:21:55 2006 From: dmarkman at mac.com (Dmitry Markman) Date: Tue Mar 28 18:25:38 2006 Subject: [Rxtx] sole of a new design pattern In-Reply-To: <442160DA.80107@trusted-logic.com> References: <442160DA.80107@trusted-logic.com> Message-ID: I don't think I get it On Mar 22, 2006, at 9:36 AM, David Garnier wrote: > Using the singleton pattern in this case is just convenient for the > programmer. Problems arises > pretty quickly, especially if you attempt to unit-test your classes. so you're saying that something isn't so good because you can not test it in the convenient way? if that's true, I'm totally disagree change your test, debug whatever, but if software is efficient at runtime, works fine and only problem is some unit test (which is some kind of framework for testing) then dump that unit test , dump that unit framework and make something appropriate to the software you're testing so if Douglas want to use singletons, what's the problem? and what do you mean by abusing of singleton usage? of course singleton doesn't prevent concurrent access to the resource across the processes unless you're using some OS facility to prevent it, besides singleton as it was introduced is relevant only and only inside of the same process otherwise it's not singleton it's something else (let's say network singleton: so you have remote invocation facility and some factory method that return object created by that facility) I don't have any problem with using any kind of singletons. Parametric Singleton idea (if I understand it right) could be easily implemented in the following way: use a map populate map with instances of some class and key is your parameter (you can use lazy population too) if somebody ask the key check the value if it's null so resource is taken if somebody returns the resource put it back to the map public synchronized static Object getSomeResource(Object parameter); public synchronized static void returnResource(Object parameter); getSomeResource (inside of the same process) could return null in 2 cases 1. if somebody (from other thread for example) already took that resource 2. if OS API said that resource corresponded to that parameter (serial port with parameter = 1 (port #)) is locked and unavailable; I'm not sure that in case of serial ports we even need those Parametric Singletons (unless lock checking is a very expensive operation) just ask the OS about availability of that resource and if it's available give it away and then OS will lock it and therefore in next time somebody ask it just answer that resource is locked and return null for example system has 2 serial ports available so I ask getResource("tty"); or I ask getResource("Bluetooth-Modem"); and if OS is ok you can give tty or Bluetooth-Modem or both no need for any additional pattern I think back to the problem mac os x doesn't recognize locking via files, so it handles locking via some API an instance of the singleton in each process should recognize that resource is locked (by using that API) that's all we don't have to make things more complicate then they are just because there is some nice design pattern or nice unit test framework or whatever keep things simple, make them work fast, don't introduce middle layers unless you have really good reason to do so of course I could be entirely wrong, so sorry about that in advance thanks Dmitry Markman From tjarvi at qbang.org Wed Mar 22 22:31:41 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue Mar 28 18:25:38 2006 Subject: [Rxtx] sole of a new design pattern In-Reply-To: References: Message-ID: Hi Doug Interesting reading. So far I'm just reading and thinking. I have one question so far. " Clients obtain a reference to a Parametric Singleton instance only through the parametric singleton design pattern. If the instance is left in an improper state (e.g., the serial port was left open) it is NOT the role of the Parametric Singleton Design Pattern to close the IO port. Nor is it the role of the Parametric Singleton Design Pattern to open the port. That role is delegate to some other part of the system. " So when the clients obtain a reference to the singleton, can they assume the port is there? IE, would it be the singletons role to handle things like USB dongles being removed with event hints comming from the underlying OS. Hardware abstraction layer/HAL on Linux is an example of underlying OS events. I assume that role too is delegated to other parts of the system? -- Trent Jarvi tjarvi@qbang.org From lyon at docjava.com Thu Mar 23 08:10:33 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Tue Mar 28 18:25:38 2006 Subject: [Rxtx] Classes don't need goals, they need roles! In-Reply-To: References: Message-ID: Hi Trent, Yes, I think that the role of the Parametric Singleton Pattern is not to open or close serial ports, nor is it to perform error checking. On the other hand, if you were to combine the role of the Parametric Singleton Pattern with another role (like that of error checking) it might not be amiss. However, I generally caution programmers against adding multiple roles to classes, as this leads to monolithic designs. Thus a different class (NativeLibDetect) could have the role of determining if the native library can be loaded. Another class (SerialPortBean) can have the role of serializing the default state of the serial port, so that it can be recovered, from user preferences, at a later time. The SerialPortDetect could have the role of determining if the serial port is removed (i.e., a USB port was unplugged). My guess is that each class should have a different role in the system, in order to ease maintenance and testing...but I could be wrong about that. Thanks! - Doug >Hi Doug > >Interesting reading. So far I'm just reading and thinking. I have >one question so far. > >" > Clients obtain a reference to a Parametric Singleton instance only >through the parametric singleton design pattern. If the instance is >left in an improper state (e.g., the serial port was left open) it is >NOT the role of the Parametric Singleton Design Pattern to close the >IO port. Nor is it the role of the Parametric Singleton Design Pattern >to >open the port. That role is delegate to some other part of the system. >" > >So when the clients obtain a reference to the singleton, can they >assume the port is there? IE, would it be the singletons role to >handle things like USB dongles being removed with event hints >comming from the underlying OS. Hardware abstraction layer/HAL on >Linux is an example of underlying OS events. > >I assume that role too is delegated to other parts of the system? > >-- >Trent Jarvi >tjarvi@qbang.org >_______________________________________________ >Rxtx mailing list >Rxtx@qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From maximulo at yahoo.com Fri Mar 24 01:22:38 2006 From: maximulo at yahoo.com (Maximulo Majir) Date: Tue Mar 28 18:25:38 2006 Subject: [Rxtx] JavaPOS Message-ID: <20060324082238.66371.qmail@web38214.mail.mud.yahoo.com> Hi all! Hello Trent! From what i understand, RXTX or JavaComm APIs were not created solely for JavaPOS. In JavaPOS, we have the virtual method claim() which is separate from open(), but in our RXTX API, claiming is done every call to open(), we cant open the port if its claimed by another application. Would it be alright to suggest or ask to create a new method called claim(..)? Is there such thing as forceclaim() in RXTX? this could be the same as portownership transfer or its equivalent. ForceClaim is in JSR80. Do you have some samples using RXTX as the lower layer for the Device Service Objects in JavaPOS? I have tried it, i just want to compare. Thank you all! maxim __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060324/496adba2/attachment-0002.html From tjarvi at qbang.org Fri Mar 24 11:28:19 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue Mar 28 18:25:38 2006 Subject: [Rxtx] Re: RXTX 2.1 Solaris Problems In-Reply-To: <3691.1143210578@www045.gmx.net> References: <3691.1143210578@www045.gmx.net> Message-ID: On Fri, 24 Mar 2006, Andreas Guenther wrote: > Hi all, > > the solaris problem was not the lock file only. > > Ok, I had to create the directory /var/spool/locks myself. > /var/spool/uucp exists. > > But rxtx didn't find any port. > > I compiled the source with my own debug-informations > and I tried to isolate the problem. > > The problem is the testRead-call in SerialImp.c > > JNIEXPORT jboolean JNICALL RXTXCommDriver(testRead)( > > ... > if ( READ( fd, &c, 1 ) < 0 ) > { > if ( errno != EAGAIN ) { > report( "testRead() read failed\n" ); > ret = JNI_FALSE; > } > } > Thanks Andreas I'm packing up to move. I'll be more or less away for a couple weeks here. I'll be checking email but my workstation is going into a box soon. This isn't hard to fix as this port should be enumerated when EWOULDBLOCK is recieved. Thats error is OK for enumeration just as EAGAIN is. I've put the bug into bugzilla so we dont forget to get to it. http://bugzilla.qbang.org/show_bug.cgi?id=42 You can add yourself to the CC list if you wish to test fixes we provide or even put a patch into bugzilla yourself. -- Trent Jarvi tjarvi@qbang.org From tjarvi at qbang.org Fri Mar 24 11:51:52 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue Mar 28 18:25:38 2006 Subject: [Rxtx] JavaPOS In-Reply-To: <20060324082238.66371.qmail@web38214.mail.mud.yahoo.com> References: <20060324082238.66371.qmail@web38214.mail.mud.yahoo.com> Message-ID: On Fri, 24 Mar 2006, Maximulo Majir wrote: > Hi all! Hello Trent! > > > From what i understand, RXTX or JavaComm APIs were not > created solely for JavaPOS. In JavaPOS, we have the virtual method > claim() which is separate from open(), but in our RXTX API, claiming is > done every call to open(), we cant open the port if its claimed by > another application. Would it be alright to suggest or ask to create a > new method called claim(..)? Is there such thing as forceclaim() in > RXTX? this could be the same as portownership transfer or its > equivalent. ForceClaim is in JSR80. > Do you have some samples using RXTX as the lower layer for the Device > Service Objects in JavaPOS? I have tried it, i just want to compare. > maxim Hi Maxim JSR80 is the USB API IBM/Sun put together. The problem is they have a richer kernel/API underneath that can handle such things. With Serial Ports, there isnt anything there other than an ioctl that says don't let anyone touch this and lockfiles that are more of a 'lets be nice.' At times we may be using USB ports but it is through the termios layer with the limitations mentioned. The advantage is that not only USB will work with rxtx. Anything that has a termios layer should work (to the extent that termios layer is complete). I don't know how forceclaim() would help you. Lets say someone has a programmer working on /dev/ttyS0 and you take it. Now you both race each other to read data first. There isn't a mechanism I know of that will solve this problem in termios. The most obvious test being a native app and a Java app trying to take the port. There is the potential of requestion ownership from other Java Applications but the use for that is very rare. Did you have something more specific in mind that I'm missing? I'm not sure that claim() and forceclaim() would help you with rxtx other than maybe locking the port with claim() without opening it. -- Trent Jarvi tjarvi@qbang.org From tjarvi at qbang.org Sat Mar 25 23:42:08 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue Mar 28 18:25:38 2006 Subject: [Rxtx] Serial snoop Message-ID: I was reading the Linux kernel mail-list tonight and ran past a thread that mentioned sersnoop. This looks like a handy tool for people dealing with new toys. "a simple command-line tool for linux that echoes bytes to and from any two serial ports, ptys, or network sockets, and prints all traffic to stdout, in hex and ascii." http://www.restivo.org/projects/sersnoop/ It works on Linux only at this time (debian package available). -- Trent Jarvi tjarvi@qbang.org From beat.arnet at gmail.com Sun Mar 26 07:32:35 2006 From: beat.arnet at gmail.com (Beat Arnet) Date: Tue Mar 28 18:25:38 2006 Subject: [Rxtx] Error 0x5 at /home/bob/foo/tar/rxtx-2.1-7/build/../src/termios.c(860): Access is, denied. Message-ID: <4426A603.80508@gmail.com> Dear all, When trying to open the serial port, I sometimes (not always) run into the following exception (when opening the serialPort): Error 0x5 at /home/bob/foo/tar/rxtx-2.1-7/build/../src/termios.c(860): Access is denied. java.lang.UnsatisfiedLinkError: native_psmisc_report_owner at gnu.io.CommPortIdentifier.native_psmisc_report_owner(Native Method) at gnu.io.CommPortIdentifier.open(CommPortIdentifier.java:354) at codeskin.tools.CLLoader.open(CLLoader.java:79) at codeskin.tools.C2000Programmer.run(C2000Programmer.java:220) at java.lang.Thread.run(Unknown Source) Is this the type of error where I should just try to open the port again, or can it be avoided? Regards, Beat From tjarvi at qbang.org Sun Mar 26 11:40:12 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue Mar 28 18:25:38 2006 Subject: [Rxtx] Error 0x5 at /home/bob/foo/tar/rxtx-2.1-7/build/../src/termios.c(860): Access is, denied. In-Reply-To: <4426A603.80508@gmail.com> References: <4426A603.80508@gmail.com> Message-ID: On Sun, 26 Mar 2006, Beat Arnet wrote: > Dear all, > > When trying to open the serial port, I sometimes (not always) run into > the following exception (when opening the serialPort): > > Error 0x5 at /home/bob/foo/tar/rxtx-2.1-7/build/../src/termios.c(860): > Access is > denied. > > java.lang.UnsatisfiedLinkError: native_psmisc_report_owner > at gnu.io.CommPortIdentifier.native_psmisc_report_owner(Native > Method) > at gnu.io.CommPortIdentifier.open(CommPortIdentifier.java:354) > at codeskin.tools.CLLoader.open(CLLoader.java:79) > at codeskin.tools.C2000Programmer.run(C2000Programmer.java:220) > at java.lang.Thread.run(Unknown Source) > > Is this the type of error where I should just try to open the port again, > or can it be avoided? > Hi Beat We did a second build of rxtx 2.1-7 to resolve that unsatisfied link error. It should work now. rxtx is trying to tell you it thinks someone else has the serial port open. You can try to open the port again but maybe you already have a copy of the program running when it happens? ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7r2.zip fixed build. -- Trent Jarvi tjarvi@qbang.org From tjarvi at qbang.org Sun Mar 26 11:44:23 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue Mar 28 18:25:38 2006 Subject: [Rxtx] RXTX spec file (fwd) Message-ID: This is probably interesting for fedora/suse users. ---------- Forwarded message ---------- Date: Sun, 26 Mar 2006 16:25:45 +0200 To: taj@www.linux.org.uk Subject: RXTX spec file I send you this spec file which allows to create a RPM for Fedora 4, 5 (x86, x86_64) with Java Sun. -------------- next part -------------- %ifarch %ix86 %define target_cpu i386 %endif %ifarch x86_64 %define target_cpu amd64 %endif Name: rxtx Version: 2.1 Release: 7r2%{?dist} Summary: RXTX Group: Development/Libraries License: LGPL URL: http://www.rxtx.org Source0: %{name}-%{version}-%{release}.tar.gz BuildRoot: %{_tmppath}/%{name}-%{version}-%{release}-root-%(%{__id_u} -n) %description rxtx is an full implementation of java commapi which aims to support RS232 IEEE 1284, RS485, I2C and RawIO. This is a developers release. %prep %setup -q -n %{name}-%{version}-%{release} %build export THREADS_FLAG=native ./autogen.sh %configure \ LDFLAGS=-s make %{?_smp_mflags} %install rm -rf $RPM_BUILD_ROOT mkdir -p $RPM_BUILD_ROOT%{_jvmdir}/jre/lib/ext $RPM_BUILD_ROOT%{_jvmdir}/jre/lib/%{target_cpu} make RXTX_PATH=$RPM_BUILD_ROOT%{_jvmdir}/jre/lib/%{target_cpu} JHOME=$RPM_BUILD_ROOT%{_jvmdir}/jre/lib/ext install echo "Driver=gnu.io.RXTXCommDriver" > $RPM_BUILD_ROOT%{_jvmdir}/jre/lib/gnu.io.rxtx.properties %clean rm -rf $RPM_BUILD_ROOT %files %defattr(-,root,root,-) %doc AUTHORS ChangeLog README RMISecurityManager.html COPYING INSTALL PORTING TODO %{_jvmdir}/jre/lib/* %changelog * Sun Mar 26 2006 Malek Degachi - Rebuild for Fedora Core 4 and Core 5. * Sun Mar 21 2004 Willem Riede - adjust spec file to support rpmbuild by ordinary user in Fedora context. From tjarvi at qbang.org Sun Mar 26 23:42:59 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue Mar 28 18:25:38 2006 Subject: [Rxtx] Upcomming events. Message-ID: This Wednesday we will be announcing a new "Maintainer" for the rxtx project. The position is more like neutral leader. I wont be going away or doing less. This is just the right thing to do as it turns out the two people with CVS write access will be at the same company. We need a third and we need neutrality. The maintainer will have final say in any conflict and will try to be neutral. It will be open for discussion. Then we will do it :) I'll still do most of the footwork I do now. But. I'm falling behind. I should have gone through the mail-list and posted the next round of changes this weekend. I'm packing to move and its going so so - 13 years of toys collected. I suspect there will be a dead period on my part (a couple weeks) comming up. But if you get it on the mail-list, we will get it in if there are no objections. I may well not be reading the mail-list during this period as I look for a house and many other things. I hope everyone will help out. Thanks -- Trent Jarvi tjarvi@qbang.org From dmarkman at mac.com Mon Mar 20 00:20:43 2006 From: dmarkman at mac.com (Dmitry Markman) Date: Tue Mar 28 20:17:31 2006 Subject: [Rxtx] Mac OS X RXTX java installer In-Reply-To: References: <07D0DE29-BA32-4CFE-B036-66BC6423D385@buechse.de> <441AE3E0.2030503@willicon.de> <12531986.1142622114996.JavaMail.dmarkman@mac.com> <441B2674.9010409@willicon.de> <13577405.1142634732776.JavaMail.dmarkman@mac.com> <441B4182.8010407@willicon.de> <92CD0D6C-5BE8-426E-A46D-99452059FF49@mac.com> <441BBB2D.8030305@willicon.de> <441C4088.5090905@willicon.de> Message-ID: <64BC1E23-FDDE-4CE6-8863-CFC881CBC224@mac.com> Hi all I put RXTX installer that will install everything (and will create / var/lock if necessary and add user to the uucp group) for mac os x from Java into the rxtx's CVS repository it could be easily modified to install files for any platform it uses Greg Guerin's AuthKit for authentication and authorization Greg released that kit under artistic license, so Trent, please take a look we, probably, can negotiate license with Greg if it's necessary Greg's AuthKit could be downloaded from http://www.amug.org/~glguerin/ sw/#authkit Michael Hall (mikehall at spacestar dot net) had a suggestion to make implementation of the jaas LoginModule based on Greg's AuthKit (his modification of the Greg's AuthKit could be found at http:// www.spacestar.net/users/mikehall/authkit.dmg) but Michael's AuthKitLoginModule does only half a job: it does authenticate but it can not run any external unix process in privileged mode (at least I wasn't able to do so) possible explanation could be found in conversation between Greg and Michael at Apple's java-dev list (look for archives) so I didn't use jaas API for rxtxinstaller I created folder MacOSX in the contrib folder comment 1. if you want to run that installer as standalone application all you need that RXTXInstaller.jar 2. if you want to use webstart you have to add Greg's libAuthKit.jnilib to the mac os x's resources in theory RXTXInstaller.jar doesn't need it, but there is a problem with loading libAuthKit.jnilib from webstart authkit uses loadLibrary method to load library and it failed (from webstart) for standalone application I extract libAuthKit.jnilib from the RXTXInstaller.jar and put it into the /Library/Java/Extensions or ~/Library/Java/Extensions folder that file will be deleted after installer quit unfortunately I didn't have time to put documentation there but it is mostly self-explanatory I took installer code from my gl4java installer that I did about 3 years ago (with small modifications) it would be very nice if Apple will release LoginModule that really will do the job (com.apple.security.auth.module package????? ) (UnixLoginModule is pretty useless) From lyon at docjava.com Mon Mar 20 06:34:39 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Tue Mar 28 20:17:31 2006 Subject: [Rxtx] Mac OS X RXTX java installer In-Reply-To: <64BC1E23-FDDE-4CE6-8863-CFC881CBC224@mac.com> References: <07D0DE29-BA32-4CFE-B036-66BC6423D385@buechse.de> <441AE3E0.2030503@willicon.de> <12531986.1142622114996.JavaMail.dmarkman@mac.com> <441B2674.9010409@willicon.de> <13577405.1142634732776.JavaMail.dmarkman@mac.com> <441B4182.8010407@willicon.de> <92CD0D6C-5BE8-426E-A46D-99452059FF49@mac.com> <441BBB2D.8030305@willicon.de> <441C4088.5090905@willicon.de> <64BC1E23-FDDE-4CE6-8863-CFC881CBC224@mac.com> Message-ID: Hi Dimitry, This sounds like great work. Just a couple of questions; After the check out of the CVS files, using: setenv CVSROOT :pserver:anonymous@cvs.milestonesolutions.com:/usr/local/cvsroot 53 8:28 setenv PASSWORD mousy 54 8:29 cvs login 55 8:29 cvs checkout rxtx-devel I cd'd over to: rxtx-devel/MACOSX_IDE And found: CVS/ CW/ ForPackageMaker/ PB/ Where is the installer? Thanks! - Doug From tjarvi at qbang.org Mon Mar 20 06:39:37 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue Mar 28 20:17:31 2006 Subject: [Rxtx] Mac OS X RXTX java installer In-Reply-To: References: <07D0DE29-BA32-4CFE-B036-66BC6423D385@buechse.de> <441AE3E0.2030503@willicon.de> <12531986.1142622114996.JavaMail.dmarkman@mac.com> <441B2674.9010409@willicon.de> <13577405.1142634732776.JavaMail.dmarkman@mac.com> <441B4182.8010407@willicon.de> <92CD0D6C-5BE8-426E-A46D-99452059FF49@mac.com> <441BBB2D.8030305@willicon.de> <441C4088.5090905@willicon.de> <64BC1E23-FDDE-4CE6-8863-CFC881CBC224@mac.com> Message-ID: On Mon, 20 Mar 2006, Dr. Douglas Lyon wrote: > Hi Dimitry, > This sounds like great work. Just a couple of questions; > After the check out of the CVS files, using: > setenv CVSROOT > :pserver:anonymous@cvs.milestonesolutions.com:/usr/local/cvsroot > 53 8:28 setenv PASSWORD mousy > 54 8:29 cvs login > 55 8:29 cvs checkout rxtx-devel Hi Doug You want "cvs checkout -r commapi-0-0-1 rxtx-devel" to get RXTX 2.1 The default branch is rxtx 2.0 which isn't very active right now. -- Trent Jarvi tjarvi@qbang.org From lyon at docjava.com Mon Mar 20 07:05:44 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Tue Mar 28 20:17:31 2006 Subject: [Rxtx] Mac OS X RXTX java installer In-Reply-To: References: <07D0DE29-BA32-4CFE-B036-66BC6423D385@buechse.de> <441AE3E0.2030503@willicon.de> <12531986.1142622114996.JavaMail.dmarkman@mac.com> <441B2674.9010409@willicon.de> <13577405.1142634732776.JavaMail.dmarkman@mac.com> <441B4182.8010407@willicon.de> <92CD0D6C-5BE8-426E-A46D-99452059FF49@mac.com> <441BBB2D.8030305@willicon.de> <441C4088.5090905@willicon.de> <64BC1E23-FDDE-4CE6-8863-CFC881CBC224@mac.com> Message-ID: Hi Trent, Thanks for the info on the CVS checkout procedure. I did that and am still not sure where the installer is. Here is what I have: cd MACOSX_IDE/ p4.docjava.com{lyon}121: ls CVS/ ForPackageMaker/ PB/ p4.docjava.com{lyon}122: find . | more . ./ForPackageMaker ./ForPackageMaker/RXTX.pkg.sit.hqx ./ForPackageMaker/Resources ./ForPackageMaker/Resources/ReadMe.rtf ./ForPackageMaker/Resources/Welcome.rtf ./ForPackageMaker/Resources/CVS ./ForPackageMaker/Resources/CVS/Entries ./ForPackageMaker/Resources/CVS/Repository ./ForPackageMaker/Resources/CVS/Tag ./ForPackageMaker/Resources/CVS/Root ./ForPackageMaker/Resources/preinstall ./ForPackageMaker/Resources/License.rtf ./ForPackageMaker/Resources/preupgrade ./ForPackageMaker/RXTX.pmsp ./ForPackageMaker/CVS ./ForPackageMaker/CVS/Entries ./ForPackageMaker/CVS/Repository ./ForPackageMaker/CVS/Entries.Log ./ForPackageMaker/CVS/Tag ./ForPackageMaker/CVS/Root ./ForPackageMaker/RXTX_Tiger.pkg.sitx.hqx ./ForPackageMaker/RXTX_Jag.pkg.sit.hqx ./ForPackageMaker/Install ./ForPackageMaker/Install/CVS ./ForPackageMaker/Install/CVS/Entries ./ForPackageMaker/Install/CVS/Repository ./ForPackageMaker/Install/CVS/Tag ./ForPackageMaker/Install/CVS/Root ./ForPackageMaker/Install/Library ./ForPackageMaker/Install/Library/CVS ./ForPackageMaker/Install/Library/CVS/Entries ./ForPackageMaker/Install/Library/CVS/Repository ./ForPackageMaker/Install/Library/CVS/Tag ./ForPackageMaker/Install/Library/CVS/Root ./ForPackageMaker/Install/Library/Java ./ForPackageMaker/Install/Library/Java/Extensions ./ForPackageMaker/Install/Library/Java/Extensions/RXTXcomm.jar ./ForPackageMaker/Install/Library/Java/Extensions/CVS ./ForPackageMaker/Install/Library/Java/Extensions/CVS/Entries ./ForPackageMaker/Install/Library/Java/Extensions/CVS/Repository ./ForPackageMaker/Install/Library/Java/Extensions/CVS/Tag ./ForPackageMaker/Install/Library/Java/Extensions/CVS/Root ./ForPackageMaker/Install/Library/Java/Extensions/librxtxSerial.jnilib ./ForPackageMaker/Install/Library/Java/CVS ./ForPackageMaker/Install/Library/Java/CVS/Entries ./ForPackageMaker/Install/Library/Java/CVS/Repository ./ForPackageMaker/Install/Library/Java/CVS/Entries.Log ./ForPackageMaker/Install/Library/Java/CVS/Tag ./ForPackageMaker/Install/Library/Java/CVS/Root ./ForPackageMaker/RXTX_Tiger.pmproj.sitx.hqx ./CVS ./CVS/Entries ./CVS/Repository ./CVS/Entries.Log ./CVS/Tag ./CVS/Root ./PB ./PB/LibSerialUniversal.xcodeproj.sitx.hqx ./PB/CVS ./PB/CVS/Entries ./PB/CVS/Repository ./PB/CVS/Entries.Log ./PB/CVS/Tag ./PB/CVS/Root ./PB/LibSerial.pbproj.sit.hqx ./PB/startpoint.c ./PB/config.h What is the procedure to run this installer? Do we need a README in: /rxtx-devel/MACOSX_IDE Here is what we have: CVS/ ForPackageMaker/ PB/ Thanks! - DL >On Mon, 20 Mar 2006, Dr. Douglas Lyon wrote: > >>Hi Dimitry, >>This sounds like great work. Just a couple of questions; >>After the check out of the CVS files, using: >>setenv CVSROOT >>:pserver:anonymous@cvs.milestonesolutions.com:/usr/local/cvsroot >> 53 8:28 setenv PASSWORD mousy >> 54 8:29 cvs login >> 55 8:29 cvs checkout rxtx-devel > >Hi Doug > >You want "cvs checkout -r commapi-0-0-1 rxtx-devel" to get RXTX 2.1 >The default branch is rxtx 2.0 which isn't very active right now. > >-- >Trent Jarvi >tjarvi@qbang.org From tjarvi at qbang.org Mon Mar 20 07:25:30 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue Mar 28 20:17:31 2006 Subject: [Rxtx] Mac OS X RXTX java installer In-Reply-To: References: <07D0DE29-BA32-4CFE-B036-66BC6423D385@buechse.de> <441AE3E0.2030503@willicon.de> <12531986.1142622114996.JavaMail.dmarkman@mac.com> <441B2674.9010409@willicon.de> <13577405.1142634732776.JavaMail.dmarkman@mac.com> <441B4182.8010407@willicon.de> <92CD0D6C-5BE8-426E-A46D-99452059FF49@mac.com> <441BBB2D.8030305@willicon.de> <441C4088.5090905@willicon.de> <64BC1E23-FDDE-4CE6-8863-CFC881CBC224@mac.com> Message-ID: On Mon, 20 Mar 2006, Dr. Douglas Lyon wrote: > Hi Trent, > Thanks for the info on the CVS checkout procedure. > I did that and am still not sure where the installer is. Hi Doug It does look like it was not cvs committed. There is no rxtx-devel/contrib/MacOSX directory in there at the moment. It was mentioned that it was put under contrib. -- Trent Jarvi tjarvi@qbang.org From dmarkman at mac.com Mon Mar 20 07:29:56 2006 From: dmarkman at mac.com (Dmitry Markman) Date: Tue Mar 28 20:17:31 2006 Subject: [Rxtx] Mac OS X RXTX java installer In-Reply-To: References: <07D0DE29-BA32-4CFE-B036-66BC6423D385@buechse.de> <441AE3E0.2030503@willicon.de> <12531986.1142622114996.JavaMail.dmarkman@mac.com> <441B2674.9010409@willicon.de> <13577405.1142634732776.JavaMail.dmarkman@mac.com> <441B4182.8010407@willicon.de> <92CD0D6C-5BE8-426E-A46D-99452059FF49@mac.com> <441BBB2D.8030305@willicon.de> <441C4088.5090905@willicon.de> <64BC1E23-FDDE-4CE6-8863-CFC881CBC224@mac.com> Message-ID: <6054EB4E-F7E0-4A9C-BDDA-D582D6D8826F@mac.com> you can find it in the rxtx-devel/contrib folder On Mar 20, 2006, at 9:05 AM, Dr. Douglas Lyon wrote: > Hi Trent, > Thanks for the info on the CVS checkout procedure. > I did that and am still not sure where the installer is. > Here is what I have: > cd MACOSX_IDE/ > p4.docjava.com{lyon}121: ls > CVS/ ForPackageMaker/ PB/ > p4.docjava.com{lyon}122: find . | more > . > ./ForPackageMaker > ./ForPackageMaker/RXTX.pkg.sit.hqx > ./ForPackageMaker/Resources > ./ForPackageMaker/Resources/ReadMe.rtf > ./ForPackageMaker/Resources/Welcome.rtf > ./ForPackageMaker/Resources/CVS > ./ForPackageMaker/Resources/CVS/Entries > ./ForPackageMaker/Resources/CVS/Repository > ./ForPackageMaker/Resources/CVS/Tag > ./ForPackageMaker/Resources/CVS/Root > ./ForPackageMaker/Resources/preinstall > ./ForPackageMaker/Resources/License.rtf > ./ForPackageMaker/Resources/preupgrade > ./ForPackageMaker/RXTX.pmsp > ./ForPackageMaker/CVS > ./ForPackageMaker/CVS/Entries > ./ForPackageMaker/CVS/Repository > ./ForPackageMaker/CVS/Entries.Log > ./ForPackageMaker/CVS/Tag > ./ForPackageMaker/CVS/Root > ./ForPackageMaker/RXTX_Tiger.pkg.sitx.hqx > ./ForPackageMaker/RXTX_Jag.pkg.sit.hqx > ./ForPackageMaker/Install > ./ForPackageMaker/Install/CVS > ./ForPackageMaker/Install/CVS/Entries > ./ForPackageMaker/Install/CVS/Repository > ./ForPackageMaker/Install/CVS/Tag > ./ForPackageMaker/Install/CVS/Root > ./ForPackageMaker/Install/Library > ./ForPackageMaker/Install/Library/CVS > ./ForPackageMaker/Install/Library/CVS/Entries > ./ForPackageMaker/Install/Library/CVS/Repository > ./ForPackageMaker/Install/Library/CVS/Tag > ./ForPackageMaker/Install/Library/CVS/Root > ./ForPackageMaker/Install/Library/Java > ./ForPackageMaker/Install/Library/Java/Extensions > ./ForPackageMaker/Install/Library/Java/Extensions/RXTXcomm.jar > ./ForPackageMaker/Install/Library/Java/Extensions/CVS > ./ForPackageMaker/Install/Library/Java/Extensions/CVS/Entries > ./ForPackageMaker/Install/Library/Java/Extensions/CVS/Repository > ./ForPackageMaker/Install/Library/Java/Extensions/CVS/Tag > ./ForPackageMaker/Install/Library/Java/Extensions/CVS/Root > ./ForPackageMaker/Install/Library/Java/Extensions/librxtxSerial.jnilib > ./ForPackageMaker/Install/Library/Java/CVS > ./ForPackageMaker/Install/Library/Java/CVS/Entries > ./ForPackageMaker/Install/Library/Java/CVS/Repository > ./ForPackageMaker/Install/Library/Java/CVS/Entries.Log > ./ForPackageMaker/Install/Library/Java/CVS/Tag > ./ForPackageMaker/Install/Library/Java/CVS/Root > ./ForPackageMaker/RXTX_Tiger.pmproj.sitx.hqx > ./CVS > ./CVS/Entries > ./CVS/Repository > ./CVS/Entries.Log > ./CVS/Tag > ./CVS/Root > ./PB > ./PB/LibSerialUniversal.xcodeproj.sitx.hqx > ./PB/CVS > ./PB/CVS/Entries > ./PB/CVS/Repository > ./PB/CVS/Entries.Log > ./PB/CVS/Tag > ./PB/CVS/Root > ./PB/LibSerial.pbproj.sit.hqx > ./PB/startpoint.c > ./PB/config.h > > What is the procedure to run this installer? > Do we need a README in: > /rxtx-devel/MACOSX_IDE > Here is what we have: > CVS/ ForPackageMaker/ PB/ > > > Thanks! > - DL > >> On Mon, 20 Mar 2006, Dr. Douglas Lyon wrote: >> >>> Hi Dimitry, >>> This sounds like great work. Just a couple of questions; >>> After the check out of the CVS files, using: >>> setenv CVSROOT :pserver:anonymous@cvs.milestonesolutions.com:/usr/ >>> local/cvsroot >>> 53 8:28 setenv PASSWORD mousy >>> 54 8:29 cvs login >>> 55 8:29 cvs checkout rxtx-devel >> >> Hi Doug >> >> You want "cvs checkout -r commapi-0-0-1 rxtx-devel" to get RXTX 2.1 >> The default branch is rxtx 2.0 which isn't very active right now. >> >> -- >> Trent Jarvi >> tjarvi@qbang.org > > _______________________________________________ > Rxtx mailing list > Rxtx@qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx Dmitry Markman From mikehall at spacestar.net Mon Mar 20 05:25:25 2006 From: mikehall at spacestar.net (Michael Hall) Date: Tue Mar 28 20:17:31 2006 Subject: [Rxtx] Re: Mac OS X RXTX java installer In-Reply-To: <64BC1E23-FDDE-4CE6-8863-CFC881CBC224@mac.com> References: <07D0DE29-BA32-4CFE-B036-66BC6423D385@buechse.de> <441AE3E0.2030503@willicon.de> <12531986.1142622114996.JavaMail.dmarkman@mac.com> <441B2674.9010409@willicon.de> <13577405.1142634732776.JavaMail.dmarkman@mac.com> <441B4182.8010407@willicon.de> <92CD0D6C-5BE8-426E-A46D-99452059FF49@mac.com> <441BBB2D.8030305@willicon.de> <441C4088.5090905@willicon.de> <64BC1E23-FDDE-4CE6-8863-CFC881CBC224@mac.com> Message-ID: <247EB61F-5CD1-4132-89A2-FC105B6CF9A5@spacestar.net> On Mar 20, 2006, at 1:20 AM, Dmitry Markman wrote: > > Michael Hall (mikehall at spacestar dot net) had a suggestion to > make implementation of the jaas LoginModule > based on Greg's AuthKit > (his modification of the Greg's AuthKit could be found at http:// > www.spacestar.net/users/mikehall/authkit.dmg) > but Michael's AuthKitLoginModule does only half a job: > it does authenticate > but it can not run any external unix process in privileged mode (at > least I wasn't able to do so) If you got it working directly with Greg's the point is moot. But to clarify it anyhow. The login module does not allow you to do anything anything privileged on return as was explained by Greg. You need to work with a separate privileged process using the execPrivileged method of his API. I assume you did something similar although I haven't looked at how you are using it yet. I allowed instead for a action to be performed at the same time you login/authenticate,this... System.setProperty("authkit.action","/usr/bin/id"); just before this... lc.login(); To clarify, safely ignored as you are already complete. Mike Hall mikehall at spacestar dot net http://www.spacestar.net/users/mikehall http://sourceforge.net/projects/macnative -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2427 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20060320/f6e18202/smime-0003.bin From dmarkman at mac.com Mon Mar 20 07:36:47 2006 From: dmarkman at mac.com (Dmitry Markman) Date: Tue Mar 28 20:17:31 2006 Subject: [Rxtx] Re: Mac OS X RXTX java installer In-Reply-To: <247EB61F-5CD1-4132-89A2-FC105B6CF9A5@spacestar.net> References: <07D0DE29-BA32-4CFE-B036-66BC6423D385@buechse.de> <441AE3E0.2030503@willicon.de> <12531986.1142622114996.JavaMail.dmarkman@mac.com> <441B2674.9010409@willicon.de> <13577405.1142634732776.JavaMail.dmarkman@mac.com> <441B4182.8010407@willicon.de> <92CD0D6C-5BE8-426E-A46D-99452059FF49@mac.com> <441BBB2D.8030305@willicon.de> <441C4088.5090905@willicon.de> <64BC1E23-FDDE-4CE6-8863-CFC881CBC224@mac.com> <247EB61F-5CD1-4132-89A2-FC105B6CF9A5@spacestar.net> Message-ID: Hi, Michael all I have to do is to run some shell script I tried to use your action mechanism and it worked great so I just System.setProperty ("authkit.action","" ) and after that I even don't need to run anything like subject.doAs.... but after few thoughts I choose to use plain Greg's approach, because in that case I don't have to deal with various java's configurations files and therefore to use 2-3 -D parameters in the java command line especially it's useful for java web start (it's so fragile :-( ) thanks for the great job On Mar 20, 2006, at 7:25 AM, Michael Hall wrote: > > On Mar 20, 2006, at 1:20 AM, Dmitry Markman wrote: >> >> Michael Hall (mikehall at spacestar dot net) had a suggestion to >> make implementation of the jaas LoginModule >> based on Greg's AuthKit >> (his modification of the Greg's AuthKit could be found at http:// >> www.spacestar.net/users/mikehall/authkit.dmg) >> but Michael's AuthKitLoginModule does only half a job: >> it does authenticate >> but it can not run any external unix process in privileged mode >> (at least I wasn't able to do so) > > If you got it working directly with Greg's the point is moot. > > But to clarify it anyhow. > The login module does not allow you to do anything anything > privileged on return as was explained by Greg. You need to work > with a separate privileged process using the execPrivileged method > of his API. I assume you did something similar although I haven't > looked at how you are using it yet. > I allowed instead for a action to be performed at the same time you > login/authenticate,this... > System.setProperty("authkit.action","/usr/bin/id"); > just before this... > lc.login(); > To clarify, safely ignored as you are already complete. > > Mike Hall mikehall at spacestar dot net > http://www.spacestar.net/users/mikehall > http://sourceforge.net/projects/macnative > > > Dmitry Markman From dmarkman at mac.com Mon Mar 20 07:44:45 2006 From: dmarkman at mac.com (Dmitry Markman) Date: Tue Mar 28 20:17:31 2006 Subject: [Rxtx] Mac OS X RXTX java installer In-Reply-To: References: <07D0DE29-BA32-4CFE-B036-66BC6423D385@buechse.de> <441AE3E0.2030503@willicon.de> <12531986.1142622114996.JavaMail.dmarkman@mac.com> <441B2674.9010409@willicon.de> <13577405.1142634732776.JavaMail.dmarkman@mac.com> <441B4182.8010407@willicon.de> <92CD0D6C-5BE8-426E-A46D-99452059FF49@mac.com> <441BBB2D.8030305@willicon.de> <441C4088.5090905@willicon.de> <64BC1E23-FDDE-4CE6-8863-CFC881CBC224@mac.com> Message-ID: it's in the commapi-0-0-1 branch I tested it right now: cvs co -r commapi-0-0-1 rxtx-devel and I got everything On Mar 20, 2006, at 9:25 AM, Trent Jarvi wrote: > On Mon, 20 Mar 2006, Dr. Douglas Lyon wrote: > >> Hi Trent, >> Thanks for the info on the CVS checkout procedure. >> I did that and am still not sure where the installer is. > > Hi Doug > > It does look like it was not cvs committed. There is no rxtx-devel/ > contrib/MacOSX directory in there at the moment. It was mentioned > that it was put under contrib. > > -- > Trent Jarvi > tjarvi@qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx@qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx Dmitry Markman From tjarvi at qbang.org Mon Mar 20 07:52:57 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue Mar 28 20:17:31 2006 Subject: [Rxtx] Mac OS X RXTX java installer In-Reply-To: References: <07D0DE29-BA32-4CFE-B036-66BC6423D385@buechse.de> <441AE3E0.2030503@willicon.de> <12531986.1142622114996.JavaMail.dmarkman@mac.com> <441B2674.9010409@willicon.de> <13577405.1142634732776.JavaMail.dmarkman@mac.com> <441B4182.8010407@willicon.de> <92CD0D6C-5BE8-426E-A46D-99452059FF49@mac.com> <441BBB2D.8030305@willicon.de> <441C4088.5090905@willicon.de> <64BC1E23-FDDE-4CE6-8863-CFC881CBC224@mac.com> Message-ID: On Mon, 20 Mar 2006, Dmitry Markman wrote: > it's in the commapi-0-0-1 branch > > I tested it right now: > cvs co -r commapi-0-0-1 rxtx-devel > > and I got everything > A fresh checkout worked. Here is a copy of the tree (just the installer bits) ftp://ftp.qbang.org/pub/rxtx/MacOSX-installer.zip -- Trent Jarvi tjarvi@qbang.org From lyon at docjava.com Mon Mar 20 08:08:26 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Tue Mar 28 20:17:31 2006 Subject: [Rxtx] Mac OS X RXTX java installer In-Reply-To: References: <07D0DE29-BA32-4CFE-B036-66BC6423D385@buechse.de> <441AE3E0.2030503@willicon.de> <12531986.1142622114996.JavaMail.dmarkman@mac.com> <441B2674.9010409@willicon.de> <13577405.1142634732776.JavaMail.dmarkman@mac.com> <441B4182.8010407@willicon.de> <92CD0D6C-5BE8-426E-A46D-99452059FF49@mac.com> <441BBB2D.8030305@willicon.de> <441C4088.5090905@willicon.de> <64BC1E23-FDDE-4CE6-8863-CFC881CBC224@mac.com> Message-ID: Hi All, Is the Auth package able to work properly on non Mac OS's? It was not clear from the doc or download. Thanks! - Doug From dmarkman at mac.com Mon Mar 20 08:15:22 2006 From: dmarkman at mac.com (Dmitry Markman) Date: Tue Mar 28 20:17:31 2006 Subject: [Rxtx] Mac OS X RXTX java installer In-Reply-To: References: <07D0DE29-BA32-4CFE-B036-66BC6423D385@buechse.de> <441AE3E0.2030503@willicon.de> <12531986.1142622114996.JavaMail.dmarkman@mac.com> <441B2674.9010409@willicon.de> <13577405.1142634732776.JavaMail.dmarkman@mac.com> <441B4182.8010407@willicon.de> <92CD0D6C-5BE8-426E-A46D-99452059FF49@mac.com> <441BBB2D.8030305@willicon.de> <441C4088.5090905@willicon.de> <64BC1E23-FDDE-4CE6-8863-CFC881CBC224@mac.com> Message-ID: <217312D8-CCCA-4859-ABA6-32DF1CC817B9@mac.com> thanks Trent, for putting it on ftp server On Mar 20, 2006, at 9:52 AM, Trent Jarvi wrote: > A fresh checkout worked. Here is a copy of the tree (just the > installer bits) > > ftp://ftp.qbang.org/pub/rxtx/MacOSX-installer.zip > Dmitry Markman From dmarkman at mac.com Mon Mar 20 09:14:03 2006 From: dmarkman at mac.com (Dmitry Markman) Date: Tue Mar 28 20:17:31 2006 Subject: [Rxtx] Mac OS X RXTX java installer In-Reply-To: References: <07D0DE29-BA32-4CFE-B036-66BC6423D385@buechse.de> <441AE3E0.2030503@willicon.de> <12531986.1142622114996.JavaMail.dmarkman@mac.com> <441B2674.9010409@willicon.de> <13577405.1142634732776.JavaMail.dmarkman@mac.com> <441B4182.8010407@willicon.de> <92CD0D6C-5BE8-426E-A46D-99452059FF49@mac.com> <441BBB2D.8030305@willicon.de> <441C4088.5090905@willicon.de> <64BC1E23-FDDE-4CE6-8863-CFC881CBC224@mac.com> Message-ID: <4DEBA6F0-DA45-4E84-823E-1F1AC48BDCCC@mac.com> no it will work only on mac os x however it's harmless to run it on other platform if you want to use it for other platform you have to do the following (I'll do it for linux) 1. modify RXTXInstaller class method public static RXTXInstaller getInstance() public static RXTXInstaller getInstance() { String osName = System.getProperty("os.name").toLowerCase(); if(osName.startsWith("mac")){ return new gnu.io.installer.macosx.MACOSXRXTXInstaller(); } else if(osName.startsWith("windows")){ return new gnu.io.installer.windows.WindowsRXTXInstaller(); }else if(osName.startsWith("linux")){ return new gnu.io.installer.linux.LinuxRXTXInstaller(); } return null; } 2. create folder gnu/io/installer/linux/ 3. create class Linux386RXTXInstaller package gnu.io.installer.linux; import java.io.File; public class Linux386RXTXInstaller extends gnu.io.installer.RXTXInstaller{ public Linux386RXTXInstaller(){ createJarFolder(); createLibFolder(); addJarResource("RXTXcomm.jar","/gnu/io/installer/resources/ linux/jar/RXTXcomm.dat"); addLibResource("librxtxSerial.so","/gnu/io/installer/ resources/linux/lib/librxtxSerial.so"); } protected void createJarFolder(){ String javaHome = System.getProperty("java.home"); char separator = File.separatorChar; jarFolder = new File(javaHome+separator+"lib"+separator+"ext"); } protected void createLibFolder(){ String javaHome = System.getProperty("java.home"); char separator = File.separatorChar; libFolder = new File(javaHome+separator+"bin"); } public void runPreProcess() {} //put here some action you need public void runPostProcess() {} //put here some action you need } 4. create folder /gnu/io/installer/resources/linux/jar and put there linux's version of RXTXcomm.dat (which is renamed RXTXcomm.jar) 5. create folder /gnu/io/installer/resources/linux/lib and put there linux's version of librxtxSerial. so 6. make sure that RXTXInstaller.jar has the following items: /gnu/io/installer/resources/linux/jar/RXTXcomm.jar /gnu/io/installer/resources/linux/lib/librxtxSerial.so 7. modify file installer.pref: jar file RXTXInstaller.jar must have the following item /gnu/io/installer/installer.pref that's basically it for windows you have to do the similar things: just replace linux to windows and librxtxSerial.so to rxtxSerial.dll and create appropriate gnu.io.installer.windows.WindowsRXTXInstaller class package gnu.io.installer.windows; import java.io.File; public class WindowsRXTXInstaller extends gnu.io.installer.RXTXInstaller{ public WindowsRXTXInstaller(){ createJarFolder(); createLibFolder(); addJarResource("RXTXcomm.jar","/gnu/io/installer/resources/ windows/jar/RXTXcomm.dat"); addLibResource("librxtxSerial.so","/gnu/io/installer/ resources/windows/lib/rxtxSerial.dll"); } protected void createJarFolder(){ String javaHome = System.getProperty("java.home"); char separator = File.separatorChar; jarFolder = new File(javaHome+separator+"lib"+separator+"ext"); } protected void createLibFolder(){ String javaHome = System.getProperty("java.home"); char separator = File.separatorChar; libFolder = new File(javaHome+separator+"bin"); } public void runPreProcess() {} //put here some action you need public void runPostProcess() {} //put here some action you need } installer.pref will look like On Mar 20, 2006, at 10:08 AM, Dr. Douglas Lyon wrote: > Hi All, > Is the Auth package able to work properly on > non Mac OS's? > It was not clear from the doc or download. > > Thanks! > - Doug > _______________________________________________ > Rxtx mailing list > Rxtx@qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx Dmitry Markman From joachim at buechse.de Mon Mar 20 10:49:06 2006 From: joachim at buechse.de (Joachim Buechse) Date: Tue Mar 28 20:17:31 2006 Subject: [Rxtx] BUG: Lock file stays even if port opening fails Message-ID: This was only tested on MacOSX but looking at the code, it should be true for all systems that use lock_uucp. I am opening a port which can not be opened (dialup port of a telephone paired via bluetooth but currently not reachable). The lock file is created and stays arround, even though the port open failed. After looking a bit through the code (of 2.17), I really wonder if it wouldn't be a good idea to make the "locking" an explicit operation called from the java code. This would certainly simplify the generation of meaningfull exceptions (and java based debugging). Maybe even the handling of "preopened" ports should be in the Java part of the lib (again for java based debugging puposes). That beeing said, I have no idea if this would be possible for the 2.07 implementation. Regards, Joachim From tjarvi at qbang.org Mon Mar 20 11:24:22 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue Mar 28 20:17:31 2006 Subject: [Rxtx] BUG: Lock file stays even if port opening fails In-Reply-To: References: Message-ID: On Mon, 20 Mar 2006, Joachim Buechse wrote: > This was only tested on MacOSX but looking at the code, it should be true > for all systems that use lock_uucp. > > I am opening a port which can not be opened (dialup port of a telephone > paired via bluetooth but currently not reachable). The lock file is > created and stays arround, even though the port open failed. > > > After looking a bit through the code (of 2.17), I really wonder if it > wouldn't be a good idea to make the "locking" an explicit operation > called from the java code. This would certainly simplify the generation > of meaningfull exceptions (and java based debugging). > Maybe even the handling of "preopened" ports should be in the Java part > of the lib (again for java based debugging puposes). That beeing said, I > have no idea if this would be possible for the 2.07 implementation. > > Regards, Hi Joachim It should be possible in the 2.0-7 implementation too. The calls to RXTXPort.java would not change. We would just do more there Moving more of that logic into Java would be better as many people don't like to look at C code. There is a liblockdev on most Linux distros that can do most of the C code and would be easier to use. The problem is embeded devices will not have that library. The preopened port code has not been really tested. That was a last minute request in a product cycle. I expect it will be tested this year though. As I recall, some devices really do not like CD raising on open. The preopened ports then allow people to mess around in java without power cycling the devices or losing data. -- Trent Jarvi tjarvi@qbang.org From joachim at buechse.de Mon Mar 20 12:01:08 2006 From: joachim at buechse.de (Joachim Buechse) Date: Tue Mar 28 20:17:31 2006 Subject: [Rxtx] BUG: Lock file stays even if port opening fails In-Reply-To: References: Message-ID: Hi Trent, What is your general feeling about moving code to Java? The last days I have been reading quite a bit of the code and there are several things, that might not work as expected. I'll give you two examples from is_device_locked: if LOCKDIR == /var/spool/locks the directory /var/spool/lock will not be checked. LOCKDIR is not checked for lockfiles with unexpected pefixes While these things have probably never been discovered in production, they are still possibly incorrect implementations. If it was Java code, I would write some unit tests producing the errors that could later be corrected. PS: One could imagine to actually implement the whole lockfile handling in Java using some native routines to get the values required (pid, st_dev, st_rdev, ...). On 20.03.2006, at 19:24, Trent Jarvi wrote: > On Mon, 20 Mar 2006, Joachim Buechse wrote: > >> This was only tested on MacOSX but looking at the code, it should >> be true for all systems that use lock_uucp. >> >> I am opening a port which can not be opened (dialup port of a >> telephone paired via bluetooth but currently not reachable). The >> lock file is created and stays arround, even though the port open >> failed. >> >> >> After looking a bit through the code (of 2.17), I really wonder if >> it wouldn't be a good idea to make the "locking" an explicit >> operation called from the java code. This would certainly simplify >> the generation of meaningfull exceptions (and java based debugging). >> Maybe even the handling of "preopened" ports should be in the Java >> part of the lib (again for java based debugging puposes). That >> beeing said, I have no idea if this would be possible for the 2.07 >> implementation. >> >> Regards, > > Hi Joachim > > It should be possible in the 2.0-7 implementation too. The calls > to RXTXPort.java would not change. We would just do more there > Moving more of that logic into Java would be better as many people > don't like to look at C code. There is a liblockdev on most Linux > distros that can do most of the C code and would be easier to use. > The problem is embeded devices will not have that library. > > The preopened port code has not been really tested. That was a > last minute request in a product cycle. I expect it will be tested > this year though. As I recall, some devices really do not like CD > raising on open. The preopened ports then allow people to mess > around in java without power cycling the devices or losing data. > > -- > Trent Jarvi > tjarvi@qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx@qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Mon Mar 20 12:21:02 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue Mar 28 20:17:31 2006 Subject: [Rxtx] BUG: Lock file stays even if port opening fails In-Reply-To: References: Message-ID: On Mon, 20 Mar 2006, Joachim Buechse wrote: > Hi Trent, > > What is your general feeling about moving code to Java? The last days I > have been reading quite a bit of the code and there are several things, > that might not work as expected. > > I'll give you two examples from is_device_locked: > > if LOCKDIR == /var/spool/locks the directory /var/spool/lock will not be > checked. > LOCKDIR is not checked for lockfiles with unexpected pefixes > > While these things have probably never been discovered in production, > they are still possibly incorrect implementations. If it was Java code, I > would write some unit tests producing the errors that could later be > corrected. > > PS: One could imagine to actually implement the whole lockfile handling > in Java using some native routines to get the values required (pid, > st_dev, st_rdev, ...). Hi Joachim I like the idea of moving more of the code into java but there are some things to consider. If you break this into multiple JNI calls, the performance will drop considerably during enumeration of ports. We are looking for 256 ports per dev type vs (16? in Sun's 2.0 and fewer types). Its hard to make assumptions. I've seen virtual ports start at /dev/foo100 for instance. It works out to over 7500 ports on Linux if you enable them all. We already trim that back by default. See Linux-all-ports in RXTXCommDriver.java. There are also native libraries that rxtx can link to. If you move too much into Java, linking to 'standard' libraries with distros will break. "configure --enable-liblock=yes" will not be doable. This is probably a favorable way with RedHat, Debian, Suse and others. Thats the right thing to do if there will be rpms, dpkg, .. For those reasons, I think it still make sense to keep it to a minimal ~3 calls to JNI code that we can use for speed and versatility. lock() isLocked(), unlock() perhaps. When I say speed, its more about avoiding crossing the JNI layer multiple times than java vs C performance. With versatility I think liblock is the right way for most but not all (embeded) linux distros. -- Trent Jarvi tjarvi@qbang.org From joachim at buechse.de Mon Mar 20 12:42:04 2006 From: joachim at buechse.de (Joachim Buechse) Date: Tue Mar 28 20:17:31 2006 Subject: [Rxtx] BUG: Lock file stays even if port opening fails In-Reply-To: References: Message-ID: <82C19FE7-DDCB-45B6-B2C9-7606B66F0124@buechse.de> Ok, what about providing a default implementation in Java? The RXTXCommDriver would call a (native) function useNativeLocking and if it returns true, call the native functions for lock() isLocked (), unlock(), else is would use the Java based default implementation. This could possibly be overriden by a property (again for debugging). Joachim On 20.03.2006, at 20:21, Trent Jarvi wrote: > On Mon, 20 Mar 2006, Joachim Buechse wrote: > >> Hi Trent, >> >> What is your general feeling about moving code to Java? The last >> days I have been reading quite a bit of the code and there are >> several things, that might not work as expected. >> >> I'll give you two examples from is_device_locked: >> >> if LOCKDIR == /var/spool/locks the directory /var/spool/lock will >> not be checked. >> LOCKDIR is not checked for lockfiles with unexpected pefixes >> >> While these things have probably never been discovered in >> production, they are still possibly incorrect implementations. If >> it was Java code, I would write some unit tests producing the >> errors that could later be corrected. >> >> PS: One could imagine to actually implement the whole lockfile >> handling in Java using some native routines to get the values >> required (pid, st_dev, st_rdev, ...). > > Hi Joachim > > I like the idea of moving more of the code into java but there are > some things to consider. > > If you break this into multiple JNI calls, the performance will > drop considerably during enumeration of ports. We are looking for > 256 ports per dev type vs (16? in Sun's 2.0 and fewer types). Its > hard to make assumptions. I've seen virtual ports start at /dev/ > foo100 for instance. > > It works out to over 7500 ports on Linux if you enable them all. > We already trim that back by default. See Linux-all-ports in > RXTXCommDriver.java. > > There are also native libraries that rxtx can link to. If you move > too much into Java, linking to 'standard' libraries with distros > will break. "configure --enable-liblock=yes" will not be doable. > This is probably a favorable way with RedHat, Debian, Suse and > others. Thats the right thing to do if there will be rpms, dpkg, .. > > For those reasons, I think it still make sense to keep it to a > minimal ~3 calls to JNI code that we can use for speed and > versatility. lock() isLocked(), unlock() perhaps. When I say > speed, its more about avoiding crossing the JNI layer multiple > times than java vs C performance. With versatility I think liblock > is the right way for most but not all (embeded) linux distros. > > -- > Trent Jarvi > tjarvi@qbang.org > > _______________________________________________ > Rxtx mailing list > Rxtx@qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Mon Mar 20 12:44:47 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue Mar 28 20:17:31 2006 Subject: [Rxtx] BUG: Lock file stays even if port opening fails In-Reply-To: <82C19FE7-DDCB-45B6-B2C9-7606B66F0124@buechse.de> References: <82C19FE7-DDCB-45B6-B2C9-7606B66F0124@buechse.de> Message-ID: On Mon, 20 Mar 2006, Joachim Buechse wrote: > Ok, what about providing a default implementation in Java? > > The RXTXCommDriver would call a (native) function useNativeLocking and if > it returns true, call the native functions for lock() isLocked(), > unlock(), else is would use the Java based default implementation. This > could possibly be overriden by a property (again for debugging). > Hi Joachim That would be OK with me. -- Trent Jarvi tjarvi@qbang.org From dmarkman at mac.com Mon Mar 20 22:27:45 2006 From: dmarkman at mac.com (Dmitry Markman) Date: Tue Mar 28 20:17:31 2006 Subject: [Rxtx] binaries request Message-ID: <42702213-C222-4937-A585-7CFB17E47608@mac.com> Hi can somebody send me latest linux and windows binaries, please? or where I can find them (I didn't find them in the latest tareball) I gave up with my cygwin: something wrong I have no idea what java doesn't understand /cygwin/c syntax after I changed makefile it did java part but after that gcc 3.4.4 started to complain I set buffer length to 999 lines but I didn't get beginning of the story something wrong with my 1.4.2_09/include/jni.h gcc doesn't like it anyway I gave up thanks in advance Dmitry Markman -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060320/f8cbc57c/attachment-0003.html From tjarvi at qbang.org Mon Mar 20 22:36:48 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue Mar 28 20:17:31 2006 Subject: [Rxtx] binaries request In-Reply-To: <42702213-C222-4937-A585-7CFB17E47608@mac.com> References: <42702213-C222-4937-A585-7CFB17E47608@mac.com> Message-ID: On Tue, 21 Mar 2006, Dmitry Markman wrote: > Hi > can somebody send me latest linux and windows binaries, please? > > or where I can find them (I didn't find them in the latest tareball) > > I gave up with my cygwin: something wrong I have no idea what > java doesn't understand /cygwin/c syntax > after I changed makefile it did java part > but after that gcc 3.4.4 started to complain > I set buffer length to 999 lines but I didn't get beginning of the story > something wrong with my 1.4.2_09/include/jni.h gcc doesn't like it > anyway I gave up > > thanks in advance > Hi Dmitry The bins are here: ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7-bins-r2.zip Here are the files in the zip you want. Jar: rxtx-2.1-7-bins-r2/RXTXcomm.jar Windows: rxtx-2.1-7-bins-r2/Windows/i368-mingw32/rxtxSerial.dll Linux (x86) rxtx-2.1-7-bins-r2/Linux/i686-unknown-linux-gnu/librxtxSerial.so There are others in there including Parallel port support but those are the main ones for testing. -- Trent Jarvi tjarvi@qbang.org From dmarkman at mac.com Mon Mar 20 23:05:59 2006 From: dmarkman at mac.com (Dmitry Markman) Date: Tue Mar 28 20:17:31 2006 Subject: [Rxtx] binaries request In-Reply-To: References: <42702213-C222-4937-A585-7CFB17E47608@mac.com> Message-ID: thank you very much but windows's readme says: rxtxSerial.dll had to be recomopiled to link in missing native methods. should I ignore it? or what? thanks again also I understand that I should use mingw not cygwin I'll try to install mingw On Mar 21, 2006, at 12:36 AM, Trent Jarvi wrote: > On Tue, 21 Mar 2006, Dmitry Markman wrote: > >> Hi >> can somebody send me latest linux and windows binaries, please? >> >> or where I can find them (I didn't find them in the latest tareball) >> >> I gave up with my cygwin: something wrong I have no idea what >> java doesn't understand /cygwin/c syntax >> after I changed makefile it did java part >> but after that gcc 3.4.4 started to complain >> I set buffer length to 999 lines but I didn't get beginning of the >> story >> something wrong with my 1.4.2_09/include/jni.h gcc doesn't like it >> anyway I gave up >> >> thanks in advance >> > > Hi Dmitry > > The bins are here: > > ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7-bins-r2.zip > > Here are the files in the zip you want. > > Jar: > > rxtx-2.1-7-bins-r2/RXTXcomm.jar > > Windows: > > rxtx-2.1-7-bins-r2/Windows/i368-mingw32/rxtxSerial.dll > > Linux (x86) > > rxtx-2.1-7-bins-r2/Linux/i686-unknown-linux-gnu/librxtxSerial.so > > There are others in there including Parallel port support but those > are the main ones for testing. > > -- > Trent Jarvi > tjarvi@qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx@qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx Dmitry Markman From tjarvi at qbang.org Mon Mar 20 23:20:33 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue Mar 28 20:17:31 2006 Subject: [Rxtx] binaries request In-Reply-To: References: <42702213-C222-4937-A585-7CFB17E47608@mac.com> Message-ID: On Tue, 21 Mar 2006, Dmitry Markman wrote: > thank you very much > > but windows's readme says: > rxtxSerial.dll had to be recomopiled to link in missing native methods. > > should I ignore it? or what? > Hi Dmitry That dll should be OK. r2 is the recompile linked to the missing native method. The readme explains why it was recompiled; fuser.o was not linked into the dll in the first release. -- Trent Jarvi tjarvi@qbang.org From ariantristan at yahoo.com Mon Mar 20 23:55:24 2006 From: ariantristan at yahoo.com (Lambok Sianturi) Date: Tue Mar 28 20:17:31 2006 Subject: [Rxtx] jvm issue Message-ID: <20060321065524.94779.qmail@web50701.mail.yahoo.com> Hi All, This is my first time to join RxTx mailing list. I thank you all for allowing others to sign in in requests help. I use the latest RxTx lib in Fedora 3 with java version 1.4.2_09 b05. And I got this error: # # An unexpected error has been detected by HotSpot Virtual Machine: # # SIGSEGV (0xb) at pc=0x00bf27f3, pid=2633, tid=3086112448 # # Java VM: Java HotSpot(TM) Client VM (1.4.2_09-b05 mixed mode) # Problematic frame: # C [ld-linux.so.2+0xa7f3] # # An error report file with more information is saved as hs_err_pid2633.log # # If you would like to submit a bug report, please visit: # http://java.sun.com/webapps/bugreport/crash.jsp # ./run.sh: line 3: 2633 Aborted /usr/local/java/bin/java -Djava.library.path=/usr/local/java/jre/lib/ -Djsmsengine.debug=true -classpath jsmsengine.jar:smsgateway.jar:classes12.jar:RXTXcomm.jar:. com.api.sms.SMSServer What is the jvm depedency for the latest library? Can I use 1.4.2_09 b05? Thanks in advance. Arian --------------------------------- Yahoo! Mail Use Photomail to share photos without annoying attachments. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060320/83d58dd7/attachment-0003.html From f.frumento at ngi.it Tue Mar 21 00:21:47 2006 From: f.frumento at ngi.it (Fabio Frumento) Date: Tue Mar 28 20:17:31 2006 Subject: [Rxtx] Javadoc on the go Message-ID: <441FA98B.9050701@ngi.it> Hi Trent, sorry for the big delay but my job is running wild, i was out for some time but now i'm back and ready to continue the javadoc for Rxtx. Did you used the last javadoc patch i sent you ? let me know if i have to send it to you again or not. regards Fabio From lyon at docjava.com Tue Mar 21 00:51:18 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Tue Mar 28 20:17:31 2006 Subject: [Rxtx] lock files Message-ID: Hi All, You know, if the use of lock files were under Java control (rather than a build-time decision), it might enable a more unified binary distro. It might also facilitate quick prototyping of non-lock file approaches to resolving serial port contention issues (i.e., mac-like approaches vs. linux approaches, etc.). I realize that this is a radical overhaul of the lock file policy issue. Also, it may harm performance. On the other hand, our benchmarks on JNI overhead for modern processors indicate performance impact should be minimal. Perhaps it is more of an issue with the toybox systems. Suppose there were a class with a reasonable default...someone might write: SerialPortLockPolicy.setPolicy(SerialPortLockPolicy.UNIX_LOCK_FILE); SerialPortLockPolicy.setPolicy(SerialPortLockPolicy.NO_LOCK_CHECKING); SerialPortLockPolicy.setPolicy(SerialPortLockPolicy.MAC_STYLE); Thus, we could have a run-time reconfiguration of the serial port lock policy. A special NO_LOCK version of the binary would no longer be required. Any thoughts on this? Thanks! - Doug From joachim at buechse.de Tue Mar 21 03:09:09 2006 From: joachim at buechse.de (Joachim Buechse) Date: Tue Mar 28 20:17:31 2006 Subject: [Rxtx] lock files In-Reply-To: References: Message-ID: <8E12916A-1B9A-4FF2-B684-E2D1C794221B@buechse.de> This is pretty much what I thought about when I suggested, that the default behaviour could be overwritten with a property. I am very much in favor of this approach. In particular this allows much easier debugging for PC based java developers. I think big parts of the Java (and maybe some parts of the C code) could use a bit of a structural workover (unit tests, javadoc, synchronization, etc). Maybe there should be a CVS branch for this experimental version. I'd be happy to contribute a first workover for some of the Java code. Designing for testability and implementing a good bunch of unit tests has been a strategy that worked quite well in the Java projects I lead. And it ultimately allows more liberal change permission. Regards, Joachim On 21.03.2006, at 08:51, Dr. Douglas Lyon wrote: > Hi All, > You know, if the use of lock files were > under Java control (rather than a build-time decision), > it might enable a more unified binary distro. It might also > facilitate quick prototyping of non-lock file approaches > to resolving serial port contention issues (i.e., mac-like > approaches vs. linux approaches, etc.). > > I realize that this is a radical overhaul of the lock file policy > issue. Also, it may harm performance. On the other hand, > our benchmarks on JNI overhead for modern processors indicate > performance impact should be minimal. Perhaps it is more of > an issue with the toybox systems. > > Suppose there were a class with a reasonable default...someone > might write: > SerialPortLockPolicy.setPolicy(SerialPortLockPolicy.UNIX_LOCK_FILE); > SerialPortLockPolicy.setPolicy(SerialPortLockPolicy.NO_LOCK_CHECKING); > SerialPortLockPolicy.setPolicy(SerialPortLockPolicy.MAC_STYLE); > > Thus, we could have a run-time reconfiguration of the serial port lock > policy. A special NO_LOCK version of the binary would no longer > be required. > > Any thoughts on this? > > Thanks! > - Doug > _______________________________________________ > Rxtx mailing list > Rxtx@qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From joachim at buechse.de Tue Mar 21 06:23:08 2006 From: joachim at buechse.de (Joachim Buechse) Date: Tue Mar 28 20:17:31 2006 Subject: [Rxtx] PATCH: use of ioctl(fd, TIOCEXCL) instead of lockfiles Message-ID: <923AE774-EEA2-4911-92D8-32BB27802C8B@buechse.de> Here is the patch for the ioctl(fd, TIOCEXCL). I have verified this only for OSX 10.4.5, hence it is only defined for APPLE. However, it should work at least for Solaris as well. If a process has requested TIOEXCL further open calls by other user processes will fail. The patch also disables uucp style locking for APPLE. Obviously this is discussable. I think it is the way to go, as it eliminates creating the lock directory which doesnt exist on the standard installation and it eliminates messing with the system group definitions (adding users to group uucp). Regarding the possibility of root processes opening a device which is locked - I consider this a feature not a potential problem. It is highly unlikely, that somebody is crazy enough to run a JavaVM as root (unless he has no other means of getting a restricted IP port opened, ie doesnt understand ipfw). Anyway, even if the process runs as root, it fails when calling ioctl(fd, TIOCEXCL). It could however still open the port to listen for RING events. I.e. a fax server which needs to see incoming calls but otherwise doesnt want to block the port. So the only case where the proposed mechanism fails is, if an incorrectly implemented process running as root conflicts with a user process. I think this can be accepted. Regards, Joachim PS: If this patch is generally accepted, the installer and Mac doku should obviously be changed as well. Index: SerialImp.c =================================================================== RCS file: /usr/local/cvsroot/rxtx-devel/src/SerialImp.c,v retrieving revision 1.46.2.187 diff -u -r1.46.2.187 SerialImp.c --- SerialImp.c 29 Jan 2006 22:19:04 -0000 1.46.2.187 +++ SerialImp.c 21 Mar 2006 12:59:16 -0000 @@ -656,6 +656,25 @@ fd=OPEN (filename, O_RDWR | O_NOCTTY | O_NONBLOCK ); } while (fd < 0 && errno==EINTR); +#ifdef OPEN_EXCL + // Note that open() follows POSIX semantics: multiple open() calls to + // the same file will succeed unless the TIOCEXCL ioctl is issued. + // This will prevent additional opens except by root-owned processes. + // See tty(4) ("man 4 tty") and ioctl(2) ("man 2 ioctl") for details. + + if (fd >= 0 && (ioctl(fd, TIOCEXCL) == -1)) + { + sprintf( message, "open: exclusive access denied for % s\n", + filename ); + report( message ); + report_error( message ); + + close(fd); + goto fail; + } +#endif /* OPEN_EXCL */ + + if( configure_port( fd ) ) goto fail; (*env)->ReleaseStringUTFChars( env, jstr, filename ); sprintf( message, "open: fd returned is %i\n", fd ); Index: SerialImp.h =================================================================== RCS file: /usr/local/cvsroot/rxtx-devel/src/SerialImp.h,v retrieving revision 1.11.2.49 diff -u -r1.11.2.49 SerialImp.h --- SerialImp.h 5 Jul 2005 17:47:21 -0000 1.11.2.49 +++ SerialImp.h 21 Mar 2006 12:59:17 -0000 @@ -135,7 +135,8 @@ /*# define LOCKDIR "/var/spool/uucp"*/ # define LOCKDIR "/var/lock" # define LOCKFILEPREFIX "LK." -# define UUCP +/*# define UUCP*/ +# define OPEN_EXCL #endif /* __APPLE__ */ #if defined(__NetBSD__) # define DEVICEDIR "/dev/" From tjarvi at qbang.org Tue Mar 21 10:26:08 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue Mar 28 20:17:31 2006 Subject: [Rxtx] Javadoc on the go In-Reply-To: <441FA98B.9050701@ngi.it> References: <441FA98B.9050701@ngi.it> Message-ID: On Tue, 21 Mar 2006, Fabio Frumento wrote: > Hi Trent, > > sorry for the big delay but my job is running wild, i was out for some > time but now i'm back and ready to continue the javadoc for Rxtx. > > Did you used the last javadoc patch i sent you ? let me know if i have to > send it to you again or not. > > regards > > Fabio Hi Fabio The patch is in the rxtx mail-list archives. It will be going in soon. I did not see a time critical portion. I'll probably be going through the list since the last batch of patches this weekend and putting them into CVS. -- Trent Jarvi tjarvi@qbang.org From tjarvi at qbang.org Tue Mar 21 10:57:18 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue Mar 28 20:17:31 2006 Subject: [Rxtx] jvm issue In-Reply-To: <20060321065524.94779.qmail@web50701.mail.yahoo.com> References: <20060321065524.94779.qmail@web50701.mail.yahoo.com> Message-ID: On Mon, 20 Mar 2006, Lambok Sianturi wrote: > Hi All, > This is my first time to join RxTx mailing list. I thank you all for allowing others to sign in in requests help. > I use the latest RxTx lib in Fedora 3 with java version 1.4.2_09 b05. And I got this error: > > # > # An unexpected error has been detected by HotSpot Virtual Machine: > # > # SIGSEGV (0xb) at pc=0x00bf27f3, pid=2633, tid=3086112448 > # > # Java VM: Java HotSpot(TM) Client VM (1.4.2_09-b05 mixed mode) > # Problematic frame: > # C [ld-linux.so.2+0xa7f3] A native library loading error? What happens if you recompile rxtx on your system and install that? This sounds like an ABI problem? rxtx 2.1-7 was compiled with a gcc 2.96 toolchain as I recall. The hope is newer system will be backwards compatible. -- Trent Jarvi tjarvi@qbang.org From tjarvi at qbang.org Tue Mar 21 11:05:29 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue Mar 28 20:17:31 2006 Subject: [Rxtx] PATCH: use of ioctl(fd, TIOCEXCL) instead of lockfiles In-Reply-To: <923AE774-EEA2-4911-92D8-32BB27802C8B@buechse.de> References: <923AE774-EEA2-4911-92D8-32BB27802C8B@buechse.de> Message-ID: On Tue, 21 Mar 2006, Joachim Buechse wrote: > Here is the patch for the ioctl(fd, TIOCEXCL). I have verified this only > for OSX 10.4.5, hence it is only defined for APPLE. However, it should > work at least for Solaris as well. > > If a process has requested TIOEXCL further open calls by other user > processes will fail. > > The patch also disables uucp style locking for APPLE. Obviously this is > discussable. I think it is the way to go, as it eliminates creating the > lock directory which doesnt exist on the standard installation and it > eliminates messing with the system group definitions (adding users to > group uucp). > > Regarding the possibility of root processes opening a device which is > locked - I consider this a feature not a potential problem. It is highly > unlikely, that somebody is crazy enough to run a JavaVM as root (unless > he has no other means of getting a restricted IP port opened, ie doesnt > understand ipfw). Anyway, even if the process runs as root, it fails when > calling ioctl(fd, TIOCEXCL). It could however still open the port to > listen for RING events. I.e. a fax server which needs to see incoming > calls but otherwise doesnt want to block the port. So the only case where > the proposed mechanism fails is, if an incorrectly implemented process > running as root conflicts with a user process. I think this can be > accepted. > > Regards, > Joachim > > PS: If this patch is generally accepted, the installer and Mac doku > should obviously be changed as well. > > > Index: SerialImp.c > =================================================================== > RCS file: /usr/local/cvsroot/rxtx-devel/src/SerialImp.c,v > retrieving revision 1.46.2.187 > diff -u -r1.46.2.187 SerialImp.c > --- SerialImp.c 29 Jan 2006 22:19:04 -0000 1.46.2.187 > +++ SerialImp.c 21 Mar 2006 12:59:16 -0000 > @@ -656,6 +656,25 @@ > fd=OPEN (filename, O_RDWR | O_NOCTTY | O_NONBLOCK ); > } while (fd < 0 && errno==EINTR); > > +#ifdef OPEN_EXCL > + // Note that open() follows POSIX semantics: multiple open() > calls to > + // the same file will succeed unless the TIOCEXCL ioctl is > issued. > + // This will prevent additional opens except by root-owned > processes. > + // See tty(4) ("man 4 tty") and ioctl(2) ("man 2 ioctl") for > details. > + > + if (fd >= 0 && (ioctl(fd, TIOCEXCL) == -1)) > + { > + sprintf( message, "open: exclusive access denied for % > s\n", > + filename ); > + report( message ); > + report_error( message ); > + > + close(fd); > + goto fail; > + } > +#endif /* OPEN_EXCL */ > + > + > if( configure_port( fd ) ) goto fail; > (*env)->ReleaseStringUTFChars( env, jstr, filename ); > sprintf( message, "open: fd returned is %i\n", fd ); > Index: SerialImp.h > =================================================================== > RCS file: /usr/local/cvsroot/rxtx-devel/src/SerialImp.h,v > retrieving revision 1.11.2.49 > diff -u -r1.11.2.49 SerialImp.h > --- SerialImp.h 5 Jul 2005 17:47:21 -0000 1.11.2.49 > +++ SerialImp.h 21 Mar 2006 12:59:17 -0000 > @@ -135,7 +135,8 @@ > /*# define LOCKDIR "/var/spool/uucp"*/ > # define LOCKDIR "/var/lock" > # define LOCKFILEPREFIX "LK." > -# define UUCP > +/*# define UUCP*/ > +# define OPEN_EXCL > #endif /* __APPLE__ */ > #if defined(__NetBSD__) > # define DEVICEDIR "/dev/" > This looks like a good start. What do you think Dmitry? Perhaps all systems with TIOCEXCL defined should use that though. Even if they use lockfiles. It wont hurt anything. That would catch people hacking their own serial apps without checking lockfiles. Its a good idea to avoid C++ style comments in the C portions. Some older systems don't deal with them well. If it's just for Mac OS X, it isn't a big deal. I think it was the Irix compiler that was problematic? -- Trent Jarvi tjarvi@qbang.org From tjarvi at qbang.org Tue Mar 21 11:22:05 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue Mar 28 20:17:31 2006 Subject: [Rxtx] lock files In-Reply-To: <8E12916A-1B9A-4FF2-B684-E2D1C794221B@buechse.de> References: <8E12916A-1B9A-4FF2-B684-E2D1C794221B@buechse.de> Message-ID: We can try it. Maybe the JNI is much improved. The nice thing about linking into liblock is distros then worry about lockfiles on their systems. This way, we have to deal with any changes that may show up. On Tue, 21 Mar 2006, Joachim Buechse wrote: > This is pretty much what I thought about when I suggested, that the > default behaviour could be overwritten with a property. I am very much in > favor of this approach. In particular this allows much easier debugging > for PC based java developers. > > I think big parts of the Java (and maybe some parts of the C code) could > use a bit of a structural workover (unit tests, javadoc, synchronization, > etc). Maybe there should be a CVS branch for this experimental version. > I'd be happy to contribute a first workover for some of the Java code. > Designing for testability and implementing a good bunch of unit tests has > been a strategy that worked quite well in the Java projects I lead. And > it ultimately allows more liberal change permission. > > Regards, > Joachim > > > On 21.03.2006, at 08:51, Dr. Douglas Lyon wrote: > >> Hi All, >> You know, if the use of lock files were >> under Java control (rather than a build-time decision), >> it might enable a more unified binary distro. It might also >> facilitate quick prototyping of non-lock file approaches >> to resolving serial port contention issues (i.e., mac-like >> approaches vs. linux approaches, etc.). >> >> I realize that this is a radical overhaul of the lock file policy >> issue. Also, it may harm performance. On the other hand, >> our benchmarks on JNI overhead for modern processors indicate >> performance impact should be minimal. Perhaps it is more of >> an issue with the toybox systems. >> >> Suppose there were a class with a reasonable default...someone >> might write: >> SerialPortLockPolicy.setPolicy(SerialPortLockPolicy.UNIX_LOCK_FILE); >> SerialPortLockPolicy.setPolicy(SerialPortLockPolicy.NO_LOCK_CHECKING); >> SerialPortLockPolicy.setPolicy(SerialPortLockPolicy.MAC_STYLE); >> >> Thus, we could have a run-time reconfiguration of the serial port lock >> policy. A special NO_LOCK version of the binary would no longer >> be required. >> >> Any thoughts on this? >> >> Thanks! >> - Doug >> _______________________________________________ >> Rxtx mailing list >> Rxtx@qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx@qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From dmarkman at mac.com Tue Mar 21 16:05:17 2006 From: dmarkman at mac.com (Dmitry Markman) Date: Tue Mar 28 20:17:31 2006 Subject: [Rxtx] PATCH: use of ioctl(fd, TIOCEXCL) instead of lockfiles In-Reply-To: References: <923AE774-EEA2-4911-92D8-32BB27802C8B@buechse.de> Message-ID: <512AC70C-BB86-48F2-A83C-023F35C23BAB@mac.com> I think it's cool, but I'd like to have that property implementation when user can choose between locking mechanism about comments: it's easy to change comments to the C style or we can use extensions of the file to cpp so c++ compiler will be used On Mar 21, 2006, at 1:05 PM, Trent Jarvi wrote: > This looks like a good start. What do you think Dmitry? Perhaps > all systems with TIOCEXCL defined should use that though. Even if > they use lockfiles. It wont hurt anything. That would catch > people hacking their own serial apps without checking lockfiles. > > Its a good idea to avoid C++ style comments in the C portions. > Some older systems don't deal with them well. If it's just for Mac > OS X, it isn't a big deal. I think it was the Irix compiler that > was problematic? Dmitry Markman From dmarkman at mac.com Tue Mar 21 16:13:00 2006 From: dmarkman at mac.com (Dmitry Markman) Date: Tue Mar 28 20:17:31 2006 Subject: [Rxtx] PATCH: use of ioctl(fd, TIOCEXCL) instead of lockfiles In-Reply-To: References: <923AE774-EEA2-4911-92D8-32BB27802C8B@buechse.de> Message-ID: I'd like to add that creating locking folder isn't a big deal we never had a problem related to the lock folders, because we always used installer on mac os x from other hand I'm not very much familiar with iotcl locking approach and I'm not sure it's more efficient Joachim wrote "I think it is the way to go, as it eliminates creating the lock directory which doesnt exist on the standard installation and it eliminates messing with the system group definitions (adding users to group uucp)." but I really didn't have any problem with that 1. doesn't exist on the standard installation there are many-many things that don't exist in the standard installation so I don't think that argument is strong enough 2. messing with the system group definitions I don't think we're messing with the group definition mac os x provides very clear way to set up group's members and together with Greg Guerin AuthKit there is no problem to set those definitions so I don't think that argument is strong either but from other hand using iotcl is more promising and is more elegant On Mar 21, 2006, at 1:05 PM, Trent Jarvi wrote: > > This looks like a good start. What do you think Dmitry? Perhaps > all systems with TIOCEXCL defined should use that though. Even if > they use lockfiles. It wont hurt anything. That would catch > people hacking their own serial apps without checking lockfiles. Dmitry Markman From joachim at buechse.de Wed Mar 22 04:46:45 2006 From: joachim at buechse.de (Joachim Buechse) Date: Tue Mar 28 20:17:31 2006 Subject: [Rxtx] PATCH: use of ioctl(fd, TIOCEXCL) instead of lockfiles In-Reply-To: References: <923AE774-EEA2-4911-92D8-32BB27802C8B@buechse.de> Message-ID: Sorry, I was not very clear with my arguments, so I will try again;-) Please, don't take this as an attack against work that has been done. I think the contributions that have been made in the past were made in a good spirit. But I really believe, that the current solution for OSX has many shortcomings and should be changed as soon as possible. lock files --- The /var/lock folder does not exist on the standard OSX installation, however the standard installation includes several applications that use serial ports (i.e. the FAX capability). This indicates, that the lock folder approach will not work well with system components. Applications for OSX will generally try to live in harmony with system components (except for HP print drivers of course). I think RXTX should follow this approach as well. uucp group --- Accessing serial ports is not an admin privileged operation on OSX. Any user (world) has read/write privileges on /dev/tty*. So the system default is to not enforce any group membership to access these ports. The group uucp however is a system group on all unix systems I know. It exists for certain system processes. A non admin user should in general not be a member of this group. Quite arguably no user should ever be a member of this group. Installer --- My general opinion is, that - no Installer should touch user or group data without warning - no Application Installer should touch groups which are not specific to the very application installed - no Installer should ever add regular users to a system group The current installer injects the installing user in the group uucp without warning about this change and without giving the option to "opt out" of this change. This is a potential security risk (but not currently a real one, as OSX contains no folders belonging to group uucp). The current installer does not work for multi user systems. It puts the installing user in the uucp group. However the installing user is not necessarily the user that will use the application. Putting all users that may use a serial port application in the system group uucp seems like a very invasive approach to me. Besides that, newly created users will not automatically be in the group and hence, serial applications will "break" for new users without obvious reasons. Avoiding the lock files will allow self contained applications (i.e. drag&drop installation). In my eyes this is largely preferable over an installer that requests admin privileges. Adding up all these points indicates very strongly, that the lock-file implementation is not the way to go on OSX. Regards, Joachim On 22.03.2006, at 00:13, Dmitry Markman wrote: > I'd like to add that > > creating locking folder isn't a big deal > we never had a problem related to the lock folders, because we > always used installer on mac os x > from other hand I'm not very much familiar with iotcl locking > approach and I'm not sure it's more efficient > > Joachim wrote "I think it is the way to go, as it eliminates > creating the lock directory which doesnt exist on the standard > installation and it eliminates messing with the system group > definitions (adding users to group uucp)." but I really didn't have > any problem with that > > 1. doesn't exist on the standard installation > there are many-many things that don't exist in the standard > installation so I don't think that argument is strong enough > 2. messing with the system group definitions > I don't think we're messing with the group definition > mac os x provides very clear way to set up group's members and > together with Greg Guerin AuthKit there is no problem to set those > definitions > so I don't think that argument is strong either > but from other hand using iotcl is more promising and is more elegant > > > > On Mar 21, 2006, at 1:05 PM, Trent Jarvi wrote: > >> >> This looks like a good start. What do you think Dmitry? Perhaps >> all systems with TIOCEXCL defined should use that though. Even if >> they use lockfiles. It wont hurt anything. That would catch >> people hacking their own serial apps without checking lockfiles. > > Dmitry Markman > > _______________________________________________ > Rxtx mailing list > Rxtx@qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From dmarkman at mac.com Wed Mar 22 05:27:13 2006 From: dmarkman at mac.com (Dmitry Markman) Date: Tue Mar 28 20:17:31 2006 Subject: [Rxtx] PATCH: use of ioctl(fd, TIOCEXCL) instead of lockfiles In-Reply-To: References: <923AE774-EEA2-4911-92D8-32BB27802C8B@buechse.de> Message-ID: <83440CF3-DCD8-41C1-B941-F227232C27E3@mac.com> thanks for the very good explanation I didn't think that you were attacking any thing, so don't worry I just had feeling, that there were more aesthetic reasons for going to ioctl then real necessity now you explained everything quite well (BTW, asfar as I remember installer asks admin password so it wasn't quiet, but it really doesn't matter now) thanks On Mar 22, 2006, at 6:46 AM, Joachim Buechse wrote: > Sorry, I was not very clear with my arguments, so I will try again;-) > > Please, don't take this as an attack against work that has been > done. I think the contributions that have been made in the past > were made in a good spirit. But I really believe, that the current > solution for OSX has many shortcomings and should be changed as > soon as possible. > > lock files > --- > The /var/lock folder does not exist on the standard OSX > installation, however the standard installation includes several > applications that use serial ports (i.e. the FAX capability). This > indicates, that the lock folder approach will not work well with > system components. Applications for OSX will generally try to live > in harmony with system components (except for HP print drivers of > course). I think RXTX should follow this approach as well. > > uucp group > --- > Accessing serial ports is not an admin privileged operation on OSX. > Any user (world) has read/write privileges on /dev/tty*. So the > system default is to not enforce any group membership to access > these ports. The group uucp however is a system group on all unix > systems I know. It exists for certain system processes. A non admin > user should in general not be a member of this group. Quite > arguably no user should ever be a member of this group. > > Installer > --- > My general opinion is, that > - no Installer should touch user or group data without warning > - no Application Installer should touch groups which are not > specific to the very application installed > - no Installer should ever add regular users to a system group > > The current installer injects the installing user in the group uucp > without warning about this change and without giving the option to > "opt out" of this change. This is a potential security risk (but > not currently a real one, as OSX contains no folders belonging to > group uucp). > > The current installer does not work for multi user systems. It puts > the installing user in the uucp group. However the installing user > is not necessarily the user that will use the application. Putting > all users that may use a serial port application in the system > group uucp seems like a very invasive approach to me. Besides that, > newly created users will not automatically be in the group and > hence, serial applications will "break" for new users without > obvious reasons. > > > Avoiding the lock files will allow self contained applications > (i.e. drag&drop installation). In my eyes this is largely > preferable over an installer that requests admin privileges. Adding > up all these points indicates very strongly, that the lock-file > implementation is not the way to go on OSX. > > Regards, > Joachim > > > On 22.03.2006, at 00:13, Dmitry Markman wrote: > >> I'd like to add that >> >> creating locking folder isn't a big deal >> we never had a problem related to the lock folders, because we >> always used installer on mac os x >> from other hand I'm not very much familiar with iotcl locking >> approach and I'm not sure it's more efficient >> >> Joachim wrote "I think it is the way to go, as it eliminates >> creating the lock directory which doesnt exist on the standard >> installation and it eliminates messing with the system group >> definitions (adding users to group uucp)." but I really didn't >> have any problem with that >> >> 1. doesn't exist on the standard installation >> there are many-many things that don't exist in the standard >> installation so I don't think that argument is strong enough >> 2. messing with the system group definitions >> I don't think we're messing with the group definition >> mac os x provides very clear way to set up group's members and >> together with Greg Guerin AuthKit there is no problem to set those >> definitions >> so I don't think that argument is strong either >> but from other hand using iotcl is more promising and is more elegant >> >> >> >> On Mar 21, 2006, at 1:05 PM, Trent Jarvi wrote: >> >>> >>> This looks like a good start. What do you think Dmitry? Perhaps >>> all systems with TIOCEXCL defined should use that though. Even >>> if they use lockfiles. It wont hurt anything. That would catch >>> people hacking their own serial apps without checking lockfiles. >> >> Dmitry Markman >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx@qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx@qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx Dmitry Markman From lyon at docjava.com Wed Mar 22 06:12:18 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Tue Mar 28 20:17:31 2006 Subject: [Rxtx] sole of a new design pattern Message-ID: Hi All, I have been thinking about how we design the serial port software. I think we need a new design pattern. For lack of a better term, I shall call it: The Parametric Singleton Design Pattern By Douglas A. Lyon ABSTRACT The goal of the singleton design pattern is to make sure that there is one, and only one, instance of a given class. The goal of the parametric singleton design pattern is to make sure that there is one, and only one, instance of a given class with the given parametric values. We parametric singleton design pattern combines the singleton design pattern with a parameter that enables unique creation of instances of a class. These instances are cached. When a user asks for an instance with these parameters, the cache is checked. If the instance is in the cache, the instance is returned, otherwise it is created, added to the cache and then returned. We apply our parametric singleton design pattern to the retrieval of RMI registries bound to a given port. The goal of our system is to make sure that no two RMI registries are listening to the same socket and to make use of the RMI registries after they have been created. RMI registries are used in distributed computation. Introduction The singleton design pattern is meant to ensure that on a single instance of a class exists. It is also meant to provide a global point of access to it. The intent of the parametric singleton design pattern is to ensure that a class has only one instance for a given set of parameter values. It also provides a global point of access to it. Motivation A system cannot tolerate multiple instances of some classes with identical parameters. For example, you cannot have two instances making use of the same serial port, at the same time. You cannot have two instances that are trying to listen to the same socket connection. You cannot have two instances writing to the same file structure at the same time. As the operating system is often thought of as the arbiter of consumed resources (i.e., tape drives, serial ports, etc.) we frequently leave it to an operating system implementation to resolve these contention issues. Even for similar resources (like serial ports) there are few standards for handling contention. For example, serial ports on Linux are locked using a "/var/lock" file. POSIX, on the other hand, uses ioctl mechanisms to prevent contention. A better solution is to make a class that is responsible for keeping track of the instances created from the class. The class is declared final, so that it cannot be subclassed. The class also has a private constructor, so that other classes cannot instance it. The new design pattern is called the parametric singleton design pattern and it provides a way to access and create instances with given parameters. Applicability Use the Parametric Singleton Design Pattern when: 1. There must be exactly one instance of a class with the given parameters. 2. The instances must be accessible to clients from a well-known access point. Structure Insert UML diagram here. Participants The Parametric Singleton Clients that need instances 1. The Parametric Singleton defines an instance upon request from a client, if, and only if, the instance does not already exist. 2. The Parametric Singleton returns the instance to the client. 3. The Parametric Singleton is responsible for creating unique instances from given parameters. Collaborations Clients obtain a reference to a Parametric Singleton instance only through the parametric singleton design pattern. If the instance is left in an improper state (e.g., the serial port was left open) it is NOT the role of the Parametric Singleton Design Pattern to close the IO port. Nor is it the role of the Parametric Singleton Design Pattern to open the port. That role is delegate to some other part of the system. Further, it is not the role of the Parametric Singleton Design Pattern to check out resources. That is, multiple threads can have multiple references to the same resource at the same time. MUTEX locking is delegated to some other part of the system. Consequences The Parametric Singleton Design Pattern has several benefits: 1. Controlled access to parametrically defined instances. Since the Parametric Singleton class encapsulates its instances, there is control over how and when clients access it. 2. Reduced name space. The Parametric Singleton pattern avoids global variables that store instances created from the same parameter. Implementation Here are implementation issues to consider when using the Parametric Singleton pattern: 1. Unique mapping of parameters. The Parametric Singleton pattern requires that there be a mean to isomorphically map the parameter space into the instance space and back again. 2. Ensure unique instances. The Parametric Singleton pattern makes unique instances from parameters, and it does so only once. 3. Cache instances for fast retrieval. The Parametric Singleton pattern must be able to look up instances, given some set of parameters, and do so from some data structure. That is, there must be enough space to hold references to all the instances the program will need. Also, a mechanism is needed to look up and retrieve the instances quickly enough to satisfy the clients. Sample Code public final class ParametricSingletonRmiRegistry { private static Hashtable registry = new Hashtable(100); // use singleton pattern and??????????????????????????????????????????????? // prevent instantiation of RmiRegistryUtils.?????????????????????????????? private ParametricSingletonRmiRegistry() { } // the only instance of the Registry held by the RmiRegistryUtils?????????? public static void listNames(Integer port) { if (!isInCacheAndRunning(port)) return; Registry r = (Registry) registry.get(port); System.out.println("registry on port: " + port); System.out.println("registry: " + r); System.out.println("names: "); try { print(r.list()); } catch (RemoteException e) { In.message(e); } System.out.println("------------------------"); } /**???????????????????????????????????????????????????????????????????????? * Checks whether a Registry has been started on this host????????????????? * in the specified port.?????????????????????????????????????????????????? * If not, it tries to start one.?????????????????????????????????????????? * when it fails to start a Registry, it exits the program????????????????? * with exit code 1.??????????????????????????????????????????????????????? */ public static void restart(int port) { if (isInCacheAndRunning(port)) return; try { startRegistry(port); } catch (RemoteException e) { In.message(e); } } /**???????????????????????????????????????????????????????????????????????? * @param port????????????????????????????????????????????????????????????? * @return true if registry is in cache and running???????????????????????? */ private static boolean isInCacheAndRunning(Integer port) { if (!isRegistryRunning(port.intValue())) return false; if (!isRegistryInCache(port.intValue())) return false; return true; } /**???????????????????????????????????????????????????????????????????????? * @param port????????????????????????????????????????????????????????????? * @return true if we are able to locate a local registry on port.??????????????????????????????????????????????????????????????????????????? */ private static boolean isRegistryRunning(int port) { try { Registry r = LocateRegistry.getRegistry(port); if (r != null) return true; } catch (RemoteException e) { return false; } return false; } /**???????????????????????????????????????????????????????????????????????? * @param port????????????????????????????????????????????????????????????? * @return return true if registry is in cache????????????????????????????? */ private static boolean isRegistryInCache(int port) { if (registry.get(new Integer(port)) == null) return false; return true; } /**???????????????????????????????????????????????????????????????????????? * Restart the registry, if needed.???????????????????????????????????????? * Return the only instance of the registry for consistent global?????????? * using by making use of the Singleton Design Pattern????????????????????? *????????????????????????????????????????????????????????????????????????? * @return the internally held registry instance.?????????????????????????? */ public static Registry getRegistry(Integer port) { restart(port); return (Registry) registry.get(port); } private static void startRegistry(Integer port) throws RemoteException { Registry r; try { r = LocateRegistry.createRegistry(port.intValue()); registry.put(port, r); //r = new sun.rmi.registry.RegistryImpl???????????????????????????? /// (port.intValue());?????????????????????????????????????? // registry.put(port, r);?????????????????????????????????????????? } catch (Exception e) { //e.printStackTrace();????????????????????????????????????????????? r = LocateRegistry.getRegistry(port.intValue()); registry.put(port, r); } } public static void main(String args[]) throws RemoteException { //restart(port);??????????????????????????????????????????????????????? restart(5001); restart(5002); restart(5002); Registry r = LocateRegistry.getRegistry(5002); System.out.println("registry="+r); } } I would very much like to get your feedback on this new design pattern idea. Thank you for your time. Regards, - Doug From david.garnier at trusted-logic.com Wed Mar 22 07:36:10 2006 From: david.garnier at trusted-logic.com (David Garnier) Date: Tue Mar 28 20:17:31 2006 Subject: [Rxtx] sole of a new design pattern In-Reply-To: References: Message-ID: <442160DA.80107@trusted-logic.com> Hello, > The Parametric Singleton Design Pattern The Singleton is the most abused design pattern ever. Good use-cases for this pattern are extremely rare and mostly confined to problems related to hardware resources, like serial ports. > Applicability > > Use the Parametric Singleton Design Pattern when: > 1. There must be exactly one instance of a class with the given > parameters. OK. As I said above, this case this actually very unusual. The Singleton pattern is mostly used when : > 2. The instances must be accessible to clients from a well-known > access point. Using the singleton pattern in this case is just convenient for the programmer. Problems arises pretty quickly, especially if you attempt to unit-test your classes. 1) If your singleton is stateful, or hold on to stateful objects, it means that two different unit tests are not actually independent. Instead of starting with a brand new environment, the result of a test may be affected by the result of a previous test. This problem also arise when with your class relies on a database. In both cases, the solution is to reset your "unique" resource (Singleton or database) at the beginning of the test, which is a pain. Also, while most projects connect to a single database, projects that allow the use of Singletons usually contain several of thems, and new ones may cropped up unnoticed. You quickly end up with test cases that only pass in a certain order, which is a royal pain. 2) You cannot mockup a singleton. Once everyone calls the SomeSingleton class statically, you can't replace your class by SomeSingletonMockup. Furthermore, even for hardware services, the Singleton pattern does not really prevent concurrent accesses. If you start the same program in two different JVMs, unless they somehow shared the state of their "Singletons" (through lock files for example), the Singleton pattern will not prevent concurrent access. Our application uses RXTX, and we routinely encounter cases where another (native) application has already locked the port. Since we cannot modify the native application to recognize lock files, OS-level control is irreplaceable. > > Consequences > The Parametric Singleton Design Pattern has several benefits: > > 1. Controlled access to parametrically defined instances. Since > the Parametric Singleton class encapsulates its instances, there is > control over how and when clients access it. Not really. Once you've returned the instance to a client, you've lost control over it. The client can to whatever it wants with it. You cannot "recall" the instance or claim it back. > 2. Reduced name space. The Parametric Singleton pattern avoids > global variables that store instances created from the same parameter. Sure, but you don't have to rely on a Singleton for that. Just create a single Factory. > I would very much like to get your feedback on this new design > pattern idea. Well, it's nothing new. Some may say that it is the point of design patterns: formalizes the designs that occur again and again. However, this design is simply a combination of the Singleton and Factory patterns. I did use it in the past, but now I've been exposed to the shortcomings of the Singleton pattern, so I limit myself to Factories. Regards, David From sean_montgomery at baseview.com Wed Mar 22 08:35:28 2006 From: sean_montgomery at baseview.com (Sean Montgomery) Date: Tue Mar 28 20:17:31 2006 Subject: [Rxtx] sole of a new design pattern In-Reply-To: <442160DA.80107@trusted-logic.com> References: <442160DA.80107@trusted-logic.com> Message-ID: <05769CA7-A51B-4CF0-BAA0-E02DD905F5A4@baseview.com> On Mar 22, 2006, at 9:36 AM, David Garnier wrote: > Furthermore, even for hardware services, the Singleton pattern does > not really prevent concurrent > accesses. If you start the same program in two different JVMs, > unless they somehow shared the state > of their "Singletons" (through lock files for example), the > Singleton pattern will not prevent > concurrent access. > Multiple class loaders in a single JVM can be tricky, too. Then there's synchronization, lazy initialization and serialization of singletons to contend with. Bloch's Effective Java covers these, and here's a few articles: http://www.javaworld.com/javaworld/jw-04-2003/jw-0425-designpatterns- p3.html http://java.sun.com/developer/technicalArticles/Programming/singletons/ Just FYI :-) From lyon at docjava.com Wed Mar 22 08:50:48 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Tue Mar 28 20:17:32 2006 Subject: [Rxtx] sole of a new design pattern In-Reply-To: <442160DA.80107@trusted-logic.com> References: <442160DA.80107@trusted-logic.com> Message-ID: Hi All, First, I would like to thank David for his prompt and thoughtful remarks. I had no idea people that feel strongly about a design patterns! Wow! Feedback (particularly critical feedback) is greatly appreciated. Starting at the end, first: >I did use it in >the past, but now I've been exposed to the shortcomings of the >Singleton pattern, so I limit myself to Factories. David, if I understood your comments correctly, you suggested that Factories can be used in leu of the Singleton Design Pattern, or even the Parametric Singleton Design Pattern. As I see in [Gof]: Factory Method: Intent "Define an interface for creating an object, but let subclasses decide which class to instantiate. Factory Method lets a class defer instantiation to subclasses." The Singleton Design Pattern is a concrete class, which is rather different, right? Also, subclasses are not permitted with Singleton, as they are final. Naturally, I could use an abstract factory as a parent for a singleton. I could even design a facade that could be implemented with the singleton....but that is not the intention of the design. Unless you want a mock-up, as discussed, below: More below: >Hello, > >> The Parametric Singleton Design Pattern > >The Singleton is the most abused design pattern ever. Good use-cases >for this pattern are extremely >rare and mostly confined to problems related to hardware resources, >like serial ports. > > >> Applicability >> >> Use the Parametric Singleton Design Pattern when: >> 1. There must be exactly one instance of a class with the given >> parameters. >OK. As I said above, this case this actually very unusual. The >Singleton pattern is mostly used when : >> 2. The instances must be accessible to clients from a well-known >> access point. > >Using the singleton pattern in this case is just convenient for the >programmer. Problems arises >pretty quickly, especially if you attempt to unit-test your classes. > >1) If your singleton is stateful, or hold on to stateful objects, it >means that two different unit >tests are not actually independent. Instead of starting with a brand >new environment, the result of >a test may be affected by the result of a previous test. This >problem also arise when with your >class relies on a database. In both cases, the solution is to reset >your "unique" resource >(Singleton or database) at the beginning of the test, which is a >pain. Also, while most projects >connect to a single database, projects that allow the use of >Singletons usually contain several of >thems, and new ones may cropped up unnoticed. You quickly end up >with test cases that only pass in a >certain order, which is a royal pain. There are basic problems with communicating finite state machines that include reachability and deadlock analysis. These are addressed with petri net analysis and are beyond the scope of the design pattern. As you quite rightly pointed out; the parametric singleton pattern (or the singleton pattern, for that matter) enable multiple threads to gain access to the same instance. The only way that I can see to block others from gaining access to the reference is the synchronize keyword. This is putting a spin-lock (or MUTEX) on the reference. The question of how to unit-test a design pattern like the parametric singleton remains open. Perhaps this is a deficiency. > >2) You cannot mockup a singleton. Once everyone calls the >SomeSingleton class statically, you can't >replace your class by SomeSingletonMockup. Acutally, I am not sure that this is true. If the Singleton implements a Facade interface, it should be possible to make the replacement. Right? > >Furthermore, even for hardware services, the Singleton pattern does >not really prevent concurrent >accesses. If you start the same program in two different JVMs, >unless they somehow shared the state >of their "Singletons" (through lock files for example), the >Singleton pattern will not prevent >concurrent access. Good Point!! You have sharp eyes! The singleton design pattern should/could take responsibility for this. In fact, you may notice that my code does have an implementation (LocateRegistry) that can work across JVM's. The LocateRegistry will even work across the Internet! LocateRegistry takes both a host name and a Port (lock files just don't do this). I did not think to implement this beyond the local machine, but, in its present form, it will work across different processes. > >Our application uses RXTX, and we routinely encounter cases where >another (native) application has >already locked the port. Since we cannot modify the native >application to recognize lock files, >OS-level control is irreplaceable. The singleton design pattern is not meant to replace OS-level control, but to centralize the Java programmers access to it. If lock files, for example, are used for serial ports, the Singleton Design Pattern should be able to work with them. > > >> >> Consequences >> The Parametric Singleton Design Pattern has several benefits: >> > > 1. Controlled access to parametrically defined instances. Since >> the Parametric Singleton class encapsulates its instances, there is >> control over how and when clients access it. > >Not really. Once you've returned the instance to a client, you've >lost control over it. The client >can to whatever it wants with it. You cannot "recall" the instance >or claim it back. Good point, this should read: > 1. Controll when parametrically defined instances are created. Since > > the Parametric Singleton class encapsulates its instances, there is > > control over how and when they are instanced. > >> 2. Reduced name space. The Parametric Singleton pattern avoids >> global variables that store instances created from the same parameter. > >Sure, but you don't have to rely on a Singleton for that. Just >create a single Factory. > > Thank you for your thoughtful and prompt response! Regards, - Doug From dmarkman at mac.com Wed Mar 22 21:21:55 2006 From: dmarkman at mac.com (Dmitry Markman) Date: Tue Mar 28 20:17:32 2006 Subject: [Rxtx] sole of a new design pattern In-Reply-To: <442160DA.80107@trusted-logic.com> References: <442160DA.80107@trusted-logic.com> Message-ID: I don't think I get it On Mar 22, 2006, at 9:36 AM, David Garnier wrote: > Using the singleton pattern in this case is just convenient for the > programmer. Problems arises > pretty quickly, especially if you attempt to unit-test your classes. so you're saying that something isn't so good because you can not test it in the convenient way? if that's true, I'm totally disagree change your test, debug whatever, but if software is efficient at runtime, works fine and only problem is some unit test (which is some kind of framework for testing) then dump that unit test , dump that unit framework and make something appropriate to the software you're testing so if Douglas want to use singletons, what's the problem? and what do you mean by abusing of singleton usage? of course singleton doesn't prevent concurrent access to the resource across the processes unless you're using some OS facility to prevent it, besides singleton as it was introduced is relevant only and only inside of the same process otherwise it's not singleton it's something else (let's say network singleton: so you have remote invocation facility and some factory method that return object created by that facility) I don't have any problem with using any kind of singletons. Parametric Singleton idea (if I understand it right) could be easily implemented in the following way: use a map populate map with instances of some class and key is your parameter (you can use lazy population too) if somebody ask the key check the value if it's null so resource is taken if somebody returns the resource put it back to the map public synchronized static Object getSomeResource(Object parameter); public synchronized static void returnResource(Object parameter); getSomeResource (inside of the same process) could return null in 2 cases 1. if somebody (from other thread for example) already took that resource 2. if OS API said that resource corresponded to that parameter (serial port with parameter = 1 (port #)) is locked and unavailable; I'm not sure that in case of serial ports we even need those Parametric Singletons (unless lock checking is a very expensive operation) just ask the OS about availability of that resource and if it's available give it away and then OS will lock it and therefore in next time somebody ask it just answer that resource is locked and return null for example system has 2 serial ports available so I ask getResource("tty"); or I ask getResource("Bluetooth-Modem"); and if OS is ok you can give tty or Bluetooth-Modem or both no need for any additional pattern I think back to the problem mac os x doesn't recognize locking via files, so it handles locking via some API an instance of the singleton in each process should recognize that resource is locked (by using that API) that's all we don't have to make things more complicate then they are just because there is some nice design pattern or nice unit test framework or whatever keep things simple, make them work fast, don't introduce middle layers unless you have really good reason to do so of course I could be entirely wrong, so sorry about that in advance thanks Dmitry Markman From tjarvi at qbang.org Wed Mar 22 22:31:41 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue Mar 28 20:17:32 2006 Subject: [Rxtx] sole of a new design pattern In-Reply-To: References: Message-ID: Hi Doug Interesting reading. So far I'm just reading and thinking. I have one question so far. " Clients obtain a reference to a Parametric Singleton instance only through the parametric singleton design pattern. If the instance is left in an improper state (e.g., the serial port was left open) it is NOT the role of the Parametric Singleton Design Pattern to close the IO port. Nor is it the role of the Parametric Singleton Design Pattern to open the port. That role is delegate to some other part of the system. " So when the clients obtain a reference to the singleton, can they assume the port is there? IE, would it be the singletons role to handle things like USB dongles being removed with event hints comming from the underlying OS. Hardware abstraction layer/HAL on Linux is an example of underlying OS events. I assume that role too is delegated to other parts of the system? -- Trent Jarvi tjarvi@qbang.org From lyon at docjava.com Thu Mar 23 08:10:33 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Tue Mar 28 20:17:32 2006 Subject: [Rxtx] Classes don't need goals, they need roles! In-Reply-To: References: Message-ID: Hi Trent, Yes, I think that the role of the Parametric Singleton Pattern is not to open or close serial ports, nor is it to perform error checking. On the other hand, if you were to combine the role of the Parametric Singleton Pattern with another role (like that of error checking) it might not be amiss. However, I generally caution programmers against adding multiple roles to classes, as this leads to monolithic designs. Thus a different class (NativeLibDetect) could have the role of determining if the native library can be loaded. Another class (SerialPortBean) can have the role of serializing the default state of the serial port, so that it can be recovered, from user preferences, at a later time. The SerialPortDetect could have the role of determining if the serial port is removed (i.e., a USB port was unplugged). My guess is that each class should have a different role in the system, in order to ease maintenance and testing...but I could be wrong about that. Thanks! - Doug >Hi Doug > >Interesting reading. So far I'm just reading and thinking. I have >one question so far. > >" > Clients obtain a reference to a Parametric Singleton instance only >through the parametric singleton design pattern. If the instance is >left in an improper state (e.g., the serial port was left open) it is >NOT the role of the Parametric Singleton Design Pattern to close the >IO port. Nor is it the role of the Parametric Singleton Design Pattern >to >open the port. That role is delegate to some other part of the system. >" > >So when the clients obtain a reference to the singleton, can they >assume the port is there? IE, would it be the singletons role to >handle things like USB dongles being removed with event hints >comming from the underlying OS. Hardware abstraction layer/HAL on >Linux is an example of underlying OS events. > >I assume that role too is delegated to other parts of the system? > >-- >Trent Jarvi >tjarvi@qbang.org >_______________________________________________ >Rxtx mailing list >Rxtx@qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From maximulo at yahoo.com Fri Mar 24 01:22:38 2006 From: maximulo at yahoo.com (Maximulo Majir) Date: Tue Mar 28 20:17:32 2006 Subject: [Rxtx] JavaPOS Message-ID: <20060324082238.66371.qmail@web38214.mail.mud.yahoo.com> Hi all! Hello Trent! From what i understand, RXTX or JavaComm APIs were not created solely for JavaPOS. In JavaPOS, we have the virtual method claim() which is separate from open(), but in our RXTX API, claiming is done every call to open(), we cant open the port if its claimed by another application. Would it be alright to suggest or ask to create a new method called claim(..)? Is there such thing as forceclaim() in RXTX? this could be the same as portownership transfer or its equivalent. ForceClaim is in JSR80. Do you have some samples using RXTX as the lower layer for the Device Service Objects in JavaPOS? I have tried it, i just want to compare. Thank you all! maxim __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060324/496adba2/attachment-0003.html From tjarvi at qbang.org Fri Mar 24 11:28:19 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue Mar 28 20:17:32 2006 Subject: [Rxtx] Re: RXTX 2.1 Solaris Problems In-Reply-To: <3691.1143210578@www045.gmx.net> References: <3691.1143210578@www045.gmx.net> Message-ID: On Fri, 24 Mar 2006, Andreas Guenther wrote: > Hi all, > > the solaris problem was not the lock file only. > > Ok, I had to create the directory /var/spool/locks myself. > /var/spool/uucp exists. > > But rxtx didn't find any port. > > I compiled the source with my own debug-informations > and I tried to isolate the problem. > > The problem is the testRead-call in SerialImp.c > > JNIEXPORT jboolean JNICALL RXTXCommDriver(testRead)( > > ... > if ( READ( fd, &c, 1 ) < 0 ) > { > if ( errno != EAGAIN ) { > report( "testRead() read failed\n" ); > ret = JNI_FALSE; > } > } > Thanks Andreas I'm packing up to move. I'll be more or less away for a couple weeks here. I'll be checking email but my workstation is going into a box soon. This isn't hard to fix as this port should be enumerated when EWOULDBLOCK is recieved. Thats error is OK for enumeration just as EAGAIN is. I've put the bug into bugzilla so we dont forget to get to it. http://bugzilla.qbang.org/show_bug.cgi?id=42 You can add yourself to the CC list if you wish to test fixes we provide or even put a patch into bugzilla yourself. -- Trent Jarvi tjarvi@qbang.org From tjarvi at qbang.org Fri Mar 24 11:51:52 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue Mar 28 20:17:32 2006 Subject: [Rxtx] JavaPOS In-Reply-To: <20060324082238.66371.qmail@web38214.mail.mud.yahoo.com> References: <20060324082238.66371.qmail@web38214.mail.mud.yahoo.com> Message-ID: On Fri, 24 Mar 2006, Maximulo Majir wrote: > Hi all! Hello Trent! > > > From what i understand, RXTX or JavaComm APIs were not > created solely for JavaPOS. In JavaPOS, we have the virtual method > claim() which is separate from open(), but in our RXTX API, claiming is > done every call to open(), we cant open the port if its claimed by > another application. Would it be alright to suggest or ask to create a > new method called claim(..)? Is there such thing as forceclaim() in > RXTX? this could be the same as portownership transfer or its > equivalent. ForceClaim is in JSR80. > Do you have some samples using RXTX as the lower layer for the Device > Service Objects in JavaPOS? I have tried it, i just want to compare. > maxim Hi Maxim JSR80 is the USB API IBM/Sun put together. The problem is they have a richer kernel/API underneath that can handle such things. With Serial Ports, there isnt anything there other than an ioctl that says don't let anyone touch this and lockfiles that are more of a 'lets be nice.' At times we may be using USB ports but it is through the termios layer with the limitations mentioned. The advantage is that not only USB will work with rxtx. Anything that has a termios layer should work (to the extent that termios layer is complete). I don't know how forceclaim() would help you. Lets say someone has a programmer working on /dev/ttyS0 and you take it. Now you both race each other to read data first. There isn't a mechanism I know of that will solve this problem in termios. The most obvious test being a native app and a Java app trying to take the port. There is the potential of requestion ownership from other Java Applications but the use for that is very rare. Did you have something more specific in mind that I'm missing? I'm not sure that claim() and forceclaim() would help you with rxtx other than maybe locking the port with claim() without opening it. -- Trent Jarvi tjarvi@qbang.org From tjarvi at qbang.org Sat Mar 25 23:42:08 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue Mar 28 20:17:32 2006 Subject: [Rxtx] Serial snoop Message-ID: I was reading the Linux kernel mail-list tonight and ran past a thread that mentioned sersnoop. This looks like a handy tool for people dealing with new toys. "a simple command-line tool for linux that echoes bytes to and from any two serial ports, ptys, or network sockets, and prints all traffic to stdout, in hex and ascii." http://www.restivo.org/projects/sersnoop/ It works on Linux only at this time (debian package available). -- Trent Jarvi tjarvi@qbang.org From beat.arnet at gmail.com Sun Mar 26 07:32:35 2006 From: beat.arnet at gmail.com (Beat Arnet) Date: Tue Mar 28 20:17:32 2006 Subject: [Rxtx] Error 0x5 at /home/bob/foo/tar/rxtx-2.1-7/build/../src/termios.c(860): Access is, denied. Message-ID: <4426A603.80508@gmail.com> Dear all, When trying to open the serial port, I sometimes (not always) run into the following exception (when opening the serialPort): Error 0x5 at /home/bob/foo/tar/rxtx-2.1-7/build/../src/termios.c(860): Access is denied. java.lang.UnsatisfiedLinkError: native_psmisc_report_owner at gnu.io.CommPortIdentifier.native_psmisc_report_owner(Native Method) at gnu.io.CommPortIdentifier.open(CommPortIdentifier.java:354) at codeskin.tools.CLLoader.open(CLLoader.java:79) at codeskin.tools.C2000Programmer.run(C2000Programmer.java:220) at java.lang.Thread.run(Unknown Source) Is this the type of error where I should just try to open the port again, or can it be avoided? Regards, Beat From tjarvi at qbang.org Sun Mar 26 11:40:12 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue Mar 28 20:17:32 2006 Subject: [Rxtx] Error 0x5 at /home/bob/foo/tar/rxtx-2.1-7/build/../src/termios.c(860): Access is, denied. In-Reply-To: <4426A603.80508@gmail.com> References: <4426A603.80508@gmail.com> Message-ID: On Sun, 26 Mar 2006, Beat Arnet wrote: > Dear all, > > When trying to open the serial port, I sometimes (not always) run into > the following exception (when opening the serialPort): > > Error 0x5 at /home/bob/foo/tar/rxtx-2.1-7/build/../src/termios.c(860): > Access is > denied. > > java.lang.UnsatisfiedLinkError: native_psmisc_report_owner > at gnu.io.CommPortIdentifier.native_psmisc_report_owner(Native > Method) > at gnu.io.CommPortIdentifier.open(CommPortIdentifier.java:354) > at codeskin.tools.CLLoader.open(CLLoader.java:79) > at codeskin.tools.C2000Programmer.run(C2000Programmer.java:220) > at java.lang.Thread.run(Unknown Source) > > Is this the type of error where I should just try to open the port again, > or can it be avoided? > Hi Beat We did a second build of rxtx 2.1-7 to resolve that unsatisfied link error. It should work now. rxtx is trying to tell you it thinks someone else has the serial port open. You can try to open the port again but maybe you already have a copy of the program running when it happens? ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7r2.zip fixed build. -- Trent Jarvi tjarvi@qbang.org From tjarvi at qbang.org Sun Mar 26 11:44:23 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue Mar 28 20:17:32 2006 Subject: [Rxtx] RXTX spec file (fwd) Message-ID: This is probably interesting for fedora/suse users. ---------- Forwarded message ---------- Date: Sun, 26 Mar 2006 16:25:45 +0200 To: taj@www.linux.org.uk Subject: RXTX spec file I send you this spec file which allows to create a RPM for Fedora 4, 5 (x86, x86_64) with Java Sun. -------------- next part -------------- %ifarch %ix86 %define target_cpu i386 %endif %ifarch x86_64 %define target_cpu amd64 %endif Name: rxtx Version: 2.1 Release: 7r2%{?dist} Summary: RXTX Group: Development/Libraries License: LGPL URL: http://www.rxtx.org Source0: %{name}-%{version}-%{release}.tar.gz BuildRoot: %{_tmppath}/%{name}-%{version}-%{release}-root-%(%{__id_u} -n) %description rxtx is an full implementation of java commapi which aims to support RS232 IEEE 1284, RS485, I2C and RawIO. This is a developers release. %prep %setup -q -n %{name}-%{version}-%{release} %build export THREADS_FLAG=native ./autogen.sh %configure \ LDFLAGS=-s make %{?_smp_mflags} %install rm -rf $RPM_BUILD_ROOT mkdir -p $RPM_BUILD_ROOT%{_jvmdir}/jre/lib/ext $RPM_BUILD_ROOT%{_jvmdir}/jre/lib/%{target_cpu} make RXTX_PATH=$RPM_BUILD_ROOT%{_jvmdir}/jre/lib/%{target_cpu} JHOME=$RPM_BUILD_ROOT%{_jvmdir}/jre/lib/ext install echo "Driver=gnu.io.RXTXCommDriver" > $RPM_BUILD_ROOT%{_jvmdir}/jre/lib/gnu.io.rxtx.properties %clean rm -rf $RPM_BUILD_ROOT %files %defattr(-,root,root,-) %doc AUTHORS ChangeLog README RMISecurityManager.html COPYING INSTALL PORTING TODO %{_jvmdir}/jre/lib/* %changelog * Sun Mar 26 2006 Malek Degachi - Rebuild for Fedora Core 4 and Core 5. * Sun Mar 21 2004 Willem Riede - adjust spec file to support rpmbuild by ordinary user in Fedora context. From tjarvi at qbang.org Sun Mar 26 23:42:59 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue Mar 28 20:17:32 2006 Subject: [Rxtx] Upcomming events. Message-ID: This Wednesday we will be announcing a new "Maintainer" for the rxtx project. The position is more like neutral leader. I wont be going away or doing less. This is just the right thing to do as it turns out the two people with CVS write access will be at the same company. We need a third and we need neutrality. The maintainer will have final say in any conflict and will try to be neutral. It will be open for discussion. Then we will do it :) I'll still do most of the footwork I do now. But. I'm falling behind. I should have gone through the mail-list and posted the next round of changes this weekend. I'm packing to move and its going so so - 13 years of toys collected. I suspect there will be a dead period on my part (a couple weeks) comming up. But if you get it on the mail-list, we will get it in if there are no objections. I may well not be reading the mail-list during this period as I look for a house and many other things. I hope everyone will help out. Thanks -- Trent Jarvi tjarvi@qbang.org From mahmoud_hadad at yahoo.com Sun Mar 26 07:31:19 2006 From: mahmoud_hadad at yahoo.com (ronan nick) Date: Tue Mar 28 20:20:01 2006 Subject: [Rxtx] a question about the COMM API Message-ID: <20060326143119.54919.qmail@web60014.mail.yahoo.com> hi, i was intrested in knowing how i can communicate with my internal modem using java? for example if i want to make a phone dialer application or a caller id application where should i be looking at? and as i understood the COMM API is for devices that is attached to the computer through serial ports. --------------------------------- New Yahoo! Messenger with Voice. Call regular phones from your PC and save big. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060326/ce8329f0/attachment.html From dmarkman at mac.com Mon Mar 20 00:20:43 2006 From: dmarkman at mac.com (Dmitry Markman) Date: Mon, 20 Mar 2006 02:20:43 -0500 Subject: [Rxtx] Mac OS X RXTX java installer In-Reply-To: References: <07D0DE29-BA32-4CFE-B036-66BC6423D385@buechse.de> <441AE3E0.2030503@willicon.de> <12531986.1142622114996.JavaMail.dmarkman@mac.com> <441B2674.9010409@willicon.de> <13577405.1142634732776.JavaMail.dmarkman@mac.com> <441B4182.8010407@willicon.de> <92CD0D6C-5BE8-426E-A46D-99452059FF49@mac.com> <441BBB2D.8030305@willicon.de> <441C4088.5090905@willicon.de> Message-ID: <64BC1E23-FDDE-4CE6-8863-CFC881CBC224@mac.com> Hi all I put RXTX installer that will install everything (and will create / var/lock if necessary and add user to the uucp group) for mac os x from Java into the rxtx's CVS repository it could be easily modified to install files for any platform it uses Greg Guerin's AuthKit for authentication and authorization Greg released that kit under artistic license, so Trent, please take a look we, probably, can negotiate license with Greg if it's necessary Greg's AuthKit could be downloaded from http://www.amug.org/~glguerin/ sw/#authkit Michael Hall (mikehall at spacestar dot net) had a suggestion to make implementation of the jaas LoginModule based on Greg's AuthKit (his modification of the Greg's AuthKit could be found at http:// www.spacestar.net/users/mikehall/authkit.dmg) but Michael's AuthKitLoginModule does only half a job: it does authenticate but it can not run any external unix process in privileged mode (at least I wasn't able to do so) possible explanation could be found in conversation between Greg and Michael at Apple's java-dev list (look for archives) so I didn't use jaas API for rxtxinstaller I created folder MacOSX in the contrib folder comment 1. if you want to run that installer as standalone application all you need that RXTXInstaller.jar 2. if you want to use webstart you have to add Greg's libAuthKit.jnilib to the mac os x's resources in theory RXTXInstaller.jar doesn't need it, but there is a problem with loading libAuthKit.jnilib from webstart authkit uses loadLibrary method to load library and it failed (from webstart) for standalone application I extract libAuthKit.jnilib from the RXTXInstaller.jar and put it into the /Library/Java/Extensions or ~/Library/Java/Extensions folder that file will be deleted after installer quit unfortunately I didn't have time to put documentation there but it is mostly self-explanatory I took installer code from my gl4java installer that I did about 3 years ago (with small modifications) it would be very nice if Apple will release LoginModule that really will do the job (com.apple.security.auth.module package????? ) (UnixLoginModule is pretty useless) From lyon at docjava.com Mon Mar 20 06:34:39 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Mon, 20 Mar 2006 08:34:39 -0500 Subject: [Rxtx] Mac OS X RXTX java installer In-Reply-To: <64BC1E23-FDDE-4CE6-8863-CFC881CBC224@mac.com> References: <07D0DE29-BA32-4CFE-B036-66BC6423D385@buechse.de> <441AE3E0.2030503@willicon.de> <12531986.1142622114996.JavaMail.dmarkman@mac.com> <441B2674.9010409@willicon.de> <13577405.1142634732776.JavaMail.dmarkman@mac.com> <441B4182.8010407@willicon.de> <92CD0D6C-5BE8-426E-A46D-99452059FF49@mac.com> <441BBB2D.8030305@willicon.de> <441C4088.5090905@willicon.de> <64BC1E23-FDDE-4CE6-8863-CFC881CBC224@mac.com> Message-ID: Hi Dimitry, This sounds like great work. Just a couple of questions; After the check out of the CVS files, using: setenv CVSROOT :pserver:anonymous at cvs.milestonesolutions.com:/usr/local/cvsroot 53 8:28 setenv PASSWORD mousy 54 8:29 cvs login 55 8:29 cvs checkout rxtx-devel I cd'd over to: rxtx-devel/MACOSX_IDE And found: CVS/ CW/ ForPackageMaker/ PB/ Where is the installer? Thanks! - Doug From tjarvi at qbang.org Mon Mar 20 06:39:37 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 20 Mar 2006 06:39:37 -0700 (MST) Subject: [Rxtx] Mac OS X RXTX java installer In-Reply-To: References: <07D0DE29-BA32-4CFE-B036-66BC6423D385@buechse.de> <441AE3E0.2030503@willicon.de> <12531986.1142622114996.JavaMail.dmarkman@mac.com> <441B2674.9010409@willicon.de> <13577405.1142634732776.JavaMail.dmarkman@mac.com> <441B4182.8010407@willicon.de> <92CD0D6C-5BE8-426E-A46D-99452059FF49@mac.com> <441BBB2D.8030305@willicon.de> <441C4088.5090905@willicon.de> <64BC1E23-FDDE-4CE6-8863-CFC881CBC224@mac.com> Message-ID: On Mon, 20 Mar 2006, Dr. Douglas Lyon wrote: > Hi Dimitry, > This sounds like great work. Just a couple of questions; > After the check out of the CVS files, using: > setenv CVSROOT > :pserver:anonymous at cvs.milestonesolutions.com:/usr/local/cvsroot > 53 8:28 setenv PASSWORD mousy > 54 8:29 cvs login > 55 8:29 cvs checkout rxtx-devel Hi Doug You want "cvs checkout -r commapi-0-0-1 rxtx-devel" to get RXTX 2.1 The default branch is rxtx 2.0 which isn't very active right now. -- Trent Jarvi tjarvi at qbang.org From lyon at docjava.com Mon Mar 20 07:05:44 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Mon, 20 Mar 2006 09:05:44 -0500 Subject: [Rxtx] Mac OS X RXTX java installer In-Reply-To: References: <07D0DE29-BA32-4CFE-B036-66BC6423D385@buechse.de> <441AE3E0.2030503@willicon.de> <12531986.1142622114996.JavaMail.dmarkman@mac.com> <441B2674.9010409@willicon.de> <13577405.1142634732776.JavaMail.dmarkman@mac.com> <441B4182.8010407@willicon.de> <92CD0D6C-5BE8-426E-A46D-99452059FF49@mac.com> <441BBB2D.8030305@willicon.de> <441C4088.5090905@willicon.de> <64BC1E23-FDDE-4CE6-8863-CFC881CBC224@mac.com> Message-ID: Hi Trent, Thanks for the info on the CVS checkout procedure. I did that and am still not sure where the installer is. Here is what I have: cd MACOSX_IDE/ p4.docjava.com{lyon}121: ls CVS/ ForPackageMaker/ PB/ p4.docjava.com{lyon}122: find . | more . ./ForPackageMaker ./ForPackageMaker/RXTX.pkg.sit.hqx ./ForPackageMaker/Resources ./ForPackageMaker/Resources/ReadMe.rtf ./ForPackageMaker/Resources/Welcome.rtf ./ForPackageMaker/Resources/CVS ./ForPackageMaker/Resources/CVS/Entries ./ForPackageMaker/Resources/CVS/Repository ./ForPackageMaker/Resources/CVS/Tag ./ForPackageMaker/Resources/CVS/Root ./ForPackageMaker/Resources/preinstall ./ForPackageMaker/Resources/License.rtf ./ForPackageMaker/Resources/preupgrade ./ForPackageMaker/RXTX.pmsp ./ForPackageMaker/CVS ./ForPackageMaker/CVS/Entries ./ForPackageMaker/CVS/Repository ./ForPackageMaker/CVS/Entries.Log ./ForPackageMaker/CVS/Tag ./ForPackageMaker/CVS/Root ./ForPackageMaker/RXTX_Tiger.pkg.sitx.hqx ./ForPackageMaker/RXTX_Jag.pkg.sit.hqx ./ForPackageMaker/Install ./ForPackageMaker/Install/CVS ./ForPackageMaker/Install/CVS/Entries ./ForPackageMaker/Install/CVS/Repository ./ForPackageMaker/Install/CVS/Tag ./ForPackageMaker/Install/CVS/Root ./ForPackageMaker/Install/Library ./ForPackageMaker/Install/Library/CVS ./ForPackageMaker/Install/Library/CVS/Entries ./ForPackageMaker/Install/Library/CVS/Repository ./ForPackageMaker/Install/Library/CVS/Tag ./ForPackageMaker/Install/Library/CVS/Root ./ForPackageMaker/Install/Library/Java ./ForPackageMaker/Install/Library/Java/Extensions ./ForPackageMaker/Install/Library/Java/Extensions/RXTXcomm.jar ./ForPackageMaker/Install/Library/Java/Extensions/CVS ./ForPackageMaker/Install/Library/Java/Extensions/CVS/Entries ./ForPackageMaker/Install/Library/Java/Extensions/CVS/Repository ./ForPackageMaker/Install/Library/Java/Extensions/CVS/Tag ./ForPackageMaker/Install/Library/Java/Extensions/CVS/Root ./ForPackageMaker/Install/Library/Java/Extensions/librxtxSerial.jnilib ./ForPackageMaker/Install/Library/Java/CVS ./ForPackageMaker/Install/Library/Java/CVS/Entries ./ForPackageMaker/Install/Library/Java/CVS/Repository ./ForPackageMaker/Install/Library/Java/CVS/Entries.Log ./ForPackageMaker/Install/Library/Java/CVS/Tag ./ForPackageMaker/Install/Library/Java/CVS/Root ./ForPackageMaker/RXTX_Tiger.pmproj.sitx.hqx ./CVS ./CVS/Entries ./CVS/Repository ./CVS/Entries.Log ./CVS/Tag ./CVS/Root ./PB ./PB/LibSerialUniversal.xcodeproj.sitx.hqx ./PB/CVS ./PB/CVS/Entries ./PB/CVS/Repository ./PB/CVS/Entries.Log ./PB/CVS/Tag ./PB/CVS/Root ./PB/LibSerial.pbproj.sit.hqx ./PB/startpoint.c ./PB/config.h What is the procedure to run this installer? Do we need a README in: /rxtx-devel/MACOSX_IDE Here is what we have: CVS/ ForPackageMaker/ PB/ Thanks! - DL >On Mon, 20 Mar 2006, Dr. Douglas Lyon wrote: > >>Hi Dimitry, >>This sounds like great work. Just a couple of questions; >>After the check out of the CVS files, using: >>setenv CVSROOT >>:pserver:anonymous at cvs.milestonesolutions.com:/usr/local/cvsroot >> 53 8:28 setenv PASSWORD mousy >> 54 8:29 cvs login >> 55 8:29 cvs checkout rxtx-devel > >Hi Doug > >You want "cvs checkout -r commapi-0-0-1 rxtx-devel" to get RXTX 2.1 >The default branch is rxtx 2.0 which isn't very active right now. > >-- >Trent Jarvi >tjarvi at qbang.org From tjarvi at qbang.org Mon Mar 20 07:25:30 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 20 Mar 2006 07:25:30 -0700 (MST) Subject: [Rxtx] Mac OS X RXTX java installer In-Reply-To: References: <07D0DE29-BA32-4CFE-B036-66BC6423D385@buechse.de> <441AE3E0.2030503@willicon.de> <12531986.1142622114996.JavaMail.dmarkman@mac.com> <441B2674.9010409@willicon.de> <13577405.1142634732776.JavaMail.dmarkman@mac.com> <441B4182.8010407@willicon.de> <92CD0D6C-5BE8-426E-A46D-99452059FF49@mac.com> <441BBB2D.8030305@willicon.de> <441C4088.5090905@willicon.de> <64BC1E23-FDDE-4CE6-8863-CFC881CBC224@mac.com> Message-ID: On Mon, 20 Mar 2006, Dr. Douglas Lyon wrote: > Hi Trent, > Thanks for the info on the CVS checkout procedure. > I did that and am still not sure where the installer is. Hi Doug It does look like it was not cvs committed. There is no rxtx-devel/contrib/MacOSX directory in there at the moment. It was mentioned that it was put under contrib. -- Trent Jarvi tjarvi at qbang.org From dmarkman at mac.com Mon Mar 20 07:29:56 2006 From: dmarkman at mac.com (Dmitry Markman) Date: Mon, 20 Mar 2006 09:29:56 -0500 Subject: [Rxtx] Mac OS X RXTX java installer In-Reply-To: References: <07D0DE29-BA32-4CFE-B036-66BC6423D385@buechse.de> <441AE3E0.2030503@willicon.de> <12531986.1142622114996.JavaMail.dmarkman@mac.com> <441B2674.9010409@willicon.de> <13577405.1142634732776.JavaMail.dmarkman@mac.com> <441B4182.8010407@willicon.de> <92CD0D6C-5BE8-426E-A46D-99452059FF49@mac.com> <441BBB2D.8030305@willicon.de> <441C4088.5090905@willicon.de> <64BC1E23-FDDE-4CE6-8863-CFC881CBC224@mac.com> Message-ID: <6054EB4E-F7E0-4A9C-BDDA-D582D6D8826F@mac.com> you can find it in the rxtx-devel/contrib folder On Mar 20, 2006, at 9:05 AM, Dr. Douglas Lyon wrote: > Hi Trent, > Thanks for the info on the CVS checkout procedure. > I did that and am still not sure where the installer is. > Here is what I have: > cd MACOSX_IDE/ > p4.docjava.com{lyon}121: ls > CVS/ ForPackageMaker/ PB/ > p4.docjava.com{lyon}122: find . | more > . > ./ForPackageMaker > ./ForPackageMaker/RXTX.pkg.sit.hqx > ./ForPackageMaker/Resources > ./ForPackageMaker/Resources/ReadMe.rtf > ./ForPackageMaker/Resources/Welcome.rtf > ./ForPackageMaker/Resources/CVS > ./ForPackageMaker/Resources/CVS/Entries > ./ForPackageMaker/Resources/CVS/Repository > ./ForPackageMaker/Resources/CVS/Tag > ./ForPackageMaker/Resources/CVS/Root > ./ForPackageMaker/Resources/preinstall > ./ForPackageMaker/Resources/License.rtf > ./ForPackageMaker/Resources/preupgrade > ./ForPackageMaker/RXTX.pmsp > ./ForPackageMaker/CVS > ./ForPackageMaker/CVS/Entries > ./ForPackageMaker/CVS/Repository > ./ForPackageMaker/CVS/Entries.Log > ./ForPackageMaker/CVS/Tag > ./ForPackageMaker/CVS/Root > ./ForPackageMaker/RXTX_Tiger.pkg.sitx.hqx > ./ForPackageMaker/RXTX_Jag.pkg.sit.hqx > ./ForPackageMaker/Install > ./ForPackageMaker/Install/CVS > ./ForPackageMaker/Install/CVS/Entries > ./ForPackageMaker/Install/CVS/Repository > ./ForPackageMaker/Install/CVS/Tag > ./ForPackageMaker/Install/CVS/Root > ./ForPackageMaker/Install/Library > ./ForPackageMaker/Install/Library/CVS > ./ForPackageMaker/Install/Library/CVS/Entries > ./ForPackageMaker/Install/Library/CVS/Repository > ./ForPackageMaker/Install/Library/CVS/Tag > ./ForPackageMaker/Install/Library/CVS/Root > ./ForPackageMaker/Install/Library/Java > ./ForPackageMaker/Install/Library/Java/Extensions > ./ForPackageMaker/Install/Library/Java/Extensions/RXTXcomm.jar > ./ForPackageMaker/Install/Library/Java/Extensions/CVS > ./ForPackageMaker/Install/Library/Java/Extensions/CVS/Entries > ./ForPackageMaker/Install/Library/Java/Extensions/CVS/Repository > ./ForPackageMaker/Install/Library/Java/Extensions/CVS/Tag > ./ForPackageMaker/Install/Library/Java/Extensions/CVS/Root > ./ForPackageMaker/Install/Library/Java/Extensions/librxtxSerial.jnilib > ./ForPackageMaker/Install/Library/Java/CVS > ./ForPackageMaker/Install/Library/Java/CVS/Entries > ./ForPackageMaker/Install/Library/Java/CVS/Repository > ./ForPackageMaker/Install/Library/Java/CVS/Entries.Log > ./ForPackageMaker/Install/Library/Java/CVS/Tag > ./ForPackageMaker/Install/Library/Java/CVS/Root > ./ForPackageMaker/RXTX_Tiger.pmproj.sitx.hqx > ./CVS > ./CVS/Entries > ./CVS/Repository > ./CVS/Entries.Log > ./CVS/Tag > ./CVS/Root > ./PB > ./PB/LibSerialUniversal.xcodeproj.sitx.hqx > ./PB/CVS > ./PB/CVS/Entries > ./PB/CVS/Repository > ./PB/CVS/Entries.Log > ./PB/CVS/Tag > ./PB/CVS/Root > ./PB/LibSerial.pbproj.sit.hqx > ./PB/startpoint.c > ./PB/config.h > > What is the procedure to run this installer? > Do we need a README in: > /rxtx-devel/MACOSX_IDE > Here is what we have: > CVS/ ForPackageMaker/ PB/ > > > Thanks! > - DL > >> On Mon, 20 Mar 2006, Dr. Douglas Lyon wrote: >> >>> Hi Dimitry, >>> This sounds like great work. Just a couple of questions; >>> After the check out of the CVS files, using: >>> setenv CVSROOT :pserver:anonymous at cvs.milestonesolutions.com:/usr/ >>> local/cvsroot >>> 53 8:28 setenv PASSWORD mousy >>> 54 8:29 cvs login >>> 55 8:29 cvs checkout rxtx-devel >> >> Hi Doug >> >> You want "cvs checkout -r commapi-0-0-1 rxtx-devel" to get RXTX 2.1 >> The default branch is rxtx 2.0 which isn't very active right now. >> >> -- >> Trent Jarvi >> tjarvi at qbang.org > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx Dmitry Markman From mikehall at spacestar.net Mon Mar 20 05:25:25 2006 From: mikehall at spacestar.net (Michael Hall) Date: Mon, 20 Mar 2006 06:25:25 -0600 Subject: [Rxtx] Re: Mac OS X RXTX java installer In-Reply-To: <64BC1E23-FDDE-4CE6-8863-CFC881CBC224@mac.com> References: <07D0DE29-BA32-4CFE-B036-66BC6423D385@buechse.de> <441AE3E0.2030503@willicon.de> <12531986.1142622114996.JavaMail.dmarkman@mac.com> <441B2674.9010409@willicon.de> <13577405.1142634732776.JavaMail.dmarkman@mac.com> <441B4182.8010407@willicon.de> <92CD0D6C-5BE8-426E-A46D-99452059FF49@mac.com> <441BBB2D.8030305@willicon.de> <441C4088.5090905@willicon.de> <64BC1E23-FDDE-4CE6-8863-CFC881CBC224@mac.com> Message-ID: <247EB61F-5CD1-4132-89A2-FC105B6CF9A5@spacestar.net> On Mar 20, 2006, at 1:20 AM, Dmitry Markman wrote: > > Michael Hall (mikehall at spacestar dot net) had a suggestion to > make implementation of the jaas LoginModule > based on Greg's AuthKit > (his modification of the Greg's AuthKit could be found at http:// > www.spacestar.net/users/mikehall/authkit.dmg) > but Michael's AuthKitLoginModule does only half a job: > it does authenticate > but it can not run any external unix process in privileged mode (at > least I wasn't able to do so) If you got it working directly with Greg's the point is moot. But to clarify it anyhow. The login module does not allow you to do anything anything privileged on return as was explained by Greg. You need to work with a separate privileged process using the execPrivileged method of his API. I assume you did something similar although I haven't looked at how you are using it yet. I allowed instead for a action to be performed at the same time you login/authenticate,this... System.setProperty("authkit.action","/usr/bin/id"); just before this... lc.login(); To clarify, safely ignored as you are already complete. Mike Hall mikehall at spacestar dot net http://www.spacestar.net/users/mikehall http://sourceforge.net/projects/macnative -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2427 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20060320/f6e18202/smime-0004.bin From dmarkman at mac.com Mon Mar 20 07:36:47 2006 From: dmarkman at mac.com (Dmitry Markman) Date: Mon, 20 Mar 2006 09:36:47 -0500 Subject: [Rxtx] Re: Mac OS X RXTX java installer In-Reply-To: <247EB61F-5CD1-4132-89A2-FC105B6CF9A5@spacestar.net> References: <07D0DE29-BA32-4CFE-B036-66BC6423D385@buechse.de> <441AE3E0.2030503@willicon.de> <12531986.1142622114996.JavaMail.dmarkman@mac.com> <441B2674.9010409@willicon.de> <13577405.1142634732776.JavaMail.dmarkman@mac.com> <441B4182.8010407@willicon.de> <92CD0D6C-5BE8-426E-A46D-99452059FF49@mac.com> <441BBB2D.8030305@willicon.de> <441C4088.5090905@willicon.de> <64BC1E23-FDDE-4CE6-8863-CFC881CBC224@mac.com> <247EB61F-5CD1-4132-89A2-FC105B6CF9A5@spacestar.net> Message-ID: Hi, Michael all I have to do is to run some shell script I tried to use your action mechanism and it worked great so I just System.setProperty ("authkit.action","" ) and after that I even don't need to run anything like subject.doAs.... but after few thoughts I choose to use plain Greg's approach, because in that case I don't have to deal with various java's configurations files and therefore to use 2-3 -D parameters in the java command line especially it's useful for java web start (it's so fragile :-( ) thanks for the great job On Mar 20, 2006, at 7:25 AM, Michael Hall wrote: > > On Mar 20, 2006, at 1:20 AM, Dmitry Markman wrote: >> >> Michael Hall (mikehall at spacestar dot net) had a suggestion to >> make implementation of the jaas LoginModule >> based on Greg's AuthKit >> (his modification of the Greg's AuthKit could be found at http:// >> www.spacestar.net/users/mikehall/authkit.dmg) >> but Michael's AuthKitLoginModule does only half a job: >> it does authenticate >> but it can not run any external unix process in privileged mode >> (at least I wasn't able to do so) > > If you got it working directly with Greg's the point is moot. > > But to clarify it anyhow. > The login module does not allow you to do anything anything > privileged on return as was explained by Greg. You need to work > with a separate privileged process using the execPrivileged method > of his API. I assume you did something similar although I haven't > looked at how you are using it yet. > I allowed instead for a action to be performed at the same time you > login/authenticate,this... > System.setProperty("authkit.action","/usr/bin/id"); > just before this... > lc.login(); > To clarify, safely ignored as you are already complete. > > Mike Hall mikehall at spacestar dot net > http://www.spacestar.net/users/mikehall > http://sourceforge.net/projects/macnative > > > Dmitry Markman From dmarkman at mac.com Mon Mar 20 07:44:45 2006 From: dmarkman at mac.com (Dmitry Markman) Date: Mon, 20 Mar 2006 09:44:45 -0500 Subject: [Rxtx] Mac OS X RXTX java installer In-Reply-To: References: <07D0DE29-BA32-4CFE-B036-66BC6423D385@buechse.de> <441AE3E0.2030503@willicon.de> <12531986.1142622114996.JavaMail.dmarkman@mac.com> <441B2674.9010409@willicon.de> <13577405.1142634732776.JavaMail.dmarkman@mac.com> <441B4182.8010407@willicon.de> <92CD0D6C-5BE8-426E-A46D-99452059FF49@mac.com> <441BBB2D.8030305@willicon.de> <441C4088.5090905@willicon.de> <64BC1E23-FDDE-4CE6-8863-CFC881CBC224@mac.com> Message-ID: it's in the commapi-0-0-1 branch I tested it right now: cvs co -r commapi-0-0-1 rxtx-devel and I got everything On Mar 20, 2006, at 9:25 AM, Trent Jarvi wrote: > On Mon, 20 Mar 2006, Dr. Douglas Lyon wrote: > >> Hi Trent, >> Thanks for the info on the CVS checkout procedure. >> I did that and am still not sure where the installer is. > > Hi Doug > > It does look like it was not cvs committed. There is no rxtx-devel/ > contrib/MacOSX directory in there at the moment. It was mentioned > that it was put under contrib. > > -- > Trent Jarvi > tjarvi at qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx Dmitry Markman From tjarvi at qbang.org Mon Mar 20 07:52:57 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 20 Mar 2006 07:52:57 -0700 (MST) Subject: [Rxtx] Mac OS X RXTX java installer In-Reply-To: References: <07D0DE29-BA32-4CFE-B036-66BC6423D385@buechse.de> <441AE3E0.2030503@willicon.de> <12531986.1142622114996.JavaMail.dmarkman@mac.com> <441B2674.9010409@willicon.de> <13577405.1142634732776.JavaMail.dmarkman@mac.com> <441B4182.8010407@willicon.de> <92CD0D6C-5BE8-426E-A46D-99452059FF49@mac.com> <441BBB2D.8030305@willicon.de> <441C4088.5090905@willicon.de> <64BC1E23-FDDE-4CE6-8863-CFC881CBC224@mac.com> Message-ID: On Mon, 20 Mar 2006, Dmitry Markman wrote: > it's in the commapi-0-0-1 branch > > I tested it right now: > cvs co -r commapi-0-0-1 rxtx-devel > > and I got everything > A fresh checkout worked. Here is a copy of the tree (just the installer bits) ftp://ftp.qbang.org/pub/rxtx/MacOSX-installer.zip -- Trent Jarvi tjarvi at qbang.org From lyon at docjava.com Mon Mar 20 08:08:26 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Mon, 20 Mar 2006 10:08:26 -0500 Subject: [Rxtx] Mac OS X RXTX java installer In-Reply-To: References: <07D0DE29-BA32-4CFE-B036-66BC6423D385@buechse.de> <441AE3E0.2030503@willicon.de> <12531986.1142622114996.JavaMail.dmarkman@mac.com> <441B2674.9010409@willicon.de> <13577405.1142634732776.JavaMail.dmarkman@mac.com> <441B4182.8010407@willicon.de> <92CD0D6C-5BE8-426E-A46D-99452059FF49@mac.com> <441BBB2D.8030305@willicon.de> <441C4088.5090905@willicon.de> <64BC1E23-FDDE-4CE6-8863-CFC881CBC224@mac.com> Message-ID: Hi All, Is the Auth package able to work properly on non Mac OS's? It was not clear from the doc or download. Thanks! - Doug From dmarkman at mac.com Mon Mar 20 08:15:22 2006 From: dmarkman at mac.com (Dmitry Markman) Date: Mon, 20 Mar 2006 10:15:22 -0500 Subject: [Rxtx] Mac OS X RXTX java installer In-Reply-To: References: <07D0DE29-BA32-4CFE-B036-66BC6423D385@buechse.de> <441AE3E0.2030503@willicon.de> <12531986.1142622114996.JavaMail.dmarkman@mac.com> <441B2674.9010409@willicon.de> <13577405.1142634732776.JavaMail.dmarkman@mac.com> <441B4182.8010407@willicon.de> <92CD0D6C-5BE8-426E-A46D-99452059FF49@mac.com> <441BBB2D.8030305@willicon.de> <441C4088.5090905@willicon.de> <64BC1E23-FDDE-4CE6-8863-CFC881CBC224@mac.com> Message-ID: <217312D8-CCCA-4859-ABA6-32DF1CC817B9@mac.com> thanks Trent, for putting it on ftp server On Mar 20, 2006, at 9:52 AM, Trent Jarvi wrote: > A fresh checkout worked. Here is a copy of the tree (just the > installer bits) > > ftp://ftp.qbang.org/pub/rxtx/MacOSX-installer.zip > Dmitry Markman From dmarkman at mac.com Mon Mar 20 09:14:03 2006 From: dmarkman at mac.com (Dmitry Markman) Date: Mon, 20 Mar 2006 11:14:03 -0500 Subject: [Rxtx] Mac OS X RXTX java installer In-Reply-To: References: <07D0DE29-BA32-4CFE-B036-66BC6423D385@buechse.de> <441AE3E0.2030503@willicon.de> <12531986.1142622114996.JavaMail.dmarkman@mac.com> <441B2674.9010409@willicon.de> <13577405.1142634732776.JavaMail.dmarkman@mac.com> <441B4182.8010407@willicon.de> <92CD0D6C-5BE8-426E-A46D-99452059FF49@mac.com> <441BBB2D.8030305@willicon.de> <441C4088.5090905@willicon.de> <64BC1E23-FDDE-4CE6-8863-CFC881CBC224@mac.com> Message-ID: <4DEBA6F0-DA45-4E84-823E-1F1AC48BDCCC@mac.com> no it will work only on mac os x however it's harmless to run it on other platform if you want to use it for other platform you have to do the following (I'll do it for linux) 1. modify RXTXInstaller class method public static RXTXInstaller getInstance() public static RXTXInstaller getInstance() { String osName = System.getProperty("os.name").toLowerCase(); if(osName.startsWith("mac")){ return new gnu.io.installer.macosx.MACOSXRXTXInstaller(); } else if(osName.startsWith("windows")){ return new gnu.io.installer.windows.WindowsRXTXInstaller(); }else if(osName.startsWith("linux")){ return new gnu.io.installer.linux.LinuxRXTXInstaller(); } return null; } 2. create folder gnu/io/installer/linux/ 3. create class Linux386RXTXInstaller package gnu.io.installer.linux; import java.io.File; public class Linux386RXTXInstaller extends gnu.io.installer.RXTXInstaller{ public Linux386RXTXInstaller(){ createJarFolder(); createLibFolder(); addJarResource("RXTXcomm.jar","/gnu/io/installer/resources/ linux/jar/RXTXcomm.dat"); addLibResource("librxtxSerial.so","/gnu/io/installer/ resources/linux/lib/librxtxSerial.so"); } protected void createJarFolder(){ String javaHome = System.getProperty("java.home"); char separator = File.separatorChar; jarFolder = new File(javaHome+separator+"lib"+separator+"ext"); } protected void createLibFolder(){ String javaHome = System.getProperty("java.home"); char separator = File.separatorChar; libFolder = new File(javaHome+separator+"bin"); } public void runPreProcess() {} //put here some action you need public void runPostProcess() {} //put here some action you need } 4. create folder /gnu/io/installer/resources/linux/jar and put there linux's version of RXTXcomm.dat (which is renamed RXTXcomm.jar) 5. create folder /gnu/io/installer/resources/linux/lib and put there linux's version of librxtxSerial. so 6. make sure that RXTXInstaller.jar has the following items: /gnu/io/installer/resources/linux/jar/RXTXcomm.jar /gnu/io/installer/resources/linux/lib/librxtxSerial.so 7. modify file installer.pref: jar file RXTXInstaller.jar must have the following item /gnu/io/installer/installer.pref that's basically it for windows you have to do the similar things: just replace linux to windows and librxtxSerial.so to rxtxSerial.dll and create appropriate gnu.io.installer.windows.WindowsRXTXInstaller class package gnu.io.installer.windows; import java.io.File; public class WindowsRXTXInstaller extends gnu.io.installer.RXTXInstaller{ public WindowsRXTXInstaller(){ createJarFolder(); createLibFolder(); addJarResource("RXTXcomm.jar","/gnu/io/installer/resources/ windows/jar/RXTXcomm.dat"); addLibResource("librxtxSerial.so","/gnu/io/installer/ resources/windows/lib/rxtxSerial.dll"); } protected void createJarFolder(){ String javaHome = System.getProperty("java.home"); char separator = File.separatorChar; jarFolder = new File(javaHome+separator+"lib"+separator+"ext"); } protected void createLibFolder(){ String javaHome = System.getProperty("java.home"); char separator = File.separatorChar; libFolder = new File(javaHome+separator+"bin"); } public void runPreProcess() {} //put here some action you need public void runPostProcess() {} //put here some action you need } installer.pref will look like On Mar 20, 2006, at 10:08 AM, Dr. Douglas Lyon wrote: > Hi All, > Is the Auth package able to work properly on > non Mac OS's? > It was not clear from the doc or download. > > Thanks! > - Doug > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx Dmitry Markman From joachim at buechse.de Mon Mar 20 10:49:06 2006 From: joachim at buechse.de (Joachim Buechse) Date: Mon, 20 Mar 2006 18:49:06 +0100 Subject: [Rxtx] BUG: Lock file stays even if port opening fails Message-ID: This was only tested on MacOSX but looking at the code, it should be true for all systems that use lock_uucp. I am opening a port which can not be opened (dialup port of a telephone paired via bluetooth but currently not reachable). The lock file is created and stays arround, even though the port open failed. After looking a bit through the code (of 2.17), I really wonder if it wouldn't be a good idea to make the "locking" an explicit operation called from the java code. This would certainly simplify the generation of meaningfull exceptions (and java based debugging). Maybe even the handling of "preopened" ports should be in the Java part of the lib (again for java based debugging puposes). That beeing said, I have no idea if this would be possible for the 2.07 implementation. Regards, Joachim From tjarvi at qbang.org Mon Mar 20 11:24:22 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 20 Mar 2006 11:24:22 -0700 (MST) Subject: [Rxtx] BUG: Lock file stays even if port opening fails In-Reply-To: References: Message-ID: On Mon, 20 Mar 2006, Joachim Buechse wrote: > This was only tested on MacOSX but looking at the code, it should be true > for all systems that use lock_uucp. > > I am opening a port which can not be opened (dialup port of a telephone > paired via bluetooth but currently not reachable). The lock file is > created and stays arround, even though the port open failed. > > > After looking a bit through the code (of 2.17), I really wonder if it > wouldn't be a good idea to make the "locking" an explicit operation > called from the java code. This would certainly simplify the generation > of meaningfull exceptions (and java based debugging). > Maybe even the handling of "preopened" ports should be in the Java part > of the lib (again for java based debugging puposes). That beeing said, I > have no idea if this would be possible for the 2.07 implementation. > > Regards, Hi Joachim It should be possible in the 2.0-7 implementation too. The calls to RXTXPort.java would not change. We would just do more there Moving more of that logic into Java would be better as many people don't like to look at C code. There is a liblockdev on most Linux distros that can do most of the C code and would be easier to use. The problem is embeded devices will not have that library. The preopened port code has not been really tested. That was a last minute request in a product cycle. I expect it will be tested this year though. As I recall, some devices really do not like CD raising on open. The preopened ports then allow people to mess around in java without power cycling the devices or losing data. -- Trent Jarvi tjarvi at qbang.org From joachim at buechse.de Mon Mar 20 12:01:08 2006 From: joachim at buechse.de (Joachim Buechse) Date: Mon, 20 Mar 2006 20:01:08 +0100 Subject: [Rxtx] BUG: Lock file stays even if port opening fails In-Reply-To: References: Message-ID: Hi Trent, What is your general feeling about moving code to Java? The last days I have been reading quite a bit of the code and there are several things, that might not work as expected. I'll give you two examples from is_device_locked: if LOCKDIR == /var/spool/locks the directory /var/spool/lock will not be checked. LOCKDIR is not checked for lockfiles with unexpected pefixes While these things have probably never been discovered in production, they are still possibly incorrect implementations. If it was Java code, I would write some unit tests producing the errors that could later be corrected. PS: One could imagine to actually implement the whole lockfile handling in Java using some native routines to get the values required (pid, st_dev, st_rdev, ...). On 20.03.2006, at 19:24, Trent Jarvi wrote: > On Mon, 20 Mar 2006, Joachim Buechse wrote: > >> This was only tested on MacOSX but looking at the code, it should >> be true for all systems that use lock_uucp. >> >> I am opening a port which can not be opened (dialup port of a >> telephone paired via bluetooth but currently not reachable). The >> lock file is created and stays arround, even though the port open >> failed. >> >> >> After looking a bit through the code (of 2.17), I really wonder if >> it wouldn't be a good idea to make the "locking" an explicit >> operation called from the java code. This would certainly simplify >> the generation of meaningfull exceptions (and java based debugging). >> Maybe even the handling of "preopened" ports should be in the Java >> part of the lib (again for java based debugging puposes). That >> beeing said, I have no idea if this would be possible for the 2.07 >> implementation. >> >> Regards, > > Hi Joachim > > It should be possible in the 2.0-7 implementation too. The calls > to RXTXPort.java would not change. We would just do more there > Moving more of that logic into Java would be better as many people > don't like to look at C code. There is a liblockdev on most Linux > distros that can do most of the C code and would be easier to use. > The problem is embeded devices will not have that library. > > The preopened port code has not been really tested. That was a > last minute request in a product cycle. I expect it will be tested > this year though. As I recall, some devices really do not like CD > raising on open. The preopened ports then allow people to mess > around in java without power cycling the devices or losing data. > > -- > Trent Jarvi > tjarvi at qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Mon Mar 20 12:21:02 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 20 Mar 2006 12:21:02 -0700 (MST) Subject: [Rxtx] BUG: Lock file stays even if port opening fails In-Reply-To: References: Message-ID: On Mon, 20 Mar 2006, Joachim Buechse wrote: > Hi Trent, > > What is your general feeling about moving code to Java? The last days I > have been reading quite a bit of the code and there are several things, > that might not work as expected. > > I'll give you two examples from is_device_locked: > > if LOCKDIR == /var/spool/locks the directory /var/spool/lock will not be > checked. > LOCKDIR is not checked for lockfiles with unexpected pefixes > > While these things have probably never been discovered in production, > they are still possibly incorrect implementations. If it was Java code, I > would write some unit tests producing the errors that could later be > corrected. > > PS: One could imagine to actually implement the whole lockfile handling > in Java using some native routines to get the values required (pid, > st_dev, st_rdev, ...). Hi Joachim I like the idea of moving more of the code into java but there are some things to consider. If you break this into multiple JNI calls, the performance will drop considerably during enumeration of ports. We are looking for 256 ports per dev type vs (16? in Sun's 2.0 and fewer types). Its hard to make assumptions. I've seen virtual ports start at /dev/foo100 for instance. It works out to over 7500 ports on Linux if you enable them all. We already trim that back by default. See Linux-all-ports in RXTXCommDriver.java. There are also native libraries that rxtx can link to. If you move too much into Java, linking to 'standard' libraries with distros will break. "configure --enable-liblock=yes" will not be doable. This is probably a favorable way with RedHat, Debian, Suse and others. Thats the right thing to do if there will be rpms, dpkg, .. For those reasons, I think it still make sense to keep it to a minimal ~3 calls to JNI code that we can use for speed and versatility. lock() isLocked(), unlock() perhaps. When I say speed, its more about avoiding crossing the JNI layer multiple times than java vs C performance. With versatility I think liblock is the right way for most but not all (embeded) linux distros. -- Trent Jarvi tjarvi at qbang.org From joachim at buechse.de Mon Mar 20 12:42:04 2006 From: joachim at buechse.de (Joachim Buechse) Date: Mon, 20 Mar 2006 20:42:04 +0100 Subject: [Rxtx] BUG: Lock file stays even if port opening fails In-Reply-To: References: Message-ID: <82C19FE7-DDCB-45B6-B2C9-7606B66F0124@buechse.de> Ok, what about providing a default implementation in Java? The RXTXCommDriver would call a (native) function useNativeLocking and if it returns true, call the native functions for lock() isLocked (), unlock(), else is would use the Java based default implementation. This could possibly be overriden by a property (again for debugging). Joachim On 20.03.2006, at 20:21, Trent Jarvi wrote: > On Mon, 20 Mar 2006, Joachim Buechse wrote: > >> Hi Trent, >> >> What is your general feeling about moving code to Java? The last >> days I have been reading quite a bit of the code and there are >> several things, that might not work as expected. >> >> I'll give you two examples from is_device_locked: >> >> if LOCKDIR == /var/spool/locks the directory /var/spool/lock will >> not be checked. >> LOCKDIR is not checked for lockfiles with unexpected pefixes >> >> While these things have probably never been discovered in >> production, they are still possibly incorrect implementations. If >> it was Java code, I would write some unit tests producing the >> errors that could later be corrected. >> >> PS: One could imagine to actually implement the whole lockfile >> handling in Java using some native routines to get the values >> required (pid, st_dev, st_rdev, ...). > > Hi Joachim > > I like the idea of moving more of the code into java but there are > some things to consider. > > If you break this into multiple JNI calls, the performance will > drop considerably during enumeration of ports. We are looking for > 256 ports per dev type vs (16? in Sun's 2.0 and fewer types). Its > hard to make assumptions. I've seen virtual ports start at /dev/ > foo100 for instance. > > It works out to over 7500 ports on Linux if you enable them all. > We already trim that back by default. See Linux-all-ports in > RXTXCommDriver.java. > > There are also native libraries that rxtx can link to. If you move > too much into Java, linking to 'standard' libraries with distros > will break. "configure --enable-liblock=yes" will not be doable. > This is probably a favorable way with RedHat, Debian, Suse and > others. Thats the right thing to do if there will be rpms, dpkg, .. > > For those reasons, I think it still make sense to keep it to a > minimal ~3 calls to JNI code that we can use for speed and > versatility. lock() isLocked(), unlock() perhaps. When I say > speed, its more about avoiding crossing the JNI layer multiple > times than java vs C performance. With versatility I think liblock > is the right way for most but not all (embeded) linux distros. > > -- > Trent Jarvi > tjarvi at qbang.org > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Mon Mar 20 12:44:47 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 20 Mar 2006 12:44:47 -0700 (MST) Subject: [Rxtx] BUG: Lock file stays even if port opening fails In-Reply-To: <82C19FE7-DDCB-45B6-B2C9-7606B66F0124@buechse.de> References: <82C19FE7-DDCB-45B6-B2C9-7606B66F0124@buechse.de> Message-ID: On Mon, 20 Mar 2006, Joachim Buechse wrote: > Ok, what about providing a default implementation in Java? > > The RXTXCommDriver would call a (native) function useNativeLocking and if > it returns true, call the native functions for lock() isLocked(), > unlock(), else is would use the Java based default implementation. This > could possibly be overriden by a property (again for debugging). > Hi Joachim That would be OK with me. -- Trent Jarvi tjarvi at qbang.org From dmarkman at mac.com Mon Mar 20 22:27:45 2006 From: dmarkman at mac.com (Dmitry Markman) Date: Tue, 21 Mar 2006 00:27:45 -0500 Subject: [Rxtx] binaries request Message-ID: <42702213-C222-4937-A585-7CFB17E47608@mac.com> Hi can somebody send me latest linux and windows binaries, please? or where I can find them (I didn't find them in the latest tareball) I gave up with my cygwin: something wrong I have no idea what java doesn't understand /cygwin/c syntax after I changed makefile it did java part but after that gcc 3.4.4 started to complain I set buffer length to 999 lines but I didn't get beginning of the story something wrong with my 1.4.2_09/include/jni.h gcc doesn't like it anyway I gave up thanks in advance Dmitry Markman -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060320/f8cbc57c/attachment-0004.html From tjarvi at qbang.org Mon Mar 20 22:36:48 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 20 Mar 2006 22:36:48 -0700 (MST) Subject: [Rxtx] binaries request In-Reply-To: <42702213-C222-4937-A585-7CFB17E47608@mac.com> References: <42702213-C222-4937-A585-7CFB17E47608@mac.com> Message-ID: On Tue, 21 Mar 2006, Dmitry Markman wrote: > Hi > can somebody send me latest linux and windows binaries, please? > > or where I can find them (I didn't find them in the latest tareball) > > I gave up with my cygwin: something wrong I have no idea what > java doesn't understand /cygwin/c syntax > after I changed makefile it did java part > but after that gcc 3.4.4 started to complain > I set buffer length to 999 lines but I didn't get beginning of the story > something wrong with my 1.4.2_09/include/jni.h gcc doesn't like it > anyway I gave up > > thanks in advance > Hi Dmitry The bins are here: ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7-bins-r2.zip Here are the files in the zip you want. Jar: rxtx-2.1-7-bins-r2/RXTXcomm.jar Windows: rxtx-2.1-7-bins-r2/Windows/i368-mingw32/rxtxSerial.dll Linux (x86) rxtx-2.1-7-bins-r2/Linux/i686-unknown-linux-gnu/librxtxSerial.so There are others in there including Parallel port support but those are the main ones for testing. -- Trent Jarvi tjarvi at qbang.org From dmarkman at mac.com Mon Mar 20 23:05:59 2006 From: dmarkman at mac.com (Dmitry Markman) Date: Tue, 21 Mar 2006 01:05:59 -0500 Subject: [Rxtx] binaries request In-Reply-To: References: <42702213-C222-4937-A585-7CFB17E47608@mac.com> Message-ID: thank you very much but windows's readme says: rxtxSerial.dll had to be recomopiled to link in missing native methods. should I ignore it? or what? thanks again also I understand that I should use mingw not cygwin I'll try to install mingw On Mar 21, 2006, at 12:36 AM, Trent Jarvi wrote: > On Tue, 21 Mar 2006, Dmitry Markman wrote: > >> Hi >> can somebody send me latest linux and windows binaries, please? >> >> or where I can find them (I didn't find them in the latest tareball) >> >> I gave up with my cygwin: something wrong I have no idea what >> java doesn't understand /cygwin/c syntax >> after I changed makefile it did java part >> but after that gcc 3.4.4 started to complain >> I set buffer length to 999 lines but I didn't get beginning of the >> story >> something wrong with my 1.4.2_09/include/jni.h gcc doesn't like it >> anyway I gave up >> >> thanks in advance >> > > Hi Dmitry > > The bins are here: > > ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7-bins-r2.zip > > Here are the files in the zip you want. > > Jar: > > rxtx-2.1-7-bins-r2/RXTXcomm.jar > > Windows: > > rxtx-2.1-7-bins-r2/Windows/i368-mingw32/rxtxSerial.dll > > Linux (x86) > > rxtx-2.1-7-bins-r2/Linux/i686-unknown-linux-gnu/librxtxSerial.so > > There are others in there including Parallel port support but those > are the main ones for testing. > > -- > Trent Jarvi > tjarvi at qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx Dmitry Markman From tjarvi at qbang.org Mon Mar 20 23:20:33 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 20 Mar 2006 23:20:33 -0700 (MST) Subject: [Rxtx] binaries request In-Reply-To: References: <42702213-C222-4937-A585-7CFB17E47608@mac.com> Message-ID: On Tue, 21 Mar 2006, Dmitry Markman wrote: > thank you very much > > but windows's readme says: > rxtxSerial.dll had to be recomopiled to link in missing native methods. > > should I ignore it? or what? > Hi Dmitry That dll should be OK. r2 is the recompile linked to the missing native method. The readme explains why it was recompiled; fuser.o was not linked into the dll in the first release. -- Trent Jarvi tjarvi at qbang.org From ariantristan at yahoo.com Mon Mar 20 23:55:24 2006 From: ariantristan at yahoo.com (Lambok Sianturi) Date: Mon, 20 Mar 2006 22:55:24 -0800 (PST) Subject: [Rxtx] jvm issue Message-ID: <20060321065524.94779.qmail@web50701.mail.yahoo.com> Hi All, This is my first time to join RxTx mailing list. I thank you all for allowing others to sign in in requests help. I use the latest RxTx lib in Fedora 3 with java version 1.4.2_09 b05. And I got this error: # # An unexpected error has been detected by HotSpot Virtual Machine: # # SIGSEGV (0xb) at pc=0x00bf27f3, pid=2633, tid=3086112448 # # Java VM: Java HotSpot(TM) Client VM (1.4.2_09-b05 mixed mode) # Problematic frame: # C [ld-linux.so.2+0xa7f3] # # An error report file with more information is saved as hs_err_pid2633.log # # If you would like to submit a bug report, please visit: # http://java.sun.com/webapps/bugreport/crash.jsp # ./run.sh: line 3: 2633 Aborted /usr/local/java/bin/java -Djava.library.path=/usr/local/java/jre/lib/ -Djsmsengine.debug=true -classpath jsmsengine.jar:smsgateway.jar:classes12.jar:RXTXcomm.jar:. com.api.sms.SMSServer What is the jvm depedency for the latest library? Can I use 1.4.2_09 b05? Thanks in advance. Arian --------------------------------- Yahoo! Mail Use Photomail to share photos without annoying attachments. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060320/83d58dd7/attachment-0004.html From f.frumento at ngi.it Tue Mar 21 00:21:47 2006 From: f.frumento at ngi.it (Fabio Frumento) Date: Tue, 21 Mar 2006 08:21:47 +0100 Subject: [Rxtx] Javadoc on the go Message-ID: <441FA98B.9050701@ngi.it> Hi Trent, sorry for the big delay but my job is running wild, i was out for some time but now i'm back and ready to continue the javadoc for Rxtx. Did you used the last javadoc patch i sent you ? let me know if i have to send it to you again or not. regards Fabio From lyon at docjava.com Tue Mar 21 00:51:18 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Tue, 21 Mar 2006 02:51:18 -0500 Subject: [Rxtx] lock files Message-ID: Hi All, You know, if the use of lock files were under Java control (rather than a build-time decision), it might enable a more unified binary distro. It might also facilitate quick prototyping of non-lock file approaches to resolving serial port contention issues (i.e., mac-like approaches vs. linux approaches, etc.). I realize that this is a radical overhaul of the lock file policy issue. Also, it may harm performance. On the other hand, our benchmarks on JNI overhead for modern processors indicate performance impact should be minimal. Perhaps it is more of an issue with the toybox systems. Suppose there were a class with a reasonable default...someone might write: SerialPortLockPolicy.setPolicy(SerialPortLockPolicy.UNIX_LOCK_FILE); SerialPortLockPolicy.setPolicy(SerialPortLockPolicy.NO_LOCK_CHECKING); SerialPortLockPolicy.setPolicy(SerialPortLockPolicy.MAC_STYLE); Thus, we could have a run-time reconfiguration of the serial port lock policy. A special NO_LOCK version of the binary would no longer be required. Any thoughts on this? Thanks! - Doug From joachim at buechse.de Tue Mar 21 03:09:09 2006 From: joachim at buechse.de (Joachim Buechse) Date: Tue, 21 Mar 2006 11:09:09 +0100 Subject: [Rxtx] lock files In-Reply-To: References: Message-ID: <8E12916A-1B9A-4FF2-B684-E2D1C794221B@buechse.de> This is pretty much what I thought about when I suggested, that the default behaviour could be overwritten with a property. I am very much in favor of this approach. In particular this allows much easier debugging for PC based java developers. I think big parts of the Java (and maybe some parts of the C code) could use a bit of a structural workover (unit tests, javadoc, synchronization, etc). Maybe there should be a CVS branch for this experimental version. I'd be happy to contribute a first workover for some of the Java code. Designing for testability and implementing a good bunch of unit tests has been a strategy that worked quite well in the Java projects I lead. And it ultimately allows more liberal change permission. Regards, Joachim On 21.03.2006, at 08:51, Dr. Douglas Lyon wrote: > Hi All, > You know, if the use of lock files were > under Java control (rather than a build-time decision), > it might enable a more unified binary distro. It might also > facilitate quick prototyping of non-lock file approaches > to resolving serial port contention issues (i.e., mac-like > approaches vs. linux approaches, etc.). > > I realize that this is a radical overhaul of the lock file policy > issue. Also, it may harm performance. On the other hand, > our benchmarks on JNI overhead for modern processors indicate > performance impact should be minimal. Perhaps it is more of > an issue with the toybox systems. > > Suppose there were a class with a reasonable default...someone > might write: > SerialPortLockPolicy.setPolicy(SerialPortLockPolicy.UNIX_LOCK_FILE); > SerialPortLockPolicy.setPolicy(SerialPortLockPolicy.NO_LOCK_CHECKING); > SerialPortLockPolicy.setPolicy(SerialPortLockPolicy.MAC_STYLE); > > Thus, we could have a run-time reconfiguration of the serial port lock > policy. A special NO_LOCK version of the binary would no longer > be required. > > Any thoughts on this? > > Thanks! > - Doug > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From joachim at buechse.de Tue Mar 21 06:23:08 2006 From: joachim at buechse.de (Joachim Buechse) Date: Tue, 21 Mar 2006 14:23:08 +0100 Subject: [Rxtx] PATCH: use of ioctl(fd, TIOCEXCL) instead of lockfiles Message-ID: <923AE774-EEA2-4911-92D8-32BB27802C8B@buechse.de> Here is the patch for the ioctl(fd, TIOCEXCL). I have verified this only for OSX 10.4.5, hence it is only defined for APPLE. However, it should work at least for Solaris as well. If a process has requested TIOEXCL further open calls by other user processes will fail. The patch also disables uucp style locking for APPLE. Obviously this is discussable. I think it is the way to go, as it eliminates creating the lock directory which doesnt exist on the standard installation and it eliminates messing with the system group definitions (adding users to group uucp). Regarding the possibility of root processes opening a device which is locked - I consider this a feature not a potential problem. It is highly unlikely, that somebody is crazy enough to run a JavaVM as root (unless he has no other means of getting a restricted IP port opened, ie doesnt understand ipfw). Anyway, even if the process runs as root, it fails when calling ioctl(fd, TIOCEXCL). It could however still open the port to listen for RING events. I.e. a fax server which needs to see incoming calls but otherwise doesnt want to block the port. So the only case where the proposed mechanism fails is, if an incorrectly implemented process running as root conflicts with a user process. I think this can be accepted. Regards, Joachim PS: If this patch is generally accepted, the installer and Mac doku should obviously be changed as well. Index: SerialImp.c =================================================================== RCS file: /usr/local/cvsroot/rxtx-devel/src/SerialImp.c,v retrieving revision 1.46.2.187 diff -u -r1.46.2.187 SerialImp.c --- SerialImp.c 29 Jan 2006 22:19:04 -0000 1.46.2.187 +++ SerialImp.c 21 Mar 2006 12:59:16 -0000 @@ -656,6 +656,25 @@ fd=OPEN (filename, O_RDWR | O_NOCTTY | O_NONBLOCK ); } while (fd < 0 && errno==EINTR); +#ifdef OPEN_EXCL + // Note that open() follows POSIX semantics: multiple open() calls to + // the same file will succeed unless the TIOCEXCL ioctl is issued. + // This will prevent additional opens except by root-owned processes. + // See tty(4) ("man 4 tty") and ioctl(2) ("man 2 ioctl") for details. + + if (fd >= 0 && (ioctl(fd, TIOCEXCL) == -1)) + { + sprintf( message, "open: exclusive access denied for % s\n", + filename ); + report( message ); + report_error( message ); + + close(fd); + goto fail; + } +#endif /* OPEN_EXCL */ + + if( configure_port( fd ) ) goto fail; (*env)->ReleaseStringUTFChars( env, jstr, filename ); sprintf( message, "open: fd returned is %i\n", fd ); Index: SerialImp.h =================================================================== RCS file: /usr/local/cvsroot/rxtx-devel/src/SerialImp.h,v retrieving revision 1.11.2.49 diff -u -r1.11.2.49 SerialImp.h --- SerialImp.h 5 Jul 2005 17:47:21 -0000 1.11.2.49 +++ SerialImp.h 21 Mar 2006 12:59:17 -0000 @@ -135,7 +135,8 @@ /*# define LOCKDIR "/var/spool/uucp"*/ # define LOCKDIR "/var/lock" # define LOCKFILEPREFIX "LK." -# define UUCP +/*# define UUCP*/ +# define OPEN_EXCL #endif /* __APPLE__ */ #if defined(__NetBSD__) # define DEVICEDIR "/dev/" From tjarvi at qbang.org Tue Mar 21 10:26:08 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 21 Mar 2006 10:26:08 -0700 (MST) Subject: [Rxtx] Javadoc on the go In-Reply-To: <441FA98B.9050701@ngi.it> References: <441FA98B.9050701@ngi.it> Message-ID: On Tue, 21 Mar 2006, Fabio Frumento wrote: > Hi Trent, > > sorry for the big delay but my job is running wild, i was out for some > time but now i'm back and ready to continue the javadoc for Rxtx. > > Did you used the last javadoc patch i sent you ? let me know if i have to > send it to you again or not. > > regards > > Fabio Hi Fabio The patch is in the rxtx mail-list archives. It will be going in soon. I did not see a time critical portion. I'll probably be going through the list since the last batch of patches this weekend and putting them into CVS. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Tue Mar 21 10:57:18 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 21 Mar 2006 10:57:18 -0700 (MST) Subject: [Rxtx] jvm issue In-Reply-To: <20060321065524.94779.qmail@web50701.mail.yahoo.com> References: <20060321065524.94779.qmail@web50701.mail.yahoo.com> Message-ID: On Mon, 20 Mar 2006, Lambok Sianturi wrote: > Hi All, > This is my first time to join RxTx mailing list. I thank you all for allowing others to sign in in requests help. > I use the latest RxTx lib in Fedora 3 with java version 1.4.2_09 b05. And I got this error: > > # > # An unexpected error has been detected by HotSpot Virtual Machine: > # > # SIGSEGV (0xb) at pc=0x00bf27f3, pid=2633, tid=3086112448 > # > # Java VM: Java HotSpot(TM) Client VM (1.4.2_09-b05 mixed mode) > # Problematic frame: > # C [ld-linux.so.2+0xa7f3] A native library loading error? What happens if you recompile rxtx on your system and install that? This sounds like an ABI problem? rxtx 2.1-7 was compiled with a gcc 2.96 toolchain as I recall. The hope is newer system will be backwards compatible. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Tue Mar 21 11:05:29 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 21 Mar 2006 11:05:29 -0700 (MST) Subject: [Rxtx] PATCH: use of ioctl(fd, TIOCEXCL) instead of lockfiles In-Reply-To: <923AE774-EEA2-4911-92D8-32BB27802C8B@buechse.de> References: <923AE774-EEA2-4911-92D8-32BB27802C8B@buechse.de> Message-ID: On Tue, 21 Mar 2006, Joachim Buechse wrote: > Here is the patch for the ioctl(fd, TIOCEXCL). I have verified this only > for OSX 10.4.5, hence it is only defined for APPLE. However, it should > work at least for Solaris as well. > > If a process has requested TIOEXCL further open calls by other user > processes will fail. > > The patch also disables uucp style locking for APPLE. Obviously this is > discussable. I think it is the way to go, as it eliminates creating the > lock directory which doesnt exist on the standard installation and it > eliminates messing with the system group definitions (adding users to > group uucp). > > Regarding the possibility of root processes opening a device which is > locked - I consider this a feature not a potential problem. It is highly > unlikely, that somebody is crazy enough to run a JavaVM as root (unless > he has no other means of getting a restricted IP port opened, ie doesnt > understand ipfw). Anyway, even if the process runs as root, it fails when > calling ioctl(fd, TIOCEXCL). It could however still open the port to > listen for RING events. I.e. a fax server which needs to see incoming > calls but otherwise doesnt want to block the port. So the only case where > the proposed mechanism fails is, if an incorrectly implemented process > running as root conflicts with a user process. I think this can be > accepted. > > Regards, > Joachim > > PS: If this patch is generally accepted, the installer and Mac doku > should obviously be changed as well. > > > Index: SerialImp.c > =================================================================== > RCS file: /usr/local/cvsroot/rxtx-devel/src/SerialImp.c,v > retrieving revision 1.46.2.187 > diff -u -r1.46.2.187 SerialImp.c > --- SerialImp.c 29 Jan 2006 22:19:04 -0000 1.46.2.187 > +++ SerialImp.c 21 Mar 2006 12:59:16 -0000 > @@ -656,6 +656,25 @@ > fd=OPEN (filename, O_RDWR | O_NOCTTY | O_NONBLOCK ); > } while (fd < 0 && errno==EINTR); > > +#ifdef OPEN_EXCL > + // Note that open() follows POSIX semantics: multiple open() > calls to > + // the same file will succeed unless the TIOCEXCL ioctl is > issued. > + // This will prevent additional opens except by root-owned > processes. > + // See tty(4) ("man 4 tty") and ioctl(2) ("man 2 ioctl") for > details. > + > + if (fd >= 0 && (ioctl(fd, TIOCEXCL) == -1)) > + { > + sprintf( message, "open: exclusive access denied for % > s\n", > + filename ); > + report( message ); > + report_error( message ); > + > + close(fd); > + goto fail; > + } > +#endif /* OPEN_EXCL */ > + > + > if( configure_port( fd ) ) goto fail; > (*env)->ReleaseStringUTFChars( env, jstr, filename ); > sprintf( message, "open: fd returned is %i\n", fd ); > Index: SerialImp.h > =================================================================== > RCS file: /usr/local/cvsroot/rxtx-devel/src/SerialImp.h,v > retrieving revision 1.11.2.49 > diff -u -r1.11.2.49 SerialImp.h > --- SerialImp.h 5 Jul 2005 17:47:21 -0000 1.11.2.49 > +++ SerialImp.h 21 Mar 2006 12:59:17 -0000 > @@ -135,7 +135,8 @@ > /*# define LOCKDIR "/var/spool/uucp"*/ > # define LOCKDIR "/var/lock" > # define LOCKFILEPREFIX "LK." > -# define UUCP > +/*# define UUCP*/ > +# define OPEN_EXCL > #endif /* __APPLE__ */ > #if defined(__NetBSD__) > # define DEVICEDIR "/dev/" > This looks like a good start. What do you think Dmitry? Perhaps all systems with TIOCEXCL defined should use that though. Even if they use lockfiles. It wont hurt anything. That would catch people hacking their own serial apps without checking lockfiles. Its a good idea to avoid C++ style comments in the C portions. Some older systems don't deal with them well. If it's just for Mac OS X, it isn't a big deal. I think it was the Irix compiler that was problematic? -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Tue Mar 21 11:22:05 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 21 Mar 2006 11:22:05 -0700 (MST) Subject: [Rxtx] lock files In-Reply-To: <8E12916A-1B9A-4FF2-B684-E2D1C794221B@buechse.de> References: <8E12916A-1B9A-4FF2-B684-E2D1C794221B@buechse.de> Message-ID: We can try it. Maybe the JNI is much improved. The nice thing about linking into liblock is distros then worry about lockfiles on their systems. This way, we have to deal with any changes that may show up. On Tue, 21 Mar 2006, Joachim Buechse wrote: > This is pretty much what I thought about when I suggested, that the > default behaviour could be overwritten with a property. I am very much in > favor of this approach. In particular this allows much easier debugging > for PC based java developers. > > I think big parts of the Java (and maybe some parts of the C code) could > use a bit of a structural workover (unit tests, javadoc, synchronization, > etc). Maybe there should be a CVS branch for this experimental version. > I'd be happy to contribute a first workover for some of the Java code. > Designing for testability and implementing a good bunch of unit tests has > been a strategy that worked quite well in the Java projects I lead. And > it ultimately allows more liberal change permission. > > Regards, > Joachim > > > On 21.03.2006, at 08:51, Dr. Douglas Lyon wrote: > >> Hi All, >> You know, if the use of lock files were >> under Java control (rather than a build-time decision), >> it might enable a more unified binary distro. It might also >> facilitate quick prototyping of non-lock file approaches >> to resolving serial port contention issues (i.e., mac-like >> approaches vs. linux approaches, etc.). >> >> I realize that this is a radical overhaul of the lock file policy >> issue. Also, it may harm performance. On the other hand, >> our benchmarks on JNI overhead for modern processors indicate >> performance impact should be minimal. Perhaps it is more of >> an issue with the toybox systems. >> >> Suppose there were a class with a reasonable default...someone >> might write: >> SerialPortLockPolicy.setPolicy(SerialPortLockPolicy.UNIX_LOCK_FILE); >> SerialPortLockPolicy.setPolicy(SerialPortLockPolicy.NO_LOCK_CHECKING); >> SerialPortLockPolicy.setPolicy(SerialPortLockPolicy.MAC_STYLE); >> >> Thus, we could have a run-time reconfiguration of the serial port lock >> policy. A special NO_LOCK version of the binary would no longer >> be required. >> >> Any thoughts on this? >> >> Thanks! >> - Doug >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From dmarkman at mac.com Tue Mar 21 16:05:17 2006 From: dmarkman at mac.com (Dmitry Markman) Date: Tue, 21 Mar 2006 18:05:17 -0500 Subject: [Rxtx] PATCH: use of ioctl(fd, TIOCEXCL) instead of lockfiles In-Reply-To: References: <923AE774-EEA2-4911-92D8-32BB27802C8B@buechse.de> Message-ID: <512AC70C-BB86-48F2-A83C-023F35C23BAB@mac.com> I think it's cool, but I'd like to have that property implementation when user can choose between locking mechanism about comments: it's easy to change comments to the C style or we can use extensions of the file to cpp so c++ compiler will be used On Mar 21, 2006, at 1:05 PM, Trent Jarvi wrote: > This looks like a good start. What do you think Dmitry? Perhaps > all systems with TIOCEXCL defined should use that though. Even if > they use lockfiles. It wont hurt anything. That would catch > people hacking their own serial apps without checking lockfiles. > > Its a good idea to avoid C++ style comments in the C portions. > Some older systems don't deal with them well. If it's just for Mac > OS X, it isn't a big deal. I think it was the Irix compiler that > was problematic? Dmitry Markman From dmarkman at mac.com Tue Mar 21 16:13:00 2006 From: dmarkman at mac.com (Dmitry Markman) Date: Tue, 21 Mar 2006 18:13:00 -0500 Subject: [Rxtx] PATCH: use of ioctl(fd, TIOCEXCL) instead of lockfiles In-Reply-To: References: <923AE774-EEA2-4911-92D8-32BB27802C8B@buechse.de> Message-ID: I'd like to add that creating locking folder isn't a big deal we never had a problem related to the lock folders, because we always used installer on mac os x from other hand I'm not very much familiar with iotcl locking approach and I'm not sure it's more efficient Joachim wrote "I think it is the way to go, as it eliminates creating the lock directory which doesnt exist on the standard installation and it eliminates messing with the system group definitions (adding users to group uucp)." but I really didn't have any problem with that 1. doesn't exist on the standard installation there are many-many things that don't exist in the standard installation so I don't think that argument is strong enough 2. messing with the system group definitions I don't think we're messing with the group definition mac os x provides very clear way to set up group's members and together with Greg Guerin AuthKit there is no problem to set those definitions so I don't think that argument is strong either but from other hand using iotcl is more promising and is more elegant On Mar 21, 2006, at 1:05 PM, Trent Jarvi wrote: > > This looks like a good start. What do you think Dmitry? Perhaps > all systems with TIOCEXCL defined should use that though. Even if > they use lockfiles. It wont hurt anything. That would catch > people hacking their own serial apps without checking lockfiles. Dmitry Markman From joachim at buechse.de Wed Mar 22 04:46:45 2006 From: joachim at buechse.de (Joachim Buechse) Date: Wed, 22 Mar 2006 12:46:45 +0100 Subject: [Rxtx] PATCH: use of ioctl(fd, TIOCEXCL) instead of lockfiles In-Reply-To: References: <923AE774-EEA2-4911-92D8-32BB27802C8B@buechse.de> Message-ID: Sorry, I was not very clear with my arguments, so I will try again;-) Please, don't take this as an attack against work that has been done. I think the contributions that have been made in the past were made in a good spirit. But I really believe, that the current solution for OSX has many shortcomings and should be changed as soon as possible. lock files --- The /var/lock folder does not exist on the standard OSX installation, however the standard installation includes several applications that use serial ports (i.e. the FAX capability). This indicates, that the lock folder approach will not work well with system components. Applications for OSX will generally try to live in harmony with system components (except for HP print drivers of course). I think RXTX should follow this approach as well. uucp group --- Accessing serial ports is not an admin privileged operation on OSX. Any user (world) has read/write privileges on /dev/tty*. So the system default is to not enforce any group membership to access these ports. The group uucp however is a system group on all unix systems I know. It exists for certain system processes. A non admin user should in general not be a member of this group. Quite arguably no user should ever be a member of this group. Installer --- My general opinion is, that - no Installer should touch user or group data without warning - no Application Installer should touch groups which are not specific to the very application installed - no Installer should ever add regular users to a system group The current installer injects the installing user in the group uucp without warning about this change and without giving the option to "opt out" of this change. This is a potential security risk (but not currently a real one, as OSX contains no folders belonging to group uucp). The current installer does not work for multi user systems. It puts the installing user in the uucp group. However the installing user is not necessarily the user that will use the application. Putting all users that may use a serial port application in the system group uucp seems like a very invasive approach to me. Besides that, newly created users will not automatically be in the group and hence, serial applications will "break" for new users without obvious reasons. Avoiding the lock files will allow self contained applications (i.e. drag&drop installation). In my eyes this is largely preferable over an installer that requests admin privileges. Adding up all these points indicates very strongly, that the lock-file implementation is not the way to go on OSX. Regards, Joachim On 22.03.2006, at 00:13, Dmitry Markman wrote: > I'd like to add that > > creating locking folder isn't a big deal > we never had a problem related to the lock folders, because we > always used installer on mac os x > from other hand I'm not very much familiar with iotcl locking > approach and I'm not sure it's more efficient > > Joachim wrote "I think it is the way to go, as it eliminates > creating the lock directory which doesnt exist on the standard > installation and it eliminates messing with the system group > definitions (adding users to group uucp)." but I really didn't have > any problem with that > > 1. doesn't exist on the standard installation > there are many-many things that don't exist in the standard > installation so I don't think that argument is strong enough > 2. messing with the system group definitions > I don't think we're messing with the group definition > mac os x provides very clear way to set up group's members and > together with Greg Guerin AuthKit there is no problem to set those > definitions > so I don't think that argument is strong either > but from other hand using iotcl is more promising and is more elegant > > > > On Mar 21, 2006, at 1:05 PM, Trent Jarvi wrote: > >> >> This looks like a good start. What do you think Dmitry? Perhaps >> all systems with TIOCEXCL defined should use that though. Even if >> they use lockfiles. It wont hurt anything. That would catch >> people hacking their own serial apps without checking lockfiles. > > Dmitry Markman > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From dmarkman at mac.com Wed Mar 22 05:27:13 2006 From: dmarkman at mac.com (Dmitry Markman) Date: Wed, 22 Mar 2006 07:27:13 -0500 Subject: [Rxtx] PATCH: use of ioctl(fd, TIOCEXCL) instead of lockfiles In-Reply-To: References: <923AE774-EEA2-4911-92D8-32BB27802C8B@buechse.de> Message-ID: <83440CF3-DCD8-41C1-B941-F227232C27E3@mac.com> thanks for the very good explanation I didn't think that you were attacking any thing, so don't worry I just had feeling, that there were more aesthetic reasons for going to ioctl then real necessity now you explained everything quite well (BTW, asfar as I remember installer asks admin password so it wasn't quiet, but it really doesn't matter now) thanks On Mar 22, 2006, at 6:46 AM, Joachim Buechse wrote: > Sorry, I was not very clear with my arguments, so I will try again;-) > > Please, don't take this as an attack against work that has been > done. I think the contributions that have been made in the past > were made in a good spirit. But I really believe, that the current > solution for OSX has many shortcomings and should be changed as > soon as possible. > > lock files > --- > The /var/lock folder does not exist on the standard OSX > installation, however the standard installation includes several > applications that use serial ports (i.e. the FAX capability). This > indicates, that the lock folder approach will not work well with > system components. Applications for OSX will generally try to live > in harmony with system components (except for HP print drivers of > course). I think RXTX should follow this approach as well. > > uucp group > --- > Accessing serial ports is not an admin privileged operation on OSX. > Any user (world) has read/write privileges on /dev/tty*. So the > system default is to not enforce any group membership to access > these ports. The group uucp however is a system group on all unix > systems I know. It exists for certain system processes. A non admin > user should in general not be a member of this group. Quite > arguably no user should ever be a member of this group. > > Installer > --- > My general opinion is, that > - no Installer should touch user or group data without warning > - no Application Installer should touch groups which are not > specific to the very application installed > - no Installer should ever add regular users to a system group > > The current installer injects the installing user in the group uucp > without warning about this change and without giving the option to > "opt out" of this change. This is a potential security risk (but > not currently a real one, as OSX contains no folders belonging to > group uucp). > > The current installer does not work for multi user systems. It puts > the installing user in the uucp group. However the installing user > is not necessarily the user that will use the application. Putting > all users that may use a serial port application in the system > group uucp seems like a very invasive approach to me. Besides that, > newly created users will not automatically be in the group and > hence, serial applications will "break" for new users without > obvious reasons. > > > Avoiding the lock files will allow self contained applications > (i.e. drag&drop installation). In my eyes this is largely > preferable over an installer that requests admin privileges. Adding > up all these points indicates very strongly, that the lock-file > implementation is not the way to go on OSX. > > Regards, > Joachim > > > On 22.03.2006, at 00:13, Dmitry Markman wrote: > >> I'd like to add that >> >> creating locking folder isn't a big deal >> we never had a problem related to the lock folders, because we >> always used installer on mac os x >> from other hand I'm not very much familiar with iotcl locking >> approach and I'm not sure it's more efficient >> >> Joachim wrote "I think it is the way to go, as it eliminates >> creating the lock directory which doesnt exist on the standard >> installation and it eliminates messing with the system group >> definitions (adding users to group uucp)." but I really didn't >> have any problem with that >> >> 1. doesn't exist on the standard installation >> there are many-many things that don't exist in the standard >> installation so I don't think that argument is strong enough >> 2. messing with the system group definitions >> I don't think we're messing with the group definition >> mac os x provides very clear way to set up group's members and >> together with Greg Guerin AuthKit there is no problem to set those >> definitions >> so I don't think that argument is strong either >> but from other hand using iotcl is more promising and is more elegant >> >> >> >> On Mar 21, 2006, at 1:05 PM, Trent Jarvi wrote: >> >>> >>> This looks like a good start. What do you think Dmitry? Perhaps >>> all systems with TIOCEXCL defined should use that though. Even >>> if they use lockfiles. It wont hurt anything. That would catch >>> people hacking their own serial apps without checking lockfiles. >> >> Dmitry Markman >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx Dmitry Markman From lyon at docjava.com Wed Mar 22 06:12:18 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Wed, 22 Mar 2006 08:12:18 -0500 Subject: [Rxtx] sole of a new design pattern Message-ID: Hi All, I have been thinking about how we design the serial port software. I think we need a new design pattern. For lack of a better term, I shall call it: The Parametric Singleton Design Pattern By Douglas A. Lyon ABSTRACT The goal of the singleton design pattern is to make sure that there is one, and only one, instance of a given class. The goal of the parametric singleton design pattern is to make sure that there is one, and only one, instance of a given class with the given parametric values. We parametric singleton design pattern combines the singleton design pattern with a parameter that enables unique creation of instances of a class. These instances are cached. When a user asks for an instance with these parameters, the cache is checked. If the instance is in the cache, the instance is returned, otherwise it is created, added to the cache and then returned. We apply our parametric singleton design pattern to the retrieval of RMI registries bound to a given port. The goal of our system is to make sure that no two RMI registries are listening to the same socket and to make use of the RMI registries after they have been created. RMI registries are used in distributed computation. Introduction The singleton design pattern is meant to ensure that on a single instance of a class exists. It is also meant to provide a global point of access to it. The intent of the parametric singleton design pattern is to ensure that a class has only one instance for a given set of parameter values. It also provides a global point of access to it. Motivation A system cannot tolerate multiple instances of some classes with identical parameters. For example, you cannot have two instances making use of the same serial port, at the same time. You cannot have two instances that are trying to listen to the same socket connection. You cannot have two instances writing to the same file structure at the same time. As the operating system is often thought of as the arbiter of consumed resources (i.e., tape drives, serial ports, etc.) we frequently leave it to an operating system implementation to resolve these contention issues. Even for similar resources (like serial ports) there are few standards for handling contention. For example, serial ports on Linux are locked using a "/var/lock" file. POSIX, on the other hand, uses ioctl mechanisms to prevent contention. A better solution is to make a class that is responsible for keeping track of the instances created from the class. The class is declared final, so that it cannot be subclassed. The class also has a private constructor, so that other classes cannot instance it. The new design pattern is called the parametric singleton design pattern and it provides a way to access and create instances with given parameters. Applicability Use the Parametric Singleton Design Pattern when: 1. There must be exactly one instance of a class with the given parameters. 2. The instances must be accessible to clients from a well-known access point. Structure Insert UML diagram here. Participants The Parametric Singleton Clients that need instances 1. The Parametric Singleton defines an instance upon request from a client, if, and only if, the instance does not already exist. 2. The Parametric Singleton returns the instance to the client. 3. The Parametric Singleton is responsible for creating unique instances from given parameters. Collaborations Clients obtain a reference to a Parametric Singleton instance only through the parametric singleton design pattern. If the instance is left in an improper state (e.g., the serial port was left open) it is NOT the role of the Parametric Singleton Design Pattern to close the IO port. Nor is it the role of the Parametric Singleton Design Pattern to open the port. That role is delegate to some other part of the system. Further, it is not the role of the Parametric Singleton Design Pattern to check out resources. That is, multiple threads can have multiple references to the same resource at the same time. MUTEX locking is delegated to some other part of the system. Consequences The Parametric Singleton Design Pattern has several benefits: 1. Controlled access to parametrically defined instances. Since the Parametric Singleton class encapsulates its instances, there is control over how and when clients access it. 2. Reduced name space. The Parametric Singleton pattern avoids global variables that store instances created from the same parameter. Implementation Here are implementation issues to consider when using the Parametric Singleton pattern: 1. Unique mapping of parameters. The Parametric Singleton pattern requires that there be a mean to isomorphically map the parameter space into the instance space and back again. 2. Ensure unique instances. The Parametric Singleton pattern makes unique instances from parameters, and it does so only once. 3. Cache instances for fast retrieval. The Parametric Singleton pattern must be able to look up instances, given some set of parameters, and do so from some data structure. That is, there must be enough space to hold references to all the instances the program will need. Also, a mechanism is needed to look up and retrieve the instances quickly enough to satisfy the clients. Sample Code public final class ParametricSingletonRmiRegistry { private static Hashtable registry = new Hashtable(100); // use singleton pattern and??????????????????????????????????????????????? // prevent instantiation of RmiRegistryUtils.?????????????????????????????? private ParametricSingletonRmiRegistry() { } // the only instance of the Registry held by the RmiRegistryUtils?????????? public static void listNames(Integer port) { if (!isInCacheAndRunning(port)) return; Registry r = (Registry) registry.get(port); System.out.println("registry on port: " + port); System.out.println("registry: " + r); System.out.println("names: "); try { print(r.list()); } catch (RemoteException e) { In.message(e); } System.out.println("------------------------"); } /**???????????????????????????????????????????????????????????????????????? * Checks whether a Registry has been started on this host????????????????? * in the specified port.?????????????????????????????????????????????????? * If not, it tries to start one.?????????????????????????????????????????? * when it fails to start a Registry, it exits the program????????????????? * with exit code 1.??????????????????????????????????????????????????????? */ public static void restart(int port) { if (isInCacheAndRunning(port)) return; try { startRegistry(port); } catch (RemoteException e) { In.message(e); } } /**???????????????????????????????????????????????????????????????????????? * @param port????????????????????????????????????????????????????????????? * @return true if registry is in cache and running???????????????????????? */ private static boolean isInCacheAndRunning(Integer port) { if (!isRegistryRunning(port.intValue())) return false; if (!isRegistryInCache(port.intValue())) return false; return true; } /**???????????????????????????????????????????????????????????????????????? * @param port????????????????????????????????????????????????????????????? * @return true if we are able to locate a local registry on port.??????????????????????????????????????????????????????????????????????????? */ private static boolean isRegistryRunning(int port) { try { Registry r = LocateRegistry.getRegistry(port); if (r != null) return true; } catch (RemoteException e) { return false; } return false; } /**???????????????????????????????????????????????????????????????????????? * @param port????????????????????????????????????????????????????????????? * @return return true if registry is in cache????????????????????????????? */ private static boolean isRegistryInCache(int port) { if (registry.get(new Integer(port)) == null) return false; return true; } /**???????????????????????????????????????????????????????????????????????? * Restart the registry, if needed.???????????????????????????????????????? * Return the only instance of the registry for consistent global?????????? * using by making use of the Singleton Design Pattern????????????????????? *????????????????????????????????????????????????????????????????????????? * @return the internally held registry instance.?????????????????????????? */ public static Registry getRegistry(Integer port) { restart(port); return (Registry) registry.get(port); } private static void startRegistry(Integer port) throws RemoteException { Registry r; try { r = LocateRegistry.createRegistry(port.intValue()); registry.put(port, r); //r = new sun.rmi.registry.RegistryImpl???????????????????????????? /// (port.intValue());?????????????????????????????????????? // registry.put(port, r);?????????????????????????????????????????? } catch (Exception e) { //e.printStackTrace();????????????????????????????????????????????? r = LocateRegistry.getRegistry(port.intValue()); registry.put(port, r); } } public static void main(String args[]) throws RemoteException { //restart(port);??????????????????????????????????????????????????????? restart(5001); restart(5002); restart(5002); Registry r = LocateRegistry.getRegistry(5002); System.out.println("registry="+r); } } I would very much like to get your feedback on this new design pattern idea. Thank you for your time. Regards, - Doug From david.garnier at trusted-logic.com Wed Mar 22 07:36:10 2006 From: david.garnier at trusted-logic.com (David Garnier) Date: Wed, 22 Mar 2006 15:36:10 +0100 Subject: [Rxtx] sole of a new design pattern In-Reply-To: References: Message-ID: <442160DA.80107@trusted-logic.com> Hello, > The Parametric Singleton Design Pattern The Singleton is the most abused design pattern ever. Good use-cases for this pattern are extremely rare and mostly confined to problems related to hardware resources, like serial ports. > Applicability > > Use the Parametric Singleton Design Pattern when: > 1. There must be exactly one instance of a class with the given > parameters. OK. As I said above, this case this actually very unusual. The Singleton pattern is mostly used when : > 2. The instances must be accessible to clients from a well-known > access point. Using the singleton pattern in this case is just convenient for the programmer. Problems arises pretty quickly, especially if you attempt to unit-test your classes. 1) If your singleton is stateful, or hold on to stateful objects, it means that two different unit tests are not actually independent. Instead of starting with a brand new environment, the result of a test may be affected by the result of a previous test. This problem also arise when with your class relies on a database. In both cases, the solution is to reset your "unique" resource (Singleton or database) at the beginning of the test, which is a pain. Also, while most projects connect to a single database, projects that allow the use of Singletons usually contain several of thems, and new ones may cropped up unnoticed. You quickly end up with test cases that only pass in a certain order, which is a royal pain. 2) You cannot mockup a singleton. Once everyone calls the SomeSingleton class statically, you can't replace your class by SomeSingletonMockup. Furthermore, even for hardware services, the Singleton pattern does not really prevent concurrent accesses. If you start the same program in two different JVMs, unless they somehow shared the state of their "Singletons" (through lock files for example), the Singleton pattern will not prevent concurrent access. Our application uses RXTX, and we routinely encounter cases where another (native) application has already locked the port. Since we cannot modify the native application to recognize lock files, OS-level control is irreplaceable. > > Consequences > The Parametric Singleton Design Pattern has several benefits: > > 1. Controlled access to parametrically defined instances. Since > the Parametric Singleton class encapsulates its instances, there is > control over how and when clients access it. Not really. Once you've returned the instance to a client, you've lost control over it. The client can to whatever it wants with it. You cannot "recall" the instance or claim it back. > 2. Reduced name space. The Parametric Singleton pattern avoids > global variables that store instances created from the same parameter. Sure, but you don't have to rely on a Singleton for that. Just create a single Factory. > I would very much like to get your feedback on this new design > pattern idea. Well, it's nothing new. Some may say that it is the point of design patterns: formalizes the designs that occur again and again. However, this design is simply a combination of the Singleton and Factory patterns. I did use it in the past, but now I've been exposed to the shortcomings of the Singleton pattern, so I limit myself to Factories. Regards, David From sean_montgomery at baseview.com Wed Mar 22 08:35:28 2006 From: sean_montgomery at baseview.com (Sean Montgomery) Date: Wed, 22 Mar 2006 10:35:28 -0500 Subject: [Rxtx] sole of a new design pattern In-Reply-To: <442160DA.80107@trusted-logic.com> References: <442160DA.80107@trusted-logic.com> Message-ID: <05769CA7-A51B-4CF0-BAA0-E02DD905F5A4@baseview.com> On Mar 22, 2006, at 9:36 AM, David Garnier wrote: > Furthermore, even for hardware services, the Singleton pattern does > not really prevent concurrent > accesses. If you start the same program in two different JVMs, > unless they somehow shared the state > of their "Singletons" (through lock files for example), the > Singleton pattern will not prevent > concurrent access. > Multiple class loaders in a single JVM can be tricky, too. Then there's synchronization, lazy initialization and serialization of singletons to contend with. Bloch's Effective Java covers these, and here's a few articles: http://www.javaworld.com/javaworld/jw-04-2003/jw-0425-designpatterns- p3.html http://java.sun.com/developer/technicalArticles/Programming/singletons/ Just FYI :-) From lyon at docjava.com Wed Mar 22 08:50:48 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Wed, 22 Mar 2006 10:50:48 -0500 Subject: [Rxtx] sole of a new design pattern In-Reply-To: <442160DA.80107@trusted-logic.com> References: <442160DA.80107@trusted-logic.com> Message-ID: Hi All, First, I would like to thank David for his prompt and thoughtful remarks. I had no idea people that feel strongly about a design patterns! Wow! Feedback (particularly critical feedback) is greatly appreciated. Starting at the end, first: >I did use it in >the past, but now I've been exposed to the shortcomings of the >Singleton pattern, so I limit myself to Factories. David, if I understood your comments correctly, you suggested that Factories can be used in leu of the Singleton Design Pattern, or even the Parametric Singleton Design Pattern. As I see in [Gof]: Factory Method: Intent "Define an interface for creating an object, but let subclasses decide which class to instantiate. Factory Method lets a class defer instantiation to subclasses." The Singleton Design Pattern is a concrete class, which is rather different, right? Also, subclasses are not permitted with Singleton, as they are final. Naturally, I could use an abstract factory as a parent for a singleton. I could even design a facade that could be implemented with the singleton....but that is not the intention of the design. Unless you want a mock-up, as discussed, below: More below: >Hello, > >> The Parametric Singleton Design Pattern > >The Singleton is the most abused design pattern ever. Good use-cases >for this pattern are extremely >rare and mostly confined to problems related to hardware resources, >like serial ports. > > >> Applicability >> >> Use the Parametric Singleton Design Pattern when: >> 1. There must be exactly one instance of a class with the given >> parameters. >OK. As I said above, this case this actually very unusual. The >Singleton pattern is mostly used when : >> 2. The instances must be accessible to clients from a well-known >> access point. > >Using the singleton pattern in this case is just convenient for the >programmer. Problems arises >pretty quickly, especially if you attempt to unit-test your classes. > >1) If your singleton is stateful, or hold on to stateful objects, it >means that two different unit >tests are not actually independent. Instead of starting with a brand >new environment, the result of >a test may be affected by the result of a previous test. This >problem also arise when with your >class relies on a database. In both cases, the solution is to reset >your "unique" resource >(Singleton or database) at the beginning of the test, which is a >pain. Also, while most projects >connect to a single database, projects that allow the use of >Singletons usually contain several of >thems, and new ones may cropped up unnoticed. You quickly end up >with test cases that only pass in a >certain order, which is a royal pain. There are basic problems with communicating finite state machines that include reachability and deadlock analysis. These are addressed with petri net analysis and are beyond the scope of the design pattern. As you quite rightly pointed out; the parametric singleton pattern (or the singleton pattern, for that matter) enable multiple threads to gain access to the same instance. The only way that I can see to block others from gaining access to the reference is the synchronize keyword. This is putting a spin-lock (or MUTEX) on the reference. The question of how to unit-test a design pattern like the parametric singleton remains open. Perhaps this is a deficiency. > >2) You cannot mockup a singleton. Once everyone calls the >SomeSingleton class statically, you can't >replace your class by SomeSingletonMockup. Acutally, I am not sure that this is true. If the Singleton implements a Facade interface, it should be possible to make the replacement. Right? > >Furthermore, even for hardware services, the Singleton pattern does >not really prevent concurrent >accesses. If you start the same program in two different JVMs, >unless they somehow shared the state >of their "Singletons" (through lock files for example), the >Singleton pattern will not prevent >concurrent access. Good Point!! You have sharp eyes! The singleton design pattern should/could take responsibility for this. In fact, you may notice that my code does have an implementation (LocateRegistry) that can work across JVM's. The LocateRegistry will even work across the Internet! LocateRegistry takes both a host name and a Port (lock files just don't do this). I did not think to implement this beyond the local machine, but, in its present form, it will work across different processes. > >Our application uses RXTX, and we routinely encounter cases where >another (native) application has >already locked the port. Since we cannot modify the native >application to recognize lock files, >OS-level control is irreplaceable. The singleton design pattern is not meant to replace OS-level control, but to centralize the Java programmers access to it. If lock files, for example, are used for serial ports, the Singleton Design Pattern should be able to work with them. > > >> >> Consequences >> The Parametric Singleton Design Pattern has several benefits: >> > > 1. Controlled access to parametrically defined instances. Since >> the Parametric Singleton class encapsulates its instances, there is >> control over how and when clients access it. > >Not really. Once you've returned the instance to a client, you've >lost control over it. The client >can to whatever it wants with it. You cannot "recall" the instance >or claim it back. Good point, this should read: > 1. Controll when parametrically defined instances are created. Since > > the Parametric Singleton class encapsulates its instances, there is > > control over how and when they are instanced. > >> 2. Reduced name space. The Parametric Singleton pattern avoids >> global variables that store instances created from the same parameter. > >Sure, but you don't have to rely on a Singleton for that. Just >create a single Factory. > > Thank you for your thoughtful and prompt response! Regards, - Doug From dmarkman at mac.com Wed Mar 22 21:21:55 2006 From: dmarkman at mac.com (Dmitry Markman) Date: Wed, 22 Mar 2006 23:21:55 -0500 Subject: [Rxtx] sole of a new design pattern In-Reply-To: <442160DA.80107@trusted-logic.com> References: <442160DA.80107@trusted-logic.com> Message-ID: I don't think I get it On Mar 22, 2006, at 9:36 AM, David Garnier wrote: > Using the singleton pattern in this case is just convenient for the > programmer. Problems arises > pretty quickly, especially if you attempt to unit-test your classes. so you're saying that something isn't so good because you can not test it in the convenient way? if that's true, I'm totally disagree change your test, debug whatever, but if software is efficient at runtime, works fine and only problem is some unit test (which is some kind of framework for testing) then dump that unit test , dump that unit framework and make something appropriate to the software you're testing so if Douglas want to use singletons, what's the problem? and what do you mean by abusing of singleton usage? of course singleton doesn't prevent concurrent access to the resource across the processes unless you're using some OS facility to prevent it, besides singleton as it was introduced is relevant only and only inside of the same process otherwise it's not singleton it's something else (let's say network singleton: so you have remote invocation facility and some factory method that return object created by that facility) I don't have any problem with using any kind of singletons. Parametric Singleton idea (if I understand it right) could be easily implemented in the following way: use a map populate map with instances of some class and key is your parameter (you can use lazy population too) if somebody ask the key check the value if it's null so resource is taken if somebody returns the resource put it back to the map public synchronized static Object getSomeResource(Object parameter); public synchronized static void returnResource(Object parameter); getSomeResource (inside of the same process) could return null in 2 cases 1. if somebody (from other thread for example) already took that resource 2. if OS API said that resource corresponded to that parameter (serial port with parameter = 1 (port #)) is locked and unavailable; I'm not sure that in case of serial ports we even need those Parametric Singletons (unless lock checking is a very expensive operation) just ask the OS about availability of that resource and if it's available give it away and then OS will lock it and therefore in next time somebody ask it just answer that resource is locked and return null for example system has 2 serial ports available so I ask getResource("tty"); or I ask getResource("Bluetooth-Modem"); and if OS is ok you can give tty or Bluetooth-Modem or both no need for any additional pattern I think back to the problem mac os x doesn't recognize locking via files, so it handles locking via some API an instance of the singleton in each process should recognize that resource is locked (by using that API) that's all we don't have to make things more complicate then they are just because there is some nice design pattern or nice unit test framework or whatever keep things simple, make them work fast, don't introduce middle layers unless you have really good reason to do so of course I could be entirely wrong, so sorry about that in advance thanks Dmitry Markman From tjarvi at qbang.org Wed Mar 22 22:31:41 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 22 Mar 2006 22:31:41 -0700 (MST) Subject: [Rxtx] sole of a new design pattern In-Reply-To: References: Message-ID: Hi Doug Interesting reading. So far I'm just reading and thinking. I have one question so far. " Clients obtain a reference to a Parametric Singleton instance only through the parametric singleton design pattern. If the instance is left in an improper state (e.g., the serial port was left open) it is NOT the role of the Parametric Singleton Design Pattern to close the IO port. Nor is it the role of the Parametric Singleton Design Pattern to open the port. That role is delegate to some other part of the system. " So when the clients obtain a reference to the singleton, can they assume the port is there? IE, would it be the singletons role to handle things like USB dongles being removed with event hints comming from the underlying OS. Hardware abstraction layer/HAL on Linux is an example of underlying OS events. I assume that role too is delegated to other parts of the system? -- Trent Jarvi tjarvi at qbang.org From lyon at docjava.com Thu Mar 23 08:10:33 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Thu, 23 Mar 2006 10:10:33 -0500 Subject: [Rxtx] Classes don't need goals, they need roles! In-Reply-To: References: Message-ID: Hi Trent, Yes, I think that the role of the Parametric Singleton Pattern is not to open or close serial ports, nor is it to perform error checking. On the other hand, if you were to combine the role of the Parametric Singleton Pattern with another role (like that of error checking) it might not be amiss. However, I generally caution programmers against adding multiple roles to classes, as this leads to monolithic designs. Thus a different class (NativeLibDetect) could have the role of determining if the native library can be loaded. Another class (SerialPortBean) can have the role of serializing the default state of the serial port, so that it can be recovered, from user preferences, at a later time. The SerialPortDetect could have the role of determining if the serial port is removed (i.e., a USB port was unplugged). My guess is that each class should have a different role in the system, in order to ease maintenance and testing...but I could be wrong about that. Thanks! - Doug >Hi Doug > >Interesting reading. So far I'm just reading and thinking. I have >one question so far. > >" > Clients obtain a reference to a Parametric Singleton instance only >through the parametric singleton design pattern. If the instance is >left in an improper state (e.g., the serial port was left open) it is >NOT the role of the Parametric Singleton Design Pattern to close the >IO port. Nor is it the role of the Parametric Singleton Design Pattern >to >open the port. That role is delegate to some other part of the system. >" > >So when the clients obtain a reference to the singleton, can they >assume the port is there? IE, would it be the singletons role to >handle things like USB dongles being removed with event hints >comming from the underlying OS. Hardware abstraction layer/HAL on >Linux is an example of underlying OS events. > >I assume that role too is delegated to other parts of the system? > >-- >Trent Jarvi >tjarvi at qbang.org >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From maximulo at yahoo.com Fri Mar 24 01:22:38 2006 From: maximulo at yahoo.com (Maximulo Majir) Date: Fri, 24 Mar 2006 00:22:38 -0800 (PST) Subject: [Rxtx] JavaPOS Message-ID: <20060324082238.66371.qmail@web38214.mail.mud.yahoo.com> Hi all! Hello Trent! From what i understand, RXTX or JavaComm APIs were not created solely for JavaPOS. In JavaPOS, we have the virtual method claim() which is separate from open(), but in our RXTX API, claiming is done every call to open(), we cant open the port if its claimed by another application. Would it be alright to suggest or ask to create a new method called claim(..)? Is there such thing as forceclaim() in RXTX? this could be the same as portownership transfer or its equivalent. ForceClaim is in JSR80. Do you have some samples using RXTX as the lower layer for the Device Service Objects in JavaPOS? I have tried it, i just want to compare. Thank you all! maxim __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060324/496adba2/attachment-0004.html From tjarvi at qbang.org Fri Mar 24 11:28:19 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 24 Mar 2006 11:28:19 -0700 (MST) Subject: [Rxtx] Re: RXTX 2.1 Solaris Problems In-Reply-To: <3691.1143210578@www045.gmx.net> References: <3691.1143210578@www045.gmx.net> Message-ID: On Fri, 24 Mar 2006, Andreas Guenther wrote: > Hi all, > > the solaris problem was not the lock file only. > > Ok, I had to create the directory /var/spool/locks myself. > /var/spool/uucp exists. > > But rxtx didn't find any port. > > I compiled the source with my own debug-informations > and I tried to isolate the problem. > > The problem is the testRead-call in SerialImp.c > > JNIEXPORT jboolean JNICALL RXTXCommDriver(testRead)( > > ... > if ( READ( fd, &c, 1 ) < 0 ) > { > if ( errno != EAGAIN ) { > report( "testRead() read failed\n" ); > ret = JNI_FALSE; > } > } > Thanks Andreas I'm packing up to move. I'll be more or less away for a couple weeks here. I'll be checking email but my workstation is going into a box soon. This isn't hard to fix as this port should be enumerated when EWOULDBLOCK is recieved. Thats error is OK for enumeration just as EAGAIN is. I've put the bug into bugzilla so we dont forget to get to it. http://bugzilla.qbang.org/show_bug.cgi?id=42 You can add yourself to the CC list if you wish to test fixes we provide or even put a patch into bugzilla yourself. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Fri Mar 24 11:51:52 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 24 Mar 2006 11:51:52 -0700 (MST) Subject: [Rxtx] JavaPOS In-Reply-To: <20060324082238.66371.qmail@web38214.mail.mud.yahoo.com> References: <20060324082238.66371.qmail@web38214.mail.mud.yahoo.com> Message-ID: On Fri, 24 Mar 2006, Maximulo Majir wrote: > Hi all! Hello Trent! > > > From what i understand, RXTX or JavaComm APIs were not > created solely for JavaPOS. In JavaPOS, we have the virtual method > claim() which is separate from open(), but in our RXTX API, claiming is > done every call to open(), we cant open the port if its claimed by > another application. Would it be alright to suggest or ask to create a > new method called claim(..)? Is there such thing as forceclaim() in > RXTX? this could be the same as portownership transfer or its > equivalent. ForceClaim is in JSR80. > Do you have some samples using RXTX as the lower layer for the Device > Service Objects in JavaPOS? I have tried it, i just want to compare. > maxim Hi Maxim JSR80 is the USB API IBM/Sun put together. The problem is they have a richer kernel/API underneath that can handle such things. With Serial Ports, there isnt anything there other than an ioctl that says don't let anyone touch this and lockfiles that are more of a 'lets be nice.' At times we may be using USB ports but it is through the termios layer with the limitations mentioned. The advantage is that not only USB will work with rxtx. Anything that has a termios layer should work (to the extent that termios layer is complete). I don't know how forceclaim() would help you. Lets say someone has a programmer working on /dev/ttyS0 and you take it. Now you both race each other to read data first. There isn't a mechanism I know of that will solve this problem in termios. The most obvious test being a native app and a Java app trying to take the port. There is the potential of requestion ownership from other Java Applications but the use for that is very rare. Did you have something more specific in mind that I'm missing? I'm not sure that claim() and forceclaim() would help you with rxtx other than maybe locking the port with claim() without opening it. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sat Mar 25 23:42:08 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 25 Mar 2006 23:42:08 -0700 (MST) Subject: [Rxtx] Serial snoop Message-ID: I was reading the Linux kernel mail-list tonight and ran past a thread that mentioned sersnoop. This looks like a handy tool for people dealing with new toys. "a simple command-line tool for linux that echoes bytes to and from any two serial ports, ptys, or network sockets, and prints all traffic to stdout, in hex and ascii." http://www.restivo.org/projects/sersnoop/ It works on Linux only at this time (debian package available). -- Trent Jarvi tjarvi at qbang.org From beat.arnet at gmail.com Sun Mar 26 07:32:35 2006 From: beat.arnet at gmail.com (Beat Arnet) Date: Sun, 26 Mar 2006 09:32:35 -0500 Subject: [Rxtx] Error 0x5 at /home/bob/foo/tar/rxtx-2.1-7/build/../src/termios.c(860): Access is, denied. Message-ID: <4426A603.80508@gmail.com> Dear all, When trying to open the serial port, I sometimes (not always) run into the following exception (when opening the serialPort): Error 0x5 at /home/bob/foo/tar/rxtx-2.1-7/build/../src/termios.c(860): Access is denied. java.lang.UnsatisfiedLinkError: native_psmisc_report_owner at gnu.io.CommPortIdentifier.native_psmisc_report_owner(Native Method) at gnu.io.CommPortIdentifier.open(CommPortIdentifier.java:354) at codeskin.tools.CLLoader.open(CLLoader.java:79) at codeskin.tools.C2000Programmer.run(C2000Programmer.java:220) at java.lang.Thread.run(Unknown Source) Is this the type of error where I should just try to open the port again, or can it be avoided? Regards, Beat From tjarvi at qbang.org Sun Mar 26 11:40:12 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 26 Mar 2006 11:40:12 -0700 (MST) Subject: [Rxtx] Error 0x5 at /home/bob/foo/tar/rxtx-2.1-7/build/../src/termios.c(860): Access is, denied. In-Reply-To: <4426A603.80508@gmail.com> References: <4426A603.80508@gmail.com> Message-ID: On Sun, 26 Mar 2006, Beat Arnet wrote: > Dear all, > > When trying to open the serial port, I sometimes (not always) run into > the following exception (when opening the serialPort): > > Error 0x5 at /home/bob/foo/tar/rxtx-2.1-7/build/../src/termios.c(860): > Access is > denied. > > java.lang.UnsatisfiedLinkError: native_psmisc_report_owner > at gnu.io.CommPortIdentifier.native_psmisc_report_owner(Native > Method) > at gnu.io.CommPortIdentifier.open(CommPortIdentifier.java:354) > at codeskin.tools.CLLoader.open(CLLoader.java:79) > at codeskin.tools.C2000Programmer.run(C2000Programmer.java:220) > at java.lang.Thread.run(Unknown Source) > > Is this the type of error where I should just try to open the port again, > or can it be avoided? > Hi Beat We did a second build of rxtx 2.1-7 to resolve that unsatisfied link error. It should work now. rxtx is trying to tell you it thinks someone else has the serial port open. You can try to open the port again but maybe you already have a copy of the program running when it happens? ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7r2.zip fixed build. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sun Mar 26 11:44:23 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 26 Mar 2006 11:44:23 -0700 (MST) Subject: [Rxtx] RXTX spec file (fwd) Message-ID: This is probably interesting for fedora/suse users. ---------- Forwarded message ---------- Date: Sun, 26 Mar 2006 16:25:45 +0200 To: taj at www.linux.org.uk Subject: RXTX spec file I send you this spec file which allows to create a RPM for Fedora 4, 5 (x86, x86_64) with Java Sun. -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: rxtx.spec Url: http://mailman.qbang.org/pipermail/rxtx/attachments/20060326/6c7b6af6/rxtx.pl From tjarvi at qbang.org Sun Mar 26 23:42:59 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 26 Mar 2006 23:42:59 -0700 (MST) Subject: [Rxtx] Upcomming events. Message-ID: This Wednesday we will be announcing a new "Maintainer" for the rxtx project. The position is more like neutral leader. I wont be going away or doing less. This is just the right thing to do as it turns out the two people with CVS write access will be at the same company. We need a third and we need neutrality. The maintainer will have final say in any conflict and will try to be neutral. It will be open for discussion. Then we will do it :) I'll still do most of the footwork I do now. But. I'm falling behind. I should have gone through the mail-list and posted the next round of changes this weekend. I'm packing to move and its going so so - 13 years of toys collected. I suspect there will be a dead period on my part (a couple weeks) comming up. But if you get it on the mail-list, we will get it in if there are no objections. I may well not be reading the mail-list during this period as I look for a house and many other things. I hope everyone will help out. Thanks -- Trent Jarvi tjarvi at qbang.org From mahmoud_hadad at yahoo.com Sun Mar 26 07:31:19 2006 From: mahmoud_hadad at yahoo.com (ronan nick) Date: Sun, 26 Mar 2006 06:31:19 -0800 (PST) Subject: [Rxtx] a question about the COMM API Message-ID: <20060326143119.54919.qmail@web60014.mail.yahoo.com> hi, i was intrested in knowing how i can communicate with my internal modem using java? for example if i want to make a phone dialer application or a caller id application where should i be looking at? and as i understood the COMM API is for devices that is attached to the computer through serial ports. --------------------------------- New Yahoo! Messenger with Voice. Call regular phones from your PC and save big. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060326/ce8329f0/attachment-0002.html From dmarkman at mac.com Mon Mar 20 00:20:43 2006 From: dmarkman at mac.com (Dmitry Markman) Date: Mon, 20 Mar 2006 02:20:43 -0500 Subject: [Rxtx] Mac OS X RXTX java installer In-Reply-To: References: <07D0DE29-BA32-4CFE-B036-66BC6423D385@buechse.de> <441AE3E0.2030503@willicon.de> <12531986.1142622114996.JavaMail.dmarkman@mac.com> <441B2674.9010409@willicon.de> <13577405.1142634732776.JavaMail.dmarkman@mac.com> <441B4182.8010407@willicon.de> <92CD0D6C-5BE8-426E-A46D-99452059FF49@mac.com> <441BBB2D.8030305@willicon.de> <441C4088.5090905@willicon.de> Message-ID: <64BC1E23-FDDE-4CE6-8863-CFC881CBC224@mac.com> Hi all I put RXTX installer that will install everything (and will create / var/lock if necessary and add user to the uucp group) for mac os x from Java into the rxtx's CVS repository it could be easily modified to install files for any platform it uses Greg Guerin's AuthKit for authentication and authorization Greg released that kit under artistic license, so Trent, please take a look we, probably, can negotiate license with Greg if it's necessary Greg's AuthKit could be downloaded from http://www.amug.org/~glguerin/ sw/#authkit Michael Hall (mikehall at spacestar dot net) had a suggestion to make implementation of the jaas LoginModule based on Greg's AuthKit (his modification of the Greg's AuthKit could be found at http:// www.spacestar.net/users/mikehall/authkit.dmg) but Michael's AuthKitLoginModule does only half a job: it does authenticate but it can not run any external unix process in privileged mode (at least I wasn't able to do so) possible explanation could be found in conversation between Greg and Michael at Apple's java-dev list (look for archives) so I didn't use jaas API for rxtxinstaller I created folder MacOSX in the contrib folder comment 1. if you want to run that installer as standalone application all you need that RXTXInstaller.jar 2. if you want to use webstart you have to add Greg's libAuthKit.jnilib to the mac os x's resources in theory RXTXInstaller.jar doesn't need it, but there is a problem with loading libAuthKit.jnilib from webstart authkit uses loadLibrary method to load library and it failed (from webstart) for standalone application I extract libAuthKit.jnilib from the RXTXInstaller.jar and put it into the /Library/Java/Extensions or ~/Library/Java/Extensions folder that file will be deleted after installer quit unfortunately I didn't have time to put documentation there but it is mostly self-explanatory I took installer code from my gl4java installer that I did about 3 years ago (with small modifications) it would be very nice if Apple will release LoginModule that really will do the job (com.apple.security.auth.module package????? ) (UnixLoginModule is pretty useless) From lyon at docjava.com Mon Mar 20 06:34:39 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Mon, 20 Mar 2006 08:34:39 -0500 Subject: [Rxtx] Mac OS X RXTX java installer In-Reply-To: <64BC1E23-FDDE-4CE6-8863-CFC881CBC224@mac.com> References: <07D0DE29-BA32-4CFE-B036-66BC6423D385@buechse.de> <441AE3E0.2030503@willicon.de> <12531986.1142622114996.JavaMail.dmarkman@mac.com> <441B2674.9010409@willicon.de> <13577405.1142634732776.JavaMail.dmarkman@mac.com> <441B4182.8010407@willicon.de> <92CD0D6C-5BE8-426E-A46D-99452059FF49@mac.com> <441BBB2D.8030305@willicon.de> <441C4088.5090905@willicon.de> <64BC1E23-FDDE-4CE6-8863-CFC881CBC224@mac.com> Message-ID: Hi Dimitry, This sounds like great work. Just a couple of questions; After the check out of the CVS files, using: setenv CVSROOT :pserver:anonymous at cvs.milestonesolutions.com:/usr/local/cvsroot 53 8:28 setenv PASSWORD mousy 54 8:29 cvs login 55 8:29 cvs checkout rxtx-devel I cd'd over to: rxtx-devel/MACOSX_IDE And found: CVS/ CW/ ForPackageMaker/ PB/ Where is the installer? Thanks! - Doug From tjarvi at qbang.org Mon Mar 20 06:39:37 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 20 Mar 2006 06:39:37 -0700 (MST) Subject: [Rxtx] Mac OS X RXTX java installer In-Reply-To: References: <07D0DE29-BA32-4CFE-B036-66BC6423D385@buechse.de> <441AE3E0.2030503@willicon.de> <12531986.1142622114996.JavaMail.dmarkman@mac.com> <441B2674.9010409@willicon.de> <13577405.1142634732776.JavaMail.dmarkman@mac.com> <441B4182.8010407@willicon.de> <92CD0D6C-5BE8-426E-A46D-99452059FF49@mac.com> <441BBB2D.8030305@willicon.de> <441C4088.5090905@willicon.de> <64BC1E23-FDDE-4CE6-8863-CFC881CBC224@mac.com> Message-ID: On Mon, 20 Mar 2006, Dr. Douglas Lyon wrote: > Hi Dimitry, > This sounds like great work. Just a couple of questions; > After the check out of the CVS files, using: > setenv CVSROOT > :pserver:anonymous at cvs.milestonesolutions.com:/usr/local/cvsroot > 53 8:28 setenv PASSWORD mousy > 54 8:29 cvs login > 55 8:29 cvs checkout rxtx-devel Hi Doug You want "cvs checkout -r commapi-0-0-1 rxtx-devel" to get RXTX 2.1 The default branch is rxtx 2.0 which isn't very active right now. -- Trent Jarvi tjarvi at qbang.org From lyon at docjava.com Mon Mar 20 07:05:44 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Mon, 20 Mar 2006 09:05:44 -0500 Subject: [Rxtx] Mac OS X RXTX java installer In-Reply-To: References: <07D0DE29-BA32-4CFE-B036-66BC6423D385@buechse.de> <441AE3E0.2030503@willicon.de> <12531986.1142622114996.JavaMail.dmarkman@mac.com> <441B2674.9010409@willicon.de> <13577405.1142634732776.JavaMail.dmarkman@mac.com> <441B4182.8010407@willicon.de> <92CD0D6C-5BE8-426E-A46D-99452059FF49@mac.com> <441BBB2D.8030305@willicon.de> <441C4088.5090905@willicon.de> <64BC1E23-FDDE-4CE6-8863-CFC881CBC224@mac.com> Message-ID: Hi Trent, Thanks for the info on the CVS checkout procedure. I did that and am still not sure where the installer is. Here is what I have: cd MACOSX_IDE/ p4.docjava.com{lyon}121: ls CVS/ ForPackageMaker/ PB/ p4.docjava.com{lyon}122: find . | more . ./ForPackageMaker ./ForPackageMaker/RXTX.pkg.sit.hqx ./ForPackageMaker/Resources ./ForPackageMaker/Resources/ReadMe.rtf ./ForPackageMaker/Resources/Welcome.rtf ./ForPackageMaker/Resources/CVS ./ForPackageMaker/Resources/CVS/Entries ./ForPackageMaker/Resources/CVS/Repository ./ForPackageMaker/Resources/CVS/Tag ./ForPackageMaker/Resources/CVS/Root ./ForPackageMaker/Resources/preinstall ./ForPackageMaker/Resources/License.rtf ./ForPackageMaker/Resources/preupgrade ./ForPackageMaker/RXTX.pmsp ./ForPackageMaker/CVS ./ForPackageMaker/CVS/Entries ./ForPackageMaker/CVS/Repository ./ForPackageMaker/CVS/Entries.Log ./ForPackageMaker/CVS/Tag ./ForPackageMaker/CVS/Root ./ForPackageMaker/RXTX_Tiger.pkg.sitx.hqx ./ForPackageMaker/RXTX_Jag.pkg.sit.hqx ./ForPackageMaker/Install ./ForPackageMaker/Install/CVS ./ForPackageMaker/Install/CVS/Entries ./ForPackageMaker/Install/CVS/Repository ./ForPackageMaker/Install/CVS/Tag ./ForPackageMaker/Install/CVS/Root ./ForPackageMaker/Install/Library ./ForPackageMaker/Install/Library/CVS ./ForPackageMaker/Install/Library/CVS/Entries ./ForPackageMaker/Install/Library/CVS/Repository ./ForPackageMaker/Install/Library/CVS/Tag ./ForPackageMaker/Install/Library/CVS/Root ./ForPackageMaker/Install/Library/Java ./ForPackageMaker/Install/Library/Java/Extensions ./ForPackageMaker/Install/Library/Java/Extensions/RXTXcomm.jar ./ForPackageMaker/Install/Library/Java/Extensions/CVS ./ForPackageMaker/Install/Library/Java/Extensions/CVS/Entries ./ForPackageMaker/Install/Library/Java/Extensions/CVS/Repository ./ForPackageMaker/Install/Library/Java/Extensions/CVS/Tag ./ForPackageMaker/Install/Library/Java/Extensions/CVS/Root ./ForPackageMaker/Install/Library/Java/Extensions/librxtxSerial.jnilib ./ForPackageMaker/Install/Library/Java/CVS ./ForPackageMaker/Install/Library/Java/CVS/Entries ./ForPackageMaker/Install/Library/Java/CVS/Repository ./ForPackageMaker/Install/Library/Java/CVS/Entries.Log ./ForPackageMaker/Install/Library/Java/CVS/Tag ./ForPackageMaker/Install/Library/Java/CVS/Root ./ForPackageMaker/RXTX_Tiger.pmproj.sitx.hqx ./CVS ./CVS/Entries ./CVS/Repository ./CVS/Entries.Log ./CVS/Tag ./CVS/Root ./PB ./PB/LibSerialUniversal.xcodeproj.sitx.hqx ./PB/CVS ./PB/CVS/Entries ./PB/CVS/Repository ./PB/CVS/Entries.Log ./PB/CVS/Tag ./PB/CVS/Root ./PB/LibSerial.pbproj.sit.hqx ./PB/startpoint.c ./PB/config.h What is the procedure to run this installer? Do we need a README in: /rxtx-devel/MACOSX_IDE Here is what we have: CVS/ ForPackageMaker/ PB/ Thanks! - DL >On Mon, 20 Mar 2006, Dr. Douglas Lyon wrote: > >>Hi Dimitry, >>This sounds like great work. Just a couple of questions; >>After the check out of the CVS files, using: >>setenv CVSROOT >>:pserver:anonymous at cvs.milestonesolutions.com:/usr/local/cvsroot >> 53 8:28 setenv PASSWORD mousy >> 54 8:29 cvs login >> 55 8:29 cvs checkout rxtx-devel > >Hi Doug > >You want "cvs checkout -r commapi-0-0-1 rxtx-devel" to get RXTX 2.1 >The default branch is rxtx 2.0 which isn't very active right now. > >-- >Trent Jarvi >tjarvi at qbang.org From tjarvi at qbang.org Mon Mar 20 07:25:30 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 20 Mar 2006 07:25:30 -0700 (MST) Subject: [Rxtx] Mac OS X RXTX java installer In-Reply-To: References: <07D0DE29-BA32-4CFE-B036-66BC6423D385@buechse.de> <441AE3E0.2030503@willicon.de> <12531986.1142622114996.JavaMail.dmarkman@mac.com> <441B2674.9010409@willicon.de> <13577405.1142634732776.JavaMail.dmarkman@mac.com> <441B4182.8010407@willicon.de> <92CD0D6C-5BE8-426E-A46D-99452059FF49@mac.com> <441BBB2D.8030305@willicon.de> <441C4088.5090905@willicon.de> <64BC1E23-FDDE-4CE6-8863-CFC881CBC224@mac.com> Message-ID: On Mon, 20 Mar 2006, Dr. Douglas Lyon wrote: > Hi Trent, > Thanks for the info on the CVS checkout procedure. > I did that and am still not sure where the installer is. Hi Doug It does look like it was not cvs committed. There is no rxtx-devel/contrib/MacOSX directory in there at the moment. It was mentioned that it was put under contrib. -- Trent Jarvi tjarvi at qbang.org From dmarkman at mac.com Mon Mar 20 07:29:56 2006 From: dmarkman at mac.com (Dmitry Markman) Date: Mon, 20 Mar 2006 09:29:56 -0500 Subject: [Rxtx] Mac OS X RXTX java installer In-Reply-To: References: <07D0DE29-BA32-4CFE-B036-66BC6423D385@buechse.de> <441AE3E0.2030503@willicon.de> <12531986.1142622114996.JavaMail.dmarkman@mac.com> <441B2674.9010409@willicon.de> <13577405.1142634732776.JavaMail.dmarkman@mac.com> <441B4182.8010407@willicon.de> <92CD0D6C-5BE8-426E-A46D-99452059FF49@mac.com> <441BBB2D.8030305@willicon.de> <441C4088.5090905@willicon.de> <64BC1E23-FDDE-4CE6-8863-CFC881CBC224@mac.com> Message-ID: <6054EB4E-F7E0-4A9C-BDDA-D582D6D8826F@mac.com> you can find it in the rxtx-devel/contrib folder On Mar 20, 2006, at 9:05 AM, Dr. Douglas Lyon wrote: > Hi Trent, > Thanks for the info on the CVS checkout procedure. > I did that and am still not sure where the installer is. > Here is what I have: > cd MACOSX_IDE/ > p4.docjava.com{lyon}121: ls > CVS/ ForPackageMaker/ PB/ > p4.docjava.com{lyon}122: find . | more > . > ./ForPackageMaker > ./ForPackageMaker/RXTX.pkg.sit.hqx > ./ForPackageMaker/Resources > ./ForPackageMaker/Resources/ReadMe.rtf > ./ForPackageMaker/Resources/Welcome.rtf > ./ForPackageMaker/Resources/CVS > ./ForPackageMaker/Resources/CVS/Entries > ./ForPackageMaker/Resources/CVS/Repository > ./ForPackageMaker/Resources/CVS/Tag > ./ForPackageMaker/Resources/CVS/Root > ./ForPackageMaker/Resources/preinstall > ./ForPackageMaker/Resources/License.rtf > ./ForPackageMaker/Resources/preupgrade > ./ForPackageMaker/RXTX.pmsp > ./ForPackageMaker/CVS > ./ForPackageMaker/CVS/Entries > ./ForPackageMaker/CVS/Repository > ./ForPackageMaker/CVS/Entries.Log > ./ForPackageMaker/CVS/Tag > ./ForPackageMaker/CVS/Root > ./ForPackageMaker/RXTX_Tiger.pkg.sitx.hqx > ./ForPackageMaker/RXTX_Jag.pkg.sit.hqx > ./ForPackageMaker/Install > ./ForPackageMaker/Install/CVS > ./ForPackageMaker/Install/CVS/Entries > ./ForPackageMaker/Install/CVS/Repository > ./ForPackageMaker/Install/CVS/Tag > ./ForPackageMaker/Install/CVS/Root > ./ForPackageMaker/Install/Library > ./ForPackageMaker/Install/Library/CVS > ./ForPackageMaker/Install/Library/CVS/Entries > ./ForPackageMaker/Install/Library/CVS/Repository > ./ForPackageMaker/Install/Library/CVS/Tag > ./ForPackageMaker/Install/Library/CVS/Root > ./ForPackageMaker/Install/Library/Java > ./ForPackageMaker/Install/Library/Java/Extensions > ./ForPackageMaker/Install/Library/Java/Extensions/RXTXcomm.jar > ./ForPackageMaker/Install/Library/Java/Extensions/CVS > ./ForPackageMaker/Install/Library/Java/Extensions/CVS/Entries > ./ForPackageMaker/Install/Library/Java/Extensions/CVS/Repository > ./ForPackageMaker/Install/Library/Java/Extensions/CVS/Tag > ./ForPackageMaker/Install/Library/Java/Extensions/CVS/Root > ./ForPackageMaker/Install/Library/Java/Extensions/librxtxSerial.jnilib > ./ForPackageMaker/Install/Library/Java/CVS > ./ForPackageMaker/Install/Library/Java/CVS/Entries > ./ForPackageMaker/Install/Library/Java/CVS/Repository > ./ForPackageMaker/Install/Library/Java/CVS/Entries.Log > ./ForPackageMaker/Install/Library/Java/CVS/Tag > ./ForPackageMaker/Install/Library/Java/CVS/Root > ./ForPackageMaker/RXTX_Tiger.pmproj.sitx.hqx > ./CVS > ./CVS/Entries > ./CVS/Repository > ./CVS/Entries.Log > ./CVS/Tag > ./CVS/Root > ./PB > ./PB/LibSerialUniversal.xcodeproj.sitx.hqx > ./PB/CVS > ./PB/CVS/Entries > ./PB/CVS/Repository > ./PB/CVS/Entries.Log > ./PB/CVS/Tag > ./PB/CVS/Root > ./PB/LibSerial.pbproj.sit.hqx > ./PB/startpoint.c > ./PB/config.h > > What is the procedure to run this installer? > Do we need a README in: > /rxtx-devel/MACOSX_IDE > Here is what we have: > CVS/ ForPackageMaker/ PB/ > > > Thanks! > - DL > >> On Mon, 20 Mar 2006, Dr. Douglas Lyon wrote: >> >>> Hi Dimitry, >>> This sounds like great work. Just a couple of questions; >>> After the check out of the CVS files, using: >>> setenv CVSROOT :pserver:anonymous at cvs.milestonesolutions.com:/usr/ >>> local/cvsroot >>> 53 8:28 setenv PASSWORD mousy >>> 54 8:29 cvs login >>> 55 8:29 cvs checkout rxtx-devel >> >> Hi Doug >> >> You want "cvs checkout -r commapi-0-0-1 rxtx-devel" to get RXTX 2.1 >> The default branch is rxtx 2.0 which isn't very active right now. >> >> -- >> Trent Jarvi >> tjarvi at qbang.org > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx Dmitry Markman From mikehall at spacestar.net Mon Mar 20 05:25:25 2006 From: mikehall at spacestar.net (Michael Hall) Date: Mon, 20 Mar 2006 06:25:25 -0600 Subject: [Rxtx] Re: Mac OS X RXTX java installer In-Reply-To: <64BC1E23-FDDE-4CE6-8863-CFC881CBC224@mac.com> References: <07D0DE29-BA32-4CFE-B036-66BC6423D385@buechse.de> <441AE3E0.2030503@willicon.de> <12531986.1142622114996.JavaMail.dmarkman@mac.com> <441B2674.9010409@willicon.de> <13577405.1142634732776.JavaMail.dmarkman@mac.com> <441B4182.8010407@willicon.de> <92CD0D6C-5BE8-426E-A46D-99452059FF49@mac.com> <441BBB2D.8030305@willicon.de> <441C4088.5090905@willicon.de> <64BC1E23-FDDE-4CE6-8863-CFC881CBC224@mac.com> Message-ID: <247EB61F-5CD1-4132-89A2-FC105B6CF9A5@spacestar.net> On Mar 20, 2006, at 1:20 AM, Dmitry Markman wrote: > > Michael Hall (mikehall at spacestar dot net) had a suggestion to > make implementation of the jaas LoginModule > based on Greg's AuthKit > (his modification of the Greg's AuthKit could be found at http:// > www.spacestar.net/users/mikehall/authkit.dmg) > but Michael's AuthKitLoginModule does only half a job: > it does authenticate > but it can not run any external unix process in privileged mode (at > least I wasn't able to do so) If you got it working directly with Greg's the point is moot. But to clarify it anyhow. The login module does not allow you to do anything anything privileged on return as was explained by Greg. You need to work with a separate privileged process using the execPrivileged method of his API. I assume you did something similar although I haven't looked at how you are using it yet. I allowed instead for a action to be performed at the same time you login/authenticate,this... System.setProperty("authkit.action","/usr/bin/id"); just before this... lc.login(); To clarify, safely ignored as you are already complete. Mike Hall mikehall at spacestar dot net http://www.spacestar.net/users/mikehall http://sourceforge.net/projects/macnative -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2427 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20060320/f6e18202/smime-0005.bin From dmarkman at mac.com Mon Mar 20 07:36:47 2006 From: dmarkman at mac.com (Dmitry Markman) Date: Mon, 20 Mar 2006 09:36:47 -0500 Subject: [Rxtx] Re: Mac OS X RXTX java installer In-Reply-To: <247EB61F-5CD1-4132-89A2-FC105B6CF9A5@spacestar.net> References: <07D0DE29-BA32-4CFE-B036-66BC6423D385@buechse.de> <441AE3E0.2030503@willicon.de> <12531986.1142622114996.JavaMail.dmarkman@mac.com> <441B2674.9010409@willicon.de> <13577405.1142634732776.JavaMail.dmarkman@mac.com> <441B4182.8010407@willicon.de> <92CD0D6C-5BE8-426E-A46D-99452059FF49@mac.com> <441BBB2D.8030305@willicon.de> <441C4088.5090905@willicon.de> <64BC1E23-FDDE-4CE6-8863-CFC881CBC224@mac.com> <247EB61F-5CD1-4132-89A2-FC105B6CF9A5@spacestar.net> Message-ID: Hi, Michael all I have to do is to run some shell script I tried to use your action mechanism and it worked great so I just System.setProperty ("authkit.action","" ) and after that I even don't need to run anything like subject.doAs.... but after few thoughts I choose to use plain Greg's approach, because in that case I don't have to deal with various java's configurations files and therefore to use 2-3 -D parameters in the java command line especially it's useful for java web start (it's so fragile :-( ) thanks for the great job On Mar 20, 2006, at 7:25 AM, Michael Hall wrote: > > On Mar 20, 2006, at 1:20 AM, Dmitry Markman wrote: >> >> Michael Hall (mikehall at spacestar dot net) had a suggestion to >> make implementation of the jaas LoginModule >> based on Greg's AuthKit >> (his modification of the Greg's AuthKit could be found at http:// >> www.spacestar.net/users/mikehall/authkit.dmg) >> but Michael's AuthKitLoginModule does only half a job: >> it does authenticate >> but it can not run any external unix process in privileged mode >> (at least I wasn't able to do so) > > If you got it working directly with Greg's the point is moot. > > But to clarify it anyhow. > The login module does not allow you to do anything anything > privileged on return as was explained by Greg. You need to work > with a separate privileged process using the execPrivileged method > of his API. I assume you did something similar although I haven't > looked at how you are using it yet. > I allowed instead for a action to be performed at the same time you > login/authenticate,this... > System.setProperty("authkit.action","/usr/bin/id"); > just before this... > lc.login(); > To clarify, safely ignored as you are already complete. > > Mike Hall mikehall at spacestar dot net > http://www.spacestar.net/users/mikehall > http://sourceforge.net/projects/macnative > > > Dmitry Markman From dmarkman at mac.com Mon Mar 20 07:44:45 2006 From: dmarkman at mac.com (Dmitry Markman) Date: Mon, 20 Mar 2006 09:44:45 -0500 Subject: [Rxtx] Mac OS X RXTX java installer In-Reply-To: References: <07D0DE29-BA32-4CFE-B036-66BC6423D385@buechse.de> <441AE3E0.2030503@willicon.de> <12531986.1142622114996.JavaMail.dmarkman@mac.com> <441B2674.9010409@willicon.de> <13577405.1142634732776.JavaMail.dmarkman@mac.com> <441B4182.8010407@willicon.de> <92CD0D6C-5BE8-426E-A46D-99452059FF49@mac.com> <441BBB2D.8030305@willicon.de> <441C4088.5090905@willicon.de> <64BC1E23-FDDE-4CE6-8863-CFC881CBC224@mac.com> Message-ID: it's in the commapi-0-0-1 branch I tested it right now: cvs co -r commapi-0-0-1 rxtx-devel and I got everything On Mar 20, 2006, at 9:25 AM, Trent Jarvi wrote: > On Mon, 20 Mar 2006, Dr. Douglas Lyon wrote: > >> Hi Trent, >> Thanks for the info on the CVS checkout procedure. >> I did that and am still not sure where the installer is. > > Hi Doug > > It does look like it was not cvs committed. There is no rxtx-devel/ > contrib/MacOSX directory in there at the moment. It was mentioned > that it was put under contrib. > > -- > Trent Jarvi > tjarvi at qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx Dmitry Markman From tjarvi at qbang.org Mon Mar 20 07:52:57 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 20 Mar 2006 07:52:57 -0700 (MST) Subject: [Rxtx] Mac OS X RXTX java installer In-Reply-To: References: <07D0DE29-BA32-4CFE-B036-66BC6423D385@buechse.de> <441AE3E0.2030503@willicon.de> <12531986.1142622114996.JavaMail.dmarkman@mac.com> <441B2674.9010409@willicon.de> <13577405.1142634732776.JavaMail.dmarkman@mac.com> <441B4182.8010407@willicon.de> <92CD0D6C-5BE8-426E-A46D-99452059FF49@mac.com> <441BBB2D.8030305@willicon.de> <441C4088.5090905@willicon.de> <64BC1E23-FDDE-4CE6-8863-CFC881CBC224@mac.com> Message-ID: On Mon, 20 Mar 2006, Dmitry Markman wrote: > it's in the commapi-0-0-1 branch > > I tested it right now: > cvs co -r commapi-0-0-1 rxtx-devel > > and I got everything > A fresh checkout worked. Here is a copy of the tree (just the installer bits) ftp://ftp.qbang.org/pub/rxtx/MacOSX-installer.zip -- Trent Jarvi tjarvi at qbang.org From lyon at docjava.com Mon Mar 20 08:08:26 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Mon, 20 Mar 2006 10:08:26 -0500 Subject: [Rxtx] Mac OS X RXTX java installer In-Reply-To: References: <07D0DE29-BA32-4CFE-B036-66BC6423D385@buechse.de> <441AE3E0.2030503@willicon.de> <12531986.1142622114996.JavaMail.dmarkman@mac.com> <441B2674.9010409@willicon.de> <13577405.1142634732776.JavaMail.dmarkman@mac.com> <441B4182.8010407@willicon.de> <92CD0D6C-5BE8-426E-A46D-99452059FF49@mac.com> <441BBB2D.8030305@willicon.de> <441C4088.5090905@willicon.de> <64BC1E23-FDDE-4CE6-8863-CFC881CBC224@mac.com> Message-ID: Hi All, Is the Auth package able to work properly on non Mac OS's? It was not clear from the doc or download. Thanks! - Doug From dmarkman at mac.com Mon Mar 20 08:15:22 2006 From: dmarkman at mac.com (Dmitry Markman) Date: Mon, 20 Mar 2006 10:15:22 -0500 Subject: [Rxtx] Mac OS X RXTX java installer In-Reply-To: References: <07D0DE29-BA32-4CFE-B036-66BC6423D385@buechse.de> <441AE3E0.2030503@willicon.de> <12531986.1142622114996.JavaMail.dmarkman@mac.com> <441B2674.9010409@willicon.de> <13577405.1142634732776.JavaMail.dmarkman@mac.com> <441B4182.8010407@willicon.de> <92CD0D6C-5BE8-426E-A46D-99452059FF49@mac.com> <441BBB2D.8030305@willicon.de> <441C4088.5090905@willicon.de> <64BC1E23-FDDE-4CE6-8863-CFC881CBC224@mac.com> Message-ID: <217312D8-CCCA-4859-ABA6-32DF1CC817B9@mac.com> thanks Trent, for putting it on ftp server On Mar 20, 2006, at 9:52 AM, Trent Jarvi wrote: > A fresh checkout worked. Here is a copy of the tree (just the > installer bits) > > ftp://ftp.qbang.org/pub/rxtx/MacOSX-installer.zip > Dmitry Markman From dmarkman at mac.com Mon Mar 20 09:14:03 2006 From: dmarkman at mac.com (Dmitry Markman) Date: Mon, 20 Mar 2006 11:14:03 -0500 Subject: [Rxtx] Mac OS X RXTX java installer In-Reply-To: References: <07D0DE29-BA32-4CFE-B036-66BC6423D385@buechse.de> <441AE3E0.2030503@willicon.de> <12531986.1142622114996.JavaMail.dmarkman@mac.com> <441B2674.9010409@willicon.de> <13577405.1142634732776.JavaMail.dmarkman@mac.com> <441B4182.8010407@willicon.de> <92CD0D6C-5BE8-426E-A46D-99452059FF49@mac.com> <441BBB2D.8030305@willicon.de> <441C4088.5090905@willicon.de> <64BC1E23-FDDE-4CE6-8863-CFC881CBC224@mac.com> Message-ID: <4DEBA6F0-DA45-4E84-823E-1F1AC48BDCCC@mac.com> no it will work only on mac os x however it's harmless to run it on other platform if you want to use it for other platform you have to do the following (I'll do it for linux) 1. modify RXTXInstaller class method public static RXTXInstaller getInstance() public static RXTXInstaller getInstance() { String osName = System.getProperty("os.name").toLowerCase(); if(osName.startsWith("mac")){ return new gnu.io.installer.macosx.MACOSXRXTXInstaller(); } else if(osName.startsWith("windows")){ return new gnu.io.installer.windows.WindowsRXTXInstaller(); }else if(osName.startsWith("linux")){ return new gnu.io.installer.linux.LinuxRXTXInstaller(); } return null; } 2. create folder gnu/io/installer/linux/ 3. create class Linux386RXTXInstaller package gnu.io.installer.linux; import java.io.File; public class Linux386RXTXInstaller extends gnu.io.installer.RXTXInstaller{ public Linux386RXTXInstaller(){ createJarFolder(); createLibFolder(); addJarResource("RXTXcomm.jar","/gnu/io/installer/resources/ linux/jar/RXTXcomm.dat"); addLibResource("librxtxSerial.so","/gnu/io/installer/ resources/linux/lib/librxtxSerial.so"); } protected void createJarFolder(){ String javaHome = System.getProperty("java.home"); char separator = File.separatorChar; jarFolder = new File(javaHome+separator+"lib"+separator+"ext"); } protected void createLibFolder(){ String javaHome = System.getProperty("java.home"); char separator = File.separatorChar; libFolder = new File(javaHome+separator+"bin"); } public void runPreProcess() {} //put here some action you need public void runPostProcess() {} //put here some action you need } 4. create folder /gnu/io/installer/resources/linux/jar and put there linux's version of RXTXcomm.dat (which is renamed RXTXcomm.jar) 5. create folder /gnu/io/installer/resources/linux/lib and put there linux's version of librxtxSerial. so 6. make sure that RXTXInstaller.jar has the following items: /gnu/io/installer/resources/linux/jar/RXTXcomm.jar /gnu/io/installer/resources/linux/lib/librxtxSerial.so 7. modify file installer.pref: jar file RXTXInstaller.jar must have the following item /gnu/io/installer/installer.pref that's basically it for windows you have to do the similar things: just replace linux to windows and librxtxSerial.so to rxtxSerial.dll and create appropriate gnu.io.installer.windows.WindowsRXTXInstaller class package gnu.io.installer.windows; import java.io.File; public class WindowsRXTXInstaller extends gnu.io.installer.RXTXInstaller{ public WindowsRXTXInstaller(){ createJarFolder(); createLibFolder(); addJarResource("RXTXcomm.jar","/gnu/io/installer/resources/ windows/jar/RXTXcomm.dat"); addLibResource("librxtxSerial.so","/gnu/io/installer/ resources/windows/lib/rxtxSerial.dll"); } protected void createJarFolder(){ String javaHome = System.getProperty("java.home"); char separator = File.separatorChar; jarFolder = new File(javaHome+separator+"lib"+separator+"ext"); } protected void createLibFolder(){ String javaHome = System.getProperty("java.home"); char separator = File.separatorChar; libFolder = new File(javaHome+separator+"bin"); } public void runPreProcess() {} //put here some action you need public void runPostProcess() {} //put here some action you need } installer.pref will look like On Mar 20, 2006, at 10:08 AM, Dr. Douglas Lyon wrote: > Hi All, > Is the Auth package able to work properly on > non Mac OS's? > It was not clear from the doc or download. > > Thanks! > - Doug > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx Dmitry Markman From joachim at buechse.de Mon Mar 20 10:49:06 2006 From: joachim at buechse.de (Joachim Buechse) Date: Mon, 20 Mar 2006 18:49:06 +0100 Subject: [Rxtx] BUG: Lock file stays even if port opening fails Message-ID: This was only tested on MacOSX but looking at the code, it should be true for all systems that use lock_uucp. I am opening a port which can not be opened (dialup port of a telephone paired via bluetooth but currently not reachable). The lock file is created and stays arround, even though the port open failed. After looking a bit through the code (of 2.17), I really wonder if it wouldn't be a good idea to make the "locking" an explicit operation called from the java code. This would certainly simplify the generation of meaningfull exceptions (and java based debugging). Maybe even the handling of "preopened" ports should be in the Java part of the lib (again for java based debugging puposes). That beeing said, I have no idea if this would be possible for the 2.07 implementation. Regards, Joachim From tjarvi at qbang.org Mon Mar 20 11:24:22 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 20 Mar 2006 11:24:22 -0700 (MST) Subject: [Rxtx] BUG: Lock file stays even if port opening fails In-Reply-To: References: Message-ID: On Mon, 20 Mar 2006, Joachim Buechse wrote: > This was only tested on MacOSX but looking at the code, it should be true > for all systems that use lock_uucp. > > I am opening a port which can not be opened (dialup port of a telephone > paired via bluetooth but currently not reachable). The lock file is > created and stays arround, even though the port open failed. > > > After looking a bit through the code (of 2.17), I really wonder if it > wouldn't be a good idea to make the "locking" an explicit operation > called from the java code. This would certainly simplify the generation > of meaningfull exceptions (and java based debugging). > Maybe even the handling of "preopened" ports should be in the Java part > of the lib (again for java based debugging puposes). That beeing said, I > have no idea if this would be possible for the 2.07 implementation. > > Regards, Hi Joachim It should be possible in the 2.0-7 implementation too. The calls to RXTXPort.java would not change. We would just do more there Moving more of that logic into Java would be better as many people don't like to look at C code. There is a liblockdev on most Linux distros that can do most of the C code and would be easier to use. The problem is embeded devices will not have that library. The preopened port code has not been really tested. That was a last minute request in a product cycle. I expect it will be tested this year though. As I recall, some devices really do not like CD raising on open. The preopened ports then allow people to mess around in java without power cycling the devices or losing data. -- Trent Jarvi tjarvi at qbang.org From joachim at buechse.de Mon Mar 20 12:01:08 2006 From: joachim at buechse.de (Joachim Buechse) Date: Mon, 20 Mar 2006 20:01:08 +0100 Subject: [Rxtx] BUG: Lock file stays even if port opening fails In-Reply-To: References: Message-ID: Hi Trent, What is your general feeling about moving code to Java? The last days I have been reading quite a bit of the code and there are several things, that might not work as expected. I'll give you two examples from is_device_locked: if LOCKDIR == /var/spool/locks the directory /var/spool/lock will not be checked. LOCKDIR is not checked for lockfiles with unexpected pefixes While these things have probably never been discovered in production, they are still possibly incorrect implementations. If it was Java code, I would write some unit tests producing the errors that could later be corrected. PS: One could imagine to actually implement the whole lockfile handling in Java using some native routines to get the values required (pid, st_dev, st_rdev, ...). On 20.03.2006, at 19:24, Trent Jarvi wrote: > On Mon, 20 Mar 2006, Joachim Buechse wrote: > >> This was only tested on MacOSX but looking at the code, it should >> be true for all systems that use lock_uucp. >> >> I am opening a port which can not be opened (dialup port of a >> telephone paired via bluetooth but currently not reachable). The >> lock file is created and stays arround, even though the port open >> failed. >> >> >> After looking a bit through the code (of 2.17), I really wonder if >> it wouldn't be a good idea to make the "locking" an explicit >> operation called from the java code. This would certainly simplify >> the generation of meaningfull exceptions (and java based debugging). >> Maybe even the handling of "preopened" ports should be in the Java >> part of the lib (again for java based debugging puposes). That >> beeing said, I have no idea if this would be possible for the 2.07 >> implementation. >> >> Regards, > > Hi Joachim > > It should be possible in the 2.0-7 implementation too. The calls > to RXTXPort.java would not change. We would just do more there > Moving more of that logic into Java would be better as many people > don't like to look at C code. There is a liblockdev on most Linux > distros that can do most of the C code and would be easier to use. > The problem is embeded devices will not have that library. > > The preopened port code has not been really tested. That was a > last minute request in a product cycle. I expect it will be tested > this year though. As I recall, some devices really do not like CD > raising on open. The preopened ports then allow people to mess > around in java without power cycling the devices or losing data. > > -- > Trent Jarvi > tjarvi at qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Mon Mar 20 12:21:02 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 20 Mar 2006 12:21:02 -0700 (MST) Subject: [Rxtx] BUG: Lock file stays even if port opening fails In-Reply-To: References: Message-ID: On Mon, 20 Mar 2006, Joachim Buechse wrote: > Hi Trent, > > What is your general feeling about moving code to Java? The last days I > have been reading quite a bit of the code and there are several things, > that might not work as expected. > > I'll give you two examples from is_device_locked: > > if LOCKDIR == /var/spool/locks the directory /var/spool/lock will not be > checked. > LOCKDIR is not checked for lockfiles with unexpected pefixes > > While these things have probably never been discovered in production, > they are still possibly incorrect implementations. If it was Java code, I > would write some unit tests producing the errors that could later be > corrected. > > PS: One could imagine to actually implement the whole lockfile handling > in Java using some native routines to get the values required (pid, > st_dev, st_rdev, ...). Hi Joachim I like the idea of moving more of the code into java but there are some things to consider. If you break this into multiple JNI calls, the performance will drop considerably during enumeration of ports. We are looking for 256 ports per dev type vs (16? in Sun's 2.0 and fewer types). Its hard to make assumptions. I've seen virtual ports start at /dev/foo100 for instance. It works out to over 7500 ports on Linux if you enable them all. We already trim that back by default. See Linux-all-ports in RXTXCommDriver.java. There are also native libraries that rxtx can link to. If you move too much into Java, linking to 'standard' libraries with distros will break. "configure --enable-liblock=yes" will not be doable. This is probably a favorable way with RedHat, Debian, Suse and others. Thats the right thing to do if there will be rpms, dpkg, .. For those reasons, I think it still make sense to keep it to a minimal ~3 calls to JNI code that we can use for speed and versatility. lock() isLocked(), unlock() perhaps. When I say speed, its more about avoiding crossing the JNI layer multiple times than java vs C performance. With versatility I think liblock is the right way for most but not all (embeded) linux distros. -- Trent Jarvi tjarvi at qbang.org From joachim at buechse.de Mon Mar 20 12:42:04 2006 From: joachim at buechse.de (Joachim Buechse) Date: Mon, 20 Mar 2006 20:42:04 +0100 Subject: [Rxtx] BUG: Lock file stays even if port opening fails In-Reply-To: References: Message-ID: <82C19FE7-DDCB-45B6-B2C9-7606B66F0124@buechse.de> Ok, what about providing a default implementation in Java? The RXTXCommDriver would call a (native) function useNativeLocking and if it returns true, call the native functions for lock() isLocked (), unlock(), else is would use the Java based default implementation. This could possibly be overriden by a property (again for debugging). Joachim On 20.03.2006, at 20:21, Trent Jarvi wrote: > On Mon, 20 Mar 2006, Joachim Buechse wrote: > >> Hi Trent, >> >> What is your general feeling about moving code to Java? The last >> days I have been reading quite a bit of the code and there are >> several things, that might not work as expected. >> >> I'll give you two examples from is_device_locked: >> >> if LOCKDIR == /var/spool/locks the directory /var/spool/lock will >> not be checked. >> LOCKDIR is not checked for lockfiles with unexpected pefixes >> >> While these things have probably never been discovered in >> production, they are still possibly incorrect implementations. If >> it was Java code, I would write some unit tests producing the >> errors that could later be corrected. >> >> PS: One could imagine to actually implement the whole lockfile >> handling in Java using some native routines to get the values >> required (pid, st_dev, st_rdev, ...). > > Hi Joachim > > I like the idea of moving more of the code into java but there are > some things to consider. > > If you break this into multiple JNI calls, the performance will > drop considerably during enumeration of ports. We are looking for > 256 ports per dev type vs (16? in Sun's 2.0 and fewer types). Its > hard to make assumptions. I've seen virtual ports start at /dev/ > foo100 for instance. > > It works out to over 7500 ports on Linux if you enable them all. > We already trim that back by default. See Linux-all-ports in > RXTXCommDriver.java. > > There are also native libraries that rxtx can link to. If you move > too much into Java, linking to 'standard' libraries with distros > will break. "configure --enable-liblock=yes" will not be doable. > This is probably a favorable way with RedHat, Debian, Suse and > others. Thats the right thing to do if there will be rpms, dpkg, .. > > For those reasons, I think it still make sense to keep it to a > minimal ~3 calls to JNI code that we can use for speed and > versatility. lock() isLocked(), unlock() perhaps. When I say > speed, its more about avoiding crossing the JNI layer multiple > times than java vs C performance. With versatility I think liblock > is the right way for most but not all (embeded) linux distros. > > -- > Trent Jarvi > tjarvi at qbang.org > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Mon Mar 20 12:44:47 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 20 Mar 2006 12:44:47 -0700 (MST) Subject: [Rxtx] BUG: Lock file stays even if port opening fails In-Reply-To: <82C19FE7-DDCB-45B6-B2C9-7606B66F0124@buechse.de> References: <82C19FE7-DDCB-45B6-B2C9-7606B66F0124@buechse.de> Message-ID: On Mon, 20 Mar 2006, Joachim Buechse wrote: > Ok, what about providing a default implementation in Java? > > The RXTXCommDriver would call a (native) function useNativeLocking and if > it returns true, call the native functions for lock() isLocked(), > unlock(), else is would use the Java based default implementation. This > could possibly be overriden by a property (again for debugging). > Hi Joachim That would be OK with me. -- Trent Jarvi tjarvi at qbang.org From dmarkman at mac.com Mon Mar 20 22:27:45 2006 From: dmarkman at mac.com (Dmitry Markman) Date: Tue, 21 Mar 2006 00:27:45 -0500 Subject: [Rxtx] binaries request Message-ID: <42702213-C222-4937-A585-7CFB17E47608@mac.com> Hi can somebody send me latest linux and windows binaries, please? or where I can find them (I didn't find them in the latest tareball) I gave up with my cygwin: something wrong I have no idea what java doesn't understand /cygwin/c syntax after I changed makefile it did java part but after that gcc 3.4.4 started to complain I set buffer length to 999 lines but I didn't get beginning of the story something wrong with my 1.4.2_09/include/jni.h gcc doesn't like it anyway I gave up thanks in advance Dmitry Markman -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060320/f8cbc57c/attachment-0005.html From tjarvi at qbang.org Mon Mar 20 22:36:48 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 20 Mar 2006 22:36:48 -0700 (MST) Subject: [Rxtx] binaries request In-Reply-To: <42702213-C222-4937-A585-7CFB17E47608@mac.com> References: <42702213-C222-4937-A585-7CFB17E47608@mac.com> Message-ID: On Tue, 21 Mar 2006, Dmitry Markman wrote: > Hi > can somebody send me latest linux and windows binaries, please? > > or where I can find them (I didn't find them in the latest tareball) > > I gave up with my cygwin: something wrong I have no idea what > java doesn't understand /cygwin/c syntax > after I changed makefile it did java part > but after that gcc 3.4.4 started to complain > I set buffer length to 999 lines but I didn't get beginning of the story > something wrong with my 1.4.2_09/include/jni.h gcc doesn't like it > anyway I gave up > > thanks in advance > Hi Dmitry The bins are here: ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7-bins-r2.zip Here are the files in the zip you want. Jar: rxtx-2.1-7-bins-r2/RXTXcomm.jar Windows: rxtx-2.1-7-bins-r2/Windows/i368-mingw32/rxtxSerial.dll Linux (x86) rxtx-2.1-7-bins-r2/Linux/i686-unknown-linux-gnu/librxtxSerial.so There are others in there including Parallel port support but those are the main ones for testing. -- Trent Jarvi tjarvi at qbang.org From dmarkman at mac.com Mon Mar 20 23:05:59 2006 From: dmarkman at mac.com (Dmitry Markman) Date: Tue, 21 Mar 2006 01:05:59 -0500 Subject: [Rxtx] binaries request In-Reply-To: References: <42702213-C222-4937-A585-7CFB17E47608@mac.com> Message-ID: thank you very much but windows's readme says: rxtxSerial.dll had to be recomopiled to link in missing native methods. should I ignore it? or what? thanks again also I understand that I should use mingw not cygwin I'll try to install mingw On Mar 21, 2006, at 12:36 AM, Trent Jarvi wrote: > On Tue, 21 Mar 2006, Dmitry Markman wrote: > >> Hi >> can somebody send me latest linux and windows binaries, please? >> >> or where I can find them (I didn't find them in the latest tareball) >> >> I gave up with my cygwin: something wrong I have no idea what >> java doesn't understand /cygwin/c syntax >> after I changed makefile it did java part >> but after that gcc 3.4.4 started to complain >> I set buffer length to 999 lines but I didn't get beginning of the >> story >> something wrong with my 1.4.2_09/include/jni.h gcc doesn't like it >> anyway I gave up >> >> thanks in advance >> > > Hi Dmitry > > The bins are here: > > ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7-bins-r2.zip > > Here are the files in the zip you want. > > Jar: > > rxtx-2.1-7-bins-r2/RXTXcomm.jar > > Windows: > > rxtx-2.1-7-bins-r2/Windows/i368-mingw32/rxtxSerial.dll > > Linux (x86) > > rxtx-2.1-7-bins-r2/Linux/i686-unknown-linux-gnu/librxtxSerial.so > > There are others in there including Parallel port support but those > are the main ones for testing. > > -- > Trent Jarvi > tjarvi at qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx Dmitry Markman From tjarvi at qbang.org Mon Mar 20 23:20:33 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 20 Mar 2006 23:20:33 -0700 (MST) Subject: [Rxtx] binaries request In-Reply-To: References: <42702213-C222-4937-A585-7CFB17E47608@mac.com> Message-ID: On Tue, 21 Mar 2006, Dmitry Markman wrote: > thank you very much > > but windows's readme says: > rxtxSerial.dll had to be recomopiled to link in missing native methods. > > should I ignore it? or what? > Hi Dmitry That dll should be OK. r2 is the recompile linked to the missing native method. The readme explains why it was recompiled; fuser.o was not linked into the dll in the first release. -- Trent Jarvi tjarvi at qbang.org From ariantristan at yahoo.com Mon Mar 20 23:55:24 2006 From: ariantristan at yahoo.com (Lambok Sianturi) Date: Mon, 20 Mar 2006 22:55:24 -0800 (PST) Subject: [Rxtx] jvm issue Message-ID: <20060321065524.94779.qmail@web50701.mail.yahoo.com> Hi All, This is my first time to join RxTx mailing list. I thank you all for allowing others to sign in in requests help. I use the latest RxTx lib in Fedora 3 with java version 1.4.2_09 b05. And I got this error: # # An unexpected error has been detected by HotSpot Virtual Machine: # # SIGSEGV (0xb) at pc=0x00bf27f3, pid=2633, tid=3086112448 # # Java VM: Java HotSpot(TM) Client VM (1.4.2_09-b05 mixed mode) # Problematic frame: # C [ld-linux.so.2+0xa7f3] # # An error report file with more information is saved as hs_err_pid2633.log # # If you would like to submit a bug report, please visit: # http://java.sun.com/webapps/bugreport/crash.jsp # ./run.sh: line 3: 2633 Aborted /usr/local/java/bin/java -Djava.library.path=/usr/local/java/jre/lib/ -Djsmsengine.debug=true -classpath jsmsengine.jar:smsgateway.jar:classes12.jar:RXTXcomm.jar:. com.api.sms.SMSServer What is the jvm depedency for the latest library? Can I use 1.4.2_09 b05? Thanks in advance. Arian --------------------------------- Yahoo! Mail Use Photomail to share photos without annoying attachments. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060320/83d58dd7/attachment-0005.html From f.frumento at ngi.it Tue Mar 21 00:21:47 2006 From: f.frumento at ngi.it (Fabio Frumento) Date: Tue, 21 Mar 2006 08:21:47 +0100 Subject: [Rxtx] Javadoc on the go Message-ID: <441FA98B.9050701@ngi.it> Hi Trent, sorry for the big delay but my job is running wild, i was out for some time but now i'm back and ready to continue the javadoc for Rxtx. Did you used the last javadoc patch i sent you ? let me know if i have to send it to you again or not. regards Fabio From lyon at docjava.com Tue Mar 21 00:51:18 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Tue, 21 Mar 2006 02:51:18 -0500 Subject: [Rxtx] lock files Message-ID: Hi All, You know, if the use of lock files were under Java control (rather than a build-time decision), it might enable a more unified binary distro. It might also facilitate quick prototyping of non-lock file approaches to resolving serial port contention issues (i.e., mac-like approaches vs. linux approaches, etc.). I realize that this is a radical overhaul of the lock file policy issue. Also, it may harm performance. On the other hand, our benchmarks on JNI overhead for modern processors indicate performance impact should be minimal. Perhaps it is more of an issue with the toybox systems. Suppose there were a class with a reasonable default...someone might write: SerialPortLockPolicy.setPolicy(SerialPortLockPolicy.UNIX_LOCK_FILE); SerialPortLockPolicy.setPolicy(SerialPortLockPolicy.NO_LOCK_CHECKING); SerialPortLockPolicy.setPolicy(SerialPortLockPolicy.MAC_STYLE); Thus, we could have a run-time reconfiguration of the serial port lock policy. A special NO_LOCK version of the binary would no longer be required. Any thoughts on this? Thanks! - Doug From joachim at buechse.de Tue Mar 21 03:09:09 2006 From: joachim at buechse.de (Joachim Buechse) Date: Tue, 21 Mar 2006 11:09:09 +0100 Subject: [Rxtx] lock files In-Reply-To: References: Message-ID: <8E12916A-1B9A-4FF2-B684-E2D1C794221B@buechse.de> This is pretty much what I thought about when I suggested, that the default behaviour could be overwritten with a property. I am very much in favor of this approach. In particular this allows much easier debugging for PC based java developers. I think big parts of the Java (and maybe some parts of the C code) could use a bit of a structural workover (unit tests, javadoc, synchronization, etc). Maybe there should be a CVS branch for this experimental version. I'd be happy to contribute a first workover for some of the Java code. Designing for testability and implementing a good bunch of unit tests has been a strategy that worked quite well in the Java projects I lead. And it ultimately allows more liberal change permission. Regards, Joachim On 21.03.2006, at 08:51, Dr. Douglas Lyon wrote: > Hi All, > You know, if the use of lock files were > under Java control (rather than a build-time decision), > it might enable a more unified binary distro. It might also > facilitate quick prototyping of non-lock file approaches > to resolving serial port contention issues (i.e., mac-like > approaches vs. linux approaches, etc.). > > I realize that this is a radical overhaul of the lock file policy > issue. Also, it may harm performance. On the other hand, > our benchmarks on JNI overhead for modern processors indicate > performance impact should be minimal. Perhaps it is more of > an issue with the toybox systems. > > Suppose there were a class with a reasonable default...someone > might write: > SerialPortLockPolicy.setPolicy(SerialPortLockPolicy.UNIX_LOCK_FILE); > SerialPortLockPolicy.setPolicy(SerialPortLockPolicy.NO_LOCK_CHECKING); > SerialPortLockPolicy.setPolicy(SerialPortLockPolicy.MAC_STYLE); > > Thus, we could have a run-time reconfiguration of the serial port lock > policy. A special NO_LOCK version of the binary would no longer > be required. > > Any thoughts on this? > > Thanks! > - Doug > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From joachim at buechse.de Tue Mar 21 06:23:08 2006 From: joachim at buechse.de (Joachim Buechse) Date: Tue, 21 Mar 2006 14:23:08 +0100 Subject: [Rxtx] PATCH: use of ioctl(fd, TIOCEXCL) instead of lockfiles Message-ID: <923AE774-EEA2-4911-92D8-32BB27802C8B@buechse.de> Here is the patch for the ioctl(fd, TIOCEXCL). I have verified this only for OSX 10.4.5, hence it is only defined for APPLE. However, it should work at least for Solaris as well. If a process has requested TIOEXCL further open calls by other user processes will fail. The patch also disables uucp style locking for APPLE. Obviously this is discussable. I think it is the way to go, as it eliminates creating the lock directory which doesnt exist on the standard installation and it eliminates messing with the system group definitions (adding users to group uucp). Regarding the possibility of root processes opening a device which is locked - I consider this a feature not a potential problem. It is highly unlikely, that somebody is crazy enough to run a JavaVM as root (unless he has no other means of getting a restricted IP port opened, ie doesnt understand ipfw). Anyway, even if the process runs as root, it fails when calling ioctl(fd, TIOCEXCL). It could however still open the port to listen for RING events. I.e. a fax server which needs to see incoming calls but otherwise doesnt want to block the port. So the only case where the proposed mechanism fails is, if an incorrectly implemented process running as root conflicts with a user process. I think this can be accepted. Regards, Joachim PS: If this patch is generally accepted, the installer and Mac doku should obviously be changed as well. Index: SerialImp.c =================================================================== RCS file: /usr/local/cvsroot/rxtx-devel/src/SerialImp.c,v retrieving revision 1.46.2.187 diff -u -r1.46.2.187 SerialImp.c --- SerialImp.c 29 Jan 2006 22:19:04 -0000 1.46.2.187 +++ SerialImp.c 21 Mar 2006 12:59:16 -0000 @@ -656,6 +656,25 @@ fd=OPEN (filename, O_RDWR | O_NOCTTY | O_NONBLOCK ); } while (fd < 0 && errno==EINTR); +#ifdef OPEN_EXCL + // Note that open() follows POSIX semantics: multiple open() calls to + // the same file will succeed unless the TIOCEXCL ioctl is issued. + // This will prevent additional opens except by root-owned processes. + // See tty(4) ("man 4 tty") and ioctl(2) ("man 2 ioctl") for details. + + if (fd >= 0 && (ioctl(fd, TIOCEXCL) == -1)) + { + sprintf( message, "open: exclusive access denied for % s\n", + filename ); + report( message ); + report_error( message ); + + close(fd); + goto fail; + } +#endif /* OPEN_EXCL */ + + if( configure_port( fd ) ) goto fail; (*env)->ReleaseStringUTFChars( env, jstr, filename ); sprintf( message, "open: fd returned is %i\n", fd ); Index: SerialImp.h =================================================================== RCS file: /usr/local/cvsroot/rxtx-devel/src/SerialImp.h,v retrieving revision 1.11.2.49 diff -u -r1.11.2.49 SerialImp.h --- SerialImp.h 5 Jul 2005 17:47:21 -0000 1.11.2.49 +++ SerialImp.h 21 Mar 2006 12:59:17 -0000 @@ -135,7 +135,8 @@ /*# define LOCKDIR "/var/spool/uucp"*/ # define LOCKDIR "/var/lock" # define LOCKFILEPREFIX "LK." -# define UUCP +/*# define UUCP*/ +# define OPEN_EXCL #endif /* __APPLE__ */ #if defined(__NetBSD__) # define DEVICEDIR "/dev/" From tjarvi at qbang.org Tue Mar 21 10:26:08 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 21 Mar 2006 10:26:08 -0700 (MST) Subject: [Rxtx] Javadoc on the go In-Reply-To: <441FA98B.9050701@ngi.it> References: <441FA98B.9050701@ngi.it> Message-ID: On Tue, 21 Mar 2006, Fabio Frumento wrote: > Hi Trent, > > sorry for the big delay but my job is running wild, i was out for some > time but now i'm back and ready to continue the javadoc for Rxtx. > > Did you used the last javadoc patch i sent you ? let me know if i have to > send it to you again or not. > > regards > > Fabio Hi Fabio The patch is in the rxtx mail-list archives. It will be going in soon. I did not see a time critical portion. I'll probably be going through the list since the last batch of patches this weekend and putting them into CVS. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Tue Mar 21 10:57:18 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 21 Mar 2006 10:57:18 -0700 (MST) Subject: [Rxtx] jvm issue In-Reply-To: <20060321065524.94779.qmail@web50701.mail.yahoo.com> References: <20060321065524.94779.qmail@web50701.mail.yahoo.com> Message-ID: On Mon, 20 Mar 2006, Lambok Sianturi wrote: > Hi All, > This is my first time to join RxTx mailing list. I thank you all for allowing others to sign in in requests help. > I use the latest RxTx lib in Fedora 3 with java version 1.4.2_09 b05. And I got this error: > > # > # An unexpected error has been detected by HotSpot Virtual Machine: > # > # SIGSEGV (0xb) at pc=0x00bf27f3, pid=2633, tid=3086112448 > # > # Java VM: Java HotSpot(TM) Client VM (1.4.2_09-b05 mixed mode) > # Problematic frame: > # C [ld-linux.so.2+0xa7f3] A native library loading error? What happens if you recompile rxtx on your system and install that? This sounds like an ABI problem? rxtx 2.1-7 was compiled with a gcc 2.96 toolchain as I recall. The hope is newer system will be backwards compatible. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Tue Mar 21 11:05:29 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 21 Mar 2006 11:05:29 -0700 (MST) Subject: [Rxtx] PATCH: use of ioctl(fd, TIOCEXCL) instead of lockfiles In-Reply-To: <923AE774-EEA2-4911-92D8-32BB27802C8B@buechse.de> References: <923AE774-EEA2-4911-92D8-32BB27802C8B@buechse.de> Message-ID: On Tue, 21 Mar 2006, Joachim Buechse wrote: > Here is the patch for the ioctl(fd, TIOCEXCL). I have verified this only > for OSX 10.4.5, hence it is only defined for APPLE. However, it should > work at least for Solaris as well. > > If a process has requested TIOEXCL further open calls by other user > processes will fail. > > The patch also disables uucp style locking for APPLE. Obviously this is > discussable. I think it is the way to go, as it eliminates creating the > lock directory which doesnt exist on the standard installation and it > eliminates messing with the system group definitions (adding users to > group uucp). > > Regarding the possibility of root processes opening a device which is > locked - I consider this a feature not a potential problem. It is highly > unlikely, that somebody is crazy enough to run a JavaVM as root (unless > he has no other means of getting a restricted IP port opened, ie doesnt > understand ipfw). Anyway, even if the process runs as root, it fails when > calling ioctl(fd, TIOCEXCL). It could however still open the port to > listen for RING events. I.e. a fax server which needs to see incoming > calls but otherwise doesnt want to block the port. So the only case where > the proposed mechanism fails is, if an incorrectly implemented process > running as root conflicts with a user process. I think this can be > accepted. > > Regards, > Joachim > > PS: If this patch is generally accepted, the installer and Mac doku > should obviously be changed as well. > > > Index: SerialImp.c > =================================================================== > RCS file: /usr/local/cvsroot/rxtx-devel/src/SerialImp.c,v > retrieving revision 1.46.2.187 > diff -u -r1.46.2.187 SerialImp.c > --- SerialImp.c 29 Jan 2006 22:19:04 -0000 1.46.2.187 > +++ SerialImp.c 21 Mar 2006 12:59:16 -0000 > @@ -656,6 +656,25 @@ > fd=OPEN (filename, O_RDWR | O_NOCTTY | O_NONBLOCK ); > } while (fd < 0 && errno==EINTR); > > +#ifdef OPEN_EXCL > + // Note that open() follows POSIX semantics: multiple open() > calls to > + // the same file will succeed unless the TIOCEXCL ioctl is > issued. > + // This will prevent additional opens except by root-owned > processes. > + // See tty(4) ("man 4 tty") and ioctl(2) ("man 2 ioctl") for > details. > + > + if (fd >= 0 && (ioctl(fd, TIOCEXCL) == -1)) > + { > + sprintf( message, "open: exclusive access denied for % > s\n", > + filename ); > + report( message ); > + report_error( message ); > + > + close(fd); > + goto fail; > + } > +#endif /* OPEN_EXCL */ > + > + > if( configure_port( fd ) ) goto fail; > (*env)->ReleaseStringUTFChars( env, jstr, filename ); > sprintf( message, "open: fd returned is %i\n", fd ); > Index: SerialImp.h > =================================================================== > RCS file: /usr/local/cvsroot/rxtx-devel/src/SerialImp.h,v > retrieving revision 1.11.2.49 > diff -u -r1.11.2.49 SerialImp.h > --- SerialImp.h 5 Jul 2005 17:47:21 -0000 1.11.2.49 > +++ SerialImp.h 21 Mar 2006 12:59:17 -0000 > @@ -135,7 +135,8 @@ > /*# define LOCKDIR "/var/spool/uucp"*/ > # define LOCKDIR "/var/lock" > # define LOCKFILEPREFIX "LK." > -# define UUCP > +/*# define UUCP*/ > +# define OPEN_EXCL > #endif /* __APPLE__ */ > #if defined(__NetBSD__) > # define DEVICEDIR "/dev/" > This looks like a good start. What do you think Dmitry? Perhaps all systems with TIOCEXCL defined should use that though. Even if they use lockfiles. It wont hurt anything. That would catch people hacking their own serial apps without checking lockfiles. Its a good idea to avoid C++ style comments in the C portions. Some older systems don't deal with them well. If it's just for Mac OS X, it isn't a big deal. I think it was the Irix compiler that was problematic? -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Tue Mar 21 11:22:05 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 21 Mar 2006 11:22:05 -0700 (MST) Subject: [Rxtx] lock files In-Reply-To: <8E12916A-1B9A-4FF2-B684-E2D1C794221B@buechse.de> References: <8E12916A-1B9A-4FF2-B684-E2D1C794221B@buechse.de> Message-ID: We can try it. Maybe the JNI is much improved. The nice thing about linking into liblock is distros then worry about lockfiles on their systems. This way, we have to deal with any changes that may show up. On Tue, 21 Mar 2006, Joachim Buechse wrote: > This is pretty much what I thought about when I suggested, that the > default behaviour could be overwritten with a property. I am very much in > favor of this approach. In particular this allows much easier debugging > for PC based java developers. > > I think big parts of the Java (and maybe some parts of the C code) could > use a bit of a structural workover (unit tests, javadoc, synchronization, > etc). Maybe there should be a CVS branch for this experimental version. > I'd be happy to contribute a first workover for some of the Java code. > Designing for testability and implementing a good bunch of unit tests has > been a strategy that worked quite well in the Java projects I lead. And > it ultimately allows more liberal change permission. > > Regards, > Joachim > > > On 21.03.2006, at 08:51, Dr. Douglas Lyon wrote: > >> Hi All, >> You know, if the use of lock files were >> under Java control (rather than a build-time decision), >> it might enable a more unified binary distro. It might also >> facilitate quick prototyping of non-lock file approaches >> to resolving serial port contention issues (i.e., mac-like >> approaches vs. linux approaches, etc.). >> >> I realize that this is a radical overhaul of the lock file policy >> issue. Also, it may harm performance. On the other hand, >> our benchmarks on JNI overhead for modern processors indicate >> performance impact should be minimal. Perhaps it is more of >> an issue with the toybox systems. >> >> Suppose there were a class with a reasonable default...someone >> might write: >> SerialPortLockPolicy.setPolicy(SerialPortLockPolicy.UNIX_LOCK_FILE); >> SerialPortLockPolicy.setPolicy(SerialPortLockPolicy.NO_LOCK_CHECKING); >> SerialPortLockPolicy.setPolicy(SerialPortLockPolicy.MAC_STYLE); >> >> Thus, we could have a run-time reconfiguration of the serial port lock >> policy. A special NO_LOCK version of the binary would no longer >> be required. >> >> Any thoughts on this? >> >> Thanks! >> - Doug >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From dmarkman at mac.com Tue Mar 21 16:05:17 2006 From: dmarkman at mac.com (Dmitry Markman) Date: Tue, 21 Mar 2006 18:05:17 -0500 Subject: [Rxtx] PATCH: use of ioctl(fd, TIOCEXCL) instead of lockfiles In-Reply-To: References: <923AE774-EEA2-4911-92D8-32BB27802C8B@buechse.de> Message-ID: <512AC70C-BB86-48F2-A83C-023F35C23BAB@mac.com> I think it's cool, but I'd like to have that property implementation when user can choose between locking mechanism about comments: it's easy to change comments to the C style or we can use extensions of the file to cpp so c++ compiler will be used On Mar 21, 2006, at 1:05 PM, Trent Jarvi wrote: > This looks like a good start. What do you think Dmitry? Perhaps > all systems with TIOCEXCL defined should use that though. Even if > they use lockfiles. It wont hurt anything. That would catch > people hacking their own serial apps without checking lockfiles. > > Its a good idea to avoid C++ style comments in the C portions. > Some older systems don't deal with them well. If it's just for Mac > OS X, it isn't a big deal. I think it was the Irix compiler that > was problematic? Dmitry Markman From dmarkman at mac.com Tue Mar 21 16:13:00 2006 From: dmarkman at mac.com (Dmitry Markman) Date: Tue, 21 Mar 2006 18:13:00 -0500 Subject: [Rxtx] PATCH: use of ioctl(fd, TIOCEXCL) instead of lockfiles In-Reply-To: References: <923AE774-EEA2-4911-92D8-32BB27802C8B@buechse.de> Message-ID: I'd like to add that creating locking folder isn't a big deal we never had a problem related to the lock folders, because we always used installer on mac os x from other hand I'm not very much familiar with iotcl locking approach and I'm not sure it's more efficient Joachim wrote "I think it is the way to go, as it eliminates creating the lock directory which doesnt exist on the standard installation and it eliminates messing with the system group definitions (adding users to group uucp)." but I really didn't have any problem with that 1. doesn't exist on the standard installation there are many-many things that don't exist in the standard installation so I don't think that argument is strong enough 2. messing with the system group definitions I don't think we're messing with the group definition mac os x provides very clear way to set up group's members and together with Greg Guerin AuthKit there is no problem to set those definitions so I don't think that argument is strong either but from other hand using iotcl is more promising and is more elegant On Mar 21, 2006, at 1:05 PM, Trent Jarvi wrote: > > This looks like a good start. What do you think Dmitry? Perhaps > all systems with TIOCEXCL defined should use that though. Even if > they use lockfiles. It wont hurt anything. That would catch > people hacking their own serial apps without checking lockfiles. Dmitry Markman From joachim at buechse.de Wed Mar 22 04:46:45 2006 From: joachim at buechse.de (Joachim Buechse) Date: Wed, 22 Mar 2006 12:46:45 +0100 Subject: [Rxtx] PATCH: use of ioctl(fd, TIOCEXCL) instead of lockfiles In-Reply-To: References: <923AE774-EEA2-4911-92D8-32BB27802C8B@buechse.de> Message-ID: Sorry, I was not very clear with my arguments, so I will try again;-) Please, don't take this as an attack against work that has been done. I think the contributions that have been made in the past were made in a good spirit. But I really believe, that the current solution for OSX has many shortcomings and should be changed as soon as possible. lock files --- The /var/lock folder does not exist on the standard OSX installation, however the standard installation includes several applications that use serial ports (i.e. the FAX capability). This indicates, that the lock folder approach will not work well with system components. Applications for OSX will generally try to live in harmony with system components (except for HP print drivers of course). I think RXTX should follow this approach as well. uucp group --- Accessing serial ports is not an admin privileged operation on OSX. Any user (world) has read/write privileges on /dev/tty*. So the system default is to not enforce any group membership to access these ports. The group uucp however is a system group on all unix systems I know. It exists for certain system processes. A non admin user should in general not be a member of this group. Quite arguably no user should ever be a member of this group. Installer --- My general opinion is, that - no Installer should touch user or group data without warning - no Application Installer should touch groups which are not specific to the very application installed - no Installer should ever add regular users to a system group The current installer injects the installing user in the group uucp without warning about this change and without giving the option to "opt out" of this change. This is a potential security risk (but not currently a real one, as OSX contains no folders belonging to group uucp). The current installer does not work for multi user systems. It puts the installing user in the uucp group. However the installing user is not necessarily the user that will use the application. Putting all users that may use a serial port application in the system group uucp seems like a very invasive approach to me. Besides that, newly created users will not automatically be in the group and hence, serial applications will "break" for new users without obvious reasons. Avoiding the lock files will allow self contained applications (i.e. drag&drop installation). In my eyes this is largely preferable over an installer that requests admin privileges. Adding up all these points indicates very strongly, that the lock-file implementation is not the way to go on OSX. Regards, Joachim On 22.03.2006, at 00:13, Dmitry Markman wrote: > I'd like to add that > > creating locking folder isn't a big deal > we never had a problem related to the lock folders, because we > always used installer on mac os x > from other hand I'm not very much familiar with iotcl locking > approach and I'm not sure it's more efficient > > Joachim wrote "I think it is the way to go, as it eliminates > creating the lock directory which doesnt exist on the standard > installation and it eliminates messing with the system group > definitions (adding users to group uucp)." but I really didn't have > any problem with that > > 1. doesn't exist on the standard installation > there are many-many things that don't exist in the standard > installation so I don't think that argument is strong enough > 2. messing with the system group definitions > I don't think we're messing with the group definition > mac os x provides very clear way to set up group's members and > together with Greg Guerin AuthKit there is no problem to set those > definitions > so I don't think that argument is strong either > but from other hand using iotcl is more promising and is more elegant > > > > On Mar 21, 2006, at 1:05 PM, Trent Jarvi wrote: > >> >> This looks like a good start. What do you think Dmitry? Perhaps >> all systems with TIOCEXCL defined should use that though. Even if >> they use lockfiles. It wont hurt anything. That would catch >> people hacking their own serial apps without checking lockfiles. > > Dmitry Markman > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From dmarkman at mac.com Wed Mar 22 05:27:13 2006 From: dmarkman at mac.com (Dmitry Markman) Date: Wed, 22 Mar 2006 07:27:13 -0500 Subject: [Rxtx] PATCH: use of ioctl(fd, TIOCEXCL) instead of lockfiles In-Reply-To: References: <923AE774-EEA2-4911-92D8-32BB27802C8B@buechse.de> Message-ID: <83440CF3-DCD8-41C1-B941-F227232C27E3@mac.com> thanks for the very good explanation I didn't think that you were attacking any thing, so don't worry I just had feeling, that there were more aesthetic reasons for going to ioctl then real necessity now you explained everything quite well (BTW, asfar as I remember installer asks admin password so it wasn't quiet, but it really doesn't matter now) thanks On Mar 22, 2006, at 6:46 AM, Joachim Buechse wrote: > Sorry, I was not very clear with my arguments, so I will try again;-) > > Please, don't take this as an attack against work that has been > done. I think the contributions that have been made in the past > were made in a good spirit. But I really believe, that the current > solution for OSX has many shortcomings and should be changed as > soon as possible. > > lock files > --- > The /var/lock folder does not exist on the standard OSX > installation, however the standard installation includes several > applications that use serial ports (i.e. the FAX capability). This > indicates, that the lock folder approach will not work well with > system components. Applications for OSX will generally try to live > in harmony with system components (except for HP print drivers of > course). I think RXTX should follow this approach as well. > > uucp group > --- > Accessing serial ports is not an admin privileged operation on OSX. > Any user (world) has read/write privileges on /dev/tty*. So the > system default is to not enforce any group membership to access > these ports. The group uucp however is a system group on all unix > systems I know. It exists for certain system processes. A non admin > user should in general not be a member of this group. Quite > arguably no user should ever be a member of this group. > > Installer > --- > My general opinion is, that > - no Installer should touch user or group data without warning > - no Application Installer should touch groups which are not > specific to the very application installed > - no Installer should ever add regular users to a system group > > The current installer injects the installing user in the group uucp > without warning about this change and without giving the option to > "opt out" of this change. This is a potential security risk (but > not currently a real one, as OSX contains no folders belonging to > group uucp). > > The current installer does not work for multi user systems. It puts > the installing user in the uucp group. However the installing user > is not necessarily the user that will use the application. Putting > all users that may use a serial port application in the system > group uucp seems like a very invasive approach to me. Besides that, > newly created users will not automatically be in the group and > hence, serial applications will "break" for new users without > obvious reasons. > > > Avoiding the lock files will allow self contained applications > (i.e. drag&drop installation). In my eyes this is largely > preferable over an installer that requests admin privileges. Adding > up all these points indicates very strongly, that the lock-file > implementation is not the way to go on OSX. > > Regards, > Joachim > > > On 22.03.2006, at 00:13, Dmitry Markman wrote: > >> I'd like to add that >> >> creating locking folder isn't a big deal >> we never had a problem related to the lock folders, because we >> always used installer on mac os x >> from other hand I'm not very much familiar with iotcl locking >> approach and I'm not sure it's more efficient >> >> Joachim wrote "I think it is the way to go, as it eliminates >> creating the lock directory which doesnt exist on the standard >> installation and it eliminates messing with the system group >> definitions (adding users to group uucp)." but I really didn't >> have any problem with that >> >> 1. doesn't exist on the standard installation >> there are many-many things that don't exist in the standard >> installation so I don't think that argument is strong enough >> 2. messing with the system group definitions >> I don't think we're messing with the group definition >> mac os x provides very clear way to set up group's members and >> together with Greg Guerin AuthKit there is no problem to set those >> definitions >> so I don't think that argument is strong either >> but from other hand using iotcl is more promising and is more elegant >> >> >> >> On Mar 21, 2006, at 1:05 PM, Trent Jarvi wrote: >> >>> >>> This looks like a good start. What do you think Dmitry? Perhaps >>> all systems with TIOCEXCL defined should use that though. Even >>> if they use lockfiles. It wont hurt anything. That would catch >>> people hacking their own serial apps without checking lockfiles. >> >> Dmitry Markman >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx Dmitry Markman From lyon at docjava.com Wed Mar 22 06:12:18 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Wed, 22 Mar 2006 08:12:18 -0500 Subject: [Rxtx] sole of a new design pattern Message-ID: Hi All, I have been thinking about how we design the serial port software. I think we need a new design pattern. For lack of a better term, I shall call it: The Parametric Singleton Design Pattern By Douglas A. Lyon ABSTRACT The goal of the singleton design pattern is to make sure that there is one, and only one, instance of a given class. The goal of the parametric singleton design pattern is to make sure that there is one, and only one, instance of a given class with the given parametric values. We parametric singleton design pattern combines the singleton design pattern with a parameter that enables unique creation of instances of a class. These instances are cached. When a user asks for an instance with these parameters, the cache is checked. If the instance is in the cache, the instance is returned, otherwise it is created, added to the cache and then returned. We apply our parametric singleton design pattern to the retrieval of RMI registries bound to a given port. The goal of our system is to make sure that no two RMI registries are listening to the same socket and to make use of the RMI registries after they have been created. RMI registries are used in distributed computation. Introduction The singleton design pattern is meant to ensure that on a single instance of a class exists. It is also meant to provide a global point of access to it. The intent of the parametric singleton design pattern is to ensure that a class has only one instance for a given set of parameter values. It also provides a global point of access to it. Motivation A system cannot tolerate multiple instances of some classes with identical parameters. For example, you cannot have two instances making use of the same serial port, at the same time. You cannot have two instances that are trying to listen to the same socket connection. You cannot have two instances writing to the same file structure at the same time. As the operating system is often thought of as the arbiter of consumed resources (i.e., tape drives, serial ports, etc.) we frequently leave it to an operating system implementation to resolve these contention issues. Even for similar resources (like serial ports) there are few standards for handling contention. For example, serial ports on Linux are locked using a "/var/lock" file. POSIX, on the other hand, uses ioctl mechanisms to prevent contention. A better solution is to make a class that is responsible for keeping track of the instances created from the class. The class is declared final, so that it cannot be subclassed. The class also has a private constructor, so that other classes cannot instance it. The new design pattern is called the parametric singleton design pattern and it provides a way to access and create instances with given parameters. Applicability Use the Parametric Singleton Design Pattern when: 1. There must be exactly one instance of a class with the given parameters. 2. The instances must be accessible to clients from a well-known access point. Structure Insert UML diagram here. Participants The Parametric Singleton Clients that need instances 1. The Parametric Singleton defines an instance upon request from a client, if, and only if, the instance does not already exist. 2. The Parametric Singleton returns the instance to the client. 3. The Parametric Singleton is responsible for creating unique instances from given parameters. Collaborations Clients obtain a reference to a Parametric Singleton instance only through the parametric singleton design pattern. If the instance is left in an improper state (e.g., the serial port was left open) it is NOT the role of the Parametric Singleton Design Pattern to close the IO port. Nor is it the role of the Parametric Singleton Design Pattern to open the port. That role is delegate to some other part of the system. Further, it is not the role of the Parametric Singleton Design Pattern to check out resources. That is, multiple threads can have multiple references to the same resource at the same time. MUTEX locking is delegated to some other part of the system. Consequences The Parametric Singleton Design Pattern has several benefits: 1. Controlled access to parametrically defined instances. Since the Parametric Singleton class encapsulates its instances, there is control over how and when clients access it. 2. Reduced name space. The Parametric Singleton pattern avoids global variables that store instances created from the same parameter. Implementation Here are implementation issues to consider when using the Parametric Singleton pattern: 1. Unique mapping of parameters. The Parametric Singleton pattern requires that there be a mean to isomorphically map the parameter space into the instance space and back again. 2. Ensure unique instances. The Parametric Singleton pattern makes unique instances from parameters, and it does so only once. 3. Cache instances for fast retrieval. The Parametric Singleton pattern must be able to look up instances, given some set of parameters, and do so from some data structure. That is, there must be enough space to hold references to all the instances the program will need. Also, a mechanism is needed to look up and retrieve the instances quickly enough to satisfy the clients. Sample Code public final class ParametricSingletonRmiRegistry { private static Hashtable registry = new Hashtable(100); // use singleton pattern and??????????????????????????????????????????????? // prevent instantiation of RmiRegistryUtils.?????????????????????????????? private ParametricSingletonRmiRegistry() { } // the only instance of the Registry held by the RmiRegistryUtils?????????? public static void listNames(Integer port) { if (!isInCacheAndRunning(port)) return; Registry r = (Registry) registry.get(port); System.out.println("registry on port: " + port); System.out.println("registry: " + r); System.out.println("names: "); try { print(r.list()); } catch (RemoteException e) { In.message(e); } System.out.println("------------------------"); } /**???????????????????????????????????????????????????????????????????????? * Checks whether a Registry has been started on this host????????????????? * in the specified port.?????????????????????????????????????????????????? * If not, it tries to start one.?????????????????????????????????????????? * when it fails to start a Registry, it exits the program????????????????? * with exit code 1.??????????????????????????????????????????????????????? */ public static void restart(int port) { if (isInCacheAndRunning(port)) return; try { startRegistry(port); } catch (RemoteException e) { In.message(e); } } /**???????????????????????????????????????????????????????????????????????? * @param port????????????????????????????????????????????????????????????? * @return true if registry is in cache and running???????????????????????? */ private static boolean isInCacheAndRunning(Integer port) { if (!isRegistryRunning(port.intValue())) return false; if (!isRegistryInCache(port.intValue())) return false; return true; } /**???????????????????????????????????????????????????????????????????????? * @param port????????????????????????????????????????????????????????????? * @return true if we are able to locate a local registry on port.??????????????????????????????????????????????????????????????????????????? */ private static boolean isRegistryRunning(int port) { try { Registry r = LocateRegistry.getRegistry(port); if (r != null) return true; } catch (RemoteException e) { return false; } return false; } /**???????????????????????????????????????????????????????????????????????? * @param port????????????????????????????????????????????????????????????? * @return return true if registry is in cache????????????????????????????? */ private static boolean isRegistryInCache(int port) { if (registry.get(new Integer(port)) == null) return false; return true; } /**???????????????????????????????????????????????????????????????????????? * Restart the registry, if needed.???????????????????????????????????????? * Return the only instance of the registry for consistent global?????????? * using by making use of the Singleton Design Pattern????????????????????? *????????????????????????????????????????????????????????????????????????? * @return the internally held registry instance.?????????????????????????? */ public static Registry getRegistry(Integer port) { restart(port); return (Registry) registry.get(port); } private static void startRegistry(Integer port) throws RemoteException { Registry r; try { r = LocateRegistry.createRegistry(port.intValue()); registry.put(port, r); //r = new sun.rmi.registry.RegistryImpl???????????????????????????? /// (port.intValue());?????????????????????????????????????? // registry.put(port, r);?????????????????????????????????????????? } catch (Exception e) { //e.printStackTrace();????????????????????????????????????????????? r = LocateRegistry.getRegistry(port.intValue()); registry.put(port, r); } } public static void main(String args[]) throws RemoteException { //restart(port);??????????????????????????????????????????????????????? restart(5001); restart(5002); restart(5002); Registry r = LocateRegistry.getRegistry(5002); System.out.println("registry="+r); } } I would very much like to get your feedback on this new design pattern idea. Thank you for your time. Regards, - Doug From david.garnier at trusted-logic.com Wed Mar 22 07:36:10 2006 From: david.garnier at trusted-logic.com (David Garnier) Date: Wed, 22 Mar 2006 15:36:10 +0100 Subject: [Rxtx] sole of a new design pattern In-Reply-To: References: Message-ID: <442160DA.80107@trusted-logic.com> Hello, > The Parametric Singleton Design Pattern The Singleton is the most abused design pattern ever. Good use-cases for this pattern are extremely rare and mostly confined to problems related to hardware resources, like serial ports. > Applicability > > Use the Parametric Singleton Design Pattern when: > 1. There must be exactly one instance of a class with the given > parameters. OK. As I said above, this case this actually very unusual. The Singleton pattern is mostly used when : > 2. The instances must be accessible to clients from a well-known > access point. Using the singleton pattern in this case is just convenient for the programmer. Problems arises pretty quickly, especially if you attempt to unit-test your classes. 1) If your singleton is stateful, or hold on to stateful objects, it means that two different unit tests are not actually independent. Instead of starting with a brand new environment, the result of a test may be affected by the result of a previous test. This problem also arise when with your class relies on a database. In both cases, the solution is to reset your "unique" resource (Singleton or database) at the beginning of the test, which is a pain. Also, while most projects connect to a single database, projects that allow the use of Singletons usually contain several of thems, and new ones may cropped up unnoticed. You quickly end up with test cases that only pass in a certain order, which is a royal pain. 2) You cannot mockup a singleton. Once everyone calls the SomeSingleton class statically, you can't replace your class by SomeSingletonMockup. Furthermore, even for hardware services, the Singleton pattern does not really prevent concurrent accesses. If you start the same program in two different JVMs, unless they somehow shared the state of their "Singletons" (through lock files for example), the Singleton pattern will not prevent concurrent access. Our application uses RXTX, and we routinely encounter cases where another (native) application has already locked the port. Since we cannot modify the native application to recognize lock files, OS-level control is irreplaceable. > > Consequences > The Parametric Singleton Design Pattern has several benefits: > > 1. Controlled access to parametrically defined instances. Since > the Parametric Singleton class encapsulates its instances, there is > control over how and when clients access it. Not really. Once you've returned the instance to a client, you've lost control over it. The client can to whatever it wants with it. You cannot "recall" the instance or claim it back. > 2. Reduced name space. The Parametric Singleton pattern avoids > global variables that store instances created from the same parameter. Sure, but you don't have to rely on a Singleton for that. Just create a single Factory. > I would very much like to get your feedback on this new design > pattern idea. Well, it's nothing new. Some may say that it is the point of design patterns: formalizes the designs that occur again and again. However, this design is simply a combination of the Singleton and Factory patterns. I did use it in the past, but now I've been exposed to the shortcomings of the Singleton pattern, so I limit myself to Factories. Regards, David From sean_montgomery at baseview.com Wed Mar 22 08:35:28 2006 From: sean_montgomery at baseview.com (Sean Montgomery) Date: Wed, 22 Mar 2006 10:35:28 -0500 Subject: [Rxtx] sole of a new design pattern In-Reply-To: <442160DA.80107@trusted-logic.com> References: <442160DA.80107@trusted-logic.com> Message-ID: <05769CA7-A51B-4CF0-BAA0-E02DD905F5A4@baseview.com> On Mar 22, 2006, at 9:36 AM, David Garnier wrote: > Furthermore, even for hardware services, the Singleton pattern does > not really prevent concurrent > accesses. If you start the same program in two different JVMs, > unless they somehow shared the state > of their "Singletons" (through lock files for example), the > Singleton pattern will not prevent > concurrent access. > Multiple class loaders in a single JVM can be tricky, too. Then there's synchronization, lazy initialization and serialization of singletons to contend with. Bloch's Effective Java covers these, and here's a few articles: http://www.javaworld.com/javaworld/jw-04-2003/jw-0425-designpatterns- p3.html http://java.sun.com/developer/technicalArticles/Programming/singletons/ Just FYI :-) From lyon at docjava.com Wed Mar 22 08:50:48 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Wed, 22 Mar 2006 10:50:48 -0500 Subject: [Rxtx] sole of a new design pattern In-Reply-To: <442160DA.80107@trusted-logic.com> References: <442160DA.80107@trusted-logic.com> Message-ID: Hi All, First, I would like to thank David for his prompt and thoughtful remarks. I had no idea people that feel strongly about a design patterns! Wow! Feedback (particularly critical feedback) is greatly appreciated. Starting at the end, first: >I did use it in >the past, but now I've been exposed to the shortcomings of the >Singleton pattern, so I limit myself to Factories. David, if I understood your comments correctly, you suggested that Factories can be used in leu of the Singleton Design Pattern, or even the Parametric Singleton Design Pattern. As I see in [Gof]: Factory Method: Intent "Define an interface for creating an object, but let subclasses decide which class to instantiate. Factory Method lets a class defer instantiation to subclasses." The Singleton Design Pattern is a concrete class, which is rather different, right? Also, subclasses are not permitted with Singleton, as they are final. Naturally, I could use an abstract factory as a parent for a singleton. I could even design a facade that could be implemented with the singleton....but that is not the intention of the design. Unless you want a mock-up, as discussed, below: More below: >Hello, > >> The Parametric Singleton Design Pattern > >The Singleton is the most abused design pattern ever. Good use-cases >for this pattern are extremely >rare and mostly confined to problems related to hardware resources, >like serial ports. > > >> Applicability >> >> Use the Parametric Singleton Design Pattern when: >> 1. There must be exactly one instance of a class with the given >> parameters. >OK. As I said above, this case this actually very unusual. The >Singleton pattern is mostly used when : >> 2. The instances must be accessible to clients from a well-known >> access point. > >Using the singleton pattern in this case is just convenient for the >programmer. Problems arises >pretty quickly, especially if you attempt to unit-test your classes. > >1) If your singleton is stateful, or hold on to stateful objects, it >means that two different unit >tests are not actually independent. Instead of starting with a brand >new environment, the result of >a test may be affected by the result of a previous test. This >problem also arise when with your >class relies on a database. In both cases, the solution is to reset >your "unique" resource >(Singleton or database) at the beginning of the test, which is a >pain. Also, while most projects >connect to a single database, projects that allow the use of >Singletons usually contain several of >thems, and new ones may cropped up unnoticed. You quickly end up >with test cases that only pass in a >certain order, which is a royal pain. There are basic problems with communicating finite state machines that include reachability and deadlock analysis. These are addressed with petri net analysis and are beyond the scope of the design pattern. As you quite rightly pointed out; the parametric singleton pattern (or the singleton pattern, for that matter) enable multiple threads to gain access to the same instance. The only way that I can see to block others from gaining access to the reference is the synchronize keyword. This is putting a spin-lock (or MUTEX) on the reference. The question of how to unit-test a design pattern like the parametric singleton remains open. Perhaps this is a deficiency. > >2) You cannot mockup a singleton. Once everyone calls the >SomeSingleton class statically, you can't >replace your class by SomeSingletonMockup. Acutally, I am not sure that this is true. If the Singleton implements a Facade interface, it should be possible to make the replacement. Right? > >Furthermore, even for hardware services, the Singleton pattern does >not really prevent concurrent >accesses. If you start the same program in two different JVMs, >unless they somehow shared the state >of their "Singletons" (through lock files for example), the >Singleton pattern will not prevent >concurrent access. Good Point!! You have sharp eyes! The singleton design pattern should/could take responsibility for this. In fact, you may notice that my code does have an implementation (LocateRegistry) that can work across JVM's. The LocateRegistry will even work across the Internet! LocateRegistry takes both a host name and a Port (lock files just don't do this). I did not think to implement this beyond the local machine, but, in its present form, it will work across different processes. > >Our application uses RXTX, and we routinely encounter cases where >another (native) application has >already locked the port. Since we cannot modify the native >application to recognize lock files, >OS-level control is irreplaceable. The singleton design pattern is not meant to replace OS-level control, but to centralize the Java programmers access to it. If lock files, for example, are used for serial ports, the Singleton Design Pattern should be able to work with them. > > >> >> Consequences >> The Parametric Singleton Design Pattern has several benefits: >> > > 1. Controlled access to parametrically defined instances. Since >> the Parametric Singleton class encapsulates its instances, there is >> control over how and when clients access it. > >Not really. Once you've returned the instance to a client, you've >lost control over it. The client >can to whatever it wants with it. You cannot "recall" the instance >or claim it back. Good point, this should read: > 1. Controll when parametrically defined instances are created. Since > > the Parametric Singleton class encapsulates its instances, there is > > control over how and when they are instanced. > >> 2. Reduced name space. The Parametric Singleton pattern avoids >> global variables that store instances created from the same parameter. > >Sure, but you don't have to rely on a Singleton for that. Just >create a single Factory. > > Thank you for your thoughtful and prompt response! Regards, - Doug From dmarkman at mac.com Wed Mar 22 21:21:55 2006 From: dmarkman at mac.com (Dmitry Markman) Date: Wed, 22 Mar 2006 23:21:55 -0500 Subject: [Rxtx] sole of a new design pattern In-Reply-To: <442160DA.80107@trusted-logic.com> References: <442160DA.80107@trusted-logic.com> Message-ID: I don't think I get it On Mar 22, 2006, at 9:36 AM, David Garnier wrote: > Using the singleton pattern in this case is just convenient for the > programmer. Problems arises > pretty quickly, especially if you attempt to unit-test your classes. so you're saying that something isn't so good because you can not test it in the convenient way? if that's true, I'm totally disagree change your test, debug whatever, but if software is efficient at runtime, works fine and only problem is some unit test (which is some kind of framework for testing) then dump that unit test , dump that unit framework and make something appropriate to the software you're testing so if Douglas want to use singletons, what's the problem? and what do you mean by abusing of singleton usage? of course singleton doesn't prevent concurrent access to the resource across the processes unless you're using some OS facility to prevent it, besides singleton as it was introduced is relevant only and only inside of the same process otherwise it's not singleton it's something else (let's say network singleton: so you have remote invocation facility and some factory method that return object created by that facility) I don't have any problem with using any kind of singletons. Parametric Singleton idea (if I understand it right) could be easily implemented in the following way: use a map populate map with instances of some class and key is your parameter (you can use lazy population too) if somebody ask the key check the value if it's null so resource is taken if somebody returns the resource put it back to the map public synchronized static Object getSomeResource(Object parameter); public synchronized static void returnResource(Object parameter); getSomeResource (inside of the same process) could return null in 2 cases 1. if somebody (from other thread for example) already took that resource 2. if OS API said that resource corresponded to that parameter (serial port with parameter = 1 (port #)) is locked and unavailable; I'm not sure that in case of serial ports we even need those Parametric Singletons (unless lock checking is a very expensive operation) just ask the OS about availability of that resource and if it's available give it away and then OS will lock it and therefore in next time somebody ask it just answer that resource is locked and return null for example system has 2 serial ports available so I ask getResource("tty"); or I ask getResource("Bluetooth-Modem"); and if OS is ok you can give tty or Bluetooth-Modem or both no need for any additional pattern I think back to the problem mac os x doesn't recognize locking via files, so it handles locking via some API an instance of the singleton in each process should recognize that resource is locked (by using that API) that's all we don't have to make things more complicate then they are just because there is some nice design pattern or nice unit test framework or whatever keep things simple, make them work fast, don't introduce middle layers unless you have really good reason to do so of course I could be entirely wrong, so sorry about that in advance thanks Dmitry Markman From tjarvi at qbang.org Wed Mar 22 22:31:41 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 22 Mar 2006 22:31:41 -0700 (MST) Subject: [Rxtx] sole of a new design pattern In-Reply-To: References: Message-ID: Hi Doug Interesting reading. So far I'm just reading and thinking. I have one question so far. " Clients obtain a reference to a Parametric Singleton instance only through the parametric singleton design pattern. If the instance is left in an improper state (e.g., the serial port was left open) it is NOT the role of the Parametric Singleton Design Pattern to close the IO port. Nor is it the role of the Parametric Singleton Design Pattern to open the port. That role is delegate to some other part of the system. " So when the clients obtain a reference to the singleton, can they assume the port is there? IE, would it be the singletons role to handle things like USB dongles being removed with event hints comming from the underlying OS. Hardware abstraction layer/HAL on Linux is an example of underlying OS events. I assume that role too is delegated to other parts of the system? -- Trent Jarvi tjarvi at qbang.org From lyon at docjava.com Thu Mar 23 08:10:33 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Thu, 23 Mar 2006 10:10:33 -0500 Subject: [Rxtx] Classes don't need goals, they need roles! In-Reply-To: References: Message-ID: Hi Trent, Yes, I think that the role of the Parametric Singleton Pattern is not to open or close serial ports, nor is it to perform error checking. On the other hand, if you were to combine the role of the Parametric Singleton Pattern with another role (like that of error checking) it might not be amiss. However, I generally caution programmers against adding multiple roles to classes, as this leads to monolithic designs. Thus a different class (NativeLibDetect) could have the role of determining if the native library can be loaded. Another class (SerialPortBean) can have the role of serializing the default state of the serial port, so that it can be recovered, from user preferences, at a later time. The SerialPortDetect could have the role of determining if the serial port is removed (i.e., a USB port was unplugged). My guess is that each class should have a different role in the system, in order to ease maintenance and testing...but I could be wrong about that. Thanks! - Doug >Hi Doug > >Interesting reading. So far I'm just reading and thinking. I have >one question so far. > >" > Clients obtain a reference to a Parametric Singleton instance only >through the parametric singleton design pattern. If the instance is >left in an improper state (e.g., the serial port was left open) it is >NOT the role of the Parametric Singleton Design Pattern to close the >IO port. Nor is it the role of the Parametric Singleton Design Pattern >to >open the port. That role is delegate to some other part of the system. >" > >So when the clients obtain a reference to the singleton, can they >assume the port is there? IE, would it be the singletons role to >handle things like USB dongles being removed with event hints >comming from the underlying OS. Hardware abstraction layer/HAL on >Linux is an example of underlying OS events. > >I assume that role too is delegated to other parts of the system? > >-- >Trent Jarvi >tjarvi at qbang.org >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From maximulo at yahoo.com Fri Mar 24 01:22:38 2006 From: maximulo at yahoo.com (Maximulo Majir) Date: Fri, 24 Mar 2006 00:22:38 -0800 (PST) Subject: [Rxtx] JavaPOS Message-ID: <20060324082238.66371.qmail@web38214.mail.mud.yahoo.com> Hi all! Hello Trent! From what i understand, RXTX or JavaComm APIs were not created solely for JavaPOS. In JavaPOS, we have the virtual method claim() which is separate from open(), but in our RXTX API, claiming is done every call to open(), we cant open the port if its claimed by another application. Would it be alright to suggest or ask to create a new method called claim(..)? Is there such thing as forceclaim() in RXTX? this could be the same as portownership transfer or its equivalent. ForceClaim is in JSR80. Do you have some samples using RXTX as the lower layer for the Device Service Objects in JavaPOS? I have tried it, i just want to compare. Thank you all! maxim __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060324/496adba2/attachment-0005.html From tjarvi at qbang.org Fri Mar 24 11:28:19 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 24 Mar 2006 11:28:19 -0700 (MST) Subject: [Rxtx] Re: RXTX 2.1 Solaris Problems In-Reply-To: <3691.1143210578@www045.gmx.net> References: <3691.1143210578@www045.gmx.net> Message-ID: On Fri, 24 Mar 2006, Andreas Guenther wrote: > Hi all, > > the solaris problem was not the lock file only. > > Ok, I had to create the directory /var/spool/locks myself. > /var/spool/uucp exists. > > But rxtx didn't find any port. > > I compiled the source with my own debug-informations > and I tried to isolate the problem. > > The problem is the testRead-call in SerialImp.c > > JNIEXPORT jboolean JNICALL RXTXCommDriver(testRead)( > > ... > if ( READ( fd, &c, 1 ) < 0 ) > { > if ( errno != EAGAIN ) { > report( "testRead() read failed\n" ); > ret = JNI_FALSE; > } > } > Thanks Andreas I'm packing up to move. I'll be more or less away for a couple weeks here. I'll be checking email but my workstation is going into a box soon. This isn't hard to fix as this port should be enumerated when EWOULDBLOCK is recieved. Thats error is OK for enumeration just as EAGAIN is. I've put the bug into bugzilla so we dont forget to get to it. http://bugzilla.qbang.org/show_bug.cgi?id=42 You can add yourself to the CC list if you wish to test fixes we provide or even put a patch into bugzilla yourself. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Fri Mar 24 11:51:52 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 24 Mar 2006 11:51:52 -0700 (MST) Subject: [Rxtx] JavaPOS In-Reply-To: <20060324082238.66371.qmail@web38214.mail.mud.yahoo.com> References: <20060324082238.66371.qmail@web38214.mail.mud.yahoo.com> Message-ID: On Fri, 24 Mar 2006, Maximulo Majir wrote: > Hi all! Hello Trent! > > > From what i understand, RXTX or JavaComm APIs were not > created solely for JavaPOS. In JavaPOS, we have the virtual method > claim() which is separate from open(), but in our RXTX API, claiming is > done every call to open(), we cant open the port if its claimed by > another application. Would it be alright to suggest or ask to create a > new method called claim(..)? Is there such thing as forceclaim() in > RXTX? this could be the same as portownership transfer or its > equivalent. ForceClaim is in JSR80. > Do you have some samples using RXTX as the lower layer for the Device > Service Objects in JavaPOS? I have tried it, i just want to compare. > maxim Hi Maxim JSR80 is the USB API IBM/Sun put together. The problem is they have a richer kernel/API underneath that can handle such things. With Serial Ports, there isnt anything there other than an ioctl that says don't let anyone touch this and lockfiles that are more of a 'lets be nice.' At times we may be using USB ports but it is through the termios layer with the limitations mentioned. The advantage is that not only USB will work with rxtx. Anything that has a termios layer should work (to the extent that termios layer is complete). I don't know how forceclaim() would help you. Lets say someone has a programmer working on /dev/ttyS0 and you take it. Now you both race each other to read data first. There isn't a mechanism I know of that will solve this problem in termios. The most obvious test being a native app and a Java app trying to take the port. There is the potential of requestion ownership from other Java Applications but the use for that is very rare. Did you have something more specific in mind that I'm missing? I'm not sure that claim() and forceclaim() would help you with rxtx other than maybe locking the port with claim() without opening it. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sat Mar 25 23:42:08 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 25 Mar 2006 23:42:08 -0700 (MST) Subject: [Rxtx] Serial snoop Message-ID: I was reading the Linux kernel mail-list tonight and ran past a thread that mentioned sersnoop. This looks like a handy tool for people dealing with new toys. "a simple command-line tool for linux that echoes bytes to and from any two serial ports, ptys, or network sockets, and prints all traffic to stdout, in hex and ascii." http://www.restivo.org/projects/sersnoop/ It works on Linux only at this time (debian package available). -- Trent Jarvi tjarvi at qbang.org From beat.arnet at gmail.com Sun Mar 26 07:32:35 2006 From: beat.arnet at gmail.com (Beat Arnet) Date: Sun, 26 Mar 2006 09:32:35 -0500 Subject: [Rxtx] Error 0x5 at /home/bob/foo/tar/rxtx-2.1-7/build/../src/termios.c(860): Access is, denied. Message-ID: <4426A603.80508@gmail.com> Dear all, When trying to open the serial port, I sometimes (not always) run into the following exception (when opening the serialPort): Error 0x5 at /home/bob/foo/tar/rxtx-2.1-7/build/../src/termios.c(860): Access is denied. java.lang.UnsatisfiedLinkError: native_psmisc_report_owner at gnu.io.CommPortIdentifier.native_psmisc_report_owner(Native Method) at gnu.io.CommPortIdentifier.open(CommPortIdentifier.java:354) at codeskin.tools.CLLoader.open(CLLoader.java:79) at codeskin.tools.C2000Programmer.run(C2000Programmer.java:220) at java.lang.Thread.run(Unknown Source) Is this the type of error where I should just try to open the port again, or can it be avoided? Regards, Beat From tjarvi at qbang.org Sun Mar 26 11:40:12 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 26 Mar 2006 11:40:12 -0700 (MST) Subject: [Rxtx] Error 0x5 at /home/bob/foo/tar/rxtx-2.1-7/build/../src/termios.c(860): Access is, denied. In-Reply-To: <4426A603.80508@gmail.com> References: <4426A603.80508@gmail.com> Message-ID: On Sun, 26 Mar 2006, Beat Arnet wrote: > Dear all, > > When trying to open the serial port, I sometimes (not always) run into > the following exception (when opening the serialPort): > > Error 0x5 at /home/bob/foo/tar/rxtx-2.1-7/build/../src/termios.c(860): > Access is > denied. > > java.lang.UnsatisfiedLinkError: native_psmisc_report_owner > at gnu.io.CommPortIdentifier.native_psmisc_report_owner(Native > Method) > at gnu.io.CommPortIdentifier.open(CommPortIdentifier.java:354) > at codeskin.tools.CLLoader.open(CLLoader.java:79) > at codeskin.tools.C2000Programmer.run(C2000Programmer.java:220) > at java.lang.Thread.run(Unknown Source) > > Is this the type of error where I should just try to open the port again, > or can it be avoided? > Hi Beat We did a second build of rxtx 2.1-7 to resolve that unsatisfied link error. It should work now. rxtx is trying to tell you it thinks someone else has the serial port open. You can try to open the port again but maybe you already have a copy of the program running when it happens? ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7r2.zip fixed build. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sun Mar 26 11:44:23 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 26 Mar 2006 11:44:23 -0700 (MST) Subject: [Rxtx] RXTX spec file (fwd) Message-ID: This is probably interesting for fedora/suse users. ---------- Forwarded message ---------- Date: Sun, 26 Mar 2006 16:25:45 +0200 To: taj at www.linux.org.uk Subject: RXTX spec file I send you this spec file which allows to create a RPM for Fedora 4, 5 (x86, x86_64) with Java Sun. -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: rxtx.spec Url: http://mailman.qbang.org/pipermail/rxtx/attachments/20060326/6c7b6af6/rxtx-0001.pl From tjarvi at qbang.org Sun Mar 26 23:42:59 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 26 Mar 2006 23:42:59 -0700 (MST) Subject: [Rxtx] Upcomming events. Message-ID: This Wednesday we will be announcing a new "Maintainer" for the rxtx project. The position is more like neutral leader. I wont be going away or doing less. This is just the right thing to do as it turns out the two people with CVS write access will be at the same company. We need a third and we need neutrality. The maintainer will have final say in any conflict and will try to be neutral. It will be open for discussion. Then we will do it :) I'll still do most of the footwork I do now. But. I'm falling behind. I should have gone through the mail-list and posted the next round of changes this weekend. I'm packing to move and its going so so - 13 years of toys collected. I suspect there will be a dead period on my part (a couple weeks) comming up. But if you get it on the mail-list, we will get it in if there are no objections. I may well not be reading the mail-list during this period as I look for a house and many other things. I hope everyone will help out. Thanks -- Trent Jarvi tjarvi at qbang.org From mahmoud_hadad at yahoo.com Sun Mar 26 07:31:19 2006 From: mahmoud_hadad at yahoo.com (ronan nick) Date: Sun, 26 Mar 2006 06:31:19 -0800 (PST) Subject: [Rxtx] a question about the COMM API Message-ID: <20060326143119.54919.qmail@web60014.mail.yahoo.com> hi, i was intrested in knowing how i can communicate with my internal modem using java? for example if i want to make a phone dialer application or a caller id application where should i be looking at? and as i understood the COMM API is for devices that is attached to the computer through serial ports. --------------------------------- New Yahoo! Messenger with Voice. Call regular phones from your PC and save big. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060326/ce8329f0/attachment-0003.html From dmarkman at mac.com Mon Mar 20 00:20:43 2006 From: dmarkman at mac.com (Dmitry Markman) Date: Mon, 20 Mar 2006 02:20:43 -0500 Subject: [Rxtx] Mac OS X RXTX java installer In-Reply-To: References: <07D0DE29-BA32-4CFE-B036-66BC6423D385@buechse.de> <441AE3E0.2030503@willicon.de> <12531986.1142622114996.JavaMail.dmarkman@mac.com> <441B2674.9010409@willicon.de> <13577405.1142634732776.JavaMail.dmarkman@mac.com> <441B4182.8010407@willicon.de> <92CD0D6C-5BE8-426E-A46D-99452059FF49@mac.com> <441BBB2D.8030305@willicon.de> <441C4088.5090905@willicon.de> Message-ID: <64BC1E23-FDDE-4CE6-8863-CFC881CBC224@mac.com> Hi all I put RXTX installer that will install everything (and will create / var/lock if necessary and add user to the uucp group) for mac os x from Java into the rxtx's CVS repository it could be easily modified to install files for any platform it uses Greg Guerin's AuthKit for authentication and authorization Greg released that kit under artistic license, so Trent, please take a look we, probably, can negotiate license with Greg if it's necessary Greg's AuthKit could be downloaded from http://www.amug.org/~glguerin/ sw/#authkit Michael Hall (mikehall at spacestar dot net) had a suggestion to make implementation of the jaas LoginModule based on Greg's AuthKit (his modification of the Greg's AuthKit could be found at http:// www.spacestar.net/users/mikehall/authkit.dmg) but Michael's AuthKitLoginModule does only half a job: it does authenticate but it can not run any external unix process in privileged mode (at least I wasn't able to do so) possible explanation could be found in conversation between Greg and Michael at Apple's java-dev list (look for archives) so I didn't use jaas API for rxtxinstaller I created folder MacOSX in the contrib folder comment 1. if you want to run that installer as standalone application all you need that RXTXInstaller.jar 2. if you want to use webstart you have to add Greg's libAuthKit.jnilib to the mac os x's resources in theory RXTXInstaller.jar doesn't need it, but there is a problem with loading libAuthKit.jnilib from webstart authkit uses loadLibrary method to load library and it failed (from webstart) for standalone application I extract libAuthKit.jnilib from the RXTXInstaller.jar and put it into the /Library/Java/Extensions or ~/Library/Java/Extensions folder that file will be deleted after installer quit unfortunately I didn't have time to put documentation there but it is mostly self-explanatory I took installer code from my gl4java installer that I did about 3 years ago (with small modifications) it would be very nice if Apple will release LoginModule that really will do the job (com.apple.security.auth.module package????? ) (UnixLoginModule is pretty useless) From lyon at docjava.com Mon Mar 20 06:34:39 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Mon, 20 Mar 2006 08:34:39 -0500 Subject: [Rxtx] Mac OS X RXTX java installer In-Reply-To: <64BC1E23-FDDE-4CE6-8863-CFC881CBC224@mac.com> References: <07D0DE29-BA32-4CFE-B036-66BC6423D385@buechse.de> <441AE3E0.2030503@willicon.de> <12531986.1142622114996.JavaMail.dmarkman@mac.com> <441B2674.9010409@willicon.de> <13577405.1142634732776.JavaMail.dmarkman@mac.com> <441B4182.8010407@willicon.de> <92CD0D6C-5BE8-426E-A46D-99452059FF49@mac.com> <441BBB2D.8030305@willicon.de> <441C4088.5090905@willicon.de> <64BC1E23-FDDE-4CE6-8863-CFC881CBC224@mac.com> Message-ID: Hi Dimitry, This sounds like great work. Just a couple of questions; After the check out of the CVS files, using: setenv CVSROOT :pserver:anonymous at cvs.milestonesolutions.com:/usr/local/cvsroot 53 8:28 setenv PASSWORD mousy 54 8:29 cvs login 55 8:29 cvs checkout rxtx-devel I cd'd over to: rxtx-devel/MACOSX_IDE And found: CVS/ CW/ ForPackageMaker/ PB/ Where is the installer? Thanks! - Doug From tjarvi at qbang.org Mon Mar 20 06:39:37 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 20 Mar 2006 06:39:37 -0700 (MST) Subject: [Rxtx] Mac OS X RXTX java installer In-Reply-To: References: <07D0DE29-BA32-4CFE-B036-66BC6423D385@buechse.de> <441AE3E0.2030503@willicon.de> <12531986.1142622114996.JavaMail.dmarkman@mac.com> <441B2674.9010409@willicon.de> <13577405.1142634732776.JavaMail.dmarkman@mac.com> <441B4182.8010407@willicon.de> <92CD0D6C-5BE8-426E-A46D-99452059FF49@mac.com> <441BBB2D.8030305@willicon.de> <441C4088.5090905@willicon.de> <64BC1E23-FDDE-4CE6-8863-CFC881CBC224@mac.com> Message-ID: On Mon, 20 Mar 2006, Dr. Douglas Lyon wrote: > Hi Dimitry, > This sounds like great work. Just a couple of questions; > After the check out of the CVS files, using: > setenv CVSROOT > :pserver:anonymous at cvs.milestonesolutions.com:/usr/local/cvsroot > 53 8:28 setenv PASSWORD mousy > 54 8:29 cvs login > 55 8:29 cvs checkout rxtx-devel Hi Doug You want "cvs checkout -r commapi-0-0-1 rxtx-devel" to get RXTX 2.1 The default branch is rxtx 2.0 which isn't very active right now. -- Trent Jarvi tjarvi at qbang.org From lyon at docjava.com Mon Mar 20 07:05:44 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Mon, 20 Mar 2006 09:05:44 -0500 Subject: [Rxtx] Mac OS X RXTX java installer In-Reply-To: References: <07D0DE29-BA32-4CFE-B036-66BC6423D385@buechse.de> <441AE3E0.2030503@willicon.de> <12531986.1142622114996.JavaMail.dmarkman@mac.com> <441B2674.9010409@willicon.de> <13577405.1142634732776.JavaMail.dmarkman@mac.com> <441B4182.8010407@willicon.de> <92CD0D6C-5BE8-426E-A46D-99452059FF49@mac.com> <441BBB2D.8030305@willicon.de> <441C4088.5090905@willicon.de> <64BC1E23-FDDE-4CE6-8863-CFC881CBC224@mac.com> Message-ID: Hi Trent, Thanks for the info on the CVS checkout procedure. I did that and am still not sure where the installer is. Here is what I have: cd MACOSX_IDE/ p4.docjava.com{lyon}121: ls CVS/ ForPackageMaker/ PB/ p4.docjava.com{lyon}122: find . | more . ./ForPackageMaker ./ForPackageMaker/RXTX.pkg.sit.hqx ./ForPackageMaker/Resources ./ForPackageMaker/Resources/ReadMe.rtf ./ForPackageMaker/Resources/Welcome.rtf ./ForPackageMaker/Resources/CVS ./ForPackageMaker/Resources/CVS/Entries ./ForPackageMaker/Resources/CVS/Repository ./ForPackageMaker/Resources/CVS/Tag ./ForPackageMaker/Resources/CVS/Root ./ForPackageMaker/Resources/preinstall ./ForPackageMaker/Resources/License.rtf ./ForPackageMaker/Resources/preupgrade ./ForPackageMaker/RXTX.pmsp ./ForPackageMaker/CVS ./ForPackageMaker/CVS/Entries ./ForPackageMaker/CVS/Repository ./ForPackageMaker/CVS/Entries.Log ./ForPackageMaker/CVS/Tag ./ForPackageMaker/CVS/Root ./ForPackageMaker/RXTX_Tiger.pkg.sitx.hqx ./ForPackageMaker/RXTX_Jag.pkg.sit.hqx ./ForPackageMaker/Install ./ForPackageMaker/Install/CVS ./ForPackageMaker/Install/CVS/Entries ./ForPackageMaker/Install/CVS/Repository ./ForPackageMaker/Install/CVS/Tag ./ForPackageMaker/Install/CVS/Root ./ForPackageMaker/Install/Library ./ForPackageMaker/Install/Library/CVS ./ForPackageMaker/Install/Library/CVS/Entries ./ForPackageMaker/Install/Library/CVS/Repository ./ForPackageMaker/Install/Library/CVS/Tag ./ForPackageMaker/Install/Library/CVS/Root ./ForPackageMaker/Install/Library/Java ./ForPackageMaker/Install/Library/Java/Extensions ./ForPackageMaker/Install/Library/Java/Extensions/RXTXcomm.jar ./ForPackageMaker/Install/Library/Java/Extensions/CVS ./ForPackageMaker/Install/Library/Java/Extensions/CVS/Entries ./ForPackageMaker/Install/Library/Java/Extensions/CVS/Repository ./ForPackageMaker/Install/Library/Java/Extensions/CVS/Tag ./ForPackageMaker/Install/Library/Java/Extensions/CVS/Root ./ForPackageMaker/Install/Library/Java/Extensions/librxtxSerial.jnilib ./ForPackageMaker/Install/Library/Java/CVS ./ForPackageMaker/Install/Library/Java/CVS/Entries ./ForPackageMaker/Install/Library/Java/CVS/Repository ./ForPackageMaker/Install/Library/Java/CVS/Entries.Log ./ForPackageMaker/Install/Library/Java/CVS/Tag ./ForPackageMaker/Install/Library/Java/CVS/Root ./ForPackageMaker/RXTX_Tiger.pmproj.sitx.hqx ./CVS ./CVS/Entries ./CVS/Repository ./CVS/Entries.Log ./CVS/Tag ./CVS/Root ./PB ./PB/LibSerialUniversal.xcodeproj.sitx.hqx ./PB/CVS ./PB/CVS/Entries ./PB/CVS/Repository ./PB/CVS/Entries.Log ./PB/CVS/Tag ./PB/CVS/Root ./PB/LibSerial.pbproj.sit.hqx ./PB/startpoint.c ./PB/config.h What is the procedure to run this installer? Do we need a README in: /rxtx-devel/MACOSX_IDE Here is what we have: CVS/ ForPackageMaker/ PB/ Thanks! - DL >On Mon, 20 Mar 2006, Dr. Douglas Lyon wrote: > >>Hi Dimitry, >>This sounds like great work. Just a couple of questions; >>After the check out of the CVS files, using: >>setenv CVSROOT >>:pserver:anonymous at cvs.milestonesolutions.com:/usr/local/cvsroot >> 53 8:28 setenv PASSWORD mousy >> 54 8:29 cvs login >> 55 8:29 cvs checkout rxtx-devel > >Hi Doug > >You want "cvs checkout -r commapi-0-0-1 rxtx-devel" to get RXTX 2.1 >The default branch is rxtx 2.0 which isn't very active right now. > >-- >Trent Jarvi >tjarvi at qbang.org From tjarvi at qbang.org Mon Mar 20 07:25:30 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 20 Mar 2006 07:25:30 -0700 (MST) Subject: [Rxtx] Mac OS X RXTX java installer In-Reply-To: References: <07D0DE29-BA32-4CFE-B036-66BC6423D385@buechse.de> <441AE3E0.2030503@willicon.de> <12531986.1142622114996.JavaMail.dmarkman@mac.com> <441B2674.9010409@willicon.de> <13577405.1142634732776.JavaMail.dmarkman@mac.com> <441B4182.8010407@willicon.de> <92CD0D6C-5BE8-426E-A46D-99452059FF49@mac.com> <441BBB2D.8030305@willicon.de> <441C4088.5090905@willicon.de> <64BC1E23-FDDE-4CE6-8863-CFC881CBC224@mac.com> Message-ID: On Mon, 20 Mar 2006, Dr. Douglas Lyon wrote: > Hi Trent, > Thanks for the info on the CVS checkout procedure. > I did that and am still not sure where the installer is. Hi Doug It does look like it was not cvs committed. There is no rxtx-devel/contrib/MacOSX directory in there at the moment. It was mentioned that it was put under contrib. -- Trent Jarvi tjarvi at qbang.org From dmarkman at mac.com Mon Mar 20 07:29:56 2006 From: dmarkman at mac.com (Dmitry Markman) Date: Mon, 20 Mar 2006 09:29:56 -0500 Subject: [Rxtx] Mac OS X RXTX java installer In-Reply-To: References: <07D0DE29-BA32-4CFE-B036-66BC6423D385@buechse.de> <441AE3E0.2030503@willicon.de> <12531986.1142622114996.JavaMail.dmarkman@mac.com> <441B2674.9010409@willicon.de> <13577405.1142634732776.JavaMail.dmarkman@mac.com> <441B4182.8010407@willicon.de> <92CD0D6C-5BE8-426E-A46D-99452059FF49@mac.com> <441BBB2D.8030305@willicon.de> <441C4088.5090905@willicon.de> <64BC1E23-FDDE-4CE6-8863-CFC881CBC224@mac.com> Message-ID: <6054EB4E-F7E0-4A9C-BDDA-D582D6D8826F@mac.com> you can find it in the rxtx-devel/contrib folder On Mar 20, 2006, at 9:05 AM, Dr. Douglas Lyon wrote: > Hi Trent, > Thanks for the info on the CVS checkout procedure. > I did that and am still not sure where the installer is. > Here is what I have: > cd MACOSX_IDE/ > p4.docjava.com{lyon}121: ls > CVS/ ForPackageMaker/ PB/ > p4.docjava.com{lyon}122: find . | more > . > ./ForPackageMaker > ./ForPackageMaker/RXTX.pkg.sit.hqx > ./ForPackageMaker/Resources > ./ForPackageMaker/Resources/ReadMe.rtf > ./ForPackageMaker/Resources/Welcome.rtf > ./ForPackageMaker/Resources/CVS > ./ForPackageMaker/Resources/CVS/Entries > ./ForPackageMaker/Resources/CVS/Repository > ./ForPackageMaker/Resources/CVS/Tag > ./ForPackageMaker/Resources/CVS/Root > ./ForPackageMaker/Resources/preinstall > ./ForPackageMaker/Resources/License.rtf > ./ForPackageMaker/Resources/preupgrade > ./ForPackageMaker/RXTX.pmsp > ./ForPackageMaker/CVS > ./ForPackageMaker/CVS/Entries > ./ForPackageMaker/CVS/Repository > ./ForPackageMaker/CVS/Entries.Log > ./ForPackageMaker/CVS/Tag > ./ForPackageMaker/CVS/Root > ./ForPackageMaker/RXTX_Tiger.pkg.sitx.hqx > ./ForPackageMaker/RXTX_Jag.pkg.sit.hqx > ./ForPackageMaker/Install > ./ForPackageMaker/Install/CVS > ./ForPackageMaker/Install/CVS/Entries > ./ForPackageMaker/Install/CVS/Repository > ./ForPackageMaker/Install/CVS/Tag > ./ForPackageMaker/Install/CVS/Root > ./ForPackageMaker/Install/Library > ./ForPackageMaker/Install/Library/CVS > ./ForPackageMaker/Install/Library/CVS/Entries > ./ForPackageMaker/Install/Library/CVS/Repository > ./ForPackageMaker/Install/Library/CVS/Tag > ./ForPackageMaker/Install/Library/CVS/Root > ./ForPackageMaker/Install/Library/Java > ./ForPackageMaker/Install/Library/Java/Extensions > ./ForPackageMaker/Install/Library/Java/Extensions/RXTXcomm.jar > ./ForPackageMaker/Install/Library/Java/Extensions/CVS > ./ForPackageMaker/Install/Library/Java/Extensions/CVS/Entries > ./ForPackageMaker/Install/Library/Java/Extensions/CVS/Repository > ./ForPackageMaker/Install/Library/Java/Extensions/CVS/Tag > ./ForPackageMaker/Install/Library/Java/Extensions/CVS/Root > ./ForPackageMaker/Install/Library/Java/Extensions/librxtxSerial.jnilib > ./ForPackageMaker/Install/Library/Java/CVS > ./ForPackageMaker/Install/Library/Java/CVS/Entries > ./ForPackageMaker/Install/Library/Java/CVS/Repository > ./ForPackageMaker/Install/Library/Java/CVS/Entries.Log > ./ForPackageMaker/Install/Library/Java/CVS/Tag > ./ForPackageMaker/Install/Library/Java/CVS/Root > ./ForPackageMaker/RXTX_Tiger.pmproj.sitx.hqx > ./CVS > ./CVS/Entries > ./CVS/Repository > ./CVS/Entries.Log > ./CVS/Tag > ./CVS/Root > ./PB > ./PB/LibSerialUniversal.xcodeproj.sitx.hqx > ./PB/CVS > ./PB/CVS/Entries > ./PB/CVS/Repository > ./PB/CVS/Entries.Log > ./PB/CVS/Tag > ./PB/CVS/Root > ./PB/LibSerial.pbproj.sit.hqx > ./PB/startpoint.c > ./PB/config.h > > What is the procedure to run this installer? > Do we need a README in: > /rxtx-devel/MACOSX_IDE > Here is what we have: > CVS/ ForPackageMaker/ PB/ > > > Thanks! > - DL > >> On Mon, 20 Mar 2006, Dr. Douglas Lyon wrote: >> >>> Hi Dimitry, >>> This sounds like great work. Just a couple of questions; >>> After the check out of the CVS files, using: >>> setenv CVSROOT :pserver:anonymous at cvs.milestonesolutions.com:/usr/ >>> local/cvsroot >>> 53 8:28 setenv PASSWORD mousy >>> 54 8:29 cvs login >>> 55 8:29 cvs checkout rxtx-devel >> >> Hi Doug >> >> You want "cvs checkout -r commapi-0-0-1 rxtx-devel" to get RXTX 2.1 >> The default branch is rxtx 2.0 which isn't very active right now. >> >> -- >> Trent Jarvi >> tjarvi at qbang.org > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx Dmitry Markman From mikehall at spacestar.net Mon Mar 20 05:25:25 2006 From: mikehall at spacestar.net (Michael Hall) Date: Mon, 20 Mar 2006 06:25:25 -0600 Subject: [Rxtx] Re: Mac OS X RXTX java installer In-Reply-To: <64BC1E23-FDDE-4CE6-8863-CFC881CBC224@mac.com> References: <07D0DE29-BA32-4CFE-B036-66BC6423D385@buechse.de> <441AE3E0.2030503@willicon.de> <12531986.1142622114996.JavaMail.dmarkman@mac.com> <441B2674.9010409@willicon.de> <13577405.1142634732776.JavaMail.dmarkman@mac.com> <441B4182.8010407@willicon.de> <92CD0D6C-5BE8-426E-A46D-99452059FF49@mac.com> <441BBB2D.8030305@willicon.de> <441C4088.5090905@willicon.de> <64BC1E23-FDDE-4CE6-8863-CFC881CBC224@mac.com> Message-ID: <247EB61F-5CD1-4132-89A2-FC105B6CF9A5@spacestar.net> On Mar 20, 2006, at 1:20 AM, Dmitry Markman wrote: > > Michael Hall (mikehall at spacestar dot net) had a suggestion to > make implementation of the jaas LoginModule > based on Greg's AuthKit > (his modification of the Greg's AuthKit could be found at http:// > www.spacestar.net/users/mikehall/authkit.dmg) > but Michael's AuthKitLoginModule does only half a job: > it does authenticate > but it can not run any external unix process in privileged mode (at > least I wasn't able to do so) If you got it working directly with Greg's the point is moot. But to clarify it anyhow. The login module does not allow you to do anything anything privileged on return as was explained by Greg. You need to work with a separate privileged process using the execPrivileged method of his API. I assume you did something similar although I haven't looked at how you are using it yet. I allowed instead for a action to be performed at the same time you login/authenticate,this... System.setProperty("authkit.action","/usr/bin/id"); just before this... lc.login(); To clarify, safely ignored as you are already complete. Mike Hall mikehall at spacestar dot net http://www.spacestar.net/users/mikehall http://sourceforge.net/projects/macnative -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2427 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20060320/f6e18202/smime-0006.bin From dmarkman at mac.com Mon Mar 20 07:36:47 2006 From: dmarkman at mac.com (Dmitry Markman) Date: Mon, 20 Mar 2006 09:36:47 -0500 Subject: [Rxtx] Re: Mac OS X RXTX java installer In-Reply-To: <247EB61F-5CD1-4132-89A2-FC105B6CF9A5@spacestar.net> References: <07D0DE29-BA32-4CFE-B036-66BC6423D385@buechse.de> <441AE3E0.2030503@willicon.de> <12531986.1142622114996.JavaMail.dmarkman@mac.com> <441B2674.9010409@willicon.de> <13577405.1142634732776.JavaMail.dmarkman@mac.com> <441B4182.8010407@willicon.de> <92CD0D6C-5BE8-426E-A46D-99452059FF49@mac.com> <441BBB2D.8030305@willicon.de> <441C4088.5090905@willicon.de> <64BC1E23-FDDE-4CE6-8863-CFC881CBC224@mac.com> <247EB61F-5CD1-4132-89A2-FC105B6CF9A5@spacestar.net> Message-ID: Hi, Michael all I have to do is to run some shell script I tried to use your action mechanism and it worked great so I just System.setProperty ("authkit.action","" ) and after that I even don't need to run anything like subject.doAs.... but after few thoughts I choose to use plain Greg's approach, because in that case I don't have to deal with various java's configurations files and therefore to use 2-3 -D parameters in the java command line especially it's useful for java web start (it's so fragile :-( ) thanks for the great job On Mar 20, 2006, at 7:25 AM, Michael Hall wrote: > > On Mar 20, 2006, at 1:20 AM, Dmitry Markman wrote: >> >> Michael Hall (mikehall at spacestar dot net) had a suggestion to >> make implementation of the jaas LoginModule >> based on Greg's AuthKit >> (his modification of the Greg's AuthKit could be found at http:// >> www.spacestar.net/users/mikehall/authkit.dmg) >> but Michael's AuthKitLoginModule does only half a job: >> it does authenticate >> but it can not run any external unix process in privileged mode >> (at least I wasn't able to do so) > > If you got it working directly with Greg's the point is moot. > > But to clarify it anyhow. > The login module does not allow you to do anything anything > privileged on return as was explained by Greg. You need to work > with a separate privileged process using the execPrivileged method > of his API. I assume you did something similar although I haven't > looked at how you are using it yet. > I allowed instead for a action to be performed at the same time you > login/authenticate,this... > System.setProperty("authkit.action","/usr/bin/id"); > just before this... > lc.login(); > To clarify, safely ignored as you are already complete. > > Mike Hall mikehall at spacestar dot net > http://www.spacestar.net/users/mikehall > http://sourceforge.net/projects/macnative > > > Dmitry Markman From dmarkman at mac.com Mon Mar 20 07:44:45 2006 From: dmarkman at mac.com (Dmitry Markman) Date: Mon, 20 Mar 2006 09:44:45 -0500 Subject: [Rxtx] Mac OS X RXTX java installer In-Reply-To: References: <07D0DE29-BA32-4CFE-B036-66BC6423D385@buechse.de> <441AE3E0.2030503@willicon.de> <12531986.1142622114996.JavaMail.dmarkman@mac.com> <441B2674.9010409@willicon.de> <13577405.1142634732776.JavaMail.dmarkman@mac.com> <441B4182.8010407@willicon.de> <92CD0D6C-5BE8-426E-A46D-99452059FF49@mac.com> <441BBB2D.8030305@willicon.de> <441C4088.5090905@willicon.de> <64BC1E23-FDDE-4CE6-8863-CFC881CBC224@mac.com> Message-ID: it's in the commapi-0-0-1 branch I tested it right now: cvs co -r commapi-0-0-1 rxtx-devel and I got everything On Mar 20, 2006, at 9:25 AM, Trent Jarvi wrote: > On Mon, 20 Mar 2006, Dr. Douglas Lyon wrote: > >> Hi Trent, >> Thanks for the info on the CVS checkout procedure. >> I did that and am still not sure where the installer is. > > Hi Doug > > It does look like it was not cvs committed. There is no rxtx-devel/ > contrib/MacOSX directory in there at the moment. It was mentioned > that it was put under contrib. > > -- > Trent Jarvi > tjarvi at qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx Dmitry Markman From tjarvi at qbang.org Mon Mar 20 07:52:57 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 20 Mar 2006 07:52:57 -0700 (MST) Subject: [Rxtx] Mac OS X RXTX java installer In-Reply-To: References: <07D0DE29-BA32-4CFE-B036-66BC6423D385@buechse.de> <441AE3E0.2030503@willicon.de> <12531986.1142622114996.JavaMail.dmarkman@mac.com> <441B2674.9010409@willicon.de> <13577405.1142634732776.JavaMail.dmarkman@mac.com> <441B4182.8010407@willicon.de> <92CD0D6C-5BE8-426E-A46D-99452059FF49@mac.com> <441BBB2D.8030305@willicon.de> <441C4088.5090905@willicon.de> <64BC1E23-FDDE-4CE6-8863-CFC881CBC224@mac.com> Message-ID: On Mon, 20 Mar 2006, Dmitry Markman wrote: > it's in the commapi-0-0-1 branch > > I tested it right now: > cvs co -r commapi-0-0-1 rxtx-devel > > and I got everything > A fresh checkout worked. Here is a copy of the tree (just the installer bits) ftp://ftp.qbang.org/pub/rxtx/MacOSX-installer.zip -- Trent Jarvi tjarvi at qbang.org From lyon at docjava.com Mon Mar 20 08:08:26 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Mon, 20 Mar 2006 10:08:26 -0500 Subject: [Rxtx] Mac OS X RXTX java installer In-Reply-To: References: <07D0DE29-BA32-4CFE-B036-66BC6423D385@buechse.de> <441AE3E0.2030503@willicon.de> <12531986.1142622114996.JavaMail.dmarkman@mac.com> <441B2674.9010409@willicon.de> <13577405.1142634732776.JavaMail.dmarkman@mac.com> <441B4182.8010407@willicon.de> <92CD0D6C-5BE8-426E-A46D-99452059FF49@mac.com> <441BBB2D.8030305@willicon.de> <441C4088.5090905@willicon.de> <64BC1E23-FDDE-4CE6-8863-CFC881CBC224@mac.com> Message-ID: Hi All, Is the Auth package able to work properly on non Mac OS's? It was not clear from the doc or download. Thanks! - Doug From dmarkman at mac.com Mon Mar 20 08:15:22 2006 From: dmarkman at mac.com (Dmitry Markman) Date: Mon, 20 Mar 2006 10:15:22 -0500 Subject: [Rxtx] Mac OS X RXTX java installer In-Reply-To: References: <07D0DE29-BA32-4CFE-B036-66BC6423D385@buechse.de> <441AE3E0.2030503@willicon.de> <12531986.1142622114996.JavaMail.dmarkman@mac.com> <441B2674.9010409@willicon.de> <13577405.1142634732776.JavaMail.dmarkman@mac.com> <441B4182.8010407@willicon.de> <92CD0D6C-5BE8-426E-A46D-99452059FF49@mac.com> <441BBB2D.8030305@willicon.de> <441C4088.5090905@willicon.de> <64BC1E23-FDDE-4CE6-8863-CFC881CBC224@mac.com> Message-ID: <217312D8-CCCA-4859-ABA6-32DF1CC817B9@mac.com> thanks Trent, for putting it on ftp server On Mar 20, 2006, at 9:52 AM, Trent Jarvi wrote: > A fresh checkout worked. Here is a copy of the tree (just the > installer bits) > > ftp://ftp.qbang.org/pub/rxtx/MacOSX-installer.zip > Dmitry Markman From dmarkman at mac.com Mon Mar 20 09:14:03 2006 From: dmarkman at mac.com (Dmitry Markman) Date: Mon, 20 Mar 2006 11:14:03 -0500 Subject: [Rxtx] Mac OS X RXTX java installer In-Reply-To: References: <07D0DE29-BA32-4CFE-B036-66BC6423D385@buechse.de> <441AE3E0.2030503@willicon.de> <12531986.1142622114996.JavaMail.dmarkman@mac.com> <441B2674.9010409@willicon.de> <13577405.1142634732776.JavaMail.dmarkman@mac.com> <441B4182.8010407@willicon.de> <92CD0D6C-5BE8-426E-A46D-99452059FF49@mac.com> <441BBB2D.8030305@willicon.de> <441C4088.5090905@willicon.de> <64BC1E23-FDDE-4CE6-8863-CFC881CBC224@mac.com> Message-ID: <4DEBA6F0-DA45-4E84-823E-1F1AC48BDCCC@mac.com> no it will work only on mac os x however it's harmless to run it on other platform if you want to use it for other platform you have to do the following (I'll do it for linux) 1. modify RXTXInstaller class method public static RXTXInstaller getInstance() public static RXTXInstaller getInstance() { String osName = System.getProperty("os.name").toLowerCase(); if(osName.startsWith("mac")){ return new gnu.io.installer.macosx.MACOSXRXTXInstaller(); } else if(osName.startsWith("windows")){ return new gnu.io.installer.windows.WindowsRXTXInstaller(); }else if(osName.startsWith("linux")){ return new gnu.io.installer.linux.LinuxRXTXInstaller(); } return null; } 2. create folder gnu/io/installer/linux/ 3. create class Linux386RXTXInstaller package gnu.io.installer.linux; import java.io.File; public class Linux386RXTXInstaller extends gnu.io.installer.RXTXInstaller{ public Linux386RXTXInstaller(){ createJarFolder(); createLibFolder(); addJarResource("RXTXcomm.jar","/gnu/io/installer/resources/ linux/jar/RXTXcomm.dat"); addLibResource("librxtxSerial.so","/gnu/io/installer/ resources/linux/lib/librxtxSerial.so"); } protected void createJarFolder(){ String javaHome = System.getProperty("java.home"); char separator = File.separatorChar; jarFolder = new File(javaHome+separator+"lib"+separator+"ext"); } protected void createLibFolder(){ String javaHome = System.getProperty("java.home"); char separator = File.separatorChar; libFolder = new File(javaHome+separator+"bin"); } public void runPreProcess() {} //put here some action you need public void runPostProcess() {} //put here some action you need } 4. create folder /gnu/io/installer/resources/linux/jar and put there linux's version of RXTXcomm.dat (which is renamed RXTXcomm.jar) 5. create folder /gnu/io/installer/resources/linux/lib and put there linux's version of librxtxSerial. so 6. make sure that RXTXInstaller.jar has the following items: /gnu/io/installer/resources/linux/jar/RXTXcomm.jar /gnu/io/installer/resources/linux/lib/librxtxSerial.so 7. modify file installer.pref: jar file RXTXInstaller.jar must have the following item /gnu/io/installer/installer.pref that's basically it for windows you have to do the similar things: just replace linux to windows and librxtxSerial.so to rxtxSerial.dll and create appropriate gnu.io.installer.windows.WindowsRXTXInstaller class package gnu.io.installer.windows; import java.io.File; public class WindowsRXTXInstaller extends gnu.io.installer.RXTXInstaller{ public WindowsRXTXInstaller(){ createJarFolder(); createLibFolder(); addJarResource("RXTXcomm.jar","/gnu/io/installer/resources/ windows/jar/RXTXcomm.dat"); addLibResource("librxtxSerial.so","/gnu/io/installer/ resources/windows/lib/rxtxSerial.dll"); } protected void createJarFolder(){ String javaHome = System.getProperty("java.home"); char separator = File.separatorChar; jarFolder = new File(javaHome+separator+"lib"+separator+"ext"); } protected void createLibFolder(){ String javaHome = System.getProperty("java.home"); char separator = File.separatorChar; libFolder = new File(javaHome+separator+"bin"); } public void runPreProcess() {} //put here some action you need public void runPostProcess() {} //put here some action you need } installer.pref will look like On Mar 20, 2006, at 10:08 AM, Dr. Douglas Lyon wrote: > Hi All, > Is the Auth package able to work properly on > non Mac OS's? > It was not clear from the doc or download. > > Thanks! > - Doug > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx Dmitry Markman From joachim at buechse.de Mon Mar 20 10:49:06 2006 From: joachim at buechse.de (Joachim Buechse) Date: Mon, 20 Mar 2006 18:49:06 +0100 Subject: [Rxtx] BUG: Lock file stays even if port opening fails Message-ID: This was only tested on MacOSX but looking at the code, it should be true for all systems that use lock_uucp. I am opening a port which can not be opened (dialup port of a telephone paired via bluetooth but currently not reachable). The lock file is created and stays arround, even though the port open failed. After looking a bit through the code (of 2.17), I really wonder if it wouldn't be a good idea to make the "locking" an explicit operation called from the java code. This would certainly simplify the generation of meaningfull exceptions (and java based debugging). Maybe even the handling of "preopened" ports should be in the Java part of the lib (again for java based debugging puposes). That beeing said, I have no idea if this would be possible for the 2.07 implementation. Regards, Joachim From tjarvi at qbang.org Mon Mar 20 11:24:22 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 20 Mar 2006 11:24:22 -0700 (MST) Subject: [Rxtx] BUG: Lock file stays even if port opening fails In-Reply-To: References: Message-ID: On Mon, 20 Mar 2006, Joachim Buechse wrote: > This was only tested on MacOSX but looking at the code, it should be true > for all systems that use lock_uucp. > > I am opening a port which can not be opened (dialup port of a telephone > paired via bluetooth but currently not reachable). The lock file is > created and stays arround, even though the port open failed. > > > After looking a bit through the code (of 2.17), I really wonder if it > wouldn't be a good idea to make the "locking" an explicit operation > called from the java code. This would certainly simplify the generation > of meaningfull exceptions (and java based debugging). > Maybe even the handling of "preopened" ports should be in the Java part > of the lib (again for java based debugging puposes). That beeing said, I > have no idea if this would be possible for the 2.07 implementation. > > Regards, Hi Joachim It should be possible in the 2.0-7 implementation too. The calls to RXTXPort.java would not change. We would just do more there Moving more of that logic into Java would be better as many people don't like to look at C code. There is a liblockdev on most Linux distros that can do most of the C code and would be easier to use. The problem is embeded devices will not have that library. The preopened port code has not been really tested. That was a last minute request in a product cycle. I expect it will be tested this year though. As I recall, some devices really do not like CD raising on open. The preopened ports then allow people to mess around in java without power cycling the devices or losing data. -- Trent Jarvi tjarvi at qbang.org From joachim at buechse.de Mon Mar 20 12:01:08 2006 From: joachim at buechse.de (Joachim Buechse) Date: Mon, 20 Mar 2006 20:01:08 +0100 Subject: [Rxtx] BUG: Lock file stays even if port opening fails In-Reply-To: References: Message-ID: Hi Trent, What is your general feeling about moving code to Java? The last days I have been reading quite a bit of the code and there are several things, that might not work as expected. I'll give you two examples from is_device_locked: if LOCKDIR == /var/spool/locks the directory /var/spool/lock will not be checked. LOCKDIR is not checked for lockfiles with unexpected pefixes While these things have probably never been discovered in production, they are still possibly incorrect implementations. If it was Java code, I would write some unit tests producing the errors that could later be corrected. PS: One could imagine to actually implement the whole lockfile handling in Java using some native routines to get the values required (pid, st_dev, st_rdev, ...). On 20.03.2006, at 19:24, Trent Jarvi wrote: > On Mon, 20 Mar 2006, Joachim Buechse wrote: > >> This was only tested on MacOSX but looking at the code, it should >> be true for all systems that use lock_uucp. >> >> I am opening a port which can not be opened (dialup port of a >> telephone paired via bluetooth but currently not reachable). The >> lock file is created and stays arround, even though the port open >> failed. >> >> >> After looking a bit through the code (of 2.17), I really wonder if >> it wouldn't be a good idea to make the "locking" an explicit >> operation called from the java code. This would certainly simplify >> the generation of meaningfull exceptions (and java based debugging). >> Maybe even the handling of "preopened" ports should be in the Java >> part of the lib (again for java based debugging puposes). That >> beeing said, I have no idea if this would be possible for the 2.07 >> implementation. >> >> Regards, > > Hi Joachim > > It should be possible in the 2.0-7 implementation too. The calls > to RXTXPort.java would not change. We would just do more there > Moving more of that logic into Java would be better as many people > don't like to look at C code. There is a liblockdev on most Linux > distros that can do most of the C code and would be easier to use. > The problem is embeded devices will not have that library. > > The preopened port code has not been really tested. That was a > last minute request in a product cycle. I expect it will be tested > this year though. As I recall, some devices really do not like CD > raising on open. The preopened ports then allow people to mess > around in java without power cycling the devices or losing data. > > -- > Trent Jarvi > tjarvi at qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Mon Mar 20 12:21:02 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 20 Mar 2006 12:21:02 -0700 (MST) Subject: [Rxtx] BUG: Lock file stays even if port opening fails In-Reply-To: References: Message-ID: On Mon, 20 Mar 2006, Joachim Buechse wrote: > Hi Trent, > > What is your general feeling about moving code to Java? The last days I > have been reading quite a bit of the code and there are several things, > that might not work as expected. > > I'll give you two examples from is_device_locked: > > if LOCKDIR == /var/spool/locks the directory /var/spool/lock will not be > checked. > LOCKDIR is not checked for lockfiles with unexpected pefixes > > While these things have probably never been discovered in production, > they are still possibly incorrect implementations. If it was Java code, I > would write some unit tests producing the errors that could later be > corrected. > > PS: One could imagine to actually implement the whole lockfile handling > in Java using some native routines to get the values required (pid, > st_dev, st_rdev, ...). Hi Joachim I like the idea of moving more of the code into java but there are some things to consider. If you break this into multiple JNI calls, the performance will drop considerably during enumeration of ports. We are looking for 256 ports per dev type vs (16? in Sun's 2.0 and fewer types). Its hard to make assumptions. I've seen virtual ports start at /dev/foo100 for instance. It works out to over 7500 ports on Linux if you enable them all. We already trim that back by default. See Linux-all-ports in RXTXCommDriver.java. There are also native libraries that rxtx can link to. If you move too much into Java, linking to 'standard' libraries with distros will break. "configure --enable-liblock=yes" will not be doable. This is probably a favorable way with RedHat, Debian, Suse and others. Thats the right thing to do if there will be rpms, dpkg, .. For those reasons, I think it still make sense to keep it to a minimal ~3 calls to JNI code that we can use for speed and versatility. lock() isLocked(), unlock() perhaps. When I say speed, its more about avoiding crossing the JNI layer multiple times than java vs C performance. With versatility I think liblock is the right way for most but not all (embeded) linux distros. -- Trent Jarvi tjarvi at qbang.org From joachim at buechse.de Mon Mar 20 12:42:04 2006 From: joachim at buechse.de (Joachim Buechse) Date: Mon, 20 Mar 2006 20:42:04 +0100 Subject: [Rxtx] BUG: Lock file stays even if port opening fails In-Reply-To: References: Message-ID: <82C19FE7-DDCB-45B6-B2C9-7606B66F0124@buechse.de> Ok, what about providing a default implementation in Java? The RXTXCommDriver would call a (native) function useNativeLocking and if it returns true, call the native functions for lock() isLocked (), unlock(), else is would use the Java based default implementation. This could possibly be overriden by a property (again for debugging). Joachim On 20.03.2006, at 20:21, Trent Jarvi wrote: > On Mon, 20 Mar 2006, Joachim Buechse wrote: > >> Hi Trent, >> >> What is your general feeling about moving code to Java? The last >> days I have been reading quite a bit of the code and there are >> several things, that might not work as expected. >> >> I'll give you two examples from is_device_locked: >> >> if LOCKDIR == /var/spool/locks the directory /var/spool/lock will >> not be checked. >> LOCKDIR is not checked for lockfiles with unexpected pefixes >> >> While these things have probably never been discovered in >> production, they are still possibly incorrect implementations. If >> it was Java code, I would write some unit tests producing the >> errors that could later be corrected. >> >> PS: One could imagine to actually implement the whole lockfile >> handling in Java using some native routines to get the values >> required (pid, st_dev, st_rdev, ...). > > Hi Joachim > > I like the idea of moving more of the code into java but there are > some things to consider. > > If you break this into multiple JNI calls, the performance will > drop considerably during enumeration of ports. We are looking for > 256 ports per dev type vs (16? in Sun's 2.0 and fewer types). Its > hard to make assumptions. I've seen virtual ports start at /dev/ > foo100 for instance. > > It works out to over 7500 ports on Linux if you enable them all. > We already trim that back by default. See Linux-all-ports in > RXTXCommDriver.java. > > There are also native libraries that rxtx can link to. If you move > too much into Java, linking to 'standard' libraries with distros > will break. "configure --enable-liblock=yes" will not be doable. > This is probably a favorable way with RedHat, Debian, Suse and > others. Thats the right thing to do if there will be rpms, dpkg, .. > > For those reasons, I think it still make sense to keep it to a > minimal ~3 calls to JNI code that we can use for speed and > versatility. lock() isLocked(), unlock() perhaps. When I say > speed, its more about avoiding crossing the JNI layer multiple > times than java vs C performance. With versatility I think liblock > is the right way for most but not all (embeded) linux distros. > > -- > Trent Jarvi > tjarvi at qbang.org > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Mon Mar 20 12:44:47 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 20 Mar 2006 12:44:47 -0700 (MST) Subject: [Rxtx] BUG: Lock file stays even if port opening fails In-Reply-To: <82C19FE7-DDCB-45B6-B2C9-7606B66F0124@buechse.de> References: <82C19FE7-DDCB-45B6-B2C9-7606B66F0124@buechse.de> Message-ID: On Mon, 20 Mar 2006, Joachim Buechse wrote: > Ok, what about providing a default implementation in Java? > > The RXTXCommDriver would call a (native) function useNativeLocking and if > it returns true, call the native functions for lock() isLocked(), > unlock(), else is would use the Java based default implementation. This > could possibly be overriden by a property (again for debugging). > Hi Joachim That would be OK with me. -- Trent Jarvi tjarvi at qbang.org From dmarkman at mac.com Mon Mar 20 22:27:45 2006 From: dmarkman at mac.com (Dmitry Markman) Date: Tue, 21 Mar 2006 00:27:45 -0500 Subject: [Rxtx] binaries request Message-ID: <42702213-C222-4937-A585-7CFB17E47608@mac.com> Hi can somebody send me latest linux and windows binaries, please? or where I can find them (I didn't find them in the latest tareball) I gave up with my cygwin: something wrong I have no idea what java doesn't understand /cygwin/c syntax after I changed makefile it did java part but after that gcc 3.4.4 started to complain I set buffer length to 999 lines but I didn't get beginning of the story something wrong with my 1.4.2_09/include/jni.h gcc doesn't like it anyway I gave up thanks in advance Dmitry Markman -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060320/f8cbc57c/attachment-0006.html From tjarvi at qbang.org Mon Mar 20 22:36:48 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 20 Mar 2006 22:36:48 -0700 (MST) Subject: [Rxtx] binaries request In-Reply-To: <42702213-C222-4937-A585-7CFB17E47608@mac.com> References: <42702213-C222-4937-A585-7CFB17E47608@mac.com> Message-ID: On Tue, 21 Mar 2006, Dmitry Markman wrote: > Hi > can somebody send me latest linux and windows binaries, please? > > or where I can find them (I didn't find them in the latest tareball) > > I gave up with my cygwin: something wrong I have no idea what > java doesn't understand /cygwin/c syntax > after I changed makefile it did java part > but after that gcc 3.4.4 started to complain > I set buffer length to 999 lines but I didn't get beginning of the story > something wrong with my 1.4.2_09/include/jni.h gcc doesn't like it > anyway I gave up > > thanks in advance > Hi Dmitry The bins are here: ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7-bins-r2.zip Here are the files in the zip you want. Jar: rxtx-2.1-7-bins-r2/RXTXcomm.jar Windows: rxtx-2.1-7-bins-r2/Windows/i368-mingw32/rxtxSerial.dll Linux (x86) rxtx-2.1-7-bins-r2/Linux/i686-unknown-linux-gnu/librxtxSerial.so There are others in there including Parallel port support but those are the main ones for testing. -- Trent Jarvi tjarvi at qbang.org From dmarkman at mac.com Mon Mar 20 23:05:59 2006 From: dmarkman at mac.com (Dmitry Markman) Date: Tue, 21 Mar 2006 01:05:59 -0500 Subject: [Rxtx] binaries request In-Reply-To: References: <42702213-C222-4937-A585-7CFB17E47608@mac.com> Message-ID: thank you very much but windows's readme says: rxtxSerial.dll had to be recomopiled to link in missing native methods. should I ignore it? or what? thanks again also I understand that I should use mingw not cygwin I'll try to install mingw On Mar 21, 2006, at 12:36 AM, Trent Jarvi wrote: > On Tue, 21 Mar 2006, Dmitry Markman wrote: > >> Hi >> can somebody send me latest linux and windows binaries, please? >> >> or where I can find them (I didn't find them in the latest tareball) >> >> I gave up with my cygwin: something wrong I have no idea what >> java doesn't understand /cygwin/c syntax >> after I changed makefile it did java part >> but after that gcc 3.4.4 started to complain >> I set buffer length to 999 lines but I didn't get beginning of the >> story >> something wrong with my 1.4.2_09/include/jni.h gcc doesn't like it >> anyway I gave up >> >> thanks in advance >> > > Hi Dmitry > > The bins are here: > > ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7-bins-r2.zip > > Here are the files in the zip you want. > > Jar: > > rxtx-2.1-7-bins-r2/RXTXcomm.jar > > Windows: > > rxtx-2.1-7-bins-r2/Windows/i368-mingw32/rxtxSerial.dll > > Linux (x86) > > rxtx-2.1-7-bins-r2/Linux/i686-unknown-linux-gnu/librxtxSerial.so > > There are others in there including Parallel port support but those > are the main ones for testing. > > -- > Trent Jarvi > tjarvi at qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx Dmitry Markman From tjarvi at qbang.org Mon Mar 20 23:20:33 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 20 Mar 2006 23:20:33 -0700 (MST) Subject: [Rxtx] binaries request In-Reply-To: References: <42702213-C222-4937-A585-7CFB17E47608@mac.com> Message-ID: On Tue, 21 Mar 2006, Dmitry Markman wrote: > thank you very much > > but windows's readme says: > rxtxSerial.dll had to be recomopiled to link in missing native methods. > > should I ignore it? or what? > Hi Dmitry That dll should be OK. r2 is the recompile linked to the missing native method. The readme explains why it was recompiled; fuser.o was not linked into the dll in the first release. -- Trent Jarvi tjarvi at qbang.org From ariantristan at yahoo.com Mon Mar 20 23:55:24 2006 From: ariantristan at yahoo.com (Lambok Sianturi) Date: Mon, 20 Mar 2006 22:55:24 -0800 (PST) Subject: [Rxtx] jvm issue Message-ID: <20060321065524.94779.qmail@web50701.mail.yahoo.com> Hi All, This is my first time to join RxTx mailing list. I thank you all for allowing others to sign in in requests help. I use the latest RxTx lib in Fedora 3 with java version 1.4.2_09 b05. And I got this error: # # An unexpected error has been detected by HotSpot Virtual Machine: # # SIGSEGV (0xb) at pc=0x00bf27f3, pid=2633, tid=3086112448 # # Java VM: Java HotSpot(TM) Client VM (1.4.2_09-b05 mixed mode) # Problematic frame: # C [ld-linux.so.2+0xa7f3] # # An error report file with more information is saved as hs_err_pid2633.log # # If you would like to submit a bug report, please visit: # http://java.sun.com/webapps/bugreport/crash.jsp # ./run.sh: line 3: 2633 Aborted /usr/local/java/bin/java -Djava.library.path=/usr/local/java/jre/lib/ -Djsmsengine.debug=true -classpath jsmsengine.jar:smsgateway.jar:classes12.jar:RXTXcomm.jar:. com.api.sms.SMSServer What is the jvm depedency for the latest library? Can I use 1.4.2_09 b05? Thanks in advance. Arian --------------------------------- Yahoo! Mail Use Photomail to share photos without annoying attachments. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060320/83d58dd7/attachment-0006.html From f.frumento at ngi.it Tue Mar 21 00:21:47 2006 From: f.frumento at ngi.it (Fabio Frumento) Date: Tue, 21 Mar 2006 08:21:47 +0100 Subject: [Rxtx] Javadoc on the go Message-ID: <441FA98B.9050701@ngi.it> Hi Trent, sorry for the big delay but my job is running wild, i was out for some time but now i'm back and ready to continue the javadoc for Rxtx. Did you used the last javadoc patch i sent you ? let me know if i have to send it to you again or not. regards Fabio From lyon at docjava.com Tue Mar 21 00:51:18 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Tue, 21 Mar 2006 02:51:18 -0500 Subject: [Rxtx] lock files Message-ID: Hi All, You know, if the use of lock files were under Java control (rather than a build-time decision), it might enable a more unified binary distro. It might also facilitate quick prototyping of non-lock file approaches to resolving serial port contention issues (i.e., mac-like approaches vs. linux approaches, etc.). I realize that this is a radical overhaul of the lock file policy issue. Also, it may harm performance. On the other hand, our benchmarks on JNI overhead for modern processors indicate performance impact should be minimal. Perhaps it is more of an issue with the toybox systems. Suppose there were a class with a reasonable default...someone might write: SerialPortLockPolicy.setPolicy(SerialPortLockPolicy.UNIX_LOCK_FILE); SerialPortLockPolicy.setPolicy(SerialPortLockPolicy.NO_LOCK_CHECKING); SerialPortLockPolicy.setPolicy(SerialPortLockPolicy.MAC_STYLE); Thus, we could have a run-time reconfiguration of the serial port lock policy. A special NO_LOCK version of the binary would no longer be required. Any thoughts on this? Thanks! - Doug From joachim at buechse.de Tue Mar 21 03:09:09 2006 From: joachim at buechse.de (Joachim Buechse) Date: Tue, 21 Mar 2006 11:09:09 +0100 Subject: [Rxtx] lock files In-Reply-To: References: Message-ID: <8E12916A-1B9A-4FF2-B684-E2D1C794221B@buechse.de> This is pretty much what I thought about when I suggested, that the default behaviour could be overwritten with a property. I am very much in favor of this approach. In particular this allows much easier debugging for PC based java developers. I think big parts of the Java (and maybe some parts of the C code) could use a bit of a structural workover (unit tests, javadoc, synchronization, etc). Maybe there should be a CVS branch for this experimental version. I'd be happy to contribute a first workover for some of the Java code. Designing for testability and implementing a good bunch of unit tests has been a strategy that worked quite well in the Java projects I lead. And it ultimately allows more liberal change permission. Regards, Joachim On 21.03.2006, at 08:51, Dr. Douglas Lyon wrote: > Hi All, > You know, if the use of lock files were > under Java control (rather than a build-time decision), > it might enable a more unified binary distro. It might also > facilitate quick prototyping of non-lock file approaches > to resolving serial port contention issues (i.e., mac-like > approaches vs. linux approaches, etc.). > > I realize that this is a radical overhaul of the lock file policy > issue. Also, it may harm performance. On the other hand, > our benchmarks on JNI overhead for modern processors indicate > performance impact should be minimal. Perhaps it is more of > an issue with the toybox systems. > > Suppose there were a class with a reasonable default...someone > might write: > SerialPortLockPolicy.setPolicy(SerialPortLockPolicy.UNIX_LOCK_FILE); > SerialPortLockPolicy.setPolicy(SerialPortLockPolicy.NO_LOCK_CHECKING); > SerialPortLockPolicy.setPolicy(SerialPortLockPolicy.MAC_STYLE); > > Thus, we could have a run-time reconfiguration of the serial port lock > policy. A special NO_LOCK version of the binary would no longer > be required. > > Any thoughts on this? > > Thanks! > - Doug > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From joachim at buechse.de Tue Mar 21 06:23:08 2006 From: joachim at buechse.de (Joachim Buechse) Date: Tue, 21 Mar 2006 14:23:08 +0100 Subject: [Rxtx] PATCH: use of ioctl(fd, TIOCEXCL) instead of lockfiles Message-ID: <923AE774-EEA2-4911-92D8-32BB27802C8B@buechse.de> Here is the patch for the ioctl(fd, TIOCEXCL). I have verified this only for OSX 10.4.5, hence it is only defined for APPLE. However, it should work at least for Solaris as well. If a process has requested TIOEXCL further open calls by other user processes will fail. The patch also disables uucp style locking for APPLE. Obviously this is discussable. I think it is the way to go, as it eliminates creating the lock directory which doesnt exist on the standard installation and it eliminates messing with the system group definitions (adding users to group uucp). Regarding the possibility of root processes opening a device which is locked - I consider this a feature not a potential problem. It is highly unlikely, that somebody is crazy enough to run a JavaVM as root (unless he has no other means of getting a restricted IP port opened, ie doesnt understand ipfw). Anyway, even if the process runs as root, it fails when calling ioctl(fd, TIOCEXCL). It could however still open the port to listen for RING events. I.e. a fax server which needs to see incoming calls but otherwise doesnt want to block the port. So the only case where the proposed mechanism fails is, if an incorrectly implemented process running as root conflicts with a user process. I think this can be accepted. Regards, Joachim PS: If this patch is generally accepted, the installer and Mac doku should obviously be changed as well. Index: SerialImp.c =================================================================== RCS file: /usr/local/cvsroot/rxtx-devel/src/SerialImp.c,v retrieving revision 1.46.2.187 diff -u -r1.46.2.187 SerialImp.c --- SerialImp.c 29 Jan 2006 22:19:04 -0000 1.46.2.187 +++ SerialImp.c 21 Mar 2006 12:59:16 -0000 @@ -656,6 +656,25 @@ fd=OPEN (filename, O_RDWR | O_NOCTTY | O_NONBLOCK ); } while (fd < 0 && errno==EINTR); +#ifdef OPEN_EXCL + // Note that open() follows POSIX semantics: multiple open() calls to + // the same file will succeed unless the TIOCEXCL ioctl is issued. + // This will prevent additional opens except by root-owned processes. + // See tty(4) ("man 4 tty") and ioctl(2) ("man 2 ioctl") for details. + + if (fd >= 0 && (ioctl(fd, TIOCEXCL) == -1)) + { + sprintf( message, "open: exclusive access denied for % s\n", + filename ); + report( message ); + report_error( message ); + + close(fd); + goto fail; + } +#endif /* OPEN_EXCL */ + + if( configure_port( fd ) ) goto fail; (*env)->ReleaseStringUTFChars( env, jstr, filename ); sprintf( message, "open: fd returned is %i\n", fd ); Index: SerialImp.h =================================================================== RCS file: /usr/local/cvsroot/rxtx-devel/src/SerialImp.h,v retrieving revision 1.11.2.49 diff -u -r1.11.2.49 SerialImp.h --- SerialImp.h 5 Jul 2005 17:47:21 -0000 1.11.2.49 +++ SerialImp.h 21 Mar 2006 12:59:17 -0000 @@ -135,7 +135,8 @@ /*# define LOCKDIR "/var/spool/uucp"*/ # define LOCKDIR "/var/lock" # define LOCKFILEPREFIX "LK." -# define UUCP +/*# define UUCP*/ +# define OPEN_EXCL #endif /* __APPLE__ */ #if defined(__NetBSD__) # define DEVICEDIR "/dev/" From tjarvi at qbang.org Tue Mar 21 10:26:08 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 21 Mar 2006 10:26:08 -0700 (MST) Subject: [Rxtx] Javadoc on the go In-Reply-To: <441FA98B.9050701@ngi.it> References: <441FA98B.9050701@ngi.it> Message-ID: On Tue, 21 Mar 2006, Fabio Frumento wrote: > Hi Trent, > > sorry for the big delay but my job is running wild, i was out for some > time but now i'm back and ready to continue the javadoc for Rxtx. > > Did you used the last javadoc patch i sent you ? let me know if i have to > send it to you again or not. > > regards > > Fabio Hi Fabio The patch is in the rxtx mail-list archives. It will be going in soon. I did not see a time critical portion. I'll probably be going through the list since the last batch of patches this weekend and putting them into CVS. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Tue Mar 21 10:57:18 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 21 Mar 2006 10:57:18 -0700 (MST) Subject: [Rxtx] jvm issue In-Reply-To: <20060321065524.94779.qmail@web50701.mail.yahoo.com> References: <20060321065524.94779.qmail@web50701.mail.yahoo.com> Message-ID: On Mon, 20 Mar 2006, Lambok Sianturi wrote: > Hi All, > This is my first time to join RxTx mailing list. I thank you all for allowing others to sign in in requests help. > I use the latest RxTx lib in Fedora 3 with java version 1.4.2_09 b05. And I got this error: > > # > # An unexpected error has been detected by HotSpot Virtual Machine: > # > # SIGSEGV (0xb) at pc=0x00bf27f3, pid=2633, tid=3086112448 > # > # Java VM: Java HotSpot(TM) Client VM (1.4.2_09-b05 mixed mode) > # Problematic frame: > # C [ld-linux.so.2+0xa7f3] A native library loading error? What happens if you recompile rxtx on your system and install that? This sounds like an ABI problem? rxtx 2.1-7 was compiled with a gcc 2.96 toolchain as I recall. The hope is newer system will be backwards compatible. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Tue Mar 21 11:05:29 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 21 Mar 2006 11:05:29 -0700 (MST) Subject: [Rxtx] PATCH: use of ioctl(fd, TIOCEXCL) instead of lockfiles In-Reply-To: <923AE774-EEA2-4911-92D8-32BB27802C8B@buechse.de> References: <923AE774-EEA2-4911-92D8-32BB27802C8B@buechse.de> Message-ID: On Tue, 21 Mar 2006, Joachim Buechse wrote: > Here is the patch for the ioctl(fd, TIOCEXCL). I have verified this only > for OSX 10.4.5, hence it is only defined for APPLE. However, it should > work at least for Solaris as well. > > If a process has requested TIOEXCL further open calls by other user > processes will fail. > > The patch also disables uucp style locking for APPLE. Obviously this is > discussable. I think it is the way to go, as it eliminates creating the > lock directory which doesnt exist on the standard installation and it > eliminates messing with the system group definitions (adding users to > group uucp). > > Regarding the possibility of root processes opening a device which is > locked - I consider this a feature not a potential problem. It is highly > unlikely, that somebody is crazy enough to run a JavaVM as root (unless > he has no other means of getting a restricted IP port opened, ie doesnt > understand ipfw). Anyway, even if the process runs as root, it fails when > calling ioctl(fd, TIOCEXCL). It could however still open the port to > listen for RING events. I.e. a fax server which needs to see incoming > calls but otherwise doesnt want to block the port. So the only case where > the proposed mechanism fails is, if an incorrectly implemented process > running as root conflicts with a user process. I think this can be > accepted. > > Regards, > Joachim > > PS: If this patch is generally accepted, the installer and Mac doku > should obviously be changed as well. > > > Index: SerialImp.c > =================================================================== > RCS file: /usr/local/cvsroot/rxtx-devel/src/SerialImp.c,v > retrieving revision 1.46.2.187 > diff -u -r1.46.2.187 SerialImp.c > --- SerialImp.c 29 Jan 2006 22:19:04 -0000 1.46.2.187 > +++ SerialImp.c 21 Mar 2006 12:59:16 -0000 > @@ -656,6 +656,25 @@ > fd=OPEN (filename, O_RDWR | O_NOCTTY | O_NONBLOCK ); > } while (fd < 0 && errno==EINTR); > > +#ifdef OPEN_EXCL > + // Note that open() follows POSIX semantics: multiple open() > calls to > + // the same file will succeed unless the TIOCEXCL ioctl is > issued. > + // This will prevent additional opens except by root-owned > processes. > + // See tty(4) ("man 4 tty") and ioctl(2) ("man 2 ioctl") for > details. > + > + if (fd >= 0 && (ioctl(fd, TIOCEXCL) == -1)) > + { > + sprintf( message, "open: exclusive access denied for % > s\n", > + filename ); > + report( message ); > + report_error( message ); > + > + close(fd); > + goto fail; > + } > +#endif /* OPEN_EXCL */ > + > + > if( configure_port( fd ) ) goto fail; > (*env)->ReleaseStringUTFChars( env, jstr, filename ); > sprintf( message, "open: fd returned is %i\n", fd ); > Index: SerialImp.h > =================================================================== > RCS file: /usr/local/cvsroot/rxtx-devel/src/SerialImp.h,v > retrieving revision 1.11.2.49 > diff -u -r1.11.2.49 SerialImp.h > --- SerialImp.h 5 Jul 2005 17:47:21 -0000 1.11.2.49 > +++ SerialImp.h 21 Mar 2006 12:59:17 -0000 > @@ -135,7 +135,8 @@ > /*# define LOCKDIR "/var/spool/uucp"*/ > # define LOCKDIR "/var/lock" > # define LOCKFILEPREFIX "LK." > -# define UUCP > +/*# define UUCP*/ > +# define OPEN_EXCL > #endif /* __APPLE__ */ > #if defined(__NetBSD__) > # define DEVICEDIR "/dev/" > This looks like a good start. What do you think Dmitry? Perhaps all systems with TIOCEXCL defined should use that though. Even if they use lockfiles. It wont hurt anything. That would catch people hacking their own serial apps without checking lockfiles. Its a good idea to avoid C++ style comments in the C portions. Some older systems don't deal with them well. If it's just for Mac OS X, it isn't a big deal. I think it was the Irix compiler that was problematic? -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Tue Mar 21 11:22:05 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 21 Mar 2006 11:22:05 -0700 (MST) Subject: [Rxtx] lock files In-Reply-To: <8E12916A-1B9A-4FF2-B684-E2D1C794221B@buechse.de> References: <8E12916A-1B9A-4FF2-B684-E2D1C794221B@buechse.de> Message-ID: We can try it. Maybe the JNI is much improved. The nice thing about linking into liblock is distros then worry about lockfiles on their systems. This way, we have to deal with any changes that may show up. On Tue, 21 Mar 2006, Joachim Buechse wrote: > This is pretty much what I thought about when I suggested, that the > default behaviour could be overwritten with a property. I am very much in > favor of this approach. In particular this allows much easier debugging > for PC based java developers. > > I think big parts of the Java (and maybe some parts of the C code) could > use a bit of a structural workover (unit tests, javadoc, synchronization, > etc). Maybe there should be a CVS branch for this experimental version. > I'd be happy to contribute a first workover for some of the Java code. > Designing for testability and implementing a good bunch of unit tests has > been a strategy that worked quite well in the Java projects I lead. And > it ultimately allows more liberal change permission. > > Regards, > Joachim > > > On 21.03.2006, at 08:51, Dr. Douglas Lyon wrote: > >> Hi All, >> You know, if the use of lock files were >> under Java control (rather than a build-time decision), >> it might enable a more unified binary distro. It might also >> facilitate quick prototyping of non-lock file approaches >> to resolving serial port contention issues (i.e., mac-like >> approaches vs. linux approaches, etc.). >> >> I realize that this is a radical overhaul of the lock file policy >> issue. Also, it may harm performance. On the other hand, >> our benchmarks on JNI overhead for modern processors indicate >> performance impact should be minimal. Perhaps it is more of >> an issue with the toybox systems. >> >> Suppose there were a class with a reasonable default...someone >> might write: >> SerialPortLockPolicy.setPolicy(SerialPortLockPolicy.UNIX_LOCK_FILE); >> SerialPortLockPolicy.setPolicy(SerialPortLockPolicy.NO_LOCK_CHECKING); >> SerialPortLockPolicy.setPolicy(SerialPortLockPolicy.MAC_STYLE); >> >> Thus, we could have a run-time reconfiguration of the serial port lock >> policy. A special NO_LOCK version of the binary would no longer >> be required. >> >> Any thoughts on this? >> >> Thanks! >> - Doug >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From dmarkman at mac.com Tue Mar 21 16:05:17 2006 From: dmarkman at mac.com (Dmitry Markman) Date: Tue, 21 Mar 2006 18:05:17 -0500 Subject: [Rxtx] PATCH: use of ioctl(fd, TIOCEXCL) instead of lockfiles In-Reply-To: References: <923AE774-EEA2-4911-92D8-32BB27802C8B@buechse.de> Message-ID: <512AC70C-BB86-48F2-A83C-023F35C23BAB@mac.com> I think it's cool, but I'd like to have that property implementation when user can choose between locking mechanism about comments: it's easy to change comments to the C style or we can use extensions of the file to cpp so c++ compiler will be used On Mar 21, 2006, at 1:05 PM, Trent Jarvi wrote: > This looks like a good start. What do you think Dmitry? Perhaps > all systems with TIOCEXCL defined should use that though. Even if > they use lockfiles. It wont hurt anything. That would catch > people hacking their own serial apps without checking lockfiles. > > Its a good idea to avoid C++ style comments in the C portions. > Some older systems don't deal with them well. If it's just for Mac > OS X, it isn't a big deal. I think it was the Irix compiler that > was problematic? Dmitry Markman From dmarkman at mac.com Tue Mar 21 16:13:00 2006 From: dmarkman at mac.com (Dmitry Markman) Date: Tue, 21 Mar 2006 18:13:00 -0500 Subject: [Rxtx] PATCH: use of ioctl(fd, TIOCEXCL) instead of lockfiles In-Reply-To: References: <923AE774-EEA2-4911-92D8-32BB27802C8B@buechse.de> Message-ID: I'd like to add that creating locking folder isn't a big deal we never had a problem related to the lock folders, because we always used installer on mac os x from other hand I'm not very much familiar with iotcl locking approach and I'm not sure it's more efficient Joachim wrote "I think it is the way to go, as it eliminates creating the lock directory which doesnt exist on the standard installation and it eliminates messing with the system group definitions (adding users to group uucp)." but I really didn't have any problem with that 1. doesn't exist on the standard installation there are many-many things that don't exist in the standard installation so I don't think that argument is strong enough 2. messing with the system group definitions I don't think we're messing with the group definition mac os x provides very clear way to set up group's members and together with Greg Guerin AuthKit there is no problem to set those definitions so I don't think that argument is strong either but from other hand using iotcl is more promising and is more elegant On Mar 21, 2006, at 1:05 PM, Trent Jarvi wrote: > > This looks like a good start. What do you think Dmitry? Perhaps > all systems with TIOCEXCL defined should use that though. Even if > they use lockfiles. It wont hurt anything. That would catch > people hacking their own serial apps without checking lockfiles. Dmitry Markman From joachim at buechse.de Wed Mar 22 04:46:45 2006 From: joachim at buechse.de (Joachim Buechse) Date: Wed, 22 Mar 2006 12:46:45 +0100 Subject: [Rxtx] PATCH: use of ioctl(fd, TIOCEXCL) instead of lockfiles In-Reply-To: References: <923AE774-EEA2-4911-92D8-32BB27802C8B@buechse.de> Message-ID: Sorry, I was not very clear with my arguments, so I will try again;-) Please, don't take this as an attack against work that has been done. I think the contributions that have been made in the past were made in a good spirit. But I really believe, that the current solution for OSX has many shortcomings and should be changed as soon as possible. lock files --- The /var/lock folder does not exist on the standard OSX installation, however the standard installation includes several applications that use serial ports (i.e. the FAX capability). This indicates, that the lock folder approach will not work well with system components. Applications for OSX will generally try to live in harmony with system components (except for HP print drivers of course). I think RXTX should follow this approach as well. uucp group --- Accessing serial ports is not an admin privileged operation on OSX. Any user (world) has read/write privileges on /dev/tty*. So the system default is to not enforce any group membership to access these ports. The group uucp however is a system group on all unix systems I know. It exists for certain system processes. A non admin user should in general not be a member of this group. Quite arguably no user should ever be a member of this group. Installer --- My general opinion is, that - no Installer should touch user or group data without warning - no Application Installer should touch groups which are not specific to the very application installed - no Installer should ever add regular users to a system group The current installer injects the installing user in the group uucp without warning about this change and without giving the option to "opt out" of this change. This is a potential security risk (but not currently a real one, as OSX contains no folders belonging to group uucp). The current installer does not work for multi user systems. It puts the installing user in the uucp group. However the installing user is not necessarily the user that will use the application. Putting all users that may use a serial port application in the system group uucp seems like a very invasive approach to me. Besides that, newly created users will not automatically be in the group and hence, serial applications will "break" for new users without obvious reasons. Avoiding the lock files will allow self contained applications (i.e. drag&drop installation). In my eyes this is largely preferable over an installer that requests admin privileges. Adding up all these points indicates very strongly, that the lock-file implementation is not the way to go on OSX. Regards, Joachim On 22.03.2006, at 00:13, Dmitry Markman wrote: > I'd like to add that > > creating locking folder isn't a big deal > we never had a problem related to the lock folders, because we > always used installer on mac os x > from other hand I'm not very much familiar with iotcl locking > approach and I'm not sure it's more efficient > > Joachim wrote "I think it is the way to go, as it eliminates > creating the lock directory which doesnt exist on the standard > installation and it eliminates messing with the system group > definitions (adding users to group uucp)." but I really didn't have > any problem with that > > 1. doesn't exist on the standard installation > there are many-many things that don't exist in the standard > installation so I don't think that argument is strong enough > 2. messing with the system group definitions > I don't think we're messing with the group definition > mac os x provides very clear way to set up group's members and > together with Greg Guerin AuthKit there is no problem to set those > definitions > so I don't think that argument is strong either > but from other hand using iotcl is more promising and is more elegant > > > > On Mar 21, 2006, at 1:05 PM, Trent Jarvi wrote: > >> >> This looks like a good start. What do you think Dmitry? Perhaps >> all systems with TIOCEXCL defined should use that though. Even if >> they use lockfiles. It wont hurt anything. That would catch >> people hacking their own serial apps without checking lockfiles. > > Dmitry Markman > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From dmarkman at mac.com Wed Mar 22 05:27:13 2006 From: dmarkman at mac.com (Dmitry Markman) Date: Wed, 22 Mar 2006 07:27:13 -0500 Subject: [Rxtx] PATCH: use of ioctl(fd, TIOCEXCL) instead of lockfiles In-Reply-To: References: <923AE774-EEA2-4911-92D8-32BB27802C8B@buechse.de> Message-ID: <83440CF3-DCD8-41C1-B941-F227232C27E3@mac.com> thanks for the very good explanation I didn't think that you were attacking any thing, so don't worry I just had feeling, that there were more aesthetic reasons for going to ioctl then real necessity now you explained everything quite well (BTW, asfar as I remember installer asks admin password so it wasn't quiet, but it really doesn't matter now) thanks On Mar 22, 2006, at 6:46 AM, Joachim Buechse wrote: > Sorry, I was not very clear with my arguments, so I will try again;-) > > Please, don't take this as an attack against work that has been > done. I think the contributions that have been made in the past > were made in a good spirit. But I really believe, that the current > solution for OSX has many shortcomings and should be changed as > soon as possible. > > lock files > --- > The /var/lock folder does not exist on the standard OSX > installation, however the standard installation includes several > applications that use serial ports (i.e. the FAX capability). This > indicates, that the lock folder approach will not work well with > system components. Applications for OSX will generally try to live > in harmony with system components (except for HP print drivers of > course). I think RXTX should follow this approach as well. > > uucp group > --- > Accessing serial ports is not an admin privileged operation on OSX. > Any user (world) has read/write privileges on /dev/tty*. So the > system default is to not enforce any group membership to access > these ports. The group uucp however is a system group on all unix > systems I know. It exists for certain system processes. A non admin > user should in general not be a member of this group. Quite > arguably no user should ever be a member of this group. > > Installer > --- > My general opinion is, that > - no Installer should touch user or group data without warning > - no Application Installer should touch groups which are not > specific to the very application installed > - no Installer should ever add regular users to a system group > > The current installer injects the installing user in the group uucp > without warning about this change and without giving the option to > "opt out" of this change. This is a potential security risk (but > not currently a real one, as OSX contains no folders belonging to > group uucp). > > The current installer does not work for multi user systems. It puts > the installing user in the uucp group. However the installing user > is not necessarily the user that will use the application. Putting > all users that may use a serial port application in the system > group uucp seems like a very invasive approach to me. Besides that, > newly created users will not automatically be in the group and > hence, serial applications will "break" for new users without > obvious reasons. > > > Avoiding the lock files will allow self contained applications > (i.e. drag&drop installation). In my eyes this is largely > preferable over an installer that requests admin privileges. Adding > up all these points indicates very strongly, that the lock-file > implementation is not the way to go on OSX. > > Regards, > Joachim > > > On 22.03.2006, at 00:13, Dmitry Markman wrote: > >> I'd like to add that >> >> creating locking folder isn't a big deal >> we never had a problem related to the lock folders, because we >> always used installer on mac os x >> from other hand I'm not very much familiar with iotcl locking >> approach and I'm not sure it's more efficient >> >> Joachim wrote "I think it is the way to go, as it eliminates >> creating the lock directory which doesnt exist on the standard >> installation and it eliminates messing with the system group >> definitions (adding users to group uucp)." but I really didn't >> have any problem with that >> >> 1. doesn't exist on the standard installation >> there are many-many things that don't exist in the standard >> installation so I don't think that argument is strong enough >> 2. messing with the system group definitions >> I don't think we're messing with the group definition >> mac os x provides very clear way to set up group's members and >> together with Greg Guerin AuthKit there is no problem to set those >> definitions >> so I don't think that argument is strong either >> but from other hand using iotcl is more promising and is more elegant >> >> >> >> On Mar 21, 2006, at 1:05 PM, Trent Jarvi wrote: >> >>> >>> This looks like a good start. What do you think Dmitry? Perhaps >>> all systems with TIOCEXCL defined should use that though. Even >>> if they use lockfiles. It wont hurt anything. That would catch >>> people hacking their own serial apps without checking lockfiles. >> >> Dmitry Markman >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx Dmitry Markman From lyon at docjava.com Wed Mar 22 06:12:18 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Wed, 22 Mar 2006 08:12:18 -0500 Subject: [Rxtx] sole of a new design pattern Message-ID: Hi All, I have been thinking about how we design the serial port software. I think we need a new design pattern. For lack of a better term, I shall call it: The Parametric Singleton Design Pattern By Douglas A. Lyon ABSTRACT The goal of the singleton design pattern is to make sure that there is one, and only one, instance of a given class. The goal of the parametric singleton design pattern is to make sure that there is one, and only one, instance of a given class with the given parametric values. We parametric singleton design pattern combines the singleton design pattern with a parameter that enables unique creation of instances of a class. These instances are cached. When a user asks for an instance with these parameters, the cache is checked. If the instance is in the cache, the instance is returned, otherwise it is created, added to the cache and then returned. We apply our parametric singleton design pattern to the retrieval of RMI registries bound to a given port. The goal of our system is to make sure that no two RMI registries are listening to the same socket and to make use of the RMI registries after they have been created. RMI registries are used in distributed computation. Introduction The singleton design pattern is meant to ensure that on a single instance of a class exists. It is also meant to provide a global point of access to it. The intent of the parametric singleton design pattern is to ensure that a class has only one instance for a given set of parameter values. It also provides a global point of access to it. Motivation A system cannot tolerate multiple instances of some classes with identical parameters. For example, you cannot have two instances making use of the same serial port, at the same time. You cannot have two instances that are trying to listen to the same socket connection. You cannot have two instances writing to the same file structure at the same time. As the operating system is often thought of as the arbiter of consumed resources (i.e., tape drives, serial ports, etc.) we frequently leave it to an operating system implementation to resolve these contention issues. Even for similar resources (like serial ports) there are few standards for handling contention. For example, serial ports on Linux are locked using a "/var/lock" file. POSIX, on the other hand, uses ioctl mechanisms to prevent contention. A better solution is to make a class that is responsible for keeping track of the instances created from the class. The class is declared final, so that it cannot be subclassed. The class also has a private constructor, so that other classes cannot instance it. The new design pattern is called the parametric singleton design pattern and it provides a way to access and create instances with given parameters. Applicability Use the Parametric Singleton Design Pattern when: 1. There must be exactly one instance of a class with the given parameters. 2. The instances must be accessible to clients from a well-known access point. Structure Insert UML diagram here. Participants The Parametric Singleton Clients that need instances 1. The Parametric Singleton defines an instance upon request from a client, if, and only if, the instance does not already exist. 2. The Parametric Singleton returns the instance to the client. 3. The Parametric Singleton is responsible for creating unique instances from given parameters. Collaborations Clients obtain a reference to a Parametric Singleton instance only through the parametric singleton design pattern. If the instance is left in an improper state (e.g., the serial port was left open) it is NOT the role of the Parametric Singleton Design Pattern to close the IO port. Nor is it the role of the Parametric Singleton Design Pattern to open the port. That role is delegate to some other part of the system. Further, it is not the role of the Parametric Singleton Design Pattern to check out resources. That is, multiple threads can have multiple references to the same resource at the same time. MUTEX locking is delegated to some other part of the system. Consequences The Parametric Singleton Design Pattern has several benefits: 1. Controlled access to parametrically defined instances. Since the Parametric Singleton class encapsulates its instances, there is control over how and when clients access it. 2. Reduced name space. The Parametric Singleton pattern avoids global variables that store instances created from the same parameter. Implementation Here are implementation issues to consider when using the Parametric Singleton pattern: 1. Unique mapping of parameters. The Parametric Singleton pattern requires that there be a mean to isomorphically map the parameter space into the instance space and back again. 2. Ensure unique instances. The Parametric Singleton pattern makes unique instances from parameters, and it does so only once. 3. Cache instances for fast retrieval. The Parametric Singleton pattern must be able to look up instances, given some set of parameters, and do so from some data structure. That is, there must be enough space to hold references to all the instances the program will need. Also, a mechanism is needed to look up and retrieve the instances quickly enough to satisfy the clients. Sample Code public final class ParametricSingletonRmiRegistry { private static Hashtable registry = new Hashtable(100); // use singleton pattern and??????????????????????????????????????????????? // prevent instantiation of RmiRegistryUtils.?????????????????????????????? private ParametricSingletonRmiRegistry() { } // the only instance of the Registry held by the RmiRegistryUtils?????????? public static void listNames(Integer port) { if (!isInCacheAndRunning(port)) return; Registry r = (Registry) registry.get(port); System.out.println("registry on port: " + port); System.out.println("registry: " + r); System.out.println("names: "); try { print(r.list()); } catch (RemoteException e) { In.message(e); } System.out.println("------------------------"); } /**???????????????????????????????????????????????????????????????????????? * Checks whether a Registry has been started on this host????????????????? * in the specified port.?????????????????????????????????????????????????? * If not, it tries to start one.?????????????????????????????????????????? * when it fails to start a Registry, it exits the program????????????????? * with exit code 1.??????????????????????????????????????????????????????? */ public static void restart(int port) { if (isInCacheAndRunning(port)) return; try { startRegistry(port); } catch (RemoteException e) { In.message(e); } } /**???????????????????????????????????????????????????????????????????????? * @param port????????????????????????????????????????????????????????????? * @return true if registry is in cache and running???????????????????????? */ private static boolean isInCacheAndRunning(Integer port) { if (!isRegistryRunning(port.intValue())) return false; if (!isRegistryInCache(port.intValue())) return false; return true; } /**???????????????????????????????????????????????????????????????????????? * @param port????????????????????????????????????????????????????????????? * @return true if we are able to locate a local registry on port.??????????????????????????????????????????????????????????????????????????? */ private static boolean isRegistryRunning(int port) { try { Registry r = LocateRegistry.getRegistry(port); if (r != null) return true; } catch (RemoteException e) { return false; } return false; } /**???????????????????????????????????????????????????????????????????????? * @param port????????????????????????????????????????????????????????????? * @return return true if registry is in cache????????????????????????????? */ private static boolean isRegistryInCache(int port) { if (registry.get(new Integer(port)) == null) return false; return true; } /**???????????????????????????????????????????????????????????????????????? * Restart the registry, if needed.???????????????????????????????????????? * Return the only instance of the registry for consistent global?????????? * using by making use of the Singleton Design Pattern????????????????????? *????????????????????????????????????????????????????????????????????????? * @return the internally held registry instance.?????????????????????????? */ public static Registry getRegistry(Integer port) { restart(port); return (Registry) registry.get(port); } private static void startRegistry(Integer port) throws RemoteException { Registry r; try { r = LocateRegistry.createRegistry(port.intValue()); registry.put(port, r); //r = new sun.rmi.registry.RegistryImpl???????????????????????????? /// (port.intValue());?????????????????????????????????????? // registry.put(port, r);?????????????????????????????????????????? } catch (Exception e) { //e.printStackTrace();????????????????????????????????????????????? r = LocateRegistry.getRegistry(port.intValue()); registry.put(port, r); } } public static void main(String args[]) throws RemoteException { //restart(port);??????????????????????????????????????????????????????? restart(5001); restart(5002); restart(5002); Registry r = LocateRegistry.getRegistry(5002); System.out.println("registry="+r); } } I would very much like to get your feedback on this new design pattern idea. Thank you for your time. Regards, - Doug From david.garnier at trusted-logic.com Wed Mar 22 07:36:10 2006 From: david.garnier at trusted-logic.com (David Garnier) Date: Wed, 22 Mar 2006 15:36:10 +0100 Subject: [Rxtx] sole of a new design pattern In-Reply-To: References: Message-ID: <442160DA.80107@trusted-logic.com> Hello, > The Parametric Singleton Design Pattern The Singleton is the most abused design pattern ever. Good use-cases for this pattern are extremely rare and mostly confined to problems related to hardware resources, like serial ports. > Applicability > > Use the Parametric Singleton Design Pattern when: > 1. There must be exactly one instance of a class with the given > parameters. OK. As I said above, this case this actually very unusual. The Singleton pattern is mostly used when : > 2. The instances must be accessible to clients from a well-known > access point. Using the singleton pattern in this case is just convenient for the programmer. Problems arises pretty quickly, especially if you attempt to unit-test your classes. 1) If your singleton is stateful, or hold on to stateful objects, it means that two different unit tests are not actually independent. Instead of starting with a brand new environment, the result of a test may be affected by the result of a previous test. This problem also arise when with your class relies on a database. In both cases, the solution is to reset your "unique" resource (Singleton or database) at the beginning of the test, which is a pain. Also, while most projects connect to a single database, projects that allow the use of Singletons usually contain several of thems, and new ones may cropped up unnoticed. You quickly end up with test cases that only pass in a certain order, which is a royal pain. 2) You cannot mockup a singleton. Once everyone calls the SomeSingleton class statically, you can't replace your class by SomeSingletonMockup. Furthermore, even for hardware services, the Singleton pattern does not really prevent concurrent accesses. If you start the same program in two different JVMs, unless they somehow shared the state of their "Singletons" (through lock files for example), the Singleton pattern will not prevent concurrent access. Our application uses RXTX, and we routinely encounter cases where another (native) application has already locked the port. Since we cannot modify the native application to recognize lock files, OS-level control is irreplaceable. > > Consequences > The Parametric Singleton Design Pattern has several benefits: > > 1. Controlled access to parametrically defined instances. Since > the Parametric Singleton class encapsulates its instances, there is > control over how and when clients access it. Not really. Once you've returned the instance to a client, you've lost control over it. The client can to whatever it wants with it. You cannot "recall" the instance or claim it back. > 2. Reduced name space. The Parametric Singleton pattern avoids > global variables that store instances created from the same parameter. Sure, but you don't have to rely on a Singleton for that. Just create a single Factory. > I would very much like to get your feedback on this new design > pattern idea. Well, it's nothing new. Some may say that it is the point of design patterns: formalizes the designs that occur again and again. However, this design is simply a combination of the Singleton and Factory patterns. I did use it in the past, but now I've been exposed to the shortcomings of the Singleton pattern, so I limit myself to Factories. Regards, David From sean_montgomery at baseview.com Wed Mar 22 08:35:28 2006 From: sean_montgomery at baseview.com (Sean Montgomery) Date: Wed, 22 Mar 2006 10:35:28 -0500 Subject: [Rxtx] sole of a new design pattern In-Reply-To: <442160DA.80107@trusted-logic.com> References: <442160DA.80107@trusted-logic.com> Message-ID: <05769CA7-A51B-4CF0-BAA0-E02DD905F5A4@baseview.com> On Mar 22, 2006, at 9:36 AM, David Garnier wrote: > Furthermore, even for hardware services, the Singleton pattern does > not really prevent concurrent > accesses. If you start the same program in two different JVMs, > unless they somehow shared the state > of their "Singletons" (through lock files for example), the > Singleton pattern will not prevent > concurrent access. > Multiple class loaders in a single JVM can be tricky, too. Then there's synchronization, lazy initialization and serialization of singletons to contend with. Bloch's Effective Java covers these, and here's a few articles: http://www.javaworld.com/javaworld/jw-04-2003/jw-0425-designpatterns- p3.html http://java.sun.com/developer/technicalArticles/Programming/singletons/ Just FYI :-) From lyon at docjava.com Wed Mar 22 08:50:48 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Wed, 22 Mar 2006 10:50:48 -0500 Subject: [Rxtx] sole of a new design pattern In-Reply-To: <442160DA.80107@trusted-logic.com> References: <442160DA.80107@trusted-logic.com> Message-ID: Hi All, First, I would like to thank David for his prompt and thoughtful remarks. I had no idea people that feel strongly about a design patterns! Wow! Feedback (particularly critical feedback) is greatly appreciated. Starting at the end, first: >I did use it in >the past, but now I've been exposed to the shortcomings of the >Singleton pattern, so I limit myself to Factories. David, if I understood your comments correctly, you suggested that Factories can be used in leu of the Singleton Design Pattern, or even the Parametric Singleton Design Pattern. As I see in [Gof]: Factory Method: Intent "Define an interface for creating an object, but let subclasses decide which class to instantiate. Factory Method lets a class defer instantiation to subclasses." The Singleton Design Pattern is a concrete class, which is rather different, right? Also, subclasses are not permitted with Singleton, as they are final. Naturally, I could use an abstract factory as a parent for a singleton. I could even design a facade that could be implemented with the singleton....but that is not the intention of the design. Unless you want a mock-up, as discussed, below: More below: >Hello, > >> The Parametric Singleton Design Pattern > >The Singleton is the most abused design pattern ever. Good use-cases >for this pattern are extremely >rare and mostly confined to problems related to hardware resources, >like serial ports. > > >> Applicability >> >> Use the Parametric Singleton Design Pattern when: >> 1. There must be exactly one instance of a class with the given >> parameters. >OK. As I said above, this case this actually very unusual. The >Singleton pattern is mostly used when : >> 2. The instances must be accessible to clients from a well-known >> access point. > >Using the singleton pattern in this case is just convenient for the >programmer. Problems arises >pretty quickly, especially if you attempt to unit-test your classes. > >1) If your singleton is stateful, or hold on to stateful objects, it >means that two different unit >tests are not actually independent. Instead of starting with a brand >new environment, the result of >a test may be affected by the result of a previous test. This >problem also arise when with your >class relies on a database. In both cases, the solution is to reset >your "unique" resource >(Singleton or database) at the beginning of the test, which is a >pain. Also, while most projects >connect to a single database, projects that allow the use of >Singletons usually contain several of >thems, and new ones may cropped up unnoticed. You quickly end up >with test cases that only pass in a >certain order, which is a royal pain. There are basic problems with communicating finite state machines that include reachability and deadlock analysis. These are addressed with petri net analysis and are beyond the scope of the design pattern. As you quite rightly pointed out; the parametric singleton pattern (or the singleton pattern, for that matter) enable multiple threads to gain access to the same instance. The only way that I can see to block others from gaining access to the reference is the synchronize keyword. This is putting a spin-lock (or MUTEX) on the reference. The question of how to unit-test a design pattern like the parametric singleton remains open. Perhaps this is a deficiency. > >2) You cannot mockup a singleton. Once everyone calls the >SomeSingleton class statically, you can't >replace your class by SomeSingletonMockup. Acutally, I am not sure that this is true. If the Singleton implements a Facade interface, it should be possible to make the replacement. Right? > >Furthermore, even for hardware services, the Singleton pattern does >not really prevent concurrent >accesses. If you start the same program in two different JVMs, >unless they somehow shared the state >of their "Singletons" (through lock files for example), the >Singleton pattern will not prevent >concurrent access. Good Point!! You have sharp eyes! The singleton design pattern should/could take responsibility for this. In fact, you may notice that my code does have an implementation (LocateRegistry) that can work across JVM's. The LocateRegistry will even work across the Internet! LocateRegistry takes both a host name and a Port (lock files just don't do this). I did not think to implement this beyond the local machine, but, in its present form, it will work across different processes. > >Our application uses RXTX, and we routinely encounter cases where >another (native) application has >already locked the port. Since we cannot modify the native >application to recognize lock files, >OS-level control is irreplaceable. The singleton design pattern is not meant to replace OS-level control, but to centralize the Java programmers access to it. If lock files, for example, are used for serial ports, the Singleton Design Pattern should be able to work with them. > > >> >> Consequences >> The Parametric Singleton Design Pattern has several benefits: >> > > 1. Controlled access to parametrically defined instances. Since >> the Parametric Singleton class encapsulates its instances, there is >> control over how and when clients access it. > >Not really. Once you've returned the instance to a client, you've >lost control over it. The client >can to whatever it wants with it. You cannot "recall" the instance >or claim it back. Good point, this should read: > 1. Controll when parametrically defined instances are created. Since > > the Parametric Singleton class encapsulates its instances, there is > > control over how and when they are instanced. > >> 2. Reduced name space. The Parametric Singleton pattern avoids >> global variables that store instances created from the same parameter. > >Sure, but you don't have to rely on a Singleton for that. Just >create a single Factory. > > Thank you for your thoughtful and prompt response! Regards, - Doug From dmarkman at mac.com Wed Mar 22 21:21:55 2006 From: dmarkman at mac.com (Dmitry Markman) Date: Wed, 22 Mar 2006 23:21:55 -0500 Subject: [Rxtx] sole of a new design pattern In-Reply-To: <442160DA.80107@trusted-logic.com> References: <442160DA.80107@trusted-logic.com> Message-ID: I don't think I get it On Mar 22, 2006, at 9:36 AM, David Garnier wrote: > Using the singleton pattern in this case is just convenient for the > programmer. Problems arises > pretty quickly, especially if you attempt to unit-test your classes. so you're saying that something isn't so good because you can not test it in the convenient way? if that's true, I'm totally disagree change your test, debug whatever, but if software is efficient at runtime, works fine and only problem is some unit test (which is some kind of framework for testing) then dump that unit test , dump that unit framework and make something appropriate to the software you're testing so if Douglas want to use singletons, what's the problem? and what do you mean by abusing of singleton usage? of course singleton doesn't prevent concurrent access to the resource across the processes unless you're using some OS facility to prevent it, besides singleton as it was introduced is relevant only and only inside of the same process otherwise it's not singleton it's something else (let's say network singleton: so you have remote invocation facility and some factory method that return object created by that facility) I don't have any problem with using any kind of singletons. Parametric Singleton idea (if I understand it right) could be easily implemented in the following way: use a map populate map with instances of some class and key is your parameter (you can use lazy population too) if somebody ask the key check the value if it's null so resource is taken if somebody returns the resource put it back to the map public synchronized static Object getSomeResource(Object parameter); public synchronized static void returnResource(Object parameter); getSomeResource (inside of the same process) could return null in 2 cases 1. if somebody (from other thread for example) already took that resource 2. if OS API said that resource corresponded to that parameter (serial port with parameter = 1 (port #)) is locked and unavailable; I'm not sure that in case of serial ports we even need those Parametric Singletons (unless lock checking is a very expensive operation) just ask the OS about availability of that resource and if it's available give it away and then OS will lock it and therefore in next time somebody ask it just answer that resource is locked and return null for example system has 2 serial ports available so I ask getResource("tty"); or I ask getResource("Bluetooth-Modem"); and if OS is ok you can give tty or Bluetooth-Modem or both no need for any additional pattern I think back to the problem mac os x doesn't recognize locking via files, so it handles locking via some API an instance of the singleton in each process should recognize that resource is locked (by using that API) that's all we don't have to make things more complicate then they are just because there is some nice design pattern or nice unit test framework or whatever keep things simple, make them work fast, don't introduce middle layers unless you have really good reason to do so of course I could be entirely wrong, so sorry about that in advance thanks Dmitry Markman From tjarvi at qbang.org Wed Mar 22 22:31:41 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 22 Mar 2006 22:31:41 -0700 (MST) Subject: [Rxtx] sole of a new design pattern In-Reply-To: References: Message-ID: Hi Doug Interesting reading. So far I'm just reading and thinking. I have one question so far. " Clients obtain a reference to a Parametric Singleton instance only through the parametric singleton design pattern. If the instance is left in an improper state (e.g., the serial port was left open) it is NOT the role of the Parametric Singleton Design Pattern to close the IO port. Nor is it the role of the Parametric Singleton Design Pattern to open the port. That role is delegate to some other part of the system. " So when the clients obtain a reference to the singleton, can they assume the port is there? IE, would it be the singletons role to handle things like USB dongles being removed with event hints comming from the underlying OS. Hardware abstraction layer/HAL on Linux is an example of underlying OS events. I assume that role too is delegated to other parts of the system? -- Trent Jarvi tjarvi at qbang.org From lyon at docjava.com Thu Mar 23 08:10:33 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Thu, 23 Mar 2006 10:10:33 -0500 Subject: [Rxtx] Classes don't need goals, they need roles! In-Reply-To: References: Message-ID: Hi Trent, Yes, I think that the role of the Parametric Singleton Pattern is not to open or close serial ports, nor is it to perform error checking. On the other hand, if you were to combine the role of the Parametric Singleton Pattern with another role (like that of error checking) it might not be amiss. However, I generally caution programmers against adding multiple roles to classes, as this leads to monolithic designs. Thus a different class (NativeLibDetect) could have the role of determining if the native library can be loaded. Another class (SerialPortBean) can have the role of serializing the default state of the serial port, so that it can be recovered, from user preferences, at a later time. The SerialPortDetect could have the role of determining if the serial port is removed (i.e., a USB port was unplugged). My guess is that each class should have a different role in the system, in order to ease maintenance and testing...but I could be wrong about that. Thanks! - Doug >Hi Doug > >Interesting reading. So far I'm just reading and thinking. I have >one question so far. > >" > Clients obtain a reference to a Parametric Singleton instance only >through the parametric singleton design pattern. If the instance is >left in an improper state (e.g., the serial port was left open) it is >NOT the role of the Parametric Singleton Design Pattern to close the >IO port. Nor is it the role of the Parametric Singleton Design Pattern >to >open the port. That role is delegate to some other part of the system. >" > >So when the clients obtain a reference to the singleton, can they >assume the port is there? IE, would it be the singletons role to >handle things like USB dongles being removed with event hints >comming from the underlying OS. Hardware abstraction layer/HAL on >Linux is an example of underlying OS events. > >I assume that role too is delegated to other parts of the system? > >-- >Trent Jarvi >tjarvi at qbang.org >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From maximulo at yahoo.com Fri Mar 24 01:22:38 2006 From: maximulo at yahoo.com (Maximulo Majir) Date: Fri, 24 Mar 2006 00:22:38 -0800 (PST) Subject: [Rxtx] JavaPOS Message-ID: <20060324082238.66371.qmail@web38214.mail.mud.yahoo.com> Hi all! Hello Trent! From what i understand, RXTX or JavaComm APIs were not created solely for JavaPOS. In JavaPOS, we have the virtual method claim() which is separate from open(), but in our RXTX API, claiming is done every call to open(), we cant open the port if its claimed by another application. Would it be alright to suggest or ask to create a new method called claim(..)? Is there such thing as forceclaim() in RXTX? this could be the same as portownership transfer or its equivalent. ForceClaim is in JSR80. Do you have some samples using RXTX as the lower layer for the Device Service Objects in JavaPOS? I have tried it, i just want to compare. Thank you all! maxim __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060324/496adba2/attachment-0006.html From tjarvi at qbang.org Fri Mar 24 11:28:19 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 24 Mar 2006 11:28:19 -0700 (MST) Subject: [Rxtx] Re: RXTX 2.1 Solaris Problems In-Reply-To: <3691.1143210578@www045.gmx.net> References: <3691.1143210578@www045.gmx.net> Message-ID: On Fri, 24 Mar 2006, Andreas Guenther wrote: > Hi all, > > the solaris problem was not the lock file only. > > Ok, I had to create the directory /var/spool/locks myself. > /var/spool/uucp exists. > > But rxtx didn't find any port. > > I compiled the source with my own debug-informations > and I tried to isolate the problem. > > The problem is the testRead-call in SerialImp.c > > JNIEXPORT jboolean JNICALL RXTXCommDriver(testRead)( > > ... > if ( READ( fd, &c, 1 ) < 0 ) > { > if ( errno != EAGAIN ) { > report( "testRead() read failed\n" ); > ret = JNI_FALSE; > } > } > Thanks Andreas I'm packing up to move. I'll be more or less away for a couple weeks here. I'll be checking email but my workstation is going into a box soon. This isn't hard to fix as this port should be enumerated when EWOULDBLOCK is recieved. Thats error is OK for enumeration just as EAGAIN is. I've put the bug into bugzilla so we dont forget to get to it. http://bugzilla.qbang.org/show_bug.cgi?id=42 You can add yourself to the CC list if you wish to test fixes we provide or even put a patch into bugzilla yourself. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Fri Mar 24 11:51:52 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 24 Mar 2006 11:51:52 -0700 (MST) Subject: [Rxtx] JavaPOS In-Reply-To: <20060324082238.66371.qmail@web38214.mail.mud.yahoo.com> References: <20060324082238.66371.qmail@web38214.mail.mud.yahoo.com> Message-ID: On Fri, 24 Mar 2006, Maximulo Majir wrote: > Hi all! Hello Trent! > > > From what i understand, RXTX or JavaComm APIs were not > created solely for JavaPOS. In JavaPOS, we have the virtual method > claim() which is separate from open(), but in our RXTX API, claiming is > done every call to open(), we cant open the port if its claimed by > another application. Would it be alright to suggest or ask to create a > new method called claim(..)? Is there such thing as forceclaim() in > RXTX? this could be the same as portownership transfer or its > equivalent. ForceClaim is in JSR80. > Do you have some samples using RXTX as the lower layer for the Device > Service Objects in JavaPOS? I have tried it, i just want to compare. > maxim Hi Maxim JSR80 is the USB API IBM/Sun put together. The problem is they have a richer kernel/API underneath that can handle such things. With Serial Ports, there isnt anything there other than an ioctl that says don't let anyone touch this and lockfiles that are more of a 'lets be nice.' At times we may be using USB ports but it is through the termios layer with the limitations mentioned. The advantage is that not only USB will work with rxtx. Anything that has a termios layer should work (to the extent that termios layer is complete). I don't know how forceclaim() would help you. Lets say someone has a programmer working on /dev/ttyS0 and you take it. Now you both race each other to read data first. There isn't a mechanism I know of that will solve this problem in termios. The most obvious test being a native app and a Java app trying to take the port. There is the potential of requestion ownership from other Java Applications but the use for that is very rare. Did you have something more specific in mind that I'm missing? I'm not sure that claim() and forceclaim() would help you with rxtx other than maybe locking the port with claim() without opening it. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sat Mar 25 23:42:08 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 25 Mar 2006 23:42:08 -0700 (MST) Subject: [Rxtx] Serial snoop Message-ID: I was reading the Linux kernel mail-list tonight and ran past a thread that mentioned sersnoop. This looks like a handy tool for people dealing with new toys. "a simple command-line tool for linux that echoes bytes to and from any two serial ports, ptys, or network sockets, and prints all traffic to stdout, in hex and ascii." http://www.restivo.org/projects/sersnoop/ It works on Linux only at this time (debian package available). -- Trent Jarvi tjarvi at qbang.org From beat.arnet at gmail.com Sun Mar 26 07:32:35 2006 From: beat.arnet at gmail.com (Beat Arnet) Date: Sun, 26 Mar 2006 09:32:35 -0500 Subject: [Rxtx] Error 0x5 at /home/bob/foo/tar/rxtx-2.1-7/build/../src/termios.c(860): Access is, denied. Message-ID: <4426A603.80508@gmail.com> Dear all, When trying to open the serial port, I sometimes (not always) run into the following exception (when opening the serialPort): Error 0x5 at /home/bob/foo/tar/rxtx-2.1-7/build/../src/termios.c(860): Access is denied. java.lang.UnsatisfiedLinkError: native_psmisc_report_owner at gnu.io.CommPortIdentifier.native_psmisc_report_owner(Native Method) at gnu.io.CommPortIdentifier.open(CommPortIdentifier.java:354) at codeskin.tools.CLLoader.open(CLLoader.java:79) at codeskin.tools.C2000Programmer.run(C2000Programmer.java:220) at java.lang.Thread.run(Unknown Source) Is this the type of error where I should just try to open the port again, or can it be avoided? Regards, Beat From tjarvi at qbang.org Sun Mar 26 11:40:12 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 26 Mar 2006 11:40:12 -0700 (MST) Subject: [Rxtx] Error 0x5 at /home/bob/foo/tar/rxtx-2.1-7/build/../src/termios.c(860): Access is, denied. In-Reply-To: <4426A603.80508@gmail.com> References: <4426A603.80508@gmail.com> Message-ID: On Sun, 26 Mar 2006, Beat Arnet wrote: > Dear all, > > When trying to open the serial port, I sometimes (not always) run into > the following exception (when opening the serialPort): > > Error 0x5 at /home/bob/foo/tar/rxtx-2.1-7/build/../src/termios.c(860): > Access is > denied. > > java.lang.UnsatisfiedLinkError: native_psmisc_report_owner > at gnu.io.CommPortIdentifier.native_psmisc_report_owner(Native > Method) > at gnu.io.CommPortIdentifier.open(CommPortIdentifier.java:354) > at codeskin.tools.CLLoader.open(CLLoader.java:79) > at codeskin.tools.C2000Programmer.run(C2000Programmer.java:220) > at java.lang.Thread.run(Unknown Source) > > Is this the type of error where I should just try to open the port again, > or can it be avoided? > Hi Beat We did a second build of rxtx 2.1-7 to resolve that unsatisfied link error. It should work now. rxtx is trying to tell you it thinks someone else has the serial port open. You can try to open the port again but maybe you already have a copy of the program running when it happens? ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7r2.zip fixed build. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sun Mar 26 11:44:23 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 26 Mar 2006 11:44:23 -0700 (MST) Subject: [Rxtx] RXTX spec file (fwd) Message-ID: This is probably interesting for fedora/suse users. ---------- Forwarded message ---------- Date: Sun, 26 Mar 2006 16:25:45 +0200 To: taj at www.linux.org.uk Subject: RXTX spec file I send you this spec file which allows to create a RPM for Fedora 4, 5 (x86, x86_64) with Java Sun. -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: rxtx.spec Url: http://mailman.qbang.org/pipermail/rxtx/attachments/20060326/6c7b6af6/rxtx-0002.pl From tjarvi at qbang.org Sun Mar 26 23:42:59 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 26 Mar 2006 23:42:59 -0700 (MST) Subject: [Rxtx] Upcomming events. Message-ID: This Wednesday we will be announcing a new "Maintainer" for the rxtx project. The position is more like neutral leader. I wont be going away or doing less. This is just the right thing to do as it turns out the two people with CVS write access will be at the same company. We need a third and we need neutrality. The maintainer will have final say in any conflict and will try to be neutral. It will be open for discussion. Then we will do it :) I'll still do most of the footwork I do now. But. I'm falling behind. I should have gone through the mail-list and posted the next round of changes this weekend. I'm packing to move and its going so so - 13 years of toys collected. I suspect there will be a dead period on my part (a couple weeks) comming up. But if you get it on the mail-list, we will get it in if there are no objections. I may well not be reading the mail-list during this period as I look for a house and many other things. I hope everyone will help out. Thanks -- Trent Jarvi tjarvi at qbang.org From mahmoud_hadad at yahoo.com Sun Mar 26 07:31:19 2006 From: mahmoud_hadad at yahoo.com (ronan nick) Date: Sun, 26 Mar 2006 06:31:19 -0800 (PST) Subject: [Rxtx] a question about the COMM API Message-ID: <20060326143119.54919.qmail@web60014.mail.yahoo.com> hi, i was intrested in knowing how i can communicate with my internal modem using java? for example if i want to make a phone dialer application or a caller id application where should i be looking at? and as i understood the COMM API is for devices that is attached to the computer through serial ports. --------------------------------- New Yahoo! Messenger with Voice. Call regular phones from your PC and save big. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060326/ce8329f0/attachment-0004.html From dmarkman at mac.com Mon Mar 20 00:20:43 2006 From: dmarkman at mac.com (Dmitry Markman) Date: Mon, 20 Mar 2006 02:20:43 -0500 Subject: [Rxtx] Mac OS X RXTX java installer In-Reply-To: References: <07D0DE29-BA32-4CFE-B036-66BC6423D385@buechse.de> <441AE3E0.2030503@willicon.de> <12531986.1142622114996.JavaMail.dmarkman@mac.com> <441B2674.9010409@willicon.de> <13577405.1142634732776.JavaMail.dmarkman@mac.com> <441B4182.8010407@willicon.de> <92CD0D6C-5BE8-426E-A46D-99452059FF49@mac.com> <441BBB2D.8030305@willicon.de> <441C4088.5090905@willicon.de> Message-ID: <64BC1E23-FDDE-4CE6-8863-CFC881CBC224@mac.com> Hi all I put RXTX installer that will install everything (and will create / var/lock if necessary and add user to the uucp group) for mac os x from Java into the rxtx's CVS repository it could be easily modified to install files for any platform it uses Greg Guerin's AuthKit for authentication and authorization Greg released that kit under artistic license, so Trent, please take a look we, probably, can negotiate license with Greg if it's necessary Greg's AuthKit could be downloaded from http://www.amug.org/~glguerin/ sw/#authkit Michael Hall (mikehall at spacestar dot net) had a suggestion to make implementation of the jaas LoginModule based on Greg's AuthKit (his modification of the Greg's AuthKit could be found at http:// www.spacestar.net/users/mikehall/authkit.dmg) but Michael's AuthKitLoginModule does only half a job: it does authenticate but it can not run any external unix process in privileged mode (at least I wasn't able to do so) possible explanation could be found in conversation between Greg and Michael at Apple's java-dev list (look for archives) so I didn't use jaas API for rxtxinstaller I created folder MacOSX in the contrib folder comment 1. if you want to run that installer as standalone application all you need that RXTXInstaller.jar 2. if you want to use webstart you have to add Greg's libAuthKit.jnilib to the mac os x's resources in theory RXTXInstaller.jar doesn't need it, but there is a problem with loading libAuthKit.jnilib from webstart authkit uses loadLibrary method to load library and it failed (from webstart) for standalone application I extract libAuthKit.jnilib from the RXTXInstaller.jar and put it into the /Library/Java/Extensions or ~/Library/Java/Extensions folder that file will be deleted after installer quit unfortunately I didn't have time to put documentation there but it is mostly self-explanatory I took installer code from my gl4java installer that I did about 3 years ago (with small modifications) it would be very nice if Apple will release LoginModule that really will do the job (com.apple.security.auth.module package????? ) (UnixLoginModule is pretty useless) From lyon at docjava.com Mon Mar 20 06:34:39 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Mon, 20 Mar 2006 08:34:39 -0500 Subject: [Rxtx] Mac OS X RXTX java installer In-Reply-To: <64BC1E23-FDDE-4CE6-8863-CFC881CBC224@mac.com> References: <07D0DE29-BA32-4CFE-B036-66BC6423D385@buechse.de> <441AE3E0.2030503@willicon.de> <12531986.1142622114996.JavaMail.dmarkman@mac.com> <441B2674.9010409@willicon.de> <13577405.1142634732776.JavaMail.dmarkman@mac.com> <441B4182.8010407@willicon.de> <92CD0D6C-5BE8-426E-A46D-99452059FF49@mac.com> <441BBB2D.8030305@willicon.de> <441C4088.5090905@willicon.de> <64BC1E23-FDDE-4CE6-8863-CFC881CBC224@mac.com> Message-ID: Hi Dimitry, This sounds like great work. Just a couple of questions; After the check out of the CVS files, using: setenv CVSROOT :pserver:anonymous at cvs.milestonesolutions.com:/usr/local/cvsroot 53 8:28 setenv PASSWORD mousy 54 8:29 cvs login 55 8:29 cvs checkout rxtx-devel I cd'd over to: rxtx-devel/MACOSX_IDE And found: CVS/ CW/ ForPackageMaker/ PB/ Where is the installer? Thanks! - Doug From tjarvi at qbang.org Mon Mar 20 06:39:37 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 20 Mar 2006 06:39:37 -0700 (MST) Subject: [Rxtx] Mac OS X RXTX java installer In-Reply-To: References: <07D0DE29-BA32-4CFE-B036-66BC6423D385@buechse.de> <441AE3E0.2030503@willicon.de> <12531986.1142622114996.JavaMail.dmarkman@mac.com> <441B2674.9010409@willicon.de> <13577405.1142634732776.JavaMail.dmarkman@mac.com> <441B4182.8010407@willicon.de> <92CD0D6C-5BE8-426E-A46D-99452059FF49@mac.com> <441BBB2D.8030305@willicon.de> <441C4088.5090905@willicon.de> <64BC1E23-FDDE-4CE6-8863-CFC881CBC224@mac.com> Message-ID: On Mon, 20 Mar 2006, Dr. Douglas Lyon wrote: > Hi Dimitry, > This sounds like great work. Just a couple of questions; > After the check out of the CVS files, using: > setenv CVSROOT > :pserver:anonymous at cvs.milestonesolutions.com:/usr/local/cvsroot > 53 8:28 setenv PASSWORD mousy > 54 8:29 cvs login > 55 8:29 cvs checkout rxtx-devel Hi Doug You want "cvs checkout -r commapi-0-0-1 rxtx-devel" to get RXTX 2.1 The default branch is rxtx 2.0 which isn't very active right now. -- Trent Jarvi tjarvi at qbang.org From lyon at docjava.com Mon Mar 20 07:05:44 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Mon, 20 Mar 2006 09:05:44 -0500 Subject: [Rxtx] Mac OS X RXTX java installer In-Reply-To: References: <07D0DE29-BA32-4CFE-B036-66BC6423D385@buechse.de> <441AE3E0.2030503@willicon.de> <12531986.1142622114996.JavaMail.dmarkman@mac.com> <441B2674.9010409@willicon.de> <13577405.1142634732776.JavaMail.dmarkman@mac.com> <441B4182.8010407@willicon.de> <92CD0D6C-5BE8-426E-A46D-99452059FF49@mac.com> <441BBB2D.8030305@willicon.de> <441C4088.5090905@willicon.de> <64BC1E23-FDDE-4CE6-8863-CFC881CBC224@mac.com> Message-ID: Hi Trent, Thanks for the info on the CVS checkout procedure. I did that and am still not sure where the installer is. Here is what I have: cd MACOSX_IDE/ p4.docjava.com{lyon}121: ls CVS/ ForPackageMaker/ PB/ p4.docjava.com{lyon}122: find . | more . ./ForPackageMaker ./ForPackageMaker/RXTX.pkg.sit.hqx ./ForPackageMaker/Resources ./ForPackageMaker/Resources/ReadMe.rtf ./ForPackageMaker/Resources/Welcome.rtf ./ForPackageMaker/Resources/CVS ./ForPackageMaker/Resources/CVS/Entries ./ForPackageMaker/Resources/CVS/Repository ./ForPackageMaker/Resources/CVS/Tag ./ForPackageMaker/Resources/CVS/Root ./ForPackageMaker/Resources/preinstall ./ForPackageMaker/Resources/License.rtf ./ForPackageMaker/Resources/preupgrade ./ForPackageMaker/RXTX.pmsp ./ForPackageMaker/CVS ./ForPackageMaker/CVS/Entries ./ForPackageMaker/CVS/Repository ./ForPackageMaker/CVS/Entries.Log ./ForPackageMaker/CVS/Tag ./ForPackageMaker/CVS/Root ./ForPackageMaker/RXTX_Tiger.pkg.sitx.hqx ./ForPackageMaker/RXTX_Jag.pkg.sit.hqx ./ForPackageMaker/Install ./ForPackageMaker/Install/CVS ./ForPackageMaker/Install/CVS/Entries ./ForPackageMaker/Install/CVS/Repository ./ForPackageMaker/Install/CVS/Tag ./ForPackageMaker/Install/CVS/Root ./ForPackageMaker/Install/Library ./ForPackageMaker/Install/Library/CVS ./ForPackageMaker/Install/Library/CVS/Entries ./ForPackageMaker/Install/Library/CVS/Repository ./ForPackageMaker/Install/Library/CVS/Tag ./ForPackageMaker/Install/Library/CVS/Root ./ForPackageMaker/Install/Library/Java ./ForPackageMaker/Install/Library/Java/Extensions ./ForPackageMaker/Install/Library/Java/Extensions/RXTXcomm.jar ./ForPackageMaker/Install/Library/Java/Extensions/CVS ./ForPackageMaker/Install/Library/Java/Extensions/CVS/Entries ./ForPackageMaker/Install/Library/Java/Extensions/CVS/Repository ./ForPackageMaker/Install/Library/Java/Extensions/CVS/Tag ./ForPackageMaker/Install/Library/Java/Extensions/CVS/Root ./ForPackageMaker/Install/Library/Java/Extensions/librxtxSerial.jnilib ./ForPackageMaker/Install/Library/Java/CVS ./ForPackageMaker/Install/Library/Java/CVS/Entries ./ForPackageMaker/Install/Library/Java/CVS/Repository ./ForPackageMaker/Install/Library/Java/CVS/Entries.Log ./ForPackageMaker/Install/Library/Java/CVS/Tag ./ForPackageMaker/Install/Library/Java/CVS/Root ./ForPackageMaker/RXTX_Tiger.pmproj.sitx.hqx ./CVS ./CVS/Entries ./CVS/Repository ./CVS/Entries.Log ./CVS/Tag ./CVS/Root ./PB ./PB/LibSerialUniversal.xcodeproj.sitx.hqx ./PB/CVS ./PB/CVS/Entries ./PB/CVS/Repository ./PB/CVS/Entries.Log ./PB/CVS/Tag ./PB/CVS/Root ./PB/LibSerial.pbproj.sit.hqx ./PB/startpoint.c ./PB/config.h What is the procedure to run this installer? Do we need a README in: /rxtx-devel/MACOSX_IDE Here is what we have: CVS/ ForPackageMaker/ PB/ Thanks! - DL >On Mon, 20 Mar 2006, Dr. Douglas Lyon wrote: > >>Hi Dimitry, >>This sounds like great work. Just a couple of questions; >>After the check out of the CVS files, using: >>setenv CVSROOT >>:pserver:anonymous at cvs.milestonesolutions.com:/usr/local/cvsroot >> 53 8:28 setenv PASSWORD mousy >> 54 8:29 cvs login >> 55 8:29 cvs checkout rxtx-devel > >Hi Doug > >You want "cvs checkout -r commapi-0-0-1 rxtx-devel" to get RXTX 2.1 >The default branch is rxtx 2.0 which isn't very active right now. > >-- >Trent Jarvi >tjarvi at qbang.org From tjarvi at qbang.org Mon Mar 20 07:25:30 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 20 Mar 2006 07:25:30 -0700 (MST) Subject: [Rxtx] Mac OS X RXTX java installer In-Reply-To: References: <07D0DE29-BA32-4CFE-B036-66BC6423D385@buechse.de> <441AE3E0.2030503@willicon.de> <12531986.1142622114996.JavaMail.dmarkman@mac.com> <441B2674.9010409@willicon.de> <13577405.1142634732776.JavaMail.dmarkman@mac.com> <441B4182.8010407@willicon.de> <92CD0D6C-5BE8-426E-A46D-99452059FF49@mac.com> <441BBB2D.8030305@willicon.de> <441C4088.5090905@willicon.de> <64BC1E23-FDDE-4CE6-8863-CFC881CBC224@mac.com> Message-ID: On Mon, 20 Mar 2006, Dr. Douglas Lyon wrote: > Hi Trent, > Thanks for the info on the CVS checkout procedure. > I did that and am still not sure where the installer is. Hi Doug It does look like it was not cvs committed. There is no rxtx-devel/contrib/MacOSX directory in there at the moment. It was mentioned that it was put under contrib. -- Trent Jarvi tjarvi at qbang.org From dmarkman at mac.com Mon Mar 20 07:29:56 2006 From: dmarkman at mac.com (Dmitry Markman) Date: Mon, 20 Mar 2006 09:29:56 -0500 Subject: [Rxtx] Mac OS X RXTX java installer In-Reply-To: References: <07D0DE29-BA32-4CFE-B036-66BC6423D385@buechse.de> <441AE3E0.2030503@willicon.de> <12531986.1142622114996.JavaMail.dmarkman@mac.com> <441B2674.9010409@willicon.de> <13577405.1142634732776.JavaMail.dmarkman@mac.com> <441B4182.8010407@willicon.de> <92CD0D6C-5BE8-426E-A46D-99452059FF49@mac.com> <441BBB2D.8030305@willicon.de> <441C4088.5090905@willicon.de> <64BC1E23-FDDE-4CE6-8863-CFC881CBC224@mac.com> Message-ID: <6054EB4E-F7E0-4A9C-BDDA-D582D6D8826F@mac.com> you can find it in the rxtx-devel/contrib folder On Mar 20, 2006, at 9:05 AM, Dr. Douglas Lyon wrote: > Hi Trent, > Thanks for the info on the CVS checkout procedure. > I did that and am still not sure where the installer is. > Here is what I have: > cd MACOSX_IDE/ > p4.docjava.com{lyon}121: ls > CVS/ ForPackageMaker/ PB/ > p4.docjava.com{lyon}122: find . | more > . > ./ForPackageMaker > ./ForPackageMaker/RXTX.pkg.sit.hqx > ./ForPackageMaker/Resources > ./ForPackageMaker/Resources/ReadMe.rtf > ./ForPackageMaker/Resources/Welcome.rtf > ./ForPackageMaker/Resources/CVS > ./ForPackageMaker/Resources/CVS/Entries > ./ForPackageMaker/Resources/CVS/Repository > ./ForPackageMaker/Resources/CVS/Tag > ./ForPackageMaker/Resources/CVS/Root > ./ForPackageMaker/Resources/preinstall > ./ForPackageMaker/Resources/License.rtf > ./ForPackageMaker/Resources/preupgrade > ./ForPackageMaker/RXTX.pmsp > ./ForPackageMaker/CVS > ./ForPackageMaker/CVS/Entries > ./ForPackageMaker/CVS/Repository > ./ForPackageMaker/CVS/Entries.Log > ./ForPackageMaker/CVS/Tag > ./ForPackageMaker/CVS/Root > ./ForPackageMaker/RXTX_Tiger.pkg.sitx.hqx > ./ForPackageMaker/RXTX_Jag.pkg.sit.hqx > ./ForPackageMaker/Install > ./ForPackageMaker/Install/CVS > ./ForPackageMaker/Install/CVS/Entries > ./ForPackageMaker/Install/CVS/Repository > ./ForPackageMaker/Install/CVS/Tag > ./ForPackageMaker/Install/CVS/Root > ./ForPackageMaker/Install/Library > ./ForPackageMaker/Install/Library/CVS > ./ForPackageMaker/Install/Library/CVS/Entries > ./ForPackageMaker/Install/Library/CVS/Repository > ./ForPackageMaker/Install/Library/CVS/Tag > ./ForPackageMaker/Install/Library/CVS/Root > ./ForPackageMaker/Install/Library/Java > ./ForPackageMaker/Install/Library/Java/Extensions > ./ForPackageMaker/Install/Library/Java/Extensions/RXTXcomm.jar > ./ForPackageMaker/Install/Library/Java/Extensions/CVS > ./ForPackageMaker/Install/Library/Java/Extensions/CVS/Entries > ./ForPackageMaker/Install/Library/Java/Extensions/CVS/Repository > ./ForPackageMaker/Install/Library/Java/Extensions/CVS/Tag > ./ForPackageMaker/Install/Library/Java/Extensions/CVS/Root > ./ForPackageMaker/Install/Library/Java/Extensions/librxtxSerial.jnilib > ./ForPackageMaker/Install/Library/Java/CVS > ./ForPackageMaker/Install/Library/Java/CVS/Entries > ./ForPackageMaker/Install/Library/Java/CVS/Repository > ./ForPackageMaker/Install/Library/Java/CVS/Entries.Log > ./ForPackageMaker/Install/Library/Java/CVS/Tag > ./ForPackageMaker/Install/Library/Java/CVS/Root > ./ForPackageMaker/RXTX_Tiger.pmproj.sitx.hqx > ./CVS > ./CVS/Entries > ./CVS/Repository > ./CVS/Entries.Log > ./CVS/Tag > ./CVS/Root > ./PB > ./PB/LibSerialUniversal.xcodeproj.sitx.hqx > ./PB/CVS > ./PB/CVS/Entries > ./PB/CVS/Repository > ./PB/CVS/Entries.Log > ./PB/CVS/Tag > ./PB/CVS/Root > ./PB/LibSerial.pbproj.sit.hqx > ./PB/startpoint.c > ./PB/config.h > > What is the procedure to run this installer? > Do we need a README in: > /rxtx-devel/MACOSX_IDE > Here is what we have: > CVS/ ForPackageMaker/ PB/ > > > Thanks! > - DL > >> On Mon, 20 Mar 2006, Dr. Douglas Lyon wrote: >> >>> Hi Dimitry, >>> This sounds like great work. Just a couple of questions; >>> After the check out of the CVS files, using: >>> setenv CVSROOT :pserver:anonymous at cvs.milestonesolutions.com:/usr/ >>> local/cvsroot >>> 53 8:28 setenv PASSWORD mousy >>> 54 8:29 cvs login >>> 55 8:29 cvs checkout rxtx-devel >> >> Hi Doug >> >> You want "cvs checkout -r commapi-0-0-1 rxtx-devel" to get RXTX 2.1 >> The default branch is rxtx 2.0 which isn't very active right now. >> >> -- >> Trent Jarvi >> tjarvi at qbang.org > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx Dmitry Markman From mikehall at spacestar.net Mon Mar 20 05:25:25 2006 From: mikehall at spacestar.net (Michael Hall) Date: Mon, 20 Mar 2006 06:25:25 -0600 Subject: [Rxtx] Re: Mac OS X RXTX java installer In-Reply-To: <64BC1E23-FDDE-4CE6-8863-CFC881CBC224@mac.com> References: <07D0DE29-BA32-4CFE-B036-66BC6423D385@buechse.de> <441AE3E0.2030503@willicon.de> <12531986.1142622114996.JavaMail.dmarkman@mac.com> <441B2674.9010409@willicon.de> <13577405.1142634732776.JavaMail.dmarkman@mac.com> <441B4182.8010407@willicon.de> <92CD0D6C-5BE8-426E-A46D-99452059FF49@mac.com> <441BBB2D.8030305@willicon.de> <441C4088.5090905@willicon.de> <64BC1E23-FDDE-4CE6-8863-CFC881CBC224@mac.com> Message-ID: <247EB61F-5CD1-4132-89A2-FC105B6CF9A5@spacestar.net> On Mar 20, 2006, at 1:20 AM, Dmitry Markman wrote: > > Michael Hall (mikehall at spacestar dot net) had a suggestion to > make implementation of the jaas LoginModule > based on Greg's AuthKit > (his modification of the Greg's AuthKit could be found at http:// > www.spacestar.net/users/mikehall/authkit.dmg) > but Michael's AuthKitLoginModule does only half a job: > it does authenticate > but it can not run any external unix process in privileged mode (at > least I wasn't able to do so) If you got it working directly with Greg's the point is moot. But to clarify it anyhow. The login module does not allow you to do anything anything privileged on return as was explained by Greg. You need to work with a separate privileged process using the execPrivileged method of his API. I assume you did something similar although I haven't looked at how you are using it yet. I allowed instead for a action to be performed at the same time you login/authenticate,this... System.setProperty("authkit.action","/usr/bin/id"); just before this... lc.login(); To clarify, safely ignored as you are already complete. Mike Hall mikehall at spacestar dot net http://www.spacestar.net/users/mikehall http://sourceforge.net/projects/macnative -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2427 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20060320/f6e18202/smime-0007.bin From dmarkman at mac.com Mon Mar 20 07:36:47 2006 From: dmarkman at mac.com (Dmitry Markman) Date: Mon, 20 Mar 2006 09:36:47 -0500 Subject: [Rxtx] Re: Mac OS X RXTX java installer In-Reply-To: <247EB61F-5CD1-4132-89A2-FC105B6CF9A5@spacestar.net> References: <07D0DE29-BA32-4CFE-B036-66BC6423D385@buechse.de> <441AE3E0.2030503@willicon.de> <12531986.1142622114996.JavaMail.dmarkman@mac.com> <441B2674.9010409@willicon.de> <13577405.1142634732776.JavaMail.dmarkman@mac.com> <441B4182.8010407@willicon.de> <92CD0D6C-5BE8-426E-A46D-99452059FF49@mac.com> <441BBB2D.8030305@willicon.de> <441C4088.5090905@willicon.de> <64BC1E23-FDDE-4CE6-8863-CFC881CBC224@mac.com> <247EB61F-5CD1-4132-89A2-FC105B6CF9A5@spacestar.net> Message-ID: Hi, Michael all I have to do is to run some shell script I tried to use your action mechanism and it worked great so I just System.setProperty ("authkit.action","" ) and after that I even don't need to run anything like subject.doAs.... but after few thoughts I choose to use plain Greg's approach, because in that case I don't have to deal with various java's configurations files and therefore to use 2-3 -D parameters in the java command line especially it's useful for java web start (it's so fragile :-( ) thanks for the great job On Mar 20, 2006, at 7:25 AM, Michael Hall wrote: > > On Mar 20, 2006, at 1:20 AM, Dmitry Markman wrote: >> >> Michael Hall (mikehall at spacestar dot net) had a suggestion to >> make implementation of the jaas LoginModule >> based on Greg's AuthKit >> (his modification of the Greg's AuthKit could be found at http:// >> www.spacestar.net/users/mikehall/authkit.dmg) >> but Michael's AuthKitLoginModule does only half a job: >> it does authenticate >> but it can not run any external unix process in privileged mode >> (at least I wasn't able to do so) > > If you got it working directly with Greg's the point is moot. > > But to clarify it anyhow. > The login module does not allow you to do anything anything > privileged on return as was explained by Greg. You need to work > with a separate privileged process using the execPrivileged method > of his API. I assume you did something similar although I haven't > looked at how you are using it yet. > I allowed instead for a action to be performed at the same time you > login/authenticate,this... > System.setProperty("authkit.action","/usr/bin/id"); > just before this... > lc.login(); > To clarify, safely ignored as you are already complete. > > Mike Hall mikehall at spacestar dot net > http://www.spacestar.net/users/mikehall > http://sourceforge.net/projects/macnative > > > Dmitry Markman From dmarkman at mac.com Mon Mar 20 07:44:45 2006 From: dmarkman at mac.com (Dmitry Markman) Date: Mon, 20 Mar 2006 09:44:45 -0500 Subject: [Rxtx] Mac OS X RXTX java installer In-Reply-To: References: <07D0DE29-BA32-4CFE-B036-66BC6423D385@buechse.de> <441AE3E0.2030503@willicon.de> <12531986.1142622114996.JavaMail.dmarkman@mac.com> <441B2674.9010409@willicon.de> <13577405.1142634732776.JavaMail.dmarkman@mac.com> <441B4182.8010407@willicon.de> <92CD0D6C-5BE8-426E-A46D-99452059FF49@mac.com> <441BBB2D.8030305@willicon.de> <441C4088.5090905@willicon.de> <64BC1E23-FDDE-4CE6-8863-CFC881CBC224@mac.com> Message-ID: it's in the commapi-0-0-1 branch I tested it right now: cvs co -r commapi-0-0-1 rxtx-devel and I got everything On Mar 20, 2006, at 9:25 AM, Trent Jarvi wrote: > On Mon, 20 Mar 2006, Dr. Douglas Lyon wrote: > >> Hi Trent, >> Thanks for the info on the CVS checkout procedure. >> I did that and am still not sure where the installer is. > > Hi Doug > > It does look like it was not cvs committed. There is no rxtx-devel/ > contrib/MacOSX directory in there at the moment. It was mentioned > that it was put under contrib. > > -- > Trent Jarvi > tjarvi at qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx Dmitry Markman From tjarvi at qbang.org Mon Mar 20 07:52:57 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 20 Mar 2006 07:52:57 -0700 (MST) Subject: [Rxtx] Mac OS X RXTX java installer In-Reply-To: References: <07D0DE29-BA32-4CFE-B036-66BC6423D385@buechse.de> <441AE3E0.2030503@willicon.de> <12531986.1142622114996.JavaMail.dmarkman@mac.com> <441B2674.9010409@willicon.de> <13577405.1142634732776.JavaMail.dmarkman@mac.com> <441B4182.8010407@willicon.de> <92CD0D6C-5BE8-426E-A46D-99452059FF49@mac.com> <441BBB2D.8030305@willicon.de> <441C4088.5090905@willicon.de> <64BC1E23-FDDE-4CE6-8863-CFC881CBC224@mac.com> Message-ID: On Mon, 20 Mar 2006, Dmitry Markman wrote: > it's in the commapi-0-0-1 branch > > I tested it right now: > cvs co -r commapi-0-0-1 rxtx-devel > > and I got everything > A fresh checkout worked. Here is a copy of the tree (just the installer bits) ftp://ftp.qbang.org/pub/rxtx/MacOSX-installer.zip -- Trent Jarvi tjarvi at qbang.org From lyon at docjava.com Mon Mar 20 08:08:26 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Mon, 20 Mar 2006 10:08:26 -0500 Subject: [Rxtx] Mac OS X RXTX java installer In-Reply-To: References: <07D0DE29-BA32-4CFE-B036-66BC6423D385@buechse.de> <441AE3E0.2030503@willicon.de> <12531986.1142622114996.JavaMail.dmarkman@mac.com> <441B2674.9010409@willicon.de> <13577405.1142634732776.JavaMail.dmarkman@mac.com> <441B4182.8010407@willicon.de> <92CD0D6C-5BE8-426E-A46D-99452059FF49@mac.com> <441BBB2D.8030305@willicon.de> <441C4088.5090905@willicon.de> <64BC1E23-FDDE-4CE6-8863-CFC881CBC224@mac.com> Message-ID: Hi All, Is the Auth package able to work properly on non Mac OS's? It was not clear from the doc or download. Thanks! - Doug From dmarkman at mac.com Mon Mar 20 08:15:22 2006 From: dmarkman at mac.com (Dmitry Markman) Date: Mon, 20 Mar 2006 10:15:22 -0500 Subject: [Rxtx] Mac OS X RXTX java installer In-Reply-To: References: <07D0DE29-BA32-4CFE-B036-66BC6423D385@buechse.de> <441AE3E0.2030503@willicon.de> <12531986.1142622114996.JavaMail.dmarkman@mac.com> <441B2674.9010409@willicon.de> <13577405.1142634732776.JavaMail.dmarkman@mac.com> <441B4182.8010407@willicon.de> <92CD0D6C-5BE8-426E-A46D-99452059FF49@mac.com> <441BBB2D.8030305@willicon.de> <441C4088.5090905@willicon.de> <64BC1E23-FDDE-4CE6-8863-CFC881CBC224@mac.com> Message-ID: <217312D8-CCCA-4859-ABA6-32DF1CC817B9@mac.com> thanks Trent, for putting it on ftp server On Mar 20, 2006, at 9:52 AM, Trent Jarvi wrote: > A fresh checkout worked. Here is a copy of the tree (just the > installer bits) > > ftp://ftp.qbang.org/pub/rxtx/MacOSX-installer.zip > Dmitry Markman From dmarkman at mac.com Mon Mar 20 09:14:03 2006 From: dmarkman at mac.com (Dmitry Markman) Date: Mon, 20 Mar 2006 11:14:03 -0500 Subject: [Rxtx] Mac OS X RXTX java installer In-Reply-To: References: <07D0DE29-BA32-4CFE-B036-66BC6423D385@buechse.de> <441AE3E0.2030503@willicon.de> <12531986.1142622114996.JavaMail.dmarkman@mac.com> <441B2674.9010409@willicon.de> <13577405.1142634732776.JavaMail.dmarkman@mac.com> <441B4182.8010407@willicon.de> <92CD0D6C-5BE8-426E-A46D-99452059FF49@mac.com> <441BBB2D.8030305@willicon.de> <441C4088.5090905@willicon.de> <64BC1E23-FDDE-4CE6-8863-CFC881CBC224@mac.com> Message-ID: <4DEBA6F0-DA45-4E84-823E-1F1AC48BDCCC@mac.com> no it will work only on mac os x however it's harmless to run it on other platform if you want to use it for other platform you have to do the following (I'll do it for linux) 1. modify RXTXInstaller class method public static RXTXInstaller getInstance() public static RXTXInstaller getInstance() { String osName = System.getProperty("os.name").toLowerCase(); if(osName.startsWith("mac")){ return new gnu.io.installer.macosx.MACOSXRXTXInstaller(); } else if(osName.startsWith("windows")){ return new gnu.io.installer.windows.WindowsRXTXInstaller(); }else if(osName.startsWith("linux")){ return new gnu.io.installer.linux.LinuxRXTXInstaller(); } return null; } 2. create folder gnu/io/installer/linux/ 3. create class Linux386RXTXInstaller package gnu.io.installer.linux; import java.io.File; public class Linux386RXTXInstaller extends gnu.io.installer.RXTXInstaller{ public Linux386RXTXInstaller(){ createJarFolder(); createLibFolder(); addJarResource("RXTXcomm.jar","/gnu/io/installer/resources/ linux/jar/RXTXcomm.dat"); addLibResource("librxtxSerial.so","/gnu/io/installer/ resources/linux/lib/librxtxSerial.so"); } protected void createJarFolder(){ String javaHome = System.getProperty("java.home"); char separator = File.separatorChar; jarFolder = new File(javaHome+separator+"lib"+separator+"ext"); } protected void createLibFolder(){ String javaHome = System.getProperty("java.home"); char separator = File.separatorChar; libFolder = new File(javaHome+separator+"bin"); } public void runPreProcess() {} //put here some action you need public void runPostProcess() {} //put here some action you need } 4. create folder /gnu/io/installer/resources/linux/jar and put there linux's version of RXTXcomm.dat (which is renamed RXTXcomm.jar) 5. create folder /gnu/io/installer/resources/linux/lib and put there linux's version of librxtxSerial. so 6. make sure that RXTXInstaller.jar has the following items: /gnu/io/installer/resources/linux/jar/RXTXcomm.jar /gnu/io/installer/resources/linux/lib/librxtxSerial.so 7. modify file installer.pref: jar file RXTXInstaller.jar must have the following item /gnu/io/installer/installer.pref that's basically it for windows you have to do the similar things: just replace linux to windows and librxtxSerial.so to rxtxSerial.dll and create appropriate gnu.io.installer.windows.WindowsRXTXInstaller class package gnu.io.installer.windows; import java.io.File; public class WindowsRXTXInstaller extends gnu.io.installer.RXTXInstaller{ public WindowsRXTXInstaller(){ createJarFolder(); createLibFolder(); addJarResource("RXTXcomm.jar","/gnu/io/installer/resources/ windows/jar/RXTXcomm.dat"); addLibResource("librxtxSerial.so","/gnu/io/installer/ resources/windows/lib/rxtxSerial.dll"); } protected void createJarFolder(){ String javaHome = System.getProperty("java.home"); char separator = File.separatorChar; jarFolder = new File(javaHome+separator+"lib"+separator+"ext"); } protected void createLibFolder(){ String javaHome = System.getProperty("java.home"); char separator = File.separatorChar; libFolder = new File(javaHome+separator+"bin"); } public void runPreProcess() {} //put here some action you need public void runPostProcess() {} //put here some action you need } installer.pref will look like On Mar 20, 2006, at 10:08 AM, Dr. Douglas Lyon wrote: > Hi All, > Is the Auth package able to work properly on > non Mac OS's? > It was not clear from the doc or download. > > Thanks! > - Doug > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx Dmitry Markman From joachim at buechse.de Mon Mar 20 10:49:06 2006 From: joachim at buechse.de (Joachim Buechse) Date: Mon, 20 Mar 2006 18:49:06 +0100 Subject: [Rxtx] BUG: Lock file stays even if port opening fails Message-ID: This was only tested on MacOSX but looking at the code, it should be true for all systems that use lock_uucp. I am opening a port which can not be opened (dialup port of a telephone paired via bluetooth but currently not reachable). The lock file is created and stays arround, even though the port open failed. After looking a bit through the code (of 2.17), I really wonder if it wouldn't be a good idea to make the "locking" an explicit operation called from the java code. This would certainly simplify the generation of meaningfull exceptions (and java based debugging). Maybe even the handling of "preopened" ports should be in the Java part of the lib (again for java based debugging puposes). That beeing said, I have no idea if this would be possible for the 2.07 implementation. Regards, Joachim From tjarvi at qbang.org Mon Mar 20 11:24:22 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 20 Mar 2006 11:24:22 -0700 (MST) Subject: [Rxtx] BUG: Lock file stays even if port opening fails In-Reply-To: References: Message-ID: On Mon, 20 Mar 2006, Joachim Buechse wrote: > This was only tested on MacOSX but looking at the code, it should be true > for all systems that use lock_uucp. > > I am opening a port which can not be opened (dialup port of a telephone > paired via bluetooth but currently not reachable). The lock file is > created and stays arround, even though the port open failed. > > > After looking a bit through the code (of 2.17), I really wonder if it > wouldn't be a good idea to make the "locking" an explicit operation > called from the java code. This would certainly simplify the generation > of meaningfull exceptions (and java based debugging). > Maybe even the handling of "preopened" ports should be in the Java part > of the lib (again for java based debugging puposes). That beeing said, I > have no idea if this would be possible for the 2.07 implementation. > > Regards, Hi Joachim It should be possible in the 2.0-7 implementation too. The calls to RXTXPort.java would not change. We would just do more there Moving more of that logic into Java would be better as many people don't like to look at C code. There is a liblockdev on most Linux distros that can do most of the C code and would be easier to use. The problem is embeded devices will not have that library. The preopened port code has not been really tested. That was a last minute request in a product cycle. I expect it will be tested this year though. As I recall, some devices really do not like CD raising on open. The preopened ports then allow people to mess around in java without power cycling the devices or losing data. -- Trent Jarvi tjarvi at qbang.org From joachim at buechse.de Mon Mar 20 12:01:08 2006 From: joachim at buechse.de (Joachim Buechse) Date: Mon, 20 Mar 2006 20:01:08 +0100 Subject: [Rxtx] BUG: Lock file stays even if port opening fails In-Reply-To: References: Message-ID: Hi Trent, What is your general feeling about moving code to Java? The last days I have been reading quite a bit of the code and there are several things, that might not work as expected. I'll give you two examples from is_device_locked: if LOCKDIR == /var/spool/locks the directory /var/spool/lock will not be checked. LOCKDIR is not checked for lockfiles with unexpected pefixes While these things have probably never been discovered in production, they are still possibly incorrect implementations. If it was Java code, I would write some unit tests producing the errors that could later be corrected. PS: One could imagine to actually implement the whole lockfile handling in Java using some native routines to get the values required (pid, st_dev, st_rdev, ...). On 20.03.2006, at 19:24, Trent Jarvi wrote: > On Mon, 20 Mar 2006, Joachim Buechse wrote: > >> This was only tested on MacOSX but looking at the code, it should >> be true for all systems that use lock_uucp. >> >> I am opening a port which can not be opened (dialup port of a >> telephone paired via bluetooth but currently not reachable). The >> lock file is created and stays arround, even though the port open >> failed. >> >> >> After looking a bit through the code (of 2.17), I really wonder if >> it wouldn't be a good idea to make the "locking" an explicit >> operation called from the java code. This would certainly simplify >> the generation of meaningfull exceptions (and java based debugging). >> Maybe even the handling of "preopened" ports should be in the Java >> part of the lib (again for java based debugging puposes). That >> beeing said, I have no idea if this would be possible for the 2.07 >> implementation. >> >> Regards, > > Hi Joachim > > It should be possible in the 2.0-7 implementation too. The calls > to RXTXPort.java would not change. We would just do more there > Moving more of that logic into Java would be better as many people > don't like to look at C code. There is a liblockdev on most Linux > distros that can do most of the C code and would be easier to use. > The problem is embeded devices will not have that library. > > The preopened port code has not been really tested. That was a > last minute request in a product cycle. I expect it will be tested > this year though. As I recall, some devices really do not like CD > raising on open. The preopened ports then allow people to mess > around in java without power cycling the devices or losing data. > > -- > Trent Jarvi > tjarvi at qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Mon Mar 20 12:21:02 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 20 Mar 2006 12:21:02 -0700 (MST) Subject: [Rxtx] BUG: Lock file stays even if port opening fails In-Reply-To: References: Message-ID: On Mon, 20 Mar 2006, Joachim Buechse wrote: > Hi Trent, > > What is your general feeling about moving code to Java? The last days I > have been reading quite a bit of the code and there are several things, > that might not work as expected. > > I'll give you two examples from is_device_locked: > > if LOCKDIR == /var/spool/locks the directory /var/spool/lock will not be > checked. > LOCKDIR is not checked for lockfiles with unexpected pefixes > > While these things have probably never been discovered in production, > they are still possibly incorrect implementations. If it was Java code, I > would write some unit tests producing the errors that could later be > corrected. > > PS: One could imagine to actually implement the whole lockfile handling > in Java using some native routines to get the values required (pid, > st_dev, st_rdev, ...). Hi Joachim I like the idea of moving more of the code into java but there are some things to consider. If you break this into multiple JNI calls, the performance will drop considerably during enumeration of ports. We are looking for 256 ports per dev type vs (16? in Sun's 2.0 and fewer types). Its hard to make assumptions. I've seen virtual ports start at /dev/foo100 for instance. It works out to over 7500 ports on Linux if you enable them all. We already trim that back by default. See Linux-all-ports in RXTXCommDriver.java. There are also native libraries that rxtx can link to. If you move too much into Java, linking to 'standard' libraries with distros will break. "configure --enable-liblock=yes" will not be doable. This is probably a favorable way with RedHat, Debian, Suse and others. Thats the right thing to do if there will be rpms, dpkg, .. For those reasons, I think it still make sense to keep it to a minimal ~3 calls to JNI code that we can use for speed and versatility. lock() isLocked(), unlock() perhaps. When I say speed, its more about avoiding crossing the JNI layer multiple times than java vs C performance. With versatility I think liblock is the right way for most but not all (embeded) linux distros. -- Trent Jarvi tjarvi at qbang.org From joachim at buechse.de Mon Mar 20 12:42:04 2006 From: joachim at buechse.de (Joachim Buechse) Date: Mon, 20 Mar 2006 20:42:04 +0100 Subject: [Rxtx] BUG: Lock file stays even if port opening fails In-Reply-To: References: Message-ID: <82C19FE7-DDCB-45B6-B2C9-7606B66F0124@buechse.de> Ok, what about providing a default implementation in Java? The RXTXCommDriver would call a (native) function useNativeLocking and if it returns true, call the native functions for lock() isLocked (), unlock(), else is would use the Java based default implementation. This could possibly be overriden by a property (again for debugging). Joachim On 20.03.2006, at 20:21, Trent Jarvi wrote: > On Mon, 20 Mar 2006, Joachim Buechse wrote: > >> Hi Trent, >> >> What is your general feeling about moving code to Java? The last >> days I have been reading quite a bit of the code and there are >> several things, that might not work as expected. >> >> I'll give you two examples from is_device_locked: >> >> if LOCKDIR == /var/spool/locks the directory /var/spool/lock will >> not be checked. >> LOCKDIR is not checked for lockfiles with unexpected pefixes >> >> While these things have probably never been discovered in >> production, they are still possibly incorrect implementations. If >> it was Java code, I would write some unit tests producing the >> errors that could later be corrected. >> >> PS: One could imagine to actually implement the whole lockfile >> handling in Java using some native routines to get the values >> required (pid, st_dev, st_rdev, ...). > > Hi Joachim > > I like the idea of moving more of the code into java but there are > some things to consider. > > If you break this into multiple JNI calls, the performance will > drop considerably during enumeration of ports. We are looking for > 256 ports per dev type vs (16? in Sun's 2.0 and fewer types). Its > hard to make assumptions. I've seen virtual ports start at /dev/ > foo100 for instance. > > It works out to over 7500 ports on Linux if you enable them all. > We already trim that back by default. See Linux-all-ports in > RXTXCommDriver.java. > > There are also native libraries that rxtx can link to. If you move > too much into Java, linking to 'standard' libraries with distros > will break. "configure --enable-liblock=yes" will not be doable. > This is probably a favorable way with RedHat, Debian, Suse and > others. Thats the right thing to do if there will be rpms, dpkg, .. > > For those reasons, I think it still make sense to keep it to a > minimal ~3 calls to JNI code that we can use for speed and > versatility. lock() isLocked(), unlock() perhaps. When I say > speed, its more about avoiding crossing the JNI layer multiple > times than java vs C performance. With versatility I think liblock > is the right way for most but not all (embeded) linux distros. > > -- > Trent Jarvi > tjarvi at qbang.org > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Mon Mar 20 12:44:47 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 20 Mar 2006 12:44:47 -0700 (MST) Subject: [Rxtx] BUG: Lock file stays even if port opening fails In-Reply-To: <82C19FE7-DDCB-45B6-B2C9-7606B66F0124@buechse.de> References: <82C19FE7-DDCB-45B6-B2C9-7606B66F0124@buechse.de> Message-ID: On Mon, 20 Mar 2006, Joachim Buechse wrote: > Ok, what about providing a default implementation in Java? > > The RXTXCommDriver would call a (native) function useNativeLocking and if > it returns true, call the native functions for lock() isLocked(), > unlock(), else is would use the Java based default implementation. This > could possibly be overriden by a property (again for debugging). > Hi Joachim That would be OK with me. -- Trent Jarvi tjarvi at qbang.org From dmarkman at mac.com Mon Mar 20 22:27:45 2006 From: dmarkman at mac.com (Dmitry Markman) Date: Tue, 21 Mar 2006 00:27:45 -0500 Subject: [Rxtx] binaries request Message-ID: <42702213-C222-4937-A585-7CFB17E47608@mac.com> Hi can somebody send me latest linux and windows binaries, please? or where I can find them (I didn't find them in the latest tareball) I gave up with my cygwin: something wrong I have no idea what java doesn't understand /cygwin/c syntax after I changed makefile it did java part but after that gcc 3.4.4 started to complain I set buffer length to 999 lines but I didn't get beginning of the story something wrong with my 1.4.2_09/include/jni.h gcc doesn't like it anyway I gave up thanks in advance Dmitry Markman -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060320/f8cbc57c/attachment-0007.html From tjarvi at qbang.org Mon Mar 20 22:36:48 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 20 Mar 2006 22:36:48 -0700 (MST) Subject: [Rxtx] binaries request In-Reply-To: <42702213-C222-4937-A585-7CFB17E47608@mac.com> References: <42702213-C222-4937-A585-7CFB17E47608@mac.com> Message-ID: On Tue, 21 Mar 2006, Dmitry Markman wrote: > Hi > can somebody send me latest linux and windows binaries, please? > > or where I can find them (I didn't find them in the latest tareball) > > I gave up with my cygwin: something wrong I have no idea what > java doesn't understand /cygwin/c syntax > after I changed makefile it did java part > but after that gcc 3.4.4 started to complain > I set buffer length to 999 lines but I didn't get beginning of the story > something wrong with my 1.4.2_09/include/jni.h gcc doesn't like it > anyway I gave up > > thanks in advance > Hi Dmitry The bins are here: ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7-bins-r2.zip Here are the files in the zip you want. Jar: rxtx-2.1-7-bins-r2/RXTXcomm.jar Windows: rxtx-2.1-7-bins-r2/Windows/i368-mingw32/rxtxSerial.dll Linux (x86) rxtx-2.1-7-bins-r2/Linux/i686-unknown-linux-gnu/librxtxSerial.so There are others in there including Parallel port support but those are the main ones for testing. -- Trent Jarvi tjarvi at qbang.org From dmarkman at mac.com Mon Mar 20 23:05:59 2006 From: dmarkman at mac.com (Dmitry Markman) Date: Tue, 21 Mar 2006 01:05:59 -0500 Subject: [Rxtx] binaries request In-Reply-To: References: <42702213-C222-4937-A585-7CFB17E47608@mac.com> Message-ID: thank you very much but windows's readme says: rxtxSerial.dll had to be recomopiled to link in missing native methods. should I ignore it? or what? thanks again also I understand that I should use mingw not cygwin I'll try to install mingw On Mar 21, 2006, at 12:36 AM, Trent Jarvi wrote: > On Tue, 21 Mar 2006, Dmitry Markman wrote: > >> Hi >> can somebody send me latest linux and windows binaries, please? >> >> or where I can find them (I didn't find them in the latest tareball) >> >> I gave up with my cygwin: something wrong I have no idea what >> java doesn't understand /cygwin/c syntax >> after I changed makefile it did java part >> but after that gcc 3.4.4 started to complain >> I set buffer length to 999 lines but I didn't get beginning of the >> story >> something wrong with my 1.4.2_09/include/jni.h gcc doesn't like it >> anyway I gave up >> >> thanks in advance >> > > Hi Dmitry > > The bins are here: > > ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7-bins-r2.zip > > Here are the files in the zip you want. > > Jar: > > rxtx-2.1-7-bins-r2/RXTXcomm.jar > > Windows: > > rxtx-2.1-7-bins-r2/Windows/i368-mingw32/rxtxSerial.dll > > Linux (x86) > > rxtx-2.1-7-bins-r2/Linux/i686-unknown-linux-gnu/librxtxSerial.so > > There are others in there including Parallel port support but those > are the main ones for testing. > > -- > Trent Jarvi > tjarvi at qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx Dmitry Markman From tjarvi at qbang.org Mon Mar 20 23:20:33 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 20 Mar 2006 23:20:33 -0700 (MST) Subject: [Rxtx] binaries request In-Reply-To: References: <42702213-C222-4937-A585-7CFB17E47608@mac.com> Message-ID: On Tue, 21 Mar 2006, Dmitry Markman wrote: > thank you very much > > but windows's readme says: > rxtxSerial.dll had to be recomopiled to link in missing native methods. > > should I ignore it? or what? > Hi Dmitry That dll should be OK. r2 is the recompile linked to the missing native method. The readme explains why it was recompiled; fuser.o was not linked into the dll in the first release. -- Trent Jarvi tjarvi at qbang.org From ariantristan at yahoo.com Mon Mar 20 23:55:24 2006 From: ariantristan at yahoo.com (Lambok Sianturi) Date: Mon, 20 Mar 2006 22:55:24 -0800 (PST) Subject: [Rxtx] jvm issue Message-ID: <20060321065524.94779.qmail@web50701.mail.yahoo.com> Hi All, This is my first time to join RxTx mailing list. I thank you all for allowing others to sign in in requests help. I use the latest RxTx lib in Fedora 3 with java version 1.4.2_09 b05. And I got this error: # # An unexpected error has been detected by HotSpot Virtual Machine: # # SIGSEGV (0xb) at pc=0x00bf27f3, pid=2633, tid=3086112448 # # Java VM: Java HotSpot(TM) Client VM (1.4.2_09-b05 mixed mode) # Problematic frame: # C [ld-linux.so.2+0xa7f3] # # An error report file with more information is saved as hs_err_pid2633.log # # If you would like to submit a bug report, please visit: # http://java.sun.com/webapps/bugreport/crash.jsp # ./run.sh: line 3: 2633 Aborted /usr/local/java/bin/java -Djava.library.path=/usr/local/java/jre/lib/ -Djsmsengine.debug=true -classpath jsmsengine.jar:smsgateway.jar:classes12.jar:RXTXcomm.jar:. com.api.sms.SMSServer What is the jvm depedency for the latest library? Can I use 1.4.2_09 b05? Thanks in advance. Arian --------------------------------- Yahoo! Mail Use Photomail to share photos without annoying attachments. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060320/83d58dd7/attachment-0007.html From f.frumento at ngi.it Tue Mar 21 00:21:47 2006 From: f.frumento at ngi.it (Fabio Frumento) Date: Tue, 21 Mar 2006 08:21:47 +0100 Subject: [Rxtx] Javadoc on the go Message-ID: <441FA98B.9050701@ngi.it> Hi Trent, sorry for the big delay but my job is running wild, i was out for some time but now i'm back and ready to continue the javadoc for Rxtx. Did you used the last javadoc patch i sent you ? let me know if i have to send it to you again or not. regards Fabio From lyon at docjava.com Tue Mar 21 00:51:18 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Tue, 21 Mar 2006 02:51:18 -0500 Subject: [Rxtx] lock files Message-ID: Hi All, You know, if the use of lock files were under Java control (rather than a build-time decision), it might enable a more unified binary distro. It might also facilitate quick prototyping of non-lock file approaches to resolving serial port contention issues (i.e., mac-like approaches vs. linux approaches, etc.). I realize that this is a radical overhaul of the lock file policy issue. Also, it may harm performance. On the other hand, our benchmarks on JNI overhead for modern processors indicate performance impact should be minimal. Perhaps it is more of an issue with the toybox systems. Suppose there were a class with a reasonable default...someone might write: SerialPortLockPolicy.setPolicy(SerialPortLockPolicy.UNIX_LOCK_FILE); SerialPortLockPolicy.setPolicy(SerialPortLockPolicy.NO_LOCK_CHECKING); SerialPortLockPolicy.setPolicy(SerialPortLockPolicy.MAC_STYLE); Thus, we could have a run-time reconfiguration of the serial port lock policy. A special NO_LOCK version of the binary would no longer be required. Any thoughts on this? Thanks! - Doug From joachim at buechse.de Tue Mar 21 03:09:09 2006 From: joachim at buechse.de (Joachim Buechse) Date: Tue, 21 Mar 2006 11:09:09 +0100 Subject: [Rxtx] lock files In-Reply-To: References: Message-ID: <8E12916A-1B9A-4FF2-B684-E2D1C794221B@buechse.de> This is pretty much what I thought about when I suggested, that the default behaviour could be overwritten with a property. I am very much in favor of this approach. In particular this allows much easier debugging for PC based java developers. I think big parts of the Java (and maybe some parts of the C code) could use a bit of a structural workover (unit tests, javadoc, synchronization, etc). Maybe there should be a CVS branch for this experimental version. I'd be happy to contribute a first workover for some of the Java code. Designing for testability and implementing a good bunch of unit tests has been a strategy that worked quite well in the Java projects I lead. And it ultimately allows more liberal change permission. Regards, Joachim On 21.03.2006, at 08:51, Dr. Douglas Lyon wrote: > Hi All, > You know, if the use of lock files were > under Java control (rather than a build-time decision), > it might enable a more unified binary distro. It might also > facilitate quick prototyping of non-lock file approaches > to resolving serial port contention issues (i.e., mac-like > approaches vs. linux approaches, etc.). > > I realize that this is a radical overhaul of the lock file policy > issue. Also, it may harm performance. On the other hand, > our benchmarks on JNI overhead for modern processors indicate > performance impact should be minimal. Perhaps it is more of > an issue with the toybox systems. > > Suppose there were a class with a reasonable default...someone > might write: > SerialPortLockPolicy.setPolicy(SerialPortLockPolicy.UNIX_LOCK_FILE); > SerialPortLockPolicy.setPolicy(SerialPortLockPolicy.NO_LOCK_CHECKING); > SerialPortLockPolicy.setPolicy(SerialPortLockPolicy.MAC_STYLE); > > Thus, we could have a run-time reconfiguration of the serial port lock > policy. A special NO_LOCK version of the binary would no longer > be required. > > Any thoughts on this? > > Thanks! > - Doug > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From joachim at buechse.de Tue Mar 21 06:23:08 2006 From: joachim at buechse.de (Joachim Buechse) Date: Tue, 21 Mar 2006 14:23:08 +0100 Subject: [Rxtx] PATCH: use of ioctl(fd, TIOCEXCL) instead of lockfiles Message-ID: <923AE774-EEA2-4911-92D8-32BB27802C8B@buechse.de> Here is the patch for the ioctl(fd, TIOCEXCL). I have verified this only for OSX 10.4.5, hence it is only defined for APPLE. However, it should work at least for Solaris as well. If a process has requested TIOEXCL further open calls by other user processes will fail. The patch also disables uucp style locking for APPLE. Obviously this is discussable. I think it is the way to go, as it eliminates creating the lock directory which doesnt exist on the standard installation and it eliminates messing with the system group definitions (adding users to group uucp). Regarding the possibility of root processes opening a device which is locked - I consider this a feature not a potential problem. It is highly unlikely, that somebody is crazy enough to run a JavaVM as root (unless he has no other means of getting a restricted IP port opened, ie doesnt understand ipfw). Anyway, even if the process runs as root, it fails when calling ioctl(fd, TIOCEXCL). It could however still open the port to listen for RING events. I.e. a fax server which needs to see incoming calls but otherwise doesnt want to block the port. So the only case where the proposed mechanism fails is, if an incorrectly implemented process running as root conflicts with a user process. I think this can be accepted. Regards, Joachim PS: If this patch is generally accepted, the installer and Mac doku should obviously be changed as well. Index: SerialImp.c =================================================================== RCS file: /usr/local/cvsroot/rxtx-devel/src/SerialImp.c,v retrieving revision 1.46.2.187 diff -u -r1.46.2.187 SerialImp.c --- SerialImp.c 29 Jan 2006 22:19:04 -0000 1.46.2.187 +++ SerialImp.c 21 Mar 2006 12:59:16 -0000 @@ -656,6 +656,25 @@ fd=OPEN (filename, O_RDWR | O_NOCTTY | O_NONBLOCK ); } while (fd < 0 && errno==EINTR); +#ifdef OPEN_EXCL + // Note that open() follows POSIX semantics: multiple open() calls to + // the same file will succeed unless the TIOCEXCL ioctl is issued. + // This will prevent additional opens except by root-owned processes. + // See tty(4) ("man 4 tty") and ioctl(2) ("man 2 ioctl") for details. + + if (fd >= 0 && (ioctl(fd, TIOCEXCL) == -1)) + { + sprintf( message, "open: exclusive access denied for % s\n", + filename ); + report( message ); + report_error( message ); + + close(fd); + goto fail; + } +#endif /* OPEN_EXCL */ + + if( configure_port( fd ) ) goto fail; (*env)->ReleaseStringUTFChars( env, jstr, filename ); sprintf( message, "open: fd returned is %i\n", fd ); Index: SerialImp.h =================================================================== RCS file: /usr/local/cvsroot/rxtx-devel/src/SerialImp.h,v retrieving revision 1.11.2.49 diff -u -r1.11.2.49 SerialImp.h --- SerialImp.h 5 Jul 2005 17:47:21 -0000 1.11.2.49 +++ SerialImp.h 21 Mar 2006 12:59:17 -0000 @@ -135,7 +135,8 @@ /*# define LOCKDIR "/var/spool/uucp"*/ # define LOCKDIR "/var/lock" # define LOCKFILEPREFIX "LK." -# define UUCP +/*# define UUCP*/ +# define OPEN_EXCL #endif /* __APPLE__ */ #if defined(__NetBSD__) # define DEVICEDIR "/dev/" From tjarvi at qbang.org Tue Mar 21 10:26:08 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 21 Mar 2006 10:26:08 -0700 (MST) Subject: [Rxtx] Javadoc on the go In-Reply-To: <441FA98B.9050701@ngi.it> References: <441FA98B.9050701@ngi.it> Message-ID: On Tue, 21 Mar 2006, Fabio Frumento wrote: > Hi Trent, > > sorry for the big delay but my job is running wild, i was out for some > time but now i'm back and ready to continue the javadoc for Rxtx. > > Did you used the last javadoc patch i sent you ? let me know if i have to > send it to you again or not. > > regards > > Fabio Hi Fabio The patch is in the rxtx mail-list archives. It will be going in soon. I did not see a time critical portion. I'll probably be going through the list since the last batch of patches this weekend and putting them into CVS. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Tue Mar 21 10:57:18 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 21 Mar 2006 10:57:18 -0700 (MST) Subject: [Rxtx] jvm issue In-Reply-To: <20060321065524.94779.qmail@web50701.mail.yahoo.com> References: <20060321065524.94779.qmail@web50701.mail.yahoo.com> Message-ID: On Mon, 20 Mar 2006, Lambok Sianturi wrote: > Hi All, > This is my first time to join RxTx mailing list. I thank you all for allowing others to sign in in requests help. > I use the latest RxTx lib in Fedora 3 with java version 1.4.2_09 b05. And I got this error: > > # > # An unexpected error has been detected by HotSpot Virtual Machine: > # > # SIGSEGV (0xb) at pc=0x00bf27f3, pid=2633, tid=3086112448 > # > # Java VM: Java HotSpot(TM) Client VM (1.4.2_09-b05 mixed mode) > # Problematic frame: > # C [ld-linux.so.2+0xa7f3] A native library loading error? What happens if you recompile rxtx on your system and install that? This sounds like an ABI problem? rxtx 2.1-7 was compiled with a gcc 2.96 toolchain as I recall. The hope is newer system will be backwards compatible. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Tue Mar 21 11:05:29 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 21 Mar 2006 11:05:29 -0700 (MST) Subject: [Rxtx] PATCH: use of ioctl(fd, TIOCEXCL) instead of lockfiles In-Reply-To: <923AE774-EEA2-4911-92D8-32BB27802C8B@buechse.de> References: <923AE774-EEA2-4911-92D8-32BB27802C8B@buechse.de> Message-ID: On Tue, 21 Mar 2006, Joachim Buechse wrote: > Here is the patch for the ioctl(fd, TIOCEXCL). I have verified this only > for OSX 10.4.5, hence it is only defined for APPLE. However, it should > work at least for Solaris as well. > > If a process has requested TIOEXCL further open calls by other user > processes will fail. > > The patch also disables uucp style locking for APPLE. Obviously this is > discussable. I think it is the way to go, as it eliminates creating the > lock directory which doesnt exist on the standard installation and it > eliminates messing with the system group definitions (adding users to > group uucp). > > Regarding the possibility of root processes opening a device which is > locked - I consider this a feature not a potential problem. It is highly > unlikely, that somebody is crazy enough to run a JavaVM as root (unless > he has no other means of getting a restricted IP port opened, ie doesnt > understand ipfw). Anyway, even if the process runs as root, it fails when > calling ioctl(fd, TIOCEXCL). It could however still open the port to > listen for RING events. I.e. a fax server which needs to see incoming > calls but otherwise doesnt want to block the port. So the only case where > the proposed mechanism fails is, if an incorrectly implemented process > running as root conflicts with a user process. I think this can be > accepted. > > Regards, > Joachim > > PS: If this patch is generally accepted, the installer and Mac doku > should obviously be changed as well. > > > Index: SerialImp.c > =================================================================== > RCS file: /usr/local/cvsroot/rxtx-devel/src/SerialImp.c,v > retrieving revision 1.46.2.187 > diff -u -r1.46.2.187 SerialImp.c > --- SerialImp.c 29 Jan 2006 22:19:04 -0000 1.46.2.187 > +++ SerialImp.c 21 Mar 2006 12:59:16 -0000 > @@ -656,6 +656,25 @@ > fd=OPEN (filename, O_RDWR | O_NOCTTY | O_NONBLOCK ); > } while (fd < 0 && errno==EINTR); > > +#ifdef OPEN_EXCL > + // Note that open() follows POSIX semantics: multiple open() > calls to > + // the same file will succeed unless the TIOCEXCL ioctl is > issued. > + // This will prevent additional opens except by root-owned > processes. > + // See tty(4) ("man 4 tty") and ioctl(2) ("man 2 ioctl") for > details. > + > + if (fd >= 0 && (ioctl(fd, TIOCEXCL) == -1)) > + { > + sprintf( message, "open: exclusive access denied for % > s\n", > + filename ); > + report( message ); > + report_error( message ); > + > + close(fd); > + goto fail; > + } > +#endif /* OPEN_EXCL */ > + > + > if( configure_port( fd ) ) goto fail; > (*env)->ReleaseStringUTFChars( env, jstr, filename ); > sprintf( message, "open: fd returned is %i\n", fd ); > Index: SerialImp.h > =================================================================== > RCS file: /usr/local/cvsroot/rxtx-devel/src/SerialImp.h,v > retrieving revision 1.11.2.49 > diff -u -r1.11.2.49 SerialImp.h > --- SerialImp.h 5 Jul 2005 17:47:21 -0000 1.11.2.49 > +++ SerialImp.h 21 Mar 2006 12:59:17 -0000 > @@ -135,7 +135,8 @@ > /*# define LOCKDIR "/var/spool/uucp"*/ > # define LOCKDIR "/var/lock" > # define LOCKFILEPREFIX "LK." > -# define UUCP > +/*# define UUCP*/ > +# define OPEN_EXCL > #endif /* __APPLE__ */ > #if defined(__NetBSD__) > # define DEVICEDIR "/dev/" > This looks like a good start. What do you think Dmitry? Perhaps all systems with TIOCEXCL defined should use that though. Even if they use lockfiles. It wont hurt anything. That would catch people hacking their own serial apps without checking lockfiles. Its a good idea to avoid C++ style comments in the C portions. Some older systems don't deal with them well. If it's just for Mac OS X, it isn't a big deal. I think it was the Irix compiler that was problematic? -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Tue Mar 21 11:22:05 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 21 Mar 2006 11:22:05 -0700 (MST) Subject: [Rxtx] lock files In-Reply-To: <8E12916A-1B9A-4FF2-B684-E2D1C794221B@buechse.de> References: <8E12916A-1B9A-4FF2-B684-E2D1C794221B@buechse.de> Message-ID: We can try it. Maybe the JNI is much improved. The nice thing about linking into liblock is distros then worry about lockfiles on their systems. This way, we have to deal with any changes that may show up. On Tue, 21 Mar 2006, Joachim Buechse wrote: > This is pretty much what I thought about when I suggested, that the > default behaviour could be overwritten with a property. I am very much in > favor of this approach. In particular this allows much easier debugging > for PC based java developers. > > I think big parts of the Java (and maybe some parts of the C code) could > use a bit of a structural workover (unit tests, javadoc, synchronization, > etc). Maybe there should be a CVS branch for this experimental version. > I'd be happy to contribute a first workover for some of the Java code. > Designing for testability and implementing a good bunch of unit tests has > been a strategy that worked quite well in the Java projects I lead. And > it ultimately allows more liberal change permission. > > Regards, > Joachim > > > On 21.03.2006, at 08:51, Dr. Douglas Lyon wrote: > >> Hi All, >> You know, if the use of lock files were >> under Java control (rather than a build-time decision), >> it might enable a more unified binary distro. It might also >> facilitate quick prototyping of non-lock file approaches >> to resolving serial port contention issues (i.e., mac-like >> approaches vs. linux approaches, etc.). >> >> I realize that this is a radical overhaul of the lock file policy >> issue. Also, it may harm performance. On the other hand, >> our benchmarks on JNI overhead for modern processors indicate >> performance impact should be minimal. Perhaps it is more of >> an issue with the toybox systems. >> >> Suppose there were a class with a reasonable default...someone >> might write: >> SerialPortLockPolicy.setPolicy(SerialPortLockPolicy.UNIX_LOCK_FILE); >> SerialPortLockPolicy.setPolicy(SerialPortLockPolicy.NO_LOCK_CHECKING); >> SerialPortLockPolicy.setPolicy(SerialPortLockPolicy.MAC_STYLE); >> >> Thus, we could have a run-time reconfiguration of the serial port lock >> policy. A special NO_LOCK version of the binary would no longer >> be required. >> >> Any thoughts on this? >> >> Thanks! >> - Doug >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From dmarkman at mac.com Tue Mar 21 16:05:17 2006 From: dmarkman at mac.com (Dmitry Markman) Date: Tue, 21 Mar 2006 18:05:17 -0500 Subject: [Rxtx] PATCH: use of ioctl(fd, TIOCEXCL) instead of lockfiles In-Reply-To: References: <923AE774-EEA2-4911-92D8-32BB27802C8B@buechse.de> Message-ID: <512AC70C-BB86-48F2-A83C-023F35C23BAB@mac.com> I think it's cool, but I'd like to have that property implementation when user can choose between locking mechanism about comments: it's easy to change comments to the C style or we can use extensions of the file to cpp so c++ compiler will be used On Mar 21, 2006, at 1:05 PM, Trent Jarvi wrote: > This looks like a good start. What do you think Dmitry? Perhaps > all systems with TIOCEXCL defined should use that though. Even if > they use lockfiles. It wont hurt anything. That would catch > people hacking their own serial apps without checking lockfiles. > > Its a good idea to avoid C++ style comments in the C portions. > Some older systems don't deal with them well. If it's just for Mac > OS X, it isn't a big deal. I think it was the Irix compiler that > was problematic? Dmitry Markman From dmarkman at mac.com Tue Mar 21 16:13:00 2006 From: dmarkman at mac.com (Dmitry Markman) Date: Tue, 21 Mar 2006 18:13:00 -0500 Subject: [Rxtx] PATCH: use of ioctl(fd, TIOCEXCL) instead of lockfiles In-Reply-To: References: <923AE774-EEA2-4911-92D8-32BB27802C8B@buechse.de> Message-ID: I'd like to add that creating locking folder isn't a big deal we never had a problem related to the lock folders, because we always used installer on mac os x from other hand I'm not very much familiar with iotcl locking approach and I'm not sure it's more efficient Joachim wrote "I think it is the way to go, as it eliminates creating the lock directory which doesnt exist on the standard installation and it eliminates messing with the system group definitions (adding users to group uucp)." but I really didn't have any problem with that 1. doesn't exist on the standard installation there are many-many things that don't exist in the standard installation so I don't think that argument is strong enough 2. messing with the system group definitions I don't think we're messing with the group definition mac os x provides very clear way to set up group's members and together with Greg Guerin AuthKit there is no problem to set those definitions so I don't think that argument is strong either but from other hand using iotcl is more promising and is more elegant On Mar 21, 2006, at 1:05 PM, Trent Jarvi wrote: > > This looks like a good start. What do you think Dmitry? Perhaps > all systems with TIOCEXCL defined should use that though. Even if > they use lockfiles. It wont hurt anything. That would catch > people hacking their own serial apps without checking lockfiles. Dmitry Markman From joachim at buechse.de Wed Mar 22 04:46:45 2006 From: joachim at buechse.de (Joachim Buechse) Date: Wed, 22 Mar 2006 12:46:45 +0100 Subject: [Rxtx] PATCH: use of ioctl(fd, TIOCEXCL) instead of lockfiles In-Reply-To: References: <923AE774-EEA2-4911-92D8-32BB27802C8B@buechse.de> Message-ID: Sorry, I was not very clear with my arguments, so I will try again;-) Please, don't take this as an attack against work that has been done. I think the contributions that have been made in the past were made in a good spirit. But I really believe, that the current solution for OSX has many shortcomings and should be changed as soon as possible. lock files --- The /var/lock folder does not exist on the standard OSX installation, however the standard installation includes several applications that use serial ports (i.e. the FAX capability). This indicates, that the lock folder approach will not work well with system components. Applications for OSX will generally try to live in harmony with system components (except for HP print drivers of course). I think RXTX should follow this approach as well. uucp group --- Accessing serial ports is not an admin privileged operation on OSX. Any user (world) has read/write privileges on /dev/tty*. So the system default is to not enforce any group membership to access these ports. The group uucp however is a system group on all unix systems I know. It exists for certain system processes. A non admin user should in general not be a member of this group. Quite arguably no user should ever be a member of this group. Installer --- My general opinion is, that - no Installer should touch user or group data without warning - no Application Installer should touch groups which are not specific to the very application installed - no Installer should ever add regular users to a system group The current installer injects the installing user in the group uucp without warning about this change and without giving the option to "opt out" of this change. This is a potential security risk (but not currently a real one, as OSX contains no folders belonging to group uucp). The current installer does not work for multi user systems. It puts the installing user in the uucp group. However the installing user is not necessarily the user that will use the application. Putting all users that may use a serial port application in the system group uucp seems like a very invasive approach to me. Besides that, newly created users will not automatically be in the group and hence, serial applications will "break" for new users without obvious reasons. Avoiding the lock files will allow self contained applications (i.e. drag&drop installation). In my eyes this is largely preferable over an installer that requests admin privileges. Adding up all these points indicates very strongly, that the lock-file implementation is not the way to go on OSX. Regards, Joachim On 22.03.2006, at 00:13, Dmitry Markman wrote: > I'd like to add that > > creating locking folder isn't a big deal > we never had a problem related to the lock folders, because we > always used installer on mac os x > from other hand I'm not very much familiar with iotcl locking > approach and I'm not sure it's more efficient > > Joachim wrote "I think it is the way to go, as it eliminates > creating the lock directory which doesnt exist on the standard > installation and it eliminates messing with the system group > definitions (adding users to group uucp)." but I really didn't have > any problem with that > > 1. doesn't exist on the standard installation > there are many-many things that don't exist in the standard > installation so I don't think that argument is strong enough > 2. messing with the system group definitions > I don't think we're messing with the group definition > mac os x provides very clear way to set up group's members and > together with Greg Guerin AuthKit there is no problem to set those > definitions > so I don't think that argument is strong either > but from other hand using iotcl is more promising and is more elegant > > > > On Mar 21, 2006, at 1:05 PM, Trent Jarvi wrote: > >> >> This looks like a good start. What do you think Dmitry? Perhaps >> all systems with TIOCEXCL defined should use that though. Even if >> they use lockfiles. It wont hurt anything. That would catch >> people hacking their own serial apps without checking lockfiles. > > Dmitry Markman > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From dmarkman at mac.com Wed Mar 22 05:27:13 2006 From: dmarkman at mac.com (Dmitry Markman) Date: Wed, 22 Mar 2006 07:27:13 -0500 Subject: [Rxtx] PATCH: use of ioctl(fd, TIOCEXCL) instead of lockfiles In-Reply-To: References: <923AE774-EEA2-4911-92D8-32BB27802C8B@buechse.de> Message-ID: <83440CF3-DCD8-41C1-B941-F227232C27E3@mac.com> thanks for the very good explanation I didn't think that you were attacking any thing, so don't worry I just had feeling, that there were more aesthetic reasons for going to ioctl then real necessity now you explained everything quite well (BTW, asfar as I remember installer asks admin password so it wasn't quiet, but it really doesn't matter now) thanks On Mar 22, 2006, at 6:46 AM, Joachim Buechse wrote: > Sorry, I was not very clear with my arguments, so I will try again;-) > > Please, don't take this as an attack against work that has been > done. I think the contributions that have been made in the past > were made in a good spirit. But I really believe, that the current > solution for OSX has many shortcomings and should be changed as > soon as possible. > > lock files > --- > The /var/lock folder does not exist on the standard OSX > installation, however the standard installation includes several > applications that use serial ports (i.e. the FAX capability). This > indicates, that the lock folder approach will not work well with > system components. Applications for OSX will generally try to live > in harmony with system components (except for HP print drivers of > course). I think RXTX should follow this approach as well. > > uucp group > --- > Accessing serial ports is not an admin privileged operation on OSX. > Any user (world) has read/write privileges on /dev/tty*. So the > system default is to not enforce any group membership to access > these ports. The group uucp however is a system group on all unix > systems I know. It exists for certain system processes. A non admin > user should in general not be a member of this group. Quite > arguably no user should ever be a member of this group. > > Installer > --- > My general opinion is, that > - no Installer should touch user or group data without warning > - no Application Installer should touch groups which are not > specific to the very application installed > - no Installer should ever add regular users to a system group > > The current installer injects the installing user in the group uucp > without warning about this change and without giving the option to > "opt out" of this change. This is a potential security risk (but > not currently a real one, as OSX contains no folders belonging to > group uucp). > > The current installer does not work for multi user systems. It puts > the installing user in the uucp group. However the installing user > is not necessarily the user that will use the application. Putting > all users that may use a serial port application in the system > group uucp seems like a very invasive approach to me. Besides that, > newly created users will not automatically be in the group and > hence, serial applications will "break" for new users without > obvious reasons. > > > Avoiding the lock files will allow self contained applications > (i.e. drag&drop installation). In my eyes this is largely > preferable over an installer that requests admin privileges. Adding > up all these points indicates very strongly, that the lock-file > implementation is not the way to go on OSX. > > Regards, > Joachim > > > On 22.03.2006, at 00:13, Dmitry Markman wrote: > >> I'd like to add that >> >> creating locking folder isn't a big deal >> we never had a problem related to the lock folders, because we >> always used installer on mac os x >> from other hand I'm not very much familiar with iotcl locking >> approach and I'm not sure it's more efficient >> >> Joachim wrote "I think it is the way to go, as it eliminates >> creating the lock directory which doesnt exist on the standard >> installation and it eliminates messing with the system group >> definitions (adding users to group uucp)." but I really didn't >> have any problem with that >> >> 1. doesn't exist on the standard installation >> there are many-many things that don't exist in the standard >> installation so I don't think that argument is strong enough >> 2. messing with the system group definitions >> I don't think we're messing with the group definition >> mac os x provides very clear way to set up group's members and >> together with Greg Guerin AuthKit there is no problem to set those >> definitions >> so I don't think that argument is strong either >> but from other hand using iotcl is more promising and is more elegant >> >> >> >> On Mar 21, 2006, at 1:05 PM, Trent Jarvi wrote: >> >>> >>> This looks like a good start. What do you think Dmitry? Perhaps >>> all systems with TIOCEXCL defined should use that though. Even >>> if they use lockfiles. It wont hurt anything. That would catch >>> people hacking their own serial apps without checking lockfiles. >> >> Dmitry Markman >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx Dmitry Markman From lyon at docjava.com Wed Mar 22 06:12:18 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Wed, 22 Mar 2006 08:12:18 -0500 Subject: [Rxtx] sole of a new design pattern Message-ID: Hi All, I have been thinking about how we design the serial port software. I think we need a new design pattern. For lack of a better term, I shall call it: The Parametric Singleton Design Pattern By Douglas A. Lyon ABSTRACT The goal of the singleton design pattern is to make sure that there is one, and only one, instance of a given class. The goal of the parametric singleton design pattern is to make sure that there is one, and only one, instance of a given class with the given parametric values. We parametric singleton design pattern combines the singleton design pattern with a parameter that enables unique creation of instances of a class. These instances are cached. When a user asks for an instance with these parameters, the cache is checked. If the instance is in the cache, the instance is returned, otherwise it is created, added to the cache and then returned. We apply our parametric singleton design pattern to the retrieval of RMI registries bound to a given port. The goal of our system is to make sure that no two RMI registries are listening to the same socket and to make use of the RMI registries after they have been created. RMI registries are used in distributed computation. Introduction The singleton design pattern is meant to ensure that on a single instance of a class exists. It is also meant to provide a global point of access to it. The intent of the parametric singleton design pattern is to ensure that a class has only one instance for a given set of parameter values. It also provides a global point of access to it. Motivation A system cannot tolerate multiple instances of some classes with identical parameters. For example, you cannot have two instances making use of the same serial port, at the same time. You cannot have two instances that are trying to listen to the same socket connection. You cannot have two instances writing to the same file structure at the same time. As the operating system is often thought of as the arbiter of consumed resources (i.e., tape drives, serial ports, etc.) we frequently leave it to an operating system implementation to resolve these contention issues. Even for similar resources (like serial ports) there are few standards for handling contention. For example, serial ports on Linux are locked using a "/var/lock" file. POSIX, on the other hand, uses ioctl mechanisms to prevent contention. A better solution is to make a class that is responsible for keeping track of the instances created from the class. The class is declared final, so that it cannot be subclassed. The class also has a private constructor, so that other classes cannot instance it. The new design pattern is called the parametric singleton design pattern and it provides a way to access and create instances with given parameters. Applicability Use the Parametric Singleton Design Pattern when: 1. There must be exactly one instance of a class with the given parameters. 2. The instances must be accessible to clients from a well-known access point. Structure Insert UML diagram here. Participants The Parametric Singleton Clients that need instances 1. The Parametric Singleton defines an instance upon request from a client, if, and only if, the instance does not already exist. 2. The Parametric Singleton returns the instance to the client. 3. The Parametric Singleton is responsible for creating unique instances from given parameters. Collaborations Clients obtain a reference to a Parametric Singleton instance only through the parametric singleton design pattern. If the instance is left in an improper state (e.g., the serial port was left open) it is NOT the role of the Parametric Singleton Design Pattern to close the IO port. Nor is it the role of the Parametric Singleton Design Pattern to open the port. That role is delegate to some other part of the system. Further, it is not the role of the Parametric Singleton Design Pattern to check out resources. That is, multiple threads can have multiple references to the same resource at the same time. MUTEX locking is delegated to some other part of the system. Consequences The Parametric Singleton Design Pattern has several benefits: 1. Controlled access to parametrically defined instances. Since the Parametric Singleton class encapsulates its instances, there is control over how and when clients access it. 2. Reduced name space. The Parametric Singleton pattern avoids global variables that store instances created from the same parameter. Implementation Here are implementation issues to consider when using the Parametric Singleton pattern: 1. Unique mapping of parameters. The Parametric Singleton pattern requires that there be a mean to isomorphically map the parameter space into the instance space and back again. 2. Ensure unique instances. The Parametric Singleton pattern makes unique instances from parameters, and it does so only once. 3. Cache instances for fast retrieval. The Parametric Singleton pattern must be able to look up instances, given some set of parameters, and do so from some data structure. That is, there must be enough space to hold references to all the instances the program will need. Also, a mechanism is needed to look up and retrieve the instances quickly enough to satisfy the clients. Sample Code public final class ParametricSingletonRmiRegistry { private static Hashtable registry = new Hashtable(100); // use singleton pattern and??????????????????????????????????????????????? // prevent instantiation of RmiRegistryUtils.?????????????????????????????? private ParametricSingletonRmiRegistry() { } // the only instance of the Registry held by the RmiRegistryUtils?????????? public static void listNames(Integer port) { if (!isInCacheAndRunning(port)) return; Registry r = (Registry) registry.get(port); System.out.println("registry on port: " + port); System.out.println("registry: " + r); System.out.println("names: "); try { print(r.list()); } catch (RemoteException e) { In.message(e); } System.out.println("------------------------"); } /**???????????????????????????????????????????????????????????????????????? * Checks whether a Registry has been started on this host????????????????? * in the specified port.?????????????????????????????????????????????????? * If not, it tries to start one.?????????????????????????????????????????? * when it fails to start a Registry, it exits the program????????????????? * with exit code 1.??????????????????????????????????????????????????????? */ public static void restart(int port) { if (isInCacheAndRunning(port)) return; try { startRegistry(port); } catch (RemoteException e) { In.message(e); } } /**???????????????????????????????????????????????????????????????????????? * @param port????????????????????????????????????????????????????????????? * @return true if registry is in cache and running???????????????????????? */ private static boolean isInCacheAndRunning(Integer port) { if (!isRegistryRunning(port.intValue())) return false; if (!isRegistryInCache(port.intValue())) return false; return true; } /**???????????????????????????????????????????????????????????????????????? * @param port????????????????????????????????????????????????????????????? * @return true if we are able to locate a local registry on port.??????????????????????????????????????????????????????????????????????????? */ private static boolean isRegistryRunning(int port) { try { Registry r = LocateRegistry.getRegistry(port); if (r != null) return true; } catch (RemoteException e) { return false; } return false; } /**???????????????????????????????????????????????????????????????????????? * @param port????????????????????????????????????????????????????????????? * @return return true if registry is in cache????????????????????????????? */ private static boolean isRegistryInCache(int port) { if (registry.get(new Integer(port)) == null) return false; return true; } /**???????????????????????????????????????????????????????????????????????? * Restart the registry, if needed.???????????????????????????????????????? * Return the only instance of the registry for consistent global?????????? * using by making use of the Singleton Design Pattern????????????????????? *????????????????????????????????????????????????????????????????????????? * @return the internally held registry instance.?????????????????????????? */ public static Registry getRegistry(Integer port) { restart(port); return (Registry) registry.get(port); } private static void startRegistry(Integer port) throws RemoteException { Registry r; try { r = LocateRegistry.createRegistry(port.intValue()); registry.put(port, r); //r = new sun.rmi.registry.RegistryImpl???????????????????????????? /// (port.intValue());?????????????????????????????????????? // registry.put(port, r);?????????????????????????????????????????? } catch (Exception e) { //e.printStackTrace();????????????????????????????????????????????? r = LocateRegistry.getRegistry(port.intValue()); registry.put(port, r); } } public static void main(String args[]) throws RemoteException { //restart(port);??????????????????????????????????????????????????????? restart(5001); restart(5002); restart(5002); Registry r = LocateRegistry.getRegistry(5002); System.out.println("registry="+r); } } I would very much like to get your feedback on this new design pattern idea. Thank you for your time. Regards, - Doug From david.garnier at trusted-logic.com Wed Mar 22 07:36:10 2006 From: david.garnier at trusted-logic.com (David Garnier) Date: Wed, 22 Mar 2006 15:36:10 +0100 Subject: [Rxtx] sole of a new design pattern In-Reply-To: References: Message-ID: <442160DA.80107@trusted-logic.com> Hello, > The Parametric Singleton Design Pattern The Singleton is the most abused design pattern ever. Good use-cases for this pattern are extremely rare and mostly confined to problems related to hardware resources, like serial ports. > Applicability > > Use the Parametric Singleton Design Pattern when: > 1. There must be exactly one instance of a class with the given > parameters. OK. As I said above, this case this actually very unusual. The Singleton pattern is mostly used when : > 2. The instances must be accessible to clients from a well-known > access point. Using the singleton pattern in this case is just convenient for the programmer. Problems arises pretty quickly, especially if you attempt to unit-test your classes. 1) If your singleton is stateful, or hold on to stateful objects, it means that two different unit tests are not actually independent. Instead of starting with a brand new environment, the result of a test may be affected by the result of a previous test. This problem also arise when with your class relies on a database. In both cases, the solution is to reset your "unique" resource (Singleton or database) at the beginning of the test, which is a pain. Also, while most projects connect to a single database, projects that allow the use of Singletons usually contain several of thems, and new ones may cropped up unnoticed. You quickly end up with test cases that only pass in a certain order, which is a royal pain. 2) You cannot mockup a singleton. Once everyone calls the SomeSingleton class statically, you can't replace your class by SomeSingletonMockup. Furthermore, even for hardware services, the Singleton pattern does not really prevent concurrent accesses. If you start the same program in two different JVMs, unless they somehow shared the state of their "Singletons" (through lock files for example), the Singleton pattern will not prevent concurrent access. Our application uses RXTX, and we routinely encounter cases where another (native) application has already locked the port. Since we cannot modify the native application to recognize lock files, OS-level control is irreplaceable. > > Consequences > The Parametric Singleton Design Pattern has several benefits: > > 1. Controlled access to parametrically defined instances. Since > the Parametric Singleton class encapsulates its instances, there is > control over how and when clients access it. Not really. Once you've returned the instance to a client, you've lost control over it. The client can to whatever it wants with it. You cannot "recall" the instance or claim it back. > 2. Reduced name space. The Parametric Singleton pattern avoids > global variables that store instances created from the same parameter. Sure, but you don't have to rely on a Singleton for that. Just create a single Factory. > I would very much like to get your feedback on this new design > pattern idea. Well, it's nothing new. Some may say that it is the point of design patterns: formalizes the designs that occur again and again. However, this design is simply a combination of the Singleton and Factory patterns. I did use it in the past, but now I've been exposed to the shortcomings of the Singleton pattern, so I limit myself to Factories. Regards, David From sean_montgomery at baseview.com Wed Mar 22 08:35:28 2006 From: sean_montgomery at baseview.com (Sean Montgomery) Date: Wed, 22 Mar 2006 10:35:28 -0500 Subject: [Rxtx] sole of a new design pattern In-Reply-To: <442160DA.80107@trusted-logic.com> References: <442160DA.80107@trusted-logic.com> Message-ID: <05769CA7-A51B-4CF0-BAA0-E02DD905F5A4@baseview.com> On Mar 22, 2006, at 9:36 AM, David Garnier wrote: > Furthermore, even for hardware services, the Singleton pattern does > not really prevent concurrent > accesses. If you start the same program in two different JVMs, > unless they somehow shared the state > of their "Singletons" (through lock files for example), the > Singleton pattern will not prevent > concurrent access. > Multiple class loaders in a single JVM can be tricky, too. Then there's synchronization, lazy initialization and serialization of singletons to contend with. Bloch's Effective Java covers these, and here's a few articles: http://www.javaworld.com/javaworld/jw-04-2003/jw-0425-designpatterns- p3.html http://java.sun.com/developer/technicalArticles/Programming/singletons/ Just FYI :-) From lyon at docjava.com Wed Mar 22 08:50:48 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Wed, 22 Mar 2006 10:50:48 -0500 Subject: [Rxtx] sole of a new design pattern In-Reply-To: <442160DA.80107@trusted-logic.com> References: <442160DA.80107@trusted-logic.com> Message-ID: Hi All, First, I would like to thank David for his prompt and thoughtful remarks. I had no idea people that feel strongly about a design patterns! Wow! Feedback (particularly critical feedback) is greatly appreciated. Starting at the end, first: >I did use it in >the past, but now I've been exposed to the shortcomings of the >Singleton pattern, so I limit myself to Factories. David, if I understood your comments correctly, you suggested that Factories can be used in leu of the Singleton Design Pattern, or even the Parametric Singleton Design Pattern. As I see in [Gof]: Factory Method: Intent "Define an interface for creating an object, but let subclasses decide which class to instantiate. Factory Method lets a class defer instantiation to subclasses." The Singleton Design Pattern is a concrete class, which is rather different, right? Also, subclasses are not permitted with Singleton, as they are final. Naturally, I could use an abstract factory as a parent for a singleton. I could even design a facade that could be implemented with the singleton....but that is not the intention of the design. Unless you want a mock-up, as discussed, below: More below: >Hello, > >> The Parametric Singleton Design Pattern > >The Singleton is the most abused design pattern ever. Good use-cases >for this pattern are extremely >rare and mostly confined to problems related to hardware resources, >like serial ports. > > >> Applicability >> >> Use the Parametric Singleton Design Pattern when: >> 1. There must be exactly one instance of a class with the given >> parameters. >OK. As I said above, this case this actually very unusual. The >Singleton pattern is mostly used when : >> 2. The instances must be accessible to clients from a well-known >> access point. > >Using the singleton pattern in this case is just convenient for the >programmer. Problems arises >pretty quickly, especially if you attempt to unit-test your classes. > >1) If your singleton is stateful, or hold on to stateful objects, it >means that two different unit >tests are not actually independent. Instead of starting with a brand >new environment, the result of >a test may be affected by the result of a previous test. This >problem also arise when with your >class relies on a database. In both cases, the solution is to reset >your "unique" resource >(Singleton or database) at the beginning of the test, which is a >pain. Also, while most projects >connect to a single database, projects that allow the use of >Singletons usually contain several of >thems, and new ones may cropped up unnoticed. You quickly end up >with test cases that only pass in a >certain order, which is a royal pain. There are basic problems with communicating finite state machines that include reachability and deadlock analysis. These are addressed with petri net analysis and are beyond the scope of the design pattern. As you quite rightly pointed out; the parametric singleton pattern (or the singleton pattern, for that matter) enable multiple threads to gain access to the same instance. The only way that I can see to block others from gaining access to the reference is the synchronize keyword. This is putting a spin-lock (or MUTEX) on the reference. The question of how to unit-test a design pattern like the parametric singleton remains open. Perhaps this is a deficiency. > >2) You cannot mockup a singleton. Once everyone calls the >SomeSingleton class statically, you can't >replace your class by SomeSingletonMockup. Acutally, I am not sure that this is true. If the Singleton implements a Facade interface, it should be possible to make the replacement. Right? > >Furthermore, even for hardware services, the Singleton pattern does >not really prevent concurrent >accesses. If you start the same program in two different JVMs, >unless they somehow shared the state >of their "Singletons" (through lock files for example), the >Singleton pattern will not prevent >concurrent access. Good Point!! You have sharp eyes! The singleton design pattern should/could take responsibility for this. In fact, you may notice that my code does have an implementation (LocateRegistry) that can work across JVM's. The LocateRegistry will even work across the Internet! LocateRegistry takes both a host name and a Port (lock files just don't do this). I did not think to implement this beyond the local machine, but, in its present form, it will work across different processes. > >Our application uses RXTX, and we routinely encounter cases where >another (native) application has >already locked the port. Since we cannot modify the native >application to recognize lock files, >OS-level control is irreplaceable. The singleton design pattern is not meant to replace OS-level control, but to centralize the Java programmers access to it. If lock files, for example, are used for serial ports, the Singleton Design Pattern should be able to work with them. > > >> >> Consequences >> The Parametric Singleton Design Pattern has several benefits: >> > > 1. Controlled access to parametrically defined instances. Since >> the Parametric Singleton class encapsulates its instances, there is >> control over how and when clients access it. > >Not really. Once you've returned the instance to a client, you've >lost control over it. The client >can to whatever it wants with it. You cannot "recall" the instance >or claim it back. Good point, this should read: > 1. Controll when parametrically defined instances are created. Since > > the Parametric Singleton class encapsulates its instances, there is > > control over how and when they are instanced. > >> 2. Reduced name space. The Parametric Singleton pattern avoids >> global variables that store instances created from the same parameter. > >Sure, but you don't have to rely on a Singleton for that. Just >create a single Factory. > > Thank you for your thoughtful and prompt response! Regards, - Doug From dmarkman at mac.com Wed Mar 22 21:21:55 2006 From: dmarkman at mac.com (Dmitry Markman) Date: Wed, 22 Mar 2006 23:21:55 -0500 Subject: [Rxtx] sole of a new design pattern In-Reply-To: <442160DA.80107@trusted-logic.com> References: <442160DA.80107@trusted-logic.com> Message-ID: I don't think I get it On Mar 22, 2006, at 9:36 AM, David Garnier wrote: > Using the singleton pattern in this case is just convenient for the > programmer. Problems arises > pretty quickly, especially if you attempt to unit-test your classes. so you're saying that something isn't so good because you can not test it in the convenient way? if that's true, I'm totally disagree change your test, debug whatever, but if software is efficient at runtime, works fine and only problem is some unit test (which is some kind of framework for testing) then dump that unit test , dump that unit framework and make something appropriate to the software you're testing so if Douglas want to use singletons, what's the problem? and what do you mean by abusing of singleton usage? of course singleton doesn't prevent concurrent access to the resource across the processes unless you're using some OS facility to prevent it, besides singleton as it was introduced is relevant only and only inside of the same process otherwise it's not singleton it's something else (let's say network singleton: so you have remote invocation facility and some factory method that return object created by that facility) I don't have any problem with using any kind of singletons. Parametric Singleton idea (if I understand it right) could be easily implemented in the following way: use a map populate map with instances of some class and key is your parameter (you can use lazy population too) if somebody ask the key check the value if it's null so resource is taken if somebody returns the resource put it back to the map public synchronized static Object getSomeResource(Object parameter); public synchronized static void returnResource(Object parameter); getSomeResource (inside of the same process) could return null in 2 cases 1. if somebody (from other thread for example) already took that resource 2. if OS API said that resource corresponded to that parameter (serial port with parameter = 1 (port #)) is locked and unavailable; I'm not sure that in case of serial ports we even need those Parametric Singletons (unless lock checking is a very expensive operation) just ask the OS about availability of that resource and if it's available give it away and then OS will lock it and therefore in next time somebody ask it just answer that resource is locked and return null for example system has 2 serial ports available so I ask getResource("tty"); or I ask getResource("Bluetooth-Modem"); and if OS is ok you can give tty or Bluetooth-Modem or both no need for any additional pattern I think back to the problem mac os x doesn't recognize locking via files, so it handles locking via some API an instance of the singleton in each process should recognize that resource is locked (by using that API) that's all we don't have to make things more complicate then they are just because there is some nice design pattern or nice unit test framework or whatever keep things simple, make them work fast, don't introduce middle layers unless you have really good reason to do so of course I could be entirely wrong, so sorry about that in advance thanks Dmitry Markman From tjarvi at qbang.org Wed Mar 22 22:31:41 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 22 Mar 2006 22:31:41 -0700 (MST) Subject: [Rxtx] sole of a new design pattern In-Reply-To: References: Message-ID: Hi Doug Interesting reading. So far I'm just reading and thinking. I have one question so far. " Clients obtain a reference to a Parametric Singleton instance only through the parametric singleton design pattern. If the instance is left in an improper state (e.g., the serial port was left open) it is NOT the role of the Parametric Singleton Design Pattern to close the IO port. Nor is it the role of the Parametric Singleton Design Pattern to open the port. That role is delegate to some other part of the system. " So when the clients obtain a reference to the singleton, can they assume the port is there? IE, would it be the singletons role to handle things like USB dongles being removed with event hints comming from the underlying OS. Hardware abstraction layer/HAL on Linux is an example of underlying OS events. I assume that role too is delegated to other parts of the system? -- Trent Jarvi tjarvi at qbang.org From lyon at docjava.com Thu Mar 23 08:10:33 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Thu, 23 Mar 2006 10:10:33 -0500 Subject: [Rxtx] Classes don't need goals, they need roles! In-Reply-To: References: Message-ID: Hi Trent, Yes, I think that the role of the Parametric Singleton Pattern is not to open or close serial ports, nor is it to perform error checking. On the other hand, if you were to combine the role of the Parametric Singleton Pattern with another role (like that of error checking) it might not be amiss. However, I generally caution programmers against adding multiple roles to classes, as this leads to monolithic designs. Thus a different class (NativeLibDetect) could have the role of determining if the native library can be loaded. Another class (SerialPortBean) can have the role of serializing the default state of the serial port, so that it can be recovered, from user preferences, at a later time. The SerialPortDetect could have the role of determining if the serial port is removed (i.e., a USB port was unplugged). My guess is that each class should have a different role in the system, in order to ease maintenance and testing...but I could be wrong about that. Thanks! - Doug >Hi Doug > >Interesting reading. So far I'm just reading and thinking. I have >one question so far. > >" > Clients obtain a reference to a Parametric Singleton instance only >through the parametric singleton design pattern. If the instance is >left in an improper state (e.g., the serial port was left open) it is >NOT the role of the Parametric Singleton Design Pattern to close the >IO port. Nor is it the role of the Parametric Singleton Design Pattern >to >open the port. That role is delegate to some other part of the system. >" > >So when the clients obtain a reference to the singleton, can they >assume the port is there? IE, would it be the singletons role to >handle things like USB dongles being removed with event hints >comming from the underlying OS. Hardware abstraction layer/HAL on >Linux is an example of underlying OS events. > >I assume that role too is delegated to other parts of the system? > >-- >Trent Jarvi >tjarvi at qbang.org >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From maximulo at yahoo.com Fri Mar 24 01:22:38 2006 From: maximulo at yahoo.com (Maximulo Majir) Date: Fri, 24 Mar 2006 00:22:38 -0800 (PST) Subject: [Rxtx] JavaPOS Message-ID: <20060324082238.66371.qmail@web38214.mail.mud.yahoo.com> Hi all! Hello Trent! From what i understand, RXTX or JavaComm APIs were not created solely for JavaPOS. In JavaPOS, we have the virtual method claim() which is separate from open(), but in our RXTX API, claiming is done every call to open(), we cant open the port if its claimed by another application. Would it be alright to suggest or ask to create a new method called claim(..)? Is there such thing as forceclaim() in RXTX? this could be the same as portownership transfer or its equivalent. ForceClaim is in JSR80. Do you have some samples using RXTX as the lower layer for the Device Service Objects in JavaPOS? I have tried it, i just want to compare. Thank you all! maxim __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060324/496adba2/attachment-0007.html From tjarvi at qbang.org Fri Mar 24 11:28:19 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 24 Mar 2006 11:28:19 -0700 (MST) Subject: [Rxtx] Re: RXTX 2.1 Solaris Problems In-Reply-To: <3691.1143210578@www045.gmx.net> References: <3691.1143210578@www045.gmx.net> Message-ID: On Fri, 24 Mar 2006, Andreas Guenther wrote: > Hi all, > > the solaris problem was not the lock file only. > > Ok, I had to create the directory /var/spool/locks myself. > /var/spool/uucp exists. > > But rxtx didn't find any port. > > I compiled the source with my own debug-informations > and I tried to isolate the problem. > > The problem is the testRead-call in SerialImp.c > > JNIEXPORT jboolean JNICALL RXTXCommDriver(testRead)( > > ... > if ( READ( fd, &c, 1 ) < 0 ) > { > if ( errno != EAGAIN ) { > report( "testRead() read failed\n" ); > ret = JNI_FALSE; > } > } > Thanks Andreas I'm packing up to move. I'll be more or less away for a couple weeks here. I'll be checking email but my workstation is going into a box soon. This isn't hard to fix as this port should be enumerated when EWOULDBLOCK is recieved. Thats error is OK for enumeration just as EAGAIN is. I've put the bug into bugzilla so we dont forget to get to it. http://bugzilla.qbang.org/show_bug.cgi?id=42 You can add yourself to the CC list if you wish to test fixes we provide or even put a patch into bugzilla yourself. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Fri Mar 24 11:51:52 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 24 Mar 2006 11:51:52 -0700 (MST) Subject: [Rxtx] JavaPOS In-Reply-To: <20060324082238.66371.qmail@web38214.mail.mud.yahoo.com> References: <20060324082238.66371.qmail@web38214.mail.mud.yahoo.com> Message-ID: On Fri, 24 Mar 2006, Maximulo Majir wrote: > Hi all! Hello Trent! > > > From what i understand, RXTX or JavaComm APIs were not > created solely for JavaPOS. In JavaPOS, we have the virtual method > claim() which is separate from open(), but in our RXTX API, claiming is > done every call to open(), we cant open the port if its claimed by > another application. Would it be alright to suggest or ask to create a > new method called claim(..)? Is there such thing as forceclaim() in > RXTX? this could be the same as portownership transfer or its > equivalent. ForceClaim is in JSR80. > Do you have some samples using RXTX as the lower layer for the Device > Service Objects in JavaPOS? I have tried it, i just want to compare. > maxim Hi Maxim JSR80 is the USB API IBM/Sun put together. The problem is they have a richer kernel/API underneath that can handle such things. With Serial Ports, there isnt anything there other than an ioctl that says don't let anyone touch this and lockfiles that are more of a 'lets be nice.' At times we may be using USB ports but it is through the termios layer with the limitations mentioned. The advantage is that not only USB will work with rxtx. Anything that has a termios layer should work (to the extent that termios layer is complete). I don't know how forceclaim() would help you. Lets say someone has a programmer working on /dev/ttyS0 and you take it. Now you both race each other to read data first. There isn't a mechanism I know of that will solve this problem in termios. The most obvious test being a native app and a Java app trying to take the port. There is the potential of requestion ownership from other Java Applications but the use for that is very rare. Did you have something more specific in mind that I'm missing? I'm not sure that claim() and forceclaim() would help you with rxtx other than maybe locking the port with claim() without opening it. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sat Mar 25 23:42:08 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 25 Mar 2006 23:42:08 -0700 (MST) Subject: [Rxtx] Serial snoop Message-ID: I was reading the Linux kernel mail-list tonight and ran past a thread that mentioned sersnoop. This looks like a handy tool for people dealing with new toys. "a simple command-line tool for linux that echoes bytes to and from any two serial ports, ptys, or network sockets, and prints all traffic to stdout, in hex and ascii." http://www.restivo.org/projects/sersnoop/ It works on Linux only at this time (debian package available). -- Trent Jarvi tjarvi at qbang.org From beat.arnet at gmail.com Sun Mar 26 07:32:35 2006 From: beat.arnet at gmail.com (Beat Arnet) Date: Sun, 26 Mar 2006 09:32:35 -0500 Subject: [Rxtx] Error 0x5 at /home/bob/foo/tar/rxtx-2.1-7/build/../src/termios.c(860): Access is, denied. Message-ID: <4426A603.80508@gmail.com> Dear all, When trying to open the serial port, I sometimes (not always) run into the following exception (when opening the serialPort): Error 0x5 at /home/bob/foo/tar/rxtx-2.1-7/build/../src/termios.c(860): Access is denied. java.lang.UnsatisfiedLinkError: native_psmisc_report_owner at gnu.io.CommPortIdentifier.native_psmisc_report_owner(Native Method) at gnu.io.CommPortIdentifier.open(CommPortIdentifier.java:354) at codeskin.tools.CLLoader.open(CLLoader.java:79) at codeskin.tools.C2000Programmer.run(C2000Programmer.java:220) at java.lang.Thread.run(Unknown Source) Is this the type of error where I should just try to open the port again, or can it be avoided? Regards, Beat From tjarvi at qbang.org Sun Mar 26 11:40:12 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 26 Mar 2006 11:40:12 -0700 (MST) Subject: [Rxtx] Error 0x5 at /home/bob/foo/tar/rxtx-2.1-7/build/../src/termios.c(860): Access is, denied. In-Reply-To: <4426A603.80508@gmail.com> References: <4426A603.80508@gmail.com> Message-ID: On Sun, 26 Mar 2006, Beat Arnet wrote: > Dear all, > > When trying to open the serial port, I sometimes (not always) run into > the following exception (when opening the serialPort): > > Error 0x5 at /home/bob/foo/tar/rxtx-2.1-7/build/../src/termios.c(860): > Access is > denied. > > java.lang.UnsatisfiedLinkError: native_psmisc_report_owner > at gnu.io.CommPortIdentifier.native_psmisc_report_owner(Native > Method) > at gnu.io.CommPortIdentifier.open(CommPortIdentifier.java:354) > at codeskin.tools.CLLoader.open(CLLoader.java:79) > at codeskin.tools.C2000Programmer.run(C2000Programmer.java:220) > at java.lang.Thread.run(Unknown Source) > > Is this the type of error where I should just try to open the port again, > or can it be avoided? > Hi Beat We did a second build of rxtx 2.1-7 to resolve that unsatisfied link error. It should work now. rxtx is trying to tell you it thinks someone else has the serial port open. You can try to open the port again but maybe you already have a copy of the program running when it happens? ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7r2.zip fixed build. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sun Mar 26 11:44:23 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 26 Mar 2006 11:44:23 -0700 (MST) Subject: [Rxtx] RXTX spec file (fwd) Message-ID: This is probably interesting for fedora/suse users. ---------- Forwarded message ---------- Date: Sun, 26 Mar 2006 16:25:45 +0200 To: taj at www.linux.org.uk Subject: RXTX spec file I send you this spec file which allows to create a RPM for Fedora 4, 5 (x86, x86_64) with Java Sun. -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: rxtx.spec Url: http://mailman.qbang.org/pipermail/rxtx/attachments/20060326/6c7b6af6/rxtx-0003.pl From tjarvi at qbang.org Sun Mar 26 23:42:59 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 26 Mar 2006 23:42:59 -0700 (MST) Subject: [Rxtx] Upcomming events. Message-ID: This Wednesday we will be announcing a new "Maintainer" for the rxtx project. The position is more like neutral leader. I wont be going away or doing less. This is just the right thing to do as it turns out the two people with CVS write access will be at the same company. We need a third and we need neutrality. The maintainer will have final say in any conflict and will try to be neutral. It will be open for discussion. Then we will do it :) I'll still do most of the footwork I do now. But. I'm falling behind. I should have gone through the mail-list and posted the next round of changes this weekend. I'm packing to move and its going so so - 13 years of toys collected. I suspect there will be a dead period on my part (a couple weeks) comming up. But if you get it on the mail-list, we will get it in if there are no objections. I may well not be reading the mail-list during this period as I look for a house and many other things. I hope everyone will help out. Thanks -- Trent Jarvi tjarvi at qbang.org From mahmoud_hadad at yahoo.com Sun Mar 26 07:31:19 2006 From: mahmoud_hadad at yahoo.com (ronan nick) Date: Sun, 26 Mar 2006 06:31:19 -0800 (PST) Subject: [Rxtx] a question about the COMM API Message-ID: <20060326143119.54919.qmail@web60014.mail.yahoo.com> hi, i was intrested in knowing how i can communicate with my internal modem using java? for example if i want to make a phone dialer application or a caller id application where should i be looking at? and as i understood the COMM API is for devices that is attached to the computer through serial ports. --------------------------------- New Yahoo! Messenger with Voice. Call regular phones from your PC and save big. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060326/ce8329f0/attachment-0005.html From dmarkman at mac.com Mon Mar 20 00:20:43 2006 From: dmarkman at mac.com (Dmitry Markman) Date: Mon, 20 Mar 2006 02:20:43 -0500 Subject: [Rxtx] Mac OS X RXTX java installer In-Reply-To: References: <07D0DE29-BA32-4CFE-B036-66BC6423D385@buechse.de> <441AE3E0.2030503@willicon.de> <12531986.1142622114996.JavaMail.dmarkman@mac.com> <441B2674.9010409@willicon.de> <13577405.1142634732776.JavaMail.dmarkman@mac.com> <441B4182.8010407@willicon.de> <92CD0D6C-5BE8-426E-A46D-99452059FF49@mac.com> <441BBB2D.8030305@willicon.de> <441C4088.5090905@willicon.de> Message-ID: <64BC1E23-FDDE-4CE6-8863-CFC881CBC224@mac.com> Hi all I put RXTX installer that will install everything (and will create / var/lock if necessary and add user to the uucp group) for mac os x from Java into the rxtx's CVS repository it could be easily modified to install files for any platform it uses Greg Guerin's AuthKit for authentication and authorization Greg released that kit under artistic license, so Trent, please take a look we, probably, can negotiate license with Greg if it's necessary Greg's AuthKit could be downloaded from http://www.amug.org/~glguerin/ sw/#authkit Michael Hall (mikehall at spacestar dot net) had a suggestion to make implementation of the jaas LoginModule based on Greg's AuthKit (his modification of the Greg's AuthKit could be found at http:// www.spacestar.net/users/mikehall/authkit.dmg) but Michael's AuthKitLoginModule does only half a job: it does authenticate but it can not run any external unix process in privileged mode (at least I wasn't able to do so) possible explanation could be found in conversation between Greg and Michael at Apple's java-dev list (look for archives) so I didn't use jaas API for rxtxinstaller I created folder MacOSX in the contrib folder comment 1. if you want to run that installer as standalone application all you need that RXTXInstaller.jar 2. if you want to use webstart you have to add Greg's libAuthKit.jnilib to the mac os x's resources in theory RXTXInstaller.jar doesn't need it, but there is a problem with loading libAuthKit.jnilib from webstart authkit uses loadLibrary method to load library and it failed (from webstart) for standalone application I extract libAuthKit.jnilib from the RXTXInstaller.jar and put it into the /Library/Java/Extensions or ~/Library/Java/Extensions folder that file will be deleted after installer quit unfortunately I didn't have time to put documentation there but it is mostly self-explanatory I took installer code from my gl4java installer that I did about 3 years ago (with small modifications) it would be very nice if Apple will release LoginModule that really will do the job (com.apple.security.auth.module package????? ) (UnixLoginModule is pretty useless) From lyon at docjava.com Mon Mar 20 06:34:39 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Mon, 20 Mar 2006 08:34:39 -0500 Subject: [Rxtx] Mac OS X RXTX java installer In-Reply-To: <64BC1E23-FDDE-4CE6-8863-CFC881CBC224@mac.com> References: <07D0DE29-BA32-4CFE-B036-66BC6423D385@buechse.de> <441AE3E0.2030503@willicon.de> <12531986.1142622114996.JavaMail.dmarkman@mac.com> <441B2674.9010409@willicon.de> <13577405.1142634732776.JavaMail.dmarkman@mac.com> <441B4182.8010407@willicon.de> <92CD0D6C-5BE8-426E-A46D-99452059FF49@mac.com> <441BBB2D.8030305@willicon.de> <441C4088.5090905@willicon.de> <64BC1E23-FDDE-4CE6-8863-CFC881CBC224@mac.com> Message-ID: Hi Dimitry, This sounds like great work. Just a couple of questions; After the check out of the CVS files, using: setenv CVSROOT :pserver:anonymous at cvs.milestonesolutions.com:/usr/local/cvsroot 53 8:28 setenv PASSWORD mousy 54 8:29 cvs login 55 8:29 cvs checkout rxtx-devel I cd'd over to: rxtx-devel/MACOSX_IDE And found: CVS/ CW/ ForPackageMaker/ PB/ Where is the installer? Thanks! - Doug From tjarvi at qbang.org Mon Mar 20 06:39:37 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 20 Mar 2006 06:39:37 -0700 (MST) Subject: [Rxtx] Mac OS X RXTX java installer In-Reply-To: References: <07D0DE29-BA32-4CFE-B036-66BC6423D385@buechse.de> <441AE3E0.2030503@willicon.de> <12531986.1142622114996.JavaMail.dmarkman@mac.com> <441B2674.9010409@willicon.de> <13577405.1142634732776.JavaMail.dmarkman@mac.com> <441B4182.8010407@willicon.de> <92CD0D6C-5BE8-426E-A46D-99452059FF49@mac.com> <441BBB2D.8030305@willicon.de> <441C4088.5090905@willicon.de> <64BC1E23-FDDE-4CE6-8863-CFC881CBC224@mac.com> Message-ID: On Mon, 20 Mar 2006, Dr. Douglas Lyon wrote: > Hi Dimitry, > This sounds like great work. Just a couple of questions; > After the check out of the CVS files, using: > setenv CVSROOT > :pserver:anonymous at cvs.milestonesolutions.com:/usr/local/cvsroot > 53 8:28 setenv PASSWORD mousy > 54 8:29 cvs login > 55 8:29 cvs checkout rxtx-devel Hi Doug You want "cvs checkout -r commapi-0-0-1 rxtx-devel" to get RXTX 2.1 The default branch is rxtx 2.0 which isn't very active right now. -- Trent Jarvi tjarvi at qbang.org From lyon at docjava.com Mon Mar 20 07:05:44 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Mon, 20 Mar 2006 09:05:44 -0500 Subject: [Rxtx] Mac OS X RXTX java installer In-Reply-To: References: <07D0DE29-BA32-4CFE-B036-66BC6423D385@buechse.de> <441AE3E0.2030503@willicon.de> <12531986.1142622114996.JavaMail.dmarkman@mac.com> <441B2674.9010409@willicon.de> <13577405.1142634732776.JavaMail.dmarkman@mac.com> <441B4182.8010407@willicon.de> <92CD0D6C-5BE8-426E-A46D-99452059FF49@mac.com> <441BBB2D.8030305@willicon.de> <441C4088.5090905@willicon.de> <64BC1E23-FDDE-4CE6-8863-CFC881CBC224@mac.com> Message-ID: Hi Trent, Thanks for the info on the CVS checkout procedure. I did that and am still not sure where the installer is. Here is what I have: cd MACOSX_IDE/ p4.docjava.com{lyon}121: ls CVS/ ForPackageMaker/ PB/ p4.docjava.com{lyon}122: find . | more . ./ForPackageMaker ./ForPackageMaker/RXTX.pkg.sit.hqx ./ForPackageMaker/Resources ./ForPackageMaker/Resources/ReadMe.rtf ./ForPackageMaker/Resources/Welcome.rtf ./ForPackageMaker/Resources/CVS ./ForPackageMaker/Resources/CVS/Entries ./ForPackageMaker/Resources/CVS/Repository ./ForPackageMaker/Resources/CVS/Tag ./ForPackageMaker/Resources/CVS/Root ./ForPackageMaker/Resources/preinstall ./ForPackageMaker/Resources/License.rtf ./ForPackageMaker/Resources/preupgrade ./ForPackageMaker/RXTX.pmsp ./ForPackageMaker/CVS ./ForPackageMaker/CVS/Entries ./ForPackageMaker/CVS/Repository ./ForPackageMaker/CVS/Entries.Log ./ForPackageMaker/CVS/Tag ./ForPackageMaker/CVS/Root ./ForPackageMaker/RXTX_Tiger.pkg.sitx.hqx ./ForPackageMaker/RXTX_Jag.pkg.sit.hqx ./ForPackageMaker/Install ./ForPackageMaker/Install/CVS ./ForPackageMaker/Install/CVS/Entries ./ForPackageMaker/Install/CVS/Repository ./ForPackageMaker/Install/CVS/Tag ./ForPackageMaker/Install/CVS/Root ./ForPackageMaker/Install/Library ./ForPackageMaker/Install/Library/CVS ./ForPackageMaker/Install/Library/CVS/Entries ./ForPackageMaker/Install/Library/CVS/Repository ./ForPackageMaker/Install/Library/CVS/Tag ./ForPackageMaker/Install/Library/CVS/Root ./ForPackageMaker/Install/Library/Java ./ForPackageMaker/Install/Library/Java/Extensions ./ForPackageMaker/Install/Library/Java/Extensions/RXTXcomm.jar ./ForPackageMaker/Install/Library/Java/Extensions/CVS ./ForPackageMaker/Install/Library/Java/Extensions/CVS/Entries ./ForPackageMaker/Install/Library/Java/Extensions/CVS/Repository ./ForPackageMaker/Install/Library/Java/Extensions/CVS/Tag ./ForPackageMaker/Install/Library/Java/Extensions/CVS/Root ./ForPackageMaker/Install/Library/Java/Extensions/librxtxSerial.jnilib ./ForPackageMaker/Install/Library/Java/CVS ./ForPackageMaker/Install/Library/Java/CVS/Entries ./ForPackageMaker/Install/Library/Java/CVS/Repository ./ForPackageMaker/Install/Library/Java/CVS/Entries.Log ./ForPackageMaker/Install/Library/Java/CVS/Tag ./ForPackageMaker/Install/Library/Java/CVS/Root ./ForPackageMaker/RXTX_Tiger.pmproj.sitx.hqx ./CVS ./CVS/Entries ./CVS/Repository ./CVS/Entries.Log ./CVS/Tag ./CVS/Root ./PB ./PB/LibSerialUniversal.xcodeproj.sitx.hqx ./PB/CVS ./PB/CVS/Entries ./PB/CVS/Repository ./PB/CVS/Entries.Log ./PB/CVS/Tag ./PB/CVS/Root ./PB/LibSerial.pbproj.sit.hqx ./PB/startpoint.c ./PB/config.h What is the procedure to run this installer? Do we need a README in: /rxtx-devel/MACOSX_IDE Here is what we have: CVS/ ForPackageMaker/ PB/ Thanks! - DL >On Mon, 20 Mar 2006, Dr. Douglas Lyon wrote: > >>Hi Dimitry, >>This sounds like great work. Just a couple of questions; >>After the check out of the CVS files, using: >>setenv CVSROOT >>:pserver:anonymous at cvs.milestonesolutions.com:/usr/local/cvsroot >> 53 8:28 setenv PASSWORD mousy >> 54 8:29 cvs login >> 55 8:29 cvs checkout rxtx-devel > >Hi Doug > >You want "cvs checkout -r commapi-0-0-1 rxtx-devel" to get RXTX 2.1 >The default branch is rxtx 2.0 which isn't very active right now. > >-- >Trent Jarvi >tjarvi at qbang.org From tjarvi at qbang.org Mon Mar 20 07:25:30 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 20 Mar 2006 07:25:30 -0700 (MST) Subject: [Rxtx] Mac OS X RXTX java installer In-Reply-To: References: <07D0DE29-BA32-4CFE-B036-66BC6423D385@buechse.de> <441AE3E0.2030503@willicon.de> <12531986.1142622114996.JavaMail.dmarkman@mac.com> <441B2674.9010409@willicon.de> <13577405.1142634732776.JavaMail.dmarkman@mac.com> <441B4182.8010407@willicon.de> <92CD0D6C-5BE8-426E-A46D-99452059FF49@mac.com> <441BBB2D.8030305@willicon.de> <441C4088.5090905@willicon.de> <64BC1E23-FDDE-4CE6-8863-CFC881CBC224@mac.com> Message-ID: On Mon, 20 Mar 2006, Dr. Douglas Lyon wrote: > Hi Trent, > Thanks for the info on the CVS checkout procedure. > I did that and am still not sure where the installer is. Hi Doug It does look like it was not cvs committed. There is no rxtx-devel/contrib/MacOSX directory in there at the moment. It was mentioned that it was put under contrib. -- Trent Jarvi tjarvi at qbang.org From dmarkman at mac.com Mon Mar 20 07:29:56 2006 From: dmarkman at mac.com (Dmitry Markman) Date: Mon, 20 Mar 2006 09:29:56 -0500 Subject: [Rxtx] Mac OS X RXTX java installer In-Reply-To: References: <07D0DE29-BA32-4CFE-B036-66BC6423D385@buechse.de> <441AE3E0.2030503@willicon.de> <12531986.1142622114996.JavaMail.dmarkman@mac.com> <441B2674.9010409@willicon.de> <13577405.1142634732776.JavaMail.dmarkman@mac.com> <441B4182.8010407@willicon.de> <92CD0D6C-5BE8-426E-A46D-99452059FF49@mac.com> <441BBB2D.8030305@willicon.de> <441C4088.5090905@willicon.de> <64BC1E23-FDDE-4CE6-8863-CFC881CBC224@mac.com> Message-ID: <6054EB4E-F7E0-4A9C-BDDA-D582D6D8826F@mac.com> you can find it in the rxtx-devel/contrib folder On Mar 20, 2006, at 9:05 AM, Dr. Douglas Lyon wrote: > Hi Trent, > Thanks for the info on the CVS checkout procedure. > I did that and am still not sure where the installer is. > Here is what I have: > cd MACOSX_IDE/ > p4.docjava.com{lyon}121: ls > CVS/ ForPackageMaker/ PB/ > p4.docjava.com{lyon}122: find . | more > . > ./ForPackageMaker > ./ForPackageMaker/RXTX.pkg.sit.hqx > ./ForPackageMaker/Resources > ./ForPackageMaker/Resources/ReadMe.rtf > ./ForPackageMaker/Resources/Welcome.rtf > ./ForPackageMaker/Resources/CVS > ./ForPackageMaker/Resources/CVS/Entries > ./ForPackageMaker/Resources/CVS/Repository > ./ForPackageMaker/Resources/CVS/Tag > ./ForPackageMaker/Resources/CVS/Root > ./ForPackageMaker/Resources/preinstall > ./ForPackageMaker/Resources/License.rtf > ./ForPackageMaker/Resources/preupgrade > ./ForPackageMaker/RXTX.pmsp > ./ForPackageMaker/CVS > ./ForPackageMaker/CVS/Entries > ./ForPackageMaker/CVS/Repository > ./ForPackageMaker/CVS/Entries.Log > ./ForPackageMaker/CVS/Tag > ./ForPackageMaker/CVS/Root > ./ForPackageMaker/RXTX_Tiger.pkg.sitx.hqx > ./ForPackageMaker/RXTX_Jag.pkg.sit.hqx > ./ForPackageMaker/Install > ./ForPackageMaker/Install/CVS > ./ForPackageMaker/Install/CVS/Entries > ./ForPackageMaker/Install/CVS/Repository > ./ForPackageMaker/Install/CVS/Tag > ./ForPackageMaker/Install/CVS/Root > ./ForPackageMaker/Install/Library > ./ForPackageMaker/Install/Library/CVS > ./ForPackageMaker/Install/Library/CVS/Entries > ./ForPackageMaker/Install/Library/CVS/Repository > ./ForPackageMaker/Install/Library/CVS/Tag > ./ForPackageMaker/Install/Library/CVS/Root > ./ForPackageMaker/Install/Library/Java > ./ForPackageMaker/Install/Library/Java/Extensions > ./ForPackageMaker/Install/Library/Java/Extensions/RXTXcomm.jar > ./ForPackageMaker/Install/Library/Java/Extensions/CVS > ./ForPackageMaker/Install/Library/Java/Extensions/CVS/Entries > ./ForPackageMaker/Install/Library/Java/Extensions/CVS/Repository > ./ForPackageMaker/Install/Library/Java/Extensions/CVS/Tag > ./ForPackageMaker/Install/Library/Java/Extensions/CVS/Root > ./ForPackageMaker/Install/Library/Java/Extensions/librxtxSerial.jnilib > ./ForPackageMaker/Install/Library/Java/CVS > ./ForPackageMaker/Install/Library/Java/CVS/Entries > ./ForPackageMaker/Install/Library/Java/CVS/Repository > ./ForPackageMaker/Install/Library/Java/CVS/Entries.Log > ./ForPackageMaker/Install/Library/Java/CVS/Tag > ./ForPackageMaker/Install/Library/Java/CVS/Root > ./ForPackageMaker/RXTX_Tiger.pmproj.sitx.hqx > ./CVS > ./CVS/Entries > ./CVS/Repository > ./CVS/Entries.Log > ./CVS/Tag > ./CVS/Root > ./PB > ./PB/LibSerialUniversal.xcodeproj.sitx.hqx > ./PB/CVS > ./PB/CVS/Entries > ./PB/CVS/Repository > ./PB/CVS/Entries.Log > ./PB/CVS/Tag > ./PB/CVS/Root > ./PB/LibSerial.pbproj.sit.hqx > ./PB/startpoint.c > ./PB/config.h > > What is the procedure to run this installer? > Do we need a README in: > /rxtx-devel/MACOSX_IDE > Here is what we have: > CVS/ ForPackageMaker/ PB/ > > > Thanks! > - DL > >> On Mon, 20 Mar 2006, Dr. Douglas Lyon wrote: >> >>> Hi Dimitry, >>> This sounds like great work. Just a couple of questions; >>> After the check out of the CVS files, using: >>> setenv CVSROOT :pserver:anonymous at cvs.milestonesolutions.com:/usr/ >>> local/cvsroot >>> 53 8:28 setenv PASSWORD mousy >>> 54 8:29 cvs login >>> 55 8:29 cvs checkout rxtx-devel >> >> Hi Doug >> >> You want "cvs checkout -r commapi-0-0-1 rxtx-devel" to get RXTX 2.1 >> The default branch is rxtx 2.0 which isn't very active right now. >> >> -- >> Trent Jarvi >> tjarvi at qbang.org > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx Dmitry Markman From mikehall at spacestar.net Mon Mar 20 05:25:25 2006 From: mikehall at spacestar.net (Michael Hall) Date: Mon, 20 Mar 2006 06:25:25 -0600 Subject: [Rxtx] Re: Mac OS X RXTX java installer In-Reply-To: <64BC1E23-FDDE-4CE6-8863-CFC881CBC224@mac.com> References: <07D0DE29-BA32-4CFE-B036-66BC6423D385@buechse.de> <441AE3E0.2030503@willicon.de> <12531986.1142622114996.JavaMail.dmarkman@mac.com> <441B2674.9010409@willicon.de> <13577405.1142634732776.JavaMail.dmarkman@mac.com> <441B4182.8010407@willicon.de> <92CD0D6C-5BE8-426E-A46D-99452059FF49@mac.com> <441BBB2D.8030305@willicon.de> <441C4088.5090905@willicon.de> <64BC1E23-FDDE-4CE6-8863-CFC881CBC224@mac.com> Message-ID: <247EB61F-5CD1-4132-89A2-FC105B6CF9A5@spacestar.net> On Mar 20, 2006, at 1:20 AM, Dmitry Markman wrote: > > Michael Hall (mikehall at spacestar dot net) had a suggestion to > make implementation of the jaas LoginModule > based on Greg's AuthKit > (his modification of the Greg's AuthKit could be found at http:// > www.spacestar.net/users/mikehall/authkit.dmg) > but Michael's AuthKitLoginModule does only half a job: > it does authenticate > but it can not run any external unix process in privileged mode (at > least I wasn't able to do so) If you got it working directly with Greg's the point is moot. But to clarify it anyhow. The login module does not allow you to do anything anything privileged on return as was explained by Greg. You need to work with a separate privileged process using the execPrivileged method of his API. I assume you did something similar although I haven't looked at how you are using it yet. I allowed instead for a action to be performed at the same time you login/authenticate,this... System.setProperty("authkit.action","/usr/bin/id"); just before this... lc.login(); To clarify, safely ignored as you are already complete. Mike Hall mikehall at spacestar dot net http://www.spacestar.net/users/mikehall http://sourceforge.net/projects/macnative -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2427 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20060320/f6e18202/smime-0008.bin From dmarkman at mac.com Mon Mar 20 07:36:47 2006 From: dmarkman at mac.com (Dmitry Markman) Date: Mon, 20 Mar 2006 09:36:47 -0500 Subject: [Rxtx] Re: Mac OS X RXTX java installer In-Reply-To: <247EB61F-5CD1-4132-89A2-FC105B6CF9A5@spacestar.net> References: <07D0DE29-BA32-4CFE-B036-66BC6423D385@buechse.de> <441AE3E0.2030503@willicon.de> <12531986.1142622114996.JavaMail.dmarkman@mac.com> <441B2674.9010409@willicon.de> <13577405.1142634732776.JavaMail.dmarkman@mac.com> <441B4182.8010407@willicon.de> <92CD0D6C-5BE8-426E-A46D-99452059FF49@mac.com> <441BBB2D.8030305@willicon.de> <441C4088.5090905@willicon.de> <64BC1E23-FDDE-4CE6-8863-CFC881CBC224@mac.com> <247EB61F-5CD1-4132-89A2-FC105B6CF9A5@spacestar.net> Message-ID: Hi, Michael all I have to do is to run some shell script I tried to use your action mechanism and it worked great so I just System.setProperty ("authkit.action","" ) and after that I even don't need to run anything like subject.doAs.... but after few thoughts I choose to use plain Greg's approach, because in that case I don't have to deal with various java's configurations files and therefore to use 2-3 -D parameters in the java command line especially it's useful for java web start (it's so fragile :-( ) thanks for the great job On Mar 20, 2006, at 7:25 AM, Michael Hall wrote: > > On Mar 20, 2006, at 1:20 AM, Dmitry Markman wrote: >> >> Michael Hall (mikehall at spacestar dot net) had a suggestion to >> make implementation of the jaas LoginModule >> based on Greg's AuthKit >> (his modification of the Greg's AuthKit could be found at http:// >> www.spacestar.net/users/mikehall/authkit.dmg) >> but Michael's AuthKitLoginModule does only half a job: >> it does authenticate >> but it can not run any external unix process in privileged mode >> (at least I wasn't able to do so) > > If you got it working directly with Greg's the point is moot. > > But to clarify it anyhow. > The login module does not allow you to do anything anything > privileged on return as was explained by Greg. You need to work > with a separate privileged process using the execPrivileged method > of his API. I assume you did something similar although I haven't > looked at how you are using it yet. > I allowed instead for a action to be performed at the same time you > login/authenticate,this... > System.setProperty("authkit.action","/usr/bin/id"); > just before this... > lc.login(); > To clarify, safely ignored as you are already complete. > > Mike Hall mikehall at spacestar dot net > http://www.spacestar.net/users/mikehall > http://sourceforge.net/projects/macnative > > > Dmitry Markman From dmarkman at mac.com Mon Mar 20 07:44:45 2006 From: dmarkman at mac.com (Dmitry Markman) Date: Mon, 20 Mar 2006 09:44:45 -0500 Subject: [Rxtx] Mac OS X RXTX java installer In-Reply-To: References: <07D0DE29-BA32-4CFE-B036-66BC6423D385@buechse.de> <441AE3E0.2030503@willicon.de> <12531986.1142622114996.JavaMail.dmarkman@mac.com> <441B2674.9010409@willicon.de> <13577405.1142634732776.JavaMail.dmarkman@mac.com> <441B4182.8010407@willicon.de> <92CD0D6C-5BE8-426E-A46D-99452059FF49@mac.com> <441BBB2D.8030305@willicon.de> <441C4088.5090905@willicon.de> <64BC1E23-FDDE-4CE6-8863-CFC881CBC224@mac.com> Message-ID: it's in the commapi-0-0-1 branch I tested it right now: cvs co -r commapi-0-0-1 rxtx-devel and I got everything On Mar 20, 2006, at 9:25 AM, Trent Jarvi wrote: > On Mon, 20 Mar 2006, Dr. Douglas Lyon wrote: > >> Hi Trent, >> Thanks for the info on the CVS checkout procedure. >> I did that and am still not sure where the installer is. > > Hi Doug > > It does look like it was not cvs committed. There is no rxtx-devel/ > contrib/MacOSX directory in there at the moment. It was mentioned > that it was put under contrib. > > -- > Trent Jarvi > tjarvi at qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx Dmitry Markman From tjarvi at qbang.org Mon Mar 20 07:52:57 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 20 Mar 2006 07:52:57 -0700 (MST) Subject: [Rxtx] Mac OS X RXTX java installer In-Reply-To: References: <07D0DE29-BA32-4CFE-B036-66BC6423D385@buechse.de> <441AE3E0.2030503@willicon.de> <12531986.1142622114996.JavaMail.dmarkman@mac.com> <441B2674.9010409@willicon.de> <13577405.1142634732776.JavaMail.dmarkman@mac.com> <441B4182.8010407@willicon.de> <92CD0D6C-5BE8-426E-A46D-99452059FF49@mac.com> <441BBB2D.8030305@willicon.de> <441C4088.5090905@willicon.de> <64BC1E23-FDDE-4CE6-8863-CFC881CBC224@mac.com> Message-ID: On Mon, 20 Mar 2006, Dmitry Markman wrote: > it's in the commapi-0-0-1 branch > > I tested it right now: > cvs co -r commapi-0-0-1 rxtx-devel > > and I got everything > A fresh checkout worked. Here is a copy of the tree (just the installer bits) ftp://ftp.qbang.org/pub/rxtx/MacOSX-installer.zip -- Trent Jarvi tjarvi at qbang.org From lyon at docjava.com Mon Mar 20 08:08:26 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Mon, 20 Mar 2006 10:08:26 -0500 Subject: [Rxtx] Mac OS X RXTX java installer In-Reply-To: References: <07D0DE29-BA32-4CFE-B036-66BC6423D385@buechse.de> <441AE3E0.2030503@willicon.de> <12531986.1142622114996.JavaMail.dmarkman@mac.com> <441B2674.9010409@willicon.de> <13577405.1142634732776.JavaMail.dmarkman@mac.com> <441B4182.8010407@willicon.de> <92CD0D6C-5BE8-426E-A46D-99452059FF49@mac.com> <441BBB2D.8030305@willicon.de> <441C4088.5090905@willicon.de> <64BC1E23-FDDE-4CE6-8863-CFC881CBC224@mac.com> Message-ID: Hi All, Is the Auth package able to work properly on non Mac OS's? It was not clear from the doc or download. Thanks! - Doug From dmarkman at mac.com Mon Mar 20 08:15:22 2006 From: dmarkman at mac.com (Dmitry Markman) Date: Mon, 20 Mar 2006 10:15:22 -0500 Subject: [Rxtx] Mac OS X RXTX java installer In-Reply-To: References: <07D0DE29-BA32-4CFE-B036-66BC6423D385@buechse.de> <441AE3E0.2030503@willicon.de> <12531986.1142622114996.JavaMail.dmarkman@mac.com> <441B2674.9010409@willicon.de> <13577405.1142634732776.JavaMail.dmarkman@mac.com> <441B4182.8010407@willicon.de> <92CD0D6C-5BE8-426E-A46D-99452059FF49@mac.com> <441BBB2D.8030305@willicon.de> <441C4088.5090905@willicon.de> <64BC1E23-FDDE-4CE6-8863-CFC881CBC224@mac.com> Message-ID: <217312D8-CCCA-4859-ABA6-32DF1CC817B9@mac.com> thanks Trent, for putting it on ftp server On Mar 20, 2006, at 9:52 AM, Trent Jarvi wrote: > A fresh checkout worked. Here is a copy of the tree (just the > installer bits) > > ftp://ftp.qbang.org/pub/rxtx/MacOSX-installer.zip > Dmitry Markman From dmarkman at mac.com Mon Mar 20 09:14:03 2006 From: dmarkman at mac.com (Dmitry Markman) Date: Mon, 20 Mar 2006 11:14:03 -0500 Subject: [Rxtx] Mac OS X RXTX java installer In-Reply-To: References: <07D0DE29-BA32-4CFE-B036-66BC6423D385@buechse.de> <441AE3E0.2030503@willicon.de> <12531986.1142622114996.JavaMail.dmarkman@mac.com> <441B2674.9010409@willicon.de> <13577405.1142634732776.JavaMail.dmarkman@mac.com> <441B4182.8010407@willicon.de> <92CD0D6C-5BE8-426E-A46D-99452059FF49@mac.com> <441BBB2D.8030305@willicon.de> <441C4088.5090905@willicon.de> <64BC1E23-FDDE-4CE6-8863-CFC881CBC224@mac.com> Message-ID: <4DEBA6F0-DA45-4E84-823E-1F1AC48BDCCC@mac.com> no it will work only on mac os x however it's harmless to run it on other platform if you want to use it for other platform you have to do the following (I'll do it for linux) 1. modify RXTXInstaller class method public static RXTXInstaller getInstance() public static RXTXInstaller getInstance() { String osName = System.getProperty("os.name").toLowerCase(); if(osName.startsWith("mac")){ return new gnu.io.installer.macosx.MACOSXRXTXInstaller(); } else if(osName.startsWith("windows")){ return new gnu.io.installer.windows.WindowsRXTXInstaller(); }else if(osName.startsWith("linux")){ return new gnu.io.installer.linux.LinuxRXTXInstaller(); } return null; } 2. create folder gnu/io/installer/linux/ 3. create class Linux386RXTXInstaller package gnu.io.installer.linux; import java.io.File; public class Linux386RXTXInstaller extends gnu.io.installer.RXTXInstaller{ public Linux386RXTXInstaller(){ createJarFolder(); createLibFolder(); addJarResource("RXTXcomm.jar","/gnu/io/installer/resources/ linux/jar/RXTXcomm.dat"); addLibResource("librxtxSerial.so","/gnu/io/installer/ resources/linux/lib/librxtxSerial.so"); } protected void createJarFolder(){ String javaHome = System.getProperty("java.home"); char separator = File.separatorChar; jarFolder = new File(javaHome+separator+"lib"+separator+"ext"); } protected void createLibFolder(){ String javaHome = System.getProperty("java.home"); char separator = File.separatorChar; libFolder = new File(javaHome+separator+"bin"); } public void runPreProcess() {} //put here some action you need public void runPostProcess() {} //put here some action you need } 4. create folder /gnu/io/installer/resources/linux/jar and put there linux's version of RXTXcomm.dat (which is renamed RXTXcomm.jar) 5. create folder /gnu/io/installer/resources/linux/lib and put there linux's version of librxtxSerial. so 6. make sure that RXTXInstaller.jar has the following items: /gnu/io/installer/resources/linux/jar/RXTXcomm.jar /gnu/io/installer/resources/linux/lib/librxtxSerial.so 7. modify file installer.pref: jar file RXTXInstaller.jar must have the following item /gnu/io/installer/installer.pref that's basically it for windows you have to do the similar things: just replace linux to windows and librxtxSerial.so to rxtxSerial.dll and create appropriate gnu.io.installer.windows.WindowsRXTXInstaller class package gnu.io.installer.windows; import java.io.File; public class WindowsRXTXInstaller extends gnu.io.installer.RXTXInstaller{ public WindowsRXTXInstaller(){ createJarFolder(); createLibFolder(); addJarResource("RXTXcomm.jar","/gnu/io/installer/resources/ windows/jar/RXTXcomm.dat"); addLibResource("librxtxSerial.so","/gnu/io/installer/ resources/windows/lib/rxtxSerial.dll"); } protected void createJarFolder(){ String javaHome = System.getProperty("java.home"); char separator = File.separatorChar; jarFolder = new File(javaHome+separator+"lib"+separator+"ext"); } protected void createLibFolder(){ String javaHome = System.getProperty("java.home"); char separator = File.separatorChar; libFolder = new File(javaHome+separator+"bin"); } public void runPreProcess() {} //put here some action you need public void runPostProcess() {} //put here some action you need } installer.pref will look like On Mar 20, 2006, at 10:08 AM, Dr. Douglas Lyon wrote: > Hi All, > Is the Auth package able to work properly on > non Mac OS's? > It was not clear from the doc or download. > > Thanks! > - Doug > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx Dmitry Markman From joachim at buechse.de Mon Mar 20 10:49:06 2006 From: joachim at buechse.de (Joachim Buechse) Date: Mon, 20 Mar 2006 18:49:06 +0100 Subject: [Rxtx] BUG: Lock file stays even if port opening fails Message-ID: This was only tested on MacOSX but looking at the code, it should be true for all systems that use lock_uucp. I am opening a port which can not be opened (dialup port of a telephone paired via bluetooth but currently not reachable). The lock file is created and stays arround, even though the port open failed. After looking a bit through the code (of 2.17), I really wonder if it wouldn't be a good idea to make the "locking" an explicit operation called from the java code. This would certainly simplify the generation of meaningfull exceptions (and java based debugging). Maybe even the handling of "preopened" ports should be in the Java part of the lib (again for java based debugging puposes). That beeing said, I have no idea if this would be possible for the 2.07 implementation. Regards, Joachim From tjarvi at qbang.org Mon Mar 20 11:24:22 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 20 Mar 2006 11:24:22 -0700 (MST) Subject: [Rxtx] BUG: Lock file stays even if port opening fails In-Reply-To: References: Message-ID: On Mon, 20 Mar 2006, Joachim Buechse wrote: > This was only tested on MacOSX but looking at the code, it should be true > for all systems that use lock_uucp. > > I am opening a port which can not be opened (dialup port of a telephone > paired via bluetooth but currently not reachable). The lock file is > created and stays arround, even though the port open failed. > > > After looking a bit through the code (of 2.17), I really wonder if it > wouldn't be a good idea to make the "locking" an explicit operation > called from the java code. This would certainly simplify the generation > of meaningfull exceptions (and java based debugging). > Maybe even the handling of "preopened" ports should be in the Java part > of the lib (again for java based debugging puposes). That beeing said, I > have no idea if this would be possible for the 2.07 implementation. > > Regards, Hi Joachim It should be possible in the 2.0-7 implementation too. The calls to RXTXPort.java would not change. We would just do more there Moving more of that logic into Java would be better as many people don't like to look at C code. There is a liblockdev on most Linux distros that can do most of the C code and would be easier to use. The problem is embeded devices will not have that library. The preopened port code has not been really tested. That was a last minute request in a product cycle. I expect it will be tested this year though. As I recall, some devices really do not like CD raising on open. The preopened ports then allow people to mess around in java without power cycling the devices or losing data. -- Trent Jarvi tjarvi at qbang.org From joachim at buechse.de Mon Mar 20 12:01:08 2006 From: joachim at buechse.de (Joachim Buechse) Date: Mon, 20 Mar 2006 20:01:08 +0100 Subject: [Rxtx] BUG: Lock file stays even if port opening fails In-Reply-To: References: Message-ID: Hi Trent, What is your general feeling about moving code to Java? The last days I have been reading quite a bit of the code and there are several things, that might not work as expected. I'll give you two examples from is_device_locked: if LOCKDIR == /var/spool/locks the directory /var/spool/lock will not be checked. LOCKDIR is not checked for lockfiles with unexpected pefixes While these things have probably never been discovered in production, they are still possibly incorrect implementations. If it was Java code, I would write some unit tests producing the errors that could later be corrected. PS: One could imagine to actually implement the whole lockfile handling in Java using some native routines to get the values required (pid, st_dev, st_rdev, ...). On 20.03.2006, at 19:24, Trent Jarvi wrote: > On Mon, 20 Mar 2006, Joachim Buechse wrote: > >> This was only tested on MacOSX but looking at the code, it should >> be true for all systems that use lock_uucp. >> >> I am opening a port which can not be opened (dialup port of a >> telephone paired via bluetooth but currently not reachable). The >> lock file is created and stays arround, even though the port open >> failed. >> >> >> After looking a bit through the code (of 2.17), I really wonder if >> it wouldn't be a good idea to make the "locking" an explicit >> operation called from the java code. This would certainly simplify >> the generation of meaningfull exceptions (and java based debugging). >> Maybe even the handling of "preopened" ports should be in the Java >> part of the lib (again for java based debugging puposes). That >> beeing said, I have no idea if this would be possible for the 2.07 >> implementation. >> >> Regards, > > Hi Joachim > > It should be possible in the 2.0-7 implementation too. The calls > to RXTXPort.java would not change. We would just do more there > Moving more of that logic into Java would be better as many people > don't like to look at C code. There is a liblockdev on most Linux > distros that can do most of the C code and would be easier to use. > The problem is embeded devices will not have that library. > > The preopened port code has not been really tested. That was a > last minute request in a product cycle. I expect it will be tested > this year though. As I recall, some devices really do not like CD > raising on open. The preopened ports then allow people to mess > around in java without power cycling the devices or losing data. > > -- > Trent Jarvi > tjarvi at qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Mon Mar 20 12:21:02 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 20 Mar 2006 12:21:02 -0700 (MST) Subject: [Rxtx] BUG: Lock file stays even if port opening fails In-Reply-To: References: Message-ID: On Mon, 20 Mar 2006, Joachim Buechse wrote: > Hi Trent, > > What is your general feeling about moving code to Java? The last days I > have been reading quite a bit of the code and there are several things, > that might not work as expected. > > I'll give you two examples from is_device_locked: > > if LOCKDIR == /var/spool/locks the directory /var/spool/lock will not be > checked. > LOCKDIR is not checked for lockfiles with unexpected pefixes > > While these things have probably never been discovered in production, > they are still possibly incorrect implementations. If it was Java code, I > would write some unit tests producing the errors that could later be > corrected. > > PS: One could imagine to actually implement the whole lockfile handling > in Java using some native routines to get the values required (pid, > st_dev, st_rdev, ...). Hi Joachim I like the idea of moving more of the code into java but there are some things to consider. If you break this into multiple JNI calls, the performance will drop considerably during enumeration of ports. We are looking for 256 ports per dev type vs (16? in Sun's 2.0 and fewer types). Its hard to make assumptions. I've seen virtual ports start at /dev/foo100 for instance. It works out to over 7500 ports on Linux if you enable them all. We already trim that back by default. See Linux-all-ports in RXTXCommDriver.java. There are also native libraries that rxtx can link to. If you move too much into Java, linking to 'standard' libraries with distros will break. "configure --enable-liblock=yes" will not be doable. This is probably a favorable way with RedHat, Debian, Suse and others. Thats the right thing to do if there will be rpms, dpkg, .. For those reasons, I think it still make sense to keep it to a minimal ~3 calls to JNI code that we can use for speed and versatility. lock() isLocked(), unlock() perhaps. When I say speed, its more about avoiding crossing the JNI layer multiple times than java vs C performance. With versatility I think liblock is the right way for most but not all (embeded) linux distros. -- Trent Jarvi tjarvi at qbang.org From joachim at buechse.de Mon Mar 20 12:42:04 2006 From: joachim at buechse.de (Joachim Buechse) Date: Mon, 20 Mar 2006 20:42:04 +0100 Subject: [Rxtx] BUG: Lock file stays even if port opening fails In-Reply-To: References: Message-ID: <82C19FE7-DDCB-45B6-B2C9-7606B66F0124@buechse.de> Ok, what about providing a default implementation in Java? The RXTXCommDriver would call a (native) function useNativeLocking and if it returns true, call the native functions for lock() isLocked (), unlock(), else is would use the Java based default implementation. This could possibly be overriden by a property (again for debugging). Joachim On 20.03.2006, at 20:21, Trent Jarvi wrote: > On Mon, 20 Mar 2006, Joachim Buechse wrote: > >> Hi Trent, >> >> What is your general feeling about moving code to Java? The last >> days I have been reading quite a bit of the code and there are >> several things, that might not work as expected. >> >> I'll give you two examples from is_device_locked: >> >> if LOCKDIR == /var/spool/locks the directory /var/spool/lock will >> not be checked. >> LOCKDIR is not checked for lockfiles with unexpected pefixes >> >> While these things have probably never been discovered in >> production, they are still possibly incorrect implementations. If >> it was Java code, I would write some unit tests producing the >> errors that could later be corrected. >> >> PS: One could imagine to actually implement the whole lockfile >> handling in Java using some native routines to get the values >> required (pid, st_dev, st_rdev, ...). > > Hi Joachim > > I like the idea of moving more of the code into java but there are > some things to consider. > > If you break this into multiple JNI calls, the performance will > drop considerably during enumeration of ports. We are looking for > 256 ports per dev type vs (16? in Sun's 2.0 and fewer types). Its > hard to make assumptions. I've seen virtual ports start at /dev/ > foo100 for instance. > > It works out to over 7500 ports on Linux if you enable them all. > We already trim that back by default. See Linux-all-ports in > RXTXCommDriver.java. > > There are also native libraries that rxtx can link to. If you move > too much into Java, linking to 'standard' libraries with distros > will break. "configure --enable-liblock=yes" will not be doable. > This is probably a favorable way with RedHat, Debian, Suse and > others. Thats the right thing to do if there will be rpms, dpkg, .. > > For those reasons, I think it still make sense to keep it to a > minimal ~3 calls to JNI code that we can use for speed and > versatility. lock() isLocked(), unlock() perhaps. When I say > speed, its more about avoiding crossing the JNI layer multiple > times than java vs C performance. With versatility I think liblock > is the right way for most but not all (embeded) linux distros. > > -- > Trent Jarvi > tjarvi at qbang.org > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Mon Mar 20 12:44:47 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 20 Mar 2006 12:44:47 -0700 (MST) Subject: [Rxtx] BUG: Lock file stays even if port opening fails In-Reply-To: <82C19FE7-DDCB-45B6-B2C9-7606B66F0124@buechse.de> References: <82C19FE7-DDCB-45B6-B2C9-7606B66F0124@buechse.de> Message-ID: On Mon, 20 Mar 2006, Joachim Buechse wrote: > Ok, what about providing a default implementation in Java? > > The RXTXCommDriver would call a (native) function useNativeLocking and if > it returns true, call the native functions for lock() isLocked(), > unlock(), else is would use the Java based default implementation. This > could possibly be overriden by a property (again for debugging). > Hi Joachim That would be OK with me. -- Trent Jarvi tjarvi at qbang.org From dmarkman at mac.com Mon Mar 20 22:27:45 2006 From: dmarkman at mac.com (Dmitry Markman) Date: Tue, 21 Mar 2006 00:27:45 -0500 Subject: [Rxtx] binaries request Message-ID: <42702213-C222-4937-A585-7CFB17E47608@mac.com> Hi can somebody send me latest linux and windows binaries, please? or where I can find them (I didn't find them in the latest tareball) I gave up with my cygwin: something wrong I have no idea what java doesn't understand /cygwin/c syntax after I changed makefile it did java part but after that gcc 3.4.4 started to complain I set buffer length to 999 lines but I didn't get beginning of the story something wrong with my 1.4.2_09/include/jni.h gcc doesn't like it anyway I gave up thanks in advance Dmitry Markman -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060320/f8cbc57c/attachment-0008.html From tjarvi at qbang.org Mon Mar 20 22:36:48 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 20 Mar 2006 22:36:48 -0700 (MST) Subject: [Rxtx] binaries request In-Reply-To: <42702213-C222-4937-A585-7CFB17E47608@mac.com> References: <42702213-C222-4937-A585-7CFB17E47608@mac.com> Message-ID: On Tue, 21 Mar 2006, Dmitry Markman wrote: > Hi > can somebody send me latest linux and windows binaries, please? > > or where I can find them (I didn't find them in the latest tareball) > > I gave up with my cygwin: something wrong I have no idea what > java doesn't understand /cygwin/c syntax > after I changed makefile it did java part > but after that gcc 3.4.4 started to complain > I set buffer length to 999 lines but I didn't get beginning of the story > something wrong with my 1.4.2_09/include/jni.h gcc doesn't like it > anyway I gave up > > thanks in advance > Hi Dmitry The bins are here: ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7-bins-r2.zip Here are the files in the zip you want. Jar: rxtx-2.1-7-bins-r2/RXTXcomm.jar Windows: rxtx-2.1-7-bins-r2/Windows/i368-mingw32/rxtxSerial.dll Linux (x86) rxtx-2.1-7-bins-r2/Linux/i686-unknown-linux-gnu/librxtxSerial.so There are others in there including Parallel port support but those are the main ones for testing. -- Trent Jarvi tjarvi at qbang.org From dmarkman at mac.com Mon Mar 20 23:05:59 2006 From: dmarkman at mac.com (Dmitry Markman) Date: Tue, 21 Mar 2006 01:05:59 -0500 Subject: [Rxtx] binaries request In-Reply-To: References: <42702213-C222-4937-A585-7CFB17E47608@mac.com> Message-ID: thank you very much but windows's readme says: rxtxSerial.dll had to be recomopiled to link in missing native methods. should I ignore it? or what? thanks again also I understand that I should use mingw not cygwin I'll try to install mingw On Mar 21, 2006, at 12:36 AM, Trent Jarvi wrote: > On Tue, 21 Mar 2006, Dmitry Markman wrote: > >> Hi >> can somebody send me latest linux and windows binaries, please? >> >> or where I can find them (I didn't find them in the latest tareball) >> >> I gave up with my cygwin: something wrong I have no idea what >> java doesn't understand /cygwin/c syntax >> after I changed makefile it did java part >> but after that gcc 3.4.4 started to complain >> I set buffer length to 999 lines but I didn't get beginning of the >> story >> something wrong with my 1.4.2_09/include/jni.h gcc doesn't like it >> anyway I gave up >> >> thanks in advance >> > > Hi Dmitry > > The bins are here: > > ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7-bins-r2.zip > > Here are the files in the zip you want. > > Jar: > > rxtx-2.1-7-bins-r2/RXTXcomm.jar > > Windows: > > rxtx-2.1-7-bins-r2/Windows/i368-mingw32/rxtxSerial.dll > > Linux (x86) > > rxtx-2.1-7-bins-r2/Linux/i686-unknown-linux-gnu/librxtxSerial.so > > There are others in there including Parallel port support but those > are the main ones for testing. > > -- > Trent Jarvi > tjarvi at qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx Dmitry Markman From tjarvi at qbang.org Mon Mar 20 23:20:33 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 20 Mar 2006 23:20:33 -0700 (MST) Subject: [Rxtx] binaries request In-Reply-To: References: <42702213-C222-4937-A585-7CFB17E47608@mac.com> Message-ID: On Tue, 21 Mar 2006, Dmitry Markman wrote: > thank you very much > > but windows's readme says: > rxtxSerial.dll had to be recomopiled to link in missing native methods. > > should I ignore it? or what? > Hi Dmitry That dll should be OK. r2 is the recompile linked to the missing native method. The readme explains why it was recompiled; fuser.o was not linked into the dll in the first release. -- Trent Jarvi tjarvi at qbang.org From ariantristan at yahoo.com Mon Mar 20 23:55:24 2006 From: ariantristan at yahoo.com (Lambok Sianturi) Date: Mon, 20 Mar 2006 22:55:24 -0800 (PST) Subject: [Rxtx] jvm issue Message-ID: <20060321065524.94779.qmail@web50701.mail.yahoo.com> Hi All, This is my first time to join RxTx mailing list. I thank you all for allowing others to sign in in requests help. I use the latest RxTx lib in Fedora 3 with java version 1.4.2_09 b05. And I got this error: # # An unexpected error has been detected by HotSpot Virtual Machine: # # SIGSEGV (0xb) at pc=0x00bf27f3, pid=2633, tid=3086112448 # # Java VM: Java HotSpot(TM) Client VM (1.4.2_09-b05 mixed mode) # Problematic frame: # C [ld-linux.so.2+0xa7f3] # # An error report file with more information is saved as hs_err_pid2633.log # # If you would like to submit a bug report, please visit: # http://java.sun.com/webapps/bugreport/crash.jsp # ./run.sh: line 3: 2633 Aborted /usr/local/java/bin/java -Djava.library.path=/usr/local/java/jre/lib/ -Djsmsengine.debug=true -classpath jsmsengine.jar:smsgateway.jar:classes12.jar:RXTXcomm.jar:. com.api.sms.SMSServer What is the jvm depedency for the latest library? Can I use 1.4.2_09 b05? Thanks in advance. Arian --------------------------------- Yahoo! Mail Use Photomail to share photos without annoying attachments. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060320/83d58dd7/attachment-0008.html From f.frumento at ngi.it Tue Mar 21 00:21:47 2006 From: f.frumento at ngi.it (Fabio Frumento) Date: Tue, 21 Mar 2006 08:21:47 +0100 Subject: [Rxtx] Javadoc on the go Message-ID: <441FA98B.9050701@ngi.it> Hi Trent, sorry for the big delay but my job is running wild, i was out for some time but now i'm back and ready to continue the javadoc for Rxtx. Did you used the last javadoc patch i sent you ? let me know if i have to send it to you again or not. regards Fabio From lyon at docjava.com Tue Mar 21 00:51:18 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Tue, 21 Mar 2006 02:51:18 -0500 Subject: [Rxtx] lock files Message-ID: Hi All, You know, if the use of lock files were under Java control (rather than a build-time decision), it might enable a more unified binary distro. It might also facilitate quick prototyping of non-lock file approaches to resolving serial port contention issues (i.e., mac-like approaches vs. linux approaches, etc.). I realize that this is a radical overhaul of the lock file policy issue. Also, it may harm performance. On the other hand, our benchmarks on JNI overhead for modern processors indicate performance impact should be minimal. Perhaps it is more of an issue with the toybox systems. Suppose there were a class with a reasonable default...someone might write: SerialPortLockPolicy.setPolicy(SerialPortLockPolicy.UNIX_LOCK_FILE); SerialPortLockPolicy.setPolicy(SerialPortLockPolicy.NO_LOCK_CHECKING); SerialPortLockPolicy.setPolicy(SerialPortLockPolicy.MAC_STYLE); Thus, we could have a run-time reconfiguration of the serial port lock policy. A special NO_LOCK version of the binary would no longer be required. Any thoughts on this? Thanks! - Doug From joachim at buechse.de Tue Mar 21 03:09:09 2006 From: joachim at buechse.de (Joachim Buechse) Date: Tue, 21 Mar 2006 11:09:09 +0100 Subject: [Rxtx] lock files In-Reply-To: References: Message-ID: <8E12916A-1B9A-4FF2-B684-E2D1C794221B@buechse.de> This is pretty much what I thought about when I suggested, that the default behaviour could be overwritten with a property. I am very much in favor of this approach. In particular this allows much easier debugging for PC based java developers. I think big parts of the Java (and maybe some parts of the C code) could use a bit of a structural workover (unit tests, javadoc, synchronization, etc). Maybe there should be a CVS branch for this experimental version. I'd be happy to contribute a first workover for some of the Java code. Designing for testability and implementing a good bunch of unit tests has been a strategy that worked quite well in the Java projects I lead. And it ultimately allows more liberal change permission. Regards, Joachim On 21.03.2006, at 08:51, Dr. Douglas Lyon wrote: > Hi All, > You know, if the use of lock files were > under Java control (rather than a build-time decision), > it might enable a more unified binary distro. It might also > facilitate quick prototyping of non-lock file approaches > to resolving serial port contention issues (i.e., mac-like > approaches vs. linux approaches, etc.). > > I realize that this is a radical overhaul of the lock file policy > issue. Also, it may harm performance. On the other hand, > our benchmarks on JNI overhead for modern processors indicate > performance impact should be minimal. Perhaps it is more of > an issue with the toybox systems. > > Suppose there were a class with a reasonable default...someone > might write: > SerialPortLockPolicy.setPolicy(SerialPortLockPolicy.UNIX_LOCK_FILE); > SerialPortLockPolicy.setPolicy(SerialPortLockPolicy.NO_LOCK_CHECKING); > SerialPortLockPolicy.setPolicy(SerialPortLockPolicy.MAC_STYLE); > > Thus, we could have a run-time reconfiguration of the serial port lock > policy. A special NO_LOCK version of the binary would no longer > be required. > > Any thoughts on this? > > Thanks! > - Doug > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From joachim at buechse.de Tue Mar 21 06:23:08 2006 From: joachim at buechse.de (Joachim Buechse) Date: Tue, 21 Mar 2006 14:23:08 +0100 Subject: [Rxtx] PATCH: use of ioctl(fd, TIOCEXCL) instead of lockfiles Message-ID: <923AE774-EEA2-4911-92D8-32BB27802C8B@buechse.de> Here is the patch for the ioctl(fd, TIOCEXCL). I have verified this only for OSX 10.4.5, hence it is only defined for APPLE. However, it should work at least for Solaris as well. If a process has requested TIOEXCL further open calls by other user processes will fail. The patch also disables uucp style locking for APPLE. Obviously this is discussable. I think it is the way to go, as it eliminates creating the lock directory which doesnt exist on the standard installation and it eliminates messing with the system group definitions (adding users to group uucp). Regarding the possibility of root processes opening a device which is locked - I consider this a feature not a potential problem. It is highly unlikely, that somebody is crazy enough to run a JavaVM as root (unless he has no other means of getting a restricted IP port opened, ie doesnt understand ipfw). Anyway, even if the process runs as root, it fails when calling ioctl(fd, TIOCEXCL). It could however still open the port to listen for RING events. I.e. a fax server which needs to see incoming calls but otherwise doesnt want to block the port. So the only case where the proposed mechanism fails is, if an incorrectly implemented process running as root conflicts with a user process. I think this can be accepted. Regards, Joachim PS: If this patch is generally accepted, the installer and Mac doku should obviously be changed as well. Index: SerialImp.c =================================================================== RCS file: /usr/local/cvsroot/rxtx-devel/src/SerialImp.c,v retrieving revision 1.46.2.187 diff -u -r1.46.2.187 SerialImp.c --- SerialImp.c 29 Jan 2006 22:19:04 -0000 1.46.2.187 +++ SerialImp.c 21 Mar 2006 12:59:16 -0000 @@ -656,6 +656,25 @@ fd=OPEN (filename, O_RDWR | O_NOCTTY | O_NONBLOCK ); } while (fd < 0 && errno==EINTR); +#ifdef OPEN_EXCL + // Note that open() follows POSIX semantics: multiple open() calls to + // the same file will succeed unless the TIOCEXCL ioctl is issued. + // This will prevent additional opens except by root-owned processes. + // See tty(4) ("man 4 tty") and ioctl(2) ("man 2 ioctl") for details. + + if (fd >= 0 && (ioctl(fd, TIOCEXCL) == -1)) + { + sprintf( message, "open: exclusive access denied for % s\n", + filename ); + report( message ); + report_error( message ); + + close(fd); + goto fail; + } +#endif /* OPEN_EXCL */ + + if( configure_port( fd ) ) goto fail; (*env)->ReleaseStringUTFChars( env, jstr, filename ); sprintf( message, "open: fd returned is %i\n", fd ); Index: SerialImp.h =================================================================== RCS file: /usr/local/cvsroot/rxtx-devel/src/SerialImp.h,v retrieving revision 1.11.2.49 diff -u -r1.11.2.49 SerialImp.h --- SerialImp.h 5 Jul 2005 17:47:21 -0000 1.11.2.49 +++ SerialImp.h 21 Mar 2006 12:59:17 -0000 @@ -135,7 +135,8 @@ /*# define LOCKDIR "/var/spool/uucp"*/ # define LOCKDIR "/var/lock" # define LOCKFILEPREFIX "LK." -# define UUCP +/*# define UUCP*/ +# define OPEN_EXCL #endif /* __APPLE__ */ #if defined(__NetBSD__) # define DEVICEDIR "/dev/" From tjarvi at qbang.org Tue Mar 21 10:26:08 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 21 Mar 2006 10:26:08 -0700 (MST) Subject: [Rxtx] Javadoc on the go In-Reply-To: <441FA98B.9050701@ngi.it> References: <441FA98B.9050701@ngi.it> Message-ID: On Tue, 21 Mar 2006, Fabio Frumento wrote: > Hi Trent, > > sorry for the big delay but my job is running wild, i was out for some > time but now i'm back and ready to continue the javadoc for Rxtx. > > Did you used the last javadoc patch i sent you ? let me know if i have to > send it to you again or not. > > regards > > Fabio Hi Fabio The patch is in the rxtx mail-list archives. It will be going in soon. I did not see a time critical portion. I'll probably be going through the list since the last batch of patches this weekend and putting them into CVS. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Tue Mar 21 10:57:18 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 21 Mar 2006 10:57:18 -0700 (MST) Subject: [Rxtx] jvm issue In-Reply-To: <20060321065524.94779.qmail@web50701.mail.yahoo.com> References: <20060321065524.94779.qmail@web50701.mail.yahoo.com> Message-ID: On Mon, 20 Mar 2006, Lambok Sianturi wrote: > Hi All, > This is my first time to join RxTx mailing list. I thank you all for allowing others to sign in in requests help. > I use the latest RxTx lib in Fedora 3 with java version 1.4.2_09 b05. And I got this error: > > # > # An unexpected error has been detected by HotSpot Virtual Machine: > # > # SIGSEGV (0xb) at pc=0x00bf27f3, pid=2633, tid=3086112448 > # > # Java VM: Java HotSpot(TM) Client VM (1.4.2_09-b05 mixed mode) > # Problematic frame: > # C [ld-linux.so.2+0xa7f3] A native library loading error? What happens if you recompile rxtx on your system and install that? This sounds like an ABI problem? rxtx 2.1-7 was compiled with a gcc 2.96 toolchain as I recall. The hope is newer system will be backwards compatible. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Tue Mar 21 11:05:29 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 21 Mar 2006 11:05:29 -0700 (MST) Subject: [Rxtx] PATCH: use of ioctl(fd, TIOCEXCL) instead of lockfiles In-Reply-To: <923AE774-EEA2-4911-92D8-32BB27802C8B@buechse.de> References: <923AE774-EEA2-4911-92D8-32BB27802C8B@buechse.de> Message-ID: On Tue, 21 Mar 2006, Joachim Buechse wrote: > Here is the patch for the ioctl(fd, TIOCEXCL). I have verified this only > for OSX 10.4.5, hence it is only defined for APPLE. However, it should > work at least for Solaris as well. > > If a process has requested TIOEXCL further open calls by other user > processes will fail. > > The patch also disables uucp style locking for APPLE. Obviously this is > discussable. I think it is the way to go, as it eliminates creating the > lock directory which doesnt exist on the standard installation and it > eliminates messing with the system group definitions (adding users to > group uucp). > > Regarding the possibility of root processes opening a device which is > locked - I consider this a feature not a potential problem. It is highly > unlikely, that somebody is crazy enough to run a JavaVM as root (unless > he has no other means of getting a restricted IP port opened, ie doesnt > understand ipfw). Anyway, even if the process runs as root, it fails when > calling ioctl(fd, TIOCEXCL). It could however still open the port to > listen for RING events. I.e. a fax server which needs to see incoming > calls but otherwise doesnt want to block the port. So the only case where > the proposed mechanism fails is, if an incorrectly implemented process > running as root conflicts with a user process. I think this can be > accepted. > > Regards, > Joachim > > PS: If this patch is generally accepted, the installer and Mac doku > should obviously be changed as well. > > > Index: SerialImp.c > =================================================================== > RCS file: /usr/local/cvsroot/rxtx-devel/src/SerialImp.c,v > retrieving revision 1.46.2.187 > diff -u -r1.46.2.187 SerialImp.c > --- SerialImp.c 29 Jan 2006 22:19:04 -0000 1.46.2.187 > +++ SerialImp.c 21 Mar 2006 12:59:16 -0000 > @@ -656,6 +656,25 @@ > fd=OPEN (filename, O_RDWR | O_NOCTTY | O_NONBLOCK ); > } while (fd < 0 && errno==EINTR); > > +#ifdef OPEN_EXCL > + // Note that open() follows POSIX semantics: multiple open() > calls to > + // the same file will succeed unless the TIOCEXCL ioctl is > issued. > + // This will prevent additional opens except by root-owned > processes. > + // See tty(4) ("man 4 tty") and ioctl(2) ("man 2 ioctl") for > details. > + > + if (fd >= 0 && (ioctl(fd, TIOCEXCL) == -1)) > + { > + sprintf( message, "open: exclusive access denied for % > s\n", > + filename ); > + report( message ); > + report_error( message ); > + > + close(fd); > + goto fail; > + } > +#endif /* OPEN_EXCL */ > + > + > if( configure_port( fd ) ) goto fail; > (*env)->ReleaseStringUTFChars( env, jstr, filename ); > sprintf( message, "open: fd returned is %i\n", fd ); > Index: SerialImp.h > =================================================================== > RCS file: /usr/local/cvsroot/rxtx-devel/src/SerialImp.h,v > retrieving revision 1.11.2.49 > diff -u -r1.11.2.49 SerialImp.h > --- SerialImp.h 5 Jul 2005 17:47:21 -0000 1.11.2.49 > +++ SerialImp.h 21 Mar 2006 12:59:17 -0000 > @@ -135,7 +135,8 @@ > /*# define LOCKDIR "/var/spool/uucp"*/ > # define LOCKDIR "/var/lock" > # define LOCKFILEPREFIX "LK." > -# define UUCP > +/*# define UUCP*/ > +# define OPEN_EXCL > #endif /* __APPLE__ */ > #if defined(__NetBSD__) > # define DEVICEDIR "/dev/" > This looks like a good start. What do you think Dmitry? Perhaps all systems with TIOCEXCL defined should use that though. Even if they use lockfiles. It wont hurt anything. That would catch people hacking their own serial apps without checking lockfiles. Its a good idea to avoid C++ style comments in the C portions. Some older systems don't deal with them well. If it's just for Mac OS X, it isn't a big deal. I think it was the Irix compiler that was problematic? -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Tue Mar 21 11:22:05 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 21 Mar 2006 11:22:05 -0700 (MST) Subject: [Rxtx] lock files In-Reply-To: <8E12916A-1B9A-4FF2-B684-E2D1C794221B@buechse.de> References: <8E12916A-1B9A-4FF2-B684-E2D1C794221B@buechse.de> Message-ID: We can try it. Maybe the JNI is much improved. The nice thing about linking into liblock is distros then worry about lockfiles on their systems. This way, we have to deal with any changes that may show up. On Tue, 21 Mar 2006, Joachim Buechse wrote: > This is pretty much what I thought about when I suggested, that the > default behaviour could be overwritten with a property. I am very much in > favor of this approach. In particular this allows much easier debugging > for PC based java developers. > > I think big parts of the Java (and maybe some parts of the C code) could > use a bit of a structural workover (unit tests, javadoc, synchronization, > etc). Maybe there should be a CVS branch for this experimental version. > I'd be happy to contribute a first workover for some of the Java code. > Designing for testability and implementing a good bunch of unit tests has > been a strategy that worked quite well in the Java projects I lead. And > it ultimately allows more liberal change permission. > > Regards, > Joachim > > > On 21.03.2006, at 08:51, Dr. Douglas Lyon wrote: > >> Hi All, >> You know, if the use of lock files were >> under Java control (rather than a build-time decision), >> it might enable a more unified binary distro. It might also >> facilitate quick prototyping of non-lock file approaches >> to resolving serial port contention issues (i.e., mac-like >> approaches vs. linux approaches, etc.). >> >> I realize that this is a radical overhaul of the lock file policy >> issue. Also, it may harm performance. On the other hand, >> our benchmarks on JNI overhead for modern processors indicate >> performance impact should be minimal. Perhaps it is more of >> an issue with the toybox systems. >> >> Suppose there were a class with a reasonable default...someone >> might write: >> SerialPortLockPolicy.setPolicy(SerialPortLockPolicy.UNIX_LOCK_FILE); >> SerialPortLockPolicy.setPolicy(SerialPortLockPolicy.NO_LOCK_CHECKING); >> SerialPortLockPolicy.setPolicy(SerialPortLockPolicy.MAC_STYLE); >> >> Thus, we could have a run-time reconfiguration of the serial port lock >> policy. A special NO_LOCK version of the binary would no longer >> be required. >> >> Any thoughts on this? >> >> Thanks! >> - Doug >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From dmarkman at mac.com Tue Mar 21 16:05:17 2006 From: dmarkman at mac.com (Dmitry Markman) Date: Tue, 21 Mar 2006 18:05:17 -0500 Subject: [Rxtx] PATCH: use of ioctl(fd, TIOCEXCL) instead of lockfiles In-Reply-To: References: <923AE774-EEA2-4911-92D8-32BB27802C8B@buechse.de> Message-ID: <512AC70C-BB86-48F2-A83C-023F35C23BAB@mac.com> I think it's cool, but I'd like to have that property implementation when user can choose between locking mechanism about comments: it's easy to change comments to the C style or we can use extensions of the file to cpp so c++ compiler will be used On Mar 21, 2006, at 1:05 PM, Trent Jarvi wrote: > This looks like a good start. What do you think Dmitry? Perhaps > all systems with TIOCEXCL defined should use that though. Even if > they use lockfiles. It wont hurt anything. That would catch > people hacking their own serial apps without checking lockfiles. > > Its a good idea to avoid C++ style comments in the C portions. > Some older systems don't deal with them well. If it's just for Mac > OS X, it isn't a big deal. I think it was the Irix compiler that > was problematic? Dmitry Markman From dmarkman at mac.com Tue Mar 21 16:13:00 2006 From: dmarkman at mac.com (Dmitry Markman) Date: Tue, 21 Mar 2006 18:13:00 -0500 Subject: [Rxtx] PATCH: use of ioctl(fd, TIOCEXCL) instead of lockfiles In-Reply-To: References: <923AE774-EEA2-4911-92D8-32BB27802C8B@buechse.de> Message-ID: I'd like to add that creating locking folder isn't a big deal we never had a problem related to the lock folders, because we always used installer on mac os x from other hand I'm not very much familiar with iotcl locking approach and I'm not sure it's more efficient Joachim wrote "I think it is the way to go, as it eliminates creating the lock directory which doesnt exist on the standard installation and it eliminates messing with the system group definitions (adding users to group uucp)." but I really didn't have any problem with that 1. doesn't exist on the standard installation there are many-many things that don't exist in the standard installation so I don't think that argument is strong enough 2. messing with the system group definitions I don't think we're messing with the group definition mac os x provides very clear way to set up group's members and together with Greg Guerin AuthKit there is no problem to set those definitions so I don't think that argument is strong either but from other hand using iotcl is more promising and is more elegant On Mar 21, 2006, at 1:05 PM, Trent Jarvi wrote: > > This looks like a good start. What do you think Dmitry? Perhaps > all systems with TIOCEXCL defined should use that though. Even if > they use lockfiles. It wont hurt anything. That would catch > people hacking their own serial apps without checking lockfiles. Dmitry Markman From joachim at buechse.de Wed Mar 22 04:46:45 2006 From: joachim at buechse.de (Joachim Buechse) Date: Wed, 22 Mar 2006 12:46:45 +0100 Subject: [Rxtx] PATCH: use of ioctl(fd, TIOCEXCL) instead of lockfiles In-Reply-To: References: <923AE774-EEA2-4911-92D8-32BB27802C8B@buechse.de> Message-ID: Sorry, I was not very clear with my arguments, so I will try again;-) Please, don't take this as an attack against work that has been done. I think the contributions that have been made in the past were made in a good spirit. But I really believe, that the current solution for OSX has many shortcomings and should be changed as soon as possible. lock files --- The /var/lock folder does not exist on the standard OSX installation, however the standard installation includes several applications that use serial ports (i.e. the FAX capability). This indicates, that the lock folder approach will not work well with system components. Applications for OSX will generally try to live in harmony with system components (except for HP print drivers of course). I think RXTX should follow this approach as well. uucp group --- Accessing serial ports is not an admin privileged operation on OSX. Any user (world) has read/write privileges on /dev/tty*. So the system default is to not enforce any group membership to access these ports. The group uucp however is a system group on all unix systems I know. It exists for certain system processes. A non admin user should in general not be a member of this group. Quite arguably no user should ever be a member of this group. Installer --- My general opinion is, that - no Installer should touch user or group data without warning - no Application Installer should touch groups which are not specific to the very application installed - no Installer should ever add regular users to a system group The current installer injects the installing user in the group uucp without warning about this change and without giving the option to "opt out" of this change. This is a potential security risk (but not currently a real one, as OSX contains no folders belonging to group uucp). The current installer does not work for multi user systems. It puts the installing user in the uucp group. However the installing user is not necessarily the user that will use the application. Putting all users that may use a serial port application in the system group uucp seems like a very invasive approach to me. Besides that, newly created users will not automatically be in the group and hence, serial applications will "break" for new users without obvious reasons. Avoiding the lock files will allow self contained applications (i.e. drag&drop installation). In my eyes this is largely preferable over an installer that requests admin privileges. Adding up all these points indicates very strongly, that the lock-file implementation is not the way to go on OSX. Regards, Joachim On 22.03.2006, at 00:13, Dmitry Markman wrote: > I'd like to add that > > creating locking folder isn't a big deal > we never had a problem related to the lock folders, because we > always used installer on mac os x > from other hand I'm not very much familiar with iotcl locking > approach and I'm not sure it's more efficient > > Joachim wrote "I think it is the way to go, as it eliminates > creating the lock directory which doesnt exist on the standard > installation and it eliminates messing with the system group > definitions (adding users to group uucp)." but I really didn't have > any problem with that > > 1. doesn't exist on the standard installation > there are many-many things that don't exist in the standard > installation so I don't think that argument is strong enough > 2. messing with the system group definitions > I don't think we're messing with the group definition > mac os x provides very clear way to set up group's members and > together with Greg Guerin AuthKit there is no problem to set those > definitions > so I don't think that argument is strong either > but from other hand using iotcl is more promising and is more elegant > > > > On Mar 21, 2006, at 1:05 PM, Trent Jarvi wrote: > >> >> This looks like a good start. What do you think Dmitry? Perhaps >> all systems with TIOCEXCL defined should use that though. Even if >> they use lockfiles. It wont hurt anything. That would catch >> people hacking their own serial apps without checking lockfiles. > > Dmitry Markman > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From dmarkman at mac.com Wed Mar 22 05:27:13 2006 From: dmarkman at mac.com (Dmitry Markman) Date: Wed, 22 Mar 2006 07:27:13 -0500 Subject: [Rxtx] PATCH: use of ioctl(fd, TIOCEXCL) instead of lockfiles In-Reply-To: References: <923AE774-EEA2-4911-92D8-32BB27802C8B@buechse.de> Message-ID: <83440CF3-DCD8-41C1-B941-F227232C27E3@mac.com> thanks for the very good explanation I didn't think that you were attacking any thing, so don't worry I just had feeling, that there were more aesthetic reasons for going to ioctl then real necessity now you explained everything quite well (BTW, asfar as I remember installer asks admin password so it wasn't quiet, but it really doesn't matter now) thanks On Mar 22, 2006, at 6:46 AM, Joachim Buechse wrote: > Sorry, I was not very clear with my arguments, so I will try again;-) > > Please, don't take this as an attack against work that has been > done. I think the contributions that have been made in the past > were made in a good spirit. But I really believe, that the current > solution for OSX has many shortcomings and should be changed as > soon as possible. > > lock files > --- > The /var/lock folder does not exist on the standard OSX > installation, however the standard installation includes several > applications that use serial ports (i.e. the FAX capability). This > indicates, that the lock folder approach will not work well with > system components. Applications for OSX will generally try to live > in harmony with system components (except for HP print drivers of > course). I think RXTX should follow this approach as well. > > uucp group > --- > Accessing serial ports is not an admin privileged operation on OSX. > Any user (world) has read/write privileges on /dev/tty*. So the > system default is to not enforce any group membership to access > these ports. The group uucp however is a system group on all unix > systems I know. It exists for certain system processes. A non admin > user should in general not be a member of this group. Quite > arguably no user should ever be a member of this group. > > Installer > --- > My general opinion is, that > - no Installer should touch user or group data without warning > - no Application Installer should touch groups which are not > specific to the very application installed > - no Installer should ever add regular users to a system group > > The current installer injects the installing user in the group uucp > without warning about this change and without giving the option to > "opt out" of this change. This is a potential security risk (but > not currently a real one, as OSX contains no folders belonging to > group uucp). > > The current installer does not work for multi user systems. It puts > the installing user in the uucp group. However the installing user > is not necessarily the user that will use the application. Putting > all users that may use a serial port application in the system > group uucp seems like a very invasive approach to me. Besides that, > newly created users will not automatically be in the group and > hence, serial applications will "break" for new users without > obvious reasons. > > > Avoiding the lock files will allow self contained applications > (i.e. drag&drop installation). In my eyes this is largely > preferable over an installer that requests admin privileges. Adding > up all these points indicates very strongly, that the lock-file > implementation is not the way to go on OSX. > > Regards, > Joachim > > > On 22.03.2006, at 00:13, Dmitry Markman wrote: > >> I'd like to add that >> >> creating locking folder isn't a big deal >> we never had a problem related to the lock folders, because we >> always used installer on mac os x >> from other hand I'm not very much familiar with iotcl locking >> approach and I'm not sure it's more efficient >> >> Joachim wrote "I think it is the way to go, as it eliminates >> creating the lock directory which doesnt exist on the standard >> installation and it eliminates messing with the system group >> definitions (adding users to group uucp)." but I really didn't >> have any problem with that >> >> 1. doesn't exist on the standard installation >> there are many-many things that don't exist in the standard >> installation so I don't think that argument is strong enough >> 2. messing with the system group definitions >> I don't think we're messing with the group definition >> mac os x provides very clear way to set up group's members and >> together with Greg Guerin AuthKit there is no problem to set those >> definitions >> so I don't think that argument is strong either >> but from other hand using iotcl is more promising and is more elegant >> >> >> >> On Mar 21, 2006, at 1:05 PM, Trent Jarvi wrote: >> >>> >>> This looks like a good start. What do you think Dmitry? Perhaps >>> all systems with TIOCEXCL defined should use that though. Even >>> if they use lockfiles. It wont hurt anything. That would catch >>> people hacking their own serial apps without checking lockfiles. >> >> Dmitry Markman >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx Dmitry Markman From lyon at docjava.com Wed Mar 22 06:12:18 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Wed, 22 Mar 2006 08:12:18 -0500 Subject: [Rxtx] sole of a new design pattern Message-ID: Hi All, I have been thinking about how we design the serial port software. I think we need a new design pattern. For lack of a better term, I shall call it: The Parametric Singleton Design Pattern By Douglas A. Lyon ABSTRACT The goal of the singleton design pattern is to make sure that there is one, and only one, instance of a given class. The goal of the parametric singleton design pattern is to make sure that there is one, and only one, instance of a given class with the given parametric values. We parametric singleton design pattern combines the singleton design pattern with a parameter that enables unique creation of instances of a class. These instances are cached. When a user asks for an instance with these parameters, the cache is checked. If the instance is in the cache, the instance is returned, otherwise it is created, added to the cache and then returned. We apply our parametric singleton design pattern to the retrieval of RMI registries bound to a given port. The goal of our system is to make sure that no two RMI registries are listening to the same socket and to make use of the RMI registries after they have been created. RMI registries are used in distributed computation. Introduction The singleton design pattern is meant to ensure that on a single instance of a class exists. It is also meant to provide a global point of access to it. The intent of the parametric singleton design pattern is to ensure that a class has only one instance for a given set of parameter values. It also provides a global point of access to it. Motivation A system cannot tolerate multiple instances of some classes with identical parameters. For example, you cannot have two instances making use of the same serial port, at the same time. You cannot have two instances that are trying to listen to the same socket connection. You cannot have two instances writing to the same file structure at the same time. As the operating system is often thought of as the arbiter of consumed resources (i.e., tape drives, serial ports, etc.) we frequently leave it to an operating system implementation to resolve these contention issues. Even for similar resources (like serial ports) there are few standards for handling contention. For example, serial ports on Linux are locked using a "/var/lock" file. POSIX, on the other hand, uses ioctl mechanisms to prevent contention. A better solution is to make a class that is responsible for keeping track of the instances created from the class. The class is declared final, so that it cannot be subclassed. The class also has a private constructor, so that other classes cannot instance it. The new design pattern is called the parametric singleton design pattern and it provides a way to access and create instances with given parameters. Applicability Use the Parametric Singleton Design Pattern when: 1. There must be exactly one instance of a class with the given parameters. 2. The instances must be accessible to clients from a well-known access point. Structure Insert UML diagram here. Participants The Parametric Singleton Clients that need instances 1. The Parametric Singleton defines an instance upon request from a client, if, and only if, the instance does not already exist. 2. The Parametric Singleton returns the instance to the client. 3. The Parametric Singleton is responsible for creating unique instances from given parameters. Collaborations Clients obtain a reference to a Parametric Singleton instance only through the parametric singleton design pattern. If the instance is left in an improper state (e.g., the serial port was left open) it is NOT the role of the Parametric Singleton Design Pattern to close the IO port. Nor is it the role of the Parametric Singleton Design Pattern to open the port. That role is delegate to some other part of the system. Further, it is not the role of the Parametric Singleton Design Pattern to check out resources. That is, multiple threads can have multiple references to the same resource at the same time. MUTEX locking is delegated to some other part of the system. Consequences The Parametric Singleton Design Pattern has several benefits: 1. Controlled access to parametrically defined instances. Since the Parametric Singleton class encapsulates its instances, there is control over how and when clients access it. 2. Reduced name space. The Parametric Singleton pattern avoids global variables that store instances created from the same parameter. Implementation Here are implementation issues to consider when using the Parametric Singleton pattern: 1. Unique mapping of parameters. The Parametric Singleton pattern requires that there be a mean to isomorphically map the parameter space into the instance space and back again. 2. Ensure unique instances. The Parametric Singleton pattern makes unique instances from parameters, and it does so only once. 3. Cache instances for fast retrieval. The Parametric Singleton pattern must be able to look up instances, given some set of parameters, and do so from some data structure. That is, there must be enough space to hold references to all the instances the program will need. Also, a mechanism is needed to look up and retrieve the instances quickly enough to satisfy the clients. Sample Code public final class ParametricSingletonRmiRegistry { private static Hashtable registry = new Hashtable(100); // use singleton pattern and??????????????????????????????????????????????? // prevent instantiation of RmiRegistryUtils.?????????????????????????????? private ParametricSingletonRmiRegistry() { } // the only instance of the Registry held by the RmiRegistryUtils?????????? public static void listNames(Integer port) { if (!isInCacheAndRunning(port)) return; Registry r = (Registry) registry.get(port); System.out.println("registry on port: " + port); System.out.println("registry: " + r); System.out.println("names: "); try { print(r.list()); } catch (RemoteException e) { In.message(e); } System.out.println("------------------------"); } /**???????????????????????????????????????????????????????????????????????? * Checks whether a Registry has been started on this host????????????????? * in the specified port.?????????????????????????????????????????????????? * If not, it tries to start one.?????????????????????????????????????????? * when it fails to start a Registry, it exits the program????????????????? * with exit code 1.??????????????????????????????????????????????????????? */ public static void restart(int port) { if (isInCacheAndRunning(port)) return; try { startRegistry(port); } catch (RemoteException e) { In.message(e); } } /**???????????????????????????????????????????????????????????????????????? * @param port????????????????????????????????????????????????????????????? * @return true if registry is in cache and running???????????????????????? */ private static boolean isInCacheAndRunning(Integer port) { if (!isRegistryRunning(port.intValue())) return false; if (!isRegistryInCache(port.intValue())) return false; return true; } /**???????????????????????????????????????????????????????????????????????? * @param port????????????????????????????????????????????????????????????? * @return true if we are able to locate a local registry on port.??????????????????????????????????????????????????????????????????????????? */ private static boolean isRegistryRunning(int port) { try { Registry r = LocateRegistry.getRegistry(port); if (r != null) return true; } catch (RemoteException e) { return false; } return false; } /**???????????????????????????????????????????????????????????????????????? * @param port????????????????????????????????????????????????????????????? * @return return true if registry is in cache????????????????????????????? */ private static boolean isRegistryInCache(int port) { if (registry.get(new Integer(port)) == null) return false; return true; } /**???????????????????????????????????????????????????????????????????????? * Restart the registry, if needed.???????????????????????????????????????? * Return the only instance of the registry for consistent global?????????? * using by making use of the Singleton Design Pattern????????????????????? *????????????????????????????????????????????????????????????????????????? * @return the internally held registry instance.?????????????????????????? */ public static Registry getRegistry(Integer port) { restart(port); return (Registry) registry.get(port); } private static void startRegistry(Integer port) throws RemoteException { Registry r; try { r = LocateRegistry.createRegistry(port.intValue()); registry.put(port, r); //r = new sun.rmi.registry.RegistryImpl???????????????????????????? /// (port.intValue());?????????????????????????????????????? // registry.put(port, r);?????????????????????????????????????????? } catch (Exception e) { //e.printStackTrace();????????????????????????????????????????????? r = LocateRegistry.getRegistry(port.intValue()); registry.put(port, r); } } public static void main(String args[]) throws RemoteException { //restart(port);??????????????????????????????????????????????????????? restart(5001); restart(5002); restart(5002); Registry r = LocateRegistry.getRegistry(5002); System.out.println("registry="+r); } } I would very much like to get your feedback on this new design pattern idea. Thank you for your time. Regards, - Doug From david.garnier at trusted-logic.com Wed Mar 22 07:36:10 2006 From: david.garnier at trusted-logic.com (David Garnier) Date: Wed, 22 Mar 2006 15:36:10 +0100 Subject: [Rxtx] sole of a new design pattern In-Reply-To: References: Message-ID: <442160DA.80107@trusted-logic.com> Hello, > The Parametric Singleton Design Pattern The Singleton is the most abused design pattern ever. Good use-cases for this pattern are extremely rare and mostly confined to problems related to hardware resources, like serial ports. > Applicability > > Use the Parametric Singleton Design Pattern when: > 1. There must be exactly one instance of a class with the given > parameters. OK. As I said above, this case this actually very unusual. The Singleton pattern is mostly used when : > 2. The instances must be accessible to clients from a well-known > access point. Using the singleton pattern in this case is just convenient for the programmer. Problems arises pretty quickly, especially if you attempt to unit-test your classes. 1) If your singleton is stateful, or hold on to stateful objects, it means that two different unit tests are not actually independent. Instead of starting with a brand new environment, the result of a test may be affected by the result of a previous test. This problem also arise when with your class relies on a database. In both cases, the solution is to reset your "unique" resource (Singleton or database) at the beginning of the test, which is a pain. Also, while most projects connect to a single database, projects that allow the use of Singletons usually contain several of thems, and new ones may cropped up unnoticed. You quickly end up with test cases that only pass in a certain order, which is a royal pain. 2) You cannot mockup a singleton. Once everyone calls the SomeSingleton class statically, you can't replace your class by SomeSingletonMockup. Furthermore, even for hardware services, the Singleton pattern does not really prevent concurrent accesses. If you start the same program in two different JVMs, unless they somehow shared the state of their "Singletons" (through lock files for example), the Singleton pattern will not prevent concurrent access. Our application uses RXTX, and we routinely encounter cases where another (native) application has already locked the port. Since we cannot modify the native application to recognize lock files, OS-level control is irreplaceable. > > Consequences > The Parametric Singleton Design Pattern has several benefits: > > 1. Controlled access to parametrically defined instances. Since > the Parametric Singleton class encapsulates its instances, there is > control over how and when clients access it. Not really. Once you've returned the instance to a client, you've lost control over it. The client can to whatever it wants with it. You cannot "recall" the instance or claim it back. > 2. Reduced name space. The Parametric Singleton pattern avoids > global variables that store instances created from the same parameter. Sure, but you don't have to rely on a Singleton for that. Just create a single Factory. > I would very much like to get your feedback on this new design > pattern idea. Well, it's nothing new. Some may say that it is the point of design patterns: formalizes the designs that occur again and again. However, this design is simply a combination of the Singleton and Factory patterns. I did use it in the past, but now I've been exposed to the shortcomings of the Singleton pattern, so I limit myself to Factories. Regards, David From sean_montgomery at baseview.com Wed Mar 22 08:35:28 2006 From: sean_montgomery at baseview.com (Sean Montgomery) Date: Wed, 22 Mar 2006 10:35:28 -0500 Subject: [Rxtx] sole of a new design pattern In-Reply-To: <442160DA.80107@trusted-logic.com> References: <442160DA.80107@trusted-logic.com> Message-ID: <05769CA7-A51B-4CF0-BAA0-E02DD905F5A4@baseview.com> On Mar 22, 2006, at 9:36 AM, David Garnier wrote: > Furthermore, even for hardware services, the Singleton pattern does > not really prevent concurrent > accesses. If you start the same program in two different JVMs, > unless they somehow shared the state > of their "Singletons" (through lock files for example), the > Singleton pattern will not prevent > concurrent access. > Multiple class loaders in a single JVM can be tricky, too. Then there's synchronization, lazy initialization and serialization of singletons to contend with. Bloch's Effective Java covers these, and here's a few articles: http://www.javaworld.com/javaworld/jw-04-2003/jw-0425-designpatterns- p3.html http://java.sun.com/developer/technicalArticles/Programming/singletons/ Just FYI :-) From lyon at docjava.com Wed Mar 22 08:50:48 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Wed, 22 Mar 2006 10:50:48 -0500 Subject: [Rxtx] sole of a new design pattern In-Reply-To: <442160DA.80107@trusted-logic.com> References: <442160DA.80107@trusted-logic.com> Message-ID: Hi All, First, I would like to thank David for his prompt and thoughtful remarks. I had no idea people that feel strongly about a design patterns! Wow! Feedback (particularly critical feedback) is greatly appreciated. Starting at the end, first: >I did use it in >the past, but now I've been exposed to the shortcomings of the >Singleton pattern, so I limit myself to Factories. David, if I understood your comments correctly, you suggested that Factories can be used in leu of the Singleton Design Pattern, or even the Parametric Singleton Design Pattern. As I see in [Gof]: Factory Method: Intent "Define an interface for creating an object, but let subclasses decide which class to instantiate. Factory Method lets a class defer instantiation to subclasses." The Singleton Design Pattern is a concrete class, which is rather different, right? Also, subclasses are not permitted with Singleton, as they are final. Naturally, I could use an abstract factory as a parent for a singleton. I could even design a facade that could be implemented with the singleton....but that is not the intention of the design. Unless you want a mock-up, as discussed, below: More below: >Hello, > >> The Parametric Singleton Design Pattern > >The Singleton is the most abused design pattern ever. Good use-cases >for this pattern are extremely >rare and mostly confined to problems related to hardware resources, >like serial ports. > > >> Applicability >> >> Use the Parametric Singleton Design Pattern when: >> 1. There must be exactly one instance of a class with the given >> parameters. >OK. As I said above, this case this actually very unusual. The >Singleton pattern is mostly used when : >> 2. The instances must be accessible to clients from a well-known >> access point. > >Using the singleton pattern in this case is just convenient for the >programmer. Problems arises >pretty quickly, especially if you attempt to unit-test your classes. > >1) If your singleton is stateful, or hold on to stateful objects, it >means that two different unit >tests are not actually independent. Instead of starting with a brand >new environment, the result of >a test may be affected by the result of a previous test. This >problem also arise when with your >class relies on a database. In both cases, the solution is to reset >your "unique" resource >(Singleton or database) at the beginning of the test, which is a >pain. Also, while most projects >connect to a single database, projects that allow the use of >Singletons usually contain several of >thems, and new ones may cropped up unnoticed. You quickly end up >with test cases that only pass in a >certain order, which is a royal pain. There are basic problems with communicating finite state machines that include reachability and deadlock analysis. These are addressed with petri net analysis and are beyond the scope of the design pattern. As you quite rightly pointed out; the parametric singleton pattern (or the singleton pattern, for that matter) enable multiple threads to gain access to the same instance. The only way that I can see to block others from gaining access to the reference is the synchronize keyword. This is putting a spin-lock (or MUTEX) on the reference. The question of how to unit-test a design pattern like the parametric singleton remains open. Perhaps this is a deficiency. > >2) You cannot mockup a singleton. Once everyone calls the >SomeSingleton class statically, you can't >replace your class by SomeSingletonMockup. Acutally, I am not sure that this is true. If the Singleton implements a Facade interface, it should be possible to make the replacement. Right? > >Furthermore, even for hardware services, the Singleton pattern does >not really prevent concurrent >accesses. If you start the same program in two different JVMs, >unless they somehow shared the state >of their "Singletons" (through lock files for example), the >Singleton pattern will not prevent >concurrent access. Good Point!! You have sharp eyes! The singleton design pattern should/could take responsibility for this. In fact, you may notice that my code does have an implementation (LocateRegistry) that can work across JVM's. The LocateRegistry will even work across the Internet! LocateRegistry takes both a host name and a Port (lock files just don't do this). I did not think to implement this beyond the local machine, but, in its present form, it will work across different processes. > >Our application uses RXTX, and we routinely encounter cases where >another (native) application has >already locked the port. Since we cannot modify the native >application to recognize lock files, >OS-level control is irreplaceable. The singleton design pattern is not meant to replace OS-level control, but to centralize the Java programmers access to it. If lock files, for example, are used for serial ports, the Singleton Design Pattern should be able to work with them. > > >> >> Consequences >> The Parametric Singleton Design Pattern has several benefits: >> > > 1. Controlled access to parametrically defined instances. Since >> the Parametric Singleton class encapsulates its instances, there is >> control over how and when clients access it. > >Not really. Once you've returned the instance to a client, you've >lost control over it. The client >can to whatever it wants with it. You cannot "recall" the instance >or claim it back. Good point, this should read: > 1. Controll when parametrically defined instances are created. Since > > the Parametric Singleton class encapsulates its instances, there is > > control over how and when they are instanced. > >> 2. Reduced name space. The Parametric Singleton pattern avoids >> global variables that store instances created from the same parameter. > >Sure, but you don't have to rely on a Singleton for that. Just >create a single Factory. > > Thank you for your thoughtful and prompt response! Regards, - Doug From dmarkman at mac.com Wed Mar 22 21:21:55 2006 From: dmarkman at mac.com (Dmitry Markman) Date: Wed, 22 Mar 2006 23:21:55 -0500 Subject: [Rxtx] sole of a new design pattern In-Reply-To: <442160DA.80107@trusted-logic.com> References: <442160DA.80107@trusted-logic.com> Message-ID: I don't think I get it On Mar 22, 2006, at 9:36 AM, David Garnier wrote: > Using the singleton pattern in this case is just convenient for the > programmer. Problems arises > pretty quickly, especially if you attempt to unit-test your classes. so you're saying that something isn't so good because you can not test it in the convenient way? if that's true, I'm totally disagree change your test, debug whatever, but if software is efficient at runtime, works fine and only problem is some unit test (which is some kind of framework for testing) then dump that unit test , dump that unit framework and make something appropriate to the software you're testing so if Douglas want to use singletons, what's the problem? and what do you mean by abusing of singleton usage? of course singleton doesn't prevent concurrent access to the resource across the processes unless you're using some OS facility to prevent it, besides singleton as it was introduced is relevant only and only inside of the same process otherwise it's not singleton it's something else (let's say network singleton: so you have remote invocation facility and some factory method that return object created by that facility) I don't have any problem with using any kind of singletons. Parametric Singleton idea (if I understand it right) could be easily implemented in the following way: use a map populate map with instances of some class and key is your parameter (you can use lazy population too) if somebody ask the key check the value if it's null so resource is taken if somebody returns the resource put it back to the map public synchronized static Object getSomeResource(Object parameter); public synchronized static void returnResource(Object parameter); getSomeResource (inside of the same process) could return null in 2 cases 1. if somebody (from other thread for example) already took that resource 2. if OS API said that resource corresponded to that parameter (serial port with parameter = 1 (port #)) is locked and unavailable; I'm not sure that in case of serial ports we even need those Parametric Singletons (unless lock checking is a very expensive operation) just ask the OS about availability of that resource and if it's available give it away and then OS will lock it and therefore in next time somebody ask it just answer that resource is locked and return null for example system has 2 serial ports available so I ask getResource("tty"); or I ask getResource("Bluetooth-Modem"); and if OS is ok you can give tty or Bluetooth-Modem or both no need for any additional pattern I think back to the problem mac os x doesn't recognize locking via files, so it handles locking via some API an instance of the singleton in each process should recognize that resource is locked (by using that API) that's all we don't have to make things more complicate then they are just because there is some nice design pattern or nice unit test framework or whatever keep things simple, make them work fast, don't introduce middle layers unless you have really good reason to do so of course I could be entirely wrong, so sorry about that in advance thanks Dmitry Markman From tjarvi at qbang.org Wed Mar 22 22:31:41 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 22 Mar 2006 22:31:41 -0700 (MST) Subject: [Rxtx] sole of a new design pattern In-Reply-To: References: Message-ID: Hi Doug Interesting reading. So far I'm just reading and thinking. I have one question so far. " Clients obtain a reference to a Parametric Singleton instance only through the parametric singleton design pattern. If the instance is left in an improper state (e.g., the serial port was left open) it is NOT the role of the Parametric Singleton Design Pattern to close the IO port. Nor is it the role of the Parametric Singleton Design Pattern to open the port. That role is delegate to some other part of the system. " So when the clients obtain a reference to the singleton, can they assume the port is there? IE, would it be the singletons role to handle things like USB dongles being removed with event hints comming from the underlying OS. Hardware abstraction layer/HAL on Linux is an example of underlying OS events. I assume that role too is delegated to other parts of the system? -- Trent Jarvi tjarvi at qbang.org From lyon at docjava.com Thu Mar 23 08:10:33 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Thu, 23 Mar 2006 10:10:33 -0500 Subject: [Rxtx] Classes don't need goals, they need roles! In-Reply-To: References: Message-ID: Hi Trent, Yes, I think that the role of the Parametric Singleton Pattern is not to open or close serial ports, nor is it to perform error checking. On the other hand, if you were to combine the role of the Parametric Singleton Pattern with another role (like that of error checking) it might not be amiss. However, I generally caution programmers against adding multiple roles to classes, as this leads to monolithic designs. Thus a different class (NativeLibDetect) could have the role of determining if the native library can be loaded. Another class (SerialPortBean) can have the role of serializing the default state of the serial port, so that it can be recovered, from user preferences, at a later time. The SerialPortDetect could have the role of determining if the serial port is removed (i.e., a USB port was unplugged). My guess is that each class should have a different role in the system, in order to ease maintenance and testing...but I could be wrong about that. Thanks! - Doug >Hi Doug > >Interesting reading. So far I'm just reading and thinking. I have >one question so far. > >" > Clients obtain a reference to a Parametric Singleton instance only >through the parametric singleton design pattern. If the instance is >left in an improper state (e.g., the serial port was left open) it is >NOT the role of the Parametric Singleton Design Pattern to close the >IO port. Nor is it the role of the Parametric Singleton Design Pattern >to >open the port. That role is delegate to some other part of the system. >" > >So when the clients obtain a reference to the singleton, can they >assume the port is there? IE, would it be the singletons role to >handle things like USB dongles being removed with event hints >comming from the underlying OS. Hardware abstraction layer/HAL on >Linux is an example of underlying OS events. > >I assume that role too is delegated to other parts of the system? > >-- >Trent Jarvi >tjarvi at qbang.org >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From maximulo at yahoo.com Fri Mar 24 01:22:38 2006 From: maximulo at yahoo.com (Maximulo Majir) Date: Fri, 24 Mar 2006 00:22:38 -0800 (PST) Subject: [Rxtx] JavaPOS Message-ID: <20060324082238.66371.qmail@web38214.mail.mud.yahoo.com> Hi all! Hello Trent! From what i understand, RXTX or JavaComm APIs were not created solely for JavaPOS. In JavaPOS, we have the virtual method claim() which is separate from open(), but in our RXTX API, claiming is done every call to open(), we cant open the port if its claimed by another application. Would it be alright to suggest or ask to create a new method called claim(..)? Is there such thing as forceclaim() in RXTX? this could be the same as portownership transfer or its equivalent. ForceClaim is in JSR80. Do you have some samples using RXTX as the lower layer for the Device Service Objects in JavaPOS? I have tried it, i just want to compare. Thank you all! maxim __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060324/496adba2/attachment-0008.html From tjarvi at qbang.org Fri Mar 24 11:28:19 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 24 Mar 2006 11:28:19 -0700 (MST) Subject: [Rxtx] Re: RXTX 2.1 Solaris Problems In-Reply-To: <3691.1143210578@www045.gmx.net> References: <3691.1143210578@www045.gmx.net> Message-ID: On Fri, 24 Mar 2006, Andreas Guenther wrote: > Hi all, > > the solaris problem was not the lock file only. > > Ok, I had to create the directory /var/spool/locks myself. > /var/spool/uucp exists. > > But rxtx didn't find any port. > > I compiled the source with my own debug-informations > and I tried to isolate the problem. > > The problem is the testRead-call in SerialImp.c > > JNIEXPORT jboolean JNICALL RXTXCommDriver(testRead)( > > ... > if ( READ( fd, &c, 1 ) < 0 ) > { > if ( errno != EAGAIN ) { > report( "testRead() read failed\n" ); > ret = JNI_FALSE; > } > } > Thanks Andreas I'm packing up to move. I'll be more or less away for a couple weeks here. I'll be checking email but my workstation is going into a box soon. This isn't hard to fix as this port should be enumerated when EWOULDBLOCK is recieved. Thats error is OK for enumeration just as EAGAIN is. I've put the bug into bugzilla so we dont forget to get to it. http://bugzilla.qbang.org/show_bug.cgi?id=42 You can add yourself to the CC list if you wish to test fixes we provide or even put a patch into bugzilla yourself. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Fri Mar 24 11:51:52 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 24 Mar 2006 11:51:52 -0700 (MST) Subject: [Rxtx] JavaPOS In-Reply-To: <20060324082238.66371.qmail@web38214.mail.mud.yahoo.com> References: <20060324082238.66371.qmail@web38214.mail.mud.yahoo.com> Message-ID: On Fri, 24 Mar 2006, Maximulo Majir wrote: > Hi all! Hello Trent! > > > From what i understand, RXTX or JavaComm APIs were not > created solely for JavaPOS. In JavaPOS, we have the virtual method > claim() which is separate from open(), but in our RXTX API, claiming is > done every call to open(), we cant open the port if its claimed by > another application. Would it be alright to suggest or ask to create a > new method called claim(..)? Is there such thing as forceclaim() in > RXTX? this could be the same as portownership transfer or its > equivalent. ForceClaim is in JSR80. > Do you have some samples using RXTX as the lower layer for the Device > Service Objects in JavaPOS? I have tried it, i just want to compare. > maxim Hi Maxim JSR80 is the USB API IBM/Sun put together. The problem is they have a richer kernel/API underneath that can handle such things. With Serial Ports, there isnt anything there other than an ioctl that says don't let anyone touch this and lockfiles that are more of a 'lets be nice.' At times we may be using USB ports but it is through the termios layer with the limitations mentioned. The advantage is that not only USB will work with rxtx. Anything that has a termios layer should work (to the extent that termios layer is complete). I don't know how forceclaim() would help you. Lets say someone has a programmer working on /dev/ttyS0 and you take it. Now you both race each other to read data first. There isn't a mechanism I know of that will solve this problem in termios. The most obvious test being a native app and a Java app trying to take the port. There is the potential of requestion ownership from other Java Applications but the use for that is very rare. Did you have something more specific in mind that I'm missing? I'm not sure that claim() and forceclaim() would help you with rxtx other than maybe locking the port with claim() without opening it. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sat Mar 25 23:42:08 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 25 Mar 2006 23:42:08 -0700 (MST) Subject: [Rxtx] Serial snoop Message-ID: I was reading the Linux kernel mail-list tonight and ran past a thread that mentioned sersnoop. This looks like a handy tool for people dealing with new toys. "a simple command-line tool for linux that echoes bytes to and from any two serial ports, ptys, or network sockets, and prints all traffic to stdout, in hex and ascii." http://www.restivo.org/projects/sersnoop/ It works on Linux only at this time (debian package available). -- Trent Jarvi tjarvi at qbang.org From beat.arnet at gmail.com Sun Mar 26 07:32:35 2006 From: beat.arnet at gmail.com (Beat Arnet) Date: Sun, 26 Mar 2006 09:32:35 -0500 Subject: [Rxtx] Error 0x5 at /home/bob/foo/tar/rxtx-2.1-7/build/../src/termios.c(860): Access is, denied. Message-ID: <4426A603.80508@gmail.com> Dear all, When trying to open the serial port, I sometimes (not always) run into the following exception (when opening the serialPort): Error 0x5 at /home/bob/foo/tar/rxtx-2.1-7/build/../src/termios.c(860): Access is denied. java.lang.UnsatisfiedLinkError: native_psmisc_report_owner at gnu.io.CommPortIdentifier.native_psmisc_report_owner(Native Method) at gnu.io.CommPortIdentifier.open(CommPortIdentifier.java:354) at codeskin.tools.CLLoader.open(CLLoader.java:79) at codeskin.tools.C2000Programmer.run(C2000Programmer.java:220) at java.lang.Thread.run(Unknown Source) Is this the type of error where I should just try to open the port again, or can it be avoided? Regards, Beat From tjarvi at qbang.org Sun Mar 26 11:40:12 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 26 Mar 2006 11:40:12 -0700 (MST) Subject: [Rxtx] Error 0x5 at /home/bob/foo/tar/rxtx-2.1-7/build/../src/termios.c(860): Access is, denied. In-Reply-To: <4426A603.80508@gmail.com> References: <4426A603.80508@gmail.com> Message-ID: On Sun, 26 Mar 2006, Beat Arnet wrote: > Dear all, > > When trying to open the serial port, I sometimes (not always) run into > the following exception (when opening the serialPort): > > Error 0x5 at /home/bob/foo/tar/rxtx-2.1-7/build/../src/termios.c(860): > Access is > denied. > > java.lang.UnsatisfiedLinkError: native_psmisc_report_owner > at gnu.io.CommPortIdentifier.native_psmisc_report_owner(Native > Method) > at gnu.io.CommPortIdentifier.open(CommPortIdentifier.java:354) > at codeskin.tools.CLLoader.open(CLLoader.java:79) > at codeskin.tools.C2000Programmer.run(C2000Programmer.java:220) > at java.lang.Thread.run(Unknown Source) > > Is this the type of error where I should just try to open the port again, > or can it be avoided? > Hi Beat We did a second build of rxtx 2.1-7 to resolve that unsatisfied link error. It should work now. rxtx is trying to tell you it thinks someone else has the serial port open. You can try to open the port again but maybe you already have a copy of the program running when it happens? ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7r2.zip fixed build. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sun Mar 26 11:44:23 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 26 Mar 2006 11:44:23 -0700 (MST) Subject: [Rxtx] RXTX spec file (fwd) Message-ID: This is probably interesting for fedora/suse users. ---------- Forwarded message ---------- Date: Sun, 26 Mar 2006 16:25:45 +0200 To: taj at www.linux.org.uk Subject: RXTX spec file I send you this spec file which allows to create a RPM for Fedora 4, 5 (x86, x86_64) with Java Sun. -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: rxtx.spec Url: http://mailman.qbang.org/pipermail/rxtx/attachments/20060326/6c7b6af6/rxtx-0004.pl From tjarvi at qbang.org Sun Mar 26 23:42:59 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 26 Mar 2006 23:42:59 -0700 (MST) Subject: [Rxtx] Upcomming events. Message-ID: This Wednesday we will be announcing a new "Maintainer" for the rxtx project. The position is more like neutral leader. I wont be going away or doing less. This is just the right thing to do as it turns out the two people with CVS write access will be at the same company. We need a third and we need neutrality. The maintainer will have final say in any conflict and will try to be neutral. It will be open for discussion. Then we will do it :) I'll still do most of the footwork I do now. But. I'm falling behind. I should have gone through the mail-list and posted the next round of changes this weekend. I'm packing to move and its going so so - 13 years of toys collected. I suspect there will be a dead period on my part (a couple weeks) comming up. But if you get it on the mail-list, we will get it in if there are no objections. I may well not be reading the mail-list during this period as I look for a house and many other things. I hope everyone will help out. Thanks -- Trent Jarvi tjarvi at qbang.org From mahmoud_hadad at yahoo.com Sun Mar 26 07:31:19 2006 From: mahmoud_hadad at yahoo.com (ronan nick) Date: Sun, 26 Mar 2006 06:31:19 -0800 (PST) Subject: [Rxtx] a question about the COMM API Message-ID: <20060326143119.54919.qmail@web60014.mail.yahoo.com> hi, i was intrested in knowing how i can communicate with my internal modem using java? for example if i want to make a phone dialer application or a caller id application where should i be looking at? and as i understood the COMM API is for devices that is attached to the computer through serial ports. --------------------------------- New Yahoo! Messenger with Voice. Call regular phones from your PC and save big. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060326/ce8329f0/attachment-0006.html From dmarkman at mac.com Mon Mar 20 00:20:43 2006 From: dmarkman at mac.com (Dmitry Markman) Date: Mon, 20 Mar 2006 02:20:43 -0500 Subject: [Rxtx] Mac OS X RXTX java installer In-Reply-To: References: <07D0DE29-BA32-4CFE-B036-66BC6423D385@buechse.de> <441AE3E0.2030503@willicon.de> <12531986.1142622114996.JavaMail.dmarkman@mac.com> <441B2674.9010409@willicon.de> <13577405.1142634732776.JavaMail.dmarkman@mac.com> <441B4182.8010407@willicon.de> <92CD0D6C-5BE8-426E-A46D-99452059FF49@mac.com> <441BBB2D.8030305@willicon.de> <441C4088.5090905@willicon.de> Message-ID: <64BC1E23-FDDE-4CE6-8863-CFC881CBC224@mac.com> Hi all I put RXTX installer that will install everything (and will create / var/lock if necessary and add user to the uucp group) for mac os x from Java into the rxtx's CVS repository it could be easily modified to install files for any platform it uses Greg Guerin's AuthKit for authentication and authorization Greg released that kit under artistic license, so Trent, please take a look we, probably, can negotiate license with Greg if it's necessary Greg's AuthKit could be downloaded from http://www.amug.org/~glguerin/ sw/#authkit Michael Hall (mikehall at spacestar dot net) had a suggestion to make implementation of the jaas LoginModule based on Greg's AuthKit (his modification of the Greg's AuthKit could be found at http:// www.spacestar.net/users/mikehall/authkit.dmg) but Michael's AuthKitLoginModule does only half a job: it does authenticate but it can not run any external unix process in privileged mode (at least I wasn't able to do so) possible explanation could be found in conversation between Greg and Michael at Apple's java-dev list (look for archives) so I didn't use jaas API for rxtxinstaller I created folder MacOSX in the contrib folder comment 1. if you want to run that installer as standalone application all you need that RXTXInstaller.jar 2. if you want to use webstart you have to add Greg's libAuthKit.jnilib to the mac os x's resources in theory RXTXInstaller.jar doesn't need it, but there is a problem with loading libAuthKit.jnilib from webstart authkit uses loadLibrary method to load library and it failed (from webstart) for standalone application I extract libAuthKit.jnilib from the RXTXInstaller.jar and put it into the /Library/Java/Extensions or ~/Library/Java/Extensions folder that file will be deleted after installer quit unfortunately I didn't have time to put documentation there but it is mostly self-explanatory I took installer code from my gl4java installer that I did about 3 years ago (with small modifications) it would be very nice if Apple will release LoginModule that really will do the job (com.apple.security.auth.module package????? ) (UnixLoginModule is pretty useless) From lyon at docjava.com Mon Mar 20 06:34:39 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Mon, 20 Mar 2006 08:34:39 -0500 Subject: [Rxtx] Mac OS X RXTX java installer In-Reply-To: <64BC1E23-FDDE-4CE6-8863-CFC881CBC224@mac.com> References: <07D0DE29-BA32-4CFE-B036-66BC6423D385@buechse.de> <441AE3E0.2030503@willicon.de> <12531986.1142622114996.JavaMail.dmarkman@mac.com> <441B2674.9010409@willicon.de> <13577405.1142634732776.JavaMail.dmarkman@mac.com> <441B4182.8010407@willicon.de> <92CD0D6C-5BE8-426E-A46D-99452059FF49@mac.com> <441BBB2D.8030305@willicon.de> <441C4088.5090905@willicon.de> <64BC1E23-FDDE-4CE6-8863-CFC881CBC224@mac.com> Message-ID: Hi Dimitry, This sounds like great work. Just a couple of questions; After the check out of the CVS files, using: setenv CVSROOT :pserver:anonymous at cvs.milestonesolutions.com:/usr/local/cvsroot 53 8:28 setenv PASSWORD mousy 54 8:29 cvs login 55 8:29 cvs checkout rxtx-devel I cd'd over to: rxtx-devel/MACOSX_IDE And found: CVS/ CW/ ForPackageMaker/ PB/ Where is the installer? Thanks! - Doug From tjarvi at qbang.org Mon Mar 20 06:39:37 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 20 Mar 2006 06:39:37 -0700 (MST) Subject: [Rxtx] Mac OS X RXTX java installer In-Reply-To: References: <07D0DE29-BA32-4CFE-B036-66BC6423D385@buechse.de> <441AE3E0.2030503@willicon.de> <12531986.1142622114996.JavaMail.dmarkman@mac.com> <441B2674.9010409@willicon.de> <13577405.1142634732776.JavaMail.dmarkman@mac.com> <441B4182.8010407@willicon.de> <92CD0D6C-5BE8-426E-A46D-99452059FF49@mac.com> <441BBB2D.8030305@willicon.de> <441C4088.5090905@willicon.de> <64BC1E23-FDDE-4CE6-8863-CFC881CBC224@mac.com> Message-ID: On Mon, 20 Mar 2006, Dr. Douglas Lyon wrote: > Hi Dimitry, > This sounds like great work. Just a couple of questions; > After the check out of the CVS files, using: > setenv CVSROOT > :pserver:anonymous at cvs.milestonesolutions.com:/usr/local/cvsroot > 53 8:28 setenv PASSWORD mousy > 54 8:29 cvs login > 55 8:29 cvs checkout rxtx-devel Hi Doug You want "cvs checkout -r commapi-0-0-1 rxtx-devel" to get RXTX 2.1 The default branch is rxtx 2.0 which isn't very active right now. -- Trent Jarvi tjarvi at qbang.org From lyon at docjava.com Mon Mar 20 07:05:44 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Mon, 20 Mar 2006 09:05:44 -0500 Subject: [Rxtx] Mac OS X RXTX java installer In-Reply-To: References: <07D0DE29-BA32-4CFE-B036-66BC6423D385@buechse.de> <441AE3E0.2030503@willicon.de> <12531986.1142622114996.JavaMail.dmarkman@mac.com> <441B2674.9010409@willicon.de> <13577405.1142634732776.JavaMail.dmarkman@mac.com> <441B4182.8010407@willicon.de> <92CD0D6C-5BE8-426E-A46D-99452059FF49@mac.com> <441BBB2D.8030305@willicon.de> <441C4088.5090905@willicon.de> <64BC1E23-FDDE-4CE6-8863-CFC881CBC224@mac.com> Message-ID: Hi Trent, Thanks for the info on the CVS checkout procedure. I did that and am still not sure where the installer is. Here is what I have: cd MACOSX_IDE/ p4.docjava.com{lyon}121: ls CVS/ ForPackageMaker/ PB/ p4.docjava.com{lyon}122: find . | more . ./ForPackageMaker ./ForPackageMaker/RXTX.pkg.sit.hqx ./ForPackageMaker/Resources ./ForPackageMaker/Resources/ReadMe.rtf ./ForPackageMaker/Resources/Welcome.rtf ./ForPackageMaker/Resources/CVS ./ForPackageMaker/Resources/CVS/Entries ./ForPackageMaker/Resources/CVS/Repository ./ForPackageMaker/Resources/CVS/Tag ./ForPackageMaker/Resources/CVS/Root ./ForPackageMaker/Resources/preinstall ./ForPackageMaker/Resources/License.rtf ./ForPackageMaker/Resources/preupgrade ./ForPackageMaker/RXTX.pmsp ./ForPackageMaker/CVS ./ForPackageMaker/CVS/Entries ./ForPackageMaker/CVS/Repository ./ForPackageMaker/CVS/Entries.Log ./ForPackageMaker/CVS/Tag ./ForPackageMaker/CVS/Root ./ForPackageMaker/RXTX_Tiger.pkg.sitx.hqx ./ForPackageMaker/RXTX_Jag.pkg.sit.hqx ./ForPackageMaker/Install ./ForPackageMaker/Install/CVS ./ForPackageMaker/Install/CVS/Entries ./ForPackageMaker/Install/CVS/Repository ./ForPackageMaker/Install/CVS/Tag ./ForPackageMaker/Install/CVS/Root ./ForPackageMaker/Install/Library ./ForPackageMaker/Install/Library/CVS ./ForPackageMaker/Install/Library/CVS/Entries ./ForPackageMaker/Install/Library/CVS/Repository ./ForPackageMaker/Install/Library/CVS/Tag ./ForPackageMaker/Install/Library/CVS/Root ./ForPackageMaker/Install/Library/Java ./ForPackageMaker/Install/Library/Java/Extensions ./ForPackageMaker/Install/Library/Java/Extensions/RXTXcomm.jar ./ForPackageMaker/Install/Library/Java/Extensions/CVS ./ForPackageMaker/Install/Library/Java/Extensions/CVS/Entries ./ForPackageMaker/Install/Library/Java/Extensions/CVS/Repository ./ForPackageMaker/Install/Library/Java/Extensions/CVS/Tag ./ForPackageMaker/Install/Library/Java/Extensions/CVS/Root ./ForPackageMaker/Install/Library/Java/Extensions/librxtxSerial.jnilib ./ForPackageMaker/Install/Library/Java/CVS ./ForPackageMaker/Install/Library/Java/CVS/Entries ./ForPackageMaker/Install/Library/Java/CVS/Repository ./ForPackageMaker/Install/Library/Java/CVS/Entries.Log ./ForPackageMaker/Install/Library/Java/CVS/Tag ./ForPackageMaker/Install/Library/Java/CVS/Root ./ForPackageMaker/RXTX_Tiger.pmproj.sitx.hqx ./CVS ./CVS/Entries ./CVS/Repository ./CVS/Entries.Log ./CVS/Tag ./CVS/Root ./PB ./PB/LibSerialUniversal.xcodeproj.sitx.hqx ./PB/CVS ./PB/CVS/Entries ./PB/CVS/Repository ./PB/CVS/Entries.Log ./PB/CVS/Tag ./PB/CVS/Root ./PB/LibSerial.pbproj.sit.hqx ./PB/startpoint.c ./PB/config.h What is the procedure to run this installer? Do we need a README in: /rxtx-devel/MACOSX_IDE Here is what we have: CVS/ ForPackageMaker/ PB/ Thanks! - DL >On Mon, 20 Mar 2006, Dr. Douglas Lyon wrote: > >>Hi Dimitry, >>This sounds like great work. Just a couple of questions; >>After the check out of the CVS files, using: >>setenv CVSROOT >>:pserver:anonymous at cvs.milestonesolutions.com:/usr/local/cvsroot >> 53 8:28 setenv PASSWORD mousy >> 54 8:29 cvs login >> 55 8:29 cvs checkout rxtx-devel > >Hi Doug > >You want "cvs checkout -r commapi-0-0-1 rxtx-devel" to get RXTX 2.1 >The default branch is rxtx 2.0 which isn't very active right now. > >-- >Trent Jarvi >tjarvi at qbang.org From tjarvi at qbang.org Mon Mar 20 07:25:30 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 20 Mar 2006 07:25:30 -0700 (MST) Subject: [Rxtx] Mac OS X RXTX java installer In-Reply-To: References: <07D0DE29-BA32-4CFE-B036-66BC6423D385@buechse.de> <441AE3E0.2030503@willicon.de> <12531986.1142622114996.JavaMail.dmarkman@mac.com> <441B2674.9010409@willicon.de> <13577405.1142634732776.JavaMail.dmarkman@mac.com> <441B4182.8010407@willicon.de> <92CD0D6C-5BE8-426E-A46D-99452059FF49@mac.com> <441BBB2D.8030305@willicon.de> <441C4088.5090905@willicon.de> <64BC1E23-FDDE-4CE6-8863-CFC881CBC224@mac.com> Message-ID: On Mon, 20 Mar 2006, Dr. Douglas Lyon wrote: > Hi Trent, > Thanks for the info on the CVS checkout procedure. > I did that and am still not sure where the installer is. Hi Doug It does look like it was not cvs committed. There is no rxtx-devel/contrib/MacOSX directory in there at the moment. It was mentioned that it was put under contrib. -- Trent Jarvi tjarvi at qbang.org From dmarkman at mac.com Mon Mar 20 07:29:56 2006 From: dmarkman at mac.com (Dmitry Markman) Date: Mon, 20 Mar 2006 09:29:56 -0500 Subject: [Rxtx] Mac OS X RXTX java installer In-Reply-To: References: <07D0DE29-BA32-4CFE-B036-66BC6423D385@buechse.de> <441AE3E0.2030503@willicon.de> <12531986.1142622114996.JavaMail.dmarkman@mac.com> <441B2674.9010409@willicon.de> <13577405.1142634732776.JavaMail.dmarkman@mac.com> <441B4182.8010407@willicon.de> <92CD0D6C-5BE8-426E-A46D-99452059FF49@mac.com> <441BBB2D.8030305@willicon.de> <441C4088.5090905@willicon.de> <64BC1E23-FDDE-4CE6-8863-CFC881CBC224@mac.com> Message-ID: <6054EB4E-F7E0-4A9C-BDDA-D582D6D8826F@mac.com> you can find it in the rxtx-devel/contrib folder On Mar 20, 2006, at 9:05 AM, Dr. Douglas Lyon wrote: > Hi Trent, > Thanks for the info on the CVS checkout procedure. > I did that and am still not sure where the installer is. > Here is what I have: > cd MACOSX_IDE/ > p4.docjava.com{lyon}121: ls > CVS/ ForPackageMaker/ PB/ > p4.docjava.com{lyon}122: find . | more > . > ./ForPackageMaker > ./ForPackageMaker/RXTX.pkg.sit.hqx > ./ForPackageMaker/Resources > ./ForPackageMaker/Resources/ReadMe.rtf > ./ForPackageMaker/Resources/Welcome.rtf > ./ForPackageMaker/Resources/CVS > ./ForPackageMaker/Resources/CVS/Entries > ./ForPackageMaker/Resources/CVS/Repository > ./ForPackageMaker/Resources/CVS/Tag > ./ForPackageMaker/Resources/CVS/Root > ./ForPackageMaker/Resources/preinstall > ./ForPackageMaker/Resources/License.rtf > ./ForPackageMaker/Resources/preupgrade > ./ForPackageMaker/RXTX.pmsp > ./ForPackageMaker/CVS > ./ForPackageMaker/CVS/Entries > ./ForPackageMaker/CVS/Repository > ./ForPackageMaker/CVS/Entries.Log > ./ForPackageMaker/CVS/Tag > ./ForPackageMaker/CVS/Root > ./ForPackageMaker/RXTX_Tiger.pkg.sitx.hqx > ./ForPackageMaker/RXTX_Jag.pkg.sit.hqx > ./ForPackageMaker/Install > ./ForPackageMaker/Install/CVS > ./ForPackageMaker/Install/CVS/Entries > ./ForPackageMaker/Install/CVS/Repository > ./ForPackageMaker/Install/CVS/Tag > ./ForPackageMaker/Install/CVS/Root > ./ForPackageMaker/Install/Library > ./ForPackageMaker/Install/Library/CVS > ./ForPackageMaker/Install/Library/CVS/Entries > ./ForPackageMaker/Install/Library/CVS/Repository > ./ForPackageMaker/Install/Library/CVS/Tag > ./ForPackageMaker/Install/Library/CVS/Root > ./ForPackageMaker/Install/Library/Java > ./ForPackageMaker/Install/Library/Java/Extensions > ./ForPackageMaker/Install/Library/Java/Extensions/RXTXcomm.jar > ./ForPackageMaker/Install/Library/Java/Extensions/CVS > ./ForPackageMaker/Install/Library/Java/Extensions/CVS/Entries > ./ForPackageMaker/Install/Library/Java/Extensions/CVS/Repository > ./ForPackageMaker/Install/Library/Java/Extensions/CVS/Tag > ./ForPackageMaker/Install/Library/Java/Extensions/CVS/Root > ./ForPackageMaker/Install/Library/Java/Extensions/librxtxSerial.jnilib > ./ForPackageMaker/Install/Library/Java/CVS > ./ForPackageMaker/Install/Library/Java/CVS/Entries > ./ForPackageMaker/Install/Library/Java/CVS/Repository > ./ForPackageMaker/Install/Library/Java/CVS/Entries.Log > ./ForPackageMaker/Install/Library/Java/CVS/Tag > ./ForPackageMaker/Install/Library/Java/CVS/Root > ./ForPackageMaker/RXTX_Tiger.pmproj.sitx.hqx > ./CVS > ./CVS/Entries > ./CVS/Repository > ./CVS/Entries.Log > ./CVS/Tag > ./CVS/Root > ./PB > ./PB/LibSerialUniversal.xcodeproj.sitx.hqx > ./PB/CVS > ./PB/CVS/Entries > ./PB/CVS/Repository > ./PB/CVS/Entries.Log > ./PB/CVS/Tag > ./PB/CVS/Root > ./PB/LibSerial.pbproj.sit.hqx > ./PB/startpoint.c > ./PB/config.h > > What is the procedure to run this installer? > Do we need a README in: > /rxtx-devel/MACOSX_IDE > Here is what we have: > CVS/ ForPackageMaker/ PB/ > > > Thanks! > - DL > >> On Mon, 20 Mar 2006, Dr. Douglas Lyon wrote: >> >>> Hi Dimitry, >>> This sounds like great work. Just a couple of questions; >>> After the check out of the CVS files, using: >>> setenv CVSROOT :pserver:anonymous at cvs.milestonesolutions.com:/usr/ >>> local/cvsroot >>> 53 8:28 setenv PASSWORD mousy >>> 54 8:29 cvs login >>> 55 8:29 cvs checkout rxtx-devel >> >> Hi Doug >> >> You want "cvs checkout -r commapi-0-0-1 rxtx-devel" to get RXTX 2.1 >> The default branch is rxtx 2.0 which isn't very active right now. >> >> -- >> Trent Jarvi >> tjarvi at qbang.org > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx Dmitry Markman From mikehall at spacestar.net Mon Mar 20 05:25:25 2006 From: mikehall at spacestar.net (Michael Hall) Date: Mon, 20 Mar 2006 06:25:25 -0600 Subject: [Rxtx] Re: Mac OS X RXTX java installer In-Reply-To: <64BC1E23-FDDE-4CE6-8863-CFC881CBC224@mac.com> References: <07D0DE29-BA32-4CFE-B036-66BC6423D385@buechse.de> <441AE3E0.2030503@willicon.de> <12531986.1142622114996.JavaMail.dmarkman@mac.com> <441B2674.9010409@willicon.de> <13577405.1142634732776.JavaMail.dmarkman@mac.com> <441B4182.8010407@willicon.de> <92CD0D6C-5BE8-426E-A46D-99452059FF49@mac.com> <441BBB2D.8030305@willicon.de> <441C4088.5090905@willicon.de> <64BC1E23-FDDE-4CE6-8863-CFC881CBC224@mac.com> Message-ID: <247EB61F-5CD1-4132-89A2-FC105B6CF9A5@spacestar.net> On Mar 20, 2006, at 1:20 AM, Dmitry Markman wrote: > > Michael Hall (mikehall at spacestar dot net) had a suggestion to > make implementation of the jaas LoginModule > based on Greg's AuthKit > (his modification of the Greg's AuthKit could be found at http:// > www.spacestar.net/users/mikehall/authkit.dmg) > but Michael's AuthKitLoginModule does only half a job: > it does authenticate > but it can not run any external unix process in privileged mode (at > least I wasn't able to do so) If you got it working directly with Greg's the point is moot. But to clarify it anyhow. The login module does not allow you to do anything anything privileged on return as was explained by Greg. You need to work with a separate privileged process using the execPrivileged method of his API. I assume you did something similar although I haven't looked at how you are using it yet. I allowed instead for a action to be performed at the same time you login/authenticate,this... System.setProperty("authkit.action","/usr/bin/id"); just before this... lc.login(); To clarify, safely ignored as you are already complete. Mike Hall mikehall at spacestar dot net http://www.spacestar.net/users/mikehall http://sourceforge.net/projects/macnative -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2427 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20060320/f6e18202/smime-0009.bin From dmarkman at mac.com Mon Mar 20 07:36:47 2006 From: dmarkman at mac.com (Dmitry Markman) Date: Mon, 20 Mar 2006 09:36:47 -0500 Subject: [Rxtx] Re: Mac OS X RXTX java installer In-Reply-To: <247EB61F-5CD1-4132-89A2-FC105B6CF9A5@spacestar.net> References: <07D0DE29-BA32-4CFE-B036-66BC6423D385@buechse.de> <441AE3E0.2030503@willicon.de> <12531986.1142622114996.JavaMail.dmarkman@mac.com> <441B2674.9010409@willicon.de> <13577405.1142634732776.JavaMail.dmarkman@mac.com> <441B4182.8010407@willicon.de> <92CD0D6C-5BE8-426E-A46D-99452059FF49@mac.com> <441BBB2D.8030305@willicon.de> <441C4088.5090905@willicon.de> <64BC1E23-FDDE-4CE6-8863-CFC881CBC224@mac.com> <247EB61F-5CD1-4132-89A2-FC105B6CF9A5@spacestar.net> Message-ID: Hi, Michael all I have to do is to run some shell script I tried to use your action mechanism and it worked great so I just System.setProperty ("authkit.action","" ) and after that I even don't need to run anything like subject.doAs.... but after few thoughts I choose to use plain Greg's approach, because in that case I don't have to deal with various java's configurations files and therefore to use 2-3 -D parameters in the java command line especially it's useful for java web start (it's so fragile :-( ) thanks for the great job On Mar 20, 2006, at 7:25 AM, Michael Hall wrote: > > On Mar 20, 2006, at 1:20 AM, Dmitry Markman wrote: >> >> Michael Hall (mikehall at spacestar dot net) had a suggestion to >> make implementation of the jaas LoginModule >> based on Greg's AuthKit >> (his modification of the Greg's AuthKit could be found at http:// >> www.spacestar.net/users/mikehall/authkit.dmg) >> but Michael's AuthKitLoginModule does only half a job: >> it does authenticate >> but it can not run any external unix process in privileged mode >> (at least I wasn't able to do so) > > If you got it working directly with Greg's the point is moot. > > But to clarify it anyhow. > The login module does not allow you to do anything anything > privileged on return as was explained by Greg. You need to work > with a separate privileged process using the execPrivileged method > of his API. I assume you did something similar although I haven't > looked at how you are using it yet. > I allowed instead for a action to be performed at the same time you > login/authenticate,this... > System.setProperty("authkit.action","/usr/bin/id"); > just before this... > lc.login(); > To clarify, safely ignored as you are already complete. > > Mike Hall mikehall at spacestar dot net > http://www.spacestar.net/users/mikehall > http://sourceforge.net/projects/macnative > > > Dmitry Markman From dmarkman at mac.com Mon Mar 20 07:44:45 2006 From: dmarkman at mac.com (Dmitry Markman) Date: Mon, 20 Mar 2006 09:44:45 -0500 Subject: [Rxtx] Mac OS X RXTX java installer In-Reply-To: References: <07D0DE29-BA32-4CFE-B036-66BC6423D385@buechse.de> <441AE3E0.2030503@willicon.de> <12531986.1142622114996.JavaMail.dmarkman@mac.com> <441B2674.9010409@willicon.de> <13577405.1142634732776.JavaMail.dmarkman@mac.com> <441B4182.8010407@willicon.de> <92CD0D6C-5BE8-426E-A46D-99452059FF49@mac.com> <441BBB2D.8030305@willicon.de> <441C4088.5090905@willicon.de> <64BC1E23-FDDE-4CE6-8863-CFC881CBC224@mac.com> Message-ID: it's in the commapi-0-0-1 branch I tested it right now: cvs co -r commapi-0-0-1 rxtx-devel and I got everything On Mar 20, 2006, at 9:25 AM, Trent Jarvi wrote: > On Mon, 20 Mar 2006, Dr. Douglas Lyon wrote: > >> Hi Trent, >> Thanks for the info on the CVS checkout procedure. >> I did that and am still not sure where the installer is. > > Hi Doug > > It does look like it was not cvs committed. There is no rxtx-devel/ > contrib/MacOSX directory in there at the moment. It was mentioned > that it was put under contrib. > > -- > Trent Jarvi > tjarvi at qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx Dmitry Markman From tjarvi at qbang.org Mon Mar 20 07:52:57 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 20 Mar 2006 07:52:57 -0700 (MST) Subject: [Rxtx] Mac OS X RXTX java installer In-Reply-To: References: <07D0DE29-BA32-4CFE-B036-66BC6423D385@buechse.de> <441AE3E0.2030503@willicon.de> <12531986.1142622114996.JavaMail.dmarkman@mac.com> <441B2674.9010409@willicon.de> <13577405.1142634732776.JavaMail.dmarkman@mac.com> <441B4182.8010407@willicon.de> <92CD0D6C-5BE8-426E-A46D-99452059FF49@mac.com> <441BBB2D.8030305@willicon.de> <441C4088.5090905@willicon.de> <64BC1E23-FDDE-4CE6-8863-CFC881CBC224@mac.com> Message-ID: On Mon, 20 Mar 2006, Dmitry Markman wrote: > it's in the commapi-0-0-1 branch > > I tested it right now: > cvs co -r commapi-0-0-1 rxtx-devel > > and I got everything > A fresh checkout worked. Here is a copy of the tree (just the installer bits) ftp://ftp.qbang.org/pub/rxtx/MacOSX-installer.zip -- Trent Jarvi tjarvi at qbang.org From lyon at docjava.com Mon Mar 20 08:08:26 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Mon, 20 Mar 2006 10:08:26 -0500 Subject: [Rxtx] Mac OS X RXTX java installer In-Reply-To: References: <07D0DE29-BA32-4CFE-B036-66BC6423D385@buechse.de> <441AE3E0.2030503@willicon.de> <12531986.1142622114996.JavaMail.dmarkman@mac.com> <441B2674.9010409@willicon.de> <13577405.1142634732776.JavaMail.dmarkman@mac.com> <441B4182.8010407@willicon.de> <92CD0D6C-5BE8-426E-A46D-99452059FF49@mac.com> <441BBB2D.8030305@willicon.de> <441C4088.5090905@willicon.de> <64BC1E23-FDDE-4CE6-8863-CFC881CBC224@mac.com> Message-ID: Hi All, Is the Auth package able to work properly on non Mac OS's? It was not clear from the doc or download. Thanks! - Doug From dmarkman at mac.com Mon Mar 20 08:15:22 2006 From: dmarkman at mac.com (Dmitry Markman) Date: Mon, 20 Mar 2006 10:15:22 -0500 Subject: [Rxtx] Mac OS X RXTX java installer In-Reply-To: References: <07D0DE29-BA32-4CFE-B036-66BC6423D385@buechse.de> <441AE3E0.2030503@willicon.de> <12531986.1142622114996.JavaMail.dmarkman@mac.com> <441B2674.9010409@willicon.de> <13577405.1142634732776.JavaMail.dmarkman@mac.com> <441B4182.8010407@willicon.de> <92CD0D6C-5BE8-426E-A46D-99452059FF49@mac.com> <441BBB2D.8030305@willicon.de> <441C4088.5090905@willicon.de> <64BC1E23-FDDE-4CE6-8863-CFC881CBC224@mac.com> Message-ID: <217312D8-CCCA-4859-ABA6-32DF1CC817B9@mac.com> thanks Trent, for putting it on ftp server On Mar 20, 2006, at 9:52 AM, Trent Jarvi wrote: > A fresh checkout worked. Here is a copy of the tree (just the > installer bits) > > ftp://ftp.qbang.org/pub/rxtx/MacOSX-installer.zip > Dmitry Markman From dmarkman at mac.com Mon Mar 20 09:14:03 2006 From: dmarkman at mac.com (Dmitry Markman) Date: Mon, 20 Mar 2006 11:14:03 -0500 Subject: [Rxtx] Mac OS X RXTX java installer In-Reply-To: References: <07D0DE29-BA32-4CFE-B036-66BC6423D385@buechse.de> <441AE3E0.2030503@willicon.de> <12531986.1142622114996.JavaMail.dmarkman@mac.com> <441B2674.9010409@willicon.de> <13577405.1142634732776.JavaMail.dmarkman@mac.com> <441B4182.8010407@willicon.de> <92CD0D6C-5BE8-426E-A46D-99452059FF49@mac.com> <441BBB2D.8030305@willicon.de> <441C4088.5090905@willicon.de> <64BC1E23-FDDE-4CE6-8863-CFC881CBC224@mac.com> Message-ID: <4DEBA6F0-DA45-4E84-823E-1F1AC48BDCCC@mac.com> no it will work only on mac os x however it's harmless to run it on other platform if you want to use it for other platform you have to do the following (I'll do it for linux) 1. modify RXTXInstaller class method public static RXTXInstaller getInstance() public static RXTXInstaller getInstance() { String osName = System.getProperty("os.name").toLowerCase(); if(osName.startsWith("mac")){ return new gnu.io.installer.macosx.MACOSXRXTXInstaller(); } else if(osName.startsWith("windows")){ return new gnu.io.installer.windows.WindowsRXTXInstaller(); }else if(osName.startsWith("linux")){ return new gnu.io.installer.linux.LinuxRXTXInstaller(); } return null; } 2. create folder gnu/io/installer/linux/ 3. create class Linux386RXTXInstaller package gnu.io.installer.linux; import java.io.File; public class Linux386RXTXInstaller extends gnu.io.installer.RXTXInstaller{ public Linux386RXTXInstaller(){ createJarFolder(); createLibFolder(); addJarResource("RXTXcomm.jar","/gnu/io/installer/resources/ linux/jar/RXTXcomm.dat"); addLibResource("librxtxSerial.so","/gnu/io/installer/ resources/linux/lib/librxtxSerial.so"); } protected void createJarFolder(){ String javaHome = System.getProperty("java.home"); char separator = File.separatorChar; jarFolder = new File(javaHome+separator+"lib"+separator+"ext"); } protected void createLibFolder(){ String javaHome = System.getProperty("java.home"); char separator = File.separatorChar; libFolder = new File(javaHome+separator+"bin"); } public void runPreProcess() {} //put here some action you need public void runPostProcess() {} //put here some action you need } 4. create folder /gnu/io/installer/resources/linux/jar and put there linux's version of RXTXcomm.dat (which is renamed RXTXcomm.jar) 5. create folder /gnu/io/installer/resources/linux/lib and put there linux's version of librxtxSerial. so 6. make sure that RXTXInstaller.jar has the following items: /gnu/io/installer/resources/linux/jar/RXTXcomm.jar /gnu/io/installer/resources/linux/lib/librxtxSerial.so 7. modify file installer.pref: jar file RXTXInstaller.jar must have the following item /gnu/io/installer/installer.pref that's basically it for windows you have to do the similar things: just replace linux to windows and librxtxSerial.so to rxtxSerial.dll and create appropriate gnu.io.installer.windows.WindowsRXTXInstaller class package gnu.io.installer.windows; import java.io.File; public class WindowsRXTXInstaller extends gnu.io.installer.RXTXInstaller{ public WindowsRXTXInstaller(){ createJarFolder(); createLibFolder(); addJarResource("RXTXcomm.jar","/gnu/io/installer/resources/ windows/jar/RXTXcomm.dat"); addLibResource("librxtxSerial.so","/gnu/io/installer/ resources/windows/lib/rxtxSerial.dll"); } protected void createJarFolder(){ String javaHome = System.getProperty("java.home"); char separator = File.separatorChar; jarFolder = new File(javaHome+separator+"lib"+separator+"ext"); } protected void createLibFolder(){ String javaHome = System.getProperty("java.home"); char separator = File.separatorChar; libFolder = new File(javaHome+separator+"bin"); } public void runPreProcess() {} //put here some action you need public void runPostProcess() {} //put here some action you need } installer.pref will look like On Mar 20, 2006, at 10:08 AM, Dr. Douglas Lyon wrote: > Hi All, > Is the Auth package able to work properly on > non Mac OS's? > It was not clear from the doc or download. > > Thanks! > - Doug > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx Dmitry Markman From joachim at buechse.de Mon Mar 20 10:49:06 2006 From: joachim at buechse.de (Joachim Buechse) Date: Mon, 20 Mar 2006 18:49:06 +0100 Subject: [Rxtx] BUG: Lock file stays even if port opening fails Message-ID: This was only tested on MacOSX but looking at the code, it should be true for all systems that use lock_uucp. I am opening a port which can not be opened (dialup port of a telephone paired via bluetooth but currently not reachable). The lock file is created and stays arround, even though the port open failed. After looking a bit through the code (of 2.17), I really wonder if it wouldn't be a good idea to make the "locking" an explicit operation called from the java code. This would certainly simplify the generation of meaningfull exceptions (and java based debugging). Maybe even the handling of "preopened" ports should be in the Java part of the lib (again for java based debugging puposes). That beeing said, I have no idea if this would be possible for the 2.07 implementation. Regards, Joachim From tjarvi at qbang.org Mon Mar 20 11:24:22 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 20 Mar 2006 11:24:22 -0700 (MST) Subject: [Rxtx] BUG: Lock file stays even if port opening fails In-Reply-To: References: Message-ID: On Mon, 20 Mar 2006, Joachim Buechse wrote: > This was only tested on MacOSX but looking at the code, it should be true > for all systems that use lock_uucp. > > I am opening a port which can not be opened (dialup port of a telephone > paired via bluetooth but currently not reachable). The lock file is > created and stays arround, even though the port open failed. > > > After looking a bit through the code (of 2.17), I really wonder if it > wouldn't be a good idea to make the "locking" an explicit operation > called from the java code. This would certainly simplify the generation > of meaningfull exceptions (and java based debugging). > Maybe even the handling of "preopened" ports should be in the Java part > of the lib (again for java based debugging puposes). That beeing said, I > have no idea if this would be possible for the 2.07 implementation. > > Regards, Hi Joachim It should be possible in the 2.0-7 implementation too. The calls to RXTXPort.java would not change. We would just do more there Moving more of that logic into Java would be better as many people don't like to look at C code. There is a liblockdev on most Linux distros that can do most of the C code and would be easier to use. The problem is embeded devices will not have that library. The preopened port code has not been really tested. That was a last minute request in a product cycle. I expect it will be tested this year though. As I recall, some devices really do not like CD raising on open. The preopened ports then allow people to mess around in java without power cycling the devices or losing data. -- Trent Jarvi tjarvi at qbang.org From joachim at buechse.de Mon Mar 20 12:01:08 2006 From: joachim at buechse.de (Joachim Buechse) Date: Mon, 20 Mar 2006 20:01:08 +0100 Subject: [Rxtx] BUG: Lock file stays even if port opening fails In-Reply-To: References: Message-ID: Hi Trent, What is your general feeling about moving code to Java? The last days I have been reading quite a bit of the code and there are several things, that might not work as expected. I'll give you two examples from is_device_locked: if LOCKDIR == /var/spool/locks the directory /var/spool/lock will not be checked. LOCKDIR is not checked for lockfiles with unexpected pefixes While these things have probably never been discovered in production, they are still possibly incorrect implementations. If it was Java code, I would write some unit tests producing the errors that could later be corrected. PS: One could imagine to actually implement the whole lockfile handling in Java using some native routines to get the values required (pid, st_dev, st_rdev, ...). On 20.03.2006, at 19:24, Trent Jarvi wrote: > On Mon, 20 Mar 2006, Joachim Buechse wrote: > >> This was only tested on MacOSX but looking at the code, it should >> be true for all systems that use lock_uucp. >> >> I am opening a port which can not be opened (dialup port of a >> telephone paired via bluetooth but currently not reachable). The >> lock file is created and stays arround, even though the port open >> failed. >> >> >> After looking a bit through the code (of 2.17), I really wonder if >> it wouldn't be a good idea to make the "locking" an explicit >> operation called from the java code. This would certainly simplify >> the generation of meaningfull exceptions (and java based debugging). >> Maybe even the handling of "preopened" ports should be in the Java >> part of the lib (again for java based debugging puposes). That >> beeing said, I have no idea if this would be possible for the 2.07 >> implementation. >> >> Regards, > > Hi Joachim > > It should be possible in the 2.0-7 implementation too. The calls > to RXTXPort.java would not change. We would just do more there > Moving more of that logic into Java would be better as many people > don't like to look at C code. There is a liblockdev on most Linux > distros that can do most of the C code and would be easier to use. > The problem is embeded devices will not have that library. > > The preopened port code has not been really tested. That was a > last minute request in a product cycle. I expect it will be tested > this year though. As I recall, some devices really do not like CD > raising on open. The preopened ports then allow people to mess > around in java without power cycling the devices or losing data. > > -- > Trent Jarvi > tjarvi at qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Mon Mar 20 12:21:02 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 20 Mar 2006 12:21:02 -0700 (MST) Subject: [Rxtx] BUG: Lock file stays even if port opening fails In-Reply-To: References: Message-ID: On Mon, 20 Mar 2006, Joachim Buechse wrote: > Hi Trent, > > What is your general feeling about moving code to Java? The last days I > have been reading quite a bit of the code and there are several things, > that might not work as expected. > > I'll give you two examples from is_device_locked: > > if LOCKDIR == /var/spool/locks the directory /var/spool/lock will not be > checked. > LOCKDIR is not checked for lockfiles with unexpected pefixes > > While these things have probably never been discovered in production, > they are still possibly incorrect implementations. If it was Java code, I > would write some unit tests producing the errors that could later be > corrected. > > PS: One could imagine to actually implement the whole lockfile handling > in Java using some native routines to get the values required (pid, > st_dev, st_rdev, ...). Hi Joachim I like the idea of moving more of the code into java but there are some things to consider. If you break this into multiple JNI calls, the performance will drop considerably during enumeration of ports. We are looking for 256 ports per dev type vs (16? in Sun's 2.0 and fewer types). Its hard to make assumptions. I've seen virtual ports start at /dev/foo100 for instance. It works out to over 7500 ports on Linux if you enable them all. We already trim that back by default. See Linux-all-ports in RXTXCommDriver.java. There are also native libraries that rxtx can link to. If you move too much into Java, linking to 'standard' libraries with distros will break. "configure --enable-liblock=yes" will not be doable. This is probably a favorable way with RedHat, Debian, Suse and others. Thats the right thing to do if there will be rpms, dpkg, .. For those reasons, I think it still make sense to keep it to a minimal ~3 calls to JNI code that we can use for speed and versatility. lock() isLocked(), unlock() perhaps. When I say speed, its more about avoiding crossing the JNI layer multiple times than java vs C performance. With versatility I think liblock is the right way for most but not all (embeded) linux distros. -- Trent Jarvi tjarvi at qbang.org From joachim at buechse.de Mon Mar 20 12:42:04 2006 From: joachim at buechse.de (Joachim Buechse) Date: Mon, 20 Mar 2006 20:42:04 +0100 Subject: [Rxtx] BUG: Lock file stays even if port opening fails In-Reply-To: References: Message-ID: <82C19FE7-DDCB-45B6-B2C9-7606B66F0124@buechse.de> Ok, what about providing a default implementation in Java? The RXTXCommDriver would call a (native) function useNativeLocking and if it returns true, call the native functions for lock() isLocked (), unlock(), else is would use the Java based default implementation. This could possibly be overriden by a property (again for debugging). Joachim On 20.03.2006, at 20:21, Trent Jarvi wrote: > On Mon, 20 Mar 2006, Joachim Buechse wrote: > >> Hi Trent, >> >> What is your general feeling about moving code to Java? The last >> days I have been reading quite a bit of the code and there are >> several things, that might not work as expected. >> >> I'll give you two examples from is_device_locked: >> >> if LOCKDIR == /var/spool/locks the directory /var/spool/lock will >> not be checked. >> LOCKDIR is not checked for lockfiles with unexpected pefixes >> >> While these things have probably never been discovered in >> production, they are still possibly incorrect implementations. If >> it was Java code, I would write some unit tests producing the >> errors that could later be corrected. >> >> PS: One could imagine to actually implement the whole lockfile >> handling in Java using some native routines to get the values >> required (pid, st_dev, st_rdev, ...). > > Hi Joachim > > I like the idea of moving more of the code into java but there are > some things to consider. > > If you break this into multiple JNI calls, the performance will > drop considerably during enumeration of ports. We are looking for > 256 ports per dev type vs (16? in Sun's 2.0 and fewer types). Its > hard to make assumptions. I've seen virtual ports start at /dev/ > foo100 for instance. > > It works out to over 7500 ports on Linux if you enable them all. > We already trim that back by default. See Linux-all-ports in > RXTXCommDriver.java. > > There are also native libraries that rxtx can link to. If you move > too much into Java, linking to 'standard' libraries with distros > will break. "configure --enable-liblock=yes" will not be doable. > This is probably a favorable way with RedHat, Debian, Suse and > others. Thats the right thing to do if there will be rpms, dpkg, .. > > For those reasons, I think it still make sense to keep it to a > minimal ~3 calls to JNI code that we can use for speed and > versatility. lock() isLocked(), unlock() perhaps. When I say > speed, its more about avoiding crossing the JNI layer multiple > times than java vs C performance. With versatility I think liblock > is the right way for most but not all (embeded) linux distros. > > -- > Trent Jarvi > tjarvi at qbang.org > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Mon Mar 20 12:44:47 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 20 Mar 2006 12:44:47 -0700 (MST) Subject: [Rxtx] BUG: Lock file stays even if port opening fails In-Reply-To: <82C19FE7-DDCB-45B6-B2C9-7606B66F0124@buechse.de> References: <82C19FE7-DDCB-45B6-B2C9-7606B66F0124@buechse.de> Message-ID: On Mon, 20 Mar 2006, Joachim Buechse wrote: > Ok, what about providing a default implementation in Java? > > The RXTXCommDriver would call a (native) function useNativeLocking and if > it returns true, call the native functions for lock() isLocked(), > unlock(), else is would use the Java based default implementation. This > could possibly be overriden by a property (again for debugging). > Hi Joachim That would be OK with me. -- Trent Jarvi tjarvi at qbang.org From dmarkman at mac.com Mon Mar 20 22:27:45 2006 From: dmarkman at mac.com (Dmitry Markman) Date: Tue, 21 Mar 2006 00:27:45 -0500 Subject: [Rxtx] binaries request Message-ID: <42702213-C222-4937-A585-7CFB17E47608@mac.com> Hi can somebody send me latest linux and windows binaries, please? or where I can find them (I didn't find them in the latest tareball) I gave up with my cygwin: something wrong I have no idea what java doesn't understand /cygwin/c syntax after I changed makefile it did java part but after that gcc 3.4.4 started to complain I set buffer length to 999 lines but I didn't get beginning of the story something wrong with my 1.4.2_09/include/jni.h gcc doesn't like it anyway I gave up thanks in advance Dmitry Markman -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060320/f8cbc57c/attachment-0009.html From tjarvi at qbang.org Mon Mar 20 22:36:48 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 20 Mar 2006 22:36:48 -0700 (MST) Subject: [Rxtx] binaries request In-Reply-To: <42702213-C222-4937-A585-7CFB17E47608@mac.com> References: <42702213-C222-4937-A585-7CFB17E47608@mac.com> Message-ID: On Tue, 21 Mar 2006, Dmitry Markman wrote: > Hi > can somebody send me latest linux and windows binaries, please? > > or where I can find them (I didn't find them in the latest tareball) > > I gave up with my cygwin: something wrong I have no idea what > java doesn't understand /cygwin/c syntax > after I changed makefile it did java part > but after that gcc 3.4.4 started to complain > I set buffer length to 999 lines but I didn't get beginning of the story > something wrong with my 1.4.2_09/include/jni.h gcc doesn't like it > anyway I gave up > > thanks in advance > Hi Dmitry The bins are here: ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7-bins-r2.zip Here are the files in the zip you want. Jar: rxtx-2.1-7-bins-r2/RXTXcomm.jar Windows: rxtx-2.1-7-bins-r2/Windows/i368-mingw32/rxtxSerial.dll Linux (x86) rxtx-2.1-7-bins-r2/Linux/i686-unknown-linux-gnu/librxtxSerial.so There are others in there including Parallel port support but those are the main ones for testing. -- Trent Jarvi tjarvi at qbang.org From dmarkman at mac.com Mon Mar 20 23:05:59 2006 From: dmarkman at mac.com (Dmitry Markman) Date: Tue, 21 Mar 2006 01:05:59 -0500 Subject: [Rxtx] binaries request In-Reply-To: References: <42702213-C222-4937-A585-7CFB17E47608@mac.com> Message-ID: thank you very much but windows's readme says: rxtxSerial.dll had to be recomopiled to link in missing native methods. should I ignore it? or what? thanks again also I understand that I should use mingw not cygwin I'll try to install mingw On Mar 21, 2006, at 12:36 AM, Trent Jarvi wrote: > On Tue, 21 Mar 2006, Dmitry Markman wrote: > >> Hi >> can somebody send me latest linux and windows binaries, please? >> >> or where I can find them (I didn't find them in the latest tareball) >> >> I gave up with my cygwin: something wrong I have no idea what >> java doesn't understand /cygwin/c syntax >> after I changed makefile it did java part >> but after that gcc 3.4.4 started to complain >> I set buffer length to 999 lines but I didn't get beginning of the >> story >> something wrong with my 1.4.2_09/include/jni.h gcc doesn't like it >> anyway I gave up >> >> thanks in advance >> > > Hi Dmitry > > The bins are here: > > ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7-bins-r2.zip > > Here are the files in the zip you want. > > Jar: > > rxtx-2.1-7-bins-r2/RXTXcomm.jar > > Windows: > > rxtx-2.1-7-bins-r2/Windows/i368-mingw32/rxtxSerial.dll > > Linux (x86) > > rxtx-2.1-7-bins-r2/Linux/i686-unknown-linux-gnu/librxtxSerial.so > > There are others in there including Parallel port support but those > are the main ones for testing. > > -- > Trent Jarvi > tjarvi at qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx Dmitry Markman From tjarvi at qbang.org Mon Mar 20 23:20:33 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 20 Mar 2006 23:20:33 -0700 (MST) Subject: [Rxtx] binaries request In-Reply-To: References: <42702213-C222-4937-A585-7CFB17E47608@mac.com> Message-ID: On Tue, 21 Mar 2006, Dmitry Markman wrote: > thank you very much > > but windows's readme says: > rxtxSerial.dll had to be recomopiled to link in missing native methods. > > should I ignore it? or what? > Hi Dmitry That dll should be OK. r2 is the recompile linked to the missing native method. The readme explains why it was recompiled; fuser.o was not linked into the dll in the first release. -- Trent Jarvi tjarvi at qbang.org From ariantristan at yahoo.com Mon Mar 20 23:55:24 2006 From: ariantristan at yahoo.com (Lambok Sianturi) Date: Mon, 20 Mar 2006 22:55:24 -0800 (PST) Subject: [Rxtx] jvm issue Message-ID: <20060321065524.94779.qmail@web50701.mail.yahoo.com> Hi All, This is my first time to join RxTx mailing list. I thank you all for allowing others to sign in in requests help. I use the latest RxTx lib in Fedora 3 with java version 1.4.2_09 b05. And I got this error: # # An unexpected error has been detected by HotSpot Virtual Machine: # # SIGSEGV (0xb) at pc=0x00bf27f3, pid=2633, tid=3086112448 # # Java VM: Java HotSpot(TM) Client VM (1.4.2_09-b05 mixed mode) # Problematic frame: # C [ld-linux.so.2+0xa7f3] # # An error report file with more information is saved as hs_err_pid2633.log # # If you would like to submit a bug report, please visit: # http://java.sun.com/webapps/bugreport/crash.jsp # ./run.sh: line 3: 2633 Aborted /usr/local/java/bin/java -Djava.library.path=/usr/local/java/jre/lib/ -Djsmsengine.debug=true -classpath jsmsengine.jar:smsgateway.jar:classes12.jar:RXTXcomm.jar:. com.api.sms.SMSServer What is the jvm depedency for the latest library? Can I use 1.4.2_09 b05? Thanks in advance. Arian --------------------------------- Yahoo! Mail Use Photomail to share photos without annoying attachments. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060320/83d58dd7/attachment-0009.html From f.frumento at ngi.it Tue Mar 21 00:21:47 2006 From: f.frumento at ngi.it (Fabio Frumento) Date: Tue, 21 Mar 2006 08:21:47 +0100 Subject: [Rxtx] Javadoc on the go Message-ID: <441FA98B.9050701@ngi.it> Hi Trent, sorry for the big delay but my job is running wild, i was out for some time but now i'm back and ready to continue the javadoc for Rxtx. Did you used the last javadoc patch i sent you ? let me know if i have to send it to you again or not. regards Fabio From lyon at docjava.com Tue Mar 21 00:51:18 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Tue, 21 Mar 2006 02:51:18 -0500 Subject: [Rxtx] lock files Message-ID: Hi All, You know, if the use of lock files were under Java control (rather than a build-time decision), it might enable a more unified binary distro. It might also facilitate quick prototyping of non-lock file approaches to resolving serial port contention issues (i.e., mac-like approaches vs. linux approaches, etc.). I realize that this is a radical overhaul of the lock file policy issue. Also, it may harm performance. On the other hand, our benchmarks on JNI overhead for modern processors indicate performance impact should be minimal. Perhaps it is more of an issue with the toybox systems. Suppose there were a class with a reasonable default...someone might write: SerialPortLockPolicy.setPolicy(SerialPortLockPolicy.UNIX_LOCK_FILE); SerialPortLockPolicy.setPolicy(SerialPortLockPolicy.NO_LOCK_CHECKING); SerialPortLockPolicy.setPolicy(SerialPortLockPolicy.MAC_STYLE); Thus, we could have a run-time reconfiguration of the serial port lock policy. A special NO_LOCK version of the binary would no longer be required. Any thoughts on this? Thanks! - Doug From joachim at buechse.de Tue Mar 21 03:09:09 2006 From: joachim at buechse.de (Joachim Buechse) Date: Tue, 21 Mar 2006 11:09:09 +0100 Subject: [Rxtx] lock files In-Reply-To: References: Message-ID: <8E12916A-1B9A-4FF2-B684-E2D1C794221B@buechse.de> This is pretty much what I thought about when I suggested, that the default behaviour could be overwritten with a property. I am very much in favor of this approach. In particular this allows much easier debugging for PC based java developers. I think big parts of the Java (and maybe some parts of the C code) could use a bit of a structural workover (unit tests, javadoc, synchronization, etc). Maybe there should be a CVS branch for this experimental version. I'd be happy to contribute a first workover for some of the Java code. Designing for testability and implementing a good bunch of unit tests has been a strategy that worked quite well in the Java projects I lead. And it ultimately allows more liberal change permission. Regards, Joachim On 21.03.2006, at 08:51, Dr. Douglas Lyon wrote: > Hi All, > You know, if the use of lock files were > under Java control (rather than a build-time decision), > it might enable a more unified binary distro. It might also > facilitate quick prototyping of non-lock file approaches > to resolving serial port contention issues (i.e., mac-like > approaches vs. linux approaches, etc.). > > I realize that this is a radical overhaul of the lock file policy > issue. Also, it may harm performance. On the other hand, > our benchmarks on JNI overhead for modern processors indicate > performance impact should be minimal. Perhaps it is more of > an issue with the toybox systems. > > Suppose there were a class with a reasonable default...someone > might write: > SerialPortLockPolicy.setPolicy(SerialPortLockPolicy.UNIX_LOCK_FILE); > SerialPortLockPolicy.setPolicy(SerialPortLockPolicy.NO_LOCK_CHECKING); > SerialPortLockPolicy.setPolicy(SerialPortLockPolicy.MAC_STYLE); > > Thus, we could have a run-time reconfiguration of the serial port lock > policy. A special NO_LOCK version of the binary would no longer > be required. > > Any thoughts on this? > > Thanks! > - Doug > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From joachim at buechse.de Tue Mar 21 06:23:08 2006 From: joachim at buechse.de (Joachim Buechse) Date: Tue, 21 Mar 2006 14:23:08 +0100 Subject: [Rxtx] PATCH: use of ioctl(fd, TIOCEXCL) instead of lockfiles Message-ID: <923AE774-EEA2-4911-92D8-32BB27802C8B@buechse.de> Here is the patch for the ioctl(fd, TIOCEXCL). I have verified this only for OSX 10.4.5, hence it is only defined for APPLE. However, it should work at least for Solaris as well. If a process has requested TIOEXCL further open calls by other user processes will fail. The patch also disables uucp style locking for APPLE. Obviously this is discussable. I think it is the way to go, as it eliminates creating the lock directory which doesnt exist on the standard installation and it eliminates messing with the system group definitions (adding users to group uucp). Regarding the possibility of root processes opening a device which is locked - I consider this a feature not a potential problem. It is highly unlikely, that somebody is crazy enough to run a JavaVM as root (unless he has no other means of getting a restricted IP port opened, ie doesnt understand ipfw). Anyway, even if the process runs as root, it fails when calling ioctl(fd, TIOCEXCL). It could however still open the port to listen for RING events. I.e. a fax server which needs to see incoming calls but otherwise doesnt want to block the port. So the only case where the proposed mechanism fails is, if an incorrectly implemented process running as root conflicts with a user process. I think this can be accepted. Regards, Joachim PS: If this patch is generally accepted, the installer and Mac doku should obviously be changed as well. Index: SerialImp.c =================================================================== RCS file: /usr/local/cvsroot/rxtx-devel/src/SerialImp.c,v retrieving revision 1.46.2.187 diff -u -r1.46.2.187 SerialImp.c --- SerialImp.c 29 Jan 2006 22:19:04 -0000 1.46.2.187 +++ SerialImp.c 21 Mar 2006 12:59:16 -0000 @@ -656,6 +656,25 @@ fd=OPEN (filename, O_RDWR | O_NOCTTY | O_NONBLOCK ); } while (fd < 0 && errno==EINTR); +#ifdef OPEN_EXCL + // Note that open() follows POSIX semantics: multiple open() calls to + // the same file will succeed unless the TIOCEXCL ioctl is issued. + // This will prevent additional opens except by root-owned processes. + // See tty(4) ("man 4 tty") and ioctl(2) ("man 2 ioctl") for details. + + if (fd >= 0 && (ioctl(fd, TIOCEXCL) == -1)) + { + sprintf( message, "open: exclusive access denied for % s\n", + filename ); + report( message ); + report_error( message ); + + close(fd); + goto fail; + } +#endif /* OPEN_EXCL */ + + if( configure_port( fd ) ) goto fail; (*env)->ReleaseStringUTFChars( env, jstr, filename ); sprintf( message, "open: fd returned is %i\n", fd ); Index: SerialImp.h =================================================================== RCS file: /usr/local/cvsroot/rxtx-devel/src/SerialImp.h,v retrieving revision 1.11.2.49 diff -u -r1.11.2.49 SerialImp.h --- SerialImp.h 5 Jul 2005 17:47:21 -0000 1.11.2.49 +++ SerialImp.h 21 Mar 2006 12:59:17 -0000 @@ -135,7 +135,8 @@ /*# define LOCKDIR "/var/spool/uucp"*/ # define LOCKDIR "/var/lock" # define LOCKFILEPREFIX "LK." -# define UUCP +/*# define UUCP*/ +# define OPEN_EXCL #endif /* __APPLE__ */ #if defined(__NetBSD__) # define DEVICEDIR "/dev/" From tjarvi at qbang.org Tue Mar 21 10:26:08 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 21 Mar 2006 10:26:08 -0700 (MST) Subject: [Rxtx] Javadoc on the go In-Reply-To: <441FA98B.9050701@ngi.it> References: <441FA98B.9050701@ngi.it> Message-ID: On Tue, 21 Mar 2006, Fabio Frumento wrote: > Hi Trent, > > sorry for the big delay but my job is running wild, i was out for some > time but now i'm back and ready to continue the javadoc for Rxtx. > > Did you used the last javadoc patch i sent you ? let me know if i have to > send it to you again or not. > > regards > > Fabio Hi Fabio The patch is in the rxtx mail-list archives. It will be going in soon. I did not see a time critical portion. I'll probably be going through the list since the last batch of patches this weekend and putting them into CVS. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Tue Mar 21 10:57:18 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 21 Mar 2006 10:57:18 -0700 (MST) Subject: [Rxtx] jvm issue In-Reply-To: <20060321065524.94779.qmail@web50701.mail.yahoo.com> References: <20060321065524.94779.qmail@web50701.mail.yahoo.com> Message-ID: On Mon, 20 Mar 2006, Lambok Sianturi wrote: > Hi All, > This is my first time to join RxTx mailing list. I thank you all for allowing others to sign in in requests help. > I use the latest RxTx lib in Fedora 3 with java version 1.4.2_09 b05. And I got this error: > > # > # An unexpected error has been detected by HotSpot Virtual Machine: > # > # SIGSEGV (0xb) at pc=0x00bf27f3, pid=2633, tid=3086112448 > # > # Java VM: Java HotSpot(TM) Client VM (1.4.2_09-b05 mixed mode) > # Problematic frame: > # C [ld-linux.so.2+0xa7f3] A native library loading error? What happens if you recompile rxtx on your system and install that? This sounds like an ABI problem? rxtx 2.1-7 was compiled with a gcc 2.96 toolchain as I recall. The hope is newer system will be backwards compatible. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Tue Mar 21 11:05:29 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 21 Mar 2006 11:05:29 -0700 (MST) Subject: [Rxtx] PATCH: use of ioctl(fd, TIOCEXCL) instead of lockfiles In-Reply-To: <923AE774-EEA2-4911-92D8-32BB27802C8B@buechse.de> References: <923AE774-EEA2-4911-92D8-32BB27802C8B@buechse.de> Message-ID: On Tue, 21 Mar 2006, Joachim Buechse wrote: > Here is the patch for the ioctl(fd, TIOCEXCL). I have verified this only > for OSX 10.4.5, hence it is only defined for APPLE. However, it should > work at least for Solaris as well. > > If a process has requested TIOEXCL further open calls by other user > processes will fail. > > The patch also disables uucp style locking for APPLE. Obviously this is > discussable. I think it is the way to go, as it eliminates creating the > lock directory which doesnt exist on the standard installation and it > eliminates messing with the system group definitions (adding users to > group uucp). > > Regarding the possibility of root processes opening a device which is > locked - I consider this a feature not a potential problem. It is highly > unlikely, that somebody is crazy enough to run a JavaVM as root (unless > he has no other means of getting a restricted IP port opened, ie doesnt > understand ipfw). Anyway, even if the process runs as root, it fails when > calling ioctl(fd, TIOCEXCL). It could however still open the port to > listen for RING events. I.e. a fax server which needs to see incoming > calls but otherwise doesnt want to block the port. So the only case where > the proposed mechanism fails is, if an incorrectly implemented process > running as root conflicts with a user process. I think this can be > accepted. > > Regards, > Joachim > > PS: If this patch is generally accepted, the installer and Mac doku > should obviously be changed as well. > > > Index: SerialImp.c > =================================================================== > RCS file: /usr/local/cvsroot/rxtx-devel/src/SerialImp.c,v > retrieving revision 1.46.2.187 > diff -u -r1.46.2.187 SerialImp.c > --- SerialImp.c 29 Jan 2006 22:19:04 -0000 1.46.2.187 > +++ SerialImp.c 21 Mar 2006 12:59:16 -0000 > @@ -656,6 +656,25 @@ > fd=OPEN (filename, O_RDWR | O_NOCTTY | O_NONBLOCK ); > } while (fd < 0 && errno==EINTR); > > +#ifdef OPEN_EXCL > + // Note that open() follows POSIX semantics: multiple open() > calls to > + // the same file will succeed unless the TIOCEXCL ioctl is > issued. > + // This will prevent additional opens except by root-owned > processes. > + // See tty(4) ("man 4 tty") and ioctl(2) ("man 2 ioctl") for > details. > + > + if (fd >= 0 && (ioctl(fd, TIOCEXCL) == -1)) > + { > + sprintf( message, "open: exclusive access denied for % > s\n", > + filename ); > + report( message ); > + report_error( message ); > + > + close(fd); > + goto fail; > + } > +#endif /* OPEN_EXCL */ > + > + > if( configure_port( fd ) ) goto fail; > (*env)->ReleaseStringUTFChars( env, jstr, filename ); > sprintf( message, "open: fd returned is %i\n", fd ); > Index: SerialImp.h > =================================================================== > RCS file: /usr/local/cvsroot/rxtx-devel/src/SerialImp.h,v > retrieving revision 1.11.2.49 > diff -u -r1.11.2.49 SerialImp.h > --- SerialImp.h 5 Jul 2005 17:47:21 -0000 1.11.2.49 > +++ SerialImp.h 21 Mar 2006 12:59:17 -0000 > @@ -135,7 +135,8 @@ > /*# define LOCKDIR "/var/spool/uucp"*/ > # define LOCKDIR "/var/lock" > # define LOCKFILEPREFIX "LK." > -# define UUCP > +/*# define UUCP*/ > +# define OPEN_EXCL > #endif /* __APPLE__ */ > #if defined(__NetBSD__) > # define DEVICEDIR "/dev/" > This looks like a good start. What do you think Dmitry? Perhaps all systems with TIOCEXCL defined should use that though. Even if they use lockfiles. It wont hurt anything. That would catch people hacking their own serial apps without checking lockfiles. Its a good idea to avoid C++ style comments in the C portions. Some older systems don't deal with them well. If it's just for Mac OS X, it isn't a big deal. I think it was the Irix compiler that was problematic? -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Tue Mar 21 11:22:05 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 21 Mar 2006 11:22:05 -0700 (MST) Subject: [Rxtx] lock files In-Reply-To: <8E12916A-1B9A-4FF2-B684-E2D1C794221B@buechse.de> References: <8E12916A-1B9A-4FF2-B684-E2D1C794221B@buechse.de> Message-ID: We can try it. Maybe the JNI is much improved. The nice thing about linking into liblock is distros then worry about lockfiles on their systems. This way, we have to deal with any changes that may show up. On Tue, 21 Mar 2006, Joachim Buechse wrote: > This is pretty much what I thought about when I suggested, that the > default behaviour could be overwritten with a property. I am very much in > favor of this approach. In particular this allows much easier debugging > for PC based java developers. > > I think big parts of the Java (and maybe some parts of the C code) could > use a bit of a structural workover (unit tests, javadoc, synchronization, > etc). Maybe there should be a CVS branch for this experimental version. > I'd be happy to contribute a first workover for some of the Java code. > Designing for testability and implementing a good bunch of unit tests has > been a strategy that worked quite well in the Java projects I lead. And > it ultimately allows more liberal change permission. > > Regards, > Joachim > > > On 21.03.2006, at 08:51, Dr. Douglas Lyon wrote: > >> Hi All, >> You know, if the use of lock files were >> under Java control (rather than a build-time decision), >> it might enable a more unified binary distro. It might also >> facilitate quick prototyping of non-lock file approaches >> to resolving serial port contention issues (i.e., mac-like >> approaches vs. linux approaches, etc.). >> >> I realize that this is a radical overhaul of the lock file policy >> issue. Also, it may harm performance. On the other hand, >> our benchmarks on JNI overhead for modern processors indicate >> performance impact should be minimal. Perhaps it is more of >> an issue with the toybox systems. >> >> Suppose there were a class with a reasonable default...someone >> might write: >> SerialPortLockPolicy.setPolicy(SerialPortLockPolicy.UNIX_LOCK_FILE); >> SerialPortLockPolicy.setPolicy(SerialPortLockPolicy.NO_LOCK_CHECKING); >> SerialPortLockPolicy.setPolicy(SerialPortLockPolicy.MAC_STYLE); >> >> Thus, we could have a run-time reconfiguration of the serial port lock >> policy. A special NO_LOCK version of the binary would no longer >> be required. >> >> Any thoughts on this? >> >> Thanks! >> - Doug >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From dmarkman at mac.com Tue Mar 21 16:05:17 2006 From: dmarkman at mac.com (Dmitry Markman) Date: Tue, 21 Mar 2006 18:05:17 -0500 Subject: [Rxtx] PATCH: use of ioctl(fd, TIOCEXCL) instead of lockfiles In-Reply-To: References: <923AE774-EEA2-4911-92D8-32BB27802C8B@buechse.de> Message-ID: <512AC70C-BB86-48F2-A83C-023F35C23BAB@mac.com> I think it's cool, but I'd like to have that property implementation when user can choose between locking mechanism about comments: it's easy to change comments to the C style or we can use extensions of the file to cpp so c++ compiler will be used On Mar 21, 2006, at 1:05 PM, Trent Jarvi wrote: > This looks like a good start. What do you think Dmitry? Perhaps > all systems with TIOCEXCL defined should use that though. Even if > they use lockfiles. It wont hurt anything. That would catch > people hacking their own serial apps without checking lockfiles. > > Its a good idea to avoid C++ style comments in the C portions. > Some older systems don't deal with them well. If it's just for Mac > OS X, it isn't a big deal. I think it was the Irix compiler that > was problematic? Dmitry Markman From dmarkman at mac.com Tue Mar 21 16:13:00 2006 From: dmarkman at mac.com (Dmitry Markman) Date: Tue, 21 Mar 2006 18:13:00 -0500 Subject: [Rxtx] PATCH: use of ioctl(fd, TIOCEXCL) instead of lockfiles In-Reply-To: References: <923AE774-EEA2-4911-92D8-32BB27802C8B@buechse.de> Message-ID: I'd like to add that creating locking folder isn't a big deal we never had a problem related to the lock folders, because we always used installer on mac os x from other hand I'm not very much familiar with iotcl locking approach and I'm not sure it's more efficient Joachim wrote "I think it is the way to go, as it eliminates creating the lock directory which doesnt exist on the standard installation and it eliminates messing with the system group definitions (adding users to group uucp)." but I really didn't have any problem with that 1. doesn't exist on the standard installation there are many-many things that don't exist in the standard installation so I don't think that argument is strong enough 2. messing with the system group definitions I don't think we're messing with the group definition mac os x provides very clear way to set up group's members and together with Greg Guerin AuthKit there is no problem to set those definitions so I don't think that argument is strong either but from other hand using iotcl is more promising and is more elegant On Mar 21, 2006, at 1:05 PM, Trent Jarvi wrote: > > This looks like a good start. What do you think Dmitry? Perhaps > all systems with TIOCEXCL defined should use that though. Even if > they use lockfiles. It wont hurt anything. That would catch > people hacking their own serial apps without checking lockfiles. Dmitry Markman From joachim at buechse.de Wed Mar 22 04:46:45 2006 From: joachim at buechse.de (Joachim Buechse) Date: Wed, 22 Mar 2006 12:46:45 +0100 Subject: [Rxtx] PATCH: use of ioctl(fd, TIOCEXCL) instead of lockfiles In-Reply-To: References: <923AE774-EEA2-4911-92D8-32BB27802C8B@buechse.de> Message-ID: Sorry, I was not very clear with my arguments, so I will try again;-) Please, don't take this as an attack against work that has been done. I think the contributions that have been made in the past were made in a good spirit. But I really believe, that the current solution for OSX has many shortcomings and should be changed as soon as possible. lock files --- The /var/lock folder does not exist on the standard OSX installation, however the standard installation includes several applications that use serial ports (i.e. the FAX capability). This indicates, that the lock folder approach will not work well with system components. Applications for OSX will generally try to live in harmony with system components (except for HP print drivers of course). I think RXTX should follow this approach as well. uucp group --- Accessing serial ports is not an admin privileged operation on OSX. Any user (world) has read/write privileges on /dev/tty*. So the system default is to not enforce any group membership to access these ports. The group uucp however is a system group on all unix systems I know. It exists for certain system processes. A non admin user should in general not be a member of this group. Quite arguably no user should ever be a member of this group. Installer --- My general opinion is, that - no Installer should touch user or group data without warning - no Application Installer should touch groups which are not specific to the very application installed - no Installer should ever add regular users to a system group The current installer injects the installing user in the group uucp without warning about this change and without giving the option to "opt out" of this change. This is a potential security risk (but not currently a real one, as OSX contains no folders belonging to group uucp). The current installer does not work for multi user systems. It puts the installing user in the uucp group. However the installing user is not necessarily the user that will use the application. Putting all users that may use a serial port application in the system group uucp seems like a very invasive approach to me. Besides that, newly created users will not automatically be in the group and hence, serial applications will "break" for new users without obvious reasons. Avoiding the lock files will allow self contained applications (i.e. drag&drop installation). In my eyes this is largely preferable over an installer that requests admin privileges. Adding up all these points indicates very strongly, that the lock-file implementation is not the way to go on OSX. Regards, Joachim On 22.03.2006, at 00:13, Dmitry Markman wrote: > I'd like to add that > > creating locking folder isn't a big deal > we never had a problem related to the lock folders, because we > always used installer on mac os x > from other hand I'm not very much familiar with iotcl locking > approach and I'm not sure it's more efficient > > Joachim wrote "I think it is the way to go, as it eliminates > creating the lock directory which doesnt exist on the standard > installation and it eliminates messing with the system group > definitions (adding users to group uucp)." but I really didn't have > any problem with that > > 1. doesn't exist on the standard installation > there are many-many things that don't exist in the standard > installation so I don't think that argument is strong enough > 2. messing with the system group definitions > I don't think we're messing with the group definition > mac os x provides very clear way to set up group's members and > together with Greg Guerin AuthKit there is no problem to set those > definitions > so I don't think that argument is strong either > but from other hand using iotcl is more promising and is more elegant > > > > On Mar 21, 2006, at 1:05 PM, Trent Jarvi wrote: > >> >> This looks like a good start. What do you think Dmitry? Perhaps >> all systems with TIOCEXCL defined should use that though. Even if >> they use lockfiles. It wont hurt anything. That would catch >> people hacking their own serial apps without checking lockfiles. > > Dmitry Markman > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From dmarkman at mac.com Wed Mar 22 05:27:13 2006 From: dmarkman at mac.com (Dmitry Markman) Date: Wed, 22 Mar 2006 07:27:13 -0500 Subject: [Rxtx] PATCH: use of ioctl(fd, TIOCEXCL) instead of lockfiles In-Reply-To: References: <923AE774-EEA2-4911-92D8-32BB27802C8B@buechse.de> Message-ID: <83440CF3-DCD8-41C1-B941-F227232C27E3@mac.com> thanks for the very good explanation I didn't think that you were attacking any thing, so don't worry I just had feeling, that there were more aesthetic reasons for going to ioctl then real necessity now you explained everything quite well (BTW, asfar as I remember installer asks admin password so it wasn't quiet, but it really doesn't matter now) thanks On Mar 22, 2006, at 6:46 AM, Joachim Buechse wrote: > Sorry, I was not very clear with my arguments, so I will try again;-) > > Please, don't take this as an attack against work that has been > done. I think the contributions that have been made in the past > were made in a good spirit. But I really believe, that the current > solution for OSX has many shortcomings and should be changed as > soon as possible. > > lock files > --- > The /var/lock folder does not exist on the standard OSX > installation, however the standard installation includes several > applications that use serial ports (i.e. the FAX capability). This > indicates, that the lock folder approach will not work well with > system components. Applications for OSX will generally try to live > in harmony with system components (except for HP print drivers of > course). I think RXTX should follow this approach as well. > > uucp group > --- > Accessing serial ports is not an admin privileged operation on OSX. > Any user (world) has read/write privileges on /dev/tty*. So the > system default is to not enforce any group membership to access > these ports. The group uucp however is a system group on all unix > systems I know. It exists for certain system processes. A non admin > user should in general not be a member of this group. Quite > arguably no user should ever be a member of this group. > > Installer > --- > My general opinion is, that > - no Installer should touch user or group data without warning > - no Application Installer should touch groups which are not > specific to the very application installed > - no Installer should ever add regular users to a system group > > The current installer injects the installing user in the group uucp > without warning about this change and without giving the option to > "opt out" of this change. This is a potential security risk (but > not currently a real one, as OSX contains no folders belonging to > group uucp). > > The current installer does not work for multi user systems. It puts > the installing user in the uucp group. However the installing user > is not necessarily the user that will use the application. Putting > all users that may use a serial port application in the system > group uucp seems like a very invasive approach to me. Besides that, > newly created users will not automatically be in the group and > hence, serial applications will "break" for new users without > obvious reasons. > > > Avoiding the lock files will allow self contained applications > (i.e. drag&drop installation). In my eyes this is largely > preferable over an installer that requests admin privileges. Adding > up all these points indicates very strongly, that the lock-file > implementation is not the way to go on OSX. > > Regards, > Joachim > > > On 22.03.2006, at 00:13, Dmitry Markman wrote: > >> I'd like to add that >> >> creating locking folder isn't a big deal >> we never had a problem related to the lock folders, because we >> always used installer on mac os x >> from other hand I'm not very much familiar with iotcl locking >> approach and I'm not sure it's more efficient >> >> Joachim wrote "I think it is the way to go, as it eliminates >> creating the lock directory which doesnt exist on the standard >> installation and it eliminates messing with the system group >> definitions (adding users to group uucp)." but I really didn't >> have any problem with that >> >> 1. doesn't exist on the standard installation >> there are many-many things that don't exist in the standard >> installation so I don't think that argument is strong enough >> 2. messing with the system group definitions >> I don't think we're messing with the group definition >> mac os x provides very clear way to set up group's members and >> together with Greg Guerin AuthKit there is no problem to set those >> definitions >> so I don't think that argument is strong either >> but from other hand using iotcl is more promising and is more elegant >> >> >> >> On Mar 21, 2006, at 1:05 PM, Trent Jarvi wrote: >> >>> >>> This looks like a good start. What do you think Dmitry? Perhaps >>> all systems with TIOCEXCL defined should use that though. Even >>> if they use lockfiles. It wont hurt anything. That would catch >>> people hacking their own serial apps without checking lockfiles. >> >> Dmitry Markman >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx Dmitry Markman From lyon at docjava.com Wed Mar 22 06:12:18 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Wed, 22 Mar 2006 08:12:18 -0500 Subject: [Rxtx] sole of a new design pattern Message-ID: Hi All, I have been thinking about how we design the serial port software. I think we need a new design pattern. For lack of a better term, I shall call it: The Parametric Singleton Design Pattern By Douglas A. Lyon ABSTRACT The goal of the singleton design pattern is to make sure that there is one, and only one, instance of a given class. The goal of the parametric singleton design pattern is to make sure that there is one, and only one, instance of a given class with the given parametric values. We parametric singleton design pattern combines the singleton design pattern with a parameter that enables unique creation of instances of a class. These instances are cached. When a user asks for an instance with these parameters, the cache is checked. If the instance is in the cache, the instance is returned, otherwise it is created, added to the cache and then returned. We apply our parametric singleton design pattern to the retrieval of RMI registries bound to a given port. The goal of our system is to make sure that no two RMI registries are listening to the same socket and to make use of the RMI registries after they have been created. RMI registries are used in distributed computation. Introduction The singleton design pattern is meant to ensure that on a single instance of a class exists. It is also meant to provide a global point of access to it. The intent of the parametric singleton design pattern is to ensure that a class has only one instance for a given set of parameter values. It also provides a global point of access to it. Motivation A system cannot tolerate multiple instances of some classes with identical parameters. For example, you cannot have two instances making use of the same serial port, at the same time. You cannot have two instances that are trying to listen to the same socket connection. You cannot have two instances writing to the same file structure at the same time. As the operating system is often thought of as the arbiter of consumed resources (i.e., tape drives, serial ports, etc.) we frequently leave it to an operating system implementation to resolve these contention issues. Even for similar resources (like serial ports) there are few standards for handling contention. For example, serial ports on Linux are locked using a "/var/lock" file. POSIX, on the other hand, uses ioctl mechanisms to prevent contention. A better solution is to make a class that is responsible for keeping track of the instances created from the class. The class is declared final, so that it cannot be subclassed. The class also has a private constructor, so that other classes cannot instance it. The new design pattern is called the parametric singleton design pattern and it provides a way to access and create instances with given parameters. Applicability Use the Parametric Singleton Design Pattern when: 1. There must be exactly one instance of a class with the given parameters. 2. The instances must be accessible to clients from a well-known access point. Structure Insert UML diagram here. Participants The Parametric Singleton Clients that need instances 1. The Parametric Singleton defines an instance upon request from a client, if, and only if, the instance does not already exist. 2. The Parametric Singleton returns the instance to the client. 3. The Parametric Singleton is responsible for creating unique instances from given parameters. Collaborations Clients obtain a reference to a Parametric Singleton instance only through the parametric singleton design pattern. If the instance is left in an improper state (e.g., the serial port was left open) it is NOT the role of the Parametric Singleton Design Pattern to close the IO port. Nor is it the role of the Parametric Singleton Design Pattern to open the port. That role is delegate to some other part of the system. Further, it is not the role of the Parametric Singleton Design Pattern to check out resources. That is, multiple threads can have multiple references to the same resource at the same time. MUTEX locking is delegated to some other part of the system. Consequences The Parametric Singleton Design Pattern has several benefits: 1. Controlled access to parametrically defined instances. Since the Parametric Singleton class encapsulates its instances, there is control over how and when clients access it. 2. Reduced name space. The Parametric Singleton pattern avoids global variables that store instances created from the same parameter. Implementation Here are implementation issues to consider when using the Parametric Singleton pattern: 1. Unique mapping of parameters. The Parametric Singleton pattern requires that there be a mean to isomorphically map the parameter space into the instance space and back again. 2. Ensure unique instances. The Parametric Singleton pattern makes unique instances from parameters, and it does so only once. 3. Cache instances for fast retrieval. The Parametric Singleton pattern must be able to look up instances, given some set of parameters, and do so from some data structure. That is, there must be enough space to hold references to all the instances the program will need. Also, a mechanism is needed to look up and retrieve the instances quickly enough to satisfy the clients. Sample Code public final class ParametricSingletonRmiRegistry { private static Hashtable registry = new Hashtable(100); // use singleton pattern and??????????????????????????????????????????????? // prevent instantiation of RmiRegistryUtils.?????????????????????????????? private ParametricSingletonRmiRegistry() { } // the only instance of the Registry held by the RmiRegistryUtils?????????? public static void listNames(Integer port) { if (!isInCacheAndRunning(port)) return; Registry r = (Registry) registry.get(port); System.out.println("registry on port: " + port); System.out.println("registry: " + r); System.out.println("names: "); try { print(r.list()); } catch (RemoteException e) { In.message(e); } System.out.println("------------------------"); } /**???????????????????????????????????????????????????????????????????????? * Checks whether a Registry has been started on this host????????????????? * in the specified port.?????????????????????????????????????????????????? * If not, it tries to start one.?????????????????????????????????????????? * when it fails to start a Registry, it exits the program????????????????? * with exit code 1.??????????????????????????????????????????????????????? */ public static void restart(int port) { if (isInCacheAndRunning(port)) return; try { startRegistry(port); } catch (RemoteException e) { In.message(e); } } /**???????????????????????????????????????????????????????????????????????? * @param port????????????????????????????????????????????????????????????? * @return true if registry is in cache and running???????????????????????? */ private static boolean isInCacheAndRunning(Integer port) { if (!isRegistryRunning(port.intValue())) return false; if (!isRegistryInCache(port.intValue())) return false; return true; } /**???????????????????????????????????????????????????????????????????????? * @param port????????????????????????????????????????????????????????????? * @return true if we are able to locate a local registry on port.??????????????????????????????????????????????????????????????????????????? */ private static boolean isRegistryRunning(int port) { try { Registry r = LocateRegistry.getRegistry(port); if (r != null) return true; } catch (RemoteException e) { return false; } return false; } /**???????????????????????????????????????????????????????????????????????? * @param port????????????????????????????????????????????????????????????? * @return return true if registry is in cache????????????????????????????? */ private static boolean isRegistryInCache(int port) { if (registry.get(new Integer(port)) == null) return false; return true; } /**???????????????????????????????????????????????????????????????????????? * Restart the registry, if needed.???????????????????????????????????????? * Return the only instance of the registry for consistent global?????????? * using by making use of the Singleton Design Pattern????????????????????? *????????????????????????????????????????????????????????????????????????? * @return the internally held registry instance.?????????????????????????? */ public static Registry getRegistry(Integer port) { restart(port); return (Registry) registry.get(port); } private static void startRegistry(Integer port) throws RemoteException { Registry r; try { r = LocateRegistry.createRegistry(port.intValue()); registry.put(port, r); //r = new sun.rmi.registry.RegistryImpl???????????????????????????? /// (port.intValue());?????????????????????????????????????? // registry.put(port, r);?????????????????????????????????????????? } catch (Exception e) { //e.printStackTrace();????????????????????????????????????????????? r = LocateRegistry.getRegistry(port.intValue()); registry.put(port, r); } } public static void main(String args[]) throws RemoteException { //restart(port);??????????????????????????????????????????????????????? restart(5001); restart(5002); restart(5002); Registry r = LocateRegistry.getRegistry(5002); System.out.println("registry="+r); } } I would very much like to get your feedback on this new design pattern idea. Thank you for your time. Regards, - Doug From david.garnier at trusted-logic.com Wed Mar 22 07:36:10 2006 From: david.garnier at trusted-logic.com (David Garnier) Date: Wed, 22 Mar 2006 15:36:10 +0100 Subject: [Rxtx] sole of a new design pattern In-Reply-To: References: Message-ID: <442160DA.80107@trusted-logic.com> Hello, > The Parametric Singleton Design Pattern The Singleton is the most abused design pattern ever. Good use-cases for this pattern are extremely rare and mostly confined to problems related to hardware resources, like serial ports. > Applicability > > Use the Parametric Singleton Design Pattern when: > 1. There must be exactly one instance of a class with the given > parameters. OK. As I said above, this case this actually very unusual. The Singleton pattern is mostly used when : > 2. The instances must be accessible to clients from a well-known > access point. Using the singleton pattern in this case is just convenient for the programmer. Problems arises pretty quickly, especially if you attempt to unit-test your classes. 1) If your singleton is stateful, or hold on to stateful objects, it means that two different unit tests are not actually independent. Instead of starting with a brand new environment, the result of a test may be affected by the result of a previous test. This problem also arise when with your class relies on a database. In both cases, the solution is to reset your "unique" resource (Singleton or database) at the beginning of the test, which is a pain. Also, while most projects connect to a single database, projects that allow the use of Singletons usually contain several of thems, and new ones may cropped up unnoticed. You quickly end up with test cases that only pass in a certain order, which is a royal pain. 2) You cannot mockup a singleton. Once everyone calls the SomeSingleton class statically, you can't replace your class by SomeSingletonMockup. Furthermore, even for hardware services, the Singleton pattern does not really prevent concurrent accesses. If you start the same program in two different JVMs, unless they somehow shared the state of their "Singletons" (through lock files for example), the Singleton pattern will not prevent concurrent access. Our application uses RXTX, and we routinely encounter cases where another (native) application has already locked the port. Since we cannot modify the native application to recognize lock files, OS-level control is irreplaceable. > > Consequences > The Parametric Singleton Design Pattern has several benefits: > > 1. Controlled access to parametrically defined instances. Since > the Parametric Singleton class encapsulates its instances, there is > control over how and when clients access it. Not really. Once you've returned the instance to a client, you've lost control over it. The client can to whatever it wants with it. You cannot "recall" the instance or claim it back. > 2. Reduced name space. The Parametric Singleton pattern avoids > global variables that store instances created from the same parameter. Sure, but you don't have to rely on a Singleton for that. Just create a single Factory. > I would very much like to get your feedback on this new design > pattern idea. Well, it's nothing new. Some may say that it is the point of design patterns: formalizes the designs that occur again and again. However, this design is simply a combination of the Singleton and Factory patterns. I did use it in the past, but now I've been exposed to the shortcomings of the Singleton pattern, so I limit myself to Factories. Regards, David From sean_montgomery at baseview.com Wed Mar 22 08:35:28 2006 From: sean_montgomery at baseview.com (Sean Montgomery) Date: Wed, 22 Mar 2006 10:35:28 -0500 Subject: [Rxtx] sole of a new design pattern In-Reply-To: <442160DA.80107@trusted-logic.com> References: <442160DA.80107@trusted-logic.com> Message-ID: <05769CA7-A51B-4CF0-BAA0-E02DD905F5A4@baseview.com> On Mar 22, 2006, at 9:36 AM, David Garnier wrote: > Furthermore, even for hardware services, the Singleton pattern does > not really prevent concurrent > accesses. If you start the same program in two different JVMs, > unless they somehow shared the state > of their "Singletons" (through lock files for example), the > Singleton pattern will not prevent > concurrent access. > Multiple class loaders in a single JVM can be tricky, too. Then there's synchronization, lazy initialization and serialization of singletons to contend with. Bloch's Effective Java covers these, and here's a few articles: http://www.javaworld.com/javaworld/jw-04-2003/jw-0425-designpatterns- p3.html http://java.sun.com/developer/technicalArticles/Programming/singletons/ Just FYI :-) From lyon at docjava.com Wed Mar 22 08:50:48 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Wed, 22 Mar 2006 10:50:48 -0500 Subject: [Rxtx] sole of a new design pattern In-Reply-To: <442160DA.80107@trusted-logic.com> References: <442160DA.80107@trusted-logic.com> Message-ID: Hi All, First, I would like to thank David for his prompt and thoughtful remarks. I had no idea people that feel strongly about a design patterns! Wow! Feedback (particularly critical feedback) is greatly appreciated. Starting at the end, first: >I did use it in >the past, but now I've been exposed to the shortcomings of the >Singleton pattern, so I limit myself to Factories. David, if I understood your comments correctly, you suggested that Factories can be used in leu of the Singleton Design Pattern, or even the Parametric Singleton Design Pattern. As I see in [Gof]: Factory Method: Intent "Define an interface for creating an object, but let subclasses decide which class to instantiate. Factory Method lets a class defer instantiation to subclasses." The Singleton Design Pattern is a concrete class, which is rather different, right? Also, subclasses are not permitted with Singleton, as they are final. Naturally, I could use an abstract factory as a parent for a singleton. I could even design a facade that could be implemented with the singleton....but that is not the intention of the design. Unless you want a mock-up, as discussed, below: More below: >Hello, > >> The Parametric Singleton Design Pattern > >The Singleton is the most abused design pattern ever. Good use-cases >for this pattern are extremely >rare and mostly confined to problems related to hardware resources, >like serial ports. > > >> Applicability >> >> Use the Parametric Singleton Design Pattern when: >> 1. There must be exactly one instance of a class with the given >> parameters. >OK. As I said above, this case this actually very unusual. The >Singleton pattern is mostly used when : >> 2. The instances must be accessible to clients from a well-known >> access point. > >Using the singleton pattern in this case is just convenient for the >programmer. Problems arises >pretty quickly, especially if you attempt to unit-test your classes. > >1) If your singleton is stateful, or hold on to stateful objects, it >means that two different unit >tests are not actually independent. Instead of starting with a brand >new environment, the result of >a test may be affected by the result of a previous test. This >problem also arise when with your >class relies on a database. In both cases, the solution is to reset >your "unique" resource >(Singleton or database) at the beginning of the test, which is a >pain. Also, while most projects >connect to a single database, projects that allow the use of >Singletons usually contain several of >thems, and new ones may cropped up unnoticed. You quickly end up >with test cases that only pass in a >certain order, which is a royal pain. There are basic problems with communicating finite state machines that include reachability and deadlock analysis. These are addressed with petri net analysis and are beyond the scope of the design pattern. As you quite rightly pointed out; the parametric singleton pattern (or the singleton pattern, for that matter) enable multiple threads to gain access to the same instance. The only way that I can see to block others from gaining access to the reference is the synchronize keyword. This is putting a spin-lock (or MUTEX) on the reference. The question of how to unit-test a design pattern like the parametric singleton remains open. Perhaps this is a deficiency. > >2) You cannot mockup a singleton. Once everyone calls the >SomeSingleton class statically, you can't >replace your class by SomeSingletonMockup. Acutally, I am not sure that this is true. If the Singleton implements a Facade interface, it should be possible to make the replacement. Right? > >Furthermore, even for hardware services, the Singleton pattern does >not really prevent concurrent >accesses. If you start the same program in two different JVMs, >unless they somehow shared the state >of their "Singletons" (through lock files for example), the >Singleton pattern will not prevent >concurrent access. Good Point!! You have sharp eyes! The singleton design pattern should/could take responsibility for this. In fact, you may notice that my code does have an implementation (LocateRegistry) that can work across JVM's. The LocateRegistry will even work across the Internet! LocateRegistry takes both a host name and a Port (lock files just don't do this). I did not think to implement this beyond the local machine, but, in its present form, it will work across different processes. > >Our application uses RXTX, and we routinely encounter cases where >another (native) application has >already locked the port. Since we cannot modify the native >application to recognize lock files, >OS-level control is irreplaceable. The singleton design pattern is not meant to replace OS-level control, but to centralize the Java programmers access to it. If lock files, for example, are used for serial ports, the Singleton Design Pattern should be able to work with them. > > >> >> Consequences >> The Parametric Singleton Design Pattern has several benefits: >> > > 1. Controlled access to parametrically defined instances. Since >> the Parametric Singleton class encapsulates its instances, there is >> control over how and when clients access it. > >Not really. Once you've returned the instance to a client, you've >lost control over it. The client >can to whatever it wants with it. You cannot "recall" the instance >or claim it back. Good point, this should read: > 1. Controll when parametrically defined instances are created. Since > > the Parametric Singleton class encapsulates its instances, there is > > control over how and when they are instanced. > >> 2. Reduced name space. The Parametric Singleton pattern avoids >> global variables that store instances created from the same parameter. > >Sure, but you don't have to rely on a Singleton for that. Just >create a single Factory. > > Thank you for your thoughtful and prompt response! Regards, - Doug From dmarkman at mac.com Wed Mar 22 21:21:55 2006 From: dmarkman at mac.com (Dmitry Markman) Date: Wed, 22 Mar 2006 23:21:55 -0500 Subject: [Rxtx] sole of a new design pattern In-Reply-To: <442160DA.80107@trusted-logic.com> References: <442160DA.80107@trusted-logic.com> Message-ID: I don't think I get it On Mar 22, 2006, at 9:36 AM, David Garnier wrote: > Using the singleton pattern in this case is just convenient for the > programmer. Problems arises > pretty quickly, especially if you attempt to unit-test your classes. so you're saying that something isn't so good because you can not test it in the convenient way? if that's true, I'm totally disagree change your test, debug whatever, but if software is efficient at runtime, works fine and only problem is some unit test (which is some kind of framework for testing) then dump that unit test , dump that unit framework and make something appropriate to the software you're testing so if Douglas want to use singletons, what's the problem? and what do you mean by abusing of singleton usage? of course singleton doesn't prevent concurrent access to the resource across the processes unless you're using some OS facility to prevent it, besides singleton as it was introduced is relevant only and only inside of the same process otherwise it's not singleton it's something else (let's say network singleton: so you have remote invocation facility and some factory method that return object created by that facility) I don't have any problem with using any kind of singletons. Parametric Singleton idea (if I understand it right) could be easily implemented in the following way: use a map populate map with instances of some class and key is your parameter (you can use lazy population too) if somebody ask the key check the value if it's null so resource is taken if somebody returns the resource put it back to the map public synchronized static Object getSomeResource(Object parameter); public synchronized static void returnResource(Object parameter); getSomeResource (inside of the same process) could return null in 2 cases 1. if somebody (from other thread for example) already took that resource 2. if OS API said that resource corresponded to that parameter (serial port with parameter = 1 (port #)) is locked and unavailable; I'm not sure that in case of serial ports we even need those Parametric Singletons (unless lock checking is a very expensive operation) just ask the OS about availability of that resource and if it's available give it away and then OS will lock it and therefore in next time somebody ask it just answer that resource is locked and return null for example system has 2 serial ports available so I ask getResource("tty"); or I ask getResource("Bluetooth-Modem"); and if OS is ok you can give tty or Bluetooth-Modem or both no need for any additional pattern I think back to the problem mac os x doesn't recognize locking via files, so it handles locking via some API an instance of the singleton in each process should recognize that resource is locked (by using that API) that's all we don't have to make things more complicate then they are just because there is some nice design pattern or nice unit test framework or whatever keep things simple, make them work fast, don't introduce middle layers unless you have really good reason to do so of course I could be entirely wrong, so sorry about that in advance thanks Dmitry Markman From tjarvi at qbang.org Wed Mar 22 22:31:41 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 22 Mar 2006 22:31:41 -0700 (MST) Subject: [Rxtx] sole of a new design pattern In-Reply-To: References: Message-ID: Hi Doug Interesting reading. So far I'm just reading and thinking. I have one question so far. " Clients obtain a reference to a Parametric Singleton instance only through the parametric singleton design pattern. If the instance is left in an improper state (e.g., the serial port was left open) it is NOT the role of the Parametric Singleton Design Pattern to close the IO port. Nor is it the role of the Parametric Singleton Design Pattern to open the port. That role is delegate to some other part of the system. " So when the clients obtain a reference to the singleton, can they assume the port is there? IE, would it be the singletons role to handle things like USB dongles being removed with event hints comming from the underlying OS. Hardware abstraction layer/HAL on Linux is an example of underlying OS events. I assume that role too is delegated to other parts of the system? -- Trent Jarvi tjarvi at qbang.org From lyon at docjava.com Thu Mar 23 08:10:33 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Thu, 23 Mar 2006 10:10:33 -0500 Subject: [Rxtx] Classes don't need goals, they need roles! In-Reply-To: References: Message-ID: Hi Trent, Yes, I think that the role of the Parametric Singleton Pattern is not to open or close serial ports, nor is it to perform error checking. On the other hand, if you were to combine the role of the Parametric Singleton Pattern with another role (like that of error checking) it might not be amiss. However, I generally caution programmers against adding multiple roles to classes, as this leads to monolithic designs. Thus a different class (NativeLibDetect) could have the role of determining if the native library can be loaded. Another class (SerialPortBean) can have the role of serializing the default state of the serial port, so that it can be recovered, from user preferences, at a later time. The SerialPortDetect could have the role of determining if the serial port is removed (i.e., a USB port was unplugged). My guess is that each class should have a different role in the system, in order to ease maintenance and testing...but I could be wrong about that. Thanks! - Doug >Hi Doug > >Interesting reading. So far I'm just reading and thinking. I have >one question so far. > >" > Clients obtain a reference to a Parametric Singleton instance only >through the parametric singleton design pattern. If the instance is >left in an improper state (e.g., the serial port was left open) it is >NOT the role of the Parametric Singleton Design Pattern to close the >IO port. Nor is it the role of the Parametric Singleton Design Pattern >to >open the port. That role is delegate to some other part of the system. >" > >So when the clients obtain a reference to the singleton, can they >assume the port is there? IE, would it be the singletons role to >handle things like USB dongles being removed with event hints >comming from the underlying OS. Hardware abstraction layer/HAL on >Linux is an example of underlying OS events. > >I assume that role too is delegated to other parts of the system? > >-- >Trent Jarvi >tjarvi at qbang.org >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From maximulo at yahoo.com Fri Mar 24 01:22:38 2006 From: maximulo at yahoo.com (Maximulo Majir) Date: Fri, 24 Mar 2006 00:22:38 -0800 (PST) Subject: [Rxtx] JavaPOS Message-ID: <20060324082238.66371.qmail@web38214.mail.mud.yahoo.com> Hi all! Hello Trent! From what i understand, RXTX or JavaComm APIs were not created solely for JavaPOS. In JavaPOS, we have the virtual method claim() which is separate from open(), but in our RXTX API, claiming is done every call to open(), we cant open the port if its claimed by another application. Would it be alright to suggest or ask to create a new method called claim(..)? Is there such thing as forceclaim() in RXTX? this could be the same as portownership transfer or its equivalent. ForceClaim is in JSR80. Do you have some samples using RXTX as the lower layer for the Device Service Objects in JavaPOS? I have tried it, i just want to compare. Thank you all! maxim __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060324/496adba2/attachment-0009.html From tjarvi at qbang.org Fri Mar 24 11:28:19 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 24 Mar 2006 11:28:19 -0700 (MST) Subject: [Rxtx] Re: RXTX 2.1 Solaris Problems In-Reply-To: <3691.1143210578@www045.gmx.net> References: <3691.1143210578@www045.gmx.net> Message-ID: On Fri, 24 Mar 2006, Andreas Guenther wrote: > Hi all, > > the solaris problem was not the lock file only. > > Ok, I had to create the directory /var/spool/locks myself. > /var/spool/uucp exists. > > But rxtx didn't find any port. > > I compiled the source with my own debug-informations > and I tried to isolate the problem. > > The problem is the testRead-call in SerialImp.c > > JNIEXPORT jboolean JNICALL RXTXCommDriver(testRead)( > > ... > if ( READ( fd, &c, 1 ) < 0 ) > { > if ( errno != EAGAIN ) { > report( "testRead() read failed\n" ); > ret = JNI_FALSE; > } > } > Thanks Andreas I'm packing up to move. I'll be more or less away for a couple weeks here. I'll be checking email but my workstation is going into a box soon. This isn't hard to fix as this port should be enumerated when EWOULDBLOCK is recieved. Thats error is OK for enumeration just as EAGAIN is. I've put the bug into bugzilla so we dont forget to get to it. http://bugzilla.qbang.org/show_bug.cgi?id=42 You can add yourself to the CC list if you wish to test fixes we provide or even put a patch into bugzilla yourself. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Fri Mar 24 11:51:52 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 24 Mar 2006 11:51:52 -0700 (MST) Subject: [Rxtx] JavaPOS In-Reply-To: <20060324082238.66371.qmail@web38214.mail.mud.yahoo.com> References: <20060324082238.66371.qmail@web38214.mail.mud.yahoo.com> Message-ID: On Fri, 24 Mar 2006, Maximulo Majir wrote: > Hi all! Hello Trent! > > > From what i understand, RXTX or JavaComm APIs were not > created solely for JavaPOS. In JavaPOS, we have the virtual method > claim() which is separate from open(), but in our RXTX API, claiming is > done every call to open(), we cant open the port if its claimed by > another application. Would it be alright to suggest or ask to create a > new method called claim(..)? Is there such thing as forceclaim() in > RXTX? this could be the same as portownership transfer or its > equivalent. ForceClaim is in JSR80. > Do you have some samples using RXTX as the lower layer for the Device > Service Objects in JavaPOS? I have tried it, i just want to compare. > maxim Hi Maxim JSR80 is the USB API IBM/Sun put together. The problem is they have a richer kernel/API underneath that can handle such things. With Serial Ports, there isnt anything there other than an ioctl that says don't let anyone touch this and lockfiles that are more of a 'lets be nice.' At times we may be using USB ports but it is through the termios layer with the limitations mentioned. The advantage is that not only USB will work with rxtx. Anything that has a termios layer should work (to the extent that termios layer is complete). I don't know how forceclaim() would help you. Lets say someone has a programmer working on /dev/ttyS0 and you take it. Now you both race each other to read data first. There isn't a mechanism I know of that will solve this problem in termios. The most obvious test being a native app and a Java app trying to take the port. There is the potential of requestion ownership from other Java Applications but the use for that is very rare. Did you have something more specific in mind that I'm missing? I'm not sure that claim() and forceclaim() would help you with rxtx other than maybe locking the port with claim() without opening it. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sat Mar 25 23:42:08 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 25 Mar 2006 23:42:08 -0700 (MST) Subject: [Rxtx] Serial snoop Message-ID: I was reading the Linux kernel mail-list tonight and ran past a thread that mentioned sersnoop. This looks like a handy tool for people dealing with new toys. "a simple command-line tool for linux that echoes bytes to and from any two serial ports, ptys, or network sockets, and prints all traffic to stdout, in hex and ascii." http://www.restivo.org/projects/sersnoop/ It works on Linux only at this time (debian package available). -- Trent Jarvi tjarvi at qbang.org From beat.arnet at gmail.com Sun Mar 26 07:32:35 2006 From: beat.arnet at gmail.com (Beat Arnet) Date: Sun, 26 Mar 2006 09:32:35 -0500 Subject: [Rxtx] Error 0x5 at /home/bob/foo/tar/rxtx-2.1-7/build/../src/termios.c(860): Access is, denied. Message-ID: <4426A603.80508@gmail.com> Dear all, When trying to open the serial port, I sometimes (not always) run into the following exception (when opening the serialPort): Error 0x5 at /home/bob/foo/tar/rxtx-2.1-7/build/../src/termios.c(860): Access is denied. java.lang.UnsatisfiedLinkError: native_psmisc_report_owner at gnu.io.CommPortIdentifier.native_psmisc_report_owner(Native Method) at gnu.io.CommPortIdentifier.open(CommPortIdentifier.java:354) at codeskin.tools.CLLoader.open(CLLoader.java:79) at codeskin.tools.C2000Programmer.run(C2000Programmer.java:220) at java.lang.Thread.run(Unknown Source) Is this the type of error where I should just try to open the port again, or can it be avoided? Regards, Beat From tjarvi at qbang.org Sun Mar 26 11:40:12 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 26 Mar 2006 11:40:12 -0700 (MST) Subject: [Rxtx] Error 0x5 at /home/bob/foo/tar/rxtx-2.1-7/build/../src/termios.c(860): Access is, denied. In-Reply-To: <4426A603.80508@gmail.com> References: <4426A603.80508@gmail.com> Message-ID: On Sun, 26 Mar 2006, Beat Arnet wrote: > Dear all, > > When trying to open the serial port, I sometimes (not always) run into > the following exception (when opening the serialPort): > > Error 0x5 at /home/bob/foo/tar/rxtx-2.1-7/build/../src/termios.c(860): > Access is > denied. > > java.lang.UnsatisfiedLinkError: native_psmisc_report_owner > at gnu.io.CommPortIdentifier.native_psmisc_report_owner(Native > Method) > at gnu.io.CommPortIdentifier.open(CommPortIdentifier.java:354) > at codeskin.tools.CLLoader.open(CLLoader.java:79) > at codeskin.tools.C2000Programmer.run(C2000Programmer.java:220) > at java.lang.Thread.run(Unknown Source) > > Is this the type of error where I should just try to open the port again, > or can it be avoided? > Hi Beat We did a second build of rxtx 2.1-7 to resolve that unsatisfied link error. It should work now. rxtx is trying to tell you it thinks someone else has the serial port open. You can try to open the port again but maybe you already have a copy of the program running when it happens? ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7r2.zip fixed build. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sun Mar 26 11:44:23 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 26 Mar 2006 11:44:23 -0700 (MST) Subject: [Rxtx] RXTX spec file (fwd) Message-ID: This is probably interesting for fedora/suse users. ---------- Forwarded message ---------- Date: Sun, 26 Mar 2006 16:25:45 +0200 To: taj at www.linux.org.uk Subject: RXTX spec file I send you this spec file which allows to create a RPM for Fedora 4, 5 (x86, x86_64) with Java Sun. -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: rxtx.spec Url: http://mailman.qbang.org/pipermail/rxtx/attachments/20060326/6c7b6af6/rxtx-0005.pl From tjarvi at qbang.org Sun Mar 26 23:42:59 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 26 Mar 2006 23:42:59 -0700 (MST) Subject: [Rxtx] Upcomming events. Message-ID: This Wednesday we will be announcing a new "Maintainer" for the rxtx project. The position is more like neutral leader. I wont be going away or doing less. This is just the right thing to do as it turns out the two people with CVS write access will be at the same company. We need a third and we need neutrality. The maintainer will have final say in any conflict and will try to be neutral. It will be open for discussion. Then we will do it :) I'll still do most of the footwork I do now. But. I'm falling behind. I should have gone through the mail-list and posted the next round of changes this weekend. I'm packing to move and its going so so - 13 years of toys collected. I suspect there will be a dead period on my part (a couple weeks) comming up. But if you get it on the mail-list, we will get it in if there are no objections. I may well not be reading the mail-list during this period as I look for a house and many other things. I hope everyone will help out. Thanks -- Trent Jarvi tjarvi at qbang.org From mahmoud_hadad at yahoo.com Sun Mar 26 07:31:19 2006 From: mahmoud_hadad at yahoo.com (ronan nick) Date: Sun, 26 Mar 2006 06:31:19 -0800 (PST) Subject: [Rxtx] a question about the COMM API Message-ID: <20060326143119.54919.qmail@web60014.mail.yahoo.com> hi, i was intrested in knowing how i can communicate with my internal modem using java? for example if i want to make a phone dialer application or a caller id application where should i be looking at? and as i understood the COMM API is for devices that is attached to the computer through serial ports. --------------------------------- New Yahoo! Messenger with Voice. Call regular phones from your PC and save big. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060326/ce8329f0/attachment-0007.html From dmarkman at mac.com Mon Mar 20 00:20:43 2006 From: dmarkman at mac.com (Dmitry Markman) Date: Mon, 20 Mar 2006 02:20:43 -0500 Subject: [Rxtx] Mac OS X RXTX java installer In-Reply-To: References: <07D0DE29-BA32-4CFE-B036-66BC6423D385@buechse.de> <441AE3E0.2030503@willicon.de> <12531986.1142622114996.JavaMail.dmarkman@mac.com> <441B2674.9010409@willicon.de> <13577405.1142634732776.JavaMail.dmarkman@mac.com> <441B4182.8010407@willicon.de> <92CD0D6C-5BE8-426E-A46D-99452059FF49@mac.com> <441BBB2D.8030305@willicon.de> <441C4088.5090905@willicon.de> Message-ID: <64BC1E23-FDDE-4CE6-8863-CFC881CBC224@mac.com> Hi all I put RXTX installer that will install everything (and will create / var/lock if necessary and add user to the uucp group) for mac os x from Java into the rxtx's CVS repository it could be easily modified to install files for any platform it uses Greg Guerin's AuthKit for authentication and authorization Greg released that kit under artistic license, so Trent, please take a look we, probably, can negotiate license with Greg if it's necessary Greg's AuthKit could be downloaded from http://www.amug.org/~glguerin/ sw/#authkit Michael Hall (mikehall at spacestar dot net) had a suggestion to make implementation of the jaas LoginModule based on Greg's AuthKit (his modification of the Greg's AuthKit could be found at http:// www.spacestar.net/users/mikehall/authkit.dmg) but Michael's AuthKitLoginModule does only half a job: it does authenticate but it can not run any external unix process in privileged mode (at least I wasn't able to do so) possible explanation could be found in conversation between Greg and Michael at Apple's java-dev list (look for archives) so I didn't use jaas API for rxtxinstaller I created folder MacOSX in the contrib folder comment 1. if you want to run that installer as standalone application all you need that RXTXInstaller.jar 2. if you want to use webstart you have to add Greg's libAuthKit.jnilib to the mac os x's resources in theory RXTXInstaller.jar doesn't need it, but there is a problem with loading libAuthKit.jnilib from webstart authkit uses loadLibrary method to load library and it failed (from webstart) for standalone application I extract libAuthKit.jnilib from the RXTXInstaller.jar and put it into the /Library/Java/Extensions or ~/Library/Java/Extensions folder that file will be deleted after installer quit unfortunately I didn't have time to put documentation there but it is mostly self-explanatory I took installer code from my gl4java installer that I did about 3 years ago (with small modifications) it would be very nice if Apple will release LoginModule that really will do the job (com.apple.security.auth.module package????? ) (UnixLoginModule is pretty useless) From lyon at docjava.com Mon Mar 20 06:34:39 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Mon, 20 Mar 2006 08:34:39 -0500 Subject: [Rxtx] Mac OS X RXTX java installer In-Reply-To: <64BC1E23-FDDE-4CE6-8863-CFC881CBC224@mac.com> References: <07D0DE29-BA32-4CFE-B036-66BC6423D385@buechse.de> <441AE3E0.2030503@willicon.de> <12531986.1142622114996.JavaMail.dmarkman@mac.com> <441B2674.9010409@willicon.de> <13577405.1142634732776.JavaMail.dmarkman@mac.com> <441B4182.8010407@willicon.de> <92CD0D6C-5BE8-426E-A46D-99452059FF49@mac.com> <441BBB2D.8030305@willicon.de> <441C4088.5090905@willicon.de> <64BC1E23-FDDE-4CE6-8863-CFC881CBC224@mac.com> Message-ID: Hi Dimitry, This sounds like great work. Just a couple of questions; After the check out of the CVS files, using: setenv CVSROOT :pserver:anonymous at cvs.milestonesolutions.com:/usr/local/cvsroot 53 8:28 setenv PASSWORD mousy 54 8:29 cvs login 55 8:29 cvs checkout rxtx-devel I cd'd over to: rxtx-devel/MACOSX_IDE And found: CVS/ CW/ ForPackageMaker/ PB/ Where is the installer? Thanks! - Doug From tjarvi at qbang.org Mon Mar 20 06:39:37 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 20 Mar 2006 06:39:37 -0700 (MST) Subject: [Rxtx] Mac OS X RXTX java installer In-Reply-To: References: <07D0DE29-BA32-4CFE-B036-66BC6423D385@buechse.de> <441AE3E0.2030503@willicon.de> <12531986.1142622114996.JavaMail.dmarkman@mac.com> <441B2674.9010409@willicon.de> <13577405.1142634732776.JavaMail.dmarkman@mac.com> <441B4182.8010407@willicon.de> <92CD0D6C-5BE8-426E-A46D-99452059FF49@mac.com> <441BBB2D.8030305@willicon.de> <441C4088.5090905@willicon.de> <64BC1E23-FDDE-4CE6-8863-CFC881CBC224@mac.com> Message-ID: On Mon, 20 Mar 2006, Dr. Douglas Lyon wrote: > Hi Dimitry, > This sounds like great work. Just a couple of questions; > After the check out of the CVS files, using: > setenv CVSROOT > :pserver:anonymous at cvs.milestonesolutions.com:/usr/local/cvsroot > 53 8:28 setenv PASSWORD mousy > 54 8:29 cvs login > 55 8:29 cvs checkout rxtx-devel Hi Doug You want "cvs checkout -r commapi-0-0-1 rxtx-devel" to get RXTX 2.1 The default branch is rxtx 2.0 which isn't very active right now. -- Trent Jarvi tjarvi at qbang.org From lyon at docjava.com Mon Mar 20 07:05:44 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Mon, 20 Mar 2006 09:05:44 -0500 Subject: [Rxtx] Mac OS X RXTX java installer In-Reply-To: References: <07D0DE29-BA32-4CFE-B036-66BC6423D385@buechse.de> <441AE3E0.2030503@willicon.de> <12531986.1142622114996.JavaMail.dmarkman@mac.com> <441B2674.9010409@willicon.de> <13577405.1142634732776.JavaMail.dmarkman@mac.com> <441B4182.8010407@willicon.de> <92CD0D6C-5BE8-426E-A46D-99452059FF49@mac.com> <441BBB2D.8030305@willicon.de> <441C4088.5090905@willicon.de> <64BC1E23-FDDE-4CE6-8863-CFC881CBC224@mac.com> Message-ID: Hi Trent, Thanks for the info on the CVS checkout procedure. I did that and am still not sure where the installer is. Here is what I have: cd MACOSX_IDE/ p4.docjava.com{lyon}121: ls CVS/ ForPackageMaker/ PB/ p4.docjava.com{lyon}122: find . | more . ./ForPackageMaker ./ForPackageMaker/RXTX.pkg.sit.hqx ./ForPackageMaker/Resources ./ForPackageMaker/Resources/ReadMe.rtf ./ForPackageMaker/Resources/Welcome.rtf ./ForPackageMaker/Resources/CVS ./ForPackageMaker/Resources/CVS/Entries ./ForPackageMaker/Resources/CVS/Repository ./ForPackageMaker/Resources/CVS/Tag ./ForPackageMaker/Resources/CVS/Root ./ForPackageMaker/Resources/preinstall ./ForPackageMaker/Resources/License.rtf ./ForPackageMaker/Resources/preupgrade ./ForPackageMaker/RXTX.pmsp ./ForPackageMaker/CVS ./ForPackageMaker/CVS/Entries ./ForPackageMaker/CVS/Repository ./ForPackageMaker/CVS/Entries.Log ./ForPackageMaker/CVS/Tag ./ForPackageMaker/CVS/Root ./ForPackageMaker/RXTX_Tiger.pkg.sitx.hqx ./ForPackageMaker/RXTX_Jag.pkg.sit.hqx ./ForPackageMaker/Install ./ForPackageMaker/Install/CVS ./ForPackageMaker/Install/CVS/Entries ./ForPackageMaker/Install/CVS/Repository ./ForPackageMaker/Install/CVS/Tag ./ForPackageMaker/Install/CVS/Root ./ForPackageMaker/Install/Library ./ForPackageMaker/Install/Library/CVS ./ForPackageMaker/Install/Library/CVS/Entries ./ForPackageMaker/Install/Library/CVS/Repository ./ForPackageMaker/Install/Library/CVS/Tag ./ForPackageMaker/Install/Library/CVS/Root ./ForPackageMaker/Install/Library/Java ./ForPackageMaker/Install/Library/Java/Extensions ./ForPackageMaker/Install/Library/Java/Extensions/RXTXcomm.jar ./ForPackageMaker/Install/Library/Java/Extensions/CVS ./ForPackageMaker/Install/Library/Java/Extensions/CVS/Entries ./ForPackageMaker/Install/Library/Java/Extensions/CVS/Repository ./ForPackageMaker/Install/Library/Java/Extensions/CVS/Tag ./ForPackageMaker/Install/Library/Java/Extensions/CVS/Root ./ForPackageMaker/Install/Library/Java/Extensions/librxtxSerial.jnilib ./ForPackageMaker/Install/Library/Java/CVS ./ForPackageMaker/Install/Library/Java/CVS/Entries ./ForPackageMaker/Install/Library/Java/CVS/Repository ./ForPackageMaker/Install/Library/Java/CVS/Entries.Log ./ForPackageMaker/Install/Library/Java/CVS/Tag ./ForPackageMaker/Install/Library/Java/CVS/Root ./ForPackageMaker/RXTX_Tiger.pmproj.sitx.hqx ./CVS ./CVS/Entries ./CVS/Repository ./CVS/Entries.Log ./CVS/Tag ./CVS/Root ./PB ./PB/LibSerialUniversal.xcodeproj.sitx.hqx ./PB/CVS ./PB/CVS/Entries ./PB/CVS/Repository ./PB/CVS/Entries.Log ./PB/CVS/Tag ./PB/CVS/Root ./PB/LibSerial.pbproj.sit.hqx ./PB/startpoint.c ./PB/config.h What is the procedure to run this installer? Do we need a README in: /rxtx-devel/MACOSX_IDE Here is what we have: CVS/ ForPackageMaker/ PB/ Thanks! - DL >On Mon, 20 Mar 2006, Dr. Douglas Lyon wrote: > >>Hi Dimitry, >>This sounds like great work. Just a couple of questions; >>After the check out of the CVS files, using: >>setenv CVSROOT >>:pserver:anonymous at cvs.milestonesolutions.com:/usr/local/cvsroot >> 53 8:28 setenv PASSWORD mousy >> 54 8:29 cvs login >> 55 8:29 cvs checkout rxtx-devel > >Hi Doug > >You want "cvs checkout -r commapi-0-0-1 rxtx-devel" to get RXTX 2.1 >The default branch is rxtx 2.0 which isn't very active right now. > >-- >Trent Jarvi >tjarvi at qbang.org From tjarvi at qbang.org Mon Mar 20 07:25:30 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 20 Mar 2006 07:25:30 -0700 (MST) Subject: [Rxtx] Mac OS X RXTX java installer In-Reply-To: References: <07D0DE29-BA32-4CFE-B036-66BC6423D385@buechse.de> <441AE3E0.2030503@willicon.de> <12531986.1142622114996.JavaMail.dmarkman@mac.com> <441B2674.9010409@willicon.de> <13577405.1142634732776.JavaMail.dmarkman@mac.com> <441B4182.8010407@willicon.de> <92CD0D6C-5BE8-426E-A46D-99452059FF49@mac.com> <441BBB2D.8030305@willicon.de> <441C4088.5090905@willicon.de> <64BC1E23-FDDE-4CE6-8863-CFC881CBC224@mac.com> Message-ID: On Mon, 20 Mar 2006, Dr. Douglas Lyon wrote: > Hi Trent, > Thanks for the info on the CVS checkout procedure. > I did that and am still not sure where the installer is. Hi Doug It does look like it was not cvs committed. There is no rxtx-devel/contrib/MacOSX directory in there at the moment. It was mentioned that it was put under contrib. -- Trent Jarvi tjarvi at qbang.org From dmarkman at mac.com Mon Mar 20 07:29:56 2006 From: dmarkman at mac.com (Dmitry Markman) Date: Mon, 20 Mar 2006 09:29:56 -0500 Subject: [Rxtx] Mac OS X RXTX java installer In-Reply-To: References: <07D0DE29-BA32-4CFE-B036-66BC6423D385@buechse.de> <441AE3E0.2030503@willicon.de> <12531986.1142622114996.JavaMail.dmarkman@mac.com> <441B2674.9010409@willicon.de> <13577405.1142634732776.JavaMail.dmarkman@mac.com> <441B4182.8010407@willicon.de> <92CD0D6C-5BE8-426E-A46D-99452059FF49@mac.com> <441BBB2D.8030305@willicon.de> <441C4088.5090905@willicon.de> <64BC1E23-FDDE-4CE6-8863-CFC881CBC224@mac.com> Message-ID: <6054EB4E-F7E0-4A9C-BDDA-D582D6D8826F@mac.com> you can find it in the rxtx-devel/contrib folder On Mar 20, 2006, at 9:05 AM, Dr. Douglas Lyon wrote: > Hi Trent, > Thanks for the info on the CVS checkout procedure. > I did that and am still not sure where the installer is. > Here is what I have: > cd MACOSX_IDE/ > p4.docjava.com{lyon}121: ls > CVS/ ForPackageMaker/ PB/ > p4.docjava.com{lyon}122: find . | more > . > ./ForPackageMaker > ./ForPackageMaker/RXTX.pkg.sit.hqx > ./ForPackageMaker/Resources > ./ForPackageMaker/Resources/ReadMe.rtf > ./ForPackageMaker/Resources/Welcome.rtf > ./ForPackageMaker/Resources/CVS > ./ForPackageMaker/Resources/CVS/Entries > ./ForPackageMaker/Resources/CVS/Repository > ./ForPackageMaker/Resources/CVS/Tag > ./ForPackageMaker/Resources/CVS/Root > ./ForPackageMaker/Resources/preinstall > ./ForPackageMaker/Resources/License.rtf > ./ForPackageMaker/Resources/preupgrade > ./ForPackageMaker/RXTX.pmsp > ./ForPackageMaker/CVS > ./ForPackageMaker/CVS/Entries > ./ForPackageMaker/CVS/Repository > ./ForPackageMaker/CVS/Entries.Log > ./ForPackageMaker/CVS/Tag > ./ForPackageMaker/CVS/Root > ./ForPackageMaker/RXTX_Tiger.pkg.sitx.hqx > ./ForPackageMaker/RXTX_Jag.pkg.sit.hqx > ./ForPackageMaker/Install > ./ForPackageMaker/Install/CVS > ./ForPackageMaker/Install/CVS/Entries > ./ForPackageMaker/Install/CVS/Repository > ./ForPackageMaker/Install/CVS/Tag > ./ForPackageMaker/Install/CVS/Root > ./ForPackageMaker/Install/Library > ./ForPackageMaker/Install/Library/CVS > ./ForPackageMaker/Install/Library/CVS/Entries > ./ForPackageMaker/Install/Library/CVS/Repository > ./ForPackageMaker/Install/Library/CVS/Tag > ./ForPackageMaker/Install/Library/CVS/Root > ./ForPackageMaker/Install/Library/Java > ./ForPackageMaker/Install/Library/Java/Extensions > ./ForPackageMaker/Install/Library/Java/Extensions/RXTXcomm.jar > ./ForPackageMaker/Install/Library/Java/Extensions/CVS > ./ForPackageMaker/Install/Library/Java/Extensions/CVS/Entries > ./ForPackageMaker/Install/Library/Java/Extensions/CVS/Repository > ./ForPackageMaker/Install/Library/Java/Extensions/CVS/Tag > ./ForPackageMaker/Install/Library/Java/Extensions/CVS/Root > ./ForPackageMaker/Install/Library/Java/Extensions/librxtxSerial.jnilib > ./ForPackageMaker/Install/Library/Java/CVS > ./ForPackageMaker/Install/Library/Java/CVS/Entries > ./ForPackageMaker/Install/Library/Java/CVS/Repository > ./ForPackageMaker/Install/Library/Java/CVS/Entries.Log > ./ForPackageMaker/Install/Library/Java/CVS/Tag > ./ForPackageMaker/Install/Library/Java/CVS/Root > ./ForPackageMaker/RXTX_Tiger.pmproj.sitx.hqx > ./CVS > ./CVS/Entries > ./CVS/Repository > ./CVS/Entries.Log > ./CVS/Tag > ./CVS/Root > ./PB > ./PB/LibSerialUniversal.xcodeproj.sitx.hqx > ./PB/CVS > ./PB/CVS/Entries > ./PB/CVS/Repository > ./PB/CVS/Entries.Log > ./PB/CVS/Tag > ./PB/CVS/Root > ./PB/LibSerial.pbproj.sit.hqx > ./PB/startpoint.c > ./PB/config.h > > What is the procedure to run this installer? > Do we need a README in: > /rxtx-devel/MACOSX_IDE > Here is what we have: > CVS/ ForPackageMaker/ PB/ > > > Thanks! > - DL > >> On Mon, 20 Mar 2006, Dr. Douglas Lyon wrote: >> >>> Hi Dimitry, >>> This sounds like great work. Just a couple of questions; >>> After the check out of the CVS files, using: >>> setenv CVSROOT :pserver:anonymous at cvs.milestonesolutions.com:/usr/ >>> local/cvsroot >>> 53 8:28 setenv PASSWORD mousy >>> 54 8:29 cvs login >>> 55 8:29 cvs checkout rxtx-devel >> >> Hi Doug >> >> You want "cvs checkout -r commapi-0-0-1 rxtx-devel" to get RXTX 2.1 >> The default branch is rxtx 2.0 which isn't very active right now. >> >> -- >> Trent Jarvi >> tjarvi at qbang.org > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx Dmitry Markman From mikehall at spacestar.net Mon Mar 20 05:25:25 2006 From: mikehall at spacestar.net (Michael Hall) Date: Mon, 20 Mar 2006 06:25:25 -0600 Subject: [Rxtx] Re: Mac OS X RXTX java installer In-Reply-To: <64BC1E23-FDDE-4CE6-8863-CFC881CBC224@mac.com> References: <07D0DE29-BA32-4CFE-B036-66BC6423D385@buechse.de> <441AE3E0.2030503@willicon.de> <12531986.1142622114996.JavaMail.dmarkman@mac.com> <441B2674.9010409@willicon.de> <13577405.1142634732776.JavaMail.dmarkman@mac.com> <441B4182.8010407@willicon.de> <92CD0D6C-5BE8-426E-A46D-99452059FF49@mac.com> <441BBB2D.8030305@willicon.de> <441C4088.5090905@willicon.de> <64BC1E23-FDDE-4CE6-8863-CFC881CBC224@mac.com> Message-ID: <247EB61F-5CD1-4132-89A2-FC105B6CF9A5@spacestar.net> On Mar 20, 2006, at 1:20 AM, Dmitry Markman wrote: > > Michael Hall (mikehall at spacestar dot net) had a suggestion to > make implementation of the jaas LoginModule > based on Greg's AuthKit > (his modification of the Greg's AuthKit could be found at http:// > www.spacestar.net/users/mikehall/authkit.dmg) > but Michael's AuthKitLoginModule does only half a job: > it does authenticate > but it can not run any external unix process in privileged mode (at > least I wasn't able to do so) If you got it working directly with Greg's the point is moot. But to clarify it anyhow. The login module does not allow you to do anything anything privileged on return as was explained by Greg. You need to work with a separate privileged process using the execPrivileged method of his API. I assume you did something similar although I haven't looked at how you are using it yet. I allowed instead for a action to be performed at the same time you login/authenticate,this... System.setProperty("authkit.action","/usr/bin/id"); just before this... lc.login(); To clarify, safely ignored as you are already complete. Mike Hall mikehall at spacestar dot net http://www.spacestar.net/users/mikehall http://sourceforge.net/projects/macnative -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2427 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20060320/f6e18202/smime-0010.bin From dmarkman at mac.com Mon Mar 20 07:36:47 2006 From: dmarkman at mac.com (Dmitry Markman) Date: Mon, 20 Mar 2006 09:36:47 -0500 Subject: [Rxtx] Re: Mac OS X RXTX java installer In-Reply-To: <247EB61F-5CD1-4132-89A2-FC105B6CF9A5@spacestar.net> References: <07D0DE29-BA32-4CFE-B036-66BC6423D385@buechse.de> <441AE3E0.2030503@willicon.de> <12531986.1142622114996.JavaMail.dmarkman@mac.com> <441B2674.9010409@willicon.de> <13577405.1142634732776.JavaMail.dmarkman@mac.com> <441B4182.8010407@willicon.de> <92CD0D6C-5BE8-426E-A46D-99452059FF49@mac.com> <441BBB2D.8030305@willicon.de> <441C4088.5090905@willicon.de> <64BC1E23-FDDE-4CE6-8863-CFC881CBC224@mac.com> <247EB61F-5CD1-4132-89A2-FC105B6CF9A5@spacestar.net> Message-ID: Hi, Michael all I have to do is to run some shell script I tried to use your action mechanism and it worked great so I just System.setProperty ("authkit.action","" ) and after that I even don't need to run anything like subject.doAs.... but after few thoughts I choose to use plain Greg's approach, because in that case I don't have to deal with various java's configurations files and therefore to use 2-3 -D parameters in the java command line especially it's useful for java web start (it's so fragile :-( ) thanks for the great job On Mar 20, 2006, at 7:25 AM, Michael Hall wrote: > > On Mar 20, 2006, at 1:20 AM, Dmitry Markman wrote: >> >> Michael Hall (mikehall at spacestar dot net) had a suggestion to >> make implementation of the jaas LoginModule >> based on Greg's AuthKit >> (his modification of the Greg's AuthKit could be found at http:// >> www.spacestar.net/users/mikehall/authkit.dmg) >> but Michael's AuthKitLoginModule does only half a job: >> it does authenticate >> but it can not run any external unix process in privileged mode >> (at least I wasn't able to do so) > > If you got it working directly with Greg's the point is moot. > > But to clarify it anyhow. > The login module does not allow you to do anything anything > privileged on return as was explained by Greg. You need to work > with a separate privileged process using the execPrivileged method > of his API. I assume you did something similar although I haven't > looked at how you are using it yet. > I allowed instead for a action to be performed at the same time you > login/authenticate,this... > System.setProperty("authkit.action","/usr/bin/id"); > just before this... > lc.login(); > To clarify, safely ignored as you are already complete. > > Mike Hall mikehall at spacestar dot net > http://www.spacestar.net/users/mikehall > http://sourceforge.net/projects/macnative > > > Dmitry Markman From dmarkman at mac.com Mon Mar 20 07:44:45 2006 From: dmarkman at mac.com (Dmitry Markman) Date: Mon, 20 Mar 2006 09:44:45 -0500 Subject: [Rxtx] Mac OS X RXTX java installer In-Reply-To: References: <07D0DE29-BA32-4CFE-B036-66BC6423D385@buechse.de> <441AE3E0.2030503@willicon.de> <12531986.1142622114996.JavaMail.dmarkman@mac.com> <441B2674.9010409@willicon.de> <13577405.1142634732776.JavaMail.dmarkman@mac.com> <441B4182.8010407@willicon.de> <92CD0D6C-5BE8-426E-A46D-99452059FF49@mac.com> <441BBB2D.8030305@willicon.de> <441C4088.5090905@willicon.de> <64BC1E23-FDDE-4CE6-8863-CFC881CBC224@mac.com> Message-ID: it's in the commapi-0-0-1 branch I tested it right now: cvs co -r commapi-0-0-1 rxtx-devel and I got everything On Mar 20, 2006, at 9:25 AM, Trent Jarvi wrote: > On Mon, 20 Mar 2006, Dr. Douglas Lyon wrote: > >> Hi Trent, >> Thanks for the info on the CVS checkout procedure. >> I did that and am still not sure where the installer is. > > Hi Doug > > It does look like it was not cvs committed. There is no rxtx-devel/ > contrib/MacOSX directory in there at the moment. It was mentioned > that it was put under contrib. > > -- > Trent Jarvi > tjarvi at qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx Dmitry Markman From tjarvi at qbang.org Mon Mar 20 07:52:57 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 20 Mar 2006 07:52:57 -0700 (MST) Subject: [Rxtx] Mac OS X RXTX java installer In-Reply-To: References: <07D0DE29-BA32-4CFE-B036-66BC6423D385@buechse.de> <441AE3E0.2030503@willicon.de> <12531986.1142622114996.JavaMail.dmarkman@mac.com> <441B2674.9010409@willicon.de> <13577405.1142634732776.JavaMail.dmarkman@mac.com> <441B4182.8010407@willicon.de> <92CD0D6C-5BE8-426E-A46D-99452059FF49@mac.com> <441BBB2D.8030305@willicon.de> <441C4088.5090905@willicon.de> <64BC1E23-FDDE-4CE6-8863-CFC881CBC224@mac.com> Message-ID: On Mon, 20 Mar 2006, Dmitry Markman wrote: > it's in the commapi-0-0-1 branch > > I tested it right now: > cvs co -r commapi-0-0-1 rxtx-devel > > and I got everything > A fresh checkout worked. Here is a copy of the tree (just the installer bits) ftp://ftp.qbang.org/pub/rxtx/MacOSX-installer.zip -- Trent Jarvi tjarvi at qbang.org From lyon at docjava.com Mon Mar 20 08:08:26 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Mon, 20 Mar 2006 10:08:26 -0500 Subject: [Rxtx] Mac OS X RXTX java installer In-Reply-To: References: <07D0DE29-BA32-4CFE-B036-66BC6423D385@buechse.de> <441AE3E0.2030503@willicon.de> <12531986.1142622114996.JavaMail.dmarkman@mac.com> <441B2674.9010409@willicon.de> <13577405.1142634732776.JavaMail.dmarkman@mac.com> <441B4182.8010407@willicon.de> <92CD0D6C-5BE8-426E-A46D-99452059FF49@mac.com> <441BBB2D.8030305@willicon.de> <441C4088.5090905@willicon.de> <64BC1E23-FDDE-4CE6-8863-CFC881CBC224@mac.com> Message-ID: Hi All, Is the Auth package able to work properly on non Mac OS's? It was not clear from the doc or download. Thanks! - Doug From dmarkman at mac.com Mon Mar 20 08:15:22 2006 From: dmarkman at mac.com (Dmitry Markman) Date: Mon, 20 Mar 2006 10:15:22 -0500 Subject: [Rxtx] Mac OS X RXTX java installer In-Reply-To: References: <07D0DE29-BA32-4CFE-B036-66BC6423D385@buechse.de> <441AE3E0.2030503@willicon.de> <12531986.1142622114996.JavaMail.dmarkman@mac.com> <441B2674.9010409@willicon.de> <13577405.1142634732776.JavaMail.dmarkman@mac.com> <441B4182.8010407@willicon.de> <92CD0D6C-5BE8-426E-A46D-99452059FF49@mac.com> <441BBB2D.8030305@willicon.de> <441C4088.5090905@willicon.de> <64BC1E23-FDDE-4CE6-8863-CFC881CBC224@mac.com> Message-ID: <217312D8-CCCA-4859-ABA6-32DF1CC817B9@mac.com> thanks Trent, for putting it on ftp server On Mar 20, 2006, at 9:52 AM, Trent Jarvi wrote: > A fresh checkout worked. Here is a copy of the tree (just the > installer bits) > > ftp://ftp.qbang.org/pub/rxtx/MacOSX-installer.zip > Dmitry Markman From dmarkman at mac.com Mon Mar 20 09:14:03 2006 From: dmarkman at mac.com (Dmitry Markman) Date: Mon, 20 Mar 2006 11:14:03 -0500 Subject: [Rxtx] Mac OS X RXTX java installer In-Reply-To: References: <07D0DE29-BA32-4CFE-B036-66BC6423D385@buechse.de> <441AE3E0.2030503@willicon.de> <12531986.1142622114996.JavaMail.dmarkman@mac.com> <441B2674.9010409@willicon.de> <13577405.1142634732776.JavaMail.dmarkman@mac.com> <441B4182.8010407@willicon.de> <92CD0D6C-5BE8-426E-A46D-99452059FF49@mac.com> <441BBB2D.8030305@willicon.de> <441C4088.5090905@willicon.de> <64BC1E23-FDDE-4CE6-8863-CFC881CBC224@mac.com> Message-ID: <4DEBA6F0-DA45-4E84-823E-1F1AC48BDCCC@mac.com> no it will work only on mac os x however it's harmless to run it on other platform if you want to use it for other platform you have to do the following (I'll do it for linux) 1. modify RXTXInstaller class method public static RXTXInstaller getInstance() public static RXTXInstaller getInstance() { String osName = System.getProperty("os.name").toLowerCase(); if(osName.startsWith("mac")){ return new gnu.io.installer.macosx.MACOSXRXTXInstaller(); } else if(osName.startsWith("windows")){ return new gnu.io.installer.windows.WindowsRXTXInstaller(); }else if(osName.startsWith("linux")){ return new gnu.io.installer.linux.LinuxRXTXInstaller(); } return null; } 2. create folder gnu/io/installer/linux/ 3. create class Linux386RXTXInstaller package gnu.io.installer.linux; import java.io.File; public class Linux386RXTXInstaller extends gnu.io.installer.RXTXInstaller{ public Linux386RXTXInstaller(){ createJarFolder(); createLibFolder(); addJarResource("RXTXcomm.jar","/gnu/io/installer/resources/ linux/jar/RXTXcomm.dat"); addLibResource("librxtxSerial.so","/gnu/io/installer/ resources/linux/lib/librxtxSerial.so"); } protected void createJarFolder(){ String javaHome = System.getProperty("java.home"); char separator = File.separatorChar; jarFolder = new File(javaHome+separator+"lib"+separator+"ext"); } protected void createLibFolder(){ String javaHome = System.getProperty("java.home"); char separator = File.separatorChar; libFolder = new File(javaHome+separator+"bin"); } public void runPreProcess() {} //put here some action you need public void runPostProcess() {} //put here some action you need } 4. create folder /gnu/io/installer/resources/linux/jar and put there linux's version of RXTXcomm.dat (which is renamed RXTXcomm.jar) 5. create folder /gnu/io/installer/resources/linux/lib and put there linux's version of librxtxSerial. so 6. make sure that RXTXInstaller.jar has the following items: /gnu/io/installer/resources/linux/jar/RXTXcomm.jar /gnu/io/installer/resources/linux/lib/librxtxSerial.so 7. modify file installer.pref: jar file RXTXInstaller.jar must have the following item /gnu/io/installer/installer.pref that's basically it for windows you have to do the similar things: just replace linux to windows and librxtxSerial.so to rxtxSerial.dll and create appropriate gnu.io.installer.windows.WindowsRXTXInstaller class package gnu.io.installer.windows; import java.io.File; public class WindowsRXTXInstaller extends gnu.io.installer.RXTXInstaller{ public WindowsRXTXInstaller(){ createJarFolder(); createLibFolder(); addJarResource("RXTXcomm.jar","/gnu/io/installer/resources/ windows/jar/RXTXcomm.dat"); addLibResource("librxtxSerial.so","/gnu/io/installer/ resources/windows/lib/rxtxSerial.dll"); } protected void createJarFolder(){ String javaHome = System.getProperty("java.home"); char separator = File.separatorChar; jarFolder = new File(javaHome+separator+"lib"+separator+"ext"); } protected void createLibFolder(){ String javaHome = System.getProperty("java.home"); char separator = File.separatorChar; libFolder = new File(javaHome+separator+"bin"); } public void runPreProcess() {} //put here some action you need public void runPostProcess() {} //put here some action you need } installer.pref will look like On Mar 20, 2006, at 10:08 AM, Dr. Douglas Lyon wrote: > Hi All, > Is the Auth package able to work properly on > non Mac OS's? > It was not clear from the doc or download. > > Thanks! > - Doug > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx Dmitry Markman From joachim at buechse.de Mon Mar 20 10:49:06 2006 From: joachim at buechse.de (Joachim Buechse) Date: Mon, 20 Mar 2006 18:49:06 +0100 Subject: [Rxtx] BUG: Lock file stays even if port opening fails Message-ID: This was only tested on MacOSX but looking at the code, it should be true for all systems that use lock_uucp. I am opening a port which can not be opened (dialup port of a telephone paired via bluetooth but currently not reachable). The lock file is created and stays arround, even though the port open failed. After looking a bit through the code (of 2.17), I really wonder if it wouldn't be a good idea to make the "locking" an explicit operation called from the java code. This would certainly simplify the generation of meaningfull exceptions (and java based debugging). Maybe even the handling of "preopened" ports should be in the Java part of the lib (again for java based debugging puposes). That beeing said, I have no idea if this would be possible for the 2.07 implementation. Regards, Joachim From tjarvi at qbang.org Mon Mar 20 11:24:22 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 20 Mar 2006 11:24:22 -0700 (MST) Subject: [Rxtx] BUG: Lock file stays even if port opening fails In-Reply-To: References: Message-ID: On Mon, 20 Mar 2006, Joachim Buechse wrote: > This was only tested on MacOSX but looking at the code, it should be true > for all systems that use lock_uucp. > > I am opening a port which can not be opened (dialup port of a telephone > paired via bluetooth but currently not reachable). The lock file is > created and stays arround, even though the port open failed. > > > After looking a bit through the code (of 2.17), I really wonder if it > wouldn't be a good idea to make the "locking" an explicit operation > called from the java code. This would certainly simplify the generation > of meaningfull exceptions (and java based debugging). > Maybe even the handling of "preopened" ports should be in the Java part > of the lib (again for java based debugging puposes). That beeing said, I > have no idea if this would be possible for the 2.07 implementation. > > Regards, Hi Joachim It should be possible in the 2.0-7 implementation too. The calls to RXTXPort.java would not change. We would just do more there Moving more of that logic into Java would be better as many people don't like to look at C code. There is a liblockdev on most Linux distros that can do most of the C code and would be easier to use. The problem is embeded devices will not have that library. The preopened port code has not been really tested. That was a last minute request in a product cycle. I expect it will be tested this year though. As I recall, some devices really do not like CD raising on open. The preopened ports then allow people to mess around in java without power cycling the devices or losing data. -- Trent Jarvi tjarvi at qbang.org From joachim at buechse.de Mon Mar 20 12:01:08 2006 From: joachim at buechse.de (Joachim Buechse) Date: Mon, 20 Mar 2006 20:01:08 +0100 Subject: [Rxtx] BUG: Lock file stays even if port opening fails In-Reply-To: References: Message-ID: Hi Trent, What is your general feeling about moving code to Java? The last days I have been reading quite a bit of the code and there are several things, that might not work as expected. I'll give you two examples from is_device_locked: if LOCKDIR == /var/spool/locks the directory /var/spool/lock will not be checked. LOCKDIR is not checked for lockfiles with unexpected pefixes While these things have probably never been discovered in production, they are still possibly incorrect implementations. If it was Java code, I would write some unit tests producing the errors that could later be corrected. PS: One could imagine to actually implement the whole lockfile handling in Java using some native routines to get the values required (pid, st_dev, st_rdev, ...). On 20.03.2006, at 19:24, Trent Jarvi wrote: > On Mon, 20 Mar 2006, Joachim Buechse wrote: > >> This was only tested on MacOSX but looking at the code, it should >> be true for all systems that use lock_uucp. >> >> I am opening a port which can not be opened (dialup port of a >> telephone paired via bluetooth but currently not reachable). The >> lock file is created and stays arround, even though the port open >> failed. >> >> >> After looking a bit through the code (of 2.17), I really wonder if >> it wouldn't be a good idea to make the "locking" an explicit >> operation called from the java code. This would certainly simplify >> the generation of meaningfull exceptions (and java based debugging). >> Maybe even the handling of "preopened" ports should be in the Java >> part of the lib (again for java based debugging puposes). That >> beeing said, I have no idea if this would be possible for the 2.07 >> implementation. >> >> Regards, > > Hi Joachim > > It should be possible in the 2.0-7 implementation too. The calls > to RXTXPort.java would not change. We would just do more there > Moving more of that logic into Java would be better as many people > don't like to look at C code. There is a liblockdev on most Linux > distros that can do most of the C code and would be easier to use. > The problem is embeded devices will not have that library. > > The preopened port code has not been really tested. That was a > last minute request in a product cycle. I expect it will be tested > this year though. As I recall, some devices really do not like CD > raising on open. The preopened ports then allow people to mess > around in java without power cycling the devices or losing data. > > -- > Trent Jarvi > tjarvi at qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Mon Mar 20 12:21:02 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 20 Mar 2006 12:21:02 -0700 (MST) Subject: [Rxtx] BUG: Lock file stays even if port opening fails In-Reply-To: References: Message-ID: On Mon, 20 Mar 2006, Joachim Buechse wrote: > Hi Trent, > > What is your general feeling about moving code to Java? The last days I > have been reading quite a bit of the code and there are several things, > that might not work as expected. > > I'll give you two examples from is_device_locked: > > if LOCKDIR == /var/spool/locks the directory /var/spool/lock will not be > checked. > LOCKDIR is not checked for lockfiles with unexpected pefixes > > While these things have probably never been discovered in production, > they are still possibly incorrect implementations. If it was Java code, I > would write some unit tests producing the errors that could later be > corrected. > > PS: One could imagine to actually implement the whole lockfile handling > in Java using some native routines to get the values required (pid, > st_dev, st_rdev, ...). Hi Joachim I like the idea of moving more of the code into java but there are some things to consider. If you break this into multiple JNI calls, the performance will drop considerably during enumeration of ports. We are looking for 256 ports per dev type vs (16? in Sun's 2.0 and fewer types). Its hard to make assumptions. I've seen virtual ports start at /dev/foo100 for instance. It works out to over 7500 ports on Linux if you enable them all. We already trim that back by default. See Linux-all-ports in RXTXCommDriver.java. There are also native libraries that rxtx can link to. If you move too much into Java, linking to 'standard' libraries with distros will break. "configure --enable-liblock=yes" will not be doable. This is probably a favorable way with RedHat, Debian, Suse and others. Thats the right thing to do if there will be rpms, dpkg, .. For those reasons, I think it still make sense to keep it to a minimal ~3 calls to JNI code that we can use for speed and versatility. lock() isLocked(), unlock() perhaps. When I say speed, its more about avoiding crossing the JNI layer multiple times than java vs C performance. With versatility I think liblock is the right way for most but not all (embeded) linux distros. -- Trent Jarvi tjarvi at qbang.org From joachim at buechse.de Mon Mar 20 12:42:04 2006 From: joachim at buechse.de (Joachim Buechse) Date: Mon, 20 Mar 2006 20:42:04 +0100 Subject: [Rxtx] BUG: Lock file stays even if port opening fails In-Reply-To: References: Message-ID: <82C19FE7-DDCB-45B6-B2C9-7606B66F0124@buechse.de> Ok, what about providing a default implementation in Java? The RXTXCommDriver would call a (native) function useNativeLocking and if it returns true, call the native functions for lock() isLocked (), unlock(), else is would use the Java based default implementation. This could possibly be overriden by a property (again for debugging). Joachim On 20.03.2006, at 20:21, Trent Jarvi wrote: > On Mon, 20 Mar 2006, Joachim Buechse wrote: > >> Hi Trent, >> >> What is your general feeling about moving code to Java? The last >> days I have been reading quite a bit of the code and there are >> several things, that might not work as expected. >> >> I'll give you two examples from is_device_locked: >> >> if LOCKDIR == /var/spool/locks the directory /var/spool/lock will >> not be checked. >> LOCKDIR is not checked for lockfiles with unexpected pefixes >> >> While these things have probably never been discovered in >> production, they are still possibly incorrect implementations. If >> it was Java code, I would write some unit tests producing the >> errors that could later be corrected. >> >> PS: One could imagine to actually implement the whole lockfile >> handling in Java using some native routines to get the values >> required (pid, st_dev, st_rdev, ...). > > Hi Joachim > > I like the idea of moving more of the code into java but there are > some things to consider. > > If you break this into multiple JNI calls, the performance will > drop considerably during enumeration of ports. We are looking for > 256 ports per dev type vs (16? in Sun's 2.0 and fewer types). Its > hard to make assumptions. I've seen virtual ports start at /dev/ > foo100 for instance. > > It works out to over 7500 ports on Linux if you enable them all. > We already trim that back by default. See Linux-all-ports in > RXTXCommDriver.java. > > There are also native libraries that rxtx can link to. If you move > too much into Java, linking to 'standard' libraries with distros > will break. "configure --enable-liblock=yes" will not be doable. > This is probably a favorable way with RedHat, Debian, Suse and > others. Thats the right thing to do if there will be rpms, dpkg, .. > > For those reasons, I think it still make sense to keep it to a > minimal ~3 calls to JNI code that we can use for speed and > versatility. lock() isLocked(), unlock() perhaps. When I say > speed, its more about avoiding crossing the JNI layer multiple > times than java vs C performance. With versatility I think liblock > is the right way for most but not all (embeded) linux distros. > > -- > Trent Jarvi > tjarvi at qbang.org > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Mon Mar 20 12:44:47 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 20 Mar 2006 12:44:47 -0700 (MST) Subject: [Rxtx] BUG: Lock file stays even if port opening fails In-Reply-To: <82C19FE7-DDCB-45B6-B2C9-7606B66F0124@buechse.de> References: <82C19FE7-DDCB-45B6-B2C9-7606B66F0124@buechse.de> Message-ID: On Mon, 20 Mar 2006, Joachim Buechse wrote: > Ok, what about providing a default implementation in Java? > > The RXTXCommDriver would call a (native) function useNativeLocking and if > it returns true, call the native functions for lock() isLocked(), > unlock(), else is would use the Java based default implementation. This > could possibly be overriden by a property (again for debugging). > Hi Joachim That would be OK with me. -- Trent Jarvi tjarvi at qbang.org From dmarkman at mac.com Mon Mar 20 22:27:45 2006 From: dmarkman at mac.com (Dmitry Markman) Date: Tue, 21 Mar 2006 00:27:45 -0500 Subject: [Rxtx] binaries request Message-ID: <42702213-C222-4937-A585-7CFB17E47608@mac.com> Hi can somebody send me latest linux and windows binaries, please? or where I can find them (I didn't find them in the latest tareball) I gave up with my cygwin: something wrong I have no idea what java doesn't understand /cygwin/c syntax after I changed makefile it did java part but after that gcc 3.4.4 started to complain I set buffer length to 999 lines but I didn't get beginning of the story something wrong with my 1.4.2_09/include/jni.h gcc doesn't like it anyway I gave up thanks in advance Dmitry Markman -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060320/f8cbc57c/attachment-0010.html From tjarvi at qbang.org Mon Mar 20 22:36:48 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 20 Mar 2006 22:36:48 -0700 (MST) Subject: [Rxtx] binaries request In-Reply-To: <42702213-C222-4937-A585-7CFB17E47608@mac.com> References: <42702213-C222-4937-A585-7CFB17E47608@mac.com> Message-ID: On Tue, 21 Mar 2006, Dmitry Markman wrote: > Hi > can somebody send me latest linux and windows binaries, please? > > or where I can find them (I didn't find them in the latest tareball) > > I gave up with my cygwin: something wrong I have no idea what > java doesn't understand /cygwin/c syntax > after I changed makefile it did java part > but after that gcc 3.4.4 started to complain > I set buffer length to 999 lines but I didn't get beginning of the story > something wrong with my 1.4.2_09/include/jni.h gcc doesn't like it > anyway I gave up > > thanks in advance > Hi Dmitry The bins are here: ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7-bins-r2.zip Here are the files in the zip you want. Jar: rxtx-2.1-7-bins-r2/RXTXcomm.jar Windows: rxtx-2.1-7-bins-r2/Windows/i368-mingw32/rxtxSerial.dll Linux (x86) rxtx-2.1-7-bins-r2/Linux/i686-unknown-linux-gnu/librxtxSerial.so There are others in there including Parallel port support but those are the main ones for testing. -- Trent Jarvi tjarvi at qbang.org From dmarkman at mac.com Mon Mar 20 23:05:59 2006 From: dmarkman at mac.com (Dmitry Markman) Date: Tue, 21 Mar 2006 01:05:59 -0500 Subject: [Rxtx] binaries request In-Reply-To: References: <42702213-C222-4937-A585-7CFB17E47608@mac.com> Message-ID: thank you very much but windows's readme says: rxtxSerial.dll had to be recomopiled to link in missing native methods. should I ignore it? or what? thanks again also I understand that I should use mingw not cygwin I'll try to install mingw On Mar 21, 2006, at 12:36 AM, Trent Jarvi wrote: > On Tue, 21 Mar 2006, Dmitry Markman wrote: > >> Hi >> can somebody send me latest linux and windows binaries, please? >> >> or where I can find them (I didn't find them in the latest tareball) >> >> I gave up with my cygwin: something wrong I have no idea what >> java doesn't understand /cygwin/c syntax >> after I changed makefile it did java part >> but after that gcc 3.4.4 started to complain >> I set buffer length to 999 lines but I didn't get beginning of the >> story >> something wrong with my 1.4.2_09/include/jni.h gcc doesn't like it >> anyway I gave up >> >> thanks in advance >> > > Hi Dmitry > > The bins are here: > > ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7-bins-r2.zip > > Here are the files in the zip you want. > > Jar: > > rxtx-2.1-7-bins-r2/RXTXcomm.jar > > Windows: > > rxtx-2.1-7-bins-r2/Windows/i368-mingw32/rxtxSerial.dll > > Linux (x86) > > rxtx-2.1-7-bins-r2/Linux/i686-unknown-linux-gnu/librxtxSerial.so > > There are others in there including Parallel port support but those > are the main ones for testing. > > -- > Trent Jarvi > tjarvi at qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx Dmitry Markman From tjarvi at qbang.org Mon Mar 20 23:20:33 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 20 Mar 2006 23:20:33 -0700 (MST) Subject: [Rxtx] binaries request In-Reply-To: References: <42702213-C222-4937-A585-7CFB17E47608@mac.com> Message-ID: On Tue, 21 Mar 2006, Dmitry Markman wrote: > thank you very much > > but windows's readme says: > rxtxSerial.dll had to be recomopiled to link in missing native methods. > > should I ignore it? or what? > Hi Dmitry That dll should be OK. r2 is the recompile linked to the missing native method. The readme explains why it was recompiled; fuser.o was not linked into the dll in the first release. -- Trent Jarvi tjarvi at qbang.org From ariantristan at yahoo.com Mon Mar 20 23:55:24 2006 From: ariantristan at yahoo.com (Lambok Sianturi) Date: Mon, 20 Mar 2006 22:55:24 -0800 (PST) Subject: [Rxtx] jvm issue Message-ID: <20060321065524.94779.qmail@web50701.mail.yahoo.com> Hi All, This is my first time to join RxTx mailing list. I thank you all for allowing others to sign in in requests help. I use the latest RxTx lib in Fedora 3 with java version 1.4.2_09 b05. And I got this error: # # An unexpected error has been detected by HotSpot Virtual Machine: # # SIGSEGV (0xb) at pc=0x00bf27f3, pid=2633, tid=3086112448 # # Java VM: Java HotSpot(TM) Client VM (1.4.2_09-b05 mixed mode) # Problematic frame: # C [ld-linux.so.2+0xa7f3] # # An error report file with more information is saved as hs_err_pid2633.log # # If you would like to submit a bug report, please visit: # http://java.sun.com/webapps/bugreport/crash.jsp # ./run.sh: line 3: 2633 Aborted /usr/local/java/bin/java -Djava.library.path=/usr/local/java/jre/lib/ -Djsmsengine.debug=true -classpath jsmsengine.jar:smsgateway.jar:classes12.jar:RXTXcomm.jar:. com.api.sms.SMSServer What is the jvm depedency for the latest library? Can I use 1.4.2_09 b05? Thanks in advance. Arian --------------------------------- Yahoo! Mail Use Photomail to share photos without annoying attachments. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060320/83d58dd7/attachment-0010.html From f.frumento at ngi.it Tue Mar 21 00:21:47 2006 From: f.frumento at ngi.it (Fabio Frumento) Date: Tue, 21 Mar 2006 08:21:47 +0100 Subject: [Rxtx] Javadoc on the go Message-ID: <441FA98B.9050701@ngi.it> Hi Trent, sorry for the big delay but my job is running wild, i was out for some time but now i'm back and ready to continue the javadoc for Rxtx. Did you used the last javadoc patch i sent you ? let me know if i have to send it to you again or not. regards Fabio From lyon at docjava.com Tue Mar 21 00:51:18 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Tue, 21 Mar 2006 02:51:18 -0500 Subject: [Rxtx] lock files Message-ID: Hi All, You know, if the use of lock files were under Java control (rather than a build-time decision), it might enable a more unified binary distro. It might also facilitate quick prototyping of non-lock file approaches to resolving serial port contention issues (i.e., mac-like approaches vs. linux approaches, etc.). I realize that this is a radical overhaul of the lock file policy issue. Also, it may harm performance. On the other hand, our benchmarks on JNI overhead for modern processors indicate performance impact should be minimal. Perhaps it is more of an issue with the toybox systems. Suppose there were a class with a reasonable default...someone might write: SerialPortLockPolicy.setPolicy(SerialPortLockPolicy.UNIX_LOCK_FILE); SerialPortLockPolicy.setPolicy(SerialPortLockPolicy.NO_LOCK_CHECKING); SerialPortLockPolicy.setPolicy(SerialPortLockPolicy.MAC_STYLE); Thus, we could have a run-time reconfiguration of the serial port lock policy. A special NO_LOCK version of the binary would no longer be required. Any thoughts on this? Thanks! - Doug From joachim at buechse.de Tue Mar 21 03:09:09 2006 From: joachim at buechse.de (Joachim Buechse) Date: Tue, 21 Mar 2006 11:09:09 +0100 Subject: [Rxtx] lock files In-Reply-To: References: Message-ID: <8E12916A-1B9A-4FF2-B684-E2D1C794221B@buechse.de> This is pretty much what I thought about when I suggested, that the default behaviour could be overwritten with a property. I am very much in favor of this approach. In particular this allows much easier debugging for PC based java developers. I think big parts of the Java (and maybe some parts of the C code) could use a bit of a structural workover (unit tests, javadoc, synchronization, etc). Maybe there should be a CVS branch for this experimental version. I'd be happy to contribute a first workover for some of the Java code. Designing for testability and implementing a good bunch of unit tests has been a strategy that worked quite well in the Java projects I lead. And it ultimately allows more liberal change permission. Regards, Joachim On 21.03.2006, at 08:51, Dr. Douglas Lyon wrote: > Hi All, > You know, if the use of lock files were > under Java control (rather than a build-time decision), > it might enable a more unified binary distro. It might also > facilitate quick prototyping of non-lock file approaches > to resolving serial port contention issues (i.e., mac-like > approaches vs. linux approaches, etc.). > > I realize that this is a radical overhaul of the lock file policy > issue. Also, it may harm performance. On the other hand, > our benchmarks on JNI overhead for modern processors indicate > performance impact should be minimal. Perhaps it is more of > an issue with the toybox systems. > > Suppose there were a class with a reasonable default...someone > might write: > SerialPortLockPolicy.setPolicy(SerialPortLockPolicy.UNIX_LOCK_FILE); > SerialPortLockPolicy.setPolicy(SerialPortLockPolicy.NO_LOCK_CHECKING); > SerialPortLockPolicy.setPolicy(SerialPortLockPolicy.MAC_STYLE); > > Thus, we could have a run-time reconfiguration of the serial port lock > policy. A special NO_LOCK version of the binary would no longer > be required. > > Any thoughts on this? > > Thanks! > - Doug > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From joachim at buechse.de Tue Mar 21 06:23:08 2006 From: joachim at buechse.de (Joachim Buechse) Date: Tue, 21 Mar 2006 14:23:08 +0100 Subject: [Rxtx] PATCH: use of ioctl(fd, TIOCEXCL) instead of lockfiles Message-ID: <923AE774-EEA2-4911-92D8-32BB27802C8B@buechse.de> Here is the patch for the ioctl(fd, TIOCEXCL). I have verified this only for OSX 10.4.5, hence it is only defined for APPLE. However, it should work at least for Solaris as well. If a process has requested TIOEXCL further open calls by other user processes will fail. The patch also disables uucp style locking for APPLE. Obviously this is discussable. I think it is the way to go, as it eliminates creating the lock directory which doesnt exist on the standard installation and it eliminates messing with the system group definitions (adding users to group uucp). Regarding the possibility of root processes opening a device which is locked - I consider this a feature not a potential problem. It is highly unlikely, that somebody is crazy enough to run a JavaVM as root (unless he has no other means of getting a restricted IP port opened, ie doesnt understand ipfw). Anyway, even if the process runs as root, it fails when calling ioctl(fd, TIOCEXCL). It could however still open the port to listen for RING events. I.e. a fax server which needs to see incoming calls but otherwise doesnt want to block the port. So the only case where the proposed mechanism fails is, if an incorrectly implemented process running as root conflicts with a user process. I think this can be accepted. Regards, Joachim PS: If this patch is generally accepted, the installer and Mac doku should obviously be changed as well. Index: SerialImp.c =================================================================== RCS file: /usr/local/cvsroot/rxtx-devel/src/SerialImp.c,v retrieving revision 1.46.2.187 diff -u -r1.46.2.187 SerialImp.c --- SerialImp.c 29 Jan 2006 22:19:04 -0000 1.46.2.187 +++ SerialImp.c 21 Mar 2006 12:59:16 -0000 @@ -656,6 +656,25 @@ fd=OPEN (filename, O_RDWR | O_NOCTTY | O_NONBLOCK ); } while (fd < 0 && errno==EINTR); +#ifdef OPEN_EXCL + // Note that open() follows POSIX semantics: multiple open() calls to + // the same file will succeed unless the TIOCEXCL ioctl is issued. + // This will prevent additional opens except by root-owned processes. + // See tty(4) ("man 4 tty") and ioctl(2) ("man 2 ioctl") for details. + + if (fd >= 0 && (ioctl(fd, TIOCEXCL) == -1)) + { + sprintf( message, "open: exclusive access denied for % s\n", + filename ); + report( message ); + report_error( message ); + + close(fd); + goto fail; + } +#endif /* OPEN_EXCL */ + + if( configure_port( fd ) ) goto fail; (*env)->ReleaseStringUTFChars( env, jstr, filename ); sprintf( message, "open: fd returned is %i\n", fd ); Index: SerialImp.h =================================================================== RCS file: /usr/local/cvsroot/rxtx-devel/src/SerialImp.h,v retrieving revision 1.11.2.49 diff -u -r1.11.2.49 SerialImp.h --- SerialImp.h 5 Jul 2005 17:47:21 -0000 1.11.2.49 +++ SerialImp.h 21 Mar 2006 12:59:17 -0000 @@ -135,7 +135,8 @@ /*# define LOCKDIR "/var/spool/uucp"*/ # define LOCKDIR "/var/lock" # define LOCKFILEPREFIX "LK." -# define UUCP +/*# define UUCP*/ +# define OPEN_EXCL #endif /* __APPLE__ */ #if defined(__NetBSD__) # define DEVICEDIR "/dev/" From tjarvi at qbang.org Tue Mar 21 10:26:08 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 21 Mar 2006 10:26:08 -0700 (MST) Subject: [Rxtx] Javadoc on the go In-Reply-To: <441FA98B.9050701@ngi.it> References: <441FA98B.9050701@ngi.it> Message-ID: On Tue, 21 Mar 2006, Fabio Frumento wrote: > Hi Trent, > > sorry for the big delay but my job is running wild, i was out for some > time but now i'm back and ready to continue the javadoc for Rxtx. > > Did you used the last javadoc patch i sent you ? let me know if i have to > send it to you again or not. > > regards > > Fabio Hi Fabio The patch is in the rxtx mail-list archives. It will be going in soon. I did not see a time critical portion. I'll probably be going through the list since the last batch of patches this weekend and putting them into CVS. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Tue Mar 21 10:57:18 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 21 Mar 2006 10:57:18 -0700 (MST) Subject: [Rxtx] jvm issue In-Reply-To: <20060321065524.94779.qmail@web50701.mail.yahoo.com> References: <20060321065524.94779.qmail@web50701.mail.yahoo.com> Message-ID: On Mon, 20 Mar 2006, Lambok Sianturi wrote: > Hi All, > This is my first time to join RxTx mailing list. I thank you all for allowing others to sign in in requests help. > I use the latest RxTx lib in Fedora 3 with java version 1.4.2_09 b05. And I got this error: > > # > # An unexpected error has been detected by HotSpot Virtual Machine: > # > # SIGSEGV (0xb) at pc=0x00bf27f3, pid=2633, tid=3086112448 > # > # Java VM: Java HotSpot(TM) Client VM (1.4.2_09-b05 mixed mode) > # Problematic frame: > # C [ld-linux.so.2+0xa7f3] A native library loading error? What happens if you recompile rxtx on your system and install that? This sounds like an ABI problem? rxtx 2.1-7 was compiled with a gcc 2.96 toolchain as I recall. The hope is newer system will be backwards compatible. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Tue Mar 21 11:05:29 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 21 Mar 2006 11:05:29 -0700 (MST) Subject: [Rxtx] PATCH: use of ioctl(fd, TIOCEXCL) instead of lockfiles In-Reply-To: <923AE774-EEA2-4911-92D8-32BB27802C8B@buechse.de> References: <923AE774-EEA2-4911-92D8-32BB27802C8B@buechse.de> Message-ID: On Tue, 21 Mar 2006, Joachim Buechse wrote: > Here is the patch for the ioctl(fd, TIOCEXCL). I have verified this only > for OSX 10.4.5, hence it is only defined for APPLE. However, it should > work at least for Solaris as well. > > If a process has requested TIOEXCL further open calls by other user > processes will fail. > > The patch also disables uucp style locking for APPLE. Obviously this is > discussable. I think it is the way to go, as it eliminates creating the > lock directory which doesnt exist on the standard installation and it > eliminates messing with the system group definitions (adding users to > group uucp). > > Regarding the possibility of root processes opening a device which is > locked - I consider this a feature not a potential problem. It is highly > unlikely, that somebody is crazy enough to run a JavaVM as root (unless > he has no other means of getting a restricted IP port opened, ie doesnt > understand ipfw). Anyway, even if the process runs as root, it fails when > calling ioctl(fd, TIOCEXCL). It could however still open the port to > listen for RING events. I.e. a fax server which needs to see incoming > calls but otherwise doesnt want to block the port. So the only case where > the proposed mechanism fails is, if an incorrectly implemented process > running as root conflicts with a user process. I think this can be > accepted. > > Regards, > Joachim > > PS: If this patch is generally accepted, the installer and Mac doku > should obviously be changed as well. > > > Index: SerialImp.c > =================================================================== > RCS file: /usr/local/cvsroot/rxtx-devel/src/SerialImp.c,v > retrieving revision 1.46.2.187 > diff -u -r1.46.2.187 SerialImp.c > --- SerialImp.c 29 Jan 2006 22:19:04 -0000 1.46.2.187 > +++ SerialImp.c 21 Mar 2006 12:59:16 -0000 > @@ -656,6 +656,25 @@ > fd=OPEN (filename, O_RDWR | O_NOCTTY | O_NONBLOCK ); > } while (fd < 0 && errno==EINTR); > > +#ifdef OPEN_EXCL > + // Note that open() follows POSIX semantics: multiple open() > calls to > + // the same file will succeed unless the TIOCEXCL ioctl is > issued. > + // This will prevent additional opens except by root-owned > processes. > + // See tty(4) ("man 4 tty") and ioctl(2) ("man 2 ioctl") for > details. > + > + if (fd >= 0 && (ioctl(fd, TIOCEXCL) == -1)) > + { > + sprintf( message, "open: exclusive access denied for % > s\n", > + filename ); > + report( message ); > + report_error( message ); > + > + close(fd); > + goto fail; > + } > +#endif /* OPEN_EXCL */ > + > + > if( configure_port( fd ) ) goto fail; > (*env)->ReleaseStringUTFChars( env, jstr, filename ); > sprintf( message, "open: fd returned is %i\n", fd ); > Index: SerialImp.h > =================================================================== > RCS file: /usr/local/cvsroot/rxtx-devel/src/SerialImp.h,v > retrieving revision 1.11.2.49 > diff -u -r1.11.2.49 SerialImp.h > --- SerialImp.h 5 Jul 2005 17:47:21 -0000 1.11.2.49 > +++ SerialImp.h 21 Mar 2006 12:59:17 -0000 > @@ -135,7 +135,8 @@ > /*# define LOCKDIR "/var/spool/uucp"*/ > # define LOCKDIR "/var/lock" > # define LOCKFILEPREFIX "LK." > -# define UUCP > +/*# define UUCP*/ > +# define OPEN_EXCL > #endif /* __APPLE__ */ > #if defined(__NetBSD__) > # define DEVICEDIR "/dev/" > This looks like a good start. What do you think Dmitry? Perhaps all systems with TIOCEXCL defined should use that though. Even if they use lockfiles. It wont hurt anything. That would catch people hacking their own serial apps without checking lockfiles. Its a good idea to avoid C++ style comments in the C portions. Some older systems don't deal with them well. If it's just for Mac OS X, it isn't a big deal. I think it was the Irix compiler that was problematic? -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Tue Mar 21 11:22:05 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 21 Mar 2006 11:22:05 -0700 (MST) Subject: [Rxtx] lock files In-Reply-To: <8E12916A-1B9A-4FF2-B684-E2D1C794221B@buechse.de> References: <8E12916A-1B9A-4FF2-B684-E2D1C794221B@buechse.de> Message-ID: We can try it. Maybe the JNI is much improved. The nice thing about linking into liblock is distros then worry about lockfiles on their systems. This way, we have to deal with any changes that may show up. On Tue, 21 Mar 2006, Joachim Buechse wrote: > This is pretty much what I thought about when I suggested, that the > default behaviour could be overwritten with a property. I am very much in > favor of this approach. In particular this allows much easier debugging > for PC based java developers. > > I think big parts of the Java (and maybe some parts of the C code) could > use a bit of a structural workover (unit tests, javadoc, synchronization, > etc). Maybe there should be a CVS branch for this experimental version. > I'd be happy to contribute a first workover for some of the Java code. > Designing for testability and implementing a good bunch of unit tests has > been a strategy that worked quite well in the Java projects I lead. And > it ultimately allows more liberal change permission. > > Regards, > Joachim > > > On 21.03.2006, at 08:51, Dr. Douglas Lyon wrote: > >> Hi All, >> You know, if the use of lock files were >> under Java control (rather than a build-time decision), >> it might enable a more unified binary distro. It might also >> facilitate quick prototyping of non-lock file approaches >> to resolving serial port contention issues (i.e., mac-like >> approaches vs. linux approaches, etc.). >> >> I realize that this is a radical overhaul of the lock file policy >> issue. Also, it may harm performance. On the other hand, >> our benchmarks on JNI overhead for modern processors indicate >> performance impact should be minimal. Perhaps it is more of >> an issue with the toybox systems. >> >> Suppose there were a class with a reasonable default...someone >> might write: >> SerialPortLockPolicy.setPolicy(SerialPortLockPolicy.UNIX_LOCK_FILE); >> SerialPortLockPolicy.setPolicy(SerialPortLockPolicy.NO_LOCK_CHECKING); >> SerialPortLockPolicy.setPolicy(SerialPortLockPolicy.MAC_STYLE); >> >> Thus, we could have a run-time reconfiguration of the serial port lock >> policy. A special NO_LOCK version of the binary would no longer >> be required. >> >> Any thoughts on this? >> >> Thanks! >> - Doug >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From dmarkman at mac.com Tue Mar 21 16:05:17 2006 From: dmarkman at mac.com (Dmitry Markman) Date: Tue, 21 Mar 2006 18:05:17 -0500 Subject: [Rxtx] PATCH: use of ioctl(fd, TIOCEXCL) instead of lockfiles In-Reply-To: References: <923AE774-EEA2-4911-92D8-32BB27802C8B@buechse.de> Message-ID: <512AC70C-BB86-48F2-A83C-023F35C23BAB@mac.com> I think it's cool, but I'd like to have that property implementation when user can choose between locking mechanism about comments: it's easy to change comments to the C style or we can use extensions of the file to cpp so c++ compiler will be used On Mar 21, 2006, at 1:05 PM, Trent Jarvi wrote: > This looks like a good start. What do you think Dmitry? Perhaps > all systems with TIOCEXCL defined should use that though. Even if > they use lockfiles. It wont hurt anything. That would catch > people hacking their own serial apps without checking lockfiles. > > Its a good idea to avoid C++ style comments in the C portions. > Some older systems don't deal with them well. If it's just for Mac > OS X, it isn't a big deal. I think it was the Irix compiler that > was problematic? Dmitry Markman From dmarkman at mac.com Tue Mar 21 16:13:00 2006 From: dmarkman at mac.com (Dmitry Markman) Date: Tue, 21 Mar 2006 18:13:00 -0500 Subject: [Rxtx] PATCH: use of ioctl(fd, TIOCEXCL) instead of lockfiles In-Reply-To: References: <923AE774-EEA2-4911-92D8-32BB27802C8B@buechse.de> Message-ID: I'd like to add that creating locking folder isn't a big deal we never had a problem related to the lock folders, because we always used installer on mac os x from other hand I'm not very much familiar with iotcl locking approach and I'm not sure it's more efficient Joachim wrote "I think it is the way to go, as it eliminates creating the lock directory which doesnt exist on the standard installation and it eliminates messing with the system group definitions (adding users to group uucp)." but I really didn't have any problem with that 1. doesn't exist on the standard installation there are many-many things that don't exist in the standard installation so I don't think that argument is strong enough 2. messing with the system group definitions I don't think we're messing with the group definition mac os x provides very clear way to set up group's members and together with Greg Guerin AuthKit there is no problem to set those definitions so I don't think that argument is strong either but from other hand using iotcl is more promising and is more elegant On Mar 21, 2006, at 1:05 PM, Trent Jarvi wrote: > > This looks like a good start. What do you think Dmitry? Perhaps > all systems with TIOCEXCL defined should use that though. Even if > they use lockfiles. It wont hurt anything. That would catch > people hacking their own serial apps without checking lockfiles. Dmitry Markman From joachim at buechse.de Wed Mar 22 04:46:45 2006 From: joachim at buechse.de (Joachim Buechse) Date: Wed, 22 Mar 2006 12:46:45 +0100 Subject: [Rxtx] PATCH: use of ioctl(fd, TIOCEXCL) instead of lockfiles In-Reply-To: References: <923AE774-EEA2-4911-92D8-32BB27802C8B@buechse.de> Message-ID: Sorry, I was not very clear with my arguments, so I will try again;-) Please, don't take this as an attack against work that has been done. I think the contributions that have been made in the past were made in a good spirit. But I really believe, that the current solution for OSX has many shortcomings and should be changed as soon as possible. lock files --- The /var/lock folder does not exist on the standard OSX installation, however the standard installation includes several applications that use serial ports (i.e. the FAX capability). This indicates, that the lock folder approach will not work well with system components. Applications for OSX will generally try to live in harmony with system components (except for HP print drivers of course). I think RXTX should follow this approach as well. uucp group --- Accessing serial ports is not an admin privileged operation on OSX. Any user (world) has read/write privileges on /dev/tty*. So the system default is to not enforce any group membership to access these ports. The group uucp however is a system group on all unix systems I know. It exists for certain system processes. A non admin user should in general not be a member of this group. Quite arguably no user should ever be a member of this group. Installer --- My general opinion is, that - no Installer should touch user or group data without warning - no Application Installer should touch groups which are not specific to the very application installed - no Installer should ever add regular users to a system group The current installer injects the installing user in the group uucp without warning about this change and without giving the option to "opt out" of this change. This is a potential security risk (but not currently a real one, as OSX contains no folders belonging to group uucp). The current installer does not work for multi user systems. It puts the installing user in the uucp group. However the installing user is not necessarily the user that will use the application. Putting all users that may use a serial port application in the system group uucp seems like a very invasive approach to me. Besides that, newly created users will not automatically be in the group and hence, serial applications will "break" for new users without obvious reasons. Avoiding the lock files will allow self contained applications (i.e. drag&drop installation). In my eyes this is largely preferable over an installer that requests admin privileges. Adding up all these points indicates very strongly, that the lock-file implementation is not the way to go on OSX. Regards, Joachim On 22.03.2006, at 00:13, Dmitry Markman wrote: > I'd like to add that > > creating locking folder isn't a big deal > we never had a problem related to the lock folders, because we > always used installer on mac os x > from other hand I'm not very much familiar with iotcl locking > approach and I'm not sure it's more efficient > > Joachim wrote "I think it is the way to go, as it eliminates > creating the lock directory which doesnt exist on the standard > installation and it eliminates messing with the system group > definitions (adding users to group uucp)." but I really didn't have > any problem with that > > 1. doesn't exist on the standard installation > there are many-many things that don't exist in the standard > installation so I don't think that argument is strong enough > 2. messing with the system group definitions > I don't think we're messing with the group definition > mac os x provides very clear way to set up group's members and > together with Greg Guerin AuthKit there is no problem to set those > definitions > so I don't think that argument is strong either > but from other hand using iotcl is more promising and is more elegant > > > > On Mar 21, 2006, at 1:05 PM, Trent Jarvi wrote: > >> >> This looks like a good start. What do you think Dmitry? Perhaps >> all systems with TIOCEXCL defined should use that though. Even if >> they use lockfiles. It wont hurt anything. That would catch >> people hacking their own serial apps without checking lockfiles. > > Dmitry Markman > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From dmarkman at mac.com Wed Mar 22 05:27:13 2006 From: dmarkman at mac.com (Dmitry Markman) Date: Wed, 22 Mar 2006 07:27:13 -0500 Subject: [Rxtx] PATCH: use of ioctl(fd, TIOCEXCL) instead of lockfiles In-Reply-To: References: <923AE774-EEA2-4911-92D8-32BB27802C8B@buechse.de> Message-ID: <83440CF3-DCD8-41C1-B941-F227232C27E3@mac.com> thanks for the very good explanation I didn't think that you were attacking any thing, so don't worry I just had feeling, that there were more aesthetic reasons for going to ioctl then real necessity now you explained everything quite well (BTW, asfar as I remember installer asks admin password so it wasn't quiet, but it really doesn't matter now) thanks On Mar 22, 2006, at 6:46 AM, Joachim Buechse wrote: > Sorry, I was not very clear with my arguments, so I will try again;-) > > Please, don't take this as an attack against work that has been > done. I think the contributions that have been made in the past > were made in a good spirit. But I really believe, that the current > solution for OSX has many shortcomings and should be changed as > soon as possible. > > lock files > --- > The /var/lock folder does not exist on the standard OSX > installation, however the standard installation includes several > applications that use serial ports (i.e. the FAX capability). This > indicates, that the lock folder approach will not work well with > system components. Applications for OSX will generally try to live > in harmony with system components (except for HP print drivers of > course). I think RXTX should follow this approach as well. > > uucp group > --- > Accessing serial ports is not an admin privileged operation on OSX. > Any user (world) has read/write privileges on /dev/tty*. So the > system default is to not enforce any group membership to access > these ports. The group uucp however is a system group on all unix > systems I know. It exists for certain system processes. A non admin > user should in general not be a member of this group. Quite > arguably no user should ever be a member of this group. > > Installer > --- > My general opinion is, that > - no Installer should touch user or group data without warning > - no Application Installer should touch groups which are not > specific to the very application installed > - no Installer should ever add regular users to a system group > > The current installer injects the installing user in the group uucp > without warning about this change and without giving the option to > "opt out" of this change. This is a potential security risk (but > not currently a real one, as OSX contains no folders belonging to > group uucp). > > The current installer does not work for multi user systems. It puts > the installing user in the uucp group. However the installing user > is not necessarily the user that will use the application. Putting > all users that may use a serial port application in the system > group uucp seems like a very invasive approach to me. Besides that, > newly created users will not automatically be in the group and > hence, serial applications will "break" for new users without > obvious reasons. > > > Avoiding the lock files will allow self contained applications > (i.e. drag&drop installation). In my eyes this is largely > preferable over an installer that requests admin privileges. Adding > up all these points indicates very strongly, that the lock-file > implementation is not the way to go on OSX. > > Regards, > Joachim > > > On 22.03.2006, at 00:13, Dmitry Markman wrote: > >> I'd like to add that >> >> creating locking folder isn't a big deal >> we never had a problem related to the lock folders, because we >> always used installer on mac os x >> from other hand I'm not very much familiar with iotcl locking >> approach and I'm not sure it's more efficient >> >> Joachim wrote "I think it is the way to go, as it eliminates >> creating the lock directory which doesnt exist on the standard >> installation and it eliminates messing with the system group >> definitions (adding users to group uucp)." but I really didn't >> have any problem with that >> >> 1. doesn't exist on the standard installation >> there are many-many things that don't exist in the standard >> installation so I don't think that argument is strong enough >> 2. messing with the system group definitions >> I don't think we're messing with the group definition >> mac os x provides very clear way to set up group's members and >> together with Greg Guerin AuthKit there is no problem to set those >> definitions >> so I don't think that argument is strong either >> but from other hand using iotcl is more promising and is more elegant >> >> >> >> On Mar 21, 2006, at 1:05 PM, Trent Jarvi wrote: >> >>> >>> This looks like a good start. What do you think Dmitry? Perhaps >>> all systems with TIOCEXCL defined should use that though. Even >>> if they use lockfiles. It wont hurt anything. That would catch >>> people hacking their own serial apps without checking lockfiles. >> >> Dmitry Markman >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx Dmitry Markman From lyon at docjava.com Wed Mar 22 06:12:18 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Wed, 22 Mar 2006 08:12:18 -0500 Subject: [Rxtx] sole of a new design pattern Message-ID: Hi All, I have been thinking about how we design the serial port software. I think we need a new design pattern. For lack of a better term, I shall call it: The Parametric Singleton Design Pattern By Douglas A. Lyon ABSTRACT The goal of the singleton design pattern is to make sure that there is one, and only one, instance of a given class. The goal of the parametric singleton design pattern is to make sure that there is one, and only one, instance of a given class with the given parametric values. We parametric singleton design pattern combines the singleton design pattern with a parameter that enables unique creation of instances of a class. These instances are cached. When a user asks for an instance with these parameters, the cache is checked. If the instance is in the cache, the instance is returned, otherwise it is created, added to the cache and then returned. We apply our parametric singleton design pattern to the retrieval of RMI registries bound to a given port. The goal of our system is to make sure that no two RMI registries are listening to the same socket and to make use of the RMI registries after they have been created. RMI registries are used in distributed computation. Introduction The singleton design pattern is meant to ensure that on a single instance of a class exists. It is also meant to provide a global point of access to it. The intent of the parametric singleton design pattern is to ensure that a class has only one instance for a given set of parameter values. It also provides a global point of access to it. Motivation A system cannot tolerate multiple instances of some classes with identical parameters. For example, you cannot have two instances making use of the same serial port, at the same time. You cannot have two instances that are trying to listen to the same socket connection. You cannot have two instances writing to the same file structure at the same time. As the operating system is often thought of as the arbiter of consumed resources (i.e., tape drives, serial ports, etc.) we frequently leave it to an operating system implementation to resolve these contention issues. Even for similar resources (like serial ports) there are few standards for handling contention. For example, serial ports on Linux are locked using a "/var/lock" file. POSIX, on the other hand, uses ioctl mechanisms to prevent contention. A better solution is to make a class that is responsible for keeping track of the instances created from the class. The class is declared final, so that it cannot be subclassed. The class also has a private constructor, so that other classes cannot instance it. The new design pattern is called the parametric singleton design pattern and it provides a way to access and create instances with given parameters. Applicability Use the Parametric Singleton Design Pattern when: 1. There must be exactly one instance of a class with the given parameters. 2. The instances must be accessible to clients from a well-known access point. Structure Insert UML diagram here. Participants The Parametric Singleton Clients that need instances 1. The Parametric Singleton defines an instance upon request from a client, if, and only if, the instance does not already exist. 2. The Parametric Singleton returns the instance to the client. 3. The Parametric Singleton is responsible for creating unique instances from given parameters. Collaborations Clients obtain a reference to a Parametric Singleton instance only through the parametric singleton design pattern. If the instance is left in an improper state (e.g., the serial port was left open) it is NOT the role of the Parametric Singleton Design Pattern to close the IO port. Nor is it the role of the Parametric Singleton Design Pattern to open the port. That role is delegate to some other part of the system. Further, it is not the role of the Parametric Singleton Design Pattern to check out resources. That is, multiple threads can have multiple references to the same resource at the same time. MUTEX locking is delegated to some other part of the system. Consequences The Parametric Singleton Design Pattern has several benefits: 1. Controlled access to parametrically defined instances. Since the Parametric Singleton class encapsulates its instances, there is control over how and when clients access it. 2. Reduced name space. The Parametric Singleton pattern avoids global variables that store instances created from the same parameter. Implementation Here are implementation issues to consider when using the Parametric Singleton pattern: 1. Unique mapping of parameters. The Parametric Singleton pattern requires that there be a mean to isomorphically map the parameter space into the instance space and back again. 2. Ensure unique instances. The Parametric Singleton pattern makes unique instances from parameters, and it does so only once. 3. Cache instances for fast retrieval. The Parametric Singleton pattern must be able to look up instances, given some set of parameters, and do so from some data structure. That is, there must be enough space to hold references to all the instances the program will need. Also, a mechanism is needed to look up and retrieve the instances quickly enough to satisfy the clients. Sample Code public final class ParametricSingletonRmiRegistry { private static Hashtable registry = new Hashtable(100); // use singleton pattern and??????????????????????????????????????????????? // prevent instantiation of RmiRegistryUtils.?????????????????????????????? private ParametricSingletonRmiRegistry() { } // the only instance of the Registry held by the RmiRegistryUtils?????????? public static void listNames(Integer port) { if (!isInCacheAndRunning(port)) return; Registry r = (Registry) registry.get(port); System.out.println("registry on port: " + port); System.out.println("registry: " + r); System.out.println("names: "); try { print(r.list()); } catch (RemoteException e) { In.message(e); } System.out.println("------------------------"); } /**???????????????????????????????????????????????????????????????????????? * Checks whether a Registry has been started on this host????????????????? * in the specified port.?????????????????????????????????????????????????? * If not, it tries to start one.?????????????????????????????????????????? * when it fails to start a Registry, it exits the program????????????????? * with exit code 1.??????????????????????????????????????????????????????? */ public static void restart(int port) { if (isInCacheAndRunning(port)) return; try { startRegistry(port); } catch (RemoteException e) { In.message(e); } } /**???????????????????????????????????????????????????????????????????????? * @param port????????????????????????????????????????????????????????????? * @return true if registry is in cache and running???????????????????????? */ private static boolean isInCacheAndRunning(Integer port) { if (!isRegistryRunning(port.intValue())) return false; if (!isRegistryInCache(port.intValue())) return false; return true; } /**???????????????????????????????????????????????????????????????????????? * @param port????????????????????????????????????????????????????????????? * @return true if we are able to locate a local registry on port.??????????????????????????????????????????????????????????????????????????? */ private static boolean isRegistryRunning(int port) { try { Registry r = LocateRegistry.getRegistry(port); if (r != null) return true; } catch (RemoteException e) { return false; } return false; } /**???????????????????????????????????????????????????????????????????????? * @param port????????????????????????????????????????????????????????????? * @return return true if registry is in cache????????????????????????????? */ private static boolean isRegistryInCache(int port) { if (registry.get(new Integer(port)) == null) return false; return true; } /**???????????????????????????????????????????????????????????????????????? * Restart the registry, if needed.???????????????????????????????????????? * Return the only instance of the registry for consistent global?????????? * using by making use of the Singleton Design Pattern????????????????????? *????????????????????????????????????????????????????????????????????????? * @return the internally held registry instance.?????????????????????????? */ public static Registry getRegistry(Integer port) { restart(port); return (Registry) registry.get(port); } private static void startRegistry(Integer port) throws RemoteException { Registry r; try { r = LocateRegistry.createRegistry(port.intValue()); registry.put(port, r); //r = new sun.rmi.registry.RegistryImpl???????????????????????????? /// (port.intValue());?????????????????????????????????????? // registry.put(port, r);?????????????????????????????????????????? } catch (Exception e) { //e.printStackTrace();????????????????????????????????????????????? r = LocateRegistry.getRegistry(port.intValue()); registry.put(port, r); } } public static void main(String args[]) throws RemoteException { //restart(port);??????????????????????????????????????????????????????? restart(5001); restart(5002); restart(5002); Registry r = LocateRegistry.getRegistry(5002); System.out.println("registry="+r); } } I would very much like to get your feedback on this new design pattern idea. Thank you for your time. Regards, - Doug From david.garnier at trusted-logic.com Wed Mar 22 07:36:10 2006 From: david.garnier at trusted-logic.com (David Garnier) Date: Wed, 22 Mar 2006 15:36:10 +0100 Subject: [Rxtx] sole of a new design pattern In-Reply-To: References: Message-ID: <442160DA.80107@trusted-logic.com> Hello, > The Parametric Singleton Design Pattern The Singleton is the most abused design pattern ever. Good use-cases for this pattern are extremely rare and mostly confined to problems related to hardware resources, like serial ports. > Applicability > > Use the Parametric Singleton Design Pattern when: > 1. There must be exactly one instance of a class with the given > parameters. OK. As I said above, this case this actually very unusual. The Singleton pattern is mostly used when : > 2. The instances must be accessible to clients from a well-known > access point. Using the singleton pattern in this case is just convenient for the programmer. Problems arises pretty quickly, especially if you attempt to unit-test your classes. 1) If your singleton is stateful, or hold on to stateful objects, it means that two different unit tests are not actually independent. Instead of starting with a brand new environment, the result of a test may be affected by the result of a previous test. This problem also arise when with your class relies on a database. In both cases, the solution is to reset your "unique" resource (Singleton or database) at the beginning of the test, which is a pain. Also, while most projects connect to a single database, projects that allow the use of Singletons usually contain several of thems, and new ones may cropped up unnoticed. You quickly end up with test cases that only pass in a certain order, which is a royal pain. 2) You cannot mockup a singleton. Once everyone calls the SomeSingleton class statically, you can't replace your class by SomeSingletonMockup. Furthermore, even for hardware services, the Singleton pattern does not really prevent concurrent accesses. If you start the same program in two different JVMs, unless they somehow shared the state of their "Singletons" (through lock files for example), the Singleton pattern will not prevent concurrent access. Our application uses RXTX, and we routinely encounter cases where another (native) application has already locked the port. Since we cannot modify the native application to recognize lock files, OS-level control is irreplaceable. > > Consequences > The Parametric Singleton Design Pattern has several benefits: > > 1. Controlled access to parametrically defined instances. Since > the Parametric Singleton class encapsulates its instances, there is > control over how and when clients access it. Not really. Once you've returned the instance to a client, you've lost control over it. The client can to whatever it wants with it. You cannot "recall" the instance or claim it back. > 2. Reduced name space. The Parametric Singleton pattern avoids > global variables that store instances created from the same parameter. Sure, but you don't have to rely on a Singleton for that. Just create a single Factory. > I would very much like to get your feedback on this new design > pattern idea. Well, it's nothing new. Some may say that it is the point of design patterns: formalizes the designs that occur again and again. However, this design is simply a combination of the Singleton and Factory patterns. I did use it in the past, but now I've been exposed to the shortcomings of the Singleton pattern, so I limit myself to Factories. Regards, David From sean_montgomery at baseview.com Wed Mar 22 08:35:28 2006 From: sean_montgomery at baseview.com (Sean Montgomery) Date: Wed, 22 Mar 2006 10:35:28 -0500 Subject: [Rxtx] sole of a new design pattern In-Reply-To: <442160DA.80107@trusted-logic.com> References: <442160DA.80107@trusted-logic.com> Message-ID: <05769CA7-A51B-4CF0-BAA0-E02DD905F5A4@baseview.com> On Mar 22, 2006, at 9:36 AM, David Garnier wrote: > Furthermore, even for hardware services, the Singleton pattern does > not really prevent concurrent > accesses. If you start the same program in two different JVMs, > unless they somehow shared the state > of their "Singletons" (through lock files for example), the > Singleton pattern will not prevent > concurrent access. > Multiple class loaders in a single JVM can be tricky, too. Then there's synchronization, lazy initialization and serialization of singletons to contend with. Bloch's Effective Java covers these, and here's a few articles: http://www.javaworld.com/javaworld/jw-04-2003/jw-0425-designpatterns- p3.html http://java.sun.com/developer/technicalArticles/Programming/singletons/ Just FYI :-) From lyon at docjava.com Wed Mar 22 08:50:48 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Wed, 22 Mar 2006 10:50:48 -0500 Subject: [Rxtx] sole of a new design pattern In-Reply-To: <442160DA.80107@trusted-logic.com> References: <442160DA.80107@trusted-logic.com> Message-ID: Hi All, First, I would like to thank David for his prompt and thoughtful remarks. I had no idea people that feel strongly about a design patterns! Wow! Feedback (particularly critical feedback) is greatly appreciated. Starting at the end, first: >I did use it in >the past, but now I've been exposed to the shortcomings of the >Singleton pattern, so I limit myself to Factories. David, if I understood your comments correctly, you suggested that Factories can be used in leu of the Singleton Design Pattern, or even the Parametric Singleton Design Pattern. As I see in [Gof]: Factory Method: Intent "Define an interface for creating an object, but let subclasses decide which class to instantiate. Factory Method lets a class defer instantiation to subclasses." The Singleton Design Pattern is a concrete class, which is rather different, right? Also, subclasses are not permitted with Singleton, as they are final. Naturally, I could use an abstract factory as a parent for a singleton. I could even design a facade that could be implemented with the singleton....but that is not the intention of the design. Unless you want a mock-up, as discussed, below: More below: >Hello, > >> The Parametric Singleton Design Pattern > >The Singleton is the most abused design pattern ever. Good use-cases >for this pattern are extremely >rare and mostly confined to problems related to hardware resources, >like serial ports. > > >> Applicability >> >> Use the Parametric Singleton Design Pattern when: >> 1. There must be exactly one instance of a class with the given >> parameters. >OK. As I said above, this case this actually very unusual. The >Singleton pattern is mostly used when : >> 2. The instances must be accessible to clients from a well-known >> access point. > >Using the singleton pattern in this case is just convenient for the >programmer. Problems arises >pretty quickly, especially if you attempt to unit-test your classes. > >1) If your singleton is stateful, or hold on to stateful objects, it >means that two different unit >tests are not actually independent. Instead of starting with a brand >new environment, the result of >a test may be affected by the result of a previous test. This >problem also arise when with your >class relies on a database. In both cases, the solution is to reset >your "unique" resource >(Singleton or database) at the beginning of the test, which is a >pain. Also, while most projects >connect to a single database, projects that allow the use of >Singletons usually contain several of >thems, and new ones may cropped up unnoticed. You quickly end up >with test cases that only pass in a >certain order, which is a royal pain. There are basic problems with communicating finite state machines that include reachability and deadlock analysis. These are addressed with petri net analysis and are beyond the scope of the design pattern. As you quite rightly pointed out; the parametric singleton pattern (or the singleton pattern, for that matter) enable multiple threads to gain access to the same instance. The only way that I can see to block others from gaining access to the reference is the synchronize keyword. This is putting a spin-lock (or MUTEX) on the reference. The question of how to unit-test a design pattern like the parametric singleton remains open. Perhaps this is a deficiency. > >2) You cannot mockup a singleton. Once everyone calls the >SomeSingleton class statically, you can't >replace your class by SomeSingletonMockup. Acutally, I am not sure that this is true. If the Singleton implements a Facade interface, it should be possible to make the replacement. Right? > >Furthermore, even for hardware services, the Singleton pattern does >not really prevent concurrent >accesses. If you start the same program in two different JVMs, >unless they somehow shared the state >of their "Singletons" (through lock files for example), the >Singleton pattern will not prevent >concurrent access. Good Point!! You have sharp eyes! The singleton design pattern should/could take responsibility for this. In fact, you may notice that my code does have an implementation (LocateRegistry) that can work across JVM's. The LocateRegistry will even work across the Internet! LocateRegistry takes both a host name and a Port (lock files just don't do this). I did not think to implement this beyond the local machine, but, in its present form, it will work across different processes. > >Our application uses RXTX, and we routinely encounter cases where >another (native) application has >already locked the port. Since we cannot modify the native >application to recognize lock files, >OS-level control is irreplaceable. The singleton design pattern is not meant to replace OS-level control, but to centralize the Java programmers access to it. If lock files, for example, are used for serial ports, the Singleton Design Pattern should be able to work with them. > > >> >> Consequences >> The Parametric Singleton Design Pattern has several benefits: >> > > 1. Controlled access to parametrically defined instances. Since >> the Parametric Singleton class encapsulates its instances, there is >> control over how and when clients access it. > >Not really. Once you've returned the instance to a client, you've >lost control over it. The client >can to whatever it wants with it. You cannot "recall" the instance >or claim it back. Good point, this should read: > 1. Controll when parametrically defined instances are created. Since > > the Parametric Singleton class encapsulates its instances, there is > > control over how and when they are instanced. > >> 2. Reduced name space. The Parametric Singleton pattern avoids >> global variables that store instances created from the same parameter. > >Sure, but you don't have to rely on a Singleton for that. Just >create a single Factory. > > Thank you for your thoughtful and prompt response! Regards, - Doug From dmarkman at mac.com Wed Mar 22 21:21:55 2006 From: dmarkman at mac.com (Dmitry Markman) Date: Wed, 22 Mar 2006 23:21:55 -0500 Subject: [Rxtx] sole of a new design pattern In-Reply-To: <442160DA.80107@trusted-logic.com> References: <442160DA.80107@trusted-logic.com> Message-ID: I don't think I get it On Mar 22, 2006, at 9:36 AM, David Garnier wrote: > Using the singleton pattern in this case is just convenient for the > programmer. Problems arises > pretty quickly, especially if you attempt to unit-test your classes. so you're saying that something isn't so good because you can not test it in the convenient way? if that's true, I'm totally disagree change your test, debug whatever, but if software is efficient at runtime, works fine and only problem is some unit test (which is some kind of framework for testing) then dump that unit test , dump that unit framework and make something appropriate to the software you're testing so if Douglas want to use singletons, what's the problem? and what do you mean by abusing of singleton usage? of course singleton doesn't prevent concurrent access to the resource across the processes unless you're using some OS facility to prevent it, besides singleton as it was introduced is relevant only and only inside of the same process otherwise it's not singleton it's something else (let's say network singleton: so you have remote invocation facility and some factory method that return object created by that facility) I don't have any problem with using any kind of singletons. Parametric Singleton idea (if I understand it right) could be easily implemented in the following way: use a map populate map with instances of some class and key is your parameter (you can use lazy population too) if somebody ask the key check the value if it's null so resource is taken if somebody returns the resource put it back to the map public synchronized static Object getSomeResource(Object parameter); public synchronized static void returnResource(Object parameter); getSomeResource (inside of the same process) could return null in 2 cases 1. if somebody (from other thread for example) already took that resource 2. if OS API said that resource corresponded to that parameter (serial port with parameter = 1 (port #)) is locked and unavailable; I'm not sure that in case of serial ports we even need those Parametric Singletons (unless lock checking is a very expensive operation) just ask the OS about availability of that resource and if it's available give it away and then OS will lock it and therefore in next time somebody ask it just answer that resource is locked and return null for example system has 2 serial ports available so I ask getResource("tty"); or I ask getResource("Bluetooth-Modem"); and if OS is ok you can give tty or Bluetooth-Modem or both no need for any additional pattern I think back to the problem mac os x doesn't recognize locking via files, so it handles locking via some API an instance of the singleton in each process should recognize that resource is locked (by using that API) that's all we don't have to make things more complicate then they are just because there is some nice design pattern or nice unit test framework or whatever keep things simple, make them work fast, don't introduce middle layers unless you have really good reason to do so of course I could be entirely wrong, so sorry about that in advance thanks Dmitry Markman From tjarvi at qbang.org Wed Mar 22 22:31:41 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 22 Mar 2006 22:31:41 -0700 (MST) Subject: [Rxtx] sole of a new design pattern In-Reply-To: References: Message-ID: Hi Doug Interesting reading. So far I'm just reading and thinking. I have one question so far. " Clients obtain a reference to a Parametric Singleton instance only through the parametric singleton design pattern. If the instance is left in an improper state (e.g., the serial port was left open) it is NOT the role of the Parametric Singleton Design Pattern to close the IO port. Nor is it the role of the Parametric Singleton Design Pattern to open the port. That role is delegate to some other part of the system. " So when the clients obtain a reference to the singleton, can they assume the port is there? IE, would it be the singletons role to handle things like USB dongles being removed with event hints comming from the underlying OS. Hardware abstraction layer/HAL on Linux is an example of underlying OS events. I assume that role too is delegated to other parts of the system? -- Trent Jarvi tjarvi at qbang.org From lyon at docjava.com Thu Mar 23 08:10:33 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Thu, 23 Mar 2006 10:10:33 -0500 Subject: [Rxtx] Classes don't need goals, they need roles! In-Reply-To: References: Message-ID: Hi Trent, Yes, I think that the role of the Parametric Singleton Pattern is not to open or close serial ports, nor is it to perform error checking. On the other hand, if you were to combine the role of the Parametric Singleton Pattern with another role (like that of error checking) it might not be amiss. However, I generally caution programmers against adding multiple roles to classes, as this leads to monolithic designs. Thus a different class (NativeLibDetect) could have the role of determining if the native library can be loaded. Another class (SerialPortBean) can have the role of serializing the default state of the serial port, so that it can be recovered, from user preferences, at a later time. The SerialPortDetect could have the role of determining if the serial port is removed (i.e., a USB port was unplugged). My guess is that each class should have a different role in the system, in order to ease maintenance and testing...but I could be wrong about that. Thanks! - Doug >Hi Doug > >Interesting reading. So far I'm just reading and thinking. I have >one question so far. > >" > Clients obtain a reference to a Parametric Singleton instance only >through the parametric singleton design pattern. If the instance is >left in an improper state (e.g., the serial port was left open) it is >NOT the role of the Parametric Singleton Design Pattern to close the >IO port. Nor is it the role of the Parametric Singleton Design Pattern >to >open the port. That role is delegate to some other part of the system. >" > >So when the clients obtain a reference to the singleton, can they >assume the port is there? IE, would it be the singletons role to >handle things like USB dongles being removed with event hints >comming from the underlying OS. Hardware abstraction layer/HAL on >Linux is an example of underlying OS events. > >I assume that role too is delegated to other parts of the system? > >-- >Trent Jarvi >tjarvi at qbang.org >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From maximulo at yahoo.com Fri Mar 24 01:22:38 2006 From: maximulo at yahoo.com (Maximulo Majir) Date: Fri, 24 Mar 2006 00:22:38 -0800 (PST) Subject: [Rxtx] JavaPOS Message-ID: <20060324082238.66371.qmail@web38214.mail.mud.yahoo.com> Hi all! Hello Trent! From what i understand, RXTX or JavaComm APIs were not created solely for JavaPOS. In JavaPOS, we have the virtual method claim() which is separate from open(), but in our RXTX API, claiming is done every call to open(), we cant open the port if its claimed by another application. Would it be alright to suggest or ask to create a new method called claim(..)? Is there such thing as forceclaim() in RXTX? this could be the same as portownership transfer or its equivalent. ForceClaim is in JSR80. Do you have some samples using RXTX as the lower layer for the Device Service Objects in JavaPOS? I have tried it, i just want to compare. Thank you all! maxim __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060324/496adba2/attachment-0010.html From tjarvi at qbang.org Fri Mar 24 11:28:19 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 24 Mar 2006 11:28:19 -0700 (MST) Subject: [Rxtx] Re: RXTX 2.1 Solaris Problems In-Reply-To: <3691.1143210578@www045.gmx.net> References: <3691.1143210578@www045.gmx.net> Message-ID: On Fri, 24 Mar 2006, Andreas Guenther wrote: > Hi all, > > the solaris problem was not the lock file only. > > Ok, I had to create the directory /var/spool/locks myself. > /var/spool/uucp exists. > > But rxtx didn't find any port. > > I compiled the source with my own debug-informations > and I tried to isolate the problem. > > The problem is the testRead-call in SerialImp.c > > JNIEXPORT jboolean JNICALL RXTXCommDriver(testRead)( > > ... > if ( READ( fd, &c, 1 ) < 0 ) > { > if ( errno != EAGAIN ) { > report( "testRead() read failed\n" ); > ret = JNI_FALSE; > } > } > Thanks Andreas I'm packing up to move. I'll be more or less away for a couple weeks here. I'll be checking email but my workstation is going into a box soon. This isn't hard to fix as this port should be enumerated when EWOULDBLOCK is recieved. Thats error is OK for enumeration just as EAGAIN is. I've put the bug into bugzilla so we dont forget to get to it. http://bugzilla.qbang.org/show_bug.cgi?id=42 You can add yourself to the CC list if you wish to test fixes we provide or even put a patch into bugzilla yourself. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Fri Mar 24 11:51:52 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 24 Mar 2006 11:51:52 -0700 (MST) Subject: [Rxtx] JavaPOS In-Reply-To: <20060324082238.66371.qmail@web38214.mail.mud.yahoo.com> References: <20060324082238.66371.qmail@web38214.mail.mud.yahoo.com> Message-ID: On Fri, 24 Mar 2006, Maximulo Majir wrote: > Hi all! Hello Trent! > > > From what i understand, RXTX or JavaComm APIs were not > created solely for JavaPOS. In JavaPOS, we have the virtual method > claim() which is separate from open(), but in our RXTX API, claiming is > done every call to open(), we cant open the port if its claimed by > another application. Would it be alright to suggest or ask to create a > new method called claim(..)? Is there such thing as forceclaim() in > RXTX? this could be the same as portownership transfer or its > equivalent. ForceClaim is in JSR80. > Do you have some samples using RXTX as the lower layer for the Device > Service Objects in JavaPOS? I have tried it, i just want to compare. > maxim Hi Maxim JSR80 is the USB API IBM/Sun put together. The problem is they have a richer kernel/API underneath that can handle such things. With Serial Ports, there isnt anything there other than an ioctl that says don't let anyone touch this and lockfiles that are more of a 'lets be nice.' At times we may be using USB ports but it is through the termios layer with the limitations mentioned. The advantage is that not only USB will work with rxtx. Anything that has a termios layer should work (to the extent that termios layer is complete). I don't know how forceclaim() would help you. Lets say someone has a programmer working on /dev/ttyS0 and you take it. Now you both race each other to read data first. There isn't a mechanism I know of that will solve this problem in termios. The most obvious test being a native app and a Java app trying to take the port. There is the potential of requestion ownership from other Java Applications but the use for that is very rare. Did you have something more specific in mind that I'm missing? I'm not sure that claim() and forceclaim() would help you with rxtx other than maybe locking the port with claim() without opening it. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sat Mar 25 23:42:08 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 25 Mar 2006 23:42:08 -0700 (MST) Subject: [Rxtx] Serial snoop Message-ID: I was reading the Linux kernel mail-list tonight and ran past a thread that mentioned sersnoop. This looks like a handy tool for people dealing with new toys. "a simple command-line tool for linux that echoes bytes to and from any two serial ports, ptys, or network sockets, and prints all traffic to stdout, in hex and ascii." http://www.restivo.org/projects/sersnoop/ It works on Linux only at this time (debian package available). -- Trent Jarvi tjarvi at qbang.org From beat.arnet at gmail.com Sun Mar 26 07:32:35 2006 From: beat.arnet at gmail.com (Beat Arnet) Date: Sun, 26 Mar 2006 09:32:35 -0500 Subject: [Rxtx] Error 0x5 at /home/bob/foo/tar/rxtx-2.1-7/build/../src/termios.c(860): Access is, denied. Message-ID: <4426A603.80508@gmail.com> Dear all, When trying to open the serial port, I sometimes (not always) run into the following exception (when opening the serialPort): Error 0x5 at /home/bob/foo/tar/rxtx-2.1-7/build/../src/termios.c(860): Access is denied. java.lang.UnsatisfiedLinkError: native_psmisc_report_owner at gnu.io.CommPortIdentifier.native_psmisc_report_owner(Native Method) at gnu.io.CommPortIdentifier.open(CommPortIdentifier.java:354) at codeskin.tools.CLLoader.open(CLLoader.java:79) at codeskin.tools.C2000Programmer.run(C2000Programmer.java:220) at java.lang.Thread.run(Unknown Source) Is this the type of error where I should just try to open the port again, or can it be avoided? Regards, Beat From tjarvi at qbang.org Sun Mar 26 11:40:12 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 26 Mar 2006 11:40:12 -0700 (MST) Subject: [Rxtx] Error 0x5 at /home/bob/foo/tar/rxtx-2.1-7/build/../src/termios.c(860): Access is, denied. In-Reply-To: <4426A603.80508@gmail.com> References: <4426A603.80508@gmail.com> Message-ID: On Sun, 26 Mar 2006, Beat Arnet wrote: > Dear all, > > When trying to open the serial port, I sometimes (not always) run into > the following exception (when opening the serialPort): > > Error 0x5 at /home/bob/foo/tar/rxtx-2.1-7/build/../src/termios.c(860): > Access is > denied. > > java.lang.UnsatisfiedLinkError: native_psmisc_report_owner > at gnu.io.CommPortIdentifier.native_psmisc_report_owner(Native > Method) > at gnu.io.CommPortIdentifier.open(CommPortIdentifier.java:354) > at codeskin.tools.CLLoader.open(CLLoader.java:79) > at codeskin.tools.C2000Programmer.run(C2000Programmer.java:220) > at java.lang.Thread.run(Unknown Source) > > Is this the type of error where I should just try to open the port again, > or can it be avoided? > Hi Beat We did a second build of rxtx 2.1-7 to resolve that unsatisfied link error. It should work now. rxtx is trying to tell you it thinks someone else has the serial port open. You can try to open the port again but maybe you already have a copy of the program running when it happens? ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7r2.zip fixed build. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sun Mar 26 11:44:23 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 26 Mar 2006 11:44:23 -0700 (MST) Subject: [Rxtx] RXTX spec file (fwd) Message-ID: This is probably interesting for fedora/suse users. ---------- Forwarded message ---------- Date: Sun, 26 Mar 2006 16:25:45 +0200 To: taj at www.linux.org.uk Subject: RXTX spec file I send you this spec file which allows to create a RPM for Fedora 4, 5 (x86, x86_64) with Java Sun. -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: rxtx.spec Url: http://mailman.qbang.org/pipermail/rxtx/attachments/20060326/6c7b6af6/rxtx-0006.pl From tjarvi at qbang.org Sun Mar 26 23:42:59 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 26 Mar 2006 23:42:59 -0700 (MST) Subject: [Rxtx] Upcomming events. Message-ID: This Wednesday we will be announcing a new "Maintainer" for the rxtx project. The position is more like neutral leader. I wont be going away or doing less. This is just the right thing to do as it turns out the two people with CVS write access will be at the same company. We need a third and we need neutrality. The maintainer will have final say in any conflict and will try to be neutral. It will be open for discussion. Then we will do it :) I'll still do most of the footwork I do now. But. I'm falling behind. I should have gone through the mail-list and posted the next round of changes this weekend. I'm packing to move and its going so so - 13 years of toys collected. I suspect there will be a dead period on my part (a couple weeks) comming up. But if you get it on the mail-list, we will get it in if there are no objections. I may well not be reading the mail-list during this period as I look for a house and many other things. I hope everyone will help out. Thanks -- Trent Jarvi tjarvi at qbang.org From mahmoud_hadad at yahoo.com Sun Mar 26 07:31:19 2006 From: mahmoud_hadad at yahoo.com (ronan nick) Date: Sun, 26 Mar 2006 06:31:19 -0800 (PST) Subject: [Rxtx] a question about the COMM API Message-ID: <20060326143119.54919.qmail@web60014.mail.yahoo.com> hi, i was intrested in knowing how i can communicate with my internal modem using java? for example if i want to make a phone dialer application or a caller id application where should i be looking at? and as i understood the COMM API is for devices that is attached to the computer through serial ports. --------------------------------- New Yahoo! Messenger with Voice. Call regular phones from your PC and save big. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060326/ce8329f0/attachment-0008.html From dmarkman at mac.com Mon Mar 20 00:20:43 2006 From: dmarkman at mac.com (Dmitry Markman) Date: Mon, 20 Mar 2006 02:20:43 -0500 Subject: [Rxtx] Mac OS X RXTX java installer In-Reply-To: References: <07D0DE29-BA32-4CFE-B036-66BC6423D385@buechse.de> <441AE3E0.2030503@willicon.de> <12531986.1142622114996.JavaMail.dmarkman@mac.com> <441B2674.9010409@willicon.de> <13577405.1142634732776.JavaMail.dmarkman@mac.com> <441B4182.8010407@willicon.de> <92CD0D6C-5BE8-426E-A46D-99452059FF49@mac.com> <441BBB2D.8030305@willicon.de> <441C4088.5090905@willicon.de> Message-ID: <64BC1E23-FDDE-4CE6-8863-CFC881CBC224@mac.com> Hi all I put RXTX installer that will install everything (and will create / var/lock if necessary and add user to the uucp group) for mac os x from Java into the rxtx's CVS repository it could be easily modified to install files for any platform it uses Greg Guerin's AuthKit for authentication and authorization Greg released that kit under artistic license, so Trent, please take a look we, probably, can negotiate license with Greg if it's necessary Greg's AuthKit could be downloaded from http://www.amug.org/~glguerin/ sw/#authkit Michael Hall (mikehall at spacestar dot net) had a suggestion to make implementation of the jaas LoginModule based on Greg's AuthKit (his modification of the Greg's AuthKit could be found at http:// www.spacestar.net/users/mikehall/authkit.dmg) but Michael's AuthKitLoginModule does only half a job: it does authenticate but it can not run any external unix process in privileged mode (at least I wasn't able to do so) possible explanation could be found in conversation between Greg and Michael at Apple's java-dev list (look for archives) so I didn't use jaas API for rxtxinstaller I created folder MacOSX in the contrib folder comment 1. if you want to run that installer as standalone application all you need that RXTXInstaller.jar 2. if you want to use webstart you have to add Greg's libAuthKit.jnilib to the mac os x's resources in theory RXTXInstaller.jar doesn't need it, but there is a problem with loading libAuthKit.jnilib from webstart authkit uses loadLibrary method to load library and it failed (from webstart) for standalone application I extract libAuthKit.jnilib from the RXTXInstaller.jar and put it into the /Library/Java/Extensions or ~/Library/Java/Extensions folder that file will be deleted after installer quit unfortunately I didn't have time to put documentation there but it is mostly self-explanatory I took installer code from my gl4java installer that I did about 3 years ago (with small modifications) it would be very nice if Apple will release LoginModule that really will do the job (com.apple.security.auth.module package????? ) (UnixLoginModule is pretty useless) From lyon at docjava.com Mon Mar 20 06:34:39 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Mon, 20 Mar 2006 08:34:39 -0500 Subject: [Rxtx] Mac OS X RXTX java installer In-Reply-To: <64BC1E23-FDDE-4CE6-8863-CFC881CBC224@mac.com> References: <07D0DE29-BA32-4CFE-B036-66BC6423D385@buechse.de> <441AE3E0.2030503@willicon.de> <12531986.1142622114996.JavaMail.dmarkman@mac.com> <441B2674.9010409@willicon.de> <13577405.1142634732776.JavaMail.dmarkman@mac.com> <441B4182.8010407@willicon.de> <92CD0D6C-5BE8-426E-A46D-99452059FF49@mac.com> <441BBB2D.8030305@willicon.de> <441C4088.5090905@willicon.de> <64BC1E23-FDDE-4CE6-8863-CFC881CBC224@mac.com> Message-ID: Hi Dimitry, This sounds like great work. Just a couple of questions; After the check out of the CVS files, using: setenv CVSROOT :pserver:anonymous at cvs.milestonesolutions.com:/usr/local/cvsroot 53 8:28 setenv PASSWORD mousy 54 8:29 cvs login 55 8:29 cvs checkout rxtx-devel I cd'd over to: rxtx-devel/MACOSX_IDE And found: CVS/ CW/ ForPackageMaker/ PB/ Where is the installer? Thanks! - Doug From tjarvi at qbang.org Mon Mar 20 06:39:37 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 20 Mar 2006 06:39:37 -0700 (MST) Subject: [Rxtx] Mac OS X RXTX java installer In-Reply-To: References: <07D0DE29-BA32-4CFE-B036-66BC6423D385@buechse.de> <441AE3E0.2030503@willicon.de> <12531986.1142622114996.JavaMail.dmarkman@mac.com> <441B2674.9010409@willicon.de> <13577405.1142634732776.JavaMail.dmarkman@mac.com> <441B4182.8010407@willicon.de> <92CD0D6C-5BE8-426E-A46D-99452059FF49@mac.com> <441BBB2D.8030305@willicon.de> <441C4088.5090905@willicon.de> <64BC1E23-FDDE-4CE6-8863-CFC881CBC224@mac.com> Message-ID: On Mon, 20 Mar 2006, Dr. Douglas Lyon wrote: > Hi Dimitry, > This sounds like great work. Just a couple of questions; > After the check out of the CVS files, using: > setenv CVSROOT > :pserver:anonymous at cvs.milestonesolutions.com:/usr/local/cvsroot > 53 8:28 setenv PASSWORD mousy > 54 8:29 cvs login > 55 8:29 cvs checkout rxtx-devel Hi Doug You want "cvs checkout -r commapi-0-0-1 rxtx-devel" to get RXTX 2.1 The default branch is rxtx 2.0 which isn't very active right now. -- Trent Jarvi tjarvi at qbang.org From lyon at docjava.com Mon Mar 20 07:05:44 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Mon, 20 Mar 2006 09:05:44 -0500 Subject: [Rxtx] Mac OS X RXTX java installer In-Reply-To: References: <07D0DE29-BA32-4CFE-B036-66BC6423D385@buechse.de> <441AE3E0.2030503@willicon.de> <12531986.1142622114996.JavaMail.dmarkman@mac.com> <441B2674.9010409@willicon.de> <13577405.1142634732776.JavaMail.dmarkman@mac.com> <441B4182.8010407@willicon.de> <92CD0D6C-5BE8-426E-A46D-99452059FF49@mac.com> <441BBB2D.8030305@willicon.de> <441C4088.5090905@willicon.de> <64BC1E23-FDDE-4CE6-8863-CFC881CBC224@mac.com> Message-ID: Hi Trent, Thanks for the info on the CVS checkout procedure. I did that and am still not sure where the installer is. Here is what I have: cd MACOSX_IDE/ p4.docjava.com{lyon}121: ls CVS/ ForPackageMaker/ PB/ p4.docjava.com{lyon}122: find . | more . ./ForPackageMaker ./ForPackageMaker/RXTX.pkg.sit.hqx ./ForPackageMaker/Resources ./ForPackageMaker/Resources/ReadMe.rtf ./ForPackageMaker/Resources/Welcome.rtf ./ForPackageMaker/Resources/CVS ./ForPackageMaker/Resources/CVS/Entries ./ForPackageMaker/Resources/CVS/Repository ./ForPackageMaker/Resources/CVS/Tag ./ForPackageMaker/Resources/CVS/Root ./ForPackageMaker/Resources/preinstall ./ForPackageMaker/Resources/License.rtf ./ForPackageMaker/Resources/preupgrade ./ForPackageMaker/RXTX.pmsp ./ForPackageMaker/CVS ./ForPackageMaker/CVS/Entries ./ForPackageMaker/CVS/Repository ./ForPackageMaker/CVS/Entries.Log ./ForPackageMaker/CVS/Tag ./ForPackageMaker/CVS/Root ./ForPackageMaker/RXTX_Tiger.pkg.sitx.hqx ./ForPackageMaker/RXTX_Jag.pkg.sit.hqx ./ForPackageMaker/Install ./ForPackageMaker/Install/CVS ./ForPackageMaker/Install/CVS/Entries ./ForPackageMaker/Install/CVS/Repository ./ForPackageMaker/Install/CVS/Tag ./ForPackageMaker/Install/CVS/Root ./ForPackageMaker/Install/Library ./ForPackageMaker/Install/Library/CVS ./ForPackageMaker/Install/Library/CVS/Entries ./ForPackageMaker/Install/Library/CVS/Repository ./ForPackageMaker/Install/Library/CVS/Tag ./ForPackageMaker/Install/Library/CVS/Root ./ForPackageMaker/Install/Library/Java ./ForPackageMaker/Install/Library/Java/Extensions ./ForPackageMaker/Install/Library/Java/Extensions/RXTXcomm.jar ./ForPackageMaker/Install/Library/Java/Extensions/CVS ./ForPackageMaker/Install/Library/Java/Extensions/CVS/Entries ./ForPackageMaker/Install/Library/Java/Extensions/CVS/Repository ./ForPackageMaker/Install/Library/Java/Extensions/CVS/Tag ./ForPackageMaker/Install/Library/Java/Extensions/CVS/Root ./ForPackageMaker/Install/Library/Java/Extensions/librxtxSerial.jnilib ./ForPackageMaker/Install/Library/Java/CVS ./ForPackageMaker/Install/Library/Java/CVS/Entries ./ForPackageMaker/Install/Library/Java/CVS/Repository ./ForPackageMaker/Install/Library/Java/CVS/Entries.Log ./ForPackageMaker/Install/Library/Java/CVS/Tag ./ForPackageMaker/Install/Library/Java/CVS/Root ./ForPackageMaker/RXTX_Tiger.pmproj.sitx.hqx ./CVS ./CVS/Entries ./CVS/Repository ./CVS/Entries.Log ./CVS/Tag ./CVS/Root ./PB ./PB/LibSerialUniversal.xcodeproj.sitx.hqx ./PB/CVS ./PB/CVS/Entries ./PB/CVS/Repository ./PB/CVS/Entries.Log ./PB/CVS/Tag ./PB/CVS/Root ./PB/LibSerial.pbproj.sit.hqx ./PB/startpoint.c ./PB/config.h What is the procedure to run this installer? Do we need a README in: /rxtx-devel/MACOSX_IDE Here is what we have: CVS/ ForPackageMaker/ PB/ Thanks! - DL >On Mon, 20 Mar 2006, Dr. Douglas Lyon wrote: > >>Hi Dimitry, >>This sounds like great work. Just a couple of questions; >>After the check out of the CVS files, using: >>setenv CVSROOT >>:pserver:anonymous at cvs.milestonesolutions.com:/usr/local/cvsroot >> 53 8:28 setenv PASSWORD mousy >> 54 8:29 cvs login >> 55 8:29 cvs checkout rxtx-devel > >Hi Doug > >You want "cvs checkout -r commapi-0-0-1 rxtx-devel" to get RXTX 2.1 >The default branch is rxtx 2.0 which isn't very active right now. > >-- >Trent Jarvi >tjarvi at qbang.org From tjarvi at qbang.org Mon Mar 20 07:25:30 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 20 Mar 2006 07:25:30 -0700 (MST) Subject: [Rxtx] Mac OS X RXTX java installer In-Reply-To: References: <07D0DE29-BA32-4CFE-B036-66BC6423D385@buechse.de> <441AE3E0.2030503@willicon.de> <12531986.1142622114996.JavaMail.dmarkman@mac.com> <441B2674.9010409@willicon.de> <13577405.1142634732776.JavaMail.dmarkman@mac.com> <441B4182.8010407@willicon.de> <92CD0D6C-5BE8-426E-A46D-99452059FF49@mac.com> <441BBB2D.8030305@willicon.de> <441C4088.5090905@willicon.de> <64BC1E23-FDDE-4CE6-8863-CFC881CBC224@mac.com> Message-ID: On Mon, 20 Mar 2006, Dr. Douglas Lyon wrote: > Hi Trent, > Thanks for the info on the CVS checkout procedure. > I did that and am still not sure where the installer is. Hi Doug It does look like it was not cvs committed. There is no rxtx-devel/contrib/MacOSX directory in there at the moment. It was mentioned that it was put under contrib. -- Trent Jarvi tjarvi at qbang.org From dmarkman at mac.com Mon Mar 20 07:29:56 2006 From: dmarkman at mac.com (Dmitry Markman) Date: Mon, 20 Mar 2006 09:29:56 -0500 Subject: [Rxtx] Mac OS X RXTX java installer In-Reply-To: References: <07D0DE29-BA32-4CFE-B036-66BC6423D385@buechse.de> <441AE3E0.2030503@willicon.de> <12531986.1142622114996.JavaMail.dmarkman@mac.com> <441B2674.9010409@willicon.de> <13577405.1142634732776.JavaMail.dmarkman@mac.com> <441B4182.8010407@willicon.de> <92CD0D6C-5BE8-426E-A46D-99452059FF49@mac.com> <441BBB2D.8030305@willicon.de> <441C4088.5090905@willicon.de> <64BC1E23-FDDE-4CE6-8863-CFC881CBC224@mac.com> Message-ID: <6054EB4E-F7E0-4A9C-BDDA-D582D6D8826F@mac.com> you can find it in the rxtx-devel/contrib folder On Mar 20, 2006, at 9:05 AM, Dr. Douglas Lyon wrote: > Hi Trent, > Thanks for the info on the CVS checkout procedure. > I did that and am still not sure where the installer is. > Here is what I have: > cd MACOSX_IDE/ > p4.docjava.com{lyon}121: ls > CVS/ ForPackageMaker/ PB/ > p4.docjava.com{lyon}122: find . | more > . > ./ForPackageMaker > ./ForPackageMaker/RXTX.pkg.sit.hqx > ./ForPackageMaker/Resources > ./ForPackageMaker/Resources/ReadMe.rtf > ./ForPackageMaker/Resources/Welcome.rtf > ./ForPackageMaker/Resources/CVS > ./ForPackageMaker/Resources/CVS/Entries > ./ForPackageMaker/Resources/CVS/Repository > ./ForPackageMaker/Resources/CVS/Tag > ./ForPackageMaker/Resources/CVS/Root > ./ForPackageMaker/Resources/preinstall > ./ForPackageMaker/Resources/License.rtf > ./ForPackageMaker/Resources/preupgrade > ./ForPackageMaker/RXTX.pmsp > ./ForPackageMaker/CVS > ./ForPackageMaker/CVS/Entries > ./ForPackageMaker/CVS/Repository > ./ForPackageMaker/CVS/Entries.Log > ./ForPackageMaker/CVS/Tag > ./ForPackageMaker/CVS/Root > ./ForPackageMaker/RXTX_Tiger.pkg.sitx.hqx > ./ForPackageMaker/RXTX_Jag.pkg.sit.hqx > ./ForPackageMaker/Install > ./ForPackageMaker/Install/CVS > ./ForPackageMaker/Install/CVS/Entries > ./ForPackageMaker/Install/CVS/Repository > ./ForPackageMaker/Install/CVS/Tag > ./ForPackageMaker/Install/CVS/Root > ./ForPackageMaker/Install/Library > ./ForPackageMaker/Install/Library/CVS > ./ForPackageMaker/Install/Library/CVS/Entries > ./ForPackageMaker/Install/Library/CVS/Repository > ./ForPackageMaker/Install/Library/CVS/Tag > ./ForPackageMaker/Install/Library/CVS/Root > ./ForPackageMaker/Install/Library/Java > ./ForPackageMaker/Install/Library/Java/Extensions > ./ForPackageMaker/Install/Library/Java/Extensions/RXTXcomm.jar > ./ForPackageMaker/Install/Library/Java/Extensions/CVS > ./ForPackageMaker/Install/Library/Java/Extensions/CVS/Entries > ./ForPackageMaker/Install/Library/Java/Extensions/CVS/Repository > ./ForPackageMaker/Install/Library/Java/Extensions/CVS/Tag > ./ForPackageMaker/Install/Library/Java/Extensions/CVS/Root > ./ForPackageMaker/Install/Library/Java/Extensions/librxtxSerial.jnilib > ./ForPackageMaker/Install/Library/Java/CVS > ./ForPackageMaker/Install/Library/Java/CVS/Entries > ./ForPackageMaker/Install/Library/Java/CVS/Repository > ./ForPackageMaker/Install/Library/Java/CVS/Entries.Log > ./ForPackageMaker/Install/Library/Java/CVS/Tag > ./ForPackageMaker/Install/Library/Java/CVS/Root > ./ForPackageMaker/RXTX_Tiger.pmproj.sitx.hqx > ./CVS > ./CVS/Entries > ./CVS/Repository > ./CVS/Entries.Log > ./CVS/Tag > ./CVS/Root > ./PB > ./PB/LibSerialUniversal.xcodeproj.sitx.hqx > ./PB/CVS > ./PB/CVS/Entries > ./PB/CVS/Repository > ./PB/CVS/Entries.Log > ./PB/CVS/Tag > ./PB/CVS/Root > ./PB/LibSerial.pbproj.sit.hqx > ./PB/startpoint.c > ./PB/config.h > > What is the procedure to run this installer? > Do we need a README in: > /rxtx-devel/MACOSX_IDE > Here is what we have: > CVS/ ForPackageMaker/ PB/ > > > Thanks! > - DL > >> On Mon, 20 Mar 2006, Dr. Douglas Lyon wrote: >> >>> Hi Dimitry, >>> This sounds like great work. Just a couple of questions; >>> After the check out of the CVS files, using: >>> setenv CVSROOT :pserver:anonymous at cvs.milestonesolutions.com:/usr/ >>> local/cvsroot >>> 53 8:28 setenv PASSWORD mousy >>> 54 8:29 cvs login >>> 55 8:29 cvs checkout rxtx-devel >> >> Hi Doug >> >> You want "cvs checkout -r commapi-0-0-1 rxtx-devel" to get RXTX 2.1 >> The default branch is rxtx 2.0 which isn't very active right now. >> >> -- >> Trent Jarvi >> tjarvi at qbang.org > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx Dmitry Markman From mikehall at spacestar.net Mon Mar 20 05:25:25 2006 From: mikehall at spacestar.net (Michael Hall) Date: Mon, 20 Mar 2006 06:25:25 -0600 Subject: [Rxtx] Re: Mac OS X RXTX java installer In-Reply-To: <64BC1E23-FDDE-4CE6-8863-CFC881CBC224@mac.com> References: <07D0DE29-BA32-4CFE-B036-66BC6423D385@buechse.de> <441AE3E0.2030503@willicon.de> <12531986.1142622114996.JavaMail.dmarkman@mac.com> <441B2674.9010409@willicon.de> <13577405.1142634732776.JavaMail.dmarkman@mac.com> <441B4182.8010407@willicon.de> <92CD0D6C-5BE8-426E-A46D-99452059FF49@mac.com> <441BBB2D.8030305@willicon.de> <441C4088.5090905@willicon.de> <64BC1E23-FDDE-4CE6-8863-CFC881CBC224@mac.com> Message-ID: <247EB61F-5CD1-4132-89A2-FC105B6CF9A5@spacestar.net> On Mar 20, 2006, at 1:20 AM, Dmitry Markman wrote: > > Michael Hall (mikehall at spacestar dot net) had a suggestion to > make implementation of the jaas LoginModule > based on Greg's AuthKit > (his modification of the Greg's AuthKit could be found at http:// > www.spacestar.net/users/mikehall/authkit.dmg) > but Michael's AuthKitLoginModule does only half a job: > it does authenticate > but it can not run any external unix process in privileged mode (at > least I wasn't able to do so) If you got it working directly with Greg's the point is moot. But to clarify it anyhow. The login module does not allow you to do anything anything privileged on return as was explained by Greg. You need to work with a separate privileged process using the execPrivileged method of his API. I assume you did something similar although I haven't looked at how you are using it yet. I allowed instead for a action to be performed at the same time you login/authenticate,this... System.setProperty("authkit.action","/usr/bin/id"); just before this... lc.login(); To clarify, safely ignored as you are already complete. Mike Hall mikehall at spacestar dot net http://www.spacestar.net/users/mikehall http://sourceforge.net/projects/macnative -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2427 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20060320/f6e18202/smime-0011.bin From dmarkman at mac.com Mon Mar 20 07:36:47 2006 From: dmarkman at mac.com (Dmitry Markman) Date: Mon, 20 Mar 2006 09:36:47 -0500 Subject: [Rxtx] Re: Mac OS X RXTX java installer In-Reply-To: <247EB61F-5CD1-4132-89A2-FC105B6CF9A5@spacestar.net> References: <07D0DE29-BA32-4CFE-B036-66BC6423D385@buechse.de> <441AE3E0.2030503@willicon.de> <12531986.1142622114996.JavaMail.dmarkman@mac.com> <441B2674.9010409@willicon.de> <13577405.1142634732776.JavaMail.dmarkman@mac.com> <441B4182.8010407@willicon.de> <92CD0D6C-5BE8-426E-A46D-99452059FF49@mac.com> <441BBB2D.8030305@willicon.de> <441C4088.5090905@willicon.de> <64BC1E23-FDDE-4CE6-8863-CFC881CBC224@mac.com> <247EB61F-5CD1-4132-89A2-FC105B6CF9A5@spacestar.net> Message-ID: Hi, Michael all I have to do is to run some shell script I tried to use your action mechanism and it worked great so I just System.setProperty ("authkit.action","" ) and after that I even don't need to run anything like subject.doAs.... but after few thoughts I choose to use plain Greg's approach, because in that case I don't have to deal with various java's configurations files and therefore to use 2-3 -D parameters in the java command line especially it's useful for java web start (it's so fragile :-( ) thanks for the great job On Mar 20, 2006, at 7:25 AM, Michael Hall wrote: > > On Mar 20, 2006, at 1:20 AM, Dmitry Markman wrote: >> >> Michael Hall (mikehall at spacestar dot net) had a suggestion to >> make implementation of the jaas LoginModule >> based on Greg's AuthKit >> (his modification of the Greg's AuthKit could be found at http:// >> www.spacestar.net/users/mikehall/authkit.dmg) >> but Michael's AuthKitLoginModule does only half a job: >> it does authenticate >> but it can not run any external unix process in privileged mode >> (at least I wasn't able to do so) > > If you got it working directly with Greg's the point is moot. > > But to clarify it anyhow. > The login module does not allow you to do anything anything > privileged on return as was explained by Greg. You need to work > with a separate privileged process using the execPrivileged method > of his API. I assume you did something similar although I haven't > looked at how you are using it yet. > I allowed instead for a action to be performed at the same time you > login/authenticate,this... > System.setProperty("authkit.action","/usr/bin/id"); > just before this... > lc.login(); > To clarify, safely ignored as you are already complete. > > Mike Hall mikehall at spacestar dot net > http://www.spacestar.net/users/mikehall > http://sourceforge.net/projects/macnative > > > Dmitry Markman From dmarkman at mac.com Mon Mar 20 07:44:45 2006 From: dmarkman at mac.com (Dmitry Markman) Date: Mon, 20 Mar 2006 09:44:45 -0500 Subject: [Rxtx] Mac OS X RXTX java installer In-Reply-To: References: <07D0DE29-BA32-4CFE-B036-66BC6423D385@buechse.de> <441AE3E0.2030503@willicon.de> <12531986.1142622114996.JavaMail.dmarkman@mac.com> <441B2674.9010409@willicon.de> <13577405.1142634732776.JavaMail.dmarkman@mac.com> <441B4182.8010407@willicon.de> <92CD0D6C-5BE8-426E-A46D-99452059FF49@mac.com> <441BBB2D.8030305@willicon.de> <441C4088.5090905@willicon.de> <64BC1E23-FDDE-4CE6-8863-CFC881CBC224@mac.com> Message-ID: it's in the commapi-0-0-1 branch I tested it right now: cvs co -r commapi-0-0-1 rxtx-devel and I got everything On Mar 20, 2006, at 9:25 AM, Trent Jarvi wrote: > On Mon, 20 Mar 2006, Dr. Douglas Lyon wrote: > >> Hi Trent, >> Thanks for the info on the CVS checkout procedure. >> I did that and am still not sure where the installer is. > > Hi Doug > > It does look like it was not cvs committed. There is no rxtx-devel/ > contrib/MacOSX directory in there at the moment. It was mentioned > that it was put under contrib. > > -- > Trent Jarvi > tjarvi at qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx Dmitry Markman From tjarvi at qbang.org Mon Mar 20 07:52:57 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 20 Mar 2006 07:52:57 -0700 (MST) Subject: [Rxtx] Mac OS X RXTX java installer In-Reply-To: References: <07D0DE29-BA32-4CFE-B036-66BC6423D385@buechse.de> <441AE3E0.2030503@willicon.de> <12531986.1142622114996.JavaMail.dmarkman@mac.com> <441B2674.9010409@willicon.de> <13577405.1142634732776.JavaMail.dmarkman@mac.com> <441B4182.8010407@willicon.de> <92CD0D6C-5BE8-426E-A46D-99452059FF49@mac.com> <441BBB2D.8030305@willicon.de> <441C4088.5090905@willicon.de> <64BC1E23-FDDE-4CE6-8863-CFC881CBC224@mac.com> Message-ID: On Mon, 20 Mar 2006, Dmitry Markman wrote: > it's in the commapi-0-0-1 branch > > I tested it right now: > cvs co -r commapi-0-0-1 rxtx-devel > > and I got everything > A fresh checkout worked. Here is a copy of the tree (just the installer bits) ftp://ftp.qbang.org/pub/rxtx/MacOSX-installer.zip -- Trent Jarvi tjarvi at qbang.org From lyon at docjava.com Mon Mar 20 08:08:26 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Mon, 20 Mar 2006 10:08:26 -0500 Subject: [Rxtx] Mac OS X RXTX java installer In-Reply-To: References: <07D0DE29-BA32-4CFE-B036-66BC6423D385@buechse.de> <441AE3E0.2030503@willicon.de> <12531986.1142622114996.JavaMail.dmarkman@mac.com> <441B2674.9010409@willicon.de> <13577405.1142634732776.JavaMail.dmarkman@mac.com> <441B4182.8010407@willicon.de> <92CD0D6C-5BE8-426E-A46D-99452059FF49@mac.com> <441BBB2D.8030305@willicon.de> <441C4088.5090905@willicon.de> <64BC1E23-FDDE-4CE6-8863-CFC881CBC224@mac.com> Message-ID: Hi All, Is the Auth package able to work properly on non Mac OS's? It was not clear from the doc or download. Thanks! - Doug From dmarkman at mac.com Mon Mar 20 08:15:22 2006 From: dmarkman at mac.com (Dmitry Markman) Date: Mon, 20 Mar 2006 10:15:22 -0500 Subject: [Rxtx] Mac OS X RXTX java installer In-Reply-To: References: <07D0DE29-BA32-4CFE-B036-66BC6423D385@buechse.de> <441AE3E0.2030503@willicon.de> <12531986.1142622114996.JavaMail.dmarkman@mac.com> <441B2674.9010409@willicon.de> <13577405.1142634732776.JavaMail.dmarkman@mac.com> <441B4182.8010407@willicon.de> <92CD0D6C-5BE8-426E-A46D-99452059FF49@mac.com> <441BBB2D.8030305@willicon.de> <441C4088.5090905@willicon.de> <64BC1E23-FDDE-4CE6-8863-CFC881CBC224@mac.com> Message-ID: <217312D8-CCCA-4859-ABA6-32DF1CC817B9@mac.com> thanks Trent, for putting it on ftp server On Mar 20, 2006, at 9:52 AM, Trent Jarvi wrote: > A fresh checkout worked. Here is a copy of the tree (just the > installer bits) > > ftp://ftp.qbang.org/pub/rxtx/MacOSX-installer.zip > Dmitry Markman From dmarkman at mac.com Mon Mar 20 09:14:03 2006 From: dmarkman at mac.com (Dmitry Markman) Date: Mon, 20 Mar 2006 11:14:03 -0500 Subject: [Rxtx] Mac OS X RXTX java installer In-Reply-To: References: <07D0DE29-BA32-4CFE-B036-66BC6423D385@buechse.de> <441AE3E0.2030503@willicon.de> <12531986.1142622114996.JavaMail.dmarkman@mac.com> <441B2674.9010409@willicon.de> <13577405.1142634732776.JavaMail.dmarkman@mac.com> <441B4182.8010407@willicon.de> <92CD0D6C-5BE8-426E-A46D-99452059FF49@mac.com> <441BBB2D.8030305@willicon.de> <441C4088.5090905@willicon.de> <64BC1E23-FDDE-4CE6-8863-CFC881CBC224@mac.com> Message-ID: <4DEBA6F0-DA45-4E84-823E-1F1AC48BDCCC@mac.com> no it will work only on mac os x however it's harmless to run it on other platform if you want to use it for other platform you have to do the following (I'll do it for linux) 1. modify RXTXInstaller class method public static RXTXInstaller getInstance() public static RXTXInstaller getInstance() { String osName = System.getProperty("os.name").toLowerCase(); if(osName.startsWith("mac")){ return new gnu.io.installer.macosx.MACOSXRXTXInstaller(); } else if(osName.startsWith("windows")){ return new gnu.io.installer.windows.WindowsRXTXInstaller(); }else if(osName.startsWith("linux")){ return new gnu.io.installer.linux.LinuxRXTXInstaller(); } return null; } 2. create folder gnu/io/installer/linux/ 3. create class Linux386RXTXInstaller package gnu.io.installer.linux; import java.io.File; public class Linux386RXTXInstaller extends gnu.io.installer.RXTXInstaller{ public Linux386RXTXInstaller(){ createJarFolder(); createLibFolder(); addJarResource("RXTXcomm.jar","/gnu/io/installer/resources/ linux/jar/RXTXcomm.dat"); addLibResource("librxtxSerial.so","/gnu/io/installer/ resources/linux/lib/librxtxSerial.so"); } protected void createJarFolder(){ String javaHome = System.getProperty("java.home"); char separator = File.separatorChar; jarFolder = new File(javaHome+separator+"lib"+separator+"ext"); } protected void createLibFolder(){ String javaHome = System.getProperty("java.home"); char separator = File.separatorChar; libFolder = new File(javaHome+separator+"bin"); } public void runPreProcess() {} //put here some action you need public void runPostProcess() {} //put here some action you need } 4. create folder /gnu/io/installer/resources/linux/jar and put there linux's version of RXTXcomm.dat (which is renamed RXTXcomm.jar) 5. create folder /gnu/io/installer/resources/linux/lib and put there linux's version of librxtxSerial. so 6. make sure that RXTXInstaller.jar has the following items: /gnu/io/installer/resources/linux/jar/RXTXcomm.jar /gnu/io/installer/resources/linux/lib/librxtxSerial.so 7. modify file installer.pref: jar file RXTXInstaller.jar must have the following item /gnu/io/installer/installer.pref that's basically it for windows you have to do the similar things: just replace linux to windows and librxtxSerial.so to rxtxSerial.dll and create appropriate gnu.io.installer.windows.WindowsRXTXInstaller class package gnu.io.installer.windows; import java.io.File; public class WindowsRXTXInstaller extends gnu.io.installer.RXTXInstaller{ public WindowsRXTXInstaller(){ createJarFolder(); createLibFolder(); addJarResource("RXTXcomm.jar","/gnu/io/installer/resources/ windows/jar/RXTXcomm.dat"); addLibResource("librxtxSerial.so","/gnu/io/installer/ resources/windows/lib/rxtxSerial.dll"); } protected void createJarFolder(){ String javaHome = System.getProperty("java.home"); char separator = File.separatorChar; jarFolder = new File(javaHome+separator+"lib"+separator+"ext"); } protected void createLibFolder(){ String javaHome = System.getProperty("java.home"); char separator = File.separatorChar; libFolder = new File(javaHome+separator+"bin"); } public void runPreProcess() {} //put here some action you need public void runPostProcess() {} //put here some action you need } installer.pref will look like On Mar 20, 2006, at 10:08 AM, Dr. Douglas Lyon wrote: > Hi All, > Is the Auth package able to work properly on > non Mac OS's? > It was not clear from the doc or download. > > Thanks! > - Doug > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx Dmitry Markman From joachim at buechse.de Mon Mar 20 10:49:06 2006 From: joachim at buechse.de (Joachim Buechse) Date: Mon, 20 Mar 2006 18:49:06 +0100 Subject: [Rxtx] BUG: Lock file stays even if port opening fails Message-ID: This was only tested on MacOSX but looking at the code, it should be true for all systems that use lock_uucp. I am opening a port which can not be opened (dialup port of a telephone paired via bluetooth but currently not reachable). The lock file is created and stays arround, even though the port open failed. After looking a bit through the code (of 2.17), I really wonder if it wouldn't be a good idea to make the "locking" an explicit operation called from the java code. This would certainly simplify the generation of meaningfull exceptions (and java based debugging). Maybe even the handling of "preopened" ports should be in the Java part of the lib (again for java based debugging puposes). That beeing said, I have no idea if this would be possible for the 2.07 implementation. Regards, Joachim From tjarvi at qbang.org Mon Mar 20 11:24:22 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 20 Mar 2006 11:24:22 -0700 (MST) Subject: [Rxtx] BUG: Lock file stays even if port opening fails In-Reply-To: References: Message-ID: On Mon, 20 Mar 2006, Joachim Buechse wrote: > This was only tested on MacOSX but looking at the code, it should be true > for all systems that use lock_uucp. > > I am opening a port which can not be opened (dialup port of a telephone > paired via bluetooth but currently not reachable). The lock file is > created and stays arround, even though the port open failed. > > > After looking a bit through the code (of 2.17), I really wonder if it > wouldn't be a good idea to make the "locking" an explicit operation > called from the java code. This would certainly simplify the generation > of meaningfull exceptions (and java based debugging). > Maybe even the handling of "preopened" ports should be in the Java part > of the lib (again for java based debugging puposes). That beeing said, I > have no idea if this would be possible for the 2.07 implementation. > > Regards, Hi Joachim It should be possible in the 2.0-7 implementation too. The calls to RXTXPort.java would not change. We would just do more there Moving more of that logic into Java would be better as many people don't like to look at C code. There is a liblockdev on most Linux distros that can do most of the C code and would be easier to use. The problem is embeded devices will not have that library. The preopened port code has not been really tested. That was a last minute request in a product cycle. I expect it will be tested this year though. As I recall, some devices really do not like CD raising on open. The preopened ports then allow people to mess around in java without power cycling the devices or losing data. -- Trent Jarvi tjarvi at qbang.org From joachim at buechse.de Mon Mar 20 12:01:08 2006 From: joachim at buechse.de (Joachim Buechse) Date: Mon, 20 Mar 2006 20:01:08 +0100 Subject: [Rxtx] BUG: Lock file stays even if port opening fails In-Reply-To: References: Message-ID: Hi Trent, What is your general feeling about moving code to Java? The last days I have been reading quite a bit of the code and there are several things, that might not work as expected. I'll give you two examples from is_device_locked: if LOCKDIR == /var/spool/locks the directory /var/spool/lock will not be checked. LOCKDIR is not checked for lockfiles with unexpected pefixes While these things have probably never been discovered in production, they are still possibly incorrect implementations. If it was Java code, I would write some unit tests producing the errors that could later be corrected. PS: One could imagine to actually implement the whole lockfile handling in Java using some native routines to get the values required (pid, st_dev, st_rdev, ...). On 20.03.2006, at 19:24, Trent Jarvi wrote: > On Mon, 20 Mar 2006, Joachim Buechse wrote: > >> This was only tested on MacOSX but looking at the code, it should >> be true for all systems that use lock_uucp. >> >> I am opening a port which can not be opened (dialup port of a >> telephone paired via bluetooth but currently not reachable). The >> lock file is created and stays arround, even though the port open >> failed. >> >> >> After looking a bit through the code (of 2.17), I really wonder if >> it wouldn't be a good idea to make the "locking" an explicit >> operation called from the java code. This would certainly simplify >> the generation of meaningfull exceptions (and java based debugging). >> Maybe even the handling of "preopened" ports should be in the Java >> part of the lib (again for java based debugging puposes). That >> beeing said, I have no idea if this would be possible for the 2.07 >> implementation. >> >> Regards, > > Hi Joachim > > It should be possible in the 2.0-7 implementation too. The calls > to RXTXPort.java would not change. We would just do more there > Moving more of that logic into Java would be better as many people > don't like to look at C code. There is a liblockdev on most Linux > distros that can do most of the C code and would be easier to use. > The problem is embeded devices will not have that library. > > The preopened port code has not been really tested. That was a > last minute request in a product cycle. I expect it will be tested > this year though. As I recall, some devices really do not like CD > raising on open. The preopened ports then allow people to mess > around in java without power cycling the devices or losing data. > > -- > Trent Jarvi > tjarvi at qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Mon Mar 20 12:21:02 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 20 Mar 2006 12:21:02 -0700 (MST) Subject: [Rxtx] BUG: Lock file stays even if port opening fails In-Reply-To: References: Message-ID: On Mon, 20 Mar 2006, Joachim Buechse wrote: > Hi Trent, > > What is your general feeling about moving code to Java? The last days I > have been reading quite a bit of the code and there are several things, > that might not work as expected. > > I'll give you two examples from is_device_locked: > > if LOCKDIR == /var/spool/locks the directory /var/spool/lock will not be > checked. > LOCKDIR is not checked for lockfiles with unexpected pefixes > > While these things have probably never been discovered in production, > they are still possibly incorrect implementations. If it was Java code, I > would write some unit tests producing the errors that could later be > corrected. > > PS: One could imagine to actually implement the whole lockfile handling > in Java using some native routines to get the values required (pid, > st_dev, st_rdev, ...). Hi Joachim I like the idea of moving more of the code into java but there are some things to consider. If you break this into multiple JNI calls, the performance will drop considerably during enumeration of ports. We are looking for 256 ports per dev type vs (16? in Sun's 2.0 and fewer types). Its hard to make assumptions. I've seen virtual ports start at /dev/foo100 for instance. It works out to over 7500 ports on Linux if you enable them all. We already trim that back by default. See Linux-all-ports in RXTXCommDriver.java. There are also native libraries that rxtx can link to. If you move too much into Java, linking to 'standard' libraries with distros will break. "configure --enable-liblock=yes" will not be doable. This is probably a favorable way with RedHat, Debian, Suse and others. Thats the right thing to do if there will be rpms, dpkg, .. For those reasons, I think it still make sense to keep it to a minimal ~3 calls to JNI code that we can use for speed and versatility. lock() isLocked(), unlock() perhaps. When I say speed, its more about avoiding crossing the JNI layer multiple times than java vs C performance. With versatility I think liblock is the right way for most but not all (embeded) linux distros. -- Trent Jarvi tjarvi at qbang.org From joachim at buechse.de Mon Mar 20 12:42:04 2006 From: joachim at buechse.de (Joachim Buechse) Date: Mon, 20 Mar 2006 20:42:04 +0100 Subject: [Rxtx] BUG: Lock file stays even if port opening fails In-Reply-To: References: Message-ID: <82C19FE7-DDCB-45B6-B2C9-7606B66F0124@buechse.de> Ok, what about providing a default implementation in Java? The RXTXCommDriver would call a (native) function useNativeLocking and if it returns true, call the native functions for lock() isLocked (), unlock(), else is would use the Java based default implementation. This could possibly be overriden by a property (again for debugging). Joachim On 20.03.2006, at 20:21, Trent Jarvi wrote: > On Mon, 20 Mar 2006, Joachim Buechse wrote: > >> Hi Trent, >> >> What is your general feeling about moving code to Java? The last >> days I have been reading quite a bit of the code and there are >> several things, that might not work as expected. >> >> I'll give you two examples from is_device_locked: >> >> if LOCKDIR == /var/spool/locks the directory /var/spool/lock will >> not be checked. >> LOCKDIR is not checked for lockfiles with unexpected pefixes >> >> While these things have probably never been discovered in >> production, they are still possibly incorrect implementations. If >> it was Java code, I would write some unit tests producing the >> errors that could later be corrected. >> >> PS: One could imagine to actually implement the whole lockfile >> handling in Java using some native routines to get the values >> required (pid, st_dev, st_rdev, ...). > > Hi Joachim > > I like the idea of moving more of the code into java but there are > some things to consider. > > If you break this into multiple JNI calls, the performance will > drop considerably during enumeration of ports. We are looking for > 256 ports per dev type vs (16? in Sun's 2.0 and fewer types). Its > hard to make assumptions. I've seen virtual ports start at /dev/ > foo100 for instance. > > It works out to over 7500 ports on Linux if you enable them all. > We already trim that back by default. See Linux-all-ports in > RXTXCommDriver.java. > > There are also native libraries that rxtx can link to. If you move > too much into Java, linking to 'standard' libraries with distros > will break. "configure --enable-liblock=yes" will not be doable. > This is probably a favorable way with RedHat, Debian, Suse and > others. Thats the right thing to do if there will be rpms, dpkg, .. > > For those reasons, I think it still make sense to keep it to a > minimal ~3 calls to JNI code that we can use for speed and > versatility. lock() isLocked(), unlock() perhaps. When I say > speed, its more about avoiding crossing the JNI layer multiple > times than java vs C performance. With versatility I think liblock > is the right way for most but not all (embeded) linux distros. > > -- > Trent Jarvi > tjarvi at qbang.org > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Mon Mar 20 12:44:47 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 20 Mar 2006 12:44:47 -0700 (MST) Subject: [Rxtx] BUG: Lock file stays even if port opening fails In-Reply-To: <82C19FE7-DDCB-45B6-B2C9-7606B66F0124@buechse.de> References: <82C19FE7-DDCB-45B6-B2C9-7606B66F0124@buechse.de> Message-ID: On Mon, 20 Mar 2006, Joachim Buechse wrote: > Ok, what about providing a default implementation in Java? > > The RXTXCommDriver would call a (native) function useNativeLocking and if > it returns true, call the native functions for lock() isLocked(), > unlock(), else is would use the Java based default implementation. This > could possibly be overriden by a property (again for debugging). > Hi Joachim That would be OK with me. -- Trent Jarvi tjarvi at qbang.org From dmarkman at mac.com Mon Mar 20 22:27:45 2006 From: dmarkman at mac.com (Dmitry Markman) Date: Tue, 21 Mar 2006 00:27:45 -0500 Subject: [Rxtx] binaries request Message-ID: <42702213-C222-4937-A585-7CFB17E47608@mac.com> Hi can somebody send me latest linux and windows binaries, please? or where I can find them (I didn't find them in the latest tareball) I gave up with my cygwin: something wrong I have no idea what java doesn't understand /cygwin/c syntax after I changed makefile it did java part but after that gcc 3.4.4 started to complain I set buffer length to 999 lines but I didn't get beginning of the story something wrong with my 1.4.2_09/include/jni.h gcc doesn't like it anyway I gave up thanks in advance Dmitry Markman -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060320/f8cbc57c/attachment-0011.html From tjarvi at qbang.org Mon Mar 20 22:36:48 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 20 Mar 2006 22:36:48 -0700 (MST) Subject: [Rxtx] binaries request In-Reply-To: <42702213-C222-4937-A585-7CFB17E47608@mac.com> References: <42702213-C222-4937-A585-7CFB17E47608@mac.com> Message-ID: On Tue, 21 Mar 2006, Dmitry Markman wrote: > Hi > can somebody send me latest linux and windows binaries, please? > > or where I can find them (I didn't find them in the latest tareball) > > I gave up with my cygwin: something wrong I have no idea what > java doesn't understand /cygwin/c syntax > after I changed makefile it did java part > but after that gcc 3.4.4 started to complain > I set buffer length to 999 lines but I didn't get beginning of the story > something wrong with my 1.4.2_09/include/jni.h gcc doesn't like it > anyway I gave up > > thanks in advance > Hi Dmitry The bins are here: ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7-bins-r2.zip Here are the files in the zip you want. Jar: rxtx-2.1-7-bins-r2/RXTXcomm.jar Windows: rxtx-2.1-7-bins-r2/Windows/i368-mingw32/rxtxSerial.dll Linux (x86) rxtx-2.1-7-bins-r2/Linux/i686-unknown-linux-gnu/librxtxSerial.so There are others in there including Parallel port support but those are the main ones for testing. -- Trent Jarvi tjarvi at qbang.org From dmarkman at mac.com Mon Mar 20 23:05:59 2006 From: dmarkman at mac.com (Dmitry Markman) Date: Tue, 21 Mar 2006 01:05:59 -0500 Subject: [Rxtx] binaries request In-Reply-To: References: <42702213-C222-4937-A585-7CFB17E47608@mac.com> Message-ID: thank you very much but windows's readme says: rxtxSerial.dll had to be recomopiled to link in missing native methods. should I ignore it? or what? thanks again also I understand that I should use mingw not cygwin I'll try to install mingw On Mar 21, 2006, at 12:36 AM, Trent Jarvi wrote: > On Tue, 21 Mar 2006, Dmitry Markman wrote: > >> Hi >> can somebody send me latest linux and windows binaries, please? >> >> or where I can find them (I didn't find them in the latest tareball) >> >> I gave up with my cygwin: something wrong I have no idea what >> java doesn't understand /cygwin/c syntax >> after I changed makefile it did java part >> but after that gcc 3.4.4 started to complain >> I set buffer length to 999 lines but I didn't get beginning of the >> story >> something wrong with my 1.4.2_09/include/jni.h gcc doesn't like it >> anyway I gave up >> >> thanks in advance >> > > Hi Dmitry > > The bins are here: > > ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7-bins-r2.zip > > Here are the files in the zip you want. > > Jar: > > rxtx-2.1-7-bins-r2/RXTXcomm.jar > > Windows: > > rxtx-2.1-7-bins-r2/Windows/i368-mingw32/rxtxSerial.dll > > Linux (x86) > > rxtx-2.1-7-bins-r2/Linux/i686-unknown-linux-gnu/librxtxSerial.so > > There are others in there including Parallel port support but those > are the main ones for testing. > > -- > Trent Jarvi > tjarvi at qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx Dmitry Markman From tjarvi at qbang.org Mon Mar 20 23:20:33 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 20 Mar 2006 23:20:33 -0700 (MST) Subject: [Rxtx] binaries request In-Reply-To: References: <42702213-C222-4937-A585-7CFB17E47608@mac.com> Message-ID: On Tue, 21 Mar 2006, Dmitry Markman wrote: > thank you very much > > but windows's readme says: > rxtxSerial.dll had to be recomopiled to link in missing native methods. > > should I ignore it? or what? > Hi Dmitry That dll should be OK. r2 is the recompile linked to the missing native method. The readme explains why it was recompiled; fuser.o was not linked into the dll in the first release. -- Trent Jarvi tjarvi at qbang.org From ariantristan at yahoo.com Mon Mar 20 23:55:24 2006 From: ariantristan at yahoo.com (Lambok Sianturi) Date: Mon, 20 Mar 2006 22:55:24 -0800 (PST) Subject: [Rxtx] jvm issue Message-ID: <20060321065524.94779.qmail@web50701.mail.yahoo.com> Hi All, This is my first time to join RxTx mailing list. I thank you all for allowing others to sign in in requests help. I use the latest RxTx lib in Fedora 3 with java version 1.4.2_09 b05. And I got this error: # # An unexpected error has been detected by HotSpot Virtual Machine: # # SIGSEGV (0xb) at pc=0x00bf27f3, pid=2633, tid=3086112448 # # Java VM: Java HotSpot(TM) Client VM (1.4.2_09-b05 mixed mode) # Problematic frame: # C [ld-linux.so.2+0xa7f3] # # An error report file with more information is saved as hs_err_pid2633.log # # If you would like to submit a bug report, please visit: # http://java.sun.com/webapps/bugreport/crash.jsp # ./run.sh: line 3: 2633 Aborted /usr/local/java/bin/java -Djava.library.path=/usr/local/java/jre/lib/ -Djsmsengine.debug=true -classpath jsmsengine.jar:smsgateway.jar:classes12.jar:RXTXcomm.jar:. com.api.sms.SMSServer What is the jvm depedency for the latest library? Can I use 1.4.2_09 b05? Thanks in advance. Arian --------------------------------- Yahoo! Mail Use Photomail to share photos without annoying attachments. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060320/83d58dd7/attachment-0011.html From f.frumento at ngi.it Tue Mar 21 00:21:47 2006 From: f.frumento at ngi.it (Fabio Frumento) Date: Tue, 21 Mar 2006 08:21:47 +0100 Subject: [Rxtx] Javadoc on the go Message-ID: <441FA98B.9050701@ngi.it> Hi Trent, sorry for the big delay but my job is running wild, i was out for some time but now i'm back and ready to continue the javadoc for Rxtx. Did you used the last javadoc patch i sent you ? let me know if i have to send it to you again or not. regards Fabio From lyon at docjava.com Tue Mar 21 00:51:18 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Tue, 21 Mar 2006 02:51:18 -0500 Subject: [Rxtx] lock files Message-ID: Hi All, You know, if the use of lock files were under Java control (rather than a build-time decision), it might enable a more unified binary distro. It might also facilitate quick prototyping of non-lock file approaches to resolving serial port contention issues (i.e., mac-like approaches vs. linux approaches, etc.). I realize that this is a radical overhaul of the lock file policy issue. Also, it may harm performance. On the other hand, our benchmarks on JNI overhead for modern processors indicate performance impact should be minimal. Perhaps it is more of an issue with the toybox systems. Suppose there were a class with a reasonable default...someone might write: SerialPortLockPolicy.setPolicy(SerialPortLockPolicy.UNIX_LOCK_FILE); SerialPortLockPolicy.setPolicy(SerialPortLockPolicy.NO_LOCK_CHECKING); SerialPortLockPolicy.setPolicy(SerialPortLockPolicy.MAC_STYLE); Thus, we could have a run-time reconfiguration of the serial port lock policy. A special NO_LOCK version of the binary would no longer be required. Any thoughts on this? Thanks! - Doug From joachim at buechse.de Tue Mar 21 03:09:09 2006 From: joachim at buechse.de (Joachim Buechse) Date: Tue, 21 Mar 2006 11:09:09 +0100 Subject: [Rxtx] lock files In-Reply-To: References: Message-ID: <8E12916A-1B9A-4FF2-B684-E2D1C794221B@buechse.de> This is pretty much what I thought about when I suggested, that the default behaviour could be overwritten with a property. I am very much in favor of this approach. In particular this allows much easier debugging for PC based java developers. I think big parts of the Java (and maybe some parts of the C code) could use a bit of a structural workover (unit tests, javadoc, synchronization, etc). Maybe there should be a CVS branch for this experimental version. I'd be happy to contribute a first workover for some of the Java code. Designing for testability and implementing a good bunch of unit tests has been a strategy that worked quite well in the Java projects I lead. And it ultimately allows more liberal change permission. Regards, Joachim On 21.03.2006, at 08:51, Dr. Douglas Lyon wrote: > Hi All, > You know, if the use of lock files were > under Java control (rather than a build-time decision), > it might enable a more unified binary distro. It might also > facilitate quick prototyping of non-lock file approaches > to resolving serial port contention issues (i.e., mac-like > approaches vs. linux approaches, etc.). > > I realize that this is a radical overhaul of the lock file policy > issue. Also, it may harm performance. On the other hand, > our benchmarks on JNI overhead for modern processors indicate > performance impact should be minimal. Perhaps it is more of > an issue with the toybox systems. > > Suppose there were a class with a reasonable default...someone > might write: > SerialPortLockPolicy.setPolicy(SerialPortLockPolicy.UNIX_LOCK_FILE); > SerialPortLockPolicy.setPolicy(SerialPortLockPolicy.NO_LOCK_CHECKING); > SerialPortLockPolicy.setPolicy(SerialPortLockPolicy.MAC_STYLE); > > Thus, we could have a run-time reconfiguration of the serial port lock > policy. A special NO_LOCK version of the binary would no longer > be required. > > Any thoughts on this? > > Thanks! > - Doug > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From joachim at buechse.de Tue Mar 21 06:23:08 2006 From: joachim at buechse.de (Joachim Buechse) Date: Tue, 21 Mar 2006 14:23:08 +0100 Subject: [Rxtx] PATCH: use of ioctl(fd, TIOCEXCL) instead of lockfiles Message-ID: <923AE774-EEA2-4911-92D8-32BB27802C8B@buechse.de> Here is the patch for the ioctl(fd, TIOCEXCL). I have verified this only for OSX 10.4.5, hence it is only defined for APPLE. However, it should work at least for Solaris as well. If a process has requested TIOEXCL further open calls by other user processes will fail. The patch also disables uucp style locking for APPLE. Obviously this is discussable. I think it is the way to go, as it eliminates creating the lock directory which doesnt exist on the standard installation and it eliminates messing with the system group definitions (adding users to group uucp). Regarding the possibility of root processes opening a device which is locked - I consider this a feature not a potential problem. It is highly unlikely, that somebody is crazy enough to run a JavaVM as root (unless he has no other means of getting a restricted IP port opened, ie doesnt understand ipfw). Anyway, even if the process runs as root, it fails when calling ioctl(fd, TIOCEXCL). It could however still open the port to listen for RING events. I.e. a fax server which needs to see incoming calls but otherwise doesnt want to block the port. So the only case where the proposed mechanism fails is, if an incorrectly implemented process running as root conflicts with a user process. I think this can be accepted. Regards, Joachim PS: If this patch is generally accepted, the installer and Mac doku should obviously be changed as well. Index: SerialImp.c =================================================================== RCS file: /usr/local/cvsroot/rxtx-devel/src/SerialImp.c,v retrieving revision 1.46.2.187 diff -u -r1.46.2.187 SerialImp.c --- SerialImp.c 29 Jan 2006 22:19:04 -0000 1.46.2.187 +++ SerialImp.c 21 Mar 2006 12:59:16 -0000 @@ -656,6 +656,25 @@ fd=OPEN (filename, O_RDWR | O_NOCTTY | O_NONBLOCK ); } while (fd < 0 && errno==EINTR); +#ifdef OPEN_EXCL + // Note that open() follows POSIX semantics: multiple open() calls to + // the same file will succeed unless the TIOCEXCL ioctl is issued. + // This will prevent additional opens except by root-owned processes. + // See tty(4) ("man 4 tty") and ioctl(2) ("man 2 ioctl") for details. + + if (fd >= 0 && (ioctl(fd, TIOCEXCL) == -1)) + { + sprintf( message, "open: exclusive access denied for % s\n", + filename ); + report( message ); + report_error( message ); + + close(fd); + goto fail; + } +#endif /* OPEN_EXCL */ + + if( configure_port( fd ) ) goto fail; (*env)->ReleaseStringUTFChars( env, jstr, filename ); sprintf( message, "open: fd returned is %i\n", fd ); Index: SerialImp.h =================================================================== RCS file: /usr/local/cvsroot/rxtx-devel/src/SerialImp.h,v retrieving revision 1.11.2.49 diff -u -r1.11.2.49 SerialImp.h --- SerialImp.h 5 Jul 2005 17:47:21 -0000 1.11.2.49 +++ SerialImp.h 21 Mar 2006 12:59:17 -0000 @@ -135,7 +135,8 @@ /*# define LOCKDIR "/var/spool/uucp"*/ # define LOCKDIR "/var/lock" # define LOCKFILEPREFIX "LK." -# define UUCP +/*# define UUCP*/ +# define OPEN_EXCL #endif /* __APPLE__ */ #if defined(__NetBSD__) # define DEVICEDIR "/dev/" From tjarvi at qbang.org Tue Mar 21 10:26:08 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 21 Mar 2006 10:26:08 -0700 (MST) Subject: [Rxtx] Javadoc on the go In-Reply-To: <441FA98B.9050701@ngi.it> References: <441FA98B.9050701@ngi.it> Message-ID: On Tue, 21 Mar 2006, Fabio Frumento wrote: > Hi Trent, > > sorry for the big delay but my job is running wild, i was out for some > time but now i'm back and ready to continue the javadoc for Rxtx. > > Did you used the last javadoc patch i sent you ? let me know if i have to > send it to you again or not. > > regards > > Fabio Hi Fabio The patch is in the rxtx mail-list archives. It will be going in soon. I did not see a time critical portion. I'll probably be going through the list since the last batch of patches this weekend and putting them into CVS. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Tue Mar 21 10:57:18 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 21 Mar 2006 10:57:18 -0700 (MST) Subject: [Rxtx] jvm issue In-Reply-To: <20060321065524.94779.qmail@web50701.mail.yahoo.com> References: <20060321065524.94779.qmail@web50701.mail.yahoo.com> Message-ID: On Mon, 20 Mar 2006, Lambok Sianturi wrote: > Hi All, > This is my first time to join RxTx mailing list. I thank you all for allowing others to sign in in requests help. > I use the latest RxTx lib in Fedora 3 with java version 1.4.2_09 b05. And I got this error: > > # > # An unexpected error has been detected by HotSpot Virtual Machine: > # > # SIGSEGV (0xb) at pc=0x00bf27f3, pid=2633, tid=3086112448 > # > # Java VM: Java HotSpot(TM) Client VM (1.4.2_09-b05 mixed mode) > # Problematic frame: > # C [ld-linux.so.2+0xa7f3] A native library loading error? What happens if you recompile rxtx on your system and install that? This sounds like an ABI problem? rxtx 2.1-7 was compiled with a gcc 2.96 toolchain as I recall. The hope is newer system will be backwards compatible. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Tue Mar 21 11:05:29 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 21 Mar 2006 11:05:29 -0700 (MST) Subject: [Rxtx] PATCH: use of ioctl(fd, TIOCEXCL) instead of lockfiles In-Reply-To: <923AE774-EEA2-4911-92D8-32BB27802C8B@buechse.de> References: <923AE774-EEA2-4911-92D8-32BB27802C8B@buechse.de> Message-ID: On Tue, 21 Mar 2006, Joachim Buechse wrote: > Here is the patch for the ioctl(fd, TIOCEXCL). I have verified this only > for OSX 10.4.5, hence it is only defined for APPLE. However, it should > work at least for Solaris as well. > > If a process has requested TIOEXCL further open calls by other user > processes will fail. > > The patch also disables uucp style locking for APPLE. Obviously this is > discussable. I think it is the way to go, as it eliminates creating the > lock directory which doesnt exist on the standard installation and it > eliminates messing with the system group definitions (adding users to > group uucp). > > Regarding the possibility of root processes opening a device which is > locked - I consider this a feature not a potential problem. It is highly > unlikely, that somebody is crazy enough to run a JavaVM as root (unless > he has no other means of getting a restricted IP port opened, ie doesnt > understand ipfw). Anyway, even if the process runs as root, it fails when > calling ioctl(fd, TIOCEXCL). It could however still open the port to > listen for RING events. I.e. a fax server which needs to see incoming > calls but otherwise doesnt want to block the port. So the only case where > the proposed mechanism fails is, if an incorrectly implemented process > running as root conflicts with a user process. I think this can be > accepted. > > Regards, > Joachim > > PS: If this patch is generally accepted, the installer and Mac doku > should obviously be changed as well. > > > Index: SerialImp.c > =================================================================== > RCS file: /usr/local/cvsroot/rxtx-devel/src/SerialImp.c,v > retrieving revision 1.46.2.187 > diff -u -r1.46.2.187 SerialImp.c > --- SerialImp.c 29 Jan 2006 22:19:04 -0000 1.46.2.187 > +++ SerialImp.c 21 Mar 2006 12:59:16 -0000 > @@ -656,6 +656,25 @@ > fd=OPEN (filename, O_RDWR | O_NOCTTY | O_NONBLOCK ); > } while (fd < 0 && errno==EINTR); > > +#ifdef OPEN_EXCL > + // Note that open() follows POSIX semantics: multiple open() > calls to > + // the same file will succeed unless the TIOCEXCL ioctl is > issued. > + // This will prevent additional opens except by root-owned > processes. > + // See tty(4) ("man 4 tty") and ioctl(2) ("man 2 ioctl") for > details. > + > + if (fd >= 0 && (ioctl(fd, TIOCEXCL) == -1)) > + { > + sprintf( message, "open: exclusive access denied for % > s\n", > + filename ); > + report( message ); > + report_error( message ); > + > + close(fd); > + goto fail; > + } > +#endif /* OPEN_EXCL */ > + > + > if( configure_port( fd ) ) goto fail; > (*env)->ReleaseStringUTFChars( env, jstr, filename ); > sprintf( message, "open: fd returned is %i\n", fd ); > Index: SerialImp.h > =================================================================== > RCS file: /usr/local/cvsroot/rxtx-devel/src/SerialImp.h,v > retrieving revision 1.11.2.49 > diff -u -r1.11.2.49 SerialImp.h > --- SerialImp.h 5 Jul 2005 17:47:21 -0000 1.11.2.49 > +++ SerialImp.h 21 Mar 2006 12:59:17 -0000 > @@ -135,7 +135,8 @@ > /*# define LOCKDIR "/var/spool/uucp"*/ > # define LOCKDIR "/var/lock" > # define LOCKFILEPREFIX "LK." > -# define UUCP > +/*# define UUCP*/ > +# define OPEN_EXCL > #endif /* __APPLE__ */ > #if defined(__NetBSD__) > # define DEVICEDIR "/dev/" > This looks like a good start. What do you think Dmitry? Perhaps all systems with TIOCEXCL defined should use that though. Even if they use lockfiles. It wont hurt anything. That would catch people hacking their own serial apps without checking lockfiles. Its a good idea to avoid C++ style comments in the C portions. Some older systems don't deal with them well. If it's just for Mac OS X, it isn't a big deal. I think it was the Irix compiler that was problematic? -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Tue Mar 21 11:22:05 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 21 Mar 2006 11:22:05 -0700 (MST) Subject: [Rxtx] lock files In-Reply-To: <8E12916A-1B9A-4FF2-B684-E2D1C794221B@buechse.de> References: <8E12916A-1B9A-4FF2-B684-E2D1C794221B@buechse.de> Message-ID: We can try it. Maybe the JNI is much improved. The nice thing about linking into liblock is distros then worry about lockfiles on their systems. This way, we have to deal with any changes that may show up. On Tue, 21 Mar 2006, Joachim Buechse wrote: > This is pretty much what I thought about when I suggested, that the > default behaviour could be overwritten with a property. I am very much in > favor of this approach. In particular this allows much easier debugging > for PC based java developers. > > I think big parts of the Java (and maybe some parts of the C code) could > use a bit of a structural workover (unit tests, javadoc, synchronization, > etc). Maybe there should be a CVS branch for this experimental version. > I'd be happy to contribute a first workover for some of the Java code. > Designing for testability and implementing a good bunch of unit tests has > been a strategy that worked quite well in the Java projects I lead. And > it ultimately allows more liberal change permission. > > Regards, > Joachim > > > On 21.03.2006, at 08:51, Dr. Douglas Lyon wrote: > >> Hi All, >> You know, if the use of lock files were >> under Java control (rather than a build-time decision), >> it might enable a more unified binary distro. It might also >> facilitate quick prototyping of non-lock file approaches >> to resolving serial port contention issues (i.e., mac-like >> approaches vs. linux approaches, etc.). >> >> I realize that this is a radical overhaul of the lock file policy >> issue. Also, it may harm performance. On the other hand, >> our benchmarks on JNI overhead for modern processors indicate >> performance impact should be minimal. Perhaps it is more of >> an issue with the toybox systems. >> >> Suppose there were a class with a reasonable default...someone >> might write: >> SerialPortLockPolicy.setPolicy(SerialPortLockPolicy.UNIX_LOCK_FILE); >> SerialPortLockPolicy.setPolicy(SerialPortLockPolicy.NO_LOCK_CHECKING); >> SerialPortLockPolicy.setPolicy(SerialPortLockPolicy.MAC_STYLE); >> >> Thus, we could have a run-time reconfiguration of the serial port lock >> policy. A special NO_LOCK version of the binary would no longer >> be required. >> >> Any thoughts on this? >> >> Thanks! >> - Doug >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From dmarkman at mac.com Tue Mar 21 16:05:17 2006 From: dmarkman at mac.com (Dmitry Markman) Date: Tue, 21 Mar 2006 18:05:17 -0500 Subject: [Rxtx] PATCH: use of ioctl(fd, TIOCEXCL) instead of lockfiles In-Reply-To: References: <923AE774-EEA2-4911-92D8-32BB27802C8B@buechse.de> Message-ID: <512AC70C-BB86-48F2-A83C-023F35C23BAB@mac.com> I think it's cool, but I'd like to have that property implementation when user can choose between locking mechanism about comments: it's easy to change comments to the C style or we can use extensions of the file to cpp so c++ compiler will be used On Mar 21, 2006, at 1:05 PM, Trent Jarvi wrote: > This looks like a good start. What do you think Dmitry? Perhaps > all systems with TIOCEXCL defined should use that though. Even if > they use lockfiles. It wont hurt anything. That would catch > people hacking their own serial apps without checking lockfiles. > > Its a good idea to avoid C++ style comments in the C portions. > Some older systems don't deal with them well. If it's just for Mac > OS X, it isn't a big deal. I think it was the Irix compiler that > was problematic? Dmitry Markman From dmarkman at mac.com Tue Mar 21 16:13:00 2006 From: dmarkman at mac.com (Dmitry Markman) Date: Tue, 21 Mar 2006 18:13:00 -0500 Subject: [Rxtx] PATCH: use of ioctl(fd, TIOCEXCL) instead of lockfiles In-Reply-To: References: <923AE774-EEA2-4911-92D8-32BB27802C8B@buechse.de> Message-ID: I'd like to add that creating locking folder isn't a big deal we never had a problem related to the lock folders, because we always used installer on mac os x from other hand I'm not very much familiar with iotcl locking approach and I'm not sure it's more efficient Joachim wrote "I think it is the way to go, as it eliminates creating the lock directory which doesnt exist on the standard installation and it eliminates messing with the system group definitions (adding users to group uucp)." but I really didn't have any problem with that 1. doesn't exist on the standard installation there are many-many things that don't exist in the standard installation so I don't think that argument is strong enough 2. messing with the system group definitions I don't think we're messing with the group definition mac os x provides very clear way to set up group's members and together with Greg Guerin AuthKit there is no problem to set those definitions so I don't think that argument is strong either but from other hand using iotcl is more promising and is more elegant On Mar 21, 2006, at 1:05 PM, Trent Jarvi wrote: > > This looks like a good start. What do you think Dmitry? Perhaps > all systems with TIOCEXCL defined should use that though. Even if > they use lockfiles. It wont hurt anything. That would catch > people hacking their own serial apps without checking lockfiles. Dmitry Markman From joachim at buechse.de Wed Mar 22 04:46:45 2006 From: joachim at buechse.de (Joachim Buechse) Date: Wed, 22 Mar 2006 12:46:45 +0100 Subject: [Rxtx] PATCH: use of ioctl(fd, TIOCEXCL) instead of lockfiles In-Reply-To: References: <923AE774-EEA2-4911-92D8-32BB27802C8B@buechse.de> Message-ID: Sorry, I was not very clear with my arguments, so I will try again;-) Please, don't take this as an attack against work that has been done. I think the contributions that have been made in the past were made in a good spirit. But I really believe, that the current solution for OSX has many shortcomings and should be changed as soon as possible. lock files --- The /var/lock folder does not exist on the standard OSX installation, however the standard installation includes several applications that use serial ports (i.e. the FAX capability). This indicates, that the lock folder approach will not work well with system components. Applications for OSX will generally try to live in harmony with system components (except for HP print drivers of course). I think RXTX should follow this approach as well. uucp group --- Accessing serial ports is not an admin privileged operation on OSX. Any user (world) has read/write privileges on /dev/tty*. So the system default is to not enforce any group membership to access these ports. The group uucp however is a system group on all unix systems I know. It exists for certain system processes. A non admin user should in general not be a member of this group. Quite arguably no user should ever be a member of this group. Installer --- My general opinion is, that - no Installer should touch user or group data without warning - no Application Installer should touch groups which are not specific to the very application installed - no Installer should ever add regular users to a system group The current installer injects the installing user in the group uucp without warning about this change and without giving the option to "opt out" of this change. This is a potential security risk (but not currently a real one, as OSX contains no folders belonging to group uucp). The current installer does not work for multi user systems. It puts the installing user in the uucp group. However the installing user is not necessarily the user that will use the application. Putting all users that may use a serial port application in the system group uucp seems like a very invasive approach to me. Besides that, newly created users will not automatically be in the group and hence, serial applications will "break" for new users without obvious reasons. Avoiding the lock files will allow self contained applications (i.e. drag&drop installation). In my eyes this is largely preferable over an installer that requests admin privileges. Adding up all these points indicates very strongly, that the lock-file implementation is not the way to go on OSX. Regards, Joachim On 22.03.2006, at 00:13, Dmitry Markman wrote: > I'd like to add that > > creating locking folder isn't a big deal > we never had a problem related to the lock folders, because we > always used installer on mac os x > from other hand I'm not very much familiar with iotcl locking > approach and I'm not sure it's more efficient > > Joachim wrote "I think it is the way to go, as it eliminates > creating the lock directory which doesnt exist on the standard > installation and it eliminates messing with the system group > definitions (adding users to group uucp)." but I really didn't have > any problem with that > > 1. doesn't exist on the standard installation > there are many-many things that don't exist in the standard > installation so I don't think that argument is strong enough > 2. messing with the system group definitions > I don't think we're messing with the group definition > mac os x provides very clear way to set up group's members and > together with Greg Guerin AuthKit there is no problem to set those > definitions > so I don't think that argument is strong either > but from other hand using iotcl is more promising and is more elegant > > > > On Mar 21, 2006, at 1:05 PM, Trent Jarvi wrote: > >> >> This looks like a good start. What do you think Dmitry? Perhaps >> all systems with TIOCEXCL defined should use that though. Even if >> they use lockfiles. It wont hurt anything. That would catch >> people hacking their own serial apps without checking lockfiles. > > Dmitry Markman > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From dmarkman at mac.com Wed Mar 22 05:27:13 2006 From: dmarkman at mac.com (Dmitry Markman) Date: Wed, 22 Mar 2006 07:27:13 -0500 Subject: [Rxtx] PATCH: use of ioctl(fd, TIOCEXCL) instead of lockfiles In-Reply-To: References: <923AE774-EEA2-4911-92D8-32BB27802C8B@buechse.de> Message-ID: <83440CF3-DCD8-41C1-B941-F227232C27E3@mac.com> thanks for the very good explanation I didn't think that you were attacking any thing, so don't worry I just had feeling, that there were more aesthetic reasons for going to ioctl then real necessity now you explained everything quite well (BTW, asfar as I remember installer asks admin password so it wasn't quiet, but it really doesn't matter now) thanks On Mar 22, 2006, at 6:46 AM, Joachim Buechse wrote: > Sorry, I was not very clear with my arguments, so I will try again;-) > > Please, don't take this as an attack against work that has been > done. I think the contributions that have been made in the past > were made in a good spirit. But I really believe, that the current > solution for OSX has many shortcomings and should be changed as > soon as possible. > > lock files > --- > The /var/lock folder does not exist on the standard OSX > installation, however the standard installation includes several > applications that use serial ports (i.e. the FAX capability). This > indicates, that the lock folder approach will not work well with > system components. Applications for OSX will generally try to live > in harmony with system components (except for HP print drivers of > course). I think RXTX should follow this approach as well. > > uucp group > --- > Accessing serial ports is not an admin privileged operation on OSX. > Any user (world) has read/write privileges on /dev/tty*. So the > system default is to not enforce any group membership to access > these ports. The group uucp however is a system group on all unix > systems I know. It exists for certain system processes. A non admin > user should in general not be a member of this group. Quite > arguably no user should ever be a member of this group. > > Installer > --- > My general opinion is, that > - no Installer should touch user or group data without warning > - no Application Installer should touch groups which are not > specific to the very application installed > - no Installer should ever add regular users to a system group > > The current installer injects the installing user in the group uucp > without warning about this change and without giving the option to > "opt out" of this change. This is a potential security risk (but > not currently a real one, as OSX contains no folders belonging to > group uucp). > > The current installer does not work for multi user systems. It puts > the installing user in the uucp group. However the installing user > is not necessarily the user that will use the application. Putting > all users that may use a serial port application in the system > group uucp seems like a very invasive approach to me. Besides that, > newly created users will not automatically be in the group and > hence, serial applications will "break" for new users without > obvious reasons. > > > Avoiding the lock files will allow self contained applications > (i.e. drag&drop installation). In my eyes this is largely > preferable over an installer that requests admin privileges. Adding > up all these points indicates very strongly, that the lock-file > implementation is not the way to go on OSX. > > Regards, > Joachim > > > On 22.03.2006, at 00:13, Dmitry Markman wrote: > >> I'd like to add that >> >> creating locking folder isn't a big deal >> we never had a problem related to the lock folders, because we >> always used installer on mac os x >> from other hand I'm not very much familiar with iotcl locking >> approach and I'm not sure it's more efficient >> >> Joachim wrote "I think it is the way to go, as it eliminates >> creating the lock directory which doesnt exist on the standard >> installation and it eliminates messing with the system group >> definitions (adding users to group uucp)." but I really didn't >> have any problem with that >> >> 1. doesn't exist on the standard installation >> there are many-many things that don't exist in the standard >> installation so I don't think that argument is strong enough >> 2. messing with the system group definitions >> I don't think we're messing with the group definition >> mac os x provides very clear way to set up group's members and >> together with Greg Guerin AuthKit there is no problem to set those >> definitions >> so I don't think that argument is strong either >> but from other hand using iotcl is more promising and is more elegant >> >> >> >> On Mar 21, 2006, at 1:05 PM, Trent Jarvi wrote: >> >>> >>> This looks like a good start. What do you think Dmitry? Perhaps >>> all systems with TIOCEXCL defined should use that though. Even >>> if they use lockfiles. It wont hurt anything. That would catch >>> people hacking their own serial apps without checking lockfiles. >> >> Dmitry Markman >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx Dmitry Markman From lyon at docjava.com Wed Mar 22 06:12:18 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Wed, 22 Mar 2006 08:12:18 -0500 Subject: [Rxtx] sole of a new design pattern Message-ID: Hi All, I have been thinking about how we design the serial port software. I think we need a new design pattern. For lack of a better term, I shall call it: The Parametric Singleton Design Pattern By Douglas A. Lyon ABSTRACT The goal of the singleton design pattern is to make sure that there is one, and only one, instance of a given class. The goal of the parametric singleton design pattern is to make sure that there is one, and only one, instance of a given class with the given parametric values. We parametric singleton design pattern combines the singleton design pattern with a parameter that enables unique creation of instances of a class. These instances are cached. When a user asks for an instance with these parameters, the cache is checked. If the instance is in the cache, the instance is returned, otherwise it is created, added to the cache and then returned. We apply our parametric singleton design pattern to the retrieval of RMI registries bound to a given port. The goal of our system is to make sure that no two RMI registries are listening to the same socket and to make use of the RMI registries after they have been created. RMI registries are used in distributed computation. Introduction The singleton design pattern is meant to ensure that on a single instance of a class exists. It is also meant to provide a global point of access to it. The intent of the parametric singleton design pattern is to ensure that a class has only one instance for a given set of parameter values. It also provides a global point of access to it. Motivation A system cannot tolerate multiple instances of some classes with identical parameters. For example, you cannot have two instances making use of the same serial port, at the same time. You cannot have two instances that are trying to listen to the same socket connection. You cannot have two instances writing to the same file structure at the same time. As the operating system is often thought of as the arbiter of consumed resources (i.e., tape drives, serial ports, etc.) we frequently leave it to an operating system implementation to resolve these contention issues. Even for similar resources (like serial ports) there are few standards for handling contention. For example, serial ports on Linux are locked using a "/var/lock" file. POSIX, on the other hand, uses ioctl mechanisms to prevent contention. A better solution is to make a class that is responsible for keeping track of the instances created from the class. The class is declared final, so that it cannot be subclassed. The class also has a private constructor, so that other classes cannot instance it. The new design pattern is called the parametric singleton design pattern and it provides a way to access and create instances with given parameters. Applicability Use the Parametric Singleton Design Pattern when: 1. There must be exactly one instance of a class with the given parameters. 2. The instances must be accessible to clients from a well-known access point. Structure Insert UML diagram here. Participants The Parametric Singleton Clients that need instances 1. The Parametric Singleton defines an instance upon request from a client, if, and only if, the instance does not already exist. 2. The Parametric Singleton returns the instance to the client. 3. The Parametric Singleton is responsible for creating unique instances from given parameters. Collaborations Clients obtain a reference to a Parametric Singleton instance only through the parametric singleton design pattern. If the instance is left in an improper state (e.g., the serial port was left open) it is NOT the role of the Parametric Singleton Design Pattern to close the IO port. Nor is it the role of the Parametric Singleton Design Pattern to open the port. That role is delegate to some other part of the system. Further, it is not the role of the Parametric Singleton Design Pattern to check out resources. That is, multiple threads can have multiple references to the same resource at the same time. MUTEX locking is delegated to some other part of the system. Consequences The Parametric Singleton Design Pattern has several benefits: 1. Controlled access to parametrically defined instances. Since the Parametric Singleton class encapsulates its instances, there is control over how and when clients access it. 2. Reduced name space. The Parametric Singleton pattern avoids global variables that store instances created from the same parameter. Implementation Here are implementation issues to consider when using the Parametric Singleton pattern: 1. Unique mapping of parameters. The Parametric Singleton pattern requires that there be a mean to isomorphically map the parameter space into the instance space and back again. 2. Ensure unique instances. The Parametric Singleton pattern makes unique instances from parameters, and it does so only once. 3. Cache instances for fast retrieval. The Parametric Singleton pattern must be able to look up instances, given some set of parameters, and do so from some data structure. That is, there must be enough space to hold references to all the instances the program will need. Also, a mechanism is needed to look up and retrieve the instances quickly enough to satisfy the clients. Sample Code public final class ParametricSingletonRmiRegistry { private static Hashtable registry = new Hashtable(100); // use singleton pattern and??????????????????????????????????????????????? // prevent instantiation of RmiRegistryUtils.?????????????????????????????? private ParametricSingletonRmiRegistry() { } // the only instance of the Registry held by the RmiRegistryUtils?????????? public static void listNames(Integer port) { if (!isInCacheAndRunning(port)) return; Registry r = (Registry) registry.get(port); System.out.println("registry on port: " + port); System.out.println("registry: " + r); System.out.println("names: "); try { print(r.list()); } catch (RemoteException e) { In.message(e); } System.out.println("------------------------"); } /**???????????????????????????????????????????????????????????????????????? * Checks whether a Registry has been started on this host????????????????? * in the specified port.?????????????????????????????????????????????????? * If not, it tries to start one.?????????????????????????????????????????? * when it fails to start a Registry, it exits the program????????????????? * with exit code 1.??????????????????????????????????????????????????????? */ public static void restart(int port) { if (isInCacheAndRunning(port)) return; try { startRegistry(port); } catch (RemoteException e) { In.message(e); } } /**???????????????????????????????????????????????????????????????????????? * @param port????????????????????????????????????????????????????????????? * @return true if registry is in cache and running???????????????????????? */ private static boolean isInCacheAndRunning(Integer port) { if (!isRegistryRunning(port.intValue())) return false; if (!isRegistryInCache(port.intValue())) return false; return true; } /**???????????????????????????????????????????????????????????????????????? * @param port????????????????????????????????????????????????????????????? * @return true if we are able to locate a local registry on port.??????????????????????????????????????????????????????????????????????????? */ private static boolean isRegistryRunning(int port) { try { Registry r = LocateRegistry.getRegistry(port); if (r != null) return true; } catch (RemoteException e) { return false; } return false; } /**???????????????????????????????????????????????????????????????????????? * @param port????????????????????????????????????????????????????????????? * @return return true if registry is in cache????????????????????????????? */ private static boolean isRegistryInCache(int port) { if (registry.get(new Integer(port)) == null) return false; return true; } /**???????????????????????????????????????????????????????????????????????? * Restart the registry, if needed.???????????????????????????????????????? * Return the only instance of the registry for consistent global?????????? * using by making use of the Singleton Design Pattern????????????????????? *????????????????????????????????????????????????????????????????????????? * @return the internally held registry instance.?????????????????????????? */ public static Registry getRegistry(Integer port) { restart(port); return (Registry) registry.get(port); } private static void startRegistry(Integer port) throws RemoteException { Registry r; try { r = LocateRegistry.createRegistry(port.intValue()); registry.put(port, r); //r = new sun.rmi.registry.RegistryImpl???????????????????????????? /// (port.intValue());?????????????????????????????????????? // registry.put(port, r);?????????????????????????????????????????? } catch (Exception e) { //e.printStackTrace();????????????????????????????????????????????? r = LocateRegistry.getRegistry(port.intValue()); registry.put(port, r); } } public static void main(String args[]) throws RemoteException { //restart(port);??????????????????????????????????????????????????????? restart(5001); restart(5002); restart(5002); Registry r = LocateRegistry.getRegistry(5002); System.out.println("registry="+r); } } I would very much like to get your feedback on this new design pattern idea. Thank you for your time. Regards, - Doug From david.garnier at trusted-logic.com Wed Mar 22 07:36:10 2006 From: david.garnier at trusted-logic.com (David Garnier) Date: Wed, 22 Mar 2006 15:36:10 +0100 Subject: [Rxtx] sole of a new design pattern In-Reply-To: References: Message-ID: <442160DA.80107@trusted-logic.com> Hello, > The Parametric Singleton Design Pattern The Singleton is the most abused design pattern ever. Good use-cases for this pattern are extremely rare and mostly confined to problems related to hardware resources, like serial ports. > Applicability > > Use the Parametric Singleton Design Pattern when: > 1. There must be exactly one instance of a class with the given > parameters. OK. As I said above, this case this actually very unusual. The Singleton pattern is mostly used when : > 2. The instances must be accessible to clients from a well-known > access point. Using the singleton pattern in this case is just convenient for the programmer. Problems arises pretty quickly, especially if you attempt to unit-test your classes. 1) If your singleton is stateful, or hold on to stateful objects, it means that two different unit tests are not actually independent. Instead of starting with a brand new environment, the result of a test may be affected by the result of a previous test. This problem also arise when with your class relies on a database. In both cases, the solution is to reset your "unique" resource (Singleton or database) at the beginning of the test, which is a pain. Also, while most projects connect to a single database, projects that allow the use of Singletons usually contain several of thems, and new ones may cropped up unnoticed. You quickly end up with test cases that only pass in a certain order, which is a royal pain. 2) You cannot mockup a singleton. Once everyone calls the SomeSingleton class statically, you can't replace your class by SomeSingletonMockup. Furthermore, even for hardware services, the Singleton pattern does not really prevent concurrent accesses. If you start the same program in two different JVMs, unless they somehow shared the state of their "Singletons" (through lock files for example), the Singleton pattern will not prevent concurrent access. Our application uses RXTX, and we routinely encounter cases where another (native) application has already locked the port. Since we cannot modify the native application to recognize lock files, OS-level control is irreplaceable. > > Consequences > The Parametric Singleton Design Pattern has several benefits: > > 1. Controlled access to parametrically defined instances. Since > the Parametric Singleton class encapsulates its instances, there is > control over how and when clients access it. Not really. Once you've returned the instance to a client, you've lost control over it. The client can to whatever it wants with it. You cannot "recall" the instance or claim it back. > 2. Reduced name space. The Parametric Singleton pattern avoids > global variables that store instances created from the same parameter. Sure, but you don't have to rely on a Singleton for that. Just create a single Factory. > I would very much like to get your feedback on this new design > pattern idea. Well, it's nothing new. Some may say that it is the point of design patterns: formalizes the designs that occur again and again. However, this design is simply a combination of the Singleton and Factory patterns. I did use it in the past, but now I've been exposed to the shortcomings of the Singleton pattern, so I limit myself to Factories. Regards, David From sean_montgomery at baseview.com Wed Mar 22 08:35:28 2006 From: sean_montgomery at baseview.com (Sean Montgomery) Date: Wed, 22 Mar 2006 10:35:28 -0500 Subject: [Rxtx] sole of a new design pattern In-Reply-To: <442160DA.80107@trusted-logic.com> References: <442160DA.80107@trusted-logic.com> Message-ID: <05769CA7-A51B-4CF0-BAA0-E02DD905F5A4@baseview.com> On Mar 22, 2006, at 9:36 AM, David Garnier wrote: > Furthermore, even for hardware services, the Singleton pattern does > not really prevent concurrent > accesses. If you start the same program in two different JVMs, > unless they somehow shared the state > of their "Singletons" (through lock files for example), the > Singleton pattern will not prevent > concurrent access. > Multiple class loaders in a single JVM can be tricky, too. Then there's synchronization, lazy initialization and serialization of singletons to contend with. Bloch's Effective Java covers these, and here's a few articles: http://www.javaworld.com/javaworld/jw-04-2003/jw-0425-designpatterns- p3.html http://java.sun.com/developer/technicalArticles/Programming/singletons/ Just FYI :-) From lyon at docjava.com Wed Mar 22 08:50:48 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Wed, 22 Mar 2006 10:50:48 -0500 Subject: [Rxtx] sole of a new design pattern In-Reply-To: <442160DA.80107@trusted-logic.com> References: <442160DA.80107@trusted-logic.com> Message-ID: Hi All, First, I would like to thank David for his prompt and thoughtful remarks. I had no idea people that feel strongly about a design patterns! Wow! Feedback (particularly critical feedback) is greatly appreciated. Starting at the end, first: >I did use it in >the past, but now I've been exposed to the shortcomings of the >Singleton pattern, so I limit myself to Factories. David, if I understood your comments correctly, you suggested that Factories can be used in leu of the Singleton Design Pattern, or even the Parametric Singleton Design Pattern. As I see in [Gof]: Factory Method: Intent "Define an interface for creating an object, but let subclasses decide which class to instantiate. Factory Method lets a class defer instantiation to subclasses." The Singleton Design Pattern is a concrete class, which is rather different, right? Also, subclasses are not permitted with Singleton, as they are final. Naturally, I could use an abstract factory as a parent for a singleton. I could even design a facade that could be implemented with the singleton....but that is not the intention of the design. Unless you want a mock-up, as discussed, below: More below: >Hello, > >> The Parametric Singleton Design Pattern > >The Singleton is the most abused design pattern ever. Good use-cases >for this pattern are extremely >rare and mostly confined to problems related to hardware resources, >like serial ports. > > >> Applicability >> >> Use the Parametric Singleton Design Pattern when: >> 1. There must be exactly one instance of a class with the given >> parameters. >OK. As I said above, this case this actually very unusual. The >Singleton pattern is mostly used when : >> 2. The instances must be accessible to clients from a well-known >> access point. > >Using the singleton pattern in this case is just convenient for the >programmer. Problems arises >pretty quickly, especially if you attempt to unit-test your classes. > >1) If your singleton is stateful, or hold on to stateful objects, it >means that two different unit >tests are not actually independent. Instead of starting with a brand >new environment, the result of >a test may be affected by the result of a previous test. This >problem also arise when with your >class relies on a database. In both cases, the solution is to reset >your "unique" resource >(Singleton or database) at the beginning of the test, which is a >pain. Also, while most projects >connect to a single database, projects that allow the use of >Singletons usually contain several of >thems, and new ones may cropped up unnoticed. You quickly end up >with test cases that only pass in a >certain order, which is a royal pain. There are basic problems with communicating finite state machines that include reachability and deadlock analysis. These are addressed with petri net analysis and are beyond the scope of the design pattern. As you quite rightly pointed out; the parametric singleton pattern (or the singleton pattern, for that matter) enable multiple threads to gain access to the same instance. The only way that I can see to block others from gaining access to the reference is the synchronize keyword. This is putting a spin-lock (or MUTEX) on the reference. The question of how to unit-test a design pattern like the parametric singleton remains open. Perhaps this is a deficiency. > >2) You cannot mockup a singleton. Once everyone calls the >SomeSingleton class statically, you can't >replace your class by SomeSingletonMockup. Acutally, I am not sure that this is true. If the Singleton implements a Facade interface, it should be possible to make the replacement. Right? > >Furthermore, even for hardware services, the Singleton pattern does >not really prevent concurrent >accesses. If you start the same program in two different JVMs, >unless they somehow shared the state >of their "Singletons" (through lock files for example), the >Singleton pattern will not prevent >concurrent access. Good Point!! You have sharp eyes! The singleton design pattern should/could take responsibility for this. In fact, you may notice that my code does have an implementation (LocateRegistry) that can work across JVM's. The LocateRegistry will even work across the Internet! LocateRegistry takes both a host name and a Port (lock files just don't do this). I did not think to implement this beyond the local machine, but, in its present form, it will work across different processes. > >Our application uses RXTX, and we routinely encounter cases where >another (native) application has >already locked the port. Since we cannot modify the native >application to recognize lock files, >OS-level control is irreplaceable. The singleton design pattern is not meant to replace OS-level control, but to centralize the Java programmers access to it. If lock files, for example, are used for serial ports, the Singleton Design Pattern should be able to work with them. > > >> >> Consequences >> The Parametric Singleton Design Pattern has several benefits: >> > > 1. Controlled access to parametrically defined instances. Since >> the Parametric Singleton class encapsulates its instances, there is >> control over how and when clients access it. > >Not really. Once you've returned the instance to a client, you've >lost control over it. The client >can to whatever it wants with it. You cannot "recall" the instance >or claim it back. Good point, this should read: > 1. Controll when parametrically defined instances are created. Since > > the Parametric Singleton class encapsulates its instances, there is > > control over how and when they are instanced. > >> 2. Reduced name space. The Parametric Singleton pattern avoids >> global variables that store instances created from the same parameter. > >Sure, but you don't have to rely on a Singleton for that. Just >create a single Factory. > > Thank you for your thoughtful and prompt response! Regards, - Doug From dmarkman at mac.com Wed Mar 22 21:21:55 2006 From: dmarkman at mac.com (Dmitry Markman) Date: Wed, 22 Mar 2006 23:21:55 -0500 Subject: [Rxtx] sole of a new design pattern In-Reply-To: <442160DA.80107@trusted-logic.com> References: <442160DA.80107@trusted-logic.com> Message-ID: I don't think I get it On Mar 22, 2006, at 9:36 AM, David Garnier wrote: > Using the singleton pattern in this case is just convenient for the > programmer. Problems arises > pretty quickly, especially if you attempt to unit-test your classes. so you're saying that something isn't so good because you can not test it in the convenient way? if that's true, I'm totally disagree change your test, debug whatever, but if software is efficient at runtime, works fine and only problem is some unit test (which is some kind of framework for testing) then dump that unit test , dump that unit framework and make something appropriate to the software you're testing so if Douglas want to use singletons, what's the problem? and what do you mean by abusing of singleton usage? of course singleton doesn't prevent concurrent access to the resource across the processes unless you're using some OS facility to prevent it, besides singleton as it was introduced is relevant only and only inside of the same process otherwise it's not singleton it's something else (let's say network singleton: so you have remote invocation facility and some factory method that return object created by that facility) I don't have any problem with using any kind of singletons. Parametric Singleton idea (if I understand it right) could be easily implemented in the following way: use a map populate map with instances of some class and key is your parameter (you can use lazy population too) if somebody ask the key check the value if it's null so resource is taken if somebody returns the resource put it back to the map public synchronized static Object getSomeResource(Object parameter); public synchronized static void returnResource(Object parameter); getSomeResource (inside of the same process) could return null in 2 cases 1. if somebody (from other thread for example) already took that resource 2. if OS API said that resource corresponded to that parameter (serial port with parameter = 1 (port #)) is locked and unavailable; I'm not sure that in case of serial ports we even need those Parametric Singletons (unless lock checking is a very expensive operation) just ask the OS about availability of that resource and if it's available give it away and then OS will lock it and therefore in next time somebody ask it just answer that resource is locked and return null for example system has 2 serial ports available so I ask getResource("tty"); or I ask getResource("Bluetooth-Modem"); and if OS is ok you can give tty or Bluetooth-Modem or both no need for any additional pattern I think back to the problem mac os x doesn't recognize locking via files, so it handles locking via some API an instance of the singleton in each process should recognize that resource is locked (by using that API) that's all we don't have to make things more complicate then they are just because there is some nice design pattern or nice unit test framework or whatever keep things simple, make them work fast, don't introduce middle layers unless you have really good reason to do so of course I could be entirely wrong, so sorry about that in advance thanks Dmitry Markman From tjarvi at qbang.org Wed Mar 22 22:31:41 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 22 Mar 2006 22:31:41 -0700 (MST) Subject: [Rxtx] sole of a new design pattern In-Reply-To: References: Message-ID: Hi Doug Interesting reading. So far I'm just reading and thinking. I have one question so far. " Clients obtain a reference to a Parametric Singleton instance only through the parametric singleton design pattern. If the instance is left in an improper state (e.g., the serial port was left open) it is NOT the role of the Parametric Singleton Design Pattern to close the IO port. Nor is it the role of the Parametric Singleton Design Pattern to open the port. That role is delegate to some other part of the system. " So when the clients obtain a reference to the singleton, can they assume the port is there? IE, would it be the singletons role to handle things like USB dongles being removed with event hints comming from the underlying OS. Hardware abstraction layer/HAL on Linux is an example of underlying OS events. I assume that role too is delegated to other parts of the system? -- Trent Jarvi tjarvi at qbang.org From lyon at docjava.com Thu Mar 23 08:10:33 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Thu, 23 Mar 2006 10:10:33 -0500 Subject: [Rxtx] Classes don't need goals, they need roles! In-Reply-To: References: Message-ID: Hi Trent, Yes, I think that the role of the Parametric Singleton Pattern is not to open or close serial ports, nor is it to perform error checking. On the other hand, if you were to combine the role of the Parametric Singleton Pattern with another role (like that of error checking) it might not be amiss. However, I generally caution programmers against adding multiple roles to classes, as this leads to monolithic designs. Thus a different class (NativeLibDetect) could have the role of determining if the native library can be loaded. Another class (SerialPortBean) can have the role of serializing the default state of the serial port, so that it can be recovered, from user preferences, at a later time. The SerialPortDetect could have the role of determining if the serial port is removed (i.e., a USB port was unplugged). My guess is that each class should have a different role in the system, in order to ease maintenance and testing...but I could be wrong about that. Thanks! - Doug >Hi Doug > >Interesting reading. So far I'm just reading and thinking. I have >one question so far. > >" > Clients obtain a reference to a Parametric Singleton instance only >through the parametric singleton design pattern. If the instance is >left in an improper state (e.g., the serial port was left open) it is >NOT the role of the Parametric Singleton Design Pattern to close the >IO port. Nor is it the role of the Parametric Singleton Design Pattern >to >open the port. That role is delegate to some other part of the system. >" > >So when the clients obtain a reference to the singleton, can they >assume the port is there? IE, would it be the singletons role to >handle things like USB dongles being removed with event hints >comming from the underlying OS. Hardware abstraction layer/HAL on >Linux is an example of underlying OS events. > >I assume that role too is delegated to other parts of the system? > >-- >Trent Jarvi >tjarvi at qbang.org >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From maximulo at yahoo.com Fri Mar 24 01:22:38 2006 From: maximulo at yahoo.com (Maximulo Majir) Date: Fri, 24 Mar 2006 00:22:38 -0800 (PST) Subject: [Rxtx] JavaPOS Message-ID: <20060324082238.66371.qmail@web38214.mail.mud.yahoo.com> Hi all! Hello Trent! From what i understand, RXTX or JavaComm APIs were not created solely for JavaPOS. In JavaPOS, we have the virtual method claim() which is separate from open(), but in our RXTX API, claiming is done every call to open(), we cant open the port if its claimed by another application. Would it be alright to suggest or ask to create a new method called claim(..)? Is there such thing as forceclaim() in RXTX? this could be the same as portownership transfer or its equivalent. ForceClaim is in JSR80. Do you have some samples using RXTX as the lower layer for the Device Service Objects in JavaPOS? I have tried it, i just want to compare. Thank you all! maxim __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060324/496adba2/attachment-0011.html From tjarvi at qbang.org Fri Mar 24 11:28:19 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 24 Mar 2006 11:28:19 -0700 (MST) Subject: [Rxtx] Re: RXTX 2.1 Solaris Problems In-Reply-To: <3691.1143210578@www045.gmx.net> References: <3691.1143210578@www045.gmx.net> Message-ID: On Fri, 24 Mar 2006, Andreas Guenther wrote: > Hi all, > > the solaris problem was not the lock file only. > > Ok, I had to create the directory /var/spool/locks myself. > /var/spool/uucp exists. > > But rxtx didn't find any port. > > I compiled the source with my own debug-informations > and I tried to isolate the problem. > > The problem is the testRead-call in SerialImp.c > > JNIEXPORT jboolean JNICALL RXTXCommDriver(testRead)( > > ... > if ( READ( fd, &c, 1 ) < 0 ) > { > if ( errno != EAGAIN ) { > report( "testRead() read failed\n" ); > ret = JNI_FALSE; > } > } > Thanks Andreas I'm packing up to move. I'll be more or less away for a couple weeks here. I'll be checking email but my workstation is going into a box soon. This isn't hard to fix as this port should be enumerated when EWOULDBLOCK is recieved. Thats error is OK for enumeration just as EAGAIN is. I've put the bug into bugzilla so we dont forget to get to it. http://bugzilla.qbang.org/show_bug.cgi?id=42 You can add yourself to the CC list if you wish to test fixes we provide or even put a patch into bugzilla yourself. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Fri Mar 24 11:51:52 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 24 Mar 2006 11:51:52 -0700 (MST) Subject: [Rxtx] JavaPOS In-Reply-To: <20060324082238.66371.qmail@web38214.mail.mud.yahoo.com> References: <20060324082238.66371.qmail@web38214.mail.mud.yahoo.com> Message-ID: On Fri, 24 Mar 2006, Maximulo Majir wrote: > Hi all! Hello Trent! > > > From what i understand, RXTX or JavaComm APIs were not > created solely for JavaPOS. In JavaPOS, we have the virtual method > claim() which is separate from open(), but in our RXTX API, claiming is > done every call to open(), we cant open the port if its claimed by > another application. Would it be alright to suggest or ask to create a > new method called claim(..)? Is there such thing as forceclaim() in > RXTX? this could be the same as portownership transfer or its > equivalent. ForceClaim is in JSR80. > Do you have some samples using RXTX as the lower layer for the Device > Service Objects in JavaPOS? I have tried it, i just want to compare. > maxim Hi Maxim JSR80 is the USB API IBM/Sun put together. The problem is they have a richer kernel/API underneath that can handle such things. With Serial Ports, there isnt anything there other than an ioctl that says don't let anyone touch this and lockfiles that are more of a 'lets be nice.' At times we may be using USB ports but it is through the termios layer with the limitations mentioned. The advantage is that not only USB will work with rxtx. Anything that has a termios layer should work (to the extent that termios layer is complete). I don't know how forceclaim() would help you. Lets say someone has a programmer working on /dev/ttyS0 and you take it. Now you both race each other to read data first. There isn't a mechanism I know of that will solve this problem in termios. The most obvious test being a native app and a Java app trying to take the port. There is the potential of requestion ownership from other Java Applications but the use for that is very rare. Did you have something more specific in mind that I'm missing? I'm not sure that claim() and forceclaim() would help you with rxtx other than maybe locking the port with claim() without opening it. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sat Mar 25 23:42:08 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 25 Mar 2006 23:42:08 -0700 (MST) Subject: [Rxtx] Serial snoop Message-ID: I was reading the Linux kernel mail-list tonight and ran past a thread that mentioned sersnoop. This looks like a handy tool for people dealing with new toys. "a simple command-line tool for linux that echoes bytes to and from any two serial ports, ptys, or network sockets, and prints all traffic to stdout, in hex and ascii." http://www.restivo.org/projects/sersnoop/ It works on Linux only at this time (debian package available). -- Trent Jarvi tjarvi at qbang.org From beat.arnet at gmail.com Sun Mar 26 07:32:35 2006 From: beat.arnet at gmail.com (Beat Arnet) Date: Sun, 26 Mar 2006 09:32:35 -0500 Subject: [Rxtx] Error 0x5 at /home/bob/foo/tar/rxtx-2.1-7/build/../src/termios.c(860): Access is, denied. Message-ID: <4426A603.80508@gmail.com> Dear all, When trying to open the serial port, I sometimes (not always) run into the following exception (when opening the serialPort): Error 0x5 at /home/bob/foo/tar/rxtx-2.1-7/build/../src/termios.c(860): Access is denied. java.lang.UnsatisfiedLinkError: native_psmisc_report_owner at gnu.io.CommPortIdentifier.native_psmisc_report_owner(Native Method) at gnu.io.CommPortIdentifier.open(CommPortIdentifier.java:354) at codeskin.tools.CLLoader.open(CLLoader.java:79) at codeskin.tools.C2000Programmer.run(C2000Programmer.java:220) at java.lang.Thread.run(Unknown Source) Is this the type of error where I should just try to open the port again, or can it be avoided? Regards, Beat From tjarvi at qbang.org Sun Mar 26 11:40:12 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 26 Mar 2006 11:40:12 -0700 (MST) Subject: [Rxtx] Error 0x5 at /home/bob/foo/tar/rxtx-2.1-7/build/../src/termios.c(860): Access is, denied. In-Reply-To: <4426A603.80508@gmail.com> References: <4426A603.80508@gmail.com> Message-ID: On Sun, 26 Mar 2006, Beat Arnet wrote: > Dear all, > > When trying to open the serial port, I sometimes (not always) run into > the following exception (when opening the serialPort): > > Error 0x5 at /home/bob/foo/tar/rxtx-2.1-7/build/../src/termios.c(860): > Access is > denied. > > java.lang.UnsatisfiedLinkError: native_psmisc_report_owner > at gnu.io.CommPortIdentifier.native_psmisc_report_owner(Native > Method) > at gnu.io.CommPortIdentifier.open(CommPortIdentifier.java:354) > at codeskin.tools.CLLoader.open(CLLoader.java:79) > at codeskin.tools.C2000Programmer.run(C2000Programmer.java:220) > at java.lang.Thread.run(Unknown Source) > > Is this the type of error where I should just try to open the port again, > or can it be avoided? > Hi Beat We did a second build of rxtx 2.1-7 to resolve that unsatisfied link error. It should work now. rxtx is trying to tell you it thinks someone else has the serial port open. You can try to open the port again but maybe you already have a copy of the program running when it happens? ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7r2.zip fixed build. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sun Mar 26 11:44:23 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 26 Mar 2006 11:44:23 -0700 (MST) Subject: [Rxtx] RXTX spec file (fwd) Message-ID: This is probably interesting for fedora/suse users. ---------- Forwarded message ---------- Date: Sun, 26 Mar 2006 16:25:45 +0200 To: taj at www.linux.org.uk Subject: RXTX spec file I send you this spec file which allows to create a RPM for Fedora 4, 5 (x86, x86_64) with Java Sun. -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: rxtx.spec Url: http://mailman.qbang.org/pipermail/rxtx/attachments/20060326/6c7b6af6/rxtx-0007.pl From tjarvi at qbang.org Sun Mar 26 23:42:59 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 26 Mar 2006 23:42:59 -0700 (MST) Subject: [Rxtx] Upcomming events. Message-ID: This Wednesday we will be announcing a new "Maintainer" for the rxtx project. The position is more like neutral leader. I wont be going away or doing less. This is just the right thing to do as it turns out the two people with CVS write access will be at the same company. We need a third and we need neutrality. The maintainer will have final say in any conflict and will try to be neutral. It will be open for discussion. Then we will do it :) I'll still do most of the footwork I do now. But. I'm falling behind. I should have gone through the mail-list and posted the next round of changes this weekend. I'm packing to move and its going so so - 13 years of toys collected. I suspect there will be a dead period on my part (a couple weeks) comming up. But if you get it on the mail-list, we will get it in if there are no objections. I may well not be reading the mail-list during this period as I look for a house and many other things. I hope everyone will help out. Thanks -- Trent Jarvi tjarvi at qbang.org From mahmoud_hadad at yahoo.com Sun Mar 26 07:31:19 2006 From: mahmoud_hadad at yahoo.com (ronan nick) Date: Sun, 26 Mar 2006 06:31:19 -0800 (PST) Subject: [Rxtx] a question about the COMM API Message-ID: <20060326143119.54919.qmail@web60014.mail.yahoo.com> hi, i was intrested in knowing how i can communicate with my internal modem using java? for example if i want to make a phone dialer application or a caller id application where should i be looking at? and as i understood the COMM API is for devices that is attached to the computer through serial ports. --------------------------------- New Yahoo! Messenger with Voice. Call regular phones from your PC and save big. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060326/ce8329f0/attachment-0009.html From dmarkman at mac.com Mon Mar 20 00:20:43 2006 From: dmarkman at mac.com (Dmitry Markman) Date: Mon, 20 Mar 2006 02:20:43 -0500 Subject: [Rxtx] Mac OS X RXTX java installer In-Reply-To: References: <07D0DE29-BA32-4CFE-B036-66BC6423D385@buechse.de> <441AE3E0.2030503@willicon.de> <12531986.1142622114996.JavaMail.dmarkman@mac.com> <441B2674.9010409@willicon.de> <13577405.1142634732776.JavaMail.dmarkman@mac.com> <441B4182.8010407@willicon.de> <92CD0D6C-5BE8-426E-A46D-99452059FF49@mac.com> <441BBB2D.8030305@willicon.de> <441C4088.5090905@willicon.de> Message-ID: <64BC1E23-FDDE-4CE6-8863-CFC881CBC224@mac.com> Hi all I put RXTX installer that will install everything (and will create / var/lock if necessary and add user to the uucp group) for mac os x from Java into the rxtx's CVS repository it could be easily modified to install files for any platform it uses Greg Guerin's AuthKit for authentication and authorization Greg released that kit under artistic license, so Trent, please take a look we, probably, can negotiate license with Greg if it's necessary Greg's AuthKit could be downloaded from http://www.amug.org/~glguerin/ sw/#authkit Michael Hall (mikehall at spacestar dot net) had a suggestion to make implementation of the jaas LoginModule based on Greg's AuthKit (his modification of the Greg's AuthKit could be found at http:// www.spacestar.net/users/mikehall/authkit.dmg) but Michael's AuthKitLoginModule does only half a job: it does authenticate but it can not run any external unix process in privileged mode (at least I wasn't able to do so) possible explanation could be found in conversation between Greg and Michael at Apple's java-dev list (look for archives) so I didn't use jaas API for rxtxinstaller I created folder MacOSX in the contrib folder comment 1. if you want to run that installer as standalone application all you need that RXTXInstaller.jar 2. if you want to use webstart you have to add Greg's libAuthKit.jnilib to the mac os x's resources in theory RXTXInstaller.jar doesn't need it, but there is a problem with loading libAuthKit.jnilib from webstart authkit uses loadLibrary method to load library and it failed (from webstart) for standalone application I extract libAuthKit.jnilib from the RXTXInstaller.jar and put it into the /Library/Java/Extensions or ~/Library/Java/Extensions folder that file will be deleted after installer quit unfortunately I didn't have time to put documentation there but it is mostly self-explanatory I took installer code from my gl4java installer that I did about 3 years ago (with small modifications) it would be very nice if Apple will release LoginModule that really will do the job (com.apple.security.auth.module package????? ) (UnixLoginModule is pretty useless) From lyon at docjava.com Mon Mar 20 06:34:39 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Mon, 20 Mar 2006 08:34:39 -0500 Subject: [Rxtx] Mac OS X RXTX java installer In-Reply-To: <64BC1E23-FDDE-4CE6-8863-CFC881CBC224@mac.com> References: <07D0DE29-BA32-4CFE-B036-66BC6423D385@buechse.de> <441AE3E0.2030503@willicon.de> <12531986.1142622114996.JavaMail.dmarkman@mac.com> <441B2674.9010409@willicon.de> <13577405.1142634732776.JavaMail.dmarkman@mac.com> <441B4182.8010407@willicon.de> <92CD0D6C-5BE8-426E-A46D-99452059FF49@mac.com> <441BBB2D.8030305@willicon.de> <441C4088.5090905@willicon.de> <64BC1E23-FDDE-4CE6-8863-CFC881CBC224@mac.com> Message-ID: Hi Dimitry, This sounds like great work. Just a couple of questions; After the check out of the CVS files, using: setenv CVSROOT :pserver:anonymous at cvs.milestonesolutions.com:/usr/local/cvsroot 53 8:28 setenv PASSWORD mousy 54 8:29 cvs login 55 8:29 cvs checkout rxtx-devel I cd'd over to: rxtx-devel/MACOSX_IDE And found: CVS/ CW/ ForPackageMaker/ PB/ Where is the installer? Thanks! - Doug From tjarvi at qbang.org Mon Mar 20 06:39:37 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 20 Mar 2006 06:39:37 -0700 (MST) Subject: [Rxtx] Mac OS X RXTX java installer In-Reply-To: References: <07D0DE29-BA32-4CFE-B036-66BC6423D385@buechse.de> <441AE3E0.2030503@willicon.de> <12531986.1142622114996.JavaMail.dmarkman@mac.com> <441B2674.9010409@willicon.de> <13577405.1142634732776.JavaMail.dmarkman@mac.com> <441B4182.8010407@willicon.de> <92CD0D6C-5BE8-426E-A46D-99452059FF49@mac.com> <441BBB2D.8030305@willicon.de> <441C4088.5090905@willicon.de> <64BC1E23-FDDE-4CE6-8863-CFC881CBC224@mac.com> Message-ID: On Mon, 20 Mar 2006, Dr. Douglas Lyon wrote: > Hi Dimitry, > This sounds like great work. Just a couple of questions; > After the check out of the CVS files, using: > setenv CVSROOT > :pserver:anonymous at cvs.milestonesolutions.com:/usr/local/cvsroot > 53 8:28 setenv PASSWORD mousy > 54 8:29 cvs login > 55 8:29 cvs checkout rxtx-devel Hi Doug You want "cvs checkout -r commapi-0-0-1 rxtx-devel" to get RXTX 2.1 The default branch is rxtx 2.0 which isn't very active right now. -- Trent Jarvi tjarvi at qbang.org From lyon at docjava.com Mon Mar 20 07:05:44 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Mon, 20 Mar 2006 09:05:44 -0500 Subject: [Rxtx] Mac OS X RXTX java installer In-Reply-To: References: <07D0DE29-BA32-4CFE-B036-66BC6423D385@buechse.de> <441AE3E0.2030503@willicon.de> <12531986.1142622114996.JavaMail.dmarkman@mac.com> <441B2674.9010409@willicon.de> <13577405.1142634732776.JavaMail.dmarkman@mac.com> <441B4182.8010407@willicon.de> <92CD0D6C-5BE8-426E-A46D-99452059FF49@mac.com> <441BBB2D.8030305@willicon.de> <441C4088.5090905@willicon.de> <64BC1E23-FDDE-4CE6-8863-CFC881CBC224@mac.com> Message-ID: Hi Trent, Thanks for the info on the CVS checkout procedure. I did that and am still not sure where the installer is. Here is what I have: cd MACOSX_IDE/ p4.docjava.com{lyon}121: ls CVS/ ForPackageMaker/ PB/ p4.docjava.com{lyon}122: find . | more . ./ForPackageMaker ./ForPackageMaker/RXTX.pkg.sit.hqx ./ForPackageMaker/Resources ./ForPackageMaker/Resources/ReadMe.rtf ./ForPackageMaker/Resources/Welcome.rtf ./ForPackageMaker/Resources/CVS ./ForPackageMaker/Resources/CVS/Entries ./ForPackageMaker/Resources/CVS/Repository ./ForPackageMaker/Resources/CVS/Tag ./ForPackageMaker/Resources/CVS/Root ./ForPackageMaker/Resources/preinstall ./ForPackageMaker/Resources/License.rtf ./ForPackageMaker/Resources/preupgrade ./ForPackageMaker/RXTX.pmsp ./ForPackageMaker/CVS ./ForPackageMaker/CVS/Entries ./ForPackageMaker/CVS/Repository ./ForPackageMaker/CVS/Entries.Log ./ForPackageMaker/CVS/Tag ./ForPackageMaker/CVS/Root ./ForPackageMaker/RXTX_Tiger.pkg.sitx.hqx ./ForPackageMaker/RXTX_Jag.pkg.sit.hqx ./ForPackageMaker/Install ./ForPackageMaker/Install/CVS ./ForPackageMaker/Install/CVS/Entries ./ForPackageMaker/Install/CVS/Repository ./ForPackageMaker/Install/CVS/Tag ./ForPackageMaker/Install/CVS/Root ./ForPackageMaker/Install/Library ./ForPackageMaker/Install/Library/CVS ./ForPackageMaker/Install/Library/CVS/Entries ./ForPackageMaker/Install/Library/CVS/Repository ./ForPackageMaker/Install/Library/CVS/Tag ./ForPackageMaker/Install/Library/CVS/Root ./ForPackageMaker/Install/Library/Java ./ForPackageMaker/Install/Library/Java/Extensions ./ForPackageMaker/Install/Library/Java/Extensions/RXTXcomm.jar ./ForPackageMaker/Install/Library/Java/Extensions/CVS ./ForPackageMaker/Install/Library/Java/Extensions/CVS/Entries ./ForPackageMaker/Install/Library/Java/Extensions/CVS/Repository ./ForPackageMaker/Install/Library/Java/Extensions/CVS/Tag ./ForPackageMaker/Install/Library/Java/Extensions/CVS/Root ./ForPackageMaker/Install/Library/Java/Extensions/librxtxSerial.jnilib ./ForPackageMaker/Install/Library/Java/CVS ./ForPackageMaker/Install/Library/Java/CVS/Entries ./ForPackageMaker/Install/Library/Java/CVS/Repository ./ForPackageMaker/Install/Library/Java/CVS/Entries.Log ./ForPackageMaker/Install/Library/Java/CVS/Tag ./ForPackageMaker/Install/Library/Java/CVS/Root ./ForPackageMaker/RXTX_Tiger.pmproj.sitx.hqx ./CVS ./CVS/Entries ./CVS/Repository ./CVS/Entries.Log ./CVS/Tag ./CVS/Root ./PB ./PB/LibSerialUniversal.xcodeproj.sitx.hqx ./PB/CVS ./PB/CVS/Entries ./PB/CVS/Repository ./PB/CVS/Entries.Log ./PB/CVS/Tag ./PB/CVS/Root ./PB/LibSerial.pbproj.sit.hqx ./PB/startpoint.c ./PB/config.h What is the procedure to run this installer? Do we need a README in: /rxtx-devel/MACOSX_IDE Here is what we have: CVS/ ForPackageMaker/ PB/ Thanks! - DL >On Mon, 20 Mar 2006, Dr. Douglas Lyon wrote: > >>Hi Dimitry, >>This sounds like great work. Just a couple of questions; >>After the check out of the CVS files, using: >>setenv CVSROOT >>:pserver:anonymous at cvs.milestonesolutions.com:/usr/local/cvsroot >> 53 8:28 setenv PASSWORD mousy >> 54 8:29 cvs login >> 55 8:29 cvs checkout rxtx-devel > >Hi Doug > >You want "cvs checkout -r commapi-0-0-1 rxtx-devel" to get RXTX 2.1 >The default branch is rxtx 2.0 which isn't very active right now. > >-- >Trent Jarvi >tjarvi at qbang.org From tjarvi at qbang.org Mon Mar 20 07:25:30 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 20 Mar 2006 07:25:30 -0700 (MST) Subject: [Rxtx] Mac OS X RXTX java installer In-Reply-To: References: <07D0DE29-BA32-4CFE-B036-66BC6423D385@buechse.de> <441AE3E0.2030503@willicon.de> <12531986.1142622114996.JavaMail.dmarkman@mac.com> <441B2674.9010409@willicon.de> <13577405.1142634732776.JavaMail.dmarkman@mac.com> <441B4182.8010407@willicon.de> <92CD0D6C-5BE8-426E-A46D-99452059FF49@mac.com> <441BBB2D.8030305@willicon.de> <441C4088.5090905@willicon.de> <64BC1E23-FDDE-4CE6-8863-CFC881CBC224@mac.com> Message-ID: On Mon, 20 Mar 2006, Dr. Douglas Lyon wrote: > Hi Trent, > Thanks for the info on the CVS checkout procedure. > I did that and am still not sure where the installer is. Hi Doug It does look like it was not cvs committed. There is no rxtx-devel/contrib/MacOSX directory in there at the moment. It was mentioned that it was put under contrib. -- Trent Jarvi tjarvi at qbang.org From dmarkman at mac.com Mon Mar 20 07:29:56 2006 From: dmarkman at mac.com (Dmitry Markman) Date: Mon, 20 Mar 2006 09:29:56 -0500 Subject: [Rxtx] Mac OS X RXTX java installer In-Reply-To: References: <07D0DE29-BA32-4CFE-B036-66BC6423D385@buechse.de> <441AE3E0.2030503@willicon.de> <12531986.1142622114996.JavaMail.dmarkman@mac.com> <441B2674.9010409@willicon.de> <13577405.1142634732776.JavaMail.dmarkman@mac.com> <441B4182.8010407@willicon.de> <92CD0D6C-5BE8-426E-A46D-99452059FF49@mac.com> <441BBB2D.8030305@willicon.de> <441C4088.5090905@willicon.de> <64BC1E23-FDDE-4CE6-8863-CFC881CBC224@mac.com> Message-ID: <6054EB4E-F7E0-4A9C-BDDA-D582D6D8826F@mac.com> you can find it in the rxtx-devel/contrib folder On Mar 20, 2006, at 9:05 AM, Dr. Douglas Lyon wrote: > Hi Trent, > Thanks for the info on the CVS checkout procedure. > I did that and am still not sure where the installer is. > Here is what I have: > cd MACOSX_IDE/ > p4.docjava.com{lyon}121: ls > CVS/ ForPackageMaker/ PB/ > p4.docjava.com{lyon}122: find . | more > . > ./ForPackageMaker > ./ForPackageMaker/RXTX.pkg.sit.hqx > ./ForPackageMaker/Resources > ./ForPackageMaker/Resources/ReadMe.rtf > ./ForPackageMaker/Resources/Welcome.rtf > ./ForPackageMaker/Resources/CVS > ./ForPackageMaker/Resources/CVS/Entries > ./ForPackageMaker/Resources/CVS/Repository > ./ForPackageMaker/Resources/CVS/Tag > ./ForPackageMaker/Resources/CVS/Root > ./ForPackageMaker/Resources/preinstall > ./ForPackageMaker/Resources/License.rtf > ./ForPackageMaker/Resources/preupgrade > ./ForPackageMaker/RXTX.pmsp > ./ForPackageMaker/CVS > ./ForPackageMaker/CVS/Entries > ./ForPackageMaker/CVS/Repository > ./ForPackageMaker/CVS/Entries.Log > ./ForPackageMaker/CVS/Tag > ./ForPackageMaker/CVS/Root > ./ForPackageMaker/RXTX_Tiger.pkg.sitx.hqx > ./ForPackageMaker/RXTX_Jag.pkg.sit.hqx > ./ForPackageMaker/Install > ./ForPackageMaker/Install/CVS > ./ForPackageMaker/Install/CVS/Entries > ./ForPackageMaker/Install/CVS/Repository > ./ForPackageMaker/Install/CVS/Tag > ./ForPackageMaker/Install/CVS/Root > ./ForPackageMaker/Install/Library > ./ForPackageMaker/Install/Library/CVS > ./ForPackageMaker/Install/Library/CVS/Entries > ./ForPackageMaker/Install/Library/CVS/Repository > ./ForPackageMaker/Install/Library/CVS/Tag > ./ForPackageMaker/Install/Library/CVS/Root > ./ForPackageMaker/Install/Library/Java > ./ForPackageMaker/Install/Library/Java/Extensions > ./ForPackageMaker/Install/Library/Java/Extensions/RXTXcomm.jar > ./ForPackageMaker/Install/Library/Java/Extensions/CVS > ./ForPackageMaker/Install/Library/Java/Extensions/CVS/Entries > ./ForPackageMaker/Install/Library/Java/Extensions/CVS/Repository > ./ForPackageMaker/Install/Library/Java/Extensions/CVS/Tag > ./ForPackageMaker/Install/Library/Java/Extensions/CVS/Root > ./ForPackageMaker/Install/Library/Java/Extensions/librxtxSerial.jnilib > ./ForPackageMaker/Install/Library/Java/CVS > ./ForPackageMaker/Install/Library/Java/CVS/Entries > ./ForPackageMaker/Install/Library/Java/CVS/Repository > ./ForPackageMaker/Install/Library/Java/CVS/Entries.Log > ./ForPackageMaker/Install/Library/Java/CVS/Tag > ./ForPackageMaker/Install/Library/Java/CVS/Root > ./ForPackageMaker/RXTX_Tiger.pmproj.sitx.hqx > ./CVS > ./CVS/Entries > ./CVS/Repository > ./CVS/Entries.Log > ./CVS/Tag > ./CVS/Root > ./PB > ./PB/LibSerialUniversal.xcodeproj.sitx.hqx > ./PB/CVS > ./PB/CVS/Entries > ./PB/CVS/Repository > ./PB/CVS/Entries.Log > ./PB/CVS/Tag > ./PB/CVS/Root > ./PB/LibSerial.pbproj.sit.hqx > ./PB/startpoint.c > ./PB/config.h > > What is the procedure to run this installer? > Do we need a README in: > /rxtx-devel/MACOSX_IDE > Here is what we have: > CVS/ ForPackageMaker/ PB/ > > > Thanks! > - DL > >> On Mon, 20 Mar 2006, Dr. Douglas Lyon wrote: >> >>> Hi Dimitry, >>> This sounds like great work. Just a couple of questions; >>> After the check out of the CVS files, using: >>> setenv CVSROOT :pserver:anonymous at cvs.milestonesolutions.com:/usr/ >>> local/cvsroot >>> 53 8:28 setenv PASSWORD mousy >>> 54 8:29 cvs login >>> 55 8:29 cvs checkout rxtx-devel >> >> Hi Doug >> >> You want "cvs checkout -r commapi-0-0-1 rxtx-devel" to get RXTX 2.1 >> The default branch is rxtx 2.0 which isn't very active right now. >> >> -- >> Trent Jarvi >> tjarvi at qbang.org > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx Dmitry Markman From mikehall at spacestar.net Mon Mar 20 05:25:25 2006 From: mikehall at spacestar.net (Michael Hall) Date: Mon, 20 Mar 2006 06:25:25 -0600 Subject: [Rxtx] Re: Mac OS X RXTX java installer In-Reply-To: <64BC1E23-FDDE-4CE6-8863-CFC881CBC224@mac.com> References: <07D0DE29-BA32-4CFE-B036-66BC6423D385@buechse.de> <441AE3E0.2030503@willicon.de> <12531986.1142622114996.JavaMail.dmarkman@mac.com> <441B2674.9010409@willicon.de> <13577405.1142634732776.JavaMail.dmarkman@mac.com> <441B4182.8010407@willicon.de> <92CD0D6C-5BE8-426E-A46D-99452059FF49@mac.com> <441BBB2D.8030305@willicon.de> <441C4088.5090905@willicon.de> <64BC1E23-FDDE-4CE6-8863-CFC881CBC224@mac.com> Message-ID: <247EB61F-5CD1-4132-89A2-FC105B6CF9A5@spacestar.net> On Mar 20, 2006, at 1:20 AM, Dmitry Markman wrote: > > Michael Hall (mikehall at spacestar dot net) had a suggestion to > make implementation of the jaas LoginModule > based on Greg's AuthKit > (his modification of the Greg's AuthKit could be found at http:// > www.spacestar.net/users/mikehall/authkit.dmg) > but Michael's AuthKitLoginModule does only half a job: > it does authenticate > but it can not run any external unix process in privileged mode (at > least I wasn't able to do so) If you got it working directly with Greg's the point is moot. But to clarify it anyhow. The login module does not allow you to do anything anything privileged on return as was explained by Greg. You need to work with a separate privileged process using the execPrivileged method of his API. I assume you did something similar although I haven't looked at how you are using it yet. I allowed instead for a action to be performed at the same time you login/authenticate,this... System.setProperty("authkit.action","/usr/bin/id"); just before this... lc.login(); To clarify, safely ignored as you are already complete. Mike Hall mikehall at spacestar dot net http://www.spacestar.net/users/mikehall http://sourceforge.net/projects/macnative -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2427 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20060320/f6e18202/smime-0012.bin From dmarkman at mac.com Mon Mar 20 07:36:47 2006 From: dmarkman at mac.com (Dmitry Markman) Date: Mon, 20 Mar 2006 09:36:47 -0500 Subject: [Rxtx] Re: Mac OS X RXTX java installer In-Reply-To: <247EB61F-5CD1-4132-89A2-FC105B6CF9A5@spacestar.net> References: <07D0DE29-BA32-4CFE-B036-66BC6423D385@buechse.de> <441AE3E0.2030503@willicon.de> <12531986.1142622114996.JavaMail.dmarkman@mac.com> <441B2674.9010409@willicon.de> <13577405.1142634732776.JavaMail.dmarkman@mac.com> <441B4182.8010407@willicon.de> <92CD0D6C-5BE8-426E-A46D-99452059FF49@mac.com> <441BBB2D.8030305@willicon.de> <441C4088.5090905@willicon.de> <64BC1E23-FDDE-4CE6-8863-CFC881CBC224@mac.com> <247EB61F-5CD1-4132-89A2-FC105B6CF9A5@spacestar.net> Message-ID: Hi, Michael all I have to do is to run some shell script I tried to use your action mechanism and it worked great so I just System.setProperty ("authkit.action","" ) and after that I even don't need to run anything like subject.doAs.... but after few thoughts I choose to use plain Greg's approach, because in that case I don't have to deal with various java's configurations files and therefore to use 2-3 -D parameters in the java command line especially it's useful for java web start (it's so fragile :-( ) thanks for the great job On Mar 20, 2006, at 7:25 AM, Michael Hall wrote: > > On Mar 20, 2006, at 1:20 AM, Dmitry Markman wrote: >> >> Michael Hall (mikehall at spacestar dot net) had a suggestion to >> make implementation of the jaas LoginModule >> based on Greg's AuthKit >> (his modification of the Greg's AuthKit could be found at http:// >> www.spacestar.net/users/mikehall/authkit.dmg) >> but Michael's AuthKitLoginModule does only half a job: >> it does authenticate >> but it can not run any external unix process in privileged mode >> (at least I wasn't able to do so) > > If you got it working directly with Greg's the point is moot. > > But to clarify it anyhow. > The login module does not allow you to do anything anything > privileged on return as was explained by Greg. You need to work > with a separate privileged process using the execPrivileged method > of his API. I assume you did something similar although I haven't > looked at how you are using it yet. > I allowed instead for a action to be performed at the same time you > login/authenticate,this... > System.setProperty("authkit.action","/usr/bin/id"); > just before this... > lc.login(); > To clarify, safely ignored as you are already complete. > > Mike Hall mikehall at spacestar dot net > http://www.spacestar.net/users/mikehall > http://sourceforge.net/projects/macnative > > > Dmitry Markman From dmarkman at mac.com Mon Mar 20 07:44:45 2006 From: dmarkman at mac.com (Dmitry Markman) Date: Mon, 20 Mar 2006 09:44:45 -0500 Subject: [Rxtx] Mac OS X RXTX java installer In-Reply-To: References: <07D0DE29-BA32-4CFE-B036-66BC6423D385@buechse.de> <441AE3E0.2030503@willicon.de> <12531986.1142622114996.JavaMail.dmarkman@mac.com> <441B2674.9010409@willicon.de> <13577405.1142634732776.JavaMail.dmarkman@mac.com> <441B4182.8010407@willicon.de> <92CD0D6C-5BE8-426E-A46D-99452059FF49@mac.com> <441BBB2D.8030305@willicon.de> <441C4088.5090905@willicon.de> <64BC1E23-FDDE-4CE6-8863-CFC881CBC224@mac.com> Message-ID: it's in the commapi-0-0-1 branch I tested it right now: cvs co -r commapi-0-0-1 rxtx-devel and I got everything On Mar 20, 2006, at 9:25 AM, Trent Jarvi wrote: > On Mon, 20 Mar 2006, Dr. Douglas Lyon wrote: > >> Hi Trent, >> Thanks for the info on the CVS checkout procedure. >> I did that and am still not sure where the installer is. > > Hi Doug > > It does look like it was not cvs committed. There is no rxtx-devel/ > contrib/MacOSX directory in there at the moment. It was mentioned > that it was put under contrib. > > -- > Trent Jarvi > tjarvi at qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx Dmitry Markman From tjarvi at qbang.org Mon Mar 20 07:52:57 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 20 Mar 2006 07:52:57 -0700 (MST) Subject: [Rxtx] Mac OS X RXTX java installer In-Reply-To: References: <07D0DE29-BA32-4CFE-B036-66BC6423D385@buechse.de> <441AE3E0.2030503@willicon.de> <12531986.1142622114996.JavaMail.dmarkman@mac.com> <441B2674.9010409@willicon.de> <13577405.1142634732776.JavaMail.dmarkman@mac.com> <441B4182.8010407@willicon.de> <92CD0D6C-5BE8-426E-A46D-99452059FF49@mac.com> <441BBB2D.8030305@willicon.de> <441C4088.5090905@willicon.de> <64BC1E23-FDDE-4CE6-8863-CFC881CBC224@mac.com> Message-ID: On Mon, 20 Mar 2006, Dmitry Markman wrote: > it's in the commapi-0-0-1 branch > > I tested it right now: > cvs co -r commapi-0-0-1 rxtx-devel > > and I got everything > A fresh checkout worked. Here is a copy of the tree (just the installer bits) ftp://ftp.qbang.org/pub/rxtx/MacOSX-installer.zip -- Trent Jarvi tjarvi at qbang.org From lyon at docjava.com Mon Mar 20 08:08:26 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Mon, 20 Mar 2006 10:08:26 -0500 Subject: [Rxtx] Mac OS X RXTX java installer In-Reply-To: References: <07D0DE29-BA32-4CFE-B036-66BC6423D385@buechse.de> <441AE3E0.2030503@willicon.de> <12531986.1142622114996.JavaMail.dmarkman@mac.com> <441B2674.9010409@willicon.de> <13577405.1142634732776.JavaMail.dmarkman@mac.com> <441B4182.8010407@willicon.de> <92CD0D6C-5BE8-426E-A46D-99452059FF49@mac.com> <441BBB2D.8030305@willicon.de> <441C4088.5090905@willicon.de> <64BC1E23-FDDE-4CE6-8863-CFC881CBC224@mac.com> Message-ID: Hi All, Is the Auth package able to work properly on non Mac OS's? It was not clear from the doc or download. Thanks! - Doug From dmarkman at mac.com Mon Mar 20 08:15:22 2006 From: dmarkman at mac.com (Dmitry Markman) Date: Mon, 20 Mar 2006 10:15:22 -0500 Subject: [Rxtx] Mac OS X RXTX java installer In-Reply-To: References: <07D0DE29-BA32-4CFE-B036-66BC6423D385@buechse.de> <441AE3E0.2030503@willicon.de> <12531986.1142622114996.JavaMail.dmarkman@mac.com> <441B2674.9010409@willicon.de> <13577405.1142634732776.JavaMail.dmarkman@mac.com> <441B4182.8010407@willicon.de> <92CD0D6C-5BE8-426E-A46D-99452059FF49@mac.com> <441BBB2D.8030305@willicon.de> <441C4088.5090905@willicon.de> <64BC1E23-FDDE-4CE6-8863-CFC881CBC224@mac.com> Message-ID: <217312D8-CCCA-4859-ABA6-32DF1CC817B9@mac.com> thanks Trent, for putting it on ftp server On Mar 20, 2006, at 9:52 AM, Trent Jarvi wrote: > A fresh checkout worked. Here is a copy of the tree (just the > installer bits) > > ftp://ftp.qbang.org/pub/rxtx/MacOSX-installer.zip > Dmitry Markman From dmarkman at mac.com Mon Mar 20 09:14:03 2006 From: dmarkman at mac.com (Dmitry Markman) Date: Mon, 20 Mar 2006 11:14:03 -0500 Subject: [Rxtx] Mac OS X RXTX java installer In-Reply-To: References: <07D0DE29-BA32-4CFE-B036-66BC6423D385@buechse.de> <441AE3E0.2030503@willicon.de> <12531986.1142622114996.JavaMail.dmarkman@mac.com> <441B2674.9010409@willicon.de> <13577405.1142634732776.JavaMail.dmarkman@mac.com> <441B4182.8010407@willicon.de> <92CD0D6C-5BE8-426E-A46D-99452059FF49@mac.com> <441BBB2D.8030305@willicon.de> <441C4088.5090905@willicon.de> <64BC1E23-FDDE-4CE6-8863-CFC881CBC224@mac.com> Message-ID: <4DEBA6F0-DA45-4E84-823E-1F1AC48BDCCC@mac.com> no it will work only on mac os x however it's harmless to run it on other platform if you want to use it for other platform you have to do the following (I'll do it for linux) 1. modify RXTXInstaller class method public static RXTXInstaller getInstance() public static RXTXInstaller getInstance() { String osName = System.getProperty("os.name").toLowerCase(); if(osName.startsWith("mac")){ return new gnu.io.installer.macosx.MACOSXRXTXInstaller(); } else if(osName.startsWith("windows")){ return new gnu.io.installer.windows.WindowsRXTXInstaller(); }else if(osName.startsWith("linux")){ return new gnu.io.installer.linux.LinuxRXTXInstaller(); } return null; } 2. create folder gnu/io/installer/linux/ 3. create class Linux386RXTXInstaller package gnu.io.installer.linux; import java.io.File; public class Linux386RXTXInstaller extends gnu.io.installer.RXTXInstaller{ public Linux386RXTXInstaller(){ createJarFolder(); createLibFolder(); addJarResource("RXTXcomm.jar","/gnu/io/installer/resources/ linux/jar/RXTXcomm.dat"); addLibResource("librxtxSerial.so","/gnu/io/installer/ resources/linux/lib/librxtxSerial.so"); } protected void createJarFolder(){ String javaHome = System.getProperty("java.home"); char separator = File.separatorChar; jarFolder = new File(javaHome+separator+"lib"+separator+"ext"); } protected void createLibFolder(){ String javaHome = System.getProperty("java.home"); char separator = File.separatorChar; libFolder = new File(javaHome+separator+"bin"); } public void runPreProcess() {} //put here some action you need public void runPostProcess() {} //put here some action you need } 4. create folder /gnu/io/installer/resources/linux/jar and put there linux's version of RXTXcomm.dat (which is renamed RXTXcomm.jar) 5. create folder /gnu/io/installer/resources/linux/lib and put there linux's version of librxtxSerial. so 6. make sure that RXTXInstaller.jar has the following items: /gnu/io/installer/resources/linux/jar/RXTXcomm.jar /gnu/io/installer/resources/linux/lib/librxtxSerial.so 7. modify file installer.pref: jar file RXTXInstaller.jar must have the following item /gnu/io/installer/installer.pref that's basically it for windows you have to do the similar things: just replace linux to windows and librxtxSerial.so to rxtxSerial.dll and create appropriate gnu.io.installer.windows.WindowsRXTXInstaller class package gnu.io.installer.windows; import java.io.File; public class WindowsRXTXInstaller extends gnu.io.installer.RXTXInstaller{ public WindowsRXTXInstaller(){ createJarFolder(); createLibFolder(); addJarResource("RXTXcomm.jar","/gnu/io/installer/resources/ windows/jar/RXTXcomm.dat"); addLibResource("librxtxSerial.so","/gnu/io/installer/ resources/windows/lib/rxtxSerial.dll"); } protected void createJarFolder(){ String javaHome = System.getProperty("java.home"); char separator = File.separatorChar; jarFolder = new File(javaHome+separator+"lib"+separator+"ext"); } protected void createLibFolder(){ String javaHome = System.getProperty("java.home"); char separator = File.separatorChar; libFolder = new File(javaHome+separator+"bin"); } public void runPreProcess() {} //put here some action you need public void runPostProcess() {} //put here some action you need } installer.pref will look like On Mar 20, 2006, at 10:08 AM, Dr. Douglas Lyon wrote: > Hi All, > Is the Auth package able to work properly on > non Mac OS's? > It was not clear from the doc or download. > > Thanks! > - Doug > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx Dmitry Markman From joachim at buechse.de Mon Mar 20 10:49:06 2006 From: joachim at buechse.de (Joachim Buechse) Date: Mon, 20 Mar 2006 18:49:06 +0100 Subject: [Rxtx] BUG: Lock file stays even if port opening fails Message-ID: This was only tested on MacOSX but looking at the code, it should be true for all systems that use lock_uucp. I am opening a port which can not be opened (dialup port of a telephone paired via bluetooth but currently not reachable). The lock file is created and stays arround, even though the port open failed. After looking a bit through the code (of 2.17), I really wonder if it wouldn't be a good idea to make the "locking" an explicit operation called from the java code. This would certainly simplify the generation of meaningfull exceptions (and java based debugging). Maybe even the handling of "preopened" ports should be in the Java part of the lib (again for java based debugging puposes). That beeing said, I have no idea if this would be possible for the 2.07 implementation. Regards, Joachim From tjarvi at qbang.org Mon Mar 20 11:24:22 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 20 Mar 2006 11:24:22 -0700 (MST) Subject: [Rxtx] BUG: Lock file stays even if port opening fails In-Reply-To: References: Message-ID: On Mon, 20 Mar 2006, Joachim Buechse wrote: > This was only tested on MacOSX but looking at the code, it should be true > for all systems that use lock_uucp. > > I am opening a port which can not be opened (dialup port of a telephone > paired via bluetooth but currently not reachable). The lock file is > created and stays arround, even though the port open failed. > > > After looking a bit through the code (of 2.17), I really wonder if it > wouldn't be a good idea to make the "locking" an explicit operation > called from the java code. This would certainly simplify the generation > of meaningfull exceptions (and java based debugging). > Maybe even the handling of "preopened" ports should be in the Java part > of the lib (again for java based debugging puposes). That beeing said, I > have no idea if this would be possible for the 2.07 implementation. > > Regards, Hi Joachim It should be possible in the 2.0-7 implementation too. The calls to RXTXPort.java would not change. We would just do more there Moving more of that logic into Java would be better as many people don't like to look at C code. There is a liblockdev on most Linux distros that can do most of the C code and would be easier to use. The problem is embeded devices will not have that library. The preopened port code has not been really tested. That was a last minute request in a product cycle. I expect it will be tested this year though. As I recall, some devices really do not like CD raising on open. The preopened ports then allow people to mess around in java without power cycling the devices or losing data. -- Trent Jarvi tjarvi at qbang.org From joachim at buechse.de Mon Mar 20 12:01:08 2006 From: joachim at buechse.de (Joachim Buechse) Date: Mon, 20 Mar 2006 20:01:08 +0100 Subject: [Rxtx] BUG: Lock file stays even if port opening fails In-Reply-To: References: Message-ID: Hi Trent, What is your general feeling about moving code to Java? The last days I have been reading quite a bit of the code and there are several things, that might not work as expected. I'll give you two examples from is_device_locked: if LOCKDIR == /var/spool/locks the directory /var/spool/lock will not be checked. LOCKDIR is not checked for lockfiles with unexpected pefixes While these things have probably never been discovered in production, they are still possibly incorrect implementations. If it was Java code, I would write some unit tests producing the errors that could later be corrected. PS: One could imagine to actually implement the whole lockfile handling in Java using some native routines to get the values required (pid, st_dev, st_rdev, ...). On 20.03.2006, at 19:24, Trent Jarvi wrote: > On Mon, 20 Mar 2006, Joachim Buechse wrote: > >> This was only tested on MacOSX but looking at the code, it should >> be true for all systems that use lock_uucp. >> >> I am opening a port which can not be opened (dialup port of a >> telephone paired via bluetooth but currently not reachable). The >> lock file is created and stays arround, even though the port open >> failed. >> >> >> After looking a bit through the code (of 2.17), I really wonder if >> it wouldn't be a good idea to make the "locking" an explicit >> operation called from the java code. This would certainly simplify >> the generation of meaningfull exceptions (and java based debugging). >> Maybe even the handling of "preopened" ports should be in the Java >> part of the lib (again for java based debugging puposes). That >> beeing said, I have no idea if this would be possible for the 2.07 >> implementation. >> >> Regards, > > Hi Joachim > > It should be possible in the 2.0-7 implementation too. The calls > to RXTXPort.java would not change. We would just do more there > Moving more of that logic into Java would be better as many people > don't like to look at C code. There is a liblockdev on most Linux > distros that can do most of the C code and would be easier to use. > The problem is embeded devices will not have that library. > > The preopened port code has not been really tested. That was a > last minute request in a product cycle. I expect it will be tested > this year though. As I recall, some devices really do not like CD > raising on open. The preopened ports then allow people to mess > around in java without power cycling the devices or losing data. > > -- > Trent Jarvi > tjarvi at qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Mon Mar 20 12:21:02 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 20 Mar 2006 12:21:02 -0700 (MST) Subject: [Rxtx] BUG: Lock file stays even if port opening fails In-Reply-To: References: Message-ID: On Mon, 20 Mar 2006, Joachim Buechse wrote: > Hi Trent, > > What is your general feeling about moving code to Java? The last days I > have been reading quite a bit of the code and there are several things, > that might not work as expected. > > I'll give you two examples from is_device_locked: > > if LOCKDIR == /var/spool/locks the directory /var/spool/lock will not be > checked. > LOCKDIR is not checked for lockfiles with unexpected pefixes > > While these things have probably never been discovered in production, > they are still possibly incorrect implementations. If it was Java code, I > would write some unit tests producing the errors that could later be > corrected. > > PS: One could imagine to actually implement the whole lockfile handling > in Java using some native routines to get the values required (pid, > st_dev, st_rdev, ...). Hi Joachim I like the idea of moving more of the code into java but there are some things to consider. If you break this into multiple JNI calls, the performance will drop considerably during enumeration of ports. We are looking for 256 ports per dev type vs (16? in Sun's 2.0 and fewer types). Its hard to make assumptions. I've seen virtual ports start at /dev/foo100 for instance. It works out to over 7500 ports on Linux if you enable them all. We already trim that back by default. See Linux-all-ports in RXTXCommDriver.java. There are also native libraries that rxtx can link to. If you move too much into Java, linking to 'standard' libraries with distros will break. "configure --enable-liblock=yes" will not be doable. This is probably a favorable way with RedHat, Debian, Suse and others. Thats the right thing to do if there will be rpms, dpkg, .. For those reasons, I think it still make sense to keep it to a minimal ~3 calls to JNI code that we can use for speed and versatility. lock() isLocked(), unlock() perhaps. When I say speed, its more about avoiding crossing the JNI layer multiple times than java vs C performance. With versatility I think liblock is the right way for most but not all (embeded) linux distros. -- Trent Jarvi tjarvi at qbang.org From joachim at buechse.de Mon Mar 20 12:42:04 2006 From: joachim at buechse.de (Joachim Buechse) Date: Mon, 20 Mar 2006 20:42:04 +0100 Subject: [Rxtx] BUG: Lock file stays even if port opening fails In-Reply-To: References: Message-ID: <82C19FE7-DDCB-45B6-B2C9-7606B66F0124@buechse.de> Ok, what about providing a default implementation in Java? The RXTXCommDriver would call a (native) function useNativeLocking and if it returns true, call the native functions for lock() isLocked (), unlock(), else is would use the Java based default implementation. This could possibly be overriden by a property (again for debugging). Joachim On 20.03.2006, at 20:21, Trent Jarvi wrote: > On Mon, 20 Mar 2006, Joachim Buechse wrote: > >> Hi Trent, >> >> What is your general feeling about moving code to Java? The last >> days I have been reading quite a bit of the code and there are >> several things, that might not work as expected. >> >> I'll give you two examples from is_device_locked: >> >> if LOCKDIR == /var/spool/locks the directory /var/spool/lock will >> not be checked. >> LOCKDIR is not checked for lockfiles with unexpected pefixes >> >> While these things have probably never been discovered in >> production, they are still possibly incorrect implementations. If >> it was Java code, I would write some unit tests producing the >> errors that could later be corrected. >> >> PS: One could imagine to actually implement the whole lockfile >> handling in Java using some native routines to get the values >> required (pid, st_dev, st_rdev, ...). > > Hi Joachim > > I like the idea of moving more of the code into java but there are > some things to consider. > > If you break this into multiple JNI calls, the performance will > drop considerably during enumeration of ports. We are looking for > 256 ports per dev type vs (16? in Sun's 2.0 and fewer types). Its > hard to make assumptions. I've seen virtual ports start at /dev/ > foo100 for instance. > > It works out to over 7500 ports on Linux if you enable them all. > We already trim that back by default. See Linux-all-ports in > RXTXCommDriver.java. > > There are also native libraries that rxtx can link to. If you move > too much into Java, linking to 'standard' libraries with distros > will break. "configure --enable-liblock=yes" will not be doable. > This is probably a favorable way with RedHat, Debian, Suse and > others. Thats the right thing to do if there will be rpms, dpkg, .. > > For those reasons, I think it still make sense to keep it to a > minimal ~3 calls to JNI code that we can use for speed and > versatility. lock() isLocked(), unlock() perhaps. When I say > speed, its more about avoiding crossing the JNI layer multiple > times than java vs C performance. With versatility I think liblock > is the right way for most but not all (embeded) linux distros. > > -- > Trent Jarvi > tjarvi at qbang.org > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Mon Mar 20 12:44:47 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 20 Mar 2006 12:44:47 -0700 (MST) Subject: [Rxtx] BUG: Lock file stays even if port opening fails In-Reply-To: <82C19FE7-DDCB-45B6-B2C9-7606B66F0124@buechse.de> References: <82C19FE7-DDCB-45B6-B2C9-7606B66F0124@buechse.de> Message-ID: On Mon, 20 Mar 2006, Joachim Buechse wrote: > Ok, what about providing a default implementation in Java? > > The RXTXCommDriver would call a (native) function useNativeLocking and if > it returns true, call the native functions for lock() isLocked(), > unlock(), else is would use the Java based default implementation. This > could possibly be overriden by a property (again for debugging). > Hi Joachim That would be OK with me. -- Trent Jarvi tjarvi at qbang.org From dmarkman at mac.com Mon Mar 20 22:27:45 2006 From: dmarkman at mac.com (Dmitry Markman) Date: Tue, 21 Mar 2006 00:27:45 -0500 Subject: [Rxtx] binaries request Message-ID: <42702213-C222-4937-A585-7CFB17E47608@mac.com> Hi can somebody send me latest linux and windows binaries, please? or where I can find them (I didn't find them in the latest tareball) I gave up with my cygwin: something wrong I have no idea what java doesn't understand /cygwin/c syntax after I changed makefile it did java part but after that gcc 3.4.4 started to complain I set buffer length to 999 lines but I didn't get beginning of the story something wrong with my 1.4.2_09/include/jni.h gcc doesn't like it anyway I gave up thanks in advance Dmitry Markman -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060320/f8cbc57c/attachment-0012.html From tjarvi at qbang.org Mon Mar 20 22:36:48 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 20 Mar 2006 22:36:48 -0700 (MST) Subject: [Rxtx] binaries request In-Reply-To: <42702213-C222-4937-A585-7CFB17E47608@mac.com> References: <42702213-C222-4937-A585-7CFB17E47608@mac.com> Message-ID: On Tue, 21 Mar 2006, Dmitry Markman wrote: > Hi > can somebody send me latest linux and windows binaries, please? > > or where I can find them (I didn't find them in the latest tareball) > > I gave up with my cygwin: something wrong I have no idea what > java doesn't understand /cygwin/c syntax > after I changed makefile it did java part > but after that gcc 3.4.4 started to complain > I set buffer length to 999 lines but I didn't get beginning of the story > something wrong with my 1.4.2_09/include/jni.h gcc doesn't like it > anyway I gave up > > thanks in advance > Hi Dmitry The bins are here: ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7-bins-r2.zip Here are the files in the zip you want. Jar: rxtx-2.1-7-bins-r2/RXTXcomm.jar Windows: rxtx-2.1-7-bins-r2/Windows/i368-mingw32/rxtxSerial.dll Linux (x86) rxtx-2.1-7-bins-r2/Linux/i686-unknown-linux-gnu/librxtxSerial.so There are others in there including Parallel port support but those are the main ones for testing. -- Trent Jarvi tjarvi at qbang.org From dmarkman at mac.com Mon Mar 20 23:05:59 2006 From: dmarkman at mac.com (Dmitry Markman) Date: Tue, 21 Mar 2006 01:05:59 -0500 Subject: [Rxtx] binaries request In-Reply-To: References: <42702213-C222-4937-A585-7CFB17E47608@mac.com> Message-ID: thank you very much but windows's readme says: rxtxSerial.dll had to be recomopiled to link in missing native methods. should I ignore it? or what? thanks again also I understand that I should use mingw not cygwin I'll try to install mingw On Mar 21, 2006, at 12:36 AM, Trent Jarvi wrote: > On Tue, 21 Mar 2006, Dmitry Markman wrote: > >> Hi >> can somebody send me latest linux and windows binaries, please? >> >> or where I can find them (I didn't find them in the latest tareball) >> >> I gave up with my cygwin: something wrong I have no idea what >> java doesn't understand /cygwin/c syntax >> after I changed makefile it did java part >> but after that gcc 3.4.4 started to complain >> I set buffer length to 999 lines but I didn't get beginning of the >> story >> something wrong with my 1.4.2_09/include/jni.h gcc doesn't like it >> anyway I gave up >> >> thanks in advance >> > > Hi Dmitry > > The bins are here: > > ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7-bins-r2.zip > > Here are the files in the zip you want. > > Jar: > > rxtx-2.1-7-bins-r2/RXTXcomm.jar > > Windows: > > rxtx-2.1-7-bins-r2/Windows/i368-mingw32/rxtxSerial.dll > > Linux (x86) > > rxtx-2.1-7-bins-r2/Linux/i686-unknown-linux-gnu/librxtxSerial.so > > There are others in there including Parallel port support but those > are the main ones for testing. > > -- > Trent Jarvi > tjarvi at qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx Dmitry Markman From tjarvi at qbang.org Mon Mar 20 23:20:33 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 20 Mar 2006 23:20:33 -0700 (MST) Subject: [Rxtx] binaries request In-Reply-To: References: <42702213-C222-4937-A585-7CFB17E47608@mac.com> Message-ID: On Tue, 21 Mar 2006, Dmitry Markman wrote: > thank you very much > > but windows's readme says: > rxtxSerial.dll had to be recomopiled to link in missing native methods. > > should I ignore it? or what? > Hi Dmitry That dll should be OK. r2 is the recompile linked to the missing native method. The readme explains why it was recompiled; fuser.o was not linked into the dll in the first release. -- Trent Jarvi tjarvi at qbang.org From ariantristan at yahoo.com Mon Mar 20 23:55:24 2006 From: ariantristan at yahoo.com (Lambok Sianturi) Date: Mon, 20 Mar 2006 22:55:24 -0800 (PST) Subject: [Rxtx] jvm issue Message-ID: <20060321065524.94779.qmail@web50701.mail.yahoo.com> Hi All, This is my first time to join RxTx mailing list. I thank you all for allowing others to sign in in requests help. I use the latest RxTx lib in Fedora 3 with java version 1.4.2_09 b05. And I got this error: # # An unexpected error has been detected by HotSpot Virtual Machine: # # SIGSEGV (0xb) at pc=0x00bf27f3, pid=2633, tid=3086112448 # # Java VM: Java HotSpot(TM) Client VM (1.4.2_09-b05 mixed mode) # Problematic frame: # C [ld-linux.so.2+0xa7f3] # # An error report file with more information is saved as hs_err_pid2633.log # # If you would like to submit a bug report, please visit: # http://java.sun.com/webapps/bugreport/crash.jsp # ./run.sh: line 3: 2633 Aborted /usr/local/java/bin/java -Djava.library.path=/usr/local/java/jre/lib/ -Djsmsengine.debug=true -classpath jsmsengine.jar:smsgateway.jar:classes12.jar:RXTXcomm.jar:. com.api.sms.SMSServer What is the jvm depedency for the latest library? Can I use 1.4.2_09 b05? Thanks in advance. Arian --------------------------------- Yahoo! Mail Use Photomail to share photos without annoying attachments. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060320/83d58dd7/attachment-0012.html From f.frumento at ngi.it Tue Mar 21 00:21:47 2006 From: f.frumento at ngi.it (Fabio Frumento) Date: Tue, 21 Mar 2006 08:21:47 +0100 Subject: [Rxtx] Javadoc on the go Message-ID: <441FA98B.9050701@ngi.it> Hi Trent, sorry for the big delay but my job is running wild, i was out for some time but now i'm back and ready to continue the javadoc for Rxtx. Did you used the last javadoc patch i sent you ? let me know if i have to send it to you again or not. regards Fabio From lyon at docjava.com Tue Mar 21 00:51:18 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Tue, 21 Mar 2006 02:51:18 -0500 Subject: [Rxtx] lock files Message-ID: Hi All, You know, if the use of lock files were under Java control (rather than a build-time decision), it might enable a more unified binary distro. It might also facilitate quick prototyping of non-lock file approaches to resolving serial port contention issues (i.e., mac-like approaches vs. linux approaches, etc.). I realize that this is a radical overhaul of the lock file policy issue. Also, it may harm performance. On the other hand, our benchmarks on JNI overhead for modern processors indicate performance impact should be minimal. Perhaps it is more of an issue with the toybox systems. Suppose there were a class with a reasonable default...someone might write: SerialPortLockPolicy.setPolicy(SerialPortLockPolicy.UNIX_LOCK_FILE); SerialPortLockPolicy.setPolicy(SerialPortLockPolicy.NO_LOCK_CHECKING); SerialPortLockPolicy.setPolicy(SerialPortLockPolicy.MAC_STYLE); Thus, we could have a run-time reconfiguration of the serial port lock policy. A special NO_LOCK version of the binary would no longer be required. Any thoughts on this? Thanks! - Doug From joachim at buechse.de Tue Mar 21 03:09:09 2006 From: joachim at buechse.de (Joachim Buechse) Date: Tue, 21 Mar 2006 11:09:09 +0100 Subject: [Rxtx] lock files In-Reply-To: References: Message-ID: <8E12916A-1B9A-4FF2-B684-E2D1C794221B@buechse.de> This is pretty much what I thought about when I suggested, that the default behaviour could be overwritten with a property. I am very much in favor of this approach. In particular this allows much easier debugging for PC based java developers. I think big parts of the Java (and maybe some parts of the C code) could use a bit of a structural workover (unit tests, javadoc, synchronization, etc). Maybe there should be a CVS branch for this experimental version. I'd be happy to contribute a first workover for some of the Java code. Designing for testability and implementing a good bunch of unit tests has been a strategy that worked quite well in the Java projects I lead. And it ultimately allows more liberal change permission. Regards, Joachim On 21.03.2006, at 08:51, Dr. Douglas Lyon wrote: > Hi All, > You know, if the use of lock files were > under Java control (rather than a build-time decision), > it might enable a more unified binary distro. It might also > facilitate quick prototyping of non-lock file approaches > to resolving serial port contention issues (i.e., mac-like > approaches vs. linux approaches, etc.). > > I realize that this is a radical overhaul of the lock file policy > issue. Also, it may harm performance. On the other hand, > our benchmarks on JNI overhead for modern processors indicate > performance impact should be minimal. Perhaps it is more of > an issue with the toybox systems. > > Suppose there were a class with a reasonable default...someone > might write: > SerialPortLockPolicy.setPolicy(SerialPortLockPolicy.UNIX_LOCK_FILE); > SerialPortLockPolicy.setPolicy(SerialPortLockPolicy.NO_LOCK_CHECKING); > SerialPortLockPolicy.setPolicy(SerialPortLockPolicy.MAC_STYLE); > > Thus, we could have a run-time reconfiguration of the serial port lock > policy. A special NO_LOCK version of the binary would no longer > be required. > > Any thoughts on this? > > Thanks! > - Doug > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From joachim at buechse.de Tue Mar 21 06:23:08 2006 From: joachim at buechse.de (Joachim Buechse) Date: Tue, 21 Mar 2006 14:23:08 +0100 Subject: [Rxtx] PATCH: use of ioctl(fd, TIOCEXCL) instead of lockfiles Message-ID: <923AE774-EEA2-4911-92D8-32BB27802C8B@buechse.de> Here is the patch for the ioctl(fd, TIOCEXCL). I have verified this only for OSX 10.4.5, hence it is only defined for APPLE. However, it should work at least for Solaris as well. If a process has requested TIOEXCL further open calls by other user processes will fail. The patch also disables uucp style locking for APPLE. Obviously this is discussable. I think it is the way to go, as it eliminates creating the lock directory which doesnt exist on the standard installation and it eliminates messing with the system group definitions (adding users to group uucp). Regarding the possibility of root processes opening a device which is locked - I consider this a feature not a potential problem. It is highly unlikely, that somebody is crazy enough to run a JavaVM as root (unless he has no other means of getting a restricted IP port opened, ie doesnt understand ipfw). Anyway, even if the process runs as root, it fails when calling ioctl(fd, TIOCEXCL). It could however still open the port to listen for RING events. I.e. a fax server which needs to see incoming calls but otherwise doesnt want to block the port. So the only case where the proposed mechanism fails is, if an incorrectly implemented process running as root conflicts with a user process. I think this can be accepted. Regards, Joachim PS: If this patch is generally accepted, the installer and Mac doku should obviously be changed as well. Index: SerialImp.c =================================================================== RCS file: /usr/local/cvsroot/rxtx-devel/src/SerialImp.c,v retrieving revision 1.46.2.187 diff -u -r1.46.2.187 SerialImp.c --- SerialImp.c 29 Jan 2006 22:19:04 -0000 1.46.2.187 +++ SerialImp.c 21 Mar 2006 12:59:16 -0000 @@ -656,6 +656,25 @@ fd=OPEN (filename, O_RDWR | O_NOCTTY | O_NONBLOCK ); } while (fd < 0 && errno==EINTR); +#ifdef OPEN_EXCL + // Note that open() follows POSIX semantics: multiple open() calls to + // the same file will succeed unless the TIOCEXCL ioctl is issued. + // This will prevent additional opens except by root-owned processes. + // See tty(4) ("man 4 tty") and ioctl(2) ("man 2 ioctl") for details. + + if (fd >= 0 && (ioctl(fd, TIOCEXCL) == -1)) + { + sprintf( message, "open: exclusive access denied for % s\n", + filename ); + report( message ); + report_error( message ); + + close(fd); + goto fail; + } +#endif /* OPEN_EXCL */ + + if( configure_port( fd ) ) goto fail; (*env)->ReleaseStringUTFChars( env, jstr, filename ); sprintf( message, "open: fd returned is %i\n", fd ); Index: SerialImp.h =================================================================== RCS file: /usr/local/cvsroot/rxtx-devel/src/SerialImp.h,v retrieving revision 1.11.2.49 diff -u -r1.11.2.49 SerialImp.h --- SerialImp.h 5 Jul 2005 17:47:21 -0000 1.11.2.49 +++ SerialImp.h 21 Mar 2006 12:59:17 -0000 @@ -135,7 +135,8 @@ /*# define LOCKDIR "/var/spool/uucp"*/ # define LOCKDIR "/var/lock" # define LOCKFILEPREFIX "LK." -# define UUCP +/*# define UUCP*/ +# define OPEN_EXCL #endif /* __APPLE__ */ #if defined(__NetBSD__) # define DEVICEDIR "/dev/" From tjarvi at qbang.org Tue Mar 21 10:26:08 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 21 Mar 2006 10:26:08 -0700 (MST) Subject: [Rxtx] Javadoc on the go In-Reply-To: <441FA98B.9050701@ngi.it> References: <441FA98B.9050701@ngi.it> Message-ID: On Tue, 21 Mar 2006, Fabio Frumento wrote: > Hi Trent, > > sorry for the big delay but my job is running wild, i was out for some > time but now i'm back and ready to continue the javadoc for Rxtx. > > Did you used the last javadoc patch i sent you ? let me know if i have to > send it to you again or not. > > regards > > Fabio Hi Fabio The patch is in the rxtx mail-list archives. It will be going in soon. I did not see a time critical portion. I'll probably be going through the list since the last batch of patches this weekend and putting them into CVS. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Tue Mar 21 10:57:18 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 21 Mar 2006 10:57:18 -0700 (MST) Subject: [Rxtx] jvm issue In-Reply-To: <20060321065524.94779.qmail@web50701.mail.yahoo.com> References: <20060321065524.94779.qmail@web50701.mail.yahoo.com> Message-ID: On Mon, 20 Mar 2006, Lambok Sianturi wrote: > Hi All, > This is my first time to join RxTx mailing list. I thank you all for allowing others to sign in in requests help. > I use the latest RxTx lib in Fedora 3 with java version 1.4.2_09 b05. And I got this error: > > # > # An unexpected error has been detected by HotSpot Virtual Machine: > # > # SIGSEGV (0xb) at pc=0x00bf27f3, pid=2633, tid=3086112448 > # > # Java VM: Java HotSpot(TM) Client VM (1.4.2_09-b05 mixed mode) > # Problematic frame: > # C [ld-linux.so.2+0xa7f3] A native library loading error? What happens if you recompile rxtx on your system and install that? This sounds like an ABI problem? rxtx 2.1-7 was compiled with a gcc 2.96 toolchain as I recall. The hope is newer system will be backwards compatible. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Tue Mar 21 11:05:29 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 21 Mar 2006 11:05:29 -0700 (MST) Subject: [Rxtx] PATCH: use of ioctl(fd, TIOCEXCL) instead of lockfiles In-Reply-To: <923AE774-EEA2-4911-92D8-32BB27802C8B@buechse.de> References: <923AE774-EEA2-4911-92D8-32BB27802C8B@buechse.de> Message-ID: On Tue, 21 Mar 2006, Joachim Buechse wrote: > Here is the patch for the ioctl(fd, TIOCEXCL). I have verified this only > for OSX 10.4.5, hence it is only defined for APPLE. However, it should > work at least for Solaris as well. > > If a process has requested TIOEXCL further open calls by other user > processes will fail. > > The patch also disables uucp style locking for APPLE. Obviously this is > discussable. I think it is the way to go, as it eliminates creating the > lock directory which doesnt exist on the standard installation and it > eliminates messing with the system group definitions (adding users to > group uucp). > > Regarding the possibility of root processes opening a device which is > locked - I consider this a feature not a potential problem. It is highly > unlikely, that somebody is crazy enough to run a JavaVM as root (unless > he has no other means of getting a restricted IP port opened, ie doesnt > understand ipfw). Anyway, even if the process runs as root, it fails when > calling ioctl(fd, TIOCEXCL). It could however still open the port to > listen for RING events. I.e. a fax server which needs to see incoming > calls but otherwise doesnt want to block the port. So the only case where > the proposed mechanism fails is, if an incorrectly implemented process > running as root conflicts with a user process. I think this can be > accepted. > > Regards, > Joachim > > PS: If this patch is generally accepted, the installer and Mac doku > should obviously be changed as well. > > > Index: SerialImp.c > =================================================================== > RCS file: /usr/local/cvsroot/rxtx-devel/src/SerialImp.c,v > retrieving revision 1.46.2.187 > diff -u -r1.46.2.187 SerialImp.c > --- SerialImp.c 29 Jan 2006 22:19:04 -0000 1.46.2.187 > +++ SerialImp.c 21 Mar 2006 12:59:16 -0000 > @@ -656,6 +656,25 @@ > fd=OPEN (filename, O_RDWR | O_NOCTTY | O_NONBLOCK ); > } while (fd < 0 && errno==EINTR); > > +#ifdef OPEN_EXCL > + // Note that open() follows POSIX semantics: multiple open() > calls to > + // the same file will succeed unless the TIOCEXCL ioctl is > issued. > + // This will prevent additional opens except by root-owned > processes. > + // See tty(4) ("man 4 tty") and ioctl(2) ("man 2 ioctl") for > details. > + > + if (fd >= 0 && (ioctl(fd, TIOCEXCL) == -1)) > + { > + sprintf( message, "open: exclusive access denied for % > s\n", > + filename ); > + report( message ); > + report_error( message ); > + > + close(fd); > + goto fail; > + } > +#endif /* OPEN_EXCL */ > + > + > if( configure_port( fd ) ) goto fail; > (*env)->ReleaseStringUTFChars( env, jstr, filename ); > sprintf( message, "open: fd returned is %i\n", fd ); > Index: SerialImp.h > =================================================================== > RCS file: /usr/local/cvsroot/rxtx-devel/src/SerialImp.h,v > retrieving revision 1.11.2.49 > diff -u -r1.11.2.49 SerialImp.h > --- SerialImp.h 5 Jul 2005 17:47:21 -0000 1.11.2.49 > +++ SerialImp.h 21 Mar 2006 12:59:17 -0000 > @@ -135,7 +135,8 @@ > /*# define LOCKDIR "/var/spool/uucp"*/ > # define LOCKDIR "/var/lock" > # define LOCKFILEPREFIX "LK." > -# define UUCP > +/*# define UUCP*/ > +# define OPEN_EXCL > #endif /* __APPLE__ */ > #if defined(__NetBSD__) > # define DEVICEDIR "/dev/" > This looks like a good start. What do you think Dmitry? Perhaps all systems with TIOCEXCL defined should use that though. Even if they use lockfiles. It wont hurt anything. That would catch people hacking their own serial apps without checking lockfiles. Its a good idea to avoid C++ style comments in the C portions. Some older systems don't deal with them well. If it's just for Mac OS X, it isn't a big deal. I think it was the Irix compiler that was problematic? -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Tue Mar 21 11:22:05 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 21 Mar 2006 11:22:05 -0700 (MST) Subject: [Rxtx] lock files In-Reply-To: <8E12916A-1B9A-4FF2-B684-E2D1C794221B@buechse.de> References: <8E12916A-1B9A-4FF2-B684-E2D1C794221B@buechse.de> Message-ID: We can try it. Maybe the JNI is much improved. The nice thing about linking into liblock is distros then worry about lockfiles on their systems. This way, we have to deal with any changes that may show up. On Tue, 21 Mar 2006, Joachim Buechse wrote: > This is pretty much what I thought about when I suggested, that the > default behaviour could be overwritten with a property. I am very much in > favor of this approach. In particular this allows much easier debugging > for PC based java developers. > > I think big parts of the Java (and maybe some parts of the C code) could > use a bit of a structural workover (unit tests, javadoc, synchronization, > etc). Maybe there should be a CVS branch for this experimental version. > I'd be happy to contribute a first workover for some of the Java code. > Designing for testability and implementing a good bunch of unit tests has > been a strategy that worked quite well in the Java projects I lead. And > it ultimately allows more liberal change permission. > > Regards, > Joachim > > > On 21.03.2006, at 08:51, Dr. Douglas Lyon wrote: > >> Hi All, >> You know, if the use of lock files were >> under Java control (rather than a build-time decision), >> it might enable a more unified binary distro. It might also >> facilitate quick prototyping of non-lock file approaches >> to resolving serial port contention issues (i.e., mac-like >> approaches vs. linux approaches, etc.). >> >> I realize that this is a radical overhaul of the lock file policy >> issue. Also, it may harm performance. On the other hand, >> our benchmarks on JNI overhead for modern processors indicate >> performance impact should be minimal. Perhaps it is more of >> an issue with the toybox systems. >> >> Suppose there were a class with a reasonable default...someone >> might write: >> SerialPortLockPolicy.setPolicy(SerialPortLockPolicy.UNIX_LOCK_FILE); >> SerialPortLockPolicy.setPolicy(SerialPortLockPolicy.NO_LOCK_CHECKING); >> SerialPortLockPolicy.setPolicy(SerialPortLockPolicy.MAC_STYLE); >> >> Thus, we could have a run-time reconfiguration of the serial port lock >> policy. A special NO_LOCK version of the binary would no longer >> be required. >> >> Any thoughts on this? >> >> Thanks! >> - Doug >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From dmarkman at mac.com Tue Mar 21 16:05:17 2006 From: dmarkman at mac.com (Dmitry Markman) Date: Tue, 21 Mar 2006 18:05:17 -0500 Subject: [Rxtx] PATCH: use of ioctl(fd, TIOCEXCL) instead of lockfiles In-Reply-To: References: <923AE774-EEA2-4911-92D8-32BB27802C8B@buechse.de> Message-ID: <512AC70C-BB86-48F2-A83C-023F35C23BAB@mac.com> I think it's cool, but I'd like to have that property implementation when user can choose between locking mechanism about comments: it's easy to change comments to the C style or we can use extensions of the file to cpp so c++ compiler will be used On Mar 21, 2006, at 1:05 PM, Trent Jarvi wrote: > This looks like a good start. What do you think Dmitry? Perhaps > all systems with TIOCEXCL defined should use that though. Even if > they use lockfiles. It wont hurt anything. That would catch > people hacking their own serial apps without checking lockfiles. > > Its a good idea to avoid C++ style comments in the C portions. > Some older systems don't deal with them well. If it's just for Mac > OS X, it isn't a big deal. I think it was the Irix compiler that > was problematic? Dmitry Markman From dmarkman at mac.com Tue Mar 21 16:13:00 2006 From: dmarkman at mac.com (Dmitry Markman) Date: Tue, 21 Mar 2006 18:13:00 -0500 Subject: [Rxtx] PATCH: use of ioctl(fd, TIOCEXCL) instead of lockfiles In-Reply-To: References: <923AE774-EEA2-4911-92D8-32BB27802C8B@buechse.de> Message-ID: I'd like to add that creating locking folder isn't a big deal we never had a problem related to the lock folders, because we always used installer on mac os x from other hand I'm not very much familiar with iotcl locking approach and I'm not sure it's more efficient Joachim wrote "I think it is the way to go, as it eliminates creating the lock directory which doesnt exist on the standard installation and it eliminates messing with the system group definitions (adding users to group uucp)." but I really didn't have any problem with that 1. doesn't exist on the standard installation there are many-many things that don't exist in the standard installation so I don't think that argument is strong enough 2. messing with the system group definitions I don't think we're messing with the group definition mac os x provides very clear way to set up group's members and together with Greg Guerin AuthKit there is no problem to set those definitions so I don't think that argument is strong either but from other hand using iotcl is more promising and is more elegant On Mar 21, 2006, at 1:05 PM, Trent Jarvi wrote: > > This looks like a good start. What do you think Dmitry? Perhaps > all systems with TIOCEXCL defined should use that though. Even if > they use lockfiles. It wont hurt anything. That would catch > people hacking their own serial apps without checking lockfiles. Dmitry Markman From joachim at buechse.de Wed Mar 22 04:46:45 2006 From: joachim at buechse.de (Joachim Buechse) Date: Wed, 22 Mar 2006 12:46:45 +0100 Subject: [Rxtx] PATCH: use of ioctl(fd, TIOCEXCL) instead of lockfiles In-Reply-To: References: <923AE774-EEA2-4911-92D8-32BB27802C8B@buechse.de> Message-ID: Sorry, I was not very clear with my arguments, so I will try again;-) Please, don't take this as an attack against work that has been done. I think the contributions that have been made in the past were made in a good spirit. But I really believe, that the current solution for OSX has many shortcomings and should be changed as soon as possible. lock files --- The /var/lock folder does not exist on the standard OSX installation, however the standard installation includes several applications that use serial ports (i.e. the FAX capability). This indicates, that the lock folder approach will not work well with system components. Applications for OSX will generally try to live in harmony with system components (except for HP print drivers of course). I think RXTX should follow this approach as well. uucp group --- Accessing serial ports is not an admin privileged operation on OSX. Any user (world) has read/write privileges on /dev/tty*. So the system default is to not enforce any group membership to access these ports. The group uucp however is a system group on all unix systems I know. It exists for certain system processes. A non admin user should in general not be a member of this group. Quite arguably no user should ever be a member of this group. Installer --- My general opinion is, that - no Installer should touch user or group data without warning - no Application Installer should touch groups which are not specific to the very application installed - no Installer should ever add regular users to a system group The current installer injects the installing user in the group uucp without warning about this change and without giving the option to "opt out" of this change. This is a potential security risk (but not currently a real one, as OSX contains no folders belonging to group uucp). The current installer does not work for multi user systems. It puts the installing user in the uucp group. However the installing user is not necessarily the user that will use the application. Putting all users that may use a serial port application in the system group uucp seems like a very invasive approach to me. Besides that, newly created users will not automatically be in the group and hence, serial applications will "break" for new users without obvious reasons. Avoiding the lock files will allow self contained applications (i.e. drag&drop installation). In my eyes this is largely preferable over an installer that requests admin privileges. Adding up all these points indicates very strongly, that the lock-file implementation is not the way to go on OSX. Regards, Joachim On 22.03.2006, at 00:13, Dmitry Markman wrote: > I'd like to add that > > creating locking folder isn't a big deal > we never had a problem related to the lock folders, because we > always used installer on mac os x > from other hand I'm not very much familiar with iotcl locking > approach and I'm not sure it's more efficient > > Joachim wrote "I think it is the way to go, as it eliminates > creating the lock directory which doesnt exist on the standard > installation and it eliminates messing with the system group > definitions (adding users to group uucp)." but I really didn't have > any problem with that > > 1. doesn't exist on the standard installation > there are many-many things that don't exist in the standard > installation so I don't think that argument is strong enough > 2. messing with the system group definitions > I don't think we're messing with the group definition > mac os x provides very clear way to set up group's members and > together with Greg Guerin AuthKit there is no problem to set those > definitions > so I don't think that argument is strong either > but from other hand using iotcl is more promising and is more elegant > > > > On Mar 21, 2006, at 1:05 PM, Trent Jarvi wrote: > >> >> This looks like a good start. What do you think Dmitry? Perhaps >> all systems with TIOCEXCL defined should use that though. Even if >> they use lockfiles. It wont hurt anything. That would catch >> people hacking their own serial apps without checking lockfiles. > > Dmitry Markman > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From dmarkman at mac.com Wed Mar 22 05:27:13 2006 From: dmarkman at mac.com (Dmitry Markman) Date: Wed, 22 Mar 2006 07:27:13 -0500 Subject: [Rxtx] PATCH: use of ioctl(fd, TIOCEXCL) instead of lockfiles In-Reply-To: References: <923AE774-EEA2-4911-92D8-32BB27802C8B@buechse.de> Message-ID: <83440CF3-DCD8-41C1-B941-F227232C27E3@mac.com> thanks for the very good explanation I didn't think that you were attacking any thing, so don't worry I just had feeling, that there were more aesthetic reasons for going to ioctl then real necessity now you explained everything quite well (BTW, asfar as I remember installer asks admin password so it wasn't quiet, but it really doesn't matter now) thanks On Mar 22, 2006, at 6:46 AM, Joachim Buechse wrote: > Sorry, I was not very clear with my arguments, so I will try again;-) > > Please, don't take this as an attack against work that has been > done. I think the contributions that have been made in the past > were made in a good spirit. But I really believe, that the current > solution for OSX has many shortcomings and should be changed as > soon as possible. > > lock files > --- > The /var/lock folder does not exist on the standard OSX > installation, however the standard installation includes several > applications that use serial ports (i.e. the FAX capability). This > indicates, that the lock folder approach will not work well with > system components. Applications for OSX will generally try to live > in harmony with system components (except for HP print drivers of > course). I think RXTX should follow this approach as well. > > uucp group > --- > Accessing serial ports is not an admin privileged operation on OSX. > Any user (world) has read/write privileges on /dev/tty*. So the > system default is to not enforce any group membership to access > these ports. The group uucp however is a system group on all unix > systems I know. It exists for certain system processes. A non admin > user should in general not be a member of this group. Quite > arguably no user should ever be a member of this group. > > Installer > --- > My general opinion is, that > - no Installer should touch user or group data without warning > - no Application Installer should touch groups which are not > specific to the very application installed > - no Installer should ever add regular users to a system group > > The current installer injects the installing user in the group uucp > without warning about this change and without giving the option to > "opt out" of this change. This is a potential security risk (but > not currently a real one, as OSX contains no folders belonging to > group uucp). > > The current installer does not work for multi user systems. It puts > the installing user in the uucp group. However the installing user > is not necessarily the user that will use the application. Putting > all users that may use a serial port application in the system > group uucp seems like a very invasive approach to me. Besides that, > newly created users will not automatically be in the group and > hence, serial applications will "break" for new users without > obvious reasons. > > > Avoiding the lock files will allow self contained applications > (i.e. drag&drop installation). In my eyes this is largely > preferable over an installer that requests admin privileges. Adding > up all these points indicates very strongly, that the lock-file > implementation is not the way to go on OSX. > > Regards, > Joachim > > > On 22.03.2006, at 00:13, Dmitry Markman wrote: > >> I'd like to add that >> >> creating locking folder isn't a big deal >> we never had a problem related to the lock folders, because we >> always used installer on mac os x >> from other hand I'm not very much familiar with iotcl locking >> approach and I'm not sure it's more efficient >> >> Joachim wrote "I think it is the way to go, as it eliminates >> creating the lock directory which doesnt exist on the standard >> installation and it eliminates messing with the system group >> definitions (adding users to group uucp)." but I really didn't >> have any problem with that >> >> 1. doesn't exist on the standard installation >> there are many-many things that don't exist in the standard >> installation so I don't think that argument is strong enough >> 2. messing with the system group definitions >> I don't think we're messing with the group definition >> mac os x provides very clear way to set up group's members and >> together with Greg Guerin AuthKit there is no problem to set those >> definitions >> so I don't think that argument is strong either >> but from other hand using iotcl is more promising and is more elegant >> >> >> >> On Mar 21, 2006, at 1:05 PM, Trent Jarvi wrote: >> >>> >>> This looks like a good start. What do you think Dmitry? Perhaps >>> all systems with TIOCEXCL defined should use that though. Even >>> if they use lockfiles. It wont hurt anything. That would catch >>> people hacking their own serial apps without checking lockfiles. >> >> Dmitry Markman >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx Dmitry Markman From lyon at docjava.com Wed Mar 22 06:12:18 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Wed, 22 Mar 2006 08:12:18 -0500 Subject: [Rxtx] sole of a new design pattern Message-ID: Hi All, I have been thinking about how we design the serial port software. I think we need a new design pattern. For lack of a better term, I shall call it: The Parametric Singleton Design Pattern By Douglas A. Lyon ABSTRACT The goal of the singleton design pattern is to make sure that there is one, and only one, instance of a given class. The goal of the parametric singleton design pattern is to make sure that there is one, and only one, instance of a given class with the given parametric values. We parametric singleton design pattern combines the singleton design pattern with a parameter that enables unique creation of instances of a class. These instances are cached. When a user asks for an instance with these parameters, the cache is checked. If the instance is in the cache, the instance is returned, otherwise it is created, added to the cache and then returned. We apply our parametric singleton design pattern to the retrieval of RMI registries bound to a given port. The goal of our system is to make sure that no two RMI registries are listening to the same socket and to make use of the RMI registries after they have been created. RMI registries are used in distributed computation. Introduction The singleton design pattern is meant to ensure that on a single instance of a class exists. It is also meant to provide a global point of access to it. The intent of the parametric singleton design pattern is to ensure that a class has only one instance for a given set of parameter values. It also provides a global point of access to it. Motivation A system cannot tolerate multiple instances of some classes with identical parameters. For example, you cannot have two instances making use of the same serial port, at the same time. You cannot have two instances that are trying to listen to the same socket connection. You cannot have two instances writing to the same file structure at the same time. As the operating system is often thought of as the arbiter of consumed resources (i.e., tape drives, serial ports, etc.) we frequently leave it to an operating system implementation to resolve these contention issues. Even for similar resources (like serial ports) there are few standards for handling contention. For example, serial ports on Linux are locked using a "/var/lock" file. POSIX, on the other hand, uses ioctl mechanisms to prevent contention. A better solution is to make a class that is responsible for keeping track of the instances created from the class. The class is declared final, so that it cannot be subclassed. The class also has a private constructor, so that other classes cannot instance it. The new design pattern is called the parametric singleton design pattern and it provides a way to access and create instances with given parameters. Applicability Use the Parametric Singleton Design Pattern when: 1. There must be exactly one instance of a class with the given parameters. 2. The instances must be accessible to clients from a well-known access point. Structure Insert UML diagram here. Participants The Parametric Singleton Clients that need instances 1. The Parametric Singleton defines an instance upon request from a client, if, and only if, the instance does not already exist. 2. The Parametric Singleton returns the instance to the client. 3. The Parametric Singleton is responsible for creating unique instances from given parameters. Collaborations Clients obtain a reference to a Parametric Singleton instance only through the parametric singleton design pattern. If the instance is left in an improper state (e.g., the serial port was left open) it is NOT the role of the Parametric Singleton Design Pattern to close the IO port. Nor is it the role of the Parametric Singleton Design Pattern to open the port. That role is delegate to some other part of the system. Further, it is not the role of the Parametric Singleton Design Pattern to check out resources. That is, multiple threads can have multiple references to the same resource at the same time. MUTEX locking is delegated to some other part of the system. Consequences The Parametric Singleton Design Pattern has several benefits: 1. Controlled access to parametrically defined instances. Since the Parametric Singleton class encapsulates its instances, there is control over how and when clients access it. 2. Reduced name space. The Parametric Singleton pattern avoids global variables that store instances created from the same parameter. Implementation Here are implementation issues to consider when using the Parametric Singleton pattern: 1. Unique mapping of parameters. The Parametric Singleton pattern requires that there be a mean to isomorphically map the parameter space into the instance space and back again. 2. Ensure unique instances. The Parametric Singleton pattern makes unique instances from parameters, and it does so only once. 3. Cache instances for fast retrieval. The Parametric Singleton pattern must be able to look up instances, given some set of parameters, and do so from some data structure. That is, there must be enough space to hold references to all the instances the program will need. Also, a mechanism is needed to look up and retrieve the instances quickly enough to satisfy the clients. Sample Code public final class ParametricSingletonRmiRegistry { private static Hashtable registry = new Hashtable(100); // use singleton pattern and??????????????????????????????????????????????? // prevent instantiation of RmiRegistryUtils.?????????????????????????????? private ParametricSingletonRmiRegistry() { } // the only instance of the Registry held by the RmiRegistryUtils?????????? public static void listNames(Integer port) { if (!isInCacheAndRunning(port)) return; Registry r = (Registry) registry.get(port); System.out.println("registry on port: " + port); System.out.println("registry: " + r); System.out.println("names: "); try { print(r.list()); } catch (RemoteException e) { In.message(e); } System.out.println("------------------------"); } /**???????????????????????????????????????????????????????????????????????? * Checks whether a Registry has been started on this host????????????????? * in the specified port.?????????????????????????????????????????????????? * If not, it tries to start one.?????????????????????????????????????????? * when it fails to start a Registry, it exits the program????????????????? * with exit code 1.??????????????????????????????????????????????????????? */ public static void restart(int port) { if (isInCacheAndRunning(port)) return; try { startRegistry(port); } catch (RemoteException e) { In.message(e); } } /**???????????????????????????????????????????????????????????????????????? * @param port????????????????????????????????????????????????????????????? * @return true if registry is in cache and running???????????????????????? */ private static boolean isInCacheAndRunning(Integer port) { if (!isRegistryRunning(port.intValue())) return false; if (!isRegistryInCache(port.intValue())) return false; return true; } /**???????????????????????????????????????????????????????????????????????? * @param port????????????????????????????????????????????????????????????? * @return true if we are able to locate a local registry on port.??????????????????????????????????????????????????????????????????????????? */ private static boolean isRegistryRunning(int port) { try { Registry r = LocateRegistry.getRegistry(port); if (r != null) return true; } catch (RemoteException e) { return false; } return false; } /**???????????????????????????????????????????????????????????????????????? * @param port????????????????????????????????????????????????????????????? * @return return true if registry is in cache????????????????????????????? */ private static boolean isRegistryInCache(int port) { if (registry.get(new Integer(port)) == null) return false; return true; } /**???????????????????????????????????????????????????????????????????????? * Restart the registry, if needed.???????????????????????????????????????? * Return the only instance of the registry for consistent global?????????? * using by making use of the Singleton Design Pattern????????????????????? *????????????????????????????????????????????????????????????????????????? * @return the internally held registry instance.?????????????????????????? */ public static Registry getRegistry(Integer port) { restart(port); return (Registry) registry.get(port); } private static void startRegistry(Integer port) throws RemoteException { Registry r; try { r = LocateRegistry.createRegistry(port.intValue()); registry.put(port, r); //r = new sun.rmi.registry.RegistryImpl???????????????????????????? /// (port.intValue());?????????????????????????????????????? // registry.put(port, r);?????????????????????????????????????????? } catch (Exception e) { //e.printStackTrace();????????????????????????????????????????????? r = LocateRegistry.getRegistry(port.intValue()); registry.put(port, r); } } public static void main(String args[]) throws RemoteException { //restart(port);??????????????????????????????????????????????????????? restart(5001); restart(5002); restart(5002); Registry r = LocateRegistry.getRegistry(5002); System.out.println("registry="+r); } } I would very much like to get your feedback on this new design pattern idea. Thank you for your time. Regards, - Doug From david.garnier at trusted-logic.com Wed Mar 22 07:36:10 2006 From: david.garnier at trusted-logic.com (David Garnier) Date: Wed, 22 Mar 2006 15:36:10 +0100 Subject: [Rxtx] sole of a new design pattern In-Reply-To: References: Message-ID: <442160DA.80107@trusted-logic.com> Hello, > The Parametric Singleton Design Pattern The Singleton is the most abused design pattern ever. Good use-cases for this pattern are extremely rare and mostly confined to problems related to hardware resources, like serial ports. > Applicability > > Use the Parametric Singleton Design Pattern when: > 1. There must be exactly one instance of a class with the given > parameters. OK. As I said above, this case this actually very unusual. The Singleton pattern is mostly used when : > 2. The instances must be accessible to clients from a well-known > access point. Using the singleton pattern in this case is just convenient for the programmer. Problems arises pretty quickly, especially if you attempt to unit-test your classes. 1) If your singleton is stateful, or hold on to stateful objects, it means that two different unit tests are not actually independent. Instead of starting with a brand new environment, the result of a test may be affected by the result of a previous test. This problem also arise when with your class relies on a database. In both cases, the solution is to reset your "unique" resource (Singleton or database) at the beginning of the test, which is a pain. Also, while most projects connect to a single database, projects that allow the use of Singletons usually contain several of thems, and new ones may cropped up unnoticed. You quickly end up with test cases that only pass in a certain order, which is a royal pain. 2) You cannot mockup a singleton. Once everyone calls the SomeSingleton class statically, you can't replace your class by SomeSingletonMockup. Furthermore, even for hardware services, the Singleton pattern does not really prevent concurrent accesses. If you start the same program in two different JVMs, unless they somehow shared the state of their "Singletons" (through lock files for example), the Singleton pattern will not prevent concurrent access. Our application uses RXTX, and we routinely encounter cases where another (native) application has already locked the port. Since we cannot modify the native application to recognize lock files, OS-level control is irreplaceable. > > Consequences > The Parametric Singleton Design Pattern has several benefits: > > 1. Controlled access to parametrically defined instances. Since > the Parametric Singleton class encapsulates its instances, there is > control over how and when clients access it. Not really. Once you've returned the instance to a client, you've lost control over it. The client can to whatever it wants with it. You cannot "recall" the instance or claim it back. > 2. Reduced name space. The Parametric Singleton pattern avoids > global variables that store instances created from the same parameter. Sure, but you don't have to rely on a Singleton for that. Just create a single Factory. > I would very much like to get your feedback on this new design > pattern idea. Well, it's nothing new. Some may say that it is the point of design patterns: formalizes the designs that occur again and again. However, this design is simply a combination of the Singleton and Factory patterns. I did use it in the past, but now I've been exposed to the shortcomings of the Singleton pattern, so I limit myself to Factories. Regards, David From sean_montgomery at baseview.com Wed Mar 22 08:35:28 2006 From: sean_montgomery at baseview.com (Sean Montgomery) Date: Wed, 22 Mar 2006 10:35:28 -0500 Subject: [Rxtx] sole of a new design pattern In-Reply-To: <442160DA.80107@trusted-logic.com> References: <442160DA.80107@trusted-logic.com> Message-ID: <05769CA7-A51B-4CF0-BAA0-E02DD905F5A4@baseview.com> On Mar 22, 2006, at 9:36 AM, David Garnier wrote: > Furthermore, even for hardware services, the Singleton pattern does > not really prevent concurrent > accesses. If you start the same program in two different JVMs, > unless they somehow shared the state > of their "Singletons" (through lock files for example), the > Singleton pattern will not prevent > concurrent access. > Multiple class loaders in a single JVM can be tricky, too. Then there's synchronization, lazy initialization and serialization of singletons to contend with. Bloch's Effective Java covers these, and here's a few articles: http://www.javaworld.com/javaworld/jw-04-2003/jw-0425-designpatterns- p3.html http://java.sun.com/developer/technicalArticles/Programming/singletons/ Just FYI :-) From lyon at docjava.com Wed Mar 22 08:50:48 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Wed, 22 Mar 2006 10:50:48 -0500 Subject: [Rxtx] sole of a new design pattern In-Reply-To: <442160DA.80107@trusted-logic.com> References: <442160DA.80107@trusted-logic.com> Message-ID: Hi All, First, I would like to thank David for his prompt and thoughtful remarks. I had no idea people that feel strongly about a design patterns! Wow! Feedback (particularly critical feedback) is greatly appreciated. Starting at the end, first: >I did use it in >the past, but now I've been exposed to the shortcomings of the >Singleton pattern, so I limit myself to Factories. David, if I understood your comments correctly, you suggested that Factories can be used in leu of the Singleton Design Pattern, or even the Parametric Singleton Design Pattern. As I see in [Gof]: Factory Method: Intent "Define an interface for creating an object, but let subclasses decide which class to instantiate. Factory Method lets a class defer instantiation to subclasses." The Singleton Design Pattern is a concrete class, which is rather different, right? Also, subclasses are not permitted with Singleton, as they are final. Naturally, I could use an abstract factory as a parent for a singleton. I could even design a facade that could be implemented with the singleton....but that is not the intention of the design. Unless you want a mock-up, as discussed, below: More below: >Hello, > >> The Parametric Singleton Design Pattern > >The Singleton is the most abused design pattern ever. Good use-cases >for this pattern are extremely >rare and mostly confined to problems related to hardware resources, >like serial ports. > > >> Applicability >> >> Use the Parametric Singleton Design Pattern when: >> 1. There must be exactly one instance of a class with the given >> parameters. >OK. As I said above, this case this actually very unusual. The >Singleton pattern is mostly used when : >> 2. The instances must be accessible to clients from a well-known >> access point. > >Using the singleton pattern in this case is just convenient for the >programmer. Problems arises >pretty quickly, especially if you attempt to unit-test your classes. > >1) If your singleton is stateful, or hold on to stateful objects, it >means that two different unit >tests are not actually independent. Instead of starting with a brand >new environment, the result of >a test may be affected by the result of a previous test. This >problem also arise when with your >class relies on a database. In both cases, the solution is to reset >your "unique" resource >(Singleton or database) at the beginning of the test, which is a >pain. Also, while most projects >connect to a single database, projects that allow the use of >Singletons usually contain several of >thems, and new ones may cropped up unnoticed. You quickly end up >with test cases that only pass in a >certain order, which is a royal pain. There are basic problems with communicating finite state machines that include reachability and deadlock analysis. These are addressed with petri net analysis and are beyond the scope of the design pattern. As you quite rightly pointed out; the parametric singleton pattern (or the singleton pattern, for that matter) enable multiple threads to gain access to the same instance. The only way that I can see to block others from gaining access to the reference is the synchronize keyword. This is putting a spin-lock (or MUTEX) on the reference. The question of how to unit-test a design pattern like the parametric singleton remains open. Perhaps this is a deficiency. > >2) You cannot mockup a singleton. Once everyone calls the >SomeSingleton class statically, you can't >replace your class by SomeSingletonMockup. Acutally, I am not sure that this is true. If the Singleton implements a Facade interface, it should be possible to make the replacement. Right? > >Furthermore, even for hardware services, the Singleton pattern does >not really prevent concurrent >accesses. If you start the same program in two different JVMs, >unless they somehow shared the state >of their "Singletons" (through lock files for example), the >Singleton pattern will not prevent >concurrent access. Good Point!! You have sharp eyes! The singleton design pattern should/could take responsibility for this. In fact, you may notice that my code does have an implementation (LocateRegistry) that can work across JVM's. The LocateRegistry will even work across the Internet! LocateRegistry takes both a host name and a Port (lock files just don't do this). I did not think to implement this beyond the local machine, but, in its present form, it will work across different processes. > >Our application uses RXTX, and we routinely encounter cases where >another (native) application has >already locked the port. Since we cannot modify the native >application to recognize lock files, >OS-level control is irreplaceable. The singleton design pattern is not meant to replace OS-level control, but to centralize the Java programmers access to it. If lock files, for example, are used for serial ports, the Singleton Design Pattern should be able to work with them. > > >> >> Consequences >> The Parametric Singleton Design Pattern has several benefits: >> > > 1. Controlled access to parametrically defined instances. Since >> the Parametric Singleton class encapsulates its instances, there is >> control over how and when clients access it. > >Not really. Once you've returned the instance to a client, you've >lost control over it. The client >can to whatever it wants with it. You cannot "recall" the instance >or claim it back. Good point, this should read: > 1. Controll when parametrically defined instances are created. Since > > the Parametric Singleton class encapsulates its instances, there is > > control over how and when they are instanced. > >> 2. Reduced name space. The Parametric Singleton pattern avoids >> global variables that store instances created from the same parameter. > >Sure, but you don't have to rely on a Singleton for that. Just >create a single Factory. > > Thank you for your thoughtful and prompt response! Regards, - Doug From dmarkman at mac.com Wed Mar 22 21:21:55 2006 From: dmarkman at mac.com (Dmitry Markman) Date: Wed, 22 Mar 2006 23:21:55 -0500 Subject: [Rxtx] sole of a new design pattern In-Reply-To: <442160DA.80107@trusted-logic.com> References: <442160DA.80107@trusted-logic.com> Message-ID: I don't think I get it On Mar 22, 2006, at 9:36 AM, David Garnier wrote: > Using the singleton pattern in this case is just convenient for the > programmer. Problems arises > pretty quickly, especially if you attempt to unit-test your classes. so you're saying that something isn't so good because you can not test it in the convenient way? if that's true, I'm totally disagree change your test, debug whatever, but if software is efficient at runtime, works fine and only problem is some unit test (which is some kind of framework for testing) then dump that unit test , dump that unit framework and make something appropriate to the software you're testing so if Douglas want to use singletons, what's the problem? and what do you mean by abusing of singleton usage? of course singleton doesn't prevent concurrent access to the resource across the processes unless you're using some OS facility to prevent it, besides singleton as it was introduced is relevant only and only inside of the same process otherwise it's not singleton it's something else (let's say network singleton: so you have remote invocation facility and some factory method that return object created by that facility) I don't have any problem with using any kind of singletons. Parametric Singleton idea (if I understand it right) could be easily implemented in the following way: use a map populate map with instances of some class and key is your parameter (you can use lazy population too) if somebody ask the key check the value if it's null so resource is taken if somebody returns the resource put it back to the map public synchronized static Object getSomeResource(Object parameter); public synchronized static void returnResource(Object parameter); getSomeResource (inside of the same process) could return null in 2 cases 1. if somebody (from other thread for example) already took that resource 2. if OS API said that resource corresponded to that parameter (serial port with parameter = 1 (port #)) is locked and unavailable; I'm not sure that in case of serial ports we even need those Parametric Singletons (unless lock checking is a very expensive operation) just ask the OS about availability of that resource and if it's available give it away and then OS will lock it and therefore in next time somebody ask it just answer that resource is locked and return null for example system has 2 serial ports available so I ask getResource("tty"); or I ask getResource("Bluetooth-Modem"); and if OS is ok you can give tty or Bluetooth-Modem or both no need for any additional pattern I think back to the problem mac os x doesn't recognize locking via files, so it handles locking via some API an instance of the singleton in each process should recognize that resource is locked (by using that API) that's all we don't have to make things more complicate then they are just because there is some nice design pattern or nice unit test framework or whatever keep things simple, make them work fast, don't introduce middle layers unless you have really good reason to do so of course I could be entirely wrong, so sorry about that in advance thanks Dmitry Markman From tjarvi at qbang.org Wed Mar 22 22:31:41 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 22 Mar 2006 22:31:41 -0700 (MST) Subject: [Rxtx] sole of a new design pattern In-Reply-To: References: Message-ID: Hi Doug Interesting reading. So far I'm just reading and thinking. I have one question so far. " Clients obtain a reference to a Parametric Singleton instance only through the parametric singleton design pattern. If the instance is left in an improper state (e.g., the serial port was left open) it is NOT the role of the Parametric Singleton Design Pattern to close the IO port. Nor is it the role of the Parametric Singleton Design Pattern to open the port. That role is delegate to some other part of the system. " So when the clients obtain a reference to the singleton, can they assume the port is there? IE, would it be the singletons role to handle things like USB dongles being removed with event hints comming from the underlying OS. Hardware abstraction layer/HAL on Linux is an example of underlying OS events. I assume that role too is delegated to other parts of the system? -- Trent Jarvi tjarvi at qbang.org From lyon at docjava.com Thu Mar 23 08:10:33 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Thu, 23 Mar 2006 10:10:33 -0500 Subject: [Rxtx] Classes don't need goals, they need roles! In-Reply-To: References: Message-ID: Hi Trent, Yes, I think that the role of the Parametric Singleton Pattern is not to open or close serial ports, nor is it to perform error checking. On the other hand, if you were to combine the role of the Parametric Singleton Pattern with another role (like that of error checking) it might not be amiss. However, I generally caution programmers against adding multiple roles to classes, as this leads to monolithic designs. Thus a different class (NativeLibDetect) could have the role of determining if the native library can be loaded. Another class (SerialPortBean) can have the role of serializing the default state of the serial port, so that it can be recovered, from user preferences, at a later time. The SerialPortDetect could have the role of determining if the serial port is removed (i.e., a USB port was unplugged). My guess is that each class should have a different role in the system, in order to ease maintenance and testing...but I could be wrong about that. Thanks! - Doug >Hi Doug > >Interesting reading. So far I'm just reading and thinking. I have >one question so far. > >" > Clients obtain a reference to a Parametric Singleton instance only >through the parametric singleton design pattern. If the instance is >left in an improper state (e.g., the serial port was left open) it is >NOT the role of the Parametric Singleton Design Pattern to close the >IO port. Nor is it the role of the Parametric Singleton Design Pattern >to >open the port. That role is delegate to some other part of the system. >" > >So when the clients obtain a reference to the singleton, can they >assume the port is there? IE, would it be the singletons role to >handle things like USB dongles being removed with event hints >comming from the underlying OS. Hardware abstraction layer/HAL on >Linux is an example of underlying OS events. > >I assume that role too is delegated to other parts of the system? > >-- >Trent Jarvi >tjarvi at qbang.org >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From maximulo at yahoo.com Fri Mar 24 01:22:38 2006 From: maximulo at yahoo.com (Maximulo Majir) Date: Fri, 24 Mar 2006 00:22:38 -0800 (PST) Subject: [Rxtx] JavaPOS Message-ID: <20060324082238.66371.qmail@web38214.mail.mud.yahoo.com> Hi all! Hello Trent! From what i understand, RXTX or JavaComm APIs were not created solely for JavaPOS. In JavaPOS, we have the virtual method claim() which is separate from open(), but in our RXTX API, claiming is done every call to open(), we cant open the port if its claimed by another application. Would it be alright to suggest or ask to create a new method called claim(..)? Is there such thing as forceclaim() in RXTX? this could be the same as portownership transfer or its equivalent. ForceClaim is in JSR80. Do you have some samples using RXTX as the lower layer for the Device Service Objects in JavaPOS? I have tried it, i just want to compare. Thank you all! maxim __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060324/496adba2/attachment-0012.html From tjarvi at qbang.org Fri Mar 24 11:28:19 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 24 Mar 2006 11:28:19 -0700 (MST) Subject: [Rxtx] Re: RXTX 2.1 Solaris Problems In-Reply-To: <3691.1143210578@www045.gmx.net> References: <3691.1143210578@www045.gmx.net> Message-ID: On Fri, 24 Mar 2006, Andreas Guenther wrote: > Hi all, > > the solaris problem was not the lock file only. > > Ok, I had to create the directory /var/spool/locks myself. > /var/spool/uucp exists. > > But rxtx didn't find any port. > > I compiled the source with my own debug-informations > and I tried to isolate the problem. > > The problem is the testRead-call in SerialImp.c > > JNIEXPORT jboolean JNICALL RXTXCommDriver(testRead)( > > ... > if ( READ( fd, &c, 1 ) < 0 ) > { > if ( errno != EAGAIN ) { > report( "testRead() read failed\n" ); > ret = JNI_FALSE; > } > } > Thanks Andreas I'm packing up to move. I'll be more or less away for a couple weeks here. I'll be checking email but my workstation is going into a box soon. This isn't hard to fix as this port should be enumerated when EWOULDBLOCK is recieved. Thats error is OK for enumeration just as EAGAIN is. I've put the bug into bugzilla so we dont forget to get to it. http://bugzilla.qbang.org/show_bug.cgi?id=42 You can add yourself to the CC list if you wish to test fixes we provide or even put a patch into bugzilla yourself. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Fri Mar 24 11:51:52 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 24 Mar 2006 11:51:52 -0700 (MST) Subject: [Rxtx] JavaPOS In-Reply-To: <20060324082238.66371.qmail@web38214.mail.mud.yahoo.com> References: <20060324082238.66371.qmail@web38214.mail.mud.yahoo.com> Message-ID: On Fri, 24 Mar 2006, Maximulo Majir wrote: > Hi all! Hello Trent! > > > From what i understand, RXTX or JavaComm APIs were not > created solely for JavaPOS. In JavaPOS, we have the virtual method > claim() which is separate from open(), but in our RXTX API, claiming is > done every call to open(), we cant open the port if its claimed by > another application. Would it be alright to suggest or ask to create a > new method called claim(..)? Is there such thing as forceclaim() in > RXTX? this could be the same as portownership transfer or its > equivalent. ForceClaim is in JSR80. > Do you have some samples using RXTX as the lower layer for the Device > Service Objects in JavaPOS? I have tried it, i just want to compare. > maxim Hi Maxim JSR80 is the USB API IBM/Sun put together. The problem is they have a richer kernel/API underneath that can handle such things. With Serial Ports, there isnt anything there other than an ioctl that says don't let anyone touch this and lockfiles that are more of a 'lets be nice.' At times we may be using USB ports but it is through the termios layer with the limitations mentioned. The advantage is that not only USB will work with rxtx. Anything that has a termios layer should work (to the extent that termios layer is complete). I don't know how forceclaim() would help you. Lets say someone has a programmer working on /dev/ttyS0 and you take it. Now you both race each other to read data first. There isn't a mechanism I know of that will solve this problem in termios. The most obvious test being a native app and a Java app trying to take the port. There is the potential of requestion ownership from other Java Applications but the use for that is very rare. Did you have something more specific in mind that I'm missing? I'm not sure that claim() and forceclaim() would help you with rxtx other than maybe locking the port with claim() without opening it. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sat Mar 25 23:42:08 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 25 Mar 2006 23:42:08 -0700 (MST) Subject: [Rxtx] Serial snoop Message-ID: I was reading the Linux kernel mail-list tonight and ran past a thread that mentioned sersnoop. This looks like a handy tool for people dealing with new toys. "a simple command-line tool for linux that echoes bytes to and from any two serial ports, ptys, or network sockets, and prints all traffic to stdout, in hex and ascii." http://www.restivo.org/projects/sersnoop/ It works on Linux only at this time (debian package available). -- Trent Jarvi tjarvi at qbang.org From beat.arnet at gmail.com Sun Mar 26 07:32:35 2006 From: beat.arnet at gmail.com (Beat Arnet) Date: Sun, 26 Mar 2006 09:32:35 -0500 Subject: [Rxtx] Error 0x5 at /home/bob/foo/tar/rxtx-2.1-7/build/../src/termios.c(860): Access is, denied. Message-ID: <4426A603.80508@gmail.com> Dear all, When trying to open the serial port, I sometimes (not always) run into the following exception (when opening the serialPort): Error 0x5 at /home/bob/foo/tar/rxtx-2.1-7/build/../src/termios.c(860): Access is denied. java.lang.UnsatisfiedLinkError: native_psmisc_report_owner at gnu.io.CommPortIdentifier.native_psmisc_report_owner(Native Method) at gnu.io.CommPortIdentifier.open(CommPortIdentifier.java:354) at codeskin.tools.CLLoader.open(CLLoader.java:79) at codeskin.tools.C2000Programmer.run(C2000Programmer.java:220) at java.lang.Thread.run(Unknown Source) Is this the type of error where I should just try to open the port again, or can it be avoided? Regards, Beat From tjarvi at qbang.org Sun Mar 26 11:40:12 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 26 Mar 2006 11:40:12 -0700 (MST) Subject: [Rxtx] Error 0x5 at /home/bob/foo/tar/rxtx-2.1-7/build/../src/termios.c(860): Access is, denied. In-Reply-To: <4426A603.80508@gmail.com> References: <4426A603.80508@gmail.com> Message-ID: On Sun, 26 Mar 2006, Beat Arnet wrote: > Dear all, > > When trying to open the serial port, I sometimes (not always) run into > the following exception (when opening the serialPort): > > Error 0x5 at /home/bob/foo/tar/rxtx-2.1-7/build/../src/termios.c(860): > Access is > denied. > > java.lang.UnsatisfiedLinkError: native_psmisc_report_owner > at gnu.io.CommPortIdentifier.native_psmisc_report_owner(Native > Method) > at gnu.io.CommPortIdentifier.open(CommPortIdentifier.java:354) > at codeskin.tools.CLLoader.open(CLLoader.java:79) > at codeskin.tools.C2000Programmer.run(C2000Programmer.java:220) > at java.lang.Thread.run(Unknown Source) > > Is this the type of error where I should just try to open the port again, > or can it be avoided? > Hi Beat We did a second build of rxtx 2.1-7 to resolve that unsatisfied link error. It should work now. rxtx is trying to tell you it thinks someone else has the serial port open. You can try to open the port again but maybe you already have a copy of the program running when it happens? ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7r2.zip fixed build. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sun Mar 26 11:44:23 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 26 Mar 2006 11:44:23 -0700 (MST) Subject: [Rxtx] RXTX spec file (fwd) Message-ID: This is probably interesting for fedora/suse users. ---------- Forwarded message ---------- Date: Sun, 26 Mar 2006 16:25:45 +0200 To: taj at www.linux.org.uk Subject: RXTX spec file I send you this spec file which allows to create a RPM for Fedora 4, 5 (x86, x86_64) with Java Sun. -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: rxtx.spec Url: http://mailman.qbang.org/pipermail/rxtx/attachments/20060326/6c7b6af6/rxtx-0008.pl From tjarvi at qbang.org Sun Mar 26 23:42:59 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 26 Mar 2006 23:42:59 -0700 (MST) Subject: [Rxtx] Upcomming events. Message-ID: This Wednesday we will be announcing a new "Maintainer" for the rxtx project. The position is more like neutral leader. I wont be going away or doing less. This is just the right thing to do as it turns out the two people with CVS write access will be at the same company. We need a third and we need neutrality. The maintainer will have final say in any conflict and will try to be neutral. It will be open for discussion. Then we will do it :) I'll still do most of the footwork I do now. But. I'm falling behind. I should have gone through the mail-list and posted the next round of changes this weekend. I'm packing to move and its going so so - 13 years of toys collected. I suspect there will be a dead period on my part (a couple weeks) comming up. But if you get it on the mail-list, we will get it in if there are no objections. I may well not be reading the mail-list during this period as I look for a house and many other things. I hope everyone will help out. Thanks -- Trent Jarvi tjarvi at qbang.org From mahmoud_hadad at yahoo.com Sun Mar 26 07:31:19 2006 From: mahmoud_hadad at yahoo.com (ronan nick) Date: Sun, 26 Mar 2006 06:31:19 -0800 (PST) Subject: [Rxtx] a question about the COMM API Message-ID: <20060326143119.54919.qmail@web60014.mail.yahoo.com> hi, i was intrested in knowing how i can communicate with my internal modem using java? for example if i want to make a phone dialer application or a caller id application where should i be looking at? and as i understood the COMM API is for devices that is attached to the computer through serial ports. --------------------------------- New Yahoo! Messenger with Voice. Call regular phones from your PC and save big. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060326/ce8329f0/attachment-0010.html From dmarkman at mac.com Mon Mar 20 00:20:43 2006 From: dmarkman at mac.com (Dmitry Markman) Date: Mon, 20 Mar 2006 02:20:43 -0500 Subject: [Rxtx] Mac OS X RXTX java installer In-Reply-To: References: <07D0DE29-BA32-4CFE-B036-66BC6423D385@buechse.de> <441AE3E0.2030503@willicon.de> <12531986.1142622114996.JavaMail.dmarkman@mac.com> <441B2674.9010409@willicon.de> <13577405.1142634732776.JavaMail.dmarkman@mac.com> <441B4182.8010407@willicon.de> <92CD0D6C-5BE8-426E-A46D-99452059FF49@mac.com> <441BBB2D.8030305@willicon.de> <441C4088.5090905@willicon.de> Message-ID: <64BC1E23-FDDE-4CE6-8863-CFC881CBC224@mac.com> Hi all I put RXTX installer that will install everything (and will create / var/lock if necessary and add user to the uucp group) for mac os x from Java into the rxtx's CVS repository it could be easily modified to install files for any platform it uses Greg Guerin's AuthKit for authentication and authorization Greg released that kit under artistic license, so Trent, please take a look we, probably, can negotiate license with Greg if it's necessary Greg's AuthKit could be downloaded from http://www.amug.org/~glguerin/ sw/#authkit Michael Hall (mikehall at spacestar dot net) had a suggestion to make implementation of the jaas LoginModule based on Greg's AuthKit (his modification of the Greg's AuthKit could be found at http:// www.spacestar.net/users/mikehall/authkit.dmg) but Michael's AuthKitLoginModule does only half a job: it does authenticate but it can not run any external unix process in privileged mode (at least I wasn't able to do so) possible explanation could be found in conversation between Greg and Michael at Apple's java-dev list (look for archives) so I didn't use jaas API for rxtxinstaller I created folder MacOSX in the contrib folder comment 1. if you want to run that installer as standalone application all you need that RXTXInstaller.jar 2. if you want to use webstart you have to add Greg's libAuthKit.jnilib to the mac os x's resources in theory RXTXInstaller.jar doesn't need it, but there is a problem with loading libAuthKit.jnilib from webstart authkit uses loadLibrary method to load library and it failed (from webstart) for standalone application I extract libAuthKit.jnilib from the RXTXInstaller.jar and put it into the /Library/Java/Extensions or ~/Library/Java/Extensions folder that file will be deleted after installer quit unfortunately I didn't have time to put documentation there but it is mostly self-explanatory I took installer code from my gl4java installer that I did about 3 years ago (with small modifications) it would be very nice if Apple will release LoginModule that really will do the job (com.apple.security.auth.module package????? ) (UnixLoginModule is pretty useless) From lyon at docjava.com Mon Mar 20 06:34:39 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Mon, 20 Mar 2006 08:34:39 -0500 Subject: [Rxtx] Mac OS X RXTX java installer In-Reply-To: <64BC1E23-FDDE-4CE6-8863-CFC881CBC224@mac.com> References: <07D0DE29-BA32-4CFE-B036-66BC6423D385@buechse.de> <441AE3E0.2030503@willicon.de> <12531986.1142622114996.JavaMail.dmarkman@mac.com> <441B2674.9010409@willicon.de> <13577405.1142634732776.JavaMail.dmarkman@mac.com> <441B4182.8010407@willicon.de> <92CD0D6C-5BE8-426E-A46D-99452059FF49@mac.com> <441BBB2D.8030305@willicon.de> <441C4088.5090905@willicon.de> <64BC1E23-FDDE-4CE6-8863-CFC881CBC224@mac.com> Message-ID: Hi Dimitry, This sounds like great work. Just a couple of questions; After the check out of the CVS files, using: setenv CVSROOT :pserver:anonymous at cvs.milestonesolutions.com:/usr/local/cvsroot 53 8:28 setenv PASSWORD mousy 54 8:29 cvs login 55 8:29 cvs checkout rxtx-devel I cd'd over to: rxtx-devel/MACOSX_IDE And found: CVS/ CW/ ForPackageMaker/ PB/ Where is the installer? Thanks! - Doug From tjarvi at qbang.org Mon Mar 20 06:39:37 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 20 Mar 2006 06:39:37 -0700 (MST) Subject: [Rxtx] Mac OS X RXTX java installer In-Reply-To: References: <07D0DE29-BA32-4CFE-B036-66BC6423D385@buechse.de> <441AE3E0.2030503@willicon.de> <12531986.1142622114996.JavaMail.dmarkman@mac.com> <441B2674.9010409@willicon.de> <13577405.1142634732776.JavaMail.dmarkman@mac.com> <441B4182.8010407@willicon.de> <92CD0D6C-5BE8-426E-A46D-99452059FF49@mac.com> <441BBB2D.8030305@willicon.de> <441C4088.5090905@willicon.de> <64BC1E23-FDDE-4CE6-8863-CFC881CBC224@mac.com> Message-ID: On Mon, 20 Mar 2006, Dr. Douglas Lyon wrote: > Hi Dimitry, > This sounds like great work. Just a couple of questions; > After the check out of the CVS files, using: > setenv CVSROOT > :pserver:anonymous at cvs.milestonesolutions.com:/usr/local/cvsroot > 53 8:28 setenv PASSWORD mousy > 54 8:29 cvs login > 55 8:29 cvs checkout rxtx-devel Hi Doug You want "cvs checkout -r commapi-0-0-1 rxtx-devel" to get RXTX 2.1 The default branch is rxtx 2.0 which isn't very active right now. -- Trent Jarvi tjarvi at qbang.org From lyon at docjava.com Mon Mar 20 07:05:44 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Mon, 20 Mar 2006 09:05:44 -0500 Subject: [Rxtx] Mac OS X RXTX java installer In-Reply-To: References: <07D0DE29-BA32-4CFE-B036-66BC6423D385@buechse.de> <441AE3E0.2030503@willicon.de> <12531986.1142622114996.JavaMail.dmarkman@mac.com> <441B2674.9010409@willicon.de> <13577405.1142634732776.JavaMail.dmarkman@mac.com> <441B4182.8010407@willicon.de> <92CD0D6C-5BE8-426E-A46D-99452059FF49@mac.com> <441BBB2D.8030305@willicon.de> <441C4088.5090905@willicon.de> <64BC1E23-FDDE-4CE6-8863-CFC881CBC224@mac.com> Message-ID: Hi Trent, Thanks for the info on the CVS checkout procedure. I did that and am still not sure where the installer is. Here is what I have: cd MACOSX_IDE/ p4.docjava.com{lyon}121: ls CVS/ ForPackageMaker/ PB/ p4.docjava.com{lyon}122: find . | more . ./ForPackageMaker ./ForPackageMaker/RXTX.pkg.sit.hqx ./ForPackageMaker/Resources ./ForPackageMaker/Resources/ReadMe.rtf ./ForPackageMaker/Resources/Welcome.rtf ./ForPackageMaker/Resources/CVS ./ForPackageMaker/Resources/CVS/Entries ./ForPackageMaker/Resources/CVS/Repository ./ForPackageMaker/Resources/CVS/Tag ./ForPackageMaker/Resources/CVS/Root ./ForPackageMaker/Resources/preinstall ./ForPackageMaker/Resources/License.rtf ./ForPackageMaker/Resources/preupgrade ./ForPackageMaker/RXTX.pmsp ./ForPackageMaker/CVS ./ForPackageMaker/CVS/Entries ./ForPackageMaker/CVS/Repository ./ForPackageMaker/CVS/Entries.Log ./ForPackageMaker/CVS/Tag ./ForPackageMaker/CVS/Root ./ForPackageMaker/RXTX_Tiger.pkg.sitx.hqx ./ForPackageMaker/RXTX_Jag.pkg.sit.hqx ./ForPackageMaker/Install ./ForPackageMaker/Install/CVS ./ForPackageMaker/Install/CVS/Entries ./ForPackageMaker/Install/CVS/Repository ./ForPackageMaker/Install/CVS/Tag ./ForPackageMaker/Install/CVS/Root ./ForPackageMaker/Install/Library ./ForPackageMaker/Install/Library/CVS ./ForPackageMaker/Install/Library/CVS/Entries ./ForPackageMaker/Install/Library/CVS/Repository ./ForPackageMaker/Install/Library/CVS/Tag ./ForPackageMaker/Install/Library/CVS/Root ./ForPackageMaker/Install/Library/Java ./ForPackageMaker/Install/Library/Java/Extensions ./ForPackageMaker/Install/Library/Java/Extensions/RXTXcomm.jar ./ForPackageMaker/Install/Library/Java/Extensions/CVS ./ForPackageMaker/Install/Library/Java/Extensions/CVS/Entries ./ForPackageMaker/Install/Library/Java/Extensions/CVS/Repository ./ForPackageMaker/Install/Library/Java/Extensions/CVS/Tag ./ForPackageMaker/Install/Library/Java/Extensions/CVS/Root ./ForPackageMaker/Install/Library/Java/Extensions/librxtxSerial.jnilib ./ForPackageMaker/Install/Library/Java/CVS ./ForPackageMaker/Install/Library/Java/CVS/Entries ./ForPackageMaker/Install/Library/Java/CVS/Repository ./ForPackageMaker/Install/Library/Java/CVS/Entries.Log ./ForPackageMaker/Install/Library/Java/CVS/Tag ./ForPackageMaker/Install/Library/Java/CVS/Root ./ForPackageMaker/RXTX_Tiger.pmproj.sitx.hqx ./CVS ./CVS/Entries ./CVS/Repository ./CVS/Entries.Log ./CVS/Tag ./CVS/Root ./PB ./PB/LibSerialUniversal.xcodeproj.sitx.hqx ./PB/CVS ./PB/CVS/Entries ./PB/CVS/Repository ./PB/CVS/Entries.Log ./PB/CVS/Tag ./PB/CVS/Root ./PB/LibSerial.pbproj.sit.hqx ./PB/startpoint.c ./PB/config.h What is the procedure to run this installer? Do we need a README in: /rxtx-devel/MACOSX_IDE Here is what we have: CVS/ ForPackageMaker/ PB/ Thanks! - DL >On Mon, 20 Mar 2006, Dr. Douglas Lyon wrote: > >>Hi Dimitry, >>This sounds like great work. Just a couple of questions; >>After the check out of the CVS files, using: >>setenv CVSROOT >>:pserver:anonymous at cvs.milestonesolutions.com:/usr/local/cvsroot >> 53 8:28 setenv PASSWORD mousy >> 54 8:29 cvs login >> 55 8:29 cvs checkout rxtx-devel > >Hi Doug > >You want "cvs checkout -r commapi-0-0-1 rxtx-devel" to get RXTX 2.1 >The default branch is rxtx 2.0 which isn't very active right now. > >-- >Trent Jarvi >tjarvi at qbang.org From tjarvi at qbang.org Mon Mar 20 07:25:30 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 20 Mar 2006 07:25:30 -0700 (MST) Subject: [Rxtx] Mac OS X RXTX java installer In-Reply-To: References: <07D0DE29-BA32-4CFE-B036-66BC6423D385@buechse.de> <441AE3E0.2030503@willicon.de> <12531986.1142622114996.JavaMail.dmarkman@mac.com> <441B2674.9010409@willicon.de> <13577405.1142634732776.JavaMail.dmarkman@mac.com> <441B4182.8010407@willicon.de> <92CD0D6C-5BE8-426E-A46D-99452059FF49@mac.com> <441BBB2D.8030305@willicon.de> <441C4088.5090905@willicon.de> <64BC1E23-FDDE-4CE6-8863-CFC881CBC224@mac.com> Message-ID: On Mon, 20 Mar 2006, Dr. Douglas Lyon wrote: > Hi Trent, > Thanks for the info on the CVS checkout procedure. > I did that and am still not sure where the installer is. Hi Doug It does look like it was not cvs committed. There is no rxtx-devel/contrib/MacOSX directory in there at the moment. It was mentioned that it was put under contrib. -- Trent Jarvi tjarvi at qbang.org From dmarkman at mac.com Mon Mar 20 07:29:56 2006 From: dmarkman at mac.com (Dmitry Markman) Date: Mon, 20 Mar 2006 09:29:56 -0500 Subject: [Rxtx] Mac OS X RXTX java installer In-Reply-To: References: <07D0DE29-BA32-4CFE-B036-66BC6423D385@buechse.de> <441AE3E0.2030503@willicon.de> <12531986.1142622114996.JavaMail.dmarkman@mac.com> <441B2674.9010409@willicon.de> <13577405.1142634732776.JavaMail.dmarkman@mac.com> <441B4182.8010407@willicon.de> <92CD0D6C-5BE8-426E-A46D-99452059FF49@mac.com> <441BBB2D.8030305@willicon.de> <441C4088.5090905@willicon.de> <64BC1E23-FDDE-4CE6-8863-CFC881CBC224@mac.com> Message-ID: <6054EB4E-F7E0-4A9C-BDDA-D582D6D8826F@mac.com> you can find it in the rxtx-devel/contrib folder On Mar 20, 2006, at 9:05 AM, Dr. Douglas Lyon wrote: > Hi Trent, > Thanks for the info on the CVS checkout procedure. > I did that and am still not sure where the installer is. > Here is what I have: > cd MACOSX_IDE/ > p4.docjava.com{lyon}121: ls > CVS/ ForPackageMaker/ PB/ > p4.docjava.com{lyon}122: find . | more > . > ./ForPackageMaker > ./ForPackageMaker/RXTX.pkg.sit.hqx > ./ForPackageMaker/Resources > ./ForPackageMaker/Resources/ReadMe.rtf > ./ForPackageMaker/Resources/Welcome.rtf > ./ForPackageMaker/Resources/CVS > ./ForPackageMaker/Resources/CVS/Entries > ./ForPackageMaker/Resources/CVS/Repository > ./ForPackageMaker/Resources/CVS/Tag > ./ForPackageMaker/Resources/CVS/Root > ./ForPackageMaker/Resources/preinstall > ./ForPackageMaker/Resources/License.rtf > ./ForPackageMaker/Resources/preupgrade > ./ForPackageMaker/RXTX.pmsp > ./ForPackageMaker/CVS > ./ForPackageMaker/CVS/Entries > ./ForPackageMaker/CVS/Repository > ./ForPackageMaker/CVS/Entries.Log > ./ForPackageMaker/CVS/Tag > ./ForPackageMaker/CVS/Root > ./ForPackageMaker/RXTX_Tiger.pkg.sitx.hqx > ./ForPackageMaker/RXTX_Jag.pkg.sit.hqx > ./ForPackageMaker/Install > ./ForPackageMaker/Install/CVS > ./ForPackageMaker/Install/CVS/Entries > ./ForPackageMaker/Install/CVS/Repository > ./ForPackageMaker/Install/CVS/Tag > ./ForPackageMaker/Install/CVS/Root > ./ForPackageMaker/Install/Library > ./ForPackageMaker/Install/Library/CVS > ./ForPackageMaker/Install/Library/CVS/Entries > ./ForPackageMaker/Install/Library/CVS/Repository > ./ForPackageMaker/Install/Library/CVS/Tag > ./ForPackageMaker/Install/Library/CVS/Root > ./ForPackageMaker/Install/Library/Java > ./ForPackageMaker/Install/Library/Java/Extensions > ./ForPackageMaker/Install/Library/Java/Extensions/RXTXcomm.jar > ./ForPackageMaker/Install/Library/Java/Extensions/CVS > ./ForPackageMaker/Install/Library/Java/Extensions/CVS/Entries > ./ForPackageMaker/Install/Library/Java/Extensions/CVS/Repository > ./ForPackageMaker/Install/Library/Java/Extensions/CVS/Tag > ./ForPackageMaker/Install/Library/Java/Extensions/CVS/Root > ./ForPackageMaker/Install/Library/Java/Extensions/librxtxSerial.jnilib > ./ForPackageMaker/Install/Library/Java/CVS > ./ForPackageMaker/Install/Library/Java/CVS/Entries > ./ForPackageMaker/Install/Library/Java/CVS/Repository > ./ForPackageMaker/Install/Library/Java/CVS/Entries.Log > ./ForPackageMaker/Install/Library/Java/CVS/Tag > ./ForPackageMaker/Install/Library/Java/CVS/Root > ./ForPackageMaker/RXTX_Tiger.pmproj.sitx.hqx > ./CVS > ./CVS/Entries > ./CVS/Repository > ./CVS/Entries.Log > ./CVS/Tag > ./CVS/Root > ./PB > ./PB/LibSerialUniversal.xcodeproj.sitx.hqx > ./PB/CVS > ./PB/CVS/Entries > ./PB/CVS/Repository > ./PB/CVS/Entries.Log > ./PB/CVS/Tag > ./PB/CVS/Root > ./PB/LibSerial.pbproj.sit.hqx > ./PB/startpoint.c > ./PB/config.h > > What is the procedure to run this installer? > Do we need a README in: > /rxtx-devel/MACOSX_IDE > Here is what we have: > CVS/ ForPackageMaker/ PB/ > > > Thanks! > - DL > >> On Mon, 20 Mar 2006, Dr. Douglas Lyon wrote: >> >>> Hi Dimitry, >>> This sounds like great work. Just a couple of questions; >>> After the check out of the CVS files, using: >>> setenv CVSROOT :pserver:anonymous at cvs.milestonesolutions.com:/usr/ >>> local/cvsroot >>> 53 8:28 setenv PASSWORD mousy >>> 54 8:29 cvs login >>> 55 8:29 cvs checkout rxtx-devel >> >> Hi Doug >> >> You want "cvs checkout -r commapi-0-0-1 rxtx-devel" to get RXTX 2.1 >> The default branch is rxtx 2.0 which isn't very active right now. >> >> -- >> Trent Jarvi >> tjarvi at qbang.org > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx Dmitry Markman From mikehall at spacestar.net Mon Mar 20 05:25:25 2006 From: mikehall at spacestar.net (Michael Hall) Date: Mon, 20 Mar 2006 06:25:25 -0600 Subject: [Rxtx] Re: Mac OS X RXTX java installer In-Reply-To: <64BC1E23-FDDE-4CE6-8863-CFC881CBC224@mac.com> References: <07D0DE29-BA32-4CFE-B036-66BC6423D385@buechse.de> <441AE3E0.2030503@willicon.de> <12531986.1142622114996.JavaMail.dmarkman@mac.com> <441B2674.9010409@willicon.de> <13577405.1142634732776.JavaMail.dmarkman@mac.com> <441B4182.8010407@willicon.de> <92CD0D6C-5BE8-426E-A46D-99452059FF49@mac.com> <441BBB2D.8030305@willicon.de> <441C4088.5090905@willicon.de> <64BC1E23-FDDE-4CE6-8863-CFC881CBC224@mac.com> Message-ID: <247EB61F-5CD1-4132-89A2-FC105B6CF9A5@spacestar.net> On Mar 20, 2006, at 1:20 AM, Dmitry Markman wrote: > > Michael Hall (mikehall at spacestar dot net) had a suggestion to > make implementation of the jaas LoginModule > based on Greg's AuthKit > (his modification of the Greg's AuthKit could be found at http:// > www.spacestar.net/users/mikehall/authkit.dmg) > but Michael's AuthKitLoginModule does only half a job: > it does authenticate > but it can not run any external unix process in privileged mode (at > least I wasn't able to do so) If you got it working directly with Greg's the point is moot. But to clarify it anyhow. The login module does not allow you to do anything anything privileged on return as was explained by Greg. You need to work with a separate privileged process using the execPrivileged method of his API. I assume you did something similar although I haven't looked at how you are using it yet. I allowed instead for a action to be performed at the same time you login/authenticate,this... System.setProperty("authkit.action","/usr/bin/id"); just before this... lc.login(); To clarify, safely ignored as you are already complete. Mike Hall mikehall at spacestar dot net http://www.spacestar.net/users/mikehall http://sourceforge.net/projects/macnative -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2427 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20060320/f6e18202/smime-0013.bin From dmarkman at mac.com Mon Mar 20 07:36:47 2006 From: dmarkman at mac.com (Dmitry Markman) Date: Mon, 20 Mar 2006 09:36:47 -0500 Subject: [Rxtx] Re: Mac OS X RXTX java installer In-Reply-To: <247EB61F-5CD1-4132-89A2-FC105B6CF9A5@spacestar.net> References: <07D0DE29-BA32-4CFE-B036-66BC6423D385@buechse.de> <441AE3E0.2030503@willicon.de> <12531986.1142622114996.JavaMail.dmarkman@mac.com> <441B2674.9010409@willicon.de> <13577405.1142634732776.JavaMail.dmarkman@mac.com> <441B4182.8010407@willicon.de> <92CD0D6C-5BE8-426E-A46D-99452059FF49@mac.com> <441BBB2D.8030305@willicon.de> <441C4088.5090905@willicon.de> <64BC1E23-FDDE-4CE6-8863-CFC881CBC224@mac.com> <247EB61F-5CD1-4132-89A2-FC105B6CF9A5@spacestar.net> Message-ID: Hi, Michael all I have to do is to run some shell script I tried to use your action mechanism and it worked great so I just System.setProperty ("authkit.action","" ) and after that I even don't need to run anything like subject.doAs.... but after few thoughts I choose to use plain Greg's approach, because in that case I don't have to deal with various java's configurations files and therefore to use 2-3 -D parameters in the java command line especially it's useful for java web start (it's so fragile :-( ) thanks for the great job On Mar 20, 2006, at 7:25 AM, Michael Hall wrote: > > On Mar 20, 2006, at 1:20 AM, Dmitry Markman wrote: >> >> Michael Hall (mikehall at spacestar dot net) had a suggestion to >> make implementation of the jaas LoginModule >> based on Greg's AuthKit >> (his modification of the Greg's AuthKit could be found at http:// >> www.spacestar.net/users/mikehall/authkit.dmg) >> but Michael's AuthKitLoginModule does only half a job: >> it does authenticate >> but it can not run any external unix process in privileged mode >> (at least I wasn't able to do so) > > If you got it working directly with Greg's the point is moot. > > But to clarify it anyhow. > The login module does not allow you to do anything anything > privileged on return as was explained by Greg. You need to work > with a separate privileged process using the execPrivileged method > of his API. I assume you did something similar although I haven't > looked at how you are using it yet. > I allowed instead for a action to be performed at the same time you > login/authenticate,this... > System.setProperty("authkit.action","/usr/bin/id"); > just before this... > lc.login(); > To clarify, safely ignored as you are already complete. > > Mike Hall mikehall at spacestar dot net > http://www.spacestar.net/users/mikehall > http://sourceforge.net/projects/macnative > > > Dmitry Markman From dmarkman at mac.com Mon Mar 20 07:44:45 2006 From: dmarkman at mac.com (Dmitry Markman) Date: Mon, 20 Mar 2006 09:44:45 -0500 Subject: [Rxtx] Mac OS X RXTX java installer In-Reply-To: References: <07D0DE29-BA32-4CFE-B036-66BC6423D385@buechse.de> <441AE3E0.2030503@willicon.de> <12531986.1142622114996.JavaMail.dmarkman@mac.com> <441B2674.9010409@willicon.de> <13577405.1142634732776.JavaMail.dmarkman@mac.com> <441B4182.8010407@willicon.de> <92CD0D6C-5BE8-426E-A46D-99452059FF49@mac.com> <441BBB2D.8030305@willicon.de> <441C4088.5090905@willicon.de> <64BC1E23-FDDE-4CE6-8863-CFC881CBC224@mac.com> Message-ID: it's in the commapi-0-0-1 branch I tested it right now: cvs co -r commapi-0-0-1 rxtx-devel and I got everything On Mar 20, 2006, at 9:25 AM, Trent Jarvi wrote: > On Mon, 20 Mar 2006, Dr. Douglas Lyon wrote: > >> Hi Trent, >> Thanks for the info on the CVS checkout procedure. >> I did that and am still not sure where the installer is. > > Hi Doug > > It does look like it was not cvs committed. There is no rxtx-devel/ > contrib/MacOSX directory in there at the moment. It was mentioned > that it was put under contrib. > > -- > Trent Jarvi > tjarvi at qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx Dmitry Markman From tjarvi at qbang.org Mon Mar 20 07:52:57 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 20 Mar 2006 07:52:57 -0700 (MST) Subject: [Rxtx] Mac OS X RXTX java installer In-Reply-To: References: <07D0DE29-BA32-4CFE-B036-66BC6423D385@buechse.de> <441AE3E0.2030503@willicon.de> <12531986.1142622114996.JavaMail.dmarkman@mac.com> <441B2674.9010409@willicon.de> <13577405.1142634732776.JavaMail.dmarkman@mac.com> <441B4182.8010407@willicon.de> <92CD0D6C-5BE8-426E-A46D-99452059FF49@mac.com> <441BBB2D.8030305@willicon.de> <441C4088.5090905@willicon.de> <64BC1E23-FDDE-4CE6-8863-CFC881CBC224@mac.com> Message-ID: On Mon, 20 Mar 2006, Dmitry Markman wrote: > it's in the commapi-0-0-1 branch > > I tested it right now: > cvs co -r commapi-0-0-1 rxtx-devel > > and I got everything > A fresh checkout worked. Here is a copy of the tree (just the installer bits) ftp://ftp.qbang.org/pub/rxtx/MacOSX-installer.zip -- Trent Jarvi tjarvi at qbang.org From lyon at docjava.com Mon Mar 20 08:08:26 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Mon, 20 Mar 2006 10:08:26 -0500 Subject: [Rxtx] Mac OS X RXTX java installer In-Reply-To: References: <07D0DE29-BA32-4CFE-B036-66BC6423D385@buechse.de> <441AE3E0.2030503@willicon.de> <12531986.1142622114996.JavaMail.dmarkman@mac.com> <441B2674.9010409@willicon.de> <13577405.1142634732776.JavaMail.dmarkman@mac.com> <441B4182.8010407@willicon.de> <92CD0D6C-5BE8-426E-A46D-99452059FF49@mac.com> <441BBB2D.8030305@willicon.de> <441C4088.5090905@willicon.de> <64BC1E23-FDDE-4CE6-8863-CFC881CBC224@mac.com> Message-ID: Hi All, Is the Auth package able to work properly on non Mac OS's? It was not clear from the doc or download. Thanks! - Doug From dmarkman at mac.com Mon Mar 20 08:15:22 2006 From: dmarkman at mac.com (Dmitry Markman) Date: Mon, 20 Mar 2006 10:15:22 -0500 Subject: [Rxtx] Mac OS X RXTX java installer In-Reply-To: References: <07D0DE29-BA32-4CFE-B036-66BC6423D385@buechse.de> <441AE3E0.2030503@willicon.de> <12531986.1142622114996.JavaMail.dmarkman@mac.com> <441B2674.9010409@willicon.de> <13577405.1142634732776.JavaMail.dmarkman@mac.com> <441B4182.8010407@willicon.de> <92CD0D6C-5BE8-426E-A46D-99452059FF49@mac.com> <441BBB2D.8030305@willicon.de> <441C4088.5090905@willicon.de> <64BC1E23-FDDE-4CE6-8863-CFC881CBC224@mac.com> Message-ID: <217312D8-CCCA-4859-ABA6-32DF1CC817B9@mac.com> thanks Trent, for putting it on ftp server On Mar 20, 2006, at 9:52 AM, Trent Jarvi wrote: > A fresh checkout worked. Here is a copy of the tree (just the > installer bits) > > ftp://ftp.qbang.org/pub/rxtx/MacOSX-installer.zip > Dmitry Markman From dmarkman at mac.com Mon Mar 20 09:14:03 2006 From: dmarkman at mac.com (Dmitry Markman) Date: Mon, 20 Mar 2006 11:14:03 -0500 Subject: [Rxtx] Mac OS X RXTX java installer In-Reply-To: References: <07D0DE29-BA32-4CFE-B036-66BC6423D385@buechse.de> <441AE3E0.2030503@willicon.de> <12531986.1142622114996.JavaMail.dmarkman@mac.com> <441B2674.9010409@willicon.de> <13577405.1142634732776.JavaMail.dmarkman@mac.com> <441B4182.8010407@willicon.de> <92CD0D6C-5BE8-426E-A46D-99452059FF49@mac.com> <441BBB2D.8030305@willicon.de> <441C4088.5090905@willicon.de> <64BC1E23-FDDE-4CE6-8863-CFC881CBC224@mac.com> Message-ID: <4DEBA6F0-DA45-4E84-823E-1F1AC48BDCCC@mac.com> no it will work only on mac os x however it's harmless to run it on other platform if you want to use it for other platform you have to do the following (I'll do it for linux) 1. modify RXTXInstaller class method public static RXTXInstaller getInstance() public static RXTXInstaller getInstance() { String osName = System.getProperty("os.name").toLowerCase(); if(osName.startsWith("mac")){ return new gnu.io.installer.macosx.MACOSXRXTXInstaller(); } else if(osName.startsWith("windows")){ return new gnu.io.installer.windows.WindowsRXTXInstaller(); }else if(osName.startsWith("linux")){ return new gnu.io.installer.linux.LinuxRXTXInstaller(); } return null; } 2. create folder gnu/io/installer/linux/ 3. create class Linux386RXTXInstaller package gnu.io.installer.linux; import java.io.File; public class Linux386RXTXInstaller extends gnu.io.installer.RXTXInstaller{ public Linux386RXTXInstaller(){ createJarFolder(); createLibFolder(); addJarResource("RXTXcomm.jar","/gnu/io/installer/resources/ linux/jar/RXTXcomm.dat"); addLibResource("librxtxSerial.so","/gnu/io/installer/ resources/linux/lib/librxtxSerial.so"); } protected void createJarFolder(){ String javaHome = System.getProperty("java.home"); char separator = File.separatorChar; jarFolder = new File(javaHome+separator+"lib"+separator+"ext"); } protected void createLibFolder(){ String javaHome = System.getProperty("java.home"); char separator = File.separatorChar; libFolder = new File(javaHome+separator+"bin"); } public void runPreProcess() {} //put here some action you need public void runPostProcess() {} //put here some action you need } 4. create folder /gnu/io/installer/resources/linux/jar and put there linux's version of RXTXcomm.dat (which is renamed RXTXcomm.jar) 5. create folder /gnu/io/installer/resources/linux/lib and put there linux's version of librxtxSerial. so 6. make sure that RXTXInstaller.jar has the following items: /gnu/io/installer/resources/linux/jar/RXTXcomm.jar /gnu/io/installer/resources/linux/lib/librxtxSerial.so 7. modify file installer.pref: jar file RXTXInstaller.jar must have the following item /gnu/io/installer/installer.pref that's basically it for windows you have to do the similar things: just replace linux to windows and librxtxSerial.so to rxtxSerial.dll and create appropriate gnu.io.installer.windows.WindowsRXTXInstaller class package gnu.io.installer.windows; import java.io.File; public class WindowsRXTXInstaller extends gnu.io.installer.RXTXInstaller{ public WindowsRXTXInstaller(){ createJarFolder(); createLibFolder(); addJarResource("RXTXcomm.jar","/gnu/io/installer/resources/ windows/jar/RXTXcomm.dat"); addLibResource("librxtxSerial.so","/gnu/io/installer/ resources/windows/lib/rxtxSerial.dll"); } protected void createJarFolder(){ String javaHome = System.getProperty("java.home"); char separator = File.separatorChar; jarFolder = new File(javaHome+separator+"lib"+separator+"ext"); } protected void createLibFolder(){ String javaHome = System.getProperty("java.home"); char separator = File.separatorChar; libFolder = new File(javaHome+separator+"bin"); } public void runPreProcess() {} //put here some action you need public void runPostProcess() {} //put here some action you need } installer.pref will look like On Mar 20, 2006, at 10:08 AM, Dr. Douglas Lyon wrote: > Hi All, > Is the Auth package able to work properly on > non Mac OS's? > It was not clear from the doc or download. > > Thanks! > - Doug > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx Dmitry Markman From joachim at buechse.de Mon Mar 20 10:49:06 2006 From: joachim at buechse.de (Joachim Buechse) Date: Mon, 20 Mar 2006 18:49:06 +0100 Subject: [Rxtx] BUG: Lock file stays even if port opening fails Message-ID: This was only tested on MacOSX but looking at the code, it should be true for all systems that use lock_uucp. I am opening a port which can not be opened (dialup port of a telephone paired via bluetooth but currently not reachable). The lock file is created and stays arround, even though the port open failed. After looking a bit through the code (of 2.17), I really wonder if it wouldn't be a good idea to make the "locking" an explicit operation called from the java code. This would certainly simplify the generation of meaningfull exceptions (and java based debugging). Maybe even the handling of "preopened" ports should be in the Java part of the lib (again for java based debugging puposes). That beeing said, I have no idea if this would be possible for the 2.07 implementation. Regards, Joachim From tjarvi at qbang.org Mon Mar 20 11:24:22 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 20 Mar 2006 11:24:22 -0700 (MST) Subject: [Rxtx] BUG: Lock file stays even if port opening fails In-Reply-To: References: Message-ID: On Mon, 20 Mar 2006, Joachim Buechse wrote: > This was only tested on MacOSX but looking at the code, it should be true > for all systems that use lock_uucp. > > I am opening a port which can not be opened (dialup port of a telephone > paired via bluetooth but currently not reachable). The lock file is > created and stays arround, even though the port open failed. > > > After looking a bit through the code (of 2.17), I really wonder if it > wouldn't be a good idea to make the "locking" an explicit operation > called from the java code. This would certainly simplify the generation > of meaningfull exceptions (and java based debugging). > Maybe even the handling of "preopened" ports should be in the Java part > of the lib (again for java based debugging puposes). That beeing said, I > have no idea if this would be possible for the 2.07 implementation. > > Regards, Hi Joachim It should be possible in the 2.0-7 implementation too. The calls to RXTXPort.java would not change. We would just do more there Moving more of that logic into Java would be better as many people don't like to look at C code. There is a liblockdev on most Linux distros that can do most of the C code and would be easier to use. The problem is embeded devices will not have that library. The preopened port code has not been really tested. That was a last minute request in a product cycle. I expect it will be tested this year though. As I recall, some devices really do not like CD raising on open. The preopened ports then allow people to mess around in java without power cycling the devices or losing data. -- Trent Jarvi tjarvi at qbang.org From joachim at buechse.de Mon Mar 20 12:01:08 2006 From: joachim at buechse.de (Joachim Buechse) Date: Mon, 20 Mar 2006 20:01:08 +0100 Subject: [Rxtx] BUG: Lock file stays even if port opening fails In-Reply-To: References: Message-ID: Hi Trent, What is your general feeling about moving code to Java? The last days I have been reading quite a bit of the code and there are several things, that might not work as expected. I'll give you two examples from is_device_locked: if LOCKDIR == /var/spool/locks the directory /var/spool/lock will not be checked. LOCKDIR is not checked for lockfiles with unexpected pefixes While these things have probably never been discovered in production, they are still possibly incorrect implementations. If it was Java code, I would write some unit tests producing the errors that could later be corrected. PS: One could imagine to actually implement the whole lockfile handling in Java using some native routines to get the values required (pid, st_dev, st_rdev, ...). On 20.03.2006, at 19:24, Trent Jarvi wrote: > On Mon, 20 Mar 2006, Joachim Buechse wrote: > >> This was only tested on MacOSX but looking at the code, it should >> be true for all systems that use lock_uucp. >> >> I am opening a port which can not be opened (dialup port of a >> telephone paired via bluetooth but currently not reachable). The >> lock file is created and stays arround, even though the port open >> failed. >> >> >> After looking a bit through the code (of 2.17), I really wonder if >> it wouldn't be a good idea to make the "locking" an explicit >> operation called from the java code. This would certainly simplify >> the generation of meaningfull exceptions (and java based debugging). >> Maybe even the handling of "preopened" ports should be in the Java >> part of the lib (again for java based debugging puposes). That >> beeing said, I have no idea if this would be possible for the 2.07 >> implementation. >> >> Regards, > > Hi Joachim > > It should be possible in the 2.0-7 implementation too. The calls > to RXTXPort.java would not change. We would just do more there > Moving more of that logic into Java would be better as many people > don't like to look at C code. There is a liblockdev on most Linux > distros that can do most of the C code and would be easier to use. > The problem is embeded devices will not have that library. > > The preopened port code has not been really tested. That was a > last minute request in a product cycle. I expect it will be tested > this year though. As I recall, some devices really do not like CD > raising on open. The preopened ports then allow people to mess > around in java without power cycling the devices or losing data. > > -- > Trent Jarvi > tjarvi at qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Mon Mar 20 12:21:02 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 20 Mar 2006 12:21:02 -0700 (MST) Subject: [Rxtx] BUG: Lock file stays even if port opening fails In-Reply-To: References: Message-ID: On Mon, 20 Mar 2006, Joachim Buechse wrote: > Hi Trent, > > What is your general feeling about moving code to Java? The last days I > have been reading quite a bit of the code and there are several things, > that might not work as expected. > > I'll give you two examples from is_device_locked: > > if LOCKDIR == /var/spool/locks the directory /var/spool/lock will not be > checked. > LOCKDIR is not checked for lockfiles with unexpected pefixes > > While these things have probably never been discovered in production, > they are still possibly incorrect implementations. If it was Java code, I > would write some unit tests producing the errors that could later be > corrected. > > PS: One could imagine to actually implement the whole lockfile handling > in Java using some native routines to get the values required (pid, > st_dev, st_rdev, ...). Hi Joachim I like the idea of moving more of the code into java but there are some things to consider. If you break this into multiple JNI calls, the performance will drop considerably during enumeration of ports. We are looking for 256 ports per dev type vs (16? in Sun's 2.0 and fewer types). Its hard to make assumptions. I've seen virtual ports start at /dev/foo100 for instance. It works out to over 7500 ports on Linux if you enable them all. We already trim that back by default. See Linux-all-ports in RXTXCommDriver.java. There are also native libraries that rxtx can link to. If you move too much into Java, linking to 'standard' libraries with distros will break. "configure --enable-liblock=yes" will not be doable. This is probably a favorable way with RedHat, Debian, Suse and others. Thats the right thing to do if there will be rpms, dpkg, .. For those reasons, I think it still make sense to keep it to a minimal ~3 calls to JNI code that we can use for speed and versatility. lock() isLocked(), unlock() perhaps. When I say speed, its more about avoiding crossing the JNI layer multiple times than java vs C performance. With versatility I think liblock is the right way for most but not all (embeded) linux distros. -- Trent Jarvi tjarvi at qbang.org From joachim at buechse.de Mon Mar 20 12:42:04 2006 From: joachim at buechse.de (Joachim Buechse) Date: Mon, 20 Mar 2006 20:42:04 +0100 Subject: [Rxtx] BUG: Lock file stays even if port opening fails In-Reply-To: References: Message-ID: <82C19FE7-DDCB-45B6-B2C9-7606B66F0124@buechse.de> Ok, what about providing a default implementation in Java? The RXTXCommDriver would call a (native) function useNativeLocking and if it returns true, call the native functions for lock() isLocked (), unlock(), else is would use the Java based default implementation. This could possibly be overriden by a property (again for debugging). Joachim On 20.03.2006, at 20:21, Trent Jarvi wrote: > On Mon, 20 Mar 2006, Joachim Buechse wrote: > >> Hi Trent, >> >> What is your general feeling about moving code to Java? The last >> days I have been reading quite a bit of the code and there are >> several things, that might not work as expected. >> >> I'll give you two examples from is_device_locked: >> >> if LOCKDIR == /var/spool/locks the directory /var/spool/lock will >> not be checked. >> LOCKDIR is not checked for lockfiles with unexpected pefixes >> >> While these things have probably never been discovered in >> production, they are still possibly incorrect implementations. If >> it was Java code, I would write some unit tests producing the >> errors that could later be corrected. >> >> PS: One could imagine to actually implement the whole lockfile >> handling in Java using some native routines to get the values >> required (pid, st_dev, st_rdev, ...). > > Hi Joachim > > I like the idea of moving more of the code into java but there are > some things to consider. > > If you break this into multiple JNI calls, the performance will > drop considerably during enumeration of ports. We are looking for > 256 ports per dev type vs (16? in Sun's 2.0 and fewer types). Its > hard to make assumptions. I've seen virtual ports start at /dev/ > foo100 for instance. > > It works out to over 7500 ports on Linux if you enable them all. > We already trim that back by default. See Linux-all-ports in > RXTXCommDriver.java. > > There are also native libraries that rxtx can link to. If you move > too much into Java, linking to 'standard' libraries with distros > will break. "configure --enable-liblock=yes" will not be doable. > This is probably a favorable way with RedHat, Debian, Suse and > others. Thats the right thing to do if there will be rpms, dpkg, .. > > For those reasons, I think it still make sense to keep it to a > minimal ~3 calls to JNI code that we can use for speed and > versatility. lock() isLocked(), unlock() perhaps. When I say > speed, its more about avoiding crossing the JNI layer multiple > times than java vs C performance. With versatility I think liblock > is the right way for most but not all (embeded) linux distros. > > -- > Trent Jarvi > tjarvi at qbang.org > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Mon Mar 20 12:44:47 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 20 Mar 2006 12:44:47 -0700 (MST) Subject: [Rxtx] BUG: Lock file stays even if port opening fails In-Reply-To: <82C19FE7-DDCB-45B6-B2C9-7606B66F0124@buechse.de> References: <82C19FE7-DDCB-45B6-B2C9-7606B66F0124@buechse.de> Message-ID: On Mon, 20 Mar 2006, Joachim Buechse wrote: > Ok, what about providing a default implementation in Java? > > The RXTXCommDriver would call a (native) function useNativeLocking and if > it returns true, call the native functions for lock() isLocked(), > unlock(), else is would use the Java based default implementation. This > could possibly be overriden by a property (again for debugging). > Hi Joachim That would be OK with me. -- Trent Jarvi tjarvi at qbang.org From dmarkman at mac.com Mon Mar 20 22:27:45 2006 From: dmarkman at mac.com (Dmitry Markman) Date: Tue, 21 Mar 2006 00:27:45 -0500 Subject: [Rxtx] binaries request Message-ID: <42702213-C222-4937-A585-7CFB17E47608@mac.com> Hi can somebody send me latest linux and windows binaries, please? or where I can find them (I didn't find them in the latest tareball) I gave up with my cygwin: something wrong I have no idea what java doesn't understand /cygwin/c syntax after I changed makefile it did java part but after that gcc 3.4.4 started to complain I set buffer length to 999 lines but I didn't get beginning of the story something wrong with my 1.4.2_09/include/jni.h gcc doesn't like it anyway I gave up thanks in advance Dmitry Markman -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060320/f8cbc57c/attachment-0013.html From tjarvi at qbang.org Mon Mar 20 22:36:48 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 20 Mar 2006 22:36:48 -0700 (MST) Subject: [Rxtx] binaries request In-Reply-To: <42702213-C222-4937-A585-7CFB17E47608@mac.com> References: <42702213-C222-4937-A585-7CFB17E47608@mac.com> Message-ID: On Tue, 21 Mar 2006, Dmitry Markman wrote: > Hi > can somebody send me latest linux and windows binaries, please? > > or where I can find them (I didn't find them in the latest tareball) > > I gave up with my cygwin: something wrong I have no idea what > java doesn't understand /cygwin/c syntax > after I changed makefile it did java part > but after that gcc 3.4.4 started to complain > I set buffer length to 999 lines but I didn't get beginning of the story > something wrong with my 1.4.2_09/include/jni.h gcc doesn't like it > anyway I gave up > > thanks in advance > Hi Dmitry The bins are here: ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7-bins-r2.zip Here are the files in the zip you want. Jar: rxtx-2.1-7-bins-r2/RXTXcomm.jar Windows: rxtx-2.1-7-bins-r2/Windows/i368-mingw32/rxtxSerial.dll Linux (x86) rxtx-2.1-7-bins-r2/Linux/i686-unknown-linux-gnu/librxtxSerial.so There are others in there including Parallel port support but those are the main ones for testing. -- Trent Jarvi tjarvi at qbang.org From dmarkman at mac.com Mon Mar 20 23:05:59 2006 From: dmarkman at mac.com (Dmitry Markman) Date: Tue, 21 Mar 2006 01:05:59 -0500 Subject: [Rxtx] binaries request In-Reply-To: References: <42702213-C222-4937-A585-7CFB17E47608@mac.com> Message-ID: thank you very much but windows's readme says: rxtxSerial.dll had to be recomopiled to link in missing native methods. should I ignore it? or what? thanks again also I understand that I should use mingw not cygwin I'll try to install mingw On Mar 21, 2006, at 12:36 AM, Trent Jarvi wrote: > On Tue, 21 Mar 2006, Dmitry Markman wrote: > >> Hi >> can somebody send me latest linux and windows binaries, please? >> >> or where I can find them (I didn't find them in the latest tareball) >> >> I gave up with my cygwin: something wrong I have no idea what >> java doesn't understand /cygwin/c syntax >> after I changed makefile it did java part >> but after that gcc 3.4.4 started to complain >> I set buffer length to 999 lines but I didn't get beginning of the >> story >> something wrong with my 1.4.2_09/include/jni.h gcc doesn't like it >> anyway I gave up >> >> thanks in advance >> > > Hi Dmitry > > The bins are here: > > ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7-bins-r2.zip > > Here are the files in the zip you want. > > Jar: > > rxtx-2.1-7-bins-r2/RXTXcomm.jar > > Windows: > > rxtx-2.1-7-bins-r2/Windows/i368-mingw32/rxtxSerial.dll > > Linux (x86) > > rxtx-2.1-7-bins-r2/Linux/i686-unknown-linux-gnu/librxtxSerial.so > > There are others in there including Parallel port support but those > are the main ones for testing. > > -- > Trent Jarvi > tjarvi at qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx Dmitry Markman From tjarvi at qbang.org Mon Mar 20 23:20:33 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 20 Mar 2006 23:20:33 -0700 (MST) Subject: [Rxtx] binaries request In-Reply-To: References: <42702213-C222-4937-A585-7CFB17E47608@mac.com> Message-ID: On Tue, 21 Mar 2006, Dmitry Markman wrote: > thank you very much > > but windows's readme says: > rxtxSerial.dll had to be recomopiled to link in missing native methods. > > should I ignore it? or what? > Hi Dmitry That dll should be OK. r2 is the recompile linked to the missing native method. The readme explains why it was recompiled; fuser.o was not linked into the dll in the first release. -- Trent Jarvi tjarvi at qbang.org From ariantristan at yahoo.com Mon Mar 20 23:55:24 2006 From: ariantristan at yahoo.com (Lambok Sianturi) Date: Mon, 20 Mar 2006 22:55:24 -0800 (PST) Subject: [Rxtx] jvm issue Message-ID: <20060321065524.94779.qmail@web50701.mail.yahoo.com> Hi All, This is my first time to join RxTx mailing list. I thank you all for allowing others to sign in in requests help. I use the latest RxTx lib in Fedora 3 with java version 1.4.2_09 b05. And I got this error: # # An unexpected error has been detected by HotSpot Virtual Machine: # # SIGSEGV (0xb) at pc=0x00bf27f3, pid=2633, tid=3086112448 # # Java VM: Java HotSpot(TM) Client VM (1.4.2_09-b05 mixed mode) # Problematic frame: # C [ld-linux.so.2+0xa7f3] # # An error report file with more information is saved as hs_err_pid2633.log # # If you would like to submit a bug report, please visit: # http://java.sun.com/webapps/bugreport/crash.jsp # ./run.sh: line 3: 2633 Aborted /usr/local/java/bin/java -Djava.library.path=/usr/local/java/jre/lib/ -Djsmsengine.debug=true -classpath jsmsengine.jar:smsgateway.jar:classes12.jar:RXTXcomm.jar:. com.api.sms.SMSServer What is the jvm depedency for the latest library? Can I use 1.4.2_09 b05? Thanks in advance. Arian --------------------------------- Yahoo! Mail Use Photomail to share photos without annoying attachments. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060320/83d58dd7/attachment-0013.html From f.frumento at ngi.it Tue Mar 21 00:21:47 2006 From: f.frumento at ngi.it (Fabio Frumento) Date: Tue, 21 Mar 2006 08:21:47 +0100 Subject: [Rxtx] Javadoc on the go Message-ID: <441FA98B.9050701@ngi.it> Hi Trent, sorry for the big delay but my job is running wild, i was out for some time but now i'm back and ready to continue the javadoc for Rxtx. Did you used the last javadoc patch i sent you ? let me know if i have to send it to you again or not. regards Fabio From lyon at docjava.com Tue Mar 21 00:51:18 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Tue, 21 Mar 2006 02:51:18 -0500 Subject: [Rxtx] lock files Message-ID: Hi All, You know, if the use of lock files were under Java control (rather than a build-time decision), it might enable a more unified binary distro. It might also facilitate quick prototyping of non-lock file approaches to resolving serial port contention issues (i.e., mac-like approaches vs. linux approaches, etc.). I realize that this is a radical overhaul of the lock file policy issue. Also, it may harm performance. On the other hand, our benchmarks on JNI overhead for modern processors indicate performance impact should be minimal. Perhaps it is more of an issue with the toybox systems. Suppose there were a class with a reasonable default...someone might write: SerialPortLockPolicy.setPolicy(SerialPortLockPolicy.UNIX_LOCK_FILE); SerialPortLockPolicy.setPolicy(SerialPortLockPolicy.NO_LOCK_CHECKING); SerialPortLockPolicy.setPolicy(SerialPortLockPolicy.MAC_STYLE); Thus, we could have a run-time reconfiguration of the serial port lock policy. A special NO_LOCK version of the binary would no longer be required. Any thoughts on this? Thanks! - Doug From joachim at buechse.de Tue Mar 21 03:09:09 2006 From: joachim at buechse.de (Joachim Buechse) Date: Tue, 21 Mar 2006 11:09:09 +0100 Subject: [Rxtx] lock files In-Reply-To: References: Message-ID: <8E12916A-1B9A-4FF2-B684-E2D1C794221B@buechse.de> This is pretty much what I thought about when I suggested, that the default behaviour could be overwritten with a property. I am very much in favor of this approach. In particular this allows much easier debugging for PC based java developers. I think big parts of the Java (and maybe some parts of the C code) could use a bit of a structural workover (unit tests, javadoc, synchronization, etc). Maybe there should be a CVS branch for this experimental version. I'd be happy to contribute a first workover for some of the Java code. Designing for testability and implementing a good bunch of unit tests has been a strategy that worked quite well in the Java projects I lead. And it ultimately allows more liberal change permission. Regards, Joachim On 21.03.2006, at 08:51, Dr. Douglas Lyon wrote: > Hi All, > You know, if the use of lock files were > under Java control (rather than a build-time decision), > it might enable a more unified binary distro. It might also > facilitate quick prototyping of non-lock file approaches > to resolving serial port contention issues (i.e., mac-like > approaches vs. linux approaches, etc.). > > I realize that this is a radical overhaul of the lock file policy > issue. Also, it may harm performance. On the other hand, > our benchmarks on JNI overhead for modern processors indicate > performance impact should be minimal. Perhaps it is more of > an issue with the toybox systems. > > Suppose there were a class with a reasonable default...someone > might write: > SerialPortLockPolicy.setPolicy(SerialPortLockPolicy.UNIX_LOCK_FILE); > SerialPortLockPolicy.setPolicy(SerialPortLockPolicy.NO_LOCK_CHECKING); > SerialPortLockPolicy.setPolicy(SerialPortLockPolicy.MAC_STYLE); > > Thus, we could have a run-time reconfiguration of the serial port lock > policy. A special NO_LOCK version of the binary would no longer > be required. > > Any thoughts on this? > > Thanks! > - Doug > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From joachim at buechse.de Tue Mar 21 06:23:08 2006 From: joachim at buechse.de (Joachim Buechse) Date: Tue, 21 Mar 2006 14:23:08 +0100 Subject: [Rxtx] PATCH: use of ioctl(fd, TIOCEXCL) instead of lockfiles Message-ID: <923AE774-EEA2-4911-92D8-32BB27802C8B@buechse.de> Here is the patch for the ioctl(fd, TIOCEXCL). I have verified this only for OSX 10.4.5, hence it is only defined for APPLE. However, it should work at least for Solaris as well. If a process has requested TIOEXCL further open calls by other user processes will fail. The patch also disables uucp style locking for APPLE. Obviously this is discussable. I think it is the way to go, as it eliminates creating the lock directory which doesnt exist on the standard installation and it eliminates messing with the system group definitions (adding users to group uucp). Regarding the possibility of root processes opening a device which is locked - I consider this a feature not a potential problem. It is highly unlikely, that somebody is crazy enough to run a JavaVM as root (unless he has no other means of getting a restricted IP port opened, ie doesnt understand ipfw). Anyway, even if the process runs as root, it fails when calling ioctl(fd, TIOCEXCL). It could however still open the port to listen for RING events. I.e. a fax server which needs to see incoming calls but otherwise doesnt want to block the port. So the only case where the proposed mechanism fails is, if an incorrectly implemented process running as root conflicts with a user process. I think this can be accepted. Regards, Joachim PS: If this patch is generally accepted, the installer and Mac doku should obviously be changed as well. Index: SerialImp.c =================================================================== RCS file: /usr/local/cvsroot/rxtx-devel/src/SerialImp.c,v retrieving revision 1.46.2.187 diff -u -r1.46.2.187 SerialImp.c --- SerialImp.c 29 Jan 2006 22:19:04 -0000 1.46.2.187 +++ SerialImp.c 21 Mar 2006 12:59:16 -0000 @@ -656,6 +656,25 @@ fd=OPEN (filename, O_RDWR | O_NOCTTY | O_NONBLOCK ); } while (fd < 0 && errno==EINTR); +#ifdef OPEN_EXCL + // Note that open() follows POSIX semantics: multiple open() calls to + // the same file will succeed unless the TIOCEXCL ioctl is issued. + // This will prevent additional opens except by root-owned processes. + // See tty(4) ("man 4 tty") and ioctl(2) ("man 2 ioctl") for details. + + if (fd >= 0 && (ioctl(fd, TIOCEXCL) == -1)) + { + sprintf( message, "open: exclusive access denied for % s\n", + filename ); + report( message ); + report_error( message ); + + close(fd); + goto fail; + } +#endif /* OPEN_EXCL */ + + if( configure_port( fd ) ) goto fail; (*env)->ReleaseStringUTFChars( env, jstr, filename ); sprintf( message, "open: fd returned is %i\n", fd ); Index: SerialImp.h =================================================================== RCS file: /usr/local/cvsroot/rxtx-devel/src/SerialImp.h,v retrieving revision 1.11.2.49 diff -u -r1.11.2.49 SerialImp.h --- SerialImp.h 5 Jul 2005 17:47:21 -0000 1.11.2.49 +++ SerialImp.h 21 Mar 2006 12:59:17 -0000 @@ -135,7 +135,8 @@ /*# define LOCKDIR "/var/spool/uucp"*/ # define LOCKDIR "/var/lock" # define LOCKFILEPREFIX "LK." -# define UUCP +/*# define UUCP*/ +# define OPEN_EXCL #endif /* __APPLE__ */ #if defined(__NetBSD__) # define DEVICEDIR "/dev/" From tjarvi at qbang.org Tue Mar 21 10:26:08 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 21 Mar 2006 10:26:08 -0700 (MST) Subject: [Rxtx] Javadoc on the go In-Reply-To: <441FA98B.9050701@ngi.it> References: <441FA98B.9050701@ngi.it> Message-ID: On Tue, 21 Mar 2006, Fabio Frumento wrote: > Hi Trent, > > sorry for the big delay but my job is running wild, i was out for some > time but now i'm back and ready to continue the javadoc for Rxtx. > > Did you used the last javadoc patch i sent you ? let me know if i have to > send it to you again or not. > > regards > > Fabio Hi Fabio The patch is in the rxtx mail-list archives. It will be going in soon. I did not see a time critical portion. I'll probably be going through the list since the last batch of patches this weekend and putting them into CVS. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Tue Mar 21 10:57:18 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 21 Mar 2006 10:57:18 -0700 (MST) Subject: [Rxtx] jvm issue In-Reply-To: <20060321065524.94779.qmail@web50701.mail.yahoo.com> References: <20060321065524.94779.qmail@web50701.mail.yahoo.com> Message-ID: On Mon, 20 Mar 2006, Lambok Sianturi wrote: > Hi All, > This is my first time to join RxTx mailing list. I thank you all for allowing others to sign in in requests help. > I use the latest RxTx lib in Fedora 3 with java version 1.4.2_09 b05. And I got this error: > > # > # An unexpected error has been detected by HotSpot Virtual Machine: > # > # SIGSEGV (0xb) at pc=0x00bf27f3, pid=2633, tid=3086112448 > # > # Java VM: Java HotSpot(TM) Client VM (1.4.2_09-b05 mixed mode) > # Problematic frame: > # C [ld-linux.so.2+0xa7f3] A native library loading error? What happens if you recompile rxtx on your system and install that? This sounds like an ABI problem? rxtx 2.1-7 was compiled with a gcc 2.96 toolchain as I recall. The hope is newer system will be backwards compatible. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Tue Mar 21 11:05:29 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 21 Mar 2006 11:05:29 -0700 (MST) Subject: [Rxtx] PATCH: use of ioctl(fd, TIOCEXCL) instead of lockfiles In-Reply-To: <923AE774-EEA2-4911-92D8-32BB27802C8B@buechse.de> References: <923AE774-EEA2-4911-92D8-32BB27802C8B@buechse.de> Message-ID: On Tue, 21 Mar 2006, Joachim Buechse wrote: > Here is the patch for the ioctl(fd, TIOCEXCL). I have verified this only > for OSX 10.4.5, hence it is only defined for APPLE. However, it should > work at least for Solaris as well. > > If a process has requested TIOEXCL further open calls by other user > processes will fail. > > The patch also disables uucp style locking for APPLE. Obviously this is > discussable. I think it is the way to go, as it eliminates creating the > lock directory which doesnt exist on the standard installation and it > eliminates messing with the system group definitions (adding users to > group uucp). > > Regarding the possibility of root processes opening a device which is > locked - I consider this a feature not a potential problem. It is highly > unlikely, that somebody is crazy enough to run a JavaVM as root (unless > he has no other means of getting a restricted IP port opened, ie doesnt > understand ipfw). Anyway, even if the process runs as root, it fails when > calling ioctl(fd, TIOCEXCL). It could however still open the port to > listen for RING events. I.e. a fax server which needs to see incoming > calls but otherwise doesnt want to block the port. So the only case where > the proposed mechanism fails is, if an incorrectly implemented process > running as root conflicts with a user process. I think this can be > accepted. > > Regards, > Joachim > > PS: If this patch is generally accepted, the installer and Mac doku > should obviously be changed as well. > > > Index: SerialImp.c > =================================================================== > RCS file: /usr/local/cvsroot/rxtx-devel/src/SerialImp.c,v > retrieving revision 1.46.2.187 > diff -u -r1.46.2.187 SerialImp.c > --- SerialImp.c 29 Jan 2006 22:19:04 -0000 1.46.2.187 > +++ SerialImp.c 21 Mar 2006 12:59:16 -0000 > @@ -656,6 +656,25 @@ > fd=OPEN (filename, O_RDWR | O_NOCTTY | O_NONBLOCK ); > } while (fd < 0 && errno==EINTR); > > +#ifdef OPEN_EXCL > + // Note that open() follows POSIX semantics: multiple open() > calls to > + // the same file will succeed unless the TIOCEXCL ioctl is > issued. > + // This will prevent additional opens except by root-owned > processes. > + // See tty(4) ("man 4 tty") and ioctl(2) ("man 2 ioctl") for > details. > + > + if (fd >= 0 && (ioctl(fd, TIOCEXCL) == -1)) > + { > + sprintf( message, "open: exclusive access denied for % > s\n", > + filename ); > + report( message ); > + report_error( message ); > + > + close(fd); > + goto fail; > + } > +#endif /* OPEN_EXCL */ > + > + > if( configure_port( fd ) ) goto fail; > (*env)->ReleaseStringUTFChars( env, jstr, filename ); > sprintf( message, "open: fd returned is %i\n", fd ); > Index: SerialImp.h > =================================================================== > RCS file: /usr/local/cvsroot/rxtx-devel/src/SerialImp.h,v > retrieving revision 1.11.2.49 > diff -u -r1.11.2.49 SerialImp.h > --- SerialImp.h 5 Jul 2005 17:47:21 -0000 1.11.2.49 > +++ SerialImp.h 21 Mar 2006 12:59:17 -0000 > @@ -135,7 +135,8 @@ > /*# define LOCKDIR "/var/spool/uucp"*/ > # define LOCKDIR "/var/lock" > # define LOCKFILEPREFIX "LK." > -# define UUCP > +/*# define UUCP*/ > +# define OPEN_EXCL > #endif /* __APPLE__ */ > #if defined(__NetBSD__) > # define DEVICEDIR "/dev/" > This looks like a good start. What do you think Dmitry? Perhaps all systems with TIOCEXCL defined should use that though. Even if they use lockfiles. It wont hurt anything. That would catch people hacking their own serial apps without checking lockfiles. Its a good idea to avoid C++ style comments in the C portions. Some older systems don't deal with them well. If it's just for Mac OS X, it isn't a big deal. I think it was the Irix compiler that was problematic? -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Tue Mar 21 11:22:05 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 21 Mar 2006 11:22:05 -0700 (MST) Subject: [Rxtx] lock files In-Reply-To: <8E12916A-1B9A-4FF2-B684-E2D1C794221B@buechse.de> References: <8E12916A-1B9A-4FF2-B684-E2D1C794221B@buechse.de> Message-ID: We can try it. Maybe the JNI is much improved. The nice thing about linking into liblock is distros then worry about lockfiles on their systems. This way, we have to deal with any changes that may show up. On Tue, 21 Mar 2006, Joachim Buechse wrote: > This is pretty much what I thought about when I suggested, that the > default behaviour could be overwritten with a property. I am very much in > favor of this approach. In particular this allows much easier debugging > for PC based java developers. > > I think big parts of the Java (and maybe some parts of the C code) could > use a bit of a structural workover (unit tests, javadoc, synchronization, > etc). Maybe there should be a CVS branch for this experimental version. > I'd be happy to contribute a first workover for some of the Java code. > Designing for testability and implementing a good bunch of unit tests has > been a strategy that worked quite well in the Java projects I lead. And > it ultimately allows more liberal change permission. > > Regards, > Joachim > > > On 21.03.2006, at 08:51, Dr. Douglas Lyon wrote: > >> Hi All, >> You know, if the use of lock files were >> under Java control (rather than a build-time decision), >> it might enable a more unified binary distro. It might also >> facilitate quick prototyping of non-lock file approaches >> to resolving serial port contention issues (i.e., mac-like >> approaches vs. linux approaches, etc.). >> >> I realize that this is a radical overhaul of the lock file policy >> issue. Also, it may harm performance. On the other hand, >> our benchmarks on JNI overhead for modern processors indicate >> performance impact should be minimal. Perhaps it is more of >> an issue with the toybox systems. >> >> Suppose there were a class with a reasonable default...someone >> might write: >> SerialPortLockPolicy.setPolicy(SerialPortLockPolicy.UNIX_LOCK_FILE); >> SerialPortLockPolicy.setPolicy(SerialPortLockPolicy.NO_LOCK_CHECKING); >> SerialPortLockPolicy.setPolicy(SerialPortLockPolicy.MAC_STYLE); >> >> Thus, we could have a run-time reconfiguration of the serial port lock >> policy. A special NO_LOCK version of the binary would no longer >> be required. >> >> Any thoughts on this? >> >> Thanks! >> - Doug >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From dmarkman at mac.com Tue Mar 21 16:05:17 2006 From: dmarkman at mac.com (Dmitry Markman) Date: Tue, 21 Mar 2006 18:05:17 -0500 Subject: [Rxtx] PATCH: use of ioctl(fd, TIOCEXCL) instead of lockfiles In-Reply-To: References: <923AE774-EEA2-4911-92D8-32BB27802C8B@buechse.de> Message-ID: <512AC70C-BB86-48F2-A83C-023F35C23BAB@mac.com> I think it's cool, but I'd like to have that property implementation when user can choose between locking mechanism about comments: it's easy to change comments to the C style or we can use extensions of the file to cpp so c++ compiler will be used On Mar 21, 2006, at 1:05 PM, Trent Jarvi wrote: > This looks like a good start. What do you think Dmitry? Perhaps > all systems with TIOCEXCL defined should use that though. Even if > they use lockfiles. It wont hurt anything. That would catch > people hacking their own serial apps without checking lockfiles. > > Its a good idea to avoid C++ style comments in the C portions. > Some older systems don't deal with them well. If it's just for Mac > OS X, it isn't a big deal. I think it was the Irix compiler that > was problematic? Dmitry Markman From dmarkman at mac.com Tue Mar 21 16:13:00 2006 From: dmarkman at mac.com (Dmitry Markman) Date: Tue, 21 Mar 2006 18:13:00 -0500 Subject: [Rxtx] PATCH: use of ioctl(fd, TIOCEXCL) instead of lockfiles In-Reply-To: References: <923AE774-EEA2-4911-92D8-32BB27802C8B@buechse.de> Message-ID: I'd like to add that creating locking folder isn't a big deal we never had a problem related to the lock folders, because we always used installer on mac os x from other hand I'm not very much familiar with iotcl locking approach and I'm not sure it's more efficient Joachim wrote "I think it is the way to go, as it eliminates creating the lock directory which doesnt exist on the standard installation and it eliminates messing with the system group definitions (adding users to group uucp)." but I really didn't have any problem with that 1. doesn't exist on the standard installation there are many-many things that don't exist in the standard installation so I don't think that argument is strong enough 2. messing with the system group definitions I don't think we're messing with the group definition mac os x provides very clear way to set up group's members and together with Greg Guerin AuthKit there is no problem to set those definitions so I don't think that argument is strong either but from other hand using iotcl is more promising and is more elegant On Mar 21, 2006, at 1:05 PM, Trent Jarvi wrote: > > This looks like a good start. What do you think Dmitry? Perhaps > all systems with TIOCEXCL defined should use that though. Even if > they use lockfiles. It wont hurt anything. That would catch > people hacking their own serial apps without checking lockfiles. Dmitry Markman From joachim at buechse.de Wed Mar 22 04:46:45 2006 From: joachim at buechse.de (Joachim Buechse) Date: Wed, 22 Mar 2006 12:46:45 +0100 Subject: [Rxtx] PATCH: use of ioctl(fd, TIOCEXCL) instead of lockfiles In-Reply-To: References: <923AE774-EEA2-4911-92D8-32BB27802C8B@buechse.de> Message-ID: Sorry, I was not very clear with my arguments, so I will try again;-) Please, don't take this as an attack against work that has been done. I think the contributions that have been made in the past were made in a good spirit. But I really believe, that the current solution for OSX has many shortcomings and should be changed as soon as possible. lock files --- The /var/lock folder does not exist on the standard OSX installation, however the standard installation includes several applications that use serial ports (i.e. the FAX capability). This indicates, that the lock folder approach will not work well with system components. Applications for OSX will generally try to live in harmony with system components (except for HP print drivers of course). I think RXTX should follow this approach as well. uucp group --- Accessing serial ports is not an admin privileged operation on OSX. Any user (world) has read/write privileges on /dev/tty*. So the system default is to not enforce any group membership to access these ports. The group uucp however is a system group on all unix systems I know. It exists for certain system processes. A non admin user should in general not be a member of this group. Quite arguably no user should ever be a member of this group. Installer --- My general opinion is, that - no Installer should touch user or group data without warning - no Application Installer should touch groups which are not specific to the very application installed - no Installer should ever add regular users to a system group The current installer injects the installing user in the group uucp without warning about this change and without giving the option to "opt out" of this change. This is a potential security risk (but not currently a real one, as OSX contains no folders belonging to group uucp). The current installer does not work for multi user systems. It puts the installing user in the uucp group. However the installing user is not necessarily the user that will use the application. Putting all users that may use a serial port application in the system group uucp seems like a very invasive approach to me. Besides that, newly created users will not automatically be in the group and hence, serial applications will "break" for new users without obvious reasons. Avoiding the lock files will allow self contained applications (i.e. drag&drop installation). In my eyes this is largely preferable over an installer that requests admin privileges. Adding up all these points indicates very strongly, that the lock-file implementation is not the way to go on OSX. Regards, Joachim On 22.03.2006, at 00:13, Dmitry Markman wrote: > I'd like to add that > > creating locking folder isn't a big deal > we never had a problem related to the lock folders, because we > always used installer on mac os x > from other hand I'm not very much familiar with iotcl locking > approach and I'm not sure it's more efficient > > Joachim wrote "I think it is the way to go, as it eliminates > creating the lock directory which doesnt exist on the standard > installation and it eliminates messing with the system group > definitions (adding users to group uucp)." but I really didn't have > any problem with that > > 1. doesn't exist on the standard installation > there are many-many things that don't exist in the standard > installation so I don't think that argument is strong enough > 2. messing with the system group definitions > I don't think we're messing with the group definition > mac os x provides very clear way to set up group's members and > together with Greg Guerin AuthKit there is no problem to set those > definitions > so I don't think that argument is strong either > but from other hand using iotcl is more promising and is more elegant > > > > On Mar 21, 2006, at 1:05 PM, Trent Jarvi wrote: > >> >> This looks like a good start. What do you think Dmitry? Perhaps >> all systems with TIOCEXCL defined should use that though. Even if >> they use lockfiles. It wont hurt anything. That would catch >> people hacking their own serial apps without checking lockfiles. > > Dmitry Markman > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From dmarkman at mac.com Wed Mar 22 05:27:13 2006 From: dmarkman at mac.com (Dmitry Markman) Date: Wed, 22 Mar 2006 07:27:13 -0500 Subject: [Rxtx] PATCH: use of ioctl(fd, TIOCEXCL) instead of lockfiles In-Reply-To: References: <923AE774-EEA2-4911-92D8-32BB27802C8B@buechse.de> Message-ID: <83440CF3-DCD8-41C1-B941-F227232C27E3@mac.com> thanks for the very good explanation I didn't think that you were attacking any thing, so don't worry I just had feeling, that there were more aesthetic reasons for going to ioctl then real necessity now you explained everything quite well (BTW, asfar as I remember installer asks admin password so it wasn't quiet, but it really doesn't matter now) thanks On Mar 22, 2006, at 6:46 AM, Joachim Buechse wrote: > Sorry, I was not very clear with my arguments, so I will try again;-) > > Please, don't take this as an attack against work that has been > done. I think the contributions that have been made in the past > were made in a good spirit. But I really believe, that the current > solution for OSX has many shortcomings and should be changed as > soon as possible. > > lock files > --- > The /var/lock folder does not exist on the standard OSX > installation, however the standard installation includes several > applications that use serial ports (i.e. the FAX capability). This > indicates, that the lock folder approach will not work well with > system components. Applications for OSX will generally try to live > in harmony with system components (except for HP print drivers of > course). I think RXTX should follow this approach as well. > > uucp group > --- > Accessing serial ports is not an admin privileged operation on OSX. > Any user (world) has read/write privileges on /dev/tty*. So the > system default is to not enforce any group membership to access > these ports. The group uucp however is a system group on all unix > systems I know. It exists for certain system processes. A non admin > user should in general not be a member of this group. Quite > arguably no user should ever be a member of this group. > > Installer > --- > My general opinion is, that > - no Installer should touch user or group data without warning > - no Application Installer should touch groups which are not > specific to the very application installed > - no Installer should ever add regular users to a system group > > The current installer injects the installing user in the group uucp > without warning about this change and without giving the option to > "opt out" of this change. This is a potential security risk (but > not currently a real one, as OSX contains no folders belonging to > group uucp). > > The current installer does not work for multi user systems. It puts > the installing user in the uucp group. However the installing user > is not necessarily the user that will use the application. Putting > all users that may use a serial port application in the system > group uucp seems like a very invasive approach to me. Besides that, > newly created users will not automatically be in the group and > hence, serial applications will "break" for new users without > obvious reasons. > > > Avoiding the lock files will allow self contained applications > (i.e. drag&drop installation). In my eyes this is largely > preferable over an installer that requests admin privileges. Adding > up all these points indicates very strongly, that the lock-file > implementation is not the way to go on OSX. > > Regards, > Joachim > > > On 22.03.2006, at 00:13, Dmitry Markman wrote: > >> I'd like to add that >> >> creating locking folder isn't a big deal >> we never had a problem related to the lock folders, because we >> always used installer on mac os x >> from other hand I'm not very much familiar with iotcl locking >> approach and I'm not sure it's more efficient >> >> Joachim wrote "I think it is the way to go, as it eliminates >> creating the lock directory which doesnt exist on the standard >> installation and it eliminates messing with the system group >> definitions (adding users to group uucp)." but I really didn't >> have any problem with that >> >> 1. doesn't exist on the standard installation >> there are many-many things that don't exist in the standard >> installation so I don't think that argument is strong enough >> 2. messing with the system group definitions >> I don't think we're messing with the group definition >> mac os x provides very clear way to set up group's members and >> together with Greg Guerin AuthKit there is no problem to set those >> definitions >> so I don't think that argument is strong either >> but from other hand using iotcl is more promising and is more elegant >> >> >> >> On Mar 21, 2006, at 1:05 PM, Trent Jarvi wrote: >> >>> >>> This looks like a good start. What do you think Dmitry? Perhaps >>> all systems with TIOCEXCL defined should use that though. Even >>> if they use lockfiles. It wont hurt anything. That would catch >>> people hacking their own serial apps without checking lockfiles. >> >> Dmitry Markman >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx Dmitry Markman From lyon at docjava.com Wed Mar 22 06:12:18 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Wed, 22 Mar 2006 08:12:18 -0500 Subject: [Rxtx] sole of a new design pattern Message-ID: Hi All, I have been thinking about how we design the serial port software. I think we need a new design pattern. For lack of a better term, I shall call it: The Parametric Singleton Design Pattern By Douglas A. Lyon ABSTRACT The goal of the singleton design pattern is to make sure that there is one, and only one, instance of a given class. The goal of the parametric singleton design pattern is to make sure that there is one, and only one, instance of a given class with the given parametric values. We parametric singleton design pattern combines the singleton design pattern with a parameter that enables unique creation of instances of a class. These instances are cached. When a user asks for an instance with these parameters, the cache is checked. If the instance is in the cache, the instance is returned, otherwise it is created, added to the cache and then returned. We apply our parametric singleton design pattern to the retrieval of RMI registries bound to a given port. The goal of our system is to make sure that no two RMI registries are listening to the same socket and to make use of the RMI registries after they have been created. RMI registries are used in distributed computation. Introduction The singleton design pattern is meant to ensure that on a single instance of a class exists. It is also meant to provide a global point of access to it. The intent of the parametric singleton design pattern is to ensure that a class has only one instance for a given set of parameter values. It also provides a global point of access to it. Motivation A system cannot tolerate multiple instances of some classes with identical parameters. For example, you cannot have two instances making use of the same serial port, at the same time. You cannot have two instances that are trying to listen to the same socket connection. You cannot have two instances writing to the same file structure at the same time. As the operating system is often thought of as the arbiter of consumed resources (i.e., tape drives, serial ports, etc.) we frequently leave it to an operating system implementation to resolve these contention issues. Even for similar resources (like serial ports) there are few standards for handling contention. For example, serial ports on Linux are locked using a "/var/lock" file. POSIX, on the other hand, uses ioctl mechanisms to prevent contention. A better solution is to make a class that is responsible for keeping track of the instances created from the class. The class is declared final, so that it cannot be subclassed. The class also has a private constructor, so that other classes cannot instance it. The new design pattern is called the parametric singleton design pattern and it provides a way to access and create instances with given parameters. Applicability Use the Parametric Singleton Design Pattern when: 1. There must be exactly one instance of a class with the given parameters. 2. The instances must be accessible to clients from a well-known access point. Structure Insert UML diagram here. Participants The Parametric Singleton Clients that need instances 1. The Parametric Singleton defines an instance upon request from a client, if, and only if, the instance does not already exist. 2. The Parametric Singleton returns the instance to the client. 3. The Parametric Singleton is responsible for creating unique instances from given parameters. Collaborations Clients obtain a reference to a Parametric Singleton instance only through the parametric singleton design pattern. If the instance is left in an improper state (e.g., the serial port was left open) it is NOT the role of the Parametric Singleton Design Pattern to close the IO port. Nor is it the role of the Parametric Singleton Design Pattern to open the port. That role is delegate to some other part of the system. Further, it is not the role of the Parametric Singleton Design Pattern to check out resources. That is, multiple threads can have multiple references to the same resource at the same time. MUTEX locking is delegated to some other part of the system. Consequences The Parametric Singleton Design Pattern has several benefits: 1. Controlled access to parametrically defined instances. Since the Parametric Singleton class encapsulates its instances, there is control over how and when clients access it. 2. Reduced name space. The Parametric Singleton pattern avoids global variables that store instances created from the same parameter. Implementation Here are implementation issues to consider when using the Parametric Singleton pattern: 1. Unique mapping of parameters. The Parametric Singleton pattern requires that there be a mean to isomorphically map the parameter space into the instance space and back again. 2. Ensure unique instances. The Parametric Singleton pattern makes unique instances from parameters, and it does so only once. 3. Cache instances for fast retrieval. The Parametric Singleton pattern must be able to look up instances, given some set of parameters, and do so from some data structure. That is, there must be enough space to hold references to all the instances the program will need. Also, a mechanism is needed to look up and retrieve the instances quickly enough to satisfy the clients. Sample Code public final class ParametricSingletonRmiRegistry { private static Hashtable registry = new Hashtable(100); // use singleton pattern and??????????????????????????????????????????????? // prevent instantiation of RmiRegistryUtils.?????????????????????????????? private ParametricSingletonRmiRegistry() { } // the only instance of the Registry held by the RmiRegistryUtils?????????? public static void listNames(Integer port) { if (!isInCacheAndRunning(port)) return; Registry r = (Registry) registry.get(port); System.out.println("registry on port: " + port); System.out.println("registry: " + r); System.out.println("names: "); try { print(r.list()); } catch (RemoteException e) { In.message(e); } System.out.println("------------------------"); } /**???????????????????????????????????????????????????????????????????????? * Checks whether a Registry has been started on this host????????????????? * in the specified port.?????????????????????????????????????????????????? * If not, it tries to start one.?????????????????????????????????????????? * when it fails to start a Registry, it exits the program????????????????? * with exit code 1.??????????????????????????????????????????????????????? */ public static void restart(int port) { if (isInCacheAndRunning(port)) return; try { startRegistry(port); } catch (RemoteException e) { In.message(e); } } /**???????????????????????????????????????????????????????????????????????? * @param port????????????????????????????????????????????????????????????? * @return true if registry is in cache and running???????????????????????? */ private static boolean isInCacheAndRunning(Integer port) { if (!isRegistryRunning(port.intValue())) return false; if (!isRegistryInCache(port.intValue())) return false; return true; } /**???????????????????????????????????????????????????????????????????????? * @param port????????????????????????????????????????????????????????????? * @return true if we are able to locate a local registry on port.??????????????????????????????????????????????????????????????????????????? */ private static boolean isRegistryRunning(int port) { try { Registry r = LocateRegistry.getRegistry(port); if (r != null) return true; } catch (RemoteException e) { return false; } return false; } /**???????????????????????????????????????????????????????????????????????? * @param port????????????????????????????????????????????????????????????? * @return return true if registry is in cache????????????????????????????? */ private static boolean isRegistryInCache(int port) { if (registry.get(new Integer(port)) == null) return false; return true; } /**???????????????????????????????????????????????????????????????????????? * Restart the registry, if needed.???????????????????????????????????????? * Return the only instance of the registry for consistent global?????????? * using by making use of the Singleton Design Pattern????????????????????? *????????????????????????????????????????????????????????????????????????? * @return the internally held registry instance.?????????????????????????? */ public static Registry getRegistry(Integer port) { restart(port); return (Registry) registry.get(port); } private static void startRegistry(Integer port) throws RemoteException { Registry r; try { r = LocateRegistry.createRegistry(port.intValue()); registry.put(port, r); //r = new sun.rmi.registry.RegistryImpl???????????????????????????? /// (port.intValue());?????????????????????????????????????? // registry.put(port, r);?????????????????????????????????????????? } catch (Exception e) { //e.printStackTrace();????????????????????????????????????????????? r = LocateRegistry.getRegistry(port.intValue()); registry.put(port, r); } } public static void main(String args[]) throws RemoteException { //restart(port);??????????????????????????????????????????????????????? restart(5001); restart(5002); restart(5002); Registry r = LocateRegistry.getRegistry(5002); System.out.println("registry="+r); } } I would very much like to get your feedback on this new design pattern idea. Thank you for your time. Regards, - Doug From david.garnier at trusted-logic.com Wed Mar 22 07:36:10 2006 From: david.garnier at trusted-logic.com (David Garnier) Date: Wed, 22 Mar 2006 15:36:10 +0100 Subject: [Rxtx] sole of a new design pattern In-Reply-To: References: Message-ID: <442160DA.80107@trusted-logic.com> Hello, > The Parametric Singleton Design Pattern The Singleton is the most abused design pattern ever. Good use-cases for this pattern are extremely rare and mostly confined to problems related to hardware resources, like serial ports. > Applicability > > Use the Parametric Singleton Design Pattern when: > 1. There must be exactly one instance of a class with the given > parameters. OK. As I said above, this case this actually very unusual. The Singleton pattern is mostly used when : > 2. The instances must be accessible to clients from a well-known > access point. Using the singleton pattern in this case is just convenient for the programmer. Problems arises pretty quickly, especially if you attempt to unit-test your classes. 1) If your singleton is stateful, or hold on to stateful objects, it means that two different unit tests are not actually independent. Instead of starting with a brand new environment, the result of a test may be affected by the result of a previous test. This problem also arise when with your class relies on a database. In both cases, the solution is to reset your "unique" resource (Singleton or database) at the beginning of the test, which is a pain. Also, while most projects connect to a single database, projects that allow the use of Singletons usually contain several of thems, and new ones may cropped up unnoticed. You quickly end up with test cases that only pass in a certain order, which is a royal pain. 2) You cannot mockup a singleton. Once everyone calls the SomeSingleton class statically, you can't replace your class by SomeSingletonMockup. Furthermore, even for hardware services, the Singleton pattern does not really prevent concurrent accesses. If you start the same program in two different JVMs, unless they somehow shared the state of their "Singletons" (through lock files for example), the Singleton pattern will not prevent concurrent access. Our application uses RXTX, and we routinely encounter cases where another (native) application has already locked the port. Since we cannot modify the native application to recognize lock files, OS-level control is irreplaceable. > > Consequences > The Parametric Singleton Design Pattern has several benefits: > > 1. Controlled access to parametrically defined instances. Since > the Parametric Singleton class encapsulates its instances, there is > control over how and when clients access it. Not really. Once you've returned the instance to a client, you've lost control over it. The client can to whatever it wants with it. You cannot "recall" the instance or claim it back. > 2. Reduced name space. The Parametric Singleton pattern avoids > global variables that store instances created from the same parameter. Sure, but you don't have to rely on a Singleton for that. Just create a single Factory. > I would very much like to get your feedback on this new design > pattern idea. Well, it's nothing new. Some may say that it is the point of design patterns: formalizes the designs that occur again and again. However, this design is simply a combination of the Singleton and Factory patterns. I did use it in the past, but now I've been exposed to the shortcomings of the Singleton pattern, so I limit myself to Factories. Regards, David From sean_montgomery at baseview.com Wed Mar 22 08:35:28 2006 From: sean_montgomery at baseview.com (Sean Montgomery) Date: Wed, 22 Mar 2006 10:35:28 -0500 Subject: [Rxtx] sole of a new design pattern In-Reply-To: <442160DA.80107@trusted-logic.com> References: <442160DA.80107@trusted-logic.com> Message-ID: <05769CA7-A51B-4CF0-BAA0-E02DD905F5A4@baseview.com> On Mar 22, 2006, at 9:36 AM, David Garnier wrote: > Furthermore, even for hardware services, the Singleton pattern does > not really prevent concurrent > accesses. If you start the same program in two different JVMs, > unless they somehow shared the state > of their "Singletons" (through lock files for example), the > Singleton pattern will not prevent > concurrent access. > Multiple class loaders in a single JVM can be tricky, too. Then there's synchronization, lazy initialization and serialization of singletons to contend with. Bloch's Effective Java covers these, and here's a few articles: http://www.javaworld.com/javaworld/jw-04-2003/jw-0425-designpatterns- p3.html http://java.sun.com/developer/technicalArticles/Programming/singletons/ Just FYI :-) From lyon at docjava.com Wed Mar 22 08:50:48 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Wed, 22 Mar 2006 10:50:48 -0500 Subject: [Rxtx] sole of a new design pattern In-Reply-To: <442160DA.80107@trusted-logic.com> References: <442160DA.80107@trusted-logic.com> Message-ID: Hi All, First, I would like to thank David for his prompt and thoughtful remarks. I had no idea people that feel strongly about a design patterns! Wow! Feedback (particularly critical feedback) is greatly appreciated. Starting at the end, first: >I did use it in >the past, but now I've been exposed to the shortcomings of the >Singleton pattern, so I limit myself to Factories. David, if I understood your comments correctly, you suggested that Factories can be used in leu of the Singleton Design Pattern, or even the Parametric Singleton Design Pattern. As I see in [Gof]: Factory Method: Intent "Define an interface for creating an object, but let subclasses decide which class to instantiate. Factory Method lets a class defer instantiation to subclasses." The Singleton Design Pattern is a concrete class, which is rather different, right? Also, subclasses are not permitted with Singleton, as they are final. Naturally, I could use an abstract factory as a parent for a singleton. I could even design a facade that could be implemented with the singleton....but that is not the intention of the design. Unless you want a mock-up, as discussed, below: More below: >Hello, > >> The Parametric Singleton Design Pattern > >The Singleton is the most abused design pattern ever. Good use-cases >for this pattern are extremely >rare and mostly confined to problems related to hardware resources, >like serial ports. > > >> Applicability >> >> Use the Parametric Singleton Design Pattern when: >> 1. There must be exactly one instance of a class with the given >> parameters. >OK. As I said above, this case this actually very unusual. The >Singleton pattern is mostly used when : >> 2. The instances must be accessible to clients from a well-known >> access point. > >Using the singleton pattern in this case is just convenient for the >programmer. Problems arises >pretty quickly, especially if you attempt to unit-test your classes. > >1) If your singleton is stateful, or hold on to stateful objects, it >means that two different unit >tests are not actually independent. Instead of starting with a brand >new environment, the result of >a test may be affected by the result of a previous test. This >problem also arise when with your >class relies on a database. In both cases, the solution is to reset >your "unique" resource >(Singleton or database) at the beginning of the test, which is a >pain. Also, while most projects >connect to a single database, projects that allow the use of >Singletons usually contain several of >thems, and new ones may cropped up unnoticed. You quickly end up >with test cases that only pass in a >certain order, which is a royal pain. There are basic problems with communicating finite state machines that include reachability and deadlock analysis. These are addressed with petri net analysis and are beyond the scope of the design pattern. As you quite rightly pointed out; the parametric singleton pattern (or the singleton pattern, for that matter) enable multiple threads to gain access to the same instance. The only way that I can see to block others from gaining access to the reference is the synchronize keyword. This is putting a spin-lock (or MUTEX) on the reference. The question of how to unit-test a design pattern like the parametric singleton remains open. Perhaps this is a deficiency. > >2) You cannot mockup a singleton. Once everyone calls the >SomeSingleton class statically, you can't >replace your class by SomeSingletonMockup. Acutally, I am not sure that this is true. If the Singleton implements a Facade interface, it should be possible to make the replacement. Right? > >Furthermore, even for hardware services, the Singleton pattern does >not really prevent concurrent >accesses. If you start the same program in two different JVMs, >unless they somehow shared the state >of their "Singletons" (through lock files for example), the >Singleton pattern will not prevent >concurrent access. Good Point!! You have sharp eyes! The singleton design pattern should/could take responsibility for this. In fact, you may notice that my code does have an implementation (LocateRegistry) that can work across JVM's. The LocateRegistry will even work across the Internet! LocateRegistry takes both a host name and a Port (lock files just don't do this). I did not think to implement this beyond the local machine, but, in its present form, it will work across different processes. > >Our application uses RXTX, and we routinely encounter cases where >another (native) application has >already locked the port. Since we cannot modify the native >application to recognize lock files, >OS-level control is irreplaceable. The singleton design pattern is not meant to replace OS-level control, but to centralize the Java programmers access to it. If lock files, for example, are used for serial ports, the Singleton Design Pattern should be able to work with them. > > >> >> Consequences >> The Parametric Singleton Design Pattern has several benefits: >> > > 1. Controlled access to parametrically defined instances. Since >> the Parametric Singleton class encapsulates its instances, there is >> control over how and when clients access it. > >Not really. Once you've returned the instance to a client, you've >lost control over it. The client >can to whatever it wants with it. You cannot "recall" the instance >or claim it back. Good point, this should read: > 1. Controll when parametrically defined instances are created. Since > > the Parametric Singleton class encapsulates its instances, there is > > control over how and when they are instanced. > >> 2. Reduced name space. The Parametric Singleton pattern avoids >> global variables that store instances created from the same parameter. > >Sure, but you don't have to rely on a Singleton for that. Just >create a single Factory. > > Thank you for your thoughtful and prompt response! Regards, - Doug From dmarkman at mac.com Wed Mar 22 21:21:55 2006 From: dmarkman at mac.com (Dmitry Markman) Date: Wed, 22 Mar 2006 23:21:55 -0500 Subject: [Rxtx] sole of a new design pattern In-Reply-To: <442160DA.80107@trusted-logic.com> References: <442160DA.80107@trusted-logic.com> Message-ID: I don't think I get it On Mar 22, 2006, at 9:36 AM, David Garnier wrote: > Using the singleton pattern in this case is just convenient for the > programmer. Problems arises > pretty quickly, especially if you attempt to unit-test your classes. so you're saying that something isn't so good because you can not test it in the convenient way? if that's true, I'm totally disagree change your test, debug whatever, but if software is efficient at runtime, works fine and only problem is some unit test (which is some kind of framework for testing) then dump that unit test , dump that unit framework and make something appropriate to the software you're testing so if Douglas want to use singletons, what's the problem? and what do you mean by abusing of singleton usage? of course singleton doesn't prevent concurrent access to the resource across the processes unless you're using some OS facility to prevent it, besides singleton as it was introduced is relevant only and only inside of the same process otherwise it's not singleton it's something else (let's say network singleton: so you have remote invocation facility and some factory method that return object created by that facility) I don't have any problem with using any kind of singletons. Parametric Singleton idea (if I understand it right) could be easily implemented in the following way: use a map populate map with instances of some class and key is your parameter (you can use lazy population too) if somebody ask the key check the value if it's null so resource is taken if somebody returns the resource put it back to the map public synchronized static Object getSomeResource(Object parameter); public synchronized static void returnResource(Object parameter); getSomeResource (inside of the same process) could return null in 2 cases 1. if somebody (from other thread for example) already took that resource 2. if OS API said that resource corresponded to that parameter (serial port with parameter = 1 (port #)) is locked and unavailable; I'm not sure that in case of serial ports we even need those Parametric Singletons (unless lock checking is a very expensive operation) just ask the OS about availability of that resource and if it's available give it away and then OS will lock it and therefore in next time somebody ask it just answer that resource is locked and return null for example system has 2 serial ports available so I ask getResource("tty"); or I ask getResource("Bluetooth-Modem"); and if OS is ok you can give tty or Bluetooth-Modem or both no need for any additional pattern I think back to the problem mac os x doesn't recognize locking via files, so it handles locking via some API an instance of the singleton in each process should recognize that resource is locked (by using that API) that's all we don't have to make things more complicate then they are just because there is some nice design pattern or nice unit test framework or whatever keep things simple, make them work fast, don't introduce middle layers unless you have really good reason to do so of course I could be entirely wrong, so sorry about that in advance thanks Dmitry Markman From tjarvi at qbang.org Wed Mar 22 22:31:41 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 22 Mar 2006 22:31:41 -0700 (MST) Subject: [Rxtx] sole of a new design pattern In-Reply-To: References: Message-ID: Hi Doug Interesting reading. So far I'm just reading and thinking. I have one question so far. " Clients obtain a reference to a Parametric Singleton instance only through the parametric singleton design pattern. If the instance is left in an improper state (e.g., the serial port was left open) it is NOT the role of the Parametric Singleton Design Pattern to close the IO port. Nor is it the role of the Parametric Singleton Design Pattern to open the port. That role is delegate to some other part of the system. " So when the clients obtain a reference to the singleton, can they assume the port is there? IE, would it be the singletons role to handle things like USB dongles being removed with event hints comming from the underlying OS. Hardware abstraction layer/HAL on Linux is an example of underlying OS events. I assume that role too is delegated to other parts of the system? -- Trent Jarvi tjarvi at qbang.org From lyon at docjava.com Thu Mar 23 08:10:33 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Thu, 23 Mar 2006 10:10:33 -0500 Subject: [Rxtx] Classes don't need goals, they need roles! In-Reply-To: References: Message-ID: Hi Trent, Yes, I think that the role of the Parametric Singleton Pattern is not to open or close serial ports, nor is it to perform error checking. On the other hand, if you were to combine the role of the Parametric Singleton Pattern with another role (like that of error checking) it might not be amiss. However, I generally caution programmers against adding multiple roles to classes, as this leads to monolithic designs. Thus a different class (NativeLibDetect) could have the role of determining if the native library can be loaded. Another class (SerialPortBean) can have the role of serializing the default state of the serial port, so that it can be recovered, from user preferences, at a later time. The SerialPortDetect could have the role of determining if the serial port is removed (i.e., a USB port was unplugged). My guess is that each class should have a different role in the system, in order to ease maintenance and testing...but I could be wrong about that. Thanks! - Doug >Hi Doug > >Interesting reading. So far I'm just reading and thinking. I have >one question so far. > >" > Clients obtain a reference to a Parametric Singleton instance only >through the parametric singleton design pattern. If the instance is >left in an improper state (e.g., the serial port was left open) it is >NOT the role of the Parametric Singleton Design Pattern to close the >IO port. Nor is it the role of the Parametric Singleton Design Pattern >to >open the port. That role is delegate to some other part of the system. >" > >So when the clients obtain a reference to the singleton, can they >assume the port is there? IE, would it be the singletons role to >handle things like USB dongles being removed with event hints >comming from the underlying OS. Hardware abstraction layer/HAL on >Linux is an example of underlying OS events. > >I assume that role too is delegated to other parts of the system? > >-- >Trent Jarvi >tjarvi at qbang.org >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From maximulo at yahoo.com Fri Mar 24 01:22:38 2006 From: maximulo at yahoo.com (Maximulo Majir) Date: Fri, 24 Mar 2006 00:22:38 -0800 (PST) Subject: [Rxtx] JavaPOS Message-ID: <20060324082238.66371.qmail@web38214.mail.mud.yahoo.com> Hi all! Hello Trent! From what i understand, RXTX or JavaComm APIs were not created solely for JavaPOS. In JavaPOS, we have the virtual method claim() which is separate from open(), but in our RXTX API, claiming is done every call to open(), we cant open the port if its claimed by another application. Would it be alright to suggest or ask to create a new method called claim(..)? Is there such thing as forceclaim() in RXTX? this could be the same as portownership transfer or its equivalent. ForceClaim is in JSR80. Do you have some samples using RXTX as the lower layer for the Device Service Objects in JavaPOS? I have tried it, i just want to compare. Thank you all! maxim __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060324/496adba2/attachment-0013.html From tjarvi at qbang.org Fri Mar 24 11:28:19 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 24 Mar 2006 11:28:19 -0700 (MST) Subject: [Rxtx] Re: RXTX 2.1 Solaris Problems In-Reply-To: <3691.1143210578@www045.gmx.net> References: <3691.1143210578@www045.gmx.net> Message-ID: On Fri, 24 Mar 2006, Andreas Guenther wrote: > Hi all, > > the solaris problem was not the lock file only. > > Ok, I had to create the directory /var/spool/locks myself. > /var/spool/uucp exists. > > But rxtx didn't find any port. > > I compiled the source with my own debug-informations > and I tried to isolate the problem. > > The problem is the testRead-call in SerialImp.c > > JNIEXPORT jboolean JNICALL RXTXCommDriver(testRead)( > > ... > if ( READ( fd, &c, 1 ) < 0 ) > { > if ( errno != EAGAIN ) { > report( "testRead() read failed\n" ); > ret = JNI_FALSE; > } > } > Thanks Andreas I'm packing up to move. I'll be more or less away for a couple weeks here. I'll be checking email but my workstation is going into a box soon. This isn't hard to fix as this port should be enumerated when EWOULDBLOCK is recieved. Thats error is OK for enumeration just as EAGAIN is. I've put the bug into bugzilla so we dont forget to get to it. http://bugzilla.qbang.org/show_bug.cgi?id=42 You can add yourself to the CC list if you wish to test fixes we provide or even put a patch into bugzilla yourself. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Fri Mar 24 11:51:52 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 24 Mar 2006 11:51:52 -0700 (MST) Subject: [Rxtx] JavaPOS In-Reply-To: <20060324082238.66371.qmail@web38214.mail.mud.yahoo.com> References: <20060324082238.66371.qmail@web38214.mail.mud.yahoo.com> Message-ID: On Fri, 24 Mar 2006, Maximulo Majir wrote: > Hi all! Hello Trent! > > > From what i understand, RXTX or JavaComm APIs were not > created solely for JavaPOS. In JavaPOS, we have the virtual method > claim() which is separate from open(), but in our RXTX API, claiming is > done every call to open(), we cant open the port if its claimed by > another application. Would it be alright to suggest or ask to create a > new method called claim(..)? Is there such thing as forceclaim() in > RXTX? this could be the same as portownership transfer or its > equivalent. ForceClaim is in JSR80. > Do you have some samples using RXTX as the lower layer for the Device > Service Objects in JavaPOS? I have tried it, i just want to compare. > maxim Hi Maxim JSR80 is the USB API IBM/Sun put together. The problem is they have a richer kernel/API underneath that can handle such things. With Serial Ports, there isnt anything there other than an ioctl that says don't let anyone touch this and lockfiles that are more of a 'lets be nice.' At times we may be using USB ports but it is through the termios layer with the limitations mentioned. The advantage is that not only USB will work with rxtx. Anything that has a termios layer should work (to the extent that termios layer is complete). I don't know how forceclaim() would help you. Lets say someone has a programmer working on /dev/ttyS0 and you take it. Now you both race each other to read data first. There isn't a mechanism I know of that will solve this problem in termios. The most obvious test being a native app and a Java app trying to take the port. There is the potential of requestion ownership from other Java Applications but the use for that is very rare. Did you have something more specific in mind that I'm missing? I'm not sure that claim() and forceclaim() would help you with rxtx other than maybe locking the port with claim() without opening it. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sat Mar 25 23:42:08 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 25 Mar 2006 23:42:08 -0700 (MST) Subject: [Rxtx] Serial snoop Message-ID: I was reading the Linux kernel mail-list tonight and ran past a thread that mentioned sersnoop. This looks like a handy tool for people dealing with new toys. "a simple command-line tool for linux that echoes bytes to and from any two serial ports, ptys, or network sockets, and prints all traffic to stdout, in hex and ascii." http://www.restivo.org/projects/sersnoop/ It works on Linux only at this time (debian package available). -- Trent Jarvi tjarvi at qbang.org From beat.arnet at gmail.com Sun Mar 26 07:32:35 2006 From: beat.arnet at gmail.com (Beat Arnet) Date: Sun, 26 Mar 2006 09:32:35 -0500 Subject: [Rxtx] Error 0x5 at /home/bob/foo/tar/rxtx-2.1-7/build/../src/termios.c(860): Access is, denied. Message-ID: <4426A603.80508@gmail.com> Dear all, When trying to open the serial port, I sometimes (not always) run into the following exception (when opening the serialPort): Error 0x5 at /home/bob/foo/tar/rxtx-2.1-7/build/../src/termios.c(860): Access is denied. java.lang.UnsatisfiedLinkError: native_psmisc_report_owner at gnu.io.CommPortIdentifier.native_psmisc_report_owner(Native Method) at gnu.io.CommPortIdentifier.open(CommPortIdentifier.java:354) at codeskin.tools.CLLoader.open(CLLoader.java:79) at codeskin.tools.C2000Programmer.run(C2000Programmer.java:220) at java.lang.Thread.run(Unknown Source) Is this the type of error where I should just try to open the port again, or can it be avoided? Regards, Beat From tjarvi at qbang.org Sun Mar 26 11:40:12 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 26 Mar 2006 11:40:12 -0700 (MST) Subject: [Rxtx] Error 0x5 at /home/bob/foo/tar/rxtx-2.1-7/build/../src/termios.c(860): Access is, denied. In-Reply-To: <4426A603.80508@gmail.com> References: <4426A603.80508@gmail.com> Message-ID: On Sun, 26 Mar 2006, Beat Arnet wrote: > Dear all, > > When trying to open the serial port, I sometimes (not always) run into > the following exception (when opening the serialPort): > > Error 0x5 at /home/bob/foo/tar/rxtx-2.1-7/build/../src/termios.c(860): > Access is > denied. > > java.lang.UnsatisfiedLinkError: native_psmisc_report_owner > at gnu.io.CommPortIdentifier.native_psmisc_report_owner(Native > Method) > at gnu.io.CommPortIdentifier.open(CommPortIdentifier.java:354) > at codeskin.tools.CLLoader.open(CLLoader.java:79) > at codeskin.tools.C2000Programmer.run(C2000Programmer.java:220) > at java.lang.Thread.run(Unknown Source) > > Is this the type of error where I should just try to open the port again, > or can it be avoided? > Hi Beat We did a second build of rxtx 2.1-7 to resolve that unsatisfied link error. It should work now. rxtx is trying to tell you it thinks someone else has the serial port open. You can try to open the port again but maybe you already have a copy of the program running when it happens? ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7r2.zip fixed build. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sun Mar 26 11:44:23 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 26 Mar 2006 11:44:23 -0700 (MST) Subject: [Rxtx] RXTX spec file (fwd) Message-ID: This is probably interesting for fedora/suse users. ---------- Forwarded message ---------- Date: Sun, 26 Mar 2006 16:25:45 +0200 To: taj at www.linux.org.uk Subject: RXTX spec file I send you this spec file which allows to create a RPM for Fedora 4, 5 (x86, x86_64) with Java Sun. -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: rxtx.spec Url: http://mailman.qbang.org/pipermail/rxtx/attachments/20060326/6c7b6af6/rxtx-0009.pl From tjarvi at qbang.org Sun Mar 26 23:42:59 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 26 Mar 2006 23:42:59 -0700 (MST) Subject: [Rxtx] Upcomming events. Message-ID: This Wednesday we will be announcing a new "Maintainer" for the rxtx project. The position is more like neutral leader. I wont be going away or doing less. This is just the right thing to do as it turns out the two people with CVS write access will be at the same company. We need a third and we need neutrality. The maintainer will have final say in any conflict and will try to be neutral. It will be open for discussion. Then we will do it :) I'll still do most of the footwork I do now. But. I'm falling behind. I should have gone through the mail-list and posted the next round of changes this weekend. I'm packing to move and its going so so - 13 years of toys collected. I suspect there will be a dead period on my part (a couple weeks) comming up. But if you get it on the mail-list, we will get it in if there are no objections. I may well not be reading the mail-list during this period as I look for a house and many other things. I hope everyone will help out. Thanks -- Trent Jarvi tjarvi at qbang.org From mahmoud_hadad at yahoo.com Sun Mar 26 07:31:19 2006 From: mahmoud_hadad at yahoo.com (ronan nick) Date: Sun, 26 Mar 2006 06:31:19 -0800 (PST) Subject: [Rxtx] a question about the COMM API Message-ID: <20060326143119.54919.qmail@web60014.mail.yahoo.com> hi, i was intrested in knowing how i can communicate with my internal modem using java? for example if i want to make a phone dialer application or a caller id application where should i be looking at? and as i understood the COMM API is for devices that is attached to the computer through serial ports. --------------------------------- New Yahoo! Messenger with Voice. Call regular phones from your PC and save big. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060326/ce8329f0/attachment-0011.html From dmarkman at mac.com Mon Mar 20 00:20:43 2006 From: dmarkman at mac.com (Dmitry Markman) Date: Mon, 20 Mar 2006 02:20:43 -0500 Subject: [Rxtx] Mac OS X RXTX java installer In-Reply-To: References: <07D0DE29-BA32-4CFE-B036-66BC6423D385@buechse.de> <441AE3E0.2030503@willicon.de> <12531986.1142622114996.JavaMail.dmarkman@mac.com> <441B2674.9010409@willicon.de> <13577405.1142634732776.JavaMail.dmarkman@mac.com> <441B4182.8010407@willicon.de> <92CD0D6C-5BE8-426E-A46D-99452059FF49@mac.com> <441BBB2D.8030305@willicon.de> <441C4088.5090905@willicon.de> Message-ID: <64BC1E23-FDDE-4CE6-8863-CFC881CBC224@mac.com> Hi all I put RXTX installer that will install everything (and will create / var/lock if necessary and add user to the uucp group) for mac os x from Java into the rxtx's CVS repository it could be easily modified to install files for any platform it uses Greg Guerin's AuthKit for authentication and authorization Greg released that kit under artistic license, so Trent, please take a look we, probably, can negotiate license with Greg if it's necessary Greg's AuthKit could be downloaded from http://www.amug.org/~glguerin/ sw/#authkit Michael Hall (mikehall at spacestar dot net) had a suggestion to make implementation of the jaas LoginModule based on Greg's AuthKit (his modification of the Greg's AuthKit could be found at http:// www.spacestar.net/users/mikehall/authkit.dmg) but Michael's AuthKitLoginModule does only half a job: it does authenticate but it can not run any external unix process in privileged mode (at least I wasn't able to do so) possible explanation could be found in conversation between Greg and Michael at Apple's java-dev list (look for archives) so I didn't use jaas API for rxtxinstaller I created folder MacOSX in the contrib folder comment 1. if you want to run that installer as standalone application all you need that RXTXInstaller.jar 2. if you want to use webstart you have to add Greg's libAuthKit.jnilib to the mac os x's resources in theory RXTXInstaller.jar doesn't need it, but there is a problem with loading libAuthKit.jnilib from webstart authkit uses loadLibrary method to load library and it failed (from webstart) for standalone application I extract libAuthKit.jnilib from the RXTXInstaller.jar and put it into the /Library/Java/Extensions or ~/Library/Java/Extensions folder that file will be deleted after installer quit unfortunately I didn't have time to put documentation there but it is mostly self-explanatory I took installer code from my gl4java installer that I did about 3 years ago (with small modifications) it would be very nice if Apple will release LoginModule that really will do the job (com.apple.security.auth.module package????? ) (UnixLoginModule is pretty useless) From lyon at docjava.com Mon Mar 20 06:34:39 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Mon, 20 Mar 2006 08:34:39 -0500 Subject: [Rxtx] Mac OS X RXTX java installer In-Reply-To: <64BC1E23-FDDE-4CE6-8863-CFC881CBC224@mac.com> References: <07D0DE29-BA32-4CFE-B036-66BC6423D385@buechse.de> <441AE3E0.2030503@willicon.de> <12531986.1142622114996.JavaMail.dmarkman@mac.com> <441B2674.9010409@willicon.de> <13577405.1142634732776.JavaMail.dmarkman@mac.com> <441B4182.8010407@willicon.de> <92CD0D6C-5BE8-426E-A46D-99452059FF49@mac.com> <441BBB2D.8030305@willicon.de> <441C4088.5090905@willicon.de> <64BC1E23-FDDE-4CE6-8863-CFC881CBC224@mac.com> Message-ID: Hi Dimitry, This sounds like great work. Just a couple of questions; After the check out of the CVS files, using: setenv CVSROOT :pserver:anonymous at cvs.milestonesolutions.com:/usr/local/cvsroot 53 8:28 setenv PASSWORD mousy 54 8:29 cvs login 55 8:29 cvs checkout rxtx-devel I cd'd over to: rxtx-devel/MACOSX_IDE And found: CVS/ CW/ ForPackageMaker/ PB/ Where is the installer? Thanks! - Doug From tjarvi at qbang.org Mon Mar 20 06:39:37 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 20 Mar 2006 06:39:37 -0700 (MST) Subject: [Rxtx] Mac OS X RXTX java installer In-Reply-To: References: <07D0DE29-BA32-4CFE-B036-66BC6423D385@buechse.de> <441AE3E0.2030503@willicon.de> <12531986.1142622114996.JavaMail.dmarkman@mac.com> <441B2674.9010409@willicon.de> <13577405.1142634732776.JavaMail.dmarkman@mac.com> <441B4182.8010407@willicon.de> <92CD0D6C-5BE8-426E-A46D-99452059FF49@mac.com> <441BBB2D.8030305@willicon.de> <441C4088.5090905@willicon.de> <64BC1E23-FDDE-4CE6-8863-CFC881CBC224@mac.com> Message-ID: On Mon, 20 Mar 2006, Dr. Douglas Lyon wrote: > Hi Dimitry, > This sounds like great work. Just a couple of questions; > After the check out of the CVS files, using: > setenv CVSROOT > :pserver:anonymous at cvs.milestonesolutions.com:/usr/local/cvsroot > 53 8:28 setenv PASSWORD mousy > 54 8:29 cvs login > 55 8:29 cvs checkout rxtx-devel Hi Doug You want "cvs checkout -r commapi-0-0-1 rxtx-devel" to get RXTX 2.1 The default branch is rxtx 2.0 which isn't very active right now. -- Trent Jarvi tjarvi at qbang.org From lyon at docjava.com Mon Mar 20 07:05:44 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Mon, 20 Mar 2006 09:05:44 -0500 Subject: [Rxtx] Mac OS X RXTX java installer In-Reply-To: References: <07D0DE29-BA32-4CFE-B036-66BC6423D385@buechse.de> <441AE3E0.2030503@willicon.de> <12531986.1142622114996.JavaMail.dmarkman@mac.com> <441B2674.9010409@willicon.de> <13577405.1142634732776.JavaMail.dmarkman@mac.com> <441B4182.8010407@willicon.de> <92CD0D6C-5BE8-426E-A46D-99452059FF49@mac.com> <441BBB2D.8030305@willicon.de> <441C4088.5090905@willicon.de> <64BC1E23-FDDE-4CE6-8863-CFC881CBC224@mac.com> Message-ID: Hi Trent, Thanks for the info on the CVS checkout procedure. I did that and am still not sure where the installer is. Here is what I have: cd MACOSX_IDE/ p4.docjava.com{lyon}121: ls CVS/ ForPackageMaker/ PB/ p4.docjava.com{lyon}122: find . | more . ./ForPackageMaker ./ForPackageMaker/RXTX.pkg.sit.hqx ./ForPackageMaker/Resources ./ForPackageMaker/Resources/ReadMe.rtf ./ForPackageMaker/Resources/Welcome.rtf ./ForPackageMaker/Resources/CVS ./ForPackageMaker/Resources/CVS/Entries ./ForPackageMaker/Resources/CVS/Repository ./ForPackageMaker/Resources/CVS/Tag ./ForPackageMaker/Resources/CVS/Root ./ForPackageMaker/Resources/preinstall ./ForPackageMaker/Resources/License.rtf ./ForPackageMaker/Resources/preupgrade ./ForPackageMaker/RXTX.pmsp ./ForPackageMaker/CVS ./ForPackageMaker/CVS/Entries ./ForPackageMaker/CVS/Repository ./ForPackageMaker/CVS/Entries.Log ./ForPackageMaker/CVS/Tag ./ForPackageMaker/CVS/Root ./ForPackageMaker/RXTX_Tiger.pkg.sitx.hqx ./ForPackageMaker/RXTX_Jag.pkg.sit.hqx ./ForPackageMaker/Install ./ForPackageMaker/Install/CVS ./ForPackageMaker/Install/CVS/Entries ./ForPackageMaker/Install/CVS/Repository ./ForPackageMaker/Install/CVS/Tag ./ForPackageMaker/Install/CVS/Root ./ForPackageMaker/Install/Library ./ForPackageMaker/Install/Library/CVS ./ForPackageMaker/Install/Library/CVS/Entries ./ForPackageMaker/Install/Library/CVS/Repository ./ForPackageMaker/Install/Library/CVS/Tag ./ForPackageMaker/Install/Library/CVS/Root ./ForPackageMaker/Install/Library/Java ./ForPackageMaker/Install/Library/Java/Extensions ./ForPackageMaker/Install/Library/Java/Extensions/RXTXcomm.jar ./ForPackageMaker/Install/Library/Java/Extensions/CVS ./ForPackageMaker/Install/Library/Java/Extensions/CVS/Entries ./ForPackageMaker/Install/Library/Java/Extensions/CVS/Repository ./ForPackageMaker/Install/Library/Java/Extensions/CVS/Tag ./ForPackageMaker/Install/Library/Java/Extensions/CVS/Root ./ForPackageMaker/Install/Library/Java/Extensions/librxtxSerial.jnilib ./ForPackageMaker/Install/Library/Java/CVS ./ForPackageMaker/Install/Library/Java/CVS/Entries ./ForPackageMaker/Install/Library/Java/CVS/Repository ./ForPackageMaker/Install/Library/Java/CVS/Entries.Log ./ForPackageMaker/Install/Library/Java/CVS/Tag ./ForPackageMaker/Install/Library/Java/CVS/Root ./ForPackageMaker/RXTX_Tiger.pmproj.sitx.hqx ./CVS ./CVS/Entries ./CVS/Repository ./CVS/Entries.Log ./CVS/Tag ./CVS/Root ./PB ./PB/LibSerialUniversal.xcodeproj.sitx.hqx ./PB/CVS ./PB/CVS/Entries ./PB/CVS/Repository ./PB/CVS/Entries.Log ./PB/CVS/Tag ./PB/CVS/Root ./PB/LibSerial.pbproj.sit.hqx ./PB/startpoint.c ./PB/config.h What is the procedure to run this installer? Do we need a README in: /rxtx-devel/MACOSX_IDE Here is what we have: CVS/ ForPackageMaker/ PB/ Thanks! - DL >On Mon, 20 Mar 2006, Dr. Douglas Lyon wrote: > >>Hi Dimitry, >>This sounds like great work. Just a couple of questions; >>After the check out of the CVS files, using: >>setenv CVSROOT >>:pserver:anonymous at cvs.milestonesolutions.com:/usr/local/cvsroot >> 53 8:28 setenv PASSWORD mousy >> 54 8:29 cvs login >> 55 8:29 cvs checkout rxtx-devel > >Hi Doug > >You want "cvs checkout -r commapi-0-0-1 rxtx-devel" to get RXTX 2.1 >The default branch is rxtx 2.0 which isn't very active right now. > >-- >Trent Jarvi >tjarvi at qbang.org From tjarvi at qbang.org Mon Mar 20 07:25:30 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 20 Mar 2006 07:25:30 -0700 (MST) Subject: [Rxtx] Mac OS X RXTX java installer In-Reply-To: References: <07D0DE29-BA32-4CFE-B036-66BC6423D385@buechse.de> <441AE3E0.2030503@willicon.de> <12531986.1142622114996.JavaMail.dmarkman@mac.com> <441B2674.9010409@willicon.de> <13577405.1142634732776.JavaMail.dmarkman@mac.com> <441B4182.8010407@willicon.de> <92CD0D6C-5BE8-426E-A46D-99452059FF49@mac.com> <441BBB2D.8030305@willicon.de> <441C4088.5090905@willicon.de> <64BC1E23-FDDE-4CE6-8863-CFC881CBC224@mac.com> Message-ID: On Mon, 20 Mar 2006, Dr. Douglas Lyon wrote: > Hi Trent, > Thanks for the info on the CVS checkout procedure. > I did that and am still not sure where the installer is. Hi Doug It does look like it was not cvs committed. There is no rxtx-devel/contrib/MacOSX directory in there at the moment. It was mentioned that it was put under contrib. -- Trent Jarvi tjarvi at qbang.org From dmarkman at mac.com Mon Mar 20 07:29:56 2006 From: dmarkman at mac.com (Dmitry Markman) Date: Mon, 20 Mar 2006 09:29:56 -0500 Subject: [Rxtx] Mac OS X RXTX java installer In-Reply-To: References: <07D0DE29-BA32-4CFE-B036-66BC6423D385@buechse.de> <441AE3E0.2030503@willicon.de> <12531986.1142622114996.JavaMail.dmarkman@mac.com> <441B2674.9010409@willicon.de> <13577405.1142634732776.JavaMail.dmarkman@mac.com> <441B4182.8010407@willicon.de> <92CD0D6C-5BE8-426E-A46D-99452059FF49@mac.com> <441BBB2D.8030305@willicon.de> <441C4088.5090905@willicon.de> <64BC1E23-FDDE-4CE6-8863-CFC881CBC224@mac.com> Message-ID: <6054EB4E-F7E0-4A9C-BDDA-D582D6D8826F@mac.com> you can find it in the rxtx-devel/contrib folder On Mar 20, 2006, at 9:05 AM, Dr. Douglas Lyon wrote: > Hi Trent, > Thanks for the info on the CVS checkout procedure. > I did that and am still not sure where the installer is. > Here is what I have: > cd MACOSX_IDE/ > p4.docjava.com{lyon}121: ls > CVS/ ForPackageMaker/ PB/ > p4.docjava.com{lyon}122: find . | more > . > ./ForPackageMaker > ./ForPackageMaker/RXTX.pkg.sit.hqx > ./ForPackageMaker/Resources > ./ForPackageMaker/Resources/ReadMe.rtf > ./ForPackageMaker/Resources/Welcome.rtf > ./ForPackageMaker/Resources/CVS > ./ForPackageMaker/Resources/CVS/Entries > ./ForPackageMaker/Resources/CVS/Repository > ./ForPackageMaker/Resources/CVS/Tag > ./ForPackageMaker/Resources/CVS/Root > ./ForPackageMaker/Resources/preinstall > ./ForPackageMaker/Resources/License.rtf > ./ForPackageMaker/Resources/preupgrade > ./ForPackageMaker/RXTX.pmsp > ./ForPackageMaker/CVS > ./ForPackageMaker/CVS/Entries > ./ForPackageMaker/CVS/Repository > ./ForPackageMaker/CVS/Entries.Log > ./ForPackageMaker/CVS/Tag > ./ForPackageMaker/CVS/Root > ./ForPackageMaker/RXTX_Tiger.pkg.sitx.hqx > ./ForPackageMaker/RXTX_Jag.pkg.sit.hqx > ./ForPackageMaker/Install > ./ForPackageMaker/Install/CVS > ./ForPackageMaker/Install/CVS/Entries > ./ForPackageMaker/Install/CVS/Repository > ./ForPackageMaker/Install/CVS/Tag > ./ForPackageMaker/Install/CVS/Root > ./ForPackageMaker/Install/Library > ./ForPackageMaker/Install/Library/CVS > ./ForPackageMaker/Install/Library/CVS/Entries > ./ForPackageMaker/Install/Library/CVS/Repository > ./ForPackageMaker/Install/Library/CVS/Tag > ./ForPackageMaker/Install/Library/CVS/Root > ./ForPackageMaker/Install/Library/Java > ./ForPackageMaker/Install/Library/Java/Extensions > ./ForPackageMaker/Install/Library/Java/Extensions/RXTXcomm.jar > ./ForPackageMaker/Install/Library/Java/Extensions/CVS > ./ForPackageMaker/Install/Library/Java/Extensions/CVS/Entries > ./ForPackageMaker/Install/Library/Java/Extensions/CVS/Repository > ./ForPackageMaker/Install/Library/Java/Extensions/CVS/Tag > ./ForPackageMaker/Install/Library/Java/Extensions/CVS/Root > ./ForPackageMaker/Install/Library/Java/Extensions/librxtxSerial.jnilib > ./ForPackageMaker/Install/Library/Java/CVS > ./ForPackageMaker/Install/Library/Java/CVS/Entries > ./ForPackageMaker/Install/Library/Java/CVS/Repository > ./ForPackageMaker/Install/Library/Java/CVS/Entries.Log > ./ForPackageMaker/Install/Library/Java/CVS/Tag > ./ForPackageMaker/Install/Library/Java/CVS/Root > ./ForPackageMaker/RXTX_Tiger.pmproj.sitx.hqx > ./CVS > ./CVS/Entries > ./CVS/Repository > ./CVS/Entries.Log > ./CVS/Tag > ./CVS/Root > ./PB > ./PB/LibSerialUniversal.xcodeproj.sitx.hqx > ./PB/CVS > ./PB/CVS/Entries > ./PB/CVS/Repository > ./PB/CVS/Entries.Log > ./PB/CVS/Tag > ./PB/CVS/Root > ./PB/LibSerial.pbproj.sit.hqx > ./PB/startpoint.c > ./PB/config.h > > What is the procedure to run this installer? > Do we need a README in: > /rxtx-devel/MACOSX_IDE > Here is what we have: > CVS/ ForPackageMaker/ PB/ > > > Thanks! > - DL > >> On Mon, 20 Mar 2006, Dr. Douglas Lyon wrote: >> >>> Hi Dimitry, >>> This sounds like great work. Just a couple of questions; >>> After the check out of the CVS files, using: >>> setenv CVSROOT :pserver:anonymous at cvs.milestonesolutions.com:/usr/ >>> local/cvsroot >>> 53 8:28 setenv PASSWORD mousy >>> 54 8:29 cvs login >>> 55 8:29 cvs checkout rxtx-devel >> >> Hi Doug >> >> You want "cvs checkout -r commapi-0-0-1 rxtx-devel" to get RXTX 2.1 >> The default branch is rxtx 2.0 which isn't very active right now. >> >> -- >> Trent Jarvi >> tjarvi at qbang.org > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx Dmitry Markman From mikehall at spacestar.net Mon Mar 20 05:25:25 2006 From: mikehall at spacestar.net (Michael Hall) Date: Mon, 20 Mar 2006 06:25:25 -0600 Subject: [Rxtx] Re: Mac OS X RXTX java installer In-Reply-To: <64BC1E23-FDDE-4CE6-8863-CFC881CBC224@mac.com> References: <07D0DE29-BA32-4CFE-B036-66BC6423D385@buechse.de> <441AE3E0.2030503@willicon.de> <12531986.1142622114996.JavaMail.dmarkman@mac.com> <441B2674.9010409@willicon.de> <13577405.1142634732776.JavaMail.dmarkman@mac.com> <441B4182.8010407@willicon.de> <92CD0D6C-5BE8-426E-A46D-99452059FF49@mac.com> <441BBB2D.8030305@willicon.de> <441C4088.5090905@willicon.de> <64BC1E23-FDDE-4CE6-8863-CFC881CBC224@mac.com> Message-ID: <247EB61F-5CD1-4132-89A2-FC105B6CF9A5@spacestar.net> On Mar 20, 2006, at 1:20 AM, Dmitry Markman wrote: > > Michael Hall (mikehall at spacestar dot net) had a suggestion to > make implementation of the jaas LoginModule > based on Greg's AuthKit > (his modification of the Greg's AuthKit could be found at http:// > www.spacestar.net/users/mikehall/authkit.dmg) > but Michael's AuthKitLoginModule does only half a job: > it does authenticate > but it can not run any external unix process in privileged mode (at > least I wasn't able to do so) If you got it working directly with Greg's the point is moot. But to clarify it anyhow. The login module does not allow you to do anything anything privileged on return as was explained by Greg. You need to work with a separate privileged process using the execPrivileged method of his API. I assume you did something similar although I haven't looked at how you are using it yet. I allowed instead for a action to be performed at the same time you login/authenticate,this... System.setProperty("authkit.action","/usr/bin/id"); just before this... lc.login(); To clarify, safely ignored as you are already complete. Mike Hall mikehall at spacestar dot net http://www.spacestar.net/users/mikehall http://sourceforge.net/projects/macnative -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2427 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20060320/f6e18202/smime-0014.bin From dmarkman at mac.com Mon Mar 20 07:36:47 2006 From: dmarkman at mac.com (Dmitry Markman) Date: Mon, 20 Mar 2006 09:36:47 -0500 Subject: [Rxtx] Re: Mac OS X RXTX java installer In-Reply-To: <247EB61F-5CD1-4132-89A2-FC105B6CF9A5@spacestar.net> References: <07D0DE29-BA32-4CFE-B036-66BC6423D385@buechse.de> <441AE3E0.2030503@willicon.de> <12531986.1142622114996.JavaMail.dmarkman@mac.com> <441B2674.9010409@willicon.de> <13577405.1142634732776.JavaMail.dmarkman@mac.com> <441B4182.8010407@willicon.de> <92CD0D6C-5BE8-426E-A46D-99452059FF49@mac.com> <441BBB2D.8030305@willicon.de> <441C4088.5090905@willicon.de> <64BC1E23-FDDE-4CE6-8863-CFC881CBC224@mac.com> <247EB61F-5CD1-4132-89A2-FC105B6CF9A5@spacestar.net> Message-ID: Hi, Michael all I have to do is to run some shell script I tried to use your action mechanism and it worked great so I just System.setProperty ("authkit.action","" ) and after that I even don't need to run anything like subject.doAs.... but after few thoughts I choose to use plain Greg's approach, because in that case I don't have to deal with various java's configurations files and therefore to use 2-3 -D parameters in the java command line especially it's useful for java web start (it's so fragile :-( ) thanks for the great job On Mar 20, 2006, at 7:25 AM, Michael Hall wrote: > > On Mar 20, 2006, at 1:20 AM, Dmitry Markman wrote: >> >> Michael Hall (mikehall at spacestar dot net) had a suggestion to >> make implementation of the jaas LoginModule >> based on Greg's AuthKit >> (his modification of the Greg's AuthKit could be found at http:// >> www.spacestar.net/users/mikehall/authkit.dmg) >> but Michael's AuthKitLoginModule does only half a job: >> it does authenticate >> but it can not run any external unix process in privileged mode >> (at least I wasn't able to do so) > > If you got it working directly with Greg's the point is moot. > > But to clarify it anyhow. > The login module does not allow you to do anything anything > privileged on return as was explained by Greg. You need to work > with a separate privileged process using the execPrivileged method > of his API. I assume you did something similar although I haven't > looked at how you are using it yet. > I allowed instead for a action to be performed at the same time you > login/authenticate,this... > System.setProperty("authkit.action","/usr/bin/id"); > just before this... > lc.login(); > To clarify, safely ignored as you are already complete. > > Mike Hall mikehall at spacestar dot net > http://www.spacestar.net/users/mikehall > http://sourceforge.net/projects/macnative > > > Dmitry Markman From dmarkman at mac.com Mon Mar 20 07:44:45 2006 From: dmarkman at mac.com (Dmitry Markman) Date: Mon, 20 Mar 2006 09:44:45 -0500 Subject: [Rxtx] Mac OS X RXTX java installer In-Reply-To: References: <07D0DE29-BA32-4CFE-B036-66BC6423D385@buechse.de> <441AE3E0.2030503@willicon.de> <12531986.1142622114996.JavaMail.dmarkman@mac.com> <441B2674.9010409@willicon.de> <13577405.1142634732776.JavaMail.dmarkman@mac.com> <441B4182.8010407@willicon.de> <92CD0D6C-5BE8-426E-A46D-99452059FF49@mac.com> <441BBB2D.8030305@willicon.de> <441C4088.5090905@willicon.de> <64BC1E23-FDDE-4CE6-8863-CFC881CBC224@mac.com> Message-ID: it's in the commapi-0-0-1 branch I tested it right now: cvs co -r commapi-0-0-1 rxtx-devel and I got everything On Mar 20, 2006, at 9:25 AM, Trent Jarvi wrote: > On Mon, 20 Mar 2006, Dr. Douglas Lyon wrote: > >> Hi Trent, >> Thanks for the info on the CVS checkout procedure. >> I did that and am still not sure where the installer is. > > Hi Doug > > It does look like it was not cvs committed. There is no rxtx-devel/ > contrib/MacOSX directory in there at the moment. It was mentioned > that it was put under contrib. > > -- > Trent Jarvi > tjarvi at qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx Dmitry Markman From tjarvi at qbang.org Mon Mar 20 07:52:57 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 20 Mar 2006 07:52:57 -0700 (MST) Subject: [Rxtx] Mac OS X RXTX java installer In-Reply-To: References: <07D0DE29-BA32-4CFE-B036-66BC6423D385@buechse.de> <441AE3E0.2030503@willicon.de> <12531986.1142622114996.JavaMail.dmarkman@mac.com> <441B2674.9010409@willicon.de> <13577405.1142634732776.JavaMail.dmarkman@mac.com> <441B4182.8010407@willicon.de> <92CD0D6C-5BE8-426E-A46D-99452059FF49@mac.com> <441BBB2D.8030305@willicon.de> <441C4088.5090905@willicon.de> <64BC1E23-FDDE-4CE6-8863-CFC881CBC224@mac.com> Message-ID: On Mon, 20 Mar 2006, Dmitry Markman wrote: > it's in the commapi-0-0-1 branch > > I tested it right now: > cvs co -r commapi-0-0-1 rxtx-devel > > and I got everything > A fresh checkout worked. Here is a copy of the tree (just the installer bits) ftp://ftp.qbang.org/pub/rxtx/MacOSX-installer.zip -- Trent Jarvi tjarvi at qbang.org From lyon at docjava.com Mon Mar 20 08:08:26 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Mon, 20 Mar 2006 10:08:26 -0500 Subject: [Rxtx] Mac OS X RXTX java installer In-Reply-To: References: <07D0DE29-BA32-4CFE-B036-66BC6423D385@buechse.de> <441AE3E0.2030503@willicon.de> <12531986.1142622114996.JavaMail.dmarkman@mac.com> <441B2674.9010409@willicon.de> <13577405.1142634732776.JavaMail.dmarkman@mac.com> <441B4182.8010407@willicon.de> <92CD0D6C-5BE8-426E-A46D-99452059FF49@mac.com> <441BBB2D.8030305@willicon.de> <441C4088.5090905@willicon.de> <64BC1E23-FDDE-4CE6-8863-CFC881CBC224@mac.com> Message-ID: Hi All, Is the Auth package able to work properly on non Mac OS's? It was not clear from the doc or download. Thanks! - Doug From dmarkman at mac.com Mon Mar 20 08:15:22 2006 From: dmarkman at mac.com (Dmitry Markman) Date: Mon, 20 Mar 2006 10:15:22 -0500 Subject: [Rxtx] Mac OS X RXTX java installer In-Reply-To: References: <07D0DE29-BA32-4CFE-B036-66BC6423D385@buechse.de> <441AE3E0.2030503@willicon.de> <12531986.1142622114996.JavaMail.dmarkman@mac.com> <441B2674.9010409@willicon.de> <13577405.1142634732776.JavaMail.dmarkman@mac.com> <441B4182.8010407@willicon.de> <92CD0D6C-5BE8-426E-A46D-99452059FF49@mac.com> <441BBB2D.8030305@willicon.de> <441C4088.5090905@willicon.de> <64BC1E23-FDDE-4CE6-8863-CFC881CBC224@mac.com> Message-ID: <217312D8-CCCA-4859-ABA6-32DF1CC817B9@mac.com> thanks Trent, for putting it on ftp server On Mar 20, 2006, at 9:52 AM, Trent Jarvi wrote: > A fresh checkout worked. Here is a copy of the tree (just the > installer bits) > > ftp://ftp.qbang.org/pub/rxtx/MacOSX-installer.zip > Dmitry Markman From dmarkman at mac.com Mon Mar 20 09:14:03 2006 From: dmarkman at mac.com (Dmitry Markman) Date: Mon, 20 Mar 2006 11:14:03 -0500 Subject: [Rxtx] Mac OS X RXTX java installer In-Reply-To: References: <07D0DE29-BA32-4CFE-B036-66BC6423D385@buechse.de> <441AE3E0.2030503@willicon.de> <12531986.1142622114996.JavaMail.dmarkman@mac.com> <441B2674.9010409@willicon.de> <13577405.1142634732776.JavaMail.dmarkman@mac.com> <441B4182.8010407@willicon.de> <92CD0D6C-5BE8-426E-A46D-99452059FF49@mac.com> <441BBB2D.8030305@willicon.de> <441C4088.5090905@willicon.de> <64BC1E23-FDDE-4CE6-8863-CFC881CBC224@mac.com> Message-ID: <4DEBA6F0-DA45-4E84-823E-1F1AC48BDCCC@mac.com> no it will work only on mac os x however it's harmless to run it on other platform if you want to use it for other platform you have to do the following (I'll do it for linux) 1. modify RXTXInstaller class method public static RXTXInstaller getInstance() public static RXTXInstaller getInstance() { String osName = System.getProperty("os.name").toLowerCase(); if(osName.startsWith("mac")){ return new gnu.io.installer.macosx.MACOSXRXTXInstaller(); } else if(osName.startsWith("windows")){ return new gnu.io.installer.windows.WindowsRXTXInstaller(); }else if(osName.startsWith("linux")){ return new gnu.io.installer.linux.LinuxRXTXInstaller(); } return null; } 2. create folder gnu/io/installer/linux/ 3. create class Linux386RXTXInstaller package gnu.io.installer.linux; import java.io.File; public class Linux386RXTXInstaller extends gnu.io.installer.RXTXInstaller{ public Linux386RXTXInstaller(){ createJarFolder(); createLibFolder(); addJarResource("RXTXcomm.jar","/gnu/io/installer/resources/ linux/jar/RXTXcomm.dat"); addLibResource("librxtxSerial.so","/gnu/io/installer/ resources/linux/lib/librxtxSerial.so"); } protected void createJarFolder(){ String javaHome = System.getProperty("java.home"); char separator = File.separatorChar; jarFolder = new File(javaHome+separator+"lib"+separator+"ext"); } protected void createLibFolder(){ String javaHome = System.getProperty("java.home"); char separator = File.separatorChar; libFolder = new File(javaHome+separator+"bin"); } public void runPreProcess() {} //put here some action you need public void runPostProcess() {} //put here some action you need } 4. create folder /gnu/io/installer/resources/linux/jar and put there linux's version of RXTXcomm.dat (which is renamed RXTXcomm.jar) 5. create folder /gnu/io/installer/resources/linux/lib and put there linux's version of librxtxSerial. so 6. make sure that RXTXInstaller.jar has the following items: /gnu/io/installer/resources/linux/jar/RXTXcomm.jar /gnu/io/installer/resources/linux/lib/librxtxSerial.so 7. modify file installer.pref: jar file RXTXInstaller.jar must have the following item /gnu/io/installer/installer.pref that's basically it for windows you have to do the similar things: just replace linux to windows and librxtxSerial.so to rxtxSerial.dll and create appropriate gnu.io.installer.windows.WindowsRXTXInstaller class package gnu.io.installer.windows; import java.io.File; public class WindowsRXTXInstaller extends gnu.io.installer.RXTXInstaller{ public WindowsRXTXInstaller(){ createJarFolder(); createLibFolder(); addJarResource("RXTXcomm.jar","/gnu/io/installer/resources/ windows/jar/RXTXcomm.dat"); addLibResource("librxtxSerial.so","/gnu/io/installer/ resources/windows/lib/rxtxSerial.dll"); } protected void createJarFolder(){ String javaHome = System.getProperty("java.home"); char separator = File.separatorChar; jarFolder = new File(javaHome+separator+"lib"+separator+"ext"); } protected void createLibFolder(){ String javaHome = System.getProperty("java.home"); char separator = File.separatorChar; libFolder = new File(javaHome+separator+"bin"); } public void runPreProcess() {} //put here some action you need public void runPostProcess() {} //put here some action you need } installer.pref will look like On Mar 20, 2006, at 10:08 AM, Dr. Douglas Lyon wrote: > Hi All, > Is the Auth package able to work properly on > non Mac OS's? > It was not clear from the doc or download. > > Thanks! > - Doug > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx Dmitry Markman From joachim at buechse.de Mon Mar 20 10:49:06 2006 From: joachim at buechse.de (Joachim Buechse) Date: Mon, 20 Mar 2006 18:49:06 +0100 Subject: [Rxtx] BUG: Lock file stays even if port opening fails Message-ID: This was only tested on MacOSX but looking at the code, it should be true for all systems that use lock_uucp. I am opening a port which can not be opened (dialup port of a telephone paired via bluetooth but currently not reachable). The lock file is created and stays arround, even though the port open failed. After looking a bit through the code (of 2.17), I really wonder if it wouldn't be a good idea to make the "locking" an explicit operation called from the java code. This would certainly simplify the generation of meaningfull exceptions (and java based debugging). Maybe even the handling of "preopened" ports should be in the Java part of the lib (again for java based debugging puposes). That beeing said, I have no idea if this would be possible for the 2.07 implementation. Regards, Joachim From tjarvi at qbang.org Mon Mar 20 11:24:22 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 20 Mar 2006 11:24:22 -0700 (MST) Subject: [Rxtx] BUG: Lock file stays even if port opening fails In-Reply-To: References: Message-ID: On Mon, 20 Mar 2006, Joachim Buechse wrote: > This was only tested on MacOSX but looking at the code, it should be true > for all systems that use lock_uucp. > > I am opening a port which can not be opened (dialup port of a telephone > paired via bluetooth but currently not reachable). The lock file is > created and stays arround, even though the port open failed. > > > After looking a bit through the code (of 2.17), I really wonder if it > wouldn't be a good idea to make the "locking" an explicit operation > called from the java code. This would certainly simplify the generation > of meaningfull exceptions (and java based debugging). > Maybe even the handling of "preopened" ports should be in the Java part > of the lib (again for java based debugging puposes). That beeing said, I > have no idea if this would be possible for the 2.07 implementation. > > Regards, Hi Joachim It should be possible in the 2.0-7 implementation too. The calls to RXTXPort.java would not change. We would just do more there Moving more of that logic into Java would be better as many people don't like to look at C code. There is a liblockdev on most Linux distros that can do most of the C code and would be easier to use. The problem is embeded devices will not have that library. The preopened port code has not been really tested. That was a last minute request in a product cycle. I expect it will be tested this year though. As I recall, some devices really do not like CD raising on open. The preopened ports then allow people to mess around in java without power cycling the devices or losing data. -- Trent Jarvi tjarvi at qbang.org From joachim at buechse.de Mon Mar 20 12:01:08 2006 From: joachim at buechse.de (Joachim Buechse) Date: Mon, 20 Mar 2006 20:01:08 +0100 Subject: [Rxtx] BUG: Lock file stays even if port opening fails In-Reply-To: References: Message-ID: Hi Trent, What is your general feeling about moving code to Java? The last days I have been reading quite a bit of the code and there are several things, that might not work as expected. I'll give you two examples from is_device_locked: if LOCKDIR == /var/spool/locks the directory /var/spool/lock will not be checked. LOCKDIR is not checked for lockfiles with unexpected pefixes While these things have probably never been discovered in production, they are still possibly incorrect implementations. If it was Java code, I would write some unit tests producing the errors that could later be corrected. PS: One could imagine to actually implement the whole lockfile handling in Java using some native routines to get the values required (pid, st_dev, st_rdev, ...). On 20.03.2006, at 19:24, Trent Jarvi wrote: > On Mon, 20 Mar 2006, Joachim Buechse wrote: > >> This was only tested on MacOSX but looking at the code, it should >> be true for all systems that use lock_uucp. >> >> I am opening a port which can not be opened (dialup port of a >> telephone paired via bluetooth but currently not reachable). The >> lock file is created and stays arround, even though the port open >> failed. >> >> >> After looking a bit through the code (of 2.17), I really wonder if >> it wouldn't be a good idea to make the "locking" an explicit >> operation called from the java code. This would certainly simplify >> the generation of meaningfull exceptions (and java based debugging). >> Maybe even the handling of "preopened" ports should be in the Java >> part of the lib (again for java based debugging puposes). That >> beeing said, I have no idea if this would be possible for the 2.07 >> implementation. >> >> Regards, > > Hi Joachim > > It should be possible in the 2.0-7 implementation too. The calls > to RXTXPort.java would not change. We would just do more there > Moving more of that logic into Java would be better as many people > don't like to look at C code. There is a liblockdev on most Linux > distros that can do most of the C code and would be easier to use. > The problem is embeded devices will not have that library. > > The preopened port code has not been really tested. That was a > last minute request in a product cycle. I expect it will be tested > this year though. As I recall, some devices really do not like CD > raising on open. The preopened ports then allow people to mess > around in java without power cycling the devices or losing data. > > -- > Trent Jarvi > tjarvi at qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Mon Mar 20 12:21:02 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 20 Mar 2006 12:21:02 -0700 (MST) Subject: [Rxtx] BUG: Lock file stays even if port opening fails In-Reply-To: References: Message-ID: On Mon, 20 Mar 2006, Joachim Buechse wrote: > Hi Trent, > > What is your general feeling about moving code to Java? The last days I > have been reading quite a bit of the code and there are several things, > that might not work as expected. > > I'll give you two examples from is_device_locked: > > if LOCKDIR == /var/spool/locks the directory /var/spool/lock will not be > checked. > LOCKDIR is not checked for lockfiles with unexpected pefixes > > While these things have probably never been discovered in production, > they are still possibly incorrect implementations. If it was Java code, I > would write some unit tests producing the errors that could later be > corrected. > > PS: One could imagine to actually implement the whole lockfile handling > in Java using some native routines to get the values required (pid, > st_dev, st_rdev, ...). Hi Joachim I like the idea of moving more of the code into java but there are some things to consider. If you break this into multiple JNI calls, the performance will drop considerably during enumeration of ports. We are looking for 256 ports per dev type vs (16? in Sun's 2.0 and fewer types). Its hard to make assumptions. I've seen virtual ports start at /dev/foo100 for instance. It works out to over 7500 ports on Linux if you enable them all. We already trim that back by default. See Linux-all-ports in RXTXCommDriver.java. There are also native libraries that rxtx can link to. If you move too much into Java, linking to 'standard' libraries with distros will break. "configure --enable-liblock=yes" will not be doable. This is probably a favorable way with RedHat, Debian, Suse and others. Thats the right thing to do if there will be rpms, dpkg, .. For those reasons, I think it still make sense to keep it to a minimal ~3 calls to JNI code that we can use for speed and versatility. lock() isLocked(), unlock() perhaps. When I say speed, its more about avoiding crossing the JNI layer multiple times than java vs C performance. With versatility I think liblock is the right way for most but not all (embeded) linux distros. -- Trent Jarvi tjarvi at qbang.org From joachim at buechse.de Mon Mar 20 12:42:04 2006 From: joachim at buechse.de (Joachim Buechse) Date: Mon, 20 Mar 2006 20:42:04 +0100 Subject: [Rxtx] BUG: Lock file stays even if port opening fails In-Reply-To: References: Message-ID: <82C19FE7-DDCB-45B6-B2C9-7606B66F0124@buechse.de> Ok, what about providing a default implementation in Java? The RXTXCommDriver would call a (native) function useNativeLocking and if it returns true, call the native functions for lock() isLocked (), unlock(), else is would use the Java based default implementation. This could possibly be overriden by a property (again for debugging). Joachim On 20.03.2006, at 20:21, Trent Jarvi wrote: > On Mon, 20 Mar 2006, Joachim Buechse wrote: > >> Hi Trent, >> >> What is your general feeling about moving code to Java? The last >> days I have been reading quite a bit of the code and there are >> several things, that might not work as expected. >> >> I'll give you two examples from is_device_locked: >> >> if LOCKDIR == /var/spool/locks the directory /var/spool/lock will >> not be checked. >> LOCKDIR is not checked for lockfiles with unexpected pefixes >> >> While these things have probably never been discovered in >> production, they are still possibly incorrect implementations. If >> it was Java code, I would write some unit tests producing the >> errors that could later be corrected. >> >> PS: One could imagine to actually implement the whole lockfile >> handling in Java using some native routines to get the values >> required (pid, st_dev, st_rdev, ...). > > Hi Joachim > > I like the idea of moving more of the code into java but there are > some things to consider. > > If you break this into multiple JNI calls, the performance will > drop considerably during enumeration of ports. We are looking for > 256 ports per dev type vs (16? in Sun's 2.0 and fewer types). Its > hard to make assumptions. I've seen virtual ports start at /dev/ > foo100 for instance. > > It works out to over 7500 ports on Linux if you enable them all. > We already trim that back by default. See Linux-all-ports in > RXTXCommDriver.java. > > There are also native libraries that rxtx can link to. If you move > too much into Java, linking to 'standard' libraries with distros > will break. "configure --enable-liblock=yes" will not be doable. > This is probably a favorable way with RedHat, Debian, Suse and > others. Thats the right thing to do if there will be rpms, dpkg, .. > > For those reasons, I think it still make sense to keep it to a > minimal ~3 calls to JNI code that we can use for speed and > versatility. lock() isLocked(), unlock() perhaps. When I say > speed, its more about avoiding crossing the JNI layer multiple > times than java vs C performance. With versatility I think liblock > is the right way for most but not all (embeded) linux distros. > > -- > Trent Jarvi > tjarvi at qbang.org > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Mon Mar 20 12:44:47 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 20 Mar 2006 12:44:47 -0700 (MST) Subject: [Rxtx] BUG: Lock file stays even if port opening fails In-Reply-To: <82C19FE7-DDCB-45B6-B2C9-7606B66F0124@buechse.de> References: <82C19FE7-DDCB-45B6-B2C9-7606B66F0124@buechse.de> Message-ID: On Mon, 20 Mar 2006, Joachim Buechse wrote: > Ok, what about providing a default implementation in Java? > > The RXTXCommDriver would call a (native) function useNativeLocking and if > it returns true, call the native functions for lock() isLocked(), > unlock(), else is would use the Java based default implementation. This > could possibly be overriden by a property (again for debugging). > Hi Joachim That would be OK with me. -- Trent Jarvi tjarvi at qbang.org From dmarkman at mac.com Mon Mar 20 22:27:45 2006 From: dmarkman at mac.com (Dmitry Markman) Date: Tue, 21 Mar 2006 00:27:45 -0500 Subject: [Rxtx] binaries request Message-ID: <42702213-C222-4937-A585-7CFB17E47608@mac.com> Hi can somebody send me latest linux and windows binaries, please? or where I can find them (I didn't find them in the latest tareball) I gave up with my cygwin: something wrong I have no idea what java doesn't understand /cygwin/c syntax after I changed makefile it did java part but after that gcc 3.4.4 started to complain I set buffer length to 999 lines but I didn't get beginning of the story something wrong with my 1.4.2_09/include/jni.h gcc doesn't like it anyway I gave up thanks in advance Dmitry Markman -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060320/f8cbc57c/attachment-0014.html From tjarvi at qbang.org Mon Mar 20 22:36:48 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 20 Mar 2006 22:36:48 -0700 (MST) Subject: [Rxtx] binaries request In-Reply-To: <42702213-C222-4937-A585-7CFB17E47608@mac.com> References: <42702213-C222-4937-A585-7CFB17E47608@mac.com> Message-ID: On Tue, 21 Mar 2006, Dmitry Markman wrote: > Hi > can somebody send me latest linux and windows binaries, please? > > or where I can find them (I didn't find them in the latest tareball) > > I gave up with my cygwin: something wrong I have no idea what > java doesn't understand /cygwin/c syntax > after I changed makefile it did java part > but after that gcc 3.4.4 started to complain > I set buffer length to 999 lines but I didn't get beginning of the story > something wrong with my 1.4.2_09/include/jni.h gcc doesn't like it > anyway I gave up > > thanks in advance > Hi Dmitry The bins are here: ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7-bins-r2.zip Here are the files in the zip you want. Jar: rxtx-2.1-7-bins-r2/RXTXcomm.jar Windows: rxtx-2.1-7-bins-r2/Windows/i368-mingw32/rxtxSerial.dll Linux (x86) rxtx-2.1-7-bins-r2/Linux/i686-unknown-linux-gnu/librxtxSerial.so There are others in there including Parallel port support but those are the main ones for testing. -- Trent Jarvi tjarvi at qbang.org From dmarkman at mac.com Mon Mar 20 23:05:59 2006 From: dmarkman at mac.com (Dmitry Markman) Date: Tue, 21 Mar 2006 01:05:59 -0500 Subject: [Rxtx] binaries request In-Reply-To: References: <42702213-C222-4937-A585-7CFB17E47608@mac.com> Message-ID: thank you very much but windows's readme says: rxtxSerial.dll had to be recomopiled to link in missing native methods. should I ignore it? or what? thanks again also I understand that I should use mingw not cygwin I'll try to install mingw On Mar 21, 2006, at 12:36 AM, Trent Jarvi wrote: > On Tue, 21 Mar 2006, Dmitry Markman wrote: > >> Hi >> can somebody send me latest linux and windows binaries, please? >> >> or where I can find them (I didn't find them in the latest tareball) >> >> I gave up with my cygwin: something wrong I have no idea what >> java doesn't understand /cygwin/c syntax >> after I changed makefile it did java part >> but after that gcc 3.4.4 started to complain >> I set buffer length to 999 lines but I didn't get beginning of the >> story >> something wrong with my 1.4.2_09/include/jni.h gcc doesn't like it >> anyway I gave up >> >> thanks in advance >> > > Hi Dmitry > > The bins are here: > > ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7-bins-r2.zip > > Here are the files in the zip you want. > > Jar: > > rxtx-2.1-7-bins-r2/RXTXcomm.jar > > Windows: > > rxtx-2.1-7-bins-r2/Windows/i368-mingw32/rxtxSerial.dll > > Linux (x86) > > rxtx-2.1-7-bins-r2/Linux/i686-unknown-linux-gnu/librxtxSerial.so > > There are others in there including Parallel port support but those > are the main ones for testing. > > -- > Trent Jarvi > tjarvi at qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx Dmitry Markman From tjarvi at qbang.org Mon Mar 20 23:20:33 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 20 Mar 2006 23:20:33 -0700 (MST) Subject: [Rxtx] binaries request In-Reply-To: References: <42702213-C222-4937-A585-7CFB17E47608@mac.com> Message-ID: On Tue, 21 Mar 2006, Dmitry Markman wrote: > thank you very much > > but windows's readme says: > rxtxSerial.dll had to be recomopiled to link in missing native methods. > > should I ignore it? or what? > Hi Dmitry That dll should be OK. r2 is the recompile linked to the missing native method. The readme explains why it was recompiled; fuser.o was not linked into the dll in the first release. -- Trent Jarvi tjarvi at qbang.org From ariantristan at yahoo.com Mon Mar 20 23:55:24 2006 From: ariantristan at yahoo.com (Lambok Sianturi) Date: Mon, 20 Mar 2006 22:55:24 -0800 (PST) Subject: [Rxtx] jvm issue Message-ID: <20060321065524.94779.qmail@web50701.mail.yahoo.com> Hi All, This is my first time to join RxTx mailing list. I thank you all for allowing others to sign in in requests help. I use the latest RxTx lib in Fedora 3 with java version 1.4.2_09 b05. And I got this error: # # An unexpected error has been detected by HotSpot Virtual Machine: # # SIGSEGV (0xb) at pc=0x00bf27f3, pid=2633, tid=3086112448 # # Java VM: Java HotSpot(TM) Client VM (1.4.2_09-b05 mixed mode) # Problematic frame: # C [ld-linux.so.2+0xa7f3] # # An error report file with more information is saved as hs_err_pid2633.log # # If you would like to submit a bug report, please visit: # http://java.sun.com/webapps/bugreport/crash.jsp # ./run.sh: line 3: 2633 Aborted /usr/local/java/bin/java -Djava.library.path=/usr/local/java/jre/lib/ -Djsmsengine.debug=true -classpath jsmsengine.jar:smsgateway.jar:classes12.jar:RXTXcomm.jar:. com.api.sms.SMSServer What is the jvm depedency for the latest library? Can I use 1.4.2_09 b05? Thanks in advance. Arian --------------------------------- Yahoo! Mail Use Photomail to share photos without annoying attachments. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060320/83d58dd7/attachment-0014.html From f.frumento at ngi.it Tue Mar 21 00:21:47 2006 From: f.frumento at ngi.it (Fabio Frumento) Date: Tue, 21 Mar 2006 08:21:47 +0100 Subject: [Rxtx] Javadoc on the go Message-ID: <441FA98B.9050701@ngi.it> Hi Trent, sorry for the big delay but my job is running wild, i was out for some time but now i'm back and ready to continue the javadoc for Rxtx. Did you used the last javadoc patch i sent you ? let me know if i have to send it to you again or not. regards Fabio From lyon at docjava.com Tue Mar 21 00:51:18 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Tue, 21 Mar 2006 02:51:18 -0500 Subject: [Rxtx] lock files Message-ID: Hi All, You know, if the use of lock files were under Java control (rather than a build-time decision), it might enable a more unified binary distro. It might also facilitate quick prototyping of non-lock file approaches to resolving serial port contention issues (i.e., mac-like approaches vs. linux approaches, etc.). I realize that this is a radical overhaul of the lock file policy issue. Also, it may harm performance. On the other hand, our benchmarks on JNI overhead for modern processors indicate performance impact should be minimal. Perhaps it is more of an issue with the toybox systems. Suppose there were a class with a reasonable default...someone might write: SerialPortLockPolicy.setPolicy(SerialPortLockPolicy.UNIX_LOCK_FILE); SerialPortLockPolicy.setPolicy(SerialPortLockPolicy.NO_LOCK_CHECKING); SerialPortLockPolicy.setPolicy(SerialPortLockPolicy.MAC_STYLE); Thus, we could have a run-time reconfiguration of the serial port lock policy. A special NO_LOCK version of the binary would no longer be required. Any thoughts on this? Thanks! - Doug From joachim at buechse.de Tue Mar 21 03:09:09 2006 From: joachim at buechse.de (Joachim Buechse) Date: Tue, 21 Mar 2006 11:09:09 +0100 Subject: [Rxtx] lock files In-Reply-To: References: Message-ID: <8E12916A-1B9A-4FF2-B684-E2D1C794221B@buechse.de> This is pretty much what I thought about when I suggested, that the default behaviour could be overwritten with a property. I am very much in favor of this approach. In particular this allows much easier debugging for PC based java developers. I think big parts of the Java (and maybe some parts of the C code) could use a bit of a structural workover (unit tests, javadoc, synchronization, etc). Maybe there should be a CVS branch for this experimental version. I'd be happy to contribute a first workover for some of the Java code. Designing for testability and implementing a good bunch of unit tests has been a strategy that worked quite well in the Java projects I lead. And it ultimately allows more liberal change permission. Regards, Joachim On 21.03.2006, at 08:51, Dr. Douglas Lyon wrote: > Hi All, > You know, if the use of lock files were > under Java control (rather than a build-time decision), > it might enable a more unified binary distro. It might also > facilitate quick prototyping of non-lock file approaches > to resolving serial port contention issues (i.e., mac-like > approaches vs. linux approaches, etc.). > > I realize that this is a radical overhaul of the lock file policy > issue. Also, it may harm performance. On the other hand, > our benchmarks on JNI overhead for modern processors indicate > performance impact should be minimal. Perhaps it is more of > an issue with the toybox systems. > > Suppose there were a class with a reasonable default...someone > might write: > SerialPortLockPolicy.setPolicy(SerialPortLockPolicy.UNIX_LOCK_FILE); > SerialPortLockPolicy.setPolicy(SerialPortLockPolicy.NO_LOCK_CHECKING); > SerialPortLockPolicy.setPolicy(SerialPortLockPolicy.MAC_STYLE); > > Thus, we could have a run-time reconfiguration of the serial port lock > policy. A special NO_LOCK version of the binary would no longer > be required. > > Any thoughts on this? > > Thanks! > - Doug > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From joachim at buechse.de Tue Mar 21 06:23:08 2006 From: joachim at buechse.de (Joachim Buechse) Date: Tue, 21 Mar 2006 14:23:08 +0100 Subject: [Rxtx] PATCH: use of ioctl(fd, TIOCEXCL) instead of lockfiles Message-ID: <923AE774-EEA2-4911-92D8-32BB27802C8B@buechse.de> Here is the patch for the ioctl(fd, TIOCEXCL). I have verified this only for OSX 10.4.5, hence it is only defined for APPLE. However, it should work at least for Solaris as well. If a process has requested TIOEXCL further open calls by other user processes will fail. The patch also disables uucp style locking for APPLE. Obviously this is discussable. I think it is the way to go, as it eliminates creating the lock directory which doesnt exist on the standard installation and it eliminates messing with the system group definitions (adding users to group uucp). Regarding the possibility of root processes opening a device which is locked - I consider this a feature not a potential problem. It is highly unlikely, that somebody is crazy enough to run a JavaVM as root (unless he has no other means of getting a restricted IP port opened, ie doesnt understand ipfw). Anyway, even if the process runs as root, it fails when calling ioctl(fd, TIOCEXCL). It could however still open the port to listen for RING events. I.e. a fax server which needs to see incoming calls but otherwise doesnt want to block the port. So the only case where the proposed mechanism fails is, if an incorrectly implemented process running as root conflicts with a user process. I think this can be accepted. Regards, Joachim PS: If this patch is generally accepted, the installer and Mac doku should obviously be changed as well. Index: SerialImp.c =================================================================== RCS file: /usr/local/cvsroot/rxtx-devel/src/SerialImp.c,v retrieving revision 1.46.2.187 diff -u -r1.46.2.187 SerialImp.c --- SerialImp.c 29 Jan 2006 22:19:04 -0000 1.46.2.187 +++ SerialImp.c 21 Mar 2006 12:59:16 -0000 @@ -656,6 +656,25 @@ fd=OPEN (filename, O_RDWR | O_NOCTTY | O_NONBLOCK ); } while (fd < 0 && errno==EINTR); +#ifdef OPEN_EXCL + // Note that open() follows POSIX semantics: multiple open() calls to + // the same file will succeed unless the TIOCEXCL ioctl is issued. + // This will prevent additional opens except by root-owned processes. + // See tty(4) ("man 4 tty") and ioctl(2) ("man 2 ioctl") for details. + + if (fd >= 0 && (ioctl(fd, TIOCEXCL) == -1)) + { + sprintf( message, "open: exclusive access denied for % s\n", + filename ); + report( message ); + report_error( message ); + + close(fd); + goto fail; + } +#endif /* OPEN_EXCL */ + + if( configure_port( fd ) ) goto fail; (*env)->ReleaseStringUTFChars( env, jstr, filename ); sprintf( message, "open: fd returned is %i\n", fd ); Index: SerialImp.h =================================================================== RCS file: /usr/local/cvsroot/rxtx-devel/src/SerialImp.h,v retrieving revision 1.11.2.49 diff -u -r1.11.2.49 SerialImp.h --- SerialImp.h 5 Jul 2005 17:47:21 -0000 1.11.2.49 +++ SerialImp.h 21 Mar 2006 12:59:17 -0000 @@ -135,7 +135,8 @@ /*# define LOCKDIR "/var/spool/uucp"*/ # define LOCKDIR "/var/lock" # define LOCKFILEPREFIX "LK." -# define UUCP +/*# define UUCP*/ +# define OPEN_EXCL #endif /* __APPLE__ */ #if defined(__NetBSD__) # define DEVICEDIR "/dev/" From tjarvi at qbang.org Tue Mar 21 10:26:08 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 21 Mar 2006 10:26:08 -0700 (MST) Subject: [Rxtx] Javadoc on the go In-Reply-To: <441FA98B.9050701@ngi.it> References: <441FA98B.9050701@ngi.it> Message-ID: On Tue, 21 Mar 2006, Fabio Frumento wrote: > Hi Trent, > > sorry for the big delay but my job is running wild, i was out for some > time but now i'm back and ready to continue the javadoc for Rxtx. > > Did you used the last javadoc patch i sent you ? let me know if i have to > send it to you again or not. > > regards > > Fabio Hi Fabio The patch is in the rxtx mail-list archives. It will be going in soon. I did not see a time critical portion. I'll probably be going through the list since the last batch of patches this weekend and putting them into CVS. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Tue Mar 21 10:57:18 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 21 Mar 2006 10:57:18 -0700 (MST) Subject: [Rxtx] jvm issue In-Reply-To: <20060321065524.94779.qmail@web50701.mail.yahoo.com> References: <20060321065524.94779.qmail@web50701.mail.yahoo.com> Message-ID: On Mon, 20 Mar 2006, Lambok Sianturi wrote: > Hi All, > This is my first time to join RxTx mailing list. I thank you all for allowing others to sign in in requests help. > I use the latest RxTx lib in Fedora 3 with java version 1.4.2_09 b05. And I got this error: > > # > # An unexpected error has been detected by HotSpot Virtual Machine: > # > # SIGSEGV (0xb) at pc=0x00bf27f3, pid=2633, tid=3086112448 > # > # Java VM: Java HotSpot(TM) Client VM (1.4.2_09-b05 mixed mode) > # Problematic frame: > # C [ld-linux.so.2+0xa7f3] A native library loading error? What happens if you recompile rxtx on your system and install that? This sounds like an ABI problem? rxtx 2.1-7 was compiled with a gcc 2.96 toolchain as I recall. The hope is newer system will be backwards compatible. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Tue Mar 21 11:05:29 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 21 Mar 2006 11:05:29 -0700 (MST) Subject: [Rxtx] PATCH: use of ioctl(fd, TIOCEXCL) instead of lockfiles In-Reply-To: <923AE774-EEA2-4911-92D8-32BB27802C8B@buechse.de> References: <923AE774-EEA2-4911-92D8-32BB27802C8B@buechse.de> Message-ID: On Tue, 21 Mar 2006, Joachim Buechse wrote: > Here is the patch for the ioctl(fd, TIOCEXCL). I have verified this only > for OSX 10.4.5, hence it is only defined for APPLE. However, it should > work at least for Solaris as well. > > If a process has requested TIOEXCL further open calls by other user > processes will fail. > > The patch also disables uucp style locking for APPLE. Obviously this is > discussable. I think it is the way to go, as it eliminates creating the > lock directory which doesnt exist on the standard installation and it > eliminates messing with the system group definitions (adding users to > group uucp). > > Regarding the possibility of root processes opening a device which is > locked - I consider this a feature not a potential problem. It is highly > unlikely, that somebody is crazy enough to run a JavaVM as root (unless > he has no other means of getting a restricted IP port opened, ie doesnt > understand ipfw). Anyway, even if the process runs as root, it fails when > calling ioctl(fd, TIOCEXCL). It could however still open the port to > listen for RING events. I.e. a fax server which needs to see incoming > calls but otherwise doesnt want to block the port. So the only case where > the proposed mechanism fails is, if an incorrectly implemented process > running as root conflicts with a user process. I think this can be > accepted. > > Regards, > Joachim > > PS: If this patch is generally accepted, the installer and Mac doku > should obviously be changed as well. > > > Index: SerialImp.c > =================================================================== > RCS file: /usr/local/cvsroot/rxtx-devel/src/SerialImp.c,v > retrieving revision 1.46.2.187 > diff -u -r1.46.2.187 SerialImp.c > --- SerialImp.c 29 Jan 2006 22:19:04 -0000 1.46.2.187 > +++ SerialImp.c 21 Mar 2006 12:59:16 -0000 > @@ -656,6 +656,25 @@ > fd=OPEN (filename, O_RDWR | O_NOCTTY | O_NONBLOCK ); > } while (fd < 0 && errno==EINTR); > > +#ifdef OPEN_EXCL > + // Note that open() follows POSIX semantics: multiple open() > calls to > + // the same file will succeed unless the TIOCEXCL ioctl is > issued. > + // This will prevent additional opens except by root-owned > processes. > + // See tty(4) ("man 4 tty") and ioctl(2) ("man 2 ioctl") for > details. > + > + if (fd >= 0 && (ioctl(fd, TIOCEXCL) == -1)) > + { > + sprintf( message, "open: exclusive access denied for % > s\n", > + filename ); > + report( message ); > + report_error( message ); > + > + close(fd); > + goto fail; > + } > +#endif /* OPEN_EXCL */ > + > + > if( configure_port( fd ) ) goto fail; > (*env)->ReleaseStringUTFChars( env, jstr, filename ); > sprintf( message, "open: fd returned is %i\n", fd ); > Index: SerialImp.h > =================================================================== > RCS file: /usr/local/cvsroot/rxtx-devel/src/SerialImp.h,v > retrieving revision 1.11.2.49 > diff -u -r1.11.2.49 SerialImp.h > --- SerialImp.h 5 Jul 2005 17:47:21 -0000 1.11.2.49 > +++ SerialImp.h 21 Mar 2006 12:59:17 -0000 > @@ -135,7 +135,8 @@ > /*# define LOCKDIR "/var/spool/uucp"*/ > # define LOCKDIR "/var/lock" > # define LOCKFILEPREFIX "LK." > -# define UUCP > +/*# define UUCP*/ > +# define OPEN_EXCL > #endif /* __APPLE__ */ > #if defined(__NetBSD__) > # define DEVICEDIR "/dev/" > This looks like a good start. What do you think Dmitry? Perhaps all systems with TIOCEXCL defined should use that though. Even if they use lockfiles. It wont hurt anything. That would catch people hacking their own serial apps without checking lockfiles. Its a good idea to avoid C++ style comments in the C portions. Some older systems don't deal with them well. If it's just for Mac OS X, it isn't a big deal. I think it was the Irix compiler that was problematic? -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Tue Mar 21 11:22:05 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 21 Mar 2006 11:22:05 -0700 (MST) Subject: [Rxtx] lock files In-Reply-To: <8E12916A-1B9A-4FF2-B684-E2D1C794221B@buechse.de> References: <8E12916A-1B9A-4FF2-B684-E2D1C794221B@buechse.de> Message-ID: We can try it. Maybe the JNI is much improved. The nice thing about linking into liblock is distros then worry about lockfiles on their systems. This way, we have to deal with any changes that may show up. On Tue, 21 Mar 2006, Joachim Buechse wrote: > This is pretty much what I thought about when I suggested, that the > default behaviour could be overwritten with a property. I am very much in > favor of this approach. In particular this allows much easier debugging > for PC based java developers. > > I think big parts of the Java (and maybe some parts of the C code) could > use a bit of a structural workover (unit tests, javadoc, synchronization, > etc). Maybe there should be a CVS branch for this experimental version. > I'd be happy to contribute a first workover for some of the Java code. > Designing for testability and implementing a good bunch of unit tests has > been a strategy that worked quite well in the Java projects I lead. And > it ultimately allows more liberal change permission. > > Regards, > Joachim > > > On 21.03.2006, at 08:51, Dr. Douglas Lyon wrote: > >> Hi All, >> You know, if the use of lock files were >> under Java control (rather than a build-time decision), >> it might enable a more unified binary distro. It might also >> facilitate quick prototyping of non-lock file approaches >> to resolving serial port contention issues (i.e., mac-like >> approaches vs. linux approaches, etc.). >> >> I realize that this is a radical overhaul of the lock file policy >> issue. Also, it may harm performance. On the other hand, >> our benchmarks on JNI overhead for modern processors indicate >> performance impact should be minimal. Perhaps it is more of >> an issue with the toybox systems. >> >> Suppose there were a class with a reasonable default...someone >> might write: >> SerialPortLockPolicy.setPolicy(SerialPortLockPolicy.UNIX_LOCK_FILE); >> SerialPortLockPolicy.setPolicy(SerialPortLockPolicy.NO_LOCK_CHECKING); >> SerialPortLockPolicy.setPolicy(SerialPortLockPolicy.MAC_STYLE); >> >> Thus, we could have a run-time reconfiguration of the serial port lock >> policy. A special NO_LOCK version of the binary would no longer >> be required. >> >> Any thoughts on this? >> >> Thanks! >> - Doug >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From dmarkman at mac.com Tue Mar 21 16:05:17 2006 From: dmarkman at mac.com (Dmitry Markman) Date: Tue, 21 Mar 2006 18:05:17 -0500 Subject: [Rxtx] PATCH: use of ioctl(fd, TIOCEXCL) instead of lockfiles In-Reply-To: References: <923AE774-EEA2-4911-92D8-32BB27802C8B@buechse.de> Message-ID: <512AC70C-BB86-48F2-A83C-023F35C23BAB@mac.com> I think it's cool, but I'd like to have that property implementation when user can choose between locking mechanism about comments: it's easy to change comments to the C style or we can use extensions of the file to cpp so c++ compiler will be used On Mar 21, 2006, at 1:05 PM, Trent Jarvi wrote: > This looks like a good start. What do you think Dmitry? Perhaps > all systems with TIOCEXCL defined should use that though. Even if > they use lockfiles. It wont hurt anything. That would catch > people hacking their own serial apps without checking lockfiles. > > Its a good idea to avoid C++ style comments in the C portions. > Some older systems don't deal with them well. If it's just for Mac > OS X, it isn't a big deal. I think it was the Irix compiler that > was problematic? Dmitry Markman From dmarkman at mac.com Tue Mar 21 16:13:00 2006 From: dmarkman at mac.com (Dmitry Markman) Date: Tue, 21 Mar 2006 18:13:00 -0500 Subject: [Rxtx] PATCH: use of ioctl(fd, TIOCEXCL) instead of lockfiles In-Reply-To: References: <923AE774-EEA2-4911-92D8-32BB27802C8B@buechse.de> Message-ID: I'd like to add that creating locking folder isn't a big deal we never had a problem related to the lock folders, because we always used installer on mac os x from other hand I'm not very much familiar with iotcl locking approach and I'm not sure it's more efficient Joachim wrote "I think it is the way to go, as it eliminates creating the lock directory which doesnt exist on the standard installation and it eliminates messing with the system group definitions (adding users to group uucp)." but I really didn't have any problem with that 1. doesn't exist on the standard installation there are many-many things that don't exist in the standard installation so I don't think that argument is strong enough 2. messing with the system group definitions I don't think we're messing with the group definition mac os x provides very clear way to set up group's members and together with Greg Guerin AuthKit there is no problem to set those definitions so I don't think that argument is strong either but from other hand using iotcl is more promising and is more elegant On Mar 21, 2006, at 1:05 PM, Trent Jarvi wrote: > > This looks like a good start. What do you think Dmitry? Perhaps > all systems with TIOCEXCL defined should use that though. Even if > they use lockfiles. It wont hurt anything. That would catch > people hacking their own serial apps without checking lockfiles. Dmitry Markman From joachim at buechse.de Wed Mar 22 04:46:45 2006 From: joachim at buechse.de (Joachim Buechse) Date: Wed, 22 Mar 2006 12:46:45 +0100 Subject: [Rxtx] PATCH: use of ioctl(fd, TIOCEXCL) instead of lockfiles In-Reply-To: References: <923AE774-EEA2-4911-92D8-32BB27802C8B@buechse.de> Message-ID: Sorry, I was not very clear with my arguments, so I will try again;-) Please, don't take this as an attack against work that has been done. I think the contributions that have been made in the past were made in a good spirit. But I really believe, that the current solution for OSX has many shortcomings and should be changed as soon as possible. lock files --- The /var/lock folder does not exist on the standard OSX installation, however the standard installation includes several applications that use serial ports (i.e. the FAX capability). This indicates, that the lock folder approach will not work well with system components. Applications for OSX will generally try to live in harmony with system components (except for HP print drivers of course). I think RXTX should follow this approach as well. uucp group --- Accessing serial ports is not an admin privileged operation on OSX. Any user (world) has read/write privileges on /dev/tty*. So the system default is to not enforce any group membership to access these ports. The group uucp however is a system group on all unix systems I know. It exists for certain system processes. A non admin user should in general not be a member of this group. Quite arguably no user should ever be a member of this group. Installer --- My general opinion is, that - no Installer should touch user or group data without warning - no Application Installer should touch groups which are not specific to the very application installed - no Installer should ever add regular users to a system group The current installer injects the installing user in the group uucp without warning about this change and without giving the option to "opt out" of this change. This is a potential security risk (but not currently a real one, as OSX contains no folders belonging to group uucp). The current installer does not work for multi user systems. It puts the installing user in the uucp group. However the installing user is not necessarily the user that will use the application. Putting all users that may use a serial port application in the system group uucp seems like a very invasive approach to me. Besides that, newly created users will not automatically be in the group and hence, serial applications will "break" for new users without obvious reasons. Avoiding the lock files will allow self contained applications (i.e. drag&drop installation). In my eyes this is largely preferable over an installer that requests admin privileges. Adding up all these points indicates very strongly, that the lock-file implementation is not the way to go on OSX. Regards, Joachim On 22.03.2006, at 00:13, Dmitry Markman wrote: > I'd like to add that > > creating locking folder isn't a big deal > we never had a problem related to the lock folders, because we > always used installer on mac os x > from other hand I'm not very much familiar with iotcl locking > approach and I'm not sure it's more efficient > > Joachim wrote "I think it is the way to go, as it eliminates > creating the lock directory which doesnt exist on the standard > installation and it eliminates messing with the system group > definitions (adding users to group uucp)." but I really didn't have > any problem with that > > 1. doesn't exist on the standard installation > there are many-many things that don't exist in the standard > installation so I don't think that argument is strong enough > 2. messing with the system group definitions > I don't think we're messing with the group definition > mac os x provides very clear way to set up group's members and > together with Greg Guerin AuthKit there is no problem to set those > definitions > so I don't think that argument is strong either > but from other hand using iotcl is more promising and is more elegant > > > > On Mar 21, 2006, at 1:05 PM, Trent Jarvi wrote: > >> >> This looks like a good start. What do you think Dmitry? Perhaps >> all systems with TIOCEXCL defined should use that though. Even if >> they use lockfiles. It wont hurt anything. That would catch >> people hacking their own serial apps without checking lockfiles. > > Dmitry Markman > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From dmarkman at mac.com Wed Mar 22 05:27:13 2006 From: dmarkman at mac.com (Dmitry Markman) Date: Wed, 22 Mar 2006 07:27:13 -0500 Subject: [Rxtx] PATCH: use of ioctl(fd, TIOCEXCL) instead of lockfiles In-Reply-To: References: <923AE774-EEA2-4911-92D8-32BB27802C8B@buechse.de> Message-ID: <83440CF3-DCD8-41C1-B941-F227232C27E3@mac.com> thanks for the very good explanation I didn't think that you were attacking any thing, so don't worry I just had feeling, that there were more aesthetic reasons for going to ioctl then real necessity now you explained everything quite well (BTW, asfar as I remember installer asks admin password so it wasn't quiet, but it really doesn't matter now) thanks On Mar 22, 2006, at 6:46 AM, Joachim Buechse wrote: > Sorry, I was not very clear with my arguments, so I will try again;-) > > Please, don't take this as an attack against work that has been > done. I think the contributions that have been made in the past > were made in a good spirit. But I really believe, that the current > solution for OSX has many shortcomings and should be changed as > soon as possible. > > lock files > --- > The /var/lock folder does not exist on the standard OSX > installation, however the standard installation includes several > applications that use serial ports (i.e. the FAX capability). This > indicates, that the lock folder approach will not work well with > system components. Applications for OSX will generally try to live > in harmony with system components (except for HP print drivers of > course). I think RXTX should follow this approach as well. > > uucp group > --- > Accessing serial ports is not an admin privileged operation on OSX. > Any user (world) has read/write privileges on /dev/tty*. So the > system default is to not enforce any group membership to access > these ports. The group uucp however is a system group on all unix > systems I know. It exists for certain system processes. A non admin > user should in general not be a member of this group. Quite > arguably no user should ever be a member of this group. > > Installer > --- > My general opinion is, that > - no Installer should touch user or group data without warning > - no Application Installer should touch groups which are not > specific to the very application installed > - no Installer should ever add regular users to a system group > > The current installer injects the installing user in the group uucp > without warning about this change and without giving the option to > "opt out" of this change. This is a potential security risk (but > not currently a real one, as OSX contains no folders belonging to > group uucp). > > The current installer does not work for multi user systems. It puts > the installing user in the uucp group. However the installing user > is not necessarily the user that will use the application. Putting > all users that may use a serial port application in the system > group uucp seems like a very invasive approach to me. Besides that, > newly created users will not automatically be in the group and > hence, serial applications will "break" for new users without > obvious reasons. > > > Avoiding the lock files will allow self contained applications > (i.e. drag&drop installation). In my eyes this is largely > preferable over an installer that requests admin privileges. Adding > up all these points indicates very strongly, that the lock-file > implementation is not the way to go on OSX. > > Regards, > Joachim > > > On 22.03.2006, at 00:13, Dmitry Markman wrote: > >> I'd like to add that >> >> creating locking folder isn't a big deal >> we never had a problem related to the lock folders, because we >> always used installer on mac os x >> from other hand I'm not very much familiar with iotcl locking >> approach and I'm not sure it's more efficient >> >> Joachim wrote "I think it is the way to go, as it eliminates >> creating the lock directory which doesnt exist on the standard >> installation and it eliminates messing with the system group >> definitions (adding users to group uucp)." but I really didn't >> have any problem with that >> >> 1. doesn't exist on the standard installation >> there are many-many things that don't exist in the standard >> installation so I don't think that argument is strong enough >> 2. messing with the system group definitions >> I don't think we're messing with the group definition >> mac os x provides very clear way to set up group's members and >> together with Greg Guerin AuthKit there is no problem to set those >> definitions >> so I don't think that argument is strong either >> but from other hand using iotcl is more promising and is more elegant >> >> >> >> On Mar 21, 2006, at 1:05 PM, Trent Jarvi wrote: >> >>> >>> This looks like a good start. What do you think Dmitry? Perhaps >>> all systems with TIOCEXCL defined should use that though. Even >>> if they use lockfiles. It wont hurt anything. That would catch >>> people hacking their own serial apps without checking lockfiles. >> >> Dmitry Markman >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx Dmitry Markman From lyon at docjava.com Wed Mar 22 06:12:18 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Wed, 22 Mar 2006 08:12:18 -0500 Subject: [Rxtx] sole of a new design pattern Message-ID: Hi All, I have been thinking about how we design the serial port software. I think we need a new design pattern. For lack of a better term, I shall call it: The Parametric Singleton Design Pattern By Douglas A. Lyon ABSTRACT The goal of the singleton design pattern is to make sure that there is one, and only one, instance of a given class. The goal of the parametric singleton design pattern is to make sure that there is one, and only one, instance of a given class with the given parametric values. We parametric singleton design pattern combines the singleton design pattern with a parameter that enables unique creation of instances of a class. These instances are cached. When a user asks for an instance with these parameters, the cache is checked. If the instance is in the cache, the instance is returned, otherwise it is created, added to the cache and then returned. We apply our parametric singleton design pattern to the retrieval of RMI registries bound to a given port. The goal of our system is to make sure that no two RMI registries are listening to the same socket and to make use of the RMI registries after they have been created. RMI registries are used in distributed computation. Introduction The singleton design pattern is meant to ensure that on a single instance of a class exists. It is also meant to provide a global point of access to it. The intent of the parametric singleton design pattern is to ensure that a class has only one instance for a given set of parameter values. It also provides a global point of access to it. Motivation A system cannot tolerate multiple instances of some classes with identical parameters. For example, you cannot have two instances making use of the same serial port, at the same time. You cannot have two instances that are trying to listen to the same socket connection. You cannot have two instances writing to the same file structure at the same time. As the operating system is often thought of as the arbiter of consumed resources (i.e., tape drives, serial ports, etc.) we frequently leave it to an operating system implementation to resolve these contention issues. Even for similar resources (like serial ports) there are few standards for handling contention. For example, serial ports on Linux are locked using a "/var/lock" file. POSIX, on the other hand, uses ioctl mechanisms to prevent contention. A better solution is to make a class that is responsible for keeping track of the instances created from the class. The class is declared final, so that it cannot be subclassed. The class also has a private constructor, so that other classes cannot instance it. The new design pattern is called the parametric singleton design pattern and it provides a way to access and create instances with given parameters. Applicability Use the Parametric Singleton Design Pattern when: 1. There must be exactly one instance of a class with the given parameters. 2. The instances must be accessible to clients from a well-known access point. Structure Insert UML diagram here. Participants The Parametric Singleton Clients that need instances 1. The Parametric Singleton defines an instance upon request from a client, if, and only if, the instance does not already exist. 2. The Parametric Singleton returns the instance to the client. 3. The Parametric Singleton is responsible for creating unique instances from given parameters. Collaborations Clients obtain a reference to a Parametric Singleton instance only through the parametric singleton design pattern. If the instance is left in an improper state (e.g., the serial port was left open) it is NOT the role of the Parametric Singleton Design Pattern to close the IO port. Nor is it the role of the Parametric Singleton Design Pattern to open the port. That role is delegate to some other part of the system. Further, it is not the role of the Parametric Singleton Design Pattern to check out resources. That is, multiple threads can have multiple references to the same resource at the same time. MUTEX locking is delegated to some other part of the system. Consequences The Parametric Singleton Design Pattern has several benefits: 1. Controlled access to parametrically defined instances. Since the Parametric Singleton class encapsulates its instances, there is control over how and when clients access it. 2. Reduced name space. The Parametric Singleton pattern avoids global variables that store instances created from the same parameter. Implementation Here are implementation issues to consider when using the Parametric Singleton pattern: 1. Unique mapping of parameters. The Parametric Singleton pattern requires that there be a mean to isomorphically map the parameter space into the instance space and back again. 2. Ensure unique instances. The Parametric Singleton pattern makes unique instances from parameters, and it does so only once. 3. Cache instances for fast retrieval. The Parametric Singleton pattern must be able to look up instances, given some set of parameters, and do so from some data structure. That is, there must be enough space to hold references to all the instances the program will need. Also, a mechanism is needed to look up and retrieve the instances quickly enough to satisfy the clients. Sample Code public final class ParametricSingletonRmiRegistry { private static Hashtable registry = new Hashtable(100); // use singleton pattern and??????????????????????????????????????????????? // prevent instantiation of RmiRegistryUtils.?????????????????????????????? private ParametricSingletonRmiRegistry() { } // the only instance of the Registry held by the RmiRegistryUtils?????????? public static void listNames(Integer port) { if (!isInCacheAndRunning(port)) return; Registry r = (Registry) registry.get(port); System.out.println("registry on port: " + port); System.out.println("registry: " + r); System.out.println("names: "); try { print(r.list()); } catch (RemoteException e) { In.message(e); } System.out.println("------------------------"); } /**???????????????????????????????????????????????????????????????????????? * Checks whether a Registry has been started on this host????????????????? * in the specified port.?????????????????????????????????????????????????? * If not, it tries to start one.?????????????????????????????????????????? * when it fails to start a Registry, it exits the program????????????????? * with exit code 1.??????????????????????????????????????????????????????? */ public static void restart(int port) { if (isInCacheAndRunning(port)) return; try { startRegistry(port); } catch (RemoteException e) { In.message(e); } } /**???????????????????????????????????????????????????????????????????????? * @param port????????????????????????????????????????????????????????????? * @return true if registry is in cache and running???????????????????????? */ private static boolean isInCacheAndRunning(Integer port) { if (!isRegistryRunning(port.intValue())) return false; if (!isRegistryInCache(port.intValue())) return false; return true; } /**???????????????????????????????????????????????????????????????????????? * @param port????????????????????????????????????????????????????????????? * @return true if we are able to locate a local registry on port.??????????????????????????????????????????????????????????????????????????? */ private static boolean isRegistryRunning(int port) { try { Registry r = LocateRegistry.getRegistry(port); if (r != null) return true; } catch (RemoteException e) { return false; } return false; } /**???????????????????????????????????????????????????????????????????????? * @param port????????????????????????????????????????????????????????????? * @return return true if registry is in cache????????????????????????????? */ private static boolean isRegistryInCache(int port) { if (registry.get(new Integer(port)) == null) return false; return true; } /**???????????????????????????????????????????????????????????????????????? * Restart the registry, if needed.???????????????????????????????????????? * Return the only instance of the registry for consistent global?????????? * using by making use of the Singleton Design Pattern????????????????????? *????????????????????????????????????????????????????????????????????????? * @return the internally held registry instance.?????????????????????????? */ public static Registry getRegistry(Integer port) { restart(port); return (Registry) registry.get(port); } private static void startRegistry(Integer port) throws RemoteException { Registry r; try { r = LocateRegistry.createRegistry(port.intValue()); registry.put(port, r); //r = new sun.rmi.registry.RegistryImpl???????????????????????????? /// (port.intValue());?????????????????????????????????????? // registry.put(port, r);?????????????????????????????????????????? } catch (Exception e) { //e.printStackTrace();????????????????????????????????????????????? r = LocateRegistry.getRegistry(port.intValue()); registry.put(port, r); } } public static void main(String args[]) throws RemoteException { //restart(port);??????????????????????????????????????????????????????? restart(5001); restart(5002); restart(5002); Registry r = LocateRegistry.getRegistry(5002); System.out.println("registry="+r); } } I would very much like to get your feedback on this new design pattern idea. Thank you for your time. Regards, - Doug From david.garnier at trusted-logic.com Wed Mar 22 07:36:10 2006 From: david.garnier at trusted-logic.com (David Garnier) Date: Wed, 22 Mar 2006 15:36:10 +0100 Subject: [Rxtx] sole of a new design pattern In-Reply-To: References: Message-ID: <442160DA.80107@trusted-logic.com> Hello, > The Parametric Singleton Design Pattern The Singleton is the most abused design pattern ever. Good use-cases for this pattern are extremely rare and mostly confined to problems related to hardware resources, like serial ports. > Applicability > > Use the Parametric Singleton Design Pattern when: > 1. There must be exactly one instance of a class with the given > parameters. OK. As I said above, this case this actually very unusual. The Singleton pattern is mostly used when : > 2. The instances must be accessible to clients from a well-known > access point. Using the singleton pattern in this case is just convenient for the programmer. Problems arises pretty quickly, especially if you attempt to unit-test your classes. 1) If your singleton is stateful, or hold on to stateful objects, it means that two different unit tests are not actually independent. Instead of starting with a brand new environment, the result of a test may be affected by the result of a previous test. This problem also arise when with your class relies on a database. In both cases, the solution is to reset your "unique" resource (Singleton or database) at the beginning of the test, which is a pain. Also, while most projects connect to a single database, projects that allow the use of Singletons usually contain several of thems, and new ones may cropped up unnoticed. You quickly end up with test cases that only pass in a certain order, which is a royal pain. 2) You cannot mockup a singleton. Once everyone calls the SomeSingleton class statically, you can't replace your class by SomeSingletonMockup. Furthermore, even for hardware services, the Singleton pattern does not really prevent concurrent accesses. If you start the same program in two different JVMs, unless they somehow shared the state of their "Singletons" (through lock files for example), the Singleton pattern will not prevent concurrent access. Our application uses RXTX, and we routinely encounter cases where another (native) application has already locked the port. Since we cannot modify the native application to recognize lock files, OS-level control is irreplaceable. > > Consequences > The Parametric Singleton Design Pattern has several benefits: > > 1. Controlled access to parametrically defined instances. Since > the Parametric Singleton class encapsulates its instances, there is > control over how and when clients access it. Not really. Once you've returned the instance to a client, you've lost control over it. The client can to whatever it wants with it. You cannot "recall" the instance or claim it back. > 2. Reduced name space. The Parametric Singleton pattern avoids > global variables that store instances created from the same parameter. Sure, but you don't have to rely on a Singleton for that. Just create a single Factory. > I would very much like to get your feedback on this new design > pattern idea. Well, it's nothing new. Some may say that it is the point of design patterns: formalizes the designs that occur again and again. However, this design is simply a combination of the Singleton and Factory patterns. I did use it in the past, but now I've been exposed to the shortcomings of the Singleton pattern, so I limit myself to Factories. Regards, David From sean_montgomery at baseview.com Wed Mar 22 08:35:28 2006 From: sean_montgomery at baseview.com (Sean Montgomery) Date: Wed, 22 Mar 2006 10:35:28 -0500 Subject: [Rxtx] sole of a new design pattern In-Reply-To: <442160DA.80107@trusted-logic.com> References: <442160DA.80107@trusted-logic.com> Message-ID: <05769CA7-A51B-4CF0-BAA0-E02DD905F5A4@baseview.com> On Mar 22, 2006, at 9:36 AM, David Garnier wrote: > Furthermore, even for hardware services, the Singleton pattern does > not really prevent concurrent > accesses. If you start the same program in two different JVMs, > unless they somehow shared the state > of their "Singletons" (through lock files for example), the > Singleton pattern will not prevent > concurrent access. > Multiple class loaders in a single JVM can be tricky, too. Then there's synchronization, lazy initialization and serialization of singletons to contend with. Bloch's Effective Java covers these, and here's a few articles: http://www.javaworld.com/javaworld/jw-04-2003/jw-0425-designpatterns- p3.html http://java.sun.com/developer/technicalArticles/Programming/singletons/ Just FYI :-) From lyon at docjava.com Wed Mar 22 08:50:48 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Wed, 22 Mar 2006 10:50:48 -0500 Subject: [Rxtx] sole of a new design pattern In-Reply-To: <442160DA.80107@trusted-logic.com> References: <442160DA.80107@trusted-logic.com> Message-ID: Hi All, First, I would like to thank David for his prompt and thoughtful remarks. I had no idea people that feel strongly about a design patterns! Wow! Feedback (particularly critical feedback) is greatly appreciated. Starting at the end, first: >I did use it in >the past, but now I've been exposed to the shortcomings of the >Singleton pattern, so I limit myself to Factories. David, if I understood your comments correctly, you suggested that Factories can be used in leu of the Singleton Design Pattern, or even the Parametric Singleton Design Pattern. As I see in [Gof]: Factory Method: Intent "Define an interface for creating an object, but let subclasses decide which class to instantiate. Factory Method lets a class defer instantiation to subclasses." The Singleton Design Pattern is a concrete class, which is rather different, right? Also, subclasses are not permitted with Singleton, as they are final. Naturally, I could use an abstract factory as a parent for a singleton. I could even design a facade that could be implemented with the singleton....but that is not the intention of the design. Unless you want a mock-up, as discussed, below: More below: >Hello, > >> The Parametric Singleton Design Pattern > >The Singleton is the most abused design pattern ever. Good use-cases >for this pattern are extremely >rare and mostly confined to problems related to hardware resources, >like serial ports. > > >> Applicability >> >> Use the Parametric Singleton Design Pattern when: >> 1. There must be exactly one instance of a class with the given >> parameters. >OK. As I said above, this case this actually very unusual. The >Singleton pattern is mostly used when : >> 2. The instances must be accessible to clients from a well-known >> access point. > >Using the singleton pattern in this case is just convenient for the >programmer. Problems arises >pretty quickly, especially if you attempt to unit-test your classes. > >1) If your singleton is stateful, or hold on to stateful objects, it >means that two different unit >tests are not actually independent. Instead of starting with a brand >new environment, the result of >a test may be affected by the result of a previous test. This >problem also arise when with your >class relies on a database. In both cases, the solution is to reset >your "unique" resource >(Singleton or database) at the beginning of the test, which is a >pain. Also, while most projects >connect to a single database, projects that allow the use of >Singletons usually contain several of >thems, and new ones may cropped up unnoticed. You quickly end up >with test cases that only pass in a >certain order, which is a royal pain. There are basic problems with communicating finite state machines that include reachability and deadlock analysis. These are addressed with petri net analysis and are beyond the scope of the design pattern. As you quite rightly pointed out; the parametric singleton pattern (or the singleton pattern, for that matter) enable multiple threads to gain access to the same instance. The only way that I can see to block others from gaining access to the reference is the synchronize keyword. This is putting a spin-lock (or MUTEX) on the reference. The question of how to unit-test a design pattern like the parametric singleton remains open. Perhaps this is a deficiency. > >2) You cannot mockup a singleton. Once everyone calls the >SomeSingleton class statically, you can't >replace your class by SomeSingletonMockup. Acutally, I am not sure that this is true. If the Singleton implements a Facade interface, it should be possible to make the replacement. Right? > >Furthermore, even for hardware services, the Singleton pattern does >not really prevent concurrent >accesses. If you start the same program in two different JVMs, >unless they somehow shared the state >of their "Singletons" (through lock files for example), the >Singleton pattern will not prevent >concurrent access. Good Point!! You have sharp eyes! The singleton design pattern should/could take responsibility for this. In fact, you may notice that my code does have an implementation (LocateRegistry) that can work across JVM's. The LocateRegistry will even work across the Internet! LocateRegistry takes both a host name and a Port (lock files just don't do this). I did not think to implement this beyond the local machine, but, in its present form, it will work across different processes. > >Our application uses RXTX, and we routinely encounter cases where >another (native) application has >already locked the port. Since we cannot modify the native >application to recognize lock files, >OS-level control is irreplaceable. The singleton design pattern is not meant to replace OS-level control, but to centralize the Java programmers access to it. If lock files, for example, are used for serial ports, the Singleton Design Pattern should be able to work with them. > > >> >> Consequences >> The Parametric Singleton Design Pattern has several benefits: >> > > 1. Controlled access to parametrically defined instances. Since >> the Parametric Singleton class encapsulates its instances, there is >> control over how and when clients access it. > >Not really. Once you've returned the instance to a client, you've >lost control over it. The client >can to whatever it wants with it. You cannot "recall" the instance >or claim it back. Good point, this should read: > 1. Controll when parametrically defined instances are created. Since > > the Parametric Singleton class encapsulates its instances, there is > > control over how and when they are instanced. > >> 2. Reduced name space. The Parametric Singleton pattern avoids >> global variables that store instances created from the same parameter. > >Sure, but you don't have to rely on a Singleton for that. Just >create a single Factory. > > Thank you for your thoughtful and prompt response! Regards, - Doug From dmarkman at mac.com Wed Mar 22 21:21:55 2006 From: dmarkman at mac.com (Dmitry Markman) Date: Wed, 22 Mar 2006 23:21:55 -0500 Subject: [Rxtx] sole of a new design pattern In-Reply-To: <442160DA.80107@trusted-logic.com> References: <442160DA.80107@trusted-logic.com> Message-ID: I don't think I get it On Mar 22, 2006, at 9:36 AM, David Garnier wrote: > Using the singleton pattern in this case is just convenient for the > programmer. Problems arises > pretty quickly, especially if you attempt to unit-test your classes. so you're saying that something isn't so good because you can not test it in the convenient way? if that's true, I'm totally disagree change your test, debug whatever, but if software is efficient at runtime, works fine and only problem is some unit test (which is some kind of framework for testing) then dump that unit test , dump that unit framework and make something appropriate to the software you're testing so if Douglas want to use singletons, what's the problem? and what do you mean by abusing of singleton usage? of course singleton doesn't prevent concurrent access to the resource across the processes unless you're using some OS facility to prevent it, besides singleton as it was introduced is relevant only and only inside of the same process otherwise it's not singleton it's something else (let's say network singleton: so you have remote invocation facility and some factory method that return object created by that facility) I don't have any problem with using any kind of singletons. Parametric Singleton idea (if I understand it right) could be easily implemented in the following way: use a map populate map with instances of some class and key is your parameter (you can use lazy population too) if somebody ask the key check the value if it's null so resource is taken if somebody returns the resource put it back to the map public synchronized static Object getSomeResource(Object parameter); public synchronized static void returnResource(Object parameter); getSomeResource (inside of the same process) could return null in 2 cases 1. if somebody (from other thread for example) already took that resource 2. if OS API said that resource corresponded to that parameter (serial port with parameter = 1 (port #)) is locked and unavailable; I'm not sure that in case of serial ports we even need those Parametric Singletons (unless lock checking is a very expensive operation) just ask the OS about availability of that resource and if it's available give it away and then OS will lock it and therefore in next time somebody ask it just answer that resource is locked and return null for example system has 2 serial ports available so I ask getResource("tty"); or I ask getResource("Bluetooth-Modem"); and if OS is ok you can give tty or Bluetooth-Modem or both no need for any additional pattern I think back to the problem mac os x doesn't recognize locking via files, so it handles locking via some API an instance of the singleton in each process should recognize that resource is locked (by using that API) that's all we don't have to make things more complicate then they are just because there is some nice design pattern or nice unit test framework or whatever keep things simple, make them work fast, don't introduce middle layers unless you have really good reason to do so of course I could be entirely wrong, so sorry about that in advance thanks Dmitry Markman From tjarvi at qbang.org Wed Mar 22 22:31:41 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 22 Mar 2006 22:31:41 -0700 (MST) Subject: [Rxtx] sole of a new design pattern In-Reply-To: References: Message-ID: Hi Doug Interesting reading. So far I'm just reading and thinking. I have one question so far. " Clients obtain a reference to a Parametric Singleton instance only through the parametric singleton design pattern. If the instance is left in an improper state (e.g., the serial port was left open) it is NOT the role of the Parametric Singleton Design Pattern to close the IO port. Nor is it the role of the Parametric Singleton Design Pattern to open the port. That role is delegate to some other part of the system. " So when the clients obtain a reference to the singleton, can they assume the port is there? IE, would it be the singletons role to handle things like USB dongles being removed with event hints comming from the underlying OS. Hardware abstraction layer/HAL on Linux is an example of underlying OS events. I assume that role too is delegated to other parts of the system? -- Trent Jarvi tjarvi at qbang.org From lyon at docjava.com Thu Mar 23 08:10:33 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Thu, 23 Mar 2006 10:10:33 -0500 Subject: [Rxtx] Classes don't need goals, they need roles! In-Reply-To: References: Message-ID: Hi Trent, Yes, I think that the role of the Parametric Singleton Pattern is not to open or close serial ports, nor is it to perform error checking. On the other hand, if you were to combine the role of the Parametric Singleton Pattern with another role (like that of error checking) it might not be amiss. However, I generally caution programmers against adding multiple roles to classes, as this leads to monolithic designs. Thus a different class (NativeLibDetect) could have the role of determining if the native library can be loaded. Another class (SerialPortBean) can have the role of serializing the default state of the serial port, so that it can be recovered, from user preferences, at a later time. The SerialPortDetect could have the role of determining if the serial port is removed (i.e., a USB port was unplugged). My guess is that each class should have a different role in the system, in order to ease maintenance and testing...but I could be wrong about that. Thanks! - Doug >Hi Doug > >Interesting reading. So far I'm just reading and thinking. I have >one question so far. > >" > Clients obtain a reference to a Parametric Singleton instance only >through the parametric singleton design pattern. If the instance is >left in an improper state (e.g., the serial port was left open) it is >NOT the role of the Parametric Singleton Design Pattern to close the >IO port. Nor is it the role of the Parametric Singleton Design Pattern >to >open the port. That role is delegate to some other part of the system. >" > >So when the clients obtain a reference to the singleton, can they >assume the port is there? IE, would it be the singletons role to >handle things like USB dongles being removed with event hints >comming from the underlying OS. Hardware abstraction layer/HAL on >Linux is an example of underlying OS events. > >I assume that role too is delegated to other parts of the system? > >-- >Trent Jarvi >tjarvi at qbang.org >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From maximulo at yahoo.com Fri Mar 24 01:22:38 2006 From: maximulo at yahoo.com (Maximulo Majir) Date: Fri, 24 Mar 2006 00:22:38 -0800 (PST) Subject: [Rxtx] JavaPOS Message-ID: <20060324082238.66371.qmail@web38214.mail.mud.yahoo.com> Hi all! Hello Trent! From what i understand, RXTX or JavaComm APIs were not created solely for JavaPOS. In JavaPOS, we have the virtual method claim() which is separate from open(), but in our RXTX API, claiming is done every call to open(), we cant open the port if its claimed by another application. Would it be alright to suggest or ask to create a new method called claim(..)? Is there such thing as forceclaim() in RXTX? this could be the same as portownership transfer or its equivalent. ForceClaim is in JSR80. Do you have some samples using RXTX as the lower layer for the Device Service Objects in JavaPOS? I have tried it, i just want to compare. Thank you all! maxim __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060324/496adba2/attachment-0014.html From tjarvi at qbang.org Fri Mar 24 11:28:19 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 24 Mar 2006 11:28:19 -0700 (MST) Subject: [Rxtx] Re: RXTX 2.1 Solaris Problems In-Reply-To: <3691.1143210578@www045.gmx.net> References: <3691.1143210578@www045.gmx.net> Message-ID: On Fri, 24 Mar 2006, Andreas Guenther wrote: > Hi all, > > the solaris problem was not the lock file only. > > Ok, I had to create the directory /var/spool/locks myself. > /var/spool/uucp exists. > > But rxtx didn't find any port. > > I compiled the source with my own debug-informations > and I tried to isolate the problem. > > The problem is the testRead-call in SerialImp.c > > JNIEXPORT jboolean JNICALL RXTXCommDriver(testRead)( > > ... > if ( READ( fd, &c, 1 ) < 0 ) > { > if ( errno != EAGAIN ) { > report( "testRead() read failed\n" ); > ret = JNI_FALSE; > } > } > Thanks Andreas I'm packing up to move. I'll be more or less away for a couple weeks here. I'll be checking email but my workstation is going into a box soon. This isn't hard to fix as this port should be enumerated when EWOULDBLOCK is recieved. Thats error is OK for enumeration just as EAGAIN is. I've put the bug into bugzilla so we dont forget to get to it. http://bugzilla.qbang.org/show_bug.cgi?id=42 You can add yourself to the CC list if you wish to test fixes we provide or even put a patch into bugzilla yourself. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Fri Mar 24 11:51:52 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 24 Mar 2006 11:51:52 -0700 (MST) Subject: [Rxtx] JavaPOS In-Reply-To: <20060324082238.66371.qmail@web38214.mail.mud.yahoo.com> References: <20060324082238.66371.qmail@web38214.mail.mud.yahoo.com> Message-ID: On Fri, 24 Mar 2006, Maximulo Majir wrote: > Hi all! Hello Trent! > > > From what i understand, RXTX or JavaComm APIs were not > created solely for JavaPOS. In JavaPOS, we have the virtual method > claim() which is separate from open(), but in our RXTX API, claiming is > done every call to open(), we cant open the port if its claimed by > another application. Would it be alright to suggest or ask to create a > new method called claim(..)? Is there such thing as forceclaim() in > RXTX? this could be the same as portownership transfer or its > equivalent. ForceClaim is in JSR80. > Do you have some samples using RXTX as the lower layer for the Device > Service Objects in JavaPOS? I have tried it, i just want to compare. > maxim Hi Maxim JSR80 is the USB API IBM/Sun put together. The problem is they have a richer kernel/API underneath that can handle such things. With Serial Ports, there isnt anything there other than an ioctl that says don't let anyone touch this and lockfiles that are more of a 'lets be nice.' At times we may be using USB ports but it is through the termios layer with the limitations mentioned. The advantage is that not only USB will work with rxtx. Anything that has a termios layer should work (to the extent that termios layer is complete). I don't know how forceclaim() would help you. Lets say someone has a programmer working on /dev/ttyS0 and you take it. Now you both race each other to read data first. There isn't a mechanism I know of that will solve this problem in termios. The most obvious test being a native app and a Java app trying to take the port. There is the potential of requestion ownership from other Java Applications but the use for that is very rare. Did you have something more specific in mind that I'm missing? I'm not sure that claim() and forceclaim() would help you with rxtx other than maybe locking the port with claim() without opening it. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sat Mar 25 23:42:08 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 25 Mar 2006 23:42:08 -0700 (MST) Subject: [Rxtx] Serial snoop Message-ID: I was reading the Linux kernel mail-list tonight and ran past a thread that mentioned sersnoop. This looks like a handy tool for people dealing with new toys. "a simple command-line tool for linux that echoes bytes to and from any two serial ports, ptys, or network sockets, and prints all traffic to stdout, in hex and ascii." http://www.restivo.org/projects/sersnoop/ It works on Linux only at this time (debian package available). -- Trent Jarvi tjarvi at qbang.org From beat.arnet at gmail.com Sun Mar 26 07:32:35 2006 From: beat.arnet at gmail.com (Beat Arnet) Date: Sun, 26 Mar 2006 09:32:35 -0500 Subject: [Rxtx] Error 0x5 at /home/bob/foo/tar/rxtx-2.1-7/build/../src/termios.c(860): Access is, denied. Message-ID: <4426A603.80508@gmail.com> Dear all, When trying to open the serial port, I sometimes (not always) run into the following exception (when opening the serialPort): Error 0x5 at /home/bob/foo/tar/rxtx-2.1-7/build/../src/termios.c(860): Access is denied. java.lang.UnsatisfiedLinkError: native_psmisc_report_owner at gnu.io.CommPortIdentifier.native_psmisc_report_owner(Native Method) at gnu.io.CommPortIdentifier.open(CommPortIdentifier.java:354) at codeskin.tools.CLLoader.open(CLLoader.java:79) at codeskin.tools.C2000Programmer.run(C2000Programmer.java:220) at java.lang.Thread.run(Unknown Source) Is this the type of error where I should just try to open the port again, or can it be avoided? Regards, Beat From tjarvi at qbang.org Sun Mar 26 11:40:12 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 26 Mar 2006 11:40:12 -0700 (MST) Subject: [Rxtx] Error 0x5 at /home/bob/foo/tar/rxtx-2.1-7/build/../src/termios.c(860): Access is, denied. In-Reply-To: <4426A603.80508@gmail.com> References: <4426A603.80508@gmail.com> Message-ID: On Sun, 26 Mar 2006, Beat Arnet wrote: > Dear all, > > When trying to open the serial port, I sometimes (not always) run into > the following exception (when opening the serialPort): > > Error 0x5 at /home/bob/foo/tar/rxtx-2.1-7/build/../src/termios.c(860): > Access is > denied. > > java.lang.UnsatisfiedLinkError: native_psmisc_report_owner > at gnu.io.CommPortIdentifier.native_psmisc_report_owner(Native > Method) > at gnu.io.CommPortIdentifier.open(CommPortIdentifier.java:354) > at codeskin.tools.CLLoader.open(CLLoader.java:79) > at codeskin.tools.C2000Programmer.run(C2000Programmer.java:220) > at java.lang.Thread.run(Unknown Source) > > Is this the type of error where I should just try to open the port again, > or can it be avoided? > Hi Beat We did a second build of rxtx 2.1-7 to resolve that unsatisfied link error. It should work now. rxtx is trying to tell you it thinks someone else has the serial port open. You can try to open the port again but maybe you already have a copy of the program running when it happens? ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7r2.zip fixed build. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sun Mar 26 11:44:23 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 26 Mar 2006 11:44:23 -0700 (MST) Subject: [Rxtx] RXTX spec file (fwd) Message-ID: This is probably interesting for fedora/suse users. ---------- Forwarded message ---------- Date: Sun, 26 Mar 2006 16:25:45 +0200 To: taj at www.linux.org.uk Subject: RXTX spec file I send you this spec file which allows to create a RPM for Fedora 4, 5 (x86, x86_64) with Java Sun. -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: rxtx.spec Url: http://mailman.qbang.org/pipermail/rxtx/attachments/20060326/6c7b6af6/rxtx-0010.pl From tjarvi at qbang.org Sun Mar 26 23:42:59 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 26 Mar 2006 23:42:59 -0700 (MST) Subject: [Rxtx] Upcomming events. Message-ID: This Wednesday we will be announcing a new "Maintainer" for the rxtx project. The position is more like neutral leader. I wont be going away or doing less. This is just the right thing to do as it turns out the two people with CVS write access will be at the same company. We need a third and we need neutrality. The maintainer will have final say in any conflict and will try to be neutral. It will be open for discussion. Then we will do it :) I'll still do most of the footwork I do now. But. I'm falling behind. I should have gone through the mail-list and posted the next round of changes this weekend. I'm packing to move and its going so so - 13 years of toys collected. I suspect there will be a dead period on my part (a couple weeks) comming up. But if you get it on the mail-list, we will get it in if there are no objections. I may well not be reading the mail-list during this period as I look for a house and many other things. I hope everyone will help out. Thanks -- Trent Jarvi tjarvi at qbang.org From mahmoud_hadad at yahoo.com Sun Mar 26 07:31:19 2006 From: mahmoud_hadad at yahoo.com (ronan nick) Date: Sun, 26 Mar 2006 06:31:19 -0800 (PST) Subject: [Rxtx] a question about the COMM API Message-ID: <20060326143119.54919.qmail@web60014.mail.yahoo.com> hi, i was intrested in knowing how i can communicate with my internal modem using java? for example if i want to make a phone dialer application or a caller id application where should i be looking at? and as i understood the COMM API is for devices that is attached to the computer through serial ports. --------------------------------- New Yahoo! Messenger with Voice. Call regular phones from your PC and save big. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060326/ce8329f0/attachment-0012.html From dmarkman at mac.com Mon Mar 20 00:20:43 2006 From: dmarkman at mac.com (Dmitry Markman) Date: Mon, 20 Mar 2006 02:20:43 -0500 Subject: [Rxtx] Mac OS X RXTX java installer In-Reply-To: References: <07D0DE29-BA32-4CFE-B036-66BC6423D385@buechse.de> <441AE3E0.2030503@willicon.de> <12531986.1142622114996.JavaMail.dmarkman@mac.com> <441B2674.9010409@willicon.de> <13577405.1142634732776.JavaMail.dmarkman@mac.com> <441B4182.8010407@willicon.de> <92CD0D6C-5BE8-426E-A46D-99452059FF49@mac.com> <441BBB2D.8030305@willicon.de> <441C4088.5090905@willicon.de> Message-ID: <64BC1E23-FDDE-4CE6-8863-CFC881CBC224@mac.com> Hi all I put RXTX installer that will install everything (and will create / var/lock if necessary and add user to the uucp group) for mac os x from Java into the rxtx's CVS repository it could be easily modified to install files for any platform it uses Greg Guerin's AuthKit for authentication and authorization Greg released that kit under artistic license, so Trent, please take a look we, probably, can negotiate license with Greg if it's necessary Greg's AuthKit could be downloaded from http://www.amug.org/~glguerin/ sw/#authkit Michael Hall (mikehall at spacestar dot net) had a suggestion to make implementation of the jaas LoginModule based on Greg's AuthKit (his modification of the Greg's AuthKit could be found at http:// www.spacestar.net/users/mikehall/authkit.dmg) but Michael's AuthKitLoginModule does only half a job: it does authenticate but it can not run any external unix process in privileged mode (at least I wasn't able to do so) possible explanation could be found in conversation between Greg and Michael at Apple's java-dev list (look for archives) so I didn't use jaas API for rxtxinstaller I created folder MacOSX in the contrib folder comment 1. if you want to run that installer as standalone application all you need that RXTXInstaller.jar 2. if you want to use webstart you have to add Greg's libAuthKit.jnilib to the mac os x's resources in theory RXTXInstaller.jar doesn't need it, but there is a problem with loading libAuthKit.jnilib from webstart authkit uses loadLibrary method to load library and it failed (from webstart) for standalone application I extract libAuthKit.jnilib from the RXTXInstaller.jar and put it into the /Library/Java/Extensions or ~/Library/Java/Extensions folder that file will be deleted after installer quit unfortunately I didn't have time to put documentation there but it is mostly self-explanatory I took installer code from my gl4java installer that I did about 3 years ago (with small modifications) it would be very nice if Apple will release LoginModule that really will do the job (com.apple.security.auth.module package????? ) (UnixLoginModule is pretty useless) From lyon at docjava.com Mon Mar 20 06:34:39 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Mon, 20 Mar 2006 08:34:39 -0500 Subject: [Rxtx] Mac OS X RXTX java installer In-Reply-To: <64BC1E23-FDDE-4CE6-8863-CFC881CBC224@mac.com> References: <07D0DE29-BA32-4CFE-B036-66BC6423D385@buechse.de> <441AE3E0.2030503@willicon.de> <12531986.1142622114996.JavaMail.dmarkman@mac.com> <441B2674.9010409@willicon.de> <13577405.1142634732776.JavaMail.dmarkman@mac.com> <441B4182.8010407@willicon.de> <92CD0D6C-5BE8-426E-A46D-99452059FF49@mac.com> <441BBB2D.8030305@willicon.de> <441C4088.5090905@willicon.de> <64BC1E23-FDDE-4CE6-8863-CFC881CBC224@mac.com> Message-ID: Hi Dimitry, This sounds like great work. Just a couple of questions; After the check out of the CVS files, using: setenv CVSROOT :pserver:anonymous at cvs.milestonesolutions.com:/usr/local/cvsroot 53 8:28 setenv PASSWORD mousy 54 8:29 cvs login 55 8:29 cvs checkout rxtx-devel I cd'd over to: rxtx-devel/MACOSX_IDE And found: CVS/ CW/ ForPackageMaker/ PB/ Where is the installer? Thanks! - Doug From tjarvi at qbang.org Mon Mar 20 06:39:37 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 20 Mar 2006 06:39:37 -0700 (MST) Subject: [Rxtx] Mac OS X RXTX java installer In-Reply-To: References: <07D0DE29-BA32-4CFE-B036-66BC6423D385@buechse.de> <441AE3E0.2030503@willicon.de> <12531986.1142622114996.JavaMail.dmarkman@mac.com> <441B2674.9010409@willicon.de> <13577405.1142634732776.JavaMail.dmarkman@mac.com> <441B4182.8010407@willicon.de> <92CD0D6C-5BE8-426E-A46D-99452059FF49@mac.com> <441BBB2D.8030305@willicon.de> <441C4088.5090905@willicon.de> <64BC1E23-FDDE-4CE6-8863-CFC881CBC224@mac.com> Message-ID: On Mon, 20 Mar 2006, Dr. Douglas Lyon wrote: > Hi Dimitry, > This sounds like great work. Just a couple of questions; > After the check out of the CVS files, using: > setenv CVSROOT > :pserver:anonymous at cvs.milestonesolutions.com:/usr/local/cvsroot > 53 8:28 setenv PASSWORD mousy > 54 8:29 cvs login > 55 8:29 cvs checkout rxtx-devel Hi Doug You want "cvs checkout -r commapi-0-0-1 rxtx-devel" to get RXTX 2.1 The default branch is rxtx 2.0 which isn't very active right now. -- Trent Jarvi tjarvi at qbang.org From lyon at docjava.com Mon Mar 20 07:05:44 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Mon, 20 Mar 2006 09:05:44 -0500 Subject: [Rxtx] Mac OS X RXTX java installer In-Reply-To: References: <07D0DE29-BA32-4CFE-B036-66BC6423D385@buechse.de> <441AE3E0.2030503@willicon.de> <12531986.1142622114996.JavaMail.dmarkman@mac.com> <441B2674.9010409@willicon.de> <13577405.1142634732776.JavaMail.dmarkman@mac.com> <441B4182.8010407@willicon.de> <92CD0D6C-5BE8-426E-A46D-99452059FF49@mac.com> <441BBB2D.8030305@willicon.de> <441C4088.5090905@willicon.de> <64BC1E23-FDDE-4CE6-8863-CFC881CBC224@mac.com> Message-ID: Hi Trent, Thanks for the info on the CVS checkout procedure. I did that and am still not sure where the installer is. Here is what I have: cd MACOSX_IDE/ p4.docjava.com{lyon}121: ls CVS/ ForPackageMaker/ PB/ p4.docjava.com{lyon}122: find . | more . ./ForPackageMaker ./ForPackageMaker/RXTX.pkg.sit.hqx ./ForPackageMaker/Resources ./ForPackageMaker/Resources/ReadMe.rtf ./ForPackageMaker/Resources/Welcome.rtf ./ForPackageMaker/Resources/CVS ./ForPackageMaker/Resources/CVS/Entries ./ForPackageMaker/Resources/CVS/Repository ./ForPackageMaker/Resources/CVS/Tag ./ForPackageMaker/Resources/CVS/Root ./ForPackageMaker/Resources/preinstall ./ForPackageMaker/Resources/License.rtf ./ForPackageMaker/Resources/preupgrade ./ForPackageMaker/RXTX.pmsp ./ForPackageMaker/CVS ./ForPackageMaker/CVS/Entries ./ForPackageMaker/CVS/Repository ./ForPackageMaker/CVS/Entries.Log ./ForPackageMaker/CVS/Tag ./ForPackageMaker/CVS/Root ./ForPackageMaker/RXTX_Tiger.pkg.sitx.hqx ./ForPackageMaker/RXTX_Jag.pkg.sit.hqx ./ForPackageMaker/Install ./ForPackageMaker/Install/CVS ./ForPackageMaker/Install/CVS/Entries ./ForPackageMaker/Install/CVS/Repository ./ForPackageMaker/Install/CVS/Tag ./ForPackageMaker/Install/CVS/Root ./ForPackageMaker/Install/Library ./ForPackageMaker/Install/Library/CVS ./ForPackageMaker/Install/Library/CVS/Entries ./ForPackageMaker/Install/Library/CVS/Repository ./ForPackageMaker/Install/Library/CVS/Tag ./ForPackageMaker/Install/Library/CVS/Root ./ForPackageMaker/Install/Library/Java ./ForPackageMaker/Install/Library/Java/Extensions ./ForPackageMaker/Install/Library/Java/Extensions/RXTXcomm.jar ./ForPackageMaker/Install/Library/Java/Extensions/CVS ./ForPackageMaker/Install/Library/Java/Extensions/CVS/Entries ./ForPackageMaker/Install/Library/Java/Extensions/CVS/Repository ./ForPackageMaker/Install/Library/Java/Extensions/CVS/Tag ./ForPackageMaker/Install/Library/Java/Extensions/CVS/Root ./ForPackageMaker/Install/Library/Java/Extensions/librxtxSerial.jnilib ./ForPackageMaker/Install/Library/Java/CVS ./ForPackageMaker/Install/Library/Java/CVS/Entries ./ForPackageMaker/Install/Library/Java/CVS/Repository ./ForPackageMaker/Install/Library/Java/CVS/Entries.Log ./ForPackageMaker/Install/Library/Java/CVS/Tag ./ForPackageMaker/Install/Library/Java/CVS/Root ./ForPackageMaker/RXTX_Tiger.pmproj.sitx.hqx ./CVS ./CVS/Entries ./CVS/Repository ./CVS/Entries.Log ./CVS/Tag ./CVS/Root ./PB ./PB/LibSerialUniversal.xcodeproj.sitx.hqx ./PB/CVS ./PB/CVS/Entries ./PB/CVS/Repository ./PB/CVS/Entries.Log ./PB/CVS/Tag ./PB/CVS/Root ./PB/LibSerial.pbproj.sit.hqx ./PB/startpoint.c ./PB/config.h What is the procedure to run this installer? Do we need a README in: /rxtx-devel/MACOSX_IDE Here is what we have: CVS/ ForPackageMaker/ PB/ Thanks! - DL >On Mon, 20 Mar 2006, Dr. Douglas Lyon wrote: > >>Hi Dimitry, >>This sounds like great work. Just a couple of questions; >>After the check out of the CVS files, using: >>setenv CVSROOT >>:pserver:anonymous at cvs.milestonesolutions.com:/usr/local/cvsroot >> 53 8:28 setenv PASSWORD mousy >> 54 8:29 cvs login >> 55 8:29 cvs checkout rxtx-devel > >Hi Doug > >You want "cvs checkout -r commapi-0-0-1 rxtx-devel" to get RXTX 2.1 >The default branch is rxtx 2.0 which isn't very active right now. > >-- >Trent Jarvi >tjarvi at qbang.org From tjarvi at qbang.org Mon Mar 20 07:25:30 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 20 Mar 2006 07:25:30 -0700 (MST) Subject: [Rxtx] Mac OS X RXTX java installer In-Reply-To: References: <07D0DE29-BA32-4CFE-B036-66BC6423D385@buechse.de> <441AE3E0.2030503@willicon.de> <12531986.1142622114996.JavaMail.dmarkman@mac.com> <441B2674.9010409@willicon.de> <13577405.1142634732776.JavaMail.dmarkman@mac.com> <441B4182.8010407@willicon.de> <92CD0D6C-5BE8-426E-A46D-99452059FF49@mac.com> <441BBB2D.8030305@willicon.de> <441C4088.5090905@willicon.de> <64BC1E23-FDDE-4CE6-8863-CFC881CBC224@mac.com> Message-ID: On Mon, 20 Mar 2006, Dr. Douglas Lyon wrote: > Hi Trent, > Thanks for the info on the CVS checkout procedure. > I did that and am still not sure where the installer is. Hi Doug It does look like it was not cvs committed. There is no rxtx-devel/contrib/MacOSX directory in there at the moment. It was mentioned that it was put under contrib. -- Trent Jarvi tjarvi at qbang.org From dmarkman at mac.com Mon Mar 20 07:29:56 2006 From: dmarkman at mac.com (Dmitry Markman) Date: Mon, 20 Mar 2006 09:29:56 -0500 Subject: [Rxtx] Mac OS X RXTX java installer In-Reply-To: References: <07D0DE29-BA32-4CFE-B036-66BC6423D385@buechse.de> <441AE3E0.2030503@willicon.de> <12531986.1142622114996.JavaMail.dmarkman@mac.com> <441B2674.9010409@willicon.de> <13577405.1142634732776.JavaMail.dmarkman@mac.com> <441B4182.8010407@willicon.de> <92CD0D6C-5BE8-426E-A46D-99452059FF49@mac.com> <441BBB2D.8030305@willicon.de> <441C4088.5090905@willicon.de> <64BC1E23-FDDE-4CE6-8863-CFC881CBC224@mac.com> Message-ID: <6054EB4E-F7E0-4A9C-BDDA-D582D6D8826F@mac.com> you can find it in the rxtx-devel/contrib folder On Mar 20, 2006, at 9:05 AM, Dr. Douglas Lyon wrote: > Hi Trent, > Thanks for the info on the CVS checkout procedure. > I did that and am still not sure where the installer is. > Here is what I have: > cd MACOSX_IDE/ > p4.docjava.com{lyon}121: ls > CVS/ ForPackageMaker/ PB/ > p4.docjava.com{lyon}122: find . | more > . > ./ForPackageMaker > ./ForPackageMaker/RXTX.pkg.sit.hqx > ./ForPackageMaker/Resources > ./ForPackageMaker/Resources/ReadMe.rtf > ./ForPackageMaker/Resources/Welcome.rtf > ./ForPackageMaker/Resources/CVS > ./ForPackageMaker/Resources/CVS/Entries > ./ForPackageMaker/Resources/CVS/Repository > ./ForPackageMaker/Resources/CVS/Tag > ./ForPackageMaker/Resources/CVS/Root > ./ForPackageMaker/Resources/preinstall > ./ForPackageMaker/Resources/License.rtf > ./ForPackageMaker/Resources/preupgrade > ./ForPackageMaker/RXTX.pmsp > ./ForPackageMaker/CVS > ./ForPackageMaker/CVS/Entries > ./ForPackageMaker/CVS/Repository > ./ForPackageMaker/CVS/Entries.Log > ./ForPackageMaker/CVS/Tag > ./ForPackageMaker/CVS/Root > ./ForPackageMaker/RXTX_Tiger.pkg.sitx.hqx > ./ForPackageMaker/RXTX_Jag.pkg.sit.hqx > ./ForPackageMaker/Install > ./ForPackageMaker/Install/CVS > ./ForPackageMaker/Install/CVS/Entries > ./ForPackageMaker/Install/CVS/Repository > ./ForPackageMaker/Install/CVS/Tag > ./ForPackageMaker/Install/CVS/Root > ./ForPackageMaker/Install/Library > ./ForPackageMaker/Install/Library/CVS > ./ForPackageMaker/Install/Library/CVS/Entries > ./ForPackageMaker/Install/Library/CVS/Repository > ./ForPackageMaker/Install/Library/CVS/Tag > ./ForPackageMaker/Install/Library/CVS/Root > ./ForPackageMaker/Install/Library/Java > ./ForPackageMaker/Install/Library/Java/Extensions > ./ForPackageMaker/Install/Library/Java/Extensions/RXTXcomm.jar > ./ForPackageMaker/Install/Library/Java/Extensions/CVS > ./ForPackageMaker/Install/Library/Java/Extensions/CVS/Entries > ./ForPackageMaker/Install/Library/Java/Extensions/CVS/Repository > ./ForPackageMaker/Install/Library/Java/Extensions/CVS/Tag > ./ForPackageMaker/Install/Library/Java/Extensions/CVS/Root > ./ForPackageMaker/Install/Library/Java/Extensions/librxtxSerial.jnilib > ./ForPackageMaker/Install/Library/Java/CVS > ./ForPackageMaker/Install/Library/Java/CVS/Entries > ./ForPackageMaker/Install/Library/Java/CVS/Repository > ./ForPackageMaker/Install/Library/Java/CVS/Entries.Log > ./ForPackageMaker/Install/Library/Java/CVS/Tag > ./ForPackageMaker/Install/Library/Java/CVS/Root > ./ForPackageMaker/RXTX_Tiger.pmproj.sitx.hqx > ./CVS > ./CVS/Entries > ./CVS/Repository > ./CVS/Entries.Log > ./CVS/Tag > ./CVS/Root > ./PB > ./PB/LibSerialUniversal.xcodeproj.sitx.hqx > ./PB/CVS > ./PB/CVS/Entries > ./PB/CVS/Repository > ./PB/CVS/Entries.Log > ./PB/CVS/Tag > ./PB/CVS/Root > ./PB/LibSerial.pbproj.sit.hqx > ./PB/startpoint.c > ./PB/config.h > > What is the procedure to run this installer? > Do we need a README in: > /rxtx-devel/MACOSX_IDE > Here is what we have: > CVS/ ForPackageMaker/ PB/ > > > Thanks! > - DL > >> On Mon, 20 Mar 2006, Dr. Douglas Lyon wrote: >> >>> Hi Dimitry, >>> This sounds like great work. Just a couple of questions; >>> After the check out of the CVS files, using: >>> setenv CVSROOT :pserver:anonymous at cvs.milestonesolutions.com:/usr/ >>> local/cvsroot >>> 53 8:28 setenv PASSWORD mousy >>> 54 8:29 cvs login >>> 55 8:29 cvs checkout rxtx-devel >> >> Hi Doug >> >> You want "cvs checkout -r commapi-0-0-1 rxtx-devel" to get RXTX 2.1 >> The default branch is rxtx 2.0 which isn't very active right now. >> >> -- >> Trent Jarvi >> tjarvi at qbang.org > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx Dmitry Markman From mikehall at spacestar.net Mon Mar 20 05:25:25 2006 From: mikehall at spacestar.net (Michael Hall) Date: Mon, 20 Mar 2006 06:25:25 -0600 Subject: [Rxtx] Re: Mac OS X RXTX java installer In-Reply-To: <64BC1E23-FDDE-4CE6-8863-CFC881CBC224@mac.com> References: <07D0DE29-BA32-4CFE-B036-66BC6423D385@buechse.de> <441AE3E0.2030503@willicon.de> <12531986.1142622114996.JavaMail.dmarkman@mac.com> <441B2674.9010409@willicon.de> <13577405.1142634732776.JavaMail.dmarkman@mac.com> <441B4182.8010407@willicon.de> <92CD0D6C-5BE8-426E-A46D-99452059FF49@mac.com> <441BBB2D.8030305@willicon.de> <441C4088.5090905@willicon.de> <64BC1E23-FDDE-4CE6-8863-CFC881CBC224@mac.com> Message-ID: <247EB61F-5CD1-4132-89A2-FC105B6CF9A5@spacestar.net> On Mar 20, 2006, at 1:20 AM, Dmitry Markman wrote: > > Michael Hall (mikehall at spacestar dot net) had a suggestion to > make implementation of the jaas LoginModule > based on Greg's AuthKit > (his modification of the Greg's AuthKit could be found at http:// > www.spacestar.net/users/mikehall/authkit.dmg) > but Michael's AuthKitLoginModule does only half a job: > it does authenticate > but it can not run any external unix process in privileged mode (at > least I wasn't able to do so) If you got it working directly with Greg's the point is moot. But to clarify it anyhow. The login module does not allow you to do anything anything privileged on return as was explained by Greg. You need to work with a separate privileged process using the execPrivileged method of his API. I assume you did something similar although I haven't looked at how you are using it yet. I allowed instead for a action to be performed at the same time you login/authenticate,this... System.setProperty("authkit.action","/usr/bin/id"); just before this... lc.login(); To clarify, safely ignored as you are already complete. Mike Hall mikehall at spacestar dot net http://www.spacestar.net/users/mikehall http://sourceforge.net/projects/macnative -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2427 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20060320/f6e18202/smime-0015.bin From dmarkman at mac.com Mon Mar 20 07:36:47 2006 From: dmarkman at mac.com (Dmitry Markman) Date: Mon, 20 Mar 2006 09:36:47 -0500 Subject: [Rxtx] Re: Mac OS X RXTX java installer In-Reply-To: <247EB61F-5CD1-4132-89A2-FC105B6CF9A5@spacestar.net> References: <07D0DE29-BA32-4CFE-B036-66BC6423D385@buechse.de> <441AE3E0.2030503@willicon.de> <12531986.1142622114996.JavaMail.dmarkman@mac.com> <441B2674.9010409@willicon.de> <13577405.1142634732776.JavaMail.dmarkman@mac.com> <441B4182.8010407@willicon.de> <92CD0D6C-5BE8-426E-A46D-99452059FF49@mac.com> <441BBB2D.8030305@willicon.de> <441C4088.5090905@willicon.de> <64BC1E23-FDDE-4CE6-8863-CFC881CBC224@mac.com> <247EB61F-5CD1-4132-89A2-FC105B6CF9A5@spacestar.net> Message-ID: Hi, Michael all I have to do is to run some shell script I tried to use your action mechanism and it worked great so I just System.setProperty ("authkit.action","" ) and after that I even don't need to run anything like subject.doAs.... but after few thoughts I choose to use plain Greg's approach, because in that case I don't have to deal with various java's configurations files and therefore to use 2-3 -D parameters in the java command line especially it's useful for java web start (it's so fragile :-( ) thanks for the great job On Mar 20, 2006, at 7:25 AM, Michael Hall wrote: > > On Mar 20, 2006, at 1:20 AM, Dmitry Markman wrote: >> >> Michael Hall (mikehall at spacestar dot net) had a suggestion to >> make implementation of the jaas LoginModule >> based on Greg's AuthKit >> (his modification of the Greg's AuthKit could be found at http:// >> www.spacestar.net/users/mikehall/authkit.dmg) >> but Michael's AuthKitLoginModule does only half a job: >> it does authenticate >> but it can not run any external unix process in privileged mode >> (at least I wasn't able to do so) > > If you got it working directly with Greg's the point is moot. > > But to clarify it anyhow. > The login module does not allow you to do anything anything > privileged on return as was explained by Greg. You need to work > with a separate privileged process using the execPrivileged method > of his API. I assume you did something similar although I haven't > looked at how you are using it yet. > I allowed instead for a action to be performed at the same time you > login/authenticate,this... > System.setProperty("authkit.action","/usr/bin/id"); > just before this... > lc.login(); > To clarify, safely ignored as you are already complete. > > Mike Hall mikehall at spacestar dot net > http://www.spacestar.net/users/mikehall > http://sourceforge.net/projects/macnative > > > Dmitry Markman From dmarkman at mac.com Mon Mar 20 07:44:45 2006 From: dmarkman at mac.com (Dmitry Markman) Date: Mon, 20 Mar 2006 09:44:45 -0500 Subject: [Rxtx] Mac OS X RXTX java installer In-Reply-To: References: <07D0DE29-BA32-4CFE-B036-66BC6423D385@buechse.de> <441AE3E0.2030503@willicon.de> <12531986.1142622114996.JavaMail.dmarkman@mac.com> <441B2674.9010409@willicon.de> <13577405.1142634732776.JavaMail.dmarkman@mac.com> <441B4182.8010407@willicon.de> <92CD0D6C-5BE8-426E-A46D-99452059FF49@mac.com> <441BBB2D.8030305@willicon.de> <441C4088.5090905@willicon.de> <64BC1E23-FDDE-4CE6-8863-CFC881CBC224@mac.com> Message-ID: it's in the commapi-0-0-1 branch I tested it right now: cvs co -r commapi-0-0-1 rxtx-devel and I got everything On Mar 20, 2006, at 9:25 AM, Trent Jarvi wrote: > On Mon, 20 Mar 2006, Dr. Douglas Lyon wrote: > >> Hi Trent, >> Thanks for the info on the CVS checkout procedure. >> I did that and am still not sure where the installer is. > > Hi Doug > > It does look like it was not cvs committed. There is no rxtx-devel/ > contrib/MacOSX directory in there at the moment. It was mentioned > that it was put under contrib. > > -- > Trent Jarvi > tjarvi at qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx Dmitry Markman From tjarvi at qbang.org Mon Mar 20 07:52:57 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 20 Mar 2006 07:52:57 -0700 (MST) Subject: [Rxtx] Mac OS X RXTX java installer In-Reply-To: References: <07D0DE29-BA32-4CFE-B036-66BC6423D385@buechse.de> <441AE3E0.2030503@willicon.de> <12531986.1142622114996.JavaMail.dmarkman@mac.com> <441B2674.9010409@willicon.de> <13577405.1142634732776.JavaMail.dmarkman@mac.com> <441B4182.8010407@willicon.de> <92CD0D6C-5BE8-426E-A46D-99452059FF49@mac.com> <441BBB2D.8030305@willicon.de> <441C4088.5090905@willicon.de> <64BC1E23-FDDE-4CE6-8863-CFC881CBC224@mac.com> Message-ID: On Mon, 20 Mar 2006, Dmitry Markman wrote: > it's in the commapi-0-0-1 branch > > I tested it right now: > cvs co -r commapi-0-0-1 rxtx-devel > > and I got everything > A fresh checkout worked. Here is a copy of the tree (just the installer bits) ftp://ftp.qbang.org/pub/rxtx/MacOSX-installer.zip -- Trent Jarvi tjarvi at qbang.org From lyon at docjava.com Mon Mar 20 08:08:26 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Mon, 20 Mar 2006 10:08:26 -0500 Subject: [Rxtx] Mac OS X RXTX java installer In-Reply-To: References: <07D0DE29-BA32-4CFE-B036-66BC6423D385@buechse.de> <441AE3E0.2030503@willicon.de> <12531986.1142622114996.JavaMail.dmarkman@mac.com> <441B2674.9010409@willicon.de> <13577405.1142634732776.JavaMail.dmarkman@mac.com> <441B4182.8010407@willicon.de> <92CD0D6C-5BE8-426E-A46D-99452059FF49@mac.com> <441BBB2D.8030305@willicon.de> <441C4088.5090905@willicon.de> <64BC1E23-FDDE-4CE6-8863-CFC881CBC224@mac.com> Message-ID: Hi All, Is the Auth package able to work properly on non Mac OS's? It was not clear from the doc or download. Thanks! - Doug From dmarkman at mac.com Mon Mar 20 08:15:22 2006 From: dmarkman at mac.com (Dmitry Markman) Date: Mon, 20 Mar 2006 10:15:22 -0500 Subject: [Rxtx] Mac OS X RXTX java installer In-Reply-To: References: <07D0DE29-BA32-4CFE-B036-66BC6423D385@buechse.de> <441AE3E0.2030503@willicon.de> <12531986.1142622114996.JavaMail.dmarkman@mac.com> <441B2674.9010409@willicon.de> <13577405.1142634732776.JavaMail.dmarkman@mac.com> <441B4182.8010407@willicon.de> <92CD0D6C-5BE8-426E-A46D-99452059FF49@mac.com> <441BBB2D.8030305@willicon.de> <441C4088.5090905@willicon.de> <64BC1E23-FDDE-4CE6-8863-CFC881CBC224@mac.com> Message-ID: <217312D8-CCCA-4859-ABA6-32DF1CC817B9@mac.com> thanks Trent, for putting it on ftp server On Mar 20, 2006, at 9:52 AM, Trent Jarvi wrote: > A fresh checkout worked. Here is a copy of the tree (just the > installer bits) > > ftp://ftp.qbang.org/pub/rxtx/MacOSX-installer.zip > Dmitry Markman From dmarkman at mac.com Mon Mar 20 09:14:03 2006 From: dmarkman at mac.com (Dmitry Markman) Date: Mon, 20 Mar 2006 11:14:03 -0500 Subject: [Rxtx] Mac OS X RXTX java installer In-Reply-To: References: <07D0DE29-BA32-4CFE-B036-66BC6423D385@buechse.de> <441AE3E0.2030503@willicon.de> <12531986.1142622114996.JavaMail.dmarkman@mac.com> <441B2674.9010409@willicon.de> <13577405.1142634732776.JavaMail.dmarkman@mac.com> <441B4182.8010407@willicon.de> <92CD0D6C-5BE8-426E-A46D-99452059FF49@mac.com> <441BBB2D.8030305@willicon.de> <441C4088.5090905@willicon.de> <64BC1E23-FDDE-4CE6-8863-CFC881CBC224@mac.com> Message-ID: <4DEBA6F0-DA45-4E84-823E-1F1AC48BDCCC@mac.com> no it will work only on mac os x however it's harmless to run it on other platform if you want to use it for other platform you have to do the following (I'll do it for linux) 1. modify RXTXInstaller class method public static RXTXInstaller getInstance() public static RXTXInstaller getInstance() { String osName = System.getProperty("os.name").toLowerCase(); if(osName.startsWith("mac")){ return new gnu.io.installer.macosx.MACOSXRXTXInstaller(); } else if(osName.startsWith("windows")){ return new gnu.io.installer.windows.WindowsRXTXInstaller(); }else if(osName.startsWith("linux")){ return new gnu.io.installer.linux.LinuxRXTXInstaller(); } return null; } 2. create folder gnu/io/installer/linux/ 3. create class Linux386RXTXInstaller package gnu.io.installer.linux; import java.io.File; public class Linux386RXTXInstaller extends gnu.io.installer.RXTXInstaller{ public Linux386RXTXInstaller(){ createJarFolder(); createLibFolder(); addJarResource("RXTXcomm.jar","/gnu/io/installer/resources/ linux/jar/RXTXcomm.dat"); addLibResource("librxtxSerial.so","/gnu/io/installer/ resources/linux/lib/librxtxSerial.so"); } protected void createJarFolder(){ String javaHome = System.getProperty("java.home"); char separator = File.separatorChar; jarFolder = new File(javaHome+separator+"lib"+separator+"ext"); } protected void createLibFolder(){ String javaHome = System.getProperty("java.home"); char separator = File.separatorChar; libFolder = new File(javaHome+separator+"bin"); } public void runPreProcess() {} //put here some action you need public void runPostProcess() {} //put here some action you need } 4. create folder /gnu/io/installer/resources/linux/jar and put there linux's version of RXTXcomm.dat (which is renamed RXTXcomm.jar) 5. create folder /gnu/io/installer/resources/linux/lib and put there linux's version of librxtxSerial. so 6. make sure that RXTXInstaller.jar has the following items: /gnu/io/installer/resources/linux/jar/RXTXcomm.jar /gnu/io/installer/resources/linux/lib/librxtxSerial.so 7. modify file installer.pref: jar file RXTXInstaller.jar must have the following item /gnu/io/installer/installer.pref that's basically it for windows you have to do the similar things: just replace linux to windows and librxtxSerial.so to rxtxSerial.dll and create appropriate gnu.io.installer.windows.WindowsRXTXInstaller class package gnu.io.installer.windows; import java.io.File; public class WindowsRXTXInstaller extends gnu.io.installer.RXTXInstaller{ public WindowsRXTXInstaller(){ createJarFolder(); createLibFolder(); addJarResource("RXTXcomm.jar","/gnu/io/installer/resources/ windows/jar/RXTXcomm.dat"); addLibResource("librxtxSerial.so","/gnu/io/installer/ resources/windows/lib/rxtxSerial.dll"); } protected void createJarFolder(){ String javaHome = System.getProperty("java.home"); char separator = File.separatorChar; jarFolder = new File(javaHome+separator+"lib"+separator+"ext"); } protected void createLibFolder(){ String javaHome = System.getProperty("java.home"); char separator = File.separatorChar; libFolder = new File(javaHome+separator+"bin"); } public void runPreProcess() {} //put here some action you need public void runPostProcess() {} //put here some action you need } installer.pref will look like On Mar 20, 2006, at 10:08 AM, Dr. Douglas Lyon wrote: > Hi All, > Is the Auth package able to work properly on > non Mac OS's? > It was not clear from the doc or download. > > Thanks! > - Doug > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx Dmitry Markman From joachim at buechse.de Mon Mar 20 10:49:06 2006 From: joachim at buechse.de (Joachim Buechse) Date: Mon, 20 Mar 2006 18:49:06 +0100 Subject: [Rxtx] BUG: Lock file stays even if port opening fails Message-ID: This was only tested on MacOSX but looking at the code, it should be true for all systems that use lock_uucp. I am opening a port which can not be opened (dialup port of a telephone paired via bluetooth but currently not reachable). The lock file is created and stays arround, even though the port open failed. After looking a bit through the code (of 2.17), I really wonder if it wouldn't be a good idea to make the "locking" an explicit operation called from the java code. This would certainly simplify the generation of meaningfull exceptions (and java based debugging). Maybe even the handling of "preopened" ports should be in the Java part of the lib (again for java based debugging puposes). That beeing said, I have no idea if this would be possible for the 2.07 implementation. Regards, Joachim From tjarvi at qbang.org Mon Mar 20 11:24:22 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 20 Mar 2006 11:24:22 -0700 (MST) Subject: [Rxtx] BUG: Lock file stays even if port opening fails In-Reply-To: References: Message-ID: On Mon, 20 Mar 2006, Joachim Buechse wrote: > This was only tested on MacOSX but looking at the code, it should be true > for all systems that use lock_uucp. > > I am opening a port which can not be opened (dialup port of a telephone > paired via bluetooth but currently not reachable). The lock file is > created and stays arround, even though the port open failed. > > > After looking a bit through the code (of 2.17), I really wonder if it > wouldn't be a good idea to make the "locking" an explicit operation > called from the java code. This would certainly simplify the generation > of meaningfull exceptions (and java based debugging). > Maybe even the handling of "preopened" ports should be in the Java part > of the lib (again for java based debugging puposes). That beeing said, I > have no idea if this would be possible for the 2.07 implementation. > > Regards, Hi Joachim It should be possible in the 2.0-7 implementation too. The calls to RXTXPort.java would not change. We would just do more there Moving more of that logic into Java would be better as many people don't like to look at C code. There is a liblockdev on most Linux distros that can do most of the C code and would be easier to use. The problem is embeded devices will not have that library. The preopened port code has not been really tested. That was a last minute request in a product cycle. I expect it will be tested this year though. As I recall, some devices really do not like CD raising on open. The preopened ports then allow people to mess around in java without power cycling the devices or losing data. -- Trent Jarvi tjarvi at qbang.org From joachim at buechse.de Mon Mar 20 12:01:08 2006 From: joachim at buechse.de (Joachim Buechse) Date: Mon, 20 Mar 2006 20:01:08 +0100 Subject: [Rxtx] BUG: Lock file stays even if port opening fails In-Reply-To: References: Message-ID: Hi Trent, What is your general feeling about moving code to Java? The last days I have been reading quite a bit of the code and there are several things, that might not work as expected. I'll give you two examples from is_device_locked: if LOCKDIR == /var/spool/locks the directory /var/spool/lock will not be checked. LOCKDIR is not checked for lockfiles with unexpected pefixes While these things have probably never been discovered in production, they are still possibly incorrect implementations. If it was Java code, I would write some unit tests producing the errors that could later be corrected. PS: One could imagine to actually implement the whole lockfile handling in Java using some native routines to get the values required (pid, st_dev, st_rdev, ...). On 20.03.2006, at 19:24, Trent Jarvi wrote: > On Mon, 20 Mar 2006, Joachim Buechse wrote: > >> This was only tested on MacOSX but looking at the code, it should >> be true for all systems that use lock_uucp. >> >> I am opening a port which can not be opened (dialup port of a >> telephone paired via bluetooth but currently not reachable). The >> lock file is created and stays arround, even though the port open >> failed. >> >> >> After looking a bit through the code (of 2.17), I really wonder if >> it wouldn't be a good idea to make the "locking" an explicit >> operation called from the java code. This would certainly simplify >> the generation of meaningfull exceptions (and java based debugging). >> Maybe even the handling of "preopened" ports should be in the Java >> part of the lib (again for java based debugging puposes). That >> beeing said, I have no idea if this would be possible for the 2.07 >> implementation. >> >> Regards, > > Hi Joachim > > It should be possible in the 2.0-7 implementation too. The calls > to RXTXPort.java would not change. We would just do more there > Moving more of that logic into Java would be better as many people > don't like to look at C code. There is a liblockdev on most Linux > distros that can do most of the C code and would be easier to use. > The problem is embeded devices will not have that library. > > The preopened port code has not been really tested. That was a > last minute request in a product cycle. I expect it will be tested > this year though. As I recall, some devices really do not like CD > raising on open. The preopened ports then allow people to mess > around in java without power cycling the devices or losing data. > > -- > Trent Jarvi > tjarvi at qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Mon Mar 20 12:21:02 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 20 Mar 2006 12:21:02 -0700 (MST) Subject: [Rxtx] BUG: Lock file stays even if port opening fails In-Reply-To: References: Message-ID: On Mon, 20 Mar 2006, Joachim Buechse wrote: > Hi Trent, > > What is your general feeling about moving code to Java? The last days I > have been reading quite a bit of the code and there are several things, > that might not work as expected. > > I'll give you two examples from is_device_locked: > > if LOCKDIR == /var/spool/locks the directory /var/spool/lock will not be > checked. > LOCKDIR is not checked for lockfiles with unexpected pefixes > > While these things have probably never been discovered in production, > they are still possibly incorrect implementations. If it was Java code, I > would write some unit tests producing the errors that could later be > corrected. > > PS: One could imagine to actually implement the whole lockfile handling > in Java using some native routines to get the values required (pid, > st_dev, st_rdev, ...). Hi Joachim I like the idea of moving more of the code into java but there are some things to consider. If you break this into multiple JNI calls, the performance will drop considerably during enumeration of ports. We are looking for 256 ports per dev type vs (16? in Sun's 2.0 and fewer types). Its hard to make assumptions. I've seen virtual ports start at /dev/foo100 for instance. It works out to over 7500 ports on Linux if you enable them all. We already trim that back by default. See Linux-all-ports in RXTXCommDriver.java. There are also native libraries that rxtx can link to. If you move too much into Java, linking to 'standard' libraries with distros will break. "configure --enable-liblock=yes" will not be doable. This is probably a favorable way with RedHat, Debian, Suse and others. Thats the right thing to do if there will be rpms, dpkg, .. For those reasons, I think it still make sense to keep it to a minimal ~3 calls to JNI code that we can use for speed and versatility. lock() isLocked(), unlock() perhaps. When I say speed, its more about avoiding crossing the JNI layer multiple times than java vs C performance. With versatility I think liblock is the right way for most but not all (embeded) linux distros. -- Trent Jarvi tjarvi at qbang.org From joachim at buechse.de Mon Mar 20 12:42:04 2006 From: joachim at buechse.de (Joachim Buechse) Date: Mon, 20 Mar 2006 20:42:04 +0100 Subject: [Rxtx] BUG: Lock file stays even if port opening fails In-Reply-To: References: Message-ID: <82C19FE7-DDCB-45B6-B2C9-7606B66F0124@buechse.de> Ok, what about providing a default implementation in Java? The RXTXCommDriver would call a (native) function useNativeLocking and if it returns true, call the native functions for lock() isLocked (), unlock(), else is would use the Java based default implementation. This could possibly be overriden by a property (again for debugging). Joachim On 20.03.2006, at 20:21, Trent Jarvi wrote: > On Mon, 20 Mar 2006, Joachim Buechse wrote: > >> Hi Trent, >> >> What is your general feeling about moving code to Java? The last >> days I have been reading quite a bit of the code and there are >> several things, that might not work as expected. >> >> I'll give you two examples from is_device_locked: >> >> if LOCKDIR == /var/spool/locks the directory /var/spool/lock will >> not be checked. >> LOCKDIR is not checked for lockfiles with unexpected pefixes >> >> While these things have probably never been discovered in >> production, they are still possibly incorrect implementations. If >> it was Java code, I would write some unit tests producing the >> errors that could later be corrected. >> >> PS: One could imagine to actually implement the whole lockfile >> handling in Java using some native routines to get the values >> required (pid, st_dev, st_rdev, ...). > > Hi Joachim > > I like the idea of moving more of the code into java but there are > some things to consider. > > If you break this into multiple JNI calls, the performance will > drop considerably during enumeration of ports. We are looking for > 256 ports per dev type vs (16? in Sun's 2.0 and fewer types). Its > hard to make assumptions. I've seen virtual ports start at /dev/ > foo100 for instance. > > It works out to over 7500 ports on Linux if you enable them all. > We already trim that back by default. See Linux-all-ports in > RXTXCommDriver.java. > > There are also native libraries that rxtx can link to. If you move > too much into Java, linking to 'standard' libraries with distros > will break. "configure --enable-liblock=yes" will not be doable. > This is probably a favorable way with RedHat, Debian, Suse and > others. Thats the right thing to do if there will be rpms, dpkg, .. > > For those reasons, I think it still make sense to keep it to a > minimal ~3 calls to JNI code that we can use for speed and > versatility. lock() isLocked(), unlock() perhaps. When I say > speed, its more about avoiding crossing the JNI layer multiple > times than java vs C performance. With versatility I think liblock > is the right way for most but not all (embeded) linux distros. > > -- > Trent Jarvi > tjarvi at qbang.org > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Mon Mar 20 12:44:47 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 20 Mar 2006 12:44:47 -0700 (MST) Subject: [Rxtx] BUG: Lock file stays even if port opening fails In-Reply-To: <82C19FE7-DDCB-45B6-B2C9-7606B66F0124@buechse.de> References: <82C19FE7-DDCB-45B6-B2C9-7606B66F0124@buechse.de> Message-ID: On Mon, 20 Mar 2006, Joachim Buechse wrote: > Ok, what about providing a default implementation in Java? > > The RXTXCommDriver would call a (native) function useNativeLocking and if > it returns true, call the native functions for lock() isLocked(), > unlock(), else is would use the Java based default implementation. This > could possibly be overriden by a property (again for debugging). > Hi Joachim That would be OK with me. -- Trent Jarvi tjarvi at qbang.org From dmarkman at mac.com Mon Mar 20 22:27:45 2006 From: dmarkman at mac.com (Dmitry Markman) Date: Tue, 21 Mar 2006 00:27:45 -0500 Subject: [Rxtx] binaries request Message-ID: <42702213-C222-4937-A585-7CFB17E47608@mac.com> Hi can somebody send me latest linux and windows binaries, please? or where I can find them (I didn't find them in the latest tareball) I gave up with my cygwin: something wrong I have no idea what java doesn't understand /cygwin/c syntax after I changed makefile it did java part but after that gcc 3.4.4 started to complain I set buffer length to 999 lines but I didn't get beginning of the story something wrong with my 1.4.2_09/include/jni.h gcc doesn't like it anyway I gave up thanks in advance Dmitry Markman -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060320/f8cbc57c/attachment-0015.html From tjarvi at qbang.org Mon Mar 20 22:36:48 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 20 Mar 2006 22:36:48 -0700 (MST) Subject: [Rxtx] binaries request In-Reply-To: <42702213-C222-4937-A585-7CFB17E47608@mac.com> References: <42702213-C222-4937-A585-7CFB17E47608@mac.com> Message-ID: On Tue, 21 Mar 2006, Dmitry Markman wrote: > Hi > can somebody send me latest linux and windows binaries, please? > > or where I can find them (I didn't find them in the latest tareball) > > I gave up with my cygwin: something wrong I have no idea what > java doesn't understand /cygwin/c syntax > after I changed makefile it did java part > but after that gcc 3.4.4 started to complain > I set buffer length to 999 lines but I didn't get beginning of the story > something wrong with my 1.4.2_09/include/jni.h gcc doesn't like it > anyway I gave up > > thanks in advance > Hi Dmitry The bins are here: ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7-bins-r2.zip Here are the files in the zip you want. Jar: rxtx-2.1-7-bins-r2/RXTXcomm.jar Windows: rxtx-2.1-7-bins-r2/Windows/i368-mingw32/rxtxSerial.dll Linux (x86) rxtx-2.1-7-bins-r2/Linux/i686-unknown-linux-gnu/librxtxSerial.so There are others in there including Parallel port support but those are the main ones for testing. -- Trent Jarvi tjarvi at qbang.org From dmarkman at mac.com Mon Mar 20 23:05:59 2006 From: dmarkman at mac.com (Dmitry Markman) Date: Tue, 21 Mar 2006 01:05:59 -0500 Subject: [Rxtx] binaries request In-Reply-To: References: <42702213-C222-4937-A585-7CFB17E47608@mac.com> Message-ID: thank you very much but windows's readme says: rxtxSerial.dll had to be recomopiled to link in missing native methods. should I ignore it? or what? thanks again also I understand that I should use mingw not cygwin I'll try to install mingw On Mar 21, 2006, at 12:36 AM, Trent Jarvi wrote: > On Tue, 21 Mar 2006, Dmitry Markman wrote: > >> Hi >> can somebody send me latest linux and windows binaries, please? >> >> or where I can find them (I didn't find them in the latest tareball) >> >> I gave up with my cygwin: something wrong I have no idea what >> java doesn't understand /cygwin/c syntax >> after I changed makefile it did java part >> but after that gcc 3.4.4 started to complain >> I set buffer length to 999 lines but I didn't get beginning of the >> story >> something wrong with my 1.4.2_09/include/jni.h gcc doesn't like it >> anyway I gave up >> >> thanks in advance >> > > Hi Dmitry > > The bins are here: > > ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7-bins-r2.zip > > Here are the files in the zip you want. > > Jar: > > rxtx-2.1-7-bins-r2/RXTXcomm.jar > > Windows: > > rxtx-2.1-7-bins-r2/Windows/i368-mingw32/rxtxSerial.dll > > Linux (x86) > > rxtx-2.1-7-bins-r2/Linux/i686-unknown-linux-gnu/librxtxSerial.so > > There are others in there including Parallel port support but those > are the main ones for testing. > > -- > Trent Jarvi > tjarvi at qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx Dmitry Markman From tjarvi at qbang.org Mon Mar 20 23:20:33 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 20 Mar 2006 23:20:33 -0700 (MST) Subject: [Rxtx] binaries request In-Reply-To: References: <42702213-C222-4937-A585-7CFB17E47608@mac.com> Message-ID: On Tue, 21 Mar 2006, Dmitry Markman wrote: > thank you very much > > but windows's readme says: > rxtxSerial.dll had to be recomopiled to link in missing native methods. > > should I ignore it? or what? > Hi Dmitry That dll should be OK. r2 is the recompile linked to the missing native method. The readme explains why it was recompiled; fuser.o was not linked into the dll in the first release. -- Trent Jarvi tjarvi at qbang.org From ariantristan at yahoo.com Mon Mar 20 23:55:24 2006 From: ariantristan at yahoo.com (Lambok Sianturi) Date: Mon, 20 Mar 2006 22:55:24 -0800 (PST) Subject: [Rxtx] jvm issue Message-ID: <20060321065524.94779.qmail@web50701.mail.yahoo.com> Hi All, This is my first time to join RxTx mailing list. I thank you all for allowing others to sign in in requests help. I use the latest RxTx lib in Fedora 3 with java version 1.4.2_09 b05. And I got this error: # # An unexpected error has been detected by HotSpot Virtual Machine: # # SIGSEGV (0xb) at pc=0x00bf27f3, pid=2633, tid=3086112448 # # Java VM: Java HotSpot(TM) Client VM (1.4.2_09-b05 mixed mode) # Problematic frame: # C [ld-linux.so.2+0xa7f3] # # An error report file with more information is saved as hs_err_pid2633.log # # If you would like to submit a bug report, please visit: # http://java.sun.com/webapps/bugreport/crash.jsp # ./run.sh: line 3: 2633 Aborted /usr/local/java/bin/java -Djava.library.path=/usr/local/java/jre/lib/ -Djsmsengine.debug=true -classpath jsmsengine.jar:smsgateway.jar:classes12.jar:RXTXcomm.jar:. com.api.sms.SMSServer What is the jvm depedency for the latest library? Can I use 1.4.2_09 b05? Thanks in advance. Arian --------------------------------- Yahoo! Mail Use Photomail to share photos without annoying attachments. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060320/83d58dd7/attachment-0015.html From f.frumento at ngi.it Tue Mar 21 00:21:47 2006 From: f.frumento at ngi.it (Fabio Frumento) Date: Tue, 21 Mar 2006 08:21:47 +0100 Subject: [Rxtx] Javadoc on the go Message-ID: <441FA98B.9050701@ngi.it> Hi Trent, sorry for the big delay but my job is running wild, i was out for some time but now i'm back and ready to continue the javadoc for Rxtx. Did you used the last javadoc patch i sent you ? let me know if i have to send it to you again or not. regards Fabio From lyon at docjava.com Tue Mar 21 00:51:18 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Tue, 21 Mar 2006 02:51:18 -0500 Subject: [Rxtx] lock files Message-ID: Hi All, You know, if the use of lock files were under Java control (rather than a build-time decision), it might enable a more unified binary distro. It might also facilitate quick prototyping of non-lock file approaches to resolving serial port contention issues (i.e., mac-like approaches vs. linux approaches, etc.). I realize that this is a radical overhaul of the lock file policy issue. Also, it may harm performance. On the other hand, our benchmarks on JNI overhead for modern processors indicate performance impact should be minimal. Perhaps it is more of an issue with the toybox systems. Suppose there were a class with a reasonable default...someone might write: SerialPortLockPolicy.setPolicy(SerialPortLockPolicy.UNIX_LOCK_FILE); SerialPortLockPolicy.setPolicy(SerialPortLockPolicy.NO_LOCK_CHECKING); SerialPortLockPolicy.setPolicy(SerialPortLockPolicy.MAC_STYLE); Thus, we could have a run-time reconfiguration of the serial port lock policy. A special NO_LOCK version of the binary would no longer be required. Any thoughts on this? Thanks! - Doug From joachim at buechse.de Tue Mar 21 03:09:09 2006 From: joachim at buechse.de (Joachim Buechse) Date: Tue, 21 Mar 2006 11:09:09 +0100 Subject: [Rxtx] lock files In-Reply-To: References: Message-ID: <8E12916A-1B9A-4FF2-B684-E2D1C794221B@buechse.de> This is pretty much what I thought about when I suggested, that the default behaviour could be overwritten with a property. I am very much in favor of this approach. In particular this allows much easier debugging for PC based java developers. I think big parts of the Java (and maybe some parts of the C code) could use a bit of a structural workover (unit tests, javadoc, synchronization, etc). Maybe there should be a CVS branch for this experimental version. I'd be happy to contribute a first workover for some of the Java code. Designing for testability and implementing a good bunch of unit tests has been a strategy that worked quite well in the Java projects I lead. And it ultimately allows more liberal change permission. Regards, Joachim On 21.03.2006, at 08:51, Dr. Douglas Lyon wrote: > Hi All, > You know, if the use of lock files were > under Java control (rather than a build-time decision), > it might enable a more unified binary distro. It might also > facilitate quick prototyping of non-lock file approaches > to resolving serial port contention issues (i.e., mac-like > approaches vs. linux approaches, etc.). > > I realize that this is a radical overhaul of the lock file policy > issue. Also, it may harm performance. On the other hand, > our benchmarks on JNI overhead for modern processors indicate > performance impact should be minimal. Perhaps it is more of > an issue with the toybox systems. > > Suppose there were a class with a reasonable default...someone > might write: > SerialPortLockPolicy.setPolicy(SerialPortLockPolicy.UNIX_LOCK_FILE); > SerialPortLockPolicy.setPolicy(SerialPortLockPolicy.NO_LOCK_CHECKING); > SerialPortLockPolicy.setPolicy(SerialPortLockPolicy.MAC_STYLE); > > Thus, we could have a run-time reconfiguration of the serial port lock > policy. A special NO_LOCK version of the binary would no longer > be required. > > Any thoughts on this? > > Thanks! > - Doug > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From joachim at buechse.de Tue Mar 21 06:23:08 2006 From: joachim at buechse.de (Joachim Buechse) Date: Tue, 21 Mar 2006 14:23:08 +0100 Subject: [Rxtx] PATCH: use of ioctl(fd, TIOCEXCL) instead of lockfiles Message-ID: <923AE774-EEA2-4911-92D8-32BB27802C8B@buechse.de> Here is the patch for the ioctl(fd, TIOCEXCL). I have verified this only for OSX 10.4.5, hence it is only defined for APPLE. However, it should work at least for Solaris as well. If a process has requested TIOEXCL further open calls by other user processes will fail. The patch also disables uucp style locking for APPLE. Obviously this is discussable. I think it is the way to go, as it eliminates creating the lock directory which doesnt exist on the standard installation and it eliminates messing with the system group definitions (adding users to group uucp). Regarding the possibility of root processes opening a device which is locked - I consider this a feature not a potential problem. It is highly unlikely, that somebody is crazy enough to run a JavaVM as root (unless he has no other means of getting a restricted IP port opened, ie doesnt understand ipfw). Anyway, even if the process runs as root, it fails when calling ioctl(fd, TIOCEXCL). It could however still open the port to listen for RING events. I.e. a fax server which needs to see incoming calls but otherwise doesnt want to block the port. So the only case where the proposed mechanism fails is, if an incorrectly implemented process running as root conflicts with a user process. I think this can be accepted. Regards, Joachim PS: If this patch is generally accepted, the installer and Mac doku should obviously be changed as well. Index: SerialImp.c =================================================================== RCS file: /usr/local/cvsroot/rxtx-devel/src/SerialImp.c,v retrieving revision 1.46.2.187 diff -u -r1.46.2.187 SerialImp.c --- SerialImp.c 29 Jan 2006 22:19:04 -0000 1.46.2.187 +++ SerialImp.c 21 Mar 2006 12:59:16 -0000 @@ -656,6 +656,25 @@ fd=OPEN (filename, O_RDWR | O_NOCTTY | O_NONBLOCK ); } while (fd < 0 && errno==EINTR); +#ifdef OPEN_EXCL + // Note that open() follows POSIX semantics: multiple open() calls to + // the same file will succeed unless the TIOCEXCL ioctl is issued. + // This will prevent additional opens except by root-owned processes. + // See tty(4) ("man 4 tty") and ioctl(2) ("man 2 ioctl") for details. + + if (fd >= 0 && (ioctl(fd, TIOCEXCL) == -1)) + { + sprintf( message, "open: exclusive access denied for % s\n", + filename ); + report( message ); + report_error( message ); + + close(fd); + goto fail; + } +#endif /* OPEN_EXCL */ + + if( configure_port( fd ) ) goto fail; (*env)->ReleaseStringUTFChars( env, jstr, filename ); sprintf( message, "open: fd returned is %i\n", fd ); Index: SerialImp.h =================================================================== RCS file: /usr/local/cvsroot/rxtx-devel/src/SerialImp.h,v retrieving revision 1.11.2.49 diff -u -r1.11.2.49 SerialImp.h --- SerialImp.h 5 Jul 2005 17:47:21 -0000 1.11.2.49 +++ SerialImp.h 21 Mar 2006 12:59:17 -0000 @@ -135,7 +135,8 @@ /*# define LOCKDIR "/var/spool/uucp"*/ # define LOCKDIR "/var/lock" # define LOCKFILEPREFIX "LK." -# define UUCP +/*# define UUCP*/ +# define OPEN_EXCL #endif /* __APPLE__ */ #if defined(__NetBSD__) # define DEVICEDIR "/dev/" From tjarvi at qbang.org Tue Mar 21 10:26:08 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 21 Mar 2006 10:26:08 -0700 (MST) Subject: [Rxtx] Javadoc on the go In-Reply-To: <441FA98B.9050701@ngi.it> References: <441FA98B.9050701@ngi.it> Message-ID: On Tue, 21 Mar 2006, Fabio Frumento wrote: > Hi Trent, > > sorry for the big delay but my job is running wild, i was out for some > time but now i'm back and ready to continue the javadoc for Rxtx. > > Did you used the last javadoc patch i sent you ? let me know if i have to > send it to you again or not. > > regards > > Fabio Hi Fabio The patch is in the rxtx mail-list archives. It will be going in soon. I did not see a time critical portion. I'll probably be going through the list since the last batch of patches this weekend and putting them into CVS. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Tue Mar 21 10:57:18 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 21 Mar 2006 10:57:18 -0700 (MST) Subject: [Rxtx] jvm issue In-Reply-To: <20060321065524.94779.qmail@web50701.mail.yahoo.com> References: <20060321065524.94779.qmail@web50701.mail.yahoo.com> Message-ID: On Mon, 20 Mar 2006, Lambok Sianturi wrote: > Hi All, > This is my first time to join RxTx mailing list. I thank you all for allowing others to sign in in requests help. > I use the latest RxTx lib in Fedora 3 with java version 1.4.2_09 b05. And I got this error: > > # > # An unexpected error has been detected by HotSpot Virtual Machine: > # > # SIGSEGV (0xb) at pc=0x00bf27f3, pid=2633, tid=3086112448 > # > # Java VM: Java HotSpot(TM) Client VM (1.4.2_09-b05 mixed mode) > # Problematic frame: > # C [ld-linux.so.2+0xa7f3] A native library loading error? What happens if you recompile rxtx on your system and install that? This sounds like an ABI problem? rxtx 2.1-7 was compiled with a gcc 2.96 toolchain as I recall. The hope is newer system will be backwards compatible. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Tue Mar 21 11:05:29 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 21 Mar 2006 11:05:29 -0700 (MST) Subject: [Rxtx] PATCH: use of ioctl(fd, TIOCEXCL) instead of lockfiles In-Reply-To: <923AE774-EEA2-4911-92D8-32BB27802C8B@buechse.de> References: <923AE774-EEA2-4911-92D8-32BB27802C8B@buechse.de> Message-ID: On Tue, 21 Mar 2006, Joachim Buechse wrote: > Here is the patch for the ioctl(fd, TIOCEXCL). I have verified this only > for OSX 10.4.5, hence it is only defined for APPLE. However, it should > work at least for Solaris as well. > > If a process has requested TIOEXCL further open calls by other user > processes will fail. > > The patch also disables uucp style locking for APPLE. Obviously this is > discussable. I think it is the way to go, as it eliminates creating the > lock directory which doesnt exist on the standard installation and it > eliminates messing with the system group definitions (adding users to > group uucp). > > Regarding the possibility of root processes opening a device which is > locked - I consider this a feature not a potential problem. It is highly > unlikely, that somebody is crazy enough to run a JavaVM as root (unless > he has no other means of getting a restricted IP port opened, ie doesnt > understand ipfw). Anyway, even if the process runs as root, it fails when > calling ioctl(fd, TIOCEXCL). It could however still open the port to > listen for RING events. I.e. a fax server which needs to see incoming > calls but otherwise doesnt want to block the port. So the only case where > the proposed mechanism fails is, if an incorrectly implemented process > running as root conflicts with a user process. I think this can be > accepted. > > Regards, > Joachim > > PS: If this patch is generally accepted, the installer and Mac doku > should obviously be changed as well. > > > Index: SerialImp.c > =================================================================== > RCS file: /usr/local/cvsroot/rxtx-devel/src/SerialImp.c,v > retrieving revision 1.46.2.187 > diff -u -r1.46.2.187 SerialImp.c > --- SerialImp.c 29 Jan 2006 22:19:04 -0000 1.46.2.187 > +++ SerialImp.c 21 Mar 2006 12:59:16 -0000 > @@ -656,6 +656,25 @@ > fd=OPEN (filename, O_RDWR | O_NOCTTY | O_NONBLOCK ); > } while (fd < 0 && errno==EINTR); > > +#ifdef OPEN_EXCL > + // Note that open() follows POSIX semantics: multiple open() > calls to > + // the same file will succeed unless the TIOCEXCL ioctl is > issued. > + // This will prevent additional opens except by root-owned > processes. > + // See tty(4) ("man 4 tty") and ioctl(2) ("man 2 ioctl") for > details. > + > + if (fd >= 0 && (ioctl(fd, TIOCEXCL) == -1)) > + { > + sprintf( message, "open: exclusive access denied for % > s\n", > + filename ); > + report( message ); > + report_error( message ); > + > + close(fd); > + goto fail; > + } > +#endif /* OPEN_EXCL */ > + > + > if( configure_port( fd ) ) goto fail; > (*env)->ReleaseStringUTFChars( env, jstr, filename ); > sprintf( message, "open: fd returned is %i\n", fd ); > Index: SerialImp.h > =================================================================== > RCS file: /usr/local/cvsroot/rxtx-devel/src/SerialImp.h,v > retrieving revision 1.11.2.49 > diff -u -r1.11.2.49 SerialImp.h > --- SerialImp.h 5 Jul 2005 17:47:21 -0000 1.11.2.49 > +++ SerialImp.h 21 Mar 2006 12:59:17 -0000 > @@ -135,7 +135,8 @@ > /*# define LOCKDIR "/var/spool/uucp"*/ > # define LOCKDIR "/var/lock" > # define LOCKFILEPREFIX "LK." > -# define UUCP > +/*# define UUCP*/ > +# define OPEN_EXCL > #endif /* __APPLE__ */ > #if defined(__NetBSD__) > # define DEVICEDIR "/dev/" > This looks like a good start. What do you think Dmitry? Perhaps all systems with TIOCEXCL defined should use that though. Even if they use lockfiles. It wont hurt anything. That would catch people hacking their own serial apps without checking lockfiles. Its a good idea to avoid C++ style comments in the C portions. Some older systems don't deal with them well. If it's just for Mac OS X, it isn't a big deal. I think it was the Irix compiler that was problematic? -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Tue Mar 21 11:22:05 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 21 Mar 2006 11:22:05 -0700 (MST) Subject: [Rxtx] lock files In-Reply-To: <8E12916A-1B9A-4FF2-B684-E2D1C794221B@buechse.de> References: <8E12916A-1B9A-4FF2-B684-E2D1C794221B@buechse.de> Message-ID: We can try it. Maybe the JNI is much improved. The nice thing about linking into liblock is distros then worry about lockfiles on their systems. This way, we have to deal with any changes that may show up. On Tue, 21 Mar 2006, Joachim Buechse wrote: > This is pretty much what I thought about when I suggested, that the > default behaviour could be overwritten with a property. I am very much in > favor of this approach. In particular this allows much easier debugging > for PC based java developers. > > I think big parts of the Java (and maybe some parts of the C code) could > use a bit of a structural workover (unit tests, javadoc, synchronization, > etc). Maybe there should be a CVS branch for this experimental version. > I'd be happy to contribute a first workover for some of the Java code. > Designing for testability and implementing a good bunch of unit tests has > been a strategy that worked quite well in the Java projects I lead. And > it ultimately allows more liberal change permission. > > Regards, > Joachim > > > On 21.03.2006, at 08:51, Dr. Douglas Lyon wrote: > >> Hi All, >> You know, if the use of lock files were >> under Java control (rather than a build-time decision), >> it might enable a more unified binary distro. It might also >> facilitate quick prototyping of non-lock file approaches >> to resolving serial port contention issues (i.e., mac-like >> approaches vs. linux approaches, etc.). >> >> I realize that this is a radical overhaul of the lock file policy >> issue. Also, it may harm performance. On the other hand, >> our benchmarks on JNI overhead for modern processors indicate >> performance impact should be minimal. Perhaps it is more of >> an issue with the toybox systems. >> >> Suppose there were a class with a reasonable default...someone >> might write: >> SerialPortLockPolicy.setPolicy(SerialPortLockPolicy.UNIX_LOCK_FILE); >> SerialPortLockPolicy.setPolicy(SerialPortLockPolicy.NO_LOCK_CHECKING); >> SerialPortLockPolicy.setPolicy(SerialPortLockPolicy.MAC_STYLE); >> >> Thus, we could have a run-time reconfiguration of the serial port lock >> policy. A special NO_LOCK version of the binary would no longer >> be required. >> >> Any thoughts on this? >> >> Thanks! >> - Doug >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From dmarkman at mac.com Tue Mar 21 16:05:17 2006 From: dmarkman at mac.com (Dmitry Markman) Date: Tue, 21 Mar 2006 18:05:17 -0500 Subject: [Rxtx] PATCH: use of ioctl(fd, TIOCEXCL) instead of lockfiles In-Reply-To: References: <923AE774-EEA2-4911-92D8-32BB27802C8B@buechse.de> Message-ID: <512AC70C-BB86-48F2-A83C-023F35C23BAB@mac.com> I think it's cool, but I'd like to have that property implementation when user can choose between locking mechanism about comments: it's easy to change comments to the C style or we can use extensions of the file to cpp so c++ compiler will be used On Mar 21, 2006, at 1:05 PM, Trent Jarvi wrote: > This looks like a good start. What do you think Dmitry? Perhaps > all systems with TIOCEXCL defined should use that though. Even if > they use lockfiles. It wont hurt anything. That would catch > people hacking their own serial apps without checking lockfiles. > > Its a good idea to avoid C++ style comments in the C portions. > Some older systems don't deal with them well. If it's just for Mac > OS X, it isn't a big deal. I think it was the Irix compiler that > was problematic? Dmitry Markman From dmarkman at mac.com Tue Mar 21 16:13:00 2006 From: dmarkman at mac.com (Dmitry Markman) Date: Tue, 21 Mar 2006 18:13:00 -0500 Subject: [Rxtx] PATCH: use of ioctl(fd, TIOCEXCL) instead of lockfiles In-Reply-To: References: <923AE774-EEA2-4911-92D8-32BB27802C8B@buechse.de> Message-ID: I'd like to add that creating locking folder isn't a big deal we never had a problem related to the lock folders, because we always used installer on mac os x from other hand I'm not very much familiar with iotcl locking approach and I'm not sure it's more efficient Joachim wrote "I think it is the way to go, as it eliminates creating the lock directory which doesnt exist on the standard installation and it eliminates messing with the system group definitions (adding users to group uucp)." but I really didn't have any problem with that 1. doesn't exist on the standard installation there are many-many things that don't exist in the standard installation so I don't think that argument is strong enough 2. messing with the system group definitions I don't think we're messing with the group definition mac os x provides very clear way to set up group's members and together with Greg Guerin AuthKit there is no problem to set those definitions so I don't think that argument is strong either but from other hand using iotcl is more promising and is more elegant On Mar 21, 2006, at 1:05 PM, Trent Jarvi wrote: > > This looks like a good start. What do you think Dmitry? Perhaps > all systems with TIOCEXCL defined should use that though. Even if > they use lockfiles. It wont hurt anything. That would catch > people hacking their own serial apps without checking lockfiles. Dmitry Markman From joachim at buechse.de Wed Mar 22 04:46:45 2006 From: joachim at buechse.de (Joachim Buechse) Date: Wed, 22 Mar 2006 12:46:45 +0100 Subject: [Rxtx] PATCH: use of ioctl(fd, TIOCEXCL) instead of lockfiles In-Reply-To: References: <923AE774-EEA2-4911-92D8-32BB27802C8B@buechse.de> Message-ID: Sorry, I was not very clear with my arguments, so I will try again;-) Please, don't take this as an attack against work that has been done. I think the contributions that have been made in the past were made in a good spirit. But I really believe, that the current solution for OSX has many shortcomings and should be changed as soon as possible. lock files --- The /var/lock folder does not exist on the standard OSX installation, however the standard installation includes several applications that use serial ports (i.e. the FAX capability). This indicates, that the lock folder approach will not work well with system components. Applications for OSX will generally try to live in harmony with system components (except for HP print drivers of course). I think RXTX should follow this approach as well. uucp group --- Accessing serial ports is not an admin privileged operation on OSX. Any user (world) has read/write privileges on /dev/tty*. So the system default is to not enforce any group membership to access these ports. The group uucp however is a system group on all unix systems I know. It exists for certain system processes. A non admin user should in general not be a member of this group. Quite arguably no user should ever be a member of this group. Installer --- My general opinion is, that - no Installer should touch user or group data without warning - no Application Installer should touch groups which are not specific to the very application installed - no Installer should ever add regular users to a system group The current installer injects the installing user in the group uucp without warning about this change and without giving the option to "opt out" of this change. This is a potential security risk (but not currently a real one, as OSX contains no folders belonging to group uucp). The current installer does not work for multi user systems. It puts the installing user in the uucp group. However the installing user is not necessarily the user that will use the application. Putting all users that may use a serial port application in the system group uucp seems like a very invasive approach to me. Besides that, newly created users will not automatically be in the group and hence, serial applications will "break" for new users without obvious reasons. Avoiding the lock files will allow self contained applications (i.e. drag&drop installation). In my eyes this is largely preferable over an installer that requests admin privileges. Adding up all these points indicates very strongly, that the lock-file implementation is not the way to go on OSX. Regards, Joachim On 22.03.2006, at 00:13, Dmitry Markman wrote: > I'd like to add that > > creating locking folder isn't a big deal > we never had a problem related to the lock folders, because we > always used installer on mac os x > from other hand I'm not very much familiar with iotcl locking > approach and I'm not sure it's more efficient > > Joachim wrote "I think it is the way to go, as it eliminates > creating the lock directory which doesnt exist on the standard > installation and it eliminates messing with the system group > definitions (adding users to group uucp)." but I really didn't have > any problem with that > > 1. doesn't exist on the standard installation > there are many-many things that don't exist in the standard > installation so I don't think that argument is strong enough > 2. messing with the system group definitions > I don't think we're messing with the group definition > mac os x provides very clear way to set up group's members and > together with Greg Guerin AuthKit there is no problem to set those > definitions > so I don't think that argument is strong either > but from other hand using iotcl is more promising and is more elegant > > > > On Mar 21, 2006, at 1:05 PM, Trent Jarvi wrote: > >> >> This looks like a good start. What do you think Dmitry? Perhaps >> all systems with TIOCEXCL defined should use that though. Even if >> they use lockfiles. It wont hurt anything. That would catch >> people hacking their own serial apps without checking lockfiles. > > Dmitry Markman > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From dmarkman at mac.com Wed Mar 22 05:27:13 2006 From: dmarkman at mac.com (Dmitry Markman) Date: Wed, 22 Mar 2006 07:27:13 -0500 Subject: [Rxtx] PATCH: use of ioctl(fd, TIOCEXCL) instead of lockfiles In-Reply-To: References: <923AE774-EEA2-4911-92D8-32BB27802C8B@buechse.de> Message-ID: <83440CF3-DCD8-41C1-B941-F227232C27E3@mac.com> thanks for the very good explanation I didn't think that you were attacking any thing, so don't worry I just had feeling, that there were more aesthetic reasons for going to ioctl then real necessity now you explained everything quite well (BTW, asfar as I remember installer asks admin password so it wasn't quiet, but it really doesn't matter now) thanks On Mar 22, 2006, at 6:46 AM, Joachim Buechse wrote: > Sorry, I was not very clear with my arguments, so I will try again;-) > > Please, don't take this as an attack against work that has been > done. I think the contributions that have been made in the past > were made in a good spirit. But I really believe, that the current > solution for OSX has many shortcomings and should be changed as > soon as possible. > > lock files > --- > The /var/lock folder does not exist on the standard OSX > installation, however the standard installation includes several > applications that use serial ports (i.e. the FAX capability). This > indicates, that the lock folder approach will not work well with > system components. Applications for OSX will generally try to live > in harmony with system components (except for HP print drivers of > course). I think RXTX should follow this approach as well. > > uucp group > --- > Accessing serial ports is not an admin privileged operation on OSX. > Any user (world) has read/write privileges on /dev/tty*. So the > system default is to not enforce any group membership to access > these ports. The group uucp however is a system group on all unix > systems I know. It exists for certain system processes. A non admin > user should in general not be a member of this group. Quite > arguably no user should ever be a member of this group. > > Installer > --- > My general opinion is, that > - no Installer should touch user or group data without warning > - no Application Installer should touch groups which are not > specific to the very application installed > - no Installer should ever add regular users to a system group > > The current installer injects the installing user in the group uucp > without warning about this change and without giving the option to > "opt out" of this change. This is a potential security risk (but > not currently a real one, as OSX contains no folders belonging to > group uucp). > > The current installer does not work for multi user systems. It puts > the installing user in the uucp group. However the installing user > is not necessarily the user that will use the application. Putting > all users that may use a serial port application in the system > group uucp seems like a very invasive approach to me. Besides that, > newly created users will not automatically be in the group and > hence, serial applications will "break" for new users without > obvious reasons. > > > Avoiding the lock files will allow self contained applications > (i.e. drag&drop installation). In my eyes this is largely > preferable over an installer that requests admin privileges. Adding > up all these points indicates very strongly, that the lock-file > implementation is not the way to go on OSX. > > Regards, > Joachim > > > On 22.03.2006, at 00:13, Dmitry Markman wrote: > >> I'd like to add that >> >> creating locking folder isn't a big deal >> we never had a problem related to the lock folders, because we >> always used installer on mac os x >> from other hand I'm not very much familiar with iotcl locking >> approach and I'm not sure it's more efficient >> >> Joachim wrote "I think it is the way to go, as it eliminates >> creating the lock directory which doesnt exist on the standard >> installation and it eliminates messing with the system group >> definitions (adding users to group uucp)." but I really didn't >> have any problem with that >> >> 1. doesn't exist on the standard installation >> there are many-many things that don't exist in the standard >> installation so I don't think that argument is strong enough >> 2. messing with the system group definitions >> I don't think we're messing with the group definition >> mac os x provides very clear way to set up group's members and >> together with Greg Guerin AuthKit there is no problem to set those >> definitions >> so I don't think that argument is strong either >> but from other hand using iotcl is more promising and is more elegant >> >> >> >> On Mar 21, 2006, at 1:05 PM, Trent Jarvi wrote: >> >>> >>> This looks like a good start. What do you think Dmitry? Perhaps >>> all systems with TIOCEXCL defined should use that though. Even >>> if they use lockfiles. It wont hurt anything. That would catch >>> people hacking their own serial apps without checking lockfiles. >> >> Dmitry Markman >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx Dmitry Markman From lyon at docjava.com Wed Mar 22 06:12:18 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Wed, 22 Mar 2006 08:12:18 -0500 Subject: [Rxtx] sole of a new design pattern Message-ID: Hi All, I have been thinking about how we design the serial port software. I think we need a new design pattern. For lack of a better term, I shall call it: The Parametric Singleton Design Pattern By Douglas A. Lyon ABSTRACT The goal of the singleton design pattern is to make sure that there is one, and only one, instance of a given class. The goal of the parametric singleton design pattern is to make sure that there is one, and only one, instance of a given class with the given parametric values. We parametric singleton design pattern combines the singleton design pattern with a parameter that enables unique creation of instances of a class. These instances are cached. When a user asks for an instance with these parameters, the cache is checked. If the instance is in the cache, the instance is returned, otherwise it is created, added to the cache and then returned. We apply our parametric singleton design pattern to the retrieval of RMI registries bound to a given port. The goal of our system is to make sure that no two RMI registries are listening to the same socket and to make use of the RMI registries after they have been created. RMI registries are used in distributed computation. Introduction The singleton design pattern is meant to ensure that on a single instance of a class exists. It is also meant to provide a global point of access to it. The intent of the parametric singleton design pattern is to ensure that a class has only one instance for a given set of parameter values. It also provides a global point of access to it. Motivation A system cannot tolerate multiple instances of some classes with identical parameters. For example, you cannot have two instances making use of the same serial port, at the same time. You cannot have two instances that are trying to listen to the same socket connection. You cannot have two instances writing to the same file structure at the same time. As the operating system is often thought of as the arbiter of consumed resources (i.e., tape drives, serial ports, etc.) we frequently leave it to an operating system implementation to resolve these contention issues. Even for similar resources (like serial ports) there are few standards for handling contention. For example, serial ports on Linux are locked using a "/var/lock" file. POSIX, on the other hand, uses ioctl mechanisms to prevent contention. A better solution is to make a class that is responsible for keeping track of the instances created from the class. The class is declared final, so that it cannot be subclassed. The class also has a private constructor, so that other classes cannot instance it. The new design pattern is called the parametric singleton design pattern and it provides a way to access and create instances with given parameters. Applicability Use the Parametric Singleton Design Pattern when: 1. There must be exactly one instance of a class with the given parameters. 2. The instances must be accessible to clients from a well-known access point. Structure Insert UML diagram here. Participants The Parametric Singleton Clients that need instances 1. The Parametric Singleton defines an instance upon request from a client, if, and only if, the instance does not already exist. 2. The Parametric Singleton returns the instance to the client. 3. The Parametric Singleton is responsible for creating unique instances from given parameters. Collaborations Clients obtain a reference to a Parametric Singleton instance only through the parametric singleton design pattern. If the instance is left in an improper state (e.g., the serial port was left open) it is NOT the role of the Parametric Singleton Design Pattern to close the IO port. Nor is it the role of the Parametric Singleton Design Pattern to open the port. That role is delegate to some other part of the system. Further, it is not the role of the Parametric Singleton Design Pattern to check out resources. That is, multiple threads can have multiple references to the same resource at the same time. MUTEX locking is delegated to some other part of the system. Consequences The Parametric Singleton Design Pattern has several benefits: 1. Controlled access to parametrically defined instances. Since the Parametric Singleton class encapsulates its instances, there is control over how and when clients access it. 2. Reduced name space. The Parametric Singleton pattern avoids global variables that store instances created from the same parameter. Implementation Here are implementation issues to consider when using the Parametric Singleton pattern: 1. Unique mapping of parameters. The Parametric Singleton pattern requires that there be a mean to isomorphically map the parameter space into the instance space and back again. 2. Ensure unique instances. The Parametric Singleton pattern makes unique instances from parameters, and it does so only once. 3. Cache instances for fast retrieval. The Parametric Singleton pattern must be able to look up instances, given some set of parameters, and do so from some data structure. That is, there must be enough space to hold references to all the instances the program will need. Also, a mechanism is needed to look up and retrieve the instances quickly enough to satisfy the clients. Sample Code public final class ParametricSingletonRmiRegistry { private static Hashtable registry = new Hashtable(100); // use singleton pattern and??????????????????????????????????????????????? // prevent instantiation of RmiRegistryUtils.?????????????????????????????? private ParametricSingletonRmiRegistry() { } // the only instance of the Registry held by the RmiRegistryUtils?????????? public static void listNames(Integer port) { if (!isInCacheAndRunning(port)) return; Registry r = (Registry) registry.get(port); System.out.println("registry on port: " + port); System.out.println("registry: " + r); System.out.println("names: "); try { print(r.list()); } catch (RemoteException e) { In.message(e); } System.out.println("------------------------"); } /**???????????????????????????????????????????????????????????????????????? * Checks whether a Registry has been started on this host????????????????? * in the specified port.?????????????????????????????????????????????????? * If not, it tries to start one.?????????????????????????????????????????? * when it fails to start a Registry, it exits the program????????????????? * with exit code 1.??????????????????????????????????????????????????????? */ public static void restart(int port) { if (isInCacheAndRunning(port)) return; try { startRegistry(port); } catch (RemoteException e) { In.message(e); } } /**???????????????????????????????????????????????????????????????????????? * @param port????????????????????????????????????????????????????????????? * @return true if registry is in cache and running???????????????????????? */ private static boolean isInCacheAndRunning(Integer port) { if (!isRegistryRunning(port.intValue())) return false; if (!isRegistryInCache(port.intValue())) return false; return true; } /**???????????????????????????????????????????????????????????????????????? * @param port????????????????????????????????????????????????????????????? * @return true if we are able to locate a local registry on port.??????????????????????????????????????????????????????????????????????????? */ private static boolean isRegistryRunning(int port) { try { Registry r = LocateRegistry.getRegistry(port); if (r != null) return true; } catch (RemoteException e) { return false; } return false; } /**???????????????????????????????????????????????????????????????????????? * @param port????????????????????????????????????????????????????????????? * @return return true if registry is in cache????????????????????????????? */ private static boolean isRegistryInCache(int port) { if (registry.get(new Integer(port)) == null) return false; return true; } /**???????????????????????????????????????????????????????????????????????? * Restart the registry, if needed.???????????????????????????????????????? * Return the only instance of the registry for consistent global?????????? * using by making use of the Singleton Design Pattern????????????????????? *????????????????????????????????????????????????????????????????????????? * @return the internally held registry instance.?????????????????????????? */ public static Registry getRegistry(Integer port) { restart(port); return (Registry) registry.get(port); } private static void startRegistry(Integer port) throws RemoteException { Registry r; try { r = LocateRegistry.createRegistry(port.intValue()); registry.put(port, r); //r = new sun.rmi.registry.RegistryImpl???????????????????????????? /// (port.intValue());?????????????????????????????????????? // registry.put(port, r);?????????????????????????????????????????? } catch (Exception e) { //e.printStackTrace();????????????????????????????????????????????? r = LocateRegistry.getRegistry(port.intValue()); registry.put(port, r); } } public static void main(String args[]) throws RemoteException { //restart(port);??????????????????????????????????????????????????????? restart(5001); restart(5002); restart(5002); Registry r = LocateRegistry.getRegistry(5002); System.out.println("registry="+r); } } I would very much like to get your feedback on this new design pattern idea. Thank you for your time. Regards, - Doug From david.garnier at trusted-logic.com Wed Mar 22 07:36:10 2006 From: david.garnier at trusted-logic.com (David Garnier) Date: Wed, 22 Mar 2006 15:36:10 +0100 Subject: [Rxtx] sole of a new design pattern In-Reply-To: References: Message-ID: <442160DA.80107@trusted-logic.com> Hello, > The Parametric Singleton Design Pattern The Singleton is the most abused design pattern ever. Good use-cases for this pattern are extremely rare and mostly confined to problems related to hardware resources, like serial ports. > Applicability > > Use the Parametric Singleton Design Pattern when: > 1. There must be exactly one instance of a class with the given > parameters. OK. As I said above, this case this actually very unusual. The Singleton pattern is mostly used when : > 2. The instances must be accessible to clients from a well-known > access point. Using the singleton pattern in this case is just convenient for the programmer. Problems arises pretty quickly, especially if you attempt to unit-test your classes. 1) If your singleton is stateful, or hold on to stateful objects, it means that two different unit tests are not actually independent. Instead of starting with a brand new environment, the result of a test may be affected by the result of a previous test. This problem also arise when with your class relies on a database. In both cases, the solution is to reset your "unique" resource (Singleton or database) at the beginning of the test, which is a pain. Also, while most projects connect to a single database, projects that allow the use of Singletons usually contain several of thems, and new ones may cropped up unnoticed. You quickly end up with test cases that only pass in a certain order, which is a royal pain. 2) You cannot mockup a singleton. Once everyone calls the SomeSingleton class statically, you can't replace your class by SomeSingletonMockup. Furthermore, even for hardware services, the Singleton pattern does not really prevent concurrent accesses. If you start the same program in two different JVMs, unless they somehow shared the state of their "Singletons" (through lock files for example), the Singleton pattern will not prevent concurrent access. Our application uses RXTX, and we routinely encounter cases where another (native) application has already locked the port. Since we cannot modify the native application to recognize lock files, OS-level control is irreplaceable. > > Consequences > The Parametric Singleton Design Pattern has several benefits: > > 1. Controlled access to parametrically defined instances. Since > the Parametric Singleton class encapsulates its instances, there is > control over how and when clients access it. Not really. Once you've returned the instance to a client, you've lost control over it. The client can to whatever it wants with it. You cannot "recall" the instance or claim it back. > 2. Reduced name space. The Parametric Singleton pattern avoids > global variables that store instances created from the same parameter. Sure, but you don't have to rely on a Singleton for that. Just create a single Factory. > I would very much like to get your feedback on this new design > pattern idea. Well, it's nothing new. Some may say that it is the point of design patterns: formalizes the designs that occur again and again. However, this design is simply a combination of the Singleton and Factory patterns. I did use it in the past, but now I've been exposed to the shortcomings of the Singleton pattern, so I limit myself to Factories. Regards, David From sean_montgomery at baseview.com Wed Mar 22 08:35:28 2006 From: sean_montgomery at baseview.com (Sean Montgomery) Date: Wed, 22 Mar 2006 10:35:28 -0500 Subject: [Rxtx] sole of a new design pattern In-Reply-To: <442160DA.80107@trusted-logic.com> References: <442160DA.80107@trusted-logic.com> Message-ID: <05769CA7-A51B-4CF0-BAA0-E02DD905F5A4@baseview.com> On Mar 22, 2006, at 9:36 AM, David Garnier wrote: > Furthermore, even for hardware services, the Singleton pattern does > not really prevent concurrent > accesses. If you start the same program in two different JVMs, > unless they somehow shared the state > of their "Singletons" (through lock files for example), the > Singleton pattern will not prevent > concurrent access. > Multiple class loaders in a single JVM can be tricky, too. Then there's synchronization, lazy initialization and serialization of singletons to contend with. Bloch's Effective Java covers these, and here's a few articles: http://www.javaworld.com/javaworld/jw-04-2003/jw-0425-designpatterns- p3.html http://java.sun.com/developer/technicalArticles/Programming/singletons/ Just FYI :-) From lyon at docjava.com Wed Mar 22 08:50:48 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Wed, 22 Mar 2006 10:50:48 -0500 Subject: [Rxtx] sole of a new design pattern In-Reply-To: <442160DA.80107@trusted-logic.com> References: <442160DA.80107@trusted-logic.com> Message-ID: Hi All, First, I would like to thank David for his prompt and thoughtful remarks. I had no idea people that feel strongly about a design patterns! Wow! Feedback (particularly critical feedback) is greatly appreciated. Starting at the end, first: >I did use it in >the past, but now I've been exposed to the shortcomings of the >Singleton pattern, so I limit myself to Factories. David, if I understood your comments correctly, you suggested that Factories can be used in leu of the Singleton Design Pattern, or even the Parametric Singleton Design Pattern. As I see in [Gof]: Factory Method: Intent "Define an interface for creating an object, but let subclasses decide which class to instantiate. Factory Method lets a class defer instantiation to subclasses." The Singleton Design Pattern is a concrete class, which is rather different, right? Also, subclasses are not permitted with Singleton, as they are final. Naturally, I could use an abstract factory as a parent for a singleton. I could even design a facade that could be implemented with the singleton....but that is not the intention of the design. Unless you want a mock-up, as discussed, below: More below: >Hello, > >> The Parametric Singleton Design Pattern > >The Singleton is the most abused design pattern ever. Good use-cases >for this pattern are extremely >rare and mostly confined to problems related to hardware resources, >like serial ports. > > >> Applicability >> >> Use the Parametric Singleton Design Pattern when: >> 1. There must be exactly one instance of a class with the given >> parameters. >OK. As I said above, this case this actually very unusual. The >Singleton pattern is mostly used when : >> 2. The instances must be accessible to clients from a well-known >> access point. > >Using the singleton pattern in this case is just convenient for the >programmer. Problems arises >pretty quickly, especially if you attempt to unit-test your classes. > >1) If your singleton is stateful, or hold on to stateful objects, it >means that two different unit >tests are not actually independent. Instead of starting with a brand >new environment, the result of >a test may be affected by the result of a previous test. This >problem also arise when with your >class relies on a database. In both cases, the solution is to reset >your "unique" resource >(Singleton or database) at the beginning of the test, which is a >pain. Also, while most projects >connect to a single database, projects that allow the use of >Singletons usually contain several of >thems, and new ones may cropped up unnoticed. You quickly end up >with test cases that only pass in a >certain order, which is a royal pain. There are basic problems with communicating finite state machines that include reachability and deadlock analysis. These are addressed with petri net analysis and are beyond the scope of the design pattern. As you quite rightly pointed out; the parametric singleton pattern (or the singleton pattern, for that matter) enable multiple threads to gain access to the same instance. The only way that I can see to block others from gaining access to the reference is the synchronize keyword. This is putting a spin-lock (or MUTEX) on the reference. The question of how to unit-test a design pattern like the parametric singleton remains open. Perhaps this is a deficiency. > >2) You cannot mockup a singleton. Once everyone calls the >SomeSingleton class statically, you can't >replace your class by SomeSingletonMockup. Acutally, I am not sure that this is true. If the Singleton implements a Facade interface, it should be possible to make the replacement. Right? > >Furthermore, even for hardware services, the Singleton pattern does >not really prevent concurrent >accesses. If you start the same program in two different JVMs, >unless they somehow shared the state >of their "Singletons" (through lock files for example), the >Singleton pattern will not prevent >concurrent access. Good Point!! You have sharp eyes! The singleton design pattern should/could take responsibility for this. In fact, you may notice that my code does have an implementation (LocateRegistry) that can work across JVM's. The LocateRegistry will even work across the Internet! LocateRegistry takes both a host name and a Port (lock files just don't do this). I did not think to implement this beyond the local machine, but, in its present form, it will work across different processes. > >Our application uses RXTX, and we routinely encounter cases where >another (native) application has >already locked the port. Since we cannot modify the native >application to recognize lock files, >OS-level control is irreplaceable. The singleton design pattern is not meant to replace OS-level control, but to centralize the Java programmers access to it. If lock files, for example, are used for serial ports, the Singleton Design Pattern should be able to work with them. > > >> >> Consequences >> The Parametric Singleton Design Pattern has several benefits: >> > > 1. Controlled access to parametrically defined instances. Since >> the Parametric Singleton class encapsulates its instances, there is >> control over how and when clients access it. > >Not really. Once you've returned the instance to a client, you've >lost control over it. The client >can to whatever it wants with it. You cannot "recall" the instance >or claim it back. Good point, this should read: > 1. Controll when parametrically defined instances are created. Since > > the Parametric Singleton class encapsulates its instances, there is > > control over how and when they are instanced. > >> 2. Reduced name space. The Parametric Singleton pattern avoids >> global variables that store instances created from the same parameter. > >Sure, but you don't have to rely on a Singleton for that. Just >create a single Factory. > > Thank you for your thoughtful and prompt response! Regards, - Doug From dmarkman at mac.com Wed Mar 22 21:21:55 2006 From: dmarkman at mac.com (Dmitry Markman) Date: Wed, 22 Mar 2006 23:21:55 -0500 Subject: [Rxtx] sole of a new design pattern In-Reply-To: <442160DA.80107@trusted-logic.com> References: <442160DA.80107@trusted-logic.com> Message-ID: I don't think I get it On Mar 22, 2006, at 9:36 AM, David Garnier wrote: > Using the singleton pattern in this case is just convenient for the > programmer. Problems arises > pretty quickly, especially if you attempt to unit-test your classes. so you're saying that something isn't so good because you can not test it in the convenient way? if that's true, I'm totally disagree change your test, debug whatever, but if software is efficient at runtime, works fine and only problem is some unit test (which is some kind of framework for testing) then dump that unit test , dump that unit framework and make something appropriate to the software you're testing so if Douglas want to use singletons, what's the problem? and what do you mean by abusing of singleton usage? of course singleton doesn't prevent concurrent access to the resource across the processes unless you're using some OS facility to prevent it, besides singleton as it was introduced is relevant only and only inside of the same process otherwise it's not singleton it's something else (let's say network singleton: so you have remote invocation facility and some factory method that return object created by that facility) I don't have any problem with using any kind of singletons. Parametric Singleton idea (if I understand it right) could be easily implemented in the following way: use a map populate map with instances of some class and key is your parameter (you can use lazy population too) if somebody ask the key check the value if it's null so resource is taken if somebody returns the resource put it back to the map public synchronized static Object getSomeResource(Object parameter); public synchronized static void returnResource(Object parameter); getSomeResource (inside of the same process) could return null in 2 cases 1. if somebody (from other thread for example) already took that resource 2. if OS API said that resource corresponded to that parameter (serial port with parameter = 1 (port #)) is locked and unavailable; I'm not sure that in case of serial ports we even need those Parametric Singletons (unless lock checking is a very expensive operation) just ask the OS about availability of that resource and if it's available give it away and then OS will lock it and therefore in next time somebody ask it just answer that resource is locked and return null for example system has 2 serial ports available so I ask getResource("tty"); or I ask getResource("Bluetooth-Modem"); and if OS is ok you can give tty or Bluetooth-Modem or both no need for any additional pattern I think back to the problem mac os x doesn't recognize locking via files, so it handles locking via some API an instance of the singleton in each process should recognize that resource is locked (by using that API) that's all we don't have to make things more complicate then they are just because there is some nice design pattern or nice unit test framework or whatever keep things simple, make them work fast, don't introduce middle layers unless you have really good reason to do so of course I could be entirely wrong, so sorry about that in advance thanks Dmitry Markman From tjarvi at qbang.org Wed Mar 22 22:31:41 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 22 Mar 2006 22:31:41 -0700 (MST) Subject: [Rxtx] sole of a new design pattern In-Reply-To: References: Message-ID: Hi Doug Interesting reading. So far I'm just reading and thinking. I have one question so far. " Clients obtain a reference to a Parametric Singleton instance only through the parametric singleton design pattern. If the instance is left in an improper state (e.g., the serial port was left open) it is NOT the role of the Parametric Singleton Design Pattern to close the IO port. Nor is it the role of the Parametric Singleton Design Pattern to open the port. That role is delegate to some other part of the system. " So when the clients obtain a reference to the singleton, can they assume the port is there? IE, would it be the singletons role to handle things like USB dongles being removed with event hints comming from the underlying OS. Hardware abstraction layer/HAL on Linux is an example of underlying OS events. I assume that role too is delegated to other parts of the system? -- Trent Jarvi tjarvi at qbang.org From lyon at docjava.com Thu Mar 23 08:10:33 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Thu, 23 Mar 2006 10:10:33 -0500 Subject: [Rxtx] Classes don't need goals, they need roles! In-Reply-To: References: Message-ID: Hi Trent, Yes, I think that the role of the Parametric Singleton Pattern is not to open or close serial ports, nor is it to perform error checking. On the other hand, if you were to combine the role of the Parametric Singleton Pattern with another role (like that of error checking) it might not be amiss. However, I generally caution programmers against adding multiple roles to classes, as this leads to monolithic designs. Thus a different class (NativeLibDetect) could have the role of determining if the native library can be loaded. Another class (SerialPortBean) can have the role of serializing the default state of the serial port, so that it can be recovered, from user preferences, at a later time. The SerialPortDetect could have the role of determining if the serial port is removed (i.e., a USB port was unplugged). My guess is that each class should have a different role in the system, in order to ease maintenance and testing...but I could be wrong about that. Thanks! - Doug >Hi Doug > >Interesting reading. So far I'm just reading and thinking. I have >one question so far. > >" > Clients obtain a reference to a Parametric Singleton instance only >through the parametric singleton design pattern. If the instance is >left in an improper state (e.g., the serial port was left open) it is >NOT the role of the Parametric Singleton Design Pattern to close the >IO port. Nor is it the role of the Parametric Singleton Design Pattern >to >open the port. That role is delegate to some other part of the system. >" > >So when the clients obtain a reference to the singleton, can they >assume the port is there? IE, would it be the singletons role to >handle things like USB dongles being removed with event hints >comming from the underlying OS. Hardware abstraction layer/HAL on >Linux is an example of underlying OS events. > >I assume that role too is delegated to other parts of the system? > >-- >Trent Jarvi >tjarvi at qbang.org >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From maximulo at yahoo.com Fri Mar 24 01:22:38 2006 From: maximulo at yahoo.com (Maximulo Majir) Date: Fri, 24 Mar 2006 00:22:38 -0800 (PST) Subject: [Rxtx] JavaPOS Message-ID: <20060324082238.66371.qmail@web38214.mail.mud.yahoo.com> Hi all! Hello Trent! From what i understand, RXTX or JavaComm APIs were not created solely for JavaPOS. In JavaPOS, we have the virtual method claim() which is separate from open(), but in our RXTX API, claiming is done every call to open(), we cant open the port if its claimed by another application. Would it be alright to suggest or ask to create a new method called claim(..)? Is there such thing as forceclaim() in RXTX? this could be the same as portownership transfer or its equivalent. ForceClaim is in JSR80. Do you have some samples using RXTX as the lower layer for the Device Service Objects in JavaPOS? I have tried it, i just want to compare. Thank you all! maxim __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060324/496adba2/attachment-0015.html From tjarvi at qbang.org Fri Mar 24 11:28:19 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 24 Mar 2006 11:28:19 -0700 (MST) Subject: [Rxtx] Re: RXTX 2.1 Solaris Problems In-Reply-To: <3691.1143210578@www045.gmx.net> References: <3691.1143210578@www045.gmx.net> Message-ID: On Fri, 24 Mar 2006, Andreas Guenther wrote: > Hi all, > > the solaris problem was not the lock file only. > > Ok, I had to create the directory /var/spool/locks myself. > /var/spool/uucp exists. > > But rxtx didn't find any port. > > I compiled the source with my own debug-informations > and I tried to isolate the problem. > > The problem is the testRead-call in SerialImp.c > > JNIEXPORT jboolean JNICALL RXTXCommDriver(testRead)( > > ... > if ( READ( fd, &c, 1 ) < 0 ) > { > if ( errno != EAGAIN ) { > report( "testRead() read failed\n" ); > ret = JNI_FALSE; > } > } > Thanks Andreas I'm packing up to move. I'll be more or less away for a couple weeks here. I'll be checking email but my workstation is going into a box soon. This isn't hard to fix as this port should be enumerated when EWOULDBLOCK is recieved. Thats error is OK for enumeration just as EAGAIN is. I've put the bug into bugzilla so we dont forget to get to it. http://bugzilla.qbang.org/show_bug.cgi?id=42 You can add yourself to the CC list if you wish to test fixes we provide or even put a patch into bugzilla yourself. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Fri Mar 24 11:51:52 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 24 Mar 2006 11:51:52 -0700 (MST) Subject: [Rxtx] JavaPOS In-Reply-To: <20060324082238.66371.qmail@web38214.mail.mud.yahoo.com> References: <20060324082238.66371.qmail@web38214.mail.mud.yahoo.com> Message-ID: On Fri, 24 Mar 2006, Maximulo Majir wrote: > Hi all! Hello Trent! > > > From what i understand, RXTX or JavaComm APIs were not > created solely for JavaPOS. In JavaPOS, we have the virtual method > claim() which is separate from open(), but in our RXTX API, claiming is > done every call to open(), we cant open the port if its claimed by > another application. Would it be alright to suggest or ask to create a > new method called claim(..)? Is there such thing as forceclaim() in > RXTX? this could be the same as portownership transfer or its > equivalent. ForceClaim is in JSR80. > Do you have some samples using RXTX as the lower layer for the Device > Service Objects in JavaPOS? I have tried it, i just want to compare. > maxim Hi Maxim JSR80 is the USB API IBM/Sun put together. The problem is they have a richer kernel/API underneath that can handle such things. With Serial Ports, there isnt anything there other than an ioctl that says don't let anyone touch this and lockfiles that are more of a 'lets be nice.' At times we may be using USB ports but it is through the termios layer with the limitations mentioned. The advantage is that not only USB will work with rxtx. Anything that has a termios layer should work (to the extent that termios layer is complete). I don't know how forceclaim() would help you. Lets say someone has a programmer working on /dev/ttyS0 and you take it. Now you both race each other to read data first. There isn't a mechanism I know of that will solve this problem in termios. The most obvious test being a native app and a Java app trying to take the port. There is the potential of requestion ownership from other Java Applications but the use for that is very rare. Did you have something more specific in mind that I'm missing? I'm not sure that claim() and forceclaim() would help you with rxtx other than maybe locking the port with claim() without opening it. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sat Mar 25 23:42:08 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 25 Mar 2006 23:42:08 -0700 (MST) Subject: [Rxtx] Serial snoop Message-ID: I was reading the Linux kernel mail-list tonight and ran past a thread that mentioned sersnoop. This looks like a handy tool for people dealing with new toys. "a simple command-line tool for linux that echoes bytes to and from any two serial ports, ptys, or network sockets, and prints all traffic to stdout, in hex and ascii." http://www.restivo.org/projects/sersnoop/ It works on Linux only at this time (debian package available). -- Trent Jarvi tjarvi at qbang.org From beat.arnet at gmail.com Sun Mar 26 07:32:35 2006 From: beat.arnet at gmail.com (Beat Arnet) Date: Sun, 26 Mar 2006 09:32:35 -0500 Subject: [Rxtx] Error 0x5 at /home/bob/foo/tar/rxtx-2.1-7/build/../src/termios.c(860): Access is, denied. Message-ID: <4426A603.80508@gmail.com> Dear all, When trying to open the serial port, I sometimes (not always) run into the following exception (when opening the serialPort): Error 0x5 at /home/bob/foo/tar/rxtx-2.1-7/build/../src/termios.c(860): Access is denied. java.lang.UnsatisfiedLinkError: native_psmisc_report_owner at gnu.io.CommPortIdentifier.native_psmisc_report_owner(Native Method) at gnu.io.CommPortIdentifier.open(CommPortIdentifier.java:354) at codeskin.tools.CLLoader.open(CLLoader.java:79) at codeskin.tools.C2000Programmer.run(C2000Programmer.java:220) at java.lang.Thread.run(Unknown Source) Is this the type of error where I should just try to open the port again, or can it be avoided? Regards, Beat From tjarvi at qbang.org Sun Mar 26 11:40:12 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 26 Mar 2006 11:40:12 -0700 (MST) Subject: [Rxtx] Error 0x5 at /home/bob/foo/tar/rxtx-2.1-7/build/../src/termios.c(860): Access is, denied. In-Reply-To: <4426A603.80508@gmail.com> References: <4426A603.80508@gmail.com> Message-ID: On Sun, 26 Mar 2006, Beat Arnet wrote: > Dear all, > > When trying to open the serial port, I sometimes (not always) run into > the following exception (when opening the serialPort): > > Error 0x5 at /home/bob/foo/tar/rxtx-2.1-7/build/../src/termios.c(860): > Access is > denied. > > java.lang.UnsatisfiedLinkError: native_psmisc_report_owner > at gnu.io.CommPortIdentifier.native_psmisc_report_owner(Native > Method) > at gnu.io.CommPortIdentifier.open(CommPortIdentifier.java:354) > at codeskin.tools.CLLoader.open(CLLoader.java:79) > at codeskin.tools.C2000Programmer.run(C2000Programmer.java:220) > at java.lang.Thread.run(Unknown Source) > > Is this the type of error where I should just try to open the port again, > or can it be avoided? > Hi Beat We did a second build of rxtx 2.1-7 to resolve that unsatisfied link error. It should work now. rxtx is trying to tell you it thinks someone else has the serial port open. You can try to open the port again but maybe you already have a copy of the program running when it happens? ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7r2.zip fixed build. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sun Mar 26 11:44:23 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 26 Mar 2006 11:44:23 -0700 (MST) Subject: [Rxtx] RXTX spec file (fwd) Message-ID: This is probably interesting for fedora/suse users. ---------- Forwarded message ---------- Date: Sun, 26 Mar 2006 16:25:45 +0200 To: taj at www.linux.org.uk Subject: RXTX spec file I send you this spec file which allows to create a RPM for Fedora 4, 5 (x86, x86_64) with Java Sun. -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: rxtx.spec Url: http://mailman.qbang.org/pipermail/rxtx/attachments/20060326/6c7b6af6/rxtx-0011.pl From tjarvi at qbang.org Sun Mar 26 23:42:59 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 26 Mar 2006 23:42:59 -0700 (MST) Subject: [Rxtx] Upcomming events. Message-ID: This Wednesday we will be announcing a new "Maintainer" for the rxtx project. The position is more like neutral leader. I wont be going away or doing less. This is just the right thing to do as it turns out the two people with CVS write access will be at the same company. We need a third and we need neutrality. The maintainer will have final say in any conflict and will try to be neutral. It will be open for discussion. Then we will do it :) I'll still do most of the footwork I do now. But. I'm falling behind. I should have gone through the mail-list and posted the next round of changes this weekend. I'm packing to move and its going so so - 13 years of toys collected. I suspect there will be a dead period on my part (a couple weeks) comming up. But if you get it on the mail-list, we will get it in if there are no objections. I may well not be reading the mail-list during this period as I look for a house and many other things. I hope everyone will help out. Thanks -- Trent Jarvi tjarvi at qbang.org From mahmoud_hadad at yahoo.com Sun Mar 26 07:31:19 2006 From: mahmoud_hadad at yahoo.com (ronan nick) Date: Sun, 26 Mar 2006 06:31:19 -0800 (PST) Subject: [Rxtx] a question about the COMM API Message-ID: <20060326143119.54919.qmail@web60014.mail.yahoo.com> hi, i was intrested in knowing how i can communicate with my internal modem using java? for example if i want to make a phone dialer application or a caller id application where should i be looking at? and as i understood the COMM API is for devices that is attached to the computer through serial ports. --------------------------------- New Yahoo! Messenger with Voice. Call regular phones from your PC and save big. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060326/ce8329f0/attachment-0013.html From dmarkman at mac.com Mon Mar 20 00:20:43 2006 From: dmarkman at mac.com (Dmitry Markman) Date: Mon, 20 Mar 2006 02:20:43 -0500 Subject: [Rxtx] Mac OS X RXTX java installer In-Reply-To: References: <07D0DE29-BA32-4CFE-B036-66BC6423D385@buechse.de> <441AE3E0.2030503@willicon.de> <12531986.1142622114996.JavaMail.dmarkman@mac.com> <441B2674.9010409@willicon.de> <13577405.1142634732776.JavaMail.dmarkman@mac.com> <441B4182.8010407@willicon.de> <92CD0D6C-5BE8-426E-A46D-99452059FF49@mac.com> <441BBB2D.8030305@willicon.de> <441C4088.5090905@willicon.de> Message-ID: <64BC1E23-FDDE-4CE6-8863-CFC881CBC224@mac.com> Hi all I put RXTX installer that will install everything (and will create / var/lock if necessary and add user to the uucp group) for mac os x from Java into the rxtx's CVS repository it could be easily modified to install files for any platform it uses Greg Guerin's AuthKit for authentication and authorization Greg released that kit under artistic license, so Trent, please take a look we, probably, can negotiate license with Greg if it's necessary Greg's AuthKit could be downloaded from http://www.amug.org/~glguerin/ sw/#authkit Michael Hall (mikehall at spacestar dot net) had a suggestion to make implementation of the jaas LoginModule based on Greg's AuthKit (his modification of the Greg's AuthKit could be found at http:// www.spacestar.net/users/mikehall/authkit.dmg) but Michael's AuthKitLoginModule does only half a job: it does authenticate but it can not run any external unix process in privileged mode (at least I wasn't able to do so) possible explanation could be found in conversation between Greg and Michael at Apple's java-dev list (look for archives) so I didn't use jaas API for rxtxinstaller I created folder MacOSX in the contrib folder comment 1. if you want to run that installer as standalone application all you need that RXTXInstaller.jar 2. if you want to use webstart you have to add Greg's libAuthKit.jnilib to the mac os x's resources in theory RXTXInstaller.jar doesn't need it, but there is a problem with loading libAuthKit.jnilib from webstart authkit uses loadLibrary method to load library and it failed (from webstart) for standalone application I extract libAuthKit.jnilib from the RXTXInstaller.jar and put it into the /Library/Java/Extensions or ~/Library/Java/Extensions folder that file will be deleted after installer quit unfortunately I didn't have time to put documentation there but it is mostly self-explanatory I took installer code from my gl4java installer that I did about 3 years ago (with small modifications) it would be very nice if Apple will release LoginModule that really will do the job (com.apple.security.auth.module package????? ) (UnixLoginModule is pretty useless) From lyon at docjava.com Mon Mar 20 06:34:39 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Mon, 20 Mar 2006 08:34:39 -0500 Subject: [Rxtx] Mac OS X RXTX java installer In-Reply-To: <64BC1E23-FDDE-4CE6-8863-CFC881CBC224@mac.com> References: <07D0DE29-BA32-4CFE-B036-66BC6423D385@buechse.de> <441AE3E0.2030503@willicon.de> <12531986.1142622114996.JavaMail.dmarkman@mac.com> <441B2674.9010409@willicon.de> <13577405.1142634732776.JavaMail.dmarkman@mac.com> <441B4182.8010407@willicon.de> <92CD0D6C-5BE8-426E-A46D-99452059FF49@mac.com> <441BBB2D.8030305@willicon.de> <441C4088.5090905@willicon.de> <64BC1E23-FDDE-4CE6-8863-CFC881CBC224@mac.com> Message-ID: Hi Dimitry, This sounds like great work. Just a couple of questions; After the check out of the CVS files, using: setenv CVSROOT :pserver:anonymous at cvs.milestonesolutions.com:/usr/local/cvsroot 53 8:28 setenv PASSWORD mousy 54 8:29 cvs login 55 8:29 cvs checkout rxtx-devel I cd'd over to: rxtx-devel/MACOSX_IDE And found: CVS/ CW/ ForPackageMaker/ PB/ Where is the installer? Thanks! - Doug From tjarvi at qbang.org Mon Mar 20 06:39:37 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 20 Mar 2006 06:39:37 -0700 (MST) Subject: [Rxtx] Mac OS X RXTX java installer In-Reply-To: References: <07D0DE29-BA32-4CFE-B036-66BC6423D385@buechse.de> <441AE3E0.2030503@willicon.de> <12531986.1142622114996.JavaMail.dmarkman@mac.com> <441B2674.9010409@willicon.de> <13577405.1142634732776.JavaMail.dmarkman@mac.com> <441B4182.8010407@willicon.de> <92CD0D6C-5BE8-426E-A46D-99452059FF49@mac.com> <441BBB2D.8030305@willicon.de> <441C4088.5090905@willicon.de> <64BC1E23-FDDE-4CE6-8863-CFC881CBC224@mac.com> Message-ID: On Mon, 20 Mar 2006, Dr. Douglas Lyon wrote: > Hi Dimitry, > This sounds like great work. Just a couple of questions; > After the check out of the CVS files, using: > setenv CVSROOT > :pserver:anonymous at cvs.milestonesolutions.com:/usr/local/cvsroot > 53 8:28 setenv PASSWORD mousy > 54 8:29 cvs login > 55 8:29 cvs checkout rxtx-devel Hi Doug You want "cvs checkout -r commapi-0-0-1 rxtx-devel" to get RXTX 2.1 The default branch is rxtx 2.0 which isn't very active right now. -- Trent Jarvi tjarvi at qbang.org From lyon at docjava.com Mon Mar 20 07:05:44 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Mon, 20 Mar 2006 09:05:44 -0500 Subject: [Rxtx] Mac OS X RXTX java installer In-Reply-To: References: <07D0DE29-BA32-4CFE-B036-66BC6423D385@buechse.de> <441AE3E0.2030503@willicon.de> <12531986.1142622114996.JavaMail.dmarkman@mac.com> <441B2674.9010409@willicon.de> <13577405.1142634732776.JavaMail.dmarkman@mac.com> <441B4182.8010407@willicon.de> <92CD0D6C-5BE8-426E-A46D-99452059FF49@mac.com> <441BBB2D.8030305@willicon.de> <441C4088.5090905@willicon.de> <64BC1E23-FDDE-4CE6-8863-CFC881CBC224@mac.com> Message-ID: Hi Trent, Thanks for the info on the CVS checkout procedure. I did that and am still not sure where the installer is. Here is what I have: cd MACOSX_IDE/ p4.docjava.com{lyon}121: ls CVS/ ForPackageMaker/ PB/ p4.docjava.com{lyon}122: find . | more . ./ForPackageMaker ./ForPackageMaker/RXTX.pkg.sit.hqx ./ForPackageMaker/Resources ./ForPackageMaker/Resources/ReadMe.rtf ./ForPackageMaker/Resources/Welcome.rtf ./ForPackageMaker/Resources/CVS ./ForPackageMaker/Resources/CVS/Entries ./ForPackageMaker/Resources/CVS/Repository ./ForPackageMaker/Resources/CVS/Tag ./ForPackageMaker/Resources/CVS/Root ./ForPackageMaker/Resources/preinstall ./ForPackageMaker/Resources/License.rtf ./ForPackageMaker/Resources/preupgrade ./ForPackageMaker/RXTX.pmsp ./ForPackageMaker/CVS ./ForPackageMaker/CVS/Entries ./ForPackageMaker/CVS/Repository ./ForPackageMaker/CVS/Entries.Log ./ForPackageMaker/CVS/Tag ./ForPackageMaker/CVS/Root ./ForPackageMaker/RXTX_Tiger.pkg.sitx.hqx ./ForPackageMaker/RXTX_Jag.pkg.sit.hqx ./ForPackageMaker/Install ./ForPackageMaker/Install/CVS ./ForPackageMaker/Install/CVS/Entries ./ForPackageMaker/Install/CVS/Repository ./ForPackageMaker/Install/CVS/Tag ./ForPackageMaker/Install/CVS/Root ./ForPackageMaker/Install/Library ./ForPackageMaker/Install/Library/CVS ./ForPackageMaker/Install/Library/CVS/Entries ./ForPackageMaker/Install/Library/CVS/Repository ./ForPackageMaker/Install/Library/CVS/Tag ./ForPackageMaker/Install/Library/CVS/Root ./ForPackageMaker/Install/Library/Java ./ForPackageMaker/Install/Library/Java/Extensions ./ForPackageMaker/Install/Library/Java/Extensions/RXTXcomm.jar ./ForPackageMaker/Install/Library/Java/Extensions/CVS ./ForPackageMaker/Install/Library/Java/Extensions/CVS/Entries ./ForPackageMaker/Install/Library/Java/Extensions/CVS/Repository ./ForPackageMaker/Install/Library/Java/Extensions/CVS/Tag ./ForPackageMaker/Install/Library/Java/Extensions/CVS/Root ./ForPackageMaker/Install/Library/Java/Extensions/librxtxSerial.jnilib ./ForPackageMaker/Install/Library/Java/CVS ./ForPackageMaker/Install/Library/Java/CVS/Entries ./ForPackageMaker/Install/Library/Java/CVS/Repository ./ForPackageMaker/Install/Library/Java/CVS/Entries.Log ./ForPackageMaker/Install/Library/Java/CVS/Tag ./ForPackageMaker/Install/Library/Java/CVS/Root ./ForPackageMaker/RXTX_Tiger.pmproj.sitx.hqx ./CVS ./CVS/Entries ./CVS/Repository ./CVS/Entries.Log ./CVS/Tag ./CVS/Root ./PB ./PB/LibSerialUniversal.xcodeproj.sitx.hqx ./PB/CVS ./PB/CVS/Entries ./PB/CVS/Repository ./PB/CVS/Entries.Log ./PB/CVS/Tag ./PB/CVS/Root ./PB/LibSerial.pbproj.sit.hqx ./PB/startpoint.c ./PB/config.h What is the procedure to run this installer? Do we need a README in: /rxtx-devel/MACOSX_IDE Here is what we have: CVS/ ForPackageMaker/ PB/ Thanks! - DL >On Mon, 20 Mar 2006, Dr. Douglas Lyon wrote: > >>Hi Dimitry, >>This sounds like great work. Just a couple of questions; >>After the check out of the CVS files, using: >>setenv CVSROOT >>:pserver:anonymous at cvs.milestonesolutions.com:/usr/local/cvsroot >> 53 8:28 setenv PASSWORD mousy >> 54 8:29 cvs login >> 55 8:29 cvs checkout rxtx-devel > >Hi Doug > >You want "cvs checkout -r commapi-0-0-1 rxtx-devel" to get RXTX 2.1 >The default branch is rxtx 2.0 which isn't very active right now. > >-- >Trent Jarvi >tjarvi at qbang.org From tjarvi at qbang.org Mon Mar 20 07:25:30 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 20 Mar 2006 07:25:30 -0700 (MST) Subject: [Rxtx] Mac OS X RXTX java installer In-Reply-To: References: <07D0DE29-BA32-4CFE-B036-66BC6423D385@buechse.de> <441AE3E0.2030503@willicon.de> <12531986.1142622114996.JavaMail.dmarkman@mac.com> <441B2674.9010409@willicon.de> <13577405.1142634732776.JavaMail.dmarkman@mac.com> <441B4182.8010407@willicon.de> <92CD0D6C-5BE8-426E-A46D-99452059FF49@mac.com> <441BBB2D.8030305@willicon.de> <441C4088.5090905@willicon.de> <64BC1E23-FDDE-4CE6-8863-CFC881CBC224@mac.com> Message-ID: On Mon, 20 Mar 2006, Dr. Douglas Lyon wrote: > Hi Trent, > Thanks for the info on the CVS checkout procedure. > I did that and am still not sure where the installer is. Hi Doug It does look like it was not cvs committed. There is no rxtx-devel/contrib/MacOSX directory in there at the moment. It was mentioned that it was put under contrib. -- Trent Jarvi tjarvi at qbang.org From dmarkman at mac.com Mon Mar 20 07:29:56 2006 From: dmarkman at mac.com (Dmitry Markman) Date: Mon, 20 Mar 2006 09:29:56 -0500 Subject: [Rxtx] Mac OS X RXTX java installer In-Reply-To: References: <07D0DE29-BA32-4CFE-B036-66BC6423D385@buechse.de> <441AE3E0.2030503@willicon.de> <12531986.1142622114996.JavaMail.dmarkman@mac.com> <441B2674.9010409@willicon.de> <13577405.1142634732776.JavaMail.dmarkman@mac.com> <441B4182.8010407@willicon.de> <92CD0D6C-5BE8-426E-A46D-99452059FF49@mac.com> <441BBB2D.8030305@willicon.de> <441C4088.5090905@willicon.de> <64BC1E23-FDDE-4CE6-8863-CFC881CBC224@mac.com> Message-ID: <6054EB4E-F7E0-4A9C-BDDA-D582D6D8826F@mac.com> you can find it in the rxtx-devel/contrib folder On Mar 20, 2006, at 9:05 AM, Dr. Douglas Lyon wrote: > Hi Trent, > Thanks for the info on the CVS checkout procedure. > I did that and am still not sure where the installer is. > Here is what I have: > cd MACOSX_IDE/ > p4.docjava.com{lyon}121: ls > CVS/ ForPackageMaker/ PB/ > p4.docjava.com{lyon}122: find . | more > . > ./ForPackageMaker > ./ForPackageMaker/RXTX.pkg.sit.hqx > ./ForPackageMaker/Resources > ./ForPackageMaker/Resources/ReadMe.rtf > ./ForPackageMaker/Resources/Welcome.rtf > ./ForPackageMaker/Resources/CVS > ./ForPackageMaker/Resources/CVS/Entries > ./ForPackageMaker/Resources/CVS/Repository > ./ForPackageMaker/Resources/CVS/Tag > ./ForPackageMaker/Resources/CVS/Root > ./ForPackageMaker/Resources/preinstall > ./ForPackageMaker/Resources/License.rtf > ./ForPackageMaker/Resources/preupgrade > ./ForPackageMaker/RXTX.pmsp > ./ForPackageMaker/CVS > ./ForPackageMaker/CVS/Entries > ./ForPackageMaker/CVS/Repository > ./ForPackageMaker/CVS/Entries.Log > ./ForPackageMaker/CVS/Tag > ./ForPackageMaker/CVS/Root > ./ForPackageMaker/RXTX_Tiger.pkg.sitx.hqx > ./ForPackageMaker/RXTX_Jag.pkg.sit.hqx > ./ForPackageMaker/Install > ./ForPackageMaker/Install/CVS > ./ForPackageMaker/Install/CVS/Entries > ./ForPackageMaker/Install/CVS/Repository > ./ForPackageMaker/Install/CVS/Tag > ./ForPackageMaker/Install/CVS/Root > ./ForPackageMaker/Install/Library > ./ForPackageMaker/Install/Library/CVS > ./ForPackageMaker/Install/Library/CVS/Entries > ./ForPackageMaker/Install/Library/CVS/Repository > ./ForPackageMaker/Install/Library/CVS/Tag > ./ForPackageMaker/Install/Library/CVS/Root > ./ForPackageMaker/Install/Library/Java > ./ForPackageMaker/Install/Library/Java/Extensions > ./ForPackageMaker/Install/Library/Java/Extensions/RXTXcomm.jar > ./ForPackageMaker/Install/Library/Java/Extensions/CVS > ./ForPackageMaker/Install/Library/Java/Extensions/CVS/Entries > ./ForPackageMaker/Install/Library/Java/Extensions/CVS/Repository > ./ForPackageMaker/Install/Library/Java/Extensions/CVS/Tag > ./ForPackageMaker/Install/Library/Java/Extensions/CVS/Root > ./ForPackageMaker/Install/Library/Java/Extensions/librxtxSerial.jnilib > ./ForPackageMaker/Install/Library/Java/CVS > ./ForPackageMaker/Install/Library/Java/CVS/Entries > ./ForPackageMaker/Install/Library/Java/CVS/Repository > ./ForPackageMaker/Install/Library/Java/CVS/Entries.Log > ./ForPackageMaker/Install/Library/Java/CVS/Tag > ./ForPackageMaker/Install/Library/Java/CVS/Root > ./ForPackageMaker/RXTX_Tiger.pmproj.sitx.hqx > ./CVS > ./CVS/Entries > ./CVS/Repository > ./CVS/Entries.Log > ./CVS/Tag > ./CVS/Root > ./PB > ./PB/LibSerialUniversal.xcodeproj.sitx.hqx > ./PB/CVS > ./PB/CVS/Entries > ./PB/CVS/Repository > ./PB/CVS/Entries.Log > ./PB/CVS/Tag > ./PB/CVS/Root > ./PB/LibSerial.pbproj.sit.hqx > ./PB/startpoint.c > ./PB/config.h > > What is the procedure to run this installer? > Do we need a README in: > /rxtx-devel/MACOSX_IDE > Here is what we have: > CVS/ ForPackageMaker/ PB/ > > > Thanks! > - DL > >> On Mon, 20 Mar 2006, Dr. Douglas Lyon wrote: >> >>> Hi Dimitry, >>> This sounds like great work. Just a couple of questions; >>> After the check out of the CVS files, using: >>> setenv CVSROOT :pserver:anonymous at cvs.milestonesolutions.com:/usr/ >>> local/cvsroot >>> 53 8:28 setenv PASSWORD mousy >>> 54 8:29 cvs login >>> 55 8:29 cvs checkout rxtx-devel >> >> Hi Doug >> >> You want "cvs checkout -r commapi-0-0-1 rxtx-devel" to get RXTX 2.1 >> The default branch is rxtx 2.0 which isn't very active right now. >> >> -- >> Trent Jarvi >> tjarvi at qbang.org > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx Dmitry Markman From mikehall at spacestar.net Mon Mar 20 05:25:25 2006 From: mikehall at spacestar.net (Michael Hall) Date: Mon, 20 Mar 2006 06:25:25 -0600 Subject: [Rxtx] Re: Mac OS X RXTX java installer In-Reply-To: <64BC1E23-FDDE-4CE6-8863-CFC881CBC224@mac.com> References: <07D0DE29-BA32-4CFE-B036-66BC6423D385@buechse.de> <441AE3E0.2030503@willicon.de> <12531986.1142622114996.JavaMail.dmarkman@mac.com> <441B2674.9010409@willicon.de> <13577405.1142634732776.JavaMail.dmarkman@mac.com> <441B4182.8010407@willicon.de> <92CD0D6C-5BE8-426E-A46D-99452059FF49@mac.com> <441BBB2D.8030305@willicon.de> <441C4088.5090905@willicon.de> <64BC1E23-FDDE-4CE6-8863-CFC881CBC224@mac.com> Message-ID: <247EB61F-5CD1-4132-89A2-FC105B6CF9A5@spacestar.net> On Mar 20, 2006, at 1:20 AM, Dmitry Markman wrote: > > Michael Hall (mikehall at spacestar dot net) had a suggestion to > make implementation of the jaas LoginModule > based on Greg's AuthKit > (his modification of the Greg's AuthKit could be found at http:// > www.spacestar.net/users/mikehall/authkit.dmg) > but Michael's AuthKitLoginModule does only half a job: > it does authenticate > but it can not run any external unix process in privileged mode (at > least I wasn't able to do so) If you got it working directly with Greg's the point is moot. But to clarify it anyhow. The login module does not allow you to do anything anything privileged on return as was explained by Greg. You need to work with a separate privileged process using the execPrivileged method of his API. I assume you did something similar although I haven't looked at how you are using it yet. I allowed instead for a action to be performed at the same time you login/authenticate,this... System.setProperty("authkit.action","/usr/bin/id"); just before this... lc.login(); To clarify, safely ignored as you are already complete. Mike Hall mikehall at spacestar dot net http://www.spacestar.net/users/mikehall http://sourceforge.net/projects/macnative -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2427 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20060320/f6e18202/smime-0016.bin From dmarkman at mac.com Mon Mar 20 07:36:47 2006 From: dmarkman at mac.com (Dmitry Markman) Date: Mon, 20 Mar 2006 09:36:47 -0500 Subject: [Rxtx] Re: Mac OS X RXTX java installer In-Reply-To: <247EB61F-5CD1-4132-89A2-FC105B6CF9A5@spacestar.net> References: <07D0DE29-BA32-4CFE-B036-66BC6423D385@buechse.de> <441AE3E0.2030503@willicon.de> <12531986.1142622114996.JavaMail.dmarkman@mac.com> <441B2674.9010409@willicon.de> <13577405.1142634732776.JavaMail.dmarkman@mac.com> <441B4182.8010407@willicon.de> <92CD0D6C-5BE8-426E-A46D-99452059FF49@mac.com> <441BBB2D.8030305@willicon.de> <441C4088.5090905@willicon.de> <64BC1E23-FDDE-4CE6-8863-CFC881CBC224@mac.com> <247EB61F-5CD1-4132-89A2-FC105B6CF9A5@spacestar.net> Message-ID: Hi, Michael all I have to do is to run some shell script I tried to use your action mechanism and it worked great so I just System.setProperty ("authkit.action","" ) and after that I even don't need to run anything like subject.doAs.... but after few thoughts I choose to use plain Greg's approach, because in that case I don't have to deal with various java's configurations files and therefore to use 2-3 -D parameters in the java command line especially it's useful for java web start (it's so fragile :-( ) thanks for the great job On Mar 20, 2006, at 7:25 AM, Michael Hall wrote: > > On Mar 20, 2006, at 1:20 AM, Dmitry Markman wrote: >> >> Michael Hall (mikehall at spacestar dot net) had a suggestion to >> make implementation of the jaas LoginModule >> based on Greg's AuthKit >> (his modification of the Greg's AuthKit could be found at http:// >> www.spacestar.net/users/mikehall/authkit.dmg) >> but Michael's AuthKitLoginModule does only half a job: >> it does authenticate >> but it can not run any external unix process in privileged mode >> (at least I wasn't able to do so) > > If you got it working directly with Greg's the point is moot. > > But to clarify it anyhow. > The login module does not allow you to do anything anything > privileged on return as was explained by Greg. You need to work > with a separate privileged process using the execPrivileged method > of his API. I assume you did something similar although I haven't > looked at how you are using it yet. > I allowed instead for a action to be performed at the same time you > login/authenticate,this... > System.setProperty("authkit.action","/usr/bin/id"); > just before this... > lc.login(); > To clarify, safely ignored as you are already complete. > > Mike Hall mikehall at spacestar dot net > http://www.spacestar.net/users/mikehall > http://sourceforge.net/projects/macnative > > > Dmitry Markman From dmarkman at mac.com Mon Mar 20 07:44:45 2006 From: dmarkman at mac.com (Dmitry Markman) Date: Mon, 20 Mar 2006 09:44:45 -0500 Subject: [Rxtx] Mac OS X RXTX java installer In-Reply-To: References: <07D0DE29-BA32-4CFE-B036-66BC6423D385@buechse.de> <441AE3E0.2030503@willicon.de> <12531986.1142622114996.JavaMail.dmarkman@mac.com> <441B2674.9010409@willicon.de> <13577405.1142634732776.JavaMail.dmarkman@mac.com> <441B4182.8010407@willicon.de> <92CD0D6C-5BE8-426E-A46D-99452059FF49@mac.com> <441BBB2D.8030305@willicon.de> <441C4088.5090905@willicon.de> <64BC1E23-FDDE-4CE6-8863-CFC881CBC224@mac.com> Message-ID: it's in the commapi-0-0-1 branch I tested it right now: cvs co -r commapi-0-0-1 rxtx-devel and I got everything On Mar 20, 2006, at 9:25 AM, Trent Jarvi wrote: > On Mon, 20 Mar 2006, Dr. Douglas Lyon wrote: > >> Hi Trent, >> Thanks for the info on the CVS checkout procedure. >> I did that and am still not sure where the installer is. > > Hi Doug > > It does look like it was not cvs committed. There is no rxtx-devel/ > contrib/MacOSX directory in there at the moment. It was mentioned > that it was put under contrib. > > -- > Trent Jarvi > tjarvi at qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx Dmitry Markman From tjarvi at qbang.org Mon Mar 20 07:52:57 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 20 Mar 2006 07:52:57 -0700 (MST) Subject: [Rxtx] Mac OS X RXTX java installer In-Reply-To: References: <07D0DE29-BA32-4CFE-B036-66BC6423D385@buechse.de> <441AE3E0.2030503@willicon.de> <12531986.1142622114996.JavaMail.dmarkman@mac.com> <441B2674.9010409@willicon.de> <13577405.1142634732776.JavaMail.dmarkman@mac.com> <441B4182.8010407@willicon.de> <92CD0D6C-5BE8-426E-A46D-99452059FF49@mac.com> <441BBB2D.8030305@willicon.de> <441C4088.5090905@willicon.de> <64BC1E23-FDDE-4CE6-8863-CFC881CBC224@mac.com> Message-ID: On Mon, 20 Mar 2006, Dmitry Markman wrote: > it's in the commapi-0-0-1 branch > > I tested it right now: > cvs co -r commapi-0-0-1 rxtx-devel > > and I got everything > A fresh checkout worked. Here is a copy of the tree (just the installer bits) ftp://ftp.qbang.org/pub/rxtx/MacOSX-installer.zip -- Trent Jarvi tjarvi at qbang.org From lyon at docjava.com Mon Mar 20 08:08:26 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Mon, 20 Mar 2006 10:08:26 -0500 Subject: [Rxtx] Mac OS X RXTX java installer In-Reply-To: References: <07D0DE29-BA32-4CFE-B036-66BC6423D385@buechse.de> <441AE3E0.2030503@willicon.de> <12531986.1142622114996.JavaMail.dmarkman@mac.com> <441B2674.9010409@willicon.de> <13577405.1142634732776.JavaMail.dmarkman@mac.com> <441B4182.8010407@willicon.de> <92CD0D6C-5BE8-426E-A46D-99452059FF49@mac.com> <441BBB2D.8030305@willicon.de> <441C4088.5090905@willicon.de> <64BC1E23-FDDE-4CE6-8863-CFC881CBC224@mac.com> Message-ID: Hi All, Is the Auth package able to work properly on non Mac OS's? It was not clear from the doc or download. Thanks! - Doug From dmarkman at mac.com Mon Mar 20 08:15:22 2006 From: dmarkman at mac.com (Dmitry Markman) Date: Mon, 20 Mar 2006 10:15:22 -0500 Subject: [Rxtx] Mac OS X RXTX java installer In-Reply-To: References: <07D0DE29-BA32-4CFE-B036-66BC6423D385@buechse.de> <441AE3E0.2030503@willicon.de> <12531986.1142622114996.JavaMail.dmarkman@mac.com> <441B2674.9010409@willicon.de> <13577405.1142634732776.JavaMail.dmarkman@mac.com> <441B4182.8010407@willicon.de> <92CD0D6C-5BE8-426E-A46D-99452059FF49@mac.com> <441BBB2D.8030305@willicon.de> <441C4088.5090905@willicon.de> <64BC1E23-FDDE-4CE6-8863-CFC881CBC224@mac.com> Message-ID: <217312D8-CCCA-4859-ABA6-32DF1CC817B9@mac.com> thanks Trent, for putting it on ftp server On Mar 20, 2006, at 9:52 AM, Trent Jarvi wrote: > A fresh checkout worked. Here is a copy of the tree (just the > installer bits) > > ftp://ftp.qbang.org/pub/rxtx/MacOSX-installer.zip > Dmitry Markman From dmarkman at mac.com Mon Mar 20 09:14:03 2006 From: dmarkman at mac.com (Dmitry Markman) Date: Mon, 20 Mar 2006 11:14:03 -0500 Subject: [Rxtx] Mac OS X RXTX java installer In-Reply-To: References: <07D0DE29-BA32-4CFE-B036-66BC6423D385@buechse.de> <441AE3E0.2030503@willicon.de> <12531986.1142622114996.JavaMail.dmarkman@mac.com> <441B2674.9010409@willicon.de> <13577405.1142634732776.JavaMail.dmarkman@mac.com> <441B4182.8010407@willicon.de> <92CD0D6C-5BE8-426E-A46D-99452059FF49@mac.com> <441BBB2D.8030305@willicon.de> <441C4088.5090905@willicon.de> <64BC1E23-FDDE-4CE6-8863-CFC881CBC224@mac.com> Message-ID: <4DEBA6F0-DA45-4E84-823E-1F1AC48BDCCC@mac.com> no it will work only on mac os x however it's harmless to run it on other platform if you want to use it for other platform you have to do the following (I'll do it for linux) 1. modify RXTXInstaller class method public static RXTXInstaller getInstance() public static RXTXInstaller getInstance() { String osName = System.getProperty("os.name").toLowerCase(); if(osName.startsWith("mac")){ return new gnu.io.installer.macosx.MACOSXRXTXInstaller(); } else if(osName.startsWith("windows")){ return new gnu.io.installer.windows.WindowsRXTXInstaller(); }else if(osName.startsWith("linux")){ return new gnu.io.installer.linux.LinuxRXTXInstaller(); } return null; } 2. create folder gnu/io/installer/linux/ 3. create class Linux386RXTXInstaller package gnu.io.installer.linux; import java.io.File; public class Linux386RXTXInstaller extends gnu.io.installer.RXTXInstaller{ public Linux386RXTXInstaller(){ createJarFolder(); createLibFolder(); addJarResource("RXTXcomm.jar","/gnu/io/installer/resources/ linux/jar/RXTXcomm.dat"); addLibResource("librxtxSerial.so","/gnu/io/installer/ resources/linux/lib/librxtxSerial.so"); } protected void createJarFolder(){ String javaHome = System.getProperty("java.home"); char separator = File.separatorChar; jarFolder = new File(javaHome+separator+"lib"+separator+"ext"); } protected void createLibFolder(){ String javaHome = System.getProperty("java.home"); char separator = File.separatorChar; libFolder = new File(javaHome+separator+"bin"); } public void runPreProcess() {} //put here some action you need public void runPostProcess() {} //put here some action you need } 4. create folder /gnu/io/installer/resources/linux/jar and put there linux's version of RXTXcomm.dat (which is renamed RXTXcomm.jar) 5. create folder /gnu/io/installer/resources/linux/lib and put there linux's version of librxtxSerial. so 6. make sure that RXTXInstaller.jar has the following items: /gnu/io/installer/resources/linux/jar/RXTXcomm.jar /gnu/io/installer/resources/linux/lib/librxtxSerial.so 7. modify file installer.pref: jar file RXTXInstaller.jar must have the following item /gnu/io/installer/installer.pref that's basically it for windows you have to do the similar things: just replace linux to windows and librxtxSerial.so to rxtxSerial.dll and create appropriate gnu.io.installer.windows.WindowsRXTXInstaller class package gnu.io.installer.windows; import java.io.File; public class WindowsRXTXInstaller extends gnu.io.installer.RXTXInstaller{ public WindowsRXTXInstaller(){ createJarFolder(); createLibFolder(); addJarResource("RXTXcomm.jar","/gnu/io/installer/resources/ windows/jar/RXTXcomm.dat"); addLibResource("librxtxSerial.so","/gnu/io/installer/ resources/windows/lib/rxtxSerial.dll"); } protected void createJarFolder(){ String javaHome = System.getProperty("java.home"); char separator = File.separatorChar; jarFolder = new File(javaHome+separator+"lib"+separator+"ext"); } protected void createLibFolder(){ String javaHome = System.getProperty("java.home"); char separator = File.separatorChar; libFolder = new File(javaHome+separator+"bin"); } public void runPreProcess() {} //put here some action you need public void runPostProcess() {} //put here some action you need } installer.pref will look like On Mar 20, 2006, at 10:08 AM, Dr. Douglas Lyon wrote: > Hi All, > Is the Auth package able to work properly on > non Mac OS's? > It was not clear from the doc or download. > > Thanks! > - Doug > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx Dmitry Markman From joachim at buechse.de Mon Mar 20 10:49:06 2006 From: joachim at buechse.de (Joachim Buechse) Date: Mon, 20 Mar 2006 18:49:06 +0100 Subject: [Rxtx] BUG: Lock file stays even if port opening fails Message-ID: This was only tested on MacOSX but looking at the code, it should be true for all systems that use lock_uucp. I am opening a port which can not be opened (dialup port of a telephone paired via bluetooth but currently not reachable). The lock file is created and stays arround, even though the port open failed. After looking a bit through the code (of 2.17), I really wonder if it wouldn't be a good idea to make the "locking" an explicit operation called from the java code. This would certainly simplify the generation of meaningfull exceptions (and java based debugging). Maybe even the handling of "preopened" ports should be in the Java part of the lib (again for java based debugging puposes). That beeing said, I have no idea if this would be possible for the 2.07 implementation. Regards, Joachim From tjarvi at qbang.org Mon Mar 20 11:24:22 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 20 Mar 2006 11:24:22 -0700 (MST) Subject: [Rxtx] BUG: Lock file stays even if port opening fails In-Reply-To: References: Message-ID: On Mon, 20 Mar 2006, Joachim Buechse wrote: > This was only tested on MacOSX but looking at the code, it should be true > for all systems that use lock_uucp. > > I am opening a port which can not be opened (dialup port of a telephone > paired via bluetooth but currently not reachable). The lock file is > created and stays arround, even though the port open failed. > > > After looking a bit through the code (of 2.17), I really wonder if it > wouldn't be a good idea to make the "locking" an explicit operation > called from the java code. This would certainly simplify the generation > of meaningfull exceptions (and java based debugging). > Maybe even the handling of "preopened" ports should be in the Java part > of the lib (again for java based debugging puposes). That beeing said, I > have no idea if this would be possible for the 2.07 implementation. > > Regards, Hi Joachim It should be possible in the 2.0-7 implementation too. The calls to RXTXPort.java would not change. We would just do more there Moving more of that logic into Java would be better as many people don't like to look at C code. There is a liblockdev on most Linux distros that can do most of the C code and would be easier to use. The problem is embeded devices will not have that library. The preopened port code has not been really tested. That was a last minute request in a product cycle. I expect it will be tested this year though. As I recall, some devices really do not like CD raising on open. The preopened ports then allow people to mess around in java without power cycling the devices or losing data. -- Trent Jarvi tjarvi at qbang.org From joachim at buechse.de Mon Mar 20 12:01:08 2006 From: joachim at buechse.de (Joachim Buechse) Date: Mon, 20 Mar 2006 20:01:08 +0100 Subject: [Rxtx] BUG: Lock file stays even if port opening fails In-Reply-To: References: Message-ID: Hi Trent, What is your general feeling about moving code to Java? The last days I have been reading quite a bit of the code and there are several things, that might not work as expected. I'll give you two examples from is_device_locked: if LOCKDIR == /var/spool/locks the directory /var/spool/lock will not be checked. LOCKDIR is not checked for lockfiles with unexpected pefixes While these things have probably never been discovered in production, they are still possibly incorrect implementations. If it was Java code, I would write some unit tests producing the errors that could later be corrected. PS: One could imagine to actually implement the whole lockfile handling in Java using some native routines to get the values required (pid, st_dev, st_rdev, ...). On 20.03.2006, at 19:24, Trent Jarvi wrote: > On Mon, 20 Mar 2006, Joachim Buechse wrote: > >> This was only tested on MacOSX but looking at the code, it should >> be true for all systems that use lock_uucp. >> >> I am opening a port which can not be opened (dialup port of a >> telephone paired via bluetooth but currently not reachable). The >> lock file is created and stays arround, even though the port open >> failed. >> >> >> After looking a bit through the code (of 2.17), I really wonder if >> it wouldn't be a good idea to make the "locking" an explicit >> operation called from the java code. This would certainly simplify >> the generation of meaningfull exceptions (and java based debugging). >> Maybe even the handling of "preopened" ports should be in the Java >> part of the lib (again for java based debugging puposes). That >> beeing said, I have no idea if this would be possible for the 2.07 >> implementation. >> >> Regards, > > Hi Joachim > > It should be possible in the 2.0-7 implementation too. The calls > to RXTXPort.java would not change. We would just do more there > Moving more of that logic into Java would be better as many people > don't like to look at C code. There is a liblockdev on most Linux > distros that can do most of the C code and would be easier to use. > The problem is embeded devices will not have that library. > > The preopened port code has not been really tested. That was a > last minute request in a product cycle. I expect it will be tested > this year though. As I recall, some devices really do not like CD > raising on open. The preopened ports then allow people to mess > around in java without power cycling the devices or losing data. > > -- > Trent Jarvi > tjarvi at qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Mon Mar 20 12:21:02 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 20 Mar 2006 12:21:02 -0700 (MST) Subject: [Rxtx] BUG: Lock file stays even if port opening fails In-Reply-To: References: Message-ID: On Mon, 20 Mar 2006, Joachim Buechse wrote: > Hi Trent, > > What is your general feeling about moving code to Java? The last days I > have been reading quite a bit of the code and there are several things, > that might not work as expected. > > I'll give you two examples from is_device_locked: > > if LOCKDIR == /var/spool/locks the directory /var/spool/lock will not be > checked. > LOCKDIR is not checked for lockfiles with unexpected pefixes > > While these things have probably never been discovered in production, > they are still possibly incorrect implementations. If it was Java code, I > would write some unit tests producing the errors that could later be > corrected. > > PS: One could imagine to actually implement the whole lockfile handling > in Java using some native routines to get the values required (pid, > st_dev, st_rdev, ...). Hi Joachim I like the idea of moving more of the code into java but there are some things to consider. If you break this into multiple JNI calls, the performance will drop considerably during enumeration of ports. We are looking for 256 ports per dev type vs (16? in Sun's 2.0 and fewer types). Its hard to make assumptions. I've seen virtual ports start at /dev/foo100 for instance. It works out to over 7500 ports on Linux if you enable them all. We already trim that back by default. See Linux-all-ports in RXTXCommDriver.java. There are also native libraries that rxtx can link to. If you move too much into Java, linking to 'standard' libraries with distros will break. "configure --enable-liblock=yes" will not be doable. This is probably a favorable way with RedHat, Debian, Suse and others. Thats the right thing to do if there will be rpms, dpkg, .. For those reasons, I think it still make sense to keep it to a minimal ~3 calls to JNI code that we can use for speed and versatility. lock() isLocked(), unlock() perhaps. When I say speed, its more about avoiding crossing the JNI layer multiple times than java vs C performance. With versatility I think liblock is the right way for most but not all (embeded) linux distros. -- Trent Jarvi tjarvi at qbang.org From joachim at buechse.de Mon Mar 20 12:42:04 2006 From: joachim at buechse.de (Joachim Buechse) Date: Mon, 20 Mar 2006 20:42:04 +0100 Subject: [Rxtx] BUG: Lock file stays even if port opening fails In-Reply-To: References: Message-ID: <82C19FE7-DDCB-45B6-B2C9-7606B66F0124@buechse.de> Ok, what about providing a default implementation in Java? The RXTXCommDriver would call a (native) function useNativeLocking and if it returns true, call the native functions for lock() isLocked (), unlock(), else is would use the Java based default implementation. This could possibly be overriden by a property (again for debugging). Joachim On 20.03.2006, at 20:21, Trent Jarvi wrote: > On Mon, 20 Mar 2006, Joachim Buechse wrote: > >> Hi Trent, >> >> What is your general feeling about moving code to Java? The last >> days I have been reading quite a bit of the code and there are >> several things, that might not work as expected. >> >> I'll give you two examples from is_device_locked: >> >> if LOCKDIR == /var/spool/locks the directory /var/spool/lock will >> not be checked. >> LOCKDIR is not checked for lockfiles with unexpected pefixes >> >> While these things have probably never been discovered in >> production, they are still possibly incorrect implementations. If >> it was Java code, I would write some unit tests producing the >> errors that could later be corrected. >> >> PS: One could imagine to actually implement the whole lockfile >> handling in Java using some native routines to get the values >> required (pid, st_dev, st_rdev, ...). > > Hi Joachim > > I like the idea of moving more of the code into java but there are > some things to consider. > > If you break this into multiple JNI calls, the performance will > drop considerably during enumeration of ports. We are looking for > 256 ports per dev type vs (16? in Sun's 2.0 and fewer types). Its > hard to make assumptions. I've seen virtual ports start at /dev/ > foo100 for instance. > > It works out to over 7500 ports on Linux if you enable them all. > We already trim that back by default. See Linux-all-ports in > RXTXCommDriver.java. > > There are also native libraries that rxtx can link to. If you move > too much into Java, linking to 'standard' libraries with distros > will break. "configure --enable-liblock=yes" will not be doable. > This is probably a favorable way with RedHat, Debian, Suse and > others. Thats the right thing to do if there will be rpms, dpkg, .. > > For those reasons, I think it still make sense to keep it to a > minimal ~3 calls to JNI code that we can use for speed and > versatility. lock() isLocked(), unlock() perhaps. When I say > speed, its more about avoiding crossing the JNI layer multiple > times than java vs C performance. With versatility I think liblock > is the right way for most but not all (embeded) linux distros. > > -- > Trent Jarvi > tjarvi at qbang.org > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Mon Mar 20 12:44:47 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 20 Mar 2006 12:44:47 -0700 (MST) Subject: [Rxtx] BUG: Lock file stays even if port opening fails In-Reply-To: <82C19FE7-DDCB-45B6-B2C9-7606B66F0124@buechse.de> References: <82C19FE7-DDCB-45B6-B2C9-7606B66F0124@buechse.de> Message-ID: On Mon, 20 Mar 2006, Joachim Buechse wrote: > Ok, what about providing a default implementation in Java? > > The RXTXCommDriver would call a (native) function useNativeLocking and if > it returns true, call the native functions for lock() isLocked(), > unlock(), else is would use the Java based default implementation. This > could possibly be overriden by a property (again for debugging). > Hi Joachim That would be OK with me. -- Trent Jarvi tjarvi at qbang.org From dmarkman at mac.com Mon Mar 20 22:27:45 2006 From: dmarkman at mac.com (Dmitry Markman) Date: Tue, 21 Mar 2006 00:27:45 -0500 Subject: [Rxtx] binaries request Message-ID: <42702213-C222-4937-A585-7CFB17E47608@mac.com> Hi can somebody send me latest linux and windows binaries, please? or where I can find them (I didn't find them in the latest tareball) I gave up with my cygwin: something wrong I have no idea what java doesn't understand /cygwin/c syntax after I changed makefile it did java part but after that gcc 3.4.4 started to complain I set buffer length to 999 lines but I didn't get beginning of the story something wrong with my 1.4.2_09/include/jni.h gcc doesn't like it anyway I gave up thanks in advance Dmitry Markman -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060320/f8cbc57c/attachment-0016.html From tjarvi at qbang.org Mon Mar 20 22:36:48 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 20 Mar 2006 22:36:48 -0700 (MST) Subject: [Rxtx] binaries request In-Reply-To: <42702213-C222-4937-A585-7CFB17E47608@mac.com> References: <42702213-C222-4937-A585-7CFB17E47608@mac.com> Message-ID: On Tue, 21 Mar 2006, Dmitry Markman wrote: > Hi > can somebody send me latest linux and windows binaries, please? > > or where I can find them (I didn't find them in the latest tareball) > > I gave up with my cygwin: something wrong I have no idea what > java doesn't understand /cygwin/c syntax > after I changed makefile it did java part > but after that gcc 3.4.4 started to complain > I set buffer length to 999 lines but I didn't get beginning of the story > something wrong with my 1.4.2_09/include/jni.h gcc doesn't like it > anyway I gave up > > thanks in advance > Hi Dmitry The bins are here: ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7-bins-r2.zip Here are the files in the zip you want. Jar: rxtx-2.1-7-bins-r2/RXTXcomm.jar Windows: rxtx-2.1-7-bins-r2/Windows/i368-mingw32/rxtxSerial.dll Linux (x86) rxtx-2.1-7-bins-r2/Linux/i686-unknown-linux-gnu/librxtxSerial.so There are others in there including Parallel port support but those are the main ones for testing. -- Trent Jarvi tjarvi at qbang.org From dmarkman at mac.com Mon Mar 20 23:05:59 2006 From: dmarkman at mac.com (Dmitry Markman) Date: Tue, 21 Mar 2006 01:05:59 -0500 Subject: [Rxtx] binaries request In-Reply-To: References: <42702213-C222-4937-A585-7CFB17E47608@mac.com> Message-ID: thank you very much but windows's readme says: rxtxSerial.dll had to be recomopiled to link in missing native methods. should I ignore it? or what? thanks again also I understand that I should use mingw not cygwin I'll try to install mingw On Mar 21, 2006, at 12:36 AM, Trent Jarvi wrote: > On Tue, 21 Mar 2006, Dmitry Markman wrote: > >> Hi >> can somebody send me latest linux and windows binaries, please? >> >> or where I can find them (I didn't find them in the latest tareball) >> >> I gave up with my cygwin: something wrong I have no idea what >> java doesn't understand /cygwin/c syntax >> after I changed makefile it did java part >> but after that gcc 3.4.4 started to complain >> I set buffer length to 999 lines but I didn't get beginning of the >> story >> something wrong with my 1.4.2_09/include/jni.h gcc doesn't like it >> anyway I gave up >> >> thanks in advance >> > > Hi Dmitry > > The bins are here: > > ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7-bins-r2.zip > > Here are the files in the zip you want. > > Jar: > > rxtx-2.1-7-bins-r2/RXTXcomm.jar > > Windows: > > rxtx-2.1-7-bins-r2/Windows/i368-mingw32/rxtxSerial.dll > > Linux (x86) > > rxtx-2.1-7-bins-r2/Linux/i686-unknown-linux-gnu/librxtxSerial.so > > There are others in there including Parallel port support but those > are the main ones for testing. > > -- > Trent Jarvi > tjarvi at qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx Dmitry Markman From tjarvi at qbang.org Mon Mar 20 23:20:33 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 20 Mar 2006 23:20:33 -0700 (MST) Subject: [Rxtx] binaries request In-Reply-To: References: <42702213-C222-4937-A585-7CFB17E47608@mac.com> Message-ID: On Tue, 21 Mar 2006, Dmitry Markman wrote: > thank you very much > > but windows's readme says: > rxtxSerial.dll had to be recomopiled to link in missing native methods. > > should I ignore it? or what? > Hi Dmitry That dll should be OK. r2 is the recompile linked to the missing native method. The readme explains why it was recompiled; fuser.o was not linked into the dll in the first release. -- Trent Jarvi tjarvi at qbang.org From ariantristan at yahoo.com Mon Mar 20 23:55:24 2006 From: ariantristan at yahoo.com (Lambok Sianturi) Date: Mon, 20 Mar 2006 22:55:24 -0800 (PST) Subject: [Rxtx] jvm issue Message-ID: <20060321065524.94779.qmail@web50701.mail.yahoo.com> Hi All, This is my first time to join RxTx mailing list. I thank you all for allowing others to sign in in requests help. I use the latest RxTx lib in Fedora 3 with java version 1.4.2_09 b05. And I got this error: # # An unexpected error has been detected by HotSpot Virtual Machine: # # SIGSEGV (0xb) at pc=0x00bf27f3, pid=2633, tid=3086112448 # # Java VM: Java HotSpot(TM) Client VM (1.4.2_09-b05 mixed mode) # Problematic frame: # C [ld-linux.so.2+0xa7f3] # # An error report file with more information is saved as hs_err_pid2633.log # # If you would like to submit a bug report, please visit: # http://java.sun.com/webapps/bugreport/crash.jsp # ./run.sh: line 3: 2633 Aborted /usr/local/java/bin/java -Djava.library.path=/usr/local/java/jre/lib/ -Djsmsengine.debug=true -classpath jsmsengine.jar:smsgateway.jar:classes12.jar:RXTXcomm.jar:. com.api.sms.SMSServer What is the jvm depedency for the latest library? Can I use 1.4.2_09 b05? Thanks in advance. Arian --------------------------------- Yahoo! Mail Use Photomail to share photos without annoying attachments. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060320/83d58dd7/attachment-0016.html From f.frumento at ngi.it Tue Mar 21 00:21:47 2006 From: f.frumento at ngi.it (Fabio Frumento) Date: Tue, 21 Mar 2006 08:21:47 +0100 Subject: [Rxtx] Javadoc on the go Message-ID: <441FA98B.9050701@ngi.it> Hi Trent, sorry for the big delay but my job is running wild, i was out for some time but now i'm back and ready to continue the javadoc for Rxtx. Did you used the last javadoc patch i sent you ? let me know if i have to send it to you again or not. regards Fabio From lyon at docjava.com Tue Mar 21 00:51:18 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Tue, 21 Mar 2006 02:51:18 -0500 Subject: [Rxtx] lock files Message-ID: Hi All, You know, if the use of lock files were under Java control (rather than a build-time decision), it might enable a more unified binary distro. It might also facilitate quick prototyping of non-lock file approaches to resolving serial port contention issues (i.e., mac-like approaches vs. linux approaches, etc.). I realize that this is a radical overhaul of the lock file policy issue. Also, it may harm performance. On the other hand, our benchmarks on JNI overhead for modern processors indicate performance impact should be minimal. Perhaps it is more of an issue with the toybox systems. Suppose there were a class with a reasonable default...someone might write: SerialPortLockPolicy.setPolicy(SerialPortLockPolicy.UNIX_LOCK_FILE); SerialPortLockPolicy.setPolicy(SerialPortLockPolicy.NO_LOCK_CHECKING); SerialPortLockPolicy.setPolicy(SerialPortLockPolicy.MAC_STYLE); Thus, we could have a run-time reconfiguration of the serial port lock policy. A special NO_LOCK version of the binary would no longer be required. Any thoughts on this? Thanks! - Doug From joachim at buechse.de Tue Mar 21 03:09:09 2006 From: joachim at buechse.de (Joachim Buechse) Date: Tue, 21 Mar 2006 11:09:09 +0100 Subject: [Rxtx] lock files In-Reply-To: References: Message-ID: <8E12916A-1B9A-4FF2-B684-E2D1C794221B@buechse.de> This is pretty much what I thought about when I suggested, that the default behaviour could be overwritten with a property. I am very much in favor of this approach. In particular this allows much easier debugging for PC based java developers. I think big parts of the Java (and maybe some parts of the C code) could use a bit of a structural workover (unit tests, javadoc, synchronization, etc). Maybe there should be a CVS branch for this experimental version. I'd be happy to contribute a first workover for some of the Java code. Designing for testability and implementing a good bunch of unit tests has been a strategy that worked quite well in the Java projects I lead. And it ultimately allows more liberal change permission. Regards, Joachim On 21.03.2006, at 08:51, Dr. Douglas Lyon wrote: > Hi All, > You know, if the use of lock files were > under Java control (rather than a build-time decision), > it might enable a more unified binary distro. It might also > facilitate quick prototyping of non-lock file approaches > to resolving serial port contention issues (i.e., mac-like > approaches vs. linux approaches, etc.). > > I realize that this is a radical overhaul of the lock file policy > issue. Also, it may harm performance. On the other hand, > our benchmarks on JNI overhead for modern processors indicate > performance impact should be minimal. Perhaps it is more of > an issue with the toybox systems. > > Suppose there were a class with a reasonable default...someone > might write: > SerialPortLockPolicy.setPolicy(SerialPortLockPolicy.UNIX_LOCK_FILE); > SerialPortLockPolicy.setPolicy(SerialPortLockPolicy.NO_LOCK_CHECKING); > SerialPortLockPolicy.setPolicy(SerialPortLockPolicy.MAC_STYLE); > > Thus, we could have a run-time reconfiguration of the serial port lock > policy. A special NO_LOCK version of the binary would no longer > be required. > > Any thoughts on this? > > Thanks! > - Doug > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From joachim at buechse.de Tue Mar 21 06:23:08 2006 From: joachim at buechse.de (Joachim Buechse) Date: Tue, 21 Mar 2006 14:23:08 +0100 Subject: [Rxtx] PATCH: use of ioctl(fd, TIOCEXCL) instead of lockfiles Message-ID: <923AE774-EEA2-4911-92D8-32BB27802C8B@buechse.de> Here is the patch for the ioctl(fd, TIOCEXCL). I have verified this only for OSX 10.4.5, hence it is only defined for APPLE. However, it should work at least for Solaris as well. If a process has requested TIOEXCL further open calls by other user processes will fail. The patch also disables uucp style locking for APPLE. Obviously this is discussable. I think it is the way to go, as it eliminates creating the lock directory which doesnt exist on the standard installation and it eliminates messing with the system group definitions (adding users to group uucp). Regarding the possibility of root processes opening a device which is locked - I consider this a feature not a potential problem. It is highly unlikely, that somebody is crazy enough to run a JavaVM as root (unless he has no other means of getting a restricted IP port opened, ie doesnt understand ipfw). Anyway, even if the process runs as root, it fails when calling ioctl(fd, TIOCEXCL). It could however still open the port to listen for RING events. I.e. a fax server which needs to see incoming calls but otherwise doesnt want to block the port. So the only case where the proposed mechanism fails is, if an incorrectly implemented process running as root conflicts with a user process. I think this can be accepted. Regards, Joachim PS: If this patch is generally accepted, the installer and Mac doku should obviously be changed as well. Index: SerialImp.c =================================================================== RCS file: /usr/local/cvsroot/rxtx-devel/src/SerialImp.c,v retrieving revision 1.46.2.187 diff -u -r1.46.2.187 SerialImp.c --- SerialImp.c 29 Jan 2006 22:19:04 -0000 1.46.2.187 +++ SerialImp.c 21 Mar 2006 12:59:16 -0000 @@ -656,6 +656,25 @@ fd=OPEN (filename, O_RDWR | O_NOCTTY | O_NONBLOCK ); } while (fd < 0 && errno==EINTR); +#ifdef OPEN_EXCL + // Note that open() follows POSIX semantics: multiple open() calls to + // the same file will succeed unless the TIOCEXCL ioctl is issued. + // This will prevent additional opens except by root-owned processes. + // See tty(4) ("man 4 tty") and ioctl(2) ("man 2 ioctl") for details. + + if (fd >= 0 && (ioctl(fd, TIOCEXCL) == -1)) + { + sprintf( message, "open: exclusive access denied for % s\n", + filename ); + report( message ); + report_error( message ); + + close(fd); + goto fail; + } +#endif /* OPEN_EXCL */ + + if( configure_port( fd ) ) goto fail; (*env)->ReleaseStringUTFChars( env, jstr, filename ); sprintf( message, "open: fd returned is %i\n", fd ); Index: SerialImp.h =================================================================== RCS file: /usr/local/cvsroot/rxtx-devel/src/SerialImp.h,v retrieving revision 1.11.2.49 diff -u -r1.11.2.49 SerialImp.h --- SerialImp.h 5 Jul 2005 17:47:21 -0000 1.11.2.49 +++ SerialImp.h 21 Mar 2006 12:59:17 -0000 @@ -135,7 +135,8 @@ /*# define LOCKDIR "/var/spool/uucp"*/ # define LOCKDIR "/var/lock" # define LOCKFILEPREFIX "LK." -# define UUCP +/*# define UUCP*/ +# define OPEN_EXCL #endif /* __APPLE__ */ #if defined(__NetBSD__) # define DEVICEDIR "/dev/" From tjarvi at qbang.org Tue Mar 21 10:26:08 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 21 Mar 2006 10:26:08 -0700 (MST) Subject: [Rxtx] Javadoc on the go In-Reply-To: <441FA98B.9050701@ngi.it> References: <441FA98B.9050701@ngi.it> Message-ID: On Tue, 21 Mar 2006, Fabio Frumento wrote: > Hi Trent, > > sorry for the big delay but my job is running wild, i was out for some > time but now i'm back and ready to continue the javadoc for Rxtx. > > Did you used the last javadoc patch i sent you ? let me know if i have to > send it to you again or not. > > regards > > Fabio Hi Fabio The patch is in the rxtx mail-list archives. It will be going in soon. I did not see a time critical portion. I'll probably be going through the list since the last batch of patches this weekend and putting them into CVS. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Tue Mar 21 10:57:18 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 21 Mar 2006 10:57:18 -0700 (MST) Subject: [Rxtx] jvm issue In-Reply-To: <20060321065524.94779.qmail@web50701.mail.yahoo.com> References: <20060321065524.94779.qmail@web50701.mail.yahoo.com> Message-ID: On Mon, 20 Mar 2006, Lambok Sianturi wrote: > Hi All, > This is my first time to join RxTx mailing list. I thank you all for allowing others to sign in in requests help. > I use the latest RxTx lib in Fedora 3 with java version 1.4.2_09 b05. And I got this error: > > # > # An unexpected error has been detected by HotSpot Virtual Machine: > # > # SIGSEGV (0xb) at pc=0x00bf27f3, pid=2633, tid=3086112448 > # > # Java VM: Java HotSpot(TM) Client VM (1.4.2_09-b05 mixed mode) > # Problematic frame: > # C [ld-linux.so.2+0xa7f3] A native library loading error? What happens if you recompile rxtx on your system and install that? This sounds like an ABI problem? rxtx 2.1-7 was compiled with a gcc 2.96 toolchain as I recall. The hope is newer system will be backwards compatible. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Tue Mar 21 11:05:29 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 21 Mar 2006 11:05:29 -0700 (MST) Subject: [Rxtx] PATCH: use of ioctl(fd, TIOCEXCL) instead of lockfiles In-Reply-To: <923AE774-EEA2-4911-92D8-32BB27802C8B@buechse.de> References: <923AE774-EEA2-4911-92D8-32BB27802C8B@buechse.de> Message-ID: On Tue, 21 Mar 2006, Joachim Buechse wrote: > Here is the patch for the ioctl(fd, TIOCEXCL). I have verified this only > for OSX 10.4.5, hence it is only defined for APPLE. However, it should > work at least for Solaris as well. > > If a process has requested TIOEXCL further open calls by other user > processes will fail. > > The patch also disables uucp style locking for APPLE. Obviously this is > discussable. I think it is the way to go, as it eliminates creating the > lock directory which doesnt exist on the standard installation and it > eliminates messing with the system group definitions (adding users to > group uucp). > > Regarding the possibility of root processes opening a device which is > locked - I consider this a feature not a potential problem. It is highly > unlikely, that somebody is crazy enough to run a JavaVM as root (unless > he has no other means of getting a restricted IP port opened, ie doesnt > understand ipfw). Anyway, even if the process runs as root, it fails when > calling ioctl(fd, TIOCEXCL). It could however still open the port to > listen for RING events. I.e. a fax server which needs to see incoming > calls but otherwise doesnt want to block the port. So the only case where > the proposed mechanism fails is, if an incorrectly implemented process > running as root conflicts with a user process. I think this can be > accepted. > > Regards, > Joachim > > PS: If this patch is generally accepted, the installer and Mac doku > should obviously be changed as well. > > > Index: SerialImp.c > =================================================================== > RCS file: /usr/local/cvsroot/rxtx-devel/src/SerialImp.c,v > retrieving revision 1.46.2.187 > diff -u -r1.46.2.187 SerialImp.c > --- SerialImp.c 29 Jan 2006 22:19:04 -0000 1.46.2.187 > +++ SerialImp.c 21 Mar 2006 12:59:16 -0000 > @@ -656,6 +656,25 @@ > fd=OPEN (filename, O_RDWR | O_NOCTTY | O_NONBLOCK ); > } while (fd < 0 && errno==EINTR); > > +#ifdef OPEN_EXCL > + // Note that open() follows POSIX semantics: multiple open() > calls to > + // the same file will succeed unless the TIOCEXCL ioctl is > issued. > + // This will prevent additional opens except by root-owned > processes. > + // See tty(4) ("man 4 tty") and ioctl(2) ("man 2 ioctl") for > details. > + > + if (fd >= 0 && (ioctl(fd, TIOCEXCL) == -1)) > + { > + sprintf( message, "open: exclusive access denied for % > s\n", > + filename ); > + report( message ); > + report_error( message ); > + > + close(fd); > + goto fail; > + } > +#endif /* OPEN_EXCL */ > + > + > if( configure_port( fd ) ) goto fail; > (*env)->ReleaseStringUTFChars( env, jstr, filename ); > sprintf( message, "open: fd returned is %i\n", fd ); > Index: SerialImp.h > =================================================================== > RCS file: /usr/local/cvsroot/rxtx-devel/src/SerialImp.h,v > retrieving revision 1.11.2.49 > diff -u -r1.11.2.49 SerialImp.h > --- SerialImp.h 5 Jul 2005 17:47:21 -0000 1.11.2.49 > +++ SerialImp.h 21 Mar 2006 12:59:17 -0000 > @@ -135,7 +135,8 @@ > /*# define LOCKDIR "/var/spool/uucp"*/ > # define LOCKDIR "/var/lock" > # define LOCKFILEPREFIX "LK." > -# define UUCP > +/*# define UUCP*/ > +# define OPEN_EXCL > #endif /* __APPLE__ */ > #if defined(__NetBSD__) > # define DEVICEDIR "/dev/" > This looks like a good start. What do you think Dmitry? Perhaps all systems with TIOCEXCL defined should use that though. Even if they use lockfiles. It wont hurt anything. That would catch people hacking their own serial apps without checking lockfiles. Its a good idea to avoid C++ style comments in the C portions. Some older systems don't deal with them well. If it's just for Mac OS X, it isn't a big deal. I think it was the Irix compiler that was problematic? -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Tue Mar 21 11:22:05 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 21 Mar 2006 11:22:05 -0700 (MST) Subject: [Rxtx] lock files In-Reply-To: <8E12916A-1B9A-4FF2-B684-E2D1C794221B@buechse.de> References: <8E12916A-1B9A-4FF2-B684-E2D1C794221B@buechse.de> Message-ID: We can try it. Maybe the JNI is much improved. The nice thing about linking into liblock is distros then worry about lockfiles on their systems. This way, we have to deal with any changes that may show up. On Tue, 21 Mar 2006, Joachim Buechse wrote: > This is pretty much what I thought about when I suggested, that the > default behaviour could be overwritten with a property. I am very much in > favor of this approach. In particular this allows much easier debugging > for PC based java developers. > > I think big parts of the Java (and maybe some parts of the C code) could > use a bit of a structural workover (unit tests, javadoc, synchronization, > etc). Maybe there should be a CVS branch for this experimental version. > I'd be happy to contribute a first workover for some of the Java code. > Designing for testability and implementing a good bunch of unit tests has > been a strategy that worked quite well in the Java projects I lead. And > it ultimately allows more liberal change permission. > > Regards, > Joachim > > > On 21.03.2006, at 08:51, Dr. Douglas Lyon wrote: > >> Hi All, >> You know, if the use of lock files were >> under Java control (rather than a build-time decision), >> it might enable a more unified binary distro. It might also >> facilitate quick prototyping of non-lock file approaches >> to resolving serial port contention issues (i.e., mac-like >> approaches vs. linux approaches, etc.). >> >> I realize that this is a radical overhaul of the lock file policy >> issue. Also, it may harm performance. On the other hand, >> our benchmarks on JNI overhead for modern processors indicate >> performance impact should be minimal. Perhaps it is more of >> an issue with the toybox systems. >> >> Suppose there were a class with a reasonable default...someone >> might write: >> SerialPortLockPolicy.setPolicy(SerialPortLockPolicy.UNIX_LOCK_FILE); >> SerialPortLockPolicy.setPolicy(SerialPortLockPolicy.NO_LOCK_CHECKING); >> SerialPortLockPolicy.setPolicy(SerialPortLockPolicy.MAC_STYLE); >> >> Thus, we could have a run-time reconfiguration of the serial port lock >> policy. A special NO_LOCK version of the binary would no longer >> be required. >> >> Any thoughts on this? >> >> Thanks! >> - Doug >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From dmarkman at mac.com Tue Mar 21 16:05:17 2006 From: dmarkman at mac.com (Dmitry Markman) Date: Tue, 21 Mar 2006 18:05:17 -0500 Subject: [Rxtx] PATCH: use of ioctl(fd, TIOCEXCL) instead of lockfiles In-Reply-To: References: <923AE774-EEA2-4911-92D8-32BB27802C8B@buechse.de> Message-ID: <512AC70C-BB86-48F2-A83C-023F35C23BAB@mac.com> I think it's cool, but I'd like to have that property implementation when user can choose between locking mechanism about comments: it's easy to change comments to the C style or we can use extensions of the file to cpp so c++ compiler will be used On Mar 21, 2006, at 1:05 PM, Trent Jarvi wrote: > This looks like a good start. What do you think Dmitry? Perhaps > all systems with TIOCEXCL defined should use that though. Even if > they use lockfiles. It wont hurt anything. That would catch > people hacking their own serial apps without checking lockfiles. > > Its a good idea to avoid C++ style comments in the C portions. > Some older systems don't deal with them well. If it's just for Mac > OS X, it isn't a big deal. I think it was the Irix compiler that > was problematic? Dmitry Markman From dmarkman at mac.com Tue Mar 21 16:13:00 2006 From: dmarkman at mac.com (Dmitry Markman) Date: Tue, 21 Mar 2006 18:13:00 -0500 Subject: [Rxtx] PATCH: use of ioctl(fd, TIOCEXCL) instead of lockfiles In-Reply-To: References: <923AE774-EEA2-4911-92D8-32BB27802C8B@buechse.de> Message-ID: I'd like to add that creating locking folder isn't a big deal we never had a problem related to the lock folders, because we always used installer on mac os x from other hand I'm not very much familiar with iotcl locking approach and I'm not sure it's more efficient Joachim wrote "I think it is the way to go, as it eliminates creating the lock directory which doesnt exist on the standard installation and it eliminates messing with the system group definitions (adding users to group uucp)." but I really didn't have any problem with that 1. doesn't exist on the standard installation there are many-many things that don't exist in the standard installation so I don't think that argument is strong enough 2. messing with the system group definitions I don't think we're messing with the group definition mac os x provides very clear way to set up group's members and together with Greg Guerin AuthKit there is no problem to set those definitions so I don't think that argument is strong either but from other hand using iotcl is more promising and is more elegant On Mar 21, 2006, at 1:05 PM, Trent Jarvi wrote: > > This looks like a good start. What do you think Dmitry? Perhaps > all systems with TIOCEXCL defined should use that though. Even if > they use lockfiles. It wont hurt anything. That would catch > people hacking their own serial apps without checking lockfiles. Dmitry Markman From joachim at buechse.de Wed Mar 22 04:46:45 2006 From: joachim at buechse.de (Joachim Buechse) Date: Wed, 22 Mar 2006 12:46:45 +0100 Subject: [Rxtx] PATCH: use of ioctl(fd, TIOCEXCL) instead of lockfiles In-Reply-To: References: <923AE774-EEA2-4911-92D8-32BB27802C8B@buechse.de> Message-ID: Sorry, I was not very clear with my arguments, so I will try again;-) Please, don't take this as an attack against work that has been done. I think the contributions that have been made in the past were made in a good spirit. But I really believe, that the current solution for OSX has many shortcomings and should be changed as soon as possible. lock files --- The /var/lock folder does not exist on the standard OSX installation, however the standard installation includes several applications that use serial ports (i.e. the FAX capability). This indicates, that the lock folder approach will not work well with system components. Applications for OSX will generally try to live in harmony with system components (except for HP print drivers of course). I think RXTX should follow this approach as well. uucp group --- Accessing serial ports is not an admin privileged operation on OSX. Any user (world) has read/write privileges on /dev/tty*. So the system default is to not enforce any group membership to access these ports. The group uucp however is a system group on all unix systems I know. It exists for certain system processes. A non admin user should in general not be a member of this group. Quite arguably no user should ever be a member of this group. Installer --- My general opinion is, that - no Installer should touch user or group data without warning - no Application Installer should touch groups which are not specific to the very application installed - no Installer should ever add regular users to a system group The current installer injects the installing user in the group uucp without warning about this change and without giving the option to "opt out" of this change. This is a potential security risk (but not currently a real one, as OSX contains no folders belonging to group uucp). The current installer does not work for multi user systems. It puts the installing user in the uucp group. However the installing user is not necessarily the user that will use the application. Putting all users that may use a serial port application in the system group uucp seems like a very invasive approach to me. Besides that, newly created users will not automatically be in the group and hence, serial applications will "break" for new users without obvious reasons. Avoiding the lock files will allow self contained applications (i.e. drag&drop installation). In my eyes this is largely preferable over an installer that requests admin privileges. Adding up all these points indicates very strongly, that the lock-file implementation is not the way to go on OSX. Regards, Joachim On 22.03.2006, at 00:13, Dmitry Markman wrote: > I'd like to add that > > creating locking folder isn't a big deal > we never had a problem related to the lock folders, because we > always used installer on mac os x > from other hand I'm not very much familiar with iotcl locking > approach and I'm not sure it's more efficient > > Joachim wrote "I think it is the way to go, as it eliminates > creating the lock directory which doesnt exist on the standard > installation and it eliminates messing with the system group > definitions (adding users to group uucp)." but I really didn't have > any problem with that > > 1. doesn't exist on the standard installation > there are many-many things that don't exist in the standard > installation so I don't think that argument is strong enough > 2. messing with the system group definitions > I don't think we're messing with the group definition > mac os x provides very clear way to set up group's members and > together with Greg Guerin AuthKit there is no problem to set those > definitions > so I don't think that argument is strong either > but from other hand using iotcl is more promising and is more elegant > > > > On Mar 21, 2006, at 1:05 PM, Trent Jarvi wrote: > >> >> This looks like a good start. What do you think Dmitry? Perhaps >> all systems with TIOCEXCL defined should use that though. Even if >> they use lockfiles. It wont hurt anything. That would catch >> people hacking their own serial apps without checking lockfiles. > > Dmitry Markman > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From dmarkman at mac.com Wed Mar 22 05:27:13 2006 From: dmarkman at mac.com (Dmitry Markman) Date: Wed, 22 Mar 2006 07:27:13 -0500 Subject: [Rxtx] PATCH: use of ioctl(fd, TIOCEXCL) instead of lockfiles In-Reply-To: References: <923AE774-EEA2-4911-92D8-32BB27802C8B@buechse.de> Message-ID: <83440CF3-DCD8-41C1-B941-F227232C27E3@mac.com> thanks for the very good explanation I didn't think that you were attacking any thing, so don't worry I just had feeling, that there were more aesthetic reasons for going to ioctl then real necessity now you explained everything quite well (BTW, asfar as I remember installer asks admin password so it wasn't quiet, but it really doesn't matter now) thanks On Mar 22, 2006, at 6:46 AM, Joachim Buechse wrote: > Sorry, I was not very clear with my arguments, so I will try again;-) > > Please, don't take this as an attack against work that has been > done. I think the contributions that have been made in the past > were made in a good spirit. But I really believe, that the current > solution for OSX has many shortcomings and should be changed as > soon as possible. > > lock files > --- > The /var/lock folder does not exist on the standard OSX > installation, however the standard installation includes several > applications that use serial ports (i.e. the FAX capability). This > indicates, that the lock folder approach will not work well with > system components. Applications for OSX will generally try to live > in harmony with system components (except for HP print drivers of > course). I think RXTX should follow this approach as well. > > uucp group > --- > Accessing serial ports is not an admin privileged operation on OSX. > Any user (world) has read/write privileges on /dev/tty*. So the > system default is to not enforce any group membership to access > these ports. The group uucp however is a system group on all unix > systems I know. It exists for certain system processes. A non admin > user should in general not be a member of this group. Quite > arguably no user should ever be a member of this group. > > Installer > --- > My general opinion is, that > - no Installer should touch user or group data without warning > - no Application Installer should touch groups which are not > specific to the very application installed > - no Installer should ever add regular users to a system group > > The current installer injects the installing user in the group uucp > without warning about this change and without giving the option to > "opt out" of this change. This is a potential security risk (but > not currently a real one, as OSX contains no folders belonging to > group uucp). > > The current installer does not work for multi user systems. It puts > the installing user in the uucp group. However the installing user > is not necessarily the user that will use the application. Putting > all users that may use a serial port application in the system > group uucp seems like a very invasive approach to me. Besides that, > newly created users will not automatically be in the group and > hence, serial applications will "break" for new users without > obvious reasons. > > > Avoiding the lock files will allow self contained applications > (i.e. drag&drop installation). In my eyes this is largely > preferable over an installer that requests admin privileges. Adding > up all these points indicates very strongly, that the lock-file > implementation is not the way to go on OSX. > > Regards, > Joachim > > > On 22.03.2006, at 00:13, Dmitry Markman wrote: > >> I'd like to add that >> >> creating locking folder isn't a big deal >> we never had a problem related to the lock folders, because we >> always used installer on mac os x >> from other hand I'm not very much familiar with iotcl locking >> approach and I'm not sure it's more efficient >> >> Joachim wrote "I think it is the way to go, as it eliminates >> creating the lock directory which doesnt exist on the standard >> installation and it eliminates messing with the system group >> definitions (adding users to group uucp)." but I really didn't >> have any problem with that >> >> 1. doesn't exist on the standard installation >> there are many-many things that don't exist in the standard >> installation so I don't think that argument is strong enough >> 2. messing with the system group definitions >> I don't think we're messing with the group definition >> mac os x provides very clear way to set up group's members and >> together with Greg Guerin AuthKit there is no problem to set those >> definitions >> so I don't think that argument is strong either >> but from other hand using iotcl is more promising and is more elegant >> >> >> >> On Mar 21, 2006, at 1:05 PM, Trent Jarvi wrote: >> >>> >>> This looks like a good start. What do you think Dmitry? Perhaps >>> all systems with TIOCEXCL defined should use that though. Even >>> if they use lockfiles. It wont hurt anything. That would catch >>> people hacking their own serial apps without checking lockfiles. >> >> Dmitry Markman >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx Dmitry Markman From lyon at docjava.com Wed Mar 22 06:12:18 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Wed, 22 Mar 2006 08:12:18 -0500 Subject: [Rxtx] sole of a new design pattern Message-ID: Hi All, I have been thinking about how we design the serial port software. I think we need a new design pattern. For lack of a better term, I shall call it: The Parametric Singleton Design Pattern By Douglas A. Lyon ABSTRACT The goal of the singleton design pattern is to make sure that there is one, and only one, instance of a given class. The goal of the parametric singleton design pattern is to make sure that there is one, and only one, instance of a given class with the given parametric values. We parametric singleton design pattern combines the singleton design pattern with a parameter that enables unique creation of instances of a class. These instances are cached. When a user asks for an instance with these parameters, the cache is checked. If the instance is in the cache, the instance is returned, otherwise it is created, added to the cache and then returned. We apply our parametric singleton design pattern to the retrieval of RMI registries bound to a given port. The goal of our system is to make sure that no two RMI registries are listening to the same socket and to make use of the RMI registries after they have been created. RMI registries are used in distributed computation. Introduction The singleton design pattern is meant to ensure that on a single instance of a class exists. It is also meant to provide a global point of access to it. The intent of the parametric singleton design pattern is to ensure that a class has only one instance for a given set of parameter values. It also provides a global point of access to it. Motivation A system cannot tolerate multiple instances of some classes with identical parameters. For example, you cannot have two instances making use of the same serial port, at the same time. You cannot have two instances that are trying to listen to the same socket connection. You cannot have two instances writing to the same file structure at the same time. As the operating system is often thought of as the arbiter of consumed resources (i.e., tape drives, serial ports, etc.) we frequently leave it to an operating system implementation to resolve these contention issues. Even for similar resources (like serial ports) there are few standards for handling contention. For example, serial ports on Linux are locked using a "/var/lock" file. POSIX, on the other hand, uses ioctl mechanisms to prevent contention. A better solution is to make a class that is responsible for keeping track of the instances created from the class. The class is declared final, so that it cannot be subclassed. The class also has a private constructor, so that other classes cannot instance it. The new design pattern is called the parametric singleton design pattern and it provides a way to access and create instances with given parameters. Applicability Use the Parametric Singleton Design Pattern when: 1. There must be exactly one instance of a class with the given parameters. 2. The instances must be accessible to clients from a well-known access point. Structure Insert UML diagram here. Participants The Parametric Singleton Clients that need instances 1. The Parametric Singleton defines an instance upon request from a client, if, and only if, the instance does not already exist. 2. The Parametric Singleton returns the instance to the client. 3. The Parametric Singleton is responsible for creating unique instances from given parameters. Collaborations Clients obtain a reference to a Parametric Singleton instance only through the parametric singleton design pattern. If the instance is left in an improper state (e.g., the serial port was left open) it is NOT the role of the Parametric Singleton Design Pattern to close the IO port. Nor is it the role of the Parametric Singleton Design Pattern to open the port. That role is delegate to some other part of the system. Further, it is not the role of the Parametric Singleton Design Pattern to check out resources. That is, multiple threads can have multiple references to the same resource at the same time. MUTEX locking is delegated to some other part of the system. Consequences The Parametric Singleton Design Pattern has several benefits: 1. Controlled access to parametrically defined instances. Since the Parametric Singleton class encapsulates its instances, there is control over how and when clients access it. 2. Reduced name space. The Parametric Singleton pattern avoids global variables that store instances created from the same parameter. Implementation Here are implementation issues to consider when using the Parametric Singleton pattern: 1. Unique mapping of parameters. The Parametric Singleton pattern requires that there be a mean to isomorphically map the parameter space into the instance space and back again. 2. Ensure unique instances. The Parametric Singleton pattern makes unique instances from parameters, and it does so only once. 3. Cache instances for fast retrieval. The Parametric Singleton pattern must be able to look up instances, given some set of parameters, and do so from some data structure. That is, there must be enough space to hold references to all the instances the program will need. Also, a mechanism is needed to look up and retrieve the instances quickly enough to satisfy the clients. Sample Code public final class ParametricSingletonRmiRegistry { private static Hashtable registry = new Hashtable(100); // use singleton pattern and??????????????????????????????????????????????? // prevent instantiation of RmiRegistryUtils.?????????????????????????????? private ParametricSingletonRmiRegistry() { } // the only instance of the Registry held by the RmiRegistryUtils?????????? public static void listNames(Integer port) { if (!isInCacheAndRunning(port)) return; Registry r = (Registry) registry.get(port); System.out.println("registry on port: " + port); System.out.println("registry: " + r); System.out.println("names: "); try { print(r.list()); } catch (RemoteException e) { In.message(e); } System.out.println("------------------------"); } /**???????????????????????????????????????????????????????????????????????? * Checks whether a Registry has been started on this host????????????????? * in the specified port.?????????????????????????????????????????????????? * If not, it tries to start one.?????????????????????????????????????????? * when it fails to start a Registry, it exits the program????????????????? * with exit code 1.??????????????????????????????????????????????????????? */ public static void restart(int port) { if (isInCacheAndRunning(port)) return; try { startRegistry(port); } catch (RemoteException e) { In.message(e); } } /**???????????????????????????????????????????????????????????????????????? * @param port????????????????????????????????????????????????????????????? * @return true if registry is in cache and running???????????????????????? */ private static boolean isInCacheAndRunning(Integer port) { if (!isRegistryRunning(port.intValue())) return false; if (!isRegistryInCache(port.intValue())) return false; return true; } /**???????????????????????????????????????????????????????????????????????? * @param port????????????????????????????????????????????????????????????? * @return true if we are able to locate a local registry on port.??????????????????????????????????????????????????????????????????????????? */ private static boolean isRegistryRunning(int port) { try { Registry r = LocateRegistry.getRegistry(port); if (r != null) return true; } catch (RemoteException e) { return false; } return false; } /**???????????????????????????????????????????????????????????????????????? * @param port????????????????????????????????????????????????????????????? * @return return true if registry is in cache????????????????????????????? */ private static boolean isRegistryInCache(int port) { if (registry.get(new Integer(port)) == null) return false; return true; } /**???????????????????????????????????????????????????????????????????????? * Restart the registry, if needed.???????????????????????????????????????? * Return the only instance of the registry for consistent global?????????? * using by making use of the Singleton Design Pattern????????????????????? *????????????????????????????????????????????????????????????????????????? * @return the internally held registry instance.?????????????????????????? */ public static Registry getRegistry(Integer port) { restart(port); return (Registry) registry.get(port); } private static void startRegistry(Integer port) throws RemoteException { Registry r; try { r = LocateRegistry.createRegistry(port.intValue()); registry.put(port, r); //r = new sun.rmi.registry.RegistryImpl???????????????????????????? /// (port.intValue());?????????????????????????????????????? // registry.put(port, r);?????????????????????????????????????????? } catch (Exception e) { //e.printStackTrace();????????????????????????????????????????????? r = LocateRegistry.getRegistry(port.intValue()); registry.put(port, r); } } public static void main(String args[]) throws RemoteException { //restart(port);??????????????????????????????????????????????????????? restart(5001); restart(5002); restart(5002); Registry r = LocateRegistry.getRegistry(5002); System.out.println("registry="+r); } } I would very much like to get your feedback on this new design pattern idea. Thank you for your time. Regards, - Doug From david.garnier at trusted-logic.com Wed Mar 22 07:36:10 2006 From: david.garnier at trusted-logic.com (David Garnier) Date: Wed, 22 Mar 2006 15:36:10 +0100 Subject: [Rxtx] sole of a new design pattern In-Reply-To: References: Message-ID: <442160DA.80107@trusted-logic.com> Hello, > The Parametric Singleton Design Pattern The Singleton is the most abused design pattern ever. Good use-cases for this pattern are extremely rare and mostly confined to problems related to hardware resources, like serial ports. > Applicability > > Use the Parametric Singleton Design Pattern when: > 1. There must be exactly one instance of a class with the given > parameters. OK. As I said above, this case this actually very unusual. The Singleton pattern is mostly used when : > 2. The instances must be accessible to clients from a well-known > access point. Using the singleton pattern in this case is just convenient for the programmer. Problems arises pretty quickly, especially if you attempt to unit-test your classes. 1) If your singleton is stateful, or hold on to stateful objects, it means that two different unit tests are not actually independent. Instead of starting with a brand new environment, the result of a test may be affected by the result of a previous test. This problem also arise when with your class relies on a database. In both cases, the solution is to reset your "unique" resource (Singleton or database) at the beginning of the test, which is a pain. Also, while most projects connect to a single database, projects that allow the use of Singletons usually contain several of thems, and new ones may cropped up unnoticed. You quickly end up with test cases that only pass in a certain order, which is a royal pain. 2) You cannot mockup a singleton. Once everyone calls the SomeSingleton class statically, you can't replace your class by SomeSingletonMockup. Furthermore, even for hardware services, the Singleton pattern does not really prevent concurrent accesses. If you start the same program in two different JVMs, unless they somehow shared the state of their "Singletons" (through lock files for example), the Singleton pattern will not prevent concurrent access. Our application uses RXTX, and we routinely encounter cases where another (native) application has already locked the port. Since we cannot modify the native application to recognize lock files, OS-level control is irreplaceable. > > Consequences > The Parametric Singleton Design Pattern has several benefits: > > 1. Controlled access to parametrically defined instances. Since > the Parametric Singleton class encapsulates its instances, there is > control over how and when clients access it. Not really. Once you've returned the instance to a client, you've lost control over it. The client can to whatever it wants with it. You cannot "recall" the instance or claim it back. > 2. Reduced name space. The Parametric Singleton pattern avoids > global variables that store instances created from the same parameter. Sure, but you don't have to rely on a Singleton for that. Just create a single Factory. > I would very much like to get your feedback on this new design > pattern idea. Well, it's nothing new. Some may say that it is the point of design patterns: formalizes the designs that occur again and again. However, this design is simply a combination of the Singleton and Factory patterns. I did use it in the past, but now I've been exposed to the shortcomings of the Singleton pattern, so I limit myself to Factories. Regards, David From sean_montgomery at baseview.com Wed Mar 22 08:35:28 2006 From: sean_montgomery at baseview.com (Sean Montgomery) Date: Wed, 22 Mar 2006 10:35:28 -0500 Subject: [Rxtx] sole of a new design pattern In-Reply-To: <442160DA.80107@trusted-logic.com> References: <442160DA.80107@trusted-logic.com> Message-ID: <05769CA7-A51B-4CF0-BAA0-E02DD905F5A4@baseview.com> On Mar 22, 2006, at 9:36 AM, David Garnier wrote: > Furthermore, even for hardware services, the Singleton pattern does > not really prevent concurrent > accesses. If you start the same program in two different JVMs, > unless they somehow shared the state > of their "Singletons" (through lock files for example), the > Singleton pattern will not prevent > concurrent access. > Multiple class loaders in a single JVM can be tricky, too. Then there's synchronization, lazy initialization and serialization of singletons to contend with. Bloch's Effective Java covers these, and here's a few articles: http://www.javaworld.com/javaworld/jw-04-2003/jw-0425-designpatterns- p3.html http://java.sun.com/developer/technicalArticles/Programming/singletons/ Just FYI :-) From lyon at docjava.com Wed Mar 22 08:50:48 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Wed, 22 Mar 2006 10:50:48 -0500 Subject: [Rxtx] sole of a new design pattern In-Reply-To: <442160DA.80107@trusted-logic.com> References: <442160DA.80107@trusted-logic.com> Message-ID: Hi All, First, I would like to thank David for his prompt and thoughtful remarks. I had no idea people that feel strongly about a design patterns! Wow! Feedback (particularly critical feedback) is greatly appreciated. Starting at the end, first: >I did use it in >the past, but now I've been exposed to the shortcomings of the >Singleton pattern, so I limit myself to Factories. David, if I understood your comments correctly, you suggested that Factories can be used in leu of the Singleton Design Pattern, or even the Parametric Singleton Design Pattern. As I see in [Gof]: Factory Method: Intent "Define an interface for creating an object, but let subclasses decide which class to instantiate. Factory Method lets a class defer instantiation to subclasses." The Singleton Design Pattern is a concrete class, which is rather different, right? Also, subclasses are not permitted with Singleton, as they are final. Naturally, I could use an abstract factory as a parent for a singleton. I could even design a facade that could be implemented with the singleton....but that is not the intention of the design. Unless you want a mock-up, as discussed, below: More below: >Hello, > >> The Parametric Singleton Design Pattern > >The Singleton is the most abused design pattern ever. Good use-cases >for this pattern are extremely >rare and mostly confined to problems related to hardware resources, >like serial ports. > > >> Applicability >> >> Use the Parametric Singleton Design Pattern when: >> 1. There must be exactly one instance of a class with the given >> parameters. >OK. As I said above, this case this actually very unusual. The >Singleton pattern is mostly used when : >> 2. The instances must be accessible to clients from a well-known >> access point. > >Using the singleton pattern in this case is just convenient for the >programmer. Problems arises >pretty quickly, especially if you attempt to unit-test your classes. > >1) If your singleton is stateful, or hold on to stateful objects, it >means that two different unit >tests are not actually independent. Instead of starting with a brand >new environment, the result of >a test may be affected by the result of a previous test. This >problem also arise when with your >class relies on a database. In both cases, the solution is to reset >your "unique" resource >(Singleton or database) at the beginning of the test, which is a >pain. Also, while most projects >connect to a single database, projects that allow the use of >Singletons usually contain several of >thems, and new ones may cropped up unnoticed. You quickly end up >with test cases that only pass in a >certain order, which is a royal pain. There are basic problems with communicating finite state machines that include reachability and deadlock analysis. These are addressed with petri net analysis and are beyond the scope of the design pattern. As you quite rightly pointed out; the parametric singleton pattern (or the singleton pattern, for that matter) enable multiple threads to gain access to the same instance. The only way that I can see to block others from gaining access to the reference is the synchronize keyword. This is putting a spin-lock (or MUTEX) on the reference. The question of how to unit-test a design pattern like the parametric singleton remains open. Perhaps this is a deficiency. > >2) You cannot mockup a singleton. Once everyone calls the >SomeSingleton class statically, you can't >replace your class by SomeSingletonMockup. Acutally, I am not sure that this is true. If the Singleton implements a Facade interface, it should be possible to make the replacement. Right? > >Furthermore, even for hardware services, the Singleton pattern does >not really prevent concurrent >accesses. If you start the same program in two different JVMs, >unless they somehow shared the state >of their "Singletons" (through lock files for example), the >Singleton pattern will not prevent >concurrent access. Good Point!! You have sharp eyes! The singleton design pattern should/could take responsibility for this. In fact, you may notice that my code does have an implementation (LocateRegistry) that can work across JVM's. The LocateRegistry will even work across the Internet! LocateRegistry takes both a host name and a Port (lock files just don't do this). I did not think to implement this beyond the local machine, but, in its present form, it will work across different processes. > >Our application uses RXTX, and we routinely encounter cases where >another (native) application has >already locked the port. Since we cannot modify the native >application to recognize lock files, >OS-level control is irreplaceable. The singleton design pattern is not meant to replace OS-level control, but to centralize the Java programmers access to it. If lock files, for example, are used for serial ports, the Singleton Design Pattern should be able to work with them. > > >> >> Consequences >> The Parametric Singleton Design Pattern has several benefits: >> > > 1. Controlled access to parametrically defined instances. Since >> the Parametric Singleton class encapsulates its instances, there is >> control over how and when clients access it. > >Not really. Once you've returned the instance to a client, you've >lost control over it. The client >can to whatever it wants with it. You cannot "recall" the instance >or claim it back. Good point, this should read: > 1. Controll when parametrically defined instances are created. Since > > the Parametric Singleton class encapsulates its instances, there is > > control over how and when they are instanced. > >> 2. Reduced name space. The Parametric Singleton pattern avoids >> global variables that store instances created from the same parameter. > >Sure, but you don't have to rely on a Singleton for that. Just >create a single Factory. > > Thank you for your thoughtful and prompt response! Regards, - Doug From dmarkman at mac.com Wed Mar 22 21:21:55 2006 From: dmarkman at mac.com (Dmitry Markman) Date: Wed, 22 Mar 2006 23:21:55 -0500 Subject: [Rxtx] sole of a new design pattern In-Reply-To: <442160DA.80107@trusted-logic.com> References: <442160DA.80107@trusted-logic.com> Message-ID: I don't think I get it On Mar 22, 2006, at 9:36 AM, David Garnier wrote: > Using the singleton pattern in this case is just convenient for the > programmer. Problems arises > pretty quickly, especially if you attempt to unit-test your classes. so you're saying that something isn't so good because you can not test it in the convenient way? if that's true, I'm totally disagree change your test, debug whatever, but if software is efficient at runtime, works fine and only problem is some unit test (which is some kind of framework for testing) then dump that unit test , dump that unit framework and make something appropriate to the software you're testing so if Douglas want to use singletons, what's the problem? and what do you mean by abusing of singleton usage? of course singleton doesn't prevent concurrent access to the resource across the processes unless you're using some OS facility to prevent it, besides singleton as it was introduced is relevant only and only inside of the same process otherwise it's not singleton it's something else (let's say network singleton: so you have remote invocation facility and some factory method that return object created by that facility) I don't have any problem with using any kind of singletons. Parametric Singleton idea (if I understand it right) could be easily implemented in the following way: use a map populate map with instances of some class and key is your parameter (you can use lazy population too) if somebody ask the key check the value if it's null so resource is taken if somebody returns the resource put it back to the map public synchronized static Object getSomeResource(Object parameter); public synchronized static void returnResource(Object parameter); getSomeResource (inside of the same process) could return null in 2 cases 1. if somebody (from other thread for example) already took that resource 2. if OS API said that resource corresponded to that parameter (serial port with parameter = 1 (port #)) is locked and unavailable; I'm not sure that in case of serial ports we even need those Parametric Singletons (unless lock checking is a very expensive operation) just ask the OS about availability of that resource and if it's available give it away and then OS will lock it and therefore in next time somebody ask it just answer that resource is locked and return null for example system has 2 serial ports available so I ask getResource("tty"); or I ask getResource("Bluetooth-Modem"); and if OS is ok you can give tty or Bluetooth-Modem or both no need for any additional pattern I think back to the problem mac os x doesn't recognize locking via files, so it handles locking via some API an instance of the singleton in each process should recognize that resource is locked (by using that API) that's all we don't have to make things more complicate then they are just because there is some nice design pattern or nice unit test framework or whatever keep things simple, make them work fast, don't introduce middle layers unless you have really good reason to do so of course I could be entirely wrong, so sorry about that in advance thanks Dmitry Markman From tjarvi at qbang.org Wed Mar 22 22:31:41 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 22 Mar 2006 22:31:41 -0700 (MST) Subject: [Rxtx] sole of a new design pattern In-Reply-To: References: Message-ID: Hi Doug Interesting reading. So far I'm just reading and thinking. I have one question so far. " Clients obtain a reference to a Parametric Singleton instance only through the parametric singleton design pattern. If the instance is left in an improper state (e.g., the serial port was left open) it is NOT the role of the Parametric Singleton Design Pattern to close the IO port. Nor is it the role of the Parametric Singleton Design Pattern to open the port. That role is delegate to some other part of the system. " So when the clients obtain a reference to the singleton, can they assume the port is there? IE, would it be the singletons role to handle things like USB dongles being removed with event hints comming from the underlying OS. Hardware abstraction layer/HAL on Linux is an example of underlying OS events. I assume that role too is delegated to other parts of the system? -- Trent Jarvi tjarvi at qbang.org From lyon at docjava.com Thu Mar 23 08:10:33 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Thu, 23 Mar 2006 10:10:33 -0500 Subject: [Rxtx] Classes don't need goals, they need roles! In-Reply-To: References: Message-ID: Hi Trent, Yes, I think that the role of the Parametric Singleton Pattern is not to open or close serial ports, nor is it to perform error checking. On the other hand, if you were to combine the role of the Parametric Singleton Pattern with another role (like that of error checking) it might not be amiss. However, I generally caution programmers against adding multiple roles to classes, as this leads to monolithic designs. Thus a different class (NativeLibDetect) could have the role of determining if the native library can be loaded. Another class (SerialPortBean) can have the role of serializing the default state of the serial port, so that it can be recovered, from user preferences, at a later time. The SerialPortDetect could have the role of determining if the serial port is removed (i.e., a USB port was unplugged). My guess is that each class should have a different role in the system, in order to ease maintenance and testing...but I could be wrong about that. Thanks! - Doug >Hi Doug > >Interesting reading. So far I'm just reading and thinking. I have >one question so far. > >" > Clients obtain a reference to a Parametric Singleton instance only >through the parametric singleton design pattern. If the instance is >left in an improper state (e.g., the serial port was left open) it is >NOT the role of the Parametric Singleton Design Pattern to close the >IO port. Nor is it the role of the Parametric Singleton Design Pattern >to >open the port. That role is delegate to some other part of the system. >" > >So when the clients obtain a reference to the singleton, can they >assume the port is there? IE, would it be the singletons role to >handle things like USB dongles being removed with event hints >comming from the underlying OS. Hardware abstraction layer/HAL on >Linux is an example of underlying OS events. > >I assume that role too is delegated to other parts of the system? > >-- >Trent Jarvi >tjarvi at qbang.org >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From maximulo at yahoo.com Fri Mar 24 01:22:38 2006 From: maximulo at yahoo.com (Maximulo Majir) Date: Fri, 24 Mar 2006 00:22:38 -0800 (PST) Subject: [Rxtx] JavaPOS Message-ID: <20060324082238.66371.qmail@web38214.mail.mud.yahoo.com> Hi all! Hello Trent! From what i understand, RXTX or JavaComm APIs were not created solely for JavaPOS. In JavaPOS, we have the virtual method claim() which is separate from open(), but in our RXTX API, claiming is done every call to open(), we cant open the port if its claimed by another application. Would it be alright to suggest or ask to create a new method called claim(..)? Is there such thing as forceclaim() in RXTX? this could be the same as portownership transfer or its equivalent. ForceClaim is in JSR80. Do you have some samples using RXTX as the lower layer for the Device Service Objects in JavaPOS? I have tried it, i just want to compare. Thank you all! maxim __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060324/496adba2/attachment-0016.html From tjarvi at qbang.org Fri Mar 24 11:28:19 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 24 Mar 2006 11:28:19 -0700 (MST) Subject: [Rxtx] Re: RXTX 2.1 Solaris Problems In-Reply-To: <3691.1143210578@www045.gmx.net> References: <3691.1143210578@www045.gmx.net> Message-ID: On Fri, 24 Mar 2006, Andreas Guenther wrote: > Hi all, > > the solaris problem was not the lock file only. > > Ok, I had to create the directory /var/spool/locks myself. > /var/spool/uucp exists. > > But rxtx didn't find any port. > > I compiled the source with my own debug-informations > and I tried to isolate the problem. > > The problem is the testRead-call in SerialImp.c > > JNIEXPORT jboolean JNICALL RXTXCommDriver(testRead)( > > ... > if ( READ( fd, &c, 1 ) < 0 ) > { > if ( errno != EAGAIN ) { > report( "testRead() read failed\n" ); > ret = JNI_FALSE; > } > } > Thanks Andreas I'm packing up to move. I'll be more or less away for a couple weeks here. I'll be checking email but my workstation is going into a box soon. This isn't hard to fix as this port should be enumerated when EWOULDBLOCK is recieved. Thats error is OK for enumeration just as EAGAIN is. I've put the bug into bugzilla so we dont forget to get to it. http://bugzilla.qbang.org/show_bug.cgi?id=42 You can add yourself to the CC list if you wish to test fixes we provide or even put a patch into bugzilla yourself. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Fri Mar 24 11:51:52 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 24 Mar 2006 11:51:52 -0700 (MST) Subject: [Rxtx] JavaPOS In-Reply-To: <20060324082238.66371.qmail@web38214.mail.mud.yahoo.com> References: <20060324082238.66371.qmail@web38214.mail.mud.yahoo.com> Message-ID: On Fri, 24 Mar 2006, Maximulo Majir wrote: > Hi all! Hello Trent! > > > From what i understand, RXTX or JavaComm APIs were not > created solely for JavaPOS. In JavaPOS, we have the virtual method > claim() which is separate from open(), but in our RXTX API, claiming is > done every call to open(), we cant open the port if its claimed by > another application. Would it be alright to suggest or ask to create a > new method called claim(..)? Is there such thing as forceclaim() in > RXTX? this could be the same as portownership transfer or its > equivalent. ForceClaim is in JSR80. > Do you have some samples using RXTX as the lower layer for the Device > Service Objects in JavaPOS? I have tried it, i just want to compare. > maxim Hi Maxim JSR80 is the USB API IBM/Sun put together. The problem is they have a richer kernel/API underneath that can handle such things. With Serial Ports, there isnt anything there other than an ioctl that says don't let anyone touch this and lockfiles that are more of a 'lets be nice.' At times we may be using USB ports but it is through the termios layer with the limitations mentioned. The advantage is that not only USB will work with rxtx. Anything that has a termios layer should work (to the extent that termios layer is complete). I don't know how forceclaim() would help you. Lets say someone has a programmer working on /dev/ttyS0 and you take it. Now you both race each other to read data first. There isn't a mechanism I know of that will solve this problem in termios. The most obvious test being a native app and a Java app trying to take the port. There is the potential of requestion ownership from other Java Applications but the use for that is very rare. Did you have something more specific in mind that I'm missing? I'm not sure that claim() and forceclaim() would help you with rxtx other than maybe locking the port with claim() without opening it. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sat Mar 25 23:42:08 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 25 Mar 2006 23:42:08 -0700 (MST) Subject: [Rxtx] Serial snoop Message-ID: I was reading the Linux kernel mail-list tonight and ran past a thread that mentioned sersnoop. This looks like a handy tool for people dealing with new toys. "a simple command-line tool for linux that echoes bytes to and from any two serial ports, ptys, or network sockets, and prints all traffic to stdout, in hex and ascii." http://www.restivo.org/projects/sersnoop/ It works on Linux only at this time (debian package available). -- Trent Jarvi tjarvi at qbang.org From beat.arnet at gmail.com Sun Mar 26 07:32:35 2006 From: beat.arnet at gmail.com (Beat Arnet) Date: Sun, 26 Mar 2006 09:32:35 -0500 Subject: [Rxtx] Error 0x5 at /home/bob/foo/tar/rxtx-2.1-7/build/../src/termios.c(860): Access is, denied. Message-ID: <4426A603.80508@gmail.com> Dear all, When trying to open the serial port, I sometimes (not always) run into the following exception (when opening the serialPort): Error 0x5 at /home/bob/foo/tar/rxtx-2.1-7/build/../src/termios.c(860): Access is denied. java.lang.UnsatisfiedLinkError: native_psmisc_report_owner at gnu.io.CommPortIdentifier.native_psmisc_report_owner(Native Method) at gnu.io.CommPortIdentifier.open(CommPortIdentifier.java:354) at codeskin.tools.CLLoader.open(CLLoader.java:79) at codeskin.tools.C2000Programmer.run(C2000Programmer.java:220) at java.lang.Thread.run(Unknown Source) Is this the type of error where I should just try to open the port again, or can it be avoided? Regards, Beat From tjarvi at qbang.org Sun Mar 26 11:40:12 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 26 Mar 2006 11:40:12 -0700 (MST) Subject: [Rxtx] Error 0x5 at /home/bob/foo/tar/rxtx-2.1-7/build/../src/termios.c(860): Access is, denied. In-Reply-To: <4426A603.80508@gmail.com> References: <4426A603.80508@gmail.com> Message-ID: On Sun, 26 Mar 2006, Beat Arnet wrote: > Dear all, > > When trying to open the serial port, I sometimes (not always) run into > the following exception (when opening the serialPort): > > Error 0x5 at /home/bob/foo/tar/rxtx-2.1-7/build/../src/termios.c(860): > Access is > denied. > > java.lang.UnsatisfiedLinkError: native_psmisc_report_owner > at gnu.io.CommPortIdentifier.native_psmisc_report_owner(Native > Method) > at gnu.io.CommPortIdentifier.open(CommPortIdentifier.java:354) > at codeskin.tools.CLLoader.open(CLLoader.java:79) > at codeskin.tools.C2000Programmer.run(C2000Programmer.java:220) > at java.lang.Thread.run(Unknown Source) > > Is this the type of error where I should just try to open the port again, > or can it be avoided? > Hi Beat We did a second build of rxtx 2.1-7 to resolve that unsatisfied link error. It should work now. rxtx is trying to tell you it thinks someone else has the serial port open. You can try to open the port again but maybe you already have a copy of the program running when it happens? ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7r2.zip fixed build. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sun Mar 26 11:44:23 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 26 Mar 2006 11:44:23 -0700 (MST) Subject: [Rxtx] RXTX spec file (fwd) Message-ID: This is probably interesting for fedora/suse users. ---------- Forwarded message ---------- Date: Sun, 26 Mar 2006 16:25:45 +0200 To: taj at www.linux.org.uk Subject: RXTX spec file I send you this spec file which allows to create a RPM for Fedora 4, 5 (x86, x86_64) with Java Sun. -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: rxtx.spec Url: http://mailman.qbang.org/pipermail/rxtx/attachments/20060326/6c7b6af6/rxtx-0012.pl From tjarvi at qbang.org Sun Mar 26 23:42:59 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 26 Mar 2006 23:42:59 -0700 (MST) Subject: [Rxtx] Upcomming events. Message-ID: This Wednesday we will be announcing a new "Maintainer" for the rxtx project. The position is more like neutral leader. I wont be going away or doing less. This is just the right thing to do as it turns out the two people with CVS write access will be at the same company. We need a third and we need neutrality. The maintainer will have final say in any conflict and will try to be neutral. It will be open for discussion. Then we will do it :) I'll still do most of the footwork I do now. But. I'm falling behind. I should have gone through the mail-list and posted the next round of changes this weekend. I'm packing to move and its going so so - 13 years of toys collected. I suspect there will be a dead period on my part (a couple weeks) comming up. But if you get it on the mail-list, we will get it in if there are no objections. I may well not be reading the mail-list during this period as I look for a house and many other things. I hope everyone will help out. Thanks -- Trent Jarvi tjarvi at qbang.org From mahmoud_hadad at yahoo.com Sun Mar 26 07:31:19 2006 From: mahmoud_hadad at yahoo.com (ronan nick) Date: Sun, 26 Mar 2006 06:31:19 -0800 (PST) Subject: [Rxtx] a question about the COMM API Message-ID: <20060326143119.54919.qmail@web60014.mail.yahoo.com> hi, i was intrested in knowing how i can communicate with my internal modem using java? for example if i want to make a phone dialer application or a caller id application where should i be looking at? and as i understood the COMM API is for devices that is attached to the computer through serial ports. --------------------------------- New Yahoo! Messenger with Voice. Call regular phones from your PC and save big. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060326/ce8329f0/attachment-0014.html From dmarkman at mac.com Mon Mar 20 00:20:43 2006 From: dmarkman at mac.com (Dmitry Markman) Date: Mon, 20 Mar 2006 02:20:43 -0500 Subject: [Rxtx] Mac OS X RXTX java installer In-Reply-To: References: <07D0DE29-BA32-4CFE-B036-66BC6423D385@buechse.de> <441AE3E0.2030503@willicon.de> <12531986.1142622114996.JavaMail.dmarkman@mac.com> <441B2674.9010409@willicon.de> <13577405.1142634732776.JavaMail.dmarkman@mac.com> <441B4182.8010407@willicon.de> <92CD0D6C-5BE8-426E-A46D-99452059FF49@mac.com> <441BBB2D.8030305@willicon.de> <441C4088.5090905@willicon.de> Message-ID: <64BC1E23-FDDE-4CE6-8863-CFC881CBC224@mac.com> Hi all I put RXTX installer that will install everything (and will create / var/lock if necessary and add user to the uucp group) for mac os x from Java into the rxtx's CVS repository it could be easily modified to install files for any platform it uses Greg Guerin's AuthKit for authentication and authorization Greg released that kit under artistic license, so Trent, please take a look we, probably, can negotiate license with Greg if it's necessary Greg's AuthKit could be downloaded from http://www.amug.org/~glguerin/ sw/#authkit Michael Hall (mikehall at spacestar dot net) had a suggestion to make implementation of the jaas LoginModule based on Greg's AuthKit (his modification of the Greg's AuthKit could be found at http:// www.spacestar.net/users/mikehall/authkit.dmg) but Michael's AuthKitLoginModule does only half a job: it does authenticate but it can not run any external unix process in privileged mode (at least I wasn't able to do so) possible explanation could be found in conversation between Greg and Michael at Apple's java-dev list (look for archives) so I didn't use jaas API for rxtxinstaller I created folder MacOSX in the contrib folder comment 1. if you want to run that installer as standalone application all you need that RXTXInstaller.jar 2. if you want to use webstart you have to add Greg's libAuthKit.jnilib to the mac os x's resources in theory RXTXInstaller.jar doesn't need it, but there is a problem with loading libAuthKit.jnilib from webstart authkit uses loadLibrary method to load library and it failed (from webstart) for standalone application I extract libAuthKit.jnilib from the RXTXInstaller.jar and put it into the /Library/Java/Extensions or ~/Library/Java/Extensions folder that file will be deleted after installer quit unfortunately I didn't have time to put documentation there but it is mostly self-explanatory I took installer code from my gl4java installer that I did about 3 years ago (with small modifications) it would be very nice if Apple will release LoginModule that really will do the job (com.apple.security.auth.module package????? ) (UnixLoginModule is pretty useless) From lyon at docjava.com Mon Mar 20 06:34:39 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Mon, 20 Mar 2006 08:34:39 -0500 Subject: [Rxtx] Mac OS X RXTX java installer In-Reply-To: <64BC1E23-FDDE-4CE6-8863-CFC881CBC224@mac.com> References: <07D0DE29-BA32-4CFE-B036-66BC6423D385@buechse.de> <441AE3E0.2030503@willicon.de> <12531986.1142622114996.JavaMail.dmarkman@mac.com> <441B2674.9010409@willicon.de> <13577405.1142634732776.JavaMail.dmarkman@mac.com> <441B4182.8010407@willicon.de> <92CD0D6C-5BE8-426E-A46D-99452059FF49@mac.com> <441BBB2D.8030305@willicon.de> <441C4088.5090905@willicon.de> <64BC1E23-FDDE-4CE6-8863-CFC881CBC224@mac.com> Message-ID: Hi Dimitry, This sounds like great work. Just a couple of questions; After the check out of the CVS files, using: setenv CVSROOT :pserver:anonymous at cvs.milestonesolutions.com:/usr/local/cvsroot 53 8:28 setenv PASSWORD mousy 54 8:29 cvs login 55 8:29 cvs checkout rxtx-devel I cd'd over to: rxtx-devel/MACOSX_IDE And found: CVS/ CW/ ForPackageMaker/ PB/ Where is the installer? Thanks! - Doug From tjarvi at qbang.org Mon Mar 20 06:39:37 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 20 Mar 2006 06:39:37 -0700 (MST) Subject: [Rxtx] Mac OS X RXTX java installer In-Reply-To: References: <07D0DE29-BA32-4CFE-B036-66BC6423D385@buechse.de> <441AE3E0.2030503@willicon.de> <12531986.1142622114996.JavaMail.dmarkman@mac.com> <441B2674.9010409@willicon.de> <13577405.1142634732776.JavaMail.dmarkman@mac.com> <441B4182.8010407@willicon.de> <92CD0D6C-5BE8-426E-A46D-99452059FF49@mac.com> <441BBB2D.8030305@willicon.de> <441C4088.5090905@willicon.de> <64BC1E23-FDDE-4CE6-8863-CFC881CBC224@mac.com> Message-ID: On Mon, 20 Mar 2006, Dr. Douglas Lyon wrote: > Hi Dimitry, > This sounds like great work. Just a couple of questions; > After the check out of the CVS files, using: > setenv CVSROOT > :pserver:anonymous at cvs.milestonesolutions.com:/usr/local/cvsroot > 53 8:28 setenv PASSWORD mousy > 54 8:29 cvs login > 55 8:29 cvs checkout rxtx-devel Hi Doug You want "cvs checkout -r commapi-0-0-1 rxtx-devel" to get RXTX 2.1 The default branch is rxtx 2.0 which isn't very active right now. -- Trent Jarvi tjarvi at qbang.org From lyon at docjava.com Mon Mar 20 07:05:44 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Mon, 20 Mar 2006 09:05:44 -0500 Subject: [Rxtx] Mac OS X RXTX java installer In-Reply-To: References: <07D0DE29-BA32-4CFE-B036-66BC6423D385@buechse.de> <441AE3E0.2030503@willicon.de> <12531986.1142622114996.JavaMail.dmarkman@mac.com> <441B2674.9010409@willicon.de> <13577405.1142634732776.JavaMail.dmarkman@mac.com> <441B4182.8010407@willicon.de> <92CD0D6C-5BE8-426E-A46D-99452059FF49@mac.com> <441BBB2D.8030305@willicon.de> <441C4088.5090905@willicon.de> <64BC1E23-FDDE-4CE6-8863-CFC881CBC224@mac.com> Message-ID: Hi Trent, Thanks for the info on the CVS checkout procedure. I did that and am still not sure where the installer is. Here is what I have: cd MACOSX_IDE/ p4.docjava.com{lyon}121: ls CVS/ ForPackageMaker/ PB/ p4.docjava.com{lyon}122: find . | more . ./ForPackageMaker ./ForPackageMaker/RXTX.pkg.sit.hqx ./ForPackageMaker/Resources ./ForPackageMaker/Resources/ReadMe.rtf ./ForPackageMaker/Resources/Welcome.rtf ./ForPackageMaker/Resources/CVS ./ForPackageMaker/Resources/CVS/Entries ./ForPackageMaker/Resources/CVS/Repository ./ForPackageMaker/Resources/CVS/Tag ./ForPackageMaker/Resources/CVS/Root ./ForPackageMaker/Resources/preinstall ./ForPackageMaker/Resources/License.rtf ./ForPackageMaker/Resources/preupgrade ./ForPackageMaker/RXTX.pmsp ./ForPackageMaker/CVS ./ForPackageMaker/CVS/Entries ./ForPackageMaker/CVS/Repository ./ForPackageMaker/CVS/Entries.Log ./ForPackageMaker/CVS/Tag ./ForPackageMaker/CVS/Root ./ForPackageMaker/RXTX_Tiger.pkg.sitx.hqx ./ForPackageMaker/RXTX_Jag.pkg.sit.hqx ./ForPackageMaker/Install ./ForPackageMaker/Install/CVS ./ForPackageMaker/Install/CVS/Entries ./ForPackageMaker/Install/CVS/Repository ./ForPackageMaker/Install/CVS/Tag ./ForPackageMaker/Install/CVS/Root ./ForPackageMaker/Install/Library ./ForPackageMaker/Install/Library/CVS ./ForPackageMaker/Install/Library/CVS/Entries ./ForPackageMaker/Install/Library/CVS/Repository ./ForPackageMaker/Install/Library/CVS/Tag ./ForPackageMaker/Install/Library/CVS/Root ./ForPackageMaker/Install/Library/Java ./ForPackageMaker/Install/Library/Java/Extensions ./ForPackageMaker/Install/Library/Java/Extensions/RXTXcomm.jar ./ForPackageMaker/Install/Library/Java/Extensions/CVS ./ForPackageMaker/Install/Library/Java/Extensions/CVS/Entries ./ForPackageMaker/Install/Library/Java/Extensions/CVS/Repository ./ForPackageMaker/Install/Library/Java/Extensions/CVS/Tag ./ForPackageMaker/Install/Library/Java/Extensions/CVS/Root ./ForPackageMaker/Install/Library/Java/Extensions/librxtxSerial.jnilib ./ForPackageMaker/Install/Library/Java/CVS ./ForPackageMaker/Install/Library/Java/CVS/Entries ./ForPackageMaker/Install/Library/Java/CVS/Repository ./ForPackageMaker/Install/Library/Java/CVS/Entries.Log ./ForPackageMaker/Install/Library/Java/CVS/Tag ./ForPackageMaker/Install/Library/Java/CVS/Root ./ForPackageMaker/RXTX_Tiger.pmproj.sitx.hqx ./CVS ./CVS/Entries ./CVS/Repository ./CVS/Entries.Log ./CVS/Tag ./CVS/Root ./PB ./PB/LibSerialUniversal.xcodeproj.sitx.hqx ./PB/CVS ./PB/CVS/Entries ./PB/CVS/Repository ./PB/CVS/Entries.Log ./PB/CVS/Tag ./PB/CVS/Root ./PB/LibSerial.pbproj.sit.hqx ./PB/startpoint.c ./PB/config.h What is the procedure to run this installer? Do we need a README in: /rxtx-devel/MACOSX_IDE Here is what we have: CVS/ ForPackageMaker/ PB/ Thanks! - DL >On Mon, 20 Mar 2006, Dr. Douglas Lyon wrote: > >>Hi Dimitry, >>This sounds like great work. Just a couple of questions; >>After the check out of the CVS files, using: >>setenv CVSROOT >>:pserver:anonymous at cvs.milestonesolutions.com:/usr/local/cvsroot >> 53 8:28 setenv PASSWORD mousy >> 54 8:29 cvs login >> 55 8:29 cvs checkout rxtx-devel > >Hi Doug > >You want "cvs checkout -r commapi-0-0-1 rxtx-devel" to get RXTX 2.1 >The default branch is rxtx 2.0 which isn't very active right now. > >-- >Trent Jarvi >tjarvi at qbang.org From tjarvi at qbang.org Mon Mar 20 07:25:30 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 20 Mar 2006 07:25:30 -0700 (MST) Subject: [Rxtx] Mac OS X RXTX java installer In-Reply-To: References: <07D0DE29-BA32-4CFE-B036-66BC6423D385@buechse.de> <441AE3E0.2030503@willicon.de> <12531986.1142622114996.JavaMail.dmarkman@mac.com> <441B2674.9010409@willicon.de> <13577405.1142634732776.JavaMail.dmarkman@mac.com> <441B4182.8010407@willicon.de> <92CD0D6C-5BE8-426E-A46D-99452059FF49@mac.com> <441BBB2D.8030305@willicon.de> <441C4088.5090905@willicon.de> <64BC1E23-FDDE-4CE6-8863-CFC881CBC224@mac.com> Message-ID: On Mon, 20 Mar 2006, Dr. Douglas Lyon wrote: > Hi Trent, > Thanks for the info on the CVS checkout procedure. > I did that and am still not sure where the installer is. Hi Doug It does look like it was not cvs committed. There is no rxtx-devel/contrib/MacOSX directory in there at the moment. It was mentioned that it was put under contrib. -- Trent Jarvi tjarvi at qbang.org From dmarkman at mac.com Mon Mar 20 07:29:56 2006 From: dmarkman at mac.com (Dmitry Markman) Date: Mon, 20 Mar 2006 09:29:56 -0500 Subject: [Rxtx] Mac OS X RXTX java installer In-Reply-To: References: <07D0DE29-BA32-4CFE-B036-66BC6423D385@buechse.de> <441AE3E0.2030503@willicon.de> <12531986.1142622114996.JavaMail.dmarkman@mac.com> <441B2674.9010409@willicon.de> <13577405.1142634732776.JavaMail.dmarkman@mac.com> <441B4182.8010407@willicon.de> <92CD0D6C-5BE8-426E-A46D-99452059FF49@mac.com> <441BBB2D.8030305@willicon.de> <441C4088.5090905@willicon.de> <64BC1E23-FDDE-4CE6-8863-CFC881CBC224@mac.com> Message-ID: <6054EB4E-F7E0-4A9C-BDDA-D582D6D8826F@mac.com> you can find it in the rxtx-devel/contrib folder On Mar 20, 2006, at 9:05 AM, Dr. Douglas Lyon wrote: > Hi Trent, > Thanks for the info on the CVS checkout procedure. > I did that and am still not sure where the installer is. > Here is what I have: > cd MACOSX_IDE/ > p4.docjava.com{lyon}121: ls > CVS/ ForPackageMaker/ PB/ > p4.docjava.com{lyon}122: find . | more > . > ./ForPackageMaker > ./ForPackageMaker/RXTX.pkg.sit.hqx > ./ForPackageMaker/Resources > ./ForPackageMaker/Resources/ReadMe.rtf > ./ForPackageMaker/Resources/Welcome.rtf > ./ForPackageMaker/Resources/CVS > ./ForPackageMaker/Resources/CVS/Entries > ./ForPackageMaker/Resources/CVS/Repository > ./ForPackageMaker/Resources/CVS/Tag > ./ForPackageMaker/Resources/CVS/Root > ./ForPackageMaker/Resources/preinstall > ./ForPackageMaker/Resources/License.rtf > ./ForPackageMaker/Resources/preupgrade > ./ForPackageMaker/RXTX.pmsp > ./ForPackageMaker/CVS > ./ForPackageMaker/CVS/Entries > ./ForPackageMaker/CVS/Repository > ./ForPackageMaker/CVS/Entries.Log > ./ForPackageMaker/CVS/Tag > ./ForPackageMaker/CVS/Root > ./ForPackageMaker/RXTX_Tiger.pkg.sitx.hqx > ./ForPackageMaker/RXTX_Jag.pkg.sit.hqx > ./ForPackageMaker/Install > ./ForPackageMaker/Install/CVS > ./ForPackageMaker/Install/CVS/Entries > ./ForPackageMaker/Install/CVS/Repository > ./ForPackageMaker/Install/CVS/Tag > ./ForPackageMaker/Install/CVS/Root > ./ForPackageMaker/Install/Library > ./ForPackageMaker/Install/Library/CVS > ./ForPackageMaker/Install/Library/CVS/Entries > ./ForPackageMaker/Install/Library/CVS/Repository > ./ForPackageMaker/Install/Library/CVS/Tag > ./ForPackageMaker/Install/Library/CVS/Root > ./ForPackageMaker/Install/Library/Java > ./ForPackageMaker/Install/Library/Java/Extensions > ./ForPackageMaker/Install/Library/Java/Extensions/RXTXcomm.jar > ./ForPackageMaker/Install/Library/Java/Extensions/CVS > ./ForPackageMaker/Install/Library/Java/Extensions/CVS/Entries > ./ForPackageMaker/Install/Library/Java/Extensions/CVS/Repository > ./ForPackageMaker/Install/Library/Java/Extensions/CVS/Tag > ./ForPackageMaker/Install/Library/Java/Extensions/CVS/Root > ./ForPackageMaker/Install/Library/Java/Extensions/librxtxSerial.jnilib > ./ForPackageMaker/Install/Library/Java/CVS > ./ForPackageMaker/Install/Library/Java/CVS/Entries > ./ForPackageMaker/Install/Library/Java/CVS/Repository > ./ForPackageMaker/Install/Library/Java/CVS/Entries.Log > ./ForPackageMaker/Install/Library/Java/CVS/Tag > ./ForPackageMaker/Install/Library/Java/CVS/Root > ./ForPackageMaker/RXTX_Tiger.pmproj.sitx.hqx > ./CVS > ./CVS/Entries > ./CVS/Repository > ./CVS/Entries.Log > ./CVS/Tag > ./CVS/Root > ./PB > ./PB/LibSerialUniversal.xcodeproj.sitx.hqx > ./PB/CVS > ./PB/CVS/Entries > ./PB/CVS/Repository > ./PB/CVS/Entries.Log > ./PB/CVS/Tag > ./PB/CVS/Root > ./PB/LibSerial.pbproj.sit.hqx > ./PB/startpoint.c > ./PB/config.h > > What is the procedure to run this installer? > Do we need a README in: > /rxtx-devel/MACOSX_IDE > Here is what we have: > CVS/ ForPackageMaker/ PB/ > > > Thanks! > - DL > >> On Mon, 20 Mar 2006, Dr. Douglas Lyon wrote: >> >>> Hi Dimitry, >>> This sounds like great work. Just a couple of questions; >>> After the check out of the CVS files, using: >>> setenv CVSROOT :pserver:anonymous at cvs.milestonesolutions.com:/usr/ >>> local/cvsroot >>> 53 8:28 setenv PASSWORD mousy >>> 54 8:29 cvs login >>> 55 8:29 cvs checkout rxtx-devel >> >> Hi Doug >> >> You want "cvs checkout -r commapi-0-0-1 rxtx-devel" to get RXTX 2.1 >> The default branch is rxtx 2.0 which isn't very active right now. >> >> -- >> Trent Jarvi >> tjarvi at qbang.org > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx Dmitry Markman From mikehall at spacestar.net Mon Mar 20 05:25:25 2006 From: mikehall at spacestar.net (Michael Hall) Date: Mon, 20 Mar 2006 06:25:25 -0600 Subject: [Rxtx] Re: Mac OS X RXTX java installer In-Reply-To: <64BC1E23-FDDE-4CE6-8863-CFC881CBC224@mac.com> References: <07D0DE29-BA32-4CFE-B036-66BC6423D385@buechse.de> <441AE3E0.2030503@willicon.de> <12531986.1142622114996.JavaMail.dmarkman@mac.com> <441B2674.9010409@willicon.de> <13577405.1142634732776.JavaMail.dmarkman@mac.com> <441B4182.8010407@willicon.de> <92CD0D6C-5BE8-426E-A46D-99452059FF49@mac.com> <441BBB2D.8030305@willicon.de> <441C4088.5090905@willicon.de> <64BC1E23-FDDE-4CE6-8863-CFC881CBC224@mac.com> Message-ID: <247EB61F-5CD1-4132-89A2-FC105B6CF9A5@spacestar.net> On Mar 20, 2006, at 1:20 AM, Dmitry Markman wrote: > > Michael Hall (mikehall at spacestar dot net) had a suggestion to > make implementation of the jaas LoginModule > based on Greg's AuthKit > (his modification of the Greg's AuthKit could be found at http:// > www.spacestar.net/users/mikehall/authkit.dmg) > but Michael's AuthKitLoginModule does only half a job: > it does authenticate > but it can not run any external unix process in privileged mode (at > least I wasn't able to do so) If you got it working directly with Greg's the point is moot. But to clarify it anyhow. The login module does not allow you to do anything anything privileged on return as was explained by Greg. You need to work with a separate privileged process using the execPrivileged method of his API. I assume you did something similar although I haven't looked at how you are using it yet. I allowed instead for a action to be performed at the same time you login/authenticate,this... System.setProperty("authkit.action","/usr/bin/id"); just before this... lc.login(); To clarify, safely ignored as you are already complete. Mike Hall mikehall at spacestar dot net http://www.spacestar.net/users/mikehall http://sourceforge.net/projects/macnative -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2427 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20060320/f6e18202/smime-0017.bin From dmarkman at mac.com Mon Mar 20 07:36:47 2006 From: dmarkman at mac.com (Dmitry Markman) Date: Mon, 20 Mar 2006 09:36:47 -0500 Subject: [Rxtx] Re: Mac OS X RXTX java installer In-Reply-To: <247EB61F-5CD1-4132-89A2-FC105B6CF9A5@spacestar.net> References: <07D0DE29-BA32-4CFE-B036-66BC6423D385@buechse.de> <441AE3E0.2030503@willicon.de> <12531986.1142622114996.JavaMail.dmarkman@mac.com> <441B2674.9010409@willicon.de> <13577405.1142634732776.JavaMail.dmarkman@mac.com> <441B4182.8010407@willicon.de> <92CD0D6C-5BE8-426E-A46D-99452059FF49@mac.com> <441BBB2D.8030305@willicon.de> <441C4088.5090905@willicon.de> <64BC1E23-FDDE-4CE6-8863-CFC881CBC224@mac.com> <247EB61F-5CD1-4132-89A2-FC105B6CF9A5@spacestar.net> Message-ID: Hi, Michael all I have to do is to run some shell script I tried to use your action mechanism and it worked great so I just System.setProperty ("authkit.action","" ) and after that I even don't need to run anything like subject.doAs.... but after few thoughts I choose to use plain Greg's approach, because in that case I don't have to deal with various java's configurations files and therefore to use 2-3 -D parameters in the java command line especially it's useful for java web start (it's so fragile :-( ) thanks for the great job On Mar 20, 2006, at 7:25 AM, Michael Hall wrote: > > On Mar 20, 2006, at 1:20 AM, Dmitry Markman wrote: >> >> Michael Hall (mikehall at spacestar dot net) had a suggestion to >> make implementation of the jaas LoginModule >> based on Greg's AuthKit >> (his modification of the Greg's AuthKit could be found at http:// >> www.spacestar.net/users/mikehall/authkit.dmg) >> but Michael's AuthKitLoginModule does only half a job: >> it does authenticate >> but it can not run any external unix process in privileged mode >> (at least I wasn't able to do so) > > If you got it working directly with Greg's the point is moot. > > But to clarify it anyhow. > The login module does not allow you to do anything anything > privileged on return as was explained by Greg. You need to work > with a separate privileged process using the execPrivileged method > of his API. I assume you did something similar although I haven't > looked at how you are using it yet. > I allowed instead for a action to be performed at the same time you > login/authenticate,this... > System.setProperty("authkit.action","/usr/bin/id"); > just before this... > lc.login(); > To clarify, safely ignored as you are already complete. > > Mike Hall mikehall at spacestar dot net > http://www.spacestar.net/users/mikehall > http://sourceforge.net/projects/macnative > > > Dmitry Markman From dmarkman at mac.com Mon Mar 20 07:44:45 2006 From: dmarkman at mac.com (Dmitry Markman) Date: Mon, 20 Mar 2006 09:44:45 -0500 Subject: [Rxtx] Mac OS X RXTX java installer In-Reply-To: References: <07D0DE29-BA32-4CFE-B036-66BC6423D385@buechse.de> <441AE3E0.2030503@willicon.de> <12531986.1142622114996.JavaMail.dmarkman@mac.com> <441B2674.9010409@willicon.de> <13577405.1142634732776.JavaMail.dmarkman@mac.com> <441B4182.8010407@willicon.de> <92CD0D6C-5BE8-426E-A46D-99452059FF49@mac.com> <441BBB2D.8030305@willicon.de> <441C4088.5090905@willicon.de> <64BC1E23-FDDE-4CE6-8863-CFC881CBC224@mac.com> Message-ID: it's in the commapi-0-0-1 branch I tested it right now: cvs co -r commapi-0-0-1 rxtx-devel and I got everything On Mar 20, 2006, at 9:25 AM, Trent Jarvi wrote: > On Mon, 20 Mar 2006, Dr. Douglas Lyon wrote: > >> Hi Trent, >> Thanks for the info on the CVS checkout procedure. >> I did that and am still not sure where the installer is. > > Hi Doug > > It does look like it was not cvs committed. There is no rxtx-devel/ > contrib/MacOSX directory in there at the moment. It was mentioned > that it was put under contrib. > > -- > Trent Jarvi > tjarvi at qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx Dmitry Markman From tjarvi at qbang.org Mon Mar 20 07:52:57 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 20 Mar 2006 07:52:57 -0700 (MST) Subject: [Rxtx] Mac OS X RXTX java installer In-Reply-To: References: <07D0DE29-BA32-4CFE-B036-66BC6423D385@buechse.de> <441AE3E0.2030503@willicon.de> <12531986.1142622114996.JavaMail.dmarkman@mac.com> <441B2674.9010409@willicon.de> <13577405.1142634732776.JavaMail.dmarkman@mac.com> <441B4182.8010407@willicon.de> <92CD0D6C-5BE8-426E-A46D-99452059FF49@mac.com> <441BBB2D.8030305@willicon.de> <441C4088.5090905@willicon.de> <64BC1E23-FDDE-4CE6-8863-CFC881CBC224@mac.com> Message-ID: On Mon, 20 Mar 2006, Dmitry Markman wrote: > it's in the commapi-0-0-1 branch > > I tested it right now: > cvs co -r commapi-0-0-1 rxtx-devel > > and I got everything > A fresh checkout worked. Here is a copy of the tree (just the installer bits) ftp://ftp.qbang.org/pub/rxtx/MacOSX-installer.zip -- Trent Jarvi tjarvi at qbang.org From lyon at docjava.com Mon Mar 20 08:08:26 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Mon, 20 Mar 2006 10:08:26 -0500 Subject: [Rxtx] Mac OS X RXTX java installer In-Reply-To: References: <07D0DE29-BA32-4CFE-B036-66BC6423D385@buechse.de> <441AE3E0.2030503@willicon.de> <12531986.1142622114996.JavaMail.dmarkman@mac.com> <441B2674.9010409@willicon.de> <13577405.1142634732776.JavaMail.dmarkman@mac.com> <441B4182.8010407@willicon.de> <92CD0D6C-5BE8-426E-A46D-99452059FF49@mac.com> <441BBB2D.8030305@willicon.de> <441C4088.5090905@willicon.de> <64BC1E23-FDDE-4CE6-8863-CFC881CBC224@mac.com> Message-ID: Hi All, Is the Auth package able to work properly on non Mac OS's? It was not clear from the doc or download. Thanks! - Doug From dmarkman at mac.com Mon Mar 20 08:15:22 2006 From: dmarkman at mac.com (Dmitry Markman) Date: Mon, 20 Mar 2006 10:15:22 -0500 Subject: [Rxtx] Mac OS X RXTX java installer In-Reply-To: References: <07D0DE29-BA32-4CFE-B036-66BC6423D385@buechse.de> <441AE3E0.2030503@willicon.de> <12531986.1142622114996.JavaMail.dmarkman@mac.com> <441B2674.9010409@willicon.de> <13577405.1142634732776.JavaMail.dmarkman@mac.com> <441B4182.8010407@willicon.de> <92CD0D6C-5BE8-426E-A46D-99452059FF49@mac.com> <441BBB2D.8030305@willicon.de> <441C4088.5090905@willicon.de> <64BC1E23-FDDE-4CE6-8863-CFC881CBC224@mac.com> Message-ID: <217312D8-CCCA-4859-ABA6-32DF1CC817B9@mac.com> thanks Trent, for putting it on ftp server On Mar 20, 2006, at 9:52 AM, Trent Jarvi wrote: > A fresh checkout worked. Here is a copy of the tree (just the > installer bits) > > ftp://ftp.qbang.org/pub/rxtx/MacOSX-installer.zip > Dmitry Markman From dmarkman at mac.com Mon Mar 20 09:14:03 2006 From: dmarkman at mac.com (Dmitry Markman) Date: Mon, 20 Mar 2006 11:14:03 -0500 Subject: [Rxtx] Mac OS X RXTX java installer In-Reply-To: References: <07D0DE29-BA32-4CFE-B036-66BC6423D385@buechse.de> <441AE3E0.2030503@willicon.de> <12531986.1142622114996.JavaMail.dmarkman@mac.com> <441B2674.9010409@willicon.de> <13577405.1142634732776.JavaMail.dmarkman@mac.com> <441B4182.8010407@willicon.de> <92CD0D6C-5BE8-426E-A46D-99452059FF49@mac.com> <441BBB2D.8030305@willicon.de> <441C4088.5090905@willicon.de> <64BC1E23-FDDE-4CE6-8863-CFC881CBC224@mac.com> Message-ID: <4DEBA6F0-DA45-4E84-823E-1F1AC48BDCCC@mac.com> no it will work only on mac os x however it's harmless to run it on other platform if you want to use it for other platform you have to do the following (I'll do it for linux) 1. modify RXTXInstaller class method public static RXTXInstaller getInstance() public static RXTXInstaller getInstance() { String osName = System.getProperty("os.name").toLowerCase(); if(osName.startsWith("mac")){ return new gnu.io.installer.macosx.MACOSXRXTXInstaller(); } else if(osName.startsWith("windows")){ return new gnu.io.installer.windows.WindowsRXTXInstaller(); }else if(osName.startsWith("linux")){ return new gnu.io.installer.linux.LinuxRXTXInstaller(); } return null; } 2. create folder gnu/io/installer/linux/ 3. create class Linux386RXTXInstaller package gnu.io.installer.linux; import java.io.File; public class Linux386RXTXInstaller extends gnu.io.installer.RXTXInstaller{ public Linux386RXTXInstaller(){ createJarFolder(); createLibFolder(); addJarResource("RXTXcomm.jar","/gnu/io/installer/resources/ linux/jar/RXTXcomm.dat"); addLibResource("librxtxSerial.so","/gnu/io/installer/ resources/linux/lib/librxtxSerial.so"); } protected void createJarFolder(){ String javaHome = System.getProperty("java.home"); char separator = File.separatorChar; jarFolder = new File(javaHome+separator+"lib"+separator+"ext"); } protected void createLibFolder(){ String javaHome = System.getProperty("java.home"); char separator = File.separatorChar; libFolder = new File(javaHome+separator+"bin"); } public void runPreProcess() {} //put here some action you need public void runPostProcess() {} //put here some action you need } 4. create folder /gnu/io/installer/resources/linux/jar and put there linux's version of RXTXcomm.dat (which is renamed RXTXcomm.jar) 5. create folder /gnu/io/installer/resources/linux/lib and put there linux's version of librxtxSerial. so 6. make sure that RXTXInstaller.jar has the following items: /gnu/io/installer/resources/linux/jar/RXTXcomm.jar /gnu/io/installer/resources/linux/lib/librxtxSerial.so 7. modify file installer.pref: jar file RXTXInstaller.jar must have the following item /gnu/io/installer/installer.pref that's basically it for windows you have to do the similar things: just replace linux to windows and librxtxSerial.so to rxtxSerial.dll and create appropriate gnu.io.installer.windows.WindowsRXTXInstaller class package gnu.io.installer.windows; import java.io.File; public class WindowsRXTXInstaller extends gnu.io.installer.RXTXInstaller{ public WindowsRXTXInstaller(){ createJarFolder(); createLibFolder(); addJarResource("RXTXcomm.jar","/gnu/io/installer/resources/ windows/jar/RXTXcomm.dat"); addLibResource("librxtxSerial.so","/gnu/io/installer/ resources/windows/lib/rxtxSerial.dll"); } protected void createJarFolder(){ String javaHome = System.getProperty("java.home"); char separator = File.separatorChar; jarFolder = new File(javaHome+separator+"lib"+separator+"ext"); } protected void createLibFolder(){ String javaHome = System.getProperty("java.home"); char separator = File.separatorChar; libFolder = new File(javaHome+separator+"bin"); } public void runPreProcess() {} //put here some action you need public void runPostProcess() {} //put here some action you need } installer.pref will look like On Mar 20, 2006, at 10:08 AM, Dr. Douglas Lyon wrote: > Hi All, > Is the Auth package able to work properly on > non Mac OS's? > It was not clear from the doc or download. > > Thanks! > - Doug > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx Dmitry Markman From joachim at buechse.de Mon Mar 20 10:49:06 2006 From: joachim at buechse.de (Joachim Buechse) Date: Mon, 20 Mar 2006 18:49:06 +0100 Subject: [Rxtx] BUG: Lock file stays even if port opening fails Message-ID: This was only tested on MacOSX but looking at the code, it should be true for all systems that use lock_uucp. I am opening a port which can not be opened (dialup port of a telephone paired via bluetooth but currently not reachable). The lock file is created and stays arround, even though the port open failed. After looking a bit through the code (of 2.17), I really wonder if it wouldn't be a good idea to make the "locking" an explicit operation called from the java code. This would certainly simplify the generation of meaningfull exceptions (and java based debugging). Maybe even the handling of "preopened" ports should be in the Java part of the lib (again for java based debugging puposes). That beeing said, I have no idea if this would be possible for the 2.07 implementation. Regards, Joachim From tjarvi at qbang.org Mon Mar 20 11:24:22 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 20 Mar 2006 11:24:22 -0700 (MST) Subject: [Rxtx] BUG: Lock file stays even if port opening fails In-Reply-To: References: Message-ID: On Mon, 20 Mar 2006, Joachim Buechse wrote: > This was only tested on MacOSX but looking at the code, it should be true > for all systems that use lock_uucp. > > I am opening a port which can not be opened (dialup port of a telephone > paired via bluetooth but currently not reachable). The lock file is > created and stays arround, even though the port open failed. > > > After looking a bit through the code (of 2.17), I really wonder if it > wouldn't be a good idea to make the "locking" an explicit operation > called from the java code. This would certainly simplify the generation > of meaningfull exceptions (and java based debugging). > Maybe even the handling of "preopened" ports should be in the Java part > of the lib (again for java based debugging puposes). That beeing said, I > have no idea if this would be possible for the 2.07 implementation. > > Regards, Hi Joachim It should be possible in the 2.0-7 implementation too. The calls to RXTXPort.java would not change. We would just do more there Moving more of that logic into Java would be better as many people don't like to look at C code. There is a liblockdev on most Linux distros that can do most of the C code and would be easier to use. The problem is embeded devices will not have that library. The preopened port code has not been really tested. That was a last minute request in a product cycle. I expect it will be tested this year though. As I recall, some devices really do not like CD raising on open. The preopened ports then allow people to mess around in java without power cycling the devices or losing data. -- Trent Jarvi tjarvi at qbang.org From joachim at buechse.de Mon Mar 20 12:01:08 2006 From: joachim at buechse.de (Joachim Buechse) Date: Mon, 20 Mar 2006 20:01:08 +0100 Subject: [Rxtx] BUG: Lock file stays even if port opening fails In-Reply-To: References: Message-ID: Hi Trent, What is your general feeling about moving code to Java? The last days I have been reading quite a bit of the code and there are several things, that might not work as expected. I'll give you two examples from is_device_locked: if LOCKDIR == /var/spool/locks the directory /var/spool/lock will not be checked. LOCKDIR is not checked for lockfiles with unexpected pefixes While these things have probably never been discovered in production, they are still possibly incorrect implementations. If it was Java code, I would write some unit tests producing the errors that could later be corrected. PS: One could imagine to actually implement the whole lockfile handling in Java using some native routines to get the values required (pid, st_dev, st_rdev, ...). On 20.03.2006, at 19:24, Trent Jarvi wrote: > On Mon, 20 Mar 2006, Joachim Buechse wrote: > >> This was only tested on MacOSX but looking at the code, it should >> be true for all systems that use lock_uucp. >> >> I am opening a port which can not be opened (dialup port of a >> telephone paired via bluetooth but currently not reachable). The >> lock file is created and stays arround, even though the port open >> failed. >> >> >> After looking a bit through the code (of 2.17), I really wonder if >> it wouldn't be a good idea to make the "locking" an explicit >> operation called from the java code. This would certainly simplify >> the generation of meaningfull exceptions (and java based debugging). >> Maybe even the handling of "preopened" ports should be in the Java >> part of the lib (again for java based debugging puposes). That >> beeing said, I have no idea if this would be possible for the 2.07 >> implementation. >> >> Regards, > > Hi Joachim > > It should be possible in the 2.0-7 implementation too. The calls > to RXTXPort.java would not change. We would just do more there > Moving more of that logic into Java would be better as many people > don't like to look at C code. There is a liblockdev on most Linux > distros that can do most of the C code and would be easier to use. > The problem is embeded devices will not have that library. > > The preopened port code has not been really tested. That was a > last minute request in a product cycle. I expect it will be tested > this year though. As I recall, some devices really do not like CD > raising on open. The preopened ports then allow people to mess > around in java without power cycling the devices or losing data. > > -- > Trent Jarvi > tjarvi at qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Mon Mar 20 12:21:02 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 20 Mar 2006 12:21:02 -0700 (MST) Subject: [Rxtx] BUG: Lock file stays even if port opening fails In-Reply-To: References: Message-ID: On Mon, 20 Mar 2006, Joachim Buechse wrote: > Hi Trent, > > What is your general feeling about moving code to Java? The last days I > have been reading quite a bit of the code and there are several things, > that might not work as expected. > > I'll give you two examples from is_device_locked: > > if LOCKDIR == /var/spool/locks the directory /var/spool/lock will not be > checked. > LOCKDIR is not checked for lockfiles with unexpected pefixes > > While these things have probably never been discovered in production, > they are still possibly incorrect implementations. If it was Java code, I > would write some unit tests producing the errors that could later be > corrected. > > PS: One could imagine to actually implement the whole lockfile handling > in Java using some native routines to get the values required (pid, > st_dev, st_rdev, ...). Hi Joachim I like the idea of moving more of the code into java but there are some things to consider. If you break this into multiple JNI calls, the performance will drop considerably during enumeration of ports. We are looking for 256 ports per dev type vs (16? in Sun's 2.0 and fewer types). Its hard to make assumptions. I've seen virtual ports start at /dev/foo100 for instance. It works out to over 7500 ports on Linux if you enable them all. We already trim that back by default. See Linux-all-ports in RXTXCommDriver.java. There are also native libraries that rxtx can link to. If you move too much into Java, linking to 'standard' libraries with distros will break. "configure --enable-liblock=yes" will not be doable. This is probably a favorable way with RedHat, Debian, Suse and others. Thats the right thing to do if there will be rpms, dpkg, .. For those reasons, I think it still make sense to keep it to a minimal ~3 calls to JNI code that we can use for speed and versatility. lock() isLocked(), unlock() perhaps. When I say speed, its more about avoiding crossing the JNI layer multiple times than java vs C performance. With versatility I think liblock is the right way for most but not all (embeded) linux distros. -- Trent Jarvi tjarvi at qbang.org From joachim at buechse.de Mon Mar 20 12:42:04 2006 From: joachim at buechse.de (Joachim Buechse) Date: Mon, 20 Mar 2006 20:42:04 +0100 Subject: [Rxtx] BUG: Lock file stays even if port opening fails In-Reply-To: References: Message-ID: <82C19FE7-DDCB-45B6-B2C9-7606B66F0124@buechse.de> Ok, what about providing a default implementation in Java? The RXTXCommDriver would call a (native) function useNativeLocking and if it returns true, call the native functions for lock() isLocked (), unlock(), else is would use the Java based default implementation. This could possibly be overriden by a property (again for debugging). Joachim On 20.03.2006, at 20:21, Trent Jarvi wrote: > On Mon, 20 Mar 2006, Joachim Buechse wrote: > >> Hi Trent, >> >> What is your general feeling about moving code to Java? The last >> days I have been reading quite a bit of the code and there are >> several things, that might not work as expected. >> >> I'll give you two examples from is_device_locked: >> >> if LOCKDIR == /var/spool/locks the directory /var/spool/lock will >> not be checked. >> LOCKDIR is not checked for lockfiles with unexpected pefixes >> >> While these things have probably never been discovered in >> production, they are still possibly incorrect implementations. If >> it was Java code, I would write some unit tests producing the >> errors that could later be corrected. >> >> PS: One could imagine to actually implement the whole lockfile >> handling in Java using some native routines to get the values >> required (pid, st_dev, st_rdev, ...). > > Hi Joachim > > I like the idea of moving more of the code into java but there are > some things to consider. > > If you break this into multiple JNI calls, the performance will > drop considerably during enumeration of ports. We are looking for > 256 ports per dev type vs (16? in Sun's 2.0 and fewer types). Its > hard to make assumptions. I've seen virtual ports start at /dev/ > foo100 for instance. > > It works out to over 7500 ports on Linux if you enable them all. > We already trim that back by default. See Linux-all-ports in > RXTXCommDriver.java. > > There are also native libraries that rxtx can link to. If you move > too much into Java, linking to 'standard' libraries with distros > will break. "configure --enable-liblock=yes" will not be doable. > This is probably a favorable way with RedHat, Debian, Suse and > others. Thats the right thing to do if there will be rpms, dpkg, .. > > For those reasons, I think it still make sense to keep it to a > minimal ~3 calls to JNI code that we can use for speed and > versatility. lock() isLocked(), unlock() perhaps. When I say > speed, its more about avoiding crossing the JNI layer multiple > times than java vs C performance. With versatility I think liblock > is the right way for most but not all (embeded) linux distros. > > -- > Trent Jarvi > tjarvi at qbang.org > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Mon Mar 20 12:44:47 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 20 Mar 2006 12:44:47 -0700 (MST) Subject: [Rxtx] BUG: Lock file stays even if port opening fails In-Reply-To: <82C19FE7-DDCB-45B6-B2C9-7606B66F0124@buechse.de> References: <82C19FE7-DDCB-45B6-B2C9-7606B66F0124@buechse.de> Message-ID: On Mon, 20 Mar 2006, Joachim Buechse wrote: > Ok, what about providing a default implementation in Java? > > The RXTXCommDriver would call a (native) function useNativeLocking and if > it returns true, call the native functions for lock() isLocked(), > unlock(), else is would use the Java based default implementation. This > could possibly be overriden by a property (again for debugging). > Hi Joachim That would be OK with me. -- Trent Jarvi tjarvi at qbang.org From dmarkman at mac.com Mon Mar 20 22:27:45 2006 From: dmarkman at mac.com (Dmitry Markman) Date: Tue, 21 Mar 2006 00:27:45 -0500 Subject: [Rxtx] binaries request Message-ID: <42702213-C222-4937-A585-7CFB17E47608@mac.com> Hi can somebody send me latest linux and windows binaries, please? or where I can find them (I didn't find them in the latest tareball) I gave up with my cygwin: something wrong I have no idea what java doesn't understand /cygwin/c syntax after I changed makefile it did java part but after that gcc 3.4.4 started to complain I set buffer length to 999 lines but I didn't get beginning of the story something wrong with my 1.4.2_09/include/jni.h gcc doesn't like it anyway I gave up thanks in advance Dmitry Markman -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060320/f8cbc57c/attachment-0017.html From tjarvi at qbang.org Mon Mar 20 22:36:48 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 20 Mar 2006 22:36:48 -0700 (MST) Subject: [Rxtx] binaries request In-Reply-To: <42702213-C222-4937-A585-7CFB17E47608@mac.com> References: <42702213-C222-4937-A585-7CFB17E47608@mac.com> Message-ID: On Tue, 21 Mar 2006, Dmitry Markman wrote: > Hi > can somebody send me latest linux and windows binaries, please? > > or where I can find them (I didn't find them in the latest tareball) > > I gave up with my cygwin: something wrong I have no idea what > java doesn't understand /cygwin/c syntax > after I changed makefile it did java part > but after that gcc 3.4.4 started to complain > I set buffer length to 999 lines but I didn't get beginning of the story > something wrong with my 1.4.2_09/include/jni.h gcc doesn't like it > anyway I gave up > > thanks in advance > Hi Dmitry The bins are here: ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7-bins-r2.zip Here are the files in the zip you want. Jar: rxtx-2.1-7-bins-r2/RXTXcomm.jar Windows: rxtx-2.1-7-bins-r2/Windows/i368-mingw32/rxtxSerial.dll Linux (x86) rxtx-2.1-7-bins-r2/Linux/i686-unknown-linux-gnu/librxtxSerial.so There are others in there including Parallel port support but those are the main ones for testing. -- Trent Jarvi tjarvi at qbang.org From dmarkman at mac.com Mon Mar 20 23:05:59 2006 From: dmarkman at mac.com (Dmitry Markman) Date: Tue, 21 Mar 2006 01:05:59 -0500 Subject: [Rxtx] binaries request In-Reply-To: References: <42702213-C222-4937-A585-7CFB17E47608@mac.com> Message-ID: thank you very much but windows's readme says: rxtxSerial.dll had to be recomopiled to link in missing native methods. should I ignore it? or what? thanks again also I understand that I should use mingw not cygwin I'll try to install mingw On Mar 21, 2006, at 12:36 AM, Trent Jarvi wrote: > On Tue, 21 Mar 2006, Dmitry Markman wrote: > >> Hi >> can somebody send me latest linux and windows binaries, please? >> >> or where I can find them (I didn't find them in the latest tareball) >> >> I gave up with my cygwin: something wrong I have no idea what >> java doesn't understand /cygwin/c syntax >> after I changed makefile it did java part >> but after that gcc 3.4.4 started to complain >> I set buffer length to 999 lines but I didn't get beginning of the >> story >> something wrong with my 1.4.2_09/include/jni.h gcc doesn't like it >> anyway I gave up >> >> thanks in advance >> > > Hi Dmitry > > The bins are here: > > ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7-bins-r2.zip > > Here are the files in the zip you want. > > Jar: > > rxtx-2.1-7-bins-r2/RXTXcomm.jar > > Windows: > > rxtx-2.1-7-bins-r2/Windows/i368-mingw32/rxtxSerial.dll > > Linux (x86) > > rxtx-2.1-7-bins-r2/Linux/i686-unknown-linux-gnu/librxtxSerial.so > > There are others in there including Parallel port support but those > are the main ones for testing. > > -- > Trent Jarvi > tjarvi at qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx Dmitry Markman From tjarvi at qbang.org Mon Mar 20 23:20:33 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 20 Mar 2006 23:20:33 -0700 (MST) Subject: [Rxtx] binaries request In-Reply-To: References: <42702213-C222-4937-A585-7CFB17E47608@mac.com> Message-ID: On Tue, 21 Mar 2006, Dmitry Markman wrote: > thank you very much > > but windows's readme says: > rxtxSerial.dll had to be recomopiled to link in missing native methods. > > should I ignore it? or what? > Hi Dmitry That dll should be OK. r2 is the recompile linked to the missing native method. The readme explains why it was recompiled; fuser.o was not linked into the dll in the first release. -- Trent Jarvi tjarvi at qbang.org From ariantristan at yahoo.com Mon Mar 20 23:55:24 2006 From: ariantristan at yahoo.com (Lambok Sianturi) Date: Mon, 20 Mar 2006 22:55:24 -0800 (PST) Subject: [Rxtx] jvm issue Message-ID: <20060321065524.94779.qmail@web50701.mail.yahoo.com> Hi All, This is my first time to join RxTx mailing list. I thank you all for allowing others to sign in in requests help. I use the latest RxTx lib in Fedora 3 with java version 1.4.2_09 b05. And I got this error: # # An unexpected error has been detected by HotSpot Virtual Machine: # # SIGSEGV (0xb) at pc=0x00bf27f3, pid=2633, tid=3086112448 # # Java VM: Java HotSpot(TM) Client VM (1.4.2_09-b05 mixed mode) # Problematic frame: # C [ld-linux.so.2+0xa7f3] # # An error report file with more information is saved as hs_err_pid2633.log # # If you would like to submit a bug report, please visit: # http://java.sun.com/webapps/bugreport/crash.jsp # ./run.sh: line 3: 2633 Aborted /usr/local/java/bin/java -Djava.library.path=/usr/local/java/jre/lib/ -Djsmsengine.debug=true -classpath jsmsengine.jar:smsgateway.jar:classes12.jar:RXTXcomm.jar:. com.api.sms.SMSServer What is the jvm depedency for the latest library? Can I use 1.4.2_09 b05? Thanks in advance. Arian --------------------------------- Yahoo! Mail Use Photomail to share photos without annoying attachments. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060320/83d58dd7/attachment-0017.html From f.frumento at ngi.it Tue Mar 21 00:21:47 2006 From: f.frumento at ngi.it (Fabio Frumento) Date: Tue, 21 Mar 2006 08:21:47 +0100 Subject: [Rxtx] Javadoc on the go Message-ID: <441FA98B.9050701@ngi.it> Hi Trent, sorry for the big delay but my job is running wild, i was out for some time but now i'm back and ready to continue the javadoc for Rxtx. Did you used the last javadoc patch i sent you ? let me know if i have to send it to you again or not. regards Fabio From lyon at docjava.com Tue Mar 21 00:51:18 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Tue, 21 Mar 2006 02:51:18 -0500 Subject: [Rxtx] lock files Message-ID: Hi All, You know, if the use of lock files were under Java control (rather than a build-time decision), it might enable a more unified binary distro. It might also facilitate quick prototyping of non-lock file approaches to resolving serial port contention issues (i.e., mac-like approaches vs. linux approaches, etc.). I realize that this is a radical overhaul of the lock file policy issue. Also, it may harm performance. On the other hand, our benchmarks on JNI overhead for modern processors indicate performance impact should be minimal. Perhaps it is more of an issue with the toybox systems. Suppose there were a class with a reasonable default...someone might write: SerialPortLockPolicy.setPolicy(SerialPortLockPolicy.UNIX_LOCK_FILE); SerialPortLockPolicy.setPolicy(SerialPortLockPolicy.NO_LOCK_CHECKING); SerialPortLockPolicy.setPolicy(SerialPortLockPolicy.MAC_STYLE); Thus, we could have a run-time reconfiguration of the serial port lock policy. A special NO_LOCK version of the binary would no longer be required. Any thoughts on this? Thanks! - Doug From joachim at buechse.de Tue Mar 21 03:09:09 2006 From: joachim at buechse.de (Joachim Buechse) Date: Tue, 21 Mar 2006 11:09:09 +0100 Subject: [Rxtx] lock files In-Reply-To: References: Message-ID: <8E12916A-1B9A-4FF2-B684-E2D1C794221B@buechse.de> This is pretty much what I thought about when I suggested, that the default behaviour could be overwritten with a property. I am very much in favor of this approach. In particular this allows much easier debugging for PC based java developers. I think big parts of the Java (and maybe some parts of the C code) could use a bit of a structural workover (unit tests, javadoc, synchronization, etc). Maybe there should be a CVS branch for this experimental version. I'd be happy to contribute a first workover for some of the Java code. Designing for testability and implementing a good bunch of unit tests has been a strategy that worked quite well in the Java projects I lead. And it ultimately allows more liberal change permission. Regards, Joachim On 21.03.2006, at 08:51, Dr. Douglas Lyon wrote: > Hi All, > You know, if the use of lock files were > under Java control (rather than a build-time decision), > it might enable a more unified binary distro. It might also > facilitate quick prototyping of non-lock file approaches > to resolving serial port contention issues (i.e., mac-like > approaches vs. linux approaches, etc.). > > I realize that this is a radical overhaul of the lock file policy > issue. Also, it may harm performance. On the other hand, > our benchmarks on JNI overhead for modern processors indicate > performance impact should be minimal. Perhaps it is more of > an issue with the toybox systems. > > Suppose there were a class with a reasonable default...someone > might write: > SerialPortLockPolicy.setPolicy(SerialPortLockPolicy.UNIX_LOCK_FILE); > SerialPortLockPolicy.setPolicy(SerialPortLockPolicy.NO_LOCK_CHECKING); > SerialPortLockPolicy.setPolicy(SerialPortLockPolicy.MAC_STYLE); > > Thus, we could have a run-time reconfiguration of the serial port lock > policy. A special NO_LOCK version of the binary would no longer > be required. > > Any thoughts on this? > > Thanks! > - Doug > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From joachim at buechse.de Tue Mar 21 06:23:08 2006 From: joachim at buechse.de (Joachim Buechse) Date: Tue, 21 Mar 2006 14:23:08 +0100 Subject: [Rxtx] PATCH: use of ioctl(fd, TIOCEXCL) instead of lockfiles Message-ID: <923AE774-EEA2-4911-92D8-32BB27802C8B@buechse.de> Here is the patch for the ioctl(fd, TIOCEXCL). I have verified this only for OSX 10.4.5, hence it is only defined for APPLE. However, it should work at least for Solaris as well. If a process has requested TIOEXCL further open calls by other user processes will fail. The patch also disables uucp style locking for APPLE. Obviously this is discussable. I think it is the way to go, as it eliminates creating the lock directory which doesnt exist on the standard installation and it eliminates messing with the system group definitions (adding users to group uucp). Regarding the possibility of root processes opening a device which is locked - I consider this a feature not a potential problem. It is highly unlikely, that somebody is crazy enough to run a JavaVM as root (unless he has no other means of getting a restricted IP port opened, ie doesnt understand ipfw). Anyway, even if the process runs as root, it fails when calling ioctl(fd, TIOCEXCL). It could however still open the port to listen for RING events. I.e. a fax server which needs to see incoming calls but otherwise doesnt want to block the port. So the only case where the proposed mechanism fails is, if an incorrectly implemented process running as root conflicts with a user process. I think this can be accepted. Regards, Joachim PS: If this patch is generally accepted, the installer and Mac doku should obviously be changed as well. Index: SerialImp.c =================================================================== RCS file: /usr/local/cvsroot/rxtx-devel/src/SerialImp.c,v retrieving revision 1.46.2.187 diff -u -r1.46.2.187 SerialImp.c --- SerialImp.c 29 Jan 2006 22:19:04 -0000 1.46.2.187 +++ SerialImp.c 21 Mar 2006 12:59:16 -0000 @@ -656,6 +656,25 @@ fd=OPEN (filename, O_RDWR | O_NOCTTY | O_NONBLOCK ); } while (fd < 0 && errno==EINTR); +#ifdef OPEN_EXCL + // Note that open() follows POSIX semantics: multiple open() calls to + // the same file will succeed unless the TIOCEXCL ioctl is issued. + // This will prevent additional opens except by root-owned processes. + // See tty(4) ("man 4 tty") and ioctl(2) ("man 2 ioctl") for details. + + if (fd >= 0 && (ioctl(fd, TIOCEXCL) == -1)) + { + sprintf( message, "open: exclusive access denied for % s\n", + filename ); + report( message ); + report_error( message ); + + close(fd); + goto fail; + } +#endif /* OPEN_EXCL */ + + if( configure_port( fd ) ) goto fail; (*env)->ReleaseStringUTFChars( env, jstr, filename ); sprintf( message, "open: fd returned is %i\n", fd ); Index: SerialImp.h =================================================================== RCS file: /usr/local/cvsroot/rxtx-devel/src/SerialImp.h,v retrieving revision 1.11.2.49 diff -u -r1.11.2.49 SerialImp.h --- SerialImp.h 5 Jul 2005 17:47:21 -0000 1.11.2.49 +++ SerialImp.h 21 Mar 2006 12:59:17 -0000 @@ -135,7 +135,8 @@ /*# define LOCKDIR "/var/spool/uucp"*/ # define LOCKDIR "/var/lock" # define LOCKFILEPREFIX "LK." -# define UUCP +/*# define UUCP*/ +# define OPEN_EXCL #endif /* __APPLE__ */ #if defined(__NetBSD__) # define DEVICEDIR "/dev/" From tjarvi at qbang.org Tue Mar 21 10:26:08 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 21 Mar 2006 10:26:08 -0700 (MST) Subject: [Rxtx] Javadoc on the go In-Reply-To: <441FA98B.9050701@ngi.it> References: <441FA98B.9050701@ngi.it> Message-ID: On Tue, 21 Mar 2006, Fabio Frumento wrote: > Hi Trent, > > sorry for the big delay but my job is running wild, i was out for some > time but now i'm back and ready to continue the javadoc for Rxtx. > > Did you used the last javadoc patch i sent you ? let me know if i have to > send it to you again or not. > > regards > > Fabio Hi Fabio The patch is in the rxtx mail-list archives. It will be going in soon. I did not see a time critical portion. I'll probably be going through the list since the last batch of patches this weekend and putting them into CVS. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Tue Mar 21 10:57:18 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 21 Mar 2006 10:57:18 -0700 (MST) Subject: [Rxtx] jvm issue In-Reply-To: <20060321065524.94779.qmail@web50701.mail.yahoo.com> References: <20060321065524.94779.qmail@web50701.mail.yahoo.com> Message-ID: On Mon, 20 Mar 2006, Lambok Sianturi wrote: > Hi All, > This is my first time to join RxTx mailing list. I thank you all for allowing others to sign in in requests help. > I use the latest RxTx lib in Fedora 3 with java version 1.4.2_09 b05. And I got this error: > > # > # An unexpected error has been detected by HotSpot Virtual Machine: > # > # SIGSEGV (0xb) at pc=0x00bf27f3, pid=2633, tid=3086112448 > # > # Java VM: Java HotSpot(TM) Client VM (1.4.2_09-b05 mixed mode) > # Problematic frame: > # C [ld-linux.so.2+0xa7f3] A native library loading error? What happens if you recompile rxtx on your system and install that? This sounds like an ABI problem? rxtx 2.1-7 was compiled with a gcc 2.96 toolchain as I recall. The hope is newer system will be backwards compatible. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Tue Mar 21 11:05:29 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 21 Mar 2006 11:05:29 -0700 (MST) Subject: [Rxtx] PATCH: use of ioctl(fd, TIOCEXCL) instead of lockfiles In-Reply-To: <923AE774-EEA2-4911-92D8-32BB27802C8B@buechse.de> References: <923AE774-EEA2-4911-92D8-32BB27802C8B@buechse.de> Message-ID: On Tue, 21 Mar 2006, Joachim Buechse wrote: > Here is the patch for the ioctl(fd, TIOCEXCL). I have verified this only > for OSX 10.4.5, hence it is only defined for APPLE. However, it should > work at least for Solaris as well. > > If a process has requested TIOEXCL further open calls by other user > processes will fail. > > The patch also disables uucp style locking for APPLE. Obviously this is > discussable. I think it is the way to go, as it eliminates creating the > lock directory which doesnt exist on the standard installation and it > eliminates messing with the system group definitions (adding users to > group uucp). > > Regarding the possibility of root processes opening a device which is > locked - I consider this a feature not a potential problem. It is highly > unlikely, that somebody is crazy enough to run a JavaVM as root (unless > he has no other means of getting a restricted IP port opened, ie doesnt > understand ipfw). Anyway, even if the process runs as root, it fails when > calling ioctl(fd, TIOCEXCL). It could however still open the port to > listen for RING events. I.e. a fax server which needs to see incoming > calls but otherwise doesnt want to block the port. So the only case where > the proposed mechanism fails is, if an incorrectly implemented process > running as root conflicts with a user process. I think this can be > accepted. > > Regards, > Joachim > > PS: If this patch is generally accepted, the installer and Mac doku > should obviously be changed as well. > > > Index: SerialImp.c > =================================================================== > RCS file: /usr/local/cvsroot/rxtx-devel/src/SerialImp.c,v > retrieving revision 1.46.2.187 > diff -u -r1.46.2.187 SerialImp.c > --- SerialImp.c 29 Jan 2006 22:19:04 -0000 1.46.2.187 > +++ SerialImp.c 21 Mar 2006 12:59:16 -0000 > @@ -656,6 +656,25 @@ > fd=OPEN (filename, O_RDWR | O_NOCTTY | O_NONBLOCK ); > } while (fd < 0 && errno==EINTR); > > +#ifdef OPEN_EXCL > + // Note that open() follows POSIX semantics: multiple open() > calls to > + // the same file will succeed unless the TIOCEXCL ioctl is > issued. > + // This will prevent additional opens except by root-owned > processes. > + // See tty(4) ("man 4 tty") and ioctl(2) ("man 2 ioctl") for > details. > + > + if (fd >= 0 && (ioctl(fd, TIOCEXCL) == -1)) > + { > + sprintf( message, "open: exclusive access denied for % > s\n", > + filename ); > + report( message ); > + report_error( message ); > + > + close(fd); > + goto fail; > + } > +#endif /* OPEN_EXCL */ > + > + > if( configure_port( fd ) ) goto fail; > (*env)->ReleaseStringUTFChars( env, jstr, filename ); > sprintf( message, "open: fd returned is %i\n", fd ); > Index: SerialImp.h > =================================================================== > RCS file: /usr/local/cvsroot/rxtx-devel/src/SerialImp.h,v > retrieving revision 1.11.2.49 > diff -u -r1.11.2.49 SerialImp.h > --- SerialImp.h 5 Jul 2005 17:47:21 -0000 1.11.2.49 > +++ SerialImp.h 21 Mar 2006 12:59:17 -0000 > @@ -135,7 +135,8 @@ > /*# define LOCKDIR "/var/spool/uucp"*/ > # define LOCKDIR "/var/lock" > # define LOCKFILEPREFIX "LK." > -# define UUCP > +/*# define UUCP*/ > +# define OPEN_EXCL > #endif /* __APPLE__ */ > #if defined(__NetBSD__) > # define DEVICEDIR "/dev/" > This looks like a good start. What do you think Dmitry? Perhaps all systems with TIOCEXCL defined should use that though. Even if they use lockfiles. It wont hurt anything. That would catch people hacking their own serial apps without checking lockfiles. Its a good idea to avoid C++ style comments in the C portions. Some older systems don't deal with them well. If it's just for Mac OS X, it isn't a big deal. I think it was the Irix compiler that was problematic? -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Tue Mar 21 11:22:05 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 21 Mar 2006 11:22:05 -0700 (MST) Subject: [Rxtx] lock files In-Reply-To: <8E12916A-1B9A-4FF2-B684-E2D1C794221B@buechse.de> References: <8E12916A-1B9A-4FF2-B684-E2D1C794221B@buechse.de> Message-ID: We can try it. Maybe the JNI is much improved. The nice thing about linking into liblock is distros then worry about lockfiles on their systems. This way, we have to deal with any changes that may show up. On Tue, 21 Mar 2006, Joachim Buechse wrote: > This is pretty much what I thought about when I suggested, that the > default behaviour could be overwritten with a property. I am very much in > favor of this approach. In particular this allows much easier debugging > for PC based java developers. > > I think big parts of the Java (and maybe some parts of the C code) could > use a bit of a structural workover (unit tests, javadoc, synchronization, > etc). Maybe there should be a CVS branch for this experimental version. > I'd be happy to contribute a first workover for some of the Java code. > Designing for testability and implementing a good bunch of unit tests has > been a strategy that worked quite well in the Java projects I lead. And > it ultimately allows more liberal change permission. > > Regards, > Joachim > > > On 21.03.2006, at 08:51, Dr. Douglas Lyon wrote: > >> Hi All, >> You know, if the use of lock files were >> under Java control (rather than a build-time decision), >> it might enable a more unified binary distro. It might also >> facilitate quick prototyping of non-lock file approaches >> to resolving serial port contention issues (i.e., mac-like >> approaches vs. linux approaches, etc.). >> >> I realize that this is a radical overhaul of the lock file policy >> issue. Also, it may harm performance. On the other hand, >> our benchmarks on JNI overhead for modern processors indicate >> performance impact should be minimal. Perhaps it is more of >> an issue with the toybox systems. >> >> Suppose there were a class with a reasonable default...someone >> might write: >> SerialPortLockPolicy.setPolicy(SerialPortLockPolicy.UNIX_LOCK_FILE); >> SerialPortLockPolicy.setPolicy(SerialPortLockPolicy.NO_LOCK_CHECKING); >> SerialPortLockPolicy.setPolicy(SerialPortLockPolicy.MAC_STYLE); >> >> Thus, we could have a run-time reconfiguration of the serial port lock >> policy. A special NO_LOCK version of the binary would no longer >> be required. >> >> Any thoughts on this? >> >> Thanks! >> - Doug >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From dmarkman at mac.com Tue Mar 21 16:05:17 2006 From: dmarkman at mac.com (Dmitry Markman) Date: Tue, 21 Mar 2006 18:05:17 -0500 Subject: [Rxtx] PATCH: use of ioctl(fd, TIOCEXCL) instead of lockfiles In-Reply-To: References: <923AE774-EEA2-4911-92D8-32BB27802C8B@buechse.de> Message-ID: <512AC70C-BB86-48F2-A83C-023F35C23BAB@mac.com> I think it's cool, but I'd like to have that property implementation when user can choose between locking mechanism about comments: it's easy to change comments to the C style or we can use extensions of the file to cpp so c++ compiler will be used On Mar 21, 2006, at 1:05 PM, Trent Jarvi wrote: > This looks like a good start. What do you think Dmitry? Perhaps > all systems with TIOCEXCL defined should use that though. Even if > they use lockfiles. It wont hurt anything. That would catch > people hacking their own serial apps without checking lockfiles. > > Its a good idea to avoid C++ style comments in the C portions. > Some older systems don't deal with them well. If it's just for Mac > OS X, it isn't a big deal. I think it was the Irix compiler that > was problematic? Dmitry Markman From dmarkman at mac.com Tue Mar 21 16:13:00 2006 From: dmarkman at mac.com (Dmitry Markman) Date: Tue, 21 Mar 2006 18:13:00 -0500 Subject: [Rxtx] PATCH: use of ioctl(fd, TIOCEXCL) instead of lockfiles In-Reply-To: References: <923AE774-EEA2-4911-92D8-32BB27802C8B@buechse.de> Message-ID: I'd like to add that creating locking folder isn't a big deal we never had a problem related to the lock folders, because we always used installer on mac os x from other hand I'm not very much familiar with iotcl locking approach and I'm not sure it's more efficient Joachim wrote "I think it is the way to go, as it eliminates creating the lock directory which doesnt exist on the standard installation and it eliminates messing with the system group definitions (adding users to group uucp)." but I really didn't have any problem with that 1. doesn't exist on the standard installation there are many-many things that don't exist in the standard installation so I don't think that argument is strong enough 2. messing with the system group definitions I don't think we're messing with the group definition mac os x provides very clear way to set up group's members and together with Greg Guerin AuthKit there is no problem to set those definitions so I don't think that argument is strong either but from other hand using iotcl is more promising and is more elegant On Mar 21, 2006, at 1:05 PM, Trent Jarvi wrote: > > This looks like a good start. What do you think Dmitry? Perhaps > all systems with TIOCEXCL defined should use that though. Even if > they use lockfiles. It wont hurt anything. That would catch > people hacking their own serial apps without checking lockfiles. Dmitry Markman From joachim at buechse.de Wed Mar 22 04:46:45 2006 From: joachim at buechse.de (Joachim Buechse) Date: Wed, 22 Mar 2006 12:46:45 +0100 Subject: [Rxtx] PATCH: use of ioctl(fd, TIOCEXCL) instead of lockfiles In-Reply-To: References: <923AE774-EEA2-4911-92D8-32BB27802C8B@buechse.de> Message-ID: Sorry, I was not very clear with my arguments, so I will try again;-) Please, don't take this as an attack against work that has been done. I think the contributions that have been made in the past were made in a good spirit. But I really believe, that the current solution for OSX has many shortcomings and should be changed as soon as possible. lock files --- The /var/lock folder does not exist on the standard OSX installation, however the standard installation includes several applications that use serial ports (i.e. the FAX capability). This indicates, that the lock folder approach will not work well with system components. Applications for OSX will generally try to live in harmony with system components (except for HP print drivers of course). I think RXTX should follow this approach as well. uucp group --- Accessing serial ports is not an admin privileged operation on OSX. Any user (world) has read/write privileges on /dev/tty*. So the system default is to not enforce any group membership to access these ports. The group uucp however is a system group on all unix systems I know. It exists for certain system processes. A non admin user should in general not be a member of this group. Quite arguably no user should ever be a member of this group. Installer --- My general opinion is, that - no Installer should touch user or group data without warning - no Application Installer should touch groups which are not specific to the very application installed - no Installer should ever add regular users to a system group The current installer injects the installing user in the group uucp without warning about this change and without giving the option to "opt out" of this change. This is a potential security risk (but not currently a real one, as OSX contains no folders belonging to group uucp). The current installer does not work for multi user systems. It puts the installing user in the uucp group. However the installing user is not necessarily the user that will use the application. Putting all users that may use a serial port application in the system group uucp seems like a very invasive approach to me. Besides that, newly created users will not automatically be in the group and hence, serial applications will "break" for new users without obvious reasons. Avoiding the lock files will allow self contained applications (i.e. drag&drop installation). In my eyes this is largely preferable over an installer that requests admin privileges. Adding up all these points indicates very strongly, that the lock-file implementation is not the way to go on OSX. Regards, Joachim On 22.03.2006, at 00:13, Dmitry Markman wrote: > I'd like to add that > > creating locking folder isn't a big deal > we never had a problem related to the lock folders, because we > always used installer on mac os x > from other hand I'm not very much familiar with iotcl locking > approach and I'm not sure it's more efficient > > Joachim wrote "I think it is the way to go, as it eliminates > creating the lock directory which doesnt exist on the standard > installation and it eliminates messing with the system group > definitions (adding users to group uucp)." but I really didn't have > any problem with that > > 1. doesn't exist on the standard installation > there are many-many things that don't exist in the standard > installation so I don't think that argument is strong enough > 2. messing with the system group definitions > I don't think we're messing with the group definition > mac os x provides very clear way to set up group's members and > together with Greg Guerin AuthKit there is no problem to set those > definitions > so I don't think that argument is strong either > but from other hand using iotcl is more promising and is more elegant > > > > On Mar 21, 2006, at 1:05 PM, Trent Jarvi wrote: > >> >> This looks like a good start. What do you think Dmitry? Perhaps >> all systems with TIOCEXCL defined should use that though. Even if >> they use lockfiles. It wont hurt anything. That would catch >> people hacking their own serial apps without checking lockfiles. > > Dmitry Markman > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From dmarkman at mac.com Wed Mar 22 05:27:13 2006 From: dmarkman at mac.com (Dmitry Markman) Date: Wed, 22 Mar 2006 07:27:13 -0500 Subject: [Rxtx] PATCH: use of ioctl(fd, TIOCEXCL) instead of lockfiles In-Reply-To: References: <923AE774-EEA2-4911-92D8-32BB27802C8B@buechse.de> Message-ID: <83440CF3-DCD8-41C1-B941-F227232C27E3@mac.com> thanks for the very good explanation I didn't think that you were attacking any thing, so don't worry I just had feeling, that there were more aesthetic reasons for going to ioctl then real necessity now you explained everything quite well (BTW, asfar as I remember installer asks admin password so it wasn't quiet, but it really doesn't matter now) thanks On Mar 22, 2006, at 6:46 AM, Joachim Buechse wrote: > Sorry, I was not very clear with my arguments, so I will try again;-) > > Please, don't take this as an attack against work that has been > done. I think the contributions that have been made in the past > were made in a good spirit. But I really believe, that the current > solution for OSX has many shortcomings and should be changed as > soon as possible. > > lock files > --- > The /var/lock folder does not exist on the standard OSX > installation, however the standard installation includes several > applications that use serial ports (i.e. the FAX capability). This > indicates, that the lock folder approach will not work well with > system components. Applications for OSX will generally try to live > in harmony with system components (except for HP print drivers of > course). I think RXTX should follow this approach as well. > > uucp group > --- > Accessing serial ports is not an admin privileged operation on OSX. > Any user (world) has read/write privileges on /dev/tty*. So the > system default is to not enforce any group membership to access > these ports. The group uucp however is a system group on all unix > systems I know. It exists for certain system processes. A non admin > user should in general not be a member of this group. Quite > arguably no user should ever be a member of this group. > > Installer > --- > My general opinion is, that > - no Installer should touch user or group data without warning > - no Application Installer should touch groups which are not > specific to the very application installed > - no Installer should ever add regular users to a system group > > The current installer injects the installing user in the group uucp > without warning about this change and without giving the option to > "opt out" of this change. This is a potential security risk (but > not currently a real one, as OSX contains no folders belonging to > group uucp). > > The current installer does not work for multi user systems. It puts > the installing user in the uucp group. However the installing user > is not necessarily the user that will use the application. Putting > all users that may use a serial port application in the system > group uucp seems like a very invasive approach to me. Besides that, > newly created users will not automatically be in the group and > hence, serial applications will "break" for new users without > obvious reasons. > > > Avoiding the lock files will allow self contained applications > (i.e. drag&drop installation). In my eyes this is largely > preferable over an installer that requests admin privileges. Adding > up all these points indicates very strongly, that the lock-file > implementation is not the way to go on OSX. > > Regards, > Joachim > > > On 22.03.2006, at 00:13, Dmitry Markman wrote: > >> I'd like to add that >> >> creating locking folder isn't a big deal >> we never had a problem related to the lock folders, because we >> always used installer on mac os x >> from other hand I'm not very much familiar with iotcl locking >> approach and I'm not sure it's more efficient >> >> Joachim wrote "I think it is the way to go, as it eliminates >> creating the lock directory which doesnt exist on the standard >> installation and it eliminates messing with the system group >> definitions (adding users to group uucp)." but I really didn't >> have any problem with that >> >> 1. doesn't exist on the standard installation >> there are many-many things that don't exist in the standard >> installation so I don't think that argument is strong enough >> 2. messing with the system group definitions >> I don't think we're messing with the group definition >> mac os x provides very clear way to set up group's members and >> together with Greg Guerin AuthKit there is no problem to set those >> definitions >> so I don't think that argument is strong either >> but from other hand using iotcl is more promising and is more elegant >> >> >> >> On Mar 21, 2006, at 1:05 PM, Trent Jarvi wrote: >> >>> >>> This looks like a good start. What do you think Dmitry? Perhaps >>> all systems with TIOCEXCL defined should use that though. Even >>> if they use lockfiles. It wont hurt anything. That would catch >>> people hacking their own serial apps without checking lockfiles. >> >> Dmitry Markman >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx Dmitry Markman From lyon at docjava.com Wed Mar 22 06:12:18 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Wed, 22 Mar 2006 08:12:18 -0500 Subject: [Rxtx] sole of a new design pattern Message-ID: Hi All, I have been thinking about how we design the serial port software. I think we need a new design pattern. For lack of a better term, I shall call it: The Parametric Singleton Design Pattern By Douglas A. Lyon ABSTRACT The goal of the singleton design pattern is to make sure that there is one, and only one, instance of a given class. The goal of the parametric singleton design pattern is to make sure that there is one, and only one, instance of a given class with the given parametric values. We parametric singleton design pattern combines the singleton design pattern with a parameter that enables unique creation of instances of a class. These instances are cached. When a user asks for an instance with these parameters, the cache is checked. If the instance is in the cache, the instance is returned, otherwise it is created, added to the cache and then returned. We apply our parametric singleton design pattern to the retrieval of RMI registries bound to a given port. The goal of our system is to make sure that no two RMI registries are listening to the same socket and to make use of the RMI registries after they have been created. RMI registries are used in distributed computation. Introduction The singleton design pattern is meant to ensure that on a single instance of a class exists. It is also meant to provide a global point of access to it. The intent of the parametric singleton design pattern is to ensure that a class has only one instance for a given set of parameter values. It also provides a global point of access to it. Motivation A system cannot tolerate multiple instances of some classes with identical parameters. For example, you cannot have two instances making use of the same serial port, at the same time. You cannot have two instances that are trying to listen to the same socket connection. You cannot have two instances writing to the same file structure at the same time. As the operating system is often thought of as the arbiter of consumed resources (i.e., tape drives, serial ports, etc.) we frequently leave it to an operating system implementation to resolve these contention issues. Even for similar resources (like serial ports) there are few standards for handling contention. For example, serial ports on Linux are locked using a "/var/lock" file. POSIX, on the other hand, uses ioctl mechanisms to prevent contention. A better solution is to make a class that is responsible for keeping track of the instances created from the class. The class is declared final, so that it cannot be subclassed. The class also has a private constructor, so that other classes cannot instance it. The new design pattern is called the parametric singleton design pattern and it provides a way to access and create instances with given parameters. Applicability Use the Parametric Singleton Design Pattern when: 1. There must be exactly one instance of a class with the given parameters. 2. The instances must be accessible to clients from a well-known access point. Structure Insert UML diagram here. Participants The Parametric Singleton Clients that need instances 1. The Parametric Singleton defines an instance upon request from a client, if, and only if, the instance does not already exist. 2. The Parametric Singleton returns the instance to the client. 3. The Parametric Singleton is responsible for creating unique instances from given parameters. Collaborations Clients obtain a reference to a Parametric Singleton instance only through the parametric singleton design pattern. If the instance is left in an improper state (e.g., the serial port was left open) it is NOT the role of the Parametric Singleton Design Pattern to close the IO port. Nor is it the role of the Parametric Singleton Design Pattern to open the port. That role is delegate to some other part of the system. Further, it is not the role of the Parametric Singleton Design Pattern to check out resources. That is, multiple threads can have multiple references to the same resource at the same time. MUTEX locking is delegated to some other part of the system. Consequences The Parametric Singleton Design Pattern has several benefits: 1. Controlled access to parametrically defined instances. Since the Parametric Singleton class encapsulates its instances, there is control over how and when clients access it. 2. Reduced name space. The Parametric Singleton pattern avoids global variables that store instances created from the same parameter. Implementation Here are implementation issues to consider when using the Parametric Singleton pattern: 1. Unique mapping of parameters. The Parametric Singleton pattern requires that there be a mean to isomorphically map the parameter space into the instance space and back again. 2. Ensure unique instances. The Parametric Singleton pattern makes unique instances from parameters, and it does so only once. 3. Cache instances for fast retrieval. The Parametric Singleton pattern must be able to look up instances, given some set of parameters, and do so from some data structure. That is, there must be enough space to hold references to all the instances the program will need. Also, a mechanism is needed to look up and retrieve the instances quickly enough to satisfy the clients. Sample Code public final class ParametricSingletonRmiRegistry { private static Hashtable registry = new Hashtable(100); // use singleton pattern and??????????????????????????????????????????????? // prevent instantiation of RmiRegistryUtils.?????????????????????????????? private ParametricSingletonRmiRegistry() { } // the only instance of the Registry held by the RmiRegistryUtils?????????? public static void listNames(Integer port) { if (!isInCacheAndRunning(port)) return; Registry r = (Registry) registry.get(port); System.out.println("registry on port: " + port); System.out.println("registry: " + r); System.out.println("names: "); try { print(r.list()); } catch (RemoteException e) { In.message(e); } System.out.println("------------------------"); } /**???????????????????????????????????????????????????????????????????????? * Checks whether a Registry has been started on this host????????????????? * in the specified port.?????????????????????????????????????????????????? * If not, it tries to start one.?????????????????????????????????????????? * when it fails to start a Registry, it exits the program????????????????? * with exit code 1.??????????????????????????????????????????????????????? */ public static void restart(int port) { if (isInCacheAndRunning(port)) return; try { startRegistry(port); } catch (RemoteException e) { In.message(e); } } /**???????????????????????????????????????????????????????????????????????? * @param port????????????????????????????????????????????????????????????? * @return true if registry is in cache and running???????????????????????? */ private static boolean isInCacheAndRunning(Integer port) { if (!isRegistryRunning(port.intValue())) return false; if (!isRegistryInCache(port.intValue())) return false; return true; } /**???????????????????????????????????????????????????????????????????????? * @param port????????????????????????????????????????????????????????????? * @return true if we are able to locate a local registry on port.??????????????????????????????????????????????????????????????????????????? */ private static boolean isRegistryRunning(int port) { try { Registry r = LocateRegistry.getRegistry(port); if (r != null) return true; } catch (RemoteException e) { return false; } return false; } /**???????????????????????????????????????????????????????????????????????? * @param port????????????????????????????????????????????????????????????? * @return return true if registry is in cache????????????????????????????? */ private static boolean isRegistryInCache(int port) { if (registry.get(new Integer(port)) == null) return false; return true; } /**???????????????????????????????????????????????????????????????????????? * Restart the registry, if needed.???????????????????????????????????????? * Return the only instance of the registry for consistent global?????????? * using by making use of the Singleton Design Pattern????????????????????? *????????????????????????????????????????????????????????????????????????? * @return the internally held registry instance.?????????????????????????? */ public static Registry getRegistry(Integer port) { restart(port); return (Registry) registry.get(port); } private static void startRegistry(Integer port) throws RemoteException { Registry r; try { r = LocateRegistry.createRegistry(port.intValue()); registry.put(port, r); //r = new sun.rmi.registry.RegistryImpl???????????????????????????? /// (port.intValue());?????????????????????????????????????? // registry.put(port, r);?????????????????????????????????????????? } catch (Exception e) { //e.printStackTrace();????????????????????????????????????????????? r = LocateRegistry.getRegistry(port.intValue()); registry.put(port, r); } } public static void main(String args[]) throws RemoteException { //restart(port);??????????????????????????????????????????????????????? restart(5001); restart(5002); restart(5002); Registry r = LocateRegistry.getRegistry(5002); System.out.println("registry="+r); } } I would very much like to get your feedback on this new design pattern idea. Thank you for your time. Regards, - Doug From david.garnier at trusted-logic.com Wed Mar 22 07:36:10 2006 From: david.garnier at trusted-logic.com (David Garnier) Date: Wed, 22 Mar 2006 15:36:10 +0100 Subject: [Rxtx] sole of a new design pattern In-Reply-To: References: Message-ID: <442160DA.80107@trusted-logic.com> Hello, > The Parametric Singleton Design Pattern The Singleton is the most abused design pattern ever. Good use-cases for this pattern are extremely rare and mostly confined to problems related to hardware resources, like serial ports. > Applicability > > Use the Parametric Singleton Design Pattern when: > 1. There must be exactly one instance of a class with the given > parameters. OK. As I said above, this case this actually very unusual. The Singleton pattern is mostly used when : > 2. The instances must be accessible to clients from a well-known > access point. Using the singleton pattern in this case is just convenient for the programmer. Problems arises pretty quickly, especially if you attempt to unit-test your classes. 1) If your singleton is stateful, or hold on to stateful objects, it means that two different unit tests are not actually independent. Instead of starting with a brand new environment, the result of a test may be affected by the result of a previous test. This problem also arise when with your class relies on a database. In both cases, the solution is to reset your "unique" resource (Singleton or database) at the beginning of the test, which is a pain. Also, while most projects connect to a single database, projects that allow the use of Singletons usually contain several of thems, and new ones may cropped up unnoticed. You quickly end up with test cases that only pass in a certain order, which is a royal pain. 2) You cannot mockup a singleton. Once everyone calls the SomeSingleton class statically, you can't replace your class by SomeSingletonMockup. Furthermore, even for hardware services, the Singleton pattern does not really prevent concurrent accesses. If you start the same program in two different JVMs, unless they somehow shared the state of their "Singletons" (through lock files for example), the Singleton pattern will not prevent concurrent access. Our application uses RXTX, and we routinely encounter cases where another (native) application has already locked the port. Since we cannot modify the native application to recognize lock files, OS-level control is irreplaceable. > > Consequences > The Parametric Singleton Design Pattern has several benefits: > > 1. Controlled access to parametrically defined instances. Since > the Parametric Singleton class encapsulates its instances, there is > control over how and when clients access it. Not really. Once you've returned the instance to a client, you've lost control over it. The client can to whatever it wants with it. You cannot "recall" the instance or claim it back. > 2. Reduced name space. The Parametric Singleton pattern avoids > global variables that store instances created from the same parameter. Sure, but you don't have to rely on a Singleton for that. Just create a single Factory. > I would very much like to get your feedback on this new design > pattern idea. Well, it's nothing new. Some may say that it is the point of design patterns: formalizes the designs that occur again and again. However, this design is simply a combination of the Singleton and Factory patterns. I did use it in the past, but now I've been exposed to the shortcomings of the Singleton pattern, so I limit myself to Factories. Regards, David From sean_montgomery at baseview.com Wed Mar 22 08:35:28 2006 From: sean_montgomery at baseview.com (Sean Montgomery) Date: Wed, 22 Mar 2006 10:35:28 -0500 Subject: [Rxtx] sole of a new design pattern In-Reply-To: <442160DA.80107@trusted-logic.com> References: <442160DA.80107@trusted-logic.com> Message-ID: <05769CA7-A51B-4CF0-BAA0-E02DD905F5A4@baseview.com> On Mar 22, 2006, at 9:36 AM, David Garnier wrote: > Furthermore, even for hardware services, the Singleton pattern does > not really prevent concurrent > accesses. If you start the same program in two different JVMs, > unless they somehow shared the state > of their "Singletons" (through lock files for example), the > Singleton pattern will not prevent > concurrent access. > Multiple class loaders in a single JVM can be tricky, too. Then there's synchronization, lazy initialization and serialization of singletons to contend with. Bloch's Effective Java covers these, and here's a few articles: http://www.javaworld.com/javaworld/jw-04-2003/jw-0425-designpatterns- p3.html http://java.sun.com/developer/technicalArticles/Programming/singletons/ Just FYI :-) From lyon at docjava.com Wed Mar 22 08:50:48 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Wed, 22 Mar 2006 10:50:48 -0500 Subject: [Rxtx] sole of a new design pattern In-Reply-To: <442160DA.80107@trusted-logic.com> References: <442160DA.80107@trusted-logic.com> Message-ID: Hi All, First, I would like to thank David for his prompt and thoughtful remarks. I had no idea people that feel strongly about a design patterns! Wow! Feedback (particularly critical feedback) is greatly appreciated. Starting at the end, first: >I did use it in >the past, but now I've been exposed to the shortcomings of the >Singleton pattern, so I limit myself to Factories. David, if I understood your comments correctly, you suggested that Factories can be used in leu of the Singleton Design Pattern, or even the Parametric Singleton Design Pattern. As I see in [Gof]: Factory Method: Intent "Define an interface for creating an object, but let subclasses decide which class to instantiate. Factory Method lets a class defer instantiation to subclasses." The Singleton Design Pattern is a concrete class, which is rather different, right? Also, subclasses are not permitted with Singleton, as they are final. Naturally, I could use an abstract factory as a parent for a singleton. I could even design a facade that could be implemented with the singleton....but that is not the intention of the design. Unless you want a mock-up, as discussed, below: More below: >Hello, > >> The Parametric Singleton Design Pattern > >The Singleton is the most abused design pattern ever. Good use-cases >for this pattern are extremely >rare and mostly confined to problems related to hardware resources, >like serial ports. > > >> Applicability >> >> Use the Parametric Singleton Design Pattern when: >> 1. There must be exactly one instance of a class with the given >> parameters. >OK. As I said above, this case this actually very unusual. The >Singleton pattern is mostly used when : >> 2. The instances must be accessible to clients from a well-known >> access point. > >Using the singleton pattern in this case is just convenient for the >programmer. Problems arises >pretty quickly, especially if you attempt to unit-test your classes. > >1) If your singleton is stateful, or hold on to stateful objects, it >means that two different unit >tests are not actually independent. Instead of starting with a brand >new environment, the result of >a test may be affected by the result of a previous test. This >problem also arise when with your >class relies on a database. In both cases, the solution is to reset >your "unique" resource >(Singleton or database) at the beginning of the test, which is a >pain. Also, while most projects >connect to a single database, projects that allow the use of >Singletons usually contain several of >thems, and new ones may cropped up unnoticed. You quickly end up >with test cases that only pass in a >certain order, which is a royal pain. There are basic problems with communicating finite state machines that include reachability and deadlock analysis. These are addressed with petri net analysis and are beyond the scope of the design pattern. As you quite rightly pointed out; the parametric singleton pattern (or the singleton pattern, for that matter) enable multiple threads to gain access to the same instance. The only way that I can see to block others from gaining access to the reference is the synchronize keyword. This is putting a spin-lock (or MUTEX) on the reference. The question of how to unit-test a design pattern like the parametric singleton remains open. Perhaps this is a deficiency. > >2) You cannot mockup a singleton. Once everyone calls the >SomeSingleton class statically, you can't >replace your class by SomeSingletonMockup. Acutally, I am not sure that this is true. If the Singleton implements a Facade interface, it should be possible to make the replacement. Right? > >Furthermore, even for hardware services, the Singleton pattern does >not really prevent concurrent >accesses. If you start the same program in two different JVMs, >unless they somehow shared the state >of their "Singletons" (through lock files for example), the >Singleton pattern will not prevent >concurrent access. Good Point!! You have sharp eyes! The singleton design pattern should/could take responsibility for this. In fact, you may notice that my code does have an implementation (LocateRegistry) that can work across JVM's. The LocateRegistry will even work across the Internet! LocateRegistry takes both a host name and a Port (lock files just don't do this). I did not think to implement this beyond the local machine, but, in its present form, it will work across different processes. > >Our application uses RXTX, and we routinely encounter cases where >another (native) application has >already locked the port. Since we cannot modify the native >application to recognize lock files, >OS-level control is irreplaceable. The singleton design pattern is not meant to replace OS-level control, but to centralize the Java programmers access to it. If lock files, for example, are used for serial ports, the Singleton Design Pattern should be able to work with them. > > >> >> Consequences >> The Parametric Singleton Design Pattern has several benefits: >> > > 1. Controlled access to parametrically defined instances. Since >> the Parametric Singleton class encapsulates its instances, there is >> control over how and when clients access it. > >Not really. Once you've returned the instance to a client, you've >lost control over it. The client >can to whatever it wants with it. You cannot "recall" the instance >or claim it back. Good point, this should read: > 1. Controll when parametrically defined instances are created. Since > > the Parametric Singleton class encapsulates its instances, there is > > control over how and when they are instanced. > >> 2. Reduced name space. The Parametric Singleton pattern avoids >> global variables that store instances created from the same parameter. > >Sure, but you don't have to rely on a Singleton for that. Just >create a single Factory. > > Thank you for your thoughtful and prompt response! Regards, - Doug From dmarkman at mac.com Wed Mar 22 21:21:55 2006 From: dmarkman at mac.com (Dmitry Markman) Date: Wed, 22 Mar 2006 23:21:55 -0500 Subject: [Rxtx] sole of a new design pattern In-Reply-To: <442160DA.80107@trusted-logic.com> References: <442160DA.80107@trusted-logic.com> Message-ID: I don't think I get it On Mar 22, 2006, at 9:36 AM, David Garnier wrote: > Using the singleton pattern in this case is just convenient for the > programmer. Problems arises > pretty quickly, especially if you attempt to unit-test your classes. so you're saying that something isn't so good because you can not test it in the convenient way? if that's true, I'm totally disagree change your test, debug whatever, but if software is efficient at runtime, works fine and only problem is some unit test (which is some kind of framework for testing) then dump that unit test , dump that unit framework and make something appropriate to the software you're testing so if Douglas want to use singletons, what's the problem? and what do you mean by abusing of singleton usage? of course singleton doesn't prevent concurrent access to the resource across the processes unless you're using some OS facility to prevent it, besides singleton as it was introduced is relevant only and only inside of the same process otherwise it's not singleton it's something else (let's say network singleton: so you have remote invocation facility and some factory method that return object created by that facility) I don't have any problem with using any kind of singletons. Parametric Singleton idea (if I understand it right) could be easily implemented in the following way: use a map populate map with instances of some class and key is your parameter (you can use lazy population too) if somebody ask the key check the value if it's null so resource is taken if somebody returns the resource put it back to the map public synchronized static Object getSomeResource(Object parameter); public synchronized static void returnResource(Object parameter); getSomeResource (inside of the same process) could return null in 2 cases 1. if somebody (from other thread for example) already took that resource 2. if OS API said that resource corresponded to that parameter (serial port with parameter = 1 (port #)) is locked and unavailable; I'm not sure that in case of serial ports we even need those Parametric Singletons (unless lock checking is a very expensive operation) just ask the OS about availability of that resource and if it's available give it away and then OS will lock it and therefore in next time somebody ask it just answer that resource is locked and return null for example system has 2 serial ports available so I ask getResource("tty"); or I ask getResource("Bluetooth-Modem"); and if OS is ok you can give tty or Bluetooth-Modem or both no need for any additional pattern I think back to the problem mac os x doesn't recognize locking via files, so it handles locking via some API an instance of the singleton in each process should recognize that resource is locked (by using that API) that's all we don't have to make things more complicate then they are just because there is some nice design pattern or nice unit test framework or whatever keep things simple, make them work fast, don't introduce middle layers unless you have really good reason to do so of course I could be entirely wrong, so sorry about that in advance thanks Dmitry Markman From tjarvi at qbang.org Wed Mar 22 22:31:41 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 22 Mar 2006 22:31:41 -0700 (MST) Subject: [Rxtx] sole of a new design pattern In-Reply-To: References: Message-ID: Hi Doug Interesting reading. So far I'm just reading and thinking. I have one question so far. " Clients obtain a reference to a Parametric Singleton instance only through the parametric singleton design pattern. If the instance is left in an improper state (e.g., the serial port was left open) it is NOT the role of the Parametric Singleton Design Pattern to close the IO port. Nor is it the role of the Parametric Singleton Design Pattern to open the port. That role is delegate to some other part of the system. " So when the clients obtain a reference to the singleton, can they assume the port is there? IE, would it be the singletons role to handle things like USB dongles being removed with event hints comming from the underlying OS. Hardware abstraction layer/HAL on Linux is an example of underlying OS events. I assume that role too is delegated to other parts of the system? -- Trent Jarvi tjarvi at qbang.org From lyon at docjava.com Thu Mar 23 08:10:33 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Thu, 23 Mar 2006 10:10:33 -0500 Subject: [Rxtx] Classes don't need goals, they need roles! In-Reply-To: References: Message-ID: Hi Trent, Yes, I think that the role of the Parametric Singleton Pattern is not to open or close serial ports, nor is it to perform error checking. On the other hand, if you were to combine the role of the Parametric Singleton Pattern with another role (like that of error checking) it might not be amiss. However, I generally caution programmers against adding multiple roles to classes, as this leads to monolithic designs. Thus a different class (NativeLibDetect) could have the role of determining if the native library can be loaded. Another class (SerialPortBean) can have the role of serializing the default state of the serial port, so that it can be recovered, from user preferences, at a later time. The SerialPortDetect could have the role of determining if the serial port is removed (i.e., a USB port was unplugged). My guess is that each class should have a different role in the system, in order to ease maintenance and testing...but I could be wrong about that. Thanks! - Doug >Hi Doug > >Interesting reading. So far I'm just reading and thinking. I have >one question so far. > >" > Clients obtain a reference to a Parametric Singleton instance only >through the parametric singleton design pattern. If the instance is >left in an improper state (e.g., the serial port was left open) it is >NOT the role of the Parametric Singleton Design Pattern to close the >IO port. Nor is it the role of the Parametric Singleton Design Pattern >to >open the port. That role is delegate to some other part of the system. >" > >So when the clients obtain a reference to the singleton, can they >assume the port is there? IE, would it be the singletons role to >handle things like USB dongles being removed with event hints >comming from the underlying OS. Hardware abstraction layer/HAL on >Linux is an example of underlying OS events. > >I assume that role too is delegated to other parts of the system? > >-- >Trent Jarvi >tjarvi at qbang.org >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From maximulo at yahoo.com Fri Mar 24 01:22:38 2006 From: maximulo at yahoo.com (Maximulo Majir) Date: Fri, 24 Mar 2006 00:22:38 -0800 (PST) Subject: [Rxtx] JavaPOS Message-ID: <20060324082238.66371.qmail@web38214.mail.mud.yahoo.com> Hi all! Hello Trent! From what i understand, RXTX or JavaComm APIs were not created solely for JavaPOS. In JavaPOS, we have the virtual method claim() which is separate from open(), but in our RXTX API, claiming is done every call to open(), we cant open the port if its claimed by another application. Would it be alright to suggest or ask to create a new method called claim(..)? Is there such thing as forceclaim() in RXTX? this could be the same as portownership transfer or its equivalent. ForceClaim is in JSR80. Do you have some samples using RXTX as the lower layer for the Device Service Objects in JavaPOS? I have tried it, i just want to compare. Thank you all! maxim __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060324/496adba2/attachment-0017.html From tjarvi at qbang.org Fri Mar 24 11:28:19 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 24 Mar 2006 11:28:19 -0700 (MST) Subject: [Rxtx] Re: RXTX 2.1 Solaris Problems In-Reply-To: <3691.1143210578@www045.gmx.net> References: <3691.1143210578@www045.gmx.net> Message-ID: On Fri, 24 Mar 2006, Andreas Guenther wrote: > Hi all, > > the solaris problem was not the lock file only. > > Ok, I had to create the directory /var/spool/locks myself. > /var/spool/uucp exists. > > But rxtx didn't find any port. > > I compiled the source with my own debug-informations > and I tried to isolate the problem. > > The problem is the testRead-call in SerialImp.c > > JNIEXPORT jboolean JNICALL RXTXCommDriver(testRead)( > > ... > if ( READ( fd, &c, 1 ) < 0 ) > { > if ( errno != EAGAIN ) { > report( "testRead() read failed\n" ); > ret = JNI_FALSE; > } > } > Thanks Andreas I'm packing up to move. I'll be more or less away for a couple weeks here. I'll be checking email but my workstation is going into a box soon. This isn't hard to fix as this port should be enumerated when EWOULDBLOCK is recieved. Thats error is OK for enumeration just as EAGAIN is. I've put the bug into bugzilla so we dont forget to get to it. http://bugzilla.qbang.org/show_bug.cgi?id=42 You can add yourself to the CC list if you wish to test fixes we provide or even put a patch into bugzilla yourself. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Fri Mar 24 11:51:52 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 24 Mar 2006 11:51:52 -0700 (MST) Subject: [Rxtx] JavaPOS In-Reply-To: <20060324082238.66371.qmail@web38214.mail.mud.yahoo.com> References: <20060324082238.66371.qmail@web38214.mail.mud.yahoo.com> Message-ID: On Fri, 24 Mar 2006, Maximulo Majir wrote: > Hi all! Hello Trent! > > > From what i understand, RXTX or JavaComm APIs were not > created solely for JavaPOS. In JavaPOS, we have the virtual method > claim() which is separate from open(), but in our RXTX API, claiming is > done every call to open(), we cant open the port if its claimed by > another application. Would it be alright to suggest or ask to create a > new method called claim(..)? Is there such thing as forceclaim() in > RXTX? this could be the same as portownership transfer or its > equivalent. ForceClaim is in JSR80. > Do you have some samples using RXTX as the lower layer for the Device > Service Objects in JavaPOS? I have tried it, i just want to compare. > maxim Hi Maxim JSR80 is the USB API IBM/Sun put together. The problem is they have a richer kernel/API underneath that can handle such things. With Serial Ports, there isnt anything there other than an ioctl that says don't let anyone touch this and lockfiles that are more of a 'lets be nice.' At times we may be using USB ports but it is through the termios layer with the limitations mentioned. The advantage is that not only USB will work with rxtx. Anything that has a termios layer should work (to the extent that termios layer is complete). I don't know how forceclaim() would help you. Lets say someone has a programmer working on /dev/ttyS0 and you take it. Now you both race each other to read data first. There isn't a mechanism I know of that will solve this problem in termios. The most obvious test being a native app and a Java app trying to take the port. There is the potential of requestion ownership from other Java Applications but the use for that is very rare. Did you have something more specific in mind that I'm missing? I'm not sure that claim() and forceclaim() would help you with rxtx other than maybe locking the port with claim() without opening it. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sat Mar 25 23:42:08 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 25 Mar 2006 23:42:08 -0700 (MST) Subject: [Rxtx] Serial snoop Message-ID: I was reading the Linux kernel mail-list tonight and ran past a thread that mentioned sersnoop. This looks like a handy tool for people dealing with new toys. "a simple command-line tool for linux that echoes bytes to and from any two serial ports, ptys, or network sockets, and prints all traffic to stdout, in hex and ascii." http://www.restivo.org/projects/sersnoop/ It works on Linux only at this time (debian package available). -- Trent Jarvi tjarvi at qbang.org From beat.arnet at gmail.com Sun Mar 26 07:32:35 2006 From: beat.arnet at gmail.com (Beat Arnet) Date: Sun, 26 Mar 2006 09:32:35 -0500 Subject: [Rxtx] Error 0x5 at /home/bob/foo/tar/rxtx-2.1-7/build/../src/termios.c(860): Access is, denied. Message-ID: <4426A603.80508@gmail.com> Dear all, When trying to open the serial port, I sometimes (not always) run into the following exception (when opening the serialPort): Error 0x5 at /home/bob/foo/tar/rxtx-2.1-7/build/../src/termios.c(860): Access is denied. java.lang.UnsatisfiedLinkError: native_psmisc_report_owner at gnu.io.CommPortIdentifier.native_psmisc_report_owner(Native Method) at gnu.io.CommPortIdentifier.open(CommPortIdentifier.java:354) at codeskin.tools.CLLoader.open(CLLoader.java:79) at codeskin.tools.C2000Programmer.run(C2000Programmer.java:220) at java.lang.Thread.run(Unknown Source) Is this the type of error where I should just try to open the port again, or can it be avoided? Regards, Beat From tjarvi at qbang.org Sun Mar 26 11:40:12 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 26 Mar 2006 11:40:12 -0700 (MST) Subject: [Rxtx] Error 0x5 at /home/bob/foo/tar/rxtx-2.1-7/build/../src/termios.c(860): Access is, denied. In-Reply-To: <4426A603.80508@gmail.com> References: <4426A603.80508@gmail.com> Message-ID: On Sun, 26 Mar 2006, Beat Arnet wrote: > Dear all, > > When trying to open the serial port, I sometimes (not always) run into > the following exception (when opening the serialPort): > > Error 0x5 at /home/bob/foo/tar/rxtx-2.1-7/build/../src/termios.c(860): > Access is > denied. > > java.lang.UnsatisfiedLinkError: native_psmisc_report_owner > at gnu.io.CommPortIdentifier.native_psmisc_report_owner(Native > Method) > at gnu.io.CommPortIdentifier.open(CommPortIdentifier.java:354) > at codeskin.tools.CLLoader.open(CLLoader.java:79) > at codeskin.tools.C2000Programmer.run(C2000Programmer.java:220) > at java.lang.Thread.run(Unknown Source) > > Is this the type of error where I should just try to open the port again, > or can it be avoided? > Hi Beat We did a second build of rxtx 2.1-7 to resolve that unsatisfied link error. It should work now. rxtx is trying to tell you it thinks someone else has the serial port open. You can try to open the port again but maybe you already have a copy of the program running when it happens? ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7r2.zip fixed build. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sun Mar 26 11:44:23 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 26 Mar 2006 11:44:23 -0700 (MST) Subject: [Rxtx] RXTX spec file (fwd) Message-ID: This is probably interesting for fedora/suse users. ---------- Forwarded message ---------- Date: Sun, 26 Mar 2006 16:25:45 +0200 To: taj at www.linux.org.uk Subject: RXTX spec file I send you this spec file which allows to create a RPM for Fedora 4, 5 (x86, x86_64) with Java Sun. -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: rxtx.spec Url: http://mailman.qbang.org/pipermail/rxtx/attachments/20060326/6c7b6af6/rxtx-0013.pl From tjarvi at qbang.org Sun Mar 26 23:42:59 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 26 Mar 2006 23:42:59 -0700 (MST) Subject: [Rxtx] Upcomming events. Message-ID: This Wednesday we will be announcing a new "Maintainer" for the rxtx project. The position is more like neutral leader. I wont be going away or doing less. This is just the right thing to do as it turns out the two people with CVS write access will be at the same company. We need a third and we need neutrality. The maintainer will have final say in any conflict and will try to be neutral. It will be open for discussion. Then we will do it :) I'll still do most of the footwork I do now. But. I'm falling behind. I should have gone through the mail-list and posted the next round of changes this weekend. I'm packing to move and its going so so - 13 years of toys collected. I suspect there will be a dead period on my part (a couple weeks) comming up. But if you get it on the mail-list, we will get it in if there are no objections. I may well not be reading the mail-list during this period as I look for a house and many other things. I hope everyone will help out. Thanks -- Trent Jarvi tjarvi at qbang.org From mahmoud_hadad at yahoo.com Sun Mar 26 07:31:19 2006 From: mahmoud_hadad at yahoo.com (ronan nick) Date: Sun, 26 Mar 2006 06:31:19 -0800 (PST) Subject: [Rxtx] a question about the COMM API Message-ID: <20060326143119.54919.qmail@web60014.mail.yahoo.com> hi, i was intrested in knowing how i can communicate with my internal modem using java? for example if i want to make a phone dialer application or a caller id application where should i be looking at? and as i understood the COMM API is for devices that is attached to the computer through serial ports. --------------------------------- New Yahoo! Messenger with Voice. Call regular phones from your PC and save big. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060326/ce8329f0/attachment-0015.html From dmarkman at mac.com Mon Mar 20 00:20:43 2006 From: dmarkman at mac.com (Dmitry Markman) Date: Mon, 20 Mar 2006 02:20:43 -0500 Subject: [Rxtx] Mac OS X RXTX java installer In-Reply-To: References: <07D0DE29-BA32-4CFE-B036-66BC6423D385@buechse.de> <441AE3E0.2030503@willicon.de> <12531986.1142622114996.JavaMail.dmarkman@mac.com> <441B2674.9010409@willicon.de> <13577405.1142634732776.JavaMail.dmarkman@mac.com> <441B4182.8010407@willicon.de> <92CD0D6C-5BE8-426E-A46D-99452059FF49@mac.com> <441BBB2D.8030305@willicon.de> <441C4088.5090905@willicon.de> Message-ID: <64BC1E23-FDDE-4CE6-8863-CFC881CBC224@mac.com> Hi all I put RXTX installer that will install everything (and will create / var/lock if necessary and add user to the uucp group) for mac os x from Java into the rxtx's CVS repository it could be easily modified to install files for any platform it uses Greg Guerin's AuthKit for authentication and authorization Greg released that kit under artistic license, so Trent, please take a look we, probably, can negotiate license with Greg if it's necessary Greg's AuthKit could be downloaded from http://www.amug.org/~glguerin/ sw/#authkit Michael Hall (mikehall at spacestar dot net) had a suggestion to make implementation of the jaas LoginModule based on Greg's AuthKit (his modification of the Greg's AuthKit could be found at http:// www.spacestar.net/users/mikehall/authkit.dmg) but Michael's AuthKitLoginModule does only half a job: it does authenticate but it can not run any external unix process in privileged mode (at least I wasn't able to do so) possible explanation could be found in conversation between Greg and Michael at Apple's java-dev list (look for archives) so I didn't use jaas API for rxtxinstaller I created folder MacOSX in the contrib folder comment 1. if you want to run that installer as standalone application all you need that RXTXInstaller.jar 2. if you want to use webstart you have to add Greg's libAuthKit.jnilib to the mac os x's resources in theory RXTXInstaller.jar doesn't need it, but there is a problem with loading libAuthKit.jnilib from webstart authkit uses loadLibrary method to load library and it failed (from webstart) for standalone application I extract libAuthKit.jnilib from the RXTXInstaller.jar and put it into the /Library/Java/Extensions or ~/Library/Java/Extensions folder that file will be deleted after installer quit unfortunately I didn't have time to put documentation there but it is mostly self-explanatory I took installer code from my gl4java installer that I did about 3 years ago (with small modifications) it would be very nice if Apple will release LoginModule that really will do the job (com.apple.security.auth.module package????? ) (UnixLoginModule is pretty useless) From lyon at docjava.com Mon Mar 20 06:34:39 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Mon, 20 Mar 2006 08:34:39 -0500 Subject: [Rxtx] Mac OS X RXTX java installer In-Reply-To: <64BC1E23-FDDE-4CE6-8863-CFC881CBC224@mac.com> References: <07D0DE29-BA32-4CFE-B036-66BC6423D385@buechse.de> <441AE3E0.2030503@willicon.de> <12531986.1142622114996.JavaMail.dmarkman@mac.com> <441B2674.9010409@willicon.de> <13577405.1142634732776.JavaMail.dmarkman@mac.com> <441B4182.8010407@willicon.de> <92CD0D6C-5BE8-426E-A46D-99452059FF49@mac.com> <441BBB2D.8030305@willicon.de> <441C4088.5090905@willicon.de> <64BC1E23-FDDE-4CE6-8863-CFC881CBC224@mac.com> Message-ID: Hi Dimitry, This sounds like great work. Just a couple of questions; After the check out of the CVS files, using: setenv CVSROOT :pserver:anonymous at cvs.milestonesolutions.com:/usr/local/cvsroot 53 8:28 setenv PASSWORD mousy 54 8:29 cvs login 55 8:29 cvs checkout rxtx-devel I cd'd over to: rxtx-devel/MACOSX_IDE And found: CVS/ CW/ ForPackageMaker/ PB/ Where is the installer? Thanks! - Doug From tjarvi at qbang.org Mon Mar 20 06:39:37 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 20 Mar 2006 06:39:37 -0700 (MST) Subject: [Rxtx] Mac OS X RXTX java installer In-Reply-To: References: <07D0DE29-BA32-4CFE-B036-66BC6423D385@buechse.de> <441AE3E0.2030503@willicon.de> <12531986.1142622114996.JavaMail.dmarkman@mac.com> <441B2674.9010409@willicon.de> <13577405.1142634732776.JavaMail.dmarkman@mac.com> <441B4182.8010407@willicon.de> <92CD0D6C-5BE8-426E-A46D-99452059FF49@mac.com> <441BBB2D.8030305@willicon.de> <441C4088.5090905@willicon.de> <64BC1E23-FDDE-4CE6-8863-CFC881CBC224@mac.com> Message-ID: On Mon, 20 Mar 2006, Dr. Douglas Lyon wrote: > Hi Dimitry, > This sounds like great work. Just a couple of questions; > After the check out of the CVS files, using: > setenv CVSROOT > :pserver:anonymous at cvs.milestonesolutions.com:/usr/local/cvsroot > 53 8:28 setenv PASSWORD mousy > 54 8:29 cvs login > 55 8:29 cvs checkout rxtx-devel Hi Doug You want "cvs checkout -r commapi-0-0-1 rxtx-devel" to get RXTX 2.1 The default branch is rxtx 2.0 which isn't very active right now. -- Trent Jarvi tjarvi at qbang.org From lyon at docjava.com Mon Mar 20 07:05:44 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Mon, 20 Mar 2006 09:05:44 -0500 Subject: [Rxtx] Mac OS X RXTX java installer In-Reply-To: References: <07D0DE29-BA32-4CFE-B036-66BC6423D385@buechse.de> <441AE3E0.2030503@willicon.de> <12531986.1142622114996.JavaMail.dmarkman@mac.com> <441B2674.9010409@willicon.de> <13577405.1142634732776.JavaMail.dmarkman@mac.com> <441B4182.8010407@willicon.de> <92CD0D6C-5BE8-426E-A46D-99452059FF49@mac.com> <441BBB2D.8030305@willicon.de> <441C4088.5090905@willicon.de> <64BC1E23-FDDE-4CE6-8863-CFC881CBC224@mac.com> Message-ID: Hi Trent, Thanks for the info on the CVS checkout procedure. I did that and am still not sure where the installer is. Here is what I have: cd MACOSX_IDE/ p4.docjava.com{lyon}121: ls CVS/ ForPackageMaker/ PB/ p4.docjava.com{lyon}122: find . | more . ./ForPackageMaker ./ForPackageMaker/RXTX.pkg.sit.hqx ./ForPackageMaker/Resources ./ForPackageMaker/Resources/ReadMe.rtf ./ForPackageMaker/Resources/Welcome.rtf ./ForPackageMaker/Resources/CVS ./ForPackageMaker/Resources/CVS/Entries ./ForPackageMaker/Resources/CVS/Repository ./ForPackageMaker/Resources/CVS/Tag ./ForPackageMaker/Resources/CVS/Root ./ForPackageMaker/Resources/preinstall ./ForPackageMaker/Resources/License.rtf ./ForPackageMaker/Resources/preupgrade ./ForPackageMaker/RXTX.pmsp ./ForPackageMaker/CVS ./ForPackageMaker/CVS/Entries ./ForPackageMaker/CVS/Repository ./ForPackageMaker/CVS/Entries.Log ./ForPackageMaker/CVS/Tag ./ForPackageMaker/CVS/Root ./ForPackageMaker/RXTX_Tiger.pkg.sitx.hqx ./ForPackageMaker/RXTX_Jag.pkg.sit.hqx ./ForPackageMaker/Install ./ForPackageMaker/Install/CVS ./ForPackageMaker/Install/CVS/Entries ./ForPackageMaker/Install/CVS/Repository ./ForPackageMaker/Install/CVS/Tag ./ForPackageMaker/Install/CVS/Root ./ForPackageMaker/Install/Library ./ForPackageMaker/Install/Library/CVS ./ForPackageMaker/Install/Library/CVS/Entries ./ForPackageMaker/Install/Library/CVS/Repository ./ForPackageMaker/Install/Library/CVS/Tag ./ForPackageMaker/Install/Library/CVS/Root ./ForPackageMaker/Install/Library/Java ./ForPackageMaker/Install/Library/Java/Extensions ./ForPackageMaker/Install/Library/Java/Extensions/RXTXcomm.jar ./ForPackageMaker/Install/Library/Java/Extensions/CVS ./ForPackageMaker/Install/Library/Java/Extensions/CVS/Entries ./ForPackageMaker/Install/Library/Java/Extensions/CVS/Repository ./ForPackageMaker/Install/Library/Java/Extensions/CVS/Tag ./ForPackageMaker/Install/Library/Java/Extensions/CVS/Root ./ForPackageMaker/Install/Library/Java/Extensions/librxtxSerial.jnilib ./ForPackageMaker/Install/Library/Java/CVS ./ForPackageMaker/Install/Library/Java/CVS/Entries ./ForPackageMaker/Install/Library/Java/CVS/Repository ./ForPackageMaker/Install/Library/Java/CVS/Entries.Log ./ForPackageMaker/Install/Library/Java/CVS/Tag ./ForPackageMaker/Install/Library/Java/CVS/Root ./ForPackageMaker/RXTX_Tiger.pmproj.sitx.hqx ./CVS ./CVS/Entries ./CVS/Repository ./CVS/Entries.Log ./CVS/Tag ./CVS/Root ./PB ./PB/LibSerialUniversal.xcodeproj.sitx.hqx ./PB/CVS ./PB/CVS/Entries ./PB/CVS/Repository ./PB/CVS/Entries.Log ./PB/CVS/Tag ./PB/CVS/Root ./PB/LibSerial.pbproj.sit.hqx ./PB/startpoint.c ./PB/config.h What is the procedure to run this installer? Do we need a README in: /rxtx-devel/MACOSX_IDE Here is what we have: CVS/ ForPackageMaker/ PB/ Thanks! - DL >On Mon, 20 Mar 2006, Dr. Douglas Lyon wrote: > >>Hi Dimitry, >>This sounds like great work. Just a couple of questions; >>After the check out of the CVS files, using: >>setenv CVSROOT >>:pserver:anonymous at cvs.milestonesolutions.com:/usr/local/cvsroot >> 53 8:28 setenv PASSWORD mousy >> 54 8:29 cvs login >> 55 8:29 cvs checkout rxtx-devel > >Hi Doug > >You want "cvs checkout -r commapi-0-0-1 rxtx-devel" to get RXTX 2.1 >The default branch is rxtx 2.0 which isn't very active right now. > >-- >Trent Jarvi >tjarvi at qbang.org From tjarvi at qbang.org Mon Mar 20 07:25:30 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 20 Mar 2006 07:25:30 -0700 (MST) Subject: [Rxtx] Mac OS X RXTX java installer In-Reply-To: References: <07D0DE29-BA32-4CFE-B036-66BC6423D385@buechse.de> <441AE3E0.2030503@willicon.de> <12531986.1142622114996.JavaMail.dmarkman@mac.com> <441B2674.9010409@willicon.de> <13577405.1142634732776.JavaMail.dmarkman@mac.com> <441B4182.8010407@willicon.de> <92CD0D6C-5BE8-426E-A46D-99452059FF49@mac.com> <441BBB2D.8030305@willicon.de> <441C4088.5090905@willicon.de> <64BC1E23-FDDE-4CE6-8863-CFC881CBC224@mac.com> Message-ID: On Mon, 20 Mar 2006, Dr. Douglas Lyon wrote: > Hi Trent, > Thanks for the info on the CVS checkout procedure. > I did that and am still not sure where the installer is. Hi Doug It does look like it was not cvs committed. There is no rxtx-devel/contrib/MacOSX directory in there at the moment. It was mentioned that it was put under contrib. -- Trent Jarvi tjarvi at qbang.org From dmarkman at mac.com Mon Mar 20 07:29:56 2006 From: dmarkman at mac.com (Dmitry Markman) Date: Mon, 20 Mar 2006 09:29:56 -0500 Subject: [Rxtx] Mac OS X RXTX java installer In-Reply-To: References: <07D0DE29-BA32-4CFE-B036-66BC6423D385@buechse.de> <441AE3E0.2030503@willicon.de> <12531986.1142622114996.JavaMail.dmarkman@mac.com> <441B2674.9010409@willicon.de> <13577405.1142634732776.JavaMail.dmarkman@mac.com> <441B4182.8010407@willicon.de> <92CD0D6C-5BE8-426E-A46D-99452059FF49@mac.com> <441BBB2D.8030305@willicon.de> <441C4088.5090905@willicon.de> <64BC1E23-FDDE-4CE6-8863-CFC881CBC224@mac.com> Message-ID: <6054EB4E-F7E0-4A9C-BDDA-D582D6D8826F@mac.com> you can find it in the rxtx-devel/contrib folder On Mar 20, 2006, at 9:05 AM, Dr. Douglas Lyon wrote: > Hi Trent, > Thanks for the info on the CVS checkout procedure. > I did that and am still not sure where the installer is. > Here is what I have: > cd MACOSX_IDE/ > p4.docjava.com{lyon}121: ls > CVS/ ForPackageMaker/ PB/ > p4.docjava.com{lyon}122: find . | more > . > ./ForPackageMaker > ./ForPackageMaker/RXTX.pkg.sit.hqx > ./ForPackageMaker/Resources > ./ForPackageMaker/Resources/ReadMe.rtf > ./ForPackageMaker/Resources/Welcome.rtf > ./ForPackageMaker/Resources/CVS > ./ForPackageMaker/Resources/CVS/Entries > ./ForPackageMaker/Resources/CVS/Repository > ./ForPackageMaker/Resources/CVS/Tag > ./ForPackageMaker/Resources/CVS/Root > ./ForPackageMaker/Resources/preinstall > ./ForPackageMaker/Resources/License.rtf > ./ForPackageMaker/Resources/preupgrade > ./ForPackageMaker/RXTX.pmsp > ./ForPackageMaker/CVS > ./ForPackageMaker/CVS/Entries > ./ForPackageMaker/CVS/Repository > ./ForPackageMaker/CVS/Entries.Log > ./ForPackageMaker/CVS/Tag > ./ForPackageMaker/CVS/Root > ./ForPackageMaker/RXTX_Tiger.pkg.sitx.hqx > ./ForPackageMaker/RXTX_Jag.pkg.sit.hqx > ./ForPackageMaker/Install > ./ForPackageMaker/Install/CVS > ./ForPackageMaker/Install/CVS/Entries > ./ForPackageMaker/Install/CVS/Repository > ./ForPackageMaker/Install/CVS/Tag > ./ForPackageMaker/Install/CVS/Root > ./ForPackageMaker/Install/Library > ./ForPackageMaker/Install/Library/CVS > ./ForPackageMaker/Install/Library/CVS/Entries > ./ForPackageMaker/Install/Library/CVS/Repository > ./ForPackageMaker/Install/Library/CVS/Tag > ./ForPackageMaker/Install/Library/CVS/Root > ./ForPackageMaker/Install/Library/Java > ./ForPackageMaker/Install/Library/Java/Extensions > ./ForPackageMaker/Install/Library/Java/Extensions/RXTXcomm.jar > ./ForPackageMaker/Install/Library/Java/Extensions/CVS > ./ForPackageMaker/Install/Library/Java/Extensions/CVS/Entries > ./ForPackageMaker/Install/Library/Java/Extensions/CVS/Repository > ./ForPackageMaker/Install/Library/Java/Extensions/CVS/Tag > ./ForPackageMaker/Install/Library/Java/Extensions/CVS/Root > ./ForPackageMaker/Install/Library/Java/Extensions/librxtxSerial.jnilib > ./ForPackageMaker/Install/Library/Java/CVS > ./ForPackageMaker/Install/Library/Java/CVS/Entries > ./ForPackageMaker/Install/Library/Java/CVS/Repository > ./ForPackageMaker/Install/Library/Java/CVS/Entries.Log > ./ForPackageMaker/Install/Library/Java/CVS/Tag > ./ForPackageMaker/Install/Library/Java/CVS/Root > ./ForPackageMaker/RXTX_Tiger.pmproj.sitx.hqx > ./CVS > ./CVS/Entries > ./CVS/Repository > ./CVS/Entries.Log > ./CVS/Tag > ./CVS/Root > ./PB > ./PB/LibSerialUniversal.xcodeproj.sitx.hqx > ./PB/CVS > ./PB/CVS/Entries > ./PB/CVS/Repository > ./PB/CVS/Entries.Log > ./PB/CVS/Tag > ./PB/CVS/Root > ./PB/LibSerial.pbproj.sit.hqx > ./PB/startpoint.c > ./PB/config.h > > What is the procedure to run this installer? > Do we need a README in: > /rxtx-devel/MACOSX_IDE > Here is what we have: > CVS/ ForPackageMaker/ PB/ > > > Thanks! > - DL > >> On Mon, 20 Mar 2006, Dr. Douglas Lyon wrote: >> >>> Hi Dimitry, >>> This sounds like great work. Just a couple of questions; >>> After the check out of the CVS files, using: >>> setenv CVSROOT :pserver:anonymous at cvs.milestonesolutions.com:/usr/ >>> local/cvsroot >>> 53 8:28 setenv PASSWORD mousy >>> 54 8:29 cvs login >>> 55 8:29 cvs checkout rxtx-devel >> >> Hi Doug >> >> You want "cvs checkout -r commapi-0-0-1 rxtx-devel" to get RXTX 2.1 >> The default branch is rxtx 2.0 which isn't very active right now. >> >> -- >> Trent Jarvi >> tjarvi at qbang.org > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx Dmitry Markman From mikehall at spacestar.net Mon Mar 20 05:25:25 2006 From: mikehall at spacestar.net (Michael Hall) Date: Mon, 20 Mar 2006 06:25:25 -0600 Subject: [Rxtx] Re: Mac OS X RXTX java installer In-Reply-To: <64BC1E23-FDDE-4CE6-8863-CFC881CBC224@mac.com> References: <07D0DE29-BA32-4CFE-B036-66BC6423D385@buechse.de> <441AE3E0.2030503@willicon.de> <12531986.1142622114996.JavaMail.dmarkman@mac.com> <441B2674.9010409@willicon.de> <13577405.1142634732776.JavaMail.dmarkman@mac.com> <441B4182.8010407@willicon.de> <92CD0D6C-5BE8-426E-A46D-99452059FF49@mac.com> <441BBB2D.8030305@willicon.de> <441C4088.5090905@willicon.de> <64BC1E23-FDDE-4CE6-8863-CFC881CBC224@mac.com> Message-ID: <247EB61F-5CD1-4132-89A2-FC105B6CF9A5@spacestar.net> On Mar 20, 2006, at 1:20 AM, Dmitry Markman wrote: > > Michael Hall (mikehall at spacestar dot net) had a suggestion to > make implementation of the jaas LoginModule > based on Greg's AuthKit > (his modification of the Greg's AuthKit could be found at http:// > www.spacestar.net/users/mikehall/authkit.dmg) > but Michael's AuthKitLoginModule does only half a job: > it does authenticate > but it can not run any external unix process in privileged mode (at > least I wasn't able to do so) If you got it working directly with Greg's the point is moot. But to clarify it anyhow. The login module does not allow you to do anything anything privileged on return as was explained by Greg. You need to work with a separate privileged process using the execPrivileged method of his API. I assume you did something similar although I haven't looked at how you are using it yet. I allowed instead for a action to be performed at the same time you login/authenticate,this... System.setProperty("authkit.action","/usr/bin/id"); just before this... lc.login(); To clarify, safely ignored as you are already complete. Mike Hall mikehall at spacestar dot net http://www.spacestar.net/users/mikehall http://sourceforge.net/projects/macnative -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2427 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20060320/f6e18202/smime-0018.bin From dmarkman at mac.com Mon Mar 20 07:36:47 2006 From: dmarkman at mac.com (Dmitry Markman) Date: Mon, 20 Mar 2006 09:36:47 -0500 Subject: [Rxtx] Re: Mac OS X RXTX java installer In-Reply-To: <247EB61F-5CD1-4132-89A2-FC105B6CF9A5@spacestar.net> References: <07D0DE29-BA32-4CFE-B036-66BC6423D385@buechse.de> <441AE3E0.2030503@willicon.de> <12531986.1142622114996.JavaMail.dmarkman@mac.com> <441B2674.9010409@willicon.de> <13577405.1142634732776.JavaMail.dmarkman@mac.com> <441B4182.8010407@willicon.de> <92CD0D6C-5BE8-426E-A46D-99452059FF49@mac.com> <441BBB2D.8030305@willicon.de> <441C4088.5090905@willicon.de> <64BC1E23-FDDE-4CE6-8863-CFC881CBC224@mac.com> <247EB61F-5CD1-4132-89A2-FC105B6CF9A5@spacestar.net> Message-ID: Hi, Michael all I have to do is to run some shell script I tried to use your action mechanism and it worked great so I just System.setProperty ("authkit.action","" ) and after that I even don't need to run anything like subject.doAs.... but after few thoughts I choose to use plain Greg's approach, because in that case I don't have to deal with various java's configurations files and therefore to use 2-3 -D parameters in the java command line especially it's useful for java web start (it's so fragile :-( ) thanks for the great job On Mar 20, 2006, at 7:25 AM, Michael Hall wrote: > > On Mar 20, 2006, at 1:20 AM, Dmitry Markman wrote: >> >> Michael Hall (mikehall at spacestar dot net) had a suggestion to >> make implementation of the jaas LoginModule >> based on Greg's AuthKit >> (his modification of the Greg's AuthKit could be found at http:// >> www.spacestar.net/users/mikehall/authkit.dmg) >> but Michael's AuthKitLoginModule does only half a job: >> it does authenticate >> but it can not run any external unix process in privileged mode >> (at least I wasn't able to do so) > > If you got it working directly with Greg's the point is moot. > > But to clarify it anyhow. > The login module does not allow you to do anything anything > privileged on return as was explained by Greg. You need to work > with a separate privileged process using the execPrivileged method > of his API. I assume you did something similar although I haven't > looked at how you are using it yet. > I allowed instead for a action to be performed at the same time you > login/authenticate,this... > System.setProperty("authkit.action","/usr/bin/id"); > just before this... > lc.login(); > To clarify, safely ignored as you are already complete. > > Mike Hall mikehall at spacestar dot net > http://www.spacestar.net/users/mikehall > http://sourceforge.net/projects/macnative > > > Dmitry Markman From dmarkman at mac.com Mon Mar 20 07:44:45 2006 From: dmarkman at mac.com (Dmitry Markman) Date: Mon, 20 Mar 2006 09:44:45 -0500 Subject: [Rxtx] Mac OS X RXTX java installer In-Reply-To: References: <07D0DE29-BA32-4CFE-B036-66BC6423D385@buechse.de> <441AE3E0.2030503@willicon.de> <12531986.1142622114996.JavaMail.dmarkman@mac.com> <441B2674.9010409@willicon.de> <13577405.1142634732776.JavaMail.dmarkman@mac.com> <441B4182.8010407@willicon.de> <92CD0D6C-5BE8-426E-A46D-99452059FF49@mac.com> <441BBB2D.8030305@willicon.de> <441C4088.5090905@willicon.de> <64BC1E23-FDDE-4CE6-8863-CFC881CBC224@mac.com> Message-ID: it's in the commapi-0-0-1 branch I tested it right now: cvs co -r commapi-0-0-1 rxtx-devel and I got everything On Mar 20, 2006, at 9:25 AM, Trent Jarvi wrote: > On Mon, 20 Mar 2006, Dr. Douglas Lyon wrote: > >> Hi Trent, >> Thanks for the info on the CVS checkout procedure. >> I did that and am still not sure where the installer is. > > Hi Doug > > It does look like it was not cvs committed. There is no rxtx-devel/ > contrib/MacOSX directory in there at the moment. It was mentioned > that it was put under contrib. > > -- > Trent Jarvi > tjarvi at qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx Dmitry Markman From tjarvi at qbang.org Mon Mar 20 07:52:57 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 20 Mar 2006 07:52:57 -0700 (MST) Subject: [Rxtx] Mac OS X RXTX java installer In-Reply-To: References: <07D0DE29-BA32-4CFE-B036-66BC6423D385@buechse.de> <441AE3E0.2030503@willicon.de> <12531986.1142622114996.JavaMail.dmarkman@mac.com> <441B2674.9010409@willicon.de> <13577405.1142634732776.JavaMail.dmarkman@mac.com> <441B4182.8010407@willicon.de> <92CD0D6C-5BE8-426E-A46D-99452059FF49@mac.com> <441BBB2D.8030305@willicon.de> <441C4088.5090905@willicon.de> <64BC1E23-FDDE-4CE6-8863-CFC881CBC224@mac.com> Message-ID: On Mon, 20 Mar 2006, Dmitry Markman wrote: > it's in the commapi-0-0-1 branch > > I tested it right now: > cvs co -r commapi-0-0-1 rxtx-devel > > and I got everything > A fresh checkout worked. Here is a copy of the tree (just the installer bits) ftp://ftp.qbang.org/pub/rxtx/MacOSX-installer.zip -- Trent Jarvi tjarvi at qbang.org From lyon at docjava.com Mon Mar 20 08:08:26 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Mon, 20 Mar 2006 10:08:26 -0500 Subject: [Rxtx] Mac OS X RXTX java installer In-Reply-To: References: <07D0DE29-BA32-4CFE-B036-66BC6423D385@buechse.de> <441AE3E0.2030503@willicon.de> <12531986.1142622114996.JavaMail.dmarkman@mac.com> <441B2674.9010409@willicon.de> <13577405.1142634732776.JavaMail.dmarkman@mac.com> <441B4182.8010407@willicon.de> <92CD0D6C-5BE8-426E-A46D-99452059FF49@mac.com> <441BBB2D.8030305@willicon.de> <441C4088.5090905@willicon.de> <64BC1E23-FDDE-4CE6-8863-CFC881CBC224@mac.com> Message-ID: Hi All, Is the Auth package able to work properly on non Mac OS's? It was not clear from the doc or download. Thanks! - Doug From dmarkman at mac.com Mon Mar 20 08:15:22 2006 From: dmarkman at mac.com (Dmitry Markman) Date: Mon, 20 Mar 2006 10:15:22 -0500 Subject: [Rxtx] Mac OS X RXTX java installer In-Reply-To: References: <07D0DE29-BA32-4CFE-B036-66BC6423D385@buechse.de> <441AE3E0.2030503@willicon.de> <12531986.1142622114996.JavaMail.dmarkman@mac.com> <441B2674.9010409@willicon.de> <13577405.1142634732776.JavaMail.dmarkman@mac.com> <441B4182.8010407@willicon.de> <92CD0D6C-5BE8-426E-A46D-99452059FF49@mac.com> <441BBB2D.8030305@willicon.de> <441C4088.5090905@willicon.de> <64BC1E23-FDDE-4CE6-8863-CFC881CBC224@mac.com> Message-ID: <217312D8-CCCA-4859-ABA6-32DF1CC817B9@mac.com> thanks Trent, for putting it on ftp server On Mar 20, 2006, at 9:52 AM, Trent Jarvi wrote: > A fresh checkout worked. Here is a copy of the tree (just the > installer bits) > > ftp://ftp.qbang.org/pub/rxtx/MacOSX-installer.zip > Dmitry Markman From dmarkman at mac.com Mon Mar 20 09:14:03 2006 From: dmarkman at mac.com (Dmitry Markman) Date: Mon, 20 Mar 2006 11:14:03 -0500 Subject: [Rxtx] Mac OS X RXTX java installer In-Reply-To: References: <07D0DE29-BA32-4CFE-B036-66BC6423D385@buechse.de> <441AE3E0.2030503@willicon.de> <12531986.1142622114996.JavaMail.dmarkman@mac.com> <441B2674.9010409@willicon.de> <13577405.1142634732776.JavaMail.dmarkman@mac.com> <441B4182.8010407@willicon.de> <92CD0D6C-5BE8-426E-A46D-99452059FF49@mac.com> <441BBB2D.8030305@willicon.de> <441C4088.5090905@willicon.de> <64BC1E23-FDDE-4CE6-8863-CFC881CBC224@mac.com> Message-ID: <4DEBA6F0-DA45-4E84-823E-1F1AC48BDCCC@mac.com> no it will work only on mac os x however it's harmless to run it on other platform if you want to use it for other platform you have to do the following (I'll do it for linux) 1. modify RXTXInstaller class method public static RXTXInstaller getInstance() public static RXTXInstaller getInstance() { String osName = System.getProperty("os.name").toLowerCase(); if(osName.startsWith("mac")){ return new gnu.io.installer.macosx.MACOSXRXTXInstaller(); } else if(osName.startsWith("windows")){ return new gnu.io.installer.windows.WindowsRXTXInstaller(); }else if(osName.startsWith("linux")){ return new gnu.io.installer.linux.LinuxRXTXInstaller(); } return null; } 2. create folder gnu/io/installer/linux/ 3. create class Linux386RXTXInstaller package gnu.io.installer.linux; import java.io.File; public class Linux386RXTXInstaller extends gnu.io.installer.RXTXInstaller{ public Linux386RXTXInstaller(){ createJarFolder(); createLibFolder(); addJarResource("RXTXcomm.jar","/gnu/io/installer/resources/ linux/jar/RXTXcomm.dat"); addLibResource("librxtxSerial.so","/gnu/io/installer/ resources/linux/lib/librxtxSerial.so"); } protected void createJarFolder(){ String javaHome = System.getProperty("java.home"); char separator = File.separatorChar; jarFolder = new File(javaHome+separator+"lib"+separator+"ext"); } protected void createLibFolder(){ String javaHome = System.getProperty("java.home"); char separator = File.separatorChar; libFolder = new File(javaHome+separator+"bin"); } public void runPreProcess() {} //put here some action you need public void runPostProcess() {} //put here some action you need } 4. create folder /gnu/io/installer/resources/linux/jar and put there linux's version of RXTXcomm.dat (which is renamed RXTXcomm.jar) 5. create folder /gnu/io/installer/resources/linux/lib and put there linux's version of librxtxSerial. so 6. make sure that RXTXInstaller.jar has the following items: /gnu/io/installer/resources/linux/jar/RXTXcomm.jar /gnu/io/installer/resources/linux/lib/librxtxSerial.so 7. modify file installer.pref: jar file RXTXInstaller.jar must have the following item /gnu/io/installer/installer.pref that's basically it for windows you have to do the similar things: just replace linux to windows and librxtxSerial.so to rxtxSerial.dll and create appropriate gnu.io.installer.windows.WindowsRXTXInstaller class package gnu.io.installer.windows; import java.io.File; public class WindowsRXTXInstaller extends gnu.io.installer.RXTXInstaller{ public WindowsRXTXInstaller(){ createJarFolder(); createLibFolder(); addJarResource("RXTXcomm.jar","/gnu/io/installer/resources/ windows/jar/RXTXcomm.dat"); addLibResource("librxtxSerial.so","/gnu/io/installer/ resources/windows/lib/rxtxSerial.dll"); } protected void createJarFolder(){ String javaHome = System.getProperty("java.home"); char separator = File.separatorChar; jarFolder = new File(javaHome+separator+"lib"+separator+"ext"); } protected void createLibFolder(){ String javaHome = System.getProperty("java.home"); char separator = File.separatorChar; libFolder = new File(javaHome+separator+"bin"); } public void runPreProcess() {} //put here some action you need public void runPostProcess() {} //put here some action you need } installer.pref will look like On Mar 20, 2006, at 10:08 AM, Dr. Douglas Lyon wrote: > Hi All, > Is the Auth package able to work properly on > non Mac OS's? > It was not clear from the doc or download. > > Thanks! > - Doug > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx Dmitry Markman From joachim at buechse.de Mon Mar 20 10:49:06 2006 From: joachim at buechse.de (Joachim Buechse) Date: Mon, 20 Mar 2006 18:49:06 +0100 Subject: [Rxtx] BUG: Lock file stays even if port opening fails Message-ID: This was only tested on MacOSX but looking at the code, it should be true for all systems that use lock_uucp. I am opening a port which can not be opened (dialup port of a telephone paired via bluetooth but currently not reachable). The lock file is created and stays arround, even though the port open failed. After looking a bit through the code (of 2.17), I really wonder if it wouldn't be a good idea to make the "locking" an explicit operation called from the java code. This would certainly simplify the generation of meaningfull exceptions (and java based debugging). Maybe even the handling of "preopened" ports should be in the Java part of the lib (again for java based debugging puposes). That beeing said, I have no idea if this would be possible for the 2.07 implementation. Regards, Joachim From tjarvi at qbang.org Mon Mar 20 11:24:22 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 20 Mar 2006 11:24:22 -0700 (MST) Subject: [Rxtx] BUG: Lock file stays even if port opening fails In-Reply-To: References: Message-ID: On Mon, 20 Mar 2006, Joachim Buechse wrote: > This was only tested on MacOSX but looking at the code, it should be true > for all systems that use lock_uucp. > > I am opening a port which can not be opened (dialup port of a telephone > paired via bluetooth but currently not reachable). The lock file is > created and stays arround, even though the port open failed. > > > After looking a bit through the code (of 2.17), I really wonder if it > wouldn't be a good idea to make the "locking" an explicit operation > called from the java code. This would certainly simplify the generation > of meaningfull exceptions (and java based debugging). > Maybe even the handling of "preopened" ports should be in the Java part > of the lib (again for java based debugging puposes). That beeing said, I > have no idea if this would be possible for the 2.07 implementation. > > Regards, Hi Joachim It should be possible in the 2.0-7 implementation too. The calls to RXTXPort.java would not change. We would just do more there Moving more of that logic into Java would be better as many people don't like to look at C code. There is a liblockdev on most Linux distros that can do most of the C code and would be easier to use. The problem is embeded devices will not have that library. The preopened port code has not been really tested. That was a last minute request in a product cycle. I expect it will be tested this year though. As I recall, some devices really do not like CD raising on open. The preopened ports then allow people to mess around in java without power cycling the devices or losing data. -- Trent Jarvi tjarvi at qbang.org From joachim at buechse.de Mon Mar 20 12:01:08 2006 From: joachim at buechse.de (Joachim Buechse) Date: Mon, 20 Mar 2006 20:01:08 +0100 Subject: [Rxtx] BUG: Lock file stays even if port opening fails In-Reply-To: References: Message-ID: Hi Trent, What is your general feeling about moving code to Java? The last days I have been reading quite a bit of the code and there are several things, that might not work as expected. I'll give you two examples from is_device_locked: if LOCKDIR == /var/spool/locks the directory /var/spool/lock will not be checked. LOCKDIR is not checked for lockfiles with unexpected pefixes While these things have probably never been discovered in production, they are still possibly incorrect implementations. If it was Java code, I would write some unit tests producing the errors that could later be corrected. PS: One could imagine to actually implement the whole lockfile handling in Java using some native routines to get the values required (pid, st_dev, st_rdev, ...). On 20.03.2006, at 19:24, Trent Jarvi wrote: > On Mon, 20 Mar 2006, Joachim Buechse wrote: > >> This was only tested on MacOSX but looking at the code, it should >> be true for all systems that use lock_uucp. >> >> I am opening a port which can not be opened (dialup port of a >> telephone paired via bluetooth but currently not reachable). The >> lock file is created and stays arround, even though the port open >> failed. >> >> >> After looking a bit through the code (of 2.17), I really wonder if >> it wouldn't be a good idea to make the "locking" an explicit >> operation called from the java code. This would certainly simplify >> the generation of meaningfull exceptions (and java based debugging). >> Maybe even the handling of "preopened" ports should be in the Java >> part of the lib (again for java based debugging puposes). That >> beeing said, I have no idea if this would be possible for the 2.07 >> implementation. >> >> Regards, > > Hi Joachim > > It should be possible in the 2.0-7 implementation too. The calls > to RXTXPort.java would not change. We would just do more there > Moving more of that logic into Java would be better as many people > don't like to look at C code. There is a liblockdev on most Linux > distros that can do most of the C code and would be easier to use. > The problem is embeded devices will not have that library. > > The preopened port code has not been really tested. That was a > last minute request in a product cycle. I expect it will be tested > this year though. As I recall, some devices really do not like CD > raising on open. The preopened ports then allow people to mess > around in java without power cycling the devices or losing data. > > -- > Trent Jarvi > tjarvi at qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Mon Mar 20 12:21:02 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 20 Mar 2006 12:21:02 -0700 (MST) Subject: [Rxtx] BUG: Lock file stays even if port opening fails In-Reply-To: References: Message-ID: On Mon, 20 Mar 2006, Joachim Buechse wrote: > Hi Trent, > > What is your general feeling about moving code to Java? The last days I > have been reading quite a bit of the code and there are several things, > that might not work as expected. > > I'll give you two examples from is_device_locked: > > if LOCKDIR == /var/spool/locks the directory /var/spool/lock will not be > checked. > LOCKDIR is not checked for lockfiles with unexpected pefixes > > While these things have probably never been discovered in production, > they are still possibly incorrect implementations. If it was Java code, I > would write some unit tests producing the errors that could later be > corrected. > > PS: One could imagine to actually implement the whole lockfile handling > in Java using some native routines to get the values required (pid, > st_dev, st_rdev, ...). Hi Joachim I like the idea of moving more of the code into java but there are some things to consider. If you break this into multiple JNI calls, the performance will drop considerably during enumeration of ports. We are looking for 256 ports per dev type vs (16? in Sun's 2.0 and fewer types). Its hard to make assumptions. I've seen virtual ports start at /dev/foo100 for instance. It works out to over 7500 ports on Linux if you enable them all. We already trim that back by default. See Linux-all-ports in RXTXCommDriver.java. There are also native libraries that rxtx can link to. If you move too much into Java, linking to 'standard' libraries with distros will break. "configure --enable-liblock=yes" will not be doable. This is probably a favorable way with RedHat, Debian, Suse and others. Thats the right thing to do if there will be rpms, dpkg, .. For those reasons, I think it still make sense to keep it to a minimal ~3 calls to JNI code that we can use for speed and versatility. lock() isLocked(), unlock() perhaps. When I say speed, its more about avoiding crossing the JNI layer multiple times than java vs C performance. With versatility I think liblock is the right way for most but not all (embeded) linux distros. -- Trent Jarvi tjarvi at qbang.org From joachim at buechse.de Mon Mar 20 12:42:04 2006 From: joachim at buechse.de (Joachim Buechse) Date: Mon, 20 Mar 2006 20:42:04 +0100 Subject: [Rxtx] BUG: Lock file stays even if port opening fails In-Reply-To: References: Message-ID: <82C19FE7-DDCB-45B6-B2C9-7606B66F0124@buechse.de> Ok, what about providing a default implementation in Java? The RXTXCommDriver would call a (native) function useNativeLocking and if it returns true, call the native functions for lock() isLocked (), unlock(), else is would use the Java based default implementation. This could possibly be overriden by a property (again for debugging). Joachim On 20.03.2006, at 20:21, Trent Jarvi wrote: > On Mon, 20 Mar 2006, Joachim Buechse wrote: > >> Hi Trent, >> >> What is your general feeling about moving code to Java? The last >> days I have been reading quite a bit of the code and there are >> several things, that might not work as expected. >> >> I'll give you two examples from is_device_locked: >> >> if LOCKDIR == /var/spool/locks the directory /var/spool/lock will >> not be checked. >> LOCKDIR is not checked for lockfiles with unexpected pefixes >> >> While these things have probably never been discovered in >> production, they are still possibly incorrect implementations. If >> it was Java code, I would write some unit tests producing the >> errors that could later be corrected. >> >> PS: One could imagine to actually implement the whole lockfile >> handling in Java using some native routines to get the values >> required (pid, st_dev, st_rdev, ...). > > Hi Joachim > > I like the idea of moving more of the code into java but there are > some things to consider. > > If you break this into multiple JNI calls, the performance will > drop considerably during enumeration of ports. We are looking for > 256 ports per dev type vs (16? in Sun's 2.0 and fewer types). Its > hard to make assumptions. I've seen virtual ports start at /dev/ > foo100 for instance. > > It works out to over 7500 ports on Linux if you enable them all. > We already trim that back by default. See Linux-all-ports in > RXTXCommDriver.java. > > There are also native libraries that rxtx can link to. If you move > too much into Java, linking to 'standard' libraries with distros > will break. "configure --enable-liblock=yes" will not be doable. > This is probably a favorable way with RedHat, Debian, Suse and > others. Thats the right thing to do if there will be rpms, dpkg, .. > > For those reasons, I think it still make sense to keep it to a > minimal ~3 calls to JNI code that we can use for speed and > versatility. lock() isLocked(), unlock() perhaps. When I say > speed, its more about avoiding crossing the JNI layer multiple > times than java vs C performance. With versatility I think liblock > is the right way for most but not all (embeded) linux distros. > > -- > Trent Jarvi > tjarvi at qbang.org > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Mon Mar 20 12:44:47 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 20 Mar 2006 12:44:47 -0700 (MST) Subject: [Rxtx] BUG: Lock file stays even if port opening fails In-Reply-To: <82C19FE7-DDCB-45B6-B2C9-7606B66F0124@buechse.de> References: <82C19FE7-DDCB-45B6-B2C9-7606B66F0124@buechse.de> Message-ID: On Mon, 20 Mar 2006, Joachim Buechse wrote: > Ok, what about providing a default implementation in Java? > > The RXTXCommDriver would call a (native) function useNativeLocking and if > it returns true, call the native functions for lock() isLocked(), > unlock(), else is would use the Java based default implementation. This > could possibly be overriden by a property (again for debugging). > Hi Joachim That would be OK with me. -- Trent Jarvi tjarvi at qbang.org From dmarkman at mac.com Mon Mar 20 22:27:45 2006 From: dmarkman at mac.com (Dmitry Markman) Date: Tue, 21 Mar 2006 00:27:45 -0500 Subject: [Rxtx] binaries request Message-ID: <42702213-C222-4937-A585-7CFB17E47608@mac.com> Hi can somebody send me latest linux and windows binaries, please? or where I can find them (I didn't find them in the latest tareball) I gave up with my cygwin: something wrong I have no idea what java doesn't understand /cygwin/c syntax after I changed makefile it did java part but after that gcc 3.4.4 started to complain I set buffer length to 999 lines but I didn't get beginning of the story something wrong with my 1.4.2_09/include/jni.h gcc doesn't like it anyway I gave up thanks in advance Dmitry Markman -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060320/f8cbc57c/attachment-0018.html From tjarvi at qbang.org Mon Mar 20 22:36:48 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 20 Mar 2006 22:36:48 -0700 (MST) Subject: [Rxtx] binaries request In-Reply-To: <42702213-C222-4937-A585-7CFB17E47608@mac.com> References: <42702213-C222-4937-A585-7CFB17E47608@mac.com> Message-ID: On Tue, 21 Mar 2006, Dmitry Markman wrote: > Hi > can somebody send me latest linux and windows binaries, please? > > or where I can find them (I didn't find them in the latest tareball) > > I gave up with my cygwin: something wrong I have no idea what > java doesn't understand /cygwin/c syntax > after I changed makefile it did java part > but after that gcc 3.4.4 started to complain > I set buffer length to 999 lines but I didn't get beginning of the story > something wrong with my 1.4.2_09/include/jni.h gcc doesn't like it > anyway I gave up > > thanks in advance > Hi Dmitry The bins are here: ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7-bins-r2.zip Here are the files in the zip you want. Jar: rxtx-2.1-7-bins-r2/RXTXcomm.jar Windows: rxtx-2.1-7-bins-r2/Windows/i368-mingw32/rxtxSerial.dll Linux (x86) rxtx-2.1-7-bins-r2/Linux/i686-unknown-linux-gnu/librxtxSerial.so There are others in there including Parallel port support but those are the main ones for testing. -- Trent Jarvi tjarvi at qbang.org From dmarkman at mac.com Mon Mar 20 23:05:59 2006 From: dmarkman at mac.com (Dmitry Markman) Date: Tue, 21 Mar 2006 01:05:59 -0500 Subject: [Rxtx] binaries request In-Reply-To: References: <42702213-C222-4937-A585-7CFB17E47608@mac.com> Message-ID: thank you very much but windows's readme says: rxtxSerial.dll had to be recomopiled to link in missing native methods. should I ignore it? or what? thanks again also I understand that I should use mingw not cygwin I'll try to install mingw On Mar 21, 2006, at 12:36 AM, Trent Jarvi wrote: > On Tue, 21 Mar 2006, Dmitry Markman wrote: > >> Hi >> can somebody send me latest linux and windows binaries, please? >> >> or where I can find them (I didn't find them in the latest tareball) >> >> I gave up with my cygwin: something wrong I have no idea what >> java doesn't understand /cygwin/c syntax >> after I changed makefile it did java part >> but after that gcc 3.4.4 started to complain >> I set buffer length to 999 lines but I didn't get beginning of the >> story >> something wrong with my 1.4.2_09/include/jni.h gcc doesn't like it >> anyway I gave up >> >> thanks in advance >> > > Hi Dmitry > > The bins are here: > > ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7-bins-r2.zip > > Here are the files in the zip you want. > > Jar: > > rxtx-2.1-7-bins-r2/RXTXcomm.jar > > Windows: > > rxtx-2.1-7-bins-r2/Windows/i368-mingw32/rxtxSerial.dll > > Linux (x86) > > rxtx-2.1-7-bins-r2/Linux/i686-unknown-linux-gnu/librxtxSerial.so > > There are others in there including Parallel port support but those > are the main ones for testing. > > -- > Trent Jarvi > tjarvi at qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx Dmitry Markman From tjarvi at qbang.org Mon Mar 20 23:20:33 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 20 Mar 2006 23:20:33 -0700 (MST) Subject: [Rxtx] binaries request In-Reply-To: References: <42702213-C222-4937-A585-7CFB17E47608@mac.com> Message-ID: On Tue, 21 Mar 2006, Dmitry Markman wrote: > thank you very much > > but windows's readme says: > rxtxSerial.dll had to be recomopiled to link in missing native methods. > > should I ignore it? or what? > Hi Dmitry That dll should be OK. r2 is the recompile linked to the missing native method. The readme explains why it was recompiled; fuser.o was not linked into the dll in the first release. -- Trent Jarvi tjarvi at qbang.org From ariantristan at yahoo.com Mon Mar 20 23:55:24 2006 From: ariantristan at yahoo.com (Lambok Sianturi) Date: Mon, 20 Mar 2006 22:55:24 -0800 (PST) Subject: [Rxtx] jvm issue Message-ID: <20060321065524.94779.qmail@web50701.mail.yahoo.com> Hi All, This is my first time to join RxTx mailing list. I thank you all for allowing others to sign in in requests help. I use the latest RxTx lib in Fedora 3 with java version 1.4.2_09 b05. And I got this error: # # An unexpected error has been detected by HotSpot Virtual Machine: # # SIGSEGV (0xb) at pc=0x00bf27f3, pid=2633, tid=3086112448 # # Java VM: Java HotSpot(TM) Client VM (1.4.2_09-b05 mixed mode) # Problematic frame: # C [ld-linux.so.2+0xa7f3] # # An error report file with more information is saved as hs_err_pid2633.log # # If you would like to submit a bug report, please visit: # http://java.sun.com/webapps/bugreport/crash.jsp # ./run.sh: line 3: 2633 Aborted /usr/local/java/bin/java -Djava.library.path=/usr/local/java/jre/lib/ -Djsmsengine.debug=true -classpath jsmsengine.jar:smsgateway.jar:classes12.jar:RXTXcomm.jar:. com.api.sms.SMSServer What is the jvm depedency for the latest library? Can I use 1.4.2_09 b05? Thanks in advance. Arian --------------------------------- Yahoo! Mail Use Photomail to share photos without annoying attachments. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060320/83d58dd7/attachment-0018.html From f.frumento at ngi.it Tue Mar 21 00:21:47 2006 From: f.frumento at ngi.it (Fabio Frumento) Date: Tue, 21 Mar 2006 08:21:47 +0100 Subject: [Rxtx] Javadoc on the go Message-ID: <441FA98B.9050701@ngi.it> Hi Trent, sorry for the big delay but my job is running wild, i was out for some time but now i'm back and ready to continue the javadoc for Rxtx. Did you used the last javadoc patch i sent you ? let me know if i have to send it to you again or not. regards Fabio From lyon at docjava.com Tue Mar 21 00:51:18 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Tue, 21 Mar 2006 02:51:18 -0500 Subject: [Rxtx] lock files Message-ID: Hi All, You know, if the use of lock files were under Java control (rather than a build-time decision), it might enable a more unified binary distro. It might also facilitate quick prototyping of non-lock file approaches to resolving serial port contention issues (i.e., mac-like approaches vs. linux approaches, etc.). I realize that this is a radical overhaul of the lock file policy issue. Also, it may harm performance. On the other hand, our benchmarks on JNI overhead for modern processors indicate performance impact should be minimal. Perhaps it is more of an issue with the toybox systems. Suppose there were a class with a reasonable default...someone might write: SerialPortLockPolicy.setPolicy(SerialPortLockPolicy.UNIX_LOCK_FILE); SerialPortLockPolicy.setPolicy(SerialPortLockPolicy.NO_LOCK_CHECKING); SerialPortLockPolicy.setPolicy(SerialPortLockPolicy.MAC_STYLE); Thus, we could have a run-time reconfiguration of the serial port lock policy. A special NO_LOCK version of the binary would no longer be required. Any thoughts on this? Thanks! - Doug From joachim at buechse.de Tue Mar 21 03:09:09 2006 From: joachim at buechse.de (Joachim Buechse) Date: Tue, 21 Mar 2006 11:09:09 +0100 Subject: [Rxtx] lock files In-Reply-To: References: Message-ID: <8E12916A-1B9A-4FF2-B684-E2D1C794221B@buechse.de> This is pretty much what I thought about when I suggested, that the default behaviour could be overwritten with a property. I am very much in favor of this approach. In particular this allows much easier debugging for PC based java developers. I think big parts of the Java (and maybe some parts of the C code) could use a bit of a structural workover (unit tests, javadoc, synchronization, etc). Maybe there should be a CVS branch for this experimental version. I'd be happy to contribute a first workover for some of the Java code. Designing for testability and implementing a good bunch of unit tests has been a strategy that worked quite well in the Java projects I lead. And it ultimately allows more liberal change permission. Regards, Joachim On 21.03.2006, at 08:51, Dr. Douglas Lyon wrote: > Hi All, > You know, if the use of lock files were > under Java control (rather than a build-time decision), > it might enable a more unified binary distro. It might also > facilitate quick prototyping of non-lock file approaches > to resolving serial port contention issues (i.e., mac-like > approaches vs. linux approaches, etc.). > > I realize that this is a radical overhaul of the lock file policy > issue. Also, it may harm performance. On the other hand, > our benchmarks on JNI overhead for modern processors indicate > performance impact should be minimal. Perhaps it is more of > an issue with the toybox systems. > > Suppose there were a class with a reasonable default...someone > might write: > SerialPortLockPolicy.setPolicy(SerialPortLockPolicy.UNIX_LOCK_FILE); > SerialPortLockPolicy.setPolicy(SerialPortLockPolicy.NO_LOCK_CHECKING); > SerialPortLockPolicy.setPolicy(SerialPortLockPolicy.MAC_STYLE); > > Thus, we could have a run-time reconfiguration of the serial port lock > policy. A special NO_LOCK version of the binary would no longer > be required. > > Any thoughts on this? > > Thanks! > - Doug > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From joachim at buechse.de Tue Mar 21 06:23:08 2006 From: joachim at buechse.de (Joachim Buechse) Date: Tue, 21 Mar 2006 14:23:08 +0100 Subject: [Rxtx] PATCH: use of ioctl(fd, TIOCEXCL) instead of lockfiles Message-ID: <923AE774-EEA2-4911-92D8-32BB27802C8B@buechse.de> Here is the patch for the ioctl(fd, TIOCEXCL). I have verified this only for OSX 10.4.5, hence it is only defined for APPLE. However, it should work at least for Solaris as well. If a process has requested TIOEXCL further open calls by other user processes will fail. The patch also disables uucp style locking for APPLE. Obviously this is discussable. I think it is the way to go, as it eliminates creating the lock directory which doesnt exist on the standard installation and it eliminates messing with the system group definitions (adding users to group uucp). Regarding the possibility of root processes opening a device which is locked - I consider this a feature not a potential problem. It is highly unlikely, that somebody is crazy enough to run a JavaVM as root (unless he has no other means of getting a restricted IP port opened, ie doesnt understand ipfw). Anyway, even if the process runs as root, it fails when calling ioctl(fd, TIOCEXCL). It could however still open the port to listen for RING events. I.e. a fax server which needs to see incoming calls but otherwise doesnt want to block the port. So the only case where the proposed mechanism fails is, if an incorrectly implemented process running as root conflicts with a user process. I think this can be accepted. Regards, Joachim PS: If this patch is generally accepted, the installer and Mac doku should obviously be changed as well. Index: SerialImp.c =================================================================== RCS file: /usr/local/cvsroot/rxtx-devel/src/SerialImp.c,v retrieving revision 1.46.2.187 diff -u -r1.46.2.187 SerialImp.c --- SerialImp.c 29 Jan 2006 22:19:04 -0000 1.46.2.187 +++ SerialImp.c 21 Mar 2006 12:59:16 -0000 @@ -656,6 +656,25 @@ fd=OPEN (filename, O_RDWR | O_NOCTTY | O_NONBLOCK ); } while (fd < 0 && errno==EINTR); +#ifdef OPEN_EXCL + // Note that open() follows POSIX semantics: multiple open() calls to + // the same file will succeed unless the TIOCEXCL ioctl is issued. + // This will prevent additional opens except by root-owned processes. + // See tty(4) ("man 4 tty") and ioctl(2) ("man 2 ioctl") for details. + + if (fd >= 0 && (ioctl(fd, TIOCEXCL) == -1)) + { + sprintf( message, "open: exclusive access denied for % s\n", + filename ); + report( message ); + report_error( message ); + + close(fd); + goto fail; + } +#endif /* OPEN_EXCL */ + + if( configure_port( fd ) ) goto fail; (*env)->ReleaseStringUTFChars( env, jstr, filename ); sprintf( message, "open: fd returned is %i\n", fd ); Index: SerialImp.h =================================================================== RCS file: /usr/local/cvsroot/rxtx-devel/src/SerialImp.h,v retrieving revision 1.11.2.49 diff -u -r1.11.2.49 SerialImp.h --- SerialImp.h 5 Jul 2005 17:47:21 -0000 1.11.2.49 +++ SerialImp.h 21 Mar 2006 12:59:17 -0000 @@ -135,7 +135,8 @@ /*# define LOCKDIR "/var/spool/uucp"*/ # define LOCKDIR "/var/lock" # define LOCKFILEPREFIX "LK." -# define UUCP +/*# define UUCP*/ +# define OPEN_EXCL #endif /* __APPLE__ */ #if defined(__NetBSD__) # define DEVICEDIR "/dev/" From tjarvi at qbang.org Tue Mar 21 10:26:08 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 21 Mar 2006 10:26:08 -0700 (MST) Subject: [Rxtx] Javadoc on the go In-Reply-To: <441FA98B.9050701@ngi.it> References: <441FA98B.9050701@ngi.it> Message-ID: On Tue, 21 Mar 2006, Fabio Frumento wrote: > Hi Trent, > > sorry for the big delay but my job is running wild, i was out for some > time but now i'm back and ready to continue the javadoc for Rxtx. > > Did you used the last javadoc patch i sent you ? let me know if i have to > send it to you again or not. > > regards > > Fabio Hi Fabio The patch is in the rxtx mail-list archives. It will be going in soon. I did not see a time critical portion. I'll probably be going through the list since the last batch of patches this weekend and putting them into CVS. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Tue Mar 21 10:57:18 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 21 Mar 2006 10:57:18 -0700 (MST) Subject: [Rxtx] jvm issue In-Reply-To: <20060321065524.94779.qmail@web50701.mail.yahoo.com> References: <20060321065524.94779.qmail@web50701.mail.yahoo.com> Message-ID: On Mon, 20 Mar 2006, Lambok Sianturi wrote: > Hi All, > This is my first time to join RxTx mailing list. I thank you all for allowing others to sign in in requests help. > I use the latest RxTx lib in Fedora 3 with java version 1.4.2_09 b05. And I got this error: > > # > # An unexpected error has been detected by HotSpot Virtual Machine: > # > # SIGSEGV (0xb) at pc=0x00bf27f3, pid=2633, tid=3086112448 > # > # Java VM: Java HotSpot(TM) Client VM (1.4.2_09-b05 mixed mode) > # Problematic frame: > # C [ld-linux.so.2+0xa7f3] A native library loading error? What happens if you recompile rxtx on your system and install that? This sounds like an ABI problem? rxtx 2.1-7 was compiled with a gcc 2.96 toolchain as I recall. The hope is newer system will be backwards compatible. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Tue Mar 21 11:05:29 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 21 Mar 2006 11:05:29 -0700 (MST) Subject: [Rxtx] PATCH: use of ioctl(fd, TIOCEXCL) instead of lockfiles In-Reply-To: <923AE774-EEA2-4911-92D8-32BB27802C8B@buechse.de> References: <923AE774-EEA2-4911-92D8-32BB27802C8B@buechse.de> Message-ID: On Tue, 21 Mar 2006, Joachim Buechse wrote: > Here is the patch for the ioctl(fd, TIOCEXCL). I have verified this only > for OSX 10.4.5, hence it is only defined for APPLE. However, it should > work at least for Solaris as well. > > If a process has requested TIOEXCL further open calls by other user > processes will fail. > > The patch also disables uucp style locking for APPLE. Obviously this is > discussable. I think it is the way to go, as it eliminates creating the > lock directory which doesnt exist on the standard installation and it > eliminates messing with the system group definitions (adding users to > group uucp). > > Regarding the possibility of root processes opening a device which is > locked - I consider this a feature not a potential problem. It is highly > unlikely, that somebody is crazy enough to run a JavaVM as root (unless > he has no other means of getting a restricted IP port opened, ie doesnt > understand ipfw). Anyway, even if the process runs as root, it fails when > calling ioctl(fd, TIOCEXCL). It could however still open the port to > listen for RING events. I.e. a fax server which needs to see incoming > calls but otherwise doesnt want to block the port. So the only case where > the proposed mechanism fails is, if an incorrectly implemented process > running as root conflicts with a user process. I think this can be > accepted. > > Regards, > Joachim > > PS: If this patch is generally accepted, the installer and Mac doku > should obviously be changed as well. > > > Index: SerialImp.c > =================================================================== > RCS file: /usr/local/cvsroot/rxtx-devel/src/SerialImp.c,v > retrieving revision 1.46.2.187 > diff -u -r1.46.2.187 SerialImp.c > --- SerialImp.c 29 Jan 2006 22:19:04 -0000 1.46.2.187 > +++ SerialImp.c 21 Mar 2006 12:59:16 -0000 > @@ -656,6 +656,25 @@ > fd=OPEN (filename, O_RDWR | O_NOCTTY | O_NONBLOCK ); > } while (fd < 0 && errno==EINTR); > > +#ifdef OPEN_EXCL > + // Note that open() follows POSIX semantics: multiple open() > calls to > + // the same file will succeed unless the TIOCEXCL ioctl is > issued. > + // This will prevent additional opens except by root-owned > processes. > + // See tty(4) ("man 4 tty") and ioctl(2) ("man 2 ioctl") for > details. > + > + if (fd >= 0 && (ioctl(fd, TIOCEXCL) == -1)) > + { > + sprintf( message, "open: exclusive access denied for % > s\n", > + filename ); > + report( message ); > + report_error( message ); > + > + close(fd); > + goto fail; > + } > +#endif /* OPEN_EXCL */ > + > + > if( configure_port( fd ) ) goto fail; > (*env)->ReleaseStringUTFChars( env, jstr, filename ); > sprintf( message, "open: fd returned is %i\n", fd ); > Index: SerialImp.h > =================================================================== > RCS file: /usr/local/cvsroot/rxtx-devel/src/SerialImp.h,v > retrieving revision 1.11.2.49 > diff -u -r1.11.2.49 SerialImp.h > --- SerialImp.h 5 Jul 2005 17:47:21 -0000 1.11.2.49 > +++ SerialImp.h 21 Mar 2006 12:59:17 -0000 > @@ -135,7 +135,8 @@ > /*# define LOCKDIR "/var/spool/uucp"*/ > # define LOCKDIR "/var/lock" > # define LOCKFILEPREFIX "LK." > -# define UUCP > +/*# define UUCP*/ > +# define OPEN_EXCL > #endif /* __APPLE__ */ > #if defined(__NetBSD__) > # define DEVICEDIR "/dev/" > This looks like a good start. What do you think Dmitry? Perhaps all systems with TIOCEXCL defined should use that though. Even if they use lockfiles. It wont hurt anything. That would catch people hacking their own serial apps without checking lockfiles. Its a good idea to avoid C++ style comments in the C portions. Some older systems don't deal with them well. If it's just for Mac OS X, it isn't a big deal. I think it was the Irix compiler that was problematic? -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Tue Mar 21 11:22:05 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 21 Mar 2006 11:22:05 -0700 (MST) Subject: [Rxtx] lock files In-Reply-To: <8E12916A-1B9A-4FF2-B684-E2D1C794221B@buechse.de> References: <8E12916A-1B9A-4FF2-B684-E2D1C794221B@buechse.de> Message-ID: We can try it. Maybe the JNI is much improved. The nice thing about linking into liblock is distros then worry about lockfiles on their systems. This way, we have to deal with any changes that may show up. On Tue, 21 Mar 2006, Joachim Buechse wrote: > This is pretty much what I thought about when I suggested, that the > default behaviour could be overwritten with a property. I am very much in > favor of this approach. In particular this allows much easier debugging > for PC based java developers. > > I think big parts of the Java (and maybe some parts of the C code) could > use a bit of a structural workover (unit tests, javadoc, synchronization, > etc). Maybe there should be a CVS branch for this experimental version. > I'd be happy to contribute a first workover for some of the Java code. > Designing for testability and implementing a good bunch of unit tests has > been a strategy that worked quite well in the Java projects I lead. And > it ultimately allows more liberal change permission. > > Regards, > Joachim > > > On 21.03.2006, at 08:51, Dr. Douglas Lyon wrote: > >> Hi All, >> You know, if the use of lock files were >> under Java control (rather than a build-time decision), >> it might enable a more unified binary distro. It might also >> facilitate quick prototyping of non-lock file approaches >> to resolving serial port contention issues (i.e., mac-like >> approaches vs. linux approaches, etc.). >> >> I realize that this is a radical overhaul of the lock file policy >> issue. Also, it may harm performance. On the other hand, >> our benchmarks on JNI overhead for modern processors indicate >> performance impact should be minimal. Perhaps it is more of >> an issue with the toybox systems. >> >> Suppose there were a class with a reasonable default...someone >> might write: >> SerialPortLockPolicy.setPolicy(SerialPortLockPolicy.UNIX_LOCK_FILE); >> SerialPortLockPolicy.setPolicy(SerialPortLockPolicy.NO_LOCK_CHECKING); >> SerialPortLockPolicy.setPolicy(SerialPortLockPolicy.MAC_STYLE); >> >> Thus, we could have a run-time reconfiguration of the serial port lock >> policy. A special NO_LOCK version of the binary would no longer >> be required. >> >> Any thoughts on this? >> >> Thanks! >> - Doug >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From dmarkman at mac.com Tue Mar 21 16:05:17 2006 From: dmarkman at mac.com (Dmitry Markman) Date: Tue, 21 Mar 2006 18:05:17 -0500 Subject: [Rxtx] PATCH: use of ioctl(fd, TIOCEXCL) instead of lockfiles In-Reply-To: References: <923AE774-EEA2-4911-92D8-32BB27802C8B@buechse.de> Message-ID: <512AC70C-BB86-48F2-A83C-023F35C23BAB@mac.com> I think it's cool, but I'd like to have that property implementation when user can choose between locking mechanism about comments: it's easy to change comments to the C style or we can use extensions of the file to cpp so c++ compiler will be used On Mar 21, 2006, at 1:05 PM, Trent Jarvi wrote: > This looks like a good start. What do you think Dmitry? Perhaps > all systems with TIOCEXCL defined should use that though. Even if > they use lockfiles. It wont hurt anything. That would catch > people hacking their own serial apps without checking lockfiles. > > Its a good idea to avoid C++ style comments in the C portions. > Some older systems don't deal with them well. If it's just for Mac > OS X, it isn't a big deal. I think it was the Irix compiler that > was problematic? Dmitry Markman From dmarkman at mac.com Tue Mar 21 16:13:00 2006 From: dmarkman at mac.com (Dmitry Markman) Date: Tue, 21 Mar 2006 18:13:00 -0500 Subject: [Rxtx] PATCH: use of ioctl(fd, TIOCEXCL) instead of lockfiles In-Reply-To: References: <923AE774-EEA2-4911-92D8-32BB27802C8B@buechse.de> Message-ID: I'd like to add that creating locking folder isn't a big deal we never had a problem related to the lock folders, because we always used installer on mac os x from other hand I'm not very much familiar with iotcl locking approach and I'm not sure it's more efficient Joachim wrote "I think it is the way to go, as it eliminates creating the lock directory which doesnt exist on the standard installation and it eliminates messing with the system group definitions (adding users to group uucp)." but I really didn't have any problem with that 1. doesn't exist on the standard installation there are many-many things that don't exist in the standard installation so I don't think that argument is strong enough 2. messing with the system group definitions I don't think we're messing with the group definition mac os x provides very clear way to set up group's members and together with Greg Guerin AuthKit there is no problem to set those definitions so I don't think that argument is strong either but from other hand using iotcl is more promising and is more elegant On Mar 21, 2006, at 1:05 PM, Trent Jarvi wrote: > > This looks like a good start. What do you think Dmitry? Perhaps > all systems with TIOCEXCL defined should use that though. Even if > they use lockfiles. It wont hurt anything. That would catch > people hacking their own serial apps without checking lockfiles. Dmitry Markman From joachim at buechse.de Wed Mar 22 04:46:45 2006 From: joachim at buechse.de (Joachim Buechse) Date: Wed, 22 Mar 2006 12:46:45 +0100 Subject: [Rxtx] PATCH: use of ioctl(fd, TIOCEXCL) instead of lockfiles In-Reply-To: References: <923AE774-EEA2-4911-92D8-32BB27802C8B@buechse.de> Message-ID: Sorry, I was not very clear with my arguments, so I will try again;-) Please, don't take this as an attack against work that has been done. I think the contributions that have been made in the past were made in a good spirit. But I really believe, that the current solution for OSX has many shortcomings and should be changed as soon as possible. lock files --- The /var/lock folder does not exist on the standard OSX installation, however the standard installation includes several applications that use serial ports (i.e. the FAX capability). This indicates, that the lock folder approach will not work well with system components. Applications for OSX will generally try to live in harmony with system components (except for HP print drivers of course). I think RXTX should follow this approach as well. uucp group --- Accessing serial ports is not an admin privileged operation on OSX. Any user (world) has read/write privileges on /dev/tty*. So the system default is to not enforce any group membership to access these ports. The group uucp however is a system group on all unix systems I know. It exists for certain system processes. A non admin user should in general not be a member of this group. Quite arguably no user should ever be a member of this group. Installer --- My general opinion is, that - no Installer should touch user or group data without warning - no Application Installer should touch groups which are not specific to the very application installed - no Installer should ever add regular users to a system group The current installer injects the installing user in the group uucp without warning about this change and without giving the option to "opt out" of this change. This is a potential security risk (but not currently a real one, as OSX contains no folders belonging to group uucp). The current installer does not work for multi user systems. It puts the installing user in the uucp group. However the installing user is not necessarily the user that will use the application. Putting all users that may use a serial port application in the system group uucp seems like a very invasive approach to me. Besides that, newly created users will not automatically be in the group and hence, serial applications will "break" for new users without obvious reasons. Avoiding the lock files will allow self contained applications (i.e. drag&drop installation). In my eyes this is largely preferable over an installer that requests admin privileges. Adding up all these points indicates very strongly, that the lock-file implementation is not the way to go on OSX. Regards, Joachim On 22.03.2006, at 00:13, Dmitry Markman wrote: > I'd like to add that > > creating locking folder isn't a big deal > we never had a problem related to the lock folders, because we > always used installer on mac os x > from other hand I'm not very much familiar with iotcl locking > approach and I'm not sure it's more efficient > > Joachim wrote "I think it is the way to go, as it eliminates > creating the lock directory which doesnt exist on the standard > installation and it eliminates messing with the system group > definitions (adding users to group uucp)." but I really didn't have > any problem with that > > 1. doesn't exist on the standard installation > there are many-many things that don't exist in the standard > installation so I don't think that argument is strong enough > 2. messing with the system group definitions > I don't think we're messing with the group definition > mac os x provides very clear way to set up group's members and > together with Greg Guerin AuthKit there is no problem to set those > definitions > so I don't think that argument is strong either > but from other hand using iotcl is more promising and is more elegant > > > > On Mar 21, 2006, at 1:05 PM, Trent Jarvi wrote: > >> >> This looks like a good start. What do you think Dmitry? Perhaps >> all systems with TIOCEXCL defined should use that though. Even if >> they use lockfiles. It wont hurt anything. That would catch >> people hacking their own serial apps without checking lockfiles. > > Dmitry Markman > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From dmarkman at mac.com Wed Mar 22 05:27:13 2006 From: dmarkman at mac.com (Dmitry Markman) Date: Wed, 22 Mar 2006 07:27:13 -0500 Subject: [Rxtx] PATCH: use of ioctl(fd, TIOCEXCL) instead of lockfiles In-Reply-To: References: <923AE774-EEA2-4911-92D8-32BB27802C8B@buechse.de> Message-ID: <83440CF3-DCD8-41C1-B941-F227232C27E3@mac.com> thanks for the very good explanation I didn't think that you were attacking any thing, so don't worry I just had feeling, that there were more aesthetic reasons for going to ioctl then real necessity now you explained everything quite well (BTW, asfar as I remember installer asks admin password so it wasn't quiet, but it really doesn't matter now) thanks On Mar 22, 2006, at 6:46 AM, Joachim Buechse wrote: > Sorry, I was not very clear with my arguments, so I will try again;-) > > Please, don't take this as an attack against work that has been > done. I think the contributions that have been made in the past > were made in a good spirit. But I really believe, that the current > solution for OSX has many shortcomings and should be changed as > soon as possible. > > lock files > --- > The /var/lock folder does not exist on the standard OSX > installation, however the standard installation includes several > applications that use serial ports (i.e. the FAX capability). This > indicates, that the lock folder approach will not work well with > system components. Applications for OSX will generally try to live > in harmony with system components (except for HP print drivers of > course). I think RXTX should follow this approach as well. > > uucp group > --- > Accessing serial ports is not an admin privileged operation on OSX. > Any user (world) has read/write privileges on /dev/tty*. So the > system default is to not enforce any group membership to access > these ports. The group uucp however is a system group on all unix > systems I know. It exists for certain system processes. A non admin > user should in general not be a member of this group. Quite > arguably no user should ever be a member of this group. > > Installer > --- > My general opinion is, that > - no Installer should touch user or group data without warning > - no Application Installer should touch groups which are not > specific to the very application installed > - no Installer should ever add regular users to a system group > > The current installer injects the installing user in the group uucp > without warning about this change and without giving the option to > "opt out" of this change. This is a potential security risk (but > not currently a real one, as OSX contains no folders belonging to > group uucp). > > The current installer does not work for multi user systems. It puts > the installing user in the uucp group. However the installing user > is not necessarily the user that will use the application. Putting > all users that may use a serial port application in the system > group uucp seems like a very invasive approach to me. Besides that, > newly created users will not automatically be in the group and > hence, serial applications will "break" for new users without > obvious reasons. > > > Avoiding the lock files will allow self contained applications > (i.e. drag&drop installation). In my eyes this is largely > preferable over an installer that requests admin privileges. Adding > up all these points indicates very strongly, that the lock-file > implementation is not the way to go on OSX. > > Regards, > Joachim > > > On 22.03.2006, at 00:13, Dmitry Markman wrote: > >> I'd like to add that >> >> creating locking folder isn't a big deal >> we never had a problem related to the lock folders, because we >> always used installer on mac os x >> from other hand I'm not very much familiar with iotcl locking >> approach and I'm not sure it's more efficient >> >> Joachim wrote "I think it is the way to go, as it eliminates >> creating the lock directory which doesnt exist on the standard >> installation and it eliminates messing with the system group >> definitions (adding users to group uucp)." but I really didn't >> have any problem with that >> >> 1. doesn't exist on the standard installation >> there are many-many things that don't exist in the standard >> installation so I don't think that argument is strong enough >> 2. messing with the system group definitions >> I don't think we're messing with the group definition >> mac os x provides very clear way to set up group's members and >> together with Greg Guerin AuthKit there is no problem to set those >> definitions >> so I don't think that argument is strong either >> but from other hand using iotcl is more promising and is more elegant >> >> >> >> On Mar 21, 2006, at 1:05 PM, Trent Jarvi wrote: >> >>> >>> This looks like a good start. What do you think Dmitry? Perhaps >>> all systems with TIOCEXCL defined should use that though. Even >>> if they use lockfiles. It wont hurt anything. That would catch >>> people hacking their own serial apps without checking lockfiles. >> >> Dmitry Markman >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx Dmitry Markman From lyon at docjava.com Wed Mar 22 06:12:18 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Wed, 22 Mar 2006 08:12:18 -0500 Subject: [Rxtx] sole of a new design pattern Message-ID: Hi All, I have been thinking about how we design the serial port software. I think we need a new design pattern. For lack of a better term, I shall call it: The Parametric Singleton Design Pattern By Douglas A. Lyon ABSTRACT The goal of the singleton design pattern is to make sure that there is one, and only one, instance of a given class. The goal of the parametric singleton design pattern is to make sure that there is one, and only one, instance of a given class with the given parametric values. We parametric singleton design pattern combines the singleton design pattern with a parameter that enables unique creation of instances of a class. These instances are cached. When a user asks for an instance with these parameters, the cache is checked. If the instance is in the cache, the instance is returned, otherwise it is created, added to the cache and then returned. We apply our parametric singleton design pattern to the retrieval of RMI registries bound to a given port. The goal of our system is to make sure that no two RMI registries are listening to the same socket and to make use of the RMI registries after they have been created. RMI registries are used in distributed computation. Introduction The singleton design pattern is meant to ensure that on a single instance of a class exists. It is also meant to provide a global point of access to it. The intent of the parametric singleton design pattern is to ensure that a class has only one instance for a given set of parameter values. It also provides a global point of access to it. Motivation A system cannot tolerate multiple instances of some classes with identical parameters. For example, you cannot have two instances making use of the same serial port, at the same time. You cannot have two instances that are trying to listen to the same socket connection. You cannot have two instances writing to the same file structure at the same time. As the operating system is often thought of as the arbiter of consumed resources (i.e., tape drives, serial ports, etc.) we frequently leave it to an operating system implementation to resolve these contention issues. Even for similar resources (like serial ports) there are few standards for handling contention. For example, serial ports on Linux are locked using a "/var/lock" file. POSIX, on the other hand, uses ioctl mechanisms to prevent contention. A better solution is to make a class that is responsible for keeping track of the instances created from the class. The class is declared final, so that it cannot be subclassed. The class also has a private constructor, so that other classes cannot instance it. The new design pattern is called the parametric singleton design pattern and it provides a way to access and create instances with given parameters. Applicability Use the Parametric Singleton Design Pattern when: 1. There must be exactly one instance of a class with the given parameters. 2. The instances must be accessible to clients from a well-known access point. Structure Insert UML diagram here. Participants The Parametric Singleton Clients that need instances 1. The Parametric Singleton defines an instance upon request from a client, if, and only if, the instance does not already exist. 2. The Parametric Singleton returns the instance to the client. 3. The Parametric Singleton is responsible for creating unique instances from given parameters. Collaborations Clients obtain a reference to a Parametric Singleton instance only through the parametric singleton design pattern. If the instance is left in an improper state (e.g., the serial port was left open) it is NOT the role of the Parametric Singleton Design Pattern to close the IO port. Nor is it the role of the Parametric Singleton Design Pattern to open the port. That role is delegate to some other part of the system. Further, it is not the role of the Parametric Singleton Design Pattern to check out resources. That is, multiple threads can have multiple references to the same resource at the same time. MUTEX locking is delegated to some other part of the system. Consequences The Parametric Singleton Design Pattern has several benefits: 1. Controlled access to parametrically defined instances. Since the Parametric Singleton class encapsulates its instances, there is control over how and when clients access it. 2. Reduced name space. The Parametric Singleton pattern avoids global variables that store instances created from the same parameter. Implementation Here are implementation issues to consider when using the Parametric Singleton pattern: 1. Unique mapping of parameters. The Parametric Singleton pattern requires that there be a mean to isomorphically map the parameter space into the instance space and back again. 2. Ensure unique instances. The Parametric Singleton pattern makes unique instances from parameters, and it does so only once. 3. Cache instances for fast retrieval. The Parametric Singleton pattern must be able to look up instances, given some set of parameters, and do so from some data structure. That is, there must be enough space to hold references to all the instances the program will need. Also, a mechanism is needed to look up and retrieve the instances quickly enough to satisfy the clients. Sample Code public final class ParametricSingletonRmiRegistry { private static Hashtable registry = new Hashtable(100); // use singleton pattern and??????????????????????????????????????????????? // prevent instantiation of RmiRegistryUtils.?????????????????????????????? private ParametricSingletonRmiRegistry() { } // the only instance of the Registry held by the RmiRegistryUtils?????????? public static void listNames(Integer port) { if (!isInCacheAndRunning(port)) return; Registry r = (Registry) registry.get(port); System.out.println("registry on port: " + port); System.out.println("registry: " + r); System.out.println("names: "); try { print(r.list()); } catch (RemoteException e) { In.message(e); } System.out.println("------------------------"); } /**???????????????????????????????????????????????????????????????????????? * Checks whether a Registry has been started on this host????????????????? * in the specified port.?????????????????????????????????????????????????? * If not, it tries to start one.?????????????????????????????????????????? * when it fails to start a Registry, it exits the program????????????????? * with exit code 1.??????????????????????????????????????????????????????? */ public static void restart(int port) { if (isInCacheAndRunning(port)) return; try { startRegistry(port); } catch (RemoteException e) { In.message(e); } } /**???????????????????????????????????????????????????????????????????????? * @param port????????????????????????????????????????????????????????????? * @return true if registry is in cache and running???????????????????????? */ private static boolean isInCacheAndRunning(Integer port) { if (!isRegistryRunning(port.intValue())) return false; if (!isRegistryInCache(port.intValue())) return false; return true; } /**???????????????????????????????????????????????????????????????????????? * @param port????????????????????????????????????????????????????????????? * @return true if we are able to locate a local registry on port.??????????????????????????????????????????????????????????????????????????? */ private static boolean isRegistryRunning(int port) { try { Registry r = LocateRegistry.getRegistry(port); if (r != null) return true; } catch (RemoteException e) { return false; } return false; } /**???????????????????????????????????????????????????????????????????????? * @param port????????????????????????????????????????????????????????????? * @return return true if registry is in cache????????????????????????????? */ private static boolean isRegistryInCache(int port) { if (registry.get(new Integer(port)) == null) return false; return true; } /**???????????????????????????????????????????????????????????????????????? * Restart the registry, if needed.???????????????????????????????????????? * Return the only instance of the registry for consistent global?????????? * using by making use of the Singleton Design Pattern????????????????????? *????????????????????????????????????????????????????????????????????????? * @return the internally held registry instance.?????????????????????????? */ public static Registry getRegistry(Integer port) { restart(port); return (Registry) registry.get(port); } private static void startRegistry(Integer port) throws RemoteException { Registry r; try { r = LocateRegistry.createRegistry(port.intValue()); registry.put(port, r); //r = new sun.rmi.registry.RegistryImpl???????????????????????????? /// (port.intValue());?????????????????????????????????????? // registry.put(port, r);?????????????????????????????????????????? } catch (Exception e) { //e.printStackTrace();????????????????????????????????????????????? r = LocateRegistry.getRegistry(port.intValue()); registry.put(port, r); } } public static void main(String args[]) throws RemoteException { //restart(port);??????????????????????????????????????????????????????? restart(5001); restart(5002); restart(5002); Registry r = LocateRegistry.getRegistry(5002); System.out.println("registry="+r); } } I would very much like to get your feedback on this new design pattern idea. Thank you for your time. Regards, - Doug From david.garnier at trusted-logic.com Wed Mar 22 07:36:10 2006 From: david.garnier at trusted-logic.com (David Garnier) Date: Wed, 22 Mar 2006 15:36:10 +0100 Subject: [Rxtx] sole of a new design pattern In-Reply-To: References: Message-ID: <442160DA.80107@trusted-logic.com> Hello, > The Parametric Singleton Design Pattern The Singleton is the most abused design pattern ever. Good use-cases for this pattern are extremely rare and mostly confined to problems related to hardware resources, like serial ports. > Applicability > > Use the Parametric Singleton Design Pattern when: > 1. There must be exactly one instance of a class with the given > parameters. OK. As I said above, this case this actually very unusual. The Singleton pattern is mostly used when : > 2. The instances must be accessible to clients from a well-known > access point. Using the singleton pattern in this case is just convenient for the programmer. Problems arises pretty quickly, especially if you attempt to unit-test your classes. 1) If your singleton is stateful, or hold on to stateful objects, it means that two different unit tests are not actually independent. Instead of starting with a brand new environment, the result of a test may be affected by the result of a previous test. This problem also arise when with your class relies on a database. In both cases, the solution is to reset your "unique" resource (Singleton or database) at the beginning of the test, which is a pain. Also, while most projects connect to a single database, projects that allow the use of Singletons usually contain several of thems, and new ones may cropped up unnoticed. You quickly end up with test cases that only pass in a certain order, which is a royal pain. 2) You cannot mockup a singleton. Once everyone calls the SomeSingleton class statically, you can't replace your class by SomeSingletonMockup. Furthermore, even for hardware services, the Singleton pattern does not really prevent concurrent accesses. If you start the same program in two different JVMs, unless they somehow shared the state of their "Singletons" (through lock files for example), the Singleton pattern will not prevent concurrent access. Our application uses RXTX, and we routinely encounter cases where another (native) application has already locked the port. Since we cannot modify the native application to recognize lock files, OS-level control is irreplaceable. > > Consequences > The Parametric Singleton Design Pattern has several benefits: > > 1. Controlled access to parametrically defined instances. Since > the Parametric Singleton class encapsulates its instances, there is > control over how and when clients access it. Not really. Once you've returned the instance to a client, you've lost control over it. The client can to whatever it wants with it. You cannot "recall" the instance or claim it back. > 2. Reduced name space. The Parametric Singleton pattern avoids > global variables that store instances created from the same parameter. Sure, but you don't have to rely on a Singleton for that. Just create a single Factory. > I would very much like to get your feedback on this new design > pattern idea. Well, it's nothing new. Some may say that it is the point of design patterns: formalizes the designs that occur again and again. However, this design is simply a combination of the Singleton and Factory patterns. I did use it in the past, but now I've been exposed to the shortcomings of the Singleton pattern, so I limit myself to Factories. Regards, David From sean_montgomery at baseview.com Wed Mar 22 08:35:28 2006 From: sean_montgomery at baseview.com (Sean Montgomery) Date: Wed, 22 Mar 2006 10:35:28 -0500 Subject: [Rxtx] sole of a new design pattern In-Reply-To: <442160DA.80107@trusted-logic.com> References: <442160DA.80107@trusted-logic.com> Message-ID: <05769CA7-A51B-4CF0-BAA0-E02DD905F5A4@baseview.com> On Mar 22, 2006, at 9:36 AM, David Garnier wrote: > Furthermore, even for hardware services, the Singleton pattern does > not really prevent concurrent > accesses. If you start the same program in two different JVMs, > unless they somehow shared the state > of their "Singletons" (through lock files for example), the > Singleton pattern will not prevent > concurrent access. > Multiple class loaders in a single JVM can be tricky, too. Then there's synchronization, lazy initialization and serialization of singletons to contend with. Bloch's Effective Java covers these, and here's a few articles: http://www.javaworld.com/javaworld/jw-04-2003/jw-0425-designpatterns- p3.html http://java.sun.com/developer/technicalArticles/Programming/singletons/ Just FYI :-) From lyon at docjava.com Wed Mar 22 08:50:48 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Wed, 22 Mar 2006 10:50:48 -0500 Subject: [Rxtx] sole of a new design pattern In-Reply-To: <442160DA.80107@trusted-logic.com> References: <442160DA.80107@trusted-logic.com> Message-ID: Hi All, First, I would like to thank David for his prompt and thoughtful remarks. I had no idea people that feel strongly about a design patterns! Wow! Feedback (particularly critical feedback) is greatly appreciated. Starting at the end, first: >I did use it in >the past, but now I've been exposed to the shortcomings of the >Singleton pattern, so I limit myself to Factories. David, if I understood your comments correctly, you suggested that Factories can be used in leu of the Singleton Design Pattern, or even the Parametric Singleton Design Pattern. As I see in [Gof]: Factory Method: Intent "Define an interface for creating an object, but let subclasses decide which class to instantiate. Factory Method lets a class defer instantiation to subclasses." The Singleton Design Pattern is a concrete class, which is rather different, right? Also, subclasses are not permitted with Singleton, as they are final. Naturally, I could use an abstract factory as a parent for a singleton. I could even design a facade that could be implemented with the singleton....but that is not the intention of the design. Unless you want a mock-up, as discussed, below: More below: >Hello, > >> The Parametric Singleton Design Pattern > >The Singleton is the most abused design pattern ever. Good use-cases >for this pattern are extremely >rare and mostly confined to problems related to hardware resources, >like serial ports. > > >> Applicability >> >> Use the Parametric Singleton Design Pattern when: >> 1. There must be exactly one instance of a class with the given >> parameters. >OK. As I said above, this case this actually very unusual. The >Singleton pattern is mostly used when : >> 2. The instances must be accessible to clients from a well-known >> access point. > >Using the singleton pattern in this case is just convenient for the >programmer. Problems arises >pretty quickly, especially if you attempt to unit-test your classes. > >1) If your singleton is stateful, or hold on to stateful objects, it >means that two different unit >tests are not actually independent. Instead of starting with a brand >new environment, the result of >a test may be affected by the result of a previous test. This >problem also arise when with your >class relies on a database. In both cases, the solution is to reset >your "unique" resource >(Singleton or database) at the beginning of the test, which is a >pain. Also, while most projects >connect to a single database, projects that allow the use of >Singletons usually contain several of >thems, and new ones may cropped up unnoticed. You quickly end up >with test cases that only pass in a >certain order, which is a royal pain. There are basic problems with communicating finite state machines that include reachability and deadlock analysis. These are addressed with petri net analysis and are beyond the scope of the design pattern. As you quite rightly pointed out; the parametric singleton pattern (or the singleton pattern, for that matter) enable multiple threads to gain access to the same instance. The only way that I can see to block others from gaining access to the reference is the synchronize keyword. This is putting a spin-lock (or MUTEX) on the reference. The question of how to unit-test a design pattern like the parametric singleton remains open. Perhaps this is a deficiency. > >2) You cannot mockup a singleton. Once everyone calls the >SomeSingleton class statically, you can't >replace your class by SomeSingletonMockup. Acutally, I am not sure that this is true. If the Singleton implements a Facade interface, it should be possible to make the replacement. Right? > >Furthermore, even for hardware services, the Singleton pattern does >not really prevent concurrent >accesses. If you start the same program in two different JVMs, >unless they somehow shared the state >of their "Singletons" (through lock files for example), the >Singleton pattern will not prevent >concurrent access. Good Point!! You have sharp eyes! The singleton design pattern should/could take responsibility for this. In fact, you may notice that my code does have an implementation (LocateRegistry) that can work across JVM's. The LocateRegistry will even work across the Internet! LocateRegistry takes both a host name and a Port (lock files just don't do this). I did not think to implement this beyond the local machine, but, in its present form, it will work across different processes. > >Our application uses RXTX, and we routinely encounter cases where >another (native) application has >already locked the port. Since we cannot modify the native >application to recognize lock files, >OS-level control is irreplaceable. The singleton design pattern is not meant to replace OS-level control, but to centralize the Java programmers access to it. If lock files, for example, are used for serial ports, the Singleton Design Pattern should be able to work with them. > > >> >> Consequences >> The Parametric Singleton Design Pattern has several benefits: >> > > 1. Controlled access to parametrically defined instances. Since >> the Parametric Singleton class encapsulates its instances, there is >> control over how and when clients access it. > >Not really. Once you've returned the instance to a client, you've >lost control over it. The client >can to whatever it wants with it. You cannot "recall" the instance >or claim it back. Good point, this should read: > 1. Controll when parametrically defined instances are created. Since > > the Parametric Singleton class encapsulates its instances, there is > > control over how and when they are instanced. > >> 2. Reduced name space. The Parametric Singleton pattern avoids >> global variables that store instances created from the same parameter. > >Sure, but you don't have to rely on a Singleton for that. Just >create a single Factory. > > Thank you for your thoughtful and prompt response! Regards, - Doug From dmarkman at mac.com Wed Mar 22 21:21:55 2006 From: dmarkman at mac.com (Dmitry Markman) Date: Wed, 22 Mar 2006 23:21:55 -0500 Subject: [Rxtx] sole of a new design pattern In-Reply-To: <442160DA.80107@trusted-logic.com> References: <442160DA.80107@trusted-logic.com> Message-ID: I don't think I get it On Mar 22, 2006, at 9:36 AM, David Garnier wrote: > Using the singleton pattern in this case is just convenient for the > programmer. Problems arises > pretty quickly, especially if you attempt to unit-test your classes. so you're saying that something isn't so good because you can not test it in the convenient way? if that's true, I'm totally disagree change your test, debug whatever, but if software is efficient at runtime, works fine and only problem is some unit test (which is some kind of framework for testing) then dump that unit test , dump that unit framework and make something appropriate to the software you're testing so if Douglas want to use singletons, what's the problem? and what do you mean by abusing of singleton usage? of course singleton doesn't prevent concurrent access to the resource across the processes unless you're using some OS facility to prevent it, besides singleton as it was introduced is relevant only and only inside of the same process otherwise it's not singleton it's something else (let's say network singleton: so you have remote invocation facility and some factory method that return object created by that facility) I don't have any problem with using any kind of singletons. Parametric Singleton idea (if I understand it right) could be easily implemented in the following way: use a map populate map with instances of some class and key is your parameter (you can use lazy population too) if somebody ask the key check the value if it's null so resource is taken if somebody returns the resource put it back to the map public synchronized static Object getSomeResource(Object parameter); public synchronized static void returnResource(Object parameter); getSomeResource (inside of the same process) could return null in 2 cases 1. if somebody (from other thread for example) already took that resource 2. if OS API said that resource corresponded to that parameter (serial port with parameter = 1 (port #)) is locked and unavailable; I'm not sure that in case of serial ports we even need those Parametric Singletons (unless lock checking is a very expensive operation) just ask the OS about availability of that resource and if it's available give it away and then OS will lock it and therefore in next time somebody ask it just answer that resource is locked and return null for example system has 2 serial ports available so I ask getResource("tty"); or I ask getResource("Bluetooth-Modem"); and if OS is ok you can give tty or Bluetooth-Modem or both no need for any additional pattern I think back to the problem mac os x doesn't recognize locking via files, so it handles locking via some API an instance of the singleton in each process should recognize that resource is locked (by using that API) that's all we don't have to make things more complicate then they are just because there is some nice design pattern or nice unit test framework or whatever keep things simple, make them work fast, don't introduce middle layers unless you have really good reason to do so of course I could be entirely wrong, so sorry about that in advance thanks Dmitry Markman From tjarvi at qbang.org Wed Mar 22 22:31:41 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 22 Mar 2006 22:31:41 -0700 (MST) Subject: [Rxtx] sole of a new design pattern In-Reply-To: References: Message-ID: Hi Doug Interesting reading. So far I'm just reading and thinking. I have one question so far. " Clients obtain a reference to a Parametric Singleton instance only through the parametric singleton design pattern. If the instance is left in an improper state (e.g., the serial port was left open) it is NOT the role of the Parametric Singleton Design Pattern to close the IO port. Nor is it the role of the Parametric Singleton Design Pattern to open the port. That role is delegate to some other part of the system. " So when the clients obtain a reference to the singleton, can they assume the port is there? IE, would it be the singletons role to handle things like USB dongles being removed with event hints comming from the underlying OS. Hardware abstraction layer/HAL on Linux is an example of underlying OS events. I assume that role too is delegated to other parts of the system? -- Trent Jarvi tjarvi at qbang.org From lyon at docjava.com Thu Mar 23 08:10:33 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Thu, 23 Mar 2006 10:10:33 -0500 Subject: [Rxtx] Classes don't need goals, they need roles! In-Reply-To: References: Message-ID: Hi Trent, Yes, I think that the role of the Parametric Singleton Pattern is not to open or close serial ports, nor is it to perform error checking. On the other hand, if you were to combine the role of the Parametric Singleton Pattern with another role (like that of error checking) it might not be amiss. However, I generally caution programmers against adding multiple roles to classes, as this leads to monolithic designs. Thus a different class (NativeLibDetect) could have the role of determining if the native library can be loaded. Another class (SerialPortBean) can have the role of serializing the default state of the serial port, so that it can be recovered, from user preferences, at a later time. The SerialPortDetect could have the role of determining if the serial port is removed (i.e., a USB port was unplugged). My guess is that each class should have a different role in the system, in order to ease maintenance and testing...but I could be wrong about that. Thanks! - Doug >Hi Doug > >Interesting reading. So far I'm just reading and thinking. I have >one question so far. > >" > Clients obtain a reference to a Parametric Singleton instance only >through the parametric singleton design pattern. If the instance is >left in an improper state (e.g., the serial port was left open) it is >NOT the role of the Parametric Singleton Design Pattern to close the >IO port. Nor is it the role of the Parametric Singleton Design Pattern >to >open the port. That role is delegate to some other part of the system. >" > >So when the clients obtain a reference to the singleton, can they >assume the port is there? IE, would it be the singletons role to >handle things like USB dongles being removed with event hints >comming from the underlying OS. Hardware abstraction layer/HAL on >Linux is an example of underlying OS events. > >I assume that role too is delegated to other parts of the system? > >-- >Trent Jarvi >tjarvi at qbang.org >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From maximulo at yahoo.com Fri Mar 24 01:22:38 2006 From: maximulo at yahoo.com (Maximulo Majir) Date: Fri, 24 Mar 2006 00:22:38 -0800 (PST) Subject: [Rxtx] JavaPOS Message-ID: <20060324082238.66371.qmail@web38214.mail.mud.yahoo.com> Hi all! Hello Trent! From what i understand, RXTX or JavaComm APIs were not created solely for JavaPOS. In JavaPOS, we have the virtual method claim() which is separate from open(), but in our RXTX API, claiming is done every call to open(), we cant open the port if its claimed by another application. Would it be alright to suggest or ask to create a new method called claim(..)? Is there such thing as forceclaim() in RXTX? this could be the same as portownership transfer or its equivalent. ForceClaim is in JSR80. Do you have some samples using RXTX as the lower layer for the Device Service Objects in JavaPOS? I have tried it, i just want to compare. Thank you all! maxim __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060324/496adba2/attachment-0018.html From tjarvi at qbang.org Fri Mar 24 11:28:19 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 24 Mar 2006 11:28:19 -0700 (MST) Subject: [Rxtx] Re: RXTX 2.1 Solaris Problems In-Reply-To: <3691.1143210578@www045.gmx.net> References: <3691.1143210578@www045.gmx.net> Message-ID: On Fri, 24 Mar 2006, Andreas Guenther wrote: > Hi all, > > the solaris problem was not the lock file only. > > Ok, I had to create the directory /var/spool/locks myself. > /var/spool/uucp exists. > > But rxtx didn't find any port. > > I compiled the source with my own debug-informations > and I tried to isolate the problem. > > The problem is the testRead-call in SerialImp.c > > JNIEXPORT jboolean JNICALL RXTXCommDriver(testRead)( > > ... > if ( READ( fd, &c, 1 ) < 0 ) > { > if ( errno != EAGAIN ) { > report( "testRead() read failed\n" ); > ret = JNI_FALSE; > } > } > Thanks Andreas I'm packing up to move. I'll be more or less away for a couple weeks here. I'll be checking email but my workstation is going into a box soon. This isn't hard to fix as this port should be enumerated when EWOULDBLOCK is recieved. Thats error is OK for enumeration just as EAGAIN is. I've put the bug into bugzilla so we dont forget to get to it. http://bugzilla.qbang.org/show_bug.cgi?id=42 You can add yourself to the CC list if you wish to test fixes we provide or even put a patch into bugzilla yourself. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Fri Mar 24 11:51:52 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 24 Mar 2006 11:51:52 -0700 (MST) Subject: [Rxtx] JavaPOS In-Reply-To: <20060324082238.66371.qmail@web38214.mail.mud.yahoo.com> References: <20060324082238.66371.qmail@web38214.mail.mud.yahoo.com> Message-ID: On Fri, 24 Mar 2006, Maximulo Majir wrote: > Hi all! Hello Trent! > > > From what i understand, RXTX or JavaComm APIs were not > created solely for JavaPOS. In JavaPOS, we have the virtual method > claim() which is separate from open(), but in our RXTX API, claiming is > done every call to open(), we cant open the port if its claimed by > another application. Would it be alright to suggest or ask to create a > new method called claim(..)? Is there such thing as forceclaim() in > RXTX? this could be the same as portownership transfer or its > equivalent. ForceClaim is in JSR80. > Do you have some samples using RXTX as the lower layer for the Device > Service Objects in JavaPOS? I have tried it, i just want to compare. > maxim Hi Maxim JSR80 is the USB API IBM/Sun put together. The problem is they have a richer kernel/API underneath that can handle such things. With Serial Ports, there isnt anything there other than an ioctl that says don't let anyone touch this and lockfiles that are more of a 'lets be nice.' At times we may be using USB ports but it is through the termios layer with the limitations mentioned. The advantage is that not only USB will work with rxtx. Anything that has a termios layer should work (to the extent that termios layer is complete). I don't know how forceclaim() would help you. Lets say someone has a programmer working on /dev/ttyS0 and you take it. Now you both race each other to read data first. There isn't a mechanism I know of that will solve this problem in termios. The most obvious test being a native app and a Java app trying to take the port. There is the potential of requestion ownership from other Java Applications but the use for that is very rare. Did you have something more specific in mind that I'm missing? I'm not sure that claim() and forceclaim() would help you with rxtx other than maybe locking the port with claim() without opening it. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sat Mar 25 23:42:08 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 25 Mar 2006 23:42:08 -0700 (MST) Subject: [Rxtx] Serial snoop Message-ID: I was reading the Linux kernel mail-list tonight and ran past a thread that mentioned sersnoop. This looks like a handy tool for people dealing with new toys. "a simple command-line tool for linux that echoes bytes to and from any two serial ports, ptys, or network sockets, and prints all traffic to stdout, in hex and ascii." http://www.restivo.org/projects/sersnoop/ It works on Linux only at this time (debian package available). -- Trent Jarvi tjarvi at qbang.org From beat.arnet at gmail.com Sun Mar 26 07:32:35 2006 From: beat.arnet at gmail.com (Beat Arnet) Date: Sun, 26 Mar 2006 09:32:35 -0500 Subject: [Rxtx] Error 0x5 at /home/bob/foo/tar/rxtx-2.1-7/build/../src/termios.c(860): Access is, denied. Message-ID: <4426A603.80508@gmail.com> Dear all, When trying to open the serial port, I sometimes (not always) run into the following exception (when opening the serialPort): Error 0x5 at /home/bob/foo/tar/rxtx-2.1-7/build/../src/termios.c(860): Access is denied. java.lang.UnsatisfiedLinkError: native_psmisc_report_owner at gnu.io.CommPortIdentifier.native_psmisc_report_owner(Native Method) at gnu.io.CommPortIdentifier.open(CommPortIdentifier.java:354) at codeskin.tools.CLLoader.open(CLLoader.java:79) at codeskin.tools.C2000Programmer.run(C2000Programmer.java:220) at java.lang.Thread.run(Unknown Source) Is this the type of error where I should just try to open the port again, or can it be avoided? Regards, Beat From tjarvi at qbang.org Sun Mar 26 11:40:12 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 26 Mar 2006 11:40:12 -0700 (MST) Subject: [Rxtx] Error 0x5 at /home/bob/foo/tar/rxtx-2.1-7/build/../src/termios.c(860): Access is, denied. In-Reply-To: <4426A603.80508@gmail.com> References: <4426A603.80508@gmail.com> Message-ID: On Sun, 26 Mar 2006, Beat Arnet wrote: > Dear all, > > When trying to open the serial port, I sometimes (not always) run into > the following exception (when opening the serialPort): > > Error 0x5 at /home/bob/foo/tar/rxtx-2.1-7/build/../src/termios.c(860): > Access is > denied. > > java.lang.UnsatisfiedLinkError: native_psmisc_report_owner > at gnu.io.CommPortIdentifier.native_psmisc_report_owner(Native > Method) > at gnu.io.CommPortIdentifier.open(CommPortIdentifier.java:354) > at codeskin.tools.CLLoader.open(CLLoader.java:79) > at codeskin.tools.C2000Programmer.run(C2000Programmer.java:220) > at java.lang.Thread.run(Unknown Source) > > Is this the type of error where I should just try to open the port again, > or can it be avoided? > Hi Beat We did a second build of rxtx 2.1-7 to resolve that unsatisfied link error. It should work now. rxtx is trying to tell you it thinks someone else has the serial port open. You can try to open the port again but maybe you already have a copy of the program running when it happens? ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7r2.zip fixed build. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sun Mar 26 11:44:23 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 26 Mar 2006 11:44:23 -0700 (MST) Subject: [Rxtx] RXTX spec file (fwd) Message-ID: This is probably interesting for fedora/suse users. ---------- Forwarded message ---------- Date: Sun, 26 Mar 2006 16:25:45 +0200 To: taj at www.linux.org.uk Subject: RXTX spec file I send you this spec file which allows to create a RPM for Fedora 4, 5 (x86, x86_64) with Java Sun. -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: rxtx.spec Url: http://mailman.qbang.org/pipermail/rxtx/attachments/20060326/6c7b6af6/rxtx-0014.pl From tjarvi at qbang.org Sun Mar 26 23:42:59 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 26 Mar 2006 23:42:59 -0700 (MST) Subject: [Rxtx] Upcomming events. Message-ID: This Wednesday we will be announcing a new "Maintainer" for the rxtx project. The position is more like neutral leader. I wont be going away or doing less. This is just the right thing to do as it turns out the two people with CVS write access will be at the same company. We need a third and we need neutrality. The maintainer will have final say in any conflict and will try to be neutral. It will be open for discussion. Then we will do it :) I'll still do most of the footwork I do now. But. I'm falling behind. I should have gone through the mail-list and posted the next round of changes this weekend. I'm packing to move and its going so so - 13 years of toys collected. I suspect there will be a dead period on my part (a couple weeks) comming up. But if you get it on the mail-list, we will get it in if there are no objections. I may well not be reading the mail-list during this period as I look for a house and many other things. I hope everyone will help out. Thanks -- Trent Jarvi tjarvi at qbang.org From mahmoud_hadad at yahoo.com Sun Mar 26 07:31:19 2006 From: mahmoud_hadad at yahoo.com (ronan nick) Date: Sun, 26 Mar 2006 06:31:19 -0800 (PST) Subject: [Rxtx] a question about the COMM API Message-ID: <20060326143119.54919.qmail@web60014.mail.yahoo.com> hi, i was intrested in knowing how i can communicate with my internal modem using java? for example if i want to make a phone dialer application or a caller id application where should i be looking at? and as i understood the COMM API is for devices that is attached to the computer through serial ports. --------------------------------- New Yahoo! Messenger with Voice. Call regular phones from your PC and save big. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060326/ce8329f0/attachment-0016.html From dmarkman at mac.com Mon Mar 20 00:20:43 2006 From: dmarkman at mac.com (Dmitry Markman) Date: Mon, 20 Mar 2006 02:20:43 -0500 Subject: [Rxtx] Mac OS X RXTX java installer In-Reply-To: References: <07D0DE29-BA32-4CFE-B036-66BC6423D385@buechse.de> <441AE3E0.2030503@willicon.de> <12531986.1142622114996.JavaMail.dmarkman@mac.com> <441B2674.9010409@willicon.de> <13577405.1142634732776.JavaMail.dmarkman@mac.com> <441B4182.8010407@willicon.de> <92CD0D6C-5BE8-426E-A46D-99452059FF49@mac.com> <441BBB2D.8030305@willicon.de> <441C4088.5090905@willicon.de> Message-ID: <64BC1E23-FDDE-4CE6-8863-CFC881CBC224@mac.com> Hi all I put RXTX installer that will install everything (and will create / var/lock if necessary and add user to the uucp group) for mac os x from Java into the rxtx's CVS repository it could be easily modified to install files for any platform it uses Greg Guerin's AuthKit for authentication and authorization Greg released that kit under artistic license, so Trent, please take a look we, probably, can negotiate license with Greg if it's necessary Greg's AuthKit could be downloaded from http://www.amug.org/~glguerin/ sw/#authkit Michael Hall (mikehall at spacestar dot net) had a suggestion to make implementation of the jaas LoginModule based on Greg's AuthKit (his modification of the Greg's AuthKit could be found at http:// www.spacestar.net/users/mikehall/authkit.dmg) but Michael's AuthKitLoginModule does only half a job: it does authenticate but it can not run any external unix process in privileged mode (at least I wasn't able to do so) possible explanation could be found in conversation between Greg and Michael at Apple's java-dev list (look for archives) so I didn't use jaas API for rxtxinstaller I created folder MacOSX in the contrib folder comment 1. if you want to run that installer as standalone application all you need that RXTXInstaller.jar 2. if you want to use webstart you have to add Greg's libAuthKit.jnilib to the mac os x's resources in theory RXTXInstaller.jar doesn't need it, but there is a problem with loading libAuthKit.jnilib from webstart authkit uses loadLibrary method to load library and it failed (from webstart) for standalone application I extract libAuthKit.jnilib from the RXTXInstaller.jar and put it into the /Library/Java/Extensions or ~/Library/Java/Extensions folder that file will be deleted after installer quit unfortunately I didn't have time to put documentation there but it is mostly self-explanatory I took installer code from my gl4java installer that I did about 3 years ago (with small modifications) it would be very nice if Apple will release LoginModule that really will do the job (com.apple.security.auth.module package????? ) (UnixLoginModule is pretty useless) From lyon at docjava.com Mon Mar 20 06:34:39 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Mon, 20 Mar 2006 08:34:39 -0500 Subject: [Rxtx] Mac OS X RXTX java installer In-Reply-To: <64BC1E23-FDDE-4CE6-8863-CFC881CBC224@mac.com> References: <07D0DE29-BA32-4CFE-B036-66BC6423D385@buechse.de> <441AE3E0.2030503@willicon.de> <12531986.1142622114996.JavaMail.dmarkman@mac.com> <441B2674.9010409@willicon.de> <13577405.1142634732776.JavaMail.dmarkman@mac.com> <441B4182.8010407@willicon.de> <92CD0D6C-5BE8-426E-A46D-99452059FF49@mac.com> <441BBB2D.8030305@willicon.de> <441C4088.5090905@willicon.de> <64BC1E23-FDDE-4CE6-8863-CFC881CBC224@mac.com> Message-ID: Hi Dimitry, This sounds like great work. Just a couple of questions; After the check out of the CVS files, using: setenv CVSROOT :pserver:anonymous at cvs.milestonesolutions.com:/usr/local/cvsroot 53 8:28 setenv PASSWORD mousy 54 8:29 cvs login 55 8:29 cvs checkout rxtx-devel I cd'd over to: rxtx-devel/MACOSX_IDE And found: CVS/ CW/ ForPackageMaker/ PB/ Where is the installer? Thanks! - Doug From tjarvi at qbang.org Mon Mar 20 06:39:37 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 20 Mar 2006 06:39:37 -0700 (MST) Subject: [Rxtx] Mac OS X RXTX java installer In-Reply-To: References: <07D0DE29-BA32-4CFE-B036-66BC6423D385@buechse.de> <441AE3E0.2030503@willicon.de> <12531986.1142622114996.JavaMail.dmarkman@mac.com> <441B2674.9010409@willicon.de> <13577405.1142634732776.JavaMail.dmarkman@mac.com> <441B4182.8010407@willicon.de> <92CD0D6C-5BE8-426E-A46D-99452059FF49@mac.com> <441BBB2D.8030305@willicon.de> <441C4088.5090905@willicon.de> <64BC1E23-FDDE-4CE6-8863-CFC881CBC224@mac.com> Message-ID: On Mon, 20 Mar 2006, Dr. Douglas Lyon wrote: > Hi Dimitry, > This sounds like great work. Just a couple of questions; > After the check out of the CVS files, using: > setenv CVSROOT > :pserver:anonymous at cvs.milestonesolutions.com:/usr/local/cvsroot > 53 8:28 setenv PASSWORD mousy > 54 8:29 cvs login > 55 8:29 cvs checkout rxtx-devel Hi Doug You want "cvs checkout -r commapi-0-0-1 rxtx-devel" to get RXTX 2.1 The default branch is rxtx 2.0 which isn't very active right now. -- Trent Jarvi tjarvi at qbang.org From lyon at docjava.com Mon Mar 20 07:05:44 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Mon, 20 Mar 2006 09:05:44 -0500 Subject: [Rxtx] Mac OS X RXTX java installer In-Reply-To: References: <07D0DE29-BA32-4CFE-B036-66BC6423D385@buechse.de> <441AE3E0.2030503@willicon.de> <12531986.1142622114996.JavaMail.dmarkman@mac.com> <441B2674.9010409@willicon.de> <13577405.1142634732776.JavaMail.dmarkman@mac.com> <441B4182.8010407@willicon.de> <92CD0D6C-5BE8-426E-A46D-99452059FF49@mac.com> <441BBB2D.8030305@willicon.de> <441C4088.5090905@willicon.de> <64BC1E23-FDDE-4CE6-8863-CFC881CBC224@mac.com> Message-ID: Hi Trent, Thanks for the info on the CVS checkout procedure. I did that and am still not sure where the installer is. Here is what I have: cd MACOSX_IDE/ p4.docjava.com{lyon}121: ls CVS/ ForPackageMaker/ PB/ p4.docjava.com{lyon}122: find . | more . ./ForPackageMaker ./ForPackageMaker/RXTX.pkg.sit.hqx ./ForPackageMaker/Resources ./ForPackageMaker/Resources/ReadMe.rtf ./ForPackageMaker/Resources/Welcome.rtf ./ForPackageMaker/Resources/CVS ./ForPackageMaker/Resources/CVS/Entries ./ForPackageMaker/Resources/CVS/Repository ./ForPackageMaker/Resources/CVS/Tag ./ForPackageMaker/Resources/CVS/Root ./ForPackageMaker/Resources/preinstall ./ForPackageMaker/Resources/License.rtf ./ForPackageMaker/Resources/preupgrade ./ForPackageMaker/RXTX.pmsp ./ForPackageMaker/CVS ./ForPackageMaker/CVS/Entries ./ForPackageMaker/CVS/Repository ./ForPackageMaker/CVS/Entries.Log ./ForPackageMaker/CVS/Tag ./ForPackageMaker/CVS/Root ./ForPackageMaker/RXTX_Tiger.pkg.sitx.hqx ./ForPackageMaker/RXTX_Jag.pkg.sit.hqx ./ForPackageMaker/Install ./ForPackageMaker/Install/CVS ./ForPackageMaker/Install/CVS/Entries ./ForPackageMaker/Install/CVS/Repository ./ForPackageMaker/Install/CVS/Tag ./ForPackageMaker/Install/CVS/Root ./ForPackageMaker/Install/Library ./ForPackageMaker/Install/Library/CVS ./ForPackageMaker/Install/Library/CVS/Entries ./ForPackageMaker/Install/Library/CVS/Repository ./ForPackageMaker/Install/Library/CVS/Tag ./ForPackageMaker/Install/Library/CVS/Root ./ForPackageMaker/Install/Library/Java ./ForPackageMaker/Install/Library/Java/Extensions ./ForPackageMaker/Install/Library/Java/Extensions/RXTXcomm.jar ./ForPackageMaker/Install/Library/Java/Extensions/CVS ./ForPackageMaker/Install/Library/Java/Extensions/CVS/Entries ./ForPackageMaker/Install/Library/Java/Extensions/CVS/Repository ./ForPackageMaker/Install/Library/Java/Extensions/CVS/Tag ./ForPackageMaker/Install/Library/Java/Extensions/CVS/Root ./ForPackageMaker/Install/Library/Java/Extensions/librxtxSerial.jnilib ./ForPackageMaker/Install/Library/Java/CVS ./ForPackageMaker/Install/Library/Java/CVS/Entries ./ForPackageMaker/Install/Library/Java/CVS/Repository ./ForPackageMaker/Install/Library/Java/CVS/Entries.Log ./ForPackageMaker/Install/Library/Java/CVS/Tag ./ForPackageMaker/Install/Library/Java/CVS/Root ./ForPackageMaker/RXTX_Tiger.pmproj.sitx.hqx ./CVS ./CVS/Entries ./CVS/Repository ./CVS/Entries.Log ./CVS/Tag ./CVS/Root ./PB ./PB/LibSerialUniversal.xcodeproj.sitx.hqx ./PB/CVS ./PB/CVS/Entries ./PB/CVS/Repository ./PB/CVS/Entries.Log ./PB/CVS/Tag ./PB/CVS/Root ./PB/LibSerial.pbproj.sit.hqx ./PB/startpoint.c ./PB/config.h What is the procedure to run this installer? Do we need a README in: /rxtx-devel/MACOSX_IDE Here is what we have: CVS/ ForPackageMaker/ PB/ Thanks! - DL >On Mon, 20 Mar 2006, Dr. Douglas Lyon wrote: > >>Hi Dimitry, >>This sounds like great work. Just a couple of questions; >>After the check out of the CVS files, using: >>setenv CVSROOT >>:pserver:anonymous at cvs.milestonesolutions.com:/usr/local/cvsroot >> 53 8:28 setenv PASSWORD mousy >> 54 8:29 cvs login >> 55 8:29 cvs checkout rxtx-devel > >Hi Doug > >You want "cvs checkout -r commapi-0-0-1 rxtx-devel" to get RXTX 2.1 >The default branch is rxtx 2.0 which isn't very active right now. > >-- >Trent Jarvi >tjarvi at qbang.org From tjarvi at qbang.org Mon Mar 20 07:25:30 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 20 Mar 2006 07:25:30 -0700 (MST) Subject: [Rxtx] Mac OS X RXTX java installer In-Reply-To: References: <07D0DE29-BA32-4CFE-B036-66BC6423D385@buechse.de> <441AE3E0.2030503@willicon.de> <12531986.1142622114996.JavaMail.dmarkman@mac.com> <441B2674.9010409@willicon.de> <13577405.1142634732776.JavaMail.dmarkman@mac.com> <441B4182.8010407@willicon.de> <92CD0D6C-5BE8-426E-A46D-99452059FF49@mac.com> <441BBB2D.8030305@willicon.de> <441C4088.5090905@willicon.de> <64BC1E23-FDDE-4CE6-8863-CFC881CBC224@mac.com> Message-ID: On Mon, 20 Mar 2006, Dr. Douglas Lyon wrote: > Hi Trent, > Thanks for the info on the CVS checkout procedure. > I did that and am still not sure where the installer is. Hi Doug It does look like it was not cvs committed. There is no rxtx-devel/contrib/MacOSX directory in there at the moment. It was mentioned that it was put under contrib. -- Trent Jarvi tjarvi at qbang.org From dmarkman at mac.com Mon Mar 20 07:29:56 2006 From: dmarkman at mac.com (Dmitry Markman) Date: Mon, 20 Mar 2006 09:29:56 -0500 Subject: [Rxtx] Mac OS X RXTX java installer In-Reply-To: References: <07D0DE29-BA32-4CFE-B036-66BC6423D385@buechse.de> <441AE3E0.2030503@willicon.de> <12531986.1142622114996.JavaMail.dmarkman@mac.com> <441B2674.9010409@willicon.de> <13577405.1142634732776.JavaMail.dmarkman@mac.com> <441B4182.8010407@willicon.de> <92CD0D6C-5BE8-426E-A46D-99452059FF49@mac.com> <441BBB2D.8030305@willicon.de> <441C4088.5090905@willicon.de> <64BC1E23-FDDE-4CE6-8863-CFC881CBC224@mac.com> Message-ID: <6054EB4E-F7E0-4A9C-BDDA-D582D6D8826F@mac.com> you can find it in the rxtx-devel/contrib folder On Mar 20, 2006, at 9:05 AM, Dr. Douglas Lyon wrote: > Hi Trent, > Thanks for the info on the CVS checkout procedure. > I did that and am still not sure where the installer is. > Here is what I have: > cd MACOSX_IDE/ > p4.docjava.com{lyon}121: ls > CVS/ ForPackageMaker/ PB/ > p4.docjava.com{lyon}122: find . | more > . > ./ForPackageMaker > ./ForPackageMaker/RXTX.pkg.sit.hqx > ./ForPackageMaker/Resources > ./ForPackageMaker/Resources/ReadMe.rtf > ./ForPackageMaker/Resources/Welcome.rtf > ./ForPackageMaker/Resources/CVS > ./ForPackageMaker/Resources/CVS/Entries > ./ForPackageMaker/Resources/CVS/Repository > ./ForPackageMaker/Resources/CVS/Tag > ./ForPackageMaker/Resources/CVS/Root > ./ForPackageMaker/Resources/preinstall > ./ForPackageMaker/Resources/License.rtf > ./ForPackageMaker/Resources/preupgrade > ./ForPackageMaker/RXTX.pmsp > ./ForPackageMaker/CVS > ./ForPackageMaker/CVS/Entries > ./ForPackageMaker/CVS/Repository > ./ForPackageMaker/CVS/Entries.Log > ./ForPackageMaker/CVS/Tag > ./ForPackageMaker/CVS/Root > ./ForPackageMaker/RXTX_Tiger.pkg.sitx.hqx > ./ForPackageMaker/RXTX_Jag.pkg.sit.hqx > ./ForPackageMaker/Install > ./ForPackageMaker/Install/CVS > ./ForPackageMaker/Install/CVS/Entries > ./ForPackageMaker/Install/CVS/Repository > ./ForPackageMaker/Install/CVS/Tag > ./ForPackageMaker/Install/CVS/Root > ./ForPackageMaker/Install/Library > ./ForPackageMaker/Install/Library/CVS > ./ForPackageMaker/Install/Library/CVS/Entries > ./ForPackageMaker/Install/Library/CVS/Repository > ./ForPackageMaker/Install/Library/CVS/Tag > ./ForPackageMaker/Install/Library/CVS/Root > ./ForPackageMaker/Install/Library/Java > ./ForPackageMaker/Install/Library/Java/Extensions > ./ForPackageMaker/Install/Library/Java/Extensions/RXTXcomm.jar > ./ForPackageMaker/Install/Library/Java/Extensions/CVS > ./ForPackageMaker/Install/Library/Java/Extensions/CVS/Entries > ./ForPackageMaker/Install/Library/Java/Extensions/CVS/Repository > ./ForPackageMaker/Install/Library/Java/Extensions/CVS/Tag > ./ForPackageMaker/Install/Library/Java/Extensions/CVS/Root > ./ForPackageMaker/Install/Library/Java/Extensions/librxtxSerial.jnilib > ./ForPackageMaker/Install/Library/Java/CVS > ./ForPackageMaker/Install/Library/Java/CVS/Entries > ./ForPackageMaker/Install/Library/Java/CVS/Repository > ./ForPackageMaker/Install/Library/Java/CVS/Entries.Log > ./ForPackageMaker/Install/Library/Java/CVS/Tag > ./ForPackageMaker/Install/Library/Java/CVS/Root > ./ForPackageMaker/RXTX_Tiger.pmproj.sitx.hqx > ./CVS > ./CVS/Entries > ./CVS/Repository > ./CVS/Entries.Log > ./CVS/Tag > ./CVS/Root > ./PB > ./PB/LibSerialUniversal.xcodeproj.sitx.hqx > ./PB/CVS > ./PB/CVS/Entries > ./PB/CVS/Repository > ./PB/CVS/Entries.Log > ./PB/CVS/Tag > ./PB/CVS/Root > ./PB/LibSerial.pbproj.sit.hqx > ./PB/startpoint.c > ./PB/config.h > > What is the procedure to run this installer? > Do we need a README in: > /rxtx-devel/MACOSX_IDE > Here is what we have: > CVS/ ForPackageMaker/ PB/ > > > Thanks! > - DL > >> On Mon, 20 Mar 2006, Dr. Douglas Lyon wrote: >> >>> Hi Dimitry, >>> This sounds like great work. Just a couple of questions; >>> After the check out of the CVS files, using: >>> setenv CVSROOT :pserver:anonymous at cvs.milestonesolutions.com:/usr/ >>> local/cvsroot >>> 53 8:28 setenv PASSWORD mousy >>> 54 8:29 cvs login >>> 55 8:29 cvs checkout rxtx-devel >> >> Hi Doug >> >> You want "cvs checkout -r commapi-0-0-1 rxtx-devel" to get RXTX 2.1 >> The default branch is rxtx 2.0 which isn't very active right now. >> >> -- >> Trent Jarvi >> tjarvi at qbang.org > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx Dmitry Markman From mikehall at spacestar.net Mon Mar 20 05:25:25 2006 From: mikehall at spacestar.net (Michael Hall) Date: Mon, 20 Mar 2006 06:25:25 -0600 Subject: [Rxtx] Re: Mac OS X RXTX java installer In-Reply-To: <64BC1E23-FDDE-4CE6-8863-CFC881CBC224@mac.com> References: <07D0DE29-BA32-4CFE-B036-66BC6423D385@buechse.de> <441AE3E0.2030503@willicon.de> <12531986.1142622114996.JavaMail.dmarkman@mac.com> <441B2674.9010409@willicon.de> <13577405.1142634732776.JavaMail.dmarkman@mac.com> <441B4182.8010407@willicon.de> <92CD0D6C-5BE8-426E-A46D-99452059FF49@mac.com> <441BBB2D.8030305@willicon.de> <441C4088.5090905@willicon.de> <64BC1E23-FDDE-4CE6-8863-CFC881CBC224@mac.com> Message-ID: <247EB61F-5CD1-4132-89A2-FC105B6CF9A5@spacestar.net> On Mar 20, 2006, at 1:20 AM, Dmitry Markman wrote: > > Michael Hall (mikehall at spacestar dot net) had a suggestion to > make implementation of the jaas LoginModule > based on Greg's AuthKit > (his modification of the Greg's AuthKit could be found at http:// > www.spacestar.net/users/mikehall/authkit.dmg) > but Michael's AuthKitLoginModule does only half a job: > it does authenticate > but it can not run any external unix process in privileged mode (at > least I wasn't able to do so) If you got it working directly with Greg's the point is moot. But to clarify it anyhow. The login module does not allow you to do anything anything privileged on return as was explained by Greg. You need to work with a separate privileged process using the execPrivileged method of his API. I assume you did something similar although I haven't looked at how you are using it yet. I allowed instead for a action to be performed at the same time you login/authenticate,this... System.setProperty("authkit.action","/usr/bin/id"); just before this... lc.login(); To clarify, safely ignored as you are already complete. Mike Hall mikehall at spacestar dot net http://www.spacestar.net/users/mikehall http://sourceforge.net/projects/macnative -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2427 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20060320/f6e18202/smime-0019.bin From dmarkman at mac.com Mon Mar 20 07:36:47 2006 From: dmarkman at mac.com (Dmitry Markman) Date: Mon, 20 Mar 2006 09:36:47 -0500 Subject: [Rxtx] Re: Mac OS X RXTX java installer In-Reply-To: <247EB61F-5CD1-4132-89A2-FC105B6CF9A5@spacestar.net> References: <07D0DE29-BA32-4CFE-B036-66BC6423D385@buechse.de> <441AE3E0.2030503@willicon.de> <12531986.1142622114996.JavaMail.dmarkman@mac.com> <441B2674.9010409@willicon.de> <13577405.1142634732776.JavaMail.dmarkman@mac.com> <441B4182.8010407@willicon.de> <92CD0D6C-5BE8-426E-A46D-99452059FF49@mac.com> <441BBB2D.8030305@willicon.de> <441C4088.5090905@willicon.de> <64BC1E23-FDDE-4CE6-8863-CFC881CBC224@mac.com> <247EB61F-5CD1-4132-89A2-FC105B6CF9A5@spacestar.net> Message-ID: Hi, Michael all I have to do is to run some shell script I tried to use your action mechanism and it worked great so I just System.setProperty ("authkit.action","" ) and after that I even don't need to run anything like subject.doAs.... but after few thoughts I choose to use plain Greg's approach, because in that case I don't have to deal with various java's configurations files and therefore to use 2-3 -D parameters in the java command line especially it's useful for java web start (it's so fragile :-( ) thanks for the great job On Mar 20, 2006, at 7:25 AM, Michael Hall wrote: > > On Mar 20, 2006, at 1:20 AM, Dmitry Markman wrote: >> >> Michael Hall (mikehall at spacestar dot net) had a suggestion to >> make implementation of the jaas LoginModule >> based on Greg's AuthKit >> (his modification of the Greg's AuthKit could be found at http:// >> www.spacestar.net/users/mikehall/authkit.dmg) >> but Michael's AuthKitLoginModule does only half a job: >> it does authenticate >> but it can not run any external unix process in privileged mode >> (at least I wasn't able to do so) > > If you got it working directly with Greg's the point is moot. > > But to clarify it anyhow. > The login module does not allow you to do anything anything > privileged on return as was explained by Greg. You need to work > with a separate privileged process using the execPrivileged method > of his API. I assume you did something similar although I haven't > looked at how you are using it yet. > I allowed instead for a action to be performed at the same time you > login/authenticate,this... > System.setProperty("authkit.action","/usr/bin/id"); > just before this... > lc.login(); > To clarify, safely ignored as you are already complete. > > Mike Hall mikehall at spacestar dot net > http://www.spacestar.net/users/mikehall > http://sourceforge.net/projects/macnative > > > Dmitry Markman From dmarkman at mac.com Mon Mar 20 07:44:45 2006 From: dmarkman at mac.com (Dmitry Markman) Date: Mon, 20 Mar 2006 09:44:45 -0500 Subject: [Rxtx] Mac OS X RXTX java installer In-Reply-To: References: <07D0DE29-BA32-4CFE-B036-66BC6423D385@buechse.de> <441AE3E0.2030503@willicon.de> <12531986.1142622114996.JavaMail.dmarkman@mac.com> <441B2674.9010409@willicon.de> <13577405.1142634732776.JavaMail.dmarkman@mac.com> <441B4182.8010407@willicon.de> <92CD0D6C-5BE8-426E-A46D-99452059FF49@mac.com> <441BBB2D.8030305@willicon.de> <441C4088.5090905@willicon.de> <64BC1E23-FDDE-4CE6-8863-CFC881CBC224@mac.com> Message-ID: it's in the commapi-0-0-1 branch I tested it right now: cvs co -r commapi-0-0-1 rxtx-devel and I got everything On Mar 20, 2006, at 9:25 AM, Trent Jarvi wrote: > On Mon, 20 Mar 2006, Dr. Douglas Lyon wrote: > >> Hi Trent, >> Thanks for the info on the CVS checkout procedure. >> I did that and am still not sure where the installer is. > > Hi Doug > > It does look like it was not cvs committed. There is no rxtx-devel/ > contrib/MacOSX directory in there at the moment. It was mentioned > that it was put under contrib. > > -- > Trent Jarvi > tjarvi at qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx Dmitry Markman From tjarvi at qbang.org Mon Mar 20 07:52:57 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 20 Mar 2006 07:52:57 -0700 (MST) Subject: [Rxtx] Mac OS X RXTX java installer In-Reply-To: References: <07D0DE29-BA32-4CFE-B036-66BC6423D385@buechse.de> <441AE3E0.2030503@willicon.de> <12531986.1142622114996.JavaMail.dmarkman@mac.com> <441B2674.9010409@willicon.de> <13577405.1142634732776.JavaMail.dmarkman@mac.com> <441B4182.8010407@willicon.de> <92CD0D6C-5BE8-426E-A46D-99452059FF49@mac.com> <441BBB2D.8030305@willicon.de> <441C4088.5090905@willicon.de> <64BC1E23-FDDE-4CE6-8863-CFC881CBC224@mac.com> Message-ID: On Mon, 20 Mar 2006, Dmitry Markman wrote: > it's in the commapi-0-0-1 branch > > I tested it right now: > cvs co -r commapi-0-0-1 rxtx-devel > > and I got everything > A fresh checkout worked. Here is a copy of the tree (just the installer bits) ftp://ftp.qbang.org/pub/rxtx/MacOSX-installer.zip -- Trent Jarvi tjarvi at qbang.org From lyon at docjava.com Mon Mar 20 08:08:26 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Mon, 20 Mar 2006 10:08:26 -0500 Subject: [Rxtx] Mac OS X RXTX java installer In-Reply-To: References: <07D0DE29-BA32-4CFE-B036-66BC6423D385@buechse.de> <441AE3E0.2030503@willicon.de> <12531986.1142622114996.JavaMail.dmarkman@mac.com> <441B2674.9010409@willicon.de> <13577405.1142634732776.JavaMail.dmarkman@mac.com> <441B4182.8010407@willicon.de> <92CD0D6C-5BE8-426E-A46D-99452059FF49@mac.com> <441BBB2D.8030305@willicon.de> <441C4088.5090905@willicon.de> <64BC1E23-FDDE-4CE6-8863-CFC881CBC224@mac.com> Message-ID: Hi All, Is the Auth package able to work properly on non Mac OS's? It was not clear from the doc or download. Thanks! - Doug From dmarkman at mac.com Mon Mar 20 08:15:22 2006 From: dmarkman at mac.com (Dmitry Markman) Date: Mon, 20 Mar 2006 10:15:22 -0500 Subject: [Rxtx] Mac OS X RXTX java installer In-Reply-To: References: <07D0DE29-BA32-4CFE-B036-66BC6423D385@buechse.de> <441AE3E0.2030503@willicon.de> <12531986.1142622114996.JavaMail.dmarkman@mac.com> <441B2674.9010409@willicon.de> <13577405.1142634732776.JavaMail.dmarkman@mac.com> <441B4182.8010407@willicon.de> <92CD0D6C-5BE8-426E-A46D-99452059FF49@mac.com> <441BBB2D.8030305@willicon.de> <441C4088.5090905@willicon.de> <64BC1E23-FDDE-4CE6-8863-CFC881CBC224@mac.com> Message-ID: <217312D8-CCCA-4859-ABA6-32DF1CC817B9@mac.com> thanks Trent, for putting it on ftp server On Mar 20, 2006, at 9:52 AM, Trent Jarvi wrote: > A fresh checkout worked. Here is a copy of the tree (just the > installer bits) > > ftp://ftp.qbang.org/pub/rxtx/MacOSX-installer.zip > Dmitry Markman From dmarkman at mac.com Mon Mar 20 09:14:03 2006 From: dmarkman at mac.com (Dmitry Markman) Date: Mon, 20 Mar 2006 11:14:03 -0500 Subject: [Rxtx] Mac OS X RXTX java installer In-Reply-To: References: <07D0DE29-BA32-4CFE-B036-66BC6423D385@buechse.de> <441AE3E0.2030503@willicon.de> <12531986.1142622114996.JavaMail.dmarkman@mac.com> <441B2674.9010409@willicon.de> <13577405.1142634732776.JavaMail.dmarkman@mac.com> <441B4182.8010407@willicon.de> <92CD0D6C-5BE8-426E-A46D-99452059FF49@mac.com> <441BBB2D.8030305@willicon.de> <441C4088.5090905@willicon.de> <64BC1E23-FDDE-4CE6-8863-CFC881CBC224@mac.com> Message-ID: <4DEBA6F0-DA45-4E84-823E-1F1AC48BDCCC@mac.com> no it will work only on mac os x however it's harmless to run it on other platform if you want to use it for other platform you have to do the following (I'll do it for linux) 1. modify RXTXInstaller class method public static RXTXInstaller getInstance() public static RXTXInstaller getInstance() { String osName = System.getProperty("os.name").toLowerCase(); if(osName.startsWith("mac")){ return new gnu.io.installer.macosx.MACOSXRXTXInstaller(); } else if(osName.startsWith("windows")){ return new gnu.io.installer.windows.WindowsRXTXInstaller(); }else if(osName.startsWith("linux")){ return new gnu.io.installer.linux.LinuxRXTXInstaller(); } return null; } 2. create folder gnu/io/installer/linux/ 3. create class Linux386RXTXInstaller package gnu.io.installer.linux; import java.io.File; public class Linux386RXTXInstaller extends gnu.io.installer.RXTXInstaller{ public Linux386RXTXInstaller(){ createJarFolder(); createLibFolder(); addJarResource("RXTXcomm.jar","/gnu/io/installer/resources/ linux/jar/RXTXcomm.dat"); addLibResource("librxtxSerial.so","/gnu/io/installer/ resources/linux/lib/librxtxSerial.so"); } protected void createJarFolder(){ String javaHome = System.getProperty("java.home"); char separator = File.separatorChar; jarFolder = new File(javaHome+separator+"lib"+separator+"ext"); } protected void createLibFolder(){ String javaHome = System.getProperty("java.home"); char separator = File.separatorChar; libFolder = new File(javaHome+separator+"bin"); } public void runPreProcess() {} //put here some action you need public void runPostProcess() {} //put here some action you need } 4. create folder /gnu/io/installer/resources/linux/jar and put there linux's version of RXTXcomm.dat (which is renamed RXTXcomm.jar) 5. create folder /gnu/io/installer/resources/linux/lib and put there linux's version of librxtxSerial. so 6. make sure that RXTXInstaller.jar has the following items: /gnu/io/installer/resources/linux/jar/RXTXcomm.jar /gnu/io/installer/resources/linux/lib/librxtxSerial.so 7. modify file installer.pref: jar file RXTXInstaller.jar must have the following item /gnu/io/installer/installer.pref that's basically it for windows you have to do the similar things: just replace linux to windows and librxtxSerial.so to rxtxSerial.dll and create appropriate gnu.io.installer.windows.WindowsRXTXInstaller class package gnu.io.installer.windows; import java.io.File; public class WindowsRXTXInstaller extends gnu.io.installer.RXTXInstaller{ public WindowsRXTXInstaller(){ createJarFolder(); createLibFolder(); addJarResource("RXTXcomm.jar","/gnu/io/installer/resources/ windows/jar/RXTXcomm.dat"); addLibResource("librxtxSerial.so","/gnu/io/installer/ resources/windows/lib/rxtxSerial.dll"); } protected void createJarFolder(){ String javaHome = System.getProperty("java.home"); char separator = File.separatorChar; jarFolder = new File(javaHome+separator+"lib"+separator+"ext"); } protected void createLibFolder(){ String javaHome = System.getProperty("java.home"); char separator = File.separatorChar; libFolder = new File(javaHome+separator+"bin"); } public void runPreProcess() {} //put here some action you need public void runPostProcess() {} //put here some action you need } installer.pref will look like On Mar 20, 2006, at 10:08 AM, Dr. Douglas Lyon wrote: > Hi All, > Is the Auth package able to work properly on > non Mac OS's? > It was not clear from the doc or download. > > Thanks! > - Doug > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx Dmitry Markman From joachim at buechse.de Mon Mar 20 10:49:06 2006 From: joachim at buechse.de (Joachim Buechse) Date: Mon, 20 Mar 2006 18:49:06 +0100 Subject: [Rxtx] BUG: Lock file stays even if port opening fails Message-ID: This was only tested on MacOSX but looking at the code, it should be true for all systems that use lock_uucp. I am opening a port which can not be opened (dialup port of a telephone paired via bluetooth but currently not reachable). The lock file is created and stays arround, even though the port open failed. After looking a bit through the code (of 2.17), I really wonder if it wouldn't be a good idea to make the "locking" an explicit operation called from the java code. This would certainly simplify the generation of meaningfull exceptions (and java based debugging). Maybe even the handling of "preopened" ports should be in the Java part of the lib (again for java based debugging puposes). That beeing said, I have no idea if this would be possible for the 2.07 implementation. Regards, Joachim From tjarvi at qbang.org Mon Mar 20 11:24:22 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 20 Mar 2006 11:24:22 -0700 (MST) Subject: [Rxtx] BUG: Lock file stays even if port opening fails In-Reply-To: References: Message-ID: On Mon, 20 Mar 2006, Joachim Buechse wrote: > This was only tested on MacOSX but looking at the code, it should be true > for all systems that use lock_uucp. > > I am opening a port which can not be opened (dialup port of a telephone > paired via bluetooth but currently not reachable). The lock file is > created and stays arround, even though the port open failed. > > > After looking a bit through the code (of 2.17), I really wonder if it > wouldn't be a good idea to make the "locking" an explicit operation > called from the java code. This would certainly simplify the generation > of meaningfull exceptions (and java based debugging). > Maybe even the handling of "preopened" ports should be in the Java part > of the lib (again for java based debugging puposes). That beeing said, I > have no idea if this would be possible for the 2.07 implementation. > > Regards, Hi Joachim It should be possible in the 2.0-7 implementation too. The calls to RXTXPort.java would not change. We would just do more there Moving more of that logic into Java would be better as many people don't like to look at C code. There is a liblockdev on most Linux distros that can do most of the C code and would be easier to use. The problem is embeded devices will not have that library. The preopened port code has not been really tested. That was a last minute request in a product cycle. I expect it will be tested this year though. As I recall, some devices really do not like CD raising on open. The preopened ports then allow people to mess around in java without power cycling the devices or losing data. -- Trent Jarvi tjarvi at qbang.org From joachim at buechse.de Mon Mar 20 12:01:08 2006 From: joachim at buechse.de (Joachim Buechse) Date: Mon, 20 Mar 2006 20:01:08 +0100 Subject: [Rxtx] BUG: Lock file stays even if port opening fails In-Reply-To: References: Message-ID: Hi Trent, What is your general feeling about moving code to Java? The last days I have been reading quite a bit of the code and there are several things, that might not work as expected. I'll give you two examples from is_device_locked: if LOCKDIR == /var/spool/locks the directory /var/spool/lock will not be checked. LOCKDIR is not checked for lockfiles with unexpected pefixes While these things have probably never been discovered in production, they are still possibly incorrect implementations. If it was Java code, I would write some unit tests producing the errors that could later be corrected. PS: One could imagine to actually implement the whole lockfile handling in Java using some native routines to get the values required (pid, st_dev, st_rdev, ...). On 20.03.2006, at 19:24, Trent Jarvi wrote: > On Mon, 20 Mar 2006, Joachim Buechse wrote: > >> This was only tested on MacOSX but looking at the code, it should >> be true for all systems that use lock_uucp. >> >> I am opening a port which can not be opened (dialup port of a >> telephone paired via bluetooth but currently not reachable). The >> lock file is created and stays arround, even though the port open >> failed. >> >> >> After looking a bit through the code (of 2.17), I really wonder if >> it wouldn't be a good idea to make the "locking" an explicit >> operation called from the java code. This would certainly simplify >> the generation of meaningfull exceptions (and java based debugging). >> Maybe even the handling of "preopened" ports should be in the Java >> part of the lib (again for java based debugging puposes). That >> beeing said, I have no idea if this would be possible for the 2.07 >> implementation. >> >> Regards, > > Hi Joachim > > It should be possible in the 2.0-7 implementation too. The calls > to RXTXPort.java would not change. We would just do more there > Moving more of that logic into Java would be better as many people > don't like to look at C code. There is a liblockdev on most Linux > distros that can do most of the C code and would be easier to use. > The problem is embeded devices will not have that library. > > The preopened port code has not been really tested. That was a > last minute request in a product cycle. I expect it will be tested > this year though. As I recall, some devices really do not like CD > raising on open. The preopened ports then allow people to mess > around in java without power cycling the devices or losing data. > > -- > Trent Jarvi > tjarvi at qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Mon Mar 20 12:21:02 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 20 Mar 2006 12:21:02 -0700 (MST) Subject: [Rxtx] BUG: Lock file stays even if port opening fails In-Reply-To: References: Message-ID: On Mon, 20 Mar 2006, Joachim Buechse wrote: > Hi Trent, > > What is your general feeling about moving code to Java? The last days I > have been reading quite a bit of the code and there are several things, > that might not work as expected. > > I'll give you two examples from is_device_locked: > > if LOCKDIR == /var/spool/locks the directory /var/spool/lock will not be > checked. > LOCKDIR is not checked for lockfiles with unexpected pefixes > > While these things have probably never been discovered in production, > they are still possibly incorrect implementations. If it was Java code, I > would write some unit tests producing the errors that could later be > corrected. > > PS: One could imagine to actually implement the whole lockfile handling > in Java using some native routines to get the values required (pid, > st_dev, st_rdev, ...). Hi Joachim I like the idea of moving more of the code into java but there are some things to consider. If you break this into multiple JNI calls, the performance will drop considerably during enumeration of ports. We are looking for 256 ports per dev type vs (16? in Sun's 2.0 and fewer types). Its hard to make assumptions. I've seen virtual ports start at /dev/foo100 for instance. It works out to over 7500 ports on Linux if you enable them all. We already trim that back by default. See Linux-all-ports in RXTXCommDriver.java. There are also native libraries that rxtx can link to. If you move too much into Java, linking to 'standard' libraries with distros will break. "configure --enable-liblock=yes" will not be doable. This is probably a favorable way with RedHat, Debian, Suse and others. Thats the right thing to do if there will be rpms, dpkg, .. For those reasons, I think it still make sense to keep it to a minimal ~3 calls to JNI code that we can use for speed and versatility. lock() isLocked(), unlock() perhaps. When I say speed, its more about avoiding crossing the JNI layer multiple times than java vs C performance. With versatility I think liblock is the right way for most but not all (embeded) linux distros. -- Trent Jarvi tjarvi at qbang.org From joachim at buechse.de Mon Mar 20 12:42:04 2006 From: joachim at buechse.de (Joachim Buechse) Date: Mon, 20 Mar 2006 20:42:04 +0100 Subject: [Rxtx] BUG: Lock file stays even if port opening fails In-Reply-To: References: Message-ID: <82C19FE7-DDCB-45B6-B2C9-7606B66F0124@buechse.de> Ok, what about providing a default implementation in Java? The RXTXCommDriver would call a (native) function useNativeLocking and if it returns true, call the native functions for lock() isLocked (), unlock(), else is would use the Java based default implementation. This could possibly be overriden by a property (again for debugging). Joachim On 20.03.2006, at 20:21, Trent Jarvi wrote: > On Mon, 20 Mar 2006, Joachim Buechse wrote: > >> Hi Trent, >> >> What is your general feeling about moving code to Java? The last >> days I have been reading quite a bit of the code and there are >> several things, that might not work as expected. >> >> I'll give you two examples from is_device_locked: >> >> if LOCKDIR == /var/spool/locks the directory /var/spool/lock will >> not be checked. >> LOCKDIR is not checked for lockfiles with unexpected pefixes >> >> While these things have probably never been discovered in >> production, they are still possibly incorrect implementations. If >> it was Java code, I would write some unit tests producing the >> errors that could later be corrected. >> >> PS: One could imagine to actually implement the whole lockfile >> handling in Java using some native routines to get the values >> required (pid, st_dev, st_rdev, ...). > > Hi Joachim > > I like the idea of moving more of the code into java but there are > some things to consider. > > If you break this into multiple JNI calls, the performance will > drop considerably during enumeration of ports. We are looking for > 256 ports per dev type vs (16? in Sun's 2.0 and fewer types). Its > hard to make assumptions. I've seen virtual ports start at /dev/ > foo100 for instance. > > It works out to over 7500 ports on Linux if you enable them all. > We already trim that back by default. See Linux-all-ports in > RXTXCommDriver.java. > > There are also native libraries that rxtx can link to. If you move > too much into Java, linking to 'standard' libraries with distros > will break. "configure --enable-liblock=yes" will not be doable. > This is probably a favorable way with RedHat, Debian, Suse and > others. Thats the right thing to do if there will be rpms, dpkg, .. > > For those reasons, I think it still make sense to keep it to a > minimal ~3 calls to JNI code that we can use for speed and > versatility. lock() isLocked(), unlock() perhaps. When I say > speed, its more about avoiding crossing the JNI layer multiple > times than java vs C performance. With versatility I think liblock > is the right way for most but not all (embeded) linux distros. > > -- > Trent Jarvi > tjarvi at qbang.org > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Mon Mar 20 12:44:47 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 20 Mar 2006 12:44:47 -0700 (MST) Subject: [Rxtx] BUG: Lock file stays even if port opening fails In-Reply-To: <82C19FE7-DDCB-45B6-B2C9-7606B66F0124@buechse.de> References: <82C19FE7-DDCB-45B6-B2C9-7606B66F0124@buechse.de> Message-ID: On Mon, 20 Mar 2006, Joachim Buechse wrote: > Ok, what about providing a default implementation in Java? > > The RXTXCommDriver would call a (native) function useNativeLocking and if > it returns true, call the native functions for lock() isLocked(), > unlock(), else is would use the Java based default implementation. This > could possibly be overriden by a property (again for debugging). > Hi Joachim That would be OK with me. -- Trent Jarvi tjarvi at qbang.org From dmarkman at mac.com Mon Mar 20 22:27:45 2006 From: dmarkman at mac.com (Dmitry Markman) Date: Tue, 21 Mar 2006 00:27:45 -0500 Subject: [Rxtx] binaries request Message-ID: <42702213-C222-4937-A585-7CFB17E47608@mac.com> Hi can somebody send me latest linux and windows binaries, please? or where I can find them (I didn't find them in the latest tareball) I gave up with my cygwin: something wrong I have no idea what java doesn't understand /cygwin/c syntax after I changed makefile it did java part but after that gcc 3.4.4 started to complain I set buffer length to 999 lines but I didn't get beginning of the story something wrong with my 1.4.2_09/include/jni.h gcc doesn't like it anyway I gave up thanks in advance Dmitry Markman -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060320/f8cbc57c/attachment-0019.html From tjarvi at qbang.org Mon Mar 20 22:36:48 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 20 Mar 2006 22:36:48 -0700 (MST) Subject: [Rxtx] binaries request In-Reply-To: <42702213-C222-4937-A585-7CFB17E47608@mac.com> References: <42702213-C222-4937-A585-7CFB17E47608@mac.com> Message-ID: On Tue, 21 Mar 2006, Dmitry Markman wrote: > Hi > can somebody send me latest linux and windows binaries, please? > > or where I can find them (I didn't find them in the latest tareball) > > I gave up with my cygwin: something wrong I have no idea what > java doesn't understand /cygwin/c syntax > after I changed makefile it did java part > but after that gcc 3.4.4 started to complain > I set buffer length to 999 lines but I didn't get beginning of the story > something wrong with my 1.4.2_09/include/jni.h gcc doesn't like it > anyway I gave up > > thanks in advance > Hi Dmitry The bins are here: ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7-bins-r2.zip Here are the files in the zip you want. Jar: rxtx-2.1-7-bins-r2/RXTXcomm.jar Windows: rxtx-2.1-7-bins-r2/Windows/i368-mingw32/rxtxSerial.dll Linux (x86) rxtx-2.1-7-bins-r2/Linux/i686-unknown-linux-gnu/librxtxSerial.so There are others in there including Parallel port support but those are the main ones for testing. -- Trent Jarvi tjarvi at qbang.org From dmarkman at mac.com Mon Mar 20 23:05:59 2006 From: dmarkman at mac.com (Dmitry Markman) Date: Tue, 21 Mar 2006 01:05:59 -0500 Subject: [Rxtx] binaries request In-Reply-To: References: <42702213-C222-4937-A585-7CFB17E47608@mac.com> Message-ID: thank you very much but windows's readme says: rxtxSerial.dll had to be recomopiled to link in missing native methods. should I ignore it? or what? thanks again also I understand that I should use mingw not cygwin I'll try to install mingw On Mar 21, 2006, at 12:36 AM, Trent Jarvi wrote: > On Tue, 21 Mar 2006, Dmitry Markman wrote: > >> Hi >> can somebody send me latest linux and windows binaries, please? >> >> or where I can find them (I didn't find them in the latest tareball) >> >> I gave up with my cygwin: something wrong I have no idea what >> java doesn't understand /cygwin/c syntax >> after I changed makefile it did java part >> but after that gcc 3.4.4 started to complain >> I set buffer length to 999 lines but I didn't get beginning of the >> story >> something wrong with my 1.4.2_09/include/jni.h gcc doesn't like it >> anyway I gave up >> >> thanks in advance >> > > Hi Dmitry > > The bins are here: > > ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7-bins-r2.zip > > Here are the files in the zip you want. > > Jar: > > rxtx-2.1-7-bins-r2/RXTXcomm.jar > > Windows: > > rxtx-2.1-7-bins-r2/Windows/i368-mingw32/rxtxSerial.dll > > Linux (x86) > > rxtx-2.1-7-bins-r2/Linux/i686-unknown-linux-gnu/librxtxSerial.so > > There are others in there including Parallel port support but those > are the main ones for testing. > > -- > Trent Jarvi > tjarvi at qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx Dmitry Markman From tjarvi at qbang.org Mon Mar 20 23:20:33 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 20 Mar 2006 23:20:33 -0700 (MST) Subject: [Rxtx] binaries request In-Reply-To: References: <42702213-C222-4937-A585-7CFB17E47608@mac.com> Message-ID: On Tue, 21 Mar 2006, Dmitry Markman wrote: > thank you very much > > but windows's readme says: > rxtxSerial.dll had to be recomopiled to link in missing native methods. > > should I ignore it? or what? > Hi Dmitry That dll should be OK. r2 is the recompile linked to the missing native method. The readme explains why it was recompiled; fuser.o was not linked into the dll in the first release. -- Trent Jarvi tjarvi at qbang.org From ariantristan at yahoo.com Mon Mar 20 23:55:24 2006 From: ariantristan at yahoo.com (Lambok Sianturi) Date: Mon, 20 Mar 2006 22:55:24 -0800 (PST) Subject: [Rxtx] jvm issue Message-ID: <20060321065524.94779.qmail@web50701.mail.yahoo.com> Hi All, This is my first time to join RxTx mailing list. I thank you all for allowing others to sign in in requests help. I use the latest RxTx lib in Fedora 3 with java version 1.4.2_09 b05. And I got this error: # # An unexpected error has been detected by HotSpot Virtual Machine: # # SIGSEGV (0xb) at pc=0x00bf27f3, pid=2633, tid=3086112448 # # Java VM: Java HotSpot(TM) Client VM (1.4.2_09-b05 mixed mode) # Problematic frame: # C [ld-linux.so.2+0xa7f3] # # An error report file with more information is saved as hs_err_pid2633.log # # If you would like to submit a bug report, please visit: # http://java.sun.com/webapps/bugreport/crash.jsp # ./run.sh: line 3: 2633 Aborted /usr/local/java/bin/java -Djava.library.path=/usr/local/java/jre/lib/ -Djsmsengine.debug=true -classpath jsmsengine.jar:smsgateway.jar:classes12.jar:RXTXcomm.jar:. com.api.sms.SMSServer What is the jvm depedency for the latest library? Can I use 1.4.2_09 b05? Thanks in advance. Arian --------------------------------- Yahoo! Mail Use Photomail to share photos without annoying attachments. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060320/83d58dd7/attachment-0019.html From f.frumento at ngi.it Tue Mar 21 00:21:47 2006 From: f.frumento at ngi.it (Fabio Frumento) Date: Tue, 21 Mar 2006 08:21:47 +0100 Subject: [Rxtx] Javadoc on the go Message-ID: <441FA98B.9050701@ngi.it> Hi Trent, sorry for the big delay but my job is running wild, i was out for some time but now i'm back and ready to continue the javadoc for Rxtx. Did you used the last javadoc patch i sent you ? let me know if i have to send it to you again or not. regards Fabio From lyon at docjava.com Tue Mar 21 00:51:18 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Tue, 21 Mar 2006 02:51:18 -0500 Subject: [Rxtx] lock files Message-ID: Hi All, You know, if the use of lock files were under Java control (rather than a build-time decision), it might enable a more unified binary distro. It might also facilitate quick prototyping of non-lock file approaches to resolving serial port contention issues (i.e., mac-like approaches vs. linux approaches, etc.). I realize that this is a radical overhaul of the lock file policy issue. Also, it may harm performance. On the other hand, our benchmarks on JNI overhead for modern processors indicate performance impact should be minimal. Perhaps it is more of an issue with the toybox systems. Suppose there were a class with a reasonable default...someone might write: SerialPortLockPolicy.setPolicy(SerialPortLockPolicy.UNIX_LOCK_FILE); SerialPortLockPolicy.setPolicy(SerialPortLockPolicy.NO_LOCK_CHECKING); SerialPortLockPolicy.setPolicy(SerialPortLockPolicy.MAC_STYLE); Thus, we could have a run-time reconfiguration of the serial port lock policy. A special NO_LOCK version of the binary would no longer be required. Any thoughts on this? Thanks! - Doug From joachim at buechse.de Tue Mar 21 03:09:09 2006 From: joachim at buechse.de (Joachim Buechse) Date: Tue, 21 Mar 2006 11:09:09 +0100 Subject: [Rxtx] lock files In-Reply-To: References: Message-ID: <8E12916A-1B9A-4FF2-B684-E2D1C794221B@buechse.de> This is pretty much what I thought about when I suggested, that the default behaviour could be overwritten with a property. I am very much in favor of this approach. In particular this allows much easier debugging for PC based java developers. I think big parts of the Java (and maybe some parts of the C code) could use a bit of a structural workover (unit tests, javadoc, synchronization, etc). Maybe there should be a CVS branch for this experimental version. I'd be happy to contribute a first workover for some of the Java code. Designing for testability and implementing a good bunch of unit tests has been a strategy that worked quite well in the Java projects I lead. And it ultimately allows more liberal change permission. Regards, Joachim On 21.03.2006, at 08:51, Dr. Douglas Lyon wrote: > Hi All, > You know, if the use of lock files were > under Java control (rather than a build-time decision), > it might enable a more unified binary distro. It might also > facilitate quick prototyping of non-lock file approaches > to resolving serial port contention issues (i.e., mac-like > approaches vs. linux approaches, etc.). > > I realize that this is a radical overhaul of the lock file policy > issue. Also, it may harm performance. On the other hand, > our benchmarks on JNI overhead for modern processors indicate > performance impact should be minimal. Perhaps it is more of > an issue with the toybox systems. > > Suppose there were a class with a reasonable default...someone > might write: > SerialPortLockPolicy.setPolicy(SerialPortLockPolicy.UNIX_LOCK_FILE); > SerialPortLockPolicy.setPolicy(SerialPortLockPolicy.NO_LOCK_CHECKING); > SerialPortLockPolicy.setPolicy(SerialPortLockPolicy.MAC_STYLE); > > Thus, we could have a run-time reconfiguration of the serial port lock > policy. A special NO_LOCK version of the binary would no longer > be required. > > Any thoughts on this? > > Thanks! > - Doug > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From joachim at buechse.de Tue Mar 21 06:23:08 2006 From: joachim at buechse.de (Joachim Buechse) Date: Tue, 21 Mar 2006 14:23:08 +0100 Subject: [Rxtx] PATCH: use of ioctl(fd, TIOCEXCL) instead of lockfiles Message-ID: <923AE774-EEA2-4911-92D8-32BB27802C8B@buechse.de> Here is the patch for the ioctl(fd, TIOCEXCL). I have verified this only for OSX 10.4.5, hence it is only defined for APPLE. However, it should work at least for Solaris as well. If a process has requested TIOEXCL further open calls by other user processes will fail. The patch also disables uucp style locking for APPLE. Obviously this is discussable. I think it is the way to go, as it eliminates creating the lock directory which doesnt exist on the standard installation and it eliminates messing with the system group definitions (adding users to group uucp). Regarding the possibility of root processes opening a device which is locked - I consider this a feature not a potential problem. It is highly unlikely, that somebody is crazy enough to run a JavaVM as root (unless he has no other means of getting a restricted IP port opened, ie doesnt understand ipfw). Anyway, even if the process runs as root, it fails when calling ioctl(fd, TIOCEXCL). It could however still open the port to listen for RING events. I.e. a fax server which needs to see incoming calls but otherwise doesnt want to block the port. So the only case where the proposed mechanism fails is, if an incorrectly implemented process running as root conflicts with a user process. I think this can be accepted. Regards, Joachim PS: If this patch is generally accepted, the installer and Mac doku should obviously be changed as well. Index: SerialImp.c =================================================================== RCS file: /usr/local/cvsroot/rxtx-devel/src/SerialImp.c,v retrieving revision 1.46.2.187 diff -u -r1.46.2.187 SerialImp.c --- SerialImp.c 29 Jan 2006 22:19:04 -0000 1.46.2.187 +++ SerialImp.c 21 Mar 2006 12:59:16 -0000 @@ -656,6 +656,25 @@ fd=OPEN (filename, O_RDWR | O_NOCTTY | O_NONBLOCK ); } while (fd < 0 && errno==EINTR); +#ifdef OPEN_EXCL + // Note that open() follows POSIX semantics: multiple open() calls to + // the same file will succeed unless the TIOCEXCL ioctl is issued. + // This will prevent additional opens except by root-owned processes. + // See tty(4) ("man 4 tty") and ioctl(2) ("man 2 ioctl") for details. + + if (fd >= 0 && (ioctl(fd, TIOCEXCL) == -1)) + { + sprintf( message, "open: exclusive access denied for % s\n", + filename ); + report( message ); + report_error( message ); + + close(fd); + goto fail; + } +#endif /* OPEN_EXCL */ + + if( configure_port( fd ) ) goto fail; (*env)->ReleaseStringUTFChars( env, jstr, filename ); sprintf( message, "open: fd returned is %i\n", fd ); Index: SerialImp.h =================================================================== RCS file: /usr/local/cvsroot/rxtx-devel/src/SerialImp.h,v retrieving revision 1.11.2.49 diff -u -r1.11.2.49 SerialImp.h --- SerialImp.h 5 Jul 2005 17:47:21 -0000 1.11.2.49 +++ SerialImp.h 21 Mar 2006 12:59:17 -0000 @@ -135,7 +135,8 @@ /*# define LOCKDIR "/var/spool/uucp"*/ # define LOCKDIR "/var/lock" # define LOCKFILEPREFIX "LK." -# define UUCP +/*# define UUCP*/ +# define OPEN_EXCL #endif /* __APPLE__ */ #if defined(__NetBSD__) # define DEVICEDIR "/dev/" From tjarvi at qbang.org Tue Mar 21 10:26:08 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 21 Mar 2006 10:26:08 -0700 (MST) Subject: [Rxtx] Javadoc on the go In-Reply-To: <441FA98B.9050701@ngi.it> References: <441FA98B.9050701@ngi.it> Message-ID: On Tue, 21 Mar 2006, Fabio Frumento wrote: > Hi Trent, > > sorry for the big delay but my job is running wild, i was out for some > time but now i'm back and ready to continue the javadoc for Rxtx. > > Did you used the last javadoc patch i sent you ? let me know if i have to > send it to you again or not. > > regards > > Fabio Hi Fabio The patch is in the rxtx mail-list archives. It will be going in soon. I did not see a time critical portion. I'll probably be going through the list since the last batch of patches this weekend and putting them into CVS. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Tue Mar 21 10:57:18 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 21 Mar 2006 10:57:18 -0700 (MST) Subject: [Rxtx] jvm issue In-Reply-To: <20060321065524.94779.qmail@web50701.mail.yahoo.com> References: <20060321065524.94779.qmail@web50701.mail.yahoo.com> Message-ID: On Mon, 20 Mar 2006, Lambok Sianturi wrote: > Hi All, > This is my first time to join RxTx mailing list. I thank you all for allowing others to sign in in requests help. > I use the latest RxTx lib in Fedora 3 with java version 1.4.2_09 b05. And I got this error: > > # > # An unexpected error has been detected by HotSpot Virtual Machine: > # > # SIGSEGV (0xb) at pc=0x00bf27f3, pid=2633, tid=3086112448 > # > # Java VM: Java HotSpot(TM) Client VM (1.4.2_09-b05 mixed mode) > # Problematic frame: > # C [ld-linux.so.2+0xa7f3] A native library loading error? What happens if you recompile rxtx on your system and install that? This sounds like an ABI problem? rxtx 2.1-7 was compiled with a gcc 2.96 toolchain as I recall. The hope is newer system will be backwards compatible. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Tue Mar 21 11:05:29 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 21 Mar 2006 11:05:29 -0700 (MST) Subject: [Rxtx] PATCH: use of ioctl(fd, TIOCEXCL) instead of lockfiles In-Reply-To: <923AE774-EEA2-4911-92D8-32BB27802C8B@buechse.de> References: <923AE774-EEA2-4911-92D8-32BB27802C8B@buechse.de> Message-ID: On Tue, 21 Mar 2006, Joachim Buechse wrote: > Here is the patch for the ioctl(fd, TIOCEXCL). I have verified this only > for OSX 10.4.5, hence it is only defined for APPLE. However, it should > work at least for Solaris as well. > > If a process has requested TIOEXCL further open calls by other user > processes will fail. > > The patch also disables uucp style locking for APPLE. Obviously this is > discussable. I think it is the way to go, as it eliminates creating the > lock directory which doesnt exist on the standard installation and it > eliminates messing with the system group definitions (adding users to > group uucp). > > Regarding the possibility of root processes opening a device which is > locked - I consider this a feature not a potential problem. It is highly > unlikely, that somebody is crazy enough to run a JavaVM as root (unless > he has no other means of getting a restricted IP port opened, ie doesnt > understand ipfw). Anyway, even if the process runs as root, it fails when > calling ioctl(fd, TIOCEXCL). It could however still open the port to > listen for RING events. I.e. a fax server which needs to see incoming > calls but otherwise doesnt want to block the port. So the only case where > the proposed mechanism fails is, if an incorrectly implemented process > running as root conflicts with a user process. I think this can be > accepted. > > Regards, > Joachim > > PS: If this patch is generally accepted, the installer and Mac doku > should obviously be changed as well. > > > Index: SerialImp.c > =================================================================== > RCS file: /usr/local/cvsroot/rxtx-devel/src/SerialImp.c,v > retrieving revision 1.46.2.187 > diff -u -r1.46.2.187 SerialImp.c > --- SerialImp.c 29 Jan 2006 22:19:04 -0000 1.46.2.187 > +++ SerialImp.c 21 Mar 2006 12:59:16 -0000 > @@ -656,6 +656,25 @@ > fd=OPEN (filename, O_RDWR | O_NOCTTY | O_NONBLOCK ); > } while (fd < 0 && errno==EINTR); > > +#ifdef OPEN_EXCL > + // Note that open() follows POSIX semantics: multiple open() > calls to > + // the same file will succeed unless the TIOCEXCL ioctl is > issued. > + // This will prevent additional opens except by root-owned > processes. > + // See tty(4) ("man 4 tty") and ioctl(2) ("man 2 ioctl") for > details. > + > + if (fd >= 0 && (ioctl(fd, TIOCEXCL) == -1)) > + { > + sprintf( message, "open: exclusive access denied for % > s\n", > + filename ); > + report( message ); > + report_error( message ); > + > + close(fd); > + goto fail; > + } > +#endif /* OPEN_EXCL */ > + > + > if( configure_port( fd ) ) goto fail; > (*env)->ReleaseStringUTFChars( env, jstr, filename ); > sprintf( message, "open: fd returned is %i\n", fd ); > Index: SerialImp.h > =================================================================== > RCS file: /usr/local/cvsroot/rxtx-devel/src/SerialImp.h,v > retrieving revision 1.11.2.49 > diff -u -r1.11.2.49 SerialImp.h > --- SerialImp.h 5 Jul 2005 17:47:21 -0000 1.11.2.49 > +++ SerialImp.h 21 Mar 2006 12:59:17 -0000 > @@ -135,7 +135,8 @@ > /*# define LOCKDIR "/var/spool/uucp"*/ > # define LOCKDIR "/var/lock" > # define LOCKFILEPREFIX "LK." > -# define UUCP > +/*# define UUCP*/ > +# define OPEN_EXCL > #endif /* __APPLE__ */ > #if defined(__NetBSD__) > # define DEVICEDIR "/dev/" > This looks like a good start. What do you think Dmitry? Perhaps all systems with TIOCEXCL defined should use that though. Even if they use lockfiles. It wont hurt anything. That would catch people hacking their own serial apps without checking lockfiles. Its a good idea to avoid C++ style comments in the C portions. Some older systems don't deal with them well. If it's just for Mac OS X, it isn't a big deal. I think it was the Irix compiler that was problematic? -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Tue Mar 21 11:22:05 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 21 Mar 2006 11:22:05 -0700 (MST) Subject: [Rxtx] lock files In-Reply-To: <8E12916A-1B9A-4FF2-B684-E2D1C794221B@buechse.de> References: <8E12916A-1B9A-4FF2-B684-E2D1C794221B@buechse.de> Message-ID: We can try it. Maybe the JNI is much improved. The nice thing about linking into liblock is distros then worry about lockfiles on their systems. This way, we have to deal with any changes that may show up. On Tue, 21 Mar 2006, Joachim Buechse wrote: > This is pretty much what I thought about when I suggested, that the > default behaviour could be overwritten with a property. I am very much in > favor of this approach. In particular this allows much easier debugging > for PC based java developers. > > I think big parts of the Java (and maybe some parts of the C code) could > use a bit of a structural workover (unit tests, javadoc, synchronization, > etc). Maybe there should be a CVS branch for this experimental version. > I'd be happy to contribute a first workover for some of the Java code. > Designing for testability and implementing a good bunch of unit tests has > been a strategy that worked quite well in the Java projects I lead. And > it ultimately allows more liberal change permission. > > Regards, > Joachim > > > On 21.03.2006, at 08:51, Dr. Douglas Lyon wrote: > >> Hi All, >> You know, if the use of lock files were >> under Java control (rather than a build-time decision), >> it might enable a more unified binary distro. It might also >> facilitate quick prototyping of non-lock file approaches >> to resolving serial port contention issues (i.e., mac-like >> approaches vs. linux approaches, etc.). >> >> I realize that this is a radical overhaul of the lock file policy >> issue. Also, it may harm performance. On the other hand, >> our benchmarks on JNI overhead for modern processors indicate >> performance impact should be minimal. Perhaps it is more of >> an issue with the toybox systems. >> >> Suppose there were a class with a reasonable default...someone >> might write: >> SerialPortLockPolicy.setPolicy(SerialPortLockPolicy.UNIX_LOCK_FILE); >> SerialPortLockPolicy.setPolicy(SerialPortLockPolicy.NO_LOCK_CHECKING); >> SerialPortLockPolicy.setPolicy(SerialPortLockPolicy.MAC_STYLE); >> >> Thus, we could have a run-time reconfiguration of the serial port lock >> policy. A special NO_LOCK version of the binary would no longer >> be required. >> >> Any thoughts on this? >> >> Thanks! >> - Doug >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From dmarkman at mac.com Tue Mar 21 16:05:17 2006 From: dmarkman at mac.com (Dmitry Markman) Date: Tue, 21 Mar 2006 18:05:17 -0500 Subject: [Rxtx] PATCH: use of ioctl(fd, TIOCEXCL) instead of lockfiles In-Reply-To: References: <923AE774-EEA2-4911-92D8-32BB27802C8B@buechse.de> Message-ID: <512AC70C-BB86-48F2-A83C-023F35C23BAB@mac.com> I think it's cool, but I'd like to have that property implementation when user can choose between locking mechanism about comments: it's easy to change comments to the C style or we can use extensions of the file to cpp so c++ compiler will be used On Mar 21, 2006, at 1:05 PM, Trent Jarvi wrote: > This looks like a good start. What do you think Dmitry? Perhaps > all systems with TIOCEXCL defined should use that though. Even if > they use lockfiles. It wont hurt anything. That would catch > people hacking their own serial apps without checking lockfiles. > > Its a good idea to avoid C++ style comments in the C portions. > Some older systems don't deal with them well. If it's just for Mac > OS X, it isn't a big deal. I think it was the Irix compiler that > was problematic? Dmitry Markman From dmarkman at mac.com Tue Mar 21 16:13:00 2006 From: dmarkman at mac.com (Dmitry Markman) Date: Tue, 21 Mar 2006 18:13:00 -0500 Subject: [Rxtx] PATCH: use of ioctl(fd, TIOCEXCL) instead of lockfiles In-Reply-To: References: <923AE774-EEA2-4911-92D8-32BB27802C8B@buechse.de> Message-ID: I'd like to add that creating locking folder isn't a big deal we never had a problem related to the lock folders, because we always used installer on mac os x from other hand I'm not very much familiar with iotcl locking approach and I'm not sure it's more efficient Joachim wrote "I think it is the way to go, as it eliminates creating the lock directory which doesnt exist on the standard installation and it eliminates messing with the system group definitions (adding users to group uucp)." but I really didn't have any problem with that 1. doesn't exist on the standard installation there are many-many things that don't exist in the standard installation so I don't think that argument is strong enough 2. messing with the system group definitions I don't think we're messing with the group definition mac os x provides very clear way to set up group's members and together with Greg Guerin AuthKit there is no problem to set those definitions so I don't think that argument is strong either but from other hand using iotcl is more promising and is more elegant On Mar 21, 2006, at 1:05 PM, Trent Jarvi wrote: > > This looks like a good start. What do you think Dmitry? Perhaps > all systems with TIOCEXCL defined should use that though. Even if > they use lockfiles. It wont hurt anything. That would catch > people hacking their own serial apps without checking lockfiles. Dmitry Markman From joachim at buechse.de Wed Mar 22 04:46:45 2006 From: joachim at buechse.de (Joachim Buechse) Date: Wed, 22 Mar 2006 12:46:45 +0100 Subject: [Rxtx] PATCH: use of ioctl(fd, TIOCEXCL) instead of lockfiles In-Reply-To: References: <923AE774-EEA2-4911-92D8-32BB27802C8B@buechse.de> Message-ID: Sorry, I was not very clear with my arguments, so I will try again;-) Please, don't take this as an attack against work that has been done. I think the contributions that have been made in the past were made in a good spirit. But I really believe, that the current solution for OSX has many shortcomings and should be changed as soon as possible. lock files --- The /var/lock folder does not exist on the standard OSX installation, however the standard installation includes several applications that use serial ports (i.e. the FAX capability). This indicates, that the lock folder approach will not work well with system components. Applications for OSX will generally try to live in harmony with system components (except for HP print drivers of course). I think RXTX should follow this approach as well. uucp group --- Accessing serial ports is not an admin privileged operation on OSX. Any user (world) has read/write privileges on /dev/tty*. So the system default is to not enforce any group membership to access these ports. The group uucp however is a system group on all unix systems I know. It exists for certain system processes. A non admin user should in general not be a member of this group. Quite arguably no user should ever be a member of this group. Installer --- My general opinion is, that - no Installer should touch user or group data without warning - no Application Installer should touch groups which are not specific to the very application installed - no Installer should ever add regular users to a system group The current installer injects the installing user in the group uucp without warning about this change and without giving the option to "opt out" of this change. This is a potential security risk (but not currently a real one, as OSX contains no folders belonging to group uucp). The current installer does not work for multi user systems. It puts the installing user in the uucp group. However the installing user is not necessarily the user that will use the application. Putting all users that may use a serial port application in the system group uucp seems like a very invasive approach to me. Besides that, newly created users will not automatically be in the group and hence, serial applications will "break" for new users without obvious reasons. Avoiding the lock files will allow self contained applications (i.e. drag&drop installation). In my eyes this is largely preferable over an installer that requests admin privileges. Adding up all these points indicates very strongly, that the lock-file implementation is not the way to go on OSX. Regards, Joachim On 22.03.2006, at 00:13, Dmitry Markman wrote: > I'd like to add that > > creating locking folder isn't a big deal > we never had a problem related to the lock folders, because we > always used installer on mac os x > from other hand I'm not very much familiar with iotcl locking > approach and I'm not sure it's more efficient > > Joachim wrote "I think it is the way to go, as it eliminates > creating the lock directory which doesnt exist on the standard > installation and it eliminates messing with the system group > definitions (adding users to group uucp)." but I really didn't have > any problem with that > > 1. doesn't exist on the standard installation > there are many-many things that don't exist in the standard > installation so I don't think that argument is strong enough > 2. messing with the system group definitions > I don't think we're messing with the group definition > mac os x provides very clear way to set up group's members and > together with Greg Guerin AuthKit there is no problem to set those > definitions > so I don't think that argument is strong either > but from other hand using iotcl is more promising and is more elegant > > > > On Mar 21, 2006, at 1:05 PM, Trent Jarvi wrote: > >> >> This looks like a good start. What do you think Dmitry? Perhaps >> all systems with TIOCEXCL defined should use that though. Even if >> they use lockfiles. It wont hurt anything. That would catch >> people hacking their own serial apps without checking lockfiles. > > Dmitry Markman > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From dmarkman at mac.com Wed Mar 22 05:27:13 2006 From: dmarkman at mac.com (Dmitry Markman) Date: Wed, 22 Mar 2006 07:27:13 -0500 Subject: [Rxtx] PATCH: use of ioctl(fd, TIOCEXCL) instead of lockfiles In-Reply-To: References: <923AE774-EEA2-4911-92D8-32BB27802C8B@buechse.de> Message-ID: <83440CF3-DCD8-41C1-B941-F227232C27E3@mac.com> thanks for the very good explanation I didn't think that you were attacking any thing, so don't worry I just had feeling, that there were more aesthetic reasons for going to ioctl then real necessity now you explained everything quite well (BTW, asfar as I remember installer asks admin password so it wasn't quiet, but it really doesn't matter now) thanks On Mar 22, 2006, at 6:46 AM, Joachim Buechse wrote: > Sorry, I was not very clear with my arguments, so I will try again;-) > > Please, don't take this as an attack against work that has been > done. I think the contributions that have been made in the past > were made in a good spirit. But I really believe, that the current > solution for OSX has many shortcomings and should be changed as > soon as possible. > > lock files > --- > The /var/lock folder does not exist on the standard OSX > installation, however the standard installation includes several > applications that use serial ports (i.e. the FAX capability). This > indicates, that the lock folder approach will not work well with > system components. Applications for OSX will generally try to live > in harmony with system components (except for HP print drivers of > course). I think RXTX should follow this approach as well. > > uucp group > --- > Accessing serial ports is not an admin privileged operation on OSX. > Any user (world) has read/write privileges on /dev/tty*. So the > system default is to not enforce any group membership to access > these ports. The group uucp however is a system group on all unix > systems I know. It exists for certain system processes. A non admin > user should in general not be a member of this group. Quite > arguably no user should ever be a member of this group. > > Installer > --- > My general opinion is, that > - no Installer should touch user or group data without warning > - no Application Installer should touch groups which are not > specific to the very application installed > - no Installer should ever add regular users to a system group > > The current installer injects the installing user in the group uucp > without warning about this change and without giving the option to > "opt out" of this change. This is a potential security risk (but > not currently a real one, as OSX contains no folders belonging to > group uucp). > > The current installer does not work for multi user systems. It puts > the installing user in the uucp group. However the installing user > is not necessarily the user that will use the application. Putting > all users that may use a serial port application in the system > group uucp seems like a very invasive approach to me. Besides that, > newly created users will not automatically be in the group and > hence, serial applications will "break" for new users without > obvious reasons. > > > Avoiding the lock files will allow self contained applications > (i.e. drag&drop installation). In my eyes this is largely > preferable over an installer that requests admin privileges. Adding > up all these points indicates very strongly, that the lock-file > implementation is not the way to go on OSX. > > Regards, > Joachim > > > On 22.03.2006, at 00:13, Dmitry Markman wrote: > >> I'd like to add that >> >> creating locking folder isn't a big deal >> we never had a problem related to the lock folders, because we >> always used installer on mac os x >> from other hand I'm not very much familiar with iotcl locking >> approach and I'm not sure it's more efficient >> >> Joachim wrote "I think it is the way to go, as it eliminates >> creating the lock directory which doesnt exist on the standard >> installation and it eliminates messing with the system group >> definitions (adding users to group uucp)." but I really didn't >> have any problem with that >> >> 1. doesn't exist on the standard installation >> there are many-many things that don't exist in the standard >> installation so I don't think that argument is strong enough >> 2. messing with the system group definitions >> I don't think we're messing with the group definition >> mac os x provides very clear way to set up group's members and >> together with Greg Guerin AuthKit there is no problem to set those >> definitions >> so I don't think that argument is strong either >> but from other hand using iotcl is more promising and is more elegant >> >> >> >> On Mar 21, 2006, at 1:05 PM, Trent Jarvi wrote: >> >>> >>> This looks like a good start. What do you think Dmitry? Perhaps >>> all systems with TIOCEXCL defined should use that though. Even >>> if they use lockfiles. It wont hurt anything. That would catch >>> people hacking their own serial apps without checking lockfiles. >> >> Dmitry Markman >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx Dmitry Markman From lyon at docjava.com Wed Mar 22 06:12:18 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Wed, 22 Mar 2006 08:12:18 -0500 Subject: [Rxtx] sole of a new design pattern Message-ID: Hi All, I have been thinking about how we design the serial port software. I think we need a new design pattern. For lack of a better term, I shall call it: The Parametric Singleton Design Pattern By Douglas A. Lyon ABSTRACT The goal of the singleton design pattern is to make sure that there is one, and only one, instance of a given class. The goal of the parametric singleton design pattern is to make sure that there is one, and only one, instance of a given class with the given parametric values. We parametric singleton design pattern combines the singleton design pattern with a parameter that enables unique creation of instances of a class. These instances are cached. When a user asks for an instance with these parameters, the cache is checked. If the instance is in the cache, the instance is returned, otherwise it is created, added to the cache and then returned. We apply our parametric singleton design pattern to the retrieval of RMI registries bound to a given port. The goal of our system is to make sure that no two RMI registries are listening to the same socket and to make use of the RMI registries after they have been created. RMI registries are used in distributed computation. Introduction The singleton design pattern is meant to ensure that on a single instance of a class exists. It is also meant to provide a global point of access to it. The intent of the parametric singleton design pattern is to ensure that a class has only one instance for a given set of parameter values. It also provides a global point of access to it. Motivation A system cannot tolerate multiple instances of some classes with identical parameters. For example, you cannot have two instances making use of the same serial port, at the same time. You cannot have two instances that are trying to listen to the same socket connection. You cannot have two instances writing to the same file structure at the same time. As the operating system is often thought of as the arbiter of consumed resources (i.e., tape drives, serial ports, etc.) we frequently leave it to an operating system implementation to resolve these contention issues. Even for similar resources (like serial ports) there are few standards for handling contention. For example, serial ports on Linux are locked using a "/var/lock" file. POSIX, on the other hand, uses ioctl mechanisms to prevent contention. A better solution is to make a class that is responsible for keeping track of the instances created from the class. The class is declared final, so that it cannot be subclassed. The class also has a private constructor, so that other classes cannot instance it. The new design pattern is called the parametric singleton design pattern and it provides a way to access and create instances with given parameters. Applicability Use the Parametric Singleton Design Pattern when: 1. There must be exactly one instance of a class with the given parameters. 2. The instances must be accessible to clients from a well-known access point. Structure Insert UML diagram here. Participants The Parametric Singleton Clients that need instances 1. The Parametric Singleton defines an instance upon request from a client, if, and only if, the instance does not already exist. 2. The Parametric Singleton returns the instance to the client. 3. The Parametric Singleton is responsible for creating unique instances from given parameters. Collaborations Clients obtain a reference to a Parametric Singleton instance only through the parametric singleton design pattern. If the instance is left in an improper state (e.g., the serial port was left open) it is NOT the role of the Parametric Singleton Design Pattern to close the IO port. Nor is it the role of the Parametric Singleton Design Pattern to open the port. That role is delegate to some other part of the system. Further, it is not the role of the Parametric Singleton Design Pattern to check out resources. That is, multiple threads can have multiple references to the same resource at the same time. MUTEX locking is delegated to some other part of the system. Consequences The Parametric Singleton Design Pattern has several benefits: 1. Controlled access to parametrically defined instances. Since the Parametric Singleton class encapsulates its instances, there is control over how and when clients access it. 2. Reduced name space. The Parametric Singleton pattern avoids global variables that store instances created from the same parameter. Implementation Here are implementation issues to consider when using the Parametric Singleton pattern: 1. Unique mapping of parameters. The Parametric Singleton pattern requires that there be a mean to isomorphically map the parameter space into the instance space and back again. 2. Ensure unique instances. The Parametric Singleton pattern makes unique instances from parameters, and it does so only once. 3. Cache instances for fast retrieval. The Parametric Singleton pattern must be able to look up instances, given some set of parameters, and do so from some data structure. That is, there must be enough space to hold references to all the instances the program will need. Also, a mechanism is needed to look up and retrieve the instances quickly enough to satisfy the clients. Sample Code public final class ParametricSingletonRmiRegistry { private static Hashtable registry = new Hashtable(100); // use singleton pattern and??????????????????????????????????????????????? // prevent instantiation of RmiRegistryUtils.?????????????????????????????? private ParametricSingletonRmiRegistry() { } // the only instance of the Registry held by the RmiRegistryUtils?????????? public static void listNames(Integer port) { if (!isInCacheAndRunning(port)) return; Registry r = (Registry) registry.get(port); System.out.println("registry on port: " + port); System.out.println("registry: " + r); System.out.println("names: "); try { print(r.list()); } catch (RemoteException e) { In.message(e); } System.out.println("------------------------"); } /**???????????????????????????????????????????????????????????????????????? * Checks whether a Registry has been started on this host????????????????? * in the specified port.?????????????????????????????????????????????????? * If not, it tries to start one.?????????????????????????????????????????? * when it fails to start a Registry, it exits the program????????????????? * with exit code 1.??????????????????????????????????????????????????????? */ public static void restart(int port) { if (isInCacheAndRunning(port)) return; try { startRegistry(port); } catch (RemoteException e) { In.message(e); } } /**???????????????????????????????????????????????????????????????????????? * @param port????????????????????????????????????????????????????????????? * @return true if registry is in cache and running???????????????????????? */ private static boolean isInCacheAndRunning(Integer port) { if (!isRegistryRunning(port.intValue())) return false; if (!isRegistryInCache(port.intValue())) return false; return true; } /**???????????????????????????????????????????????????????????????????????? * @param port????????????????????????????????????????????????????????????? * @return true if we are able to locate a local registry on port.??????????????????????????????????????????????????????????????????????????? */ private static boolean isRegistryRunning(int port) { try { Registry r = LocateRegistry.getRegistry(port); if (r != null) return true; } catch (RemoteException e) { return false; } return false; } /**???????????????????????????????????????????????????????????????????????? * @param port????????????????????????????????????????????????????????????? * @return return true if registry is in cache????????????????????????????? */ private static boolean isRegistryInCache(int port) { if (registry.get(new Integer(port)) == null) return false; return true; } /**???????????????????????????????????????????????????????????????????????? * Restart the registry, if needed.???????????????????????????????????????? * Return the only instance of the registry for consistent global?????????? * using by making use of the Singleton Design Pattern????????????????????? *????????????????????????????????????????????????????????????????????????? * @return the internally held registry instance.?????????????????????????? */ public static Registry getRegistry(Integer port) { restart(port); return (Registry) registry.get(port); } private static void startRegistry(Integer port) throws RemoteException { Registry r; try { r = LocateRegistry.createRegistry(port.intValue()); registry.put(port, r); //r = new sun.rmi.registry.RegistryImpl???????????????????????????? /// (port.intValue());?????????????????????????????????????? // registry.put(port, r);?????????????????????????????????????????? } catch (Exception e) { //e.printStackTrace();????????????????????????????????????????????? r = LocateRegistry.getRegistry(port.intValue()); registry.put(port, r); } } public static void main(String args[]) throws RemoteException { //restart(port);??????????????????????????????????????????????????????? restart(5001); restart(5002); restart(5002); Registry r = LocateRegistry.getRegistry(5002); System.out.println("registry="+r); } } I would very much like to get your feedback on this new design pattern idea. Thank you for your time. Regards, - Doug From david.garnier at trusted-logic.com Wed Mar 22 07:36:10 2006 From: david.garnier at trusted-logic.com (David Garnier) Date: Wed, 22 Mar 2006 15:36:10 +0100 Subject: [Rxtx] sole of a new design pattern In-Reply-To: References: Message-ID: <442160DA.80107@trusted-logic.com> Hello, > The Parametric Singleton Design Pattern The Singleton is the most abused design pattern ever. Good use-cases for this pattern are extremely rare and mostly confined to problems related to hardware resources, like serial ports. > Applicability > > Use the Parametric Singleton Design Pattern when: > 1. There must be exactly one instance of a class with the given > parameters. OK. As I said above, this case this actually very unusual. The Singleton pattern is mostly used when : > 2. The instances must be accessible to clients from a well-known > access point. Using the singleton pattern in this case is just convenient for the programmer. Problems arises pretty quickly, especially if you attempt to unit-test your classes. 1) If your singleton is stateful, or hold on to stateful objects, it means that two different unit tests are not actually independent. Instead of starting with a brand new environment, the result of a test may be affected by the result of a previous test. This problem also arise when with your class relies on a database. In both cases, the solution is to reset your "unique" resource (Singleton or database) at the beginning of the test, which is a pain. Also, while most projects connect to a single database, projects that allow the use of Singletons usually contain several of thems, and new ones may cropped up unnoticed. You quickly end up with test cases that only pass in a certain order, which is a royal pain. 2) You cannot mockup a singleton. Once everyone calls the SomeSingleton class statically, you can't replace your class by SomeSingletonMockup. Furthermore, even for hardware services, the Singleton pattern does not really prevent concurrent accesses. If you start the same program in two different JVMs, unless they somehow shared the state of their "Singletons" (through lock files for example), the Singleton pattern will not prevent concurrent access. Our application uses RXTX, and we routinely encounter cases where another (native) application has already locked the port. Since we cannot modify the native application to recognize lock files, OS-level control is irreplaceable. > > Consequences > The Parametric Singleton Design Pattern has several benefits: > > 1. Controlled access to parametrically defined instances. Since > the Parametric Singleton class encapsulates its instances, there is > control over how and when clients access it. Not really. Once you've returned the instance to a client, you've lost control over it. The client can to whatever it wants with it. You cannot "recall" the instance or claim it back. > 2. Reduced name space. The Parametric Singleton pattern avoids > global variables that store instances created from the same parameter. Sure, but you don't have to rely on a Singleton for that. Just create a single Factory. > I would very much like to get your feedback on this new design > pattern idea. Well, it's nothing new. Some may say that it is the point of design patterns: formalizes the designs that occur again and again. However, this design is simply a combination of the Singleton and Factory patterns. I did use it in the past, but now I've been exposed to the shortcomings of the Singleton pattern, so I limit myself to Factories. Regards, David From sean_montgomery at baseview.com Wed Mar 22 08:35:28 2006 From: sean_montgomery at baseview.com (Sean Montgomery) Date: Wed, 22 Mar 2006 10:35:28 -0500 Subject: [Rxtx] sole of a new design pattern In-Reply-To: <442160DA.80107@trusted-logic.com> References: <442160DA.80107@trusted-logic.com> Message-ID: <05769CA7-A51B-4CF0-BAA0-E02DD905F5A4@baseview.com> On Mar 22, 2006, at 9:36 AM, David Garnier wrote: > Furthermore, even for hardware services, the Singleton pattern does > not really prevent concurrent > accesses. If you start the same program in two different JVMs, > unless they somehow shared the state > of their "Singletons" (through lock files for example), the > Singleton pattern will not prevent > concurrent access. > Multiple class loaders in a single JVM can be tricky, too. Then there's synchronization, lazy initialization and serialization of singletons to contend with. Bloch's Effective Java covers these, and here's a few articles: http://www.javaworld.com/javaworld/jw-04-2003/jw-0425-designpatterns- p3.html http://java.sun.com/developer/technicalArticles/Programming/singletons/ Just FYI :-) From lyon at docjava.com Wed Mar 22 08:50:48 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Wed, 22 Mar 2006 10:50:48 -0500 Subject: [Rxtx] sole of a new design pattern In-Reply-To: <442160DA.80107@trusted-logic.com> References: <442160DA.80107@trusted-logic.com> Message-ID: Hi All, First, I would like to thank David for his prompt and thoughtful remarks. I had no idea people that feel strongly about a design patterns! Wow! Feedback (particularly critical feedback) is greatly appreciated. Starting at the end, first: >I did use it in >the past, but now I've been exposed to the shortcomings of the >Singleton pattern, so I limit myself to Factories. David, if I understood your comments correctly, you suggested that Factories can be used in leu of the Singleton Design Pattern, or even the Parametric Singleton Design Pattern. As I see in [Gof]: Factory Method: Intent "Define an interface for creating an object, but let subclasses decide which class to instantiate. Factory Method lets a class defer instantiation to subclasses." The Singleton Design Pattern is a concrete class, which is rather different, right? Also, subclasses are not permitted with Singleton, as they are final. Naturally, I could use an abstract factory as a parent for a singleton. I could even design a facade that could be implemented with the singleton....but that is not the intention of the design. Unless you want a mock-up, as discussed, below: More below: >Hello, > >> The Parametric Singleton Design Pattern > >The Singleton is the most abused design pattern ever. Good use-cases >for this pattern are extremely >rare and mostly confined to problems related to hardware resources, >like serial ports. > > >> Applicability >> >> Use the Parametric Singleton Design Pattern when: >> 1. There must be exactly one instance of a class with the given >> parameters. >OK. As I said above, this case this actually very unusual. The >Singleton pattern is mostly used when : >> 2. The instances must be accessible to clients from a well-known >> access point. > >Using the singleton pattern in this case is just convenient for the >programmer. Problems arises >pretty quickly, especially if you attempt to unit-test your classes. > >1) If your singleton is stateful, or hold on to stateful objects, it >means that two different unit >tests are not actually independent. Instead of starting with a brand >new environment, the result of >a test may be affected by the result of a previous test. This >problem also arise when with your >class relies on a database. In both cases, the solution is to reset >your "unique" resource >(Singleton or database) at the beginning of the test, which is a >pain. Also, while most projects >connect to a single database, projects that allow the use of >Singletons usually contain several of >thems, and new ones may cropped up unnoticed. You quickly end up >with test cases that only pass in a >certain order, which is a royal pain. There are basic problems with communicating finite state machines that include reachability and deadlock analysis. These are addressed with petri net analysis and are beyond the scope of the design pattern. As you quite rightly pointed out; the parametric singleton pattern (or the singleton pattern, for that matter) enable multiple threads to gain access to the same instance. The only way that I can see to block others from gaining access to the reference is the synchronize keyword. This is putting a spin-lock (or MUTEX) on the reference. The question of how to unit-test a design pattern like the parametric singleton remains open. Perhaps this is a deficiency. > >2) You cannot mockup a singleton. Once everyone calls the >SomeSingleton class statically, you can't >replace your class by SomeSingletonMockup. Acutally, I am not sure that this is true. If the Singleton implements a Facade interface, it should be possible to make the replacement. Right? > >Furthermore, even for hardware services, the Singleton pattern does >not really prevent concurrent >accesses. If you start the same program in two different JVMs, >unless they somehow shared the state >of their "Singletons" (through lock files for example), the >Singleton pattern will not prevent >concurrent access. Good Point!! You have sharp eyes! The singleton design pattern should/could take responsibility for this. In fact, you may notice that my code does have an implementation (LocateRegistry) that can work across JVM's. The LocateRegistry will even work across the Internet! LocateRegistry takes both a host name and a Port (lock files just don't do this). I did not think to implement this beyond the local machine, but, in its present form, it will work across different processes. > >Our application uses RXTX, and we routinely encounter cases where >another (native) application has >already locked the port. Since we cannot modify the native >application to recognize lock files, >OS-level control is irreplaceable. The singleton design pattern is not meant to replace OS-level control, but to centralize the Java programmers access to it. If lock files, for example, are used for serial ports, the Singleton Design Pattern should be able to work with them. > > >> >> Consequences >> The Parametric Singleton Design Pattern has several benefits: >> > > 1. Controlled access to parametrically defined instances. Since >> the Parametric Singleton class encapsulates its instances, there is >> control over how and when clients access it. > >Not really. Once you've returned the instance to a client, you've >lost control over it. The client >can to whatever it wants with it. You cannot "recall" the instance >or claim it back. Good point, this should read: > 1. Controll when parametrically defined instances are created. Since > > the Parametric Singleton class encapsulates its instances, there is > > control over how and when they are instanced. > >> 2. Reduced name space. The Parametric Singleton pattern avoids >> global variables that store instances created from the same parameter. > >Sure, but you don't have to rely on a Singleton for that. Just >create a single Factory. > > Thank you for your thoughtful and prompt response! Regards, - Doug From dmarkman at mac.com Wed Mar 22 21:21:55 2006 From: dmarkman at mac.com (Dmitry Markman) Date: Wed, 22 Mar 2006 23:21:55 -0500 Subject: [Rxtx] sole of a new design pattern In-Reply-To: <442160DA.80107@trusted-logic.com> References: <442160DA.80107@trusted-logic.com> Message-ID: I don't think I get it On Mar 22, 2006, at 9:36 AM, David Garnier wrote: > Using the singleton pattern in this case is just convenient for the > programmer. Problems arises > pretty quickly, especially if you attempt to unit-test your classes. so you're saying that something isn't so good because you can not test it in the convenient way? if that's true, I'm totally disagree change your test, debug whatever, but if software is efficient at runtime, works fine and only problem is some unit test (which is some kind of framework for testing) then dump that unit test , dump that unit framework and make something appropriate to the software you're testing so if Douglas want to use singletons, what's the problem? and what do you mean by abusing of singleton usage? of course singleton doesn't prevent concurrent access to the resource across the processes unless you're using some OS facility to prevent it, besides singleton as it was introduced is relevant only and only inside of the same process otherwise it's not singleton it's something else (let's say network singleton: so you have remote invocation facility and some factory method that return object created by that facility) I don't have any problem with using any kind of singletons. Parametric Singleton idea (if I understand it right) could be easily implemented in the following way: use a map populate map with instances of some class and key is your parameter (you can use lazy population too) if somebody ask the key check the value if it's null so resource is taken if somebody returns the resource put it back to the map public synchronized static Object getSomeResource(Object parameter); public synchronized static void returnResource(Object parameter); getSomeResource (inside of the same process) could return null in 2 cases 1. if somebody (from other thread for example) already took that resource 2. if OS API said that resource corresponded to that parameter (serial port with parameter = 1 (port #)) is locked and unavailable; I'm not sure that in case of serial ports we even need those Parametric Singletons (unless lock checking is a very expensive operation) just ask the OS about availability of that resource and if it's available give it away and then OS will lock it and therefore in next time somebody ask it just answer that resource is locked and return null for example system has 2 serial ports available so I ask getResource("tty"); or I ask getResource("Bluetooth-Modem"); and if OS is ok you can give tty or Bluetooth-Modem or both no need for any additional pattern I think back to the problem mac os x doesn't recognize locking via files, so it handles locking via some API an instance of the singleton in each process should recognize that resource is locked (by using that API) that's all we don't have to make things more complicate then they are just because there is some nice design pattern or nice unit test framework or whatever keep things simple, make them work fast, don't introduce middle layers unless you have really good reason to do so of course I could be entirely wrong, so sorry about that in advance thanks Dmitry Markman From tjarvi at qbang.org Wed Mar 22 22:31:41 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 22 Mar 2006 22:31:41 -0700 (MST) Subject: [Rxtx] sole of a new design pattern In-Reply-To: References: Message-ID: Hi Doug Interesting reading. So far I'm just reading and thinking. I have one question so far. " Clients obtain a reference to a Parametric Singleton instance only through the parametric singleton design pattern. If the instance is left in an improper state (e.g., the serial port was left open) it is NOT the role of the Parametric Singleton Design Pattern to close the IO port. Nor is it the role of the Parametric Singleton Design Pattern to open the port. That role is delegate to some other part of the system. " So when the clients obtain a reference to the singleton, can they assume the port is there? IE, would it be the singletons role to handle things like USB dongles being removed with event hints comming from the underlying OS. Hardware abstraction layer/HAL on Linux is an example of underlying OS events. I assume that role too is delegated to other parts of the system? -- Trent Jarvi tjarvi at qbang.org From lyon at docjava.com Thu Mar 23 08:10:33 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Thu, 23 Mar 2006 10:10:33 -0500 Subject: [Rxtx] Classes don't need goals, they need roles! In-Reply-To: References: Message-ID: Hi Trent, Yes, I think that the role of the Parametric Singleton Pattern is not to open or close serial ports, nor is it to perform error checking. On the other hand, if you were to combine the role of the Parametric Singleton Pattern with another role (like that of error checking) it might not be amiss. However, I generally caution programmers against adding multiple roles to classes, as this leads to monolithic designs. Thus a different class (NativeLibDetect) could have the role of determining if the native library can be loaded. Another class (SerialPortBean) can have the role of serializing the default state of the serial port, so that it can be recovered, from user preferences, at a later time. The SerialPortDetect could have the role of determining if the serial port is removed (i.e., a USB port was unplugged). My guess is that each class should have a different role in the system, in order to ease maintenance and testing...but I could be wrong about that. Thanks! - Doug >Hi Doug > >Interesting reading. So far I'm just reading and thinking. I have >one question so far. > >" > Clients obtain a reference to a Parametric Singleton instance only >through the parametric singleton design pattern. If the instance is >left in an improper state (e.g., the serial port was left open) it is >NOT the role of the Parametric Singleton Design Pattern to close the >IO port. Nor is it the role of the Parametric Singleton Design Pattern >to >open the port. That role is delegate to some other part of the system. >" > >So when the clients obtain a reference to the singleton, can they >assume the port is there? IE, would it be the singletons role to >handle things like USB dongles being removed with event hints >comming from the underlying OS. Hardware abstraction layer/HAL on >Linux is an example of underlying OS events. > >I assume that role too is delegated to other parts of the system? > >-- >Trent Jarvi >tjarvi at qbang.org >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From maximulo at yahoo.com Fri Mar 24 01:22:38 2006 From: maximulo at yahoo.com (Maximulo Majir) Date: Fri, 24 Mar 2006 00:22:38 -0800 (PST) Subject: [Rxtx] JavaPOS Message-ID: <20060324082238.66371.qmail@web38214.mail.mud.yahoo.com> Hi all! Hello Trent! From what i understand, RXTX or JavaComm APIs were not created solely for JavaPOS. In JavaPOS, we have the virtual method claim() which is separate from open(), but in our RXTX API, claiming is done every call to open(), we cant open the port if its claimed by another application. Would it be alright to suggest or ask to create a new method called claim(..)? Is there such thing as forceclaim() in RXTX? this could be the same as portownership transfer or its equivalent. ForceClaim is in JSR80. Do you have some samples using RXTX as the lower layer for the Device Service Objects in JavaPOS? I have tried it, i just want to compare. Thank you all! maxim __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060324/496adba2/attachment-0019.html From tjarvi at qbang.org Fri Mar 24 11:28:19 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 24 Mar 2006 11:28:19 -0700 (MST) Subject: [Rxtx] Re: RXTX 2.1 Solaris Problems In-Reply-To: <3691.1143210578@www045.gmx.net> References: <3691.1143210578@www045.gmx.net> Message-ID: On Fri, 24 Mar 2006, Andreas Guenther wrote: > Hi all, > > the solaris problem was not the lock file only. > > Ok, I had to create the directory /var/spool/locks myself. > /var/spool/uucp exists. > > But rxtx didn't find any port. > > I compiled the source with my own debug-informations > and I tried to isolate the problem. > > The problem is the testRead-call in SerialImp.c > > JNIEXPORT jboolean JNICALL RXTXCommDriver(testRead)( > > ... > if ( READ( fd, &c, 1 ) < 0 ) > { > if ( errno != EAGAIN ) { > report( "testRead() read failed\n" ); > ret = JNI_FALSE; > } > } > Thanks Andreas I'm packing up to move. I'll be more or less away for a couple weeks here. I'll be checking email but my workstation is going into a box soon. This isn't hard to fix as this port should be enumerated when EWOULDBLOCK is recieved. Thats error is OK for enumeration just as EAGAIN is. I've put the bug into bugzilla so we dont forget to get to it. http://bugzilla.qbang.org/show_bug.cgi?id=42 You can add yourself to the CC list if you wish to test fixes we provide or even put a patch into bugzilla yourself. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Fri Mar 24 11:51:52 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 24 Mar 2006 11:51:52 -0700 (MST) Subject: [Rxtx] JavaPOS In-Reply-To: <20060324082238.66371.qmail@web38214.mail.mud.yahoo.com> References: <20060324082238.66371.qmail@web38214.mail.mud.yahoo.com> Message-ID: On Fri, 24 Mar 2006, Maximulo Majir wrote: > Hi all! Hello Trent! > > > From what i understand, RXTX or JavaComm APIs were not > created solely for JavaPOS. In JavaPOS, we have the virtual method > claim() which is separate from open(), but in our RXTX API, claiming is > done every call to open(), we cant open the port if its claimed by > another application. Would it be alright to suggest or ask to create a > new method called claim(..)? Is there such thing as forceclaim() in > RXTX? this could be the same as portownership transfer or its > equivalent. ForceClaim is in JSR80. > Do you have some samples using RXTX as the lower layer for the Device > Service Objects in JavaPOS? I have tried it, i just want to compare. > maxim Hi Maxim JSR80 is the USB API IBM/Sun put together. The problem is they have a richer kernel/API underneath that can handle such things. With Serial Ports, there isnt anything there other than an ioctl that says don't let anyone touch this and lockfiles that are more of a 'lets be nice.' At times we may be using USB ports but it is through the termios layer with the limitations mentioned. The advantage is that not only USB will work with rxtx. Anything that has a termios layer should work (to the extent that termios layer is complete). I don't know how forceclaim() would help you. Lets say someone has a programmer working on /dev/ttyS0 and you take it. Now you both race each other to read data first. There isn't a mechanism I know of that will solve this problem in termios. The most obvious test being a native app and a Java app trying to take the port. There is the potential of requestion ownership from other Java Applications but the use for that is very rare. Did you have something more specific in mind that I'm missing? I'm not sure that claim() and forceclaim() would help you with rxtx other than maybe locking the port with claim() without opening it. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sat Mar 25 23:42:08 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 25 Mar 2006 23:42:08 -0700 (MST) Subject: [Rxtx] Serial snoop Message-ID: I was reading the Linux kernel mail-list tonight and ran past a thread that mentioned sersnoop. This looks like a handy tool for people dealing with new toys. "a simple command-line tool for linux that echoes bytes to and from any two serial ports, ptys, or network sockets, and prints all traffic to stdout, in hex and ascii." http://www.restivo.org/projects/sersnoop/ It works on Linux only at this time (debian package available). -- Trent Jarvi tjarvi at qbang.org From beat.arnet at gmail.com Sun Mar 26 07:32:35 2006 From: beat.arnet at gmail.com (Beat Arnet) Date: Sun, 26 Mar 2006 09:32:35 -0500 Subject: [Rxtx] Error 0x5 at /home/bob/foo/tar/rxtx-2.1-7/build/../src/termios.c(860): Access is, denied. Message-ID: <4426A603.80508@gmail.com> Dear all, When trying to open the serial port, I sometimes (not always) run into the following exception (when opening the serialPort): Error 0x5 at /home/bob/foo/tar/rxtx-2.1-7/build/../src/termios.c(860): Access is denied. java.lang.UnsatisfiedLinkError: native_psmisc_report_owner at gnu.io.CommPortIdentifier.native_psmisc_report_owner(Native Method) at gnu.io.CommPortIdentifier.open(CommPortIdentifier.java:354) at codeskin.tools.CLLoader.open(CLLoader.java:79) at codeskin.tools.C2000Programmer.run(C2000Programmer.java:220) at java.lang.Thread.run(Unknown Source) Is this the type of error where I should just try to open the port again, or can it be avoided? Regards, Beat From tjarvi at qbang.org Sun Mar 26 11:40:12 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 26 Mar 2006 11:40:12 -0700 (MST) Subject: [Rxtx] Error 0x5 at /home/bob/foo/tar/rxtx-2.1-7/build/../src/termios.c(860): Access is, denied. In-Reply-To: <4426A603.80508@gmail.com> References: <4426A603.80508@gmail.com> Message-ID: On Sun, 26 Mar 2006, Beat Arnet wrote: > Dear all, > > When trying to open the serial port, I sometimes (not always) run into > the following exception (when opening the serialPort): > > Error 0x5 at /home/bob/foo/tar/rxtx-2.1-7/build/../src/termios.c(860): > Access is > denied. > > java.lang.UnsatisfiedLinkError: native_psmisc_report_owner > at gnu.io.CommPortIdentifier.native_psmisc_report_owner(Native > Method) > at gnu.io.CommPortIdentifier.open(CommPortIdentifier.java:354) > at codeskin.tools.CLLoader.open(CLLoader.java:79) > at codeskin.tools.C2000Programmer.run(C2000Programmer.java:220) > at java.lang.Thread.run(Unknown Source) > > Is this the type of error where I should just try to open the port again, > or can it be avoided? > Hi Beat We did a second build of rxtx 2.1-7 to resolve that unsatisfied link error. It should work now. rxtx is trying to tell you it thinks someone else has the serial port open. You can try to open the port again but maybe you already have a copy of the program running when it happens? ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7r2.zip fixed build. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sun Mar 26 11:44:23 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 26 Mar 2006 11:44:23 -0700 (MST) Subject: [Rxtx] RXTX spec file (fwd) Message-ID: This is probably interesting for fedora/suse users. ---------- Forwarded message ---------- Date: Sun, 26 Mar 2006 16:25:45 +0200 To: taj at www.linux.org.uk Subject: RXTX spec file I send you this spec file which allows to create a RPM for Fedora 4, 5 (x86, x86_64) with Java Sun. -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: rxtx.spec Url: http://mailman.qbang.org/pipermail/rxtx/attachments/20060326/6c7b6af6/rxtx-0015.pl From tjarvi at qbang.org Sun Mar 26 23:42:59 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 26 Mar 2006 23:42:59 -0700 (MST) Subject: [Rxtx] Upcomming events. Message-ID: This Wednesday we will be announcing a new "Maintainer" for the rxtx project. The position is more like neutral leader. I wont be going away or doing less. This is just the right thing to do as it turns out the two people with CVS write access will be at the same company. We need a third and we need neutrality. The maintainer will have final say in any conflict and will try to be neutral. It will be open for discussion. Then we will do it :) I'll still do most of the footwork I do now. But. I'm falling behind. I should have gone through the mail-list and posted the next round of changes this weekend. I'm packing to move and its going so so - 13 years of toys collected. I suspect there will be a dead period on my part (a couple weeks) comming up. But if you get it on the mail-list, we will get it in if there are no objections. I may well not be reading the mail-list during this period as I look for a house and many other things. I hope everyone will help out. Thanks -- Trent Jarvi tjarvi at qbang.org From mahmoud_hadad at yahoo.com Sun Mar 26 07:31:19 2006 From: mahmoud_hadad at yahoo.com (ronan nick) Date: Sun, 26 Mar 2006 06:31:19 -0800 (PST) Subject: [Rxtx] a question about the COMM API Message-ID: <20060326143119.54919.qmail@web60014.mail.yahoo.com> hi, i was intrested in knowing how i can communicate with my internal modem using java? for example if i want to make a phone dialer application or a caller id application where should i be looking at? and as i understood the COMM API is for devices that is attached to the computer through serial ports. --------------------------------- New Yahoo! Messenger with Voice. Call regular phones from your PC and save big. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060326/ce8329f0/attachment-0017.html From dmarkman at mac.com Mon Mar 20 00:20:43 2006 From: dmarkman at mac.com (Dmitry Markman) Date: Mon, 20 Mar 2006 02:20:43 -0500 Subject: [Rxtx] Mac OS X RXTX java installer In-Reply-To: References: <07D0DE29-BA32-4CFE-B036-66BC6423D385@buechse.de> <441AE3E0.2030503@willicon.de> <12531986.1142622114996.JavaMail.dmarkman@mac.com> <441B2674.9010409@willicon.de> <13577405.1142634732776.JavaMail.dmarkman@mac.com> <441B4182.8010407@willicon.de> <92CD0D6C-5BE8-426E-A46D-99452059FF49@mac.com> <441BBB2D.8030305@willicon.de> <441C4088.5090905@willicon.de> Message-ID: <64BC1E23-FDDE-4CE6-8863-CFC881CBC224@mac.com> Hi all I put RXTX installer that will install everything (and will create / var/lock if necessary and add user to the uucp group) for mac os x from Java into the rxtx's CVS repository it could be easily modified to install files for any platform it uses Greg Guerin's AuthKit for authentication and authorization Greg released that kit under artistic license, so Trent, please take a look we, probably, can negotiate license with Greg if it's necessary Greg's AuthKit could be downloaded from http://www.amug.org/~glguerin/ sw/#authkit Michael Hall (mikehall at spacestar dot net) had a suggestion to make implementation of the jaas LoginModule based on Greg's AuthKit (his modification of the Greg's AuthKit could be found at http:// www.spacestar.net/users/mikehall/authkit.dmg) but Michael's AuthKitLoginModule does only half a job: it does authenticate but it can not run any external unix process in privileged mode (at least I wasn't able to do so) possible explanation could be found in conversation between Greg and Michael at Apple's java-dev list (look for archives) so I didn't use jaas API for rxtxinstaller I created folder MacOSX in the contrib folder comment 1. if you want to run that installer as standalone application all you need that RXTXInstaller.jar 2. if you want to use webstart you have to add Greg's libAuthKit.jnilib to the mac os x's resources in theory RXTXInstaller.jar doesn't need it, but there is a problem with loading libAuthKit.jnilib from webstart authkit uses loadLibrary method to load library and it failed (from webstart) for standalone application I extract libAuthKit.jnilib from the RXTXInstaller.jar and put it into the /Library/Java/Extensions or ~/Library/Java/Extensions folder that file will be deleted after installer quit unfortunately I didn't have time to put documentation there but it is mostly self-explanatory I took installer code from my gl4java installer that I did about 3 years ago (with small modifications) it would be very nice if Apple will release LoginModule that really will do the job (com.apple.security.auth.module package????? ) (UnixLoginModule is pretty useless) From lyon at docjava.com Mon Mar 20 06:34:39 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Mon, 20 Mar 2006 08:34:39 -0500 Subject: [Rxtx] Mac OS X RXTX java installer In-Reply-To: <64BC1E23-FDDE-4CE6-8863-CFC881CBC224@mac.com> References: <07D0DE29-BA32-4CFE-B036-66BC6423D385@buechse.de> <441AE3E0.2030503@willicon.de> <12531986.1142622114996.JavaMail.dmarkman@mac.com> <441B2674.9010409@willicon.de> <13577405.1142634732776.JavaMail.dmarkman@mac.com> <441B4182.8010407@willicon.de> <92CD0D6C-5BE8-426E-A46D-99452059FF49@mac.com> <441BBB2D.8030305@willicon.de> <441C4088.5090905@willicon.de> <64BC1E23-FDDE-4CE6-8863-CFC881CBC224@mac.com> Message-ID: Hi Dimitry, This sounds like great work. Just a couple of questions; After the check out of the CVS files, using: setenv CVSROOT :pserver:anonymous at cvs.milestonesolutions.com:/usr/local/cvsroot 53 8:28 setenv PASSWORD mousy 54 8:29 cvs login 55 8:29 cvs checkout rxtx-devel I cd'd over to: rxtx-devel/MACOSX_IDE And found: CVS/ CW/ ForPackageMaker/ PB/ Where is the installer? Thanks! - Doug From tjarvi at qbang.org Mon Mar 20 06:39:37 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 20 Mar 2006 06:39:37 -0700 (MST) Subject: [Rxtx] Mac OS X RXTX java installer In-Reply-To: References: <07D0DE29-BA32-4CFE-B036-66BC6423D385@buechse.de> <441AE3E0.2030503@willicon.de> <12531986.1142622114996.JavaMail.dmarkman@mac.com> <441B2674.9010409@willicon.de> <13577405.1142634732776.JavaMail.dmarkman@mac.com> <441B4182.8010407@willicon.de> <92CD0D6C-5BE8-426E-A46D-99452059FF49@mac.com> <441BBB2D.8030305@willicon.de> <441C4088.5090905@willicon.de> <64BC1E23-FDDE-4CE6-8863-CFC881CBC224@mac.com> Message-ID: On Mon, 20 Mar 2006, Dr. Douglas Lyon wrote: > Hi Dimitry, > This sounds like great work. Just a couple of questions; > After the check out of the CVS files, using: > setenv CVSROOT > :pserver:anonymous at cvs.milestonesolutions.com:/usr/local/cvsroot > 53 8:28 setenv PASSWORD mousy > 54 8:29 cvs login > 55 8:29 cvs checkout rxtx-devel Hi Doug You want "cvs checkout -r commapi-0-0-1 rxtx-devel" to get RXTX 2.1 The default branch is rxtx 2.0 which isn't very active right now. -- Trent Jarvi tjarvi at qbang.org From lyon at docjava.com Mon Mar 20 07:05:44 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Mon, 20 Mar 2006 09:05:44 -0500 Subject: [Rxtx] Mac OS X RXTX java installer In-Reply-To: References: <07D0DE29-BA32-4CFE-B036-66BC6423D385@buechse.de> <441AE3E0.2030503@willicon.de> <12531986.1142622114996.JavaMail.dmarkman@mac.com> <441B2674.9010409@willicon.de> <13577405.1142634732776.JavaMail.dmarkman@mac.com> <441B4182.8010407@willicon.de> <92CD0D6C-5BE8-426E-A46D-99452059FF49@mac.com> <441BBB2D.8030305@willicon.de> <441C4088.5090905@willicon.de> <64BC1E23-FDDE-4CE6-8863-CFC881CBC224@mac.com> Message-ID: Hi Trent, Thanks for the info on the CVS checkout procedure. I did that and am still not sure where the installer is. Here is what I have: cd MACOSX_IDE/ p4.docjava.com{lyon}121: ls CVS/ ForPackageMaker/ PB/ p4.docjava.com{lyon}122: find . | more . ./ForPackageMaker ./ForPackageMaker/RXTX.pkg.sit.hqx ./ForPackageMaker/Resources ./ForPackageMaker/Resources/ReadMe.rtf ./ForPackageMaker/Resources/Welcome.rtf ./ForPackageMaker/Resources/CVS ./ForPackageMaker/Resources/CVS/Entries ./ForPackageMaker/Resources/CVS/Repository ./ForPackageMaker/Resources/CVS/Tag ./ForPackageMaker/Resources/CVS/Root ./ForPackageMaker/Resources/preinstall ./ForPackageMaker/Resources/License.rtf ./ForPackageMaker/Resources/preupgrade ./ForPackageMaker/RXTX.pmsp ./ForPackageMaker/CVS ./ForPackageMaker/CVS/Entries ./ForPackageMaker/CVS/Repository ./ForPackageMaker/CVS/Entries.Log ./ForPackageMaker/CVS/Tag ./ForPackageMaker/CVS/Root ./ForPackageMaker/RXTX_Tiger.pkg.sitx.hqx ./ForPackageMaker/RXTX_Jag.pkg.sit.hqx ./ForPackageMaker/Install ./ForPackageMaker/Install/CVS ./ForPackageMaker/Install/CVS/Entries ./ForPackageMaker/Install/CVS/Repository ./ForPackageMaker/Install/CVS/Tag ./ForPackageMaker/Install/CVS/Root ./ForPackageMaker/Install/Library ./ForPackageMaker/Install/Library/CVS ./ForPackageMaker/Install/Library/CVS/Entries ./ForPackageMaker/Install/Library/CVS/Repository ./ForPackageMaker/Install/Library/CVS/Tag ./ForPackageMaker/Install/Library/CVS/Root ./ForPackageMaker/Install/Library/Java ./ForPackageMaker/Install/Library/Java/Extensions ./ForPackageMaker/Install/Library/Java/Extensions/RXTXcomm.jar ./ForPackageMaker/Install/Library/Java/Extensions/CVS ./ForPackageMaker/Install/Library/Java/Extensions/CVS/Entries ./ForPackageMaker/Install/Library/Java/Extensions/CVS/Repository ./ForPackageMaker/Install/Library/Java/Extensions/CVS/Tag ./ForPackageMaker/Install/Library/Java/Extensions/CVS/Root ./ForPackageMaker/Install/Library/Java/Extensions/librxtxSerial.jnilib ./ForPackageMaker/Install/Library/Java/CVS ./ForPackageMaker/Install/Library/Java/CVS/Entries ./ForPackageMaker/Install/Library/Java/CVS/Repository ./ForPackageMaker/Install/Library/Java/CVS/Entries.Log ./ForPackageMaker/Install/Library/Java/CVS/Tag ./ForPackageMaker/Install/Library/Java/CVS/Root ./ForPackageMaker/RXTX_Tiger.pmproj.sitx.hqx ./CVS ./CVS/Entries ./CVS/Repository ./CVS/Entries.Log ./CVS/Tag ./CVS/Root ./PB ./PB/LibSerialUniversal.xcodeproj.sitx.hqx ./PB/CVS ./PB/CVS/Entries ./PB/CVS/Repository ./PB/CVS/Entries.Log ./PB/CVS/Tag ./PB/CVS/Root ./PB/LibSerial.pbproj.sit.hqx ./PB/startpoint.c ./PB/config.h What is the procedure to run this installer? Do we need a README in: /rxtx-devel/MACOSX_IDE Here is what we have: CVS/ ForPackageMaker/ PB/ Thanks! - DL >On Mon, 20 Mar 2006, Dr. Douglas Lyon wrote: > >>Hi Dimitry, >>This sounds like great work. Just a couple of questions; >>After the check out of the CVS files, using: >>setenv CVSROOT >>:pserver:anonymous at cvs.milestonesolutions.com:/usr/local/cvsroot >> 53 8:28 setenv PASSWORD mousy >> 54 8:29 cvs login >> 55 8:29 cvs checkout rxtx-devel > >Hi Doug > >You want "cvs checkout -r commapi-0-0-1 rxtx-devel" to get RXTX 2.1 >The default branch is rxtx 2.0 which isn't very active right now. > >-- >Trent Jarvi >tjarvi at qbang.org From tjarvi at qbang.org Mon Mar 20 07:25:30 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 20 Mar 2006 07:25:30 -0700 (MST) Subject: [Rxtx] Mac OS X RXTX java installer In-Reply-To: References: <07D0DE29-BA32-4CFE-B036-66BC6423D385@buechse.de> <441AE3E0.2030503@willicon.de> <12531986.1142622114996.JavaMail.dmarkman@mac.com> <441B2674.9010409@willicon.de> <13577405.1142634732776.JavaMail.dmarkman@mac.com> <441B4182.8010407@willicon.de> <92CD0D6C-5BE8-426E-A46D-99452059FF49@mac.com> <441BBB2D.8030305@willicon.de> <441C4088.5090905@willicon.de> <64BC1E23-FDDE-4CE6-8863-CFC881CBC224@mac.com> Message-ID: On Mon, 20 Mar 2006, Dr. Douglas Lyon wrote: > Hi Trent, > Thanks for the info on the CVS checkout procedure. > I did that and am still not sure where the installer is. Hi Doug It does look like it was not cvs committed. There is no rxtx-devel/contrib/MacOSX directory in there at the moment. It was mentioned that it was put under contrib. -- Trent Jarvi tjarvi at qbang.org From dmarkman at mac.com Mon Mar 20 07:29:56 2006 From: dmarkman at mac.com (Dmitry Markman) Date: Mon, 20 Mar 2006 09:29:56 -0500 Subject: [Rxtx] Mac OS X RXTX java installer In-Reply-To: References: <07D0DE29-BA32-4CFE-B036-66BC6423D385@buechse.de> <441AE3E0.2030503@willicon.de> <12531986.1142622114996.JavaMail.dmarkman@mac.com> <441B2674.9010409@willicon.de> <13577405.1142634732776.JavaMail.dmarkman@mac.com> <441B4182.8010407@willicon.de> <92CD0D6C-5BE8-426E-A46D-99452059FF49@mac.com> <441BBB2D.8030305@willicon.de> <441C4088.5090905@willicon.de> <64BC1E23-FDDE-4CE6-8863-CFC881CBC224@mac.com> Message-ID: <6054EB4E-F7E0-4A9C-BDDA-D582D6D8826F@mac.com> you can find it in the rxtx-devel/contrib folder On Mar 20, 2006, at 9:05 AM, Dr. Douglas Lyon wrote: > Hi Trent, > Thanks for the info on the CVS checkout procedure. > I did that and am still not sure where the installer is. > Here is what I have: > cd MACOSX_IDE/ > p4.docjava.com{lyon}121: ls > CVS/ ForPackageMaker/ PB/ > p4.docjava.com{lyon}122: find . | more > . > ./ForPackageMaker > ./ForPackageMaker/RXTX.pkg.sit.hqx > ./ForPackageMaker/Resources > ./ForPackageMaker/Resources/ReadMe.rtf > ./ForPackageMaker/Resources/Welcome.rtf > ./ForPackageMaker/Resources/CVS > ./ForPackageMaker/Resources/CVS/Entries > ./ForPackageMaker/Resources/CVS/Repository > ./ForPackageMaker/Resources/CVS/Tag > ./ForPackageMaker/Resources/CVS/Root > ./ForPackageMaker/Resources/preinstall > ./ForPackageMaker/Resources/License.rtf > ./ForPackageMaker/Resources/preupgrade > ./ForPackageMaker/RXTX.pmsp > ./ForPackageMaker/CVS > ./ForPackageMaker/CVS/Entries > ./ForPackageMaker/CVS/Repository > ./ForPackageMaker/CVS/Entries.Log > ./ForPackageMaker/CVS/Tag > ./ForPackageMaker/CVS/Root > ./ForPackageMaker/RXTX_Tiger.pkg.sitx.hqx > ./ForPackageMaker/RXTX_Jag.pkg.sit.hqx > ./ForPackageMaker/Install > ./ForPackageMaker/Install/CVS > ./ForPackageMaker/Install/CVS/Entries > ./ForPackageMaker/Install/CVS/Repository > ./ForPackageMaker/Install/CVS/Tag > ./ForPackageMaker/Install/CVS/Root > ./ForPackageMaker/Install/Library > ./ForPackageMaker/Install/Library/CVS > ./ForPackageMaker/Install/Library/CVS/Entries > ./ForPackageMaker/Install/Library/CVS/Repository > ./ForPackageMaker/Install/Library/CVS/Tag > ./ForPackageMaker/Install/Library/CVS/Root > ./ForPackageMaker/Install/Library/Java > ./ForPackageMaker/Install/Library/Java/Extensions > ./ForPackageMaker/Install/Library/Java/Extensions/RXTXcomm.jar > ./ForPackageMaker/Install/Library/Java/Extensions/CVS > ./ForPackageMaker/Install/Library/Java/Extensions/CVS/Entries > ./ForPackageMaker/Install/Library/Java/Extensions/CVS/Repository > ./ForPackageMaker/Install/Library/Java/Extensions/CVS/Tag > ./ForPackageMaker/Install/Library/Java/Extensions/CVS/Root > ./ForPackageMaker/Install/Library/Java/Extensions/librxtxSerial.jnilib > ./ForPackageMaker/Install/Library/Java/CVS > ./ForPackageMaker/Install/Library/Java/CVS/Entries > ./ForPackageMaker/Install/Library/Java/CVS/Repository > ./ForPackageMaker/Install/Library/Java/CVS/Entries.Log > ./ForPackageMaker/Install/Library/Java/CVS/Tag > ./ForPackageMaker/Install/Library/Java/CVS/Root > ./ForPackageMaker/RXTX_Tiger.pmproj.sitx.hqx > ./CVS > ./CVS/Entries > ./CVS/Repository > ./CVS/Entries.Log > ./CVS/Tag > ./CVS/Root > ./PB > ./PB/LibSerialUniversal.xcodeproj.sitx.hqx > ./PB/CVS > ./PB/CVS/Entries > ./PB/CVS/Repository > ./PB/CVS/Entries.Log > ./PB/CVS/Tag > ./PB/CVS/Root > ./PB/LibSerial.pbproj.sit.hqx > ./PB/startpoint.c > ./PB/config.h > > What is the procedure to run this installer? > Do we need a README in: > /rxtx-devel/MACOSX_IDE > Here is what we have: > CVS/ ForPackageMaker/ PB/ > > > Thanks! > - DL > >> On Mon, 20 Mar 2006, Dr. Douglas Lyon wrote: >> >>> Hi Dimitry, >>> This sounds like great work. Just a couple of questions; >>> After the check out of the CVS files, using: >>> setenv CVSROOT :pserver:anonymous at cvs.milestonesolutions.com:/usr/ >>> local/cvsroot >>> 53 8:28 setenv PASSWORD mousy >>> 54 8:29 cvs login >>> 55 8:29 cvs checkout rxtx-devel >> >> Hi Doug >> >> You want "cvs checkout -r commapi-0-0-1 rxtx-devel" to get RXTX 2.1 >> The default branch is rxtx 2.0 which isn't very active right now. >> >> -- >> Trent Jarvi >> tjarvi at qbang.org > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx Dmitry Markman From mikehall at spacestar.net Mon Mar 20 05:25:25 2006 From: mikehall at spacestar.net (Michael Hall) Date: Mon, 20 Mar 2006 06:25:25 -0600 Subject: [Rxtx] Re: Mac OS X RXTX java installer In-Reply-To: <64BC1E23-FDDE-4CE6-8863-CFC881CBC224@mac.com> References: <07D0DE29-BA32-4CFE-B036-66BC6423D385@buechse.de> <441AE3E0.2030503@willicon.de> <12531986.1142622114996.JavaMail.dmarkman@mac.com> <441B2674.9010409@willicon.de> <13577405.1142634732776.JavaMail.dmarkman@mac.com> <441B4182.8010407@willicon.de> <92CD0D6C-5BE8-426E-A46D-99452059FF49@mac.com> <441BBB2D.8030305@willicon.de> <441C4088.5090905@willicon.de> <64BC1E23-FDDE-4CE6-8863-CFC881CBC224@mac.com> Message-ID: <247EB61F-5CD1-4132-89A2-FC105B6CF9A5@spacestar.net> On Mar 20, 2006, at 1:20 AM, Dmitry Markman wrote: > > Michael Hall (mikehall at spacestar dot net) had a suggestion to > make implementation of the jaas LoginModule > based on Greg's AuthKit > (his modification of the Greg's AuthKit could be found at http:// > www.spacestar.net/users/mikehall/authkit.dmg) > but Michael's AuthKitLoginModule does only half a job: > it does authenticate > but it can not run any external unix process in privileged mode (at > least I wasn't able to do so) If you got it working directly with Greg's the point is moot. But to clarify it anyhow. The login module does not allow you to do anything anything privileged on return as was explained by Greg. You need to work with a separate privileged process using the execPrivileged method of his API. I assume you did something similar although I haven't looked at how you are using it yet. I allowed instead for a action to be performed at the same time you login/authenticate,this... System.setProperty("authkit.action","/usr/bin/id"); just before this... lc.login(); To clarify, safely ignored as you are already complete. Mike Hall mikehall at spacestar dot net http://www.spacestar.net/users/mikehall http://sourceforge.net/projects/macnative -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2427 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20060320/f6e18202/smime-0020.bin From dmarkman at mac.com Mon Mar 20 07:36:47 2006 From: dmarkman at mac.com (Dmitry Markman) Date: Mon, 20 Mar 2006 09:36:47 -0500 Subject: [Rxtx] Re: Mac OS X RXTX java installer In-Reply-To: <247EB61F-5CD1-4132-89A2-FC105B6CF9A5@spacestar.net> References: <07D0DE29-BA32-4CFE-B036-66BC6423D385@buechse.de> <441AE3E0.2030503@willicon.de> <12531986.1142622114996.JavaMail.dmarkman@mac.com> <441B2674.9010409@willicon.de> <13577405.1142634732776.JavaMail.dmarkman@mac.com> <441B4182.8010407@willicon.de> <92CD0D6C-5BE8-426E-A46D-99452059FF49@mac.com> <441BBB2D.8030305@willicon.de> <441C4088.5090905@willicon.de> <64BC1E23-FDDE-4CE6-8863-CFC881CBC224@mac.com> <247EB61F-5CD1-4132-89A2-FC105B6CF9A5@spacestar.net> Message-ID: Hi, Michael all I have to do is to run some shell script I tried to use your action mechanism and it worked great so I just System.setProperty ("authkit.action","" ) and after that I even don't need to run anything like subject.doAs.... but after few thoughts I choose to use plain Greg's approach, because in that case I don't have to deal with various java's configurations files and therefore to use 2-3 -D parameters in the java command line especially it's useful for java web start (it's so fragile :-( ) thanks for the great job On Mar 20, 2006, at 7:25 AM, Michael Hall wrote: > > On Mar 20, 2006, at 1:20 AM, Dmitry Markman wrote: >> >> Michael Hall (mikehall at spacestar dot net) had a suggestion to >> make implementation of the jaas LoginModule >> based on Greg's AuthKit >> (his modification of the Greg's AuthKit could be found at http:// >> www.spacestar.net/users/mikehall/authkit.dmg) >> but Michael's AuthKitLoginModule does only half a job: >> it does authenticate >> but it can not run any external unix process in privileged mode >> (at least I wasn't able to do so) > > If you got it working directly with Greg's the point is moot. > > But to clarify it anyhow. > The login module does not allow you to do anything anything > privileged on return as was explained by Greg. You need to work > with a separate privileged process using the execPrivileged method > of his API. I assume you did something similar although I haven't > looked at how you are using it yet. > I allowed instead for a action to be performed at the same time you > login/authenticate,this... > System.setProperty("authkit.action","/usr/bin/id"); > just before this... > lc.login(); > To clarify, safely ignored as you are already complete. > > Mike Hall mikehall at spacestar dot net > http://www.spacestar.net/users/mikehall > http://sourceforge.net/projects/macnative > > > Dmitry Markman From dmarkman at mac.com Mon Mar 20 07:44:45 2006 From: dmarkman at mac.com (Dmitry Markman) Date: Mon, 20 Mar 2006 09:44:45 -0500 Subject: [Rxtx] Mac OS X RXTX java installer In-Reply-To: References: <07D0DE29-BA32-4CFE-B036-66BC6423D385@buechse.de> <441AE3E0.2030503@willicon.de> <12531986.1142622114996.JavaMail.dmarkman@mac.com> <441B2674.9010409@willicon.de> <13577405.1142634732776.JavaMail.dmarkman@mac.com> <441B4182.8010407@willicon.de> <92CD0D6C-5BE8-426E-A46D-99452059FF49@mac.com> <441BBB2D.8030305@willicon.de> <441C4088.5090905@willicon.de> <64BC1E23-FDDE-4CE6-8863-CFC881CBC224@mac.com> Message-ID: it's in the commapi-0-0-1 branch I tested it right now: cvs co -r commapi-0-0-1 rxtx-devel and I got everything On Mar 20, 2006, at 9:25 AM, Trent Jarvi wrote: > On Mon, 20 Mar 2006, Dr. Douglas Lyon wrote: > >> Hi Trent, >> Thanks for the info on the CVS checkout procedure. >> I did that and am still not sure where the installer is. > > Hi Doug > > It does look like it was not cvs committed. There is no rxtx-devel/ > contrib/MacOSX directory in there at the moment. It was mentioned > that it was put under contrib. > > -- > Trent Jarvi > tjarvi at qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx Dmitry Markman From tjarvi at qbang.org Mon Mar 20 07:52:57 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 20 Mar 2006 07:52:57 -0700 (MST) Subject: [Rxtx] Mac OS X RXTX java installer In-Reply-To: References: <07D0DE29-BA32-4CFE-B036-66BC6423D385@buechse.de> <441AE3E0.2030503@willicon.de> <12531986.1142622114996.JavaMail.dmarkman@mac.com> <441B2674.9010409@willicon.de> <13577405.1142634732776.JavaMail.dmarkman@mac.com> <441B4182.8010407@willicon.de> <92CD0D6C-5BE8-426E-A46D-99452059FF49@mac.com> <441BBB2D.8030305@willicon.de> <441C4088.5090905@willicon.de> <64BC1E23-FDDE-4CE6-8863-CFC881CBC224@mac.com> Message-ID: On Mon, 20 Mar 2006, Dmitry Markman wrote: > it's in the commapi-0-0-1 branch > > I tested it right now: > cvs co -r commapi-0-0-1 rxtx-devel > > and I got everything > A fresh checkout worked. Here is a copy of the tree (just the installer bits) ftp://ftp.qbang.org/pub/rxtx/MacOSX-installer.zip -- Trent Jarvi tjarvi at qbang.org From lyon at docjava.com Mon Mar 20 08:08:26 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Mon, 20 Mar 2006 10:08:26 -0500 Subject: [Rxtx] Mac OS X RXTX java installer In-Reply-To: References: <07D0DE29-BA32-4CFE-B036-66BC6423D385@buechse.de> <441AE3E0.2030503@willicon.de> <12531986.1142622114996.JavaMail.dmarkman@mac.com> <441B2674.9010409@willicon.de> <13577405.1142634732776.JavaMail.dmarkman@mac.com> <441B4182.8010407@willicon.de> <92CD0D6C-5BE8-426E-A46D-99452059FF49@mac.com> <441BBB2D.8030305@willicon.de> <441C4088.5090905@willicon.de> <64BC1E23-FDDE-4CE6-8863-CFC881CBC224@mac.com> Message-ID: Hi All, Is the Auth package able to work properly on non Mac OS's? It was not clear from the doc or download. Thanks! - Doug From dmarkman at mac.com Mon Mar 20 08:15:22 2006 From: dmarkman at mac.com (Dmitry Markman) Date: Mon, 20 Mar 2006 10:15:22 -0500 Subject: [Rxtx] Mac OS X RXTX java installer In-Reply-To: References: <07D0DE29-BA32-4CFE-B036-66BC6423D385@buechse.de> <441AE3E0.2030503@willicon.de> <12531986.1142622114996.JavaMail.dmarkman@mac.com> <441B2674.9010409@willicon.de> <13577405.1142634732776.JavaMail.dmarkman@mac.com> <441B4182.8010407@willicon.de> <92CD0D6C-5BE8-426E-A46D-99452059FF49@mac.com> <441BBB2D.8030305@willicon.de> <441C4088.5090905@willicon.de> <64BC1E23-FDDE-4CE6-8863-CFC881CBC224@mac.com> Message-ID: <217312D8-CCCA-4859-ABA6-32DF1CC817B9@mac.com> thanks Trent, for putting it on ftp server On Mar 20, 2006, at 9:52 AM, Trent Jarvi wrote: > A fresh checkout worked. Here is a copy of the tree (just the > installer bits) > > ftp://ftp.qbang.org/pub/rxtx/MacOSX-installer.zip > Dmitry Markman From dmarkman at mac.com Mon Mar 20 09:14:03 2006 From: dmarkman at mac.com (Dmitry Markman) Date: Mon, 20 Mar 2006 11:14:03 -0500 Subject: [Rxtx] Mac OS X RXTX java installer In-Reply-To: References: <07D0DE29-BA32-4CFE-B036-66BC6423D385@buechse.de> <441AE3E0.2030503@willicon.de> <12531986.1142622114996.JavaMail.dmarkman@mac.com> <441B2674.9010409@willicon.de> <13577405.1142634732776.JavaMail.dmarkman@mac.com> <441B4182.8010407@willicon.de> <92CD0D6C-5BE8-426E-A46D-99452059FF49@mac.com> <441BBB2D.8030305@willicon.de> <441C4088.5090905@willicon.de> <64BC1E23-FDDE-4CE6-8863-CFC881CBC224@mac.com> Message-ID: <4DEBA6F0-DA45-4E84-823E-1F1AC48BDCCC@mac.com> no it will work only on mac os x however it's harmless to run it on other platform if you want to use it for other platform you have to do the following (I'll do it for linux) 1. modify RXTXInstaller class method public static RXTXInstaller getInstance() public static RXTXInstaller getInstance() { String osName = System.getProperty("os.name").toLowerCase(); if(osName.startsWith("mac")){ return new gnu.io.installer.macosx.MACOSXRXTXInstaller(); } else if(osName.startsWith("windows")){ return new gnu.io.installer.windows.WindowsRXTXInstaller(); }else if(osName.startsWith("linux")){ return new gnu.io.installer.linux.LinuxRXTXInstaller(); } return null; } 2. create folder gnu/io/installer/linux/ 3. create class Linux386RXTXInstaller package gnu.io.installer.linux; import java.io.File; public class Linux386RXTXInstaller extends gnu.io.installer.RXTXInstaller{ public Linux386RXTXInstaller(){ createJarFolder(); createLibFolder(); addJarResource("RXTXcomm.jar","/gnu/io/installer/resources/ linux/jar/RXTXcomm.dat"); addLibResource("librxtxSerial.so","/gnu/io/installer/ resources/linux/lib/librxtxSerial.so"); } protected void createJarFolder(){ String javaHome = System.getProperty("java.home"); char separator = File.separatorChar; jarFolder = new File(javaHome+separator+"lib"+separator+"ext"); } protected void createLibFolder(){ String javaHome = System.getProperty("java.home"); char separator = File.separatorChar; libFolder = new File(javaHome+separator+"bin"); } public void runPreProcess() {} //put here some action you need public void runPostProcess() {} //put here some action you need } 4. create folder /gnu/io/installer/resources/linux/jar and put there linux's version of RXTXcomm.dat (which is renamed RXTXcomm.jar) 5. create folder /gnu/io/installer/resources/linux/lib and put there linux's version of librxtxSerial. so 6. make sure that RXTXInstaller.jar has the following items: /gnu/io/installer/resources/linux/jar/RXTXcomm.jar /gnu/io/installer/resources/linux/lib/librxtxSerial.so 7. modify file installer.pref: jar file RXTXInstaller.jar must have the following item /gnu/io/installer/installer.pref that's basically it for windows you have to do the similar things: just replace linux to windows and librxtxSerial.so to rxtxSerial.dll and create appropriate gnu.io.installer.windows.WindowsRXTXInstaller class package gnu.io.installer.windows; import java.io.File; public class WindowsRXTXInstaller extends gnu.io.installer.RXTXInstaller{ public WindowsRXTXInstaller(){ createJarFolder(); createLibFolder(); addJarResource("RXTXcomm.jar","/gnu/io/installer/resources/ windows/jar/RXTXcomm.dat"); addLibResource("librxtxSerial.so","/gnu/io/installer/ resources/windows/lib/rxtxSerial.dll"); } protected void createJarFolder(){ String javaHome = System.getProperty("java.home"); char separator = File.separatorChar; jarFolder = new File(javaHome+separator+"lib"+separator+"ext"); } protected void createLibFolder(){ String javaHome = System.getProperty("java.home"); char separator = File.separatorChar; libFolder = new File(javaHome+separator+"bin"); } public void runPreProcess() {} //put here some action you need public void runPostProcess() {} //put here some action you need } installer.pref will look like On Mar 20, 2006, at 10:08 AM, Dr. Douglas Lyon wrote: > Hi All, > Is the Auth package able to work properly on > non Mac OS's? > It was not clear from the doc or download. > > Thanks! > - Doug > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx Dmitry Markman From joachim at buechse.de Mon Mar 20 10:49:06 2006 From: joachim at buechse.de (Joachim Buechse) Date: Mon, 20 Mar 2006 18:49:06 +0100 Subject: [Rxtx] BUG: Lock file stays even if port opening fails Message-ID: This was only tested on MacOSX but looking at the code, it should be true for all systems that use lock_uucp. I am opening a port which can not be opened (dialup port of a telephone paired via bluetooth but currently not reachable). The lock file is created and stays arround, even though the port open failed. After looking a bit through the code (of 2.17), I really wonder if it wouldn't be a good idea to make the "locking" an explicit operation called from the java code. This would certainly simplify the generation of meaningfull exceptions (and java based debugging). Maybe even the handling of "preopened" ports should be in the Java part of the lib (again for java based debugging puposes). That beeing said, I have no idea if this would be possible for the 2.07 implementation. Regards, Joachim From tjarvi at qbang.org Mon Mar 20 11:24:22 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 20 Mar 2006 11:24:22 -0700 (MST) Subject: [Rxtx] BUG: Lock file stays even if port opening fails In-Reply-To: References: Message-ID: On Mon, 20 Mar 2006, Joachim Buechse wrote: > This was only tested on MacOSX but looking at the code, it should be true > for all systems that use lock_uucp. > > I am opening a port which can not be opened (dialup port of a telephone > paired via bluetooth but currently not reachable). The lock file is > created and stays arround, even though the port open failed. > > > After looking a bit through the code (of 2.17), I really wonder if it > wouldn't be a good idea to make the "locking" an explicit operation > called from the java code. This would certainly simplify the generation > of meaningfull exceptions (and java based debugging). > Maybe even the handling of "preopened" ports should be in the Java part > of the lib (again for java based debugging puposes). That beeing said, I > have no idea if this would be possible for the 2.07 implementation. > > Regards, Hi Joachim It should be possible in the 2.0-7 implementation too. The calls to RXTXPort.java would not change. We would just do more there Moving more of that logic into Java would be better as many people don't like to look at C code. There is a liblockdev on most Linux distros that can do most of the C code and would be easier to use. The problem is embeded devices will not have that library. The preopened port code has not been really tested. That was a last minute request in a product cycle. I expect it will be tested this year though. As I recall, some devices really do not like CD raising on open. The preopened ports then allow people to mess around in java without power cycling the devices or losing data. -- Trent Jarvi tjarvi at qbang.org From joachim at buechse.de Mon Mar 20 12:01:08 2006 From: joachim at buechse.de (Joachim Buechse) Date: Mon, 20 Mar 2006 20:01:08 +0100 Subject: [Rxtx] BUG: Lock file stays even if port opening fails In-Reply-To: References: Message-ID: Hi Trent, What is your general feeling about moving code to Java? The last days I have been reading quite a bit of the code and there are several things, that might not work as expected. I'll give you two examples from is_device_locked: if LOCKDIR == /var/spool/locks the directory /var/spool/lock will not be checked. LOCKDIR is not checked for lockfiles with unexpected pefixes While these things have probably never been discovered in production, they are still possibly incorrect implementations. If it was Java code, I would write some unit tests producing the errors that could later be corrected. PS: One could imagine to actually implement the whole lockfile handling in Java using some native routines to get the values required (pid, st_dev, st_rdev, ...). On 20.03.2006, at 19:24, Trent Jarvi wrote: > On Mon, 20 Mar 2006, Joachim Buechse wrote: > >> This was only tested on MacOSX but looking at the code, it should >> be true for all systems that use lock_uucp. >> >> I am opening a port which can not be opened (dialup port of a >> telephone paired via bluetooth but currently not reachable). The >> lock file is created and stays arround, even though the port open >> failed. >> >> >> After looking a bit through the code (of 2.17), I really wonder if >> it wouldn't be a good idea to make the "locking" an explicit >> operation called from the java code. This would certainly simplify >> the generation of meaningfull exceptions (and java based debugging). >> Maybe even the handling of "preopened" ports should be in the Java >> part of the lib (again for java based debugging puposes). That >> beeing said, I have no idea if this would be possible for the 2.07 >> implementation. >> >> Regards, > > Hi Joachim > > It should be possible in the 2.0-7 implementation too. The calls > to RXTXPort.java would not change. We would just do more there > Moving more of that logic into Java would be better as many people > don't like to look at C code. There is a liblockdev on most Linux > distros that can do most of the C code and would be easier to use. > The problem is embeded devices will not have that library. > > The preopened port code has not been really tested. That was a > last minute request in a product cycle. I expect it will be tested > this year though. As I recall, some devices really do not like CD > raising on open. The preopened ports then allow people to mess > around in java without power cycling the devices or losing data. > > -- > Trent Jarvi > tjarvi at qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Mon Mar 20 12:21:02 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 20 Mar 2006 12:21:02 -0700 (MST) Subject: [Rxtx] BUG: Lock file stays even if port opening fails In-Reply-To: References: Message-ID: On Mon, 20 Mar 2006, Joachim Buechse wrote: > Hi Trent, > > What is your general feeling about moving code to Java? The last days I > have been reading quite a bit of the code and there are several things, > that might not work as expected. > > I'll give you two examples from is_device_locked: > > if LOCKDIR == /var/spool/locks the directory /var/spool/lock will not be > checked. > LOCKDIR is not checked for lockfiles with unexpected pefixes > > While these things have probably never been discovered in production, > they are still possibly incorrect implementations. If it was Java code, I > would write some unit tests producing the errors that could later be > corrected. > > PS: One could imagine to actually implement the whole lockfile handling > in Java using some native routines to get the values required (pid, > st_dev, st_rdev, ...). Hi Joachim I like the idea of moving more of the code into java but there are some things to consider. If you break this into multiple JNI calls, the performance will drop considerably during enumeration of ports. We are looking for 256 ports per dev type vs (16? in Sun's 2.0 and fewer types). Its hard to make assumptions. I've seen virtual ports start at /dev/foo100 for instance. It works out to over 7500 ports on Linux if you enable them all. We already trim that back by default. See Linux-all-ports in RXTXCommDriver.java. There are also native libraries that rxtx can link to. If you move too much into Java, linking to 'standard' libraries with distros will break. "configure --enable-liblock=yes" will not be doable. This is probably a favorable way with RedHat, Debian, Suse and others. Thats the right thing to do if there will be rpms, dpkg, .. For those reasons, I think it still make sense to keep it to a minimal ~3 calls to JNI code that we can use for speed and versatility. lock() isLocked(), unlock() perhaps. When I say speed, its more about avoiding crossing the JNI layer multiple times than java vs C performance. With versatility I think liblock is the right way for most but not all (embeded) linux distros. -- Trent Jarvi tjarvi at qbang.org From joachim at buechse.de Mon Mar 20 12:42:04 2006 From: joachim at buechse.de (Joachim Buechse) Date: Mon, 20 Mar 2006 20:42:04 +0100 Subject: [Rxtx] BUG: Lock file stays even if port opening fails In-Reply-To: References: Message-ID: <82C19FE7-DDCB-45B6-B2C9-7606B66F0124@buechse.de> Ok, what about providing a default implementation in Java? The RXTXCommDriver would call a (native) function useNativeLocking and if it returns true, call the native functions for lock() isLocked (), unlock(), else is would use the Java based default implementation. This could possibly be overriden by a property (again for debugging). Joachim On 20.03.2006, at 20:21, Trent Jarvi wrote: > On Mon, 20 Mar 2006, Joachim Buechse wrote: > >> Hi Trent, >> >> What is your general feeling about moving code to Java? The last >> days I have been reading quite a bit of the code and there are >> several things, that might not work as expected. >> >> I'll give you two examples from is_device_locked: >> >> if LOCKDIR == /var/spool/locks the directory /var/spool/lock will >> not be checked. >> LOCKDIR is not checked for lockfiles with unexpected pefixes >> >> While these things have probably never been discovered in >> production, they are still possibly incorrect implementations. If >> it was Java code, I would write some unit tests producing the >> errors that could later be corrected. >> >> PS: One could imagine to actually implement the whole lockfile >> handling in Java using some native routines to get the values >> required (pid, st_dev, st_rdev, ...). > > Hi Joachim > > I like the idea of moving more of the code into java but there are > some things to consider. > > If you break this into multiple JNI calls, the performance will > drop considerably during enumeration of ports. We are looking for > 256 ports per dev type vs (16? in Sun's 2.0 and fewer types). Its > hard to make assumptions. I've seen virtual ports start at /dev/ > foo100 for instance. > > It works out to over 7500 ports on Linux if you enable them all. > We already trim that back by default. See Linux-all-ports in > RXTXCommDriver.java. > > There are also native libraries that rxtx can link to. If you move > too much into Java, linking to 'standard' libraries with distros > will break. "configure --enable-liblock=yes" will not be doable. > This is probably a favorable way with RedHat, Debian, Suse and > others. Thats the right thing to do if there will be rpms, dpkg, .. > > For those reasons, I think it still make sense to keep it to a > minimal ~3 calls to JNI code that we can use for speed and > versatility. lock() isLocked(), unlock() perhaps. When I say > speed, its more about avoiding crossing the JNI layer multiple > times than java vs C performance. With versatility I think liblock > is the right way for most but not all (embeded) linux distros. > > -- > Trent Jarvi > tjarvi at qbang.org > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Mon Mar 20 12:44:47 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 20 Mar 2006 12:44:47 -0700 (MST) Subject: [Rxtx] BUG: Lock file stays even if port opening fails In-Reply-To: <82C19FE7-DDCB-45B6-B2C9-7606B66F0124@buechse.de> References: <82C19FE7-DDCB-45B6-B2C9-7606B66F0124@buechse.de> Message-ID: On Mon, 20 Mar 2006, Joachim Buechse wrote: > Ok, what about providing a default implementation in Java? > > The RXTXCommDriver would call a (native) function useNativeLocking and if > it returns true, call the native functions for lock() isLocked(), > unlock(), else is would use the Java based default implementation. This > could possibly be overriden by a property (again for debugging). > Hi Joachim That would be OK with me. -- Trent Jarvi tjarvi at qbang.org From dmarkman at mac.com Mon Mar 20 22:27:45 2006 From: dmarkman at mac.com (Dmitry Markman) Date: Tue, 21 Mar 2006 00:27:45 -0500 Subject: [Rxtx] binaries request Message-ID: <42702213-C222-4937-A585-7CFB17E47608@mac.com> Hi can somebody send me latest linux and windows binaries, please? or where I can find them (I didn't find them in the latest tareball) I gave up with my cygwin: something wrong I have no idea what java doesn't understand /cygwin/c syntax after I changed makefile it did java part but after that gcc 3.4.4 started to complain I set buffer length to 999 lines but I didn't get beginning of the story something wrong with my 1.4.2_09/include/jni.h gcc doesn't like it anyway I gave up thanks in advance Dmitry Markman -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060320/f8cbc57c/attachment-0020.html From tjarvi at qbang.org Mon Mar 20 22:36:48 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 20 Mar 2006 22:36:48 -0700 (MST) Subject: [Rxtx] binaries request In-Reply-To: <42702213-C222-4937-A585-7CFB17E47608@mac.com> References: <42702213-C222-4937-A585-7CFB17E47608@mac.com> Message-ID: On Tue, 21 Mar 2006, Dmitry Markman wrote: > Hi > can somebody send me latest linux and windows binaries, please? > > or where I can find them (I didn't find them in the latest tareball) > > I gave up with my cygwin: something wrong I have no idea what > java doesn't understand /cygwin/c syntax > after I changed makefile it did java part > but after that gcc 3.4.4 started to complain > I set buffer length to 999 lines but I didn't get beginning of the story > something wrong with my 1.4.2_09/include/jni.h gcc doesn't like it > anyway I gave up > > thanks in advance > Hi Dmitry The bins are here: ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7-bins-r2.zip Here are the files in the zip you want. Jar: rxtx-2.1-7-bins-r2/RXTXcomm.jar Windows: rxtx-2.1-7-bins-r2/Windows/i368-mingw32/rxtxSerial.dll Linux (x86) rxtx-2.1-7-bins-r2/Linux/i686-unknown-linux-gnu/librxtxSerial.so There are others in there including Parallel port support but those are the main ones for testing. -- Trent Jarvi tjarvi at qbang.org From dmarkman at mac.com Mon Mar 20 23:05:59 2006 From: dmarkman at mac.com (Dmitry Markman) Date: Tue, 21 Mar 2006 01:05:59 -0500 Subject: [Rxtx] binaries request In-Reply-To: References: <42702213-C222-4937-A585-7CFB17E47608@mac.com> Message-ID: thank you very much but windows's readme says: rxtxSerial.dll had to be recomopiled to link in missing native methods. should I ignore it? or what? thanks again also I understand that I should use mingw not cygwin I'll try to install mingw On Mar 21, 2006, at 12:36 AM, Trent Jarvi wrote: > On Tue, 21 Mar 2006, Dmitry Markman wrote: > >> Hi >> can somebody send me latest linux and windows binaries, please? >> >> or where I can find them (I didn't find them in the latest tareball) >> >> I gave up with my cygwin: something wrong I have no idea what >> java doesn't understand /cygwin/c syntax >> after I changed makefile it did java part >> but after that gcc 3.4.4 started to complain >> I set buffer length to 999 lines but I didn't get beginning of the >> story >> something wrong with my 1.4.2_09/include/jni.h gcc doesn't like it >> anyway I gave up >> >> thanks in advance >> > > Hi Dmitry > > The bins are here: > > ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7-bins-r2.zip > > Here are the files in the zip you want. > > Jar: > > rxtx-2.1-7-bins-r2/RXTXcomm.jar > > Windows: > > rxtx-2.1-7-bins-r2/Windows/i368-mingw32/rxtxSerial.dll > > Linux (x86) > > rxtx-2.1-7-bins-r2/Linux/i686-unknown-linux-gnu/librxtxSerial.so > > There are others in there including Parallel port support but those > are the main ones for testing. > > -- > Trent Jarvi > tjarvi at qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx Dmitry Markman From tjarvi at qbang.org Mon Mar 20 23:20:33 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 20 Mar 2006 23:20:33 -0700 (MST) Subject: [Rxtx] binaries request In-Reply-To: References: <42702213-C222-4937-A585-7CFB17E47608@mac.com> Message-ID: On Tue, 21 Mar 2006, Dmitry Markman wrote: > thank you very much > > but windows's readme says: > rxtxSerial.dll had to be recomopiled to link in missing native methods. > > should I ignore it? or what? > Hi Dmitry That dll should be OK. r2 is the recompile linked to the missing native method. The readme explains why it was recompiled; fuser.o was not linked into the dll in the first release. -- Trent Jarvi tjarvi at qbang.org From ariantristan at yahoo.com Mon Mar 20 23:55:24 2006 From: ariantristan at yahoo.com (Lambok Sianturi) Date: Mon, 20 Mar 2006 22:55:24 -0800 (PST) Subject: [Rxtx] jvm issue Message-ID: <20060321065524.94779.qmail@web50701.mail.yahoo.com> Hi All, This is my first time to join RxTx mailing list. I thank you all for allowing others to sign in in requests help. I use the latest RxTx lib in Fedora 3 with java version 1.4.2_09 b05. And I got this error: # # An unexpected error has been detected by HotSpot Virtual Machine: # # SIGSEGV (0xb) at pc=0x00bf27f3, pid=2633, tid=3086112448 # # Java VM: Java HotSpot(TM) Client VM (1.4.2_09-b05 mixed mode) # Problematic frame: # C [ld-linux.so.2+0xa7f3] # # An error report file with more information is saved as hs_err_pid2633.log # # If you would like to submit a bug report, please visit: # http://java.sun.com/webapps/bugreport/crash.jsp # ./run.sh: line 3: 2633 Aborted /usr/local/java/bin/java -Djava.library.path=/usr/local/java/jre/lib/ -Djsmsengine.debug=true -classpath jsmsengine.jar:smsgateway.jar:classes12.jar:RXTXcomm.jar:. com.api.sms.SMSServer What is the jvm depedency for the latest library? Can I use 1.4.2_09 b05? Thanks in advance. Arian --------------------------------- Yahoo! Mail Use Photomail to share photos without annoying attachments. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060320/83d58dd7/attachment-0020.html From f.frumento at ngi.it Tue Mar 21 00:21:47 2006 From: f.frumento at ngi.it (Fabio Frumento) Date: Tue, 21 Mar 2006 08:21:47 +0100 Subject: [Rxtx] Javadoc on the go Message-ID: <441FA98B.9050701@ngi.it> Hi Trent, sorry for the big delay but my job is running wild, i was out for some time but now i'm back and ready to continue the javadoc for Rxtx. Did you used the last javadoc patch i sent you ? let me know if i have to send it to you again or not. regards Fabio From lyon at docjava.com Tue Mar 21 00:51:18 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Tue, 21 Mar 2006 02:51:18 -0500 Subject: [Rxtx] lock files Message-ID: Hi All, You know, if the use of lock files were under Java control (rather than a build-time decision), it might enable a more unified binary distro. It might also facilitate quick prototyping of non-lock file approaches to resolving serial port contention issues (i.e., mac-like approaches vs. linux approaches, etc.). I realize that this is a radical overhaul of the lock file policy issue. Also, it may harm performance. On the other hand, our benchmarks on JNI overhead for modern processors indicate performance impact should be minimal. Perhaps it is more of an issue with the toybox systems. Suppose there were a class with a reasonable default...someone might write: SerialPortLockPolicy.setPolicy(SerialPortLockPolicy.UNIX_LOCK_FILE); SerialPortLockPolicy.setPolicy(SerialPortLockPolicy.NO_LOCK_CHECKING); SerialPortLockPolicy.setPolicy(SerialPortLockPolicy.MAC_STYLE); Thus, we could have a run-time reconfiguration of the serial port lock policy. A special NO_LOCK version of the binary would no longer be required. Any thoughts on this? Thanks! - Doug From joachim at buechse.de Tue Mar 21 03:09:09 2006 From: joachim at buechse.de (Joachim Buechse) Date: Tue, 21 Mar 2006 11:09:09 +0100 Subject: [Rxtx] lock files In-Reply-To: References: Message-ID: <8E12916A-1B9A-4FF2-B684-E2D1C794221B@buechse.de> This is pretty much what I thought about when I suggested, that the default behaviour could be overwritten with a property. I am very much in favor of this approach. In particular this allows much easier debugging for PC based java developers. I think big parts of the Java (and maybe some parts of the C code) could use a bit of a structural workover (unit tests, javadoc, synchronization, etc). Maybe there should be a CVS branch for this experimental version. I'd be happy to contribute a first workover for some of the Java code. Designing for testability and implementing a good bunch of unit tests has been a strategy that worked quite well in the Java projects I lead. And it ultimately allows more liberal change permission. Regards, Joachim On 21.03.2006, at 08:51, Dr. Douglas Lyon wrote: > Hi All, > You know, if the use of lock files were > under Java control (rather than a build-time decision), > it might enable a more unified binary distro. It might also > facilitate quick prototyping of non-lock file approaches > to resolving serial port contention issues (i.e., mac-like > approaches vs. linux approaches, etc.). > > I realize that this is a radical overhaul of the lock file policy > issue. Also, it may harm performance. On the other hand, > our benchmarks on JNI overhead for modern processors indicate > performance impact should be minimal. Perhaps it is more of > an issue with the toybox systems. > > Suppose there were a class with a reasonable default...someone > might write: > SerialPortLockPolicy.setPolicy(SerialPortLockPolicy.UNIX_LOCK_FILE); > SerialPortLockPolicy.setPolicy(SerialPortLockPolicy.NO_LOCK_CHECKING); > SerialPortLockPolicy.setPolicy(SerialPortLockPolicy.MAC_STYLE); > > Thus, we could have a run-time reconfiguration of the serial port lock > policy. A special NO_LOCK version of the binary would no longer > be required. > > Any thoughts on this? > > Thanks! > - Doug > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From joachim at buechse.de Tue Mar 21 06:23:08 2006 From: joachim at buechse.de (Joachim Buechse) Date: Tue, 21 Mar 2006 14:23:08 +0100 Subject: [Rxtx] PATCH: use of ioctl(fd, TIOCEXCL) instead of lockfiles Message-ID: <923AE774-EEA2-4911-92D8-32BB27802C8B@buechse.de> Here is the patch for the ioctl(fd, TIOCEXCL). I have verified this only for OSX 10.4.5, hence it is only defined for APPLE. However, it should work at least for Solaris as well. If a process has requested TIOEXCL further open calls by other user processes will fail. The patch also disables uucp style locking for APPLE. Obviously this is discussable. I think it is the way to go, as it eliminates creating the lock directory which doesnt exist on the standard installation and it eliminates messing with the system group definitions (adding users to group uucp). Regarding the possibility of root processes opening a device which is locked - I consider this a feature not a potential problem. It is highly unlikely, that somebody is crazy enough to run a JavaVM as root (unless he has no other means of getting a restricted IP port opened, ie doesnt understand ipfw). Anyway, even if the process runs as root, it fails when calling ioctl(fd, TIOCEXCL). It could however still open the port to listen for RING events. I.e. a fax server which needs to see incoming calls but otherwise doesnt want to block the port. So the only case where the proposed mechanism fails is, if an incorrectly implemented process running as root conflicts with a user process. I think this can be accepted. Regards, Joachim PS: If this patch is generally accepted, the installer and Mac doku should obviously be changed as well. Index: SerialImp.c =================================================================== RCS file: /usr/local/cvsroot/rxtx-devel/src/SerialImp.c,v retrieving revision 1.46.2.187 diff -u -r1.46.2.187 SerialImp.c --- SerialImp.c 29 Jan 2006 22:19:04 -0000 1.46.2.187 +++ SerialImp.c 21 Mar 2006 12:59:16 -0000 @@ -656,6 +656,25 @@ fd=OPEN (filename, O_RDWR | O_NOCTTY | O_NONBLOCK ); } while (fd < 0 && errno==EINTR); +#ifdef OPEN_EXCL + // Note that open() follows POSIX semantics: multiple open() calls to + // the same file will succeed unless the TIOCEXCL ioctl is issued. + // This will prevent additional opens except by root-owned processes. + // See tty(4) ("man 4 tty") and ioctl(2) ("man 2 ioctl") for details. + + if (fd >= 0 && (ioctl(fd, TIOCEXCL) == -1)) + { + sprintf( message, "open: exclusive access denied for % s\n", + filename ); + report( message ); + report_error( message ); + + close(fd); + goto fail; + } +#endif /* OPEN_EXCL */ + + if( configure_port( fd ) ) goto fail; (*env)->ReleaseStringUTFChars( env, jstr, filename ); sprintf( message, "open: fd returned is %i\n", fd ); Index: SerialImp.h =================================================================== RCS file: /usr/local/cvsroot/rxtx-devel/src/SerialImp.h,v retrieving revision 1.11.2.49 diff -u -r1.11.2.49 SerialImp.h --- SerialImp.h 5 Jul 2005 17:47:21 -0000 1.11.2.49 +++ SerialImp.h 21 Mar 2006 12:59:17 -0000 @@ -135,7 +135,8 @@ /*# define LOCKDIR "/var/spool/uucp"*/ # define LOCKDIR "/var/lock" # define LOCKFILEPREFIX "LK." -# define UUCP +/*# define UUCP*/ +# define OPEN_EXCL #endif /* __APPLE__ */ #if defined(__NetBSD__) # define DEVICEDIR "/dev/" From tjarvi at qbang.org Tue Mar 21 10:26:08 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 21 Mar 2006 10:26:08 -0700 (MST) Subject: [Rxtx] Javadoc on the go In-Reply-To: <441FA98B.9050701@ngi.it> References: <441FA98B.9050701@ngi.it> Message-ID: On Tue, 21 Mar 2006, Fabio Frumento wrote: > Hi Trent, > > sorry for the big delay but my job is running wild, i was out for some > time but now i'm back and ready to continue the javadoc for Rxtx. > > Did you used the last javadoc patch i sent you ? let me know if i have to > send it to you again or not. > > regards > > Fabio Hi Fabio The patch is in the rxtx mail-list archives. It will be going in soon. I did not see a time critical portion. I'll probably be going through the list since the last batch of patches this weekend and putting them into CVS. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Tue Mar 21 10:57:18 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 21 Mar 2006 10:57:18 -0700 (MST) Subject: [Rxtx] jvm issue In-Reply-To: <20060321065524.94779.qmail@web50701.mail.yahoo.com> References: <20060321065524.94779.qmail@web50701.mail.yahoo.com> Message-ID: On Mon, 20 Mar 2006, Lambok Sianturi wrote: > Hi All, > This is my first time to join RxTx mailing list. I thank you all for allowing others to sign in in requests help. > I use the latest RxTx lib in Fedora 3 with java version 1.4.2_09 b05. And I got this error: > > # > # An unexpected error has been detected by HotSpot Virtual Machine: > # > # SIGSEGV (0xb) at pc=0x00bf27f3, pid=2633, tid=3086112448 > # > # Java VM: Java HotSpot(TM) Client VM (1.4.2_09-b05 mixed mode) > # Problematic frame: > # C [ld-linux.so.2+0xa7f3] A native library loading error? What happens if you recompile rxtx on your system and install that? This sounds like an ABI problem? rxtx 2.1-7 was compiled with a gcc 2.96 toolchain as I recall. The hope is newer system will be backwards compatible. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Tue Mar 21 11:05:29 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 21 Mar 2006 11:05:29 -0700 (MST) Subject: [Rxtx] PATCH: use of ioctl(fd, TIOCEXCL) instead of lockfiles In-Reply-To: <923AE774-EEA2-4911-92D8-32BB27802C8B@buechse.de> References: <923AE774-EEA2-4911-92D8-32BB27802C8B@buechse.de> Message-ID: On Tue, 21 Mar 2006, Joachim Buechse wrote: > Here is the patch for the ioctl(fd, TIOCEXCL). I have verified this only > for OSX 10.4.5, hence it is only defined for APPLE. However, it should > work at least for Solaris as well. > > If a process has requested TIOEXCL further open calls by other user > processes will fail. > > The patch also disables uucp style locking for APPLE. Obviously this is > discussable. I think it is the way to go, as it eliminates creating the > lock directory which doesnt exist on the standard installation and it > eliminates messing with the system group definitions (adding users to > group uucp). > > Regarding the possibility of root processes opening a device which is > locked - I consider this a feature not a potential problem. It is highly > unlikely, that somebody is crazy enough to run a JavaVM as root (unless > he has no other means of getting a restricted IP port opened, ie doesnt > understand ipfw). Anyway, even if the process runs as root, it fails when > calling ioctl(fd, TIOCEXCL). It could however still open the port to > listen for RING events. I.e. a fax server which needs to see incoming > calls but otherwise doesnt want to block the port. So the only case where > the proposed mechanism fails is, if an incorrectly implemented process > running as root conflicts with a user process. I think this can be > accepted. > > Regards, > Joachim > > PS: If this patch is generally accepted, the installer and Mac doku > should obviously be changed as well. > > > Index: SerialImp.c > =================================================================== > RCS file: /usr/local/cvsroot/rxtx-devel/src/SerialImp.c,v > retrieving revision 1.46.2.187 > diff -u -r1.46.2.187 SerialImp.c > --- SerialImp.c 29 Jan 2006 22:19:04 -0000 1.46.2.187 > +++ SerialImp.c 21 Mar 2006 12:59:16 -0000 > @@ -656,6 +656,25 @@ > fd=OPEN (filename, O_RDWR | O_NOCTTY | O_NONBLOCK ); > } while (fd < 0 && errno==EINTR); > > +#ifdef OPEN_EXCL > + // Note that open() follows POSIX semantics: multiple open() > calls to > + // the same file will succeed unless the TIOCEXCL ioctl is > issued. > + // This will prevent additional opens except by root-owned > processes. > + // See tty(4) ("man 4 tty") and ioctl(2) ("man 2 ioctl") for > details. > + > + if (fd >= 0 && (ioctl(fd, TIOCEXCL) == -1)) > + { > + sprintf( message, "open: exclusive access denied for % > s\n", > + filename ); > + report( message ); > + report_error( message ); > + > + close(fd); > + goto fail; > + } > +#endif /* OPEN_EXCL */ > + > + > if( configure_port( fd ) ) goto fail; > (*env)->ReleaseStringUTFChars( env, jstr, filename ); > sprintf( message, "open: fd returned is %i\n", fd ); > Index: SerialImp.h > =================================================================== > RCS file: /usr/local/cvsroot/rxtx-devel/src/SerialImp.h,v > retrieving revision 1.11.2.49 > diff -u -r1.11.2.49 SerialImp.h > --- SerialImp.h 5 Jul 2005 17:47:21 -0000 1.11.2.49 > +++ SerialImp.h 21 Mar 2006 12:59:17 -0000 > @@ -135,7 +135,8 @@ > /*# define LOCKDIR "/var/spool/uucp"*/ > # define LOCKDIR "/var/lock" > # define LOCKFILEPREFIX "LK." > -# define UUCP > +/*# define UUCP*/ > +# define OPEN_EXCL > #endif /* __APPLE__ */ > #if defined(__NetBSD__) > # define DEVICEDIR "/dev/" > This looks like a good start. What do you think Dmitry? Perhaps all systems with TIOCEXCL defined should use that though. Even if they use lockfiles. It wont hurt anything. That would catch people hacking their own serial apps without checking lockfiles. Its a good idea to avoid C++ style comments in the C portions. Some older systems don't deal with them well. If it's just for Mac OS X, it isn't a big deal. I think it was the Irix compiler that was problematic? -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Tue Mar 21 11:22:05 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 21 Mar 2006 11:22:05 -0700 (MST) Subject: [Rxtx] lock files In-Reply-To: <8E12916A-1B9A-4FF2-B684-E2D1C794221B@buechse.de> References: <8E12916A-1B9A-4FF2-B684-E2D1C794221B@buechse.de> Message-ID: We can try it. Maybe the JNI is much improved. The nice thing about linking into liblock is distros then worry about lockfiles on their systems. This way, we have to deal with any changes that may show up. On Tue, 21 Mar 2006, Joachim Buechse wrote: > This is pretty much what I thought about when I suggested, that the > default behaviour could be overwritten with a property. I am very much in > favor of this approach. In particular this allows much easier debugging > for PC based java developers. > > I think big parts of the Java (and maybe some parts of the C code) could > use a bit of a structural workover (unit tests, javadoc, synchronization, > etc). Maybe there should be a CVS branch for this experimental version. > I'd be happy to contribute a first workover for some of the Java code. > Designing for testability and implementing a good bunch of unit tests has > been a strategy that worked quite well in the Java projects I lead. And > it ultimately allows more liberal change permission. > > Regards, > Joachim > > > On 21.03.2006, at 08:51, Dr. Douglas Lyon wrote: > >> Hi All, >> You know, if the use of lock files were >> under Java control (rather than a build-time decision), >> it might enable a more unified binary distro. It might also >> facilitate quick prototyping of non-lock file approaches >> to resolving serial port contention issues (i.e., mac-like >> approaches vs. linux approaches, etc.). >> >> I realize that this is a radical overhaul of the lock file policy >> issue. Also, it may harm performance. On the other hand, >> our benchmarks on JNI overhead for modern processors indicate >> performance impact should be minimal. Perhaps it is more of >> an issue with the toybox systems. >> >> Suppose there were a class with a reasonable default...someone >> might write: >> SerialPortLockPolicy.setPolicy(SerialPortLockPolicy.UNIX_LOCK_FILE); >> SerialPortLockPolicy.setPolicy(SerialPortLockPolicy.NO_LOCK_CHECKING); >> SerialPortLockPolicy.setPolicy(SerialPortLockPolicy.MAC_STYLE); >> >> Thus, we could have a run-time reconfiguration of the serial port lock >> policy. A special NO_LOCK version of the binary would no longer >> be required. >> >> Any thoughts on this? >> >> Thanks! >> - Doug >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From dmarkman at mac.com Tue Mar 21 16:05:17 2006 From: dmarkman at mac.com (Dmitry Markman) Date: Tue, 21 Mar 2006 18:05:17 -0500 Subject: [Rxtx] PATCH: use of ioctl(fd, TIOCEXCL) instead of lockfiles In-Reply-To: References: <923AE774-EEA2-4911-92D8-32BB27802C8B@buechse.de> Message-ID: <512AC70C-BB86-48F2-A83C-023F35C23BAB@mac.com> I think it's cool, but I'd like to have that property implementation when user can choose between locking mechanism about comments: it's easy to change comments to the C style or we can use extensions of the file to cpp so c++ compiler will be used On Mar 21, 2006, at 1:05 PM, Trent Jarvi wrote: > This looks like a good start. What do you think Dmitry? Perhaps > all systems with TIOCEXCL defined should use that though. Even if > they use lockfiles. It wont hurt anything. That would catch > people hacking their own serial apps without checking lockfiles. > > Its a good idea to avoid C++ style comments in the C portions. > Some older systems don't deal with them well. If it's just for Mac > OS X, it isn't a big deal. I think it was the Irix compiler that > was problematic? Dmitry Markman From dmarkman at mac.com Tue Mar 21 16:13:00 2006 From: dmarkman at mac.com (Dmitry Markman) Date: Tue, 21 Mar 2006 18:13:00 -0500 Subject: [Rxtx] PATCH: use of ioctl(fd, TIOCEXCL) instead of lockfiles In-Reply-To: References: <923AE774-EEA2-4911-92D8-32BB27802C8B@buechse.de> Message-ID: I'd like to add that creating locking folder isn't a big deal we never had a problem related to the lock folders, because we always used installer on mac os x from other hand I'm not very much familiar with iotcl locking approach and I'm not sure it's more efficient Joachim wrote "I think it is the way to go, as it eliminates creating the lock directory which doesnt exist on the standard installation and it eliminates messing with the system group definitions (adding users to group uucp)." but I really didn't have any problem with that 1. doesn't exist on the standard installation there are many-many things that don't exist in the standard installation so I don't think that argument is strong enough 2. messing with the system group definitions I don't think we're messing with the group definition mac os x provides very clear way to set up group's members and together with Greg Guerin AuthKit there is no problem to set those definitions so I don't think that argument is strong either but from other hand using iotcl is more promising and is more elegant On Mar 21, 2006, at 1:05 PM, Trent Jarvi wrote: > > This looks like a good start. What do you think Dmitry? Perhaps > all systems with TIOCEXCL defined should use that though. Even if > they use lockfiles. It wont hurt anything. That would catch > people hacking their own serial apps without checking lockfiles. Dmitry Markman From joachim at buechse.de Wed Mar 22 04:46:45 2006 From: joachim at buechse.de (Joachim Buechse) Date: Wed, 22 Mar 2006 12:46:45 +0100 Subject: [Rxtx] PATCH: use of ioctl(fd, TIOCEXCL) instead of lockfiles In-Reply-To: References: <923AE774-EEA2-4911-92D8-32BB27802C8B@buechse.de> Message-ID: Sorry, I was not very clear with my arguments, so I will try again;-) Please, don't take this as an attack against work that has been done. I think the contributions that have been made in the past were made in a good spirit. But I really believe, that the current solution for OSX has many shortcomings and should be changed as soon as possible. lock files --- The /var/lock folder does not exist on the standard OSX installation, however the standard installation includes several applications that use serial ports (i.e. the FAX capability). This indicates, that the lock folder approach will not work well with system components. Applications for OSX will generally try to live in harmony with system components (except for HP print drivers of course). I think RXTX should follow this approach as well. uucp group --- Accessing serial ports is not an admin privileged operation on OSX. Any user (world) has read/write privileges on /dev/tty*. So the system default is to not enforce any group membership to access these ports. The group uucp however is a system group on all unix systems I know. It exists for certain system processes. A non admin user should in general not be a member of this group. Quite arguably no user should ever be a member of this group. Installer --- My general opinion is, that - no Installer should touch user or group data without warning - no Application Installer should touch groups which are not specific to the very application installed - no Installer should ever add regular users to a system group The current installer injects the installing user in the group uucp without warning about this change and without giving the option to "opt out" of this change. This is a potential security risk (but not currently a real one, as OSX contains no folders belonging to group uucp). The current installer does not work for multi user systems. It puts the installing user in the uucp group. However the installing user is not necessarily the user that will use the application. Putting all users that may use a serial port application in the system group uucp seems like a very invasive approach to me. Besides that, newly created users will not automatically be in the group and hence, serial applications will "break" for new users without obvious reasons. Avoiding the lock files will allow self contained applications (i.e. drag&drop installation). In my eyes this is largely preferable over an installer that requests admin privileges. Adding up all these points indicates very strongly, that the lock-file implementation is not the way to go on OSX. Regards, Joachim On 22.03.2006, at 00:13, Dmitry Markman wrote: > I'd like to add that > > creating locking folder isn't a big deal > we never had a problem related to the lock folders, because we > always used installer on mac os x > from other hand I'm not very much familiar with iotcl locking > approach and I'm not sure it's more efficient > > Joachim wrote "I think it is the way to go, as it eliminates > creating the lock directory which doesnt exist on the standard > installation and it eliminates messing with the system group > definitions (adding users to group uucp)." but I really didn't have > any problem with that > > 1. doesn't exist on the standard installation > there are many-many things that don't exist in the standard > installation so I don't think that argument is strong enough > 2. messing with the system group definitions > I don't think we're messing with the group definition > mac os x provides very clear way to set up group's members and > together with Greg Guerin AuthKit there is no problem to set those > definitions > so I don't think that argument is strong either > but from other hand using iotcl is more promising and is more elegant > > > > On Mar 21, 2006, at 1:05 PM, Trent Jarvi wrote: > >> >> This looks like a good start. What do you think Dmitry? Perhaps >> all systems with TIOCEXCL defined should use that though. Even if >> they use lockfiles. It wont hurt anything. That would catch >> people hacking their own serial apps without checking lockfiles. > > Dmitry Markman > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From dmarkman at mac.com Wed Mar 22 05:27:13 2006 From: dmarkman at mac.com (Dmitry Markman) Date: Wed, 22 Mar 2006 07:27:13 -0500 Subject: [Rxtx] PATCH: use of ioctl(fd, TIOCEXCL) instead of lockfiles In-Reply-To: References: <923AE774-EEA2-4911-92D8-32BB27802C8B@buechse.de> Message-ID: <83440CF3-DCD8-41C1-B941-F227232C27E3@mac.com> thanks for the very good explanation I didn't think that you were attacking any thing, so don't worry I just had feeling, that there were more aesthetic reasons for going to ioctl then real necessity now you explained everything quite well (BTW, asfar as I remember installer asks admin password so it wasn't quiet, but it really doesn't matter now) thanks On Mar 22, 2006, at 6:46 AM, Joachim Buechse wrote: > Sorry, I was not very clear with my arguments, so I will try again;-) > > Please, don't take this as an attack against work that has been > done. I think the contributions that have been made in the past > were made in a good spirit. But I really believe, that the current > solution for OSX has many shortcomings and should be changed as > soon as possible. > > lock files > --- > The /var/lock folder does not exist on the standard OSX > installation, however the standard installation includes several > applications that use serial ports (i.e. the FAX capability). This > indicates, that the lock folder approach will not work well with > system components. Applications for OSX will generally try to live > in harmony with system components (except for HP print drivers of > course). I think RXTX should follow this approach as well. > > uucp group > --- > Accessing serial ports is not an admin privileged operation on OSX. > Any user (world) has read/write privileges on /dev/tty*. So the > system default is to not enforce any group membership to access > these ports. The group uucp however is a system group on all unix > systems I know. It exists for certain system processes. A non admin > user should in general not be a member of this group. Quite > arguably no user should ever be a member of this group. > > Installer > --- > My general opinion is, that > - no Installer should touch user or group data without warning > - no Application Installer should touch groups which are not > specific to the very application installed > - no Installer should ever add regular users to a system group > > The current installer injects the installing user in the group uucp > without warning about this change and without giving the option to > "opt out" of this change. This is a potential security risk (but > not currently a real one, as OSX contains no folders belonging to > group uucp). > > The current installer does not work for multi user systems. It puts > the installing user in the uucp group. However the installing user > is not necessarily the user that will use the application. Putting > all users that may use a serial port application in the system > group uucp seems like a very invasive approach to me. Besides that, > newly created users will not automatically be in the group and > hence, serial applications will "break" for new users without > obvious reasons. > > > Avoiding the lock files will allow self contained applications > (i.e. drag&drop installation). In my eyes this is largely > preferable over an installer that requests admin privileges. Adding > up all these points indicates very strongly, that the lock-file > implementation is not the way to go on OSX. > > Regards, > Joachim > > > On 22.03.2006, at 00:13, Dmitry Markman wrote: > >> I'd like to add that >> >> creating locking folder isn't a big deal >> we never had a problem related to the lock folders, because we >> always used installer on mac os x >> from other hand I'm not very much familiar with iotcl locking >> approach and I'm not sure it's more efficient >> >> Joachim wrote "I think it is the way to go, as it eliminates >> creating the lock directory which doesnt exist on the standard >> installation and it eliminates messing with the system group >> definitions (adding users to group uucp)." but I really didn't >> have any problem with that >> >> 1. doesn't exist on the standard installation >> there are many-many things that don't exist in the standard >> installation so I don't think that argument is strong enough >> 2. messing with the system group definitions >> I don't think we're messing with the group definition >> mac os x provides very clear way to set up group's members and >> together with Greg Guerin AuthKit there is no problem to set those >> definitions >> so I don't think that argument is strong either >> but from other hand using iotcl is more promising and is more elegant >> >> >> >> On Mar 21, 2006, at 1:05 PM, Trent Jarvi wrote: >> >>> >>> This looks like a good start. What do you think Dmitry? Perhaps >>> all systems with TIOCEXCL defined should use that though. Even >>> if they use lockfiles. It wont hurt anything. That would catch >>> people hacking their own serial apps without checking lockfiles. >> >> Dmitry Markman >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx Dmitry Markman From lyon at docjava.com Wed Mar 22 06:12:18 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Wed, 22 Mar 2006 08:12:18 -0500 Subject: [Rxtx] sole of a new design pattern Message-ID: Hi All, I have been thinking about how we design the serial port software. I think we need a new design pattern. For lack of a better term, I shall call it: The Parametric Singleton Design Pattern By Douglas A. Lyon ABSTRACT The goal of the singleton design pattern is to make sure that there is one, and only one, instance of a given class. The goal of the parametric singleton design pattern is to make sure that there is one, and only one, instance of a given class with the given parametric values. We parametric singleton design pattern combines the singleton design pattern with a parameter that enables unique creation of instances of a class. These instances are cached. When a user asks for an instance with these parameters, the cache is checked. If the instance is in the cache, the instance is returned, otherwise it is created, added to the cache and then returned. We apply our parametric singleton design pattern to the retrieval of RMI registries bound to a given port. The goal of our system is to make sure that no two RMI registries are listening to the same socket and to make use of the RMI registries after they have been created. RMI registries are used in distributed computation. Introduction The singleton design pattern is meant to ensure that on a single instance of a class exists. It is also meant to provide a global point of access to it. The intent of the parametric singleton design pattern is to ensure that a class has only one instance for a given set of parameter values. It also provides a global point of access to it. Motivation A system cannot tolerate multiple instances of some classes with identical parameters. For example, you cannot have two instances making use of the same serial port, at the same time. You cannot have two instances that are trying to listen to the same socket connection. You cannot have two instances writing to the same file structure at the same time. As the operating system is often thought of as the arbiter of consumed resources (i.e., tape drives, serial ports, etc.) we frequently leave it to an operating system implementation to resolve these contention issues. Even for similar resources (like serial ports) there are few standards for handling contention. For example, serial ports on Linux are locked using a "/var/lock" file. POSIX, on the other hand, uses ioctl mechanisms to prevent contention. A better solution is to make a class that is responsible for keeping track of the instances created from the class. The class is declared final, so that it cannot be subclassed. The class also has a private constructor, so that other classes cannot instance it. The new design pattern is called the parametric singleton design pattern and it provides a way to access and create instances with given parameters. Applicability Use the Parametric Singleton Design Pattern when: 1. There must be exactly one instance of a class with the given parameters. 2. The instances must be accessible to clients from a well-known access point. Structure Insert UML diagram here. Participants The Parametric Singleton Clients that need instances 1. The Parametric Singleton defines an instance upon request from a client, if, and only if, the instance does not already exist. 2. The Parametric Singleton returns the instance to the client. 3. The Parametric Singleton is responsible for creating unique instances from given parameters. Collaborations Clients obtain a reference to a Parametric Singleton instance only through the parametric singleton design pattern. If the instance is left in an improper state (e.g., the serial port was left open) it is NOT the role of the Parametric Singleton Design Pattern to close the IO port. Nor is it the role of the Parametric Singleton Design Pattern to open the port. That role is delegate to some other part of the system. Further, it is not the role of the Parametric Singleton Design Pattern to check out resources. That is, multiple threads can have multiple references to the same resource at the same time. MUTEX locking is delegated to some other part of the system. Consequences The Parametric Singleton Design Pattern has several benefits: 1. Controlled access to parametrically defined instances. Since the Parametric Singleton class encapsulates its instances, there is control over how and when clients access it. 2. Reduced name space. The Parametric Singleton pattern avoids global variables that store instances created from the same parameter. Implementation Here are implementation issues to consider when using the Parametric Singleton pattern: 1. Unique mapping of parameters. The Parametric Singleton pattern requires that there be a mean to isomorphically map the parameter space into the instance space and back again. 2. Ensure unique instances. The Parametric Singleton pattern makes unique instances from parameters, and it does so only once. 3. Cache instances for fast retrieval. The Parametric Singleton pattern must be able to look up instances, given some set of parameters, and do so from some data structure. That is, there must be enough space to hold references to all the instances the program will need. Also, a mechanism is needed to look up and retrieve the instances quickly enough to satisfy the clients. Sample Code public final class ParametricSingletonRmiRegistry { private static Hashtable registry = new Hashtable(100); // use singleton pattern and??????????????????????????????????????????????? // prevent instantiation of RmiRegistryUtils.?????????????????????????????? private ParametricSingletonRmiRegistry() { } // the only instance of the Registry held by the RmiRegistryUtils?????????? public static void listNames(Integer port) { if (!isInCacheAndRunning(port)) return; Registry r = (Registry) registry.get(port); System.out.println("registry on port: " + port); System.out.println("registry: " + r); System.out.println("names: "); try { print(r.list()); } catch (RemoteException e) { In.message(e); } System.out.println("------------------------"); } /**???????????????????????????????????????????????????????????????????????? * Checks whether a Registry has been started on this host????????????????? * in the specified port.?????????????????????????????????????????????????? * If not, it tries to start one.?????????????????????????????????????????? * when it fails to start a Registry, it exits the program????????????????? * with exit code 1.??????????????????????????????????????????????????????? */ public static void restart(int port) { if (isInCacheAndRunning(port)) return; try { startRegistry(port); } catch (RemoteException e) { In.message(e); } } /**???????????????????????????????????????????????????????????????????????? * @param port????????????????????????????????????????????????????????????? * @return true if registry is in cache and running???????????????????????? */ private static boolean isInCacheAndRunning(Integer port) { if (!isRegistryRunning(port.intValue())) return false; if (!isRegistryInCache(port.intValue())) return false; return true; } /**???????????????????????????????????????????????????????????????????????? * @param port????????????????????????????????????????????????????????????? * @return true if we are able to locate a local registry on port.??????????????????????????????????????????????????????????????????????????? */ private static boolean isRegistryRunning(int port) { try { Registry r = LocateRegistry.getRegistry(port); if (r != null) return true; } catch (RemoteException e) { return false; } return false; } /**???????????????????????????????????????????????????????????????????????? * @param port????????????????????????????????????????????????????????????? * @return return true if registry is in cache????????????????????????????? */ private static boolean isRegistryInCache(int port) { if (registry.get(new Integer(port)) == null) return false; return true; } /**???????????????????????????????????????????????????????????????????????? * Restart the registry, if needed.???????????????????????????????????????? * Return the only instance of the registry for consistent global?????????? * using by making use of the Singleton Design Pattern????????????????????? *????????????????????????????????????????????????????????????????????????? * @return the internally held registry instance.?????????????????????????? */ public static Registry getRegistry(Integer port) { restart(port); return (Registry) registry.get(port); } private static void startRegistry(Integer port) throws RemoteException { Registry r; try { r = LocateRegistry.createRegistry(port.intValue()); registry.put(port, r); //r = new sun.rmi.registry.RegistryImpl???????????????????????????? /// (port.intValue());?????????????????????????????????????? // registry.put(port, r);?????????????????????????????????????????? } catch (Exception e) { //e.printStackTrace();????????????????????????????????????????????? r = LocateRegistry.getRegistry(port.intValue()); registry.put(port, r); } } public static void main(String args[]) throws RemoteException { //restart(port);??????????????????????????????????????????????????????? restart(5001); restart(5002); restart(5002); Registry r = LocateRegistry.getRegistry(5002); System.out.println("registry="+r); } } I would very much like to get your feedback on this new design pattern idea. Thank you for your time. Regards, - Doug From david.garnier at trusted-logic.com Wed Mar 22 07:36:10 2006 From: david.garnier at trusted-logic.com (David Garnier) Date: Wed, 22 Mar 2006 15:36:10 +0100 Subject: [Rxtx] sole of a new design pattern In-Reply-To: References: Message-ID: <442160DA.80107@trusted-logic.com> Hello, > The Parametric Singleton Design Pattern The Singleton is the most abused design pattern ever. Good use-cases for this pattern are extremely rare and mostly confined to problems related to hardware resources, like serial ports. > Applicability > > Use the Parametric Singleton Design Pattern when: > 1. There must be exactly one instance of a class with the given > parameters. OK. As I said above, this case this actually very unusual. The Singleton pattern is mostly used when : > 2. The instances must be accessible to clients from a well-known > access point. Using the singleton pattern in this case is just convenient for the programmer. Problems arises pretty quickly, especially if you attempt to unit-test your classes. 1) If your singleton is stateful, or hold on to stateful objects, it means that two different unit tests are not actually independent. Instead of starting with a brand new environment, the result of a test may be affected by the result of a previous test. This problem also arise when with your class relies on a database. In both cases, the solution is to reset your "unique" resource (Singleton or database) at the beginning of the test, which is a pain. Also, while most projects connect to a single database, projects that allow the use of Singletons usually contain several of thems, and new ones may cropped up unnoticed. You quickly end up with test cases that only pass in a certain order, which is a royal pain. 2) You cannot mockup a singleton. Once everyone calls the SomeSingleton class statically, you can't replace your class by SomeSingletonMockup. Furthermore, even for hardware services, the Singleton pattern does not really prevent concurrent accesses. If you start the same program in two different JVMs, unless they somehow shared the state of their "Singletons" (through lock files for example), the Singleton pattern will not prevent concurrent access. Our application uses RXTX, and we routinely encounter cases where another (native) application has already locked the port. Since we cannot modify the native application to recognize lock files, OS-level control is irreplaceable. > > Consequences > The Parametric Singleton Design Pattern has several benefits: > > 1. Controlled access to parametrically defined instances. Since > the Parametric Singleton class encapsulates its instances, there is > control over how and when clients access it. Not really. Once you've returned the instance to a client, you've lost control over it. The client can to whatever it wants with it. You cannot "recall" the instance or claim it back. > 2. Reduced name space. The Parametric Singleton pattern avoids > global variables that store instances created from the same parameter. Sure, but you don't have to rely on a Singleton for that. Just create a single Factory. > I would very much like to get your feedback on this new design > pattern idea. Well, it's nothing new. Some may say that it is the point of design patterns: formalizes the designs that occur again and again. However, this design is simply a combination of the Singleton and Factory patterns. I did use it in the past, but now I've been exposed to the shortcomings of the Singleton pattern, so I limit myself to Factories. Regards, David From sean_montgomery at baseview.com Wed Mar 22 08:35:28 2006 From: sean_montgomery at baseview.com (Sean Montgomery) Date: Wed, 22 Mar 2006 10:35:28 -0500 Subject: [Rxtx] sole of a new design pattern In-Reply-To: <442160DA.80107@trusted-logic.com> References: <442160DA.80107@trusted-logic.com> Message-ID: <05769CA7-A51B-4CF0-BAA0-E02DD905F5A4@baseview.com> On Mar 22, 2006, at 9:36 AM, David Garnier wrote: > Furthermore, even for hardware services, the Singleton pattern does > not really prevent concurrent > accesses. If you start the same program in two different JVMs, > unless they somehow shared the state > of their "Singletons" (through lock files for example), the > Singleton pattern will not prevent > concurrent access. > Multiple class loaders in a single JVM can be tricky, too. Then there's synchronization, lazy initialization and serialization of singletons to contend with. Bloch's Effective Java covers these, and here's a few articles: http://www.javaworld.com/javaworld/jw-04-2003/jw-0425-designpatterns- p3.html http://java.sun.com/developer/technicalArticles/Programming/singletons/ Just FYI :-) From lyon at docjava.com Wed Mar 22 08:50:48 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Wed, 22 Mar 2006 10:50:48 -0500 Subject: [Rxtx] sole of a new design pattern In-Reply-To: <442160DA.80107@trusted-logic.com> References: <442160DA.80107@trusted-logic.com> Message-ID: Hi All, First, I would like to thank David for his prompt and thoughtful remarks. I had no idea people that feel strongly about a design patterns! Wow! Feedback (particularly critical feedback) is greatly appreciated. Starting at the end, first: >I did use it in >the past, but now I've been exposed to the shortcomings of the >Singleton pattern, so I limit myself to Factories. David, if I understood your comments correctly, you suggested that Factories can be used in leu of the Singleton Design Pattern, or even the Parametric Singleton Design Pattern. As I see in [Gof]: Factory Method: Intent "Define an interface for creating an object, but let subclasses decide which class to instantiate. Factory Method lets a class defer instantiation to subclasses." The Singleton Design Pattern is a concrete class, which is rather different, right? Also, subclasses are not permitted with Singleton, as they are final. Naturally, I could use an abstract factory as a parent for a singleton. I could even design a facade that could be implemented with the singleton....but that is not the intention of the design. Unless you want a mock-up, as discussed, below: More below: >Hello, > >> The Parametric Singleton Design Pattern > >The Singleton is the most abused design pattern ever. Good use-cases >for this pattern are extremely >rare and mostly confined to problems related to hardware resources, >like serial ports. > > >> Applicability >> >> Use the Parametric Singleton Design Pattern when: >> 1. There must be exactly one instance of a class with the given >> parameters. >OK. As I said above, this case this actually very unusual. The >Singleton pattern is mostly used when : >> 2. The instances must be accessible to clients from a well-known >> access point. > >Using the singleton pattern in this case is just convenient for the >programmer. Problems arises >pretty quickly, especially if you attempt to unit-test your classes. > >1) If your singleton is stateful, or hold on to stateful objects, it >means that two different unit >tests are not actually independent. Instead of starting with a brand >new environment, the result of >a test may be affected by the result of a previous test. This >problem also arise when with your >class relies on a database. In both cases, the solution is to reset >your "unique" resource >(Singleton or database) at the beginning of the test, which is a >pain. Also, while most projects >connect to a single database, projects that allow the use of >Singletons usually contain several of >thems, and new ones may cropped up unnoticed. You quickly end up >with test cases that only pass in a >certain order, which is a royal pain. There are basic problems with communicating finite state machines that include reachability and deadlock analysis. These are addressed with petri net analysis and are beyond the scope of the design pattern. As you quite rightly pointed out; the parametric singleton pattern (or the singleton pattern, for that matter) enable multiple threads to gain access to the same instance. The only way that I can see to block others from gaining access to the reference is the synchronize keyword. This is putting a spin-lock (or MUTEX) on the reference. The question of how to unit-test a design pattern like the parametric singleton remains open. Perhaps this is a deficiency. > >2) You cannot mockup a singleton. Once everyone calls the >SomeSingleton class statically, you can't >replace your class by SomeSingletonMockup. Acutally, I am not sure that this is true. If the Singleton implements a Facade interface, it should be possible to make the replacement. Right? > >Furthermore, even for hardware services, the Singleton pattern does >not really prevent concurrent >accesses. If you start the same program in two different JVMs, >unless they somehow shared the state >of their "Singletons" (through lock files for example), the >Singleton pattern will not prevent >concurrent access. Good Point!! You have sharp eyes! The singleton design pattern should/could take responsibility for this. In fact, you may notice that my code does have an implementation (LocateRegistry) that can work across JVM's. The LocateRegistry will even work across the Internet! LocateRegistry takes both a host name and a Port (lock files just don't do this). I did not think to implement this beyond the local machine, but, in its present form, it will work across different processes. > >Our application uses RXTX, and we routinely encounter cases where >another (native) application has >already locked the port. Since we cannot modify the native >application to recognize lock files, >OS-level control is irreplaceable. The singleton design pattern is not meant to replace OS-level control, but to centralize the Java programmers access to it. If lock files, for example, are used for serial ports, the Singleton Design Pattern should be able to work with them. > > >> >> Consequences >> The Parametric Singleton Design Pattern has several benefits: >> > > 1. Controlled access to parametrically defined instances. Since >> the Parametric Singleton class encapsulates its instances, there is >> control over how and when clients access it. > >Not really. Once you've returned the instance to a client, you've >lost control over it. The client >can to whatever it wants with it. You cannot "recall" the instance >or claim it back. Good point, this should read: > 1. Controll when parametrically defined instances are created. Since > > the Parametric Singleton class encapsulates its instances, there is > > control over how and when they are instanced. > >> 2. Reduced name space. The Parametric Singleton pattern avoids >> global variables that store instances created from the same parameter. > >Sure, but you don't have to rely on a Singleton for that. Just >create a single Factory. > > Thank you for your thoughtful and prompt response! Regards, - Doug From dmarkman at mac.com Wed Mar 22 21:21:55 2006 From: dmarkman at mac.com (Dmitry Markman) Date: Wed, 22 Mar 2006 23:21:55 -0500 Subject: [Rxtx] sole of a new design pattern In-Reply-To: <442160DA.80107@trusted-logic.com> References: <442160DA.80107@trusted-logic.com> Message-ID: I don't think I get it On Mar 22, 2006, at 9:36 AM, David Garnier wrote: > Using the singleton pattern in this case is just convenient for the > programmer. Problems arises > pretty quickly, especially if you attempt to unit-test your classes. so you're saying that something isn't so good because you can not test it in the convenient way? if that's true, I'm totally disagree change your test, debug whatever, but if software is efficient at runtime, works fine and only problem is some unit test (which is some kind of framework for testing) then dump that unit test , dump that unit framework and make something appropriate to the software you're testing so if Douglas want to use singletons, what's the problem? and what do you mean by abusing of singleton usage? of course singleton doesn't prevent concurrent access to the resource across the processes unless you're using some OS facility to prevent it, besides singleton as it was introduced is relevant only and only inside of the same process otherwise it's not singleton it's something else (let's say network singleton: so you have remote invocation facility and some factory method that return object created by that facility) I don't have any problem with using any kind of singletons. Parametric Singleton idea (if I understand it right) could be easily implemented in the following way: use a map populate map with instances of some class and key is your parameter (you can use lazy population too) if somebody ask the key check the value if it's null so resource is taken if somebody returns the resource put it back to the map public synchronized static Object getSomeResource(Object parameter); public synchronized static void returnResource(Object parameter); getSomeResource (inside of the same process) could return null in 2 cases 1. if somebody (from other thread for example) already took that resource 2. if OS API said that resource corresponded to that parameter (serial port with parameter = 1 (port #)) is locked and unavailable; I'm not sure that in case of serial ports we even need those Parametric Singletons (unless lock checking is a very expensive operation) just ask the OS about availability of that resource and if it's available give it away and then OS will lock it and therefore in next time somebody ask it just answer that resource is locked and return null for example system has 2 serial ports available so I ask getResource("tty"); or I ask getResource("Bluetooth-Modem"); and if OS is ok you can give tty or Bluetooth-Modem or both no need for any additional pattern I think back to the problem mac os x doesn't recognize locking via files, so it handles locking via some API an instance of the singleton in each process should recognize that resource is locked (by using that API) that's all we don't have to make things more complicate then they are just because there is some nice design pattern or nice unit test framework or whatever keep things simple, make them work fast, don't introduce middle layers unless you have really good reason to do so of course I could be entirely wrong, so sorry about that in advance thanks Dmitry Markman From tjarvi at qbang.org Wed Mar 22 22:31:41 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 22 Mar 2006 22:31:41 -0700 (MST) Subject: [Rxtx] sole of a new design pattern In-Reply-To: References: Message-ID: Hi Doug Interesting reading. So far I'm just reading and thinking. I have one question so far. " Clients obtain a reference to a Parametric Singleton instance only through the parametric singleton design pattern. If the instance is left in an improper state (e.g., the serial port was left open) it is NOT the role of the Parametric Singleton Design Pattern to close the IO port. Nor is it the role of the Parametric Singleton Design Pattern to open the port. That role is delegate to some other part of the system. " So when the clients obtain a reference to the singleton, can they assume the port is there? IE, would it be the singletons role to handle things like USB dongles being removed with event hints comming from the underlying OS. Hardware abstraction layer/HAL on Linux is an example of underlying OS events. I assume that role too is delegated to other parts of the system? -- Trent Jarvi tjarvi at qbang.org From lyon at docjava.com Thu Mar 23 08:10:33 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Thu, 23 Mar 2006 10:10:33 -0500 Subject: [Rxtx] Classes don't need goals, they need roles! In-Reply-To: References: Message-ID: Hi Trent, Yes, I think that the role of the Parametric Singleton Pattern is not to open or close serial ports, nor is it to perform error checking. On the other hand, if you were to combine the role of the Parametric Singleton Pattern with another role (like that of error checking) it might not be amiss. However, I generally caution programmers against adding multiple roles to classes, as this leads to monolithic designs. Thus a different class (NativeLibDetect) could have the role of determining if the native library can be loaded. Another class (SerialPortBean) can have the role of serializing the default state of the serial port, so that it can be recovered, from user preferences, at a later time. The SerialPortDetect could have the role of determining if the serial port is removed (i.e., a USB port was unplugged). My guess is that each class should have a different role in the system, in order to ease maintenance and testing...but I could be wrong about that. Thanks! - Doug >Hi Doug > >Interesting reading. So far I'm just reading and thinking. I have >one question so far. > >" > Clients obtain a reference to a Parametric Singleton instance only >through the parametric singleton design pattern. If the instance is >left in an improper state (e.g., the serial port was left open) it is >NOT the role of the Parametric Singleton Design Pattern to close the >IO port. Nor is it the role of the Parametric Singleton Design Pattern >to >open the port. That role is delegate to some other part of the system. >" > >So when the clients obtain a reference to the singleton, can they >assume the port is there? IE, would it be the singletons role to >handle things like USB dongles being removed with event hints >comming from the underlying OS. Hardware abstraction layer/HAL on >Linux is an example of underlying OS events. > >I assume that role too is delegated to other parts of the system? > >-- >Trent Jarvi >tjarvi at qbang.org >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From maximulo at yahoo.com Fri Mar 24 01:22:38 2006 From: maximulo at yahoo.com (Maximulo Majir) Date: Fri, 24 Mar 2006 00:22:38 -0800 (PST) Subject: [Rxtx] JavaPOS Message-ID: <20060324082238.66371.qmail@web38214.mail.mud.yahoo.com> Hi all! Hello Trent! From what i understand, RXTX or JavaComm APIs were not created solely for JavaPOS. In JavaPOS, we have the virtual method claim() which is separate from open(), but in our RXTX API, claiming is done every call to open(), we cant open the port if its claimed by another application. Would it be alright to suggest or ask to create a new method called claim(..)? Is there such thing as forceclaim() in RXTX? this could be the same as portownership transfer or its equivalent. ForceClaim is in JSR80. Do you have some samples using RXTX as the lower layer for the Device Service Objects in JavaPOS? I have tried it, i just want to compare. Thank you all! maxim __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060324/496adba2/attachment-0020.html From tjarvi at qbang.org Fri Mar 24 11:28:19 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 24 Mar 2006 11:28:19 -0700 (MST) Subject: [Rxtx] Re: RXTX 2.1 Solaris Problems In-Reply-To: <3691.1143210578@www045.gmx.net> References: <3691.1143210578@www045.gmx.net> Message-ID: On Fri, 24 Mar 2006, Andreas Guenther wrote: > Hi all, > > the solaris problem was not the lock file only. > > Ok, I had to create the directory /var/spool/locks myself. > /var/spool/uucp exists. > > But rxtx didn't find any port. > > I compiled the source with my own debug-informations > and I tried to isolate the problem. > > The problem is the testRead-call in SerialImp.c > > JNIEXPORT jboolean JNICALL RXTXCommDriver(testRead)( > > ... > if ( READ( fd, &c, 1 ) < 0 ) > { > if ( errno != EAGAIN ) { > report( "testRead() read failed\n" ); > ret = JNI_FALSE; > } > } > Thanks Andreas I'm packing up to move. I'll be more or less away for a couple weeks here. I'll be checking email but my workstation is going into a box soon. This isn't hard to fix as this port should be enumerated when EWOULDBLOCK is recieved. Thats error is OK for enumeration just as EAGAIN is. I've put the bug into bugzilla so we dont forget to get to it. http://bugzilla.qbang.org/show_bug.cgi?id=42 You can add yourself to the CC list if you wish to test fixes we provide or even put a patch into bugzilla yourself. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Fri Mar 24 11:51:52 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 24 Mar 2006 11:51:52 -0700 (MST) Subject: [Rxtx] JavaPOS In-Reply-To: <20060324082238.66371.qmail@web38214.mail.mud.yahoo.com> References: <20060324082238.66371.qmail@web38214.mail.mud.yahoo.com> Message-ID: On Fri, 24 Mar 2006, Maximulo Majir wrote: > Hi all! Hello Trent! > > > From what i understand, RXTX or JavaComm APIs were not > created solely for JavaPOS. In JavaPOS, we have the virtual method > claim() which is separate from open(), but in our RXTX API, claiming is > done every call to open(), we cant open the port if its claimed by > another application. Would it be alright to suggest or ask to create a > new method called claim(..)? Is there such thing as forceclaim() in > RXTX? this could be the same as portownership transfer or its > equivalent. ForceClaim is in JSR80. > Do you have some samples using RXTX as the lower layer for the Device > Service Objects in JavaPOS? I have tried it, i just want to compare. > maxim Hi Maxim JSR80 is the USB API IBM/Sun put together. The problem is they have a richer kernel/API underneath that can handle such things. With Serial Ports, there isnt anything there other than an ioctl that says don't let anyone touch this and lockfiles that are more of a 'lets be nice.' At times we may be using USB ports but it is through the termios layer with the limitations mentioned. The advantage is that not only USB will work with rxtx. Anything that has a termios layer should work (to the extent that termios layer is complete). I don't know how forceclaim() would help you. Lets say someone has a programmer working on /dev/ttyS0 and you take it. Now you both race each other to read data first. There isn't a mechanism I know of that will solve this problem in termios. The most obvious test being a native app and a Java app trying to take the port. There is the potential of requestion ownership from other Java Applications but the use for that is very rare. Did you have something more specific in mind that I'm missing? I'm not sure that claim() and forceclaim() would help you with rxtx other than maybe locking the port with claim() without opening it. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sat Mar 25 23:42:08 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 25 Mar 2006 23:42:08 -0700 (MST) Subject: [Rxtx] Serial snoop Message-ID: I was reading the Linux kernel mail-list tonight and ran past a thread that mentioned sersnoop. This looks like a handy tool for people dealing with new toys. "a simple command-line tool for linux that echoes bytes to and from any two serial ports, ptys, or network sockets, and prints all traffic to stdout, in hex and ascii." http://www.restivo.org/projects/sersnoop/ It works on Linux only at this time (debian package available). -- Trent Jarvi tjarvi at qbang.org From beat.arnet at gmail.com Sun Mar 26 07:32:35 2006 From: beat.arnet at gmail.com (Beat Arnet) Date: Sun, 26 Mar 2006 09:32:35 -0500 Subject: [Rxtx] Error 0x5 at /home/bob/foo/tar/rxtx-2.1-7/build/../src/termios.c(860): Access is, denied. Message-ID: <4426A603.80508@gmail.com> Dear all, When trying to open the serial port, I sometimes (not always) run into the following exception (when opening the serialPort): Error 0x5 at /home/bob/foo/tar/rxtx-2.1-7/build/../src/termios.c(860): Access is denied. java.lang.UnsatisfiedLinkError: native_psmisc_report_owner at gnu.io.CommPortIdentifier.native_psmisc_report_owner(Native Method) at gnu.io.CommPortIdentifier.open(CommPortIdentifier.java:354) at codeskin.tools.CLLoader.open(CLLoader.java:79) at codeskin.tools.C2000Programmer.run(C2000Programmer.java:220) at java.lang.Thread.run(Unknown Source) Is this the type of error where I should just try to open the port again, or can it be avoided? Regards, Beat From tjarvi at qbang.org Sun Mar 26 11:40:12 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 26 Mar 2006 11:40:12 -0700 (MST) Subject: [Rxtx] Error 0x5 at /home/bob/foo/tar/rxtx-2.1-7/build/../src/termios.c(860): Access is, denied. In-Reply-To: <4426A603.80508@gmail.com> References: <4426A603.80508@gmail.com> Message-ID: On Sun, 26 Mar 2006, Beat Arnet wrote: > Dear all, > > When trying to open the serial port, I sometimes (not always) run into > the following exception (when opening the serialPort): > > Error 0x5 at /home/bob/foo/tar/rxtx-2.1-7/build/../src/termios.c(860): > Access is > denied. > > java.lang.UnsatisfiedLinkError: native_psmisc_report_owner > at gnu.io.CommPortIdentifier.native_psmisc_report_owner(Native > Method) > at gnu.io.CommPortIdentifier.open(CommPortIdentifier.java:354) > at codeskin.tools.CLLoader.open(CLLoader.java:79) > at codeskin.tools.C2000Programmer.run(C2000Programmer.java:220) > at java.lang.Thread.run(Unknown Source) > > Is this the type of error where I should just try to open the port again, > or can it be avoided? > Hi Beat We did a second build of rxtx 2.1-7 to resolve that unsatisfied link error. It should work now. rxtx is trying to tell you it thinks someone else has the serial port open. You can try to open the port again but maybe you already have a copy of the program running when it happens? ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7r2.zip fixed build. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sun Mar 26 11:44:23 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 26 Mar 2006 11:44:23 -0700 (MST) Subject: [Rxtx] RXTX spec file (fwd) Message-ID: This is probably interesting for fedora/suse users. ---------- Forwarded message ---------- Date: Sun, 26 Mar 2006 16:25:45 +0200 To: taj at www.linux.org.uk Subject: RXTX spec file I send you this spec file which allows to create a RPM for Fedora 4, 5 (x86, x86_64) with Java Sun. -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: rxtx.spec Url: http://mailman.qbang.org/pipermail/rxtx/attachments/20060326/6c7b6af6/rxtx-0016.pl From tjarvi at qbang.org Sun Mar 26 23:42:59 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 26 Mar 2006 23:42:59 -0700 (MST) Subject: [Rxtx] Upcomming events. Message-ID: This Wednesday we will be announcing a new "Maintainer" for the rxtx project. The position is more like neutral leader. I wont be going away or doing less. This is just the right thing to do as it turns out the two people with CVS write access will be at the same company. We need a third and we need neutrality. The maintainer will have final say in any conflict and will try to be neutral. It will be open for discussion. Then we will do it :) I'll still do most of the footwork I do now. But. I'm falling behind. I should have gone through the mail-list and posted the next round of changes this weekend. I'm packing to move and its going so so - 13 years of toys collected. I suspect there will be a dead period on my part (a couple weeks) comming up. But if you get it on the mail-list, we will get it in if there are no objections. I may well not be reading the mail-list during this period as I look for a house and many other things. I hope everyone will help out. Thanks -- Trent Jarvi tjarvi at qbang.org From mahmoud_hadad at yahoo.com Sun Mar 26 07:31:19 2006 From: mahmoud_hadad at yahoo.com (ronan nick) Date: Sun, 26 Mar 2006 06:31:19 -0800 (PST) Subject: [Rxtx] a question about the COMM API Message-ID: <20060326143119.54919.qmail@web60014.mail.yahoo.com> hi, i was intrested in knowing how i can communicate with my internal modem using java? for example if i want to make a phone dialer application or a caller id application where should i be looking at? and as i understood the COMM API is for devices that is attached to the computer through serial ports. --------------------------------- New Yahoo! Messenger with Voice. Call regular phones from your PC and save big. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060326/ce8329f0/attachment-0018.html From dmarkman at mac.com Mon Mar 20 00:20:43 2006 From: dmarkman at mac.com (Dmitry Markman) Date: Mon, 20 Mar 2006 02:20:43 -0500 Subject: [Rxtx] Mac OS X RXTX java installer In-Reply-To: References: <07D0DE29-BA32-4CFE-B036-66BC6423D385@buechse.de> <441AE3E0.2030503@willicon.de> <12531986.1142622114996.JavaMail.dmarkman@mac.com> <441B2674.9010409@willicon.de> <13577405.1142634732776.JavaMail.dmarkman@mac.com> <441B4182.8010407@willicon.de> <92CD0D6C-5BE8-426E-A46D-99452059FF49@mac.com> <441BBB2D.8030305@willicon.de> <441C4088.5090905@willicon.de> Message-ID: <64BC1E23-FDDE-4CE6-8863-CFC881CBC224@mac.com> Hi all I put RXTX installer that will install everything (and will create / var/lock if necessary and add user to the uucp group) for mac os x from Java into the rxtx's CVS repository it could be easily modified to install files for any platform it uses Greg Guerin's AuthKit for authentication and authorization Greg released that kit under artistic license, so Trent, please take a look we, probably, can negotiate license with Greg if it's necessary Greg's AuthKit could be downloaded from http://www.amug.org/~glguerin/ sw/#authkit Michael Hall (mikehall at spacestar dot net) had a suggestion to make implementation of the jaas LoginModule based on Greg's AuthKit (his modification of the Greg's AuthKit could be found at http:// www.spacestar.net/users/mikehall/authkit.dmg) but Michael's AuthKitLoginModule does only half a job: it does authenticate but it can not run any external unix process in privileged mode (at least I wasn't able to do so) possible explanation could be found in conversation between Greg and Michael at Apple's java-dev list (look for archives) so I didn't use jaas API for rxtxinstaller I created folder MacOSX in the contrib folder comment 1. if you want to run that installer as standalone application all you need that RXTXInstaller.jar 2. if you want to use webstart you have to add Greg's libAuthKit.jnilib to the mac os x's resources in theory RXTXInstaller.jar doesn't need it, but there is a problem with loading libAuthKit.jnilib from webstart authkit uses loadLibrary method to load library and it failed (from webstart) for standalone application I extract libAuthKit.jnilib from the RXTXInstaller.jar and put it into the /Library/Java/Extensions or ~/Library/Java/Extensions folder that file will be deleted after installer quit unfortunately I didn't have time to put documentation there but it is mostly self-explanatory I took installer code from my gl4java installer that I did about 3 years ago (with small modifications) it would be very nice if Apple will release LoginModule that really will do the job (com.apple.security.auth.module package????? ) (UnixLoginModule is pretty useless) From lyon at docjava.com Mon Mar 20 06:34:39 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Mon, 20 Mar 2006 08:34:39 -0500 Subject: [Rxtx] Mac OS X RXTX java installer In-Reply-To: <64BC1E23-FDDE-4CE6-8863-CFC881CBC224@mac.com> References: <07D0DE29-BA32-4CFE-B036-66BC6423D385@buechse.de> <441AE3E0.2030503@willicon.de> <12531986.1142622114996.JavaMail.dmarkman@mac.com> <441B2674.9010409@willicon.de> <13577405.1142634732776.JavaMail.dmarkman@mac.com> <441B4182.8010407@willicon.de> <92CD0D6C-5BE8-426E-A46D-99452059FF49@mac.com> <441BBB2D.8030305@willicon.de> <441C4088.5090905@willicon.de> <64BC1E23-FDDE-4CE6-8863-CFC881CBC224@mac.com> Message-ID: Hi Dimitry, This sounds like great work. Just a couple of questions; After the check out of the CVS files, using: setenv CVSROOT :pserver:anonymous at cvs.milestonesolutions.com:/usr/local/cvsroot 53 8:28 setenv PASSWORD mousy 54 8:29 cvs login 55 8:29 cvs checkout rxtx-devel I cd'd over to: rxtx-devel/MACOSX_IDE And found: CVS/ CW/ ForPackageMaker/ PB/ Where is the installer? Thanks! - Doug From tjarvi at qbang.org Mon Mar 20 06:39:37 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 20 Mar 2006 06:39:37 -0700 (MST) Subject: [Rxtx] Mac OS X RXTX java installer In-Reply-To: References: <07D0DE29-BA32-4CFE-B036-66BC6423D385@buechse.de> <441AE3E0.2030503@willicon.de> <12531986.1142622114996.JavaMail.dmarkman@mac.com> <441B2674.9010409@willicon.de> <13577405.1142634732776.JavaMail.dmarkman@mac.com> <441B4182.8010407@willicon.de> <92CD0D6C-5BE8-426E-A46D-99452059FF49@mac.com> <441BBB2D.8030305@willicon.de> <441C4088.5090905@willicon.de> <64BC1E23-FDDE-4CE6-8863-CFC881CBC224@mac.com> Message-ID: On Mon, 20 Mar 2006, Dr. Douglas Lyon wrote: > Hi Dimitry, > This sounds like great work. Just a couple of questions; > After the check out of the CVS files, using: > setenv CVSROOT > :pserver:anonymous at cvs.milestonesolutions.com:/usr/local/cvsroot > 53 8:28 setenv PASSWORD mousy > 54 8:29 cvs login > 55 8:29 cvs checkout rxtx-devel Hi Doug You want "cvs checkout -r commapi-0-0-1 rxtx-devel" to get RXTX 2.1 The default branch is rxtx 2.0 which isn't very active right now. -- Trent Jarvi tjarvi at qbang.org From lyon at docjava.com Mon Mar 20 07:05:44 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Mon, 20 Mar 2006 09:05:44 -0500 Subject: [Rxtx] Mac OS X RXTX java installer In-Reply-To: References: <07D0DE29-BA32-4CFE-B036-66BC6423D385@buechse.de> <441AE3E0.2030503@willicon.de> <12531986.1142622114996.JavaMail.dmarkman@mac.com> <441B2674.9010409@willicon.de> <13577405.1142634732776.JavaMail.dmarkman@mac.com> <441B4182.8010407@willicon.de> <92CD0D6C-5BE8-426E-A46D-99452059FF49@mac.com> <441BBB2D.8030305@willicon.de> <441C4088.5090905@willicon.de> <64BC1E23-FDDE-4CE6-8863-CFC881CBC224@mac.com> Message-ID: Hi Trent, Thanks for the info on the CVS checkout procedure. I did that and am still not sure where the installer is. Here is what I have: cd MACOSX_IDE/ p4.docjava.com{lyon}121: ls CVS/ ForPackageMaker/ PB/ p4.docjava.com{lyon}122: find . | more . ./ForPackageMaker ./ForPackageMaker/RXTX.pkg.sit.hqx ./ForPackageMaker/Resources ./ForPackageMaker/Resources/ReadMe.rtf ./ForPackageMaker/Resources/Welcome.rtf ./ForPackageMaker/Resources/CVS ./ForPackageMaker/Resources/CVS/Entries ./ForPackageMaker/Resources/CVS/Repository ./ForPackageMaker/Resources/CVS/Tag ./ForPackageMaker/Resources/CVS/Root ./ForPackageMaker/Resources/preinstall ./ForPackageMaker/Resources/License.rtf ./ForPackageMaker/Resources/preupgrade ./ForPackageMaker/RXTX.pmsp ./ForPackageMaker/CVS ./ForPackageMaker/CVS/Entries ./ForPackageMaker/CVS/Repository ./ForPackageMaker/CVS/Entries.Log ./ForPackageMaker/CVS/Tag ./ForPackageMaker/CVS/Root ./ForPackageMaker/RXTX_Tiger.pkg.sitx.hqx ./ForPackageMaker/RXTX_Jag.pkg.sit.hqx ./ForPackageMaker/Install ./ForPackageMaker/Install/CVS ./ForPackageMaker/Install/CVS/Entries ./ForPackageMaker/Install/CVS/Repository ./ForPackageMaker/Install/CVS/Tag ./ForPackageMaker/Install/CVS/Root ./ForPackageMaker/Install/Library ./ForPackageMaker/Install/Library/CVS ./ForPackageMaker/Install/Library/CVS/Entries ./ForPackageMaker/Install/Library/CVS/Repository ./ForPackageMaker/Install/Library/CVS/Tag ./ForPackageMaker/Install/Library/CVS/Root ./ForPackageMaker/Install/Library/Java ./ForPackageMaker/Install/Library/Java/Extensions ./ForPackageMaker/Install/Library/Java/Extensions/RXTXcomm.jar ./ForPackageMaker/Install/Library/Java/Extensions/CVS ./ForPackageMaker/Install/Library/Java/Extensions/CVS/Entries ./ForPackageMaker/Install/Library/Java/Extensions/CVS/Repository ./ForPackageMaker/Install/Library/Java/Extensions/CVS/Tag ./ForPackageMaker/Install/Library/Java/Extensions/CVS/Root ./ForPackageMaker/Install/Library/Java/Extensions/librxtxSerial.jnilib ./ForPackageMaker/Install/Library/Java/CVS ./ForPackageMaker/Install/Library/Java/CVS/Entries ./ForPackageMaker/Install/Library/Java/CVS/Repository ./ForPackageMaker/Install/Library/Java/CVS/Entries.Log ./ForPackageMaker/Install/Library/Java/CVS/Tag ./ForPackageMaker/Install/Library/Java/CVS/Root ./ForPackageMaker/RXTX_Tiger.pmproj.sitx.hqx ./CVS ./CVS/Entries ./CVS/Repository ./CVS/Entries.Log ./CVS/Tag ./CVS/Root ./PB ./PB/LibSerialUniversal.xcodeproj.sitx.hqx ./PB/CVS ./PB/CVS/Entries ./PB/CVS/Repository ./PB/CVS/Entries.Log ./PB/CVS/Tag ./PB/CVS/Root ./PB/LibSerial.pbproj.sit.hqx ./PB/startpoint.c ./PB/config.h What is the procedure to run this installer? Do we need a README in: /rxtx-devel/MACOSX_IDE Here is what we have: CVS/ ForPackageMaker/ PB/ Thanks! - DL >On Mon, 20 Mar 2006, Dr. Douglas Lyon wrote: > >>Hi Dimitry, >>This sounds like great work. Just a couple of questions; >>After the check out of the CVS files, using: >>setenv CVSROOT >>:pserver:anonymous at cvs.milestonesolutions.com:/usr/local/cvsroot >> 53 8:28 setenv PASSWORD mousy >> 54 8:29 cvs login >> 55 8:29 cvs checkout rxtx-devel > >Hi Doug > >You want "cvs checkout -r commapi-0-0-1 rxtx-devel" to get RXTX 2.1 >The default branch is rxtx 2.0 which isn't very active right now. > >-- >Trent Jarvi >tjarvi at qbang.org From tjarvi at qbang.org Mon Mar 20 07:25:30 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 20 Mar 2006 07:25:30 -0700 (MST) Subject: [Rxtx] Mac OS X RXTX java installer In-Reply-To: References: <07D0DE29-BA32-4CFE-B036-66BC6423D385@buechse.de> <441AE3E0.2030503@willicon.de> <12531986.1142622114996.JavaMail.dmarkman@mac.com> <441B2674.9010409@willicon.de> <13577405.1142634732776.JavaMail.dmarkman@mac.com> <441B4182.8010407@willicon.de> <92CD0D6C-5BE8-426E-A46D-99452059FF49@mac.com> <441BBB2D.8030305@willicon.de> <441C4088.5090905@willicon.de> <64BC1E23-FDDE-4CE6-8863-CFC881CBC224@mac.com> Message-ID: On Mon, 20 Mar 2006, Dr. Douglas Lyon wrote: > Hi Trent, > Thanks for the info on the CVS checkout procedure. > I did that and am still not sure where the installer is. Hi Doug It does look like it was not cvs committed. There is no rxtx-devel/contrib/MacOSX directory in there at the moment. It was mentioned that it was put under contrib. -- Trent Jarvi tjarvi at qbang.org From dmarkman at mac.com Mon Mar 20 07:29:56 2006 From: dmarkman at mac.com (Dmitry Markman) Date: Mon, 20 Mar 2006 09:29:56 -0500 Subject: [Rxtx] Mac OS X RXTX java installer In-Reply-To: References: <07D0DE29-BA32-4CFE-B036-66BC6423D385@buechse.de> <441AE3E0.2030503@willicon.de> <12531986.1142622114996.JavaMail.dmarkman@mac.com> <441B2674.9010409@willicon.de> <13577405.1142634732776.JavaMail.dmarkman@mac.com> <441B4182.8010407@willicon.de> <92CD0D6C-5BE8-426E-A46D-99452059FF49@mac.com> <441BBB2D.8030305@willicon.de> <441C4088.5090905@willicon.de> <64BC1E23-FDDE-4CE6-8863-CFC881CBC224@mac.com> Message-ID: <6054EB4E-F7E0-4A9C-BDDA-D582D6D8826F@mac.com> you can find it in the rxtx-devel/contrib folder On Mar 20, 2006, at 9:05 AM, Dr. Douglas Lyon wrote: > Hi Trent, > Thanks for the info on the CVS checkout procedure. > I did that and am still not sure where the installer is. > Here is what I have: > cd MACOSX_IDE/ > p4.docjava.com{lyon}121: ls > CVS/ ForPackageMaker/ PB/ > p4.docjava.com{lyon}122: find . | more > . > ./ForPackageMaker > ./ForPackageMaker/RXTX.pkg.sit.hqx > ./ForPackageMaker/Resources > ./ForPackageMaker/Resources/ReadMe.rtf > ./ForPackageMaker/Resources/Welcome.rtf > ./ForPackageMaker/Resources/CVS > ./ForPackageMaker/Resources/CVS/Entries > ./ForPackageMaker/Resources/CVS/Repository > ./ForPackageMaker/Resources/CVS/Tag > ./ForPackageMaker/Resources/CVS/Root > ./ForPackageMaker/Resources/preinstall > ./ForPackageMaker/Resources/License.rtf > ./ForPackageMaker/Resources/preupgrade > ./ForPackageMaker/RXTX.pmsp > ./ForPackageMaker/CVS > ./ForPackageMaker/CVS/Entries > ./ForPackageMaker/CVS/Repository > ./ForPackageMaker/CVS/Entries.Log > ./ForPackageMaker/CVS/Tag > ./ForPackageMaker/CVS/Root > ./ForPackageMaker/RXTX_Tiger.pkg.sitx.hqx > ./ForPackageMaker/RXTX_Jag.pkg.sit.hqx > ./ForPackageMaker/Install > ./ForPackageMaker/Install/CVS > ./ForPackageMaker/Install/CVS/Entries > ./ForPackageMaker/Install/CVS/Repository > ./ForPackageMaker/Install/CVS/Tag > ./ForPackageMaker/Install/CVS/Root > ./ForPackageMaker/Install/Library > ./ForPackageMaker/Install/Library/CVS > ./ForPackageMaker/Install/Library/CVS/Entries > ./ForPackageMaker/Install/Library/CVS/Repository > ./ForPackageMaker/Install/Library/CVS/Tag > ./ForPackageMaker/Install/Library/CVS/Root > ./ForPackageMaker/Install/Library/Java > ./ForPackageMaker/Install/Library/Java/Extensions > ./ForPackageMaker/Install/Library/Java/Extensions/RXTXcomm.jar > ./ForPackageMaker/Install/Library/Java/Extensions/CVS > ./ForPackageMaker/Install/Library/Java/Extensions/CVS/Entries > ./ForPackageMaker/Install/Library/Java/Extensions/CVS/Repository > ./ForPackageMaker/Install/Library/Java/Extensions/CVS/Tag > ./ForPackageMaker/Install/Library/Java/Extensions/CVS/Root > ./ForPackageMaker/Install/Library/Java/Extensions/librxtxSerial.jnilib > ./ForPackageMaker/Install/Library/Java/CVS > ./ForPackageMaker/Install/Library/Java/CVS/Entries > ./ForPackageMaker/Install/Library/Java/CVS/Repository > ./ForPackageMaker/Install/Library/Java/CVS/Entries.Log > ./ForPackageMaker/Install/Library/Java/CVS/Tag > ./ForPackageMaker/Install/Library/Java/CVS/Root > ./ForPackageMaker/RXTX_Tiger.pmproj.sitx.hqx > ./CVS > ./CVS/Entries > ./CVS/Repository > ./CVS/Entries.Log > ./CVS/Tag > ./CVS/Root > ./PB > ./PB/LibSerialUniversal.xcodeproj.sitx.hqx > ./PB/CVS > ./PB/CVS/Entries > ./PB/CVS/Repository > ./PB/CVS/Entries.Log > ./PB/CVS/Tag > ./PB/CVS/Root > ./PB/LibSerial.pbproj.sit.hqx > ./PB/startpoint.c > ./PB/config.h > > What is the procedure to run this installer? > Do we need a README in: > /rxtx-devel/MACOSX_IDE > Here is what we have: > CVS/ ForPackageMaker/ PB/ > > > Thanks! > - DL > >> On Mon, 20 Mar 2006, Dr. Douglas Lyon wrote: >> >>> Hi Dimitry, >>> This sounds like great work. Just a couple of questions; >>> After the check out of the CVS files, using: >>> setenv CVSROOT :pserver:anonymous at cvs.milestonesolutions.com:/usr/ >>> local/cvsroot >>> 53 8:28 setenv PASSWORD mousy >>> 54 8:29 cvs login >>> 55 8:29 cvs checkout rxtx-devel >> >> Hi Doug >> >> You want "cvs checkout -r commapi-0-0-1 rxtx-devel" to get RXTX 2.1 >> The default branch is rxtx 2.0 which isn't very active right now. >> >> -- >> Trent Jarvi >> tjarvi at qbang.org > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx Dmitry Markman From mikehall at spacestar.net Mon Mar 20 05:25:25 2006 From: mikehall at spacestar.net (Michael Hall) Date: Mon, 20 Mar 2006 06:25:25 -0600 Subject: [Rxtx] Re: Mac OS X RXTX java installer In-Reply-To: <64BC1E23-FDDE-4CE6-8863-CFC881CBC224@mac.com> References: <07D0DE29-BA32-4CFE-B036-66BC6423D385@buechse.de> <441AE3E0.2030503@willicon.de> <12531986.1142622114996.JavaMail.dmarkman@mac.com> <441B2674.9010409@willicon.de> <13577405.1142634732776.JavaMail.dmarkman@mac.com> <441B4182.8010407@willicon.de> <92CD0D6C-5BE8-426E-A46D-99452059FF49@mac.com> <441BBB2D.8030305@willicon.de> <441C4088.5090905@willicon.de> <64BC1E23-FDDE-4CE6-8863-CFC881CBC224@mac.com> Message-ID: <247EB61F-5CD1-4132-89A2-FC105B6CF9A5@spacestar.net> On Mar 20, 2006, at 1:20 AM, Dmitry Markman wrote: > > Michael Hall (mikehall at spacestar dot net) had a suggestion to > make implementation of the jaas LoginModule > based on Greg's AuthKit > (his modification of the Greg's AuthKit could be found at http:// > www.spacestar.net/users/mikehall/authkit.dmg) > but Michael's AuthKitLoginModule does only half a job: > it does authenticate > but it can not run any external unix process in privileged mode (at > least I wasn't able to do so) If you got it working directly with Greg's the point is moot. But to clarify it anyhow. The login module does not allow you to do anything anything privileged on return as was explained by Greg. You need to work with a separate privileged process using the execPrivileged method of his API. I assume you did something similar although I haven't looked at how you are using it yet. I allowed instead for a action to be performed at the same time you login/authenticate,this... System.setProperty("authkit.action","/usr/bin/id"); just before this... lc.login(); To clarify, safely ignored as you are already complete. Mike Hall mikehall at spacestar dot net http://www.spacestar.net/users/mikehall http://sourceforge.net/projects/macnative -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2427 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20060320/f6e18202/smime-0021.bin From dmarkman at mac.com Mon Mar 20 07:36:47 2006 From: dmarkman at mac.com (Dmitry Markman) Date: Mon, 20 Mar 2006 09:36:47 -0500 Subject: [Rxtx] Re: Mac OS X RXTX java installer In-Reply-To: <247EB61F-5CD1-4132-89A2-FC105B6CF9A5@spacestar.net> References: <07D0DE29-BA32-4CFE-B036-66BC6423D385@buechse.de> <441AE3E0.2030503@willicon.de> <12531986.1142622114996.JavaMail.dmarkman@mac.com> <441B2674.9010409@willicon.de> <13577405.1142634732776.JavaMail.dmarkman@mac.com> <441B4182.8010407@willicon.de> <92CD0D6C-5BE8-426E-A46D-99452059FF49@mac.com> <441BBB2D.8030305@willicon.de> <441C4088.5090905@willicon.de> <64BC1E23-FDDE-4CE6-8863-CFC881CBC224@mac.com> <247EB61F-5CD1-4132-89A2-FC105B6CF9A5@spacestar.net> Message-ID: Hi, Michael all I have to do is to run some shell script I tried to use your action mechanism and it worked great so I just System.setProperty ("authkit.action","" ) and after that I even don't need to run anything like subject.doAs.... but after few thoughts I choose to use plain Greg's approach, because in that case I don't have to deal with various java's configurations files and therefore to use 2-3 -D parameters in the java command line especially it's useful for java web start (it's so fragile :-( ) thanks for the great job On Mar 20, 2006, at 7:25 AM, Michael Hall wrote: > > On Mar 20, 2006, at 1:20 AM, Dmitry Markman wrote: >> >> Michael Hall (mikehall at spacestar dot net) had a suggestion to >> make implementation of the jaas LoginModule >> based on Greg's AuthKit >> (his modification of the Greg's AuthKit could be found at http:// >> www.spacestar.net/users/mikehall/authkit.dmg) >> but Michael's AuthKitLoginModule does only half a job: >> it does authenticate >> but it can not run any external unix process in privileged mode >> (at least I wasn't able to do so) > > If you got it working directly with Greg's the point is moot. > > But to clarify it anyhow. > The login module does not allow you to do anything anything > privileged on return as was explained by Greg. You need to work > with a separate privileged process using the execPrivileged method > of his API. I assume you did something similar although I haven't > looked at how you are using it yet. > I allowed instead for a action to be performed at the same time you > login/authenticate,this... > System.setProperty("authkit.action","/usr/bin/id"); > just before this... > lc.login(); > To clarify, safely ignored as you are already complete. > > Mike Hall mikehall at spacestar dot net > http://www.spacestar.net/users/mikehall > http://sourceforge.net/projects/macnative > > > Dmitry Markman From dmarkman at mac.com Mon Mar 20 07:44:45 2006 From: dmarkman at mac.com (Dmitry Markman) Date: Mon, 20 Mar 2006 09:44:45 -0500 Subject: [Rxtx] Mac OS X RXTX java installer In-Reply-To: References: <07D0DE29-BA32-4CFE-B036-66BC6423D385@buechse.de> <441AE3E0.2030503@willicon.de> <12531986.1142622114996.JavaMail.dmarkman@mac.com> <441B2674.9010409@willicon.de> <13577405.1142634732776.JavaMail.dmarkman@mac.com> <441B4182.8010407@willicon.de> <92CD0D6C-5BE8-426E-A46D-99452059FF49@mac.com> <441BBB2D.8030305@willicon.de> <441C4088.5090905@willicon.de> <64BC1E23-FDDE-4CE6-8863-CFC881CBC224@mac.com> Message-ID: it's in the commapi-0-0-1 branch I tested it right now: cvs co -r commapi-0-0-1 rxtx-devel and I got everything On Mar 20, 2006, at 9:25 AM, Trent Jarvi wrote: > On Mon, 20 Mar 2006, Dr. Douglas Lyon wrote: > >> Hi Trent, >> Thanks for the info on the CVS checkout procedure. >> I did that and am still not sure where the installer is. > > Hi Doug > > It does look like it was not cvs committed. There is no rxtx-devel/ > contrib/MacOSX directory in there at the moment. It was mentioned > that it was put under contrib. > > -- > Trent Jarvi > tjarvi at qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx Dmitry Markman From tjarvi at qbang.org Mon Mar 20 07:52:57 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 20 Mar 2006 07:52:57 -0700 (MST) Subject: [Rxtx] Mac OS X RXTX java installer In-Reply-To: References: <07D0DE29-BA32-4CFE-B036-66BC6423D385@buechse.de> <441AE3E0.2030503@willicon.de> <12531986.1142622114996.JavaMail.dmarkman@mac.com> <441B2674.9010409@willicon.de> <13577405.1142634732776.JavaMail.dmarkman@mac.com> <441B4182.8010407@willicon.de> <92CD0D6C-5BE8-426E-A46D-99452059FF49@mac.com> <441BBB2D.8030305@willicon.de> <441C4088.5090905@willicon.de> <64BC1E23-FDDE-4CE6-8863-CFC881CBC224@mac.com> Message-ID: On Mon, 20 Mar 2006, Dmitry Markman wrote: > it's in the commapi-0-0-1 branch > > I tested it right now: > cvs co -r commapi-0-0-1 rxtx-devel > > and I got everything > A fresh checkout worked. Here is a copy of the tree (just the installer bits) ftp://ftp.qbang.org/pub/rxtx/MacOSX-installer.zip -- Trent Jarvi tjarvi at qbang.org From lyon at docjava.com Mon Mar 20 08:08:26 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Mon, 20 Mar 2006 10:08:26 -0500 Subject: [Rxtx] Mac OS X RXTX java installer In-Reply-To: References: <07D0DE29-BA32-4CFE-B036-66BC6423D385@buechse.de> <441AE3E0.2030503@willicon.de> <12531986.1142622114996.JavaMail.dmarkman@mac.com> <441B2674.9010409@willicon.de> <13577405.1142634732776.JavaMail.dmarkman@mac.com> <441B4182.8010407@willicon.de> <92CD0D6C-5BE8-426E-A46D-99452059FF49@mac.com> <441BBB2D.8030305@willicon.de> <441C4088.5090905@willicon.de> <64BC1E23-FDDE-4CE6-8863-CFC881CBC224@mac.com> Message-ID: Hi All, Is the Auth package able to work properly on non Mac OS's? It was not clear from the doc or download. Thanks! - Doug From dmarkman at mac.com Mon Mar 20 08:15:22 2006 From: dmarkman at mac.com (Dmitry Markman) Date: Mon, 20 Mar 2006 10:15:22 -0500 Subject: [Rxtx] Mac OS X RXTX java installer In-Reply-To: References: <07D0DE29-BA32-4CFE-B036-66BC6423D385@buechse.de> <441AE3E0.2030503@willicon.de> <12531986.1142622114996.JavaMail.dmarkman@mac.com> <441B2674.9010409@willicon.de> <13577405.1142634732776.JavaMail.dmarkman@mac.com> <441B4182.8010407@willicon.de> <92CD0D6C-5BE8-426E-A46D-99452059FF49@mac.com> <441BBB2D.8030305@willicon.de> <441C4088.5090905@willicon.de> <64BC1E23-FDDE-4CE6-8863-CFC881CBC224@mac.com> Message-ID: <217312D8-CCCA-4859-ABA6-32DF1CC817B9@mac.com> thanks Trent, for putting it on ftp server On Mar 20, 2006, at 9:52 AM, Trent Jarvi wrote: > A fresh checkout worked. Here is a copy of the tree (just the > installer bits) > > ftp://ftp.qbang.org/pub/rxtx/MacOSX-installer.zip > Dmitry Markman From dmarkman at mac.com Mon Mar 20 09:14:03 2006 From: dmarkman at mac.com (Dmitry Markman) Date: Mon, 20 Mar 2006 11:14:03 -0500 Subject: [Rxtx] Mac OS X RXTX java installer In-Reply-To: References: <07D0DE29-BA32-4CFE-B036-66BC6423D385@buechse.de> <441AE3E0.2030503@willicon.de> <12531986.1142622114996.JavaMail.dmarkman@mac.com> <441B2674.9010409@willicon.de> <13577405.1142634732776.JavaMail.dmarkman@mac.com> <441B4182.8010407@willicon.de> <92CD0D6C-5BE8-426E-A46D-99452059FF49@mac.com> <441BBB2D.8030305@willicon.de> <441C4088.5090905@willicon.de> <64BC1E23-FDDE-4CE6-8863-CFC881CBC224@mac.com> Message-ID: <4DEBA6F0-DA45-4E84-823E-1F1AC48BDCCC@mac.com> no it will work only on mac os x however it's harmless to run it on other platform if you want to use it for other platform you have to do the following (I'll do it for linux) 1. modify RXTXInstaller class method public static RXTXInstaller getInstance() public static RXTXInstaller getInstance() { String osName = System.getProperty("os.name").toLowerCase(); if(osName.startsWith("mac")){ return new gnu.io.installer.macosx.MACOSXRXTXInstaller(); } else if(osName.startsWith("windows")){ return new gnu.io.installer.windows.WindowsRXTXInstaller(); }else if(osName.startsWith("linux")){ return new gnu.io.installer.linux.LinuxRXTXInstaller(); } return null; } 2. create folder gnu/io/installer/linux/ 3. create class Linux386RXTXInstaller package gnu.io.installer.linux; import java.io.File; public class Linux386RXTXInstaller extends gnu.io.installer.RXTXInstaller{ public Linux386RXTXInstaller(){ createJarFolder(); createLibFolder(); addJarResource("RXTXcomm.jar","/gnu/io/installer/resources/ linux/jar/RXTXcomm.dat"); addLibResource("librxtxSerial.so","/gnu/io/installer/ resources/linux/lib/librxtxSerial.so"); } protected void createJarFolder(){ String javaHome = System.getProperty("java.home"); char separator = File.separatorChar; jarFolder = new File(javaHome+separator+"lib"+separator+"ext"); } protected void createLibFolder(){ String javaHome = System.getProperty("java.home"); char separator = File.separatorChar; libFolder = new File(javaHome+separator+"bin"); } public void runPreProcess() {} //put here some action you need public void runPostProcess() {} //put here some action you need } 4. create folder /gnu/io/installer/resources/linux/jar and put there linux's version of RXTXcomm.dat (which is renamed RXTXcomm.jar) 5. create folder /gnu/io/installer/resources/linux/lib and put there linux's version of librxtxSerial. so 6. make sure that RXTXInstaller.jar has the following items: /gnu/io/installer/resources/linux/jar/RXTXcomm.jar /gnu/io/installer/resources/linux/lib/librxtxSerial.so 7. modify file installer.pref: jar file RXTXInstaller.jar must have the following item /gnu/io/installer/installer.pref that's basically it for windows you have to do the similar things: just replace linux to windows and librxtxSerial.so to rxtxSerial.dll and create appropriate gnu.io.installer.windows.WindowsRXTXInstaller class package gnu.io.installer.windows; import java.io.File; public class WindowsRXTXInstaller extends gnu.io.installer.RXTXInstaller{ public WindowsRXTXInstaller(){ createJarFolder(); createLibFolder(); addJarResource("RXTXcomm.jar","/gnu/io/installer/resources/ windows/jar/RXTXcomm.dat"); addLibResource("librxtxSerial.so","/gnu/io/installer/ resources/windows/lib/rxtxSerial.dll"); } protected void createJarFolder(){ String javaHome = System.getProperty("java.home"); char separator = File.separatorChar; jarFolder = new File(javaHome+separator+"lib"+separator+"ext"); } protected void createLibFolder(){ String javaHome = System.getProperty("java.home"); char separator = File.separatorChar; libFolder = new File(javaHome+separator+"bin"); } public void runPreProcess() {} //put here some action you need public void runPostProcess() {} //put here some action you need } installer.pref will look like On Mar 20, 2006, at 10:08 AM, Dr. Douglas Lyon wrote: > Hi All, > Is the Auth package able to work properly on > non Mac OS's? > It was not clear from the doc or download. > > Thanks! > - Doug > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx Dmitry Markman From joachim at buechse.de Mon Mar 20 10:49:06 2006 From: joachim at buechse.de (Joachim Buechse) Date: Mon, 20 Mar 2006 18:49:06 +0100 Subject: [Rxtx] BUG: Lock file stays even if port opening fails Message-ID: This was only tested on MacOSX but looking at the code, it should be true for all systems that use lock_uucp. I am opening a port which can not be opened (dialup port of a telephone paired via bluetooth but currently not reachable). The lock file is created and stays arround, even though the port open failed. After looking a bit through the code (of 2.17), I really wonder if it wouldn't be a good idea to make the "locking" an explicit operation called from the java code. This would certainly simplify the generation of meaningfull exceptions (and java based debugging). Maybe even the handling of "preopened" ports should be in the Java part of the lib (again for java based debugging puposes). That beeing said, I have no idea if this would be possible for the 2.07 implementation. Regards, Joachim From tjarvi at qbang.org Mon Mar 20 11:24:22 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 20 Mar 2006 11:24:22 -0700 (MST) Subject: [Rxtx] BUG: Lock file stays even if port opening fails In-Reply-To: References: Message-ID: On Mon, 20 Mar 2006, Joachim Buechse wrote: > This was only tested on MacOSX but looking at the code, it should be true > for all systems that use lock_uucp. > > I am opening a port which can not be opened (dialup port of a telephone > paired via bluetooth but currently not reachable). The lock file is > created and stays arround, even though the port open failed. > > > After looking a bit through the code (of 2.17), I really wonder if it > wouldn't be a good idea to make the "locking" an explicit operation > called from the java code. This would certainly simplify the generation > of meaningfull exceptions (and java based debugging). > Maybe even the handling of "preopened" ports should be in the Java part > of the lib (again for java based debugging puposes). That beeing said, I > have no idea if this would be possible for the 2.07 implementation. > > Regards, Hi Joachim It should be possible in the 2.0-7 implementation too. The calls to RXTXPort.java would not change. We would just do more there Moving more of that logic into Java would be better as many people don't like to look at C code. There is a liblockdev on most Linux distros that can do most of the C code and would be easier to use. The problem is embeded devices will not have that library. The preopened port code has not been really tested. That was a last minute request in a product cycle. I expect it will be tested this year though. As I recall, some devices really do not like CD raising on open. The preopened ports then allow people to mess around in java without power cycling the devices or losing data. -- Trent Jarvi tjarvi at qbang.org From joachim at buechse.de Mon Mar 20 12:01:08 2006 From: joachim at buechse.de (Joachim Buechse) Date: Mon, 20 Mar 2006 20:01:08 +0100 Subject: [Rxtx] BUG: Lock file stays even if port opening fails In-Reply-To: References: Message-ID: Hi Trent, What is your general feeling about moving code to Java? The last days I have been reading quite a bit of the code and there are several things, that might not work as expected. I'll give you two examples from is_device_locked: if LOCKDIR == /var/spool/locks the directory /var/spool/lock will not be checked. LOCKDIR is not checked for lockfiles with unexpected pefixes While these things have probably never been discovered in production, they are still possibly incorrect implementations. If it was Java code, I would write some unit tests producing the errors that could later be corrected. PS: One could imagine to actually implement the whole lockfile handling in Java using some native routines to get the values required (pid, st_dev, st_rdev, ...). On 20.03.2006, at 19:24, Trent Jarvi wrote: > On Mon, 20 Mar 2006, Joachim Buechse wrote: > >> This was only tested on MacOSX but looking at the code, it should >> be true for all systems that use lock_uucp. >> >> I am opening a port which can not be opened (dialup port of a >> telephone paired via bluetooth but currently not reachable). The >> lock file is created and stays arround, even though the port open >> failed. >> >> >> After looking a bit through the code (of 2.17), I really wonder if >> it wouldn't be a good idea to make the "locking" an explicit >> operation called from the java code. This would certainly simplify >> the generation of meaningfull exceptions (and java based debugging). >> Maybe even the handling of "preopened" ports should be in the Java >> part of the lib (again for java based debugging puposes). That >> beeing said, I have no idea if this would be possible for the 2.07 >> implementation. >> >> Regards, > > Hi Joachim > > It should be possible in the 2.0-7 implementation too. The calls > to RXTXPort.java would not change. We would just do more there > Moving more of that logic into Java would be better as many people > don't like to look at C code. There is a liblockdev on most Linux > distros that can do most of the C code and would be easier to use. > The problem is embeded devices will not have that library. > > The preopened port code has not been really tested. That was a > last minute request in a product cycle. I expect it will be tested > this year though. As I recall, some devices really do not like CD > raising on open. The preopened ports then allow people to mess > around in java without power cycling the devices or losing data. > > -- > Trent Jarvi > tjarvi at qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Mon Mar 20 12:21:02 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 20 Mar 2006 12:21:02 -0700 (MST) Subject: [Rxtx] BUG: Lock file stays even if port opening fails In-Reply-To: References: Message-ID: On Mon, 20 Mar 2006, Joachim Buechse wrote: > Hi Trent, > > What is your general feeling about moving code to Java? The last days I > have been reading quite a bit of the code and there are several things, > that might not work as expected. > > I'll give you two examples from is_device_locked: > > if LOCKDIR == /var/spool/locks the directory /var/spool/lock will not be > checked. > LOCKDIR is not checked for lockfiles with unexpected pefixes > > While these things have probably never been discovered in production, > they are still possibly incorrect implementations. If it was Java code, I > would write some unit tests producing the errors that could later be > corrected. > > PS: One could imagine to actually implement the whole lockfile handling > in Java using some native routines to get the values required (pid, > st_dev, st_rdev, ...). Hi Joachim I like the idea of moving more of the code into java but there are some things to consider. If you break this into multiple JNI calls, the performance will drop considerably during enumeration of ports. We are looking for 256 ports per dev type vs (16? in Sun's 2.0 and fewer types). Its hard to make assumptions. I've seen virtual ports start at /dev/foo100 for instance. It works out to over 7500 ports on Linux if you enable them all. We already trim that back by default. See Linux-all-ports in RXTXCommDriver.java. There are also native libraries that rxtx can link to. If you move too much into Java, linking to 'standard' libraries with distros will break. "configure --enable-liblock=yes" will not be doable. This is probably a favorable way with RedHat, Debian, Suse and others. Thats the right thing to do if there will be rpms, dpkg, .. For those reasons, I think it still make sense to keep it to a minimal ~3 calls to JNI code that we can use for speed and versatility. lock() isLocked(), unlock() perhaps. When I say speed, its more about avoiding crossing the JNI layer multiple times than java vs C performance. With versatility I think liblock is the right way for most but not all (embeded) linux distros. -- Trent Jarvi tjarvi at qbang.org From joachim at buechse.de Mon Mar 20 12:42:04 2006 From: joachim at buechse.de (Joachim Buechse) Date: Mon, 20 Mar 2006 20:42:04 +0100 Subject: [Rxtx] BUG: Lock file stays even if port opening fails In-Reply-To: References: Message-ID: <82C19FE7-DDCB-45B6-B2C9-7606B66F0124@buechse.de> Ok, what about providing a default implementation in Java? The RXTXCommDriver would call a (native) function useNativeLocking and if it returns true, call the native functions for lock() isLocked (), unlock(), else is would use the Java based default implementation. This could possibly be overriden by a property (again for debugging). Joachim On 20.03.2006, at 20:21, Trent Jarvi wrote: > On Mon, 20 Mar 2006, Joachim Buechse wrote: > >> Hi Trent, >> >> What is your general feeling about moving code to Java? The last >> days I have been reading quite a bit of the code and there are >> several things, that might not work as expected. >> >> I'll give you two examples from is_device_locked: >> >> if LOCKDIR == /var/spool/locks the directory /var/spool/lock will >> not be checked. >> LOCKDIR is not checked for lockfiles with unexpected pefixes >> >> While these things have probably never been discovered in >> production, they are still possibly incorrect implementations. If >> it was Java code, I would write some unit tests producing the >> errors that could later be corrected. >> >> PS: One could imagine to actually implement the whole lockfile >> handling in Java using some native routines to get the values >> required (pid, st_dev, st_rdev, ...). > > Hi Joachim > > I like the idea of moving more of the code into java but there are > some things to consider. > > If you break this into multiple JNI calls, the performance will > drop considerably during enumeration of ports. We are looking for > 256 ports per dev type vs (16? in Sun's 2.0 and fewer types). Its > hard to make assumptions. I've seen virtual ports start at /dev/ > foo100 for instance. > > It works out to over 7500 ports on Linux if you enable them all. > We already trim that back by default. See Linux-all-ports in > RXTXCommDriver.java. > > There are also native libraries that rxtx can link to. If you move > too much into Java, linking to 'standard' libraries with distros > will break. "configure --enable-liblock=yes" will not be doable. > This is probably a favorable way with RedHat, Debian, Suse and > others. Thats the right thing to do if there will be rpms, dpkg, .. > > For those reasons, I think it still make sense to keep it to a > minimal ~3 calls to JNI code that we can use for speed and > versatility. lock() isLocked(), unlock() perhaps. When I say > speed, its more about avoiding crossing the JNI layer multiple > times than java vs C performance. With versatility I think liblock > is the right way for most but not all (embeded) linux distros. > > -- > Trent Jarvi > tjarvi at qbang.org > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Mon Mar 20 12:44:47 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 20 Mar 2006 12:44:47 -0700 (MST) Subject: [Rxtx] BUG: Lock file stays even if port opening fails In-Reply-To: <82C19FE7-DDCB-45B6-B2C9-7606B66F0124@buechse.de> References: <82C19FE7-DDCB-45B6-B2C9-7606B66F0124@buechse.de> Message-ID: On Mon, 20 Mar 2006, Joachim Buechse wrote: > Ok, what about providing a default implementation in Java? > > The RXTXCommDriver would call a (native) function useNativeLocking and if > it returns true, call the native functions for lock() isLocked(), > unlock(), else is would use the Java based default implementation. This > could possibly be overriden by a property (again for debugging). > Hi Joachim That would be OK with me. -- Trent Jarvi tjarvi at qbang.org From dmarkman at mac.com Mon Mar 20 22:27:45 2006 From: dmarkman at mac.com (Dmitry Markman) Date: Tue, 21 Mar 2006 00:27:45 -0500 Subject: [Rxtx] binaries request Message-ID: <42702213-C222-4937-A585-7CFB17E47608@mac.com> Hi can somebody send me latest linux and windows binaries, please? or where I can find them (I didn't find them in the latest tareball) I gave up with my cygwin: something wrong I have no idea what java doesn't understand /cygwin/c syntax after I changed makefile it did java part but after that gcc 3.4.4 started to complain I set buffer length to 999 lines but I didn't get beginning of the story something wrong with my 1.4.2_09/include/jni.h gcc doesn't like it anyway I gave up thanks in advance Dmitry Markman -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060320/f8cbc57c/attachment-0021.html From tjarvi at qbang.org Mon Mar 20 22:36:48 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 20 Mar 2006 22:36:48 -0700 (MST) Subject: [Rxtx] binaries request In-Reply-To: <42702213-C222-4937-A585-7CFB17E47608@mac.com> References: <42702213-C222-4937-A585-7CFB17E47608@mac.com> Message-ID: On Tue, 21 Mar 2006, Dmitry Markman wrote: > Hi > can somebody send me latest linux and windows binaries, please? > > or where I can find them (I didn't find them in the latest tareball) > > I gave up with my cygwin: something wrong I have no idea what > java doesn't understand /cygwin/c syntax > after I changed makefile it did java part > but after that gcc 3.4.4 started to complain > I set buffer length to 999 lines but I didn't get beginning of the story > something wrong with my 1.4.2_09/include/jni.h gcc doesn't like it > anyway I gave up > > thanks in advance > Hi Dmitry The bins are here: ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7-bins-r2.zip Here are the files in the zip you want. Jar: rxtx-2.1-7-bins-r2/RXTXcomm.jar Windows: rxtx-2.1-7-bins-r2/Windows/i368-mingw32/rxtxSerial.dll Linux (x86) rxtx-2.1-7-bins-r2/Linux/i686-unknown-linux-gnu/librxtxSerial.so There are others in there including Parallel port support but those are the main ones for testing. -- Trent Jarvi tjarvi at qbang.org From dmarkman at mac.com Mon Mar 20 23:05:59 2006 From: dmarkman at mac.com (Dmitry Markman) Date: Tue, 21 Mar 2006 01:05:59 -0500 Subject: [Rxtx] binaries request In-Reply-To: References: <42702213-C222-4937-A585-7CFB17E47608@mac.com> Message-ID: thank you very much but windows's readme says: rxtxSerial.dll had to be recomopiled to link in missing native methods. should I ignore it? or what? thanks again also I understand that I should use mingw not cygwin I'll try to install mingw On Mar 21, 2006, at 12:36 AM, Trent Jarvi wrote: > On Tue, 21 Mar 2006, Dmitry Markman wrote: > >> Hi >> can somebody send me latest linux and windows binaries, please? >> >> or where I can find them (I didn't find them in the latest tareball) >> >> I gave up with my cygwin: something wrong I have no idea what >> java doesn't understand /cygwin/c syntax >> after I changed makefile it did java part >> but after that gcc 3.4.4 started to complain >> I set buffer length to 999 lines but I didn't get beginning of the >> story >> something wrong with my 1.4.2_09/include/jni.h gcc doesn't like it >> anyway I gave up >> >> thanks in advance >> > > Hi Dmitry > > The bins are here: > > ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7-bins-r2.zip > > Here are the files in the zip you want. > > Jar: > > rxtx-2.1-7-bins-r2/RXTXcomm.jar > > Windows: > > rxtx-2.1-7-bins-r2/Windows/i368-mingw32/rxtxSerial.dll > > Linux (x86) > > rxtx-2.1-7-bins-r2/Linux/i686-unknown-linux-gnu/librxtxSerial.so > > There are others in there including Parallel port support but those > are the main ones for testing. > > -- > Trent Jarvi > tjarvi at qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx Dmitry Markman From tjarvi at qbang.org Mon Mar 20 23:20:33 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 20 Mar 2006 23:20:33 -0700 (MST) Subject: [Rxtx] binaries request In-Reply-To: References: <42702213-C222-4937-A585-7CFB17E47608@mac.com> Message-ID: On Tue, 21 Mar 2006, Dmitry Markman wrote: > thank you very much > > but windows's readme says: > rxtxSerial.dll had to be recomopiled to link in missing native methods. > > should I ignore it? or what? > Hi Dmitry That dll should be OK. r2 is the recompile linked to the missing native method. The readme explains why it was recompiled; fuser.o was not linked into the dll in the first release. -- Trent Jarvi tjarvi at qbang.org From ariantristan at yahoo.com Mon Mar 20 23:55:24 2006 From: ariantristan at yahoo.com (Lambok Sianturi) Date: Mon, 20 Mar 2006 22:55:24 -0800 (PST) Subject: [Rxtx] jvm issue Message-ID: <20060321065524.94779.qmail@web50701.mail.yahoo.com> Hi All, This is my first time to join RxTx mailing list. I thank you all for allowing others to sign in in requests help. I use the latest RxTx lib in Fedora 3 with java version 1.4.2_09 b05. And I got this error: # # An unexpected error has been detected by HotSpot Virtual Machine: # # SIGSEGV (0xb) at pc=0x00bf27f3, pid=2633, tid=3086112448 # # Java VM: Java HotSpot(TM) Client VM (1.4.2_09-b05 mixed mode) # Problematic frame: # C [ld-linux.so.2+0xa7f3] # # An error report file with more information is saved as hs_err_pid2633.log # # If you would like to submit a bug report, please visit: # http://java.sun.com/webapps/bugreport/crash.jsp # ./run.sh: line 3: 2633 Aborted /usr/local/java/bin/java -Djava.library.path=/usr/local/java/jre/lib/ -Djsmsengine.debug=true -classpath jsmsengine.jar:smsgateway.jar:classes12.jar:RXTXcomm.jar:. com.api.sms.SMSServer What is the jvm depedency for the latest library? Can I use 1.4.2_09 b05? Thanks in advance. Arian --------------------------------- Yahoo! Mail Use Photomail to share photos without annoying attachments. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060320/83d58dd7/attachment-0021.html From f.frumento at ngi.it Tue Mar 21 00:21:47 2006 From: f.frumento at ngi.it (Fabio Frumento) Date: Tue, 21 Mar 2006 08:21:47 +0100 Subject: [Rxtx] Javadoc on the go Message-ID: <441FA98B.9050701@ngi.it> Hi Trent, sorry for the big delay but my job is running wild, i was out for some time but now i'm back and ready to continue the javadoc for Rxtx. Did you used the last javadoc patch i sent you ? let me know if i have to send it to you again or not. regards Fabio From lyon at docjava.com Tue Mar 21 00:51:18 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Tue, 21 Mar 2006 02:51:18 -0500 Subject: [Rxtx] lock files Message-ID: Hi All, You know, if the use of lock files were under Java control (rather than a build-time decision), it might enable a more unified binary distro. It might also facilitate quick prototyping of non-lock file approaches to resolving serial port contention issues (i.e., mac-like approaches vs. linux approaches, etc.). I realize that this is a radical overhaul of the lock file policy issue. Also, it may harm performance. On the other hand, our benchmarks on JNI overhead for modern processors indicate performance impact should be minimal. Perhaps it is more of an issue with the toybox systems. Suppose there were a class with a reasonable default...someone might write: SerialPortLockPolicy.setPolicy(SerialPortLockPolicy.UNIX_LOCK_FILE); SerialPortLockPolicy.setPolicy(SerialPortLockPolicy.NO_LOCK_CHECKING); SerialPortLockPolicy.setPolicy(SerialPortLockPolicy.MAC_STYLE); Thus, we could have a run-time reconfiguration of the serial port lock policy. A special NO_LOCK version of the binary would no longer be required. Any thoughts on this? Thanks! - Doug From joachim at buechse.de Tue Mar 21 03:09:09 2006 From: joachim at buechse.de (Joachim Buechse) Date: Tue, 21 Mar 2006 11:09:09 +0100 Subject: [Rxtx] lock files In-Reply-To: References: Message-ID: <8E12916A-1B9A-4FF2-B684-E2D1C794221B@buechse.de> This is pretty much what I thought about when I suggested, that the default behaviour could be overwritten with a property. I am very much in favor of this approach. In particular this allows much easier debugging for PC based java developers. I think big parts of the Java (and maybe some parts of the C code) could use a bit of a structural workover (unit tests, javadoc, synchronization, etc). Maybe there should be a CVS branch for this experimental version. I'd be happy to contribute a first workover for some of the Java code. Designing for testability and implementing a good bunch of unit tests has been a strategy that worked quite well in the Java projects I lead. And it ultimately allows more liberal change permission. Regards, Joachim On 21.03.2006, at 08:51, Dr. Douglas Lyon wrote: > Hi All, > You know, if the use of lock files were > under Java control (rather than a build-time decision), > it might enable a more unified binary distro. It might also > facilitate quick prototyping of non-lock file approaches > to resolving serial port contention issues (i.e., mac-like > approaches vs. linux approaches, etc.). > > I realize that this is a radical overhaul of the lock file policy > issue. Also, it may harm performance. On the other hand, > our benchmarks on JNI overhead for modern processors indicate > performance impact should be minimal. Perhaps it is more of > an issue with the toybox systems. > > Suppose there were a class with a reasonable default...someone > might write: > SerialPortLockPolicy.setPolicy(SerialPortLockPolicy.UNIX_LOCK_FILE); > SerialPortLockPolicy.setPolicy(SerialPortLockPolicy.NO_LOCK_CHECKING); > SerialPortLockPolicy.setPolicy(SerialPortLockPolicy.MAC_STYLE); > > Thus, we could have a run-time reconfiguration of the serial port lock > policy. A special NO_LOCK version of the binary would no longer > be required. > > Any thoughts on this? > > Thanks! > - Doug > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From joachim at buechse.de Tue Mar 21 06:23:08 2006 From: joachim at buechse.de (Joachim Buechse) Date: Tue, 21 Mar 2006 14:23:08 +0100 Subject: [Rxtx] PATCH: use of ioctl(fd, TIOCEXCL) instead of lockfiles Message-ID: <923AE774-EEA2-4911-92D8-32BB27802C8B@buechse.de> Here is the patch for the ioctl(fd, TIOCEXCL). I have verified this only for OSX 10.4.5, hence it is only defined for APPLE. However, it should work at least for Solaris as well. If a process has requested TIOEXCL further open calls by other user processes will fail. The patch also disables uucp style locking for APPLE. Obviously this is discussable. I think it is the way to go, as it eliminates creating the lock directory which doesnt exist on the standard installation and it eliminates messing with the system group definitions (adding users to group uucp). Regarding the possibility of root processes opening a device which is locked - I consider this a feature not a potential problem. It is highly unlikely, that somebody is crazy enough to run a JavaVM as root (unless he has no other means of getting a restricted IP port opened, ie doesnt understand ipfw). Anyway, even if the process runs as root, it fails when calling ioctl(fd, TIOCEXCL). It could however still open the port to listen for RING events. I.e. a fax server which needs to see incoming calls but otherwise doesnt want to block the port. So the only case where the proposed mechanism fails is, if an incorrectly implemented process running as root conflicts with a user process. I think this can be accepted. Regards, Joachim PS: If this patch is generally accepted, the installer and Mac doku should obviously be changed as well. Index: SerialImp.c =================================================================== RCS file: /usr/local/cvsroot/rxtx-devel/src/SerialImp.c,v retrieving revision 1.46.2.187 diff -u -r1.46.2.187 SerialImp.c --- SerialImp.c 29 Jan 2006 22:19:04 -0000 1.46.2.187 +++ SerialImp.c 21 Mar 2006 12:59:16 -0000 @@ -656,6 +656,25 @@ fd=OPEN (filename, O_RDWR | O_NOCTTY | O_NONBLOCK ); } while (fd < 0 && errno==EINTR); +#ifdef OPEN_EXCL + // Note that open() follows POSIX semantics: multiple open() calls to + // the same file will succeed unless the TIOCEXCL ioctl is issued. + // This will prevent additional opens except by root-owned processes. + // See tty(4) ("man 4 tty") and ioctl(2) ("man 2 ioctl") for details. + + if (fd >= 0 && (ioctl(fd, TIOCEXCL) == -1)) + { + sprintf( message, "open: exclusive access denied for % s\n", + filename ); + report( message ); + report_error( message ); + + close(fd); + goto fail; + } +#endif /* OPEN_EXCL */ + + if( configure_port( fd ) ) goto fail; (*env)->ReleaseStringUTFChars( env, jstr, filename ); sprintf( message, "open: fd returned is %i\n", fd ); Index: SerialImp.h =================================================================== RCS file: /usr/local/cvsroot/rxtx-devel/src/SerialImp.h,v retrieving revision 1.11.2.49 diff -u -r1.11.2.49 SerialImp.h --- SerialImp.h 5 Jul 2005 17:47:21 -0000 1.11.2.49 +++ SerialImp.h 21 Mar 2006 12:59:17 -0000 @@ -135,7 +135,8 @@ /*# define LOCKDIR "/var/spool/uucp"*/ # define LOCKDIR "/var/lock" # define LOCKFILEPREFIX "LK." -# define UUCP +/*# define UUCP*/ +# define OPEN_EXCL #endif /* __APPLE__ */ #if defined(__NetBSD__) # define DEVICEDIR "/dev/" From tjarvi at qbang.org Tue Mar 21 10:26:08 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 21 Mar 2006 10:26:08 -0700 (MST) Subject: [Rxtx] Javadoc on the go In-Reply-To: <441FA98B.9050701@ngi.it> References: <441FA98B.9050701@ngi.it> Message-ID: On Tue, 21 Mar 2006, Fabio Frumento wrote: > Hi Trent, > > sorry for the big delay but my job is running wild, i was out for some > time but now i'm back and ready to continue the javadoc for Rxtx. > > Did you used the last javadoc patch i sent you ? let me know if i have to > send it to you again or not. > > regards > > Fabio Hi Fabio The patch is in the rxtx mail-list archives. It will be going in soon. I did not see a time critical portion. I'll probably be going through the list since the last batch of patches this weekend and putting them into CVS. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Tue Mar 21 10:57:18 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 21 Mar 2006 10:57:18 -0700 (MST) Subject: [Rxtx] jvm issue In-Reply-To: <20060321065524.94779.qmail@web50701.mail.yahoo.com> References: <20060321065524.94779.qmail@web50701.mail.yahoo.com> Message-ID: On Mon, 20 Mar 2006, Lambok Sianturi wrote: > Hi All, > This is my first time to join RxTx mailing list. I thank you all for allowing others to sign in in requests help. > I use the latest RxTx lib in Fedora 3 with java version 1.4.2_09 b05. And I got this error: > > # > # An unexpected error has been detected by HotSpot Virtual Machine: > # > # SIGSEGV (0xb) at pc=0x00bf27f3, pid=2633, tid=3086112448 > # > # Java VM: Java HotSpot(TM) Client VM (1.4.2_09-b05 mixed mode) > # Problematic frame: > # C [ld-linux.so.2+0xa7f3] A native library loading error? What happens if you recompile rxtx on your system and install that? This sounds like an ABI problem? rxtx 2.1-7 was compiled with a gcc 2.96 toolchain as I recall. The hope is newer system will be backwards compatible. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Tue Mar 21 11:05:29 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 21 Mar 2006 11:05:29 -0700 (MST) Subject: [Rxtx] PATCH: use of ioctl(fd, TIOCEXCL) instead of lockfiles In-Reply-To: <923AE774-EEA2-4911-92D8-32BB27802C8B@buechse.de> References: <923AE774-EEA2-4911-92D8-32BB27802C8B@buechse.de> Message-ID: On Tue, 21 Mar 2006, Joachim Buechse wrote: > Here is the patch for the ioctl(fd, TIOCEXCL). I have verified this only > for OSX 10.4.5, hence it is only defined for APPLE. However, it should > work at least for Solaris as well. > > If a process has requested TIOEXCL further open calls by other user > processes will fail. > > The patch also disables uucp style locking for APPLE. Obviously this is > discussable. I think it is the way to go, as it eliminates creating the > lock directory which doesnt exist on the standard installation and it > eliminates messing with the system group definitions (adding users to > group uucp). > > Regarding the possibility of root processes opening a device which is > locked - I consider this a feature not a potential problem. It is highly > unlikely, that somebody is crazy enough to run a JavaVM as root (unless > he has no other means of getting a restricted IP port opened, ie doesnt > understand ipfw). Anyway, even if the process runs as root, it fails when > calling ioctl(fd, TIOCEXCL). It could however still open the port to > listen for RING events. I.e. a fax server which needs to see incoming > calls but otherwise doesnt want to block the port. So the only case where > the proposed mechanism fails is, if an incorrectly implemented process > running as root conflicts with a user process. I think this can be > accepted. > > Regards, > Joachim > > PS: If this patch is generally accepted, the installer and Mac doku > should obviously be changed as well. > > > Index: SerialImp.c > =================================================================== > RCS file: /usr/local/cvsroot/rxtx-devel/src/SerialImp.c,v > retrieving revision 1.46.2.187 > diff -u -r1.46.2.187 SerialImp.c > --- SerialImp.c 29 Jan 2006 22:19:04 -0000 1.46.2.187 > +++ SerialImp.c 21 Mar 2006 12:59:16 -0000 > @@ -656,6 +656,25 @@ > fd=OPEN (filename, O_RDWR | O_NOCTTY | O_NONBLOCK ); > } while (fd < 0 && errno==EINTR); > > +#ifdef OPEN_EXCL > + // Note that open() follows POSIX semantics: multiple open() > calls to > + // the same file will succeed unless the TIOCEXCL ioctl is > issued. > + // This will prevent additional opens except by root-owned > processes. > + // See tty(4) ("man 4 tty") and ioctl(2) ("man 2 ioctl") for > details. > + > + if (fd >= 0 && (ioctl(fd, TIOCEXCL) == -1)) > + { > + sprintf( message, "open: exclusive access denied for % > s\n", > + filename ); > + report( message ); > + report_error( message ); > + > + close(fd); > + goto fail; > + } > +#endif /* OPEN_EXCL */ > + > + > if( configure_port( fd ) ) goto fail; > (*env)->ReleaseStringUTFChars( env, jstr, filename ); > sprintf( message, "open: fd returned is %i\n", fd ); > Index: SerialImp.h > =================================================================== > RCS file: /usr/local/cvsroot/rxtx-devel/src/SerialImp.h,v > retrieving revision 1.11.2.49 > diff -u -r1.11.2.49 SerialImp.h > --- SerialImp.h 5 Jul 2005 17:47:21 -0000 1.11.2.49 > +++ SerialImp.h 21 Mar 2006 12:59:17 -0000 > @@ -135,7 +135,8 @@ > /*# define LOCKDIR "/var/spool/uucp"*/ > # define LOCKDIR "/var/lock" > # define LOCKFILEPREFIX "LK." > -# define UUCP > +/*# define UUCP*/ > +# define OPEN_EXCL > #endif /* __APPLE__ */ > #if defined(__NetBSD__) > # define DEVICEDIR "/dev/" > This looks like a good start. What do you think Dmitry? Perhaps all systems with TIOCEXCL defined should use that though. Even if they use lockfiles. It wont hurt anything. That would catch people hacking their own serial apps without checking lockfiles. Its a good idea to avoid C++ style comments in the C portions. Some older systems don't deal with them well. If it's just for Mac OS X, it isn't a big deal. I think it was the Irix compiler that was problematic? -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Tue Mar 21 11:22:05 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 21 Mar 2006 11:22:05 -0700 (MST) Subject: [Rxtx] lock files In-Reply-To: <8E12916A-1B9A-4FF2-B684-E2D1C794221B@buechse.de> References: <8E12916A-1B9A-4FF2-B684-E2D1C794221B@buechse.de> Message-ID: We can try it. Maybe the JNI is much improved. The nice thing about linking into liblock is distros then worry about lockfiles on their systems. This way, we have to deal with any changes that may show up. On Tue, 21 Mar 2006, Joachim Buechse wrote: > This is pretty much what I thought about when I suggested, that the > default behaviour could be overwritten with a property. I am very much in > favor of this approach. In particular this allows much easier debugging > for PC based java developers. > > I think big parts of the Java (and maybe some parts of the C code) could > use a bit of a structural workover (unit tests, javadoc, synchronization, > etc). Maybe there should be a CVS branch for this experimental version. > I'd be happy to contribute a first workover for some of the Java code. > Designing for testability and implementing a good bunch of unit tests has > been a strategy that worked quite well in the Java projects I lead. And > it ultimately allows more liberal change permission. > > Regards, > Joachim > > > On 21.03.2006, at 08:51, Dr. Douglas Lyon wrote: > >> Hi All, >> You know, if the use of lock files were >> under Java control (rather than a build-time decision), >> it might enable a more unified binary distro. It might also >> facilitate quick prototyping of non-lock file approaches >> to resolving serial port contention issues (i.e., mac-like >> approaches vs. linux approaches, etc.). >> >> I realize that this is a radical overhaul of the lock file policy >> issue. Also, it may harm performance. On the other hand, >> our benchmarks on JNI overhead for modern processors indicate >> performance impact should be minimal. Perhaps it is more of >> an issue with the toybox systems. >> >> Suppose there were a class with a reasonable default...someone >> might write: >> SerialPortLockPolicy.setPolicy(SerialPortLockPolicy.UNIX_LOCK_FILE); >> SerialPortLockPolicy.setPolicy(SerialPortLockPolicy.NO_LOCK_CHECKING); >> SerialPortLockPolicy.setPolicy(SerialPortLockPolicy.MAC_STYLE); >> >> Thus, we could have a run-time reconfiguration of the serial port lock >> policy. A special NO_LOCK version of the binary would no longer >> be required. >> >> Any thoughts on this? >> >> Thanks! >> - Doug >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From dmarkman at mac.com Tue Mar 21 16:05:17 2006 From: dmarkman at mac.com (Dmitry Markman) Date: Tue, 21 Mar 2006 18:05:17 -0500 Subject: [Rxtx] PATCH: use of ioctl(fd, TIOCEXCL) instead of lockfiles In-Reply-To: References: <923AE774-EEA2-4911-92D8-32BB27802C8B@buechse.de> Message-ID: <512AC70C-BB86-48F2-A83C-023F35C23BAB@mac.com> I think it's cool, but I'd like to have that property implementation when user can choose between locking mechanism about comments: it's easy to change comments to the C style or we can use extensions of the file to cpp so c++ compiler will be used On Mar 21, 2006, at 1:05 PM, Trent Jarvi wrote: > This looks like a good start. What do you think Dmitry? Perhaps > all systems with TIOCEXCL defined should use that though. Even if > they use lockfiles. It wont hurt anything. That would catch > people hacking their own serial apps without checking lockfiles. > > Its a good idea to avoid C++ style comments in the C portions. > Some older systems don't deal with them well. If it's just for Mac > OS X, it isn't a big deal. I think it was the Irix compiler that > was problematic? Dmitry Markman From dmarkman at mac.com Tue Mar 21 16:13:00 2006 From: dmarkman at mac.com (Dmitry Markman) Date: Tue, 21 Mar 2006 18:13:00 -0500 Subject: [Rxtx] PATCH: use of ioctl(fd, TIOCEXCL) instead of lockfiles In-Reply-To: References: <923AE774-EEA2-4911-92D8-32BB27802C8B@buechse.de> Message-ID: I'd like to add that creating locking folder isn't a big deal we never had a problem related to the lock folders, because we always used installer on mac os x from other hand I'm not very much familiar with iotcl locking approach and I'm not sure it's more efficient Joachim wrote "I think it is the way to go, as it eliminates creating the lock directory which doesnt exist on the standard installation and it eliminates messing with the system group definitions (adding users to group uucp)." but I really didn't have any problem with that 1. doesn't exist on the standard installation there are many-many things that don't exist in the standard installation so I don't think that argument is strong enough 2. messing with the system group definitions I don't think we're messing with the group definition mac os x provides very clear way to set up group's members and together with Greg Guerin AuthKit there is no problem to set those definitions so I don't think that argument is strong either but from other hand using iotcl is more promising and is more elegant On Mar 21, 2006, at 1:05 PM, Trent Jarvi wrote: > > This looks like a good start. What do you think Dmitry? Perhaps > all systems with TIOCEXCL defined should use that though. Even if > they use lockfiles. It wont hurt anything. That would catch > people hacking their own serial apps without checking lockfiles. Dmitry Markman From joachim at buechse.de Wed Mar 22 04:46:45 2006 From: joachim at buechse.de (Joachim Buechse) Date: Wed, 22 Mar 2006 12:46:45 +0100 Subject: [Rxtx] PATCH: use of ioctl(fd, TIOCEXCL) instead of lockfiles In-Reply-To: References: <923AE774-EEA2-4911-92D8-32BB27802C8B@buechse.de> Message-ID: Sorry, I was not very clear with my arguments, so I will try again;-) Please, don't take this as an attack against work that has been done. I think the contributions that have been made in the past were made in a good spirit. But I really believe, that the current solution for OSX has many shortcomings and should be changed as soon as possible. lock files --- The /var/lock folder does not exist on the standard OSX installation, however the standard installation includes several applications that use serial ports (i.e. the FAX capability). This indicates, that the lock folder approach will not work well with system components. Applications for OSX will generally try to live in harmony with system components (except for HP print drivers of course). I think RXTX should follow this approach as well. uucp group --- Accessing serial ports is not an admin privileged operation on OSX. Any user (world) has read/write privileges on /dev/tty*. So the system default is to not enforce any group membership to access these ports. The group uucp however is a system group on all unix systems I know. It exists for certain system processes. A non admin user should in general not be a member of this group. Quite arguably no user should ever be a member of this group. Installer --- My general opinion is, that - no Installer should touch user or group data without warning - no Application Installer should touch groups which are not specific to the very application installed - no Installer should ever add regular users to a system group The current installer injects the installing user in the group uucp without warning about this change and without giving the option to "opt out" of this change. This is a potential security risk (but not currently a real one, as OSX contains no folders belonging to group uucp). The current installer does not work for multi user systems. It puts the installing user in the uucp group. However the installing user is not necessarily the user that will use the application. Putting all users that may use a serial port application in the system group uucp seems like a very invasive approach to me. Besides that, newly created users will not automatically be in the group and hence, serial applications will "break" for new users without obvious reasons. Avoiding the lock files will allow self contained applications (i.e. drag&drop installation). In my eyes this is largely preferable over an installer that requests admin privileges. Adding up all these points indicates very strongly, that the lock-file implementation is not the way to go on OSX. Regards, Joachim On 22.03.2006, at 00:13, Dmitry Markman wrote: > I'd like to add that > > creating locking folder isn't a big deal > we never had a problem related to the lock folders, because we > always used installer on mac os x > from other hand I'm not very much familiar with iotcl locking > approach and I'm not sure it's more efficient > > Joachim wrote "I think it is the way to go, as it eliminates > creating the lock directory which doesnt exist on the standard > installation and it eliminates messing with the system group > definitions (adding users to group uucp)." but I really didn't have > any problem with that > > 1. doesn't exist on the standard installation > there are many-many things that don't exist in the standard > installation so I don't think that argument is strong enough > 2. messing with the system group definitions > I don't think we're messing with the group definition > mac os x provides very clear way to set up group's members and > together with Greg Guerin AuthKit there is no problem to set those > definitions > so I don't think that argument is strong either > but from other hand using iotcl is more promising and is more elegant > > > > On Mar 21, 2006, at 1:05 PM, Trent Jarvi wrote: > >> >> This looks like a good start. What do you think Dmitry? Perhaps >> all systems with TIOCEXCL defined should use that though. Even if >> they use lockfiles. It wont hurt anything. That would catch >> people hacking their own serial apps without checking lockfiles. > > Dmitry Markman > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From dmarkman at mac.com Wed Mar 22 05:27:13 2006 From: dmarkman at mac.com (Dmitry Markman) Date: Wed, 22 Mar 2006 07:27:13 -0500 Subject: [Rxtx] PATCH: use of ioctl(fd, TIOCEXCL) instead of lockfiles In-Reply-To: References: <923AE774-EEA2-4911-92D8-32BB27802C8B@buechse.de> Message-ID: <83440CF3-DCD8-41C1-B941-F227232C27E3@mac.com> thanks for the very good explanation I didn't think that you were attacking any thing, so don't worry I just had feeling, that there were more aesthetic reasons for going to ioctl then real necessity now you explained everything quite well (BTW, asfar as I remember installer asks admin password so it wasn't quiet, but it really doesn't matter now) thanks On Mar 22, 2006, at 6:46 AM, Joachim Buechse wrote: > Sorry, I was not very clear with my arguments, so I will try again;-) > > Please, don't take this as an attack against work that has been > done. I think the contributions that have been made in the past > were made in a good spirit. But I really believe, that the current > solution for OSX has many shortcomings and should be changed as > soon as possible. > > lock files > --- > The /var/lock folder does not exist on the standard OSX > installation, however the standard installation includes several > applications that use serial ports (i.e. the FAX capability). This > indicates, that the lock folder approach will not work well with > system components. Applications for OSX will generally try to live > in harmony with system components (except for HP print drivers of > course). I think RXTX should follow this approach as well. > > uucp group > --- > Accessing serial ports is not an admin privileged operation on OSX. > Any user (world) has read/write privileges on /dev/tty*. So the > system default is to not enforce any group membership to access > these ports. The group uucp however is a system group on all unix > systems I know. It exists for certain system processes. A non admin > user should in general not be a member of this group. Quite > arguably no user should ever be a member of this group. > > Installer > --- > My general opinion is, that > - no Installer should touch user or group data without warning > - no Application Installer should touch groups which are not > specific to the very application installed > - no Installer should ever add regular users to a system group > > The current installer injects the installing user in the group uucp > without warning about this change and without giving the option to > "opt out" of this change. This is a potential security risk (but > not currently a real one, as OSX contains no folders belonging to > group uucp). > > The current installer does not work for multi user systems. It puts > the installing user in the uucp group. However the installing user > is not necessarily the user that will use the application. Putting > all users that may use a serial port application in the system > group uucp seems like a very invasive approach to me. Besides that, > newly created users will not automatically be in the group and > hence, serial applications will "break" for new users without > obvious reasons. > > > Avoiding the lock files will allow self contained applications > (i.e. drag&drop installation). In my eyes this is largely > preferable over an installer that requests admin privileges. Adding > up all these points indicates very strongly, that the lock-file > implementation is not the way to go on OSX. > > Regards, > Joachim > > > On 22.03.2006, at 00:13, Dmitry Markman wrote: > >> I'd like to add that >> >> creating locking folder isn't a big deal >> we never had a problem related to the lock folders, because we >> always used installer on mac os x >> from other hand I'm not very much familiar with iotcl locking >> approach and I'm not sure it's more efficient >> >> Joachim wrote "I think it is the way to go, as it eliminates >> creating the lock directory which doesnt exist on the standard >> installation and it eliminates messing with the system group >> definitions (adding users to group uucp)." but I really didn't >> have any problem with that >> >> 1. doesn't exist on the standard installation >> there are many-many things that don't exist in the standard >> installation so I don't think that argument is strong enough >> 2. messing with the system group definitions >> I don't think we're messing with the group definition >> mac os x provides very clear way to set up group's members and >> together with Greg Guerin AuthKit there is no problem to set those >> definitions >> so I don't think that argument is strong either >> but from other hand using iotcl is more promising and is more elegant >> >> >> >> On Mar 21, 2006, at 1:05 PM, Trent Jarvi wrote: >> >>> >>> This looks like a good start. What do you think Dmitry? Perhaps >>> all systems with TIOCEXCL defined should use that though. Even >>> if they use lockfiles. It wont hurt anything. That would catch >>> people hacking their own serial apps without checking lockfiles. >> >> Dmitry Markman >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx Dmitry Markman From lyon at docjava.com Wed Mar 22 06:12:18 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Wed, 22 Mar 2006 08:12:18 -0500 Subject: [Rxtx] sole of a new design pattern Message-ID: Hi All, I have been thinking about how we design the serial port software. I think we need a new design pattern. For lack of a better term, I shall call it: The Parametric Singleton Design Pattern By Douglas A. Lyon ABSTRACT The goal of the singleton design pattern is to make sure that there is one, and only one, instance of a given class. The goal of the parametric singleton design pattern is to make sure that there is one, and only one, instance of a given class with the given parametric values. We parametric singleton design pattern combines the singleton design pattern with a parameter that enables unique creation of instances of a class. These instances are cached. When a user asks for an instance with these parameters, the cache is checked. If the instance is in the cache, the instance is returned, otherwise it is created, added to the cache and then returned. We apply our parametric singleton design pattern to the retrieval of RMI registries bound to a given port. The goal of our system is to make sure that no two RMI registries are listening to the same socket and to make use of the RMI registries after they have been created. RMI registries are used in distributed computation. Introduction The singleton design pattern is meant to ensure that on a single instance of a class exists. It is also meant to provide a global point of access to it. The intent of the parametric singleton design pattern is to ensure that a class has only one instance for a given set of parameter values. It also provides a global point of access to it. Motivation A system cannot tolerate multiple instances of some classes with identical parameters. For example, you cannot have two instances making use of the same serial port, at the same time. You cannot have two instances that are trying to listen to the same socket connection. You cannot have two instances writing to the same file structure at the same time. As the operating system is often thought of as the arbiter of consumed resources (i.e., tape drives, serial ports, etc.) we frequently leave it to an operating system implementation to resolve these contention issues. Even for similar resources (like serial ports) there are few standards for handling contention. For example, serial ports on Linux are locked using a "/var/lock" file. POSIX, on the other hand, uses ioctl mechanisms to prevent contention. A better solution is to make a class that is responsible for keeping track of the instances created from the class. The class is declared final, so that it cannot be subclassed. The class also has a private constructor, so that other classes cannot instance it. The new design pattern is called the parametric singleton design pattern and it provides a way to access and create instances with given parameters. Applicability Use the Parametric Singleton Design Pattern when: 1. There must be exactly one instance of a class with the given parameters. 2. The instances must be accessible to clients from a well-known access point. Structure Insert UML diagram here. Participants The Parametric Singleton Clients that need instances 1. The Parametric Singleton defines an instance upon request from a client, if, and only if, the instance does not already exist. 2. The Parametric Singleton returns the instance to the client. 3. The Parametric Singleton is responsible for creating unique instances from given parameters. Collaborations Clients obtain a reference to a Parametric Singleton instance only through the parametric singleton design pattern. If the instance is left in an improper state (e.g., the serial port was left open) it is NOT the role of the Parametric Singleton Design Pattern to close the IO port. Nor is it the role of the Parametric Singleton Design Pattern to open the port. That role is delegate to some other part of the system. Further, it is not the role of the Parametric Singleton Design Pattern to check out resources. That is, multiple threads can have multiple references to the same resource at the same time. MUTEX locking is delegated to some other part of the system. Consequences The Parametric Singleton Design Pattern has several benefits: 1. Controlled access to parametrically defined instances. Since the Parametric Singleton class encapsulates its instances, there is control over how and when clients access it. 2. Reduced name space. The Parametric Singleton pattern avoids global variables that store instances created from the same parameter. Implementation Here are implementation issues to consider when using the Parametric Singleton pattern: 1. Unique mapping of parameters. The Parametric Singleton pattern requires that there be a mean to isomorphically map the parameter space into the instance space and back again. 2. Ensure unique instances. The Parametric Singleton pattern makes unique instances from parameters, and it does so only once. 3. Cache instances for fast retrieval. The Parametric Singleton pattern must be able to look up instances, given some set of parameters, and do so from some data structure. That is, there must be enough space to hold references to all the instances the program will need. Also, a mechanism is needed to look up and retrieve the instances quickly enough to satisfy the clients. Sample Code public final class ParametricSingletonRmiRegistry { private static Hashtable registry = new Hashtable(100); // use singleton pattern and??????????????????????????????????????????????? // prevent instantiation of RmiRegistryUtils.?????????????????????????????? private ParametricSingletonRmiRegistry() { } // the only instance of the Registry held by the RmiRegistryUtils?????????? public static void listNames(Integer port) { if (!isInCacheAndRunning(port)) return; Registry r = (Registry) registry.get(port); System.out.println("registry on port: " + port); System.out.println("registry: " + r); System.out.println("names: "); try { print(r.list()); } catch (RemoteException e) { In.message(e); } System.out.println("------------------------"); } /**???????????????????????????????????????????????????????????????????????? * Checks whether a Registry has been started on this host????????????????? * in the specified port.?????????????????????????????????????????????????? * If not, it tries to start one.?????????????????????????????????????????? * when it fails to start a Registry, it exits the program????????????????? * with exit code 1.??????????????????????????????????????????????????????? */ public static void restart(int port) { if (isInCacheAndRunning(port)) return; try { startRegistry(port); } catch (RemoteException e) { In.message(e); } } /**???????????????????????????????????????????????????????????????????????? * @param port????????????????????????????????????????????????????????????? * @return true if registry is in cache and running???????????????????????? */ private static boolean isInCacheAndRunning(Integer port) { if (!isRegistryRunning(port.intValue())) return false; if (!isRegistryInCache(port.intValue())) return false; return true; } /**???????????????????????????????????????????????????????????????????????? * @param port????????????????????????????????????????????????????????????? * @return true if we are able to locate a local registry on port.??????????????????????????????????????????????????????????????????????????? */ private static boolean isRegistryRunning(int port) { try { Registry r = LocateRegistry.getRegistry(port); if (r != null) return true; } catch (RemoteException e) { return false; } return false; } /**???????????????????????????????????????????????????????????????????????? * @param port????????????????????????????????????????????????????????????? * @return return true if registry is in cache????????????????????????????? */ private static boolean isRegistryInCache(int port) { if (registry.get(new Integer(port)) == null) return false; return true; } /**???????????????????????????????????????????????????????????????????????? * Restart the registry, if needed.???????????????????????????????????????? * Return the only instance of the registry for consistent global?????????? * using by making use of the Singleton Design Pattern????????????????????? *????????????????????????????????????????????????????????????????????????? * @return the internally held registry instance.?????????????????????????? */ public static Registry getRegistry(Integer port) { restart(port); return (Registry) registry.get(port); } private static void startRegistry(Integer port) throws RemoteException { Registry r; try { r = LocateRegistry.createRegistry(port.intValue()); registry.put(port, r); //r = new sun.rmi.registry.RegistryImpl???????????????????????????? /// (port.intValue());?????????????????????????????????????? // registry.put(port, r);?????????????????????????????????????????? } catch (Exception e) { //e.printStackTrace();????????????????????????????????????????????? r = LocateRegistry.getRegistry(port.intValue()); registry.put(port, r); } } public static void main(String args[]) throws RemoteException { //restart(port);??????????????????????????????????????????????????????? restart(5001); restart(5002); restart(5002); Registry r = LocateRegistry.getRegistry(5002); System.out.println("registry="+r); } } I would very much like to get your feedback on this new design pattern idea. Thank you for your time. Regards, - Doug From david.garnier at trusted-logic.com Wed Mar 22 07:36:10 2006 From: david.garnier at trusted-logic.com (David Garnier) Date: Wed, 22 Mar 2006 15:36:10 +0100 Subject: [Rxtx] sole of a new design pattern In-Reply-To: References: Message-ID: <442160DA.80107@trusted-logic.com> Hello, > The Parametric Singleton Design Pattern The Singleton is the most abused design pattern ever. Good use-cases for this pattern are extremely rare and mostly confined to problems related to hardware resources, like serial ports. > Applicability > > Use the Parametric Singleton Design Pattern when: > 1. There must be exactly one instance of a class with the given > parameters. OK. As I said above, this case this actually very unusual. The Singleton pattern is mostly used when : > 2. The instances must be accessible to clients from a well-known > access point. Using the singleton pattern in this case is just convenient for the programmer. Problems arises pretty quickly, especially if you attempt to unit-test your classes. 1) If your singleton is stateful, or hold on to stateful objects, it means that two different unit tests are not actually independent. Instead of starting with a brand new environment, the result of a test may be affected by the result of a previous test. This problem also arise when with your class relies on a database. In both cases, the solution is to reset your "unique" resource (Singleton or database) at the beginning of the test, which is a pain. Also, while most projects connect to a single database, projects that allow the use of Singletons usually contain several of thems, and new ones may cropped up unnoticed. You quickly end up with test cases that only pass in a certain order, which is a royal pain. 2) You cannot mockup a singleton. Once everyone calls the SomeSingleton class statically, you can't replace your class by SomeSingletonMockup. Furthermore, even for hardware services, the Singleton pattern does not really prevent concurrent accesses. If you start the same program in two different JVMs, unless they somehow shared the state of their "Singletons" (through lock files for example), the Singleton pattern will not prevent concurrent access. Our application uses RXTX, and we routinely encounter cases where another (native) application has already locked the port. Since we cannot modify the native application to recognize lock files, OS-level control is irreplaceable. > > Consequences > The Parametric Singleton Design Pattern has several benefits: > > 1. Controlled access to parametrically defined instances. Since > the Parametric Singleton class encapsulates its instances, there is > control over how and when clients access it. Not really. Once you've returned the instance to a client, you've lost control over it. The client can to whatever it wants with it. You cannot "recall" the instance or claim it back. > 2. Reduced name space. The Parametric Singleton pattern avoids > global variables that store instances created from the same parameter. Sure, but you don't have to rely on a Singleton for that. Just create a single Factory. > I would very much like to get your feedback on this new design > pattern idea. Well, it's nothing new. Some may say that it is the point of design patterns: formalizes the designs that occur again and again. However, this design is simply a combination of the Singleton and Factory patterns. I did use it in the past, but now I've been exposed to the shortcomings of the Singleton pattern, so I limit myself to Factories. Regards, David From sean_montgomery at baseview.com Wed Mar 22 08:35:28 2006 From: sean_montgomery at baseview.com (Sean Montgomery) Date: Wed, 22 Mar 2006 10:35:28 -0500 Subject: [Rxtx] sole of a new design pattern In-Reply-To: <442160DA.80107@trusted-logic.com> References: <442160DA.80107@trusted-logic.com> Message-ID: <05769CA7-A51B-4CF0-BAA0-E02DD905F5A4@baseview.com> On Mar 22, 2006, at 9:36 AM, David Garnier wrote: > Furthermore, even for hardware services, the Singleton pattern does > not really prevent concurrent > accesses. If you start the same program in two different JVMs, > unless they somehow shared the state > of their "Singletons" (through lock files for example), the > Singleton pattern will not prevent > concurrent access. > Multiple class loaders in a single JVM can be tricky, too. Then there's synchronization, lazy initialization and serialization of singletons to contend with. Bloch's Effective Java covers these, and here's a few articles: http://www.javaworld.com/javaworld/jw-04-2003/jw-0425-designpatterns- p3.html http://java.sun.com/developer/technicalArticles/Programming/singletons/ Just FYI :-) From lyon at docjava.com Wed Mar 22 08:50:48 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Wed, 22 Mar 2006 10:50:48 -0500 Subject: [Rxtx] sole of a new design pattern In-Reply-To: <442160DA.80107@trusted-logic.com> References: <442160DA.80107@trusted-logic.com> Message-ID: Hi All, First, I would like to thank David for his prompt and thoughtful remarks. I had no idea people that feel strongly about a design patterns! Wow! Feedback (particularly critical feedback) is greatly appreciated. Starting at the end, first: >I did use it in >the past, but now I've been exposed to the shortcomings of the >Singleton pattern, so I limit myself to Factories. David, if I understood your comments correctly, you suggested that Factories can be used in leu of the Singleton Design Pattern, or even the Parametric Singleton Design Pattern. As I see in [Gof]: Factory Method: Intent "Define an interface for creating an object, but let subclasses decide which class to instantiate. Factory Method lets a class defer instantiation to subclasses." The Singleton Design Pattern is a concrete class, which is rather different, right? Also, subclasses are not permitted with Singleton, as they are final. Naturally, I could use an abstract factory as a parent for a singleton. I could even design a facade that could be implemented with the singleton....but that is not the intention of the design. Unless you want a mock-up, as discussed, below: More below: >Hello, > >> The Parametric Singleton Design Pattern > >The Singleton is the most abused design pattern ever. Good use-cases >for this pattern are extremely >rare and mostly confined to problems related to hardware resources, >like serial ports. > > >> Applicability >> >> Use the Parametric Singleton Design Pattern when: >> 1. There must be exactly one instance of a class with the given >> parameters. >OK. As I said above, this case this actually very unusual. The >Singleton pattern is mostly used when : >> 2. The instances must be accessible to clients from a well-known >> access point. > >Using the singleton pattern in this case is just convenient for the >programmer. Problems arises >pretty quickly, especially if you attempt to unit-test your classes. > >1) If your singleton is stateful, or hold on to stateful objects, it >means that two different unit >tests are not actually independent. Instead of starting with a brand >new environment, the result of >a test may be affected by the result of a previous test. This >problem also arise when with your >class relies on a database. In both cases, the solution is to reset >your "unique" resource >(Singleton or database) at the beginning of the test, which is a >pain. Also, while most projects >connect to a single database, projects that allow the use of >Singletons usually contain several of >thems, and new ones may cropped up unnoticed. You quickly end up >with test cases that only pass in a >certain order, which is a royal pain. There are basic problems with communicating finite state machines that include reachability and deadlock analysis. These are addressed with petri net analysis and are beyond the scope of the design pattern. As you quite rightly pointed out; the parametric singleton pattern (or the singleton pattern, for that matter) enable multiple threads to gain access to the same instance. The only way that I can see to block others from gaining access to the reference is the synchronize keyword. This is putting a spin-lock (or MUTEX) on the reference. The question of how to unit-test a design pattern like the parametric singleton remains open. Perhaps this is a deficiency. > >2) You cannot mockup a singleton. Once everyone calls the >SomeSingleton class statically, you can't >replace your class by SomeSingletonMockup. Acutally, I am not sure that this is true. If the Singleton implements a Facade interface, it should be possible to make the replacement. Right? > >Furthermore, even for hardware services, the Singleton pattern does >not really prevent concurrent >accesses. If you start the same program in two different JVMs, >unless they somehow shared the state >of their "Singletons" (through lock files for example), the >Singleton pattern will not prevent >concurrent access. Good Point!! You have sharp eyes! The singleton design pattern should/could take responsibility for this. In fact, you may notice that my code does have an implementation (LocateRegistry) that can work across JVM's. The LocateRegistry will even work across the Internet! LocateRegistry takes both a host name and a Port (lock files just don't do this). I did not think to implement this beyond the local machine, but, in its present form, it will work across different processes. > >Our application uses RXTX, and we routinely encounter cases where >another (native) application has >already locked the port. Since we cannot modify the native >application to recognize lock files, >OS-level control is irreplaceable. The singleton design pattern is not meant to replace OS-level control, but to centralize the Java programmers access to it. If lock files, for example, are used for serial ports, the Singleton Design Pattern should be able to work with them. > > >> >> Consequences >> The Parametric Singleton Design Pattern has several benefits: >> > > 1. Controlled access to parametrically defined instances. Since >> the Parametric Singleton class encapsulates its instances, there is >> control over how and when clients access it. > >Not really. Once you've returned the instance to a client, you've >lost control over it. The client >can to whatever it wants with it. You cannot "recall" the instance >or claim it back. Good point, this should read: > 1. Controll when parametrically defined instances are created. Since > > the Parametric Singleton class encapsulates its instances, there is > > control over how and when they are instanced. > >> 2. Reduced name space. The Parametric Singleton pattern avoids >> global variables that store instances created from the same parameter. > >Sure, but you don't have to rely on a Singleton for that. Just >create a single Factory. > > Thank you for your thoughtful and prompt response! Regards, - Doug From dmarkman at mac.com Wed Mar 22 21:21:55 2006 From: dmarkman at mac.com (Dmitry Markman) Date: Wed, 22 Mar 2006 23:21:55 -0500 Subject: [Rxtx] sole of a new design pattern In-Reply-To: <442160DA.80107@trusted-logic.com> References: <442160DA.80107@trusted-logic.com> Message-ID: I don't think I get it On Mar 22, 2006, at 9:36 AM, David Garnier wrote: > Using the singleton pattern in this case is just convenient for the > programmer. Problems arises > pretty quickly, especially if you attempt to unit-test your classes. so you're saying that something isn't so good because you can not test it in the convenient way? if that's true, I'm totally disagree change your test, debug whatever, but if software is efficient at runtime, works fine and only problem is some unit test (which is some kind of framework for testing) then dump that unit test , dump that unit framework and make something appropriate to the software you're testing so if Douglas want to use singletons, what's the problem? and what do you mean by abusing of singleton usage? of course singleton doesn't prevent concurrent access to the resource across the processes unless you're using some OS facility to prevent it, besides singleton as it was introduced is relevant only and only inside of the same process otherwise it's not singleton it's something else (let's say network singleton: so you have remote invocation facility and some factory method that return object created by that facility) I don't have any problem with using any kind of singletons. Parametric Singleton idea (if I understand it right) could be easily implemented in the following way: use a map populate map with instances of some class and key is your parameter (you can use lazy population too) if somebody ask the key check the value if it's null so resource is taken if somebody returns the resource put it back to the map public synchronized static Object getSomeResource(Object parameter); public synchronized static void returnResource(Object parameter); getSomeResource (inside of the same process) could return null in 2 cases 1. if somebody (from other thread for example) already took that resource 2. if OS API said that resource corresponded to that parameter (serial port with parameter = 1 (port #)) is locked and unavailable; I'm not sure that in case of serial ports we even need those Parametric Singletons (unless lock checking is a very expensive operation) just ask the OS about availability of that resource and if it's available give it away and then OS will lock it and therefore in next time somebody ask it just answer that resource is locked and return null for example system has 2 serial ports available so I ask getResource("tty"); or I ask getResource("Bluetooth-Modem"); and if OS is ok you can give tty or Bluetooth-Modem or both no need for any additional pattern I think back to the problem mac os x doesn't recognize locking via files, so it handles locking via some API an instance of the singleton in each process should recognize that resource is locked (by using that API) that's all we don't have to make things more complicate then they are just because there is some nice design pattern or nice unit test framework or whatever keep things simple, make them work fast, don't introduce middle layers unless you have really good reason to do so of course I could be entirely wrong, so sorry about that in advance thanks Dmitry Markman From tjarvi at qbang.org Wed Mar 22 22:31:41 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 22 Mar 2006 22:31:41 -0700 (MST) Subject: [Rxtx] sole of a new design pattern In-Reply-To: References: Message-ID: Hi Doug Interesting reading. So far I'm just reading and thinking. I have one question so far. " Clients obtain a reference to a Parametric Singleton instance only through the parametric singleton design pattern. If the instance is left in an improper state (e.g., the serial port was left open) it is NOT the role of the Parametric Singleton Design Pattern to close the IO port. Nor is it the role of the Parametric Singleton Design Pattern to open the port. That role is delegate to some other part of the system. " So when the clients obtain a reference to the singleton, can they assume the port is there? IE, would it be the singletons role to handle things like USB dongles being removed with event hints comming from the underlying OS. Hardware abstraction layer/HAL on Linux is an example of underlying OS events. I assume that role too is delegated to other parts of the system? -- Trent Jarvi tjarvi at qbang.org From lyon at docjava.com Thu Mar 23 08:10:33 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Thu, 23 Mar 2006 10:10:33 -0500 Subject: [Rxtx] Classes don't need goals, they need roles! In-Reply-To: References: Message-ID: Hi Trent, Yes, I think that the role of the Parametric Singleton Pattern is not to open or close serial ports, nor is it to perform error checking. On the other hand, if you were to combine the role of the Parametric Singleton Pattern with another role (like that of error checking) it might not be amiss. However, I generally caution programmers against adding multiple roles to classes, as this leads to monolithic designs. Thus a different class (NativeLibDetect) could have the role of determining if the native library can be loaded. Another class (SerialPortBean) can have the role of serializing the default state of the serial port, so that it can be recovered, from user preferences, at a later time. The SerialPortDetect could have the role of determining if the serial port is removed (i.e., a USB port was unplugged). My guess is that each class should have a different role in the system, in order to ease maintenance and testing...but I could be wrong about that. Thanks! - Doug >Hi Doug > >Interesting reading. So far I'm just reading and thinking. I have >one question so far. > >" > Clients obtain a reference to a Parametric Singleton instance only >through the parametric singleton design pattern. If the instance is >left in an improper state (e.g., the serial port was left open) it is >NOT the role of the Parametric Singleton Design Pattern to close the >IO port. Nor is it the role of the Parametric Singleton Design Pattern >to >open the port. That role is delegate to some other part of the system. >" > >So when the clients obtain a reference to the singleton, can they >assume the port is there? IE, would it be the singletons role to >handle things like USB dongles being removed with event hints >comming from the underlying OS. Hardware abstraction layer/HAL on >Linux is an example of underlying OS events. > >I assume that role too is delegated to other parts of the system? > >-- >Trent Jarvi >tjarvi at qbang.org >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From maximulo at yahoo.com Fri Mar 24 01:22:38 2006 From: maximulo at yahoo.com (Maximulo Majir) Date: Fri, 24 Mar 2006 00:22:38 -0800 (PST) Subject: [Rxtx] JavaPOS Message-ID: <20060324082238.66371.qmail@web38214.mail.mud.yahoo.com> Hi all! Hello Trent! From what i understand, RXTX or JavaComm APIs were not created solely for JavaPOS. In JavaPOS, we have the virtual method claim() which is separate from open(), but in our RXTX API, claiming is done every call to open(), we cant open the port if its claimed by another application. Would it be alright to suggest or ask to create a new method called claim(..)? Is there such thing as forceclaim() in RXTX? this could be the same as portownership transfer or its equivalent. ForceClaim is in JSR80. Do you have some samples using RXTX as the lower layer for the Device Service Objects in JavaPOS? I have tried it, i just want to compare. Thank you all! maxim __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060324/496adba2/attachment-0021.html From tjarvi at qbang.org Fri Mar 24 11:28:19 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 24 Mar 2006 11:28:19 -0700 (MST) Subject: [Rxtx] Re: RXTX 2.1 Solaris Problems In-Reply-To: <3691.1143210578@www045.gmx.net> References: <3691.1143210578@www045.gmx.net> Message-ID: On Fri, 24 Mar 2006, Andreas Guenther wrote: > Hi all, > > the solaris problem was not the lock file only. > > Ok, I had to create the directory /var/spool/locks myself. > /var/spool/uucp exists. > > But rxtx didn't find any port. > > I compiled the source with my own debug-informations > and I tried to isolate the problem. > > The problem is the testRead-call in SerialImp.c > > JNIEXPORT jboolean JNICALL RXTXCommDriver(testRead)( > > ... > if ( READ( fd, &c, 1 ) < 0 ) > { > if ( errno != EAGAIN ) { > report( "testRead() read failed\n" ); > ret = JNI_FALSE; > } > } > Thanks Andreas I'm packing up to move. I'll be more or less away for a couple weeks here. I'll be checking email but my workstation is going into a box soon. This isn't hard to fix as this port should be enumerated when EWOULDBLOCK is recieved. Thats error is OK for enumeration just as EAGAIN is. I've put the bug into bugzilla so we dont forget to get to it. http://bugzilla.qbang.org/show_bug.cgi?id=42 You can add yourself to the CC list if you wish to test fixes we provide or even put a patch into bugzilla yourself. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Fri Mar 24 11:51:52 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 24 Mar 2006 11:51:52 -0700 (MST) Subject: [Rxtx] JavaPOS In-Reply-To: <20060324082238.66371.qmail@web38214.mail.mud.yahoo.com> References: <20060324082238.66371.qmail@web38214.mail.mud.yahoo.com> Message-ID: On Fri, 24 Mar 2006, Maximulo Majir wrote: > Hi all! Hello Trent! > > > From what i understand, RXTX or JavaComm APIs were not > created solely for JavaPOS. In JavaPOS, we have the virtual method > claim() which is separate from open(), but in our RXTX API, claiming is > done every call to open(), we cant open the port if its claimed by > another application. Would it be alright to suggest or ask to create a > new method called claim(..)? Is there such thing as forceclaim() in > RXTX? this could be the same as portownership transfer or its > equivalent. ForceClaim is in JSR80. > Do you have some samples using RXTX as the lower layer for the Device > Service Objects in JavaPOS? I have tried it, i just want to compare. > maxim Hi Maxim JSR80 is the USB API IBM/Sun put together. The problem is they have a richer kernel/API underneath that can handle such things. With Serial Ports, there isnt anything there other than an ioctl that says don't let anyone touch this and lockfiles that are more of a 'lets be nice.' At times we may be using USB ports but it is through the termios layer with the limitations mentioned. The advantage is that not only USB will work with rxtx. Anything that has a termios layer should work (to the extent that termios layer is complete). I don't know how forceclaim() would help you. Lets say someone has a programmer working on /dev/ttyS0 and you take it. Now you both race each other to read data first. There isn't a mechanism I know of that will solve this problem in termios. The most obvious test being a native app and a Java app trying to take the port. There is the potential of requestion ownership from other Java Applications but the use for that is very rare. Did you have something more specific in mind that I'm missing? I'm not sure that claim() and forceclaim() would help you with rxtx other than maybe locking the port with claim() without opening it. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sat Mar 25 23:42:08 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 25 Mar 2006 23:42:08 -0700 (MST) Subject: [Rxtx] Serial snoop Message-ID: I was reading the Linux kernel mail-list tonight and ran past a thread that mentioned sersnoop. This looks like a handy tool for people dealing with new toys. "a simple command-line tool for linux that echoes bytes to and from any two serial ports, ptys, or network sockets, and prints all traffic to stdout, in hex and ascii." http://www.restivo.org/projects/sersnoop/ It works on Linux only at this time (debian package available). -- Trent Jarvi tjarvi at qbang.org From beat.arnet at gmail.com Sun Mar 26 07:32:35 2006 From: beat.arnet at gmail.com (Beat Arnet) Date: Sun, 26 Mar 2006 09:32:35 -0500 Subject: [Rxtx] Error 0x5 at /home/bob/foo/tar/rxtx-2.1-7/build/../src/termios.c(860): Access is, denied. Message-ID: <4426A603.80508@gmail.com> Dear all, When trying to open the serial port, I sometimes (not always) run into the following exception (when opening the serialPort): Error 0x5 at /home/bob/foo/tar/rxtx-2.1-7/build/../src/termios.c(860): Access is denied. java.lang.UnsatisfiedLinkError: native_psmisc_report_owner at gnu.io.CommPortIdentifier.native_psmisc_report_owner(Native Method) at gnu.io.CommPortIdentifier.open(CommPortIdentifier.java:354) at codeskin.tools.CLLoader.open(CLLoader.java:79) at codeskin.tools.C2000Programmer.run(C2000Programmer.java:220) at java.lang.Thread.run(Unknown Source) Is this the type of error where I should just try to open the port again, or can it be avoided? Regards, Beat From tjarvi at qbang.org Sun Mar 26 11:40:12 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 26 Mar 2006 11:40:12 -0700 (MST) Subject: [Rxtx] Error 0x5 at /home/bob/foo/tar/rxtx-2.1-7/build/../src/termios.c(860): Access is, denied. In-Reply-To: <4426A603.80508@gmail.com> References: <4426A603.80508@gmail.com> Message-ID: On Sun, 26 Mar 2006, Beat Arnet wrote: > Dear all, > > When trying to open the serial port, I sometimes (not always) run into > the following exception (when opening the serialPort): > > Error 0x5 at /home/bob/foo/tar/rxtx-2.1-7/build/../src/termios.c(860): > Access is > denied. > > java.lang.UnsatisfiedLinkError: native_psmisc_report_owner > at gnu.io.CommPortIdentifier.native_psmisc_report_owner(Native > Method) > at gnu.io.CommPortIdentifier.open(CommPortIdentifier.java:354) > at codeskin.tools.CLLoader.open(CLLoader.java:79) > at codeskin.tools.C2000Programmer.run(C2000Programmer.java:220) > at java.lang.Thread.run(Unknown Source) > > Is this the type of error where I should just try to open the port again, > or can it be avoided? > Hi Beat We did a second build of rxtx 2.1-7 to resolve that unsatisfied link error. It should work now. rxtx is trying to tell you it thinks someone else has the serial port open. You can try to open the port again but maybe you already have a copy of the program running when it happens? ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7r2.zip fixed build. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sun Mar 26 11:44:23 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 26 Mar 2006 11:44:23 -0700 (MST) Subject: [Rxtx] RXTX spec file (fwd) Message-ID: This is probably interesting for fedora/suse users. ---------- Forwarded message ---------- Date: Sun, 26 Mar 2006 16:25:45 +0200 To: taj at www.linux.org.uk Subject: RXTX spec file I send you this spec file which allows to create a RPM for Fedora 4, 5 (x86, x86_64) with Java Sun. -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: rxtx.spec Url: http://mailman.qbang.org/pipermail/rxtx/attachments/20060326/6c7b6af6/rxtx-0017.pl From tjarvi at qbang.org Sun Mar 26 23:42:59 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 26 Mar 2006 23:42:59 -0700 (MST) Subject: [Rxtx] Upcomming events. Message-ID: This Wednesday we will be announcing a new "Maintainer" for the rxtx project. The position is more like neutral leader. I wont be going away or doing less. This is just the right thing to do as it turns out the two people with CVS write access will be at the same company. We need a third and we need neutrality. The maintainer will have final say in any conflict and will try to be neutral. It will be open for discussion. Then we will do it :) I'll still do most of the footwork I do now. But. I'm falling behind. I should have gone through the mail-list and posted the next round of changes this weekend. I'm packing to move and its going so so - 13 years of toys collected. I suspect there will be a dead period on my part (a couple weeks) comming up. But if you get it on the mail-list, we will get it in if there are no objections. I may well not be reading the mail-list during this period as I look for a house and many other things. I hope everyone will help out. Thanks -- Trent Jarvi tjarvi at qbang.org From mahmoud_hadad at yahoo.com Sun Mar 26 07:31:19 2006 From: mahmoud_hadad at yahoo.com (ronan nick) Date: Sun, 26 Mar 2006 06:31:19 -0800 (PST) Subject: [Rxtx] a question about the COMM API Message-ID: <20060326143119.54919.qmail@web60014.mail.yahoo.com> hi, i was intrested in knowing how i can communicate with my internal modem using java? for example if i want to make a phone dialer application or a caller id application where should i be looking at? and as i understood the COMM API is for devices that is attached to the computer through serial ports. --------------------------------- New Yahoo! Messenger with Voice. Call regular phones from your PC and save big. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060326/ce8329f0/attachment-0019.html From dmarkman at mac.com Mon Mar 20 00:20:43 2006 From: dmarkman at mac.com (Dmitry Markman) Date: Mon, 20 Mar 2006 02:20:43 -0500 Subject: [Rxtx] Mac OS X RXTX java installer In-Reply-To: References: <07D0DE29-BA32-4CFE-B036-66BC6423D385@buechse.de> <441AE3E0.2030503@willicon.de> <12531986.1142622114996.JavaMail.dmarkman@mac.com> <441B2674.9010409@willicon.de> <13577405.1142634732776.JavaMail.dmarkman@mac.com> <441B4182.8010407@willicon.de> <92CD0D6C-5BE8-426E-A46D-99452059FF49@mac.com> <441BBB2D.8030305@willicon.de> <441C4088.5090905@willicon.de> Message-ID: <64BC1E23-FDDE-4CE6-8863-CFC881CBC224@mac.com> Hi all I put RXTX installer that will install everything (and will create / var/lock if necessary and add user to the uucp group) for mac os x from Java into the rxtx's CVS repository it could be easily modified to install files for any platform it uses Greg Guerin's AuthKit for authentication and authorization Greg released that kit under artistic license, so Trent, please take a look we, probably, can negotiate license with Greg if it's necessary Greg's AuthKit could be downloaded from http://www.amug.org/~glguerin/ sw/#authkit Michael Hall (mikehall at spacestar dot net) had a suggestion to make implementation of the jaas LoginModule based on Greg's AuthKit (his modification of the Greg's AuthKit could be found at http:// www.spacestar.net/users/mikehall/authkit.dmg) but Michael's AuthKitLoginModule does only half a job: it does authenticate but it can not run any external unix process in privileged mode (at least I wasn't able to do so) possible explanation could be found in conversation between Greg and Michael at Apple's java-dev list (look for archives) so I didn't use jaas API for rxtxinstaller I created folder MacOSX in the contrib folder comment 1. if you want to run that installer as standalone application all you need that RXTXInstaller.jar 2. if you want to use webstart you have to add Greg's libAuthKit.jnilib to the mac os x's resources in theory RXTXInstaller.jar doesn't need it, but there is a problem with loading libAuthKit.jnilib from webstart authkit uses loadLibrary method to load library and it failed (from webstart) for standalone application I extract libAuthKit.jnilib from the RXTXInstaller.jar and put it into the /Library/Java/Extensions or ~/Library/Java/Extensions folder that file will be deleted after installer quit unfortunately I didn't have time to put documentation there but it is mostly self-explanatory I took installer code from my gl4java installer that I did about 3 years ago (with small modifications) it would be very nice if Apple will release LoginModule that really will do the job (com.apple.security.auth.module package????? ) (UnixLoginModule is pretty useless) From lyon at docjava.com Mon Mar 20 06:34:39 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Mon, 20 Mar 2006 08:34:39 -0500 Subject: [Rxtx] Mac OS X RXTX java installer In-Reply-To: <64BC1E23-FDDE-4CE6-8863-CFC881CBC224@mac.com> References: <07D0DE29-BA32-4CFE-B036-66BC6423D385@buechse.de> <441AE3E0.2030503@willicon.de> <12531986.1142622114996.JavaMail.dmarkman@mac.com> <441B2674.9010409@willicon.de> <13577405.1142634732776.JavaMail.dmarkman@mac.com> <441B4182.8010407@willicon.de> <92CD0D6C-5BE8-426E-A46D-99452059FF49@mac.com> <441BBB2D.8030305@willicon.de> <441C4088.5090905@willicon.de> <64BC1E23-FDDE-4CE6-8863-CFC881CBC224@mac.com> Message-ID: Hi Dimitry, This sounds like great work. Just a couple of questions; After the check out of the CVS files, using: setenv CVSROOT :pserver:anonymous at cvs.milestonesolutions.com:/usr/local/cvsroot 53 8:28 setenv PASSWORD mousy 54 8:29 cvs login 55 8:29 cvs checkout rxtx-devel I cd'd over to: rxtx-devel/MACOSX_IDE And found: CVS/ CW/ ForPackageMaker/ PB/ Where is the installer? Thanks! - Doug From tjarvi at qbang.org Mon Mar 20 06:39:37 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 20 Mar 2006 06:39:37 -0700 (MST) Subject: [Rxtx] Mac OS X RXTX java installer In-Reply-To: References: <07D0DE29-BA32-4CFE-B036-66BC6423D385@buechse.de> <441AE3E0.2030503@willicon.de> <12531986.1142622114996.JavaMail.dmarkman@mac.com> <441B2674.9010409@willicon.de> <13577405.1142634732776.JavaMail.dmarkman@mac.com> <441B4182.8010407@willicon.de> <92CD0D6C-5BE8-426E-A46D-99452059FF49@mac.com> <441BBB2D.8030305@willicon.de> <441C4088.5090905@willicon.de> <64BC1E23-FDDE-4CE6-8863-CFC881CBC224@mac.com> Message-ID: On Mon, 20 Mar 2006, Dr. Douglas Lyon wrote: > Hi Dimitry, > This sounds like great work. Just a couple of questions; > After the check out of the CVS files, using: > setenv CVSROOT > :pserver:anonymous at cvs.milestonesolutions.com:/usr/local/cvsroot > 53 8:28 setenv PASSWORD mousy > 54 8:29 cvs login > 55 8:29 cvs checkout rxtx-devel Hi Doug You want "cvs checkout -r commapi-0-0-1 rxtx-devel" to get RXTX 2.1 The default branch is rxtx 2.0 which isn't very active right now. -- Trent Jarvi tjarvi at qbang.org From lyon at docjava.com Mon Mar 20 07:05:44 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Mon, 20 Mar 2006 09:05:44 -0500 Subject: [Rxtx] Mac OS X RXTX java installer In-Reply-To: References: <07D0DE29-BA32-4CFE-B036-66BC6423D385@buechse.de> <441AE3E0.2030503@willicon.de> <12531986.1142622114996.JavaMail.dmarkman@mac.com> <441B2674.9010409@willicon.de> <13577405.1142634732776.JavaMail.dmarkman@mac.com> <441B4182.8010407@willicon.de> <92CD0D6C-5BE8-426E-A46D-99452059FF49@mac.com> <441BBB2D.8030305@willicon.de> <441C4088.5090905@willicon.de> <64BC1E23-FDDE-4CE6-8863-CFC881CBC224@mac.com> Message-ID: Hi Trent, Thanks for the info on the CVS checkout procedure. I did that and am still not sure where the installer is. Here is what I have: cd MACOSX_IDE/ p4.docjava.com{lyon}121: ls CVS/ ForPackageMaker/ PB/ p4.docjava.com{lyon}122: find . | more . ./ForPackageMaker ./ForPackageMaker/RXTX.pkg.sit.hqx ./ForPackageMaker/Resources ./ForPackageMaker/Resources/ReadMe.rtf ./ForPackageMaker/Resources/Welcome.rtf ./ForPackageMaker/Resources/CVS ./ForPackageMaker/Resources/CVS/Entries ./ForPackageMaker/Resources/CVS/Repository ./ForPackageMaker/Resources/CVS/Tag ./ForPackageMaker/Resources/CVS/Root ./ForPackageMaker/Resources/preinstall ./ForPackageMaker/Resources/License.rtf ./ForPackageMaker/Resources/preupgrade ./ForPackageMaker/RXTX.pmsp ./ForPackageMaker/CVS ./ForPackageMaker/CVS/Entries ./ForPackageMaker/CVS/Repository ./ForPackageMaker/CVS/Entries.Log ./ForPackageMaker/CVS/Tag ./ForPackageMaker/CVS/Root ./ForPackageMaker/RXTX_Tiger.pkg.sitx.hqx ./ForPackageMaker/RXTX_Jag.pkg.sit.hqx ./ForPackageMaker/Install ./ForPackageMaker/Install/CVS ./ForPackageMaker/Install/CVS/Entries ./ForPackageMaker/Install/CVS/Repository ./ForPackageMaker/Install/CVS/Tag ./ForPackageMaker/Install/CVS/Root ./ForPackageMaker/Install/Library ./ForPackageMaker/Install/Library/CVS ./ForPackageMaker/Install/Library/CVS/Entries ./ForPackageMaker/Install/Library/CVS/Repository ./ForPackageMaker/Install/Library/CVS/Tag ./ForPackageMaker/Install/Library/CVS/Root ./ForPackageMaker/Install/Library/Java ./ForPackageMaker/Install/Library/Java/Extensions ./ForPackageMaker/Install/Library/Java/Extensions/RXTXcomm.jar ./ForPackageMaker/Install/Library/Java/Extensions/CVS ./ForPackageMaker/Install/Library/Java/Extensions/CVS/Entries ./ForPackageMaker/Install/Library/Java/Extensions/CVS/Repository ./ForPackageMaker/Install/Library/Java/Extensions/CVS/Tag ./ForPackageMaker/Install/Library/Java/Extensions/CVS/Root ./ForPackageMaker/Install/Library/Java/Extensions/librxtxSerial.jnilib ./ForPackageMaker/Install/Library/Java/CVS ./ForPackageMaker/Install/Library/Java/CVS/Entries ./ForPackageMaker/Install/Library/Java/CVS/Repository ./ForPackageMaker/Install/Library/Java/CVS/Entries.Log ./ForPackageMaker/Install/Library/Java/CVS/Tag ./ForPackageMaker/Install/Library/Java/CVS/Root ./ForPackageMaker/RXTX_Tiger.pmproj.sitx.hqx ./CVS ./CVS/Entries ./CVS/Repository ./CVS/Entries.Log ./CVS/Tag ./CVS/Root ./PB ./PB/LibSerialUniversal.xcodeproj.sitx.hqx ./PB/CVS ./PB/CVS/Entries ./PB/CVS/Repository ./PB/CVS/Entries.Log ./PB/CVS/Tag ./PB/CVS/Root ./PB/LibSerial.pbproj.sit.hqx ./PB/startpoint.c ./PB/config.h What is the procedure to run this installer? Do we need a README in: /rxtx-devel/MACOSX_IDE Here is what we have: CVS/ ForPackageMaker/ PB/ Thanks! - DL >On Mon, 20 Mar 2006, Dr. Douglas Lyon wrote: > >>Hi Dimitry, >>This sounds like great work. Just a couple of questions; >>After the check out of the CVS files, using: >>setenv CVSROOT >>:pserver:anonymous at cvs.milestonesolutions.com:/usr/local/cvsroot >> 53 8:28 setenv PASSWORD mousy >> 54 8:29 cvs login >> 55 8:29 cvs checkout rxtx-devel > >Hi Doug > >You want "cvs checkout -r commapi-0-0-1 rxtx-devel" to get RXTX 2.1 >The default branch is rxtx 2.0 which isn't very active right now. > >-- >Trent Jarvi >tjarvi at qbang.org From tjarvi at qbang.org Mon Mar 20 07:25:30 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 20 Mar 2006 07:25:30 -0700 (MST) Subject: [Rxtx] Mac OS X RXTX java installer In-Reply-To: References: <07D0DE29-BA32-4CFE-B036-66BC6423D385@buechse.de> <441AE3E0.2030503@willicon.de> <12531986.1142622114996.JavaMail.dmarkman@mac.com> <441B2674.9010409@willicon.de> <13577405.1142634732776.JavaMail.dmarkman@mac.com> <441B4182.8010407@willicon.de> <92CD0D6C-5BE8-426E-A46D-99452059FF49@mac.com> <441BBB2D.8030305@willicon.de> <441C4088.5090905@willicon.de> <64BC1E23-FDDE-4CE6-8863-CFC881CBC224@mac.com> Message-ID: On Mon, 20 Mar 2006, Dr. Douglas Lyon wrote: > Hi Trent, > Thanks for the info on the CVS checkout procedure. > I did that and am still not sure where the installer is. Hi Doug It does look like it was not cvs committed. There is no rxtx-devel/contrib/MacOSX directory in there at the moment. It was mentioned that it was put under contrib. -- Trent Jarvi tjarvi at qbang.org From dmarkman at mac.com Mon Mar 20 07:29:56 2006 From: dmarkman at mac.com (Dmitry Markman) Date: Mon, 20 Mar 2006 09:29:56 -0500 Subject: [Rxtx] Mac OS X RXTX java installer In-Reply-To: References: <07D0DE29-BA32-4CFE-B036-66BC6423D385@buechse.de> <441AE3E0.2030503@willicon.de> <12531986.1142622114996.JavaMail.dmarkman@mac.com> <441B2674.9010409@willicon.de> <13577405.1142634732776.JavaMail.dmarkman@mac.com> <441B4182.8010407@willicon.de> <92CD0D6C-5BE8-426E-A46D-99452059FF49@mac.com> <441BBB2D.8030305@willicon.de> <441C4088.5090905@willicon.de> <64BC1E23-FDDE-4CE6-8863-CFC881CBC224@mac.com> Message-ID: <6054EB4E-F7E0-4A9C-BDDA-D582D6D8826F@mac.com> you can find it in the rxtx-devel/contrib folder On Mar 20, 2006, at 9:05 AM, Dr. Douglas Lyon wrote: > Hi Trent, > Thanks for the info on the CVS checkout procedure. > I did that and am still not sure where the installer is. > Here is what I have: > cd MACOSX_IDE/ > p4.docjava.com{lyon}121: ls > CVS/ ForPackageMaker/ PB/ > p4.docjava.com{lyon}122: find . | more > . > ./ForPackageMaker > ./ForPackageMaker/RXTX.pkg.sit.hqx > ./ForPackageMaker/Resources > ./ForPackageMaker/Resources/ReadMe.rtf > ./ForPackageMaker/Resources/Welcome.rtf > ./ForPackageMaker/Resources/CVS > ./ForPackageMaker/Resources/CVS/Entries > ./ForPackageMaker/Resources/CVS/Repository > ./ForPackageMaker/Resources/CVS/Tag > ./ForPackageMaker/Resources/CVS/Root > ./ForPackageMaker/Resources/preinstall > ./ForPackageMaker/Resources/License.rtf > ./ForPackageMaker/Resources/preupgrade > ./ForPackageMaker/RXTX.pmsp > ./ForPackageMaker/CVS > ./ForPackageMaker/CVS/Entries > ./ForPackageMaker/CVS/Repository > ./ForPackageMaker/CVS/Entries.Log > ./ForPackageMaker/CVS/Tag > ./ForPackageMaker/CVS/Root > ./ForPackageMaker/RXTX_Tiger.pkg.sitx.hqx > ./ForPackageMaker/RXTX_Jag.pkg.sit.hqx > ./ForPackageMaker/Install > ./ForPackageMaker/Install/CVS > ./ForPackageMaker/Install/CVS/Entries > ./ForPackageMaker/Install/CVS/Repository > ./ForPackageMaker/Install/CVS/Tag > ./ForPackageMaker/Install/CVS/Root > ./ForPackageMaker/Install/Library > ./ForPackageMaker/Install/Library/CVS > ./ForPackageMaker/Install/Library/CVS/Entries > ./ForPackageMaker/Install/Library/CVS/Repository > ./ForPackageMaker/Install/Library/CVS/Tag > ./ForPackageMaker/Install/Library/CVS/Root > ./ForPackageMaker/Install/Library/Java > ./ForPackageMaker/Install/Library/Java/Extensions > ./ForPackageMaker/Install/Library/Java/Extensions/RXTXcomm.jar > ./ForPackageMaker/Install/Library/Java/Extensions/CVS > ./ForPackageMaker/Install/Library/Java/Extensions/CVS/Entries > ./ForPackageMaker/Install/Library/Java/Extensions/CVS/Repository > ./ForPackageMaker/Install/Library/Java/Extensions/CVS/Tag > ./ForPackageMaker/Install/Library/Java/Extensions/CVS/Root > ./ForPackageMaker/Install/Library/Java/Extensions/librxtxSerial.jnilib > ./ForPackageMaker/Install/Library/Java/CVS > ./ForPackageMaker/Install/Library/Java/CVS/Entries > ./ForPackageMaker/Install/Library/Java/CVS/Repository > ./ForPackageMaker/Install/Library/Java/CVS/Entries.Log > ./ForPackageMaker/Install/Library/Java/CVS/Tag > ./ForPackageMaker/Install/Library/Java/CVS/Root > ./ForPackageMaker/RXTX_Tiger.pmproj.sitx.hqx > ./CVS > ./CVS/Entries > ./CVS/Repository > ./CVS/Entries.Log > ./CVS/Tag > ./CVS/Root > ./PB > ./PB/LibSerialUniversal.xcodeproj.sitx.hqx > ./PB/CVS > ./PB/CVS/Entries > ./PB/CVS/Repository > ./PB/CVS/Entries.Log > ./PB/CVS/Tag > ./PB/CVS/Root > ./PB/LibSerial.pbproj.sit.hqx > ./PB/startpoint.c > ./PB/config.h > > What is the procedure to run this installer? > Do we need a README in: > /rxtx-devel/MACOSX_IDE > Here is what we have: > CVS/ ForPackageMaker/ PB/ > > > Thanks! > - DL > >> On Mon, 20 Mar 2006, Dr. Douglas Lyon wrote: >> >>> Hi Dimitry, >>> This sounds like great work. Just a couple of questions; >>> After the check out of the CVS files, using: >>> setenv CVSROOT :pserver:anonymous at cvs.milestonesolutions.com:/usr/ >>> local/cvsroot >>> 53 8:28 setenv PASSWORD mousy >>> 54 8:29 cvs login >>> 55 8:29 cvs checkout rxtx-devel >> >> Hi Doug >> >> You want "cvs checkout -r commapi-0-0-1 rxtx-devel" to get RXTX 2.1 >> The default branch is rxtx 2.0 which isn't very active right now. >> >> -- >> Trent Jarvi >> tjarvi at qbang.org > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx Dmitry Markman From mikehall at spacestar.net Mon Mar 20 05:25:25 2006 From: mikehall at spacestar.net (Michael Hall) Date: Mon, 20 Mar 2006 06:25:25 -0600 Subject: [Rxtx] Re: Mac OS X RXTX java installer In-Reply-To: <64BC1E23-FDDE-4CE6-8863-CFC881CBC224@mac.com> References: <07D0DE29-BA32-4CFE-B036-66BC6423D385@buechse.de> <441AE3E0.2030503@willicon.de> <12531986.1142622114996.JavaMail.dmarkman@mac.com> <441B2674.9010409@willicon.de> <13577405.1142634732776.JavaMail.dmarkman@mac.com> <441B4182.8010407@willicon.de> <92CD0D6C-5BE8-426E-A46D-99452059FF49@mac.com> <441BBB2D.8030305@willicon.de> <441C4088.5090905@willicon.de> <64BC1E23-FDDE-4CE6-8863-CFC881CBC224@mac.com> Message-ID: <247EB61F-5CD1-4132-89A2-FC105B6CF9A5@spacestar.net> On Mar 20, 2006, at 1:20 AM, Dmitry Markman wrote: > > Michael Hall (mikehall at spacestar dot net) had a suggestion to > make implementation of the jaas LoginModule > based on Greg's AuthKit > (his modification of the Greg's AuthKit could be found at http:// > www.spacestar.net/users/mikehall/authkit.dmg) > but Michael's AuthKitLoginModule does only half a job: > it does authenticate > but it can not run any external unix process in privileged mode (at > least I wasn't able to do so) If you got it working directly with Greg's the point is moot. But to clarify it anyhow. The login module does not allow you to do anything anything privileged on return as was explained by Greg. You need to work with a separate privileged process using the execPrivileged method of his API. I assume you did something similar although I haven't looked at how you are using it yet. I allowed instead for a action to be performed at the same time you login/authenticate,this... System.setProperty("authkit.action","/usr/bin/id"); just before this... lc.login(); To clarify, safely ignored as you are already complete. Mike Hall mikehall at spacestar dot net http://www.spacestar.net/users/mikehall http://sourceforge.net/projects/macnative -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2427 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20060320/f6e18202/smime-0022.bin From dmarkman at mac.com Mon Mar 20 07:36:47 2006 From: dmarkman at mac.com (Dmitry Markman) Date: Mon, 20 Mar 2006 09:36:47 -0500 Subject: [Rxtx] Re: Mac OS X RXTX java installer In-Reply-To: <247EB61F-5CD1-4132-89A2-FC105B6CF9A5@spacestar.net> References: <07D0DE29-BA32-4CFE-B036-66BC6423D385@buechse.de> <441AE3E0.2030503@willicon.de> <12531986.1142622114996.JavaMail.dmarkman@mac.com> <441B2674.9010409@willicon.de> <13577405.1142634732776.JavaMail.dmarkman@mac.com> <441B4182.8010407@willicon.de> <92CD0D6C-5BE8-426E-A46D-99452059FF49@mac.com> <441BBB2D.8030305@willicon.de> <441C4088.5090905@willicon.de> <64BC1E23-FDDE-4CE6-8863-CFC881CBC224@mac.com> <247EB61F-5CD1-4132-89A2-FC105B6CF9A5@spacestar.net> Message-ID: Hi, Michael all I have to do is to run some shell script I tried to use your action mechanism and it worked great so I just System.setProperty ("authkit.action","" ) and after that I even don't need to run anything like subject.doAs.... but after few thoughts I choose to use plain Greg's approach, because in that case I don't have to deal with various java's configurations files and therefore to use 2-3 -D parameters in the java command line especially it's useful for java web start (it's so fragile :-( ) thanks for the great job On Mar 20, 2006, at 7:25 AM, Michael Hall wrote: > > On Mar 20, 2006, at 1:20 AM, Dmitry Markman wrote: >> >> Michael Hall (mikehall at spacestar dot net) had a suggestion to >> make implementation of the jaas LoginModule >> based on Greg's AuthKit >> (his modification of the Greg's AuthKit could be found at http:// >> www.spacestar.net/users/mikehall/authkit.dmg) >> but Michael's AuthKitLoginModule does only half a job: >> it does authenticate >> but it can not run any external unix process in privileged mode >> (at least I wasn't able to do so) > > If you got it working directly with Greg's the point is moot. > > But to clarify it anyhow. > The login module does not allow you to do anything anything > privileged on return as was explained by Greg. You need to work > with a separate privileged process using the execPrivileged method > of his API. I assume you did something similar although I haven't > looked at how you are using it yet. > I allowed instead for a action to be performed at the same time you > login/authenticate,this... > System.setProperty("authkit.action","/usr/bin/id"); > just before this... > lc.login(); > To clarify, safely ignored as you are already complete. > > Mike Hall mikehall at spacestar dot net > http://www.spacestar.net/users/mikehall > http://sourceforge.net/projects/macnative > > > Dmitry Markman From dmarkman at mac.com Mon Mar 20 07:44:45 2006 From: dmarkman at mac.com (Dmitry Markman) Date: Mon, 20 Mar 2006 09:44:45 -0500 Subject: [Rxtx] Mac OS X RXTX java installer In-Reply-To: References: <07D0DE29-BA32-4CFE-B036-66BC6423D385@buechse.de> <441AE3E0.2030503@willicon.de> <12531986.1142622114996.JavaMail.dmarkman@mac.com> <441B2674.9010409@willicon.de> <13577405.1142634732776.JavaMail.dmarkman@mac.com> <441B4182.8010407@willicon.de> <92CD0D6C-5BE8-426E-A46D-99452059FF49@mac.com> <441BBB2D.8030305@willicon.de> <441C4088.5090905@willicon.de> <64BC1E23-FDDE-4CE6-8863-CFC881CBC224@mac.com> Message-ID: it's in the commapi-0-0-1 branch I tested it right now: cvs co -r commapi-0-0-1 rxtx-devel and I got everything On Mar 20, 2006, at 9:25 AM, Trent Jarvi wrote: > On Mon, 20 Mar 2006, Dr. Douglas Lyon wrote: > >> Hi Trent, >> Thanks for the info on the CVS checkout procedure. >> I did that and am still not sure where the installer is. > > Hi Doug > > It does look like it was not cvs committed. There is no rxtx-devel/ > contrib/MacOSX directory in there at the moment. It was mentioned > that it was put under contrib. > > -- > Trent Jarvi > tjarvi at qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx Dmitry Markman From tjarvi at qbang.org Mon Mar 20 07:52:57 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 20 Mar 2006 07:52:57 -0700 (MST) Subject: [Rxtx] Mac OS X RXTX java installer In-Reply-To: References: <07D0DE29-BA32-4CFE-B036-66BC6423D385@buechse.de> <441AE3E0.2030503@willicon.de> <12531986.1142622114996.JavaMail.dmarkman@mac.com> <441B2674.9010409@willicon.de> <13577405.1142634732776.JavaMail.dmarkman@mac.com> <441B4182.8010407@willicon.de> <92CD0D6C-5BE8-426E-A46D-99452059FF49@mac.com> <441BBB2D.8030305@willicon.de> <441C4088.5090905@willicon.de> <64BC1E23-FDDE-4CE6-8863-CFC881CBC224@mac.com> Message-ID: On Mon, 20 Mar 2006, Dmitry Markman wrote: > it's in the commapi-0-0-1 branch > > I tested it right now: > cvs co -r commapi-0-0-1 rxtx-devel > > and I got everything > A fresh checkout worked. Here is a copy of the tree (just the installer bits) ftp://ftp.qbang.org/pub/rxtx/MacOSX-installer.zip -- Trent Jarvi tjarvi at qbang.org From lyon at docjava.com Mon Mar 20 08:08:26 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Mon, 20 Mar 2006 10:08:26 -0500 Subject: [Rxtx] Mac OS X RXTX java installer In-Reply-To: References: <07D0DE29-BA32-4CFE-B036-66BC6423D385@buechse.de> <441AE3E0.2030503@willicon.de> <12531986.1142622114996.JavaMail.dmarkman@mac.com> <441B2674.9010409@willicon.de> <13577405.1142634732776.JavaMail.dmarkman@mac.com> <441B4182.8010407@willicon.de> <92CD0D6C-5BE8-426E-A46D-99452059FF49@mac.com> <441BBB2D.8030305@willicon.de> <441C4088.5090905@willicon.de> <64BC1E23-FDDE-4CE6-8863-CFC881CBC224@mac.com> Message-ID: Hi All, Is the Auth package able to work properly on non Mac OS's? It was not clear from the doc or download. Thanks! - Doug From dmarkman at mac.com Mon Mar 20 08:15:22 2006 From: dmarkman at mac.com (Dmitry Markman) Date: Mon, 20 Mar 2006 10:15:22 -0500 Subject: [Rxtx] Mac OS X RXTX java installer In-Reply-To: References: <07D0DE29-BA32-4CFE-B036-66BC6423D385@buechse.de> <441AE3E0.2030503@willicon.de> <12531986.1142622114996.JavaMail.dmarkman@mac.com> <441B2674.9010409@willicon.de> <13577405.1142634732776.JavaMail.dmarkman@mac.com> <441B4182.8010407@willicon.de> <92CD0D6C-5BE8-426E-A46D-99452059FF49@mac.com> <441BBB2D.8030305@willicon.de> <441C4088.5090905@willicon.de> <64BC1E23-FDDE-4CE6-8863-CFC881CBC224@mac.com> Message-ID: <217312D8-CCCA-4859-ABA6-32DF1CC817B9@mac.com> thanks Trent, for putting it on ftp server On Mar 20, 2006, at 9:52 AM, Trent Jarvi wrote: > A fresh checkout worked. Here is a copy of the tree (just the > installer bits) > > ftp://ftp.qbang.org/pub/rxtx/MacOSX-installer.zip > Dmitry Markman From dmarkman at mac.com Mon Mar 20 09:14:03 2006 From: dmarkman at mac.com (Dmitry Markman) Date: Mon, 20 Mar 2006 11:14:03 -0500 Subject: [Rxtx] Mac OS X RXTX java installer In-Reply-To: References: <07D0DE29-BA32-4CFE-B036-66BC6423D385@buechse.de> <441AE3E0.2030503@willicon.de> <12531986.1142622114996.JavaMail.dmarkman@mac.com> <441B2674.9010409@willicon.de> <13577405.1142634732776.JavaMail.dmarkman@mac.com> <441B4182.8010407@willicon.de> <92CD0D6C-5BE8-426E-A46D-99452059FF49@mac.com> <441BBB2D.8030305@willicon.de> <441C4088.5090905@willicon.de> <64BC1E23-FDDE-4CE6-8863-CFC881CBC224@mac.com> Message-ID: <4DEBA6F0-DA45-4E84-823E-1F1AC48BDCCC@mac.com> no it will work only on mac os x however it's harmless to run it on other platform if you want to use it for other platform you have to do the following (I'll do it for linux) 1. modify RXTXInstaller class method public static RXTXInstaller getInstance() public static RXTXInstaller getInstance() { String osName = System.getProperty("os.name").toLowerCase(); if(osName.startsWith("mac")){ return new gnu.io.installer.macosx.MACOSXRXTXInstaller(); } else if(osName.startsWith("windows")){ return new gnu.io.installer.windows.WindowsRXTXInstaller(); }else if(osName.startsWith("linux")){ return new gnu.io.installer.linux.LinuxRXTXInstaller(); } return null; } 2. create folder gnu/io/installer/linux/ 3. create class Linux386RXTXInstaller package gnu.io.installer.linux; import java.io.File; public class Linux386RXTXInstaller extends gnu.io.installer.RXTXInstaller{ public Linux386RXTXInstaller(){ createJarFolder(); createLibFolder(); addJarResource("RXTXcomm.jar","/gnu/io/installer/resources/ linux/jar/RXTXcomm.dat"); addLibResource("librxtxSerial.so","/gnu/io/installer/ resources/linux/lib/librxtxSerial.so"); } protected void createJarFolder(){ String javaHome = System.getProperty("java.home"); char separator = File.separatorChar; jarFolder = new File(javaHome+separator+"lib"+separator+"ext"); } protected void createLibFolder(){ String javaHome = System.getProperty("java.home"); char separator = File.separatorChar; libFolder = new File(javaHome+separator+"bin"); } public void runPreProcess() {} //put here some action you need public void runPostProcess() {} //put here some action you need } 4. create folder /gnu/io/installer/resources/linux/jar and put there linux's version of RXTXcomm.dat (which is renamed RXTXcomm.jar) 5. create folder /gnu/io/installer/resources/linux/lib and put there linux's version of librxtxSerial. so 6. make sure that RXTXInstaller.jar has the following items: /gnu/io/installer/resources/linux/jar/RXTXcomm.jar /gnu/io/installer/resources/linux/lib/librxtxSerial.so 7. modify file installer.pref: jar file RXTXInstaller.jar must have the following item /gnu/io/installer/installer.pref that's basically it for windows you have to do the similar things: just replace linux to windows and librxtxSerial.so to rxtxSerial.dll and create appropriate gnu.io.installer.windows.WindowsRXTXInstaller class package gnu.io.installer.windows; import java.io.File; public class WindowsRXTXInstaller extends gnu.io.installer.RXTXInstaller{ public WindowsRXTXInstaller(){ createJarFolder(); createLibFolder(); addJarResource("RXTXcomm.jar","/gnu/io/installer/resources/ windows/jar/RXTXcomm.dat"); addLibResource("librxtxSerial.so","/gnu/io/installer/ resources/windows/lib/rxtxSerial.dll"); } protected void createJarFolder(){ String javaHome = System.getProperty("java.home"); char separator = File.separatorChar; jarFolder = new File(javaHome+separator+"lib"+separator+"ext"); } protected void createLibFolder(){ String javaHome = System.getProperty("java.home"); char separator = File.separatorChar; libFolder = new File(javaHome+separator+"bin"); } public void runPreProcess() {} //put here some action you need public void runPostProcess() {} //put here some action you need } installer.pref will look like On Mar 20, 2006, at 10:08 AM, Dr. Douglas Lyon wrote: > Hi All, > Is the Auth package able to work properly on > non Mac OS's? > It was not clear from the doc or download. > > Thanks! > - Doug > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx Dmitry Markman From joachim at buechse.de Mon Mar 20 10:49:06 2006 From: joachim at buechse.de (Joachim Buechse) Date: Mon, 20 Mar 2006 18:49:06 +0100 Subject: [Rxtx] BUG: Lock file stays even if port opening fails Message-ID: This was only tested on MacOSX but looking at the code, it should be true for all systems that use lock_uucp. I am opening a port which can not be opened (dialup port of a telephone paired via bluetooth but currently not reachable). The lock file is created and stays arround, even though the port open failed. After looking a bit through the code (of 2.17), I really wonder if it wouldn't be a good idea to make the "locking" an explicit operation called from the java code. This would certainly simplify the generation of meaningfull exceptions (and java based debugging). Maybe even the handling of "preopened" ports should be in the Java part of the lib (again for java based debugging puposes). That beeing said, I have no idea if this would be possible for the 2.07 implementation. Regards, Joachim From tjarvi at qbang.org Mon Mar 20 11:24:22 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 20 Mar 2006 11:24:22 -0700 (MST) Subject: [Rxtx] BUG: Lock file stays even if port opening fails In-Reply-To: References: Message-ID: On Mon, 20 Mar 2006, Joachim Buechse wrote: > This was only tested on MacOSX but looking at the code, it should be true > for all systems that use lock_uucp. > > I am opening a port which can not be opened (dialup port of a telephone > paired via bluetooth but currently not reachable). The lock file is > created and stays arround, even though the port open failed. > > > After looking a bit through the code (of 2.17), I really wonder if it > wouldn't be a good idea to make the "locking" an explicit operation > called from the java code. This would certainly simplify the generation > of meaningfull exceptions (and java based debugging). > Maybe even the handling of "preopened" ports should be in the Java part > of the lib (again for java based debugging puposes). That beeing said, I > have no idea if this would be possible for the 2.07 implementation. > > Regards, Hi Joachim It should be possible in the 2.0-7 implementation too. The calls to RXTXPort.java would not change. We would just do more there Moving more of that logic into Java would be better as many people don't like to look at C code. There is a liblockdev on most Linux distros that can do most of the C code and would be easier to use. The problem is embeded devices will not have that library. The preopened port code has not been really tested. That was a last minute request in a product cycle. I expect it will be tested this year though. As I recall, some devices really do not like CD raising on open. The preopened ports then allow people to mess around in java without power cycling the devices or losing data. -- Trent Jarvi tjarvi at qbang.org From joachim at buechse.de Mon Mar 20 12:01:08 2006 From: joachim at buechse.de (Joachim Buechse) Date: Mon, 20 Mar 2006 20:01:08 +0100 Subject: [Rxtx] BUG: Lock file stays even if port opening fails In-Reply-To: References: Message-ID: Hi Trent, What is your general feeling about moving code to Java? The last days I have been reading quite a bit of the code and there are several things, that might not work as expected. I'll give you two examples from is_device_locked: if LOCKDIR == /var/spool/locks the directory /var/spool/lock will not be checked. LOCKDIR is not checked for lockfiles with unexpected pefixes While these things have probably never been discovered in production, they are still possibly incorrect implementations. If it was Java code, I would write some unit tests producing the errors that could later be corrected. PS: One could imagine to actually implement the whole lockfile handling in Java using some native routines to get the values required (pid, st_dev, st_rdev, ...). On 20.03.2006, at 19:24, Trent Jarvi wrote: > On Mon, 20 Mar 2006, Joachim Buechse wrote: > >> This was only tested on MacOSX but looking at the code, it should >> be true for all systems that use lock_uucp. >> >> I am opening a port which can not be opened (dialup port of a >> telephone paired via bluetooth but currently not reachable). The >> lock file is created and stays arround, even though the port open >> failed. >> >> >> After looking a bit through the code (of 2.17), I really wonder if >> it wouldn't be a good idea to make the "locking" an explicit >> operation called from the java code. This would certainly simplify >> the generation of meaningfull exceptions (and java based debugging). >> Maybe even the handling of "preopened" ports should be in the Java >> part of the lib (again for java based debugging puposes). That >> beeing said, I have no idea if this would be possible for the 2.07 >> implementation. >> >> Regards, > > Hi Joachim > > It should be possible in the 2.0-7 implementation too. The calls > to RXTXPort.java would not change. We would just do more there > Moving more of that logic into Java would be better as many people > don't like to look at C code. There is a liblockdev on most Linux > distros that can do most of the C code and would be easier to use. > The problem is embeded devices will not have that library. > > The preopened port code has not been really tested. That was a > last minute request in a product cycle. I expect it will be tested > this year though. As I recall, some devices really do not like CD > raising on open. The preopened ports then allow people to mess > around in java without power cycling the devices or losing data. > > -- > Trent Jarvi > tjarvi at qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Mon Mar 20 12:21:02 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 20 Mar 2006 12:21:02 -0700 (MST) Subject: [Rxtx] BUG: Lock file stays even if port opening fails In-Reply-To: References: Message-ID: On Mon, 20 Mar 2006, Joachim Buechse wrote: > Hi Trent, > > What is your general feeling about moving code to Java? The last days I > have been reading quite a bit of the code and there are several things, > that might not work as expected. > > I'll give you two examples from is_device_locked: > > if LOCKDIR == /var/spool/locks the directory /var/spool/lock will not be > checked. > LOCKDIR is not checked for lockfiles with unexpected pefixes > > While these things have probably never been discovered in production, > they are still possibly incorrect implementations. If it was Java code, I > would write some unit tests producing the errors that could later be > corrected. > > PS: One could imagine to actually implement the whole lockfile handling > in Java using some native routines to get the values required (pid, > st_dev, st_rdev, ...). Hi Joachim I like the idea of moving more of the code into java but there are some things to consider. If you break this into multiple JNI calls, the performance will drop considerably during enumeration of ports. We are looking for 256 ports per dev type vs (16? in Sun's 2.0 and fewer types). Its hard to make assumptions. I've seen virtual ports start at /dev/foo100 for instance. It works out to over 7500 ports on Linux if you enable them all. We already trim that back by default. See Linux-all-ports in RXTXCommDriver.java. There are also native libraries that rxtx can link to. If you move too much into Java, linking to 'standard' libraries with distros will break. "configure --enable-liblock=yes" will not be doable. This is probably a favorable way with RedHat, Debian, Suse and others. Thats the right thing to do if there will be rpms, dpkg, .. For those reasons, I think it still make sense to keep it to a minimal ~3 calls to JNI code that we can use for speed and versatility. lock() isLocked(), unlock() perhaps. When I say speed, its more about avoiding crossing the JNI layer multiple times than java vs C performance. With versatility I think liblock is the right way for most but not all (embeded) linux distros. -- Trent Jarvi tjarvi at qbang.org From joachim at buechse.de Mon Mar 20 12:42:04 2006 From: joachim at buechse.de (Joachim Buechse) Date: Mon, 20 Mar 2006 20:42:04 +0100 Subject: [Rxtx] BUG: Lock file stays even if port opening fails In-Reply-To: References: Message-ID: <82C19FE7-DDCB-45B6-B2C9-7606B66F0124@buechse.de> Ok, what about providing a default implementation in Java? The RXTXCommDriver would call a (native) function useNativeLocking and if it returns true, call the native functions for lock() isLocked (), unlock(), else is would use the Java based default implementation. This could possibly be overriden by a property (again for debugging). Joachim On 20.03.2006, at 20:21, Trent Jarvi wrote: > On Mon, 20 Mar 2006, Joachim Buechse wrote: > >> Hi Trent, >> >> What is your general feeling about moving code to Java? The last >> days I have been reading quite a bit of the code and there are >> several things, that might not work as expected. >> >> I'll give you two examples from is_device_locked: >> >> if LOCKDIR == /var/spool/locks the directory /var/spool/lock will >> not be checked. >> LOCKDIR is not checked for lockfiles with unexpected pefixes >> >> While these things have probably never been discovered in >> production, they are still possibly incorrect implementations. If >> it was Java code, I would write some unit tests producing the >> errors that could later be corrected. >> >> PS: One could imagine to actually implement the whole lockfile >> handling in Java using some native routines to get the values >> required (pid, st_dev, st_rdev, ...). > > Hi Joachim > > I like the idea of moving more of the code into java but there are > some things to consider. > > If you break this into multiple JNI calls, the performance will > drop considerably during enumeration of ports. We are looking for > 256 ports per dev type vs (16? in Sun's 2.0 and fewer types). Its > hard to make assumptions. I've seen virtual ports start at /dev/ > foo100 for instance. > > It works out to over 7500 ports on Linux if you enable them all. > We already trim that back by default. See Linux-all-ports in > RXTXCommDriver.java. > > There are also native libraries that rxtx can link to. If you move > too much into Java, linking to 'standard' libraries with distros > will break. "configure --enable-liblock=yes" will not be doable. > This is probably a favorable way with RedHat, Debian, Suse and > others. Thats the right thing to do if there will be rpms, dpkg, .. > > For those reasons, I think it still make sense to keep it to a > minimal ~3 calls to JNI code that we can use for speed and > versatility. lock() isLocked(), unlock() perhaps. When I say > speed, its more about avoiding crossing the JNI layer multiple > times than java vs C performance. With versatility I think liblock > is the right way for most but not all (embeded) linux distros. > > -- > Trent Jarvi > tjarvi at qbang.org > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Mon Mar 20 12:44:47 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 20 Mar 2006 12:44:47 -0700 (MST) Subject: [Rxtx] BUG: Lock file stays even if port opening fails In-Reply-To: <82C19FE7-DDCB-45B6-B2C9-7606B66F0124@buechse.de> References: <82C19FE7-DDCB-45B6-B2C9-7606B66F0124@buechse.de> Message-ID: On Mon, 20 Mar 2006, Joachim Buechse wrote: > Ok, what about providing a default implementation in Java? > > The RXTXCommDriver would call a (native) function useNativeLocking and if > it returns true, call the native functions for lock() isLocked(), > unlock(), else is would use the Java based default implementation. This > could possibly be overriden by a property (again for debugging). > Hi Joachim That would be OK with me. -- Trent Jarvi tjarvi at qbang.org From dmarkman at mac.com Mon Mar 20 22:27:45 2006 From: dmarkman at mac.com (Dmitry Markman) Date: Tue, 21 Mar 2006 00:27:45 -0500 Subject: [Rxtx] binaries request Message-ID: <42702213-C222-4937-A585-7CFB17E47608@mac.com> Hi can somebody send me latest linux and windows binaries, please? or where I can find them (I didn't find them in the latest tareball) I gave up with my cygwin: something wrong I have no idea what java doesn't understand /cygwin/c syntax after I changed makefile it did java part but after that gcc 3.4.4 started to complain I set buffer length to 999 lines but I didn't get beginning of the story something wrong with my 1.4.2_09/include/jni.h gcc doesn't like it anyway I gave up thanks in advance Dmitry Markman -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060320/f8cbc57c/attachment-0022.html From tjarvi at qbang.org Mon Mar 20 22:36:48 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 20 Mar 2006 22:36:48 -0700 (MST) Subject: [Rxtx] binaries request In-Reply-To: <42702213-C222-4937-A585-7CFB17E47608@mac.com> References: <42702213-C222-4937-A585-7CFB17E47608@mac.com> Message-ID: On Tue, 21 Mar 2006, Dmitry Markman wrote: > Hi > can somebody send me latest linux and windows binaries, please? > > or where I can find them (I didn't find them in the latest tareball) > > I gave up with my cygwin: something wrong I have no idea what > java doesn't understand /cygwin/c syntax > after I changed makefile it did java part > but after that gcc 3.4.4 started to complain > I set buffer length to 999 lines but I didn't get beginning of the story > something wrong with my 1.4.2_09/include/jni.h gcc doesn't like it > anyway I gave up > > thanks in advance > Hi Dmitry The bins are here: ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7-bins-r2.zip Here are the files in the zip you want. Jar: rxtx-2.1-7-bins-r2/RXTXcomm.jar Windows: rxtx-2.1-7-bins-r2/Windows/i368-mingw32/rxtxSerial.dll Linux (x86) rxtx-2.1-7-bins-r2/Linux/i686-unknown-linux-gnu/librxtxSerial.so There are others in there including Parallel port support but those are the main ones for testing. -- Trent Jarvi tjarvi at qbang.org From dmarkman at mac.com Mon Mar 20 23:05:59 2006 From: dmarkman at mac.com (Dmitry Markman) Date: Tue, 21 Mar 2006 01:05:59 -0500 Subject: [Rxtx] binaries request In-Reply-To: References: <42702213-C222-4937-A585-7CFB17E47608@mac.com> Message-ID: thank you very much but windows's readme says: rxtxSerial.dll had to be recomopiled to link in missing native methods. should I ignore it? or what? thanks again also I understand that I should use mingw not cygwin I'll try to install mingw On Mar 21, 2006, at 12:36 AM, Trent Jarvi wrote: > On Tue, 21 Mar 2006, Dmitry Markman wrote: > >> Hi >> can somebody send me latest linux and windows binaries, please? >> >> or where I can find them (I didn't find them in the latest tareball) >> >> I gave up with my cygwin: something wrong I have no idea what >> java doesn't understand /cygwin/c syntax >> after I changed makefile it did java part >> but after that gcc 3.4.4 started to complain >> I set buffer length to 999 lines but I didn't get beginning of the >> story >> something wrong with my 1.4.2_09/include/jni.h gcc doesn't like it >> anyway I gave up >> >> thanks in advance >> > > Hi Dmitry > > The bins are here: > > ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7-bins-r2.zip > > Here are the files in the zip you want. > > Jar: > > rxtx-2.1-7-bins-r2/RXTXcomm.jar > > Windows: > > rxtx-2.1-7-bins-r2/Windows/i368-mingw32/rxtxSerial.dll > > Linux (x86) > > rxtx-2.1-7-bins-r2/Linux/i686-unknown-linux-gnu/librxtxSerial.so > > There are others in there including Parallel port support but those > are the main ones for testing. > > -- > Trent Jarvi > tjarvi at qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx Dmitry Markman From tjarvi at qbang.org Mon Mar 20 23:20:33 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 20 Mar 2006 23:20:33 -0700 (MST) Subject: [Rxtx] binaries request In-Reply-To: References: <42702213-C222-4937-A585-7CFB17E47608@mac.com> Message-ID: On Tue, 21 Mar 2006, Dmitry Markman wrote: > thank you very much > > but windows's readme says: > rxtxSerial.dll had to be recomopiled to link in missing native methods. > > should I ignore it? or what? > Hi Dmitry That dll should be OK. r2 is the recompile linked to the missing native method. The readme explains why it was recompiled; fuser.o was not linked into the dll in the first release. -- Trent Jarvi tjarvi at qbang.org From ariantristan at yahoo.com Mon Mar 20 23:55:24 2006 From: ariantristan at yahoo.com (Lambok Sianturi) Date: Mon, 20 Mar 2006 22:55:24 -0800 (PST) Subject: [Rxtx] jvm issue Message-ID: <20060321065524.94779.qmail@web50701.mail.yahoo.com> Hi All, This is my first time to join RxTx mailing list. I thank you all for allowing others to sign in in requests help. I use the latest RxTx lib in Fedora 3 with java version 1.4.2_09 b05. And I got this error: # # An unexpected error has been detected by HotSpot Virtual Machine: # # SIGSEGV (0xb) at pc=0x00bf27f3, pid=2633, tid=3086112448 # # Java VM: Java HotSpot(TM) Client VM (1.4.2_09-b05 mixed mode) # Problematic frame: # C [ld-linux.so.2+0xa7f3] # # An error report file with more information is saved as hs_err_pid2633.log # # If you would like to submit a bug report, please visit: # http://java.sun.com/webapps/bugreport/crash.jsp # ./run.sh: line 3: 2633 Aborted /usr/local/java/bin/java -Djava.library.path=/usr/local/java/jre/lib/ -Djsmsengine.debug=true -classpath jsmsengine.jar:smsgateway.jar:classes12.jar:RXTXcomm.jar:. com.api.sms.SMSServer What is the jvm depedency for the latest library? Can I use 1.4.2_09 b05? Thanks in advance. Arian --------------------------------- Yahoo! Mail Use Photomail to share photos without annoying attachments. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060320/83d58dd7/attachment-0022.html From f.frumento at ngi.it Tue Mar 21 00:21:47 2006 From: f.frumento at ngi.it (Fabio Frumento) Date: Tue, 21 Mar 2006 08:21:47 +0100 Subject: [Rxtx] Javadoc on the go Message-ID: <441FA98B.9050701@ngi.it> Hi Trent, sorry for the big delay but my job is running wild, i was out for some time but now i'm back and ready to continue the javadoc for Rxtx. Did you used the last javadoc patch i sent you ? let me know if i have to send it to you again or not. regards Fabio From lyon at docjava.com Tue Mar 21 00:51:18 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Tue, 21 Mar 2006 02:51:18 -0500 Subject: [Rxtx] lock files Message-ID: Hi All, You know, if the use of lock files were under Java control (rather than a build-time decision), it might enable a more unified binary distro. It might also facilitate quick prototyping of non-lock file approaches to resolving serial port contention issues (i.e., mac-like approaches vs. linux approaches, etc.). I realize that this is a radical overhaul of the lock file policy issue. Also, it may harm performance. On the other hand, our benchmarks on JNI overhead for modern processors indicate performance impact should be minimal. Perhaps it is more of an issue with the toybox systems. Suppose there were a class with a reasonable default...someone might write: SerialPortLockPolicy.setPolicy(SerialPortLockPolicy.UNIX_LOCK_FILE); SerialPortLockPolicy.setPolicy(SerialPortLockPolicy.NO_LOCK_CHECKING); SerialPortLockPolicy.setPolicy(SerialPortLockPolicy.MAC_STYLE); Thus, we could have a run-time reconfiguration of the serial port lock policy. A special NO_LOCK version of the binary would no longer be required. Any thoughts on this? Thanks! - Doug From joachim at buechse.de Tue Mar 21 03:09:09 2006 From: joachim at buechse.de (Joachim Buechse) Date: Tue, 21 Mar 2006 11:09:09 +0100 Subject: [Rxtx] lock files In-Reply-To: References: Message-ID: <8E12916A-1B9A-4FF2-B684-E2D1C794221B@buechse.de> This is pretty much what I thought about when I suggested, that the default behaviour could be overwritten with a property. I am very much in favor of this approach. In particular this allows much easier debugging for PC based java developers. I think big parts of the Java (and maybe some parts of the C code) could use a bit of a structural workover (unit tests, javadoc, synchronization, etc). Maybe there should be a CVS branch for this experimental version. I'd be happy to contribute a first workover for some of the Java code. Designing for testability and implementing a good bunch of unit tests has been a strategy that worked quite well in the Java projects I lead. And it ultimately allows more liberal change permission. Regards, Joachim On 21.03.2006, at 08:51, Dr. Douglas Lyon wrote: > Hi All, > You know, if the use of lock files were > under Java control (rather than a build-time decision), > it might enable a more unified binary distro. It might also > facilitate quick prototyping of non-lock file approaches > to resolving serial port contention issues (i.e., mac-like > approaches vs. linux approaches, etc.). > > I realize that this is a radical overhaul of the lock file policy > issue. Also, it may harm performance. On the other hand, > our benchmarks on JNI overhead for modern processors indicate > performance impact should be minimal. Perhaps it is more of > an issue with the toybox systems. > > Suppose there were a class with a reasonable default...someone > might write: > SerialPortLockPolicy.setPolicy(SerialPortLockPolicy.UNIX_LOCK_FILE); > SerialPortLockPolicy.setPolicy(SerialPortLockPolicy.NO_LOCK_CHECKING); > SerialPortLockPolicy.setPolicy(SerialPortLockPolicy.MAC_STYLE); > > Thus, we could have a run-time reconfiguration of the serial port lock > policy. A special NO_LOCK version of the binary would no longer > be required. > > Any thoughts on this? > > Thanks! > - Doug > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From joachim at buechse.de Tue Mar 21 06:23:08 2006 From: joachim at buechse.de (Joachim Buechse) Date: Tue, 21 Mar 2006 14:23:08 +0100 Subject: [Rxtx] PATCH: use of ioctl(fd, TIOCEXCL) instead of lockfiles Message-ID: <923AE774-EEA2-4911-92D8-32BB27802C8B@buechse.de> Here is the patch for the ioctl(fd, TIOCEXCL). I have verified this only for OSX 10.4.5, hence it is only defined for APPLE. However, it should work at least for Solaris as well. If a process has requested TIOEXCL further open calls by other user processes will fail. The patch also disables uucp style locking for APPLE. Obviously this is discussable. I think it is the way to go, as it eliminates creating the lock directory which doesnt exist on the standard installation and it eliminates messing with the system group definitions (adding users to group uucp). Regarding the possibility of root processes opening a device which is locked - I consider this a feature not a potential problem. It is highly unlikely, that somebody is crazy enough to run a JavaVM as root (unless he has no other means of getting a restricted IP port opened, ie doesnt understand ipfw). Anyway, even if the process runs as root, it fails when calling ioctl(fd, TIOCEXCL). It could however still open the port to listen for RING events. I.e. a fax server which needs to see incoming calls but otherwise doesnt want to block the port. So the only case where the proposed mechanism fails is, if an incorrectly implemented process running as root conflicts with a user process. I think this can be accepted. Regards, Joachim PS: If this patch is generally accepted, the installer and Mac doku should obviously be changed as well. Index: SerialImp.c =================================================================== RCS file: /usr/local/cvsroot/rxtx-devel/src/SerialImp.c,v retrieving revision 1.46.2.187 diff -u -r1.46.2.187 SerialImp.c --- SerialImp.c 29 Jan 2006 22:19:04 -0000 1.46.2.187 +++ SerialImp.c 21 Mar 2006 12:59:16 -0000 @@ -656,6 +656,25 @@ fd=OPEN (filename, O_RDWR | O_NOCTTY | O_NONBLOCK ); } while (fd < 0 && errno==EINTR); +#ifdef OPEN_EXCL + // Note that open() follows POSIX semantics: multiple open() calls to + // the same file will succeed unless the TIOCEXCL ioctl is issued. + // This will prevent additional opens except by root-owned processes. + // See tty(4) ("man 4 tty") and ioctl(2) ("man 2 ioctl") for details. + + if (fd >= 0 && (ioctl(fd, TIOCEXCL) == -1)) + { + sprintf( message, "open: exclusive access denied for % s\n", + filename ); + report( message ); + report_error( message ); + + close(fd); + goto fail; + } +#endif /* OPEN_EXCL */ + + if( configure_port( fd ) ) goto fail; (*env)->ReleaseStringUTFChars( env, jstr, filename ); sprintf( message, "open: fd returned is %i\n", fd ); Index: SerialImp.h =================================================================== RCS file: /usr/local/cvsroot/rxtx-devel/src/SerialImp.h,v retrieving revision 1.11.2.49 diff -u -r1.11.2.49 SerialImp.h --- SerialImp.h 5 Jul 2005 17:47:21 -0000 1.11.2.49 +++ SerialImp.h 21 Mar 2006 12:59:17 -0000 @@ -135,7 +135,8 @@ /*# define LOCKDIR "/var/spool/uucp"*/ # define LOCKDIR "/var/lock" # define LOCKFILEPREFIX "LK." -# define UUCP +/*# define UUCP*/ +# define OPEN_EXCL #endif /* __APPLE__ */ #if defined(__NetBSD__) # define DEVICEDIR "/dev/" From tjarvi at qbang.org Tue Mar 21 10:26:08 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 21 Mar 2006 10:26:08 -0700 (MST) Subject: [Rxtx] Javadoc on the go In-Reply-To: <441FA98B.9050701@ngi.it> References: <441FA98B.9050701@ngi.it> Message-ID: On Tue, 21 Mar 2006, Fabio Frumento wrote: > Hi Trent, > > sorry for the big delay but my job is running wild, i was out for some > time but now i'm back and ready to continue the javadoc for Rxtx. > > Did you used the last javadoc patch i sent you ? let me know if i have to > send it to you again or not. > > regards > > Fabio Hi Fabio The patch is in the rxtx mail-list archives. It will be going in soon. I did not see a time critical portion. I'll probably be going through the list since the last batch of patches this weekend and putting them into CVS. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Tue Mar 21 10:57:18 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 21 Mar 2006 10:57:18 -0700 (MST) Subject: [Rxtx] jvm issue In-Reply-To: <20060321065524.94779.qmail@web50701.mail.yahoo.com> References: <20060321065524.94779.qmail@web50701.mail.yahoo.com> Message-ID: On Mon, 20 Mar 2006, Lambok Sianturi wrote: > Hi All, > This is my first time to join RxTx mailing list. I thank you all for allowing others to sign in in requests help. > I use the latest RxTx lib in Fedora 3 with java version 1.4.2_09 b05. And I got this error: > > # > # An unexpected error has been detected by HotSpot Virtual Machine: > # > # SIGSEGV (0xb) at pc=0x00bf27f3, pid=2633, tid=3086112448 > # > # Java VM: Java HotSpot(TM) Client VM (1.4.2_09-b05 mixed mode) > # Problematic frame: > # C [ld-linux.so.2+0xa7f3] A native library loading error? What happens if you recompile rxtx on your system and install that? This sounds like an ABI problem? rxtx 2.1-7 was compiled with a gcc 2.96 toolchain as I recall. The hope is newer system will be backwards compatible. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Tue Mar 21 11:05:29 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 21 Mar 2006 11:05:29 -0700 (MST) Subject: [Rxtx] PATCH: use of ioctl(fd, TIOCEXCL) instead of lockfiles In-Reply-To: <923AE774-EEA2-4911-92D8-32BB27802C8B@buechse.de> References: <923AE774-EEA2-4911-92D8-32BB27802C8B@buechse.de> Message-ID: On Tue, 21 Mar 2006, Joachim Buechse wrote: > Here is the patch for the ioctl(fd, TIOCEXCL). I have verified this only > for OSX 10.4.5, hence it is only defined for APPLE. However, it should > work at least for Solaris as well. > > If a process has requested TIOEXCL further open calls by other user > processes will fail. > > The patch also disables uucp style locking for APPLE. Obviously this is > discussable. I think it is the way to go, as it eliminates creating the > lock directory which doesnt exist on the standard installation and it > eliminates messing with the system group definitions (adding users to > group uucp). > > Regarding the possibility of root processes opening a device which is > locked - I consider this a feature not a potential problem. It is highly > unlikely, that somebody is crazy enough to run a JavaVM as root (unless > he has no other means of getting a restricted IP port opened, ie doesnt > understand ipfw). Anyway, even if the process runs as root, it fails when > calling ioctl(fd, TIOCEXCL). It could however still open the port to > listen for RING events. I.e. a fax server which needs to see incoming > calls but otherwise doesnt want to block the port. So the only case where > the proposed mechanism fails is, if an incorrectly implemented process > running as root conflicts with a user process. I think this can be > accepted. > > Regards, > Joachim > > PS: If this patch is generally accepted, the installer and Mac doku > should obviously be changed as well. > > > Index: SerialImp.c > =================================================================== > RCS file: /usr/local/cvsroot/rxtx-devel/src/SerialImp.c,v > retrieving revision 1.46.2.187 > diff -u -r1.46.2.187 SerialImp.c > --- SerialImp.c 29 Jan 2006 22:19:04 -0000 1.46.2.187 > +++ SerialImp.c 21 Mar 2006 12:59:16 -0000 > @@ -656,6 +656,25 @@ > fd=OPEN (filename, O_RDWR | O_NOCTTY | O_NONBLOCK ); > } while (fd < 0 && errno==EINTR); > > +#ifdef OPEN_EXCL > + // Note that open() follows POSIX semantics: multiple open() > calls to > + // the same file will succeed unless the TIOCEXCL ioctl is > issued. > + // This will prevent additional opens except by root-owned > processes. > + // See tty(4) ("man 4 tty") and ioctl(2) ("man 2 ioctl") for > details. > + > + if (fd >= 0 && (ioctl(fd, TIOCEXCL) == -1)) > + { > + sprintf( message, "open: exclusive access denied for % > s\n", > + filename ); > + report( message ); > + report_error( message ); > + > + close(fd); > + goto fail; > + } > +#endif /* OPEN_EXCL */ > + > + > if( configure_port( fd ) ) goto fail; > (*env)->ReleaseStringUTFChars( env, jstr, filename ); > sprintf( message, "open: fd returned is %i\n", fd ); > Index: SerialImp.h > =================================================================== > RCS file: /usr/local/cvsroot/rxtx-devel/src/SerialImp.h,v > retrieving revision 1.11.2.49 > diff -u -r1.11.2.49 SerialImp.h > --- SerialImp.h 5 Jul 2005 17:47:21 -0000 1.11.2.49 > +++ SerialImp.h 21 Mar 2006 12:59:17 -0000 > @@ -135,7 +135,8 @@ > /*# define LOCKDIR "/var/spool/uucp"*/ > # define LOCKDIR "/var/lock" > # define LOCKFILEPREFIX "LK." > -# define UUCP > +/*# define UUCP*/ > +# define OPEN_EXCL > #endif /* __APPLE__ */ > #if defined(__NetBSD__) > # define DEVICEDIR "/dev/" > This looks like a good start. What do you think Dmitry? Perhaps all systems with TIOCEXCL defined should use that though. Even if they use lockfiles. It wont hurt anything. That would catch people hacking their own serial apps without checking lockfiles. Its a good idea to avoid C++ style comments in the C portions. Some older systems don't deal with them well. If it's just for Mac OS X, it isn't a big deal. I think it was the Irix compiler that was problematic? -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Tue Mar 21 11:22:05 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 21 Mar 2006 11:22:05 -0700 (MST) Subject: [Rxtx] lock files In-Reply-To: <8E12916A-1B9A-4FF2-B684-E2D1C794221B@buechse.de> References: <8E12916A-1B9A-4FF2-B684-E2D1C794221B@buechse.de> Message-ID: We can try it. Maybe the JNI is much improved. The nice thing about linking into liblock is distros then worry about lockfiles on their systems. This way, we have to deal with any changes that may show up. On Tue, 21 Mar 2006, Joachim Buechse wrote: > This is pretty much what I thought about when I suggested, that the > default behaviour could be overwritten with a property. I am very much in > favor of this approach. In particular this allows much easier debugging > for PC based java developers. > > I think big parts of the Java (and maybe some parts of the C code) could > use a bit of a structural workover (unit tests, javadoc, synchronization, > etc). Maybe there should be a CVS branch for this experimental version. > I'd be happy to contribute a first workover for some of the Java code. > Designing for testability and implementing a good bunch of unit tests has > been a strategy that worked quite well in the Java projects I lead. And > it ultimately allows more liberal change permission. > > Regards, > Joachim > > > On 21.03.2006, at 08:51, Dr. Douglas Lyon wrote: > >> Hi All, >> You know, if the use of lock files were >> under Java control (rather than a build-time decision), >> it might enable a more unified binary distro. It might also >> facilitate quick prototyping of non-lock file approaches >> to resolving serial port contention issues (i.e., mac-like >> approaches vs. linux approaches, etc.). >> >> I realize that this is a radical overhaul of the lock file policy >> issue. Also, it may harm performance. On the other hand, >> our benchmarks on JNI overhead for modern processors indicate >> performance impact should be minimal. Perhaps it is more of >> an issue with the toybox systems. >> >> Suppose there were a class with a reasonable default...someone >> might write: >> SerialPortLockPolicy.setPolicy(SerialPortLockPolicy.UNIX_LOCK_FILE); >> SerialPortLockPolicy.setPolicy(SerialPortLockPolicy.NO_LOCK_CHECKING); >> SerialPortLockPolicy.setPolicy(SerialPortLockPolicy.MAC_STYLE); >> >> Thus, we could have a run-time reconfiguration of the serial port lock >> policy. A special NO_LOCK version of the binary would no longer >> be required. >> >> Any thoughts on this? >> >> Thanks! >> - Doug >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From dmarkman at mac.com Tue Mar 21 16:05:17 2006 From: dmarkman at mac.com (Dmitry Markman) Date: Tue, 21 Mar 2006 18:05:17 -0500 Subject: [Rxtx] PATCH: use of ioctl(fd, TIOCEXCL) instead of lockfiles In-Reply-To: References: <923AE774-EEA2-4911-92D8-32BB27802C8B@buechse.de> Message-ID: <512AC70C-BB86-48F2-A83C-023F35C23BAB@mac.com> I think it's cool, but I'd like to have that property implementation when user can choose between locking mechanism about comments: it's easy to change comments to the C style or we can use extensions of the file to cpp so c++ compiler will be used On Mar 21, 2006, at 1:05 PM, Trent Jarvi wrote: > This looks like a good start. What do you think Dmitry? Perhaps > all systems with TIOCEXCL defined should use that though. Even if > they use lockfiles. It wont hurt anything. That would catch > people hacking their own serial apps without checking lockfiles. > > Its a good idea to avoid C++ style comments in the C portions. > Some older systems don't deal with them well. If it's just for Mac > OS X, it isn't a big deal. I think it was the Irix compiler that > was problematic? Dmitry Markman From dmarkman at mac.com Tue Mar 21 16:13:00 2006 From: dmarkman at mac.com (Dmitry Markman) Date: Tue, 21 Mar 2006 18:13:00 -0500 Subject: [Rxtx] PATCH: use of ioctl(fd, TIOCEXCL) instead of lockfiles In-Reply-To: References: <923AE774-EEA2-4911-92D8-32BB27802C8B@buechse.de> Message-ID: I'd like to add that creating locking folder isn't a big deal we never had a problem related to the lock folders, because we always used installer on mac os x from other hand I'm not very much familiar with iotcl locking approach and I'm not sure it's more efficient Joachim wrote "I think it is the way to go, as it eliminates creating the lock directory which doesnt exist on the standard installation and it eliminates messing with the system group definitions (adding users to group uucp)." but I really didn't have any problem with that 1. doesn't exist on the standard installation there are many-many things that don't exist in the standard installation so I don't think that argument is strong enough 2. messing with the system group definitions I don't think we're messing with the group definition mac os x provides very clear way to set up group's members and together with Greg Guerin AuthKit there is no problem to set those definitions so I don't think that argument is strong either but from other hand using iotcl is more promising and is more elegant On Mar 21, 2006, at 1:05 PM, Trent Jarvi wrote: > > This looks like a good start. What do you think Dmitry? Perhaps > all systems with TIOCEXCL defined should use that though. Even if > they use lockfiles. It wont hurt anything. That would catch > people hacking their own serial apps without checking lockfiles. Dmitry Markman From joachim at buechse.de Wed Mar 22 04:46:45 2006 From: joachim at buechse.de (Joachim Buechse) Date: Wed, 22 Mar 2006 12:46:45 +0100 Subject: [Rxtx] PATCH: use of ioctl(fd, TIOCEXCL) instead of lockfiles In-Reply-To: References: <923AE774-EEA2-4911-92D8-32BB27802C8B@buechse.de> Message-ID: Sorry, I was not very clear with my arguments, so I will try again;-) Please, don't take this as an attack against work that has been done. I think the contributions that have been made in the past were made in a good spirit. But I really believe, that the current solution for OSX has many shortcomings and should be changed as soon as possible. lock files --- The /var/lock folder does not exist on the standard OSX installation, however the standard installation includes several applications that use serial ports (i.e. the FAX capability). This indicates, that the lock folder approach will not work well with system components. Applications for OSX will generally try to live in harmony with system components (except for HP print drivers of course). I think RXTX should follow this approach as well. uucp group --- Accessing serial ports is not an admin privileged operation on OSX. Any user (world) has read/write privileges on /dev/tty*. So the system default is to not enforce any group membership to access these ports. The group uucp however is a system group on all unix systems I know. It exists for certain system processes. A non admin user should in general not be a member of this group. Quite arguably no user should ever be a member of this group. Installer --- My general opinion is, that - no Installer should touch user or group data without warning - no Application Installer should touch groups which are not specific to the very application installed - no Installer should ever add regular users to a system group The current installer injects the installing user in the group uucp without warning about this change and without giving the option to "opt out" of this change. This is a potential security risk (but not currently a real one, as OSX contains no folders belonging to group uucp). The current installer does not work for multi user systems. It puts the installing user in the uucp group. However the installing user is not necessarily the user that will use the application. Putting all users that may use a serial port application in the system group uucp seems like a very invasive approach to me. Besides that, newly created users will not automatically be in the group and hence, serial applications will "break" for new users without obvious reasons. Avoiding the lock files will allow self contained applications (i.e. drag&drop installation). In my eyes this is largely preferable over an installer that requests admin privileges. Adding up all these points indicates very strongly, that the lock-file implementation is not the way to go on OSX. Regards, Joachim On 22.03.2006, at 00:13, Dmitry Markman wrote: > I'd like to add that > > creating locking folder isn't a big deal > we never had a problem related to the lock folders, because we > always used installer on mac os x > from other hand I'm not very much familiar with iotcl locking > approach and I'm not sure it's more efficient > > Joachim wrote "I think it is the way to go, as it eliminates > creating the lock directory which doesnt exist on the standard > installation and it eliminates messing with the system group > definitions (adding users to group uucp)." but I really didn't have > any problem with that > > 1. doesn't exist on the standard installation > there are many-many things that don't exist in the standard > installation so I don't think that argument is strong enough > 2. messing with the system group definitions > I don't think we're messing with the group definition > mac os x provides very clear way to set up group's members and > together with Greg Guerin AuthKit there is no problem to set those > definitions > so I don't think that argument is strong either > but from other hand using iotcl is more promising and is more elegant > > > > On Mar 21, 2006, at 1:05 PM, Trent Jarvi wrote: > >> >> This looks like a good start. What do you think Dmitry? Perhaps >> all systems with TIOCEXCL defined should use that though. Even if >> they use lockfiles. It wont hurt anything. That would catch >> people hacking their own serial apps without checking lockfiles. > > Dmitry Markman > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From dmarkman at mac.com Wed Mar 22 05:27:13 2006 From: dmarkman at mac.com (Dmitry Markman) Date: Wed, 22 Mar 2006 07:27:13 -0500 Subject: [Rxtx] PATCH: use of ioctl(fd, TIOCEXCL) instead of lockfiles In-Reply-To: References: <923AE774-EEA2-4911-92D8-32BB27802C8B@buechse.de> Message-ID: <83440CF3-DCD8-41C1-B941-F227232C27E3@mac.com> thanks for the very good explanation I didn't think that you were attacking any thing, so don't worry I just had feeling, that there were more aesthetic reasons for going to ioctl then real necessity now you explained everything quite well (BTW, asfar as I remember installer asks admin password so it wasn't quiet, but it really doesn't matter now) thanks On Mar 22, 2006, at 6:46 AM, Joachim Buechse wrote: > Sorry, I was not very clear with my arguments, so I will try again;-) > > Please, don't take this as an attack against work that has been > done. I think the contributions that have been made in the past > were made in a good spirit. But I really believe, that the current > solution for OSX has many shortcomings and should be changed as > soon as possible. > > lock files > --- > The /var/lock folder does not exist on the standard OSX > installation, however the standard installation includes several > applications that use serial ports (i.e. the FAX capability). This > indicates, that the lock folder approach will not work well with > system components. Applications for OSX will generally try to live > in harmony with system components (except for HP print drivers of > course). I think RXTX should follow this approach as well. > > uucp group > --- > Accessing serial ports is not an admin privileged operation on OSX. > Any user (world) has read/write privileges on /dev/tty*. So the > system default is to not enforce any group membership to access > these ports. The group uucp however is a system group on all unix > systems I know. It exists for certain system processes. A non admin > user should in general not be a member of this group. Quite > arguably no user should ever be a member of this group. > > Installer > --- > My general opinion is, that > - no Installer should touch user or group data without warning > - no Application Installer should touch groups which are not > specific to the very application installed > - no Installer should ever add regular users to a system group > > The current installer injects the installing user in the group uucp > without warning about this change and without giving the option to > "opt out" of this change. This is a potential security risk (but > not currently a real one, as OSX contains no folders belonging to > group uucp). > > The current installer does not work for multi user systems. It puts > the installing user in the uucp group. However the installing user > is not necessarily the user that will use the application. Putting > all users that may use a serial port application in the system > group uucp seems like a very invasive approach to me. Besides that, > newly created users will not automatically be in the group and > hence, serial applications will "break" for new users without > obvious reasons. > > > Avoiding the lock files will allow self contained applications > (i.e. drag&drop installation). In my eyes this is largely > preferable over an installer that requests admin privileges. Adding > up all these points indicates very strongly, that the lock-file > implementation is not the way to go on OSX. > > Regards, > Joachim > > > On 22.03.2006, at 00:13, Dmitry Markman wrote: > >> I'd like to add that >> >> creating locking folder isn't a big deal >> we never had a problem related to the lock folders, because we >> always used installer on mac os x >> from other hand I'm not very much familiar with iotcl locking >> approach and I'm not sure it's more efficient >> >> Joachim wrote "I think it is the way to go, as it eliminates >> creating the lock directory which doesnt exist on the standard >> installation and it eliminates messing with the system group >> definitions (adding users to group uucp)." but I really didn't >> have any problem with that >> >> 1. doesn't exist on the standard installation >> there are many-many things that don't exist in the standard >> installation so I don't think that argument is strong enough >> 2. messing with the system group definitions >> I don't think we're messing with the group definition >> mac os x provides very clear way to set up group's members and >> together with Greg Guerin AuthKit there is no problem to set those >> definitions >> so I don't think that argument is strong either >> but from other hand using iotcl is more promising and is more elegant >> >> >> >> On Mar 21, 2006, at 1:05 PM, Trent Jarvi wrote: >> >>> >>> This looks like a good start. What do you think Dmitry? Perhaps >>> all systems with TIOCEXCL defined should use that though. Even >>> if they use lockfiles. It wont hurt anything. That would catch >>> people hacking their own serial apps without checking lockfiles. >> >> Dmitry Markman >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx Dmitry Markman From lyon at docjava.com Wed Mar 22 06:12:18 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Wed, 22 Mar 2006 08:12:18 -0500 Subject: [Rxtx] sole of a new design pattern Message-ID: Hi All, I have been thinking about how we design the serial port software. I think we need a new design pattern. For lack of a better term, I shall call it: The Parametric Singleton Design Pattern By Douglas A. Lyon ABSTRACT The goal of the singleton design pattern is to make sure that there is one, and only one, instance of a given class. The goal of the parametric singleton design pattern is to make sure that there is one, and only one, instance of a given class with the given parametric values. We parametric singleton design pattern combines the singleton design pattern with a parameter that enables unique creation of instances of a class. These instances are cached. When a user asks for an instance with these parameters, the cache is checked. If the instance is in the cache, the instance is returned, otherwise it is created, added to the cache and then returned. We apply our parametric singleton design pattern to the retrieval of RMI registries bound to a given port. The goal of our system is to make sure that no two RMI registries are listening to the same socket and to make use of the RMI registries after they have been created. RMI registries are used in distributed computation. Introduction The singleton design pattern is meant to ensure that on a single instance of a class exists. It is also meant to provide a global point of access to it. The intent of the parametric singleton design pattern is to ensure that a class has only one instance for a given set of parameter values. It also provides a global point of access to it. Motivation A system cannot tolerate multiple instances of some classes with identical parameters. For example, you cannot have two instances making use of the same serial port, at the same time. You cannot have two instances that are trying to listen to the same socket connection. You cannot have two instances writing to the same file structure at the same time. As the operating system is often thought of as the arbiter of consumed resources (i.e., tape drives, serial ports, etc.) we frequently leave it to an operating system implementation to resolve these contention issues. Even for similar resources (like serial ports) there are few standards for handling contention. For example, serial ports on Linux are locked using a "/var/lock" file. POSIX, on the other hand, uses ioctl mechanisms to prevent contention. A better solution is to make a class that is responsible for keeping track of the instances created from the class. The class is declared final, so that it cannot be subclassed. The class also has a private constructor, so that other classes cannot instance it. The new design pattern is called the parametric singleton design pattern and it provides a way to access and create instances with given parameters. Applicability Use the Parametric Singleton Design Pattern when: 1. There must be exactly one instance of a class with the given parameters. 2. The instances must be accessible to clients from a well-known access point. Structure Insert UML diagram here. Participants The Parametric Singleton Clients that need instances 1. The Parametric Singleton defines an instance upon request from a client, if, and only if, the instance does not already exist. 2. The Parametric Singleton returns the instance to the client. 3. The Parametric Singleton is responsible for creating unique instances from given parameters. Collaborations Clients obtain a reference to a Parametric Singleton instance only through the parametric singleton design pattern. If the instance is left in an improper state (e.g., the serial port was left open) it is NOT the role of the Parametric Singleton Design Pattern to close the IO port. Nor is it the role of the Parametric Singleton Design Pattern to open the port. That role is delegate to some other part of the system. Further, it is not the role of the Parametric Singleton Design Pattern to check out resources. That is, multiple threads can have multiple references to the same resource at the same time. MUTEX locking is delegated to some other part of the system. Consequences The Parametric Singleton Design Pattern has several benefits: 1. Controlled access to parametrically defined instances. Since the Parametric Singleton class encapsulates its instances, there is control over how and when clients access it. 2. Reduced name space. The Parametric Singleton pattern avoids global variables that store instances created from the same parameter. Implementation Here are implementation issues to consider when using the Parametric Singleton pattern: 1. Unique mapping of parameters. The Parametric Singleton pattern requires that there be a mean to isomorphically map the parameter space into the instance space and back again. 2. Ensure unique instances. The Parametric Singleton pattern makes unique instances from parameters, and it does so only once. 3. Cache instances for fast retrieval. The Parametric Singleton pattern must be able to look up instances, given some set of parameters, and do so from some data structure. That is, there must be enough space to hold references to all the instances the program will need. Also, a mechanism is needed to look up and retrieve the instances quickly enough to satisfy the clients. Sample Code public final class ParametricSingletonRmiRegistry { private static Hashtable registry = new Hashtable(100); // use singleton pattern and??????????????????????????????????????????????? // prevent instantiation of RmiRegistryUtils.?????????????????????????????? private ParametricSingletonRmiRegistry() { } // the only instance of the Registry held by the RmiRegistryUtils?????????? public static void listNames(Integer port) { if (!isInCacheAndRunning(port)) return; Registry r = (Registry) registry.get(port); System.out.println("registry on port: " + port); System.out.println("registry: " + r); System.out.println("names: "); try { print(r.list()); } catch (RemoteException e) { In.message(e); } System.out.println("------------------------"); } /**???????????????????????????????????????????????????????????????????????? * Checks whether a Registry has been started on this host????????????????? * in the specified port.?????????????????????????????????????????????????? * If not, it tries to start one.?????????????????????????????????????????? * when it fails to start a Registry, it exits the program????????????????? * with exit code 1.??????????????????????????????????????????????????????? */ public static void restart(int port) { if (isInCacheAndRunning(port)) return; try { startRegistry(port); } catch (RemoteException e) { In.message(e); } } /**???????????????????????????????????????????????????????????????????????? * @param port????????????????????????????????????????????????????????????? * @return true if registry is in cache and running???????????????????????? */ private static boolean isInCacheAndRunning(Integer port) { if (!isRegistryRunning(port.intValue())) return false; if (!isRegistryInCache(port.intValue())) return false; return true; } /**???????????????????????????????????????????????????????????????????????? * @param port????????????????????????????????????????????????????????????? * @return true if we are able to locate a local registry on port.??????????????????????????????????????????????????????????????????????????? */ private static boolean isRegistryRunning(int port) { try { Registry r = LocateRegistry.getRegistry(port); if (r != null) return true; } catch (RemoteException e) { return false; } return false; } /**???????????????????????????????????????????????????????????????????????? * @param port????????????????????????????????????????????????????????????? * @return return true if registry is in cache????????????????????????????? */ private static boolean isRegistryInCache(int port) { if (registry.get(new Integer(port)) == null) return false; return true; } /**???????????????????????????????????????????????????????????????????????? * Restart the registry, if needed.???????????????????????????????????????? * Return the only instance of the registry for consistent global?????????? * using by making use of the Singleton Design Pattern????????????????????? *????????????????????????????????????????????????????????????????????????? * @return the internally held registry instance.?????????????????????????? */ public static Registry getRegistry(Integer port) { restart(port); return (Registry) registry.get(port); } private static void startRegistry(Integer port) throws RemoteException { Registry r; try { r = LocateRegistry.createRegistry(port.intValue()); registry.put(port, r); //r = new sun.rmi.registry.RegistryImpl???????????????????????????? /// (port.intValue());?????????????????????????????????????? // registry.put(port, r);?????????????????????????????????????????? } catch (Exception e) { //e.printStackTrace();????????????????????????????????????????????? r = LocateRegistry.getRegistry(port.intValue()); registry.put(port, r); } } public static void main(String args[]) throws RemoteException { //restart(port);??????????????????????????????????????????????????????? restart(5001); restart(5002); restart(5002); Registry r = LocateRegistry.getRegistry(5002); System.out.println("registry="+r); } } I would very much like to get your feedback on this new design pattern idea. Thank you for your time. Regards, - Doug From david.garnier at trusted-logic.com Wed Mar 22 07:36:10 2006 From: david.garnier at trusted-logic.com (David Garnier) Date: Wed, 22 Mar 2006 15:36:10 +0100 Subject: [Rxtx] sole of a new design pattern In-Reply-To: References: Message-ID: <442160DA.80107@trusted-logic.com> Hello, > The Parametric Singleton Design Pattern The Singleton is the most abused design pattern ever. Good use-cases for this pattern are extremely rare and mostly confined to problems related to hardware resources, like serial ports. > Applicability > > Use the Parametric Singleton Design Pattern when: > 1. There must be exactly one instance of a class with the given > parameters. OK. As I said above, this case this actually very unusual. The Singleton pattern is mostly used when : > 2. The instances must be accessible to clients from a well-known > access point. Using the singleton pattern in this case is just convenient for the programmer. Problems arises pretty quickly, especially if you attempt to unit-test your classes. 1) If your singleton is stateful, or hold on to stateful objects, it means that two different unit tests are not actually independent. Instead of starting with a brand new environment, the result of a test may be affected by the result of a previous test. This problem also arise when with your class relies on a database. In both cases, the solution is to reset your "unique" resource (Singleton or database) at the beginning of the test, which is a pain. Also, while most projects connect to a single database, projects that allow the use of Singletons usually contain several of thems, and new ones may cropped up unnoticed. You quickly end up with test cases that only pass in a certain order, which is a royal pain. 2) You cannot mockup a singleton. Once everyone calls the SomeSingleton class statically, you can't replace your class by SomeSingletonMockup. Furthermore, even for hardware services, the Singleton pattern does not really prevent concurrent accesses. If you start the same program in two different JVMs, unless they somehow shared the state of their "Singletons" (through lock files for example), the Singleton pattern will not prevent concurrent access. Our application uses RXTX, and we routinely encounter cases where another (native) application has already locked the port. Since we cannot modify the native application to recognize lock files, OS-level control is irreplaceable. > > Consequences > The Parametric Singleton Design Pattern has several benefits: > > 1. Controlled access to parametrically defined instances. Since > the Parametric Singleton class encapsulates its instances, there is > control over how and when clients access it. Not really. Once you've returned the instance to a client, you've lost control over it. The client can to whatever it wants with it. You cannot "recall" the instance or claim it back. > 2. Reduced name space. The Parametric Singleton pattern avoids > global variables that store instances created from the same parameter. Sure, but you don't have to rely on a Singleton for that. Just create a single Factory. > I would very much like to get your feedback on this new design > pattern idea. Well, it's nothing new. Some may say that it is the point of design patterns: formalizes the designs that occur again and again. However, this design is simply a combination of the Singleton and Factory patterns. I did use it in the past, but now I've been exposed to the shortcomings of the Singleton pattern, so I limit myself to Factories. Regards, David From sean_montgomery at baseview.com Wed Mar 22 08:35:28 2006 From: sean_montgomery at baseview.com (Sean Montgomery) Date: Wed, 22 Mar 2006 10:35:28 -0500 Subject: [Rxtx] sole of a new design pattern In-Reply-To: <442160DA.80107@trusted-logic.com> References: <442160DA.80107@trusted-logic.com> Message-ID: <05769CA7-A51B-4CF0-BAA0-E02DD905F5A4@baseview.com> On Mar 22, 2006, at 9:36 AM, David Garnier wrote: > Furthermore, even for hardware services, the Singleton pattern does > not really prevent concurrent > accesses. If you start the same program in two different JVMs, > unless they somehow shared the state > of their "Singletons" (through lock files for example), the > Singleton pattern will not prevent > concurrent access. > Multiple class loaders in a single JVM can be tricky, too. Then there's synchronization, lazy initialization and serialization of singletons to contend with. Bloch's Effective Java covers these, and here's a few articles: http://www.javaworld.com/javaworld/jw-04-2003/jw-0425-designpatterns- p3.html http://java.sun.com/developer/technicalArticles/Programming/singletons/ Just FYI :-) From lyon at docjava.com Wed Mar 22 08:50:48 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Wed, 22 Mar 2006 10:50:48 -0500 Subject: [Rxtx] sole of a new design pattern In-Reply-To: <442160DA.80107@trusted-logic.com> References: <442160DA.80107@trusted-logic.com> Message-ID: Hi All, First, I would like to thank David for his prompt and thoughtful remarks. I had no idea people that feel strongly about a design patterns! Wow! Feedback (particularly critical feedback) is greatly appreciated. Starting at the end, first: >I did use it in >the past, but now I've been exposed to the shortcomings of the >Singleton pattern, so I limit myself to Factories. David, if I understood your comments correctly, you suggested that Factories can be used in leu of the Singleton Design Pattern, or even the Parametric Singleton Design Pattern. As I see in [Gof]: Factory Method: Intent "Define an interface for creating an object, but let subclasses decide which class to instantiate. Factory Method lets a class defer instantiation to subclasses." The Singleton Design Pattern is a concrete class, which is rather different, right? Also, subclasses are not permitted with Singleton, as they are final. Naturally, I could use an abstract factory as a parent for a singleton. I could even design a facade that could be implemented with the singleton....but that is not the intention of the design. Unless you want a mock-up, as discussed, below: More below: >Hello, > >> The Parametric Singleton Design Pattern > >The Singleton is the most abused design pattern ever. Good use-cases >for this pattern are extremely >rare and mostly confined to problems related to hardware resources, >like serial ports. > > >> Applicability >> >> Use the Parametric Singleton Design Pattern when: >> 1. There must be exactly one instance of a class with the given >> parameters. >OK. As I said above, this case this actually very unusual. The >Singleton pattern is mostly used when : >> 2. The instances must be accessible to clients from a well-known >> access point. > >Using the singleton pattern in this case is just convenient for the >programmer. Problems arises >pretty quickly, especially if you attempt to unit-test your classes. > >1) If your singleton is stateful, or hold on to stateful objects, it >means that two different unit >tests are not actually independent. Instead of starting with a brand >new environment, the result of >a test may be affected by the result of a previous test. This >problem also arise when with your >class relies on a database. In both cases, the solution is to reset >your "unique" resource >(Singleton or database) at the beginning of the test, which is a >pain. Also, while most projects >connect to a single database, projects that allow the use of >Singletons usually contain several of >thems, and new ones may cropped up unnoticed. You quickly end up >with test cases that only pass in a >certain order, which is a royal pain. There are basic problems with communicating finite state machines that include reachability and deadlock analysis. These are addressed with petri net analysis and are beyond the scope of the design pattern. As you quite rightly pointed out; the parametric singleton pattern (or the singleton pattern, for that matter) enable multiple threads to gain access to the same instance. The only way that I can see to block others from gaining access to the reference is the synchronize keyword. This is putting a spin-lock (or MUTEX) on the reference. The question of how to unit-test a design pattern like the parametric singleton remains open. Perhaps this is a deficiency. > >2) You cannot mockup a singleton. Once everyone calls the >SomeSingleton class statically, you can't >replace your class by SomeSingletonMockup. Acutally, I am not sure that this is true. If the Singleton implements a Facade interface, it should be possible to make the replacement. Right? > >Furthermore, even for hardware services, the Singleton pattern does >not really prevent concurrent >accesses. If you start the same program in two different JVMs, >unless they somehow shared the state >of their "Singletons" (through lock files for example), the >Singleton pattern will not prevent >concurrent access. Good Point!! You have sharp eyes! The singleton design pattern should/could take responsibility for this. In fact, you may notice that my code does have an implementation (LocateRegistry) that can work across JVM's. The LocateRegistry will even work across the Internet! LocateRegistry takes both a host name and a Port (lock files just don't do this). I did not think to implement this beyond the local machine, but, in its present form, it will work across different processes. > >Our application uses RXTX, and we routinely encounter cases where >another (native) application has >already locked the port. Since we cannot modify the native >application to recognize lock files, >OS-level control is irreplaceable. The singleton design pattern is not meant to replace OS-level control, but to centralize the Java programmers access to it. If lock files, for example, are used for serial ports, the Singleton Design Pattern should be able to work with them. > > >> >> Consequences >> The Parametric Singleton Design Pattern has several benefits: >> > > 1. Controlled access to parametrically defined instances. Since >> the Parametric Singleton class encapsulates its instances, there is >> control over how and when clients access it. > >Not really. Once you've returned the instance to a client, you've >lost control over it. The client >can to whatever it wants with it. You cannot "recall" the instance >or claim it back. Good point, this should read: > 1. Controll when parametrically defined instances are created. Since > > the Parametric Singleton class encapsulates its instances, there is > > control over how and when they are instanced. > >> 2. Reduced name space. The Parametric Singleton pattern avoids >> global variables that store instances created from the same parameter. > >Sure, but you don't have to rely on a Singleton for that. Just >create a single Factory. > > Thank you for your thoughtful and prompt response! Regards, - Doug From dmarkman at mac.com Wed Mar 22 21:21:55 2006 From: dmarkman at mac.com (Dmitry Markman) Date: Wed, 22 Mar 2006 23:21:55 -0500 Subject: [Rxtx] sole of a new design pattern In-Reply-To: <442160DA.80107@trusted-logic.com> References: <442160DA.80107@trusted-logic.com> Message-ID: I don't think I get it On Mar 22, 2006, at 9:36 AM, David Garnier wrote: > Using the singleton pattern in this case is just convenient for the > programmer. Problems arises > pretty quickly, especially if you attempt to unit-test your classes. so you're saying that something isn't so good because you can not test it in the convenient way? if that's true, I'm totally disagree change your test, debug whatever, but if software is efficient at runtime, works fine and only problem is some unit test (which is some kind of framework for testing) then dump that unit test , dump that unit framework and make something appropriate to the software you're testing so if Douglas want to use singletons, what's the problem? and what do you mean by abusing of singleton usage? of course singleton doesn't prevent concurrent access to the resource across the processes unless you're using some OS facility to prevent it, besides singleton as it was introduced is relevant only and only inside of the same process otherwise it's not singleton it's something else (let's say network singleton: so you have remote invocation facility and some factory method that return object created by that facility) I don't have any problem with using any kind of singletons. Parametric Singleton idea (if I understand it right) could be easily implemented in the following way: use a map populate map with instances of some class and key is your parameter (you can use lazy population too) if somebody ask the key check the value if it's null so resource is taken if somebody returns the resource put it back to the map public synchronized static Object getSomeResource(Object parameter); public synchronized static void returnResource(Object parameter); getSomeResource (inside of the same process) could return null in 2 cases 1. if somebody (from other thread for example) already took that resource 2. if OS API said that resource corresponded to that parameter (serial port with parameter = 1 (port #)) is locked and unavailable; I'm not sure that in case of serial ports we even need those Parametric Singletons (unless lock checking is a very expensive operation) just ask the OS about availability of that resource and if it's available give it away and then OS will lock it and therefore in next time somebody ask it just answer that resource is locked and return null for example system has 2 serial ports available so I ask getResource("tty"); or I ask getResource("Bluetooth-Modem"); and if OS is ok you can give tty or Bluetooth-Modem or both no need for any additional pattern I think back to the problem mac os x doesn't recognize locking via files, so it handles locking via some API an instance of the singleton in each process should recognize that resource is locked (by using that API) that's all we don't have to make things more complicate then they are just because there is some nice design pattern or nice unit test framework or whatever keep things simple, make them work fast, don't introduce middle layers unless you have really good reason to do so of course I could be entirely wrong, so sorry about that in advance thanks Dmitry Markman From tjarvi at qbang.org Wed Mar 22 22:31:41 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 22 Mar 2006 22:31:41 -0700 (MST) Subject: [Rxtx] sole of a new design pattern In-Reply-To: References: Message-ID: Hi Doug Interesting reading. So far I'm just reading and thinking. I have one question so far. " Clients obtain a reference to a Parametric Singleton instance only through the parametric singleton design pattern. If the instance is left in an improper state (e.g., the serial port was left open) it is NOT the role of the Parametric Singleton Design Pattern to close the IO port. Nor is it the role of the Parametric Singleton Design Pattern to open the port. That role is delegate to some other part of the system. " So when the clients obtain a reference to the singleton, can they assume the port is there? IE, would it be the singletons role to handle things like USB dongles being removed with event hints comming from the underlying OS. Hardware abstraction layer/HAL on Linux is an example of underlying OS events. I assume that role too is delegated to other parts of the system? -- Trent Jarvi tjarvi at qbang.org From lyon at docjava.com Thu Mar 23 08:10:33 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Thu, 23 Mar 2006 10:10:33 -0500 Subject: [Rxtx] Classes don't need goals, they need roles! In-Reply-To: References: Message-ID: Hi Trent, Yes, I think that the role of the Parametric Singleton Pattern is not to open or close serial ports, nor is it to perform error checking. On the other hand, if you were to combine the role of the Parametric Singleton Pattern with another role (like that of error checking) it might not be amiss. However, I generally caution programmers against adding multiple roles to classes, as this leads to monolithic designs. Thus a different class (NativeLibDetect) could have the role of determining if the native library can be loaded. Another class (SerialPortBean) can have the role of serializing the default state of the serial port, so that it can be recovered, from user preferences, at a later time. The SerialPortDetect could have the role of determining if the serial port is removed (i.e., a USB port was unplugged). My guess is that each class should have a different role in the system, in order to ease maintenance and testing...but I could be wrong about that. Thanks! - Doug >Hi Doug > >Interesting reading. So far I'm just reading and thinking. I have >one question so far. > >" > Clients obtain a reference to a Parametric Singleton instance only >through the parametric singleton design pattern. If the instance is >left in an improper state (e.g., the serial port was left open) it is >NOT the role of the Parametric Singleton Design Pattern to close the >IO port. Nor is it the role of the Parametric Singleton Design Pattern >to >open the port. That role is delegate to some other part of the system. >" > >So when the clients obtain a reference to the singleton, can they >assume the port is there? IE, would it be the singletons role to >handle things like USB dongles being removed with event hints >comming from the underlying OS. Hardware abstraction layer/HAL on >Linux is an example of underlying OS events. > >I assume that role too is delegated to other parts of the system? > >-- >Trent Jarvi >tjarvi at qbang.org >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From maximulo at yahoo.com Fri Mar 24 01:22:38 2006 From: maximulo at yahoo.com (Maximulo Majir) Date: Fri, 24 Mar 2006 00:22:38 -0800 (PST) Subject: [Rxtx] JavaPOS Message-ID: <20060324082238.66371.qmail@web38214.mail.mud.yahoo.com> Hi all! Hello Trent! From what i understand, RXTX or JavaComm APIs were not created solely for JavaPOS. In JavaPOS, we have the virtual method claim() which is separate from open(), but in our RXTX API, claiming is done every call to open(), we cant open the port if its claimed by another application. Would it be alright to suggest or ask to create a new method called claim(..)? Is there such thing as forceclaim() in RXTX? this could be the same as portownership transfer or its equivalent. ForceClaim is in JSR80. Do you have some samples using RXTX as the lower layer for the Device Service Objects in JavaPOS? I have tried it, i just want to compare. Thank you all! maxim __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060324/496adba2/attachment-0022.html From tjarvi at qbang.org Fri Mar 24 11:28:19 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 24 Mar 2006 11:28:19 -0700 (MST) Subject: [Rxtx] Re: RXTX 2.1 Solaris Problems In-Reply-To: <3691.1143210578@www045.gmx.net> References: <3691.1143210578@www045.gmx.net> Message-ID: On Fri, 24 Mar 2006, Andreas Guenther wrote: > Hi all, > > the solaris problem was not the lock file only. > > Ok, I had to create the directory /var/spool/locks myself. > /var/spool/uucp exists. > > But rxtx didn't find any port. > > I compiled the source with my own debug-informations > and I tried to isolate the problem. > > The problem is the testRead-call in SerialImp.c > > JNIEXPORT jboolean JNICALL RXTXCommDriver(testRead)( > > ... > if ( READ( fd, &c, 1 ) < 0 ) > { > if ( errno != EAGAIN ) { > report( "testRead() read failed\n" ); > ret = JNI_FALSE; > } > } > Thanks Andreas I'm packing up to move. I'll be more or less away for a couple weeks here. I'll be checking email but my workstation is going into a box soon. This isn't hard to fix as this port should be enumerated when EWOULDBLOCK is recieved. Thats error is OK for enumeration just as EAGAIN is. I've put the bug into bugzilla so we dont forget to get to it. http://bugzilla.qbang.org/show_bug.cgi?id=42 You can add yourself to the CC list if you wish to test fixes we provide or even put a patch into bugzilla yourself. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Fri Mar 24 11:51:52 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 24 Mar 2006 11:51:52 -0700 (MST) Subject: [Rxtx] JavaPOS In-Reply-To: <20060324082238.66371.qmail@web38214.mail.mud.yahoo.com> References: <20060324082238.66371.qmail@web38214.mail.mud.yahoo.com> Message-ID: On Fri, 24 Mar 2006, Maximulo Majir wrote: > Hi all! Hello Trent! > > > From what i understand, RXTX or JavaComm APIs were not > created solely for JavaPOS. In JavaPOS, we have the virtual method > claim() which is separate from open(), but in our RXTX API, claiming is > done every call to open(), we cant open the port if its claimed by > another application. Would it be alright to suggest or ask to create a > new method called claim(..)? Is there such thing as forceclaim() in > RXTX? this could be the same as portownership transfer or its > equivalent. ForceClaim is in JSR80. > Do you have some samples using RXTX as the lower layer for the Device > Service Objects in JavaPOS? I have tried it, i just want to compare. > maxim Hi Maxim JSR80 is the USB API IBM/Sun put together. The problem is they have a richer kernel/API underneath that can handle such things. With Serial Ports, there isnt anything there other than an ioctl that says don't let anyone touch this and lockfiles that are more of a 'lets be nice.' At times we may be using USB ports but it is through the termios layer with the limitations mentioned. The advantage is that not only USB will work with rxtx. Anything that has a termios layer should work (to the extent that termios layer is complete). I don't know how forceclaim() would help you. Lets say someone has a programmer working on /dev/ttyS0 and you take it. Now you both race each other to read data first. There isn't a mechanism I know of that will solve this problem in termios. The most obvious test being a native app and a Java app trying to take the port. There is the potential of requestion ownership from other Java Applications but the use for that is very rare. Did you have something more specific in mind that I'm missing? I'm not sure that claim() and forceclaim() would help you with rxtx other than maybe locking the port with claim() without opening it. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sat Mar 25 23:42:08 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 25 Mar 2006 23:42:08 -0700 (MST) Subject: [Rxtx] Serial snoop Message-ID: I was reading the Linux kernel mail-list tonight and ran past a thread that mentioned sersnoop. This looks like a handy tool for people dealing with new toys. "a simple command-line tool for linux that echoes bytes to and from any two serial ports, ptys, or network sockets, and prints all traffic to stdout, in hex and ascii." http://www.restivo.org/projects/sersnoop/ It works on Linux only at this time (debian package available). -- Trent Jarvi tjarvi at qbang.org From beat.arnet at gmail.com Sun Mar 26 07:32:35 2006 From: beat.arnet at gmail.com (Beat Arnet) Date: Sun, 26 Mar 2006 09:32:35 -0500 Subject: [Rxtx] Error 0x5 at /home/bob/foo/tar/rxtx-2.1-7/build/../src/termios.c(860): Access is, denied. Message-ID: <4426A603.80508@gmail.com> Dear all, When trying to open the serial port, I sometimes (not always) run into the following exception (when opening the serialPort): Error 0x5 at /home/bob/foo/tar/rxtx-2.1-7/build/../src/termios.c(860): Access is denied. java.lang.UnsatisfiedLinkError: native_psmisc_report_owner at gnu.io.CommPortIdentifier.native_psmisc_report_owner(Native Method) at gnu.io.CommPortIdentifier.open(CommPortIdentifier.java:354) at codeskin.tools.CLLoader.open(CLLoader.java:79) at codeskin.tools.C2000Programmer.run(C2000Programmer.java:220) at java.lang.Thread.run(Unknown Source) Is this the type of error where I should just try to open the port again, or can it be avoided? Regards, Beat From tjarvi at qbang.org Sun Mar 26 11:40:12 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 26 Mar 2006 11:40:12 -0700 (MST) Subject: [Rxtx] Error 0x5 at /home/bob/foo/tar/rxtx-2.1-7/build/../src/termios.c(860): Access is, denied. In-Reply-To: <4426A603.80508@gmail.com> References: <4426A603.80508@gmail.com> Message-ID: On Sun, 26 Mar 2006, Beat Arnet wrote: > Dear all, > > When trying to open the serial port, I sometimes (not always) run into > the following exception (when opening the serialPort): > > Error 0x5 at /home/bob/foo/tar/rxtx-2.1-7/build/../src/termios.c(860): > Access is > denied. > > java.lang.UnsatisfiedLinkError: native_psmisc_report_owner > at gnu.io.CommPortIdentifier.native_psmisc_report_owner(Native > Method) > at gnu.io.CommPortIdentifier.open(CommPortIdentifier.java:354) > at codeskin.tools.CLLoader.open(CLLoader.java:79) > at codeskin.tools.C2000Programmer.run(C2000Programmer.java:220) > at java.lang.Thread.run(Unknown Source) > > Is this the type of error where I should just try to open the port again, > or can it be avoided? > Hi Beat We did a second build of rxtx 2.1-7 to resolve that unsatisfied link error. It should work now. rxtx is trying to tell you it thinks someone else has the serial port open. You can try to open the port again but maybe you already have a copy of the program running when it happens? ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7r2.zip fixed build. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sun Mar 26 11:44:23 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 26 Mar 2006 11:44:23 -0700 (MST) Subject: [Rxtx] RXTX spec file (fwd) Message-ID: This is probably interesting for fedora/suse users. ---------- Forwarded message ---------- Date: Sun, 26 Mar 2006 16:25:45 +0200 To: taj at www.linux.org.uk Subject: RXTX spec file I send you this spec file which allows to create a RPM for Fedora 4, 5 (x86, x86_64) with Java Sun. -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: rxtx.spec Url: http://mailman.qbang.org/pipermail/rxtx/attachments/20060326/6c7b6af6/rxtx-0018.pl From tjarvi at qbang.org Sun Mar 26 23:42:59 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 26 Mar 2006 23:42:59 -0700 (MST) Subject: [Rxtx] Upcomming events. Message-ID: This Wednesday we will be announcing a new "Maintainer" for the rxtx project. The position is more like neutral leader. I wont be going away or doing less. This is just the right thing to do as it turns out the two people with CVS write access will be at the same company. We need a third and we need neutrality. The maintainer will have final say in any conflict and will try to be neutral. It will be open for discussion. Then we will do it :) I'll still do most of the footwork I do now. But. I'm falling behind. I should have gone through the mail-list and posted the next round of changes this weekend. I'm packing to move and its going so so - 13 years of toys collected. I suspect there will be a dead period on my part (a couple weeks) comming up. But if you get it on the mail-list, we will get it in if there are no objections. I may well not be reading the mail-list during this period as I look for a house and many other things. I hope everyone will help out. Thanks -- Trent Jarvi tjarvi at qbang.org From mahmoud_hadad at yahoo.com Sun Mar 26 07:31:19 2006 From: mahmoud_hadad at yahoo.com (ronan nick) Date: Sun, 26 Mar 2006 06:31:19 -0800 (PST) Subject: [Rxtx] a question about the COMM API Message-ID: <20060326143119.54919.qmail@web60014.mail.yahoo.com> hi, i was intrested in knowing how i can communicate with my internal modem using java? for example if i want to make a phone dialer application or a caller id application where should i be looking at? and as i understood the COMM API is for devices that is attached to the computer through serial ports. --------------------------------- New Yahoo! Messenger with Voice. Call regular phones from your PC and save big. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060326/ce8329f0/attachment-0020.html From dmarkman at mac.com Mon Mar 20 00:20:43 2006 From: dmarkman at mac.com (Dmitry Markman) Date: Mon, 20 Mar 2006 02:20:43 -0500 Subject: [Rxtx] Mac OS X RXTX java installer In-Reply-To: References: <07D0DE29-BA32-4CFE-B036-66BC6423D385@buechse.de> <441AE3E0.2030503@willicon.de> <12531986.1142622114996.JavaMail.dmarkman@mac.com> <441B2674.9010409@willicon.de> <13577405.1142634732776.JavaMail.dmarkman@mac.com> <441B4182.8010407@willicon.de> <92CD0D6C-5BE8-426E-A46D-99452059FF49@mac.com> <441BBB2D.8030305@willicon.de> <441C4088.5090905@willicon.de> Message-ID: <64BC1E23-FDDE-4CE6-8863-CFC881CBC224@mac.com> Hi all I put RXTX installer that will install everything (and will create / var/lock if necessary and add user to the uucp group) for mac os x from Java into the rxtx's CVS repository it could be easily modified to install files for any platform it uses Greg Guerin's AuthKit for authentication and authorization Greg released that kit under artistic license, so Trent, please take a look we, probably, can negotiate license with Greg if it's necessary Greg's AuthKit could be downloaded from http://www.amug.org/~glguerin/ sw/#authkit Michael Hall (mikehall at spacestar dot net) had a suggestion to make implementation of the jaas LoginModule based on Greg's AuthKit (his modification of the Greg's AuthKit could be found at http:// www.spacestar.net/users/mikehall/authkit.dmg) but Michael's AuthKitLoginModule does only half a job: it does authenticate but it can not run any external unix process in privileged mode (at least I wasn't able to do so) possible explanation could be found in conversation between Greg and Michael at Apple's java-dev list (look for archives) so I didn't use jaas API for rxtxinstaller I created folder MacOSX in the contrib folder comment 1. if you want to run that installer as standalone application all you need that RXTXInstaller.jar 2. if you want to use webstart you have to add Greg's libAuthKit.jnilib to the mac os x's resources in theory RXTXInstaller.jar doesn't need it, but there is a problem with loading libAuthKit.jnilib from webstart authkit uses loadLibrary method to load library and it failed (from webstart) for standalone application I extract libAuthKit.jnilib from the RXTXInstaller.jar and put it into the /Library/Java/Extensions or ~/Library/Java/Extensions folder that file will be deleted after installer quit unfortunately I didn't have time to put documentation there but it is mostly self-explanatory I took installer code from my gl4java installer that I did about 3 years ago (with small modifications) it would be very nice if Apple will release LoginModule that really will do the job (com.apple.security.auth.module package????? ) (UnixLoginModule is pretty useless) From lyon at docjava.com Mon Mar 20 06:34:39 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Mon, 20 Mar 2006 08:34:39 -0500 Subject: [Rxtx] Mac OS X RXTX java installer In-Reply-To: <64BC1E23-FDDE-4CE6-8863-CFC881CBC224@mac.com> References: <07D0DE29-BA32-4CFE-B036-66BC6423D385@buechse.de> <441AE3E0.2030503@willicon.de> <12531986.1142622114996.JavaMail.dmarkman@mac.com> <441B2674.9010409@willicon.de> <13577405.1142634732776.JavaMail.dmarkman@mac.com> <441B4182.8010407@willicon.de> <92CD0D6C-5BE8-426E-A46D-99452059FF49@mac.com> <441BBB2D.8030305@willicon.de> <441C4088.5090905@willicon.de> <64BC1E23-FDDE-4CE6-8863-CFC881CBC224@mac.com> Message-ID: Hi Dimitry, This sounds like great work. Just a couple of questions; After the check out of the CVS files, using: setenv CVSROOT :pserver:anonymous at cvs.milestonesolutions.com:/usr/local/cvsroot 53 8:28 setenv PASSWORD mousy 54 8:29 cvs login 55 8:29 cvs checkout rxtx-devel I cd'd over to: rxtx-devel/MACOSX_IDE And found: CVS/ CW/ ForPackageMaker/ PB/ Where is the installer? Thanks! - Doug From tjarvi at qbang.org Mon Mar 20 06:39:37 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 20 Mar 2006 06:39:37 -0700 (MST) Subject: [Rxtx] Mac OS X RXTX java installer In-Reply-To: References: <07D0DE29-BA32-4CFE-B036-66BC6423D385@buechse.de> <441AE3E0.2030503@willicon.de> <12531986.1142622114996.JavaMail.dmarkman@mac.com> <441B2674.9010409@willicon.de> <13577405.1142634732776.JavaMail.dmarkman@mac.com> <441B4182.8010407@willicon.de> <92CD0D6C-5BE8-426E-A46D-99452059FF49@mac.com> <441BBB2D.8030305@willicon.de> <441C4088.5090905@willicon.de> <64BC1E23-FDDE-4CE6-8863-CFC881CBC224@mac.com> Message-ID: On Mon, 20 Mar 2006, Dr. Douglas Lyon wrote: > Hi Dimitry, > This sounds like great work. Just a couple of questions; > After the check out of the CVS files, using: > setenv CVSROOT > :pserver:anonymous at cvs.milestonesolutions.com:/usr/local/cvsroot > 53 8:28 setenv PASSWORD mousy > 54 8:29 cvs login > 55 8:29 cvs checkout rxtx-devel Hi Doug You want "cvs checkout -r commapi-0-0-1 rxtx-devel" to get RXTX 2.1 The default branch is rxtx 2.0 which isn't very active right now. -- Trent Jarvi tjarvi at qbang.org From lyon at docjava.com Mon Mar 20 07:05:44 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Mon, 20 Mar 2006 09:05:44 -0500 Subject: [Rxtx] Mac OS X RXTX java installer In-Reply-To: References: <07D0DE29-BA32-4CFE-B036-66BC6423D385@buechse.de> <441AE3E0.2030503@willicon.de> <12531986.1142622114996.JavaMail.dmarkman@mac.com> <441B2674.9010409@willicon.de> <13577405.1142634732776.JavaMail.dmarkman@mac.com> <441B4182.8010407@willicon.de> <92CD0D6C-5BE8-426E-A46D-99452059FF49@mac.com> <441BBB2D.8030305@willicon.de> <441C4088.5090905@willicon.de> <64BC1E23-FDDE-4CE6-8863-CFC881CBC224@mac.com> Message-ID: Hi Trent, Thanks for the info on the CVS checkout procedure. I did that and am still not sure where the installer is. Here is what I have: cd MACOSX_IDE/ p4.docjava.com{lyon}121: ls CVS/ ForPackageMaker/ PB/ p4.docjava.com{lyon}122: find . | more . ./ForPackageMaker ./ForPackageMaker/RXTX.pkg.sit.hqx ./ForPackageMaker/Resources ./ForPackageMaker/Resources/ReadMe.rtf ./ForPackageMaker/Resources/Welcome.rtf ./ForPackageMaker/Resources/CVS ./ForPackageMaker/Resources/CVS/Entries ./ForPackageMaker/Resources/CVS/Repository ./ForPackageMaker/Resources/CVS/Tag ./ForPackageMaker/Resources/CVS/Root ./ForPackageMaker/Resources/preinstall ./ForPackageMaker/Resources/License.rtf ./ForPackageMaker/Resources/preupgrade ./ForPackageMaker/RXTX.pmsp ./ForPackageMaker/CVS ./ForPackageMaker/CVS/Entries ./ForPackageMaker/CVS/Repository ./ForPackageMaker/CVS/Entries.Log ./ForPackageMaker/CVS/Tag ./ForPackageMaker/CVS/Root ./ForPackageMaker/RXTX_Tiger.pkg.sitx.hqx ./ForPackageMaker/RXTX_Jag.pkg.sit.hqx ./ForPackageMaker/Install ./ForPackageMaker/Install/CVS ./ForPackageMaker/Install/CVS/Entries ./ForPackageMaker/Install/CVS/Repository ./ForPackageMaker/Install/CVS/Tag ./ForPackageMaker/Install/CVS/Root ./ForPackageMaker/Install/Library ./ForPackageMaker/Install/Library/CVS ./ForPackageMaker/Install/Library/CVS/Entries ./ForPackageMaker/Install/Library/CVS/Repository ./ForPackageMaker/Install/Library/CVS/Tag ./ForPackageMaker/Install/Library/CVS/Root ./ForPackageMaker/Install/Library/Java ./ForPackageMaker/Install/Library/Java/Extensions ./ForPackageMaker/Install/Library/Java/Extensions/RXTXcomm.jar ./ForPackageMaker/Install/Library/Java/Extensions/CVS ./ForPackageMaker/Install/Library/Java/Extensions/CVS/Entries ./ForPackageMaker/Install/Library/Java/Extensions/CVS/Repository ./ForPackageMaker/Install/Library/Java/Extensions/CVS/Tag ./ForPackageMaker/Install/Library/Java/Extensions/CVS/Root ./ForPackageMaker/Install/Library/Java/Extensions/librxtxSerial.jnilib ./ForPackageMaker/Install/Library/Java/CVS ./ForPackageMaker/Install/Library/Java/CVS/Entries ./ForPackageMaker/Install/Library/Java/CVS/Repository ./ForPackageMaker/Install/Library/Java/CVS/Entries.Log ./ForPackageMaker/Install/Library/Java/CVS/Tag ./ForPackageMaker/Install/Library/Java/CVS/Root ./ForPackageMaker/RXTX_Tiger.pmproj.sitx.hqx ./CVS ./CVS/Entries ./CVS/Repository ./CVS/Entries.Log ./CVS/Tag ./CVS/Root ./PB ./PB/LibSerialUniversal.xcodeproj.sitx.hqx ./PB/CVS ./PB/CVS/Entries ./PB/CVS/Repository ./PB/CVS/Entries.Log ./PB/CVS/Tag ./PB/CVS/Root ./PB/LibSerial.pbproj.sit.hqx ./PB/startpoint.c ./PB/config.h What is the procedure to run this installer? Do we need a README in: /rxtx-devel/MACOSX_IDE Here is what we have: CVS/ ForPackageMaker/ PB/ Thanks! - DL >On Mon, 20 Mar 2006, Dr. Douglas Lyon wrote: > >>Hi Dimitry, >>This sounds like great work. Just a couple of questions; >>After the check out of the CVS files, using: >>setenv CVSROOT >>:pserver:anonymous at cvs.milestonesolutions.com:/usr/local/cvsroot >> 53 8:28 setenv PASSWORD mousy >> 54 8:29 cvs login >> 55 8:29 cvs checkout rxtx-devel > >Hi Doug > >You want "cvs checkout -r commapi-0-0-1 rxtx-devel" to get RXTX 2.1 >The default branch is rxtx 2.0 which isn't very active right now. > >-- >Trent Jarvi >tjarvi at qbang.org From tjarvi at qbang.org Mon Mar 20 07:25:30 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 20 Mar 2006 07:25:30 -0700 (MST) Subject: [Rxtx] Mac OS X RXTX java installer In-Reply-To: References: <07D0DE29-BA32-4CFE-B036-66BC6423D385@buechse.de> <441AE3E0.2030503@willicon.de> <12531986.1142622114996.JavaMail.dmarkman@mac.com> <441B2674.9010409@willicon.de> <13577405.1142634732776.JavaMail.dmarkman@mac.com> <441B4182.8010407@willicon.de> <92CD0D6C-5BE8-426E-A46D-99452059FF49@mac.com> <441BBB2D.8030305@willicon.de> <441C4088.5090905@willicon.de> <64BC1E23-FDDE-4CE6-8863-CFC881CBC224@mac.com> Message-ID: On Mon, 20 Mar 2006, Dr. Douglas Lyon wrote: > Hi Trent, > Thanks for the info on the CVS checkout procedure. > I did that and am still not sure where the installer is. Hi Doug It does look like it was not cvs committed. There is no rxtx-devel/contrib/MacOSX directory in there at the moment. It was mentioned that it was put under contrib. -- Trent Jarvi tjarvi at qbang.org From dmarkman at mac.com Mon Mar 20 07:29:56 2006 From: dmarkman at mac.com (Dmitry Markman) Date: Mon, 20 Mar 2006 09:29:56 -0500 Subject: [Rxtx] Mac OS X RXTX java installer In-Reply-To: References: <07D0DE29-BA32-4CFE-B036-66BC6423D385@buechse.de> <441AE3E0.2030503@willicon.de> <12531986.1142622114996.JavaMail.dmarkman@mac.com> <441B2674.9010409@willicon.de> <13577405.1142634732776.JavaMail.dmarkman@mac.com> <441B4182.8010407@willicon.de> <92CD0D6C-5BE8-426E-A46D-99452059FF49@mac.com> <441BBB2D.8030305@willicon.de> <441C4088.5090905@willicon.de> <64BC1E23-FDDE-4CE6-8863-CFC881CBC224@mac.com> Message-ID: <6054EB4E-F7E0-4A9C-BDDA-D582D6D8826F@mac.com> you can find it in the rxtx-devel/contrib folder On Mar 20, 2006, at 9:05 AM, Dr. Douglas Lyon wrote: > Hi Trent, > Thanks for the info on the CVS checkout procedure. > I did that and am still not sure where the installer is. > Here is what I have: > cd MACOSX_IDE/ > p4.docjava.com{lyon}121: ls > CVS/ ForPackageMaker/ PB/ > p4.docjava.com{lyon}122: find . | more > . > ./ForPackageMaker > ./ForPackageMaker/RXTX.pkg.sit.hqx > ./ForPackageMaker/Resources > ./ForPackageMaker/Resources/ReadMe.rtf > ./ForPackageMaker/Resources/Welcome.rtf > ./ForPackageMaker/Resources/CVS > ./ForPackageMaker/Resources/CVS/Entries > ./ForPackageMaker/Resources/CVS/Repository > ./ForPackageMaker/Resources/CVS/Tag > ./ForPackageMaker/Resources/CVS/Root > ./ForPackageMaker/Resources/preinstall > ./ForPackageMaker/Resources/License.rtf > ./ForPackageMaker/Resources/preupgrade > ./ForPackageMaker/RXTX.pmsp > ./ForPackageMaker/CVS > ./ForPackageMaker/CVS/Entries > ./ForPackageMaker/CVS/Repository > ./ForPackageMaker/CVS/Entries.Log > ./ForPackageMaker/CVS/Tag > ./ForPackageMaker/CVS/Root > ./ForPackageMaker/RXTX_Tiger.pkg.sitx.hqx > ./ForPackageMaker/RXTX_Jag.pkg.sit.hqx > ./ForPackageMaker/Install > ./ForPackageMaker/Install/CVS > ./ForPackageMaker/Install/CVS/Entries > ./ForPackageMaker/Install/CVS/Repository > ./ForPackageMaker/Install/CVS/Tag > ./ForPackageMaker/Install/CVS/Root > ./ForPackageMaker/Install/Library > ./ForPackageMaker/Install/Library/CVS > ./ForPackageMaker/Install/Library/CVS/Entries > ./ForPackageMaker/Install/Library/CVS/Repository > ./ForPackageMaker/Install/Library/CVS/Tag > ./ForPackageMaker/Install/Library/CVS/Root > ./ForPackageMaker/Install/Library/Java > ./ForPackageMaker/Install/Library/Java/Extensions > ./ForPackageMaker/Install/Library/Java/Extensions/RXTXcomm.jar > ./ForPackageMaker/Install/Library/Java/Extensions/CVS > ./ForPackageMaker/Install/Library/Java/Extensions/CVS/Entries > ./ForPackageMaker/Install/Library/Java/Extensions/CVS/Repository > ./ForPackageMaker/Install/Library/Java/Extensions/CVS/Tag > ./ForPackageMaker/Install/Library/Java/Extensions/CVS/Root > ./ForPackageMaker/Install/Library/Java/Extensions/librxtxSerial.jnilib > ./ForPackageMaker/Install/Library/Java/CVS > ./ForPackageMaker/Install/Library/Java/CVS/Entries > ./ForPackageMaker/Install/Library/Java/CVS/Repository > ./ForPackageMaker/Install/Library/Java/CVS/Entries.Log > ./ForPackageMaker/Install/Library/Java/CVS/Tag > ./ForPackageMaker/Install/Library/Java/CVS/Root > ./ForPackageMaker/RXTX_Tiger.pmproj.sitx.hqx > ./CVS > ./CVS/Entries > ./CVS/Repository > ./CVS/Entries.Log > ./CVS/Tag > ./CVS/Root > ./PB > ./PB/LibSerialUniversal.xcodeproj.sitx.hqx > ./PB/CVS > ./PB/CVS/Entries > ./PB/CVS/Repository > ./PB/CVS/Entries.Log > ./PB/CVS/Tag > ./PB/CVS/Root > ./PB/LibSerial.pbproj.sit.hqx > ./PB/startpoint.c > ./PB/config.h > > What is the procedure to run this installer? > Do we need a README in: > /rxtx-devel/MACOSX_IDE > Here is what we have: > CVS/ ForPackageMaker/ PB/ > > > Thanks! > - DL > >> On Mon, 20 Mar 2006, Dr. Douglas Lyon wrote: >> >>> Hi Dimitry, >>> This sounds like great work. Just a couple of questions; >>> After the check out of the CVS files, using: >>> setenv CVSROOT :pserver:anonymous at cvs.milestonesolutions.com:/usr/ >>> local/cvsroot >>> 53 8:28 setenv PASSWORD mousy >>> 54 8:29 cvs login >>> 55 8:29 cvs checkout rxtx-devel >> >> Hi Doug >> >> You want "cvs checkout -r commapi-0-0-1 rxtx-devel" to get RXTX 2.1 >> The default branch is rxtx 2.0 which isn't very active right now. >> >> -- >> Trent Jarvi >> tjarvi at qbang.org > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx Dmitry Markman From mikehall at spacestar.net Mon Mar 20 05:25:25 2006 From: mikehall at spacestar.net (Michael Hall) Date: Mon, 20 Mar 2006 06:25:25 -0600 Subject: [Rxtx] Re: Mac OS X RXTX java installer In-Reply-To: <64BC1E23-FDDE-4CE6-8863-CFC881CBC224@mac.com> References: <07D0DE29-BA32-4CFE-B036-66BC6423D385@buechse.de> <441AE3E0.2030503@willicon.de> <12531986.1142622114996.JavaMail.dmarkman@mac.com> <441B2674.9010409@willicon.de> <13577405.1142634732776.JavaMail.dmarkman@mac.com> <441B4182.8010407@willicon.de> <92CD0D6C-5BE8-426E-A46D-99452059FF49@mac.com> <441BBB2D.8030305@willicon.de> <441C4088.5090905@willicon.de> <64BC1E23-FDDE-4CE6-8863-CFC881CBC224@mac.com> Message-ID: <247EB61F-5CD1-4132-89A2-FC105B6CF9A5@spacestar.net> On Mar 20, 2006, at 1:20 AM, Dmitry Markman wrote: > > Michael Hall (mikehall at spacestar dot net) had a suggestion to > make implementation of the jaas LoginModule > based on Greg's AuthKit > (his modification of the Greg's AuthKit could be found at http:// > www.spacestar.net/users/mikehall/authkit.dmg) > but Michael's AuthKitLoginModule does only half a job: > it does authenticate > but it can not run any external unix process in privileged mode (at > least I wasn't able to do so) If you got it working directly with Greg's the point is moot. But to clarify it anyhow. The login module does not allow you to do anything anything privileged on return as was explained by Greg. You need to work with a separate privileged process using the execPrivileged method of his API. I assume you did something similar although I haven't looked at how you are using it yet. I allowed instead for a action to be performed at the same time you login/authenticate,this... System.setProperty("authkit.action","/usr/bin/id"); just before this... lc.login(); To clarify, safely ignored as you are already complete. Mike Hall mikehall at spacestar dot net http://www.spacestar.net/users/mikehall http://sourceforge.net/projects/macnative -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2427 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20060320/f6e18202/smime-0023.bin From dmarkman at mac.com Mon Mar 20 07:36:47 2006 From: dmarkman at mac.com (Dmitry Markman) Date: Mon, 20 Mar 2006 09:36:47 -0500 Subject: [Rxtx] Re: Mac OS X RXTX java installer In-Reply-To: <247EB61F-5CD1-4132-89A2-FC105B6CF9A5@spacestar.net> References: <07D0DE29-BA32-4CFE-B036-66BC6423D385@buechse.de> <441AE3E0.2030503@willicon.de> <12531986.1142622114996.JavaMail.dmarkman@mac.com> <441B2674.9010409@willicon.de> <13577405.1142634732776.JavaMail.dmarkman@mac.com> <441B4182.8010407@willicon.de> <92CD0D6C-5BE8-426E-A46D-99452059FF49@mac.com> <441BBB2D.8030305@willicon.de> <441C4088.5090905@willicon.de> <64BC1E23-FDDE-4CE6-8863-CFC881CBC224@mac.com> <247EB61F-5CD1-4132-89A2-FC105B6CF9A5@spacestar.net> Message-ID: Hi, Michael all I have to do is to run some shell script I tried to use your action mechanism and it worked great so I just System.setProperty ("authkit.action","" ) and after that I even don't need to run anything like subject.doAs.... but after few thoughts I choose to use plain Greg's approach, because in that case I don't have to deal with various java's configurations files and therefore to use 2-3 -D parameters in the java command line especially it's useful for java web start (it's so fragile :-( ) thanks for the great job On Mar 20, 2006, at 7:25 AM, Michael Hall wrote: > > On Mar 20, 2006, at 1:20 AM, Dmitry Markman wrote: >> >> Michael Hall (mikehall at spacestar dot net) had a suggestion to >> make implementation of the jaas LoginModule >> based on Greg's AuthKit >> (his modification of the Greg's AuthKit could be found at http:// >> www.spacestar.net/users/mikehall/authkit.dmg) >> but Michael's AuthKitLoginModule does only half a job: >> it does authenticate >> but it can not run any external unix process in privileged mode >> (at least I wasn't able to do so) > > If you got it working directly with Greg's the point is moot. > > But to clarify it anyhow. > The login module does not allow you to do anything anything > privileged on return as was explained by Greg. You need to work > with a separate privileged process using the execPrivileged method > of his API. I assume you did something similar although I haven't > looked at how you are using it yet. > I allowed instead for a action to be performed at the same time you > login/authenticate,this... > System.setProperty("authkit.action","/usr/bin/id"); > just before this... > lc.login(); > To clarify, safely ignored as you are already complete. > > Mike Hall mikehall at spacestar dot net > http://www.spacestar.net/users/mikehall > http://sourceforge.net/projects/macnative > > > Dmitry Markman From dmarkman at mac.com Mon Mar 20 07:44:45 2006 From: dmarkman at mac.com (Dmitry Markman) Date: Mon, 20 Mar 2006 09:44:45 -0500 Subject: [Rxtx] Mac OS X RXTX java installer In-Reply-To: References: <07D0DE29-BA32-4CFE-B036-66BC6423D385@buechse.de> <441AE3E0.2030503@willicon.de> <12531986.1142622114996.JavaMail.dmarkman@mac.com> <441B2674.9010409@willicon.de> <13577405.1142634732776.JavaMail.dmarkman@mac.com> <441B4182.8010407@willicon.de> <92CD0D6C-5BE8-426E-A46D-99452059FF49@mac.com> <441BBB2D.8030305@willicon.de> <441C4088.5090905@willicon.de> <64BC1E23-FDDE-4CE6-8863-CFC881CBC224@mac.com> Message-ID: it's in the commapi-0-0-1 branch I tested it right now: cvs co -r commapi-0-0-1 rxtx-devel and I got everything On Mar 20, 2006, at 9:25 AM, Trent Jarvi wrote: > On Mon, 20 Mar 2006, Dr. Douglas Lyon wrote: > >> Hi Trent, >> Thanks for the info on the CVS checkout procedure. >> I did that and am still not sure where the installer is. > > Hi Doug > > It does look like it was not cvs committed. There is no rxtx-devel/ > contrib/MacOSX directory in there at the moment. It was mentioned > that it was put under contrib. > > -- > Trent Jarvi > tjarvi at qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx Dmitry Markman From tjarvi at qbang.org Mon Mar 20 07:52:57 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 20 Mar 2006 07:52:57 -0700 (MST) Subject: [Rxtx] Mac OS X RXTX java installer In-Reply-To: References: <07D0DE29-BA32-4CFE-B036-66BC6423D385@buechse.de> <441AE3E0.2030503@willicon.de> <12531986.1142622114996.JavaMail.dmarkman@mac.com> <441B2674.9010409@willicon.de> <13577405.1142634732776.JavaMail.dmarkman@mac.com> <441B4182.8010407@willicon.de> <92CD0D6C-5BE8-426E-A46D-99452059FF49@mac.com> <441BBB2D.8030305@willicon.de> <441C4088.5090905@willicon.de> <64BC1E23-FDDE-4CE6-8863-CFC881CBC224@mac.com> Message-ID: On Mon, 20 Mar 2006, Dmitry Markman wrote: > it's in the commapi-0-0-1 branch > > I tested it right now: > cvs co -r commapi-0-0-1 rxtx-devel > > and I got everything > A fresh checkout worked. Here is a copy of the tree (just the installer bits) ftp://ftp.qbang.org/pub/rxtx/MacOSX-installer.zip -- Trent Jarvi tjarvi at qbang.org From lyon at docjava.com Mon Mar 20 08:08:26 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Mon, 20 Mar 2006 10:08:26 -0500 Subject: [Rxtx] Mac OS X RXTX java installer In-Reply-To: References: <07D0DE29-BA32-4CFE-B036-66BC6423D385@buechse.de> <441AE3E0.2030503@willicon.de> <12531986.1142622114996.JavaMail.dmarkman@mac.com> <441B2674.9010409@willicon.de> <13577405.1142634732776.JavaMail.dmarkman@mac.com> <441B4182.8010407@willicon.de> <92CD0D6C-5BE8-426E-A46D-99452059FF49@mac.com> <441BBB2D.8030305@willicon.de> <441C4088.5090905@willicon.de> <64BC1E23-FDDE-4CE6-8863-CFC881CBC224@mac.com> Message-ID: Hi All, Is the Auth package able to work properly on non Mac OS's? It was not clear from the doc or download. Thanks! - Doug From dmarkman at mac.com Mon Mar 20 08:15:22 2006 From: dmarkman at mac.com (Dmitry Markman) Date: Mon, 20 Mar 2006 10:15:22 -0500 Subject: [Rxtx] Mac OS X RXTX java installer In-Reply-To: References: <07D0DE29-BA32-4CFE-B036-66BC6423D385@buechse.de> <441AE3E0.2030503@willicon.de> <12531986.1142622114996.JavaMail.dmarkman@mac.com> <441B2674.9010409@willicon.de> <13577405.1142634732776.JavaMail.dmarkman@mac.com> <441B4182.8010407@willicon.de> <92CD0D6C-5BE8-426E-A46D-99452059FF49@mac.com> <441BBB2D.8030305@willicon.de> <441C4088.5090905@willicon.de> <64BC1E23-FDDE-4CE6-8863-CFC881CBC224@mac.com> Message-ID: <217312D8-CCCA-4859-ABA6-32DF1CC817B9@mac.com> thanks Trent, for putting it on ftp server On Mar 20, 2006, at 9:52 AM, Trent Jarvi wrote: > A fresh checkout worked. Here is a copy of the tree (just the > installer bits) > > ftp://ftp.qbang.org/pub/rxtx/MacOSX-installer.zip > Dmitry Markman From dmarkman at mac.com Mon Mar 20 09:14:03 2006 From: dmarkman at mac.com (Dmitry Markman) Date: Mon, 20 Mar 2006 11:14:03 -0500 Subject: [Rxtx] Mac OS X RXTX java installer In-Reply-To: References: <07D0DE29-BA32-4CFE-B036-66BC6423D385@buechse.de> <441AE3E0.2030503@willicon.de> <12531986.1142622114996.JavaMail.dmarkman@mac.com> <441B2674.9010409@willicon.de> <13577405.1142634732776.JavaMail.dmarkman@mac.com> <441B4182.8010407@willicon.de> <92CD0D6C-5BE8-426E-A46D-99452059FF49@mac.com> <441BBB2D.8030305@willicon.de> <441C4088.5090905@willicon.de> <64BC1E23-FDDE-4CE6-8863-CFC881CBC224@mac.com> Message-ID: <4DEBA6F0-DA45-4E84-823E-1F1AC48BDCCC@mac.com> no it will work only on mac os x however it's harmless to run it on other platform if you want to use it for other platform you have to do the following (I'll do it for linux) 1. modify RXTXInstaller class method public static RXTXInstaller getInstance() public static RXTXInstaller getInstance() { String osName = System.getProperty("os.name").toLowerCase(); if(osName.startsWith("mac")){ return new gnu.io.installer.macosx.MACOSXRXTXInstaller(); } else if(osName.startsWith("windows")){ return new gnu.io.installer.windows.WindowsRXTXInstaller(); }else if(osName.startsWith("linux")){ return new gnu.io.installer.linux.LinuxRXTXInstaller(); } return null; } 2. create folder gnu/io/installer/linux/ 3. create class Linux386RXTXInstaller package gnu.io.installer.linux; import java.io.File; public class Linux386RXTXInstaller extends gnu.io.installer.RXTXInstaller{ public Linux386RXTXInstaller(){ createJarFolder(); createLibFolder(); addJarResource("RXTXcomm.jar","/gnu/io/installer/resources/ linux/jar/RXTXcomm.dat"); addLibResource("librxtxSerial.so","/gnu/io/installer/ resources/linux/lib/librxtxSerial.so"); } protected void createJarFolder(){ String javaHome = System.getProperty("java.home"); char separator = File.separatorChar; jarFolder = new File(javaHome+separator+"lib"+separator+"ext"); } protected void createLibFolder(){ String javaHome = System.getProperty("java.home"); char separator = File.separatorChar; libFolder = new File(javaHome+separator+"bin"); } public void runPreProcess() {} //put here some action you need public void runPostProcess() {} //put here some action you need } 4. create folder /gnu/io/installer/resources/linux/jar and put there linux's version of RXTXcomm.dat (which is renamed RXTXcomm.jar) 5. create folder /gnu/io/installer/resources/linux/lib and put there linux's version of librxtxSerial. so 6. make sure that RXTXInstaller.jar has the following items: /gnu/io/installer/resources/linux/jar/RXTXcomm.jar /gnu/io/installer/resources/linux/lib/librxtxSerial.so 7. modify file installer.pref: jar file RXTXInstaller.jar must have the following item /gnu/io/installer/installer.pref that's basically it for windows you have to do the similar things: just replace linux to windows and librxtxSerial.so to rxtxSerial.dll and create appropriate gnu.io.installer.windows.WindowsRXTXInstaller class package gnu.io.installer.windows; import java.io.File; public class WindowsRXTXInstaller extends gnu.io.installer.RXTXInstaller{ public WindowsRXTXInstaller(){ createJarFolder(); createLibFolder(); addJarResource("RXTXcomm.jar","/gnu/io/installer/resources/ windows/jar/RXTXcomm.dat"); addLibResource("librxtxSerial.so","/gnu/io/installer/ resources/windows/lib/rxtxSerial.dll"); } protected void createJarFolder(){ String javaHome = System.getProperty("java.home"); char separator = File.separatorChar; jarFolder = new File(javaHome+separator+"lib"+separator+"ext"); } protected void createLibFolder(){ String javaHome = System.getProperty("java.home"); char separator = File.separatorChar; libFolder = new File(javaHome+separator+"bin"); } public void runPreProcess() {} //put here some action you need public void runPostProcess() {} //put here some action you need } installer.pref will look like On Mar 20, 2006, at 10:08 AM, Dr. Douglas Lyon wrote: > Hi All, > Is the Auth package able to work properly on > non Mac OS's? > It was not clear from the doc or download. > > Thanks! > - Doug > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx Dmitry Markman From joachim at buechse.de Mon Mar 20 10:49:06 2006 From: joachim at buechse.de (Joachim Buechse) Date: Mon, 20 Mar 2006 18:49:06 +0100 Subject: [Rxtx] BUG: Lock file stays even if port opening fails Message-ID: This was only tested on MacOSX but looking at the code, it should be true for all systems that use lock_uucp. I am opening a port which can not be opened (dialup port of a telephone paired via bluetooth but currently not reachable). The lock file is created and stays arround, even though the port open failed. After looking a bit through the code (of 2.17), I really wonder if it wouldn't be a good idea to make the "locking" an explicit operation called from the java code. This would certainly simplify the generation of meaningfull exceptions (and java based debugging). Maybe even the handling of "preopened" ports should be in the Java part of the lib (again for java based debugging puposes). That beeing said, I have no idea if this would be possible for the 2.07 implementation. Regards, Joachim From tjarvi at qbang.org Mon Mar 20 11:24:22 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 20 Mar 2006 11:24:22 -0700 (MST) Subject: [Rxtx] BUG: Lock file stays even if port opening fails In-Reply-To: References: Message-ID: On Mon, 20 Mar 2006, Joachim Buechse wrote: > This was only tested on MacOSX but looking at the code, it should be true > for all systems that use lock_uucp. > > I am opening a port which can not be opened (dialup port of a telephone > paired via bluetooth but currently not reachable). The lock file is > created and stays arround, even though the port open failed. > > > After looking a bit through the code (of 2.17), I really wonder if it > wouldn't be a good idea to make the "locking" an explicit operation > called from the java code. This would certainly simplify the generation > of meaningfull exceptions (and java based debugging). > Maybe even the handling of "preopened" ports should be in the Java part > of the lib (again for java based debugging puposes). That beeing said, I > have no idea if this would be possible for the 2.07 implementation. > > Regards, Hi Joachim It should be possible in the 2.0-7 implementation too. The calls to RXTXPort.java would not change. We would just do more there Moving more of that logic into Java would be better as many people don't like to look at C code. There is a liblockdev on most Linux distros that can do most of the C code and would be easier to use. The problem is embeded devices will not have that library. The preopened port code has not been really tested. That was a last minute request in a product cycle. I expect it will be tested this year though. As I recall, some devices really do not like CD raising on open. The preopened ports then allow people to mess around in java without power cycling the devices or losing data. -- Trent Jarvi tjarvi at qbang.org From joachim at buechse.de Mon Mar 20 12:01:08 2006 From: joachim at buechse.de (Joachim Buechse) Date: Mon, 20 Mar 2006 20:01:08 +0100 Subject: [Rxtx] BUG: Lock file stays even if port opening fails In-Reply-To: References: Message-ID: Hi Trent, What is your general feeling about moving code to Java? The last days I have been reading quite a bit of the code and there are several things, that might not work as expected. I'll give you two examples from is_device_locked: if LOCKDIR == /var/spool/locks the directory /var/spool/lock will not be checked. LOCKDIR is not checked for lockfiles with unexpected pefixes While these things have probably never been discovered in production, they are still possibly incorrect implementations. If it was Java code, I would write some unit tests producing the errors that could later be corrected. PS: One could imagine to actually implement the whole lockfile handling in Java using some native routines to get the values required (pid, st_dev, st_rdev, ...). On 20.03.2006, at 19:24, Trent Jarvi wrote: > On Mon, 20 Mar 2006, Joachim Buechse wrote: > >> This was only tested on MacOSX but looking at the code, it should >> be true for all systems that use lock_uucp. >> >> I am opening a port which can not be opened (dialup port of a >> telephone paired via bluetooth but currently not reachable). The >> lock file is created and stays arround, even though the port open >> failed. >> >> >> After looking a bit through the code (of 2.17), I really wonder if >> it wouldn't be a good idea to make the "locking" an explicit >> operation called from the java code. This would certainly simplify >> the generation of meaningfull exceptions (and java based debugging). >> Maybe even the handling of "preopened" ports should be in the Java >> part of the lib (again for java based debugging puposes). That >> beeing said, I have no idea if this would be possible for the 2.07 >> implementation. >> >> Regards, > > Hi Joachim > > It should be possible in the 2.0-7 implementation too. The calls > to RXTXPort.java would not change. We would just do more there > Moving more of that logic into Java would be better as many people > don't like to look at C code. There is a liblockdev on most Linux > distros that can do most of the C code and would be easier to use. > The problem is embeded devices will not have that library. > > The preopened port code has not been really tested. That was a > last minute request in a product cycle. I expect it will be tested > this year though. As I recall, some devices really do not like CD > raising on open. The preopened ports then allow people to mess > around in java without power cycling the devices or losing data. > > -- > Trent Jarvi > tjarvi at qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Mon Mar 20 12:21:02 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 20 Mar 2006 12:21:02 -0700 (MST) Subject: [Rxtx] BUG: Lock file stays even if port opening fails In-Reply-To: References: Message-ID: On Mon, 20 Mar 2006, Joachim Buechse wrote: > Hi Trent, > > What is your general feeling about moving code to Java? The last days I > have been reading quite a bit of the code and there are several things, > that might not work as expected. > > I'll give you two examples from is_device_locked: > > if LOCKDIR == /var/spool/locks the directory /var/spool/lock will not be > checked. > LOCKDIR is not checked for lockfiles with unexpected pefixes > > While these things have probably never been discovered in production, > they are still possibly incorrect implementations. If it was Java code, I > would write some unit tests producing the errors that could later be > corrected. > > PS: One could imagine to actually implement the whole lockfile handling > in Java using some native routines to get the values required (pid, > st_dev, st_rdev, ...). Hi Joachim I like the idea of moving more of the code into java but there are some things to consider. If you break this into multiple JNI calls, the performance will drop considerably during enumeration of ports. We are looking for 256 ports per dev type vs (16? in Sun's 2.0 and fewer types). Its hard to make assumptions. I've seen virtual ports start at /dev/foo100 for instance. It works out to over 7500 ports on Linux if you enable them all. We already trim that back by default. See Linux-all-ports in RXTXCommDriver.java. There are also native libraries that rxtx can link to. If you move too much into Java, linking to 'standard' libraries with distros will break. "configure --enable-liblock=yes" will not be doable. This is probably a favorable way with RedHat, Debian, Suse and others. Thats the right thing to do if there will be rpms, dpkg, .. For those reasons, I think it still make sense to keep it to a minimal ~3 calls to JNI code that we can use for speed and versatility. lock() isLocked(), unlock() perhaps. When I say speed, its more about avoiding crossing the JNI layer multiple times than java vs C performance. With versatility I think liblock is the right way for most but not all (embeded) linux distros. -- Trent Jarvi tjarvi at qbang.org From joachim at buechse.de Mon Mar 20 12:42:04 2006 From: joachim at buechse.de (Joachim Buechse) Date: Mon, 20 Mar 2006 20:42:04 +0100 Subject: [Rxtx] BUG: Lock file stays even if port opening fails In-Reply-To: References: Message-ID: <82C19FE7-DDCB-45B6-B2C9-7606B66F0124@buechse.de> Ok, what about providing a default implementation in Java? The RXTXCommDriver would call a (native) function useNativeLocking and if it returns true, call the native functions for lock() isLocked (), unlock(), else is would use the Java based default implementation. This could possibly be overriden by a property (again for debugging). Joachim On 20.03.2006, at 20:21, Trent Jarvi wrote: > On Mon, 20 Mar 2006, Joachim Buechse wrote: > >> Hi Trent, >> >> What is your general feeling about moving code to Java? The last >> days I have been reading quite a bit of the code and there are >> several things, that might not work as expected. >> >> I'll give you two examples from is_device_locked: >> >> if LOCKDIR == /var/spool/locks the directory /var/spool/lock will >> not be checked. >> LOCKDIR is not checked for lockfiles with unexpected pefixes >> >> While these things have probably never been discovered in >> production, they are still possibly incorrect implementations. If >> it was Java code, I would write some unit tests producing the >> errors that could later be corrected. >> >> PS: One could imagine to actually implement the whole lockfile >> handling in Java using some native routines to get the values >> required (pid, st_dev, st_rdev, ...). > > Hi Joachim > > I like the idea of moving more of the code into java but there are > some things to consider. > > If you break this into multiple JNI calls, the performance will > drop considerably during enumeration of ports. We are looking for > 256 ports per dev type vs (16? in Sun's 2.0 and fewer types). Its > hard to make assumptions. I've seen virtual ports start at /dev/ > foo100 for instance. > > It works out to over 7500 ports on Linux if you enable them all. > We already trim that back by default. See Linux-all-ports in > RXTXCommDriver.java. > > There are also native libraries that rxtx can link to. If you move > too much into Java, linking to 'standard' libraries with distros > will break. "configure --enable-liblock=yes" will not be doable. > This is probably a favorable way with RedHat, Debian, Suse and > others. Thats the right thing to do if there will be rpms, dpkg, .. > > For those reasons, I think it still make sense to keep it to a > minimal ~3 calls to JNI code that we can use for speed and > versatility. lock() isLocked(), unlock() perhaps. When I say > speed, its more about avoiding crossing the JNI layer multiple > times than java vs C performance. With versatility I think liblock > is the right way for most but not all (embeded) linux distros. > > -- > Trent Jarvi > tjarvi at qbang.org > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Mon Mar 20 12:44:47 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 20 Mar 2006 12:44:47 -0700 (MST) Subject: [Rxtx] BUG: Lock file stays even if port opening fails In-Reply-To: <82C19FE7-DDCB-45B6-B2C9-7606B66F0124@buechse.de> References: <82C19FE7-DDCB-45B6-B2C9-7606B66F0124@buechse.de> Message-ID: On Mon, 20 Mar 2006, Joachim Buechse wrote: > Ok, what about providing a default implementation in Java? > > The RXTXCommDriver would call a (native) function useNativeLocking and if > it returns true, call the native functions for lock() isLocked(), > unlock(), else is would use the Java based default implementation. This > could possibly be overriden by a property (again for debugging). > Hi Joachim That would be OK with me. -- Trent Jarvi tjarvi at qbang.org From dmarkman at mac.com Mon Mar 20 22:27:45 2006 From: dmarkman at mac.com (Dmitry Markman) Date: Tue, 21 Mar 2006 00:27:45 -0500 Subject: [Rxtx] binaries request Message-ID: <42702213-C222-4937-A585-7CFB17E47608@mac.com> Hi can somebody send me latest linux and windows binaries, please? or where I can find them (I didn't find them in the latest tareball) I gave up with my cygwin: something wrong I have no idea what java doesn't understand /cygwin/c syntax after I changed makefile it did java part but after that gcc 3.4.4 started to complain I set buffer length to 999 lines but I didn't get beginning of the story something wrong with my 1.4.2_09/include/jni.h gcc doesn't like it anyway I gave up thanks in advance Dmitry Markman -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060320/f8cbc57c/attachment-0023.html From tjarvi at qbang.org Mon Mar 20 22:36:48 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 20 Mar 2006 22:36:48 -0700 (MST) Subject: [Rxtx] binaries request In-Reply-To: <42702213-C222-4937-A585-7CFB17E47608@mac.com> References: <42702213-C222-4937-A585-7CFB17E47608@mac.com> Message-ID: On Tue, 21 Mar 2006, Dmitry Markman wrote: > Hi > can somebody send me latest linux and windows binaries, please? > > or where I can find them (I didn't find them in the latest tareball) > > I gave up with my cygwin: something wrong I have no idea what > java doesn't understand /cygwin/c syntax > after I changed makefile it did java part > but after that gcc 3.4.4 started to complain > I set buffer length to 999 lines but I didn't get beginning of the story > something wrong with my 1.4.2_09/include/jni.h gcc doesn't like it > anyway I gave up > > thanks in advance > Hi Dmitry The bins are here: ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7-bins-r2.zip Here are the files in the zip you want. Jar: rxtx-2.1-7-bins-r2/RXTXcomm.jar Windows: rxtx-2.1-7-bins-r2/Windows/i368-mingw32/rxtxSerial.dll Linux (x86) rxtx-2.1-7-bins-r2/Linux/i686-unknown-linux-gnu/librxtxSerial.so There are others in there including Parallel port support but those are the main ones for testing. -- Trent Jarvi tjarvi at qbang.org From dmarkman at mac.com Mon Mar 20 23:05:59 2006 From: dmarkman at mac.com (Dmitry Markman) Date: Tue, 21 Mar 2006 01:05:59 -0500 Subject: [Rxtx] binaries request In-Reply-To: References: <42702213-C222-4937-A585-7CFB17E47608@mac.com> Message-ID: thank you very much but windows's readme says: rxtxSerial.dll had to be recomopiled to link in missing native methods. should I ignore it? or what? thanks again also I understand that I should use mingw not cygwin I'll try to install mingw On Mar 21, 2006, at 12:36 AM, Trent Jarvi wrote: > On Tue, 21 Mar 2006, Dmitry Markman wrote: > >> Hi >> can somebody send me latest linux and windows binaries, please? >> >> or where I can find them (I didn't find them in the latest tareball) >> >> I gave up with my cygwin: something wrong I have no idea what >> java doesn't understand /cygwin/c syntax >> after I changed makefile it did java part >> but after that gcc 3.4.4 started to complain >> I set buffer length to 999 lines but I didn't get beginning of the >> story >> something wrong with my 1.4.2_09/include/jni.h gcc doesn't like it >> anyway I gave up >> >> thanks in advance >> > > Hi Dmitry > > The bins are here: > > ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7-bins-r2.zip > > Here are the files in the zip you want. > > Jar: > > rxtx-2.1-7-bins-r2/RXTXcomm.jar > > Windows: > > rxtx-2.1-7-bins-r2/Windows/i368-mingw32/rxtxSerial.dll > > Linux (x86) > > rxtx-2.1-7-bins-r2/Linux/i686-unknown-linux-gnu/librxtxSerial.so > > There are others in there including Parallel port support but those > are the main ones for testing. > > -- > Trent Jarvi > tjarvi at qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx Dmitry Markman From tjarvi at qbang.org Mon Mar 20 23:20:33 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 20 Mar 2006 23:20:33 -0700 (MST) Subject: [Rxtx] binaries request In-Reply-To: References: <42702213-C222-4937-A585-7CFB17E47608@mac.com> Message-ID: On Tue, 21 Mar 2006, Dmitry Markman wrote: > thank you very much > > but windows's readme says: > rxtxSerial.dll had to be recomopiled to link in missing native methods. > > should I ignore it? or what? > Hi Dmitry That dll should be OK. r2 is the recompile linked to the missing native method. The readme explains why it was recompiled; fuser.o was not linked into the dll in the first release. -- Trent Jarvi tjarvi at qbang.org From ariantristan at yahoo.com Mon Mar 20 23:55:24 2006 From: ariantristan at yahoo.com (Lambok Sianturi) Date: Mon, 20 Mar 2006 22:55:24 -0800 (PST) Subject: [Rxtx] jvm issue Message-ID: <20060321065524.94779.qmail@web50701.mail.yahoo.com> Hi All, This is my first time to join RxTx mailing list. I thank you all for allowing others to sign in in requests help. I use the latest RxTx lib in Fedora 3 with java version 1.4.2_09 b05. And I got this error: # # An unexpected error has been detected by HotSpot Virtual Machine: # # SIGSEGV (0xb) at pc=0x00bf27f3, pid=2633, tid=3086112448 # # Java VM: Java HotSpot(TM) Client VM (1.4.2_09-b05 mixed mode) # Problematic frame: # C [ld-linux.so.2+0xa7f3] # # An error report file with more information is saved as hs_err_pid2633.log # # If you would like to submit a bug report, please visit: # http://java.sun.com/webapps/bugreport/crash.jsp # ./run.sh: line 3: 2633 Aborted /usr/local/java/bin/java -Djava.library.path=/usr/local/java/jre/lib/ -Djsmsengine.debug=true -classpath jsmsengine.jar:smsgateway.jar:classes12.jar:RXTXcomm.jar:. com.api.sms.SMSServer What is the jvm depedency for the latest library? Can I use 1.4.2_09 b05? Thanks in advance. Arian --------------------------------- Yahoo! Mail Use Photomail to share photos without annoying attachments. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060320/83d58dd7/attachment-0023.html From f.frumento at ngi.it Tue Mar 21 00:21:47 2006 From: f.frumento at ngi.it (Fabio Frumento) Date: Tue, 21 Mar 2006 08:21:47 +0100 Subject: [Rxtx] Javadoc on the go Message-ID: <441FA98B.9050701@ngi.it> Hi Trent, sorry for the big delay but my job is running wild, i was out for some time but now i'm back and ready to continue the javadoc for Rxtx. Did you used the last javadoc patch i sent you ? let me know if i have to send it to you again or not. regards Fabio From lyon at docjava.com Tue Mar 21 00:51:18 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Tue, 21 Mar 2006 02:51:18 -0500 Subject: [Rxtx] lock files Message-ID: Hi All, You know, if the use of lock files were under Java control (rather than a build-time decision), it might enable a more unified binary distro. It might also facilitate quick prototyping of non-lock file approaches to resolving serial port contention issues (i.e., mac-like approaches vs. linux approaches, etc.). I realize that this is a radical overhaul of the lock file policy issue. Also, it may harm performance. On the other hand, our benchmarks on JNI overhead for modern processors indicate performance impact should be minimal. Perhaps it is more of an issue with the toybox systems. Suppose there were a class with a reasonable default...someone might write: SerialPortLockPolicy.setPolicy(SerialPortLockPolicy.UNIX_LOCK_FILE); SerialPortLockPolicy.setPolicy(SerialPortLockPolicy.NO_LOCK_CHECKING); SerialPortLockPolicy.setPolicy(SerialPortLockPolicy.MAC_STYLE); Thus, we could have a run-time reconfiguration of the serial port lock policy. A special NO_LOCK version of the binary would no longer be required. Any thoughts on this? Thanks! - Doug From joachim at buechse.de Tue Mar 21 03:09:09 2006 From: joachim at buechse.de (Joachim Buechse) Date: Tue, 21 Mar 2006 11:09:09 +0100 Subject: [Rxtx] lock files In-Reply-To: References: Message-ID: <8E12916A-1B9A-4FF2-B684-E2D1C794221B@buechse.de> This is pretty much what I thought about when I suggested, that the default behaviour could be overwritten with a property. I am very much in favor of this approach. In particular this allows much easier debugging for PC based java developers. I think big parts of the Java (and maybe some parts of the C code) could use a bit of a structural workover (unit tests, javadoc, synchronization, etc). Maybe there should be a CVS branch for this experimental version. I'd be happy to contribute a first workover for some of the Java code. Designing for testability and implementing a good bunch of unit tests has been a strategy that worked quite well in the Java projects I lead. And it ultimately allows more liberal change permission. Regards, Joachim On 21.03.2006, at 08:51, Dr. Douglas Lyon wrote: > Hi All, > You know, if the use of lock files were > under Java control (rather than a build-time decision), > it might enable a more unified binary distro. It might also > facilitate quick prototyping of non-lock file approaches > to resolving serial port contention issues (i.e., mac-like > approaches vs. linux approaches, etc.). > > I realize that this is a radical overhaul of the lock file policy > issue. Also, it may harm performance. On the other hand, > our benchmarks on JNI overhead for modern processors indicate > performance impact should be minimal. Perhaps it is more of > an issue with the toybox systems. > > Suppose there were a class with a reasonable default...someone > might write: > SerialPortLockPolicy.setPolicy(SerialPortLockPolicy.UNIX_LOCK_FILE); > SerialPortLockPolicy.setPolicy(SerialPortLockPolicy.NO_LOCK_CHECKING); > SerialPortLockPolicy.setPolicy(SerialPortLockPolicy.MAC_STYLE); > > Thus, we could have a run-time reconfiguration of the serial port lock > policy. A special NO_LOCK version of the binary would no longer > be required. > > Any thoughts on this? > > Thanks! > - Doug > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From joachim at buechse.de Tue Mar 21 06:23:08 2006 From: joachim at buechse.de (Joachim Buechse) Date: Tue, 21 Mar 2006 14:23:08 +0100 Subject: [Rxtx] PATCH: use of ioctl(fd, TIOCEXCL) instead of lockfiles Message-ID: <923AE774-EEA2-4911-92D8-32BB27802C8B@buechse.de> Here is the patch for the ioctl(fd, TIOCEXCL). I have verified this only for OSX 10.4.5, hence it is only defined for APPLE. However, it should work at least for Solaris as well. If a process has requested TIOEXCL further open calls by other user processes will fail. The patch also disables uucp style locking for APPLE. Obviously this is discussable. I think it is the way to go, as it eliminates creating the lock directory which doesnt exist on the standard installation and it eliminates messing with the system group definitions (adding users to group uucp). Regarding the possibility of root processes opening a device which is locked - I consider this a feature not a potential problem. It is highly unlikely, that somebody is crazy enough to run a JavaVM as root (unless he has no other means of getting a restricted IP port opened, ie doesnt understand ipfw). Anyway, even if the process runs as root, it fails when calling ioctl(fd, TIOCEXCL). It could however still open the port to listen for RING events. I.e. a fax server which needs to see incoming calls but otherwise doesnt want to block the port. So the only case where the proposed mechanism fails is, if an incorrectly implemented process running as root conflicts with a user process. I think this can be accepted. Regards, Joachim PS: If this patch is generally accepted, the installer and Mac doku should obviously be changed as well. Index: SerialImp.c =================================================================== RCS file: /usr/local/cvsroot/rxtx-devel/src/SerialImp.c,v retrieving revision 1.46.2.187 diff -u -r1.46.2.187 SerialImp.c --- SerialImp.c 29 Jan 2006 22:19:04 -0000 1.46.2.187 +++ SerialImp.c 21 Mar 2006 12:59:16 -0000 @@ -656,6 +656,25 @@ fd=OPEN (filename, O_RDWR | O_NOCTTY | O_NONBLOCK ); } while (fd < 0 && errno==EINTR); +#ifdef OPEN_EXCL + // Note that open() follows POSIX semantics: multiple open() calls to + // the same file will succeed unless the TIOCEXCL ioctl is issued. + // This will prevent additional opens except by root-owned processes. + // See tty(4) ("man 4 tty") and ioctl(2) ("man 2 ioctl") for details. + + if (fd >= 0 && (ioctl(fd, TIOCEXCL) == -1)) + { + sprintf( message, "open: exclusive access denied for % s\n", + filename ); + report( message ); + report_error( message ); + + close(fd); + goto fail; + } +#endif /* OPEN_EXCL */ + + if( configure_port( fd ) ) goto fail; (*env)->ReleaseStringUTFChars( env, jstr, filename ); sprintf( message, "open: fd returned is %i\n", fd ); Index: SerialImp.h =================================================================== RCS file: /usr/local/cvsroot/rxtx-devel/src/SerialImp.h,v retrieving revision 1.11.2.49 diff -u -r1.11.2.49 SerialImp.h --- SerialImp.h 5 Jul 2005 17:47:21 -0000 1.11.2.49 +++ SerialImp.h 21 Mar 2006 12:59:17 -0000 @@ -135,7 +135,8 @@ /*# define LOCKDIR "/var/spool/uucp"*/ # define LOCKDIR "/var/lock" # define LOCKFILEPREFIX "LK." -# define UUCP +/*# define UUCP*/ +# define OPEN_EXCL #endif /* __APPLE__ */ #if defined(__NetBSD__) # define DEVICEDIR "/dev/" From tjarvi at qbang.org Tue Mar 21 10:26:08 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 21 Mar 2006 10:26:08 -0700 (MST) Subject: [Rxtx] Javadoc on the go In-Reply-To: <441FA98B.9050701@ngi.it> References: <441FA98B.9050701@ngi.it> Message-ID: On Tue, 21 Mar 2006, Fabio Frumento wrote: > Hi Trent, > > sorry for the big delay but my job is running wild, i was out for some > time but now i'm back and ready to continue the javadoc for Rxtx. > > Did you used the last javadoc patch i sent you ? let me know if i have to > send it to you again or not. > > regards > > Fabio Hi Fabio The patch is in the rxtx mail-list archives. It will be going in soon. I did not see a time critical portion. I'll probably be going through the list since the last batch of patches this weekend and putting them into CVS. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Tue Mar 21 10:57:18 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 21 Mar 2006 10:57:18 -0700 (MST) Subject: [Rxtx] jvm issue In-Reply-To: <20060321065524.94779.qmail@web50701.mail.yahoo.com> References: <20060321065524.94779.qmail@web50701.mail.yahoo.com> Message-ID: On Mon, 20 Mar 2006, Lambok Sianturi wrote: > Hi All, > This is my first time to join RxTx mailing list. I thank you all for allowing others to sign in in requests help. > I use the latest RxTx lib in Fedora 3 with java version 1.4.2_09 b05. And I got this error: > > # > # An unexpected error has been detected by HotSpot Virtual Machine: > # > # SIGSEGV (0xb) at pc=0x00bf27f3, pid=2633, tid=3086112448 > # > # Java VM: Java HotSpot(TM) Client VM (1.4.2_09-b05 mixed mode) > # Problematic frame: > # C [ld-linux.so.2+0xa7f3] A native library loading error? What happens if you recompile rxtx on your system and install that? This sounds like an ABI problem? rxtx 2.1-7 was compiled with a gcc 2.96 toolchain as I recall. The hope is newer system will be backwards compatible. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Tue Mar 21 11:05:29 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 21 Mar 2006 11:05:29 -0700 (MST) Subject: [Rxtx] PATCH: use of ioctl(fd, TIOCEXCL) instead of lockfiles In-Reply-To: <923AE774-EEA2-4911-92D8-32BB27802C8B@buechse.de> References: <923AE774-EEA2-4911-92D8-32BB27802C8B@buechse.de> Message-ID: On Tue, 21 Mar 2006, Joachim Buechse wrote: > Here is the patch for the ioctl(fd, TIOCEXCL). I have verified this only > for OSX 10.4.5, hence it is only defined for APPLE. However, it should > work at least for Solaris as well. > > If a process has requested TIOEXCL further open calls by other user > processes will fail. > > The patch also disables uucp style locking for APPLE. Obviously this is > discussable. I think it is the way to go, as it eliminates creating the > lock directory which doesnt exist on the standard installation and it > eliminates messing with the system group definitions (adding users to > group uucp). > > Regarding the possibility of root processes opening a device which is > locked - I consider this a feature not a potential problem. It is highly > unlikely, that somebody is crazy enough to run a JavaVM as root (unless > he has no other means of getting a restricted IP port opened, ie doesnt > understand ipfw). Anyway, even if the process runs as root, it fails when > calling ioctl(fd, TIOCEXCL). It could however still open the port to > listen for RING events. I.e. a fax server which needs to see incoming > calls but otherwise doesnt want to block the port. So the only case where > the proposed mechanism fails is, if an incorrectly implemented process > running as root conflicts with a user process. I think this can be > accepted. > > Regards, > Joachim > > PS: If this patch is generally accepted, the installer and Mac doku > should obviously be changed as well. > > > Index: SerialImp.c > =================================================================== > RCS file: /usr/local/cvsroot/rxtx-devel/src/SerialImp.c,v > retrieving revision 1.46.2.187 > diff -u -r1.46.2.187 SerialImp.c > --- SerialImp.c 29 Jan 2006 22:19:04 -0000 1.46.2.187 > +++ SerialImp.c 21 Mar 2006 12:59:16 -0000 > @@ -656,6 +656,25 @@ > fd=OPEN (filename, O_RDWR | O_NOCTTY | O_NONBLOCK ); > } while (fd < 0 && errno==EINTR); > > +#ifdef OPEN_EXCL > + // Note that open() follows POSIX semantics: multiple open() > calls to > + // the same file will succeed unless the TIOCEXCL ioctl is > issued. > + // This will prevent additional opens except by root-owned > processes. > + // See tty(4) ("man 4 tty") and ioctl(2) ("man 2 ioctl") for > details. > + > + if (fd >= 0 && (ioctl(fd, TIOCEXCL) == -1)) > + { > + sprintf( message, "open: exclusive access denied for % > s\n", > + filename ); > + report( message ); > + report_error( message ); > + > + close(fd); > + goto fail; > + } > +#endif /* OPEN_EXCL */ > + > + > if( configure_port( fd ) ) goto fail; > (*env)->ReleaseStringUTFChars( env, jstr, filename ); > sprintf( message, "open: fd returned is %i\n", fd ); > Index: SerialImp.h > =================================================================== > RCS file: /usr/local/cvsroot/rxtx-devel/src/SerialImp.h,v > retrieving revision 1.11.2.49 > diff -u -r1.11.2.49 SerialImp.h > --- SerialImp.h 5 Jul 2005 17:47:21 -0000 1.11.2.49 > +++ SerialImp.h 21 Mar 2006 12:59:17 -0000 > @@ -135,7 +135,8 @@ > /*# define LOCKDIR "/var/spool/uucp"*/ > # define LOCKDIR "/var/lock" > # define LOCKFILEPREFIX "LK." > -# define UUCP > +/*# define UUCP*/ > +# define OPEN_EXCL > #endif /* __APPLE__ */ > #if defined(__NetBSD__) > # define DEVICEDIR "/dev/" > This looks like a good start. What do you think Dmitry? Perhaps all systems with TIOCEXCL defined should use that though. Even if they use lockfiles. It wont hurt anything. That would catch people hacking their own serial apps without checking lockfiles. Its a good idea to avoid C++ style comments in the C portions. Some older systems don't deal with them well. If it's just for Mac OS X, it isn't a big deal. I think it was the Irix compiler that was problematic? -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Tue Mar 21 11:22:05 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 21 Mar 2006 11:22:05 -0700 (MST) Subject: [Rxtx] lock files In-Reply-To: <8E12916A-1B9A-4FF2-B684-E2D1C794221B@buechse.de> References: <8E12916A-1B9A-4FF2-B684-E2D1C794221B@buechse.de> Message-ID: We can try it. Maybe the JNI is much improved. The nice thing about linking into liblock is distros then worry about lockfiles on their systems. This way, we have to deal with any changes that may show up. On Tue, 21 Mar 2006, Joachim Buechse wrote: > This is pretty much what I thought about when I suggested, that the > default behaviour could be overwritten with a property. I am very much in > favor of this approach. In particular this allows much easier debugging > for PC based java developers. > > I think big parts of the Java (and maybe some parts of the C code) could > use a bit of a structural workover (unit tests, javadoc, synchronization, > etc). Maybe there should be a CVS branch for this experimental version. > I'd be happy to contribute a first workover for some of the Java code. > Designing for testability and implementing a good bunch of unit tests has > been a strategy that worked quite well in the Java projects I lead. And > it ultimately allows more liberal change permission. > > Regards, > Joachim > > > On 21.03.2006, at 08:51, Dr. Douglas Lyon wrote: > >> Hi All, >> You know, if the use of lock files were >> under Java control (rather than a build-time decision), >> it might enable a more unified binary distro. It might also >> facilitate quick prototyping of non-lock file approaches >> to resolving serial port contention issues (i.e., mac-like >> approaches vs. linux approaches, etc.). >> >> I realize that this is a radical overhaul of the lock file policy >> issue. Also, it may harm performance. On the other hand, >> our benchmarks on JNI overhead for modern processors indicate >> performance impact should be minimal. Perhaps it is more of >> an issue with the toybox systems. >> >> Suppose there were a class with a reasonable default...someone >> might write: >> SerialPortLockPolicy.setPolicy(SerialPortLockPolicy.UNIX_LOCK_FILE); >> SerialPortLockPolicy.setPolicy(SerialPortLockPolicy.NO_LOCK_CHECKING); >> SerialPortLockPolicy.setPolicy(SerialPortLockPolicy.MAC_STYLE); >> >> Thus, we could have a run-time reconfiguration of the serial port lock >> policy. A special NO_LOCK version of the binary would no longer >> be required. >> >> Any thoughts on this? >> >> Thanks! >> - Doug >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From dmarkman at mac.com Tue Mar 21 16:05:17 2006 From: dmarkman at mac.com (Dmitry Markman) Date: Tue, 21 Mar 2006 18:05:17 -0500 Subject: [Rxtx] PATCH: use of ioctl(fd, TIOCEXCL) instead of lockfiles In-Reply-To: References: <923AE774-EEA2-4911-92D8-32BB27802C8B@buechse.de> Message-ID: <512AC70C-BB86-48F2-A83C-023F35C23BAB@mac.com> I think it's cool, but I'd like to have that property implementation when user can choose between locking mechanism about comments: it's easy to change comments to the C style or we can use extensions of the file to cpp so c++ compiler will be used On Mar 21, 2006, at 1:05 PM, Trent Jarvi wrote: > This looks like a good start. What do you think Dmitry? Perhaps > all systems with TIOCEXCL defined should use that though. Even if > they use lockfiles. It wont hurt anything. That would catch > people hacking their own serial apps without checking lockfiles. > > Its a good idea to avoid C++ style comments in the C portions. > Some older systems don't deal with them well. If it's just for Mac > OS X, it isn't a big deal. I think it was the Irix compiler that > was problematic? Dmitry Markman From dmarkman at mac.com Tue Mar 21 16:13:00 2006 From: dmarkman at mac.com (Dmitry Markman) Date: Tue, 21 Mar 2006 18:13:00 -0500 Subject: [Rxtx] PATCH: use of ioctl(fd, TIOCEXCL) instead of lockfiles In-Reply-To: References: <923AE774-EEA2-4911-92D8-32BB27802C8B@buechse.de> Message-ID: I'd like to add that creating locking folder isn't a big deal we never had a problem related to the lock folders, because we always used installer on mac os x from other hand I'm not very much familiar with iotcl locking approach and I'm not sure it's more efficient Joachim wrote "I think it is the way to go, as it eliminates creating the lock directory which doesnt exist on the standard installation and it eliminates messing with the system group definitions (adding users to group uucp)." but I really didn't have any problem with that 1. doesn't exist on the standard installation there are many-many things that don't exist in the standard installation so I don't think that argument is strong enough 2. messing with the system group definitions I don't think we're messing with the group definition mac os x provides very clear way to set up group's members and together with Greg Guerin AuthKit there is no problem to set those definitions so I don't think that argument is strong either but from other hand using iotcl is more promising and is more elegant On Mar 21, 2006, at 1:05 PM, Trent Jarvi wrote: > > This looks like a good start. What do you think Dmitry? Perhaps > all systems with TIOCEXCL defined should use that though. Even if > they use lockfiles. It wont hurt anything. That would catch > people hacking their own serial apps without checking lockfiles. Dmitry Markman From joachim at buechse.de Wed Mar 22 04:46:45 2006 From: joachim at buechse.de (Joachim Buechse) Date: Wed, 22 Mar 2006 12:46:45 +0100 Subject: [Rxtx] PATCH: use of ioctl(fd, TIOCEXCL) instead of lockfiles In-Reply-To: References: <923AE774-EEA2-4911-92D8-32BB27802C8B@buechse.de> Message-ID: Sorry, I was not very clear with my arguments, so I will try again;-) Please, don't take this as an attack against work that has been done. I think the contributions that have been made in the past were made in a good spirit. But I really believe, that the current solution for OSX has many shortcomings and should be changed as soon as possible. lock files --- The /var/lock folder does not exist on the standard OSX installation, however the standard installation includes several applications that use serial ports (i.e. the FAX capability). This indicates, that the lock folder approach will not work well with system components. Applications for OSX will generally try to live in harmony with system components (except for HP print drivers of course). I think RXTX should follow this approach as well. uucp group --- Accessing serial ports is not an admin privileged operation on OSX. Any user (world) has read/write privileges on /dev/tty*. So the system default is to not enforce any group membership to access these ports. The group uucp however is a system group on all unix systems I know. It exists for certain system processes. A non admin user should in general not be a member of this group. Quite arguably no user should ever be a member of this group. Installer --- My general opinion is, that - no Installer should touch user or group data without warning - no Application Installer should touch groups which are not specific to the very application installed - no Installer should ever add regular users to a system group The current installer injects the installing user in the group uucp without warning about this change and without giving the option to "opt out" of this change. This is a potential security risk (but not currently a real one, as OSX contains no folders belonging to group uucp). The current installer does not work for multi user systems. It puts the installing user in the uucp group. However the installing user is not necessarily the user that will use the application. Putting all users that may use a serial port application in the system group uucp seems like a very invasive approach to me. Besides that, newly created users will not automatically be in the group and hence, serial applications will "break" for new users without obvious reasons. Avoiding the lock files will allow self contained applications (i.e. drag&drop installation). In my eyes this is largely preferable over an installer that requests admin privileges. Adding up all these points indicates very strongly, that the lock-file implementation is not the way to go on OSX. Regards, Joachim On 22.03.2006, at 00:13, Dmitry Markman wrote: > I'd like to add that > > creating locking folder isn't a big deal > we never had a problem related to the lock folders, because we > always used installer on mac os x > from other hand I'm not very much familiar with iotcl locking > approach and I'm not sure it's more efficient > > Joachim wrote "I think it is the way to go, as it eliminates > creating the lock directory which doesnt exist on the standard > installation and it eliminates messing with the system group > definitions (adding users to group uucp)." but I really didn't have > any problem with that > > 1. doesn't exist on the standard installation > there are many-many things that don't exist in the standard > installation so I don't think that argument is strong enough > 2. messing with the system group definitions > I don't think we're messing with the group definition > mac os x provides very clear way to set up group's members and > together with Greg Guerin AuthKit there is no problem to set those > definitions > so I don't think that argument is strong either > but from other hand using iotcl is more promising and is more elegant > > > > On Mar 21, 2006, at 1:05 PM, Trent Jarvi wrote: > >> >> This looks like a good start. What do you think Dmitry? Perhaps >> all systems with TIOCEXCL defined should use that though. Even if >> they use lockfiles. It wont hurt anything. That would catch >> people hacking their own serial apps without checking lockfiles. > > Dmitry Markman > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From dmarkman at mac.com Wed Mar 22 05:27:13 2006 From: dmarkman at mac.com (Dmitry Markman) Date: Wed, 22 Mar 2006 07:27:13 -0500 Subject: [Rxtx] PATCH: use of ioctl(fd, TIOCEXCL) instead of lockfiles In-Reply-To: References: <923AE774-EEA2-4911-92D8-32BB27802C8B@buechse.de> Message-ID: <83440CF3-DCD8-41C1-B941-F227232C27E3@mac.com> thanks for the very good explanation I didn't think that you were attacking any thing, so don't worry I just had feeling, that there were more aesthetic reasons for going to ioctl then real necessity now you explained everything quite well (BTW, asfar as I remember installer asks admin password so it wasn't quiet, but it really doesn't matter now) thanks On Mar 22, 2006, at 6:46 AM, Joachim Buechse wrote: > Sorry, I was not very clear with my arguments, so I will try again;-) > > Please, don't take this as an attack against work that has been > done. I think the contributions that have been made in the past > were made in a good spirit. But I really believe, that the current > solution for OSX has many shortcomings and should be changed as > soon as possible. > > lock files > --- > The /var/lock folder does not exist on the standard OSX > installation, however the standard installation includes several > applications that use serial ports (i.e. the FAX capability). This > indicates, that the lock folder approach will not work well with > system components. Applications for OSX will generally try to live > in harmony with system components (except for HP print drivers of > course). I think RXTX should follow this approach as well. > > uucp group > --- > Accessing serial ports is not an admin privileged operation on OSX. > Any user (world) has read/write privileges on /dev/tty*. So the > system default is to not enforce any group membership to access > these ports. The group uucp however is a system group on all unix > systems I know. It exists for certain system processes. A non admin > user should in general not be a member of this group. Quite > arguably no user should ever be a member of this group. > > Installer > --- > My general opinion is, that > - no Installer should touch user or group data without warning > - no Application Installer should touch groups which are not > specific to the very application installed > - no Installer should ever add regular users to a system group > > The current installer injects the installing user in the group uucp > without warning about this change and without giving the option to > "opt out" of this change. This is a potential security risk (but > not currently a real one, as OSX contains no folders belonging to > group uucp). > > The current installer does not work for multi user systems. It puts > the installing user in the uucp group. However the installing user > is not necessarily the user that will use the application. Putting > all users that may use a serial port application in the system > group uucp seems like a very invasive approach to me. Besides that, > newly created users will not automatically be in the group and > hence, serial applications will "break" for new users without > obvious reasons. > > > Avoiding the lock files will allow self contained applications > (i.e. drag&drop installation). In my eyes this is largely > preferable over an installer that requests admin privileges. Adding > up all these points indicates very strongly, that the lock-file > implementation is not the way to go on OSX. > > Regards, > Joachim > > > On 22.03.2006, at 00:13, Dmitry Markman wrote: > >> I'd like to add that >> >> creating locking folder isn't a big deal >> we never had a problem related to the lock folders, because we >> always used installer on mac os x >> from other hand I'm not very much familiar with iotcl locking >> approach and I'm not sure it's more efficient >> >> Joachim wrote "I think it is the way to go, as it eliminates >> creating the lock directory which doesnt exist on the standard >> installation and it eliminates messing with the system group >> definitions (adding users to group uucp)." but I really didn't >> have any problem with that >> >> 1. doesn't exist on the standard installation >> there are many-many things that don't exist in the standard >> installation so I don't think that argument is strong enough >> 2. messing with the system group definitions >> I don't think we're messing with the group definition >> mac os x provides very clear way to set up group's members and >> together with Greg Guerin AuthKit there is no problem to set those >> definitions >> so I don't think that argument is strong either >> but from other hand using iotcl is more promising and is more elegant >> >> >> >> On Mar 21, 2006, at 1:05 PM, Trent Jarvi wrote: >> >>> >>> This looks like a good start. What do you think Dmitry? Perhaps >>> all systems with TIOCEXCL defined should use that though. Even >>> if they use lockfiles. It wont hurt anything. That would catch >>> people hacking their own serial apps without checking lockfiles. >> >> Dmitry Markman >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx Dmitry Markman From lyon at docjava.com Wed Mar 22 06:12:18 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Wed, 22 Mar 2006 08:12:18 -0500 Subject: [Rxtx] sole of a new design pattern Message-ID: Hi All, I have been thinking about how we design the serial port software. I think we need a new design pattern. For lack of a better term, I shall call it: The Parametric Singleton Design Pattern By Douglas A. Lyon ABSTRACT The goal of the singleton design pattern is to make sure that there is one, and only one, instance of a given class. The goal of the parametric singleton design pattern is to make sure that there is one, and only one, instance of a given class with the given parametric values. We parametric singleton design pattern combines the singleton design pattern with a parameter that enables unique creation of instances of a class. These instances are cached. When a user asks for an instance with these parameters, the cache is checked. If the instance is in the cache, the instance is returned, otherwise it is created, added to the cache and then returned. We apply our parametric singleton design pattern to the retrieval of RMI registries bound to a given port. The goal of our system is to make sure that no two RMI registries are listening to the same socket and to make use of the RMI registries after they have been created. RMI registries are used in distributed computation. Introduction The singleton design pattern is meant to ensure that on a single instance of a class exists. It is also meant to provide a global point of access to it. The intent of the parametric singleton design pattern is to ensure that a class has only one instance for a given set of parameter values. It also provides a global point of access to it. Motivation A system cannot tolerate multiple instances of some classes with identical parameters. For example, you cannot have two instances making use of the same serial port, at the same time. You cannot have two instances that are trying to listen to the same socket connection. You cannot have two instances writing to the same file structure at the same time. As the operating system is often thought of as the arbiter of consumed resources (i.e., tape drives, serial ports, etc.) we frequently leave it to an operating system implementation to resolve these contention issues. Even for similar resources (like serial ports) there are few standards for handling contention. For example, serial ports on Linux are locked using a "/var/lock" file. POSIX, on the other hand, uses ioctl mechanisms to prevent contention. A better solution is to make a class that is responsible for keeping track of the instances created from the class. The class is declared final, so that it cannot be subclassed. The class also has a private constructor, so that other classes cannot instance it. The new design pattern is called the parametric singleton design pattern and it provides a way to access and create instances with given parameters. Applicability Use the Parametric Singleton Design Pattern when: 1. There must be exactly one instance of a class with the given parameters. 2. The instances must be accessible to clients from a well-known access point. Structure Insert UML diagram here. Participants The Parametric Singleton Clients that need instances 1. The Parametric Singleton defines an instance upon request from a client, if, and only if, the instance does not already exist. 2. The Parametric Singleton returns the instance to the client. 3. The Parametric Singleton is responsible for creating unique instances from given parameters. Collaborations Clients obtain a reference to a Parametric Singleton instance only through the parametric singleton design pattern. If the instance is left in an improper state (e.g., the serial port was left open) it is NOT the role of the Parametric Singleton Design Pattern to close the IO port. Nor is it the role of the Parametric Singleton Design Pattern to open the port. That role is delegate to some other part of the system. Further, it is not the role of the Parametric Singleton Design Pattern to check out resources. That is, multiple threads can have multiple references to the same resource at the same time. MUTEX locking is delegated to some other part of the system. Consequences The Parametric Singleton Design Pattern has several benefits: 1. Controlled access to parametrically defined instances. Since the Parametric Singleton class encapsulates its instances, there is control over how and when clients access it. 2. Reduced name space. The Parametric Singleton pattern avoids global variables that store instances created from the same parameter. Implementation Here are implementation issues to consider when using the Parametric Singleton pattern: 1. Unique mapping of parameters. The Parametric Singleton pattern requires that there be a mean to isomorphically map the parameter space into the instance space and back again. 2. Ensure unique instances. The Parametric Singleton pattern makes unique instances from parameters, and it does so only once. 3. Cache instances for fast retrieval. The Parametric Singleton pattern must be able to look up instances, given some set of parameters, and do so from some data structure. That is, there must be enough space to hold references to all the instances the program will need. Also, a mechanism is needed to look up and retrieve the instances quickly enough to satisfy the clients. Sample Code public final class ParametricSingletonRmiRegistry { private static Hashtable registry = new Hashtable(100); // use singleton pattern and??????????????????????????????????????????????? // prevent instantiation of RmiRegistryUtils.?????????????????????????????? private ParametricSingletonRmiRegistry() { } // the only instance of the Registry held by the RmiRegistryUtils?????????? public static void listNames(Integer port) { if (!isInCacheAndRunning(port)) return; Registry r = (Registry) registry.get(port); System.out.println("registry on port: " + port); System.out.println("registry: " + r); System.out.println("names: "); try { print(r.list()); } catch (RemoteException e) { In.message(e); } System.out.println("------------------------"); } /**???????????????????????????????????????????????????????????????????????? * Checks whether a Registry has been started on this host????????????????? * in the specified port.?????????????????????????????????????????????????? * If not, it tries to start one.?????????????????????????????????????????? * when it fails to start a Registry, it exits the program????????????????? * with exit code 1.??????????????????????????????????????????????????????? */ public static void restart(int port) { if (isInCacheAndRunning(port)) return; try { startRegistry(port); } catch (RemoteException e) { In.message(e); } } /**???????????????????????????????????????????????????????????????????????? * @param port????????????????????????????????????????????????????????????? * @return true if registry is in cache and running???????????????????????? */ private static boolean isInCacheAndRunning(Integer port) { if (!isRegistryRunning(port.intValue())) return false; if (!isRegistryInCache(port.intValue())) return false; return true; } /**???????????????????????????????????????????????????????????????????????? * @param port????????????????????????????????????????????????????????????? * @return true if we are able to locate a local registry on port.??????????????????????????????????????????????????????????????????????????? */ private static boolean isRegistryRunning(int port) { try { Registry r = LocateRegistry.getRegistry(port); if (r != null) return true; } catch (RemoteException e) { return false; } return false; } /**???????????????????????????????????????????????????????????????????????? * @param port????????????????????????????????????????????????????????????? * @return return true if registry is in cache????????????????????????????? */ private static boolean isRegistryInCache(int port) { if (registry.get(new Integer(port)) == null) return false; return true; } /**???????????????????????????????????????????????????????????????????????? * Restart the registry, if needed.???????????????????????????????????????? * Return the only instance of the registry for consistent global?????????? * using by making use of the Singleton Design Pattern????????????????????? *????????????????????????????????????????????????????????????????????????? * @return the internally held registry instance.?????????????????????????? */ public static Registry getRegistry(Integer port) { restart(port); return (Registry) registry.get(port); } private static void startRegistry(Integer port) throws RemoteException { Registry r; try { r = LocateRegistry.createRegistry(port.intValue()); registry.put(port, r); //r = new sun.rmi.registry.RegistryImpl???????????????????????????? /// (port.intValue());?????????????????????????????????????? // registry.put(port, r);?????????????????????????????????????????? } catch (Exception e) { //e.printStackTrace();????????????????????????????????????????????? r = LocateRegistry.getRegistry(port.intValue()); registry.put(port, r); } } public static void main(String args[]) throws RemoteException { //restart(port);??????????????????????????????????????????????????????? restart(5001); restart(5002); restart(5002); Registry r = LocateRegistry.getRegistry(5002); System.out.println("registry="+r); } } I would very much like to get your feedback on this new design pattern idea. Thank you for your time. Regards, - Doug From david.garnier at trusted-logic.com Wed Mar 22 07:36:10 2006 From: david.garnier at trusted-logic.com (David Garnier) Date: Wed, 22 Mar 2006 15:36:10 +0100 Subject: [Rxtx] sole of a new design pattern In-Reply-To: References: Message-ID: <442160DA.80107@trusted-logic.com> Hello, > The Parametric Singleton Design Pattern The Singleton is the most abused design pattern ever. Good use-cases for this pattern are extremely rare and mostly confined to problems related to hardware resources, like serial ports. > Applicability > > Use the Parametric Singleton Design Pattern when: > 1. There must be exactly one instance of a class with the given > parameters. OK. As I said above, this case this actually very unusual. The Singleton pattern is mostly used when : > 2. The instances must be accessible to clients from a well-known > access point. Using the singleton pattern in this case is just convenient for the programmer. Problems arises pretty quickly, especially if you attempt to unit-test your classes. 1) If your singleton is stateful, or hold on to stateful objects, it means that two different unit tests are not actually independent. Instead of starting with a brand new environment, the result of a test may be affected by the result of a previous test. This problem also arise when with your class relies on a database. In both cases, the solution is to reset your "unique" resource (Singleton or database) at the beginning of the test, which is a pain. Also, while most projects connect to a single database, projects that allow the use of Singletons usually contain several of thems, and new ones may cropped up unnoticed. You quickly end up with test cases that only pass in a certain order, which is a royal pain. 2) You cannot mockup a singleton. Once everyone calls the SomeSingleton class statically, you can't replace your class by SomeSingletonMockup. Furthermore, even for hardware services, the Singleton pattern does not really prevent concurrent accesses. If you start the same program in two different JVMs, unless they somehow shared the state of their "Singletons" (through lock files for example), the Singleton pattern will not prevent concurrent access. Our application uses RXTX, and we routinely encounter cases where another (native) application has already locked the port. Since we cannot modify the native application to recognize lock files, OS-level control is irreplaceable. > > Consequences > The Parametric Singleton Design Pattern has several benefits: > > 1. Controlled access to parametrically defined instances. Since > the Parametric Singleton class encapsulates its instances, there is > control over how and when clients access it. Not really. Once you've returned the instance to a client, you've lost control over it. The client can to whatever it wants with it. You cannot "recall" the instance or claim it back. > 2. Reduced name space. The Parametric Singleton pattern avoids > global variables that store instances created from the same parameter. Sure, but you don't have to rely on a Singleton for that. Just create a single Factory. > I would very much like to get your feedback on this new design > pattern idea. Well, it's nothing new. Some may say that it is the point of design patterns: formalizes the designs that occur again and again. However, this design is simply a combination of the Singleton and Factory patterns. I did use it in the past, but now I've been exposed to the shortcomings of the Singleton pattern, so I limit myself to Factories. Regards, David From sean_montgomery at baseview.com Wed Mar 22 08:35:28 2006 From: sean_montgomery at baseview.com (Sean Montgomery) Date: Wed, 22 Mar 2006 10:35:28 -0500 Subject: [Rxtx] sole of a new design pattern In-Reply-To: <442160DA.80107@trusted-logic.com> References: <442160DA.80107@trusted-logic.com> Message-ID: <05769CA7-A51B-4CF0-BAA0-E02DD905F5A4@baseview.com> On Mar 22, 2006, at 9:36 AM, David Garnier wrote: > Furthermore, even for hardware services, the Singleton pattern does > not really prevent concurrent > accesses. If you start the same program in two different JVMs, > unless they somehow shared the state > of their "Singletons" (through lock files for example), the > Singleton pattern will not prevent > concurrent access. > Multiple class loaders in a single JVM can be tricky, too. Then there's synchronization, lazy initialization and serialization of singletons to contend with. Bloch's Effective Java covers these, and here's a few articles: http://www.javaworld.com/javaworld/jw-04-2003/jw-0425-designpatterns- p3.html http://java.sun.com/developer/technicalArticles/Programming/singletons/ Just FYI :-) From lyon at docjava.com Wed Mar 22 08:50:48 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Wed, 22 Mar 2006 10:50:48 -0500 Subject: [Rxtx] sole of a new design pattern In-Reply-To: <442160DA.80107@trusted-logic.com> References: <442160DA.80107@trusted-logic.com> Message-ID: Hi All, First, I would like to thank David for his prompt and thoughtful remarks. I had no idea people that feel strongly about a design patterns! Wow! Feedback (particularly critical feedback) is greatly appreciated. Starting at the end, first: >I did use it in >the past, but now I've been exposed to the shortcomings of the >Singleton pattern, so I limit myself to Factories. David, if I understood your comments correctly, you suggested that Factories can be used in leu of the Singleton Design Pattern, or even the Parametric Singleton Design Pattern. As I see in [Gof]: Factory Method: Intent "Define an interface for creating an object, but let subclasses decide which class to instantiate. Factory Method lets a class defer instantiation to subclasses." The Singleton Design Pattern is a concrete class, which is rather different, right? Also, subclasses are not permitted with Singleton, as they are final. Naturally, I could use an abstract factory as a parent for a singleton. I could even design a facade that could be implemented with the singleton....but that is not the intention of the design. Unless you want a mock-up, as discussed, below: More below: >Hello, > >> The Parametric Singleton Design Pattern > >The Singleton is the most abused design pattern ever. Good use-cases >for this pattern are extremely >rare and mostly confined to problems related to hardware resources, >like serial ports. > > >> Applicability >> >> Use the Parametric Singleton Design Pattern when: >> 1. There must be exactly one instance of a class with the given >> parameters. >OK. As I said above, this case this actually very unusual. The >Singleton pattern is mostly used when : >> 2. The instances must be accessible to clients from a well-known >> access point. > >Using the singleton pattern in this case is just convenient for the >programmer. Problems arises >pretty quickly, especially if you attempt to unit-test your classes. > >1) If your singleton is stateful, or hold on to stateful objects, it >means that two different unit >tests are not actually independent. Instead of starting with a brand >new environment, the result of >a test may be affected by the result of a previous test. This >problem also arise when with your >class relies on a database. In both cases, the solution is to reset >your "unique" resource >(Singleton or database) at the beginning of the test, which is a >pain. Also, while most projects >connect to a single database, projects that allow the use of >Singletons usually contain several of >thems, and new ones may cropped up unnoticed. You quickly end up >with test cases that only pass in a >certain order, which is a royal pain. There are basic problems with communicating finite state machines that include reachability and deadlock analysis. These are addressed with petri net analysis and are beyond the scope of the design pattern. As you quite rightly pointed out; the parametric singleton pattern (or the singleton pattern, for that matter) enable multiple threads to gain access to the same instance. The only way that I can see to block others from gaining access to the reference is the synchronize keyword. This is putting a spin-lock (or MUTEX) on the reference. The question of how to unit-test a design pattern like the parametric singleton remains open. Perhaps this is a deficiency. > >2) You cannot mockup a singleton. Once everyone calls the >SomeSingleton class statically, you can't >replace your class by SomeSingletonMockup. Acutally, I am not sure that this is true. If the Singleton implements a Facade interface, it should be possible to make the replacement. Right? > >Furthermore, even for hardware services, the Singleton pattern does >not really prevent concurrent >accesses. If you start the same program in two different JVMs, >unless they somehow shared the state >of their "Singletons" (through lock files for example), the >Singleton pattern will not prevent >concurrent access. Good Point!! You have sharp eyes! The singleton design pattern should/could take responsibility for this. In fact, you may notice that my code does have an implementation (LocateRegistry) that can work across JVM's. The LocateRegistry will even work across the Internet! LocateRegistry takes both a host name and a Port (lock files just don't do this). I did not think to implement this beyond the local machine, but, in its present form, it will work across different processes. > >Our application uses RXTX, and we routinely encounter cases where >another (native) application has >already locked the port. Since we cannot modify the native >application to recognize lock files, >OS-level control is irreplaceable. The singleton design pattern is not meant to replace OS-level control, but to centralize the Java programmers access to it. If lock files, for example, are used for serial ports, the Singleton Design Pattern should be able to work with them. > > >> >> Consequences >> The Parametric Singleton Design Pattern has several benefits: >> > > 1. Controlled access to parametrically defined instances. Since >> the Parametric Singleton class encapsulates its instances, there is >> control over how and when clients access it. > >Not really. Once you've returned the instance to a client, you've >lost control over it. The client >can to whatever it wants with it. You cannot "recall" the instance >or claim it back. Good point, this should read: > 1. Controll when parametrically defined instances are created. Since > > the Parametric Singleton class encapsulates its instances, there is > > control over how and when they are instanced. > >> 2. Reduced name space. The Parametric Singleton pattern avoids >> global variables that store instances created from the same parameter. > >Sure, but you don't have to rely on a Singleton for that. Just >create a single Factory. > > Thank you for your thoughtful and prompt response! Regards, - Doug From dmarkman at mac.com Wed Mar 22 21:21:55 2006 From: dmarkman at mac.com (Dmitry Markman) Date: Wed, 22 Mar 2006 23:21:55 -0500 Subject: [Rxtx] sole of a new design pattern In-Reply-To: <442160DA.80107@trusted-logic.com> References: <442160DA.80107@trusted-logic.com> Message-ID: I don't think I get it On Mar 22, 2006, at 9:36 AM, David Garnier wrote: > Using the singleton pattern in this case is just convenient for the > programmer. Problems arises > pretty quickly, especially if you attempt to unit-test your classes. so you're saying that something isn't so good because you can not test it in the convenient way? if that's true, I'm totally disagree change your test, debug whatever, but if software is efficient at runtime, works fine and only problem is some unit test (which is some kind of framework for testing) then dump that unit test , dump that unit framework and make something appropriate to the software you're testing so if Douglas want to use singletons, what's the problem? and what do you mean by abusing of singleton usage? of course singleton doesn't prevent concurrent access to the resource across the processes unless you're using some OS facility to prevent it, besides singleton as it was introduced is relevant only and only inside of the same process otherwise it's not singleton it's something else (let's say network singleton: so you have remote invocation facility and some factory method that return object created by that facility) I don't have any problem with using any kind of singletons. Parametric Singleton idea (if I understand it right) could be easily implemented in the following way: use a map populate map with instances of some class and key is your parameter (you can use lazy population too) if somebody ask the key check the value if it's null so resource is taken if somebody returns the resource put it back to the map public synchronized static Object getSomeResource(Object parameter); public synchronized static void returnResource(Object parameter); getSomeResource (inside of the same process) could return null in 2 cases 1. if somebody (from other thread for example) already took that resource 2. if OS API said that resource corresponded to that parameter (serial port with parameter = 1 (port #)) is locked and unavailable; I'm not sure that in case of serial ports we even need those Parametric Singletons (unless lock checking is a very expensive operation) just ask the OS about availability of that resource and if it's available give it away and then OS will lock it and therefore in next time somebody ask it just answer that resource is locked and return null for example system has 2 serial ports available so I ask getResource("tty"); or I ask getResource("Bluetooth-Modem"); and if OS is ok you can give tty or Bluetooth-Modem or both no need for any additional pattern I think back to the problem mac os x doesn't recognize locking via files, so it handles locking via some API an instance of the singleton in each process should recognize that resource is locked (by using that API) that's all we don't have to make things more complicate then they are just because there is some nice design pattern or nice unit test framework or whatever keep things simple, make them work fast, don't introduce middle layers unless you have really good reason to do so of course I could be entirely wrong, so sorry about that in advance thanks Dmitry Markman From tjarvi at qbang.org Wed Mar 22 22:31:41 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 22 Mar 2006 22:31:41 -0700 (MST) Subject: [Rxtx] sole of a new design pattern In-Reply-To: References: Message-ID: Hi Doug Interesting reading. So far I'm just reading and thinking. I have one question so far. " Clients obtain a reference to a Parametric Singleton instance only through the parametric singleton design pattern. If the instance is left in an improper state (e.g., the serial port was left open) it is NOT the role of the Parametric Singleton Design Pattern to close the IO port. Nor is it the role of the Parametric Singleton Design Pattern to open the port. That role is delegate to some other part of the system. " So when the clients obtain a reference to the singleton, can they assume the port is there? IE, would it be the singletons role to handle things like USB dongles being removed with event hints comming from the underlying OS. Hardware abstraction layer/HAL on Linux is an example of underlying OS events. I assume that role too is delegated to other parts of the system? -- Trent Jarvi tjarvi at qbang.org From lyon at docjava.com Thu Mar 23 08:10:33 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Thu, 23 Mar 2006 10:10:33 -0500 Subject: [Rxtx] Classes don't need goals, they need roles! In-Reply-To: References: Message-ID: Hi Trent, Yes, I think that the role of the Parametric Singleton Pattern is not to open or close serial ports, nor is it to perform error checking. On the other hand, if you were to combine the role of the Parametric Singleton Pattern with another role (like that of error checking) it might not be amiss. However, I generally caution programmers against adding multiple roles to classes, as this leads to monolithic designs. Thus a different class (NativeLibDetect) could have the role of determining if the native library can be loaded. Another class (SerialPortBean) can have the role of serializing the default state of the serial port, so that it can be recovered, from user preferences, at a later time. The SerialPortDetect could have the role of determining if the serial port is removed (i.e., a USB port was unplugged). My guess is that each class should have a different role in the system, in order to ease maintenance and testing...but I could be wrong about that. Thanks! - Doug >Hi Doug > >Interesting reading. So far I'm just reading and thinking. I have >one question so far. > >" > Clients obtain a reference to a Parametric Singleton instance only >through the parametric singleton design pattern. If the instance is >left in an improper state (e.g., the serial port was left open) it is >NOT the role of the Parametric Singleton Design Pattern to close the >IO port. Nor is it the role of the Parametric Singleton Design Pattern >to >open the port. That role is delegate to some other part of the system. >" > >So when the clients obtain a reference to the singleton, can they >assume the port is there? IE, would it be the singletons role to >handle things like USB dongles being removed with event hints >comming from the underlying OS. Hardware abstraction layer/HAL on >Linux is an example of underlying OS events. > >I assume that role too is delegated to other parts of the system? > >-- >Trent Jarvi >tjarvi at qbang.org >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From maximulo at yahoo.com Fri Mar 24 01:22:38 2006 From: maximulo at yahoo.com (Maximulo Majir) Date: Fri, 24 Mar 2006 00:22:38 -0800 (PST) Subject: [Rxtx] JavaPOS Message-ID: <20060324082238.66371.qmail@web38214.mail.mud.yahoo.com> Hi all! Hello Trent! From what i understand, RXTX or JavaComm APIs were not created solely for JavaPOS. In JavaPOS, we have the virtual method claim() which is separate from open(), but in our RXTX API, claiming is done every call to open(), we cant open the port if its claimed by another application. Would it be alright to suggest or ask to create a new method called claim(..)? Is there such thing as forceclaim() in RXTX? this could be the same as portownership transfer or its equivalent. ForceClaim is in JSR80. Do you have some samples using RXTX as the lower layer for the Device Service Objects in JavaPOS? I have tried it, i just want to compare. Thank you all! maxim __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060324/496adba2/attachment-0023.html From tjarvi at qbang.org Fri Mar 24 11:28:19 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 24 Mar 2006 11:28:19 -0700 (MST) Subject: [Rxtx] Re: RXTX 2.1 Solaris Problems In-Reply-To: <3691.1143210578@www045.gmx.net> References: <3691.1143210578@www045.gmx.net> Message-ID: On Fri, 24 Mar 2006, Andreas Guenther wrote: > Hi all, > > the solaris problem was not the lock file only. > > Ok, I had to create the directory /var/spool/locks myself. > /var/spool/uucp exists. > > But rxtx didn't find any port. > > I compiled the source with my own debug-informations > and I tried to isolate the problem. > > The problem is the testRead-call in SerialImp.c > > JNIEXPORT jboolean JNICALL RXTXCommDriver(testRead)( > > ... > if ( READ( fd, &c, 1 ) < 0 ) > { > if ( errno != EAGAIN ) { > report( "testRead() read failed\n" ); > ret = JNI_FALSE; > } > } > Thanks Andreas I'm packing up to move. I'll be more or less away for a couple weeks here. I'll be checking email but my workstation is going into a box soon. This isn't hard to fix as this port should be enumerated when EWOULDBLOCK is recieved. Thats error is OK for enumeration just as EAGAIN is. I've put the bug into bugzilla so we dont forget to get to it. http://bugzilla.qbang.org/show_bug.cgi?id=42 You can add yourself to the CC list if you wish to test fixes we provide or even put a patch into bugzilla yourself. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Fri Mar 24 11:51:52 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 24 Mar 2006 11:51:52 -0700 (MST) Subject: [Rxtx] JavaPOS In-Reply-To: <20060324082238.66371.qmail@web38214.mail.mud.yahoo.com> References: <20060324082238.66371.qmail@web38214.mail.mud.yahoo.com> Message-ID: On Fri, 24 Mar 2006, Maximulo Majir wrote: > Hi all! Hello Trent! > > > From what i understand, RXTX or JavaComm APIs were not > created solely for JavaPOS. In JavaPOS, we have the virtual method > claim() which is separate from open(), but in our RXTX API, claiming is > done every call to open(), we cant open the port if its claimed by > another application. Would it be alright to suggest or ask to create a > new method called claim(..)? Is there such thing as forceclaim() in > RXTX? this could be the same as portownership transfer or its > equivalent. ForceClaim is in JSR80. > Do you have some samples using RXTX as the lower layer for the Device > Service Objects in JavaPOS? I have tried it, i just want to compare. > maxim Hi Maxim JSR80 is the USB API IBM/Sun put together. The problem is they have a richer kernel/API underneath that can handle such things. With Serial Ports, there isnt anything there other than an ioctl that says don't let anyone touch this and lockfiles that are more of a 'lets be nice.' At times we may be using USB ports but it is through the termios layer with the limitations mentioned. The advantage is that not only USB will work with rxtx. Anything that has a termios layer should work (to the extent that termios layer is complete). I don't know how forceclaim() would help you. Lets say someone has a programmer working on /dev/ttyS0 and you take it. Now you both race each other to read data first. There isn't a mechanism I know of that will solve this problem in termios. The most obvious test being a native app and a Java app trying to take the port. There is the potential of requestion ownership from other Java Applications but the use for that is very rare. Did you have something more specific in mind that I'm missing? I'm not sure that claim() and forceclaim() would help you with rxtx other than maybe locking the port with claim() without opening it. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sat Mar 25 23:42:08 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 25 Mar 2006 23:42:08 -0700 (MST) Subject: [Rxtx] Serial snoop Message-ID: I was reading the Linux kernel mail-list tonight and ran past a thread that mentioned sersnoop. This looks like a handy tool for people dealing with new toys. "a simple command-line tool for linux that echoes bytes to and from any two serial ports, ptys, or network sockets, and prints all traffic to stdout, in hex and ascii." http://www.restivo.org/projects/sersnoop/ It works on Linux only at this time (debian package available). -- Trent Jarvi tjarvi at qbang.org From beat.arnet at gmail.com Sun Mar 26 07:32:35 2006 From: beat.arnet at gmail.com (Beat Arnet) Date: Sun, 26 Mar 2006 09:32:35 -0500 Subject: [Rxtx] Error 0x5 at /home/bob/foo/tar/rxtx-2.1-7/build/../src/termios.c(860): Access is, denied. Message-ID: <4426A603.80508@gmail.com> Dear all, When trying to open the serial port, I sometimes (not always) run into the following exception (when opening the serialPort): Error 0x5 at /home/bob/foo/tar/rxtx-2.1-7/build/../src/termios.c(860): Access is denied. java.lang.UnsatisfiedLinkError: native_psmisc_report_owner at gnu.io.CommPortIdentifier.native_psmisc_report_owner(Native Method) at gnu.io.CommPortIdentifier.open(CommPortIdentifier.java:354) at codeskin.tools.CLLoader.open(CLLoader.java:79) at codeskin.tools.C2000Programmer.run(C2000Programmer.java:220) at java.lang.Thread.run(Unknown Source) Is this the type of error where I should just try to open the port again, or can it be avoided? Regards, Beat From tjarvi at qbang.org Sun Mar 26 11:40:12 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 26 Mar 2006 11:40:12 -0700 (MST) Subject: [Rxtx] Error 0x5 at /home/bob/foo/tar/rxtx-2.1-7/build/../src/termios.c(860): Access is, denied. In-Reply-To: <4426A603.80508@gmail.com> References: <4426A603.80508@gmail.com> Message-ID: On Sun, 26 Mar 2006, Beat Arnet wrote: > Dear all, > > When trying to open the serial port, I sometimes (not always) run into > the following exception (when opening the serialPort): > > Error 0x5 at /home/bob/foo/tar/rxtx-2.1-7/build/../src/termios.c(860): > Access is > denied. > > java.lang.UnsatisfiedLinkError: native_psmisc_report_owner > at gnu.io.CommPortIdentifier.native_psmisc_report_owner(Native > Method) > at gnu.io.CommPortIdentifier.open(CommPortIdentifier.java:354) > at codeskin.tools.CLLoader.open(CLLoader.java:79) > at codeskin.tools.C2000Programmer.run(C2000Programmer.java:220) > at java.lang.Thread.run(Unknown Source) > > Is this the type of error where I should just try to open the port again, > or can it be avoided? > Hi Beat We did a second build of rxtx 2.1-7 to resolve that unsatisfied link error. It should work now. rxtx is trying to tell you it thinks someone else has the serial port open. You can try to open the port again but maybe you already have a copy of the program running when it happens? ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7r2.zip fixed build. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sun Mar 26 11:44:23 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 26 Mar 2006 11:44:23 -0700 (MST) Subject: [Rxtx] RXTX spec file (fwd) Message-ID: This is probably interesting for fedora/suse users. ---------- Forwarded message ---------- Date: Sun, 26 Mar 2006 16:25:45 +0200 To: taj at www.linux.org.uk Subject: RXTX spec file I send you this spec file which allows to create a RPM for Fedora 4, 5 (x86, x86_64) with Java Sun. -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: rxtx.spec Url: http://mailman.qbang.org/pipermail/rxtx/attachments/20060326/6c7b6af6/rxtx-0019.pl From tjarvi at qbang.org Sun Mar 26 23:42:59 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 26 Mar 2006 23:42:59 -0700 (MST) Subject: [Rxtx] Upcomming events. Message-ID: This Wednesday we will be announcing a new "Maintainer" for the rxtx project. The position is more like neutral leader. I wont be going away or doing less. This is just the right thing to do as it turns out the two people with CVS write access will be at the same company. We need a third and we need neutrality. The maintainer will have final say in any conflict and will try to be neutral. It will be open for discussion. Then we will do it :) I'll still do most of the footwork I do now. But. I'm falling behind. I should have gone through the mail-list and posted the next round of changes this weekend. I'm packing to move and its going so so - 13 years of toys collected. I suspect there will be a dead period on my part (a couple weeks) comming up. But if you get it on the mail-list, we will get it in if there are no objections. I may well not be reading the mail-list during this period as I look for a house and many other things. I hope everyone will help out. Thanks -- Trent Jarvi tjarvi at qbang.org From mahmoud_hadad at yahoo.com Sun Mar 26 07:31:19 2006 From: mahmoud_hadad at yahoo.com (ronan nick) Date: Sun, 26 Mar 2006 06:31:19 -0800 (PST) Subject: [Rxtx] a question about the COMM API Message-ID: <20060326143119.54919.qmail@web60014.mail.yahoo.com> hi, i was intrested in knowing how i can communicate with my internal modem using java? for example if i want to make a phone dialer application or a caller id application where should i be looking at? and as i understood the COMM API is for devices that is attached to the computer through serial ports. --------------------------------- New Yahoo! Messenger with Voice. Call regular phones from your PC and save big. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060326/ce8329f0/attachment-0021.html From dmarkman at mac.com Mon Mar 20 00:20:43 2006 From: dmarkman at mac.com (Dmitry Markman) Date: Mon, 20 Mar 2006 02:20:43 -0500 Subject: [Rxtx] Mac OS X RXTX java installer In-Reply-To: References: <07D0DE29-BA32-4CFE-B036-66BC6423D385@buechse.de> <441AE3E0.2030503@willicon.de> <12531986.1142622114996.JavaMail.dmarkman@mac.com> <441B2674.9010409@willicon.de> <13577405.1142634732776.JavaMail.dmarkman@mac.com> <441B4182.8010407@willicon.de> <92CD0D6C-5BE8-426E-A46D-99452059FF49@mac.com> <441BBB2D.8030305@willicon.de> <441C4088.5090905@willicon.de> Message-ID: <64BC1E23-FDDE-4CE6-8863-CFC881CBC224@mac.com> Hi all I put RXTX installer that will install everything (and will create / var/lock if necessary and add user to the uucp group) for mac os x from Java into the rxtx's CVS repository it could be easily modified to install files for any platform it uses Greg Guerin's AuthKit for authentication and authorization Greg released that kit under artistic license, so Trent, please take a look we, probably, can negotiate license with Greg if it's necessary Greg's AuthKit could be downloaded from http://www.amug.org/~glguerin/ sw/#authkit Michael Hall (mikehall at spacestar dot net) had a suggestion to make implementation of the jaas LoginModule based on Greg's AuthKit (his modification of the Greg's AuthKit could be found at http:// www.spacestar.net/users/mikehall/authkit.dmg) but Michael's AuthKitLoginModule does only half a job: it does authenticate but it can not run any external unix process in privileged mode (at least I wasn't able to do so) possible explanation could be found in conversation between Greg and Michael at Apple's java-dev list (look for archives) so I didn't use jaas API for rxtxinstaller I created folder MacOSX in the contrib folder comment 1. if you want to run that installer as standalone application all you need that RXTXInstaller.jar 2. if you want to use webstart you have to add Greg's libAuthKit.jnilib to the mac os x's resources in theory RXTXInstaller.jar doesn't need it, but there is a problem with loading libAuthKit.jnilib from webstart authkit uses loadLibrary method to load library and it failed (from webstart) for standalone application I extract libAuthKit.jnilib from the RXTXInstaller.jar and put it into the /Library/Java/Extensions or ~/Library/Java/Extensions folder that file will be deleted after installer quit unfortunately I didn't have time to put documentation there but it is mostly self-explanatory I took installer code from my gl4java installer that I did about 3 years ago (with small modifications) it would be very nice if Apple will release LoginModule that really will do the job (com.apple.security.auth.module package????? ) (UnixLoginModule is pretty useless) From lyon at docjava.com Mon Mar 20 06:34:39 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Mon, 20 Mar 2006 08:34:39 -0500 Subject: [Rxtx] Mac OS X RXTX java installer In-Reply-To: <64BC1E23-FDDE-4CE6-8863-CFC881CBC224@mac.com> References: <07D0DE29-BA32-4CFE-B036-66BC6423D385@buechse.de> <441AE3E0.2030503@willicon.de> <12531986.1142622114996.JavaMail.dmarkman@mac.com> <441B2674.9010409@willicon.de> <13577405.1142634732776.JavaMail.dmarkman@mac.com> <441B4182.8010407@willicon.de> <92CD0D6C-5BE8-426E-A46D-99452059FF49@mac.com> <441BBB2D.8030305@willicon.de> <441C4088.5090905@willicon.de> <64BC1E23-FDDE-4CE6-8863-CFC881CBC224@mac.com> Message-ID: Hi Dimitry, This sounds like great work. Just a couple of questions; After the check out of the CVS files, using: setenv CVSROOT :pserver:anonymous at cvs.milestonesolutions.com:/usr/local/cvsroot 53 8:28 setenv PASSWORD mousy 54 8:29 cvs login 55 8:29 cvs checkout rxtx-devel I cd'd over to: rxtx-devel/MACOSX_IDE And found: CVS/ CW/ ForPackageMaker/ PB/ Where is the installer? Thanks! - Doug From tjarvi at qbang.org Mon Mar 20 06:39:37 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 20 Mar 2006 06:39:37 -0700 (MST) Subject: [Rxtx] Mac OS X RXTX java installer In-Reply-To: References: <07D0DE29-BA32-4CFE-B036-66BC6423D385@buechse.de> <441AE3E0.2030503@willicon.de> <12531986.1142622114996.JavaMail.dmarkman@mac.com> <441B2674.9010409@willicon.de> <13577405.1142634732776.JavaMail.dmarkman@mac.com> <441B4182.8010407@willicon.de> <92CD0D6C-5BE8-426E-A46D-99452059FF49@mac.com> <441BBB2D.8030305@willicon.de> <441C4088.5090905@willicon.de> <64BC1E23-FDDE-4CE6-8863-CFC881CBC224@mac.com> Message-ID: On Mon, 20 Mar 2006, Dr. Douglas Lyon wrote: > Hi Dimitry, > This sounds like great work. Just a couple of questions; > After the check out of the CVS files, using: > setenv CVSROOT > :pserver:anonymous at cvs.milestonesolutions.com:/usr/local/cvsroot > 53 8:28 setenv PASSWORD mousy > 54 8:29 cvs login > 55 8:29 cvs checkout rxtx-devel Hi Doug You want "cvs checkout -r commapi-0-0-1 rxtx-devel" to get RXTX 2.1 The default branch is rxtx 2.0 which isn't very active right now. -- Trent Jarvi tjarvi at qbang.org From lyon at docjava.com Mon Mar 20 07:05:44 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Mon, 20 Mar 2006 09:05:44 -0500 Subject: [Rxtx] Mac OS X RXTX java installer In-Reply-To: References: <07D0DE29-BA32-4CFE-B036-66BC6423D385@buechse.de> <441AE3E0.2030503@willicon.de> <12531986.1142622114996.JavaMail.dmarkman@mac.com> <441B2674.9010409@willicon.de> <13577405.1142634732776.JavaMail.dmarkman@mac.com> <441B4182.8010407@willicon.de> <92CD0D6C-5BE8-426E-A46D-99452059FF49@mac.com> <441BBB2D.8030305@willicon.de> <441C4088.5090905@willicon.de> <64BC1E23-FDDE-4CE6-8863-CFC881CBC224@mac.com> Message-ID: Hi Trent, Thanks for the info on the CVS checkout procedure. I did that and am still not sure where the installer is. Here is what I have: cd MACOSX_IDE/ p4.docjava.com{lyon}121: ls CVS/ ForPackageMaker/ PB/ p4.docjava.com{lyon}122: find . | more . ./ForPackageMaker ./ForPackageMaker/RXTX.pkg.sit.hqx ./ForPackageMaker/Resources ./ForPackageMaker/Resources/ReadMe.rtf ./ForPackageMaker/Resources/Welcome.rtf ./ForPackageMaker/Resources/CVS ./ForPackageMaker/Resources/CVS/Entries ./ForPackageMaker/Resources/CVS/Repository ./ForPackageMaker/Resources/CVS/Tag ./ForPackageMaker/Resources/CVS/Root ./ForPackageMaker/Resources/preinstall ./ForPackageMaker/Resources/License.rtf ./ForPackageMaker/Resources/preupgrade ./ForPackageMaker/RXTX.pmsp ./ForPackageMaker/CVS ./ForPackageMaker/CVS/Entries ./ForPackageMaker/CVS/Repository ./ForPackageMaker/CVS/Entries.Log ./ForPackageMaker/CVS/Tag ./ForPackageMaker/CVS/Root ./ForPackageMaker/RXTX_Tiger.pkg.sitx.hqx ./ForPackageMaker/RXTX_Jag.pkg.sit.hqx ./ForPackageMaker/Install ./ForPackageMaker/Install/CVS ./ForPackageMaker/Install/CVS/Entries ./ForPackageMaker/Install/CVS/Repository ./ForPackageMaker/Install/CVS/Tag ./ForPackageMaker/Install/CVS/Root ./ForPackageMaker/Install/Library ./ForPackageMaker/Install/Library/CVS ./ForPackageMaker/Install/Library/CVS/Entries ./ForPackageMaker/Install/Library/CVS/Repository ./ForPackageMaker/Install/Library/CVS/Tag ./ForPackageMaker/Install/Library/CVS/Root ./ForPackageMaker/Install/Library/Java ./ForPackageMaker/Install/Library/Java/Extensions ./ForPackageMaker/Install/Library/Java/Extensions/RXTXcomm.jar ./ForPackageMaker/Install/Library/Java/Extensions/CVS ./ForPackageMaker/Install/Library/Java/Extensions/CVS/Entries ./ForPackageMaker/Install/Library/Java/Extensions/CVS/Repository ./ForPackageMaker/Install/Library/Java/Extensions/CVS/Tag ./ForPackageMaker/Install/Library/Java/Extensions/CVS/Root ./ForPackageMaker/Install/Library/Java/Extensions/librxtxSerial.jnilib ./ForPackageMaker/Install/Library/Java/CVS ./ForPackageMaker/Install/Library/Java/CVS/Entries ./ForPackageMaker/Install/Library/Java/CVS/Repository ./ForPackageMaker/Install/Library/Java/CVS/Entries.Log ./ForPackageMaker/Install/Library/Java/CVS/Tag ./ForPackageMaker/Install/Library/Java/CVS/Root ./ForPackageMaker/RXTX_Tiger.pmproj.sitx.hqx ./CVS ./CVS/Entries ./CVS/Repository ./CVS/Entries.Log ./CVS/Tag ./CVS/Root ./PB ./PB/LibSerialUniversal.xcodeproj.sitx.hqx ./PB/CVS ./PB/CVS/Entries ./PB/CVS/Repository ./PB/CVS/Entries.Log ./PB/CVS/Tag ./PB/CVS/Root ./PB/LibSerial.pbproj.sit.hqx ./PB/startpoint.c ./PB/config.h What is the procedure to run this installer? Do we need a README in: /rxtx-devel/MACOSX_IDE Here is what we have: CVS/ ForPackageMaker/ PB/ Thanks! - DL >On Mon, 20 Mar 2006, Dr. Douglas Lyon wrote: > >>Hi Dimitry, >>This sounds like great work. Just a couple of questions; >>After the check out of the CVS files, using: >>setenv CVSROOT >>:pserver:anonymous at cvs.milestonesolutions.com:/usr/local/cvsroot >> 53 8:28 setenv PASSWORD mousy >> 54 8:29 cvs login >> 55 8:29 cvs checkout rxtx-devel > >Hi Doug > >You want "cvs checkout -r commapi-0-0-1 rxtx-devel" to get RXTX 2.1 >The default branch is rxtx 2.0 which isn't very active right now. > >-- >Trent Jarvi >tjarvi at qbang.org From tjarvi at qbang.org Mon Mar 20 07:25:30 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 20 Mar 2006 07:25:30 -0700 (MST) Subject: [Rxtx] Mac OS X RXTX java installer In-Reply-To: References: <07D0DE29-BA32-4CFE-B036-66BC6423D385@buechse.de> <441AE3E0.2030503@willicon.de> <12531986.1142622114996.JavaMail.dmarkman@mac.com> <441B2674.9010409@willicon.de> <13577405.1142634732776.JavaMail.dmarkman@mac.com> <441B4182.8010407@willicon.de> <92CD0D6C-5BE8-426E-A46D-99452059FF49@mac.com> <441BBB2D.8030305@willicon.de> <441C4088.5090905@willicon.de> <64BC1E23-FDDE-4CE6-8863-CFC881CBC224@mac.com> Message-ID: On Mon, 20 Mar 2006, Dr. Douglas Lyon wrote: > Hi Trent, > Thanks for the info on the CVS checkout procedure. > I did that and am still not sure where the installer is. Hi Doug It does look like it was not cvs committed. There is no rxtx-devel/contrib/MacOSX directory in there at the moment. It was mentioned that it was put under contrib. -- Trent Jarvi tjarvi at qbang.org From dmarkman at mac.com Mon Mar 20 07:29:56 2006 From: dmarkman at mac.com (Dmitry Markman) Date: Mon, 20 Mar 2006 09:29:56 -0500 Subject: [Rxtx] Mac OS X RXTX java installer In-Reply-To: References: <07D0DE29-BA32-4CFE-B036-66BC6423D385@buechse.de> <441AE3E0.2030503@willicon.de> <12531986.1142622114996.JavaMail.dmarkman@mac.com> <441B2674.9010409@willicon.de> <13577405.1142634732776.JavaMail.dmarkman@mac.com> <441B4182.8010407@willicon.de> <92CD0D6C-5BE8-426E-A46D-99452059FF49@mac.com> <441BBB2D.8030305@willicon.de> <441C4088.5090905@willicon.de> <64BC1E23-FDDE-4CE6-8863-CFC881CBC224@mac.com> Message-ID: <6054EB4E-F7E0-4A9C-BDDA-D582D6D8826F@mac.com> you can find it in the rxtx-devel/contrib folder On Mar 20, 2006, at 9:05 AM, Dr. Douglas Lyon wrote: > Hi Trent, > Thanks for the info on the CVS checkout procedure. > I did that and am still not sure where the installer is. > Here is what I have: > cd MACOSX_IDE/ > p4.docjava.com{lyon}121: ls > CVS/ ForPackageMaker/ PB/ > p4.docjava.com{lyon}122: find . | more > . > ./ForPackageMaker > ./ForPackageMaker/RXTX.pkg.sit.hqx > ./ForPackageMaker/Resources > ./ForPackageMaker/Resources/ReadMe.rtf > ./ForPackageMaker/Resources/Welcome.rtf > ./ForPackageMaker/Resources/CVS > ./ForPackageMaker/Resources/CVS/Entries > ./ForPackageMaker/Resources/CVS/Repository > ./ForPackageMaker/Resources/CVS/Tag > ./ForPackageMaker/Resources/CVS/Root > ./ForPackageMaker/Resources/preinstall > ./ForPackageMaker/Resources/License.rtf > ./ForPackageMaker/Resources/preupgrade > ./ForPackageMaker/RXTX.pmsp > ./ForPackageMaker/CVS > ./ForPackageMaker/CVS/Entries > ./ForPackageMaker/CVS/Repository > ./ForPackageMaker/CVS/Entries.Log > ./ForPackageMaker/CVS/Tag > ./ForPackageMaker/CVS/Root > ./ForPackageMaker/RXTX_Tiger.pkg.sitx.hqx > ./ForPackageMaker/RXTX_Jag.pkg.sit.hqx > ./ForPackageMaker/Install > ./ForPackageMaker/Install/CVS > ./ForPackageMaker/Install/CVS/Entries > ./ForPackageMaker/Install/CVS/Repository > ./ForPackageMaker/Install/CVS/Tag > ./ForPackageMaker/Install/CVS/Root > ./ForPackageMaker/Install/Library > ./ForPackageMaker/Install/Library/CVS > ./ForPackageMaker/Install/Library/CVS/Entries > ./ForPackageMaker/Install/Library/CVS/Repository > ./ForPackageMaker/Install/Library/CVS/Tag > ./ForPackageMaker/Install/Library/CVS/Root > ./ForPackageMaker/Install/Library/Java > ./ForPackageMaker/Install/Library/Java/Extensions > ./ForPackageMaker/Install/Library/Java/Extensions/RXTXcomm.jar > ./ForPackageMaker/Install/Library/Java/Extensions/CVS > ./ForPackageMaker/Install/Library/Java/Extensions/CVS/Entries > ./ForPackageMaker/Install/Library/Java/Extensions/CVS/Repository > ./ForPackageMaker/Install/Library/Java/Extensions/CVS/Tag > ./ForPackageMaker/Install/Library/Java/Extensions/CVS/Root > ./ForPackageMaker/Install/Library/Java/Extensions/librxtxSerial.jnilib > ./ForPackageMaker/Install/Library/Java/CVS > ./ForPackageMaker/Install/Library/Java/CVS/Entries > ./ForPackageMaker/Install/Library/Java/CVS/Repository > ./ForPackageMaker/Install/Library/Java/CVS/Entries.Log > ./ForPackageMaker/Install/Library/Java/CVS/Tag > ./ForPackageMaker/Install/Library/Java/CVS/Root > ./ForPackageMaker/RXTX_Tiger.pmproj.sitx.hqx > ./CVS > ./CVS/Entries > ./CVS/Repository > ./CVS/Entries.Log > ./CVS/Tag > ./CVS/Root > ./PB > ./PB/LibSerialUniversal.xcodeproj.sitx.hqx > ./PB/CVS > ./PB/CVS/Entries > ./PB/CVS/Repository > ./PB/CVS/Entries.Log > ./PB/CVS/Tag > ./PB/CVS/Root > ./PB/LibSerial.pbproj.sit.hqx > ./PB/startpoint.c > ./PB/config.h > > What is the procedure to run this installer? > Do we need a README in: > /rxtx-devel/MACOSX_IDE > Here is what we have: > CVS/ ForPackageMaker/ PB/ > > > Thanks! > - DL > >> On Mon, 20 Mar 2006, Dr. Douglas Lyon wrote: >> >>> Hi Dimitry, >>> This sounds like great work. Just a couple of questions; >>> After the check out of the CVS files, using: >>> setenv CVSROOT :pserver:anonymous at cvs.milestonesolutions.com:/usr/ >>> local/cvsroot >>> 53 8:28 setenv PASSWORD mousy >>> 54 8:29 cvs login >>> 55 8:29 cvs checkout rxtx-devel >> >> Hi Doug >> >> You want "cvs checkout -r commapi-0-0-1 rxtx-devel" to get RXTX 2.1 >> The default branch is rxtx 2.0 which isn't very active right now. >> >> -- >> Trent Jarvi >> tjarvi at qbang.org > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx Dmitry Markman From mikehall at spacestar.net Mon Mar 20 05:25:25 2006 From: mikehall at spacestar.net (Michael Hall) Date: Mon, 20 Mar 2006 06:25:25 -0600 Subject: [Rxtx] Re: Mac OS X RXTX java installer In-Reply-To: <64BC1E23-FDDE-4CE6-8863-CFC881CBC224@mac.com> References: <07D0DE29-BA32-4CFE-B036-66BC6423D385@buechse.de> <441AE3E0.2030503@willicon.de> <12531986.1142622114996.JavaMail.dmarkman@mac.com> <441B2674.9010409@willicon.de> <13577405.1142634732776.JavaMail.dmarkman@mac.com> <441B4182.8010407@willicon.de> <92CD0D6C-5BE8-426E-A46D-99452059FF49@mac.com> <441BBB2D.8030305@willicon.de> <441C4088.5090905@willicon.de> <64BC1E23-FDDE-4CE6-8863-CFC881CBC224@mac.com> Message-ID: <247EB61F-5CD1-4132-89A2-FC105B6CF9A5@spacestar.net> On Mar 20, 2006, at 1:20 AM, Dmitry Markman wrote: > > Michael Hall (mikehall at spacestar dot net) had a suggestion to > make implementation of the jaas LoginModule > based on Greg's AuthKit > (his modification of the Greg's AuthKit could be found at http:// > www.spacestar.net/users/mikehall/authkit.dmg) > but Michael's AuthKitLoginModule does only half a job: > it does authenticate > but it can not run any external unix process in privileged mode (at > least I wasn't able to do so) If you got it working directly with Greg's the point is moot. But to clarify it anyhow. The login module does not allow you to do anything anything privileged on return as was explained by Greg. You need to work with a separate privileged process using the execPrivileged method of his API. I assume you did something similar although I haven't looked at how you are using it yet. I allowed instead for a action to be performed at the same time you login/authenticate,this... System.setProperty("authkit.action","/usr/bin/id"); just before this... lc.login(); To clarify, safely ignored as you are already complete. Mike Hall mikehall at spacestar dot net http://www.spacestar.net/users/mikehall http://sourceforge.net/projects/macnative -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2427 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20060320/f6e18202/smime-0024.bin From dmarkman at mac.com Mon Mar 20 07:36:47 2006 From: dmarkman at mac.com (Dmitry Markman) Date: Mon, 20 Mar 2006 09:36:47 -0500 Subject: [Rxtx] Re: Mac OS X RXTX java installer In-Reply-To: <247EB61F-5CD1-4132-89A2-FC105B6CF9A5@spacestar.net> References: <07D0DE29-BA32-4CFE-B036-66BC6423D385@buechse.de> <441AE3E0.2030503@willicon.de> <12531986.1142622114996.JavaMail.dmarkman@mac.com> <441B2674.9010409@willicon.de> <13577405.1142634732776.JavaMail.dmarkman@mac.com> <441B4182.8010407@willicon.de> <92CD0D6C-5BE8-426E-A46D-99452059FF49@mac.com> <441BBB2D.8030305@willicon.de> <441C4088.5090905@willicon.de> <64BC1E23-FDDE-4CE6-8863-CFC881CBC224@mac.com> <247EB61F-5CD1-4132-89A2-FC105B6CF9A5@spacestar.net> Message-ID: Hi, Michael all I have to do is to run some shell script I tried to use your action mechanism and it worked great so I just System.setProperty ("authkit.action","" ) and after that I even don't need to run anything like subject.doAs.... but after few thoughts I choose to use plain Greg's approach, because in that case I don't have to deal with various java's configurations files and therefore to use 2-3 -D parameters in the java command line especially it's useful for java web start (it's so fragile :-( ) thanks for the great job On Mar 20, 2006, at 7:25 AM, Michael Hall wrote: > > On Mar 20, 2006, at 1:20 AM, Dmitry Markman wrote: >> >> Michael Hall (mikehall at spacestar dot net) had a suggestion to >> make implementation of the jaas LoginModule >> based on Greg's AuthKit >> (his modification of the Greg's AuthKit could be found at http:// >> www.spacestar.net/users/mikehall/authkit.dmg) >> but Michael's AuthKitLoginModule does only half a job: >> it does authenticate >> but it can not run any external unix process in privileged mode >> (at least I wasn't able to do so) > > If you got it working directly with Greg's the point is moot. > > But to clarify it anyhow. > The login module does not allow you to do anything anything > privileged on return as was explained by Greg. You need to work > with a separate privileged process using the execPrivileged method > of his API. I assume you did something similar although I haven't > looked at how you are using it yet. > I allowed instead for a action to be performed at the same time you > login/authenticate,this... > System.setProperty("authkit.action","/usr/bin/id"); > just before this... > lc.login(); > To clarify, safely ignored as you are already complete. > > Mike Hall mikehall at spacestar dot net > http://www.spacestar.net/users/mikehall > http://sourceforge.net/projects/macnative > > > Dmitry Markman From dmarkman at mac.com Mon Mar 20 07:44:45 2006 From: dmarkman at mac.com (Dmitry Markman) Date: Mon, 20 Mar 2006 09:44:45 -0500 Subject: [Rxtx] Mac OS X RXTX java installer In-Reply-To: References: <07D0DE29-BA32-4CFE-B036-66BC6423D385@buechse.de> <441AE3E0.2030503@willicon.de> <12531986.1142622114996.JavaMail.dmarkman@mac.com> <441B2674.9010409@willicon.de> <13577405.1142634732776.JavaMail.dmarkman@mac.com> <441B4182.8010407@willicon.de> <92CD0D6C-5BE8-426E-A46D-99452059FF49@mac.com> <441BBB2D.8030305@willicon.de> <441C4088.5090905@willicon.de> <64BC1E23-FDDE-4CE6-8863-CFC881CBC224@mac.com> Message-ID: it's in the commapi-0-0-1 branch I tested it right now: cvs co -r commapi-0-0-1 rxtx-devel and I got everything On Mar 20, 2006, at 9:25 AM, Trent Jarvi wrote: > On Mon, 20 Mar 2006, Dr. Douglas Lyon wrote: > >> Hi Trent, >> Thanks for the info on the CVS checkout procedure. >> I did that and am still not sure where the installer is. > > Hi Doug > > It does look like it was not cvs committed. There is no rxtx-devel/ > contrib/MacOSX directory in there at the moment. It was mentioned > that it was put under contrib. > > -- > Trent Jarvi > tjarvi at qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx Dmitry Markman From tjarvi at qbang.org Mon Mar 20 07:52:57 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 20 Mar 2006 07:52:57 -0700 (MST) Subject: [Rxtx] Mac OS X RXTX java installer In-Reply-To: References: <07D0DE29-BA32-4CFE-B036-66BC6423D385@buechse.de> <441AE3E0.2030503@willicon.de> <12531986.1142622114996.JavaMail.dmarkman@mac.com> <441B2674.9010409@willicon.de> <13577405.1142634732776.JavaMail.dmarkman@mac.com> <441B4182.8010407@willicon.de> <92CD0D6C-5BE8-426E-A46D-99452059FF49@mac.com> <441BBB2D.8030305@willicon.de> <441C4088.5090905@willicon.de> <64BC1E23-FDDE-4CE6-8863-CFC881CBC224@mac.com> Message-ID: On Mon, 20 Mar 2006, Dmitry Markman wrote: > it's in the commapi-0-0-1 branch > > I tested it right now: > cvs co -r commapi-0-0-1 rxtx-devel > > and I got everything > A fresh checkout worked. Here is a copy of the tree (just the installer bits) ftp://ftp.qbang.org/pub/rxtx/MacOSX-installer.zip -- Trent Jarvi tjarvi at qbang.org From lyon at docjava.com Mon Mar 20 08:08:26 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Mon, 20 Mar 2006 10:08:26 -0500 Subject: [Rxtx] Mac OS X RXTX java installer In-Reply-To: References: <07D0DE29-BA32-4CFE-B036-66BC6423D385@buechse.de> <441AE3E0.2030503@willicon.de> <12531986.1142622114996.JavaMail.dmarkman@mac.com> <441B2674.9010409@willicon.de> <13577405.1142634732776.JavaMail.dmarkman@mac.com> <441B4182.8010407@willicon.de> <92CD0D6C-5BE8-426E-A46D-99452059FF49@mac.com> <441BBB2D.8030305@willicon.de> <441C4088.5090905@willicon.de> <64BC1E23-FDDE-4CE6-8863-CFC881CBC224@mac.com> Message-ID: Hi All, Is the Auth package able to work properly on non Mac OS's? It was not clear from the doc or download. Thanks! - Doug From dmarkman at mac.com Mon Mar 20 08:15:22 2006 From: dmarkman at mac.com (Dmitry Markman) Date: Mon, 20 Mar 2006 10:15:22 -0500 Subject: [Rxtx] Mac OS X RXTX java installer In-Reply-To: References: <07D0DE29-BA32-4CFE-B036-66BC6423D385@buechse.de> <441AE3E0.2030503@willicon.de> <12531986.1142622114996.JavaMail.dmarkman@mac.com> <441B2674.9010409@willicon.de> <13577405.1142634732776.JavaMail.dmarkman@mac.com> <441B4182.8010407@willicon.de> <92CD0D6C-5BE8-426E-A46D-99452059FF49@mac.com> <441BBB2D.8030305@willicon.de> <441C4088.5090905@willicon.de> <64BC1E23-FDDE-4CE6-8863-CFC881CBC224@mac.com> Message-ID: <217312D8-CCCA-4859-ABA6-32DF1CC817B9@mac.com> thanks Trent, for putting it on ftp server On Mar 20, 2006, at 9:52 AM, Trent Jarvi wrote: > A fresh checkout worked. Here is a copy of the tree (just the > installer bits) > > ftp://ftp.qbang.org/pub/rxtx/MacOSX-installer.zip > Dmitry Markman From dmarkman at mac.com Mon Mar 20 09:14:03 2006 From: dmarkman at mac.com (Dmitry Markman) Date: Mon, 20 Mar 2006 11:14:03 -0500 Subject: [Rxtx] Mac OS X RXTX java installer In-Reply-To: References: <07D0DE29-BA32-4CFE-B036-66BC6423D385@buechse.de> <441AE3E0.2030503@willicon.de> <12531986.1142622114996.JavaMail.dmarkman@mac.com> <441B2674.9010409@willicon.de> <13577405.1142634732776.JavaMail.dmarkman@mac.com> <441B4182.8010407@willicon.de> <92CD0D6C-5BE8-426E-A46D-99452059FF49@mac.com> <441BBB2D.8030305@willicon.de> <441C4088.5090905@willicon.de> <64BC1E23-FDDE-4CE6-8863-CFC881CBC224@mac.com> Message-ID: <4DEBA6F0-DA45-4E84-823E-1F1AC48BDCCC@mac.com> no it will work only on mac os x however it's harmless to run it on other platform if you want to use it for other platform you have to do the following (I'll do it for linux) 1. modify RXTXInstaller class method public static RXTXInstaller getInstance() public static RXTXInstaller getInstance() { String osName = System.getProperty("os.name").toLowerCase(); if(osName.startsWith("mac")){ return new gnu.io.installer.macosx.MACOSXRXTXInstaller(); } else if(osName.startsWith("windows")){ return new gnu.io.installer.windows.WindowsRXTXInstaller(); }else if(osName.startsWith("linux")){ return new gnu.io.installer.linux.LinuxRXTXInstaller(); } return null; } 2. create folder gnu/io/installer/linux/ 3. create class Linux386RXTXInstaller package gnu.io.installer.linux; import java.io.File; public class Linux386RXTXInstaller extends gnu.io.installer.RXTXInstaller{ public Linux386RXTXInstaller(){ createJarFolder(); createLibFolder(); addJarResource("RXTXcomm.jar","/gnu/io/installer/resources/ linux/jar/RXTXcomm.dat"); addLibResource("librxtxSerial.so","/gnu/io/installer/ resources/linux/lib/librxtxSerial.so"); } protected void createJarFolder(){ String javaHome = System.getProperty("java.home"); char separator = File.separatorChar; jarFolder = new File(javaHome+separator+"lib"+separator+"ext"); } protected void createLibFolder(){ String javaHome = System.getProperty("java.home"); char separator = File.separatorChar; libFolder = new File(javaHome+separator+"bin"); } public void runPreProcess() {} //put here some action you need public void runPostProcess() {} //put here some action you need } 4. create folder /gnu/io/installer/resources/linux/jar and put there linux's version of RXTXcomm.dat (which is renamed RXTXcomm.jar) 5. create folder /gnu/io/installer/resources/linux/lib and put there linux's version of librxtxSerial. so 6. make sure that RXTXInstaller.jar has the following items: /gnu/io/installer/resources/linux/jar/RXTXcomm.jar /gnu/io/installer/resources/linux/lib/librxtxSerial.so 7. modify file installer.pref: jar file RXTXInstaller.jar must have the following item /gnu/io/installer/installer.pref that's basically it for windows you have to do the similar things: just replace linux to windows and librxtxSerial.so to rxtxSerial.dll and create appropriate gnu.io.installer.windows.WindowsRXTXInstaller class package gnu.io.installer.windows; import java.io.File; public class WindowsRXTXInstaller extends gnu.io.installer.RXTXInstaller{ public WindowsRXTXInstaller(){ createJarFolder(); createLibFolder(); addJarResource("RXTXcomm.jar","/gnu/io/installer/resources/ windows/jar/RXTXcomm.dat"); addLibResource("librxtxSerial.so","/gnu/io/installer/ resources/windows/lib/rxtxSerial.dll"); } protected void createJarFolder(){ String javaHome = System.getProperty("java.home"); char separator = File.separatorChar; jarFolder = new File(javaHome+separator+"lib"+separator+"ext"); } protected void createLibFolder(){ String javaHome = System.getProperty("java.home"); char separator = File.separatorChar; libFolder = new File(javaHome+separator+"bin"); } public void runPreProcess() {} //put here some action you need public void runPostProcess() {} //put here some action you need } installer.pref will look like On Mar 20, 2006, at 10:08 AM, Dr. Douglas Lyon wrote: > Hi All, > Is the Auth package able to work properly on > non Mac OS's? > It was not clear from the doc or download. > > Thanks! > - Doug > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx Dmitry Markman From joachim at buechse.de Mon Mar 20 10:49:06 2006 From: joachim at buechse.de (Joachim Buechse) Date: Mon, 20 Mar 2006 18:49:06 +0100 Subject: [Rxtx] BUG: Lock file stays even if port opening fails Message-ID: This was only tested on MacOSX but looking at the code, it should be true for all systems that use lock_uucp. I am opening a port which can not be opened (dialup port of a telephone paired via bluetooth but currently not reachable). The lock file is created and stays arround, even though the port open failed. After looking a bit through the code (of 2.17), I really wonder if it wouldn't be a good idea to make the "locking" an explicit operation called from the java code. This would certainly simplify the generation of meaningfull exceptions (and java based debugging). Maybe even the handling of "preopened" ports should be in the Java part of the lib (again for java based debugging puposes). That beeing said, I have no idea if this would be possible for the 2.07 implementation. Regards, Joachim From tjarvi at qbang.org Mon Mar 20 11:24:22 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 20 Mar 2006 11:24:22 -0700 (MST) Subject: [Rxtx] BUG: Lock file stays even if port opening fails In-Reply-To: References: Message-ID: On Mon, 20 Mar 2006, Joachim Buechse wrote: > This was only tested on MacOSX but looking at the code, it should be true > for all systems that use lock_uucp. > > I am opening a port which can not be opened (dialup port of a telephone > paired via bluetooth but currently not reachable). The lock file is > created and stays arround, even though the port open failed. > > > After looking a bit through the code (of 2.17), I really wonder if it > wouldn't be a good idea to make the "locking" an explicit operation > called from the java code. This would certainly simplify the generation > of meaningfull exceptions (and java based debugging). > Maybe even the handling of "preopened" ports should be in the Java part > of the lib (again for java based debugging puposes). That beeing said, I > have no idea if this would be possible for the 2.07 implementation. > > Regards, Hi Joachim It should be possible in the 2.0-7 implementation too. The calls to RXTXPort.java would not change. We would just do more there Moving more of that logic into Java would be better as many people don't like to look at C code. There is a liblockdev on most Linux distros that can do most of the C code and would be easier to use. The problem is embeded devices will not have that library. The preopened port code has not been really tested. That was a last minute request in a product cycle. I expect it will be tested this year though. As I recall, some devices really do not like CD raising on open. The preopened ports then allow people to mess around in java without power cycling the devices or losing data. -- Trent Jarvi tjarvi at qbang.org From joachim at buechse.de Mon Mar 20 12:01:08 2006 From: joachim at buechse.de (Joachim Buechse) Date: Mon, 20 Mar 2006 20:01:08 +0100 Subject: [Rxtx] BUG: Lock file stays even if port opening fails In-Reply-To: References: Message-ID: Hi Trent, What is your general feeling about moving code to Java? The last days I have been reading quite a bit of the code and there are several things, that might not work as expected. I'll give you two examples from is_device_locked: if LOCKDIR == /var/spool/locks the directory /var/spool/lock will not be checked. LOCKDIR is not checked for lockfiles with unexpected pefixes While these things have probably never been discovered in production, they are still possibly incorrect implementations. If it was Java code, I would write some unit tests producing the errors that could later be corrected. PS: One could imagine to actually implement the whole lockfile handling in Java using some native routines to get the values required (pid, st_dev, st_rdev, ...). On 20.03.2006, at 19:24, Trent Jarvi wrote: > On Mon, 20 Mar 2006, Joachim Buechse wrote: > >> This was only tested on MacOSX but looking at the code, it should >> be true for all systems that use lock_uucp. >> >> I am opening a port which can not be opened (dialup port of a >> telephone paired via bluetooth but currently not reachable). The >> lock file is created and stays arround, even though the port open >> failed. >> >> >> After looking a bit through the code (of 2.17), I really wonder if >> it wouldn't be a good idea to make the "locking" an explicit >> operation called from the java code. This would certainly simplify >> the generation of meaningfull exceptions (and java based debugging). >> Maybe even the handling of "preopened" ports should be in the Java >> part of the lib (again for java based debugging puposes). That >> beeing said, I have no idea if this would be possible for the 2.07 >> implementation. >> >> Regards, > > Hi Joachim > > It should be possible in the 2.0-7 implementation too. The calls > to RXTXPort.java would not change. We would just do more there > Moving more of that logic into Java would be better as many people > don't like to look at C code. There is a liblockdev on most Linux > distros that can do most of the C code and would be easier to use. > The problem is embeded devices will not have that library. > > The preopened port code has not been really tested. That was a > last minute request in a product cycle. I expect it will be tested > this year though. As I recall, some devices really do not like CD > raising on open. The preopened ports then allow people to mess > around in java without power cycling the devices or losing data. > > -- > Trent Jarvi > tjarvi at qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Mon Mar 20 12:21:02 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 20 Mar 2006 12:21:02 -0700 (MST) Subject: [Rxtx] BUG: Lock file stays even if port opening fails In-Reply-To: References: Message-ID: On Mon, 20 Mar 2006, Joachim Buechse wrote: > Hi Trent, > > What is your general feeling about moving code to Java? The last days I > have been reading quite a bit of the code and there are several things, > that might not work as expected. > > I'll give you two examples from is_device_locked: > > if LOCKDIR == /var/spool/locks the directory /var/spool/lock will not be > checked. > LOCKDIR is not checked for lockfiles with unexpected pefixes > > While these things have probably never been discovered in production, > they are still possibly incorrect implementations. If it was Java code, I > would write some unit tests producing the errors that could later be > corrected. > > PS: One could imagine to actually implement the whole lockfile handling > in Java using some native routines to get the values required (pid, > st_dev, st_rdev, ...). Hi Joachim I like the idea of moving more of the code into java but there are some things to consider. If you break this into multiple JNI calls, the performance will drop considerably during enumeration of ports. We are looking for 256 ports per dev type vs (16? in Sun's 2.0 and fewer types). Its hard to make assumptions. I've seen virtual ports start at /dev/foo100 for instance. It works out to over 7500 ports on Linux if you enable them all. We already trim that back by default. See Linux-all-ports in RXTXCommDriver.java. There are also native libraries that rxtx can link to. If you move too much into Java, linking to 'standard' libraries with distros will break. "configure --enable-liblock=yes" will not be doable. This is probably a favorable way with RedHat, Debian, Suse and others. Thats the right thing to do if there will be rpms, dpkg, .. For those reasons, I think it still make sense to keep it to a minimal ~3 calls to JNI code that we can use for speed and versatility. lock() isLocked(), unlock() perhaps. When I say speed, its more about avoiding crossing the JNI layer multiple times than java vs C performance. With versatility I think liblock is the right way for most but not all (embeded) linux distros. -- Trent Jarvi tjarvi at qbang.org From joachim at buechse.de Mon Mar 20 12:42:04 2006 From: joachim at buechse.de (Joachim Buechse) Date: Mon, 20 Mar 2006 20:42:04 +0100 Subject: [Rxtx] BUG: Lock file stays even if port opening fails In-Reply-To: References: Message-ID: <82C19FE7-DDCB-45B6-B2C9-7606B66F0124@buechse.de> Ok, what about providing a default implementation in Java? The RXTXCommDriver would call a (native) function useNativeLocking and if it returns true, call the native functions for lock() isLocked (), unlock(), else is would use the Java based default implementation. This could possibly be overriden by a property (again for debugging). Joachim On 20.03.2006, at 20:21, Trent Jarvi wrote: > On Mon, 20 Mar 2006, Joachim Buechse wrote: > >> Hi Trent, >> >> What is your general feeling about moving code to Java? The last >> days I have been reading quite a bit of the code and there are >> several things, that might not work as expected. >> >> I'll give you two examples from is_device_locked: >> >> if LOCKDIR == /var/spool/locks the directory /var/spool/lock will >> not be checked. >> LOCKDIR is not checked for lockfiles with unexpected pefixes >> >> While these things have probably never been discovered in >> production, they are still possibly incorrect implementations. If >> it was Java code, I would write some unit tests producing the >> errors that could later be corrected. >> >> PS: One could imagine to actually implement the whole lockfile >> handling in Java using some native routines to get the values >> required (pid, st_dev, st_rdev, ...). > > Hi Joachim > > I like the idea of moving more of the code into java but there are > some things to consider. > > If you break this into multiple JNI calls, the performance will > drop considerably during enumeration of ports. We are looking for > 256 ports per dev type vs (16? in Sun's 2.0 and fewer types). Its > hard to make assumptions. I've seen virtual ports start at /dev/ > foo100 for instance. > > It works out to over 7500 ports on Linux if you enable them all. > We already trim that back by default. See Linux-all-ports in > RXTXCommDriver.java. > > There are also native libraries that rxtx can link to. If you move > too much into Java, linking to 'standard' libraries with distros > will break. "configure --enable-liblock=yes" will not be doable. > This is probably a favorable way with RedHat, Debian, Suse and > others. Thats the right thing to do if there will be rpms, dpkg, .. > > For those reasons, I think it still make sense to keep it to a > minimal ~3 calls to JNI code that we can use for speed and > versatility. lock() isLocked(), unlock() perhaps. When I say > speed, its more about avoiding crossing the JNI layer multiple > times than java vs C performance. With versatility I think liblock > is the right way for most but not all (embeded) linux distros. > > -- > Trent Jarvi > tjarvi at qbang.org > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Mon Mar 20 12:44:47 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 20 Mar 2006 12:44:47 -0700 (MST) Subject: [Rxtx] BUG: Lock file stays even if port opening fails In-Reply-To: <82C19FE7-DDCB-45B6-B2C9-7606B66F0124@buechse.de> References: <82C19FE7-DDCB-45B6-B2C9-7606B66F0124@buechse.de> Message-ID: On Mon, 20 Mar 2006, Joachim Buechse wrote: > Ok, what about providing a default implementation in Java? > > The RXTXCommDriver would call a (native) function useNativeLocking and if > it returns true, call the native functions for lock() isLocked(), > unlock(), else is would use the Java based default implementation. This > could possibly be overriden by a property (again for debugging). > Hi Joachim That would be OK with me. -- Trent Jarvi tjarvi at qbang.org From dmarkman at mac.com Mon Mar 20 22:27:45 2006 From: dmarkman at mac.com (Dmitry Markman) Date: Tue, 21 Mar 2006 00:27:45 -0500 Subject: [Rxtx] binaries request Message-ID: <42702213-C222-4937-A585-7CFB17E47608@mac.com> Hi can somebody send me latest linux and windows binaries, please? or where I can find them (I didn't find them in the latest tareball) I gave up with my cygwin: something wrong I have no idea what java doesn't understand /cygwin/c syntax after I changed makefile it did java part but after that gcc 3.4.4 started to complain I set buffer length to 999 lines but I didn't get beginning of the story something wrong with my 1.4.2_09/include/jni.h gcc doesn't like it anyway I gave up thanks in advance Dmitry Markman -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060320/f8cbc57c/attachment-0024.html From tjarvi at qbang.org Mon Mar 20 22:36:48 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 20 Mar 2006 22:36:48 -0700 (MST) Subject: [Rxtx] binaries request In-Reply-To: <42702213-C222-4937-A585-7CFB17E47608@mac.com> References: <42702213-C222-4937-A585-7CFB17E47608@mac.com> Message-ID: On Tue, 21 Mar 2006, Dmitry Markman wrote: > Hi > can somebody send me latest linux and windows binaries, please? > > or where I can find them (I didn't find them in the latest tareball) > > I gave up with my cygwin: something wrong I have no idea what > java doesn't understand /cygwin/c syntax > after I changed makefile it did java part > but after that gcc 3.4.4 started to complain > I set buffer length to 999 lines but I didn't get beginning of the story > something wrong with my 1.4.2_09/include/jni.h gcc doesn't like it > anyway I gave up > > thanks in advance > Hi Dmitry The bins are here: ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7-bins-r2.zip Here are the files in the zip you want. Jar: rxtx-2.1-7-bins-r2/RXTXcomm.jar Windows: rxtx-2.1-7-bins-r2/Windows/i368-mingw32/rxtxSerial.dll Linux (x86) rxtx-2.1-7-bins-r2/Linux/i686-unknown-linux-gnu/librxtxSerial.so There are others in there including Parallel port support but those are the main ones for testing. -- Trent Jarvi tjarvi at qbang.org From dmarkman at mac.com Mon Mar 20 23:05:59 2006 From: dmarkman at mac.com (Dmitry Markman) Date: Tue, 21 Mar 2006 01:05:59 -0500 Subject: [Rxtx] binaries request In-Reply-To: References: <42702213-C222-4937-A585-7CFB17E47608@mac.com> Message-ID: thank you very much but windows's readme says: rxtxSerial.dll had to be recomopiled to link in missing native methods. should I ignore it? or what? thanks again also I understand that I should use mingw not cygwin I'll try to install mingw On Mar 21, 2006, at 12:36 AM, Trent Jarvi wrote: > On Tue, 21 Mar 2006, Dmitry Markman wrote: > >> Hi >> can somebody send me latest linux and windows binaries, please? >> >> or where I can find them (I didn't find them in the latest tareball) >> >> I gave up with my cygwin: something wrong I have no idea what >> java doesn't understand /cygwin/c syntax >> after I changed makefile it did java part >> but after that gcc 3.4.4 started to complain >> I set buffer length to 999 lines but I didn't get beginning of the >> story >> something wrong with my 1.4.2_09/include/jni.h gcc doesn't like it >> anyway I gave up >> >> thanks in advance >> > > Hi Dmitry > > The bins are here: > > ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7-bins-r2.zip > > Here are the files in the zip you want. > > Jar: > > rxtx-2.1-7-bins-r2/RXTXcomm.jar > > Windows: > > rxtx-2.1-7-bins-r2/Windows/i368-mingw32/rxtxSerial.dll > > Linux (x86) > > rxtx-2.1-7-bins-r2/Linux/i686-unknown-linux-gnu/librxtxSerial.so > > There are others in there including Parallel port support but those > are the main ones for testing. > > -- > Trent Jarvi > tjarvi at qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx Dmitry Markman From tjarvi at qbang.org Mon Mar 20 23:20:33 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 20 Mar 2006 23:20:33 -0700 (MST) Subject: [Rxtx] binaries request In-Reply-To: References: <42702213-C222-4937-A585-7CFB17E47608@mac.com> Message-ID: On Tue, 21 Mar 2006, Dmitry Markman wrote: > thank you very much > > but windows's readme says: > rxtxSerial.dll had to be recomopiled to link in missing native methods. > > should I ignore it? or what? > Hi Dmitry That dll should be OK. r2 is the recompile linked to the missing native method. The readme explains why it was recompiled; fuser.o was not linked into the dll in the first release. -- Trent Jarvi tjarvi at qbang.org From ariantristan at yahoo.com Mon Mar 20 23:55:24 2006 From: ariantristan at yahoo.com (Lambok Sianturi) Date: Mon, 20 Mar 2006 22:55:24 -0800 (PST) Subject: [Rxtx] jvm issue Message-ID: <20060321065524.94779.qmail@web50701.mail.yahoo.com> Hi All, This is my first time to join RxTx mailing list. I thank you all for allowing others to sign in in requests help. I use the latest RxTx lib in Fedora 3 with java version 1.4.2_09 b05. And I got this error: # # An unexpected error has been detected by HotSpot Virtual Machine: # # SIGSEGV (0xb) at pc=0x00bf27f3, pid=2633, tid=3086112448 # # Java VM: Java HotSpot(TM) Client VM (1.4.2_09-b05 mixed mode) # Problematic frame: # C [ld-linux.so.2+0xa7f3] # # An error report file with more information is saved as hs_err_pid2633.log # # If you would like to submit a bug report, please visit: # http://java.sun.com/webapps/bugreport/crash.jsp # ./run.sh: line 3: 2633 Aborted /usr/local/java/bin/java -Djava.library.path=/usr/local/java/jre/lib/ -Djsmsengine.debug=true -classpath jsmsengine.jar:smsgateway.jar:classes12.jar:RXTXcomm.jar:. com.api.sms.SMSServer What is the jvm depedency for the latest library? Can I use 1.4.2_09 b05? Thanks in advance. Arian --------------------------------- Yahoo! Mail Use Photomail to share photos without annoying attachments. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060320/83d58dd7/attachment-0024.html From f.frumento at ngi.it Tue Mar 21 00:21:47 2006 From: f.frumento at ngi.it (Fabio Frumento) Date: Tue, 21 Mar 2006 08:21:47 +0100 Subject: [Rxtx] Javadoc on the go Message-ID: <441FA98B.9050701@ngi.it> Hi Trent, sorry for the big delay but my job is running wild, i was out for some time but now i'm back and ready to continue the javadoc for Rxtx. Did you used the last javadoc patch i sent you ? let me know if i have to send it to you again or not. regards Fabio From lyon at docjava.com Tue Mar 21 00:51:18 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Tue, 21 Mar 2006 02:51:18 -0500 Subject: [Rxtx] lock files Message-ID: Hi All, You know, if the use of lock files were under Java control (rather than a build-time decision), it might enable a more unified binary distro. It might also facilitate quick prototyping of non-lock file approaches to resolving serial port contention issues (i.e., mac-like approaches vs. linux approaches, etc.). I realize that this is a radical overhaul of the lock file policy issue. Also, it may harm performance. On the other hand, our benchmarks on JNI overhead for modern processors indicate performance impact should be minimal. Perhaps it is more of an issue with the toybox systems. Suppose there were a class with a reasonable default...someone might write: SerialPortLockPolicy.setPolicy(SerialPortLockPolicy.UNIX_LOCK_FILE); SerialPortLockPolicy.setPolicy(SerialPortLockPolicy.NO_LOCK_CHECKING); SerialPortLockPolicy.setPolicy(SerialPortLockPolicy.MAC_STYLE); Thus, we could have a run-time reconfiguration of the serial port lock policy. A special NO_LOCK version of the binary would no longer be required. Any thoughts on this? Thanks! - Doug From joachim at buechse.de Tue Mar 21 03:09:09 2006 From: joachim at buechse.de (Joachim Buechse) Date: Tue, 21 Mar 2006 11:09:09 +0100 Subject: [Rxtx] lock files In-Reply-To: References: Message-ID: <8E12916A-1B9A-4FF2-B684-E2D1C794221B@buechse.de> This is pretty much what I thought about when I suggested, that the default behaviour could be overwritten with a property. I am very much in favor of this approach. In particular this allows much easier debugging for PC based java developers. I think big parts of the Java (and maybe some parts of the C code) could use a bit of a structural workover (unit tests, javadoc, synchronization, etc). Maybe there should be a CVS branch for this experimental version. I'd be happy to contribute a first workover for some of the Java code. Designing for testability and implementing a good bunch of unit tests has been a strategy that worked quite well in the Java projects I lead. And it ultimately allows more liberal change permission. Regards, Joachim On 21.03.2006, at 08:51, Dr. Douglas Lyon wrote: > Hi All, > You know, if the use of lock files were > under Java control (rather than a build-time decision), > it might enable a more unified binary distro. It might also > facilitate quick prototyping of non-lock file approaches > to resolving serial port contention issues (i.e., mac-like > approaches vs. linux approaches, etc.). > > I realize that this is a radical overhaul of the lock file policy > issue. Also, it may harm performance. On the other hand, > our benchmarks on JNI overhead for modern processors indicate > performance impact should be minimal. Perhaps it is more of > an issue with the toybox systems. > > Suppose there were a class with a reasonable default...someone > might write: > SerialPortLockPolicy.setPolicy(SerialPortLockPolicy.UNIX_LOCK_FILE); > SerialPortLockPolicy.setPolicy(SerialPortLockPolicy.NO_LOCK_CHECKING); > SerialPortLockPolicy.setPolicy(SerialPortLockPolicy.MAC_STYLE); > > Thus, we could have a run-time reconfiguration of the serial port lock > policy. A special NO_LOCK version of the binary would no longer > be required. > > Any thoughts on this? > > Thanks! > - Doug > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From joachim at buechse.de Tue Mar 21 06:23:08 2006 From: joachim at buechse.de (Joachim Buechse) Date: Tue, 21 Mar 2006 14:23:08 +0100 Subject: [Rxtx] PATCH: use of ioctl(fd, TIOCEXCL) instead of lockfiles Message-ID: <923AE774-EEA2-4911-92D8-32BB27802C8B@buechse.de> Here is the patch for the ioctl(fd, TIOCEXCL). I have verified this only for OSX 10.4.5, hence it is only defined for APPLE. However, it should work at least for Solaris as well. If a process has requested TIOEXCL further open calls by other user processes will fail. The patch also disables uucp style locking for APPLE. Obviously this is discussable. I think it is the way to go, as it eliminates creating the lock directory which doesnt exist on the standard installation and it eliminates messing with the system group definitions (adding users to group uucp). Regarding the possibility of root processes opening a device which is locked - I consider this a feature not a potential problem. It is highly unlikely, that somebody is crazy enough to run a JavaVM as root (unless he has no other means of getting a restricted IP port opened, ie doesnt understand ipfw). Anyway, even if the process runs as root, it fails when calling ioctl(fd, TIOCEXCL). It could however still open the port to listen for RING events. I.e. a fax server which needs to see incoming calls but otherwise doesnt want to block the port. So the only case where the proposed mechanism fails is, if an incorrectly implemented process running as root conflicts with a user process. I think this can be accepted. Regards, Joachim PS: If this patch is generally accepted, the installer and Mac doku should obviously be changed as well. Index: SerialImp.c =================================================================== RCS file: /usr/local/cvsroot/rxtx-devel/src/SerialImp.c,v retrieving revision 1.46.2.187 diff -u -r1.46.2.187 SerialImp.c --- SerialImp.c 29 Jan 2006 22:19:04 -0000 1.46.2.187 +++ SerialImp.c 21 Mar 2006 12:59:16 -0000 @@ -656,6 +656,25 @@ fd=OPEN (filename, O_RDWR | O_NOCTTY | O_NONBLOCK ); } while (fd < 0 && errno==EINTR); +#ifdef OPEN_EXCL + // Note that open() follows POSIX semantics: multiple open() calls to + // the same file will succeed unless the TIOCEXCL ioctl is issued. + // This will prevent additional opens except by root-owned processes. + // See tty(4) ("man 4 tty") and ioctl(2) ("man 2 ioctl") for details. + + if (fd >= 0 && (ioctl(fd, TIOCEXCL) == -1)) + { + sprintf( message, "open: exclusive access denied for % s\n", + filename ); + report( message ); + report_error( message ); + + close(fd); + goto fail; + } +#endif /* OPEN_EXCL */ + + if( configure_port( fd ) ) goto fail; (*env)->ReleaseStringUTFChars( env, jstr, filename ); sprintf( message, "open: fd returned is %i\n", fd ); Index: SerialImp.h =================================================================== RCS file: /usr/local/cvsroot/rxtx-devel/src/SerialImp.h,v retrieving revision 1.11.2.49 diff -u -r1.11.2.49 SerialImp.h --- SerialImp.h 5 Jul 2005 17:47:21 -0000 1.11.2.49 +++ SerialImp.h 21 Mar 2006 12:59:17 -0000 @@ -135,7 +135,8 @@ /*# define LOCKDIR "/var/spool/uucp"*/ # define LOCKDIR "/var/lock" # define LOCKFILEPREFIX "LK." -# define UUCP +/*# define UUCP*/ +# define OPEN_EXCL #endif /* __APPLE__ */ #if defined(__NetBSD__) # define DEVICEDIR "/dev/" From tjarvi at qbang.org Tue Mar 21 10:26:08 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 21 Mar 2006 10:26:08 -0700 (MST) Subject: [Rxtx] Javadoc on the go In-Reply-To: <441FA98B.9050701@ngi.it> References: <441FA98B.9050701@ngi.it> Message-ID: On Tue, 21 Mar 2006, Fabio Frumento wrote: > Hi Trent, > > sorry for the big delay but my job is running wild, i was out for some > time but now i'm back and ready to continue the javadoc for Rxtx. > > Did you used the last javadoc patch i sent you ? let me know if i have to > send it to you again or not. > > regards > > Fabio Hi Fabio The patch is in the rxtx mail-list archives. It will be going in soon. I did not see a time critical portion. I'll probably be going through the list since the last batch of patches this weekend and putting them into CVS. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Tue Mar 21 10:57:18 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 21 Mar 2006 10:57:18 -0700 (MST) Subject: [Rxtx] jvm issue In-Reply-To: <20060321065524.94779.qmail@web50701.mail.yahoo.com> References: <20060321065524.94779.qmail@web50701.mail.yahoo.com> Message-ID: On Mon, 20 Mar 2006, Lambok Sianturi wrote: > Hi All, > This is my first time to join RxTx mailing list. I thank you all for allowing others to sign in in requests help. > I use the latest RxTx lib in Fedora 3 with java version 1.4.2_09 b05. And I got this error: > > # > # An unexpected error has been detected by HotSpot Virtual Machine: > # > # SIGSEGV (0xb) at pc=0x00bf27f3, pid=2633, tid=3086112448 > # > # Java VM: Java HotSpot(TM) Client VM (1.4.2_09-b05 mixed mode) > # Problematic frame: > # C [ld-linux.so.2+0xa7f3] A native library loading error? What happens if you recompile rxtx on your system and install that? This sounds like an ABI problem? rxtx 2.1-7 was compiled with a gcc 2.96 toolchain as I recall. The hope is newer system will be backwards compatible. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Tue Mar 21 11:05:29 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 21 Mar 2006 11:05:29 -0700 (MST) Subject: [Rxtx] PATCH: use of ioctl(fd, TIOCEXCL) instead of lockfiles In-Reply-To: <923AE774-EEA2-4911-92D8-32BB27802C8B@buechse.de> References: <923AE774-EEA2-4911-92D8-32BB27802C8B@buechse.de> Message-ID: On Tue, 21 Mar 2006, Joachim Buechse wrote: > Here is the patch for the ioctl(fd, TIOCEXCL). I have verified this only > for OSX 10.4.5, hence it is only defined for APPLE. However, it should > work at least for Solaris as well. > > If a process has requested TIOEXCL further open calls by other user > processes will fail. > > The patch also disables uucp style locking for APPLE. Obviously this is > discussable. I think it is the way to go, as it eliminates creating the > lock directory which doesnt exist on the standard installation and it > eliminates messing with the system group definitions (adding users to > group uucp). > > Regarding the possibility of root processes opening a device which is > locked - I consider this a feature not a potential problem. It is highly > unlikely, that somebody is crazy enough to run a JavaVM as root (unless > he has no other means of getting a restricted IP port opened, ie doesnt > understand ipfw). Anyway, even if the process runs as root, it fails when > calling ioctl(fd, TIOCEXCL). It could however still open the port to > listen for RING events. I.e. a fax server which needs to see incoming > calls but otherwise doesnt want to block the port. So the only case where > the proposed mechanism fails is, if an incorrectly implemented process > running as root conflicts with a user process. I think this can be > accepted. > > Regards, > Joachim > > PS: If this patch is generally accepted, the installer and Mac doku > should obviously be changed as well. > > > Index: SerialImp.c > =================================================================== > RCS file: /usr/local/cvsroot/rxtx-devel/src/SerialImp.c,v > retrieving revision 1.46.2.187 > diff -u -r1.46.2.187 SerialImp.c > --- SerialImp.c 29 Jan 2006 22:19:04 -0000 1.46.2.187 > +++ SerialImp.c 21 Mar 2006 12:59:16 -0000 > @@ -656,6 +656,25 @@ > fd=OPEN (filename, O_RDWR | O_NOCTTY | O_NONBLOCK ); > } while (fd < 0 && errno==EINTR); > > +#ifdef OPEN_EXCL > + // Note that open() follows POSIX semantics: multiple open() > calls to > + // the same file will succeed unless the TIOCEXCL ioctl is > issued. > + // This will prevent additional opens except by root-owned > processes. > + // See tty(4) ("man 4 tty") and ioctl(2) ("man 2 ioctl") for > details. > + > + if (fd >= 0 && (ioctl(fd, TIOCEXCL) == -1)) > + { > + sprintf( message, "open: exclusive access denied for % > s\n", > + filename ); > + report( message ); > + report_error( message ); > + > + close(fd); > + goto fail; > + } > +#endif /* OPEN_EXCL */ > + > + > if( configure_port( fd ) ) goto fail; > (*env)->ReleaseStringUTFChars( env, jstr, filename ); > sprintf( message, "open: fd returned is %i\n", fd ); > Index: SerialImp.h > =================================================================== > RCS file: /usr/local/cvsroot/rxtx-devel/src/SerialImp.h,v > retrieving revision 1.11.2.49 > diff -u -r1.11.2.49 SerialImp.h > --- SerialImp.h 5 Jul 2005 17:47:21 -0000 1.11.2.49 > +++ SerialImp.h 21 Mar 2006 12:59:17 -0000 > @@ -135,7 +135,8 @@ > /*# define LOCKDIR "/var/spool/uucp"*/ > # define LOCKDIR "/var/lock" > # define LOCKFILEPREFIX "LK." > -# define UUCP > +/*# define UUCP*/ > +# define OPEN_EXCL > #endif /* __APPLE__ */ > #if defined(__NetBSD__) > # define DEVICEDIR "/dev/" > This looks like a good start. What do you think Dmitry? Perhaps all systems with TIOCEXCL defined should use that though. Even if they use lockfiles. It wont hurt anything. That would catch people hacking their own serial apps without checking lockfiles. Its a good idea to avoid C++ style comments in the C portions. Some older systems don't deal with them well. If it's just for Mac OS X, it isn't a big deal. I think it was the Irix compiler that was problematic? -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Tue Mar 21 11:22:05 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 21 Mar 2006 11:22:05 -0700 (MST) Subject: [Rxtx] lock files In-Reply-To: <8E12916A-1B9A-4FF2-B684-E2D1C794221B@buechse.de> References: <8E12916A-1B9A-4FF2-B684-E2D1C794221B@buechse.de> Message-ID: We can try it. Maybe the JNI is much improved. The nice thing about linking into liblock is distros then worry about lockfiles on their systems. This way, we have to deal with any changes that may show up. On Tue, 21 Mar 2006, Joachim Buechse wrote: > This is pretty much what I thought about when I suggested, that the > default behaviour could be overwritten with a property. I am very much in > favor of this approach. In particular this allows much easier debugging > for PC based java developers. > > I think big parts of the Java (and maybe some parts of the C code) could > use a bit of a structural workover (unit tests, javadoc, synchronization, > etc). Maybe there should be a CVS branch for this experimental version. > I'd be happy to contribute a first workover for some of the Java code. > Designing for testability and implementing a good bunch of unit tests has > been a strategy that worked quite well in the Java projects I lead. And > it ultimately allows more liberal change permission. > > Regards, > Joachim > > > On 21.03.2006, at 08:51, Dr. Douglas Lyon wrote: > >> Hi All, >> You know, if the use of lock files were >> under Java control (rather than a build-time decision), >> it might enable a more unified binary distro. It might also >> facilitate quick prototyping of non-lock file approaches >> to resolving serial port contention issues (i.e., mac-like >> approaches vs. linux approaches, etc.). >> >> I realize that this is a radical overhaul of the lock file policy >> issue. Also, it may harm performance. On the other hand, >> our benchmarks on JNI overhead for modern processors indicate >> performance impact should be minimal. Perhaps it is more of >> an issue with the toybox systems. >> >> Suppose there were a class with a reasonable default...someone >> might write: >> SerialPortLockPolicy.setPolicy(SerialPortLockPolicy.UNIX_LOCK_FILE); >> SerialPortLockPolicy.setPolicy(SerialPortLockPolicy.NO_LOCK_CHECKING); >> SerialPortLockPolicy.setPolicy(SerialPortLockPolicy.MAC_STYLE); >> >> Thus, we could have a run-time reconfiguration of the serial port lock >> policy. A special NO_LOCK version of the binary would no longer >> be required. >> >> Any thoughts on this? >> >> Thanks! >> - Doug >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From dmarkman at mac.com Tue Mar 21 16:05:17 2006 From: dmarkman at mac.com (Dmitry Markman) Date: Tue, 21 Mar 2006 18:05:17 -0500 Subject: [Rxtx] PATCH: use of ioctl(fd, TIOCEXCL) instead of lockfiles In-Reply-To: References: <923AE774-EEA2-4911-92D8-32BB27802C8B@buechse.de> Message-ID: <512AC70C-BB86-48F2-A83C-023F35C23BAB@mac.com> I think it's cool, but I'd like to have that property implementation when user can choose between locking mechanism about comments: it's easy to change comments to the C style or we can use extensions of the file to cpp so c++ compiler will be used On Mar 21, 2006, at 1:05 PM, Trent Jarvi wrote: > This looks like a good start. What do you think Dmitry? Perhaps > all systems with TIOCEXCL defined should use that though. Even if > they use lockfiles. It wont hurt anything. That would catch > people hacking their own serial apps without checking lockfiles. > > Its a good idea to avoid C++ style comments in the C portions. > Some older systems don't deal with them well. If it's just for Mac > OS X, it isn't a big deal. I think it was the Irix compiler that > was problematic? Dmitry Markman From dmarkman at mac.com Tue Mar 21 16:13:00 2006 From: dmarkman at mac.com (Dmitry Markman) Date: Tue, 21 Mar 2006 18:13:00 -0500 Subject: [Rxtx] PATCH: use of ioctl(fd, TIOCEXCL) instead of lockfiles In-Reply-To: References: <923AE774-EEA2-4911-92D8-32BB27802C8B@buechse.de> Message-ID: I'd like to add that creating locking folder isn't a big deal we never had a problem related to the lock folders, because we always used installer on mac os x from other hand I'm not very much familiar with iotcl locking approach and I'm not sure it's more efficient Joachim wrote "I think it is the way to go, as it eliminates creating the lock directory which doesnt exist on the standard installation and it eliminates messing with the system group definitions (adding users to group uucp)." but I really didn't have any problem with that 1. doesn't exist on the standard installation there are many-many things that don't exist in the standard installation so I don't think that argument is strong enough 2. messing with the system group definitions I don't think we're messing with the group definition mac os x provides very clear way to set up group's members and together with Greg Guerin AuthKit there is no problem to set those definitions so I don't think that argument is strong either but from other hand using iotcl is more promising and is more elegant On Mar 21, 2006, at 1:05 PM, Trent Jarvi wrote: > > This looks like a good start. What do you think Dmitry? Perhaps > all systems with TIOCEXCL defined should use that though. Even if > they use lockfiles. It wont hurt anything. That would catch > people hacking their own serial apps without checking lockfiles. Dmitry Markman From joachim at buechse.de Wed Mar 22 04:46:45 2006 From: joachim at buechse.de (Joachim Buechse) Date: Wed, 22 Mar 2006 12:46:45 +0100 Subject: [Rxtx] PATCH: use of ioctl(fd, TIOCEXCL) instead of lockfiles In-Reply-To: References: <923AE774-EEA2-4911-92D8-32BB27802C8B@buechse.de> Message-ID: Sorry, I was not very clear with my arguments, so I will try again;-) Please, don't take this as an attack against work that has been done. I think the contributions that have been made in the past were made in a good spirit. But I really believe, that the current solution for OSX has many shortcomings and should be changed as soon as possible. lock files --- The /var/lock folder does not exist on the standard OSX installation, however the standard installation includes several applications that use serial ports (i.e. the FAX capability). This indicates, that the lock folder approach will not work well with system components. Applications for OSX will generally try to live in harmony with system components (except for HP print drivers of course). I think RXTX should follow this approach as well. uucp group --- Accessing serial ports is not an admin privileged operation on OSX. Any user (world) has read/write privileges on /dev/tty*. So the system default is to not enforce any group membership to access these ports. The group uucp however is a system group on all unix systems I know. It exists for certain system processes. A non admin user should in general not be a member of this group. Quite arguably no user should ever be a member of this group. Installer --- My general opinion is, that - no Installer should touch user or group data without warning - no Application Installer should touch groups which are not specific to the very application installed - no Installer should ever add regular users to a system group The current installer injects the installing user in the group uucp without warning about this change and without giving the option to "opt out" of this change. This is a potential security risk (but not currently a real one, as OSX contains no folders belonging to group uucp). The current installer does not work for multi user systems. It puts the installing user in the uucp group. However the installing user is not necessarily the user that will use the application. Putting all users that may use a serial port application in the system group uucp seems like a very invasive approach to me. Besides that, newly created users will not automatically be in the group and hence, serial applications will "break" for new users without obvious reasons. Avoiding the lock files will allow self contained applications (i.e. drag&drop installation). In my eyes this is largely preferable over an installer that requests admin privileges. Adding up all these points indicates very strongly, that the lock-file implementation is not the way to go on OSX. Regards, Joachim On 22.03.2006, at 00:13, Dmitry Markman wrote: > I'd like to add that > > creating locking folder isn't a big deal > we never had a problem related to the lock folders, because we > always used installer on mac os x > from other hand I'm not very much familiar with iotcl locking > approach and I'm not sure it's more efficient > > Joachim wrote "I think it is the way to go, as it eliminates > creating the lock directory which doesnt exist on the standard > installation and it eliminates messing with the system group > definitions (adding users to group uucp)." but I really didn't have > any problem with that > > 1. doesn't exist on the standard installation > there are many-many things that don't exist in the standard > installation so I don't think that argument is strong enough > 2. messing with the system group definitions > I don't think we're messing with the group definition > mac os x provides very clear way to set up group's members and > together with Greg Guerin AuthKit there is no problem to set those > definitions > so I don't think that argument is strong either > but from other hand using iotcl is more promising and is more elegant > > > > On Mar 21, 2006, at 1:05 PM, Trent Jarvi wrote: > >> >> This looks like a good start. What do you think Dmitry? Perhaps >> all systems with TIOCEXCL defined should use that though. Even if >> they use lockfiles. It wont hurt anything. That would catch >> people hacking their own serial apps without checking lockfiles. > > Dmitry Markman > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From dmarkman at mac.com Wed Mar 22 05:27:13 2006 From: dmarkman at mac.com (Dmitry Markman) Date: Wed, 22 Mar 2006 07:27:13 -0500 Subject: [Rxtx] PATCH: use of ioctl(fd, TIOCEXCL) instead of lockfiles In-Reply-To: References: <923AE774-EEA2-4911-92D8-32BB27802C8B@buechse.de> Message-ID: <83440CF3-DCD8-41C1-B941-F227232C27E3@mac.com> thanks for the very good explanation I didn't think that you were attacking any thing, so don't worry I just had feeling, that there were more aesthetic reasons for going to ioctl then real necessity now you explained everything quite well (BTW, asfar as I remember installer asks admin password so it wasn't quiet, but it really doesn't matter now) thanks On Mar 22, 2006, at 6:46 AM, Joachim Buechse wrote: > Sorry, I was not very clear with my arguments, so I will try again;-) > > Please, don't take this as an attack against work that has been > done. I think the contributions that have been made in the past > were made in a good spirit. But I really believe, that the current > solution for OSX has many shortcomings and should be changed as > soon as possible. > > lock files > --- > The /var/lock folder does not exist on the standard OSX > installation, however the standard installation includes several > applications that use serial ports (i.e. the FAX capability). This > indicates, that the lock folder approach will not work well with > system components. Applications for OSX will generally try to live > in harmony with system components (except for HP print drivers of > course). I think RXTX should follow this approach as well. > > uucp group > --- > Accessing serial ports is not an admin privileged operation on OSX. > Any user (world) has read/write privileges on /dev/tty*. So the > system default is to not enforce any group membership to access > these ports. The group uucp however is a system group on all unix > systems I know. It exists for certain system processes. A non admin > user should in general not be a member of this group. Quite > arguably no user should ever be a member of this group. > > Installer > --- > My general opinion is, that > - no Installer should touch user or group data without warning > - no Application Installer should touch groups which are not > specific to the very application installed > - no Installer should ever add regular users to a system group > > The current installer injects the installing user in the group uucp > without warning about this change and without giving the option to > "opt out" of this change. This is a potential security risk (but > not currently a real one, as OSX contains no folders belonging to > group uucp). > > The current installer does not work for multi user systems. It puts > the installing user in the uucp group. However the installing user > is not necessarily the user that will use the application. Putting > all users that may use a serial port application in the system > group uucp seems like a very invasive approach to me. Besides that, > newly created users will not automatically be in the group and > hence, serial applications will "break" for new users without > obvious reasons. > > > Avoiding the lock files will allow self contained applications > (i.e. drag&drop installation). In my eyes this is largely > preferable over an installer that requests admin privileges. Adding > up all these points indicates very strongly, that the lock-file > implementation is not the way to go on OSX. > > Regards, > Joachim > > > On 22.03.2006, at 00:13, Dmitry Markman wrote: > >> I'd like to add that >> >> creating locking folder isn't a big deal >> we never had a problem related to the lock folders, because we >> always used installer on mac os x >> from other hand I'm not very much familiar with iotcl locking >> approach and I'm not sure it's more efficient >> >> Joachim wrote "I think it is the way to go, as it eliminates >> creating the lock directory which doesnt exist on the standard >> installation and it eliminates messing with the system group >> definitions (adding users to group uucp)." but I really didn't >> have any problem with that >> >> 1. doesn't exist on the standard installation >> there are many-many things that don't exist in the standard >> installation so I don't think that argument is strong enough >> 2. messing with the system group definitions >> I don't think we're messing with the group definition >> mac os x provides very clear way to set up group's members and >> together with Greg Guerin AuthKit there is no problem to set those >> definitions >> so I don't think that argument is strong either >> but from other hand using iotcl is more promising and is more elegant >> >> >> >> On Mar 21, 2006, at 1:05 PM, Trent Jarvi wrote: >> >>> >>> This looks like a good start. What do you think Dmitry? Perhaps >>> all systems with TIOCEXCL defined should use that though. Even >>> if they use lockfiles. It wont hurt anything. That would catch >>> people hacking their own serial apps without checking lockfiles. >> >> Dmitry Markman >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx Dmitry Markman From lyon at docjava.com Wed Mar 22 06:12:18 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Wed, 22 Mar 2006 08:12:18 -0500 Subject: [Rxtx] sole of a new design pattern Message-ID: Hi All, I have been thinking about how we design the serial port software. I think we need a new design pattern. For lack of a better term, I shall call it: The Parametric Singleton Design Pattern By Douglas A. Lyon ABSTRACT The goal of the singleton design pattern is to make sure that there is one, and only one, instance of a given class. The goal of the parametric singleton design pattern is to make sure that there is one, and only one, instance of a given class with the given parametric values. We parametric singleton design pattern combines the singleton design pattern with a parameter that enables unique creation of instances of a class. These instances are cached. When a user asks for an instance with these parameters, the cache is checked. If the instance is in the cache, the instance is returned, otherwise it is created, added to the cache and then returned. We apply our parametric singleton design pattern to the retrieval of RMI registries bound to a given port. The goal of our system is to make sure that no two RMI registries are listening to the same socket and to make use of the RMI registries after they have been created. RMI registries are used in distributed computation. Introduction The singleton design pattern is meant to ensure that on a single instance of a class exists. It is also meant to provide a global point of access to it. The intent of the parametric singleton design pattern is to ensure that a class has only one instance for a given set of parameter values. It also provides a global point of access to it. Motivation A system cannot tolerate multiple instances of some classes with identical parameters. For example, you cannot have two instances making use of the same serial port, at the same time. You cannot have two instances that are trying to listen to the same socket connection. You cannot have two instances writing to the same file structure at the same time. As the operating system is often thought of as the arbiter of consumed resources (i.e., tape drives, serial ports, etc.) we frequently leave it to an operating system implementation to resolve these contention issues. Even for similar resources (like serial ports) there are few standards for handling contention. For example, serial ports on Linux are locked using a "/var/lock" file. POSIX, on the other hand, uses ioctl mechanisms to prevent contention. A better solution is to make a class that is responsible for keeping track of the instances created from the class. The class is declared final, so that it cannot be subclassed. The class also has a private constructor, so that other classes cannot instance it. The new design pattern is called the parametric singleton design pattern and it provides a way to access and create instances with given parameters. Applicability Use the Parametric Singleton Design Pattern when: 1. There must be exactly one instance of a class with the given parameters. 2. The instances must be accessible to clients from a well-known access point. Structure Insert UML diagram here. Participants The Parametric Singleton Clients that need instances 1. The Parametric Singleton defines an instance upon request from a client, if, and only if, the instance does not already exist. 2. The Parametric Singleton returns the instance to the client. 3. The Parametric Singleton is responsible for creating unique instances from given parameters. Collaborations Clients obtain a reference to a Parametric Singleton instance only through the parametric singleton design pattern. If the instance is left in an improper state (e.g., the serial port was left open) it is NOT the role of the Parametric Singleton Design Pattern to close the IO port. Nor is it the role of the Parametric Singleton Design Pattern to open the port. That role is delegate to some other part of the system. Further, it is not the role of the Parametric Singleton Design Pattern to check out resources. That is, multiple threads can have multiple references to the same resource at the same time. MUTEX locking is delegated to some other part of the system. Consequences The Parametric Singleton Design Pattern has several benefits: 1. Controlled access to parametrically defined instances. Since the Parametric Singleton class encapsulates its instances, there is control over how and when clients access it. 2. Reduced name space. The Parametric Singleton pattern avoids global variables that store instances created from the same parameter. Implementation Here are implementation issues to consider when using the Parametric Singleton pattern: 1. Unique mapping of parameters. The Parametric Singleton pattern requires that there be a mean to isomorphically map the parameter space into the instance space and back again. 2. Ensure unique instances. The Parametric Singleton pattern makes unique instances from parameters, and it does so only once. 3. Cache instances for fast retrieval. The Parametric Singleton pattern must be able to look up instances, given some set of parameters, and do so from some data structure. That is, there must be enough space to hold references to all the instances the program will need. Also, a mechanism is needed to look up and retrieve the instances quickly enough to satisfy the clients. Sample Code public final class ParametricSingletonRmiRegistry { private static Hashtable registry = new Hashtable(100); // use singleton pattern and??????????????????????????????????????????????? // prevent instantiation of RmiRegistryUtils.?????????????????????????????? private ParametricSingletonRmiRegistry() { } // the only instance of the Registry held by the RmiRegistryUtils?????????? public static void listNames(Integer port) { if (!isInCacheAndRunning(port)) return; Registry r = (Registry) registry.get(port); System.out.println("registry on port: " + port); System.out.println("registry: " + r); System.out.println("names: "); try { print(r.list()); } catch (RemoteException e) { In.message(e); } System.out.println("------------------------"); } /**???????????????????????????????????????????????????????????????????????? * Checks whether a Registry has been started on this host????????????????? * in the specified port.?????????????????????????????????????????????????? * If not, it tries to start one.?????????????????????????????????????????? * when it fails to start a Registry, it exits the program????????????????? * with exit code 1.??????????????????????????????????????????????????????? */ public static void restart(int port) { if (isInCacheAndRunning(port)) return; try { startRegistry(port); } catch (RemoteException e) { In.message(e); } } /**???????????????????????????????????????????????????????????????????????? * @param port????????????????????????????????????????????????????????????? * @return true if registry is in cache and running???????????????????????? */ private static boolean isInCacheAndRunning(Integer port) { if (!isRegistryRunning(port.intValue())) return false; if (!isRegistryInCache(port.intValue())) return false; return true; } /**???????????????????????????????????????????????????????????????????????? * @param port????????????????????????????????????????????????????????????? * @return true if we are able to locate a local registry on port.??????????????????????????????????????????????????????????????????????????? */ private static boolean isRegistryRunning(int port) { try { Registry r = LocateRegistry.getRegistry(port); if (r != null) return true; } catch (RemoteException e) { return false; } return false; } /**???????????????????????????????????????????????????????????????????????? * @param port????????????????????????????????????????????????????????????? * @return return true if registry is in cache????????????????????????????? */ private static boolean isRegistryInCache(int port) { if (registry.get(new Integer(port)) == null) return false; return true; } /**???????????????????????????????????????????????????????????????????????? * Restart the registry, if needed.???????????????????????????????????????? * Return the only instance of the registry for consistent global?????????? * using by making use of the Singleton Design Pattern????????????????????? *????????????????????????????????????????????????????????????????????????? * @return the internally held registry instance.?????????????????????????? */ public static Registry getRegistry(Integer port) { restart(port); return (Registry) registry.get(port); } private static void startRegistry(Integer port) throws RemoteException { Registry r; try { r = LocateRegistry.createRegistry(port.intValue()); registry.put(port, r); //r = new sun.rmi.registry.RegistryImpl???????????????????????????? /// (port.intValue());?????????????????????????????????????? // registry.put(port, r);?????????????????????????????????????????? } catch (Exception e) { //e.printStackTrace();????????????????????????????????????????????? r = LocateRegistry.getRegistry(port.intValue()); registry.put(port, r); } } public static void main(String args[]) throws RemoteException { //restart(port);??????????????????????????????????????????????????????? restart(5001); restart(5002); restart(5002); Registry r = LocateRegistry.getRegistry(5002); System.out.println("registry="+r); } } I would very much like to get your feedback on this new design pattern idea. Thank you for your time. Regards, - Doug From david.garnier at trusted-logic.com Wed Mar 22 07:36:10 2006 From: david.garnier at trusted-logic.com (David Garnier) Date: Wed, 22 Mar 2006 15:36:10 +0100 Subject: [Rxtx] sole of a new design pattern In-Reply-To: References: Message-ID: <442160DA.80107@trusted-logic.com> Hello, > The Parametric Singleton Design Pattern The Singleton is the most abused design pattern ever. Good use-cases for this pattern are extremely rare and mostly confined to problems related to hardware resources, like serial ports. > Applicability > > Use the Parametric Singleton Design Pattern when: > 1. There must be exactly one instance of a class with the given > parameters. OK. As I said above, this case this actually very unusual. The Singleton pattern is mostly used when : > 2. The instances must be accessible to clients from a well-known > access point. Using the singleton pattern in this case is just convenient for the programmer. Problems arises pretty quickly, especially if you attempt to unit-test your classes. 1) If your singleton is stateful, or hold on to stateful objects, it means that two different unit tests are not actually independent. Instead of starting with a brand new environment, the result of a test may be affected by the result of a previous test. This problem also arise when with your class relies on a database. In both cases, the solution is to reset your "unique" resource (Singleton or database) at the beginning of the test, which is a pain. Also, while most projects connect to a single database, projects that allow the use of Singletons usually contain several of thems, and new ones may cropped up unnoticed. You quickly end up with test cases that only pass in a certain order, which is a royal pain. 2) You cannot mockup a singleton. Once everyone calls the SomeSingleton class statically, you can't replace your class by SomeSingletonMockup. Furthermore, even for hardware services, the Singleton pattern does not really prevent concurrent accesses. If you start the same program in two different JVMs, unless they somehow shared the state of their "Singletons" (through lock files for example), the Singleton pattern will not prevent concurrent access. Our application uses RXTX, and we routinely encounter cases where another (native) application has already locked the port. Since we cannot modify the native application to recognize lock files, OS-level control is irreplaceable. > > Consequences > The Parametric Singleton Design Pattern has several benefits: > > 1. Controlled access to parametrically defined instances. Since > the Parametric Singleton class encapsulates its instances, there is > control over how and when clients access it. Not really. Once you've returned the instance to a client, you've lost control over it. The client can to whatever it wants with it. You cannot "recall" the instance or claim it back. > 2. Reduced name space. The Parametric Singleton pattern avoids > global variables that store instances created from the same parameter. Sure, but you don't have to rely on a Singleton for that. Just create a single Factory. > I would very much like to get your feedback on this new design > pattern idea. Well, it's nothing new. Some may say that it is the point of design patterns: formalizes the designs that occur again and again. However, this design is simply a combination of the Singleton and Factory patterns. I did use it in the past, but now I've been exposed to the shortcomings of the Singleton pattern, so I limit myself to Factories. Regards, David From sean_montgomery at baseview.com Wed Mar 22 08:35:28 2006 From: sean_montgomery at baseview.com (Sean Montgomery) Date: Wed, 22 Mar 2006 10:35:28 -0500 Subject: [Rxtx] sole of a new design pattern In-Reply-To: <442160DA.80107@trusted-logic.com> References: <442160DA.80107@trusted-logic.com> Message-ID: <05769CA7-A51B-4CF0-BAA0-E02DD905F5A4@baseview.com> On Mar 22, 2006, at 9:36 AM, David Garnier wrote: > Furthermore, even for hardware services, the Singleton pattern does > not really prevent concurrent > accesses. If you start the same program in two different JVMs, > unless they somehow shared the state > of their "Singletons" (through lock files for example), the > Singleton pattern will not prevent > concurrent access. > Multiple class loaders in a single JVM can be tricky, too. Then there's synchronization, lazy initialization and serialization of singletons to contend with. Bloch's Effective Java covers these, and here's a few articles: http://www.javaworld.com/javaworld/jw-04-2003/jw-0425-designpatterns- p3.html http://java.sun.com/developer/technicalArticles/Programming/singletons/ Just FYI :-) From lyon at docjava.com Wed Mar 22 08:50:48 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Wed, 22 Mar 2006 10:50:48 -0500 Subject: [Rxtx] sole of a new design pattern In-Reply-To: <442160DA.80107@trusted-logic.com> References: <442160DA.80107@trusted-logic.com> Message-ID: Hi All, First, I would like to thank David for his prompt and thoughtful remarks. I had no idea people that feel strongly about a design patterns! Wow! Feedback (particularly critical feedback) is greatly appreciated. Starting at the end, first: >I did use it in >the past, but now I've been exposed to the shortcomings of the >Singleton pattern, so I limit myself to Factories. David, if I understood your comments correctly, you suggested that Factories can be used in leu of the Singleton Design Pattern, or even the Parametric Singleton Design Pattern. As I see in [Gof]: Factory Method: Intent "Define an interface for creating an object, but let subclasses decide which class to instantiate. Factory Method lets a class defer instantiation to subclasses." The Singleton Design Pattern is a concrete class, which is rather different, right? Also, subclasses are not permitted with Singleton, as they are final. Naturally, I could use an abstract factory as a parent for a singleton. I could even design a facade that could be implemented with the singleton....but that is not the intention of the design. Unless you want a mock-up, as discussed, below: More below: >Hello, > >> The Parametric Singleton Design Pattern > >The Singleton is the most abused design pattern ever. Good use-cases >for this pattern are extremely >rare and mostly confined to problems related to hardware resources, >like serial ports. > > >> Applicability >> >> Use the Parametric Singleton Design Pattern when: >> 1. There must be exactly one instance of a class with the given >> parameters. >OK. As I said above, this case this actually very unusual. The >Singleton pattern is mostly used when : >> 2. The instances must be accessible to clients from a well-known >> access point. > >Using the singleton pattern in this case is just convenient for the >programmer. Problems arises >pretty quickly, especially if you attempt to unit-test your classes. > >1) If your singleton is stateful, or hold on to stateful objects, it >means that two different unit >tests are not actually independent. Instead of starting with a brand >new environment, the result of >a test may be affected by the result of a previous test. This >problem also arise when with your >class relies on a database. In both cases, the solution is to reset >your "unique" resource >(Singleton or database) at the beginning of the test, which is a >pain. Also, while most projects >connect to a single database, projects that allow the use of >Singletons usually contain several of >thems, and new ones may cropped up unnoticed. You quickly end up >with test cases that only pass in a >certain order, which is a royal pain. There are basic problems with communicating finite state machines that include reachability and deadlock analysis. These are addressed with petri net analysis and are beyond the scope of the design pattern. As you quite rightly pointed out; the parametric singleton pattern (or the singleton pattern, for that matter) enable multiple threads to gain access to the same instance. The only way that I can see to block others from gaining access to the reference is the synchronize keyword. This is putting a spin-lock (or MUTEX) on the reference. The question of how to unit-test a design pattern like the parametric singleton remains open. Perhaps this is a deficiency. > >2) You cannot mockup a singleton. Once everyone calls the >SomeSingleton class statically, you can't >replace your class by SomeSingletonMockup. Acutally, I am not sure that this is true. If the Singleton implements a Facade interface, it should be possible to make the replacement. Right? > >Furthermore, even for hardware services, the Singleton pattern does >not really prevent concurrent >accesses. If you start the same program in two different JVMs, >unless they somehow shared the state >of their "Singletons" (through lock files for example), the >Singleton pattern will not prevent >concurrent access. Good Point!! You have sharp eyes! The singleton design pattern should/could take responsibility for this. In fact, you may notice that my code does have an implementation (LocateRegistry) that can work across JVM's. The LocateRegistry will even work across the Internet! LocateRegistry takes both a host name and a Port (lock files just don't do this). I did not think to implement this beyond the local machine, but, in its present form, it will work across different processes. > >Our application uses RXTX, and we routinely encounter cases where >another (native) application has >already locked the port. Since we cannot modify the native >application to recognize lock files, >OS-level control is irreplaceable. The singleton design pattern is not meant to replace OS-level control, but to centralize the Java programmers access to it. If lock files, for example, are used for serial ports, the Singleton Design Pattern should be able to work with them. > > >> >> Consequences >> The Parametric Singleton Design Pattern has several benefits: >> > > 1. Controlled access to parametrically defined instances. Since >> the Parametric Singleton class encapsulates its instances, there is >> control over how and when clients access it. > >Not really. Once you've returned the instance to a client, you've >lost control over it. The client >can to whatever it wants with it. You cannot "recall" the instance >or claim it back. Good point, this should read: > 1. Controll when parametrically defined instances are created. Since > > the Parametric Singleton class encapsulates its instances, there is > > control over how and when they are instanced. > >> 2. Reduced name space. The Parametric Singleton pattern avoids >> global variables that store instances created from the same parameter. > >Sure, but you don't have to rely on a Singleton for that. Just >create a single Factory. > > Thank you for your thoughtful and prompt response! Regards, - Doug From dmarkman at mac.com Wed Mar 22 21:21:55 2006 From: dmarkman at mac.com (Dmitry Markman) Date: Wed, 22 Mar 2006 23:21:55 -0500 Subject: [Rxtx] sole of a new design pattern In-Reply-To: <442160DA.80107@trusted-logic.com> References: <442160DA.80107@trusted-logic.com> Message-ID: I don't think I get it On Mar 22, 2006, at 9:36 AM, David Garnier wrote: > Using the singleton pattern in this case is just convenient for the > programmer. Problems arises > pretty quickly, especially if you attempt to unit-test your classes. so you're saying that something isn't so good because you can not test it in the convenient way? if that's true, I'm totally disagree change your test, debug whatever, but if software is efficient at runtime, works fine and only problem is some unit test (which is some kind of framework for testing) then dump that unit test , dump that unit framework and make something appropriate to the software you're testing so if Douglas want to use singletons, what's the problem? and what do you mean by abusing of singleton usage? of course singleton doesn't prevent concurrent access to the resource across the processes unless you're using some OS facility to prevent it, besides singleton as it was introduced is relevant only and only inside of the same process otherwise it's not singleton it's something else (let's say network singleton: so you have remote invocation facility and some factory method that return object created by that facility) I don't have any problem with using any kind of singletons. Parametric Singleton idea (if I understand it right) could be easily implemented in the following way: use a map populate map with instances of some class and key is your parameter (you can use lazy population too) if somebody ask the key check the value if it's null so resource is taken if somebody returns the resource put it back to the map public synchronized static Object getSomeResource(Object parameter); public synchronized static void returnResource(Object parameter); getSomeResource (inside of the same process) could return null in 2 cases 1. if somebody (from other thread for example) already took that resource 2. if OS API said that resource corresponded to that parameter (serial port with parameter = 1 (port #)) is locked and unavailable; I'm not sure that in case of serial ports we even need those Parametric Singletons (unless lock checking is a very expensive operation) just ask the OS about availability of that resource and if it's available give it away and then OS will lock it and therefore in next time somebody ask it just answer that resource is locked and return null for example system has 2 serial ports available so I ask getResource("tty"); or I ask getResource("Bluetooth-Modem"); and if OS is ok you can give tty or Bluetooth-Modem or both no need for any additional pattern I think back to the problem mac os x doesn't recognize locking via files, so it handles locking via some API an instance of the singleton in each process should recognize that resource is locked (by using that API) that's all we don't have to make things more complicate then they are just because there is some nice design pattern or nice unit test framework or whatever keep things simple, make them work fast, don't introduce middle layers unless you have really good reason to do so of course I could be entirely wrong, so sorry about that in advance thanks Dmitry Markman From tjarvi at qbang.org Wed Mar 22 22:31:41 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 22 Mar 2006 22:31:41 -0700 (MST) Subject: [Rxtx] sole of a new design pattern In-Reply-To: References: Message-ID: Hi Doug Interesting reading. So far I'm just reading and thinking. I have one question so far. " Clients obtain a reference to a Parametric Singleton instance only through the parametric singleton design pattern. If the instance is left in an improper state (e.g., the serial port was left open) it is NOT the role of the Parametric Singleton Design Pattern to close the IO port. Nor is it the role of the Parametric Singleton Design Pattern to open the port. That role is delegate to some other part of the system. " So when the clients obtain a reference to the singleton, can they assume the port is there? IE, would it be the singletons role to handle things like USB dongles being removed with event hints comming from the underlying OS. Hardware abstraction layer/HAL on Linux is an example of underlying OS events. I assume that role too is delegated to other parts of the system? -- Trent Jarvi tjarvi at qbang.org From lyon at docjava.com Thu Mar 23 08:10:33 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Thu, 23 Mar 2006 10:10:33 -0500 Subject: [Rxtx] Classes don't need goals, they need roles! In-Reply-To: References: Message-ID: Hi Trent, Yes, I think that the role of the Parametric Singleton Pattern is not to open or close serial ports, nor is it to perform error checking. On the other hand, if you were to combine the role of the Parametric Singleton Pattern with another role (like that of error checking) it might not be amiss. However, I generally caution programmers against adding multiple roles to classes, as this leads to monolithic designs. Thus a different class (NativeLibDetect) could have the role of determining if the native library can be loaded. Another class (SerialPortBean) can have the role of serializing the default state of the serial port, so that it can be recovered, from user preferences, at a later time. The SerialPortDetect could have the role of determining if the serial port is removed (i.e., a USB port was unplugged). My guess is that each class should have a different role in the system, in order to ease maintenance and testing...but I could be wrong about that. Thanks! - Doug >Hi Doug > >Interesting reading. So far I'm just reading and thinking. I have >one question so far. > >" > Clients obtain a reference to a Parametric Singleton instance only >through the parametric singleton design pattern. If the instance is >left in an improper state (e.g., the serial port was left open) it is >NOT the role of the Parametric Singleton Design Pattern to close the >IO port. Nor is it the role of the Parametric Singleton Design Pattern >to >open the port. That role is delegate to some other part of the system. >" > >So when the clients obtain a reference to the singleton, can they >assume the port is there? IE, would it be the singletons role to >handle things like USB dongles being removed with event hints >comming from the underlying OS. Hardware abstraction layer/HAL on >Linux is an example of underlying OS events. > >I assume that role too is delegated to other parts of the system? > >-- >Trent Jarvi >tjarvi at qbang.org >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From maximulo at yahoo.com Fri Mar 24 01:22:38 2006 From: maximulo at yahoo.com (Maximulo Majir) Date: Fri, 24 Mar 2006 00:22:38 -0800 (PST) Subject: [Rxtx] JavaPOS Message-ID: <20060324082238.66371.qmail@web38214.mail.mud.yahoo.com> Hi all! Hello Trent! From what i understand, RXTX or JavaComm APIs were not created solely for JavaPOS. In JavaPOS, we have the virtual method claim() which is separate from open(), but in our RXTX API, claiming is done every call to open(), we cant open the port if its claimed by another application. Would it be alright to suggest or ask to create a new method called claim(..)? Is there such thing as forceclaim() in RXTX? this could be the same as portownership transfer or its equivalent. ForceClaim is in JSR80. Do you have some samples using RXTX as the lower layer for the Device Service Objects in JavaPOS? I have tried it, i just want to compare. Thank you all! maxim __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060324/496adba2/attachment-0024.html From tjarvi at qbang.org Fri Mar 24 11:28:19 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 24 Mar 2006 11:28:19 -0700 (MST) Subject: [Rxtx] Re: RXTX 2.1 Solaris Problems In-Reply-To: <3691.1143210578@www045.gmx.net> References: <3691.1143210578@www045.gmx.net> Message-ID: On Fri, 24 Mar 2006, Andreas Guenther wrote: > Hi all, > > the solaris problem was not the lock file only. > > Ok, I had to create the directory /var/spool/locks myself. > /var/spool/uucp exists. > > But rxtx didn't find any port. > > I compiled the source with my own debug-informations > and I tried to isolate the problem. > > The problem is the testRead-call in SerialImp.c > > JNIEXPORT jboolean JNICALL RXTXCommDriver(testRead)( > > ... > if ( READ( fd, &c, 1 ) < 0 ) > { > if ( errno != EAGAIN ) { > report( "testRead() read failed\n" ); > ret = JNI_FALSE; > } > } > Thanks Andreas I'm packing up to move. I'll be more or less away for a couple weeks here. I'll be checking email but my workstation is going into a box soon. This isn't hard to fix as this port should be enumerated when EWOULDBLOCK is recieved. Thats error is OK for enumeration just as EAGAIN is. I've put the bug into bugzilla so we dont forget to get to it. http://bugzilla.qbang.org/show_bug.cgi?id=42 You can add yourself to the CC list if you wish to test fixes we provide or even put a patch into bugzilla yourself. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Fri Mar 24 11:51:52 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 24 Mar 2006 11:51:52 -0700 (MST) Subject: [Rxtx] JavaPOS In-Reply-To: <20060324082238.66371.qmail@web38214.mail.mud.yahoo.com> References: <20060324082238.66371.qmail@web38214.mail.mud.yahoo.com> Message-ID: On Fri, 24 Mar 2006, Maximulo Majir wrote: > Hi all! Hello Trent! > > > From what i understand, RXTX or JavaComm APIs were not > created solely for JavaPOS. In JavaPOS, we have the virtual method > claim() which is separate from open(), but in our RXTX API, claiming is > done every call to open(), we cant open the port if its claimed by > another application. Would it be alright to suggest or ask to create a > new method called claim(..)? Is there such thing as forceclaim() in > RXTX? this could be the same as portownership transfer or its > equivalent. ForceClaim is in JSR80. > Do you have some samples using RXTX as the lower layer for the Device > Service Objects in JavaPOS? I have tried it, i just want to compare. > maxim Hi Maxim JSR80 is the USB API IBM/Sun put together. The problem is they have a richer kernel/API underneath that can handle such things. With Serial Ports, there isnt anything there other than an ioctl that says don't let anyone touch this and lockfiles that are more of a 'lets be nice.' At times we may be using USB ports but it is through the termios layer with the limitations mentioned. The advantage is that not only USB will work with rxtx. Anything that has a termios layer should work (to the extent that termios layer is complete). I don't know how forceclaim() would help you. Lets say someone has a programmer working on /dev/ttyS0 and you take it. Now you both race each other to read data first. There isn't a mechanism I know of that will solve this problem in termios. The most obvious test being a native app and a Java app trying to take the port. There is the potential of requestion ownership from other Java Applications but the use for that is very rare. Did you have something more specific in mind that I'm missing? I'm not sure that claim() and forceclaim() would help you with rxtx other than maybe locking the port with claim() without opening it. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sat Mar 25 23:42:08 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 25 Mar 2006 23:42:08 -0700 (MST) Subject: [Rxtx] Serial snoop Message-ID: I was reading the Linux kernel mail-list tonight and ran past a thread that mentioned sersnoop. This looks like a handy tool for people dealing with new toys. "a simple command-line tool for linux that echoes bytes to and from any two serial ports, ptys, or network sockets, and prints all traffic to stdout, in hex and ascii." http://www.restivo.org/projects/sersnoop/ It works on Linux only at this time (debian package available). -- Trent Jarvi tjarvi at qbang.org From beat.arnet at gmail.com Sun Mar 26 07:32:35 2006 From: beat.arnet at gmail.com (Beat Arnet) Date: Sun, 26 Mar 2006 09:32:35 -0500 Subject: [Rxtx] Error 0x5 at /home/bob/foo/tar/rxtx-2.1-7/build/../src/termios.c(860): Access is, denied. Message-ID: <4426A603.80508@gmail.com> Dear all, When trying to open the serial port, I sometimes (not always) run into the following exception (when opening the serialPort): Error 0x5 at /home/bob/foo/tar/rxtx-2.1-7/build/../src/termios.c(860): Access is denied. java.lang.UnsatisfiedLinkError: native_psmisc_report_owner at gnu.io.CommPortIdentifier.native_psmisc_report_owner(Native Method) at gnu.io.CommPortIdentifier.open(CommPortIdentifier.java:354) at codeskin.tools.CLLoader.open(CLLoader.java:79) at codeskin.tools.C2000Programmer.run(C2000Programmer.java:220) at java.lang.Thread.run(Unknown Source) Is this the type of error where I should just try to open the port again, or can it be avoided? Regards, Beat From tjarvi at qbang.org Sun Mar 26 11:40:12 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 26 Mar 2006 11:40:12 -0700 (MST) Subject: [Rxtx] Error 0x5 at /home/bob/foo/tar/rxtx-2.1-7/build/../src/termios.c(860): Access is, denied. In-Reply-To: <4426A603.80508@gmail.com> References: <4426A603.80508@gmail.com> Message-ID: On Sun, 26 Mar 2006, Beat Arnet wrote: > Dear all, > > When trying to open the serial port, I sometimes (not always) run into > the following exception (when opening the serialPort): > > Error 0x5 at /home/bob/foo/tar/rxtx-2.1-7/build/../src/termios.c(860): > Access is > denied. > > java.lang.UnsatisfiedLinkError: native_psmisc_report_owner > at gnu.io.CommPortIdentifier.native_psmisc_report_owner(Native > Method) > at gnu.io.CommPortIdentifier.open(CommPortIdentifier.java:354) > at codeskin.tools.CLLoader.open(CLLoader.java:79) > at codeskin.tools.C2000Programmer.run(C2000Programmer.java:220) > at java.lang.Thread.run(Unknown Source) > > Is this the type of error where I should just try to open the port again, > or can it be avoided? > Hi Beat We did a second build of rxtx 2.1-7 to resolve that unsatisfied link error. It should work now. rxtx is trying to tell you it thinks someone else has the serial port open. You can try to open the port again but maybe you already have a copy of the program running when it happens? ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7r2.zip fixed build. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sun Mar 26 11:44:23 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 26 Mar 2006 11:44:23 -0700 (MST) Subject: [Rxtx] RXTX spec file (fwd) Message-ID: This is probably interesting for fedora/suse users. ---------- Forwarded message ---------- Date: Sun, 26 Mar 2006 16:25:45 +0200 To: taj at www.linux.org.uk Subject: RXTX spec file I send you this spec file which allows to create a RPM for Fedora 4, 5 (x86, x86_64) with Java Sun. -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: rxtx.spec Url: http://mailman.qbang.org/pipermail/rxtx/attachments/20060326/6c7b6af6/rxtx-0020.pl From tjarvi at qbang.org Sun Mar 26 23:42:59 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 26 Mar 2006 23:42:59 -0700 (MST) Subject: [Rxtx] Upcomming events. Message-ID: This Wednesday we will be announcing a new "Maintainer" for the rxtx project. The position is more like neutral leader. I wont be going away or doing less. This is just the right thing to do as it turns out the two people with CVS write access will be at the same company. We need a third and we need neutrality. The maintainer will have final say in any conflict and will try to be neutral. It will be open for discussion. Then we will do it :) I'll still do most of the footwork I do now. But. I'm falling behind. I should have gone through the mail-list and posted the next round of changes this weekend. I'm packing to move and its going so so - 13 years of toys collected. I suspect there will be a dead period on my part (a couple weeks) comming up. But if you get it on the mail-list, we will get it in if there are no objections. I may well not be reading the mail-list during this period as I look for a house and many other things. I hope everyone will help out. Thanks -- Trent Jarvi tjarvi at qbang.org From mahmoud_hadad at yahoo.com Sun Mar 26 07:31:19 2006 From: mahmoud_hadad at yahoo.com (ronan nick) Date: Sun, 26 Mar 2006 06:31:19 -0800 (PST) Subject: [Rxtx] a question about the COMM API Message-ID: <20060326143119.54919.qmail@web60014.mail.yahoo.com> hi, i was intrested in knowing how i can communicate with my internal modem using java? for example if i want to make a phone dialer application or a caller id application where should i be looking at? and as i understood the COMM API is for devices that is attached to the computer through serial ports. --------------------------------- New Yahoo! Messenger with Voice. Call regular phones from your PC and save big. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060326/ce8329f0/attachment-0022.html From dmarkman at mac.com Mon Mar 20 00:20:43 2006 From: dmarkman at mac.com (Dmitry Markman) Date: Mon, 20 Mar 2006 02:20:43 -0500 Subject: [Rxtx] Mac OS X RXTX java installer In-Reply-To: References: <07D0DE29-BA32-4CFE-B036-66BC6423D385@buechse.de> <441AE3E0.2030503@willicon.de> <12531986.1142622114996.JavaMail.dmarkman@mac.com> <441B2674.9010409@willicon.de> <13577405.1142634732776.JavaMail.dmarkman@mac.com> <441B4182.8010407@willicon.de> <92CD0D6C-5BE8-426E-A46D-99452059FF49@mac.com> <441BBB2D.8030305@willicon.de> <441C4088.5090905@willicon.de> Message-ID: <64BC1E23-FDDE-4CE6-8863-CFC881CBC224@mac.com> Hi all I put RXTX installer that will install everything (and will create / var/lock if necessary and add user to the uucp group) for mac os x from Java into the rxtx's CVS repository it could be easily modified to install files for any platform it uses Greg Guerin's AuthKit for authentication and authorization Greg released that kit under artistic license, so Trent, please take a look we, probably, can negotiate license with Greg if it's necessary Greg's AuthKit could be downloaded from http://www.amug.org/~glguerin/ sw/#authkit Michael Hall (mikehall at spacestar dot net) had a suggestion to make implementation of the jaas LoginModule based on Greg's AuthKit (his modification of the Greg's AuthKit could be found at http:// www.spacestar.net/users/mikehall/authkit.dmg) but Michael's AuthKitLoginModule does only half a job: it does authenticate but it can not run any external unix process in privileged mode (at least I wasn't able to do so) possible explanation could be found in conversation between Greg and Michael at Apple's java-dev list (look for archives) so I didn't use jaas API for rxtxinstaller I created folder MacOSX in the contrib folder comment 1. if you want to run that installer as standalone application all you need that RXTXInstaller.jar 2. if you want to use webstart you have to add Greg's libAuthKit.jnilib to the mac os x's resources in theory RXTXInstaller.jar doesn't need it, but there is a problem with loading libAuthKit.jnilib from webstart authkit uses loadLibrary method to load library and it failed (from webstart) for standalone application I extract libAuthKit.jnilib from the RXTXInstaller.jar and put it into the /Library/Java/Extensions or ~/Library/Java/Extensions folder that file will be deleted after installer quit unfortunately I didn't have time to put documentation there but it is mostly self-explanatory I took installer code from my gl4java installer that I did about 3 years ago (with small modifications) it would be very nice if Apple will release LoginModule that really will do the job (com.apple.security.auth.module package????? ) (UnixLoginModule is pretty useless) From lyon at docjava.com Mon Mar 20 06:34:39 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Mon, 20 Mar 2006 08:34:39 -0500 Subject: [Rxtx] Mac OS X RXTX java installer In-Reply-To: <64BC1E23-FDDE-4CE6-8863-CFC881CBC224@mac.com> References: <07D0DE29-BA32-4CFE-B036-66BC6423D385@buechse.de> <441AE3E0.2030503@willicon.de> <12531986.1142622114996.JavaMail.dmarkman@mac.com> <441B2674.9010409@willicon.de> <13577405.1142634732776.JavaMail.dmarkman@mac.com> <441B4182.8010407@willicon.de> <92CD0D6C-5BE8-426E-A46D-99452059FF49@mac.com> <441BBB2D.8030305@willicon.de> <441C4088.5090905@willicon.de> <64BC1E23-FDDE-4CE6-8863-CFC881CBC224@mac.com> Message-ID: Hi Dimitry, This sounds like great work. Just a couple of questions; After the check out of the CVS files, using: setenv CVSROOT :pserver:anonymous at cvs.milestonesolutions.com:/usr/local/cvsroot 53 8:28 setenv PASSWORD mousy 54 8:29 cvs login 55 8:29 cvs checkout rxtx-devel I cd'd over to: rxtx-devel/MACOSX_IDE And found: CVS/ CW/ ForPackageMaker/ PB/ Where is the installer? Thanks! - Doug From tjarvi at qbang.org Mon Mar 20 06:39:37 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 20 Mar 2006 06:39:37 -0700 (MST) Subject: [Rxtx] Mac OS X RXTX java installer In-Reply-To: References: <07D0DE29-BA32-4CFE-B036-66BC6423D385@buechse.de> <441AE3E0.2030503@willicon.de> <12531986.1142622114996.JavaMail.dmarkman@mac.com> <441B2674.9010409@willicon.de> <13577405.1142634732776.JavaMail.dmarkman@mac.com> <441B4182.8010407@willicon.de> <92CD0D6C-5BE8-426E-A46D-99452059FF49@mac.com> <441BBB2D.8030305@willicon.de> <441C4088.5090905@willicon.de> <64BC1E23-FDDE-4CE6-8863-CFC881CBC224@mac.com> Message-ID: On Mon, 20 Mar 2006, Dr. Douglas Lyon wrote: > Hi Dimitry, > This sounds like great work. Just a couple of questions; > After the check out of the CVS files, using: > setenv CVSROOT > :pserver:anonymous at cvs.milestonesolutions.com:/usr/local/cvsroot > 53 8:28 setenv PASSWORD mousy > 54 8:29 cvs login > 55 8:29 cvs checkout rxtx-devel Hi Doug You want "cvs checkout -r commapi-0-0-1 rxtx-devel" to get RXTX 2.1 The default branch is rxtx 2.0 which isn't very active right now. -- Trent Jarvi tjarvi at qbang.org From lyon at docjava.com Mon Mar 20 07:05:44 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Mon, 20 Mar 2006 09:05:44 -0500 Subject: [Rxtx] Mac OS X RXTX java installer In-Reply-To: References: <07D0DE29-BA32-4CFE-B036-66BC6423D385@buechse.de> <441AE3E0.2030503@willicon.de> <12531986.1142622114996.JavaMail.dmarkman@mac.com> <441B2674.9010409@willicon.de> <13577405.1142634732776.JavaMail.dmarkman@mac.com> <441B4182.8010407@willicon.de> <92CD0D6C-5BE8-426E-A46D-99452059FF49@mac.com> <441BBB2D.8030305@willicon.de> <441C4088.5090905@willicon.de> <64BC1E23-FDDE-4CE6-8863-CFC881CBC224@mac.com> Message-ID: Hi Trent, Thanks for the info on the CVS checkout procedure. I did that and am still not sure where the installer is. Here is what I have: cd MACOSX_IDE/ p4.docjava.com{lyon}121: ls CVS/ ForPackageMaker/ PB/ p4.docjava.com{lyon}122: find . | more . ./ForPackageMaker ./ForPackageMaker/RXTX.pkg.sit.hqx ./ForPackageMaker/Resources ./ForPackageMaker/Resources/ReadMe.rtf ./ForPackageMaker/Resources/Welcome.rtf ./ForPackageMaker/Resources/CVS ./ForPackageMaker/Resources/CVS/Entries ./ForPackageMaker/Resources/CVS/Repository ./ForPackageMaker/Resources/CVS/Tag ./ForPackageMaker/Resources/CVS/Root ./ForPackageMaker/Resources/preinstall ./ForPackageMaker/Resources/License.rtf ./ForPackageMaker/Resources/preupgrade ./ForPackageMaker/RXTX.pmsp ./ForPackageMaker/CVS ./ForPackageMaker/CVS/Entries ./ForPackageMaker/CVS/Repository ./ForPackageMaker/CVS/Entries.Log ./ForPackageMaker/CVS/Tag ./ForPackageMaker/CVS/Root ./ForPackageMaker/RXTX_Tiger.pkg.sitx.hqx ./ForPackageMaker/RXTX_Jag.pkg.sit.hqx ./ForPackageMaker/Install ./ForPackageMaker/Install/CVS ./ForPackageMaker/Install/CVS/Entries ./ForPackageMaker/Install/CVS/Repository ./ForPackageMaker/Install/CVS/Tag ./ForPackageMaker/Install/CVS/Root ./ForPackageMaker/Install/Library ./ForPackageMaker/Install/Library/CVS ./ForPackageMaker/Install/Library/CVS/Entries ./ForPackageMaker/Install/Library/CVS/Repository ./ForPackageMaker/Install/Library/CVS/Tag ./ForPackageMaker/Install/Library/CVS/Root ./ForPackageMaker/Install/Library/Java ./ForPackageMaker/Install/Library/Java/Extensions ./ForPackageMaker/Install/Library/Java/Extensions/RXTXcomm.jar ./ForPackageMaker/Install/Library/Java/Extensions/CVS ./ForPackageMaker/Install/Library/Java/Extensions/CVS/Entries ./ForPackageMaker/Install/Library/Java/Extensions/CVS/Repository ./ForPackageMaker/Install/Library/Java/Extensions/CVS/Tag ./ForPackageMaker/Install/Library/Java/Extensions/CVS/Root ./ForPackageMaker/Install/Library/Java/Extensions/librxtxSerial.jnilib ./ForPackageMaker/Install/Library/Java/CVS ./ForPackageMaker/Install/Library/Java/CVS/Entries ./ForPackageMaker/Install/Library/Java/CVS/Repository ./ForPackageMaker/Install/Library/Java/CVS/Entries.Log ./ForPackageMaker/Install/Library/Java/CVS/Tag ./ForPackageMaker/Install/Library/Java/CVS/Root ./ForPackageMaker/RXTX_Tiger.pmproj.sitx.hqx ./CVS ./CVS/Entries ./CVS/Repository ./CVS/Entries.Log ./CVS/Tag ./CVS/Root ./PB ./PB/LibSerialUniversal.xcodeproj.sitx.hqx ./PB/CVS ./PB/CVS/Entries ./PB/CVS/Repository ./PB/CVS/Entries.Log ./PB/CVS/Tag ./PB/CVS/Root ./PB/LibSerial.pbproj.sit.hqx ./PB/startpoint.c ./PB/config.h What is the procedure to run this installer? Do we need a README in: /rxtx-devel/MACOSX_IDE Here is what we have: CVS/ ForPackageMaker/ PB/ Thanks! - DL >On Mon, 20 Mar 2006, Dr. Douglas Lyon wrote: > >>Hi Dimitry, >>This sounds like great work. Just a couple of questions; >>After the check out of the CVS files, using: >>setenv CVSROOT >>:pserver:anonymous at cvs.milestonesolutions.com:/usr/local/cvsroot >> 53 8:28 setenv PASSWORD mousy >> 54 8:29 cvs login >> 55 8:29 cvs checkout rxtx-devel > >Hi Doug > >You want "cvs checkout -r commapi-0-0-1 rxtx-devel" to get RXTX 2.1 >The default branch is rxtx 2.0 which isn't very active right now. > >-- >Trent Jarvi >tjarvi at qbang.org From tjarvi at qbang.org Mon Mar 20 07:25:30 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 20 Mar 2006 07:25:30 -0700 (MST) Subject: [Rxtx] Mac OS X RXTX java installer In-Reply-To: References: <07D0DE29-BA32-4CFE-B036-66BC6423D385@buechse.de> <441AE3E0.2030503@willicon.de> <12531986.1142622114996.JavaMail.dmarkman@mac.com> <441B2674.9010409@willicon.de> <13577405.1142634732776.JavaMail.dmarkman@mac.com> <441B4182.8010407@willicon.de> <92CD0D6C-5BE8-426E-A46D-99452059FF49@mac.com> <441BBB2D.8030305@willicon.de> <441C4088.5090905@willicon.de> <64BC1E23-FDDE-4CE6-8863-CFC881CBC224@mac.com> Message-ID: On Mon, 20 Mar 2006, Dr. Douglas Lyon wrote: > Hi Trent, > Thanks for the info on the CVS checkout procedure. > I did that and am still not sure where the installer is. Hi Doug It does look like it was not cvs committed. There is no rxtx-devel/contrib/MacOSX directory in there at the moment. It was mentioned that it was put under contrib. -- Trent Jarvi tjarvi at qbang.org From dmarkman at mac.com Mon Mar 20 07:29:56 2006 From: dmarkman at mac.com (Dmitry Markman) Date: Mon, 20 Mar 2006 09:29:56 -0500 Subject: [Rxtx] Mac OS X RXTX java installer In-Reply-To: References: <07D0DE29-BA32-4CFE-B036-66BC6423D385@buechse.de> <441AE3E0.2030503@willicon.de> <12531986.1142622114996.JavaMail.dmarkman@mac.com> <441B2674.9010409@willicon.de> <13577405.1142634732776.JavaMail.dmarkman@mac.com> <441B4182.8010407@willicon.de> <92CD0D6C-5BE8-426E-A46D-99452059FF49@mac.com> <441BBB2D.8030305@willicon.de> <441C4088.5090905@willicon.de> <64BC1E23-FDDE-4CE6-8863-CFC881CBC224@mac.com> Message-ID: <6054EB4E-F7E0-4A9C-BDDA-D582D6D8826F@mac.com> you can find it in the rxtx-devel/contrib folder On Mar 20, 2006, at 9:05 AM, Dr. Douglas Lyon wrote: > Hi Trent, > Thanks for the info on the CVS checkout procedure. > I did that and am still not sure where the installer is. > Here is what I have: > cd MACOSX_IDE/ > p4.docjava.com{lyon}121: ls > CVS/ ForPackageMaker/ PB/ > p4.docjava.com{lyon}122: find . | more > . > ./ForPackageMaker > ./ForPackageMaker/RXTX.pkg.sit.hqx > ./ForPackageMaker/Resources > ./ForPackageMaker/Resources/ReadMe.rtf > ./ForPackageMaker/Resources/Welcome.rtf > ./ForPackageMaker/Resources/CVS > ./ForPackageMaker/Resources/CVS/Entries > ./ForPackageMaker/Resources/CVS/Repository > ./ForPackageMaker/Resources/CVS/Tag > ./ForPackageMaker/Resources/CVS/Root > ./ForPackageMaker/Resources/preinstall > ./ForPackageMaker/Resources/License.rtf > ./ForPackageMaker/Resources/preupgrade > ./ForPackageMaker/RXTX.pmsp > ./ForPackageMaker/CVS > ./ForPackageMaker/CVS/Entries > ./ForPackageMaker/CVS/Repository > ./ForPackageMaker/CVS/Entries.Log > ./ForPackageMaker/CVS/Tag > ./ForPackageMaker/CVS/Root > ./ForPackageMaker/RXTX_Tiger.pkg.sitx.hqx > ./ForPackageMaker/RXTX_Jag.pkg.sit.hqx > ./ForPackageMaker/Install > ./ForPackageMaker/Install/CVS > ./ForPackageMaker/Install/CVS/Entries > ./ForPackageMaker/Install/CVS/Repository > ./ForPackageMaker/Install/CVS/Tag > ./ForPackageMaker/Install/CVS/Root > ./ForPackageMaker/Install/Library > ./ForPackageMaker/Install/Library/CVS > ./ForPackageMaker/Install/Library/CVS/Entries > ./ForPackageMaker/Install/Library/CVS/Repository > ./ForPackageMaker/Install/Library/CVS/Tag > ./ForPackageMaker/Install/Library/CVS/Root > ./ForPackageMaker/Install/Library/Java > ./ForPackageMaker/Install/Library/Java/Extensions > ./ForPackageMaker/Install/Library/Java/Extensions/RXTXcomm.jar > ./ForPackageMaker/Install/Library/Java/Extensions/CVS > ./ForPackageMaker/Install/Library/Java/Extensions/CVS/Entries > ./ForPackageMaker/Install/Library/Java/Extensions/CVS/Repository > ./ForPackageMaker/Install/Library/Java/Extensions/CVS/Tag > ./ForPackageMaker/Install/Library/Java/Extensions/CVS/Root > ./ForPackageMaker/Install/Library/Java/Extensions/librxtxSerial.jnilib > ./ForPackageMaker/Install/Library/Java/CVS > ./ForPackageMaker/Install/Library/Java/CVS/Entries > ./ForPackageMaker/Install/Library/Java/CVS/Repository > ./ForPackageMaker/Install/Library/Java/CVS/Entries.Log > ./ForPackageMaker/Install/Library/Java/CVS/Tag > ./ForPackageMaker/Install/Library/Java/CVS/Root > ./ForPackageMaker/RXTX_Tiger.pmproj.sitx.hqx > ./CVS > ./CVS/Entries > ./CVS/Repository > ./CVS/Entries.Log > ./CVS/Tag > ./CVS/Root > ./PB > ./PB/LibSerialUniversal.xcodeproj.sitx.hqx > ./PB/CVS > ./PB/CVS/Entries > ./PB/CVS/Repository > ./PB/CVS/Entries.Log > ./PB/CVS/Tag > ./PB/CVS/Root > ./PB/LibSerial.pbproj.sit.hqx > ./PB/startpoint.c > ./PB/config.h > > What is the procedure to run this installer? > Do we need a README in: > /rxtx-devel/MACOSX_IDE > Here is what we have: > CVS/ ForPackageMaker/ PB/ > > > Thanks! > - DL > >> On Mon, 20 Mar 2006, Dr. Douglas Lyon wrote: >> >>> Hi Dimitry, >>> This sounds like great work. Just a couple of questions; >>> After the check out of the CVS files, using: >>> setenv CVSROOT :pserver:anonymous at cvs.milestonesolutions.com:/usr/ >>> local/cvsroot >>> 53 8:28 setenv PASSWORD mousy >>> 54 8:29 cvs login >>> 55 8:29 cvs checkout rxtx-devel >> >> Hi Doug >> >> You want "cvs checkout -r commapi-0-0-1 rxtx-devel" to get RXTX 2.1 >> The default branch is rxtx 2.0 which isn't very active right now. >> >> -- >> Trent Jarvi >> tjarvi at qbang.org > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx Dmitry Markman From mikehall at spacestar.net Mon Mar 20 05:25:25 2006 From: mikehall at spacestar.net (Michael Hall) Date: Mon, 20 Mar 2006 06:25:25 -0600 Subject: [Rxtx] Re: Mac OS X RXTX java installer In-Reply-To: <64BC1E23-FDDE-4CE6-8863-CFC881CBC224@mac.com> References: <07D0DE29-BA32-4CFE-B036-66BC6423D385@buechse.de> <441AE3E0.2030503@willicon.de> <12531986.1142622114996.JavaMail.dmarkman@mac.com> <441B2674.9010409@willicon.de> <13577405.1142634732776.JavaMail.dmarkman@mac.com> <441B4182.8010407@willicon.de> <92CD0D6C-5BE8-426E-A46D-99452059FF49@mac.com> <441BBB2D.8030305@willicon.de> <441C4088.5090905@willicon.de> <64BC1E23-FDDE-4CE6-8863-CFC881CBC224@mac.com> Message-ID: <247EB61F-5CD1-4132-89A2-FC105B6CF9A5@spacestar.net> On Mar 20, 2006, at 1:20 AM, Dmitry Markman wrote: > > Michael Hall (mikehall at spacestar dot net) had a suggestion to > make implementation of the jaas LoginModule > based on Greg's AuthKit > (his modification of the Greg's AuthKit could be found at http:// > www.spacestar.net/users/mikehall/authkit.dmg) > but Michael's AuthKitLoginModule does only half a job: > it does authenticate > but it can not run any external unix process in privileged mode (at > least I wasn't able to do so) If you got it working directly with Greg's the point is moot. But to clarify it anyhow. The login module does not allow you to do anything anything privileged on return as was explained by Greg. You need to work with a separate privileged process using the execPrivileged method of his API. I assume you did something similar although I haven't looked at how you are using it yet. I allowed instead for a action to be performed at the same time you login/authenticate,this... System.setProperty("authkit.action","/usr/bin/id"); just before this... lc.login(); To clarify, safely ignored as you are already complete. Mike Hall mikehall at spacestar dot net http://www.spacestar.net/users/mikehall http://sourceforge.net/projects/macnative -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2427 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20060320/f6e18202/smime-0025.bin From dmarkman at mac.com Mon Mar 20 07:36:47 2006 From: dmarkman at mac.com (Dmitry Markman) Date: Mon, 20 Mar 2006 09:36:47 -0500 Subject: [Rxtx] Re: Mac OS X RXTX java installer In-Reply-To: <247EB61F-5CD1-4132-89A2-FC105B6CF9A5@spacestar.net> References: <07D0DE29-BA32-4CFE-B036-66BC6423D385@buechse.de> <441AE3E0.2030503@willicon.de> <12531986.1142622114996.JavaMail.dmarkman@mac.com> <441B2674.9010409@willicon.de> <13577405.1142634732776.JavaMail.dmarkman@mac.com> <441B4182.8010407@willicon.de> <92CD0D6C-5BE8-426E-A46D-99452059FF49@mac.com> <441BBB2D.8030305@willicon.de> <441C4088.5090905@willicon.de> <64BC1E23-FDDE-4CE6-8863-CFC881CBC224@mac.com> <247EB61F-5CD1-4132-89A2-FC105B6CF9A5@spacestar.net> Message-ID: Hi, Michael all I have to do is to run some shell script I tried to use your action mechanism and it worked great so I just System.setProperty ("authkit.action","" ) and after that I even don't need to run anything like subject.doAs.... but after few thoughts I choose to use plain Greg's approach, because in that case I don't have to deal with various java's configurations files and therefore to use 2-3 -D parameters in the java command line especially it's useful for java web start (it's so fragile :-( ) thanks for the great job On Mar 20, 2006, at 7:25 AM, Michael Hall wrote: > > On Mar 20, 2006, at 1:20 AM, Dmitry Markman wrote: >> >> Michael Hall (mikehall at spacestar dot net) had a suggestion to >> make implementation of the jaas LoginModule >> based on Greg's AuthKit >> (his modification of the Greg's AuthKit could be found at http:// >> www.spacestar.net/users/mikehall/authkit.dmg) >> but Michael's AuthKitLoginModule does only half a job: >> it does authenticate >> but it can not run any external unix process in privileged mode >> (at least I wasn't able to do so) > > If you got it working directly with Greg's the point is moot. > > But to clarify it anyhow. > The login module does not allow you to do anything anything > privileged on return as was explained by Greg. You need to work > with a separate privileged process using the execPrivileged method > of his API. I assume you did something similar although I haven't > looked at how you are using it yet. > I allowed instead for a action to be performed at the same time you > login/authenticate,this... > System.setProperty("authkit.action","/usr/bin/id"); > just before this... > lc.login(); > To clarify, safely ignored as you are already complete. > > Mike Hall mikehall at spacestar dot net > http://www.spacestar.net/users/mikehall > http://sourceforge.net/projects/macnative > > > Dmitry Markman From dmarkman at mac.com Mon Mar 20 07:44:45 2006 From: dmarkman at mac.com (Dmitry Markman) Date: Mon, 20 Mar 2006 09:44:45 -0500 Subject: [Rxtx] Mac OS X RXTX java installer In-Reply-To: References: <07D0DE29-BA32-4CFE-B036-66BC6423D385@buechse.de> <441AE3E0.2030503@willicon.de> <12531986.1142622114996.JavaMail.dmarkman@mac.com> <441B2674.9010409@willicon.de> <13577405.1142634732776.JavaMail.dmarkman@mac.com> <441B4182.8010407@willicon.de> <92CD0D6C-5BE8-426E-A46D-99452059FF49@mac.com> <441BBB2D.8030305@willicon.de> <441C4088.5090905@willicon.de> <64BC1E23-FDDE-4CE6-8863-CFC881CBC224@mac.com> Message-ID: it's in the commapi-0-0-1 branch I tested it right now: cvs co -r commapi-0-0-1 rxtx-devel and I got everything On Mar 20, 2006, at 9:25 AM, Trent Jarvi wrote: > On Mon, 20 Mar 2006, Dr. Douglas Lyon wrote: > >> Hi Trent, >> Thanks for the info on the CVS checkout procedure. >> I did that and am still not sure where the installer is. > > Hi Doug > > It does look like it was not cvs committed. There is no rxtx-devel/ > contrib/MacOSX directory in there at the moment. It was mentioned > that it was put under contrib. > > -- > Trent Jarvi > tjarvi at qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx Dmitry Markman From tjarvi at qbang.org Mon Mar 20 07:52:57 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 20 Mar 2006 07:52:57 -0700 (MST) Subject: [Rxtx] Mac OS X RXTX java installer In-Reply-To: References: <07D0DE29-BA32-4CFE-B036-66BC6423D385@buechse.de> <441AE3E0.2030503@willicon.de> <12531986.1142622114996.JavaMail.dmarkman@mac.com> <441B2674.9010409@willicon.de> <13577405.1142634732776.JavaMail.dmarkman@mac.com> <441B4182.8010407@willicon.de> <92CD0D6C-5BE8-426E-A46D-99452059FF49@mac.com> <441BBB2D.8030305@willicon.de> <441C4088.5090905@willicon.de> <64BC1E23-FDDE-4CE6-8863-CFC881CBC224@mac.com> Message-ID: On Mon, 20 Mar 2006, Dmitry Markman wrote: > it's in the commapi-0-0-1 branch > > I tested it right now: > cvs co -r commapi-0-0-1 rxtx-devel > > and I got everything > A fresh checkout worked. Here is a copy of the tree (just the installer bits) ftp://ftp.qbang.org/pub/rxtx/MacOSX-installer.zip -- Trent Jarvi tjarvi at qbang.org From lyon at docjava.com Mon Mar 20 08:08:26 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Mon, 20 Mar 2006 10:08:26 -0500 Subject: [Rxtx] Mac OS X RXTX java installer In-Reply-To: References: <07D0DE29-BA32-4CFE-B036-66BC6423D385@buechse.de> <441AE3E0.2030503@willicon.de> <12531986.1142622114996.JavaMail.dmarkman@mac.com> <441B2674.9010409@willicon.de> <13577405.1142634732776.JavaMail.dmarkman@mac.com> <441B4182.8010407@willicon.de> <92CD0D6C-5BE8-426E-A46D-99452059FF49@mac.com> <441BBB2D.8030305@willicon.de> <441C4088.5090905@willicon.de> <64BC1E23-FDDE-4CE6-8863-CFC881CBC224@mac.com> Message-ID: Hi All, Is the Auth package able to work properly on non Mac OS's? It was not clear from the doc or download. Thanks! - Doug From dmarkman at mac.com Mon Mar 20 08:15:22 2006 From: dmarkman at mac.com (Dmitry Markman) Date: Mon, 20 Mar 2006 10:15:22 -0500 Subject: [Rxtx] Mac OS X RXTX java installer In-Reply-To: References: <07D0DE29-BA32-4CFE-B036-66BC6423D385@buechse.de> <441AE3E0.2030503@willicon.de> <12531986.1142622114996.JavaMail.dmarkman@mac.com> <441B2674.9010409@willicon.de> <13577405.1142634732776.JavaMail.dmarkman@mac.com> <441B4182.8010407@willicon.de> <92CD0D6C-5BE8-426E-A46D-99452059FF49@mac.com> <441BBB2D.8030305@willicon.de> <441C4088.5090905@willicon.de> <64BC1E23-FDDE-4CE6-8863-CFC881CBC224@mac.com> Message-ID: <217312D8-CCCA-4859-ABA6-32DF1CC817B9@mac.com> thanks Trent, for putting it on ftp server On Mar 20, 2006, at 9:52 AM, Trent Jarvi wrote: > A fresh checkout worked. Here is a copy of the tree (just the > installer bits) > > ftp://ftp.qbang.org/pub/rxtx/MacOSX-installer.zip > Dmitry Markman From dmarkman at mac.com Mon Mar 20 09:14:03 2006 From: dmarkman at mac.com (Dmitry Markman) Date: Mon, 20 Mar 2006 11:14:03 -0500 Subject: [Rxtx] Mac OS X RXTX java installer In-Reply-To: References: <07D0DE29-BA32-4CFE-B036-66BC6423D385@buechse.de> <441AE3E0.2030503@willicon.de> <12531986.1142622114996.JavaMail.dmarkman@mac.com> <441B2674.9010409@willicon.de> <13577405.1142634732776.JavaMail.dmarkman@mac.com> <441B4182.8010407@willicon.de> <92CD0D6C-5BE8-426E-A46D-99452059FF49@mac.com> <441BBB2D.8030305@willicon.de> <441C4088.5090905@willicon.de> <64BC1E23-FDDE-4CE6-8863-CFC881CBC224@mac.com> Message-ID: <4DEBA6F0-DA45-4E84-823E-1F1AC48BDCCC@mac.com> no it will work only on mac os x however it's harmless to run it on other platform if you want to use it for other platform you have to do the following (I'll do it for linux) 1. modify RXTXInstaller class method public static RXTXInstaller getInstance() public static RXTXInstaller getInstance() { String osName = System.getProperty("os.name").toLowerCase(); if(osName.startsWith("mac")){ return new gnu.io.installer.macosx.MACOSXRXTXInstaller(); } else if(osName.startsWith("windows")){ return new gnu.io.installer.windows.WindowsRXTXInstaller(); }else if(osName.startsWith("linux")){ return new gnu.io.installer.linux.LinuxRXTXInstaller(); } return null; } 2. create folder gnu/io/installer/linux/ 3. create class Linux386RXTXInstaller package gnu.io.installer.linux; import java.io.File; public class Linux386RXTXInstaller extends gnu.io.installer.RXTXInstaller{ public Linux386RXTXInstaller(){ createJarFolder(); createLibFolder(); addJarResource("RXTXcomm.jar","/gnu/io/installer/resources/ linux/jar/RXTXcomm.dat"); addLibResource("librxtxSerial.so","/gnu/io/installer/ resources/linux/lib/librxtxSerial.so"); } protected void createJarFolder(){ String javaHome = System.getProperty("java.home"); char separator = File.separatorChar; jarFolder = new File(javaHome+separator+"lib"+separator+"ext"); } protected void createLibFolder(){ String javaHome = System.getProperty("java.home"); char separator = File.separatorChar; libFolder = new File(javaHome+separator+"bin"); } public void runPreProcess() {} //put here some action you need public void runPostProcess() {} //put here some action you need } 4. create folder /gnu/io/installer/resources/linux/jar and put there linux's version of RXTXcomm.dat (which is renamed RXTXcomm.jar) 5. create folder /gnu/io/installer/resources/linux/lib and put there linux's version of librxtxSerial. so 6. make sure that RXTXInstaller.jar has the following items: /gnu/io/installer/resources/linux/jar/RXTXcomm.jar /gnu/io/installer/resources/linux/lib/librxtxSerial.so 7. modify file installer.pref: jar file RXTXInstaller.jar must have the following item /gnu/io/installer/installer.pref that's basically it for windows you have to do the similar things: just replace linux to windows and librxtxSerial.so to rxtxSerial.dll and create appropriate gnu.io.installer.windows.WindowsRXTXInstaller class package gnu.io.installer.windows; import java.io.File; public class WindowsRXTXInstaller extends gnu.io.installer.RXTXInstaller{ public WindowsRXTXInstaller(){ createJarFolder(); createLibFolder(); addJarResource("RXTXcomm.jar","/gnu/io/installer/resources/ windows/jar/RXTXcomm.dat"); addLibResource("librxtxSerial.so","/gnu/io/installer/ resources/windows/lib/rxtxSerial.dll"); } protected void createJarFolder(){ String javaHome = System.getProperty("java.home"); char separator = File.separatorChar; jarFolder = new File(javaHome+separator+"lib"+separator+"ext"); } protected void createLibFolder(){ String javaHome = System.getProperty("java.home"); char separator = File.separatorChar; libFolder = new File(javaHome+separator+"bin"); } public void runPreProcess() {} //put here some action you need public void runPostProcess() {} //put here some action you need } installer.pref will look like On Mar 20, 2006, at 10:08 AM, Dr. Douglas Lyon wrote: > Hi All, > Is the Auth package able to work properly on > non Mac OS's? > It was not clear from the doc or download. > > Thanks! > - Doug > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx Dmitry Markman From joachim at buechse.de Mon Mar 20 10:49:06 2006 From: joachim at buechse.de (Joachim Buechse) Date: Mon, 20 Mar 2006 18:49:06 +0100 Subject: [Rxtx] BUG: Lock file stays even if port opening fails Message-ID: This was only tested on MacOSX but looking at the code, it should be true for all systems that use lock_uucp. I am opening a port which can not be opened (dialup port of a telephone paired via bluetooth but currently not reachable). The lock file is created and stays arround, even though the port open failed. After looking a bit through the code (of 2.17), I really wonder if it wouldn't be a good idea to make the "locking" an explicit operation called from the java code. This would certainly simplify the generation of meaningfull exceptions (and java based debugging). Maybe even the handling of "preopened" ports should be in the Java part of the lib (again for java based debugging puposes). That beeing said, I have no idea if this would be possible for the 2.07 implementation. Regards, Joachim From tjarvi at qbang.org Mon Mar 20 11:24:22 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 20 Mar 2006 11:24:22 -0700 (MST) Subject: [Rxtx] BUG: Lock file stays even if port opening fails In-Reply-To: References: Message-ID: On Mon, 20 Mar 2006, Joachim Buechse wrote: > This was only tested on MacOSX but looking at the code, it should be true > for all systems that use lock_uucp. > > I am opening a port which can not be opened (dialup port of a telephone > paired via bluetooth but currently not reachable). The lock file is > created and stays arround, even though the port open failed. > > > After looking a bit through the code (of 2.17), I really wonder if it > wouldn't be a good idea to make the "locking" an explicit operation > called from the java code. This would certainly simplify the generation > of meaningfull exceptions (and java based debugging). > Maybe even the handling of "preopened" ports should be in the Java part > of the lib (again for java based debugging puposes). That beeing said, I > have no idea if this would be possible for the 2.07 implementation. > > Regards, Hi Joachim It should be possible in the 2.0-7 implementation too. The calls to RXTXPort.java would not change. We would just do more there Moving more of that logic into Java would be better as many people don't like to look at C code. There is a liblockdev on most Linux distros that can do most of the C code and would be easier to use. The problem is embeded devices will not have that library. The preopened port code has not been really tested. That was a last minute request in a product cycle. I expect it will be tested this year though. As I recall, some devices really do not like CD raising on open. The preopened ports then allow people to mess around in java without power cycling the devices or losing data. -- Trent Jarvi tjarvi at qbang.org From joachim at buechse.de Mon Mar 20 12:01:08 2006 From: joachim at buechse.de (Joachim Buechse) Date: Mon, 20 Mar 2006 20:01:08 +0100 Subject: [Rxtx] BUG: Lock file stays even if port opening fails In-Reply-To: References: Message-ID: Hi Trent, What is your general feeling about moving code to Java? The last days I have been reading quite a bit of the code and there are several things, that might not work as expected. I'll give you two examples from is_device_locked: if LOCKDIR == /var/spool/locks the directory /var/spool/lock will not be checked. LOCKDIR is not checked for lockfiles with unexpected pefixes While these things have probably never been discovered in production, they are still possibly incorrect implementations. If it was Java code, I would write some unit tests producing the errors that could later be corrected. PS: One could imagine to actually implement the whole lockfile handling in Java using some native routines to get the values required (pid, st_dev, st_rdev, ...). On 20.03.2006, at 19:24, Trent Jarvi wrote: > On Mon, 20 Mar 2006, Joachim Buechse wrote: > >> This was only tested on MacOSX but looking at the code, it should >> be true for all systems that use lock_uucp. >> >> I am opening a port which can not be opened (dialup port of a >> telephone paired via bluetooth but currently not reachable). The >> lock file is created and stays arround, even though the port open >> failed. >> >> >> After looking a bit through the code (of 2.17), I really wonder if >> it wouldn't be a good idea to make the "locking" an explicit >> operation called from the java code. This would certainly simplify >> the generation of meaningfull exceptions (and java based debugging). >> Maybe even the handling of "preopened" ports should be in the Java >> part of the lib (again for java based debugging puposes). That >> beeing said, I have no idea if this would be possible for the 2.07 >> implementation. >> >> Regards, > > Hi Joachim > > It should be possible in the 2.0-7 implementation too. The calls > to RXTXPort.java would not change. We would just do more there > Moving more of that logic into Java would be better as many people > don't like to look at C code. There is a liblockdev on most Linux > distros that can do most of the C code and would be easier to use. > The problem is embeded devices will not have that library. > > The preopened port code has not been really tested. That was a > last minute request in a product cycle. I expect it will be tested > this year though. As I recall, some devices really do not like CD > raising on open. The preopened ports then allow people to mess > around in java without power cycling the devices or losing data. > > -- > Trent Jarvi > tjarvi at qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Mon Mar 20 12:21:02 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 20 Mar 2006 12:21:02 -0700 (MST) Subject: [Rxtx] BUG: Lock file stays even if port opening fails In-Reply-To: References: Message-ID: On Mon, 20 Mar 2006, Joachim Buechse wrote: > Hi Trent, > > What is your general feeling about moving code to Java? The last days I > have been reading quite a bit of the code and there are several things, > that might not work as expected. > > I'll give you two examples from is_device_locked: > > if LOCKDIR == /var/spool/locks the directory /var/spool/lock will not be > checked. > LOCKDIR is not checked for lockfiles with unexpected pefixes > > While these things have probably never been discovered in production, > they are still possibly incorrect implementations. If it was Java code, I > would write some unit tests producing the errors that could later be > corrected. > > PS: One could imagine to actually implement the whole lockfile handling > in Java using some native routines to get the values required (pid, > st_dev, st_rdev, ...). Hi Joachim I like the idea of moving more of the code into java but there are some things to consider. If you break this into multiple JNI calls, the performance will drop considerably during enumeration of ports. We are looking for 256 ports per dev type vs (16? in Sun's 2.0 and fewer types). Its hard to make assumptions. I've seen virtual ports start at /dev/foo100 for instance. It works out to over 7500 ports on Linux if you enable them all. We already trim that back by default. See Linux-all-ports in RXTXCommDriver.java. There are also native libraries that rxtx can link to. If you move too much into Java, linking to 'standard' libraries with distros will break. "configure --enable-liblock=yes" will not be doable. This is probably a favorable way with RedHat, Debian, Suse and others. Thats the right thing to do if there will be rpms, dpkg, .. For those reasons, I think it still make sense to keep it to a minimal ~3 calls to JNI code that we can use for speed and versatility. lock() isLocked(), unlock() perhaps. When I say speed, its more about avoiding crossing the JNI layer multiple times than java vs C performance. With versatility I think liblock is the right way for most but not all (embeded) linux distros. -- Trent Jarvi tjarvi at qbang.org From joachim at buechse.de Mon Mar 20 12:42:04 2006 From: joachim at buechse.de (Joachim Buechse) Date: Mon, 20 Mar 2006 20:42:04 +0100 Subject: [Rxtx] BUG: Lock file stays even if port opening fails In-Reply-To: References: Message-ID: <82C19FE7-DDCB-45B6-B2C9-7606B66F0124@buechse.de> Ok, what about providing a default implementation in Java? The RXTXCommDriver would call a (native) function useNativeLocking and if it returns true, call the native functions for lock() isLocked (), unlock(), else is would use the Java based default implementation. This could possibly be overriden by a property (again for debugging). Joachim On 20.03.2006, at 20:21, Trent Jarvi wrote: > On Mon, 20 Mar 2006, Joachim Buechse wrote: > >> Hi Trent, >> >> What is your general feeling about moving code to Java? The last >> days I have been reading quite a bit of the code and there are >> several things, that might not work as expected. >> >> I'll give you two examples from is_device_locked: >> >> if LOCKDIR == /var/spool/locks the directory /var/spool/lock will >> not be checked. >> LOCKDIR is not checked for lockfiles with unexpected pefixes >> >> While these things have probably never been discovered in >> production, they are still possibly incorrect implementations. If >> it was Java code, I would write some unit tests producing the >> errors that could later be corrected. >> >> PS: One could imagine to actually implement the whole lockfile >> handling in Java using some native routines to get the values >> required (pid, st_dev, st_rdev, ...). > > Hi Joachim > > I like the idea of moving more of the code into java but there are > some things to consider. > > If you break this into multiple JNI calls, the performance will > drop considerably during enumeration of ports. We are looking for > 256 ports per dev type vs (16? in Sun's 2.0 and fewer types). Its > hard to make assumptions. I've seen virtual ports start at /dev/ > foo100 for instance. > > It works out to over 7500 ports on Linux if you enable them all. > We already trim that back by default. See Linux-all-ports in > RXTXCommDriver.java. > > There are also native libraries that rxtx can link to. If you move > too much into Java, linking to 'standard' libraries with distros > will break. "configure --enable-liblock=yes" will not be doable. > This is probably a favorable way with RedHat, Debian, Suse and > others. Thats the right thing to do if there will be rpms, dpkg, .. > > For those reasons, I think it still make sense to keep it to a > minimal ~3 calls to JNI code that we can use for speed and > versatility. lock() isLocked(), unlock() perhaps. When I say > speed, its more about avoiding crossing the JNI layer multiple > times than java vs C performance. With versatility I think liblock > is the right way for most but not all (embeded) linux distros. > > -- > Trent Jarvi > tjarvi at qbang.org > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Mon Mar 20 12:44:47 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 20 Mar 2006 12:44:47 -0700 (MST) Subject: [Rxtx] BUG: Lock file stays even if port opening fails In-Reply-To: <82C19FE7-DDCB-45B6-B2C9-7606B66F0124@buechse.de> References: <82C19FE7-DDCB-45B6-B2C9-7606B66F0124@buechse.de> Message-ID: On Mon, 20 Mar 2006, Joachim Buechse wrote: > Ok, what about providing a default implementation in Java? > > The RXTXCommDriver would call a (native) function useNativeLocking and if > it returns true, call the native functions for lock() isLocked(), > unlock(), else is would use the Java based default implementation. This > could possibly be overriden by a property (again for debugging). > Hi Joachim That would be OK with me. -- Trent Jarvi tjarvi at qbang.org From dmarkman at mac.com Mon Mar 20 22:27:45 2006 From: dmarkman at mac.com (Dmitry Markman) Date: Tue, 21 Mar 2006 00:27:45 -0500 Subject: [Rxtx] binaries request Message-ID: <42702213-C222-4937-A585-7CFB17E47608@mac.com> Hi can somebody send me latest linux and windows binaries, please? or where I can find them (I didn't find them in the latest tareball) I gave up with my cygwin: something wrong I have no idea what java doesn't understand /cygwin/c syntax after I changed makefile it did java part but after that gcc 3.4.4 started to complain I set buffer length to 999 lines but I didn't get beginning of the story something wrong with my 1.4.2_09/include/jni.h gcc doesn't like it anyway I gave up thanks in advance Dmitry Markman -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060320/f8cbc57c/attachment-0025.html From tjarvi at qbang.org Mon Mar 20 22:36:48 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 20 Mar 2006 22:36:48 -0700 (MST) Subject: [Rxtx] binaries request In-Reply-To: <42702213-C222-4937-A585-7CFB17E47608@mac.com> References: <42702213-C222-4937-A585-7CFB17E47608@mac.com> Message-ID: On Tue, 21 Mar 2006, Dmitry Markman wrote: > Hi > can somebody send me latest linux and windows binaries, please? > > or where I can find them (I didn't find them in the latest tareball) > > I gave up with my cygwin: something wrong I have no idea what > java doesn't understand /cygwin/c syntax > after I changed makefile it did java part > but after that gcc 3.4.4 started to complain > I set buffer length to 999 lines but I didn't get beginning of the story > something wrong with my 1.4.2_09/include/jni.h gcc doesn't like it > anyway I gave up > > thanks in advance > Hi Dmitry The bins are here: ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7-bins-r2.zip Here are the files in the zip you want. Jar: rxtx-2.1-7-bins-r2/RXTXcomm.jar Windows: rxtx-2.1-7-bins-r2/Windows/i368-mingw32/rxtxSerial.dll Linux (x86) rxtx-2.1-7-bins-r2/Linux/i686-unknown-linux-gnu/librxtxSerial.so There are others in there including Parallel port support but those are the main ones for testing. -- Trent Jarvi tjarvi at qbang.org From dmarkman at mac.com Mon Mar 20 23:05:59 2006 From: dmarkman at mac.com (Dmitry Markman) Date: Tue, 21 Mar 2006 01:05:59 -0500 Subject: [Rxtx] binaries request In-Reply-To: References: <42702213-C222-4937-A585-7CFB17E47608@mac.com> Message-ID: thank you very much but windows's readme says: rxtxSerial.dll had to be recomopiled to link in missing native methods. should I ignore it? or what? thanks again also I understand that I should use mingw not cygwin I'll try to install mingw On Mar 21, 2006, at 12:36 AM, Trent Jarvi wrote: > On Tue, 21 Mar 2006, Dmitry Markman wrote: > >> Hi >> can somebody send me latest linux and windows binaries, please? >> >> or where I can find them (I didn't find them in the latest tareball) >> >> I gave up with my cygwin: something wrong I have no idea what >> java doesn't understand /cygwin/c syntax >> after I changed makefile it did java part >> but after that gcc 3.4.4 started to complain >> I set buffer length to 999 lines but I didn't get beginning of the >> story >> something wrong with my 1.4.2_09/include/jni.h gcc doesn't like it >> anyway I gave up >> >> thanks in advance >> > > Hi Dmitry > > The bins are here: > > ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7-bins-r2.zip > > Here are the files in the zip you want. > > Jar: > > rxtx-2.1-7-bins-r2/RXTXcomm.jar > > Windows: > > rxtx-2.1-7-bins-r2/Windows/i368-mingw32/rxtxSerial.dll > > Linux (x86) > > rxtx-2.1-7-bins-r2/Linux/i686-unknown-linux-gnu/librxtxSerial.so > > There are others in there including Parallel port support but those > are the main ones for testing. > > -- > Trent Jarvi > tjarvi at qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx Dmitry Markman From tjarvi at qbang.org Mon Mar 20 23:20:33 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 20 Mar 2006 23:20:33 -0700 (MST) Subject: [Rxtx] binaries request In-Reply-To: References: <42702213-C222-4937-A585-7CFB17E47608@mac.com> Message-ID: On Tue, 21 Mar 2006, Dmitry Markman wrote: > thank you very much > > but windows's readme says: > rxtxSerial.dll had to be recomopiled to link in missing native methods. > > should I ignore it? or what? > Hi Dmitry That dll should be OK. r2 is the recompile linked to the missing native method. The readme explains why it was recompiled; fuser.o was not linked into the dll in the first release. -- Trent Jarvi tjarvi at qbang.org From ariantristan at yahoo.com Mon Mar 20 23:55:24 2006 From: ariantristan at yahoo.com (Lambok Sianturi) Date: Mon, 20 Mar 2006 22:55:24 -0800 (PST) Subject: [Rxtx] jvm issue Message-ID: <20060321065524.94779.qmail@web50701.mail.yahoo.com> Hi All, This is my first time to join RxTx mailing list. I thank you all for allowing others to sign in in requests help. I use the latest RxTx lib in Fedora 3 with java version 1.4.2_09 b05. And I got this error: # # An unexpected error has been detected by HotSpot Virtual Machine: # # SIGSEGV (0xb) at pc=0x00bf27f3, pid=2633, tid=3086112448 # # Java VM: Java HotSpot(TM) Client VM (1.4.2_09-b05 mixed mode) # Problematic frame: # C [ld-linux.so.2+0xa7f3] # # An error report file with more information is saved as hs_err_pid2633.log # # If you would like to submit a bug report, please visit: # http://java.sun.com/webapps/bugreport/crash.jsp # ./run.sh: line 3: 2633 Aborted /usr/local/java/bin/java -Djava.library.path=/usr/local/java/jre/lib/ -Djsmsengine.debug=true -classpath jsmsengine.jar:smsgateway.jar:classes12.jar:RXTXcomm.jar:. com.api.sms.SMSServer What is the jvm depedency for the latest library? Can I use 1.4.2_09 b05? Thanks in advance. Arian --------------------------------- Yahoo! Mail Use Photomail to share photos without annoying attachments. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060320/83d58dd7/attachment-0025.html From f.frumento at ngi.it Tue Mar 21 00:21:47 2006 From: f.frumento at ngi.it (Fabio Frumento) Date: Tue, 21 Mar 2006 08:21:47 +0100 Subject: [Rxtx] Javadoc on the go Message-ID: <441FA98B.9050701@ngi.it> Hi Trent, sorry for the big delay but my job is running wild, i was out for some time but now i'm back and ready to continue the javadoc for Rxtx. Did you used the last javadoc patch i sent you ? let me know if i have to send it to you again or not. regards Fabio From lyon at docjava.com Tue Mar 21 00:51:18 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Tue, 21 Mar 2006 02:51:18 -0500 Subject: [Rxtx] lock files Message-ID: Hi All, You know, if the use of lock files were under Java control (rather than a build-time decision), it might enable a more unified binary distro. It might also facilitate quick prototyping of non-lock file approaches to resolving serial port contention issues (i.e., mac-like approaches vs. linux approaches, etc.). I realize that this is a radical overhaul of the lock file policy issue. Also, it may harm performance. On the other hand, our benchmarks on JNI overhead for modern processors indicate performance impact should be minimal. Perhaps it is more of an issue with the toybox systems. Suppose there were a class with a reasonable default...someone might write: SerialPortLockPolicy.setPolicy(SerialPortLockPolicy.UNIX_LOCK_FILE); SerialPortLockPolicy.setPolicy(SerialPortLockPolicy.NO_LOCK_CHECKING); SerialPortLockPolicy.setPolicy(SerialPortLockPolicy.MAC_STYLE); Thus, we could have a run-time reconfiguration of the serial port lock policy. A special NO_LOCK version of the binary would no longer be required. Any thoughts on this? Thanks! - Doug From joachim at buechse.de Tue Mar 21 03:09:09 2006 From: joachim at buechse.de (Joachim Buechse) Date: Tue, 21 Mar 2006 11:09:09 +0100 Subject: [Rxtx] lock files In-Reply-To: References: Message-ID: <8E12916A-1B9A-4FF2-B684-E2D1C794221B@buechse.de> This is pretty much what I thought about when I suggested, that the default behaviour could be overwritten with a property. I am very much in favor of this approach. In particular this allows much easier debugging for PC based java developers. I think big parts of the Java (and maybe some parts of the C code) could use a bit of a structural workover (unit tests, javadoc, synchronization, etc). Maybe there should be a CVS branch for this experimental version. I'd be happy to contribute a first workover for some of the Java code. Designing for testability and implementing a good bunch of unit tests has been a strategy that worked quite well in the Java projects I lead. And it ultimately allows more liberal change permission. Regards, Joachim On 21.03.2006, at 08:51, Dr. Douglas Lyon wrote: > Hi All, > You know, if the use of lock files were > under Java control (rather than a build-time decision), > it might enable a more unified binary distro. It might also > facilitate quick prototyping of non-lock file approaches > to resolving serial port contention issues (i.e., mac-like > approaches vs. linux approaches, etc.). > > I realize that this is a radical overhaul of the lock file policy > issue. Also, it may harm performance. On the other hand, > our benchmarks on JNI overhead for modern processors indicate > performance impact should be minimal. Perhaps it is more of > an issue with the toybox systems. > > Suppose there were a class with a reasonable default...someone > might write: > SerialPortLockPolicy.setPolicy(SerialPortLockPolicy.UNIX_LOCK_FILE); > SerialPortLockPolicy.setPolicy(SerialPortLockPolicy.NO_LOCK_CHECKING); > SerialPortLockPolicy.setPolicy(SerialPortLockPolicy.MAC_STYLE); > > Thus, we could have a run-time reconfiguration of the serial port lock > policy. A special NO_LOCK version of the binary would no longer > be required. > > Any thoughts on this? > > Thanks! > - Doug > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From joachim at buechse.de Tue Mar 21 06:23:08 2006 From: joachim at buechse.de (Joachim Buechse) Date: Tue, 21 Mar 2006 14:23:08 +0100 Subject: [Rxtx] PATCH: use of ioctl(fd, TIOCEXCL) instead of lockfiles Message-ID: <923AE774-EEA2-4911-92D8-32BB27802C8B@buechse.de> Here is the patch for the ioctl(fd, TIOCEXCL). I have verified this only for OSX 10.4.5, hence it is only defined for APPLE. However, it should work at least for Solaris as well. If a process has requested TIOEXCL further open calls by other user processes will fail. The patch also disables uucp style locking for APPLE. Obviously this is discussable. I think it is the way to go, as it eliminates creating the lock directory which doesnt exist on the standard installation and it eliminates messing with the system group definitions (adding users to group uucp). Regarding the possibility of root processes opening a device which is locked - I consider this a feature not a potential problem. It is highly unlikely, that somebody is crazy enough to run a JavaVM as root (unless he has no other means of getting a restricted IP port opened, ie doesnt understand ipfw). Anyway, even if the process runs as root, it fails when calling ioctl(fd, TIOCEXCL). It could however still open the port to listen for RING events. I.e. a fax server which needs to see incoming calls but otherwise doesnt want to block the port. So the only case where the proposed mechanism fails is, if an incorrectly implemented process running as root conflicts with a user process. I think this can be accepted. Regards, Joachim PS: If this patch is generally accepted, the installer and Mac doku should obviously be changed as well. Index: SerialImp.c =================================================================== RCS file: /usr/local/cvsroot/rxtx-devel/src/SerialImp.c,v retrieving revision 1.46.2.187 diff -u -r1.46.2.187 SerialImp.c --- SerialImp.c 29 Jan 2006 22:19:04 -0000 1.46.2.187 +++ SerialImp.c 21 Mar 2006 12:59:16 -0000 @@ -656,6 +656,25 @@ fd=OPEN (filename, O_RDWR | O_NOCTTY | O_NONBLOCK ); } while (fd < 0 && errno==EINTR); +#ifdef OPEN_EXCL + // Note that open() follows POSIX semantics: multiple open() calls to + // the same file will succeed unless the TIOCEXCL ioctl is issued. + // This will prevent additional opens except by root-owned processes. + // See tty(4) ("man 4 tty") and ioctl(2) ("man 2 ioctl") for details. + + if (fd >= 0 && (ioctl(fd, TIOCEXCL) == -1)) + { + sprintf( message, "open: exclusive access denied for % s\n", + filename ); + report( message ); + report_error( message ); + + close(fd); + goto fail; + } +#endif /* OPEN_EXCL */ + + if( configure_port( fd ) ) goto fail; (*env)->ReleaseStringUTFChars( env, jstr, filename ); sprintf( message, "open: fd returned is %i\n", fd ); Index: SerialImp.h =================================================================== RCS file: /usr/local/cvsroot/rxtx-devel/src/SerialImp.h,v retrieving revision 1.11.2.49 diff -u -r1.11.2.49 SerialImp.h --- SerialImp.h 5 Jul 2005 17:47:21 -0000 1.11.2.49 +++ SerialImp.h 21 Mar 2006 12:59:17 -0000 @@ -135,7 +135,8 @@ /*# define LOCKDIR "/var/spool/uucp"*/ # define LOCKDIR "/var/lock" # define LOCKFILEPREFIX "LK." -# define UUCP +/*# define UUCP*/ +# define OPEN_EXCL #endif /* __APPLE__ */ #if defined(__NetBSD__) # define DEVICEDIR "/dev/" From tjarvi at qbang.org Tue Mar 21 10:26:08 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 21 Mar 2006 10:26:08 -0700 (MST) Subject: [Rxtx] Javadoc on the go In-Reply-To: <441FA98B.9050701@ngi.it> References: <441FA98B.9050701@ngi.it> Message-ID: On Tue, 21 Mar 2006, Fabio Frumento wrote: > Hi Trent, > > sorry for the big delay but my job is running wild, i was out for some > time but now i'm back and ready to continue the javadoc for Rxtx. > > Did you used the last javadoc patch i sent you ? let me know if i have to > send it to you again or not. > > regards > > Fabio Hi Fabio The patch is in the rxtx mail-list archives. It will be going in soon. I did not see a time critical portion. I'll probably be going through the list since the last batch of patches this weekend and putting them into CVS. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Tue Mar 21 10:57:18 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 21 Mar 2006 10:57:18 -0700 (MST) Subject: [Rxtx] jvm issue In-Reply-To: <20060321065524.94779.qmail@web50701.mail.yahoo.com> References: <20060321065524.94779.qmail@web50701.mail.yahoo.com> Message-ID: On Mon, 20 Mar 2006, Lambok Sianturi wrote: > Hi All, > This is my first time to join RxTx mailing list. I thank you all for allowing others to sign in in requests help. > I use the latest RxTx lib in Fedora 3 with java version 1.4.2_09 b05. And I got this error: > > # > # An unexpected error has been detected by HotSpot Virtual Machine: > # > # SIGSEGV (0xb) at pc=0x00bf27f3, pid=2633, tid=3086112448 > # > # Java VM: Java HotSpot(TM) Client VM (1.4.2_09-b05 mixed mode) > # Problematic frame: > # C [ld-linux.so.2+0xa7f3] A native library loading error? What happens if you recompile rxtx on your system and install that? This sounds like an ABI problem? rxtx 2.1-7 was compiled with a gcc 2.96 toolchain as I recall. The hope is newer system will be backwards compatible. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Tue Mar 21 11:05:29 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 21 Mar 2006 11:05:29 -0700 (MST) Subject: [Rxtx] PATCH: use of ioctl(fd, TIOCEXCL) instead of lockfiles In-Reply-To: <923AE774-EEA2-4911-92D8-32BB27802C8B@buechse.de> References: <923AE774-EEA2-4911-92D8-32BB27802C8B@buechse.de> Message-ID: On Tue, 21 Mar 2006, Joachim Buechse wrote: > Here is the patch for the ioctl(fd, TIOCEXCL). I have verified this only > for OSX 10.4.5, hence it is only defined for APPLE. However, it should > work at least for Solaris as well. > > If a process has requested TIOEXCL further open calls by other user > processes will fail. > > The patch also disables uucp style locking for APPLE. Obviously this is > discussable. I think it is the way to go, as it eliminates creating the > lock directory which doesnt exist on the standard installation and it > eliminates messing with the system group definitions (adding users to > group uucp). > > Regarding the possibility of root processes opening a device which is > locked - I consider this a feature not a potential problem. It is highly > unlikely, that somebody is crazy enough to run a JavaVM as root (unless > he has no other means of getting a restricted IP port opened, ie doesnt > understand ipfw). Anyway, even if the process runs as root, it fails when > calling ioctl(fd, TIOCEXCL). It could however still open the port to > listen for RING events. I.e. a fax server which needs to see incoming > calls but otherwise doesnt want to block the port. So the only case where > the proposed mechanism fails is, if an incorrectly implemented process > running as root conflicts with a user process. I think this can be > accepted. > > Regards, > Joachim > > PS: If this patch is generally accepted, the installer and Mac doku > should obviously be changed as well. > > > Index: SerialImp.c > =================================================================== > RCS file: /usr/local/cvsroot/rxtx-devel/src/SerialImp.c,v > retrieving revision 1.46.2.187 > diff -u -r1.46.2.187 SerialImp.c > --- SerialImp.c 29 Jan 2006 22:19:04 -0000 1.46.2.187 > +++ SerialImp.c 21 Mar 2006 12:59:16 -0000 > @@ -656,6 +656,25 @@ > fd=OPEN (filename, O_RDWR | O_NOCTTY | O_NONBLOCK ); > } while (fd < 0 && errno==EINTR); > > +#ifdef OPEN_EXCL > + // Note that open() follows POSIX semantics: multiple open() > calls to > + // the same file will succeed unless the TIOCEXCL ioctl is > issued. > + // This will prevent additional opens except by root-owned > processes. > + // See tty(4) ("man 4 tty") and ioctl(2) ("man 2 ioctl") for > details. > + > + if (fd >= 0 && (ioctl(fd, TIOCEXCL) == -1)) > + { > + sprintf( message, "open: exclusive access denied for % > s\n", > + filename ); > + report( message ); > + report_error( message ); > + > + close(fd); > + goto fail; > + } > +#endif /* OPEN_EXCL */ > + > + > if( configure_port( fd ) ) goto fail; > (*env)->ReleaseStringUTFChars( env, jstr, filename ); > sprintf( message, "open: fd returned is %i\n", fd ); > Index: SerialImp.h > =================================================================== > RCS file: /usr/local/cvsroot/rxtx-devel/src/SerialImp.h,v > retrieving revision 1.11.2.49 > diff -u -r1.11.2.49 SerialImp.h > --- SerialImp.h 5 Jul 2005 17:47:21 -0000 1.11.2.49 > +++ SerialImp.h 21 Mar 2006 12:59:17 -0000 > @@ -135,7 +135,8 @@ > /*# define LOCKDIR "/var/spool/uucp"*/ > # define LOCKDIR "/var/lock" > # define LOCKFILEPREFIX "LK." > -# define UUCP > +/*# define UUCP*/ > +# define OPEN_EXCL > #endif /* __APPLE__ */ > #if defined(__NetBSD__) > # define DEVICEDIR "/dev/" > This looks like a good start. What do you think Dmitry? Perhaps all systems with TIOCEXCL defined should use that though. Even if they use lockfiles. It wont hurt anything. That would catch people hacking their own serial apps without checking lockfiles. Its a good idea to avoid C++ style comments in the C portions. Some older systems don't deal with them well. If it's just for Mac OS X, it isn't a big deal. I think it was the Irix compiler that was problematic? -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Tue Mar 21 11:22:05 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 21 Mar 2006 11:22:05 -0700 (MST) Subject: [Rxtx] lock files In-Reply-To: <8E12916A-1B9A-4FF2-B684-E2D1C794221B@buechse.de> References: <8E12916A-1B9A-4FF2-B684-E2D1C794221B@buechse.de> Message-ID: We can try it. Maybe the JNI is much improved. The nice thing about linking into liblock is distros then worry about lockfiles on their systems. This way, we have to deal with any changes that may show up. On Tue, 21 Mar 2006, Joachim Buechse wrote: > This is pretty much what I thought about when I suggested, that the > default behaviour could be overwritten with a property. I am very much in > favor of this approach. In particular this allows much easier debugging > for PC based java developers. > > I think big parts of the Java (and maybe some parts of the C code) could > use a bit of a structural workover (unit tests, javadoc, synchronization, > etc). Maybe there should be a CVS branch for this experimental version. > I'd be happy to contribute a first workover for some of the Java code. > Designing for testability and implementing a good bunch of unit tests has > been a strategy that worked quite well in the Java projects I lead. And > it ultimately allows more liberal change permission. > > Regards, > Joachim > > > On 21.03.2006, at 08:51, Dr. Douglas Lyon wrote: > >> Hi All, >> You know, if the use of lock files were >> under Java control (rather than a build-time decision), >> it might enable a more unified binary distro. It might also >> facilitate quick prototyping of non-lock file approaches >> to resolving serial port contention issues (i.e., mac-like >> approaches vs. linux approaches, etc.). >> >> I realize that this is a radical overhaul of the lock file policy >> issue. Also, it may harm performance. On the other hand, >> our benchmarks on JNI overhead for modern processors indicate >> performance impact should be minimal. Perhaps it is more of >> an issue with the toybox systems. >> >> Suppose there were a class with a reasonable default...someone >> might write: >> SerialPortLockPolicy.setPolicy(SerialPortLockPolicy.UNIX_LOCK_FILE); >> SerialPortLockPolicy.setPolicy(SerialPortLockPolicy.NO_LOCK_CHECKING); >> SerialPortLockPolicy.setPolicy(SerialPortLockPolicy.MAC_STYLE); >> >> Thus, we could have a run-time reconfiguration of the serial port lock >> policy. A special NO_LOCK version of the binary would no longer >> be required. >> >> Any thoughts on this? >> >> Thanks! >> - Doug >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From dmarkman at mac.com Tue Mar 21 16:05:17 2006 From: dmarkman at mac.com (Dmitry Markman) Date: Tue, 21 Mar 2006 18:05:17 -0500 Subject: [Rxtx] PATCH: use of ioctl(fd, TIOCEXCL) instead of lockfiles In-Reply-To: References: <923AE774-EEA2-4911-92D8-32BB27802C8B@buechse.de> Message-ID: <512AC70C-BB86-48F2-A83C-023F35C23BAB@mac.com> I think it's cool, but I'd like to have that property implementation when user can choose between locking mechanism about comments: it's easy to change comments to the C style or we can use extensions of the file to cpp so c++ compiler will be used On Mar 21, 2006, at 1:05 PM, Trent Jarvi wrote: > This looks like a good start. What do you think Dmitry? Perhaps > all systems with TIOCEXCL defined should use that though. Even if > they use lockfiles. It wont hurt anything. That would catch > people hacking their own serial apps without checking lockfiles. > > Its a good idea to avoid C++ style comments in the C portions. > Some older systems don't deal with them well. If it's just for Mac > OS X, it isn't a big deal. I think it was the Irix compiler that > was problematic? Dmitry Markman From dmarkman at mac.com Tue Mar 21 16:13:00 2006 From: dmarkman at mac.com (Dmitry Markman) Date: Tue, 21 Mar 2006 18:13:00 -0500 Subject: [Rxtx] PATCH: use of ioctl(fd, TIOCEXCL) instead of lockfiles In-Reply-To: References: <923AE774-EEA2-4911-92D8-32BB27802C8B@buechse.de> Message-ID: I'd like to add that creating locking folder isn't a big deal we never had a problem related to the lock folders, because we always used installer on mac os x from other hand I'm not very much familiar with iotcl locking approach and I'm not sure it's more efficient Joachim wrote "I think it is the way to go, as it eliminates creating the lock directory which doesnt exist on the standard installation and it eliminates messing with the system group definitions (adding users to group uucp)." but I really didn't have any problem with that 1. doesn't exist on the standard installation there are many-many things that don't exist in the standard installation so I don't think that argument is strong enough 2. messing with the system group definitions I don't think we're messing with the group definition mac os x provides very clear way to set up group's members and together with Greg Guerin AuthKit there is no problem to set those definitions so I don't think that argument is strong either but from other hand using iotcl is more promising and is more elegant On Mar 21, 2006, at 1:05 PM, Trent Jarvi wrote: > > This looks like a good start. What do you think Dmitry? Perhaps > all systems with TIOCEXCL defined should use that though. Even if > they use lockfiles. It wont hurt anything. That would catch > people hacking their own serial apps without checking lockfiles. Dmitry Markman From joachim at buechse.de Wed Mar 22 04:46:45 2006 From: joachim at buechse.de (Joachim Buechse) Date: Wed, 22 Mar 2006 12:46:45 +0100 Subject: [Rxtx] PATCH: use of ioctl(fd, TIOCEXCL) instead of lockfiles In-Reply-To: References: <923AE774-EEA2-4911-92D8-32BB27802C8B@buechse.de> Message-ID: Sorry, I was not very clear with my arguments, so I will try again;-) Please, don't take this as an attack against work that has been done. I think the contributions that have been made in the past were made in a good spirit. But I really believe, that the current solution for OSX has many shortcomings and should be changed as soon as possible. lock files --- The /var/lock folder does not exist on the standard OSX installation, however the standard installation includes several applications that use serial ports (i.e. the FAX capability). This indicates, that the lock folder approach will not work well with system components. Applications for OSX will generally try to live in harmony with system components (except for HP print drivers of course). I think RXTX should follow this approach as well. uucp group --- Accessing serial ports is not an admin privileged operation on OSX. Any user (world) has read/write privileges on /dev/tty*. So the system default is to not enforce any group membership to access these ports. The group uucp however is a system group on all unix systems I know. It exists for certain system processes. A non admin user should in general not be a member of this group. Quite arguably no user should ever be a member of this group. Installer --- My general opinion is, that - no Installer should touch user or group data without warning - no Application Installer should touch groups which are not specific to the very application installed - no Installer should ever add regular users to a system group The current installer injects the installing user in the group uucp without warning about this change and without giving the option to "opt out" of this change. This is a potential security risk (but not currently a real one, as OSX contains no folders belonging to group uucp). The current installer does not work for multi user systems. It puts the installing user in the uucp group. However the installing user is not necessarily the user that will use the application. Putting all users that may use a serial port application in the system group uucp seems like a very invasive approach to me. Besides that, newly created users will not automatically be in the group and hence, serial applications will "break" for new users without obvious reasons. Avoiding the lock files will allow self contained applications (i.e. drag&drop installation). In my eyes this is largely preferable over an installer that requests admin privileges. Adding up all these points indicates very strongly, that the lock-file implementation is not the way to go on OSX. Regards, Joachim On 22.03.2006, at 00:13, Dmitry Markman wrote: > I'd like to add that > > creating locking folder isn't a big deal > we never had a problem related to the lock folders, because we > always used installer on mac os x > from other hand I'm not very much familiar with iotcl locking > approach and I'm not sure it's more efficient > > Joachim wrote "I think it is the way to go, as it eliminates > creating the lock directory which doesnt exist on the standard > installation and it eliminates messing with the system group > definitions (adding users to group uucp)." but I really didn't have > any problem with that > > 1. doesn't exist on the standard installation > there are many-many things that don't exist in the standard > installation so I don't think that argument is strong enough > 2. messing with the system group definitions > I don't think we're messing with the group definition > mac os x provides very clear way to set up group's members and > together with Greg Guerin AuthKit there is no problem to set those > definitions > so I don't think that argument is strong either > but from other hand using iotcl is more promising and is more elegant > > > > On Mar 21, 2006, at 1:05 PM, Trent Jarvi wrote: > >> >> This looks like a good start. What do you think Dmitry? Perhaps >> all systems with TIOCEXCL defined should use that though. Even if >> they use lockfiles. It wont hurt anything. That would catch >> people hacking their own serial apps without checking lockfiles. > > Dmitry Markman > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From dmarkman at mac.com Wed Mar 22 05:27:13 2006 From: dmarkman at mac.com (Dmitry Markman) Date: Wed, 22 Mar 2006 07:27:13 -0500 Subject: [Rxtx] PATCH: use of ioctl(fd, TIOCEXCL) instead of lockfiles In-Reply-To: References: <923AE774-EEA2-4911-92D8-32BB27802C8B@buechse.de> Message-ID: <83440CF3-DCD8-41C1-B941-F227232C27E3@mac.com> thanks for the very good explanation I didn't think that you were attacking any thing, so don't worry I just had feeling, that there were more aesthetic reasons for going to ioctl then real necessity now you explained everything quite well (BTW, asfar as I remember installer asks admin password so it wasn't quiet, but it really doesn't matter now) thanks On Mar 22, 2006, at 6:46 AM, Joachim Buechse wrote: > Sorry, I was not very clear with my arguments, so I will try again;-) > > Please, don't take this as an attack against work that has been > done. I think the contributions that have been made in the past > were made in a good spirit. But I really believe, that the current > solution for OSX has many shortcomings and should be changed as > soon as possible. > > lock files > --- > The /var/lock folder does not exist on the standard OSX > installation, however the standard installation includes several > applications that use serial ports (i.e. the FAX capability). This > indicates, that the lock folder approach will not work well with > system components. Applications for OSX will generally try to live > in harmony with system components (except for HP print drivers of > course). I think RXTX should follow this approach as well. > > uucp group > --- > Accessing serial ports is not an admin privileged operation on OSX. > Any user (world) has read/write privileges on /dev/tty*. So the > system default is to not enforce any group membership to access > these ports. The group uucp however is a system group on all unix > systems I know. It exists for certain system processes. A non admin > user should in general not be a member of this group. Quite > arguably no user should ever be a member of this group. > > Installer > --- > My general opinion is, that > - no Installer should touch user or group data without warning > - no Application Installer should touch groups which are not > specific to the very application installed > - no Installer should ever add regular users to a system group > > The current installer injects the installing user in the group uucp > without warning about this change and without giving the option to > "opt out" of this change. This is a potential security risk (but > not currently a real one, as OSX contains no folders belonging to > group uucp). > > The current installer does not work for multi user systems. It puts > the installing user in the uucp group. However the installing user > is not necessarily the user that will use the application. Putting > all users that may use a serial port application in the system > group uucp seems like a very invasive approach to me. Besides that, > newly created users will not automatically be in the group and > hence, serial applications will "break" for new users without > obvious reasons. > > > Avoiding the lock files will allow self contained applications > (i.e. drag&drop installation). In my eyes this is largely > preferable over an installer that requests admin privileges. Adding > up all these points indicates very strongly, that the lock-file > implementation is not the way to go on OSX. > > Regards, > Joachim > > > On 22.03.2006, at 00:13, Dmitry Markman wrote: > >> I'd like to add that >> >> creating locking folder isn't a big deal >> we never had a problem related to the lock folders, because we >> always used installer on mac os x >> from other hand I'm not very much familiar with iotcl locking >> approach and I'm not sure it's more efficient >> >> Joachim wrote "I think it is the way to go, as it eliminates >> creating the lock directory which doesnt exist on the standard >> installation and it eliminates messing with the system group >> definitions (adding users to group uucp)." but I really didn't >> have any problem with that >> >> 1. doesn't exist on the standard installation >> there are many-many things that don't exist in the standard >> installation so I don't think that argument is strong enough >> 2. messing with the system group definitions >> I don't think we're messing with the group definition >> mac os x provides very clear way to set up group's members and >> together with Greg Guerin AuthKit there is no problem to set those >> definitions >> so I don't think that argument is strong either >> but from other hand using iotcl is more promising and is more elegant >> >> >> >> On Mar 21, 2006, at 1:05 PM, Trent Jarvi wrote: >> >>> >>> This looks like a good start. What do you think Dmitry? Perhaps >>> all systems with TIOCEXCL defined should use that though. Even >>> if they use lockfiles. It wont hurt anything. That would catch >>> people hacking their own serial apps without checking lockfiles. >> >> Dmitry Markman >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx Dmitry Markman From lyon at docjava.com Wed Mar 22 06:12:18 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Wed, 22 Mar 2006 08:12:18 -0500 Subject: [Rxtx] sole of a new design pattern Message-ID: Hi All, I have been thinking about how we design the serial port software. I think we need a new design pattern. For lack of a better term, I shall call it: The Parametric Singleton Design Pattern By Douglas A. Lyon ABSTRACT The goal of the singleton design pattern is to make sure that there is one, and only one, instance of a given class. The goal of the parametric singleton design pattern is to make sure that there is one, and only one, instance of a given class with the given parametric values. We parametric singleton design pattern combines the singleton design pattern with a parameter that enables unique creation of instances of a class. These instances are cached. When a user asks for an instance with these parameters, the cache is checked. If the instance is in the cache, the instance is returned, otherwise it is created, added to the cache and then returned. We apply our parametric singleton design pattern to the retrieval of RMI registries bound to a given port. The goal of our system is to make sure that no two RMI registries are listening to the same socket and to make use of the RMI registries after they have been created. RMI registries are used in distributed computation. Introduction The singleton design pattern is meant to ensure that on a single instance of a class exists. It is also meant to provide a global point of access to it. The intent of the parametric singleton design pattern is to ensure that a class has only one instance for a given set of parameter values. It also provides a global point of access to it. Motivation A system cannot tolerate multiple instances of some classes with identical parameters. For example, you cannot have two instances making use of the same serial port, at the same time. You cannot have two instances that are trying to listen to the same socket connection. You cannot have two instances writing to the same file structure at the same time. As the operating system is often thought of as the arbiter of consumed resources (i.e., tape drives, serial ports, etc.) we frequently leave it to an operating system implementation to resolve these contention issues. Even for similar resources (like serial ports) there are few standards for handling contention. For example, serial ports on Linux are locked using a "/var/lock" file. POSIX, on the other hand, uses ioctl mechanisms to prevent contention. A better solution is to make a class that is responsible for keeping track of the instances created from the class. The class is declared final, so that it cannot be subclassed. The class also has a private constructor, so that other classes cannot instance it. The new design pattern is called the parametric singleton design pattern and it provides a way to access and create instances with given parameters. Applicability Use the Parametric Singleton Design Pattern when: 1. There must be exactly one instance of a class with the given parameters. 2. The instances must be accessible to clients from a well-known access point. Structure Insert UML diagram here. Participants The Parametric Singleton Clients that need instances 1. The Parametric Singleton defines an instance upon request from a client, if, and only if, the instance does not already exist. 2. The Parametric Singleton returns the instance to the client. 3. The Parametric Singleton is responsible for creating unique instances from given parameters. Collaborations Clients obtain a reference to a Parametric Singleton instance only through the parametric singleton design pattern. If the instance is left in an improper state (e.g., the serial port was left open) it is NOT the role of the Parametric Singleton Design Pattern to close the IO port. Nor is it the role of the Parametric Singleton Design Pattern to open the port. That role is delegate to some other part of the system. Further, it is not the role of the Parametric Singleton Design Pattern to check out resources. That is, multiple threads can have multiple references to the same resource at the same time. MUTEX locking is delegated to some other part of the system. Consequences The Parametric Singleton Design Pattern has several benefits: 1. Controlled access to parametrically defined instances. Since the Parametric Singleton class encapsulates its instances, there is control over how and when clients access it. 2. Reduced name space. The Parametric Singleton pattern avoids global variables that store instances created from the same parameter. Implementation Here are implementation issues to consider when using the Parametric Singleton pattern: 1. Unique mapping of parameters. The Parametric Singleton pattern requires that there be a mean to isomorphically map the parameter space into the instance space and back again. 2. Ensure unique instances. The Parametric Singleton pattern makes unique instances from parameters, and it does so only once. 3. Cache instances for fast retrieval. The Parametric Singleton pattern must be able to look up instances, given some set of parameters, and do so from some data structure. That is, there must be enough space to hold references to all the instances the program will need. Also, a mechanism is needed to look up and retrieve the instances quickly enough to satisfy the clients. Sample Code public final class ParametricSingletonRmiRegistry { private static Hashtable registry = new Hashtable(100); // use singleton pattern and??????????????????????????????????????????????? // prevent instantiation of RmiRegistryUtils.?????????????????????????????? private ParametricSingletonRmiRegistry() { } // the only instance of the Registry held by the RmiRegistryUtils?????????? public static void listNames(Integer port) { if (!isInCacheAndRunning(port)) return; Registry r = (Registry) registry.get(port); System.out.println("registry on port: " + port); System.out.println("registry: " + r); System.out.println("names: "); try { print(r.list()); } catch (RemoteException e) { In.message(e); } System.out.println("------------------------"); } /**???????????????????????????????????????????????????????????????????????? * Checks whether a Registry has been started on this host????????????????? * in the specified port.?????????????????????????????????????????????????? * If not, it tries to start one.?????????????????????????????????????????? * when it fails to start a Registry, it exits the program????????????????? * with exit code 1.??????????????????????????????????????????????????????? */ public static void restart(int port) { if (isInCacheAndRunning(port)) return; try { startRegistry(port); } catch (RemoteException e) { In.message(e); } } /**???????????????????????????????????????????????????????????????????????? * @param port????????????????????????????????????????????????????????????? * @return true if registry is in cache and running???????????????????????? */ private static boolean isInCacheAndRunning(Integer port) { if (!isRegistryRunning(port.intValue())) return false; if (!isRegistryInCache(port.intValue())) return false; return true; } /**???????????????????????????????????????????????????????????????????????? * @param port????????????????????????????????????????????????????????????? * @return true if we are able to locate a local registry on port.??????????????????????????????????????????????????????????????????????????? */ private static boolean isRegistryRunning(int port) { try { Registry r = LocateRegistry.getRegistry(port); if (r != null) return true; } catch (RemoteException e) { return false; } return false; } /**???????????????????????????????????????????????????????????????????????? * @param port????????????????????????????????????????????????????????????? * @return return true if registry is in cache????????????????????????????? */ private static boolean isRegistryInCache(int port) { if (registry.get(new Integer(port)) == null) return false; return true; } /**???????????????????????????????????????????????????????????????????????? * Restart the registry, if needed.???????????????????????????????????????? * Return the only instance of the registry for consistent global?????????? * using by making use of the Singleton Design Pattern????????????????????? *????????????????????????????????????????????????????????????????????????? * @return the internally held registry instance.?????????????????????????? */ public static Registry getRegistry(Integer port) { restart(port); return (Registry) registry.get(port); } private static void startRegistry(Integer port) throws RemoteException { Registry r; try { r = LocateRegistry.createRegistry(port.intValue()); registry.put(port, r); //r = new sun.rmi.registry.RegistryImpl???????????????????????????? /// (port.intValue());?????????????????????????????????????? // registry.put(port, r);?????????????????????????????????????????? } catch (Exception e) { //e.printStackTrace();????????????????????????????????????????????? r = LocateRegistry.getRegistry(port.intValue()); registry.put(port, r); } } public static void main(String args[]) throws RemoteException { //restart(port);??????????????????????????????????????????????????????? restart(5001); restart(5002); restart(5002); Registry r = LocateRegistry.getRegistry(5002); System.out.println("registry="+r); } } I would very much like to get your feedback on this new design pattern idea. Thank you for your time. Regards, - Doug From david.garnier at trusted-logic.com Wed Mar 22 07:36:10 2006 From: david.garnier at trusted-logic.com (David Garnier) Date: Wed, 22 Mar 2006 15:36:10 +0100 Subject: [Rxtx] sole of a new design pattern In-Reply-To: References: Message-ID: <442160DA.80107@trusted-logic.com> Hello, > The Parametric Singleton Design Pattern The Singleton is the most abused design pattern ever. Good use-cases for this pattern are extremely rare and mostly confined to problems related to hardware resources, like serial ports. > Applicability > > Use the Parametric Singleton Design Pattern when: > 1. There must be exactly one instance of a class with the given > parameters. OK. As I said above, this case this actually very unusual. The Singleton pattern is mostly used when : > 2. The instances must be accessible to clients from a well-known > access point. Using the singleton pattern in this case is just convenient for the programmer. Problems arises pretty quickly, especially if you attempt to unit-test your classes. 1) If your singleton is stateful, or hold on to stateful objects, it means that two different unit tests are not actually independent. Instead of starting with a brand new environment, the result of a test may be affected by the result of a previous test. This problem also arise when with your class relies on a database. In both cases, the solution is to reset your "unique" resource (Singleton or database) at the beginning of the test, which is a pain. Also, while most projects connect to a single database, projects that allow the use of Singletons usually contain several of thems, and new ones may cropped up unnoticed. You quickly end up with test cases that only pass in a certain order, which is a royal pain. 2) You cannot mockup a singleton. Once everyone calls the SomeSingleton class statically, you can't replace your class by SomeSingletonMockup. Furthermore, even for hardware services, the Singleton pattern does not really prevent concurrent accesses. If you start the same program in two different JVMs, unless they somehow shared the state of their "Singletons" (through lock files for example), the Singleton pattern will not prevent concurrent access. Our application uses RXTX, and we routinely encounter cases where another (native) application has already locked the port. Since we cannot modify the native application to recognize lock files, OS-level control is irreplaceable. > > Consequences > The Parametric Singleton Design Pattern has several benefits: > > 1. Controlled access to parametrically defined instances. Since > the Parametric Singleton class encapsulates its instances, there is > control over how and when clients access it. Not really. Once you've returned the instance to a client, you've lost control over it. The client can to whatever it wants with it. You cannot "recall" the instance or claim it back. > 2. Reduced name space. The Parametric Singleton pattern avoids > global variables that store instances created from the same parameter. Sure, but you don't have to rely on a Singleton for that. Just create a single Factory. > I would very much like to get your feedback on this new design > pattern idea. Well, it's nothing new. Some may say that it is the point of design patterns: formalizes the designs that occur again and again. However, this design is simply a combination of the Singleton and Factory patterns. I did use it in the past, but now I've been exposed to the shortcomings of the Singleton pattern, so I limit myself to Factories. Regards, David From sean_montgomery at baseview.com Wed Mar 22 08:35:28 2006 From: sean_montgomery at baseview.com (Sean Montgomery) Date: Wed, 22 Mar 2006 10:35:28 -0500 Subject: [Rxtx] sole of a new design pattern In-Reply-To: <442160DA.80107@trusted-logic.com> References: <442160DA.80107@trusted-logic.com> Message-ID: <05769CA7-A51B-4CF0-BAA0-E02DD905F5A4@baseview.com> On Mar 22, 2006, at 9:36 AM, David Garnier wrote: > Furthermore, even for hardware services, the Singleton pattern does > not really prevent concurrent > accesses. If you start the same program in two different JVMs, > unless they somehow shared the state > of their "Singletons" (through lock files for example), the > Singleton pattern will not prevent > concurrent access. > Multiple class loaders in a single JVM can be tricky, too. Then there's synchronization, lazy initialization and serialization of singletons to contend with. Bloch's Effective Java covers these, and here's a few articles: http://www.javaworld.com/javaworld/jw-04-2003/jw-0425-designpatterns- p3.html http://java.sun.com/developer/technicalArticles/Programming/singletons/ Just FYI :-) From lyon at docjava.com Wed Mar 22 08:50:48 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Wed, 22 Mar 2006 10:50:48 -0500 Subject: [Rxtx] sole of a new design pattern In-Reply-To: <442160DA.80107@trusted-logic.com> References: <442160DA.80107@trusted-logic.com> Message-ID: Hi All, First, I would like to thank David for his prompt and thoughtful remarks. I had no idea people that feel strongly about a design patterns! Wow! Feedback (particularly critical feedback) is greatly appreciated. Starting at the end, first: >I did use it in >the past, but now I've been exposed to the shortcomings of the >Singleton pattern, so I limit myself to Factories. David, if I understood your comments correctly, you suggested that Factories can be used in leu of the Singleton Design Pattern, or even the Parametric Singleton Design Pattern. As I see in [Gof]: Factory Method: Intent "Define an interface for creating an object, but let subclasses decide which class to instantiate. Factory Method lets a class defer instantiation to subclasses." The Singleton Design Pattern is a concrete class, which is rather different, right? Also, subclasses are not permitted with Singleton, as they are final. Naturally, I could use an abstract factory as a parent for a singleton. I could even design a facade that could be implemented with the singleton....but that is not the intention of the design. Unless you want a mock-up, as discussed, below: More below: >Hello, > >> The Parametric Singleton Design Pattern > >The Singleton is the most abused design pattern ever. Good use-cases >for this pattern are extremely >rare and mostly confined to problems related to hardware resources, >like serial ports. > > >> Applicability >> >> Use the Parametric Singleton Design Pattern when: >> 1. There must be exactly one instance of a class with the given >> parameters. >OK. As I said above, this case this actually very unusual. The >Singleton pattern is mostly used when : >> 2. The instances must be accessible to clients from a well-known >> access point. > >Using the singleton pattern in this case is just convenient for the >programmer. Problems arises >pretty quickly, especially if you attempt to unit-test your classes. > >1) If your singleton is stateful, or hold on to stateful objects, it >means that two different unit >tests are not actually independent. Instead of starting with a brand >new environment, the result of >a test may be affected by the result of a previous test. This >problem also arise when with your >class relies on a database. In both cases, the solution is to reset >your "unique" resource >(Singleton or database) at the beginning of the test, which is a >pain. Also, while most projects >connect to a single database, projects that allow the use of >Singletons usually contain several of >thems, and new ones may cropped up unnoticed. You quickly end up >with test cases that only pass in a >certain order, which is a royal pain. There are basic problems with communicating finite state machines that include reachability and deadlock analysis. These are addressed with petri net analysis and are beyond the scope of the design pattern. As you quite rightly pointed out; the parametric singleton pattern (or the singleton pattern, for that matter) enable multiple threads to gain access to the same instance. The only way that I can see to block others from gaining access to the reference is the synchronize keyword. This is putting a spin-lock (or MUTEX) on the reference. The question of how to unit-test a design pattern like the parametric singleton remains open. Perhaps this is a deficiency. > >2) You cannot mockup a singleton. Once everyone calls the >SomeSingleton class statically, you can't >replace your class by SomeSingletonMockup. Acutally, I am not sure that this is true. If the Singleton implements a Facade interface, it should be possible to make the replacement. Right? > >Furthermore, even for hardware services, the Singleton pattern does >not really prevent concurrent >accesses. If you start the same program in two different JVMs, >unless they somehow shared the state >of their "Singletons" (through lock files for example), the >Singleton pattern will not prevent >concurrent access. Good Point!! You have sharp eyes! The singleton design pattern should/could take responsibility for this. In fact, you may notice that my code does have an implementation (LocateRegistry) that can work across JVM's. The LocateRegistry will even work across the Internet! LocateRegistry takes both a host name and a Port (lock files just don't do this). I did not think to implement this beyond the local machine, but, in its present form, it will work across different processes. > >Our application uses RXTX, and we routinely encounter cases where >another (native) application has >already locked the port. Since we cannot modify the native >application to recognize lock files, >OS-level control is irreplaceable. The singleton design pattern is not meant to replace OS-level control, but to centralize the Java programmers access to it. If lock files, for example, are used for serial ports, the Singleton Design Pattern should be able to work with them. > > >> >> Consequences >> The Parametric Singleton Design Pattern has several benefits: >> > > 1. Controlled access to parametrically defined instances. Since >> the Parametric Singleton class encapsulates its instances, there is >> control over how and when clients access it. > >Not really. Once you've returned the instance to a client, you've >lost control over it. The client >can to whatever it wants with it. You cannot "recall" the instance >or claim it back. Good point, this should read: > 1. Controll when parametrically defined instances are created. Since > > the Parametric Singleton class encapsulates its instances, there is > > control over how and when they are instanced. > >> 2. Reduced name space. The Parametric Singleton pattern avoids >> global variables that store instances created from the same parameter. > >Sure, but you don't have to rely on a Singleton for that. Just >create a single Factory. > > Thank you for your thoughtful and prompt response! Regards, - Doug From dmarkman at mac.com Wed Mar 22 21:21:55 2006 From: dmarkman at mac.com (Dmitry Markman) Date: Wed, 22 Mar 2006 23:21:55 -0500 Subject: [Rxtx] sole of a new design pattern In-Reply-To: <442160DA.80107@trusted-logic.com> References: <442160DA.80107@trusted-logic.com> Message-ID: I don't think I get it On Mar 22, 2006, at 9:36 AM, David Garnier wrote: > Using the singleton pattern in this case is just convenient for the > programmer. Problems arises > pretty quickly, especially if you attempt to unit-test your classes. so you're saying that something isn't so good because you can not test it in the convenient way? if that's true, I'm totally disagree change your test, debug whatever, but if software is efficient at runtime, works fine and only problem is some unit test (which is some kind of framework for testing) then dump that unit test , dump that unit framework and make something appropriate to the software you're testing so if Douglas want to use singletons, what's the problem? and what do you mean by abusing of singleton usage? of course singleton doesn't prevent concurrent access to the resource across the processes unless you're using some OS facility to prevent it, besides singleton as it was introduced is relevant only and only inside of the same process otherwise it's not singleton it's something else (let's say network singleton: so you have remote invocation facility and some factory method that return object created by that facility) I don't have any problem with using any kind of singletons. Parametric Singleton idea (if I understand it right) could be easily implemented in the following way: use a map populate map with instances of some class and key is your parameter (you can use lazy population too) if somebody ask the key check the value if it's null so resource is taken if somebody returns the resource put it back to the map public synchronized static Object getSomeResource(Object parameter); public synchronized static void returnResource(Object parameter); getSomeResource (inside of the same process) could return null in 2 cases 1. if somebody (from other thread for example) already took that resource 2. if OS API said that resource corresponded to that parameter (serial port with parameter = 1 (port #)) is locked and unavailable; I'm not sure that in case of serial ports we even need those Parametric Singletons (unless lock checking is a very expensive operation) just ask the OS about availability of that resource and if it's available give it away and then OS will lock it and therefore in next time somebody ask it just answer that resource is locked and return null for example system has 2 serial ports available so I ask getResource("tty"); or I ask getResource("Bluetooth-Modem"); and if OS is ok you can give tty or Bluetooth-Modem or both no need for any additional pattern I think back to the problem mac os x doesn't recognize locking via files, so it handles locking via some API an instance of the singleton in each process should recognize that resource is locked (by using that API) that's all we don't have to make things more complicate then they are just because there is some nice design pattern or nice unit test framework or whatever keep things simple, make them work fast, don't introduce middle layers unless you have really good reason to do so of course I could be entirely wrong, so sorry about that in advance thanks Dmitry Markman From tjarvi at qbang.org Wed Mar 22 22:31:41 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 22 Mar 2006 22:31:41 -0700 (MST) Subject: [Rxtx] sole of a new design pattern In-Reply-To: References: Message-ID: Hi Doug Interesting reading. So far I'm just reading and thinking. I have one question so far. " Clients obtain a reference to a Parametric Singleton instance only through the parametric singleton design pattern. If the instance is left in an improper state (e.g., the serial port was left open) it is NOT the role of the Parametric Singleton Design Pattern to close the IO port. Nor is it the role of the Parametric Singleton Design Pattern to open the port. That role is delegate to some other part of the system. " So when the clients obtain a reference to the singleton, can they assume the port is there? IE, would it be the singletons role to handle things like USB dongles being removed with event hints comming from the underlying OS. Hardware abstraction layer/HAL on Linux is an example of underlying OS events. I assume that role too is delegated to other parts of the system? -- Trent Jarvi tjarvi at qbang.org From lyon at docjava.com Thu Mar 23 08:10:33 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Thu, 23 Mar 2006 10:10:33 -0500 Subject: [Rxtx] Classes don't need goals, they need roles! In-Reply-To: References: Message-ID: Hi Trent, Yes, I think that the role of the Parametric Singleton Pattern is not to open or close serial ports, nor is it to perform error checking. On the other hand, if you were to combine the role of the Parametric Singleton Pattern with another role (like that of error checking) it might not be amiss. However, I generally caution programmers against adding multiple roles to classes, as this leads to monolithic designs. Thus a different class (NativeLibDetect) could have the role of determining if the native library can be loaded. Another class (SerialPortBean) can have the role of serializing the default state of the serial port, so that it can be recovered, from user preferences, at a later time. The SerialPortDetect could have the role of determining if the serial port is removed (i.e., a USB port was unplugged). My guess is that each class should have a different role in the system, in order to ease maintenance and testing...but I could be wrong about that. Thanks! - Doug >Hi Doug > >Interesting reading. So far I'm just reading and thinking. I have >one question so far. > >" > Clients obtain a reference to a Parametric Singleton instance only >through the parametric singleton design pattern. If the instance is >left in an improper state (e.g., the serial port was left open) it is >NOT the role of the Parametric Singleton Design Pattern to close the >IO port. Nor is it the role of the Parametric Singleton Design Pattern >to >open the port. That role is delegate to some other part of the system. >" > >So when the clients obtain a reference to the singleton, can they >assume the port is there? IE, would it be the singletons role to >handle things like USB dongles being removed with event hints >comming from the underlying OS. Hardware abstraction layer/HAL on >Linux is an example of underlying OS events. > >I assume that role too is delegated to other parts of the system? > >-- >Trent Jarvi >tjarvi at qbang.org >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From maximulo at yahoo.com Fri Mar 24 01:22:38 2006 From: maximulo at yahoo.com (Maximulo Majir) Date: Fri, 24 Mar 2006 00:22:38 -0800 (PST) Subject: [Rxtx] JavaPOS Message-ID: <20060324082238.66371.qmail@web38214.mail.mud.yahoo.com> Hi all! Hello Trent! From what i understand, RXTX or JavaComm APIs were not created solely for JavaPOS. In JavaPOS, we have the virtual method claim() which is separate from open(), but in our RXTX API, claiming is done every call to open(), we cant open the port if its claimed by another application. Would it be alright to suggest or ask to create a new method called claim(..)? Is there such thing as forceclaim() in RXTX? this could be the same as portownership transfer or its equivalent. ForceClaim is in JSR80. Do you have some samples using RXTX as the lower layer for the Device Service Objects in JavaPOS? I have tried it, i just want to compare. Thank you all! maxim __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060324/496adba2/attachment-0025.html From tjarvi at qbang.org Fri Mar 24 11:28:19 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 24 Mar 2006 11:28:19 -0700 (MST) Subject: [Rxtx] Re: RXTX 2.1 Solaris Problems In-Reply-To: <3691.1143210578@www045.gmx.net> References: <3691.1143210578@www045.gmx.net> Message-ID: On Fri, 24 Mar 2006, Andreas Guenther wrote: > Hi all, > > the solaris problem was not the lock file only. > > Ok, I had to create the directory /var/spool/locks myself. > /var/spool/uucp exists. > > But rxtx didn't find any port. > > I compiled the source with my own debug-informations > and I tried to isolate the problem. > > The problem is the testRead-call in SerialImp.c > > JNIEXPORT jboolean JNICALL RXTXCommDriver(testRead)( > > ... > if ( READ( fd, &c, 1 ) < 0 ) > { > if ( errno != EAGAIN ) { > report( "testRead() read failed\n" ); > ret = JNI_FALSE; > } > } > Thanks Andreas I'm packing up to move. I'll be more or less away for a couple weeks here. I'll be checking email but my workstation is going into a box soon. This isn't hard to fix as this port should be enumerated when EWOULDBLOCK is recieved. Thats error is OK for enumeration just as EAGAIN is. I've put the bug into bugzilla so we dont forget to get to it. http://bugzilla.qbang.org/show_bug.cgi?id=42 You can add yourself to the CC list if you wish to test fixes we provide or even put a patch into bugzilla yourself. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Fri Mar 24 11:51:52 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 24 Mar 2006 11:51:52 -0700 (MST) Subject: [Rxtx] JavaPOS In-Reply-To: <20060324082238.66371.qmail@web38214.mail.mud.yahoo.com> References: <20060324082238.66371.qmail@web38214.mail.mud.yahoo.com> Message-ID: On Fri, 24 Mar 2006, Maximulo Majir wrote: > Hi all! Hello Trent! > > > From what i understand, RXTX or JavaComm APIs were not > created solely for JavaPOS. In JavaPOS, we have the virtual method > claim() which is separate from open(), but in our RXTX API, claiming is > done every call to open(), we cant open the port if its claimed by > another application. Would it be alright to suggest or ask to create a > new method called claim(..)? Is there such thing as forceclaim() in > RXTX? this could be the same as portownership transfer or its > equivalent. ForceClaim is in JSR80. > Do you have some samples using RXTX as the lower layer for the Device > Service Objects in JavaPOS? I have tried it, i just want to compare. > maxim Hi Maxim JSR80 is the USB API IBM/Sun put together. The problem is they have a richer kernel/API underneath that can handle such things. With Serial Ports, there isnt anything there other than an ioctl that says don't let anyone touch this and lockfiles that are more of a 'lets be nice.' At times we may be using USB ports but it is through the termios layer with the limitations mentioned. The advantage is that not only USB will work with rxtx. Anything that has a termios layer should work (to the extent that termios layer is complete). I don't know how forceclaim() would help you. Lets say someone has a programmer working on /dev/ttyS0 and you take it. Now you both race each other to read data first. There isn't a mechanism I know of that will solve this problem in termios. The most obvious test being a native app and a Java app trying to take the port. There is the potential of requestion ownership from other Java Applications but the use for that is very rare. Did you have something more specific in mind that I'm missing? I'm not sure that claim() and forceclaim() would help you with rxtx other than maybe locking the port with claim() without opening it. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sat Mar 25 23:42:08 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 25 Mar 2006 23:42:08 -0700 (MST) Subject: [Rxtx] Serial snoop Message-ID: I was reading the Linux kernel mail-list tonight and ran past a thread that mentioned sersnoop. This looks like a handy tool for people dealing with new toys. "a simple command-line tool for linux that echoes bytes to and from any two serial ports, ptys, or network sockets, and prints all traffic to stdout, in hex and ascii." http://www.restivo.org/projects/sersnoop/ It works on Linux only at this time (debian package available). -- Trent Jarvi tjarvi at qbang.org From beat.arnet at gmail.com Sun Mar 26 07:32:35 2006 From: beat.arnet at gmail.com (Beat Arnet) Date: Sun, 26 Mar 2006 09:32:35 -0500 Subject: [Rxtx] Error 0x5 at /home/bob/foo/tar/rxtx-2.1-7/build/../src/termios.c(860): Access is, denied. Message-ID: <4426A603.80508@gmail.com> Dear all, When trying to open the serial port, I sometimes (not always) run into the following exception (when opening the serialPort): Error 0x5 at /home/bob/foo/tar/rxtx-2.1-7/build/../src/termios.c(860): Access is denied. java.lang.UnsatisfiedLinkError: native_psmisc_report_owner at gnu.io.CommPortIdentifier.native_psmisc_report_owner(Native Method) at gnu.io.CommPortIdentifier.open(CommPortIdentifier.java:354) at codeskin.tools.CLLoader.open(CLLoader.java:79) at codeskin.tools.C2000Programmer.run(C2000Programmer.java:220) at java.lang.Thread.run(Unknown Source) Is this the type of error where I should just try to open the port again, or can it be avoided? Regards, Beat From tjarvi at qbang.org Sun Mar 26 11:40:12 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 26 Mar 2006 11:40:12 -0700 (MST) Subject: [Rxtx] Error 0x5 at /home/bob/foo/tar/rxtx-2.1-7/build/../src/termios.c(860): Access is, denied. In-Reply-To: <4426A603.80508@gmail.com> References: <4426A603.80508@gmail.com> Message-ID: On Sun, 26 Mar 2006, Beat Arnet wrote: > Dear all, > > When trying to open the serial port, I sometimes (not always) run into > the following exception (when opening the serialPort): > > Error 0x5 at /home/bob/foo/tar/rxtx-2.1-7/build/../src/termios.c(860): > Access is > denied. > > java.lang.UnsatisfiedLinkError: native_psmisc_report_owner > at gnu.io.CommPortIdentifier.native_psmisc_report_owner(Native > Method) > at gnu.io.CommPortIdentifier.open(CommPortIdentifier.java:354) > at codeskin.tools.CLLoader.open(CLLoader.java:79) > at codeskin.tools.C2000Programmer.run(C2000Programmer.java:220) > at java.lang.Thread.run(Unknown Source) > > Is this the type of error where I should just try to open the port again, > or can it be avoided? > Hi Beat We did a second build of rxtx 2.1-7 to resolve that unsatisfied link error. It should work now. rxtx is trying to tell you it thinks someone else has the serial port open. You can try to open the port again but maybe you already have a copy of the program running when it happens? ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7r2.zip fixed build. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sun Mar 26 11:44:23 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 26 Mar 2006 11:44:23 -0700 (MST) Subject: [Rxtx] RXTX spec file (fwd) Message-ID: This is probably interesting for fedora/suse users. ---------- Forwarded message ---------- Date: Sun, 26 Mar 2006 16:25:45 +0200 To: taj at www.linux.org.uk Subject: RXTX spec file I send you this spec file which allows to create a RPM for Fedora 4, 5 (x86, x86_64) with Java Sun. -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: rxtx.spec Url: http://mailman.qbang.org/pipermail/rxtx/attachments/20060326/6c7b6af6/rxtx-0021.pl From tjarvi at qbang.org Sun Mar 26 23:42:59 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 26 Mar 2006 23:42:59 -0700 (MST) Subject: [Rxtx] Upcomming events. Message-ID: This Wednesday we will be announcing a new "Maintainer" for the rxtx project. The position is more like neutral leader. I wont be going away or doing less. This is just the right thing to do as it turns out the two people with CVS write access will be at the same company. We need a third and we need neutrality. The maintainer will have final say in any conflict and will try to be neutral. It will be open for discussion. Then we will do it :) I'll still do most of the footwork I do now. But. I'm falling behind. I should have gone through the mail-list and posted the next round of changes this weekend. I'm packing to move and its going so so - 13 years of toys collected. I suspect there will be a dead period on my part (a couple weeks) comming up. But if you get it on the mail-list, we will get it in if there are no objections. I may well not be reading the mail-list during this period as I look for a house and many other things. I hope everyone will help out. Thanks -- Trent Jarvi tjarvi at qbang.org From mahmoud_hadad at yahoo.com Sun Mar 26 07:31:19 2006 From: mahmoud_hadad at yahoo.com (ronan nick) Date: Sun, 26 Mar 2006 06:31:19 -0800 (PST) Subject: [Rxtx] a question about the COMM API Message-ID: <20060326143119.54919.qmail@web60014.mail.yahoo.com> hi, i was intrested in knowing how i can communicate with my internal modem using java? for example if i want to make a phone dialer application or a caller id application where should i be looking at? and as i understood the COMM API is for devices that is attached to the computer through serial ports. --------------------------------- New Yahoo! Messenger with Voice. Call regular phones from your PC and save big. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060326/ce8329f0/attachment-0023.html From dmarkman at mac.com Mon Mar 20 00:20:43 2006 From: dmarkman at mac.com (Dmitry Markman) Date: Mon, 20 Mar 2006 02:20:43 -0500 Subject: [Rxtx] Mac OS X RXTX java installer In-Reply-To: References: <07D0DE29-BA32-4CFE-B036-66BC6423D385@buechse.de> <441AE3E0.2030503@willicon.de> <12531986.1142622114996.JavaMail.dmarkman@mac.com> <441B2674.9010409@willicon.de> <13577405.1142634732776.JavaMail.dmarkman@mac.com> <441B4182.8010407@willicon.de> <92CD0D6C-5BE8-426E-A46D-99452059FF49@mac.com> <441BBB2D.8030305@willicon.de> <441C4088.5090905@willicon.de> Message-ID: <64BC1E23-FDDE-4CE6-8863-CFC881CBC224@mac.com> Hi all I put RXTX installer that will install everything (and will create / var/lock if necessary and add user to the uucp group) for mac os x from Java into the rxtx's CVS repository it could be easily modified to install files for any platform it uses Greg Guerin's AuthKit for authentication and authorization Greg released that kit under artistic license, so Trent, please take a look we, probably, can negotiate license with Greg if it's necessary Greg's AuthKit could be downloaded from http://www.amug.org/~glguerin/ sw/#authkit Michael Hall (mikehall at spacestar dot net) had a suggestion to make implementation of the jaas LoginModule based on Greg's AuthKit (his modification of the Greg's AuthKit could be found at http:// www.spacestar.net/users/mikehall/authkit.dmg) but Michael's AuthKitLoginModule does only half a job: it does authenticate but it can not run any external unix process in privileged mode (at least I wasn't able to do so) possible explanation could be found in conversation between Greg and Michael at Apple's java-dev list (look for archives) so I didn't use jaas API for rxtxinstaller I created folder MacOSX in the contrib folder comment 1. if you want to run that installer as standalone application all you need that RXTXInstaller.jar 2. if you want to use webstart you have to add Greg's libAuthKit.jnilib to the mac os x's resources in theory RXTXInstaller.jar doesn't need it, but there is a problem with loading libAuthKit.jnilib from webstart authkit uses loadLibrary method to load library and it failed (from webstart) for standalone application I extract libAuthKit.jnilib from the RXTXInstaller.jar and put it into the /Library/Java/Extensions or ~/Library/Java/Extensions folder that file will be deleted after installer quit unfortunately I didn't have time to put documentation there but it is mostly self-explanatory I took installer code from my gl4java installer that I did about 3 years ago (with small modifications) it would be very nice if Apple will release LoginModule that really will do the job (com.apple.security.auth.module package????? ) (UnixLoginModule is pretty useless) From lyon at docjava.com Mon Mar 20 06:34:39 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Mon, 20 Mar 2006 08:34:39 -0500 Subject: [Rxtx] Mac OS X RXTX java installer In-Reply-To: <64BC1E23-FDDE-4CE6-8863-CFC881CBC224@mac.com> References: <07D0DE29-BA32-4CFE-B036-66BC6423D385@buechse.de> <441AE3E0.2030503@willicon.de> <12531986.1142622114996.JavaMail.dmarkman@mac.com> <441B2674.9010409@willicon.de> <13577405.1142634732776.JavaMail.dmarkman@mac.com> <441B4182.8010407@willicon.de> <92CD0D6C-5BE8-426E-A46D-99452059FF49@mac.com> <441BBB2D.8030305@willicon.de> <441C4088.5090905@willicon.de> <64BC1E23-FDDE-4CE6-8863-CFC881CBC224@mac.com> Message-ID: Hi Dimitry, This sounds like great work. Just a couple of questions; After the check out of the CVS files, using: setenv CVSROOT :pserver:anonymous at cvs.milestonesolutions.com:/usr/local/cvsroot 53 8:28 setenv PASSWORD mousy 54 8:29 cvs login 55 8:29 cvs checkout rxtx-devel I cd'd over to: rxtx-devel/MACOSX_IDE And found: CVS/ CW/ ForPackageMaker/ PB/ Where is the installer? Thanks! - Doug From tjarvi at qbang.org Mon Mar 20 06:39:37 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 20 Mar 2006 06:39:37 -0700 (MST) Subject: [Rxtx] Mac OS X RXTX java installer In-Reply-To: References: <07D0DE29-BA32-4CFE-B036-66BC6423D385@buechse.de> <441AE3E0.2030503@willicon.de> <12531986.1142622114996.JavaMail.dmarkman@mac.com> <441B2674.9010409@willicon.de> <13577405.1142634732776.JavaMail.dmarkman@mac.com> <441B4182.8010407@willicon.de> <92CD0D6C-5BE8-426E-A46D-99452059FF49@mac.com> <441BBB2D.8030305@willicon.de> <441C4088.5090905@willicon.de> <64BC1E23-FDDE-4CE6-8863-CFC881CBC224@mac.com> Message-ID: On Mon, 20 Mar 2006, Dr. Douglas Lyon wrote: > Hi Dimitry, > This sounds like great work. Just a couple of questions; > After the check out of the CVS files, using: > setenv CVSROOT > :pserver:anonymous at cvs.milestonesolutions.com:/usr/local/cvsroot > 53 8:28 setenv PASSWORD mousy > 54 8:29 cvs login > 55 8:29 cvs checkout rxtx-devel Hi Doug You want "cvs checkout -r commapi-0-0-1 rxtx-devel" to get RXTX 2.1 The default branch is rxtx 2.0 which isn't very active right now. -- Trent Jarvi tjarvi at qbang.org From lyon at docjava.com Mon Mar 20 07:05:44 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Mon, 20 Mar 2006 09:05:44 -0500 Subject: [Rxtx] Mac OS X RXTX java installer In-Reply-To: References: <07D0DE29-BA32-4CFE-B036-66BC6423D385@buechse.de> <441AE3E0.2030503@willicon.de> <12531986.1142622114996.JavaMail.dmarkman@mac.com> <441B2674.9010409@willicon.de> <13577405.1142634732776.JavaMail.dmarkman@mac.com> <441B4182.8010407@willicon.de> <92CD0D6C-5BE8-426E-A46D-99452059FF49@mac.com> <441BBB2D.8030305@willicon.de> <441C4088.5090905@willicon.de> <64BC1E23-FDDE-4CE6-8863-CFC881CBC224@mac.com> Message-ID: Hi Trent, Thanks for the info on the CVS checkout procedure. I did that and am still not sure where the installer is. Here is what I have: cd MACOSX_IDE/ p4.docjava.com{lyon}121: ls CVS/ ForPackageMaker/ PB/ p4.docjava.com{lyon}122: find . | more . ./ForPackageMaker ./ForPackageMaker/RXTX.pkg.sit.hqx ./ForPackageMaker/Resources ./ForPackageMaker/Resources/ReadMe.rtf ./ForPackageMaker/Resources/Welcome.rtf ./ForPackageMaker/Resources/CVS ./ForPackageMaker/Resources/CVS/Entries ./ForPackageMaker/Resources/CVS/Repository ./ForPackageMaker/Resources/CVS/Tag ./ForPackageMaker/Resources/CVS/Root ./ForPackageMaker/Resources/preinstall ./ForPackageMaker/Resources/License.rtf ./ForPackageMaker/Resources/preupgrade ./ForPackageMaker/RXTX.pmsp ./ForPackageMaker/CVS ./ForPackageMaker/CVS/Entries ./ForPackageMaker/CVS/Repository ./ForPackageMaker/CVS/Entries.Log ./ForPackageMaker/CVS/Tag ./ForPackageMaker/CVS/Root ./ForPackageMaker/RXTX_Tiger.pkg.sitx.hqx ./ForPackageMaker/RXTX_Jag.pkg.sit.hqx ./ForPackageMaker/Install ./ForPackageMaker/Install/CVS ./ForPackageMaker/Install/CVS/Entries ./ForPackageMaker/Install/CVS/Repository ./ForPackageMaker/Install/CVS/Tag ./ForPackageMaker/Install/CVS/Root ./ForPackageMaker/Install/Library ./ForPackageMaker/Install/Library/CVS ./ForPackageMaker/Install/Library/CVS/Entries ./ForPackageMaker/Install/Library/CVS/Repository ./ForPackageMaker/Install/Library/CVS/Tag ./ForPackageMaker/Install/Library/CVS/Root ./ForPackageMaker/Install/Library/Java ./ForPackageMaker/Install/Library/Java/Extensions ./ForPackageMaker/Install/Library/Java/Extensions/RXTXcomm.jar ./ForPackageMaker/Install/Library/Java/Extensions/CVS ./ForPackageMaker/Install/Library/Java/Extensions/CVS/Entries ./ForPackageMaker/Install/Library/Java/Extensions/CVS/Repository ./ForPackageMaker/Install/Library/Java/Extensions/CVS/Tag ./ForPackageMaker/Install/Library/Java/Extensions/CVS/Root ./ForPackageMaker/Install/Library/Java/Extensions/librxtxSerial.jnilib ./ForPackageMaker/Install/Library/Java/CVS ./ForPackageMaker/Install/Library/Java/CVS/Entries ./ForPackageMaker/Install/Library/Java/CVS/Repository ./ForPackageMaker/Install/Library/Java/CVS/Entries.Log ./ForPackageMaker/Install/Library/Java/CVS/Tag ./ForPackageMaker/Install/Library/Java/CVS/Root ./ForPackageMaker/RXTX_Tiger.pmproj.sitx.hqx ./CVS ./CVS/Entries ./CVS/Repository ./CVS/Entries.Log ./CVS/Tag ./CVS/Root ./PB ./PB/LibSerialUniversal.xcodeproj.sitx.hqx ./PB/CVS ./PB/CVS/Entries ./PB/CVS/Repository ./PB/CVS/Entries.Log ./PB/CVS/Tag ./PB/CVS/Root ./PB/LibSerial.pbproj.sit.hqx ./PB/startpoint.c ./PB/config.h What is the procedure to run this installer? Do we need a README in: /rxtx-devel/MACOSX_IDE Here is what we have: CVS/ ForPackageMaker/ PB/ Thanks! - DL >On Mon, 20 Mar 2006, Dr. Douglas Lyon wrote: > >>Hi Dimitry, >>This sounds like great work. Just a couple of questions; >>After the check out of the CVS files, using: >>setenv CVSROOT >>:pserver:anonymous at cvs.milestonesolutions.com:/usr/local/cvsroot >> 53 8:28 setenv PASSWORD mousy >> 54 8:29 cvs login >> 55 8:29 cvs checkout rxtx-devel > >Hi Doug > >You want "cvs checkout -r commapi-0-0-1 rxtx-devel" to get RXTX 2.1 >The default branch is rxtx 2.0 which isn't very active right now. > >-- >Trent Jarvi >tjarvi at qbang.org From tjarvi at qbang.org Mon Mar 20 07:25:30 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 20 Mar 2006 07:25:30 -0700 (MST) Subject: [Rxtx] Mac OS X RXTX java installer In-Reply-To: References: <07D0DE29-BA32-4CFE-B036-66BC6423D385@buechse.de> <441AE3E0.2030503@willicon.de> <12531986.1142622114996.JavaMail.dmarkman@mac.com> <441B2674.9010409@willicon.de> <13577405.1142634732776.JavaMail.dmarkman@mac.com> <441B4182.8010407@willicon.de> <92CD0D6C-5BE8-426E-A46D-99452059FF49@mac.com> <441BBB2D.8030305@willicon.de> <441C4088.5090905@willicon.de> <64BC1E23-FDDE-4CE6-8863-CFC881CBC224@mac.com> Message-ID: On Mon, 20 Mar 2006, Dr. Douglas Lyon wrote: > Hi Trent, > Thanks for the info on the CVS checkout procedure. > I did that and am still not sure where the installer is. Hi Doug It does look like it was not cvs committed. There is no rxtx-devel/contrib/MacOSX directory in there at the moment. It was mentioned that it was put under contrib. -- Trent Jarvi tjarvi at qbang.org From dmarkman at mac.com Mon Mar 20 07:29:56 2006 From: dmarkman at mac.com (Dmitry Markman) Date: Mon, 20 Mar 2006 09:29:56 -0500 Subject: [Rxtx] Mac OS X RXTX java installer In-Reply-To: References: <07D0DE29-BA32-4CFE-B036-66BC6423D385@buechse.de> <441AE3E0.2030503@willicon.de> <12531986.1142622114996.JavaMail.dmarkman@mac.com> <441B2674.9010409@willicon.de> <13577405.1142634732776.JavaMail.dmarkman@mac.com> <441B4182.8010407@willicon.de> <92CD0D6C-5BE8-426E-A46D-99452059FF49@mac.com> <441BBB2D.8030305@willicon.de> <441C4088.5090905@willicon.de> <64BC1E23-FDDE-4CE6-8863-CFC881CBC224@mac.com> Message-ID: <6054EB4E-F7E0-4A9C-BDDA-D582D6D8826F@mac.com> you can find it in the rxtx-devel/contrib folder On Mar 20, 2006, at 9:05 AM, Dr. Douglas Lyon wrote: > Hi Trent, > Thanks for the info on the CVS checkout procedure. > I did that and am still not sure where the installer is. > Here is what I have: > cd MACOSX_IDE/ > p4.docjava.com{lyon}121: ls > CVS/ ForPackageMaker/ PB/ > p4.docjava.com{lyon}122: find . | more > . > ./ForPackageMaker > ./ForPackageMaker/RXTX.pkg.sit.hqx > ./ForPackageMaker/Resources > ./ForPackageMaker/Resources/ReadMe.rtf > ./ForPackageMaker/Resources/Welcome.rtf > ./ForPackageMaker/Resources/CVS > ./ForPackageMaker/Resources/CVS/Entries > ./ForPackageMaker/Resources/CVS/Repository > ./ForPackageMaker/Resources/CVS/Tag > ./ForPackageMaker/Resources/CVS/Root > ./ForPackageMaker/Resources/preinstall > ./ForPackageMaker/Resources/License.rtf > ./ForPackageMaker/Resources/preupgrade > ./ForPackageMaker/RXTX.pmsp > ./ForPackageMaker/CVS > ./ForPackageMaker/CVS/Entries > ./ForPackageMaker/CVS/Repository > ./ForPackageMaker/CVS/Entries.Log > ./ForPackageMaker/CVS/Tag > ./ForPackageMaker/CVS/Root > ./ForPackageMaker/RXTX_Tiger.pkg.sitx.hqx > ./ForPackageMaker/RXTX_Jag.pkg.sit.hqx > ./ForPackageMaker/Install > ./ForPackageMaker/Install/CVS > ./ForPackageMaker/Install/CVS/Entries > ./ForPackageMaker/Install/CVS/Repository > ./ForPackageMaker/Install/CVS/Tag > ./ForPackageMaker/Install/CVS/Root > ./ForPackageMaker/Install/Library > ./ForPackageMaker/Install/Library/CVS > ./ForPackageMaker/Install/Library/CVS/Entries > ./ForPackageMaker/Install/Library/CVS/Repository > ./ForPackageMaker/Install/Library/CVS/Tag > ./ForPackageMaker/Install/Library/CVS/Root > ./ForPackageMaker/Install/Library/Java > ./ForPackageMaker/Install/Library/Java/Extensions > ./ForPackageMaker/Install/Library/Java/Extensions/RXTXcomm.jar > ./ForPackageMaker/Install/Library/Java/Extensions/CVS > ./ForPackageMaker/Install/Library/Java/Extensions/CVS/Entries > ./ForPackageMaker/Install/Library/Java/Extensions/CVS/Repository > ./ForPackageMaker/Install/Library/Java/Extensions/CVS/Tag > ./ForPackageMaker/Install/Library/Java/Extensions/CVS/Root > ./ForPackageMaker/Install/Library/Java/Extensions/librxtxSerial.jnilib > ./ForPackageMaker/Install/Library/Java/CVS > ./ForPackageMaker/Install/Library/Java/CVS/Entries > ./ForPackageMaker/Install/Library/Java/CVS/Repository > ./ForPackageMaker/Install/Library/Java/CVS/Entries.Log > ./ForPackageMaker/Install/Library/Java/CVS/Tag > ./ForPackageMaker/Install/Library/Java/CVS/Root > ./ForPackageMaker/RXTX_Tiger.pmproj.sitx.hqx > ./CVS > ./CVS/Entries > ./CVS/Repository > ./CVS/Entries.Log > ./CVS/Tag > ./CVS/Root > ./PB > ./PB/LibSerialUniversal.xcodeproj.sitx.hqx > ./PB/CVS > ./PB/CVS/Entries > ./PB/CVS/Repository > ./PB/CVS/Entries.Log > ./PB/CVS/Tag > ./PB/CVS/Root > ./PB/LibSerial.pbproj.sit.hqx > ./PB/startpoint.c > ./PB/config.h > > What is the procedure to run this installer? > Do we need a README in: > /rxtx-devel/MACOSX_IDE > Here is what we have: > CVS/ ForPackageMaker/ PB/ > > > Thanks! > - DL > >> On Mon, 20 Mar 2006, Dr. Douglas Lyon wrote: >> >>> Hi Dimitry, >>> This sounds like great work. Just a couple of questions; >>> After the check out of the CVS files, using: >>> setenv CVSROOT :pserver:anonymous at cvs.milestonesolutions.com:/usr/ >>> local/cvsroot >>> 53 8:28 setenv PASSWORD mousy >>> 54 8:29 cvs login >>> 55 8:29 cvs checkout rxtx-devel >> >> Hi Doug >> >> You want "cvs checkout -r commapi-0-0-1 rxtx-devel" to get RXTX 2.1 >> The default branch is rxtx 2.0 which isn't very active right now. >> >> -- >> Trent Jarvi >> tjarvi at qbang.org > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx Dmitry Markman From mikehall at spacestar.net Mon Mar 20 05:25:25 2006 From: mikehall at spacestar.net (Michael Hall) Date: Mon, 20 Mar 2006 06:25:25 -0600 Subject: [Rxtx] Re: Mac OS X RXTX java installer In-Reply-To: <64BC1E23-FDDE-4CE6-8863-CFC881CBC224@mac.com> References: <07D0DE29-BA32-4CFE-B036-66BC6423D385@buechse.de> <441AE3E0.2030503@willicon.de> <12531986.1142622114996.JavaMail.dmarkman@mac.com> <441B2674.9010409@willicon.de> <13577405.1142634732776.JavaMail.dmarkman@mac.com> <441B4182.8010407@willicon.de> <92CD0D6C-5BE8-426E-A46D-99452059FF49@mac.com> <441BBB2D.8030305@willicon.de> <441C4088.5090905@willicon.de> <64BC1E23-FDDE-4CE6-8863-CFC881CBC224@mac.com> Message-ID: <247EB61F-5CD1-4132-89A2-FC105B6CF9A5@spacestar.net> On Mar 20, 2006, at 1:20 AM, Dmitry Markman wrote: > > Michael Hall (mikehall at spacestar dot net) had a suggestion to > make implementation of the jaas LoginModule > based on Greg's AuthKit > (his modification of the Greg's AuthKit could be found at http:// > www.spacestar.net/users/mikehall/authkit.dmg) > but Michael's AuthKitLoginModule does only half a job: > it does authenticate > but it can not run any external unix process in privileged mode (at > least I wasn't able to do so) If you got it working directly with Greg's the point is moot. But to clarify it anyhow. The login module does not allow you to do anything anything privileged on return as was explained by Greg. You need to work with a separate privileged process using the execPrivileged method of his API. I assume you did something similar although I haven't looked at how you are using it yet. I allowed instead for a action to be performed at the same time you login/authenticate,this... System.setProperty("authkit.action","/usr/bin/id"); just before this... lc.login(); To clarify, safely ignored as you are already complete. Mike Hall mikehall at spacestar dot net http://www.spacestar.net/users/mikehall http://sourceforge.net/projects/macnative -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2427 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20060320/f6e18202/smime-0026.bin From dmarkman at mac.com Mon Mar 20 07:36:47 2006 From: dmarkman at mac.com (Dmitry Markman) Date: Mon, 20 Mar 2006 09:36:47 -0500 Subject: [Rxtx] Re: Mac OS X RXTX java installer In-Reply-To: <247EB61F-5CD1-4132-89A2-FC105B6CF9A5@spacestar.net> References: <07D0DE29-BA32-4CFE-B036-66BC6423D385@buechse.de> <441AE3E0.2030503@willicon.de> <12531986.1142622114996.JavaMail.dmarkman@mac.com> <441B2674.9010409@willicon.de> <13577405.1142634732776.JavaMail.dmarkman@mac.com> <441B4182.8010407@willicon.de> <92CD0D6C-5BE8-426E-A46D-99452059FF49@mac.com> <441BBB2D.8030305@willicon.de> <441C4088.5090905@willicon.de> <64BC1E23-FDDE-4CE6-8863-CFC881CBC224@mac.com> <247EB61F-5CD1-4132-89A2-FC105B6CF9A5@spacestar.net> Message-ID: Hi, Michael all I have to do is to run some shell script I tried to use your action mechanism and it worked great so I just System.setProperty ("authkit.action","" ) and after that I even don't need to run anything like subject.doAs.... but after few thoughts I choose to use plain Greg's approach, because in that case I don't have to deal with various java's configurations files and therefore to use 2-3 -D parameters in the java command line especially it's useful for java web start (it's so fragile :-( ) thanks for the great job On Mar 20, 2006, at 7:25 AM, Michael Hall wrote: > > On Mar 20, 2006, at 1:20 AM, Dmitry Markman wrote: >> >> Michael Hall (mikehall at spacestar dot net) had a suggestion to >> make implementation of the jaas LoginModule >> based on Greg's AuthKit >> (his modification of the Greg's AuthKit could be found at http:// >> www.spacestar.net/users/mikehall/authkit.dmg) >> but Michael's AuthKitLoginModule does only half a job: >> it does authenticate >> but it can not run any external unix process in privileged mode >> (at least I wasn't able to do so) > > If you got it working directly with Greg's the point is moot. > > But to clarify it anyhow. > The login module does not allow you to do anything anything > privileged on return as was explained by Greg. You need to work > with a separate privileged process using the execPrivileged method > of his API. I assume you did something similar although I haven't > looked at how you are using it yet. > I allowed instead for a action to be performed at the same time you > login/authenticate,this... > System.setProperty("authkit.action","/usr/bin/id"); > just before this... > lc.login(); > To clarify, safely ignored as you are already complete. > > Mike Hall mikehall at spacestar dot net > http://www.spacestar.net/users/mikehall > http://sourceforge.net/projects/macnative > > > Dmitry Markman From dmarkman at mac.com Mon Mar 20 07:44:45 2006 From: dmarkman at mac.com (Dmitry Markman) Date: Mon, 20 Mar 2006 09:44:45 -0500 Subject: [Rxtx] Mac OS X RXTX java installer In-Reply-To: References: <07D0DE29-BA32-4CFE-B036-66BC6423D385@buechse.de> <441AE3E0.2030503@willicon.de> <12531986.1142622114996.JavaMail.dmarkman@mac.com> <441B2674.9010409@willicon.de> <13577405.1142634732776.JavaMail.dmarkman@mac.com> <441B4182.8010407@willicon.de> <92CD0D6C-5BE8-426E-A46D-99452059FF49@mac.com> <441BBB2D.8030305@willicon.de> <441C4088.5090905@willicon.de> <64BC1E23-FDDE-4CE6-8863-CFC881CBC224@mac.com> Message-ID: it's in the commapi-0-0-1 branch I tested it right now: cvs co -r commapi-0-0-1 rxtx-devel and I got everything On Mar 20, 2006, at 9:25 AM, Trent Jarvi wrote: > On Mon, 20 Mar 2006, Dr. Douglas Lyon wrote: > >> Hi Trent, >> Thanks for the info on the CVS checkout procedure. >> I did that and am still not sure where the installer is. > > Hi Doug > > It does look like it was not cvs committed. There is no rxtx-devel/ > contrib/MacOSX directory in there at the moment. It was mentioned > that it was put under contrib. > > -- > Trent Jarvi > tjarvi at qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx Dmitry Markman From tjarvi at qbang.org Mon Mar 20 07:52:57 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 20 Mar 2006 07:52:57 -0700 (MST) Subject: [Rxtx] Mac OS X RXTX java installer In-Reply-To: References: <07D0DE29-BA32-4CFE-B036-66BC6423D385@buechse.de> <441AE3E0.2030503@willicon.de> <12531986.1142622114996.JavaMail.dmarkman@mac.com> <441B2674.9010409@willicon.de> <13577405.1142634732776.JavaMail.dmarkman@mac.com> <441B4182.8010407@willicon.de> <92CD0D6C-5BE8-426E-A46D-99452059FF49@mac.com> <441BBB2D.8030305@willicon.de> <441C4088.5090905@willicon.de> <64BC1E23-FDDE-4CE6-8863-CFC881CBC224@mac.com> Message-ID: On Mon, 20 Mar 2006, Dmitry Markman wrote: > it's in the commapi-0-0-1 branch > > I tested it right now: > cvs co -r commapi-0-0-1 rxtx-devel > > and I got everything > A fresh checkout worked. Here is a copy of the tree (just the installer bits) ftp://ftp.qbang.org/pub/rxtx/MacOSX-installer.zip -- Trent Jarvi tjarvi at qbang.org From lyon at docjava.com Mon Mar 20 08:08:26 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Mon, 20 Mar 2006 10:08:26 -0500 Subject: [Rxtx] Mac OS X RXTX java installer In-Reply-To: References: <07D0DE29-BA32-4CFE-B036-66BC6423D385@buechse.de> <441AE3E0.2030503@willicon.de> <12531986.1142622114996.JavaMail.dmarkman@mac.com> <441B2674.9010409@willicon.de> <13577405.1142634732776.JavaMail.dmarkman@mac.com> <441B4182.8010407@willicon.de> <92CD0D6C-5BE8-426E-A46D-99452059FF49@mac.com> <441BBB2D.8030305@willicon.de> <441C4088.5090905@willicon.de> <64BC1E23-FDDE-4CE6-8863-CFC881CBC224@mac.com> Message-ID: Hi All, Is the Auth package able to work properly on non Mac OS's? It was not clear from the doc or download. Thanks! - Doug From dmarkman at mac.com Mon Mar 20 08:15:22 2006 From: dmarkman at mac.com (Dmitry Markman) Date: Mon, 20 Mar 2006 10:15:22 -0500 Subject: [Rxtx] Mac OS X RXTX java installer In-Reply-To: References: <07D0DE29-BA32-4CFE-B036-66BC6423D385@buechse.de> <441AE3E0.2030503@willicon.de> <12531986.1142622114996.JavaMail.dmarkman@mac.com> <441B2674.9010409@willicon.de> <13577405.1142634732776.JavaMail.dmarkman@mac.com> <441B4182.8010407@willicon.de> <92CD0D6C-5BE8-426E-A46D-99452059FF49@mac.com> <441BBB2D.8030305@willicon.de> <441C4088.5090905@willicon.de> <64BC1E23-FDDE-4CE6-8863-CFC881CBC224@mac.com> Message-ID: <217312D8-CCCA-4859-ABA6-32DF1CC817B9@mac.com> thanks Trent, for putting it on ftp server On Mar 20, 2006, at 9:52 AM, Trent Jarvi wrote: > A fresh checkout worked. Here is a copy of the tree (just the > installer bits) > > ftp://ftp.qbang.org/pub/rxtx/MacOSX-installer.zip > Dmitry Markman From dmarkman at mac.com Mon Mar 20 09:14:03 2006 From: dmarkman at mac.com (Dmitry Markman) Date: Mon, 20 Mar 2006 11:14:03 -0500 Subject: [Rxtx] Mac OS X RXTX java installer In-Reply-To: References: <07D0DE29-BA32-4CFE-B036-66BC6423D385@buechse.de> <441AE3E0.2030503@willicon.de> <12531986.1142622114996.JavaMail.dmarkman@mac.com> <441B2674.9010409@willicon.de> <13577405.1142634732776.JavaMail.dmarkman@mac.com> <441B4182.8010407@willicon.de> <92CD0D6C-5BE8-426E-A46D-99452059FF49@mac.com> <441BBB2D.8030305@willicon.de> <441C4088.5090905@willicon.de> <64BC1E23-FDDE-4CE6-8863-CFC881CBC224@mac.com> Message-ID: <4DEBA6F0-DA45-4E84-823E-1F1AC48BDCCC@mac.com> no it will work only on mac os x however it's harmless to run it on other platform if you want to use it for other platform you have to do the following (I'll do it for linux) 1. modify RXTXInstaller class method public static RXTXInstaller getInstance() public static RXTXInstaller getInstance() { String osName = System.getProperty("os.name").toLowerCase(); if(osName.startsWith("mac")){ return new gnu.io.installer.macosx.MACOSXRXTXInstaller(); } else if(osName.startsWith("windows")){ return new gnu.io.installer.windows.WindowsRXTXInstaller(); }else if(osName.startsWith("linux")){ return new gnu.io.installer.linux.LinuxRXTXInstaller(); } return null; } 2. create folder gnu/io/installer/linux/ 3. create class Linux386RXTXInstaller package gnu.io.installer.linux; import java.io.File; public class Linux386RXTXInstaller extends gnu.io.installer.RXTXInstaller{ public Linux386RXTXInstaller(){ createJarFolder(); createLibFolder(); addJarResource("RXTXcomm.jar","/gnu/io/installer/resources/ linux/jar/RXTXcomm.dat"); addLibResource("librxtxSerial.so","/gnu/io/installer/ resources/linux/lib/librxtxSerial.so"); } protected void createJarFolder(){ String javaHome = System.getProperty("java.home"); char separator = File.separatorChar; jarFolder = new File(javaHome+separator+"lib"+separator+"ext"); } protected void createLibFolder(){ String javaHome = System.getProperty("java.home"); char separator = File.separatorChar; libFolder = new File(javaHome+separator+"bin"); } public void runPreProcess() {} //put here some action you need public void runPostProcess() {} //put here some action you need } 4. create folder /gnu/io/installer/resources/linux/jar and put there linux's version of RXTXcomm.dat (which is renamed RXTXcomm.jar) 5. create folder /gnu/io/installer/resources/linux/lib and put there linux's version of librxtxSerial. so 6. make sure that RXTXInstaller.jar has the following items: /gnu/io/installer/resources/linux/jar/RXTXcomm.jar /gnu/io/installer/resources/linux/lib/librxtxSerial.so 7. modify file installer.pref: jar file RXTXInstaller.jar must have the following item /gnu/io/installer/installer.pref that's basically it for windows you have to do the similar things: just replace linux to windows and librxtxSerial.so to rxtxSerial.dll and create appropriate gnu.io.installer.windows.WindowsRXTXInstaller class package gnu.io.installer.windows; import java.io.File; public class WindowsRXTXInstaller extends gnu.io.installer.RXTXInstaller{ public WindowsRXTXInstaller(){ createJarFolder(); createLibFolder(); addJarResource("RXTXcomm.jar","/gnu/io/installer/resources/ windows/jar/RXTXcomm.dat"); addLibResource("librxtxSerial.so","/gnu/io/installer/ resources/windows/lib/rxtxSerial.dll"); } protected void createJarFolder(){ String javaHome = System.getProperty("java.home"); char separator = File.separatorChar; jarFolder = new File(javaHome+separator+"lib"+separator+"ext"); } protected void createLibFolder(){ String javaHome = System.getProperty("java.home"); char separator = File.separatorChar; libFolder = new File(javaHome+separator+"bin"); } public void runPreProcess() {} //put here some action you need public void runPostProcess() {} //put here some action you need } installer.pref will look like On Mar 20, 2006, at 10:08 AM, Dr. Douglas Lyon wrote: > Hi All, > Is the Auth package able to work properly on > non Mac OS's? > It was not clear from the doc or download. > > Thanks! > - Doug > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx Dmitry Markman From joachim at buechse.de Mon Mar 20 10:49:06 2006 From: joachim at buechse.de (Joachim Buechse) Date: Mon, 20 Mar 2006 18:49:06 +0100 Subject: [Rxtx] BUG: Lock file stays even if port opening fails Message-ID: This was only tested on MacOSX but looking at the code, it should be true for all systems that use lock_uucp. I am opening a port which can not be opened (dialup port of a telephone paired via bluetooth but currently not reachable). The lock file is created and stays arround, even though the port open failed. After looking a bit through the code (of 2.17), I really wonder if it wouldn't be a good idea to make the "locking" an explicit operation called from the java code. This would certainly simplify the generation of meaningfull exceptions (and java based debugging). Maybe even the handling of "preopened" ports should be in the Java part of the lib (again for java based debugging puposes). That beeing said, I have no idea if this would be possible for the 2.07 implementation. Regards, Joachim From tjarvi at qbang.org Mon Mar 20 11:24:22 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 20 Mar 2006 11:24:22 -0700 (MST) Subject: [Rxtx] BUG: Lock file stays even if port opening fails In-Reply-To: References: Message-ID: On Mon, 20 Mar 2006, Joachim Buechse wrote: > This was only tested on MacOSX but looking at the code, it should be true > for all systems that use lock_uucp. > > I am opening a port which can not be opened (dialup port of a telephone > paired via bluetooth but currently not reachable). The lock file is > created and stays arround, even though the port open failed. > > > After looking a bit through the code (of 2.17), I really wonder if it > wouldn't be a good idea to make the "locking" an explicit operation > called from the java code. This would certainly simplify the generation > of meaningfull exceptions (and java based debugging). > Maybe even the handling of "preopened" ports should be in the Java part > of the lib (again for java based debugging puposes). That beeing said, I > have no idea if this would be possible for the 2.07 implementation. > > Regards, Hi Joachim It should be possible in the 2.0-7 implementation too. The calls to RXTXPort.java would not change. We would just do more there Moving more of that logic into Java would be better as many people don't like to look at C code. There is a liblockdev on most Linux distros that can do most of the C code and would be easier to use. The problem is embeded devices will not have that library. The preopened port code has not been really tested. That was a last minute request in a product cycle. I expect it will be tested this year though. As I recall, some devices really do not like CD raising on open. The preopened ports then allow people to mess around in java without power cycling the devices or losing data. -- Trent Jarvi tjarvi at qbang.org From joachim at buechse.de Mon Mar 20 12:01:08 2006 From: joachim at buechse.de (Joachim Buechse) Date: Mon, 20 Mar 2006 20:01:08 +0100 Subject: [Rxtx] BUG: Lock file stays even if port opening fails In-Reply-To: References: Message-ID: Hi Trent, What is your general feeling about moving code to Java? The last days I have been reading quite a bit of the code and there are several things, that might not work as expected. I'll give you two examples from is_device_locked: if LOCKDIR == /var/spool/locks the directory /var/spool/lock will not be checked. LOCKDIR is not checked for lockfiles with unexpected pefixes While these things have probably never been discovered in production, they are still possibly incorrect implementations. If it was Java code, I would write some unit tests producing the errors that could later be corrected. PS: One could imagine to actually implement the whole lockfile handling in Java using some native routines to get the values required (pid, st_dev, st_rdev, ...). On 20.03.2006, at 19:24, Trent Jarvi wrote: > On Mon, 20 Mar 2006, Joachim Buechse wrote: > >> This was only tested on MacOSX but looking at the code, it should >> be true for all systems that use lock_uucp. >> >> I am opening a port which can not be opened (dialup port of a >> telephone paired via bluetooth but currently not reachable). The >> lock file is created and stays arround, even though the port open >> failed. >> >> >> After looking a bit through the code (of 2.17), I really wonder if >> it wouldn't be a good idea to make the "locking" an explicit >> operation called from the java code. This would certainly simplify >> the generation of meaningfull exceptions (and java based debugging). >> Maybe even the handling of "preopened" ports should be in the Java >> part of the lib (again for java based debugging puposes). That >> beeing said, I have no idea if this would be possible for the 2.07 >> implementation. >> >> Regards, > > Hi Joachim > > It should be possible in the 2.0-7 implementation too. The calls > to RXTXPort.java would not change. We would just do more there > Moving more of that logic into Java would be better as many people > don't like to look at C code. There is a liblockdev on most Linux > distros that can do most of the C code and would be easier to use. > The problem is embeded devices will not have that library. > > The preopened port code has not been really tested. That was a > last minute request in a product cycle. I expect it will be tested > this year though. As I recall, some devices really do not like CD > raising on open. The preopened ports then allow people to mess > around in java without power cycling the devices or losing data. > > -- > Trent Jarvi > tjarvi at qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Mon Mar 20 12:21:02 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 20 Mar 2006 12:21:02 -0700 (MST) Subject: [Rxtx] BUG: Lock file stays even if port opening fails In-Reply-To: References: Message-ID: On Mon, 20 Mar 2006, Joachim Buechse wrote: > Hi Trent, > > What is your general feeling about moving code to Java? The last days I > have been reading quite a bit of the code and there are several things, > that might not work as expected. > > I'll give you two examples from is_device_locked: > > if LOCKDIR == /var/spool/locks the directory /var/spool/lock will not be > checked. > LOCKDIR is not checked for lockfiles with unexpected pefixes > > While these things have probably never been discovered in production, > they are still possibly incorrect implementations. If it was Java code, I > would write some unit tests producing the errors that could later be > corrected. > > PS: One could imagine to actually implement the whole lockfile handling > in Java using some native routines to get the values required (pid, > st_dev, st_rdev, ...). Hi Joachim I like the idea of moving more of the code into java but there are some things to consider. If you break this into multiple JNI calls, the performance will drop considerably during enumeration of ports. We are looking for 256 ports per dev type vs (16? in Sun's 2.0 and fewer types). Its hard to make assumptions. I've seen virtual ports start at /dev/foo100 for instance. It works out to over 7500 ports on Linux if you enable them all. We already trim that back by default. See Linux-all-ports in RXTXCommDriver.java. There are also native libraries that rxtx can link to. If you move too much into Java, linking to 'standard' libraries with distros will break. "configure --enable-liblock=yes" will not be doable. This is probably a favorable way with RedHat, Debian, Suse and others. Thats the right thing to do if there will be rpms, dpkg, .. For those reasons, I think it still make sense to keep it to a minimal ~3 calls to JNI code that we can use for speed and versatility. lock() isLocked(), unlock() perhaps. When I say speed, its more about avoiding crossing the JNI layer multiple times than java vs C performance. With versatility I think liblock is the right way for most but not all (embeded) linux distros. -- Trent Jarvi tjarvi at qbang.org From joachim at buechse.de Mon Mar 20 12:42:04 2006 From: joachim at buechse.de (Joachim Buechse) Date: Mon, 20 Mar 2006 20:42:04 +0100 Subject: [Rxtx] BUG: Lock file stays even if port opening fails In-Reply-To: References: Message-ID: <82C19FE7-DDCB-45B6-B2C9-7606B66F0124@buechse.de> Ok, what about providing a default implementation in Java? The RXTXCommDriver would call a (native) function useNativeLocking and if it returns true, call the native functions for lock() isLocked (), unlock(), else is would use the Java based default implementation. This could possibly be overriden by a property (again for debugging). Joachim On 20.03.2006, at 20:21, Trent Jarvi wrote: > On Mon, 20 Mar 2006, Joachim Buechse wrote: > >> Hi Trent, >> >> What is your general feeling about moving code to Java? The last >> days I have been reading quite a bit of the code and there are >> several things, that might not work as expected. >> >> I'll give you two examples from is_device_locked: >> >> if LOCKDIR == /var/spool/locks the directory /var/spool/lock will >> not be checked. >> LOCKDIR is not checked for lockfiles with unexpected pefixes >> >> While these things have probably never been discovered in >> production, they are still possibly incorrect implementations. If >> it was Java code, I would write some unit tests producing the >> errors that could later be corrected. >> >> PS: One could imagine to actually implement the whole lockfile >> handling in Java using some native routines to get the values >> required (pid, st_dev, st_rdev, ...). > > Hi Joachim > > I like the idea of moving more of the code into java but there are > some things to consider. > > If you break this into multiple JNI calls, the performance will > drop considerably during enumeration of ports. We are looking for > 256 ports per dev type vs (16? in Sun's 2.0 and fewer types). Its > hard to make assumptions. I've seen virtual ports start at /dev/ > foo100 for instance. > > It works out to over 7500 ports on Linux if you enable them all. > We already trim that back by default. See Linux-all-ports in > RXTXCommDriver.java. > > There are also native libraries that rxtx can link to. If you move > too much into Java, linking to 'standard' libraries with distros > will break. "configure --enable-liblock=yes" will not be doable. > This is probably a favorable way with RedHat, Debian, Suse and > others. Thats the right thing to do if there will be rpms, dpkg, .. > > For those reasons, I think it still make sense to keep it to a > minimal ~3 calls to JNI code that we can use for speed and > versatility. lock() isLocked(), unlock() perhaps. When I say > speed, its more about avoiding crossing the JNI layer multiple > times than java vs C performance. With versatility I think liblock > is the right way for most but not all (embeded) linux distros. > > -- > Trent Jarvi > tjarvi at qbang.org > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Mon Mar 20 12:44:47 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 20 Mar 2006 12:44:47 -0700 (MST) Subject: [Rxtx] BUG: Lock file stays even if port opening fails In-Reply-To: <82C19FE7-DDCB-45B6-B2C9-7606B66F0124@buechse.de> References: <82C19FE7-DDCB-45B6-B2C9-7606B66F0124@buechse.de> Message-ID: On Mon, 20 Mar 2006, Joachim Buechse wrote: > Ok, what about providing a default implementation in Java? > > The RXTXCommDriver would call a (native) function useNativeLocking and if > it returns true, call the native functions for lock() isLocked(), > unlock(), else is would use the Java based default implementation. This > could possibly be overriden by a property (again for debugging). > Hi Joachim That would be OK with me. -- Trent Jarvi tjarvi at qbang.org From dmarkman at mac.com Mon Mar 20 22:27:45 2006 From: dmarkman at mac.com (Dmitry Markman) Date: Tue, 21 Mar 2006 00:27:45 -0500 Subject: [Rxtx] binaries request Message-ID: <42702213-C222-4937-A585-7CFB17E47608@mac.com> Hi can somebody send me latest linux and windows binaries, please? or where I can find them (I didn't find them in the latest tareball) I gave up with my cygwin: something wrong I have no idea what java doesn't understand /cygwin/c syntax after I changed makefile it did java part but after that gcc 3.4.4 started to complain I set buffer length to 999 lines but I didn't get beginning of the story something wrong with my 1.4.2_09/include/jni.h gcc doesn't like it anyway I gave up thanks in advance Dmitry Markman -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060320/f8cbc57c/attachment-0026.html From tjarvi at qbang.org Mon Mar 20 22:36:48 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 20 Mar 2006 22:36:48 -0700 (MST) Subject: [Rxtx] binaries request In-Reply-To: <42702213-C222-4937-A585-7CFB17E47608@mac.com> References: <42702213-C222-4937-A585-7CFB17E47608@mac.com> Message-ID: On Tue, 21 Mar 2006, Dmitry Markman wrote: > Hi > can somebody send me latest linux and windows binaries, please? > > or where I can find them (I didn't find them in the latest tareball) > > I gave up with my cygwin: something wrong I have no idea what > java doesn't understand /cygwin/c syntax > after I changed makefile it did java part > but after that gcc 3.4.4 started to complain > I set buffer length to 999 lines but I didn't get beginning of the story > something wrong with my 1.4.2_09/include/jni.h gcc doesn't like it > anyway I gave up > > thanks in advance > Hi Dmitry The bins are here: ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7-bins-r2.zip Here are the files in the zip you want. Jar: rxtx-2.1-7-bins-r2/RXTXcomm.jar Windows: rxtx-2.1-7-bins-r2/Windows/i368-mingw32/rxtxSerial.dll Linux (x86) rxtx-2.1-7-bins-r2/Linux/i686-unknown-linux-gnu/librxtxSerial.so There are others in there including Parallel port support but those are the main ones for testing. -- Trent Jarvi tjarvi at qbang.org From dmarkman at mac.com Mon Mar 20 23:05:59 2006 From: dmarkman at mac.com (Dmitry Markman) Date: Tue, 21 Mar 2006 01:05:59 -0500 Subject: [Rxtx] binaries request In-Reply-To: References: <42702213-C222-4937-A585-7CFB17E47608@mac.com> Message-ID: thank you very much but windows's readme says: rxtxSerial.dll had to be recomopiled to link in missing native methods. should I ignore it? or what? thanks again also I understand that I should use mingw not cygwin I'll try to install mingw On Mar 21, 2006, at 12:36 AM, Trent Jarvi wrote: > On Tue, 21 Mar 2006, Dmitry Markman wrote: > >> Hi >> can somebody send me latest linux and windows binaries, please? >> >> or where I can find them (I didn't find them in the latest tareball) >> >> I gave up with my cygwin: something wrong I have no idea what >> java doesn't understand /cygwin/c syntax >> after I changed makefile it did java part >> but after that gcc 3.4.4 started to complain >> I set buffer length to 999 lines but I didn't get beginning of the >> story >> something wrong with my 1.4.2_09/include/jni.h gcc doesn't like it >> anyway I gave up >> >> thanks in advance >> > > Hi Dmitry > > The bins are here: > > ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7-bins-r2.zip > > Here are the files in the zip you want. > > Jar: > > rxtx-2.1-7-bins-r2/RXTXcomm.jar > > Windows: > > rxtx-2.1-7-bins-r2/Windows/i368-mingw32/rxtxSerial.dll > > Linux (x86) > > rxtx-2.1-7-bins-r2/Linux/i686-unknown-linux-gnu/librxtxSerial.so > > There are others in there including Parallel port support but those > are the main ones for testing. > > -- > Trent Jarvi > tjarvi at qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx Dmitry Markman From tjarvi at qbang.org Mon Mar 20 23:20:33 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 20 Mar 2006 23:20:33 -0700 (MST) Subject: [Rxtx] binaries request In-Reply-To: References: <42702213-C222-4937-A585-7CFB17E47608@mac.com> Message-ID: On Tue, 21 Mar 2006, Dmitry Markman wrote: > thank you very much > > but windows's readme says: > rxtxSerial.dll had to be recomopiled to link in missing native methods. > > should I ignore it? or what? > Hi Dmitry That dll should be OK. r2 is the recompile linked to the missing native method. The readme explains why it was recompiled; fuser.o was not linked into the dll in the first release. -- Trent Jarvi tjarvi at qbang.org From ariantristan at yahoo.com Mon Mar 20 23:55:24 2006 From: ariantristan at yahoo.com (Lambok Sianturi) Date: Mon, 20 Mar 2006 22:55:24 -0800 (PST) Subject: [Rxtx] jvm issue Message-ID: <20060321065524.94779.qmail@web50701.mail.yahoo.com> Hi All, This is my first time to join RxTx mailing list. I thank you all for allowing others to sign in in requests help. I use the latest RxTx lib in Fedora 3 with java version 1.4.2_09 b05. And I got this error: # # An unexpected error has been detected by HotSpot Virtual Machine: # # SIGSEGV (0xb) at pc=0x00bf27f3, pid=2633, tid=3086112448 # # Java VM: Java HotSpot(TM) Client VM (1.4.2_09-b05 mixed mode) # Problematic frame: # C [ld-linux.so.2+0xa7f3] # # An error report file with more information is saved as hs_err_pid2633.log # # If you would like to submit a bug report, please visit: # http://java.sun.com/webapps/bugreport/crash.jsp # ./run.sh: line 3: 2633 Aborted /usr/local/java/bin/java -Djava.library.path=/usr/local/java/jre/lib/ -Djsmsengine.debug=true -classpath jsmsengine.jar:smsgateway.jar:classes12.jar:RXTXcomm.jar:. com.api.sms.SMSServer What is the jvm depedency for the latest library? Can I use 1.4.2_09 b05? Thanks in advance. Arian --------------------------------- Yahoo! Mail Use Photomail to share photos without annoying attachments. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060320/83d58dd7/attachment-0026.html From f.frumento at ngi.it Tue Mar 21 00:21:47 2006 From: f.frumento at ngi.it (Fabio Frumento) Date: Tue, 21 Mar 2006 08:21:47 +0100 Subject: [Rxtx] Javadoc on the go Message-ID: <441FA98B.9050701@ngi.it> Hi Trent, sorry for the big delay but my job is running wild, i was out for some time but now i'm back and ready to continue the javadoc for Rxtx. Did you used the last javadoc patch i sent you ? let me know if i have to send it to you again or not. regards Fabio From lyon at docjava.com Tue Mar 21 00:51:18 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Tue, 21 Mar 2006 02:51:18 -0500 Subject: [Rxtx] lock files Message-ID: Hi All, You know, if the use of lock files were under Java control (rather than a build-time decision), it might enable a more unified binary distro. It might also facilitate quick prototyping of non-lock file approaches to resolving serial port contention issues (i.e., mac-like approaches vs. linux approaches, etc.). I realize that this is a radical overhaul of the lock file policy issue. Also, it may harm performance. On the other hand, our benchmarks on JNI overhead for modern processors indicate performance impact should be minimal. Perhaps it is more of an issue with the toybox systems. Suppose there were a class with a reasonable default...someone might write: SerialPortLockPolicy.setPolicy(SerialPortLockPolicy.UNIX_LOCK_FILE); SerialPortLockPolicy.setPolicy(SerialPortLockPolicy.NO_LOCK_CHECKING); SerialPortLockPolicy.setPolicy(SerialPortLockPolicy.MAC_STYLE); Thus, we could have a run-time reconfiguration of the serial port lock policy. A special NO_LOCK version of the binary would no longer be required. Any thoughts on this? Thanks! - Doug From joachim at buechse.de Tue Mar 21 03:09:09 2006 From: joachim at buechse.de (Joachim Buechse) Date: Tue, 21 Mar 2006 11:09:09 +0100 Subject: [Rxtx] lock files In-Reply-To: References: Message-ID: <8E12916A-1B9A-4FF2-B684-E2D1C794221B@buechse.de> This is pretty much what I thought about when I suggested, that the default behaviour could be overwritten with a property. I am very much in favor of this approach. In particular this allows much easier debugging for PC based java developers. I think big parts of the Java (and maybe some parts of the C code) could use a bit of a structural workover (unit tests, javadoc, synchronization, etc). Maybe there should be a CVS branch for this experimental version. I'd be happy to contribute a first workover for some of the Java code. Designing for testability and implementing a good bunch of unit tests has been a strategy that worked quite well in the Java projects I lead. And it ultimately allows more liberal change permission. Regards, Joachim On 21.03.2006, at 08:51, Dr. Douglas Lyon wrote: > Hi All, > You know, if the use of lock files were > under Java control (rather than a build-time decision), > it might enable a more unified binary distro. It might also > facilitate quick prototyping of non-lock file approaches > to resolving serial port contention issues (i.e., mac-like > approaches vs. linux approaches, etc.). > > I realize that this is a radical overhaul of the lock file policy > issue. Also, it may harm performance. On the other hand, > our benchmarks on JNI overhead for modern processors indicate > performance impact should be minimal. Perhaps it is more of > an issue with the toybox systems. > > Suppose there were a class with a reasonable default...someone > might write: > SerialPortLockPolicy.setPolicy(SerialPortLockPolicy.UNIX_LOCK_FILE); > SerialPortLockPolicy.setPolicy(SerialPortLockPolicy.NO_LOCK_CHECKING); > SerialPortLockPolicy.setPolicy(SerialPortLockPolicy.MAC_STYLE); > > Thus, we could have a run-time reconfiguration of the serial port lock > policy. A special NO_LOCK version of the binary would no longer > be required. > > Any thoughts on this? > > Thanks! > - Doug > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From joachim at buechse.de Tue Mar 21 06:23:08 2006 From: joachim at buechse.de (Joachim Buechse) Date: Tue, 21 Mar 2006 14:23:08 +0100 Subject: [Rxtx] PATCH: use of ioctl(fd, TIOCEXCL) instead of lockfiles Message-ID: <923AE774-EEA2-4911-92D8-32BB27802C8B@buechse.de> Here is the patch for the ioctl(fd, TIOCEXCL). I have verified this only for OSX 10.4.5, hence it is only defined for APPLE. However, it should work at least for Solaris as well. If a process has requested TIOEXCL further open calls by other user processes will fail. The patch also disables uucp style locking for APPLE. Obviously this is discussable. I think it is the way to go, as it eliminates creating the lock directory which doesnt exist on the standard installation and it eliminates messing with the system group definitions (adding users to group uucp). Regarding the possibility of root processes opening a device which is locked - I consider this a feature not a potential problem. It is highly unlikely, that somebody is crazy enough to run a JavaVM as root (unless he has no other means of getting a restricted IP port opened, ie doesnt understand ipfw). Anyway, even if the process runs as root, it fails when calling ioctl(fd, TIOCEXCL). It could however still open the port to listen for RING events. I.e. a fax server which needs to see incoming calls but otherwise doesnt want to block the port. So the only case where the proposed mechanism fails is, if an incorrectly implemented process running as root conflicts with a user process. I think this can be accepted. Regards, Joachim PS: If this patch is generally accepted, the installer and Mac doku should obviously be changed as well. Index: SerialImp.c =================================================================== RCS file: /usr/local/cvsroot/rxtx-devel/src/SerialImp.c,v retrieving revision 1.46.2.187 diff -u -r1.46.2.187 SerialImp.c --- SerialImp.c 29 Jan 2006 22:19:04 -0000 1.46.2.187 +++ SerialImp.c 21 Mar 2006 12:59:16 -0000 @@ -656,6 +656,25 @@ fd=OPEN (filename, O_RDWR | O_NOCTTY | O_NONBLOCK ); } while (fd < 0 && errno==EINTR); +#ifdef OPEN_EXCL + // Note that open() follows POSIX semantics: multiple open() calls to + // the same file will succeed unless the TIOCEXCL ioctl is issued. + // This will prevent additional opens except by root-owned processes. + // See tty(4) ("man 4 tty") and ioctl(2) ("man 2 ioctl") for details. + + if (fd >= 0 && (ioctl(fd, TIOCEXCL) == -1)) + { + sprintf( message, "open: exclusive access denied for % s\n", + filename ); + report( message ); + report_error( message ); + + close(fd); + goto fail; + } +#endif /* OPEN_EXCL */ + + if( configure_port( fd ) ) goto fail; (*env)->ReleaseStringUTFChars( env, jstr, filename ); sprintf( message, "open: fd returned is %i\n", fd ); Index: SerialImp.h =================================================================== RCS file: /usr/local/cvsroot/rxtx-devel/src/SerialImp.h,v retrieving revision 1.11.2.49 diff -u -r1.11.2.49 SerialImp.h --- SerialImp.h 5 Jul 2005 17:47:21 -0000 1.11.2.49 +++ SerialImp.h 21 Mar 2006 12:59:17 -0000 @@ -135,7 +135,8 @@ /*# define LOCKDIR "/var/spool/uucp"*/ # define LOCKDIR "/var/lock" # define LOCKFILEPREFIX "LK." -# define UUCP +/*# define UUCP*/ +# define OPEN_EXCL #endif /* __APPLE__ */ #if defined(__NetBSD__) # define DEVICEDIR "/dev/" From tjarvi at qbang.org Tue Mar 21 10:26:08 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 21 Mar 2006 10:26:08 -0700 (MST) Subject: [Rxtx] Javadoc on the go In-Reply-To: <441FA98B.9050701@ngi.it> References: <441FA98B.9050701@ngi.it> Message-ID: On Tue, 21 Mar 2006, Fabio Frumento wrote: > Hi Trent, > > sorry for the big delay but my job is running wild, i was out for some > time but now i'm back and ready to continue the javadoc for Rxtx. > > Did you used the last javadoc patch i sent you ? let me know if i have to > send it to you again or not. > > regards > > Fabio Hi Fabio The patch is in the rxtx mail-list archives. It will be going in soon. I did not see a time critical portion. I'll probably be going through the list since the last batch of patches this weekend and putting them into CVS. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Tue Mar 21 10:57:18 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 21 Mar 2006 10:57:18 -0700 (MST) Subject: [Rxtx] jvm issue In-Reply-To: <20060321065524.94779.qmail@web50701.mail.yahoo.com> References: <20060321065524.94779.qmail@web50701.mail.yahoo.com> Message-ID: On Mon, 20 Mar 2006, Lambok Sianturi wrote: > Hi All, > This is my first time to join RxTx mailing list. I thank you all for allowing others to sign in in requests help. > I use the latest RxTx lib in Fedora 3 with java version 1.4.2_09 b05. And I got this error: > > # > # An unexpected error has been detected by HotSpot Virtual Machine: > # > # SIGSEGV (0xb) at pc=0x00bf27f3, pid=2633, tid=3086112448 > # > # Java VM: Java HotSpot(TM) Client VM (1.4.2_09-b05 mixed mode) > # Problematic frame: > # C [ld-linux.so.2+0xa7f3] A native library loading error? What happens if you recompile rxtx on your system and install that? This sounds like an ABI problem? rxtx 2.1-7 was compiled with a gcc 2.96 toolchain as I recall. The hope is newer system will be backwards compatible. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Tue Mar 21 11:05:29 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 21 Mar 2006 11:05:29 -0700 (MST) Subject: [Rxtx] PATCH: use of ioctl(fd, TIOCEXCL) instead of lockfiles In-Reply-To: <923AE774-EEA2-4911-92D8-32BB27802C8B@buechse.de> References: <923AE774-EEA2-4911-92D8-32BB27802C8B@buechse.de> Message-ID: On Tue, 21 Mar 2006, Joachim Buechse wrote: > Here is the patch for the ioctl(fd, TIOCEXCL). I have verified this only > for OSX 10.4.5, hence it is only defined for APPLE. However, it should > work at least for Solaris as well. > > If a process has requested TIOEXCL further open calls by other user > processes will fail. > > The patch also disables uucp style locking for APPLE. Obviously this is > discussable. I think it is the way to go, as it eliminates creating the > lock directory which doesnt exist on the standard installation and it > eliminates messing with the system group definitions (adding users to > group uucp). > > Regarding the possibility of root processes opening a device which is > locked - I consider this a feature not a potential problem. It is highly > unlikely, that somebody is crazy enough to run a JavaVM as root (unless > he has no other means of getting a restricted IP port opened, ie doesnt > understand ipfw). Anyway, even if the process runs as root, it fails when > calling ioctl(fd, TIOCEXCL). It could however still open the port to > listen for RING events. I.e. a fax server which needs to see incoming > calls but otherwise doesnt want to block the port. So the only case where > the proposed mechanism fails is, if an incorrectly implemented process > running as root conflicts with a user process. I think this can be > accepted. > > Regards, > Joachim > > PS: If this patch is generally accepted, the installer and Mac doku > should obviously be changed as well. > > > Index: SerialImp.c > =================================================================== > RCS file: /usr/local/cvsroot/rxtx-devel/src/SerialImp.c,v > retrieving revision 1.46.2.187 > diff -u -r1.46.2.187 SerialImp.c > --- SerialImp.c 29 Jan 2006 22:19:04 -0000 1.46.2.187 > +++ SerialImp.c 21 Mar 2006 12:59:16 -0000 > @@ -656,6 +656,25 @@ > fd=OPEN (filename, O_RDWR | O_NOCTTY | O_NONBLOCK ); > } while (fd < 0 && errno==EINTR); > > +#ifdef OPEN_EXCL > + // Note that open() follows POSIX semantics: multiple open() > calls to > + // the same file will succeed unless the TIOCEXCL ioctl is > issued. > + // This will prevent additional opens except by root-owned > processes. > + // See tty(4) ("man 4 tty") and ioctl(2) ("man 2 ioctl") for > details. > + > + if (fd >= 0 && (ioctl(fd, TIOCEXCL) == -1)) > + { > + sprintf( message, "open: exclusive access denied for % > s\n", > + filename ); > + report( message ); > + report_error( message ); > + > + close(fd); > + goto fail; > + } > +#endif /* OPEN_EXCL */ > + > + > if( configure_port( fd ) ) goto fail; > (*env)->ReleaseStringUTFChars( env, jstr, filename ); > sprintf( message, "open: fd returned is %i\n", fd ); > Index: SerialImp.h > =================================================================== > RCS file: /usr/local/cvsroot/rxtx-devel/src/SerialImp.h,v > retrieving revision 1.11.2.49 > diff -u -r1.11.2.49 SerialImp.h > --- SerialImp.h 5 Jul 2005 17:47:21 -0000 1.11.2.49 > +++ SerialImp.h 21 Mar 2006 12:59:17 -0000 > @@ -135,7 +135,8 @@ > /*# define LOCKDIR "/var/spool/uucp"*/ > # define LOCKDIR "/var/lock" > # define LOCKFILEPREFIX "LK." > -# define UUCP > +/*# define UUCP*/ > +# define OPEN_EXCL > #endif /* __APPLE__ */ > #if defined(__NetBSD__) > # define DEVICEDIR "/dev/" > This looks like a good start. What do you think Dmitry? Perhaps all systems with TIOCEXCL defined should use that though. Even if they use lockfiles. It wont hurt anything. That would catch people hacking their own serial apps without checking lockfiles. Its a good idea to avoid C++ style comments in the C portions. Some older systems don't deal with them well. If it's just for Mac OS X, it isn't a big deal. I think it was the Irix compiler that was problematic? -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Tue Mar 21 11:22:05 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 21 Mar 2006 11:22:05 -0700 (MST) Subject: [Rxtx] lock files In-Reply-To: <8E12916A-1B9A-4FF2-B684-E2D1C794221B@buechse.de> References: <8E12916A-1B9A-4FF2-B684-E2D1C794221B@buechse.de> Message-ID: We can try it. Maybe the JNI is much improved. The nice thing about linking into liblock is distros then worry about lockfiles on their systems. This way, we have to deal with any changes that may show up. On Tue, 21 Mar 2006, Joachim Buechse wrote: > This is pretty much what I thought about when I suggested, that the > default behaviour could be overwritten with a property. I am very much in > favor of this approach. In particular this allows much easier debugging > for PC based java developers. > > I think big parts of the Java (and maybe some parts of the C code) could > use a bit of a structural workover (unit tests, javadoc, synchronization, > etc). Maybe there should be a CVS branch for this experimental version. > I'd be happy to contribute a first workover for some of the Java code. > Designing for testability and implementing a good bunch of unit tests has > been a strategy that worked quite well in the Java projects I lead. And > it ultimately allows more liberal change permission. > > Regards, > Joachim > > > On 21.03.2006, at 08:51, Dr. Douglas Lyon wrote: > >> Hi All, >> You know, if the use of lock files were >> under Java control (rather than a build-time decision), >> it might enable a more unified binary distro. It might also >> facilitate quick prototyping of non-lock file approaches >> to resolving serial port contention issues (i.e., mac-like >> approaches vs. linux approaches, etc.). >> >> I realize that this is a radical overhaul of the lock file policy >> issue. Also, it may harm performance. On the other hand, >> our benchmarks on JNI overhead for modern processors indicate >> performance impact should be minimal. Perhaps it is more of >> an issue with the toybox systems. >> >> Suppose there were a class with a reasonable default...someone >> might write: >> SerialPortLockPolicy.setPolicy(SerialPortLockPolicy.UNIX_LOCK_FILE); >> SerialPortLockPolicy.setPolicy(SerialPortLockPolicy.NO_LOCK_CHECKING); >> SerialPortLockPolicy.setPolicy(SerialPortLockPolicy.MAC_STYLE); >> >> Thus, we could have a run-time reconfiguration of the serial port lock >> policy. A special NO_LOCK version of the binary would no longer >> be required. >> >> Any thoughts on this? >> >> Thanks! >> - Doug >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From dmarkman at mac.com Tue Mar 21 16:05:17 2006 From: dmarkman at mac.com (Dmitry Markman) Date: Tue, 21 Mar 2006 18:05:17 -0500 Subject: [Rxtx] PATCH: use of ioctl(fd, TIOCEXCL) instead of lockfiles In-Reply-To: References: <923AE774-EEA2-4911-92D8-32BB27802C8B@buechse.de> Message-ID: <512AC70C-BB86-48F2-A83C-023F35C23BAB@mac.com> I think it's cool, but I'd like to have that property implementation when user can choose between locking mechanism about comments: it's easy to change comments to the C style or we can use extensions of the file to cpp so c++ compiler will be used On Mar 21, 2006, at 1:05 PM, Trent Jarvi wrote: > This looks like a good start. What do you think Dmitry? Perhaps > all systems with TIOCEXCL defined should use that though. Even if > they use lockfiles. It wont hurt anything. That would catch > people hacking their own serial apps without checking lockfiles. > > Its a good idea to avoid C++ style comments in the C portions. > Some older systems don't deal with them well. If it's just for Mac > OS X, it isn't a big deal. I think it was the Irix compiler that > was problematic? Dmitry Markman From dmarkman at mac.com Tue Mar 21 16:13:00 2006 From: dmarkman at mac.com (Dmitry Markman) Date: Tue, 21 Mar 2006 18:13:00 -0500 Subject: [Rxtx] PATCH: use of ioctl(fd, TIOCEXCL) instead of lockfiles In-Reply-To: References: <923AE774-EEA2-4911-92D8-32BB27802C8B@buechse.de> Message-ID: I'd like to add that creating locking folder isn't a big deal we never had a problem related to the lock folders, because we always used installer on mac os x from other hand I'm not very much familiar with iotcl locking approach and I'm not sure it's more efficient Joachim wrote "I think it is the way to go, as it eliminates creating the lock directory which doesnt exist on the standard installation and it eliminates messing with the system group definitions (adding users to group uucp)." but I really didn't have any problem with that 1. doesn't exist on the standard installation there are many-many things that don't exist in the standard installation so I don't think that argument is strong enough 2. messing with the system group definitions I don't think we're messing with the group definition mac os x provides very clear way to set up group's members and together with Greg Guerin AuthKit there is no problem to set those definitions so I don't think that argument is strong either but from other hand using iotcl is more promising and is more elegant On Mar 21, 2006, at 1:05 PM, Trent Jarvi wrote: > > This looks like a good start. What do you think Dmitry? Perhaps > all systems with TIOCEXCL defined should use that though. Even if > they use lockfiles. It wont hurt anything. That would catch > people hacking their own serial apps without checking lockfiles. Dmitry Markman From joachim at buechse.de Wed Mar 22 04:46:45 2006 From: joachim at buechse.de (Joachim Buechse) Date: Wed, 22 Mar 2006 12:46:45 +0100 Subject: [Rxtx] PATCH: use of ioctl(fd, TIOCEXCL) instead of lockfiles In-Reply-To: References: <923AE774-EEA2-4911-92D8-32BB27802C8B@buechse.de> Message-ID: Sorry, I was not very clear with my arguments, so I will try again;-) Please, don't take this as an attack against work that has been done. I think the contributions that have been made in the past were made in a good spirit. But I really believe, that the current solution for OSX has many shortcomings and should be changed as soon as possible. lock files --- The /var/lock folder does not exist on the standard OSX installation, however the standard installation includes several applications that use serial ports (i.e. the FAX capability). This indicates, that the lock folder approach will not work well with system components. Applications for OSX will generally try to live in harmony with system components (except for HP print drivers of course). I think RXTX should follow this approach as well. uucp group --- Accessing serial ports is not an admin privileged operation on OSX. Any user (world) has read/write privileges on /dev/tty*. So the system default is to not enforce any group membership to access these ports. The group uucp however is a system group on all unix systems I know. It exists for certain system processes. A non admin user should in general not be a member of this group. Quite arguably no user should ever be a member of this group. Installer --- My general opinion is, that - no Installer should touch user or group data without warning - no Application Installer should touch groups which are not specific to the very application installed - no Installer should ever add regular users to a system group The current installer injects the installing user in the group uucp without warning about this change and without giving the option to "opt out" of this change. This is a potential security risk (but not currently a real one, as OSX contains no folders belonging to group uucp). The current installer does not work for multi user systems. It puts the installing user in the uucp group. However the installing user is not necessarily the user that will use the application. Putting all users that may use a serial port application in the system group uucp seems like a very invasive approach to me. Besides that, newly created users will not automatically be in the group and hence, serial applications will "break" for new users without obvious reasons. Avoiding the lock files will allow self contained applications (i.e. drag&drop installation). In my eyes this is largely preferable over an installer that requests admin privileges. Adding up all these points indicates very strongly, that the lock-file implementation is not the way to go on OSX. Regards, Joachim On 22.03.2006, at 00:13, Dmitry Markman wrote: > I'd like to add that > > creating locking folder isn't a big deal > we never had a problem related to the lock folders, because we > always used installer on mac os x > from other hand I'm not very much familiar with iotcl locking > approach and I'm not sure it's more efficient > > Joachim wrote "I think it is the way to go, as it eliminates > creating the lock directory which doesnt exist on the standard > installation and it eliminates messing with the system group > definitions (adding users to group uucp)." but I really didn't have > any problem with that > > 1. doesn't exist on the standard installation > there are many-many things that don't exist in the standard > installation so I don't think that argument is strong enough > 2. messing with the system group definitions > I don't think we're messing with the group definition > mac os x provides very clear way to set up group's members and > together with Greg Guerin AuthKit there is no problem to set those > definitions > so I don't think that argument is strong either > but from other hand using iotcl is more promising and is more elegant > > > > On Mar 21, 2006, at 1:05 PM, Trent Jarvi wrote: > >> >> This looks like a good start. What do you think Dmitry? Perhaps >> all systems with TIOCEXCL defined should use that though. Even if >> they use lockfiles. It wont hurt anything. That would catch >> people hacking their own serial apps without checking lockfiles. > > Dmitry Markman > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From dmarkman at mac.com Wed Mar 22 05:27:13 2006 From: dmarkman at mac.com (Dmitry Markman) Date: Wed, 22 Mar 2006 07:27:13 -0500 Subject: [Rxtx] PATCH: use of ioctl(fd, TIOCEXCL) instead of lockfiles In-Reply-To: References: <923AE774-EEA2-4911-92D8-32BB27802C8B@buechse.de> Message-ID: <83440CF3-DCD8-41C1-B941-F227232C27E3@mac.com> thanks for the very good explanation I didn't think that you were attacking any thing, so don't worry I just had feeling, that there were more aesthetic reasons for going to ioctl then real necessity now you explained everything quite well (BTW, asfar as I remember installer asks admin password so it wasn't quiet, but it really doesn't matter now) thanks On Mar 22, 2006, at 6:46 AM, Joachim Buechse wrote: > Sorry, I was not very clear with my arguments, so I will try again;-) > > Please, don't take this as an attack against work that has been > done. I think the contributions that have been made in the past > were made in a good spirit. But I really believe, that the current > solution for OSX has many shortcomings and should be changed as > soon as possible. > > lock files > --- > The /var/lock folder does not exist on the standard OSX > installation, however the standard installation includes several > applications that use serial ports (i.e. the FAX capability). This > indicates, that the lock folder approach will not work well with > system components. Applications for OSX will generally try to live > in harmony with system components (except for HP print drivers of > course). I think RXTX should follow this approach as well. > > uucp group > --- > Accessing serial ports is not an admin privileged operation on OSX. > Any user (world) has read/write privileges on /dev/tty*. So the > system default is to not enforce any group membership to access > these ports. The group uucp however is a system group on all unix > systems I know. It exists for certain system processes. A non admin > user should in general not be a member of this group. Quite > arguably no user should ever be a member of this group. > > Installer > --- > My general opinion is, that > - no Installer should touch user or group data without warning > - no Application Installer should touch groups which are not > specific to the very application installed > - no Installer should ever add regular users to a system group > > The current installer injects the installing user in the group uucp > without warning about this change and without giving the option to > "opt out" of this change. This is a potential security risk (but > not currently a real one, as OSX contains no folders belonging to > group uucp). > > The current installer does not work for multi user systems. It puts > the installing user in the uucp group. However the installing user > is not necessarily the user that will use the application. Putting > all users that may use a serial port application in the system > group uucp seems like a very invasive approach to me. Besides that, > newly created users will not automatically be in the group and > hence, serial applications will "break" for new users without > obvious reasons. > > > Avoiding the lock files will allow self contained applications > (i.e. drag&drop installation). In my eyes this is largely > preferable over an installer that requests admin privileges. Adding > up all these points indicates very strongly, that the lock-file > implementation is not the way to go on OSX. > > Regards, > Joachim > > > On 22.03.2006, at 00:13, Dmitry Markman wrote: > >> I'd like to add that >> >> creating locking folder isn't a big deal >> we never had a problem related to the lock folders, because we >> always used installer on mac os x >> from other hand I'm not very much familiar with iotcl locking >> approach and I'm not sure it's more efficient >> >> Joachim wrote "I think it is the way to go, as it eliminates >> creating the lock directory which doesnt exist on the standard >> installation and it eliminates messing with the system group >> definitions (adding users to group uucp)." but I really didn't >> have any problem with that >> >> 1. doesn't exist on the standard installation >> there are many-many things that don't exist in the standard >> installation so I don't think that argument is strong enough >> 2. messing with the system group definitions >> I don't think we're messing with the group definition >> mac os x provides very clear way to set up group's members and >> together with Greg Guerin AuthKit there is no problem to set those >> definitions >> so I don't think that argument is strong either >> but from other hand using iotcl is more promising and is more elegant >> >> >> >> On Mar 21, 2006, at 1:05 PM, Trent Jarvi wrote: >> >>> >>> This looks like a good start. What do you think Dmitry? Perhaps >>> all systems with TIOCEXCL defined should use that though. Even >>> if they use lockfiles. It wont hurt anything. That would catch >>> people hacking their own serial apps without checking lockfiles. >> >> Dmitry Markman >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx Dmitry Markman From lyon at docjava.com Wed Mar 22 06:12:18 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Wed, 22 Mar 2006 08:12:18 -0500 Subject: [Rxtx] sole of a new design pattern Message-ID: Hi All, I have been thinking about how we design the serial port software. I think we need a new design pattern. For lack of a better term, I shall call it: The Parametric Singleton Design Pattern By Douglas A. Lyon ABSTRACT The goal of the singleton design pattern is to make sure that there is one, and only one, instance of a given class. The goal of the parametric singleton design pattern is to make sure that there is one, and only one, instance of a given class with the given parametric values. We parametric singleton design pattern combines the singleton design pattern with a parameter that enables unique creation of instances of a class. These instances are cached. When a user asks for an instance with these parameters, the cache is checked. If the instance is in the cache, the instance is returned, otherwise it is created, added to the cache and then returned. We apply our parametric singleton design pattern to the retrieval of RMI registries bound to a given port. The goal of our system is to make sure that no two RMI registries are listening to the same socket and to make use of the RMI registries after they have been created. RMI registries are used in distributed computation. Introduction The singleton design pattern is meant to ensure that on a single instance of a class exists. It is also meant to provide a global point of access to it. The intent of the parametric singleton design pattern is to ensure that a class has only one instance for a given set of parameter values. It also provides a global point of access to it. Motivation A system cannot tolerate multiple instances of some classes with identical parameters. For example, you cannot have two instances making use of the same serial port, at the same time. You cannot have two instances that are trying to listen to the same socket connection. You cannot have two instances writing to the same file structure at the same time. As the operating system is often thought of as the arbiter of consumed resources (i.e., tape drives, serial ports, etc.) we frequently leave it to an operating system implementation to resolve these contention issues. Even for similar resources (like serial ports) there are few standards for handling contention. For example, serial ports on Linux are locked using a "/var/lock" file. POSIX, on the other hand, uses ioctl mechanisms to prevent contention. A better solution is to make a class that is responsible for keeping track of the instances created from the class. The class is declared final, so that it cannot be subclassed. The class also has a private constructor, so that other classes cannot instance it. The new design pattern is called the parametric singleton design pattern and it provides a way to access and create instances with given parameters. Applicability Use the Parametric Singleton Design Pattern when: 1. There must be exactly one instance of a class with the given parameters. 2. The instances must be accessible to clients from a well-known access point. Structure Insert UML diagram here. Participants The Parametric Singleton Clients that need instances 1. The Parametric Singleton defines an instance upon request from a client, if, and only if, the instance does not already exist. 2. The Parametric Singleton returns the instance to the client. 3. The Parametric Singleton is responsible for creating unique instances from given parameters. Collaborations Clients obtain a reference to a Parametric Singleton instance only through the parametric singleton design pattern. If the instance is left in an improper state (e.g., the serial port was left open) it is NOT the role of the Parametric Singleton Design Pattern to close the IO port. Nor is it the role of the Parametric Singleton Design Pattern to open the port. That role is delegate to some other part of the system. Further, it is not the role of the Parametric Singleton Design Pattern to check out resources. That is, multiple threads can have multiple references to the same resource at the same time. MUTEX locking is delegated to some other part of the system. Consequences The Parametric Singleton Design Pattern has several benefits: 1. Controlled access to parametrically defined instances. Since the Parametric Singleton class encapsulates its instances, there is control over how and when clients access it. 2. Reduced name space. The Parametric Singleton pattern avoids global variables that store instances created from the same parameter. Implementation Here are implementation issues to consider when using the Parametric Singleton pattern: 1. Unique mapping of parameters. The Parametric Singleton pattern requires that there be a mean to isomorphically map the parameter space into the instance space and back again. 2. Ensure unique instances. The Parametric Singleton pattern makes unique instances from parameters, and it does so only once. 3. Cache instances for fast retrieval. The Parametric Singleton pattern must be able to look up instances, given some set of parameters, and do so from some data structure. That is, there must be enough space to hold references to all the instances the program will need. Also, a mechanism is needed to look up and retrieve the instances quickly enough to satisfy the clients. Sample Code public final class ParametricSingletonRmiRegistry { private static Hashtable registry = new Hashtable(100); // use singleton pattern and??????????????????????????????????????????????? // prevent instantiation of RmiRegistryUtils.?????????????????????????????? private ParametricSingletonRmiRegistry() { } // the only instance of the Registry held by the RmiRegistryUtils?????????? public static void listNames(Integer port) { if (!isInCacheAndRunning(port)) return; Registry r = (Registry) registry.get(port); System.out.println("registry on port: " + port); System.out.println("registry: " + r); System.out.println("names: "); try { print(r.list()); } catch (RemoteException e) { In.message(e); } System.out.println("------------------------"); } /**???????????????????????????????????????????????????????????????????????? * Checks whether a Registry has been started on this host????????????????? * in the specified port.?????????????????????????????????????????????????? * If not, it tries to start one.?????????????????????????????????????????? * when it fails to start a Registry, it exits the program????????????????? * with exit code 1.??????????????????????????????????????????????????????? */ public static void restart(int port) { if (isInCacheAndRunning(port)) return; try { startRegistry(port); } catch (RemoteException e) { In.message(e); } } /**???????????????????????????????????????????????????????????????????????? * @param port????????????????????????????????????????????????????????????? * @return true if registry is in cache and running???????????????????????? */ private static boolean isInCacheAndRunning(Integer port) { if (!isRegistryRunning(port.intValue())) return false; if (!isRegistryInCache(port.intValue())) return false; return true; } /**???????????????????????????????????????????????????????????????????????? * @param port????????????????????????????????????????????????????????????? * @return true if we are able to locate a local registry on port.??????????????????????????????????????????????????????????????????????????? */ private static boolean isRegistryRunning(int port) { try { Registry r = LocateRegistry.getRegistry(port); if (r != null) return true; } catch (RemoteException e) { return false; } return false; } /**???????????????????????????????????????????????????????????????????????? * @param port????????????????????????????????????????????????????????????? * @return return true if registry is in cache????????????????????????????? */ private static boolean isRegistryInCache(int port) { if (registry.get(new Integer(port)) == null) return false; return true; } /**???????????????????????????????????????????????????????????????????????? * Restart the registry, if needed.???????????????????????????????????????? * Return the only instance of the registry for consistent global?????????? * using by making use of the Singleton Design Pattern????????????????????? *????????????????????????????????????????????????????????????????????????? * @return the internally held registry instance.?????????????????????????? */ public static Registry getRegistry(Integer port) { restart(port); return (Registry) registry.get(port); } private static void startRegistry(Integer port) throws RemoteException { Registry r; try { r = LocateRegistry.createRegistry(port.intValue()); registry.put(port, r); //r = new sun.rmi.registry.RegistryImpl???????????????????????????? /// (port.intValue());?????????????????????????????????????? // registry.put(port, r);?????????????????????????????????????????? } catch (Exception e) { //e.printStackTrace();????????????????????????????????????????????? r = LocateRegistry.getRegistry(port.intValue()); registry.put(port, r); } } public static void main(String args[]) throws RemoteException { //restart(port);??????????????????????????????????????????????????????? restart(5001); restart(5002); restart(5002); Registry r = LocateRegistry.getRegistry(5002); System.out.println("registry="+r); } } I would very much like to get your feedback on this new design pattern idea. Thank you for your time. Regards, - Doug From david.garnier at trusted-logic.com Wed Mar 22 07:36:10 2006 From: david.garnier at trusted-logic.com (David Garnier) Date: Wed, 22 Mar 2006 15:36:10 +0100 Subject: [Rxtx] sole of a new design pattern In-Reply-To: References: Message-ID: <442160DA.80107@trusted-logic.com> Hello, > The Parametric Singleton Design Pattern The Singleton is the most abused design pattern ever. Good use-cases for this pattern are extremely rare and mostly confined to problems related to hardware resources, like serial ports. > Applicability > > Use the Parametric Singleton Design Pattern when: > 1. There must be exactly one instance of a class with the given > parameters. OK. As I said above, this case this actually very unusual. The Singleton pattern is mostly used when : > 2. The instances must be accessible to clients from a well-known > access point. Using the singleton pattern in this case is just convenient for the programmer. Problems arises pretty quickly, especially if you attempt to unit-test your classes. 1) If your singleton is stateful, or hold on to stateful objects, it means that two different unit tests are not actually independent. Instead of starting with a brand new environment, the result of a test may be affected by the result of a previous test. This problem also arise when with your class relies on a database. In both cases, the solution is to reset your "unique" resource (Singleton or database) at the beginning of the test, which is a pain. Also, while most projects connect to a single database, projects that allow the use of Singletons usually contain several of thems, and new ones may cropped up unnoticed. You quickly end up with test cases that only pass in a certain order, which is a royal pain. 2) You cannot mockup a singleton. Once everyone calls the SomeSingleton class statically, you can't replace your class by SomeSingletonMockup. Furthermore, even for hardware services, the Singleton pattern does not really prevent concurrent accesses. If you start the same program in two different JVMs, unless they somehow shared the state of their "Singletons" (through lock files for example), the Singleton pattern will not prevent concurrent access. Our application uses RXTX, and we routinely encounter cases where another (native) application has already locked the port. Since we cannot modify the native application to recognize lock files, OS-level control is irreplaceable. > > Consequences > The Parametric Singleton Design Pattern has several benefits: > > 1. Controlled access to parametrically defined instances. Since > the Parametric Singleton class encapsulates its instances, there is > control over how and when clients access it. Not really. Once you've returned the instance to a client, you've lost control over it. The client can to whatever it wants with it. You cannot "recall" the instance or claim it back. > 2. Reduced name space. The Parametric Singleton pattern avoids > global variables that store instances created from the same parameter. Sure, but you don't have to rely on a Singleton for that. Just create a single Factory. > I would very much like to get your feedback on this new design > pattern idea. Well, it's nothing new. Some may say that it is the point of design patterns: formalizes the designs that occur again and again. However, this design is simply a combination of the Singleton and Factory patterns. I did use it in the past, but now I've been exposed to the shortcomings of the Singleton pattern, so I limit myself to Factories. Regards, David From sean_montgomery at baseview.com Wed Mar 22 08:35:28 2006 From: sean_montgomery at baseview.com (Sean Montgomery) Date: Wed, 22 Mar 2006 10:35:28 -0500 Subject: [Rxtx] sole of a new design pattern In-Reply-To: <442160DA.80107@trusted-logic.com> References: <442160DA.80107@trusted-logic.com> Message-ID: <05769CA7-A51B-4CF0-BAA0-E02DD905F5A4@baseview.com> On Mar 22, 2006, at 9:36 AM, David Garnier wrote: > Furthermore, even for hardware services, the Singleton pattern does > not really prevent concurrent > accesses. If you start the same program in two different JVMs, > unless they somehow shared the state > of their "Singletons" (through lock files for example), the > Singleton pattern will not prevent > concurrent access. > Multiple class loaders in a single JVM can be tricky, too. Then there's synchronization, lazy initialization and serialization of singletons to contend with. Bloch's Effective Java covers these, and here's a few articles: http://www.javaworld.com/javaworld/jw-04-2003/jw-0425-designpatterns- p3.html http://java.sun.com/developer/technicalArticles/Programming/singletons/ Just FYI :-) From lyon at docjava.com Wed Mar 22 08:50:48 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Wed, 22 Mar 2006 10:50:48 -0500 Subject: [Rxtx] sole of a new design pattern In-Reply-To: <442160DA.80107@trusted-logic.com> References: <442160DA.80107@trusted-logic.com> Message-ID: Hi All, First, I would like to thank David for his prompt and thoughtful remarks. I had no idea people that feel strongly about a design patterns! Wow! Feedback (particularly critical feedback) is greatly appreciated. Starting at the end, first: >I did use it in >the past, but now I've been exposed to the shortcomings of the >Singleton pattern, so I limit myself to Factories. David, if I understood your comments correctly, you suggested that Factories can be used in leu of the Singleton Design Pattern, or even the Parametric Singleton Design Pattern. As I see in [Gof]: Factory Method: Intent "Define an interface for creating an object, but let subclasses decide which class to instantiate. Factory Method lets a class defer instantiation to subclasses." The Singleton Design Pattern is a concrete class, which is rather different, right? Also, subclasses are not permitted with Singleton, as they are final. Naturally, I could use an abstract factory as a parent for a singleton. I could even design a facade that could be implemented with the singleton....but that is not the intention of the design. Unless you want a mock-up, as discussed, below: More below: >Hello, > >> The Parametric Singleton Design Pattern > >The Singleton is the most abused design pattern ever. Good use-cases >for this pattern are extremely >rare and mostly confined to problems related to hardware resources, >like serial ports. > > >> Applicability >> >> Use the Parametric Singleton Design Pattern when: >> 1. There must be exactly one instance of a class with the given >> parameters. >OK. As I said above, this case this actually very unusual. The >Singleton pattern is mostly used when : >> 2. The instances must be accessible to clients from a well-known >> access point. > >Using the singleton pattern in this case is just convenient for the >programmer. Problems arises >pretty quickly, especially if you attempt to unit-test your classes. > >1) If your singleton is stateful, or hold on to stateful objects, it >means that two different unit >tests are not actually independent. Instead of starting with a brand >new environment, the result of >a test may be affected by the result of a previous test. This >problem also arise when with your >class relies on a database. In both cases, the solution is to reset >your "unique" resource >(Singleton or database) at the beginning of the test, which is a >pain. Also, while most projects >connect to a single database, projects that allow the use of >Singletons usually contain several of >thems, and new ones may cropped up unnoticed. You quickly end up >with test cases that only pass in a >certain order, which is a royal pain. There are basic problems with communicating finite state machines that include reachability and deadlock analysis. These are addressed with petri net analysis and are beyond the scope of the design pattern. As you quite rightly pointed out; the parametric singleton pattern (or the singleton pattern, for that matter) enable multiple threads to gain access to the same instance. The only way that I can see to block others from gaining access to the reference is the synchronize keyword. This is putting a spin-lock (or MUTEX) on the reference. The question of how to unit-test a design pattern like the parametric singleton remains open. Perhaps this is a deficiency. > >2) You cannot mockup a singleton. Once everyone calls the >SomeSingleton class statically, you can't >replace your class by SomeSingletonMockup. Acutally, I am not sure that this is true. If the Singleton implements a Facade interface, it should be possible to make the replacement. Right? > >Furthermore, even for hardware services, the Singleton pattern does >not really prevent concurrent >accesses. If you start the same program in two different JVMs, >unless they somehow shared the state >of their "Singletons" (through lock files for example), the >Singleton pattern will not prevent >concurrent access. Good Point!! You have sharp eyes! The singleton design pattern should/could take responsibility for this. In fact, you may notice that my code does have an implementation (LocateRegistry) that can work across JVM's. The LocateRegistry will even work across the Internet! LocateRegistry takes both a host name and a Port (lock files just don't do this). I did not think to implement this beyond the local machine, but, in its present form, it will work across different processes. > >Our application uses RXTX, and we routinely encounter cases where >another (native) application has >already locked the port. Since we cannot modify the native >application to recognize lock files, >OS-level control is irreplaceable. The singleton design pattern is not meant to replace OS-level control, but to centralize the Java programmers access to it. If lock files, for example, are used for serial ports, the Singleton Design Pattern should be able to work with them. > > >> >> Consequences >> The Parametric Singleton Design Pattern has several benefits: >> > > 1. Controlled access to parametrically defined instances. Since >> the Parametric Singleton class encapsulates its instances, there is >> control over how and when clients access it. > >Not really. Once you've returned the instance to a client, you've >lost control over it. The client >can to whatever it wants with it. You cannot "recall" the instance >or claim it back. Good point, this should read: > 1. Controll when parametrically defined instances are created. Since > > the Parametric Singleton class encapsulates its instances, there is > > control over how and when they are instanced. > >> 2. Reduced name space. The Parametric Singleton pattern avoids >> global variables that store instances created from the same parameter. > >Sure, but you don't have to rely on a Singleton for that. Just >create a single Factory. > > Thank you for your thoughtful and prompt response! Regards, - Doug From dmarkman at mac.com Wed Mar 22 21:21:55 2006 From: dmarkman at mac.com (Dmitry Markman) Date: Wed, 22 Mar 2006 23:21:55 -0500 Subject: [Rxtx] sole of a new design pattern In-Reply-To: <442160DA.80107@trusted-logic.com> References: <442160DA.80107@trusted-logic.com> Message-ID: I don't think I get it On Mar 22, 2006, at 9:36 AM, David Garnier wrote: > Using the singleton pattern in this case is just convenient for the > programmer. Problems arises > pretty quickly, especially if you attempt to unit-test your classes. so you're saying that something isn't so good because you can not test it in the convenient way? if that's true, I'm totally disagree change your test, debug whatever, but if software is efficient at runtime, works fine and only problem is some unit test (which is some kind of framework for testing) then dump that unit test , dump that unit framework and make something appropriate to the software you're testing so if Douglas want to use singletons, what's the problem? and what do you mean by abusing of singleton usage? of course singleton doesn't prevent concurrent access to the resource across the processes unless you're using some OS facility to prevent it, besides singleton as it was introduced is relevant only and only inside of the same process otherwise it's not singleton it's something else (let's say network singleton: so you have remote invocation facility and some factory method that return object created by that facility) I don't have any problem with using any kind of singletons. Parametric Singleton idea (if I understand it right) could be easily implemented in the following way: use a map populate map with instances of some class and key is your parameter (you can use lazy population too) if somebody ask the key check the value if it's null so resource is taken if somebody returns the resource put it back to the map public synchronized static Object getSomeResource(Object parameter); public synchronized static void returnResource(Object parameter); getSomeResource (inside of the same process) could return null in 2 cases 1. if somebody (from other thread for example) already took that resource 2. if OS API said that resource corresponded to that parameter (serial port with parameter = 1 (port #)) is locked and unavailable; I'm not sure that in case of serial ports we even need those Parametric Singletons (unless lock checking is a very expensive operation) just ask the OS about availability of that resource and if it's available give it away and then OS will lock it and therefore in next time somebody ask it just answer that resource is locked and return null for example system has 2 serial ports available so I ask getResource("tty"); or I ask getResource("Bluetooth-Modem"); and if OS is ok you can give tty or Bluetooth-Modem or both no need for any additional pattern I think back to the problem mac os x doesn't recognize locking via files, so it handles locking via some API an instance of the singleton in each process should recognize that resource is locked (by using that API) that's all we don't have to make things more complicate then they are just because there is some nice design pattern or nice unit test framework or whatever keep things simple, make them work fast, don't introduce middle layers unless you have really good reason to do so of course I could be entirely wrong, so sorry about that in advance thanks Dmitry Markman From tjarvi at qbang.org Wed Mar 22 22:31:41 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 22 Mar 2006 22:31:41 -0700 (MST) Subject: [Rxtx] sole of a new design pattern In-Reply-To: References: Message-ID: Hi Doug Interesting reading. So far I'm just reading and thinking. I have one question so far. " Clients obtain a reference to a Parametric Singleton instance only through the parametric singleton design pattern. If the instance is left in an improper state (e.g., the serial port was left open) it is NOT the role of the Parametric Singleton Design Pattern to close the IO port. Nor is it the role of the Parametric Singleton Design Pattern to open the port. That role is delegate to some other part of the system. " So when the clients obtain a reference to the singleton, can they assume the port is there? IE, would it be the singletons role to handle things like USB dongles being removed with event hints comming from the underlying OS. Hardware abstraction layer/HAL on Linux is an example of underlying OS events. I assume that role too is delegated to other parts of the system? -- Trent Jarvi tjarvi at qbang.org From lyon at docjava.com Thu Mar 23 08:10:33 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Thu, 23 Mar 2006 10:10:33 -0500 Subject: [Rxtx] Classes don't need goals, they need roles! In-Reply-To: References: Message-ID: Hi Trent, Yes, I think that the role of the Parametric Singleton Pattern is not to open or close serial ports, nor is it to perform error checking. On the other hand, if you were to combine the role of the Parametric Singleton Pattern with another role (like that of error checking) it might not be amiss. However, I generally caution programmers against adding multiple roles to classes, as this leads to monolithic designs. Thus a different class (NativeLibDetect) could have the role of determining if the native library can be loaded. Another class (SerialPortBean) can have the role of serializing the default state of the serial port, so that it can be recovered, from user preferences, at a later time. The SerialPortDetect could have the role of determining if the serial port is removed (i.e., a USB port was unplugged). My guess is that each class should have a different role in the system, in order to ease maintenance and testing...but I could be wrong about that. Thanks! - Doug >Hi Doug > >Interesting reading. So far I'm just reading and thinking. I have >one question so far. > >" > Clients obtain a reference to a Parametric Singleton instance only >through the parametric singleton design pattern. If the instance is >left in an improper state (e.g., the serial port was left open) it is >NOT the role of the Parametric Singleton Design Pattern to close the >IO port. Nor is it the role of the Parametric Singleton Design Pattern >to >open the port. That role is delegate to some other part of the system. >" > >So when the clients obtain a reference to the singleton, can they >assume the port is there? IE, would it be the singletons role to >handle things like USB dongles being removed with event hints >comming from the underlying OS. Hardware abstraction layer/HAL on >Linux is an example of underlying OS events. > >I assume that role too is delegated to other parts of the system? > >-- >Trent Jarvi >tjarvi at qbang.org >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From maximulo at yahoo.com Fri Mar 24 01:22:38 2006 From: maximulo at yahoo.com (Maximulo Majir) Date: Fri, 24 Mar 2006 00:22:38 -0800 (PST) Subject: [Rxtx] JavaPOS Message-ID: <20060324082238.66371.qmail@web38214.mail.mud.yahoo.com> Hi all! Hello Trent! From what i understand, RXTX or JavaComm APIs were not created solely for JavaPOS. In JavaPOS, we have the virtual method claim() which is separate from open(), but in our RXTX API, claiming is done every call to open(), we cant open the port if its claimed by another application. Would it be alright to suggest or ask to create a new method called claim(..)? Is there such thing as forceclaim() in RXTX? this could be the same as portownership transfer or its equivalent. ForceClaim is in JSR80. Do you have some samples using RXTX as the lower layer for the Device Service Objects in JavaPOS? I have tried it, i just want to compare. Thank you all! maxim __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060324/496adba2/attachment-0026.html From tjarvi at qbang.org Fri Mar 24 11:28:19 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 24 Mar 2006 11:28:19 -0700 (MST) Subject: [Rxtx] Re: RXTX 2.1 Solaris Problems In-Reply-To: <3691.1143210578@www045.gmx.net> References: <3691.1143210578@www045.gmx.net> Message-ID: On Fri, 24 Mar 2006, Andreas Guenther wrote: > Hi all, > > the solaris problem was not the lock file only. > > Ok, I had to create the directory /var/spool/locks myself. > /var/spool/uucp exists. > > But rxtx didn't find any port. > > I compiled the source with my own debug-informations > and I tried to isolate the problem. > > The problem is the testRead-call in SerialImp.c > > JNIEXPORT jboolean JNICALL RXTXCommDriver(testRead)( > > ... > if ( READ( fd, &c, 1 ) < 0 ) > { > if ( errno != EAGAIN ) { > report( "testRead() read failed\n" ); > ret = JNI_FALSE; > } > } > Thanks Andreas I'm packing up to move. I'll be more or less away for a couple weeks here. I'll be checking email but my workstation is going into a box soon. This isn't hard to fix as this port should be enumerated when EWOULDBLOCK is recieved. Thats error is OK for enumeration just as EAGAIN is. I've put the bug into bugzilla so we dont forget to get to it. http://bugzilla.qbang.org/show_bug.cgi?id=42 You can add yourself to the CC list if you wish to test fixes we provide or even put a patch into bugzilla yourself. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Fri Mar 24 11:51:52 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 24 Mar 2006 11:51:52 -0700 (MST) Subject: [Rxtx] JavaPOS In-Reply-To: <20060324082238.66371.qmail@web38214.mail.mud.yahoo.com> References: <20060324082238.66371.qmail@web38214.mail.mud.yahoo.com> Message-ID: On Fri, 24 Mar 2006, Maximulo Majir wrote: > Hi all! Hello Trent! > > > From what i understand, RXTX or JavaComm APIs were not > created solely for JavaPOS. In JavaPOS, we have the virtual method > claim() which is separate from open(), but in our RXTX API, claiming is > done every call to open(), we cant open the port if its claimed by > another application. Would it be alright to suggest or ask to create a > new method called claim(..)? Is there such thing as forceclaim() in > RXTX? this could be the same as portownership transfer or its > equivalent. ForceClaim is in JSR80. > Do you have some samples using RXTX as the lower layer for the Device > Service Objects in JavaPOS? I have tried it, i just want to compare. > maxim Hi Maxim JSR80 is the USB API IBM/Sun put together. The problem is they have a richer kernel/API underneath that can handle such things. With Serial Ports, there isnt anything there other than an ioctl that says don't let anyone touch this and lockfiles that are more of a 'lets be nice.' At times we may be using USB ports but it is through the termios layer with the limitations mentioned. The advantage is that not only USB will work with rxtx. Anything that has a termios layer should work (to the extent that termios layer is complete). I don't know how forceclaim() would help you. Lets say someone has a programmer working on /dev/ttyS0 and you take it. Now you both race each other to read data first. There isn't a mechanism I know of that will solve this problem in termios. The most obvious test being a native app and a Java app trying to take the port. There is the potential of requestion ownership from other Java Applications but the use for that is very rare. Did you have something more specific in mind that I'm missing? I'm not sure that claim() and forceclaim() would help you with rxtx other than maybe locking the port with claim() without opening it. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sat Mar 25 23:42:08 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 25 Mar 2006 23:42:08 -0700 (MST) Subject: [Rxtx] Serial snoop Message-ID: I was reading the Linux kernel mail-list tonight and ran past a thread that mentioned sersnoop. This looks like a handy tool for people dealing with new toys. "a simple command-line tool for linux that echoes bytes to and from any two serial ports, ptys, or network sockets, and prints all traffic to stdout, in hex and ascii." http://www.restivo.org/projects/sersnoop/ It works on Linux only at this time (debian package available). -- Trent Jarvi tjarvi at qbang.org From beat.arnet at gmail.com Sun Mar 26 07:32:35 2006 From: beat.arnet at gmail.com (Beat Arnet) Date: Sun, 26 Mar 2006 09:32:35 -0500 Subject: [Rxtx] Error 0x5 at /home/bob/foo/tar/rxtx-2.1-7/build/../src/termios.c(860): Access is, denied. Message-ID: <4426A603.80508@gmail.com> Dear all, When trying to open the serial port, I sometimes (not always) run into the following exception (when opening the serialPort): Error 0x5 at /home/bob/foo/tar/rxtx-2.1-7/build/../src/termios.c(860): Access is denied. java.lang.UnsatisfiedLinkError: native_psmisc_report_owner at gnu.io.CommPortIdentifier.native_psmisc_report_owner(Native Method) at gnu.io.CommPortIdentifier.open(CommPortIdentifier.java:354) at codeskin.tools.CLLoader.open(CLLoader.java:79) at codeskin.tools.C2000Programmer.run(C2000Programmer.java:220) at java.lang.Thread.run(Unknown Source) Is this the type of error where I should just try to open the port again, or can it be avoided? Regards, Beat From tjarvi at qbang.org Sun Mar 26 11:40:12 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 26 Mar 2006 11:40:12 -0700 (MST) Subject: [Rxtx] Error 0x5 at /home/bob/foo/tar/rxtx-2.1-7/build/../src/termios.c(860): Access is, denied. In-Reply-To: <4426A603.80508@gmail.com> References: <4426A603.80508@gmail.com> Message-ID: On Sun, 26 Mar 2006, Beat Arnet wrote: > Dear all, > > When trying to open the serial port, I sometimes (not always) run into > the following exception (when opening the serialPort): > > Error 0x5 at /home/bob/foo/tar/rxtx-2.1-7/build/../src/termios.c(860): > Access is > denied. > > java.lang.UnsatisfiedLinkError: native_psmisc_report_owner > at gnu.io.CommPortIdentifier.native_psmisc_report_owner(Native > Method) > at gnu.io.CommPortIdentifier.open(CommPortIdentifier.java:354) > at codeskin.tools.CLLoader.open(CLLoader.java:79) > at codeskin.tools.C2000Programmer.run(C2000Programmer.java:220) > at java.lang.Thread.run(Unknown Source) > > Is this the type of error where I should just try to open the port again, > or can it be avoided? > Hi Beat We did a second build of rxtx 2.1-7 to resolve that unsatisfied link error. It should work now. rxtx is trying to tell you it thinks someone else has the serial port open. You can try to open the port again but maybe you already have a copy of the program running when it happens? ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7r2.zip fixed build. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sun Mar 26 11:44:23 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 26 Mar 2006 11:44:23 -0700 (MST) Subject: [Rxtx] RXTX spec file (fwd) Message-ID: This is probably interesting for fedora/suse users. ---------- Forwarded message ---------- Date: Sun, 26 Mar 2006 16:25:45 +0200 To: taj at www.linux.org.uk Subject: RXTX spec file I send you this spec file which allows to create a RPM for Fedora 4, 5 (x86, x86_64) with Java Sun. -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: rxtx.spec Url: http://mailman.qbang.org/pipermail/rxtx/attachments/20060326/6c7b6af6/rxtx-0022.pl From tjarvi at qbang.org Sun Mar 26 23:42:59 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 26 Mar 2006 23:42:59 -0700 (MST) Subject: [Rxtx] Upcomming events. Message-ID: This Wednesday we will be announcing a new "Maintainer" for the rxtx project. The position is more like neutral leader. I wont be going away or doing less. This is just the right thing to do as it turns out the two people with CVS write access will be at the same company. We need a third and we need neutrality. The maintainer will have final say in any conflict and will try to be neutral. It will be open for discussion. Then we will do it :) I'll still do most of the footwork I do now. But. I'm falling behind. I should have gone through the mail-list and posted the next round of changes this weekend. I'm packing to move and its going so so - 13 years of toys collected. I suspect there will be a dead period on my part (a couple weeks) comming up. But if you get it on the mail-list, we will get it in if there are no objections. I may well not be reading the mail-list during this period as I look for a house and many other things. I hope everyone will help out. Thanks -- Trent Jarvi tjarvi at qbang.org From mahmoud_hadad at yahoo.com Sun Mar 26 07:31:19 2006 From: mahmoud_hadad at yahoo.com (ronan nick) Date: Sun, 26 Mar 2006 06:31:19 -0800 (PST) Subject: [Rxtx] a question about the COMM API Message-ID: <20060326143119.54919.qmail@web60014.mail.yahoo.com> hi, i was intrested in knowing how i can communicate with my internal modem using java? for example if i want to make a phone dialer application or a caller id application where should i be looking at? and as i understood the COMM API is for devices that is attached to the computer through serial ports. --------------------------------- New Yahoo! Messenger with Voice. Call regular phones from your PC and save big. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060326/ce8329f0/attachment-0024.html From dmarkman at mac.com Mon Mar 20 00:20:43 2006 From: dmarkman at mac.com (Dmitry Markman) Date: Mon, 20 Mar 2006 02:20:43 -0500 Subject: [Rxtx] Mac OS X RXTX java installer In-Reply-To: References: <07D0DE29-BA32-4CFE-B036-66BC6423D385@buechse.de> <441AE3E0.2030503@willicon.de> <12531986.1142622114996.JavaMail.dmarkman@mac.com> <441B2674.9010409@willicon.de> <13577405.1142634732776.JavaMail.dmarkman@mac.com> <441B4182.8010407@willicon.de> <92CD0D6C-5BE8-426E-A46D-99452059FF49@mac.com> <441BBB2D.8030305@willicon.de> <441C4088.5090905@willicon.de> Message-ID: <64BC1E23-FDDE-4CE6-8863-CFC881CBC224@mac.com> Hi all I put RXTX installer that will install everything (and will create / var/lock if necessary and add user to the uucp group) for mac os x from Java into the rxtx's CVS repository it could be easily modified to install files for any platform it uses Greg Guerin's AuthKit for authentication and authorization Greg released that kit under artistic license, so Trent, please take a look we, probably, can negotiate license with Greg if it's necessary Greg's AuthKit could be downloaded from http://www.amug.org/~glguerin/ sw/#authkit Michael Hall (mikehall at spacestar dot net) had a suggestion to make implementation of the jaas LoginModule based on Greg's AuthKit (his modification of the Greg's AuthKit could be found at http:// www.spacestar.net/users/mikehall/authkit.dmg) but Michael's AuthKitLoginModule does only half a job: it does authenticate but it can not run any external unix process in privileged mode (at least I wasn't able to do so) possible explanation could be found in conversation between Greg and Michael at Apple's java-dev list (look for archives) so I didn't use jaas API for rxtxinstaller I created folder MacOSX in the contrib folder comment 1. if you want to run that installer as standalone application all you need that RXTXInstaller.jar 2. if you want to use webstart you have to add Greg's libAuthKit.jnilib to the mac os x's resources in theory RXTXInstaller.jar doesn't need it, but there is a problem with loading libAuthKit.jnilib from webstart authkit uses loadLibrary method to load library and it failed (from webstart) for standalone application I extract libAuthKit.jnilib from the RXTXInstaller.jar and put it into the /Library/Java/Extensions or ~/Library/Java/Extensions folder that file will be deleted after installer quit unfortunately I didn't have time to put documentation there but it is mostly self-explanatory I took installer code from my gl4java installer that I did about 3 years ago (with small modifications) it would be very nice if Apple will release LoginModule that really will do the job (com.apple.security.auth.module package????? ) (UnixLoginModule is pretty useless) From lyon at docjava.com Mon Mar 20 06:34:39 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Mon, 20 Mar 2006 08:34:39 -0500 Subject: [Rxtx] Mac OS X RXTX java installer In-Reply-To: <64BC1E23-FDDE-4CE6-8863-CFC881CBC224@mac.com> References: <07D0DE29-BA32-4CFE-B036-66BC6423D385@buechse.de> <441AE3E0.2030503@willicon.de> <12531986.1142622114996.JavaMail.dmarkman@mac.com> <441B2674.9010409@willicon.de> <13577405.1142634732776.JavaMail.dmarkman@mac.com> <441B4182.8010407@willicon.de> <92CD0D6C-5BE8-426E-A46D-99452059FF49@mac.com> <441BBB2D.8030305@willicon.de> <441C4088.5090905@willicon.de> <64BC1E23-FDDE-4CE6-8863-CFC881CBC224@mac.com> Message-ID: Hi Dimitry, This sounds like great work. Just a couple of questions; After the check out of the CVS files, using: setenv CVSROOT :pserver:anonymous at cvs.milestonesolutions.com:/usr/local/cvsroot 53 8:28 setenv PASSWORD mousy 54 8:29 cvs login 55 8:29 cvs checkout rxtx-devel I cd'd over to: rxtx-devel/MACOSX_IDE And found: CVS/ CW/ ForPackageMaker/ PB/ Where is the installer? Thanks! - Doug From tjarvi at qbang.org Mon Mar 20 06:39:37 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 20 Mar 2006 06:39:37 -0700 (MST) Subject: [Rxtx] Mac OS X RXTX java installer In-Reply-To: References: <07D0DE29-BA32-4CFE-B036-66BC6423D385@buechse.de> <441AE3E0.2030503@willicon.de> <12531986.1142622114996.JavaMail.dmarkman@mac.com> <441B2674.9010409@willicon.de> <13577405.1142634732776.JavaMail.dmarkman@mac.com> <441B4182.8010407@willicon.de> <92CD0D6C-5BE8-426E-A46D-99452059FF49@mac.com> <441BBB2D.8030305@willicon.de> <441C4088.5090905@willicon.de> <64BC1E23-FDDE-4CE6-8863-CFC881CBC224@mac.com> Message-ID: On Mon, 20 Mar 2006, Dr. Douglas Lyon wrote: > Hi Dimitry, > This sounds like great work. Just a couple of questions; > After the check out of the CVS files, using: > setenv CVSROOT > :pserver:anonymous at cvs.milestonesolutions.com:/usr/local/cvsroot > 53 8:28 setenv PASSWORD mousy > 54 8:29 cvs login > 55 8:29 cvs checkout rxtx-devel Hi Doug You want "cvs checkout -r commapi-0-0-1 rxtx-devel" to get RXTX 2.1 The default branch is rxtx 2.0 which isn't very active right now. -- Trent Jarvi tjarvi at qbang.org From lyon at docjava.com Mon Mar 20 07:05:44 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Mon, 20 Mar 2006 09:05:44 -0500 Subject: [Rxtx] Mac OS X RXTX java installer In-Reply-To: References: <07D0DE29-BA32-4CFE-B036-66BC6423D385@buechse.de> <441AE3E0.2030503@willicon.de> <12531986.1142622114996.JavaMail.dmarkman@mac.com> <441B2674.9010409@willicon.de> <13577405.1142634732776.JavaMail.dmarkman@mac.com> <441B4182.8010407@willicon.de> <92CD0D6C-5BE8-426E-A46D-99452059FF49@mac.com> <441BBB2D.8030305@willicon.de> <441C4088.5090905@willicon.de> <64BC1E23-FDDE-4CE6-8863-CFC881CBC224@mac.com> Message-ID: Hi Trent, Thanks for the info on the CVS checkout procedure. I did that and am still not sure where the installer is. Here is what I have: cd MACOSX_IDE/ p4.docjava.com{lyon}121: ls CVS/ ForPackageMaker/ PB/ p4.docjava.com{lyon}122: find . | more . ./ForPackageMaker ./ForPackageMaker/RXTX.pkg.sit.hqx ./ForPackageMaker/Resources ./ForPackageMaker/Resources/ReadMe.rtf ./ForPackageMaker/Resources/Welcome.rtf ./ForPackageMaker/Resources/CVS ./ForPackageMaker/Resources/CVS/Entries ./ForPackageMaker/Resources/CVS/Repository ./ForPackageMaker/Resources/CVS/Tag ./ForPackageMaker/Resources/CVS/Root ./ForPackageMaker/Resources/preinstall ./ForPackageMaker/Resources/License.rtf ./ForPackageMaker/Resources/preupgrade ./ForPackageMaker/RXTX.pmsp ./ForPackageMaker/CVS ./ForPackageMaker/CVS/Entries ./ForPackageMaker/CVS/Repository ./ForPackageMaker/CVS/Entries.Log ./ForPackageMaker/CVS/Tag ./ForPackageMaker/CVS/Root ./ForPackageMaker/RXTX_Tiger.pkg.sitx.hqx ./ForPackageMaker/RXTX_Jag.pkg.sit.hqx ./ForPackageMaker/Install ./ForPackageMaker/Install/CVS ./ForPackageMaker/Install/CVS/Entries ./ForPackageMaker/Install/CVS/Repository ./ForPackageMaker/Install/CVS/Tag ./ForPackageMaker/Install/CVS/Root ./ForPackageMaker/Install/Library ./ForPackageMaker/Install/Library/CVS ./ForPackageMaker/Install/Library/CVS/Entries ./ForPackageMaker/Install/Library/CVS/Repository ./ForPackageMaker/Install/Library/CVS/Tag ./ForPackageMaker/Install/Library/CVS/Root ./ForPackageMaker/Install/Library/Java ./ForPackageMaker/Install/Library/Java/Extensions ./ForPackageMaker/Install/Library/Java/Extensions/RXTXcomm.jar ./ForPackageMaker/Install/Library/Java/Extensions/CVS ./ForPackageMaker/Install/Library/Java/Extensions/CVS/Entries ./ForPackageMaker/Install/Library/Java/Extensions/CVS/Repository ./ForPackageMaker/Install/Library/Java/Extensions/CVS/Tag ./ForPackageMaker/Install/Library/Java/Extensions/CVS/Root ./ForPackageMaker/Install/Library/Java/Extensions/librxtxSerial.jnilib ./ForPackageMaker/Install/Library/Java/CVS ./ForPackageMaker/Install/Library/Java/CVS/Entries ./ForPackageMaker/Install/Library/Java/CVS/Repository ./ForPackageMaker/Install/Library/Java/CVS/Entries.Log ./ForPackageMaker/Install/Library/Java/CVS/Tag ./ForPackageMaker/Install/Library/Java/CVS/Root ./ForPackageMaker/RXTX_Tiger.pmproj.sitx.hqx ./CVS ./CVS/Entries ./CVS/Repository ./CVS/Entries.Log ./CVS/Tag ./CVS/Root ./PB ./PB/LibSerialUniversal.xcodeproj.sitx.hqx ./PB/CVS ./PB/CVS/Entries ./PB/CVS/Repository ./PB/CVS/Entries.Log ./PB/CVS/Tag ./PB/CVS/Root ./PB/LibSerial.pbproj.sit.hqx ./PB/startpoint.c ./PB/config.h What is the procedure to run this installer? Do we need a README in: /rxtx-devel/MACOSX_IDE Here is what we have: CVS/ ForPackageMaker/ PB/ Thanks! - DL >On Mon, 20 Mar 2006, Dr. Douglas Lyon wrote: > >>Hi Dimitry, >>This sounds like great work. Just a couple of questions; >>After the check out of the CVS files, using: >>setenv CVSROOT >>:pserver:anonymous at cvs.milestonesolutions.com:/usr/local/cvsroot >> 53 8:28 setenv PASSWORD mousy >> 54 8:29 cvs login >> 55 8:29 cvs checkout rxtx-devel > >Hi Doug > >You want "cvs checkout -r commapi-0-0-1 rxtx-devel" to get RXTX 2.1 >The default branch is rxtx 2.0 which isn't very active right now. > >-- >Trent Jarvi >tjarvi at qbang.org From tjarvi at qbang.org Mon Mar 20 07:25:30 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 20 Mar 2006 07:25:30 -0700 (MST) Subject: [Rxtx] Mac OS X RXTX java installer In-Reply-To: References: <07D0DE29-BA32-4CFE-B036-66BC6423D385@buechse.de> <441AE3E0.2030503@willicon.de> <12531986.1142622114996.JavaMail.dmarkman@mac.com> <441B2674.9010409@willicon.de> <13577405.1142634732776.JavaMail.dmarkman@mac.com> <441B4182.8010407@willicon.de> <92CD0D6C-5BE8-426E-A46D-99452059FF49@mac.com> <441BBB2D.8030305@willicon.de> <441C4088.5090905@willicon.de> <64BC1E23-FDDE-4CE6-8863-CFC881CBC224@mac.com> Message-ID: On Mon, 20 Mar 2006, Dr. Douglas Lyon wrote: > Hi Trent, > Thanks for the info on the CVS checkout procedure. > I did that and am still not sure where the installer is. Hi Doug It does look like it was not cvs committed. There is no rxtx-devel/contrib/MacOSX directory in there at the moment. It was mentioned that it was put under contrib. -- Trent Jarvi tjarvi at qbang.org From dmarkman at mac.com Mon Mar 20 07:29:56 2006 From: dmarkman at mac.com (Dmitry Markman) Date: Mon, 20 Mar 2006 09:29:56 -0500 Subject: [Rxtx] Mac OS X RXTX java installer In-Reply-To: References: <07D0DE29-BA32-4CFE-B036-66BC6423D385@buechse.de> <441AE3E0.2030503@willicon.de> <12531986.1142622114996.JavaMail.dmarkman@mac.com> <441B2674.9010409@willicon.de> <13577405.1142634732776.JavaMail.dmarkman@mac.com> <441B4182.8010407@willicon.de> <92CD0D6C-5BE8-426E-A46D-99452059FF49@mac.com> <441BBB2D.8030305@willicon.de> <441C4088.5090905@willicon.de> <64BC1E23-FDDE-4CE6-8863-CFC881CBC224@mac.com> Message-ID: <6054EB4E-F7E0-4A9C-BDDA-D582D6D8826F@mac.com> you can find it in the rxtx-devel/contrib folder On Mar 20, 2006, at 9:05 AM, Dr. Douglas Lyon wrote: > Hi Trent, > Thanks for the info on the CVS checkout procedure. > I did that and am still not sure where the installer is. > Here is what I have: > cd MACOSX_IDE/ > p4.docjava.com{lyon}121: ls > CVS/ ForPackageMaker/ PB/ > p4.docjava.com{lyon}122: find . | more > . > ./ForPackageMaker > ./ForPackageMaker/RXTX.pkg.sit.hqx > ./ForPackageMaker/Resources > ./ForPackageMaker/Resources/ReadMe.rtf > ./ForPackageMaker/Resources/Welcome.rtf > ./ForPackageMaker/Resources/CVS > ./ForPackageMaker/Resources/CVS/Entries > ./ForPackageMaker/Resources/CVS/Repository > ./ForPackageMaker/Resources/CVS/Tag > ./ForPackageMaker/Resources/CVS/Root > ./ForPackageMaker/Resources/preinstall > ./ForPackageMaker/Resources/License.rtf > ./ForPackageMaker/Resources/preupgrade > ./ForPackageMaker/RXTX.pmsp > ./ForPackageMaker/CVS > ./ForPackageMaker/CVS/Entries > ./ForPackageMaker/CVS/Repository > ./ForPackageMaker/CVS/Entries.Log > ./ForPackageMaker/CVS/Tag > ./ForPackageMaker/CVS/Root > ./ForPackageMaker/RXTX_Tiger.pkg.sitx.hqx > ./ForPackageMaker/RXTX_Jag.pkg.sit.hqx > ./ForPackageMaker/Install > ./ForPackageMaker/Install/CVS > ./ForPackageMaker/Install/CVS/Entries > ./ForPackageMaker/Install/CVS/Repository > ./ForPackageMaker/Install/CVS/Tag > ./ForPackageMaker/Install/CVS/Root > ./ForPackageMaker/Install/Library > ./ForPackageMaker/Install/Library/CVS > ./ForPackageMaker/Install/Library/CVS/Entries > ./ForPackageMaker/Install/Library/CVS/Repository > ./ForPackageMaker/Install/Library/CVS/Tag > ./ForPackageMaker/Install/Library/CVS/Root > ./ForPackageMaker/Install/Library/Java > ./ForPackageMaker/Install/Library/Java/Extensions > ./ForPackageMaker/Install/Library/Java/Extensions/RXTXcomm.jar > ./ForPackageMaker/Install/Library/Java/Extensions/CVS > ./ForPackageMaker/Install/Library/Java/Extensions/CVS/Entries > ./ForPackageMaker/Install/Library/Java/Extensions/CVS/Repository > ./ForPackageMaker/Install/Library/Java/Extensions/CVS/Tag > ./ForPackageMaker/Install/Library/Java/Extensions/CVS/Root > ./ForPackageMaker/Install/Library/Java/Extensions/librxtxSerial.jnilib > ./ForPackageMaker/Install/Library/Java/CVS > ./ForPackageMaker/Install/Library/Java/CVS/Entries > ./ForPackageMaker/Install/Library/Java/CVS/Repository > ./ForPackageMaker/Install/Library/Java/CVS/Entries.Log > ./ForPackageMaker/Install/Library/Java/CVS/Tag > ./ForPackageMaker/Install/Library/Java/CVS/Root > ./ForPackageMaker/RXTX_Tiger.pmproj.sitx.hqx > ./CVS > ./CVS/Entries > ./CVS/Repository > ./CVS/Entries.Log > ./CVS/Tag > ./CVS/Root > ./PB > ./PB/LibSerialUniversal.xcodeproj.sitx.hqx > ./PB/CVS > ./PB/CVS/Entries > ./PB/CVS/Repository > ./PB/CVS/Entries.Log > ./PB/CVS/Tag > ./PB/CVS/Root > ./PB/LibSerial.pbproj.sit.hqx > ./PB/startpoint.c > ./PB/config.h > > What is the procedure to run this installer? > Do we need a README in: > /rxtx-devel/MACOSX_IDE > Here is what we have: > CVS/ ForPackageMaker/ PB/ > > > Thanks! > - DL > >> On Mon, 20 Mar 2006, Dr. Douglas Lyon wrote: >> >>> Hi Dimitry, >>> This sounds like great work. Just a couple of questions; >>> After the check out of the CVS files, using: >>> setenv CVSROOT :pserver:anonymous at cvs.milestonesolutions.com:/usr/ >>> local/cvsroot >>> 53 8:28 setenv PASSWORD mousy >>> 54 8:29 cvs login >>> 55 8:29 cvs checkout rxtx-devel >> >> Hi Doug >> >> You want "cvs checkout -r commapi-0-0-1 rxtx-devel" to get RXTX 2.1 >> The default branch is rxtx 2.0 which isn't very active right now. >> >> -- >> Trent Jarvi >> tjarvi at qbang.org > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx Dmitry Markman From mikehall at spacestar.net Mon Mar 20 05:25:25 2006 From: mikehall at spacestar.net (Michael Hall) Date: Mon, 20 Mar 2006 06:25:25 -0600 Subject: [Rxtx] Re: Mac OS X RXTX java installer In-Reply-To: <64BC1E23-FDDE-4CE6-8863-CFC881CBC224@mac.com> References: <07D0DE29-BA32-4CFE-B036-66BC6423D385@buechse.de> <441AE3E0.2030503@willicon.de> <12531986.1142622114996.JavaMail.dmarkman@mac.com> <441B2674.9010409@willicon.de> <13577405.1142634732776.JavaMail.dmarkman@mac.com> <441B4182.8010407@willicon.de> <92CD0D6C-5BE8-426E-A46D-99452059FF49@mac.com> <441BBB2D.8030305@willicon.de> <441C4088.5090905@willicon.de> <64BC1E23-FDDE-4CE6-8863-CFC881CBC224@mac.com> Message-ID: <247EB61F-5CD1-4132-89A2-FC105B6CF9A5@spacestar.net> On Mar 20, 2006, at 1:20 AM, Dmitry Markman wrote: > > Michael Hall (mikehall at spacestar dot net) had a suggestion to > make implementation of the jaas LoginModule > based on Greg's AuthKit > (his modification of the Greg's AuthKit could be found at http:// > www.spacestar.net/users/mikehall/authkit.dmg) > but Michael's AuthKitLoginModule does only half a job: > it does authenticate > but it can not run any external unix process in privileged mode (at > least I wasn't able to do so) If you got it working directly with Greg's the point is moot. But to clarify it anyhow. The login module does not allow you to do anything anything privileged on return as was explained by Greg. You need to work with a separate privileged process using the execPrivileged method of his API. I assume you did something similar although I haven't looked at how you are using it yet. I allowed instead for a action to be performed at the same time you login/authenticate,this... System.setProperty("authkit.action","/usr/bin/id"); just before this... lc.login(); To clarify, safely ignored as you are already complete. Mike Hall mikehall at spacestar dot net http://www.spacestar.net/users/mikehall http://sourceforge.net/projects/macnative -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2427 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20060320/f6e18202/smime-0027.bin From dmarkman at mac.com Mon Mar 20 07:36:47 2006 From: dmarkman at mac.com (Dmitry Markman) Date: Mon, 20 Mar 2006 09:36:47 -0500 Subject: [Rxtx] Re: Mac OS X RXTX java installer In-Reply-To: <247EB61F-5CD1-4132-89A2-FC105B6CF9A5@spacestar.net> References: <07D0DE29-BA32-4CFE-B036-66BC6423D385@buechse.de> <441AE3E0.2030503@willicon.de> <12531986.1142622114996.JavaMail.dmarkman@mac.com> <441B2674.9010409@willicon.de> <13577405.1142634732776.JavaMail.dmarkman@mac.com> <441B4182.8010407@willicon.de> <92CD0D6C-5BE8-426E-A46D-99452059FF49@mac.com> <441BBB2D.8030305@willicon.de> <441C4088.5090905@willicon.de> <64BC1E23-FDDE-4CE6-8863-CFC881CBC224@mac.com> <247EB61F-5CD1-4132-89A2-FC105B6CF9A5@spacestar.net> Message-ID: Hi, Michael all I have to do is to run some shell script I tried to use your action mechanism and it worked great so I just System.setProperty ("authkit.action","" ) and after that I even don't need to run anything like subject.doAs.... but after few thoughts I choose to use plain Greg's approach, because in that case I don't have to deal with various java's configurations files and therefore to use 2-3 -D parameters in the java command line especially it's useful for java web start (it's so fragile :-( ) thanks for the great job On Mar 20, 2006, at 7:25 AM, Michael Hall wrote: > > On Mar 20, 2006, at 1:20 AM, Dmitry Markman wrote: >> >> Michael Hall (mikehall at spacestar dot net) had a suggestion to >> make implementation of the jaas LoginModule >> based on Greg's AuthKit >> (his modification of the Greg's AuthKit could be found at http:// >> www.spacestar.net/users/mikehall/authkit.dmg) >> but Michael's AuthKitLoginModule does only half a job: >> it does authenticate >> but it can not run any external unix process in privileged mode >> (at least I wasn't able to do so) > > If you got it working directly with Greg's the point is moot. > > But to clarify it anyhow. > The login module does not allow you to do anything anything > privileged on return as was explained by Greg. You need to work > with a separate privileged process using the execPrivileged method > of his API. I assume you did something similar although I haven't > looked at how you are using it yet. > I allowed instead for a action to be performed at the same time you > login/authenticate,this... > System.setProperty("authkit.action","/usr/bin/id"); > just before this... > lc.login(); > To clarify, safely ignored as you are already complete. > > Mike Hall mikehall at spacestar dot net > http://www.spacestar.net/users/mikehall > http://sourceforge.net/projects/macnative > > > Dmitry Markman From dmarkman at mac.com Mon Mar 20 07:44:45 2006 From: dmarkman at mac.com (Dmitry Markman) Date: Mon, 20 Mar 2006 09:44:45 -0500 Subject: [Rxtx] Mac OS X RXTX java installer In-Reply-To: References: <07D0DE29-BA32-4CFE-B036-66BC6423D385@buechse.de> <441AE3E0.2030503@willicon.de> <12531986.1142622114996.JavaMail.dmarkman@mac.com> <441B2674.9010409@willicon.de> <13577405.1142634732776.JavaMail.dmarkman@mac.com> <441B4182.8010407@willicon.de> <92CD0D6C-5BE8-426E-A46D-99452059FF49@mac.com> <441BBB2D.8030305@willicon.de> <441C4088.5090905@willicon.de> <64BC1E23-FDDE-4CE6-8863-CFC881CBC224@mac.com> Message-ID: it's in the commapi-0-0-1 branch I tested it right now: cvs co -r commapi-0-0-1 rxtx-devel and I got everything On Mar 20, 2006, at 9:25 AM, Trent Jarvi wrote: > On Mon, 20 Mar 2006, Dr. Douglas Lyon wrote: > >> Hi Trent, >> Thanks for the info on the CVS checkout procedure. >> I did that and am still not sure where the installer is. > > Hi Doug > > It does look like it was not cvs committed. There is no rxtx-devel/ > contrib/MacOSX directory in there at the moment. It was mentioned > that it was put under contrib. > > -- > Trent Jarvi > tjarvi at qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx Dmitry Markman From tjarvi at qbang.org Mon Mar 20 07:52:57 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 20 Mar 2006 07:52:57 -0700 (MST) Subject: [Rxtx] Mac OS X RXTX java installer In-Reply-To: References: <07D0DE29-BA32-4CFE-B036-66BC6423D385@buechse.de> <441AE3E0.2030503@willicon.de> <12531986.1142622114996.JavaMail.dmarkman@mac.com> <441B2674.9010409@willicon.de> <13577405.1142634732776.JavaMail.dmarkman@mac.com> <441B4182.8010407@willicon.de> <92CD0D6C-5BE8-426E-A46D-99452059FF49@mac.com> <441BBB2D.8030305@willicon.de> <441C4088.5090905@willicon.de> <64BC1E23-FDDE-4CE6-8863-CFC881CBC224@mac.com> Message-ID: On Mon, 20 Mar 2006, Dmitry Markman wrote: > it's in the commapi-0-0-1 branch > > I tested it right now: > cvs co -r commapi-0-0-1 rxtx-devel > > and I got everything > A fresh checkout worked. Here is a copy of the tree (just the installer bits) ftp://ftp.qbang.org/pub/rxtx/MacOSX-installer.zip -- Trent Jarvi tjarvi at qbang.org From lyon at docjava.com Mon Mar 20 08:08:26 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Mon, 20 Mar 2006 10:08:26 -0500 Subject: [Rxtx] Mac OS X RXTX java installer In-Reply-To: References: <07D0DE29-BA32-4CFE-B036-66BC6423D385@buechse.de> <441AE3E0.2030503@willicon.de> <12531986.1142622114996.JavaMail.dmarkman@mac.com> <441B2674.9010409@willicon.de> <13577405.1142634732776.JavaMail.dmarkman@mac.com> <441B4182.8010407@willicon.de> <92CD0D6C-5BE8-426E-A46D-99452059FF49@mac.com> <441BBB2D.8030305@willicon.de> <441C4088.5090905@willicon.de> <64BC1E23-FDDE-4CE6-8863-CFC881CBC224@mac.com> Message-ID: Hi All, Is the Auth package able to work properly on non Mac OS's? It was not clear from the doc or download. Thanks! - Doug From dmarkman at mac.com Mon Mar 20 08:15:22 2006 From: dmarkman at mac.com (Dmitry Markman) Date: Mon, 20 Mar 2006 10:15:22 -0500 Subject: [Rxtx] Mac OS X RXTX java installer In-Reply-To: References: <07D0DE29-BA32-4CFE-B036-66BC6423D385@buechse.de> <441AE3E0.2030503@willicon.de> <12531986.1142622114996.JavaMail.dmarkman@mac.com> <441B2674.9010409@willicon.de> <13577405.1142634732776.JavaMail.dmarkman@mac.com> <441B4182.8010407@willicon.de> <92CD0D6C-5BE8-426E-A46D-99452059FF49@mac.com> <441BBB2D.8030305@willicon.de> <441C4088.5090905@willicon.de> <64BC1E23-FDDE-4CE6-8863-CFC881CBC224@mac.com> Message-ID: <217312D8-CCCA-4859-ABA6-32DF1CC817B9@mac.com> thanks Trent, for putting it on ftp server On Mar 20, 2006, at 9:52 AM, Trent Jarvi wrote: > A fresh checkout worked. Here is a copy of the tree (just the > installer bits) > > ftp://ftp.qbang.org/pub/rxtx/MacOSX-installer.zip > Dmitry Markman From dmarkman at mac.com Mon Mar 20 09:14:03 2006 From: dmarkman at mac.com (Dmitry Markman) Date: Mon, 20 Mar 2006 11:14:03 -0500 Subject: [Rxtx] Mac OS X RXTX java installer In-Reply-To: References: <07D0DE29-BA32-4CFE-B036-66BC6423D385@buechse.de> <441AE3E0.2030503@willicon.de> <12531986.1142622114996.JavaMail.dmarkman@mac.com> <441B2674.9010409@willicon.de> <13577405.1142634732776.JavaMail.dmarkman@mac.com> <441B4182.8010407@willicon.de> <92CD0D6C-5BE8-426E-A46D-99452059FF49@mac.com> <441BBB2D.8030305@willicon.de> <441C4088.5090905@willicon.de> <64BC1E23-FDDE-4CE6-8863-CFC881CBC224@mac.com> Message-ID: <4DEBA6F0-DA45-4E84-823E-1F1AC48BDCCC@mac.com> no it will work only on mac os x however it's harmless to run it on other platform if you want to use it for other platform you have to do the following (I'll do it for linux) 1. modify RXTXInstaller class method public static RXTXInstaller getInstance() public static RXTXInstaller getInstance() { String osName = System.getProperty("os.name").toLowerCase(); if(osName.startsWith("mac")){ return new gnu.io.installer.macosx.MACOSXRXTXInstaller(); } else if(osName.startsWith("windows")){ return new gnu.io.installer.windows.WindowsRXTXInstaller(); }else if(osName.startsWith("linux")){ return new gnu.io.installer.linux.LinuxRXTXInstaller(); } return null; } 2. create folder gnu/io/installer/linux/ 3. create class Linux386RXTXInstaller package gnu.io.installer.linux; import java.io.File; public class Linux386RXTXInstaller extends gnu.io.installer.RXTXInstaller{ public Linux386RXTXInstaller(){ createJarFolder(); createLibFolder(); addJarResource("RXTXcomm.jar","/gnu/io/installer/resources/ linux/jar/RXTXcomm.dat"); addLibResource("librxtxSerial.so","/gnu/io/installer/ resources/linux/lib/librxtxSerial.so"); } protected void createJarFolder(){ String javaHome = System.getProperty("java.home"); char separator = File.separatorChar; jarFolder = new File(javaHome+separator+"lib"+separator+"ext"); } protected void createLibFolder(){ String javaHome = System.getProperty("java.home"); char separator = File.separatorChar; libFolder = new File(javaHome+separator+"bin"); } public void runPreProcess() {} //put here some action you need public void runPostProcess() {} //put here some action you need } 4. create folder /gnu/io/installer/resources/linux/jar and put there linux's version of RXTXcomm.dat (which is renamed RXTXcomm.jar) 5. create folder /gnu/io/installer/resources/linux/lib and put there linux's version of librxtxSerial. so 6. make sure that RXTXInstaller.jar has the following items: /gnu/io/installer/resources/linux/jar/RXTXcomm.jar /gnu/io/installer/resources/linux/lib/librxtxSerial.so 7. modify file installer.pref: jar file RXTXInstaller.jar must have the following item /gnu/io/installer/installer.pref that's basically it for windows you have to do the similar things: just replace linux to windows and librxtxSerial.so to rxtxSerial.dll and create appropriate gnu.io.installer.windows.WindowsRXTXInstaller class package gnu.io.installer.windows; import java.io.File; public class WindowsRXTXInstaller extends gnu.io.installer.RXTXInstaller{ public WindowsRXTXInstaller(){ createJarFolder(); createLibFolder(); addJarResource("RXTXcomm.jar","/gnu/io/installer/resources/ windows/jar/RXTXcomm.dat"); addLibResource("librxtxSerial.so","/gnu/io/installer/ resources/windows/lib/rxtxSerial.dll"); } protected void createJarFolder(){ String javaHome = System.getProperty("java.home"); char separator = File.separatorChar; jarFolder = new File(javaHome+separator+"lib"+separator+"ext"); } protected void createLibFolder(){ String javaHome = System.getProperty("java.home"); char separator = File.separatorChar; libFolder = new File(javaHome+separator+"bin"); } public void runPreProcess() {} //put here some action you need public void runPostProcess() {} //put here some action you need } installer.pref will look like On Mar 20, 2006, at 10:08 AM, Dr. Douglas Lyon wrote: > Hi All, > Is the Auth package able to work properly on > non Mac OS's? > It was not clear from the doc or download. > > Thanks! > - Doug > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx Dmitry Markman From joachim at buechse.de Mon Mar 20 10:49:06 2006 From: joachim at buechse.de (Joachim Buechse) Date: Mon, 20 Mar 2006 18:49:06 +0100 Subject: [Rxtx] BUG: Lock file stays even if port opening fails Message-ID: This was only tested on MacOSX but looking at the code, it should be true for all systems that use lock_uucp. I am opening a port which can not be opened (dialup port of a telephone paired via bluetooth but currently not reachable). The lock file is created and stays arround, even though the port open failed. After looking a bit through the code (of 2.17), I really wonder if it wouldn't be a good idea to make the "locking" an explicit operation called from the java code. This would certainly simplify the generation of meaningfull exceptions (and java based debugging). Maybe even the handling of "preopened" ports should be in the Java part of the lib (again for java based debugging puposes). That beeing said, I have no idea if this would be possible for the 2.07 implementation. Regards, Joachim From tjarvi at qbang.org Mon Mar 20 11:24:22 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 20 Mar 2006 11:24:22 -0700 (MST) Subject: [Rxtx] BUG: Lock file stays even if port opening fails In-Reply-To: References: Message-ID: On Mon, 20 Mar 2006, Joachim Buechse wrote: > This was only tested on MacOSX but looking at the code, it should be true > for all systems that use lock_uucp. > > I am opening a port which can not be opened (dialup port of a telephone > paired via bluetooth but currently not reachable). The lock file is > created and stays arround, even though the port open failed. > > > After looking a bit through the code (of 2.17), I really wonder if it > wouldn't be a good idea to make the "locking" an explicit operation > called from the java code. This would certainly simplify the generation > of meaningfull exceptions (and java based debugging). > Maybe even the handling of "preopened" ports should be in the Java part > of the lib (again for java based debugging puposes). That beeing said, I > have no idea if this would be possible for the 2.07 implementation. > > Regards, Hi Joachim It should be possible in the 2.0-7 implementation too. The calls to RXTXPort.java would not change. We would just do more there Moving more of that logic into Java would be better as many people don't like to look at C code. There is a liblockdev on most Linux distros that can do most of the C code and would be easier to use. The problem is embeded devices will not have that library. The preopened port code has not been really tested. That was a last minute request in a product cycle. I expect it will be tested this year though. As I recall, some devices really do not like CD raising on open. The preopened ports then allow people to mess around in java without power cycling the devices or losing data. -- Trent Jarvi tjarvi at qbang.org From joachim at buechse.de Mon Mar 20 12:01:08 2006 From: joachim at buechse.de (Joachim Buechse) Date: Mon, 20 Mar 2006 20:01:08 +0100 Subject: [Rxtx] BUG: Lock file stays even if port opening fails In-Reply-To: References: Message-ID: Hi Trent, What is your general feeling about moving code to Java? The last days I have been reading quite a bit of the code and there are several things, that might not work as expected. I'll give you two examples from is_device_locked: if LOCKDIR == /var/spool/locks the directory /var/spool/lock will not be checked. LOCKDIR is not checked for lockfiles with unexpected pefixes While these things have probably never been discovered in production, they are still possibly incorrect implementations. If it was Java code, I would write some unit tests producing the errors that could later be corrected. PS: One could imagine to actually implement the whole lockfile handling in Java using some native routines to get the values required (pid, st_dev, st_rdev, ...). On 20.03.2006, at 19:24, Trent Jarvi wrote: > On Mon, 20 Mar 2006, Joachim Buechse wrote: > >> This was only tested on MacOSX but looking at the code, it should >> be true for all systems that use lock_uucp. >> >> I am opening a port which can not be opened (dialup port of a >> telephone paired via bluetooth but currently not reachable). The >> lock file is created and stays arround, even though the port open >> failed. >> >> >> After looking a bit through the code (of 2.17), I really wonder if >> it wouldn't be a good idea to make the "locking" an explicit >> operation called from the java code. This would certainly simplify >> the generation of meaningfull exceptions (and java based debugging). >> Maybe even the handling of "preopened" ports should be in the Java >> part of the lib (again for java based debugging puposes). That >> beeing said, I have no idea if this would be possible for the 2.07 >> implementation. >> >> Regards, > > Hi Joachim > > It should be possible in the 2.0-7 implementation too. The calls > to RXTXPort.java would not change. We would just do more there > Moving more of that logic into Java would be better as many people > don't like to look at C code. There is a liblockdev on most Linux > distros that can do most of the C code and would be easier to use. > The problem is embeded devices will not have that library. > > The preopened port code has not been really tested. That was a > last minute request in a product cycle. I expect it will be tested > this year though. As I recall, some devices really do not like CD > raising on open. The preopened ports then allow people to mess > around in java without power cycling the devices or losing data. > > -- > Trent Jarvi > tjarvi at qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Mon Mar 20 12:21:02 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 20 Mar 2006 12:21:02 -0700 (MST) Subject: [Rxtx] BUG: Lock file stays even if port opening fails In-Reply-To: References: Message-ID: On Mon, 20 Mar 2006, Joachim Buechse wrote: > Hi Trent, > > What is your general feeling about moving code to Java? The last days I > have been reading quite a bit of the code and there are several things, > that might not work as expected. > > I'll give you two examples from is_device_locked: > > if LOCKDIR == /var/spool/locks the directory /var/spool/lock will not be > checked. > LOCKDIR is not checked for lockfiles with unexpected pefixes > > While these things have probably never been discovered in production, > they are still possibly incorrect implementations. If it was Java code, I > would write some unit tests producing the errors that could later be > corrected. > > PS: One could imagine to actually implement the whole lockfile handling > in Java using some native routines to get the values required (pid, > st_dev, st_rdev, ...). Hi Joachim I like the idea of moving more of the code into java but there are some things to consider. If you break this into multiple JNI calls, the performance will drop considerably during enumeration of ports. We are looking for 256 ports per dev type vs (16? in Sun's 2.0 and fewer types). Its hard to make assumptions. I've seen virtual ports start at /dev/foo100 for instance. It works out to over 7500 ports on Linux if you enable them all. We already trim that back by default. See Linux-all-ports in RXTXCommDriver.java. There are also native libraries that rxtx can link to. If you move too much into Java, linking to 'standard' libraries with distros will break. "configure --enable-liblock=yes" will not be doable. This is probably a favorable way with RedHat, Debian, Suse and others. Thats the right thing to do if there will be rpms, dpkg, .. For those reasons, I think it still make sense to keep it to a minimal ~3 calls to JNI code that we can use for speed and versatility. lock() isLocked(), unlock() perhaps. When I say speed, its more about avoiding crossing the JNI layer multiple times than java vs C performance. With versatility I think liblock is the right way for most but not all (embeded) linux distros. -- Trent Jarvi tjarvi at qbang.org From joachim at buechse.de Mon Mar 20 12:42:04 2006 From: joachim at buechse.de (Joachim Buechse) Date: Mon, 20 Mar 2006 20:42:04 +0100 Subject: [Rxtx] BUG: Lock file stays even if port opening fails In-Reply-To: References: Message-ID: <82C19FE7-DDCB-45B6-B2C9-7606B66F0124@buechse.de> Ok, what about providing a default implementation in Java? The RXTXCommDriver would call a (native) function useNativeLocking and if it returns true, call the native functions for lock() isLocked (), unlock(), else is would use the Java based default implementation. This could possibly be overriden by a property (again for debugging). Joachim On 20.03.2006, at 20:21, Trent Jarvi wrote: > On Mon, 20 Mar 2006, Joachim Buechse wrote: > >> Hi Trent, >> >> What is your general feeling about moving code to Java? The last >> days I have been reading quite a bit of the code and there are >> several things, that might not work as expected. >> >> I'll give you two examples from is_device_locked: >> >> if LOCKDIR == /var/spool/locks the directory /var/spool/lock will >> not be checked. >> LOCKDIR is not checked for lockfiles with unexpected pefixes >> >> While these things have probably never been discovered in >> production, they are still possibly incorrect implementations. If >> it was Java code, I would write some unit tests producing the >> errors that could later be corrected. >> >> PS: One could imagine to actually implement the whole lockfile >> handling in Java using some native routines to get the values >> required (pid, st_dev, st_rdev, ...). > > Hi Joachim > > I like the idea of moving more of the code into java but there are > some things to consider. > > If you break this into multiple JNI calls, the performance will > drop considerably during enumeration of ports. We are looking for > 256 ports per dev type vs (16? in Sun's 2.0 and fewer types). Its > hard to make assumptions. I've seen virtual ports start at /dev/ > foo100 for instance. > > It works out to over 7500 ports on Linux if you enable them all. > We already trim that back by default. See Linux-all-ports in > RXTXCommDriver.java. > > There are also native libraries that rxtx can link to. If you move > too much into Java, linking to 'standard' libraries with distros > will break. "configure --enable-liblock=yes" will not be doable. > This is probably a favorable way with RedHat, Debian, Suse and > others. Thats the right thing to do if there will be rpms, dpkg, .. > > For those reasons, I think it still make sense to keep it to a > minimal ~3 calls to JNI code that we can use for speed and > versatility. lock() isLocked(), unlock() perhaps. When I say > speed, its more about avoiding crossing the JNI layer multiple > times than java vs C performance. With versatility I think liblock > is the right way for most but not all (embeded) linux distros. > > -- > Trent Jarvi > tjarvi at qbang.org > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Mon Mar 20 12:44:47 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 20 Mar 2006 12:44:47 -0700 (MST) Subject: [Rxtx] BUG: Lock file stays even if port opening fails In-Reply-To: <82C19FE7-DDCB-45B6-B2C9-7606B66F0124@buechse.de> References: <82C19FE7-DDCB-45B6-B2C9-7606B66F0124@buechse.de> Message-ID: On Mon, 20 Mar 2006, Joachim Buechse wrote: > Ok, what about providing a default implementation in Java? > > The RXTXCommDriver would call a (native) function useNativeLocking and if > it returns true, call the native functions for lock() isLocked(), > unlock(), else is would use the Java based default implementation. This > could possibly be overriden by a property (again for debugging). > Hi Joachim That would be OK with me. -- Trent Jarvi tjarvi at qbang.org From dmarkman at mac.com Mon Mar 20 22:27:45 2006 From: dmarkman at mac.com (Dmitry Markman) Date: Tue, 21 Mar 2006 00:27:45 -0500 Subject: [Rxtx] binaries request Message-ID: <42702213-C222-4937-A585-7CFB17E47608@mac.com> Hi can somebody send me latest linux and windows binaries, please? or where I can find them (I didn't find them in the latest tareball) I gave up with my cygwin: something wrong I have no idea what java doesn't understand /cygwin/c syntax after I changed makefile it did java part but after that gcc 3.4.4 started to complain I set buffer length to 999 lines but I didn't get beginning of the story something wrong with my 1.4.2_09/include/jni.h gcc doesn't like it anyway I gave up thanks in advance Dmitry Markman -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060320/f8cbc57c/attachment-0027.html From tjarvi at qbang.org Mon Mar 20 22:36:48 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 20 Mar 2006 22:36:48 -0700 (MST) Subject: [Rxtx] binaries request In-Reply-To: <42702213-C222-4937-A585-7CFB17E47608@mac.com> References: <42702213-C222-4937-A585-7CFB17E47608@mac.com> Message-ID: On Tue, 21 Mar 2006, Dmitry Markman wrote: > Hi > can somebody send me latest linux and windows binaries, please? > > or where I can find them (I didn't find them in the latest tareball) > > I gave up with my cygwin: something wrong I have no idea what > java doesn't understand /cygwin/c syntax > after I changed makefile it did java part > but after that gcc 3.4.4 started to complain > I set buffer length to 999 lines but I didn't get beginning of the story > something wrong with my 1.4.2_09/include/jni.h gcc doesn't like it > anyway I gave up > > thanks in advance > Hi Dmitry The bins are here: ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7-bins-r2.zip Here are the files in the zip you want. Jar: rxtx-2.1-7-bins-r2/RXTXcomm.jar Windows: rxtx-2.1-7-bins-r2/Windows/i368-mingw32/rxtxSerial.dll Linux (x86) rxtx-2.1-7-bins-r2/Linux/i686-unknown-linux-gnu/librxtxSerial.so There are others in there including Parallel port support but those are the main ones for testing. -- Trent Jarvi tjarvi at qbang.org From dmarkman at mac.com Mon Mar 20 23:05:59 2006 From: dmarkman at mac.com (Dmitry Markman) Date: Tue, 21 Mar 2006 01:05:59 -0500 Subject: [Rxtx] binaries request In-Reply-To: References: <42702213-C222-4937-A585-7CFB17E47608@mac.com> Message-ID: thank you very much but windows's readme says: rxtxSerial.dll had to be recomopiled to link in missing native methods. should I ignore it? or what? thanks again also I understand that I should use mingw not cygwin I'll try to install mingw On Mar 21, 2006, at 12:36 AM, Trent Jarvi wrote: > On Tue, 21 Mar 2006, Dmitry Markman wrote: > >> Hi >> can somebody send me latest linux and windows binaries, please? >> >> or where I can find them (I didn't find them in the latest tareball) >> >> I gave up with my cygwin: something wrong I have no idea what >> java doesn't understand /cygwin/c syntax >> after I changed makefile it did java part >> but after that gcc 3.4.4 started to complain >> I set buffer length to 999 lines but I didn't get beginning of the >> story >> something wrong with my 1.4.2_09/include/jni.h gcc doesn't like it >> anyway I gave up >> >> thanks in advance >> > > Hi Dmitry > > The bins are here: > > ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7-bins-r2.zip > > Here are the files in the zip you want. > > Jar: > > rxtx-2.1-7-bins-r2/RXTXcomm.jar > > Windows: > > rxtx-2.1-7-bins-r2/Windows/i368-mingw32/rxtxSerial.dll > > Linux (x86) > > rxtx-2.1-7-bins-r2/Linux/i686-unknown-linux-gnu/librxtxSerial.so > > There are others in there including Parallel port support but those > are the main ones for testing. > > -- > Trent Jarvi > tjarvi at qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx Dmitry Markman From tjarvi at qbang.org Mon Mar 20 23:20:33 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 20 Mar 2006 23:20:33 -0700 (MST) Subject: [Rxtx] binaries request In-Reply-To: References: <42702213-C222-4937-A585-7CFB17E47608@mac.com> Message-ID: On Tue, 21 Mar 2006, Dmitry Markman wrote: > thank you very much > > but windows's readme says: > rxtxSerial.dll had to be recomopiled to link in missing native methods. > > should I ignore it? or what? > Hi Dmitry That dll should be OK. r2 is the recompile linked to the missing native method. The readme explains why it was recompiled; fuser.o was not linked into the dll in the first release. -- Trent Jarvi tjarvi at qbang.org From ariantristan at yahoo.com Mon Mar 20 23:55:24 2006 From: ariantristan at yahoo.com (Lambok Sianturi) Date: Mon, 20 Mar 2006 22:55:24 -0800 (PST) Subject: [Rxtx] jvm issue Message-ID: <20060321065524.94779.qmail@web50701.mail.yahoo.com> Hi All, This is my first time to join RxTx mailing list. I thank you all for allowing others to sign in in requests help. I use the latest RxTx lib in Fedora 3 with java version 1.4.2_09 b05. And I got this error: # # An unexpected error has been detected by HotSpot Virtual Machine: # # SIGSEGV (0xb) at pc=0x00bf27f3, pid=2633, tid=3086112448 # # Java VM: Java HotSpot(TM) Client VM (1.4.2_09-b05 mixed mode) # Problematic frame: # C [ld-linux.so.2+0xa7f3] # # An error report file with more information is saved as hs_err_pid2633.log # # If you would like to submit a bug report, please visit: # http://java.sun.com/webapps/bugreport/crash.jsp # ./run.sh: line 3: 2633 Aborted /usr/local/java/bin/java -Djava.library.path=/usr/local/java/jre/lib/ -Djsmsengine.debug=true -classpath jsmsengine.jar:smsgateway.jar:classes12.jar:RXTXcomm.jar:. com.api.sms.SMSServer What is the jvm depedency for the latest library? Can I use 1.4.2_09 b05? Thanks in advance. Arian --------------------------------- Yahoo! Mail Use Photomail to share photos without annoying attachments. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060320/83d58dd7/attachment-0027.html From f.frumento at ngi.it Tue Mar 21 00:21:47 2006 From: f.frumento at ngi.it (Fabio Frumento) Date: Tue, 21 Mar 2006 08:21:47 +0100 Subject: [Rxtx] Javadoc on the go Message-ID: <441FA98B.9050701@ngi.it> Hi Trent, sorry for the big delay but my job is running wild, i was out for some time but now i'm back and ready to continue the javadoc for Rxtx. Did you used the last javadoc patch i sent you ? let me know if i have to send it to you again or not. regards Fabio From lyon at docjava.com Tue Mar 21 00:51:18 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Tue, 21 Mar 2006 02:51:18 -0500 Subject: [Rxtx] lock files Message-ID: Hi All, You know, if the use of lock files were under Java control (rather than a build-time decision), it might enable a more unified binary distro. It might also facilitate quick prototyping of non-lock file approaches to resolving serial port contention issues (i.e., mac-like approaches vs. linux approaches, etc.). I realize that this is a radical overhaul of the lock file policy issue. Also, it may harm performance. On the other hand, our benchmarks on JNI overhead for modern processors indicate performance impact should be minimal. Perhaps it is more of an issue with the toybox systems. Suppose there were a class with a reasonable default...someone might write: SerialPortLockPolicy.setPolicy(SerialPortLockPolicy.UNIX_LOCK_FILE); SerialPortLockPolicy.setPolicy(SerialPortLockPolicy.NO_LOCK_CHECKING); SerialPortLockPolicy.setPolicy(SerialPortLockPolicy.MAC_STYLE); Thus, we could have a run-time reconfiguration of the serial port lock policy. A special NO_LOCK version of the binary would no longer be required. Any thoughts on this? Thanks! - Doug From joachim at buechse.de Tue Mar 21 03:09:09 2006 From: joachim at buechse.de (Joachim Buechse) Date: Tue, 21 Mar 2006 11:09:09 +0100 Subject: [Rxtx] lock files In-Reply-To: References: Message-ID: <8E12916A-1B9A-4FF2-B684-E2D1C794221B@buechse.de> This is pretty much what I thought about when I suggested, that the default behaviour could be overwritten with a property. I am very much in favor of this approach. In particular this allows much easier debugging for PC based java developers. I think big parts of the Java (and maybe some parts of the C code) could use a bit of a structural workover (unit tests, javadoc, synchronization, etc). Maybe there should be a CVS branch for this experimental version. I'd be happy to contribute a first workover for some of the Java code. Designing for testability and implementing a good bunch of unit tests has been a strategy that worked quite well in the Java projects I lead. And it ultimately allows more liberal change permission. Regards, Joachim On 21.03.2006, at 08:51, Dr. Douglas Lyon wrote: > Hi All, > You know, if the use of lock files were > under Java control (rather than a build-time decision), > it might enable a more unified binary distro. It might also > facilitate quick prototyping of non-lock file approaches > to resolving serial port contention issues (i.e., mac-like > approaches vs. linux approaches, etc.). > > I realize that this is a radical overhaul of the lock file policy > issue. Also, it may harm performance. On the other hand, > our benchmarks on JNI overhead for modern processors indicate > performance impact should be minimal. Perhaps it is more of > an issue with the toybox systems. > > Suppose there were a class with a reasonable default...someone > might write: > SerialPortLockPolicy.setPolicy(SerialPortLockPolicy.UNIX_LOCK_FILE); > SerialPortLockPolicy.setPolicy(SerialPortLockPolicy.NO_LOCK_CHECKING); > SerialPortLockPolicy.setPolicy(SerialPortLockPolicy.MAC_STYLE); > > Thus, we could have a run-time reconfiguration of the serial port lock > policy. A special NO_LOCK version of the binary would no longer > be required. > > Any thoughts on this? > > Thanks! > - Doug > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From joachim at buechse.de Tue Mar 21 06:23:08 2006 From: joachim at buechse.de (Joachim Buechse) Date: Tue, 21 Mar 2006 14:23:08 +0100 Subject: [Rxtx] PATCH: use of ioctl(fd, TIOCEXCL) instead of lockfiles Message-ID: <923AE774-EEA2-4911-92D8-32BB27802C8B@buechse.de> Here is the patch for the ioctl(fd, TIOCEXCL). I have verified this only for OSX 10.4.5, hence it is only defined for APPLE. However, it should work at least for Solaris as well. If a process has requested TIOEXCL further open calls by other user processes will fail. The patch also disables uucp style locking for APPLE. Obviously this is discussable. I think it is the way to go, as it eliminates creating the lock directory which doesnt exist on the standard installation and it eliminates messing with the system group definitions (adding users to group uucp). Regarding the possibility of root processes opening a device which is locked - I consider this a feature not a potential problem. It is highly unlikely, that somebody is crazy enough to run a JavaVM as root (unless he has no other means of getting a restricted IP port opened, ie doesnt understand ipfw). Anyway, even if the process runs as root, it fails when calling ioctl(fd, TIOCEXCL). It could however still open the port to listen for RING events. I.e. a fax server which needs to see incoming calls but otherwise doesnt want to block the port. So the only case where the proposed mechanism fails is, if an incorrectly implemented process running as root conflicts with a user process. I think this can be accepted. Regards, Joachim PS: If this patch is generally accepted, the installer and Mac doku should obviously be changed as well. Index: SerialImp.c =================================================================== RCS file: /usr/local/cvsroot/rxtx-devel/src/SerialImp.c,v retrieving revision 1.46.2.187 diff -u -r1.46.2.187 SerialImp.c --- SerialImp.c 29 Jan 2006 22:19:04 -0000 1.46.2.187 +++ SerialImp.c 21 Mar 2006 12:59:16 -0000 @@ -656,6 +656,25 @@ fd=OPEN (filename, O_RDWR | O_NOCTTY | O_NONBLOCK ); } while (fd < 0 && errno==EINTR); +#ifdef OPEN_EXCL + // Note that open() follows POSIX semantics: multiple open() calls to + // the same file will succeed unless the TIOCEXCL ioctl is issued. + // This will prevent additional opens except by root-owned processes. + // See tty(4) ("man 4 tty") and ioctl(2) ("man 2 ioctl") for details. + + if (fd >= 0 && (ioctl(fd, TIOCEXCL) == -1)) + { + sprintf( message, "open: exclusive access denied for % s\n", + filename ); + report( message ); + report_error( message ); + + close(fd); + goto fail; + } +#endif /* OPEN_EXCL */ + + if( configure_port( fd ) ) goto fail; (*env)->ReleaseStringUTFChars( env, jstr, filename ); sprintf( message, "open: fd returned is %i\n", fd ); Index: SerialImp.h =================================================================== RCS file: /usr/local/cvsroot/rxtx-devel/src/SerialImp.h,v retrieving revision 1.11.2.49 diff -u -r1.11.2.49 SerialImp.h --- SerialImp.h 5 Jul 2005 17:47:21 -0000 1.11.2.49 +++ SerialImp.h 21 Mar 2006 12:59:17 -0000 @@ -135,7 +135,8 @@ /*# define LOCKDIR "/var/spool/uucp"*/ # define LOCKDIR "/var/lock" # define LOCKFILEPREFIX "LK." -# define UUCP +/*# define UUCP*/ +# define OPEN_EXCL #endif /* __APPLE__ */ #if defined(__NetBSD__) # define DEVICEDIR "/dev/" From tjarvi at qbang.org Tue Mar 21 10:26:08 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 21 Mar 2006 10:26:08 -0700 (MST) Subject: [Rxtx] Javadoc on the go In-Reply-To: <441FA98B.9050701@ngi.it> References: <441FA98B.9050701@ngi.it> Message-ID: On Tue, 21 Mar 2006, Fabio Frumento wrote: > Hi Trent, > > sorry for the big delay but my job is running wild, i was out for some > time but now i'm back and ready to continue the javadoc for Rxtx. > > Did you used the last javadoc patch i sent you ? let me know if i have to > send it to you again or not. > > regards > > Fabio Hi Fabio The patch is in the rxtx mail-list archives. It will be going in soon. I did not see a time critical portion. I'll probably be going through the list since the last batch of patches this weekend and putting them into CVS. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Tue Mar 21 10:57:18 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 21 Mar 2006 10:57:18 -0700 (MST) Subject: [Rxtx] jvm issue In-Reply-To: <20060321065524.94779.qmail@web50701.mail.yahoo.com> References: <20060321065524.94779.qmail@web50701.mail.yahoo.com> Message-ID: On Mon, 20 Mar 2006, Lambok Sianturi wrote: > Hi All, > This is my first time to join RxTx mailing list. I thank you all for allowing others to sign in in requests help. > I use the latest RxTx lib in Fedora 3 with java version 1.4.2_09 b05. And I got this error: > > # > # An unexpected error has been detected by HotSpot Virtual Machine: > # > # SIGSEGV (0xb) at pc=0x00bf27f3, pid=2633, tid=3086112448 > # > # Java VM: Java HotSpot(TM) Client VM (1.4.2_09-b05 mixed mode) > # Problematic frame: > # C [ld-linux.so.2+0xa7f3] A native library loading error? What happens if you recompile rxtx on your system and install that? This sounds like an ABI problem? rxtx 2.1-7 was compiled with a gcc 2.96 toolchain as I recall. The hope is newer system will be backwards compatible. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Tue Mar 21 11:05:29 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 21 Mar 2006 11:05:29 -0700 (MST) Subject: [Rxtx] PATCH: use of ioctl(fd, TIOCEXCL) instead of lockfiles In-Reply-To: <923AE774-EEA2-4911-92D8-32BB27802C8B@buechse.de> References: <923AE774-EEA2-4911-92D8-32BB27802C8B@buechse.de> Message-ID: On Tue, 21 Mar 2006, Joachim Buechse wrote: > Here is the patch for the ioctl(fd, TIOCEXCL). I have verified this only > for OSX 10.4.5, hence it is only defined for APPLE. However, it should > work at least for Solaris as well. > > If a process has requested TIOEXCL further open calls by other user > processes will fail. > > The patch also disables uucp style locking for APPLE. Obviously this is > discussable. I think it is the way to go, as it eliminates creating the > lock directory which doesnt exist on the standard installation and it > eliminates messing with the system group definitions (adding users to > group uucp). > > Regarding the possibility of root processes opening a device which is > locked - I consider this a feature not a potential problem. It is highly > unlikely, that somebody is crazy enough to run a JavaVM as root (unless > he has no other means of getting a restricted IP port opened, ie doesnt > understand ipfw). Anyway, even if the process runs as root, it fails when > calling ioctl(fd, TIOCEXCL). It could however still open the port to > listen for RING events. I.e. a fax server which needs to see incoming > calls but otherwise doesnt want to block the port. So the only case where > the proposed mechanism fails is, if an incorrectly implemented process > running as root conflicts with a user process. I think this can be > accepted. > > Regards, > Joachim > > PS: If this patch is generally accepted, the installer and Mac doku > should obviously be changed as well. > > > Index: SerialImp.c > =================================================================== > RCS file: /usr/local/cvsroot/rxtx-devel/src/SerialImp.c,v > retrieving revision 1.46.2.187 > diff -u -r1.46.2.187 SerialImp.c > --- SerialImp.c 29 Jan 2006 22:19:04 -0000 1.46.2.187 > +++ SerialImp.c 21 Mar 2006 12:59:16 -0000 > @@ -656,6 +656,25 @@ > fd=OPEN (filename, O_RDWR | O_NOCTTY | O_NONBLOCK ); > } while (fd < 0 && errno==EINTR); > > +#ifdef OPEN_EXCL > + // Note that open() follows POSIX semantics: multiple open() > calls to > + // the same file will succeed unless the TIOCEXCL ioctl is > issued. > + // This will prevent additional opens except by root-owned > processes. > + // See tty(4) ("man 4 tty") and ioctl(2) ("man 2 ioctl") for > details. > + > + if (fd >= 0 && (ioctl(fd, TIOCEXCL) == -1)) > + { > + sprintf( message, "open: exclusive access denied for % > s\n", > + filename ); > + report( message ); > + report_error( message ); > + > + close(fd); > + goto fail; > + } > +#endif /* OPEN_EXCL */ > + > + > if( configure_port( fd ) ) goto fail; > (*env)->ReleaseStringUTFChars( env, jstr, filename ); > sprintf( message, "open: fd returned is %i\n", fd ); > Index: SerialImp.h > =================================================================== > RCS file: /usr/local/cvsroot/rxtx-devel/src/SerialImp.h,v > retrieving revision 1.11.2.49 > diff -u -r1.11.2.49 SerialImp.h > --- SerialImp.h 5 Jul 2005 17:47:21 -0000 1.11.2.49 > +++ SerialImp.h 21 Mar 2006 12:59:17 -0000 > @@ -135,7 +135,8 @@ > /*# define LOCKDIR "/var/spool/uucp"*/ > # define LOCKDIR "/var/lock" > # define LOCKFILEPREFIX "LK." > -# define UUCP > +/*# define UUCP*/ > +# define OPEN_EXCL > #endif /* __APPLE__ */ > #if defined(__NetBSD__) > # define DEVICEDIR "/dev/" > This looks like a good start. What do you think Dmitry? Perhaps all systems with TIOCEXCL defined should use that though. Even if they use lockfiles. It wont hurt anything. That would catch people hacking their own serial apps without checking lockfiles. Its a good idea to avoid C++ style comments in the C portions. Some older systems don't deal with them well. If it's just for Mac OS X, it isn't a big deal. I think it was the Irix compiler that was problematic? -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Tue Mar 21 11:22:05 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 21 Mar 2006 11:22:05 -0700 (MST) Subject: [Rxtx] lock files In-Reply-To: <8E12916A-1B9A-4FF2-B684-E2D1C794221B@buechse.de> References: <8E12916A-1B9A-4FF2-B684-E2D1C794221B@buechse.de> Message-ID: We can try it. Maybe the JNI is much improved. The nice thing about linking into liblock is distros then worry about lockfiles on their systems. This way, we have to deal with any changes that may show up. On Tue, 21 Mar 2006, Joachim Buechse wrote: > This is pretty much what I thought about when I suggested, that the > default behaviour could be overwritten with a property. I am very much in > favor of this approach. In particular this allows much easier debugging > for PC based java developers. > > I think big parts of the Java (and maybe some parts of the C code) could > use a bit of a structural workover (unit tests, javadoc, synchronization, > etc). Maybe there should be a CVS branch for this experimental version. > I'd be happy to contribute a first workover for some of the Java code. > Designing for testability and implementing a good bunch of unit tests has > been a strategy that worked quite well in the Java projects I lead. And > it ultimately allows more liberal change permission. > > Regards, > Joachim > > > On 21.03.2006, at 08:51, Dr. Douglas Lyon wrote: > >> Hi All, >> You know, if the use of lock files were >> under Java control (rather than a build-time decision), >> it might enable a more unified binary distro. It might also >> facilitate quick prototyping of non-lock file approaches >> to resolving serial port contention issues (i.e., mac-like >> approaches vs. linux approaches, etc.). >> >> I realize that this is a radical overhaul of the lock file policy >> issue. Also, it may harm performance. On the other hand, >> our benchmarks on JNI overhead for modern processors indicate >> performance impact should be minimal. Perhaps it is more of >> an issue with the toybox systems. >> >> Suppose there were a class with a reasonable default...someone >> might write: >> SerialPortLockPolicy.setPolicy(SerialPortLockPolicy.UNIX_LOCK_FILE); >> SerialPortLockPolicy.setPolicy(SerialPortLockPolicy.NO_LOCK_CHECKING); >> SerialPortLockPolicy.setPolicy(SerialPortLockPolicy.MAC_STYLE); >> >> Thus, we could have a run-time reconfiguration of the serial port lock >> policy. A special NO_LOCK version of the binary would no longer >> be required. >> >> Any thoughts on this? >> >> Thanks! >> - Doug >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From dmarkman at mac.com Tue Mar 21 16:05:17 2006 From: dmarkman at mac.com (Dmitry Markman) Date: Tue, 21 Mar 2006 18:05:17 -0500 Subject: [Rxtx] PATCH: use of ioctl(fd, TIOCEXCL) instead of lockfiles In-Reply-To: References: <923AE774-EEA2-4911-92D8-32BB27802C8B@buechse.de> Message-ID: <512AC70C-BB86-48F2-A83C-023F35C23BAB@mac.com> I think it's cool, but I'd like to have that property implementation when user can choose between locking mechanism about comments: it's easy to change comments to the C style or we can use extensions of the file to cpp so c++ compiler will be used On Mar 21, 2006, at 1:05 PM, Trent Jarvi wrote: > This looks like a good start. What do you think Dmitry? Perhaps > all systems with TIOCEXCL defined should use that though. Even if > they use lockfiles. It wont hurt anything. That would catch > people hacking their own serial apps without checking lockfiles. > > Its a good idea to avoid C++ style comments in the C portions. > Some older systems don't deal with them well. If it's just for Mac > OS X, it isn't a big deal. I think it was the Irix compiler that > was problematic? Dmitry Markman From dmarkman at mac.com Tue Mar 21 16:13:00 2006 From: dmarkman at mac.com (Dmitry Markman) Date: Tue, 21 Mar 2006 18:13:00 -0500 Subject: [Rxtx] PATCH: use of ioctl(fd, TIOCEXCL) instead of lockfiles In-Reply-To: References: <923AE774-EEA2-4911-92D8-32BB27802C8B@buechse.de> Message-ID: I'd like to add that creating locking folder isn't a big deal we never had a problem related to the lock folders, because we always used installer on mac os x from other hand I'm not very much familiar with iotcl locking approach and I'm not sure it's more efficient Joachim wrote "I think it is the way to go, as it eliminates creating the lock directory which doesnt exist on the standard installation and it eliminates messing with the system group definitions (adding users to group uucp)." but I really didn't have any problem with that 1. doesn't exist on the standard installation there are many-many things that don't exist in the standard installation so I don't think that argument is strong enough 2. messing with the system group definitions I don't think we're messing with the group definition mac os x provides very clear way to set up group's members and together with Greg Guerin AuthKit there is no problem to set those definitions so I don't think that argument is strong either but from other hand using iotcl is more promising and is more elegant On Mar 21, 2006, at 1:05 PM, Trent Jarvi wrote: > > This looks like a good start. What do you think Dmitry? Perhaps > all systems with TIOCEXCL defined should use that though. Even if > they use lockfiles. It wont hurt anything. That would catch > people hacking their own serial apps without checking lockfiles. Dmitry Markman From joachim at buechse.de Wed Mar 22 04:46:45 2006 From: joachim at buechse.de (Joachim Buechse) Date: Wed, 22 Mar 2006 12:46:45 +0100 Subject: [Rxtx] PATCH: use of ioctl(fd, TIOCEXCL) instead of lockfiles In-Reply-To: References: <923AE774-EEA2-4911-92D8-32BB27802C8B@buechse.de> Message-ID: Sorry, I was not very clear with my arguments, so I will try again;-) Please, don't take this as an attack against work that has been done. I think the contributions that have been made in the past were made in a good spirit. But I really believe, that the current solution for OSX has many shortcomings and should be changed as soon as possible. lock files --- The /var/lock folder does not exist on the standard OSX installation, however the standard installation includes several applications that use serial ports (i.e. the FAX capability). This indicates, that the lock folder approach will not work well with system components. Applications for OSX will generally try to live in harmony with system components (except for HP print drivers of course). I think RXTX should follow this approach as well. uucp group --- Accessing serial ports is not an admin privileged operation on OSX. Any user (world) has read/write privileges on /dev/tty*. So the system default is to not enforce any group membership to access these ports. The group uucp however is a system group on all unix systems I know. It exists for certain system processes. A non admin user should in general not be a member of this group. Quite arguably no user should ever be a member of this group. Installer --- My general opinion is, that - no Installer should touch user or group data without warning - no Application Installer should touch groups which are not specific to the very application installed - no Installer should ever add regular users to a system group The current installer injects the installing user in the group uucp without warning about this change and without giving the option to "opt out" of this change. This is a potential security risk (but not currently a real one, as OSX contains no folders belonging to group uucp). The current installer does not work for multi user systems. It puts the installing user in the uucp group. However the installing user is not necessarily the user that will use the application. Putting all users that may use a serial port application in the system group uucp seems like a very invasive approach to me. Besides that, newly created users will not automatically be in the group and hence, serial applications will "break" for new users without obvious reasons. Avoiding the lock files will allow self contained applications (i.e. drag&drop installation). In my eyes this is largely preferable over an installer that requests admin privileges. Adding up all these points indicates very strongly, that the lock-file implementation is not the way to go on OSX. Regards, Joachim On 22.03.2006, at 00:13, Dmitry Markman wrote: > I'd like to add that > > creating locking folder isn't a big deal > we never had a problem related to the lock folders, because we > always used installer on mac os x > from other hand I'm not very much familiar with iotcl locking > approach and I'm not sure it's more efficient > > Joachim wrote "I think it is the way to go, as it eliminates > creating the lock directory which doesnt exist on the standard > installation and it eliminates messing with the system group > definitions (adding users to group uucp)." but I really didn't have > any problem with that > > 1. doesn't exist on the standard installation > there are many-many things that don't exist in the standard > installation so I don't think that argument is strong enough > 2. messing with the system group definitions > I don't think we're messing with the group definition > mac os x provides very clear way to set up group's members and > together with Greg Guerin AuthKit there is no problem to set those > definitions > so I don't think that argument is strong either > but from other hand using iotcl is more promising and is more elegant > > > > On Mar 21, 2006, at 1:05 PM, Trent Jarvi wrote: > >> >> This looks like a good start. What do you think Dmitry? Perhaps >> all systems with TIOCEXCL defined should use that though. Even if >> they use lockfiles. It wont hurt anything. That would catch >> people hacking their own serial apps without checking lockfiles. > > Dmitry Markman > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From dmarkman at mac.com Wed Mar 22 05:27:13 2006 From: dmarkman at mac.com (Dmitry Markman) Date: Wed, 22 Mar 2006 07:27:13 -0500 Subject: [Rxtx] PATCH: use of ioctl(fd, TIOCEXCL) instead of lockfiles In-Reply-To: References: <923AE774-EEA2-4911-92D8-32BB27802C8B@buechse.de> Message-ID: <83440CF3-DCD8-41C1-B941-F227232C27E3@mac.com> thanks for the very good explanation I didn't think that you were attacking any thing, so don't worry I just had feeling, that there were more aesthetic reasons for going to ioctl then real necessity now you explained everything quite well (BTW, asfar as I remember installer asks admin password so it wasn't quiet, but it really doesn't matter now) thanks On Mar 22, 2006, at 6:46 AM, Joachim Buechse wrote: > Sorry, I was not very clear with my arguments, so I will try again;-) > > Please, don't take this as an attack against work that has been > done. I think the contributions that have been made in the past > were made in a good spirit. But I really believe, that the current > solution for OSX has many shortcomings and should be changed as > soon as possible. > > lock files > --- > The /var/lock folder does not exist on the standard OSX > installation, however the standard installation includes several > applications that use serial ports (i.e. the FAX capability). This > indicates, that the lock folder approach will not work well with > system components. Applications for OSX will generally try to live > in harmony with system components (except for HP print drivers of > course). I think RXTX should follow this approach as well. > > uucp group > --- > Accessing serial ports is not an admin privileged operation on OSX. > Any user (world) has read/write privileges on /dev/tty*. So the > system default is to not enforce any group membership to access > these ports. The group uucp however is a system group on all unix > systems I know. It exists for certain system processes. A non admin > user should in general not be a member of this group. Quite > arguably no user should ever be a member of this group. > > Installer > --- > My general opinion is, that > - no Installer should touch user or group data without warning > - no Application Installer should touch groups which are not > specific to the very application installed > - no Installer should ever add regular users to a system group > > The current installer injects the installing user in the group uucp > without warning about this change and without giving the option to > "opt out" of this change. This is a potential security risk (but > not currently a real one, as OSX contains no folders belonging to > group uucp). > > The current installer does not work for multi user systems. It puts > the installing user in the uucp group. However the installing user > is not necessarily the user that will use the application. Putting > all users that may use a serial port application in the system > group uucp seems like a very invasive approach to me. Besides that, > newly created users will not automatically be in the group and > hence, serial applications will "break" for new users without > obvious reasons. > > > Avoiding the lock files will allow self contained applications > (i.e. drag&drop installation). In my eyes this is largely > preferable over an installer that requests admin privileges. Adding > up all these points indicates very strongly, that the lock-file > implementation is not the way to go on OSX. > > Regards, > Joachim > > > On 22.03.2006, at 00:13, Dmitry Markman wrote: > >> I'd like to add that >> >> creating locking folder isn't a big deal >> we never had a problem related to the lock folders, because we >> always used installer on mac os x >> from other hand I'm not very much familiar with iotcl locking >> approach and I'm not sure it's more efficient >> >> Joachim wrote "I think it is the way to go, as it eliminates >> creating the lock directory which doesnt exist on the standard >> installation and it eliminates messing with the system group >> definitions (adding users to group uucp)." but I really didn't >> have any problem with that >> >> 1. doesn't exist on the standard installation >> there are many-many things that don't exist in the standard >> installation so I don't think that argument is strong enough >> 2. messing with the system group definitions >> I don't think we're messing with the group definition >> mac os x provides very clear way to set up group's members and >> together with Greg Guerin AuthKit there is no problem to set those >> definitions >> so I don't think that argument is strong either >> but from other hand using iotcl is more promising and is more elegant >> >> >> >> On Mar 21, 2006, at 1:05 PM, Trent Jarvi wrote: >> >>> >>> This looks like a good start. What do you think Dmitry? Perhaps >>> all systems with TIOCEXCL defined should use that though. Even >>> if they use lockfiles. It wont hurt anything. That would catch >>> people hacking their own serial apps without checking lockfiles. >> >> Dmitry Markman >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx Dmitry Markman From lyon at docjava.com Wed Mar 22 06:12:18 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Wed, 22 Mar 2006 08:12:18 -0500 Subject: [Rxtx] sole of a new design pattern Message-ID: Hi All, I have been thinking about how we design the serial port software. I think we need a new design pattern. For lack of a better term, I shall call it: The Parametric Singleton Design Pattern By Douglas A. Lyon ABSTRACT The goal of the singleton design pattern is to make sure that there is one, and only one, instance of a given class. The goal of the parametric singleton design pattern is to make sure that there is one, and only one, instance of a given class with the given parametric values. We parametric singleton design pattern combines the singleton design pattern with a parameter that enables unique creation of instances of a class. These instances are cached. When a user asks for an instance with these parameters, the cache is checked. If the instance is in the cache, the instance is returned, otherwise it is created, added to the cache and then returned. We apply our parametric singleton design pattern to the retrieval of RMI registries bound to a given port. The goal of our system is to make sure that no two RMI registries are listening to the same socket and to make use of the RMI registries after they have been created. RMI registries are used in distributed computation. Introduction The singleton design pattern is meant to ensure that on a single instance of a class exists. It is also meant to provide a global point of access to it. The intent of the parametric singleton design pattern is to ensure that a class has only one instance for a given set of parameter values. It also provides a global point of access to it. Motivation A system cannot tolerate multiple instances of some classes with identical parameters. For example, you cannot have two instances making use of the same serial port, at the same time. You cannot have two instances that are trying to listen to the same socket connection. You cannot have two instances writing to the same file structure at the same time. As the operating system is often thought of as the arbiter of consumed resources (i.e., tape drives, serial ports, etc.) we frequently leave it to an operating system implementation to resolve these contention issues. Even for similar resources (like serial ports) there are few standards for handling contention. For example, serial ports on Linux are locked using a "/var/lock" file. POSIX, on the other hand, uses ioctl mechanisms to prevent contention. A better solution is to make a class that is responsible for keeping track of the instances created from the class. The class is declared final, so that it cannot be subclassed. The class also has a private constructor, so that other classes cannot instance it. The new design pattern is called the parametric singleton design pattern and it provides a way to access and create instances with given parameters. Applicability Use the Parametric Singleton Design Pattern when: 1. There must be exactly one instance of a class with the given parameters. 2. The instances must be accessible to clients from a well-known access point. Structure Insert UML diagram here. Participants The Parametric Singleton Clients that need instances 1. The Parametric Singleton defines an instance upon request from a client, if, and only if, the instance does not already exist. 2. The Parametric Singleton returns the instance to the client. 3. The Parametric Singleton is responsible for creating unique instances from given parameters. Collaborations Clients obtain a reference to a Parametric Singleton instance only through the parametric singleton design pattern. If the instance is left in an improper state (e.g., the serial port was left open) it is NOT the role of the Parametric Singleton Design Pattern to close the IO port. Nor is it the role of the Parametric Singleton Design Pattern to open the port. That role is delegate to some other part of the system. Further, it is not the role of the Parametric Singleton Design Pattern to check out resources. That is, multiple threads can have multiple references to the same resource at the same time. MUTEX locking is delegated to some other part of the system. Consequences The Parametric Singleton Design Pattern has several benefits: 1. Controlled access to parametrically defined instances. Since the Parametric Singleton class encapsulates its instances, there is control over how and when clients access it. 2. Reduced name space. The Parametric Singleton pattern avoids global variables that store instances created from the same parameter. Implementation Here are implementation issues to consider when using the Parametric Singleton pattern: 1. Unique mapping of parameters. The Parametric Singleton pattern requires that there be a mean to isomorphically map the parameter space into the instance space and back again. 2. Ensure unique instances. The Parametric Singleton pattern makes unique instances from parameters, and it does so only once. 3. Cache instances for fast retrieval. The Parametric Singleton pattern must be able to look up instances, given some set of parameters, and do so from some data structure. That is, there must be enough space to hold references to all the instances the program will need. Also, a mechanism is needed to look up and retrieve the instances quickly enough to satisfy the clients. Sample Code public final class ParametricSingletonRmiRegistry { private static Hashtable registry = new Hashtable(100); // use singleton pattern and??????????????????????????????????????????????? // prevent instantiation of RmiRegistryUtils.?????????????????????????????? private ParametricSingletonRmiRegistry() { } // the only instance of the Registry held by the RmiRegistryUtils?????????? public static void listNames(Integer port) { if (!isInCacheAndRunning(port)) return; Registry r = (Registry) registry.get(port); System.out.println("registry on port: " + port); System.out.println("registry: " + r); System.out.println("names: "); try { print(r.list()); } catch (RemoteException e) { In.message(e); } System.out.println("------------------------"); } /**???????????????????????????????????????????????????????????????????????? * Checks whether a Registry has been started on this host????????????????? * in the specified port.?????????????????????????????????????????????????? * If not, it tries to start one.?????????????????????????????????????????? * when it fails to start a Registry, it exits the program????????????????? * with exit code 1.??????????????????????????????????????????????????????? */ public static void restart(int port) { if (isInCacheAndRunning(port)) return; try { startRegistry(port); } catch (RemoteException e) { In.message(e); } } /**???????????????????????????????????????????????????????????????????????? * @param port????????????????????????????????????????????????????????????? * @return true if registry is in cache and running???????????????????????? */ private static boolean isInCacheAndRunning(Integer port) { if (!isRegistryRunning(port.intValue())) return false; if (!isRegistryInCache(port.intValue())) return false; return true; } /**???????????????????????????????????????????????????????????????????????? * @param port????????????????????????????????????????????????????????????? * @return true if we are able to locate a local registry on port.??????????????????????????????????????????????????????????????????????????? */ private static boolean isRegistryRunning(int port) { try { Registry r = LocateRegistry.getRegistry(port); if (r != null) return true; } catch (RemoteException e) { return false; } return false; } /**???????????????????????????????????????????????????????????????????????? * @param port????????????????????????????????????????????????????????????? * @return return true if registry is in cache????????????????????????????? */ private static boolean isRegistryInCache(int port) { if (registry.get(new Integer(port)) == null) return false; return true; } /**???????????????????????????????????????????????????????????????????????? * Restart the registry, if needed.???????????????????????????????????????? * Return the only instance of the registry for consistent global?????????? * using by making use of the Singleton Design Pattern????????????????????? *????????????????????????????????????????????????????????????????????????? * @return the internally held registry instance.?????????????????????????? */ public static Registry getRegistry(Integer port) { restart(port); return (Registry) registry.get(port); } private static void startRegistry(Integer port) throws RemoteException { Registry r; try { r = LocateRegistry.createRegistry(port.intValue()); registry.put(port, r); //r = new sun.rmi.registry.RegistryImpl???????????????????????????? /// (port.intValue());?????????????????????????????????????? // registry.put(port, r);?????????????????????????????????????????? } catch (Exception e) { //e.printStackTrace();????????????????????????????????????????????? r = LocateRegistry.getRegistry(port.intValue()); registry.put(port, r); } } public static void main(String args[]) throws RemoteException { //restart(port);??????????????????????????????????????????????????????? restart(5001); restart(5002); restart(5002); Registry r = LocateRegistry.getRegistry(5002); System.out.println("registry="+r); } } I would very much like to get your feedback on this new design pattern idea. Thank you for your time. Regards, - Doug From david.garnier at trusted-logic.com Wed Mar 22 07:36:10 2006 From: david.garnier at trusted-logic.com (David Garnier) Date: Wed, 22 Mar 2006 15:36:10 +0100 Subject: [Rxtx] sole of a new design pattern In-Reply-To: References: Message-ID: <442160DA.80107@trusted-logic.com> Hello, > The Parametric Singleton Design Pattern The Singleton is the most abused design pattern ever. Good use-cases for this pattern are extremely rare and mostly confined to problems related to hardware resources, like serial ports. > Applicability > > Use the Parametric Singleton Design Pattern when: > 1. There must be exactly one instance of a class with the given > parameters. OK. As I said above, this case this actually very unusual. The Singleton pattern is mostly used when : > 2. The instances must be accessible to clients from a well-known > access point. Using the singleton pattern in this case is just convenient for the programmer. Problems arises pretty quickly, especially if you attempt to unit-test your classes. 1) If your singleton is stateful, or hold on to stateful objects, it means that two different unit tests are not actually independent. Instead of starting with a brand new environment, the result of a test may be affected by the result of a previous test. This problem also arise when with your class relies on a database. In both cases, the solution is to reset your "unique" resource (Singleton or database) at the beginning of the test, which is a pain. Also, while most projects connect to a single database, projects that allow the use of Singletons usually contain several of thems, and new ones may cropped up unnoticed. You quickly end up with test cases that only pass in a certain order, which is a royal pain. 2) You cannot mockup a singleton. Once everyone calls the SomeSingleton class statically, you can't replace your class by SomeSingletonMockup. Furthermore, even for hardware services, the Singleton pattern does not really prevent concurrent accesses. If you start the same program in two different JVMs, unless they somehow shared the state of their "Singletons" (through lock files for example), the Singleton pattern will not prevent concurrent access. Our application uses RXTX, and we routinely encounter cases where another (native) application has already locked the port. Since we cannot modify the native application to recognize lock files, OS-level control is irreplaceable. > > Consequences > The Parametric Singleton Design Pattern has several benefits: > > 1. Controlled access to parametrically defined instances. Since > the Parametric Singleton class encapsulates its instances, there is > control over how and when clients access it. Not really. Once you've returned the instance to a client, you've lost control over it. The client can to whatever it wants with it. You cannot "recall" the instance or claim it back. > 2. Reduced name space. The Parametric Singleton pattern avoids > global variables that store instances created from the same parameter. Sure, but you don't have to rely on a Singleton for that. Just create a single Factory. > I would very much like to get your feedback on this new design > pattern idea. Well, it's nothing new. Some may say that it is the point of design patterns: formalizes the designs that occur again and again. However, this design is simply a combination of the Singleton and Factory patterns. I did use it in the past, but now I've been exposed to the shortcomings of the Singleton pattern, so I limit myself to Factories. Regards, David From sean_montgomery at baseview.com Wed Mar 22 08:35:28 2006 From: sean_montgomery at baseview.com (Sean Montgomery) Date: Wed, 22 Mar 2006 10:35:28 -0500 Subject: [Rxtx] sole of a new design pattern In-Reply-To: <442160DA.80107@trusted-logic.com> References: <442160DA.80107@trusted-logic.com> Message-ID: <05769CA7-A51B-4CF0-BAA0-E02DD905F5A4@baseview.com> On Mar 22, 2006, at 9:36 AM, David Garnier wrote: > Furthermore, even for hardware services, the Singleton pattern does > not really prevent concurrent > accesses. If you start the same program in two different JVMs, > unless they somehow shared the state > of their "Singletons" (through lock files for example), the > Singleton pattern will not prevent > concurrent access. > Multiple class loaders in a single JVM can be tricky, too. Then there's synchronization, lazy initialization and serialization of singletons to contend with. Bloch's Effective Java covers these, and here's a few articles: http://www.javaworld.com/javaworld/jw-04-2003/jw-0425-designpatterns- p3.html http://java.sun.com/developer/technicalArticles/Programming/singletons/ Just FYI :-) From lyon at docjava.com Wed Mar 22 08:50:48 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Wed, 22 Mar 2006 10:50:48 -0500 Subject: [Rxtx] sole of a new design pattern In-Reply-To: <442160DA.80107@trusted-logic.com> References: <442160DA.80107@trusted-logic.com> Message-ID: Hi All, First, I would like to thank David for his prompt and thoughtful remarks. I had no idea people that feel strongly about a design patterns! Wow! Feedback (particularly critical feedback) is greatly appreciated. Starting at the end, first: >I did use it in >the past, but now I've been exposed to the shortcomings of the >Singleton pattern, so I limit myself to Factories. David, if I understood your comments correctly, you suggested that Factories can be used in leu of the Singleton Design Pattern, or even the Parametric Singleton Design Pattern. As I see in [Gof]: Factory Method: Intent "Define an interface for creating an object, but let subclasses decide which class to instantiate. Factory Method lets a class defer instantiation to subclasses." The Singleton Design Pattern is a concrete class, which is rather different, right? Also, subclasses are not permitted with Singleton, as they are final. Naturally, I could use an abstract factory as a parent for a singleton. I could even design a facade that could be implemented with the singleton....but that is not the intention of the design. Unless you want a mock-up, as discussed, below: More below: >Hello, > >> The Parametric Singleton Design Pattern > >The Singleton is the most abused design pattern ever. Good use-cases >for this pattern are extremely >rare and mostly confined to problems related to hardware resources, >like serial ports. > > >> Applicability >> >> Use the Parametric Singleton Design Pattern when: >> 1. There must be exactly one instance of a class with the given >> parameters. >OK. As I said above, this case this actually very unusual. The >Singleton pattern is mostly used when : >> 2. The instances must be accessible to clients from a well-known >> access point. > >Using the singleton pattern in this case is just convenient for the >programmer. Problems arises >pretty quickly, especially if you attempt to unit-test your classes. > >1) If your singleton is stateful, or hold on to stateful objects, it >means that two different unit >tests are not actually independent. Instead of starting with a brand >new environment, the result of >a test may be affected by the result of a previous test. This >problem also arise when with your >class relies on a database. In both cases, the solution is to reset >your "unique" resource >(Singleton or database) at the beginning of the test, which is a >pain. Also, while most projects >connect to a single database, projects that allow the use of >Singletons usually contain several of >thems, and new ones may cropped up unnoticed. You quickly end up >with test cases that only pass in a >certain order, which is a royal pain. There are basic problems with communicating finite state machines that include reachability and deadlock analysis. These are addressed with petri net analysis and are beyond the scope of the design pattern. As you quite rightly pointed out; the parametric singleton pattern (or the singleton pattern, for that matter) enable multiple threads to gain access to the same instance. The only way that I can see to block others from gaining access to the reference is the synchronize keyword. This is putting a spin-lock (or MUTEX) on the reference. The question of how to unit-test a design pattern like the parametric singleton remains open. Perhaps this is a deficiency. > >2) You cannot mockup a singleton. Once everyone calls the >SomeSingleton class statically, you can't >replace your class by SomeSingletonMockup. Acutally, I am not sure that this is true. If the Singleton implements a Facade interface, it should be possible to make the replacement. Right? > >Furthermore, even for hardware services, the Singleton pattern does >not really prevent concurrent >accesses. If you start the same program in two different JVMs, >unless they somehow shared the state >of their "Singletons" (through lock files for example), the >Singleton pattern will not prevent >concurrent access. Good Point!! You have sharp eyes! The singleton design pattern should/could take responsibility for this. In fact, you may notice that my code does have an implementation (LocateRegistry) that can work across JVM's. The LocateRegistry will even work across the Internet! LocateRegistry takes both a host name and a Port (lock files just don't do this). I did not think to implement this beyond the local machine, but, in its present form, it will work across different processes. > >Our application uses RXTX, and we routinely encounter cases where >another (native) application has >already locked the port. Since we cannot modify the native >application to recognize lock files, >OS-level control is irreplaceable. The singleton design pattern is not meant to replace OS-level control, but to centralize the Java programmers access to it. If lock files, for example, are used for serial ports, the Singleton Design Pattern should be able to work with them. > > >> >> Consequences >> The Parametric Singleton Design Pattern has several benefits: >> > > 1. Controlled access to parametrically defined instances. Since >> the Parametric Singleton class encapsulates its instances, there is >> control over how and when clients access it. > >Not really. Once you've returned the instance to a client, you've >lost control over it. The client >can to whatever it wants with it. You cannot "recall" the instance >or claim it back. Good point, this should read: > 1. Controll when parametrically defined instances are created. Since > > the Parametric Singleton class encapsulates its instances, there is > > control over how and when they are instanced. > >> 2. Reduced name space. The Parametric Singleton pattern avoids >> global variables that store instances created from the same parameter. > >Sure, but you don't have to rely on a Singleton for that. Just >create a single Factory. > > Thank you for your thoughtful and prompt response! Regards, - Doug From dmarkman at mac.com Wed Mar 22 21:21:55 2006 From: dmarkman at mac.com (Dmitry Markman) Date: Wed, 22 Mar 2006 23:21:55 -0500 Subject: [Rxtx] sole of a new design pattern In-Reply-To: <442160DA.80107@trusted-logic.com> References: <442160DA.80107@trusted-logic.com> Message-ID: I don't think I get it On Mar 22, 2006, at 9:36 AM, David Garnier wrote: > Using the singleton pattern in this case is just convenient for the > programmer. Problems arises > pretty quickly, especially if you attempt to unit-test your classes. so you're saying that something isn't so good because you can not test it in the convenient way? if that's true, I'm totally disagree change your test, debug whatever, but if software is efficient at runtime, works fine and only problem is some unit test (which is some kind of framework for testing) then dump that unit test , dump that unit framework and make something appropriate to the software you're testing so if Douglas want to use singletons, what's the problem? and what do you mean by abusing of singleton usage? of course singleton doesn't prevent concurrent access to the resource across the processes unless you're using some OS facility to prevent it, besides singleton as it was introduced is relevant only and only inside of the same process otherwise it's not singleton it's something else (let's say network singleton: so you have remote invocation facility and some factory method that return object created by that facility) I don't have any problem with using any kind of singletons. Parametric Singleton idea (if I understand it right) could be easily implemented in the following way: use a map populate map with instances of some class and key is your parameter (you can use lazy population too) if somebody ask the key check the value if it's null so resource is taken if somebody returns the resource put it back to the map public synchronized static Object getSomeResource(Object parameter); public synchronized static void returnResource(Object parameter); getSomeResource (inside of the same process) could return null in 2 cases 1. if somebody (from other thread for example) already took that resource 2. if OS API said that resource corresponded to that parameter (serial port with parameter = 1 (port #)) is locked and unavailable; I'm not sure that in case of serial ports we even need those Parametric Singletons (unless lock checking is a very expensive operation) just ask the OS about availability of that resource and if it's available give it away and then OS will lock it and therefore in next time somebody ask it just answer that resource is locked and return null for example system has 2 serial ports available so I ask getResource("tty"); or I ask getResource("Bluetooth-Modem"); and if OS is ok you can give tty or Bluetooth-Modem or both no need for any additional pattern I think back to the problem mac os x doesn't recognize locking via files, so it handles locking via some API an instance of the singleton in each process should recognize that resource is locked (by using that API) that's all we don't have to make things more complicate then they are just because there is some nice design pattern or nice unit test framework or whatever keep things simple, make them work fast, don't introduce middle layers unless you have really good reason to do so of course I could be entirely wrong, so sorry about that in advance thanks Dmitry Markman From tjarvi at qbang.org Wed Mar 22 22:31:41 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 22 Mar 2006 22:31:41 -0700 (MST) Subject: [Rxtx] sole of a new design pattern In-Reply-To: References: Message-ID: Hi Doug Interesting reading. So far I'm just reading and thinking. I have one question so far. " Clients obtain a reference to a Parametric Singleton instance only through the parametric singleton design pattern. If the instance is left in an improper state (e.g., the serial port was left open) it is NOT the role of the Parametric Singleton Design Pattern to close the IO port. Nor is it the role of the Parametric Singleton Design Pattern to open the port. That role is delegate to some other part of the system. " So when the clients obtain a reference to the singleton, can they assume the port is there? IE, would it be the singletons role to handle things like USB dongles being removed with event hints comming from the underlying OS. Hardware abstraction layer/HAL on Linux is an example of underlying OS events. I assume that role too is delegated to other parts of the system? -- Trent Jarvi tjarvi at qbang.org From lyon at docjava.com Thu Mar 23 08:10:33 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Thu, 23 Mar 2006 10:10:33 -0500 Subject: [Rxtx] Classes don't need goals, they need roles! In-Reply-To: References: Message-ID: Hi Trent, Yes, I think that the role of the Parametric Singleton Pattern is not to open or close serial ports, nor is it to perform error checking. On the other hand, if you were to combine the role of the Parametric Singleton Pattern with another role (like that of error checking) it might not be amiss. However, I generally caution programmers against adding multiple roles to classes, as this leads to monolithic designs. Thus a different class (NativeLibDetect) could have the role of determining if the native library can be loaded. Another class (SerialPortBean) can have the role of serializing the default state of the serial port, so that it can be recovered, from user preferences, at a later time. The SerialPortDetect could have the role of determining if the serial port is removed (i.e., a USB port was unplugged). My guess is that each class should have a different role in the system, in order to ease maintenance and testing...but I could be wrong about that. Thanks! - Doug >Hi Doug > >Interesting reading. So far I'm just reading and thinking. I have >one question so far. > >" > Clients obtain a reference to a Parametric Singleton instance only >through the parametric singleton design pattern. If the instance is >left in an improper state (e.g., the serial port was left open) it is >NOT the role of the Parametric Singleton Design Pattern to close the >IO port. Nor is it the role of the Parametric Singleton Design Pattern >to >open the port. That role is delegate to some other part of the system. >" > >So when the clients obtain a reference to the singleton, can they >assume the port is there? IE, would it be the singletons role to >handle things like USB dongles being removed with event hints >comming from the underlying OS. Hardware abstraction layer/HAL on >Linux is an example of underlying OS events. > >I assume that role too is delegated to other parts of the system? > >-- >Trent Jarvi >tjarvi at qbang.org >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From maximulo at yahoo.com Fri Mar 24 01:22:38 2006 From: maximulo at yahoo.com (Maximulo Majir) Date: Fri, 24 Mar 2006 00:22:38 -0800 (PST) Subject: [Rxtx] JavaPOS Message-ID: <20060324082238.66371.qmail@web38214.mail.mud.yahoo.com> Hi all! Hello Trent! From what i understand, RXTX or JavaComm APIs were not created solely for JavaPOS. In JavaPOS, we have the virtual method claim() which is separate from open(), but in our RXTX API, claiming is done every call to open(), we cant open the port if its claimed by another application. Would it be alright to suggest or ask to create a new method called claim(..)? Is there such thing as forceclaim() in RXTX? this could be the same as portownership transfer or its equivalent. ForceClaim is in JSR80. Do you have some samples using RXTX as the lower layer for the Device Service Objects in JavaPOS? I have tried it, i just want to compare. Thank you all! maxim __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060324/496adba2/attachment-0027.html From tjarvi at qbang.org Fri Mar 24 11:28:19 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 24 Mar 2006 11:28:19 -0700 (MST) Subject: [Rxtx] Re: RXTX 2.1 Solaris Problems In-Reply-To: <3691.1143210578@www045.gmx.net> References: <3691.1143210578@www045.gmx.net> Message-ID: On Fri, 24 Mar 2006, Andreas Guenther wrote: > Hi all, > > the solaris problem was not the lock file only. > > Ok, I had to create the directory /var/spool/locks myself. > /var/spool/uucp exists. > > But rxtx didn't find any port. > > I compiled the source with my own debug-informations > and I tried to isolate the problem. > > The problem is the testRead-call in SerialImp.c > > JNIEXPORT jboolean JNICALL RXTXCommDriver(testRead)( > > ... > if ( READ( fd, &c, 1 ) < 0 ) > { > if ( errno != EAGAIN ) { > report( "testRead() read failed\n" ); > ret = JNI_FALSE; > } > } > Thanks Andreas I'm packing up to move. I'll be more or less away for a couple weeks here. I'll be checking email but my workstation is going into a box soon. This isn't hard to fix as this port should be enumerated when EWOULDBLOCK is recieved. Thats error is OK for enumeration just as EAGAIN is. I've put the bug into bugzilla so we dont forget to get to it. http://bugzilla.qbang.org/show_bug.cgi?id=42 You can add yourself to the CC list if you wish to test fixes we provide or even put a patch into bugzilla yourself. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Fri Mar 24 11:51:52 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 24 Mar 2006 11:51:52 -0700 (MST) Subject: [Rxtx] JavaPOS In-Reply-To: <20060324082238.66371.qmail@web38214.mail.mud.yahoo.com> References: <20060324082238.66371.qmail@web38214.mail.mud.yahoo.com> Message-ID: On Fri, 24 Mar 2006, Maximulo Majir wrote: > Hi all! Hello Trent! > > > From what i understand, RXTX or JavaComm APIs were not > created solely for JavaPOS. In JavaPOS, we have the virtual method > claim() which is separate from open(), but in our RXTX API, claiming is > done every call to open(), we cant open the port if its claimed by > another application. Would it be alright to suggest or ask to create a > new method called claim(..)? Is there such thing as forceclaim() in > RXTX? this could be the same as portownership transfer or its > equivalent. ForceClaim is in JSR80. > Do you have some samples using RXTX as the lower layer for the Device > Service Objects in JavaPOS? I have tried it, i just want to compare. > maxim Hi Maxim JSR80 is the USB API IBM/Sun put together. The problem is they have a richer kernel/API underneath that can handle such things. With Serial Ports, there isnt anything there other than an ioctl that says don't let anyone touch this and lockfiles that are more of a 'lets be nice.' At times we may be using USB ports but it is through the termios layer with the limitations mentioned. The advantage is that not only USB will work with rxtx. Anything that has a termios layer should work (to the extent that termios layer is complete). I don't know how forceclaim() would help you. Lets say someone has a programmer working on /dev/ttyS0 and you take it. Now you both race each other to read data first. There isn't a mechanism I know of that will solve this problem in termios. The most obvious test being a native app and a Java app trying to take the port. There is the potential of requestion ownership from other Java Applications but the use for that is very rare. Did you have something more specific in mind that I'm missing? I'm not sure that claim() and forceclaim() would help you with rxtx other than maybe locking the port with claim() without opening it. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sat Mar 25 23:42:08 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 25 Mar 2006 23:42:08 -0700 (MST) Subject: [Rxtx] Serial snoop Message-ID: I was reading the Linux kernel mail-list tonight and ran past a thread that mentioned sersnoop. This looks like a handy tool for people dealing with new toys. "a simple command-line tool for linux that echoes bytes to and from any two serial ports, ptys, or network sockets, and prints all traffic to stdout, in hex and ascii." http://www.restivo.org/projects/sersnoop/ It works on Linux only at this time (debian package available). -- Trent Jarvi tjarvi at qbang.org From beat.arnet at gmail.com Sun Mar 26 07:32:35 2006 From: beat.arnet at gmail.com (Beat Arnet) Date: Sun, 26 Mar 2006 09:32:35 -0500 Subject: [Rxtx] Error 0x5 at /home/bob/foo/tar/rxtx-2.1-7/build/../src/termios.c(860): Access is, denied. Message-ID: <4426A603.80508@gmail.com> Dear all, When trying to open the serial port, I sometimes (not always) run into the following exception (when opening the serialPort): Error 0x5 at /home/bob/foo/tar/rxtx-2.1-7/build/../src/termios.c(860): Access is denied. java.lang.UnsatisfiedLinkError: native_psmisc_report_owner at gnu.io.CommPortIdentifier.native_psmisc_report_owner(Native Method) at gnu.io.CommPortIdentifier.open(CommPortIdentifier.java:354) at codeskin.tools.CLLoader.open(CLLoader.java:79) at codeskin.tools.C2000Programmer.run(C2000Programmer.java:220) at java.lang.Thread.run(Unknown Source) Is this the type of error where I should just try to open the port again, or can it be avoided? Regards, Beat From tjarvi at qbang.org Sun Mar 26 11:40:12 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 26 Mar 2006 11:40:12 -0700 (MST) Subject: [Rxtx] Error 0x5 at /home/bob/foo/tar/rxtx-2.1-7/build/../src/termios.c(860): Access is, denied. In-Reply-To: <4426A603.80508@gmail.com> References: <4426A603.80508@gmail.com> Message-ID: On Sun, 26 Mar 2006, Beat Arnet wrote: > Dear all, > > When trying to open the serial port, I sometimes (not always) run into > the following exception (when opening the serialPort): > > Error 0x5 at /home/bob/foo/tar/rxtx-2.1-7/build/../src/termios.c(860): > Access is > denied. > > java.lang.UnsatisfiedLinkError: native_psmisc_report_owner > at gnu.io.CommPortIdentifier.native_psmisc_report_owner(Native > Method) > at gnu.io.CommPortIdentifier.open(CommPortIdentifier.java:354) > at codeskin.tools.CLLoader.open(CLLoader.java:79) > at codeskin.tools.C2000Programmer.run(C2000Programmer.java:220) > at java.lang.Thread.run(Unknown Source) > > Is this the type of error where I should just try to open the port again, > or can it be avoided? > Hi Beat We did a second build of rxtx 2.1-7 to resolve that unsatisfied link error. It should work now. rxtx is trying to tell you it thinks someone else has the serial port open. You can try to open the port again but maybe you already have a copy of the program running when it happens? ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7r2.zip fixed build. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sun Mar 26 11:44:23 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 26 Mar 2006 11:44:23 -0700 (MST) Subject: [Rxtx] RXTX spec file (fwd) Message-ID: This is probably interesting for fedora/suse users. ---------- Forwarded message ---------- Date: Sun, 26 Mar 2006 16:25:45 +0200 To: taj at www.linux.org.uk Subject: RXTX spec file I send you this spec file which allows to create a RPM for Fedora 4, 5 (x86, x86_64) with Java Sun. -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: rxtx.spec Url: http://mailman.qbang.org/pipermail/rxtx/attachments/20060326/6c7b6af6/rxtx-0023.pl From tjarvi at qbang.org Sun Mar 26 23:42:59 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 26 Mar 2006 23:42:59 -0700 (MST) Subject: [Rxtx] Upcomming events. Message-ID: This Wednesday we will be announcing a new "Maintainer" for the rxtx project. The position is more like neutral leader. I wont be going away or doing less. This is just the right thing to do as it turns out the two people with CVS write access will be at the same company. We need a third and we need neutrality. The maintainer will have final say in any conflict and will try to be neutral. It will be open for discussion. Then we will do it :) I'll still do most of the footwork I do now. But. I'm falling behind. I should have gone through the mail-list and posted the next round of changes this weekend. I'm packing to move and its going so so - 13 years of toys collected. I suspect there will be a dead period on my part (a couple weeks) comming up. But if you get it on the mail-list, we will get it in if there are no objections. I may well not be reading the mail-list during this period as I look for a house and many other things. I hope everyone will help out. Thanks -- Trent Jarvi tjarvi at qbang.org From mahmoud_hadad at yahoo.com Sun Mar 26 07:31:19 2006 From: mahmoud_hadad at yahoo.com (ronan nick) Date: Sun, 26 Mar 2006 06:31:19 -0800 (PST) Subject: [Rxtx] a question about the COMM API Message-ID: <20060326143119.54919.qmail@web60014.mail.yahoo.com> hi, i was intrested in knowing how i can communicate with my internal modem using java? for example if i want to make a phone dialer application or a caller id application where should i be looking at? and as i understood the COMM API is for devices that is attached to the computer through serial ports. --------------------------------- New Yahoo! Messenger with Voice. Call regular phones from your PC and save big. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060326/ce8329f0/attachment-0025.html From dmarkman at mac.com Mon Mar 20 00:20:43 2006 From: dmarkman at mac.com (Dmitry Markman) Date: Mon, 20 Mar 2006 02:20:43 -0500 Subject: [Rxtx] Mac OS X RXTX java installer In-Reply-To: References: <07D0DE29-BA32-4CFE-B036-66BC6423D385@buechse.de> <441AE3E0.2030503@willicon.de> <12531986.1142622114996.JavaMail.dmarkman@mac.com> <441B2674.9010409@willicon.de> <13577405.1142634732776.JavaMail.dmarkman@mac.com> <441B4182.8010407@willicon.de> <92CD0D6C-5BE8-426E-A46D-99452059FF49@mac.com> <441BBB2D.8030305@willicon.de> <441C4088.5090905@willicon.de> Message-ID: <64BC1E23-FDDE-4CE6-8863-CFC881CBC224@mac.com> Hi all I put RXTX installer that will install everything (and will create / var/lock if necessary and add user to the uucp group) for mac os x from Java into the rxtx's CVS repository it could be easily modified to install files for any platform it uses Greg Guerin's AuthKit for authentication and authorization Greg released that kit under artistic license, so Trent, please take a look we, probably, can negotiate license with Greg if it's necessary Greg's AuthKit could be downloaded from http://www.amug.org/~glguerin/ sw/#authkit Michael Hall (mikehall at spacestar dot net) had a suggestion to make implementation of the jaas LoginModule based on Greg's AuthKit (his modification of the Greg's AuthKit could be found at http:// www.spacestar.net/users/mikehall/authkit.dmg) but Michael's AuthKitLoginModule does only half a job: it does authenticate but it can not run any external unix process in privileged mode (at least I wasn't able to do so) possible explanation could be found in conversation between Greg and Michael at Apple's java-dev list (look for archives) so I didn't use jaas API for rxtxinstaller I created folder MacOSX in the contrib folder comment 1. if you want to run that installer as standalone application all you need that RXTXInstaller.jar 2. if you want to use webstart you have to add Greg's libAuthKit.jnilib to the mac os x's resources in theory RXTXInstaller.jar doesn't need it, but there is a problem with loading libAuthKit.jnilib from webstart authkit uses loadLibrary method to load library and it failed (from webstart) for standalone application I extract libAuthKit.jnilib from the RXTXInstaller.jar and put it into the /Library/Java/Extensions or ~/Library/Java/Extensions folder that file will be deleted after installer quit unfortunately I didn't have time to put documentation there but it is mostly self-explanatory I took installer code from my gl4java installer that I did about 3 years ago (with small modifications) it would be very nice if Apple will release LoginModule that really will do the job (com.apple.security.auth.module package????? ) (UnixLoginModule is pretty useless) From lyon at docjava.com Mon Mar 20 06:34:39 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Mon, 20 Mar 2006 08:34:39 -0500 Subject: [Rxtx] Mac OS X RXTX java installer In-Reply-To: <64BC1E23-FDDE-4CE6-8863-CFC881CBC224@mac.com> References: <07D0DE29-BA32-4CFE-B036-66BC6423D385@buechse.de> <441AE3E0.2030503@willicon.de> <12531986.1142622114996.JavaMail.dmarkman@mac.com> <441B2674.9010409@willicon.de> <13577405.1142634732776.JavaMail.dmarkman@mac.com> <441B4182.8010407@willicon.de> <92CD0D6C-5BE8-426E-A46D-99452059FF49@mac.com> <441BBB2D.8030305@willicon.de> <441C4088.5090905@willicon.de> <64BC1E23-FDDE-4CE6-8863-CFC881CBC224@mac.com> Message-ID: Hi Dimitry, This sounds like great work. Just a couple of questions; After the check out of the CVS files, using: setenv CVSROOT :pserver:anonymous at cvs.milestonesolutions.com:/usr/local/cvsroot 53 8:28 setenv PASSWORD mousy 54 8:29 cvs login 55 8:29 cvs checkout rxtx-devel I cd'd over to: rxtx-devel/MACOSX_IDE And found: CVS/ CW/ ForPackageMaker/ PB/ Where is the installer? Thanks! - Doug From tjarvi at qbang.org Mon Mar 20 06:39:37 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 20 Mar 2006 06:39:37 -0700 (MST) Subject: [Rxtx] Mac OS X RXTX java installer In-Reply-To: References: <07D0DE29-BA32-4CFE-B036-66BC6423D385@buechse.de> <441AE3E0.2030503@willicon.de> <12531986.1142622114996.JavaMail.dmarkman@mac.com> <441B2674.9010409@willicon.de> <13577405.1142634732776.JavaMail.dmarkman@mac.com> <441B4182.8010407@willicon.de> <92CD0D6C-5BE8-426E-A46D-99452059FF49@mac.com> <441BBB2D.8030305@willicon.de> <441C4088.5090905@willicon.de> <64BC1E23-FDDE-4CE6-8863-CFC881CBC224@mac.com> Message-ID: On Mon, 20 Mar 2006, Dr. Douglas Lyon wrote: > Hi Dimitry, > This sounds like great work. Just a couple of questions; > After the check out of the CVS files, using: > setenv CVSROOT > :pserver:anonymous at cvs.milestonesolutions.com:/usr/local/cvsroot > 53 8:28 setenv PASSWORD mousy > 54 8:29 cvs login > 55 8:29 cvs checkout rxtx-devel Hi Doug You want "cvs checkout -r commapi-0-0-1 rxtx-devel" to get RXTX 2.1 The default branch is rxtx 2.0 which isn't very active right now. -- Trent Jarvi tjarvi at qbang.org From lyon at docjava.com Mon Mar 20 07:05:44 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Mon, 20 Mar 2006 09:05:44 -0500 Subject: [Rxtx] Mac OS X RXTX java installer In-Reply-To: References: <07D0DE29-BA32-4CFE-B036-66BC6423D385@buechse.de> <441AE3E0.2030503@willicon.de> <12531986.1142622114996.JavaMail.dmarkman@mac.com> <441B2674.9010409@willicon.de> <13577405.1142634732776.JavaMail.dmarkman@mac.com> <441B4182.8010407@willicon.de> <92CD0D6C-5BE8-426E-A46D-99452059FF49@mac.com> <441BBB2D.8030305@willicon.de> <441C4088.5090905@willicon.de> <64BC1E23-FDDE-4CE6-8863-CFC881CBC224@mac.com> Message-ID: Hi Trent, Thanks for the info on the CVS checkout procedure. I did that and am still not sure where the installer is. Here is what I have: cd MACOSX_IDE/ p4.docjava.com{lyon}121: ls CVS/ ForPackageMaker/ PB/ p4.docjava.com{lyon}122: find . | more . ./ForPackageMaker ./ForPackageMaker/RXTX.pkg.sit.hqx ./ForPackageMaker/Resources ./ForPackageMaker/Resources/ReadMe.rtf ./ForPackageMaker/Resources/Welcome.rtf ./ForPackageMaker/Resources/CVS ./ForPackageMaker/Resources/CVS/Entries ./ForPackageMaker/Resources/CVS/Repository ./ForPackageMaker/Resources/CVS/Tag ./ForPackageMaker/Resources/CVS/Root ./ForPackageMaker/Resources/preinstall ./ForPackageMaker/Resources/License.rtf ./ForPackageMaker/Resources/preupgrade ./ForPackageMaker/RXTX.pmsp ./ForPackageMaker/CVS ./ForPackageMaker/CVS/Entries ./ForPackageMaker/CVS/Repository ./ForPackageMaker/CVS/Entries.Log ./ForPackageMaker/CVS/Tag ./ForPackageMaker/CVS/Root ./ForPackageMaker/RXTX_Tiger.pkg.sitx.hqx ./ForPackageMaker/RXTX_Jag.pkg.sit.hqx ./ForPackageMaker/Install ./ForPackageMaker/Install/CVS ./ForPackageMaker/Install/CVS/Entries ./ForPackageMaker/Install/CVS/Repository ./ForPackageMaker/Install/CVS/Tag ./ForPackageMaker/Install/CVS/Root ./ForPackageMaker/Install/Library ./ForPackageMaker/Install/Library/CVS ./ForPackageMaker/Install/Library/CVS/Entries ./ForPackageMaker/Install/Library/CVS/Repository ./ForPackageMaker/Install/Library/CVS/Tag ./ForPackageMaker/Install/Library/CVS/Root ./ForPackageMaker/Install/Library/Java ./ForPackageMaker/Install/Library/Java/Extensions ./ForPackageMaker/Install/Library/Java/Extensions/RXTXcomm.jar ./ForPackageMaker/Install/Library/Java/Extensions/CVS ./ForPackageMaker/Install/Library/Java/Extensions/CVS/Entries ./ForPackageMaker/Install/Library/Java/Extensions/CVS/Repository ./ForPackageMaker/Install/Library/Java/Extensions/CVS/Tag ./ForPackageMaker/Install/Library/Java/Extensions/CVS/Root ./ForPackageMaker/Install/Library/Java/Extensions/librxtxSerial.jnilib ./ForPackageMaker/Install/Library/Java/CVS ./ForPackageMaker/Install/Library/Java/CVS/Entries ./ForPackageMaker/Install/Library/Java/CVS/Repository ./ForPackageMaker/Install/Library/Java/CVS/Entries.Log ./ForPackageMaker/Install/Library/Java/CVS/Tag ./ForPackageMaker/Install/Library/Java/CVS/Root ./ForPackageMaker/RXTX_Tiger.pmproj.sitx.hqx ./CVS ./CVS/Entries ./CVS/Repository ./CVS/Entries.Log ./CVS/Tag ./CVS/Root ./PB ./PB/LibSerialUniversal.xcodeproj.sitx.hqx ./PB/CVS ./PB/CVS/Entries ./PB/CVS/Repository ./PB/CVS/Entries.Log ./PB/CVS/Tag ./PB/CVS/Root ./PB/LibSerial.pbproj.sit.hqx ./PB/startpoint.c ./PB/config.h What is the procedure to run this installer? Do we need a README in: /rxtx-devel/MACOSX_IDE Here is what we have: CVS/ ForPackageMaker/ PB/ Thanks! - DL >On Mon, 20 Mar 2006, Dr. Douglas Lyon wrote: > >>Hi Dimitry, >>This sounds like great work. Just a couple of questions; >>After the check out of the CVS files, using: >>setenv CVSROOT >>:pserver:anonymous at cvs.milestonesolutions.com:/usr/local/cvsroot >> 53 8:28 setenv PASSWORD mousy >> 54 8:29 cvs login >> 55 8:29 cvs checkout rxtx-devel > >Hi Doug > >You want "cvs checkout -r commapi-0-0-1 rxtx-devel" to get RXTX 2.1 >The default branch is rxtx 2.0 which isn't very active right now. > >-- >Trent Jarvi >tjarvi at qbang.org From tjarvi at qbang.org Mon Mar 20 07:25:30 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 20 Mar 2006 07:25:30 -0700 (MST) Subject: [Rxtx] Mac OS X RXTX java installer In-Reply-To: References: <07D0DE29-BA32-4CFE-B036-66BC6423D385@buechse.de> <441AE3E0.2030503@willicon.de> <12531986.1142622114996.JavaMail.dmarkman@mac.com> <441B2674.9010409@willicon.de> <13577405.1142634732776.JavaMail.dmarkman@mac.com> <441B4182.8010407@willicon.de> <92CD0D6C-5BE8-426E-A46D-99452059FF49@mac.com> <441BBB2D.8030305@willicon.de> <441C4088.5090905@willicon.de> <64BC1E23-FDDE-4CE6-8863-CFC881CBC224@mac.com> Message-ID: On Mon, 20 Mar 2006, Dr. Douglas Lyon wrote: > Hi Trent, > Thanks for the info on the CVS checkout procedure. > I did that and am still not sure where the installer is. Hi Doug It does look like it was not cvs committed. There is no rxtx-devel/contrib/MacOSX directory in there at the moment. It was mentioned that it was put under contrib. -- Trent Jarvi tjarvi at qbang.org From dmarkman at mac.com Mon Mar 20 07:29:56 2006 From: dmarkman at mac.com (Dmitry Markman) Date: Mon, 20 Mar 2006 09:29:56 -0500 Subject: [Rxtx] Mac OS X RXTX java installer In-Reply-To: References: <07D0DE29-BA32-4CFE-B036-66BC6423D385@buechse.de> <441AE3E0.2030503@willicon.de> <12531986.1142622114996.JavaMail.dmarkman@mac.com> <441B2674.9010409@willicon.de> <13577405.1142634732776.JavaMail.dmarkman@mac.com> <441B4182.8010407@willicon.de> <92CD0D6C-5BE8-426E-A46D-99452059FF49@mac.com> <441BBB2D.8030305@willicon.de> <441C4088.5090905@willicon.de> <64BC1E23-FDDE-4CE6-8863-CFC881CBC224@mac.com> Message-ID: <6054EB4E-F7E0-4A9C-BDDA-D582D6D8826F@mac.com> you can find it in the rxtx-devel/contrib folder On Mar 20, 2006, at 9:05 AM, Dr. Douglas Lyon wrote: > Hi Trent, > Thanks for the info on the CVS checkout procedure. > I did that and am still not sure where the installer is. > Here is what I have: > cd MACOSX_IDE/ > p4.docjava.com{lyon}121: ls > CVS/ ForPackageMaker/ PB/ > p4.docjava.com{lyon}122: find . | more > . > ./ForPackageMaker > ./ForPackageMaker/RXTX.pkg.sit.hqx > ./ForPackageMaker/Resources > ./ForPackageMaker/Resources/ReadMe.rtf > ./ForPackageMaker/Resources/Welcome.rtf > ./ForPackageMaker/Resources/CVS > ./ForPackageMaker/Resources/CVS/Entries > ./ForPackageMaker/Resources/CVS/Repository > ./ForPackageMaker/Resources/CVS/Tag > ./ForPackageMaker/Resources/CVS/Root > ./ForPackageMaker/Resources/preinstall > ./ForPackageMaker/Resources/License.rtf > ./ForPackageMaker/Resources/preupgrade > ./ForPackageMaker/RXTX.pmsp > ./ForPackageMaker/CVS > ./ForPackageMaker/CVS/Entries > ./ForPackageMaker/CVS/Repository > ./ForPackageMaker/CVS/Entries.Log > ./ForPackageMaker/CVS/Tag > ./ForPackageMaker/CVS/Root > ./ForPackageMaker/RXTX_Tiger.pkg.sitx.hqx > ./ForPackageMaker/RXTX_Jag.pkg.sit.hqx > ./ForPackageMaker/Install > ./ForPackageMaker/Install/CVS > ./ForPackageMaker/Install/CVS/Entries > ./ForPackageMaker/Install/CVS/Repository > ./ForPackageMaker/Install/CVS/Tag > ./ForPackageMaker/Install/CVS/Root > ./ForPackageMaker/Install/Library > ./ForPackageMaker/Install/Library/CVS > ./ForPackageMaker/Install/Library/CVS/Entries > ./ForPackageMaker/Install/Library/CVS/Repository > ./ForPackageMaker/Install/Library/CVS/Tag > ./ForPackageMaker/Install/Library/CVS/Root > ./ForPackageMaker/Install/Library/Java > ./ForPackageMaker/Install/Library/Java/Extensions > ./ForPackageMaker/Install/Library/Java/Extensions/RXTXcomm.jar > ./ForPackageMaker/Install/Library/Java/Extensions/CVS > ./ForPackageMaker/Install/Library/Java/Extensions/CVS/Entries > ./ForPackageMaker/Install/Library/Java/Extensions/CVS/Repository > ./ForPackageMaker/Install/Library/Java/Extensions/CVS/Tag > ./ForPackageMaker/Install/Library/Java/Extensions/CVS/Root > ./ForPackageMaker/Install/Library/Java/Extensions/librxtxSerial.jnilib > ./ForPackageMaker/Install/Library/Java/CVS > ./ForPackageMaker/Install/Library/Java/CVS/Entries > ./ForPackageMaker/Install/Library/Java/CVS/Repository > ./ForPackageMaker/Install/Library/Java/CVS/Entries.Log > ./ForPackageMaker/Install/Library/Java/CVS/Tag > ./ForPackageMaker/Install/Library/Java/CVS/Root > ./ForPackageMaker/RXTX_Tiger.pmproj.sitx.hqx > ./CVS > ./CVS/Entries > ./CVS/Repository > ./CVS/Entries.Log > ./CVS/Tag > ./CVS/Root > ./PB > ./PB/LibSerialUniversal.xcodeproj.sitx.hqx > ./PB/CVS > ./PB/CVS/Entries > ./PB/CVS/Repository > ./PB/CVS/Entries.Log > ./PB/CVS/Tag > ./PB/CVS/Root > ./PB/LibSerial.pbproj.sit.hqx > ./PB/startpoint.c > ./PB/config.h > > What is the procedure to run this installer? > Do we need a README in: > /rxtx-devel/MACOSX_IDE > Here is what we have: > CVS/ ForPackageMaker/ PB/ > > > Thanks! > - DL > >> On Mon, 20 Mar 2006, Dr. Douglas Lyon wrote: >> >>> Hi Dimitry, >>> This sounds like great work. Just a couple of questions; >>> After the check out of the CVS files, using: >>> setenv CVSROOT :pserver:anonymous at cvs.milestonesolutions.com:/usr/ >>> local/cvsroot >>> 53 8:28 setenv PASSWORD mousy >>> 54 8:29 cvs login >>> 55 8:29 cvs checkout rxtx-devel >> >> Hi Doug >> >> You want "cvs checkout -r commapi-0-0-1 rxtx-devel" to get RXTX 2.1 >> The default branch is rxtx 2.0 which isn't very active right now. >> >> -- >> Trent Jarvi >> tjarvi at qbang.org > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx Dmitry Markman From mikehall at spacestar.net Mon Mar 20 05:25:25 2006 From: mikehall at spacestar.net (Michael Hall) Date: Mon, 20 Mar 2006 06:25:25 -0600 Subject: [Rxtx] Re: Mac OS X RXTX java installer In-Reply-To: <64BC1E23-FDDE-4CE6-8863-CFC881CBC224@mac.com> References: <07D0DE29-BA32-4CFE-B036-66BC6423D385@buechse.de> <441AE3E0.2030503@willicon.de> <12531986.1142622114996.JavaMail.dmarkman@mac.com> <441B2674.9010409@willicon.de> <13577405.1142634732776.JavaMail.dmarkman@mac.com> <441B4182.8010407@willicon.de> <92CD0D6C-5BE8-426E-A46D-99452059FF49@mac.com> <441BBB2D.8030305@willicon.de> <441C4088.5090905@willicon.de> <64BC1E23-FDDE-4CE6-8863-CFC881CBC224@mac.com> Message-ID: <247EB61F-5CD1-4132-89A2-FC105B6CF9A5@spacestar.net> On Mar 20, 2006, at 1:20 AM, Dmitry Markman wrote: > > Michael Hall (mikehall at spacestar dot net) had a suggestion to > make implementation of the jaas LoginModule > based on Greg's AuthKit > (his modification of the Greg's AuthKit could be found at http:// > www.spacestar.net/users/mikehall/authkit.dmg) > but Michael's AuthKitLoginModule does only half a job: > it does authenticate > but it can not run any external unix process in privileged mode (at > least I wasn't able to do so) If you got it working directly with Greg's the point is moot. But to clarify it anyhow. The login module does not allow you to do anything anything privileged on return as was explained by Greg. You need to work with a separate privileged process using the execPrivileged method of his API. I assume you did something similar although I haven't looked at how you are using it yet. I allowed instead for a action to be performed at the same time you login/authenticate,this... System.setProperty("authkit.action","/usr/bin/id"); just before this... lc.login(); To clarify, safely ignored as you are already complete. Mike Hall mikehall at spacestar dot net http://www.spacestar.net/users/mikehall http://sourceforge.net/projects/macnative -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2427 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20060320/f6e18202/smime-0028.bin From dmarkman at mac.com Mon Mar 20 07:36:47 2006 From: dmarkman at mac.com (Dmitry Markman) Date: Mon, 20 Mar 2006 09:36:47 -0500 Subject: [Rxtx] Re: Mac OS X RXTX java installer In-Reply-To: <247EB61F-5CD1-4132-89A2-FC105B6CF9A5@spacestar.net> References: <07D0DE29-BA32-4CFE-B036-66BC6423D385@buechse.de> <441AE3E0.2030503@willicon.de> <12531986.1142622114996.JavaMail.dmarkman@mac.com> <441B2674.9010409@willicon.de> <13577405.1142634732776.JavaMail.dmarkman@mac.com> <441B4182.8010407@willicon.de> <92CD0D6C-5BE8-426E-A46D-99452059FF49@mac.com> <441BBB2D.8030305@willicon.de> <441C4088.5090905@willicon.de> <64BC1E23-FDDE-4CE6-8863-CFC881CBC224@mac.com> <247EB61F-5CD1-4132-89A2-FC105B6CF9A5@spacestar.net> Message-ID: Hi, Michael all I have to do is to run some shell script I tried to use your action mechanism and it worked great so I just System.setProperty ("authkit.action","" ) and after that I even don't need to run anything like subject.doAs.... but after few thoughts I choose to use plain Greg's approach, because in that case I don't have to deal with various java's configurations files and therefore to use 2-3 -D parameters in the java command line especially it's useful for java web start (it's so fragile :-( ) thanks for the great job On Mar 20, 2006, at 7:25 AM, Michael Hall wrote: > > On Mar 20, 2006, at 1:20 AM, Dmitry Markman wrote: >> >> Michael Hall (mikehall at spacestar dot net) had a suggestion to >> make implementation of the jaas LoginModule >> based on Greg's AuthKit >> (his modification of the Greg's AuthKit could be found at http:// >> www.spacestar.net/users/mikehall/authkit.dmg) >> but Michael's AuthKitLoginModule does only half a job: >> it does authenticate >> but it can not run any external unix process in privileged mode >> (at least I wasn't able to do so) > > If you got it working directly with Greg's the point is moot. > > But to clarify it anyhow. > The login module does not allow you to do anything anything > privileged on return as was explained by Greg. You need to work > with a separate privileged process using the execPrivileged method > of his API. I assume you did something similar although I haven't > looked at how you are using it yet. > I allowed instead for a action to be performed at the same time you > login/authenticate,this... > System.setProperty("authkit.action","/usr/bin/id"); > just before this... > lc.login(); > To clarify, safely ignored as you are already complete. > > Mike Hall mikehall at spacestar dot net > http://www.spacestar.net/users/mikehall > http://sourceforge.net/projects/macnative > > > Dmitry Markman From dmarkman at mac.com Mon Mar 20 07:44:45 2006 From: dmarkman at mac.com (Dmitry Markman) Date: Mon, 20 Mar 2006 09:44:45 -0500 Subject: [Rxtx] Mac OS X RXTX java installer In-Reply-To: References: <07D0DE29-BA32-4CFE-B036-66BC6423D385@buechse.de> <441AE3E0.2030503@willicon.de> <12531986.1142622114996.JavaMail.dmarkman@mac.com> <441B2674.9010409@willicon.de> <13577405.1142634732776.JavaMail.dmarkman@mac.com> <441B4182.8010407@willicon.de> <92CD0D6C-5BE8-426E-A46D-99452059FF49@mac.com> <441BBB2D.8030305@willicon.de> <441C4088.5090905@willicon.de> <64BC1E23-FDDE-4CE6-8863-CFC881CBC224@mac.com> Message-ID: it's in the commapi-0-0-1 branch I tested it right now: cvs co -r commapi-0-0-1 rxtx-devel and I got everything On Mar 20, 2006, at 9:25 AM, Trent Jarvi wrote: > On Mon, 20 Mar 2006, Dr. Douglas Lyon wrote: > >> Hi Trent, >> Thanks for the info on the CVS checkout procedure. >> I did that and am still not sure where the installer is. > > Hi Doug > > It does look like it was not cvs committed. There is no rxtx-devel/ > contrib/MacOSX directory in there at the moment. It was mentioned > that it was put under contrib. > > -- > Trent Jarvi > tjarvi at qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx Dmitry Markman From tjarvi at qbang.org Mon Mar 20 07:52:57 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 20 Mar 2006 07:52:57 -0700 (MST) Subject: [Rxtx] Mac OS X RXTX java installer In-Reply-To: References: <07D0DE29-BA32-4CFE-B036-66BC6423D385@buechse.de> <441AE3E0.2030503@willicon.de> <12531986.1142622114996.JavaMail.dmarkman@mac.com> <441B2674.9010409@willicon.de> <13577405.1142634732776.JavaMail.dmarkman@mac.com> <441B4182.8010407@willicon.de> <92CD0D6C-5BE8-426E-A46D-99452059FF49@mac.com> <441BBB2D.8030305@willicon.de> <441C4088.5090905@willicon.de> <64BC1E23-FDDE-4CE6-8863-CFC881CBC224@mac.com> Message-ID: On Mon, 20 Mar 2006, Dmitry Markman wrote: > it's in the commapi-0-0-1 branch > > I tested it right now: > cvs co -r commapi-0-0-1 rxtx-devel > > and I got everything > A fresh checkout worked. Here is a copy of the tree (just the installer bits) ftp://ftp.qbang.org/pub/rxtx/MacOSX-installer.zip -- Trent Jarvi tjarvi at qbang.org From lyon at docjava.com Mon Mar 20 08:08:26 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Mon, 20 Mar 2006 10:08:26 -0500 Subject: [Rxtx] Mac OS X RXTX java installer In-Reply-To: References: <07D0DE29-BA32-4CFE-B036-66BC6423D385@buechse.de> <441AE3E0.2030503@willicon.de> <12531986.1142622114996.JavaMail.dmarkman@mac.com> <441B2674.9010409@willicon.de> <13577405.1142634732776.JavaMail.dmarkman@mac.com> <441B4182.8010407@willicon.de> <92CD0D6C-5BE8-426E-A46D-99452059FF49@mac.com> <441BBB2D.8030305@willicon.de> <441C4088.5090905@willicon.de> <64BC1E23-FDDE-4CE6-8863-CFC881CBC224@mac.com> Message-ID: Hi All, Is the Auth package able to work properly on non Mac OS's? It was not clear from the doc or download. Thanks! - Doug From dmarkman at mac.com Mon Mar 20 08:15:22 2006 From: dmarkman at mac.com (Dmitry Markman) Date: Mon, 20 Mar 2006 10:15:22 -0500 Subject: [Rxtx] Mac OS X RXTX java installer In-Reply-To: References: <07D0DE29-BA32-4CFE-B036-66BC6423D385@buechse.de> <441AE3E0.2030503@willicon.de> <12531986.1142622114996.JavaMail.dmarkman@mac.com> <441B2674.9010409@willicon.de> <13577405.1142634732776.JavaMail.dmarkman@mac.com> <441B4182.8010407@willicon.de> <92CD0D6C-5BE8-426E-A46D-99452059FF49@mac.com> <441BBB2D.8030305@willicon.de> <441C4088.5090905@willicon.de> <64BC1E23-FDDE-4CE6-8863-CFC881CBC224@mac.com> Message-ID: <217312D8-CCCA-4859-ABA6-32DF1CC817B9@mac.com> thanks Trent, for putting it on ftp server On Mar 20, 2006, at 9:52 AM, Trent Jarvi wrote: > A fresh checkout worked. Here is a copy of the tree (just the > installer bits) > > ftp://ftp.qbang.org/pub/rxtx/MacOSX-installer.zip > Dmitry Markman From dmarkman at mac.com Mon Mar 20 09:14:03 2006 From: dmarkman at mac.com (Dmitry Markman) Date: Mon, 20 Mar 2006 11:14:03 -0500 Subject: [Rxtx] Mac OS X RXTX java installer In-Reply-To: References: <07D0DE29-BA32-4CFE-B036-66BC6423D385@buechse.de> <441AE3E0.2030503@willicon.de> <12531986.1142622114996.JavaMail.dmarkman@mac.com> <441B2674.9010409@willicon.de> <13577405.1142634732776.JavaMail.dmarkman@mac.com> <441B4182.8010407@willicon.de> <92CD0D6C-5BE8-426E-A46D-99452059FF49@mac.com> <441BBB2D.8030305@willicon.de> <441C4088.5090905@willicon.de> <64BC1E23-FDDE-4CE6-8863-CFC881CBC224@mac.com> Message-ID: <4DEBA6F0-DA45-4E84-823E-1F1AC48BDCCC@mac.com> no it will work only on mac os x however it's harmless to run it on other platform if you want to use it for other platform you have to do the following (I'll do it for linux) 1. modify RXTXInstaller class method public static RXTXInstaller getInstance() public static RXTXInstaller getInstance() { String osName = System.getProperty("os.name").toLowerCase(); if(osName.startsWith("mac")){ return new gnu.io.installer.macosx.MACOSXRXTXInstaller(); } else if(osName.startsWith("windows")){ return new gnu.io.installer.windows.WindowsRXTXInstaller(); }else if(osName.startsWith("linux")){ return new gnu.io.installer.linux.LinuxRXTXInstaller(); } return null; } 2. create folder gnu/io/installer/linux/ 3. create class Linux386RXTXInstaller package gnu.io.installer.linux; import java.io.File; public class Linux386RXTXInstaller extends gnu.io.installer.RXTXInstaller{ public Linux386RXTXInstaller(){ createJarFolder(); createLibFolder(); addJarResource("RXTXcomm.jar","/gnu/io/installer/resources/ linux/jar/RXTXcomm.dat"); addLibResource("librxtxSerial.so","/gnu/io/installer/ resources/linux/lib/librxtxSerial.so"); } protected void createJarFolder(){ String javaHome = System.getProperty("java.home"); char separator = File.separatorChar; jarFolder = new File(javaHome+separator+"lib"+separator+"ext"); } protected void createLibFolder(){ String javaHome = System.getProperty("java.home"); char separator = File.separatorChar; libFolder = new File(javaHome+separator+"bin"); } public void runPreProcess() {} //put here some action you need public void runPostProcess() {} //put here some action you need } 4. create folder /gnu/io/installer/resources/linux/jar and put there linux's version of RXTXcomm.dat (which is renamed RXTXcomm.jar) 5. create folder /gnu/io/installer/resources/linux/lib and put there linux's version of librxtxSerial. so 6. make sure that RXTXInstaller.jar has the following items: /gnu/io/installer/resources/linux/jar/RXTXcomm.jar /gnu/io/installer/resources/linux/lib/librxtxSerial.so 7. modify file installer.pref: jar file RXTXInstaller.jar must have the following item /gnu/io/installer/installer.pref that's basically it for windows you have to do the similar things: just replace linux to windows and librxtxSerial.so to rxtxSerial.dll and create appropriate gnu.io.installer.windows.WindowsRXTXInstaller class package gnu.io.installer.windows; import java.io.File; public class WindowsRXTXInstaller extends gnu.io.installer.RXTXInstaller{ public WindowsRXTXInstaller(){ createJarFolder(); createLibFolder(); addJarResource("RXTXcomm.jar","/gnu/io/installer/resources/ windows/jar/RXTXcomm.dat"); addLibResource("librxtxSerial.so","/gnu/io/installer/ resources/windows/lib/rxtxSerial.dll"); } protected void createJarFolder(){ String javaHome = System.getProperty("java.home"); char separator = File.separatorChar; jarFolder = new File(javaHome+separator+"lib"+separator+"ext"); } protected void createLibFolder(){ String javaHome = System.getProperty("java.home"); char separator = File.separatorChar; libFolder = new File(javaHome+separator+"bin"); } public void runPreProcess() {} //put here some action you need public void runPostProcess() {} //put here some action you need } installer.pref will look like On Mar 20, 2006, at 10:08 AM, Dr. Douglas Lyon wrote: > Hi All, > Is the Auth package able to work properly on > non Mac OS's? > It was not clear from the doc or download. > > Thanks! > - Doug > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx Dmitry Markman From joachim at buechse.de Mon Mar 20 10:49:06 2006 From: joachim at buechse.de (Joachim Buechse) Date: Mon, 20 Mar 2006 18:49:06 +0100 Subject: [Rxtx] BUG: Lock file stays even if port opening fails Message-ID: This was only tested on MacOSX but looking at the code, it should be true for all systems that use lock_uucp. I am opening a port which can not be opened (dialup port of a telephone paired via bluetooth but currently not reachable). The lock file is created and stays arround, even though the port open failed. After looking a bit through the code (of 2.17), I really wonder if it wouldn't be a good idea to make the "locking" an explicit operation called from the java code. This would certainly simplify the generation of meaningfull exceptions (and java based debugging). Maybe even the handling of "preopened" ports should be in the Java part of the lib (again for java based debugging puposes). That beeing said, I have no idea if this would be possible for the 2.07 implementation. Regards, Joachim From tjarvi at qbang.org Mon Mar 20 11:24:22 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 20 Mar 2006 11:24:22 -0700 (MST) Subject: [Rxtx] BUG: Lock file stays even if port opening fails In-Reply-To: References: Message-ID: On Mon, 20 Mar 2006, Joachim Buechse wrote: > This was only tested on MacOSX but looking at the code, it should be true > for all systems that use lock_uucp. > > I am opening a port which can not be opened (dialup port of a telephone > paired via bluetooth but currently not reachable). The lock file is > created and stays arround, even though the port open failed. > > > After looking a bit through the code (of 2.17), I really wonder if it > wouldn't be a good idea to make the "locking" an explicit operation > called from the java code. This would certainly simplify the generation > of meaningfull exceptions (and java based debugging). > Maybe even the handling of "preopened" ports should be in the Java part > of the lib (again for java based debugging puposes). That beeing said, I > have no idea if this would be possible for the 2.07 implementation. > > Regards, Hi Joachim It should be possible in the 2.0-7 implementation too. The calls to RXTXPort.java would not change. We would just do more there Moving more of that logic into Java would be better as many people don't like to look at C code. There is a liblockdev on most Linux distros that can do most of the C code and would be easier to use. The problem is embeded devices will not have that library. The preopened port code has not been really tested. That was a last minute request in a product cycle. I expect it will be tested this year though. As I recall, some devices really do not like CD raising on open. The preopened ports then allow people to mess around in java without power cycling the devices or losing data. -- Trent Jarvi tjarvi at qbang.org From joachim at buechse.de Mon Mar 20 12:01:08 2006 From: joachim at buechse.de (Joachim Buechse) Date: Mon, 20 Mar 2006 20:01:08 +0100 Subject: [Rxtx] BUG: Lock file stays even if port opening fails In-Reply-To: References: Message-ID: Hi Trent, What is your general feeling about moving code to Java? The last days I have been reading quite a bit of the code and there are several things, that might not work as expected. I'll give you two examples from is_device_locked: if LOCKDIR == /var/spool/locks the directory /var/spool/lock will not be checked. LOCKDIR is not checked for lockfiles with unexpected pefixes While these things have probably never been discovered in production, they are still possibly incorrect implementations. If it was Java code, I would write some unit tests producing the errors that could later be corrected. PS: One could imagine to actually implement the whole lockfile handling in Java using some native routines to get the values required (pid, st_dev, st_rdev, ...). On 20.03.2006, at 19:24, Trent Jarvi wrote: > On Mon, 20 Mar 2006, Joachim Buechse wrote: > >> This was only tested on MacOSX but looking at the code, it should >> be true for all systems that use lock_uucp. >> >> I am opening a port which can not be opened (dialup port of a >> telephone paired via bluetooth but currently not reachable). The >> lock file is created and stays arround, even though the port open >> failed. >> >> >> After looking a bit through the code (of 2.17), I really wonder if >> it wouldn't be a good idea to make the "locking" an explicit >> operation called from the java code. This would certainly simplify >> the generation of meaningfull exceptions (and java based debugging). >> Maybe even the handling of "preopened" ports should be in the Java >> part of the lib (again for java based debugging puposes). That >> beeing said, I have no idea if this would be possible for the 2.07 >> implementation. >> >> Regards, > > Hi Joachim > > It should be possible in the 2.0-7 implementation too. The calls > to RXTXPort.java would not change. We would just do more there > Moving more of that logic into Java would be better as many people > don't like to look at C code. There is a liblockdev on most Linux > distros that can do most of the C code and would be easier to use. > The problem is embeded devices will not have that library. > > The preopened port code has not been really tested. That was a > last minute request in a product cycle. I expect it will be tested > this year though. As I recall, some devices really do not like CD > raising on open. The preopened ports then allow people to mess > around in java without power cycling the devices or losing data. > > -- > Trent Jarvi > tjarvi at qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Mon Mar 20 12:21:02 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 20 Mar 2006 12:21:02 -0700 (MST) Subject: [Rxtx] BUG: Lock file stays even if port opening fails In-Reply-To: References: Message-ID: On Mon, 20 Mar 2006, Joachim Buechse wrote: > Hi Trent, > > What is your general feeling about moving code to Java? The last days I > have been reading quite a bit of the code and there are several things, > that might not work as expected. > > I'll give you two examples from is_device_locked: > > if LOCKDIR == /var/spool/locks the directory /var/spool/lock will not be > checked. > LOCKDIR is not checked for lockfiles with unexpected pefixes > > While these things have probably never been discovered in production, > they are still possibly incorrect implementations. If it was Java code, I > would write some unit tests producing the errors that could later be > corrected. > > PS: One could imagine to actually implement the whole lockfile handling > in Java using some native routines to get the values required (pid, > st_dev, st_rdev, ...). Hi Joachim I like the idea of moving more of the code into java but there are some things to consider. If you break this into multiple JNI calls, the performance will drop considerably during enumeration of ports. We are looking for 256 ports per dev type vs (16? in Sun's 2.0 and fewer types). Its hard to make assumptions. I've seen virtual ports start at /dev/foo100 for instance. It works out to over 7500 ports on Linux if you enable them all. We already trim that back by default. See Linux-all-ports in RXTXCommDriver.java. There are also native libraries that rxtx can link to. If you move too much into Java, linking to 'standard' libraries with distros will break. "configure --enable-liblock=yes" will not be doable. This is probably a favorable way with RedHat, Debian, Suse and others. Thats the right thing to do if there will be rpms, dpkg, .. For those reasons, I think it still make sense to keep it to a minimal ~3 calls to JNI code that we can use for speed and versatility. lock() isLocked(), unlock() perhaps. When I say speed, its more about avoiding crossing the JNI layer multiple times than java vs C performance. With versatility I think liblock is the right way for most but not all (embeded) linux distros. -- Trent Jarvi tjarvi at qbang.org From joachim at buechse.de Mon Mar 20 12:42:04 2006 From: joachim at buechse.de (Joachim Buechse) Date: Mon, 20 Mar 2006 20:42:04 +0100 Subject: [Rxtx] BUG: Lock file stays even if port opening fails In-Reply-To: References: Message-ID: <82C19FE7-DDCB-45B6-B2C9-7606B66F0124@buechse.de> Ok, what about providing a default implementation in Java? The RXTXCommDriver would call a (native) function useNativeLocking and if it returns true, call the native functions for lock() isLocked (), unlock(), else is would use the Java based default implementation. This could possibly be overriden by a property (again for debugging). Joachim On 20.03.2006, at 20:21, Trent Jarvi wrote: > On Mon, 20 Mar 2006, Joachim Buechse wrote: > >> Hi Trent, >> >> What is your general feeling about moving code to Java? The last >> days I have been reading quite a bit of the code and there are >> several things, that might not work as expected. >> >> I'll give you two examples from is_device_locked: >> >> if LOCKDIR == /var/spool/locks the directory /var/spool/lock will >> not be checked. >> LOCKDIR is not checked for lockfiles with unexpected pefixes >> >> While these things have probably never been discovered in >> production, they are still possibly incorrect implementations. If >> it was Java code, I would write some unit tests producing the >> errors that could later be corrected. >> >> PS: One could imagine to actually implement the whole lockfile >> handling in Java using some native routines to get the values >> required (pid, st_dev, st_rdev, ...). > > Hi Joachim > > I like the idea of moving more of the code into java but there are > some things to consider. > > If you break this into multiple JNI calls, the performance will > drop considerably during enumeration of ports. We are looking for > 256 ports per dev type vs (16? in Sun's 2.0 and fewer types). Its > hard to make assumptions. I've seen virtual ports start at /dev/ > foo100 for instance. > > It works out to over 7500 ports on Linux if you enable them all. > We already trim that back by default. See Linux-all-ports in > RXTXCommDriver.java. > > There are also native libraries that rxtx can link to. If you move > too much into Java, linking to 'standard' libraries with distros > will break. "configure --enable-liblock=yes" will not be doable. > This is probably a favorable way with RedHat, Debian, Suse and > others. Thats the right thing to do if there will be rpms, dpkg, .. > > For those reasons, I think it still make sense to keep it to a > minimal ~3 calls to JNI code that we can use for speed and > versatility. lock() isLocked(), unlock() perhaps. When I say > speed, its more about avoiding crossing the JNI layer multiple > times than java vs C performance. With versatility I think liblock > is the right way for most but not all (embeded) linux distros. > > -- > Trent Jarvi > tjarvi at qbang.org > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Mon Mar 20 12:44:47 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 20 Mar 2006 12:44:47 -0700 (MST) Subject: [Rxtx] BUG: Lock file stays even if port opening fails In-Reply-To: <82C19FE7-DDCB-45B6-B2C9-7606B66F0124@buechse.de> References: <82C19FE7-DDCB-45B6-B2C9-7606B66F0124@buechse.de> Message-ID: On Mon, 20 Mar 2006, Joachim Buechse wrote: > Ok, what about providing a default implementation in Java? > > The RXTXCommDriver would call a (native) function useNativeLocking and if > it returns true, call the native functions for lock() isLocked(), > unlock(), else is would use the Java based default implementation. This > could possibly be overriden by a property (again for debugging). > Hi Joachim That would be OK with me. -- Trent Jarvi tjarvi at qbang.org From dmarkman at mac.com Mon Mar 20 22:27:45 2006 From: dmarkman at mac.com (Dmitry Markman) Date: Tue, 21 Mar 2006 00:27:45 -0500 Subject: [Rxtx] binaries request Message-ID: <42702213-C222-4937-A585-7CFB17E47608@mac.com> Hi can somebody send me latest linux and windows binaries, please? or where I can find them (I didn't find them in the latest tareball) I gave up with my cygwin: something wrong I have no idea what java doesn't understand /cygwin/c syntax after I changed makefile it did java part but after that gcc 3.4.4 started to complain I set buffer length to 999 lines but I didn't get beginning of the story something wrong with my 1.4.2_09/include/jni.h gcc doesn't like it anyway I gave up thanks in advance Dmitry Markman -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060320/f8cbc57c/attachment-0028.html From tjarvi at qbang.org Mon Mar 20 22:36:48 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 20 Mar 2006 22:36:48 -0700 (MST) Subject: [Rxtx] binaries request In-Reply-To: <42702213-C222-4937-A585-7CFB17E47608@mac.com> References: <42702213-C222-4937-A585-7CFB17E47608@mac.com> Message-ID: On Tue, 21 Mar 2006, Dmitry Markman wrote: > Hi > can somebody send me latest linux and windows binaries, please? > > or where I can find them (I didn't find them in the latest tareball) > > I gave up with my cygwin: something wrong I have no idea what > java doesn't understand /cygwin/c syntax > after I changed makefile it did java part > but after that gcc 3.4.4 started to complain > I set buffer length to 999 lines but I didn't get beginning of the story > something wrong with my 1.4.2_09/include/jni.h gcc doesn't like it > anyway I gave up > > thanks in advance > Hi Dmitry The bins are here: ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7-bins-r2.zip Here are the files in the zip you want. Jar: rxtx-2.1-7-bins-r2/RXTXcomm.jar Windows: rxtx-2.1-7-bins-r2/Windows/i368-mingw32/rxtxSerial.dll Linux (x86) rxtx-2.1-7-bins-r2/Linux/i686-unknown-linux-gnu/librxtxSerial.so There are others in there including Parallel port support but those are the main ones for testing. -- Trent Jarvi tjarvi at qbang.org From dmarkman at mac.com Mon Mar 20 23:05:59 2006 From: dmarkman at mac.com (Dmitry Markman) Date: Tue, 21 Mar 2006 01:05:59 -0500 Subject: [Rxtx] binaries request In-Reply-To: References: <42702213-C222-4937-A585-7CFB17E47608@mac.com> Message-ID: thank you very much but windows's readme says: rxtxSerial.dll had to be recomopiled to link in missing native methods. should I ignore it? or what? thanks again also I understand that I should use mingw not cygwin I'll try to install mingw On Mar 21, 2006, at 12:36 AM, Trent Jarvi wrote: > On Tue, 21 Mar 2006, Dmitry Markman wrote: > >> Hi >> can somebody send me latest linux and windows binaries, please? >> >> or where I can find them (I didn't find them in the latest tareball) >> >> I gave up with my cygwin: something wrong I have no idea what >> java doesn't understand /cygwin/c syntax >> after I changed makefile it did java part >> but after that gcc 3.4.4 started to complain >> I set buffer length to 999 lines but I didn't get beginning of the >> story >> something wrong with my 1.4.2_09/include/jni.h gcc doesn't like it >> anyway I gave up >> >> thanks in advance >> > > Hi Dmitry > > The bins are here: > > ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7-bins-r2.zip > > Here are the files in the zip you want. > > Jar: > > rxtx-2.1-7-bins-r2/RXTXcomm.jar > > Windows: > > rxtx-2.1-7-bins-r2/Windows/i368-mingw32/rxtxSerial.dll > > Linux (x86) > > rxtx-2.1-7-bins-r2/Linux/i686-unknown-linux-gnu/librxtxSerial.so > > There are others in there including Parallel port support but those > are the main ones for testing. > > -- > Trent Jarvi > tjarvi at qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx Dmitry Markman From tjarvi at qbang.org Mon Mar 20 23:20:33 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 20 Mar 2006 23:20:33 -0700 (MST) Subject: [Rxtx] binaries request In-Reply-To: References: <42702213-C222-4937-A585-7CFB17E47608@mac.com> Message-ID: On Tue, 21 Mar 2006, Dmitry Markman wrote: > thank you very much > > but windows's readme says: > rxtxSerial.dll had to be recomopiled to link in missing native methods. > > should I ignore it? or what? > Hi Dmitry That dll should be OK. r2 is the recompile linked to the missing native method. The readme explains why it was recompiled; fuser.o was not linked into the dll in the first release. -- Trent Jarvi tjarvi at qbang.org From ariantristan at yahoo.com Mon Mar 20 23:55:24 2006 From: ariantristan at yahoo.com (Lambok Sianturi) Date: Mon, 20 Mar 2006 22:55:24 -0800 (PST) Subject: [Rxtx] jvm issue Message-ID: <20060321065524.94779.qmail@web50701.mail.yahoo.com> Hi All, This is my first time to join RxTx mailing list. I thank you all for allowing others to sign in in requests help. I use the latest RxTx lib in Fedora 3 with java version 1.4.2_09 b05. And I got this error: # # An unexpected error has been detected by HotSpot Virtual Machine: # # SIGSEGV (0xb) at pc=0x00bf27f3, pid=2633, tid=3086112448 # # Java VM: Java HotSpot(TM) Client VM (1.4.2_09-b05 mixed mode) # Problematic frame: # C [ld-linux.so.2+0xa7f3] # # An error report file with more information is saved as hs_err_pid2633.log # # If you would like to submit a bug report, please visit: # http://java.sun.com/webapps/bugreport/crash.jsp # ./run.sh: line 3: 2633 Aborted /usr/local/java/bin/java -Djava.library.path=/usr/local/java/jre/lib/ -Djsmsengine.debug=true -classpath jsmsengine.jar:smsgateway.jar:classes12.jar:RXTXcomm.jar:. com.api.sms.SMSServer What is the jvm depedency for the latest library? Can I use 1.4.2_09 b05? Thanks in advance. Arian --------------------------------- Yahoo! Mail Use Photomail to share photos without annoying attachments. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060320/83d58dd7/attachment-0028.html From f.frumento at ngi.it Tue Mar 21 00:21:47 2006 From: f.frumento at ngi.it (Fabio Frumento) Date: Tue, 21 Mar 2006 08:21:47 +0100 Subject: [Rxtx] Javadoc on the go Message-ID: <441FA98B.9050701@ngi.it> Hi Trent, sorry for the big delay but my job is running wild, i was out for some time but now i'm back and ready to continue the javadoc for Rxtx. Did you used the last javadoc patch i sent you ? let me know if i have to send it to you again or not. regards Fabio From lyon at docjava.com Tue Mar 21 00:51:18 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Tue, 21 Mar 2006 02:51:18 -0500 Subject: [Rxtx] lock files Message-ID: Hi All, You know, if the use of lock files were under Java control (rather than a build-time decision), it might enable a more unified binary distro. It might also facilitate quick prototyping of non-lock file approaches to resolving serial port contention issues (i.e., mac-like approaches vs. linux approaches, etc.). I realize that this is a radical overhaul of the lock file policy issue. Also, it may harm performance. On the other hand, our benchmarks on JNI overhead for modern processors indicate performance impact should be minimal. Perhaps it is more of an issue with the toybox systems. Suppose there were a class with a reasonable default...someone might write: SerialPortLockPolicy.setPolicy(SerialPortLockPolicy.UNIX_LOCK_FILE); SerialPortLockPolicy.setPolicy(SerialPortLockPolicy.NO_LOCK_CHECKING); SerialPortLockPolicy.setPolicy(SerialPortLockPolicy.MAC_STYLE); Thus, we could have a run-time reconfiguration of the serial port lock policy. A special NO_LOCK version of the binary would no longer be required. Any thoughts on this? Thanks! - Doug From joachim at buechse.de Tue Mar 21 03:09:09 2006 From: joachim at buechse.de (Joachim Buechse) Date: Tue, 21 Mar 2006 11:09:09 +0100 Subject: [Rxtx] lock files In-Reply-To: References: Message-ID: <8E12916A-1B9A-4FF2-B684-E2D1C794221B@buechse.de> This is pretty much what I thought about when I suggested, that the default behaviour could be overwritten with a property. I am very much in favor of this approach. In particular this allows much easier debugging for PC based java developers. I think big parts of the Java (and maybe some parts of the C code) could use a bit of a structural workover (unit tests, javadoc, synchronization, etc). Maybe there should be a CVS branch for this experimental version. I'd be happy to contribute a first workover for some of the Java code. Designing for testability and implementing a good bunch of unit tests has been a strategy that worked quite well in the Java projects I lead. And it ultimately allows more liberal change permission. Regards, Joachim On 21.03.2006, at 08:51, Dr. Douglas Lyon wrote: > Hi All, > You know, if the use of lock files were > under Java control (rather than a build-time decision), > it might enable a more unified binary distro. It might also > facilitate quick prototyping of non-lock file approaches > to resolving serial port contention issues (i.e., mac-like > approaches vs. linux approaches, etc.). > > I realize that this is a radical overhaul of the lock file policy > issue. Also, it may harm performance. On the other hand, > our benchmarks on JNI overhead for modern processors indicate > performance impact should be minimal. Perhaps it is more of > an issue with the toybox systems. > > Suppose there were a class with a reasonable default...someone > might write: > SerialPortLockPolicy.setPolicy(SerialPortLockPolicy.UNIX_LOCK_FILE); > SerialPortLockPolicy.setPolicy(SerialPortLockPolicy.NO_LOCK_CHECKING); > SerialPortLockPolicy.setPolicy(SerialPortLockPolicy.MAC_STYLE); > > Thus, we could have a run-time reconfiguration of the serial port lock > policy. A special NO_LOCK version of the binary would no longer > be required. > > Any thoughts on this? > > Thanks! > - Doug > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From joachim at buechse.de Tue Mar 21 06:23:08 2006 From: joachim at buechse.de (Joachim Buechse) Date: Tue, 21 Mar 2006 14:23:08 +0100 Subject: [Rxtx] PATCH: use of ioctl(fd, TIOCEXCL) instead of lockfiles Message-ID: <923AE774-EEA2-4911-92D8-32BB27802C8B@buechse.de> Here is the patch for the ioctl(fd, TIOCEXCL). I have verified this only for OSX 10.4.5, hence it is only defined for APPLE. However, it should work at least for Solaris as well. If a process has requested TIOEXCL further open calls by other user processes will fail. The patch also disables uucp style locking for APPLE. Obviously this is discussable. I think it is the way to go, as it eliminates creating the lock directory which doesnt exist on the standard installation and it eliminates messing with the system group definitions (adding users to group uucp). Regarding the possibility of root processes opening a device which is locked - I consider this a feature not a potential problem. It is highly unlikely, that somebody is crazy enough to run a JavaVM as root (unless he has no other means of getting a restricted IP port opened, ie doesnt understand ipfw). Anyway, even if the process runs as root, it fails when calling ioctl(fd, TIOCEXCL). It could however still open the port to listen for RING events. I.e. a fax server which needs to see incoming calls but otherwise doesnt want to block the port. So the only case where the proposed mechanism fails is, if an incorrectly implemented process running as root conflicts with a user process. I think this can be accepted. Regards, Joachim PS: If this patch is generally accepted, the installer and Mac doku should obviously be changed as well. Index: SerialImp.c =================================================================== RCS file: /usr/local/cvsroot/rxtx-devel/src/SerialImp.c,v retrieving revision 1.46.2.187 diff -u -r1.46.2.187 SerialImp.c --- SerialImp.c 29 Jan 2006 22:19:04 -0000 1.46.2.187 +++ SerialImp.c 21 Mar 2006 12:59:16 -0000 @@ -656,6 +656,25 @@ fd=OPEN (filename, O_RDWR | O_NOCTTY | O_NONBLOCK ); } while (fd < 0 && errno==EINTR); +#ifdef OPEN_EXCL + // Note that open() follows POSIX semantics: multiple open() calls to + // the same file will succeed unless the TIOCEXCL ioctl is issued. + // This will prevent additional opens except by root-owned processes. + // See tty(4) ("man 4 tty") and ioctl(2) ("man 2 ioctl") for details. + + if (fd >= 0 && (ioctl(fd, TIOCEXCL) == -1)) + { + sprintf( message, "open: exclusive access denied for % s\n", + filename ); + report( message ); + report_error( message ); + + close(fd); + goto fail; + } +#endif /* OPEN_EXCL */ + + if( configure_port( fd ) ) goto fail; (*env)->ReleaseStringUTFChars( env, jstr, filename ); sprintf( message, "open: fd returned is %i\n", fd ); Index: SerialImp.h =================================================================== RCS file: /usr/local/cvsroot/rxtx-devel/src/SerialImp.h,v retrieving revision 1.11.2.49 diff -u -r1.11.2.49 SerialImp.h --- SerialImp.h 5 Jul 2005 17:47:21 -0000 1.11.2.49 +++ SerialImp.h 21 Mar 2006 12:59:17 -0000 @@ -135,7 +135,8 @@ /*# define LOCKDIR "/var/spool/uucp"*/ # define LOCKDIR "/var/lock" # define LOCKFILEPREFIX "LK." -# define UUCP +/*# define UUCP*/ +# define OPEN_EXCL #endif /* __APPLE__ */ #if defined(__NetBSD__) # define DEVICEDIR "/dev/" From tjarvi at qbang.org Tue Mar 21 10:26:08 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 21 Mar 2006 10:26:08 -0700 (MST) Subject: [Rxtx] Javadoc on the go In-Reply-To: <441FA98B.9050701@ngi.it> References: <441FA98B.9050701@ngi.it> Message-ID: On Tue, 21 Mar 2006, Fabio Frumento wrote: > Hi Trent, > > sorry for the big delay but my job is running wild, i was out for some > time but now i'm back and ready to continue the javadoc for Rxtx. > > Did you used the last javadoc patch i sent you ? let me know if i have to > send it to you again or not. > > regards > > Fabio Hi Fabio The patch is in the rxtx mail-list archives. It will be going in soon. I did not see a time critical portion. I'll probably be going through the list since the last batch of patches this weekend and putting them into CVS. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Tue Mar 21 10:57:18 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 21 Mar 2006 10:57:18 -0700 (MST) Subject: [Rxtx] jvm issue In-Reply-To: <20060321065524.94779.qmail@web50701.mail.yahoo.com> References: <20060321065524.94779.qmail@web50701.mail.yahoo.com> Message-ID: On Mon, 20 Mar 2006, Lambok Sianturi wrote: > Hi All, > This is my first time to join RxTx mailing list. I thank you all for allowing others to sign in in requests help. > I use the latest RxTx lib in Fedora 3 with java version 1.4.2_09 b05. And I got this error: > > # > # An unexpected error has been detected by HotSpot Virtual Machine: > # > # SIGSEGV (0xb) at pc=0x00bf27f3, pid=2633, tid=3086112448 > # > # Java VM: Java HotSpot(TM) Client VM (1.4.2_09-b05 mixed mode) > # Problematic frame: > # C [ld-linux.so.2+0xa7f3] A native library loading error? What happens if you recompile rxtx on your system and install that? This sounds like an ABI problem? rxtx 2.1-7 was compiled with a gcc 2.96 toolchain as I recall. The hope is newer system will be backwards compatible. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Tue Mar 21 11:05:29 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 21 Mar 2006 11:05:29 -0700 (MST) Subject: [Rxtx] PATCH: use of ioctl(fd, TIOCEXCL) instead of lockfiles In-Reply-To: <923AE774-EEA2-4911-92D8-32BB27802C8B@buechse.de> References: <923AE774-EEA2-4911-92D8-32BB27802C8B@buechse.de> Message-ID: On Tue, 21 Mar 2006, Joachim Buechse wrote: > Here is the patch for the ioctl(fd, TIOCEXCL). I have verified this only > for OSX 10.4.5, hence it is only defined for APPLE. However, it should > work at least for Solaris as well. > > If a process has requested TIOEXCL further open calls by other user > processes will fail. > > The patch also disables uucp style locking for APPLE. Obviously this is > discussable. I think it is the way to go, as it eliminates creating the > lock directory which doesnt exist on the standard installation and it > eliminates messing with the system group definitions (adding users to > group uucp). > > Regarding the possibility of root processes opening a device which is > locked - I consider this a feature not a potential problem. It is highly > unlikely, that somebody is crazy enough to run a JavaVM as root (unless > he has no other means of getting a restricted IP port opened, ie doesnt > understand ipfw). Anyway, even if the process runs as root, it fails when > calling ioctl(fd, TIOCEXCL). It could however still open the port to > listen for RING events. I.e. a fax server which needs to see incoming > calls but otherwise doesnt want to block the port. So the only case where > the proposed mechanism fails is, if an incorrectly implemented process > running as root conflicts with a user process. I think this can be > accepted. > > Regards, > Joachim > > PS: If this patch is generally accepted, the installer and Mac doku > should obviously be changed as well. > > > Index: SerialImp.c > =================================================================== > RCS file: /usr/local/cvsroot/rxtx-devel/src/SerialImp.c,v > retrieving revision 1.46.2.187 > diff -u -r1.46.2.187 SerialImp.c > --- SerialImp.c 29 Jan 2006 22:19:04 -0000 1.46.2.187 > +++ SerialImp.c 21 Mar 2006 12:59:16 -0000 > @@ -656,6 +656,25 @@ > fd=OPEN (filename, O_RDWR | O_NOCTTY | O_NONBLOCK ); > } while (fd < 0 && errno==EINTR); > > +#ifdef OPEN_EXCL > + // Note that open() follows POSIX semantics: multiple open() > calls to > + // the same file will succeed unless the TIOCEXCL ioctl is > issued. > + // This will prevent additional opens except by root-owned > processes. > + // See tty(4) ("man 4 tty") and ioctl(2) ("man 2 ioctl") for > details. > + > + if (fd >= 0 && (ioctl(fd, TIOCEXCL) == -1)) > + { > + sprintf( message, "open: exclusive access denied for % > s\n", > + filename ); > + report( message ); > + report_error( message ); > + > + close(fd); > + goto fail; > + } > +#endif /* OPEN_EXCL */ > + > + > if( configure_port( fd ) ) goto fail; > (*env)->ReleaseStringUTFChars( env, jstr, filename ); > sprintf( message, "open: fd returned is %i\n", fd ); > Index: SerialImp.h > =================================================================== > RCS file: /usr/local/cvsroot/rxtx-devel/src/SerialImp.h,v > retrieving revision 1.11.2.49 > diff -u -r1.11.2.49 SerialImp.h > --- SerialImp.h 5 Jul 2005 17:47:21 -0000 1.11.2.49 > +++ SerialImp.h 21 Mar 2006 12:59:17 -0000 > @@ -135,7 +135,8 @@ > /*# define LOCKDIR "/var/spool/uucp"*/ > # define LOCKDIR "/var/lock" > # define LOCKFILEPREFIX "LK." > -# define UUCP > +/*# define UUCP*/ > +# define OPEN_EXCL > #endif /* __APPLE__ */ > #if defined(__NetBSD__) > # define DEVICEDIR "/dev/" > This looks like a good start. What do you think Dmitry? Perhaps all systems with TIOCEXCL defined should use that though. Even if they use lockfiles. It wont hurt anything. That would catch people hacking their own serial apps without checking lockfiles. Its a good idea to avoid C++ style comments in the C portions. Some older systems don't deal with them well. If it's just for Mac OS X, it isn't a big deal. I think it was the Irix compiler that was problematic? -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Tue Mar 21 11:22:05 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 21 Mar 2006 11:22:05 -0700 (MST) Subject: [Rxtx] lock files In-Reply-To: <8E12916A-1B9A-4FF2-B684-E2D1C794221B@buechse.de> References: <8E12916A-1B9A-4FF2-B684-E2D1C794221B@buechse.de> Message-ID: We can try it. Maybe the JNI is much improved. The nice thing about linking into liblock is distros then worry about lockfiles on their systems. This way, we have to deal with any changes that may show up. On Tue, 21 Mar 2006, Joachim Buechse wrote: > This is pretty much what I thought about when I suggested, that the > default behaviour could be overwritten with a property. I am very much in > favor of this approach. In particular this allows much easier debugging > for PC based java developers. > > I think big parts of the Java (and maybe some parts of the C code) could > use a bit of a structural workover (unit tests, javadoc, synchronization, > etc). Maybe there should be a CVS branch for this experimental version. > I'd be happy to contribute a first workover for some of the Java code. > Designing for testability and implementing a good bunch of unit tests has > been a strategy that worked quite well in the Java projects I lead. And > it ultimately allows more liberal change permission. > > Regards, > Joachim > > > On 21.03.2006, at 08:51, Dr. Douglas Lyon wrote: > >> Hi All, >> You know, if the use of lock files were >> under Java control (rather than a build-time decision), >> it might enable a more unified binary distro. It might also >> facilitate quick prototyping of non-lock file approaches >> to resolving serial port contention issues (i.e., mac-like >> approaches vs. linux approaches, etc.). >> >> I realize that this is a radical overhaul of the lock file policy >> issue. Also, it may harm performance. On the other hand, >> our benchmarks on JNI overhead for modern processors indicate >> performance impact should be minimal. Perhaps it is more of >> an issue with the toybox systems. >> >> Suppose there were a class with a reasonable default...someone >> might write: >> SerialPortLockPolicy.setPolicy(SerialPortLockPolicy.UNIX_LOCK_FILE); >> SerialPortLockPolicy.setPolicy(SerialPortLockPolicy.NO_LOCK_CHECKING); >> SerialPortLockPolicy.setPolicy(SerialPortLockPolicy.MAC_STYLE); >> >> Thus, we could have a run-time reconfiguration of the serial port lock >> policy. A special NO_LOCK version of the binary would no longer >> be required. >> >> Any thoughts on this? >> >> Thanks! >> - Doug >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From dmarkman at mac.com Tue Mar 21 16:05:17 2006 From: dmarkman at mac.com (Dmitry Markman) Date: Tue, 21 Mar 2006 18:05:17 -0500 Subject: [Rxtx] PATCH: use of ioctl(fd, TIOCEXCL) instead of lockfiles In-Reply-To: References: <923AE774-EEA2-4911-92D8-32BB27802C8B@buechse.de> Message-ID: <512AC70C-BB86-48F2-A83C-023F35C23BAB@mac.com> I think it's cool, but I'd like to have that property implementation when user can choose between locking mechanism about comments: it's easy to change comments to the C style or we can use extensions of the file to cpp so c++ compiler will be used On Mar 21, 2006, at 1:05 PM, Trent Jarvi wrote: > This looks like a good start. What do you think Dmitry? Perhaps > all systems with TIOCEXCL defined should use that though. Even if > they use lockfiles. It wont hurt anything. That would catch > people hacking their own serial apps without checking lockfiles. > > Its a good idea to avoid C++ style comments in the C portions. > Some older systems don't deal with them well. If it's just for Mac > OS X, it isn't a big deal. I think it was the Irix compiler that > was problematic? Dmitry Markman From dmarkman at mac.com Tue Mar 21 16:13:00 2006 From: dmarkman at mac.com (Dmitry Markman) Date: Tue, 21 Mar 2006 18:13:00 -0500 Subject: [Rxtx] PATCH: use of ioctl(fd, TIOCEXCL) instead of lockfiles In-Reply-To: References: <923AE774-EEA2-4911-92D8-32BB27802C8B@buechse.de> Message-ID: I'd like to add that creating locking folder isn't a big deal we never had a problem related to the lock folders, because we always used installer on mac os x from other hand I'm not very much familiar with iotcl locking approach and I'm not sure it's more efficient Joachim wrote "I think it is the way to go, as it eliminates creating the lock directory which doesnt exist on the standard installation and it eliminates messing with the system group definitions (adding users to group uucp)." but I really didn't have any problem with that 1. doesn't exist on the standard installation there are many-many things that don't exist in the standard installation so I don't think that argument is strong enough 2. messing with the system group definitions I don't think we're messing with the group definition mac os x provides very clear way to set up group's members and together with Greg Guerin AuthKit there is no problem to set those definitions so I don't think that argument is strong either but from other hand using iotcl is more promising and is more elegant On Mar 21, 2006, at 1:05 PM, Trent Jarvi wrote: > > This looks like a good start. What do you think Dmitry? Perhaps > all systems with TIOCEXCL defined should use that though. Even if > they use lockfiles. It wont hurt anything. That would catch > people hacking their own serial apps without checking lockfiles. Dmitry Markman From joachim at buechse.de Wed Mar 22 04:46:45 2006 From: joachim at buechse.de (Joachim Buechse) Date: Wed, 22 Mar 2006 12:46:45 +0100 Subject: [Rxtx] PATCH: use of ioctl(fd, TIOCEXCL) instead of lockfiles In-Reply-To: References: <923AE774-EEA2-4911-92D8-32BB27802C8B@buechse.de> Message-ID: Sorry, I was not very clear with my arguments, so I will try again;-) Please, don't take this as an attack against work that has been done. I think the contributions that have been made in the past were made in a good spirit. But I really believe, that the current solution for OSX has many shortcomings and should be changed as soon as possible. lock files --- The /var/lock folder does not exist on the standard OSX installation, however the standard installation includes several applications that use serial ports (i.e. the FAX capability). This indicates, that the lock folder approach will not work well with system components. Applications for OSX will generally try to live in harmony with system components (except for HP print drivers of course). I think RXTX should follow this approach as well. uucp group --- Accessing serial ports is not an admin privileged operation on OSX. Any user (world) has read/write privileges on /dev/tty*. So the system default is to not enforce any group membership to access these ports. The group uucp however is a system group on all unix systems I know. It exists for certain system processes. A non admin user should in general not be a member of this group. Quite arguably no user should ever be a member of this group. Installer --- My general opinion is, that - no Installer should touch user or group data without warning - no Application Installer should touch groups which are not specific to the very application installed - no Installer should ever add regular users to a system group The current installer injects the installing user in the group uucp without warning about this change and without giving the option to "opt out" of this change. This is a potential security risk (but not currently a real one, as OSX contains no folders belonging to group uucp). The current installer does not work for multi user systems. It puts the installing user in the uucp group. However the installing user is not necessarily the user that will use the application. Putting all users that may use a serial port application in the system group uucp seems like a very invasive approach to me. Besides that, newly created users will not automatically be in the group and hence, serial applications will "break" for new users without obvious reasons. Avoiding the lock files will allow self contained applications (i.e. drag&drop installation). In my eyes this is largely preferable over an installer that requests admin privileges. Adding up all these points indicates very strongly, that the lock-file implementation is not the way to go on OSX. Regards, Joachim On 22.03.2006, at 00:13, Dmitry Markman wrote: > I'd like to add that > > creating locking folder isn't a big deal > we never had a problem related to the lock folders, because we > always used installer on mac os x > from other hand I'm not very much familiar with iotcl locking > approach and I'm not sure it's more efficient > > Joachim wrote "I think it is the way to go, as it eliminates > creating the lock directory which doesnt exist on the standard > installation and it eliminates messing with the system group > definitions (adding users to group uucp)." but I really didn't have > any problem with that > > 1. doesn't exist on the standard installation > there are many-many things that don't exist in the standard > installation so I don't think that argument is strong enough > 2. messing with the system group definitions > I don't think we're messing with the group definition > mac os x provides very clear way to set up group's members and > together with Greg Guerin AuthKit there is no problem to set those > definitions > so I don't think that argument is strong either > but from other hand using iotcl is more promising and is more elegant > > > > On Mar 21, 2006, at 1:05 PM, Trent Jarvi wrote: > >> >> This looks like a good start. What do you think Dmitry? Perhaps >> all systems with TIOCEXCL defined should use that though. Even if >> they use lockfiles. It wont hurt anything. That would catch >> people hacking their own serial apps without checking lockfiles. > > Dmitry Markman > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From dmarkman at mac.com Wed Mar 22 05:27:13 2006 From: dmarkman at mac.com (Dmitry Markman) Date: Wed, 22 Mar 2006 07:27:13 -0500 Subject: [Rxtx] PATCH: use of ioctl(fd, TIOCEXCL) instead of lockfiles In-Reply-To: References: <923AE774-EEA2-4911-92D8-32BB27802C8B@buechse.de> Message-ID: <83440CF3-DCD8-41C1-B941-F227232C27E3@mac.com> thanks for the very good explanation I didn't think that you were attacking any thing, so don't worry I just had feeling, that there were more aesthetic reasons for going to ioctl then real necessity now you explained everything quite well (BTW, asfar as I remember installer asks admin password so it wasn't quiet, but it really doesn't matter now) thanks On Mar 22, 2006, at 6:46 AM, Joachim Buechse wrote: > Sorry, I was not very clear with my arguments, so I will try again;-) > > Please, don't take this as an attack against work that has been > done. I think the contributions that have been made in the past > were made in a good spirit. But I really believe, that the current > solution for OSX has many shortcomings and should be changed as > soon as possible. > > lock files > --- > The /var/lock folder does not exist on the standard OSX > installation, however the standard installation includes several > applications that use serial ports (i.e. the FAX capability). This > indicates, that the lock folder approach will not work well with > system components. Applications for OSX will generally try to live > in harmony with system components (except for HP print drivers of > course). I think RXTX should follow this approach as well. > > uucp group > --- > Accessing serial ports is not an admin privileged operation on OSX. > Any user (world) has read/write privileges on /dev/tty*. So the > system default is to not enforce any group membership to access > these ports. The group uucp however is a system group on all unix > systems I know. It exists for certain system processes. A non admin > user should in general not be a member of this group. Quite > arguably no user should ever be a member of this group. > > Installer > --- > My general opinion is, that > - no Installer should touch user or group data without warning > - no Application Installer should touch groups which are not > specific to the very application installed > - no Installer should ever add regular users to a system group > > The current installer injects the installing user in the group uucp > without warning about this change and without giving the option to > "opt out" of this change. This is a potential security risk (but > not currently a real one, as OSX contains no folders belonging to > group uucp). > > The current installer does not work for multi user systems. It puts > the installing user in the uucp group. However the installing user > is not necessarily the user that will use the application. Putting > all users that may use a serial port application in the system > group uucp seems like a very invasive approach to me. Besides that, > newly created users will not automatically be in the group and > hence, serial applications will "break" for new users without > obvious reasons. > > > Avoiding the lock files will allow self contained applications > (i.e. drag&drop installation). In my eyes this is largely > preferable over an installer that requests admin privileges. Adding > up all these points indicates very strongly, that the lock-file > implementation is not the way to go on OSX. > > Regards, > Joachim > > > On 22.03.2006, at 00:13, Dmitry Markman wrote: > >> I'd like to add that >> >> creating locking folder isn't a big deal >> we never had a problem related to the lock folders, because we >> always used installer on mac os x >> from other hand I'm not very much familiar with iotcl locking >> approach and I'm not sure it's more efficient >> >> Joachim wrote "I think it is the way to go, as it eliminates >> creating the lock directory which doesnt exist on the standard >> installation and it eliminates messing with the system group >> definitions (adding users to group uucp)." but I really didn't >> have any problem with that >> >> 1. doesn't exist on the standard installation >> there are many-many things that don't exist in the standard >> installation so I don't think that argument is strong enough >> 2. messing with the system group definitions >> I don't think we're messing with the group definition >> mac os x provides very clear way to set up group's members and >> together with Greg Guerin AuthKit there is no problem to set those >> definitions >> so I don't think that argument is strong either >> but from other hand using iotcl is more promising and is more elegant >> >> >> >> On Mar 21, 2006, at 1:05 PM, Trent Jarvi wrote: >> >>> >>> This looks like a good start. What do you think Dmitry? Perhaps >>> all systems with TIOCEXCL defined should use that though. Even >>> if they use lockfiles. It wont hurt anything. That would catch >>> people hacking their own serial apps without checking lockfiles. >> >> Dmitry Markman >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx Dmitry Markman From lyon at docjava.com Wed Mar 22 06:12:18 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Wed, 22 Mar 2006 08:12:18 -0500 Subject: [Rxtx] sole of a new design pattern Message-ID: Hi All, I have been thinking about how we design the serial port software. I think we need a new design pattern. For lack of a better term, I shall call it: The Parametric Singleton Design Pattern By Douglas A. Lyon ABSTRACT The goal of the singleton design pattern is to make sure that there is one, and only one, instance of a given class. The goal of the parametric singleton design pattern is to make sure that there is one, and only one, instance of a given class with the given parametric values. We parametric singleton design pattern combines the singleton design pattern with a parameter that enables unique creation of instances of a class. These instances are cached. When a user asks for an instance with these parameters, the cache is checked. If the instance is in the cache, the instance is returned, otherwise it is created, added to the cache and then returned. We apply our parametric singleton design pattern to the retrieval of RMI registries bound to a given port. The goal of our system is to make sure that no two RMI registries are listening to the same socket and to make use of the RMI registries after they have been created. RMI registries are used in distributed computation. Introduction The singleton design pattern is meant to ensure that on a single instance of a class exists. It is also meant to provide a global point of access to it. The intent of the parametric singleton design pattern is to ensure that a class has only one instance for a given set of parameter values. It also provides a global point of access to it. Motivation A system cannot tolerate multiple instances of some classes with identical parameters. For example, you cannot have two instances making use of the same serial port, at the same time. You cannot have two instances that are trying to listen to the same socket connection. You cannot have two instances writing to the same file structure at the same time. As the operating system is often thought of as the arbiter of consumed resources (i.e., tape drives, serial ports, etc.) we frequently leave it to an operating system implementation to resolve these contention issues. Even for similar resources (like serial ports) there are few standards for handling contention. For example, serial ports on Linux are locked using a "/var/lock" file. POSIX, on the other hand, uses ioctl mechanisms to prevent contention. A better solution is to make a class that is responsible for keeping track of the instances created from the class. The class is declared final, so that it cannot be subclassed. The class also has a private constructor, so that other classes cannot instance it. The new design pattern is called the parametric singleton design pattern and it provides a way to access and create instances with given parameters. Applicability Use the Parametric Singleton Design Pattern when: 1. There must be exactly one instance of a class with the given parameters. 2. The instances must be accessible to clients from a well-known access point. Structure Insert UML diagram here. Participants The Parametric Singleton Clients that need instances 1. The Parametric Singleton defines an instance upon request from a client, if, and only if, the instance does not already exist. 2. The Parametric Singleton returns the instance to the client. 3. The Parametric Singleton is responsible for creating unique instances from given parameters. Collaborations Clients obtain a reference to a Parametric Singleton instance only through the parametric singleton design pattern. If the instance is left in an improper state (e.g., the serial port was left open) it is NOT the role of the Parametric Singleton Design Pattern to close the IO port. Nor is it the role of the Parametric Singleton Design Pattern to open the port. That role is delegate to some other part of the system. Further, it is not the role of the Parametric Singleton Design Pattern to check out resources. That is, multiple threads can have multiple references to the same resource at the same time. MUTEX locking is delegated to some other part of the system. Consequences The Parametric Singleton Design Pattern has several benefits: 1. Controlled access to parametrically defined instances. Since the Parametric Singleton class encapsulates its instances, there is control over how and when clients access it. 2. Reduced name space. The Parametric Singleton pattern avoids global variables that store instances created from the same parameter. Implementation Here are implementation issues to consider when using the Parametric Singleton pattern: 1. Unique mapping of parameters. The Parametric Singleton pattern requires that there be a mean to isomorphically map the parameter space into the instance space and back again. 2. Ensure unique instances. The Parametric Singleton pattern makes unique instances from parameters, and it does so only once. 3. Cache instances for fast retrieval. The Parametric Singleton pattern must be able to look up instances, given some set of parameters, and do so from some data structure. That is, there must be enough space to hold references to all the instances the program will need. Also, a mechanism is needed to look up and retrieve the instances quickly enough to satisfy the clients. Sample Code public final class ParametricSingletonRmiRegistry { private static Hashtable registry = new Hashtable(100); // use singleton pattern and??????????????????????????????????????????????? // prevent instantiation of RmiRegistryUtils.?????????????????????????????? private ParametricSingletonRmiRegistry() { } // the only instance of the Registry held by the RmiRegistryUtils?????????? public static void listNames(Integer port) { if (!isInCacheAndRunning(port)) return; Registry r = (Registry) registry.get(port); System.out.println("registry on port: " + port); System.out.println("registry: " + r); System.out.println("names: "); try { print(r.list()); } catch (RemoteException e) { In.message(e); } System.out.println("------------------------"); } /**???????????????????????????????????????????????????????????????????????? * Checks whether a Registry has been started on this host????????????????? * in the specified port.?????????????????????????????????????????????????? * If not, it tries to start one.?????????????????????????????????????????? * when it fails to start a Registry, it exits the program????????????????? * with exit code 1.??????????????????????????????????????????????????????? */ public static void restart(int port) { if (isInCacheAndRunning(port)) return; try { startRegistry(port); } catch (RemoteException e) { In.message(e); } } /**???????????????????????????????????????????????????????????????????????? * @param port????????????????????????????????????????????????????????????? * @return true if registry is in cache and running???????????????????????? */ private static boolean isInCacheAndRunning(Integer port) { if (!isRegistryRunning(port.intValue())) return false; if (!isRegistryInCache(port.intValue())) return false; return true; } /**???????????????????????????????????????????????????????????????????????? * @param port????????????????????????????????????????????????????????????? * @return true if we are able to locate a local registry on port.??????????????????????????????????????????????????????????????????????????? */ private static boolean isRegistryRunning(int port) { try { Registry r = LocateRegistry.getRegistry(port); if (r != null) return true; } catch (RemoteException e) { return false; } return false; } /**???????????????????????????????????????????????????????????????????????? * @param port????????????????????????????????????????????????????????????? * @return return true if registry is in cache????????????????????????????? */ private static boolean isRegistryInCache(int port) { if (registry.get(new Integer(port)) == null) return false; return true; } /**???????????????????????????????????????????????????????????????????????? * Restart the registry, if needed.???????????????????????????????????????? * Return the only instance of the registry for consistent global?????????? * using by making use of the Singleton Design Pattern????????????????????? *????????????????????????????????????????????????????????????????????????? * @return the internally held registry instance.?????????????????????????? */ public static Registry getRegistry(Integer port) { restart(port); return (Registry) registry.get(port); } private static void startRegistry(Integer port) throws RemoteException { Registry r; try { r = LocateRegistry.createRegistry(port.intValue()); registry.put(port, r); //r = new sun.rmi.registry.RegistryImpl???????????????????????????? /// (port.intValue());?????????????????????????????????????? // registry.put(port, r);?????????????????????????????????????????? } catch (Exception e) { //e.printStackTrace();????????????????????????????????????????????? r = LocateRegistry.getRegistry(port.intValue()); registry.put(port, r); } } public static void main(String args[]) throws RemoteException { //restart(port);??????????????????????????????????????????????????????? restart(5001); restart(5002); restart(5002); Registry r = LocateRegistry.getRegistry(5002); System.out.println("registry="+r); } } I would very much like to get your feedback on this new design pattern idea. Thank you for your time. Regards, - Doug From david.garnier at trusted-logic.com Wed Mar 22 07:36:10 2006 From: david.garnier at trusted-logic.com (David Garnier) Date: Wed, 22 Mar 2006 15:36:10 +0100 Subject: [Rxtx] sole of a new design pattern In-Reply-To: References: Message-ID: <442160DA.80107@trusted-logic.com> Hello, > The Parametric Singleton Design Pattern The Singleton is the most abused design pattern ever. Good use-cases for this pattern are extremely rare and mostly confined to problems related to hardware resources, like serial ports. > Applicability > > Use the Parametric Singleton Design Pattern when: > 1. There must be exactly one instance of a class with the given > parameters. OK. As I said above, this case this actually very unusual. The Singleton pattern is mostly used when : > 2. The instances must be accessible to clients from a well-known > access point. Using the singleton pattern in this case is just convenient for the programmer. Problems arises pretty quickly, especially if you attempt to unit-test your classes. 1) If your singleton is stateful, or hold on to stateful objects, it means that two different unit tests are not actually independent. Instead of starting with a brand new environment, the result of a test may be affected by the result of a previous test. This problem also arise when with your class relies on a database. In both cases, the solution is to reset your "unique" resource (Singleton or database) at the beginning of the test, which is a pain. Also, while most projects connect to a single database, projects that allow the use of Singletons usually contain several of thems, and new ones may cropped up unnoticed. You quickly end up with test cases that only pass in a certain order, which is a royal pain. 2) You cannot mockup a singleton. Once everyone calls the SomeSingleton class statically, you can't replace your class by SomeSingletonMockup. Furthermore, even for hardware services, the Singleton pattern does not really prevent concurrent accesses. If you start the same program in two different JVMs, unless they somehow shared the state of their "Singletons" (through lock files for example), the Singleton pattern will not prevent concurrent access. Our application uses RXTX, and we routinely encounter cases where another (native) application has already locked the port. Since we cannot modify the native application to recognize lock files, OS-level control is irreplaceable. > > Consequences > The Parametric Singleton Design Pattern has several benefits: > > 1. Controlled access to parametrically defined instances. Since > the Parametric Singleton class encapsulates its instances, there is > control over how and when clients access it. Not really. Once you've returned the instance to a client, you've lost control over it. The client can to whatever it wants with it. You cannot "recall" the instance or claim it back. > 2. Reduced name space. The Parametric Singleton pattern avoids > global variables that store instances created from the same parameter. Sure, but you don't have to rely on a Singleton for that. Just create a single Factory. > I would very much like to get your feedback on this new design > pattern idea. Well, it's nothing new. Some may say that it is the point of design patterns: formalizes the designs that occur again and again. However, this design is simply a combination of the Singleton and Factory patterns. I did use it in the past, but now I've been exposed to the shortcomings of the Singleton pattern, so I limit myself to Factories. Regards, David From sean_montgomery at baseview.com Wed Mar 22 08:35:28 2006 From: sean_montgomery at baseview.com (Sean Montgomery) Date: Wed, 22 Mar 2006 10:35:28 -0500 Subject: [Rxtx] sole of a new design pattern In-Reply-To: <442160DA.80107@trusted-logic.com> References: <442160DA.80107@trusted-logic.com> Message-ID: <05769CA7-A51B-4CF0-BAA0-E02DD905F5A4@baseview.com> On Mar 22, 2006, at 9:36 AM, David Garnier wrote: > Furthermore, even for hardware services, the Singleton pattern does > not really prevent concurrent > accesses. If you start the same program in two different JVMs, > unless they somehow shared the state > of their "Singletons" (through lock files for example), the > Singleton pattern will not prevent > concurrent access. > Multiple class loaders in a single JVM can be tricky, too. Then there's synchronization, lazy initialization and serialization of singletons to contend with. Bloch's Effective Java covers these, and here's a few articles: http://www.javaworld.com/javaworld/jw-04-2003/jw-0425-designpatterns- p3.html http://java.sun.com/developer/technicalArticles/Programming/singletons/ Just FYI :-) From lyon at docjava.com Wed Mar 22 08:50:48 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Wed, 22 Mar 2006 10:50:48 -0500 Subject: [Rxtx] sole of a new design pattern In-Reply-To: <442160DA.80107@trusted-logic.com> References: <442160DA.80107@trusted-logic.com> Message-ID: Hi All, First, I would like to thank David for his prompt and thoughtful remarks. I had no idea people that feel strongly about a design patterns! Wow! Feedback (particularly critical feedback) is greatly appreciated. Starting at the end, first: >I did use it in >the past, but now I've been exposed to the shortcomings of the >Singleton pattern, so I limit myself to Factories. David, if I understood your comments correctly, you suggested that Factories can be used in leu of the Singleton Design Pattern, or even the Parametric Singleton Design Pattern. As I see in [Gof]: Factory Method: Intent "Define an interface for creating an object, but let subclasses decide which class to instantiate. Factory Method lets a class defer instantiation to subclasses." The Singleton Design Pattern is a concrete class, which is rather different, right? Also, subclasses are not permitted with Singleton, as they are final. Naturally, I could use an abstract factory as a parent for a singleton. I could even design a facade that could be implemented with the singleton....but that is not the intention of the design. Unless you want a mock-up, as discussed, below: More below: >Hello, > >> The Parametric Singleton Design Pattern > >The Singleton is the most abused design pattern ever. Good use-cases >for this pattern are extremely >rare and mostly confined to problems related to hardware resources, >like serial ports. > > >> Applicability >> >> Use the Parametric Singleton Design Pattern when: >> 1. There must be exactly one instance of a class with the given >> parameters. >OK. As I said above, this case this actually very unusual. The >Singleton pattern is mostly used when : >> 2. The instances must be accessible to clients from a well-known >> access point. > >Using the singleton pattern in this case is just convenient for the >programmer. Problems arises >pretty quickly, especially if you attempt to unit-test your classes. > >1) If your singleton is stateful, or hold on to stateful objects, it >means that two different unit >tests are not actually independent. Instead of starting with a brand >new environment, the result of >a test may be affected by the result of a previous test. This >problem also arise when with your >class relies on a database. In both cases, the solution is to reset >your "unique" resource >(Singleton or database) at the beginning of the test, which is a >pain. Also, while most projects >connect to a single database, projects that allow the use of >Singletons usually contain several of >thems, and new ones may cropped up unnoticed. You quickly end up >with test cases that only pass in a >certain order, which is a royal pain. There are basic problems with communicating finite state machines that include reachability and deadlock analysis. These are addressed with petri net analysis and are beyond the scope of the design pattern. As you quite rightly pointed out; the parametric singleton pattern (or the singleton pattern, for that matter) enable multiple threads to gain access to the same instance. The only way that I can see to block others from gaining access to the reference is the synchronize keyword. This is putting a spin-lock (or MUTEX) on the reference. The question of how to unit-test a design pattern like the parametric singleton remains open. Perhaps this is a deficiency. > >2) You cannot mockup a singleton. Once everyone calls the >SomeSingleton class statically, you can't >replace your class by SomeSingletonMockup. Acutally, I am not sure that this is true. If the Singleton implements a Facade interface, it should be possible to make the replacement. Right? > >Furthermore, even for hardware services, the Singleton pattern does >not really prevent concurrent >accesses. If you start the same program in two different JVMs, >unless they somehow shared the state >of their "Singletons" (through lock files for example), the >Singleton pattern will not prevent >concurrent access. Good Point!! You have sharp eyes! The singleton design pattern should/could take responsibility for this. In fact, you may notice that my code does have an implementation (LocateRegistry) that can work across JVM's. The LocateRegistry will even work across the Internet! LocateRegistry takes both a host name and a Port (lock files just don't do this). I did not think to implement this beyond the local machine, but, in its present form, it will work across different processes. > >Our application uses RXTX, and we routinely encounter cases where >another (native) application has >already locked the port. Since we cannot modify the native >application to recognize lock files, >OS-level control is irreplaceable. The singleton design pattern is not meant to replace OS-level control, but to centralize the Java programmers access to it. If lock files, for example, are used for serial ports, the Singleton Design Pattern should be able to work with them. > > >> >> Consequences >> The Parametric Singleton Design Pattern has several benefits: >> > > 1. Controlled access to parametrically defined instances. Since >> the Parametric Singleton class encapsulates its instances, there is >> control over how and when clients access it. > >Not really. Once you've returned the instance to a client, you've >lost control over it. The client >can to whatever it wants with it. You cannot "recall" the instance >or claim it back. Good point, this should read: > 1. Controll when parametrically defined instances are created. Since > > the Parametric Singleton class encapsulates its instances, there is > > control over how and when they are instanced. > >> 2. Reduced name space. The Parametric Singleton pattern avoids >> global variables that store instances created from the same parameter. > >Sure, but you don't have to rely on a Singleton for that. Just >create a single Factory. > > Thank you for your thoughtful and prompt response! Regards, - Doug From dmarkman at mac.com Wed Mar 22 21:21:55 2006 From: dmarkman at mac.com (Dmitry Markman) Date: Wed, 22 Mar 2006 23:21:55 -0500 Subject: [Rxtx] sole of a new design pattern In-Reply-To: <442160DA.80107@trusted-logic.com> References: <442160DA.80107@trusted-logic.com> Message-ID: I don't think I get it On Mar 22, 2006, at 9:36 AM, David Garnier wrote: > Using the singleton pattern in this case is just convenient for the > programmer. Problems arises > pretty quickly, especially if you attempt to unit-test your classes. so you're saying that something isn't so good because you can not test it in the convenient way? if that's true, I'm totally disagree change your test, debug whatever, but if software is efficient at runtime, works fine and only problem is some unit test (which is some kind of framework for testing) then dump that unit test , dump that unit framework and make something appropriate to the software you're testing so if Douglas want to use singletons, what's the problem? and what do you mean by abusing of singleton usage? of course singleton doesn't prevent concurrent access to the resource across the processes unless you're using some OS facility to prevent it, besides singleton as it was introduced is relevant only and only inside of the same process otherwise it's not singleton it's something else (let's say network singleton: so you have remote invocation facility and some factory method that return object created by that facility) I don't have any problem with using any kind of singletons. Parametric Singleton idea (if I understand it right) could be easily implemented in the following way: use a map populate map with instances of some class and key is your parameter (you can use lazy population too) if somebody ask the key check the value if it's null so resource is taken if somebody returns the resource put it back to the map public synchronized static Object getSomeResource(Object parameter); public synchronized static void returnResource(Object parameter); getSomeResource (inside of the same process) could return null in 2 cases 1. if somebody (from other thread for example) already took that resource 2. if OS API said that resource corresponded to that parameter (serial port with parameter = 1 (port #)) is locked and unavailable; I'm not sure that in case of serial ports we even need those Parametric Singletons (unless lock checking is a very expensive operation) just ask the OS about availability of that resource and if it's available give it away and then OS will lock it and therefore in next time somebody ask it just answer that resource is locked and return null for example system has 2 serial ports available so I ask getResource("tty"); or I ask getResource("Bluetooth-Modem"); and if OS is ok you can give tty or Bluetooth-Modem or both no need for any additional pattern I think back to the problem mac os x doesn't recognize locking via files, so it handles locking via some API an instance of the singleton in each process should recognize that resource is locked (by using that API) that's all we don't have to make things more complicate then they are just because there is some nice design pattern or nice unit test framework or whatever keep things simple, make them work fast, don't introduce middle layers unless you have really good reason to do so of course I could be entirely wrong, so sorry about that in advance thanks Dmitry Markman From tjarvi at qbang.org Wed Mar 22 22:31:41 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 22 Mar 2006 22:31:41 -0700 (MST) Subject: [Rxtx] sole of a new design pattern In-Reply-To: References: Message-ID: Hi Doug Interesting reading. So far I'm just reading and thinking. I have one question so far. " Clients obtain a reference to a Parametric Singleton instance only through the parametric singleton design pattern. If the instance is left in an improper state (e.g., the serial port was left open) it is NOT the role of the Parametric Singleton Design Pattern to close the IO port. Nor is it the role of the Parametric Singleton Design Pattern to open the port. That role is delegate to some other part of the system. " So when the clients obtain a reference to the singleton, can they assume the port is there? IE, would it be the singletons role to handle things like USB dongles being removed with event hints comming from the underlying OS. Hardware abstraction layer/HAL on Linux is an example of underlying OS events. I assume that role too is delegated to other parts of the system? -- Trent Jarvi tjarvi at qbang.org From lyon at docjava.com Thu Mar 23 08:10:33 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Thu, 23 Mar 2006 10:10:33 -0500 Subject: [Rxtx] Classes don't need goals, they need roles! In-Reply-To: References: Message-ID: Hi Trent, Yes, I think that the role of the Parametric Singleton Pattern is not to open or close serial ports, nor is it to perform error checking. On the other hand, if you were to combine the role of the Parametric Singleton Pattern with another role (like that of error checking) it might not be amiss. However, I generally caution programmers against adding multiple roles to classes, as this leads to monolithic designs. Thus a different class (NativeLibDetect) could have the role of determining if the native library can be loaded. Another class (SerialPortBean) can have the role of serializing the default state of the serial port, so that it can be recovered, from user preferences, at a later time. The SerialPortDetect could have the role of determining if the serial port is removed (i.e., a USB port was unplugged). My guess is that each class should have a different role in the system, in order to ease maintenance and testing...but I could be wrong about that. Thanks! - Doug >Hi Doug > >Interesting reading. So far I'm just reading and thinking. I have >one question so far. > >" > Clients obtain a reference to a Parametric Singleton instance only >through the parametric singleton design pattern. If the instance is >left in an improper state (e.g., the serial port was left open) it is >NOT the role of the Parametric Singleton Design Pattern to close the >IO port. Nor is it the role of the Parametric Singleton Design Pattern >to >open the port. That role is delegate to some other part of the system. >" > >So when the clients obtain a reference to the singleton, can they >assume the port is there? IE, would it be the singletons role to >handle things like USB dongles being removed with event hints >comming from the underlying OS. Hardware abstraction layer/HAL on >Linux is an example of underlying OS events. > >I assume that role too is delegated to other parts of the system? > >-- >Trent Jarvi >tjarvi at qbang.org >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From maximulo at yahoo.com Fri Mar 24 01:22:38 2006 From: maximulo at yahoo.com (Maximulo Majir) Date: Fri, 24 Mar 2006 00:22:38 -0800 (PST) Subject: [Rxtx] JavaPOS Message-ID: <20060324082238.66371.qmail@web38214.mail.mud.yahoo.com> Hi all! Hello Trent! From what i understand, RXTX or JavaComm APIs were not created solely for JavaPOS. In JavaPOS, we have the virtual method claim() which is separate from open(), but in our RXTX API, claiming is done every call to open(), we cant open the port if its claimed by another application. Would it be alright to suggest or ask to create a new method called claim(..)? Is there such thing as forceclaim() in RXTX? this could be the same as portownership transfer or its equivalent. ForceClaim is in JSR80. Do you have some samples using RXTX as the lower layer for the Device Service Objects in JavaPOS? I have tried it, i just want to compare. Thank you all! maxim __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060324/496adba2/attachment-0028.html From tjarvi at qbang.org Fri Mar 24 11:28:19 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 24 Mar 2006 11:28:19 -0700 (MST) Subject: [Rxtx] Re: RXTX 2.1 Solaris Problems In-Reply-To: <3691.1143210578@www045.gmx.net> References: <3691.1143210578@www045.gmx.net> Message-ID: On Fri, 24 Mar 2006, Andreas Guenther wrote: > Hi all, > > the solaris problem was not the lock file only. > > Ok, I had to create the directory /var/spool/locks myself. > /var/spool/uucp exists. > > But rxtx didn't find any port. > > I compiled the source with my own debug-informations > and I tried to isolate the problem. > > The problem is the testRead-call in SerialImp.c > > JNIEXPORT jboolean JNICALL RXTXCommDriver(testRead)( > > ... > if ( READ( fd, &c, 1 ) < 0 ) > { > if ( errno != EAGAIN ) { > report( "testRead() read failed\n" ); > ret = JNI_FALSE; > } > } > Thanks Andreas I'm packing up to move. I'll be more or less away for a couple weeks here. I'll be checking email but my workstation is going into a box soon. This isn't hard to fix as this port should be enumerated when EWOULDBLOCK is recieved. Thats error is OK for enumeration just as EAGAIN is. I've put the bug into bugzilla so we dont forget to get to it. http://bugzilla.qbang.org/show_bug.cgi?id=42 You can add yourself to the CC list if you wish to test fixes we provide or even put a patch into bugzilla yourself. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Fri Mar 24 11:51:52 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 24 Mar 2006 11:51:52 -0700 (MST) Subject: [Rxtx] JavaPOS In-Reply-To: <20060324082238.66371.qmail@web38214.mail.mud.yahoo.com> References: <20060324082238.66371.qmail@web38214.mail.mud.yahoo.com> Message-ID: On Fri, 24 Mar 2006, Maximulo Majir wrote: > Hi all! Hello Trent! > > > From what i understand, RXTX or JavaComm APIs were not > created solely for JavaPOS. In JavaPOS, we have the virtual method > claim() which is separate from open(), but in our RXTX API, claiming is > done every call to open(), we cant open the port if its claimed by > another application. Would it be alright to suggest or ask to create a > new method called claim(..)? Is there such thing as forceclaim() in > RXTX? this could be the same as portownership transfer or its > equivalent. ForceClaim is in JSR80. > Do you have some samples using RXTX as the lower layer for the Device > Service Objects in JavaPOS? I have tried it, i just want to compare. > maxim Hi Maxim JSR80 is the USB API IBM/Sun put together. The problem is they have a richer kernel/API underneath that can handle such things. With Serial Ports, there isnt anything there other than an ioctl that says don't let anyone touch this and lockfiles that are more of a 'lets be nice.' At times we may be using USB ports but it is through the termios layer with the limitations mentioned. The advantage is that not only USB will work with rxtx. Anything that has a termios layer should work (to the extent that termios layer is complete). I don't know how forceclaim() would help you. Lets say someone has a programmer working on /dev/ttyS0 and you take it. Now you both race each other to read data first. There isn't a mechanism I know of that will solve this problem in termios. The most obvious test being a native app and a Java app trying to take the port. There is the potential of requestion ownership from other Java Applications but the use for that is very rare. Did you have something more specific in mind that I'm missing? I'm not sure that claim() and forceclaim() would help you with rxtx other than maybe locking the port with claim() without opening it. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sat Mar 25 23:42:08 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 25 Mar 2006 23:42:08 -0700 (MST) Subject: [Rxtx] Serial snoop Message-ID: I was reading the Linux kernel mail-list tonight and ran past a thread that mentioned sersnoop. This looks like a handy tool for people dealing with new toys. "a simple command-line tool for linux that echoes bytes to and from any two serial ports, ptys, or network sockets, and prints all traffic to stdout, in hex and ascii." http://www.restivo.org/projects/sersnoop/ It works on Linux only at this time (debian package available). -- Trent Jarvi tjarvi at qbang.org From beat.arnet at gmail.com Sun Mar 26 07:32:35 2006 From: beat.arnet at gmail.com (Beat Arnet) Date: Sun, 26 Mar 2006 09:32:35 -0500 Subject: [Rxtx] Error 0x5 at /home/bob/foo/tar/rxtx-2.1-7/build/../src/termios.c(860): Access is, denied. Message-ID: <4426A603.80508@gmail.com> Dear all, When trying to open the serial port, I sometimes (not always) run into the following exception (when opening the serialPort): Error 0x5 at /home/bob/foo/tar/rxtx-2.1-7/build/../src/termios.c(860): Access is denied. java.lang.UnsatisfiedLinkError: native_psmisc_report_owner at gnu.io.CommPortIdentifier.native_psmisc_report_owner(Native Method) at gnu.io.CommPortIdentifier.open(CommPortIdentifier.java:354) at codeskin.tools.CLLoader.open(CLLoader.java:79) at codeskin.tools.C2000Programmer.run(C2000Programmer.java:220) at java.lang.Thread.run(Unknown Source) Is this the type of error where I should just try to open the port again, or can it be avoided? Regards, Beat From tjarvi at qbang.org Sun Mar 26 11:40:12 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 26 Mar 2006 11:40:12 -0700 (MST) Subject: [Rxtx] Error 0x5 at /home/bob/foo/tar/rxtx-2.1-7/build/../src/termios.c(860): Access is, denied. In-Reply-To: <4426A603.80508@gmail.com> References: <4426A603.80508@gmail.com> Message-ID: On Sun, 26 Mar 2006, Beat Arnet wrote: > Dear all, > > When trying to open the serial port, I sometimes (not always) run into > the following exception (when opening the serialPort): > > Error 0x5 at /home/bob/foo/tar/rxtx-2.1-7/build/../src/termios.c(860): > Access is > denied. > > java.lang.UnsatisfiedLinkError: native_psmisc_report_owner > at gnu.io.CommPortIdentifier.native_psmisc_report_owner(Native > Method) > at gnu.io.CommPortIdentifier.open(CommPortIdentifier.java:354) > at codeskin.tools.CLLoader.open(CLLoader.java:79) > at codeskin.tools.C2000Programmer.run(C2000Programmer.java:220) > at java.lang.Thread.run(Unknown Source) > > Is this the type of error where I should just try to open the port again, > or can it be avoided? > Hi Beat We did a second build of rxtx 2.1-7 to resolve that unsatisfied link error. It should work now. rxtx is trying to tell you it thinks someone else has the serial port open. You can try to open the port again but maybe you already have a copy of the program running when it happens? ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7r2.zip fixed build. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sun Mar 26 11:44:23 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 26 Mar 2006 11:44:23 -0700 (MST) Subject: [Rxtx] RXTX spec file (fwd) Message-ID: This is probably interesting for fedora/suse users. ---------- Forwarded message ---------- Date: Sun, 26 Mar 2006 16:25:45 +0200 To: taj at www.linux.org.uk Subject: RXTX spec file I send you this spec file which allows to create a RPM for Fedora 4, 5 (x86, x86_64) with Java Sun. -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: rxtx.spec Url: http://mailman.qbang.org/pipermail/rxtx/attachments/20060326/6c7b6af6/rxtx-0024.pl From tjarvi at qbang.org Sun Mar 26 23:42:59 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 26 Mar 2006 23:42:59 -0700 (MST) Subject: [Rxtx] Upcomming events. Message-ID: This Wednesday we will be announcing a new "Maintainer" for the rxtx project. The position is more like neutral leader. I wont be going away or doing less. This is just the right thing to do as it turns out the two people with CVS write access will be at the same company. We need a third and we need neutrality. The maintainer will have final say in any conflict and will try to be neutral. It will be open for discussion. Then we will do it :) I'll still do most of the footwork I do now. But. I'm falling behind. I should have gone through the mail-list and posted the next round of changes this weekend. I'm packing to move and its going so so - 13 years of toys collected. I suspect there will be a dead period on my part (a couple weeks) comming up. But if you get it on the mail-list, we will get it in if there are no objections. I may well not be reading the mail-list during this period as I look for a house and many other things. I hope everyone will help out. Thanks -- Trent Jarvi tjarvi at qbang.org From mahmoud_hadad at yahoo.com Sun Mar 26 07:31:19 2006 From: mahmoud_hadad at yahoo.com (ronan nick) Date: Sun, 26 Mar 2006 06:31:19 -0800 (PST) Subject: [Rxtx] a question about the COMM API Message-ID: <20060326143119.54919.qmail@web60014.mail.yahoo.com> hi, i was intrested in knowing how i can communicate with my internal modem using java? for example if i want to make a phone dialer application or a caller id application where should i be looking at? and as i understood the COMM API is for devices that is attached to the computer through serial ports. --------------------------------- New Yahoo! Messenger with Voice. Call regular phones from your PC and save big. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060326/ce8329f0/attachment-0026.html From dmarkman at mac.com Mon Mar 20 00:20:43 2006 From: dmarkman at mac.com (Dmitry Markman) Date: Mon, 20 Mar 2006 02:20:43 -0500 Subject: [Rxtx] Mac OS X RXTX java installer In-Reply-To: References: <07D0DE29-BA32-4CFE-B036-66BC6423D385@buechse.de> <441AE3E0.2030503@willicon.de> <12531986.1142622114996.JavaMail.dmarkman@mac.com> <441B2674.9010409@willicon.de> <13577405.1142634732776.JavaMail.dmarkman@mac.com> <441B4182.8010407@willicon.de> <92CD0D6C-5BE8-426E-A46D-99452059FF49@mac.com> <441BBB2D.8030305@willicon.de> <441C4088.5090905@willicon.de> Message-ID: <64BC1E23-FDDE-4CE6-8863-CFC881CBC224@mac.com> Hi all I put RXTX installer that will install everything (and will create / var/lock if necessary and add user to the uucp group) for mac os x from Java into the rxtx's CVS repository it could be easily modified to install files for any platform it uses Greg Guerin's AuthKit for authentication and authorization Greg released that kit under artistic license, so Trent, please take a look we, probably, can negotiate license with Greg if it's necessary Greg's AuthKit could be downloaded from http://www.amug.org/~glguerin/ sw/#authkit Michael Hall (mikehall at spacestar dot net) had a suggestion to make implementation of the jaas LoginModule based on Greg's AuthKit (his modification of the Greg's AuthKit could be found at http:// www.spacestar.net/users/mikehall/authkit.dmg) but Michael's AuthKitLoginModule does only half a job: it does authenticate but it can not run any external unix process in privileged mode (at least I wasn't able to do so) possible explanation could be found in conversation between Greg and Michael at Apple's java-dev list (look for archives) so I didn't use jaas API for rxtxinstaller I created folder MacOSX in the contrib folder comment 1. if you want to run that installer as standalone application all you need that RXTXInstaller.jar 2. if you want to use webstart you have to add Greg's libAuthKit.jnilib to the mac os x's resources in theory RXTXInstaller.jar doesn't need it, but there is a problem with loading libAuthKit.jnilib from webstart authkit uses loadLibrary method to load library and it failed (from webstart) for standalone application I extract libAuthKit.jnilib from the RXTXInstaller.jar and put it into the /Library/Java/Extensions or ~/Library/Java/Extensions folder that file will be deleted after installer quit unfortunately I didn't have time to put documentation there but it is mostly self-explanatory I took installer code from my gl4java installer that I did about 3 years ago (with small modifications) it would be very nice if Apple will release LoginModule that really will do the job (com.apple.security.auth.module package????? ) (UnixLoginModule is pretty useless) From lyon at docjava.com Mon Mar 20 06:34:39 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Mon, 20 Mar 2006 08:34:39 -0500 Subject: [Rxtx] Mac OS X RXTX java installer In-Reply-To: <64BC1E23-FDDE-4CE6-8863-CFC881CBC224@mac.com> References: <07D0DE29-BA32-4CFE-B036-66BC6423D385@buechse.de> <441AE3E0.2030503@willicon.de> <12531986.1142622114996.JavaMail.dmarkman@mac.com> <441B2674.9010409@willicon.de> <13577405.1142634732776.JavaMail.dmarkman@mac.com> <441B4182.8010407@willicon.de> <92CD0D6C-5BE8-426E-A46D-99452059FF49@mac.com> <441BBB2D.8030305@willicon.de> <441C4088.5090905@willicon.de> <64BC1E23-FDDE-4CE6-8863-CFC881CBC224@mac.com> Message-ID: Hi Dimitry, This sounds like great work. Just a couple of questions; After the check out of the CVS files, using: setenv CVSROOT :pserver:anonymous at cvs.milestonesolutions.com:/usr/local/cvsroot 53 8:28 setenv PASSWORD mousy 54 8:29 cvs login 55 8:29 cvs checkout rxtx-devel I cd'd over to: rxtx-devel/MACOSX_IDE And found: CVS/ CW/ ForPackageMaker/ PB/ Where is the installer? Thanks! - Doug From tjarvi at qbang.org Mon Mar 20 06:39:37 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 20 Mar 2006 06:39:37 -0700 (MST) Subject: [Rxtx] Mac OS X RXTX java installer In-Reply-To: References: <07D0DE29-BA32-4CFE-B036-66BC6423D385@buechse.de> <441AE3E0.2030503@willicon.de> <12531986.1142622114996.JavaMail.dmarkman@mac.com> <441B2674.9010409@willicon.de> <13577405.1142634732776.JavaMail.dmarkman@mac.com> <441B4182.8010407@willicon.de> <92CD0D6C-5BE8-426E-A46D-99452059FF49@mac.com> <441BBB2D.8030305@willicon.de> <441C4088.5090905@willicon.de> <64BC1E23-FDDE-4CE6-8863-CFC881CBC224@mac.com> Message-ID: On Mon, 20 Mar 2006, Dr. Douglas Lyon wrote: > Hi Dimitry, > This sounds like great work. Just a couple of questions; > After the check out of the CVS files, using: > setenv CVSROOT > :pserver:anonymous at cvs.milestonesolutions.com:/usr/local/cvsroot > 53 8:28 setenv PASSWORD mousy > 54 8:29 cvs login > 55 8:29 cvs checkout rxtx-devel Hi Doug You want "cvs checkout -r commapi-0-0-1 rxtx-devel" to get RXTX 2.1 The default branch is rxtx 2.0 which isn't very active right now. -- Trent Jarvi tjarvi at qbang.org From lyon at docjava.com Mon Mar 20 07:05:44 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Mon, 20 Mar 2006 09:05:44 -0500 Subject: [Rxtx] Mac OS X RXTX java installer In-Reply-To: References: <07D0DE29-BA32-4CFE-B036-66BC6423D385@buechse.de> <441AE3E0.2030503@willicon.de> <12531986.1142622114996.JavaMail.dmarkman@mac.com> <441B2674.9010409@willicon.de> <13577405.1142634732776.JavaMail.dmarkman@mac.com> <441B4182.8010407@willicon.de> <92CD0D6C-5BE8-426E-A46D-99452059FF49@mac.com> <441BBB2D.8030305@willicon.de> <441C4088.5090905@willicon.de> <64BC1E23-FDDE-4CE6-8863-CFC881CBC224@mac.com> Message-ID: Hi Trent, Thanks for the info on the CVS checkout procedure. I did that and am still not sure where the installer is. Here is what I have: cd MACOSX_IDE/ p4.docjava.com{lyon}121: ls CVS/ ForPackageMaker/ PB/ p4.docjava.com{lyon}122: find . | more . ./ForPackageMaker ./ForPackageMaker/RXTX.pkg.sit.hqx ./ForPackageMaker/Resources ./ForPackageMaker/Resources/ReadMe.rtf ./ForPackageMaker/Resources/Welcome.rtf ./ForPackageMaker/Resources/CVS ./ForPackageMaker/Resources/CVS/Entries ./ForPackageMaker/Resources/CVS/Repository ./ForPackageMaker/Resources/CVS/Tag ./ForPackageMaker/Resources/CVS/Root ./ForPackageMaker/Resources/preinstall ./ForPackageMaker/Resources/License.rtf ./ForPackageMaker/Resources/preupgrade ./ForPackageMaker/RXTX.pmsp ./ForPackageMaker/CVS ./ForPackageMaker/CVS/Entries ./ForPackageMaker/CVS/Repository ./ForPackageMaker/CVS/Entries.Log ./ForPackageMaker/CVS/Tag ./ForPackageMaker/CVS/Root ./ForPackageMaker/RXTX_Tiger.pkg.sitx.hqx ./ForPackageMaker/RXTX_Jag.pkg.sit.hqx ./ForPackageMaker/Install ./ForPackageMaker/Install/CVS ./ForPackageMaker/Install/CVS/Entries ./ForPackageMaker/Install/CVS/Repository ./ForPackageMaker/Install/CVS/Tag ./ForPackageMaker/Install/CVS/Root ./ForPackageMaker/Install/Library ./ForPackageMaker/Install/Library/CVS ./ForPackageMaker/Install/Library/CVS/Entries ./ForPackageMaker/Install/Library/CVS/Repository ./ForPackageMaker/Install/Library/CVS/Tag ./ForPackageMaker/Install/Library/CVS/Root ./ForPackageMaker/Install/Library/Java ./ForPackageMaker/Install/Library/Java/Extensions ./ForPackageMaker/Install/Library/Java/Extensions/RXTXcomm.jar ./ForPackageMaker/Install/Library/Java/Extensions/CVS ./ForPackageMaker/Install/Library/Java/Extensions/CVS/Entries ./ForPackageMaker/Install/Library/Java/Extensions/CVS/Repository ./ForPackageMaker/Install/Library/Java/Extensions/CVS/Tag ./ForPackageMaker/Install/Library/Java/Extensions/CVS/Root ./ForPackageMaker/Install/Library/Java/Extensions/librxtxSerial.jnilib ./ForPackageMaker/Install/Library/Java/CVS ./ForPackageMaker/Install/Library/Java/CVS/Entries ./ForPackageMaker/Install/Library/Java/CVS/Repository ./ForPackageMaker/Install/Library/Java/CVS/Entries.Log ./ForPackageMaker/Install/Library/Java/CVS/Tag ./ForPackageMaker/Install/Library/Java/CVS/Root ./ForPackageMaker/RXTX_Tiger.pmproj.sitx.hqx ./CVS ./CVS/Entries ./CVS/Repository ./CVS/Entries.Log ./CVS/Tag ./CVS/Root ./PB ./PB/LibSerialUniversal.xcodeproj.sitx.hqx ./PB/CVS ./PB/CVS/Entries ./PB/CVS/Repository ./PB/CVS/Entries.Log ./PB/CVS/Tag ./PB/CVS/Root ./PB/LibSerial.pbproj.sit.hqx ./PB/startpoint.c ./PB/config.h What is the procedure to run this installer? Do we need a README in: /rxtx-devel/MACOSX_IDE Here is what we have: CVS/ ForPackageMaker/ PB/ Thanks! - DL >On Mon, 20 Mar 2006, Dr. Douglas Lyon wrote: > >>Hi Dimitry, >>This sounds like great work. Just a couple of questions; >>After the check out of the CVS files, using: >>setenv CVSROOT >>:pserver:anonymous at cvs.milestonesolutions.com:/usr/local/cvsroot >> 53 8:28 setenv PASSWORD mousy >> 54 8:29 cvs login >> 55 8:29 cvs checkout rxtx-devel > >Hi Doug > >You want "cvs checkout -r commapi-0-0-1 rxtx-devel" to get RXTX 2.1 >The default branch is rxtx 2.0 which isn't very active right now. > >-- >Trent Jarvi >tjarvi at qbang.org From tjarvi at qbang.org Mon Mar 20 07:25:30 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 20 Mar 2006 07:25:30 -0700 (MST) Subject: [Rxtx] Mac OS X RXTX java installer In-Reply-To: References: <07D0DE29-BA32-4CFE-B036-66BC6423D385@buechse.de> <441AE3E0.2030503@willicon.de> <12531986.1142622114996.JavaMail.dmarkman@mac.com> <441B2674.9010409@willicon.de> <13577405.1142634732776.JavaMail.dmarkman@mac.com> <441B4182.8010407@willicon.de> <92CD0D6C-5BE8-426E-A46D-99452059FF49@mac.com> <441BBB2D.8030305@willicon.de> <441C4088.5090905@willicon.de> <64BC1E23-FDDE-4CE6-8863-CFC881CBC224@mac.com> Message-ID: On Mon, 20 Mar 2006, Dr. Douglas Lyon wrote: > Hi Trent, > Thanks for the info on the CVS checkout procedure. > I did that and am still not sure where the installer is. Hi Doug It does look like it was not cvs committed. There is no rxtx-devel/contrib/MacOSX directory in there at the moment. It was mentioned that it was put under contrib. -- Trent Jarvi tjarvi at qbang.org From dmarkman at mac.com Mon Mar 20 07:29:56 2006 From: dmarkman at mac.com (Dmitry Markman) Date: Mon, 20 Mar 2006 09:29:56 -0500 Subject: [Rxtx] Mac OS X RXTX java installer In-Reply-To: References: <07D0DE29-BA32-4CFE-B036-66BC6423D385@buechse.de> <441AE3E0.2030503@willicon.de> <12531986.1142622114996.JavaMail.dmarkman@mac.com> <441B2674.9010409@willicon.de> <13577405.1142634732776.JavaMail.dmarkman@mac.com> <441B4182.8010407@willicon.de> <92CD0D6C-5BE8-426E-A46D-99452059FF49@mac.com> <441BBB2D.8030305@willicon.de> <441C4088.5090905@willicon.de> <64BC1E23-FDDE-4CE6-8863-CFC881CBC224@mac.com> Message-ID: <6054EB4E-F7E0-4A9C-BDDA-D582D6D8826F@mac.com> you can find it in the rxtx-devel/contrib folder On Mar 20, 2006, at 9:05 AM, Dr. Douglas Lyon wrote: > Hi Trent, > Thanks for the info on the CVS checkout procedure. > I did that and am still not sure where the installer is. > Here is what I have: > cd MACOSX_IDE/ > p4.docjava.com{lyon}121: ls > CVS/ ForPackageMaker/ PB/ > p4.docjava.com{lyon}122: find . | more > . > ./ForPackageMaker > ./ForPackageMaker/RXTX.pkg.sit.hqx > ./ForPackageMaker/Resources > ./ForPackageMaker/Resources/ReadMe.rtf > ./ForPackageMaker/Resources/Welcome.rtf > ./ForPackageMaker/Resources/CVS > ./ForPackageMaker/Resources/CVS/Entries > ./ForPackageMaker/Resources/CVS/Repository > ./ForPackageMaker/Resources/CVS/Tag > ./ForPackageMaker/Resources/CVS/Root > ./ForPackageMaker/Resources/preinstall > ./ForPackageMaker/Resources/License.rtf > ./ForPackageMaker/Resources/preupgrade > ./ForPackageMaker/RXTX.pmsp > ./ForPackageMaker/CVS > ./ForPackageMaker/CVS/Entries > ./ForPackageMaker/CVS/Repository > ./ForPackageMaker/CVS/Entries.Log > ./ForPackageMaker/CVS/Tag > ./ForPackageMaker/CVS/Root > ./ForPackageMaker/RXTX_Tiger.pkg.sitx.hqx > ./ForPackageMaker/RXTX_Jag.pkg.sit.hqx > ./ForPackageMaker/Install > ./ForPackageMaker/Install/CVS > ./ForPackageMaker/Install/CVS/Entries > ./ForPackageMaker/Install/CVS/Repository > ./ForPackageMaker/Install/CVS/Tag > ./ForPackageMaker/Install/CVS/Root > ./ForPackageMaker/Install/Library > ./ForPackageMaker/Install/Library/CVS > ./ForPackageMaker/Install/Library/CVS/Entries > ./ForPackageMaker/Install/Library/CVS/Repository > ./ForPackageMaker/Install/Library/CVS/Tag > ./ForPackageMaker/Install/Library/CVS/Root > ./ForPackageMaker/Install/Library/Java > ./ForPackageMaker/Install/Library/Java/Extensions > ./ForPackageMaker/Install/Library/Java/Extensions/RXTXcomm.jar > ./ForPackageMaker/Install/Library/Java/Extensions/CVS > ./ForPackageMaker/Install/Library/Java/Extensions/CVS/Entries > ./ForPackageMaker/Install/Library/Java/Extensions/CVS/Repository > ./ForPackageMaker/Install/Library/Java/Extensions/CVS/Tag > ./ForPackageMaker/Install/Library/Java/Extensions/CVS/Root > ./ForPackageMaker/Install/Library/Java/Extensions/librxtxSerial.jnilib > ./ForPackageMaker/Install/Library/Java/CVS > ./ForPackageMaker/Install/Library/Java/CVS/Entries > ./ForPackageMaker/Install/Library/Java/CVS/Repository > ./ForPackageMaker/Install/Library/Java/CVS/Entries.Log > ./ForPackageMaker/Install/Library/Java/CVS/Tag > ./ForPackageMaker/Install/Library/Java/CVS/Root > ./ForPackageMaker/RXTX_Tiger.pmproj.sitx.hqx > ./CVS > ./CVS/Entries > ./CVS/Repository > ./CVS/Entries.Log > ./CVS/Tag > ./CVS/Root > ./PB > ./PB/LibSerialUniversal.xcodeproj.sitx.hqx > ./PB/CVS > ./PB/CVS/Entries > ./PB/CVS/Repository > ./PB/CVS/Entries.Log > ./PB/CVS/Tag > ./PB/CVS/Root > ./PB/LibSerial.pbproj.sit.hqx > ./PB/startpoint.c > ./PB/config.h > > What is the procedure to run this installer? > Do we need a README in: > /rxtx-devel/MACOSX_IDE > Here is what we have: > CVS/ ForPackageMaker/ PB/ > > > Thanks! > - DL > >> On Mon, 20 Mar 2006, Dr. Douglas Lyon wrote: >> >>> Hi Dimitry, >>> This sounds like great work. Just a couple of questions; >>> After the check out of the CVS files, using: >>> setenv CVSROOT :pserver:anonymous at cvs.milestonesolutions.com:/usr/ >>> local/cvsroot >>> 53 8:28 setenv PASSWORD mousy >>> 54 8:29 cvs login >>> 55 8:29 cvs checkout rxtx-devel >> >> Hi Doug >> >> You want "cvs checkout -r commapi-0-0-1 rxtx-devel" to get RXTX 2.1 >> The default branch is rxtx 2.0 which isn't very active right now. >> >> -- >> Trent Jarvi >> tjarvi at qbang.org > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx Dmitry Markman From mikehall at spacestar.net Mon Mar 20 05:25:25 2006 From: mikehall at spacestar.net (Michael Hall) Date: Mon, 20 Mar 2006 06:25:25 -0600 Subject: [Rxtx] Re: Mac OS X RXTX java installer In-Reply-To: <64BC1E23-FDDE-4CE6-8863-CFC881CBC224@mac.com> References: <07D0DE29-BA32-4CFE-B036-66BC6423D385@buechse.de> <441AE3E0.2030503@willicon.de> <12531986.1142622114996.JavaMail.dmarkman@mac.com> <441B2674.9010409@willicon.de> <13577405.1142634732776.JavaMail.dmarkman@mac.com> <441B4182.8010407@willicon.de> <92CD0D6C-5BE8-426E-A46D-99452059FF49@mac.com> <441BBB2D.8030305@willicon.de> <441C4088.5090905@willicon.de> <64BC1E23-FDDE-4CE6-8863-CFC881CBC224@mac.com> Message-ID: <247EB61F-5CD1-4132-89A2-FC105B6CF9A5@spacestar.net> On Mar 20, 2006, at 1:20 AM, Dmitry Markman wrote: > > Michael Hall (mikehall at spacestar dot net) had a suggestion to > make implementation of the jaas LoginModule > based on Greg's AuthKit > (his modification of the Greg's AuthKit could be found at http:// > www.spacestar.net/users/mikehall/authkit.dmg) > but Michael's AuthKitLoginModule does only half a job: > it does authenticate > but it can not run any external unix process in privileged mode (at > least I wasn't able to do so) If you got it working directly with Greg's the point is moot. But to clarify it anyhow. The login module does not allow you to do anything anything privileged on return as was explained by Greg. You need to work with a separate privileged process using the execPrivileged method of his API. I assume you did something similar although I haven't looked at how you are using it yet. I allowed instead for a action to be performed at the same time you login/authenticate,this... System.setProperty("authkit.action","/usr/bin/id"); just before this... lc.login(); To clarify, safely ignored as you are already complete. Mike Hall mikehall at spacestar dot net http://www.spacestar.net/users/mikehall http://sourceforge.net/projects/macnative -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2427 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20060320/f6e18202/smime-0029.bin From dmarkman at mac.com Mon Mar 20 07:36:47 2006 From: dmarkman at mac.com (Dmitry Markman) Date: Mon, 20 Mar 2006 09:36:47 -0500 Subject: [Rxtx] Re: Mac OS X RXTX java installer In-Reply-To: <247EB61F-5CD1-4132-89A2-FC105B6CF9A5@spacestar.net> References: <07D0DE29-BA32-4CFE-B036-66BC6423D385@buechse.de> <441AE3E0.2030503@willicon.de> <12531986.1142622114996.JavaMail.dmarkman@mac.com> <441B2674.9010409@willicon.de> <13577405.1142634732776.JavaMail.dmarkman@mac.com> <441B4182.8010407@willicon.de> <92CD0D6C-5BE8-426E-A46D-99452059FF49@mac.com> <441BBB2D.8030305@willicon.de> <441C4088.5090905@willicon.de> <64BC1E23-FDDE-4CE6-8863-CFC881CBC224@mac.com> <247EB61F-5CD1-4132-89A2-FC105B6CF9A5@spacestar.net> Message-ID: Hi, Michael all I have to do is to run some shell script I tried to use your action mechanism and it worked great so I just System.setProperty ("authkit.action","" ) and after that I even don't need to run anything like subject.doAs.... but after few thoughts I choose to use plain Greg's approach, because in that case I don't have to deal with various java's configurations files and therefore to use 2-3 -D parameters in the java command line especially it's useful for java web start (it's so fragile :-( ) thanks for the great job On Mar 20, 2006, at 7:25 AM, Michael Hall wrote: > > On Mar 20, 2006, at 1:20 AM, Dmitry Markman wrote: >> >> Michael Hall (mikehall at spacestar dot net) had a suggestion to >> make implementation of the jaas LoginModule >> based on Greg's AuthKit >> (his modification of the Greg's AuthKit could be found at http:// >> www.spacestar.net/users/mikehall/authkit.dmg) >> but Michael's AuthKitLoginModule does only half a job: >> it does authenticate >> but it can not run any external unix process in privileged mode >> (at least I wasn't able to do so) > > If you got it working directly with Greg's the point is moot. > > But to clarify it anyhow. > The login module does not allow you to do anything anything > privileged on return as was explained by Greg. You need to work > with a separate privileged process using the execPrivileged method > of his API. I assume you did something similar although I haven't > looked at how you are using it yet. > I allowed instead for a action to be performed at the same time you > login/authenticate,this... > System.setProperty("authkit.action","/usr/bin/id"); > just before this... > lc.login(); > To clarify, safely ignored as you are already complete. > > Mike Hall mikehall at spacestar dot net > http://www.spacestar.net/users/mikehall > http://sourceforge.net/projects/macnative > > > Dmitry Markman From dmarkman at mac.com Mon Mar 20 07:44:45 2006 From: dmarkman at mac.com (Dmitry Markman) Date: Mon, 20 Mar 2006 09:44:45 -0500 Subject: [Rxtx] Mac OS X RXTX java installer In-Reply-To: References: <07D0DE29-BA32-4CFE-B036-66BC6423D385@buechse.de> <441AE3E0.2030503@willicon.de> <12531986.1142622114996.JavaMail.dmarkman@mac.com> <441B2674.9010409@willicon.de> <13577405.1142634732776.JavaMail.dmarkman@mac.com> <441B4182.8010407@willicon.de> <92CD0D6C-5BE8-426E-A46D-99452059FF49@mac.com> <441BBB2D.8030305@willicon.de> <441C4088.5090905@willicon.de> <64BC1E23-FDDE-4CE6-8863-CFC881CBC224@mac.com> Message-ID: it's in the commapi-0-0-1 branch I tested it right now: cvs co -r commapi-0-0-1 rxtx-devel and I got everything On Mar 20, 2006, at 9:25 AM, Trent Jarvi wrote: > On Mon, 20 Mar 2006, Dr. Douglas Lyon wrote: > >> Hi Trent, >> Thanks for the info on the CVS checkout procedure. >> I did that and am still not sure where the installer is. > > Hi Doug > > It does look like it was not cvs committed. There is no rxtx-devel/ > contrib/MacOSX directory in there at the moment. It was mentioned > that it was put under contrib. > > -- > Trent Jarvi > tjarvi at qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx Dmitry Markman From tjarvi at qbang.org Mon Mar 20 07:52:57 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 20 Mar 2006 07:52:57 -0700 (MST) Subject: [Rxtx] Mac OS X RXTX java installer In-Reply-To: References: <07D0DE29-BA32-4CFE-B036-66BC6423D385@buechse.de> <441AE3E0.2030503@willicon.de> <12531986.1142622114996.JavaMail.dmarkman@mac.com> <441B2674.9010409@willicon.de> <13577405.1142634732776.JavaMail.dmarkman@mac.com> <441B4182.8010407@willicon.de> <92CD0D6C-5BE8-426E-A46D-99452059FF49@mac.com> <441BBB2D.8030305@willicon.de> <441C4088.5090905@willicon.de> <64BC1E23-FDDE-4CE6-8863-CFC881CBC224@mac.com> Message-ID: On Mon, 20 Mar 2006, Dmitry Markman wrote: > it's in the commapi-0-0-1 branch > > I tested it right now: > cvs co -r commapi-0-0-1 rxtx-devel > > and I got everything > A fresh checkout worked. Here is a copy of the tree (just the installer bits) ftp://ftp.qbang.org/pub/rxtx/MacOSX-installer.zip -- Trent Jarvi tjarvi at qbang.org From lyon at docjava.com Mon Mar 20 08:08:26 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Mon, 20 Mar 2006 10:08:26 -0500 Subject: [Rxtx] Mac OS X RXTX java installer In-Reply-To: References: <07D0DE29-BA32-4CFE-B036-66BC6423D385@buechse.de> <441AE3E0.2030503@willicon.de> <12531986.1142622114996.JavaMail.dmarkman@mac.com> <441B2674.9010409@willicon.de> <13577405.1142634732776.JavaMail.dmarkman@mac.com> <441B4182.8010407@willicon.de> <92CD0D6C-5BE8-426E-A46D-99452059FF49@mac.com> <441BBB2D.8030305@willicon.de> <441C4088.5090905@willicon.de> <64BC1E23-FDDE-4CE6-8863-CFC881CBC224@mac.com> Message-ID: Hi All, Is the Auth package able to work properly on non Mac OS's? It was not clear from the doc or download. Thanks! - Doug From dmarkman at mac.com Mon Mar 20 08:15:22 2006 From: dmarkman at mac.com (Dmitry Markman) Date: Mon, 20 Mar 2006 10:15:22 -0500 Subject: [Rxtx] Mac OS X RXTX java installer In-Reply-To: References: <07D0DE29-BA32-4CFE-B036-66BC6423D385@buechse.de> <441AE3E0.2030503@willicon.de> <12531986.1142622114996.JavaMail.dmarkman@mac.com> <441B2674.9010409@willicon.de> <13577405.1142634732776.JavaMail.dmarkman@mac.com> <441B4182.8010407@willicon.de> <92CD0D6C-5BE8-426E-A46D-99452059FF49@mac.com> <441BBB2D.8030305@willicon.de> <441C4088.5090905@willicon.de> <64BC1E23-FDDE-4CE6-8863-CFC881CBC224@mac.com> Message-ID: <217312D8-CCCA-4859-ABA6-32DF1CC817B9@mac.com> thanks Trent, for putting it on ftp server On Mar 20, 2006, at 9:52 AM, Trent Jarvi wrote: > A fresh checkout worked. Here is a copy of the tree (just the > installer bits) > > ftp://ftp.qbang.org/pub/rxtx/MacOSX-installer.zip > Dmitry Markman From dmarkman at mac.com Mon Mar 20 09:14:03 2006 From: dmarkman at mac.com (Dmitry Markman) Date: Mon, 20 Mar 2006 11:14:03 -0500 Subject: [Rxtx] Mac OS X RXTX java installer In-Reply-To: References: <07D0DE29-BA32-4CFE-B036-66BC6423D385@buechse.de> <441AE3E0.2030503@willicon.de> <12531986.1142622114996.JavaMail.dmarkman@mac.com> <441B2674.9010409@willicon.de> <13577405.1142634732776.JavaMail.dmarkman@mac.com> <441B4182.8010407@willicon.de> <92CD0D6C-5BE8-426E-A46D-99452059FF49@mac.com> <441BBB2D.8030305@willicon.de> <441C4088.5090905@willicon.de> <64BC1E23-FDDE-4CE6-8863-CFC881CBC224@mac.com> Message-ID: <4DEBA6F0-DA45-4E84-823E-1F1AC48BDCCC@mac.com> no it will work only on mac os x however it's harmless to run it on other platform if you want to use it for other platform you have to do the following (I'll do it for linux) 1. modify RXTXInstaller class method public static RXTXInstaller getInstance() public static RXTXInstaller getInstance() { String osName = System.getProperty("os.name").toLowerCase(); if(osName.startsWith("mac")){ return new gnu.io.installer.macosx.MACOSXRXTXInstaller(); } else if(osName.startsWith("windows")){ return new gnu.io.installer.windows.WindowsRXTXInstaller(); }else if(osName.startsWith("linux")){ return new gnu.io.installer.linux.LinuxRXTXInstaller(); } return null; } 2. create folder gnu/io/installer/linux/ 3. create class Linux386RXTXInstaller package gnu.io.installer.linux; import java.io.File; public class Linux386RXTXInstaller extends gnu.io.installer.RXTXInstaller{ public Linux386RXTXInstaller(){ createJarFolder(); createLibFolder(); addJarResource("RXTXcomm.jar","/gnu/io/installer/resources/ linux/jar/RXTXcomm.dat"); addLibResource("librxtxSerial.so","/gnu/io/installer/ resources/linux/lib/librxtxSerial.so"); } protected void createJarFolder(){ String javaHome = System.getProperty("java.home"); char separator = File.separatorChar; jarFolder = new File(javaHome+separator+"lib"+separator+"ext"); } protected void createLibFolder(){ String javaHome = System.getProperty("java.home"); char separator = File.separatorChar; libFolder = new File(javaHome+separator+"bin"); } public void runPreProcess() {} //put here some action you need public void runPostProcess() {} //put here some action you need } 4. create folder /gnu/io/installer/resources/linux/jar and put there linux's version of RXTXcomm.dat (which is renamed RXTXcomm.jar) 5. create folder /gnu/io/installer/resources/linux/lib and put there linux's version of librxtxSerial. so 6. make sure that RXTXInstaller.jar has the following items: /gnu/io/installer/resources/linux/jar/RXTXcomm.jar /gnu/io/installer/resources/linux/lib/librxtxSerial.so 7. modify file installer.pref: jar file RXTXInstaller.jar must have the following item /gnu/io/installer/installer.pref that's basically it for windows you have to do the similar things: just replace linux to windows and librxtxSerial.so to rxtxSerial.dll and create appropriate gnu.io.installer.windows.WindowsRXTXInstaller class package gnu.io.installer.windows; import java.io.File; public class WindowsRXTXInstaller extends gnu.io.installer.RXTXInstaller{ public WindowsRXTXInstaller(){ createJarFolder(); createLibFolder(); addJarResource("RXTXcomm.jar","/gnu/io/installer/resources/ windows/jar/RXTXcomm.dat"); addLibResource("librxtxSerial.so","/gnu/io/installer/ resources/windows/lib/rxtxSerial.dll"); } protected void createJarFolder(){ String javaHome = System.getProperty("java.home"); char separator = File.separatorChar; jarFolder = new File(javaHome+separator+"lib"+separator+"ext"); } protected void createLibFolder(){ String javaHome = System.getProperty("java.home"); char separator = File.separatorChar; libFolder = new File(javaHome+separator+"bin"); } public void runPreProcess() {} //put here some action you need public void runPostProcess() {} //put here some action you need } installer.pref will look like On Mar 20, 2006, at 10:08 AM, Dr. Douglas Lyon wrote: > Hi All, > Is the Auth package able to work properly on > non Mac OS's? > It was not clear from the doc or download. > > Thanks! > - Doug > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx Dmitry Markman From joachim at buechse.de Mon Mar 20 10:49:06 2006 From: joachim at buechse.de (Joachim Buechse) Date: Mon, 20 Mar 2006 18:49:06 +0100 Subject: [Rxtx] BUG: Lock file stays even if port opening fails Message-ID: This was only tested on MacOSX but looking at the code, it should be true for all systems that use lock_uucp. I am opening a port which can not be opened (dialup port of a telephone paired via bluetooth but currently not reachable). The lock file is created and stays arround, even though the port open failed. After looking a bit through the code (of 2.17), I really wonder if it wouldn't be a good idea to make the "locking" an explicit operation called from the java code. This would certainly simplify the generation of meaningfull exceptions (and java based debugging). Maybe even the handling of "preopened" ports should be in the Java part of the lib (again for java based debugging puposes). That beeing said, I have no idea if this would be possible for the 2.07 implementation. Regards, Joachim From tjarvi at qbang.org Mon Mar 20 11:24:22 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 20 Mar 2006 11:24:22 -0700 (MST) Subject: [Rxtx] BUG: Lock file stays even if port opening fails In-Reply-To: References: Message-ID: On Mon, 20 Mar 2006, Joachim Buechse wrote: > This was only tested on MacOSX but looking at the code, it should be true > for all systems that use lock_uucp. > > I am opening a port which can not be opened (dialup port of a telephone > paired via bluetooth but currently not reachable). The lock file is > created and stays arround, even though the port open failed. > > > After looking a bit through the code (of 2.17), I really wonder if it > wouldn't be a good idea to make the "locking" an explicit operation > called from the java code. This would certainly simplify the generation > of meaningfull exceptions (and java based debugging). > Maybe even the handling of "preopened" ports should be in the Java part > of the lib (again for java based debugging puposes). That beeing said, I > have no idea if this would be possible for the 2.07 implementation. > > Regards, Hi Joachim It should be possible in the 2.0-7 implementation too. The calls to RXTXPort.java would not change. We would just do more there Moving more of that logic into Java would be better as many people don't like to look at C code. There is a liblockdev on most Linux distros that can do most of the C code and would be easier to use. The problem is embeded devices will not have that library. The preopened port code has not been really tested. That was a last minute request in a product cycle. I expect it will be tested this year though. As I recall, some devices really do not like CD raising on open. The preopened ports then allow people to mess around in java without power cycling the devices or losing data. -- Trent Jarvi tjarvi at qbang.org From joachim at buechse.de Mon Mar 20 12:01:08 2006 From: joachim at buechse.de (Joachim Buechse) Date: Mon, 20 Mar 2006 20:01:08 +0100 Subject: [Rxtx] BUG: Lock file stays even if port opening fails In-Reply-To: References: Message-ID: Hi Trent, What is your general feeling about moving code to Java? The last days I have been reading quite a bit of the code and there are several things, that might not work as expected. I'll give you two examples from is_device_locked: if LOCKDIR == /var/spool/locks the directory /var/spool/lock will not be checked. LOCKDIR is not checked for lockfiles with unexpected pefixes While these things have probably never been discovered in production, they are still possibly incorrect implementations. If it was Java code, I would write some unit tests producing the errors that could later be corrected. PS: One could imagine to actually implement the whole lockfile handling in Java using some native routines to get the values required (pid, st_dev, st_rdev, ...). On 20.03.2006, at 19:24, Trent Jarvi wrote: > On Mon, 20 Mar 2006, Joachim Buechse wrote: > >> This was only tested on MacOSX but looking at the code, it should >> be true for all systems that use lock_uucp. >> >> I am opening a port which can not be opened (dialup port of a >> telephone paired via bluetooth but currently not reachable). The >> lock file is created and stays arround, even though the port open >> failed. >> >> >> After looking a bit through the code (of 2.17), I really wonder if >> it wouldn't be a good idea to make the "locking" an explicit >> operation called from the java code. This would certainly simplify >> the generation of meaningfull exceptions (and java based debugging). >> Maybe even the handling of "preopened" ports should be in the Java >> part of the lib (again for java based debugging puposes). That >> beeing said, I have no idea if this would be possible for the 2.07 >> implementation. >> >> Regards, > > Hi Joachim > > It should be possible in the 2.0-7 implementation too. The calls > to RXTXPort.java would not change. We would just do more there > Moving more of that logic into Java would be better as many people > don't like to look at C code. There is a liblockdev on most Linux > distros that can do most of the C code and would be easier to use. > The problem is embeded devices will not have that library. > > The preopened port code has not been really tested. That was a > last minute request in a product cycle. I expect it will be tested > this year though. As I recall, some devices really do not like CD > raising on open. The preopened ports then allow people to mess > around in java without power cycling the devices or losing data. > > -- > Trent Jarvi > tjarvi at qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Mon Mar 20 12:21:02 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 20 Mar 2006 12:21:02 -0700 (MST) Subject: [Rxtx] BUG: Lock file stays even if port opening fails In-Reply-To: References: Message-ID: On Mon, 20 Mar 2006, Joachim Buechse wrote: > Hi Trent, > > What is your general feeling about moving code to Java? The last days I > have been reading quite a bit of the code and there are several things, > that might not work as expected. > > I'll give you two examples from is_device_locked: > > if LOCKDIR == /var/spool/locks the directory /var/spool/lock will not be > checked. > LOCKDIR is not checked for lockfiles with unexpected pefixes > > While these things have probably never been discovered in production, > they are still possibly incorrect implementations. If it was Java code, I > would write some unit tests producing the errors that could later be > corrected. > > PS: One could imagine to actually implement the whole lockfile handling > in Java using some native routines to get the values required (pid, > st_dev, st_rdev, ...). Hi Joachim I like the idea of moving more of the code into java but there are some things to consider. If you break this into multiple JNI calls, the performance will drop considerably during enumeration of ports. We are looking for 256 ports per dev type vs (16? in Sun's 2.0 and fewer types). Its hard to make assumptions. I've seen virtual ports start at /dev/foo100 for instance. It works out to over 7500 ports on Linux if you enable them all. We already trim that back by default. See Linux-all-ports in RXTXCommDriver.java. There are also native libraries that rxtx can link to. If you move too much into Java, linking to 'standard' libraries with distros will break. "configure --enable-liblock=yes" will not be doable. This is probably a favorable way with RedHat, Debian, Suse and others. Thats the right thing to do if there will be rpms, dpkg, .. For those reasons, I think it still make sense to keep it to a minimal ~3 calls to JNI code that we can use for speed and versatility. lock() isLocked(), unlock() perhaps. When I say speed, its more about avoiding crossing the JNI layer multiple times than java vs C performance. With versatility I think liblock is the right way for most but not all (embeded) linux distros. -- Trent Jarvi tjarvi at qbang.org From joachim at buechse.de Mon Mar 20 12:42:04 2006 From: joachim at buechse.de (Joachim Buechse) Date: Mon, 20 Mar 2006 20:42:04 +0100 Subject: [Rxtx] BUG: Lock file stays even if port opening fails In-Reply-To: References: Message-ID: <82C19FE7-DDCB-45B6-B2C9-7606B66F0124@buechse.de> Ok, what about providing a default implementation in Java? The RXTXCommDriver would call a (native) function useNativeLocking and if it returns true, call the native functions for lock() isLocked (), unlock(), else is would use the Java based default implementation. This could possibly be overriden by a property (again for debugging). Joachim On 20.03.2006, at 20:21, Trent Jarvi wrote: > On Mon, 20 Mar 2006, Joachim Buechse wrote: > >> Hi Trent, >> >> What is your general feeling about moving code to Java? The last >> days I have been reading quite a bit of the code and there are >> several things, that might not work as expected. >> >> I'll give you two examples from is_device_locked: >> >> if LOCKDIR == /var/spool/locks the directory /var/spool/lock will >> not be checked. >> LOCKDIR is not checked for lockfiles with unexpected pefixes >> >> While these things have probably never been discovered in >> production, they are still possibly incorrect implementations. If >> it was Java code, I would write some unit tests producing the >> errors that could later be corrected. >> >> PS: One could imagine to actually implement the whole lockfile >> handling in Java using some native routines to get the values >> required (pid, st_dev, st_rdev, ...). > > Hi Joachim > > I like the idea of moving more of the code into java but there are > some things to consider. > > If you break this into multiple JNI calls, the performance will > drop considerably during enumeration of ports. We are looking for > 256 ports per dev type vs (16? in Sun's 2.0 and fewer types). Its > hard to make assumptions. I've seen virtual ports start at /dev/ > foo100 for instance. > > It works out to over 7500 ports on Linux if you enable them all. > We already trim that back by default. See Linux-all-ports in > RXTXCommDriver.java. > > There are also native libraries that rxtx can link to. If you move > too much into Java, linking to 'standard' libraries with distros > will break. "configure --enable-liblock=yes" will not be doable. > This is probably a favorable way with RedHat, Debian, Suse and > others. Thats the right thing to do if there will be rpms, dpkg, .. > > For those reasons, I think it still make sense to keep it to a > minimal ~3 calls to JNI code that we can use for speed and > versatility. lock() isLocked(), unlock() perhaps. When I say > speed, its more about avoiding crossing the JNI layer multiple > times than java vs C performance. With versatility I think liblock > is the right way for most but not all (embeded) linux distros. > > -- > Trent Jarvi > tjarvi at qbang.org > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Mon Mar 20 12:44:47 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 20 Mar 2006 12:44:47 -0700 (MST) Subject: [Rxtx] BUG: Lock file stays even if port opening fails In-Reply-To: <82C19FE7-DDCB-45B6-B2C9-7606B66F0124@buechse.de> References: <82C19FE7-DDCB-45B6-B2C9-7606B66F0124@buechse.de> Message-ID: On Mon, 20 Mar 2006, Joachim Buechse wrote: > Ok, what about providing a default implementation in Java? > > The RXTXCommDriver would call a (native) function useNativeLocking and if > it returns true, call the native functions for lock() isLocked(), > unlock(), else is would use the Java based default implementation. This > could possibly be overriden by a property (again for debugging). > Hi Joachim That would be OK with me. -- Trent Jarvi tjarvi at qbang.org From dmarkman at mac.com Mon Mar 20 22:27:45 2006 From: dmarkman at mac.com (Dmitry Markman) Date: Tue, 21 Mar 2006 00:27:45 -0500 Subject: [Rxtx] binaries request Message-ID: <42702213-C222-4937-A585-7CFB17E47608@mac.com> Hi can somebody send me latest linux and windows binaries, please? or where I can find them (I didn't find them in the latest tareball) I gave up with my cygwin: something wrong I have no idea what java doesn't understand /cygwin/c syntax after I changed makefile it did java part but after that gcc 3.4.4 started to complain I set buffer length to 999 lines but I didn't get beginning of the story something wrong with my 1.4.2_09/include/jni.h gcc doesn't like it anyway I gave up thanks in advance Dmitry Markman -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060320/f8cbc57c/attachment-0029.html From tjarvi at qbang.org Mon Mar 20 22:36:48 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 20 Mar 2006 22:36:48 -0700 (MST) Subject: [Rxtx] binaries request In-Reply-To: <42702213-C222-4937-A585-7CFB17E47608@mac.com> References: <42702213-C222-4937-A585-7CFB17E47608@mac.com> Message-ID: On Tue, 21 Mar 2006, Dmitry Markman wrote: > Hi > can somebody send me latest linux and windows binaries, please? > > or where I can find them (I didn't find them in the latest tareball) > > I gave up with my cygwin: something wrong I have no idea what > java doesn't understand /cygwin/c syntax > after I changed makefile it did java part > but after that gcc 3.4.4 started to complain > I set buffer length to 999 lines but I didn't get beginning of the story > something wrong with my 1.4.2_09/include/jni.h gcc doesn't like it > anyway I gave up > > thanks in advance > Hi Dmitry The bins are here: ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7-bins-r2.zip Here are the files in the zip you want. Jar: rxtx-2.1-7-bins-r2/RXTXcomm.jar Windows: rxtx-2.1-7-bins-r2/Windows/i368-mingw32/rxtxSerial.dll Linux (x86) rxtx-2.1-7-bins-r2/Linux/i686-unknown-linux-gnu/librxtxSerial.so There are others in there including Parallel port support but those are the main ones for testing. -- Trent Jarvi tjarvi at qbang.org From dmarkman at mac.com Mon Mar 20 23:05:59 2006 From: dmarkman at mac.com (Dmitry Markman) Date: Tue, 21 Mar 2006 01:05:59 -0500 Subject: [Rxtx] binaries request In-Reply-To: References: <42702213-C222-4937-A585-7CFB17E47608@mac.com> Message-ID: thank you very much but windows's readme says: rxtxSerial.dll had to be recomopiled to link in missing native methods. should I ignore it? or what? thanks again also I understand that I should use mingw not cygwin I'll try to install mingw On Mar 21, 2006, at 12:36 AM, Trent Jarvi wrote: > On Tue, 21 Mar 2006, Dmitry Markman wrote: > >> Hi >> can somebody send me latest linux and windows binaries, please? >> >> or where I can find them (I didn't find them in the latest tareball) >> >> I gave up with my cygwin: something wrong I have no idea what >> java doesn't understand /cygwin/c syntax >> after I changed makefile it did java part >> but after that gcc 3.4.4 started to complain >> I set buffer length to 999 lines but I didn't get beginning of the >> story >> something wrong with my 1.4.2_09/include/jni.h gcc doesn't like it >> anyway I gave up >> >> thanks in advance >> > > Hi Dmitry > > The bins are here: > > ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7-bins-r2.zip > > Here are the files in the zip you want. > > Jar: > > rxtx-2.1-7-bins-r2/RXTXcomm.jar > > Windows: > > rxtx-2.1-7-bins-r2/Windows/i368-mingw32/rxtxSerial.dll > > Linux (x86) > > rxtx-2.1-7-bins-r2/Linux/i686-unknown-linux-gnu/librxtxSerial.so > > There are others in there including Parallel port support but those > are the main ones for testing. > > -- > Trent Jarvi > tjarvi at qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx Dmitry Markman From tjarvi at qbang.org Mon Mar 20 23:20:33 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 20 Mar 2006 23:20:33 -0700 (MST) Subject: [Rxtx] binaries request In-Reply-To: References: <42702213-C222-4937-A585-7CFB17E47608@mac.com> Message-ID: On Tue, 21 Mar 2006, Dmitry Markman wrote: > thank you very much > > but windows's readme says: > rxtxSerial.dll had to be recomopiled to link in missing native methods. > > should I ignore it? or what? > Hi Dmitry That dll should be OK. r2 is the recompile linked to the missing native method. The readme explains why it was recompiled; fuser.o was not linked into the dll in the first release. -- Trent Jarvi tjarvi at qbang.org From ariantristan at yahoo.com Mon Mar 20 23:55:24 2006 From: ariantristan at yahoo.com (Lambok Sianturi) Date: Mon, 20 Mar 2006 22:55:24 -0800 (PST) Subject: [Rxtx] jvm issue Message-ID: <20060321065524.94779.qmail@web50701.mail.yahoo.com> Hi All, This is my first time to join RxTx mailing list. I thank you all for allowing others to sign in in requests help. I use the latest RxTx lib in Fedora 3 with java version 1.4.2_09 b05. And I got this error: # # An unexpected error has been detected by HotSpot Virtual Machine: # # SIGSEGV (0xb) at pc=0x00bf27f3, pid=2633, tid=3086112448 # # Java VM: Java HotSpot(TM) Client VM (1.4.2_09-b05 mixed mode) # Problematic frame: # C [ld-linux.so.2+0xa7f3] # # An error report file with more information is saved as hs_err_pid2633.log # # If you would like to submit a bug report, please visit: # http://java.sun.com/webapps/bugreport/crash.jsp # ./run.sh: line 3: 2633 Aborted /usr/local/java/bin/java -Djava.library.path=/usr/local/java/jre/lib/ -Djsmsengine.debug=true -classpath jsmsengine.jar:smsgateway.jar:classes12.jar:RXTXcomm.jar:. com.api.sms.SMSServer What is the jvm depedency for the latest library? Can I use 1.4.2_09 b05? Thanks in advance. Arian --------------------------------- Yahoo! Mail Use Photomail to share photos without annoying attachments. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060320/83d58dd7/attachment-0029.html From f.frumento at ngi.it Tue Mar 21 00:21:47 2006 From: f.frumento at ngi.it (Fabio Frumento) Date: Tue, 21 Mar 2006 08:21:47 +0100 Subject: [Rxtx] Javadoc on the go Message-ID: <441FA98B.9050701@ngi.it> Hi Trent, sorry for the big delay but my job is running wild, i was out for some time but now i'm back and ready to continue the javadoc for Rxtx. Did you used the last javadoc patch i sent you ? let me know if i have to send it to you again or not. regards Fabio From lyon at docjava.com Tue Mar 21 00:51:18 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Tue, 21 Mar 2006 02:51:18 -0500 Subject: [Rxtx] lock files Message-ID: Hi All, You know, if the use of lock files were under Java control (rather than a build-time decision), it might enable a more unified binary distro. It might also facilitate quick prototyping of non-lock file approaches to resolving serial port contention issues (i.e., mac-like approaches vs. linux approaches, etc.). I realize that this is a radical overhaul of the lock file policy issue. Also, it may harm performance. On the other hand, our benchmarks on JNI overhead for modern processors indicate performance impact should be minimal. Perhaps it is more of an issue with the toybox systems. Suppose there were a class with a reasonable default...someone might write: SerialPortLockPolicy.setPolicy(SerialPortLockPolicy.UNIX_LOCK_FILE); SerialPortLockPolicy.setPolicy(SerialPortLockPolicy.NO_LOCK_CHECKING); SerialPortLockPolicy.setPolicy(SerialPortLockPolicy.MAC_STYLE); Thus, we could have a run-time reconfiguration of the serial port lock policy. A special NO_LOCK version of the binary would no longer be required. Any thoughts on this? Thanks! - Doug From joachim at buechse.de Tue Mar 21 03:09:09 2006 From: joachim at buechse.de (Joachim Buechse) Date: Tue, 21 Mar 2006 11:09:09 +0100 Subject: [Rxtx] lock files In-Reply-To: References: Message-ID: <8E12916A-1B9A-4FF2-B684-E2D1C794221B@buechse.de> This is pretty much what I thought about when I suggested, that the default behaviour could be overwritten with a property. I am very much in favor of this approach. In particular this allows much easier debugging for PC based java developers. I think big parts of the Java (and maybe some parts of the C code) could use a bit of a structural workover (unit tests, javadoc, synchronization, etc). Maybe there should be a CVS branch for this experimental version. I'd be happy to contribute a first workover for some of the Java code. Designing for testability and implementing a good bunch of unit tests has been a strategy that worked quite well in the Java projects I lead. And it ultimately allows more liberal change permission. Regards, Joachim On 21.03.2006, at 08:51, Dr. Douglas Lyon wrote: > Hi All, > You know, if the use of lock files were > under Java control (rather than a build-time decision), > it might enable a more unified binary distro. It might also > facilitate quick prototyping of non-lock file approaches > to resolving serial port contention issues (i.e., mac-like > approaches vs. linux approaches, etc.). > > I realize that this is a radical overhaul of the lock file policy > issue. Also, it may harm performance. On the other hand, > our benchmarks on JNI overhead for modern processors indicate > performance impact should be minimal. Perhaps it is more of > an issue with the toybox systems. > > Suppose there were a class with a reasonable default...someone > might write: > SerialPortLockPolicy.setPolicy(SerialPortLockPolicy.UNIX_LOCK_FILE); > SerialPortLockPolicy.setPolicy(SerialPortLockPolicy.NO_LOCK_CHECKING); > SerialPortLockPolicy.setPolicy(SerialPortLockPolicy.MAC_STYLE); > > Thus, we could have a run-time reconfiguration of the serial port lock > policy. A special NO_LOCK version of the binary would no longer > be required. > > Any thoughts on this? > > Thanks! > - Doug > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From joachim at buechse.de Tue Mar 21 06:23:08 2006 From: joachim at buechse.de (Joachim Buechse) Date: Tue, 21 Mar 2006 14:23:08 +0100 Subject: [Rxtx] PATCH: use of ioctl(fd, TIOCEXCL) instead of lockfiles Message-ID: <923AE774-EEA2-4911-92D8-32BB27802C8B@buechse.de> Here is the patch for the ioctl(fd, TIOCEXCL). I have verified this only for OSX 10.4.5, hence it is only defined for APPLE. However, it should work at least for Solaris as well. If a process has requested TIOEXCL further open calls by other user processes will fail. The patch also disables uucp style locking for APPLE. Obviously this is discussable. I think it is the way to go, as it eliminates creating the lock directory which doesnt exist on the standard installation and it eliminates messing with the system group definitions (adding users to group uucp). Regarding the possibility of root processes opening a device which is locked - I consider this a feature not a potential problem. It is highly unlikely, that somebody is crazy enough to run a JavaVM as root (unless he has no other means of getting a restricted IP port opened, ie doesnt understand ipfw). Anyway, even if the process runs as root, it fails when calling ioctl(fd, TIOCEXCL). It could however still open the port to listen for RING events. I.e. a fax server which needs to see incoming calls but otherwise doesnt want to block the port. So the only case where the proposed mechanism fails is, if an incorrectly implemented process running as root conflicts with a user process. I think this can be accepted. Regards, Joachim PS: If this patch is generally accepted, the installer and Mac doku should obviously be changed as well. Index: SerialImp.c =================================================================== RCS file: /usr/local/cvsroot/rxtx-devel/src/SerialImp.c,v retrieving revision 1.46.2.187 diff -u -r1.46.2.187 SerialImp.c --- SerialImp.c 29 Jan 2006 22:19:04 -0000 1.46.2.187 +++ SerialImp.c 21 Mar 2006 12:59:16 -0000 @@ -656,6 +656,25 @@ fd=OPEN (filename, O_RDWR | O_NOCTTY | O_NONBLOCK ); } while (fd < 0 && errno==EINTR); +#ifdef OPEN_EXCL + // Note that open() follows POSIX semantics: multiple open() calls to + // the same file will succeed unless the TIOCEXCL ioctl is issued. + // This will prevent additional opens except by root-owned processes. + // See tty(4) ("man 4 tty") and ioctl(2) ("man 2 ioctl") for details. + + if (fd >= 0 && (ioctl(fd, TIOCEXCL) == -1)) + { + sprintf( message, "open: exclusive access denied for % s\n", + filename ); + report( message ); + report_error( message ); + + close(fd); + goto fail; + } +#endif /* OPEN_EXCL */ + + if( configure_port( fd ) ) goto fail; (*env)->ReleaseStringUTFChars( env, jstr, filename ); sprintf( message, "open: fd returned is %i\n", fd ); Index: SerialImp.h =================================================================== RCS file: /usr/local/cvsroot/rxtx-devel/src/SerialImp.h,v retrieving revision 1.11.2.49 diff -u -r1.11.2.49 SerialImp.h --- SerialImp.h 5 Jul 2005 17:47:21 -0000 1.11.2.49 +++ SerialImp.h 21 Mar 2006 12:59:17 -0000 @@ -135,7 +135,8 @@ /*# define LOCKDIR "/var/spool/uucp"*/ # define LOCKDIR "/var/lock" # define LOCKFILEPREFIX "LK." -# define UUCP +/*# define UUCP*/ +# define OPEN_EXCL #endif /* __APPLE__ */ #if defined(__NetBSD__) # define DEVICEDIR "/dev/" From tjarvi at qbang.org Tue Mar 21 10:26:08 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 21 Mar 2006 10:26:08 -0700 (MST) Subject: [Rxtx] Javadoc on the go In-Reply-To: <441FA98B.9050701@ngi.it> References: <441FA98B.9050701@ngi.it> Message-ID: On Tue, 21 Mar 2006, Fabio Frumento wrote: > Hi Trent, > > sorry for the big delay but my job is running wild, i was out for some > time but now i'm back and ready to continue the javadoc for Rxtx. > > Did you used the last javadoc patch i sent you ? let me know if i have to > send it to you again or not. > > regards > > Fabio Hi Fabio The patch is in the rxtx mail-list archives. It will be going in soon. I did not see a time critical portion. I'll probably be going through the list since the last batch of patches this weekend and putting them into CVS. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Tue Mar 21 10:57:18 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 21 Mar 2006 10:57:18 -0700 (MST) Subject: [Rxtx] jvm issue In-Reply-To: <20060321065524.94779.qmail@web50701.mail.yahoo.com> References: <20060321065524.94779.qmail@web50701.mail.yahoo.com> Message-ID: On Mon, 20 Mar 2006, Lambok Sianturi wrote: > Hi All, > This is my first time to join RxTx mailing list. I thank you all for allowing others to sign in in requests help. > I use the latest RxTx lib in Fedora 3 with java version 1.4.2_09 b05. And I got this error: > > # > # An unexpected error has been detected by HotSpot Virtual Machine: > # > # SIGSEGV (0xb) at pc=0x00bf27f3, pid=2633, tid=3086112448 > # > # Java VM: Java HotSpot(TM) Client VM (1.4.2_09-b05 mixed mode) > # Problematic frame: > # C [ld-linux.so.2+0xa7f3] A native library loading error? What happens if you recompile rxtx on your system and install that? This sounds like an ABI problem? rxtx 2.1-7 was compiled with a gcc 2.96 toolchain as I recall. The hope is newer system will be backwards compatible. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Tue Mar 21 11:05:29 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 21 Mar 2006 11:05:29 -0700 (MST) Subject: [Rxtx] PATCH: use of ioctl(fd, TIOCEXCL) instead of lockfiles In-Reply-To: <923AE774-EEA2-4911-92D8-32BB27802C8B@buechse.de> References: <923AE774-EEA2-4911-92D8-32BB27802C8B@buechse.de> Message-ID: On Tue, 21 Mar 2006, Joachim Buechse wrote: > Here is the patch for the ioctl(fd, TIOCEXCL). I have verified this only > for OSX 10.4.5, hence it is only defined for APPLE. However, it should > work at least for Solaris as well. > > If a process has requested TIOEXCL further open calls by other user > processes will fail. > > The patch also disables uucp style locking for APPLE. Obviously this is > discussable. I think it is the way to go, as it eliminates creating the > lock directory which doesnt exist on the standard installation and it > eliminates messing with the system group definitions (adding users to > group uucp). > > Regarding the possibility of root processes opening a device which is > locked - I consider this a feature not a potential problem. It is highly > unlikely, that somebody is crazy enough to run a JavaVM as root (unless > he has no other means of getting a restricted IP port opened, ie doesnt > understand ipfw). Anyway, even if the process runs as root, it fails when > calling ioctl(fd, TIOCEXCL). It could however still open the port to > listen for RING events. I.e. a fax server which needs to see incoming > calls but otherwise doesnt want to block the port. So the only case where > the proposed mechanism fails is, if an incorrectly implemented process > running as root conflicts with a user process. I think this can be > accepted. > > Regards, > Joachim > > PS: If this patch is generally accepted, the installer and Mac doku > should obviously be changed as well. > > > Index: SerialImp.c > =================================================================== > RCS file: /usr/local/cvsroot/rxtx-devel/src/SerialImp.c,v > retrieving revision 1.46.2.187 > diff -u -r1.46.2.187 SerialImp.c > --- SerialImp.c 29 Jan 2006 22:19:04 -0000 1.46.2.187 > +++ SerialImp.c 21 Mar 2006 12:59:16 -0000 > @@ -656,6 +656,25 @@ > fd=OPEN (filename, O_RDWR | O_NOCTTY | O_NONBLOCK ); > } while (fd < 0 && errno==EINTR); > > +#ifdef OPEN_EXCL > + // Note that open() follows POSIX semantics: multiple open() > calls to > + // the same file will succeed unless the TIOCEXCL ioctl is > issued. > + // This will prevent additional opens except by root-owned > processes. > + // See tty(4) ("man 4 tty") and ioctl(2) ("man 2 ioctl") for > details. > + > + if (fd >= 0 && (ioctl(fd, TIOCEXCL) == -1)) > + { > + sprintf( message, "open: exclusive access denied for % > s\n", > + filename ); > + report( message ); > + report_error( message ); > + > + close(fd); > + goto fail; > + } > +#endif /* OPEN_EXCL */ > + > + > if( configure_port( fd ) ) goto fail; > (*env)->ReleaseStringUTFChars( env, jstr, filename ); > sprintf( message, "open: fd returned is %i\n", fd ); > Index: SerialImp.h > =================================================================== > RCS file: /usr/local/cvsroot/rxtx-devel/src/SerialImp.h,v > retrieving revision 1.11.2.49 > diff -u -r1.11.2.49 SerialImp.h > --- SerialImp.h 5 Jul 2005 17:47:21 -0000 1.11.2.49 > +++ SerialImp.h 21 Mar 2006 12:59:17 -0000 > @@ -135,7 +135,8 @@ > /*# define LOCKDIR "/var/spool/uucp"*/ > # define LOCKDIR "/var/lock" > # define LOCKFILEPREFIX "LK." > -# define UUCP > +/*# define UUCP*/ > +# define OPEN_EXCL > #endif /* __APPLE__ */ > #if defined(__NetBSD__) > # define DEVICEDIR "/dev/" > This looks like a good start. What do you think Dmitry? Perhaps all systems with TIOCEXCL defined should use that though. Even if they use lockfiles. It wont hurt anything. That would catch people hacking their own serial apps without checking lockfiles. Its a good idea to avoid C++ style comments in the C portions. Some older systems don't deal with them well. If it's just for Mac OS X, it isn't a big deal. I think it was the Irix compiler that was problematic? -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Tue Mar 21 11:22:05 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 21 Mar 2006 11:22:05 -0700 (MST) Subject: [Rxtx] lock files In-Reply-To: <8E12916A-1B9A-4FF2-B684-E2D1C794221B@buechse.de> References: <8E12916A-1B9A-4FF2-B684-E2D1C794221B@buechse.de> Message-ID: We can try it. Maybe the JNI is much improved. The nice thing about linking into liblock is distros then worry about lockfiles on their systems. This way, we have to deal with any changes that may show up. On Tue, 21 Mar 2006, Joachim Buechse wrote: > This is pretty much what I thought about when I suggested, that the > default behaviour could be overwritten with a property. I am very much in > favor of this approach. In particular this allows much easier debugging > for PC based java developers. > > I think big parts of the Java (and maybe some parts of the C code) could > use a bit of a structural workover (unit tests, javadoc, synchronization, > etc). Maybe there should be a CVS branch for this experimental version. > I'd be happy to contribute a first workover for some of the Java code. > Designing for testability and implementing a good bunch of unit tests has > been a strategy that worked quite well in the Java projects I lead. And > it ultimately allows more liberal change permission. > > Regards, > Joachim > > > On 21.03.2006, at 08:51, Dr. Douglas Lyon wrote: > >> Hi All, >> You know, if the use of lock files were >> under Java control (rather than a build-time decision), >> it might enable a more unified binary distro. It might also >> facilitate quick prototyping of non-lock file approaches >> to resolving serial port contention issues (i.e., mac-like >> approaches vs. linux approaches, etc.). >> >> I realize that this is a radical overhaul of the lock file policy >> issue. Also, it may harm performance. On the other hand, >> our benchmarks on JNI overhead for modern processors indicate >> performance impact should be minimal. Perhaps it is more of >> an issue with the toybox systems. >> >> Suppose there were a class with a reasonable default...someone >> might write: >> SerialPortLockPolicy.setPolicy(SerialPortLockPolicy.UNIX_LOCK_FILE); >> SerialPortLockPolicy.setPolicy(SerialPortLockPolicy.NO_LOCK_CHECKING); >> SerialPortLockPolicy.setPolicy(SerialPortLockPolicy.MAC_STYLE); >> >> Thus, we could have a run-time reconfiguration of the serial port lock >> policy. A special NO_LOCK version of the binary would no longer >> be required. >> >> Any thoughts on this? >> >> Thanks! >> - Doug >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From dmarkman at mac.com Tue Mar 21 16:05:17 2006 From: dmarkman at mac.com (Dmitry Markman) Date: Tue, 21 Mar 2006 18:05:17 -0500 Subject: [Rxtx] PATCH: use of ioctl(fd, TIOCEXCL) instead of lockfiles In-Reply-To: References: <923AE774-EEA2-4911-92D8-32BB27802C8B@buechse.de> Message-ID: <512AC70C-BB86-48F2-A83C-023F35C23BAB@mac.com> I think it's cool, but I'd like to have that property implementation when user can choose between locking mechanism about comments: it's easy to change comments to the C style or we can use extensions of the file to cpp so c++ compiler will be used On Mar 21, 2006, at 1:05 PM, Trent Jarvi wrote: > This looks like a good start. What do you think Dmitry? Perhaps > all systems with TIOCEXCL defined should use that though. Even if > they use lockfiles. It wont hurt anything. That would catch > people hacking their own serial apps without checking lockfiles. > > Its a good idea to avoid C++ style comments in the C portions. > Some older systems don't deal with them well. If it's just for Mac > OS X, it isn't a big deal. I think it was the Irix compiler that > was problematic? Dmitry Markman From dmarkman at mac.com Tue Mar 21 16:13:00 2006 From: dmarkman at mac.com (Dmitry Markman) Date: Tue, 21 Mar 2006 18:13:00 -0500 Subject: [Rxtx] PATCH: use of ioctl(fd, TIOCEXCL) instead of lockfiles In-Reply-To: References: <923AE774-EEA2-4911-92D8-32BB27802C8B@buechse.de> Message-ID: I'd like to add that creating locking folder isn't a big deal we never had a problem related to the lock folders, because we always used installer on mac os x from other hand I'm not very much familiar with iotcl locking approach and I'm not sure it's more efficient Joachim wrote "I think it is the way to go, as it eliminates creating the lock directory which doesnt exist on the standard installation and it eliminates messing with the system group definitions (adding users to group uucp)." but I really didn't have any problem with that 1. doesn't exist on the standard installation there are many-many things that don't exist in the standard installation so I don't think that argument is strong enough 2. messing with the system group definitions I don't think we're messing with the group definition mac os x provides very clear way to set up group's members and together with Greg Guerin AuthKit there is no problem to set those definitions so I don't think that argument is strong either but from other hand using iotcl is more promising and is more elegant On Mar 21, 2006, at 1:05 PM, Trent Jarvi wrote: > > This looks like a good start. What do you think Dmitry? Perhaps > all systems with TIOCEXCL defined should use that though. Even if > they use lockfiles. It wont hurt anything. That would catch > people hacking their own serial apps without checking lockfiles. Dmitry Markman From joachim at buechse.de Wed Mar 22 04:46:45 2006 From: joachim at buechse.de (Joachim Buechse) Date: Wed, 22 Mar 2006 12:46:45 +0100 Subject: [Rxtx] PATCH: use of ioctl(fd, TIOCEXCL) instead of lockfiles In-Reply-To: References: <923AE774-EEA2-4911-92D8-32BB27802C8B@buechse.de> Message-ID: Sorry, I was not very clear with my arguments, so I will try again;-) Please, don't take this as an attack against work that has been done. I think the contributions that have been made in the past were made in a good spirit. But I really believe, that the current solution for OSX has many shortcomings and should be changed as soon as possible. lock files --- The /var/lock folder does not exist on the standard OSX installation, however the standard installation includes several applications that use serial ports (i.e. the FAX capability). This indicates, that the lock folder approach will not work well with system components. Applications for OSX will generally try to live in harmony with system components (except for HP print drivers of course). I think RXTX should follow this approach as well. uucp group --- Accessing serial ports is not an admin privileged operation on OSX. Any user (world) has read/write privileges on /dev/tty*. So the system default is to not enforce any group membership to access these ports. The group uucp however is a system group on all unix systems I know. It exists for certain system processes. A non admin user should in general not be a member of this group. Quite arguably no user should ever be a member of this group. Installer --- My general opinion is, that - no Installer should touch user or group data without warning - no Application Installer should touch groups which are not specific to the very application installed - no Installer should ever add regular users to a system group The current installer injects the installing user in the group uucp without warning about this change and without giving the option to "opt out" of this change. This is a potential security risk (but not currently a real one, as OSX contains no folders belonging to group uucp). The current installer does not work for multi user systems. It puts the installing user in the uucp group. However the installing user is not necessarily the user that will use the application. Putting all users that may use a serial port application in the system group uucp seems like a very invasive approach to me. Besides that, newly created users will not automatically be in the group and hence, serial applications will "break" for new users without obvious reasons. Avoiding the lock files will allow self contained applications (i.e. drag&drop installation). In my eyes this is largely preferable over an installer that requests admin privileges. Adding up all these points indicates very strongly, that the lock-file implementation is not the way to go on OSX. Regards, Joachim On 22.03.2006, at 00:13, Dmitry Markman wrote: > I'd like to add that > > creating locking folder isn't a big deal > we never had a problem related to the lock folders, because we > always used installer on mac os x > from other hand I'm not very much familiar with iotcl locking > approach and I'm not sure it's more efficient > > Joachim wrote "I think it is the way to go, as it eliminates > creating the lock directory which doesnt exist on the standard > installation and it eliminates messing with the system group > definitions (adding users to group uucp)." but I really didn't have > any problem with that > > 1. doesn't exist on the standard installation > there are many-many things that don't exist in the standard > installation so I don't think that argument is strong enough > 2. messing with the system group definitions > I don't think we're messing with the group definition > mac os x provides very clear way to set up group's members and > together with Greg Guerin AuthKit there is no problem to set those > definitions > so I don't think that argument is strong either > but from other hand using iotcl is more promising and is more elegant > > > > On Mar 21, 2006, at 1:05 PM, Trent Jarvi wrote: > >> >> This looks like a good start. What do you think Dmitry? Perhaps >> all systems with TIOCEXCL defined should use that though. Even if >> they use lockfiles. It wont hurt anything. That would catch >> people hacking their own serial apps without checking lockfiles. > > Dmitry Markman > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From dmarkman at mac.com Wed Mar 22 05:27:13 2006 From: dmarkman at mac.com (Dmitry Markman) Date: Wed, 22 Mar 2006 07:27:13 -0500 Subject: [Rxtx] PATCH: use of ioctl(fd, TIOCEXCL) instead of lockfiles In-Reply-To: References: <923AE774-EEA2-4911-92D8-32BB27802C8B@buechse.de> Message-ID: <83440CF3-DCD8-41C1-B941-F227232C27E3@mac.com> thanks for the very good explanation I didn't think that you were attacking any thing, so don't worry I just had feeling, that there were more aesthetic reasons for going to ioctl then real necessity now you explained everything quite well (BTW, asfar as I remember installer asks admin password so it wasn't quiet, but it really doesn't matter now) thanks On Mar 22, 2006, at 6:46 AM, Joachim Buechse wrote: > Sorry, I was not very clear with my arguments, so I will try again;-) > > Please, don't take this as an attack against work that has been > done. I think the contributions that have been made in the past > were made in a good spirit. But I really believe, that the current > solution for OSX has many shortcomings and should be changed as > soon as possible. > > lock files > --- > The /var/lock folder does not exist on the standard OSX > installation, however the standard installation includes several > applications that use serial ports (i.e. the FAX capability). This > indicates, that the lock folder approach will not work well with > system components. Applications for OSX will generally try to live > in harmony with system components (except for HP print drivers of > course). I think RXTX should follow this approach as well. > > uucp group > --- > Accessing serial ports is not an admin privileged operation on OSX. > Any user (world) has read/write privileges on /dev/tty*. So the > system default is to not enforce any group membership to access > these ports. The group uucp however is a system group on all unix > systems I know. It exists for certain system processes. A non admin > user should in general not be a member of this group. Quite > arguably no user should ever be a member of this group. > > Installer > --- > My general opinion is, that > - no Installer should touch user or group data without warning > - no Application Installer should touch groups which are not > specific to the very application installed > - no Installer should ever add regular users to a system group > > The current installer injects the installing user in the group uucp > without warning about this change and without giving the option to > "opt out" of this change. This is a potential security risk (but > not currently a real one, as OSX contains no folders belonging to > group uucp). > > The current installer does not work for multi user systems. It puts > the installing user in the uucp group. However the installing user > is not necessarily the user that will use the application. Putting > all users that may use a serial port application in the system > group uucp seems like a very invasive approach to me. Besides that, > newly created users will not automatically be in the group and > hence, serial applications will "break" for new users without > obvious reasons. > > > Avoiding the lock files will allow self contained applications > (i.e. drag&drop installation). In my eyes this is largely > preferable over an installer that requests admin privileges. Adding > up all these points indicates very strongly, that the lock-file > implementation is not the way to go on OSX. > > Regards, > Joachim > > > On 22.03.2006, at 00:13, Dmitry Markman wrote: > >> I'd like to add that >> >> creating locking folder isn't a big deal >> we never had a problem related to the lock folders, because we >> always used installer on mac os x >> from other hand I'm not very much familiar with iotcl locking >> approach and I'm not sure it's more efficient >> >> Joachim wrote "I think it is the way to go, as it eliminates >> creating the lock directory which doesnt exist on the standard >> installation and it eliminates messing with the system group >> definitions (adding users to group uucp)." but I really didn't >> have any problem with that >> >> 1. doesn't exist on the standard installation >> there are many-many things that don't exist in the standard >> installation so I don't think that argument is strong enough >> 2. messing with the system group definitions >> I don't think we're messing with the group definition >> mac os x provides very clear way to set up group's members and >> together with Greg Guerin AuthKit there is no problem to set those >> definitions >> so I don't think that argument is strong either >> but from other hand using iotcl is more promising and is more elegant >> >> >> >> On Mar 21, 2006, at 1:05 PM, Trent Jarvi wrote: >> >>> >>> This looks like a good start. What do you think Dmitry? Perhaps >>> all systems with TIOCEXCL defined should use that though. Even >>> if they use lockfiles. It wont hurt anything. That would catch >>> people hacking their own serial apps without checking lockfiles. >> >> Dmitry Markman >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx Dmitry Markman From lyon at docjava.com Wed Mar 22 06:12:18 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Wed, 22 Mar 2006 08:12:18 -0500 Subject: [Rxtx] sole of a new design pattern Message-ID: Hi All, I have been thinking about how we design the serial port software. I think we need a new design pattern. For lack of a better term, I shall call it: The Parametric Singleton Design Pattern By Douglas A. Lyon ABSTRACT The goal of the singleton design pattern is to make sure that there is one, and only one, instance of a given class. The goal of the parametric singleton design pattern is to make sure that there is one, and only one, instance of a given class with the given parametric values. We parametric singleton design pattern combines the singleton design pattern with a parameter that enables unique creation of instances of a class. These instances are cached. When a user asks for an instance with these parameters, the cache is checked. If the instance is in the cache, the instance is returned, otherwise it is created, added to the cache and then returned. We apply our parametric singleton design pattern to the retrieval of RMI registries bound to a given port. The goal of our system is to make sure that no two RMI registries are listening to the same socket and to make use of the RMI registries after they have been created. RMI registries are used in distributed computation. Introduction The singleton design pattern is meant to ensure that on a single instance of a class exists. It is also meant to provide a global point of access to it. The intent of the parametric singleton design pattern is to ensure that a class has only one instance for a given set of parameter values. It also provides a global point of access to it. Motivation A system cannot tolerate multiple instances of some classes with identical parameters. For example, you cannot have two instances making use of the same serial port, at the same time. You cannot have two instances that are trying to listen to the same socket connection. You cannot have two instances writing to the same file structure at the same time. As the operating system is often thought of as the arbiter of consumed resources (i.e., tape drives, serial ports, etc.) we frequently leave it to an operating system implementation to resolve these contention issues. Even for similar resources (like serial ports) there are few standards for handling contention. For example, serial ports on Linux are locked using a "/var/lock" file. POSIX, on the other hand, uses ioctl mechanisms to prevent contention. A better solution is to make a class that is responsible for keeping track of the instances created from the class. The class is declared final, so that it cannot be subclassed. The class also has a private constructor, so that other classes cannot instance it. The new design pattern is called the parametric singleton design pattern and it provides a way to access and create instances with given parameters. Applicability Use the Parametric Singleton Design Pattern when: 1. There must be exactly one instance of a class with the given parameters. 2. The instances must be accessible to clients from a well-known access point. Structure Insert UML diagram here. Participants The Parametric Singleton Clients that need instances 1. The Parametric Singleton defines an instance upon request from a client, if, and only if, the instance does not already exist. 2. The Parametric Singleton returns the instance to the client. 3. The Parametric Singleton is responsible for creating unique instances from given parameters. Collaborations Clients obtain a reference to a Parametric Singleton instance only through the parametric singleton design pattern. If the instance is left in an improper state (e.g., the serial port was left open) it is NOT the role of the Parametric Singleton Design Pattern to close the IO port. Nor is it the role of the Parametric Singleton Design Pattern to open the port. That role is delegate to some other part of the system. Further, it is not the role of the Parametric Singleton Design Pattern to check out resources. That is, multiple threads can have multiple references to the same resource at the same time. MUTEX locking is delegated to some other part of the system. Consequences The Parametric Singleton Design Pattern has several benefits: 1. Controlled access to parametrically defined instances. Since the Parametric Singleton class encapsulates its instances, there is control over how and when clients access it. 2. Reduced name space. The Parametric Singleton pattern avoids global variables that store instances created from the same parameter. Implementation Here are implementation issues to consider when using the Parametric Singleton pattern: 1. Unique mapping of parameters. The Parametric Singleton pattern requires that there be a mean to isomorphically map the parameter space into the instance space and back again. 2. Ensure unique instances. The Parametric Singleton pattern makes unique instances from parameters, and it does so only once. 3. Cache instances for fast retrieval. The Parametric Singleton pattern must be able to look up instances, given some set of parameters, and do so from some data structure. That is, there must be enough space to hold references to all the instances the program will need. Also, a mechanism is needed to look up and retrieve the instances quickly enough to satisfy the clients. Sample Code public final class ParametricSingletonRmiRegistry { private static Hashtable registry = new Hashtable(100); // use singleton pattern and??????????????????????????????????????????????? // prevent instantiation of RmiRegistryUtils.?????????????????????????????? private ParametricSingletonRmiRegistry() { } // the only instance of the Registry held by the RmiRegistryUtils?????????? public static void listNames(Integer port) { if (!isInCacheAndRunning(port)) return; Registry r = (Registry) registry.get(port); System.out.println("registry on port: " + port); System.out.println("registry: " + r); System.out.println("names: "); try { print(r.list()); } catch (RemoteException e) { In.message(e); } System.out.println("------------------------"); } /**???????????????????????????????????????????????????????????????????????? * Checks whether a Registry has been started on this host????????????????? * in the specified port.?????????????????????????????????????????????????? * If not, it tries to start one.?????????????????????????????????????????? * when it fails to start a Registry, it exits the program????????????????? * with exit code 1.??????????????????????????????????????????????????????? */ public static void restart(int port) { if (isInCacheAndRunning(port)) return; try { startRegistry(port); } catch (RemoteException e) { In.message(e); } } /**???????????????????????????????????????????????????????????????????????? * @param port????????????????????????????????????????????????????????????? * @return true if registry is in cache and running???????????????????????? */ private static boolean isInCacheAndRunning(Integer port) { if (!isRegistryRunning(port.intValue())) return false; if (!isRegistryInCache(port.intValue())) return false; return true; } /**???????????????????????????????????????????????????????????????????????? * @param port????????????????????????????????????????????????????????????? * @return true if we are able to locate a local registry on port.??????????????????????????????????????????????????????????????????????????? */ private static boolean isRegistryRunning(int port) { try { Registry r = LocateRegistry.getRegistry(port); if (r != null) return true; } catch (RemoteException e) { return false; } return false; } /**???????????????????????????????????????????????????????????????????????? * @param port????????????????????????????????????????????????????????????? * @return return true if registry is in cache????????????????????????????? */ private static boolean isRegistryInCache(int port) { if (registry.get(new Integer(port)) == null) return false; return true; } /**???????????????????????????????????????????????????????????????????????? * Restart the registry, if needed.???????????????????????????????????????? * Return the only instance of the registry for consistent global?????????? * using by making use of the Singleton Design Pattern????????????????????? *????????????????????????????????????????????????????????????????????????? * @return the internally held registry instance.?????????????????????????? */ public static Registry getRegistry(Integer port) { restart(port); return (Registry) registry.get(port); } private static void startRegistry(Integer port) throws RemoteException { Registry r; try { r = LocateRegistry.createRegistry(port.intValue()); registry.put(port, r); //r = new sun.rmi.registry.RegistryImpl???????????????????????????? /// (port.intValue());?????????????????????????????????????? // registry.put(port, r);?????????????????????????????????????????? } catch (Exception e) { //e.printStackTrace();????????????????????????????????????????????? r = LocateRegistry.getRegistry(port.intValue()); registry.put(port, r); } } public static void main(String args[]) throws RemoteException { //restart(port);??????????????????????????????????????????????????????? restart(5001); restart(5002); restart(5002); Registry r = LocateRegistry.getRegistry(5002); System.out.println("registry="+r); } } I would very much like to get your feedback on this new design pattern idea. Thank you for your time. Regards, - Doug From david.garnier at trusted-logic.com Wed Mar 22 07:36:10 2006 From: david.garnier at trusted-logic.com (David Garnier) Date: Wed, 22 Mar 2006 15:36:10 +0100 Subject: [Rxtx] sole of a new design pattern In-Reply-To: References: Message-ID: <442160DA.80107@trusted-logic.com> Hello, > The Parametric Singleton Design Pattern The Singleton is the most abused design pattern ever. Good use-cases for this pattern are extremely rare and mostly confined to problems related to hardware resources, like serial ports. > Applicability > > Use the Parametric Singleton Design Pattern when: > 1. There must be exactly one instance of a class with the given > parameters. OK. As I said above, this case this actually very unusual. The Singleton pattern is mostly used when : > 2. The instances must be accessible to clients from a well-known > access point. Using the singleton pattern in this case is just convenient for the programmer. Problems arises pretty quickly, especially if you attempt to unit-test your classes. 1) If your singleton is stateful, or hold on to stateful objects, it means that two different unit tests are not actually independent. Instead of starting with a brand new environment, the result of a test may be affected by the result of a previous test. This problem also arise when with your class relies on a database. In both cases, the solution is to reset your "unique" resource (Singleton or database) at the beginning of the test, which is a pain. Also, while most projects connect to a single database, projects that allow the use of Singletons usually contain several of thems, and new ones may cropped up unnoticed. You quickly end up with test cases that only pass in a certain order, which is a royal pain. 2) You cannot mockup a singleton. Once everyone calls the SomeSingleton class statically, you can't replace your class by SomeSingletonMockup. Furthermore, even for hardware services, the Singleton pattern does not really prevent concurrent accesses. If you start the same program in two different JVMs, unless they somehow shared the state of their "Singletons" (through lock files for example), the Singleton pattern will not prevent concurrent access. Our application uses RXTX, and we routinely encounter cases where another (native) application has already locked the port. Since we cannot modify the native application to recognize lock files, OS-level control is irreplaceable. > > Consequences > The Parametric Singleton Design Pattern has several benefits: > > 1. Controlled access to parametrically defined instances. Since > the Parametric Singleton class encapsulates its instances, there is > control over how and when clients access it. Not really. Once you've returned the instance to a client, you've lost control over it. The client can to whatever it wants with it. You cannot "recall" the instance or claim it back. > 2. Reduced name space. The Parametric Singleton pattern avoids > global variables that store instances created from the same parameter. Sure, but you don't have to rely on a Singleton for that. Just create a single Factory. > I would very much like to get your feedback on this new design > pattern idea. Well, it's nothing new. Some may say that it is the point of design patterns: formalizes the designs that occur again and again. However, this design is simply a combination of the Singleton and Factory patterns. I did use it in the past, but now I've been exposed to the shortcomings of the Singleton pattern, so I limit myself to Factories. Regards, David From sean_montgomery at baseview.com Wed Mar 22 08:35:28 2006 From: sean_montgomery at baseview.com (Sean Montgomery) Date: Wed, 22 Mar 2006 10:35:28 -0500 Subject: [Rxtx] sole of a new design pattern In-Reply-To: <442160DA.80107@trusted-logic.com> References: <442160DA.80107@trusted-logic.com> Message-ID: <05769CA7-A51B-4CF0-BAA0-E02DD905F5A4@baseview.com> On Mar 22, 2006, at 9:36 AM, David Garnier wrote: > Furthermore, even for hardware services, the Singleton pattern does > not really prevent concurrent > accesses. If you start the same program in two different JVMs, > unless they somehow shared the state > of their "Singletons" (through lock files for example), the > Singleton pattern will not prevent > concurrent access. > Multiple class loaders in a single JVM can be tricky, too. Then there's synchronization, lazy initialization and serialization of singletons to contend with. Bloch's Effective Java covers these, and here's a few articles: http://www.javaworld.com/javaworld/jw-04-2003/jw-0425-designpatterns- p3.html http://java.sun.com/developer/technicalArticles/Programming/singletons/ Just FYI :-) From lyon at docjava.com Wed Mar 22 08:50:48 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Wed, 22 Mar 2006 10:50:48 -0500 Subject: [Rxtx] sole of a new design pattern In-Reply-To: <442160DA.80107@trusted-logic.com> References: <442160DA.80107@trusted-logic.com> Message-ID: Hi All, First, I would like to thank David for his prompt and thoughtful remarks. I had no idea people that feel strongly about a design patterns! Wow! Feedback (particularly critical feedback) is greatly appreciated. Starting at the end, first: >I did use it in >the past, but now I've been exposed to the shortcomings of the >Singleton pattern, so I limit myself to Factories. David, if I understood your comments correctly, you suggested that Factories can be used in leu of the Singleton Design Pattern, or even the Parametric Singleton Design Pattern. As I see in [Gof]: Factory Method: Intent "Define an interface for creating an object, but let subclasses decide which class to instantiate. Factory Method lets a class defer instantiation to subclasses." The Singleton Design Pattern is a concrete class, which is rather different, right? Also, subclasses are not permitted with Singleton, as they are final. Naturally, I could use an abstract factory as a parent for a singleton. I could even design a facade that could be implemented with the singleton....but that is not the intention of the design. Unless you want a mock-up, as discussed, below: More below: >Hello, > >> The Parametric Singleton Design Pattern > >The Singleton is the most abused design pattern ever. Good use-cases >for this pattern are extremely >rare and mostly confined to problems related to hardware resources, >like serial ports. > > >> Applicability >> >> Use the Parametric Singleton Design Pattern when: >> 1. There must be exactly one instance of a class with the given >> parameters. >OK. As I said above, this case this actually very unusual. The >Singleton pattern is mostly used when : >> 2. The instances must be accessible to clients from a well-known >> access point. > >Using the singleton pattern in this case is just convenient for the >programmer. Problems arises >pretty quickly, especially if you attempt to unit-test your classes. > >1) If your singleton is stateful, or hold on to stateful objects, it >means that two different unit >tests are not actually independent. Instead of starting with a brand >new environment, the result of >a test may be affected by the result of a previous test. This >problem also arise when with your >class relies on a database. In both cases, the solution is to reset >your "unique" resource >(Singleton or database) at the beginning of the test, which is a >pain. Also, while most projects >connect to a single database, projects that allow the use of >Singletons usually contain several of >thems, and new ones may cropped up unnoticed. You quickly end up >with test cases that only pass in a >certain order, which is a royal pain. There are basic problems with communicating finite state machines that include reachability and deadlock analysis. These are addressed with petri net analysis and are beyond the scope of the design pattern. As you quite rightly pointed out; the parametric singleton pattern (or the singleton pattern, for that matter) enable multiple threads to gain access to the same instance. The only way that I can see to block others from gaining access to the reference is the synchronize keyword. This is putting a spin-lock (or MUTEX) on the reference. The question of how to unit-test a design pattern like the parametric singleton remains open. Perhaps this is a deficiency. > >2) You cannot mockup a singleton. Once everyone calls the >SomeSingleton class statically, you can't >replace your class by SomeSingletonMockup. Acutally, I am not sure that this is true. If the Singleton implements a Facade interface, it should be possible to make the replacement. Right? > >Furthermore, even for hardware services, the Singleton pattern does >not really prevent concurrent >accesses. If you start the same program in two different JVMs, >unless they somehow shared the state >of their "Singletons" (through lock files for example), the >Singleton pattern will not prevent >concurrent access. Good Point!! You have sharp eyes! The singleton design pattern should/could take responsibility for this. In fact, you may notice that my code does have an implementation (LocateRegistry) that can work across JVM's. The LocateRegistry will even work across the Internet! LocateRegistry takes both a host name and a Port (lock files just don't do this). I did not think to implement this beyond the local machine, but, in its present form, it will work across different processes. > >Our application uses RXTX, and we routinely encounter cases where >another (native) application has >already locked the port. Since we cannot modify the native >application to recognize lock files, >OS-level control is irreplaceable. The singleton design pattern is not meant to replace OS-level control, but to centralize the Java programmers access to it. If lock files, for example, are used for serial ports, the Singleton Design Pattern should be able to work with them. > > >> >> Consequences >> The Parametric Singleton Design Pattern has several benefits: >> > > 1. Controlled access to parametrically defined instances. Since >> the Parametric Singleton class encapsulates its instances, there is >> control over how and when clients access it. > >Not really. Once you've returned the instance to a client, you've >lost control over it. The client >can to whatever it wants with it. You cannot "recall" the instance >or claim it back. Good point, this should read: > 1. Controll when parametrically defined instances are created. Since > > the Parametric Singleton class encapsulates its instances, there is > > control over how and when they are instanced. > >> 2. Reduced name space. The Parametric Singleton pattern avoids >> global variables that store instances created from the same parameter. > >Sure, but you don't have to rely on a Singleton for that. Just >create a single Factory. > > Thank you for your thoughtful and prompt response! Regards, - Doug From dmarkman at mac.com Wed Mar 22 21:21:55 2006 From: dmarkman at mac.com (Dmitry Markman) Date: Wed, 22 Mar 2006 23:21:55 -0500 Subject: [Rxtx] sole of a new design pattern In-Reply-To: <442160DA.80107@trusted-logic.com> References: <442160DA.80107@trusted-logic.com> Message-ID: I don't think I get it On Mar 22, 2006, at 9:36 AM, David Garnier wrote: > Using the singleton pattern in this case is just convenient for the > programmer. Problems arises > pretty quickly, especially if you attempt to unit-test your classes. so you're saying that something isn't so good because you can not test it in the convenient way? if that's true, I'm totally disagree change your test, debug whatever, but if software is efficient at runtime, works fine and only problem is some unit test (which is some kind of framework for testing) then dump that unit test , dump that unit framework and make something appropriate to the software you're testing so if Douglas want to use singletons, what's the problem? and what do you mean by abusing of singleton usage? of course singleton doesn't prevent concurrent access to the resource across the processes unless you're using some OS facility to prevent it, besides singleton as it was introduced is relevant only and only inside of the same process otherwise it's not singleton it's something else (let's say network singleton: so you have remote invocation facility and some factory method that return object created by that facility) I don't have any problem with using any kind of singletons. Parametric Singleton idea (if I understand it right) could be easily implemented in the following way: use a map populate map with instances of some class and key is your parameter (you can use lazy population too) if somebody ask the key check the value if it's null so resource is taken if somebody returns the resource put it back to the map public synchronized static Object getSomeResource(Object parameter); public synchronized static void returnResource(Object parameter); getSomeResource (inside of the same process) could return null in 2 cases 1. if somebody (from other thread for example) already took that resource 2. if OS API said that resource corresponded to that parameter (serial port with parameter = 1 (port #)) is locked and unavailable; I'm not sure that in case of serial ports we even need those Parametric Singletons (unless lock checking is a very expensive operation) just ask the OS about availability of that resource and if it's available give it away and then OS will lock it and therefore in next time somebody ask it just answer that resource is locked and return null for example system has 2 serial ports available so I ask getResource("tty"); or I ask getResource("Bluetooth-Modem"); and if OS is ok you can give tty or Bluetooth-Modem or both no need for any additional pattern I think back to the problem mac os x doesn't recognize locking via files, so it handles locking via some API an instance of the singleton in each process should recognize that resource is locked (by using that API) that's all we don't have to make things more complicate then they are just because there is some nice design pattern or nice unit test framework or whatever keep things simple, make them work fast, don't introduce middle layers unless you have really good reason to do so of course I could be entirely wrong, so sorry about that in advance thanks Dmitry Markman From tjarvi at qbang.org Wed Mar 22 22:31:41 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 22 Mar 2006 22:31:41 -0700 (MST) Subject: [Rxtx] sole of a new design pattern In-Reply-To: References: Message-ID: Hi Doug Interesting reading. So far I'm just reading and thinking. I have one question so far. " Clients obtain a reference to a Parametric Singleton instance only through the parametric singleton design pattern. If the instance is left in an improper state (e.g., the serial port was left open) it is NOT the role of the Parametric Singleton Design Pattern to close the IO port. Nor is it the role of the Parametric Singleton Design Pattern to open the port. That role is delegate to some other part of the system. " So when the clients obtain a reference to the singleton, can they assume the port is there? IE, would it be the singletons role to handle things like USB dongles being removed with event hints comming from the underlying OS. Hardware abstraction layer/HAL on Linux is an example of underlying OS events. I assume that role too is delegated to other parts of the system? -- Trent Jarvi tjarvi at qbang.org From lyon at docjava.com Thu Mar 23 08:10:33 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Thu, 23 Mar 2006 10:10:33 -0500 Subject: [Rxtx] Classes don't need goals, they need roles! In-Reply-To: References: Message-ID: Hi Trent, Yes, I think that the role of the Parametric Singleton Pattern is not to open or close serial ports, nor is it to perform error checking. On the other hand, if you were to combine the role of the Parametric Singleton Pattern with another role (like that of error checking) it might not be amiss. However, I generally caution programmers against adding multiple roles to classes, as this leads to monolithic designs. Thus a different class (NativeLibDetect) could have the role of determining if the native library can be loaded. Another class (SerialPortBean) can have the role of serializing the default state of the serial port, so that it can be recovered, from user preferences, at a later time. The SerialPortDetect could have the role of determining if the serial port is removed (i.e., a USB port was unplugged). My guess is that each class should have a different role in the system, in order to ease maintenance and testing...but I could be wrong about that. Thanks! - Doug >Hi Doug > >Interesting reading. So far I'm just reading and thinking. I have >one question so far. > >" > Clients obtain a reference to a Parametric Singleton instance only >through the parametric singleton design pattern. If the instance is >left in an improper state (e.g., the serial port was left open) it is >NOT the role of the Parametric Singleton Design Pattern to close the >IO port. Nor is it the role of the Parametric Singleton Design Pattern >to >open the port. That role is delegate to some other part of the system. >" > >So when the clients obtain a reference to the singleton, can they >assume the port is there? IE, would it be the singletons role to >handle things like USB dongles being removed with event hints >comming from the underlying OS. Hardware abstraction layer/HAL on >Linux is an example of underlying OS events. > >I assume that role too is delegated to other parts of the system? > >-- >Trent Jarvi >tjarvi at qbang.org >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From maximulo at yahoo.com Fri Mar 24 01:22:38 2006 From: maximulo at yahoo.com (Maximulo Majir) Date: Fri, 24 Mar 2006 00:22:38 -0800 (PST) Subject: [Rxtx] JavaPOS Message-ID: <20060324082238.66371.qmail@web38214.mail.mud.yahoo.com> Hi all! Hello Trent! From what i understand, RXTX or JavaComm APIs were not created solely for JavaPOS. In JavaPOS, we have the virtual method claim() which is separate from open(), but in our RXTX API, claiming is done every call to open(), we cant open the port if its claimed by another application. Would it be alright to suggest or ask to create a new method called claim(..)? Is there such thing as forceclaim() in RXTX? this could be the same as portownership transfer or its equivalent. ForceClaim is in JSR80. Do you have some samples using RXTX as the lower layer for the Device Service Objects in JavaPOS? I have tried it, i just want to compare. Thank you all! maxim __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060324/496adba2/attachment-0029.html From tjarvi at qbang.org Fri Mar 24 11:28:19 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 24 Mar 2006 11:28:19 -0700 (MST) Subject: [Rxtx] Re: RXTX 2.1 Solaris Problems In-Reply-To: <3691.1143210578@www045.gmx.net> References: <3691.1143210578@www045.gmx.net> Message-ID: On Fri, 24 Mar 2006, Andreas Guenther wrote: > Hi all, > > the solaris problem was not the lock file only. > > Ok, I had to create the directory /var/spool/locks myself. > /var/spool/uucp exists. > > But rxtx didn't find any port. > > I compiled the source with my own debug-informations > and I tried to isolate the problem. > > The problem is the testRead-call in SerialImp.c > > JNIEXPORT jboolean JNICALL RXTXCommDriver(testRead)( > > ... > if ( READ( fd, &c, 1 ) < 0 ) > { > if ( errno != EAGAIN ) { > report( "testRead() read failed\n" ); > ret = JNI_FALSE; > } > } > Thanks Andreas I'm packing up to move. I'll be more or less away for a couple weeks here. I'll be checking email but my workstation is going into a box soon. This isn't hard to fix as this port should be enumerated when EWOULDBLOCK is recieved. Thats error is OK for enumeration just as EAGAIN is. I've put the bug into bugzilla so we dont forget to get to it. http://bugzilla.qbang.org/show_bug.cgi?id=42 You can add yourself to the CC list if you wish to test fixes we provide or even put a patch into bugzilla yourself. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Fri Mar 24 11:51:52 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 24 Mar 2006 11:51:52 -0700 (MST) Subject: [Rxtx] JavaPOS In-Reply-To: <20060324082238.66371.qmail@web38214.mail.mud.yahoo.com> References: <20060324082238.66371.qmail@web38214.mail.mud.yahoo.com> Message-ID: On Fri, 24 Mar 2006, Maximulo Majir wrote: > Hi all! Hello Trent! > > > From what i understand, RXTX or JavaComm APIs were not > created solely for JavaPOS. In JavaPOS, we have the virtual method > claim() which is separate from open(), but in our RXTX API, claiming is > done every call to open(), we cant open the port if its claimed by > another application. Would it be alright to suggest or ask to create a > new method called claim(..)? Is there such thing as forceclaim() in > RXTX? this could be the same as portownership transfer or its > equivalent. ForceClaim is in JSR80. > Do you have some samples using RXTX as the lower layer for the Device > Service Objects in JavaPOS? I have tried it, i just want to compare. > maxim Hi Maxim JSR80 is the USB API IBM/Sun put together. The problem is they have a richer kernel/API underneath that can handle such things. With Serial Ports, there isnt anything there other than an ioctl that says don't let anyone touch this and lockfiles that are more of a 'lets be nice.' At times we may be using USB ports but it is through the termios layer with the limitations mentioned. The advantage is that not only USB will work with rxtx. Anything that has a termios layer should work (to the extent that termios layer is complete). I don't know how forceclaim() would help you. Lets say someone has a programmer working on /dev/ttyS0 and you take it. Now you both race each other to read data first. There isn't a mechanism I know of that will solve this problem in termios. The most obvious test being a native app and a Java app trying to take the port. There is the potential of requestion ownership from other Java Applications but the use for that is very rare. Did you have something more specific in mind that I'm missing? I'm not sure that claim() and forceclaim() would help you with rxtx other than maybe locking the port with claim() without opening it. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sat Mar 25 23:42:08 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 25 Mar 2006 23:42:08 -0700 (MST) Subject: [Rxtx] Serial snoop Message-ID: I was reading the Linux kernel mail-list tonight and ran past a thread that mentioned sersnoop. This looks like a handy tool for people dealing with new toys. "a simple command-line tool for linux that echoes bytes to and from any two serial ports, ptys, or network sockets, and prints all traffic to stdout, in hex and ascii." http://www.restivo.org/projects/sersnoop/ It works on Linux only at this time (debian package available). -- Trent Jarvi tjarvi at qbang.org From beat.arnet at gmail.com Sun Mar 26 07:32:35 2006 From: beat.arnet at gmail.com (Beat Arnet) Date: Sun, 26 Mar 2006 09:32:35 -0500 Subject: [Rxtx] Error 0x5 at /home/bob/foo/tar/rxtx-2.1-7/build/../src/termios.c(860): Access is, denied. Message-ID: <4426A603.80508@gmail.com> Dear all, When trying to open the serial port, I sometimes (not always) run into the following exception (when opening the serialPort): Error 0x5 at /home/bob/foo/tar/rxtx-2.1-7/build/../src/termios.c(860): Access is denied. java.lang.UnsatisfiedLinkError: native_psmisc_report_owner at gnu.io.CommPortIdentifier.native_psmisc_report_owner(Native Method) at gnu.io.CommPortIdentifier.open(CommPortIdentifier.java:354) at codeskin.tools.CLLoader.open(CLLoader.java:79) at codeskin.tools.C2000Programmer.run(C2000Programmer.java:220) at java.lang.Thread.run(Unknown Source) Is this the type of error where I should just try to open the port again, or can it be avoided? Regards, Beat From tjarvi at qbang.org Sun Mar 26 11:40:12 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 26 Mar 2006 11:40:12 -0700 (MST) Subject: [Rxtx] Error 0x5 at /home/bob/foo/tar/rxtx-2.1-7/build/../src/termios.c(860): Access is, denied. In-Reply-To: <4426A603.80508@gmail.com> References: <4426A603.80508@gmail.com> Message-ID: On Sun, 26 Mar 2006, Beat Arnet wrote: > Dear all, > > When trying to open the serial port, I sometimes (not always) run into > the following exception (when opening the serialPort): > > Error 0x5 at /home/bob/foo/tar/rxtx-2.1-7/build/../src/termios.c(860): > Access is > denied. > > java.lang.UnsatisfiedLinkError: native_psmisc_report_owner > at gnu.io.CommPortIdentifier.native_psmisc_report_owner(Native > Method) > at gnu.io.CommPortIdentifier.open(CommPortIdentifier.java:354) > at codeskin.tools.CLLoader.open(CLLoader.java:79) > at codeskin.tools.C2000Programmer.run(C2000Programmer.java:220) > at java.lang.Thread.run(Unknown Source) > > Is this the type of error where I should just try to open the port again, > or can it be avoided? > Hi Beat We did a second build of rxtx 2.1-7 to resolve that unsatisfied link error. It should work now. rxtx is trying to tell you it thinks someone else has the serial port open. You can try to open the port again but maybe you already have a copy of the program running when it happens? ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7r2.zip fixed build. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sun Mar 26 11:44:23 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 26 Mar 2006 11:44:23 -0700 (MST) Subject: [Rxtx] RXTX spec file (fwd) Message-ID: This is probably interesting for fedora/suse users. ---------- Forwarded message ---------- Date: Sun, 26 Mar 2006 16:25:45 +0200 To: taj at www.linux.org.uk Subject: RXTX spec file I send you this spec file which allows to create a RPM for Fedora 4, 5 (x86, x86_64) with Java Sun. -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: rxtx.spec Url: http://mailman.qbang.org/pipermail/rxtx/attachments/20060326/6c7b6af6/rxtx-0025.pl From tjarvi at qbang.org Sun Mar 26 23:42:59 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 26 Mar 2006 23:42:59 -0700 (MST) Subject: [Rxtx] Upcomming events. Message-ID: This Wednesday we will be announcing a new "Maintainer" for the rxtx project. The position is more like neutral leader. I wont be going away or doing less. This is just the right thing to do as it turns out the two people with CVS write access will be at the same company. We need a third and we need neutrality. The maintainer will have final say in any conflict and will try to be neutral. It will be open for discussion. Then we will do it :) I'll still do most of the footwork I do now. But. I'm falling behind. I should have gone through the mail-list and posted the next round of changes this weekend. I'm packing to move and its going so so - 13 years of toys collected. I suspect there will be a dead period on my part (a couple weeks) comming up. But if you get it on the mail-list, we will get it in if there are no objections. I may well not be reading the mail-list during this period as I look for a house and many other things. I hope everyone will help out. Thanks -- Trent Jarvi tjarvi at qbang.org From mahmoud_hadad at yahoo.com Sun Mar 26 07:31:19 2006 From: mahmoud_hadad at yahoo.com (ronan nick) Date: Sun, 26 Mar 2006 06:31:19 -0800 (PST) Subject: [Rxtx] a question about the COMM API Message-ID: <20060326143119.54919.qmail@web60014.mail.yahoo.com> hi, i was intrested in knowing how i can communicate with my internal modem using java? for example if i want to make a phone dialer application or a caller id application where should i be looking at? and as i understood the COMM API is for devices that is attached to the computer through serial ports. --------------------------------- New Yahoo! Messenger with Voice. Call regular phones from your PC and save big. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060326/ce8329f0/attachment-0027.html From dmarkman at mac.com Mon Mar 20 00:20:43 2006 From: dmarkman at mac.com (Dmitry Markman) Date: Mon, 20 Mar 2006 02:20:43 -0500 Subject: [Rxtx] Mac OS X RXTX java installer In-Reply-To: References: <07D0DE29-BA32-4CFE-B036-66BC6423D385@buechse.de> <441AE3E0.2030503@willicon.de> <12531986.1142622114996.JavaMail.dmarkman@mac.com> <441B2674.9010409@willicon.de> <13577405.1142634732776.JavaMail.dmarkman@mac.com> <441B4182.8010407@willicon.de> <92CD0D6C-5BE8-426E-A46D-99452059FF49@mac.com> <441BBB2D.8030305@willicon.de> <441C4088.5090905@willicon.de> Message-ID: <64BC1E23-FDDE-4CE6-8863-CFC881CBC224@mac.com> Hi all I put RXTX installer that will install everything (and will create / var/lock if necessary and add user to the uucp group) for mac os x from Java into the rxtx's CVS repository it could be easily modified to install files for any platform it uses Greg Guerin's AuthKit for authentication and authorization Greg released that kit under artistic license, so Trent, please take a look we, probably, can negotiate license with Greg if it's necessary Greg's AuthKit could be downloaded from http://www.amug.org/~glguerin/ sw/#authkit Michael Hall (mikehall at spacestar dot net) had a suggestion to make implementation of the jaas LoginModule based on Greg's AuthKit (his modification of the Greg's AuthKit could be found at http:// www.spacestar.net/users/mikehall/authkit.dmg) but Michael's AuthKitLoginModule does only half a job: it does authenticate but it can not run any external unix process in privileged mode (at least I wasn't able to do so) possible explanation could be found in conversation between Greg and Michael at Apple's java-dev list (look for archives) so I didn't use jaas API for rxtxinstaller I created folder MacOSX in the contrib folder comment 1. if you want to run that installer as standalone application all you need that RXTXInstaller.jar 2. if you want to use webstart you have to add Greg's libAuthKit.jnilib to the mac os x's resources in theory RXTXInstaller.jar doesn't need it, but there is a problem with loading libAuthKit.jnilib from webstart authkit uses loadLibrary method to load library and it failed (from webstart) for standalone application I extract libAuthKit.jnilib from the RXTXInstaller.jar and put it into the /Library/Java/Extensions or ~/Library/Java/Extensions folder that file will be deleted after installer quit unfortunately I didn't have time to put documentation there but it is mostly self-explanatory I took installer code from my gl4java installer that I did about 3 years ago (with small modifications) it would be very nice if Apple will release LoginModule that really will do the job (com.apple.security.auth.module package????? ) (UnixLoginModule is pretty useless) From lyon at docjava.com Mon Mar 20 06:34:39 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Mon, 20 Mar 2006 08:34:39 -0500 Subject: [Rxtx] Mac OS X RXTX java installer In-Reply-To: <64BC1E23-FDDE-4CE6-8863-CFC881CBC224@mac.com> References: <07D0DE29-BA32-4CFE-B036-66BC6423D385@buechse.de> <441AE3E0.2030503@willicon.de> <12531986.1142622114996.JavaMail.dmarkman@mac.com> <441B2674.9010409@willicon.de> <13577405.1142634732776.JavaMail.dmarkman@mac.com> <441B4182.8010407@willicon.de> <92CD0D6C-5BE8-426E-A46D-99452059FF49@mac.com> <441BBB2D.8030305@willicon.de> <441C4088.5090905@willicon.de> <64BC1E23-FDDE-4CE6-8863-CFC881CBC224@mac.com> Message-ID: Hi Dimitry, This sounds like great work. Just a couple of questions; After the check out of the CVS files, using: setenv CVSROOT :pserver:anonymous at cvs.milestonesolutions.com:/usr/local/cvsroot 53 8:28 setenv PASSWORD mousy 54 8:29 cvs login 55 8:29 cvs checkout rxtx-devel I cd'd over to: rxtx-devel/MACOSX_IDE And found: CVS/ CW/ ForPackageMaker/ PB/ Where is the installer? Thanks! - Doug From tjarvi at qbang.org Mon Mar 20 06:39:37 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 20 Mar 2006 06:39:37 -0700 (MST) Subject: [Rxtx] Mac OS X RXTX java installer In-Reply-To: References: <07D0DE29-BA32-4CFE-B036-66BC6423D385@buechse.de> <441AE3E0.2030503@willicon.de> <12531986.1142622114996.JavaMail.dmarkman@mac.com> <441B2674.9010409@willicon.de> <13577405.1142634732776.JavaMail.dmarkman@mac.com> <441B4182.8010407@willicon.de> <92CD0D6C-5BE8-426E-A46D-99452059FF49@mac.com> <441BBB2D.8030305@willicon.de> <441C4088.5090905@willicon.de> <64BC1E23-FDDE-4CE6-8863-CFC881CBC224@mac.com> Message-ID: On Mon, 20 Mar 2006, Dr. Douglas Lyon wrote: > Hi Dimitry, > This sounds like great work. Just a couple of questions; > After the check out of the CVS files, using: > setenv CVSROOT > :pserver:anonymous at cvs.milestonesolutions.com:/usr/local/cvsroot > 53 8:28 setenv PASSWORD mousy > 54 8:29 cvs login > 55 8:29 cvs checkout rxtx-devel Hi Doug You want "cvs checkout -r commapi-0-0-1 rxtx-devel" to get RXTX 2.1 The default branch is rxtx 2.0 which isn't very active right now. -- Trent Jarvi tjarvi at qbang.org From lyon at docjava.com Mon Mar 20 07:05:44 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Mon, 20 Mar 2006 09:05:44 -0500 Subject: [Rxtx] Mac OS X RXTX java installer In-Reply-To: References: <07D0DE29-BA32-4CFE-B036-66BC6423D385@buechse.de> <441AE3E0.2030503@willicon.de> <12531986.1142622114996.JavaMail.dmarkman@mac.com> <441B2674.9010409@willicon.de> <13577405.1142634732776.JavaMail.dmarkman@mac.com> <441B4182.8010407@willicon.de> <92CD0D6C-5BE8-426E-A46D-99452059FF49@mac.com> <441BBB2D.8030305@willicon.de> <441C4088.5090905@willicon.de> <64BC1E23-FDDE-4CE6-8863-CFC881CBC224@mac.com> Message-ID: Hi Trent, Thanks for the info on the CVS checkout procedure. I did that and am still not sure where the installer is. Here is what I have: cd MACOSX_IDE/ p4.docjava.com{lyon}121: ls CVS/ ForPackageMaker/ PB/ p4.docjava.com{lyon}122: find . | more . ./ForPackageMaker ./ForPackageMaker/RXTX.pkg.sit.hqx ./ForPackageMaker/Resources ./ForPackageMaker/Resources/ReadMe.rtf ./ForPackageMaker/Resources/Welcome.rtf ./ForPackageMaker/Resources/CVS ./ForPackageMaker/Resources/CVS/Entries ./ForPackageMaker/Resources/CVS/Repository ./ForPackageMaker/Resources/CVS/Tag ./ForPackageMaker/Resources/CVS/Root ./ForPackageMaker/Resources/preinstall ./ForPackageMaker/Resources/License.rtf ./ForPackageMaker/Resources/preupgrade ./ForPackageMaker/RXTX.pmsp ./ForPackageMaker/CVS ./ForPackageMaker/CVS/Entries ./ForPackageMaker/CVS/Repository ./ForPackageMaker/CVS/Entries.Log ./ForPackageMaker/CVS/Tag ./ForPackageMaker/CVS/Root ./ForPackageMaker/RXTX_Tiger.pkg.sitx.hqx ./ForPackageMaker/RXTX_Jag.pkg.sit.hqx ./ForPackageMaker/Install ./ForPackageMaker/Install/CVS ./ForPackageMaker/Install/CVS/Entries ./ForPackageMaker/Install/CVS/Repository ./ForPackageMaker/Install/CVS/Tag ./ForPackageMaker/Install/CVS/Root ./ForPackageMaker/Install/Library ./ForPackageMaker/Install/Library/CVS ./ForPackageMaker/Install/Library/CVS/Entries ./ForPackageMaker/Install/Library/CVS/Repository ./ForPackageMaker/Install/Library/CVS/Tag ./ForPackageMaker/Install/Library/CVS/Root ./ForPackageMaker/Install/Library/Java ./ForPackageMaker/Install/Library/Java/Extensions ./ForPackageMaker/Install/Library/Java/Extensions/RXTXcomm.jar ./ForPackageMaker/Install/Library/Java/Extensions/CVS ./ForPackageMaker/Install/Library/Java/Extensions/CVS/Entries ./ForPackageMaker/Install/Library/Java/Extensions/CVS/Repository ./ForPackageMaker/Install/Library/Java/Extensions/CVS/Tag ./ForPackageMaker/Install/Library/Java/Extensions/CVS/Root ./ForPackageMaker/Install/Library/Java/Extensions/librxtxSerial.jnilib ./ForPackageMaker/Install/Library/Java/CVS ./ForPackageMaker/Install/Library/Java/CVS/Entries ./ForPackageMaker/Install/Library/Java/CVS/Repository ./ForPackageMaker/Install/Library/Java/CVS/Entries.Log ./ForPackageMaker/Install/Library/Java/CVS/Tag ./ForPackageMaker/Install/Library/Java/CVS/Root ./ForPackageMaker/RXTX_Tiger.pmproj.sitx.hqx ./CVS ./CVS/Entries ./CVS/Repository ./CVS/Entries.Log ./CVS/Tag ./CVS/Root ./PB ./PB/LibSerialUniversal.xcodeproj.sitx.hqx ./PB/CVS ./PB/CVS/Entries ./PB/CVS/Repository ./PB/CVS/Entries.Log ./PB/CVS/Tag ./PB/CVS/Root ./PB/LibSerial.pbproj.sit.hqx ./PB/startpoint.c ./PB/config.h What is the procedure to run this installer? Do we need a README in: /rxtx-devel/MACOSX_IDE Here is what we have: CVS/ ForPackageMaker/ PB/ Thanks! - DL >On Mon, 20 Mar 2006, Dr. Douglas Lyon wrote: > >>Hi Dimitry, >>This sounds like great work. Just a couple of questions; >>After the check out of the CVS files, using: >>setenv CVSROOT >>:pserver:anonymous at cvs.milestonesolutions.com:/usr/local/cvsroot >> 53 8:28 setenv PASSWORD mousy >> 54 8:29 cvs login >> 55 8:29 cvs checkout rxtx-devel > >Hi Doug > >You want "cvs checkout -r commapi-0-0-1 rxtx-devel" to get RXTX 2.1 >The default branch is rxtx 2.0 which isn't very active right now. > >-- >Trent Jarvi >tjarvi at qbang.org From tjarvi at qbang.org Mon Mar 20 07:25:30 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 20 Mar 2006 07:25:30 -0700 (MST) Subject: [Rxtx] Mac OS X RXTX java installer In-Reply-To: References: <07D0DE29-BA32-4CFE-B036-66BC6423D385@buechse.de> <441AE3E0.2030503@willicon.de> <12531986.1142622114996.JavaMail.dmarkman@mac.com> <441B2674.9010409@willicon.de> <13577405.1142634732776.JavaMail.dmarkman@mac.com> <441B4182.8010407@willicon.de> <92CD0D6C-5BE8-426E-A46D-99452059FF49@mac.com> <441BBB2D.8030305@willicon.de> <441C4088.5090905@willicon.de> <64BC1E23-FDDE-4CE6-8863-CFC881CBC224@mac.com> Message-ID: On Mon, 20 Mar 2006, Dr. Douglas Lyon wrote: > Hi Trent, > Thanks for the info on the CVS checkout procedure. > I did that and am still not sure where the installer is. Hi Doug It does look like it was not cvs committed. There is no rxtx-devel/contrib/MacOSX directory in there at the moment. It was mentioned that it was put under contrib. -- Trent Jarvi tjarvi at qbang.org From dmarkman at mac.com Mon Mar 20 07:29:56 2006 From: dmarkman at mac.com (Dmitry Markman) Date: Mon, 20 Mar 2006 09:29:56 -0500 Subject: [Rxtx] Mac OS X RXTX java installer In-Reply-To: References: <07D0DE29-BA32-4CFE-B036-66BC6423D385@buechse.de> <441AE3E0.2030503@willicon.de> <12531986.1142622114996.JavaMail.dmarkman@mac.com> <441B2674.9010409@willicon.de> <13577405.1142634732776.JavaMail.dmarkman@mac.com> <441B4182.8010407@willicon.de> <92CD0D6C-5BE8-426E-A46D-99452059FF49@mac.com> <441BBB2D.8030305@willicon.de> <441C4088.5090905@willicon.de> <64BC1E23-FDDE-4CE6-8863-CFC881CBC224@mac.com> Message-ID: <6054EB4E-F7E0-4A9C-BDDA-D582D6D8826F@mac.com> you can find it in the rxtx-devel/contrib folder On Mar 20, 2006, at 9:05 AM, Dr. Douglas Lyon wrote: > Hi Trent, > Thanks for the info on the CVS checkout procedure. > I did that and am still not sure where the installer is. > Here is what I have: > cd MACOSX_IDE/ > p4.docjava.com{lyon}121: ls > CVS/ ForPackageMaker/ PB/ > p4.docjava.com{lyon}122: find . | more > . > ./ForPackageMaker > ./ForPackageMaker/RXTX.pkg.sit.hqx > ./ForPackageMaker/Resources > ./ForPackageMaker/Resources/ReadMe.rtf > ./ForPackageMaker/Resources/Welcome.rtf > ./ForPackageMaker/Resources/CVS > ./ForPackageMaker/Resources/CVS/Entries > ./ForPackageMaker/Resources/CVS/Repository > ./ForPackageMaker/Resources/CVS/Tag > ./ForPackageMaker/Resources/CVS/Root > ./ForPackageMaker/Resources/preinstall > ./ForPackageMaker/Resources/License.rtf > ./ForPackageMaker/Resources/preupgrade > ./ForPackageMaker/RXTX.pmsp > ./ForPackageMaker/CVS > ./ForPackageMaker/CVS/Entries > ./ForPackageMaker/CVS/Repository > ./ForPackageMaker/CVS/Entries.Log > ./ForPackageMaker/CVS/Tag > ./ForPackageMaker/CVS/Root > ./ForPackageMaker/RXTX_Tiger.pkg.sitx.hqx > ./ForPackageMaker/RXTX_Jag.pkg.sit.hqx > ./ForPackageMaker/Install > ./ForPackageMaker/Install/CVS > ./ForPackageMaker/Install/CVS/Entries > ./ForPackageMaker/Install/CVS/Repository > ./ForPackageMaker/Install/CVS/Tag > ./ForPackageMaker/Install/CVS/Root > ./ForPackageMaker/Install/Library > ./ForPackageMaker/Install/Library/CVS > ./ForPackageMaker/Install/Library/CVS/Entries > ./ForPackageMaker/Install/Library/CVS/Repository > ./ForPackageMaker/Install/Library/CVS/Tag > ./ForPackageMaker/Install/Library/CVS/Root > ./ForPackageMaker/Install/Library/Java > ./ForPackageMaker/Install/Library/Java/Extensions > ./ForPackageMaker/Install/Library/Java/Extensions/RXTXcomm.jar > ./ForPackageMaker/Install/Library/Java/Extensions/CVS > ./ForPackageMaker/Install/Library/Java/Extensions/CVS/Entries > ./ForPackageMaker/Install/Library/Java/Extensions/CVS/Repository > ./ForPackageMaker/Install/Library/Java/Extensions/CVS/Tag > ./ForPackageMaker/Install/Library/Java/Extensions/CVS/Root > ./ForPackageMaker/Install/Library/Java/Extensions/librxtxSerial.jnilib > ./ForPackageMaker/Install/Library/Java/CVS > ./ForPackageMaker/Install/Library/Java/CVS/Entries > ./ForPackageMaker/Install/Library/Java/CVS/Repository > ./ForPackageMaker/Install/Library/Java/CVS/Entries.Log > ./ForPackageMaker/Install/Library/Java/CVS/Tag > ./ForPackageMaker/Install/Library/Java/CVS/Root > ./ForPackageMaker/RXTX_Tiger.pmproj.sitx.hqx > ./CVS > ./CVS/Entries > ./CVS/Repository > ./CVS/Entries.Log > ./CVS/Tag > ./CVS/Root > ./PB > ./PB/LibSerialUniversal.xcodeproj.sitx.hqx > ./PB/CVS > ./PB/CVS/Entries > ./PB/CVS/Repository > ./PB/CVS/Entries.Log > ./PB/CVS/Tag > ./PB/CVS/Root > ./PB/LibSerial.pbproj.sit.hqx > ./PB/startpoint.c > ./PB/config.h > > What is the procedure to run this installer? > Do we need a README in: > /rxtx-devel/MACOSX_IDE > Here is what we have: > CVS/ ForPackageMaker/ PB/ > > > Thanks! > - DL > >> On Mon, 20 Mar 2006, Dr. Douglas Lyon wrote: >> >>> Hi Dimitry, >>> This sounds like great work. Just a couple of questions; >>> After the check out of the CVS files, using: >>> setenv CVSROOT :pserver:anonymous at cvs.milestonesolutions.com:/usr/ >>> local/cvsroot >>> 53 8:28 setenv PASSWORD mousy >>> 54 8:29 cvs login >>> 55 8:29 cvs checkout rxtx-devel >> >> Hi Doug >> >> You want "cvs checkout -r commapi-0-0-1 rxtx-devel" to get RXTX 2.1 >> The default branch is rxtx 2.0 which isn't very active right now. >> >> -- >> Trent Jarvi >> tjarvi at qbang.org > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx Dmitry Markman From mikehall at spacestar.net Mon Mar 20 05:25:25 2006 From: mikehall at spacestar.net (Michael Hall) Date: Mon, 20 Mar 2006 06:25:25 -0600 Subject: [Rxtx] Re: Mac OS X RXTX java installer In-Reply-To: <64BC1E23-FDDE-4CE6-8863-CFC881CBC224@mac.com> References: <07D0DE29-BA32-4CFE-B036-66BC6423D385@buechse.de> <441AE3E0.2030503@willicon.de> <12531986.1142622114996.JavaMail.dmarkman@mac.com> <441B2674.9010409@willicon.de> <13577405.1142634732776.JavaMail.dmarkman@mac.com> <441B4182.8010407@willicon.de> <92CD0D6C-5BE8-426E-A46D-99452059FF49@mac.com> <441BBB2D.8030305@willicon.de> <441C4088.5090905@willicon.de> <64BC1E23-FDDE-4CE6-8863-CFC881CBC224@mac.com> Message-ID: <247EB61F-5CD1-4132-89A2-FC105B6CF9A5@spacestar.net> On Mar 20, 2006, at 1:20 AM, Dmitry Markman wrote: > > Michael Hall (mikehall at spacestar dot net) had a suggestion to > make implementation of the jaas LoginModule > based on Greg's AuthKit > (his modification of the Greg's AuthKit could be found at http:// > www.spacestar.net/users/mikehall/authkit.dmg) > but Michael's AuthKitLoginModule does only half a job: > it does authenticate > but it can not run any external unix process in privileged mode (at > least I wasn't able to do so) If you got it working directly with Greg's the point is moot. But to clarify it anyhow. The login module does not allow you to do anything anything privileged on return as was explained by Greg. You need to work with a separate privileged process using the execPrivileged method of his API. I assume you did something similar although I haven't looked at how you are using it yet. I allowed instead for a action to be performed at the same time you login/authenticate,this... System.setProperty("authkit.action","/usr/bin/id"); just before this... lc.login(); To clarify, safely ignored as you are already complete. Mike Hall mikehall at spacestar dot net http://www.spacestar.net/users/mikehall http://sourceforge.net/projects/macnative -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2427 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20060320/f6e18202/smime-0030.bin From dmarkman at mac.com Mon Mar 20 07:36:47 2006 From: dmarkman at mac.com (Dmitry Markman) Date: Mon, 20 Mar 2006 09:36:47 -0500 Subject: [Rxtx] Re: Mac OS X RXTX java installer In-Reply-To: <247EB61F-5CD1-4132-89A2-FC105B6CF9A5@spacestar.net> References: <07D0DE29-BA32-4CFE-B036-66BC6423D385@buechse.de> <441AE3E0.2030503@willicon.de> <12531986.1142622114996.JavaMail.dmarkman@mac.com> <441B2674.9010409@willicon.de> <13577405.1142634732776.JavaMail.dmarkman@mac.com> <441B4182.8010407@willicon.de> <92CD0D6C-5BE8-426E-A46D-99452059FF49@mac.com> <441BBB2D.8030305@willicon.de> <441C4088.5090905@willicon.de> <64BC1E23-FDDE-4CE6-8863-CFC881CBC224@mac.com> <247EB61F-5CD1-4132-89A2-FC105B6CF9A5@spacestar.net> Message-ID: Hi, Michael all I have to do is to run some shell script I tried to use your action mechanism and it worked great so I just System.setProperty ("authkit.action","" ) and after that I even don't need to run anything like subject.doAs.... but after few thoughts I choose to use plain Greg's approach, because in that case I don't have to deal with various java's configurations files and therefore to use 2-3 -D parameters in the java command line especially it's useful for java web start (it's so fragile :-( ) thanks for the great job On Mar 20, 2006, at 7:25 AM, Michael Hall wrote: > > On Mar 20, 2006, at 1:20 AM, Dmitry Markman wrote: >> >> Michael Hall (mikehall at spacestar dot net) had a suggestion to >> make implementation of the jaas LoginModule >> based on Greg's AuthKit >> (his modification of the Greg's AuthKit could be found at http:// >> www.spacestar.net/users/mikehall/authkit.dmg) >> but Michael's AuthKitLoginModule does only half a job: >> it does authenticate >> but it can not run any external unix process in privileged mode >> (at least I wasn't able to do so) > > If you got it working directly with Greg's the point is moot. > > But to clarify it anyhow. > The login module does not allow you to do anything anything > privileged on return as was explained by Greg. You need to work > with a separate privileged process using the execPrivileged method > of his API. I assume you did something similar although I haven't > looked at how you are using it yet. > I allowed instead for a action to be performed at the same time you > login/authenticate,this... > System.setProperty("authkit.action","/usr/bin/id"); > just before this... > lc.login(); > To clarify, safely ignored as you are already complete. > > Mike Hall mikehall at spacestar dot net > http://www.spacestar.net/users/mikehall > http://sourceforge.net/projects/macnative > > > Dmitry Markman From dmarkman at mac.com Mon Mar 20 07:44:45 2006 From: dmarkman at mac.com (Dmitry Markman) Date: Mon, 20 Mar 2006 09:44:45 -0500 Subject: [Rxtx] Mac OS X RXTX java installer In-Reply-To: References: <07D0DE29-BA32-4CFE-B036-66BC6423D385@buechse.de> <441AE3E0.2030503@willicon.de> <12531986.1142622114996.JavaMail.dmarkman@mac.com> <441B2674.9010409@willicon.de> <13577405.1142634732776.JavaMail.dmarkman@mac.com> <441B4182.8010407@willicon.de> <92CD0D6C-5BE8-426E-A46D-99452059FF49@mac.com> <441BBB2D.8030305@willicon.de> <441C4088.5090905@willicon.de> <64BC1E23-FDDE-4CE6-8863-CFC881CBC224@mac.com> Message-ID: it's in the commapi-0-0-1 branch I tested it right now: cvs co -r commapi-0-0-1 rxtx-devel and I got everything On Mar 20, 2006, at 9:25 AM, Trent Jarvi wrote: > On Mon, 20 Mar 2006, Dr. Douglas Lyon wrote: > >> Hi Trent, >> Thanks for the info on the CVS checkout procedure. >> I did that and am still not sure where the installer is. > > Hi Doug > > It does look like it was not cvs committed. There is no rxtx-devel/ > contrib/MacOSX directory in there at the moment. It was mentioned > that it was put under contrib. > > -- > Trent Jarvi > tjarvi at qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx Dmitry Markman From tjarvi at qbang.org Mon Mar 20 07:52:57 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 20 Mar 2006 07:52:57 -0700 (MST) Subject: [Rxtx] Mac OS X RXTX java installer In-Reply-To: References: <07D0DE29-BA32-4CFE-B036-66BC6423D385@buechse.de> <441AE3E0.2030503@willicon.de> <12531986.1142622114996.JavaMail.dmarkman@mac.com> <441B2674.9010409@willicon.de> <13577405.1142634732776.JavaMail.dmarkman@mac.com> <441B4182.8010407@willicon.de> <92CD0D6C-5BE8-426E-A46D-99452059FF49@mac.com> <441BBB2D.8030305@willicon.de> <441C4088.5090905@willicon.de> <64BC1E23-FDDE-4CE6-8863-CFC881CBC224@mac.com> Message-ID: On Mon, 20 Mar 2006, Dmitry Markman wrote: > it's in the commapi-0-0-1 branch > > I tested it right now: > cvs co -r commapi-0-0-1 rxtx-devel > > and I got everything > A fresh checkout worked. Here is a copy of the tree (just the installer bits) ftp://ftp.qbang.org/pub/rxtx/MacOSX-installer.zip -- Trent Jarvi tjarvi at qbang.org From lyon at docjava.com Mon Mar 20 08:08:26 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Mon, 20 Mar 2006 10:08:26 -0500 Subject: [Rxtx] Mac OS X RXTX java installer In-Reply-To: References: <07D0DE29-BA32-4CFE-B036-66BC6423D385@buechse.de> <441AE3E0.2030503@willicon.de> <12531986.1142622114996.JavaMail.dmarkman@mac.com> <441B2674.9010409@willicon.de> <13577405.1142634732776.JavaMail.dmarkman@mac.com> <441B4182.8010407@willicon.de> <92CD0D6C-5BE8-426E-A46D-99452059FF49@mac.com> <441BBB2D.8030305@willicon.de> <441C4088.5090905@willicon.de> <64BC1E23-FDDE-4CE6-8863-CFC881CBC224@mac.com> Message-ID: Hi All, Is the Auth package able to work properly on non Mac OS's? It was not clear from the doc or download. Thanks! - Doug From dmarkman at mac.com Mon Mar 20 08:15:22 2006 From: dmarkman at mac.com (Dmitry Markman) Date: Mon, 20 Mar 2006 10:15:22 -0500 Subject: [Rxtx] Mac OS X RXTX java installer In-Reply-To: References: <07D0DE29-BA32-4CFE-B036-66BC6423D385@buechse.de> <441AE3E0.2030503@willicon.de> <12531986.1142622114996.JavaMail.dmarkman@mac.com> <441B2674.9010409@willicon.de> <13577405.1142634732776.JavaMail.dmarkman@mac.com> <441B4182.8010407@willicon.de> <92CD0D6C-5BE8-426E-A46D-99452059FF49@mac.com> <441BBB2D.8030305@willicon.de> <441C4088.5090905@willicon.de> <64BC1E23-FDDE-4CE6-8863-CFC881CBC224@mac.com> Message-ID: <217312D8-CCCA-4859-ABA6-32DF1CC817B9@mac.com> thanks Trent, for putting it on ftp server On Mar 20, 2006, at 9:52 AM, Trent Jarvi wrote: > A fresh checkout worked. Here is a copy of the tree (just the > installer bits) > > ftp://ftp.qbang.org/pub/rxtx/MacOSX-installer.zip > Dmitry Markman From dmarkman at mac.com Mon Mar 20 09:14:03 2006 From: dmarkman at mac.com (Dmitry Markman) Date: Mon, 20 Mar 2006 11:14:03 -0500 Subject: [Rxtx] Mac OS X RXTX java installer In-Reply-To: References: <07D0DE29-BA32-4CFE-B036-66BC6423D385@buechse.de> <441AE3E0.2030503@willicon.de> <12531986.1142622114996.JavaMail.dmarkman@mac.com> <441B2674.9010409@willicon.de> <13577405.1142634732776.JavaMail.dmarkman@mac.com> <441B4182.8010407@willicon.de> <92CD0D6C-5BE8-426E-A46D-99452059FF49@mac.com> <441BBB2D.8030305@willicon.de> <441C4088.5090905@willicon.de> <64BC1E23-FDDE-4CE6-8863-CFC881CBC224@mac.com> Message-ID: <4DEBA6F0-DA45-4E84-823E-1F1AC48BDCCC@mac.com> no it will work only on mac os x however it's harmless to run it on other platform if you want to use it for other platform you have to do the following (I'll do it for linux) 1. modify RXTXInstaller class method public static RXTXInstaller getInstance() public static RXTXInstaller getInstance() { String osName = System.getProperty("os.name").toLowerCase(); if(osName.startsWith("mac")){ return new gnu.io.installer.macosx.MACOSXRXTXInstaller(); } else if(osName.startsWith("windows")){ return new gnu.io.installer.windows.WindowsRXTXInstaller(); }else if(osName.startsWith("linux")){ return new gnu.io.installer.linux.LinuxRXTXInstaller(); } return null; } 2. create folder gnu/io/installer/linux/ 3. create class Linux386RXTXInstaller package gnu.io.installer.linux; import java.io.File; public class Linux386RXTXInstaller extends gnu.io.installer.RXTXInstaller{ public Linux386RXTXInstaller(){ createJarFolder(); createLibFolder(); addJarResource("RXTXcomm.jar","/gnu/io/installer/resources/ linux/jar/RXTXcomm.dat"); addLibResource("librxtxSerial.so","/gnu/io/installer/ resources/linux/lib/librxtxSerial.so"); } protected void createJarFolder(){ String javaHome = System.getProperty("java.home"); char separator = File.separatorChar; jarFolder = new File(javaHome+separator+"lib"+separator+"ext"); } protected void createLibFolder(){ String javaHome = System.getProperty("java.home"); char separator = File.separatorChar; libFolder = new File(javaHome+separator+"bin"); } public void runPreProcess() {} //put here some action you need public void runPostProcess() {} //put here some action you need } 4. create folder /gnu/io/installer/resources/linux/jar and put there linux's version of RXTXcomm.dat (which is renamed RXTXcomm.jar) 5. create folder /gnu/io/installer/resources/linux/lib and put there linux's version of librxtxSerial. so 6. make sure that RXTXInstaller.jar has the following items: /gnu/io/installer/resources/linux/jar/RXTXcomm.jar /gnu/io/installer/resources/linux/lib/librxtxSerial.so 7. modify file installer.pref: jar file RXTXInstaller.jar must have the following item /gnu/io/installer/installer.pref that's basically it for windows you have to do the similar things: just replace linux to windows and librxtxSerial.so to rxtxSerial.dll and create appropriate gnu.io.installer.windows.WindowsRXTXInstaller class package gnu.io.installer.windows; import java.io.File; public class WindowsRXTXInstaller extends gnu.io.installer.RXTXInstaller{ public WindowsRXTXInstaller(){ createJarFolder(); createLibFolder(); addJarResource("RXTXcomm.jar","/gnu/io/installer/resources/ windows/jar/RXTXcomm.dat"); addLibResource("librxtxSerial.so","/gnu/io/installer/ resources/windows/lib/rxtxSerial.dll"); } protected void createJarFolder(){ String javaHome = System.getProperty("java.home"); char separator = File.separatorChar; jarFolder = new File(javaHome+separator+"lib"+separator+"ext"); } protected void createLibFolder(){ String javaHome = System.getProperty("java.home"); char separator = File.separatorChar; libFolder = new File(javaHome+separator+"bin"); } public void runPreProcess() {} //put here some action you need public void runPostProcess() {} //put here some action you need } installer.pref will look like On Mar 20, 2006, at 10:08 AM, Dr. Douglas Lyon wrote: > Hi All, > Is the Auth package able to work properly on > non Mac OS's? > It was not clear from the doc or download. > > Thanks! > - Doug > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx Dmitry Markman From joachim at buechse.de Mon Mar 20 10:49:06 2006 From: joachim at buechse.de (Joachim Buechse) Date: Mon, 20 Mar 2006 18:49:06 +0100 Subject: [Rxtx] BUG: Lock file stays even if port opening fails Message-ID: This was only tested on MacOSX but looking at the code, it should be true for all systems that use lock_uucp. I am opening a port which can not be opened (dialup port of a telephone paired via bluetooth but currently not reachable). The lock file is created and stays arround, even though the port open failed. After looking a bit through the code (of 2.17), I really wonder if it wouldn't be a good idea to make the "locking" an explicit operation called from the java code. This would certainly simplify the generation of meaningfull exceptions (and java based debugging). Maybe even the handling of "preopened" ports should be in the Java part of the lib (again for java based debugging puposes). That beeing said, I have no idea if this would be possible for the 2.07 implementation. Regards, Joachim From tjarvi at qbang.org Mon Mar 20 11:24:22 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 20 Mar 2006 11:24:22 -0700 (MST) Subject: [Rxtx] BUG: Lock file stays even if port opening fails In-Reply-To: References: Message-ID: On Mon, 20 Mar 2006, Joachim Buechse wrote: > This was only tested on MacOSX but looking at the code, it should be true > for all systems that use lock_uucp. > > I am opening a port which can not be opened (dialup port of a telephone > paired via bluetooth but currently not reachable). The lock file is > created and stays arround, even though the port open failed. > > > After looking a bit through the code (of 2.17), I really wonder if it > wouldn't be a good idea to make the "locking" an explicit operation > called from the java code. This would certainly simplify the generation > of meaningfull exceptions (and java based debugging). > Maybe even the handling of "preopened" ports should be in the Java part > of the lib (again for java based debugging puposes). That beeing said, I > have no idea if this would be possible for the 2.07 implementation. > > Regards, Hi Joachim It should be possible in the 2.0-7 implementation too. The calls to RXTXPort.java would not change. We would just do more there Moving more of that logic into Java would be better as many people don't like to look at C code. There is a liblockdev on most Linux distros that can do most of the C code and would be easier to use. The problem is embeded devices will not have that library. The preopened port code has not been really tested. That was a last minute request in a product cycle. I expect it will be tested this year though. As I recall, some devices really do not like CD raising on open. The preopened ports then allow people to mess around in java without power cycling the devices or losing data. -- Trent Jarvi tjarvi at qbang.org From joachim at buechse.de Mon Mar 20 12:01:08 2006 From: joachim at buechse.de (Joachim Buechse) Date: Mon, 20 Mar 2006 20:01:08 +0100 Subject: [Rxtx] BUG: Lock file stays even if port opening fails In-Reply-To: References: Message-ID: Hi Trent, What is your general feeling about moving code to Java? The last days I have been reading quite a bit of the code and there are several things, that might not work as expected. I'll give you two examples from is_device_locked: if LOCKDIR == /var/spool/locks the directory /var/spool/lock will not be checked. LOCKDIR is not checked for lockfiles with unexpected pefixes While these things have probably never been discovered in production, they are still possibly incorrect implementations. If it was Java code, I would write some unit tests producing the errors that could later be corrected. PS: One could imagine to actually implement the whole lockfile handling in Java using some native routines to get the values required (pid, st_dev, st_rdev, ...). On 20.03.2006, at 19:24, Trent Jarvi wrote: > On Mon, 20 Mar 2006, Joachim Buechse wrote: > >> This was only tested on MacOSX but looking at the code, it should >> be true for all systems that use lock_uucp. >> >> I am opening a port which can not be opened (dialup port of a >> telephone paired via bluetooth but currently not reachable). The >> lock file is created and stays arround, even though the port open >> failed. >> >> >> After looking a bit through the code (of 2.17), I really wonder if >> it wouldn't be a good idea to make the "locking" an explicit >> operation called from the java code. This would certainly simplify >> the generation of meaningfull exceptions (and java based debugging). >> Maybe even the handling of "preopened" ports should be in the Java >> part of the lib (again for java based debugging puposes). That >> beeing said, I have no idea if this would be possible for the 2.07 >> implementation. >> >> Regards, > > Hi Joachim > > It should be possible in the 2.0-7 implementation too. The calls > to RXTXPort.java would not change. We would just do more there > Moving more of that logic into Java would be better as many people > don't like to look at C code. There is a liblockdev on most Linux > distros that can do most of the C code and would be easier to use. > The problem is embeded devices will not have that library. > > The preopened port code has not been really tested. That was a > last minute request in a product cycle. I expect it will be tested > this year though. As I recall, some devices really do not like CD > raising on open. The preopened ports then allow people to mess > around in java without power cycling the devices or losing data. > > -- > Trent Jarvi > tjarvi at qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Mon Mar 20 12:21:02 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 20 Mar 2006 12:21:02 -0700 (MST) Subject: [Rxtx] BUG: Lock file stays even if port opening fails In-Reply-To: References: Message-ID: On Mon, 20 Mar 2006, Joachim Buechse wrote: > Hi Trent, > > What is your general feeling about moving code to Java? The last days I > have been reading quite a bit of the code and there are several things, > that might not work as expected. > > I'll give you two examples from is_device_locked: > > if LOCKDIR == /var/spool/locks the directory /var/spool/lock will not be > checked. > LOCKDIR is not checked for lockfiles with unexpected pefixes > > While these things have probably never been discovered in production, > they are still possibly incorrect implementations. If it was Java code, I > would write some unit tests producing the errors that could later be > corrected. > > PS: One could imagine to actually implement the whole lockfile handling > in Java using some native routines to get the values required (pid, > st_dev, st_rdev, ...). Hi Joachim I like the idea of moving more of the code into java but there are some things to consider. If you break this into multiple JNI calls, the performance will drop considerably during enumeration of ports. We are looking for 256 ports per dev type vs (16? in Sun's 2.0 and fewer types). Its hard to make assumptions. I've seen virtual ports start at /dev/foo100 for instance. It works out to over 7500 ports on Linux if you enable them all. We already trim that back by default. See Linux-all-ports in RXTXCommDriver.java. There are also native libraries that rxtx can link to. If you move too much into Java, linking to 'standard' libraries with distros will break. "configure --enable-liblock=yes" will not be doable. This is probably a favorable way with RedHat, Debian, Suse and others. Thats the right thing to do if there will be rpms, dpkg, .. For those reasons, I think it still make sense to keep it to a minimal ~3 calls to JNI code that we can use for speed and versatility. lock() isLocked(), unlock() perhaps. When I say speed, its more about avoiding crossing the JNI layer multiple times than java vs C performance. With versatility I think liblock is the right way for most but not all (embeded) linux distros. -- Trent Jarvi tjarvi at qbang.org From joachim at buechse.de Mon Mar 20 12:42:04 2006 From: joachim at buechse.de (Joachim Buechse) Date: Mon, 20 Mar 2006 20:42:04 +0100 Subject: [Rxtx] BUG: Lock file stays even if port opening fails In-Reply-To: References: Message-ID: <82C19FE7-DDCB-45B6-B2C9-7606B66F0124@buechse.de> Ok, what about providing a default implementation in Java? The RXTXCommDriver would call a (native) function useNativeLocking and if it returns true, call the native functions for lock() isLocked (), unlock(), else is would use the Java based default implementation. This could possibly be overriden by a property (again for debugging). Joachim On 20.03.2006, at 20:21, Trent Jarvi wrote: > On Mon, 20 Mar 2006, Joachim Buechse wrote: > >> Hi Trent, >> >> What is your general feeling about moving code to Java? The last >> days I have been reading quite a bit of the code and there are >> several things, that might not work as expected. >> >> I'll give you two examples from is_device_locked: >> >> if LOCKDIR == /var/spool/locks the directory /var/spool/lock will >> not be checked. >> LOCKDIR is not checked for lockfiles with unexpected pefixes >> >> While these things have probably never been discovered in >> production, they are still possibly incorrect implementations. If >> it was Java code, I would write some unit tests producing the >> errors that could later be corrected. >> >> PS: One could imagine to actually implement the whole lockfile >> handling in Java using some native routines to get the values >> required (pid, st_dev, st_rdev, ...). > > Hi Joachim > > I like the idea of moving more of the code into java but there are > some things to consider. > > If you break this into multiple JNI calls, the performance will > drop considerably during enumeration of ports. We are looking for > 256 ports per dev type vs (16? in Sun's 2.0 and fewer types). Its > hard to make assumptions. I've seen virtual ports start at /dev/ > foo100 for instance. > > It works out to over 7500 ports on Linux if you enable them all. > We already trim that back by default. See Linux-all-ports in > RXTXCommDriver.java. > > There are also native libraries that rxtx can link to. If you move > too much into Java, linking to 'standard' libraries with distros > will break. "configure --enable-liblock=yes" will not be doable. > This is probably a favorable way with RedHat, Debian, Suse and > others. Thats the right thing to do if there will be rpms, dpkg, .. > > For those reasons, I think it still make sense to keep it to a > minimal ~3 calls to JNI code that we can use for speed and > versatility. lock() isLocked(), unlock() perhaps. When I say > speed, its more about avoiding crossing the JNI layer multiple > times than java vs C performance. With versatility I think liblock > is the right way for most but not all (embeded) linux distros. > > -- > Trent Jarvi > tjarvi at qbang.org > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Mon Mar 20 12:44:47 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 20 Mar 2006 12:44:47 -0700 (MST) Subject: [Rxtx] BUG: Lock file stays even if port opening fails In-Reply-To: <82C19FE7-DDCB-45B6-B2C9-7606B66F0124@buechse.de> References: <82C19FE7-DDCB-45B6-B2C9-7606B66F0124@buechse.de> Message-ID: On Mon, 20 Mar 2006, Joachim Buechse wrote: > Ok, what about providing a default implementation in Java? > > The RXTXCommDriver would call a (native) function useNativeLocking and if > it returns true, call the native functions for lock() isLocked(), > unlock(), else is would use the Java based default implementation. This > could possibly be overriden by a property (again for debugging). > Hi Joachim That would be OK with me. -- Trent Jarvi tjarvi at qbang.org From dmarkman at mac.com Mon Mar 20 22:27:45 2006 From: dmarkman at mac.com (Dmitry Markman) Date: Tue, 21 Mar 2006 00:27:45 -0500 Subject: [Rxtx] binaries request Message-ID: <42702213-C222-4937-A585-7CFB17E47608@mac.com> Hi can somebody send me latest linux and windows binaries, please? or where I can find them (I didn't find them in the latest tareball) I gave up with my cygwin: something wrong I have no idea what java doesn't understand /cygwin/c syntax after I changed makefile it did java part but after that gcc 3.4.4 started to complain I set buffer length to 999 lines but I didn't get beginning of the story something wrong with my 1.4.2_09/include/jni.h gcc doesn't like it anyway I gave up thanks in advance Dmitry Markman -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060320/f8cbc57c/attachment-0030.html From tjarvi at qbang.org Mon Mar 20 22:36:48 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 20 Mar 2006 22:36:48 -0700 (MST) Subject: [Rxtx] binaries request In-Reply-To: <42702213-C222-4937-A585-7CFB17E47608@mac.com> References: <42702213-C222-4937-A585-7CFB17E47608@mac.com> Message-ID: On Tue, 21 Mar 2006, Dmitry Markman wrote: > Hi > can somebody send me latest linux and windows binaries, please? > > or where I can find them (I didn't find them in the latest tareball) > > I gave up with my cygwin: something wrong I have no idea what > java doesn't understand /cygwin/c syntax > after I changed makefile it did java part > but after that gcc 3.4.4 started to complain > I set buffer length to 999 lines but I didn't get beginning of the story > something wrong with my 1.4.2_09/include/jni.h gcc doesn't like it > anyway I gave up > > thanks in advance > Hi Dmitry The bins are here: ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7-bins-r2.zip Here are the files in the zip you want. Jar: rxtx-2.1-7-bins-r2/RXTXcomm.jar Windows: rxtx-2.1-7-bins-r2/Windows/i368-mingw32/rxtxSerial.dll Linux (x86) rxtx-2.1-7-bins-r2/Linux/i686-unknown-linux-gnu/librxtxSerial.so There are others in there including Parallel port support but those are the main ones for testing. -- Trent Jarvi tjarvi at qbang.org From dmarkman at mac.com Mon Mar 20 23:05:59 2006 From: dmarkman at mac.com (Dmitry Markman) Date: Tue, 21 Mar 2006 01:05:59 -0500 Subject: [Rxtx] binaries request In-Reply-To: References: <42702213-C222-4937-A585-7CFB17E47608@mac.com> Message-ID: thank you very much but windows's readme says: rxtxSerial.dll had to be recomopiled to link in missing native methods. should I ignore it? or what? thanks again also I understand that I should use mingw not cygwin I'll try to install mingw On Mar 21, 2006, at 12:36 AM, Trent Jarvi wrote: > On Tue, 21 Mar 2006, Dmitry Markman wrote: > >> Hi >> can somebody send me latest linux and windows binaries, please? >> >> or where I can find them (I didn't find them in the latest tareball) >> >> I gave up with my cygwin: something wrong I have no idea what >> java doesn't understand /cygwin/c syntax >> after I changed makefile it did java part >> but after that gcc 3.4.4 started to complain >> I set buffer length to 999 lines but I didn't get beginning of the >> story >> something wrong with my 1.4.2_09/include/jni.h gcc doesn't like it >> anyway I gave up >> >> thanks in advance >> > > Hi Dmitry > > The bins are here: > > ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7-bins-r2.zip > > Here are the files in the zip you want. > > Jar: > > rxtx-2.1-7-bins-r2/RXTXcomm.jar > > Windows: > > rxtx-2.1-7-bins-r2/Windows/i368-mingw32/rxtxSerial.dll > > Linux (x86) > > rxtx-2.1-7-bins-r2/Linux/i686-unknown-linux-gnu/librxtxSerial.so > > There are others in there including Parallel port support but those > are the main ones for testing. > > -- > Trent Jarvi > tjarvi at qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx Dmitry Markman From tjarvi at qbang.org Mon Mar 20 23:20:33 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 20 Mar 2006 23:20:33 -0700 (MST) Subject: [Rxtx] binaries request In-Reply-To: References: <42702213-C222-4937-A585-7CFB17E47608@mac.com> Message-ID: On Tue, 21 Mar 2006, Dmitry Markman wrote: > thank you very much > > but windows's readme says: > rxtxSerial.dll had to be recomopiled to link in missing native methods. > > should I ignore it? or what? > Hi Dmitry That dll should be OK. r2 is the recompile linked to the missing native method. The readme explains why it was recompiled; fuser.o was not linked into the dll in the first release. -- Trent Jarvi tjarvi at qbang.org From ariantristan at yahoo.com Mon Mar 20 23:55:24 2006 From: ariantristan at yahoo.com (Lambok Sianturi) Date: Mon, 20 Mar 2006 22:55:24 -0800 (PST) Subject: [Rxtx] jvm issue Message-ID: <20060321065524.94779.qmail@web50701.mail.yahoo.com> Hi All, This is my first time to join RxTx mailing list. I thank you all for allowing others to sign in in requests help. I use the latest RxTx lib in Fedora 3 with java version 1.4.2_09 b05. And I got this error: # # An unexpected error has been detected by HotSpot Virtual Machine: # # SIGSEGV (0xb) at pc=0x00bf27f3, pid=2633, tid=3086112448 # # Java VM: Java HotSpot(TM) Client VM (1.4.2_09-b05 mixed mode) # Problematic frame: # C [ld-linux.so.2+0xa7f3] # # An error report file with more information is saved as hs_err_pid2633.log # # If you would like to submit a bug report, please visit: # http://java.sun.com/webapps/bugreport/crash.jsp # ./run.sh: line 3: 2633 Aborted /usr/local/java/bin/java -Djava.library.path=/usr/local/java/jre/lib/ -Djsmsengine.debug=true -classpath jsmsengine.jar:smsgateway.jar:classes12.jar:RXTXcomm.jar:. com.api.sms.SMSServer What is the jvm depedency for the latest library? Can I use 1.4.2_09 b05? Thanks in advance. Arian --------------------------------- Yahoo! Mail Use Photomail to share photos without annoying attachments. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060320/83d58dd7/attachment-0030.html From f.frumento at ngi.it Tue Mar 21 00:21:47 2006 From: f.frumento at ngi.it (Fabio Frumento) Date: Tue, 21 Mar 2006 08:21:47 +0100 Subject: [Rxtx] Javadoc on the go Message-ID: <441FA98B.9050701@ngi.it> Hi Trent, sorry for the big delay but my job is running wild, i was out for some time but now i'm back and ready to continue the javadoc for Rxtx. Did you used the last javadoc patch i sent you ? let me know if i have to send it to you again or not. regards Fabio From lyon at docjava.com Tue Mar 21 00:51:18 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Tue, 21 Mar 2006 02:51:18 -0500 Subject: [Rxtx] lock files Message-ID: Hi All, You know, if the use of lock files were under Java control (rather than a build-time decision), it might enable a more unified binary distro. It might also facilitate quick prototyping of non-lock file approaches to resolving serial port contention issues (i.e., mac-like approaches vs. linux approaches, etc.). I realize that this is a radical overhaul of the lock file policy issue. Also, it may harm performance. On the other hand, our benchmarks on JNI overhead for modern processors indicate performance impact should be minimal. Perhaps it is more of an issue with the toybox systems. Suppose there were a class with a reasonable default...someone might write: SerialPortLockPolicy.setPolicy(SerialPortLockPolicy.UNIX_LOCK_FILE); SerialPortLockPolicy.setPolicy(SerialPortLockPolicy.NO_LOCK_CHECKING); SerialPortLockPolicy.setPolicy(SerialPortLockPolicy.MAC_STYLE); Thus, we could have a run-time reconfiguration of the serial port lock policy. A special NO_LOCK version of the binary would no longer be required. Any thoughts on this? Thanks! - Doug From joachim at buechse.de Tue Mar 21 03:09:09 2006 From: joachim at buechse.de (Joachim Buechse) Date: Tue, 21 Mar 2006 11:09:09 +0100 Subject: [Rxtx] lock files In-Reply-To: References: Message-ID: <8E12916A-1B9A-4FF2-B684-E2D1C794221B@buechse.de> This is pretty much what I thought about when I suggested, that the default behaviour could be overwritten with a property. I am very much in favor of this approach. In particular this allows much easier debugging for PC based java developers. I think big parts of the Java (and maybe some parts of the C code) could use a bit of a structural workover (unit tests, javadoc, synchronization, etc). Maybe there should be a CVS branch for this experimental version. I'd be happy to contribute a first workover for some of the Java code. Designing for testability and implementing a good bunch of unit tests has been a strategy that worked quite well in the Java projects I lead. And it ultimately allows more liberal change permission. Regards, Joachim On 21.03.2006, at 08:51, Dr. Douglas Lyon wrote: > Hi All, > You know, if the use of lock files were > under Java control (rather than a build-time decision), > it might enable a more unified binary distro. It might also > facilitate quick prototyping of non-lock file approaches > to resolving serial port contention issues (i.e., mac-like > approaches vs. linux approaches, etc.). > > I realize that this is a radical overhaul of the lock file policy > issue. Also, it may harm performance. On the other hand, > our benchmarks on JNI overhead for modern processors indicate > performance impact should be minimal. Perhaps it is more of > an issue with the toybox systems. > > Suppose there were a class with a reasonable default...someone > might write: > SerialPortLockPolicy.setPolicy(SerialPortLockPolicy.UNIX_LOCK_FILE); > SerialPortLockPolicy.setPolicy(SerialPortLockPolicy.NO_LOCK_CHECKING); > SerialPortLockPolicy.setPolicy(SerialPortLockPolicy.MAC_STYLE); > > Thus, we could have a run-time reconfiguration of the serial port lock > policy. A special NO_LOCK version of the binary would no longer > be required. > > Any thoughts on this? > > Thanks! > - Doug > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From joachim at buechse.de Tue Mar 21 06:23:08 2006 From: joachim at buechse.de (Joachim Buechse) Date: Tue, 21 Mar 2006 14:23:08 +0100 Subject: [Rxtx] PATCH: use of ioctl(fd, TIOCEXCL) instead of lockfiles Message-ID: <923AE774-EEA2-4911-92D8-32BB27802C8B@buechse.de> Here is the patch for the ioctl(fd, TIOCEXCL). I have verified this only for OSX 10.4.5, hence it is only defined for APPLE. However, it should work at least for Solaris as well. If a process has requested TIOEXCL further open calls by other user processes will fail. The patch also disables uucp style locking for APPLE. Obviously this is discussable. I think it is the way to go, as it eliminates creating the lock directory which doesnt exist on the standard installation and it eliminates messing with the system group definitions (adding users to group uucp). Regarding the possibility of root processes opening a device which is locked - I consider this a feature not a potential problem. It is highly unlikely, that somebody is crazy enough to run a JavaVM as root (unless he has no other means of getting a restricted IP port opened, ie doesnt understand ipfw). Anyway, even if the process runs as root, it fails when calling ioctl(fd, TIOCEXCL). It could however still open the port to listen for RING events. I.e. a fax server which needs to see incoming calls but otherwise doesnt want to block the port. So the only case where the proposed mechanism fails is, if an incorrectly implemented process running as root conflicts with a user process. I think this can be accepted. Regards, Joachim PS: If this patch is generally accepted, the installer and Mac doku should obviously be changed as well. Index: SerialImp.c =================================================================== RCS file: /usr/local/cvsroot/rxtx-devel/src/SerialImp.c,v retrieving revision 1.46.2.187 diff -u -r1.46.2.187 SerialImp.c --- SerialImp.c 29 Jan 2006 22:19:04 -0000 1.46.2.187 +++ SerialImp.c 21 Mar 2006 12:59:16 -0000 @@ -656,6 +656,25 @@ fd=OPEN (filename, O_RDWR | O_NOCTTY | O_NONBLOCK ); } while (fd < 0 && errno==EINTR); +#ifdef OPEN_EXCL + // Note that open() follows POSIX semantics: multiple open() calls to + // the same file will succeed unless the TIOCEXCL ioctl is issued. + // This will prevent additional opens except by root-owned processes. + // See tty(4) ("man 4 tty") and ioctl(2) ("man 2 ioctl") for details. + + if (fd >= 0 && (ioctl(fd, TIOCEXCL) == -1)) + { + sprintf( message, "open: exclusive access denied for % s\n", + filename ); + report( message ); + report_error( message ); + + close(fd); + goto fail; + } +#endif /* OPEN_EXCL */ + + if( configure_port( fd ) ) goto fail; (*env)->ReleaseStringUTFChars( env, jstr, filename ); sprintf( message, "open: fd returned is %i\n", fd ); Index: SerialImp.h =================================================================== RCS file: /usr/local/cvsroot/rxtx-devel/src/SerialImp.h,v retrieving revision 1.11.2.49 diff -u -r1.11.2.49 SerialImp.h --- SerialImp.h 5 Jul 2005 17:47:21 -0000 1.11.2.49 +++ SerialImp.h 21 Mar 2006 12:59:17 -0000 @@ -135,7 +135,8 @@ /*# define LOCKDIR "/var/spool/uucp"*/ # define LOCKDIR "/var/lock" # define LOCKFILEPREFIX "LK." -# define UUCP +/*# define UUCP*/ +# define OPEN_EXCL #endif /* __APPLE__ */ #if defined(__NetBSD__) # define DEVICEDIR "/dev/" From tjarvi at qbang.org Tue Mar 21 10:26:08 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 21 Mar 2006 10:26:08 -0700 (MST) Subject: [Rxtx] Javadoc on the go In-Reply-To: <441FA98B.9050701@ngi.it> References: <441FA98B.9050701@ngi.it> Message-ID: On Tue, 21 Mar 2006, Fabio Frumento wrote: > Hi Trent, > > sorry for the big delay but my job is running wild, i was out for some > time but now i'm back and ready to continue the javadoc for Rxtx. > > Did you used the last javadoc patch i sent you ? let me know if i have to > send it to you again or not. > > regards > > Fabio Hi Fabio The patch is in the rxtx mail-list archives. It will be going in soon. I did not see a time critical portion. I'll probably be going through the list since the last batch of patches this weekend and putting them into CVS. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Tue Mar 21 10:57:18 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 21 Mar 2006 10:57:18 -0700 (MST) Subject: [Rxtx] jvm issue In-Reply-To: <20060321065524.94779.qmail@web50701.mail.yahoo.com> References: <20060321065524.94779.qmail@web50701.mail.yahoo.com> Message-ID: On Mon, 20 Mar 2006, Lambok Sianturi wrote: > Hi All, > This is my first time to join RxTx mailing list. I thank you all for allowing others to sign in in requests help. > I use the latest RxTx lib in Fedora 3 with java version 1.4.2_09 b05. And I got this error: > > # > # An unexpected error has been detected by HotSpot Virtual Machine: > # > # SIGSEGV (0xb) at pc=0x00bf27f3, pid=2633, tid=3086112448 > # > # Java VM: Java HotSpot(TM) Client VM (1.4.2_09-b05 mixed mode) > # Problematic frame: > # C [ld-linux.so.2+0xa7f3] A native library loading error? What happens if you recompile rxtx on your system and install that? This sounds like an ABI problem? rxtx 2.1-7 was compiled with a gcc 2.96 toolchain as I recall. The hope is newer system will be backwards compatible. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Tue Mar 21 11:05:29 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 21 Mar 2006 11:05:29 -0700 (MST) Subject: [Rxtx] PATCH: use of ioctl(fd, TIOCEXCL) instead of lockfiles In-Reply-To: <923AE774-EEA2-4911-92D8-32BB27802C8B@buechse.de> References: <923AE774-EEA2-4911-92D8-32BB27802C8B@buechse.de> Message-ID: On Tue, 21 Mar 2006, Joachim Buechse wrote: > Here is the patch for the ioctl(fd, TIOCEXCL). I have verified this only > for OSX 10.4.5, hence it is only defined for APPLE. However, it should > work at least for Solaris as well. > > If a process has requested TIOEXCL further open calls by other user > processes will fail. > > The patch also disables uucp style locking for APPLE. Obviously this is > discussable. I think it is the way to go, as it eliminates creating the > lock directory which doesnt exist on the standard installation and it > eliminates messing with the system group definitions (adding users to > group uucp). > > Regarding the possibility of root processes opening a device which is > locked - I consider this a feature not a potential problem. It is highly > unlikely, that somebody is crazy enough to run a JavaVM as root (unless > he has no other means of getting a restricted IP port opened, ie doesnt > understand ipfw). Anyway, even if the process runs as root, it fails when > calling ioctl(fd, TIOCEXCL). It could however still open the port to > listen for RING events. I.e. a fax server which needs to see incoming > calls but otherwise doesnt want to block the port. So the only case where > the proposed mechanism fails is, if an incorrectly implemented process > running as root conflicts with a user process. I think this can be > accepted. > > Regards, > Joachim > > PS: If this patch is generally accepted, the installer and Mac doku > should obviously be changed as well. > > > Index: SerialImp.c > =================================================================== > RCS file: /usr/local/cvsroot/rxtx-devel/src/SerialImp.c,v > retrieving revision 1.46.2.187 > diff -u -r1.46.2.187 SerialImp.c > --- SerialImp.c 29 Jan 2006 22:19:04 -0000 1.46.2.187 > +++ SerialImp.c 21 Mar 2006 12:59:16 -0000 > @@ -656,6 +656,25 @@ > fd=OPEN (filename, O_RDWR | O_NOCTTY | O_NONBLOCK ); > } while (fd < 0 && errno==EINTR); > > +#ifdef OPEN_EXCL > + // Note that open() follows POSIX semantics: multiple open() > calls to > + // the same file will succeed unless the TIOCEXCL ioctl is > issued. > + // This will prevent additional opens except by root-owned > processes. > + // See tty(4) ("man 4 tty") and ioctl(2) ("man 2 ioctl") for > details. > + > + if (fd >= 0 && (ioctl(fd, TIOCEXCL) == -1)) > + { > + sprintf( message, "open: exclusive access denied for % > s\n", > + filename ); > + report( message ); > + report_error( message ); > + > + close(fd); > + goto fail; > + } > +#endif /* OPEN_EXCL */ > + > + > if( configure_port( fd ) ) goto fail; > (*env)->ReleaseStringUTFChars( env, jstr, filename ); > sprintf( message, "open: fd returned is %i\n", fd ); > Index: SerialImp.h > =================================================================== > RCS file: /usr/local/cvsroot/rxtx-devel/src/SerialImp.h,v > retrieving revision 1.11.2.49 > diff -u -r1.11.2.49 SerialImp.h > --- SerialImp.h 5 Jul 2005 17:47:21 -0000 1.11.2.49 > +++ SerialImp.h 21 Mar 2006 12:59:17 -0000 > @@ -135,7 +135,8 @@ > /*# define LOCKDIR "/var/spool/uucp"*/ > # define LOCKDIR "/var/lock" > # define LOCKFILEPREFIX "LK." > -# define UUCP > +/*# define UUCP*/ > +# define OPEN_EXCL > #endif /* __APPLE__ */ > #if defined(__NetBSD__) > # define DEVICEDIR "/dev/" > This looks like a good start. What do you think Dmitry? Perhaps all systems with TIOCEXCL defined should use that though. Even if they use lockfiles. It wont hurt anything. That would catch people hacking their own serial apps without checking lockfiles. Its a good idea to avoid C++ style comments in the C portions. Some older systems don't deal with them well. If it's just for Mac OS X, it isn't a big deal. I think it was the Irix compiler that was problematic? -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Tue Mar 21 11:22:05 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 21 Mar 2006 11:22:05 -0700 (MST) Subject: [Rxtx] lock files In-Reply-To: <8E12916A-1B9A-4FF2-B684-E2D1C794221B@buechse.de> References: <8E12916A-1B9A-4FF2-B684-E2D1C794221B@buechse.de> Message-ID: We can try it. Maybe the JNI is much improved. The nice thing about linking into liblock is distros then worry about lockfiles on their systems. This way, we have to deal with any changes that may show up. On Tue, 21 Mar 2006, Joachim Buechse wrote: > This is pretty much what I thought about when I suggested, that the > default behaviour could be overwritten with a property. I am very much in > favor of this approach. In particular this allows much easier debugging > for PC based java developers. > > I think big parts of the Java (and maybe some parts of the C code) could > use a bit of a structural workover (unit tests, javadoc, synchronization, > etc). Maybe there should be a CVS branch for this experimental version. > I'd be happy to contribute a first workover for some of the Java code. > Designing for testability and implementing a good bunch of unit tests has > been a strategy that worked quite well in the Java projects I lead. And > it ultimately allows more liberal change permission. > > Regards, > Joachim > > > On 21.03.2006, at 08:51, Dr. Douglas Lyon wrote: > >> Hi All, >> You know, if the use of lock files were >> under Java control (rather than a build-time decision), >> it might enable a more unified binary distro. It might also >> facilitate quick prototyping of non-lock file approaches >> to resolving serial port contention issues (i.e., mac-like >> approaches vs. linux approaches, etc.). >> >> I realize that this is a radical overhaul of the lock file policy >> issue. Also, it may harm performance. On the other hand, >> our benchmarks on JNI overhead for modern processors indicate >> performance impact should be minimal. Perhaps it is more of >> an issue with the toybox systems. >> >> Suppose there were a class with a reasonable default...someone >> might write: >> SerialPortLockPolicy.setPolicy(SerialPortLockPolicy.UNIX_LOCK_FILE); >> SerialPortLockPolicy.setPolicy(SerialPortLockPolicy.NO_LOCK_CHECKING); >> SerialPortLockPolicy.setPolicy(SerialPortLockPolicy.MAC_STYLE); >> >> Thus, we could have a run-time reconfiguration of the serial port lock >> policy. A special NO_LOCK version of the binary would no longer >> be required. >> >> Any thoughts on this? >> >> Thanks! >> - Doug >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From dmarkman at mac.com Tue Mar 21 16:05:17 2006 From: dmarkman at mac.com (Dmitry Markman) Date: Tue, 21 Mar 2006 18:05:17 -0500 Subject: [Rxtx] PATCH: use of ioctl(fd, TIOCEXCL) instead of lockfiles In-Reply-To: References: <923AE774-EEA2-4911-92D8-32BB27802C8B@buechse.de> Message-ID: <512AC70C-BB86-48F2-A83C-023F35C23BAB@mac.com> I think it's cool, but I'd like to have that property implementation when user can choose between locking mechanism about comments: it's easy to change comments to the C style or we can use extensions of the file to cpp so c++ compiler will be used On Mar 21, 2006, at 1:05 PM, Trent Jarvi wrote: > This looks like a good start. What do you think Dmitry? Perhaps > all systems with TIOCEXCL defined should use that though. Even if > they use lockfiles. It wont hurt anything. That would catch > people hacking their own serial apps without checking lockfiles. > > Its a good idea to avoid C++ style comments in the C portions. > Some older systems don't deal with them well. If it's just for Mac > OS X, it isn't a big deal. I think it was the Irix compiler that > was problematic? Dmitry Markman From dmarkman at mac.com Tue Mar 21 16:13:00 2006 From: dmarkman at mac.com (Dmitry Markman) Date: Tue, 21 Mar 2006 18:13:00 -0500 Subject: [Rxtx] PATCH: use of ioctl(fd, TIOCEXCL) instead of lockfiles In-Reply-To: References: <923AE774-EEA2-4911-92D8-32BB27802C8B@buechse.de> Message-ID: I'd like to add that creating locking folder isn't a big deal we never had a problem related to the lock folders, because we always used installer on mac os x from other hand I'm not very much familiar with iotcl locking approach and I'm not sure it's more efficient Joachim wrote "I think it is the way to go, as it eliminates creating the lock directory which doesnt exist on the standard installation and it eliminates messing with the system group definitions (adding users to group uucp)." but I really didn't have any problem with that 1. doesn't exist on the standard installation there are many-many things that don't exist in the standard installation so I don't think that argument is strong enough 2. messing with the system group definitions I don't think we're messing with the group definition mac os x provides very clear way to set up group's members and together with Greg Guerin AuthKit there is no problem to set those definitions so I don't think that argument is strong either but from other hand using iotcl is more promising and is more elegant On Mar 21, 2006, at 1:05 PM, Trent Jarvi wrote: > > This looks like a good start. What do you think Dmitry? Perhaps > all systems with TIOCEXCL defined should use that though. Even if > they use lockfiles. It wont hurt anything. That would catch > people hacking their own serial apps without checking lockfiles. Dmitry Markman From joachim at buechse.de Wed Mar 22 04:46:45 2006 From: joachim at buechse.de (Joachim Buechse) Date: Wed, 22 Mar 2006 12:46:45 +0100 Subject: [Rxtx] PATCH: use of ioctl(fd, TIOCEXCL) instead of lockfiles In-Reply-To: References: <923AE774-EEA2-4911-92D8-32BB27802C8B@buechse.de> Message-ID: Sorry, I was not very clear with my arguments, so I will try again;-) Please, don't take this as an attack against work that has been done. I think the contributions that have been made in the past were made in a good spirit. But I really believe, that the current solution for OSX has many shortcomings and should be changed as soon as possible. lock files --- The /var/lock folder does not exist on the standard OSX installation, however the standard installation includes several applications that use serial ports (i.e. the FAX capability). This indicates, that the lock folder approach will not work well with system components. Applications for OSX will generally try to live in harmony with system components (except for HP print drivers of course). I think RXTX should follow this approach as well. uucp group --- Accessing serial ports is not an admin privileged operation on OSX. Any user (world) has read/write privileges on /dev/tty*. So the system default is to not enforce any group membership to access these ports. The group uucp however is a system group on all unix systems I know. It exists for certain system processes. A non admin user should in general not be a member of this group. Quite arguably no user should ever be a member of this group. Installer --- My general opinion is, that - no Installer should touch user or group data without warning - no Application Installer should touch groups which are not specific to the very application installed - no Installer should ever add regular users to a system group The current installer injects the installing user in the group uucp without warning about this change and without giving the option to "opt out" of this change. This is a potential security risk (but not currently a real one, as OSX contains no folders belonging to group uucp). The current installer does not work for multi user systems. It puts the installing user in the uucp group. However the installing user is not necessarily the user that will use the application. Putting all users that may use a serial port application in the system group uucp seems like a very invasive approach to me. Besides that, newly created users will not automatically be in the group and hence, serial applications will "break" for new users without obvious reasons. Avoiding the lock files will allow self contained applications (i.e. drag&drop installation). In my eyes this is largely preferable over an installer that requests admin privileges. Adding up all these points indicates very strongly, that the lock-file implementation is not the way to go on OSX. Regards, Joachim On 22.03.2006, at 00:13, Dmitry Markman wrote: > I'd like to add that > > creating locking folder isn't a big deal > we never had a problem related to the lock folders, because we > always used installer on mac os x > from other hand I'm not very much familiar with iotcl locking > approach and I'm not sure it's more efficient > > Joachim wrote "I think it is the way to go, as it eliminates > creating the lock directory which doesnt exist on the standard > installation and it eliminates messing with the system group > definitions (adding users to group uucp)." but I really didn't have > any problem with that > > 1. doesn't exist on the standard installation > there are many-many things that don't exist in the standard > installation so I don't think that argument is strong enough > 2. messing with the system group definitions > I don't think we're messing with the group definition > mac os x provides very clear way to set up group's members and > together with Greg Guerin AuthKit there is no problem to set those > definitions > so I don't think that argument is strong either > but from other hand using iotcl is more promising and is more elegant > > > > On Mar 21, 2006, at 1:05 PM, Trent Jarvi wrote: > >> >> This looks like a good start. What do you think Dmitry? Perhaps >> all systems with TIOCEXCL defined should use that though. Even if >> they use lockfiles. It wont hurt anything. That would catch >> people hacking their own serial apps without checking lockfiles. > > Dmitry Markman > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From dmarkman at mac.com Wed Mar 22 05:27:13 2006 From: dmarkman at mac.com (Dmitry Markman) Date: Wed, 22 Mar 2006 07:27:13 -0500 Subject: [Rxtx] PATCH: use of ioctl(fd, TIOCEXCL) instead of lockfiles In-Reply-To: References: <923AE774-EEA2-4911-92D8-32BB27802C8B@buechse.de> Message-ID: <83440CF3-DCD8-41C1-B941-F227232C27E3@mac.com> thanks for the very good explanation I didn't think that you were attacking any thing, so don't worry I just had feeling, that there were more aesthetic reasons for going to ioctl then real necessity now you explained everything quite well (BTW, asfar as I remember installer asks admin password so it wasn't quiet, but it really doesn't matter now) thanks On Mar 22, 2006, at 6:46 AM, Joachim Buechse wrote: > Sorry, I was not very clear with my arguments, so I will try again;-) > > Please, don't take this as an attack against work that has been > done. I think the contributions that have been made in the past > were made in a good spirit. But I really believe, that the current > solution for OSX has many shortcomings and should be changed as > soon as possible. > > lock files > --- > The /var/lock folder does not exist on the standard OSX > installation, however the standard installation includes several > applications that use serial ports (i.e. the FAX capability). This > indicates, that the lock folder approach will not work well with > system components. Applications for OSX will generally try to live > in harmony with system components (except for HP print drivers of > course). I think RXTX should follow this approach as well. > > uucp group > --- > Accessing serial ports is not an admin privileged operation on OSX. > Any user (world) has read/write privileges on /dev/tty*. So the > system default is to not enforce any group membership to access > these ports. The group uucp however is a system group on all unix > systems I know. It exists for certain system processes. A non admin > user should in general not be a member of this group. Quite > arguably no user should ever be a member of this group. > > Installer > --- > My general opinion is, that > - no Installer should touch user or group data without warning > - no Application Installer should touch groups which are not > specific to the very application installed > - no Installer should ever add regular users to a system group > > The current installer injects the installing user in the group uucp > without warning about this change and without giving the option to > "opt out" of this change. This is a potential security risk (but > not currently a real one, as OSX contains no folders belonging to > group uucp). > > The current installer does not work for multi user systems. It puts > the installing user in the uucp group. However the installing user > is not necessarily the user that will use the application. Putting > all users that may use a serial port application in the system > group uucp seems like a very invasive approach to me. Besides that, > newly created users will not automatically be in the group and > hence, serial applications will "break" for new users without > obvious reasons. > > > Avoiding the lock files will allow self contained applications > (i.e. drag&drop installation). In my eyes this is largely > preferable over an installer that requests admin privileges. Adding > up all these points indicates very strongly, that the lock-file > implementation is not the way to go on OSX. > > Regards, > Joachim > > > On 22.03.2006, at 00:13, Dmitry Markman wrote: > >> I'd like to add that >> >> creating locking folder isn't a big deal >> we never had a problem related to the lock folders, because we >> always used installer on mac os x >> from other hand I'm not very much familiar with iotcl locking >> approach and I'm not sure it's more efficient >> >> Joachim wrote "I think it is the way to go, as it eliminates >> creating the lock directory which doesnt exist on the standard >> installation and it eliminates messing with the system group >> definitions (adding users to group uucp)." but I really didn't >> have any problem with that >> >> 1. doesn't exist on the standard installation >> there are many-many things that don't exist in the standard >> installation so I don't think that argument is strong enough >> 2. messing with the system group definitions >> I don't think we're messing with the group definition >> mac os x provides very clear way to set up group's members and >> together with Greg Guerin AuthKit there is no problem to set those >> definitions >> so I don't think that argument is strong either >> but from other hand using iotcl is more promising and is more elegant >> >> >> >> On Mar 21, 2006, at 1:05 PM, Trent Jarvi wrote: >> >>> >>> This looks like a good start. What do you think Dmitry? Perhaps >>> all systems with TIOCEXCL defined should use that though. Even >>> if they use lockfiles. It wont hurt anything. That would catch >>> people hacking their own serial apps without checking lockfiles. >> >> Dmitry Markman >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx Dmitry Markman From lyon at docjava.com Wed Mar 22 06:12:18 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Wed, 22 Mar 2006 08:12:18 -0500 Subject: [Rxtx] sole of a new design pattern Message-ID: Hi All, I have been thinking about how we design the serial port software. I think we need a new design pattern. For lack of a better term, I shall call it: The Parametric Singleton Design Pattern By Douglas A. Lyon ABSTRACT The goal of the singleton design pattern is to make sure that there is one, and only one, instance of a given class. The goal of the parametric singleton design pattern is to make sure that there is one, and only one, instance of a given class with the given parametric values. We parametric singleton design pattern combines the singleton design pattern with a parameter that enables unique creation of instances of a class. These instances are cached. When a user asks for an instance with these parameters, the cache is checked. If the instance is in the cache, the instance is returned, otherwise it is created, added to the cache and then returned. We apply our parametric singleton design pattern to the retrieval of RMI registries bound to a given port. The goal of our system is to make sure that no two RMI registries are listening to the same socket and to make use of the RMI registries after they have been created. RMI registries are used in distributed computation. Introduction The singleton design pattern is meant to ensure that on a single instance of a class exists. It is also meant to provide a global point of access to it. The intent of the parametric singleton design pattern is to ensure that a class has only one instance for a given set of parameter values. It also provides a global point of access to it. Motivation A system cannot tolerate multiple instances of some classes with identical parameters. For example, you cannot have two instances making use of the same serial port, at the same time. You cannot have two instances that are trying to listen to the same socket connection. You cannot have two instances writing to the same file structure at the same time. As the operating system is often thought of as the arbiter of consumed resources (i.e., tape drives, serial ports, etc.) we frequently leave it to an operating system implementation to resolve these contention issues. Even for similar resources (like serial ports) there are few standards for handling contention. For example, serial ports on Linux are locked using a "/var/lock" file. POSIX, on the other hand, uses ioctl mechanisms to prevent contention. A better solution is to make a class that is responsible for keeping track of the instances created from the class. The class is declared final, so that it cannot be subclassed. The class also has a private constructor, so that other classes cannot instance it. The new design pattern is called the parametric singleton design pattern and it provides a way to access and create instances with given parameters. Applicability Use the Parametric Singleton Design Pattern when: 1. There must be exactly one instance of a class with the given parameters. 2. The instances must be accessible to clients from a well-known access point. Structure Insert UML diagram here. Participants The Parametric Singleton Clients that need instances 1. The Parametric Singleton defines an instance upon request from a client, if, and only if, the instance does not already exist. 2. The Parametric Singleton returns the instance to the client. 3. The Parametric Singleton is responsible for creating unique instances from given parameters. Collaborations Clients obtain a reference to a Parametric Singleton instance only through the parametric singleton design pattern. If the instance is left in an improper state (e.g., the serial port was left open) it is NOT the role of the Parametric Singleton Design Pattern to close the IO port. Nor is it the role of the Parametric Singleton Design Pattern to open the port. That role is delegate to some other part of the system. Further, it is not the role of the Parametric Singleton Design Pattern to check out resources. That is, multiple threads can have multiple references to the same resource at the same time. MUTEX locking is delegated to some other part of the system. Consequences The Parametric Singleton Design Pattern has several benefits: 1. Controlled access to parametrically defined instances. Since the Parametric Singleton class encapsulates its instances, there is control over how and when clients access it. 2. Reduced name space. The Parametric Singleton pattern avoids global variables that store instances created from the same parameter. Implementation Here are implementation issues to consider when using the Parametric Singleton pattern: 1. Unique mapping of parameters. The Parametric Singleton pattern requires that there be a mean to isomorphically map the parameter space into the instance space and back again. 2. Ensure unique instances. The Parametric Singleton pattern makes unique instances from parameters, and it does so only once. 3. Cache instances for fast retrieval. The Parametric Singleton pattern must be able to look up instances, given some set of parameters, and do so from some data structure. That is, there must be enough space to hold references to all the instances the program will need. Also, a mechanism is needed to look up and retrieve the instances quickly enough to satisfy the clients. Sample Code public final class ParametricSingletonRmiRegistry { private static Hashtable registry = new Hashtable(100); // use singleton pattern and??????????????????????????????????????????????? // prevent instantiation of RmiRegistryUtils.?????????????????????????????? private ParametricSingletonRmiRegistry() { } // the only instance of the Registry held by the RmiRegistryUtils?????????? public static void listNames(Integer port) { if (!isInCacheAndRunning(port)) return; Registry r = (Registry) registry.get(port); System.out.println("registry on port: " + port); System.out.println("registry: " + r); System.out.println("names: "); try { print(r.list()); } catch (RemoteException e) { In.message(e); } System.out.println("------------------------"); } /**???????????????????????????????????????????????????????????????????????? * Checks whether a Registry has been started on this host????????????????? * in the specified port.?????????????????????????????????????????????????? * If not, it tries to start one.?????????????????????????????????????????? * when it fails to start a Registry, it exits the program????????????????? * with exit code 1.??????????????????????????????????????????????????????? */ public static void restart(int port) { if (isInCacheAndRunning(port)) return; try { startRegistry(port); } catch (RemoteException e) { In.message(e); } } /**???????????????????????????????????????????????????????????????????????? * @param port????????????????????????????????????????????????????????????? * @return true if registry is in cache and running???????????????????????? */ private static boolean isInCacheAndRunning(Integer port) { if (!isRegistryRunning(port.intValue())) return false; if (!isRegistryInCache(port.intValue())) return false; return true; } /**???????????????????????????????????????????????????????????????????????? * @param port????????????????????????????????????????????????????????????? * @return true if we are able to locate a local registry on port.??????????????????????????????????????????????????????????????????????????? */ private static boolean isRegistryRunning(int port) { try { Registry r = LocateRegistry.getRegistry(port); if (r != null) return true; } catch (RemoteException e) { return false; } return false; } /**???????????????????????????????????????????????????????????????????????? * @param port????????????????????????????????????????????????????????????? * @return return true if registry is in cache????????????????????????????? */ private static boolean isRegistryInCache(int port) { if (registry.get(new Integer(port)) == null) return false; return true; } /**???????????????????????????????????????????????????????????????????????? * Restart the registry, if needed.???????????????????????????????????????? * Return the only instance of the registry for consistent global?????????? * using by making use of the Singleton Design Pattern????????????????????? *????????????????????????????????????????????????????????????????????????? * @return the internally held registry instance.?????????????????????????? */ public static Registry getRegistry(Integer port) { restart(port); return (Registry) registry.get(port); } private static void startRegistry(Integer port) throws RemoteException { Registry r; try { r = LocateRegistry.createRegistry(port.intValue()); registry.put(port, r); //r = new sun.rmi.registry.RegistryImpl???????????????????????????? /// (port.intValue());?????????????????????????????????????? // registry.put(port, r);?????????????????????????????????????????? } catch (Exception e) { //e.printStackTrace();????????????????????????????????????????????? r = LocateRegistry.getRegistry(port.intValue()); registry.put(port, r); } } public static void main(String args[]) throws RemoteException { //restart(port);??????????????????????????????????????????????????????? restart(5001); restart(5002); restart(5002); Registry r = LocateRegistry.getRegistry(5002); System.out.println("registry="+r); } } I would very much like to get your feedback on this new design pattern idea. Thank you for your time. Regards, - Doug From david.garnier at trusted-logic.com Wed Mar 22 07:36:10 2006 From: david.garnier at trusted-logic.com (David Garnier) Date: Wed, 22 Mar 2006 15:36:10 +0100 Subject: [Rxtx] sole of a new design pattern In-Reply-To: References: Message-ID: <442160DA.80107@trusted-logic.com> Hello, > The Parametric Singleton Design Pattern The Singleton is the most abused design pattern ever. Good use-cases for this pattern are extremely rare and mostly confined to problems related to hardware resources, like serial ports. > Applicability > > Use the Parametric Singleton Design Pattern when: > 1. There must be exactly one instance of a class with the given > parameters. OK. As I said above, this case this actually very unusual. The Singleton pattern is mostly used when : > 2. The instances must be accessible to clients from a well-known > access point. Using the singleton pattern in this case is just convenient for the programmer. Problems arises pretty quickly, especially if you attempt to unit-test your classes. 1) If your singleton is stateful, or hold on to stateful objects, it means that two different unit tests are not actually independent. Instead of starting with a brand new environment, the result of a test may be affected by the result of a previous test. This problem also arise when with your class relies on a database. In both cases, the solution is to reset your "unique" resource (Singleton or database) at the beginning of the test, which is a pain. Also, while most projects connect to a single database, projects that allow the use of Singletons usually contain several of thems, and new ones may cropped up unnoticed. You quickly end up with test cases that only pass in a certain order, which is a royal pain. 2) You cannot mockup a singleton. Once everyone calls the SomeSingleton class statically, you can't replace your class by SomeSingletonMockup. Furthermore, even for hardware services, the Singleton pattern does not really prevent concurrent accesses. If you start the same program in two different JVMs, unless they somehow shared the state of their "Singletons" (through lock files for example), the Singleton pattern will not prevent concurrent access. Our application uses RXTX, and we routinely encounter cases where another (native) application has already locked the port. Since we cannot modify the native application to recognize lock files, OS-level control is irreplaceable. > > Consequences > The Parametric Singleton Design Pattern has several benefits: > > 1. Controlled access to parametrically defined instances. Since > the Parametric Singleton class encapsulates its instances, there is > control over how and when clients access it. Not really. Once you've returned the instance to a client, you've lost control over it. The client can to whatever it wants with it. You cannot "recall" the instance or claim it back. > 2. Reduced name space. The Parametric Singleton pattern avoids > global variables that store instances created from the same parameter. Sure, but you don't have to rely on a Singleton for that. Just create a single Factory. > I would very much like to get your feedback on this new design > pattern idea. Well, it's nothing new. Some may say that it is the point of design patterns: formalizes the designs that occur again and again. However, this design is simply a combination of the Singleton and Factory patterns. I did use it in the past, but now I've been exposed to the shortcomings of the Singleton pattern, so I limit myself to Factories. Regards, David From sean_montgomery at baseview.com Wed Mar 22 08:35:28 2006 From: sean_montgomery at baseview.com (Sean Montgomery) Date: Wed, 22 Mar 2006 10:35:28 -0500 Subject: [Rxtx] sole of a new design pattern In-Reply-To: <442160DA.80107@trusted-logic.com> References: <442160DA.80107@trusted-logic.com> Message-ID: <05769CA7-A51B-4CF0-BAA0-E02DD905F5A4@baseview.com> On Mar 22, 2006, at 9:36 AM, David Garnier wrote: > Furthermore, even for hardware services, the Singleton pattern does > not really prevent concurrent > accesses. If you start the same program in two different JVMs, > unless they somehow shared the state > of their "Singletons" (through lock files for example), the > Singleton pattern will not prevent > concurrent access. > Multiple class loaders in a single JVM can be tricky, too. Then there's synchronization, lazy initialization and serialization of singletons to contend with. Bloch's Effective Java covers these, and here's a few articles: http://www.javaworld.com/javaworld/jw-04-2003/jw-0425-designpatterns- p3.html http://java.sun.com/developer/technicalArticles/Programming/singletons/ Just FYI :-) From lyon at docjava.com Wed Mar 22 08:50:48 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Wed, 22 Mar 2006 10:50:48 -0500 Subject: [Rxtx] sole of a new design pattern In-Reply-To: <442160DA.80107@trusted-logic.com> References: <442160DA.80107@trusted-logic.com> Message-ID: Hi All, First, I would like to thank David for his prompt and thoughtful remarks. I had no idea people that feel strongly about a design patterns! Wow! Feedback (particularly critical feedback) is greatly appreciated. Starting at the end, first: >I did use it in >the past, but now I've been exposed to the shortcomings of the >Singleton pattern, so I limit myself to Factories. David, if I understood your comments correctly, you suggested that Factories can be used in leu of the Singleton Design Pattern, or even the Parametric Singleton Design Pattern. As I see in [Gof]: Factory Method: Intent "Define an interface for creating an object, but let subclasses decide which class to instantiate. Factory Method lets a class defer instantiation to subclasses." The Singleton Design Pattern is a concrete class, which is rather different, right? Also, subclasses are not permitted with Singleton, as they are final. Naturally, I could use an abstract factory as a parent for a singleton. I could even design a facade that could be implemented with the singleton....but that is not the intention of the design. Unless you want a mock-up, as discussed, below: More below: >Hello, > >> The Parametric Singleton Design Pattern > >The Singleton is the most abused design pattern ever. Good use-cases >for this pattern are extremely >rare and mostly confined to problems related to hardware resources, >like serial ports. > > >> Applicability >> >> Use the Parametric Singleton Design Pattern when: >> 1. There must be exactly one instance of a class with the given >> parameters. >OK. As I said above, this case this actually very unusual. The >Singleton pattern is mostly used when : >> 2. The instances must be accessible to clients from a well-known >> access point. > >Using the singleton pattern in this case is just convenient for the >programmer. Problems arises >pretty quickly, especially if you attempt to unit-test your classes. > >1) If your singleton is stateful, or hold on to stateful objects, it >means that two different unit >tests are not actually independent. Instead of starting with a brand >new environment, the result of >a test may be affected by the result of a previous test. This >problem also arise when with your >class relies on a database. In both cases, the solution is to reset >your "unique" resource >(Singleton or database) at the beginning of the test, which is a >pain. Also, while most projects >connect to a single database, projects that allow the use of >Singletons usually contain several of >thems, and new ones may cropped up unnoticed. You quickly end up >with test cases that only pass in a >certain order, which is a royal pain. There are basic problems with communicating finite state machines that include reachability and deadlock analysis. These are addressed with petri net analysis and are beyond the scope of the design pattern. As you quite rightly pointed out; the parametric singleton pattern (or the singleton pattern, for that matter) enable multiple threads to gain access to the same instance. The only way that I can see to block others from gaining access to the reference is the synchronize keyword. This is putting a spin-lock (or MUTEX) on the reference. The question of how to unit-test a design pattern like the parametric singleton remains open. Perhaps this is a deficiency. > >2) You cannot mockup a singleton. Once everyone calls the >SomeSingleton class statically, you can't >replace your class by SomeSingletonMockup. Acutally, I am not sure that this is true. If the Singleton implements a Facade interface, it should be possible to make the replacement. Right? > >Furthermore, even for hardware services, the Singleton pattern does >not really prevent concurrent >accesses. If you start the same program in two different JVMs, >unless they somehow shared the state >of their "Singletons" (through lock files for example), the >Singleton pattern will not prevent >concurrent access. Good Point!! You have sharp eyes! The singleton design pattern should/could take responsibility for this. In fact, you may notice that my code does have an implementation (LocateRegistry) that can work across JVM's. The LocateRegistry will even work across the Internet! LocateRegistry takes both a host name and a Port (lock files just don't do this). I did not think to implement this beyond the local machine, but, in its present form, it will work across different processes. > >Our application uses RXTX, and we routinely encounter cases where >another (native) application has >already locked the port. Since we cannot modify the native >application to recognize lock files, >OS-level control is irreplaceable. The singleton design pattern is not meant to replace OS-level control, but to centralize the Java programmers access to it. If lock files, for example, are used for serial ports, the Singleton Design Pattern should be able to work with them. > > >> >> Consequences >> The Parametric Singleton Design Pattern has several benefits: >> > > 1. Controlled access to parametrically defined instances. Since >> the Parametric Singleton class encapsulates its instances, there is >> control over how and when clients access it. > >Not really. Once you've returned the instance to a client, you've >lost control over it. The client >can to whatever it wants with it. You cannot "recall" the instance >or claim it back. Good point, this should read: > 1. Controll when parametrically defined instances are created. Since > > the Parametric Singleton class encapsulates its instances, there is > > control over how and when they are instanced. > >> 2. Reduced name space. The Parametric Singleton pattern avoids >> global variables that store instances created from the same parameter. > >Sure, but you don't have to rely on a Singleton for that. Just >create a single Factory. > > Thank you for your thoughtful and prompt response! Regards, - Doug From dmarkman at mac.com Wed Mar 22 21:21:55 2006 From: dmarkman at mac.com (Dmitry Markman) Date: Wed, 22 Mar 2006 23:21:55 -0500 Subject: [Rxtx] sole of a new design pattern In-Reply-To: <442160DA.80107@trusted-logic.com> References: <442160DA.80107@trusted-logic.com> Message-ID: I don't think I get it On Mar 22, 2006, at 9:36 AM, David Garnier wrote: > Using the singleton pattern in this case is just convenient for the > programmer. Problems arises > pretty quickly, especially if you attempt to unit-test your classes. so you're saying that something isn't so good because you can not test it in the convenient way? if that's true, I'm totally disagree change your test, debug whatever, but if software is efficient at runtime, works fine and only problem is some unit test (which is some kind of framework for testing) then dump that unit test , dump that unit framework and make something appropriate to the software you're testing so if Douglas want to use singletons, what's the problem? and what do you mean by abusing of singleton usage? of course singleton doesn't prevent concurrent access to the resource across the processes unless you're using some OS facility to prevent it, besides singleton as it was introduced is relevant only and only inside of the same process otherwise it's not singleton it's something else (let's say network singleton: so you have remote invocation facility and some factory method that return object created by that facility) I don't have any problem with using any kind of singletons. Parametric Singleton idea (if I understand it right) could be easily implemented in the following way: use a map populate map with instances of some class and key is your parameter (you can use lazy population too) if somebody ask the key check the value if it's null so resource is taken if somebody returns the resource put it back to the map public synchronized static Object getSomeResource(Object parameter); public synchronized static void returnResource(Object parameter); getSomeResource (inside of the same process) could return null in 2 cases 1. if somebody (from other thread for example) already took that resource 2. if OS API said that resource corresponded to that parameter (serial port with parameter = 1 (port #)) is locked and unavailable; I'm not sure that in case of serial ports we even need those Parametric Singletons (unless lock checking is a very expensive operation) just ask the OS about availability of that resource and if it's available give it away and then OS will lock it and therefore in next time somebody ask it just answer that resource is locked and return null for example system has 2 serial ports available so I ask getResource("tty"); or I ask getResource("Bluetooth-Modem"); and if OS is ok you can give tty or Bluetooth-Modem or both no need for any additional pattern I think back to the problem mac os x doesn't recognize locking via files, so it handles locking via some API an instance of the singleton in each process should recognize that resource is locked (by using that API) that's all we don't have to make things more complicate then they are just because there is some nice design pattern or nice unit test framework or whatever keep things simple, make them work fast, don't introduce middle layers unless you have really good reason to do so of course I could be entirely wrong, so sorry about that in advance thanks Dmitry Markman From tjarvi at qbang.org Wed Mar 22 22:31:41 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 22 Mar 2006 22:31:41 -0700 (MST) Subject: [Rxtx] sole of a new design pattern In-Reply-To: References: Message-ID: Hi Doug Interesting reading. So far I'm just reading and thinking. I have one question so far. " Clients obtain a reference to a Parametric Singleton instance only through the parametric singleton design pattern. If the instance is left in an improper state (e.g., the serial port was left open) it is NOT the role of the Parametric Singleton Design Pattern to close the IO port. Nor is it the role of the Parametric Singleton Design Pattern to open the port. That role is delegate to some other part of the system. " So when the clients obtain a reference to the singleton, can they assume the port is there? IE, would it be the singletons role to handle things like USB dongles being removed with event hints comming from the underlying OS. Hardware abstraction layer/HAL on Linux is an example of underlying OS events. I assume that role too is delegated to other parts of the system? -- Trent Jarvi tjarvi at qbang.org From lyon at docjava.com Thu Mar 23 08:10:33 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Thu, 23 Mar 2006 10:10:33 -0500 Subject: [Rxtx] Classes don't need goals, they need roles! In-Reply-To: References: Message-ID: Hi Trent, Yes, I think that the role of the Parametric Singleton Pattern is not to open or close serial ports, nor is it to perform error checking. On the other hand, if you were to combine the role of the Parametric Singleton Pattern with another role (like that of error checking) it might not be amiss. However, I generally caution programmers against adding multiple roles to classes, as this leads to monolithic designs. Thus a different class (NativeLibDetect) could have the role of determining if the native library can be loaded. Another class (SerialPortBean) can have the role of serializing the default state of the serial port, so that it can be recovered, from user preferences, at a later time. The SerialPortDetect could have the role of determining if the serial port is removed (i.e., a USB port was unplugged). My guess is that each class should have a different role in the system, in order to ease maintenance and testing...but I could be wrong about that. Thanks! - Doug >Hi Doug > >Interesting reading. So far I'm just reading and thinking. I have >one question so far. > >" > Clients obtain a reference to a Parametric Singleton instance only >through the parametric singleton design pattern. If the instance is >left in an improper state (e.g., the serial port was left open) it is >NOT the role of the Parametric Singleton Design Pattern to close the >IO port. Nor is it the role of the Parametric Singleton Design Pattern >to >open the port. That role is delegate to some other part of the system. >" > >So when the clients obtain a reference to the singleton, can they >assume the port is there? IE, would it be the singletons role to >handle things like USB dongles being removed with event hints >comming from the underlying OS. Hardware abstraction layer/HAL on >Linux is an example of underlying OS events. > >I assume that role too is delegated to other parts of the system? > >-- >Trent Jarvi >tjarvi at qbang.org >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From maximulo at yahoo.com Fri Mar 24 01:22:38 2006 From: maximulo at yahoo.com (Maximulo Majir) Date: Fri, 24 Mar 2006 00:22:38 -0800 (PST) Subject: [Rxtx] JavaPOS Message-ID: <20060324082238.66371.qmail@web38214.mail.mud.yahoo.com> Hi all! Hello Trent! From what i understand, RXTX or JavaComm APIs were not created solely for JavaPOS. In JavaPOS, we have the virtual method claim() which is separate from open(), but in our RXTX API, claiming is done every call to open(), we cant open the port if its claimed by another application. Would it be alright to suggest or ask to create a new method called claim(..)? Is there such thing as forceclaim() in RXTX? this could be the same as portownership transfer or its equivalent. ForceClaim is in JSR80. Do you have some samples using RXTX as the lower layer for the Device Service Objects in JavaPOS? I have tried it, i just want to compare. Thank you all! maxim __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060324/496adba2/attachment-0030.html From tjarvi at qbang.org Fri Mar 24 11:28:19 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 24 Mar 2006 11:28:19 -0700 (MST) Subject: [Rxtx] Re: RXTX 2.1 Solaris Problems In-Reply-To: <3691.1143210578@www045.gmx.net> References: <3691.1143210578@www045.gmx.net> Message-ID: On Fri, 24 Mar 2006, Andreas Guenther wrote: > Hi all, > > the solaris problem was not the lock file only. > > Ok, I had to create the directory /var/spool/locks myself. > /var/spool/uucp exists. > > But rxtx didn't find any port. > > I compiled the source with my own debug-informations > and I tried to isolate the problem. > > The problem is the testRead-call in SerialImp.c > > JNIEXPORT jboolean JNICALL RXTXCommDriver(testRead)( > > ... > if ( READ( fd, &c, 1 ) < 0 ) > { > if ( errno != EAGAIN ) { > report( "testRead() read failed\n" ); > ret = JNI_FALSE; > } > } > Thanks Andreas I'm packing up to move. I'll be more or less away for a couple weeks here. I'll be checking email but my workstation is going into a box soon. This isn't hard to fix as this port should be enumerated when EWOULDBLOCK is recieved. Thats error is OK for enumeration just as EAGAIN is. I've put the bug into bugzilla so we dont forget to get to it. http://bugzilla.qbang.org/show_bug.cgi?id=42 You can add yourself to the CC list if you wish to test fixes we provide or even put a patch into bugzilla yourself. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Fri Mar 24 11:51:52 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 24 Mar 2006 11:51:52 -0700 (MST) Subject: [Rxtx] JavaPOS In-Reply-To: <20060324082238.66371.qmail@web38214.mail.mud.yahoo.com> References: <20060324082238.66371.qmail@web38214.mail.mud.yahoo.com> Message-ID: On Fri, 24 Mar 2006, Maximulo Majir wrote: > Hi all! Hello Trent! > > > From what i understand, RXTX or JavaComm APIs were not > created solely for JavaPOS. In JavaPOS, we have the virtual method > claim() which is separate from open(), but in our RXTX API, claiming is > done every call to open(), we cant open the port if its claimed by > another application. Would it be alright to suggest or ask to create a > new method called claim(..)? Is there such thing as forceclaim() in > RXTX? this could be the same as portownership transfer or its > equivalent. ForceClaim is in JSR80. > Do you have some samples using RXTX as the lower layer for the Device > Service Objects in JavaPOS? I have tried it, i just want to compare. > maxim Hi Maxim JSR80 is the USB API IBM/Sun put together. The problem is they have a richer kernel/API underneath that can handle such things. With Serial Ports, there isnt anything there other than an ioctl that says don't let anyone touch this and lockfiles that are more of a 'lets be nice.' At times we may be using USB ports but it is through the termios layer with the limitations mentioned. The advantage is that not only USB will work with rxtx. Anything that has a termios layer should work (to the extent that termios layer is complete). I don't know how forceclaim() would help you. Lets say someone has a programmer working on /dev/ttyS0 and you take it. Now you both race each other to read data first. There isn't a mechanism I know of that will solve this problem in termios. The most obvious test being a native app and a Java app trying to take the port. There is the potential of requestion ownership from other Java Applications but the use for that is very rare. Did you have something more specific in mind that I'm missing? I'm not sure that claim() and forceclaim() would help you with rxtx other than maybe locking the port with claim() without opening it. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sat Mar 25 23:42:08 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 25 Mar 2006 23:42:08 -0700 (MST) Subject: [Rxtx] Serial snoop Message-ID: I was reading the Linux kernel mail-list tonight and ran past a thread that mentioned sersnoop. This looks like a handy tool for people dealing with new toys. "a simple command-line tool for linux that echoes bytes to and from any two serial ports, ptys, or network sockets, and prints all traffic to stdout, in hex and ascii." http://www.restivo.org/projects/sersnoop/ It works on Linux only at this time (debian package available). -- Trent Jarvi tjarvi at qbang.org From beat.arnet at gmail.com Sun Mar 26 07:32:35 2006 From: beat.arnet at gmail.com (Beat Arnet) Date: Sun, 26 Mar 2006 09:32:35 -0500 Subject: [Rxtx] Error 0x5 at /home/bob/foo/tar/rxtx-2.1-7/build/../src/termios.c(860): Access is, denied. Message-ID: <4426A603.80508@gmail.com> Dear all, When trying to open the serial port, I sometimes (not always) run into the following exception (when opening the serialPort): Error 0x5 at /home/bob/foo/tar/rxtx-2.1-7/build/../src/termios.c(860): Access is denied. java.lang.UnsatisfiedLinkError: native_psmisc_report_owner at gnu.io.CommPortIdentifier.native_psmisc_report_owner(Native Method) at gnu.io.CommPortIdentifier.open(CommPortIdentifier.java:354) at codeskin.tools.CLLoader.open(CLLoader.java:79) at codeskin.tools.C2000Programmer.run(C2000Programmer.java:220) at java.lang.Thread.run(Unknown Source) Is this the type of error where I should just try to open the port again, or can it be avoided? Regards, Beat From tjarvi at qbang.org Sun Mar 26 11:40:12 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 26 Mar 2006 11:40:12 -0700 (MST) Subject: [Rxtx] Error 0x5 at /home/bob/foo/tar/rxtx-2.1-7/build/../src/termios.c(860): Access is, denied. In-Reply-To: <4426A603.80508@gmail.com> References: <4426A603.80508@gmail.com> Message-ID: On Sun, 26 Mar 2006, Beat Arnet wrote: > Dear all, > > When trying to open the serial port, I sometimes (not always) run into > the following exception (when opening the serialPort): > > Error 0x5 at /home/bob/foo/tar/rxtx-2.1-7/build/../src/termios.c(860): > Access is > denied. > > java.lang.UnsatisfiedLinkError: native_psmisc_report_owner > at gnu.io.CommPortIdentifier.native_psmisc_report_owner(Native > Method) > at gnu.io.CommPortIdentifier.open(CommPortIdentifier.java:354) > at codeskin.tools.CLLoader.open(CLLoader.java:79) > at codeskin.tools.C2000Programmer.run(C2000Programmer.java:220) > at java.lang.Thread.run(Unknown Source) > > Is this the type of error where I should just try to open the port again, > or can it be avoided? > Hi Beat We did a second build of rxtx 2.1-7 to resolve that unsatisfied link error. It should work now. rxtx is trying to tell you it thinks someone else has the serial port open. You can try to open the port again but maybe you already have a copy of the program running when it happens? ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7r2.zip fixed build. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sun Mar 26 11:44:23 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 26 Mar 2006 11:44:23 -0700 (MST) Subject: [Rxtx] RXTX spec file (fwd) Message-ID: This is probably interesting for fedora/suse users. ---------- Forwarded message ---------- Date: Sun, 26 Mar 2006 16:25:45 +0200 To: taj at www.linux.org.uk Subject: RXTX spec file I send you this spec file which allows to create a RPM for Fedora 4, 5 (x86, x86_64) with Java Sun. -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: rxtx.spec Url: http://mailman.qbang.org/pipermail/rxtx/attachments/20060326/6c7b6af6/rxtx-0026.pl From tjarvi at qbang.org Sun Mar 26 23:42:59 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 26 Mar 2006 23:42:59 -0700 (MST) Subject: [Rxtx] Upcomming events. Message-ID: This Wednesday we will be announcing a new "Maintainer" for the rxtx project. The position is more like neutral leader. I wont be going away or doing less. This is just the right thing to do as it turns out the two people with CVS write access will be at the same company. We need a third and we need neutrality. The maintainer will have final say in any conflict and will try to be neutral. It will be open for discussion. Then we will do it :) I'll still do most of the footwork I do now. But. I'm falling behind. I should have gone through the mail-list and posted the next round of changes this weekend. I'm packing to move and its going so so - 13 years of toys collected. I suspect there will be a dead period on my part (a couple weeks) comming up. But if you get it on the mail-list, we will get it in if there are no objections. I may well not be reading the mail-list during this period as I look for a house and many other things. I hope everyone will help out. Thanks -- Trent Jarvi tjarvi at qbang.org From mahmoud_hadad at yahoo.com Sun Mar 26 07:31:19 2006 From: mahmoud_hadad at yahoo.com (ronan nick) Date: Sun, 26 Mar 2006 06:31:19 -0800 (PST) Subject: [Rxtx] a question about the COMM API Message-ID: <20060326143119.54919.qmail@web60014.mail.yahoo.com> hi, i was intrested in knowing how i can communicate with my internal modem using java? for example if i want to make a phone dialer application or a caller id application where should i be looking at? and as i understood the COMM API is for devices that is attached to the computer through serial ports. --------------------------------- New Yahoo! Messenger with Voice. Call regular phones from your PC and save big. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060326/ce8329f0/attachment-0028.html From dmarkman at mac.com Mon Mar 20 00:20:43 2006 From: dmarkman at mac.com (Dmitry Markman) Date: Mon, 20 Mar 2006 02:20:43 -0500 Subject: [Rxtx] Mac OS X RXTX java installer In-Reply-To: References: <07D0DE29-BA32-4CFE-B036-66BC6423D385@buechse.de> <441AE3E0.2030503@willicon.de> <12531986.1142622114996.JavaMail.dmarkman@mac.com> <441B2674.9010409@willicon.de> <13577405.1142634732776.JavaMail.dmarkman@mac.com> <441B4182.8010407@willicon.de> <92CD0D6C-5BE8-426E-A46D-99452059FF49@mac.com> <441BBB2D.8030305@willicon.de> <441C4088.5090905@willicon.de> Message-ID: <64BC1E23-FDDE-4CE6-8863-CFC881CBC224@mac.com> Hi all I put RXTX installer that will install everything (and will create / var/lock if necessary and add user to the uucp group) for mac os x from Java into the rxtx's CVS repository it could be easily modified to install files for any platform it uses Greg Guerin's AuthKit for authentication and authorization Greg released that kit under artistic license, so Trent, please take a look we, probably, can negotiate license with Greg if it's necessary Greg's AuthKit could be downloaded from http://www.amug.org/~glguerin/ sw/#authkit Michael Hall (mikehall at spacestar dot net) had a suggestion to make implementation of the jaas LoginModule based on Greg's AuthKit (his modification of the Greg's AuthKit could be found at http:// www.spacestar.net/users/mikehall/authkit.dmg) but Michael's AuthKitLoginModule does only half a job: it does authenticate but it can not run any external unix process in privileged mode (at least I wasn't able to do so) possible explanation could be found in conversation between Greg and Michael at Apple's java-dev list (look for archives) so I didn't use jaas API for rxtxinstaller I created folder MacOSX in the contrib folder comment 1. if you want to run that installer as standalone application all you need that RXTXInstaller.jar 2. if you want to use webstart you have to add Greg's libAuthKit.jnilib to the mac os x's resources in theory RXTXInstaller.jar doesn't need it, but there is a problem with loading libAuthKit.jnilib from webstart authkit uses loadLibrary method to load library and it failed (from webstart) for standalone application I extract libAuthKit.jnilib from the RXTXInstaller.jar and put it into the /Library/Java/Extensions or ~/Library/Java/Extensions folder that file will be deleted after installer quit unfortunately I didn't have time to put documentation there but it is mostly self-explanatory I took installer code from my gl4java installer that I did about 3 years ago (with small modifications) it would be very nice if Apple will release LoginModule that really will do the job (com.apple.security.auth.module package????? ) (UnixLoginModule is pretty useless) From lyon at docjava.com Mon Mar 20 06:34:39 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Mon, 20 Mar 2006 08:34:39 -0500 Subject: [Rxtx] Mac OS X RXTX java installer In-Reply-To: <64BC1E23-FDDE-4CE6-8863-CFC881CBC224@mac.com> References: <07D0DE29-BA32-4CFE-B036-66BC6423D385@buechse.de> <441AE3E0.2030503@willicon.de> <12531986.1142622114996.JavaMail.dmarkman@mac.com> <441B2674.9010409@willicon.de> <13577405.1142634732776.JavaMail.dmarkman@mac.com> <441B4182.8010407@willicon.de> <92CD0D6C-5BE8-426E-A46D-99452059FF49@mac.com> <441BBB2D.8030305@willicon.de> <441C4088.5090905@willicon.de> <64BC1E23-FDDE-4CE6-8863-CFC881CBC224@mac.com> Message-ID: Hi Dimitry, This sounds like great work. Just a couple of questions; After the check out of the CVS files, using: setenv CVSROOT :pserver:anonymous at cvs.milestonesolutions.com:/usr/local/cvsroot 53 8:28 setenv PASSWORD mousy 54 8:29 cvs login 55 8:29 cvs checkout rxtx-devel I cd'd over to: rxtx-devel/MACOSX_IDE And found: CVS/ CW/ ForPackageMaker/ PB/ Where is the installer? Thanks! - Doug From tjarvi at qbang.org Mon Mar 20 06:39:37 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 20 Mar 2006 06:39:37 -0700 (MST) Subject: [Rxtx] Mac OS X RXTX java installer In-Reply-To: References: <07D0DE29-BA32-4CFE-B036-66BC6423D385@buechse.de> <441AE3E0.2030503@willicon.de> <12531986.1142622114996.JavaMail.dmarkman@mac.com> <441B2674.9010409@willicon.de> <13577405.1142634732776.JavaMail.dmarkman@mac.com> <441B4182.8010407@willicon.de> <92CD0D6C-5BE8-426E-A46D-99452059FF49@mac.com> <441BBB2D.8030305@willicon.de> <441C4088.5090905@willicon.de> <64BC1E23-FDDE-4CE6-8863-CFC881CBC224@mac.com> Message-ID: On Mon, 20 Mar 2006, Dr. Douglas Lyon wrote: > Hi Dimitry, > This sounds like great work. Just a couple of questions; > After the check out of the CVS files, using: > setenv CVSROOT > :pserver:anonymous at cvs.milestonesolutions.com:/usr/local/cvsroot > 53 8:28 setenv PASSWORD mousy > 54 8:29 cvs login > 55 8:29 cvs checkout rxtx-devel Hi Doug You want "cvs checkout -r commapi-0-0-1 rxtx-devel" to get RXTX 2.1 The default branch is rxtx 2.0 which isn't very active right now. -- Trent Jarvi tjarvi at qbang.org From lyon at docjava.com Mon Mar 20 07:05:44 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Mon, 20 Mar 2006 09:05:44 -0500 Subject: [Rxtx] Mac OS X RXTX java installer In-Reply-To: References: <07D0DE29-BA32-4CFE-B036-66BC6423D385@buechse.de> <441AE3E0.2030503@willicon.de> <12531986.1142622114996.JavaMail.dmarkman@mac.com> <441B2674.9010409@willicon.de> <13577405.1142634732776.JavaMail.dmarkman@mac.com> <441B4182.8010407@willicon.de> <92CD0D6C-5BE8-426E-A46D-99452059FF49@mac.com> <441BBB2D.8030305@willicon.de> <441C4088.5090905@willicon.de> <64BC1E23-FDDE-4CE6-8863-CFC881CBC224@mac.com> Message-ID: Hi Trent, Thanks for the info on the CVS checkout procedure. I did that and am still not sure where the installer is. Here is what I have: cd MACOSX_IDE/ p4.docjava.com{lyon}121: ls CVS/ ForPackageMaker/ PB/ p4.docjava.com{lyon}122: find . | more . ./ForPackageMaker ./ForPackageMaker/RXTX.pkg.sit.hqx ./ForPackageMaker/Resources ./ForPackageMaker/Resources/ReadMe.rtf ./ForPackageMaker/Resources/Welcome.rtf ./ForPackageMaker/Resources/CVS ./ForPackageMaker/Resources/CVS/Entries ./ForPackageMaker/Resources/CVS/Repository ./ForPackageMaker/Resources/CVS/Tag ./ForPackageMaker/Resources/CVS/Root ./ForPackageMaker/Resources/preinstall ./ForPackageMaker/Resources/License.rtf ./ForPackageMaker/Resources/preupgrade ./ForPackageMaker/RXTX.pmsp ./ForPackageMaker/CVS ./ForPackageMaker/CVS/Entries ./ForPackageMaker/CVS/Repository ./ForPackageMaker/CVS/Entries.Log ./ForPackageMaker/CVS/Tag ./ForPackageMaker/CVS/Root ./ForPackageMaker/RXTX_Tiger.pkg.sitx.hqx ./ForPackageMaker/RXTX_Jag.pkg.sit.hqx ./ForPackageMaker/Install ./ForPackageMaker/Install/CVS ./ForPackageMaker/Install/CVS/Entries ./ForPackageMaker/Install/CVS/Repository ./ForPackageMaker/Install/CVS/Tag ./ForPackageMaker/Install/CVS/Root ./ForPackageMaker/Install/Library ./ForPackageMaker/Install/Library/CVS ./ForPackageMaker/Install/Library/CVS/Entries ./ForPackageMaker/Install/Library/CVS/Repository ./ForPackageMaker/Install/Library/CVS/Tag ./ForPackageMaker/Install/Library/CVS/Root ./ForPackageMaker/Install/Library/Java ./ForPackageMaker/Install/Library/Java/Extensions ./ForPackageMaker/Install/Library/Java/Extensions/RXTXcomm.jar ./ForPackageMaker/Install/Library/Java/Extensions/CVS ./ForPackageMaker/Install/Library/Java/Extensions/CVS/Entries ./ForPackageMaker/Install/Library/Java/Extensions/CVS/Repository ./ForPackageMaker/Install/Library/Java/Extensions/CVS/Tag ./ForPackageMaker/Install/Library/Java/Extensions/CVS/Root ./ForPackageMaker/Install/Library/Java/Extensions/librxtxSerial.jnilib ./ForPackageMaker/Install/Library/Java/CVS ./ForPackageMaker/Install/Library/Java/CVS/Entries ./ForPackageMaker/Install/Library/Java/CVS/Repository ./ForPackageMaker/Install/Library/Java/CVS/Entries.Log ./ForPackageMaker/Install/Library/Java/CVS/Tag ./ForPackageMaker/Install/Library/Java/CVS/Root ./ForPackageMaker/RXTX_Tiger.pmproj.sitx.hqx ./CVS ./CVS/Entries ./CVS/Repository ./CVS/Entries.Log ./CVS/Tag ./CVS/Root ./PB ./PB/LibSerialUniversal.xcodeproj.sitx.hqx ./PB/CVS ./PB/CVS/Entries ./PB/CVS/Repository ./PB/CVS/Entries.Log ./PB/CVS/Tag ./PB/CVS/Root ./PB/LibSerial.pbproj.sit.hqx ./PB/startpoint.c ./PB/config.h What is the procedure to run this installer? Do we need a README in: /rxtx-devel/MACOSX_IDE Here is what we have: CVS/ ForPackageMaker/ PB/ Thanks! - DL >On Mon, 20 Mar 2006, Dr. Douglas Lyon wrote: > >>Hi Dimitry, >>This sounds like great work. Just a couple of questions; >>After the check out of the CVS files, using: >>setenv CVSROOT >>:pserver:anonymous at cvs.milestonesolutions.com:/usr/local/cvsroot >> 53 8:28 setenv PASSWORD mousy >> 54 8:29 cvs login >> 55 8:29 cvs checkout rxtx-devel > >Hi Doug > >You want "cvs checkout -r commapi-0-0-1 rxtx-devel" to get RXTX 2.1 >The default branch is rxtx 2.0 which isn't very active right now. > >-- >Trent Jarvi >tjarvi at qbang.org From tjarvi at qbang.org Mon Mar 20 07:25:30 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 20 Mar 2006 07:25:30 -0700 (MST) Subject: [Rxtx] Mac OS X RXTX java installer In-Reply-To: References: <07D0DE29-BA32-4CFE-B036-66BC6423D385@buechse.de> <441AE3E0.2030503@willicon.de> <12531986.1142622114996.JavaMail.dmarkman@mac.com> <441B2674.9010409@willicon.de> <13577405.1142634732776.JavaMail.dmarkman@mac.com> <441B4182.8010407@willicon.de> <92CD0D6C-5BE8-426E-A46D-99452059FF49@mac.com> <441BBB2D.8030305@willicon.de> <441C4088.5090905@willicon.de> <64BC1E23-FDDE-4CE6-8863-CFC881CBC224@mac.com> Message-ID: On Mon, 20 Mar 2006, Dr. Douglas Lyon wrote: > Hi Trent, > Thanks for the info on the CVS checkout procedure. > I did that and am still not sure where the installer is. Hi Doug It does look like it was not cvs committed. There is no rxtx-devel/contrib/MacOSX directory in there at the moment. It was mentioned that it was put under contrib. -- Trent Jarvi tjarvi at qbang.org From dmarkman at mac.com Mon Mar 20 07:29:56 2006 From: dmarkman at mac.com (Dmitry Markman) Date: Mon, 20 Mar 2006 09:29:56 -0500 Subject: [Rxtx] Mac OS X RXTX java installer In-Reply-To: References: <07D0DE29-BA32-4CFE-B036-66BC6423D385@buechse.de> <441AE3E0.2030503@willicon.de> <12531986.1142622114996.JavaMail.dmarkman@mac.com> <441B2674.9010409@willicon.de> <13577405.1142634732776.JavaMail.dmarkman@mac.com> <441B4182.8010407@willicon.de> <92CD0D6C-5BE8-426E-A46D-99452059FF49@mac.com> <441BBB2D.8030305@willicon.de> <441C4088.5090905@willicon.de> <64BC1E23-FDDE-4CE6-8863-CFC881CBC224@mac.com> Message-ID: <6054EB4E-F7E0-4A9C-BDDA-D582D6D8826F@mac.com> you can find it in the rxtx-devel/contrib folder On Mar 20, 2006, at 9:05 AM, Dr. Douglas Lyon wrote: > Hi Trent, > Thanks for the info on the CVS checkout procedure. > I did that and am still not sure where the installer is. > Here is what I have: > cd MACOSX_IDE/ > p4.docjava.com{lyon}121: ls > CVS/ ForPackageMaker/ PB/ > p4.docjava.com{lyon}122: find . | more > . > ./ForPackageMaker > ./ForPackageMaker/RXTX.pkg.sit.hqx > ./ForPackageMaker/Resources > ./ForPackageMaker/Resources/ReadMe.rtf > ./ForPackageMaker/Resources/Welcome.rtf > ./ForPackageMaker/Resources/CVS > ./ForPackageMaker/Resources/CVS/Entries > ./ForPackageMaker/Resources/CVS/Repository > ./ForPackageMaker/Resources/CVS/Tag > ./ForPackageMaker/Resources/CVS/Root > ./ForPackageMaker/Resources/preinstall > ./ForPackageMaker/Resources/License.rtf > ./ForPackageMaker/Resources/preupgrade > ./ForPackageMaker/RXTX.pmsp > ./ForPackageMaker/CVS > ./ForPackageMaker/CVS/Entries > ./ForPackageMaker/CVS/Repository > ./ForPackageMaker/CVS/Entries.Log > ./ForPackageMaker/CVS/Tag > ./ForPackageMaker/CVS/Root > ./ForPackageMaker/RXTX_Tiger.pkg.sitx.hqx > ./ForPackageMaker/RXTX_Jag.pkg.sit.hqx > ./ForPackageMaker/Install > ./ForPackageMaker/Install/CVS > ./ForPackageMaker/Install/CVS/Entries > ./ForPackageMaker/Install/CVS/Repository > ./ForPackageMaker/Install/CVS/Tag > ./ForPackageMaker/Install/CVS/Root > ./ForPackageMaker/Install/Library > ./ForPackageMaker/Install/Library/CVS > ./ForPackageMaker/Install/Library/CVS/Entries > ./ForPackageMaker/Install/Library/CVS/Repository > ./ForPackageMaker/Install/Library/CVS/Tag > ./ForPackageMaker/Install/Library/CVS/Root > ./ForPackageMaker/Install/Library/Java > ./ForPackageMaker/Install/Library/Java/Extensions > ./ForPackageMaker/Install/Library/Java/Extensions/RXTXcomm.jar > ./ForPackageMaker/Install/Library/Java/Extensions/CVS > ./ForPackageMaker/Install/Library/Java/Extensions/CVS/Entries > ./ForPackageMaker/Install/Library/Java/Extensions/CVS/Repository > ./ForPackageMaker/Install/Library/Java/Extensions/CVS/Tag > ./ForPackageMaker/Install/Library/Java/Extensions/CVS/Root > ./ForPackageMaker/Install/Library/Java/Extensions/librxtxSerial.jnilib > ./ForPackageMaker/Install/Library/Java/CVS > ./ForPackageMaker/Install/Library/Java/CVS/Entries > ./ForPackageMaker/Install/Library/Java/CVS/Repository > ./ForPackageMaker/Install/Library/Java/CVS/Entries.Log > ./ForPackageMaker/Install/Library/Java/CVS/Tag > ./ForPackageMaker/Install/Library/Java/CVS/Root > ./ForPackageMaker/RXTX_Tiger.pmproj.sitx.hqx > ./CVS > ./CVS/Entries > ./CVS/Repository > ./CVS/Entries.Log > ./CVS/Tag > ./CVS/Root > ./PB > ./PB/LibSerialUniversal.xcodeproj.sitx.hqx > ./PB/CVS > ./PB/CVS/Entries > ./PB/CVS/Repository > ./PB/CVS/Entries.Log > ./PB/CVS/Tag > ./PB/CVS/Root > ./PB/LibSerial.pbproj.sit.hqx > ./PB/startpoint.c > ./PB/config.h > > What is the procedure to run this installer? > Do we need a README in: > /rxtx-devel/MACOSX_IDE > Here is what we have: > CVS/ ForPackageMaker/ PB/ > > > Thanks! > - DL > >> On Mon, 20 Mar 2006, Dr. Douglas Lyon wrote: >> >>> Hi Dimitry, >>> This sounds like great work. Just a couple of questions; >>> After the check out of the CVS files, using: >>> setenv CVSROOT :pserver:anonymous at cvs.milestonesolutions.com:/usr/ >>> local/cvsroot >>> 53 8:28 setenv PASSWORD mousy >>> 54 8:29 cvs login >>> 55 8:29 cvs checkout rxtx-devel >> >> Hi Doug >> >> You want "cvs checkout -r commapi-0-0-1 rxtx-devel" to get RXTX 2.1 >> The default branch is rxtx 2.0 which isn't very active right now. >> >> -- >> Trent Jarvi >> tjarvi at qbang.org > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx Dmitry Markman From mikehall at spacestar.net Mon Mar 20 05:25:25 2006 From: mikehall at spacestar.net (Michael Hall) Date: Mon, 20 Mar 2006 06:25:25 -0600 Subject: [Rxtx] Re: Mac OS X RXTX java installer In-Reply-To: <64BC1E23-FDDE-4CE6-8863-CFC881CBC224@mac.com> References: <07D0DE29-BA32-4CFE-B036-66BC6423D385@buechse.de> <441AE3E0.2030503@willicon.de> <12531986.1142622114996.JavaMail.dmarkman@mac.com> <441B2674.9010409@willicon.de> <13577405.1142634732776.JavaMail.dmarkman@mac.com> <441B4182.8010407@willicon.de> <92CD0D6C-5BE8-426E-A46D-99452059FF49@mac.com> <441BBB2D.8030305@willicon.de> <441C4088.5090905@willicon.de> <64BC1E23-FDDE-4CE6-8863-CFC881CBC224@mac.com> Message-ID: <247EB61F-5CD1-4132-89A2-FC105B6CF9A5@spacestar.net> On Mar 20, 2006, at 1:20 AM, Dmitry Markman wrote: > > Michael Hall (mikehall at spacestar dot net) had a suggestion to > make implementation of the jaas LoginModule > based on Greg's AuthKit > (his modification of the Greg's AuthKit could be found at http:// > www.spacestar.net/users/mikehall/authkit.dmg) > but Michael's AuthKitLoginModule does only half a job: > it does authenticate > but it can not run any external unix process in privileged mode (at > least I wasn't able to do so) If you got it working directly with Greg's the point is moot. But to clarify it anyhow. The login module does not allow you to do anything anything privileged on return as was explained by Greg. You need to work with a separate privileged process using the execPrivileged method of his API. I assume you did something similar although I haven't looked at how you are using it yet. I allowed instead for a action to be performed at the same time you login/authenticate,this... System.setProperty("authkit.action","/usr/bin/id"); just before this... lc.login(); To clarify, safely ignored as you are already complete. Mike Hall mikehall at spacestar dot net http://www.spacestar.net/users/mikehall http://sourceforge.net/projects/macnative -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2427 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20060320/f6e18202/smime-0031.bin From dmarkman at mac.com Mon Mar 20 07:36:47 2006 From: dmarkman at mac.com (Dmitry Markman) Date: Mon, 20 Mar 2006 09:36:47 -0500 Subject: [Rxtx] Re: Mac OS X RXTX java installer In-Reply-To: <247EB61F-5CD1-4132-89A2-FC105B6CF9A5@spacestar.net> References: <07D0DE29-BA32-4CFE-B036-66BC6423D385@buechse.de> <441AE3E0.2030503@willicon.de> <12531986.1142622114996.JavaMail.dmarkman@mac.com> <441B2674.9010409@willicon.de> <13577405.1142634732776.JavaMail.dmarkman@mac.com> <441B4182.8010407@willicon.de> <92CD0D6C-5BE8-426E-A46D-99452059FF49@mac.com> <441BBB2D.8030305@willicon.de> <441C4088.5090905@willicon.de> <64BC1E23-FDDE-4CE6-8863-CFC881CBC224@mac.com> <247EB61F-5CD1-4132-89A2-FC105B6CF9A5@spacestar.net> Message-ID: Hi, Michael all I have to do is to run some shell script I tried to use your action mechanism and it worked great so I just System.setProperty ("authkit.action","" ) and after that I even don't need to run anything like subject.doAs.... but after few thoughts I choose to use plain Greg's approach, because in that case I don't have to deal with various java's configurations files and therefore to use 2-3 -D parameters in the java command line especially it's useful for java web start (it's so fragile :-( ) thanks for the great job On Mar 20, 2006, at 7:25 AM, Michael Hall wrote: > > On Mar 20, 2006, at 1:20 AM, Dmitry Markman wrote: >> >> Michael Hall (mikehall at spacestar dot net) had a suggestion to >> make implementation of the jaas LoginModule >> based on Greg's AuthKit >> (his modification of the Greg's AuthKit could be found at http:// >> www.spacestar.net/users/mikehall/authkit.dmg) >> but Michael's AuthKitLoginModule does only half a job: >> it does authenticate >> but it can not run any external unix process in privileged mode >> (at least I wasn't able to do so) > > If you got it working directly with Greg's the point is moot. > > But to clarify it anyhow. > The login module does not allow you to do anything anything > privileged on return as was explained by Greg. You need to work > with a separate privileged process using the execPrivileged method > of his API. I assume you did something similar although I haven't > looked at how you are using it yet. > I allowed instead for a action to be performed at the same time you > login/authenticate,this... > System.setProperty("authkit.action","/usr/bin/id"); > just before this... > lc.login(); > To clarify, safely ignored as you are already complete. > > Mike Hall mikehall at spacestar dot net > http://www.spacestar.net/users/mikehall > http://sourceforge.net/projects/macnative > > > Dmitry Markman From dmarkman at mac.com Mon Mar 20 07:44:45 2006 From: dmarkman at mac.com (Dmitry Markman) Date: Mon, 20 Mar 2006 09:44:45 -0500 Subject: [Rxtx] Mac OS X RXTX java installer In-Reply-To: References: <07D0DE29-BA32-4CFE-B036-66BC6423D385@buechse.de> <441AE3E0.2030503@willicon.de> <12531986.1142622114996.JavaMail.dmarkman@mac.com> <441B2674.9010409@willicon.de> <13577405.1142634732776.JavaMail.dmarkman@mac.com> <441B4182.8010407@willicon.de> <92CD0D6C-5BE8-426E-A46D-99452059FF49@mac.com> <441BBB2D.8030305@willicon.de> <441C4088.5090905@willicon.de> <64BC1E23-FDDE-4CE6-8863-CFC881CBC224@mac.com> Message-ID: it's in the commapi-0-0-1 branch I tested it right now: cvs co -r commapi-0-0-1 rxtx-devel and I got everything On Mar 20, 2006, at 9:25 AM, Trent Jarvi wrote: > On Mon, 20 Mar 2006, Dr. Douglas Lyon wrote: > >> Hi Trent, >> Thanks for the info on the CVS checkout procedure. >> I did that and am still not sure where the installer is. > > Hi Doug > > It does look like it was not cvs committed. There is no rxtx-devel/ > contrib/MacOSX directory in there at the moment. It was mentioned > that it was put under contrib. > > -- > Trent Jarvi > tjarvi at qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx Dmitry Markman From tjarvi at qbang.org Mon Mar 20 07:52:57 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 20 Mar 2006 07:52:57 -0700 (MST) Subject: [Rxtx] Mac OS X RXTX java installer In-Reply-To: References: <07D0DE29-BA32-4CFE-B036-66BC6423D385@buechse.de> <441AE3E0.2030503@willicon.de> <12531986.1142622114996.JavaMail.dmarkman@mac.com> <441B2674.9010409@willicon.de> <13577405.1142634732776.JavaMail.dmarkman@mac.com> <441B4182.8010407@willicon.de> <92CD0D6C-5BE8-426E-A46D-99452059FF49@mac.com> <441BBB2D.8030305@willicon.de> <441C4088.5090905@willicon.de> <64BC1E23-FDDE-4CE6-8863-CFC881CBC224@mac.com> Message-ID: On Mon, 20 Mar 2006, Dmitry Markman wrote: > it's in the commapi-0-0-1 branch > > I tested it right now: > cvs co -r commapi-0-0-1 rxtx-devel > > and I got everything > A fresh checkout worked. Here is a copy of the tree (just the installer bits) ftp://ftp.qbang.org/pub/rxtx/MacOSX-installer.zip -- Trent Jarvi tjarvi at qbang.org From lyon at docjava.com Mon Mar 20 08:08:26 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Mon, 20 Mar 2006 10:08:26 -0500 Subject: [Rxtx] Mac OS X RXTX java installer In-Reply-To: References: <07D0DE29-BA32-4CFE-B036-66BC6423D385@buechse.de> <441AE3E0.2030503@willicon.de> <12531986.1142622114996.JavaMail.dmarkman@mac.com> <441B2674.9010409@willicon.de> <13577405.1142634732776.JavaMail.dmarkman@mac.com> <441B4182.8010407@willicon.de> <92CD0D6C-5BE8-426E-A46D-99452059FF49@mac.com> <441BBB2D.8030305@willicon.de> <441C4088.5090905@willicon.de> <64BC1E23-FDDE-4CE6-8863-CFC881CBC224@mac.com> Message-ID: Hi All, Is the Auth package able to work properly on non Mac OS's? It was not clear from the doc or download. Thanks! - Doug From dmarkman at mac.com Mon Mar 20 08:15:22 2006 From: dmarkman at mac.com (Dmitry Markman) Date: Mon, 20 Mar 2006 10:15:22 -0500 Subject: [Rxtx] Mac OS X RXTX java installer In-Reply-To: References: <07D0DE29-BA32-4CFE-B036-66BC6423D385@buechse.de> <441AE3E0.2030503@willicon.de> <12531986.1142622114996.JavaMail.dmarkman@mac.com> <441B2674.9010409@willicon.de> <13577405.1142634732776.JavaMail.dmarkman@mac.com> <441B4182.8010407@willicon.de> <92CD0D6C-5BE8-426E-A46D-99452059FF49@mac.com> <441BBB2D.8030305@willicon.de> <441C4088.5090905@willicon.de> <64BC1E23-FDDE-4CE6-8863-CFC881CBC224@mac.com> Message-ID: <217312D8-CCCA-4859-ABA6-32DF1CC817B9@mac.com> thanks Trent, for putting it on ftp server On Mar 20, 2006, at 9:52 AM, Trent Jarvi wrote: > A fresh checkout worked. Here is a copy of the tree (just the > installer bits) > > ftp://ftp.qbang.org/pub/rxtx/MacOSX-installer.zip > Dmitry Markman From dmarkman at mac.com Mon Mar 20 09:14:03 2006 From: dmarkman at mac.com (Dmitry Markman) Date: Mon, 20 Mar 2006 11:14:03 -0500 Subject: [Rxtx] Mac OS X RXTX java installer In-Reply-To: References: <07D0DE29-BA32-4CFE-B036-66BC6423D385@buechse.de> <441AE3E0.2030503@willicon.de> <12531986.1142622114996.JavaMail.dmarkman@mac.com> <441B2674.9010409@willicon.de> <13577405.1142634732776.JavaMail.dmarkman@mac.com> <441B4182.8010407@willicon.de> <92CD0D6C-5BE8-426E-A46D-99452059FF49@mac.com> <441BBB2D.8030305@willicon.de> <441C4088.5090905@willicon.de> <64BC1E23-FDDE-4CE6-8863-CFC881CBC224@mac.com> Message-ID: <4DEBA6F0-DA45-4E84-823E-1F1AC48BDCCC@mac.com> no it will work only on mac os x however it's harmless to run it on other platform if you want to use it for other platform you have to do the following (I'll do it for linux) 1. modify RXTXInstaller class method public static RXTXInstaller getInstance() public static RXTXInstaller getInstance() { String osName = System.getProperty("os.name").toLowerCase(); if(osName.startsWith("mac")){ return new gnu.io.installer.macosx.MACOSXRXTXInstaller(); } else if(osName.startsWith("windows")){ return new gnu.io.installer.windows.WindowsRXTXInstaller(); }else if(osName.startsWith("linux")){ return new gnu.io.installer.linux.LinuxRXTXInstaller(); } return null; } 2. create folder gnu/io/installer/linux/ 3. create class Linux386RXTXInstaller package gnu.io.installer.linux; import java.io.File; public class Linux386RXTXInstaller extends gnu.io.installer.RXTXInstaller{ public Linux386RXTXInstaller(){ createJarFolder(); createLibFolder(); addJarResource("RXTXcomm.jar","/gnu/io/installer/resources/ linux/jar/RXTXcomm.dat"); addLibResource("librxtxSerial.so","/gnu/io/installer/ resources/linux/lib/librxtxSerial.so"); } protected void createJarFolder(){ String javaHome = System.getProperty("java.home"); char separator = File.separatorChar; jarFolder = new File(javaHome+separator+"lib"+separator+"ext"); } protected void createLibFolder(){ String javaHome = System.getProperty("java.home"); char separator = File.separatorChar; libFolder = new File(javaHome+separator+"bin"); } public void runPreProcess() {} //put here some action you need public void runPostProcess() {} //put here some action you need } 4. create folder /gnu/io/installer/resources/linux/jar and put there linux's version of RXTXcomm.dat (which is renamed RXTXcomm.jar) 5. create folder /gnu/io/installer/resources/linux/lib and put there linux's version of librxtxSerial. so 6. make sure that RXTXInstaller.jar has the following items: /gnu/io/installer/resources/linux/jar/RXTXcomm.jar /gnu/io/installer/resources/linux/lib/librxtxSerial.so 7. modify file installer.pref: jar file RXTXInstaller.jar must have the following item /gnu/io/installer/installer.pref that's basically it for windows you have to do the similar things: just replace linux to windows and librxtxSerial.so to rxtxSerial.dll and create appropriate gnu.io.installer.windows.WindowsRXTXInstaller class package gnu.io.installer.windows; import java.io.File; public class WindowsRXTXInstaller extends gnu.io.installer.RXTXInstaller{ public WindowsRXTXInstaller(){ createJarFolder(); createLibFolder(); addJarResource("RXTXcomm.jar","/gnu/io/installer/resources/ windows/jar/RXTXcomm.dat"); addLibResource("librxtxSerial.so","/gnu/io/installer/ resources/windows/lib/rxtxSerial.dll"); } protected void createJarFolder(){ String javaHome = System.getProperty("java.home"); char separator = File.separatorChar; jarFolder = new File(javaHome+separator+"lib"+separator+"ext"); } protected void createLibFolder(){ String javaHome = System.getProperty("java.home"); char separator = File.separatorChar; libFolder = new File(javaHome+separator+"bin"); } public void runPreProcess() {} //put here some action you need public void runPostProcess() {} //put here some action you need } installer.pref will look like On Mar 20, 2006, at 10:08 AM, Dr. Douglas Lyon wrote: > Hi All, > Is the Auth package able to work properly on > non Mac OS's? > It was not clear from the doc or download. > > Thanks! > - Doug > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx Dmitry Markman From joachim at buechse.de Mon Mar 20 10:49:06 2006 From: joachim at buechse.de (Joachim Buechse) Date: Mon, 20 Mar 2006 18:49:06 +0100 Subject: [Rxtx] BUG: Lock file stays even if port opening fails Message-ID: This was only tested on MacOSX but looking at the code, it should be true for all systems that use lock_uucp. I am opening a port which can not be opened (dialup port of a telephone paired via bluetooth but currently not reachable). The lock file is created and stays arround, even though the port open failed. After looking a bit through the code (of 2.17), I really wonder if it wouldn't be a good idea to make the "locking" an explicit operation called from the java code. This would certainly simplify the generation of meaningfull exceptions (and java based debugging). Maybe even the handling of "preopened" ports should be in the Java part of the lib (again for java based debugging puposes). That beeing said, I have no idea if this would be possible for the 2.07 implementation. Regards, Joachim From tjarvi at qbang.org Mon Mar 20 11:24:22 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 20 Mar 2006 11:24:22 -0700 (MST) Subject: [Rxtx] BUG: Lock file stays even if port opening fails In-Reply-To: References: Message-ID: On Mon, 20 Mar 2006, Joachim Buechse wrote: > This was only tested on MacOSX but looking at the code, it should be true > for all systems that use lock_uucp. > > I am opening a port which can not be opened (dialup port of a telephone > paired via bluetooth but currently not reachable). The lock file is > created and stays arround, even though the port open failed. > > > After looking a bit through the code (of 2.17), I really wonder if it > wouldn't be a good idea to make the "locking" an explicit operation > called from the java code. This would certainly simplify the generation > of meaningfull exceptions (and java based debugging). > Maybe even the handling of "preopened" ports should be in the Java part > of the lib (again for java based debugging puposes). That beeing said, I > have no idea if this would be possible for the 2.07 implementation. > > Regards, Hi Joachim It should be possible in the 2.0-7 implementation too. The calls to RXTXPort.java would not change. We would just do more there Moving more of that logic into Java would be better as many people don't like to look at C code. There is a liblockdev on most Linux distros that can do most of the C code and would be easier to use. The problem is embeded devices will not have that library. The preopened port code has not been really tested. That was a last minute request in a product cycle. I expect it will be tested this year though. As I recall, some devices really do not like CD raising on open. The preopened ports then allow people to mess around in java without power cycling the devices or losing data. -- Trent Jarvi tjarvi at qbang.org From joachim at buechse.de Mon Mar 20 12:01:08 2006 From: joachim at buechse.de (Joachim Buechse) Date: Mon, 20 Mar 2006 20:01:08 +0100 Subject: [Rxtx] BUG: Lock file stays even if port opening fails In-Reply-To: References: Message-ID: Hi Trent, What is your general feeling about moving code to Java? The last days I have been reading quite a bit of the code and there are several things, that might not work as expected. I'll give you two examples from is_device_locked: if LOCKDIR == /var/spool/locks the directory /var/spool/lock will not be checked. LOCKDIR is not checked for lockfiles with unexpected pefixes While these things have probably never been discovered in production, they are still possibly incorrect implementations. If it was Java code, I would write some unit tests producing the errors that could later be corrected. PS: One could imagine to actually implement the whole lockfile handling in Java using some native routines to get the values required (pid, st_dev, st_rdev, ...). On 20.03.2006, at 19:24, Trent Jarvi wrote: > On Mon, 20 Mar 2006, Joachim Buechse wrote: > >> This was only tested on MacOSX but looking at the code, it should >> be true for all systems that use lock_uucp. >> >> I am opening a port which can not be opened (dialup port of a >> telephone paired via bluetooth but currently not reachable). The >> lock file is created and stays arround, even though the port open >> failed. >> >> >> After looking a bit through the code (of 2.17), I really wonder if >> it wouldn't be a good idea to make the "locking" an explicit >> operation called from the java code. This would certainly simplify >> the generation of meaningfull exceptions (and java based debugging). >> Maybe even the handling of "preopened" ports should be in the Java >> part of the lib (again for java based debugging puposes). That >> beeing said, I have no idea if this would be possible for the 2.07 >> implementation. >> >> Regards, > > Hi Joachim > > It should be possible in the 2.0-7 implementation too. The calls > to RXTXPort.java would not change. We would just do more there > Moving more of that logic into Java would be better as many people > don't like to look at C code. There is a liblockdev on most Linux > distros that can do most of the C code and would be easier to use. > The problem is embeded devices will not have that library. > > The preopened port code has not been really tested. That was a > last minute request in a product cycle. I expect it will be tested > this year though. As I recall, some devices really do not like CD > raising on open. The preopened ports then allow people to mess > around in java without power cycling the devices or losing data. > > -- > Trent Jarvi > tjarvi at qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Mon Mar 20 12:21:02 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 20 Mar 2006 12:21:02 -0700 (MST) Subject: [Rxtx] BUG: Lock file stays even if port opening fails In-Reply-To: References: Message-ID: On Mon, 20 Mar 2006, Joachim Buechse wrote: > Hi Trent, > > What is your general feeling about moving code to Java? The last days I > have been reading quite a bit of the code and there are several things, > that might not work as expected. > > I'll give you two examples from is_device_locked: > > if LOCKDIR == /var/spool/locks the directory /var/spool/lock will not be > checked. > LOCKDIR is not checked for lockfiles with unexpected pefixes > > While these things have probably never been discovered in production, > they are still possibly incorrect implementations. If it was Java code, I > would write some unit tests producing the errors that could later be > corrected. > > PS: One could imagine to actually implement the whole lockfile handling > in Java using some native routines to get the values required (pid, > st_dev, st_rdev, ...). Hi Joachim I like the idea of moving more of the code into java but there are some things to consider. If you break this into multiple JNI calls, the performance will drop considerably during enumeration of ports. We are looking for 256 ports per dev type vs (16? in Sun's 2.0 and fewer types). Its hard to make assumptions. I've seen virtual ports start at /dev/foo100 for instance. It works out to over 7500 ports on Linux if you enable them all. We already trim that back by default. See Linux-all-ports in RXTXCommDriver.java. There are also native libraries that rxtx can link to. If you move too much into Java, linking to 'standard' libraries with distros will break. "configure --enable-liblock=yes" will not be doable. This is probably a favorable way with RedHat, Debian, Suse and others. Thats the right thing to do if there will be rpms, dpkg, .. For those reasons, I think it still make sense to keep it to a minimal ~3 calls to JNI code that we can use for speed and versatility. lock() isLocked(), unlock() perhaps. When I say speed, its more about avoiding crossing the JNI layer multiple times than java vs C performance. With versatility I think liblock is the right way for most but not all (embeded) linux distros. -- Trent Jarvi tjarvi at qbang.org From joachim at buechse.de Mon Mar 20 12:42:04 2006 From: joachim at buechse.de (Joachim Buechse) Date: Mon, 20 Mar 2006 20:42:04 +0100 Subject: [Rxtx] BUG: Lock file stays even if port opening fails In-Reply-To: References: Message-ID: <82C19FE7-DDCB-45B6-B2C9-7606B66F0124@buechse.de> Ok, what about providing a default implementation in Java? The RXTXCommDriver would call a (native) function useNativeLocking and if it returns true, call the native functions for lock() isLocked (), unlock(), else is would use the Java based default implementation. This could possibly be overriden by a property (again for debugging). Joachim On 20.03.2006, at 20:21, Trent Jarvi wrote: > On Mon, 20 Mar 2006, Joachim Buechse wrote: > >> Hi Trent, >> >> What is your general feeling about moving code to Java? The last >> days I have been reading quite a bit of the code and there are >> several things, that might not work as expected. >> >> I'll give you two examples from is_device_locked: >> >> if LOCKDIR == /var/spool/locks the directory /var/spool/lock will >> not be checked. >> LOCKDIR is not checked for lockfiles with unexpected pefixes >> >> While these things have probably never been discovered in >> production, they are still possibly incorrect implementations. If >> it was Java code, I would write some unit tests producing the >> errors that could later be corrected. >> >> PS: One could imagine to actually implement the whole lockfile >> handling in Java using some native routines to get the values >> required (pid, st_dev, st_rdev, ...). > > Hi Joachim > > I like the idea of moving more of the code into java but there are > some things to consider. > > If you break this into multiple JNI calls, the performance will > drop considerably during enumeration of ports. We are looking for > 256 ports per dev type vs (16? in Sun's 2.0 and fewer types). Its > hard to make assumptions. I've seen virtual ports start at /dev/ > foo100 for instance. > > It works out to over 7500 ports on Linux if you enable them all. > We already trim that back by default. See Linux-all-ports in > RXTXCommDriver.java. > > There are also native libraries that rxtx can link to. If you move > too much into Java, linking to 'standard' libraries with distros > will break. "configure --enable-liblock=yes" will not be doable. > This is probably a favorable way with RedHat, Debian, Suse and > others. Thats the right thing to do if there will be rpms, dpkg, .. > > For those reasons, I think it still make sense to keep it to a > minimal ~3 calls to JNI code that we can use for speed and > versatility. lock() isLocked(), unlock() perhaps. When I say > speed, its more about avoiding crossing the JNI layer multiple > times than java vs C performance. With versatility I think liblock > is the right way for most but not all (embeded) linux distros. > > -- > Trent Jarvi > tjarvi at qbang.org > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Mon Mar 20 12:44:47 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 20 Mar 2006 12:44:47 -0700 (MST) Subject: [Rxtx] BUG: Lock file stays even if port opening fails In-Reply-To: <82C19FE7-DDCB-45B6-B2C9-7606B66F0124@buechse.de> References: <82C19FE7-DDCB-45B6-B2C9-7606B66F0124@buechse.de> Message-ID: On Mon, 20 Mar 2006, Joachim Buechse wrote: > Ok, what about providing a default implementation in Java? > > The RXTXCommDriver would call a (native) function useNativeLocking and if > it returns true, call the native functions for lock() isLocked(), > unlock(), else is would use the Java based default implementation. This > could possibly be overriden by a property (again for debugging). > Hi Joachim That would be OK with me. -- Trent Jarvi tjarvi at qbang.org From dmarkman at mac.com Mon Mar 20 22:27:45 2006 From: dmarkman at mac.com (Dmitry Markman) Date: Tue, 21 Mar 2006 00:27:45 -0500 Subject: [Rxtx] binaries request Message-ID: <42702213-C222-4937-A585-7CFB17E47608@mac.com> Hi can somebody send me latest linux and windows binaries, please? or where I can find them (I didn't find them in the latest tareball) I gave up with my cygwin: something wrong I have no idea what java doesn't understand /cygwin/c syntax after I changed makefile it did java part but after that gcc 3.4.4 started to complain I set buffer length to 999 lines but I didn't get beginning of the story something wrong with my 1.4.2_09/include/jni.h gcc doesn't like it anyway I gave up thanks in advance Dmitry Markman -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060320/f8cbc57c/attachment-0031.html From tjarvi at qbang.org Mon Mar 20 22:36:48 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 20 Mar 2006 22:36:48 -0700 (MST) Subject: [Rxtx] binaries request In-Reply-To: <42702213-C222-4937-A585-7CFB17E47608@mac.com> References: <42702213-C222-4937-A585-7CFB17E47608@mac.com> Message-ID: On Tue, 21 Mar 2006, Dmitry Markman wrote: > Hi > can somebody send me latest linux and windows binaries, please? > > or where I can find them (I didn't find them in the latest tareball) > > I gave up with my cygwin: something wrong I have no idea what > java doesn't understand /cygwin/c syntax > after I changed makefile it did java part > but after that gcc 3.4.4 started to complain > I set buffer length to 999 lines but I didn't get beginning of the story > something wrong with my 1.4.2_09/include/jni.h gcc doesn't like it > anyway I gave up > > thanks in advance > Hi Dmitry The bins are here: ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7-bins-r2.zip Here are the files in the zip you want. Jar: rxtx-2.1-7-bins-r2/RXTXcomm.jar Windows: rxtx-2.1-7-bins-r2/Windows/i368-mingw32/rxtxSerial.dll Linux (x86) rxtx-2.1-7-bins-r2/Linux/i686-unknown-linux-gnu/librxtxSerial.so There are others in there including Parallel port support but those are the main ones for testing. -- Trent Jarvi tjarvi at qbang.org From dmarkman at mac.com Mon Mar 20 23:05:59 2006 From: dmarkman at mac.com (Dmitry Markman) Date: Tue, 21 Mar 2006 01:05:59 -0500 Subject: [Rxtx] binaries request In-Reply-To: References: <42702213-C222-4937-A585-7CFB17E47608@mac.com> Message-ID: thank you very much but windows's readme says: rxtxSerial.dll had to be recomopiled to link in missing native methods. should I ignore it? or what? thanks again also I understand that I should use mingw not cygwin I'll try to install mingw On Mar 21, 2006, at 12:36 AM, Trent Jarvi wrote: > On Tue, 21 Mar 2006, Dmitry Markman wrote: > >> Hi >> can somebody send me latest linux and windows binaries, please? >> >> or where I can find them (I didn't find them in the latest tareball) >> >> I gave up with my cygwin: something wrong I have no idea what >> java doesn't understand /cygwin/c syntax >> after I changed makefile it did java part >> but after that gcc 3.4.4 started to complain >> I set buffer length to 999 lines but I didn't get beginning of the >> story >> something wrong with my 1.4.2_09/include/jni.h gcc doesn't like it >> anyway I gave up >> >> thanks in advance >> > > Hi Dmitry > > The bins are here: > > ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7-bins-r2.zip > > Here are the files in the zip you want. > > Jar: > > rxtx-2.1-7-bins-r2/RXTXcomm.jar > > Windows: > > rxtx-2.1-7-bins-r2/Windows/i368-mingw32/rxtxSerial.dll > > Linux (x86) > > rxtx-2.1-7-bins-r2/Linux/i686-unknown-linux-gnu/librxtxSerial.so > > There are others in there including Parallel port support but those > are the main ones for testing. > > -- > Trent Jarvi > tjarvi at qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx Dmitry Markman From tjarvi at qbang.org Mon Mar 20 23:20:33 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 20 Mar 2006 23:20:33 -0700 (MST) Subject: [Rxtx] binaries request In-Reply-To: References: <42702213-C222-4937-A585-7CFB17E47608@mac.com> Message-ID: On Tue, 21 Mar 2006, Dmitry Markman wrote: > thank you very much > > but windows's readme says: > rxtxSerial.dll had to be recomopiled to link in missing native methods. > > should I ignore it? or what? > Hi Dmitry That dll should be OK. r2 is the recompile linked to the missing native method. The readme explains why it was recompiled; fuser.o was not linked into the dll in the first release. -- Trent Jarvi tjarvi at qbang.org From ariantristan at yahoo.com Mon Mar 20 23:55:24 2006 From: ariantristan at yahoo.com (Lambok Sianturi) Date: Mon, 20 Mar 2006 22:55:24 -0800 (PST) Subject: [Rxtx] jvm issue Message-ID: <20060321065524.94779.qmail@web50701.mail.yahoo.com> Hi All, This is my first time to join RxTx mailing list. I thank you all for allowing others to sign in in requests help. I use the latest RxTx lib in Fedora 3 with java version 1.4.2_09 b05. And I got this error: # # An unexpected error has been detected by HotSpot Virtual Machine: # # SIGSEGV (0xb) at pc=0x00bf27f3, pid=2633, tid=3086112448 # # Java VM: Java HotSpot(TM) Client VM (1.4.2_09-b05 mixed mode) # Problematic frame: # C [ld-linux.so.2+0xa7f3] # # An error report file with more information is saved as hs_err_pid2633.log # # If you would like to submit a bug report, please visit: # http://java.sun.com/webapps/bugreport/crash.jsp # ./run.sh: line 3: 2633 Aborted /usr/local/java/bin/java -Djava.library.path=/usr/local/java/jre/lib/ -Djsmsengine.debug=true -classpath jsmsengine.jar:smsgateway.jar:classes12.jar:RXTXcomm.jar:. com.api.sms.SMSServer What is the jvm depedency for the latest library? Can I use 1.4.2_09 b05? Thanks in advance. Arian --------------------------------- Yahoo! Mail Use Photomail to share photos without annoying attachments. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060320/83d58dd7/attachment-0031.html From f.frumento at ngi.it Tue Mar 21 00:21:47 2006 From: f.frumento at ngi.it (Fabio Frumento) Date: Tue, 21 Mar 2006 08:21:47 +0100 Subject: [Rxtx] Javadoc on the go Message-ID: <441FA98B.9050701@ngi.it> Hi Trent, sorry for the big delay but my job is running wild, i was out for some time but now i'm back and ready to continue the javadoc for Rxtx. Did you used the last javadoc patch i sent you ? let me know if i have to send it to you again or not. regards Fabio From lyon at docjava.com Tue Mar 21 00:51:18 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Tue, 21 Mar 2006 02:51:18 -0500 Subject: [Rxtx] lock files Message-ID: Hi All, You know, if the use of lock files were under Java control (rather than a build-time decision), it might enable a more unified binary distro. It might also facilitate quick prototyping of non-lock file approaches to resolving serial port contention issues (i.e., mac-like approaches vs. linux approaches, etc.). I realize that this is a radical overhaul of the lock file policy issue. Also, it may harm performance. On the other hand, our benchmarks on JNI overhead for modern processors indicate performance impact should be minimal. Perhaps it is more of an issue with the toybox systems. Suppose there were a class with a reasonable default...someone might write: SerialPortLockPolicy.setPolicy(SerialPortLockPolicy.UNIX_LOCK_FILE); SerialPortLockPolicy.setPolicy(SerialPortLockPolicy.NO_LOCK_CHECKING); SerialPortLockPolicy.setPolicy(SerialPortLockPolicy.MAC_STYLE); Thus, we could have a run-time reconfiguration of the serial port lock policy. A special NO_LOCK version of the binary would no longer be required. Any thoughts on this? Thanks! - Doug From joachim at buechse.de Tue Mar 21 03:09:09 2006 From: joachim at buechse.de (Joachim Buechse) Date: Tue, 21 Mar 2006 11:09:09 +0100 Subject: [Rxtx] lock files In-Reply-To: References: Message-ID: <8E12916A-1B9A-4FF2-B684-E2D1C794221B@buechse.de> This is pretty much what I thought about when I suggested, that the default behaviour could be overwritten with a property. I am very much in favor of this approach. In particular this allows much easier debugging for PC based java developers. I think big parts of the Java (and maybe some parts of the C code) could use a bit of a structural workover (unit tests, javadoc, synchronization, etc). Maybe there should be a CVS branch for this experimental version. I'd be happy to contribute a first workover for some of the Java code. Designing for testability and implementing a good bunch of unit tests has been a strategy that worked quite well in the Java projects I lead. And it ultimately allows more liberal change permission. Regards, Joachim On 21.03.2006, at 08:51, Dr. Douglas Lyon wrote: > Hi All, > You know, if the use of lock files were > under Java control (rather than a build-time decision), > it might enable a more unified binary distro. It might also > facilitate quick prototyping of non-lock file approaches > to resolving serial port contention issues (i.e., mac-like > approaches vs. linux approaches, etc.). > > I realize that this is a radical overhaul of the lock file policy > issue. Also, it may harm performance. On the other hand, > our benchmarks on JNI overhead for modern processors indicate > performance impact should be minimal. Perhaps it is more of > an issue with the toybox systems. > > Suppose there were a class with a reasonable default...someone > might write: > SerialPortLockPolicy.setPolicy(SerialPortLockPolicy.UNIX_LOCK_FILE); > SerialPortLockPolicy.setPolicy(SerialPortLockPolicy.NO_LOCK_CHECKING); > SerialPortLockPolicy.setPolicy(SerialPortLockPolicy.MAC_STYLE); > > Thus, we could have a run-time reconfiguration of the serial port lock > policy. A special NO_LOCK version of the binary would no longer > be required. > > Any thoughts on this? > > Thanks! > - Doug > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From joachim at buechse.de Tue Mar 21 06:23:08 2006 From: joachim at buechse.de (Joachim Buechse) Date: Tue, 21 Mar 2006 14:23:08 +0100 Subject: [Rxtx] PATCH: use of ioctl(fd, TIOCEXCL) instead of lockfiles Message-ID: <923AE774-EEA2-4911-92D8-32BB27802C8B@buechse.de> Here is the patch for the ioctl(fd, TIOCEXCL). I have verified this only for OSX 10.4.5, hence it is only defined for APPLE. However, it should work at least for Solaris as well. If a process has requested TIOEXCL further open calls by other user processes will fail. The patch also disables uucp style locking for APPLE. Obviously this is discussable. I think it is the way to go, as it eliminates creating the lock directory which doesnt exist on the standard installation and it eliminates messing with the system group definitions (adding users to group uucp). Regarding the possibility of root processes opening a device which is locked - I consider this a feature not a potential problem. It is highly unlikely, that somebody is crazy enough to run a JavaVM as root (unless he has no other means of getting a restricted IP port opened, ie doesnt understand ipfw). Anyway, even if the process runs as root, it fails when calling ioctl(fd, TIOCEXCL). It could however still open the port to listen for RING events. I.e. a fax server which needs to see incoming calls but otherwise doesnt want to block the port. So the only case where the proposed mechanism fails is, if an incorrectly implemented process running as root conflicts with a user process. I think this can be accepted. Regards, Joachim PS: If this patch is generally accepted, the installer and Mac doku should obviously be changed as well. Index: SerialImp.c =================================================================== RCS file: /usr/local/cvsroot/rxtx-devel/src/SerialImp.c,v retrieving revision 1.46.2.187 diff -u -r1.46.2.187 SerialImp.c --- SerialImp.c 29 Jan 2006 22:19:04 -0000 1.46.2.187 +++ SerialImp.c 21 Mar 2006 12:59:16 -0000 @@ -656,6 +656,25 @@ fd=OPEN (filename, O_RDWR | O_NOCTTY | O_NONBLOCK ); } while (fd < 0 && errno==EINTR); +#ifdef OPEN_EXCL + // Note that open() follows POSIX semantics: multiple open() calls to + // the same file will succeed unless the TIOCEXCL ioctl is issued. + // This will prevent additional opens except by root-owned processes. + // See tty(4) ("man 4 tty") and ioctl(2) ("man 2 ioctl") for details. + + if (fd >= 0 && (ioctl(fd, TIOCEXCL) == -1)) + { + sprintf( message, "open: exclusive access denied for % s\n", + filename ); + report( message ); + report_error( message ); + + close(fd); + goto fail; + } +#endif /* OPEN_EXCL */ + + if( configure_port( fd ) ) goto fail; (*env)->ReleaseStringUTFChars( env, jstr, filename ); sprintf( message, "open: fd returned is %i\n", fd ); Index: SerialImp.h =================================================================== RCS file: /usr/local/cvsroot/rxtx-devel/src/SerialImp.h,v retrieving revision 1.11.2.49 diff -u -r1.11.2.49 SerialImp.h --- SerialImp.h 5 Jul 2005 17:47:21 -0000 1.11.2.49 +++ SerialImp.h 21 Mar 2006 12:59:17 -0000 @@ -135,7 +135,8 @@ /*# define LOCKDIR "/var/spool/uucp"*/ # define LOCKDIR "/var/lock" # define LOCKFILEPREFIX "LK." -# define UUCP +/*# define UUCP*/ +# define OPEN_EXCL #endif /* __APPLE__ */ #if defined(__NetBSD__) # define DEVICEDIR "/dev/" From tjarvi at qbang.org Tue Mar 21 10:26:08 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 21 Mar 2006 10:26:08 -0700 (MST) Subject: [Rxtx] Javadoc on the go In-Reply-To: <441FA98B.9050701@ngi.it> References: <441FA98B.9050701@ngi.it> Message-ID: On Tue, 21 Mar 2006, Fabio Frumento wrote: > Hi Trent, > > sorry for the big delay but my job is running wild, i was out for some > time but now i'm back and ready to continue the javadoc for Rxtx. > > Did you used the last javadoc patch i sent you ? let me know if i have to > send it to you again or not. > > regards > > Fabio Hi Fabio The patch is in the rxtx mail-list archives. It will be going in soon. I did not see a time critical portion. I'll probably be going through the list since the last batch of patches this weekend and putting them into CVS. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Tue Mar 21 10:57:18 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 21 Mar 2006 10:57:18 -0700 (MST) Subject: [Rxtx] jvm issue In-Reply-To: <20060321065524.94779.qmail@web50701.mail.yahoo.com> References: <20060321065524.94779.qmail@web50701.mail.yahoo.com> Message-ID: On Mon, 20 Mar 2006, Lambok Sianturi wrote: > Hi All, > This is my first time to join RxTx mailing list. I thank you all for allowing others to sign in in requests help. > I use the latest RxTx lib in Fedora 3 with java version 1.4.2_09 b05. And I got this error: > > # > # An unexpected error has been detected by HotSpot Virtual Machine: > # > # SIGSEGV (0xb) at pc=0x00bf27f3, pid=2633, tid=3086112448 > # > # Java VM: Java HotSpot(TM) Client VM (1.4.2_09-b05 mixed mode) > # Problematic frame: > # C [ld-linux.so.2+0xa7f3] A native library loading error? What happens if you recompile rxtx on your system and install that? This sounds like an ABI problem? rxtx 2.1-7 was compiled with a gcc 2.96 toolchain as I recall. The hope is newer system will be backwards compatible. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Tue Mar 21 11:05:29 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 21 Mar 2006 11:05:29 -0700 (MST) Subject: [Rxtx] PATCH: use of ioctl(fd, TIOCEXCL) instead of lockfiles In-Reply-To: <923AE774-EEA2-4911-92D8-32BB27802C8B@buechse.de> References: <923AE774-EEA2-4911-92D8-32BB27802C8B@buechse.de> Message-ID: On Tue, 21 Mar 2006, Joachim Buechse wrote: > Here is the patch for the ioctl(fd, TIOCEXCL). I have verified this only > for OSX 10.4.5, hence it is only defined for APPLE. However, it should > work at least for Solaris as well. > > If a process has requested TIOEXCL further open calls by other user > processes will fail. > > The patch also disables uucp style locking for APPLE. Obviously this is > discussable. I think it is the way to go, as it eliminates creating the > lock directory which doesnt exist on the standard installation and it > eliminates messing with the system group definitions (adding users to > group uucp). > > Regarding the possibility of root processes opening a device which is > locked - I consider this a feature not a potential problem. It is highly > unlikely, that somebody is crazy enough to run a JavaVM as root (unless > he has no other means of getting a restricted IP port opened, ie doesnt > understand ipfw). Anyway, even if the process runs as root, it fails when > calling ioctl(fd, TIOCEXCL). It could however still open the port to > listen for RING events. I.e. a fax server which needs to see incoming > calls but otherwise doesnt want to block the port. So the only case where > the proposed mechanism fails is, if an incorrectly implemented process > running as root conflicts with a user process. I think this can be > accepted. > > Regards, > Joachim > > PS: If this patch is generally accepted, the installer and Mac doku > should obviously be changed as well. > > > Index: SerialImp.c > =================================================================== > RCS file: /usr/local/cvsroot/rxtx-devel/src/SerialImp.c,v > retrieving revision 1.46.2.187 > diff -u -r1.46.2.187 SerialImp.c > --- SerialImp.c 29 Jan 2006 22:19:04 -0000 1.46.2.187 > +++ SerialImp.c 21 Mar 2006 12:59:16 -0000 > @@ -656,6 +656,25 @@ > fd=OPEN (filename, O_RDWR | O_NOCTTY | O_NONBLOCK ); > } while (fd < 0 && errno==EINTR); > > +#ifdef OPEN_EXCL > + // Note that open() follows POSIX semantics: multiple open() > calls to > + // the same file will succeed unless the TIOCEXCL ioctl is > issued. > + // This will prevent additional opens except by root-owned > processes. > + // See tty(4) ("man 4 tty") and ioctl(2) ("man 2 ioctl") for > details. > + > + if (fd >= 0 && (ioctl(fd, TIOCEXCL) == -1)) > + { > + sprintf( message, "open: exclusive access denied for % > s\n", > + filename ); > + report( message ); > + report_error( message ); > + > + close(fd); > + goto fail; > + } > +#endif /* OPEN_EXCL */ > + > + > if( configure_port( fd ) ) goto fail; > (*env)->ReleaseStringUTFChars( env, jstr, filename ); > sprintf( message, "open: fd returned is %i\n", fd ); > Index: SerialImp.h > =================================================================== > RCS file: /usr/local/cvsroot/rxtx-devel/src/SerialImp.h,v > retrieving revision 1.11.2.49 > diff -u -r1.11.2.49 SerialImp.h > --- SerialImp.h 5 Jul 2005 17:47:21 -0000 1.11.2.49 > +++ SerialImp.h 21 Mar 2006 12:59:17 -0000 > @@ -135,7 +135,8 @@ > /*# define LOCKDIR "/var/spool/uucp"*/ > # define LOCKDIR "/var/lock" > # define LOCKFILEPREFIX "LK." > -# define UUCP > +/*# define UUCP*/ > +# define OPEN_EXCL > #endif /* __APPLE__ */ > #if defined(__NetBSD__) > # define DEVICEDIR "/dev/" > This looks like a good start. What do you think Dmitry? Perhaps all systems with TIOCEXCL defined should use that though. Even if they use lockfiles. It wont hurt anything. That would catch people hacking their own serial apps without checking lockfiles. Its a good idea to avoid C++ style comments in the C portions. Some older systems don't deal with them well. If it's just for Mac OS X, it isn't a big deal. I think it was the Irix compiler that was problematic? -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Tue Mar 21 11:22:05 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 21 Mar 2006 11:22:05 -0700 (MST) Subject: [Rxtx] lock files In-Reply-To: <8E12916A-1B9A-4FF2-B684-E2D1C794221B@buechse.de> References: <8E12916A-1B9A-4FF2-B684-E2D1C794221B@buechse.de> Message-ID: We can try it. Maybe the JNI is much improved. The nice thing about linking into liblock is distros then worry about lockfiles on their systems. This way, we have to deal with any changes that may show up. On Tue, 21 Mar 2006, Joachim Buechse wrote: > This is pretty much what I thought about when I suggested, that the > default behaviour could be overwritten with a property. I am very much in > favor of this approach. In particular this allows much easier debugging > for PC based java developers. > > I think big parts of the Java (and maybe some parts of the C code) could > use a bit of a structural workover (unit tests, javadoc, synchronization, > etc). Maybe there should be a CVS branch for this experimental version. > I'd be happy to contribute a first workover for some of the Java code. > Designing for testability and implementing a good bunch of unit tests has > been a strategy that worked quite well in the Java projects I lead. And > it ultimately allows more liberal change permission. > > Regards, > Joachim > > > On 21.03.2006, at 08:51, Dr. Douglas Lyon wrote: > >> Hi All, >> You know, if the use of lock files were >> under Java control (rather than a build-time decision), >> it might enable a more unified binary distro. It might also >> facilitate quick prototyping of non-lock file approaches >> to resolving serial port contention issues (i.e., mac-like >> approaches vs. linux approaches, etc.). >> >> I realize that this is a radical overhaul of the lock file policy >> issue. Also, it may harm performance. On the other hand, >> our benchmarks on JNI overhead for modern processors indicate >> performance impact should be minimal. Perhaps it is more of >> an issue with the toybox systems. >> >> Suppose there were a class with a reasonable default...someone >> might write: >> SerialPortLockPolicy.setPolicy(SerialPortLockPolicy.UNIX_LOCK_FILE); >> SerialPortLockPolicy.setPolicy(SerialPortLockPolicy.NO_LOCK_CHECKING); >> SerialPortLockPolicy.setPolicy(SerialPortLockPolicy.MAC_STYLE); >> >> Thus, we could have a run-time reconfiguration of the serial port lock >> policy. A special NO_LOCK version of the binary would no longer >> be required. >> >> Any thoughts on this? >> >> Thanks! >> - Doug >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From dmarkman at mac.com Tue Mar 21 16:05:17 2006 From: dmarkman at mac.com (Dmitry Markman) Date: Tue, 21 Mar 2006 18:05:17 -0500 Subject: [Rxtx] PATCH: use of ioctl(fd, TIOCEXCL) instead of lockfiles In-Reply-To: References: <923AE774-EEA2-4911-92D8-32BB27802C8B@buechse.de> Message-ID: <512AC70C-BB86-48F2-A83C-023F35C23BAB@mac.com> I think it's cool, but I'd like to have that property implementation when user can choose between locking mechanism about comments: it's easy to change comments to the C style or we can use extensions of the file to cpp so c++ compiler will be used On Mar 21, 2006, at 1:05 PM, Trent Jarvi wrote: > This looks like a good start. What do you think Dmitry? Perhaps > all systems with TIOCEXCL defined should use that though. Even if > they use lockfiles. It wont hurt anything. That would catch > people hacking their own serial apps without checking lockfiles. > > Its a good idea to avoid C++ style comments in the C portions. > Some older systems don't deal with them well. If it's just for Mac > OS X, it isn't a big deal. I think it was the Irix compiler that > was problematic? Dmitry Markman From dmarkman at mac.com Tue Mar 21 16:13:00 2006 From: dmarkman at mac.com (Dmitry Markman) Date: Tue, 21 Mar 2006 18:13:00 -0500 Subject: [Rxtx] PATCH: use of ioctl(fd, TIOCEXCL) instead of lockfiles In-Reply-To: References: <923AE774-EEA2-4911-92D8-32BB27802C8B@buechse.de> Message-ID: I'd like to add that creating locking folder isn't a big deal we never had a problem related to the lock folders, because we always used installer on mac os x from other hand I'm not very much familiar with iotcl locking approach and I'm not sure it's more efficient Joachim wrote "I think it is the way to go, as it eliminates creating the lock directory which doesnt exist on the standard installation and it eliminates messing with the system group definitions (adding users to group uucp)." but I really didn't have any problem with that 1. doesn't exist on the standard installation there are many-many things that don't exist in the standard installation so I don't think that argument is strong enough 2. messing with the system group definitions I don't think we're messing with the group definition mac os x provides very clear way to set up group's members and together with Greg Guerin AuthKit there is no problem to set those definitions so I don't think that argument is strong either but from other hand using iotcl is more promising and is more elegant On Mar 21, 2006, at 1:05 PM, Trent Jarvi wrote: > > This looks like a good start. What do you think Dmitry? Perhaps > all systems with TIOCEXCL defined should use that though. Even if > they use lockfiles. It wont hurt anything. That would catch > people hacking their own serial apps without checking lockfiles. Dmitry Markman From joachim at buechse.de Wed Mar 22 04:46:45 2006 From: joachim at buechse.de (Joachim Buechse) Date: Wed, 22 Mar 2006 12:46:45 +0100 Subject: [Rxtx] PATCH: use of ioctl(fd, TIOCEXCL) instead of lockfiles In-Reply-To: References: <923AE774-EEA2-4911-92D8-32BB27802C8B@buechse.de> Message-ID: Sorry, I was not very clear with my arguments, so I will try again;-) Please, don't take this as an attack against work that has been done. I think the contributions that have been made in the past were made in a good spirit. But I really believe, that the current solution for OSX has many shortcomings and should be changed as soon as possible. lock files --- The /var/lock folder does not exist on the standard OSX installation, however the standard installation includes several applications that use serial ports (i.e. the FAX capability). This indicates, that the lock folder approach will not work well with system components. Applications for OSX will generally try to live in harmony with system components (except for HP print drivers of course). I think RXTX should follow this approach as well. uucp group --- Accessing serial ports is not an admin privileged operation on OSX. Any user (world) has read/write privileges on /dev/tty*. So the system default is to not enforce any group membership to access these ports. The group uucp however is a system group on all unix systems I know. It exists for certain system processes. A non admin user should in general not be a member of this group. Quite arguably no user should ever be a member of this group. Installer --- My general opinion is, that - no Installer should touch user or group data without warning - no Application Installer should touch groups which are not specific to the very application installed - no Installer should ever add regular users to a system group The current installer injects the installing user in the group uucp without warning about this change and without giving the option to "opt out" of this change. This is a potential security risk (but not currently a real one, as OSX contains no folders belonging to group uucp). The current installer does not work for multi user systems. It puts the installing user in the uucp group. However the installing user is not necessarily the user that will use the application. Putting all users that may use a serial port application in the system group uucp seems like a very invasive approach to me. Besides that, newly created users will not automatically be in the group and hence, serial applications will "break" for new users without obvious reasons. Avoiding the lock files will allow self contained applications (i.e. drag&drop installation). In my eyes this is largely preferable over an installer that requests admin privileges. Adding up all these points indicates very strongly, that the lock-file implementation is not the way to go on OSX. Regards, Joachim On 22.03.2006, at 00:13, Dmitry Markman wrote: > I'd like to add that > > creating locking folder isn't a big deal > we never had a problem related to the lock folders, because we > always used installer on mac os x > from other hand I'm not very much familiar with iotcl locking > approach and I'm not sure it's more efficient > > Joachim wrote "I think it is the way to go, as it eliminates > creating the lock directory which doesnt exist on the standard > installation and it eliminates messing with the system group > definitions (adding users to group uucp)." but I really didn't have > any problem with that > > 1. doesn't exist on the standard installation > there are many-many things that don't exist in the standard > installation so I don't think that argument is strong enough > 2. messing with the system group definitions > I don't think we're messing with the group definition > mac os x provides very clear way to set up group's members and > together with Greg Guerin AuthKit there is no problem to set those > definitions > so I don't think that argument is strong either > but from other hand using iotcl is more promising and is more elegant > > > > On Mar 21, 2006, at 1:05 PM, Trent Jarvi wrote: > >> >> This looks like a good start. What do you think Dmitry? Perhaps >> all systems with TIOCEXCL defined should use that though. Even if >> they use lockfiles. It wont hurt anything. That would catch >> people hacking their own serial apps without checking lockfiles. > > Dmitry Markman > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From dmarkman at mac.com Wed Mar 22 05:27:13 2006 From: dmarkman at mac.com (Dmitry Markman) Date: Wed, 22 Mar 2006 07:27:13 -0500 Subject: [Rxtx] PATCH: use of ioctl(fd, TIOCEXCL) instead of lockfiles In-Reply-To: References: <923AE774-EEA2-4911-92D8-32BB27802C8B@buechse.de> Message-ID: <83440CF3-DCD8-41C1-B941-F227232C27E3@mac.com> thanks for the very good explanation I didn't think that you were attacking any thing, so don't worry I just had feeling, that there were more aesthetic reasons for going to ioctl then real necessity now you explained everything quite well (BTW, asfar as I remember installer asks admin password so it wasn't quiet, but it really doesn't matter now) thanks On Mar 22, 2006, at 6:46 AM, Joachim Buechse wrote: > Sorry, I was not very clear with my arguments, so I will try again;-) > > Please, don't take this as an attack against work that has been > done. I think the contributions that have been made in the past > were made in a good spirit. But I really believe, that the current > solution for OSX has many shortcomings and should be changed as > soon as possible. > > lock files > --- > The /var/lock folder does not exist on the standard OSX > installation, however the standard installation includes several > applications that use serial ports (i.e. the FAX capability). This > indicates, that the lock folder approach will not work well with > system components. Applications for OSX will generally try to live > in harmony with system components (except for HP print drivers of > course). I think RXTX should follow this approach as well. > > uucp group > --- > Accessing serial ports is not an admin privileged operation on OSX. > Any user (world) has read/write privileges on /dev/tty*. So the > system default is to not enforce any group membership to access > these ports. The group uucp however is a system group on all unix > systems I know. It exists for certain system processes. A non admin > user should in general not be a member of this group. Quite > arguably no user should ever be a member of this group. > > Installer > --- > My general opinion is, that > - no Installer should touch user or group data without warning > - no Application Installer should touch groups which are not > specific to the very application installed > - no Installer should ever add regular users to a system group > > The current installer injects the installing user in the group uucp > without warning about this change and without giving the option to > "opt out" of this change. This is a potential security risk (but > not currently a real one, as OSX contains no folders belonging to > group uucp). > > The current installer does not work for multi user systems. It puts > the installing user in the uucp group. However the installing user > is not necessarily the user that will use the application. Putting > all users that may use a serial port application in the system > group uucp seems like a very invasive approach to me. Besides that, > newly created users will not automatically be in the group and > hence, serial applications will "break" for new users without > obvious reasons. > > > Avoiding the lock files will allow self contained applications > (i.e. drag&drop installation). In my eyes this is largely > preferable over an installer that requests admin privileges. Adding > up all these points indicates very strongly, that the lock-file > implementation is not the way to go on OSX. > > Regards, > Joachim > > > On 22.03.2006, at 00:13, Dmitry Markman wrote: > >> I'd like to add that >> >> creating locking folder isn't a big deal >> we never had a problem related to the lock folders, because we >> always used installer on mac os x >> from other hand I'm not very much familiar with iotcl locking >> approach and I'm not sure it's more efficient >> >> Joachim wrote "I think it is the way to go, as it eliminates >> creating the lock directory which doesnt exist on the standard >> installation and it eliminates messing with the system group >> definitions (adding users to group uucp)." but I really didn't >> have any problem with that >> >> 1. doesn't exist on the standard installation >> there are many-many things that don't exist in the standard >> installation so I don't think that argument is strong enough >> 2. messing with the system group definitions >> I don't think we're messing with the group definition >> mac os x provides very clear way to set up group's members and >> together with Greg Guerin AuthKit there is no problem to set those >> definitions >> so I don't think that argument is strong either >> but from other hand using iotcl is more promising and is more elegant >> >> >> >> On Mar 21, 2006, at 1:05 PM, Trent Jarvi wrote: >> >>> >>> This looks like a good start. What do you think Dmitry? Perhaps >>> all systems with TIOCEXCL defined should use that though. Even >>> if they use lockfiles. It wont hurt anything. That would catch >>> people hacking their own serial apps without checking lockfiles. >> >> Dmitry Markman >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx Dmitry Markman From lyon at docjava.com Wed Mar 22 06:12:18 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Wed, 22 Mar 2006 08:12:18 -0500 Subject: [Rxtx] sole of a new design pattern Message-ID: Hi All, I have been thinking about how we design the serial port software. I think we need a new design pattern. For lack of a better term, I shall call it: The Parametric Singleton Design Pattern By Douglas A. Lyon ABSTRACT The goal of the singleton design pattern is to make sure that there is one, and only one, instance of a given class. The goal of the parametric singleton design pattern is to make sure that there is one, and only one, instance of a given class with the given parametric values. We parametric singleton design pattern combines the singleton design pattern with a parameter that enables unique creation of instances of a class. These instances are cached. When a user asks for an instance with these parameters, the cache is checked. If the instance is in the cache, the instance is returned, otherwise it is created, added to the cache and then returned. We apply our parametric singleton design pattern to the retrieval of RMI registries bound to a given port. The goal of our system is to make sure that no two RMI registries are listening to the same socket and to make use of the RMI registries after they have been created. RMI registries are used in distributed computation. Introduction The singleton design pattern is meant to ensure that on a single instance of a class exists. It is also meant to provide a global point of access to it. The intent of the parametric singleton design pattern is to ensure that a class has only one instance for a given set of parameter values. It also provides a global point of access to it. Motivation A system cannot tolerate multiple instances of some classes with identical parameters. For example, you cannot have two instances making use of the same serial port, at the same time. You cannot have two instances that are trying to listen to the same socket connection. You cannot have two instances writing to the same file structure at the same time. As the operating system is often thought of as the arbiter of consumed resources (i.e., tape drives, serial ports, etc.) we frequently leave it to an operating system implementation to resolve these contention issues. Even for similar resources (like serial ports) there are few standards for handling contention. For example, serial ports on Linux are locked using a "/var/lock" file. POSIX, on the other hand, uses ioctl mechanisms to prevent contention. A better solution is to make a class that is responsible for keeping track of the instances created from the class. The class is declared final, so that it cannot be subclassed. The class also has a private constructor, so that other classes cannot instance it. The new design pattern is called the parametric singleton design pattern and it provides a way to access and create instances with given parameters. Applicability Use the Parametric Singleton Design Pattern when: 1. There must be exactly one instance of a class with the given parameters. 2. The instances must be accessible to clients from a well-known access point. Structure Insert UML diagram here. Participants The Parametric Singleton Clients that need instances 1. The Parametric Singleton defines an instance upon request from a client, if, and only if, the instance does not already exist. 2. The Parametric Singleton returns the instance to the client. 3. The Parametric Singleton is responsible for creating unique instances from given parameters. Collaborations Clients obtain a reference to a Parametric Singleton instance only through the parametric singleton design pattern. If the instance is left in an improper state (e.g., the serial port was left open) it is NOT the role of the Parametric Singleton Design Pattern to close the IO port. Nor is it the role of the Parametric Singleton Design Pattern to open the port. That role is delegate to some other part of the system. Further, it is not the role of the Parametric Singleton Design Pattern to check out resources. That is, multiple threads can have multiple references to the same resource at the same time. MUTEX locking is delegated to some other part of the system. Consequences The Parametric Singleton Design Pattern has several benefits: 1. Controlled access to parametrically defined instances. Since the Parametric Singleton class encapsulates its instances, there is control over how and when clients access it. 2. Reduced name space. The Parametric Singleton pattern avoids global variables that store instances created from the same parameter. Implementation Here are implementation issues to consider when using the Parametric Singleton pattern: 1. Unique mapping of parameters. The Parametric Singleton pattern requires that there be a mean to isomorphically map the parameter space into the instance space and back again. 2. Ensure unique instances. The Parametric Singleton pattern makes unique instances from parameters, and it does so only once. 3. Cache instances for fast retrieval. The Parametric Singleton pattern must be able to look up instances, given some set of parameters, and do so from some data structure. That is, there must be enough space to hold references to all the instances the program will need. Also, a mechanism is needed to look up and retrieve the instances quickly enough to satisfy the clients. Sample Code public final class ParametricSingletonRmiRegistry { private static Hashtable registry = new Hashtable(100); // use singleton pattern and??????????????????????????????????????????????? // prevent instantiation of RmiRegistryUtils.?????????????????????????????? private ParametricSingletonRmiRegistry() { } // the only instance of the Registry held by the RmiRegistryUtils?????????? public static void listNames(Integer port) { if (!isInCacheAndRunning(port)) return; Registry r = (Registry) registry.get(port); System.out.println("registry on port: " + port); System.out.println("registry: " + r); System.out.println("names: "); try { print(r.list()); } catch (RemoteException e) { In.message(e); } System.out.println("------------------------"); } /**???????????????????????????????????????????????????????????????????????? * Checks whether a Registry has been started on this host????????????????? * in the specified port.?????????????????????????????????????????????????? * If not, it tries to start one.?????????????????????????????????????????? * when it fails to start a Registry, it exits the program????????????????? * with exit code 1.??????????????????????????????????????????????????????? */ public static void restart(int port) { if (isInCacheAndRunning(port)) return; try { startRegistry(port); } catch (RemoteException e) { In.message(e); } } /**???????????????????????????????????????????????????????????????????????? * @param port????????????????????????????????????????????????????????????? * @return true if registry is in cache and running???????????????????????? */ private static boolean isInCacheAndRunning(Integer port) { if (!isRegistryRunning(port.intValue())) return false; if (!isRegistryInCache(port.intValue())) return false; return true; } /**???????????????????????????????????????????????????????????????????????? * @param port????????????????????????????????????????????????????????????? * @return true if we are able to locate a local registry on port.??????????????????????????????????????????????????????????????????????????? */ private static boolean isRegistryRunning(int port) { try { Registry r = LocateRegistry.getRegistry(port); if (r != null) return true; } catch (RemoteException e) { return false; } return false; } /**???????????????????????????????????????????????????????????????????????? * @param port????????????????????????????????????????????????????????????? * @return return true if registry is in cache????????????????????????????? */ private static boolean isRegistryInCache(int port) { if (registry.get(new Integer(port)) == null) return false; return true; } /**???????????????????????????????????????????????????????????????????????? * Restart the registry, if needed.???????????????????????????????????????? * Return the only instance of the registry for consistent global?????????? * using by making use of the Singleton Design Pattern????????????????????? *????????????????????????????????????????????????????????????????????????? * @return the internally held registry instance.?????????????????????????? */ public static Registry getRegistry(Integer port) { restart(port); return (Registry) registry.get(port); } private static void startRegistry(Integer port) throws RemoteException { Registry r; try { r = LocateRegistry.createRegistry(port.intValue()); registry.put(port, r); //r = new sun.rmi.registry.RegistryImpl???????????????????????????? /// (port.intValue());?????????????????????????????????????? // registry.put(port, r);?????????????????????????????????????????? } catch (Exception e) { //e.printStackTrace();????????????????????????????????????????????? r = LocateRegistry.getRegistry(port.intValue()); registry.put(port, r); } } public static void main(String args[]) throws RemoteException { //restart(port);??????????????????????????????????????????????????????? restart(5001); restart(5002); restart(5002); Registry r = LocateRegistry.getRegistry(5002); System.out.println("registry="+r); } } I would very much like to get your feedback on this new design pattern idea. Thank you for your time. Regards, - Doug From david.garnier at trusted-logic.com Wed Mar 22 07:36:10 2006 From: david.garnier at trusted-logic.com (David Garnier) Date: Wed, 22 Mar 2006 15:36:10 +0100 Subject: [Rxtx] sole of a new design pattern In-Reply-To: References: Message-ID: <442160DA.80107@trusted-logic.com> Hello, > The Parametric Singleton Design Pattern The Singleton is the most abused design pattern ever. Good use-cases for this pattern are extremely rare and mostly confined to problems related to hardware resources, like serial ports. > Applicability > > Use the Parametric Singleton Design Pattern when: > 1. There must be exactly one instance of a class with the given > parameters. OK. As I said above, this case this actually very unusual. The Singleton pattern is mostly used when : > 2. The instances must be accessible to clients from a well-known > access point. Using the singleton pattern in this case is just convenient for the programmer. Problems arises pretty quickly, especially if you attempt to unit-test your classes. 1) If your singleton is stateful, or hold on to stateful objects, it means that two different unit tests are not actually independent. Instead of starting with a brand new environment, the result of a test may be affected by the result of a previous test. This problem also arise when with your class relies on a database. In both cases, the solution is to reset your "unique" resource (Singleton or database) at the beginning of the test, which is a pain. Also, while most projects connect to a single database, projects that allow the use of Singletons usually contain several of thems, and new ones may cropped up unnoticed. You quickly end up with test cases that only pass in a certain order, which is a royal pain. 2) You cannot mockup a singleton. Once everyone calls the SomeSingleton class statically, you can't replace your class by SomeSingletonMockup. Furthermore, even for hardware services, the Singleton pattern does not really prevent concurrent accesses. If you start the same program in two different JVMs, unless they somehow shared the state of their "Singletons" (through lock files for example), the Singleton pattern will not prevent concurrent access. Our application uses RXTX, and we routinely encounter cases where another (native) application has already locked the port. Since we cannot modify the native application to recognize lock files, OS-level control is irreplaceable. > > Consequences > The Parametric Singleton Design Pattern has several benefits: > > 1. Controlled access to parametrically defined instances. Since > the Parametric Singleton class encapsulates its instances, there is > control over how and when clients access it. Not really. Once you've returned the instance to a client, you've lost control over it. The client can to whatever it wants with it. You cannot "recall" the instance or claim it back. > 2. Reduced name space. The Parametric Singleton pattern avoids > global variables that store instances created from the same parameter. Sure, but you don't have to rely on a Singleton for that. Just create a single Factory. > I would very much like to get your feedback on this new design > pattern idea. Well, it's nothing new. Some may say that it is the point of design patterns: formalizes the designs that occur again and again. However, this design is simply a combination of the Singleton and Factory patterns. I did use it in the past, but now I've been exposed to the shortcomings of the Singleton pattern, so I limit myself to Factories. Regards, David From sean_montgomery at baseview.com Wed Mar 22 08:35:28 2006 From: sean_montgomery at baseview.com (Sean Montgomery) Date: Wed, 22 Mar 2006 10:35:28 -0500 Subject: [Rxtx] sole of a new design pattern In-Reply-To: <442160DA.80107@trusted-logic.com> References: <442160DA.80107@trusted-logic.com> Message-ID: <05769CA7-A51B-4CF0-BAA0-E02DD905F5A4@baseview.com> On Mar 22, 2006, at 9:36 AM, David Garnier wrote: > Furthermore, even for hardware services, the Singleton pattern does > not really prevent concurrent > accesses. If you start the same program in two different JVMs, > unless they somehow shared the state > of their "Singletons" (through lock files for example), the > Singleton pattern will not prevent > concurrent access. > Multiple class loaders in a single JVM can be tricky, too. Then there's synchronization, lazy initialization and serialization of singletons to contend with. Bloch's Effective Java covers these, and here's a few articles: http://www.javaworld.com/javaworld/jw-04-2003/jw-0425-designpatterns- p3.html http://java.sun.com/developer/technicalArticles/Programming/singletons/ Just FYI :-) From lyon at docjava.com Wed Mar 22 08:50:48 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Wed, 22 Mar 2006 10:50:48 -0500 Subject: [Rxtx] sole of a new design pattern In-Reply-To: <442160DA.80107@trusted-logic.com> References: <442160DA.80107@trusted-logic.com> Message-ID: Hi All, First, I would like to thank David for his prompt and thoughtful remarks. I had no idea people that feel strongly about a design patterns! Wow! Feedback (particularly critical feedback) is greatly appreciated. Starting at the end, first: >I did use it in >the past, but now I've been exposed to the shortcomings of the >Singleton pattern, so I limit myself to Factories. David, if I understood your comments correctly, you suggested that Factories can be used in leu of the Singleton Design Pattern, or even the Parametric Singleton Design Pattern. As I see in [Gof]: Factory Method: Intent "Define an interface for creating an object, but let subclasses decide which class to instantiate. Factory Method lets a class defer instantiation to subclasses." The Singleton Design Pattern is a concrete class, which is rather different, right? Also, subclasses are not permitted with Singleton, as they are final. Naturally, I could use an abstract factory as a parent for a singleton. I could even design a facade that could be implemented with the singleton....but that is not the intention of the design. Unless you want a mock-up, as discussed, below: More below: >Hello, > >> The Parametric Singleton Design Pattern > >The Singleton is the most abused design pattern ever. Good use-cases >for this pattern are extremely >rare and mostly confined to problems related to hardware resources, >like serial ports. > > >> Applicability >> >> Use the Parametric Singleton Design Pattern when: >> 1. There must be exactly one instance of a class with the given >> parameters. >OK. As I said above, this case this actually very unusual. The >Singleton pattern is mostly used when : >> 2. The instances must be accessible to clients from a well-known >> access point. > >Using the singleton pattern in this case is just convenient for the >programmer. Problems arises >pretty quickly, especially if you attempt to unit-test your classes. > >1) If your singleton is stateful, or hold on to stateful objects, it >means that two different unit >tests are not actually independent. Instead of starting with a brand >new environment, the result of >a test may be affected by the result of a previous test. This >problem also arise when with your >class relies on a database. In both cases, the solution is to reset >your "unique" resource >(Singleton or database) at the beginning of the test, which is a >pain. Also, while most projects >connect to a single database, projects that allow the use of >Singletons usually contain several of >thems, and new ones may cropped up unnoticed. You quickly end up >with test cases that only pass in a >certain order, which is a royal pain. There are basic problems with communicating finite state machines that include reachability and deadlock analysis. These are addressed with petri net analysis and are beyond the scope of the design pattern. As you quite rightly pointed out; the parametric singleton pattern (or the singleton pattern, for that matter) enable multiple threads to gain access to the same instance. The only way that I can see to block others from gaining access to the reference is the synchronize keyword. This is putting a spin-lock (or MUTEX) on the reference. The question of how to unit-test a design pattern like the parametric singleton remains open. Perhaps this is a deficiency. > >2) You cannot mockup a singleton. Once everyone calls the >SomeSingleton class statically, you can't >replace your class by SomeSingletonMockup. Acutally, I am not sure that this is true. If the Singleton implements a Facade interface, it should be possible to make the replacement. Right? > >Furthermore, even for hardware services, the Singleton pattern does >not really prevent concurrent >accesses. If you start the same program in two different JVMs, >unless they somehow shared the state >of their "Singletons" (through lock files for example), the >Singleton pattern will not prevent >concurrent access. Good Point!! You have sharp eyes! The singleton design pattern should/could take responsibility for this. In fact, you may notice that my code does have an implementation (LocateRegistry) that can work across JVM's. The LocateRegistry will even work across the Internet! LocateRegistry takes both a host name and a Port (lock files just don't do this). I did not think to implement this beyond the local machine, but, in its present form, it will work across different processes. > >Our application uses RXTX, and we routinely encounter cases where >another (native) application has >already locked the port. Since we cannot modify the native >application to recognize lock files, >OS-level control is irreplaceable. The singleton design pattern is not meant to replace OS-level control, but to centralize the Java programmers access to it. If lock files, for example, are used for serial ports, the Singleton Design Pattern should be able to work with them. > > >> >> Consequences >> The Parametric Singleton Design Pattern has several benefits: >> > > 1. Controlled access to parametrically defined instances. Since >> the Parametric Singleton class encapsulates its instances, there is >> control over how and when clients access it. > >Not really. Once you've returned the instance to a client, you've >lost control over it. The client >can to whatever it wants with it. You cannot "recall" the instance >or claim it back. Good point, this should read: > 1. Controll when parametrically defined instances are created. Since > > the Parametric Singleton class encapsulates its instances, there is > > control over how and when they are instanced. > >> 2. Reduced name space. The Parametric Singleton pattern avoids >> global variables that store instances created from the same parameter. > >Sure, but you don't have to rely on a Singleton for that. Just >create a single Factory. > > Thank you for your thoughtful and prompt response! Regards, - Doug From dmarkman at mac.com Wed Mar 22 21:21:55 2006 From: dmarkman at mac.com (Dmitry Markman) Date: Wed, 22 Mar 2006 23:21:55 -0500 Subject: [Rxtx] sole of a new design pattern In-Reply-To: <442160DA.80107@trusted-logic.com> References: <442160DA.80107@trusted-logic.com> Message-ID: I don't think I get it On Mar 22, 2006, at 9:36 AM, David Garnier wrote: > Using the singleton pattern in this case is just convenient for the > programmer. Problems arises > pretty quickly, especially if you attempt to unit-test your classes. so you're saying that something isn't so good because you can not test it in the convenient way? if that's true, I'm totally disagree change your test, debug whatever, but if software is efficient at runtime, works fine and only problem is some unit test (which is some kind of framework for testing) then dump that unit test , dump that unit framework and make something appropriate to the software you're testing so if Douglas want to use singletons, what's the problem? and what do you mean by abusing of singleton usage? of course singleton doesn't prevent concurrent access to the resource across the processes unless you're using some OS facility to prevent it, besides singleton as it was introduced is relevant only and only inside of the same process otherwise it's not singleton it's something else (let's say network singleton: so you have remote invocation facility and some factory method that return object created by that facility) I don't have any problem with using any kind of singletons. Parametric Singleton idea (if I understand it right) could be easily implemented in the following way: use a map populate map with instances of some class and key is your parameter (you can use lazy population too) if somebody ask the key check the value if it's null so resource is taken if somebody returns the resource put it back to the map public synchronized static Object getSomeResource(Object parameter); public synchronized static void returnResource(Object parameter); getSomeResource (inside of the same process) could return null in 2 cases 1. if somebody (from other thread for example) already took that resource 2. if OS API said that resource corresponded to that parameter (serial port with parameter = 1 (port #)) is locked and unavailable; I'm not sure that in case of serial ports we even need those Parametric Singletons (unless lock checking is a very expensive operation) just ask the OS about availability of that resource and if it's available give it away and then OS will lock it and therefore in next time somebody ask it just answer that resource is locked and return null for example system has 2 serial ports available so I ask getResource("tty"); or I ask getResource("Bluetooth-Modem"); and if OS is ok you can give tty or Bluetooth-Modem or both no need for any additional pattern I think back to the problem mac os x doesn't recognize locking via files, so it handles locking via some API an instance of the singleton in each process should recognize that resource is locked (by using that API) that's all we don't have to make things more complicate then they are just because there is some nice design pattern or nice unit test framework or whatever keep things simple, make them work fast, don't introduce middle layers unless you have really good reason to do so of course I could be entirely wrong, so sorry about that in advance thanks Dmitry Markman From tjarvi at qbang.org Wed Mar 22 22:31:41 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 22 Mar 2006 22:31:41 -0700 (MST) Subject: [Rxtx] sole of a new design pattern In-Reply-To: References: Message-ID: Hi Doug Interesting reading. So far I'm just reading and thinking. I have one question so far. " Clients obtain a reference to a Parametric Singleton instance only through the parametric singleton design pattern. If the instance is left in an improper state (e.g., the serial port was left open) it is NOT the role of the Parametric Singleton Design Pattern to close the IO port. Nor is it the role of the Parametric Singleton Design Pattern to open the port. That role is delegate to some other part of the system. " So when the clients obtain a reference to the singleton, can they assume the port is there? IE, would it be the singletons role to handle things like USB dongles being removed with event hints comming from the underlying OS. Hardware abstraction layer/HAL on Linux is an example of underlying OS events. I assume that role too is delegated to other parts of the system? -- Trent Jarvi tjarvi at qbang.org From lyon at docjava.com Thu Mar 23 08:10:33 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Thu, 23 Mar 2006 10:10:33 -0500 Subject: [Rxtx] Classes don't need goals, they need roles! In-Reply-To: References: Message-ID: Hi Trent, Yes, I think that the role of the Parametric Singleton Pattern is not to open or close serial ports, nor is it to perform error checking. On the other hand, if you were to combine the role of the Parametric Singleton Pattern with another role (like that of error checking) it might not be amiss. However, I generally caution programmers against adding multiple roles to classes, as this leads to monolithic designs. Thus a different class (NativeLibDetect) could have the role of determining if the native library can be loaded. Another class (SerialPortBean) can have the role of serializing the default state of the serial port, so that it can be recovered, from user preferences, at a later time. The SerialPortDetect could have the role of determining if the serial port is removed (i.e., a USB port was unplugged). My guess is that each class should have a different role in the system, in order to ease maintenance and testing...but I could be wrong about that. Thanks! - Doug >Hi Doug > >Interesting reading. So far I'm just reading and thinking. I have >one question so far. > >" > Clients obtain a reference to a Parametric Singleton instance only >through the parametric singleton design pattern. If the instance is >left in an improper state (e.g., the serial port was left open) it is >NOT the role of the Parametric Singleton Design Pattern to close the >IO port. Nor is it the role of the Parametric Singleton Design Pattern >to >open the port. That role is delegate to some other part of the system. >" > >So when the clients obtain a reference to the singleton, can they >assume the port is there? IE, would it be the singletons role to >handle things like USB dongles being removed with event hints >comming from the underlying OS. Hardware abstraction layer/HAL on >Linux is an example of underlying OS events. > >I assume that role too is delegated to other parts of the system? > >-- >Trent Jarvi >tjarvi at qbang.org >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From maximulo at yahoo.com Fri Mar 24 01:22:38 2006 From: maximulo at yahoo.com (Maximulo Majir) Date: Fri, 24 Mar 2006 00:22:38 -0800 (PST) Subject: [Rxtx] JavaPOS Message-ID: <20060324082238.66371.qmail@web38214.mail.mud.yahoo.com> Hi all! Hello Trent! From what i understand, RXTX or JavaComm APIs were not created solely for JavaPOS. In JavaPOS, we have the virtual method claim() which is separate from open(), but in our RXTX API, claiming is done every call to open(), we cant open the port if its claimed by another application. Would it be alright to suggest or ask to create a new method called claim(..)? Is there such thing as forceclaim() in RXTX? this could be the same as portownership transfer or its equivalent. ForceClaim is in JSR80. Do you have some samples using RXTX as the lower layer for the Device Service Objects in JavaPOS? I have tried it, i just want to compare. Thank you all! maxim __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060324/496adba2/attachment-0031.html From tjarvi at qbang.org Fri Mar 24 11:28:19 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 24 Mar 2006 11:28:19 -0700 (MST) Subject: [Rxtx] Re: RXTX 2.1 Solaris Problems In-Reply-To: <3691.1143210578@www045.gmx.net> References: <3691.1143210578@www045.gmx.net> Message-ID: On Fri, 24 Mar 2006, Andreas Guenther wrote: > Hi all, > > the solaris problem was not the lock file only. > > Ok, I had to create the directory /var/spool/locks myself. > /var/spool/uucp exists. > > But rxtx didn't find any port. > > I compiled the source with my own debug-informations > and I tried to isolate the problem. > > The problem is the testRead-call in SerialImp.c > > JNIEXPORT jboolean JNICALL RXTXCommDriver(testRead)( > > ... > if ( READ( fd, &c, 1 ) < 0 ) > { > if ( errno != EAGAIN ) { > report( "testRead() read failed\n" ); > ret = JNI_FALSE; > } > } > Thanks Andreas I'm packing up to move. I'll be more or less away for a couple weeks here. I'll be checking email but my workstation is going into a box soon. This isn't hard to fix as this port should be enumerated when EWOULDBLOCK is recieved. Thats error is OK for enumeration just as EAGAIN is. I've put the bug into bugzilla so we dont forget to get to it. http://bugzilla.qbang.org/show_bug.cgi?id=42 You can add yourself to the CC list if you wish to test fixes we provide or even put a patch into bugzilla yourself. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Fri Mar 24 11:51:52 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 24 Mar 2006 11:51:52 -0700 (MST) Subject: [Rxtx] JavaPOS In-Reply-To: <20060324082238.66371.qmail@web38214.mail.mud.yahoo.com> References: <20060324082238.66371.qmail@web38214.mail.mud.yahoo.com> Message-ID: On Fri, 24 Mar 2006, Maximulo Majir wrote: > Hi all! Hello Trent! > > > From what i understand, RXTX or JavaComm APIs were not > created solely for JavaPOS. In JavaPOS, we have the virtual method > claim() which is separate from open(), but in our RXTX API, claiming is > done every call to open(), we cant open the port if its claimed by > another application. Would it be alright to suggest or ask to create a > new method called claim(..)? Is there such thing as forceclaim() in > RXTX? this could be the same as portownership transfer or its > equivalent. ForceClaim is in JSR80. > Do you have some samples using RXTX as the lower layer for the Device > Service Objects in JavaPOS? I have tried it, i just want to compare. > maxim Hi Maxim JSR80 is the USB API IBM/Sun put together. The problem is they have a richer kernel/API underneath that can handle such things. With Serial Ports, there isnt anything there other than an ioctl that says don't let anyone touch this and lockfiles that are more of a 'lets be nice.' At times we may be using USB ports but it is through the termios layer with the limitations mentioned. The advantage is that not only USB will work with rxtx. Anything that has a termios layer should work (to the extent that termios layer is complete). I don't know how forceclaim() would help you. Lets say someone has a programmer working on /dev/ttyS0 and you take it. Now you both race each other to read data first. There isn't a mechanism I know of that will solve this problem in termios. The most obvious test being a native app and a Java app trying to take the port. There is the potential of requestion ownership from other Java Applications but the use for that is very rare. Did you have something more specific in mind that I'm missing? I'm not sure that claim() and forceclaim() would help you with rxtx other than maybe locking the port with claim() without opening it. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sat Mar 25 23:42:08 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 25 Mar 2006 23:42:08 -0700 (MST) Subject: [Rxtx] Serial snoop Message-ID: I was reading the Linux kernel mail-list tonight and ran past a thread that mentioned sersnoop. This looks like a handy tool for people dealing with new toys. "a simple command-line tool for linux that echoes bytes to and from any two serial ports, ptys, or network sockets, and prints all traffic to stdout, in hex and ascii." http://www.restivo.org/projects/sersnoop/ It works on Linux only at this time (debian package available). -- Trent Jarvi tjarvi at qbang.org From beat.arnet at gmail.com Sun Mar 26 07:32:35 2006 From: beat.arnet at gmail.com (Beat Arnet) Date: Sun, 26 Mar 2006 09:32:35 -0500 Subject: [Rxtx] Error 0x5 at /home/bob/foo/tar/rxtx-2.1-7/build/../src/termios.c(860): Access is, denied. Message-ID: <4426A603.80508@gmail.com> Dear all, When trying to open the serial port, I sometimes (not always) run into the following exception (when opening the serialPort): Error 0x5 at /home/bob/foo/tar/rxtx-2.1-7/build/../src/termios.c(860): Access is denied. java.lang.UnsatisfiedLinkError: native_psmisc_report_owner at gnu.io.CommPortIdentifier.native_psmisc_report_owner(Native Method) at gnu.io.CommPortIdentifier.open(CommPortIdentifier.java:354) at codeskin.tools.CLLoader.open(CLLoader.java:79) at codeskin.tools.C2000Programmer.run(C2000Programmer.java:220) at java.lang.Thread.run(Unknown Source) Is this the type of error where I should just try to open the port again, or can it be avoided? Regards, Beat From tjarvi at qbang.org Sun Mar 26 11:40:12 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 26 Mar 2006 11:40:12 -0700 (MST) Subject: [Rxtx] Error 0x5 at /home/bob/foo/tar/rxtx-2.1-7/build/../src/termios.c(860): Access is, denied. In-Reply-To: <4426A603.80508@gmail.com> References: <4426A603.80508@gmail.com> Message-ID: On Sun, 26 Mar 2006, Beat Arnet wrote: > Dear all, > > When trying to open the serial port, I sometimes (not always) run into > the following exception (when opening the serialPort): > > Error 0x5 at /home/bob/foo/tar/rxtx-2.1-7/build/../src/termios.c(860): > Access is > denied. > > java.lang.UnsatisfiedLinkError: native_psmisc_report_owner > at gnu.io.CommPortIdentifier.native_psmisc_report_owner(Native > Method) > at gnu.io.CommPortIdentifier.open(CommPortIdentifier.java:354) > at codeskin.tools.CLLoader.open(CLLoader.java:79) > at codeskin.tools.C2000Programmer.run(C2000Programmer.java:220) > at java.lang.Thread.run(Unknown Source) > > Is this the type of error where I should just try to open the port again, > or can it be avoided? > Hi Beat We did a second build of rxtx 2.1-7 to resolve that unsatisfied link error. It should work now. rxtx is trying to tell you it thinks someone else has the serial port open. You can try to open the port again but maybe you already have a copy of the program running when it happens? ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7r2.zip fixed build. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sun Mar 26 11:44:23 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 26 Mar 2006 11:44:23 -0700 (MST) Subject: [Rxtx] RXTX spec file (fwd) Message-ID: This is probably interesting for fedora/suse users. ---------- Forwarded message ---------- Date: Sun, 26 Mar 2006 16:25:45 +0200 To: taj at www.linux.org.uk Subject: RXTX spec file I send you this spec file which allows to create a RPM for Fedora 4, 5 (x86, x86_64) with Java Sun. -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: rxtx.spec Url: http://mailman.qbang.org/pipermail/rxtx/attachments/20060326/6c7b6af6/rxtx-0027.pl From tjarvi at qbang.org Sun Mar 26 23:42:59 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 26 Mar 2006 23:42:59 -0700 (MST) Subject: [Rxtx] Upcomming events. Message-ID: This Wednesday we will be announcing a new "Maintainer" for the rxtx project. The position is more like neutral leader. I wont be going away or doing less. This is just the right thing to do as it turns out the two people with CVS write access will be at the same company. We need a third and we need neutrality. The maintainer will have final say in any conflict and will try to be neutral. It will be open for discussion. Then we will do it :) I'll still do most of the footwork I do now. But. I'm falling behind. I should have gone through the mail-list and posted the next round of changes this weekend. I'm packing to move and its going so so - 13 years of toys collected. I suspect there will be a dead period on my part (a couple weeks) comming up. But if you get it on the mail-list, we will get it in if there are no objections. I may well not be reading the mail-list during this period as I look for a house and many other things. I hope everyone will help out. Thanks -- Trent Jarvi tjarvi at qbang.org From mahmoud_hadad at yahoo.com Sun Mar 26 07:31:19 2006 From: mahmoud_hadad at yahoo.com (ronan nick) Date: Sun, 26 Mar 2006 06:31:19 -0800 (PST) Subject: [Rxtx] a question about the COMM API Message-ID: <20060326143119.54919.qmail@web60014.mail.yahoo.com> hi, i was intrested in knowing how i can communicate with my internal modem using java? for example if i want to make a phone dialer application or a caller id application where should i be looking at? and as i understood the COMM API is for devices that is attached to the computer through serial ports. --------------------------------- New Yahoo! Messenger with Voice. Call regular phones from your PC and save big. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060326/ce8329f0/attachment-0029.html From dmarkman at mac.com Mon Mar 20 00:20:43 2006 From: dmarkman at mac.com (Dmitry Markman) Date: Mon, 20 Mar 2006 02:20:43 -0500 Subject: [Rxtx] Mac OS X RXTX java installer In-Reply-To: References: <07D0DE29-BA32-4CFE-B036-66BC6423D385@buechse.de> <441AE3E0.2030503@willicon.de> <12531986.1142622114996.JavaMail.dmarkman@mac.com> <441B2674.9010409@willicon.de> <13577405.1142634732776.JavaMail.dmarkman@mac.com> <441B4182.8010407@willicon.de> <92CD0D6C-5BE8-426E-A46D-99452059FF49@mac.com> <441BBB2D.8030305@willicon.de> <441C4088.5090905@willicon.de> Message-ID: <64BC1E23-FDDE-4CE6-8863-CFC881CBC224@mac.com> Hi all I put RXTX installer that will install everything (and will create / var/lock if necessary and add user to the uucp group) for mac os x from Java into the rxtx's CVS repository it could be easily modified to install files for any platform it uses Greg Guerin's AuthKit for authentication and authorization Greg released that kit under artistic license, so Trent, please take a look we, probably, can negotiate license with Greg if it's necessary Greg's AuthKit could be downloaded from http://www.amug.org/~glguerin/ sw/#authkit Michael Hall (mikehall at spacestar dot net) had a suggestion to make implementation of the jaas LoginModule based on Greg's AuthKit (his modification of the Greg's AuthKit could be found at http:// www.spacestar.net/users/mikehall/authkit.dmg) but Michael's AuthKitLoginModule does only half a job: it does authenticate but it can not run any external unix process in privileged mode (at least I wasn't able to do so) possible explanation could be found in conversation between Greg and Michael at Apple's java-dev list (look for archives) so I didn't use jaas API for rxtxinstaller I created folder MacOSX in the contrib folder comment 1. if you want to run that installer as standalone application all you need that RXTXInstaller.jar 2. if you want to use webstart you have to add Greg's libAuthKit.jnilib to the mac os x's resources in theory RXTXInstaller.jar doesn't need it, but there is a problem with loading libAuthKit.jnilib from webstart authkit uses loadLibrary method to load library and it failed (from webstart) for standalone application I extract libAuthKit.jnilib from the RXTXInstaller.jar and put it into the /Library/Java/Extensions or ~/Library/Java/Extensions folder that file will be deleted after installer quit unfortunately I didn't have time to put documentation there but it is mostly self-explanatory I took installer code from my gl4java installer that I did about 3 years ago (with small modifications) it would be very nice if Apple will release LoginModule that really will do the job (com.apple.security.auth.module package????? ) (UnixLoginModule is pretty useless) From lyon at docjava.com Mon Mar 20 06:34:39 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Mon, 20 Mar 2006 08:34:39 -0500 Subject: [Rxtx] Mac OS X RXTX java installer In-Reply-To: <64BC1E23-FDDE-4CE6-8863-CFC881CBC224@mac.com> References: <07D0DE29-BA32-4CFE-B036-66BC6423D385@buechse.de> <441AE3E0.2030503@willicon.de> <12531986.1142622114996.JavaMail.dmarkman@mac.com> <441B2674.9010409@willicon.de> <13577405.1142634732776.JavaMail.dmarkman@mac.com> <441B4182.8010407@willicon.de> <92CD0D6C-5BE8-426E-A46D-99452059FF49@mac.com> <441BBB2D.8030305@willicon.de> <441C4088.5090905@willicon.de> <64BC1E23-FDDE-4CE6-8863-CFC881CBC224@mac.com> Message-ID: Hi Dimitry, This sounds like great work. Just a couple of questions; After the check out of the CVS files, using: setenv CVSROOT :pserver:anonymous at cvs.milestonesolutions.com:/usr/local/cvsroot 53 8:28 setenv PASSWORD mousy 54 8:29 cvs login 55 8:29 cvs checkout rxtx-devel I cd'd over to: rxtx-devel/MACOSX_IDE And found: CVS/ CW/ ForPackageMaker/ PB/ Where is the installer? Thanks! - Doug From tjarvi at qbang.org Mon Mar 20 06:39:37 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 20 Mar 2006 06:39:37 -0700 (MST) Subject: [Rxtx] Mac OS X RXTX java installer In-Reply-To: References: <07D0DE29-BA32-4CFE-B036-66BC6423D385@buechse.de> <441AE3E0.2030503@willicon.de> <12531986.1142622114996.JavaMail.dmarkman@mac.com> <441B2674.9010409@willicon.de> <13577405.1142634732776.JavaMail.dmarkman@mac.com> <441B4182.8010407@willicon.de> <92CD0D6C-5BE8-426E-A46D-99452059FF49@mac.com> <441BBB2D.8030305@willicon.de> <441C4088.5090905@willicon.de> <64BC1E23-FDDE-4CE6-8863-CFC881CBC224@mac.com> Message-ID: On Mon, 20 Mar 2006, Dr. Douglas Lyon wrote: > Hi Dimitry, > This sounds like great work. Just a couple of questions; > After the check out of the CVS files, using: > setenv CVSROOT > :pserver:anonymous at cvs.milestonesolutions.com:/usr/local/cvsroot > 53 8:28 setenv PASSWORD mousy > 54 8:29 cvs login > 55 8:29 cvs checkout rxtx-devel Hi Doug You want "cvs checkout -r commapi-0-0-1 rxtx-devel" to get RXTX 2.1 The default branch is rxtx 2.0 which isn't very active right now. -- Trent Jarvi tjarvi at qbang.org From lyon at docjava.com Mon Mar 20 07:05:44 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Mon, 20 Mar 2006 09:05:44 -0500 Subject: [Rxtx] Mac OS X RXTX java installer In-Reply-To: References: <07D0DE29-BA32-4CFE-B036-66BC6423D385@buechse.de> <441AE3E0.2030503@willicon.de> <12531986.1142622114996.JavaMail.dmarkman@mac.com> <441B2674.9010409@willicon.de> <13577405.1142634732776.JavaMail.dmarkman@mac.com> <441B4182.8010407@willicon.de> <92CD0D6C-5BE8-426E-A46D-99452059FF49@mac.com> <441BBB2D.8030305@willicon.de> <441C4088.5090905@willicon.de> <64BC1E23-FDDE-4CE6-8863-CFC881CBC224@mac.com> Message-ID: Hi Trent, Thanks for the info on the CVS checkout procedure. I did that and am still not sure where the installer is. Here is what I have: cd MACOSX_IDE/ p4.docjava.com{lyon}121: ls CVS/ ForPackageMaker/ PB/ p4.docjava.com{lyon}122: find . | more . ./ForPackageMaker ./ForPackageMaker/RXTX.pkg.sit.hqx ./ForPackageMaker/Resources ./ForPackageMaker/Resources/ReadMe.rtf ./ForPackageMaker/Resources/Welcome.rtf ./ForPackageMaker/Resources/CVS ./ForPackageMaker/Resources/CVS/Entries ./ForPackageMaker/Resources/CVS/Repository ./ForPackageMaker/Resources/CVS/Tag ./ForPackageMaker/Resources/CVS/Root ./ForPackageMaker/Resources/preinstall ./ForPackageMaker/Resources/License.rtf ./ForPackageMaker/Resources/preupgrade ./ForPackageMaker/RXTX.pmsp ./ForPackageMaker/CVS ./ForPackageMaker/CVS/Entries ./ForPackageMaker/CVS/Repository ./ForPackageMaker/CVS/Entries.Log ./ForPackageMaker/CVS/Tag ./ForPackageMaker/CVS/Root ./ForPackageMaker/RXTX_Tiger.pkg.sitx.hqx ./ForPackageMaker/RXTX_Jag.pkg.sit.hqx ./ForPackageMaker/Install ./ForPackageMaker/Install/CVS ./ForPackageMaker/Install/CVS/Entries ./ForPackageMaker/Install/CVS/Repository ./ForPackageMaker/Install/CVS/Tag ./ForPackageMaker/Install/CVS/Root ./ForPackageMaker/Install/Library ./ForPackageMaker/Install/Library/CVS ./ForPackageMaker/Install/Library/CVS/Entries ./ForPackageMaker/Install/Library/CVS/Repository ./ForPackageMaker/Install/Library/CVS/Tag ./ForPackageMaker/Install/Library/CVS/Root ./ForPackageMaker/Install/Library/Java ./ForPackageMaker/Install/Library/Java/Extensions ./ForPackageMaker/Install/Library/Java/Extensions/RXTXcomm.jar ./ForPackageMaker/Install/Library/Java/Extensions/CVS ./ForPackageMaker/Install/Library/Java/Extensions/CVS/Entries ./ForPackageMaker/Install/Library/Java/Extensions/CVS/Repository ./ForPackageMaker/Install/Library/Java/Extensions/CVS/Tag ./ForPackageMaker/Install/Library/Java/Extensions/CVS/Root ./ForPackageMaker/Install/Library/Java/Extensions/librxtxSerial.jnilib ./ForPackageMaker/Install/Library/Java/CVS ./ForPackageMaker/Install/Library/Java/CVS/Entries ./ForPackageMaker/Install/Library/Java/CVS/Repository ./ForPackageMaker/Install/Library/Java/CVS/Entries.Log ./ForPackageMaker/Install/Library/Java/CVS/Tag ./ForPackageMaker/Install/Library/Java/CVS/Root ./ForPackageMaker/RXTX_Tiger.pmproj.sitx.hqx ./CVS ./CVS/Entries ./CVS/Repository ./CVS/Entries.Log ./CVS/Tag ./CVS/Root ./PB ./PB/LibSerialUniversal.xcodeproj.sitx.hqx ./PB/CVS ./PB/CVS/Entries ./PB/CVS/Repository ./PB/CVS/Entries.Log ./PB/CVS/Tag ./PB/CVS/Root ./PB/LibSerial.pbproj.sit.hqx ./PB/startpoint.c ./PB/config.h What is the procedure to run this installer? Do we need a README in: /rxtx-devel/MACOSX_IDE Here is what we have: CVS/ ForPackageMaker/ PB/ Thanks! - DL >On Mon, 20 Mar 2006, Dr. Douglas Lyon wrote: > >>Hi Dimitry, >>This sounds like great work. Just a couple of questions; >>After the check out of the CVS files, using: >>setenv CVSROOT >>:pserver:anonymous at cvs.milestonesolutions.com:/usr/local/cvsroot >> 53 8:28 setenv PASSWORD mousy >> 54 8:29 cvs login >> 55 8:29 cvs checkout rxtx-devel > >Hi Doug > >You want "cvs checkout -r commapi-0-0-1 rxtx-devel" to get RXTX 2.1 >The default branch is rxtx 2.0 which isn't very active right now. > >-- >Trent Jarvi >tjarvi at qbang.org From tjarvi at qbang.org Mon Mar 20 07:25:30 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 20 Mar 2006 07:25:30 -0700 (MST) Subject: [Rxtx] Mac OS X RXTX java installer In-Reply-To: References: <07D0DE29-BA32-4CFE-B036-66BC6423D385@buechse.de> <441AE3E0.2030503@willicon.de> <12531986.1142622114996.JavaMail.dmarkman@mac.com> <441B2674.9010409@willicon.de> <13577405.1142634732776.JavaMail.dmarkman@mac.com> <441B4182.8010407@willicon.de> <92CD0D6C-5BE8-426E-A46D-99452059FF49@mac.com> <441BBB2D.8030305@willicon.de> <441C4088.5090905@willicon.de> <64BC1E23-FDDE-4CE6-8863-CFC881CBC224@mac.com> Message-ID: On Mon, 20 Mar 2006, Dr. Douglas Lyon wrote: > Hi Trent, > Thanks for the info on the CVS checkout procedure. > I did that and am still not sure where the installer is. Hi Doug It does look like it was not cvs committed. There is no rxtx-devel/contrib/MacOSX directory in there at the moment. It was mentioned that it was put under contrib. -- Trent Jarvi tjarvi at qbang.org From dmarkman at mac.com Mon Mar 20 07:29:56 2006 From: dmarkman at mac.com (Dmitry Markman) Date: Mon, 20 Mar 2006 09:29:56 -0500 Subject: [Rxtx] Mac OS X RXTX java installer In-Reply-To: References: <07D0DE29-BA32-4CFE-B036-66BC6423D385@buechse.de> <441AE3E0.2030503@willicon.de> <12531986.1142622114996.JavaMail.dmarkman@mac.com> <441B2674.9010409@willicon.de> <13577405.1142634732776.JavaMail.dmarkman@mac.com> <441B4182.8010407@willicon.de> <92CD0D6C-5BE8-426E-A46D-99452059FF49@mac.com> <441BBB2D.8030305@willicon.de> <441C4088.5090905@willicon.de> <64BC1E23-FDDE-4CE6-8863-CFC881CBC224@mac.com> Message-ID: <6054EB4E-F7E0-4A9C-BDDA-D582D6D8826F@mac.com> you can find it in the rxtx-devel/contrib folder On Mar 20, 2006, at 9:05 AM, Dr. Douglas Lyon wrote: > Hi Trent, > Thanks for the info on the CVS checkout procedure. > I did that and am still not sure where the installer is. > Here is what I have: > cd MACOSX_IDE/ > p4.docjava.com{lyon}121: ls > CVS/ ForPackageMaker/ PB/ > p4.docjava.com{lyon}122: find . | more > . > ./ForPackageMaker > ./ForPackageMaker/RXTX.pkg.sit.hqx > ./ForPackageMaker/Resources > ./ForPackageMaker/Resources/ReadMe.rtf > ./ForPackageMaker/Resources/Welcome.rtf > ./ForPackageMaker/Resources/CVS > ./ForPackageMaker/Resources/CVS/Entries > ./ForPackageMaker/Resources/CVS/Repository > ./ForPackageMaker/Resources/CVS/Tag > ./ForPackageMaker/Resources/CVS/Root > ./ForPackageMaker/Resources/preinstall > ./ForPackageMaker/Resources/License.rtf > ./ForPackageMaker/Resources/preupgrade > ./ForPackageMaker/RXTX.pmsp > ./ForPackageMaker/CVS > ./ForPackageMaker/CVS/Entries > ./ForPackageMaker/CVS/Repository > ./ForPackageMaker/CVS/Entries.Log > ./ForPackageMaker/CVS/Tag > ./ForPackageMaker/CVS/Root > ./ForPackageMaker/RXTX_Tiger.pkg.sitx.hqx > ./ForPackageMaker/RXTX_Jag.pkg.sit.hqx > ./ForPackageMaker/Install > ./ForPackageMaker/Install/CVS > ./ForPackageMaker/Install/CVS/Entries > ./ForPackageMaker/Install/CVS/Repository > ./ForPackageMaker/Install/CVS/Tag > ./ForPackageMaker/Install/CVS/Root > ./ForPackageMaker/Install/Library > ./ForPackageMaker/Install/Library/CVS > ./ForPackageMaker/Install/Library/CVS/Entries > ./ForPackageMaker/Install/Library/CVS/Repository > ./ForPackageMaker/Install/Library/CVS/Tag > ./ForPackageMaker/Install/Library/CVS/Root > ./ForPackageMaker/Install/Library/Java > ./ForPackageMaker/Install/Library/Java/Extensions > ./ForPackageMaker/Install/Library/Java/Extensions/RXTXcomm.jar > ./ForPackageMaker/Install/Library/Java/Extensions/CVS > ./ForPackageMaker/Install/Library/Java/Extensions/CVS/Entries > ./ForPackageMaker/Install/Library/Java/Extensions/CVS/Repository > ./ForPackageMaker/Install/Library/Java/Extensions/CVS/Tag > ./ForPackageMaker/Install/Library/Java/Extensions/CVS/Root > ./ForPackageMaker/Install/Library/Java/Extensions/librxtxSerial.jnilib > ./ForPackageMaker/Install/Library/Java/CVS > ./ForPackageMaker/Install/Library/Java/CVS/Entries > ./ForPackageMaker/Install/Library/Java/CVS/Repository > ./ForPackageMaker/Install/Library/Java/CVS/Entries.Log > ./ForPackageMaker/Install/Library/Java/CVS/Tag > ./ForPackageMaker/Install/Library/Java/CVS/Root > ./ForPackageMaker/RXTX_Tiger.pmproj.sitx.hqx > ./CVS > ./CVS/Entries > ./CVS/Repository > ./CVS/Entries.Log > ./CVS/Tag > ./CVS/Root > ./PB > ./PB/LibSerialUniversal.xcodeproj.sitx.hqx > ./PB/CVS > ./PB/CVS/Entries > ./PB/CVS/Repository > ./PB/CVS/Entries.Log > ./PB/CVS/Tag > ./PB/CVS/Root > ./PB/LibSerial.pbproj.sit.hqx > ./PB/startpoint.c > ./PB/config.h > > What is the procedure to run this installer? > Do we need a README in: > /rxtx-devel/MACOSX_IDE > Here is what we have: > CVS/ ForPackageMaker/ PB/ > > > Thanks! > - DL > >> On Mon, 20 Mar 2006, Dr. Douglas Lyon wrote: >> >>> Hi Dimitry, >>> This sounds like great work. Just a couple of questions; >>> After the check out of the CVS files, using: >>> setenv CVSROOT :pserver:anonymous at cvs.milestonesolutions.com:/usr/ >>> local/cvsroot >>> 53 8:28 setenv PASSWORD mousy >>> 54 8:29 cvs login >>> 55 8:29 cvs checkout rxtx-devel >> >> Hi Doug >> >> You want "cvs checkout -r commapi-0-0-1 rxtx-devel" to get RXTX 2.1 >> The default branch is rxtx 2.0 which isn't very active right now. >> >> -- >> Trent Jarvi >> tjarvi at qbang.org > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx Dmitry Markman From mikehall at spacestar.net Mon Mar 20 05:25:25 2006 From: mikehall at spacestar.net (Michael Hall) Date: Mon, 20 Mar 2006 06:25:25 -0600 Subject: [Rxtx] Re: Mac OS X RXTX java installer In-Reply-To: <64BC1E23-FDDE-4CE6-8863-CFC881CBC224@mac.com> References: <07D0DE29-BA32-4CFE-B036-66BC6423D385@buechse.de> <441AE3E0.2030503@willicon.de> <12531986.1142622114996.JavaMail.dmarkman@mac.com> <441B2674.9010409@willicon.de> <13577405.1142634732776.JavaMail.dmarkman@mac.com> <441B4182.8010407@willicon.de> <92CD0D6C-5BE8-426E-A46D-99452059FF49@mac.com> <441BBB2D.8030305@willicon.de> <441C4088.5090905@willicon.de> <64BC1E23-FDDE-4CE6-8863-CFC881CBC224@mac.com> Message-ID: <247EB61F-5CD1-4132-89A2-FC105B6CF9A5@spacestar.net> On Mar 20, 2006, at 1:20 AM, Dmitry Markman wrote: > > Michael Hall (mikehall at spacestar dot net) had a suggestion to > make implementation of the jaas LoginModule > based on Greg's AuthKit > (his modification of the Greg's AuthKit could be found at http:// > www.spacestar.net/users/mikehall/authkit.dmg) > but Michael's AuthKitLoginModule does only half a job: > it does authenticate > but it can not run any external unix process in privileged mode (at > least I wasn't able to do so) If you got it working directly with Greg's the point is moot. But to clarify it anyhow. The login module does not allow you to do anything anything privileged on return as was explained by Greg. You need to work with a separate privileged process using the execPrivileged method of his API. I assume you did something similar although I haven't looked at how you are using it yet. I allowed instead for a action to be performed at the same time you login/authenticate,this... System.setProperty("authkit.action","/usr/bin/id"); just before this... lc.login(); To clarify, safely ignored as you are already complete. Mike Hall mikehall at spacestar dot net http://www.spacestar.net/users/mikehall http://sourceforge.net/projects/macnative -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2427 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20060320/f6e18202/smime-0032.bin From dmarkman at mac.com Mon Mar 20 07:36:47 2006 From: dmarkman at mac.com (Dmitry Markman) Date: Mon, 20 Mar 2006 09:36:47 -0500 Subject: [Rxtx] Re: Mac OS X RXTX java installer In-Reply-To: <247EB61F-5CD1-4132-89A2-FC105B6CF9A5@spacestar.net> References: <07D0DE29-BA32-4CFE-B036-66BC6423D385@buechse.de> <441AE3E0.2030503@willicon.de> <12531986.1142622114996.JavaMail.dmarkman@mac.com> <441B2674.9010409@willicon.de> <13577405.1142634732776.JavaMail.dmarkman@mac.com> <441B4182.8010407@willicon.de> <92CD0D6C-5BE8-426E-A46D-99452059FF49@mac.com> <441BBB2D.8030305@willicon.de> <441C4088.5090905@willicon.de> <64BC1E23-FDDE-4CE6-8863-CFC881CBC224@mac.com> <247EB61F-5CD1-4132-89A2-FC105B6CF9A5@spacestar.net> Message-ID: Hi, Michael all I have to do is to run some shell script I tried to use your action mechanism and it worked great so I just System.setProperty ("authkit.action","" ) and after that I even don't need to run anything like subject.doAs.... but after few thoughts I choose to use plain Greg's approach, because in that case I don't have to deal with various java's configurations files and therefore to use 2-3 -D parameters in the java command line especially it's useful for java web start (it's so fragile :-( ) thanks for the great job On Mar 20, 2006, at 7:25 AM, Michael Hall wrote: > > On Mar 20, 2006, at 1:20 AM, Dmitry Markman wrote: >> >> Michael Hall (mikehall at spacestar dot net) had a suggestion to >> make implementation of the jaas LoginModule >> based on Greg's AuthKit >> (his modification of the Greg's AuthKit could be found at http:// >> www.spacestar.net/users/mikehall/authkit.dmg) >> but Michael's AuthKitLoginModule does only half a job: >> it does authenticate >> but it can not run any external unix process in privileged mode >> (at least I wasn't able to do so) > > If you got it working directly with Greg's the point is moot. > > But to clarify it anyhow. > The login module does not allow you to do anything anything > privileged on return as was explained by Greg. You need to work > with a separate privileged process using the execPrivileged method > of his API. I assume you did something similar although I haven't > looked at how you are using it yet. > I allowed instead for a action to be performed at the same time you > login/authenticate,this... > System.setProperty("authkit.action","/usr/bin/id"); > just before this... > lc.login(); > To clarify, safely ignored as you are already complete. > > Mike Hall mikehall at spacestar dot net > http://www.spacestar.net/users/mikehall > http://sourceforge.net/projects/macnative > > > Dmitry Markman From dmarkman at mac.com Mon Mar 20 07:44:45 2006 From: dmarkman at mac.com (Dmitry Markman) Date: Mon, 20 Mar 2006 09:44:45 -0500 Subject: [Rxtx] Mac OS X RXTX java installer In-Reply-To: References: <07D0DE29-BA32-4CFE-B036-66BC6423D385@buechse.de> <441AE3E0.2030503@willicon.de> <12531986.1142622114996.JavaMail.dmarkman@mac.com> <441B2674.9010409@willicon.de> <13577405.1142634732776.JavaMail.dmarkman@mac.com> <441B4182.8010407@willicon.de> <92CD0D6C-5BE8-426E-A46D-99452059FF49@mac.com> <441BBB2D.8030305@willicon.de> <441C4088.5090905@willicon.de> <64BC1E23-FDDE-4CE6-8863-CFC881CBC224@mac.com> Message-ID: it's in the commapi-0-0-1 branch I tested it right now: cvs co -r commapi-0-0-1 rxtx-devel and I got everything On Mar 20, 2006, at 9:25 AM, Trent Jarvi wrote: > On Mon, 20 Mar 2006, Dr. Douglas Lyon wrote: > >> Hi Trent, >> Thanks for the info on the CVS checkout procedure. >> I did that and am still not sure where the installer is. > > Hi Doug > > It does look like it was not cvs committed. There is no rxtx-devel/ > contrib/MacOSX directory in there at the moment. It was mentioned > that it was put under contrib. > > -- > Trent Jarvi > tjarvi at qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx Dmitry Markman From tjarvi at qbang.org Mon Mar 20 07:52:57 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 20 Mar 2006 07:52:57 -0700 (MST) Subject: [Rxtx] Mac OS X RXTX java installer In-Reply-To: References: <07D0DE29-BA32-4CFE-B036-66BC6423D385@buechse.de> <441AE3E0.2030503@willicon.de> <12531986.1142622114996.JavaMail.dmarkman@mac.com> <441B2674.9010409@willicon.de> <13577405.1142634732776.JavaMail.dmarkman@mac.com> <441B4182.8010407@willicon.de> <92CD0D6C-5BE8-426E-A46D-99452059FF49@mac.com> <441BBB2D.8030305@willicon.de> <441C4088.5090905@willicon.de> <64BC1E23-FDDE-4CE6-8863-CFC881CBC224@mac.com> Message-ID: On Mon, 20 Mar 2006, Dmitry Markman wrote: > it's in the commapi-0-0-1 branch > > I tested it right now: > cvs co -r commapi-0-0-1 rxtx-devel > > and I got everything > A fresh checkout worked. Here is a copy of the tree (just the installer bits) ftp://ftp.qbang.org/pub/rxtx/MacOSX-installer.zip -- Trent Jarvi tjarvi at qbang.org From lyon at docjava.com Mon Mar 20 08:08:26 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Mon, 20 Mar 2006 10:08:26 -0500 Subject: [Rxtx] Mac OS X RXTX java installer In-Reply-To: References: <07D0DE29-BA32-4CFE-B036-66BC6423D385@buechse.de> <441AE3E0.2030503@willicon.de> <12531986.1142622114996.JavaMail.dmarkman@mac.com> <441B2674.9010409@willicon.de> <13577405.1142634732776.JavaMail.dmarkman@mac.com> <441B4182.8010407@willicon.de> <92CD0D6C-5BE8-426E-A46D-99452059FF49@mac.com> <441BBB2D.8030305@willicon.de> <441C4088.5090905@willicon.de> <64BC1E23-FDDE-4CE6-8863-CFC881CBC224@mac.com> Message-ID: Hi All, Is the Auth package able to work properly on non Mac OS's? It was not clear from the doc or download. Thanks! - Doug From dmarkman at mac.com Mon Mar 20 08:15:22 2006 From: dmarkman at mac.com (Dmitry Markman) Date: Mon, 20 Mar 2006 10:15:22 -0500 Subject: [Rxtx] Mac OS X RXTX java installer In-Reply-To: References: <07D0DE29-BA32-4CFE-B036-66BC6423D385@buechse.de> <441AE3E0.2030503@willicon.de> <12531986.1142622114996.JavaMail.dmarkman@mac.com> <441B2674.9010409@willicon.de> <13577405.1142634732776.JavaMail.dmarkman@mac.com> <441B4182.8010407@willicon.de> <92CD0D6C-5BE8-426E-A46D-99452059FF49@mac.com> <441BBB2D.8030305@willicon.de> <441C4088.5090905@willicon.de> <64BC1E23-FDDE-4CE6-8863-CFC881CBC224@mac.com> Message-ID: <217312D8-CCCA-4859-ABA6-32DF1CC817B9@mac.com> thanks Trent, for putting it on ftp server On Mar 20, 2006, at 9:52 AM, Trent Jarvi wrote: > A fresh checkout worked. Here is a copy of the tree (just the > installer bits) > > ftp://ftp.qbang.org/pub/rxtx/MacOSX-installer.zip > Dmitry Markman From dmarkman at mac.com Mon Mar 20 09:14:03 2006 From: dmarkman at mac.com (Dmitry Markman) Date: Mon, 20 Mar 2006 11:14:03 -0500 Subject: [Rxtx] Mac OS X RXTX java installer In-Reply-To: References: <07D0DE29-BA32-4CFE-B036-66BC6423D385@buechse.de> <441AE3E0.2030503@willicon.de> <12531986.1142622114996.JavaMail.dmarkman@mac.com> <441B2674.9010409@willicon.de> <13577405.1142634732776.JavaMail.dmarkman@mac.com> <441B4182.8010407@willicon.de> <92CD0D6C-5BE8-426E-A46D-99452059FF49@mac.com> <441BBB2D.8030305@willicon.de> <441C4088.5090905@willicon.de> <64BC1E23-FDDE-4CE6-8863-CFC881CBC224@mac.com> Message-ID: <4DEBA6F0-DA45-4E84-823E-1F1AC48BDCCC@mac.com> no it will work only on mac os x however it's harmless to run it on other platform if you want to use it for other platform you have to do the following (I'll do it for linux) 1. modify RXTXInstaller class method public static RXTXInstaller getInstance() public static RXTXInstaller getInstance() { String osName = System.getProperty("os.name").toLowerCase(); if(osName.startsWith("mac")){ return new gnu.io.installer.macosx.MACOSXRXTXInstaller(); } else if(osName.startsWith("windows")){ return new gnu.io.installer.windows.WindowsRXTXInstaller(); }else if(osName.startsWith("linux")){ return new gnu.io.installer.linux.LinuxRXTXInstaller(); } return null; } 2. create folder gnu/io/installer/linux/ 3. create class Linux386RXTXInstaller package gnu.io.installer.linux; import java.io.File; public class Linux386RXTXInstaller extends gnu.io.installer.RXTXInstaller{ public Linux386RXTXInstaller(){ createJarFolder(); createLibFolder(); addJarResource("RXTXcomm.jar","/gnu/io/installer/resources/ linux/jar/RXTXcomm.dat"); addLibResource("librxtxSerial.so","/gnu/io/installer/ resources/linux/lib/librxtxSerial.so"); } protected void createJarFolder(){ String javaHome = System.getProperty("java.home"); char separator = File.separatorChar; jarFolder = new File(javaHome+separator+"lib"+separator+"ext"); } protected void createLibFolder(){ String javaHome = System.getProperty("java.home"); char separator = File.separatorChar; libFolder = new File(javaHome+separator+"bin"); } public void runPreProcess() {} //put here some action you need public void runPostProcess() {} //put here some action you need } 4. create folder /gnu/io/installer/resources/linux/jar and put there linux's version of RXTXcomm.dat (which is renamed RXTXcomm.jar) 5. create folder /gnu/io/installer/resources/linux/lib and put there linux's version of librxtxSerial. so 6. make sure that RXTXInstaller.jar has the following items: /gnu/io/installer/resources/linux/jar/RXTXcomm.jar /gnu/io/installer/resources/linux/lib/librxtxSerial.so 7. modify file installer.pref: jar file RXTXInstaller.jar must have the following item /gnu/io/installer/installer.pref that's basically it for windows you have to do the similar things: just replace linux to windows and librxtxSerial.so to rxtxSerial.dll and create appropriate gnu.io.installer.windows.WindowsRXTXInstaller class package gnu.io.installer.windows; import java.io.File; public class WindowsRXTXInstaller extends gnu.io.installer.RXTXInstaller{ public WindowsRXTXInstaller(){ createJarFolder(); createLibFolder(); addJarResource("RXTXcomm.jar","/gnu/io/installer/resources/ windows/jar/RXTXcomm.dat"); addLibResource("librxtxSerial.so","/gnu/io/installer/ resources/windows/lib/rxtxSerial.dll"); } protected void createJarFolder(){ String javaHome = System.getProperty("java.home"); char separator = File.separatorChar; jarFolder = new File(javaHome+separator+"lib"+separator+"ext"); } protected void createLibFolder(){ String javaHome = System.getProperty("java.home"); char separator = File.separatorChar; libFolder = new File(javaHome+separator+"bin"); } public void runPreProcess() {} //put here some action you need public void runPostProcess() {} //put here some action you need } installer.pref will look like On Mar 20, 2006, at 10:08 AM, Dr. Douglas Lyon wrote: > Hi All, > Is the Auth package able to work properly on > non Mac OS's? > It was not clear from the doc or download. > > Thanks! > - Doug > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx Dmitry Markman From joachim at buechse.de Mon Mar 20 10:49:06 2006 From: joachim at buechse.de (Joachim Buechse) Date: Mon, 20 Mar 2006 18:49:06 +0100 Subject: [Rxtx] BUG: Lock file stays even if port opening fails Message-ID: This was only tested on MacOSX but looking at the code, it should be true for all systems that use lock_uucp. I am opening a port which can not be opened (dialup port of a telephone paired via bluetooth but currently not reachable). The lock file is created and stays arround, even though the port open failed. After looking a bit through the code (of 2.17), I really wonder if it wouldn't be a good idea to make the "locking" an explicit operation called from the java code. This would certainly simplify the generation of meaningfull exceptions (and java based debugging). Maybe even the handling of "preopened" ports should be in the Java part of the lib (again for java based debugging puposes). That beeing said, I have no idea if this would be possible for the 2.07 implementation. Regards, Joachim From tjarvi at qbang.org Mon Mar 20 11:24:22 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 20 Mar 2006 11:24:22 -0700 (MST) Subject: [Rxtx] BUG: Lock file stays even if port opening fails In-Reply-To: References: Message-ID: On Mon, 20 Mar 2006, Joachim Buechse wrote: > This was only tested on MacOSX but looking at the code, it should be true > for all systems that use lock_uucp. > > I am opening a port which can not be opened (dialup port of a telephone > paired via bluetooth but currently not reachable). The lock file is > created and stays arround, even though the port open failed. > > > After looking a bit through the code (of 2.17), I really wonder if it > wouldn't be a good idea to make the "locking" an explicit operation > called from the java code. This would certainly simplify the generation > of meaningfull exceptions (and java based debugging). > Maybe even the handling of "preopened" ports should be in the Java part > of the lib (again for java based debugging puposes). That beeing said, I > have no idea if this would be possible for the 2.07 implementation. > > Regards, Hi Joachim It should be possible in the 2.0-7 implementation too. The calls to RXTXPort.java would not change. We would just do more there Moving more of that logic into Java would be better as many people don't like to look at C code. There is a liblockdev on most Linux distros that can do most of the C code and would be easier to use. The problem is embeded devices will not have that library. The preopened port code has not been really tested. That was a last minute request in a product cycle. I expect it will be tested this year though. As I recall, some devices really do not like CD raising on open. The preopened ports then allow people to mess around in java without power cycling the devices or losing data. -- Trent Jarvi tjarvi at qbang.org From joachim at buechse.de Mon Mar 20 12:01:08 2006 From: joachim at buechse.de (Joachim Buechse) Date: Mon, 20 Mar 2006 20:01:08 +0100 Subject: [Rxtx] BUG: Lock file stays even if port opening fails In-Reply-To: References: Message-ID: Hi Trent, What is your general feeling about moving code to Java? The last days I have been reading quite a bit of the code and there are several things, that might not work as expected. I'll give you two examples from is_device_locked: if LOCKDIR == /var/spool/locks the directory /var/spool/lock will not be checked. LOCKDIR is not checked for lockfiles with unexpected pefixes While these things have probably never been discovered in production, they are still possibly incorrect implementations. If it was Java code, I would write some unit tests producing the errors that could later be corrected. PS: One could imagine to actually implement the whole lockfile handling in Java using some native routines to get the values required (pid, st_dev, st_rdev, ...). On 20.03.2006, at 19:24, Trent Jarvi wrote: > On Mon, 20 Mar 2006, Joachim Buechse wrote: > >> This was only tested on MacOSX but looking at the code, it should >> be true for all systems that use lock_uucp. >> >> I am opening a port which can not be opened (dialup port of a >> telephone paired via bluetooth but currently not reachable). The >> lock file is created and stays arround, even though the port open >> failed. >> >> >> After looking a bit through the code (of 2.17), I really wonder if >> it wouldn't be a good idea to make the "locking" an explicit >> operation called from the java code. This would certainly simplify >> the generation of meaningfull exceptions (and java based debugging). >> Maybe even the handling of "preopened" ports should be in the Java >> part of the lib (again for java based debugging puposes). That >> beeing said, I have no idea if this would be possible for the 2.07 >> implementation. >> >> Regards, > > Hi Joachim > > It should be possible in the 2.0-7 implementation too. The calls > to RXTXPort.java would not change. We would just do more there > Moving more of that logic into Java would be better as many people > don't like to look at C code. There is a liblockdev on most Linux > distros that can do most of the C code and would be easier to use. > The problem is embeded devices will not have that library. > > The preopened port code has not been really tested. That was a > last minute request in a product cycle. I expect it will be tested > this year though. As I recall, some devices really do not like CD > raising on open. The preopened ports then allow people to mess > around in java without power cycling the devices or losing data. > > -- > Trent Jarvi > tjarvi at qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Mon Mar 20 12:21:02 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 20 Mar 2006 12:21:02 -0700 (MST) Subject: [Rxtx] BUG: Lock file stays even if port opening fails In-Reply-To: References: Message-ID: On Mon, 20 Mar 2006, Joachim Buechse wrote: > Hi Trent, > > What is your general feeling about moving code to Java? The last days I > have been reading quite a bit of the code and there are several things, > that might not work as expected. > > I'll give you two examples from is_device_locked: > > if LOCKDIR == /var/spool/locks the directory /var/spool/lock will not be > checked. > LOCKDIR is not checked for lockfiles with unexpected pefixes > > While these things have probably never been discovered in production, > they are still possibly incorrect implementations. If it was Java code, I > would write some unit tests producing the errors that could later be > corrected. > > PS: One could imagine to actually implement the whole lockfile handling > in Java using some native routines to get the values required (pid, > st_dev, st_rdev, ...). Hi Joachim I like the idea of moving more of the code into java but there are some things to consider. If you break this into multiple JNI calls, the performance will drop considerably during enumeration of ports. We are looking for 256 ports per dev type vs (16? in Sun's 2.0 and fewer types). Its hard to make assumptions. I've seen virtual ports start at /dev/foo100 for instance. It works out to over 7500 ports on Linux if you enable them all. We already trim that back by default. See Linux-all-ports in RXTXCommDriver.java. There are also native libraries that rxtx can link to. If you move too much into Java, linking to 'standard' libraries with distros will break. "configure --enable-liblock=yes" will not be doable. This is probably a favorable way with RedHat, Debian, Suse and others. Thats the right thing to do if there will be rpms, dpkg, .. For those reasons, I think it still make sense to keep it to a minimal ~3 calls to JNI code that we can use for speed and versatility. lock() isLocked(), unlock() perhaps. When I say speed, its more about avoiding crossing the JNI layer multiple times than java vs C performance. With versatility I think liblock is the right way for most but not all (embeded) linux distros. -- Trent Jarvi tjarvi at qbang.org From joachim at buechse.de Mon Mar 20 12:42:04 2006 From: joachim at buechse.de (Joachim Buechse) Date: Mon, 20 Mar 2006 20:42:04 +0100 Subject: [Rxtx] BUG: Lock file stays even if port opening fails In-Reply-To: References: Message-ID: <82C19FE7-DDCB-45B6-B2C9-7606B66F0124@buechse.de> Ok, what about providing a default implementation in Java? The RXTXCommDriver would call a (native) function useNativeLocking and if it returns true, call the native functions for lock() isLocked (), unlock(), else is would use the Java based default implementation. This could possibly be overriden by a property (again for debugging). Joachim On 20.03.2006, at 20:21, Trent Jarvi wrote: > On Mon, 20 Mar 2006, Joachim Buechse wrote: > >> Hi Trent, >> >> What is your general feeling about moving code to Java? The last >> days I have been reading quite a bit of the code and there are >> several things, that might not work as expected. >> >> I'll give you two examples from is_device_locked: >> >> if LOCKDIR == /var/spool/locks the directory /var/spool/lock will >> not be checked. >> LOCKDIR is not checked for lockfiles with unexpected pefixes >> >> While these things have probably never been discovered in >> production, they are still possibly incorrect implementations. If >> it was Java code, I would write some unit tests producing the >> errors that could later be corrected. >> >> PS: One could imagine to actually implement the whole lockfile >> handling in Java using some native routines to get the values >> required (pid, st_dev, st_rdev, ...). > > Hi Joachim > > I like the idea of moving more of the code into java but there are > some things to consider. > > If you break this into multiple JNI calls, the performance will > drop considerably during enumeration of ports. We are looking for > 256 ports per dev type vs (16? in Sun's 2.0 and fewer types). Its > hard to make assumptions. I've seen virtual ports start at /dev/ > foo100 for instance. > > It works out to over 7500 ports on Linux if you enable them all. > We already trim that back by default. See Linux-all-ports in > RXTXCommDriver.java. > > There are also native libraries that rxtx can link to. If you move > too much into Java, linking to 'standard' libraries with distros > will break. "configure --enable-liblock=yes" will not be doable. > This is probably a favorable way with RedHat, Debian, Suse and > others. Thats the right thing to do if there will be rpms, dpkg, .. > > For those reasons, I think it still make sense to keep it to a > minimal ~3 calls to JNI code that we can use for speed and > versatility. lock() isLocked(), unlock() perhaps. When I say > speed, its more about avoiding crossing the JNI layer multiple > times than java vs C performance. With versatility I think liblock > is the right way for most but not all (embeded) linux distros. > > -- > Trent Jarvi > tjarvi at qbang.org > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Mon Mar 20 12:44:47 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 20 Mar 2006 12:44:47 -0700 (MST) Subject: [Rxtx] BUG: Lock file stays even if port opening fails In-Reply-To: <82C19FE7-DDCB-45B6-B2C9-7606B66F0124@buechse.de> References: <82C19FE7-DDCB-45B6-B2C9-7606B66F0124@buechse.de> Message-ID: On Mon, 20 Mar 2006, Joachim Buechse wrote: > Ok, what about providing a default implementation in Java? > > The RXTXCommDriver would call a (native) function useNativeLocking and if > it returns true, call the native functions for lock() isLocked(), > unlock(), else is would use the Java based default implementation. This > could possibly be overriden by a property (again for debugging). > Hi Joachim That would be OK with me. -- Trent Jarvi tjarvi at qbang.org From dmarkman at mac.com Mon Mar 20 22:27:45 2006 From: dmarkman at mac.com (Dmitry Markman) Date: Tue, 21 Mar 2006 00:27:45 -0500 Subject: [Rxtx] binaries request Message-ID: <42702213-C222-4937-A585-7CFB17E47608@mac.com> Hi can somebody send me latest linux and windows binaries, please? or where I can find them (I didn't find them in the latest tareball) I gave up with my cygwin: something wrong I have no idea what java doesn't understand /cygwin/c syntax after I changed makefile it did java part but after that gcc 3.4.4 started to complain I set buffer length to 999 lines but I didn't get beginning of the story something wrong with my 1.4.2_09/include/jni.h gcc doesn't like it anyway I gave up thanks in advance Dmitry Markman -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060320/f8cbc57c/attachment-0032.html From tjarvi at qbang.org Mon Mar 20 22:36:48 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 20 Mar 2006 22:36:48 -0700 (MST) Subject: [Rxtx] binaries request In-Reply-To: <42702213-C222-4937-A585-7CFB17E47608@mac.com> References: <42702213-C222-4937-A585-7CFB17E47608@mac.com> Message-ID: On Tue, 21 Mar 2006, Dmitry Markman wrote: > Hi > can somebody send me latest linux and windows binaries, please? > > or where I can find them (I didn't find them in the latest tareball) > > I gave up with my cygwin: something wrong I have no idea what > java doesn't understand /cygwin/c syntax > after I changed makefile it did java part > but after that gcc 3.4.4 started to complain > I set buffer length to 999 lines but I didn't get beginning of the story > something wrong with my 1.4.2_09/include/jni.h gcc doesn't like it > anyway I gave up > > thanks in advance > Hi Dmitry The bins are here: ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7-bins-r2.zip Here are the files in the zip you want. Jar: rxtx-2.1-7-bins-r2/RXTXcomm.jar Windows: rxtx-2.1-7-bins-r2/Windows/i368-mingw32/rxtxSerial.dll Linux (x86) rxtx-2.1-7-bins-r2/Linux/i686-unknown-linux-gnu/librxtxSerial.so There are others in there including Parallel port support but those are the main ones for testing. -- Trent Jarvi tjarvi at qbang.org From dmarkman at mac.com Mon Mar 20 23:05:59 2006 From: dmarkman at mac.com (Dmitry Markman) Date: Tue, 21 Mar 2006 01:05:59 -0500 Subject: [Rxtx] binaries request In-Reply-To: References: <42702213-C222-4937-A585-7CFB17E47608@mac.com> Message-ID: thank you very much but windows's readme says: rxtxSerial.dll had to be recomopiled to link in missing native methods. should I ignore it? or what? thanks again also I understand that I should use mingw not cygwin I'll try to install mingw On Mar 21, 2006, at 12:36 AM, Trent Jarvi wrote: > On Tue, 21 Mar 2006, Dmitry Markman wrote: > >> Hi >> can somebody send me latest linux and windows binaries, please? >> >> or where I can find them (I didn't find them in the latest tareball) >> >> I gave up with my cygwin: something wrong I have no idea what >> java doesn't understand /cygwin/c syntax >> after I changed makefile it did java part >> but after that gcc 3.4.4 started to complain >> I set buffer length to 999 lines but I didn't get beginning of the >> story >> something wrong with my 1.4.2_09/include/jni.h gcc doesn't like it >> anyway I gave up >> >> thanks in advance >> > > Hi Dmitry > > The bins are here: > > ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7-bins-r2.zip > > Here are the files in the zip you want. > > Jar: > > rxtx-2.1-7-bins-r2/RXTXcomm.jar > > Windows: > > rxtx-2.1-7-bins-r2/Windows/i368-mingw32/rxtxSerial.dll > > Linux (x86) > > rxtx-2.1-7-bins-r2/Linux/i686-unknown-linux-gnu/librxtxSerial.so > > There are others in there including Parallel port support but those > are the main ones for testing. > > -- > Trent Jarvi > tjarvi at qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx Dmitry Markman From tjarvi at qbang.org Mon Mar 20 23:20:33 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 20 Mar 2006 23:20:33 -0700 (MST) Subject: [Rxtx] binaries request In-Reply-To: References: <42702213-C222-4937-A585-7CFB17E47608@mac.com> Message-ID: On Tue, 21 Mar 2006, Dmitry Markman wrote: > thank you very much > > but windows's readme says: > rxtxSerial.dll had to be recomopiled to link in missing native methods. > > should I ignore it? or what? > Hi Dmitry That dll should be OK. r2 is the recompile linked to the missing native method. The readme explains why it was recompiled; fuser.o was not linked into the dll in the first release. -- Trent Jarvi tjarvi at qbang.org From ariantristan at yahoo.com Mon Mar 20 23:55:24 2006 From: ariantristan at yahoo.com (Lambok Sianturi) Date: Mon, 20 Mar 2006 22:55:24 -0800 (PST) Subject: [Rxtx] jvm issue Message-ID: <20060321065524.94779.qmail@web50701.mail.yahoo.com> Hi All, This is my first time to join RxTx mailing list. I thank you all for allowing others to sign in in requests help. I use the latest RxTx lib in Fedora 3 with java version 1.4.2_09 b05. And I got this error: # # An unexpected error has been detected by HotSpot Virtual Machine: # # SIGSEGV (0xb) at pc=0x00bf27f3, pid=2633, tid=3086112448 # # Java VM: Java HotSpot(TM) Client VM (1.4.2_09-b05 mixed mode) # Problematic frame: # C [ld-linux.so.2+0xa7f3] # # An error report file with more information is saved as hs_err_pid2633.log # # If you would like to submit a bug report, please visit: # http://java.sun.com/webapps/bugreport/crash.jsp # ./run.sh: line 3: 2633 Aborted /usr/local/java/bin/java -Djava.library.path=/usr/local/java/jre/lib/ -Djsmsengine.debug=true -classpath jsmsengine.jar:smsgateway.jar:classes12.jar:RXTXcomm.jar:. com.api.sms.SMSServer What is the jvm depedency for the latest library? Can I use 1.4.2_09 b05? Thanks in advance. Arian --------------------------------- Yahoo! Mail Use Photomail to share photos without annoying attachments. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060320/83d58dd7/attachment-0032.html From f.frumento at ngi.it Tue Mar 21 00:21:47 2006 From: f.frumento at ngi.it (Fabio Frumento) Date: Tue, 21 Mar 2006 08:21:47 +0100 Subject: [Rxtx] Javadoc on the go Message-ID: <441FA98B.9050701@ngi.it> Hi Trent, sorry for the big delay but my job is running wild, i was out for some time but now i'm back and ready to continue the javadoc for Rxtx. Did you used the last javadoc patch i sent you ? let me know if i have to send it to you again or not. regards Fabio From lyon at docjava.com Tue Mar 21 00:51:18 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Tue, 21 Mar 2006 02:51:18 -0500 Subject: [Rxtx] lock files Message-ID: Hi All, You know, if the use of lock files were under Java control (rather than a build-time decision), it might enable a more unified binary distro. It might also facilitate quick prototyping of non-lock file approaches to resolving serial port contention issues (i.e., mac-like approaches vs. linux approaches, etc.). I realize that this is a radical overhaul of the lock file policy issue. Also, it may harm performance. On the other hand, our benchmarks on JNI overhead for modern processors indicate performance impact should be minimal. Perhaps it is more of an issue with the toybox systems. Suppose there were a class with a reasonable default...someone might write: SerialPortLockPolicy.setPolicy(SerialPortLockPolicy.UNIX_LOCK_FILE); SerialPortLockPolicy.setPolicy(SerialPortLockPolicy.NO_LOCK_CHECKING); SerialPortLockPolicy.setPolicy(SerialPortLockPolicy.MAC_STYLE); Thus, we could have a run-time reconfiguration of the serial port lock policy. A special NO_LOCK version of the binary would no longer be required. Any thoughts on this? Thanks! - Doug From joachim at buechse.de Tue Mar 21 03:09:09 2006 From: joachim at buechse.de (Joachim Buechse) Date: Tue, 21 Mar 2006 11:09:09 +0100 Subject: [Rxtx] lock files In-Reply-To: References: Message-ID: <8E12916A-1B9A-4FF2-B684-E2D1C794221B@buechse.de> This is pretty much what I thought about when I suggested, that the default behaviour could be overwritten with a property. I am very much in favor of this approach. In particular this allows much easier debugging for PC based java developers. I think big parts of the Java (and maybe some parts of the C code) could use a bit of a structural workover (unit tests, javadoc, synchronization, etc). Maybe there should be a CVS branch for this experimental version. I'd be happy to contribute a first workover for some of the Java code. Designing for testability and implementing a good bunch of unit tests has been a strategy that worked quite well in the Java projects I lead. And it ultimately allows more liberal change permission. Regards, Joachim On 21.03.2006, at 08:51, Dr. Douglas Lyon wrote: > Hi All, > You know, if the use of lock files were > under Java control (rather than a build-time decision), > it might enable a more unified binary distro. It might also > facilitate quick prototyping of non-lock file approaches > to resolving serial port contention issues (i.e., mac-like > approaches vs. linux approaches, etc.). > > I realize that this is a radical overhaul of the lock file policy > issue. Also, it may harm performance. On the other hand, > our benchmarks on JNI overhead for modern processors indicate > performance impact should be minimal. Perhaps it is more of > an issue with the toybox systems. > > Suppose there were a class with a reasonable default...someone > might write: > SerialPortLockPolicy.setPolicy(SerialPortLockPolicy.UNIX_LOCK_FILE); > SerialPortLockPolicy.setPolicy(SerialPortLockPolicy.NO_LOCK_CHECKING); > SerialPortLockPolicy.setPolicy(SerialPortLockPolicy.MAC_STYLE); > > Thus, we could have a run-time reconfiguration of the serial port lock > policy. A special NO_LOCK version of the binary would no longer > be required. > > Any thoughts on this? > > Thanks! > - Doug > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From joachim at buechse.de Tue Mar 21 06:23:08 2006 From: joachim at buechse.de (Joachim Buechse) Date: Tue, 21 Mar 2006 14:23:08 +0100 Subject: [Rxtx] PATCH: use of ioctl(fd, TIOCEXCL) instead of lockfiles Message-ID: <923AE774-EEA2-4911-92D8-32BB27802C8B@buechse.de> Here is the patch for the ioctl(fd, TIOCEXCL). I have verified this only for OSX 10.4.5, hence it is only defined for APPLE. However, it should work at least for Solaris as well. If a process has requested TIOEXCL further open calls by other user processes will fail. The patch also disables uucp style locking for APPLE. Obviously this is discussable. I think it is the way to go, as it eliminates creating the lock directory which doesnt exist on the standard installation and it eliminates messing with the system group definitions (adding users to group uucp). Regarding the possibility of root processes opening a device which is locked - I consider this a feature not a potential problem. It is highly unlikely, that somebody is crazy enough to run a JavaVM as root (unless he has no other means of getting a restricted IP port opened, ie doesnt understand ipfw). Anyway, even if the process runs as root, it fails when calling ioctl(fd, TIOCEXCL). It could however still open the port to listen for RING events. I.e. a fax server which needs to see incoming calls but otherwise doesnt want to block the port. So the only case where the proposed mechanism fails is, if an incorrectly implemented process running as root conflicts with a user process. I think this can be accepted. Regards, Joachim PS: If this patch is generally accepted, the installer and Mac doku should obviously be changed as well. Index: SerialImp.c =================================================================== RCS file: /usr/local/cvsroot/rxtx-devel/src/SerialImp.c,v retrieving revision 1.46.2.187 diff -u -r1.46.2.187 SerialImp.c --- SerialImp.c 29 Jan 2006 22:19:04 -0000 1.46.2.187 +++ SerialImp.c 21 Mar 2006 12:59:16 -0000 @@ -656,6 +656,25 @@ fd=OPEN (filename, O_RDWR | O_NOCTTY | O_NONBLOCK ); } while (fd < 0 && errno==EINTR); +#ifdef OPEN_EXCL + // Note that open() follows POSIX semantics: multiple open() calls to + // the same file will succeed unless the TIOCEXCL ioctl is issued. + // This will prevent additional opens except by root-owned processes. + // See tty(4) ("man 4 tty") and ioctl(2) ("man 2 ioctl") for details. + + if (fd >= 0 && (ioctl(fd, TIOCEXCL) == -1)) + { + sprintf( message, "open: exclusive access denied for % s\n", + filename ); + report( message ); + report_error( message ); + + close(fd); + goto fail; + } +#endif /* OPEN_EXCL */ + + if( configure_port( fd ) ) goto fail; (*env)->ReleaseStringUTFChars( env, jstr, filename ); sprintf( message, "open: fd returned is %i\n", fd ); Index: SerialImp.h =================================================================== RCS file: /usr/local/cvsroot/rxtx-devel/src/SerialImp.h,v retrieving revision 1.11.2.49 diff -u -r1.11.2.49 SerialImp.h --- SerialImp.h 5 Jul 2005 17:47:21 -0000 1.11.2.49 +++ SerialImp.h 21 Mar 2006 12:59:17 -0000 @@ -135,7 +135,8 @@ /*# define LOCKDIR "/var/spool/uucp"*/ # define LOCKDIR "/var/lock" # define LOCKFILEPREFIX "LK." -# define UUCP +/*# define UUCP*/ +# define OPEN_EXCL #endif /* __APPLE__ */ #if defined(__NetBSD__) # define DEVICEDIR "/dev/" From tjarvi at qbang.org Tue Mar 21 10:26:08 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 21 Mar 2006 10:26:08 -0700 (MST) Subject: [Rxtx] Javadoc on the go In-Reply-To: <441FA98B.9050701@ngi.it> References: <441FA98B.9050701@ngi.it> Message-ID: On Tue, 21 Mar 2006, Fabio Frumento wrote: > Hi Trent, > > sorry for the big delay but my job is running wild, i was out for some > time but now i'm back and ready to continue the javadoc for Rxtx. > > Did you used the last javadoc patch i sent you ? let me know if i have to > send it to you again or not. > > regards > > Fabio Hi Fabio The patch is in the rxtx mail-list archives. It will be going in soon. I did not see a time critical portion. I'll probably be going through the list since the last batch of patches this weekend and putting them into CVS. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Tue Mar 21 10:57:18 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 21 Mar 2006 10:57:18 -0700 (MST) Subject: [Rxtx] jvm issue In-Reply-To: <20060321065524.94779.qmail@web50701.mail.yahoo.com> References: <20060321065524.94779.qmail@web50701.mail.yahoo.com> Message-ID: On Mon, 20 Mar 2006, Lambok Sianturi wrote: > Hi All, > This is my first time to join RxTx mailing list. I thank you all for allowing others to sign in in requests help. > I use the latest RxTx lib in Fedora 3 with java version 1.4.2_09 b05. And I got this error: > > # > # An unexpected error has been detected by HotSpot Virtual Machine: > # > # SIGSEGV (0xb) at pc=0x00bf27f3, pid=2633, tid=3086112448 > # > # Java VM: Java HotSpot(TM) Client VM (1.4.2_09-b05 mixed mode) > # Problematic frame: > # C [ld-linux.so.2+0xa7f3] A native library loading error? What happens if you recompile rxtx on your system and install that? This sounds like an ABI problem? rxtx 2.1-7 was compiled with a gcc 2.96 toolchain as I recall. The hope is newer system will be backwards compatible. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Tue Mar 21 11:05:29 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 21 Mar 2006 11:05:29 -0700 (MST) Subject: [Rxtx] PATCH: use of ioctl(fd, TIOCEXCL) instead of lockfiles In-Reply-To: <923AE774-EEA2-4911-92D8-32BB27802C8B@buechse.de> References: <923AE774-EEA2-4911-92D8-32BB27802C8B@buechse.de> Message-ID: On Tue, 21 Mar 2006, Joachim Buechse wrote: > Here is the patch for the ioctl(fd, TIOCEXCL). I have verified this only > for OSX 10.4.5, hence it is only defined for APPLE. However, it should > work at least for Solaris as well. > > If a process has requested TIOEXCL further open calls by other user > processes will fail. > > The patch also disables uucp style locking for APPLE. Obviously this is > discussable. I think it is the way to go, as it eliminates creating the > lock directory which doesnt exist on the standard installation and it > eliminates messing with the system group definitions (adding users to > group uucp). > > Regarding the possibility of root processes opening a device which is > locked - I consider this a feature not a potential problem. It is highly > unlikely, that somebody is crazy enough to run a JavaVM as root (unless > he has no other means of getting a restricted IP port opened, ie doesnt > understand ipfw). Anyway, even if the process runs as root, it fails when > calling ioctl(fd, TIOCEXCL). It could however still open the port to > listen for RING events. I.e. a fax server which needs to see incoming > calls but otherwise doesnt want to block the port. So the only case where > the proposed mechanism fails is, if an incorrectly implemented process > running as root conflicts with a user process. I think this can be > accepted. > > Regards, > Joachim > > PS: If this patch is generally accepted, the installer and Mac doku > should obviously be changed as well. > > > Index: SerialImp.c > =================================================================== > RCS file: /usr/local/cvsroot/rxtx-devel/src/SerialImp.c,v > retrieving revision 1.46.2.187 > diff -u -r1.46.2.187 SerialImp.c > --- SerialImp.c 29 Jan 2006 22:19:04 -0000 1.46.2.187 > +++ SerialImp.c 21 Mar 2006 12:59:16 -0000 > @@ -656,6 +656,25 @@ > fd=OPEN (filename, O_RDWR | O_NOCTTY | O_NONBLOCK ); > } while (fd < 0 && errno==EINTR); > > +#ifdef OPEN_EXCL > + // Note that open() follows POSIX semantics: multiple open() > calls to > + // the same file will succeed unless the TIOCEXCL ioctl is > issued. > + // This will prevent additional opens except by root-owned > processes. > + // See tty(4) ("man 4 tty") and ioctl(2) ("man 2 ioctl") for > details. > + > + if (fd >= 0 && (ioctl(fd, TIOCEXCL) == -1)) > + { > + sprintf( message, "open: exclusive access denied for % > s\n", > + filename ); > + report( message ); > + report_error( message ); > + > + close(fd); > + goto fail; > + } > +#endif /* OPEN_EXCL */ > + > + > if( configure_port( fd ) ) goto fail; > (*env)->ReleaseStringUTFChars( env, jstr, filename ); > sprintf( message, "open: fd returned is %i\n", fd ); > Index: SerialImp.h > =================================================================== > RCS file: /usr/local/cvsroot/rxtx-devel/src/SerialImp.h,v > retrieving revision 1.11.2.49 > diff -u -r1.11.2.49 SerialImp.h > --- SerialImp.h 5 Jul 2005 17:47:21 -0000 1.11.2.49 > +++ SerialImp.h 21 Mar 2006 12:59:17 -0000 > @@ -135,7 +135,8 @@ > /*# define LOCKDIR "/var/spool/uucp"*/ > # define LOCKDIR "/var/lock" > # define LOCKFILEPREFIX "LK." > -# define UUCP > +/*# define UUCP*/ > +# define OPEN_EXCL > #endif /* __APPLE__ */ > #if defined(__NetBSD__) > # define DEVICEDIR "/dev/" > This looks like a good start. What do you think Dmitry? Perhaps all systems with TIOCEXCL defined should use that though. Even if they use lockfiles. It wont hurt anything. That would catch people hacking their own serial apps without checking lockfiles. Its a good idea to avoid C++ style comments in the C portions. Some older systems don't deal with them well. If it's just for Mac OS X, it isn't a big deal. I think it was the Irix compiler that was problematic? -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Tue Mar 21 11:22:05 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 21 Mar 2006 11:22:05 -0700 (MST) Subject: [Rxtx] lock files In-Reply-To: <8E12916A-1B9A-4FF2-B684-E2D1C794221B@buechse.de> References: <8E12916A-1B9A-4FF2-B684-E2D1C794221B@buechse.de> Message-ID: We can try it. Maybe the JNI is much improved. The nice thing about linking into liblock is distros then worry about lockfiles on their systems. This way, we have to deal with any changes that may show up. On Tue, 21 Mar 2006, Joachim Buechse wrote: > This is pretty much what I thought about when I suggested, that the > default behaviour could be overwritten with a property. I am very much in > favor of this approach. In particular this allows much easier debugging > for PC based java developers. > > I think big parts of the Java (and maybe some parts of the C code) could > use a bit of a structural workover (unit tests, javadoc, synchronization, > etc). Maybe there should be a CVS branch for this experimental version. > I'd be happy to contribute a first workover for some of the Java code. > Designing for testability and implementing a good bunch of unit tests has > been a strategy that worked quite well in the Java projects I lead. And > it ultimately allows more liberal change permission. > > Regards, > Joachim > > > On 21.03.2006, at 08:51, Dr. Douglas Lyon wrote: > >> Hi All, >> You know, if the use of lock files were >> under Java control (rather than a build-time decision), >> it might enable a more unified binary distro. It might also >> facilitate quick prototyping of non-lock file approaches >> to resolving serial port contention issues (i.e., mac-like >> approaches vs. linux approaches, etc.). >> >> I realize that this is a radical overhaul of the lock file policy >> issue. Also, it may harm performance. On the other hand, >> our benchmarks on JNI overhead for modern processors indicate >> performance impact should be minimal. Perhaps it is more of >> an issue with the toybox systems. >> >> Suppose there were a class with a reasonable default...someone >> might write: >> SerialPortLockPolicy.setPolicy(SerialPortLockPolicy.UNIX_LOCK_FILE); >> SerialPortLockPolicy.setPolicy(SerialPortLockPolicy.NO_LOCK_CHECKING); >> SerialPortLockPolicy.setPolicy(SerialPortLockPolicy.MAC_STYLE); >> >> Thus, we could have a run-time reconfiguration of the serial port lock >> policy. A special NO_LOCK version of the binary would no longer >> be required. >> >> Any thoughts on this? >> >> Thanks! >> - Doug >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From dmarkman at mac.com Tue Mar 21 16:05:17 2006 From: dmarkman at mac.com (Dmitry Markman) Date: Tue, 21 Mar 2006 18:05:17 -0500 Subject: [Rxtx] PATCH: use of ioctl(fd, TIOCEXCL) instead of lockfiles In-Reply-To: References: <923AE774-EEA2-4911-92D8-32BB27802C8B@buechse.de> Message-ID: <512AC70C-BB86-48F2-A83C-023F35C23BAB@mac.com> I think it's cool, but I'd like to have that property implementation when user can choose between locking mechanism about comments: it's easy to change comments to the C style or we can use extensions of the file to cpp so c++ compiler will be used On Mar 21, 2006, at 1:05 PM, Trent Jarvi wrote: > This looks like a good start. What do you think Dmitry? Perhaps > all systems with TIOCEXCL defined should use that though. Even if > they use lockfiles. It wont hurt anything. That would catch > people hacking their own serial apps without checking lockfiles. > > Its a good idea to avoid C++ style comments in the C portions. > Some older systems don't deal with them well. If it's just for Mac > OS X, it isn't a big deal. I think it was the Irix compiler that > was problematic? Dmitry Markman From dmarkman at mac.com Tue Mar 21 16:13:00 2006 From: dmarkman at mac.com (Dmitry Markman) Date: Tue, 21 Mar 2006 18:13:00 -0500 Subject: [Rxtx] PATCH: use of ioctl(fd, TIOCEXCL) instead of lockfiles In-Reply-To: References: <923AE774-EEA2-4911-92D8-32BB27802C8B@buechse.de> Message-ID: I'd like to add that creating locking folder isn't a big deal we never had a problem related to the lock folders, because we always used installer on mac os x from other hand I'm not very much familiar with iotcl locking approach and I'm not sure it's more efficient Joachim wrote "I think it is the way to go, as it eliminates creating the lock directory which doesnt exist on the standard installation and it eliminates messing with the system group definitions (adding users to group uucp)." but I really didn't have any problem with that 1. doesn't exist on the standard installation there are many-many things that don't exist in the standard installation so I don't think that argument is strong enough 2. messing with the system group definitions I don't think we're messing with the group definition mac os x provides very clear way to set up group's members and together with Greg Guerin AuthKit there is no problem to set those definitions so I don't think that argument is strong either but from other hand using iotcl is more promising and is more elegant On Mar 21, 2006, at 1:05 PM, Trent Jarvi wrote: > > This looks like a good start. What do you think Dmitry? Perhaps > all systems with TIOCEXCL defined should use that though. Even if > they use lockfiles. It wont hurt anything. That would catch > people hacking their own serial apps without checking lockfiles. Dmitry Markman From joachim at buechse.de Wed Mar 22 04:46:45 2006 From: joachim at buechse.de (Joachim Buechse) Date: Wed, 22 Mar 2006 12:46:45 +0100 Subject: [Rxtx] PATCH: use of ioctl(fd, TIOCEXCL) instead of lockfiles In-Reply-To: References: <923AE774-EEA2-4911-92D8-32BB27802C8B@buechse.de> Message-ID: Sorry, I was not very clear with my arguments, so I will try again;-) Please, don't take this as an attack against work that has been done. I think the contributions that have been made in the past were made in a good spirit. But I really believe, that the current solution for OSX has many shortcomings and should be changed as soon as possible. lock files --- The /var/lock folder does not exist on the standard OSX installation, however the standard installation includes several applications that use serial ports (i.e. the FAX capability). This indicates, that the lock folder approach will not work well with system components. Applications for OSX will generally try to live in harmony with system components (except for HP print drivers of course). I think RXTX should follow this approach as well. uucp group --- Accessing serial ports is not an admin privileged operation on OSX. Any user (world) has read/write privileges on /dev/tty*. So the system default is to not enforce any group membership to access these ports. The group uucp however is a system group on all unix systems I know. It exists for certain system processes. A non admin user should in general not be a member of this group. Quite arguably no user should ever be a member of this group. Installer --- My general opinion is, that - no Installer should touch user or group data without warning - no Application Installer should touch groups which are not specific to the very application installed - no Installer should ever add regular users to a system group The current installer injects the installing user in the group uucp without warning about this change and without giving the option to "opt out" of this change. This is a potential security risk (but not currently a real one, as OSX contains no folders belonging to group uucp). The current installer does not work for multi user systems. It puts the installing user in the uucp group. However the installing user is not necessarily the user that will use the application. Putting all users that may use a serial port application in the system group uucp seems like a very invasive approach to me. Besides that, newly created users will not automatically be in the group and hence, serial applications will "break" for new users without obvious reasons. Avoiding the lock files will allow self contained applications (i.e. drag&drop installation). In my eyes this is largely preferable over an installer that requests admin privileges. Adding up all these points indicates very strongly, that the lock-file implementation is not the way to go on OSX. Regards, Joachim On 22.03.2006, at 00:13, Dmitry Markman wrote: > I'd like to add that > > creating locking folder isn't a big deal > we never had a problem related to the lock folders, because we > always used installer on mac os x > from other hand I'm not very much familiar with iotcl locking > approach and I'm not sure it's more efficient > > Joachim wrote "I think it is the way to go, as it eliminates > creating the lock directory which doesnt exist on the standard > installation and it eliminates messing with the system group > definitions (adding users to group uucp)." but I really didn't have > any problem with that > > 1. doesn't exist on the standard installation > there are many-many things that don't exist in the standard > installation so I don't think that argument is strong enough > 2. messing with the system group definitions > I don't think we're messing with the group definition > mac os x provides very clear way to set up group's members and > together with Greg Guerin AuthKit there is no problem to set those > definitions > so I don't think that argument is strong either > but from other hand using iotcl is more promising and is more elegant > > > > On Mar 21, 2006, at 1:05 PM, Trent Jarvi wrote: > >> >> This looks like a good start. What do you think Dmitry? Perhaps >> all systems with TIOCEXCL defined should use that though. Even if >> they use lockfiles. It wont hurt anything. That would catch >> people hacking their own serial apps without checking lockfiles. > > Dmitry Markman > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From dmarkman at mac.com Wed Mar 22 05:27:13 2006 From: dmarkman at mac.com (Dmitry Markman) Date: Wed, 22 Mar 2006 07:27:13 -0500 Subject: [Rxtx] PATCH: use of ioctl(fd, TIOCEXCL) instead of lockfiles In-Reply-To: References: <923AE774-EEA2-4911-92D8-32BB27802C8B@buechse.de> Message-ID: <83440CF3-DCD8-41C1-B941-F227232C27E3@mac.com> thanks for the very good explanation I didn't think that you were attacking any thing, so don't worry I just had feeling, that there were more aesthetic reasons for going to ioctl then real necessity now you explained everything quite well (BTW, asfar as I remember installer asks admin password so it wasn't quiet, but it really doesn't matter now) thanks On Mar 22, 2006, at 6:46 AM, Joachim Buechse wrote: > Sorry, I was not very clear with my arguments, so I will try again;-) > > Please, don't take this as an attack against work that has been > done. I think the contributions that have been made in the past > were made in a good spirit. But I really believe, that the current > solution for OSX has many shortcomings and should be changed as > soon as possible. > > lock files > --- > The /var/lock folder does not exist on the standard OSX > installation, however the standard installation includes several > applications that use serial ports (i.e. the FAX capability). This > indicates, that the lock folder approach will not work well with > system components. Applications for OSX will generally try to live > in harmony with system components (except for HP print drivers of > course). I think RXTX should follow this approach as well. > > uucp group > --- > Accessing serial ports is not an admin privileged operation on OSX. > Any user (world) has read/write privileges on /dev/tty*. So the > system default is to not enforce any group membership to access > these ports. The group uucp however is a system group on all unix > systems I know. It exists for certain system processes. A non admin > user should in general not be a member of this group. Quite > arguably no user should ever be a member of this group. > > Installer > --- > My general opinion is, that > - no Installer should touch user or group data without warning > - no Application Installer should touch groups which are not > specific to the very application installed > - no Installer should ever add regular users to a system group > > The current installer injects the installing user in the group uucp > without warning about this change and without giving the option to > "opt out" of this change. This is a potential security risk (but > not currently a real one, as OSX contains no folders belonging to > group uucp). > > The current installer does not work for multi user systems. It puts > the installing user in the uucp group. However the installing user > is not necessarily the user that will use the application. Putting > all users that may use a serial port application in the system > group uucp seems like a very invasive approach to me. Besides that, > newly created users will not automatically be in the group and > hence, serial applications will "break" for new users without > obvious reasons. > > > Avoiding the lock files will allow self contained applications > (i.e. drag&drop installation). In my eyes this is largely > preferable over an installer that requests admin privileges. Adding > up all these points indicates very strongly, that the lock-file > implementation is not the way to go on OSX. > > Regards, > Joachim > > > On 22.03.2006, at 00:13, Dmitry Markman wrote: > >> I'd like to add that >> >> creating locking folder isn't a big deal >> we never had a problem related to the lock folders, because we >> always used installer on mac os x >> from other hand I'm not very much familiar with iotcl locking >> approach and I'm not sure it's more efficient >> >> Joachim wrote "I think it is the way to go, as it eliminates >> creating the lock directory which doesnt exist on the standard >> installation and it eliminates messing with the system group >> definitions (adding users to group uucp)." but I really didn't >> have any problem with that >> >> 1. doesn't exist on the standard installation >> there are many-many things that don't exist in the standard >> installation so I don't think that argument is strong enough >> 2. messing with the system group definitions >> I don't think we're messing with the group definition >> mac os x provides very clear way to set up group's members and >> together with Greg Guerin AuthKit there is no problem to set those >> definitions >> so I don't think that argument is strong either >> but from other hand using iotcl is more promising and is more elegant >> >> >> >> On Mar 21, 2006, at 1:05 PM, Trent Jarvi wrote: >> >>> >>> This looks like a good start. What do you think Dmitry? Perhaps >>> all systems with TIOCEXCL defined should use that though. Even >>> if they use lockfiles. It wont hurt anything. That would catch >>> people hacking their own serial apps without checking lockfiles. >> >> Dmitry Markman >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx Dmitry Markman From lyon at docjava.com Wed Mar 22 06:12:18 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Wed, 22 Mar 2006 08:12:18 -0500 Subject: [Rxtx] sole of a new design pattern Message-ID: Hi All, I have been thinking about how we design the serial port software. I think we need a new design pattern. For lack of a better term, I shall call it: The Parametric Singleton Design Pattern By Douglas A. Lyon ABSTRACT The goal of the singleton design pattern is to make sure that there is one, and only one, instance of a given class. The goal of the parametric singleton design pattern is to make sure that there is one, and only one, instance of a given class with the given parametric values. We parametric singleton design pattern combines the singleton design pattern with a parameter that enables unique creation of instances of a class. These instances are cached. When a user asks for an instance with these parameters, the cache is checked. If the instance is in the cache, the instance is returned, otherwise it is created, added to the cache and then returned. We apply our parametric singleton design pattern to the retrieval of RMI registries bound to a given port. The goal of our system is to make sure that no two RMI registries are listening to the same socket and to make use of the RMI registries after they have been created. RMI registries are used in distributed computation. Introduction The singleton design pattern is meant to ensure that on a single instance of a class exists. It is also meant to provide a global point of access to it. The intent of the parametric singleton design pattern is to ensure that a class has only one instance for a given set of parameter values. It also provides a global point of access to it. Motivation A system cannot tolerate multiple instances of some classes with identical parameters. For example, you cannot have two instances making use of the same serial port, at the same time. You cannot have two instances that are trying to listen to the same socket connection. You cannot have two instances writing to the same file structure at the same time. As the operating system is often thought of as the arbiter of consumed resources (i.e., tape drives, serial ports, etc.) we frequently leave it to an operating system implementation to resolve these contention issues. Even for similar resources (like serial ports) there are few standards for handling contention. For example, serial ports on Linux are locked using a "/var/lock" file. POSIX, on the other hand, uses ioctl mechanisms to prevent contention. A better solution is to make a class that is responsible for keeping track of the instances created from the class. The class is declared final, so that it cannot be subclassed. The class also has a private constructor, so that other classes cannot instance it. The new design pattern is called the parametric singleton design pattern and it provides a way to access and create instances with given parameters. Applicability Use the Parametric Singleton Design Pattern when: 1. There must be exactly one instance of a class with the given parameters. 2. The instances must be accessible to clients from a well-known access point. Structure Insert UML diagram here. Participants The Parametric Singleton Clients that need instances 1. The Parametric Singleton defines an instance upon request from a client, if, and only if, the instance does not already exist. 2. The Parametric Singleton returns the instance to the client. 3. The Parametric Singleton is responsible for creating unique instances from given parameters. Collaborations Clients obtain a reference to a Parametric Singleton instance only through the parametric singleton design pattern. If the instance is left in an improper state (e.g., the serial port was left open) it is NOT the role of the Parametric Singleton Design Pattern to close the IO port. Nor is it the role of the Parametric Singleton Design Pattern to open the port. That role is delegate to some other part of the system. Further, it is not the role of the Parametric Singleton Design Pattern to check out resources. That is, multiple threads can have multiple references to the same resource at the same time. MUTEX locking is delegated to some other part of the system. Consequences The Parametric Singleton Design Pattern has several benefits: 1. Controlled access to parametrically defined instances. Since the Parametric Singleton class encapsulates its instances, there is control over how and when clients access it. 2. Reduced name space. The Parametric Singleton pattern avoids global variables that store instances created from the same parameter. Implementation Here are implementation issues to consider when using the Parametric Singleton pattern: 1. Unique mapping of parameters. The Parametric Singleton pattern requires that there be a mean to isomorphically map the parameter space into the instance space and back again. 2. Ensure unique instances. The Parametric Singleton pattern makes unique instances from parameters, and it does so only once. 3. Cache instances for fast retrieval. The Parametric Singleton pattern must be able to look up instances, given some set of parameters, and do so from some data structure. That is, there must be enough space to hold references to all the instances the program will need. Also, a mechanism is needed to look up and retrieve the instances quickly enough to satisfy the clients. Sample Code public final class ParametricSingletonRmiRegistry { private static Hashtable registry = new Hashtable(100); // use singleton pattern and??????????????????????????????????????????????? // prevent instantiation of RmiRegistryUtils.?????????????????????????????? private ParametricSingletonRmiRegistry() { } // the only instance of the Registry held by the RmiRegistryUtils?????????? public static void listNames(Integer port) { if (!isInCacheAndRunning(port)) return; Registry r = (Registry) registry.get(port); System.out.println("registry on port: " + port); System.out.println("registry: " + r); System.out.println("names: "); try { print(r.list()); } catch (RemoteException e) { In.message(e); } System.out.println("------------------------"); } /**???????????????????????????????????????????????????????????????????????? * Checks whether a Registry has been started on this host????????????????? * in the specified port.?????????????????????????????????????????????????? * If not, it tries to start one.?????????????????????????????????????????? * when it fails to start a Registry, it exits the program????????????????? * with exit code 1.??????????????????????????????????????????????????????? */ public static void restart(int port) { if (isInCacheAndRunning(port)) return; try { startRegistry(port); } catch (RemoteException e) { In.message(e); } } /**???????????????????????????????????????????????????????????????????????? * @param port????????????????????????????????????????????????????????????? * @return true if registry is in cache and running???????????????????????? */ private static boolean isInCacheAndRunning(Integer port) { if (!isRegistryRunning(port.intValue())) return false; if (!isRegistryInCache(port.intValue())) return false; return true; } /**???????????????????????????????????????????????????????????????????????? * @param port????????????????????????????????????????????????????????????? * @return true if we are able to locate a local registry on port.??????????????????????????????????????????????????????????????????????????? */ private static boolean isRegistryRunning(int port) { try { Registry r = LocateRegistry.getRegistry(port); if (r != null) return true; } catch (RemoteException e) { return false; } return false; } /**???????????????????????????????????????????????????????????????????????? * @param port????????????????????????????????????????????????????????????? * @return return true if registry is in cache????????????????????????????? */ private static boolean isRegistryInCache(int port) { if (registry.get(new Integer(port)) == null) return false; return true; } /**???????????????????????????????????????????????????????????????????????? * Restart the registry, if needed.???????????????????????????????????????? * Return the only instance of the registry for consistent global?????????? * using by making use of the Singleton Design Pattern????????????????????? *????????????????????????????????????????????????????????????????????????? * @return the internally held registry instance.?????????????????????????? */ public static Registry getRegistry(Integer port) { restart(port); return (Registry) registry.get(port); } private static void startRegistry(Integer port) throws RemoteException { Registry r; try { r = LocateRegistry.createRegistry(port.intValue()); registry.put(port, r); //r = new sun.rmi.registry.RegistryImpl???????????????????????????? /// (port.intValue());?????????????????????????????????????? // registry.put(port, r);?????????????????????????????????????????? } catch (Exception e) { //e.printStackTrace();????????????????????????????????????????????? r = LocateRegistry.getRegistry(port.intValue()); registry.put(port, r); } } public static void main(String args[]) throws RemoteException { //restart(port);??????????????????????????????????????????????????????? restart(5001); restart(5002); restart(5002); Registry r = LocateRegistry.getRegistry(5002); System.out.println("registry="+r); } } I would very much like to get your feedback on this new design pattern idea. Thank you for your time. Regards, - Doug From david.garnier at trusted-logic.com Wed Mar 22 07:36:10 2006 From: david.garnier at trusted-logic.com (David Garnier) Date: Wed, 22 Mar 2006 15:36:10 +0100 Subject: [Rxtx] sole of a new design pattern In-Reply-To: References: Message-ID: <442160DA.80107@trusted-logic.com> Hello, > The Parametric Singleton Design Pattern The Singleton is the most abused design pattern ever. Good use-cases for this pattern are extremely rare and mostly confined to problems related to hardware resources, like serial ports. > Applicability > > Use the Parametric Singleton Design Pattern when: > 1. There must be exactly one instance of a class with the given > parameters. OK. As I said above, this case this actually very unusual. The Singleton pattern is mostly used when : > 2. The instances must be accessible to clients from a well-known > access point. Using the singleton pattern in this case is just convenient for the programmer. Problems arises pretty quickly, especially if you attempt to unit-test your classes. 1) If your singleton is stateful, or hold on to stateful objects, it means that two different unit tests are not actually independent. Instead of starting with a brand new environment, the result of a test may be affected by the result of a previous test. This problem also arise when with your class relies on a database. In both cases, the solution is to reset your "unique" resource (Singleton or database) at the beginning of the test, which is a pain. Also, while most projects connect to a single database, projects that allow the use of Singletons usually contain several of thems, and new ones may cropped up unnoticed. You quickly end up with test cases that only pass in a certain order, which is a royal pain. 2) You cannot mockup a singleton. Once everyone calls the SomeSingleton class statically, you can't replace your class by SomeSingletonMockup. Furthermore, even for hardware services, the Singleton pattern does not really prevent concurrent accesses. If you start the same program in two different JVMs, unless they somehow shared the state of their "Singletons" (through lock files for example), the Singleton pattern will not prevent concurrent access. Our application uses RXTX, and we routinely encounter cases where another (native) application has already locked the port. Since we cannot modify the native application to recognize lock files, OS-level control is irreplaceable. > > Consequences > The Parametric Singleton Design Pattern has several benefits: > > 1. Controlled access to parametrically defined instances. Since > the Parametric Singleton class encapsulates its instances, there is > control over how and when clients access it. Not really. Once you've returned the instance to a client, you've lost control over it. The client can to whatever it wants with it. You cannot "recall" the instance or claim it back. > 2. Reduced name space. The Parametric Singleton pattern avoids > global variables that store instances created from the same parameter. Sure, but you don't have to rely on a Singleton for that. Just create a single Factory. > I would very much like to get your feedback on this new design > pattern idea. Well, it's nothing new. Some may say that it is the point of design patterns: formalizes the designs that occur again and again. However, this design is simply a combination of the Singleton and Factory patterns. I did use it in the past, but now I've been exposed to the shortcomings of the Singleton pattern, so I limit myself to Factories. Regards, David From sean_montgomery at baseview.com Wed Mar 22 08:35:28 2006 From: sean_montgomery at baseview.com (Sean Montgomery) Date: Wed, 22 Mar 2006 10:35:28 -0500 Subject: [Rxtx] sole of a new design pattern In-Reply-To: <442160DA.80107@trusted-logic.com> References: <442160DA.80107@trusted-logic.com> Message-ID: <05769CA7-A51B-4CF0-BAA0-E02DD905F5A4@baseview.com> On Mar 22, 2006, at 9:36 AM, David Garnier wrote: > Furthermore, even for hardware services, the Singleton pattern does > not really prevent concurrent > accesses. If you start the same program in two different JVMs, > unless they somehow shared the state > of their "Singletons" (through lock files for example), the > Singleton pattern will not prevent > concurrent access. > Multiple class loaders in a single JVM can be tricky, too. Then there's synchronization, lazy initialization and serialization of singletons to contend with. Bloch's Effective Java covers these, and here's a few articles: http://www.javaworld.com/javaworld/jw-04-2003/jw-0425-designpatterns- p3.html http://java.sun.com/developer/technicalArticles/Programming/singletons/ Just FYI :-) From lyon at docjava.com Wed Mar 22 08:50:48 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Wed, 22 Mar 2006 10:50:48 -0500 Subject: [Rxtx] sole of a new design pattern In-Reply-To: <442160DA.80107@trusted-logic.com> References: <442160DA.80107@trusted-logic.com> Message-ID: Hi All, First, I would like to thank David for his prompt and thoughtful remarks. I had no idea people that feel strongly about a design patterns! Wow! Feedback (particularly critical feedback) is greatly appreciated. Starting at the end, first: >I did use it in >the past, but now I've been exposed to the shortcomings of the >Singleton pattern, so I limit myself to Factories. David, if I understood your comments correctly, you suggested that Factories can be used in leu of the Singleton Design Pattern, or even the Parametric Singleton Design Pattern. As I see in [Gof]: Factory Method: Intent "Define an interface for creating an object, but let subclasses decide which class to instantiate. Factory Method lets a class defer instantiation to subclasses." The Singleton Design Pattern is a concrete class, which is rather different, right? Also, subclasses are not permitted with Singleton, as they are final. Naturally, I could use an abstract factory as a parent for a singleton. I could even design a facade that could be implemented with the singleton....but that is not the intention of the design. Unless you want a mock-up, as discussed, below: More below: >Hello, > >> The Parametric Singleton Design Pattern > >The Singleton is the most abused design pattern ever. Good use-cases >for this pattern are extremely >rare and mostly confined to problems related to hardware resources, >like serial ports. > > >> Applicability >> >> Use the Parametric Singleton Design Pattern when: >> 1. There must be exactly one instance of a class with the given >> parameters. >OK. As I said above, this case this actually very unusual. The >Singleton pattern is mostly used when : >> 2. The instances must be accessible to clients from a well-known >> access point. > >Using the singleton pattern in this case is just convenient for the >programmer. Problems arises >pretty quickly, especially if you attempt to unit-test your classes. > >1) If your singleton is stateful, or hold on to stateful objects, it >means that two different unit >tests are not actually independent. Instead of starting with a brand >new environment, the result of >a test may be affected by the result of a previous test. This >problem also arise when with your >class relies on a database. In both cases, the solution is to reset >your "unique" resource >(Singleton or database) at the beginning of the test, which is a >pain. Also, while most projects >connect to a single database, projects that allow the use of >Singletons usually contain several of >thems, and new ones may cropped up unnoticed. You quickly end up >with test cases that only pass in a >certain order, which is a royal pain. There are basic problems with communicating finite state machines that include reachability and deadlock analysis. These are addressed with petri net analysis and are beyond the scope of the design pattern. As you quite rightly pointed out; the parametric singleton pattern (or the singleton pattern, for that matter) enable multiple threads to gain access to the same instance. The only way that I can see to block others from gaining access to the reference is the synchronize keyword. This is putting a spin-lock (or MUTEX) on the reference. The question of how to unit-test a design pattern like the parametric singleton remains open. Perhaps this is a deficiency. > >2) You cannot mockup a singleton. Once everyone calls the >SomeSingleton class statically, you can't >replace your class by SomeSingletonMockup. Acutally, I am not sure that this is true. If the Singleton implements a Facade interface, it should be possible to make the replacement. Right? > >Furthermore, even for hardware services, the Singleton pattern does >not really prevent concurrent >accesses. If you start the same program in two different JVMs, >unless they somehow shared the state >of their "Singletons" (through lock files for example), the >Singleton pattern will not prevent >concurrent access. Good Point!! You have sharp eyes! The singleton design pattern should/could take responsibility for this. In fact, you may notice that my code does have an implementation (LocateRegistry) that can work across JVM's. The LocateRegistry will even work across the Internet! LocateRegistry takes both a host name and a Port (lock files just don't do this). I did not think to implement this beyond the local machine, but, in its present form, it will work across different processes. > >Our application uses RXTX, and we routinely encounter cases where >another (native) application has >already locked the port. Since we cannot modify the native >application to recognize lock files, >OS-level control is irreplaceable. The singleton design pattern is not meant to replace OS-level control, but to centralize the Java programmers access to it. If lock files, for example, are used for serial ports, the Singleton Design Pattern should be able to work with them. > > >> >> Consequences >> The Parametric Singleton Design Pattern has several benefits: >> > > 1. Controlled access to parametrically defined instances. Since >> the Parametric Singleton class encapsulates its instances, there is >> control over how and when clients access it. > >Not really. Once you've returned the instance to a client, you've >lost control over it. The client >can to whatever it wants with it. You cannot "recall" the instance >or claim it back. Good point, this should read: > 1. Controll when parametrically defined instances are created. Since > > the Parametric Singleton class encapsulates its instances, there is > > control over how and when they are instanced. > >> 2. Reduced name space. The Parametric Singleton pattern avoids >> global variables that store instances created from the same parameter. > >Sure, but you don't have to rely on a Singleton for that. Just >create a single Factory. > > Thank you for your thoughtful and prompt response! Regards, - Doug From dmarkman at mac.com Wed Mar 22 21:21:55 2006 From: dmarkman at mac.com (Dmitry Markman) Date: Wed, 22 Mar 2006 23:21:55 -0500 Subject: [Rxtx] sole of a new design pattern In-Reply-To: <442160DA.80107@trusted-logic.com> References: <442160DA.80107@trusted-logic.com> Message-ID: I don't think I get it On Mar 22, 2006, at 9:36 AM, David Garnier wrote: > Using the singleton pattern in this case is just convenient for the > programmer. Problems arises > pretty quickly, especially if you attempt to unit-test your classes. so you're saying that something isn't so good because you can not test it in the convenient way? if that's true, I'm totally disagree change your test, debug whatever, but if software is efficient at runtime, works fine and only problem is some unit test (which is some kind of framework for testing) then dump that unit test , dump that unit framework and make something appropriate to the software you're testing so if Douglas want to use singletons, what's the problem? and what do you mean by abusing of singleton usage? of course singleton doesn't prevent concurrent access to the resource across the processes unless you're using some OS facility to prevent it, besides singleton as it was introduced is relevant only and only inside of the same process otherwise it's not singleton it's something else (let's say network singleton: so you have remote invocation facility and some factory method that return object created by that facility) I don't have any problem with using any kind of singletons. Parametric Singleton idea (if I understand it right) could be easily implemented in the following way: use a map populate map with instances of some class and key is your parameter (you can use lazy population too) if somebody ask the key check the value if it's null so resource is taken if somebody returns the resource put it back to the map public synchronized static Object getSomeResource(Object parameter); public synchronized static void returnResource(Object parameter); getSomeResource (inside of the same process) could return null in 2 cases 1. if somebody (from other thread for example) already took that resource 2. if OS API said that resource corresponded to that parameter (serial port with parameter = 1 (port #)) is locked and unavailable; I'm not sure that in case of serial ports we even need those Parametric Singletons (unless lock checking is a very expensive operation) just ask the OS about availability of that resource and if it's available give it away and then OS will lock it and therefore in next time somebody ask it just answer that resource is locked and return null for example system has 2 serial ports available so I ask getResource("tty"); or I ask getResource("Bluetooth-Modem"); and if OS is ok you can give tty or Bluetooth-Modem or both no need for any additional pattern I think back to the problem mac os x doesn't recognize locking via files, so it handles locking via some API an instance of the singleton in each process should recognize that resource is locked (by using that API) that's all we don't have to make things more complicate then they are just because there is some nice design pattern or nice unit test framework or whatever keep things simple, make them work fast, don't introduce middle layers unless you have really good reason to do so of course I could be entirely wrong, so sorry about that in advance thanks Dmitry Markman From tjarvi at qbang.org Wed Mar 22 22:31:41 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 22 Mar 2006 22:31:41 -0700 (MST) Subject: [Rxtx] sole of a new design pattern In-Reply-To: References: Message-ID: Hi Doug Interesting reading. So far I'm just reading and thinking. I have one question so far. " Clients obtain a reference to a Parametric Singleton instance only through the parametric singleton design pattern. If the instance is left in an improper state (e.g., the serial port was left open) it is NOT the role of the Parametric Singleton Design Pattern to close the IO port. Nor is it the role of the Parametric Singleton Design Pattern to open the port. That role is delegate to some other part of the system. " So when the clients obtain a reference to the singleton, can they assume the port is there? IE, would it be the singletons role to handle things like USB dongles being removed with event hints comming from the underlying OS. Hardware abstraction layer/HAL on Linux is an example of underlying OS events. I assume that role too is delegated to other parts of the system? -- Trent Jarvi tjarvi at qbang.org From lyon at docjava.com Thu Mar 23 08:10:33 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Thu, 23 Mar 2006 10:10:33 -0500 Subject: [Rxtx] Classes don't need goals, they need roles! In-Reply-To: References: Message-ID: Hi Trent, Yes, I think that the role of the Parametric Singleton Pattern is not to open or close serial ports, nor is it to perform error checking. On the other hand, if you were to combine the role of the Parametric Singleton Pattern with another role (like that of error checking) it might not be amiss. However, I generally caution programmers against adding multiple roles to classes, as this leads to monolithic designs. Thus a different class (NativeLibDetect) could have the role of determining if the native library can be loaded. Another class (SerialPortBean) can have the role of serializing the default state of the serial port, so that it can be recovered, from user preferences, at a later time. The SerialPortDetect could have the role of determining if the serial port is removed (i.e., a USB port was unplugged). My guess is that each class should have a different role in the system, in order to ease maintenance and testing...but I could be wrong about that. Thanks! - Doug >Hi Doug > >Interesting reading. So far I'm just reading and thinking. I have >one question so far. > >" > Clients obtain a reference to a Parametric Singleton instance only >through the parametric singleton design pattern. If the instance is >left in an improper state (e.g., the serial port was left open) it is >NOT the role of the Parametric Singleton Design Pattern to close the >IO port. Nor is it the role of the Parametric Singleton Design Pattern >to >open the port. That role is delegate to some other part of the system. >" > >So when the clients obtain a reference to the singleton, can they >assume the port is there? IE, would it be the singletons role to >handle things like USB dongles being removed with event hints >comming from the underlying OS. Hardware abstraction layer/HAL on >Linux is an example of underlying OS events. > >I assume that role too is delegated to other parts of the system? > >-- >Trent Jarvi >tjarvi at qbang.org >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From maximulo at yahoo.com Fri Mar 24 01:22:38 2006 From: maximulo at yahoo.com (Maximulo Majir) Date: Fri, 24 Mar 2006 00:22:38 -0800 (PST) Subject: [Rxtx] JavaPOS Message-ID: <20060324082238.66371.qmail@web38214.mail.mud.yahoo.com> Hi all! Hello Trent! From what i understand, RXTX or JavaComm APIs were not created solely for JavaPOS. In JavaPOS, we have the virtual method claim() which is separate from open(), but in our RXTX API, claiming is done every call to open(), we cant open the port if its claimed by another application. Would it be alright to suggest or ask to create a new method called claim(..)? Is there such thing as forceclaim() in RXTX? this could be the same as portownership transfer or its equivalent. ForceClaim is in JSR80. Do you have some samples using RXTX as the lower layer for the Device Service Objects in JavaPOS? I have tried it, i just want to compare. Thank you all! maxim __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060324/496adba2/attachment-0032.html From tjarvi at qbang.org Fri Mar 24 11:28:19 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 24 Mar 2006 11:28:19 -0700 (MST) Subject: [Rxtx] Re: RXTX 2.1 Solaris Problems In-Reply-To: <3691.1143210578@www045.gmx.net> References: <3691.1143210578@www045.gmx.net> Message-ID: On Fri, 24 Mar 2006, Andreas Guenther wrote: > Hi all, > > the solaris problem was not the lock file only. > > Ok, I had to create the directory /var/spool/locks myself. > /var/spool/uucp exists. > > But rxtx didn't find any port. > > I compiled the source with my own debug-informations > and I tried to isolate the problem. > > The problem is the testRead-call in SerialImp.c > > JNIEXPORT jboolean JNICALL RXTXCommDriver(testRead)( > > ... > if ( READ( fd, &c, 1 ) < 0 ) > { > if ( errno != EAGAIN ) { > report( "testRead() read failed\n" ); > ret = JNI_FALSE; > } > } > Thanks Andreas I'm packing up to move. I'll be more or less away for a couple weeks here. I'll be checking email but my workstation is going into a box soon. This isn't hard to fix as this port should be enumerated when EWOULDBLOCK is recieved. Thats error is OK for enumeration just as EAGAIN is. I've put the bug into bugzilla so we dont forget to get to it. http://bugzilla.qbang.org/show_bug.cgi?id=42 You can add yourself to the CC list if you wish to test fixes we provide or even put a patch into bugzilla yourself. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Fri Mar 24 11:51:52 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 24 Mar 2006 11:51:52 -0700 (MST) Subject: [Rxtx] JavaPOS In-Reply-To: <20060324082238.66371.qmail@web38214.mail.mud.yahoo.com> References: <20060324082238.66371.qmail@web38214.mail.mud.yahoo.com> Message-ID: On Fri, 24 Mar 2006, Maximulo Majir wrote: > Hi all! Hello Trent! > > > From what i understand, RXTX or JavaComm APIs were not > created solely for JavaPOS. In JavaPOS, we have the virtual method > claim() which is separate from open(), but in our RXTX API, claiming is > done every call to open(), we cant open the port if its claimed by > another application. Would it be alright to suggest or ask to create a > new method called claim(..)? Is there such thing as forceclaim() in > RXTX? this could be the same as portownership transfer or its > equivalent. ForceClaim is in JSR80. > Do you have some samples using RXTX as the lower layer for the Device > Service Objects in JavaPOS? I have tried it, i just want to compare. > maxim Hi Maxim JSR80 is the USB API IBM/Sun put together. The problem is they have a richer kernel/API underneath that can handle such things. With Serial Ports, there isnt anything there other than an ioctl that says don't let anyone touch this and lockfiles that are more of a 'lets be nice.' At times we may be using USB ports but it is through the termios layer with the limitations mentioned. The advantage is that not only USB will work with rxtx. Anything that has a termios layer should work (to the extent that termios layer is complete). I don't know how forceclaim() would help you. Lets say someone has a programmer working on /dev/ttyS0 and you take it. Now you both race each other to read data first. There isn't a mechanism I know of that will solve this problem in termios. The most obvious test being a native app and a Java app trying to take the port. There is the potential of requestion ownership from other Java Applications but the use for that is very rare. Did you have something more specific in mind that I'm missing? I'm not sure that claim() and forceclaim() would help you with rxtx other than maybe locking the port with claim() without opening it. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sat Mar 25 23:42:08 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 25 Mar 2006 23:42:08 -0700 (MST) Subject: [Rxtx] Serial snoop Message-ID: I was reading the Linux kernel mail-list tonight and ran past a thread that mentioned sersnoop. This looks like a handy tool for people dealing with new toys. "a simple command-line tool for linux that echoes bytes to and from any two serial ports, ptys, or network sockets, and prints all traffic to stdout, in hex and ascii." http://www.restivo.org/projects/sersnoop/ It works on Linux only at this time (debian package available). -- Trent Jarvi tjarvi at qbang.org From beat.arnet at gmail.com Sun Mar 26 07:32:35 2006 From: beat.arnet at gmail.com (Beat Arnet) Date: Sun, 26 Mar 2006 09:32:35 -0500 Subject: [Rxtx] Error 0x5 at /home/bob/foo/tar/rxtx-2.1-7/build/../src/termios.c(860): Access is, denied. Message-ID: <4426A603.80508@gmail.com> Dear all, When trying to open the serial port, I sometimes (not always) run into the following exception (when opening the serialPort): Error 0x5 at /home/bob/foo/tar/rxtx-2.1-7/build/../src/termios.c(860): Access is denied. java.lang.UnsatisfiedLinkError: native_psmisc_report_owner at gnu.io.CommPortIdentifier.native_psmisc_report_owner(Native Method) at gnu.io.CommPortIdentifier.open(CommPortIdentifier.java:354) at codeskin.tools.CLLoader.open(CLLoader.java:79) at codeskin.tools.C2000Programmer.run(C2000Programmer.java:220) at java.lang.Thread.run(Unknown Source) Is this the type of error where I should just try to open the port again, or can it be avoided? Regards, Beat From tjarvi at qbang.org Sun Mar 26 11:40:12 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 26 Mar 2006 11:40:12 -0700 (MST) Subject: [Rxtx] Error 0x5 at /home/bob/foo/tar/rxtx-2.1-7/build/../src/termios.c(860): Access is, denied. In-Reply-To: <4426A603.80508@gmail.com> References: <4426A603.80508@gmail.com> Message-ID: On Sun, 26 Mar 2006, Beat Arnet wrote: > Dear all, > > When trying to open the serial port, I sometimes (not always) run into > the following exception (when opening the serialPort): > > Error 0x5 at /home/bob/foo/tar/rxtx-2.1-7/build/../src/termios.c(860): > Access is > denied. > > java.lang.UnsatisfiedLinkError: native_psmisc_report_owner > at gnu.io.CommPortIdentifier.native_psmisc_report_owner(Native > Method) > at gnu.io.CommPortIdentifier.open(CommPortIdentifier.java:354) > at codeskin.tools.CLLoader.open(CLLoader.java:79) > at codeskin.tools.C2000Programmer.run(C2000Programmer.java:220) > at java.lang.Thread.run(Unknown Source) > > Is this the type of error where I should just try to open the port again, > or can it be avoided? > Hi Beat We did a second build of rxtx 2.1-7 to resolve that unsatisfied link error. It should work now. rxtx is trying to tell you it thinks someone else has the serial port open. You can try to open the port again but maybe you already have a copy of the program running when it happens? ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7r2.zip fixed build. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sun Mar 26 11:44:23 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 26 Mar 2006 11:44:23 -0700 (MST) Subject: [Rxtx] RXTX spec file (fwd) Message-ID: This is probably interesting for fedora/suse users. ---------- Forwarded message ---------- Date: Sun, 26 Mar 2006 16:25:45 +0200 To: taj at www.linux.org.uk Subject: RXTX spec file I send you this spec file which allows to create a RPM for Fedora 4, 5 (x86, x86_64) with Java Sun. -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: rxtx.spec Url: http://mailman.qbang.org/pipermail/rxtx/attachments/20060326/6c7b6af6/rxtx-0028.pl From tjarvi at qbang.org Sun Mar 26 23:42:59 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 26 Mar 2006 23:42:59 -0700 (MST) Subject: [Rxtx] Upcomming events. Message-ID: This Wednesday we will be announcing a new "Maintainer" for the rxtx project. The position is more like neutral leader. I wont be going away or doing less. This is just the right thing to do as it turns out the two people with CVS write access will be at the same company. We need a third and we need neutrality. The maintainer will have final say in any conflict and will try to be neutral. It will be open for discussion. Then we will do it :) I'll still do most of the footwork I do now. But. I'm falling behind. I should have gone through the mail-list and posted the next round of changes this weekend. I'm packing to move and its going so so - 13 years of toys collected. I suspect there will be a dead period on my part (a couple weeks) comming up. But if you get it on the mail-list, we will get it in if there are no objections. I may well not be reading the mail-list during this period as I look for a house and many other things. I hope everyone will help out. Thanks -- Trent Jarvi tjarvi at qbang.org From mahmoud_hadad at yahoo.com Sun Mar 26 07:31:19 2006 From: mahmoud_hadad at yahoo.com (ronan nick) Date: Sun, 26 Mar 2006 06:31:19 -0800 (PST) Subject: [Rxtx] a question about the COMM API Message-ID: <20060326143119.54919.qmail@web60014.mail.yahoo.com> hi, i was intrested in knowing how i can communicate with my internal modem using java? for example if i want to make a phone dialer application or a caller id application where should i be looking at? and as i understood the COMM API is for devices that is attached to the computer through serial ports. --------------------------------- New Yahoo! Messenger with Voice. Call regular phones from your PC and save big. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060326/ce8329f0/attachment-0030.html From dmarkman at mac.com Mon Mar 20 00:20:43 2006 From: dmarkman at mac.com (Dmitry Markman) Date: Mon, 20 Mar 2006 02:20:43 -0500 Subject: [Rxtx] Mac OS X RXTX java installer In-Reply-To: References: <07D0DE29-BA32-4CFE-B036-66BC6423D385@buechse.de> <441AE3E0.2030503@willicon.de> <12531986.1142622114996.JavaMail.dmarkman@mac.com> <441B2674.9010409@willicon.de> <13577405.1142634732776.JavaMail.dmarkman@mac.com> <441B4182.8010407@willicon.de> <92CD0D6C-5BE8-426E-A46D-99452059FF49@mac.com> <441BBB2D.8030305@willicon.de> <441C4088.5090905@willicon.de> Message-ID: <64BC1E23-FDDE-4CE6-8863-CFC881CBC224@mac.com> Hi all I put RXTX installer that will install everything (and will create / var/lock if necessary and add user to the uucp group) for mac os x from Java into the rxtx's CVS repository it could be easily modified to install files for any platform it uses Greg Guerin's AuthKit for authentication and authorization Greg released that kit under artistic license, so Trent, please take a look we, probably, can negotiate license with Greg if it's necessary Greg's AuthKit could be downloaded from http://www.amug.org/~glguerin/ sw/#authkit Michael Hall (mikehall at spacestar dot net) had a suggestion to make implementation of the jaas LoginModule based on Greg's AuthKit (his modification of the Greg's AuthKit could be found at http:// www.spacestar.net/users/mikehall/authkit.dmg) but Michael's AuthKitLoginModule does only half a job: it does authenticate but it can not run any external unix process in privileged mode (at least I wasn't able to do so) possible explanation could be found in conversation between Greg and Michael at Apple's java-dev list (look for archives) so I didn't use jaas API for rxtxinstaller I created folder MacOSX in the contrib folder comment 1. if you want to run that installer as standalone application all you need that RXTXInstaller.jar 2. if you want to use webstart you have to add Greg's libAuthKit.jnilib to the mac os x's resources in theory RXTXInstaller.jar doesn't need it, but there is a problem with loading libAuthKit.jnilib from webstart authkit uses loadLibrary method to load library and it failed (from webstart) for standalone application I extract libAuthKit.jnilib from the RXTXInstaller.jar and put it into the /Library/Java/Extensions or ~/Library/Java/Extensions folder that file will be deleted after installer quit unfortunately I didn't have time to put documentation there but it is mostly self-explanatory I took installer code from my gl4java installer that I did about 3 years ago (with small modifications) it would be very nice if Apple will release LoginModule that really will do the job (com.apple.security.auth.module package????? ) (UnixLoginModule is pretty useless) From lyon at docjava.com Mon Mar 20 06:34:39 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Mon, 20 Mar 2006 08:34:39 -0500 Subject: [Rxtx] Mac OS X RXTX java installer In-Reply-To: <64BC1E23-FDDE-4CE6-8863-CFC881CBC224@mac.com> References: <07D0DE29-BA32-4CFE-B036-66BC6423D385@buechse.de> <441AE3E0.2030503@willicon.de> <12531986.1142622114996.JavaMail.dmarkman@mac.com> <441B2674.9010409@willicon.de> <13577405.1142634732776.JavaMail.dmarkman@mac.com> <441B4182.8010407@willicon.de> <92CD0D6C-5BE8-426E-A46D-99452059FF49@mac.com> <441BBB2D.8030305@willicon.de> <441C4088.5090905@willicon.de> <64BC1E23-FDDE-4CE6-8863-CFC881CBC224@mac.com> Message-ID: Hi Dimitry, This sounds like great work. Just a couple of questions; After the check out of the CVS files, using: setenv CVSROOT :pserver:anonymous at cvs.milestonesolutions.com:/usr/local/cvsroot 53 8:28 setenv PASSWORD mousy 54 8:29 cvs login 55 8:29 cvs checkout rxtx-devel I cd'd over to: rxtx-devel/MACOSX_IDE And found: CVS/ CW/ ForPackageMaker/ PB/ Where is the installer? Thanks! - Doug From tjarvi at qbang.org Mon Mar 20 06:39:37 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 20 Mar 2006 06:39:37 -0700 (MST) Subject: [Rxtx] Mac OS X RXTX java installer In-Reply-To: References: <07D0DE29-BA32-4CFE-B036-66BC6423D385@buechse.de> <441AE3E0.2030503@willicon.de> <12531986.1142622114996.JavaMail.dmarkman@mac.com> <441B2674.9010409@willicon.de> <13577405.1142634732776.JavaMail.dmarkman@mac.com> <441B4182.8010407@willicon.de> <92CD0D6C-5BE8-426E-A46D-99452059FF49@mac.com> <441BBB2D.8030305@willicon.de> <441C4088.5090905@willicon.de> <64BC1E23-FDDE-4CE6-8863-CFC881CBC224@mac.com> Message-ID: On Mon, 20 Mar 2006, Dr. Douglas Lyon wrote: > Hi Dimitry, > This sounds like great work. Just a couple of questions; > After the check out of the CVS files, using: > setenv CVSROOT > :pserver:anonymous at cvs.milestonesolutions.com:/usr/local/cvsroot > 53 8:28 setenv PASSWORD mousy > 54 8:29 cvs login > 55 8:29 cvs checkout rxtx-devel Hi Doug You want "cvs checkout -r commapi-0-0-1 rxtx-devel" to get RXTX 2.1 The default branch is rxtx 2.0 which isn't very active right now. -- Trent Jarvi tjarvi at qbang.org From lyon at docjava.com Mon Mar 20 07:05:44 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Mon, 20 Mar 2006 09:05:44 -0500 Subject: [Rxtx] Mac OS X RXTX java installer In-Reply-To: References: <07D0DE29-BA32-4CFE-B036-66BC6423D385@buechse.de> <441AE3E0.2030503@willicon.de> <12531986.1142622114996.JavaMail.dmarkman@mac.com> <441B2674.9010409@willicon.de> <13577405.1142634732776.JavaMail.dmarkman@mac.com> <441B4182.8010407@willicon.de> <92CD0D6C-5BE8-426E-A46D-99452059FF49@mac.com> <441BBB2D.8030305@willicon.de> <441C4088.5090905@willicon.de> <64BC1E23-FDDE-4CE6-8863-CFC881CBC224@mac.com> Message-ID: Hi Trent, Thanks for the info on the CVS checkout procedure. I did that and am still not sure where the installer is. Here is what I have: cd MACOSX_IDE/ p4.docjava.com{lyon}121: ls CVS/ ForPackageMaker/ PB/ p4.docjava.com{lyon}122: find . | more . ./ForPackageMaker ./ForPackageMaker/RXTX.pkg.sit.hqx ./ForPackageMaker/Resources ./ForPackageMaker/Resources/ReadMe.rtf ./ForPackageMaker/Resources/Welcome.rtf ./ForPackageMaker/Resources/CVS ./ForPackageMaker/Resources/CVS/Entries ./ForPackageMaker/Resources/CVS/Repository ./ForPackageMaker/Resources/CVS/Tag ./ForPackageMaker/Resources/CVS/Root ./ForPackageMaker/Resources/preinstall ./ForPackageMaker/Resources/License.rtf ./ForPackageMaker/Resources/preupgrade ./ForPackageMaker/RXTX.pmsp ./ForPackageMaker/CVS ./ForPackageMaker/CVS/Entries ./ForPackageMaker/CVS/Repository ./ForPackageMaker/CVS/Entries.Log ./ForPackageMaker/CVS/Tag ./ForPackageMaker/CVS/Root ./ForPackageMaker/RXTX_Tiger.pkg.sitx.hqx ./ForPackageMaker/RXTX_Jag.pkg.sit.hqx ./ForPackageMaker/Install ./ForPackageMaker/Install/CVS ./ForPackageMaker/Install/CVS/Entries ./ForPackageMaker/Install/CVS/Repository ./ForPackageMaker/Install/CVS/Tag ./ForPackageMaker/Install/CVS/Root ./ForPackageMaker/Install/Library ./ForPackageMaker/Install/Library/CVS ./ForPackageMaker/Install/Library/CVS/Entries ./ForPackageMaker/Install/Library/CVS/Repository ./ForPackageMaker/Install/Library/CVS/Tag ./ForPackageMaker/Install/Library/CVS/Root ./ForPackageMaker/Install/Library/Java ./ForPackageMaker/Install/Library/Java/Extensions ./ForPackageMaker/Install/Library/Java/Extensions/RXTXcomm.jar ./ForPackageMaker/Install/Library/Java/Extensions/CVS ./ForPackageMaker/Install/Library/Java/Extensions/CVS/Entries ./ForPackageMaker/Install/Library/Java/Extensions/CVS/Repository ./ForPackageMaker/Install/Library/Java/Extensions/CVS/Tag ./ForPackageMaker/Install/Library/Java/Extensions/CVS/Root ./ForPackageMaker/Install/Library/Java/Extensions/librxtxSerial.jnilib ./ForPackageMaker/Install/Library/Java/CVS ./ForPackageMaker/Install/Library/Java/CVS/Entries ./ForPackageMaker/Install/Library/Java/CVS/Repository ./ForPackageMaker/Install/Library/Java/CVS/Entries.Log ./ForPackageMaker/Install/Library/Java/CVS/Tag ./ForPackageMaker/Install/Library/Java/CVS/Root ./ForPackageMaker/RXTX_Tiger.pmproj.sitx.hqx ./CVS ./CVS/Entries ./CVS/Repository ./CVS/Entries.Log ./CVS/Tag ./CVS/Root ./PB ./PB/LibSerialUniversal.xcodeproj.sitx.hqx ./PB/CVS ./PB/CVS/Entries ./PB/CVS/Repository ./PB/CVS/Entries.Log ./PB/CVS/Tag ./PB/CVS/Root ./PB/LibSerial.pbproj.sit.hqx ./PB/startpoint.c ./PB/config.h What is the procedure to run this installer? Do we need a README in: /rxtx-devel/MACOSX_IDE Here is what we have: CVS/ ForPackageMaker/ PB/ Thanks! - DL >On Mon, 20 Mar 2006, Dr. Douglas Lyon wrote: > >>Hi Dimitry, >>This sounds like great work. Just a couple of questions; >>After the check out of the CVS files, using: >>setenv CVSROOT >>:pserver:anonymous at cvs.milestonesolutions.com:/usr/local/cvsroot >> 53 8:28 setenv PASSWORD mousy >> 54 8:29 cvs login >> 55 8:29 cvs checkout rxtx-devel > >Hi Doug > >You want "cvs checkout -r commapi-0-0-1 rxtx-devel" to get RXTX 2.1 >The default branch is rxtx 2.0 which isn't very active right now. > >-- >Trent Jarvi >tjarvi at qbang.org From tjarvi at qbang.org Mon Mar 20 07:25:30 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 20 Mar 2006 07:25:30 -0700 (MST) Subject: [Rxtx] Mac OS X RXTX java installer In-Reply-To: References: <07D0DE29-BA32-4CFE-B036-66BC6423D385@buechse.de> <441AE3E0.2030503@willicon.de> <12531986.1142622114996.JavaMail.dmarkman@mac.com> <441B2674.9010409@willicon.de> <13577405.1142634732776.JavaMail.dmarkman@mac.com> <441B4182.8010407@willicon.de> <92CD0D6C-5BE8-426E-A46D-99452059FF49@mac.com> <441BBB2D.8030305@willicon.de> <441C4088.5090905@willicon.de> <64BC1E23-FDDE-4CE6-8863-CFC881CBC224@mac.com> Message-ID: On Mon, 20 Mar 2006, Dr. Douglas Lyon wrote: > Hi Trent, > Thanks for the info on the CVS checkout procedure. > I did that and am still not sure where the installer is. Hi Doug It does look like it was not cvs committed. There is no rxtx-devel/contrib/MacOSX directory in there at the moment. It was mentioned that it was put under contrib. -- Trent Jarvi tjarvi at qbang.org From dmarkman at mac.com Mon Mar 20 07:29:56 2006 From: dmarkman at mac.com (Dmitry Markman) Date: Mon, 20 Mar 2006 09:29:56 -0500 Subject: [Rxtx] Mac OS X RXTX java installer In-Reply-To: References: <07D0DE29-BA32-4CFE-B036-66BC6423D385@buechse.de> <441AE3E0.2030503@willicon.de> <12531986.1142622114996.JavaMail.dmarkman@mac.com> <441B2674.9010409@willicon.de> <13577405.1142634732776.JavaMail.dmarkman@mac.com> <441B4182.8010407@willicon.de> <92CD0D6C-5BE8-426E-A46D-99452059FF49@mac.com> <441BBB2D.8030305@willicon.de> <441C4088.5090905@willicon.de> <64BC1E23-FDDE-4CE6-8863-CFC881CBC224@mac.com> Message-ID: <6054EB4E-F7E0-4A9C-BDDA-D582D6D8826F@mac.com> you can find it in the rxtx-devel/contrib folder On Mar 20, 2006, at 9:05 AM, Dr. Douglas Lyon wrote: > Hi Trent, > Thanks for the info on the CVS checkout procedure. > I did that and am still not sure where the installer is. > Here is what I have: > cd MACOSX_IDE/ > p4.docjava.com{lyon}121: ls > CVS/ ForPackageMaker/ PB/ > p4.docjava.com{lyon}122: find . | more > . > ./ForPackageMaker > ./ForPackageMaker/RXTX.pkg.sit.hqx > ./ForPackageMaker/Resources > ./ForPackageMaker/Resources/ReadMe.rtf > ./ForPackageMaker/Resources/Welcome.rtf > ./ForPackageMaker/Resources/CVS > ./ForPackageMaker/Resources/CVS/Entries > ./ForPackageMaker/Resources/CVS/Repository > ./ForPackageMaker/Resources/CVS/Tag > ./ForPackageMaker/Resources/CVS/Root > ./ForPackageMaker/Resources/preinstall > ./ForPackageMaker/Resources/License.rtf > ./ForPackageMaker/Resources/preupgrade > ./ForPackageMaker/RXTX.pmsp > ./ForPackageMaker/CVS > ./ForPackageMaker/CVS/Entries > ./ForPackageMaker/CVS/Repository > ./ForPackageMaker/CVS/Entries.Log > ./ForPackageMaker/CVS/Tag > ./ForPackageMaker/CVS/Root > ./ForPackageMaker/RXTX_Tiger.pkg.sitx.hqx > ./ForPackageMaker/RXTX_Jag.pkg.sit.hqx > ./ForPackageMaker/Install > ./ForPackageMaker/Install/CVS > ./ForPackageMaker/Install/CVS/Entries > ./ForPackageMaker/Install/CVS/Repository > ./ForPackageMaker/Install/CVS/Tag > ./ForPackageMaker/Install/CVS/Root > ./ForPackageMaker/Install/Library > ./ForPackageMaker/Install/Library/CVS > ./ForPackageMaker/Install/Library/CVS/Entries > ./ForPackageMaker/Install/Library/CVS/Repository > ./ForPackageMaker/Install/Library/CVS/Tag > ./ForPackageMaker/Install/Library/CVS/Root > ./ForPackageMaker/Install/Library/Java > ./ForPackageMaker/Install/Library/Java/Extensions > ./ForPackageMaker/Install/Library/Java/Extensions/RXTXcomm.jar > ./ForPackageMaker/Install/Library/Java/Extensions/CVS > ./ForPackageMaker/Install/Library/Java/Extensions/CVS/Entries > ./ForPackageMaker/Install/Library/Java/Extensions/CVS/Repository > ./ForPackageMaker/Install/Library/Java/Extensions/CVS/Tag > ./ForPackageMaker/Install/Library/Java/Extensions/CVS/Root > ./ForPackageMaker/Install/Library/Java/Extensions/librxtxSerial.jnilib > ./ForPackageMaker/Install/Library/Java/CVS > ./ForPackageMaker/Install/Library/Java/CVS/Entries > ./ForPackageMaker/Install/Library/Java/CVS/Repository > ./ForPackageMaker/Install/Library/Java/CVS/Entries.Log > ./ForPackageMaker/Install/Library/Java/CVS/Tag > ./ForPackageMaker/Install/Library/Java/CVS/Root > ./ForPackageMaker/RXTX_Tiger.pmproj.sitx.hqx > ./CVS > ./CVS/Entries > ./CVS/Repository > ./CVS/Entries.Log > ./CVS/Tag > ./CVS/Root > ./PB > ./PB/LibSerialUniversal.xcodeproj.sitx.hqx > ./PB/CVS > ./PB/CVS/Entries > ./PB/CVS/Repository > ./PB/CVS/Entries.Log > ./PB/CVS/Tag > ./PB/CVS/Root > ./PB/LibSerial.pbproj.sit.hqx > ./PB/startpoint.c > ./PB/config.h > > What is the procedure to run this installer? > Do we need a README in: > /rxtx-devel/MACOSX_IDE > Here is what we have: > CVS/ ForPackageMaker/ PB/ > > > Thanks! > - DL > >> On Mon, 20 Mar 2006, Dr. Douglas Lyon wrote: >> >>> Hi Dimitry, >>> This sounds like great work. Just a couple of questions; >>> After the check out of the CVS files, using: >>> setenv CVSROOT :pserver:anonymous at cvs.milestonesolutions.com:/usr/ >>> local/cvsroot >>> 53 8:28 setenv PASSWORD mousy >>> 54 8:29 cvs login >>> 55 8:29 cvs checkout rxtx-devel >> >> Hi Doug >> >> You want "cvs checkout -r commapi-0-0-1 rxtx-devel" to get RXTX 2.1 >> The default branch is rxtx 2.0 which isn't very active right now. >> >> -- >> Trent Jarvi >> tjarvi at qbang.org > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx Dmitry Markman From mikehall at spacestar.net Mon Mar 20 05:25:25 2006 From: mikehall at spacestar.net (Michael Hall) Date: Mon, 20 Mar 2006 06:25:25 -0600 Subject: [Rxtx] Re: Mac OS X RXTX java installer In-Reply-To: <64BC1E23-FDDE-4CE6-8863-CFC881CBC224@mac.com> References: <07D0DE29-BA32-4CFE-B036-66BC6423D385@buechse.de> <441AE3E0.2030503@willicon.de> <12531986.1142622114996.JavaMail.dmarkman@mac.com> <441B2674.9010409@willicon.de> <13577405.1142634732776.JavaMail.dmarkman@mac.com> <441B4182.8010407@willicon.de> <92CD0D6C-5BE8-426E-A46D-99452059FF49@mac.com> <441BBB2D.8030305@willicon.de> <441C4088.5090905@willicon.de> <64BC1E23-FDDE-4CE6-8863-CFC881CBC224@mac.com> Message-ID: <247EB61F-5CD1-4132-89A2-FC105B6CF9A5@spacestar.net> On Mar 20, 2006, at 1:20 AM, Dmitry Markman wrote: > > Michael Hall (mikehall at spacestar dot net) had a suggestion to > make implementation of the jaas LoginModule > based on Greg's AuthKit > (his modification of the Greg's AuthKit could be found at http:// > www.spacestar.net/users/mikehall/authkit.dmg) > but Michael's AuthKitLoginModule does only half a job: > it does authenticate > but it can not run any external unix process in privileged mode (at > least I wasn't able to do so) If you got it working directly with Greg's the point is moot. But to clarify it anyhow. The login module does not allow you to do anything anything privileged on return as was explained by Greg. You need to work with a separate privileged process using the execPrivileged method of his API. I assume you did something similar although I haven't looked at how you are using it yet. I allowed instead for a action to be performed at the same time you login/authenticate,this... System.setProperty("authkit.action","/usr/bin/id"); just before this... lc.login(); To clarify, safely ignored as you are already complete. Mike Hall mikehall at spacestar dot net http://www.spacestar.net/users/mikehall http://sourceforge.net/projects/macnative -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2427 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20060320/f6e18202/smime-0033.bin From dmarkman at mac.com Mon Mar 20 07:36:47 2006 From: dmarkman at mac.com (Dmitry Markman) Date: Mon, 20 Mar 2006 09:36:47 -0500 Subject: [Rxtx] Re: Mac OS X RXTX java installer In-Reply-To: <247EB61F-5CD1-4132-89A2-FC105B6CF9A5@spacestar.net> References: <07D0DE29-BA32-4CFE-B036-66BC6423D385@buechse.de> <441AE3E0.2030503@willicon.de> <12531986.1142622114996.JavaMail.dmarkman@mac.com> <441B2674.9010409@willicon.de> <13577405.1142634732776.JavaMail.dmarkman@mac.com> <441B4182.8010407@willicon.de> <92CD0D6C-5BE8-426E-A46D-99452059FF49@mac.com> <441BBB2D.8030305@willicon.de> <441C4088.5090905@willicon.de> <64BC1E23-FDDE-4CE6-8863-CFC881CBC224@mac.com> <247EB61F-5CD1-4132-89A2-FC105B6CF9A5@spacestar.net> Message-ID: Hi, Michael all I have to do is to run some shell script I tried to use your action mechanism and it worked great so I just System.setProperty ("authkit.action","" ) and after that I even don't need to run anything like subject.doAs.... but after few thoughts I choose to use plain Greg's approach, because in that case I don't have to deal with various java's configurations files and therefore to use 2-3 -D parameters in the java command line especially it's useful for java web start (it's so fragile :-( ) thanks for the great job On Mar 20, 2006, at 7:25 AM, Michael Hall wrote: > > On Mar 20, 2006, at 1:20 AM, Dmitry Markman wrote: >> >> Michael Hall (mikehall at spacestar dot net) had a suggestion to >> make implementation of the jaas LoginModule >> based on Greg's AuthKit >> (his modification of the Greg's AuthKit could be found at http:// >> www.spacestar.net/users/mikehall/authkit.dmg) >> but Michael's AuthKitLoginModule does only half a job: >> it does authenticate >> but it can not run any external unix process in privileged mode >> (at least I wasn't able to do so) > > If you got it working directly with Greg's the point is moot. > > But to clarify it anyhow. > The login module does not allow you to do anything anything > privileged on return as was explained by Greg. You need to work > with a separate privileged process using the execPrivileged method > of his API. I assume you did something similar although I haven't > looked at how you are using it yet. > I allowed instead for a action to be performed at the same time you > login/authenticate,this... > System.setProperty("authkit.action","/usr/bin/id"); > just before this... > lc.login(); > To clarify, safely ignored as you are already complete. > > Mike Hall mikehall at spacestar dot net > http://www.spacestar.net/users/mikehall > http://sourceforge.net/projects/macnative > > > Dmitry Markman From dmarkman at mac.com Mon Mar 20 07:44:45 2006 From: dmarkman at mac.com (Dmitry Markman) Date: Mon, 20 Mar 2006 09:44:45 -0500 Subject: [Rxtx] Mac OS X RXTX java installer In-Reply-To: References: <07D0DE29-BA32-4CFE-B036-66BC6423D385@buechse.de> <441AE3E0.2030503@willicon.de> <12531986.1142622114996.JavaMail.dmarkman@mac.com> <441B2674.9010409@willicon.de> <13577405.1142634732776.JavaMail.dmarkman@mac.com> <441B4182.8010407@willicon.de> <92CD0D6C-5BE8-426E-A46D-99452059FF49@mac.com> <441BBB2D.8030305@willicon.de> <441C4088.5090905@willicon.de> <64BC1E23-FDDE-4CE6-8863-CFC881CBC224@mac.com> Message-ID: it's in the commapi-0-0-1 branch I tested it right now: cvs co -r commapi-0-0-1 rxtx-devel and I got everything On Mar 20, 2006, at 9:25 AM, Trent Jarvi wrote: > On Mon, 20 Mar 2006, Dr. Douglas Lyon wrote: > >> Hi Trent, >> Thanks for the info on the CVS checkout procedure. >> I did that and am still not sure where the installer is. > > Hi Doug > > It does look like it was not cvs committed. There is no rxtx-devel/ > contrib/MacOSX directory in there at the moment. It was mentioned > that it was put under contrib. > > -- > Trent Jarvi > tjarvi at qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx Dmitry Markman From tjarvi at qbang.org Mon Mar 20 07:52:57 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 20 Mar 2006 07:52:57 -0700 (MST) Subject: [Rxtx] Mac OS X RXTX java installer In-Reply-To: References: <07D0DE29-BA32-4CFE-B036-66BC6423D385@buechse.de> <441AE3E0.2030503@willicon.de> <12531986.1142622114996.JavaMail.dmarkman@mac.com> <441B2674.9010409@willicon.de> <13577405.1142634732776.JavaMail.dmarkman@mac.com> <441B4182.8010407@willicon.de> <92CD0D6C-5BE8-426E-A46D-99452059FF49@mac.com> <441BBB2D.8030305@willicon.de> <441C4088.5090905@willicon.de> <64BC1E23-FDDE-4CE6-8863-CFC881CBC224@mac.com> Message-ID: On Mon, 20 Mar 2006, Dmitry Markman wrote: > it's in the commapi-0-0-1 branch > > I tested it right now: > cvs co -r commapi-0-0-1 rxtx-devel > > and I got everything > A fresh checkout worked. Here is a copy of the tree (just the installer bits) ftp://ftp.qbang.org/pub/rxtx/MacOSX-installer.zip -- Trent Jarvi tjarvi at qbang.org From lyon at docjava.com Mon Mar 20 08:08:26 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Mon, 20 Mar 2006 10:08:26 -0500 Subject: [Rxtx] Mac OS X RXTX java installer In-Reply-To: References: <07D0DE29-BA32-4CFE-B036-66BC6423D385@buechse.de> <441AE3E0.2030503@willicon.de> <12531986.1142622114996.JavaMail.dmarkman@mac.com> <441B2674.9010409@willicon.de> <13577405.1142634732776.JavaMail.dmarkman@mac.com> <441B4182.8010407@willicon.de> <92CD0D6C-5BE8-426E-A46D-99452059FF49@mac.com> <441BBB2D.8030305@willicon.de> <441C4088.5090905@willicon.de> <64BC1E23-FDDE-4CE6-8863-CFC881CBC224@mac.com> Message-ID: Hi All, Is the Auth package able to work properly on non Mac OS's? It was not clear from the doc or download. Thanks! - Doug From dmarkman at mac.com Mon Mar 20 08:15:22 2006 From: dmarkman at mac.com (Dmitry Markman) Date: Mon, 20 Mar 2006 10:15:22 -0500 Subject: [Rxtx] Mac OS X RXTX java installer In-Reply-To: References: <07D0DE29-BA32-4CFE-B036-66BC6423D385@buechse.de> <441AE3E0.2030503@willicon.de> <12531986.1142622114996.JavaMail.dmarkman@mac.com> <441B2674.9010409@willicon.de> <13577405.1142634732776.JavaMail.dmarkman@mac.com> <441B4182.8010407@willicon.de> <92CD0D6C-5BE8-426E-A46D-99452059FF49@mac.com> <441BBB2D.8030305@willicon.de> <441C4088.5090905@willicon.de> <64BC1E23-FDDE-4CE6-8863-CFC881CBC224@mac.com> Message-ID: <217312D8-CCCA-4859-ABA6-32DF1CC817B9@mac.com> thanks Trent, for putting it on ftp server On Mar 20, 2006, at 9:52 AM, Trent Jarvi wrote: > A fresh checkout worked. Here is a copy of the tree (just the > installer bits) > > ftp://ftp.qbang.org/pub/rxtx/MacOSX-installer.zip > Dmitry Markman From dmarkman at mac.com Mon Mar 20 09:14:03 2006 From: dmarkman at mac.com (Dmitry Markman) Date: Mon, 20 Mar 2006 11:14:03 -0500 Subject: [Rxtx] Mac OS X RXTX java installer In-Reply-To: References: <07D0DE29-BA32-4CFE-B036-66BC6423D385@buechse.de> <441AE3E0.2030503@willicon.de> <12531986.1142622114996.JavaMail.dmarkman@mac.com> <441B2674.9010409@willicon.de> <13577405.1142634732776.JavaMail.dmarkman@mac.com> <441B4182.8010407@willicon.de> <92CD0D6C-5BE8-426E-A46D-99452059FF49@mac.com> <441BBB2D.8030305@willicon.de> <441C4088.5090905@willicon.de> <64BC1E23-FDDE-4CE6-8863-CFC881CBC224@mac.com> Message-ID: <4DEBA6F0-DA45-4E84-823E-1F1AC48BDCCC@mac.com> no it will work only on mac os x however it's harmless to run it on other platform if you want to use it for other platform you have to do the following (I'll do it for linux) 1. modify RXTXInstaller class method public static RXTXInstaller getInstance() public static RXTXInstaller getInstance() { String osName = System.getProperty("os.name").toLowerCase(); if(osName.startsWith("mac")){ return new gnu.io.installer.macosx.MACOSXRXTXInstaller(); } else if(osName.startsWith("windows")){ return new gnu.io.installer.windows.WindowsRXTXInstaller(); }else if(osName.startsWith("linux")){ return new gnu.io.installer.linux.LinuxRXTXInstaller(); } return null; } 2. create folder gnu/io/installer/linux/ 3. create class Linux386RXTXInstaller package gnu.io.installer.linux; import java.io.File; public class Linux386RXTXInstaller extends gnu.io.installer.RXTXInstaller{ public Linux386RXTXInstaller(){ createJarFolder(); createLibFolder(); addJarResource("RXTXcomm.jar","/gnu/io/installer/resources/ linux/jar/RXTXcomm.dat"); addLibResource("librxtxSerial.so","/gnu/io/installer/ resources/linux/lib/librxtxSerial.so"); } protected void createJarFolder(){ String javaHome = System.getProperty("java.home"); char separator = File.separatorChar; jarFolder = new File(javaHome+separator+"lib"+separator+"ext"); } protected void createLibFolder(){ String javaHome = System.getProperty("java.home"); char separator = File.separatorChar; libFolder = new File(javaHome+separator+"bin"); } public void runPreProcess() {} //put here some action you need public void runPostProcess() {} //put here some action you need } 4. create folder /gnu/io/installer/resources/linux/jar and put there linux's version of RXTXcomm.dat (which is renamed RXTXcomm.jar) 5. create folder /gnu/io/installer/resources/linux/lib and put there linux's version of librxtxSerial. so 6. make sure that RXTXInstaller.jar has the following items: /gnu/io/installer/resources/linux/jar/RXTXcomm.jar /gnu/io/installer/resources/linux/lib/librxtxSerial.so 7. modify file installer.pref: jar file RXTXInstaller.jar must have the following item /gnu/io/installer/installer.pref that's basically it for windows you have to do the similar things: just replace linux to windows and librxtxSerial.so to rxtxSerial.dll and create appropriate gnu.io.installer.windows.WindowsRXTXInstaller class package gnu.io.installer.windows; import java.io.File; public class WindowsRXTXInstaller extends gnu.io.installer.RXTXInstaller{ public WindowsRXTXInstaller(){ createJarFolder(); createLibFolder(); addJarResource("RXTXcomm.jar","/gnu/io/installer/resources/ windows/jar/RXTXcomm.dat"); addLibResource("librxtxSerial.so","/gnu/io/installer/ resources/windows/lib/rxtxSerial.dll"); } protected void createJarFolder(){ String javaHome = System.getProperty("java.home"); char separator = File.separatorChar; jarFolder = new File(javaHome+separator+"lib"+separator+"ext"); } protected void createLibFolder(){ String javaHome = System.getProperty("java.home"); char separator = File.separatorChar; libFolder = new File(javaHome+separator+"bin"); } public void runPreProcess() {} //put here some action you need public void runPostProcess() {} //put here some action you need } installer.pref will look like On Mar 20, 2006, at 10:08 AM, Dr. Douglas Lyon wrote: > Hi All, > Is the Auth package able to work properly on > non Mac OS's? > It was not clear from the doc or download. > > Thanks! > - Doug > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx Dmitry Markman From joachim at buechse.de Mon Mar 20 10:49:06 2006 From: joachim at buechse.de (Joachim Buechse) Date: Mon, 20 Mar 2006 18:49:06 +0100 Subject: [Rxtx] BUG: Lock file stays even if port opening fails Message-ID: This was only tested on MacOSX but looking at the code, it should be true for all systems that use lock_uucp. I am opening a port which can not be opened (dialup port of a telephone paired via bluetooth but currently not reachable). The lock file is created and stays arround, even though the port open failed. After looking a bit through the code (of 2.17), I really wonder if it wouldn't be a good idea to make the "locking" an explicit operation called from the java code. This would certainly simplify the generation of meaningfull exceptions (and java based debugging). Maybe even the handling of "preopened" ports should be in the Java part of the lib (again for java based debugging puposes). That beeing said, I have no idea if this would be possible for the 2.07 implementation. Regards, Joachim From tjarvi at qbang.org Mon Mar 20 11:24:22 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 20 Mar 2006 11:24:22 -0700 (MST) Subject: [Rxtx] BUG: Lock file stays even if port opening fails In-Reply-To: References: Message-ID: On Mon, 20 Mar 2006, Joachim Buechse wrote: > This was only tested on MacOSX but looking at the code, it should be true > for all systems that use lock_uucp. > > I am opening a port which can not be opened (dialup port of a telephone > paired via bluetooth but currently not reachable). The lock file is > created and stays arround, even though the port open failed. > > > After looking a bit through the code (of 2.17), I really wonder if it > wouldn't be a good idea to make the "locking" an explicit operation > called from the java code. This would certainly simplify the generation > of meaningfull exceptions (and java based debugging). > Maybe even the handling of "preopened" ports should be in the Java part > of the lib (again for java based debugging puposes). That beeing said, I > have no idea if this would be possible for the 2.07 implementation. > > Regards, Hi Joachim It should be possible in the 2.0-7 implementation too. The calls to RXTXPort.java would not change. We would just do more there Moving more of that logic into Java would be better as many people don't like to look at C code. There is a liblockdev on most Linux distros that can do most of the C code and would be easier to use. The problem is embeded devices will not have that library. The preopened port code has not been really tested. That was a last minute request in a product cycle. I expect it will be tested this year though. As I recall, some devices really do not like CD raising on open. The preopened ports then allow people to mess around in java without power cycling the devices or losing data. -- Trent Jarvi tjarvi at qbang.org From joachim at buechse.de Mon Mar 20 12:01:08 2006 From: joachim at buechse.de (Joachim Buechse) Date: Mon, 20 Mar 2006 20:01:08 +0100 Subject: [Rxtx] BUG: Lock file stays even if port opening fails In-Reply-To: References: Message-ID: Hi Trent, What is your general feeling about moving code to Java? The last days I have been reading quite a bit of the code and there are several things, that might not work as expected. I'll give you two examples from is_device_locked: if LOCKDIR == /var/spool/locks the directory /var/spool/lock will not be checked. LOCKDIR is not checked for lockfiles with unexpected pefixes While these things have probably never been discovered in production, they are still possibly incorrect implementations. If it was Java code, I would write some unit tests producing the errors that could later be corrected. PS: One could imagine to actually implement the whole lockfile handling in Java using some native routines to get the values required (pid, st_dev, st_rdev, ...). On 20.03.2006, at 19:24, Trent Jarvi wrote: > On Mon, 20 Mar 2006, Joachim Buechse wrote: > >> This was only tested on MacOSX but looking at the code, it should >> be true for all systems that use lock_uucp. >> >> I am opening a port which can not be opened (dialup port of a >> telephone paired via bluetooth but currently not reachable). The >> lock file is created and stays arround, even though the port open >> failed. >> >> >> After looking a bit through the code (of 2.17), I really wonder if >> it wouldn't be a good idea to make the "locking" an explicit >> operation called from the java code. This would certainly simplify >> the generation of meaningfull exceptions (and java based debugging). >> Maybe even the handling of "preopened" ports should be in the Java >> part of the lib (again for java based debugging puposes). That >> beeing said, I have no idea if this would be possible for the 2.07 >> implementation. >> >> Regards, > > Hi Joachim > > It should be possible in the 2.0-7 implementation too. The calls > to RXTXPort.java would not change. We would just do more there > Moving more of that logic into Java would be better as many people > don't like to look at C code. There is a liblockdev on most Linux > distros that can do most of the C code and would be easier to use. > The problem is embeded devices will not have that library. > > The preopened port code has not been really tested. That was a > last minute request in a product cycle. I expect it will be tested > this year though. As I recall, some devices really do not like CD > raising on open. The preopened ports then allow people to mess > around in java without power cycling the devices or losing data. > > -- > Trent Jarvi > tjarvi at qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Mon Mar 20 12:21:02 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 20 Mar 2006 12:21:02 -0700 (MST) Subject: [Rxtx] BUG: Lock file stays even if port opening fails In-Reply-To: References: Message-ID: On Mon, 20 Mar 2006, Joachim Buechse wrote: > Hi Trent, > > What is your general feeling about moving code to Java? The last days I > have been reading quite a bit of the code and there are several things, > that might not work as expected. > > I'll give you two examples from is_device_locked: > > if LOCKDIR == /var/spool/locks the directory /var/spool/lock will not be > checked. > LOCKDIR is not checked for lockfiles with unexpected pefixes > > While these things have probably never been discovered in production, > they are still possibly incorrect implementations. If it was Java code, I > would write some unit tests producing the errors that could later be > corrected. > > PS: One could imagine to actually implement the whole lockfile handling > in Java using some native routines to get the values required (pid, > st_dev, st_rdev, ...). Hi Joachim I like the idea of moving more of the code into java but there are some things to consider. If you break this into multiple JNI calls, the performance will drop considerably during enumeration of ports. We are looking for 256 ports per dev type vs (16? in Sun's 2.0 and fewer types). Its hard to make assumptions. I've seen virtual ports start at /dev/foo100 for instance. It works out to over 7500 ports on Linux if you enable them all. We already trim that back by default. See Linux-all-ports in RXTXCommDriver.java. There are also native libraries that rxtx can link to. If you move too much into Java, linking to 'standard' libraries with distros will break. "configure --enable-liblock=yes" will not be doable. This is probably a favorable way with RedHat, Debian, Suse and others. Thats the right thing to do if there will be rpms, dpkg, .. For those reasons, I think it still make sense to keep it to a minimal ~3 calls to JNI code that we can use for speed and versatility. lock() isLocked(), unlock() perhaps. When I say speed, its more about avoiding crossing the JNI layer multiple times than java vs C performance. With versatility I think liblock is the right way for most but not all (embeded) linux distros. -- Trent Jarvi tjarvi at qbang.org From joachim at buechse.de Mon Mar 20 12:42:04 2006 From: joachim at buechse.de (Joachim Buechse) Date: Mon, 20 Mar 2006 20:42:04 +0100 Subject: [Rxtx] BUG: Lock file stays even if port opening fails In-Reply-To: References: Message-ID: <82C19FE7-DDCB-45B6-B2C9-7606B66F0124@buechse.de> Ok, what about providing a default implementation in Java? The RXTXCommDriver would call a (native) function useNativeLocking and if it returns true, call the native functions for lock() isLocked (), unlock(), else is would use the Java based default implementation. This could possibly be overriden by a property (again for debugging). Joachim On 20.03.2006, at 20:21, Trent Jarvi wrote: > On Mon, 20 Mar 2006, Joachim Buechse wrote: > >> Hi Trent, >> >> What is your general feeling about moving code to Java? The last >> days I have been reading quite a bit of the code and there are >> several things, that might not work as expected. >> >> I'll give you two examples from is_device_locked: >> >> if LOCKDIR == /var/spool/locks the directory /var/spool/lock will >> not be checked. >> LOCKDIR is not checked for lockfiles with unexpected pefixes >> >> While these things have probably never been discovered in >> production, they are still possibly incorrect implementations. If >> it was Java code, I would write some unit tests producing the >> errors that could later be corrected. >> >> PS: One could imagine to actually implement the whole lockfile >> handling in Java using some native routines to get the values >> required (pid, st_dev, st_rdev, ...). > > Hi Joachim > > I like the idea of moving more of the code into java but there are > some things to consider. > > If you break this into multiple JNI calls, the performance will > drop considerably during enumeration of ports. We are looking for > 256 ports per dev type vs (16? in Sun's 2.0 and fewer types). Its > hard to make assumptions. I've seen virtual ports start at /dev/ > foo100 for instance. > > It works out to over 7500 ports on Linux if you enable them all. > We already trim that back by default. See Linux-all-ports in > RXTXCommDriver.java. > > There are also native libraries that rxtx can link to. If you move > too much into Java, linking to 'standard' libraries with distros > will break. "configure --enable-liblock=yes" will not be doable. > This is probably a favorable way with RedHat, Debian, Suse and > others. Thats the right thing to do if there will be rpms, dpkg, .. > > For those reasons, I think it still make sense to keep it to a > minimal ~3 calls to JNI code that we can use for speed and > versatility. lock() isLocked(), unlock() perhaps. When I say > speed, its more about avoiding crossing the JNI layer multiple > times than java vs C performance. With versatility I think liblock > is the right way for most but not all (embeded) linux distros. > > -- > Trent Jarvi > tjarvi at qbang.org > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Mon Mar 20 12:44:47 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 20 Mar 2006 12:44:47 -0700 (MST) Subject: [Rxtx] BUG: Lock file stays even if port opening fails In-Reply-To: <82C19FE7-DDCB-45B6-B2C9-7606B66F0124@buechse.de> References: <82C19FE7-DDCB-45B6-B2C9-7606B66F0124@buechse.de> Message-ID: On Mon, 20 Mar 2006, Joachim Buechse wrote: > Ok, what about providing a default implementation in Java? > > The RXTXCommDriver would call a (native) function useNativeLocking and if > it returns true, call the native functions for lock() isLocked(), > unlock(), else is would use the Java based default implementation. This > could possibly be overriden by a property (again for debugging). > Hi Joachim That would be OK with me. -- Trent Jarvi tjarvi at qbang.org From dmarkman at mac.com Mon Mar 20 22:27:45 2006 From: dmarkman at mac.com (Dmitry Markman) Date: Tue, 21 Mar 2006 00:27:45 -0500 Subject: [Rxtx] binaries request Message-ID: <42702213-C222-4937-A585-7CFB17E47608@mac.com> Hi can somebody send me latest linux and windows binaries, please? or where I can find them (I didn't find them in the latest tareball) I gave up with my cygwin: something wrong I have no idea what java doesn't understand /cygwin/c syntax after I changed makefile it did java part but after that gcc 3.4.4 started to complain I set buffer length to 999 lines but I didn't get beginning of the story something wrong with my 1.4.2_09/include/jni.h gcc doesn't like it anyway I gave up thanks in advance Dmitry Markman -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060320/f8cbc57c/attachment-0033.html From tjarvi at qbang.org Mon Mar 20 22:36:48 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 20 Mar 2006 22:36:48 -0700 (MST) Subject: [Rxtx] binaries request In-Reply-To: <42702213-C222-4937-A585-7CFB17E47608@mac.com> References: <42702213-C222-4937-A585-7CFB17E47608@mac.com> Message-ID: On Tue, 21 Mar 2006, Dmitry Markman wrote: > Hi > can somebody send me latest linux and windows binaries, please? > > or where I can find them (I didn't find them in the latest tareball) > > I gave up with my cygwin: something wrong I have no idea what > java doesn't understand /cygwin/c syntax > after I changed makefile it did java part > but after that gcc 3.4.4 started to complain > I set buffer length to 999 lines but I didn't get beginning of the story > something wrong with my 1.4.2_09/include/jni.h gcc doesn't like it > anyway I gave up > > thanks in advance > Hi Dmitry The bins are here: ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7-bins-r2.zip Here are the files in the zip you want. Jar: rxtx-2.1-7-bins-r2/RXTXcomm.jar Windows: rxtx-2.1-7-bins-r2/Windows/i368-mingw32/rxtxSerial.dll Linux (x86) rxtx-2.1-7-bins-r2/Linux/i686-unknown-linux-gnu/librxtxSerial.so There are others in there including Parallel port support but those are the main ones for testing. -- Trent Jarvi tjarvi at qbang.org From dmarkman at mac.com Mon Mar 20 23:05:59 2006 From: dmarkman at mac.com (Dmitry Markman) Date: Tue, 21 Mar 2006 01:05:59 -0500 Subject: [Rxtx] binaries request In-Reply-To: References: <42702213-C222-4937-A585-7CFB17E47608@mac.com> Message-ID: thank you very much but windows's readme says: rxtxSerial.dll had to be recomopiled to link in missing native methods. should I ignore it? or what? thanks again also I understand that I should use mingw not cygwin I'll try to install mingw On Mar 21, 2006, at 12:36 AM, Trent Jarvi wrote: > On Tue, 21 Mar 2006, Dmitry Markman wrote: > >> Hi >> can somebody send me latest linux and windows binaries, please? >> >> or where I can find them (I didn't find them in the latest tareball) >> >> I gave up with my cygwin: something wrong I have no idea what >> java doesn't understand /cygwin/c syntax >> after I changed makefile it did java part >> but after that gcc 3.4.4 started to complain >> I set buffer length to 999 lines but I didn't get beginning of the >> story >> something wrong with my 1.4.2_09/include/jni.h gcc doesn't like it >> anyway I gave up >> >> thanks in advance >> > > Hi Dmitry > > The bins are here: > > ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7-bins-r2.zip > > Here are the files in the zip you want. > > Jar: > > rxtx-2.1-7-bins-r2/RXTXcomm.jar > > Windows: > > rxtx-2.1-7-bins-r2/Windows/i368-mingw32/rxtxSerial.dll > > Linux (x86) > > rxtx-2.1-7-bins-r2/Linux/i686-unknown-linux-gnu/librxtxSerial.so > > There are others in there including Parallel port support but those > are the main ones for testing. > > -- > Trent Jarvi > tjarvi at qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx Dmitry Markman From tjarvi at qbang.org Mon Mar 20 23:20:33 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 20 Mar 2006 23:20:33 -0700 (MST) Subject: [Rxtx] binaries request In-Reply-To: References: <42702213-C222-4937-A585-7CFB17E47608@mac.com> Message-ID: On Tue, 21 Mar 2006, Dmitry Markman wrote: > thank you very much > > but windows's readme says: > rxtxSerial.dll had to be recomopiled to link in missing native methods. > > should I ignore it? or what? > Hi Dmitry That dll should be OK. r2 is the recompile linked to the missing native method. The readme explains why it was recompiled; fuser.o was not linked into the dll in the first release. -- Trent Jarvi tjarvi at qbang.org From ariantristan at yahoo.com Mon Mar 20 23:55:24 2006 From: ariantristan at yahoo.com (Lambok Sianturi) Date: Mon, 20 Mar 2006 22:55:24 -0800 (PST) Subject: [Rxtx] jvm issue Message-ID: <20060321065524.94779.qmail@web50701.mail.yahoo.com> Hi All, This is my first time to join RxTx mailing list. I thank you all for allowing others to sign in in requests help. I use the latest RxTx lib in Fedora 3 with java version 1.4.2_09 b05. And I got this error: # # An unexpected error has been detected by HotSpot Virtual Machine: # # SIGSEGV (0xb) at pc=0x00bf27f3, pid=2633, tid=3086112448 # # Java VM: Java HotSpot(TM) Client VM (1.4.2_09-b05 mixed mode) # Problematic frame: # C [ld-linux.so.2+0xa7f3] # # An error report file with more information is saved as hs_err_pid2633.log # # If you would like to submit a bug report, please visit: # http://java.sun.com/webapps/bugreport/crash.jsp # ./run.sh: line 3: 2633 Aborted /usr/local/java/bin/java -Djava.library.path=/usr/local/java/jre/lib/ -Djsmsengine.debug=true -classpath jsmsengine.jar:smsgateway.jar:classes12.jar:RXTXcomm.jar:. com.api.sms.SMSServer What is the jvm depedency for the latest library? Can I use 1.4.2_09 b05? Thanks in advance. Arian --------------------------------- Yahoo! Mail Use Photomail to share photos without annoying attachments. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060320/83d58dd7/attachment-0033.html From f.frumento at ngi.it Tue Mar 21 00:21:47 2006 From: f.frumento at ngi.it (Fabio Frumento) Date: Tue, 21 Mar 2006 08:21:47 +0100 Subject: [Rxtx] Javadoc on the go Message-ID: <441FA98B.9050701@ngi.it> Hi Trent, sorry for the big delay but my job is running wild, i was out for some time but now i'm back and ready to continue the javadoc for Rxtx. Did you used the last javadoc patch i sent you ? let me know if i have to send it to you again or not. regards Fabio From lyon at docjava.com Tue Mar 21 00:51:18 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Tue, 21 Mar 2006 02:51:18 -0500 Subject: [Rxtx] lock files Message-ID: Hi All, You know, if the use of lock files were under Java control (rather than a build-time decision), it might enable a more unified binary distro. It might also facilitate quick prototyping of non-lock file approaches to resolving serial port contention issues (i.e., mac-like approaches vs. linux approaches, etc.). I realize that this is a radical overhaul of the lock file policy issue. Also, it may harm performance. On the other hand, our benchmarks on JNI overhead for modern processors indicate performance impact should be minimal. Perhaps it is more of an issue with the toybox systems. Suppose there were a class with a reasonable default...someone might write: SerialPortLockPolicy.setPolicy(SerialPortLockPolicy.UNIX_LOCK_FILE); SerialPortLockPolicy.setPolicy(SerialPortLockPolicy.NO_LOCK_CHECKING); SerialPortLockPolicy.setPolicy(SerialPortLockPolicy.MAC_STYLE); Thus, we could have a run-time reconfiguration of the serial port lock policy. A special NO_LOCK version of the binary would no longer be required. Any thoughts on this? Thanks! - Doug From joachim at buechse.de Tue Mar 21 03:09:09 2006 From: joachim at buechse.de (Joachim Buechse) Date: Tue, 21 Mar 2006 11:09:09 +0100 Subject: [Rxtx] lock files In-Reply-To: References: Message-ID: <8E12916A-1B9A-4FF2-B684-E2D1C794221B@buechse.de> This is pretty much what I thought about when I suggested, that the default behaviour could be overwritten with a property. I am very much in favor of this approach. In particular this allows much easier debugging for PC based java developers. I think big parts of the Java (and maybe some parts of the C code) could use a bit of a structural workover (unit tests, javadoc, synchronization, etc). Maybe there should be a CVS branch for this experimental version. I'd be happy to contribute a first workover for some of the Java code. Designing for testability and implementing a good bunch of unit tests has been a strategy that worked quite well in the Java projects I lead. And it ultimately allows more liberal change permission. Regards, Joachim On 21.03.2006, at 08:51, Dr. Douglas Lyon wrote: > Hi All, > You know, if the use of lock files were > under Java control (rather than a build-time decision), > it might enable a more unified binary distro. It might also > facilitate quick prototyping of non-lock file approaches > to resolving serial port contention issues (i.e., mac-like > approaches vs. linux approaches, etc.). > > I realize that this is a radical overhaul of the lock file policy > issue. Also, it may harm performance. On the other hand, > our benchmarks on JNI overhead for modern processors indicate > performance impact should be minimal. Perhaps it is more of > an issue with the toybox systems. > > Suppose there were a class with a reasonable default...someone > might write: > SerialPortLockPolicy.setPolicy(SerialPortLockPolicy.UNIX_LOCK_FILE); > SerialPortLockPolicy.setPolicy(SerialPortLockPolicy.NO_LOCK_CHECKING); > SerialPortLockPolicy.setPolicy(SerialPortLockPolicy.MAC_STYLE); > > Thus, we could have a run-time reconfiguration of the serial port lock > policy. A special NO_LOCK version of the binary would no longer > be required. > > Any thoughts on this? > > Thanks! > - Doug > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From joachim at buechse.de Tue Mar 21 06:23:08 2006 From: joachim at buechse.de (Joachim Buechse) Date: Tue, 21 Mar 2006 14:23:08 +0100 Subject: [Rxtx] PATCH: use of ioctl(fd, TIOCEXCL) instead of lockfiles Message-ID: <923AE774-EEA2-4911-92D8-32BB27802C8B@buechse.de> Here is the patch for the ioctl(fd, TIOCEXCL). I have verified this only for OSX 10.4.5, hence it is only defined for APPLE. However, it should work at least for Solaris as well. If a process has requested TIOEXCL further open calls by other user processes will fail. The patch also disables uucp style locking for APPLE. Obviously this is discussable. I think it is the way to go, as it eliminates creating the lock directory which doesnt exist on the standard installation and it eliminates messing with the system group definitions (adding users to group uucp). Regarding the possibility of root processes opening a device which is locked - I consider this a feature not a potential problem. It is highly unlikely, that somebody is crazy enough to run a JavaVM as root (unless he has no other means of getting a restricted IP port opened, ie doesnt understand ipfw). Anyway, even if the process runs as root, it fails when calling ioctl(fd, TIOCEXCL). It could however still open the port to listen for RING events. I.e. a fax server which needs to see incoming calls but otherwise doesnt want to block the port. So the only case where the proposed mechanism fails is, if an incorrectly implemented process running as root conflicts with a user process. I think this can be accepted. Regards, Joachim PS: If this patch is generally accepted, the installer and Mac doku should obviously be changed as well. Index: SerialImp.c =================================================================== RCS file: /usr/local/cvsroot/rxtx-devel/src/SerialImp.c,v retrieving revision 1.46.2.187 diff -u -r1.46.2.187 SerialImp.c --- SerialImp.c 29 Jan 2006 22:19:04 -0000 1.46.2.187 +++ SerialImp.c 21 Mar 2006 12:59:16 -0000 @@ -656,6 +656,25 @@ fd=OPEN (filename, O_RDWR | O_NOCTTY | O_NONBLOCK ); } while (fd < 0 && errno==EINTR); +#ifdef OPEN_EXCL + // Note that open() follows POSIX semantics: multiple open() calls to + // the same file will succeed unless the TIOCEXCL ioctl is issued. + // This will prevent additional opens except by root-owned processes. + // See tty(4) ("man 4 tty") and ioctl(2) ("man 2 ioctl") for details. + + if (fd >= 0 && (ioctl(fd, TIOCEXCL) == -1)) + { + sprintf( message, "open: exclusive access denied for % s\n", + filename ); + report( message ); + report_error( message ); + + close(fd); + goto fail; + } +#endif /* OPEN_EXCL */ + + if( configure_port( fd ) ) goto fail; (*env)->ReleaseStringUTFChars( env, jstr, filename ); sprintf( message, "open: fd returned is %i\n", fd ); Index: SerialImp.h =================================================================== RCS file: /usr/local/cvsroot/rxtx-devel/src/SerialImp.h,v retrieving revision 1.11.2.49 diff -u -r1.11.2.49 SerialImp.h --- SerialImp.h 5 Jul 2005 17:47:21 -0000 1.11.2.49 +++ SerialImp.h 21 Mar 2006 12:59:17 -0000 @@ -135,7 +135,8 @@ /*# define LOCKDIR "/var/spool/uucp"*/ # define LOCKDIR "/var/lock" # define LOCKFILEPREFIX "LK." -# define UUCP +/*# define UUCP*/ +# define OPEN_EXCL #endif /* __APPLE__ */ #if defined(__NetBSD__) # define DEVICEDIR "/dev/" From tjarvi at qbang.org Tue Mar 21 10:26:08 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 21 Mar 2006 10:26:08 -0700 (MST) Subject: [Rxtx] Javadoc on the go In-Reply-To: <441FA98B.9050701@ngi.it> References: <441FA98B.9050701@ngi.it> Message-ID: On Tue, 21 Mar 2006, Fabio Frumento wrote: > Hi Trent, > > sorry for the big delay but my job is running wild, i was out for some > time but now i'm back and ready to continue the javadoc for Rxtx. > > Did you used the last javadoc patch i sent you ? let me know if i have to > send it to you again or not. > > regards > > Fabio Hi Fabio The patch is in the rxtx mail-list archives. It will be going in soon. I did not see a time critical portion. I'll probably be going through the list since the last batch of patches this weekend and putting them into CVS. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Tue Mar 21 10:57:18 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 21 Mar 2006 10:57:18 -0700 (MST) Subject: [Rxtx] jvm issue In-Reply-To: <20060321065524.94779.qmail@web50701.mail.yahoo.com> References: <20060321065524.94779.qmail@web50701.mail.yahoo.com> Message-ID: On Mon, 20 Mar 2006, Lambok Sianturi wrote: > Hi All, > This is my first time to join RxTx mailing list. I thank you all for allowing others to sign in in requests help. > I use the latest RxTx lib in Fedora 3 with java version 1.4.2_09 b05. And I got this error: > > # > # An unexpected error has been detected by HotSpot Virtual Machine: > # > # SIGSEGV (0xb) at pc=0x00bf27f3, pid=2633, tid=3086112448 > # > # Java VM: Java HotSpot(TM) Client VM (1.4.2_09-b05 mixed mode) > # Problematic frame: > # C [ld-linux.so.2+0xa7f3] A native library loading error? What happens if you recompile rxtx on your system and install that? This sounds like an ABI problem? rxtx 2.1-7 was compiled with a gcc 2.96 toolchain as I recall. The hope is newer system will be backwards compatible. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Tue Mar 21 11:05:29 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 21 Mar 2006 11:05:29 -0700 (MST) Subject: [Rxtx] PATCH: use of ioctl(fd, TIOCEXCL) instead of lockfiles In-Reply-To: <923AE774-EEA2-4911-92D8-32BB27802C8B@buechse.de> References: <923AE774-EEA2-4911-92D8-32BB27802C8B@buechse.de> Message-ID: On Tue, 21 Mar 2006, Joachim Buechse wrote: > Here is the patch for the ioctl(fd, TIOCEXCL). I have verified this only > for OSX 10.4.5, hence it is only defined for APPLE. However, it should > work at least for Solaris as well. > > If a process has requested TIOEXCL further open calls by other user > processes will fail. > > The patch also disables uucp style locking for APPLE. Obviously this is > discussable. I think it is the way to go, as it eliminates creating the > lock directory which doesnt exist on the standard installation and it > eliminates messing with the system group definitions (adding users to > group uucp). > > Regarding the possibility of root processes opening a device which is > locked - I consider this a feature not a potential problem. It is highly > unlikely, that somebody is crazy enough to run a JavaVM as root (unless > he has no other means of getting a restricted IP port opened, ie doesnt > understand ipfw). Anyway, even if the process runs as root, it fails when > calling ioctl(fd, TIOCEXCL). It could however still open the port to > listen for RING events. I.e. a fax server which needs to see incoming > calls but otherwise doesnt want to block the port. So the only case where > the proposed mechanism fails is, if an incorrectly implemented process > running as root conflicts with a user process. I think this can be > accepted. > > Regards, > Joachim > > PS: If this patch is generally accepted, the installer and Mac doku > should obviously be changed as well. > > > Index: SerialImp.c > =================================================================== > RCS file: /usr/local/cvsroot/rxtx-devel/src/SerialImp.c,v > retrieving revision 1.46.2.187 > diff -u -r1.46.2.187 SerialImp.c > --- SerialImp.c 29 Jan 2006 22:19:04 -0000 1.46.2.187 > +++ SerialImp.c 21 Mar 2006 12:59:16 -0000 > @@ -656,6 +656,25 @@ > fd=OPEN (filename, O_RDWR | O_NOCTTY | O_NONBLOCK ); > } while (fd < 0 && errno==EINTR); > > +#ifdef OPEN_EXCL > + // Note that open() follows POSIX semantics: multiple open() > calls to > + // the same file will succeed unless the TIOCEXCL ioctl is > issued. > + // This will prevent additional opens except by root-owned > processes. > + // See tty(4) ("man 4 tty") and ioctl(2) ("man 2 ioctl") for > details. > + > + if (fd >= 0 && (ioctl(fd, TIOCEXCL) == -1)) > + { > + sprintf( message, "open: exclusive access denied for % > s\n", > + filename ); > + report( message ); > + report_error( message ); > + > + close(fd); > + goto fail; > + } > +#endif /* OPEN_EXCL */ > + > + > if( configure_port( fd ) ) goto fail; > (*env)->ReleaseStringUTFChars( env, jstr, filename ); > sprintf( message, "open: fd returned is %i\n", fd ); > Index: SerialImp.h > =================================================================== > RCS file: /usr/local/cvsroot/rxtx-devel/src/SerialImp.h,v > retrieving revision 1.11.2.49 > diff -u -r1.11.2.49 SerialImp.h > --- SerialImp.h 5 Jul 2005 17:47:21 -0000 1.11.2.49 > +++ SerialImp.h 21 Mar 2006 12:59:17 -0000 > @@ -135,7 +135,8 @@ > /*# define LOCKDIR "/var/spool/uucp"*/ > # define LOCKDIR "/var/lock" > # define LOCKFILEPREFIX "LK." > -# define UUCP > +/*# define UUCP*/ > +# define OPEN_EXCL > #endif /* __APPLE__ */ > #if defined(__NetBSD__) > # define DEVICEDIR "/dev/" > This looks like a good start. What do you think Dmitry? Perhaps all systems with TIOCEXCL defined should use that though. Even if they use lockfiles. It wont hurt anything. That would catch people hacking their own serial apps without checking lockfiles. Its a good idea to avoid C++ style comments in the C portions. Some older systems don't deal with them well. If it's just for Mac OS X, it isn't a big deal. I think it was the Irix compiler that was problematic? -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Tue Mar 21 11:22:05 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 21 Mar 2006 11:22:05 -0700 (MST) Subject: [Rxtx] lock files In-Reply-To: <8E12916A-1B9A-4FF2-B684-E2D1C794221B@buechse.de> References: <8E12916A-1B9A-4FF2-B684-E2D1C794221B@buechse.de> Message-ID: We can try it. Maybe the JNI is much improved. The nice thing about linking into liblock is distros then worry about lockfiles on their systems. This way, we have to deal with any changes that may show up. On Tue, 21 Mar 2006, Joachim Buechse wrote: > This is pretty much what I thought about when I suggested, that the > default behaviour could be overwritten with a property. I am very much in > favor of this approach. In particular this allows much easier debugging > for PC based java developers. > > I think big parts of the Java (and maybe some parts of the C code) could > use a bit of a structural workover (unit tests, javadoc, synchronization, > etc). Maybe there should be a CVS branch for this experimental version. > I'd be happy to contribute a first workover for some of the Java code. > Designing for testability and implementing a good bunch of unit tests has > been a strategy that worked quite well in the Java projects I lead. And > it ultimately allows more liberal change permission. > > Regards, > Joachim > > > On 21.03.2006, at 08:51, Dr. Douglas Lyon wrote: > >> Hi All, >> You know, if the use of lock files were >> under Java control (rather than a build-time decision), >> it might enable a more unified binary distro. It might also >> facilitate quick prototyping of non-lock file approaches >> to resolving serial port contention issues (i.e., mac-like >> approaches vs. linux approaches, etc.). >> >> I realize that this is a radical overhaul of the lock file policy >> issue. Also, it may harm performance. On the other hand, >> our benchmarks on JNI overhead for modern processors indicate >> performance impact should be minimal. Perhaps it is more of >> an issue with the toybox systems. >> >> Suppose there were a class with a reasonable default...someone >> might write: >> SerialPortLockPolicy.setPolicy(SerialPortLockPolicy.UNIX_LOCK_FILE); >> SerialPortLockPolicy.setPolicy(SerialPortLockPolicy.NO_LOCK_CHECKING); >> SerialPortLockPolicy.setPolicy(SerialPortLockPolicy.MAC_STYLE); >> >> Thus, we could have a run-time reconfiguration of the serial port lock >> policy. A special NO_LOCK version of the binary would no longer >> be required. >> >> Any thoughts on this? >> >> Thanks! >> - Doug >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From dmarkman at mac.com Tue Mar 21 16:05:17 2006 From: dmarkman at mac.com (Dmitry Markman) Date: Tue, 21 Mar 2006 18:05:17 -0500 Subject: [Rxtx] PATCH: use of ioctl(fd, TIOCEXCL) instead of lockfiles In-Reply-To: References: <923AE774-EEA2-4911-92D8-32BB27802C8B@buechse.de> Message-ID: <512AC70C-BB86-48F2-A83C-023F35C23BAB@mac.com> I think it's cool, but I'd like to have that property implementation when user can choose between locking mechanism about comments: it's easy to change comments to the C style or we can use extensions of the file to cpp so c++ compiler will be used On Mar 21, 2006, at 1:05 PM, Trent Jarvi wrote: > This looks like a good start. What do you think Dmitry? Perhaps > all systems with TIOCEXCL defined should use that though. Even if > they use lockfiles. It wont hurt anything. That would catch > people hacking their own serial apps without checking lockfiles. > > Its a good idea to avoid C++ style comments in the C portions. > Some older systems don't deal with them well. If it's just for Mac > OS X, it isn't a big deal. I think it was the Irix compiler that > was problematic? Dmitry Markman From dmarkman at mac.com Tue Mar 21 16:13:00 2006 From: dmarkman at mac.com (Dmitry Markman) Date: Tue, 21 Mar 2006 18:13:00 -0500 Subject: [Rxtx] PATCH: use of ioctl(fd, TIOCEXCL) instead of lockfiles In-Reply-To: References: <923AE774-EEA2-4911-92D8-32BB27802C8B@buechse.de> Message-ID: I'd like to add that creating locking folder isn't a big deal we never had a problem related to the lock folders, because we always used installer on mac os x from other hand I'm not very much familiar with iotcl locking approach and I'm not sure it's more efficient Joachim wrote "I think it is the way to go, as it eliminates creating the lock directory which doesnt exist on the standard installation and it eliminates messing with the system group definitions (adding users to group uucp)." but I really didn't have any problem with that 1. doesn't exist on the standard installation there are many-many things that don't exist in the standard installation so I don't think that argument is strong enough 2. messing with the system group definitions I don't think we're messing with the group definition mac os x provides very clear way to set up group's members and together with Greg Guerin AuthKit there is no problem to set those definitions so I don't think that argument is strong either but from other hand using iotcl is more promising and is more elegant On Mar 21, 2006, at 1:05 PM, Trent Jarvi wrote: > > This looks like a good start. What do you think Dmitry? Perhaps > all systems with TIOCEXCL defined should use that though. Even if > they use lockfiles. It wont hurt anything. That would catch > people hacking their own serial apps without checking lockfiles. Dmitry Markman From joachim at buechse.de Wed Mar 22 04:46:45 2006 From: joachim at buechse.de (Joachim Buechse) Date: Wed, 22 Mar 2006 12:46:45 +0100 Subject: [Rxtx] PATCH: use of ioctl(fd, TIOCEXCL) instead of lockfiles In-Reply-To: References: <923AE774-EEA2-4911-92D8-32BB27802C8B@buechse.de> Message-ID: Sorry, I was not very clear with my arguments, so I will try again;-) Please, don't take this as an attack against work that has been done. I think the contributions that have been made in the past were made in a good spirit. But I really believe, that the current solution for OSX has many shortcomings and should be changed as soon as possible. lock files --- The /var/lock folder does not exist on the standard OSX installation, however the standard installation includes several applications that use serial ports (i.e. the FAX capability). This indicates, that the lock folder approach will not work well with system components. Applications for OSX will generally try to live in harmony with system components (except for HP print drivers of course). I think RXTX should follow this approach as well. uucp group --- Accessing serial ports is not an admin privileged operation on OSX. Any user (world) has read/write privileges on /dev/tty*. So the system default is to not enforce any group membership to access these ports. The group uucp however is a system group on all unix systems I know. It exists for certain system processes. A non admin user should in general not be a member of this group. Quite arguably no user should ever be a member of this group. Installer --- My general opinion is, that - no Installer should touch user or group data without warning - no Application Installer should touch groups which are not specific to the very application installed - no Installer should ever add regular users to a system group The current installer injects the installing user in the group uucp without warning about this change and without giving the option to "opt out" of this change. This is a potential security risk (but not currently a real one, as OSX contains no folders belonging to group uucp). The current installer does not work for multi user systems. It puts the installing user in the uucp group. However the installing user is not necessarily the user that will use the application. Putting all users that may use a serial port application in the system group uucp seems like a very invasive approach to me. Besides that, newly created users will not automatically be in the group and hence, serial applications will "break" for new users without obvious reasons. Avoiding the lock files will allow self contained applications (i.e. drag&drop installation). In my eyes this is largely preferable over an installer that requests admin privileges. Adding up all these points indicates very strongly, that the lock-file implementation is not the way to go on OSX. Regards, Joachim On 22.03.2006, at 00:13, Dmitry Markman wrote: > I'd like to add that > > creating locking folder isn't a big deal > we never had a problem related to the lock folders, because we > always used installer on mac os x > from other hand I'm not very much familiar with iotcl locking > approach and I'm not sure it's more efficient > > Joachim wrote "I think it is the way to go, as it eliminates > creating the lock directory which doesnt exist on the standard > installation and it eliminates messing with the system group > definitions (adding users to group uucp)." but I really didn't have > any problem with that > > 1. doesn't exist on the standard installation > there are many-many things that don't exist in the standard > installation so I don't think that argument is strong enough > 2. messing with the system group definitions > I don't think we're messing with the group definition > mac os x provides very clear way to set up group's members and > together with Greg Guerin AuthKit there is no problem to set those > definitions > so I don't think that argument is strong either > but from other hand using iotcl is more promising and is more elegant > > > > On Mar 21, 2006, at 1:05 PM, Trent Jarvi wrote: > >> >> This looks like a good start. What do you think Dmitry? Perhaps >> all systems with TIOCEXCL defined should use that though. Even if >> they use lockfiles. It wont hurt anything. That would catch >> people hacking their own serial apps without checking lockfiles. > > Dmitry Markman > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From dmarkman at mac.com Wed Mar 22 05:27:13 2006 From: dmarkman at mac.com (Dmitry Markman) Date: Wed, 22 Mar 2006 07:27:13 -0500 Subject: [Rxtx] PATCH: use of ioctl(fd, TIOCEXCL) instead of lockfiles In-Reply-To: References: <923AE774-EEA2-4911-92D8-32BB27802C8B@buechse.de> Message-ID: <83440CF3-DCD8-41C1-B941-F227232C27E3@mac.com> thanks for the very good explanation I didn't think that you were attacking any thing, so don't worry I just had feeling, that there were more aesthetic reasons for going to ioctl then real necessity now you explained everything quite well (BTW, asfar as I remember installer asks admin password so it wasn't quiet, but it really doesn't matter now) thanks On Mar 22, 2006, at 6:46 AM, Joachim Buechse wrote: > Sorry, I was not very clear with my arguments, so I will try again;-) > > Please, don't take this as an attack against work that has been > done. I think the contributions that have been made in the past > were made in a good spirit. But I really believe, that the current > solution for OSX has many shortcomings and should be changed as > soon as possible. > > lock files > --- > The /var/lock folder does not exist on the standard OSX > installation, however the standard installation includes several > applications that use serial ports (i.e. the FAX capability). This > indicates, that the lock folder approach will not work well with > system components. Applications for OSX will generally try to live > in harmony with system components (except for HP print drivers of > course). I think RXTX should follow this approach as well. > > uucp group > --- > Accessing serial ports is not an admin privileged operation on OSX. > Any user (world) has read/write privileges on /dev/tty*. So the > system default is to not enforce any group membership to access > these ports. The group uucp however is a system group on all unix > systems I know. It exists for certain system processes. A non admin > user should in general not be a member of this group. Quite > arguably no user should ever be a member of this group. > > Installer > --- > My general opinion is, that > - no Installer should touch user or group data without warning > - no Application Installer should touch groups which are not > specific to the very application installed > - no Installer should ever add regular users to a system group > > The current installer injects the installing user in the group uucp > without warning about this change and without giving the option to > "opt out" of this change. This is a potential security risk (but > not currently a real one, as OSX contains no folders belonging to > group uucp). > > The current installer does not work for multi user systems. It puts > the installing user in the uucp group. However the installing user > is not necessarily the user that will use the application. Putting > all users that may use a serial port application in the system > group uucp seems like a very invasive approach to me. Besides that, > newly created users will not automatically be in the group and > hence, serial applications will "break" for new users without > obvious reasons. > > > Avoiding the lock files will allow self contained applications > (i.e. drag&drop installation). In my eyes this is largely > preferable over an installer that requests admin privileges. Adding > up all these points indicates very strongly, that the lock-file > implementation is not the way to go on OSX. > > Regards, > Joachim > > > On 22.03.2006, at 00:13, Dmitry Markman wrote: > >> I'd like to add that >> >> creating locking folder isn't a big deal >> we never had a problem related to the lock folders, because we >> always used installer on mac os x >> from other hand I'm not very much familiar with iotcl locking >> approach and I'm not sure it's more efficient >> >> Joachim wrote "I think it is the way to go, as it eliminates >> creating the lock directory which doesnt exist on the standard >> installation and it eliminates messing with the system group >> definitions (adding users to group uucp)." but I really didn't >> have any problem with that >> >> 1. doesn't exist on the standard installation >> there are many-many things that don't exist in the standard >> installation so I don't think that argument is strong enough >> 2. messing with the system group definitions >> I don't think we're messing with the group definition >> mac os x provides very clear way to set up group's members and >> together with Greg Guerin AuthKit there is no problem to set those >> definitions >> so I don't think that argument is strong either >> but from other hand using iotcl is more promising and is more elegant >> >> >> >> On Mar 21, 2006, at 1:05 PM, Trent Jarvi wrote: >> >>> >>> This looks like a good start. What do you think Dmitry? Perhaps >>> all systems with TIOCEXCL defined should use that though. Even >>> if they use lockfiles. It wont hurt anything. That would catch >>> people hacking their own serial apps without checking lockfiles. >> >> Dmitry Markman >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx Dmitry Markman From lyon at docjava.com Wed Mar 22 06:12:18 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Wed, 22 Mar 2006 08:12:18 -0500 Subject: [Rxtx] sole of a new design pattern Message-ID: Hi All, I have been thinking about how we design the serial port software. I think we need a new design pattern. For lack of a better term, I shall call it: The Parametric Singleton Design Pattern By Douglas A. Lyon ABSTRACT The goal of the singleton design pattern is to make sure that there is one, and only one, instance of a given class. The goal of the parametric singleton design pattern is to make sure that there is one, and only one, instance of a given class with the given parametric values. We parametric singleton design pattern combines the singleton design pattern with a parameter that enables unique creation of instances of a class. These instances are cached. When a user asks for an instance with these parameters, the cache is checked. If the instance is in the cache, the instance is returned, otherwise it is created, added to the cache and then returned. We apply our parametric singleton design pattern to the retrieval of RMI registries bound to a given port. The goal of our system is to make sure that no two RMI registries are listening to the same socket and to make use of the RMI registries after they have been created. RMI registries are used in distributed computation. Introduction The singleton design pattern is meant to ensure that on a single instance of a class exists. It is also meant to provide a global point of access to it. The intent of the parametric singleton design pattern is to ensure that a class has only one instance for a given set of parameter values. It also provides a global point of access to it. Motivation A system cannot tolerate multiple instances of some classes with identical parameters. For example, you cannot have two instances making use of the same serial port, at the same time. You cannot have two instances that are trying to listen to the same socket connection. You cannot have two instances writing to the same file structure at the same time. As the operating system is often thought of as the arbiter of consumed resources (i.e., tape drives, serial ports, etc.) we frequently leave it to an operating system implementation to resolve these contention issues. Even for similar resources (like serial ports) there are few standards for handling contention. For example, serial ports on Linux are locked using a "/var/lock" file. POSIX, on the other hand, uses ioctl mechanisms to prevent contention. A better solution is to make a class that is responsible for keeping track of the instances created from the class. The class is declared final, so that it cannot be subclassed. The class also has a private constructor, so that other classes cannot instance it. The new design pattern is called the parametric singleton design pattern and it provides a way to access and create instances with given parameters. Applicability Use the Parametric Singleton Design Pattern when: 1. There must be exactly one instance of a class with the given parameters. 2. The instances must be accessible to clients from a well-known access point. Structure Insert UML diagram here. Participants The Parametric Singleton Clients that need instances 1. The Parametric Singleton defines an instance upon request from a client, if, and only if, the instance does not already exist. 2. The Parametric Singleton returns the instance to the client. 3. The Parametric Singleton is responsible for creating unique instances from given parameters. Collaborations Clients obtain a reference to a Parametric Singleton instance only through the parametric singleton design pattern. If the instance is left in an improper state (e.g., the serial port was left open) it is NOT the role of the Parametric Singleton Design Pattern to close the IO port. Nor is it the role of the Parametric Singleton Design Pattern to open the port. That role is delegate to some other part of the system. Further, it is not the role of the Parametric Singleton Design Pattern to check out resources. That is, multiple threads can have multiple references to the same resource at the same time. MUTEX locking is delegated to some other part of the system. Consequences The Parametric Singleton Design Pattern has several benefits: 1. Controlled access to parametrically defined instances. Since the Parametric Singleton class encapsulates its instances, there is control over how and when clients access it. 2. Reduced name space. The Parametric Singleton pattern avoids global variables that store instances created from the same parameter. Implementation Here are implementation issues to consider when using the Parametric Singleton pattern: 1. Unique mapping of parameters. The Parametric Singleton pattern requires that there be a mean to isomorphically map the parameter space into the instance space and back again. 2. Ensure unique instances. The Parametric Singleton pattern makes unique instances from parameters, and it does so only once. 3. Cache instances for fast retrieval. The Parametric Singleton pattern must be able to look up instances, given some set of parameters, and do so from some data structure. That is, there must be enough space to hold references to all the instances the program will need. Also, a mechanism is needed to look up and retrieve the instances quickly enough to satisfy the clients. Sample Code public final class ParametricSingletonRmiRegistry { private static Hashtable registry = new Hashtable(100); // use singleton pattern and??????????????????????????????????????????????? // prevent instantiation of RmiRegistryUtils.?????????????????????????????? private ParametricSingletonRmiRegistry() { } // the only instance of the Registry held by the RmiRegistryUtils?????????? public static void listNames(Integer port) { if (!isInCacheAndRunning(port)) return; Registry r = (Registry) registry.get(port); System.out.println("registry on port: " + port); System.out.println("registry: " + r); System.out.println("names: "); try { print(r.list()); } catch (RemoteException e) { In.message(e); } System.out.println("------------------------"); } /**???????????????????????????????????????????????????????????????????????? * Checks whether a Registry has been started on this host????????????????? * in the specified port.?????????????????????????????????????????????????? * If not, it tries to start one.?????????????????????????????????????????? * when it fails to start a Registry, it exits the program????????????????? * with exit code 1.??????????????????????????????????????????????????????? */ public static void restart(int port) { if (isInCacheAndRunning(port)) return; try { startRegistry(port); } catch (RemoteException e) { In.message(e); } } /**???????????????????????????????????????????????????????????????????????? * @param port????????????????????????????????????????????????????????????? * @return true if registry is in cache and running???????????????????????? */ private static boolean isInCacheAndRunning(Integer port) { if (!isRegistryRunning(port.intValue())) return false; if (!isRegistryInCache(port.intValue())) return false; return true; } /**???????????????????????????????????????????????????????????????????????? * @param port????????????????????????????????????????????????????????????? * @return true if we are able to locate a local registry on port.??????????????????????????????????????????????????????????????????????????? */ private static boolean isRegistryRunning(int port) { try { Registry r = LocateRegistry.getRegistry(port); if (r != null) return true; } catch (RemoteException e) { return false; } return false; } /**???????????????????????????????????????????????????????????????????????? * @param port????????????????????????????????????????????????????????????? * @return return true if registry is in cache????????????????????????????? */ private static boolean isRegistryInCache(int port) { if (registry.get(new Integer(port)) == null) return false; return true; } /**???????????????????????????????????????????????????????????????????????? * Restart the registry, if needed.???????????????????????????????????????? * Return the only instance of the registry for consistent global?????????? * using by making use of the Singleton Design Pattern????????????????????? *????????????????????????????????????????????????????????????????????????? * @return the internally held registry instance.?????????????????????????? */ public static Registry getRegistry(Integer port) { restart(port); return (Registry) registry.get(port); } private static void startRegistry(Integer port) throws RemoteException { Registry r; try { r = LocateRegistry.createRegistry(port.intValue()); registry.put(port, r); //r = new sun.rmi.registry.RegistryImpl???????????????????????????? /// (port.intValue());?????????????????????????????????????? // registry.put(port, r);?????????????????????????????????????????? } catch (Exception e) { //e.printStackTrace();????????????????????????????????????????????? r = LocateRegistry.getRegistry(port.intValue()); registry.put(port, r); } } public static void main(String args[]) throws RemoteException { //restart(port);??????????????????????????????????????????????????????? restart(5001); restart(5002); restart(5002); Registry r = LocateRegistry.getRegistry(5002); System.out.println("registry="+r); } } I would very much like to get your feedback on this new design pattern idea. Thank you for your time. Regards, - Doug From david.garnier at trusted-logic.com Wed Mar 22 07:36:10 2006 From: david.garnier at trusted-logic.com (David Garnier) Date: Wed, 22 Mar 2006 15:36:10 +0100 Subject: [Rxtx] sole of a new design pattern In-Reply-To: References: Message-ID: <442160DA.80107@trusted-logic.com> Hello, > The Parametric Singleton Design Pattern The Singleton is the most abused design pattern ever. Good use-cases for this pattern are extremely rare and mostly confined to problems related to hardware resources, like serial ports. > Applicability > > Use the Parametric Singleton Design Pattern when: > 1. There must be exactly one instance of a class with the given > parameters. OK. As I said above, this case this actually very unusual. The Singleton pattern is mostly used when : > 2. The instances must be accessible to clients from a well-known > access point. Using the singleton pattern in this case is just convenient for the programmer. Problems arises pretty quickly, especially if you attempt to unit-test your classes. 1) If your singleton is stateful, or hold on to stateful objects, it means that two different unit tests are not actually independent. Instead of starting with a brand new environment, the result of a test may be affected by the result of a previous test. This problem also arise when with your class relies on a database. In both cases, the solution is to reset your "unique" resource (Singleton or database) at the beginning of the test, which is a pain. Also, while most projects connect to a single database, projects that allow the use of Singletons usually contain several of thems, and new ones may cropped up unnoticed. You quickly end up with test cases that only pass in a certain order, which is a royal pain. 2) You cannot mockup a singleton. Once everyone calls the SomeSingleton class statically, you can't replace your class by SomeSingletonMockup. Furthermore, even for hardware services, the Singleton pattern does not really prevent concurrent accesses. If you start the same program in two different JVMs, unless they somehow shared the state of their "Singletons" (through lock files for example), the Singleton pattern will not prevent concurrent access. Our application uses RXTX, and we routinely encounter cases where another (native) application has already locked the port. Since we cannot modify the native application to recognize lock files, OS-level control is irreplaceable. > > Consequences > The Parametric Singleton Design Pattern has several benefits: > > 1. Controlled access to parametrically defined instances. Since > the Parametric Singleton class encapsulates its instances, there is > control over how and when clients access it. Not really. Once you've returned the instance to a client, you've lost control over it. The client can to whatever it wants with it. You cannot "recall" the instance or claim it back. > 2. Reduced name space. The Parametric Singleton pattern avoids > global variables that store instances created from the same parameter. Sure, but you don't have to rely on a Singleton for that. Just create a single Factory. > I would very much like to get your feedback on this new design > pattern idea. Well, it's nothing new. Some may say that it is the point of design patterns: formalizes the designs that occur again and again. However, this design is simply a combination of the Singleton and Factory patterns. I did use it in the past, but now I've been exposed to the shortcomings of the Singleton pattern, so I limit myself to Factories. Regards, David From sean_montgomery at baseview.com Wed Mar 22 08:35:28 2006 From: sean_montgomery at baseview.com (Sean Montgomery) Date: Wed, 22 Mar 2006 10:35:28 -0500 Subject: [Rxtx] sole of a new design pattern In-Reply-To: <442160DA.80107@trusted-logic.com> References: <442160DA.80107@trusted-logic.com> Message-ID: <05769CA7-A51B-4CF0-BAA0-E02DD905F5A4@baseview.com> On Mar 22, 2006, at 9:36 AM, David Garnier wrote: > Furthermore, even for hardware services, the Singleton pattern does > not really prevent concurrent > accesses. If you start the same program in two different JVMs, > unless they somehow shared the state > of their "Singletons" (through lock files for example), the > Singleton pattern will not prevent > concurrent access. > Multiple class loaders in a single JVM can be tricky, too. Then there's synchronization, lazy initialization and serialization of singletons to contend with. Bloch's Effective Java covers these, and here's a few articles: http://www.javaworld.com/javaworld/jw-04-2003/jw-0425-designpatterns- p3.html http://java.sun.com/developer/technicalArticles/Programming/singletons/ Just FYI :-) From lyon at docjava.com Wed Mar 22 08:50:48 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Wed, 22 Mar 2006 10:50:48 -0500 Subject: [Rxtx] sole of a new design pattern In-Reply-To: <442160DA.80107@trusted-logic.com> References: <442160DA.80107@trusted-logic.com> Message-ID: Hi All, First, I would like to thank David for his prompt and thoughtful remarks. I had no idea people that feel strongly about a design patterns! Wow! Feedback (particularly critical feedback) is greatly appreciated. Starting at the end, first: >I did use it in >the past, but now I've been exposed to the shortcomings of the >Singleton pattern, so I limit myself to Factories. David, if I understood your comments correctly, you suggested that Factories can be used in leu of the Singleton Design Pattern, or even the Parametric Singleton Design Pattern. As I see in [Gof]: Factory Method: Intent "Define an interface for creating an object, but let subclasses decide which class to instantiate. Factory Method lets a class defer instantiation to subclasses." The Singleton Design Pattern is a concrete class, which is rather different, right? Also, subclasses are not permitted with Singleton, as they are final. Naturally, I could use an abstract factory as a parent for a singleton. I could even design a facade that could be implemented with the singleton....but that is not the intention of the design. Unless you want a mock-up, as discussed, below: More below: >Hello, > >> The Parametric Singleton Design Pattern > >The Singleton is the most abused design pattern ever. Good use-cases >for this pattern are extremely >rare and mostly confined to problems related to hardware resources, >like serial ports. > > >> Applicability >> >> Use the Parametric Singleton Design Pattern when: >> 1. There must be exactly one instance of a class with the given >> parameters. >OK. As I said above, this case this actually very unusual. The >Singleton pattern is mostly used when : >> 2. The instances must be accessible to clients from a well-known >> access point. > >Using the singleton pattern in this case is just convenient for the >programmer. Problems arises >pretty quickly, especially if you attempt to unit-test your classes. > >1) If your singleton is stateful, or hold on to stateful objects, it >means that two different unit >tests are not actually independent. Instead of starting with a brand >new environment, the result of >a test may be affected by the result of a previous test. This >problem also arise when with your >class relies on a database. In both cases, the solution is to reset >your "unique" resource >(Singleton or database) at the beginning of the test, which is a >pain. Also, while most projects >connect to a single database, projects that allow the use of >Singletons usually contain several of >thems, and new ones may cropped up unnoticed. You quickly end up >with test cases that only pass in a >certain order, which is a royal pain. There are basic problems with communicating finite state machines that include reachability and deadlock analysis. These are addressed with petri net analysis and are beyond the scope of the design pattern. As you quite rightly pointed out; the parametric singleton pattern (or the singleton pattern, for that matter) enable multiple threads to gain access to the same instance. The only way that I can see to block others from gaining access to the reference is the synchronize keyword. This is putting a spin-lock (or MUTEX) on the reference. The question of how to unit-test a design pattern like the parametric singleton remains open. Perhaps this is a deficiency. > >2) You cannot mockup a singleton. Once everyone calls the >SomeSingleton class statically, you can't >replace your class by SomeSingletonMockup. Acutally, I am not sure that this is true. If the Singleton implements a Facade interface, it should be possible to make the replacement. Right? > >Furthermore, even for hardware services, the Singleton pattern does >not really prevent concurrent >accesses. If you start the same program in two different JVMs, >unless they somehow shared the state >of their "Singletons" (through lock files for example), the >Singleton pattern will not prevent >concurrent access. Good Point!! You have sharp eyes! The singleton design pattern should/could take responsibility for this. In fact, you may notice that my code does have an implementation (LocateRegistry) that can work across JVM's. The LocateRegistry will even work across the Internet! LocateRegistry takes both a host name and a Port (lock files just don't do this). I did not think to implement this beyond the local machine, but, in its present form, it will work across different processes. > >Our application uses RXTX, and we routinely encounter cases where >another (native) application has >already locked the port. Since we cannot modify the native >application to recognize lock files, >OS-level control is irreplaceable. The singleton design pattern is not meant to replace OS-level control, but to centralize the Java programmers access to it. If lock files, for example, are used for serial ports, the Singleton Design Pattern should be able to work with them. > > >> >> Consequences >> The Parametric Singleton Design Pattern has several benefits: >> > > 1. Controlled access to parametrically defined instances. Since >> the Parametric Singleton class encapsulates its instances, there is >> control over how and when clients access it. > >Not really. Once you've returned the instance to a client, you've >lost control over it. The client >can to whatever it wants with it. You cannot "recall" the instance >or claim it back. Good point, this should read: > 1. Controll when parametrically defined instances are created. Since > > the Parametric Singleton class encapsulates its instances, there is > > control over how and when they are instanced. > >> 2. Reduced name space. The Parametric Singleton pattern avoids >> global variables that store instances created from the same parameter. > >Sure, but you don't have to rely on a Singleton for that. Just >create a single Factory. > > Thank you for your thoughtful and prompt response! Regards, - Doug From dmarkman at mac.com Wed Mar 22 21:21:55 2006 From: dmarkman at mac.com (Dmitry Markman) Date: Wed, 22 Mar 2006 23:21:55 -0500 Subject: [Rxtx] sole of a new design pattern In-Reply-To: <442160DA.80107@trusted-logic.com> References: <442160DA.80107@trusted-logic.com> Message-ID: I don't think I get it On Mar 22, 2006, at 9:36 AM, David Garnier wrote: > Using the singleton pattern in this case is just convenient for the > programmer. Problems arises > pretty quickly, especially if you attempt to unit-test your classes. so you're saying that something isn't so good because you can not test it in the convenient way? if that's true, I'm totally disagree change your test, debug whatever, but if software is efficient at runtime, works fine and only problem is some unit test (which is some kind of framework for testing) then dump that unit test , dump that unit framework and make something appropriate to the software you're testing so if Douglas want to use singletons, what's the problem? and what do you mean by abusing of singleton usage? of course singleton doesn't prevent concurrent access to the resource across the processes unless you're using some OS facility to prevent it, besides singleton as it was introduced is relevant only and only inside of the same process otherwise it's not singleton it's something else (let's say network singleton: so you have remote invocation facility and some factory method that return object created by that facility) I don't have any problem with using any kind of singletons. Parametric Singleton idea (if I understand it right) could be easily implemented in the following way: use a map populate map with instances of some class and key is your parameter (you can use lazy population too) if somebody ask the key check the value if it's null so resource is taken if somebody returns the resource put it back to the map public synchronized static Object getSomeResource(Object parameter); public synchronized static void returnResource(Object parameter); getSomeResource (inside of the same process) could return null in 2 cases 1. if somebody (from other thread for example) already took that resource 2. if OS API said that resource corresponded to that parameter (serial port with parameter = 1 (port #)) is locked and unavailable; I'm not sure that in case of serial ports we even need those Parametric Singletons (unless lock checking is a very expensive operation) just ask the OS about availability of that resource and if it's available give it away and then OS will lock it and therefore in next time somebody ask it just answer that resource is locked and return null for example system has 2 serial ports available so I ask getResource("tty"); or I ask getResource("Bluetooth-Modem"); and if OS is ok you can give tty or Bluetooth-Modem or both no need for any additional pattern I think back to the problem mac os x doesn't recognize locking via files, so it handles locking via some API an instance of the singleton in each process should recognize that resource is locked (by using that API) that's all we don't have to make things more complicate then they are just because there is some nice design pattern or nice unit test framework or whatever keep things simple, make them work fast, don't introduce middle layers unless you have really good reason to do so of course I could be entirely wrong, so sorry about that in advance thanks Dmitry Markman From tjarvi at qbang.org Wed Mar 22 22:31:41 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 22 Mar 2006 22:31:41 -0700 (MST) Subject: [Rxtx] sole of a new design pattern In-Reply-To: References: Message-ID: Hi Doug Interesting reading. So far I'm just reading and thinking. I have one question so far. " Clients obtain a reference to a Parametric Singleton instance only through the parametric singleton design pattern. If the instance is left in an improper state (e.g., the serial port was left open) it is NOT the role of the Parametric Singleton Design Pattern to close the IO port. Nor is it the role of the Parametric Singleton Design Pattern to open the port. That role is delegate to some other part of the system. " So when the clients obtain a reference to the singleton, can they assume the port is there? IE, would it be the singletons role to handle things like USB dongles being removed with event hints comming from the underlying OS. Hardware abstraction layer/HAL on Linux is an example of underlying OS events. I assume that role too is delegated to other parts of the system? -- Trent Jarvi tjarvi at qbang.org From lyon at docjava.com Thu Mar 23 08:10:33 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Thu, 23 Mar 2006 10:10:33 -0500 Subject: [Rxtx] Classes don't need goals, they need roles! In-Reply-To: References: Message-ID: Hi Trent, Yes, I think that the role of the Parametric Singleton Pattern is not to open or close serial ports, nor is it to perform error checking. On the other hand, if you were to combine the role of the Parametric Singleton Pattern with another role (like that of error checking) it might not be amiss. However, I generally caution programmers against adding multiple roles to classes, as this leads to monolithic designs. Thus a different class (NativeLibDetect) could have the role of determining if the native library can be loaded. Another class (SerialPortBean) can have the role of serializing the default state of the serial port, so that it can be recovered, from user preferences, at a later time. The SerialPortDetect could have the role of determining if the serial port is removed (i.e., a USB port was unplugged). My guess is that each class should have a different role in the system, in order to ease maintenance and testing...but I could be wrong about that. Thanks! - Doug >Hi Doug > >Interesting reading. So far I'm just reading and thinking. I have >one question so far. > >" > Clients obtain a reference to a Parametric Singleton instance only >through the parametric singleton design pattern. If the instance is >left in an improper state (e.g., the serial port was left open) it is >NOT the role of the Parametric Singleton Design Pattern to close the >IO port. Nor is it the role of the Parametric Singleton Design Pattern >to >open the port. That role is delegate to some other part of the system. >" > >So when the clients obtain a reference to the singleton, can they >assume the port is there? IE, would it be the singletons role to >handle things like USB dongles being removed with event hints >comming from the underlying OS. Hardware abstraction layer/HAL on >Linux is an example of underlying OS events. > >I assume that role too is delegated to other parts of the system? > >-- >Trent Jarvi >tjarvi at qbang.org >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From maximulo at yahoo.com Fri Mar 24 01:22:38 2006 From: maximulo at yahoo.com (Maximulo Majir) Date: Fri, 24 Mar 2006 00:22:38 -0800 (PST) Subject: [Rxtx] JavaPOS Message-ID: <20060324082238.66371.qmail@web38214.mail.mud.yahoo.com> Hi all! Hello Trent! From what i understand, RXTX or JavaComm APIs were not created solely for JavaPOS. In JavaPOS, we have the virtual method claim() which is separate from open(), but in our RXTX API, claiming is done every call to open(), we cant open the port if its claimed by another application. Would it be alright to suggest or ask to create a new method called claim(..)? Is there such thing as forceclaim() in RXTX? this could be the same as portownership transfer or its equivalent. ForceClaim is in JSR80. Do you have some samples using RXTX as the lower layer for the Device Service Objects in JavaPOS? I have tried it, i just want to compare. Thank you all! maxim __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060324/496adba2/attachment-0033.html From tjarvi at qbang.org Fri Mar 24 11:28:19 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 24 Mar 2006 11:28:19 -0700 (MST) Subject: [Rxtx] Re: RXTX 2.1 Solaris Problems In-Reply-To: <3691.1143210578@www045.gmx.net> References: <3691.1143210578@www045.gmx.net> Message-ID: On Fri, 24 Mar 2006, Andreas Guenther wrote: > Hi all, > > the solaris problem was not the lock file only. > > Ok, I had to create the directory /var/spool/locks myself. > /var/spool/uucp exists. > > But rxtx didn't find any port. > > I compiled the source with my own debug-informations > and I tried to isolate the problem. > > The problem is the testRead-call in SerialImp.c > > JNIEXPORT jboolean JNICALL RXTXCommDriver(testRead)( > > ... > if ( READ( fd, &c, 1 ) < 0 ) > { > if ( errno != EAGAIN ) { > report( "testRead() read failed\n" ); > ret = JNI_FALSE; > } > } > Thanks Andreas I'm packing up to move. I'll be more or less away for a couple weeks here. I'll be checking email but my workstation is going into a box soon. This isn't hard to fix as this port should be enumerated when EWOULDBLOCK is recieved. Thats error is OK for enumeration just as EAGAIN is. I've put the bug into bugzilla so we dont forget to get to it. http://bugzilla.qbang.org/show_bug.cgi?id=42 You can add yourself to the CC list if you wish to test fixes we provide or even put a patch into bugzilla yourself. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Fri Mar 24 11:51:52 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 24 Mar 2006 11:51:52 -0700 (MST) Subject: [Rxtx] JavaPOS In-Reply-To: <20060324082238.66371.qmail@web38214.mail.mud.yahoo.com> References: <20060324082238.66371.qmail@web38214.mail.mud.yahoo.com> Message-ID: On Fri, 24 Mar 2006, Maximulo Majir wrote: > Hi all! Hello Trent! > > > From what i understand, RXTX or JavaComm APIs were not > created solely for JavaPOS. In JavaPOS, we have the virtual method > claim() which is separate from open(), but in our RXTX API, claiming is > done every call to open(), we cant open the port if its claimed by > another application. Would it be alright to suggest or ask to create a > new method called claim(..)? Is there such thing as forceclaim() in > RXTX? this could be the same as portownership transfer or its > equivalent. ForceClaim is in JSR80. > Do you have some samples using RXTX as the lower layer for the Device > Service Objects in JavaPOS? I have tried it, i just want to compare. > maxim Hi Maxim JSR80 is the USB API IBM/Sun put together. The problem is they have a richer kernel/API underneath that can handle such things. With Serial Ports, there isnt anything there other than an ioctl that says don't let anyone touch this and lockfiles that are more of a 'lets be nice.' At times we may be using USB ports but it is through the termios layer with the limitations mentioned. The advantage is that not only USB will work with rxtx. Anything that has a termios layer should work (to the extent that termios layer is complete). I don't know how forceclaim() would help you. Lets say someone has a programmer working on /dev/ttyS0 and you take it. Now you both race each other to read data first. There isn't a mechanism I know of that will solve this problem in termios. The most obvious test being a native app and a Java app trying to take the port. There is the potential of requestion ownership from other Java Applications but the use for that is very rare. Did you have something more specific in mind that I'm missing? I'm not sure that claim() and forceclaim() would help you with rxtx other than maybe locking the port with claim() without opening it. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sat Mar 25 23:42:08 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 25 Mar 2006 23:42:08 -0700 (MST) Subject: [Rxtx] Serial snoop Message-ID: I was reading the Linux kernel mail-list tonight and ran past a thread that mentioned sersnoop. This looks like a handy tool for people dealing with new toys. "a simple command-line tool for linux that echoes bytes to and from any two serial ports, ptys, or network sockets, and prints all traffic to stdout, in hex and ascii." http://www.restivo.org/projects/sersnoop/ It works on Linux only at this time (debian package available). -- Trent Jarvi tjarvi at qbang.org From beat.arnet at gmail.com Sun Mar 26 07:32:35 2006 From: beat.arnet at gmail.com (Beat Arnet) Date: Sun, 26 Mar 2006 09:32:35 -0500 Subject: [Rxtx] Error 0x5 at /home/bob/foo/tar/rxtx-2.1-7/build/../src/termios.c(860): Access is, denied. Message-ID: <4426A603.80508@gmail.com> Dear all, When trying to open the serial port, I sometimes (not always) run into the following exception (when opening the serialPort): Error 0x5 at /home/bob/foo/tar/rxtx-2.1-7/build/../src/termios.c(860): Access is denied. java.lang.UnsatisfiedLinkError: native_psmisc_report_owner at gnu.io.CommPortIdentifier.native_psmisc_report_owner(Native Method) at gnu.io.CommPortIdentifier.open(CommPortIdentifier.java:354) at codeskin.tools.CLLoader.open(CLLoader.java:79) at codeskin.tools.C2000Programmer.run(C2000Programmer.java:220) at java.lang.Thread.run(Unknown Source) Is this the type of error where I should just try to open the port again, or can it be avoided? Regards, Beat From tjarvi at qbang.org Sun Mar 26 11:40:12 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 26 Mar 2006 11:40:12 -0700 (MST) Subject: [Rxtx] Error 0x5 at /home/bob/foo/tar/rxtx-2.1-7/build/../src/termios.c(860): Access is, denied. In-Reply-To: <4426A603.80508@gmail.com> References: <4426A603.80508@gmail.com> Message-ID: On Sun, 26 Mar 2006, Beat Arnet wrote: > Dear all, > > When trying to open the serial port, I sometimes (not always) run into > the following exception (when opening the serialPort): > > Error 0x5 at /home/bob/foo/tar/rxtx-2.1-7/build/../src/termios.c(860): > Access is > denied. > > java.lang.UnsatisfiedLinkError: native_psmisc_report_owner > at gnu.io.CommPortIdentifier.native_psmisc_report_owner(Native > Method) > at gnu.io.CommPortIdentifier.open(CommPortIdentifier.java:354) > at codeskin.tools.CLLoader.open(CLLoader.java:79) > at codeskin.tools.C2000Programmer.run(C2000Programmer.java:220) > at java.lang.Thread.run(Unknown Source) > > Is this the type of error where I should just try to open the port again, > or can it be avoided? > Hi Beat We did a second build of rxtx 2.1-7 to resolve that unsatisfied link error. It should work now. rxtx is trying to tell you it thinks someone else has the serial port open. You can try to open the port again but maybe you already have a copy of the program running when it happens? ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7r2.zip fixed build. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sun Mar 26 11:44:23 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 26 Mar 2006 11:44:23 -0700 (MST) Subject: [Rxtx] RXTX spec file (fwd) Message-ID: This is probably interesting for fedora/suse users. ---------- Forwarded message ---------- Date: Sun, 26 Mar 2006 16:25:45 +0200 To: taj at www.linux.org.uk Subject: RXTX spec file I send you this spec file which allows to create a RPM for Fedora 4, 5 (x86, x86_64) with Java Sun. -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: rxtx.spec Url: http://mailman.qbang.org/pipermail/rxtx/attachments/20060326/6c7b6af6/rxtx-0029.pl From tjarvi at qbang.org Sun Mar 26 23:42:59 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 26 Mar 2006 23:42:59 -0700 (MST) Subject: [Rxtx] Upcomming events. Message-ID: This Wednesday we will be announcing a new "Maintainer" for the rxtx project. The position is more like neutral leader. I wont be going away or doing less. This is just the right thing to do as it turns out the two people with CVS write access will be at the same company. We need a third and we need neutrality. The maintainer will have final say in any conflict and will try to be neutral. It will be open for discussion. Then we will do it :) I'll still do most of the footwork I do now. But. I'm falling behind. I should have gone through the mail-list and posted the next round of changes this weekend. I'm packing to move and its going so so - 13 years of toys collected. I suspect there will be a dead period on my part (a couple weeks) comming up. But if you get it on the mail-list, we will get it in if there are no objections. I may well not be reading the mail-list during this period as I look for a house and many other things. I hope everyone will help out. Thanks -- Trent Jarvi tjarvi at qbang.org From mahmoud_hadad at yahoo.com Sun Mar 26 07:31:19 2006 From: mahmoud_hadad at yahoo.com (ronan nick) Date: Sun, 26 Mar 2006 06:31:19 -0800 (PST) Subject: [Rxtx] a question about the COMM API Message-ID: <20060326143119.54919.qmail@web60014.mail.yahoo.com> hi, i was intrested in knowing how i can communicate with my internal modem using java? for example if i want to make a phone dialer application or a caller id application where should i be looking at? and as i understood the COMM API is for devices that is attached to the computer through serial ports. --------------------------------- New Yahoo! Messenger with Voice. Call regular phones from your PC and save big. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060326/ce8329f0/attachment-0031.html From dmarkman at mac.com Mon Mar 20 00:20:43 2006 From: dmarkman at mac.com (Dmitry Markman) Date: Mon, 20 Mar 2006 02:20:43 -0500 Subject: [Rxtx] Mac OS X RXTX java installer In-Reply-To: References: <07D0DE29-BA32-4CFE-B036-66BC6423D385@buechse.de> <441AE3E0.2030503@willicon.de> <12531986.1142622114996.JavaMail.dmarkman@mac.com> <441B2674.9010409@willicon.de> <13577405.1142634732776.JavaMail.dmarkman@mac.com> <441B4182.8010407@willicon.de> <92CD0D6C-5BE8-426E-A46D-99452059FF49@mac.com> <441BBB2D.8030305@willicon.de> <441C4088.5090905@willicon.de> Message-ID: <64BC1E23-FDDE-4CE6-8863-CFC881CBC224@mac.com> Hi all I put RXTX installer that will install everything (and will create / var/lock if necessary and add user to the uucp group) for mac os x from Java into the rxtx's CVS repository it could be easily modified to install files for any platform it uses Greg Guerin's AuthKit for authentication and authorization Greg released that kit under artistic license, so Trent, please take a look we, probably, can negotiate license with Greg if it's necessary Greg's AuthKit could be downloaded from http://www.amug.org/~glguerin/ sw/#authkit Michael Hall (mikehall at spacestar dot net) had a suggestion to make implementation of the jaas LoginModule based on Greg's AuthKit (his modification of the Greg's AuthKit could be found at http:// www.spacestar.net/users/mikehall/authkit.dmg) but Michael's AuthKitLoginModule does only half a job: it does authenticate but it can not run any external unix process in privileged mode (at least I wasn't able to do so) possible explanation could be found in conversation between Greg and Michael at Apple's java-dev list (look for archives) so I didn't use jaas API for rxtxinstaller I created folder MacOSX in the contrib folder comment 1. if you want to run that installer as standalone application all you need that RXTXInstaller.jar 2. if you want to use webstart you have to add Greg's libAuthKit.jnilib to the mac os x's resources in theory RXTXInstaller.jar doesn't need it, but there is a problem with loading libAuthKit.jnilib from webstart authkit uses loadLibrary method to load library and it failed (from webstart) for standalone application I extract libAuthKit.jnilib from the RXTXInstaller.jar and put it into the /Library/Java/Extensions or ~/Library/Java/Extensions folder that file will be deleted after installer quit unfortunately I didn't have time to put documentation there but it is mostly self-explanatory I took installer code from my gl4java installer that I did about 3 years ago (with small modifications) it would be very nice if Apple will release LoginModule that really will do the job (com.apple.security.auth.module package????? ) (UnixLoginModule is pretty useless) From lyon at docjava.com Mon Mar 20 06:34:39 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Mon, 20 Mar 2006 08:34:39 -0500 Subject: [Rxtx] Mac OS X RXTX java installer In-Reply-To: <64BC1E23-FDDE-4CE6-8863-CFC881CBC224@mac.com> References: <07D0DE29-BA32-4CFE-B036-66BC6423D385@buechse.de> <441AE3E0.2030503@willicon.de> <12531986.1142622114996.JavaMail.dmarkman@mac.com> <441B2674.9010409@willicon.de> <13577405.1142634732776.JavaMail.dmarkman@mac.com> <441B4182.8010407@willicon.de> <92CD0D6C-5BE8-426E-A46D-99452059FF49@mac.com> <441BBB2D.8030305@willicon.de> <441C4088.5090905@willicon.de> <64BC1E23-FDDE-4CE6-8863-CFC881CBC224@mac.com> Message-ID: Hi Dimitry, This sounds like great work. Just a couple of questions; After the check out of the CVS files, using: setenv CVSROOT :pserver:anonymous at cvs.milestonesolutions.com:/usr/local/cvsroot 53 8:28 setenv PASSWORD mousy 54 8:29 cvs login 55 8:29 cvs checkout rxtx-devel I cd'd over to: rxtx-devel/MACOSX_IDE And found: CVS/ CW/ ForPackageMaker/ PB/ Where is the installer? Thanks! - Doug From tjarvi at qbang.org Mon Mar 20 06:39:37 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 20 Mar 2006 06:39:37 -0700 (MST) Subject: [Rxtx] Mac OS X RXTX java installer In-Reply-To: References: <07D0DE29-BA32-4CFE-B036-66BC6423D385@buechse.de> <441AE3E0.2030503@willicon.de> <12531986.1142622114996.JavaMail.dmarkman@mac.com> <441B2674.9010409@willicon.de> <13577405.1142634732776.JavaMail.dmarkman@mac.com> <441B4182.8010407@willicon.de> <92CD0D6C-5BE8-426E-A46D-99452059FF49@mac.com> <441BBB2D.8030305@willicon.de> <441C4088.5090905@willicon.de> <64BC1E23-FDDE-4CE6-8863-CFC881CBC224@mac.com> Message-ID: On Mon, 20 Mar 2006, Dr. Douglas Lyon wrote: > Hi Dimitry, > This sounds like great work. Just a couple of questions; > After the check out of the CVS files, using: > setenv CVSROOT > :pserver:anonymous at cvs.milestonesolutions.com:/usr/local/cvsroot > 53 8:28 setenv PASSWORD mousy > 54 8:29 cvs login > 55 8:29 cvs checkout rxtx-devel Hi Doug You want "cvs checkout -r commapi-0-0-1 rxtx-devel" to get RXTX 2.1 The default branch is rxtx 2.0 which isn't very active right now. -- Trent Jarvi tjarvi at qbang.org From lyon at docjava.com Mon Mar 20 07:05:44 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Mon, 20 Mar 2006 09:05:44 -0500 Subject: [Rxtx] Mac OS X RXTX java installer In-Reply-To: References: <07D0DE29-BA32-4CFE-B036-66BC6423D385@buechse.de> <441AE3E0.2030503@willicon.de> <12531986.1142622114996.JavaMail.dmarkman@mac.com> <441B2674.9010409@willicon.de> <13577405.1142634732776.JavaMail.dmarkman@mac.com> <441B4182.8010407@willicon.de> <92CD0D6C-5BE8-426E-A46D-99452059FF49@mac.com> <441BBB2D.8030305@willicon.de> <441C4088.5090905@willicon.de> <64BC1E23-FDDE-4CE6-8863-CFC881CBC224@mac.com> Message-ID: Hi Trent, Thanks for the info on the CVS checkout procedure. I did that and am still not sure where the installer is. Here is what I have: cd MACOSX_IDE/ p4.docjava.com{lyon}121: ls CVS/ ForPackageMaker/ PB/ p4.docjava.com{lyon}122: find . | more . ./ForPackageMaker ./ForPackageMaker/RXTX.pkg.sit.hqx ./ForPackageMaker/Resources ./ForPackageMaker/Resources/ReadMe.rtf ./ForPackageMaker/Resources/Welcome.rtf ./ForPackageMaker/Resources/CVS ./ForPackageMaker/Resources/CVS/Entries ./ForPackageMaker/Resources/CVS/Repository ./ForPackageMaker/Resources/CVS/Tag ./ForPackageMaker/Resources/CVS/Root ./ForPackageMaker/Resources/preinstall ./ForPackageMaker/Resources/License.rtf ./ForPackageMaker/Resources/preupgrade ./ForPackageMaker/RXTX.pmsp ./ForPackageMaker/CVS ./ForPackageMaker/CVS/Entries ./ForPackageMaker/CVS/Repository ./ForPackageMaker/CVS/Entries.Log ./ForPackageMaker/CVS/Tag ./ForPackageMaker/CVS/Root ./ForPackageMaker/RXTX_Tiger.pkg.sitx.hqx ./ForPackageMaker/RXTX_Jag.pkg.sit.hqx ./ForPackageMaker/Install ./ForPackageMaker/Install/CVS ./ForPackageMaker/Install/CVS/Entries ./ForPackageMaker/Install/CVS/Repository ./ForPackageMaker/Install/CVS/Tag ./ForPackageMaker/Install/CVS/Root ./ForPackageMaker/Install/Library ./ForPackageMaker/Install/Library/CVS ./ForPackageMaker/Install/Library/CVS/Entries ./ForPackageMaker/Install/Library/CVS/Repository ./ForPackageMaker/Install/Library/CVS/Tag ./ForPackageMaker/Install/Library/CVS/Root ./ForPackageMaker/Install/Library/Java ./ForPackageMaker/Install/Library/Java/Extensions ./ForPackageMaker/Install/Library/Java/Extensions/RXTXcomm.jar ./ForPackageMaker/Install/Library/Java/Extensions/CVS ./ForPackageMaker/Install/Library/Java/Extensions/CVS/Entries ./ForPackageMaker/Install/Library/Java/Extensions/CVS/Repository ./ForPackageMaker/Install/Library/Java/Extensions/CVS/Tag ./ForPackageMaker/Install/Library/Java/Extensions/CVS/Root ./ForPackageMaker/Install/Library/Java/Extensions/librxtxSerial.jnilib ./ForPackageMaker/Install/Library/Java/CVS ./ForPackageMaker/Install/Library/Java/CVS/Entries ./ForPackageMaker/Install/Library/Java/CVS/Repository ./ForPackageMaker/Install/Library/Java/CVS/Entries.Log ./ForPackageMaker/Install/Library/Java/CVS/Tag ./ForPackageMaker/Install/Library/Java/CVS/Root ./ForPackageMaker/RXTX_Tiger.pmproj.sitx.hqx ./CVS ./CVS/Entries ./CVS/Repository ./CVS/Entries.Log ./CVS/Tag ./CVS/Root ./PB ./PB/LibSerialUniversal.xcodeproj.sitx.hqx ./PB/CVS ./PB/CVS/Entries ./PB/CVS/Repository ./PB/CVS/Entries.Log ./PB/CVS/Tag ./PB/CVS/Root ./PB/LibSerial.pbproj.sit.hqx ./PB/startpoint.c ./PB/config.h What is the procedure to run this installer? Do we need a README in: /rxtx-devel/MACOSX_IDE Here is what we have: CVS/ ForPackageMaker/ PB/ Thanks! - DL >On Mon, 20 Mar 2006, Dr. Douglas Lyon wrote: > >>Hi Dimitry, >>This sounds like great work. Just a couple of questions; >>After the check out of the CVS files, using: >>setenv CVSROOT >>:pserver:anonymous at cvs.milestonesolutions.com:/usr/local/cvsroot >> 53 8:28 setenv PASSWORD mousy >> 54 8:29 cvs login >> 55 8:29 cvs checkout rxtx-devel > >Hi Doug > >You want "cvs checkout -r commapi-0-0-1 rxtx-devel" to get RXTX 2.1 >The default branch is rxtx 2.0 which isn't very active right now. > >-- >Trent Jarvi >tjarvi at qbang.org From tjarvi at qbang.org Mon Mar 20 07:25:30 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 20 Mar 2006 07:25:30 -0700 (MST) Subject: [Rxtx] Mac OS X RXTX java installer In-Reply-To: References: <07D0DE29-BA32-4CFE-B036-66BC6423D385@buechse.de> <441AE3E0.2030503@willicon.de> <12531986.1142622114996.JavaMail.dmarkman@mac.com> <441B2674.9010409@willicon.de> <13577405.1142634732776.JavaMail.dmarkman@mac.com> <441B4182.8010407@willicon.de> <92CD0D6C-5BE8-426E-A46D-99452059FF49@mac.com> <441BBB2D.8030305@willicon.de> <441C4088.5090905@willicon.de> <64BC1E23-FDDE-4CE6-8863-CFC881CBC224@mac.com> Message-ID: On Mon, 20 Mar 2006, Dr. Douglas Lyon wrote: > Hi Trent, > Thanks for the info on the CVS checkout procedure. > I did that and am still not sure where the installer is. Hi Doug It does look like it was not cvs committed. There is no rxtx-devel/contrib/MacOSX directory in there at the moment. It was mentioned that it was put under contrib. -- Trent Jarvi tjarvi at qbang.org From dmarkman at mac.com Mon Mar 20 07:29:56 2006 From: dmarkman at mac.com (Dmitry Markman) Date: Mon, 20 Mar 2006 09:29:56 -0500 Subject: [Rxtx] Mac OS X RXTX java installer In-Reply-To: References: <07D0DE29-BA32-4CFE-B036-66BC6423D385@buechse.de> <441AE3E0.2030503@willicon.de> <12531986.1142622114996.JavaMail.dmarkman@mac.com> <441B2674.9010409@willicon.de> <13577405.1142634732776.JavaMail.dmarkman@mac.com> <441B4182.8010407@willicon.de> <92CD0D6C-5BE8-426E-A46D-99452059FF49@mac.com> <441BBB2D.8030305@willicon.de> <441C4088.5090905@willicon.de> <64BC1E23-FDDE-4CE6-8863-CFC881CBC224@mac.com> Message-ID: <6054EB4E-F7E0-4A9C-BDDA-D582D6D8826F@mac.com> you can find it in the rxtx-devel/contrib folder On Mar 20, 2006, at 9:05 AM, Dr. Douglas Lyon wrote: > Hi Trent, > Thanks for the info on the CVS checkout procedure. > I did that and am still not sure where the installer is. > Here is what I have: > cd MACOSX_IDE/ > p4.docjava.com{lyon}121: ls > CVS/ ForPackageMaker/ PB/ > p4.docjava.com{lyon}122: find . | more > . > ./ForPackageMaker > ./ForPackageMaker/RXTX.pkg.sit.hqx > ./ForPackageMaker/Resources > ./ForPackageMaker/Resources/ReadMe.rtf > ./ForPackageMaker/Resources/Welcome.rtf > ./ForPackageMaker/Resources/CVS > ./ForPackageMaker/Resources/CVS/Entries > ./ForPackageMaker/Resources/CVS/Repository > ./ForPackageMaker/Resources/CVS/Tag > ./ForPackageMaker/Resources/CVS/Root > ./ForPackageMaker/Resources/preinstall > ./ForPackageMaker/Resources/License.rtf > ./ForPackageMaker/Resources/preupgrade > ./ForPackageMaker/RXTX.pmsp > ./ForPackageMaker/CVS > ./ForPackageMaker/CVS/Entries > ./ForPackageMaker/CVS/Repository > ./ForPackageMaker/CVS/Entries.Log > ./ForPackageMaker/CVS/Tag > ./ForPackageMaker/CVS/Root > ./ForPackageMaker/RXTX_Tiger.pkg.sitx.hqx > ./ForPackageMaker/RXTX_Jag.pkg.sit.hqx > ./ForPackageMaker/Install > ./ForPackageMaker/Install/CVS > ./ForPackageMaker/Install/CVS/Entries > ./ForPackageMaker/Install/CVS/Repository > ./ForPackageMaker/Install/CVS/Tag > ./ForPackageMaker/Install/CVS/Root > ./ForPackageMaker/Install/Library > ./ForPackageMaker/Install/Library/CVS > ./ForPackageMaker/Install/Library/CVS/Entries > ./ForPackageMaker/Install/Library/CVS/Repository > ./ForPackageMaker/Install/Library/CVS/Tag > ./ForPackageMaker/Install/Library/CVS/Root > ./ForPackageMaker/Install/Library/Java > ./ForPackageMaker/Install/Library/Java/Extensions > ./ForPackageMaker/Install/Library/Java/Extensions/RXTXcomm.jar > ./ForPackageMaker/Install/Library/Java/Extensions/CVS > ./ForPackageMaker/Install/Library/Java/Extensions/CVS/Entries > ./ForPackageMaker/Install/Library/Java/Extensions/CVS/Repository > ./ForPackageMaker/Install/Library/Java/Extensions/CVS/Tag > ./ForPackageMaker/Install/Library/Java/Extensions/CVS/Root > ./ForPackageMaker/Install/Library/Java/Extensions/librxtxSerial.jnilib > ./ForPackageMaker/Install/Library/Java/CVS > ./ForPackageMaker/Install/Library/Java/CVS/Entries > ./ForPackageMaker/Install/Library/Java/CVS/Repository > ./ForPackageMaker/Install/Library/Java/CVS/Entries.Log > ./ForPackageMaker/Install/Library/Java/CVS/Tag > ./ForPackageMaker/Install/Library/Java/CVS/Root > ./ForPackageMaker/RXTX_Tiger.pmproj.sitx.hqx > ./CVS > ./CVS/Entries > ./CVS/Repository > ./CVS/Entries.Log > ./CVS/Tag > ./CVS/Root > ./PB > ./PB/LibSerialUniversal.xcodeproj.sitx.hqx > ./PB/CVS > ./PB/CVS/Entries > ./PB/CVS/Repository > ./PB/CVS/Entries.Log > ./PB/CVS/Tag > ./PB/CVS/Root > ./PB/LibSerial.pbproj.sit.hqx > ./PB/startpoint.c > ./PB/config.h > > What is the procedure to run this installer? > Do we need a README in: > /rxtx-devel/MACOSX_IDE > Here is what we have: > CVS/ ForPackageMaker/ PB/ > > > Thanks! > - DL > >> On Mon, 20 Mar 2006, Dr. Douglas Lyon wrote: >> >>> Hi Dimitry, >>> This sounds like great work. Just a couple of questions; >>> After the check out of the CVS files, using: >>> setenv CVSROOT :pserver:anonymous at cvs.milestonesolutions.com:/usr/ >>> local/cvsroot >>> 53 8:28 setenv PASSWORD mousy >>> 54 8:29 cvs login >>> 55 8:29 cvs checkout rxtx-devel >> >> Hi Doug >> >> You want "cvs checkout -r commapi-0-0-1 rxtx-devel" to get RXTX 2.1 >> The default branch is rxtx 2.0 which isn't very active right now. >> >> -- >> Trent Jarvi >> tjarvi at qbang.org > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx Dmitry Markman From mikehall at spacestar.net Mon Mar 20 05:25:25 2006 From: mikehall at spacestar.net (Michael Hall) Date: Mon, 20 Mar 2006 06:25:25 -0600 Subject: [Rxtx] Re: Mac OS X RXTX java installer In-Reply-To: <64BC1E23-FDDE-4CE6-8863-CFC881CBC224@mac.com> References: <07D0DE29-BA32-4CFE-B036-66BC6423D385@buechse.de> <441AE3E0.2030503@willicon.de> <12531986.1142622114996.JavaMail.dmarkman@mac.com> <441B2674.9010409@willicon.de> <13577405.1142634732776.JavaMail.dmarkman@mac.com> <441B4182.8010407@willicon.de> <92CD0D6C-5BE8-426E-A46D-99452059FF49@mac.com> <441BBB2D.8030305@willicon.de> <441C4088.5090905@willicon.de> <64BC1E23-FDDE-4CE6-8863-CFC881CBC224@mac.com> Message-ID: <247EB61F-5CD1-4132-89A2-FC105B6CF9A5@spacestar.net> On Mar 20, 2006, at 1:20 AM, Dmitry Markman wrote: > > Michael Hall (mikehall at spacestar dot net) had a suggestion to > make implementation of the jaas LoginModule > based on Greg's AuthKit > (his modification of the Greg's AuthKit could be found at http:// > www.spacestar.net/users/mikehall/authkit.dmg) > but Michael's AuthKitLoginModule does only half a job: > it does authenticate > but it can not run any external unix process in privileged mode (at > least I wasn't able to do so) If you got it working directly with Greg's the point is moot. But to clarify it anyhow. The login module does not allow you to do anything anything privileged on return as was explained by Greg. You need to work with a separate privileged process using the execPrivileged method of his API. I assume you did something similar although I haven't looked at how you are using it yet. I allowed instead for a action to be performed at the same time you login/authenticate,this... System.setProperty("authkit.action","/usr/bin/id"); just before this... lc.login(); To clarify, safely ignored as you are already complete. Mike Hall mikehall at spacestar dot net http://www.spacestar.net/users/mikehall http://sourceforge.net/projects/macnative -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2427 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20060320/f6e18202/smime-0034.bin From dmarkman at mac.com Mon Mar 20 07:36:47 2006 From: dmarkman at mac.com (Dmitry Markman) Date: Mon, 20 Mar 2006 09:36:47 -0500 Subject: [Rxtx] Re: Mac OS X RXTX java installer In-Reply-To: <247EB61F-5CD1-4132-89A2-FC105B6CF9A5@spacestar.net> References: <07D0DE29-BA32-4CFE-B036-66BC6423D385@buechse.de> <441AE3E0.2030503@willicon.de> <12531986.1142622114996.JavaMail.dmarkman@mac.com> <441B2674.9010409@willicon.de> <13577405.1142634732776.JavaMail.dmarkman@mac.com> <441B4182.8010407@willicon.de> <92CD0D6C-5BE8-426E-A46D-99452059FF49@mac.com> <441BBB2D.8030305@willicon.de> <441C4088.5090905@willicon.de> <64BC1E23-FDDE-4CE6-8863-CFC881CBC224@mac.com> <247EB61F-5CD1-4132-89A2-FC105B6CF9A5@spacestar.net> Message-ID: Hi, Michael all I have to do is to run some shell script I tried to use your action mechanism and it worked great so I just System.setProperty ("authkit.action","" ) and after that I even don't need to run anything like subject.doAs.... but after few thoughts I choose to use plain Greg's approach, because in that case I don't have to deal with various java's configurations files and therefore to use 2-3 -D parameters in the java command line especially it's useful for java web start (it's so fragile :-( ) thanks for the great job On Mar 20, 2006, at 7:25 AM, Michael Hall wrote: > > On Mar 20, 2006, at 1:20 AM, Dmitry Markman wrote: >> >> Michael Hall (mikehall at spacestar dot net) had a suggestion to >> make implementation of the jaas LoginModule >> based on Greg's AuthKit >> (his modification of the Greg's AuthKit could be found at http:// >> www.spacestar.net/users/mikehall/authkit.dmg) >> but Michael's AuthKitLoginModule does only half a job: >> it does authenticate >> but it can not run any external unix process in privileged mode >> (at least I wasn't able to do so) > > If you got it working directly with Greg's the point is moot. > > But to clarify it anyhow. > The login module does not allow you to do anything anything > privileged on return as was explained by Greg. You need to work > with a separate privileged process using the execPrivileged method > of his API. I assume you did something similar although I haven't > looked at how you are using it yet. > I allowed instead for a action to be performed at the same time you > login/authenticate,this... > System.setProperty("authkit.action","/usr/bin/id"); > just before this... > lc.login(); > To clarify, safely ignored as you are already complete. > > Mike Hall mikehall at spacestar dot net > http://www.spacestar.net/users/mikehall > http://sourceforge.net/projects/macnative > > > Dmitry Markman From dmarkman at mac.com Mon Mar 20 07:44:45 2006 From: dmarkman at mac.com (Dmitry Markman) Date: Mon, 20 Mar 2006 09:44:45 -0500 Subject: [Rxtx] Mac OS X RXTX java installer In-Reply-To: References: <07D0DE29-BA32-4CFE-B036-66BC6423D385@buechse.de> <441AE3E0.2030503@willicon.de> <12531986.1142622114996.JavaMail.dmarkman@mac.com> <441B2674.9010409@willicon.de> <13577405.1142634732776.JavaMail.dmarkman@mac.com> <441B4182.8010407@willicon.de> <92CD0D6C-5BE8-426E-A46D-99452059FF49@mac.com> <441BBB2D.8030305@willicon.de> <441C4088.5090905@willicon.de> <64BC1E23-FDDE-4CE6-8863-CFC881CBC224@mac.com> Message-ID: it's in the commapi-0-0-1 branch I tested it right now: cvs co -r commapi-0-0-1 rxtx-devel and I got everything On Mar 20, 2006, at 9:25 AM, Trent Jarvi wrote: > On Mon, 20 Mar 2006, Dr. Douglas Lyon wrote: > >> Hi Trent, >> Thanks for the info on the CVS checkout procedure. >> I did that and am still not sure where the installer is. > > Hi Doug > > It does look like it was not cvs committed. There is no rxtx-devel/ > contrib/MacOSX directory in there at the moment. It was mentioned > that it was put under contrib. > > -- > Trent Jarvi > tjarvi at qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx Dmitry Markman From tjarvi at qbang.org Mon Mar 20 07:52:57 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 20 Mar 2006 07:52:57 -0700 (MST) Subject: [Rxtx] Mac OS X RXTX java installer In-Reply-To: References: <07D0DE29-BA32-4CFE-B036-66BC6423D385@buechse.de> <441AE3E0.2030503@willicon.de> <12531986.1142622114996.JavaMail.dmarkman@mac.com> <441B2674.9010409@willicon.de> <13577405.1142634732776.JavaMail.dmarkman@mac.com> <441B4182.8010407@willicon.de> <92CD0D6C-5BE8-426E-A46D-99452059FF49@mac.com> <441BBB2D.8030305@willicon.de> <441C4088.5090905@willicon.de> <64BC1E23-FDDE-4CE6-8863-CFC881CBC224@mac.com> Message-ID: On Mon, 20 Mar 2006, Dmitry Markman wrote: > it's in the commapi-0-0-1 branch > > I tested it right now: > cvs co -r commapi-0-0-1 rxtx-devel > > and I got everything > A fresh checkout worked. Here is a copy of the tree (just the installer bits) ftp://ftp.qbang.org/pub/rxtx/MacOSX-installer.zip -- Trent Jarvi tjarvi at qbang.org From lyon at docjava.com Mon Mar 20 08:08:26 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Mon, 20 Mar 2006 10:08:26 -0500 Subject: [Rxtx] Mac OS X RXTX java installer In-Reply-To: References: <07D0DE29-BA32-4CFE-B036-66BC6423D385@buechse.de> <441AE3E0.2030503@willicon.de> <12531986.1142622114996.JavaMail.dmarkman@mac.com> <441B2674.9010409@willicon.de> <13577405.1142634732776.JavaMail.dmarkman@mac.com> <441B4182.8010407@willicon.de> <92CD0D6C-5BE8-426E-A46D-99452059FF49@mac.com> <441BBB2D.8030305@willicon.de> <441C4088.5090905@willicon.de> <64BC1E23-FDDE-4CE6-8863-CFC881CBC224@mac.com> Message-ID: Hi All, Is the Auth package able to work properly on non Mac OS's? It was not clear from the doc or download. Thanks! - Doug From dmarkman at mac.com Mon Mar 20 08:15:22 2006 From: dmarkman at mac.com (Dmitry Markman) Date: Mon, 20 Mar 2006 10:15:22 -0500 Subject: [Rxtx] Mac OS X RXTX java installer In-Reply-To: References: <07D0DE29-BA32-4CFE-B036-66BC6423D385@buechse.de> <441AE3E0.2030503@willicon.de> <12531986.1142622114996.JavaMail.dmarkman@mac.com> <441B2674.9010409@willicon.de> <13577405.1142634732776.JavaMail.dmarkman@mac.com> <441B4182.8010407@willicon.de> <92CD0D6C-5BE8-426E-A46D-99452059FF49@mac.com> <441BBB2D.8030305@willicon.de> <441C4088.5090905@willicon.de> <64BC1E23-FDDE-4CE6-8863-CFC881CBC224@mac.com> Message-ID: <217312D8-CCCA-4859-ABA6-32DF1CC817B9@mac.com> thanks Trent, for putting it on ftp server On Mar 20, 2006, at 9:52 AM, Trent Jarvi wrote: > A fresh checkout worked. Here is a copy of the tree (just the > installer bits) > > ftp://ftp.qbang.org/pub/rxtx/MacOSX-installer.zip > Dmitry Markman From dmarkman at mac.com Mon Mar 20 09:14:03 2006 From: dmarkman at mac.com (Dmitry Markman) Date: Mon, 20 Mar 2006 11:14:03 -0500 Subject: [Rxtx] Mac OS X RXTX java installer In-Reply-To: References: <07D0DE29-BA32-4CFE-B036-66BC6423D385@buechse.de> <441AE3E0.2030503@willicon.de> <12531986.1142622114996.JavaMail.dmarkman@mac.com> <441B2674.9010409@willicon.de> <13577405.1142634732776.JavaMail.dmarkman@mac.com> <441B4182.8010407@willicon.de> <92CD0D6C-5BE8-426E-A46D-99452059FF49@mac.com> <441BBB2D.8030305@willicon.de> <441C4088.5090905@willicon.de> <64BC1E23-FDDE-4CE6-8863-CFC881CBC224@mac.com> Message-ID: <4DEBA6F0-DA45-4E84-823E-1F1AC48BDCCC@mac.com> no it will work only on mac os x however it's harmless to run it on other platform if you want to use it for other platform you have to do the following (I'll do it for linux) 1. modify RXTXInstaller class method public static RXTXInstaller getInstance() public static RXTXInstaller getInstance() { String osName = System.getProperty("os.name").toLowerCase(); if(osName.startsWith("mac")){ return new gnu.io.installer.macosx.MACOSXRXTXInstaller(); } else if(osName.startsWith("windows")){ return new gnu.io.installer.windows.WindowsRXTXInstaller(); }else if(osName.startsWith("linux")){ return new gnu.io.installer.linux.LinuxRXTXInstaller(); } return null; } 2. create folder gnu/io/installer/linux/ 3. create class Linux386RXTXInstaller package gnu.io.installer.linux; import java.io.File; public class Linux386RXTXInstaller extends gnu.io.installer.RXTXInstaller{ public Linux386RXTXInstaller(){ createJarFolder(); createLibFolder(); addJarResource("RXTXcomm.jar","/gnu/io/installer/resources/ linux/jar/RXTXcomm.dat"); addLibResource("librxtxSerial.so","/gnu/io/installer/ resources/linux/lib/librxtxSerial.so"); } protected void createJarFolder(){ String javaHome = System.getProperty("java.home"); char separator = File.separatorChar; jarFolder = new File(javaHome+separator+"lib"+separator+"ext"); } protected void createLibFolder(){ String javaHome = System.getProperty("java.home"); char separator = File.separatorChar; libFolder = new File(javaHome+separator+"bin"); } public void runPreProcess() {} //put here some action you need public void runPostProcess() {} //put here some action you need } 4. create folder /gnu/io/installer/resources/linux/jar and put there linux's version of RXTXcomm.dat (which is renamed RXTXcomm.jar) 5. create folder /gnu/io/installer/resources/linux/lib and put there linux's version of librxtxSerial. so 6. make sure that RXTXInstaller.jar has the following items: /gnu/io/installer/resources/linux/jar/RXTXcomm.jar /gnu/io/installer/resources/linux/lib/librxtxSerial.so 7. modify file installer.pref: jar file RXTXInstaller.jar must have the following item /gnu/io/installer/installer.pref that's basically it for windows you have to do the similar things: just replace linux to windows and librxtxSerial.so to rxtxSerial.dll and create appropriate gnu.io.installer.windows.WindowsRXTXInstaller class package gnu.io.installer.windows; import java.io.File; public class WindowsRXTXInstaller extends gnu.io.installer.RXTXInstaller{ public WindowsRXTXInstaller(){ createJarFolder(); createLibFolder(); addJarResource("RXTXcomm.jar","/gnu/io/installer/resources/ windows/jar/RXTXcomm.dat"); addLibResource("librxtxSerial.so","/gnu/io/installer/ resources/windows/lib/rxtxSerial.dll"); } protected void createJarFolder(){ String javaHome = System.getProperty("java.home"); char separator = File.separatorChar; jarFolder = new File(javaHome+separator+"lib"+separator+"ext"); } protected void createLibFolder(){ String javaHome = System.getProperty("java.home"); char separator = File.separatorChar; libFolder = new File(javaHome+separator+"bin"); } public void runPreProcess() {} //put here some action you need public void runPostProcess() {} //put here some action you need } installer.pref will look like On Mar 20, 2006, at 10:08 AM, Dr. Douglas Lyon wrote: > Hi All, > Is the Auth package able to work properly on > non Mac OS's? > It was not clear from the doc or download. > > Thanks! > - Doug > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx Dmitry Markman From joachim at buechse.de Mon Mar 20 10:49:06 2006 From: joachim at buechse.de (Joachim Buechse) Date: Mon, 20 Mar 2006 18:49:06 +0100 Subject: [Rxtx] BUG: Lock file stays even if port opening fails Message-ID: This was only tested on MacOSX but looking at the code, it should be true for all systems that use lock_uucp. I am opening a port which can not be opened (dialup port of a telephone paired via bluetooth but currently not reachable). The lock file is created and stays arround, even though the port open failed. After looking a bit through the code (of 2.17), I really wonder if it wouldn't be a good idea to make the "locking" an explicit operation called from the java code. This would certainly simplify the generation of meaningfull exceptions (and java based debugging). Maybe even the handling of "preopened" ports should be in the Java part of the lib (again for java based debugging puposes). That beeing said, I have no idea if this would be possible for the 2.07 implementation. Regards, Joachim From tjarvi at qbang.org Mon Mar 20 11:24:22 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 20 Mar 2006 11:24:22 -0700 (MST) Subject: [Rxtx] BUG: Lock file stays even if port opening fails In-Reply-To: References: Message-ID: On Mon, 20 Mar 2006, Joachim Buechse wrote: > This was only tested on MacOSX but looking at the code, it should be true > for all systems that use lock_uucp. > > I am opening a port which can not be opened (dialup port of a telephone > paired via bluetooth but currently not reachable). The lock file is > created and stays arround, even though the port open failed. > > > After looking a bit through the code (of 2.17), I really wonder if it > wouldn't be a good idea to make the "locking" an explicit operation > called from the java code. This would certainly simplify the generation > of meaningfull exceptions (and java based debugging). > Maybe even the handling of "preopened" ports should be in the Java part > of the lib (again for java based debugging puposes). That beeing said, I > have no idea if this would be possible for the 2.07 implementation. > > Regards, Hi Joachim It should be possible in the 2.0-7 implementation too. The calls to RXTXPort.java would not change. We would just do more there Moving more of that logic into Java would be better as many people don't like to look at C code. There is a liblockdev on most Linux distros that can do most of the C code and would be easier to use. The problem is embeded devices will not have that library. The preopened port code has not been really tested. That was a last minute request in a product cycle. I expect it will be tested this year though. As I recall, some devices really do not like CD raising on open. The preopened ports then allow people to mess around in java without power cycling the devices or losing data. -- Trent Jarvi tjarvi at qbang.org From joachim at buechse.de Mon Mar 20 12:01:08 2006 From: joachim at buechse.de (Joachim Buechse) Date: Mon, 20 Mar 2006 20:01:08 +0100 Subject: [Rxtx] BUG: Lock file stays even if port opening fails In-Reply-To: References: Message-ID: Hi Trent, What is your general feeling about moving code to Java? The last days I have been reading quite a bit of the code and there are several things, that might not work as expected. I'll give you two examples from is_device_locked: if LOCKDIR == /var/spool/locks the directory /var/spool/lock will not be checked. LOCKDIR is not checked for lockfiles with unexpected pefixes While these things have probably never been discovered in production, they are still possibly incorrect implementations. If it was Java code, I would write some unit tests producing the errors that could later be corrected. PS: One could imagine to actually implement the whole lockfile handling in Java using some native routines to get the values required (pid, st_dev, st_rdev, ...). On 20.03.2006, at 19:24, Trent Jarvi wrote: > On Mon, 20 Mar 2006, Joachim Buechse wrote: > >> This was only tested on MacOSX but looking at the code, it should >> be true for all systems that use lock_uucp. >> >> I am opening a port which can not be opened (dialup port of a >> telephone paired via bluetooth but currently not reachable). The >> lock file is created and stays arround, even though the port open >> failed. >> >> >> After looking a bit through the code (of 2.17), I really wonder if >> it wouldn't be a good idea to make the "locking" an explicit >> operation called from the java code. This would certainly simplify >> the generation of meaningfull exceptions (and java based debugging). >> Maybe even the handling of "preopened" ports should be in the Java >> part of the lib (again for java based debugging puposes). That >> beeing said, I have no idea if this would be possible for the 2.07 >> implementation. >> >> Regards, > > Hi Joachim > > It should be possible in the 2.0-7 implementation too. The calls > to RXTXPort.java would not change. We would just do more there > Moving more of that logic into Java would be better as many people > don't like to look at C code. There is a liblockdev on most Linux > distros that can do most of the C code and would be easier to use. > The problem is embeded devices will not have that library. > > The preopened port code has not been really tested. That was a > last minute request in a product cycle. I expect it will be tested > this year though. As I recall, some devices really do not like CD > raising on open. The preopened ports then allow people to mess > around in java without power cycling the devices or losing data. > > -- > Trent Jarvi > tjarvi at qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Mon Mar 20 12:21:02 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 20 Mar 2006 12:21:02 -0700 (MST) Subject: [Rxtx] BUG: Lock file stays even if port opening fails In-Reply-To: References: Message-ID: On Mon, 20 Mar 2006, Joachim Buechse wrote: > Hi Trent, > > What is your general feeling about moving code to Java? The last days I > have been reading quite a bit of the code and there are several things, > that might not work as expected. > > I'll give you two examples from is_device_locked: > > if LOCKDIR == /var/spool/locks the directory /var/spool/lock will not be > checked. > LOCKDIR is not checked for lockfiles with unexpected pefixes > > While these things have probably never been discovered in production, > they are still possibly incorrect implementations. If it was Java code, I > would write some unit tests producing the errors that could later be > corrected. > > PS: One could imagine to actually implement the whole lockfile handling > in Java using some native routines to get the values required (pid, > st_dev, st_rdev, ...). Hi Joachim I like the idea of moving more of the code into java but there are some things to consider. If you break this into multiple JNI calls, the performance will drop considerably during enumeration of ports. We are looking for 256 ports per dev type vs (16? in Sun's 2.0 and fewer types). Its hard to make assumptions. I've seen virtual ports start at /dev/foo100 for instance. It works out to over 7500 ports on Linux if you enable them all. We already trim that back by default. See Linux-all-ports in RXTXCommDriver.java. There are also native libraries that rxtx can link to. If you move too much into Java, linking to 'standard' libraries with distros will break. "configure --enable-liblock=yes" will not be doable. This is probably a favorable way with RedHat, Debian, Suse and others. Thats the right thing to do if there will be rpms, dpkg, .. For those reasons, I think it still make sense to keep it to a minimal ~3 calls to JNI code that we can use for speed and versatility. lock() isLocked(), unlock() perhaps. When I say speed, its more about avoiding crossing the JNI layer multiple times than java vs C performance. With versatility I think liblock is the right way for most but not all (embeded) linux distros. -- Trent Jarvi tjarvi at qbang.org From joachim at buechse.de Mon Mar 20 12:42:04 2006 From: joachim at buechse.de (Joachim Buechse) Date: Mon, 20 Mar 2006 20:42:04 +0100 Subject: [Rxtx] BUG: Lock file stays even if port opening fails In-Reply-To: References: Message-ID: <82C19FE7-DDCB-45B6-B2C9-7606B66F0124@buechse.de> Ok, what about providing a default implementation in Java? The RXTXCommDriver would call a (native) function useNativeLocking and if it returns true, call the native functions for lock() isLocked (), unlock(), else is would use the Java based default implementation. This could possibly be overriden by a property (again for debugging). Joachim On 20.03.2006, at 20:21, Trent Jarvi wrote: > On Mon, 20 Mar 2006, Joachim Buechse wrote: > >> Hi Trent, >> >> What is your general feeling about moving code to Java? The last >> days I have been reading quite a bit of the code and there are >> several things, that might not work as expected. >> >> I'll give you two examples from is_device_locked: >> >> if LOCKDIR == /var/spool/locks the directory /var/spool/lock will >> not be checked. >> LOCKDIR is not checked for lockfiles with unexpected pefixes >> >> While these things have probably never been discovered in >> production, they are still possibly incorrect implementations. If >> it was Java code, I would write some unit tests producing the >> errors that could later be corrected. >> >> PS: One could imagine to actually implement the whole lockfile >> handling in Java using some native routines to get the values >> required (pid, st_dev, st_rdev, ...). > > Hi Joachim > > I like the idea of moving more of the code into java but there are > some things to consider. > > If you break this into multiple JNI calls, the performance will > drop considerably during enumeration of ports. We are looking for > 256 ports per dev type vs (16? in Sun's 2.0 and fewer types). Its > hard to make assumptions. I've seen virtual ports start at /dev/ > foo100 for instance. > > It works out to over 7500 ports on Linux if you enable them all. > We already trim that back by default. See Linux-all-ports in > RXTXCommDriver.java. > > There are also native libraries that rxtx can link to. If you move > too much into Java, linking to 'standard' libraries with distros > will break. "configure --enable-liblock=yes" will not be doable. > This is probably a favorable way with RedHat, Debian, Suse and > others. Thats the right thing to do if there will be rpms, dpkg, .. > > For those reasons, I think it still make sense to keep it to a > minimal ~3 calls to JNI code that we can use for speed and > versatility. lock() isLocked(), unlock() perhaps. When I say > speed, its more about avoiding crossing the JNI layer multiple > times than java vs C performance. With versatility I think liblock > is the right way for most but not all (embeded) linux distros. > > -- > Trent Jarvi > tjarvi at qbang.org > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Mon Mar 20 12:44:47 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 20 Mar 2006 12:44:47 -0700 (MST) Subject: [Rxtx] BUG: Lock file stays even if port opening fails In-Reply-To: <82C19FE7-DDCB-45B6-B2C9-7606B66F0124@buechse.de> References: <82C19FE7-DDCB-45B6-B2C9-7606B66F0124@buechse.de> Message-ID: On Mon, 20 Mar 2006, Joachim Buechse wrote: > Ok, what about providing a default implementation in Java? > > The RXTXCommDriver would call a (native) function useNativeLocking and if > it returns true, call the native functions for lock() isLocked(), > unlock(), else is would use the Java based default implementation. This > could possibly be overriden by a property (again for debugging). > Hi Joachim That would be OK with me. -- Trent Jarvi tjarvi at qbang.org From dmarkman at mac.com Mon Mar 20 22:27:45 2006 From: dmarkman at mac.com (Dmitry Markman) Date: Tue, 21 Mar 2006 00:27:45 -0500 Subject: [Rxtx] binaries request Message-ID: <42702213-C222-4937-A585-7CFB17E47608@mac.com> Hi can somebody send me latest linux and windows binaries, please? or where I can find them (I didn't find them in the latest tareball) I gave up with my cygwin: something wrong I have no idea what java doesn't understand /cygwin/c syntax after I changed makefile it did java part but after that gcc 3.4.4 started to complain I set buffer length to 999 lines but I didn't get beginning of the story something wrong with my 1.4.2_09/include/jni.h gcc doesn't like it anyway I gave up thanks in advance Dmitry Markman -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060320/f8cbc57c/attachment-0034.html From tjarvi at qbang.org Mon Mar 20 22:36:48 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 20 Mar 2006 22:36:48 -0700 (MST) Subject: [Rxtx] binaries request In-Reply-To: <42702213-C222-4937-A585-7CFB17E47608@mac.com> References: <42702213-C222-4937-A585-7CFB17E47608@mac.com> Message-ID: On Tue, 21 Mar 2006, Dmitry Markman wrote: > Hi > can somebody send me latest linux and windows binaries, please? > > or where I can find them (I didn't find them in the latest tareball) > > I gave up with my cygwin: something wrong I have no idea what > java doesn't understand /cygwin/c syntax > after I changed makefile it did java part > but after that gcc 3.4.4 started to complain > I set buffer length to 999 lines but I didn't get beginning of the story > something wrong with my 1.4.2_09/include/jni.h gcc doesn't like it > anyway I gave up > > thanks in advance > Hi Dmitry The bins are here: ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7-bins-r2.zip Here are the files in the zip you want. Jar: rxtx-2.1-7-bins-r2/RXTXcomm.jar Windows: rxtx-2.1-7-bins-r2/Windows/i368-mingw32/rxtxSerial.dll Linux (x86) rxtx-2.1-7-bins-r2/Linux/i686-unknown-linux-gnu/librxtxSerial.so There are others in there including Parallel port support but those are the main ones for testing. -- Trent Jarvi tjarvi at qbang.org From dmarkman at mac.com Mon Mar 20 23:05:59 2006 From: dmarkman at mac.com (Dmitry Markman) Date: Tue, 21 Mar 2006 01:05:59 -0500 Subject: [Rxtx] binaries request In-Reply-To: References: <42702213-C222-4937-A585-7CFB17E47608@mac.com> Message-ID: thank you very much but windows's readme says: rxtxSerial.dll had to be recomopiled to link in missing native methods. should I ignore it? or what? thanks again also I understand that I should use mingw not cygwin I'll try to install mingw On Mar 21, 2006, at 12:36 AM, Trent Jarvi wrote: > On Tue, 21 Mar 2006, Dmitry Markman wrote: > >> Hi >> can somebody send me latest linux and windows binaries, please? >> >> or where I can find them (I didn't find them in the latest tareball) >> >> I gave up with my cygwin: something wrong I have no idea what >> java doesn't understand /cygwin/c syntax >> after I changed makefile it did java part >> but after that gcc 3.4.4 started to complain >> I set buffer length to 999 lines but I didn't get beginning of the >> story >> something wrong with my 1.4.2_09/include/jni.h gcc doesn't like it >> anyway I gave up >> >> thanks in advance >> > > Hi Dmitry > > The bins are here: > > ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7-bins-r2.zip > > Here are the files in the zip you want. > > Jar: > > rxtx-2.1-7-bins-r2/RXTXcomm.jar > > Windows: > > rxtx-2.1-7-bins-r2/Windows/i368-mingw32/rxtxSerial.dll > > Linux (x86) > > rxtx-2.1-7-bins-r2/Linux/i686-unknown-linux-gnu/librxtxSerial.so > > There are others in there including Parallel port support but those > are the main ones for testing. > > -- > Trent Jarvi > tjarvi at qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx Dmitry Markman From tjarvi at qbang.org Mon Mar 20 23:20:33 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 20 Mar 2006 23:20:33 -0700 (MST) Subject: [Rxtx] binaries request In-Reply-To: References: <42702213-C222-4937-A585-7CFB17E47608@mac.com> Message-ID: On Tue, 21 Mar 2006, Dmitry Markman wrote: > thank you very much > > but windows's readme says: > rxtxSerial.dll had to be recomopiled to link in missing native methods. > > should I ignore it? or what? > Hi Dmitry That dll should be OK. r2 is the recompile linked to the missing native method. The readme explains why it was recompiled; fuser.o was not linked into the dll in the first release. -- Trent Jarvi tjarvi at qbang.org From ariantristan at yahoo.com Mon Mar 20 23:55:24 2006 From: ariantristan at yahoo.com (Lambok Sianturi) Date: Mon, 20 Mar 2006 22:55:24 -0800 (PST) Subject: [Rxtx] jvm issue Message-ID: <20060321065524.94779.qmail@web50701.mail.yahoo.com> Hi All, This is my first time to join RxTx mailing list. I thank you all for allowing others to sign in in requests help. I use the latest RxTx lib in Fedora 3 with java version 1.4.2_09 b05. And I got this error: # # An unexpected error has been detected by HotSpot Virtual Machine: # # SIGSEGV (0xb) at pc=0x00bf27f3, pid=2633, tid=3086112448 # # Java VM: Java HotSpot(TM) Client VM (1.4.2_09-b05 mixed mode) # Problematic frame: # C [ld-linux.so.2+0xa7f3] # # An error report file with more information is saved as hs_err_pid2633.log # # If you would like to submit a bug report, please visit: # http://java.sun.com/webapps/bugreport/crash.jsp # ./run.sh: line 3: 2633 Aborted /usr/local/java/bin/java -Djava.library.path=/usr/local/java/jre/lib/ -Djsmsengine.debug=true -classpath jsmsengine.jar:smsgateway.jar:classes12.jar:RXTXcomm.jar:. com.api.sms.SMSServer What is the jvm depedency for the latest library? Can I use 1.4.2_09 b05? Thanks in advance. Arian --------------------------------- Yahoo! Mail Use Photomail to share photos without annoying attachments. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060320/83d58dd7/attachment-0034.html From f.frumento at ngi.it Tue Mar 21 00:21:47 2006 From: f.frumento at ngi.it (Fabio Frumento) Date: Tue, 21 Mar 2006 08:21:47 +0100 Subject: [Rxtx] Javadoc on the go Message-ID: <441FA98B.9050701@ngi.it> Hi Trent, sorry for the big delay but my job is running wild, i was out for some time but now i'm back and ready to continue the javadoc for Rxtx. Did you used the last javadoc patch i sent you ? let me know if i have to send it to you again or not. regards Fabio From lyon at docjava.com Tue Mar 21 00:51:18 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Tue, 21 Mar 2006 02:51:18 -0500 Subject: [Rxtx] lock files Message-ID: Hi All, You know, if the use of lock files were under Java control (rather than a build-time decision), it might enable a more unified binary distro. It might also facilitate quick prototyping of non-lock file approaches to resolving serial port contention issues (i.e., mac-like approaches vs. linux approaches, etc.). I realize that this is a radical overhaul of the lock file policy issue. Also, it may harm performance. On the other hand, our benchmarks on JNI overhead for modern processors indicate performance impact should be minimal. Perhaps it is more of an issue with the toybox systems. Suppose there were a class with a reasonable default...someone might write: SerialPortLockPolicy.setPolicy(SerialPortLockPolicy.UNIX_LOCK_FILE); SerialPortLockPolicy.setPolicy(SerialPortLockPolicy.NO_LOCK_CHECKING); SerialPortLockPolicy.setPolicy(SerialPortLockPolicy.MAC_STYLE); Thus, we could have a run-time reconfiguration of the serial port lock policy. A special NO_LOCK version of the binary would no longer be required. Any thoughts on this? Thanks! - Doug From joachim at buechse.de Tue Mar 21 03:09:09 2006 From: joachim at buechse.de (Joachim Buechse) Date: Tue, 21 Mar 2006 11:09:09 +0100 Subject: [Rxtx] lock files In-Reply-To: References: Message-ID: <8E12916A-1B9A-4FF2-B684-E2D1C794221B@buechse.de> This is pretty much what I thought about when I suggested, that the default behaviour could be overwritten with a property. I am very much in favor of this approach. In particular this allows much easier debugging for PC based java developers. I think big parts of the Java (and maybe some parts of the C code) could use a bit of a structural workover (unit tests, javadoc, synchronization, etc). Maybe there should be a CVS branch for this experimental version. I'd be happy to contribute a first workover for some of the Java code. Designing for testability and implementing a good bunch of unit tests has been a strategy that worked quite well in the Java projects I lead. And it ultimately allows more liberal change permission. Regards, Joachim On 21.03.2006, at 08:51, Dr. Douglas Lyon wrote: > Hi All, > You know, if the use of lock files were > under Java control (rather than a build-time decision), > it might enable a more unified binary distro. It might also > facilitate quick prototyping of non-lock file approaches > to resolving serial port contention issues (i.e., mac-like > approaches vs. linux approaches, etc.). > > I realize that this is a radical overhaul of the lock file policy > issue. Also, it may harm performance. On the other hand, > our benchmarks on JNI overhead for modern processors indicate > performance impact should be minimal. Perhaps it is more of > an issue with the toybox systems. > > Suppose there were a class with a reasonable default...someone > might write: > SerialPortLockPolicy.setPolicy(SerialPortLockPolicy.UNIX_LOCK_FILE); > SerialPortLockPolicy.setPolicy(SerialPortLockPolicy.NO_LOCK_CHECKING); > SerialPortLockPolicy.setPolicy(SerialPortLockPolicy.MAC_STYLE); > > Thus, we could have a run-time reconfiguration of the serial port lock > policy. A special NO_LOCK version of the binary would no longer > be required. > > Any thoughts on this? > > Thanks! > - Doug > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From joachim at buechse.de Tue Mar 21 06:23:08 2006 From: joachim at buechse.de (Joachim Buechse) Date: Tue, 21 Mar 2006 14:23:08 +0100 Subject: [Rxtx] PATCH: use of ioctl(fd, TIOCEXCL) instead of lockfiles Message-ID: <923AE774-EEA2-4911-92D8-32BB27802C8B@buechse.de> Here is the patch for the ioctl(fd, TIOCEXCL). I have verified this only for OSX 10.4.5, hence it is only defined for APPLE. However, it should work at least for Solaris as well. If a process has requested TIOEXCL further open calls by other user processes will fail. The patch also disables uucp style locking for APPLE. Obviously this is discussable. I think it is the way to go, as it eliminates creating the lock directory which doesnt exist on the standard installation and it eliminates messing with the system group definitions (adding users to group uucp). Regarding the possibility of root processes opening a device which is locked - I consider this a feature not a potential problem. It is highly unlikely, that somebody is crazy enough to run a JavaVM as root (unless he has no other means of getting a restricted IP port opened, ie doesnt understand ipfw). Anyway, even if the process runs as root, it fails when calling ioctl(fd, TIOCEXCL). It could however still open the port to listen for RING events. I.e. a fax server which needs to see incoming calls but otherwise doesnt want to block the port. So the only case where the proposed mechanism fails is, if an incorrectly implemented process running as root conflicts with a user process. I think this can be accepted. Regards, Joachim PS: If this patch is generally accepted, the installer and Mac doku should obviously be changed as well. Index: SerialImp.c =================================================================== RCS file: /usr/local/cvsroot/rxtx-devel/src/SerialImp.c,v retrieving revision 1.46.2.187 diff -u -r1.46.2.187 SerialImp.c --- SerialImp.c 29 Jan 2006 22:19:04 -0000 1.46.2.187 +++ SerialImp.c 21 Mar 2006 12:59:16 -0000 @@ -656,6 +656,25 @@ fd=OPEN (filename, O_RDWR | O_NOCTTY | O_NONBLOCK ); } while (fd < 0 && errno==EINTR); +#ifdef OPEN_EXCL + // Note that open() follows POSIX semantics: multiple open() calls to + // the same file will succeed unless the TIOCEXCL ioctl is issued. + // This will prevent additional opens except by root-owned processes. + // See tty(4) ("man 4 tty") and ioctl(2) ("man 2 ioctl") for details. + + if (fd >= 0 && (ioctl(fd, TIOCEXCL) == -1)) + { + sprintf( message, "open: exclusive access denied for % s\n", + filename ); + report( message ); + report_error( message ); + + close(fd); + goto fail; + } +#endif /* OPEN_EXCL */ + + if( configure_port( fd ) ) goto fail; (*env)->ReleaseStringUTFChars( env, jstr, filename ); sprintf( message, "open: fd returned is %i\n", fd ); Index: SerialImp.h =================================================================== RCS file: /usr/local/cvsroot/rxtx-devel/src/SerialImp.h,v retrieving revision 1.11.2.49 diff -u -r1.11.2.49 SerialImp.h --- SerialImp.h 5 Jul 2005 17:47:21 -0000 1.11.2.49 +++ SerialImp.h 21 Mar 2006 12:59:17 -0000 @@ -135,7 +135,8 @@ /*# define LOCKDIR "/var/spool/uucp"*/ # define LOCKDIR "/var/lock" # define LOCKFILEPREFIX "LK." -# define UUCP +/*# define UUCP*/ +# define OPEN_EXCL #endif /* __APPLE__ */ #if defined(__NetBSD__) # define DEVICEDIR "/dev/" From tjarvi at qbang.org Tue Mar 21 10:26:08 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 21 Mar 2006 10:26:08 -0700 (MST) Subject: [Rxtx] Javadoc on the go In-Reply-To: <441FA98B.9050701@ngi.it> References: <441FA98B.9050701@ngi.it> Message-ID: On Tue, 21 Mar 2006, Fabio Frumento wrote: > Hi Trent, > > sorry for the big delay but my job is running wild, i was out for some > time but now i'm back and ready to continue the javadoc for Rxtx. > > Did you used the last javadoc patch i sent you ? let me know if i have to > send it to you again or not. > > regards > > Fabio Hi Fabio The patch is in the rxtx mail-list archives. It will be going in soon. I did not see a time critical portion. I'll probably be going through the list since the last batch of patches this weekend and putting them into CVS. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Tue Mar 21 10:57:18 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 21 Mar 2006 10:57:18 -0700 (MST) Subject: [Rxtx] jvm issue In-Reply-To: <20060321065524.94779.qmail@web50701.mail.yahoo.com> References: <20060321065524.94779.qmail@web50701.mail.yahoo.com> Message-ID: On Mon, 20 Mar 2006, Lambok Sianturi wrote: > Hi All, > This is my first time to join RxTx mailing list. I thank you all for allowing others to sign in in requests help. > I use the latest RxTx lib in Fedora 3 with java version 1.4.2_09 b05. And I got this error: > > # > # An unexpected error has been detected by HotSpot Virtual Machine: > # > # SIGSEGV (0xb) at pc=0x00bf27f3, pid=2633, tid=3086112448 > # > # Java VM: Java HotSpot(TM) Client VM (1.4.2_09-b05 mixed mode) > # Problematic frame: > # C [ld-linux.so.2+0xa7f3] A native library loading error? What happens if you recompile rxtx on your system and install that? This sounds like an ABI problem? rxtx 2.1-7 was compiled with a gcc 2.96 toolchain as I recall. The hope is newer system will be backwards compatible. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Tue Mar 21 11:05:29 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 21 Mar 2006 11:05:29 -0700 (MST) Subject: [Rxtx] PATCH: use of ioctl(fd, TIOCEXCL) instead of lockfiles In-Reply-To: <923AE774-EEA2-4911-92D8-32BB27802C8B@buechse.de> References: <923AE774-EEA2-4911-92D8-32BB27802C8B@buechse.de> Message-ID: On Tue, 21 Mar 2006, Joachim Buechse wrote: > Here is the patch for the ioctl(fd, TIOCEXCL). I have verified this only > for OSX 10.4.5, hence it is only defined for APPLE. However, it should > work at least for Solaris as well. > > If a process has requested TIOEXCL further open calls by other user > processes will fail. > > The patch also disables uucp style locking for APPLE. Obviously this is > discussable. I think it is the way to go, as it eliminates creating the > lock directory which doesnt exist on the standard installation and it > eliminates messing with the system group definitions (adding users to > group uucp). > > Regarding the possibility of root processes opening a device which is > locked - I consider this a feature not a potential problem. It is highly > unlikely, that somebody is crazy enough to run a JavaVM as root (unless > he has no other means of getting a restricted IP port opened, ie doesnt > understand ipfw). Anyway, even if the process runs as root, it fails when > calling ioctl(fd, TIOCEXCL). It could however still open the port to > listen for RING events. I.e. a fax server which needs to see incoming > calls but otherwise doesnt want to block the port. So the only case where > the proposed mechanism fails is, if an incorrectly implemented process > running as root conflicts with a user process. I think this can be > accepted. > > Regards, > Joachim > > PS: If this patch is generally accepted, the installer and Mac doku > should obviously be changed as well. > > > Index: SerialImp.c > =================================================================== > RCS file: /usr/local/cvsroot/rxtx-devel/src/SerialImp.c,v > retrieving revision 1.46.2.187 > diff -u -r1.46.2.187 SerialImp.c > --- SerialImp.c 29 Jan 2006 22:19:04 -0000 1.46.2.187 > +++ SerialImp.c 21 Mar 2006 12:59:16 -0000 > @@ -656,6 +656,25 @@ > fd=OPEN (filename, O_RDWR | O_NOCTTY | O_NONBLOCK ); > } while (fd < 0 && errno==EINTR); > > +#ifdef OPEN_EXCL > + // Note that open() follows POSIX semantics: multiple open() > calls to > + // the same file will succeed unless the TIOCEXCL ioctl is > issued. > + // This will prevent additional opens except by root-owned > processes. > + // See tty(4) ("man 4 tty") and ioctl(2) ("man 2 ioctl") for > details. > + > + if (fd >= 0 && (ioctl(fd, TIOCEXCL) == -1)) > + { > + sprintf( message, "open: exclusive access denied for % > s\n", > + filename ); > + report( message ); > + report_error( message ); > + > + close(fd); > + goto fail; > + } > +#endif /* OPEN_EXCL */ > + > + > if( configure_port( fd ) ) goto fail; > (*env)->ReleaseStringUTFChars( env, jstr, filename ); > sprintf( message, "open: fd returned is %i\n", fd ); > Index: SerialImp.h > =================================================================== > RCS file: /usr/local/cvsroot/rxtx-devel/src/SerialImp.h,v > retrieving revision 1.11.2.49 > diff -u -r1.11.2.49 SerialImp.h > --- SerialImp.h 5 Jul 2005 17:47:21 -0000 1.11.2.49 > +++ SerialImp.h 21 Mar 2006 12:59:17 -0000 > @@ -135,7 +135,8 @@ > /*# define LOCKDIR "/var/spool/uucp"*/ > # define LOCKDIR "/var/lock" > # define LOCKFILEPREFIX "LK." > -# define UUCP > +/*# define UUCP*/ > +# define OPEN_EXCL > #endif /* __APPLE__ */ > #if defined(__NetBSD__) > # define DEVICEDIR "/dev/" > This looks like a good start. What do you think Dmitry? Perhaps all systems with TIOCEXCL defined should use that though. Even if they use lockfiles. It wont hurt anything. That would catch people hacking their own serial apps without checking lockfiles. Its a good idea to avoid C++ style comments in the C portions. Some older systems don't deal with them well. If it's just for Mac OS X, it isn't a big deal. I think it was the Irix compiler that was problematic? -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Tue Mar 21 11:22:05 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 21 Mar 2006 11:22:05 -0700 (MST) Subject: [Rxtx] lock files In-Reply-To: <8E12916A-1B9A-4FF2-B684-E2D1C794221B@buechse.de> References: <8E12916A-1B9A-4FF2-B684-E2D1C794221B@buechse.de> Message-ID: We can try it. Maybe the JNI is much improved. The nice thing about linking into liblock is distros then worry about lockfiles on their systems. This way, we have to deal with any changes that may show up. On Tue, 21 Mar 2006, Joachim Buechse wrote: > This is pretty much what I thought about when I suggested, that the > default behaviour could be overwritten with a property. I am very much in > favor of this approach. In particular this allows much easier debugging > for PC based java developers. > > I think big parts of the Java (and maybe some parts of the C code) could > use a bit of a structural workover (unit tests, javadoc, synchronization, > etc). Maybe there should be a CVS branch for this experimental version. > I'd be happy to contribute a first workover for some of the Java code. > Designing for testability and implementing a good bunch of unit tests has > been a strategy that worked quite well in the Java projects I lead. And > it ultimately allows more liberal change permission. > > Regards, > Joachim > > > On 21.03.2006, at 08:51, Dr. Douglas Lyon wrote: > >> Hi All, >> You know, if the use of lock files were >> under Java control (rather than a build-time decision), >> it might enable a more unified binary distro. It might also >> facilitate quick prototyping of non-lock file approaches >> to resolving serial port contention issues (i.e., mac-like >> approaches vs. linux approaches, etc.). >> >> I realize that this is a radical overhaul of the lock file policy >> issue. Also, it may harm performance. On the other hand, >> our benchmarks on JNI overhead for modern processors indicate >> performance impact should be minimal. Perhaps it is more of >> an issue with the toybox systems. >> >> Suppose there were a class with a reasonable default...someone >> might write: >> SerialPortLockPolicy.setPolicy(SerialPortLockPolicy.UNIX_LOCK_FILE); >> SerialPortLockPolicy.setPolicy(SerialPortLockPolicy.NO_LOCK_CHECKING); >> SerialPortLockPolicy.setPolicy(SerialPortLockPolicy.MAC_STYLE); >> >> Thus, we could have a run-time reconfiguration of the serial port lock >> policy. A special NO_LOCK version of the binary would no longer >> be required. >> >> Any thoughts on this? >> >> Thanks! >> - Doug >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From dmarkman at mac.com Tue Mar 21 16:05:17 2006 From: dmarkman at mac.com (Dmitry Markman) Date: Tue, 21 Mar 2006 18:05:17 -0500 Subject: [Rxtx] PATCH: use of ioctl(fd, TIOCEXCL) instead of lockfiles In-Reply-To: References: <923AE774-EEA2-4911-92D8-32BB27802C8B@buechse.de> Message-ID: <512AC70C-BB86-48F2-A83C-023F35C23BAB@mac.com> I think it's cool, but I'd like to have that property implementation when user can choose between locking mechanism about comments: it's easy to change comments to the C style or we can use extensions of the file to cpp so c++ compiler will be used On Mar 21, 2006, at 1:05 PM, Trent Jarvi wrote: > This looks like a good start. What do you think Dmitry? Perhaps > all systems with TIOCEXCL defined should use that though. Even if > they use lockfiles. It wont hurt anything. That would catch > people hacking their own serial apps without checking lockfiles. > > Its a good idea to avoid C++ style comments in the C portions. > Some older systems don't deal with them well. If it's just for Mac > OS X, it isn't a big deal. I think it was the Irix compiler that > was problematic? Dmitry Markman From dmarkman at mac.com Tue Mar 21 16:13:00 2006 From: dmarkman at mac.com (Dmitry Markman) Date: Tue, 21 Mar 2006 18:13:00 -0500 Subject: [Rxtx] PATCH: use of ioctl(fd, TIOCEXCL) instead of lockfiles In-Reply-To: References: <923AE774-EEA2-4911-92D8-32BB27802C8B@buechse.de> Message-ID: I'd like to add that creating locking folder isn't a big deal we never had a problem related to the lock folders, because we always used installer on mac os x from other hand I'm not very much familiar with iotcl locking approach and I'm not sure it's more efficient Joachim wrote "I think it is the way to go, as it eliminates creating the lock directory which doesnt exist on the standard installation and it eliminates messing with the system group definitions (adding users to group uucp)." but I really didn't have any problem with that 1. doesn't exist on the standard installation there are many-many things that don't exist in the standard installation so I don't think that argument is strong enough 2. messing with the system group definitions I don't think we're messing with the group definition mac os x provides very clear way to set up group's members and together with Greg Guerin AuthKit there is no problem to set those definitions so I don't think that argument is strong either but from other hand using iotcl is more promising and is more elegant On Mar 21, 2006, at 1:05 PM, Trent Jarvi wrote: > > This looks like a good start. What do you think Dmitry? Perhaps > all systems with TIOCEXCL defined should use that though. Even if > they use lockfiles. It wont hurt anything. That would catch > people hacking their own serial apps without checking lockfiles. Dmitry Markman From joachim at buechse.de Wed Mar 22 04:46:45 2006 From: joachim at buechse.de (Joachim Buechse) Date: Wed, 22 Mar 2006 12:46:45 +0100 Subject: [Rxtx] PATCH: use of ioctl(fd, TIOCEXCL) instead of lockfiles In-Reply-To: References: <923AE774-EEA2-4911-92D8-32BB27802C8B@buechse.de> Message-ID: Sorry, I was not very clear with my arguments, so I will try again;-) Please, don't take this as an attack against work that has been done. I think the contributions that have been made in the past were made in a good spirit. But I really believe, that the current solution for OSX has many shortcomings and should be changed as soon as possible. lock files --- The /var/lock folder does not exist on the standard OSX installation, however the standard installation includes several applications that use serial ports (i.e. the FAX capability). This indicates, that the lock folder approach will not work well with system components. Applications for OSX will generally try to live in harmony with system components (except for HP print drivers of course). I think RXTX should follow this approach as well. uucp group --- Accessing serial ports is not an admin privileged operation on OSX. Any user (world) has read/write privileges on /dev/tty*. So the system default is to not enforce any group membership to access these ports. The group uucp however is a system group on all unix systems I know. It exists for certain system processes. A non admin user should in general not be a member of this group. Quite arguably no user should ever be a member of this group. Installer --- My general opinion is, that - no Installer should touch user or group data without warning - no Application Installer should touch groups which are not specific to the very application installed - no Installer should ever add regular users to a system group The current installer injects the installing user in the group uucp without warning about this change and without giving the option to "opt out" of this change. This is a potential security risk (but not currently a real one, as OSX contains no folders belonging to group uucp). The current installer does not work for multi user systems. It puts the installing user in the uucp group. However the installing user is not necessarily the user that will use the application. Putting all users that may use a serial port application in the system group uucp seems like a very invasive approach to me. Besides that, newly created users will not automatically be in the group and hence, serial applications will "break" for new users without obvious reasons. Avoiding the lock files will allow self contained applications (i.e. drag&drop installation). In my eyes this is largely preferable over an installer that requests admin privileges. Adding up all these points indicates very strongly, that the lock-file implementation is not the way to go on OSX. Regards, Joachim On 22.03.2006, at 00:13, Dmitry Markman wrote: > I'd like to add that > > creating locking folder isn't a big deal > we never had a problem related to the lock folders, because we > always used installer on mac os x > from other hand I'm not very much familiar with iotcl locking > approach and I'm not sure it's more efficient > > Joachim wrote "I think it is the way to go, as it eliminates > creating the lock directory which doesnt exist on the standard > installation and it eliminates messing with the system group > definitions (adding users to group uucp)." but I really didn't have > any problem with that > > 1. doesn't exist on the standard installation > there are many-many things that don't exist in the standard > installation so I don't think that argument is strong enough > 2. messing with the system group definitions > I don't think we're messing with the group definition > mac os x provides very clear way to set up group's members and > together with Greg Guerin AuthKit there is no problem to set those > definitions > so I don't think that argument is strong either > but from other hand using iotcl is more promising and is more elegant > > > > On Mar 21, 2006, at 1:05 PM, Trent Jarvi wrote: > >> >> This looks like a good start. What do you think Dmitry? Perhaps >> all systems with TIOCEXCL defined should use that though. Even if >> they use lockfiles. It wont hurt anything. That would catch >> people hacking their own serial apps without checking lockfiles. > > Dmitry Markman > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From dmarkman at mac.com Wed Mar 22 05:27:13 2006 From: dmarkman at mac.com (Dmitry Markman) Date: Wed, 22 Mar 2006 07:27:13 -0500 Subject: [Rxtx] PATCH: use of ioctl(fd, TIOCEXCL) instead of lockfiles In-Reply-To: References: <923AE774-EEA2-4911-92D8-32BB27802C8B@buechse.de> Message-ID: <83440CF3-DCD8-41C1-B941-F227232C27E3@mac.com> thanks for the very good explanation I didn't think that you were attacking any thing, so don't worry I just had feeling, that there were more aesthetic reasons for going to ioctl then real necessity now you explained everything quite well (BTW, asfar as I remember installer asks admin password so it wasn't quiet, but it really doesn't matter now) thanks On Mar 22, 2006, at 6:46 AM, Joachim Buechse wrote: > Sorry, I was not very clear with my arguments, so I will try again;-) > > Please, don't take this as an attack against work that has been > done. I think the contributions that have been made in the past > were made in a good spirit. But I really believe, that the current > solution for OSX has many shortcomings and should be changed as > soon as possible. > > lock files > --- > The /var/lock folder does not exist on the standard OSX > installation, however the standard installation includes several > applications that use serial ports (i.e. the FAX capability). This > indicates, that the lock folder approach will not work well with > system components. Applications for OSX will generally try to live > in harmony with system components (except for HP print drivers of > course). I think RXTX should follow this approach as well. > > uucp group > --- > Accessing serial ports is not an admin privileged operation on OSX. > Any user (world) has read/write privileges on /dev/tty*. So the > system default is to not enforce any group membership to access > these ports. The group uucp however is a system group on all unix > systems I know. It exists for certain system processes. A non admin > user should in general not be a member of this group. Quite > arguably no user should ever be a member of this group. > > Installer > --- > My general opinion is, that > - no Installer should touch user or group data without warning > - no Application Installer should touch groups which are not > specific to the very application installed > - no Installer should ever add regular users to a system group > > The current installer injects the installing user in the group uucp > without warning about this change and without giving the option to > "opt out" of this change. This is a potential security risk (but > not currently a real one, as OSX contains no folders belonging to > group uucp). > > The current installer does not work for multi user systems. It puts > the installing user in the uucp group. However the installing user > is not necessarily the user that will use the application. Putting > all users that may use a serial port application in the system > group uucp seems like a very invasive approach to me. Besides that, > newly created users will not automatically be in the group and > hence, serial applications will "break" for new users without > obvious reasons. > > > Avoiding the lock files will allow self contained applications > (i.e. drag&drop installation). In my eyes this is largely > preferable over an installer that requests admin privileges. Adding > up all these points indicates very strongly, that the lock-file > implementation is not the way to go on OSX. > > Regards, > Joachim > > > On 22.03.2006, at 00:13, Dmitry Markman wrote: > >> I'd like to add that >> >> creating locking folder isn't a big deal >> we never had a problem related to the lock folders, because we >> always used installer on mac os x >> from other hand I'm not very much familiar with iotcl locking >> approach and I'm not sure it's more efficient >> >> Joachim wrote "I think it is the way to go, as it eliminates >> creating the lock directory which doesnt exist on the standard >> installation and it eliminates messing with the system group >> definitions (adding users to group uucp)." but I really didn't >> have any problem with that >> >> 1. doesn't exist on the standard installation >> there are many-many things that don't exist in the standard >> installation so I don't think that argument is strong enough >> 2. messing with the system group definitions >> I don't think we're messing with the group definition >> mac os x provides very clear way to set up group's members and >> together with Greg Guerin AuthKit there is no problem to set those >> definitions >> so I don't think that argument is strong either >> but from other hand using iotcl is more promising and is more elegant >> >> >> >> On Mar 21, 2006, at 1:05 PM, Trent Jarvi wrote: >> >>> >>> This looks like a good start. What do you think Dmitry? Perhaps >>> all systems with TIOCEXCL defined should use that though. Even >>> if they use lockfiles. It wont hurt anything. That would catch >>> people hacking their own serial apps without checking lockfiles. >> >> Dmitry Markman >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx Dmitry Markman From lyon at docjava.com Wed Mar 22 06:12:18 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Wed, 22 Mar 2006 08:12:18 -0500 Subject: [Rxtx] sole of a new design pattern Message-ID: Hi All, I have been thinking about how we design the serial port software. I think we need a new design pattern. For lack of a better term, I shall call it: The Parametric Singleton Design Pattern By Douglas A. Lyon ABSTRACT The goal of the singleton design pattern is to make sure that there is one, and only one, instance of a given class. The goal of the parametric singleton design pattern is to make sure that there is one, and only one, instance of a given class with the given parametric values. We parametric singleton design pattern combines the singleton design pattern with a parameter that enables unique creation of instances of a class. These instances are cached. When a user asks for an instance with these parameters, the cache is checked. If the instance is in the cache, the instance is returned, otherwise it is created, added to the cache and then returned. We apply our parametric singleton design pattern to the retrieval of RMI registries bound to a given port. The goal of our system is to make sure that no two RMI registries are listening to the same socket and to make use of the RMI registries after they have been created. RMI registries are used in distributed computation. Introduction The singleton design pattern is meant to ensure that on a single instance of a class exists. It is also meant to provide a global point of access to it. The intent of the parametric singleton design pattern is to ensure that a class has only one instance for a given set of parameter values. It also provides a global point of access to it. Motivation A system cannot tolerate multiple instances of some classes with identical parameters. For example, you cannot have two instances making use of the same serial port, at the same time. You cannot have two instances that are trying to listen to the same socket connection. You cannot have two instances writing to the same file structure at the same time. As the operating system is often thought of as the arbiter of consumed resources (i.e., tape drives, serial ports, etc.) we frequently leave it to an operating system implementation to resolve these contention issues. Even for similar resources (like serial ports) there are few standards for handling contention. For example, serial ports on Linux are locked using a "/var/lock" file. POSIX, on the other hand, uses ioctl mechanisms to prevent contention. A better solution is to make a class that is responsible for keeping track of the instances created from the class. The class is declared final, so that it cannot be subclassed. The class also has a private constructor, so that other classes cannot instance it. The new design pattern is called the parametric singleton design pattern and it provides a way to access and create instances with given parameters. Applicability Use the Parametric Singleton Design Pattern when: 1. There must be exactly one instance of a class with the given parameters. 2. The instances must be accessible to clients from a well-known access point. Structure Insert UML diagram here. Participants The Parametric Singleton Clients that need instances 1. The Parametric Singleton defines an instance upon request from a client, if, and only if, the instance does not already exist. 2. The Parametric Singleton returns the instance to the client. 3. The Parametric Singleton is responsible for creating unique instances from given parameters. Collaborations Clients obtain a reference to a Parametric Singleton instance only through the parametric singleton design pattern. If the instance is left in an improper state (e.g., the serial port was left open) it is NOT the role of the Parametric Singleton Design Pattern to close the IO port. Nor is it the role of the Parametric Singleton Design Pattern to open the port. That role is delegate to some other part of the system. Further, it is not the role of the Parametric Singleton Design Pattern to check out resources. That is, multiple threads can have multiple references to the same resource at the same time. MUTEX locking is delegated to some other part of the system. Consequences The Parametric Singleton Design Pattern has several benefits: 1. Controlled access to parametrically defined instances. Since the Parametric Singleton class encapsulates its instances, there is control over how and when clients access it. 2. Reduced name space. The Parametric Singleton pattern avoids global variables that store instances created from the same parameter. Implementation Here are implementation issues to consider when using the Parametric Singleton pattern: 1. Unique mapping of parameters. The Parametric Singleton pattern requires that there be a mean to isomorphically map the parameter space into the instance space and back again. 2. Ensure unique instances. The Parametric Singleton pattern makes unique instances from parameters, and it does so only once. 3. Cache instances for fast retrieval. The Parametric Singleton pattern must be able to look up instances, given some set of parameters, and do so from some data structure. That is, there must be enough space to hold references to all the instances the program will need. Also, a mechanism is needed to look up and retrieve the instances quickly enough to satisfy the clients. Sample Code public final class ParametricSingletonRmiRegistry { private static Hashtable registry = new Hashtable(100); // use singleton pattern and??????????????????????????????????????????????? // prevent instantiation of RmiRegistryUtils.?????????????????????????????? private ParametricSingletonRmiRegistry() { } // the only instance of the Registry held by the RmiRegistryUtils?????????? public static void listNames(Integer port) { if (!isInCacheAndRunning(port)) return; Registry r = (Registry) registry.get(port); System.out.println("registry on port: " + port); System.out.println("registry: " + r); System.out.println("names: "); try { print(r.list()); } catch (RemoteException e) { In.message(e); } System.out.println("------------------------"); } /**???????????????????????????????????????????????????????????????????????? * Checks whether a Registry has been started on this host????????????????? * in the specified port.?????????????????????????????????????????????????? * If not, it tries to start one.?????????????????????????????????????????? * when it fails to start a Registry, it exits the program????????????????? * with exit code 1.??????????????????????????????????????????????????????? */ public static void restart(int port) { if (isInCacheAndRunning(port)) return; try { startRegistry(port); } catch (RemoteException e) { In.message(e); } } /**???????????????????????????????????????????????????????????????????????? * @param port????????????????????????????????????????????????????????????? * @return true if registry is in cache and running???????????????????????? */ private static boolean isInCacheAndRunning(Integer port) { if (!isRegistryRunning(port.intValue())) return false; if (!isRegistryInCache(port.intValue())) return false; return true; } /**???????????????????????????????????????????????????????????????????????? * @param port????????????????????????????????????????????????????????????? * @return true if we are able to locate a local registry on port.??????????????????????????????????????????????????????????????????????????? */ private static boolean isRegistryRunning(int port) { try { Registry r = LocateRegistry.getRegistry(port); if (r != null) return true; } catch (RemoteException e) { return false; } return false; } /**???????????????????????????????????????????????????????????????????????? * @param port????????????????????????????????????????????????????????????? * @return return true if registry is in cache????????????????????????????? */ private static boolean isRegistryInCache(int port) { if (registry.get(new Integer(port)) == null) return false; return true; } /**???????????????????????????????????????????????????????????????????????? * Restart the registry, if needed.???????????????????????????????????????? * Return the only instance of the registry for consistent global?????????? * using by making use of the Singleton Design Pattern????????????????????? *????????????????????????????????????????????????????????????????????????? * @return the internally held registry instance.?????????????????????????? */ public static Registry getRegistry(Integer port) { restart(port); return (Registry) registry.get(port); } private static void startRegistry(Integer port) throws RemoteException { Registry r; try { r = LocateRegistry.createRegistry(port.intValue()); registry.put(port, r); //r = new sun.rmi.registry.RegistryImpl???????????????????????????? /// (port.intValue());?????????????????????????????????????? // registry.put(port, r);?????????????????????????????????????????? } catch (Exception e) { //e.printStackTrace();????????????????????????????????????????????? r = LocateRegistry.getRegistry(port.intValue()); registry.put(port, r); } } public static void main(String args[]) throws RemoteException { //restart(port);??????????????????????????????????????????????????????? restart(5001); restart(5002); restart(5002); Registry r = LocateRegistry.getRegistry(5002); System.out.println("registry="+r); } } I would very much like to get your feedback on this new design pattern idea. Thank you for your time. Regards, - Doug From david.garnier at trusted-logic.com Wed Mar 22 07:36:10 2006 From: david.garnier at trusted-logic.com (David Garnier) Date: Wed, 22 Mar 2006 15:36:10 +0100 Subject: [Rxtx] sole of a new design pattern In-Reply-To: References: Message-ID: <442160DA.80107@trusted-logic.com> Hello, > The Parametric Singleton Design Pattern The Singleton is the most abused design pattern ever. Good use-cases for this pattern are extremely rare and mostly confined to problems related to hardware resources, like serial ports. > Applicability > > Use the Parametric Singleton Design Pattern when: > 1. There must be exactly one instance of a class with the given > parameters. OK. As I said above, this case this actually very unusual. The Singleton pattern is mostly used when : > 2. The instances must be accessible to clients from a well-known > access point. Using the singleton pattern in this case is just convenient for the programmer. Problems arises pretty quickly, especially if you attempt to unit-test your classes. 1) If your singleton is stateful, or hold on to stateful objects, it means that two different unit tests are not actually independent. Instead of starting with a brand new environment, the result of a test may be affected by the result of a previous test. This problem also arise when with your class relies on a database. In both cases, the solution is to reset your "unique" resource (Singleton or database) at the beginning of the test, which is a pain. Also, while most projects connect to a single database, projects that allow the use of Singletons usually contain several of thems, and new ones may cropped up unnoticed. You quickly end up with test cases that only pass in a certain order, which is a royal pain. 2) You cannot mockup a singleton. Once everyone calls the SomeSingleton class statically, you can't replace your class by SomeSingletonMockup. Furthermore, even for hardware services, the Singleton pattern does not really prevent concurrent accesses. If you start the same program in two different JVMs, unless they somehow shared the state of their "Singletons" (through lock files for example), the Singleton pattern will not prevent concurrent access. Our application uses RXTX, and we routinely encounter cases where another (native) application has already locked the port. Since we cannot modify the native application to recognize lock files, OS-level control is irreplaceable. > > Consequences > The Parametric Singleton Design Pattern has several benefits: > > 1. Controlled access to parametrically defined instances. Since > the Parametric Singleton class encapsulates its instances, there is > control over how and when clients access it. Not really. Once you've returned the instance to a client, you've lost control over it. The client can to whatever it wants with it. You cannot "recall" the instance or claim it back. > 2. Reduced name space. The Parametric Singleton pattern avoids > global variables that store instances created from the same parameter. Sure, but you don't have to rely on a Singleton for that. Just create a single Factory. > I would very much like to get your feedback on this new design > pattern idea. Well, it's nothing new. Some may say that it is the point of design patterns: formalizes the designs that occur again and again. However, this design is simply a combination of the Singleton and Factory patterns. I did use it in the past, but now I've been exposed to the shortcomings of the Singleton pattern, so I limit myself to Factories. Regards, David From sean_montgomery at baseview.com Wed Mar 22 08:35:28 2006 From: sean_montgomery at baseview.com (Sean Montgomery) Date: Wed, 22 Mar 2006 10:35:28 -0500 Subject: [Rxtx] sole of a new design pattern In-Reply-To: <442160DA.80107@trusted-logic.com> References: <442160DA.80107@trusted-logic.com> Message-ID: <05769CA7-A51B-4CF0-BAA0-E02DD905F5A4@baseview.com> On Mar 22, 2006, at 9:36 AM, David Garnier wrote: > Furthermore, even for hardware services, the Singleton pattern does > not really prevent concurrent > accesses. If you start the same program in two different JVMs, > unless they somehow shared the state > of their "Singletons" (through lock files for example), the > Singleton pattern will not prevent > concurrent access. > Multiple class loaders in a single JVM can be tricky, too. Then there's synchronization, lazy initialization and serialization of singletons to contend with. Bloch's Effective Java covers these, and here's a few articles: http://www.javaworld.com/javaworld/jw-04-2003/jw-0425-designpatterns- p3.html http://java.sun.com/developer/technicalArticles/Programming/singletons/ Just FYI :-) From lyon at docjava.com Wed Mar 22 08:50:48 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Wed, 22 Mar 2006 10:50:48 -0500 Subject: [Rxtx] sole of a new design pattern In-Reply-To: <442160DA.80107@trusted-logic.com> References: <442160DA.80107@trusted-logic.com> Message-ID: Hi All, First, I would like to thank David for his prompt and thoughtful remarks. I had no idea people that feel strongly about a design patterns! Wow! Feedback (particularly critical feedback) is greatly appreciated. Starting at the end, first: >I did use it in >the past, but now I've been exposed to the shortcomings of the >Singleton pattern, so I limit myself to Factories. David, if I understood your comments correctly, you suggested that Factories can be used in leu of the Singleton Design Pattern, or even the Parametric Singleton Design Pattern. As I see in [Gof]: Factory Method: Intent "Define an interface for creating an object, but let subclasses decide which class to instantiate. Factory Method lets a class defer instantiation to subclasses." The Singleton Design Pattern is a concrete class, which is rather different, right? Also, subclasses are not permitted with Singleton, as they are final. Naturally, I could use an abstract factory as a parent for a singleton. I could even design a facade that could be implemented with the singleton....but that is not the intention of the design. Unless you want a mock-up, as discussed, below: More below: >Hello, > >> The Parametric Singleton Design Pattern > >The Singleton is the most abused design pattern ever. Good use-cases >for this pattern are extremely >rare and mostly confined to problems related to hardware resources, >like serial ports. > > >> Applicability >> >> Use the Parametric Singleton Design Pattern when: >> 1. There must be exactly one instance of a class with the given >> parameters. >OK. As I said above, this case this actually very unusual. The >Singleton pattern is mostly used when : >> 2. The instances must be accessible to clients from a well-known >> access point. > >Using the singleton pattern in this case is just convenient for the >programmer. Problems arises >pretty quickly, especially if you attempt to unit-test your classes. > >1) If your singleton is stateful, or hold on to stateful objects, it >means that two different unit >tests are not actually independent. Instead of starting with a brand >new environment, the result of >a test may be affected by the result of a previous test. This >problem also arise when with your >class relies on a database. In both cases, the solution is to reset >your "unique" resource >(Singleton or database) at the beginning of the test, which is a >pain. Also, while most projects >connect to a single database, projects that allow the use of >Singletons usually contain several of >thems, and new ones may cropped up unnoticed. You quickly end up >with test cases that only pass in a >certain order, which is a royal pain. There are basic problems with communicating finite state machines that include reachability and deadlock analysis. These are addressed with petri net analysis and are beyond the scope of the design pattern. As you quite rightly pointed out; the parametric singleton pattern (or the singleton pattern, for that matter) enable multiple threads to gain access to the same instance. The only way that I can see to block others from gaining access to the reference is the synchronize keyword. This is putting a spin-lock (or MUTEX) on the reference. The question of how to unit-test a design pattern like the parametric singleton remains open. Perhaps this is a deficiency. > >2) You cannot mockup a singleton. Once everyone calls the >SomeSingleton class statically, you can't >replace your class by SomeSingletonMockup. Acutally, I am not sure that this is true. If the Singleton implements a Facade interface, it should be possible to make the replacement. Right? > >Furthermore, even for hardware services, the Singleton pattern does >not really prevent concurrent >accesses. If you start the same program in two different JVMs, >unless they somehow shared the state >of their "Singletons" (through lock files for example), the >Singleton pattern will not prevent >concurrent access. Good Point!! You have sharp eyes! The singleton design pattern should/could take responsibility for this. In fact, you may notice that my code does have an implementation (LocateRegistry) that can work across JVM's. The LocateRegistry will even work across the Internet! LocateRegistry takes both a host name and a Port (lock files just don't do this). I did not think to implement this beyond the local machine, but, in its present form, it will work across different processes. > >Our application uses RXTX, and we routinely encounter cases where >another (native) application has >already locked the port. Since we cannot modify the native >application to recognize lock files, >OS-level control is irreplaceable. The singleton design pattern is not meant to replace OS-level control, but to centralize the Java programmers access to it. If lock files, for example, are used for serial ports, the Singleton Design Pattern should be able to work with them. > > >> >> Consequences >> The Parametric Singleton Design Pattern has several benefits: >> > > 1. Controlled access to parametrically defined instances. Since >> the Parametric Singleton class encapsulates its instances, there is >> control over how and when clients access it. > >Not really. Once you've returned the instance to a client, you've >lost control over it. The client >can to whatever it wants with it. You cannot "recall" the instance >or claim it back. Good point, this should read: > 1. Controll when parametrically defined instances are created. Since > > the Parametric Singleton class encapsulates its instances, there is > > control over how and when they are instanced. > >> 2. Reduced name space. The Parametric Singleton pattern avoids >> global variables that store instances created from the same parameter. > >Sure, but you don't have to rely on a Singleton for that. Just >create a single Factory. > > Thank you for your thoughtful and prompt response! Regards, - Doug From dmarkman at mac.com Wed Mar 22 21:21:55 2006 From: dmarkman at mac.com (Dmitry Markman) Date: Wed, 22 Mar 2006 23:21:55 -0500 Subject: [Rxtx] sole of a new design pattern In-Reply-To: <442160DA.80107@trusted-logic.com> References: <442160DA.80107@trusted-logic.com> Message-ID: I don't think I get it On Mar 22, 2006, at 9:36 AM, David Garnier wrote: > Using the singleton pattern in this case is just convenient for the > programmer. Problems arises > pretty quickly, especially if you attempt to unit-test your classes. so you're saying that something isn't so good because you can not test it in the convenient way? if that's true, I'm totally disagree change your test, debug whatever, but if software is efficient at runtime, works fine and only problem is some unit test (which is some kind of framework for testing) then dump that unit test , dump that unit framework and make something appropriate to the software you're testing so if Douglas want to use singletons, what's the problem? and what do you mean by abusing of singleton usage? of course singleton doesn't prevent concurrent access to the resource across the processes unless you're using some OS facility to prevent it, besides singleton as it was introduced is relevant only and only inside of the same process otherwise it's not singleton it's something else (let's say network singleton: so you have remote invocation facility and some factory method that return object created by that facility) I don't have any problem with using any kind of singletons. Parametric Singleton idea (if I understand it right) could be easily implemented in the following way: use a map populate map with instances of some class and key is your parameter (you can use lazy population too) if somebody ask the key check the value if it's null so resource is taken if somebody returns the resource put it back to the map public synchronized static Object getSomeResource(Object parameter); public synchronized static void returnResource(Object parameter); getSomeResource (inside of the same process) could return null in 2 cases 1. if somebody (from other thread for example) already took that resource 2. if OS API said that resource corresponded to that parameter (serial port with parameter = 1 (port #)) is locked and unavailable; I'm not sure that in case of serial ports we even need those Parametric Singletons (unless lock checking is a very expensive operation) just ask the OS about availability of that resource and if it's available give it away and then OS will lock it and therefore in next time somebody ask it just answer that resource is locked and return null for example system has 2 serial ports available so I ask getResource("tty"); or I ask getResource("Bluetooth-Modem"); and if OS is ok you can give tty or Bluetooth-Modem or both no need for any additional pattern I think back to the problem mac os x doesn't recognize locking via files, so it handles locking via some API an instance of the singleton in each process should recognize that resource is locked (by using that API) that's all we don't have to make things more complicate then they are just because there is some nice design pattern or nice unit test framework or whatever keep things simple, make them work fast, don't introduce middle layers unless you have really good reason to do so of course I could be entirely wrong, so sorry about that in advance thanks Dmitry Markman From tjarvi at qbang.org Wed Mar 22 22:31:41 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 22 Mar 2006 22:31:41 -0700 (MST) Subject: [Rxtx] sole of a new design pattern In-Reply-To: References: Message-ID: Hi Doug Interesting reading. So far I'm just reading and thinking. I have one question so far. " Clients obtain a reference to a Parametric Singleton instance only through the parametric singleton design pattern. If the instance is left in an improper state (e.g., the serial port was left open) it is NOT the role of the Parametric Singleton Design Pattern to close the IO port. Nor is it the role of the Parametric Singleton Design Pattern to open the port. That role is delegate to some other part of the system. " So when the clients obtain a reference to the singleton, can they assume the port is there? IE, would it be the singletons role to handle things like USB dongles being removed with event hints comming from the underlying OS. Hardware abstraction layer/HAL on Linux is an example of underlying OS events. I assume that role too is delegated to other parts of the system? -- Trent Jarvi tjarvi at qbang.org From lyon at docjava.com Thu Mar 23 08:10:33 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Thu, 23 Mar 2006 10:10:33 -0500 Subject: [Rxtx] Classes don't need goals, they need roles! In-Reply-To: References: Message-ID: Hi Trent, Yes, I think that the role of the Parametric Singleton Pattern is not to open or close serial ports, nor is it to perform error checking. On the other hand, if you were to combine the role of the Parametric Singleton Pattern with another role (like that of error checking) it might not be amiss. However, I generally caution programmers against adding multiple roles to classes, as this leads to monolithic designs. Thus a different class (NativeLibDetect) could have the role of determining if the native library can be loaded. Another class (SerialPortBean) can have the role of serializing the default state of the serial port, so that it can be recovered, from user preferences, at a later time. The SerialPortDetect could have the role of determining if the serial port is removed (i.e., a USB port was unplugged). My guess is that each class should have a different role in the system, in order to ease maintenance and testing...but I could be wrong about that. Thanks! - Doug >Hi Doug > >Interesting reading. So far I'm just reading and thinking. I have >one question so far. > >" > Clients obtain a reference to a Parametric Singleton instance only >through the parametric singleton design pattern. If the instance is >left in an improper state (e.g., the serial port was left open) it is >NOT the role of the Parametric Singleton Design Pattern to close the >IO port. Nor is it the role of the Parametric Singleton Design Pattern >to >open the port. That role is delegate to some other part of the system. >" > >So when the clients obtain a reference to the singleton, can they >assume the port is there? IE, would it be the singletons role to >handle things like USB dongles being removed with event hints >comming from the underlying OS. Hardware abstraction layer/HAL on >Linux is an example of underlying OS events. > >I assume that role too is delegated to other parts of the system? > >-- >Trent Jarvi >tjarvi at qbang.org >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From maximulo at yahoo.com Fri Mar 24 01:22:38 2006 From: maximulo at yahoo.com (Maximulo Majir) Date: Fri, 24 Mar 2006 00:22:38 -0800 (PST) Subject: [Rxtx] JavaPOS Message-ID: <20060324082238.66371.qmail@web38214.mail.mud.yahoo.com> Hi all! Hello Trent! From what i understand, RXTX or JavaComm APIs were not created solely for JavaPOS. In JavaPOS, we have the virtual method claim() which is separate from open(), but in our RXTX API, claiming is done every call to open(), we cant open the port if its claimed by another application. Would it be alright to suggest or ask to create a new method called claim(..)? Is there such thing as forceclaim() in RXTX? this could be the same as portownership transfer or its equivalent. ForceClaim is in JSR80. Do you have some samples using RXTX as the lower layer for the Device Service Objects in JavaPOS? I have tried it, i just want to compare. Thank you all! maxim __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060324/496adba2/attachment-0034.html From tjarvi at qbang.org Fri Mar 24 11:28:19 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 24 Mar 2006 11:28:19 -0700 (MST) Subject: [Rxtx] Re: RXTX 2.1 Solaris Problems In-Reply-To: <3691.1143210578@www045.gmx.net> References: <3691.1143210578@www045.gmx.net> Message-ID: On Fri, 24 Mar 2006, Andreas Guenther wrote: > Hi all, > > the solaris problem was not the lock file only. > > Ok, I had to create the directory /var/spool/locks myself. > /var/spool/uucp exists. > > But rxtx didn't find any port. > > I compiled the source with my own debug-informations > and I tried to isolate the problem. > > The problem is the testRead-call in SerialImp.c > > JNIEXPORT jboolean JNICALL RXTXCommDriver(testRead)( > > ... > if ( READ( fd, &c, 1 ) < 0 ) > { > if ( errno != EAGAIN ) { > report( "testRead() read failed\n" ); > ret = JNI_FALSE; > } > } > Thanks Andreas I'm packing up to move. I'll be more or less away for a couple weeks here. I'll be checking email but my workstation is going into a box soon. This isn't hard to fix as this port should be enumerated when EWOULDBLOCK is recieved. Thats error is OK for enumeration just as EAGAIN is. I've put the bug into bugzilla so we dont forget to get to it. http://bugzilla.qbang.org/show_bug.cgi?id=42 You can add yourself to the CC list if you wish to test fixes we provide or even put a patch into bugzilla yourself. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Fri Mar 24 11:51:52 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 24 Mar 2006 11:51:52 -0700 (MST) Subject: [Rxtx] JavaPOS In-Reply-To: <20060324082238.66371.qmail@web38214.mail.mud.yahoo.com> References: <20060324082238.66371.qmail@web38214.mail.mud.yahoo.com> Message-ID: On Fri, 24 Mar 2006, Maximulo Majir wrote: > Hi all! Hello Trent! > > > From what i understand, RXTX or JavaComm APIs were not > created solely for JavaPOS. In JavaPOS, we have the virtual method > claim() which is separate from open(), but in our RXTX API, claiming is > done every call to open(), we cant open the port if its claimed by > another application. Would it be alright to suggest or ask to create a > new method called claim(..)? Is there such thing as forceclaim() in > RXTX? this could be the same as portownership transfer or its > equivalent. ForceClaim is in JSR80. > Do you have some samples using RXTX as the lower layer for the Device > Service Objects in JavaPOS? I have tried it, i just want to compare. > maxim Hi Maxim JSR80 is the USB API IBM/Sun put together. The problem is they have a richer kernel/API underneath that can handle such things. With Serial Ports, there isnt anything there other than an ioctl that says don't let anyone touch this and lockfiles that are more of a 'lets be nice.' At times we may be using USB ports but it is through the termios layer with the limitations mentioned. The advantage is that not only USB will work with rxtx. Anything that has a termios layer should work (to the extent that termios layer is complete). I don't know how forceclaim() would help you. Lets say someone has a programmer working on /dev/ttyS0 and you take it. Now you both race each other to read data first. There isn't a mechanism I know of that will solve this problem in termios. The most obvious test being a native app and a Java app trying to take the port. There is the potential of requestion ownership from other Java Applications but the use for that is very rare. Did you have something more specific in mind that I'm missing? I'm not sure that claim() and forceclaim() would help you with rxtx other than maybe locking the port with claim() without opening it. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sat Mar 25 23:42:08 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 25 Mar 2006 23:42:08 -0700 (MST) Subject: [Rxtx] Serial snoop Message-ID: I was reading the Linux kernel mail-list tonight and ran past a thread that mentioned sersnoop. This looks like a handy tool for people dealing with new toys. "a simple command-line tool for linux that echoes bytes to and from any two serial ports, ptys, or network sockets, and prints all traffic to stdout, in hex and ascii." http://www.restivo.org/projects/sersnoop/ It works on Linux only at this time (debian package available). -- Trent Jarvi tjarvi at qbang.org From beat.arnet at gmail.com Sun Mar 26 07:32:35 2006 From: beat.arnet at gmail.com (Beat Arnet) Date: Sun, 26 Mar 2006 09:32:35 -0500 Subject: [Rxtx] Error 0x5 at /home/bob/foo/tar/rxtx-2.1-7/build/../src/termios.c(860): Access is, denied. Message-ID: <4426A603.80508@gmail.com> Dear all, When trying to open the serial port, I sometimes (not always) run into the following exception (when opening the serialPort): Error 0x5 at /home/bob/foo/tar/rxtx-2.1-7/build/../src/termios.c(860): Access is denied. java.lang.UnsatisfiedLinkError: native_psmisc_report_owner at gnu.io.CommPortIdentifier.native_psmisc_report_owner(Native Method) at gnu.io.CommPortIdentifier.open(CommPortIdentifier.java:354) at codeskin.tools.CLLoader.open(CLLoader.java:79) at codeskin.tools.C2000Programmer.run(C2000Programmer.java:220) at java.lang.Thread.run(Unknown Source) Is this the type of error where I should just try to open the port again, or can it be avoided? Regards, Beat From tjarvi at qbang.org Sun Mar 26 11:40:12 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 26 Mar 2006 11:40:12 -0700 (MST) Subject: [Rxtx] Error 0x5 at /home/bob/foo/tar/rxtx-2.1-7/build/../src/termios.c(860): Access is, denied. In-Reply-To: <4426A603.80508@gmail.com> References: <4426A603.80508@gmail.com> Message-ID: On Sun, 26 Mar 2006, Beat Arnet wrote: > Dear all, > > When trying to open the serial port, I sometimes (not always) run into > the following exception (when opening the serialPort): > > Error 0x5 at /home/bob/foo/tar/rxtx-2.1-7/build/../src/termios.c(860): > Access is > denied. > > java.lang.UnsatisfiedLinkError: native_psmisc_report_owner > at gnu.io.CommPortIdentifier.native_psmisc_report_owner(Native > Method) > at gnu.io.CommPortIdentifier.open(CommPortIdentifier.java:354) > at codeskin.tools.CLLoader.open(CLLoader.java:79) > at codeskin.tools.C2000Programmer.run(C2000Programmer.java:220) > at java.lang.Thread.run(Unknown Source) > > Is this the type of error where I should just try to open the port again, > or can it be avoided? > Hi Beat We did a second build of rxtx 2.1-7 to resolve that unsatisfied link error. It should work now. rxtx is trying to tell you it thinks someone else has the serial port open. You can try to open the port again but maybe you already have a copy of the program running when it happens? ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7r2.zip fixed build. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sun Mar 26 11:44:23 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 26 Mar 2006 11:44:23 -0700 (MST) Subject: [Rxtx] RXTX spec file (fwd) Message-ID: This is probably interesting for fedora/suse users. ---------- Forwarded message ---------- Date: Sun, 26 Mar 2006 16:25:45 +0200 To: taj at www.linux.org.uk Subject: RXTX spec file I send you this spec file which allows to create a RPM for Fedora 4, 5 (x86, x86_64) with Java Sun. -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: rxtx.spec Url: http://mailman.qbang.org/pipermail/rxtx/attachments/20060326/6c7b6af6/rxtx-0030.pl From tjarvi at qbang.org Sun Mar 26 23:42:59 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 26 Mar 2006 23:42:59 -0700 (MST) Subject: [Rxtx] Upcomming events. Message-ID: This Wednesday we will be announcing a new "Maintainer" for the rxtx project. The position is more like neutral leader. I wont be going away or doing less. This is just the right thing to do as it turns out the two people with CVS write access will be at the same company. We need a third and we need neutrality. The maintainer will have final say in any conflict and will try to be neutral. It will be open for discussion. Then we will do it :) I'll still do most of the footwork I do now. But. I'm falling behind. I should have gone through the mail-list and posted the next round of changes this weekend. I'm packing to move and its going so so - 13 years of toys collected. I suspect there will be a dead period on my part (a couple weeks) comming up. But if you get it on the mail-list, we will get it in if there are no objections. I may well not be reading the mail-list during this period as I look for a house and many other things. I hope everyone will help out. Thanks -- Trent Jarvi tjarvi at qbang.org From mahmoud_hadad at yahoo.com Sun Mar 26 07:31:19 2006 From: mahmoud_hadad at yahoo.com (ronan nick) Date: Sun, 26 Mar 2006 06:31:19 -0800 (PST) Subject: [Rxtx] a question about the COMM API Message-ID: <20060326143119.54919.qmail@web60014.mail.yahoo.com> hi, i was intrested in knowing how i can communicate with my internal modem using java? for example if i want to make a phone dialer application or a caller id application where should i be looking at? and as i understood the COMM API is for devices that is attached to the computer through serial ports. --------------------------------- New Yahoo! Messenger with Voice. Call regular phones from your PC and save big. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060326/ce8329f0/attachment-0032.html From dmarkman at mac.com Mon Mar 20 00:20:43 2006 From: dmarkman at mac.com (Dmitry Markman) Date: Mon, 20 Mar 2006 02:20:43 -0500 Subject: [Rxtx] Mac OS X RXTX java installer In-Reply-To: References: <07D0DE29-BA32-4CFE-B036-66BC6423D385@buechse.de> <441AE3E0.2030503@willicon.de> <12531986.1142622114996.JavaMail.dmarkman@mac.com> <441B2674.9010409@willicon.de> <13577405.1142634732776.JavaMail.dmarkman@mac.com> <441B4182.8010407@willicon.de> <92CD0D6C-5BE8-426E-A46D-99452059FF49@mac.com> <441BBB2D.8030305@willicon.de> <441C4088.5090905@willicon.de> Message-ID: <64BC1E23-FDDE-4CE6-8863-CFC881CBC224@mac.com> Hi all I put RXTX installer that will install everything (and will create / var/lock if necessary and add user to the uucp group) for mac os x from Java into the rxtx's CVS repository it could be easily modified to install files for any platform it uses Greg Guerin's AuthKit for authentication and authorization Greg released that kit under artistic license, so Trent, please take a look we, probably, can negotiate license with Greg if it's necessary Greg's AuthKit could be downloaded from http://www.amug.org/~glguerin/ sw/#authkit Michael Hall (mikehall at spacestar dot net) had a suggestion to make implementation of the jaas LoginModule based on Greg's AuthKit (his modification of the Greg's AuthKit could be found at http:// www.spacestar.net/users/mikehall/authkit.dmg) but Michael's AuthKitLoginModule does only half a job: it does authenticate but it can not run any external unix process in privileged mode (at least I wasn't able to do so) possible explanation could be found in conversation between Greg and Michael at Apple's java-dev list (look for archives) so I didn't use jaas API for rxtxinstaller I created folder MacOSX in the contrib folder comment 1. if you want to run that installer as standalone application all you need that RXTXInstaller.jar 2. if you want to use webstart you have to add Greg's libAuthKit.jnilib to the mac os x's resources in theory RXTXInstaller.jar doesn't need it, but there is a problem with loading libAuthKit.jnilib from webstart authkit uses loadLibrary method to load library and it failed (from webstart) for standalone application I extract libAuthKit.jnilib from the RXTXInstaller.jar and put it into the /Library/Java/Extensions or ~/Library/Java/Extensions folder that file will be deleted after installer quit unfortunately I didn't have time to put documentation there but it is mostly self-explanatory I took installer code from my gl4java installer that I did about 3 years ago (with small modifications) it would be very nice if Apple will release LoginModule that really will do the job (com.apple.security.auth.module package????? ) (UnixLoginModule is pretty useless) From lyon at docjava.com Mon Mar 20 06:34:39 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Mon, 20 Mar 2006 08:34:39 -0500 Subject: [Rxtx] Mac OS X RXTX java installer In-Reply-To: <64BC1E23-FDDE-4CE6-8863-CFC881CBC224@mac.com> References: <07D0DE29-BA32-4CFE-B036-66BC6423D385@buechse.de> <441AE3E0.2030503@willicon.de> <12531986.1142622114996.JavaMail.dmarkman@mac.com> <441B2674.9010409@willicon.de> <13577405.1142634732776.JavaMail.dmarkman@mac.com> <441B4182.8010407@willicon.de> <92CD0D6C-5BE8-426E-A46D-99452059FF49@mac.com> <441BBB2D.8030305@willicon.de> <441C4088.5090905@willicon.de> <64BC1E23-FDDE-4CE6-8863-CFC881CBC224@mac.com> Message-ID: Hi Dimitry, This sounds like great work. Just a couple of questions; After the check out of the CVS files, using: setenv CVSROOT :pserver:anonymous at cvs.milestonesolutions.com:/usr/local/cvsroot 53 8:28 setenv PASSWORD mousy 54 8:29 cvs login 55 8:29 cvs checkout rxtx-devel I cd'd over to: rxtx-devel/MACOSX_IDE And found: CVS/ CW/ ForPackageMaker/ PB/ Where is the installer? Thanks! - Doug From tjarvi at qbang.org Mon Mar 20 06:39:37 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 20 Mar 2006 06:39:37 -0700 (MST) Subject: [Rxtx] Mac OS X RXTX java installer In-Reply-To: References: <07D0DE29-BA32-4CFE-B036-66BC6423D385@buechse.de> <441AE3E0.2030503@willicon.de> <12531986.1142622114996.JavaMail.dmarkman@mac.com> <441B2674.9010409@willicon.de> <13577405.1142634732776.JavaMail.dmarkman@mac.com> <441B4182.8010407@willicon.de> <92CD0D6C-5BE8-426E-A46D-99452059FF49@mac.com> <441BBB2D.8030305@willicon.de> <441C4088.5090905@willicon.de> <64BC1E23-FDDE-4CE6-8863-CFC881CBC224@mac.com> Message-ID: On Mon, 20 Mar 2006, Dr. Douglas Lyon wrote: > Hi Dimitry, > This sounds like great work. Just a couple of questions; > After the check out of the CVS files, using: > setenv CVSROOT > :pserver:anonymous at cvs.milestonesolutions.com:/usr/local/cvsroot > 53 8:28 setenv PASSWORD mousy > 54 8:29 cvs login > 55 8:29 cvs checkout rxtx-devel Hi Doug You want "cvs checkout -r commapi-0-0-1 rxtx-devel" to get RXTX 2.1 The default branch is rxtx 2.0 which isn't very active right now. -- Trent Jarvi tjarvi at qbang.org From lyon at docjava.com Mon Mar 20 07:05:44 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Mon, 20 Mar 2006 09:05:44 -0500 Subject: [Rxtx] Mac OS X RXTX java installer In-Reply-To: References: <07D0DE29-BA32-4CFE-B036-66BC6423D385@buechse.de> <441AE3E0.2030503@willicon.de> <12531986.1142622114996.JavaMail.dmarkman@mac.com> <441B2674.9010409@willicon.de> <13577405.1142634732776.JavaMail.dmarkman@mac.com> <441B4182.8010407@willicon.de> <92CD0D6C-5BE8-426E-A46D-99452059FF49@mac.com> <441BBB2D.8030305@willicon.de> <441C4088.5090905@willicon.de> <64BC1E23-FDDE-4CE6-8863-CFC881CBC224@mac.com> Message-ID: Hi Trent, Thanks for the info on the CVS checkout procedure. I did that and am still not sure where the installer is. Here is what I have: cd MACOSX_IDE/ p4.docjava.com{lyon}121: ls CVS/ ForPackageMaker/ PB/ p4.docjava.com{lyon}122: find . | more . ./ForPackageMaker ./ForPackageMaker/RXTX.pkg.sit.hqx ./ForPackageMaker/Resources ./ForPackageMaker/Resources/ReadMe.rtf ./ForPackageMaker/Resources/Welcome.rtf ./ForPackageMaker/Resources/CVS ./ForPackageMaker/Resources/CVS/Entries ./ForPackageMaker/Resources/CVS/Repository ./ForPackageMaker/Resources/CVS/Tag ./ForPackageMaker/Resources/CVS/Root ./ForPackageMaker/Resources/preinstall ./ForPackageMaker/Resources/License.rtf ./ForPackageMaker/Resources/preupgrade ./ForPackageMaker/RXTX.pmsp ./ForPackageMaker/CVS ./ForPackageMaker/CVS/Entries ./ForPackageMaker/CVS/Repository ./ForPackageMaker/CVS/Entries.Log ./ForPackageMaker/CVS/Tag ./ForPackageMaker/CVS/Root ./ForPackageMaker/RXTX_Tiger.pkg.sitx.hqx ./ForPackageMaker/RXTX_Jag.pkg.sit.hqx ./ForPackageMaker/Install ./ForPackageMaker/Install/CVS ./ForPackageMaker/Install/CVS/Entries ./ForPackageMaker/Install/CVS/Repository ./ForPackageMaker/Install/CVS/Tag ./ForPackageMaker/Install/CVS/Root ./ForPackageMaker/Install/Library ./ForPackageMaker/Install/Library/CVS ./ForPackageMaker/Install/Library/CVS/Entries ./ForPackageMaker/Install/Library/CVS/Repository ./ForPackageMaker/Install/Library/CVS/Tag ./ForPackageMaker/Install/Library/CVS/Root ./ForPackageMaker/Install/Library/Java ./ForPackageMaker/Install/Library/Java/Extensions ./ForPackageMaker/Install/Library/Java/Extensions/RXTXcomm.jar ./ForPackageMaker/Install/Library/Java/Extensions/CVS ./ForPackageMaker/Install/Library/Java/Extensions/CVS/Entries ./ForPackageMaker/Install/Library/Java/Extensions/CVS/Repository ./ForPackageMaker/Install/Library/Java/Extensions/CVS/Tag ./ForPackageMaker/Install/Library/Java/Extensions/CVS/Root ./ForPackageMaker/Install/Library/Java/Extensions/librxtxSerial.jnilib ./ForPackageMaker/Install/Library/Java/CVS ./ForPackageMaker/Install/Library/Java/CVS/Entries ./ForPackageMaker/Install/Library/Java/CVS/Repository ./ForPackageMaker/Install/Library/Java/CVS/Entries.Log ./ForPackageMaker/Install/Library/Java/CVS/Tag ./ForPackageMaker/Install/Library/Java/CVS/Root ./ForPackageMaker/RXTX_Tiger.pmproj.sitx.hqx ./CVS ./CVS/Entries ./CVS/Repository ./CVS/Entries.Log ./CVS/Tag ./CVS/Root ./PB ./PB/LibSerialUniversal.xcodeproj.sitx.hqx ./PB/CVS ./PB/CVS/Entries ./PB/CVS/Repository ./PB/CVS/Entries.Log ./PB/CVS/Tag ./PB/CVS/Root ./PB/LibSerial.pbproj.sit.hqx ./PB/startpoint.c ./PB/config.h What is the procedure to run this installer? Do we need a README in: /rxtx-devel/MACOSX_IDE Here is what we have: CVS/ ForPackageMaker/ PB/ Thanks! - DL >On Mon, 20 Mar 2006, Dr. Douglas Lyon wrote: > >>Hi Dimitry, >>This sounds like great work. Just a couple of questions; >>After the check out of the CVS files, using: >>setenv CVSROOT >>:pserver:anonymous at cvs.milestonesolutions.com:/usr/local/cvsroot >> 53 8:28 setenv PASSWORD mousy >> 54 8:29 cvs login >> 55 8:29 cvs checkout rxtx-devel > >Hi Doug > >You want "cvs checkout -r commapi-0-0-1 rxtx-devel" to get RXTX 2.1 >The default branch is rxtx 2.0 which isn't very active right now. > >-- >Trent Jarvi >tjarvi at qbang.org From tjarvi at qbang.org Mon Mar 20 07:25:30 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 20 Mar 2006 07:25:30 -0700 (MST) Subject: [Rxtx] Mac OS X RXTX java installer In-Reply-To: References: <07D0DE29-BA32-4CFE-B036-66BC6423D385@buechse.de> <441AE3E0.2030503@willicon.de> <12531986.1142622114996.JavaMail.dmarkman@mac.com> <441B2674.9010409@willicon.de> <13577405.1142634732776.JavaMail.dmarkman@mac.com> <441B4182.8010407@willicon.de> <92CD0D6C-5BE8-426E-A46D-99452059FF49@mac.com> <441BBB2D.8030305@willicon.de> <441C4088.5090905@willicon.de> <64BC1E23-FDDE-4CE6-8863-CFC881CBC224@mac.com> Message-ID: On Mon, 20 Mar 2006, Dr. Douglas Lyon wrote: > Hi Trent, > Thanks for the info on the CVS checkout procedure. > I did that and am still not sure where the installer is. Hi Doug It does look like it was not cvs committed. There is no rxtx-devel/contrib/MacOSX directory in there at the moment. It was mentioned that it was put under contrib. -- Trent Jarvi tjarvi at qbang.org From dmarkman at mac.com Mon Mar 20 07:29:56 2006 From: dmarkman at mac.com (Dmitry Markman) Date: Mon, 20 Mar 2006 09:29:56 -0500 Subject: [Rxtx] Mac OS X RXTX java installer In-Reply-To: References: <07D0DE29-BA32-4CFE-B036-66BC6423D385@buechse.de> <441AE3E0.2030503@willicon.de> <12531986.1142622114996.JavaMail.dmarkman@mac.com> <441B2674.9010409@willicon.de> <13577405.1142634732776.JavaMail.dmarkman@mac.com> <441B4182.8010407@willicon.de> <92CD0D6C-5BE8-426E-A46D-99452059FF49@mac.com> <441BBB2D.8030305@willicon.de> <441C4088.5090905@willicon.de> <64BC1E23-FDDE-4CE6-8863-CFC881CBC224@mac.com> Message-ID: <6054EB4E-F7E0-4A9C-BDDA-D582D6D8826F@mac.com> you can find it in the rxtx-devel/contrib folder On Mar 20, 2006, at 9:05 AM, Dr. Douglas Lyon wrote: > Hi Trent, > Thanks for the info on the CVS checkout procedure. > I did that and am still not sure where the installer is. > Here is what I have: > cd MACOSX_IDE/ > p4.docjava.com{lyon}121: ls > CVS/ ForPackageMaker/ PB/ > p4.docjava.com{lyon}122: find . | more > . > ./ForPackageMaker > ./ForPackageMaker/RXTX.pkg.sit.hqx > ./ForPackageMaker/Resources > ./ForPackageMaker/Resources/ReadMe.rtf > ./ForPackageMaker/Resources/Welcome.rtf > ./ForPackageMaker/Resources/CVS > ./ForPackageMaker/Resources/CVS/Entries > ./ForPackageMaker/Resources/CVS/Repository > ./ForPackageMaker/Resources/CVS/Tag > ./ForPackageMaker/Resources/CVS/Root > ./ForPackageMaker/Resources/preinstall > ./ForPackageMaker/Resources/License.rtf > ./ForPackageMaker/Resources/preupgrade > ./ForPackageMaker/RXTX.pmsp > ./ForPackageMaker/CVS > ./ForPackageMaker/CVS/Entries > ./ForPackageMaker/CVS/Repository > ./ForPackageMaker/CVS/Entries.Log > ./ForPackageMaker/CVS/Tag > ./ForPackageMaker/CVS/Root > ./ForPackageMaker/RXTX_Tiger.pkg.sitx.hqx > ./ForPackageMaker/RXTX_Jag.pkg.sit.hqx > ./ForPackageMaker/Install > ./ForPackageMaker/Install/CVS > ./ForPackageMaker/Install/CVS/Entries > ./ForPackageMaker/Install/CVS/Repository > ./ForPackageMaker/Install/CVS/Tag > ./ForPackageMaker/Install/CVS/Root > ./ForPackageMaker/Install/Library > ./ForPackageMaker/Install/Library/CVS > ./ForPackageMaker/Install/Library/CVS/Entries > ./ForPackageMaker/Install/Library/CVS/Repository > ./ForPackageMaker/Install/Library/CVS/Tag > ./ForPackageMaker/Install/Library/CVS/Root > ./ForPackageMaker/Install/Library/Java > ./ForPackageMaker/Install/Library/Java/Extensions > ./ForPackageMaker/Install/Library/Java/Extensions/RXTXcomm.jar > ./ForPackageMaker/Install/Library/Java/Extensions/CVS > ./ForPackageMaker/Install/Library/Java/Extensions/CVS/Entries > ./ForPackageMaker/Install/Library/Java/Extensions/CVS/Repository > ./ForPackageMaker/Install/Library/Java/Extensions/CVS/Tag > ./ForPackageMaker/Install/Library/Java/Extensions/CVS/Root > ./ForPackageMaker/Install/Library/Java/Extensions/librxtxSerial.jnilib > ./ForPackageMaker/Install/Library/Java/CVS > ./ForPackageMaker/Install/Library/Java/CVS/Entries > ./ForPackageMaker/Install/Library/Java/CVS/Repository > ./ForPackageMaker/Install/Library/Java/CVS/Entries.Log > ./ForPackageMaker/Install/Library/Java/CVS/Tag > ./ForPackageMaker/Install/Library/Java/CVS/Root > ./ForPackageMaker/RXTX_Tiger.pmproj.sitx.hqx > ./CVS > ./CVS/Entries > ./CVS/Repository > ./CVS/Entries.Log > ./CVS/Tag > ./CVS/Root > ./PB > ./PB/LibSerialUniversal.xcodeproj.sitx.hqx > ./PB/CVS > ./PB/CVS/Entries > ./PB/CVS/Repository > ./PB/CVS/Entries.Log > ./PB/CVS/Tag > ./PB/CVS/Root > ./PB/LibSerial.pbproj.sit.hqx > ./PB/startpoint.c > ./PB/config.h > > What is the procedure to run this installer? > Do we need a README in: > /rxtx-devel/MACOSX_IDE > Here is what we have: > CVS/ ForPackageMaker/ PB/ > > > Thanks! > - DL > >> On Mon, 20 Mar 2006, Dr. Douglas Lyon wrote: >> >>> Hi Dimitry, >>> This sounds like great work. Just a couple of questions; >>> After the check out of the CVS files, using: >>> setenv CVSROOT :pserver:anonymous at cvs.milestonesolutions.com:/usr/ >>> local/cvsroot >>> 53 8:28 setenv PASSWORD mousy >>> 54 8:29 cvs login >>> 55 8:29 cvs checkout rxtx-devel >> >> Hi Doug >> >> You want "cvs checkout -r commapi-0-0-1 rxtx-devel" to get RXTX 2.1 >> The default branch is rxtx 2.0 which isn't very active right now. >> >> -- >> Trent Jarvi >> tjarvi at qbang.org > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx Dmitry Markman From mikehall at spacestar.net Mon Mar 20 05:25:25 2006 From: mikehall at spacestar.net (Michael Hall) Date: Mon, 20 Mar 2006 06:25:25 -0600 Subject: [Rxtx] Re: Mac OS X RXTX java installer In-Reply-To: <64BC1E23-FDDE-4CE6-8863-CFC881CBC224@mac.com> References: <07D0DE29-BA32-4CFE-B036-66BC6423D385@buechse.de> <441AE3E0.2030503@willicon.de> <12531986.1142622114996.JavaMail.dmarkman@mac.com> <441B2674.9010409@willicon.de> <13577405.1142634732776.JavaMail.dmarkman@mac.com> <441B4182.8010407@willicon.de> <92CD0D6C-5BE8-426E-A46D-99452059FF49@mac.com> <441BBB2D.8030305@willicon.de> <441C4088.5090905@willicon.de> <64BC1E23-FDDE-4CE6-8863-CFC881CBC224@mac.com> Message-ID: <247EB61F-5CD1-4132-89A2-FC105B6CF9A5@spacestar.net> On Mar 20, 2006, at 1:20 AM, Dmitry Markman wrote: > > Michael Hall (mikehall at spacestar dot net) had a suggestion to > make implementation of the jaas LoginModule > based on Greg's AuthKit > (his modification of the Greg's AuthKit could be found at http:// > www.spacestar.net/users/mikehall/authkit.dmg) > but Michael's AuthKitLoginModule does only half a job: > it does authenticate > but it can not run any external unix process in privileged mode (at > least I wasn't able to do so) If you got it working directly with Greg's the point is moot. But to clarify it anyhow. The login module does not allow you to do anything anything privileged on return as was explained by Greg. You need to work with a separate privileged process using the execPrivileged method of his API. I assume you did something similar although I haven't looked at how you are using it yet. I allowed instead for a action to be performed at the same time you login/authenticate,this... System.setProperty("authkit.action","/usr/bin/id"); just before this... lc.login(); To clarify, safely ignored as you are already complete. Mike Hall mikehall at spacestar dot net http://www.spacestar.net/users/mikehall http://sourceforge.net/projects/macnative -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2427 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20060320/f6e18202/smime-0035.bin From dmarkman at mac.com Mon Mar 20 07:36:47 2006 From: dmarkman at mac.com (Dmitry Markman) Date: Mon, 20 Mar 2006 09:36:47 -0500 Subject: [Rxtx] Re: Mac OS X RXTX java installer In-Reply-To: <247EB61F-5CD1-4132-89A2-FC105B6CF9A5@spacestar.net> References: <07D0DE29-BA32-4CFE-B036-66BC6423D385@buechse.de> <441AE3E0.2030503@willicon.de> <12531986.1142622114996.JavaMail.dmarkman@mac.com> <441B2674.9010409@willicon.de> <13577405.1142634732776.JavaMail.dmarkman@mac.com> <441B4182.8010407@willicon.de> <92CD0D6C-5BE8-426E-A46D-99452059FF49@mac.com> <441BBB2D.8030305@willicon.de> <441C4088.5090905@willicon.de> <64BC1E23-FDDE-4CE6-8863-CFC881CBC224@mac.com> <247EB61F-5CD1-4132-89A2-FC105B6CF9A5@spacestar.net> Message-ID: Hi, Michael all I have to do is to run some shell script I tried to use your action mechanism and it worked great so I just System.setProperty ("authkit.action","" ) and after that I even don't need to run anything like subject.doAs.... but after few thoughts I choose to use plain Greg's approach, because in that case I don't have to deal with various java's configurations files and therefore to use 2-3 -D parameters in the java command line especially it's useful for java web start (it's so fragile :-( ) thanks for the great job On Mar 20, 2006, at 7:25 AM, Michael Hall wrote: > > On Mar 20, 2006, at 1:20 AM, Dmitry Markman wrote: >> >> Michael Hall (mikehall at spacestar dot net) had a suggestion to >> make implementation of the jaas LoginModule >> based on Greg's AuthKit >> (his modification of the Greg's AuthKit could be found at http:// >> www.spacestar.net/users/mikehall/authkit.dmg) >> but Michael's AuthKitLoginModule does only half a job: >> it does authenticate >> but it can not run any external unix process in privileged mode >> (at least I wasn't able to do so) > > If you got it working directly with Greg's the point is moot. > > But to clarify it anyhow. > The login module does not allow you to do anything anything > privileged on return as was explained by Greg. You need to work > with a separate privileged process using the execPrivileged method > of his API. I assume you did something similar although I haven't > looked at how you are using it yet. > I allowed instead for a action to be performed at the same time you > login/authenticate,this... > System.setProperty("authkit.action","/usr/bin/id"); > just before this... > lc.login(); > To clarify, safely ignored as you are already complete. > > Mike Hall mikehall at spacestar dot net > http://www.spacestar.net/users/mikehall > http://sourceforge.net/projects/macnative > > > Dmitry Markman From dmarkman at mac.com Mon Mar 20 07:44:45 2006 From: dmarkman at mac.com (Dmitry Markman) Date: Mon, 20 Mar 2006 09:44:45 -0500 Subject: [Rxtx] Mac OS X RXTX java installer In-Reply-To: References: <07D0DE29-BA32-4CFE-B036-66BC6423D385@buechse.de> <441AE3E0.2030503@willicon.de> <12531986.1142622114996.JavaMail.dmarkman@mac.com> <441B2674.9010409@willicon.de> <13577405.1142634732776.JavaMail.dmarkman@mac.com> <441B4182.8010407@willicon.de> <92CD0D6C-5BE8-426E-A46D-99452059FF49@mac.com> <441BBB2D.8030305@willicon.de> <441C4088.5090905@willicon.de> <64BC1E23-FDDE-4CE6-8863-CFC881CBC224@mac.com> Message-ID: it's in the commapi-0-0-1 branch I tested it right now: cvs co -r commapi-0-0-1 rxtx-devel and I got everything On Mar 20, 2006, at 9:25 AM, Trent Jarvi wrote: > On Mon, 20 Mar 2006, Dr. Douglas Lyon wrote: > >> Hi Trent, >> Thanks for the info on the CVS checkout procedure. >> I did that and am still not sure where the installer is. > > Hi Doug > > It does look like it was not cvs committed. There is no rxtx-devel/ > contrib/MacOSX directory in there at the moment. It was mentioned > that it was put under contrib. > > -- > Trent Jarvi > tjarvi at qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx Dmitry Markman From tjarvi at qbang.org Mon Mar 20 07:52:57 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 20 Mar 2006 07:52:57 -0700 (MST) Subject: [Rxtx] Mac OS X RXTX java installer In-Reply-To: References: <07D0DE29-BA32-4CFE-B036-66BC6423D385@buechse.de> <441AE3E0.2030503@willicon.de> <12531986.1142622114996.JavaMail.dmarkman@mac.com> <441B2674.9010409@willicon.de> <13577405.1142634732776.JavaMail.dmarkman@mac.com> <441B4182.8010407@willicon.de> <92CD0D6C-5BE8-426E-A46D-99452059FF49@mac.com> <441BBB2D.8030305@willicon.de> <441C4088.5090905@willicon.de> <64BC1E23-FDDE-4CE6-8863-CFC881CBC224@mac.com> Message-ID: On Mon, 20 Mar 2006, Dmitry Markman wrote: > it's in the commapi-0-0-1 branch > > I tested it right now: > cvs co -r commapi-0-0-1 rxtx-devel > > and I got everything > A fresh checkout worked. Here is a copy of the tree (just the installer bits) ftp://ftp.qbang.org/pub/rxtx/MacOSX-installer.zip -- Trent Jarvi tjarvi at qbang.org From lyon at docjava.com Mon Mar 20 08:08:26 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Mon, 20 Mar 2006 10:08:26 -0500 Subject: [Rxtx] Mac OS X RXTX java installer In-Reply-To: References: <07D0DE29-BA32-4CFE-B036-66BC6423D385@buechse.de> <441AE3E0.2030503@willicon.de> <12531986.1142622114996.JavaMail.dmarkman@mac.com> <441B2674.9010409@willicon.de> <13577405.1142634732776.JavaMail.dmarkman@mac.com> <441B4182.8010407@willicon.de> <92CD0D6C-5BE8-426E-A46D-99452059FF49@mac.com> <441BBB2D.8030305@willicon.de> <441C4088.5090905@willicon.de> <64BC1E23-FDDE-4CE6-8863-CFC881CBC224@mac.com> Message-ID: Hi All, Is the Auth package able to work properly on non Mac OS's? It was not clear from the doc or download. Thanks! - Doug From dmarkman at mac.com Mon Mar 20 08:15:22 2006 From: dmarkman at mac.com (Dmitry Markman) Date: Mon, 20 Mar 2006 10:15:22 -0500 Subject: [Rxtx] Mac OS X RXTX java installer In-Reply-To: References: <07D0DE29-BA32-4CFE-B036-66BC6423D385@buechse.de> <441AE3E0.2030503@willicon.de> <12531986.1142622114996.JavaMail.dmarkman@mac.com> <441B2674.9010409@willicon.de> <13577405.1142634732776.JavaMail.dmarkman@mac.com> <441B4182.8010407@willicon.de> <92CD0D6C-5BE8-426E-A46D-99452059FF49@mac.com> <441BBB2D.8030305@willicon.de> <441C4088.5090905@willicon.de> <64BC1E23-FDDE-4CE6-8863-CFC881CBC224@mac.com> Message-ID: <217312D8-CCCA-4859-ABA6-32DF1CC817B9@mac.com> thanks Trent, for putting it on ftp server On Mar 20, 2006, at 9:52 AM, Trent Jarvi wrote: > A fresh checkout worked. Here is a copy of the tree (just the > installer bits) > > ftp://ftp.qbang.org/pub/rxtx/MacOSX-installer.zip > Dmitry Markman From dmarkman at mac.com Mon Mar 20 09:14:03 2006 From: dmarkman at mac.com (Dmitry Markman) Date: Mon, 20 Mar 2006 11:14:03 -0500 Subject: [Rxtx] Mac OS X RXTX java installer In-Reply-To: References: <07D0DE29-BA32-4CFE-B036-66BC6423D385@buechse.de> <441AE3E0.2030503@willicon.de> <12531986.1142622114996.JavaMail.dmarkman@mac.com> <441B2674.9010409@willicon.de> <13577405.1142634732776.JavaMail.dmarkman@mac.com> <441B4182.8010407@willicon.de> <92CD0D6C-5BE8-426E-A46D-99452059FF49@mac.com> <441BBB2D.8030305@willicon.de> <441C4088.5090905@willicon.de> <64BC1E23-FDDE-4CE6-8863-CFC881CBC224@mac.com> Message-ID: <4DEBA6F0-DA45-4E84-823E-1F1AC48BDCCC@mac.com> no it will work only on mac os x however it's harmless to run it on other platform if you want to use it for other platform you have to do the following (I'll do it for linux) 1. modify RXTXInstaller class method public static RXTXInstaller getInstance() public static RXTXInstaller getInstance() { String osName = System.getProperty("os.name").toLowerCase(); if(osName.startsWith("mac")){ return new gnu.io.installer.macosx.MACOSXRXTXInstaller(); } else if(osName.startsWith("windows")){ return new gnu.io.installer.windows.WindowsRXTXInstaller(); }else if(osName.startsWith("linux")){ return new gnu.io.installer.linux.LinuxRXTXInstaller(); } return null; } 2. create folder gnu/io/installer/linux/ 3. create class Linux386RXTXInstaller package gnu.io.installer.linux; import java.io.File; public class Linux386RXTXInstaller extends gnu.io.installer.RXTXInstaller{ public Linux386RXTXInstaller(){ createJarFolder(); createLibFolder(); addJarResource("RXTXcomm.jar","/gnu/io/installer/resources/ linux/jar/RXTXcomm.dat"); addLibResource("librxtxSerial.so","/gnu/io/installer/ resources/linux/lib/librxtxSerial.so"); } protected void createJarFolder(){ String javaHome = System.getProperty("java.home"); char separator = File.separatorChar; jarFolder = new File(javaHome+separator+"lib"+separator+"ext"); } protected void createLibFolder(){ String javaHome = System.getProperty("java.home"); char separator = File.separatorChar; libFolder = new File(javaHome+separator+"bin"); } public void runPreProcess() {} //put here some action you need public void runPostProcess() {} //put here some action you need } 4. create folder /gnu/io/installer/resources/linux/jar and put there linux's version of RXTXcomm.dat (which is renamed RXTXcomm.jar) 5. create folder /gnu/io/installer/resources/linux/lib and put there linux's version of librxtxSerial. so 6. make sure that RXTXInstaller.jar has the following items: /gnu/io/installer/resources/linux/jar/RXTXcomm.jar /gnu/io/installer/resources/linux/lib/librxtxSerial.so 7. modify file installer.pref: jar file RXTXInstaller.jar must have the following item /gnu/io/installer/installer.pref that's basically it for windows you have to do the similar things: just replace linux to windows and librxtxSerial.so to rxtxSerial.dll and create appropriate gnu.io.installer.windows.WindowsRXTXInstaller class package gnu.io.installer.windows; import java.io.File; public class WindowsRXTXInstaller extends gnu.io.installer.RXTXInstaller{ public WindowsRXTXInstaller(){ createJarFolder(); createLibFolder(); addJarResource("RXTXcomm.jar","/gnu/io/installer/resources/ windows/jar/RXTXcomm.dat"); addLibResource("librxtxSerial.so","/gnu/io/installer/ resources/windows/lib/rxtxSerial.dll"); } protected void createJarFolder(){ String javaHome = System.getProperty("java.home"); char separator = File.separatorChar; jarFolder = new File(javaHome+separator+"lib"+separator+"ext"); } protected void createLibFolder(){ String javaHome = System.getProperty("java.home"); char separator = File.separatorChar; libFolder = new File(javaHome+separator+"bin"); } public void runPreProcess() {} //put here some action you need public void runPostProcess() {} //put here some action you need } installer.pref will look like On Mar 20, 2006, at 10:08 AM, Dr. Douglas Lyon wrote: > Hi All, > Is the Auth package able to work properly on > non Mac OS's? > It was not clear from the doc or download. > > Thanks! > - Doug > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx Dmitry Markman From joachim at buechse.de Mon Mar 20 10:49:06 2006 From: joachim at buechse.de (Joachim Buechse) Date: Mon, 20 Mar 2006 18:49:06 +0100 Subject: [Rxtx] BUG: Lock file stays even if port opening fails Message-ID: This was only tested on MacOSX but looking at the code, it should be true for all systems that use lock_uucp. I am opening a port which can not be opened (dialup port of a telephone paired via bluetooth but currently not reachable). The lock file is created and stays arround, even though the port open failed. After looking a bit through the code (of 2.17), I really wonder if it wouldn't be a good idea to make the "locking" an explicit operation called from the java code. This would certainly simplify the generation of meaningfull exceptions (and java based debugging). Maybe even the handling of "preopened" ports should be in the Java part of the lib (again for java based debugging puposes). That beeing said, I have no idea if this would be possible for the 2.07 implementation. Regards, Joachim From tjarvi at qbang.org Mon Mar 20 11:24:22 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 20 Mar 2006 11:24:22 -0700 (MST) Subject: [Rxtx] BUG: Lock file stays even if port opening fails In-Reply-To: References: Message-ID: On Mon, 20 Mar 2006, Joachim Buechse wrote: > This was only tested on MacOSX but looking at the code, it should be true > for all systems that use lock_uucp. > > I am opening a port which can not be opened (dialup port of a telephone > paired via bluetooth but currently not reachable). The lock file is > created and stays arround, even though the port open failed. > > > After looking a bit through the code (of 2.17), I really wonder if it > wouldn't be a good idea to make the "locking" an explicit operation > called from the java code. This would certainly simplify the generation > of meaningfull exceptions (and java based debugging). > Maybe even the handling of "preopened" ports should be in the Java part > of the lib (again for java based debugging puposes). That beeing said, I > have no idea if this would be possible for the 2.07 implementation. > > Regards, Hi Joachim It should be possible in the 2.0-7 implementation too. The calls to RXTXPort.java would not change. We would just do more there Moving more of that logic into Java would be better as many people don't like to look at C code. There is a liblockdev on most Linux distros that can do most of the C code and would be easier to use. The problem is embeded devices will not have that library. The preopened port code has not been really tested. That was a last minute request in a product cycle. I expect it will be tested this year though. As I recall, some devices really do not like CD raising on open. The preopened ports then allow people to mess around in java without power cycling the devices or losing data. -- Trent Jarvi tjarvi at qbang.org From joachim at buechse.de Mon Mar 20 12:01:08 2006 From: joachim at buechse.de (Joachim Buechse) Date: Mon, 20 Mar 2006 20:01:08 +0100 Subject: [Rxtx] BUG: Lock file stays even if port opening fails In-Reply-To: References: Message-ID: Hi Trent, What is your general feeling about moving code to Java? The last days I have been reading quite a bit of the code and there are several things, that might not work as expected. I'll give you two examples from is_device_locked: if LOCKDIR == /var/spool/locks the directory /var/spool/lock will not be checked. LOCKDIR is not checked for lockfiles with unexpected pefixes While these things have probably never been discovered in production, they are still possibly incorrect implementations. If it was Java code, I would write some unit tests producing the errors that could later be corrected. PS: One could imagine to actually implement the whole lockfile handling in Java using some native routines to get the values required (pid, st_dev, st_rdev, ...). On 20.03.2006, at 19:24, Trent Jarvi wrote: > On Mon, 20 Mar 2006, Joachim Buechse wrote: > >> This was only tested on MacOSX but looking at the code, it should >> be true for all systems that use lock_uucp. >> >> I am opening a port which can not be opened (dialup port of a >> telephone paired via bluetooth but currently not reachable). The >> lock file is created and stays arround, even though the port open >> failed. >> >> >> After looking a bit through the code (of 2.17), I really wonder if >> it wouldn't be a good idea to make the "locking" an explicit >> operation called from the java code. This would certainly simplify >> the generation of meaningfull exceptions (and java based debugging). >> Maybe even the handling of "preopened" ports should be in the Java >> part of the lib (again for java based debugging puposes). That >> beeing said, I have no idea if this would be possible for the 2.07 >> implementation. >> >> Regards, > > Hi Joachim > > It should be possible in the 2.0-7 implementation too. The calls > to RXTXPort.java would not change. We would just do more there > Moving more of that logic into Java would be better as many people > don't like to look at C code. There is a liblockdev on most Linux > distros that can do most of the C code and would be easier to use. > The problem is embeded devices will not have that library. > > The preopened port code has not been really tested. That was a > last minute request in a product cycle. I expect it will be tested > this year though. As I recall, some devices really do not like CD > raising on open. The preopened ports then allow people to mess > around in java without power cycling the devices or losing data. > > -- > Trent Jarvi > tjarvi at qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Mon Mar 20 12:21:02 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 20 Mar 2006 12:21:02 -0700 (MST) Subject: [Rxtx] BUG: Lock file stays even if port opening fails In-Reply-To: References: Message-ID: On Mon, 20 Mar 2006, Joachim Buechse wrote: > Hi Trent, > > What is your general feeling about moving code to Java? The last days I > have been reading quite a bit of the code and there are several things, > that might not work as expected. > > I'll give you two examples from is_device_locked: > > if LOCKDIR == /var/spool/locks the directory /var/spool/lock will not be > checked. > LOCKDIR is not checked for lockfiles with unexpected pefixes > > While these things have probably never been discovered in production, > they are still possibly incorrect implementations. If it was Java code, I > would write some unit tests producing the errors that could later be > corrected. > > PS: One could imagine to actually implement the whole lockfile handling > in Java using some native routines to get the values required (pid, > st_dev, st_rdev, ...). Hi Joachim I like the idea of moving more of the code into java but there are some things to consider. If you break this into multiple JNI calls, the performance will drop considerably during enumeration of ports. We are looking for 256 ports per dev type vs (16? in Sun's 2.0 and fewer types). Its hard to make assumptions. I've seen virtual ports start at /dev/foo100 for instance. It works out to over 7500 ports on Linux if you enable them all. We already trim that back by default. See Linux-all-ports in RXTXCommDriver.java. There are also native libraries that rxtx can link to. If you move too much into Java, linking to 'standard' libraries with distros will break. "configure --enable-liblock=yes" will not be doable. This is probably a favorable way with RedHat, Debian, Suse and others. Thats the right thing to do if there will be rpms, dpkg, .. For those reasons, I think it still make sense to keep it to a minimal ~3 calls to JNI code that we can use for speed and versatility. lock() isLocked(), unlock() perhaps. When I say speed, its more about avoiding crossing the JNI layer multiple times than java vs C performance. With versatility I think liblock is the right way for most but not all (embeded) linux distros. -- Trent Jarvi tjarvi at qbang.org From joachim at buechse.de Mon Mar 20 12:42:04 2006 From: joachim at buechse.de (Joachim Buechse) Date: Mon, 20 Mar 2006 20:42:04 +0100 Subject: [Rxtx] BUG: Lock file stays even if port opening fails In-Reply-To: References: Message-ID: <82C19FE7-DDCB-45B6-B2C9-7606B66F0124@buechse.de> Ok, what about providing a default implementation in Java? The RXTXCommDriver would call a (native) function useNativeLocking and if it returns true, call the native functions for lock() isLocked (), unlock(), else is would use the Java based default implementation. This could possibly be overriden by a property (again for debugging). Joachim On 20.03.2006, at 20:21, Trent Jarvi wrote: > On Mon, 20 Mar 2006, Joachim Buechse wrote: > >> Hi Trent, >> >> What is your general feeling about moving code to Java? The last >> days I have been reading quite a bit of the code and there are >> several things, that might not work as expected. >> >> I'll give you two examples from is_device_locked: >> >> if LOCKDIR == /var/spool/locks the directory /var/spool/lock will >> not be checked. >> LOCKDIR is not checked for lockfiles with unexpected pefixes >> >> While these things have probably never been discovered in >> production, they are still possibly incorrect implementations. If >> it was Java code, I would write some unit tests producing the >> errors that could later be corrected. >> >> PS: One could imagine to actually implement the whole lockfile >> handling in Java using some native routines to get the values >> required (pid, st_dev, st_rdev, ...). > > Hi Joachim > > I like the idea of moving more of the code into java but there are > some things to consider. > > If you break this into multiple JNI calls, the performance will > drop considerably during enumeration of ports. We are looking for > 256 ports per dev type vs (16? in Sun's 2.0 and fewer types). Its > hard to make assumptions. I've seen virtual ports start at /dev/ > foo100 for instance. > > It works out to over 7500 ports on Linux if you enable them all. > We already trim that back by default. See Linux-all-ports in > RXTXCommDriver.java. > > There are also native libraries that rxtx can link to. If you move > too much into Java, linking to 'standard' libraries with distros > will break. "configure --enable-liblock=yes" will not be doable. > This is probably a favorable way with RedHat, Debian, Suse and > others. Thats the right thing to do if there will be rpms, dpkg, .. > > For those reasons, I think it still make sense to keep it to a > minimal ~3 calls to JNI code that we can use for speed and > versatility. lock() isLocked(), unlock() perhaps. When I say > speed, its more about avoiding crossing the JNI layer multiple > times than java vs C performance. With versatility I think liblock > is the right way for most but not all (embeded) linux distros. > > -- > Trent Jarvi > tjarvi at qbang.org > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Mon Mar 20 12:44:47 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 20 Mar 2006 12:44:47 -0700 (MST) Subject: [Rxtx] BUG: Lock file stays even if port opening fails In-Reply-To: <82C19FE7-DDCB-45B6-B2C9-7606B66F0124@buechse.de> References: <82C19FE7-DDCB-45B6-B2C9-7606B66F0124@buechse.de> Message-ID: On Mon, 20 Mar 2006, Joachim Buechse wrote: > Ok, what about providing a default implementation in Java? > > The RXTXCommDriver would call a (native) function useNativeLocking and if > it returns true, call the native functions for lock() isLocked(), > unlock(), else is would use the Java based default implementation. This > could possibly be overriden by a property (again for debugging). > Hi Joachim That would be OK with me. -- Trent Jarvi tjarvi at qbang.org From dmarkman at mac.com Mon Mar 20 22:27:45 2006 From: dmarkman at mac.com (Dmitry Markman) Date: Tue, 21 Mar 2006 00:27:45 -0500 Subject: [Rxtx] binaries request Message-ID: <42702213-C222-4937-A585-7CFB17E47608@mac.com> Hi can somebody send me latest linux and windows binaries, please? or where I can find them (I didn't find them in the latest tareball) I gave up with my cygwin: something wrong I have no idea what java doesn't understand /cygwin/c syntax after I changed makefile it did java part but after that gcc 3.4.4 started to complain I set buffer length to 999 lines but I didn't get beginning of the story something wrong with my 1.4.2_09/include/jni.h gcc doesn't like it anyway I gave up thanks in advance Dmitry Markman -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060320/f8cbc57c/attachment-0035.html From tjarvi at qbang.org Mon Mar 20 22:36:48 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 20 Mar 2006 22:36:48 -0700 (MST) Subject: [Rxtx] binaries request In-Reply-To: <42702213-C222-4937-A585-7CFB17E47608@mac.com> References: <42702213-C222-4937-A585-7CFB17E47608@mac.com> Message-ID: On Tue, 21 Mar 2006, Dmitry Markman wrote: > Hi > can somebody send me latest linux and windows binaries, please? > > or where I can find them (I didn't find them in the latest tareball) > > I gave up with my cygwin: something wrong I have no idea what > java doesn't understand /cygwin/c syntax > after I changed makefile it did java part > but after that gcc 3.4.4 started to complain > I set buffer length to 999 lines but I didn't get beginning of the story > something wrong with my 1.4.2_09/include/jni.h gcc doesn't like it > anyway I gave up > > thanks in advance > Hi Dmitry The bins are here: ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7-bins-r2.zip Here are the files in the zip you want. Jar: rxtx-2.1-7-bins-r2/RXTXcomm.jar Windows: rxtx-2.1-7-bins-r2/Windows/i368-mingw32/rxtxSerial.dll Linux (x86) rxtx-2.1-7-bins-r2/Linux/i686-unknown-linux-gnu/librxtxSerial.so There are others in there including Parallel port support but those are the main ones for testing. -- Trent Jarvi tjarvi at qbang.org From dmarkman at mac.com Mon Mar 20 23:05:59 2006 From: dmarkman at mac.com (Dmitry Markman) Date: Tue, 21 Mar 2006 01:05:59 -0500 Subject: [Rxtx] binaries request In-Reply-To: References: <42702213-C222-4937-A585-7CFB17E47608@mac.com> Message-ID: thank you very much but windows's readme says: rxtxSerial.dll had to be recomopiled to link in missing native methods. should I ignore it? or what? thanks again also I understand that I should use mingw not cygwin I'll try to install mingw On Mar 21, 2006, at 12:36 AM, Trent Jarvi wrote: > On Tue, 21 Mar 2006, Dmitry Markman wrote: > >> Hi >> can somebody send me latest linux and windows binaries, please? >> >> or where I can find them (I didn't find them in the latest tareball) >> >> I gave up with my cygwin: something wrong I have no idea what >> java doesn't understand /cygwin/c syntax >> after I changed makefile it did java part >> but after that gcc 3.4.4 started to complain >> I set buffer length to 999 lines but I didn't get beginning of the >> story >> something wrong with my 1.4.2_09/include/jni.h gcc doesn't like it >> anyway I gave up >> >> thanks in advance >> > > Hi Dmitry > > The bins are here: > > ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7-bins-r2.zip > > Here are the files in the zip you want. > > Jar: > > rxtx-2.1-7-bins-r2/RXTXcomm.jar > > Windows: > > rxtx-2.1-7-bins-r2/Windows/i368-mingw32/rxtxSerial.dll > > Linux (x86) > > rxtx-2.1-7-bins-r2/Linux/i686-unknown-linux-gnu/librxtxSerial.so > > There are others in there including Parallel port support but those > are the main ones for testing. > > -- > Trent Jarvi > tjarvi at qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx Dmitry Markman From tjarvi at qbang.org Mon Mar 20 23:20:33 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 20 Mar 2006 23:20:33 -0700 (MST) Subject: [Rxtx] binaries request In-Reply-To: References: <42702213-C222-4937-A585-7CFB17E47608@mac.com> Message-ID: On Tue, 21 Mar 2006, Dmitry Markman wrote: > thank you very much > > but windows's readme says: > rxtxSerial.dll had to be recomopiled to link in missing native methods. > > should I ignore it? or what? > Hi Dmitry That dll should be OK. r2 is the recompile linked to the missing native method. The readme explains why it was recompiled; fuser.o was not linked into the dll in the first release. -- Trent Jarvi tjarvi at qbang.org From ariantristan at yahoo.com Mon Mar 20 23:55:24 2006 From: ariantristan at yahoo.com (Lambok Sianturi) Date: Mon, 20 Mar 2006 22:55:24 -0800 (PST) Subject: [Rxtx] jvm issue Message-ID: <20060321065524.94779.qmail@web50701.mail.yahoo.com> Hi All, This is my first time to join RxTx mailing list. I thank you all for allowing others to sign in in requests help. I use the latest RxTx lib in Fedora 3 with java version 1.4.2_09 b05. And I got this error: # # An unexpected error has been detected by HotSpot Virtual Machine: # # SIGSEGV (0xb) at pc=0x00bf27f3, pid=2633, tid=3086112448 # # Java VM: Java HotSpot(TM) Client VM (1.4.2_09-b05 mixed mode) # Problematic frame: # C [ld-linux.so.2+0xa7f3] # # An error report file with more information is saved as hs_err_pid2633.log # # If you would like to submit a bug report, please visit: # http://java.sun.com/webapps/bugreport/crash.jsp # ./run.sh: line 3: 2633 Aborted /usr/local/java/bin/java -Djava.library.path=/usr/local/java/jre/lib/ -Djsmsengine.debug=true -classpath jsmsengine.jar:smsgateway.jar:classes12.jar:RXTXcomm.jar:. com.api.sms.SMSServer What is the jvm depedency for the latest library? Can I use 1.4.2_09 b05? Thanks in advance. Arian --------------------------------- Yahoo! Mail Use Photomail to share photos without annoying attachments. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060320/83d58dd7/attachment-0035.html From f.frumento at ngi.it Tue Mar 21 00:21:47 2006 From: f.frumento at ngi.it (Fabio Frumento) Date: Tue, 21 Mar 2006 08:21:47 +0100 Subject: [Rxtx] Javadoc on the go Message-ID: <441FA98B.9050701@ngi.it> Hi Trent, sorry for the big delay but my job is running wild, i was out for some time but now i'm back and ready to continue the javadoc for Rxtx. Did you used the last javadoc patch i sent you ? let me know if i have to send it to you again or not. regards Fabio From lyon at docjava.com Tue Mar 21 00:51:18 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Tue, 21 Mar 2006 02:51:18 -0500 Subject: [Rxtx] lock files Message-ID: Hi All, You know, if the use of lock files were under Java control (rather than a build-time decision), it might enable a more unified binary distro. It might also facilitate quick prototyping of non-lock file approaches to resolving serial port contention issues (i.e., mac-like approaches vs. linux approaches, etc.). I realize that this is a radical overhaul of the lock file policy issue. Also, it may harm performance. On the other hand, our benchmarks on JNI overhead for modern processors indicate performance impact should be minimal. Perhaps it is more of an issue with the toybox systems. Suppose there were a class with a reasonable default...someone might write: SerialPortLockPolicy.setPolicy(SerialPortLockPolicy.UNIX_LOCK_FILE); SerialPortLockPolicy.setPolicy(SerialPortLockPolicy.NO_LOCK_CHECKING); SerialPortLockPolicy.setPolicy(SerialPortLockPolicy.MAC_STYLE); Thus, we could have a run-time reconfiguration of the serial port lock policy. A special NO_LOCK version of the binary would no longer be required. Any thoughts on this? Thanks! - Doug From joachim at buechse.de Tue Mar 21 03:09:09 2006 From: joachim at buechse.de (Joachim Buechse) Date: Tue, 21 Mar 2006 11:09:09 +0100 Subject: [Rxtx] lock files In-Reply-To: References: Message-ID: <8E12916A-1B9A-4FF2-B684-E2D1C794221B@buechse.de> This is pretty much what I thought about when I suggested, that the default behaviour could be overwritten with a property. I am very much in favor of this approach. In particular this allows much easier debugging for PC based java developers. I think big parts of the Java (and maybe some parts of the C code) could use a bit of a structural workover (unit tests, javadoc, synchronization, etc). Maybe there should be a CVS branch for this experimental version. I'd be happy to contribute a first workover for some of the Java code. Designing for testability and implementing a good bunch of unit tests has been a strategy that worked quite well in the Java projects I lead. And it ultimately allows more liberal change permission. Regards, Joachim On 21.03.2006, at 08:51, Dr. Douglas Lyon wrote: > Hi All, > You know, if the use of lock files were > under Java control (rather than a build-time decision), > it might enable a more unified binary distro. It might also > facilitate quick prototyping of non-lock file approaches > to resolving serial port contention issues (i.e., mac-like > approaches vs. linux approaches, etc.). > > I realize that this is a radical overhaul of the lock file policy > issue. Also, it may harm performance. On the other hand, > our benchmarks on JNI overhead for modern processors indicate > performance impact should be minimal. Perhaps it is more of > an issue with the toybox systems. > > Suppose there were a class with a reasonable default...someone > might write: > SerialPortLockPolicy.setPolicy(SerialPortLockPolicy.UNIX_LOCK_FILE); > SerialPortLockPolicy.setPolicy(SerialPortLockPolicy.NO_LOCK_CHECKING); > SerialPortLockPolicy.setPolicy(SerialPortLockPolicy.MAC_STYLE); > > Thus, we could have a run-time reconfiguration of the serial port lock > policy. A special NO_LOCK version of the binary would no longer > be required. > > Any thoughts on this? > > Thanks! > - Doug > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From joachim at buechse.de Tue Mar 21 06:23:08 2006 From: joachim at buechse.de (Joachim Buechse) Date: Tue, 21 Mar 2006 14:23:08 +0100 Subject: [Rxtx] PATCH: use of ioctl(fd, TIOCEXCL) instead of lockfiles Message-ID: <923AE774-EEA2-4911-92D8-32BB27802C8B@buechse.de> Here is the patch for the ioctl(fd, TIOCEXCL). I have verified this only for OSX 10.4.5, hence it is only defined for APPLE. However, it should work at least for Solaris as well. If a process has requested TIOEXCL further open calls by other user processes will fail. The patch also disables uucp style locking for APPLE. Obviously this is discussable. I think it is the way to go, as it eliminates creating the lock directory which doesnt exist on the standard installation and it eliminates messing with the system group definitions (adding users to group uucp). Regarding the possibility of root processes opening a device which is locked - I consider this a feature not a potential problem. It is highly unlikely, that somebody is crazy enough to run a JavaVM as root (unless he has no other means of getting a restricted IP port opened, ie doesnt understand ipfw). Anyway, even if the process runs as root, it fails when calling ioctl(fd, TIOCEXCL). It could however still open the port to listen for RING events. I.e. a fax server which needs to see incoming calls but otherwise doesnt want to block the port. So the only case where the proposed mechanism fails is, if an incorrectly implemented process running as root conflicts with a user process. I think this can be accepted. Regards, Joachim PS: If this patch is generally accepted, the installer and Mac doku should obviously be changed as well. Index: SerialImp.c =================================================================== RCS file: /usr/local/cvsroot/rxtx-devel/src/SerialImp.c,v retrieving revision 1.46.2.187 diff -u -r1.46.2.187 SerialImp.c --- SerialImp.c 29 Jan 2006 22:19:04 -0000 1.46.2.187 +++ SerialImp.c 21 Mar 2006 12:59:16 -0000 @@ -656,6 +656,25 @@ fd=OPEN (filename, O_RDWR | O_NOCTTY | O_NONBLOCK ); } while (fd < 0 && errno==EINTR); +#ifdef OPEN_EXCL + // Note that open() follows POSIX semantics: multiple open() calls to + // the same file will succeed unless the TIOCEXCL ioctl is issued. + // This will prevent additional opens except by root-owned processes. + // See tty(4) ("man 4 tty") and ioctl(2) ("man 2 ioctl") for details. + + if (fd >= 0 && (ioctl(fd, TIOCEXCL) == -1)) + { + sprintf( message, "open: exclusive access denied for % s\n", + filename ); + report( message ); + report_error( message ); + + close(fd); + goto fail; + } +#endif /* OPEN_EXCL */ + + if( configure_port( fd ) ) goto fail; (*env)->ReleaseStringUTFChars( env, jstr, filename ); sprintf( message, "open: fd returned is %i\n", fd ); Index: SerialImp.h =================================================================== RCS file: /usr/local/cvsroot/rxtx-devel/src/SerialImp.h,v retrieving revision 1.11.2.49 diff -u -r1.11.2.49 SerialImp.h --- SerialImp.h 5 Jul 2005 17:47:21 -0000 1.11.2.49 +++ SerialImp.h 21 Mar 2006 12:59:17 -0000 @@ -135,7 +135,8 @@ /*# define LOCKDIR "/var/spool/uucp"*/ # define LOCKDIR "/var/lock" # define LOCKFILEPREFIX "LK." -# define UUCP +/*# define UUCP*/ +# define OPEN_EXCL #endif /* __APPLE__ */ #if defined(__NetBSD__) # define DEVICEDIR "/dev/" From tjarvi at qbang.org Tue Mar 21 10:26:08 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 21 Mar 2006 10:26:08 -0700 (MST) Subject: [Rxtx] Javadoc on the go In-Reply-To: <441FA98B.9050701@ngi.it> References: <441FA98B.9050701@ngi.it> Message-ID: On Tue, 21 Mar 2006, Fabio Frumento wrote: > Hi Trent, > > sorry for the big delay but my job is running wild, i was out for some > time but now i'm back and ready to continue the javadoc for Rxtx. > > Did you used the last javadoc patch i sent you ? let me know if i have to > send it to you again or not. > > regards > > Fabio Hi Fabio The patch is in the rxtx mail-list archives. It will be going in soon. I did not see a time critical portion. I'll probably be going through the list since the last batch of patches this weekend and putting them into CVS. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Tue Mar 21 10:57:18 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 21 Mar 2006 10:57:18 -0700 (MST) Subject: [Rxtx] jvm issue In-Reply-To: <20060321065524.94779.qmail@web50701.mail.yahoo.com> References: <20060321065524.94779.qmail@web50701.mail.yahoo.com> Message-ID: On Mon, 20 Mar 2006, Lambok Sianturi wrote: > Hi All, > This is my first time to join RxTx mailing list. I thank you all for allowing others to sign in in requests help. > I use the latest RxTx lib in Fedora 3 with java version 1.4.2_09 b05. And I got this error: > > # > # An unexpected error has been detected by HotSpot Virtual Machine: > # > # SIGSEGV (0xb) at pc=0x00bf27f3, pid=2633, tid=3086112448 > # > # Java VM: Java HotSpot(TM) Client VM (1.4.2_09-b05 mixed mode) > # Problematic frame: > # C [ld-linux.so.2+0xa7f3] A native library loading error? What happens if you recompile rxtx on your system and install that? This sounds like an ABI problem? rxtx 2.1-7 was compiled with a gcc 2.96 toolchain as I recall. The hope is newer system will be backwards compatible. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Tue Mar 21 11:05:29 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 21 Mar 2006 11:05:29 -0700 (MST) Subject: [Rxtx] PATCH: use of ioctl(fd, TIOCEXCL) instead of lockfiles In-Reply-To: <923AE774-EEA2-4911-92D8-32BB27802C8B@buechse.de> References: <923AE774-EEA2-4911-92D8-32BB27802C8B@buechse.de> Message-ID: On Tue, 21 Mar 2006, Joachim Buechse wrote: > Here is the patch for the ioctl(fd, TIOCEXCL). I have verified this only > for OSX 10.4.5, hence it is only defined for APPLE. However, it should > work at least for Solaris as well. > > If a process has requested TIOEXCL further open calls by other user > processes will fail. > > The patch also disables uucp style locking for APPLE. Obviously this is > discussable. I think it is the way to go, as it eliminates creating the > lock directory which doesnt exist on the standard installation and it > eliminates messing with the system group definitions (adding users to > group uucp). > > Regarding the possibility of root processes opening a device which is > locked - I consider this a feature not a potential problem. It is highly > unlikely, that somebody is crazy enough to run a JavaVM as root (unless > he has no other means of getting a restricted IP port opened, ie doesnt > understand ipfw). Anyway, even if the process runs as root, it fails when > calling ioctl(fd, TIOCEXCL). It could however still open the port to > listen for RING events. I.e. a fax server which needs to see incoming > calls but otherwise doesnt want to block the port. So the only case where > the proposed mechanism fails is, if an incorrectly implemented process > running as root conflicts with a user process. I think this can be > accepted. > > Regards, > Joachim > > PS: If this patch is generally accepted, the installer and Mac doku > should obviously be changed as well. > > > Index: SerialImp.c > =================================================================== > RCS file: /usr/local/cvsroot/rxtx-devel/src/SerialImp.c,v > retrieving revision 1.46.2.187 > diff -u -r1.46.2.187 SerialImp.c > --- SerialImp.c 29 Jan 2006 22:19:04 -0000 1.46.2.187 > +++ SerialImp.c 21 Mar 2006 12:59:16 -0000 > @@ -656,6 +656,25 @@ > fd=OPEN (filename, O_RDWR | O_NOCTTY | O_NONBLOCK ); > } while (fd < 0 && errno==EINTR); > > +#ifdef OPEN_EXCL > + // Note that open() follows POSIX semantics: multiple open() > calls to > + // the same file will succeed unless the TIOCEXCL ioctl is > issued. > + // This will prevent additional opens except by root-owned > processes. > + // See tty(4) ("man 4 tty") and ioctl(2) ("man 2 ioctl") for > details. > + > + if (fd >= 0 && (ioctl(fd, TIOCEXCL) == -1)) > + { > + sprintf( message, "open: exclusive access denied for % > s\n", > + filename ); > + report( message ); > + report_error( message ); > + > + close(fd); > + goto fail; > + } > +#endif /* OPEN_EXCL */ > + > + > if( configure_port( fd ) ) goto fail; > (*env)->ReleaseStringUTFChars( env, jstr, filename ); > sprintf( message, "open: fd returned is %i\n", fd ); > Index: SerialImp.h > =================================================================== > RCS file: /usr/local/cvsroot/rxtx-devel/src/SerialImp.h,v > retrieving revision 1.11.2.49 > diff -u -r1.11.2.49 SerialImp.h > --- SerialImp.h 5 Jul 2005 17:47:21 -0000 1.11.2.49 > +++ SerialImp.h 21 Mar 2006 12:59:17 -0000 > @@ -135,7 +135,8 @@ > /*# define LOCKDIR "/var/spool/uucp"*/ > # define LOCKDIR "/var/lock" > # define LOCKFILEPREFIX "LK." > -# define UUCP > +/*# define UUCP*/ > +# define OPEN_EXCL > #endif /* __APPLE__ */ > #if defined(__NetBSD__) > # define DEVICEDIR "/dev/" > This looks like a good start. What do you think Dmitry? Perhaps all systems with TIOCEXCL defined should use that though. Even if they use lockfiles. It wont hurt anything. That would catch people hacking their own serial apps without checking lockfiles. Its a good idea to avoid C++ style comments in the C portions. Some older systems don't deal with them well. If it's just for Mac OS X, it isn't a big deal. I think it was the Irix compiler that was problematic? -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Tue Mar 21 11:22:05 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 21 Mar 2006 11:22:05 -0700 (MST) Subject: [Rxtx] lock files In-Reply-To: <8E12916A-1B9A-4FF2-B684-E2D1C794221B@buechse.de> References: <8E12916A-1B9A-4FF2-B684-E2D1C794221B@buechse.de> Message-ID: We can try it. Maybe the JNI is much improved. The nice thing about linking into liblock is distros then worry about lockfiles on their systems. This way, we have to deal with any changes that may show up. On Tue, 21 Mar 2006, Joachim Buechse wrote: > This is pretty much what I thought about when I suggested, that the > default behaviour could be overwritten with a property. I am very much in > favor of this approach. In particular this allows much easier debugging > for PC based java developers. > > I think big parts of the Java (and maybe some parts of the C code) could > use a bit of a structural workover (unit tests, javadoc, synchronization, > etc). Maybe there should be a CVS branch for this experimental version. > I'd be happy to contribute a first workover for some of the Java code. > Designing for testability and implementing a good bunch of unit tests has > been a strategy that worked quite well in the Java projects I lead. And > it ultimately allows more liberal change permission. > > Regards, > Joachim > > > On 21.03.2006, at 08:51, Dr. Douglas Lyon wrote: > >> Hi All, >> You know, if the use of lock files were >> under Java control (rather than a build-time decision), >> it might enable a more unified binary distro. It might also >> facilitate quick prototyping of non-lock file approaches >> to resolving serial port contention issues (i.e., mac-like >> approaches vs. linux approaches, etc.). >> >> I realize that this is a radical overhaul of the lock file policy >> issue. Also, it may harm performance. On the other hand, >> our benchmarks on JNI overhead for modern processors indicate >> performance impact should be minimal. Perhaps it is more of >> an issue with the toybox systems. >> >> Suppose there were a class with a reasonable default...someone >> might write: >> SerialPortLockPolicy.setPolicy(SerialPortLockPolicy.UNIX_LOCK_FILE); >> SerialPortLockPolicy.setPolicy(SerialPortLockPolicy.NO_LOCK_CHECKING); >> SerialPortLockPolicy.setPolicy(SerialPortLockPolicy.MAC_STYLE); >> >> Thus, we could have a run-time reconfiguration of the serial port lock >> policy. A special NO_LOCK version of the binary would no longer >> be required. >> >> Any thoughts on this? >> >> Thanks! >> - Doug >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From dmarkman at mac.com Tue Mar 21 16:05:17 2006 From: dmarkman at mac.com (Dmitry Markman) Date: Tue, 21 Mar 2006 18:05:17 -0500 Subject: [Rxtx] PATCH: use of ioctl(fd, TIOCEXCL) instead of lockfiles In-Reply-To: References: <923AE774-EEA2-4911-92D8-32BB27802C8B@buechse.de> Message-ID: <512AC70C-BB86-48F2-A83C-023F35C23BAB@mac.com> I think it's cool, but I'd like to have that property implementation when user can choose between locking mechanism about comments: it's easy to change comments to the C style or we can use extensions of the file to cpp so c++ compiler will be used On Mar 21, 2006, at 1:05 PM, Trent Jarvi wrote: > This looks like a good start. What do you think Dmitry? Perhaps > all systems with TIOCEXCL defined should use that though. Even if > they use lockfiles. It wont hurt anything. That would catch > people hacking their own serial apps without checking lockfiles. > > Its a good idea to avoid C++ style comments in the C portions. > Some older systems don't deal with them well. If it's just for Mac > OS X, it isn't a big deal. I think it was the Irix compiler that > was problematic? Dmitry Markman From dmarkman at mac.com Tue Mar 21 16:13:00 2006 From: dmarkman at mac.com (Dmitry Markman) Date: Tue, 21 Mar 2006 18:13:00 -0500 Subject: [Rxtx] PATCH: use of ioctl(fd, TIOCEXCL) instead of lockfiles In-Reply-To: References: <923AE774-EEA2-4911-92D8-32BB27802C8B@buechse.de> Message-ID: I'd like to add that creating locking folder isn't a big deal we never had a problem related to the lock folders, because we always used installer on mac os x from other hand I'm not very much familiar with iotcl locking approach and I'm not sure it's more efficient Joachim wrote "I think it is the way to go, as it eliminates creating the lock directory which doesnt exist on the standard installation and it eliminates messing with the system group definitions (adding users to group uucp)." but I really didn't have any problem with that 1. doesn't exist on the standard installation there are many-many things that don't exist in the standard installation so I don't think that argument is strong enough 2. messing with the system group definitions I don't think we're messing with the group definition mac os x provides very clear way to set up group's members and together with Greg Guerin AuthKit there is no problem to set those definitions so I don't think that argument is strong either but from other hand using iotcl is more promising and is more elegant On Mar 21, 2006, at 1:05 PM, Trent Jarvi wrote: > > This looks like a good start. What do you think Dmitry? Perhaps > all systems with TIOCEXCL defined should use that though. Even if > they use lockfiles. It wont hurt anything. That would catch > people hacking their own serial apps without checking lockfiles. Dmitry Markman From joachim at buechse.de Wed Mar 22 04:46:45 2006 From: joachim at buechse.de (Joachim Buechse) Date: Wed, 22 Mar 2006 12:46:45 +0100 Subject: [Rxtx] PATCH: use of ioctl(fd, TIOCEXCL) instead of lockfiles In-Reply-To: References: <923AE774-EEA2-4911-92D8-32BB27802C8B@buechse.de> Message-ID: Sorry, I was not very clear with my arguments, so I will try again;-) Please, don't take this as an attack against work that has been done. I think the contributions that have been made in the past were made in a good spirit. But I really believe, that the current solution for OSX has many shortcomings and should be changed as soon as possible. lock files --- The /var/lock folder does not exist on the standard OSX installation, however the standard installation includes several applications that use serial ports (i.e. the FAX capability). This indicates, that the lock folder approach will not work well with system components. Applications for OSX will generally try to live in harmony with system components (except for HP print drivers of course). I think RXTX should follow this approach as well. uucp group --- Accessing serial ports is not an admin privileged operation on OSX. Any user (world) has read/write privileges on /dev/tty*. So the system default is to not enforce any group membership to access these ports. The group uucp however is a system group on all unix systems I know. It exists for certain system processes. A non admin user should in general not be a member of this group. Quite arguably no user should ever be a member of this group. Installer --- My general opinion is, that - no Installer should touch user or group data without warning - no Application Installer should touch groups which are not specific to the very application installed - no Installer should ever add regular users to a system group The current installer injects the installing user in the group uucp without warning about this change and without giving the option to "opt out" of this change. This is a potential security risk (but not currently a real one, as OSX contains no folders belonging to group uucp). The current installer does not work for multi user systems. It puts the installing user in the uucp group. However the installing user is not necessarily the user that will use the application. Putting all users that may use a serial port application in the system group uucp seems like a very invasive approach to me. Besides that, newly created users will not automatically be in the group and hence, serial applications will "break" for new users without obvious reasons. Avoiding the lock files will allow self contained applications (i.e. drag&drop installation). In my eyes this is largely preferable over an installer that requests admin privileges. Adding up all these points indicates very strongly, that the lock-file implementation is not the way to go on OSX. Regards, Joachim On 22.03.2006, at 00:13, Dmitry Markman wrote: > I'd like to add that > > creating locking folder isn't a big deal > we never had a problem related to the lock folders, because we > always used installer on mac os x > from other hand I'm not very much familiar with iotcl locking > approach and I'm not sure it's more efficient > > Joachim wrote "I think it is the way to go, as it eliminates > creating the lock directory which doesnt exist on the standard > installation and it eliminates messing with the system group > definitions (adding users to group uucp)." but I really didn't have > any problem with that > > 1. doesn't exist on the standard installation > there are many-many things that don't exist in the standard > installation so I don't think that argument is strong enough > 2. messing with the system group definitions > I don't think we're messing with the group definition > mac os x provides very clear way to set up group's members and > together with Greg Guerin AuthKit there is no problem to set those > definitions > so I don't think that argument is strong either > but from other hand using iotcl is more promising and is more elegant > > > > On Mar 21, 2006, at 1:05 PM, Trent Jarvi wrote: > >> >> This looks like a good start. What do you think Dmitry? Perhaps >> all systems with TIOCEXCL defined should use that though. Even if >> they use lockfiles. It wont hurt anything. That would catch >> people hacking their own serial apps without checking lockfiles. > > Dmitry Markman > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From dmarkman at mac.com Wed Mar 22 05:27:13 2006 From: dmarkman at mac.com (Dmitry Markman) Date: Wed, 22 Mar 2006 07:27:13 -0500 Subject: [Rxtx] PATCH: use of ioctl(fd, TIOCEXCL) instead of lockfiles In-Reply-To: References: <923AE774-EEA2-4911-92D8-32BB27802C8B@buechse.de> Message-ID: <83440CF3-DCD8-41C1-B941-F227232C27E3@mac.com> thanks for the very good explanation I didn't think that you were attacking any thing, so don't worry I just had feeling, that there were more aesthetic reasons for going to ioctl then real necessity now you explained everything quite well (BTW, asfar as I remember installer asks admin password so it wasn't quiet, but it really doesn't matter now) thanks On Mar 22, 2006, at 6:46 AM, Joachim Buechse wrote: > Sorry, I was not very clear with my arguments, so I will try again;-) > > Please, don't take this as an attack against work that has been > done. I think the contributions that have been made in the past > were made in a good spirit. But I really believe, that the current > solution for OSX has many shortcomings and should be changed as > soon as possible. > > lock files > --- > The /var/lock folder does not exist on the standard OSX > installation, however the standard installation includes several > applications that use serial ports (i.e. the FAX capability). This > indicates, that the lock folder approach will not work well with > system components. Applications for OSX will generally try to live > in harmony with system components (except for HP print drivers of > course). I think RXTX should follow this approach as well. > > uucp group > --- > Accessing serial ports is not an admin privileged operation on OSX. > Any user (world) has read/write privileges on /dev/tty*. So the > system default is to not enforce any group membership to access > these ports. The group uucp however is a system group on all unix > systems I know. It exists for certain system processes. A non admin > user should in general not be a member of this group. Quite > arguably no user should ever be a member of this group. > > Installer > --- > My general opinion is, that > - no Installer should touch user or group data without warning > - no Application Installer should touch groups which are not > specific to the very application installed > - no Installer should ever add regular users to a system group > > The current installer injects the installing user in the group uucp > without warning about this change and without giving the option to > "opt out" of this change. This is a potential security risk (but > not currently a real one, as OSX contains no folders belonging to > group uucp). > > The current installer does not work for multi user systems. It puts > the installing user in the uucp group. However the installing user > is not necessarily the user that will use the application. Putting > all users that may use a serial port application in the system > group uucp seems like a very invasive approach to me. Besides that, > newly created users will not automatically be in the group and > hence, serial applications will "break" for new users without > obvious reasons. > > > Avoiding the lock files will allow self contained applications > (i.e. drag&drop installation). In my eyes this is largely > preferable over an installer that requests admin privileges. Adding > up all these points indicates very strongly, that the lock-file > implementation is not the way to go on OSX. > > Regards, > Joachim > > > On 22.03.2006, at 00:13, Dmitry Markman wrote: > >> I'd like to add that >> >> creating locking folder isn't a big deal >> we never had a problem related to the lock folders, because we >> always used installer on mac os x >> from other hand I'm not very much familiar with iotcl locking >> approach and I'm not sure it's more efficient >> >> Joachim wrote "I think it is the way to go, as it eliminates >> creating the lock directory which doesnt exist on the standard >> installation and it eliminates messing with the system group >> definitions (adding users to group uucp)." but I really didn't >> have any problem with that >> >> 1. doesn't exist on the standard installation >> there are many-many things that don't exist in the standard >> installation so I don't think that argument is strong enough >> 2. messing with the system group definitions >> I don't think we're messing with the group definition >> mac os x provides very clear way to set up group's members and >> together with Greg Guerin AuthKit there is no problem to set those >> definitions >> so I don't think that argument is strong either >> but from other hand using iotcl is more promising and is more elegant >> >> >> >> On Mar 21, 2006, at 1:05 PM, Trent Jarvi wrote: >> >>> >>> This looks like a good start. What do you think Dmitry? Perhaps >>> all systems with TIOCEXCL defined should use that though. Even >>> if they use lockfiles. It wont hurt anything. That would catch >>> people hacking their own serial apps without checking lockfiles. >> >> Dmitry Markman >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx Dmitry Markman From lyon at docjava.com Wed Mar 22 06:12:18 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Wed, 22 Mar 2006 08:12:18 -0500 Subject: [Rxtx] sole of a new design pattern Message-ID: Hi All, I have been thinking about how we design the serial port software. I think we need a new design pattern. For lack of a better term, I shall call it: The Parametric Singleton Design Pattern By Douglas A. Lyon ABSTRACT The goal of the singleton design pattern is to make sure that there is one, and only one, instance of a given class. The goal of the parametric singleton design pattern is to make sure that there is one, and only one, instance of a given class with the given parametric values. We parametric singleton design pattern combines the singleton design pattern with a parameter that enables unique creation of instances of a class. These instances are cached. When a user asks for an instance with these parameters, the cache is checked. If the instance is in the cache, the instance is returned, otherwise it is created, added to the cache and then returned. We apply our parametric singleton design pattern to the retrieval of RMI registries bound to a given port. The goal of our system is to make sure that no two RMI registries are listening to the same socket and to make use of the RMI registries after they have been created. RMI registries are used in distributed computation. Introduction The singleton design pattern is meant to ensure that on a single instance of a class exists. It is also meant to provide a global point of access to it. The intent of the parametric singleton design pattern is to ensure that a class has only one instance for a given set of parameter values. It also provides a global point of access to it. Motivation A system cannot tolerate multiple instances of some classes with identical parameters. For example, you cannot have two instances making use of the same serial port, at the same time. You cannot have two instances that are trying to listen to the same socket connection. You cannot have two instances writing to the same file structure at the same time. As the operating system is often thought of as the arbiter of consumed resources (i.e., tape drives, serial ports, etc.) we frequently leave it to an operating system implementation to resolve these contention issues. Even for similar resources (like serial ports) there are few standards for handling contention. For example, serial ports on Linux are locked using a "/var/lock" file. POSIX, on the other hand, uses ioctl mechanisms to prevent contention. A better solution is to make a class that is responsible for keeping track of the instances created from the class. The class is declared final, so that it cannot be subclassed. The class also has a private constructor, so that other classes cannot instance it. The new design pattern is called the parametric singleton design pattern and it provides a way to access and create instances with given parameters. Applicability Use the Parametric Singleton Design Pattern when: 1. There must be exactly one instance of a class with the given parameters. 2. The instances must be accessible to clients from a well-known access point. Structure Insert UML diagram here. Participants The Parametric Singleton Clients that need instances 1. The Parametric Singleton defines an instance upon request from a client, if, and only if, the instance does not already exist. 2. The Parametric Singleton returns the instance to the client. 3. The Parametric Singleton is responsible for creating unique instances from given parameters. Collaborations Clients obtain a reference to a Parametric Singleton instance only through the parametric singleton design pattern. If the instance is left in an improper state (e.g., the serial port was left open) it is NOT the role of the Parametric Singleton Design Pattern to close the IO port. Nor is it the role of the Parametric Singleton Design Pattern to open the port. That role is delegate to some other part of the system. Further, it is not the role of the Parametric Singleton Design Pattern to check out resources. That is, multiple threads can have multiple references to the same resource at the same time. MUTEX locking is delegated to some other part of the system. Consequences The Parametric Singleton Design Pattern has several benefits: 1. Controlled access to parametrically defined instances. Since the Parametric Singleton class encapsulates its instances, there is control over how and when clients access it. 2. Reduced name space. The Parametric Singleton pattern avoids global variables that store instances created from the same parameter. Implementation Here are implementation issues to consider when using the Parametric Singleton pattern: 1. Unique mapping of parameters. The Parametric Singleton pattern requires that there be a mean to isomorphically map the parameter space into the instance space and back again. 2. Ensure unique instances. The Parametric Singleton pattern makes unique instances from parameters, and it does so only once. 3. Cache instances for fast retrieval. The Parametric Singleton pattern must be able to look up instances, given some set of parameters, and do so from some data structure. That is, there must be enough space to hold references to all the instances the program will need. Also, a mechanism is needed to look up and retrieve the instances quickly enough to satisfy the clients. Sample Code public final class ParametricSingletonRmiRegistry { private static Hashtable registry = new Hashtable(100); // use singleton pattern and??????????????????????????????????????????????? // prevent instantiation of RmiRegistryUtils.?????????????????????????????? private ParametricSingletonRmiRegistry() { } // the only instance of the Registry held by the RmiRegistryUtils?????????? public static void listNames(Integer port) { if (!isInCacheAndRunning(port)) return; Registry r = (Registry) registry.get(port); System.out.println("registry on port: " + port); System.out.println("registry: " + r); System.out.println("names: "); try { print(r.list()); } catch (RemoteException e) { In.message(e); } System.out.println("------------------------"); } /**???????????????????????????????????????????????????????????????????????? * Checks whether a Registry has been started on this host????????????????? * in the specified port.?????????????????????????????????????????????????? * If not, it tries to start one.?????????????????????????????????????????? * when it fails to start a Registry, it exits the program????????????????? * with exit code 1.??????????????????????????????????????????????????????? */ public static void restart(int port) { if (isInCacheAndRunning(port)) return; try { startRegistry(port); } catch (RemoteException e) { In.message(e); } } /**???????????????????????????????????????????????????????????????????????? * @param port????????????????????????????????????????????????????????????? * @return true if registry is in cache and running???????????????????????? */ private static boolean isInCacheAndRunning(Integer port) { if (!isRegistryRunning(port.intValue())) return false; if (!isRegistryInCache(port.intValue())) return false; return true; } /**???????????????????????????????????????????????????????????????????????? * @param port????????????????????????????????????????????????????????????? * @return true if we are able to locate a local registry on port.??????????????????????????????????????????????????????????????????????????? */ private static boolean isRegistryRunning(int port) { try { Registry r = LocateRegistry.getRegistry(port); if (r != null) return true; } catch (RemoteException e) { return false; } return false; } /**???????????????????????????????????????????????????????????????????????? * @param port????????????????????????????????????????????????????????????? * @return return true if registry is in cache????????????????????????????? */ private static boolean isRegistryInCache(int port) { if (registry.get(new Integer(port)) == null) return false; return true; } /**???????????????????????????????????????????????????????????????????????? * Restart the registry, if needed.???????????????????????????????????????? * Return the only instance of the registry for consistent global?????????? * using by making use of the Singleton Design Pattern????????????????????? *????????????????????????????????????????????????????????????????????????? * @return the internally held registry instance.?????????????????????????? */ public static Registry getRegistry(Integer port) { restart(port); return (Registry) registry.get(port); } private static void startRegistry(Integer port) throws RemoteException { Registry r; try { r = LocateRegistry.createRegistry(port.intValue()); registry.put(port, r); //r = new sun.rmi.registry.RegistryImpl???????????????????????????? /// (port.intValue());?????????????????????????????????????? // registry.put(port, r);?????????????????????????????????????????? } catch (Exception e) { //e.printStackTrace();????????????????????????????????????????????? r = LocateRegistry.getRegistry(port.intValue()); registry.put(port, r); } } public static void main(String args[]) throws RemoteException { //restart(port);??????????????????????????????????????????????????????? restart(5001); restart(5002); restart(5002); Registry r = LocateRegistry.getRegistry(5002); System.out.println("registry="+r); } } I would very much like to get your feedback on this new design pattern idea. Thank you for your time. Regards, - Doug From david.garnier at trusted-logic.com Wed Mar 22 07:36:10 2006 From: david.garnier at trusted-logic.com (David Garnier) Date: Wed, 22 Mar 2006 15:36:10 +0100 Subject: [Rxtx] sole of a new design pattern In-Reply-To: References: Message-ID: <442160DA.80107@trusted-logic.com> Hello, > The Parametric Singleton Design Pattern The Singleton is the most abused design pattern ever. Good use-cases for this pattern are extremely rare and mostly confined to problems related to hardware resources, like serial ports. > Applicability > > Use the Parametric Singleton Design Pattern when: > 1. There must be exactly one instance of a class with the given > parameters. OK. As I said above, this case this actually very unusual. The Singleton pattern is mostly used when : > 2. The instances must be accessible to clients from a well-known > access point. Using the singleton pattern in this case is just convenient for the programmer. Problems arises pretty quickly, especially if you attempt to unit-test your classes. 1) If your singleton is stateful, or hold on to stateful objects, it means that two different unit tests are not actually independent. Instead of starting with a brand new environment, the result of a test may be affected by the result of a previous test. This problem also arise when with your class relies on a database. In both cases, the solution is to reset your "unique" resource (Singleton or database) at the beginning of the test, which is a pain. Also, while most projects connect to a single database, projects that allow the use of Singletons usually contain several of thems, and new ones may cropped up unnoticed. You quickly end up with test cases that only pass in a certain order, which is a royal pain. 2) You cannot mockup a singleton. Once everyone calls the SomeSingleton class statically, you can't replace your class by SomeSingletonMockup. Furthermore, even for hardware services, the Singleton pattern does not really prevent concurrent accesses. If you start the same program in two different JVMs, unless they somehow shared the state of their "Singletons" (through lock files for example), the Singleton pattern will not prevent concurrent access. Our application uses RXTX, and we routinely encounter cases where another (native) application has already locked the port. Since we cannot modify the native application to recognize lock files, OS-level control is irreplaceable. > > Consequences > The Parametric Singleton Design Pattern has several benefits: > > 1. Controlled access to parametrically defined instances. Since > the Parametric Singleton class encapsulates its instances, there is > control over how and when clients access it. Not really. Once you've returned the instance to a client, you've lost control over it. The client can to whatever it wants with it. You cannot "recall" the instance or claim it back. > 2. Reduced name space. The Parametric Singleton pattern avoids > global variables that store instances created from the same parameter. Sure, but you don't have to rely on a Singleton for that. Just create a single Factory. > I would very much like to get your feedback on this new design > pattern idea. Well, it's nothing new. Some may say that it is the point of design patterns: formalizes the designs that occur again and again. However, this design is simply a combination of the Singleton and Factory patterns. I did use it in the past, but now I've been exposed to the shortcomings of the Singleton pattern, so I limit myself to Factories. Regards, David From sean_montgomery at baseview.com Wed Mar 22 08:35:28 2006 From: sean_montgomery at baseview.com (Sean Montgomery) Date: Wed, 22 Mar 2006 10:35:28 -0500 Subject: [Rxtx] sole of a new design pattern In-Reply-To: <442160DA.80107@trusted-logic.com> References: <442160DA.80107@trusted-logic.com> Message-ID: <05769CA7-A51B-4CF0-BAA0-E02DD905F5A4@baseview.com> On Mar 22, 2006, at 9:36 AM, David Garnier wrote: > Furthermore, even for hardware services, the Singleton pattern does > not really prevent concurrent > accesses. If you start the same program in two different JVMs, > unless they somehow shared the state > of their "Singletons" (through lock files for example), the > Singleton pattern will not prevent > concurrent access. > Multiple class loaders in a single JVM can be tricky, too. Then there's synchronization, lazy initialization and serialization of singletons to contend with. Bloch's Effective Java covers these, and here's a few articles: http://www.javaworld.com/javaworld/jw-04-2003/jw-0425-designpatterns- p3.html http://java.sun.com/developer/technicalArticles/Programming/singletons/ Just FYI :-) From lyon at docjava.com Wed Mar 22 08:50:48 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Wed, 22 Mar 2006 10:50:48 -0500 Subject: [Rxtx] sole of a new design pattern In-Reply-To: <442160DA.80107@trusted-logic.com> References: <442160DA.80107@trusted-logic.com> Message-ID: Hi All, First, I would like to thank David for his prompt and thoughtful remarks. I had no idea people that feel strongly about a design patterns! Wow! Feedback (particularly critical feedback) is greatly appreciated. Starting at the end, first: >I did use it in >the past, but now I've been exposed to the shortcomings of the >Singleton pattern, so I limit myself to Factories. David, if I understood your comments correctly, you suggested that Factories can be used in leu of the Singleton Design Pattern, or even the Parametric Singleton Design Pattern. As I see in [Gof]: Factory Method: Intent "Define an interface for creating an object, but let subclasses decide which class to instantiate. Factory Method lets a class defer instantiation to subclasses." The Singleton Design Pattern is a concrete class, which is rather different, right? Also, subclasses are not permitted with Singleton, as they are final. Naturally, I could use an abstract factory as a parent for a singleton. I could even design a facade that could be implemented with the singleton....but that is not the intention of the design. Unless you want a mock-up, as discussed, below: More below: >Hello, > >> The Parametric Singleton Design Pattern > >The Singleton is the most abused design pattern ever. Good use-cases >for this pattern are extremely >rare and mostly confined to problems related to hardware resources, >like serial ports. > > >> Applicability >> >> Use the Parametric Singleton Design Pattern when: >> 1. There must be exactly one instance of a class with the given >> parameters. >OK. As I said above, this case this actually very unusual. The >Singleton pattern is mostly used when : >> 2. The instances must be accessible to clients from a well-known >> access point. > >Using the singleton pattern in this case is just convenient for the >programmer. Problems arises >pretty quickly, especially if you attempt to unit-test your classes. > >1) If your singleton is stateful, or hold on to stateful objects, it >means that two different unit >tests are not actually independent. Instead of starting with a brand >new environment, the result of >a test may be affected by the result of a previous test. This >problem also arise when with your >class relies on a database. In both cases, the solution is to reset >your "unique" resource >(Singleton or database) at the beginning of the test, which is a >pain. Also, while most projects >connect to a single database, projects that allow the use of >Singletons usually contain several of >thems, and new ones may cropped up unnoticed. You quickly end up >with test cases that only pass in a >certain order, which is a royal pain. There are basic problems with communicating finite state machines that include reachability and deadlock analysis. These are addressed with petri net analysis and are beyond the scope of the design pattern. As you quite rightly pointed out; the parametric singleton pattern (or the singleton pattern, for that matter) enable multiple threads to gain access to the same instance. The only way that I can see to block others from gaining access to the reference is the synchronize keyword. This is putting a spin-lock (or MUTEX) on the reference. The question of how to unit-test a design pattern like the parametric singleton remains open. Perhaps this is a deficiency. > >2) You cannot mockup a singleton. Once everyone calls the >SomeSingleton class statically, you can't >replace your class by SomeSingletonMockup. Acutally, I am not sure that this is true. If the Singleton implements a Facade interface, it should be possible to make the replacement. Right? > >Furthermore, even for hardware services, the Singleton pattern does >not really prevent concurrent >accesses. If you start the same program in two different JVMs, >unless they somehow shared the state >of their "Singletons" (through lock files for example), the >Singleton pattern will not prevent >concurrent access. Good Point!! You have sharp eyes! The singleton design pattern should/could take responsibility for this. In fact, you may notice that my code does have an implementation (LocateRegistry) that can work across JVM's. The LocateRegistry will even work across the Internet! LocateRegistry takes both a host name and a Port (lock files just don't do this). I did not think to implement this beyond the local machine, but, in its present form, it will work across different processes. > >Our application uses RXTX, and we routinely encounter cases where >another (native) application has >already locked the port. Since we cannot modify the native >application to recognize lock files, >OS-level control is irreplaceable. The singleton design pattern is not meant to replace OS-level control, but to centralize the Java programmers access to it. If lock files, for example, are used for serial ports, the Singleton Design Pattern should be able to work with them. > > >> >> Consequences >> The Parametric Singleton Design Pattern has several benefits: >> > > 1. Controlled access to parametrically defined instances. Since >> the Parametric Singleton class encapsulates its instances, there is >> control over how and when clients access it. > >Not really. Once you've returned the instance to a client, you've >lost control over it. The client >can to whatever it wants with it. You cannot "recall" the instance >or claim it back. Good point, this should read: > 1. Controll when parametrically defined instances are created. Since > > the Parametric Singleton class encapsulates its instances, there is > > control over how and when they are instanced. > >> 2. Reduced name space. The Parametric Singleton pattern avoids >> global variables that store instances created from the same parameter. > >Sure, but you don't have to rely on a Singleton for that. Just >create a single Factory. > > Thank you for your thoughtful and prompt response! Regards, - Doug From dmarkman at mac.com Wed Mar 22 21:21:55 2006 From: dmarkman at mac.com (Dmitry Markman) Date: Wed, 22 Mar 2006 23:21:55 -0500 Subject: [Rxtx] sole of a new design pattern In-Reply-To: <442160DA.80107@trusted-logic.com> References: <442160DA.80107@trusted-logic.com> Message-ID: I don't think I get it On Mar 22, 2006, at 9:36 AM, David Garnier wrote: > Using the singleton pattern in this case is just convenient for the > programmer. Problems arises > pretty quickly, especially if you attempt to unit-test your classes. so you're saying that something isn't so good because you can not test it in the convenient way? if that's true, I'm totally disagree change your test, debug whatever, but if software is efficient at runtime, works fine and only problem is some unit test (which is some kind of framework for testing) then dump that unit test , dump that unit framework and make something appropriate to the software you're testing so if Douglas want to use singletons, what's the problem? and what do you mean by abusing of singleton usage? of course singleton doesn't prevent concurrent access to the resource across the processes unless you're using some OS facility to prevent it, besides singleton as it was introduced is relevant only and only inside of the same process otherwise it's not singleton it's something else (let's say network singleton: so you have remote invocation facility and some factory method that return object created by that facility) I don't have any problem with using any kind of singletons. Parametric Singleton idea (if I understand it right) could be easily implemented in the following way: use a map populate map with instances of some class and key is your parameter (you can use lazy population too) if somebody ask the key check the value if it's null so resource is taken if somebody returns the resource put it back to the map public synchronized static Object getSomeResource(Object parameter); public synchronized static void returnResource(Object parameter); getSomeResource (inside of the same process) could return null in 2 cases 1. if somebody (from other thread for example) already took that resource 2. if OS API said that resource corresponded to that parameter (serial port with parameter = 1 (port #)) is locked and unavailable; I'm not sure that in case of serial ports we even need those Parametric Singletons (unless lock checking is a very expensive operation) just ask the OS about availability of that resource and if it's available give it away and then OS will lock it and therefore in next time somebody ask it just answer that resource is locked and return null for example system has 2 serial ports available so I ask getResource("tty"); or I ask getResource("Bluetooth-Modem"); and if OS is ok you can give tty or Bluetooth-Modem or both no need for any additional pattern I think back to the problem mac os x doesn't recognize locking via files, so it handles locking via some API an instance of the singleton in each process should recognize that resource is locked (by using that API) that's all we don't have to make things more complicate then they are just because there is some nice design pattern or nice unit test framework or whatever keep things simple, make them work fast, don't introduce middle layers unless you have really good reason to do so of course I could be entirely wrong, so sorry about that in advance thanks Dmitry Markman From tjarvi at qbang.org Wed Mar 22 22:31:41 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 22 Mar 2006 22:31:41 -0700 (MST) Subject: [Rxtx] sole of a new design pattern In-Reply-To: References: Message-ID: Hi Doug Interesting reading. So far I'm just reading and thinking. I have one question so far. " Clients obtain a reference to a Parametric Singleton instance only through the parametric singleton design pattern. If the instance is left in an improper state (e.g., the serial port was left open) it is NOT the role of the Parametric Singleton Design Pattern to close the IO port. Nor is it the role of the Parametric Singleton Design Pattern to open the port. That role is delegate to some other part of the system. " So when the clients obtain a reference to the singleton, can they assume the port is there? IE, would it be the singletons role to handle things like USB dongles being removed with event hints comming from the underlying OS. Hardware abstraction layer/HAL on Linux is an example of underlying OS events. I assume that role too is delegated to other parts of the system? -- Trent Jarvi tjarvi at qbang.org From lyon at docjava.com Thu Mar 23 08:10:33 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Thu, 23 Mar 2006 10:10:33 -0500 Subject: [Rxtx] Classes don't need goals, they need roles! In-Reply-To: References: Message-ID: Hi Trent, Yes, I think that the role of the Parametric Singleton Pattern is not to open or close serial ports, nor is it to perform error checking. On the other hand, if you were to combine the role of the Parametric Singleton Pattern with another role (like that of error checking) it might not be amiss. However, I generally caution programmers against adding multiple roles to classes, as this leads to monolithic designs. Thus a different class (NativeLibDetect) could have the role of determining if the native library can be loaded. Another class (SerialPortBean) can have the role of serializing the default state of the serial port, so that it can be recovered, from user preferences, at a later time. The SerialPortDetect could have the role of determining if the serial port is removed (i.e., a USB port was unplugged). My guess is that each class should have a different role in the system, in order to ease maintenance and testing...but I could be wrong about that. Thanks! - Doug >Hi Doug > >Interesting reading. So far I'm just reading and thinking. I have >one question so far. > >" > Clients obtain a reference to a Parametric Singleton instance only >through the parametric singleton design pattern. If the instance is >left in an improper state (e.g., the serial port was left open) it is >NOT the role of the Parametric Singleton Design Pattern to close the >IO port. Nor is it the role of the Parametric Singleton Design Pattern >to >open the port. That role is delegate to some other part of the system. >" > >So when the clients obtain a reference to the singleton, can they >assume the port is there? IE, would it be the singletons role to >handle things like USB dongles being removed with event hints >comming from the underlying OS. Hardware abstraction layer/HAL on >Linux is an example of underlying OS events. > >I assume that role too is delegated to other parts of the system? > >-- >Trent Jarvi >tjarvi at qbang.org >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From maximulo at yahoo.com Fri Mar 24 01:22:38 2006 From: maximulo at yahoo.com (Maximulo Majir) Date: Fri, 24 Mar 2006 00:22:38 -0800 (PST) Subject: [Rxtx] JavaPOS Message-ID: <20060324082238.66371.qmail@web38214.mail.mud.yahoo.com> Hi all! Hello Trent! From what i understand, RXTX or JavaComm APIs were not created solely for JavaPOS. In JavaPOS, we have the virtual method claim() which is separate from open(), but in our RXTX API, claiming is done every call to open(), we cant open the port if its claimed by another application. Would it be alright to suggest or ask to create a new method called claim(..)? Is there such thing as forceclaim() in RXTX? this could be the same as portownership transfer or its equivalent. ForceClaim is in JSR80. Do you have some samples using RXTX as the lower layer for the Device Service Objects in JavaPOS? I have tried it, i just want to compare. Thank you all! maxim __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060324/496adba2/attachment-0035.html From tjarvi at qbang.org Fri Mar 24 11:28:19 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 24 Mar 2006 11:28:19 -0700 (MST) Subject: [Rxtx] Re: RXTX 2.1 Solaris Problems In-Reply-To: <3691.1143210578@www045.gmx.net> References: <3691.1143210578@www045.gmx.net> Message-ID: On Fri, 24 Mar 2006, Andreas Guenther wrote: > Hi all, > > the solaris problem was not the lock file only. > > Ok, I had to create the directory /var/spool/locks myself. > /var/spool/uucp exists. > > But rxtx didn't find any port. > > I compiled the source with my own debug-informations > and I tried to isolate the problem. > > The problem is the testRead-call in SerialImp.c > > JNIEXPORT jboolean JNICALL RXTXCommDriver(testRead)( > > ... > if ( READ( fd, &c, 1 ) < 0 ) > { > if ( errno != EAGAIN ) { > report( "testRead() read failed\n" ); > ret = JNI_FALSE; > } > } > Thanks Andreas I'm packing up to move. I'll be more or less away for a couple weeks here. I'll be checking email but my workstation is going into a box soon. This isn't hard to fix as this port should be enumerated when EWOULDBLOCK is recieved. Thats error is OK for enumeration just as EAGAIN is. I've put the bug into bugzilla so we dont forget to get to it. http://bugzilla.qbang.org/show_bug.cgi?id=42 You can add yourself to the CC list if you wish to test fixes we provide or even put a patch into bugzilla yourself. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Fri Mar 24 11:51:52 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 24 Mar 2006 11:51:52 -0700 (MST) Subject: [Rxtx] JavaPOS In-Reply-To: <20060324082238.66371.qmail@web38214.mail.mud.yahoo.com> References: <20060324082238.66371.qmail@web38214.mail.mud.yahoo.com> Message-ID: On Fri, 24 Mar 2006, Maximulo Majir wrote: > Hi all! Hello Trent! > > > From what i understand, RXTX or JavaComm APIs were not > created solely for JavaPOS. In JavaPOS, we have the virtual method > claim() which is separate from open(), but in our RXTX API, claiming is > done every call to open(), we cant open the port if its claimed by > another application. Would it be alright to suggest or ask to create a > new method called claim(..)? Is there such thing as forceclaim() in > RXTX? this could be the same as portownership transfer or its > equivalent. ForceClaim is in JSR80. > Do you have some samples using RXTX as the lower layer for the Device > Service Objects in JavaPOS? I have tried it, i just want to compare. > maxim Hi Maxim JSR80 is the USB API IBM/Sun put together. The problem is they have a richer kernel/API underneath that can handle such things. With Serial Ports, there isnt anything there other than an ioctl that says don't let anyone touch this and lockfiles that are more of a 'lets be nice.' At times we may be using USB ports but it is through the termios layer with the limitations mentioned. The advantage is that not only USB will work with rxtx. Anything that has a termios layer should work (to the extent that termios layer is complete). I don't know how forceclaim() would help you. Lets say someone has a programmer working on /dev/ttyS0 and you take it. Now you both race each other to read data first. There isn't a mechanism I know of that will solve this problem in termios. The most obvious test being a native app and a Java app trying to take the port. There is the potential of requestion ownership from other Java Applications but the use for that is very rare. Did you have something more specific in mind that I'm missing? I'm not sure that claim() and forceclaim() would help you with rxtx other than maybe locking the port with claim() without opening it. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sat Mar 25 23:42:08 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 25 Mar 2006 23:42:08 -0700 (MST) Subject: [Rxtx] Serial snoop Message-ID: I was reading the Linux kernel mail-list tonight and ran past a thread that mentioned sersnoop. This looks like a handy tool for people dealing with new toys. "a simple command-line tool for linux that echoes bytes to and from any two serial ports, ptys, or network sockets, and prints all traffic to stdout, in hex and ascii." http://www.restivo.org/projects/sersnoop/ It works on Linux only at this time (debian package available). -- Trent Jarvi tjarvi at qbang.org From beat.arnet at gmail.com Sun Mar 26 07:32:35 2006 From: beat.arnet at gmail.com (Beat Arnet) Date: Sun, 26 Mar 2006 09:32:35 -0500 Subject: [Rxtx] Error 0x5 at /home/bob/foo/tar/rxtx-2.1-7/build/../src/termios.c(860): Access is, denied. Message-ID: <4426A603.80508@gmail.com> Dear all, When trying to open the serial port, I sometimes (not always) run into the following exception (when opening the serialPort): Error 0x5 at /home/bob/foo/tar/rxtx-2.1-7/build/../src/termios.c(860): Access is denied. java.lang.UnsatisfiedLinkError: native_psmisc_report_owner at gnu.io.CommPortIdentifier.native_psmisc_report_owner(Native Method) at gnu.io.CommPortIdentifier.open(CommPortIdentifier.java:354) at codeskin.tools.CLLoader.open(CLLoader.java:79) at codeskin.tools.C2000Programmer.run(C2000Programmer.java:220) at java.lang.Thread.run(Unknown Source) Is this the type of error where I should just try to open the port again, or can it be avoided? Regards, Beat From tjarvi at qbang.org Sun Mar 26 11:40:12 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 26 Mar 2006 11:40:12 -0700 (MST) Subject: [Rxtx] Error 0x5 at /home/bob/foo/tar/rxtx-2.1-7/build/../src/termios.c(860): Access is, denied. In-Reply-To: <4426A603.80508@gmail.com> References: <4426A603.80508@gmail.com> Message-ID: On Sun, 26 Mar 2006, Beat Arnet wrote: > Dear all, > > When trying to open the serial port, I sometimes (not always) run into > the following exception (when opening the serialPort): > > Error 0x5 at /home/bob/foo/tar/rxtx-2.1-7/build/../src/termios.c(860): > Access is > denied. > > java.lang.UnsatisfiedLinkError: native_psmisc_report_owner > at gnu.io.CommPortIdentifier.native_psmisc_report_owner(Native > Method) > at gnu.io.CommPortIdentifier.open(CommPortIdentifier.java:354) > at codeskin.tools.CLLoader.open(CLLoader.java:79) > at codeskin.tools.C2000Programmer.run(C2000Programmer.java:220) > at java.lang.Thread.run(Unknown Source) > > Is this the type of error where I should just try to open the port again, > or can it be avoided? > Hi Beat We did a second build of rxtx 2.1-7 to resolve that unsatisfied link error. It should work now. rxtx is trying to tell you it thinks someone else has the serial port open. You can try to open the port again but maybe you already have a copy of the program running when it happens? ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7r2.zip fixed build. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sun Mar 26 11:44:23 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 26 Mar 2006 11:44:23 -0700 (MST) Subject: [Rxtx] RXTX spec file (fwd) Message-ID: This is probably interesting for fedora/suse users. ---------- Forwarded message ---------- Date: Sun, 26 Mar 2006 16:25:45 +0200 To: taj at www.linux.org.uk Subject: RXTX spec file I send you this spec file which allows to create a RPM for Fedora 4, 5 (x86, x86_64) with Java Sun. -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: rxtx.spec Url: http://mailman.qbang.org/pipermail/rxtx/attachments/20060326/6c7b6af6/rxtx-0031.pl From tjarvi at qbang.org Sun Mar 26 23:42:59 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 26 Mar 2006 23:42:59 -0700 (MST) Subject: [Rxtx] Upcomming events. Message-ID: This Wednesday we will be announcing a new "Maintainer" for the rxtx project. The position is more like neutral leader. I wont be going away or doing less. This is just the right thing to do as it turns out the two people with CVS write access will be at the same company. We need a third and we need neutrality. The maintainer will have final say in any conflict and will try to be neutral. It will be open for discussion. Then we will do it :) I'll still do most of the footwork I do now. But. I'm falling behind. I should have gone through the mail-list and posted the next round of changes this weekend. I'm packing to move and its going so so - 13 years of toys collected. I suspect there will be a dead period on my part (a couple weeks) comming up. But if you get it on the mail-list, we will get it in if there are no objections. I may well not be reading the mail-list during this period as I look for a house and many other things. I hope everyone will help out. Thanks -- Trent Jarvi tjarvi at qbang.org From mahmoud_hadad at yahoo.com Sun Mar 26 07:31:19 2006 From: mahmoud_hadad at yahoo.com (ronan nick) Date: Sun, 26 Mar 2006 06:31:19 -0800 (PST) Subject: [Rxtx] a question about the COMM API Message-ID: <20060326143119.54919.qmail@web60014.mail.yahoo.com> hi, i was intrested in knowing how i can communicate with my internal modem using java? for example if i want to make a phone dialer application or a caller id application where should i be looking at? and as i understood the COMM API is for devices that is attached to the computer through serial ports. --------------------------------- New Yahoo! Messenger with Voice. Call regular phones from your PC and save big. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060326/ce8329f0/attachment-0033.html From dmarkman at mac.com Mon Mar 20 00:20:43 2006 From: dmarkman at mac.com (Dmitry Markman) Date: Mon, 20 Mar 2006 02:20:43 -0500 Subject: [Rxtx] Mac OS X RXTX java installer In-Reply-To: References: <07D0DE29-BA32-4CFE-B036-66BC6423D385@buechse.de> <441AE3E0.2030503@willicon.de> <12531986.1142622114996.JavaMail.dmarkman@mac.com> <441B2674.9010409@willicon.de> <13577405.1142634732776.JavaMail.dmarkman@mac.com> <441B4182.8010407@willicon.de> <92CD0D6C-5BE8-426E-A46D-99452059FF49@mac.com> <441BBB2D.8030305@willicon.de> <441C4088.5090905@willicon.de> Message-ID: <64BC1E23-FDDE-4CE6-8863-CFC881CBC224@mac.com> Hi all I put RXTX installer that will install everything (and will create / var/lock if necessary and add user to the uucp group) for mac os x from Java into the rxtx's CVS repository it could be easily modified to install files for any platform it uses Greg Guerin's AuthKit for authentication and authorization Greg released that kit under artistic license, so Trent, please take a look we, probably, can negotiate license with Greg if it's necessary Greg's AuthKit could be downloaded from http://www.amug.org/~glguerin/ sw/#authkit Michael Hall (mikehall at spacestar dot net) had a suggestion to make implementation of the jaas LoginModule based on Greg's AuthKit (his modification of the Greg's AuthKit could be found at http:// www.spacestar.net/users/mikehall/authkit.dmg) but Michael's AuthKitLoginModule does only half a job: it does authenticate but it can not run any external unix process in privileged mode (at least I wasn't able to do so) possible explanation could be found in conversation between Greg and Michael at Apple's java-dev list (look for archives) so I didn't use jaas API for rxtxinstaller I created folder MacOSX in the contrib folder comment 1. if you want to run that installer as standalone application all you need that RXTXInstaller.jar 2. if you want to use webstart you have to add Greg's libAuthKit.jnilib to the mac os x's resources in theory RXTXInstaller.jar doesn't need it, but there is a problem with loading libAuthKit.jnilib from webstart authkit uses loadLibrary method to load library and it failed (from webstart) for standalone application I extract libAuthKit.jnilib from the RXTXInstaller.jar and put it into the /Library/Java/Extensions or ~/Library/Java/Extensions folder that file will be deleted after installer quit unfortunately I didn't have time to put documentation there but it is mostly self-explanatory I took installer code from my gl4java installer that I did about 3 years ago (with small modifications) it would be very nice if Apple will release LoginModule that really will do the job (com.apple.security.auth.module package????? ) (UnixLoginModule is pretty useless) From lyon at docjava.com Mon Mar 20 06:34:39 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Mon, 20 Mar 2006 08:34:39 -0500 Subject: [Rxtx] Mac OS X RXTX java installer In-Reply-To: <64BC1E23-FDDE-4CE6-8863-CFC881CBC224@mac.com> References: <07D0DE29-BA32-4CFE-B036-66BC6423D385@buechse.de> <441AE3E0.2030503@willicon.de> <12531986.1142622114996.JavaMail.dmarkman@mac.com> <441B2674.9010409@willicon.de> <13577405.1142634732776.JavaMail.dmarkman@mac.com> <441B4182.8010407@willicon.de> <92CD0D6C-5BE8-426E-A46D-99452059FF49@mac.com> <441BBB2D.8030305@willicon.de> <441C4088.5090905@willicon.de> <64BC1E23-FDDE-4CE6-8863-CFC881CBC224@mac.com> Message-ID: Hi Dimitry, This sounds like great work. Just a couple of questions; After the check out of the CVS files, using: setenv CVSROOT :pserver:anonymous at cvs.milestonesolutions.com:/usr/local/cvsroot 53 8:28 setenv PASSWORD mousy 54 8:29 cvs login 55 8:29 cvs checkout rxtx-devel I cd'd over to: rxtx-devel/MACOSX_IDE And found: CVS/ CW/ ForPackageMaker/ PB/ Where is the installer? Thanks! - Doug From tjarvi at qbang.org Mon Mar 20 06:39:37 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 20 Mar 2006 06:39:37 -0700 (MST) Subject: [Rxtx] Mac OS X RXTX java installer In-Reply-To: References: <07D0DE29-BA32-4CFE-B036-66BC6423D385@buechse.de> <441AE3E0.2030503@willicon.de> <12531986.1142622114996.JavaMail.dmarkman@mac.com> <441B2674.9010409@willicon.de> <13577405.1142634732776.JavaMail.dmarkman@mac.com> <441B4182.8010407@willicon.de> <92CD0D6C-5BE8-426E-A46D-99452059FF49@mac.com> <441BBB2D.8030305@willicon.de> <441C4088.5090905@willicon.de> <64BC1E23-FDDE-4CE6-8863-CFC881CBC224@mac.com> Message-ID: On Mon, 20 Mar 2006, Dr. Douglas Lyon wrote: > Hi Dimitry, > This sounds like great work. Just a couple of questions; > After the check out of the CVS files, using: > setenv CVSROOT > :pserver:anonymous at cvs.milestonesolutions.com:/usr/local/cvsroot > 53 8:28 setenv PASSWORD mousy > 54 8:29 cvs login > 55 8:29 cvs checkout rxtx-devel Hi Doug You want "cvs checkout -r commapi-0-0-1 rxtx-devel" to get RXTX 2.1 The default branch is rxtx 2.0 which isn't very active right now. -- Trent Jarvi tjarvi at qbang.org From lyon at docjava.com Mon Mar 20 07:05:44 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Mon, 20 Mar 2006 09:05:44 -0500 Subject: [Rxtx] Mac OS X RXTX java installer In-Reply-To: References: <07D0DE29-BA32-4CFE-B036-66BC6423D385@buechse.de> <441AE3E0.2030503@willicon.de> <12531986.1142622114996.JavaMail.dmarkman@mac.com> <441B2674.9010409@willicon.de> <13577405.1142634732776.JavaMail.dmarkman@mac.com> <441B4182.8010407@willicon.de> <92CD0D6C-5BE8-426E-A46D-99452059FF49@mac.com> <441BBB2D.8030305@willicon.de> <441C4088.5090905@willicon.de> <64BC1E23-FDDE-4CE6-8863-CFC881CBC224@mac.com> Message-ID: Hi Trent, Thanks for the info on the CVS checkout procedure. I did that and am still not sure where the installer is. Here is what I have: cd MACOSX_IDE/ p4.docjava.com{lyon}121: ls CVS/ ForPackageMaker/ PB/ p4.docjava.com{lyon}122: find . | more . ./ForPackageMaker ./ForPackageMaker/RXTX.pkg.sit.hqx ./ForPackageMaker/Resources ./ForPackageMaker/Resources/ReadMe.rtf ./ForPackageMaker/Resources/Welcome.rtf ./ForPackageMaker/Resources/CVS ./ForPackageMaker/Resources/CVS/Entries ./ForPackageMaker/Resources/CVS/Repository ./ForPackageMaker/Resources/CVS/Tag ./ForPackageMaker/Resources/CVS/Root ./ForPackageMaker/Resources/preinstall ./ForPackageMaker/Resources/License.rtf ./ForPackageMaker/Resources/preupgrade ./ForPackageMaker/RXTX.pmsp ./ForPackageMaker/CVS ./ForPackageMaker/CVS/Entries ./ForPackageMaker/CVS/Repository ./ForPackageMaker/CVS/Entries.Log ./ForPackageMaker/CVS/Tag ./ForPackageMaker/CVS/Root ./ForPackageMaker/RXTX_Tiger.pkg.sitx.hqx ./ForPackageMaker/RXTX_Jag.pkg.sit.hqx ./ForPackageMaker/Install ./ForPackageMaker/Install/CVS ./ForPackageMaker/Install/CVS/Entries ./ForPackageMaker/Install/CVS/Repository ./ForPackageMaker/Install/CVS/Tag ./ForPackageMaker/Install/CVS/Root ./ForPackageMaker/Install/Library ./ForPackageMaker/Install/Library/CVS ./ForPackageMaker/Install/Library/CVS/Entries ./ForPackageMaker/Install/Library/CVS/Repository ./ForPackageMaker/Install/Library/CVS/Tag ./ForPackageMaker/Install/Library/CVS/Root ./ForPackageMaker/Install/Library/Java ./ForPackageMaker/Install/Library/Java/Extensions ./ForPackageMaker/Install/Library/Java/Extensions/RXTXcomm.jar ./ForPackageMaker/Install/Library/Java/Extensions/CVS ./ForPackageMaker/Install/Library/Java/Extensions/CVS/Entries ./ForPackageMaker/Install/Library/Java/Extensions/CVS/Repository ./ForPackageMaker/Install/Library/Java/Extensions/CVS/Tag ./ForPackageMaker/Install/Library/Java/Extensions/CVS/Root ./ForPackageMaker/Install/Library/Java/Extensions/librxtxSerial.jnilib ./ForPackageMaker/Install/Library/Java/CVS ./ForPackageMaker/Install/Library/Java/CVS/Entries ./ForPackageMaker/Install/Library/Java/CVS/Repository ./ForPackageMaker/Install/Library/Java/CVS/Entries.Log ./ForPackageMaker/Install/Library/Java/CVS/Tag ./ForPackageMaker/Install/Library/Java/CVS/Root ./ForPackageMaker/RXTX_Tiger.pmproj.sitx.hqx ./CVS ./CVS/Entries ./CVS/Repository ./CVS/Entries.Log ./CVS/Tag ./CVS/Root ./PB ./PB/LibSerialUniversal.xcodeproj.sitx.hqx ./PB/CVS ./PB/CVS/Entries ./PB/CVS/Repository ./PB/CVS/Entries.Log ./PB/CVS/Tag ./PB/CVS/Root ./PB/LibSerial.pbproj.sit.hqx ./PB/startpoint.c ./PB/config.h What is the procedure to run this installer? Do we need a README in: /rxtx-devel/MACOSX_IDE Here is what we have: CVS/ ForPackageMaker/ PB/ Thanks! - DL >On Mon, 20 Mar 2006, Dr. Douglas Lyon wrote: > >>Hi Dimitry, >>This sounds like great work. Just a couple of questions; >>After the check out of the CVS files, using: >>setenv CVSROOT >>:pserver:anonymous at cvs.milestonesolutions.com:/usr/local/cvsroot >> 53 8:28 setenv PASSWORD mousy >> 54 8:29 cvs login >> 55 8:29 cvs checkout rxtx-devel > >Hi Doug > >You want "cvs checkout -r commapi-0-0-1 rxtx-devel" to get RXTX 2.1 >The default branch is rxtx 2.0 which isn't very active right now. > >-- >Trent Jarvi >tjarvi at qbang.org From tjarvi at qbang.org Mon Mar 20 07:25:30 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 20 Mar 2006 07:25:30 -0700 (MST) Subject: [Rxtx] Mac OS X RXTX java installer In-Reply-To: References: <07D0DE29-BA32-4CFE-B036-66BC6423D385@buechse.de> <441AE3E0.2030503@willicon.de> <12531986.1142622114996.JavaMail.dmarkman@mac.com> <441B2674.9010409@willicon.de> <13577405.1142634732776.JavaMail.dmarkman@mac.com> <441B4182.8010407@willicon.de> <92CD0D6C-5BE8-426E-A46D-99452059FF49@mac.com> <441BBB2D.8030305@willicon.de> <441C4088.5090905@willicon.de> <64BC1E23-FDDE-4CE6-8863-CFC881CBC224@mac.com> Message-ID: On Mon, 20 Mar 2006, Dr. Douglas Lyon wrote: > Hi Trent, > Thanks for the info on the CVS checkout procedure. > I did that and am still not sure where the installer is. Hi Doug It does look like it was not cvs committed. There is no rxtx-devel/contrib/MacOSX directory in there at the moment. It was mentioned that it was put under contrib. -- Trent Jarvi tjarvi at qbang.org From dmarkman at mac.com Mon Mar 20 07:29:56 2006 From: dmarkman at mac.com (Dmitry Markman) Date: Mon, 20 Mar 2006 09:29:56 -0500 Subject: [Rxtx] Mac OS X RXTX java installer In-Reply-To: References: <07D0DE29-BA32-4CFE-B036-66BC6423D385@buechse.de> <441AE3E0.2030503@willicon.de> <12531986.1142622114996.JavaMail.dmarkman@mac.com> <441B2674.9010409@willicon.de> <13577405.1142634732776.JavaMail.dmarkman@mac.com> <441B4182.8010407@willicon.de> <92CD0D6C-5BE8-426E-A46D-99452059FF49@mac.com> <441BBB2D.8030305@willicon.de> <441C4088.5090905@willicon.de> <64BC1E23-FDDE-4CE6-8863-CFC881CBC224@mac.com> Message-ID: <6054EB4E-F7E0-4A9C-BDDA-D582D6D8826F@mac.com> you can find it in the rxtx-devel/contrib folder On Mar 20, 2006, at 9:05 AM, Dr. Douglas Lyon wrote: > Hi Trent, > Thanks for the info on the CVS checkout procedure. > I did that and am still not sure where the installer is. > Here is what I have: > cd MACOSX_IDE/ > p4.docjava.com{lyon}121: ls > CVS/ ForPackageMaker/ PB/ > p4.docjava.com{lyon}122: find . | more > . > ./ForPackageMaker > ./ForPackageMaker/RXTX.pkg.sit.hqx > ./ForPackageMaker/Resources > ./ForPackageMaker/Resources/ReadMe.rtf > ./ForPackageMaker/Resources/Welcome.rtf > ./ForPackageMaker/Resources/CVS > ./ForPackageMaker/Resources/CVS/Entries > ./ForPackageMaker/Resources/CVS/Repository > ./ForPackageMaker/Resources/CVS/Tag > ./ForPackageMaker/Resources/CVS/Root > ./ForPackageMaker/Resources/preinstall > ./ForPackageMaker/Resources/License.rtf > ./ForPackageMaker/Resources/preupgrade > ./ForPackageMaker/RXTX.pmsp > ./ForPackageMaker/CVS > ./ForPackageMaker/CVS/Entries > ./ForPackageMaker/CVS/Repository > ./ForPackageMaker/CVS/Entries.Log > ./ForPackageMaker/CVS/Tag > ./ForPackageMaker/CVS/Root > ./ForPackageMaker/RXTX_Tiger.pkg.sitx.hqx > ./ForPackageMaker/RXTX_Jag.pkg.sit.hqx > ./ForPackageMaker/Install > ./ForPackageMaker/Install/CVS > ./ForPackageMaker/Install/CVS/Entries > ./ForPackageMaker/Install/CVS/Repository > ./ForPackageMaker/Install/CVS/Tag > ./ForPackageMaker/Install/CVS/Root > ./ForPackageMaker/Install/Library > ./ForPackageMaker/Install/Library/CVS > ./ForPackageMaker/Install/Library/CVS/Entries > ./ForPackageMaker/Install/Library/CVS/Repository > ./ForPackageMaker/Install/Library/CVS/Tag > ./ForPackageMaker/Install/Library/CVS/Root > ./ForPackageMaker/Install/Library/Java > ./ForPackageMaker/Install/Library/Java/Extensions > ./ForPackageMaker/Install/Library/Java/Extensions/RXTXcomm.jar > ./ForPackageMaker/Install/Library/Java/Extensions/CVS > ./ForPackageMaker/Install/Library/Java/Extensions/CVS/Entries > ./ForPackageMaker/Install/Library/Java/Extensions/CVS/Repository > ./ForPackageMaker/Install/Library/Java/Extensions/CVS/Tag > ./ForPackageMaker/Install/Library/Java/Extensions/CVS/Root > ./ForPackageMaker/Install/Library/Java/Extensions/librxtxSerial.jnilib > ./ForPackageMaker/Install/Library/Java/CVS > ./ForPackageMaker/Install/Library/Java/CVS/Entries > ./ForPackageMaker/Install/Library/Java/CVS/Repository > ./ForPackageMaker/Install/Library/Java/CVS/Entries.Log > ./ForPackageMaker/Install/Library/Java/CVS/Tag > ./ForPackageMaker/Install/Library/Java/CVS/Root > ./ForPackageMaker/RXTX_Tiger.pmproj.sitx.hqx > ./CVS > ./CVS/Entries > ./CVS/Repository > ./CVS/Entries.Log > ./CVS/Tag > ./CVS/Root > ./PB > ./PB/LibSerialUniversal.xcodeproj.sitx.hqx > ./PB/CVS > ./PB/CVS/Entries > ./PB/CVS/Repository > ./PB/CVS/Entries.Log > ./PB/CVS/Tag > ./PB/CVS/Root > ./PB/LibSerial.pbproj.sit.hqx > ./PB/startpoint.c > ./PB/config.h > > What is the procedure to run this installer? > Do we need a README in: > /rxtx-devel/MACOSX_IDE > Here is what we have: > CVS/ ForPackageMaker/ PB/ > > > Thanks! > - DL > >> On Mon, 20 Mar 2006, Dr. Douglas Lyon wrote: >> >>> Hi Dimitry, >>> This sounds like great work. Just a couple of questions; >>> After the check out of the CVS files, using: >>> setenv CVSROOT :pserver:anonymous at cvs.milestonesolutions.com:/usr/ >>> local/cvsroot >>> 53 8:28 setenv PASSWORD mousy >>> 54 8:29 cvs login >>> 55 8:29 cvs checkout rxtx-devel >> >> Hi Doug >> >> You want "cvs checkout -r commapi-0-0-1 rxtx-devel" to get RXTX 2.1 >> The default branch is rxtx 2.0 which isn't very active right now. >> >> -- >> Trent Jarvi >> tjarvi at qbang.org > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx Dmitry Markman From mikehall at spacestar.net Mon Mar 20 05:25:25 2006 From: mikehall at spacestar.net (Michael Hall) Date: Mon, 20 Mar 2006 06:25:25 -0600 Subject: [Rxtx] Re: Mac OS X RXTX java installer In-Reply-To: <64BC1E23-FDDE-4CE6-8863-CFC881CBC224@mac.com> References: <07D0DE29-BA32-4CFE-B036-66BC6423D385@buechse.de> <441AE3E0.2030503@willicon.de> <12531986.1142622114996.JavaMail.dmarkman@mac.com> <441B2674.9010409@willicon.de> <13577405.1142634732776.JavaMail.dmarkman@mac.com> <441B4182.8010407@willicon.de> <92CD0D6C-5BE8-426E-A46D-99452059FF49@mac.com> <441BBB2D.8030305@willicon.de> <441C4088.5090905@willicon.de> <64BC1E23-FDDE-4CE6-8863-CFC881CBC224@mac.com> Message-ID: <247EB61F-5CD1-4132-89A2-FC105B6CF9A5@spacestar.net> On Mar 20, 2006, at 1:20 AM, Dmitry Markman wrote: > > Michael Hall (mikehall at spacestar dot net) had a suggestion to > make implementation of the jaas LoginModule > based on Greg's AuthKit > (his modification of the Greg's AuthKit could be found at http:// > www.spacestar.net/users/mikehall/authkit.dmg) > but Michael's AuthKitLoginModule does only half a job: > it does authenticate > but it can not run any external unix process in privileged mode (at > least I wasn't able to do so) If you got it working directly with Greg's the point is moot. But to clarify it anyhow. The login module does not allow you to do anything anything privileged on return as was explained by Greg. You need to work with a separate privileged process using the execPrivileged method of his API. I assume you did something similar although I haven't looked at how you are using it yet. I allowed instead for a action to be performed at the same time you login/authenticate,this... System.setProperty("authkit.action","/usr/bin/id"); just before this... lc.login(); To clarify, safely ignored as you are already complete. Mike Hall mikehall at spacestar dot net http://www.spacestar.net/users/mikehall http://sourceforge.net/projects/macnative -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2427 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20060320/f6e18202/smime-0036.bin From dmarkman at mac.com Mon Mar 20 07:36:47 2006 From: dmarkman at mac.com (Dmitry Markman) Date: Mon, 20 Mar 2006 09:36:47 -0500 Subject: [Rxtx] Re: Mac OS X RXTX java installer In-Reply-To: <247EB61F-5CD1-4132-89A2-FC105B6CF9A5@spacestar.net> References: <07D0DE29-BA32-4CFE-B036-66BC6423D385@buechse.de> <441AE3E0.2030503@willicon.de> <12531986.1142622114996.JavaMail.dmarkman@mac.com> <441B2674.9010409@willicon.de> <13577405.1142634732776.JavaMail.dmarkman@mac.com> <441B4182.8010407@willicon.de> <92CD0D6C-5BE8-426E-A46D-99452059FF49@mac.com> <441BBB2D.8030305@willicon.de> <441C4088.5090905@willicon.de> <64BC1E23-FDDE-4CE6-8863-CFC881CBC224@mac.com> <247EB61F-5CD1-4132-89A2-FC105B6CF9A5@spacestar.net> Message-ID: Hi, Michael all I have to do is to run some shell script I tried to use your action mechanism and it worked great so I just System.setProperty ("authkit.action","" ) and after that I even don't need to run anything like subject.doAs.... but after few thoughts I choose to use plain Greg's approach, because in that case I don't have to deal with various java's configurations files and therefore to use 2-3 -D parameters in the java command line especially it's useful for java web start (it's so fragile :-( ) thanks for the great job On Mar 20, 2006, at 7:25 AM, Michael Hall wrote: > > On Mar 20, 2006, at 1:20 AM, Dmitry Markman wrote: >> >> Michael Hall (mikehall at spacestar dot net) had a suggestion to >> make implementation of the jaas LoginModule >> based on Greg's AuthKit >> (his modification of the Greg's AuthKit could be found at http:// >> www.spacestar.net/users/mikehall/authkit.dmg) >> but Michael's AuthKitLoginModule does only half a job: >> it does authenticate >> but it can not run any external unix process in privileged mode >> (at least I wasn't able to do so) > > If you got it working directly with Greg's the point is moot. > > But to clarify it anyhow. > The login module does not allow you to do anything anything > privileged on return as was explained by Greg. You need to work > with a separate privileged process using the execPrivileged method > of his API. I assume you did something similar although I haven't > looked at how you are using it yet. > I allowed instead for a action to be performed at the same time you > login/authenticate,this... > System.setProperty("authkit.action","/usr/bin/id"); > just before this... > lc.login(); > To clarify, safely ignored as you are already complete. > > Mike Hall mikehall at spacestar dot net > http://www.spacestar.net/users/mikehall > http://sourceforge.net/projects/macnative > > > Dmitry Markman From dmarkman at mac.com Mon Mar 20 07:44:45 2006 From: dmarkman at mac.com (Dmitry Markman) Date: Mon, 20 Mar 2006 09:44:45 -0500 Subject: [Rxtx] Mac OS X RXTX java installer In-Reply-To: References: <07D0DE29-BA32-4CFE-B036-66BC6423D385@buechse.de> <441AE3E0.2030503@willicon.de> <12531986.1142622114996.JavaMail.dmarkman@mac.com> <441B2674.9010409@willicon.de> <13577405.1142634732776.JavaMail.dmarkman@mac.com> <441B4182.8010407@willicon.de> <92CD0D6C-5BE8-426E-A46D-99452059FF49@mac.com> <441BBB2D.8030305@willicon.de> <441C4088.5090905@willicon.de> <64BC1E23-FDDE-4CE6-8863-CFC881CBC224@mac.com> Message-ID: it's in the commapi-0-0-1 branch I tested it right now: cvs co -r commapi-0-0-1 rxtx-devel and I got everything On Mar 20, 2006, at 9:25 AM, Trent Jarvi wrote: > On Mon, 20 Mar 2006, Dr. Douglas Lyon wrote: > >> Hi Trent, >> Thanks for the info on the CVS checkout procedure. >> I did that and am still not sure where the installer is. > > Hi Doug > > It does look like it was not cvs committed. There is no rxtx-devel/ > contrib/MacOSX directory in there at the moment. It was mentioned > that it was put under contrib. > > -- > Trent Jarvi > tjarvi at qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx Dmitry Markman From tjarvi at qbang.org Mon Mar 20 07:52:57 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 20 Mar 2006 07:52:57 -0700 (MST) Subject: [Rxtx] Mac OS X RXTX java installer In-Reply-To: References: <07D0DE29-BA32-4CFE-B036-66BC6423D385@buechse.de> <441AE3E0.2030503@willicon.de> <12531986.1142622114996.JavaMail.dmarkman@mac.com> <441B2674.9010409@willicon.de> <13577405.1142634732776.JavaMail.dmarkman@mac.com> <441B4182.8010407@willicon.de> <92CD0D6C-5BE8-426E-A46D-99452059FF49@mac.com> <441BBB2D.8030305@willicon.de> <441C4088.5090905@willicon.de> <64BC1E23-FDDE-4CE6-8863-CFC881CBC224@mac.com> Message-ID: On Mon, 20 Mar 2006, Dmitry Markman wrote: > it's in the commapi-0-0-1 branch > > I tested it right now: > cvs co -r commapi-0-0-1 rxtx-devel > > and I got everything > A fresh checkout worked. Here is a copy of the tree (just the installer bits) ftp://ftp.qbang.org/pub/rxtx/MacOSX-installer.zip -- Trent Jarvi tjarvi at qbang.org From lyon at docjava.com Mon Mar 20 08:08:26 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Mon, 20 Mar 2006 10:08:26 -0500 Subject: [Rxtx] Mac OS X RXTX java installer In-Reply-To: References: <07D0DE29-BA32-4CFE-B036-66BC6423D385@buechse.de> <441AE3E0.2030503@willicon.de> <12531986.1142622114996.JavaMail.dmarkman@mac.com> <441B2674.9010409@willicon.de> <13577405.1142634732776.JavaMail.dmarkman@mac.com> <441B4182.8010407@willicon.de> <92CD0D6C-5BE8-426E-A46D-99452059FF49@mac.com> <441BBB2D.8030305@willicon.de> <441C4088.5090905@willicon.de> <64BC1E23-FDDE-4CE6-8863-CFC881CBC224@mac.com> Message-ID: Hi All, Is the Auth package able to work properly on non Mac OS's? It was not clear from the doc or download. Thanks! - Doug From dmarkman at mac.com Mon Mar 20 08:15:22 2006 From: dmarkman at mac.com (Dmitry Markman) Date: Mon, 20 Mar 2006 10:15:22 -0500 Subject: [Rxtx] Mac OS X RXTX java installer In-Reply-To: References: <07D0DE29-BA32-4CFE-B036-66BC6423D385@buechse.de> <441AE3E0.2030503@willicon.de> <12531986.1142622114996.JavaMail.dmarkman@mac.com> <441B2674.9010409@willicon.de> <13577405.1142634732776.JavaMail.dmarkman@mac.com> <441B4182.8010407@willicon.de> <92CD0D6C-5BE8-426E-A46D-99452059FF49@mac.com> <441BBB2D.8030305@willicon.de> <441C4088.5090905@willicon.de> <64BC1E23-FDDE-4CE6-8863-CFC881CBC224@mac.com> Message-ID: <217312D8-CCCA-4859-ABA6-32DF1CC817B9@mac.com> thanks Trent, for putting it on ftp server On Mar 20, 2006, at 9:52 AM, Trent Jarvi wrote: > A fresh checkout worked. Here is a copy of the tree (just the > installer bits) > > ftp://ftp.qbang.org/pub/rxtx/MacOSX-installer.zip > Dmitry Markman From dmarkman at mac.com Mon Mar 20 09:14:03 2006 From: dmarkman at mac.com (Dmitry Markman) Date: Mon, 20 Mar 2006 11:14:03 -0500 Subject: [Rxtx] Mac OS X RXTX java installer In-Reply-To: References: <07D0DE29-BA32-4CFE-B036-66BC6423D385@buechse.de> <441AE3E0.2030503@willicon.de> <12531986.1142622114996.JavaMail.dmarkman@mac.com> <441B2674.9010409@willicon.de> <13577405.1142634732776.JavaMail.dmarkman@mac.com> <441B4182.8010407@willicon.de> <92CD0D6C-5BE8-426E-A46D-99452059FF49@mac.com> <441BBB2D.8030305@willicon.de> <441C4088.5090905@willicon.de> <64BC1E23-FDDE-4CE6-8863-CFC881CBC224@mac.com> Message-ID: <4DEBA6F0-DA45-4E84-823E-1F1AC48BDCCC@mac.com> no it will work only on mac os x however it's harmless to run it on other platform if you want to use it for other platform you have to do the following (I'll do it for linux) 1. modify RXTXInstaller class method public static RXTXInstaller getInstance() public static RXTXInstaller getInstance() { String osName = System.getProperty("os.name").toLowerCase(); if(osName.startsWith("mac")){ return new gnu.io.installer.macosx.MACOSXRXTXInstaller(); } else if(osName.startsWith("windows")){ return new gnu.io.installer.windows.WindowsRXTXInstaller(); }else if(osName.startsWith("linux")){ return new gnu.io.installer.linux.LinuxRXTXInstaller(); } return null; } 2. create folder gnu/io/installer/linux/ 3. create class Linux386RXTXInstaller package gnu.io.installer.linux; import java.io.File; public class Linux386RXTXInstaller extends gnu.io.installer.RXTXInstaller{ public Linux386RXTXInstaller(){ createJarFolder(); createLibFolder(); addJarResource("RXTXcomm.jar","/gnu/io/installer/resources/ linux/jar/RXTXcomm.dat"); addLibResource("librxtxSerial.so","/gnu/io/installer/ resources/linux/lib/librxtxSerial.so"); } protected void createJarFolder(){ String javaHome = System.getProperty("java.home"); char separator = File.separatorChar; jarFolder = new File(javaHome+separator+"lib"+separator+"ext"); } protected void createLibFolder(){ String javaHome = System.getProperty("java.home"); char separator = File.separatorChar; libFolder = new File(javaHome+separator+"bin"); } public void runPreProcess() {} //put here some action you need public void runPostProcess() {} //put here some action you need } 4. create folder /gnu/io/installer/resources/linux/jar and put there linux's version of RXTXcomm.dat (which is renamed RXTXcomm.jar) 5. create folder /gnu/io/installer/resources/linux/lib and put there linux's version of librxtxSerial. so 6. make sure that RXTXInstaller.jar has the following items: /gnu/io/installer/resources/linux/jar/RXTXcomm.jar /gnu/io/installer/resources/linux/lib/librxtxSerial.so 7. modify file installer.pref: jar file RXTXInstaller.jar must have the following item /gnu/io/installer/installer.pref that's basically it for windows you have to do the similar things: just replace linux to windows and librxtxSerial.so to rxtxSerial.dll and create appropriate gnu.io.installer.windows.WindowsRXTXInstaller class package gnu.io.installer.windows; import java.io.File; public class WindowsRXTXInstaller extends gnu.io.installer.RXTXInstaller{ public WindowsRXTXInstaller(){ createJarFolder(); createLibFolder(); addJarResource("RXTXcomm.jar","/gnu/io/installer/resources/ windows/jar/RXTXcomm.dat"); addLibResource("librxtxSerial.so","/gnu/io/installer/ resources/windows/lib/rxtxSerial.dll"); } protected void createJarFolder(){ String javaHome = System.getProperty("java.home"); char separator = File.separatorChar; jarFolder = new File(javaHome+separator+"lib"+separator+"ext"); } protected void createLibFolder(){ String javaHome = System.getProperty("java.home"); char separator = File.separatorChar; libFolder = new File(javaHome+separator+"bin"); } public void runPreProcess() {} //put here some action you need public void runPostProcess() {} //put here some action you need } installer.pref will look like On Mar 20, 2006, at 10:08 AM, Dr. Douglas Lyon wrote: > Hi All, > Is the Auth package able to work properly on > non Mac OS's? > It was not clear from the doc or download. > > Thanks! > - Doug > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx Dmitry Markman From joachim at buechse.de Mon Mar 20 10:49:06 2006 From: joachim at buechse.de (Joachim Buechse) Date: Mon, 20 Mar 2006 18:49:06 +0100 Subject: [Rxtx] BUG: Lock file stays even if port opening fails Message-ID: This was only tested on MacOSX but looking at the code, it should be true for all systems that use lock_uucp. I am opening a port which can not be opened (dialup port of a telephone paired via bluetooth but currently not reachable). The lock file is created and stays arround, even though the port open failed. After looking a bit through the code (of 2.17), I really wonder if it wouldn't be a good idea to make the "locking" an explicit operation called from the java code. This would certainly simplify the generation of meaningfull exceptions (and java based debugging). Maybe even the handling of "preopened" ports should be in the Java part of the lib (again for java based debugging puposes). That beeing said, I have no idea if this would be possible for the 2.07 implementation. Regards, Joachim From tjarvi at qbang.org Mon Mar 20 11:24:22 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 20 Mar 2006 11:24:22 -0700 (MST) Subject: [Rxtx] BUG: Lock file stays even if port opening fails In-Reply-To: References: Message-ID: On Mon, 20 Mar 2006, Joachim Buechse wrote: > This was only tested on MacOSX but looking at the code, it should be true > for all systems that use lock_uucp. > > I am opening a port which can not be opened (dialup port of a telephone > paired via bluetooth but currently not reachable). The lock file is > created and stays arround, even though the port open failed. > > > After looking a bit through the code (of 2.17), I really wonder if it > wouldn't be a good idea to make the "locking" an explicit operation > called from the java code. This would certainly simplify the generation > of meaningfull exceptions (and java based debugging). > Maybe even the handling of "preopened" ports should be in the Java part > of the lib (again for java based debugging puposes). That beeing said, I > have no idea if this would be possible for the 2.07 implementation. > > Regards, Hi Joachim It should be possible in the 2.0-7 implementation too. The calls to RXTXPort.java would not change. We would just do more there Moving more of that logic into Java would be better as many people don't like to look at C code. There is a liblockdev on most Linux distros that can do most of the C code and would be easier to use. The problem is embeded devices will not have that library. The preopened port code has not been really tested. That was a last minute request in a product cycle. I expect it will be tested this year though. As I recall, some devices really do not like CD raising on open. The preopened ports then allow people to mess around in java without power cycling the devices or losing data. -- Trent Jarvi tjarvi at qbang.org From joachim at buechse.de Mon Mar 20 12:01:08 2006 From: joachim at buechse.de (Joachim Buechse) Date: Mon, 20 Mar 2006 20:01:08 +0100 Subject: [Rxtx] BUG: Lock file stays even if port opening fails In-Reply-To: References: Message-ID: Hi Trent, What is your general feeling about moving code to Java? The last days I have been reading quite a bit of the code and there are several things, that might not work as expected. I'll give you two examples from is_device_locked: if LOCKDIR == /var/spool/locks the directory /var/spool/lock will not be checked. LOCKDIR is not checked for lockfiles with unexpected pefixes While these things have probably never been discovered in production, they are still possibly incorrect implementations. If it was Java code, I would write some unit tests producing the errors that could later be corrected. PS: One could imagine to actually implement the whole lockfile handling in Java using some native routines to get the values required (pid, st_dev, st_rdev, ...). On 20.03.2006, at 19:24, Trent Jarvi wrote: > On Mon, 20 Mar 2006, Joachim Buechse wrote: > >> This was only tested on MacOSX but looking at the code, it should >> be true for all systems that use lock_uucp. >> >> I am opening a port which can not be opened (dialup port of a >> telephone paired via bluetooth but currently not reachable). The >> lock file is created and stays arround, even though the port open >> failed. >> >> >> After looking a bit through the code (of 2.17), I really wonder if >> it wouldn't be a good idea to make the "locking" an explicit >> operation called from the java code. This would certainly simplify >> the generation of meaningfull exceptions (and java based debugging). >> Maybe even the handling of "preopened" ports should be in the Java >> part of the lib (again for java based debugging puposes). That >> beeing said, I have no idea if this would be possible for the 2.07 >> implementation. >> >> Regards, > > Hi Joachim > > It should be possible in the 2.0-7 implementation too. The calls > to RXTXPort.java would not change. We would just do more there > Moving more of that logic into Java would be better as many people > don't like to look at C code. There is a liblockdev on most Linux > distros that can do most of the C code and would be easier to use. > The problem is embeded devices will not have that library. > > The preopened port code has not been really tested. That was a > last minute request in a product cycle. I expect it will be tested > this year though. As I recall, some devices really do not like CD > raising on open. The preopened ports then allow people to mess > around in java without power cycling the devices or losing data. > > -- > Trent Jarvi > tjarvi at qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Mon Mar 20 12:21:02 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 20 Mar 2006 12:21:02 -0700 (MST) Subject: [Rxtx] BUG: Lock file stays even if port opening fails In-Reply-To: References: Message-ID: On Mon, 20 Mar 2006, Joachim Buechse wrote: > Hi Trent, > > What is your general feeling about moving code to Java? The last days I > have been reading quite a bit of the code and there are several things, > that might not work as expected. > > I'll give you two examples from is_device_locked: > > if LOCKDIR == /var/spool/locks the directory /var/spool/lock will not be > checked. > LOCKDIR is not checked for lockfiles with unexpected pefixes > > While these things have probably never been discovered in production, > they are still possibly incorrect implementations. If it was Java code, I > would write some unit tests producing the errors that could later be > corrected. > > PS: One could imagine to actually implement the whole lockfile handling > in Java using some native routines to get the values required (pid, > st_dev, st_rdev, ...). Hi Joachim I like the idea of moving more of the code into java but there are some things to consider. If you break this into multiple JNI calls, the performance will drop considerably during enumeration of ports. We are looking for 256 ports per dev type vs (16? in Sun's 2.0 and fewer types). Its hard to make assumptions. I've seen virtual ports start at /dev/foo100 for instance. It works out to over 7500 ports on Linux if you enable them all. We already trim that back by default. See Linux-all-ports in RXTXCommDriver.java. There are also native libraries that rxtx can link to. If you move too much into Java, linking to 'standard' libraries with distros will break. "configure --enable-liblock=yes" will not be doable. This is probably a favorable way with RedHat, Debian, Suse and others. Thats the right thing to do if there will be rpms, dpkg, .. For those reasons, I think it still make sense to keep it to a minimal ~3 calls to JNI code that we can use for speed and versatility. lock() isLocked(), unlock() perhaps. When I say speed, its more about avoiding crossing the JNI layer multiple times than java vs C performance. With versatility I think liblock is the right way for most but not all (embeded) linux distros. -- Trent Jarvi tjarvi at qbang.org From joachim at buechse.de Mon Mar 20 12:42:04 2006 From: joachim at buechse.de (Joachim Buechse) Date: Mon, 20 Mar 2006 20:42:04 +0100 Subject: [Rxtx] BUG: Lock file stays even if port opening fails In-Reply-To: References: Message-ID: <82C19FE7-DDCB-45B6-B2C9-7606B66F0124@buechse.de> Ok, what about providing a default implementation in Java? The RXTXCommDriver would call a (native) function useNativeLocking and if it returns true, call the native functions for lock() isLocked (), unlock(), else is would use the Java based default implementation. This could possibly be overriden by a property (again for debugging). Joachim On 20.03.2006, at 20:21, Trent Jarvi wrote: > On Mon, 20 Mar 2006, Joachim Buechse wrote: > >> Hi Trent, >> >> What is your general feeling about moving code to Java? The last >> days I have been reading quite a bit of the code and there are >> several things, that might not work as expected. >> >> I'll give you two examples from is_device_locked: >> >> if LOCKDIR == /var/spool/locks the directory /var/spool/lock will >> not be checked. >> LOCKDIR is not checked for lockfiles with unexpected pefixes >> >> While these things have probably never been discovered in >> production, they are still possibly incorrect implementations. If >> it was Java code, I would write some unit tests producing the >> errors that could later be corrected. >> >> PS: One could imagine to actually implement the whole lockfile >> handling in Java using some native routines to get the values >> required (pid, st_dev, st_rdev, ...). > > Hi Joachim > > I like the idea of moving more of the code into java but there are > some things to consider. > > If you break this into multiple JNI calls, the performance will > drop considerably during enumeration of ports. We are looking for > 256 ports per dev type vs (16? in Sun's 2.0 and fewer types). Its > hard to make assumptions. I've seen virtual ports start at /dev/ > foo100 for instance. > > It works out to over 7500 ports on Linux if you enable them all. > We already trim that back by default. See Linux-all-ports in > RXTXCommDriver.java. > > There are also native libraries that rxtx can link to. If you move > too much into Java, linking to 'standard' libraries with distros > will break. "configure --enable-liblock=yes" will not be doable. > This is probably a favorable way with RedHat, Debian, Suse and > others. Thats the right thing to do if there will be rpms, dpkg, .. > > For those reasons, I think it still make sense to keep it to a > minimal ~3 calls to JNI code that we can use for speed and > versatility. lock() isLocked(), unlock() perhaps. When I say > speed, its more about avoiding crossing the JNI layer multiple > times than java vs C performance. With versatility I think liblock > is the right way for most but not all (embeded) linux distros. > > -- > Trent Jarvi > tjarvi at qbang.org > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Mon Mar 20 12:44:47 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 20 Mar 2006 12:44:47 -0700 (MST) Subject: [Rxtx] BUG: Lock file stays even if port opening fails In-Reply-To: <82C19FE7-DDCB-45B6-B2C9-7606B66F0124@buechse.de> References: <82C19FE7-DDCB-45B6-B2C9-7606B66F0124@buechse.de> Message-ID: On Mon, 20 Mar 2006, Joachim Buechse wrote: > Ok, what about providing a default implementation in Java? > > The RXTXCommDriver would call a (native) function useNativeLocking and if > it returns true, call the native functions for lock() isLocked(), > unlock(), else is would use the Java based default implementation. This > could possibly be overriden by a property (again for debugging). > Hi Joachim That would be OK with me. -- Trent Jarvi tjarvi at qbang.org From dmarkman at mac.com Mon Mar 20 22:27:45 2006 From: dmarkman at mac.com (Dmitry Markman) Date: Tue, 21 Mar 2006 00:27:45 -0500 Subject: [Rxtx] binaries request Message-ID: <42702213-C222-4937-A585-7CFB17E47608@mac.com> Hi can somebody send me latest linux and windows binaries, please? or where I can find them (I didn't find them in the latest tareball) I gave up with my cygwin: something wrong I have no idea what java doesn't understand /cygwin/c syntax after I changed makefile it did java part but after that gcc 3.4.4 started to complain I set buffer length to 999 lines but I didn't get beginning of the story something wrong with my 1.4.2_09/include/jni.h gcc doesn't like it anyway I gave up thanks in advance Dmitry Markman -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060320/f8cbc57c/attachment-0036.html From tjarvi at qbang.org Mon Mar 20 22:36:48 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 20 Mar 2006 22:36:48 -0700 (MST) Subject: [Rxtx] binaries request In-Reply-To: <42702213-C222-4937-A585-7CFB17E47608@mac.com> References: <42702213-C222-4937-A585-7CFB17E47608@mac.com> Message-ID: On Tue, 21 Mar 2006, Dmitry Markman wrote: > Hi > can somebody send me latest linux and windows binaries, please? > > or where I can find them (I didn't find them in the latest tareball) > > I gave up with my cygwin: something wrong I have no idea what > java doesn't understand /cygwin/c syntax > after I changed makefile it did java part > but after that gcc 3.4.4 started to complain > I set buffer length to 999 lines but I didn't get beginning of the story > something wrong with my 1.4.2_09/include/jni.h gcc doesn't like it > anyway I gave up > > thanks in advance > Hi Dmitry The bins are here: ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7-bins-r2.zip Here are the files in the zip you want. Jar: rxtx-2.1-7-bins-r2/RXTXcomm.jar Windows: rxtx-2.1-7-bins-r2/Windows/i368-mingw32/rxtxSerial.dll Linux (x86) rxtx-2.1-7-bins-r2/Linux/i686-unknown-linux-gnu/librxtxSerial.so There are others in there including Parallel port support but those are the main ones for testing. -- Trent Jarvi tjarvi at qbang.org From dmarkman at mac.com Mon Mar 20 23:05:59 2006 From: dmarkman at mac.com (Dmitry Markman) Date: Tue, 21 Mar 2006 01:05:59 -0500 Subject: [Rxtx] binaries request In-Reply-To: References: <42702213-C222-4937-A585-7CFB17E47608@mac.com> Message-ID: thank you very much but windows's readme says: rxtxSerial.dll had to be recomopiled to link in missing native methods. should I ignore it? or what? thanks again also I understand that I should use mingw not cygwin I'll try to install mingw On Mar 21, 2006, at 12:36 AM, Trent Jarvi wrote: > On Tue, 21 Mar 2006, Dmitry Markman wrote: > >> Hi >> can somebody send me latest linux and windows binaries, please? >> >> or where I can find them (I didn't find them in the latest tareball) >> >> I gave up with my cygwin: something wrong I have no idea what >> java doesn't understand /cygwin/c syntax >> after I changed makefile it did java part >> but after that gcc 3.4.4 started to complain >> I set buffer length to 999 lines but I didn't get beginning of the >> story >> something wrong with my 1.4.2_09/include/jni.h gcc doesn't like it >> anyway I gave up >> >> thanks in advance >> > > Hi Dmitry > > The bins are here: > > ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7-bins-r2.zip > > Here are the files in the zip you want. > > Jar: > > rxtx-2.1-7-bins-r2/RXTXcomm.jar > > Windows: > > rxtx-2.1-7-bins-r2/Windows/i368-mingw32/rxtxSerial.dll > > Linux (x86) > > rxtx-2.1-7-bins-r2/Linux/i686-unknown-linux-gnu/librxtxSerial.so > > There are others in there including Parallel port support but those > are the main ones for testing. > > -- > Trent Jarvi > tjarvi at qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx Dmitry Markman From tjarvi at qbang.org Mon Mar 20 23:20:33 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 20 Mar 2006 23:20:33 -0700 (MST) Subject: [Rxtx] binaries request In-Reply-To: References: <42702213-C222-4937-A585-7CFB17E47608@mac.com> Message-ID: On Tue, 21 Mar 2006, Dmitry Markman wrote: > thank you very much > > but windows's readme says: > rxtxSerial.dll had to be recomopiled to link in missing native methods. > > should I ignore it? or what? > Hi Dmitry That dll should be OK. r2 is the recompile linked to the missing native method. The readme explains why it was recompiled; fuser.o was not linked into the dll in the first release. -- Trent Jarvi tjarvi at qbang.org From ariantristan at yahoo.com Mon Mar 20 23:55:24 2006 From: ariantristan at yahoo.com (Lambok Sianturi) Date: Mon, 20 Mar 2006 22:55:24 -0800 (PST) Subject: [Rxtx] jvm issue Message-ID: <20060321065524.94779.qmail@web50701.mail.yahoo.com> Hi All, This is my first time to join RxTx mailing list. I thank you all for allowing others to sign in in requests help. I use the latest RxTx lib in Fedora 3 with java version 1.4.2_09 b05. And I got this error: # # An unexpected error has been detected by HotSpot Virtual Machine: # # SIGSEGV (0xb) at pc=0x00bf27f3, pid=2633, tid=3086112448 # # Java VM: Java HotSpot(TM) Client VM (1.4.2_09-b05 mixed mode) # Problematic frame: # C [ld-linux.so.2+0xa7f3] # # An error report file with more information is saved as hs_err_pid2633.log # # If you would like to submit a bug report, please visit: # http://java.sun.com/webapps/bugreport/crash.jsp # ./run.sh: line 3: 2633 Aborted /usr/local/java/bin/java -Djava.library.path=/usr/local/java/jre/lib/ -Djsmsengine.debug=true -classpath jsmsengine.jar:smsgateway.jar:classes12.jar:RXTXcomm.jar:. com.api.sms.SMSServer What is the jvm depedency for the latest library? Can I use 1.4.2_09 b05? Thanks in advance. Arian --------------------------------- Yahoo! Mail Use Photomail to share photos without annoying attachments. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060320/83d58dd7/attachment-0036.html From f.frumento at ngi.it Tue Mar 21 00:21:47 2006 From: f.frumento at ngi.it (Fabio Frumento) Date: Tue, 21 Mar 2006 08:21:47 +0100 Subject: [Rxtx] Javadoc on the go Message-ID: <441FA98B.9050701@ngi.it> Hi Trent, sorry for the big delay but my job is running wild, i was out for some time but now i'm back and ready to continue the javadoc for Rxtx. Did you used the last javadoc patch i sent you ? let me know if i have to send it to you again or not. regards Fabio From lyon at docjava.com Tue Mar 21 00:51:18 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Tue, 21 Mar 2006 02:51:18 -0500 Subject: [Rxtx] lock files Message-ID: Hi All, You know, if the use of lock files were under Java control (rather than a build-time decision), it might enable a more unified binary distro. It might also facilitate quick prototyping of non-lock file approaches to resolving serial port contention issues (i.e., mac-like approaches vs. linux approaches, etc.). I realize that this is a radical overhaul of the lock file policy issue. Also, it may harm performance. On the other hand, our benchmarks on JNI overhead for modern processors indicate performance impact should be minimal. Perhaps it is more of an issue with the toybox systems. Suppose there were a class with a reasonable default...someone might write: SerialPortLockPolicy.setPolicy(SerialPortLockPolicy.UNIX_LOCK_FILE); SerialPortLockPolicy.setPolicy(SerialPortLockPolicy.NO_LOCK_CHECKING); SerialPortLockPolicy.setPolicy(SerialPortLockPolicy.MAC_STYLE); Thus, we could have a run-time reconfiguration of the serial port lock policy. A special NO_LOCK version of the binary would no longer be required. Any thoughts on this? Thanks! - Doug From joachim at buechse.de Tue Mar 21 03:09:09 2006 From: joachim at buechse.de (Joachim Buechse) Date: Tue, 21 Mar 2006 11:09:09 +0100 Subject: [Rxtx] lock files In-Reply-To: References: Message-ID: <8E12916A-1B9A-4FF2-B684-E2D1C794221B@buechse.de> This is pretty much what I thought about when I suggested, that the default behaviour could be overwritten with a property. I am very much in favor of this approach. In particular this allows much easier debugging for PC based java developers. I think big parts of the Java (and maybe some parts of the C code) could use a bit of a structural workover (unit tests, javadoc, synchronization, etc). Maybe there should be a CVS branch for this experimental version. I'd be happy to contribute a first workover for some of the Java code. Designing for testability and implementing a good bunch of unit tests has been a strategy that worked quite well in the Java projects I lead. And it ultimately allows more liberal change permission. Regards, Joachim On 21.03.2006, at 08:51, Dr. Douglas Lyon wrote: > Hi All, > You know, if the use of lock files were > under Java control (rather than a build-time decision), > it might enable a more unified binary distro. It might also > facilitate quick prototyping of non-lock file approaches > to resolving serial port contention issues (i.e., mac-like > approaches vs. linux approaches, etc.). > > I realize that this is a radical overhaul of the lock file policy > issue. Also, it may harm performance. On the other hand, > our benchmarks on JNI overhead for modern processors indicate > performance impact should be minimal. Perhaps it is more of > an issue with the toybox systems. > > Suppose there were a class with a reasonable default...someone > might write: > SerialPortLockPolicy.setPolicy(SerialPortLockPolicy.UNIX_LOCK_FILE); > SerialPortLockPolicy.setPolicy(SerialPortLockPolicy.NO_LOCK_CHECKING); > SerialPortLockPolicy.setPolicy(SerialPortLockPolicy.MAC_STYLE); > > Thus, we could have a run-time reconfiguration of the serial port lock > policy. A special NO_LOCK version of the binary would no longer > be required. > > Any thoughts on this? > > Thanks! > - Doug > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From joachim at buechse.de Tue Mar 21 06:23:08 2006 From: joachim at buechse.de (Joachim Buechse) Date: Tue, 21 Mar 2006 14:23:08 +0100 Subject: [Rxtx] PATCH: use of ioctl(fd, TIOCEXCL) instead of lockfiles Message-ID: <923AE774-EEA2-4911-92D8-32BB27802C8B@buechse.de> Here is the patch for the ioctl(fd, TIOCEXCL). I have verified this only for OSX 10.4.5, hence it is only defined for APPLE. However, it should work at least for Solaris as well. If a process has requested TIOEXCL further open calls by other user processes will fail. The patch also disables uucp style locking for APPLE. Obviously this is discussable. I think it is the way to go, as it eliminates creating the lock directory which doesnt exist on the standard installation and it eliminates messing with the system group definitions (adding users to group uucp). Regarding the possibility of root processes opening a device which is locked - I consider this a feature not a potential problem. It is highly unlikely, that somebody is crazy enough to run a JavaVM as root (unless he has no other means of getting a restricted IP port opened, ie doesnt understand ipfw). Anyway, even if the process runs as root, it fails when calling ioctl(fd, TIOCEXCL). It could however still open the port to listen for RING events. I.e. a fax server which needs to see incoming calls but otherwise doesnt want to block the port. So the only case where the proposed mechanism fails is, if an incorrectly implemented process running as root conflicts with a user process. I think this can be accepted. Regards, Joachim PS: If this patch is generally accepted, the installer and Mac doku should obviously be changed as well. Index: SerialImp.c =================================================================== RCS file: /usr/local/cvsroot/rxtx-devel/src/SerialImp.c,v retrieving revision 1.46.2.187 diff -u -r1.46.2.187 SerialImp.c --- SerialImp.c 29 Jan 2006 22:19:04 -0000 1.46.2.187 +++ SerialImp.c 21 Mar 2006 12:59:16 -0000 @@ -656,6 +656,25 @@ fd=OPEN (filename, O_RDWR | O_NOCTTY | O_NONBLOCK ); } while (fd < 0 && errno==EINTR); +#ifdef OPEN_EXCL + // Note that open() follows POSIX semantics: multiple open() calls to + // the same file will succeed unless the TIOCEXCL ioctl is issued. + // This will prevent additional opens except by root-owned processes. + // See tty(4) ("man 4 tty") and ioctl(2) ("man 2 ioctl") for details. + + if (fd >= 0 && (ioctl(fd, TIOCEXCL) == -1)) + { + sprintf( message, "open: exclusive access denied for % s\n", + filename ); + report( message ); + report_error( message ); + + close(fd); + goto fail; + } +#endif /* OPEN_EXCL */ + + if( configure_port( fd ) ) goto fail; (*env)->ReleaseStringUTFChars( env, jstr, filename ); sprintf( message, "open: fd returned is %i\n", fd ); Index: SerialImp.h =================================================================== RCS file: /usr/local/cvsroot/rxtx-devel/src/SerialImp.h,v retrieving revision 1.11.2.49 diff -u -r1.11.2.49 SerialImp.h --- SerialImp.h 5 Jul 2005 17:47:21 -0000 1.11.2.49 +++ SerialImp.h 21 Mar 2006 12:59:17 -0000 @@ -135,7 +135,8 @@ /*# define LOCKDIR "/var/spool/uucp"*/ # define LOCKDIR "/var/lock" # define LOCKFILEPREFIX "LK." -# define UUCP +/*# define UUCP*/ +# define OPEN_EXCL #endif /* __APPLE__ */ #if defined(__NetBSD__) # define DEVICEDIR "/dev/" From tjarvi at qbang.org Tue Mar 21 10:26:08 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 21 Mar 2006 10:26:08 -0700 (MST) Subject: [Rxtx] Javadoc on the go In-Reply-To: <441FA98B.9050701@ngi.it> References: <441FA98B.9050701@ngi.it> Message-ID: On Tue, 21 Mar 2006, Fabio Frumento wrote: > Hi Trent, > > sorry for the big delay but my job is running wild, i was out for some > time but now i'm back and ready to continue the javadoc for Rxtx. > > Did you used the last javadoc patch i sent you ? let me know if i have to > send it to you again or not. > > regards > > Fabio Hi Fabio The patch is in the rxtx mail-list archives. It will be going in soon. I did not see a time critical portion. I'll probably be going through the list since the last batch of patches this weekend and putting them into CVS. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Tue Mar 21 10:57:18 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 21 Mar 2006 10:57:18 -0700 (MST) Subject: [Rxtx] jvm issue In-Reply-To: <20060321065524.94779.qmail@web50701.mail.yahoo.com> References: <20060321065524.94779.qmail@web50701.mail.yahoo.com> Message-ID: On Mon, 20 Mar 2006, Lambok Sianturi wrote: > Hi All, > This is my first time to join RxTx mailing list. I thank you all for allowing others to sign in in requests help. > I use the latest RxTx lib in Fedora 3 with java version 1.4.2_09 b05. And I got this error: > > # > # An unexpected error has been detected by HotSpot Virtual Machine: > # > # SIGSEGV (0xb) at pc=0x00bf27f3, pid=2633, tid=3086112448 > # > # Java VM: Java HotSpot(TM) Client VM (1.4.2_09-b05 mixed mode) > # Problematic frame: > # C [ld-linux.so.2+0xa7f3] A native library loading error? What happens if you recompile rxtx on your system and install that? This sounds like an ABI problem? rxtx 2.1-7 was compiled with a gcc 2.96 toolchain as I recall. The hope is newer system will be backwards compatible. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Tue Mar 21 11:05:29 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 21 Mar 2006 11:05:29 -0700 (MST) Subject: [Rxtx] PATCH: use of ioctl(fd, TIOCEXCL) instead of lockfiles In-Reply-To: <923AE774-EEA2-4911-92D8-32BB27802C8B@buechse.de> References: <923AE774-EEA2-4911-92D8-32BB27802C8B@buechse.de> Message-ID: On Tue, 21 Mar 2006, Joachim Buechse wrote: > Here is the patch for the ioctl(fd, TIOCEXCL). I have verified this only > for OSX 10.4.5, hence it is only defined for APPLE. However, it should > work at least for Solaris as well. > > If a process has requested TIOEXCL further open calls by other user > processes will fail. > > The patch also disables uucp style locking for APPLE. Obviously this is > discussable. I think it is the way to go, as it eliminates creating the > lock directory which doesnt exist on the standard installation and it > eliminates messing with the system group definitions (adding users to > group uucp). > > Regarding the possibility of root processes opening a device which is > locked - I consider this a feature not a potential problem. It is highly > unlikely, that somebody is crazy enough to run a JavaVM as root (unless > he has no other means of getting a restricted IP port opened, ie doesnt > understand ipfw). Anyway, even if the process runs as root, it fails when > calling ioctl(fd, TIOCEXCL). It could however still open the port to > listen for RING events. I.e. a fax server which needs to see incoming > calls but otherwise doesnt want to block the port. So the only case where > the proposed mechanism fails is, if an incorrectly implemented process > running as root conflicts with a user process. I think this can be > accepted. > > Regards, > Joachim > > PS: If this patch is generally accepted, the installer and Mac doku > should obviously be changed as well. > > > Index: SerialImp.c > =================================================================== > RCS file: /usr/local/cvsroot/rxtx-devel/src/SerialImp.c,v > retrieving revision 1.46.2.187 > diff -u -r1.46.2.187 SerialImp.c > --- SerialImp.c 29 Jan 2006 22:19:04 -0000 1.46.2.187 > +++ SerialImp.c 21 Mar 2006 12:59:16 -0000 > @@ -656,6 +656,25 @@ > fd=OPEN (filename, O_RDWR | O_NOCTTY | O_NONBLOCK ); > } while (fd < 0 && errno==EINTR); > > +#ifdef OPEN_EXCL > + // Note that open() follows POSIX semantics: multiple open() > calls to > + // the same file will succeed unless the TIOCEXCL ioctl is > issued. > + // This will prevent additional opens except by root-owned > processes. > + // See tty(4) ("man 4 tty") and ioctl(2) ("man 2 ioctl") for > details. > + > + if (fd >= 0 && (ioctl(fd, TIOCEXCL) == -1)) > + { > + sprintf( message, "open: exclusive access denied for % > s\n", > + filename ); > + report( message ); > + report_error( message ); > + > + close(fd); > + goto fail; > + } > +#endif /* OPEN_EXCL */ > + > + > if( configure_port( fd ) ) goto fail; > (*env)->ReleaseStringUTFChars( env, jstr, filename ); > sprintf( message, "open: fd returned is %i\n", fd ); > Index: SerialImp.h > =================================================================== > RCS file: /usr/local/cvsroot/rxtx-devel/src/SerialImp.h,v > retrieving revision 1.11.2.49 > diff -u -r1.11.2.49 SerialImp.h > --- SerialImp.h 5 Jul 2005 17:47:21 -0000 1.11.2.49 > +++ SerialImp.h 21 Mar 2006 12:59:17 -0000 > @@ -135,7 +135,8 @@ > /*# define LOCKDIR "/var/spool/uucp"*/ > # define LOCKDIR "/var/lock" > # define LOCKFILEPREFIX "LK." > -# define UUCP > +/*# define UUCP*/ > +# define OPEN_EXCL > #endif /* __APPLE__ */ > #if defined(__NetBSD__) > # define DEVICEDIR "/dev/" > This looks like a good start. What do you think Dmitry? Perhaps all systems with TIOCEXCL defined should use that though. Even if they use lockfiles. It wont hurt anything. That would catch people hacking their own serial apps without checking lockfiles. Its a good idea to avoid C++ style comments in the C portions. Some older systems don't deal with them well. If it's just for Mac OS X, it isn't a big deal. I think it was the Irix compiler that was problematic? -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Tue Mar 21 11:22:05 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 21 Mar 2006 11:22:05 -0700 (MST) Subject: [Rxtx] lock files In-Reply-To: <8E12916A-1B9A-4FF2-B684-E2D1C794221B@buechse.de> References: <8E12916A-1B9A-4FF2-B684-E2D1C794221B@buechse.de> Message-ID: We can try it. Maybe the JNI is much improved. The nice thing about linking into liblock is distros then worry about lockfiles on their systems. This way, we have to deal with any changes that may show up. On Tue, 21 Mar 2006, Joachim Buechse wrote: > This is pretty much what I thought about when I suggested, that the > default behaviour could be overwritten with a property. I am very much in > favor of this approach. In particular this allows much easier debugging > for PC based java developers. > > I think big parts of the Java (and maybe some parts of the C code) could > use a bit of a structural workover (unit tests, javadoc, synchronization, > etc). Maybe there should be a CVS branch for this experimental version. > I'd be happy to contribute a first workover for some of the Java code. > Designing for testability and implementing a good bunch of unit tests has > been a strategy that worked quite well in the Java projects I lead. And > it ultimately allows more liberal change permission. > > Regards, > Joachim > > > On 21.03.2006, at 08:51, Dr. Douglas Lyon wrote: > >> Hi All, >> You know, if the use of lock files were >> under Java control (rather than a build-time decision), >> it might enable a more unified binary distro. It might also >> facilitate quick prototyping of non-lock file approaches >> to resolving serial port contention issues (i.e., mac-like >> approaches vs. linux approaches, etc.). >> >> I realize that this is a radical overhaul of the lock file policy >> issue. Also, it may harm performance. On the other hand, >> our benchmarks on JNI overhead for modern processors indicate >> performance impact should be minimal. Perhaps it is more of >> an issue with the toybox systems. >> >> Suppose there were a class with a reasonable default...someone >> might write: >> SerialPortLockPolicy.setPolicy(SerialPortLockPolicy.UNIX_LOCK_FILE); >> SerialPortLockPolicy.setPolicy(SerialPortLockPolicy.NO_LOCK_CHECKING); >> SerialPortLockPolicy.setPolicy(SerialPortLockPolicy.MAC_STYLE); >> >> Thus, we could have a run-time reconfiguration of the serial port lock >> policy. A special NO_LOCK version of the binary would no longer >> be required. >> >> Any thoughts on this? >> >> Thanks! >> - Doug >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From dmarkman at mac.com Tue Mar 21 16:05:17 2006 From: dmarkman at mac.com (Dmitry Markman) Date: Tue, 21 Mar 2006 18:05:17 -0500 Subject: [Rxtx] PATCH: use of ioctl(fd, TIOCEXCL) instead of lockfiles In-Reply-To: References: <923AE774-EEA2-4911-92D8-32BB27802C8B@buechse.de> Message-ID: <512AC70C-BB86-48F2-A83C-023F35C23BAB@mac.com> I think it's cool, but I'd like to have that property implementation when user can choose between locking mechanism about comments: it's easy to change comments to the C style or we can use extensions of the file to cpp so c++ compiler will be used On Mar 21, 2006, at 1:05 PM, Trent Jarvi wrote: > This looks like a good start. What do you think Dmitry? Perhaps > all systems with TIOCEXCL defined should use that though. Even if > they use lockfiles. It wont hurt anything. That would catch > people hacking their own serial apps without checking lockfiles. > > Its a good idea to avoid C++ style comments in the C portions. > Some older systems don't deal with them well. If it's just for Mac > OS X, it isn't a big deal. I think it was the Irix compiler that > was problematic? Dmitry Markman From dmarkman at mac.com Tue Mar 21 16:13:00 2006 From: dmarkman at mac.com (Dmitry Markman) Date: Tue, 21 Mar 2006 18:13:00 -0500 Subject: [Rxtx] PATCH: use of ioctl(fd, TIOCEXCL) instead of lockfiles In-Reply-To: References: <923AE774-EEA2-4911-92D8-32BB27802C8B@buechse.de> Message-ID: I'd like to add that creating locking folder isn't a big deal we never had a problem related to the lock folders, because we always used installer on mac os x from other hand I'm not very much familiar with iotcl locking approach and I'm not sure it's more efficient Joachim wrote "I think it is the way to go, as it eliminates creating the lock directory which doesnt exist on the standard installation and it eliminates messing with the system group definitions (adding users to group uucp)." but I really didn't have any problem with that 1. doesn't exist on the standard installation there are many-many things that don't exist in the standard installation so I don't think that argument is strong enough 2. messing with the system group definitions I don't think we're messing with the group definition mac os x provides very clear way to set up group's members and together with Greg Guerin AuthKit there is no problem to set those definitions so I don't think that argument is strong either but from other hand using iotcl is more promising and is more elegant On Mar 21, 2006, at 1:05 PM, Trent Jarvi wrote: > > This looks like a good start. What do you think Dmitry? Perhaps > all systems with TIOCEXCL defined should use that though. Even if > they use lockfiles. It wont hurt anything. That would catch > people hacking their own serial apps without checking lockfiles. Dmitry Markman From joachim at buechse.de Wed Mar 22 04:46:45 2006 From: joachim at buechse.de (Joachim Buechse) Date: Wed, 22 Mar 2006 12:46:45 +0100 Subject: [Rxtx] PATCH: use of ioctl(fd, TIOCEXCL) instead of lockfiles In-Reply-To: References: <923AE774-EEA2-4911-92D8-32BB27802C8B@buechse.de> Message-ID: Sorry, I was not very clear with my arguments, so I will try again;-) Please, don't take this as an attack against work that has been done. I think the contributions that have been made in the past were made in a good spirit. But I really believe, that the current solution for OSX has many shortcomings and should be changed as soon as possible. lock files --- The /var/lock folder does not exist on the standard OSX installation, however the standard installation includes several applications that use serial ports (i.e. the FAX capability). This indicates, that the lock folder approach will not work well with system components. Applications for OSX will generally try to live in harmony with system components (except for HP print drivers of course). I think RXTX should follow this approach as well. uucp group --- Accessing serial ports is not an admin privileged operation on OSX. Any user (world) has read/write privileges on /dev/tty*. So the system default is to not enforce any group membership to access these ports. The group uucp however is a system group on all unix systems I know. It exists for certain system processes. A non admin user should in general not be a member of this group. Quite arguably no user should ever be a member of this group. Installer --- My general opinion is, that - no Installer should touch user or group data without warning - no Application Installer should touch groups which are not specific to the very application installed - no Installer should ever add regular users to a system group The current installer injects the installing user in the group uucp without warning about this change and without giving the option to "opt out" of this change. This is a potential security risk (but not currently a real one, as OSX contains no folders belonging to group uucp). The current installer does not work for multi user systems. It puts the installing user in the uucp group. However the installing user is not necessarily the user that will use the application. Putting all users that may use a serial port application in the system group uucp seems like a very invasive approach to me. Besides that, newly created users will not automatically be in the group and hence, serial applications will "break" for new users without obvious reasons. Avoiding the lock files will allow self contained applications (i.e. drag&drop installation). In my eyes this is largely preferable over an installer that requests admin privileges. Adding up all these points indicates very strongly, that the lock-file implementation is not the way to go on OSX. Regards, Joachim On 22.03.2006, at 00:13, Dmitry Markman wrote: > I'd like to add that > > creating locking folder isn't a big deal > we never had a problem related to the lock folders, because we > always used installer on mac os x > from other hand I'm not very much familiar with iotcl locking > approach and I'm not sure it's more efficient > > Joachim wrote "I think it is the way to go, as it eliminates > creating the lock directory which doesnt exist on the standard > installation and it eliminates messing with the system group > definitions (adding users to group uucp)." but I really didn't have > any problem with that > > 1. doesn't exist on the standard installation > there are many-many things that don't exist in the standard > installation so I don't think that argument is strong enough > 2. messing with the system group definitions > I don't think we're messing with the group definition > mac os x provides very clear way to set up group's members and > together with Greg Guerin AuthKit there is no problem to set those > definitions > so I don't think that argument is strong either > but from other hand using iotcl is more promising and is more elegant > > > > On Mar 21, 2006, at 1:05 PM, Trent Jarvi wrote: > >> >> This looks like a good start. What do you think Dmitry? Perhaps >> all systems with TIOCEXCL defined should use that though. Even if >> they use lockfiles. It wont hurt anything. That would catch >> people hacking their own serial apps without checking lockfiles. > > Dmitry Markman > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From dmarkman at mac.com Wed Mar 22 05:27:13 2006 From: dmarkman at mac.com (Dmitry Markman) Date: Wed, 22 Mar 2006 07:27:13 -0500 Subject: [Rxtx] PATCH: use of ioctl(fd, TIOCEXCL) instead of lockfiles In-Reply-To: References: <923AE774-EEA2-4911-92D8-32BB27802C8B@buechse.de> Message-ID: <83440CF3-DCD8-41C1-B941-F227232C27E3@mac.com> thanks for the very good explanation I didn't think that you were attacking any thing, so don't worry I just had feeling, that there were more aesthetic reasons for going to ioctl then real necessity now you explained everything quite well (BTW, asfar as I remember installer asks admin password so it wasn't quiet, but it really doesn't matter now) thanks On Mar 22, 2006, at 6:46 AM, Joachim Buechse wrote: > Sorry, I was not very clear with my arguments, so I will try again;-) > > Please, don't take this as an attack against work that has been > done. I think the contributions that have been made in the past > were made in a good spirit. But I really believe, that the current > solution for OSX has many shortcomings and should be changed as > soon as possible. > > lock files > --- > The /var/lock folder does not exist on the standard OSX > installation, however the standard installation includes several > applications that use serial ports (i.e. the FAX capability). This > indicates, that the lock folder approach will not work well with > system components. Applications for OSX will generally try to live > in harmony with system components (except for HP print drivers of > course). I think RXTX should follow this approach as well. > > uucp group > --- > Accessing serial ports is not an admin privileged operation on OSX. > Any user (world) has read/write privileges on /dev/tty*. So the > system default is to not enforce any group membership to access > these ports. The group uucp however is a system group on all unix > systems I know. It exists for certain system processes. A non admin > user should in general not be a member of this group. Quite > arguably no user should ever be a member of this group. > > Installer > --- > My general opinion is, that > - no Installer should touch user or group data without warning > - no Application Installer should touch groups which are not > specific to the very application installed > - no Installer should ever add regular users to a system group > > The current installer injects the installing user in the group uucp > without warning about this change and without giving the option to > "opt out" of this change. This is a potential security risk (but > not currently a real one, as OSX contains no folders belonging to > group uucp). > > The current installer does not work for multi user systems. It puts > the installing user in the uucp group. However the installing user > is not necessarily the user that will use the application. Putting > all users that may use a serial port application in the system > group uucp seems like a very invasive approach to me. Besides that, > newly created users will not automatically be in the group and > hence, serial applications will "break" for new users without > obvious reasons. > > > Avoiding the lock files will allow self contained applications > (i.e. drag&drop installation). In my eyes this is largely > preferable over an installer that requests admin privileges. Adding > up all these points indicates very strongly, that the lock-file > implementation is not the way to go on OSX. > > Regards, > Joachim > > > On 22.03.2006, at 00:13, Dmitry Markman wrote: > >> I'd like to add that >> >> creating locking folder isn't a big deal >> we never had a problem related to the lock folders, because we >> always used installer on mac os x >> from other hand I'm not very much familiar with iotcl locking >> approach and I'm not sure it's more efficient >> >> Joachim wrote "I think it is the way to go, as it eliminates >> creating the lock directory which doesnt exist on the standard >> installation and it eliminates messing with the system group >> definitions (adding users to group uucp)." but I really didn't >> have any problem with that >> >> 1. doesn't exist on the standard installation >> there are many-many things that don't exist in the standard >> installation so I don't think that argument is strong enough >> 2. messing with the system group definitions >> I don't think we're messing with the group definition >> mac os x provides very clear way to set up group's members and >> together with Greg Guerin AuthKit there is no problem to set those >> definitions >> so I don't think that argument is strong either >> but from other hand using iotcl is more promising and is more elegant >> >> >> >> On Mar 21, 2006, at 1:05 PM, Trent Jarvi wrote: >> >>> >>> This looks like a good start. What do you think Dmitry? Perhaps >>> all systems with TIOCEXCL defined should use that though. Even >>> if they use lockfiles. It wont hurt anything. That would catch >>> people hacking their own serial apps without checking lockfiles. >> >> Dmitry Markman >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx Dmitry Markman From lyon at docjava.com Wed Mar 22 06:12:18 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Wed, 22 Mar 2006 08:12:18 -0500 Subject: [Rxtx] sole of a new design pattern Message-ID: Hi All, I have been thinking about how we design the serial port software. I think we need a new design pattern. For lack of a better term, I shall call it: The Parametric Singleton Design Pattern By Douglas A. Lyon ABSTRACT The goal of the singleton design pattern is to make sure that there is one, and only one, instance of a given class. The goal of the parametric singleton design pattern is to make sure that there is one, and only one, instance of a given class with the given parametric values. We parametric singleton design pattern combines the singleton design pattern with a parameter that enables unique creation of instances of a class. These instances are cached. When a user asks for an instance with these parameters, the cache is checked. If the instance is in the cache, the instance is returned, otherwise it is created, added to the cache and then returned. We apply our parametric singleton design pattern to the retrieval of RMI registries bound to a given port. The goal of our system is to make sure that no two RMI registries are listening to the same socket and to make use of the RMI registries after they have been created. RMI registries are used in distributed computation. Introduction The singleton design pattern is meant to ensure that on a single instance of a class exists. It is also meant to provide a global point of access to it. The intent of the parametric singleton design pattern is to ensure that a class has only one instance for a given set of parameter values. It also provides a global point of access to it. Motivation A system cannot tolerate multiple instances of some classes with identical parameters. For example, you cannot have two instances making use of the same serial port, at the same time. You cannot have two instances that are trying to listen to the same socket connection. You cannot have two instances writing to the same file structure at the same time. As the operating system is often thought of as the arbiter of consumed resources (i.e., tape drives, serial ports, etc.) we frequently leave it to an operating system implementation to resolve these contention issues. Even for similar resources (like serial ports) there are few standards for handling contention. For example, serial ports on Linux are locked using a "/var/lock" file. POSIX, on the other hand, uses ioctl mechanisms to prevent contention. A better solution is to make a class that is responsible for keeping track of the instances created from the class. The class is declared final, so that it cannot be subclassed. The class also has a private constructor, so that other classes cannot instance it. The new design pattern is called the parametric singleton design pattern and it provides a way to access and create instances with given parameters. Applicability Use the Parametric Singleton Design Pattern when: 1. There must be exactly one instance of a class with the given parameters. 2. The instances must be accessible to clients from a well-known access point. Structure Insert UML diagram here. Participants The Parametric Singleton Clients that need instances 1. The Parametric Singleton defines an instance upon request from a client, if, and only if, the instance does not already exist. 2. The Parametric Singleton returns the instance to the client. 3. The Parametric Singleton is responsible for creating unique instances from given parameters. Collaborations Clients obtain a reference to a Parametric Singleton instance only through the parametric singleton design pattern. If the instance is left in an improper state (e.g., the serial port was left open) it is NOT the role of the Parametric Singleton Design Pattern to close the IO port. Nor is it the role of the Parametric Singleton Design Pattern to open the port. That role is delegate to some other part of the system. Further, it is not the role of the Parametric Singleton Design Pattern to check out resources. That is, multiple threads can have multiple references to the same resource at the same time. MUTEX locking is delegated to some other part of the system. Consequences The Parametric Singleton Design Pattern has several benefits: 1. Controlled access to parametrically defined instances. Since the Parametric Singleton class encapsulates its instances, there is control over how and when clients access it. 2. Reduced name space. The Parametric Singleton pattern avoids global variables that store instances created from the same parameter. Implementation Here are implementation issues to consider when using the Parametric Singleton pattern: 1. Unique mapping of parameters. The Parametric Singleton pattern requires that there be a mean to isomorphically map the parameter space into the instance space and back again. 2. Ensure unique instances. The Parametric Singleton pattern makes unique instances from parameters, and it does so only once. 3. Cache instances for fast retrieval. The Parametric Singleton pattern must be able to look up instances, given some set of parameters, and do so from some data structure. That is, there must be enough space to hold references to all the instances the program will need. Also, a mechanism is needed to look up and retrieve the instances quickly enough to satisfy the clients. Sample Code public final class ParametricSingletonRmiRegistry { private static Hashtable registry = new Hashtable(100); // use singleton pattern and??????????????????????????????????????????????? // prevent instantiation of RmiRegistryUtils.?????????????????????????????? private ParametricSingletonRmiRegistry() { } // the only instance of the Registry held by the RmiRegistryUtils?????????? public static void listNames(Integer port) { if (!isInCacheAndRunning(port)) return; Registry r = (Registry) registry.get(port); System.out.println("registry on port: " + port); System.out.println("registry: " + r); System.out.println("names: "); try { print(r.list()); } catch (RemoteException e) { In.message(e); } System.out.println("------------------------"); } /**???????????????????????????????????????????????????????????????????????? * Checks whether a Registry has been started on this host????????????????? * in the specified port.?????????????????????????????????????????????????? * If not, it tries to start one.?????????????????????????????????????????? * when it fails to start a Registry, it exits the program????????????????? * with exit code 1.??????????????????????????????????????????????????????? */ public static void restart(int port) { if (isInCacheAndRunning(port)) return; try { startRegistry(port); } catch (RemoteException e) { In.message(e); } } /**???????????????????????????????????????????????????????????????????????? * @param port????????????????????????????????????????????????????????????? * @return true if registry is in cache and running???????????????????????? */ private static boolean isInCacheAndRunning(Integer port) { if (!isRegistryRunning(port.intValue())) return false; if (!isRegistryInCache(port.intValue())) return false; return true; } /**???????????????????????????????????????????????????????????????????????? * @param port????????????????????????????????????????????????????????????? * @return true if we are able to locate a local registry on port.??????????????????????????????????????????????????????????????????????????? */ private static boolean isRegistryRunning(int port) { try { Registry r = LocateRegistry.getRegistry(port); if (r != null) return true; } catch (RemoteException e) { return false; } return false; } /**???????????????????????????????????????????????????????????????????????? * @param port????????????????????????????????????????????????????????????? * @return return true if registry is in cache????????????????????????????? */ private static boolean isRegistryInCache(int port) { if (registry.get(new Integer(port)) == null) return false; return true; } /**???????????????????????????????????????????????????????????????????????? * Restart the registry, if needed.???????????????????????????????????????? * Return the only instance of the registry for consistent global?????????? * using by making use of the Singleton Design Pattern????????????????????? *????????????????????????????????????????????????????????????????????????? * @return the internally held registry instance.?????????????????????????? */ public static Registry getRegistry(Integer port) { restart(port); return (Registry) registry.get(port); } private static void startRegistry(Integer port) throws RemoteException { Registry r; try { r = LocateRegistry.createRegistry(port.intValue()); registry.put(port, r); //r = new sun.rmi.registry.RegistryImpl???????????????????????????? /// (port.intValue());?????????????????????????????????????? // registry.put(port, r);?????????????????????????????????????????? } catch (Exception e) { //e.printStackTrace();????????????????????????????????????????????? r = LocateRegistry.getRegistry(port.intValue()); registry.put(port, r); } } public static void main(String args[]) throws RemoteException { //restart(port);??????????????????????????????????????????????????????? restart(5001); restart(5002); restart(5002); Registry r = LocateRegistry.getRegistry(5002); System.out.println("registry="+r); } } I would very much like to get your feedback on this new design pattern idea. Thank you for your time. Regards, - Doug From david.garnier at trusted-logic.com Wed Mar 22 07:36:10 2006 From: david.garnier at trusted-logic.com (David Garnier) Date: Wed, 22 Mar 2006 15:36:10 +0100 Subject: [Rxtx] sole of a new design pattern In-Reply-To: References: Message-ID: <442160DA.80107@trusted-logic.com> Hello, > The Parametric Singleton Design Pattern The Singleton is the most abused design pattern ever. Good use-cases for this pattern are extremely rare and mostly confined to problems related to hardware resources, like serial ports. > Applicability > > Use the Parametric Singleton Design Pattern when: > 1. There must be exactly one instance of a class with the given > parameters. OK. As I said above, this case this actually very unusual. The Singleton pattern is mostly used when : > 2. The instances must be accessible to clients from a well-known > access point. Using the singleton pattern in this case is just convenient for the programmer. Problems arises pretty quickly, especially if you attempt to unit-test your classes. 1) If your singleton is stateful, or hold on to stateful objects, it means that two different unit tests are not actually independent. Instead of starting with a brand new environment, the result of a test may be affected by the result of a previous test. This problem also arise when with your class relies on a database. In both cases, the solution is to reset your "unique" resource (Singleton or database) at the beginning of the test, which is a pain. Also, while most projects connect to a single database, projects that allow the use of Singletons usually contain several of thems, and new ones may cropped up unnoticed. You quickly end up with test cases that only pass in a certain order, which is a royal pain. 2) You cannot mockup a singleton. Once everyone calls the SomeSingleton class statically, you can't replace your class by SomeSingletonMockup. Furthermore, even for hardware services, the Singleton pattern does not really prevent concurrent accesses. If you start the same program in two different JVMs, unless they somehow shared the state of their "Singletons" (through lock files for example), the Singleton pattern will not prevent concurrent access. Our application uses RXTX, and we routinely encounter cases where another (native) application has already locked the port. Since we cannot modify the native application to recognize lock files, OS-level control is irreplaceable. > > Consequences > The Parametric Singleton Design Pattern has several benefits: > > 1. Controlled access to parametrically defined instances. Since > the Parametric Singleton class encapsulates its instances, there is > control over how and when clients access it. Not really. Once you've returned the instance to a client, you've lost control over it. The client can to whatever it wants with it. You cannot "recall" the instance or claim it back. > 2. Reduced name space. The Parametric Singleton pattern avoids > global variables that store instances created from the same parameter. Sure, but you don't have to rely on a Singleton for that. Just create a single Factory. > I would very much like to get your feedback on this new design > pattern idea. Well, it's nothing new. Some may say that it is the point of design patterns: formalizes the designs that occur again and again. However, this design is simply a combination of the Singleton and Factory patterns. I did use it in the past, but now I've been exposed to the shortcomings of the Singleton pattern, so I limit myself to Factories. Regards, David From sean_montgomery at baseview.com Wed Mar 22 08:35:28 2006 From: sean_montgomery at baseview.com (Sean Montgomery) Date: Wed, 22 Mar 2006 10:35:28 -0500 Subject: [Rxtx] sole of a new design pattern In-Reply-To: <442160DA.80107@trusted-logic.com> References: <442160DA.80107@trusted-logic.com> Message-ID: <05769CA7-A51B-4CF0-BAA0-E02DD905F5A4@baseview.com> On Mar 22, 2006, at 9:36 AM, David Garnier wrote: > Furthermore, even for hardware services, the Singleton pattern does > not really prevent concurrent > accesses. If you start the same program in two different JVMs, > unless they somehow shared the state > of their "Singletons" (through lock files for example), the > Singleton pattern will not prevent > concurrent access. > Multiple class loaders in a single JVM can be tricky, too. Then there's synchronization, lazy initialization and serialization of singletons to contend with. Bloch's Effective Java covers these, and here's a few articles: http://www.javaworld.com/javaworld/jw-04-2003/jw-0425-designpatterns- p3.html http://java.sun.com/developer/technicalArticles/Programming/singletons/ Just FYI :-) From lyon at docjava.com Wed Mar 22 08:50:48 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Wed, 22 Mar 2006 10:50:48 -0500 Subject: [Rxtx] sole of a new design pattern In-Reply-To: <442160DA.80107@trusted-logic.com> References: <442160DA.80107@trusted-logic.com> Message-ID: Hi All, First, I would like to thank David for his prompt and thoughtful remarks. I had no idea people that feel strongly about a design patterns! Wow! Feedback (particularly critical feedback) is greatly appreciated. Starting at the end, first: >I did use it in >the past, but now I've been exposed to the shortcomings of the >Singleton pattern, so I limit myself to Factories. David, if I understood your comments correctly, you suggested that Factories can be used in leu of the Singleton Design Pattern, or even the Parametric Singleton Design Pattern. As I see in [Gof]: Factory Method: Intent "Define an interface for creating an object, but let subclasses decide which class to instantiate. Factory Method lets a class defer instantiation to subclasses." The Singleton Design Pattern is a concrete class, which is rather different, right? Also, subclasses are not permitted with Singleton, as they are final. Naturally, I could use an abstract factory as a parent for a singleton. I could even design a facade that could be implemented with the singleton....but that is not the intention of the design. Unless you want a mock-up, as discussed, below: More below: >Hello, > >> The Parametric Singleton Design Pattern > >The Singleton is the most abused design pattern ever. Good use-cases >for this pattern are extremely >rare and mostly confined to problems related to hardware resources, >like serial ports. > > >> Applicability >> >> Use the Parametric Singleton Design Pattern when: >> 1. There must be exactly one instance of a class with the given >> parameters. >OK. As I said above, this case this actually very unusual. The >Singleton pattern is mostly used when : >> 2. The instances must be accessible to clients from a well-known >> access point. > >Using the singleton pattern in this case is just convenient for the >programmer. Problems arises >pretty quickly, especially if you attempt to unit-test your classes. > >1) If your singleton is stateful, or hold on to stateful objects, it >means that two different unit >tests are not actually independent. Instead of starting with a brand >new environment, the result of >a test may be affected by the result of a previous test. This >problem also arise when with your >class relies on a database. In both cases, the solution is to reset >your "unique" resource >(Singleton or database) at the beginning of the test, which is a >pain. Also, while most projects >connect to a single database, projects that allow the use of >Singletons usually contain several of >thems, and new ones may cropped up unnoticed. You quickly end up >with test cases that only pass in a >certain order, which is a royal pain. There are basic problems with communicating finite state machines that include reachability and deadlock analysis. These are addressed with petri net analysis and are beyond the scope of the design pattern. As you quite rightly pointed out; the parametric singleton pattern (or the singleton pattern, for that matter) enable multiple threads to gain access to the same instance. The only way that I can see to block others from gaining access to the reference is the synchronize keyword. This is putting a spin-lock (or MUTEX) on the reference. The question of how to unit-test a design pattern like the parametric singleton remains open. Perhaps this is a deficiency. > >2) You cannot mockup a singleton. Once everyone calls the >SomeSingleton class statically, you can't >replace your class by SomeSingletonMockup. Acutally, I am not sure that this is true. If the Singleton implements a Facade interface, it should be possible to make the replacement. Right? > >Furthermore, even for hardware services, the Singleton pattern does >not really prevent concurrent >accesses. If you start the same program in two different JVMs, >unless they somehow shared the state >of their "Singletons" (through lock files for example), the >Singleton pattern will not prevent >concurrent access. Good Point!! You have sharp eyes! The singleton design pattern should/could take responsibility for this. In fact, you may notice that my code does have an implementation (LocateRegistry) that can work across JVM's. The LocateRegistry will even work across the Internet! LocateRegistry takes both a host name and a Port (lock files just don't do this). I did not think to implement this beyond the local machine, but, in its present form, it will work across different processes. > >Our application uses RXTX, and we routinely encounter cases where >another (native) application has >already locked the port. Since we cannot modify the native >application to recognize lock files, >OS-level control is irreplaceable. The singleton design pattern is not meant to replace OS-level control, but to centralize the Java programmers access to it. If lock files, for example, are used for serial ports, the Singleton Design Pattern should be able to work with them. > > >> >> Consequences >> The Parametric Singleton Design Pattern has several benefits: >> > > 1. Controlled access to parametrically defined instances. Since >> the Parametric Singleton class encapsulates its instances, there is >> control over how and when clients access it. > >Not really. Once you've returned the instance to a client, you've >lost control over it. The client >can to whatever it wants with it. You cannot "recall" the instance >or claim it back. Good point, this should read: > 1. Controll when parametrically defined instances are created. Since > > the Parametric Singleton class encapsulates its instances, there is > > control over how and when they are instanced. > >> 2. Reduced name space. The Parametric Singleton pattern avoids >> global variables that store instances created from the same parameter. > >Sure, but you don't have to rely on a Singleton for that. Just >create a single Factory. > > Thank you for your thoughtful and prompt response! Regards, - Doug From dmarkman at mac.com Wed Mar 22 21:21:55 2006 From: dmarkman at mac.com (Dmitry Markman) Date: Wed, 22 Mar 2006 23:21:55 -0500 Subject: [Rxtx] sole of a new design pattern In-Reply-To: <442160DA.80107@trusted-logic.com> References: <442160DA.80107@trusted-logic.com> Message-ID: I don't think I get it On Mar 22, 2006, at 9:36 AM, David Garnier wrote: > Using the singleton pattern in this case is just convenient for the > programmer. Problems arises > pretty quickly, especially if you attempt to unit-test your classes. so you're saying that something isn't so good because you can not test it in the convenient way? if that's true, I'm totally disagree change your test, debug whatever, but if software is efficient at runtime, works fine and only problem is some unit test (which is some kind of framework for testing) then dump that unit test , dump that unit framework and make something appropriate to the software you're testing so if Douglas want to use singletons, what's the problem? and what do you mean by abusing of singleton usage? of course singleton doesn't prevent concurrent access to the resource across the processes unless you're using some OS facility to prevent it, besides singleton as it was introduced is relevant only and only inside of the same process otherwise it's not singleton it's something else (let's say network singleton: so you have remote invocation facility and some factory method that return object created by that facility) I don't have any problem with using any kind of singletons. Parametric Singleton idea (if I understand it right) could be easily implemented in the following way: use a map populate map with instances of some class and key is your parameter (you can use lazy population too) if somebody ask the key check the value if it's null so resource is taken if somebody returns the resource put it back to the map public synchronized static Object getSomeResource(Object parameter); public synchronized static void returnResource(Object parameter); getSomeResource (inside of the same process) could return null in 2 cases 1. if somebody (from other thread for example) already took that resource 2. if OS API said that resource corresponded to that parameter (serial port with parameter = 1 (port #)) is locked and unavailable; I'm not sure that in case of serial ports we even need those Parametric Singletons (unless lock checking is a very expensive operation) just ask the OS about availability of that resource and if it's available give it away and then OS will lock it and therefore in next time somebody ask it just answer that resource is locked and return null for example system has 2 serial ports available so I ask getResource("tty"); or I ask getResource("Bluetooth-Modem"); and if OS is ok you can give tty or Bluetooth-Modem or both no need for any additional pattern I think back to the problem mac os x doesn't recognize locking via files, so it handles locking via some API an instance of the singleton in each process should recognize that resource is locked (by using that API) that's all we don't have to make things more complicate then they are just because there is some nice design pattern or nice unit test framework or whatever keep things simple, make them work fast, don't introduce middle layers unless you have really good reason to do so of course I could be entirely wrong, so sorry about that in advance thanks Dmitry Markman From tjarvi at qbang.org Wed Mar 22 22:31:41 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 22 Mar 2006 22:31:41 -0700 (MST) Subject: [Rxtx] sole of a new design pattern In-Reply-To: References: Message-ID: Hi Doug Interesting reading. So far I'm just reading and thinking. I have one question so far. " Clients obtain a reference to a Parametric Singleton instance only through the parametric singleton design pattern. If the instance is left in an improper state (e.g., the serial port was left open) it is NOT the role of the Parametric Singleton Design Pattern to close the IO port. Nor is it the role of the Parametric Singleton Design Pattern to open the port. That role is delegate to some other part of the system. " So when the clients obtain a reference to the singleton, can they assume the port is there? IE, would it be the singletons role to handle things like USB dongles being removed with event hints comming from the underlying OS. Hardware abstraction layer/HAL on Linux is an example of underlying OS events. I assume that role too is delegated to other parts of the system? -- Trent Jarvi tjarvi at qbang.org From lyon at docjava.com Thu Mar 23 08:10:33 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Thu, 23 Mar 2006 10:10:33 -0500 Subject: [Rxtx] Classes don't need goals, they need roles! In-Reply-To: References: Message-ID: Hi Trent, Yes, I think that the role of the Parametric Singleton Pattern is not to open or close serial ports, nor is it to perform error checking. On the other hand, if you were to combine the role of the Parametric Singleton Pattern with another role (like that of error checking) it might not be amiss. However, I generally caution programmers against adding multiple roles to classes, as this leads to monolithic designs. Thus a different class (NativeLibDetect) could have the role of determining if the native library can be loaded. Another class (SerialPortBean) can have the role of serializing the default state of the serial port, so that it can be recovered, from user preferences, at a later time. The SerialPortDetect could have the role of determining if the serial port is removed (i.e., a USB port was unplugged). My guess is that each class should have a different role in the system, in order to ease maintenance and testing...but I could be wrong about that. Thanks! - Doug >Hi Doug > >Interesting reading. So far I'm just reading and thinking. I have >one question so far. > >" > Clients obtain a reference to a Parametric Singleton instance only >through the parametric singleton design pattern. If the instance is >left in an improper state (e.g., the serial port was left open) it is >NOT the role of the Parametric Singleton Design Pattern to close the >IO port. Nor is it the role of the Parametric Singleton Design Pattern >to >open the port. That role is delegate to some other part of the system. >" > >So when the clients obtain a reference to the singleton, can they >assume the port is there? IE, would it be the singletons role to >handle things like USB dongles being removed with event hints >comming from the underlying OS. Hardware abstraction layer/HAL on >Linux is an example of underlying OS events. > >I assume that role too is delegated to other parts of the system? > >-- >Trent Jarvi >tjarvi at qbang.org >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From maximulo at yahoo.com Fri Mar 24 01:22:38 2006 From: maximulo at yahoo.com (Maximulo Majir) Date: Fri, 24 Mar 2006 00:22:38 -0800 (PST) Subject: [Rxtx] JavaPOS Message-ID: <20060324082238.66371.qmail@web38214.mail.mud.yahoo.com> Hi all! Hello Trent! From what i understand, RXTX or JavaComm APIs were not created solely for JavaPOS. In JavaPOS, we have the virtual method claim() which is separate from open(), but in our RXTX API, claiming is done every call to open(), we cant open the port if its claimed by another application. Would it be alright to suggest or ask to create a new method called claim(..)? Is there such thing as forceclaim() in RXTX? this could be the same as portownership transfer or its equivalent. ForceClaim is in JSR80. Do you have some samples using RXTX as the lower layer for the Device Service Objects in JavaPOS? I have tried it, i just want to compare. Thank you all! maxim __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060324/496adba2/attachment-0036.html From tjarvi at qbang.org Fri Mar 24 11:28:19 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 24 Mar 2006 11:28:19 -0700 (MST) Subject: [Rxtx] Re: RXTX 2.1 Solaris Problems In-Reply-To: <3691.1143210578@www045.gmx.net> References: <3691.1143210578@www045.gmx.net> Message-ID: On Fri, 24 Mar 2006, Andreas Guenther wrote: > Hi all, > > the solaris problem was not the lock file only. > > Ok, I had to create the directory /var/spool/locks myself. > /var/spool/uucp exists. > > But rxtx didn't find any port. > > I compiled the source with my own debug-informations > and I tried to isolate the problem. > > The problem is the testRead-call in SerialImp.c > > JNIEXPORT jboolean JNICALL RXTXCommDriver(testRead)( > > ... > if ( READ( fd, &c, 1 ) < 0 ) > { > if ( errno != EAGAIN ) { > report( "testRead() read failed\n" ); > ret = JNI_FALSE; > } > } > Thanks Andreas I'm packing up to move. I'll be more or less away for a couple weeks here. I'll be checking email but my workstation is going into a box soon. This isn't hard to fix as this port should be enumerated when EWOULDBLOCK is recieved. Thats error is OK for enumeration just as EAGAIN is. I've put the bug into bugzilla so we dont forget to get to it. http://bugzilla.qbang.org/show_bug.cgi?id=42 You can add yourself to the CC list if you wish to test fixes we provide or even put a patch into bugzilla yourself. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Fri Mar 24 11:51:52 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 24 Mar 2006 11:51:52 -0700 (MST) Subject: [Rxtx] JavaPOS In-Reply-To: <20060324082238.66371.qmail@web38214.mail.mud.yahoo.com> References: <20060324082238.66371.qmail@web38214.mail.mud.yahoo.com> Message-ID: On Fri, 24 Mar 2006, Maximulo Majir wrote: > Hi all! Hello Trent! > > > From what i understand, RXTX or JavaComm APIs were not > created solely for JavaPOS. In JavaPOS, we have the virtual method > claim() which is separate from open(), but in our RXTX API, claiming is > done every call to open(), we cant open the port if its claimed by > another application. Would it be alright to suggest or ask to create a > new method called claim(..)? Is there such thing as forceclaim() in > RXTX? this could be the same as portownership transfer or its > equivalent. ForceClaim is in JSR80. > Do you have some samples using RXTX as the lower layer for the Device > Service Objects in JavaPOS? I have tried it, i just want to compare. > maxim Hi Maxim JSR80 is the USB API IBM/Sun put together. The problem is they have a richer kernel/API underneath that can handle such things. With Serial Ports, there isnt anything there other than an ioctl that says don't let anyone touch this and lockfiles that are more of a 'lets be nice.' At times we may be using USB ports but it is through the termios layer with the limitations mentioned. The advantage is that not only USB will work with rxtx. Anything that has a termios layer should work (to the extent that termios layer is complete). I don't know how forceclaim() would help you. Lets say someone has a programmer working on /dev/ttyS0 and you take it. Now you both race each other to read data first. There isn't a mechanism I know of that will solve this problem in termios. The most obvious test being a native app and a Java app trying to take the port. There is the potential of requestion ownership from other Java Applications but the use for that is very rare. Did you have something more specific in mind that I'm missing? I'm not sure that claim() and forceclaim() would help you with rxtx other than maybe locking the port with claim() without opening it. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sat Mar 25 23:42:08 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 25 Mar 2006 23:42:08 -0700 (MST) Subject: [Rxtx] Serial snoop Message-ID: I was reading the Linux kernel mail-list tonight and ran past a thread that mentioned sersnoop. This looks like a handy tool for people dealing with new toys. "a simple command-line tool for linux that echoes bytes to and from any two serial ports, ptys, or network sockets, and prints all traffic to stdout, in hex and ascii." http://www.restivo.org/projects/sersnoop/ It works on Linux only at this time (debian package available). -- Trent Jarvi tjarvi at qbang.org From beat.arnet at gmail.com Sun Mar 26 07:32:35 2006 From: beat.arnet at gmail.com (Beat Arnet) Date: Sun, 26 Mar 2006 09:32:35 -0500 Subject: [Rxtx] Error 0x5 at /home/bob/foo/tar/rxtx-2.1-7/build/../src/termios.c(860): Access is, denied. Message-ID: <4426A603.80508@gmail.com> Dear all, When trying to open the serial port, I sometimes (not always) run into the following exception (when opening the serialPort): Error 0x5 at /home/bob/foo/tar/rxtx-2.1-7/build/../src/termios.c(860): Access is denied. java.lang.UnsatisfiedLinkError: native_psmisc_report_owner at gnu.io.CommPortIdentifier.native_psmisc_report_owner(Native Method) at gnu.io.CommPortIdentifier.open(CommPortIdentifier.java:354) at codeskin.tools.CLLoader.open(CLLoader.java:79) at codeskin.tools.C2000Programmer.run(C2000Programmer.java:220) at java.lang.Thread.run(Unknown Source) Is this the type of error where I should just try to open the port again, or can it be avoided? Regards, Beat From tjarvi at qbang.org Sun Mar 26 11:40:12 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 26 Mar 2006 11:40:12 -0700 (MST) Subject: [Rxtx] Error 0x5 at /home/bob/foo/tar/rxtx-2.1-7/build/../src/termios.c(860): Access is, denied. In-Reply-To: <4426A603.80508@gmail.com> References: <4426A603.80508@gmail.com> Message-ID: On Sun, 26 Mar 2006, Beat Arnet wrote: > Dear all, > > When trying to open the serial port, I sometimes (not always) run into > the following exception (when opening the serialPort): > > Error 0x5 at /home/bob/foo/tar/rxtx-2.1-7/build/../src/termios.c(860): > Access is > denied. > > java.lang.UnsatisfiedLinkError: native_psmisc_report_owner > at gnu.io.CommPortIdentifier.native_psmisc_report_owner(Native > Method) > at gnu.io.CommPortIdentifier.open(CommPortIdentifier.java:354) > at codeskin.tools.CLLoader.open(CLLoader.java:79) > at codeskin.tools.C2000Programmer.run(C2000Programmer.java:220) > at java.lang.Thread.run(Unknown Source) > > Is this the type of error where I should just try to open the port again, > or can it be avoided? > Hi Beat We did a second build of rxtx 2.1-7 to resolve that unsatisfied link error. It should work now. rxtx is trying to tell you it thinks someone else has the serial port open. You can try to open the port again but maybe you already have a copy of the program running when it happens? ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7r2.zip fixed build. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sun Mar 26 11:44:23 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 26 Mar 2006 11:44:23 -0700 (MST) Subject: [Rxtx] RXTX spec file (fwd) Message-ID: This is probably interesting for fedora/suse users. ---------- Forwarded message ---------- Date: Sun, 26 Mar 2006 16:25:45 +0200 To: taj at www.linux.org.uk Subject: RXTX spec file I send you this spec file which allows to create a RPM for Fedora 4, 5 (x86, x86_64) with Java Sun. -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: rxtx.spec Url: http://mailman.qbang.org/pipermail/rxtx/attachments/20060326/6c7b6af6/rxtx-0032.pl From tjarvi at qbang.org Sun Mar 26 23:42:59 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 26 Mar 2006 23:42:59 -0700 (MST) Subject: [Rxtx] Upcomming events. Message-ID: This Wednesday we will be announcing a new "Maintainer" for the rxtx project. The position is more like neutral leader. I wont be going away or doing less. This is just the right thing to do as it turns out the two people with CVS write access will be at the same company. We need a third and we need neutrality. The maintainer will have final say in any conflict and will try to be neutral. It will be open for discussion. Then we will do it :) I'll still do most of the footwork I do now. But. I'm falling behind. I should have gone through the mail-list and posted the next round of changes this weekend. I'm packing to move and its going so so - 13 years of toys collected. I suspect there will be a dead period on my part (a couple weeks) comming up. But if you get it on the mail-list, we will get it in if there are no objections. I may well not be reading the mail-list during this period as I look for a house and many other things. I hope everyone will help out. Thanks -- Trent Jarvi tjarvi at qbang.org From mahmoud_hadad at yahoo.com Sun Mar 26 07:31:19 2006 From: mahmoud_hadad at yahoo.com (ronan nick) Date: Sun, 26 Mar 2006 06:31:19 -0800 (PST) Subject: [Rxtx] a question about the COMM API Message-ID: <20060326143119.54919.qmail@web60014.mail.yahoo.com> hi, i was intrested in knowing how i can communicate with my internal modem using java? for example if i want to make a phone dialer application or a caller id application where should i be looking at? and as i understood the COMM API is for devices that is attached to the computer through serial ports. --------------------------------- New Yahoo! Messenger with Voice. Call regular phones from your PC and save big. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060326/ce8329f0/attachment-0034.html From dmarkman at mac.com Mon Mar 20 00:20:43 2006 From: dmarkman at mac.com (Dmitry Markman) Date: Mon, 20 Mar 2006 02:20:43 -0500 Subject: [Rxtx] Mac OS X RXTX java installer In-Reply-To: References: <07D0DE29-BA32-4CFE-B036-66BC6423D385@buechse.de> <441AE3E0.2030503@willicon.de> <12531986.1142622114996.JavaMail.dmarkman@mac.com> <441B2674.9010409@willicon.de> <13577405.1142634732776.JavaMail.dmarkman@mac.com> <441B4182.8010407@willicon.de> <92CD0D6C-5BE8-426E-A46D-99452059FF49@mac.com> <441BBB2D.8030305@willicon.de> <441C4088.5090905@willicon.de> Message-ID: <64BC1E23-FDDE-4CE6-8863-CFC881CBC224@mac.com> Hi all I put RXTX installer that will install everything (and will create / var/lock if necessary and add user to the uucp group) for mac os x from Java into the rxtx's CVS repository it could be easily modified to install files for any platform it uses Greg Guerin's AuthKit for authentication and authorization Greg released that kit under artistic license, so Trent, please take a look we, probably, can negotiate license with Greg if it's necessary Greg's AuthKit could be downloaded from http://www.amug.org/~glguerin/ sw/#authkit Michael Hall (mikehall at spacestar dot net) had a suggestion to make implementation of the jaas LoginModule based on Greg's AuthKit (his modification of the Greg's AuthKit could be found at http:// www.spacestar.net/users/mikehall/authkit.dmg) but Michael's AuthKitLoginModule does only half a job: it does authenticate but it can not run any external unix process in privileged mode (at least I wasn't able to do so) possible explanation could be found in conversation between Greg and Michael at Apple's java-dev list (look for archives) so I didn't use jaas API for rxtxinstaller I created folder MacOSX in the contrib folder comment 1. if you want to run that installer as standalone application all you need that RXTXInstaller.jar 2. if you want to use webstart you have to add Greg's libAuthKit.jnilib to the mac os x's resources in theory RXTXInstaller.jar doesn't need it, but there is a problem with loading libAuthKit.jnilib from webstart authkit uses loadLibrary method to load library and it failed (from webstart) for standalone application I extract libAuthKit.jnilib from the RXTXInstaller.jar and put it into the /Library/Java/Extensions or ~/Library/Java/Extensions folder that file will be deleted after installer quit unfortunately I didn't have time to put documentation there but it is mostly self-explanatory I took installer code from my gl4java installer that I did about 3 years ago (with small modifications) it would be very nice if Apple will release LoginModule that really will do the job (com.apple.security.auth.module package????? ) (UnixLoginModule is pretty useless) From lyon at docjava.com Mon Mar 20 06:34:39 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Mon, 20 Mar 2006 08:34:39 -0500 Subject: [Rxtx] Mac OS X RXTX java installer In-Reply-To: <64BC1E23-FDDE-4CE6-8863-CFC881CBC224@mac.com> References: <07D0DE29-BA32-4CFE-B036-66BC6423D385@buechse.de> <441AE3E0.2030503@willicon.de> <12531986.1142622114996.JavaMail.dmarkman@mac.com> <441B2674.9010409@willicon.de> <13577405.1142634732776.JavaMail.dmarkman@mac.com> <441B4182.8010407@willicon.de> <92CD0D6C-5BE8-426E-A46D-99452059FF49@mac.com> <441BBB2D.8030305@willicon.de> <441C4088.5090905@willicon.de> <64BC1E23-FDDE-4CE6-8863-CFC881CBC224@mac.com> Message-ID: Hi Dimitry, This sounds like great work. Just a couple of questions; After the check out of the CVS files, using: setenv CVSROOT :pserver:anonymous at cvs.milestonesolutions.com:/usr/local/cvsroot 53 8:28 setenv PASSWORD mousy 54 8:29 cvs login 55 8:29 cvs checkout rxtx-devel I cd'd over to: rxtx-devel/MACOSX_IDE And found: CVS/ CW/ ForPackageMaker/ PB/ Where is the installer? Thanks! - Doug From tjarvi at qbang.org Mon Mar 20 06:39:37 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 20 Mar 2006 06:39:37 -0700 (MST) Subject: [Rxtx] Mac OS X RXTX java installer In-Reply-To: References: <07D0DE29-BA32-4CFE-B036-66BC6423D385@buechse.de> <441AE3E0.2030503@willicon.de> <12531986.1142622114996.JavaMail.dmarkman@mac.com> <441B2674.9010409@willicon.de> <13577405.1142634732776.JavaMail.dmarkman@mac.com> <441B4182.8010407@willicon.de> <92CD0D6C-5BE8-426E-A46D-99452059FF49@mac.com> <441BBB2D.8030305@willicon.de> <441C4088.5090905@willicon.de> <64BC1E23-FDDE-4CE6-8863-CFC881CBC224@mac.com> Message-ID: On Mon, 20 Mar 2006, Dr. Douglas Lyon wrote: > Hi Dimitry, > This sounds like great work. Just a couple of questions; > After the check out of the CVS files, using: > setenv CVSROOT > :pserver:anonymous at cvs.milestonesolutions.com:/usr/local/cvsroot > 53 8:28 setenv PASSWORD mousy > 54 8:29 cvs login > 55 8:29 cvs checkout rxtx-devel Hi Doug You want "cvs checkout -r commapi-0-0-1 rxtx-devel" to get RXTX 2.1 The default branch is rxtx 2.0 which isn't very active right now. -- Trent Jarvi tjarvi at qbang.org From lyon at docjava.com Mon Mar 20 07:05:44 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Mon, 20 Mar 2006 09:05:44 -0500 Subject: [Rxtx] Mac OS X RXTX java installer In-Reply-To: References: <07D0DE29-BA32-4CFE-B036-66BC6423D385@buechse.de> <441AE3E0.2030503@willicon.de> <12531986.1142622114996.JavaMail.dmarkman@mac.com> <441B2674.9010409@willicon.de> <13577405.1142634732776.JavaMail.dmarkman@mac.com> <441B4182.8010407@willicon.de> <92CD0D6C-5BE8-426E-A46D-99452059FF49@mac.com> <441BBB2D.8030305@willicon.de> <441C4088.5090905@willicon.de> <64BC1E23-FDDE-4CE6-8863-CFC881CBC224@mac.com> Message-ID: Hi Trent, Thanks for the info on the CVS checkout procedure. I did that and am still not sure where the installer is. Here is what I have: cd MACOSX_IDE/ p4.docjava.com{lyon}121: ls CVS/ ForPackageMaker/ PB/ p4.docjava.com{lyon}122: find . | more . ./ForPackageMaker ./ForPackageMaker/RXTX.pkg.sit.hqx ./ForPackageMaker/Resources ./ForPackageMaker/Resources/ReadMe.rtf ./ForPackageMaker/Resources/Welcome.rtf ./ForPackageMaker/Resources/CVS ./ForPackageMaker/Resources/CVS/Entries ./ForPackageMaker/Resources/CVS/Repository ./ForPackageMaker/Resources/CVS/Tag ./ForPackageMaker/Resources/CVS/Root ./ForPackageMaker/Resources/preinstall ./ForPackageMaker/Resources/License.rtf ./ForPackageMaker/Resources/preupgrade ./ForPackageMaker/RXTX.pmsp ./ForPackageMaker/CVS ./ForPackageMaker/CVS/Entries ./ForPackageMaker/CVS/Repository ./ForPackageMaker/CVS/Entries.Log ./ForPackageMaker/CVS/Tag ./ForPackageMaker/CVS/Root ./ForPackageMaker/RXTX_Tiger.pkg.sitx.hqx ./ForPackageMaker/RXTX_Jag.pkg.sit.hqx ./ForPackageMaker/Install ./ForPackageMaker/Install/CVS ./ForPackageMaker/Install/CVS/Entries ./ForPackageMaker/Install/CVS/Repository ./ForPackageMaker/Install/CVS/Tag ./ForPackageMaker/Install/CVS/Root ./ForPackageMaker/Install/Library ./ForPackageMaker/Install/Library/CVS ./ForPackageMaker/Install/Library/CVS/Entries ./ForPackageMaker/Install/Library/CVS/Repository ./ForPackageMaker/Install/Library/CVS/Tag ./ForPackageMaker/Install/Library/CVS/Root ./ForPackageMaker/Install/Library/Java ./ForPackageMaker/Install/Library/Java/Extensions ./ForPackageMaker/Install/Library/Java/Extensions/RXTXcomm.jar ./ForPackageMaker/Install/Library/Java/Extensions/CVS ./ForPackageMaker/Install/Library/Java/Extensions/CVS/Entries ./ForPackageMaker/Install/Library/Java/Extensions/CVS/Repository ./ForPackageMaker/Install/Library/Java/Extensions/CVS/Tag ./ForPackageMaker/Install/Library/Java/Extensions/CVS/Root ./ForPackageMaker/Install/Library/Java/Extensions/librxtxSerial.jnilib ./ForPackageMaker/Install/Library/Java/CVS ./ForPackageMaker/Install/Library/Java/CVS/Entries ./ForPackageMaker/Install/Library/Java/CVS/Repository ./ForPackageMaker/Install/Library/Java/CVS/Entries.Log ./ForPackageMaker/Install/Library/Java/CVS/Tag ./ForPackageMaker/Install/Library/Java/CVS/Root ./ForPackageMaker/RXTX_Tiger.pmproj.sitx.hqx ./CVS ./CVS/Entries ./CVS/Repository ./CVS/Entries.Log ./CVS/Tag ./CVS/Root ./PB ./PB/LibSerialUniversal.xcodeproj.sitx.hqx ./PB/CVS ./PB/CVS/Entries ./PB/CVS/Repository ./PB/CVS/Entries.Log ./PB/CVS/Tag ./PB/CVS/Root ./PB/LibSerial.pbproj.sit.hqx ./PB/startpoint.c ./PB/config.h What is the procedure to run this installer? Do we need a README in: /rxtx-devel/MACOSX_IDE Here is what we have: CVS/ ForPackageMaker/ PB/ Thanks! - DL >On Mon, 20 Mar 2006, Dr. Douglas Lyon wrote: > >>Hi Dimitry, >>This sounds like great work. Just a couple of questions; >>After the check out of the CVS files, using: >>setenv CVSROOT >>:pserver:anonymous at cvs.milestonesolutions.com:/usr/local/cvsroot >> 53 8:28 setenv PASSWORD mousy >> 54 8:29 cvs login >> 55 8:29 cvs checkout rxtx-devel > >Hi Doug > >You want "cvs checkout -r commapi-0-0-1 rxtx-devel" to get RXTX 2.1 >The default branch is rxtx 2.0 which isn't very active right now. > >-- >Trent Jarvi >tjarvi at qbang.org From tjarvi at qbang.org Mon Mar 20 07:25:30 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 20 Mar 2006 07:25:30 -0700 (MST) Subject: [Rxtx] Mac OS X RXTX java installer In-Reply-To: References: <07D0DE29-BA32-4CFE-B036-66BC6423D385@buechse.de> <441AE3E0.2030503@willicon.de> <12531986.1142622114996.JavaMail.dmarkman@mac.com> <441B2674.9010409@willicon.de> <13577405.1142634732776.JavaMail.dmarkman@mac.com> <441B4182.8010407@willicon.de> <92CD0D6C-5BE8-426E-A46D-99452059FF49@mac.com> <441BBB2D.8030305@willicon.de> <441C4088.5090905@willicon.de> <64BC1E23-FDDE-4CE6-8863-CFC881CBC224@mac.com> Message-ID: On Mon, 20 Mar 2006, Dr. Douglas Lyon wrote: > Hi Trent, > Thanks for the info on the CVS checkout procedure. > I did that and am still not sure where the installer is. Hi Doug It does look like it was not cvs committed. There is no rxtx-devel/contrib/MacOSX directory in there at the moment. It was mentioned that it was put under contrib. -- Trent Jarvi tjarvi at qbang.org From dmarkman at mac.com Mon Mar 20 07:29:56 2006 From: dmarkman at mac.com (Dmitry Markman) Date: Mon, 20 Mar 2006 09:29:56 -0500 Subject: [Rxtx] Mac OS X RXTX java installer In-Reply-To: References: <07D0DE29-BA32-4CFE-B036-66BC6423D385@buechse.de> <441AE3E0.2030503@willicon.de> <12531986.1142622114996.JavaMail.dmarkman@mac.com> <441B2674.9010409@willicon.de> <13577405.1142634732776.JavaMail.dmarkman@mac.com> <441B4182.8010407@willicon.de> <92CD0D6C-5BE8-426E-A46D-99452059FF49@mac.com> <441BBB2D.8030305@willicon.de> <441C4088.5090905@willicon.de> <64BC1E23-FDDE-4CE6-8863-CFC881CBC224@mac.com> Message-ID: <6054EB4E-F7E0-4A9C-BDDA-D582D6D8826F@mac.com> you can find it in the rxtx-devel/contrib folder On Mar 20, 2006, at 9:05 AM, Dr. Douglas Lyon wrote: > Hi Trent, > Thanks for the info on the CVS checkout procedure. > I did that and am still not sure where the installer is. > Here is what I have: > cd MACOSX_IDE/ > p4.docjava.com{lyon}121: ls > CVS/ ForPackageMaker/ PB/ > p4.docjava.com{lyon}122: find . | more > . > ./ForPackageMaker > ./ForPackageMaker/RXTX.pkg.sit.hqx > ./ForPackageMaker/Resources > ./ForPackageMaker/Resources/ReadMe.rtf > ./ForPackageMaker/Resources/Welcome.rtf > ./ForPackageMaker/Resources/CVS > ./ForPackageMaker/Resources/CVS/Entries > ./ForPackageMaker/Resources/CVS/Repository > ./ForPackageMaker/Resources/CVS/Tag > ./ForPackageMaker/Resources/CVS/Root > ./ForPackageMaker/Resources/preinstall > ./ForPackageMaker/Resources/License.rtf > ./ForPackageMaker/Resources/preupgrade > ./ForPackageMaker/RXTX.pmsp > ./ForPackageMaker/CVS > ./ForPackageMaker/CVS/Entries > ./ForPackageMaker/CVS/Repository > ./ForPackageMaker/CVS/Entries.Log > ./ForPackageMaker/CVS/Tag > ./ForPackageMaker/CVS/Root > ./ForPackageMaker/RXTX_Tiger.pkg.sitx.hqx > ./ForPackageMaker/RXTX_Jag.pkg.sit.hqx > ./ForPackageMaker/Install > ./ForPackageMaker/Install/CVS > ./ForPackageMaker/Install/CVS/Entries > ./ForPackageMaker/Install/CVS/Repository > ./ForPackageMaker/Install/CVS/Tag > ./ForPackageMaker/Install/CVS/Root > ./ForPackageMaker/Install/Library > ./ForPackageMaker/Install/Library/CVS > ./ForPackageMaker/Install/Library/CVS/Entries > ./ForPackageMaker/Install/Library/CVS/Repository > ./ForPackageMaker/Install/Library/CVS/Tag > ./ForPackageMaker/Install/Library/CVS/Root > ./ForPackageMaker/Install/Library/Java > ./ForPackageMaker/Install/Library/Java/Extensions > ./ForPackageMaker/Install/Library/Java/Extensions/RXTXcomm.jar > ./ForPackageMaker/Install/Library/Java/Extensions/CVS > ./ForPackageMaker/Install/Library/Java/Extensions/CVS/Entries > ./ForPackageMaker/Install/Library/Java/Extensions/CVS/Repository > ./ForPackageMaker/Install/Library/Java/Extensions/CVS/Tag > ./ForPackageMaker/Install/Library/Java/Extensions/CVS/Root > ./ForPackageMaker/Install/Library/Java/Extensions/librxtxSerial.jnilib > ./ForPackageMaker/Install/Library/Java/CVS > ./ForPackageMaker/Install/Library/Java/CVS/Entries > ./ForPackageMaker/Install/Library/Java/CVS/Repository > ./ForPackageMaker/Install/Library/Java/CVS/Entries.Log > ./ForPackageMaker/Install/Library/Java/CVS/Tag > ./ForPackageMaker/Install/Library/Java/CVS/Root > ./ForPackageMaker/RXTX_Tiger.pmproj.sitx.hqx > ./CVS > ./CVS/Entries > ./CVS/Repository > ./CVS/Entries.Log > ./CVS/Tag > ./CVS/Root > ./PB > ./PB/LibSerialUniversal.xcodeproj.sitx.hqx > ./PB/CVS > ./PB/CVS/Entries > ./PB/CVS/Repository > ./PB/CVS/Entries.Log > ./PB/CVS/Tag > ./PB/CVS/Root > ./PB/LibSerial.pbproj.sit.hqx > ./PB/startpoint.c > ./PB/config.h > > What is the procedure to run this installer? > Do we need a README in: > /rxtx-devel/MACOSX_IDE > Here is what we have: > CVS/ ForPackageMaker/ PB/ > > > Thanks! > - DL > >> On Mon, 20 Mar 2006, Dr. Douglas Lyon wrote: >> >>> Hi Dimitry, >>> This sounds like great work. Just a couple of questions; >>> After the check out of the CVS files, using: >>> setenv CVSROOT :pserver:anonymous at cvs.milestonesolutions.com:/usr/ >>> local/cvsroot >>> 53 8:28 setenv PASSWORD mousy >>> 54 8:29 cvs login >>> 55 8:29 cvs checkout rxtx-devel >> >> Hi Doug >> >> You want "cvs checkout -r commapi-0-0-1 rxtx-devel" to get RXTX 2.1 >> The default branch is rxtx 2.0 which isn't very active right now. >> >> -- >> Trent Jarvi >> tjarvi at qbang.org > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx Dmitry Markman From mikehall at spacestar.net Mon Mar 20 05:25:25 2006 From: mikehall at spacestar.net (Michael Hall) Date: Mon, 20 Mar 2006 06:25:25 -0600 Subject: [Rxtx] Re: Mac OS X RXTX java installer In-Reply-To: <64BC1E23-FDDE-4CE6-8863-CFC881CBC224@mac.com> References: <07D0DE29-BA32-4CFE-B036-66BC6423D385@buechse.de> <441AE3E0.2030503@willicon.de> <12531986.1142622114996.JavaMail.dmarkman@mac.com> <441B2674.9010409@willicon.de> <13577405.1142634732776.JavaMail.dmarkman@mac.com> <441B4182.8010407@willicon.de> <92CD0D6C-5BE8-426E-A46D-99452059FF49@mac.com> <441BBB2D.8030305@willicon.de> <441C4088.5090905@willicon.de> <64BC1E23-FDDE-4CE6-8863-CFC881CBC224@mac.com> Message-ID: <247EB61F-5CD1-4132-89A2-FC105B6CF9A5@spacestar.net> On Mar 20, 2006, at 1:20 AM, Dmitry Markman wrote: > > Michael Hall (mikehall at spacestar dot net) had a suggestion to > make implementation of the jaas LoginModule > based on Greg's AuthKit > (his modification of the Greg's AuthKit could be found at http:// > www.spacestar.net/users/mikehall/authkit.dmg) > but Michael's AuthKitLoginModule does only half a job: > it does authenticate > but it can not run any external unix process in privileged mode (at > least I wasn't able to do so) If you got it working directly with Greg's the point is moot. But to clarify it anyhow. The login module does not allow you to do anything anything privileged on return as was explained by Greg. You need to work with a separate privileged process using the execPrivileged method of his API. I assume you did something similar although I haven't looked at how you are using it yet. I allowed instead for a action to be performed at the same time you login/authenticate,this... System.setProperty("authkit.action","/usr/bin/id"); just before this... lc.login(); To clarify, safely ignored as you are already complete. Mike Hall mikehall at spacestar dot net http://www.spacestar.net/users/mikehall http://sourceforge.net/projects/macnative -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2427 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20060320/f6e18202/smime-0037.bin From dmarkman at mac.com Mon Mar 20 07:36:47 2006 From: dmarkman at mac.com (Dmitry Markman) Date: Mon, 20 Mar 2006 09:36:47 -0500 Subject: [Rxtx] Re: Mac OS X RXTX java installer In-Reply-To: <247EB61F-5CD1-4132-89A2-FC105B6CF9A5@spacestar.net> References: <07D0DE29-BA32-4CFE-B036-66BC6423D385@buechse.de> <441AE3E0.2030503@willicon.de> <12531986.1142622114996.JavaMail.dmarkman@mac.com> <441B2674.9010409@willicon.de> <13577405.1142634732776.JavaMail.dmarkman@mac.com> <441B4182.8010407@willicon.de> <92CD0D6C-5BE8-426E-A46D-99452059FF49@mac.com> <441BBB2D.8030305@willicon.de> <441C4088.5090905@willicon.de> <64BC1E23-FDDE-4CE6-8863-CFC881CBC224@mac.com> <247EB61F-5CD1-4132-89A2-FC105B6CF9A5@spacestar.net> Message-ID: Hi, Michael all I have to do is to run some shell script I tried to use your action mechanism and it worked great so I just System.setProperty ("authkit.action","" ) and after that I even don't need to run anything like subject.doAs.... but after few thoughts I choose to use plain Greg's approach, because in that case I don't have to deal with various java's configurations files and therefore to use 2-3 -D parameters in the java command line especially it's useful for java web start (it's so fragile :-( ) thanks for the great job On Mar 20, 2006, at 7:25 AM, Michael Hall wrote: > > On Mar 20, 2006, at 1:20 AM, Dmitry Markman wrote: >> >> Michael Hall (mikehall at spacestar dot net) had a suggestion to >> make implementation of the jaas LoginModule >> based on Greg's AuthKit >> (his modification of the Greg's AuthKit could be found at http:// >> www.spacestar.net/users/mikehall/authkit.dmg) >> but Michael's AuthKitLoginModule does only half a job: >> it does authenticate >> but it can not run any external unix process in privileged mode >> (at least I wasn't able to do so) > > If you got it working directly with Greg's the point is moot. > > But to clarify it anyhow. > The login module does not allow you to do anything anything > privileged on return as was explained by Greg. You need to work > with a separate privileged process using the execPrivileged method > of his API. I assume you did something similar although I haven't > looked at how you are using it yet. > I allowed instead for a action to be performed at the same time you > login/authenticate,this... > System.setProperty("authkit.action","/usr/bin/id"); > just before this... > lc.login(); > To clarify, safely ignored as you are already complete. > > Mike Hall mikehall at spacestar dot net > http://www.spacestar.net/users/mikehall > http://sourceforge.net/projects/macnative > > > Dmitry Markman From dmarkman at mac.com Mon Mar 20 07:44:45 2006 From: dmarkman at mac.com (Dmitry Markman) Date: Mon, 20 Mar 2006 09:44:45 -0500 Subject: [Rxtx] Mac OS X RXTX java installer In-Reply-To: References: <07D0DE29-BA32-4CFE-B036-66BC6423D385@buechse.de> <441AE3E0.2030503@willicon.de> <12531986.1142622114996.JavaMail.dmarkman@mac.com> <441B2674.9010409@willicon.de> <13577405.1142634732776.JavaMail.dmarkman@mac.com> <441B4182.8010407@willicon.de> <92CD0D6C-5BE8-426E-A46D-99452059FF49@mac.com> <441BBB2D.8030305@willicon.de> <441C4088.5090905@willicon.de> <64BC1E23-FDDE-4CE6-8863-CFC881CBC224@mac.com> Message-ID: it's in the commapi-0-0-1 branch I tested it right now: cvs co -r commapi-0-0-1 rxtx-devel and I got everything On Mar 20, 2006, at 9:25 AM, Trent Jarvi wrote: > On Mon, 20 Mar 2006, Dr. Douglas Lyon wrote: > >> Hi Trent, >> Thanks for the info on the CVS checkout procedure. >> I did that and am still not sure where the installer is. > > Hi Doug > > It does look like it was not cvs committed. There is no rxtx-devel/ > contrib/MacOSX directory in there at the moment. It was mentioned > that it was put under contrib. > > -- > Trent Jarvi > tjarvi at qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx Dmitry Markman From tjarvi at qbang.org Mon Mar 20 07:52:57 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 20 Mar 2006 07:52:57 -0700 (MST) Subject: [Rxtx] Mac OS X RXTX java installer In-Reply-To: References: <07D0DE29-BA32-4CFE-B036-66BC6423D385@buechse.de> <441AE3E0.2030503@willicon.de> <12531986.1142622114996.JavaMail.dmarkman@mac.com> <441B2674.9010409@willicon.de> <13577405.1142634732776.JavaMail.dmarkman@mac.com> <441B4182.8010407@willicon.de> <92CD0D6C-5BE8-426E-A46D-99452059FF49@mac.com> <441BBB2D.8030305@willicon.de> <441C4088.5090905@willicon.de> <64BC1E23-FDDE-4CE6-8863-CFC881CBC224@mac.com> Message-ID: On Mon, 20 Mar 2006, Dmitry Markman wrote: > it's in the commapi-0-0-1 branch > > I tested it right now: > cvs co -r commapi-0-0-1 rxtx-devel > > and I got everything > A fresh checkout worked. Here is a copy of the tree (just the installer bits) ftp://ftp.qbang.org/pub/rxtx/MacOSX-installer.zip -- Trent Jarvi tjarvi at qbang.org From lyon at docjava.com Mon Mar 20 08:08:26 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Mon, 20 Mar 2006 10:08:26 -0500 Subject: [Rxtx] Mac OS X RXTX java installer In-Reply-To: References: <07D0DE29-BA32-4CFE-B036-66BC6423D385@buechse.de> <441AE3E0.2030503@willicon.de> <12531986.1142622114996.JavaMail.dmarkman@mac.com> <441B2674.9010409@willicon.de> <13577405.1142634732776.JavaMail.dmarkman@mac.com> <441B4182.8010407@willicon.de> <92CD0D6C-5BE8-426E-A46D-99452059FF49@mac.com> <441BBB2D.8030305@willicon.de> <441C4088.5090905@willicon.de> <64BC1E23-FDDE-4CE6-8863-CFC881CBC224@mac.com> Message-ID: Hi All, Is the Auth package able to work properly on non Mac OS's? It was not clear from the doc or download. Thanks! - Doug From dmarkman at mac.com Mon Mar 20 08:15:22 2006 From: dmarkman at mac.com (Dmitry Markman) Date: Mon, 20 Mar 2006 10:15:22 -0500 Subject: [Rxtx] Mac OS X RXTX java installer In-Reply-To: References: <07D0DE29-BA32-4CFE-B036-66BC6423D385@buechse.de> <441AE3E0.2030503@willicon.de> <12531986.1142622114996.JavaMail.dmarkman@mac.com> <441B2674.9010409@willicon.de> <13577405.1142634732776.JavaMail.dmarkman@mac.com> <441B4182.8010407@willicon.de> <92CD0D6C-5BE8-426E-A46D-99452059FF49@mac.com> <441BBB2D.8030305@willicon.de> <441C4088.5090905@willicon.de> <64BC1E23-FDDE-4CE6-8863-CFC881CBC224@mac.com> Message-ID: <217312D8-CCCA-4859-ABA6-32DF1CC817B9@mac.com> thanks Trent, for putting it on ftp server On Mar 20, 2006, at 9:52 AM, Trent Jarvi wrote: > A fresh checkout worked. Here is a copy of the tree (just the > installer bits) > > ftp://ftp.qbang.org/pub/rxtx/MacOSX-installer.zip > Dmitry Markman From dmarkman at mac.com Mon Mar 20 09:14:03 2006 From: dmarkman at mac.com (Dmitry Markman) Date: Mon, 20 Mar 2006 11:14:03 -0500 Subject: [Rxtx] Mac OS X RXTX java installer In-Reply-To: References: <07D0DE29-BA32-4CFE-B036-66BC6423D385@buechse.de> <441AE3E0.2030503@willicon.de> <12531986.1142622114996.JavaMail.dmarkman@mac.com> <441B2674.9010409@willicon.de> <13577405.1142634732776.JavaMail.dmarkman@mac.com> <441B4182.8010407@willicon.de> <92CD0D6C-5BE8-426E-A46D-99452059FF49@mac.com> <441BBB2D.8030305@willicon.de> <441C4088.5090905@willicon.de> <64BC1E23-FDDE-4CE6-8863-CFC881CBC224@mac.com> Message-ID: <4DEBA6F0-DA45-4E84-823E-1F1AC48BDCCC@mac.com> no it will work only on mac os x however it's harmless to run it on other platform if you want to use it for other platform you have to do the following (I'll do it for linux) 1. modify RXTXInstaller class method public static RXTXInstaller getInstance() public static RXTXInstaller getInstance() { String osName = System.getProperty("os.name").toLowerCase(); if(osName.startsWith("mac")){ return new gnu.io.installer.macosx.MACOSXRXTXInstaller(); } else if(osName.startsWith("windows")){ return new gnu.io.installer.windows.WindowsRXTXInstaller(); }else if(osName.startsWith("linux")){ return new gnu.io.installer.linux.LinuxRXTXInstaller(); } return null; } 2. create folder gnu/io/installer/linux/ 3. create class Linux386RXTXInstaller package gnu.io.installer.linux; import java.io.File; public class Linux386RXTXInstaller extends gnu.io.installer.RXTXInstaller{ public Linux386RXTXInstaller(){ createJarFolder(); createLibFolder(); addJarResource("RXTXcomm.jar","/gnu/io/installer/resources/ linux/jar/RXTXcomm.dat"); addLibResource("librxtxSerial.so","/gnu/io/installer/ resources/linux/lib/librxtxSerial.so"); } protected void createJarFolder(){ String javaHome = System.getProperty("java.home"); char separator = File.separatorChar; jarFolder = new File(javaHome+separator+"lib"+separator+"ext"); } protected void createLibFolder(){ String javaHome = System.getProperty("java.home"); char separator = File.separatorChar; libFolder = new File(javaHome+separator+"bin"); } public void runPreProcess() {} //put here some action you need public void runPostProcess() {} //put here some action you need } 4. create folder /gnu/io/installer/resources/linux/jar and put there linux's version of RXTXcomm.dat (which is renamed RXTXcomm.jar) 5. create folder /gnu/io/installer/resources/linux/lib and put there linux's version of librxtxSerial. so 6. make sure that RXTXInstaller.jar has the following items: /gnu/io/installer/resources/linux/jar/RXTXcomm.jar /gnu/io/installer/resources/linux/lib/librxtxSerial.so 7. modify file installer.pref: jar file RXTXInstaller.jar must have the following item /gnu/io/installer/installer.pref that's basically it for windows you have to do the similar things: just replace linux to windows and librxtxSerial.so to rxtxSerial.dll and create appropriate gnu.io.installer.windows.WindowsRXTXInstaller class package gnu.io.installer.windows; import java.io.File; public class WindowsRXTXInstaller extends gnu.io.installer.RXTXInstaller{ public WindowsRXTXInstaller(){ createJarFolder(); createLibFolder(); addJarResource("RXTXcomm.jar","/gnu/io/installer/resources/ windows/jar/RXTXcomm.dat"); addLibResource("librxtxSerial.so","/gnu/io/installer/ resources/windows/lib/rxtxSerial.dll"); } protected void createJarFolder(){ String javaHome = System.getProperty("java.home"); char separator = File.separatorChar; jarFolder = new File(javaHome+separator+"lib"+separator+"ext"); } protected void createLibFolder(){ String javaHome = System.getProperty("java.home"); char separator = File.separatorChar; libFolder = new File(javaHome+separator+"bin"); } public void runPreProcess() {} //put here some action you need public void runPostProcess() {} //put here some action you need } installer.pref will look like On Mar 20, 2006, at 10:08 AM, Dr. Douglas Lyon wrote: > Hi All, > Is the Auth package able to work properly on > non Mac OS's? > It was not clear from the doc or download. > > Thanks! > - Doug > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx Dmitry Markman From joachim at buechse.de Mon Mar 20 10:49:06 2006 From: joachim at buechse.de (Joachim Buechse) Date: Mon, 20 Mar 2006 18:49:06 +0100 Subject: [Rxtx] BUG: Lock file stays even if port opening fails Message-ID: This was only tested on MacOSX but looking at the code, it should be true for all systems that use lock_uucp. I am opening a port which can not be opened (dialup port of a telephone paired via bluetooth but currently not reachable). The lock file is created and stays arround, even though the port open failed. After looking a bit through the code (of 2.17), I really wonder if it wouldn't be a good idea to make the "locking" an explicit operation called from the java code. This would certainly simplify the generation of meaningfull exceptions (and java based debugging). Maybe even the handling of "preopened" ports should be in the Java part of the lib (again for java based debugging puposes). That beeing said, I have no idea if this would be possible for the 2.07 implementation. Regards, Joachim From tjarvi at qbang.org Mon Mar 20 11:24:22 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 20 Mar 2006 11:24:22 -0700 (MST) Subject: [Rxtx] BUG: Lock file stays even if port opening fails In-Reply-To: References: Message-ID: On Mon, 20 Mar 2006, Joachim Buechse wrote: > This was only tested on MacOSX but looking at the code, it should be true > for all systems that use lock_uucp. > > I am opening a port which can not be opened (dialup port of a telephone > paired via bluetooth but currently not reachable). The lock file is > created and stays arround, even though the port open failed. > > > After looking a bit through the code (of 2.17), I really wonder if it > wouldn't be a good idea to make the "locking" an explicit operation > called from the java code. This would certainly simplify the generation > of meaningfull exceptions (and java based debugging). > Maybe even the handling of "preopened" ports should be in the Java part > of the lib (again for java based debugging puposes). That beeing said, I > have no idea if this would be possible for the 2.07 implementation. > > Regards, Hi Joachim It should be possible in the 2.0-7 implementation too. The calls to RXTXPort.java would not change. We would just do more there Moving more of that logic into Java would be better as many people don't like to look at C code. There is a liblockdev on most Linux distros that can do most of the C code and would be easier to use. The problem is embeded devices will not have that library. The preopened port code has not been really tested. That was a last minute request in a product cycle. I expect it will be tested this year though. As I recall, some devices really do not like CD raising on open. The preopened ports then allow people to mess around in java without power cycling the devices or losing data. -- Trent Jarvi tjarvi at qbang.org From joachim at buechse.de Mon Mar 20 12:01:08 2006 From: joachim at buechse.de (Joachim Buechse) Date: Mon, 20 Mar 2006 20:01:08 +0100 Subject: [Rxtx] BUG: Lock file stays even if port opening fails In-Reply-To: References: Message-ID: Hi Trent, What is your general feeling about moving code to Java? The last days I have been reading quite a bit of the code and there are several things, that might not work as expected. I'll give you two examples from is_device_locked: if LOCKDIR == /var/spool/locks the directory /var/spool/lock will not be checked. LOCKDIR is not checked for lockfiles with unexpected pefixes While these things have probably never been discovered in production, they are still possibly incorrect implementations. If it was Java code, I would write some unit tests producing the errors that could later be corrected. PS: One could imagine to actually implement the whole lockfile handling in Java using some native routines to get the values required (pid, st_dev, st_rdev, ...). On 20.03.2006, at 19:24, Trent Jarvi wrote: > On Mon, 20 Mar 2006, Joachim Buechse wrote: > >> This was only tested on MacOSX but looking at the code, it should >> be true for all systems that use lock_uucp. >> >> I am opening a port which can not be opened (dialup port of a >> telephone paired via bluetooth but currently not reachable). The >> lock file is created and stays arround, even though the port open >> failed. >> >> >> After looking a bit through the code (of 2.17), I really wonder if >> it wouldn't be a good idea to make the "locking" an explicit >> operation called from the java code. This would certainly simplify >> the generation of meaningfull exceptions (and java based debugging). >> Maybe even the handling of "preopened" ports should be in the Java >> part of the lib (again for java based debugging puposes). That >> beeing said, I have no idea if this would be possible for the 2.07 >> implementation. >> >> Regards, > > Hi Joachim > > It should be possible in the 2.0-7 implementation too. The calls > to RXTXPort.java would not change. We would just do more there > Moving more of that logic into Java would be better as many people > don't like to look at C code. There is a liblockdev on most Linux > distros that can do most of the C code and would be easier to use. > The problem is embeded devices will not have that library. > > The preopened port code has not been really tested. That was a > last minute request in a product cycle. I expect it will be tested > this year though. As I recall, some devices really do not like CD > raising on open. The preopened ports then allow people to mess > around in java without power cycling the devices or losing data. > > -- > Trent Jarvi > tjarvi at qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Mon Mar 20 12:21:02 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 20 Mar 2006 12:21:02 -0700 (MST) Subject: [Rxtx] BUG: Lock file stays even if port opening fails In-Reply-To: References: Message-ID: On Mon, 20 Mar 2006, Joachim Buechse wrote: > Hi Trent, > > What is your general feeling about moving code to Java? The last days I > have been reading quite a bit of the code and there are several things, > that might not work as expected. > > I'll give you two examples from is_device_locked: > > if LOCKDIR == /var/spool/locks the directory /var/spool/lock will not be > checked. > LOCKDIR is not checked for lockfiles with unexpected pefixes > > While these things have probably never been discovered in production, > they are still possibly incorrect implementations. If it was Java code, I > would write some unit tests producing the errors that could later be > corrected. > > PS: One could imagine to actually implement the whole lockfile handling > in Java using some native routines to get the values required (pid, > st_dev, st_rdev, ...). Hi Joachim I like the idea of moving more of the code into java but there are some things to consider. If you break this into multiple JNI calls, the performance will drop considerably during enumeration of ports. We are looking for 256 ports per dev type vs (16? in Sun's 2.0 and fewer types). Its hard to make assumptions. I've seen virtual ports start at /dev/foo100 for instance. It works out to over 7500 ports on Linux if you enable them all. We already trim that back by default. See Linux-all-ports in RXTXCommDriver.java. There are also native libraries that rxtx can link to. If you move too much into Java, linking to 'standard' libraries with distros will break. "configure --enable-liblock=yes" will not be doable. This is probably a favorable way with RedHat, Debian, Suse and others. Thats the right thing to do if there will be rpms, dpkg, .. For those reasons, I think it still make sense to keep it to a minimal ~3 calls to JNI code that we can use for speed and versatility. lock() isLocked(), unlock() perhaps. When I say speed, its more about avoiding crossing the JNI layer multiple times than java vs C performance. With versatility I think liblock is the right way for most but not all (embeded) linux distros. -- Trent Jarvi tjarvi at qbang.org From joachim at buechse.de Mon Mar 20 12:42:04 2006 From: joachim at buechse.de (Joachim Buechse) Date: Mon, 20 Mar 2006 20:42:04 +0100 Subject: [Rxtx] BUG: Lock file stays even if port opening fails In-Reply-To: References: Message-ID: <82C19FE7-DDCB-45B6-B2C9-7606B66F0124@buechse.de> Ok, what about providing a default implementation in Java? The RXTXCommDriver would call a (native) function useNativeLocking and if it returns true, call the native functions for lock() isLocked (), unlock(), else is would use the Java based default implementation. This could possibly be overriden by a property (again for debugging). Joachim On 20.03.2006, at 20:21, Trent Jarvi wrote: > On Mon, 20 Mar 2006, Joachim Buechse wrote: > >> Hi Trent, >> >> What is your general feeling about moving code to Java? The last >> days I have been reading quite a bit of the code and there are >> several things, that might not work as expected. >> >> I'll give you two examples from is_device_locked: >> >> if LOCKDIR == /var/spool/locks the directory /var/spool/lock will >> not be checked. >> LOCKDIR is not checked for lockfiles with unexpected pefixes >> >> While these things have probably never been discovered in >> production, they are still possibly incorrect implementations. If >> it was Java code, I would write some unit tests producing the >> errors that could later be corrected. >> >> PS: One could imagine to actually implement the whole lockfile >> handling in Java using some native routines to get the values >> required (pid, st_dev, st_rdev, ...). > > Hi Joachim > > I like the idea of moving more of the code into java but there are > some things to consider. > > If you break this into multiple JNI calls, the performance will > drop considerably during enumeration of ports. We are looking for > 256 ports per dev type vs (16? in Sun's 2.0 and fewer types). Its > hard to make assumptions. I've seen virtual ports start at /dev/ > foo100 for instance. > > It works out to over 7500 ports on Linux if you enable them all. > We already trim that back by default. See Linux-all-ports in > RXTXCommDriver.java. > > There are also native libraries that rxtx can link to. If you move > too much into Java, linking to 'standard' libraries with distros > will break. "configure --enable-liblock=yes" will not be doable. > This is probably a favorable way with RedHat, Debian, Suse and > others. Thats the right thing to do if there will be rpms, dpkg, .. > > For those reasons, I think it still make sense to keep it to a > minimal ~3 calls to JNI code that we can use for speed and > versatility. lock() isLocked(), unlock() perhaps. When I say > speed, its more about avoiding crossing the JNI layer multiple > times than java vs C performance. With versatility I think liblock > is the right way for most but not all (embeded) linux distros. > > -- > Trent Jarvi > tjarvi at qbang.org > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Mon Mar 20 12:44:47 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 20 Mar 2006 12:44:47 -0700 (MST) Subject: [Rxtx] BUG: Lock file stays even if port opening fails In-Reply-To: <82C19FE7-DDCB-45B6-B2C9-7606B66F0124@buechse.de> References: <82C19FE7-DDCB-45B6-B2C9-7606B66F0124@buechse.de> Message-ID: On Mon, 20 Mar 2006, Joachim Buechse wrote: > Ok, what about providing a default implementation in Java? > > The RXTXCommDriver would call a (native) function useNativeLocking and if > it returns true, call the native functions for lock() isLocked(), > unlock(), else is would use the Java based default implementation. This > could possibly be overriden by a property (again for debugging). > Hi Joachim That would be OK with me. -- Trent Jarvi tjarvi at qbang.org From dmarkman at mac.com Mon Mar 20 22:27:45 2006 From: dmarkman at mac.com (Dmitry Markman) Date: Tue, 21 Mar 2006 00:27:45 -0500 Subject: [Rxtx] binaries request Message-ID: <42702213-C222-4937-A585-7CFB17E47608@mac.com> Hi can somebody send me latest linux and windows binaries, please? or where I can find them (I didn't find them in the latest tareball) I gave up with my cygwin: something wrong I have no idea what java doesn't understand /cygwin/c syntax after I changed makefile it did java part but after that gcc 3.4.4 started to complain I set buffer length to 999 lines but I didn't get beginning of the story something wrong with my 1.4.2_09/include/jni.h gcc doesn't like it anyway I gave up thanks in advance Dmitry Markman -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060320/f8cbc57c/attachment-0037.html From tjarvi at qbang.org Mon Mar 20 22:36:48 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 20 Mar 2006 22:36:48 -0700 (MST) Subject: [Rxtx] binaries request In-Reply-To: <42702213-C222-4937-A585-7CFB17E47608@mac.com> References: <42702213-C222-4937-A585-7CFB17E47608@mac.com> Message-ID: On Tue, 21 Mar 2006, Dmitry Markman wrote: > Hi > can somebody send me latest linux and windows binaries, please? > > or where I can find them (I didn't find them in the latest tareball) > > I gave up with my cygwin: something wrong I have no idea what > java doesn't understand /cygwin/c syntax > after I changed makefile it did java part > but after that gcc 3.4.4 started to complain > I set buffer length to 999 lines but I didn't get beginning of the story > something wrong with my 1.4.2_09/include/jni.h gcc doesn't like it > anyway I gave up > > thanks in advance > Hi Dmitry The bins are here: ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7-bins-r2.zip Here are the files in the zip you want. Jar: rxtx-2.1-7-bins-r2/RXTXcomm.jar Windows: rxtx-2.1-7-bins-r2/Windows/i368-mingw32/rxtxSerial.dll Linux (x86) rxtx-2.1-7-bins-r2/Linux/i686-unknown-linux-gnu/librxtxSerial.so There are others in there including Parallel port support but those are the main ones for testing. -- Trent Jarvi tjarvi at qbang.org From dmarkman at mac.com Mon Mar 20 23:05:59 2006 From: dmarkman at mac.com (Dmitry Markman) Date: Tue, 21 Mar 2006 01:05:59 -0500 Subject: [Rxtx] binaries request In-Reply-To: References: <42702213-C222-4937-A585-7CFB17E47608@mac.com> Message-ID: thank you very much but windows's readme says: rxtxSerial.dll had to be recomopiled to link in missing native methods. should I ignore it? or what? thanks again also I understand that I should use mingw not cygwin I'll try to install mingw On Mar 21, 2006, at 12:36 AM, Trent Jarvi wrote: > On Tue, 21 Mar 2006, Dmitry Markman wrote: > >> Hi >> can somebody send me latest linux and windows binaries, please? >> >> or where I can find them (I didn't find them in the latest tareball) >> >> I gave up with my cygwin: something wrong I have no idea what >> java doesn't understand /cygwin/c syntax >> after I changed makefile it did java part >> but after that gcc 3.4.4 started to complain >> I set buffer length to 999 lines but I didn't get beginning of the >> story >> something wrong with my 1.4.2_09/include/jni.h gcc doesn't like it >> anyway I gave up >> >> thanks in advance >> > > Hi Dmitry > > The bins are here: > > ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7-bins-r2.zip > > Here are the files in the zip you want. > > Jar: > > rxtx-2.1-7-bins-r2/RXTXcomm.jar > > Windows: > > rxtx-2.1-7-bins-r2/Windows/i368-mingw32/rxtxSerial.dll > > Linux (x86) > > rxtx-2.1-7-bins-r2/Linux/i686-unknown-linux-gnu/librxtxSerial.so > > There are others in there including Parallel port support but those > are the main ones for testing. > > -- > Trent Jarvi > tjarvi at qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx Dmitry Markman From tjarvi at qbang.org Mon Mar 20 23:20:33 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 20 Mar 2006 23:20:33 -0700 (MST) Subject: [Rxtx] binaries request In-Reply-To: References: <42702213-C222-4937-A585-7CFB17E47608@mac.com> Message-ID: On Tue, 21 Mar 2006, Dmitry Markman wrote: > thank you very much > > but windows's readme says: > rxtxSerial.dll had to be recomopiled to link in missing native methods. > > should I ignore it? or what? > Hi Dmitry That dll should be OK. r2 is the recompile linked to the missing native method. The readme explains why it was recompiled; fuser.o was not linked into the dll in the first release. -- Trent Jarvi tjarvi at qbang.org From ariantristan at yahoo.com Mon Mar 20 23:55:24 2006 From: ariantristan at yahoo.com (Lambok Sianturi) Date: Mon, 20 Mar 2006 22:55:24 -0800 (PST) Subject: [Rxtx] jvm issue Message-ID: <20060321065524.94779.qmail@web50701.mail.yahoo.com> Hi All, This is my first time to join RxTx mailing list. I thank you all for allowing others to sign in in requests help. I use the latest RxTx lib in Fedora 3 with java version 1.4.2_09 b05. And I got this error: # # An unexpected error has been detected by HotSpot Virtual Machine: # # SIGSEGV (0xb) at pc=0x00bf27f3, pid=2633, tid=3086112448 # # Java VM: Java HotSpot(TM) Client VM (1.4.2_09-b05 mixed mode) # Problematic frame: # C [ld-linux.so.2+0xa7f3] # # An error report file with more information is saved as hs_err_pid2633.log # # If you would like to submit a bug report, please visit: # http://java.sun.com/webapps/bugreport/crash.jsp # ./run.sh: line 3: 2633 Aborted /usr/local/java/bin/java -Djava.library.path=/usr/local/java/jre/lib/ -Djsmsengine.debug=true -classpath jsmsengine.jar:smsgateway.jar:classes12.jar:RXTXcomm.jar:. com.api.sms.SMSServer What is the jvm depedency for the latest library? Can I use 1.4.2_09 b05? Thanks in advance. Arian --------------------------------- Yahoo! Mail Use Photomail to share photos without annoying attachments. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060320/83d58dd7/attachment-0037.html From f.frumento at ngi.it Tue Mar 21 00:21:47 2006 From: f.frumento at ngi.it (Fabio Frumento) Date: Tue, 21 Mar 2006 08:21:47 +0100 Subject: [Rxtx] Javadoc on the go Message-ID: <441FA98B.9050701@ngi.it> Hi Trent, sorry for the big delay but my job is running wild, i was out for some time but now i'm back and ready to continue the javadoc for Rxtx. Did you used the last javadoc patch i sent you ? let me know if i have to send it to you again or not. regards Fabio From lyon at docjava.com Tue Mar 21 00:51:18 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Tue, 21 Mar 2006 02:51:18 -0500 Subject: [Rxtx] lock files Message-ID: Hi All, You know, if the use of lock files were under Java control (rather than a build-time decision), it might enable a more unified binary distro. It might also facilitate quick prototyping of non-lock file approaches to resolving serial port contention issues (i.e., mac-like approaches vs. linux approaches, etc.). I realize that this is a radical overhaul of the lock file policy issue. Also, it may harm performance. On the other hand, our benchmarks on JNI overhead for modern processors indicate performance impact should be minimal. Perhaps it is more of an issue with the toybox systems. Suppose there were a class with a reasonable default...someone might write: SerialPortLockPolicy.setPolicy(SerialPortLockPolicy.UNIX_LOCK_FILE); SerialPortLockPolicy.setPolicy(SerialPortLockPolicy.NO_LOCK_CHECKING); SerialPortLockPolicy.setPolicy(SerialPortLockPolicy.MAC_STYLE); Thus, we could have a run-time reconfiguration of the serial port lock policy. A special NO_LOCK version of the binary would no longer be required. Any thoughts on this? Thanks! - Doug From joachim at buechse.de Tue Mar 21 03:09:09 2006 From: joachim at buechse.de (Joachim Buechse) Date: Tue, 21 Mar 2006 11:09:09 +0100 Subject: [Rxtx] lock files In-Reply-To: References: Message-ID: <8E12916A-1B9A-4FF2-B684-E2D1C794221B@buechse.de> This is pretty much what I thought about when I suggested, that the default behaviour could be overwritten with a property. I am very much in favor of this approach. In particular this allows much easier debugging for PC based java developers. I think big parts of the Java (and maybe some parts of the C code) could use a bit of a structural workover (unit tests, javadoc, synchronization, etc). Maybe there should be a CVS branch for this experimental version. I'd be happy to contribute a first workover for some of the Java code. Designing for testability and implementing a good bunch of unit tests has been a strategy that worked quite well in the Java projects I lead. And it ultimately allows more liberal change permission. Regards, Joachim On 21.03.2006, at 08:51, Dr. Douglas Lyon wrote: > Hi All, > You know, if the use of lock files were > under Java control (rather than a build-time decision), > it might enable a more unified binary distro. It might also > facilitate quick prototyping of non-lock file approaches > to resolving serial port contention issues (i.e., mac-like > approaches vs. linux approaches, etc.). > > I realize that this is a radical overhaul of the lock file policy > issue. Also, it may harm performance. On the other hand, > our benchmarks on JNI overhead for modern processors indicate > performance impact should be minimal. Perhaps it is more of > an issue with the toybox systems. > > Suppose there were a class with a reasonable default...someone > might write: > SerialPortLockPolicy.setPolicy(SerialPortLockPolicy.UNIX_LOCK_FILE); > SerialPortLockPolicy.setPolicy(SerialPortLockPolicy.NO_LOCK_CHECKING); > SerialPortLockPolicy.setPolicy(SerialPortLockPolicy.MAC_STYLE); > > Thus, we could have a run-time reconfiguration of the serial port lock > policy. A special NO_LOCK version of the binary would no longer > be required. > > Any thoughts on this? > > Thanks! > - Doug > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From joachim at buechse.de Tue Mar 21 06:23:08 2006 From: joachim at buechse.de (Joachim Buechse) Date: Tue, 21 Mar 2006 14:23:08 +0100 Subject: [Rxtx] PATCH: use of ioctl(fd, TIOCEXCL) instead of lockfiles Message-ID: <923AE774-EEA2-4911-92D8-32BB27802C8B@buechse.de> Here is the patch for the ioctl(fd, TIOCEXCL). I have verified this only for OSX 10.4.5, hence it is only defined for APPLE. However, it should work at least for Solaris as well. If a process has requested TIOEXCL further open calls by other user processes will fail. The patch also disables uucp style locking for APPLE. Obviously this is discussable. I think it is the way to go, as it eliminates creating the lock directory which doesnt exist on the standard installation and it eliminates messing with the system group definitions (adding users to group uucp). Regarding the possibility of root processes opening a device which is locked - I consider this a feature not a potential problem. It is highly unlikely, that somebody is crazy enough to run a JavaVM as root (unless he has no other means of getting a restricted IP port opened, ie doesnt understand ipfw). Anyway, even if the process runs as root, it fails when calling ioctl(fd, TIOCEXCL). It could however still open the port to listen for RING events. I.e. a fax server which needs to see incoming calls but otherwise doesnt want to block the port. So the only case where the proposed mechanism fails is, if an incorrectly implemented process running as root conflicts with a user process. I think this can be accepted. Regards, Joachim PS: If this patch is generally accepted, the installer and Mac doku should obviously be changed as well. Index: SerialImp.c =================================================================== RCS file: /usr/local/cvsroot/rxtx-devel/src/SerialImp.c,v retrieving revision 1.46.2.187 diff -u -r1.46.2.187 SerialImp.c --- SerialImp.c 29 Jan 2006 22:19:04 -0000 1.46.2.187 +++ SerialImp.c 21 Mar 2006 12:59:16 -0000 @@ -656,6 +656,25 @@ fd=OPEN (filename, O_RDWR | O_NOCTTY | O_NONBLOCK ); } while (fd < 0 && errno==EINTR); +#ifdef OPEN_EXCL + // Note that open() follows POSIX semantics: multiple open() calls to + // the same file will succeed unless the TIOCEXCL ioctl is issued. + // This will prevent additional opens except by root-owned processes. + // See tty(4) ("man 4 tty") and ioctl(2) ("man 2 ioctl") for details. + + if (fd >= 0 && (ioctl(fd, TIOCEXCL) == -1)) + { + sprintf( message, "open: exclusive access denied for % s\n", + filename ); + report( message ); + report_error( message ); + + close(fd); + goto fail; + } +#endif /* OPEN_EXCL */ + + if( configure_port( fd ) ) goto fail; (*env)->ReleaseStringUTFChars( env, jstr, filename ); sprintf( message, "open: fd returned is %i\n", fd ); Index: SerialImp.h =================================================================== RCS file: /usr/local/cvsroot/rxtx-devel/src/SerialImp.h,v retrieving revision 1.11.2.49 diff -u -r1.11.2.49 SerialImp.h --- SerialImp.h 5 Jul 2005 17:47:21 -0000 1.11.2.49 +++ SerialImp.h 21 Mar 2006 12:59:17 -0000 @@ -135,7 +135,8 @@ /*# define LOCKDIR "/var/spool/uucp"*/ # define LOCKDIR "/var/lock" # define LOCKFILEPREFIX "LK." -# define UUCP +/*# define UUCP*/ +# define OPEN_EXCL #endif /* __APPLE__ */ #if defined(__NetBSD__) # define DEVICEDIR "/dev/" From tjarvi at qbang.org Tue Mar 21 10:26:08 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 21 Mar 2006 10:26:08 -0700 (MST) Subject: [Rxtx] Javadoc on the go In-Reply-To: <441FA98B.9050701@ngi.it> References: <441FA98B.9050701@ngi.it> Message-ID: On Tue, 21 Mar 2006, Fabio Frumento wrote: > Hi Trent, > > sorry for the big delay but my job is running wild, i was out for some > time but now i'm back and ready to continue the javadoc for Rxtx. > > Did you used the last javadoc patch i sent you ? let me know if i have to > send it to you again or not. > > regards > > Fabio Hi Fabio The patch is in the rxtx mail-list archives. It will be going in soon. I did not see a time critical portion. I'll probably be going through the list since the last batch of patches this weekend and putting them into CVS. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Tue Mar 21 10:57:18 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 21 Mar 2006 10:57:18 -0700 (MST) Subject: [Rxtx] jvm issue In-Reply-To: <20060321065524.94779.qmail@web50701.mail.yahoo.com> References: <20060321065524.94779.qmail@web50701.mail.yahoo.com> Message-ID: On Mon, 20 Mar 2006, Lambok Sianturi wrote: > Hi All, > This is my first time to join RxTx mailing list. I thank you all for allowing others to sign in in requests help. > I use the latest RxTx lib in Fedora 3 with java version 1.4.2_09 b05. And I got this error: > > # > # An unexpected error has been detected by HotSpot Virtual Machine: > # > # SIGSEGV (0xb) at pc=0x00bf27f3, pid=2633, tid=3086112448 > # > # Java VM: Java HotSpot(TM) Client VM (1.4.2_09-b05 mixed mode) > # Problematic frame: > # C [ld-linux.so.2+0xa7f3] A native library loading error? What happens if you recompile rxtx on your system and install that? This sounds like an ABI problem? rxtx 2.1-7 was compiled with a gcc 2.96 toolchain as I recall. The hope is newer system will be backwards compatible. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Tue Mar 21 11:05:29 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 21 Mar 2006 11:05:29 -0700 (MST) Subject: [Rxtx] PATCH: use of ioctl(fd, TIOCEXCL) instead of lockfiles In-Reply-To: <923AE774-EEA2-4911-92D8-32BB27802C8B@buechse.de> References: <923AE774-EEA2-4911-92D8-32BB27802C8B@buechse.de> Message-ID: On Tue, 21 Mar 2006, Joachim Buechse wrote: > Here is the patch for the ioctl(fd, TIOCEXCL). I have verified this only > for OSX 10.4.5, hence it is only defined for APPLE. However, it should > work at least for Solaris as well. > > If a process has requested TIOEXCL further open calls by other user > processes will fail. > > The patch also disables uucp style locking for APPLE. Obviously this is > discussable. I think it is the way to go, as it eliminates creating the > lock directory which doesnt exist on the standard installation and it > eliminates messing with the system group definitions (adding users to > group uucp). > > Regarding the possibility of root processes opening a device which is > locked - I consider this a feature not a potential problem. It is highly > unlikely, that somebody is crazy enough to run a JavaVM as root (unless > he has no other means of getting a restricted IP port opened, ie doesnt > understand ipfw). Anyway, even if the process runs as root, it fails when > calling ioctl(fd, TIOCEXCL). It could however still open the port to > listen for RING events. I.e. a fax server which needs to see incoming > calls but otherwise doesnt want to block the port. So the only case where > the proposed mechanism fails is, if an incorrectly implemented process > running as root conflicts with a user process. I think this can be > accepted. > > Regards, > Joachim > > PS: If this patch is generally accepted, the installer and Mac doku > should obviously be changed as well. > > > Index: SerialImp.c > =================================================================== > RCS file: /usr/local/cvsroot/rxtx-devel/src/SerialImp.c,v > retrieving revision 1.46.2.187 > diff -u -r1.46.2.187 SerialImp.c > --- SerialImp.c 29 Jan 2006 22:19:04 -0000 1.46.2.187 > +++ SerialImp.c 21 Mar 2006 12:59:16 -0000 > @@ -656,6 +656,25 @@ > fd=OPEN (filename, O_RDWR | O_NOCTTY | O_NONBLOCK ); > } while (fd < 0 && errno==EINTR); > > +#ifdef OPEN_EXCL > + // Note that open() follows POSIX semantics: multiple open() > calls to > + // the same file will succeed unless the TIOCEXCL ioctl is > issued. > + // This will prevent additional opens except by root-owned > processes. > + // See tty(4) ("man 4 tty") and ioctl(2) ("man 2 ioctl") for > details. > + > + if (fd >= 0 && (ioctl(fd, TIOCEXCL) == -1)) > + { > + sprintf( message, "open: exclusive access denied for % > s\n", > + filename ); > + report( message ); > + report_error( message ); > + > + close(fd); > + goto fail; > + } > +#endif /* OPEN_EXCL */ > + > + > if( configure_port( fd ) ) goto fail; > (*env)->ReleaseStringUTFChars( env, jstr, filename ); > sprintf( message, "open: fd returned is %i\n", fd ); > Index: SerialImp.h > =================================================================== > RCS file: /usr/local/cvsroot/rxtx-devel/src/SerialImp.h,v > retrieving revision 1.11.2.49 > diff -u -r1.11.2.49 SerialImp.h > --- SerialImp.h 5 Jul 2005 17:47:21 -0000 1.11.2.49 > +++ SerialImp.h 21 Mar 2006 12:59:17 -0000 > @@ -135,7 +135,8 @@ > /*# define LOCKDIR "/var/spool/uucp"*/ > # define LOCKDIR "/var/lock" > # define LOCKFILEPREFIX "LK." > -# define UUCP > +/*# define UUCP*/ > +# define OPEN_EXCL > #endif /* __APPLE__ */ > #if defined(__NetBSD__) > # define DEVICEDIR "/dev/" > This looks like a good start. What do you think Dmitry? Perhaps all systems with TIOCEXCL defined should use that though. Even if they use lockfiles. It wont hurt anything. That would catch people hacking their own serial apps without checking lockfiles. Its a good idea to avoid C++ style comments in the C portions. Some older systems don't deal with them well. If it's just for Mac OS X, it isn't a big deal. I think it was the Irix compiler that was problematic? -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Tue Mar 21 11:22:05 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 21 Mar 2006 11:22:05 -0700 (MST) Subject: [Rxtx] lock files In-Reply-To: <8E12916A-1B9A-4FF2-B684-E2D1C794221B@buechse.de> References: <8E12916A-1B9A-4FF2-B684-E2D1C794221B@buechse.de> Message-ID: We can try it. Maybe the JNI is much improved. The nice thing about linking into liblock is distros then worry about lockfiles on their systems. This way, we have to deal with any changes that may show up. On Tue, 21 Mar 2006, Joachim Buechse wrote: > This is pretty much what I thought about when I suggested, that the > default behaviour could be overwritten with a property. I am very much in > favor of this approach. In particular this allows much easier debugging > for PC based java developers. > > I think big parts of the Java (and maybe some parts of the C code) could > use a bit of a structural workover (unit tests, javadoc, synchronization, > etc). Maybe there should be a CVS branch for this experimental version. > I'd be happy to contribute a first workover for some of the Java code. > Designing for testability and implementing a good bunch of unit tests has > been a strategy that worked quite well in the Java projects I lead. And > it ultimately allows more liberal change permission. > > Regards, > Joachim > > > On 21.03.2006, at 08:51, Dr. Douglas Lyon wrote: > >> Hi All, >> You know, if the use of lock files were >> under Java control (rather than a build-time decision), >> it might enable a more unified binary distro. It might also >> facilitate quick prototyping of non-lock file approaches >> to resolving serial port contention issues (i.e., mac-like >> approaches vs. linux approaches, etc.). >> >> I realize that this is a radical overhaul of the lock file policy >> issue. Also, it may harm performance. On the other hand, >> our benchmarks on JNI overhead for modern processors indicate >> performance impact should be minimal. Perhaps it is more of >> an issue with the toybox systems. >> >> Suppose there were a class with a reasonable default...someone >> might write: >> SerialPortLockPolicy.setPolicy(SerialPortLockPolicy.UNIX_LOCK_FILE); >> SerialPortLockPolicy.setPolicy(SerialPortLockPolicy.NO_LOCK_CHECKING); >> SerialPortLockPolicy.setPolicy(SerialPortLockPolicy.MAC_STYLE); >> >> Thus, we could have a run-time reconfiguration of the serial port lock >> policy. A special NO_LOCK version of the binary would no longer >> be required. >> >> Any thoughts on this? >> >> Thanks! >> - Doug >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From dmarkman at mac.com Tue Mar 21 16:05:17 2006 From: dmarkman at mac.com (Dmitry Markman) Date: Tue, 21 Mar 2006 18:05:17 -0500 Subject: [Rxtx] PATCH: use of ioctl(fd, TIOCEXCL) instead of lockfiles In-Reply-To: References: <923AE774-EEA2-4911-92D8-32BB27802C8B@buechse.de> Message-ID: <512AC70C-BB86-48F2-A83C-023F35C23BAB@mac.com> I think it's cool, but I'd like to have that property implementation when user can choose between locking mechanism about comments: it's easy to change comments to the C style or we can use extensions of the file to cpp so c++ compiler will be used On Mar 21, 2006, at 1:05 PM, Trent Jarvi wrote: > This looks like a good start. What do you think Dmitry? Perhaps > all systems with TIOCEXCL defined should use that though. Even if > they use lockfiles. It wont hurt anything. That would catch > people hacking their own serial apps without checking lockfiles. > > Its a good idea to avoid C++ style comments in the C portions. > Some older systems don't deal with them well. If it's just for Mac > OS X, it isn't a big deal. I think it was the Irix compiler that > was problematic? Dmitry Markman From dmarkman at mac.com Tue Mar 21 16:13:00 2006 From: dmarkman at mac.com (Dmitry Markman) Date: Tue, 21 Mar 2006 18:13:00 -0500 Subject: [Rxtx] PATCH: use of ioctl(fd, TIOCEXCL) instead of lockfiles In-Reply-To: References: <923AE774-EEA2-4911-92D8-32BB27802C8B@buechse.de> Message-ID: I'd like to add that creating locking folder isn't a big deal we never had a problem related to the lock folders, because we always used installer on mac os x from other hand I'm not very much familiar with iotcl locking approach and I'm not sure it's more efficient Joachim wrote "I think it is the way to go, as it eliminates creating the lock directory which doesnt exist on the standard installation and it eliminates messing with the system group definitions (adding users to group uucp)." but I really didn't have any problem with that 1. doesn't exist on the standard installation there are many-many things that don't exist in the standard installation so I don't think that argument is strong enough 2. messing with the system group definitions I don't think we're messing with the group definition mac os x provides very clear way to set up group's members and together with Greg Guerin AuthKit there is no problem to set those definitions so I don't think that argument is strong either but from other hand using iotcl is more promising and is more elegant On Mar 21, 2006, at 1:05 PM, Trent Jarvi wrote: > > This looks like a good start. What do you think Dmitry? Perhaps > all systems with TIOCEXCL defined should use that though. Even if > they use lockfiles. It wont hurt anything. That would catch > people hacking their own serial apps without checking lockfiles. Dmitry Markman From joachim at buechse.de Wed Mar 22 04:46:45 2006 From: joachim at buechse.de (Joachim Buechse) Date: Wed, 22 Mar 2006 12:46:45 +0100 Subject: [Rxtx] PATCH: use of ioctl(fd, TIOCEXCL) instead of lockfiles In-Reply-To: References: <923AE774-EEA2-4911-92D8-32BB27802C8B@buechse.de> Message-ID: Sorry, I was not very clear with my arguments, so I will try again;-) Please, don't take this as an attack against work that has been done. I think the contributions that have been made in the past were made in a good spirit. But I really believe, that the current solution for OSX has many shortcomings and should be changed as soon as possible. lock files --- The /var/lock folder does not exist on the standard OSX installation, however the standard installation includes several applications that use serial ports (i.e. the FAX capability). This indicates, that the lock folder approach will not work well with system components. Applications for OSX will generally try to live in harmony with system components (except for HP print drivers of course). I think RXTX should follow this approach as well. uucp group --- Accessing serial ports is not an admin privileged operation on OSX. Any user (world) has read/write privileges on /dev/tty*. So the system default is to not enforce any group membership to access these ports. The group uucp however is a system group on all unix systems I know. It exists for certain system processes. A non admin user should in general not be a member of this group. Quite arguably no user should ever be a member of this group. Installer --- My general opinion is, that - no Installer should touch user or group data without warning - no Application Installer should touch groups which are not specific to the very application installed - no Installer should ever add regular users to a system group The current installer injects the installing user in the group uucp without warning about this change and without giving the option to "opt out" of this change. This is a potential security risk (but not currently a real one, as OSX contains no folders belonging to group uucp). The current installer does not work for multi user systems. It puts the installing user in the uucp group. However the installing user is not necessarily the user that will use the application. Putting all users that may use a serial port application in the system group uucp seems like a very invasive approach to me. Besides that, newly created users will not automatically be in the group and hence, serial applications will "break" for new users without obvious reasons. Avoiding the lock files will allow self contained applications (i.e. drag&drop installation). In my eyes this is largely preferable over an installer that requests admin privileges. Adding up all these points indicates very strongly, that the lock-file implementation is not the way to go on OSX. Regards, Joachim On 22.03.2006, at 00:13, Dmitry Markman wrote: > I'd like to add that > > creating locking folder isn't a big deal > we never had a problem related to the lock folders, because we > always used installer on mac os x > from other hand I'm not very much familiar with iotcl locking > approach and I'm not sure it's more efficient > > Joachim wrote "I think it is the way to go, as it eliminates > creating the lock directory which doesnt exist on the standard > installation and it eliminates messing with the system group > definitions (adding users to group uucp)." but I really didn't have > any problem with that > > 1. doesn't exist on the standard installation > there are many-many things that don't exist in the standard > installation so I don't think that argument is strong enough > 2. messing with the system group definitions > I don't think we're messing with the group definition > mac os x provides very clear way to set up group's members and > together with Greg Guerin AuthKit there is no problem to set those > definitions > so I don't think that argument is strong either > but from other hand using iotcl is more promising and is more elegant > > > > On Mar 21, 2006, at 1:05 PM, Trent Jarvi wrote: > >> >> This looks like a good start. What do you think Dmitry? Perhaps >> all systems with TIOCEXCL defined should use that though. Even if >> they use lockfiles. It wont hurt anything. That would catch >> people hacking their own serial apps without checking lockfiles. > > Dmitry Markman > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From dmarkman at mac.com Wed Mar 22 05:27:13 2006 From: dmarkman at mac.com (Dmitry Markman) Date: Wed, 22 Mar 2006 07:27:13 -0500 Subject: [Rxtx] PATCH: use of ioctl(fd, TIOCEXCL) instead of lockfiles In-Reply-To: References: <923AE774-EEA2-4911-92D8-32BB27802C8B@buechse.de> Message-ID: <83440CF3-DCD8-41C1-B941-F227232C27E3@mac.com> thanks for the very good explanation I didn't think that you were attacking any thing, so don't worry I just had feeling, that there were more aesthetic reasons for going to ioctl then real necessity now you explained everything quite well (BTW, asfar as I remember installer asks admin password so it wasn't quiet, but it really doesn't matter now) thanks On Mar 22, 2006, at 6:46 AM, Joachim Buechse wrote: > Sorry, I was not very clear with my arguments, so I will try again;-) > > Please, don't take this as an attack against work that has been > done. I think the contributions that have been made in the past > were made in a good spirit. But I really believe, that the current > solution for OSX has many shortcomings and should be changed as > soon as possible. > > lock files > --- > The /var/lock folder does not exist on the standard OSX > installation, however the standard installation includes several > applications that use serial ports (i.e. the FAX capability). This > indicates, that the lock folder approach will not work well with > system components. Applications for OSX will generally try to live > in harmony with system components (except for HP print drivers of > course). I think RXTX should follow this approach as well. > > uucp group > --- > Accessing serial ports is not an admin privileged operation on OSX. > Any user (world) has read/write privileges on /dev/tty*. So the > system default is to not enforce any group membership to access > these ports. The group uucp however is a system group on all unix > systems I know. It exists for certain system processes. A non admin > user should in general not be a member of this group. Quite > arguably no user should ever be a member of this group. > > Installer > --- > My general opinion is, that > - no Installer should touch user or group data without warning > - no Application Installer should touch groups which are not > specific to the very application installed > - no Installer should ever add regular users to a system group > > The current installer injects the installing user in the group uucp > without warning about this change and without giving the option to > "opt out" of this change. This is a potential security risk (but > not currently a real one, as OSX contains no folders belonging to > group uucp). > > The current installer does not work for multi user systems. It puts > the installing user in the uucp group. However the installing user > is not necessarily the user that will use the application. Putting > all users that may use a serial port application in the system > group uucp seems like a very invasive approach to me. Besides that, > newly created users will not automatically be in the group and > hence, serial applications will "break" for new users without > obvious reasons. > > > Avoiding the lock files will allow self contained applications > (i.e. drag&drop installation). In my eyes this is largely > preferable over an installer that requests admin privileges. Adding > up all these points indicates very strongly, that the lock-file > implementation is not the way to go on OSX. > > Regards, > Joachim > > > On 22.03.2006, at 00:13, Dmitry Markman wrote: > >> I'd like to add that >> >> creating locking folder isn't a big deal >> we never had a problem related to the lock folders, because we >> always used installer on mac os x >> from other hand I'm not very much familiar with iotcl locking >> approach and I'm not sure it's more efficient >> >> Joachim wrote "I think it is the way to go, as it eliminates >> creating the lock directory which doesnt exist on the standard >> installation and it eliminates messing with the system group >> definitions (adding users to group uucp)." but I really didn't >> have any problem with that >> >> 1. doesn't exist on the standard installation >> there are many-many things that don't exist in the standard >> installation so I don't think that argument is strong enough >> 2. messing with the system group definitions >> I don't think we're messing with the group definition >> mac os x provides very clear way to set up group's members and >> together with Greg Guerin AuthKit there is no problem to set those >> definitions >> so I don't think that argument is strong either >> but from other hand using iotcl is more promising and is more elegant >> >> >> >> On Mar 21, 2006, at 1:05 PM, Trent Jarvi wrote: >> >>> >>> This looks like a good start. What do you think Dmitry? Perhaps >>> all systems with TIOCEXCL defined should use that though. Even >>> if they use lockfiles. It wont hurt anything. That would catch >>> people hacking their own serial apps without checking lockfiles. >> >> Dmitry Markman >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx Dmitry Markman From lyon at docjava.com Wed Mar 22 06:12:18 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Wed, 22 Mar 2006 08:12:18 -0500 Subject: [Rxtx] sole of a new design pattern Message-ID: Hi All, I have been thinking about how we design the serial port software. I think we need a new design pattern. For lack of a better term, I shall call it: The Parametric Singleton Design Pattern By Douglas A. Lyon ABSTRACT The goal of the singleton design pattern is to make sure that there is one, and only one, instance of a given class. The goal of the parametric singleton design pattern is to make sure that there is one, and only one, instance of a given class with the given parametric values. We parametric singleton design pattern combines the singleton design pattern with a parameter that enables unique creation of instances of a class. These instances are cached. When a user asks for an instance with these parameters, the cache is checked. If the instance is in the cache, the instance is returned, otherwise it is created, added to the cache and then returned. We apply our parametric singleton design pattern to the retrieval of RMI registries bound to a given port. The goal of our system is to make sure that no two RMI registries are listening to the same socket and to make use of the RMI registries after they have been created. RMI registries are used in distributed computation. Introduction The singleton design pattern is meant to ensure that on a single instance of a class exists. It is also meant to provide a global point of access to it. The intent of the parametric singleton design pattern is to ensure that a class has only one instance for a given set of parameter values. It also provides a global point of access to it. Motivation A system cannot tolerate multiple instances of some classes with identical parameters. For example, you cannot have two instances making use of the same serial port, at the same time. You cannot have two instances that are trying to listen to the same socket connection. You cannot have two instances writing to the same file structure at the same time. As the operating system is often thought of as the arbiter of consumed resources (i.e., tape drives, serial ports, etc.) we frequently leave it to an operating system implementation to resolve these contention issues. Even for similar resources (like serial ports) there are few standards for handling contention. For example, serial ports on Linux are locked using a "/var/lock" file. POSIX, on the other hand, uses ioctl mechanisms to prevent contention. A better solution is to make a class that is responsible for keeping track of the instances created from the class. The class is declared final, so that it cannot be subclassed. The class also has a private constructor, so that other classes cannot instance it. The new design pattern is called the parametric singleton design pattern and it provides a way to access and create instances with given parameters. Applicability Use the Parametric Singleton Design Pattern when: 1. There must be exactly one instance of a class with the given parameters. 2. The instances must be accessible to clients from a well-known access point. Structure Insert UML diagram here. Participants The Parametric Singleton Clients that need instances 1. The Parametric Singleton defines an instance upon request from a client, if, and only if, the instance does not already exist. 2. The Parametric Singleton returns the instance to the client. 3. The Parametric Singleton is responsible for creating unique instances from given parameters. Collaborations Clients obtain a reference to a Parametric Singleton instance only through the parametric singleton design pattern. If the instance is left in an improper state (e.g., the serial port was left open) it is NOT the role of the Parametric Singleton Design Pattern to close the IO port. Nor is it the role of the Parametric Singleton Design Pattern to open the port. That role is delegate to some other part of the system. Further, it is not the role of the Parametric Singleton Design Pattern to check out resources. That is, multiple threads can have multiple references to the same resource at the same time. MUTEX locking is delegated to some other part of the system. Consequences The Parametric Singleton Design Pattern has several benefits: 1. Controlled access to parametrically defined instances. Since the Parametric Singleton class encapsulates its instances, there is control over how and when clients access it. 2. Reduced name space. The Parametric Singleton pattern avoids global variables that store instances created from the same parameter. Implementation Here are implementation issues to consider when using the Parametric Singleton pattern: 1. Unique mapping of parameters. The Parametric Singleton pattern requires that there be a mean to isomorphically map the parameter space into the instance space and back again. 2. Ensure unique instances. The Parametric Singleton pattern makes unique instances from parameters, and it does so only once. 3. Cache instances for fast retrieval. The Parametric Singleton pattern must be able to look up instances, given some set of parameters, and do so from some data structure. That is, there must be enough space to hold references to all the instances the program will need. Also, a mechanism is needed to look up and retrieve the instances quickly enough to satisfy the clients. Sample Code public final class ParametricSingletonRmiRegistry { private static Hashtable registry = new Hashtable(100); // use singleton pattern and??????????????????????????????????????????????? // prevent instantiation of RmiRegistryUtils.?????????????????????????????? private ParametricSingletonRmiRegistry() { } // the only instance of the Registry held by the RmiRegistryUtils?????????? public static void listNames(Integer port) { if (!isInCacheAndRunning(port)) return; Registry r = (Registry) registry.get(port); System.out.println("registry on port: " + port); System.out.println("registry: " + r); System.out.println("names: "); try { print(r.list()); } catch (RemoteException e) { In.message(e); } System.out.println("------------------------"); } /**???????????????????????????????????????????????????????????????????????? * Checks whether a Registry has been started on this host????????????????? * in the specified port.?????????????????????????????????????????????????? * If not, it tries to start one.?????????????????????????????????????????? * when it fails to start a Registry, it exits the program????????????????? * with exit code 1.??????????????????????????????????????????????????????? */ public static void restart(int port) { if (isInCacheAndRunning(port)) return; try { startRegistry(port); } catch (RemoteException e) { In.message(e); } } /**???????????????????????????????????????????????????????????????????????? * @param port????????????????????????????????????????????????????????????? * @return true if registry is in cache and running???????????????????????? */ private static boolean isInCacheAndRunning(Integer port) { if (!isRegistryRunning(port.intValue())) return false; if (!isRegistryInCache(port.intValue())) return false; return true; } /**???????????????????????????????????????????????????????????????????????? * @param port????????????????????????????????????????????????????????????? * @return true if we are able to locate a local registry on port.??????????????????????????????????????????????????????????????????????????? */ private static boolean isRegistryRunning(int port) { try { Registry r = LocateRegistry.getRegistry(port); if (r != null) return true; } catch (RemoteException e) { return false; } return false; } /**???????????????????????????????????????????????????????????????????????? * @param port????????????????????????????????????????????????????????????? * @return return true if registry is in cache????????????????????????????? */ private static boolean isRegistryInCache(int port) { if (registry.get(new Integer(port)) == null) return false; return true; } /**???????????????????????????????????????????????????????????????????????? * Restart the registry, if needed.???????????????????????????????????????? * Return the only instance of the registry for consistent global?????????? * using by making use of the Singleton Design Pattern????????????????????? *????????????????????????????????????????????????????????????????????????? * @return the internally held registry instance.?????????????????????????? */ public static Registry getRegistry(Integer port) { restart(port); return (Registry) registry.get(port); } private static void startRegistry(Integer port) throws RemoteException { Registry r; try { r = LocateRegistry.createRegistry(port.intValue()); registry.put(port, r); //r = new sun.rmi.registry.RegistryImpl???????????????????????????? /// (port.intValue());?????????????????????????????????????? // registry.put(port, r);?????????????????????????????????????????? } catch (Exception e) { //e.printStackTrace();????????????????????????????????????????????? r = LocateRegistry.getRegistry(port.intValue()); registry.put(port, r); } } public static void main(String args[]) throws RemoteException { //restart(port);??????????????????????????????????????????????????????? restart(5001); restart(5002); restart(5002); Registry r = LocateRegistry.getRegistry(5002); System.out.println("registry="+r); } } I would very much like to get your feedback on this new design pattern idea. Thank you for your time. Regards, - Doug From david.garnier at trusted-logic.com Wed Mar 22 07:36:10 2006 From: david.garnier at trusted-logic.com (David Garnier) Date: Wed, 22 Mar 2006 15:36:10 +0100 Subject: [Rxtx] sole of a new design pattern In-Reply-To: References: Message-ID: <442160DA.80107@trusted-logic.com> Hello, > The Parametric Singleton Design Pattern The Singleton is the most abused design pattern ever. Good use-cases for this pattern are extremely rare and mostly confined to problems related to hardware resources, like serial ports. > Applicability > > Use the Parametric Singleton Design Pattern when: > 1. There must be exactly one instance of a class with the given > parameters. OK. As I said above, this case this actually very unusual. The Singleton pattern is mostly used when : > 2. The instances must be accessible to clients from a well-known > access point. Using the singleton pattern in this case is just convenient for the programmer. Problems arises pretty quickly, especially if you attempt to unit-test your classes. 1) If your singleton is stateful, or hold on to stateful objects, it means that two different unit tests are not actually independent. Instead of starting with a brand new environment, the result of a test may be affected by the result of a previous test. This problem also arise when with your class relies on a database. In both cases, the solution is to reset your "unique" resource (Singleton or database) at the beginning of the test, which is a pain. Also, while most projects connect to a single database, projects that allow the use of Singletons usually contain several of thems, and new ones may cropped up unnoticed. You quickly end up with test cases that only pass in a certain order, which is a royal pain. 2) You cannot mockup a singleton. Once everyone calls the SomeSingleton class statically, you can't replace your class by SomeSingletonMockup. Furthermore, even for hardware services, the Singleton pattern does not really prevent concurrent accesses. If you start the same program in two different JVMs, unless they somehow shared the state of their "Singletons" (through lock files for example), the Singleton pattern will not prevent concurrent access. Our application uses RXTX, and we routinely encounter cases where another (native) application has already locked the port. Since we cannot modify the native application to recognize lock files, OS-level control is irreplaceable. > > Consequences > The Parametric Singleton Design Pattern has several benefits: > > 1. Controlled access to parametrically defined instances. Since > the Parametric Singleton class encapsulates its instances, there is > control over how and when clients access it. Not really. Once you've returned the instance to a client, you've lost control over it. The client can to whatever it wants with it. You cannot "recall" the instance or claim it back. > 2. Reduced name space. The Parametric Singleton pattern avoids > global variables that store instances created from the same parameter. Sure, but you don't have to rely on a Singleton for that. Just create a single Factory. > I would very much like to get your feedback on this new design > pattern idea. Well, it's nothing new. Some may say that it is the point of design patterns: formalizes the designs that occur again and again. However, this design is simply a combination of the Singleton and Factory patterns. I did use it in the past, but now I've been exposed to the shortcomings of the Singleton pattern, so I limit myself to Factories. Regards, David From sean_montgomery at baseview.com Wed Mar 22 08:35:28 2006 From: sean_montgomery at baseview.com (Sean Montgomery) Date: Wed, 22 Mar 2006 10:35:28 -0500 Subject: [Rxtx] sole of a new design pattern In-Reply-To: <442160DA.80107@trusted-logic.com> References: <442160DA.80107@trusted-logic.com> Message-ID: <05769CA7-A51B-4CF0-BAA0-E02DD905F5A4@baseview.com> On Mar 22, 2006, at 9:36 AM, David Garnier wrote: > Furthermore, even for hardware services, the Singleton pattern does > not really prevent concurrent > accesses. If you start the same program in two different JVMs, > unless they somehow shared the state > of their "Singletons" (through lock files for example), the > Singleton pattern will not prevent > concurrent access. > Multiple class loaders in a single JVM can be tricky, too. Then there's synchronization, lazy initialization and serialization of singletons to contend with. Bloch's Effective Java covers these, and here's a few articles: http://www.javaworld.com/javaworld/jw-04-2003/jw-0425-designpatterns- p3.html http://java.sun.com/developer/technicalArticles/Programming/singletons/ Just FYI :-) From lyon at docjava.com Wed Mar 22 08:50:48 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Wed, 22 Mar 2006 10:50:48 -0500 Subject: [Rxtx] sole of a new design pattern In-Reply-To: <442160DA.80107@trusted-logic.com> References: <442160DA.80107@trusted-logic.com> Message-ID: Hi All, First, I would like to thank David for his prompt and thoughtful remarks. I had no idea people that feel strongly about a design patterns! Wow! Feedback (particularly critical feedback) is greatly appreciated. Starting at the end, first: >I did use it in >the past, but now I've been exposed to the shortcomings of the >Singleton pattern, so I limit myself to Factories. David, if I understood your comments correctly, you suggested that Factories can be used in leu of the Singleton Design Pattern, or even the Parametric Singleton Design Pattern. As I see in [Gof]: Factory Method: Intent "Define an interface for creating an object, but let subclasses decide which class to instantiate. Factory Method lets a class defer instantiation to subclasses." The Singleton Design Pattern is a concrete class, which is rather different, right? Also, subclasses are not permitted with Singleton, as they are final. Naturally, I could use an abstract factory as a parent for a singleton. I could even design a facade that could be implemented with the singleton....but that is not the intention of the design. Unless you want a mock-up, as discussed, below: More below: >Hello, > >> The Parametric Singleton Design Pattern > >The Singleton is the most abused design pattern ever. Good use-cases >for this pattern are extremely >rare and mostly confined to problems related to hardware resources, >like serial ports. > > >> Applicability >> >> Use the Parametric Singleton Design Pattern when: >> 1. There must be exactly one instance of a class with the given >> parameters. >OK. As I said above, this case this actually very unusual. The >Singleton pattern is mostly used when : >> 2. The instances must be accessible to clients from a well-known >> access point. > >Using the singleton pattern in this case is just convenient for the >programmer. Problems arises >pretty quickly, especially if you attempt to unit-test your classes. > >1) If your singleton is stateful, or hold on to stateful objects, it >means that two different unit >tests are not actually independent. Instead of starting with a brand >new environment, the result of >a test may be affected by the result of a previous test. This >problem also arise when with your >class relies on a database. In both cases, the solution is to reset >your "unique" resource >(Singleton or database) at the beginning of the test, which is a >pain. Also, while most projects >connect to a single database, projects that allow the use of >Singletons usually contain several of >thems, and new ones may cropped up unnoticed. You quickly end up >with test cases that only pass in a >certain order, which is a royal pain. There are basic problems with communicating finite state machines that include reachability and deadlock analysis. These are addressed with petri net analysis and are beyond the scope of the design pattern. As you quite rightly pointed out; the parametric singleton pattern (or the singleton pattern, for that matter) enable multiple threads to gain access to the same instance. The only way that I can see to block others from gaining access to the reference is the synchronize keyword. This is putting a spin-lock (or MUTEX) on the reference. The question of how to unit-test a design pattern like the parametric singleton remains open. Perhaps this is a deficiency. > >2) You cannot mockup a singleton. Once everyone calls the >SomeSingleton class statically, you can't >replace your class by SomeSingletonMockup. Acutally, I am not sure that this is true. If the Singleton implements a Facade interface, it should be possible to make the replacement. Right? > >Furthermore, even for hardware services, the Singleton pattern does >not really prevent concurrent >accesses. If you start the same program in two different JVMs, >unless they somehow shared the state >of their "Singletons" (through lock files for example), the >Singleton pattern will not prevent >concurrent access. Good Point!! You have sharp eyes! The singleton design pattern should/could take responsibility for this. In fact, you may notice that my code does have an implementation (LocateRegistry) that can work across JVM's. The LocateRegistry will even work across the Internet! LocateRegistry takes both a host name and a Port (lock files just don't do this). I did not think to implement this beyond the local machine, but, in its present form, it will work across different processes. > >Our application uses RXTX, and we routinely encounter cases where >another (native) application has >already locked the port. Since we cannot modify the native >application to recognize lock files, >OS-level control is irreplaceable. The singleton design pattern is not meant to replace OS-level control, but to centralize the Java programmers access to it. If lock files, for example, are used for serial ports, the Singleton Design Pattern should be able to work with them. > > >> >> Consequences >> The Parametric Singleton Design Pattern has several benefits: >> > > 1. Controlled access to parametrically defined instances. Since >> the Parametric Singleton class encapsulates its instances, there is >> control over how and when clients access it. > >Not really. Once you've returned the instance to a client, you've >lost control over it. The client >can to whatever it wants with it. You cannot "recall" the instance >or claim it back. Good point, this should read: > 1. Controll when parametrically defined instances are created. Since > > the Parametric Singleton class encapsulates its instances, there is > > control over how and when they are instanced. > >> 2. Reduced name space. The Parametric Singleton pattern avoids >> global variables that store instances created from the same parameter. > >Sure, but you don't have to rely on a Singleton for that. Just >create a single Factory. > > Thank you for your thoughtful and prompt response! Regards, - Doug From dmarkman at mac.com Wed Mar 22 21:21:55 2006 From: dmarkman at mac.com (Dmitry Markman) Date: Wed, 22 Mar 2006 23:21:55 -0500 Subject: [Rxtx] sole of a new design pattern In-Reply-To: <442160DA.80107@trusted-logic.com> References: <442160DA.80107@trusted-logic.com> Message-ID: I don't think I get it On Mar 22, 2006, at 9:36 AM, David Garnier wrote: > Using the singleton pattern in this case is just convenient for the > programmer. Problems arises > pretty quickly, especially if you attempt to unit-test your classes. so you're saying that something isn't so good because you can not test it in the convenient way? if that's true, I'm totally disagree change your test, debug whatever, but if software is efficient at runtime, works fine and only problem is some unit test (which is some kind of framework for testing) then dump that unit test , dump that unit framework and make something appropriate to the software you're testing so if Douglas want to use singletons, what's the problem? and what do you mean by abusing of singleton usage? of course singleton doesn't prevent concurrent access to the resource across the processes unless you're using some OS facility to prevent it, besides singleton as it was introduced is relevant only and only inside of the same process otherwise it's not singleton it's something else (let's say network singleton: so you have remote invocation facility and some factory method that return object created by that facility) I don't have any problem with using any kind of singletons. Parametric Singleton idea (if I understand it right) could be easily implemented in the following way: use a map populate map with instances of some class and key is your parameter (you can use lazy population too) if somebody ask the key check the value if it's null so resource is taken if somebody returns the resource put it back to the map public synchronized static Object getSomeResource(Object parameter); public synchronized static void returnResource(Object parameter); getSomeResource (inside of the same process) could return null in 2 cases 1. if somebody (from other thread for example) already took that resource 2. if OS API said that resource corresponded to that parameter (serial port with parameter = 1 (port #)) is locked and unavailable; I'm not sure that in case of serial ports we even need those Parametric Singletons (unless lock checking is a very expensive operation) just ask the OS about availability of that resource and if it's available give it away and then OS will lock it and therefore in next time somebody ask it just answer that resource is locked and return null for example system has 2 serial ports available so I ask getResource("tty"); or I ask getResource("Bluetooth-Modem"); and if OS is ok you can give tty or Bluetooth-Modem or both no need for any additional pattern I think back to the problem mac os x doesn't recognize locking via files, so it handles locking via some API an instance of the singleton in each process should recognize that resource is locked (by using that API) that's all we don't have to make things more complicate then they are just because there is some nice design pattern or nice unit test framework or whatever keep things simple, make them work fast, don't introduce middle layers unless you have really good reason to do so of course I could be entirely wrong, so sorry about that in advance thanks Dmitry Markman From tjarvi at qbang.org Wed Mar 22 22:31:41 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 22 Mar 2006 22:31:41 -0700 (MST) Subject: [Rxtx] sole of a new design pattern In-Reply-To: References: Message-ID: Hi Doug Interesting reading. So far I'm just reading and thinking. I have one question so far. " Clients obtain a reference to a Parametric Singleton instance only through the parametric singleton design pattern. If the instance is left in an improper state (e.g., the serial port was left open) it is NOT the role of the Parametric Singleton Design Pattern to close the IO port. Nor is it the role of the Parametric Singleton Design Pattern to open the port. That role is delegate to some other part of the system. " So when the clients obtain a reference to the singleton, can they assume the port is there? IE, would it be the singletons role to handle things like USB dongles being removed with event hints comming from the underlying OS. Hardware abstraction layer/HAL on Linux is an example of underlying OS events. I assume that role too is delegated to other parts of the system? -- Trent Jarvi tjarvi at qbang.org From lyon at docjava.com Thu Mar 23 08:10:33 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Thu, 23 Mar 2006 10:10:33 -0500 Subject: [Rxtx] Classes don't need goals, they need roles! In-Reply-To: References: Message-ID: Hi Trent, Yes, I think that the role of the Parametric Singleton Pattern is not to open or close serial ports, nor is it to perform error checking. On the other hand, if you were to combine the role of the Parametric Singleton Pattern with another role (like that of error checking) it might not be amiss. However, I generally caution programmers against adding multiple roles to classes, as this leads to monolithic designs. Thus a different class (NativeLibDetect) could have the role of determining if the native library can be loaded. Another class (SerialPortBean) can have the role of serializing the default state of the serial port, so that it can be recovered, from user preferences, at a later time. The SerialPortDetect could have the role of determining if the serial port is removed (i.e., a USB port was unplugged). My guess is that each class should have a different role in the system, in order to ease maintenance and testing...but I could be wrong about that. Thanks! - Doug >Hi Doug > >Interesting reading. So far I'm just reading and thinking. I have >one question so far. > >" > Clients obtain a reference to a Parametric Singleton instance only >through the parametric singleton design pattern. If the instance is >left in an improper state (e.g., the serial port was left open) it is >NOT the role of the Parametric Singleton Design Pattern to close the >IO port. Nor is it the role of the Parametric Singleton Design Pattern >to >open the port. That role is delegate to some other part of the system. >" > >So when the clients obtain a reference to the singleton, can they >assume the port is there? IE, would it be the singletons role to >handle things like USB dongles being removed with event hints >comming from the underlying OS. Hardware abstraction layer/HAL on >Linux is an example of underlying OS events. > >I assume that role too is delegated to other parts of the system? > >-- >Trent Jarvi >tjarvi at qbang.org >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From maximulo at yahoo.com Fri Mar 24 01:22:38 2006 From: maximulo at yahoo.com (Maximulo Majir) Date: Fri, 24 Mar 2006 00:22:38 -0800 (PST) Subject: [Rxtx] JavaPOS Message-ID: <20060324082238.66371.qmail@web38214.mail.mud.yahoo.com> Hi all! Hello Trent! From what i understand, RXTX or JavaComm APIs were not created solely for JavaPOS. In JavaPOS, we have the virtual method claim() which is separate from open(), but in our RXTX API, claiming is done every call to open(), we cant open the port if its claimed by another application. Would it be alright to suggest or ask to create a new method called claim(..)? Is there such thing as forceclaim() in RXTX? this could be the same as portownership transfer or its equivalent. ForceClaim is in JSR80. Do you have some samples using RXTX as the lower layer for the Device Service Objects in JavaPOS? I have tried it, i just want to compare. Thank you all! maxim __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060324/496adba2/attachment-0037.html From tjarvi at qbang.org Fri Mar 24 11:28:19 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 24 Mar 2006 11:28:19 -0700 (MST) Subject: [Rxtx] Re: RXTX 2.1 Solaris Problems In-Reply-To: <3691.1143210578@www045.gmx.net> References: <3691.1143210578@www045.gmx.net> Message-ID: On Fri, 24 Mar 2006, Andreas Guenther wrote: > Hi all, > > the solaris problem was not the lock file only. > > Ok, I had to create the directory /var/spool/locks myself. > /var/spool/uucp exists. > > But rxtx didn't find any port. > > I compiled the source with my own debug-informations > and I tried to isolate the problem. > > The problem is the testRead-call in SerialImp.c > > JNIEXPORT jboolean JNICALL RXTXCommDriver(testRead)( > > ... > if ( READ( fd, &c, 1 ) < 0 ) > { > if ( errno != EAGAIN ) { > report( "testRead() read failed\n" ); > ret = JNI_FALSE; > } > } > Thanks Andreas I'm packing up to move. I'll be more or less away for a couple weeks here. I'll be checking email but my workstation is going into a box soon. This isn't hard to fix as this port should be enumerated when EWOULDBLOCK is recieved. Thats error is OK for enumeration just as EAGAIN is. I've put the bug into bugzilla so we dont forget to get to it. http://bugzilla.qbang.org/show_bug.cgi?id=42 You can add yourself to the CC list if you wish to test fixes we provide or even put a patch into bugzilla yourself. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Fri Mar 24 11:51:52 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 24 Mar 2006 11:51:52 -0700 (MST) Subject: [Rxtx] JavaPOS In-Reply-To: <20060324082238.66371.qmail@web38214.mail.mud.yahoo.com> References: <20060324082238.66371.qmail@web38214.mail.mud.yahoo.com> Message-ID: On Fri, 24 Mar 2006, Maximulo Majir wrote: > Hi all! Hello Trent! > > > From what i understand, RXTX or JavaComm APIs were not > created solely for JavaPOS. In JavaPOS, we have the virtual method > claim() which is separate from open(), but in our RXTX API, claiming is > done every call to open(), we cant open the port if its claimed by > another application. Would it be alright to suggest or ask to create a > new method called claim(..)? Is there such thing as forceclaim() in > RXTX? this could be the same as portownership transfer or its > equivalent. ForceClaim is in JSR80. > Do you have some samples using RXTX as the lower layer for the Device > Service Objects in JavaPOS? I have tried it, i just want to compare. > maxim Hi Maxim JSR80 is the USB API IBM/Sun put together. The problem is they have a richer kernel/API underneath that can handle such things. With Serial Ports, there isnt anything there other than an ioctl that says don't let anyone touch this and lockfiles that are more of a 'lets be nice.' At times we may be using USB ports but it is through the termios layer with the limitations mentioned. The advantage is that not only USB will work with rxtx. Anything that has a termios layer should work (to the extent that termios layer is complete). I don't know how forceclaim() would help you. Lets say someone has a programmer working on /dev/ttyS0 and you take it. Now you both race each other to read data first. There isn't a mechanism I know of that will solve this problem in termios. The most obvious test being a native app and a Java app trying to take the port. There is the potential of requestion ownership from other Java Applications but the use for that is very rare. Did you have something more specific in mind that I'm missing? I'm not sure that claim() and forceclaim() would help you with rxtx other than maybe locking the port with claim() without opening it. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sat Mar 25 23:42:08 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 25 Mar 2006 23:42:08 -0700 (MST) Subject: [Rxtx] Serial snoop Message-ID: I was reading the Linux kernel mail-list tonight and ran past a thread that mentioned sersnoop. This looks like a handy tool for people dealing with new toys. "a simple command-line tool for linux that echoes bytes to and from any two serial ports, ptys, or network sockets, and prints all traffic to stdout, in hex and ascii." http://www.restivo.org/projects/sersnoop/ It works on Linux only at this time (debian package available). -- Trent Jarvi tjarvi at qbang.org From beat.arnet at gmail.com Sun Mar 26 07:32:35 2006 From: beat.arnet at gmail.com (Beat Arnet) Date: Sun, 26 Mar 2006 09:32:35 -0500 Subject: [Rxtx] Error 0x5 at /home/bob/foo/tar/rxtx-2.1-7/build/../src/termios.c(860): Access is, denied. Message-ID: <4426A603.80508@gmail.com> Dear all, When trying to open the serial port, I sometimes (not always) run into the following exception (when opening the serialPort): Error 0x5 at /home/bob/foo/tar/rxtx-2.1-7/build/../src/termios.c(860): Access is denied. java.lang.UnsatisfiedLinkError: native_psmisc_report_owner at gnu.io.CommPortIdentifier.native_psmisc_report_owner(Native Method) at gnu.io.CommPortIdentifier.open(CommPortIdentifier.java:354) at codeskin.tools.CLLoader.open(CLLoader.java:79) at codeskin.tools.C2000Programmer.run(C2000Programmer.java:220) at java.lang.Thread.run(Unknown Source) Is this the type of error where I should just try to open the port again, or can it be avoided? Regards, Beat From tjarvi at qbang.org Sun Mar 26 11:40:12 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 26 Mar 2006 11:40:12 -0700 (MST) Subject: [Rxtx] Error 0x5 at /home/bob/foo/tar/rxtx-2.1-7/build/../src/termios.c(860): Access is, denied. In-Reply-To: <4426A603.80508@gmail.com> References: <4426A603.80508@gmail.com> Message-ID: On Sun, 26 Mar 2006, Beat Arnet wrote: > Dear all, > > When trying to open the serial port, I sometimes (not always) run into > the following exception (when opening the serialPort): > > Error 0x5 at /home/bob/foo/tar/rxtx-2.1-7/build/../src/termios.c(860): > Access is > denied. > > java.lang.UnsatisfiedLinkError: native_psmisc_report_owner > at gnu.io.CommPortIdentifier.native_psmisc_report_owner(Native > Method) > at gnu.io.CommPortIdentifier.open(CommPortIdentifier.java:354) > at codeskin.tools.CLLoader.open(CLLoader.java:79) > at codeskin.tools.C2000Programmer.run(C2000Programmer.java:220) > at java.lang.Thread.run(Unknown Source) > > Is this the type of error where I should just try to open the port again, > or can it be avoided? > Hi Beat We did a second build of rxtx 2.1-7 to resolve that unsatisfied link error. It should work now. rxtx is trying to tell you it thinks someone else has the serial port open. You can try to open the port again but maybe you already have a copy of the program running when it happens? ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7r2.zip fixed build. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sun Mar 26 11:44:23 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 26 Mar 2006 11:44:23 -0700 (MST) Subject: [Rxtx] RXTX spec file (fwd) Message-ID: This is probably interesting for fedora/suse users. ---------- Forwarded message ---------- Date: Sun, 26 Mar 2006 16:25:45 +0200 To: taj at www.linux.org.uk Subject: RXTX spec file I send you this spec file which allows to create a RPM for Fedora 4, 5 (x86, x86_64) with Java Sun. -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: rxtx.spec Url: http://mailman.qbang.org/pipermail/rxtx/attachments/20060326/6c7b6af6/rxtx-0033.pl From tjarvi at qbang.org Sun Mar 26 23:42:59 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 26 Mar 2006 23:42:59 -0700 (MST) Subject: [Rxtx] Upcomming events. Message-ID: This Wednesday we will be announcing a new "Maintainer" for the rxtx project. The position is more like neutral leader. I wont be going away or doing less. This is just the right thing to do as it turns out the two people with CVS write access will be at the same company. We need a third and we need neutrality. The maintainer will have final say in any conflict and will try to be neutral. It will be open for discussion. Then we will do it :) I'll still do most of the footwork I do now. But. I'm falling behind. I should have gone through the mail-list and posted the next round of changes this weekend. I'm packing to move and its going so so - 13 years of toys collected. I suspect there will be a dead period on my part (a couple weeks) comming up. But if you get it on the mail-list, we will get it in if there are no objections. I may well not be reading the mail-list during this period as I look for a house and many other things. I hope everyone will help out. Thanks -- Trent Jarvi tjarvi at qbang.org From mahmoud_hadad at yahoo.com Sun Mar 26 07:31:19 2006 From: mahmoud_hadad at yahoo.com (ronan nick) Date: Sun, 26 Mar 2006 06:31:19 -0800 (PST) Subject: [Rxtx] a question about the COMM API Message-ID: <20060326143119.54919.qmail@web60014.mail.yahoo.com> hi, i was intrested in knowing how i can communicate with my internal modem using java? for example if i want to make a phone dialer application or a caller id application where should i be looking at? and as i understood the COMM API is for devices that is attached to the computer through serial ports. --------------------------------- New Yahoo! Messenger with Voice. Call regular phones from your PC and save big. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060326/ce8329f0/attachment-0035.html From dmarkman at mac.com Mon Mar 20 00:20:43 2006 From: dmarkman at mac.com (Dmitry Markman) Date: Mon, 20 Mar 2006 02:20:43 -0500 Subject: [Rxtx] Mac OS X RXTX java installer In-Reply-To: References: <07D0DE29-BA32-4CFE-B036-66BC6423D385@buechse.de> <441AE3E0.2030503@willicon.de> <12531986.1142622114996.JavaMail.dmarkman@mac.com> <441B2674.9010409@willicon.de> <13577405.1142634732776.JavaMail.dmarkman@mac.com> <441B4182.8010407@willicon.de> <92CD0D6C-5BE8-426E-A46D-99452059FF49@mac.com> <441BBB2D.8030305@willicon.de> <441C4088.5090905@willicon.de> Message-ID: <64BC1E23-FDDE-4CE6-8863-CFC881CBC224@mac.com> Hi all I put RXTX installer that will install everything (and will create / var/lock if necessary and add user to the uucp group) for mac os x from Java into the rxtx's CVS repository it could be easily modified to install files for any platform it uses Greg Guerin's AuthKit for authentication and authorization Greg released that kit under artistic license, so Trent, please take a look we, probably, can negotiate license with Greg if it's necessary Greg's AuthKit could be downloaded from http://www.amug.org/~glguerin/ sw/#authkit Michael Hall (mikehall at spacestar dot net) had a suggestion to make implementation of the jaas LoginModule based on Greg's AuthKit (his modification of the Greg's AuthKit could be found at http:// www.spacestar.net/users/mikehall/authkit.dmg) but Michael's AuthKitLoginModule does only half a job: it does authenticate but it can not run any external unix process in privileged mode (at least I wasn't able to do so) possible explanation could be found in conversation between Greg and Michael at Apple's java-dev list (look for archives) so I didn't use jaas API for rxtxinstaller I created folder MacOSX in the contrib folder comment 1. if you want to run that installer as standalone application all you need that RXTXInstaller.jar 2. if you want to use webstart you have to add Greg's libAuthKit.jnilib to the mac os x's resources in theory RXTXInstaller.jar doesn't need it, but there is a problem with loading libAuthKit.jnilib from webstart authkit uses loadLibrary method to load library and it failed (from webstart) for standalone application I extract libAuthKit.jnilib from the RXTXInstaller.jar and put it into the /Library/Java/Extensions or ~/Library/Java/Extensions folder that file will be deleted after installer quit unfortunately I didn't have time to put documentation there but it is mostly self-explanatory I took installer code from my gl4java installer that I did about 3 years ago (with small modifications) it would be very nice if Apple will release LoginModule that really will do the job (com.apple.security.auth.module package????? ) (UnixLoginModule is pretty useless) From lyon at docjava.com Mon Mar 20 06:34:39 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Mon, 20 Mar 2006 08:34:39 -0500 Subject: [Rxtx] Mac OS X RXTX java installer In-Reply-To: <64BC1E23-FDDE-4CE6-8863-CFC881CBC224@mac.com> References: <07D0DE29-BA32-4CFE-B036-66BC6423D385@buechse.de> <441AE3E0.2030503@willicon.de> <12531986.1142622114996.JavaMail.dmarkman@mac.com> <441B2674.9010409@willicon.de> <13577405.1142634732776.JavaMail.dmarkman@mac.com> <441B4182.8010407@willicon.de> <92CD0D6C-5BE8-426E-A46D-99452059FF49@mac.com> <441BBB2D.8030305@willicon.de> <441C4088.5090905@willicon.de> <64BC1E23-FDDE-4CE6-8863-CFC881CBC224@mac.com> Message-ID: Hi Dimitry, This sounds like great work. Just a couple of questions; After the check out of the CVS files, using: setenv CVSROOT :pserver:anonymous at cvs.milestonesolutions.com:/usr/local/cvsroot 53 8:28 setenv PASSWORD mousy 54 8:29 cvs login 55 8:29 cvs checkout rxtx-devel I cd'd over to: rxtx-devel/MACOSX_IDE And found: CVS/ CW/ ForPackageMaker/ PB/ Where is the installer? Thanks! - Doug From tjarvi at qbang.org Mon Mar 20 06:39:37 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 20 Mar 2006 06:39:37 -0700 (MST) Subject: [Rxtx] Mac OS X RXTX java installer In-Reply-To: References: <07D0DE29-BA32-4CFE-B036-66BC6423D385@buechse.de> <441AE3E0.2030503@willicon.de> <12531986.1142622114996.JavaMail.dmarkman@mac.com> <441B2674.9010409@willicon.de> <13577405.1142634732776.JavaMail.dmarkman@mac.com> <441B4182.8010407@willicon.de> <92CD0D6C-5BE8-426E-A46D-99452059FF49@mac.com> <441BBB2D.8030305@willicon.de> <441C4088.5090905@willicon.de> <64BC1E23-FDDE-4CE6-8863-CFC881CBC224@mac.com> Message-ID: On Mon, 20 Mar 2006, Dr. Douglas Lyon wrote: > Hi Dimitry, > This sounds like great work. Just a couple of questions; > After the check out of the CVS files, using: > setenv CVSROOT > :pserver:anonymous at cvs.milestonesolutions.com:/usr/local/cvsroot > 53 8:28 setenv PASSWORD mousy > 54 8:29 cvs login > 55 8:29 cvs checkout rxtx-devel Hi Doug You want "cvs checkout -r commapi-0-0-1 rxtx-devel" to get RXTX 2.1 The default branch is rxtx 2.0 which isn't very active right now. -- Trent Jarvi tjarvi at qbang.org From lyon at docjava.com Mon Mar 20 07:05:44 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Mon, 20 Mar 2006 09:05:44 -0500 Subject: [Rxtx] Mac OS X RXTX java installer In-Reply-To: References: <07D0DE29-BA32-4CFE-B036-66BC6423D385@buechse.de> <441AE3E0.2030503@willicon.de> <12531986.1142622114996.JavaMail.dmarkman@mac.com> <441B2674.9010409@willicon.de> <13577405.1142634732776.JavaMail.dmarkman@mac.com> <441B4182.8010407@willicon.de> <92CD0D6C-5BE8-426E-A46D-99452059FF49@mac.com> <441BBB2D.8030305@willicon.de> <441C4088.5090905@willicon.de> <64BC1E23-FDDE-4CE6-8863-CFC881CBC224@mac.com> Message-ID: Hi Trent, Thanks for the info on the CVS checkout procedure. I did that and am still not sure where the installer is. Here is what I have: cd MACOSX_IDE/ p4.docjava.com{lyon}121: ls CVS/ ForPackageMaker/ PB/ p4.docjava.com{lyon}122: find . | more . ./ForPackageMaker ./ForPackageMaker/RXTX.pkg.sit.hqx ./ForPackageMaker/Resources ./ForPackageMaker/Resources/ReadMe.rtf ./ForPackageMaker/Resources/Welcome.rtf ./ForPackageMaker/Resources/CVS ./ForPackageMaker/Resources/CVS/Entries ./ForPackageMaker/Resources/CVS/Repository ./ForPackageMaker/Resources/CVS/Tag ./ForPackageMaker/Resources/CVS/Root ./ForPackageMaker/Resources/preinstall ./ForPackageMaker/Resources/License.rtf ./ForPackageMaker/Resources/preupgrade ./ForPackageMaker/RXTX.pmsp ./ForPackageMaker/CVS ./ForPackageMaker/CVS/Entries ./ForPackageMaker/CVS/Repository ./ForPackageMaker/CVS/Entries.Log ./ForPackageMaker/CVS/Tag ./ForPackageMaker/CVS/Root ./ForPackageMaker/RXTX_Tiger.pkg.sitx.hqx ./ForPackageMaker/RXTX_Jag.pkg.sit.hqx ./ForPackageMaker/Install ./ForPackageMaker/Install/CVS ./ForPackageMaker/Install/CVS/Entries ./ForPackageMaker/Install/CVS/Repository ./ForPackageMaker/Install/CVS/Tag ./ForPackageMaker/Install/CVS/Root ./ForPackageMaker/Install/Library ./ForPackageMaker/Install/Library/CVS ./ForPackageMaker/Install/Library/CVS/Entries ./ForPackageMaker/Install/Library/CVS/Repository ./ForPackageMaker/Install/Library/CVS/Tag ./ForPackageMaker/Install/Library/CVS/Root ./ForPackageMaker/Install/Library/Java ./ForPackageMaker/Install/Library/Java/Extensions ./ForPackageMaker/Install/Library/Java/Extensions/RXTXcomm.jar ./ForPackageMaker/Install/Library/Java/Extensions/CVS ./ForPackageMaker/Install/Library/Java/Extensions/CVS/Entries ./ForPackageMaker/Install/Library/Java/Extensions/CVS/Repository ./ForPackageMaker/Install/Library/Java/Extensions/CVS/Tag ./ForPackageMaker/Install/Library/Java/Extensions/CVS/Root ./ForPackageMaker/Install/Library/Java/Extensions/librxtxSerial.jnilib ./ForPackageMaker/Install/Library/Java/CVS ./ForPackageMaker/Install/Library/Java/CVS/Entries ./ForPackageMaker/Install/Library/Java/CVS/Repository ./ForPackageMaker/Install/Library/Java/CVS/Entries.Log ./ForPackageMaker/Install/Library/Java/CVS/Tag ./ForPackageMaker/Install/Library/Java/CVS/Root ./ForPackageMaker/RXTX_Tiger.pmproj.sitx.hqx ./CVS ./CVS/Entries ./CVS/Repository ./CVS/Entries.Log ./CVS/Tag ./CVS/Root ./PB ./PB/LibSerialUniversal.xcodeproj.sitx.hqx ./PB/CVS ./PB/CVS/Entries ./PB/CVS/Repository ./PB/CVS/Entries.Log ./PB/CVS/Tag ./PB/CVS/Root ./PB/LibSerial.pbproj.sit.hqx ./PB/startpoint.c ./PB/config.h What is the procedure to run this installer? Do we need a README in: /rxtx-devel/MACOSX_IDE Here is what we have: CVS/ ForPackageMaker/ PB/ Thanks! - DL >On Mon, 20 Mar 2006, Dr. Douglas Lyon wrote: > >>Hi Dimitry, >>This sounds like great work. Just a couple of questions; >>After the check out of the CVS files, using: >>setenv CVSROOT >>:pserver:anonymous at cvs.milestonesolutions.com:/usr/local/cvsroot >> 53 8:28 setenv PASSWORD mousy >> 54 8:29 cvs login >> 55 8:29 cvs checkout rxtx-devel > >Hi Doug > >You want "cvs checkout -r commapi-0-0-1 rxtx-devel" to get RXTX 2.1 >The default branch is rxtx 2.0 which isn't very active right now. > >-- >Trent Jarvi >tjarvi at qbang.org From tjarvi at qbang.org Mon Mar 20 07:25:30 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 20 Mar 2006 07:25:30 -0700 (MST) Subject: [Rxtx] Mac OS X RXTX java installer In-Reply-To: References: <07D0DE29-BA32-4CFE-B036-66BC6423D385@buechse.de> <441AE3E0.2030503@willicon.de> <12531986.1142622114996.JavaMail.dmarkman@mac.com> <441B2674.9010409@willicon.de> <13577405.1142634732776.JavaMail.dmarkman@mac.com> <441B4182.8010407@willicon.de> <92CD0D6C-5BE8-426E-A46D-99452059FF49@mac.com> <441BBB2D.8030305@willicon.de> <441C4088.5090905@willicon.de> <64BC1E23-FDDE-4CE6-8863-CFC881CBC224@mac.com> Message-ID: On Mon, 20 Mar 2006, Dr. Douglas Lyon wrote: > Hi Trent, > Thanks for the info on the CVS checkout procedure. > I did that and am still not sure where the installer is. Hi Doug It does look like it was not cvs committed. There is no rxtx-devel/contrib/MacOSX directory in there at the moment. It was mentioned that it was put under contrib. -- Trent Jarvi tjarvi at qbang.org From dmarkman at mac.com Mon Mar 20 07:29:56 2006 From: dmarkman at mac.com (Dmitry Markman) Date: Mon, 20 Mar 2006 09:29:56 -0500 Subject: [Rxtx] Mac OS X RXTX java installer In-Reply-To: References: <07D0DE29-BA32-4CFE-B036-66BC6423D385@buechse.de> <441AE3E0.2030503@willicon.de> <12531986.1142622114996.JavaMail.dmarkman@mac.com> <441B2674.9010409@willicon.de> <13577405.1142634732776.JavaMail.dmarkman@mac.com> <441B4182.8010407@willicon.de> <92CD0D6C-5BE8-426E-A46D-99452059FF49@mac.com> <441BBB2D.8030305@willicon.de> <441C4088.5090905@willicon.de> <64BC1E23-FDDE-4CE6-8863-CFC881CBC224@mac.com> Message-ID: <6054EB4E-F7E0-4A9C-BDDA-D582D6D8826F@mac.com> you can find it in the rxtx-devel/contrib folder On Mar 20, 2006, at 9:05 AM, Dr. Douglas Lyon wrote: > Hi Trent, > Thanks for the info on the CVS checkout procedure. > I did that and am still not sure where the installer is. > Here is what I have: > cd MACOSX_IDE/ > p4.docjava.com{lyon}121: ls > CVS/ ForPackageMaker/ PB/ > p4.docjava.com{lyon}122: find . | more > . > ./ForPackageMaker > ./ForPackageMaker/RXTX.pkg.sit.hqx > ./ForPackageMaker/Resources > ./ForPackageMaker/Resources/ReadMe.rtf > ./ForPackageMaker/Resources/Welcome.rtf > ./ForPackageMaker/Resources/CVS > ./ForPackageMaker/Resources/CVS/Entries > ./ForPackageMaker/Resources/CVS/Repository > ./ForPackageMaker/Resources/CVS/Tag > ./ForPackageMaker/Resources/CVS/Root > ./ForPackageMaker/Resources/preinstall > ./ForPackageMaker/Resources/License.rtf > ./ForPackageMaker/Resources/preupgrade > ./ForPackageMaker/RXTX.pmsp > ./ForPackageMaker/CVS > ./ForPackageMaker/CVS/Entries > ./ForPackageMaker/CVS/Repository > ./ForPackageMaker/CVS/Entries.Log > ./ForPackageMaker/CVS/Tag > ./ForPackageMaker/CVS/Root > ./ForPackageMaker/RXTX_Tiger.pkg.sitx.hqx > ./ForPackageMaker/RXTX_Jag.pkg.sit.hqx > ./ForPackageMaker/Install > ./ForPackageMaker/Install/CVS > ./ForPackageMaker/Install/CVS/Entries > ./ForPackageMaker/Install/CVS/Repository > ./ForPackageMaker/Install/CVS/Tag > ./ForPackageMaker/Install/CVS/Root > ./ForPackageMaker/Install/Library > ./ForPackageMaker/Install/Library/CVS > ./ForPackageMaker/Install/Library/CVS/Entries > ./ForPackageMaker/Install/Library/CVS/Repository > ./ForPackageMaker/Install/Library/CVS/Tag > ./ForPackageMaker/Install/Library/CVS/Root > ./ForPackageMaker/Install/Library/Java > ./ForPackageMaker/Install/Library/Java/Extensions > ./ForPackageMaker/Install/Library/Java/Extensions/RXTXcomm.jar > ./ForPackageMaker/Install/Library/Java/Extensions/CVS > ./ForPackageMaker/Install/Library/Java/Extensions/CVS/Entries > ./ForPackageMaker/Install/Library/Java/Extensions/CVS/Repository > ./ForPackageMaker/Install/Library/Java/Extensions/CVS/Tag > ./ForPackageMaker/Install/Library/Java/Extensions/CVS/Root > ./ForPackageMaker/Install/Library/Java/Extensions/librxtxSerial.jnilib > ./ForPackageMaker/Install/Library/Java/CVS > ./ForPackageMaker/Install/Library/Java/CVS/Entries > ./ForPackageMaker/Install/Library/Java/CVS/Repository > ./ForPackageMaker/Install/Library/Java/CVS/Entries.Log > ./ForPackageMaker/Install/Library/Java/CVS/Tag > ./ForPackageMaker/Install/Library/Java/CVS/Root > ./ForPackageMaker/RXTX_Tiger.pmproj.sitx.hqx > ./CVS > ./CVS/Entries > ./CVS/Repository > ./CVS/Entries.Log > ./CVS/Tag > ./CVS/Root > ./PB > ./PB/LibSerialUniversal.xcodeproj.sitx.hqx > ./PB/CVS > ./PB/CVS/Entries > ./PB/CVS/Repository > ./PB/CVS/Entries.Log > ./PB/CVS/Tag > ./PB/CVS/Root > ./PB/LibSerial.pbproj.sit.hqx > ./PB/startpoint.c > ./PB/config.h > > What is the procedure to run this installer? > Do we need a README in: > /rxtx-devel/MACOSX_IDE > Here is what we have: > CVS/ ForPackageMaker/ PB/ > > > Thanks! > - DL > >> On Mon, 20 Mar 2006, Dr. Douglas Lyon wrote: >> >>> Hi Dimitry, >>> This sounds like great work. Just a couple of questions; >>> After the check out of the CVS files, using: >>> setenv CVSROOT :pserver:anonymous at cvs.milestonesolutions.com:/usr/ >>> local/cvsroot >>> 53 8:28 setenv PASSWORD mousy >>> 54 8:29 cvs login >>> 55 8:29 cvs checkout rxtx-devel >> >> Hi Doug >> >> You want "cvs checkout -r commapi-0-0-1 rxtx-devel" to get RXTX 2.1 >> The default branch is rxtx 2.0 which isn't very active right now. >> >> -- >> Trent Jarvi >> tjarvi at qbang.org > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx Dmitry Markman From mikehall at spacestar.net Mon Mar 20 05:25:25 2006 From: mikehall at spacestar.net (Michael Hall) Date: Mon, 20 Mar 2006 06:25:25 -0600 Subject: [Rxtx] Re: Mac OS X RXTX java installer In-Reply-To: <64BC1E23-FDDE-4CE6-8863-CFC881CBC224@mac.com> References: <07D0DE29-BA32-4CFE-B036-66BC6423D385@buechse.de> <441AE3E0.2030503@willicon.de> <12531986.1142622114996.JavaMail.dmarkman@mac.com> <441B2674.9010409@willicon.de> <13577405.1142634732776.JavaMail.dmarkman@mac.com> <441B4182.8010407@willicon.de> <92CD0D6C-5BE8-426E-A46D-99452059FF49@mac.com> <441BBB2D.8030305@willicon.de> <441C4088.5090905@willicon.de> <64BC1E23-FDDE-4CE6-8863-CFC881CBC224@mac.com> Message-ID: <247EB61F-5CD1-4132-89A2-FC105B6CF9A5@spacestar.net> On Mar 20, 2006, at 1:20 AM, Dmitry Markman wrote: > > Michael Hall (mikehall at spacestar dot net) had a suggestion to > make implementation of the jaas LoginModule > based on Greg's AuthKit > (his modification of the Greg's AuthKit could be found at http:// > www.spacestar.net/users/mikehall/authkit.dmg) > but Michael's AuthKitLoginModule does only half a job: > it does authenticate > but it can not run any external unix process in privileged mode (at > least I wasn't able to do so) If you got it working directly with Greg's the point is moot. But to clarify it anyhow. The login module does not allow you to do anything anything privileged on return as was explained by Greg. You need to work with a separate privileged process using the execPrivileged method of his API. I assume you did something similar although I haven't looked at how you are using it yet. I allowed instead for a action to be performed at the same time you login/authenticate,this... System.setProperty("authkit.action","/usr/bin/id"); just before this... lc.login(); To clarify, safely ignored as you are already complete. Mike Hall mikehall at spacestar dot net http://www.spacestar.net/users/mikehall http://sourceforge.net/projects/macnative -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2427 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20060320/f6e18202/smime-0038.bin From dmarkman at mac.com Mon Mar 20 07:36:47 2006 From: dmarkman at mac.com (Dmitry Markman) Date: Mon, 20 Mar 2006 09:36:47 -0500 Subject: [Rxtx] Re: Mac OS X RXTX java installer In-Reply-To: <247EB61F-5CD1-4132-89A2-FC105B6CF9A5@spacestar.net> References: <07D0DE29-BA32-4CFE-B036-66BC6423D385@buechse.de> <441AE3E0.2030503@willicon.de> <12531986.1142622114996.JavaMail.dmarkman@mac.com> <441B2674.9010409@willicon.de> <13577405.1142634732776.JavaMail.dmarkman@mac.com> <441B4182.8010407@willicon.de> <92CD0D6C-5BE8-426E-A46D-99452059FF49@mac.com> <441BBB2D.8030305@willicon.de> <441C4088.5090905@willicon.de> <64BC1E23-FDDE-4CE6-8863-CFC881CBC224@mac.com> <247EB61F-5CD1-4132-89A2-FC105B6CF9A5@spacestar.net> Message-ID: Hi, Michael all I have to do is to run some shell script I tried to use your action mechanism and it worked great so I just System.setProperty ("authkit.action","" ) and after that I even don't need to run anything like subject.doAs.... but after few thoughts I choose to use plain Greg's approach, because in that case I don't have to deal with various java's configurations files and therefore to use 2-3 -D parameters in the java command line especially it's useful for java web start (it's so fragile :-( ) thanks for the great job On Mar 20, 2006, at 7:25 AM, Michael Hall wrote: > > On Mar 20, 2006, at 1:20 AM, Dmitry Markman wrote: >> >> Michael Hall (mikehall at spacestar dot net) had a suggestion to >> make implementation of the jaas LoginModule >> based on Greg's AuthKit >> (his modification of the Greg's AuthKit could be found at http:// >> www.spacestar.net/users/mikehall/authkit.dmg) >> but Michael's AuthKitLoginModule does only half a job: >> it does authenticate >> but it can not run any external unix process in privileged mode >> (at least I wasn't able to do so) > > If you got it working directly with Greg's the point is moot. > > But to clarify it anyhow. > The login module does not allow you to do anything anything > privileged on return as was explained by Greg. You need to work > with a separate privileged process using the execPrivileged method > of his API. I assume you did something similar although I haven't > looked at how you are using it yet. > I allowed instead for a action to be performed at the same time you > login/authenticate,this... > System.setProperty("authkit.action","/usr/bin/id"); > just before this... > lc.login(); > To clarify, safely ignored as you are already complete. > > Mike Hall mikehall at spacestar dot net > http://www.spacestar.net/users/mikehall > http://sourceforge.net/projects/macnative > > > Dmitry Markman From dmarkman at mac.com Mon Mar 20 07:44:45 2006 From: dmarkman at mac.com (Dmitry Markman) Date: Mon, 20 Mar 2006 09:44:45 -0500 Subject: [Rxtx] Mac OS X RXTX java installer In-Reply-To: References: <07D0DE29-BA32-4CFE-B036-66BC6423D385@buechse.de> <441AE3E0.2030503@willicon.de> <12531986.1142622114996.JavaMail.dmarkman@mac.com> <441B2674.9010409@willicon.de> <13577405.1142634732776.JavaMail.dmarkman@mac.com> <441B4182.8010407@willicon.de> <92CD0D6C-5BE8-426E-A46D-99452059FF49@mac.com> <441BBB2D.8030305@willicon.de> <441C4088.5090905@willicon.de> <64BC1E23-FDDE-4CE6-8863-CFC881CBC224@mac.com> Message-ID: it's in the commapi-0-0-1 branch I tested it right now: cvs co -r commapi-0-0-1 rxtx-devel and I got everything On Mar 20, 2006, at 9:25 AM, Trent Jarvi wrote: > On Mon, 20 Mar 2006, Dr. Douglas Lyon wrote: > >> Hi Trent, >> Thanks for the info on the CVS checkout procedure. >> I did that and am still not sure where the installer is. > > Hi Doug > > It does look like it was not cvs committed. There is no rxtx-devel/ > contrib/MacOSX directory in there at the moment. It was mentioned > that it was put under contrib. > > -- > Trent Jarvi > tjarvi at qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx Dmitry Markman From tjarvi at qbang.org Mon Mar 20 07:52:57 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 20 Mar 2006 07:52:57 -0700 (MST) Subject: [Rxtx] Mac OS X RXTX java installer In-Reply-To: References: <07D0DE29-BA32-4CFE-B036-66BC6423D385@buechse.de> <441AE3E0.2030503@willicon.de> <12531986.1142622114996.JavaMail.dmarkman@mac.com> <441B2674.9010409@willicon.de> <13577405.1142634732776.JavaMail.dmarkman@mac.com> <441B4182.8010407@willicon.de> <92CD0D6C-5BE8-426E-A46D-99452059FF49@mac.com> <441BBB2D.8030305@willicon.de> <441C4088.5090905@willicon.de> <64BC1E23-FDDE-4CE6-8863-CFC881CBC224@mac.com> Message-ID: On Mon, 20 Mar 2006, Dmitry Markman wrote: > it's in the commapi-0-0-1 branch > > I tested it right now: > cvs co -r commapi-0-0-1 rxtx-devel > > and I got everything > A fresh checkout worked. Here is a copy of the tree (just the installer bits) ftp://ftp.qbang.org/pub/rxtx/MacOSX-installer.zip -- Trent Jarvi tjarvi at qbang.org From lyon at docjava.com Mon Mar 20 08:08:26 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Mon, 20 Mar 2006 10:08:26 -0500 Subject: [Rxtx] Mac OS X RXTX java installer In-Reply-To: References: <07D0DE29-BA32-4CFE-B036-66BC6423D385@buechse.de> <441AE3E0.2030503@willicon.de> <12531986.1142622114996.JavaMail.dmarkman@mac.com> <441B2674.9010409@willicon.de> <13577405.1142634732776.JavaMail.dmarkman@mac.com> <441B4182.8010407@willicon.de> <92CD0D6C-5BE8-426E-A46D-99452059FF49@mac.com> <441BBB2D.8030305@willicon.de> <441C4088.5090905@willicon.de> <64BC1E23-FDDE-4CE6-8863-CFC881CBC224@mac.com> Message-ID: Hi All, Is the Auth package able to work properly on non Mac OS's? It was not clear from the doc or download. Thanks! - Doug From dmarkman at mac.com Mon Mar 20 08:15:22 2006 From: dmarkman at mac.com (Dmitry Markman) Date: Mon, 20 Mar 2006 10:15:22 -0500 Subject: [Rxtx] Mac OS X RXTX java installer In-Reply-To: References: <07D0DE29-BA32-4CFE-B036-66BC6423D385@buechse.de> <441AE3E0.2030503@willicon.de> <12531986.1142622114996.JavaMail.dmarkman@mac.com> <441B2674.9010409@willicon.de> <13577405.1142634732776.JavaMail.dmarkman@mac.com> <441B4182.8010407@willicon.de> <92CD0D6C-5BE8-426E-A46D-99452059FF49@mac.com> <441BBB2D.8030305@willicon.de> <441C4088.5090905@willicon.de> <64BC1E23-FDDE-4CE6-8863-CFC881CBC224@mac.com> Message-ID: <217312D8-CCCA-4859-ABA6-32DF1CC817B9@mac.com> thanks Trent, for putting it on ftp server On Mar 20, 2006, at 9:52 AM, Trent Jarvi wrote: > A fresh checkout worked. Here is a copy of the tree (just the > installer bits) > > ftp://ftp.qbang.org/pub/rxtx/MacOSX-installer.zip > Dmitry Markman From dmarkman at mac.com Mon Mar 20 09:14:03 2006 From: dmarkman at mac.com (Dmitry Markman) Date: Mon, 20 Mar 2006 11:14:03 -0500 Subject: [Rxtx] Mac OS X RXTX java installer In-Reply-To: References: <07D0DE29-BA32-4CFE-B036-66BC6423D385@buechse.de> <441AE3E0.2030503@willicon.de> <12531986.1142622114996.JavaMail.dmarkman@mac.com> <441B2674.9010409@willicon.de> <13577405.1142634732776.JavaMail.dmarkman@mac.com> <441B4182.8010407@willicon.de> <92CD0D6C-5BE8-426E-A46D-99452059FF49@mac.com> <441BBB2D.8030305@willicon.de> <441C4088.5090905@willicon.de> <64BC1E23-FDDE-4CE6-8863-CFC881CBC224@mac.com> Message-ID: <4DEBA6F0-DA45-4E84-823E-1F1AC48BDCCC@mac.com> no it will work only on mac os x however it's harmless to run it on other platform if you want to use it for other platform you have to do the following (I'll do it for linux) 1. modify RXTXInstaller class method public static RXTXInstaller getInstance() public static RXTXInstaller getInstance() { String osName = System.getProperty("os.name").toLowerCase(); if(osName.startsWith("mac")){ return new gnu.io.installer.macosx.MACOSXRXTXInstaller(); } else if(osName.startsWith("windows")){ return new gnu.io.installer.windows.WindowsRXTXInstaller(); }else if(osName.startsWith("linux")){ return new gnu.io.installer.linux.LinuxRXTXInstaller(); } return null; } 2. create folder gnu/io/installer/linux/ 3. create class Linux386RXTXInstaller package gnu.io.installer.linux; import java.io.File; public class Linux386RXTXInstaller extends gnu.io.installer.RXTXInstaller{ public Linux386RXTXInstaller(){ createJarFolder(); createLibFolder(); addJarResource("RXTXcomm.jar","/gnu/io/installer/resources/ linux/jar/RXTXcomm.dat"); addLibResource("librxtxSerial.so","/gnu/io/installer/ resources/linux/lib/librxtxSerial.so"); } protected void createJarFolder(){ String javaHome = System.getProperty("java.home"); char separator = File.separatorChar; jarFolder = new File(javaHome+separator+"lib"+separator+"ext"); } protected void createLibFolder(){ String javaHome = System.getProperty("java.home"); char separator = File.separatorChar; libFolder = new File(javaHome+separator+"bin"); } public void runPreProcess() {} //put here some action you need public void runPostProcess() {} //put here some action you need } 4. create folder /gnu/io/installer/resources/linux/jar and put there linux's version of RXTXcomm.dat (which is renamed RXTXcomm.jar) 5. create folder /gnu/io/installer/resources/linux/lib and put there linux's version of librxtxSerial. so 6. make sure that RXTXInstaller.jar has the following items: /gnu/io/installer/resources/linux/jar/RXTXcomm.jar /gnu/io/installer/resources/linux/lib/librxtxSerial.so 7. modify file installer.pref: jar file RXTXInstaller.jar must have the following item /gnu/io/installer/installer.pref that's basically it for windows you have to do the similar things: just replace linux to windows and librxtxSerial.so to rxtxSerial.dll and create appropriate gnu.io.installer.windows.WindowsRXTXInstaller class package gnu.io.installer.windows; import java.io.File; public class WindowsRXTXInstaller extends gnu.io.installer.RXTXInstaller{ public WindowsRXTXInstaller(){ createJarFolder(); createLibFolder(); addJarResource("RXTXcomm.jar","/gnu/io/installer/resources/ windows/jar/RXTXcomm.dat"); addLibResource("librxtxSerial.so","/gnu/io/installer/ resources/windows/lib/rxtxSerial.dll"); } protected void createJarFolder(){ String javaHome = System.getProperty("java.home"); char separator = File.separatorChar; jarFolder = new File(javaHome+separator+"lib"+separator+"ext"); } protected void createLibFolder(){ String javaHome = System.getProperty("java.home"); char separator = File.separatorChar; libFolder = new File(javaHome+separator+"bin"); } public void runPreProcess() {} //put here some action you need public void runPostProcess() {} //put here some action you need } installer.pref will look like On Mar 20, 2006, at 10:08 AM, Dr. Douglas Lyon wrote: > Hi All, > Is the Auth package able to work properly on > non Mac OS's? > It was not clear from the doc or download. > > Thanks! > - Doug > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx Dmitry Markman From joachim at buechse.de Mon Mar 20 10:49:06 2006 From: joachim at buechse.de (Joachim Buechse) Date: Mon, 20 Mar 2006 18:49:06 +0100 Subject: [Rxtx] BUG: Lock file stays even if port opening fails Message-ID: This was only tested on MacOSX but looking at the code, it should be true for all systems that use lock_uucp. I am opening a port which can not be opened (dialup port of a telephone paired via bluetooth but currently not reachable). The lock file is created and stays arround, even though the port open failed. After looking a bit through the code (of 2.17), I really wonder if it wouldn't be a good idea to make the "locking" an explicit operation called from the java code. This would certainly simplify the generation of meaningfull exceptions (and java based debugging). Maybe even the handling of "preopened" ports should be in the Java part of the lib (again for java based debugging puposes). That beeing said, I have no idea if this would be possible for the 2.07 implementation. Regards, Joachim From tjarvi at qbang.org Mon Mar 20 11:24:22 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 20 Mar 2006 11:24:22 -0700 (MST) Subject: [Rxtx] BUG: Lock file stays even if port opening fails In-Reply-To: References: Message-ID: On Mon, 20 Mar 2006, Joachim Buechse wrote: > This was only tested on MacOSX but looking at the code, it should be true > for all systems that use lock_uucp. > > I am opening a port which can not be opened (dialup port of a telephone > paired via bluetooth but currently not reachable). The lock file is > created and stays arround, even though the port open failed. > > > After looking a bit through the code (of 2.17), I really wonder if it > wouldn't be a good idea to make the "locking" an explicit operation > called from the java code. This would certainly simplify the generation > of meaningfull exceptions (and java based debugging). > Maybe even the handling of "preopened" ports should be in the Java part > of the lib (again for java based debugging puposes). That beeing said, I > have no idea if this would be possible for the 2.07 implementation. > > Regards, Hi Joachim It should be possible in the 2.0-7 implementation too. The calls to RXTXPort.java would not change. We would just do more there Moving more of that logic into Java would be better as many people don't like to look at C code. There is a liblockdev on most Linux distros that can do most of the C code and would be easier to use. The problem is embeded devices will not have that library. The preopened port code has not been really tested. That was a last minute request in a product cycle. I expect it will be tested this year though. As I recall, some devices really do not like CD raising on open. The preopened ports then allow people to mess around in java without power cycling the devices or losing data. -- Trent Jarvi tjarvi at qbang.org From joachim at buechse.de Mon Mar 20 12:01:08 2006 From: joachim at buechse.de (Joachim Buechse) Date: Mon, 20 Mar 2006 20:01:08 +0100 Subject: [Rxtx] BUG: Lock file stays even if port opening fails In-Reply-To: References: Message-ID: Hi Trent, What is your general feeling about moving code to Java? The last days I have been reading quite a bit of the code and there are several things, that might not work as expected. I'll give you two examples from is_device_locked: if LOCKDIR == /var/spool/locks the directory /var/spool/lock will not be checked. LOCKDIR is not checked for lockfiles with unexpected pefixes While these things have probably never been discovered in production, they are still possibly incorrect implementations. If it was Java code, I would write some unit tests producing the errors that could later be corrected. PS: One could imagine to actually implement the whole lockfile handling in Java using some native routines to get the values required (pid, st_dev, st_rdev, ...). On 20.03.2006, at 19:24, Trent Jarvi wrote: > On Mon, 20 Mar 2006, Joachim Buechse wrote: > >> This was only tested on MacOSX but looking at the code, it should >> be true for all systems that use lock_uucp. >> >> I am opening a port which can not be opened (dialup port of a >> telephone paired via bluetooth but currently not reachable). The >> lock file is created and stays arround, even though the port open >> failed. >> >> >> After looking a bit through the code (of 2.17), I really wonder if >> it wouldn't be a good idea to make the "locking" an explicit >> operation called from the java code. This would certainly simplify >> the generation of meaningfull exceptions (and java based debugging). >> Maybe even the handling of "preopened" ports should be in the Java >> part of the lib (again for java based debugging puposes). That >> beeing said, I have no idea if this would be possible for the 2.07 >> implementation. >> >> Regards, > > Hi Joachim > > It should be possible in the 2.0-7 implementation too. The calls > to RXTXPort.java would not change. We would just do more there > Moving more of that logic into Java would be better as many people > don't like to look at C code. There is a liblockdev on most Linux > distros that can do most of the C code and would be easier to use. > The problem is embeded devices will not have that library. > > The preopened port code has not been really tested. That was a > last minute request in a product cycle. I expect it will be tested > this year though. As I recall, some devices really do not like CD > raising on open. The preopened ports then allow people to mess > around in java without power cycling the devices or losing data. > > -- > Trent Jarvi > tjarvi at qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Mon Mar 20 12:21:02 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 20 Mar 2006 12:21:02 -0700 (MST) Subject: [Rxtx] BUG: Lock file stays even if port opening fails In-Reply-To: References: Message-ID: On Mon, 20 Mar 2006, Joachim Buechse wrote: > Hi Trent, > > What is your general feeling about moving code to Java? The last days I > have been reading quite a bit of the code and there are several things, > that might not work as expected. > > I'll give you two examples from is_device_locked: > > if LOCKDIR == /var/spool/locks the directory /var/spool/lock will not be > checked. > LOCKDIR is not checked for lockfiles with unexpected pefixes > > While these things have probably never been discovered in production, > they are still possibly incorrect implementations. If it was Java code, I > would write some unit tests producing the errors that could later be > corrected. > > PS: One could imagine to actually implement the whole lockfile handling > in Java using some native routines to get the values required (pid, > st_dev, st_rdev, ...). Hi Joachim I like the idea of moving more of the code into java but there are some things to consider. If you break this into multiple JNI calls, the performance will drop considerably during enumeration of ports. We are looking for 256 ports per dev type vs (16? in Sun's 2.0 and fewer types). Its hard to make assumptions. I've seen virtual ports start at /dev/foo100 for instance. It works out to over 7500 ports on Linux if you enable them all. We already trim that back by default. See Linux-all-ports in RXTXCommDriver.java. There are also native libraries that rxtx can link to. If you move too much into Java, linking to 'standard' libraries with distros will break. "configure --enable-liblock=yes" will not be doable. This is probably a favorable way with RedHat, Debian, Suse and others. Thats the right thing to do if there will be rpms, dpkg, .. For those reasons, I think it still make sense to keep it to a minimal ~3 calls to JNI code that we can use for speed and versatility. lock() isLocked(), unlock() perhaps. When I say speed, its more about avoiding crossing the JNI layer multiple times than java vs C performance. With versatility I think liblock is the right way for most but not all (embeded) linux distros. -- Trent Jarvi tjarvi at qbang.org From joachim at buechse.de Mon Mar 20 12:42:04 2006 From: joachim at buechse.de (Joachim Buechse) Date: Mon, 20 Mar 2006 20:42:04 +0100 Subject: [Rxtx] BUG: Lock file stays even if port opening fails In-Reply-To: References: Message-ID: <82C19FE7-DDCB-45B6-B2C9-7606B66F0124@buechse.de> Ok, what about providing a default implementation in Java? The RXTXCommDriver would call a (native) function useNativeLocking and if it returns true, call the native functions for lock() isLocked (), unlock(), else is would use the Java based default implementation. This could possibly be overriden by a property (again for debugging). Joachim On 20.03.2006, at 20:21, Trent Jarvi wrote: > On Mon, 20 Mar 2006, Joachim Buechse wrote: > >> Hi Trent, >> >> What is your general feeling about moving code to Java? The last >> days I have been reading quite a bit of the code and there are >> several things, that might not work as expected. >> >> I'll give you two examples from is_device_locked: >> >> if LOCKDIR == /var/spool/locks the directory /var/spool/lock will >> not be checked. >> LOCKDIR is not checked for lockfiles with unexpected pefixes >> >> While these things have probably never been discovered in >> production, they are still possibly incorrect implementations. If >> it was Java code, I would write some unit tests producing the >> errors that could later be corrected. >> >> PS: One could imagine to actually implement the whole lockfile >> handling in Java using some native routines to get the values >> required (pid, st_dev, st_rdev, ...). > > Hi Joachim > > I like the idea of moving more of the code into java but there are > some things to consider. > > If you break this into multiple JNI calls, the performance will > drop considerably during enumeration of ports. We are looking for > 256 ports per dev type vs (16? in Sun's 2.0 and fewer types). Its > hard to make assumptions. I've seen virtual ports start at /dev/ > foo100 for instance. > > It works out to over 7500 ports on Linux if you enable them all. > We already trim that back by default. See Linux-all-ports in > RXTXCommDriver.java. > > There are also native libraries that rxtx can link to. If you move > too much into Java, linking to 'standard' libraries with distros > will break. "configure --enable-liblock=yes" will not be doable. > This is probably a favorable way with RedHat, Debian, Suse and > others. Thats the right thing to do if there will be rpms, dpkg, .. > > For those reasons, I think it still make sense to keep it to a > minimal ~3 calls to JNI code that we can use for speed and > versatility. lock() isLocked(), unlock() perhaps. When I say > speed, its more about avoiding crossing the JNI layer multiple > times than java vs C performance. With versatility I think liblock > is the right way for most but not all (embeded) linux distros. > > -- > Trent Jarvi > tjarvi at qbang.org > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Mon Mar 20 12:44:47 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 20 Mar 2006 12:44:47 -0700 (MST) Subject: [Rxtx] BUG: Lock file stays even if port opening fails In-Reply-To: <82C19FE7-DDCB-45B6-B2C9-7606B66F0124@buechse.de> References: <82C19FE7-DDCB-45B6-B2C9-7606B66F0124@buechse.de> Message-ID: On Mon, 20 Mar 2006, Joachim Buechse wrote: > Ok, what about providing a default implementation in Java? > > The RXTXCommDriver would call a (native) function useNativeLocking and if > it returns true, call the native functions for lock() isLocked(), > unlock(), else is would use the Java based default implementation. This > could possibly be overriden by a property (again for debugging). > Hi Joachim That would be OK with me. -- Trent Jarvi tjarvi at qbang.org From dmarkman at mac.com Mon Mar 20 22:27:45 2006 From: dmarkman at mac.com (Dmitry Markman) Date: Tue, 21 Mar 2006 00:27:45 -0500 Subject: [Rxtx] binaries request Message-ID: <42702213-C222-4937-A585-7CFB17E47608@mac.com> Hi can somebody send me latest linux and windows binaries, please? or where I can find them (I didn't find them in the latest tareball) I gave up with my cygwin: something wrong I have no idea what java doesn't understand /cygwin/c syntax after I changed makefile it did java part but after that gcc 3.4.4 started to complain I set buffer length to 999 lines but I didn't get beginning of the story something wrong with my 1.4.2_09/include/jni.h gcc doesn't like it anyway I gave up thanks in advance Dmitry Markman -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060320/f8cbc57c/attachment-0038.html From tjarvi at qbang.org Mon Mar 20 22:36:48 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 20 Mar 2006 22:36:48 -0700 (MST) Subject: [Rxtx] binaries request In-Reply-To: <42702213-C222-4937-A585-7CFB17E47608@mac.com> References: <42702213-C222-4937-A585-7CFB17E47608@mac.com> Message-ID: On Tue, 21 Mar 2006, Dmitry Markman wrote: > Hi > can somebody send me latest linux and windows binaries, please? > > or where I can find them (I didn't find them in the latest tareball) > > I gave up with my cygwin: something wrong I have no idea what > java doesn't understand /cygwin/c syntax > after I changed makefile it did java part > but after that gcc 3.4.4 started to complain > I set buffer length to 999 lines but I didn't get beginning of the story > something wrong with my 1.4.2_09/include/jni.h gcc doesn't like it > anyway I gave up > > thanks in advance > Hi Dmitry The bins are here: ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7-bins-r2.zip Here are the files in the zip you want. Jar: rxtx-2.1-7-bins-r2/RXTXcomm.jar Windows: rxtx-2.1-7-bins-r2/Windows/i368-mingw32/rxtxSerial.dll Linux (x86) rxtx-2.1-7-bins-r2/Linux/i686-unknown-linux-gnu/librxtxSerial.so There are others in there including Parallel port support but those are the main ones for testing. -- Trent Jarvi tjarvi at qbang.org From dmarkman at mac.com Mon Mar 20 23:05:59 2006 From: dmarkman at mac.com (Dmitry Markman) Date: Tue, 21 Mar 2006 01:05:59 -0500 Subject: [Rxtx] binaries request In-Reply-To: References: <42702213-C222-4937-A585-7CFB17E47608@mac.com> Message-ID: thank you very much but windows's readme says: rxtxSerial.dll had to be recomopiled to link in missing native methods. should I ignore it? or what? thanks again also I understand that I should use mingw not cygwin I'll try to install mingw On Mar 21, 2006, at 12:36 AM, Trent Jarvi wrote: > On Tue, 21 Mar 2006, Dmitry Markman wrote: > >> Hi >> can somebody send me latest linux and windows binaries, please? >> >> or where I can find them (I didn't find them in the latest tareball) >> >> I gave up with my cygwin: something wrong I have no idea what >> java doesn't understand /cygwin/c syntax >> after I changed makefile it did java part >> but after that gcc 3.4.4 started to complain >> I set buffer length to 999 lines but I didn't get beginning of the >> story >> something wrong with my 1.4.2_09/include/jni.h gcc doesn't like it >> anyway I gave up >> >> thanks in advance >> > > Hi Dmitry > > The bins are here: > > ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7-bins-r2.zip > > Here are the files in the zip you want. > > Jar: > > rxtx-2.1-7-bins-r2/RXTXcomm.jar > > Windows: > > rxtx-2.1-7-bins-r2/Windows/i368-mingw32/rxtxSerial.dll > > Linux (x86) > > rxtx-2.1-7-bins-r2/Linux/i686-unknown-linux-gnu/librxtxSerial.so > > There are others in there including Parallel port support but those > are the main ones for testing. > > -- > Trent Jarvi > tjarvi at qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx Dmitry Markman From tjarvi at qbang.org Mon Mar 20 23:20:33 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 20 Mar 2006 23:20:33 -0700 (MST) Subject: [Rxtx] binaries request In-Reply-To: References: <42702213-C222-4937-A585-7CFB17E47608@mac.com> Message-ID: On Tue, 21 Mar 2006, Dmitry Markman wrote: > thank you very much > > but windows's readme says: > rxtxSerial.dll had to be recomopiled to link in missing native methods. > > should I ignore it? or what? > Hi Dmitry That dll should be OK. r2 is the recompile linked to the missing native method. The readme explains why it was recompiled; fuser.o was not linked into the dll in the first release. -- Trent Jarvi tjarvi at qbang.org From ariantristan at yahoo.com Mon Mar 20 23:55:24 2006 From: ariantristan at yahoo.com (Lambok Sianturi) Date: Mon, 20 Mar 2006 22:55:24 -0800 (PST) Subject: [Rxtx] jvm issue Message-ID: <20060321065524.94779.qmail@web50701.mail.yahoo.com> Hi All, This is my first time to join RxTx mailing list. I thank you all for allowing others to sign in in requests help. I use the latest RxTx lib in Fedora 3 with java version 1.4.2_09 b05. And I got this error: # # An unexpected error has been detected by HotSpot Virtual Machine: # # SIGSEGV (0xb) at pc=0x00bf27f3, pid=2633, tid=3086112448 # # Java VM: Java HotSpot(TM) Client VM (1.4.2_09-b05 mixed mode) # Problematic frame: # C [ld-linux.so.2+0xa7f3] # # An error report file with more information is saved as hs_err_pid2633.log # # If you would like to submit a bug report, please visit: # http://java.sun.com/webapps/bugreport/crash.jsp # ./run.sh: line 3: 2633 Aborted /usr/local/java/bin/java -Djava.library.path=/usr/local/java/jre/lib/ -Djsmsengine.debug=true -classpath jsmsengine.jar:smsgateway.jar:classes12.jar:RXTXcomm.jar:. com.api.sms.SMSServer What is the jvm depedency for the latest library? Can I use 1.4.2_09 b05? Thanks in advance. Arian --------------------------------- Yahoo! Mail Use Photomail to share photos without annoying attachments. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060320/83d58dd7/attachment-0038.html From f.frumento at ngi.it Tue Mar 21 00:21:47 2006 From: f.frumento at ngi.it (Fabio Frumento) Date: Tue, 21 Mar 2006 08:21:47 +0100 Subject: [Rxtx] Javadoc on the go Message-ID: <441FA98B.9050701@ngi.it> Hi Trent, sorry for the big delay but my job is running wild, i was out for some time but now i'm back and ready to continue the javadoc for Rxtx. Did you used the last javadoc patch i sent you ? let me know if i have to send it to you again or not. regards Fabio From lyon at docjava.com Tue Mar 21 00:51:18 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Tue, 21 Mar 2006 02:51:18 -0500 Subject: [Rxtx] lock files Message-ID: Hi All, You know, if the use of lock files were under Java control (rather than a build-time decision), it might enable a more unified binary distro. It might also facilitate quick prototyping of non-lock file approaches to resolving serial port contention issues (i.e., mac-like approaches vs. linux approaches, etc.). I realize that this is a radical overhaul of the lock file policy issue. Also, it may harm performance. On the other hand, our benchmarks on JNI overhead for modern processors indicate performance impact should be minimal. Perhaps it is more of an issue with the toybox systems. Suppose there were a class with a reasonable default...someone might write: SerialPortLockPolicy.setPolicy(SerialPortLockPolicy.UNIX_LOCK_FILE); SerialPortLockPolicy.setPolicy(SerialPortLockPolicy.NO_LOCK_CHECKING); SerialPortLockPolicy.setPolicy(SerialPortLockPolicy.MAC_STYLE); Thus, we could have a run-time reconfiguration of the serial port lock policy. A special NO_LOCK version of the binary would no longer be required. Any thoughts on this? Thanks! - Doug From joachim at buechse.de Tue Mar 21 03:09:09 2006 From: joachim at buechse.de (Joachim Buechse) Date: Tue, 21 Mar 2006 11:09:09 +0100 Subject: [Rxtx] lock files In-Reply-To: References: Message-ID: <8E12916A-1B9A-4FF2-B684-E2D1C794221B@buechse.de> This is pretty much what I thought about when I suggested, that the default behaviour could be overwritten with a property. I am very much in favor of this approach. In particular this allows much easier debugging for PC based java developers. I think big parts of the Java (and maybe some parts of the C code) could use a bit of a structural workover (unit tests, javadoc, synchronization, etc). Maybe there should be a CVS branch for this experimental version. I'd be happy to contribute a first workover for some of the Java code. Designing for testability and implementing a good bunch of unit tests has been a strategy that worked quite well in the Java projects I lead. And it ultimately allows more liberal change permission. Regards, Joachim On 21.03.2006, at 08:51, Dr. Douglas Lyon wrote: > Hi All, > You know, if the use of lock files were > under Java control (rather than a build-time decision), > it might enable a more unified binary distro. It might also > facilitate quick prototyping of non-lock file approaches > to resolving serial port contention issues (i.e., mac-like > approaches vs. linux approaches, etc.). > > I realize that this is a radical overhaul of the lock file policy > issue. Also, it may harm performance. On the other hand, > our benchmarks on JNI overhead for modern processors indicate > performance impact should be minimal. Perhaps it is more of > an issue with the toybox systems. > > Suppose there were a class with a reasonable default...someone > might write: > SerialPortLockPolicy.setPolicy(SerialPortLockPolicy.UNIX_LOCK_FILE); > SerialPortLockPolicy.setPolicy(SerialPortLockPolicy.NO_LOCK_CHECKING); > SerialPortLockPolicy.setPolicy(SerialPortLockPolicy.MAC_STYLE); > > Thus, we could have a run-time reconfiguration of the serial port lock > policy. A special NO_LOCK version of the binary would no longer > be required. > > Any thoughts on this? > > Thanks! > - Doug > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From joachim at buechse.de Tue Mar 21 06:23:08 2006 From: joachim at buechse.de (Joachim Buechse) Date: Tue, 21 Mar 2006 14:23:08 +0100 Subject: [Rxtx] PATCH: use of ioctl(fd, TIOCEXCL) instead of lockfiles Message-ID: <923AE774-EEA2-4911-92D8-32BB27802C8B@buechse.de> Here is the patch for the ioctl(fd, TIOCEXCL). I have verified this only for OSX 10.4.5, hence it is only defined for APPLE. However, it should work at least for Solaris as well. If a process has requested TIOEXCL further open calls by other user processes will fail. The patch also disables uucp style locking for APPLE. Obviously this is discussable. I think it is the way to go, as it eliminates creating the lock directory which doesnt exist on the standard installation and it eliminates messing with the system group definitions (adding users to group uucp). Regarding the possibility of root processes opening a device which is locked - I consider this a feature not a potential problem. It is highly unlikely, that somebody is crazy enough to run a JavaVM as root (unless he has no other means of getting a restricted IP port opened, ie doesnt understand ipfw). Anyway, even if the process runs as root, it fails when calling ioctl(fd, TIOCEXCL). It could however still open the port to listen for RING events. I.e. a fax server which needs to see incoming calls but otherwise doesnt want to block the port. So the only case where the proposed mechanism fails is, if an incorrectly implemented process running as root conflicts with a user process. I think this can be accepted. Regards, Joachim PS: If this patch is generally accepted, the installer and Mac doku should obviously be changed as well. Index: SerialImp.c =================================================================== RCS file: /usr/local/cvsroot/rxtx-devel/src/SerialImp.c,v retrieving revision 1.46.2.187 diff -u -r1.46.2.187 SerialImp.c --- SerialImp.c 29 Jan 2006 22:19:04 -0000 1.46.2.187 +++ SerialImp.c 21 Mar 2006 12:59:16 -0000 @@ -656,6 +656,25 @@ fd=OPEN (filename, O_RDWR | O_NOCTTY | O_NONBLOCK ); } while (fd < 0 && errno==EINTR); +#ifdef OPEN_EXCL + // Note that open() follows POSIX semantics: multiple open() calls to + // the same file will succeed unless the TIOCEXCL ioctl is issued. + // This will prevent additional opens except by root-owned processes. + // See tty(4) ("man 4 tty") and ioctl(2) ("man 2 ioctl") for details. + + if (fd >= 0 && (ioctl(fd, TIOCEXCL) == -1)) + { + sprintf( message, "open: exclusive access denied for % s\n", + filename ); + report( message ); + report_error( message ); + + close(fd); + goto fail; + } +#endif /* OPEN_EXCL */ + + if( configure_port( fd ) ) goto fail; (*env)->ReleaseStringUTFChars( env, jstr, filename ); sprintf( message, "open: fd returned is %i\n", fd ); Index: SerialImp.h =================================================================== RCS file: /usr/local/cvsroot/rxtx-devel/src/SerialImp.h,v retrieving revision 1.11.2.49 diff -u -r1.11.2.49 SerialImp.h --- SerialImp.h 5 Jul 2005 17:47:21 -0000 1.11.2.49 +++ SerialImp.h 21 Mar 2006 12:59:17 -0000 @@ -135,7 +135,8 @@ /*# define LOCKDIR "/var/spool/uucp"*/ # define LOCKDIR "/var/lock" # define LOCKFILEPREFIX "LK." -# define UUCP +/*# define UUCP*/ +# define OPEN_EXCL #endif /* __APPLE__ */ #if defined(__NetBSD__) # define DEVICEDIR "/dev/" From tjarvi at qbang.org Tue Mar 21 10:26:08 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 21 Mar 2006 10:26:08 -0700 (MST) Subject: [Rxtx] Javadoc on the go In-Reply-To: <441FA98B.9050701@ngi.it> References: <441FA98B.9050701@ngi.it> Message-ID: On Tue, 21 Mar 2006, Fabio Frumento wrote: > Hi Trent, > > sorry for the big delay but my job is running wild, i was out for some > time but now i'm back and ready to continue the javadoc for Rxtx. > > Did you used the last javadoc patch i sent you ? let me know if i have to > send it to you again or not. > > regards > > Fabio Hi Fabio The patch is in the rxtx mail-list archives. It will be going in soon. I did not see a time critical portion. I'll probably be going through the list since the last batch of patches this weekend and putting them into CVS. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Tue Mar 21 10:57:18 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 21 Mar 2006 10:57:18 -0700 (MST) Subject: [Rxtx] jvm issue In-Reply-To: <20060321065524.94779.qmail@web50701.mail.yahoo.com> References: <20060321065524.94779.qmail@web50701.mail.yahoo.com> Message-ID: On Mon, 20 Mar 2006, Lambok Sianturi wrote: > Hi All, > This is my first time to join RxTx mailing list. I thank you all for allowing others to sign in in requests help. > I use the latest RxTx lib in Fedora 3 with java version 1.4.2_09 b05. And I got this error: > > # > # An unexpected error has been detected by HotSpot Virtual Machine: > # > # SIGSEGV (0xb) at pc=0x00bf27f3, pid=2633, tid=3086112448 > # > # Java VM: Java HotSpot(TM) Client VM (1.4.2_09-b05 mixed mode) > # Problematic frame: > # C [ld-linux.so.2+0xa7f3] A native library loading error? What happens if you recompile rxtx on your system and install that? This sounds like an ABI problem? rxtx 2.1-7 was compiled with a gcc 2.96 toolchain as I recall. The hope is newer system will be backwards compatible. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Tue Mar 21 11:05:29 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 21 Mar 2006 11:05:29 -0700 (MST) Subject: [Rxtx] PATCH: use of ioctl(fd, TIOCEXCL) instead of lockfiles In-Reply-To: <923AE774-EEA2-4911-92D8-32BB27802C8B@buechse.de> References: <923AE774-EEA2-4911-92D8-32BB27802C8B@buechse.de> Message-ID: On Tue, 21 Mar 2006, Joachim Buechse wrote: > Here is the patch for the ioctl(fd, TIOCEXCL). I have verified this only > for OSX 10.4.5, hence it is only defined for APPLE. However, it should > work at least for Solaris as well. > > If a process has requested TIOEXCL further open calls by other user > processes will fail. > > The patch also disables uucp style locking for APPLE. Obviously this is > discussable. I think it is the way to go, as it eliminates creating the > lock directory which doesnt exist on the standard installation and it > eliminates messing with the system group definitions (adding users to > group uucp). > > Regarding the possibility of root processes opening a device which is > locked - I consider this a feature not a potential problem. It is highly > unlikely, that somebody is crazy enough to run a JavaVM as root (unless > he has no other means of getting a restricted IP port opened, ie doesnt > understand ipfw). Anyway, even if the process runs as root, it fails when > calling ioctl(fd, TIOCEXCL). It could however still open the port to > listen for RING events. I.e. a fax server which needs to see incoming > calls but otherwise doesnt want to block the port. So the only case where > the proposed mechanism fails is, if an incorrectly implemented process > running as root conflicts with a user process. I think this can be > accepted. > > Regards, > Joachim > > PS: If this patch is generally accepted, the installer and Mac doku > should obviously be changed as well. > > > Index: SerialImp.c > =================================================================== > RCS file: /usr/local/cvsroot/rxtx-devel/src/SerialImp.c,v > retrieving revision 1.46.2.187 > diff -u -r1.46.2.187 SerialImp.c > --- SerialImp.c 29 Jan 2006 22:19:04 -0000 1.46.2.187 > +++ SerialImp.c 21 Mar 2006 12:59:16 -0000 > @@ -656,6 +656,25 @@ > fd=OPEN (filename, O_RDWR | O_NOCTTY | O_NONBLOCK ); > } while (fd < 0 && errno==EINTR); > > +#ifdef OPEN_EXCL > + // Note that open() follows POSIX semantics: multiple open() > calls to > + // the same file will succeed unless the TIOCEXCL ioctl is > issued. > + // This will prevent additional opens except by root-owned > processes. > + // See tty(4) ("man 4 tty") and ioctl(2) ("man 2 ioctl") for > details. > + > + if (fd >= 0 && (ioctl(fd, TIOCEXCL) == -1)) > + { > + sprintf( message, "open: exclusive access denied for % > s\n", > + filename ); > + report( message ); > + report_error( message ); > + > + close(fd); > + goto fail; > + } > +#endif /* OPEN_EXCL */ > + > + > if( configure_port( fd ) ) goto fail; > (*env)->ReleaseStringUTFChars( env, jstr, filename ); > sprintf( message, "open: fd returned is %i\n", fd ); > Index: SerialImp.h > =================================================================== > RCS file: /usr/local/cvsroot/rxtx-devel/src/SerialImp.h,v > retrieving revision 1.11.2.49 > diff -u -r1.11.2.49 SerialImp.h > --- SerialImp.h 5 Jul 2005 17:47:21 -0000 1.11.2.49 > +++ SerialImp.h 21 Mar 2006 12:59:17 -0000 > @@ -135,7 +135,8 @@ > /*# define LOCKDIR "/var/spool/uucp"*/ > # define LOCKDIR "/var/lock" > # define LOCKFILEPREFIX "LK." > -# define UUCP > +/*# define UUCP*/ > +# define OPEN_EXCL > #endif /* __APPLE__ */ > #if defined(__NetBSD__) > # define DEVICEDIR "/dev/" > This looks like a good start. What do you think Dmitry? Perhaps all systems with TIOCEXCL defined should use that though. Even if they use lockfiles. It wont hurt anything. That would catch people hacking their own serial apps without checking lockfiles. Its a good idea to avoid C++ style comments in the C portions. Some older systems don't deal with them well. If it's just for Mac OS X, it isn't a big deal. I think it was the Irix compiler that was problematic? -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Tue Mar 21 11:22:05 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 21 Mar 2006 11:22:05 -0700 (MST) Subject: [Rxtx] lock files In-Reply-To: <8E12916A-1B9A-4FF2-B684-E2D1C794221B@buechse.de> References: <8E12916A-1B9A-4FF2-B684-E2D1C794221B@buechse.de> Message-ID: We can try it. Maybe the JNI is much improved. The nice thing about linking into liblock is distros then worry about lockfiles on their systems. This way, we have to deal with any changes that may show up. On Tue, 21 Mar 2006, Joachim Buechse wrote: > This is pretty much what I thought about when I suggested, that the > default behaviour could be overwritten with a property. I am very much in > favor of this approach. In particular this allows much easier debugging > for PC based java developers. > > I think big parts of the Java (and maybe some parts of the C code) could > use a bit of a structural workover (unit tests, javadoc, synchronization, > etc). Maybe there should be a CVS branch for this experimental version. > I'd be happy to contribute a first workover for some of the Java code. > Designing for testability and implementing a good bunch of unit tests has > been a strategy that worked quite well in the Java projects I lead. And > it ultimately allows more liberal change permission. > > Regards, > Joachim > > > On 21.03.2006, at 08:51, Dr. Douglas Lyon wrote: > >> Hi All, >> You know, if the use of lock files were >> under Java control (rather than a build-time decision), >> it might enable a more unified binary distro. It might also >> facilitate quick prototyping of non-lock file approaches >> to resolving serial port contention issues (i.e., mac-like >> approaches vs. linux approaches, etc.). >> >> I realize that this is a radical overhaul of the lock file policy >> issue. Also, it may harm performance. On the other hand, >> our benchmarks on JNI overhead for modern processors indicate >> performance impact should be minimal. Perhaps it is more of >> an issue with the toybox systems. >> >> Suppose there were a class with a reasonable default...someone >> might write: >> SerialPortLockPolicy.setPolicy(SerialPortLockPolicy.UNIX_LOCK_FILE); >> SerialPortLockPolicy.setPolicy(SerialPortLockPolicy.NO_LOCK_CHECKING); >> SerialPortLockPolicy.setPolicy(SerialPortLockPolicy.MAC_STYLE); >> >> Thus, we could have a run-time reconfiguration of the serial port lock >> policy. A special NO_LOCK version of the binary would no longer >> be required. >> >> Any thoughts on this? >> >> Thanks! >> - Doug >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From dmarkman at mac.com Tue Mar 21 16:05:17 2006 From: dmarkman at mac.com (Dmitry Markman) Date: Tue, 21 Mar 2006 18:05:17 -0500 Subject: [Rxtx] PATCH: use of ioctl(fd, TIOCEXCL) instead of lockfiles In-Reply-To: References: <923AE774-EEA2-4911-92D8-32BB27802C8B@buechse.de> Message-ID: <512AC70C-BB86-48F2-A83C-023F35C23BAB@mac.com> I think it's cool, but I'd like to have that property implementation when user can choose between locking mechanism about comments: it's easy to change comments to the C style or we can use extensions of the file to cpp so c++ compiler will be used On Mar 21, 2006, at 1:05 PM, Trent Jarvi wrote: > This looks like a good start. What do you think Dmitry? Perhaps > all systems with TIOCEXCL defined should use that though. Even if > they use lockfiles. It wont hurt anything. That would catch > people hacking their own serial apps without checking lockfiles. > > Its a good idea to avoid C++ style comments in the C portions. > Some older systems don't deal with them well. If it's just for Mac > OS X, it isn't a big deal. I think it was the Irix compiler that > was problematic? Dmitry Markman From dmarkman at mac.com Tue Mar 21 16:13:00 2006 From: dmarkman at mac.com (Dmitry Markman) Date: Tue, 21 Mar 2006 18:13:00 -0500 Subject: [Rxtx] PATCH: use of ioctl(fd, TIOCEXCL) instead of lockfiles In-Reply-To: References: <923AE774-EEA2-4911-92D8-32BB27802C8B@buechse.de> Message-ID: I'd like to add that creating locking folder isn't a big deal we never had a problem related to the lock folders, because we always used installer on mac os x from other hand I'm not very much familiar with iotcl locking approach and I'm not sure it's more efficient Joachim wrote "I think it is the way to go, as it eliminates creating the lock directory which doesnt exist on the standard installation and it eliminates messing with the system group definitions (adding users to group uucp)." but I really didn't have any problem with that 1. doesn't exist on the standard installation there are many-many things that don't exist in the standard installation so I don't think that argument is strong enough 2. messing with the system group definitions I don't think we're messing with the group definition mac os x provides very clear way to set up group's members and together with Greg Guerin AuthKit there is no problem to set those definitions so I don't think that argument is strong either but from other hand using iotcl is more promising and is more elegant On Mar 21, 2006, at 1:05 PM, Trent Jarvi wrote: > > This looks like a good start. What do you think Dmitry? Perhaps > all systems with TIOCEXCL defined should use that though. Even if > they use lockfiles. It wont hurt anything. That would catch > people hacking their own serial apps without checking lockfiles. Dmitry Markman From joachim at buechse.de Wed Mar 22 04:46:45 2006 From: joachim at buechse.de (Joachim Buechse) Date: Wed, 22 Mar 2006 12:46:45 +0100 Subject: [Rxtx] PATCH: use of ioctl(fd, TIOCEXCL) instead of lockfiles In-Reply-To: References: <923AE774-EEA2-4911-92D8-32BB27802C8B@buechse.de> Message-ID: Sorry, I was not very clear with my arguments, so I will try again;-) Please, don't take this as an attack against work that has been done. I think the contributions that have been made in the past were made in a good spirit. But I really believe, that the current solution for OSX has many shortcomings and should be changed as soon as possible. lock files --- The /var/lock folder does not exist on the standard OSX installation, however the standard installation includes several applications that use serial ports (i.e. the FAX capability). This indicates, that the lock folder approach will not work well with system components. Applications for OSX will generally try to live in harmony with system components (except for HP print drivers of course). I think RXTX should follow this approach as well. uucp group --- Accessing serial ports is not an admin privileged operation on OSX. Any user (world) has read/write privileges on /dev/tty*. So the system default is to not enforce any group membership to access these ports. The group uucp however is a system group on all unix systems I know. It exists for certain system processes. A non admin user should in general not be a member of this group. Quite arguably no user should ever be a member of this group. Installer --- My general opinion is, that - no Installer should touch user or group data without warning - no Application Installer should touch groups which are not specific to the very application installed - no Installer should ever add regular users to a system group The current installer injects the installing user in the group uucp without warning about this change and without giving the option to "opt out" of this change. This is a potential security risk (but not currently a real one, as OSX contains no folders belonging to group uucp). The current installer does not work for multi user systems. It puts the installing user in the uucp group. However the installing user is not necessarily the user that will use the application. Putting all users that may use a serial port application in the system group uucp seems like a very invasive approach to me. Besides that, newly created users will not automatically be in the group and hence, serial applications will "break" for new users without obvious reasons. Avoiding the lock files will allow self contained applications (i.e. drag&drop installation). In my eyes this is largely preferable over an installer that requests admin privileges. Adding up all these points indicates very strongly, that the lock-file implementation is not the way to go on OSX. Regards, Joachim On 22.03.2006, at 00:13, Dmitry Markman wrote: > I'd like to add that > > creating locking folder isn't a big deal > we never had a problem related to the lock folders, because we > always used installer on mac os x > from other hand I'm not very much familiar with iotcl locking > approach and I'm not sure it's more efficient > > Joachim wrote "I think it is the way to go, as it eliminates > creating the lock directory which doesnt exist on the standard > installation and it eliminates messing with the system group > definitions (adding users to group uucp)." but I really didn't have > any problem with that > > 1. doesn't exist on the standard installation > there are many-many things that don't exist in the standard > installation so I don't think that argument is strong enough > 2. messing with the system group definitions > I don't think we're messing with the group definition > mac os x provides very clear way to set up group's members and > together with Greg Guerin AuthKit there is no problem to set those > definitions > so I don't think that argument is strong either > but from other hand using iotcl is more promising and is more elegant > > > > On Mar 21, 2006, at 1:05 PM, Trent Jarvi wrote: > >> >> This looks like a good start. What do you think Dmitry? Perhaps >> all systems with TIOCEXCL defined should use that though. Even if >> they use lockfiles. It wont hurt anything. That would catch >> people hacking their own serial apps without checking lockfiles. > > Dmitry Markman > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From dmarkman at mac.com Wed Mar 22 05:27:13 2006 From: dmarkman at mac.com (Dmitry Markman) Date: Wed, 22 Mar 2006 07:27:13 -0500 Subject: [Rxtx] PATCH: use of ioctl(fd, TIOCEXCL) instead of lockfiles In-Reply-To: References: <923AE774-EEA2-4911-92D8-32BB27802C8B@buechse.de> Message-ID: <83440CF3-DCD8-41C1-B941-F227232C27E3@mac.com> thanks for the very good explanation I didn't think that you were attacking any thing, so don't worry I just had feeling, that there were more aesthetic reasons for going to ioctl then real necessity now you explained everything quite well (BTW, asfar as I remember installer asks admin password so it wasn't quiet, but it really doesn't matter now) thanks On Mar 22, 2006, at 6:46 AM, Joachim Buechse wrote: > Sorry, I was not very clear with my arguments, so I will try again;-) > > Please, don't take this as an attack against work that has been > done. I think the contributions that have been made in the past > were made in a good spirit. But I really believe, that the current > solution for OSX has many shortcomings and should be changed as > soon as possible. > > lock files > --- > The /var/lock folder does not exist on the standard OSX > installation, however the standard installation includes several > applications that use serial ports (i.e. the FAX capability). This > indicates, that the lock folder approach will not work well with > system components. Applications for OSX will generally try to live > in harmony with system components (except for HP print drivers of > course). I think RXTX should follow this approach as well. > > uucp group > --- > Accessing serial ports is not an admin privileged operation on OSX. > Any user (world) has read/write privileges on /dev/tty*. So the > system default is to not enforce any group membership to access > these ports. The group uucp however is a system group on all unix > systems I know. It exists for certain system processes. A non admin > user should in general not be a member of this group. Quite > arguably no user should ever be a member of this group. > > Installer > --- > My general opinion is, that > - no Installer should touch user or group data without warning > - no Application Installer should touch groups which are not > specific to the very application installed > - no Installer should ever add regular users to a system group > > The current installer injects the installing user in the group uucp > without warning about this change and without giving the option to > "opt out" of this change. This is a potential security risk (but > not currently a real one, as OSX contains no folders belonging to > group uucp). > > The current installer does not work for multi user systems. It puts > the installing user in the uucp group. However the installing user > is not necessarily the user that will use the application. Putting > all users that may use a serial port application in the system > group uucp seems like a very invasive approach to me. Besides that, > newly created users will not automatically be in the group and > hence, serial applications will "break" for new users without > obvious reasons. > > > Avoiding the lock files will allow self contained applications > (i.e. drag&drop installation). In my eyes this is largely > preferable over an installer that requests admin privileges. Adding > up all these points indicates very strongly, that the lock-file > implementation is not the way to go on OSX. > > Regards, > Joachim > > > On 22.03.2006, at 00:13, Dmitry Markman wrote: > >> I'd like to add that >> >> creating locking folder isn't a big deal >> we never had a problem related to the lock folders, because we >> always used installer on mac os x >> from other hand I'm not very much familiar with iotcl locking >> approach and I'm not sure it's more efficient >> >> Joachim wrote "I think it is the way to go, as it eliminates >> creating the lock directory which doesnt exist on the standard >> installation and it eliminates messing with the system group >> definitions (adding users to group uucp)." but I really didn't >> have any problem with that >> >> 1. doesn't exist on the standard installation >> there are many-many things that don't exist in the standard >> installation so I don't think that argument is strong enough >> 2. messing with the system group definitions >> I don't think we're messing with the group definition >> mac os x provides very clear way to set up group's members and >> together with Greg Guerin AuthKit there is no problem to set those >> definitions >> so I don't think that argument is strong either >> but from other hand using iotcl is more promising and is more elegant >> >> >> >> On Mar 21, 2006, at 1:05 PM, Trent Jarvi wrote: >> >>> >>> This looks like a good start. What do you think Dmitry? Perhaps >>> all systems with TIOCEXCL defined should use that though. Even >>> if they use lockfiles. It wont hurt anything. That would catch >>> people hacking their own serial apps without checking lockfiles. >> >> Dmitry Markman >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx Dmitry Markman From lyon at docjava.com Wed Mar 22 06:12:18 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Wed, 22 Mar 2006 08:12:18 -0500 Subject: [Rxtx] sole of a new design pattern Message-ID: Hi All, I have been thinking about how we design the serial port software. I think we need a new design pattern. For lack of a better term, I shall call it: The Parametric Singleton Design Pattern By Douglas A. Lyon ABSTRACT The goal of the singleton design pattern is to make sure that there is one, and only one, instance of a given class. The goal of the parametric singleton design pattern is to make sure that there is one, and only one, instance of a given class with the given parametric values. We parametric singleton design pattern combines the singleton design pattern with a parameter that enables unique creation of instances of a class. These instances are cached. When a user asks for an instance with these parameters, the cache is checked. If the instance is in the cache, the instance is returned, otherwise it is created, added to the cache and then returned. We apply our parametric singleton design pattern to the retrieval of RMI registries bound to a given port. The goal of our system is to make sure that no two RMI registries are listening to the same socket and to make use of the RMI registries after they have been created. RMI registries are used in distributed computation. Introduction The singleton design pattern is meant to ensure that on a single instance of a class exists. It is also meant to provide a global point of access to it. The intent of the parametric singleton design pattern is to ensure that a class has only one instance for a given set of parameter values. It also provides a global point of access to it. Motivation A system cannot tolerate multiple instances of some classes with identical parameters. For example, you cannot have two instances making use of the same serial port, at the same time. You cannot have two instances that are trying to listen to the same socket connection. You cannot have two instances writing to the same file structure at the same time. As the operating system is often thought of as the arbiter of consumed resources (i.e., tape drives, serial ports, etc.) we frequently leave it to an operating system implementation to resolve these contention issues. Even for similar resources (like serial ports) there are few standards for handling contention. For example, serial ports on Linux are locked using a "/var/lock" file. POSIX, on the other hand, uses ioctl mechanisms to prevent contention. A better solution is to make a class that is responsible for keeping track of the instances created from the class. The class is declared final, so that it cannot be subclassed. The class also has a private constructor, so that other classes cannot instance it. The new design pattern is called the parametric singleton design pattern and it provides a way to access and create instances with given parameters. Applicability Use the Parametric Singleton Design Pattern when: 1. There must be exactly one instance of a class with the given parameters. 2. The instances must be accessible to clients from a well-known access point. Structure Insert UML diagram here. Participants The Parametric Singleton Clients that need instances 1. The Parametric Singleton defines an instance upon request from a client, if, and only if, the instance does not already exist. 2. The Parametric Singleton returns the instance to the client. 3. The Parametric Singleton is responsible for creating unique instances from given parameters. Collaborations Clients obtain a reference to a Parametric Singleton instance only through the parametric singleton design pattern. If the instance is left in an improper state (e.g., the serial port was left open) it is NOT the role of the Parametric Singleton Design Pattern to close the IO port. Nor is it the role of the Parametric Singleton Design Pattern to open the port. That role is delegate to some other part of the system. Further, it is not the role of the Parametric Singleton Design Pattern to check out resources. That is, multiple threads can have multiple references to the same resource at the same time. MUTEX locking is delegated to some other part of the system. Consequences The Parametric Singleton Design Pattern has several benefits: 1. Controlled access to parametrically defined instances. Since the Parametric Singleton class encapsulates its instances, there is control over how and when clients access it. 2. Reduced name space. The Parametric Singleton pattern avoids global variables that store instances created from the same parameter. Implementation Here are implementation issues to consider when using the Parametric Singleton pattern: 1. Unique mapping of parameters. The Parametric Singleton pattern requires that there be a mean to isomorphically map the parameter space into the instance space and back again. 2. Ensure unique instances. The Parametric Singleton pattern makes unique instances from parameters, and it does so only once. 3. Cache instances for fast retrieval. The Parametric Singleton pattern must be able to look up instances, given some set of parameters, and do so from some data structure. That is, there must be enough space to hold references to all the instances the program will need. Also, a mechanism is needed to look up and retrieve the instances quickly enough to satisfy the clients. Sample Code public final class ParametricSingletonRmiRegistry { private static Hashtable registry = new Hashtable(100); // use singleton pattern and??????????????????????????????????????????????? // prevent instantiation of RmiRegistryUtils.?????????????????????????????? private ParametricSingletonRmiRegistry() { } // the only instance of the Registry held by the RmiRegistryUtils?????????? public static void listNames(Integer port) { if (!isInCacheAndRunning(port)) return; Registry r = (Registry) registry.get(port); System.out.println("registry on port: " + port); System.out.println("registry: " + r); System.out.println("names: "); try { print(r.list()); } catch (RemoteException e) { In.message(e); } System.out.println("------------------------"); } /**???????????????????????????????????????????????????????????????????????? * Checks whether a Registry has been started on this host????????????????? * in the specified port.?????????????????????????????????????????????????? * If not, it tries to start one.?????????????????????????????????????????? * when it fails to start a Registry, it exits the program????????????????? * with exit code 1.??????????????????????????????????????????????????????? */ public static void restart(int port) { if (isInCacheAndRunning(port)) return; try { startRegistry(port); } catch (RemoteException e) { In.message(e); } } /**???????????????????????????????????????????????????????????????????????? * @param port????????????????????????????????????????????????????????????? * @return true if registry is in cache and running???????????????????????? */ private static boolean isInCacheAndRunning(Integer port) { if (!isRegistryRunning(port.intValue())) return false; if (!isRegistryInCache(port.intValue())) return false; return true; } /**???????????????????????????????????????????????????????????????????????? * @param port????????????????????????????????????????????????????????????? * @return true if we are able to locate a local registry on port.??????????????????????????????????????????????????????????????????????????? */ private static boolean isRegistryRunning(int port) { try { Registry r = LocateRegistry.getRegistry(port); if (r != null) return true; } catch (RemoteException e) { return false; } return false; } /**???????????????????????????????????????????????????????????????????????? * @param port????????????????????????????????????????????????????????????? * @return return true if registry is in cache????????????????????????????? */ private static boolean isRegistryInCache(int port) { if (registry.get(new Integer(port)) == null) return false; return true; } /**???????????????????????????????????????????????????????????????????????? * Restart the registry, if needed.???????????????????????????????????????? * Return the only instance of the registry for consistent global?????????? * using by making use of the Singleton Design Pattern????????????????????? *????????????????????????????????????????????????????????????????????????? * @return the internally held registry instance.?????????????????????????? */ public static Registry getRegistry(Integer port) { restart(port); return (Registry) registry.get(port); } private static void startRegistry(Integer port) throws RemoteException { Registry r; try { r = LocateRegistry.createRegistry(port.intValue()); registry.put(port, r); //r = new sun.rmi.registry.RegistryImpl???????????????????????????? /// (port.intValue());?????????????????????????????????????? // registry.put(port, r);?????????????????????????????????????????? } catch (Exception e) { //e.printStackTrace();????????????????????????????????????????????? r = LocateRegistry.getRegistry(port.intValue()); registry.put(port, r); } } public static void main(String args[]) throws RemoteException { //restart(port);??????????????????????????????????????????????????????? restart(5001); restart(5002); restart(5002); Registry r = LocateRegistry.getRegistry(5002); System.out.println("registry="+r); } } I would very much like to get your feedback on this new design pattern idea. Thank you for your time. Regards, - Doug From david.garnier at trusted-logic.com Wed Mar 22 07:36:10 2006 From: david.garnier at trusted-logic.com (David Garnier) Date: Wed, 22 Mar 2006 15:36:10 +0100 Subject: [Rxtx] sole of a new design pattern In-Reply-To: References: Message-ID: <442160DA.80107@trusted-logic.com> Hello, > The Parametric Singleton Design Pattern The Singleton is the most abused design pattern ever. Good use-cases for this pattern are extremely rare and mostly confined to problems related to hardware resources, like serial ports. > Applicability > > Use the Parametric Singleton Design Pattern when: > 1. There must be exactly one instance of a class with the given > parameters. OK. As I said above, this case this actually very unusual. The Singleton pattern is mostly used when : > 2. The instances must be accessible to clients from a well-known > access point. Using the singleton pattern in this case is just convenient for the programmer. Problems arises pretty quickly, especially if you attempt to unit-test your classes. 1) If your singleton is stateful, or hold on to stateful objects, it means that two different unit tests are not actually independent. Instead of starting with a brand new environment, the result of a test may be affected by the result of a previous test. This problem also arise when with your class relies on a database. In both cases, the solution is to reset your "unique" resource (Singleton or database) at the beginning of the test, which is a pain. Also, while most projects connect to a single database, projects that allow the use of Singletons usually contain several of thems, and new ones may cropped up unnoticed. You quickly end up with test cases that only pass in a certain order, which is a royal pain. 2) You cannot mockup a singleton. Once everyone calls the SomeSingleton class statically, you can't replace your class by SomeSingletonMockup. Furthermore, even for hardware services, the Singleton pattern does not really prevent concurrent accesses. If you start the same program in two different JVMs, unless they somehow shared the state of their "Singletons" (through lock files for example), the Singleton pattern will not prevent concurrent access. Our application uses RXTX, and we routinely encounter cases where another (native) application has already locked the port. Since we cannot modify the native application to recognize lock files, OS-level control is irreplaceable. > > Consequences > The Parametric Singleton Design Pattern has several benefits: > > 1. Controlled access to parametrically defined instances. Since > the Parametric Singleton class encapsulates its instances, there is > control over how and when clients access it. Not really. Once you've returned the instance to a client, you've lost control over it. The client can to whatever it wants with it. You cannot "recall" the instance or claim it back. > 2. Reduced name space. The Parametric Singleton pattern avoids > global variables that store instances created from the same parameter. Sure, but you don't have to rely on a Singleton for that. Just create a single Factory. > I would very much like to get your feedback on this new design > pattern idea. Well, it's nothing new. Some may say that it is the point of design patterns: formalizes the designs that occur again and again. However, this design is simply a combination of the Singleton and Factory patterns. I did use it in the past, but now I've been exposed to the shortcomings of the Singleton pattern, so I limit myself to Factories. Regards, David From sean_montgomery at baseview.com Wed Mar 22 08:35:28 2006 From: sean_montgomery at baseview.com (Sean Montgomery) Date: Wed, 22 Mar 2006 10:35:28 -0500 Subject: [Rxtx] sole of a new design pattern In-Reply-To: <442160DA.80107@trusted-logic.com> References: <442160DA.80107@trusted-logic.com> Message-ID: <05769CA7-A51B-4CF0-BAA0-E02DD905F5A4@baseview.com> On Mar 22, 2006, at 9:36 AM, David Garnier wrote: > Furthermore, even for hardware services, the Singleton pattern does > not really prevent concurrent > accesses. If you start the same program in two different JVMs, > unless they somehow shared the state > of their "Singletons" (through lock files for example), the > Singleton pattern will not prevent > concurrent access. > Multiple class loaders in a single JVM can be tricky, too. Then there's synchronization, lazy initialization and serialization of singletons to contend with. Bloch's Effective Java covers these, and here's a few articles: http://www.javaworld.com/javaworld/jw-04-2003/jw-0425-designpatterns- p3.html http://java.sun.com/developer/technicalArticles/Programming/singletons/ Just FYI :-) From lyon at docjava.com Wed Mar 22 08:50:48 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Wed, 22 Mar 2006 10:50:48 -0500 Subject: [Rxtx] sole of a new design pattern In-Reply-To: <442160DA.80107@trusted-logic.com> References: <442160DA.80107@trusted-logic.com> Message-ID: Hi All, First, I would like to thank David for his prompt and thoughtful remarks. I had no idea people that feel strongly about a design patterns! Wow! Feedback (particularly critical feedback) is greatly appreciated. Starting at the end, first: >I did use it in >the past, but now I've been exposed to the shortcomings of the >Singleton pattern, so I limit myself to Factories. David, if I understood your comments correctly, you suggested that Factories can be used in leu of the Singleton Design Pattern, or even the Parametric Singleton Design Pattern. As I see in [Gof]: Factory Method: Intent "Define an interface for creating an object, but let subclasses decide which class to instantiate. Factory Method lets a class defer instantiation to subclasses." The Singleton Design Pattern is a concrete class, which is rather different, right? Also, subclasses are not permitted with Singleton, as they are final. Naturally, I could use an abstract factory as a parent for a singleton. I could even design a facade that could be implemented with the singleton....but that is not the intention of the design. Unless you want a mock-up, as discussed, below: More below: >Hello, > >> The Parametric Singleton Design Pattern > >The Singleton is the most abused design pattern ever. Good use-cases >for this pattern are extremely >rare and mostly confined to problems related to hardware resources, >like serial ports. > > >> Applicability >> >> Use the Parametric Singleton Design Pattern when: >> 1. There must be exactly one instance of a class with the given >> parameters. >OK. As I said above, this case this actually very unusual. The >Singleton pattern is mostly used when : >> 2. The instances must be accessible to clients from a well-known >> access point. > >Using the singleton pattern in this case is just convenient for the >programmer. Problems arises >pretty quickly, especially if you attempt to unit-test your classes. > >1) If your singleton is stateful, or hold on to stateful objects, it >means that two different unit >tests are not actually independent. Instead of starting with a brand >new environment, the result of >a test may be affected by the result of a previous test. This >problem also arise when with your >class relies on a database. In both cases, the solution is to reset >your "unique" resource >(Singleton or database) at the beginning of the test, which is a >pain. Also, while most projects >connect to a single database, projects that allow the use of >Singletons usually contain several of >thems, and new ones may cropped up unnoticed. You quickly end up >with test cases that only pass in a >certain order, which is a royal pain. There are basic problems with communicating finite state machines that include reachability and deadlock analysis. These are addressed with petri net analysis and are beyond the scope of the design pattern. As you quite rightly pointed out; the parametric singleton pattern (or the singleton pattern, for that matter) enable multiple threads to gain access to the same instance. The only way that I can see to block others from gaining access to the reference is the synchronize keyword. This is putting a spin-lock (or MUTEX) on the reference. The question of how to unit-test a design pattern like the parametric singleton remains open. Perhaps this is a deficiency. > >2) You cannot mockup a singleton. Once everyone calls the >SomeSingleton class statically, you can't >replace your class by SomeSingletonMockup. Acutally, I am not sure that this is true. If the Singleton implements a Facade interface, it should be possible to make the replacement. Right? > >Furthermore, even for hardware services, the Singleton pattern does >not really prevent concurrent >accesses. If you start the same program in two different JVMs, >unless they somehow shared the state >of their "Singletons" (through lock files for example), the >Singleton pattern will not prevent >concurrent access. Good Point!! You have sharp eyes! The singleton design pattern should/could take responsibility for this. In fact, you may notice that my code does have an implementation (LocateRegistry) that can work across JVM's. The LocateRegistry will even work across the Internet! LocateRegistry takes both a host name and a Port (lock files just don't do this). I did not think to implement this beyond the local machine, but, in its present form, it will work across different processes. > >Our application uses RXTX, and we routinely encounter cases where >another (native) application has >already locked the port. Since we cannot modify the native >application to recognize lock files, >OS-level control is irreplaceable. The singleton design pattern is not meant to replace OS-level control, but to centralize the Java programmers access to it. If lock files, for example, are used for serial ports, the Singleton Design Pattern should be able to work with them. > > >> >> Consequences >> The Parametric Singleton Design Pattern has several benefits: >> > > 1. Controlled access to parametrically defined instances. Since >> the Parametric Singleton class encapsulates its instances, there is >> control over how and when clients access it. > >Not really. Once you've returned the instance to a client, you've >lost control over it. The client >can to whatever it wants with it. You cannot "recall" the instance >or claim it back. Good point, this should read: > 1. Controll when parametrically defined instances are created. Since > > the Parametric Singleton class encapsulates its instances, there is > > control over how and when they are instanced. > >> 2. Reduced name space. The Parametric Singleton pattern avoids >> global variables that store instances created from the same parameter. > >Sure, but you don't have to rely on a Singleton for that. Just >create a single Factory. > > Thank you for your thoughtful and prompt response! Regards, - Doug From dmarkman at mac.com Wed Mar 22 21:21:55 2006 From: dmarkman at mac.com (Dmitry Markman) Date: Wed, 22 Mar 2006 23:21:55 -0500 Subject: [Rxtx] sole of a new design pattern In-Reply-To: <442160DA.80107@trusted-logic.com> References: <442160DA.80107@trusted-logic.com> Message-ID: I don't think I get it On Mar 22, 2006, at 9:36 AM, David Garnier wrote: > Using the singleton pattern in this case is just convenient for the > programmer. Problems arises > pretty quickly, especially if you attempt to unit-test your classes. so you're saying that something isn't so good because you can not test it in the convenient way? if that's true, I'm totally disagree change your test, debug whatever, but if software is efficient at runtime, works fine and only problem is some unit test (which is some kind of framework for testing) then dump that unit test , dump that unit framework and make something appropriate to the software you're testing so if Douglas want to use singletons, what's the problem? and what do you mean by abusing of singleton usage? of course singleton doesn't prevent concurrent access to the resource across the processes unless you're using some OS facility to prevent it, besides singleton as it was introduced is relevant only and only inside of the same process otherwise it's not singleton it's something else (let's say network singleton: so you have remote invocation facility and some factory method that return object created by that facility) I don't have any problem with using any kind of singletons. Parametric Singleton idea (if I understand it right) could be easily implemented in the following way: use a map populate map with instances of some class and key is your parameter (you can use lazy population too) if somebody ask the key check the value if it's null so resource is taken if somebody returns the resource put it back to the map public synchronized static Object getSomeResource(Object parameter); public synchronized static void returnResource(Object parameter); getSomeResource (inside of the same process) could return null in 2 cases 1. if somebody (from other thread for example) already took that resource 2. if OS API said that resource corresponded to that parameter (serial port with parameter = 1 (port #)) is locked and unavailable; I'm not sure that in case of serial ports we even need those Parametric Singletons (unless lock checking is a very expensive operation) just ask the OS about availability of that resource and if it's available give it away and then OS will lock it and therefore in next time somebody ask it just answer that resource is locked and return null for example system has 2 serial ports available so I ask getResource("tty"); or I ask getResource("Bluetooth-Modem"); and if OS is ok you can give tty or Bluetooth-Modem or both no need for any additional pattern I think back to the problem mac os x doesn't recognize locking via files, so it handles locking via some API an instance of the singleton in each process should recognize that resource is locked (by using that API) that's all we don't have to make things more complicate then they are just because there is some nice design pattern or nice unit test framework or whatever keep things simple, make them work fast, don't introduce middle layers unless you have really good reason to do so of course I could be entirely wrong, so sorry about that in advance thanks Dmitry Markman From tjarvi at qbang.org Wed Mar 22 22:31:41 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 22 Mar 2006 22:31:41 -0700 (MST) Subject: [Rxtx] sole of a new design pattern In-Reply-To: References: Message-ID: Hi Doug Interesting reading. So far I'm just reading and thinking. I have one question so far. " Clients obtain a reference to a Parametric Singleton instance only through the parametric singleton design pattern. If the instance is left in an improper state (e.g., the serial port was left open) it is NOT the role of the Parametric Singleton Design Pattern to close the IO port. Nor is it the role of the Parametric Singleton Design Pattern to open the port. That role is delegate to some other part of the system. " So when the clients obtain a reference to the singleton, can they assume the port is there? IE, would it be the singletons role to handle things like USB dongles being removed with event hints comming from the underlying OS. Hardware abstraction layer/HAL on Linux is an example of underlying OS events. I assume that role too is delegated to other parts of the system? -- Trent Jarvi tjarvi at qbang.org From lyon at docjava.com Thu Mar 23 08:10:33 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Thu, 23 Mar 2006 10:10:33 -0500 Subject: [Rxtx] Classes don't need goals, they need roles! In-Reply-To: References: Message-ID: Hi Trent, Yes, I think that the role of the Parametric Singleton Pattern is not to open or close serial ports, nor is it to perform error checking. On the other hand, if you were to combine the role of the Parametric Singleton Pattern with another role (like that of error checking) it might not be amiss. However, I generally caution programmers against adding multiple roles to classes, as this leads to monolithic designs. Thus a different class (NativeLibDetect) could have the role of determining if the native library can be loaded. Another class (SerialPortBean) can have the role of serializing the default state of the serial port, so that it can be recovered, from user preferences, at a later time. The SerialPortDetect could have the role of determining if the serial port is removed (i.e., a USB port was unplugged). My guess is that each class should have a different role in the system, in order to ease maintenance and testing...but I could be wrong about that. Thanks! - Doug >Hi Doug > >Interesting reading. So far I'm just reading and thinking. I have >one question so far. > >" > Clients obtain a reference to a Parametric Singleton instance only >through the parametric singleton design pattern. If the instance is >left in an improper state (e.g., the serial port was left open) it is >NOT the role of the Parametric Singleton Design Pattern to close the >IO port. Nor is it the role of the Parametric Singleton Design Pattern >to >open the port. That role is delegate to some other part of the system. >" > >So when the clients obtain a reference to the singleton, can they >assume the port is there? IE, would it be the singletons role to >handle things like USB dongles being removed with event hints >comming from the underlying OS. Hardware abstraction layer/HAL on >Linux is an example of underlying OS events. > >I assume that role too is delegated to other parts of the system? > >-- >Trent Jarvi >tjarvi at qbang.org >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From maximulo at yahoo.com Fri Mar 24 01:22:38 2006 From: maximulo at yahoo.com (Maximulo Majir) Date: Fri, 24 Mar 2006 00:22:38 -0800 (PST) Subject: [Rxtx] JavaPOS Message-ID: <20060324082238.66371.qmail@web38214.mail.mud.yahoo.com> Hi all! Hello Trent! From what i understand, RXTX or JavaComm APIs were not created solely for JavaPOS. In JavaPOS, we have the virtual method claim() which is separate from open(), but in our RXTX API, claiming is done every call to open(), we cant open the port if its claimed by another application. Would it be alright to suggest or ask to create a new method called claim(..)? Is there such thing as forceclaim() in RXTX? this could be the same as portownership transfer or its equivalent. ForceClaim is in JSR80. Do you have some samples using RXTX as the lower layer for the Device Service Objects in JavaPOS? I have tried it, i just want to compare. Thank you all! maxim __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060324/496adba2/attachment-0038.html From tjarvi at qbang.org Fri Mar 24 11:28:19 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 24 Mar 2006 11:28:19 -0700 (MST) Subject: [Rxtx] Re: RXTX 2.1 Solaris Problems In-Reply-To: <3691.1143210578@www045.gmx.net> References: <3691.1143210578@www045.gmx.net> Message-ID: On Fri, 24 Mar 2006, Andreas Guenther wrote: > Hi all, > > the solaris problem was not the lock file only. > > Ok, I had to create the directory /var/spool/locks myself. > /var/spool/uucp exists. > > But rxtx didn't find any port. > > I compiled the source with my own debug-informations > and I tried to isolate the problem. > > The problem is the testRead-call in SerialImp.c > > JNIEXPORT jboolean JNICALL RXTXCommDriver(testRead)( > > ... > if ( READ( fd, &c, 1 ) < 0 ) > { > if ( errno != EAGAIN ) { > report( "testRead() read failed\n" ); > ret = JNI_FALSE; > } > } > Thanks Andreas I'm packing up to move. I'll be more or less away for a couple weeks here. I'll be checking email but my workstation is going into a box soon. This isn't hard to fix as this port should be enumerated when EWOULDBLOCK is recieved. Thats error is OK for enumeration just as EAGAIN is. I've put the bug into bugzilla so we dont forget to get to it. http://bugzilla.qbang.org/show_bug.cgi?id=42 You can add yourself to the CC list if you wish to test fixes we provide or even put a patch into bugzilla yourself. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Fri Mar 24 11:51:52 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 24 Mar 2006 11:51:52 -0700 (MST) Subject: [Rxtx] JavaPOS In-Reply-To: <20060324082238.66371.qmail@web38214.mail.mud.yahoo.com> References: <20060324082238.66371.qmail@web38214.mail.mud.yahoo.com> Message-ID: On Fri, 24 Mar 2006, Maximulo Majir wrote: > Hi all! Hello Trent! > > > From what i understand, RXTX or JavaComm APIs were not > created solely for JavaPOS. In JavaPOS, we have the virtual method > claim() which is separate from open(), but in our RXTX API, claiming is > done every call to open(), we cant open the port if its claimed by > another application. Would it be alright to suggest or ask to create a > new method called claim(..)? Is there such thing as forceclaim() in > RXTX? this could be the same as portownership transfer or its > equivalent. ForceClaim is in JSR80. > Do you have some samples using RXTX as the lower layer for the Device > Service Objects in JavaPOS? I have tried it, i just want to compare. > maxim Hi Maxim JSR80 is the USB API IBM/Sun put together. The problem is they have a richer kernel/API underneath that can handle such things. With Serial Ports, there isnt anything there other than an ioctl that says don't let anyone touch this and lockfiles that are more of a 'lets be nice.' At times we may be using USB ports but it is through the termios layer with the limitations mentioned. The advantage is that not only USB will work with rxtx. Anything that has a termios layer should work (to the extent that termios layer is complete). I don't know how forceclaim() would help you. Lets say someone has a programmer working on /dev/ttyS0 and you take it. Now you both race each other to read data first. There isn't a mechanism I know of that will solve this problem in termios. The most obvious test being a native app and a Java app trying to take the port. There is the potential of requestion ownership from other Java Applications but the use for that is very rare. Did you have something more specific in mind that I'm missing? I'm not sure that claim() and forceclaim() would help you with rxtx other than maybe locking the port with claim() without opening it. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sat Mar 25 23:42:08 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 25 Mar 2006 23:42:08 -0700 (MST) Subject: [Rxtx] Serial snoop Message-ID: I was reading the Linux kernel mail-list tonight and ran past a thread that mentioned sersnoop. This looks like a handy tool for people dealing with new toys. "a simple command-line tool for linux that echoes bytes to and from any two serial ports, ptys, or network sockets, and prints all traffic to stdout, in hex and ascii." http://www.restivo.org/projects/sersnoop/ It works on Linux only at this time (debian package available). -- Trent Jarvi tjarvi at qbang.org From beat.arnet at gmail.com Sun Mar 26 07:32:35 2006 From: beat.arnet at gmail.com (Beat Arnet) Date: Sun, 26 Mar 2006 09:32:35 -0500 Subject: [Rxtx] Error 0x5 at /home/bob/foo/tar/rxtx-2.1-7/build/../src/termios.c(860): Access is, denied. Message-ID: <4426A603.80508@gmail.com> Dear all, When trying to open the serial port, I sometimes (not always) run into the following exception (when opening the serialPort): Error 0x5 at /home/bob/foo/tar/rxtx-2.1-7/build/../src/termios.c(860): Access is denied. java.lang.UnsatisfiedLinkError: native_psmisc_report_owner at gnu.io.CommPortIdentifier.native_psmisc_report_owner(Native Method) at gnu.io.CommPortIdentifier.open(CommPortIdentifier.java:354) at codeskin.tools.CLLoader.open(CLLoader.java:79) at codeskin.tools.C2000Programmer.run(C2000Programmer.java:220) at java.lang.Thread.run(Unknown Source) Is this the type of error where I should just try to open the port again, or can it be avoided? Regards, Beat From tjarvi at qbang.org Sun Mar 26 11:40:12 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 26 Mar 2006 11:40:12 -0700 (MST) Subject: [Rxtx] Error 0x5 at /home/bob/foo/tar/rxtx-2.1-7/build/../src/termios.c(860): Access is, denied. In-Reply-To: <4426A603.80508@gmail.com> References: <4426A603.80508@gmail.com> Message-ID: On Sun, 26 Mar 2006, Beat Arnet wrote: > Dear all, > > When trying to open the serial port, I sometimes (not always) run into > the following exception (when opening the serialPort): > > Error 0x5 at /home/bob/foo/tar/rxtx-2.1-7/build/../src/termios.c(860): > Access is > denied. > > java.lang.UnsatisfiedLinkError: native_psmisc_report_owner > at gnu.io.CommPortIdentifier.native_psmisc_report_owner(Native > Method) > at gnu.io.CommPortIdentifier.open(CommPortIdentifier.java:354) > at codeskin.tools.CLLoader.open(CLLoader.java:79) > at codeskin.tools.C2000Programmer.run(C2000Programmer.java:220) > at java.lang.Thread.run(Unknown Source) > > Is this the type of error where I should just try to open the port again, > or can it be avoided? > Hi Beat We did a second build of rxtx 2.1-7 to resolve that unsatisfied link error. It should work now. rxtx is trying to tell you it thinks someone else has the serial port open. You can try to open the port again but maybe you already have a copy of the program running when it happens? ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7r2.zip fixed build. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sun Mar 26 11:44:23 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 26 Mar 2006 11:44:23 -0700 (MST) Subject: [Rxtx] RXTX spec file (fwd) Message-ID: This is probably interesting for fedora/suse users. ---------- Forwarded message ---------- Date: Sun, 26 Mar 2006 16:25:45 +0200 To: taj at www.linux.org.uk Subject: RXTX spec file I send you this spec file which allows to create a RPM for Fedora 4, 5 (x86, x86_64) with Java Sun. -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: rxtx.spec Url: http://mailman.qbang.org/pipermail/rxtx/attachments/20060326/6c7b6af6/rxtx-0034.pl From tjarvi at qbang.org Sun Mar 26 23:42:59 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 26 Mar 2006 23:42:59 -0700 (MST) Subject: [Rxtx] Upcomming events. Message-ID: This Wednesday we will be announcing a new "Maintainer" for the rxtx project. The position is more like neutral leader. I wont be going away or doing less. This is just the right thing to do as it turns out the two people with CVS write access will be at the same company. We need a third and we need neutrality. The maintainer will have final say in any conflict and will try to be neutral. It will be open for discussion. Then we will do it :) I'll still do most of the footwork I do now. But. I'm falling behind. I should have gone through the mail-list and posted the next round of changes this weekend. I'm packing to move and its going so so - 13 years of toys collected. I suspect there will be a dead period on my part (a couple weeks) comming up. But if you get it on the mail-list, we will get it in if there are no objections. I may well not be reading the mail-list during this period as I look for a house and many other things. I hope everyone will help out. Thanks -- Trent Jarvi tjarvi at qbang.org From mahmoud_hadad at yahoo.com Sun Mar 26 07:31:19 2006 From: mahmoud_hadad at yahoo.com (ronan nick) Date: Sun, 26 Mar 2006 06:31:19 -0800 (PST) Subject: [Rxtx] a question about the COMM API Message-ID: <20060326143119.54919.qmail@web60014.mail.yahoo.com> hi, i was intrested in knowing how i can communicate with my internal modem using java? for example if i want to make a phone dialer application or a caller id application where should i be looking at? and as i understood the COMM API is for devices that is attached to the computer through serial ports. --------------------------------- New Yahoo! Messenger with Voice. Call regular phones from your PC and save big. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060326/ce8329f0/attachment-0036.html From dmarkman at mac.com Mon Mar 20 00:20:43 2006 From: dmarkman at mac.com (Dmitry Markman) Date: Mon, 20 Mar 2006 02:20:43 -0500 Subject: [Rxtx] Mac OS X RXTX java installer In-Reply-To: References: <07D0DE29-BA32-4CFE-B036-66BC6423D385@buechse.de> <441AE3E0.2030503@willicon.de> <12531986.1142622114996.JavaMail.dmarkman@mac.com> <441B2674.9010409@willicon.de> <13577405.1142634732776.JavaMail.dmarkman@mac.com> <441B4182.8010407@willicon.de> <92CD0D6C-5BE8-426E-A46D-99452059FF49@mac.com> <441BBB2D.8030305@willicon.de> <441C4088.5090905@willicon.de> Message-ID: <64BC1E23-FDDE-4CE6-8863-CFC881CBC224@mac.com> Hi all I put RXTX installer that will install everything (and will create / var/lock if necessary and add user to the uucp group) for mac os x from Java into the rxtx's CVS repository it could be easily modified to install files for any platform it uses Greg Guerin's AuthKit for authentication and authorization Greg released that kit under artistic license, so Trent, please take a look we, probably, can negotiate license with Greg if it's necessary Greg's AuthKit could be downloaded from http://www.amug.org/~glguerin/ sw/#authkit Michael Hall (mikehall at spacestar dot net) had a suggestion to make implementation of the jaas LoginModule based on Greg's AuthKit (his modification of the Greg's AuthKit could be found at http:// www.spacestar.net/users/mikehall/authkit.dmg) but Michael's AuthKitLoginModule does only half a job: it does authenticate but it can not run any external unix process in privileged mode (at least I wasn't able to do so) possible explanation could be found in conversation between Greg and Michael at Apple's java-dev list (look for archives) so I didn't use jaas API for rxtxinstaller I created folder MacOSX in the contrib folder comment 1. if you want to run that installer as standalone application all you need that RXTXInstaller.jar 2. if you want to use webstart you have to add Greg's libAuthKit.jnilib to the mac os x's resources in theory RXTXInstaller.jar doesn't need it, but there is a problem with loading libAuthKit.jnilib from webstart authkit uses loadLibrary method to load library and it failed (from webstart) for standalone application I extract libAuthKit.jnilib from the RXTXInstaller.jar and put it into the /Library/Java/Extensions or ~/Library/Java/Extensions folder that file will be deleted after installer quit unfortunately I didn't have time to put documentation there but it is mostly self-explanatory I took installer code from my gl4java installer that I did about 3 years ago (with small modifications) it would be very nice if Apple will release LoginModule that really will do the job (com.apple.security.auth.module package????? ) (UnixLoginModule is pretty useless) From lyon at docjava.com Mon Mar 20 06:34:39 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Mon, 20 Mar 2006 08:34:39 -0500 Subject: [Rxtx] Mac OS X RXTX java installer In-Reply-To: <64BC1E23-FDDE-4CE6-8863-CFC881CBC224@mac.com> References: <07D0DE29-BA32-4CFE-B036-66BC6423D385@buechse.de> <441AE3E0.2030503@willicon.de> <12531986.1142622114996.JavaMail.dmarkman@mac.com> <441B2674.9010409@willicon.de> <13577405.1142634732776.JavaMail.dmarkman@mac.com> <441B4182.8010407@willicon.de> <92CD0D6C-5BE8-426E-A46D-99452059FF49@mac.com> <441BBB2D.8030305@willicon.de> <441C4088.5090905@willicon.de> <64BC1E23-FDDE-4CE6-8863-CFC881CBC224@mac.com> Message-ID: Hi Dimitry, This sounds like great work. Just a couple of questions; After the check out of the CVS files, using: setenv CVSROOT :pserver:anonymous at cvs.milestonesolutions.com:/usr/local/cvsroot 53 8:28 setenv PASSWORD mousy 54 8:29 cvs login 55 8:29 cvs checkout rxtx-devel I cd'd over to: rxtx-devel/MACOSX_IDE And found: CVS/ CW/ ForPackageMaker/ PB/ Where is the installer? Thanks! - Doug From tjarvi at qbang.org Mon Mar 20 06:39:37 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 20 Mar 2006 06:39:37 -0700 (MST) Subject: [Rxtx] Mac OS X RXTX java installer In-Reply-To: References: <07D0DE29-BA32-4CFE-B036-66BC6423D385@buechse.de> <441AE3E0.2030503@willicon.de> <12531986.1142622114996.JavaMail.dmarkman@mac.com> <441B2674.9010409@willicon.de> <13577405.1142634732776.JavaMail.dmarkman@mac.com> <441B4182.8010407@willicon.de> <92CD0D6C-5BE8-426E-A46D-99452059FF49@mac.com> <441BBB2D.8030305@willicon.de> <441C4088.5090905@willicon.de> <64BC1E23-FDDE-4CE6-8863-CFC881CBC224@mac.com> Message-ID: On Mon, 20 Mar 2006, Dr. Douglas Lyon wrote: > Hi Dimitry, > This sounds like great work. Just a couple of questions; > After the check out of the CVS files, using: > setenv CVSROOT > :pserver:anonymous at cvs.milestonesolutions.com:/usr/local/cvsroot > 53 8:28 setenv PASSWORD mousy > 54 8:29 cvs login > 55 8:29 cvs checkout rxtx-devel Hi Doug You want "cvs checkout -r commapi-0-0-1 rxtx-devel" to get RXTX 2.1 The default branch is rxtx 2.0 which isn't very active right now. -- Trent Jarvi tjarvi at qbang.org From lyon at docjava.com Mon Mar 20 07:05:44 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Mon, 20 Mar 2006 09:05:44 -0500 Subject: [Rxtx] Mac OS X RXTX java installer In-Reply-To: References: <07D0DE29-BA32-4CFE-B036-66BC6423D385@buechse.de> <441AE3E0.2030503@willicon.de> <12531986.1142622114996.JavaMail.dmarkman@mac.com> <441B2674.9010409@willicon.de> <13577405.1142634732776.JavaMail.dmarkman@mac.com> <441B4182.8010407@willicon.de> <92CD0D6C-5BE8-426E-A46D-99452059FF49@mac.com> <441BBB2D.8030305@willicon.de> <441C4088.5090905@willicon.de> <64BC1E23-FDDE-4CE6-8863-CFC881CBC224@mac.com> Message-ID: Hi Trent, Thanks for the info on the CVS checkout procedure. I did that and am still not sure where the installer is. Here is what I have: cd MACOSX_IDE/ p4.docjava.com{lyon}121: ls CVS/ ForPackageMaker/ PB/ p4.docjava.com{lyon}122: find . | more . ./ForPackageMaker ./ForPackageMaker/RXTX.pkg.sit.hqx ./ForPackageMaker/Resources ./ForPackageMaker/Resources/ReadMe.rtf ./ForPackageMaker/Resources/Welcome.rtf ./ForPackageMaker/Resources/CVS ./ForPackageMaker/Resources/CVS/Entries ./ForPackageMaker/Resources/CVS/Repository ./ForPackageMaker/Resources/CVS/Tag ./ForPackageMaker/Resources/CVS/Root ./ForPackageMaker/Resources/preinstall ./ForPackageMaker/Resources/License.rtf ./ForPackageMaker/Resources/preupgrade ./ForPackageMaker/RXTX.pmsp ./ForPackageMaker/CVS ./ForPackageMaker/CVS/Entries ./ForPackageMaker/CVS/Repository ./ForPackageMaker/CVS/Entries.Log ./ForPackageMaker/CVS/Tag ./ForPackageMaker/CVS/Root ./ForPackageMaker/RXTX_Tiger.pkg.sitx.hqx ./ForPackageMaker/RXTX_Jag.pkg.sit.hqx ./ForPackageMaker/Install ./ForPackageMaker/Install/CVS ./ForPackageMaker/Install/CVS/Entries ./ForPackageMaker/Install/CVS/Repository ./ForPackageMaker/Install/CVS/Tag ./ForPackageMaker/Install/CVS/Root ./ForPackageMaker/Install/Library ./ForPackageMaker/Install/Library/CVS ./ForPackageMaker/Install/Library/CVS/Entries ./ForPackageMaker/Install/Library/CVS/Repository ./ForPackageMaker/Install/Library/CVS/Tag ./ForPackageMaker/Install/Library/CVS/Root ./ForPackageMaker/Install/Library/Java ./ForPackageMaker/Install/Library/Java/Extensions ./ForPackageMaker/Install/Library/Java/Extensions/RXTXcomm.jar ./ForPackageMaker/Install/Library/Java/Extensions/CVS ./ForPackageMaker/Install/Library/Java/Extensions/CVS/Entries ./ForPackageMaker/Install/Library/Java/Extensions/CVS/Repository ./ForPackageMaker/Install/Library/Java/Extensions/CVS/Tag ./ForPackageMaker/Install/Library/Java/Extensions/CVS/Root ./ForPackageMaker/Install/Library/Java/Extensions/librxtxSerial.jnilib ./ForPackageMaker/Install/Library/Java/CVS ./ForPackageMaker/Install/Library/Java/CVS/Entries ./ForPackageMaker/Install/Library/Java/CVS/Repository ./ForPackageMaker/Install/Library/Java/CVS/Entries.Log ./ForPackageMaker/Install/Library/Java/CVS/Tag ./ForPackageMaker/Install/Library/Java/CVS/Root ./ForPackageMaker/RXTX_Tiger.pmproj.sitx.hqx ./CVS ./CVS/Entries ./CVS/Repository ./CVS/Entries.Log ./CVS/Tag ./CVS/Root ./PB ./PB/LibSerialUniversal.xcodeproj.sitx.hqx ./PB/CVS ./PB/CVS/Entries ./PB/CVS/Repository ./PB/CVS/Entries.Log ./PB/CVS/Tag ./PB/CVS/Root ./PB/LibSerial.pbproj.sit.hqx ./PB/startpoint.c ./PB/config.h What is the procedure to run this installer? Do we need a README in: /rxtx-devel/MACOSX_IDE Here is what we have: CVS/ ForPackageMaker/ PB/ Thanks! - DL >On Mon, 20 Mar 2006, Dr. Douglas Lyon wrote: > >>Hi Dimitry, >>This sounds like great work. Just a couple of questions; >>After the check out of the CVS files, using: >>setenv CVSROOT >>:pserver:anonymous at cvs.milestonesolutions.com:/usr/local/cvsroot >> 53 8:28 setenv PASSWORD mousy >> 54 8:29 cvs login >> 55 8:29 cvs checkout rxtx-devel > >Hi Doug > >You want "cvs checkout -r commapi-0-0-1 rxtx-devel" to get RXTX 2.1 >The default branch is rxtx 2.0 which isn't very active right now. > >-- >Trent Jarvi >tjarvi at qbang.org From tjarvi at qbang.org Mon Mar 20 07:25:30 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 20 Mar 2006 07:25:30 -0700 (MST) Subject: [Rxtx] Mac OS X RXTX java installer In-Reply-To: References: <07D0DE29-BA32-4CFE-B036-66BC6423D385@buechse.de> <441AE3E0.2030503@willicon.de> <12531986.1142622114996.JavaMail.dmarkman@mac.com> <441B2674.9010409@willicon.de> <13577405.1142634732776.JavaMail.dmarkman@mac.com> <441B4182.8010407@willicon.de> <92CD0D6C-5BE8-426E-A46D-99452059FF49@mac.com> <441BBB2D.8030305@willicon.de> <441C4088.5090905@willicon.de> <64BC1E23-FDDE-4CE6-8863-CFC881CBC224@mac.com> Message-ID: On Mon, 20 Mar 2006, Dr. Douglas Lyon wrote: > Hi Trent, > Thanks for the info on the CVS checkout procedure. > I did that and am still not sure where the installer is. Hi Doug It does look like it was not cvs committed. There is no rxtx-devel/contrib/MacOSX directory in there at the moment. It was mentioned that it was put under contrib. -- Trent Jarvi tjarvi at qbang.org From dmarkman at mac.com Mon Mar 20 07:29:56 2006 From: dmarkman at mac.com (Dmitry Markman) Date: Mon, 20 Mar 2006 09:29:56 -0500 Subject: [Rxtx] Mac OS X RXTX java installer In-Reply-To: References: <07D0DE29-BA32-4CFE-B036-66BC6423D385@buechse.de> <441AE3E0.2030503@willicon.de> <12531986.1142622114996.JavaMail.dmarkman@mac.com> <441B2674.9010409@willicon.de> <13577405.1142634732776.JavaMail.dmarkman@mac.com> <441B4182.8010407@willicon.de> <92CD0D6C-5BE8-426E-A46D-99452059FF49@mac.com> <441BBB2D.8030305@willicon.de> <441C4088.5090905@willicon.de> <64BC1E23-FDDE-4CE6-8863-CFC881CBC224@mac.com> Message-ID: <6054EB4E-F7E0-4A9C-BDDA-D582D6D8826F@mac.com> you can find it in the rxtx-devel/contrib folder On Mar 20, 2006, at 9:05 AM, Dr. Douglas Lyon wrote: > Hi Trent, > Thanks for the info on the CVS checkout procedure. > I did that and am still not sure where the installer is. > Here is what I have: > cd MACOSX_IDE/ > p4.docjava.com{lyon}121: ls > CVS/ ForPackageMaker/ PB/ > p4.docjava.com{lyon}122: find . | more > . > ./ForPackageMaker > ./ForPackageMaker/RXTX.pkg.sit.hqx > ./ForPackageMaker/Resources > ./ForPackageMaker/Resources/ReadMe.rtf > ./ForPackageMaker/Resources/Welcome.rtf > ./ForPackageMaker/Resources/CVS > ./ForPackageMaker/Resources/CVS/Entries > ./ForPackageMaker/Resources/CVS/Repository > ./ForPackageMaker/Resources/CVS/Tag > ./ForPackageMaker/Resources/CVS/Root > ./ForPackageMaker/Resources/preinstall > ./ForPackageMaker/Resources/License.rtf > ./ForPackageMaker/Resources/preupgrade > ./ForPackageMaker/RXTX.pmsp > ./ForPackageMaker/CVS > ./ForPackageMaker/CVS/Entries > ./ForPackageMaker/CVS/Repository > ./ForPackageMaker/CVS/Entries.Log > ./ForPackageMaker/CVS/Tag > ./ForPackageMaker/CVS/Root > ./ForPackageMaker/RXTX_Tiger.pkg.sitx.hqx > ./ForPackageMaker/RXTX_Jag.pkg.sit.hqx > ./ForPackageMaker/Install > ./ForPackageMaker/Install/CVS > ./ForPackageMaker/Install/CVS/Entries > ./ForPackageMaker/Install/CVS/Repository > ./ForPackageMaker/Install/CVS/Tag > ./ForPackageMaker/Install/CVS/Root > ./ForPackageMaker/Install/Library > ./ForPackageMaker/Install/Library/CVS > ./ForPackageMaker/Install/Library/CVS/Entries > ./ForPackageMaker/Install/Library/CVS/Repository > ./ForPackageMaker/Install/Library/CVS/Tag > ./ForPackageMaker/Install/Library/CVS/Root > ./ForPackageMaker/Install/Library/Java > ./ForPackageMaker/Install/Library/Java/Extensions > ./ForPackageMaker/Install/Library/Java/Extensions/RXTXcomm.jar > ./ForPackageMaker/Install/Library/Java/Extensions/CVS > ./ForPackageMaker/Install/Library/Java/Extensions/CVS/Entries > ./ForPackageMaker/Install/Library/Java/Extensions/CVS/Repository > ./ForPackageMaker/Install/Library/Java/Extensions/CVS/Tag > ./ForPackageMaker/Install/Library/Java/Extensions/CVS/Root > ./ForPackageMaker/Install/Library/Java/Extensions/librxtxSerial.jnilib > ./ForPackageMaker/Install/Library/Java/CVS > ./ForPackageMaker/Install/Library/Java/CVS/Entries > ./ForPackageMaker/Install/Library/Java/CVS/Repository > ./ForPackageMaker/Install/Library/Java/CVS/Entries.Log > ./ForPackageMaker/Install/Library/Java/CVS/Tag > ./ForPackageMaker/Install/Library/Java/CVS/Root > ./ForPackageMaker/RXTX_Tiger.pmproj.sitx.hqx > ./CVS > ./CVS/Entries > ./CVS/Repository > ./CVS/Entries.Log > ./CVS/Tag > ./CVS/Root > ./PB > ./PB/LibSerialUniversal.xcodeproj.sitx.hqx > ./PB/CVS > ./PB/CVS/Entries > ./PB/CVS/Repository > ./PB/CVS/Entries.Log > ./PB/CVS/Tag > ./PB/CVS/Root > ./PB/LibSerial.pbproj.sit.hqx > ./PB/startpoint.c > ./PB/config.h > > What is the procedure to run this installer? > Do we need a README in: > /rxtx-devel/MACOSX_IDE > Here is what we have: > CVS/ ForPackageMaker/ PB/ > > > Thanks! > - DL > >> On Mon, 20 Mar 2006, Dr. Douglas Lyon wrote: >> >>> Hi Dimitry, >>> This sounds like great work. Just a couple of questions; >>> After the check out of the CVS files, using: >>> setenv CVSROOT :pserver:anonymous at cvs.milestonesolutions.com:/usr/ >>> local/cvsroot >>> 53 8:28 setenv PASSWORD mousy >>> 54 8:29 cvs login >>> 55 8:29 cvs checkout rxtx-devel >> >> Hi Doug >> >> You want "cvs checkout -r commapi-0-0-1 rxtx-devel" to get RXTX 2.1 >> The default branch is rxtx 2.0 which isn't very active right now. >> >> -- >> Trent Jarvi >> tjarvi at qbang.org > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx Dmitry Markman From mikehall at spacestar.net Mon Mar 20 05:25:25 2006 From: mikehall at spacestar.net (Michael Hall) Date: Mon, 20 Mar 2006 06:25:25 -0600 Subject: [Rxtx] Re: Mac OS X RXTX java installer In-Reply-To: <64BC1E23-FDDE-4CE6-8863-CFC881CBC224@mac.com> References: <07D0DE29-BA32-4CFE-B036-66BC6423D385@buechse.de> <441AE3E0.2030503@willicon.de> <12531986.1142622114996.JavaMail.dmarkman@mac.com> <441B2674.9010409@willicon.de> <13577405.1142634732776.JavaMail.dmarkman@mac.com> <441B4182.8010407@willicon.de> <92CD0D6C-5BE8-426E-A46D-99452059FF49@mac.com> <441BBB2D.8030305@willicon.de> <441C4088.5090905@willicon.de> <64BC1E23-FDDE-4CE6-8863-CFC881CBC224@mac.com> Message-ID: <247EB61F-5CD1-4132-89A2-FC105B6CF9A5@spacestar.net> On Mar 20, 2006, at 1:20 AM, Dmitry Markman wrote: > > Michael Hall (mikehall at spacestar dot net) had a suggestion to > make implementation of the jaas LoginModule > based on Greg's AuthKit > (his modification of the Greg's AuthKit could be found at http:// > www.spacestar.net/users/mikehall/authkit.dmg) > but Michael's AuthKitLoginModule does only half a job: > it does authenticate > but it can not run any external unix process in privileged mode (at > least I wasn't able to do so) If you got it working directly with Greg's the point is moot. But to clarify it anyhow. The login module does not allow you to do anything anything privileged on return as was explained by Greg. You need to work with a separate privileged process using the execPrivileged method of his API. I assume you did something similar although I haven't looked at how you are using it yet. I allowed instead for a action to be performed at the same time you login/authenticate,this... System.setProperty("authkit.action","/usr/bin/id"); just before this... lc.login(); To clarify, safely ignored as you are already complete. Mike Hall mikehall at spacestar dot net http://www.spacestar.net/users/mikehall http://sourceforge.net/projects/macnative -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2427 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20060320/f6e18202/smime-0039.bin From dmarkman at mac.com Mon Mar 20 07:36:47 2006 From: dmarkman at mac.com (Dmitry Markman) Date: Mon, 20 Mar 2006 09:36:47 -0500 Subject: [Rxtx] Re: Mac OS X RXTX java installer In-Reply-To: <247EB61F-5CD1-4132-89A2-FC105B6CF9A5@spacestar.net> References: <07D0DE29-BA32-4CFE-B036-66BC6423D385@buechse.de> <441AE3E0.2030503@willicon.de> <12531986.1142622114996.JavaMail.dmarkman@mac.com> <441B2674.9010409@willicon.de> <13577405.1142634732776.JavaMail.dmarkman@mac.com> <441B4182.8010407@willicon.de> <92CD0D6C-5BE8-426E-A46D-99452059FF49@mac.com> <441BBB2D.8030305@willicon.de> <441C4088.5090905@willicon.de> <64BC1E23-FDDE-4CE6-8863-CFC881CBC224@mac.com> <247EB61F-5CD1-4132-89A2-FC105B6CF9A5@spacestar.net> Message-ID: Hi, Michael all I have to do is to run some shell script I tried to use your action mechanism and it worked great so I just System.setProperty ("authkit.action","" ) and after that I even don't need to run anything like subject.doAs.... but after few thoughts I choose to use plain Greg's approach, because in that case I don't have to deal with various java's configurations files and therefore to use 2-3 -D parameters in the java command line especially it's useful for java web start (it's so fragile :-( ) thanks for the great job On Mar 20, 2006, at 7:25 AM, Michael Hall wrote: > > On Mar 20, 2006, at 1:20 AM, Dmitry Markman wrote: >> >> Michael Hall (mikehall at spacestar dot net) had a suggestion to >> make implementation of the jaas LoginModule >> based on Greg's AuthKit >> (his modification of the Greg's AuthKit could be found at http:// >> www.spacestar.net/users/mikehall/authkit.dmg) >> but Michael's AuthKitLoginModule does only half a job: >> it does authenticate >> but it can not run any external unix process in privileged mode >> (at least I wasn't able to do so) > > If you got it working directly with Greg's the point is moot. > > But to clarify it anyhow. > The login module does not allow you to do anything anything > privileged on return as was explained by Greg. You need to work > with a separate privileged process using the execPrivileged method > of his API. I assume you did something similar although I haven't > looked at how you are using it yet. > I allowed instead for a action to be performed at the same time you > login/authenticate,this... > System.setProperty("authkit.action","/usr/bin/id"); > just before this... > lc.login(); > To clarify, safely ignored as you are already complete. > > Mike Hall mikehall at spacestar dot net > http://www.spacestar.net/users/mikehall > http://sourceforge.net/projects/macnative > > > Dmitry Markman From dmarkman at mac.com Mon Mar 20 07:44:45 2006 From: dmarkman at mac.com (Dmitry Markman) Date: Mon, 20 Mar 2006 09:44:45 -0500 Subject: [Rxtx] Mac OS X RXTX java installer In-Reply-To: References: <07D0DE29-BA32-4CFE-B036-66BC6423D385@buechse.de> <441AE3E0.2030503@willicon.de> <12531986.1142622114996.JavaMail.dmarkman@mac.com> <441B2674.9010409@willicon.de> <13577405.1142634732776.JavaMail.dmarkman@mac.com> <441B4182.8010407@willicon.de> <92CD0D6C-5BE8-426E-A46D-99452059FF49@mac.com> <441BBB2D.8030305@willicon.de> <441C4088.5090905@willicon.de> <64BC1E23-FDDE-4CE6-8863-CFC881CBC224@mac.com> Message-ID: it's in the commapi-0-0-1 branch I tested it right now: cvs co -r commapi-0-0-1 rxtx-devel and I got everything On Mar 20, 2006, at 9:25 AM, Trent Jarvi wrote: > On Mon, 20 Mar 2006, Dr. Douglas Lyon wrote: > >> Hi Trent, >> Thanks for the info on the CVS checkout procedure. >> I did that and am still not sure where the installer is. > > Hi Doug > > It does look like it was not cvs committed. There is no rxtx-devel/ > contrib/MacOSX directory in there at the moment. It was mentioned > that it was put under contrib. > > -- > Trent Jarvi > tjarvi at qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx Dmitry Markman From tjarvi at qbang.org Mon Mar 20 07:52:57 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 20 Mar 2006 07:52:57 -0700 (MST) Subject: [Rxtx] Mac OS X RXTX java installer In-Reply-To: References: <07D0DE29-BA32-4CFE-B036-66BC6423D385@buechse.de> <441AE3E0.2030503@willicon.de> <12531986.1142622114996.JavaMail.dmarkman@mac.com> <441B2674.9010409@willicon.de> <13577405.1142634732776.JavaMail.dmarkman@mac.com> <441B4182.8010407@willicon.de> <92CD0D6C-5BE8-426E-A46D-99452059FF49@mac.com> <441BBB2D.8030305@willicon.de> <441C4088.5090905@willicon.de> <64BC1E23-FDDE-4CE6-8863-CFC881CBC224@mac.com> Message-ID: On Mon, 20 Mar 2006, Dmitry Markman wrote: > it's in the commapi-0-0-1 branch > > I tested it right now: > cvs co -r commapi-0-0-1 rxtx-devel > > and I got everything > A fresh checkout worked. Here is a copy of the tree (just the installer bits) ftp://ftp.qbang.org/pub/rxtx/MacOSX-installer.zip -- Trent Jarvi tjarvi at qbang.org From lyon at docjava.com Mon Mar 20 08:08:26 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Mon, 20 Mar 2006 10:08:26 -0500 Subject: [Rxtx] Mac OS X RXTX java installer In-Reply-To: References: <07D0DE29-BA32-4CFE-B036-66BC6423D385@buechse.de> <441AE3E0.2030503@willicon.de> <12531986.1142622114996.JavaMail.dmarkman@mac.com> <441B2674.9010409@willicon.de> <13577405.1142634732776.JavaMail.dmarkman@mac.com> <441B4182.8010407@willicon.de> <92CD0D6C-5BE8-426E-A46D-99452059FF49@mac.com> <441BBB2D.8030305@willicon.de> <441C4088.5090905@willicon.de> <64BC1E23-FDDE-4CE6-8863-CFC881CBC224@mac.com> Message-ID: Hi All, Is the Auth package able to work properly on non Mac OS's? It was not clear from the doc or download. Thanks! - Doug From dmarkman at mac.com Mon Mar 20 08:15:22 2006 From: dmarkman at mac.com (Dmitry Markman) Date: Mon, 20 Mar 2006 10:15:22 -0500 Subject: [Rxtx] Mac OS X RXTX java installer In-Reply-To: References: <07D0DE29-BA32-4CFE-B036-66BC6423D385@buechse.de> <441AE3E0.2030503@willicon.de> <12531986.1142622114996.JavaMail.dmarkman@mac.com> <441B2674.9010409@willicon.de> <13577405.1142634732776.JavaMail.dmarkman@mac.com> <441B4182.8010407@willicon.de> <92CD0D6C-5BE8-426E-A46D-99452059FF49@mac.com> <441BBB2D.8030305@willicon.de> <441C4088.5090905@willicon.de> <64BC1E23-FDDE-4CE6-8863-CFC881CBC224@mac.com> Message-ID: <217312D8-CCCA-4859-ABA6-32DF1CC817B9@mac.com> thanks Trent, for putting it on ftp server On Mar 20, 2006, at 9:52 AM, Trent Jarvi wrote: > A fresh checkout worked. Here is a copy of the tree (just the > installer bits) > > ftp://ftp.qbang.org/pub/rxtx/MacOSX-installer.zip > Dmitry Markman From dmarkman at mac.com Mon Mar 20 09:14:03 2006 From: dmarkman at mac.com (Dmitry Markman) Date: Mon, 20 Mar 2006 11:14:03 -0500 Subject: [Rxtx] Mac OS X RXTX java installer In-Reply-To: References: <07D0DE29-BA32-4CFE-B036-66BC6423D385@buechse.de> <441AE3E0.2030503@willicon.de> <12531986.1142622114996.JavaMail.dmarkman@mac.com> <441B2674.9010409@willicon.de> <13577405.1142634732776.JavaMail.dmarkman@mac.com> <441B4182.8010407@willicon.de> <92CD0D6C-5BE8-426E-A46D-99452059FF49@mac.com> <441BBB2D.8030305@willicon.de> <441C4088.5090905@willicon.de> <64BC1E23-FDDE-4CE6-8863-CFC881CBC224@mac.com> Message-ID: <4DEBA6F0-DA45-4E84-823E-1F1AC48BDCCC@mac.com> no it will work only on mac os x however it's harmless to run it on other platform if you want to use it for other platform you have to do the following (I'll do it for linux) 1. modify RXTXInstaller class method public static RXTXInstaller getInstance() public static RXTXInstaller getInstance() { String osName = System.getProperty("os.name").toLowerCase(); if(osName.startsWith("mac")){ return new gnu.io.installer.macosx.MACOSXRXTXInstaller(); } else if(osName.startsWith("windows")){ return new gnu.io.installer.windows.WindowsRXTXInstaller(); }else if(osName.startsWith("linux")){ return new gnu.io.installer.linux.LinuxRXTXInstaller(); } return null; } 2. create folder gnu/io/installer/linux/ 3. create class Linux386RXTXInstaller package gnu.io.installer.linux; import java.io.File; public class Linux386RXTXInstaller extends gnu.io.installer.RXTXInstaller{ public Linux386RXTXInstaller(){ createJarFolder(); createLibFolder(); addJarResource("RXTXcomm.jar","/gnu/io/installer/resources/ linux/jar/RXTXcomm.dat"); addLibResource("librxtxSerial.so","/gnu/io/installer/ resources/linux/lib/librxtxSerial.so"); } protected void createJarFolder(){ String javaHome = System.getProperty("java.home"); char separator = File.separatorChar; jarFolder = new File(javaHome+separator+"lib"+separator+"ext"); } protected void createLibFolder(){ String javaHome = System.getProperty("java.home"); char separator = File.separatorChar; libFolder = new File(javaHome+separator+"bin"); } public void runPreProcess() {} //put here some action you need public void runPostProcess() {} //put here some action you need } 4. create folder /gnu/io/installer/resources/linux/jar and put there linux's version of RXTXcomm.dat (which is renamed RXTXcomm.jar) 5. create folder /gnu/io/installer/resources/linux/lib and put there linux's version of librxtxSerial. so 6. make sure that RXTXInstaller.jar has the following items: /gnu/io/installer/resources/linux/jar/RXTXcomm.jar /gnu/io/installer/resources/linux/lib/librxtxSerial.so 7. modify file installer.pref: jar file RXTXInstaller.jar must have the following item /gnu/io/installer/installer.pref that's basically it for windows you have to do the similar things: just replace linux to windows and librxtxSerial.so to rxtxSerial.dll and create appropriate gnu.io.installer.windows.WindowsRXTXInstaller class package gnu.io.installer.windows; import java.io.File; public class WindowsRXTXInstaller extends gnu.io.installer.RXTXInstaller{ public WindowsRXTXInstaller(){ createJarFolder(); createLibFolder(); addJarResource("RXTXcomm.jar","/gnu/io/installer/resources/ windows/jar/RXTXcomm.dat"); addLibResource("librxtxSerial.so","/gnu/io/installer/ resources/windows/lib/rxtxSerial.dll"); } protected void createJarFolder(){ String javaHome = System.getProperty("java.home"); char separator = File.separatorChar; jarFolder = new File(javaHome+separator+"lib"+separator+"ext"); } protected void createLibFolder(){ String javaHome = System.getProperty("java.home"); char separator = File.separatorChar; libFolder = new File(javaHome+separator+"bin"); } public void runPreProcess() {} //put here some action you need public void runPostProcess() {} //put here some action you need } installer.pref will look like On Mar 20, 2006, at 10:08 AM, Dr. Douglas Lyon wrote: > Hi All, > Is the Auth package able to work properly on > non Mac OS's? > It was not clear from the doc or download. > > Thanks! > - Doug > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx Dmitry Markman From joachim at buechse.de Mon Mar 20 10:49:06 2006 From: joachim at buechse.de (Joachim Buechse) Date: Mon, 20 Mar 2006 18:49:06 +0100 Subject: [Rxtx] BUG: Lock file stays even if port opening fails Message-ID: This was only tested on MacOSX but looking at the code, it should be true for all systems that use lock_uucp. I am opening a port which can not be opened (dialup port of a telephone paired via bluetooth but currently not reachable). The lock file is created and stays arround, even though the port open failed. After looking a bit through the code (of 2.17), I really wonder if it wouldn't be a good idea to make the "locking" an explicit operation called from the java code. This would certainly simplify the generation of meaningfull exceptions (and java based debugging). Maybe even the handling of "preopened" ports should be in the Java part of the lib (again for java based debugging puposes). That beeing said, I have no idea if this would be possible for the 2.07 implementation. Regards, Joachim From tjarvi at qbang.org Mon Mar 20 11:24:22 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 20 Mar 2006 11:24:22 -0700 (MST) Subject: [Rxtx] BUG: Lock file stays even if port opening fails In-Reply-To: References: Message-ID: On Mon, 20 Mar 2006, Joachim Buechse wrote: > This was only tested on MacOSX but looking at the code, it should be true > for all systems that use lock_uucp. > > I am opening a port which can not be opened (dialup port of a telephone > paired via bluetooth but currently not reachable). The lock file is > created and stays arround, even though the port open failed. > > > After looking a bit through the code (of 2.17), I really wonder if it > wouldn't be a good idea to make the "locking" an explicit operation > called from the java code. This would certainly simplify the generation > of meaningfull exceptions (and java based debugging). > Maybe even the handling of "preopened" ports should be in the Java part > of the lib (again for java based debugging puposes). That beeing said, I > have no idea if this would be possible for the 2.07 implementation. > > Regards, Hi Joachim It should be possible in the 2.0-7 implementation too. The calls to RXTXPort.java would not change. We would just do more there Moving more of that logic into Java would be better as many people don't like to look at C code. There is a liblockdev on most Linux distros that can do most of the C code and would be easier to use. The problem is embeded devices will not have that library. The preopened port code has not been really tested. That was a last minute request in a product cycle. I expect it will be tested this year though. As I recall, some devices really do not like CD raising on open. The preopened ports then allow people to mess around in java without power cycling the devices or losing data. -- Trent Jarvi tjarvi at qbang.org From joachim at buechse.de Mon Mar 20 12:01:08 2006 From: joachim at buechse.de (Joachim Buechse) Date: Mon, 20 Mar 2006 20:01:08 +0100 Subject: [Rxtx] BUG: Lock file stays even if port opening fails In-Reply-To: References: Message-ID: Hi Trent, What is your general feeling about moving code to Java? The last days I have been reading quite a bit of the code and there are several things, that might not work as expected. I'll give you two examples from is_device_locked: if LOCKDIR == /var/spool/locks the directory /var/spool/lock will not be checked. LOCKDIR is not checked for lockfiles with unexpected pefixes While these things have probably never been discovered in production, they are still possibly incorrect implementations. If it was Java code, I would write some unit tests producing the errors that could later be corrected. PS: One could imagine to actually implement the whole lockfile handling in Java using some native routines to get the values required (pid, st_dev, st_rdev, ...). On 20.03.2006, at 19:24, Trent Jarvi wrote: > On Mon, 20 Mar 2006, Joachim Buechse wrote: > >> This was only tested on MacOSX but looking at the code, it should >> be true for all systems that use lock_uucp. >> >> I am opening a port which can not be opened (dialup port of a >> telephone paired via bluetooth but currently not reachable). The >> lock file is created and stays arround, even though the port open >> failed. >> >> >> After looking a bit through the code (of 2.17), I really wonder if >> it wouldn't be a good idea to make the "locking" an explicit >> operation called from the java code. This would certainly simplify >> the generation of meaningfull exceptions (and java based debugging). >> Maybe even the handling of "preopened" ports should be in the Java >> part of the lib (again for java based debugging puposes). That >> beeing said, I have no idea if this would be possible for the 2.07 >> implementation. >> >> Regards, > > Hi Joachim > > It should be possible in the 2.0-7 implementation too. The calls > to RXTXPort.java would not change. We would just do more there > Moving more of that logic into Java would be better as many people > don't like to look at C code. There is a liblockdev on most Linux > distros that can do most of the C code and would be easier to use. > The problem is embeded devices will not have that library. > > The preopened port code has not been really tested. That was a > last minute request in a product cycle. I expect it will be tested > this year though. As I recall, some devices really do not like CD > raising on open. The preopened ports then allow people to mess > around in java without power cycling the devices or losing data. > > -- > Trent Jarvi > tjarvi at qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Mon Mar 20 12:21:02 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 20 Mar 2006 12:21:02 -0700 (MST) Subject: [Rxtx] BUG: Lock file stays even if port opening fails In-Reply-To: References: Message-ID: On Mon, 20 Mar 2006, Joachim Buechse wrote: > Hi Trent, > > What is your general feeling about moving code to Java? The last days I > have been reading quite a bit of the code and there are several things, > that might not work as expected. > > I'll give you two examples from is_device_locked: > > if LOCKDIR == /var/spool/locks the directory /var/spool/lock will not be > checked. > LOCKDIR is not checked for lockfiles with unexpected pefixes > > While these things have probably never been discovered in production, > they are still possibly incorrect implementations. If it was Java code, I > would write some unit tests producing the errors that could later be > corrected. > > PS: One could imagine to actually implement the whole lockfile handling > in Java using some native routines to get the values required (pid, > st_dev, st_rdev, ...). Hi Joachim I like the idea of moving more of the code into java but there are some things to consider. If you break this into multiple JNI calls, the performance will drop considerably during enumeration of ports. We are looking for 256 ports per dev type vs (16? in Sun's 2.0 and fewer types). Its hard to make assumptions. I've seen virtual ports start at /dev/foo100 for instance. It works out to over 7500 ports on Linux if you enable them all. We already trim that back by default. See Linux-all-ports in RXTXCommDriver.java. There are also native libraries that rxtx can link to. If you move too much into Java, linking to 'standard' libraries with distros will break. "configure --enable-liblock=yes" will not be doable. This is probably a favorable way with RedHat, Debian, Suse and others. Thats the right thing to do if there will be rpms, dpkg, .. For those reasons, I think it still make sense to keep it to a minimal ~3 calls to JNI code that we can use for speed and versatility. lock() isLocked(), unlock() perhaps. When I say speed, its more about avoiding crossing the JNI layer multiple times than java vs C performance. With versatility I think liblock is the right way for most but not all (embeded) linux distros. -- Trent Jarvi tjarvi at qbang.org From joachim at buechse.de Mon Mar 20 12:42:04 2006 From: joachim at buechse.de (Joachim Buechse) Date: Mon, 20 Mar 2006 20:42:04 +0100 Subject: [Rxtx] BUG: Lock file stays even if port opening fails In-Reply-To: References: Message-ID: <82C19FE7-DDCB-45B6-B2C9-7606B66F0124@buechse.de> Ok, what about providing a default implementation in Java? The RXTXCommDriver would call a (native) function useNativeLocking and if it returns true, call the native functions for lock() isLocked (), unlock(), else is would use the Java based default implementation. This could possibly be overriden by a property (again for debugging). Joachim On 20.03.2006, at 20:21, Trent Jarvi wrote: > On Mon, 20 Mar 2006, Joachim Buechse wrote: > >> Hi Trent, >> >> What is your general feeling about moving code to Java? The last >> days I have been reading quite a bit of the code and there are >> several things, that might not work as expected. >> >> I'll give you two examples from is_device_locked: >> >> if LOCKDIR == /var/spool/locks the directory /var/spool/lock will >> not be checked. >> LOCKDIR is not checked for lockfiles with unexpected pefixes >> >> While these things have probably never been discovered in >> production, they are still possibly incorrect implementations. If >> it was Java code, I would write some unit tests producing the >> errors that could later be corrected. >> >> PS: One could imagine to actually implement the whole lockfile >> handling in Java using some native routines to get the values >> required (pid, st_dev, st_rdev, ...). > > Hi Joachim > > I like the idea of moving more of the code into java but there are > some things to consider. > > If you break this into multiple JNI calls, the performance will > drop considerably during enumeration of ports. We are looking for > 256 ports per dev type vs (16? in Sun's 2.0 and fewer types). Its > hard to make assumptions. I've seen virtual ports start at /dev/ > foo100 for instance. > > It works out to over 7500 ports on Linux if you enable them all. > We already trim that back by default. See Linux-all-ports in > RXTXCommDriver.java. > > There are also native libraries that rxtx can link to. If you move > too much into Java, linking to 'standard' libraries with distros > will break. "configure --enable-liblock=yes" will not be doable. > This is probably a favorable way with RedHat, Debian, Suse and > others. Thats the right thing to do if there will be rpms, dpkg, .. > > For those reasons, I think it still make sense to keep it to a > minimal ~3 calls to JNI code that we can use for speed and > versatility. lock() isLocked(), unlock() perhaps. When I say > speed, its more about avoiding crossing the JNI layer multiple > times than java vs C performance. With versatility I think liblock > is the right way for most but not all (embeded) linux distros. > > -- > Trent Jarvi > tjarvi at qbang.org > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Mon Mar 20 12:44:47 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 20 Mar 2006 12:44:47 -0700 (MST) Subject: [Rxtx] BUG: Lock file stays even if port opening fails In-Reply-To: <82C19FE7-DDCB-45B6-B2C9-7606B66F0124@buechse.de> References: <82C19FE7-DDCB-45B6-B2C9-7606B66F0124@buechse.de> Message-ID: On Mon, 20 Mar 2006, Joachim Buechse wrote: > Ok, what about providing a default implementation in Java? > > The RXTXCommDriver would call a (native) function useNativeLocking and if > it returns true, call the native functions for lock() isLocked(), > unlock(), else is would use the Java based default implementation. This > could possibly be overriden by a property (again for debugging). > Hi Joachim That would be OK with me. -- Trent Jarvi tjarvi at qbang.org From dmarkman at mac.com Mon Mar 20 22:27:45 2006 From: dmarkman at mac.com (Dmitry Markman) Date: Tue, 21 Mar 2006 00:27:45 -0500 Subject: [Rxtx] binaries request Message-ID: <42702213-C222-4937-A585-7CFB17E47608@mac.com> Hi can somebody send me latest linux and windows binaries, please? or where I can find them (I didn't find them in the latest tareball) I gave up with my cygwin: something wrong I have no idea what java doesn't understand /cygwin/c syntax after I changed makefile it did java part but after that gcc 3.4.4 started to complain I set buffer length to 999 lines but I didn't get beginning of the story something wrong with my 1.4.2_09/include/jni.h gcc doesn't like it anyway I gave up thanks in advance Dmitry Markman -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060320/f8cbc57c/attachment-0039.html From tjarvi at qbang.org Mon Mar 20 22:36:48 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 20 Mar 2006 22:36:48 -0700 (MST) Subject: [Rxtx] binaries request In-Reply-To: <42702213-C222-4937-A585-7CFB17E47608@mac.com> References: <42702213-C222-4937-A585-7CFB17E47608@mac.com> Message-ID: On Tue, 21 Mar 2006, Dmitry Markman wrote: > Hi > can somebody send me latest linux and windows binaries, please? > > or where I can find them (I didn't find them in the latest tareball) > > I gave up with my cygwin: something wrong I have no idea what > java doesn't understand /cygwin/c syntax > after I changed makefile it did java part > but after that gcc 3.4.4 started to complain > I set buffer length to 999 lines but I didn't get beginning of the story > something wrong with my 1.4.2_09/include/jni.h gcc doesn't like it > anyway I gave up > > thanks in advance > Hi Dmitry The bins are here: ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7-bins-r2.zip Here are the files in the zip you want. Jar: rxtx-2.1-7-bins-r2/RXTXcomm.jar Windows: rxtx-2.1-7-bins-r2/Windows/i368-mingw32/rxtxSerial.dll Linux (x86) rxtx-2.1-7-bins-r2/Linux/i686-unknown-linux-gnu/librxtxSerial.so There are others in there including Parallel port support but those are the main ones for testing. -- Trent Jarvi tjarvi at qbang.org From dmarkman at mac.com Mon Mar 20 23:05:59 2006 From: dmarkman at mac.com (Dmitry Markman) Date: Tue, 21 Mar 2006 01:05:59 -0500 Subject: [Rxtx] binaries request In-Reply-To: References: <42702213-C222-4937-A585-7CFB17E47608@mac.com> Message-ID: thank you very much but windows's readme says: rxtxSerial.dll had to be recomopiled to link in missing native methods. should I ignore it? or what? thanks again also I understand that I should use mingw not cygwin I'll try to install mingw On Mar 21, 2006, at 12:36 AM, Trent Jarvi wrote: > On Tue, 21 Mar 2006, Dmitry Markman wrote: > >> Hi >> can somebody send me latest linux and windows binaries, please? >> >> or where I can find them (I didn't find them in the latest tareball) >> >> I gave up with my cygwin: something wrong I have no idea what >> java doesn't understand /cygwin/c syntax >> after I changed makefile it did java part >> but after that gcc 3.4.4 started to complain >> I set buffer length to 999 lines but I didn't get beginning of the >> story >> something wrong with my 1.4.2_09/include/jni.h gcc doesn't like it >> anyway I gave up >> >> thanks in advance >> > > Hi Dmitry > > The bins are here: > > ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7-bins-r2.zip > > Here are the files in the zip you want. > > Jar: > > rxtx-2.1-7-bins-r2/RXTXcomm.jar > > Windows: > > rxtx-2.1-7-bins-r2/Windows/i368-mingw32/rxtxSerial.dll > > Linux (x86) > > rxtx-2.1-7-bins-r2/Linux/i686-unknown-linux-gnu/librxtxSerial.so > > There are others in there including Parallel port support but those > are the main ones for testing. > > -- > Trent Jarvi > tjarvi at qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx Dmitry Markman From tjarvi at qbang.org Mon Mar 20 23:20:33 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 20 Mar 2006 23:20:33 -0700 (MST) Subject: [Rxtx] binaries request In-Reply-To: References: <42702213-C222-4937-A585-7CFB17E47608@mac.com> Message-ID: On Tue, 21 Mar 2006, Dmitry Markman wrote: > thank you very much > > but windows's readme says: > rxtxSerial.dll had to be recomopiled to link in missing native methods. > > should I ignore it? or what? > Hi Dmitry That dll should be OK. r2 is the recompile linked to the missing native method. The readme explains why it was recompiled; fuser.o was not linked into the dll in the first release. -- Trent Jarvi tjarvi at qbang.org From ariantristan at yahoo.com Mon Mar 20 23:55:24 2006 From: ariantristan at yahoo.com (Lambok Sianturi) Date: Mon, 20 Mar 2006 22:55:24 -0800 (PST) Subject: [Rxtx] jvm issue Message-ID: <20060321065524.94779.qmail@web50701.mail.yahoo.com> Hi All, This is my first time to join RxTx mailing list. I thank you all for allowing others to sign in in requests help. I use the latest RxTx lib in Fedora 3 with java version 1.4.2_09 b05. And I got this error: # # An unexpected error has been detected by HotSpot Virtual Machine: # # SIGSEGV (0xb) at pc=0x00bf27f3, pid=2633, tid=3086112448 # # Java VM: Java HotSpot(TM) Client VM (1.4.2_09-b05 mixed mode) # Problematic frame: # C [ld-linux.so.2+0xa7f3] # # An error report file with more information is saved as hs_err_pid2633.log # # If you would like to submit a bug report, please visit: # http://java.sun.com/webapps/bugreport/crash.jsp # ./run.sh: line 3: 2633 Aborted /usr/local/java/bin/java -Djava.library.path=/usr/local/java/jre/lib/ -Djsmsengine.debug=true -classpath jsmsengine.jar:smsgateway.jar:classes12.jar:RXTXcomm.jar:. com.api.sms.SMSServer What is the jvm depedency for the latest library? Can I use 1.4.2_09 b05? Thanks in advance. Arian --------------------------------- Yahoo! Mail Use Photomail to share photos without annoying attachments. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060320/83d58dd7/attachment-0039.html From f.frumento at ngi.it Tue Mar 21 00:21:47 2006 From: f.frumento at ngi.it (Fabio Frumento) Date: Tue, 21 Mar 2006 08:21:47 +0100 Subject: [Rxtx] Javadoc on the go Message-ID: <441FA98B.9050701@ngi.it> Hi Trent, sorry for the big delay but my job is running wild, i was out for some time but now i'm back and ready to continue the javadoc for Rxtx. Did you used the last javadoc patch i sent you ? let me know if i have to send it to you again or not. regards Fabio From lyon at docjava.com Tue Mar 21 00:51:18 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Tue, 21 Mar 2006 02:51:18 -0500 Subject: [Rxtx] lock files Message-ID: Hi All, You know, if the use of lock files were under Java control (rather than a build-time decision), it might enable a more unified binary distro. It might also facilitate quick prototyping of non-lock file approaches to resolving serial port contention issues (i.e., mac-like approaches vs. linux approaches, etc.). I realize that this is a radical overhaul of the lock file policy issue. Also, it may harm performance. On the other hand, our benchmarks on JNI overhead for modern processors indicate performance impact should be minimal. Perhaps it is more of an issue with the toybox systems. Suppose there were a class with a reasonable default...someone might write: SerialPortLockPolicy.setPolicy(SerialPortLockPolicy.UNIX_LOCK_FILE); SerialPortLockPolicy.setPolicy(SerialPortLockPolicy.NO_LOCK_CHECKING); SerialPortLockPolicy.setPolicy(SerialPortLockPolicy.MAC_STYLE); Thus, we could have a run-time reconfiguration of the serial port lock policy. A special NO_LOCK version of the binary would no longer be required. Any thoughts on this? Thanks! - Doug From joachim at buechse.de Tue Mar 21 03:09:09 2006 From: joachim at buechse.de (Joachim Buechse) Date: Tue, 21 Mar 2006 11:09:09 +0100 Subject: [Rxtx] lock files In-Reply-To: References: Message-ID: <8E12916A-1B9A-4FF2-B684-E2D1C794221B@buechse.de> This is pretty much what I thought about when I suggested, that the default behaviour could be overwritten with a property. I am very much in favor of this approach. In particular this allows much easier debugging for PC based java developers. I think big parts of the Java (and maybe some parts of the C code) could use a bit of a structural workover (unit tests, javadoc, synchronization, etc). Maybe there should be a CVS branch for this experimental version. I'd be happy to contribute a first workover for some of the Java code. Designing for testability and implementing a good bunch of unit tests has been a strategy that worked quite well in the Java projects I lead. And it ultimately allows more liberal change permission. Regards, Joachim On 21.03.2006, at 08:51, Dr. Douglas Lyon wrote: > Hi All, > You know, if the use of lock files were > under Java control (rather than a build-time decision), > it might enable a more unified binary distro. It might also > facilitate quick prototyping of non-lock file approaches > to resolving serial port contention issues (i.e., mac-like > approaches vs. linux approaches, etc.). > > I realize that this is a radical overhaul of the lock file policy > issue. Also, it may harm performance. On the other hand, > our benchmarks on JNI overhead for modern processors indicate > performance impact should be minimal. Perhaps it is more of > an issue with the toybox systems. > > Suppose there were a class with a reasonable default...someone > might write: > SerialPortLockPolicy.setPolicy(SerialPortLockPolicy.UNIX_LOCK_FILE); > SerialPortLockPolicy.setPolicy(SerialPortLockPolicy.NO_LOCK_CHECKING); > SerialPortLockPolicy.setPolicy(SerialPortLockPolicy.MAC_STYLE); > > Thus, we could have a run-time reconfiguration of the serial port lock > policy. A special NO_LOCK version of the binary would no longer > be required. > > Any thoughts on this? > > Thanks! > - Doug > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From joachim at buechse.de Tue Mar 21 06:23:08 2006 From: joachim at buechse.de (Joachim Buechse) Date: Tue, 21 Mar 2006 14:23:08 +0100 Subject: [Rxtx] PATCH: use of ioctl(fd, TIOCEXCL) instead of lockfiles Message-ID: <923AE774-EEA2-4911-92D8-32BB27802C8B@buechse.de> Here is the patch for the ioctl(fd, TIOCEXCL). I have verified this only for OSX 10.4.5, hence it is only defined for APPLE. However, it should work at least for Solaris as well. If a process has requested TIOEXCL further open calls by other user processes will fail. The patch also disables uucp style locking for APPLE. Obviously this is discussable. I think it is the way to go, as it eliminates creating the lock directory which doesnt exist on the standard installation and it eliminates messing with the system group definitions (adding users to group uucp). Regarding the possibility of root processes opening a device which is locked - I consider this a feature not a potential problem. It is highly unlikely, that somebody is crazy enough to run a JavaVM as root (unless he has no other means of getting a restricted IP port opened, ie doesnt understand ipfw). Anyway, even if the process runs as root, it fails when calling ioctl(fd, TIOCEXCL). It could however still open the port to listen for RING events. I.e. a fax server which needs to see incoming calls but otherwise doesnt want to block the port. So the only case where the proposed mechanism fails is, if an incorrectly implemented process running as root conflicts with a user process. I think this can be accepted. Regards, Joachim PS: If this patch is generally accepted, the installer and Mac doku should obviously be changed as well. Index: SerialImp.c =================================================================== RCS file: /usr/local/cvsroot/rxtx-devel/src/SerialImp.c,v retrieving revision 1.46.2.187 diff -u -r1.46.2.187 SerialImp.c --- SerialImp.c 29 Jan 2006 22:19:04 -0000 1.46.2.187 +++ SerialImp.c 21 Mar 2006 12:59:16 -0000 @@ -656,6 +656,25 @@ fd=OPEN (filename, O_RDWR | O_NOCTTY | O_NONBLOCK ); } while (fd < 0 && errno==EINTR); +#ifdef OPEN_EXCL + // Note that open() follows POSIX semantics: multiple open() calls to + // the same file will succeed unless the TIOCEXCL ioctl is issued. + // This will prevent additional opens except by root-owned processes. + // See tty(4) ("man 4 tty") and ioctl(2) ("man 2 ioctl") for details. + + if (fd >= 0 && (ioctl(fd, TIOCEXCL) == -1)) + { + sprintf( message, "open: exclusive access denied for % s\n", + filename ); + report( message ); + report_error( message ); + + close(fd); + goto fail; + } +#endif /* OPEN_EXCL */ + + if( configure_port( fd ) ) goto fail; (*env)->ReleaseStringUTFChars( env, jstr, filename ); sprintf( message, "open: fd returned is %i\n", fd ); Index: SerialImp.h =================================================================== RCS file: /usr/local/cvsroot/rxtx-devel/src/SerialImp.h,v retrieving revision 1.11.2.49 diff -u -r1.11.2.49 SerialImp.h --- SerialImp.h 5 Jul 2005 17:47:21 -0000 1.11.2.49 +++ SerialImp.h 21 Mar 2006 12:59:17 -0000 @@ -135,7 +135,8 @@ /*# define LOCKDIR "/var/spool/uucp"*/ # define LOCKDIR "/var/lock" # define LOCKFILEPREFIX "LK." -# define UUCP +/*# define UUCP*/ +# define OPEN_EXCL #endif /* __APPLE__ */ #if defined(__NetBSD__) # define DEVICEDIR "/dev/" From tjarvi at qbang.org Tue Mar 21 10:26:08 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 21 Mar 2006 10:26:08 -0700 (MST) Subject: [Rxtx] Javadoc on the go In-Reply-To: <441FA98B.9050701@ngi.it> References: <441FA98B.9050701@ngi.it> Message-ID: On Tue, 21 Mar 2006, Fabio Frumento wrote: > Hi Trent, > > sorry for the big delay but my job is running wild, i was out for some > time but now i'm back and ready to continue the javadoc for Rxtx. > > Did you used the last javadoc patch i sent you ? let me know if i have to > send it to you again or not. > > regards > > Fabio Hi Fabio The patch is in the rxtx mail-list archives. It will be going in soon. I did not see a time critical portion. I'll probably be going through the list since the last batch of patches this weekend and putting them into CVS. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Tue Mar 21 10:57:18 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 21 Mar 2006 10:57:18 -0700 (MST) Subject: [Rxtx] jvm issue In-Reply-To: <20060321065524.94779.qmail@web50701.mail.yahoo.com> References: <20060321065524.94779.qmail@web50701.mail.yahoo.com> Message-ID: On Mon, 20 Mar 2006, Lambok Sianturi wrote: > Hi All, > This is my first time to join RxTx mailing list. I thank you all for allowing others to sign in in requests help. > I use the latest RxTx lib in Fedora 3 with java version 1.4.2_09 b05. And I got this error: > > # > # An unexpected error has been detected by HotSpot Virtual Machine: > # > # SIGSEGV (0xb) at pc=0x00bf27f3, pid=2633, tid=3086112448 > # > # Java VM: Java HotSpot(TM) Client VM (1.4.2_09-b05 mixed mode) > # Problematic frame: > # C [ld-linux.so.2+0xa7f3] A native library loading error? What happens if you recompile rxtx on your system and install that? This sounds like an ABI problem? rxtx 2.1-7 was compiled with a gcc 2.96 toolchain as I recall. The hope is newer system will be backwards compatible. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Tue Mar 21 11:05:29 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 21 Mar 2006 11:05:29 -0700 (MST) Subject: [Rxtx] PATCH: use of ioctl(fd, TIOCEXCL) instead of lockfiles In-Reply-To: <923AE774-EEA2-4911-92D8-32BB27802C8B@buechse.de> References: <923AE774-EEA2-4911-92D8-32BB27802C8B@buechse.de> Message-ID: On Tue, 21 Mar 2006, Joachim Buechse wrote: > Here is the patch for the ioctl(fd, TIOCEXCL). I have verified this only > for OSX 10.4.5, hence it is only defined for APPLE. However, it should > work at least for Solaris as well. > > If a process has requested TIOEXCL further open calls by other user > processes will fail. > > The patch also disables uucp style locking for APPLE. Obviously this is > discussable. I think it is the way to go, as it eliminates creating the > lock directory which doesnt exist on the standard installation and it > eliminates messing with the system group definitions (adding users to > group uucp). > > Regarding the possibility of root processes opening a device which is > locked - I consider this a feature not a potential problem. It is highly > unlikely, that somebody is crazy enough to run a JavaVM as root (unless > he has no other means of getting a restricted IP port opened, ie doesnt > understand ipfw). Anyway, even if the process runs as root, it fails when > calling ioctl(fd, TIOCEXCL). It could however still open the port to > listen for RING events. I.e. a fax server which needs to see incoming > calls but otherwise doesnt want to block the port. So the only case where > the proposed mechanism fails is, if an incorrectly implemented process > running as root conflicts with a user process. I think this can be > accepted. > > Regards, > Joachim > > PS: If this patch is generally accepted, the installer and Mac doku > should obviously be changed as well. > > > Index: SerialImp.c > =================================================================== > RCS file: /usr/local/cvsroot/rxtx-devel/src/SerialImp.c,v > retrieving revision 1.46.2.187 > diff -u -r1.46.2.187 SerialImp.c > --- SerialImp.c 29 Jan 2006 22:19:04 -0000 1.46.2.187 > +++ SerialImp.c 21 Mar 2006 12:59:16 -0000 > @@ -656,6 +656,25 @@ > fd=OPEN (filename, O_RDWR | O_NOCTTY | O_NONBLOCK ); > } while (fd < 0 && errno==EINTR); > > +#ifdef OPEN_EXCL > + // Note that open() follows POSIX semantics: multiple open() > calls to > + // the same file will succeed unless the TIOCEXCL ioctl is > issued. > + // This will prevent additional opens except by root-owned > processes. > + // See tty(4) ("man 4 tty") and ioctl(2) ("man 2 ioctl") for > details. > + > + if (fd >= 0 && (ioctl(fd, TIOCEXCL) == -1)) > + { > + sprintf( message, "open: exclusive access denied for % > s\n", > + filename ); > + report( message ); > + report_error( message ); > + > + close(fd); > + goto fail; > + } > +#endif /* OPEN_EXCL */ > + > + > if( configure_port( fd ) ) goto fail; > (*env)->ReleaseStringUTFChars( env, jstr, filename ); > sprintf( message, "open: fd returned is %i\n", fd ); > Index: SerialImp.h > =================================================================== > RCS file: /usr/local/cvsroot/rxtx-devel/src/SerialImp.h,v > retrieving revision 1.11.2.49 > diff -u -r1.11.2.49 SerialImp.h > --- SerialImp.h 5 Jul 2005 17:47:21 -0000 1.11.2.49 > +++ SerialImp.h 21 Mar 2006 12:59:17 -0000 > @@ -135,7 +135,8 @@ > /*# define LOCKDIR "/var/spool/uucp"*/ > # define LOCKDIR "/var/lock" > # define LOCKFILEPREFIX "LK." > -# define UUCP > +/*# define UUCP*/ > +# define OPEN_EXCL > #endif /* __APPLE__ */ > #if defined(__NetBSD__) > # define DEVICEDIR "/dev/" > This looks like a good start. What do you think Dmitry? Perhaps all systems with TIOCEXCL defined should use that though. Even if they use lockfiles. It wont hurt anything. That would catch people hacking their own serial apps without checking lockfiles. Its a good idea to avoid C++ style comments in the C portions. Some older systems don't deal with them well. If it's just for Mac OS X, it isn't a big deal. I think it was the Irix compiler that was problematic? -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Tue Mar 21 11:22:05 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 21 Mar 2006 11:22:05 -0700 (MST) Subject: [Rxtx] lock files In-Reply-To: <8E12916A-1B9A-4FF2-B684-E2D1C794221B@buechse.de> References: <8E12916A-1B9A-4FF2-B684-E2D1C794221B@buechse.de> Message-ID: We can try it. Maybe the JNI is much improved. The nice thing about linking into liblock is distros then worry about lockfiles on their systems. This way, we have to deal with any changes that may show up. On Tue, 21 Mar 2006, Joachim Buechse wrote: > This is pretty much what I thought about when I suggested, that the > default behaviour could be overwritten with a property. I am very much in > favor of this approach. In particular this allows much easier debugging > for PC based java developers. > > I think big parts of the Java (and maybe some parts of the C code) could > use a bit of a structural workover (unit tests, javadoc, synchronization, > etc). Maybe there should be a CVS branch for this experimental version. > I'd be happy to contribute a first workover for some of the Java code. > Designing for testability and implementing a good bunch of unit tests has > been a strategy that worked quite well in the Java projects I lead. And > it ultimately allows more liberal change permission. > > Regards, > Joachim > > > On 21.03.2006, at 08:51, Dr. Douglas Lyon wrote: > >> Hi All, >> You know, if the use of lock files were >> under Java control (rather than a build-time decision), >> it might enable a more unified binary distro. It might also >> facilitate quick prototyping of non-lock file approaches >> to resolving serial port contention issues (i.e., mac-like >> approaches vs. linux approaches, etc.). >> >> I realize that this is a radical overhaul of the lock file policy >> issue. Also, it may harm performance. On the other hand, >> our benchmarks on JNI overhead for modern processors indicate >> performance impact should be minimal. Perhaps it is more of >> an issue with the toybox systems. >> >> Suppose there were a class with a reasonable default...someone >> might write: >> SerialPortLockPolicy.setPolicy(SerialPortLockPolicy.UNIX_LOCK_FILE); >> SerialPortLockPolicy.setPolicy(SerialPortLockPolicy.NO_LOCK_CHECKING); >> SerialPortLockPolicy.setPolicy(SerialPortLockPolicy.MAC_STYLE); >> >> Thus, we could have a run-time reconfiguration of the serial port lock >> policy. A special NO_LOCK version of the binary would no longer >> be required. >> >> Any thoughts on this? >> >> Thanks! >> - Doug >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From dmarkman at mac.com Tue Mar 21 16:05:17 2006 From: dmarkman at mac.com (Dmitry Markman) Date: Tue, 21 Mar 2006 18:05:17 -0500 Subject: [Rxtx] PATCH: use of ioctl(fd, TIOCEXCL) instead of lockfiles In-Reply-To: References: <923AE774-EEA2-4911-92D8-32BB27802C8B@buechse.de> Message-ID: <512AC70C-BB86-48F2-A83C-023F35C23BAB@mac.com> I think it's cool, but I'd like to have that property implementation when user can choose between locking mechanism about comments: it's easy to change comments to the C style or we can use extensions of the file to cpp so c++ compiler will be used On Mar 21, 2006, at 1:05 PM, Trent Jarvi wrote: > This looks like a good start. What do you think Dmitry? Perhaps > all systems with TIOCEXCL defined should use that though. Even if > they use lockfiles. It wont hurt anything. That would catch > people hacking their own serial apps without checking lockfiles. > > Its a good idea to avoid C++ style comments in the C portions. > Some older systems don't deal with them well. If it's just for Mac > OS X, it isn't a big deal. I think it was the Irix compiler that > was problematic? Dmitry Markman From dmarkman at mac.com Tue Mar 21 16:13:00 2006 From: dmarkman at mac.com (Dmitry Markman) Date: Tue, 21 Mar 2006 18:13:00 -0500 Subject: [Rxtx] PATCH: use of ioctl(fd, TIOCEXCL) instead of lockfiles In-Reply-To: References: <923AE774-EEA2-4911-92D8-32BB27802C8B@buechse.de> Message-ID: I'd like to add that creating locking folder isn't a big deal we never had a problem related to the lock folders, because we always used installer on mac os x from other hand I'm not very much familiar with iotcl locking approach and I'm not sure it's more efficient Joachim wrote "I think it is the way to go, as it eliminates creating the lock directory which doesnt exist on the standard installation and it eliminates messing with the system group definitions (adding users to group uucp)." but I really didn't have any problem with that 1. doesn't exist on the standard installation there are many-many things that don't exist in the standard installation so I don't think that argument is strong enough 2. messing with the system group definitions I don't think we're messing with the group definition mac os x provides very clear way to set up group's members and together with Greg Guerin AuthKit there is no problem to set those definitions so I don't think that argument is strong either but from other hand using iotcl is more promising and is more elegant On Mar 21, 2006, at 1:05 PM, Trent Jarvi wrote: > > This looks like a good start. What do you think Dmitry? Perhaps > all systems with TIOCEXCL defined should use that though. Even if > they use lockfiles. It wont hurt anything. That would catch > people hacking their own serial apps without checking lockfiles. Dmitry Markman From joachim at buechse.de Wed Mar 22 04:46:45 2006 From: joachim at buechse.de (Joachim Buechse) Date: Wed, 22 Mar 2006 12:46:45 +0100 Subject: [Rxtx] PATCH: use of ioctl(fd, TIOCEXCL) instead of lockfiles In-Reply-To: References: <923AE774-EEA2-4911-92D8-32BB27802C8B@buechse.de> Message-ID: Sorry, I was not very clear with my arguments, so I will try again;-) Please, don't take this as an attack against work that has been done. I think the contributions that have been made in the past were made in a good spirit. But I really believe, that the current solution for OSX has many shortcomings and should be changed as soon as possible. lock files --- The /var/lock folder does not exist on the standard OSX installation, however the standard installation includes several applications that use serial ports (i.e. the FAX capability). This indicates, that the lock folder approach will not work well with system components. Applications for OSX will generally try to live in harmony with system components (except for HP print drivers of course). I think RXTX should follow this approach as well. uucp group --- Accessing serial ports is not an admin privileged operation on OSX. Any user (world) has read/write privileges on /dev/tty*. So the system default is to not enforce any group membership to access these ports. The group uucp however is a system group on all unix systems I know. It exists for certain system processes. A non admin user should in general not be a member of this group. Quite arguably no user should ever be a member of this group. Installer --- My general opinion is, that - no Installer should touch user or group data without warning - no Application Installer should touch groups which are not specific to the very application installed - no Installer should ever add regular users to a system group The current installer injects the installing user in the group uucp without warning about this change and without giving the option to "opt out" of this change. This is a potential security risk (but not currently a real one, as OSX contains no folders belonging to group uucp). The current installer does not work for multi user systems. It puts the installing user in the uucp group. However the installing user is not necessarily the user that will use the application. Putting all users that may use a serial port application in the system group uucp seems like a very invasive approach to me. Besides that, newly created users will not automatically be in the group and hence, serial applications will "break" for new users without obvious reasons. Avoiding the lock files will allow self contained applications (i.e. drag&drop installation). In my eyes this is largely preferable over an installer that requests admin privileges. Adding up all these points indicates very strongly, that the lock-file implementation is not the way to go on OSX. Regards, Joachim On 22.03.2006, at 00:13, Dmitry Markman wrote: > I'd like to add that > > creating locking folder isn't a big deal > we never had a problem related to the lock folders, because we > always used installer on mac os x > from other hand I'm not very much familiar with iotcl locking > approach and I'm not sure it's more efficient > > Joachim wrote "I think it is the way to go, as it eliminates > creating the lock directory which doesnt exist on the standard > installation and it eliminates messing with the system group > definitions (adding users to group uucp)." but I really didn't have > any problem with that > > 1. doesn't exist on the standard installation > there are many-many things that don't exist in the standard > installation so I don't think that argument is strong enough > 2. messing with the system group definitions > I don't think we're messing with the group definition > mac os x provides very clear way to set up group's members and > together with Greg Guerin AuthKit there is no problem to set those > definitions > so I don't think that argument is strong either > but from other hand using iotcl is more promising and is more elegant > > > > On Mar 21, 2006, at 1:05 PM, Trent Jarvi wrote: > >> >> This looks like a good start. What do you think Dmitry? Perhaps >> all systems with TIOCEXCL defined should use that though. Even if >> they use lockfiles. It wont hurt anything. That would catch >> people hacking their own serial apps without checking lockfiles. > > Dmitry Markman > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From dmarkman at mac.com Wed Mar 22 05:27:13 2006 From: dmarkman at mac.com (Dmitry Markman) Date: Wed, 22 Mar 2006 07:27:13 -0500 Subject: [Rxtx] PATCH: use of ioctl(fd, TIOCEXCL) instead of lockfiles In-Reply-To: References: <923AE774-EEA2-4911-92D8-32BB27802C8B@buechse.de> Message-ID: <83440CF3-DCD8-41C1-B941-F227232C27E3@mac.com> thanks for the very good explanation I didn't think that you were attacking any thing, so don't worry I just had feeling, that there were more aesthetic reasons for going to ioctl then real necessity now you explained everything quite well (BTW, asfar as I remember installer asks admin password so it wasn't quiet, but it really doesn't matter now) thanks On Mar 22, 2006, at 6:46 AM, Joachim Buechse wrote: > Sorry, I was not very clear with my arguments, so I will try again;-) > > Please, don't take this as an attack against work that has been > done. I think the contributions that have been made in the past > were made in a good spirit. But I really believe, that the current > solution for OSX has many shortcomings and should be changed as > soon as possible. > > lock files > --- > The /var/lock folder does not exist on the standard OSX > installation, however the standard installation includes several > applications that use serial ports (i.e. the FAX capability). This > indicates, that the lock folder approach will not work well with > system components. Applications for OSX will generally try to live > in harmony with system components (except for HP print drivers of > course). I think RXTX should follow this approach as well. > > uucp group > --- > Accessing serial ports is not an admin privileged operation on OSX. > Any user (world) has read/write privileges on /dev/tty*. So the > system default is to not enforce any group membership to access > these ports. The group uucp however is a system group on all unix > systems I know. It exists for certain system processes. A non admin > user should in general not be a member of this group. Quite > arguably no user should ever be a member of this group. > > Installer > --- > My general opinion is, that > - no Installer should touch user or group data without warning > - no Application Installer should touch groups which are not > specific to the very application installed > - no Installer should ever add regular users to a system group > > The current installer injects the installing user in the group uucp > without warning about this change and without giving the option to > "opt out" of this change. This is a potential security risk (but > not currently a real one, as OSX contains no folders belonging to > group uucp). > > The current installer does not work for multi user systems. It puts > the installing user in the uucp group. However the installing user > is not necessarily the user that will use the application. Putting > all users that may use a serial port application in the system > group uucp seems like a very invasive approach to me. Besides that, > newly created users will not automatically be in the group and > hence, serial applications will "break" for new users without > obvious reasons. > > > Avoiding the lock files will allow self contained applications > (i.e. drag&drop installation). In my eyes this is largely > preferable over an installer that requests admin privileges. Adding > up all these points indicates very strongly, that the lock-file > implementation is not the way to go on OSX. > > Regards, > Joachim > > > On 22.03.2006, at 00:13, Dmitry Markman wrote: > >> I'd like to add that >> >> creating locking folder isn't a big deal >> we never had a problem related to the lock folders, because we >> always used installer on mac os x >> from other hand I'm not very much familiar with iotcl locking >> approach and I'm not sure it's more efficient >> >> Joachim wrote "I think it is the way to go, as it eliminates >> creating the lock directory which doesnt exist on the standard >> installation and it eliminates messing with the system group >> definitions (adding users to group uucp)." but I really didn't >> have any problem with that >> >> 1. doesn't exist on the standard installation >> there are many-many things that don't exist in the standard >> installation so I don't think that argument is strong enough >> 2. messing with the system group definitions >> I don't think we're messing with the group definition >> mac os x provides very clear way to set up group's members and >> together with Greg Guerin AuthKit there is no problem to set those >> definitions >> so I don't think that argument is strong either >> but from other hand using iotcl is more promising and is more elegant >> >> >> >> On Mar 21, 2006, at 1:05 PM, Trent Jarvi wrote: >> >>> >>> This looks like a good start. What do you think Dmitry? Perhaps >>> all systems with TIOCEXCL defined should use that though. Even >>> if they use lockfiles. It wont hurt anything. That would catch >>> people hacking their own serial apps without checking lockfiles. >> >> Dmitry Markman >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx Dmitry Markman From lyon at docjava.com Wed Mar 22 06:12:18 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Wed, 22 Mar 2006 08:12:18 -0500 Subject: [Rxtx] sole of a new design pattern Message-ID: Hi All, I have been thinking about how we design the serial port software. I think we need a new design pattern. For lack of a better term, I shall call it: The Parametric Singleton Design Pattern By Douglas A. Lyon ABSTRACT The goal of the singleton design pattern is to make sure that there is one, and only one, instance of a given class. The goal of the parametric singleton design pattern is to make sure that there is one, and only one, instance of a given class with the given parametric values. We parametric singleton design pattern combines the singleton design pattern with a parameter that enables unique creation of instances of a class. These instances are cached. When a user asks for an instance with these parameters, the cache is checked. If the instance is in the cache, the instance is returned, otherwise it is created, added to the cache and then returned. We apply our parametric singleton design pattern to the retrieval of RMI registries bound to a given port. The goal of our system is to make sure that no two RMI registries are listening to the same socket and to make use of the RMI registries after they have been created. RMI registries are used in distributed computation. Introduction The singleton design pattern is meant to ensure that on a single instance of a class exists. It is also meant to provide a global point of access to it. The intent of the parametric singleton design pattern is to ensure that a class has only one instance for a given set of parameter values. It also provides a global point of access to it. Motivation A system cannot tolerate multiple instances of some classes with identical parameters. For example, you cannot have two instances making use of the same serial port, at the same time. You cannot have two instances that are trying to listen to the same socket connection. You cannot have two instances writing to the same file structure at the same time. As the operating system is often thought of as the arbiter of consumed resources (i.e., tape drives, serial ports, etc.) we frequently leave it to an operating system implementation to resolve these contention issues. Even for similar resources (like serial ports) there are few standards for handling contention. For example, serial ports on Linux are locked using a "/var/lock" file. POSIX, on the other hand, uses ioctl mechanisms to prevent contention. A better solution is to make a class that is responsible for keeping track of the instances created from the class. The class is declared final, so that it cannot be subclassed. The class also has a private constructor, so that other classes cannot instance it. The new design pattern is called the parametric singleton design pattern and it provides a way to access and create instances with given parameters. Applicability Use the Parametric Singleton Design Pattern when: 1. There must be exactly one instance of a class with the given parameters. 2. The instances must be accessible to clients from a well-known access point. Structure Insert UML diagram here. Participants The Parametric Singleton Clients that need instances 1. The Parametric Singleton defines an instance upon request from a client, if, and only if, the instance does not already exist. 2. The Parametric Singleton returns the instance to the client. 3. The Parametric Singleton is responsible for creating unique instances from given parameters. Collaborations Clients obtain a reference to a Parametric Singleton instance only through the parametric singleton design pattern. If the instance is left in an improper state (e.g., the serial port was left open) it is NOT the role of the Parametric Singleton Design Pattern to close the IO port. Nor is it the role of the Parametric Singleton Design Pattern to open the port. That role is delegate to some other part of the system. Further, it is not the role of the Parametric Singleton Design Pattern to check out resources. That is, multiple threads can have multiple references to the same resource at the same time. MUTEX locking is delegated to some other part of the system. Consequences The Parametric Singleton Design Pattern has several benefits: 1. Controlled access to parametrically defined instances. Since the Parametric Singleton class encapsulates its instances, there is control over how and when clients access it. 2. Reduced name space. The Parametric Singleton pattern avoids global variables that store instances created from the same parameter. Implementation Here are implementation issues to consider when using the Parametric Singleton pattern: 1. Unique mapping of parameters. The Parametric Singleton pattern requires that there be a mean to isomorphically map the parameter space into the instance space and back again. 2. Ensure unique instances. The Parametric Singleton pattern makes unique instances from parameters, and it does so only once. 3. Cache instances for fast retrieval. The Parametric Singleton pattern must be able to look up instances, given some set of parameters, and do so from some data structure. That is, there must be enough space to hold references to all the instances the program will need. Also, a mechanism is needed to look up and retrieve the instances quickly enough to satisfy the clients. Sample Code public final class ParametricSingletonRmiRegistry { private static Hashtable registry = new Hashtable(100); // use singleton pattern and??????????????????????????????????????????????? // prevent instantiation of RmiRegistryUtils.?????????????????????????????? private ParametricSingletonRmiRegistry() { } // the only instance of the Registry held by the RmiRegistryUtils?????????? public static void listNames(Integer port) { if (!isInCacheAndRunning(port)) return; Registry r = (Registry) registry.get(port); System.out.println("registry on port: " + port); System.out.println("registry: " + r); System.out.println("names: "); try { print(r.list()); } catch (RemoteException e) { In.message(e); } System.out.println("------------------------"); } /**???????????????????????????????????????????????????????????????????????? * Checks whether a Registry has been started on this host????????????????? * in the specified port.?????????????????????????????????????????????????? * If not, it tries to start one.?????????????????????????????????????????? * when it fails to start a Registry, it exits the program????????????????? * with exit code 1.??????????????????????????????????????????????????????? */ public static void restart(int port) { if (isInCacheAndRunning(port)) return; try { startRegistry(port); } catch (RemoteException e) { In.message(e); } } /**???????????????????????????????????????????????????????????????????????? * @param port????????????????????????????????????????????????????????????? * @return true if registry is in cache and running???????????????????????? */ private static boolean isInCacheAndRunning(Integer port) { if (!isRegistryRunning(port.intValue())) return false; if (!isRegistryInCache(port.intValue())) return false; return true; } /**???????????????????????????????????????????????????????????????????????? * @param port????????????????????????????????????????????????????????????? * @return true if we are able to locate a local registry on port.??????????????????????????????????????????????????????????????????????????? */ private static boolean isRegistryRunning(int port) { try { Registry r = LocateRegistry.getRegistry(port); if (r != null) return true; } catch (RemoteException e) { return false; } return false; } /**???????????????????????????????????????????????????????????????????????? * @param port????????????????????????????????????????????????????????????? * @return return true if registry is in cache????????????????????????????? */ private static boolean isRegistryInCache(int port) { if (registry.get(new Integer(port)) == null) return false; return true; } /**???????????????????????????????????????????????????????????????????????? * Restart the registry, if needed.???????????????????????????????????????? * Return the only instance of the registry for consistent global?????????? * using by making use of the Singleton Design Pattern????????????????????? *????????????????????????????????????????????????????????????????????????? * @return the internally held registry instance.?????????????????????????? */ public static Registry getRegistry(Integer port) { restart(port); return (Registry) registry.get(port); } private static void startRegistry(Integer port) throws RemoteException { Registry r; try { r = LocateRegistry.createRegistry(port.intValue()); registry.put(port, r); //r = new sun.rmi.registry.RegistryImpl???????????????????????????? /// (port.intValue());?????????????????????????????????????? // registry.put(port, r);?????????????????????????????????????????? } catch (Exception e) { //e.printStackTrace();????????????????????????????????????????????? r = LocateRegistry.getRegistry(port.intValue()); registry.put(port, r); } } public static void main(String args[]) throws RemoteException { //restart(port);??????????????????????????????????????????????????????? restart(5001); restart(5002); restart(5002); Registry r = LocateRegistry.getRegistry(5002); System.out.println("registry="+r); } } I would very much like to get your feedback on this new design pattern idea. Thank you for your time. Regards, - Doug From david.garnier at trusted-logic.com Wed Mar 22 07:36:10 2006 From: david.garnier at trusted-logic.com (David Garnier) Date: Wed, 22 Mar 2006 15:36:10 +0100 Subject: [Rxtx] sole of a new design pattern In-Reply-To: References: Message-ID: <442160DA.80107@trusted-logic.com> Hello, > The Parametric Singleton Design Pattern The Singleton is the most abused design pattern ever. Good use-cases for this pattern are extremely rare and mostly confined to problems related to hardware resources, like serial ports. > Applicability > > Use the Parametric Singleton Design Pattern when: > 1. There must be exactly one instance of a class with the given > parameters. OK. As I said above, this case this actually very unusual. The Singleton pattern is mostly used when : > 2. The instances must be accessible to clients from a well-known > access point. Using the singleton pattern in this case is just convenient for the programmer. Problems arises pretty quickly, especially if you attempt to unit-test your classes. 1) If your singleton is stateful, or hold on to stateful objects, it means that two different unit tests are not actually independent. Instead of starting with a brand new environment, the result of a test may be affected by the result of a previous test. This problem also arise when with your class relies on a database. In both cases, the solution is to reset your "unique" resource (Singleton or database) at the beginning of the test, which is a pain. Also, while most projects connect to a single database, projects that allow the use of Singletons usually contain several of thems, and new ones may cropped up unnoticed. You quickly end up with test cases that only pass in a certain order, which is a royal pain. 2) You cannot mockup a singleton. Once everyone calls the SomeSingleton class statically, you can't replace your class by SomeSingletonMockup. Furthermore, even for hardware services, the Singleton pattern does not really prevent concurrent accesses. If you start the same program in two different JVMs, unless they somehow shared the state of their "Singletons" (through lock files for example), the Singleton pattern will not prevent concurrent access. Our application uses RXTX, and we routinely encounter cases where another (native) application has already locked the port. Since we cannot modify the native application to recognize lock files, OS-level control is irreplaceable. > > Consequences > The Parametric Singleton Design Pattern has several benefits: > > 1. Controlled access to parametrically defined instances. Since > the Parametric Singleton class encapsulates its instances, there is > control over how and when clients access it. Not really. Once you've returned the instance to a client, you've lost control over it. The client can to whatever it wants with it. You cannot "recall" the instance or claim it back. > 2. Reduced name space. The Parametric Singleton pattern avoids > global variables that store instances created from the same parameter. Sure, but you don't have to rely on a Singleton for that. Just create a single Factory. > I would very much like to get your feedback on this new design > pattern idea. Well, it's nothing new. Some may say that it is the point of design patterns: formalizes the designs that occur again and again. However, this design is simply a combination of the Singleton and Factory patterns. I did use it in the past, but now I've been exposed to the shortcomings of the Singleton pattern, so I limit myself to Factories. Regards, David From sean_montgomery at baseview.com Wed Mar 22 08:35:28 2006 From: sean_montgomery at baseview.com (Sean Montgomery) Date: Wed, 22 Mar 2006 10:35:28 -0500 Subject: [Rxtx] sole of a new design pattern In-Reply-To: <442160DA.80107@trusted-logic.com> References: <442160DA.80107@trusted-logic.com> Message-ID: <05769CA7-A51B-4CF0-BAA0-E02DD905F5A4@baseview.com> On Mar 22, 2006, at 9:36 AM, David Garnier wrote: > Furthermore, even for hardware services, the Singleton pattern does > not really prevent concurrent > accesses. If you start the same program in two different JVMs, > unless they somehow shared the state > of their "Singletons" (through lock files for example), the > Singleton pattern will not prevent > concurrent access. > Multiple class loaders in a single JVM can be tricky, too. Then there's synchronization, lazy initialization and serialization of singletons to contend with. Bloch's Effective Java covers these, and here's a few articles: http://www.javaworld.com/javaworld/jw-04-2003/jw-0425-designpatterns- p3.html http://java.sun.com/developer/technicalArticles/Programming/singletons/ Just FYI :-) From lyon at docjava.com Wed Mar 22 08:50:48 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Wed, 22 Mar 2006 10:50:48 -0500 Subject: [Rxtx] sole of a new design pattern In-Reply-To: <442160DA.80107@trusted-logic.com> References: <442160DA.80107@trusted-logic.com> Message-ID: Hi All, First, I would like to thank David for his prompt and thoughtful remarks. I had no idea people that feel strongly about a design patterns! Wow! Feedback (particularly critical feedback) is greatly appreciated. Starting at the end, first: >I did use it in >the past, but now I've been exposed to the shortcomings of the >Singleton pattern, so I limit myself to Factories. David, if I understood your comments correctly, you suggested that Factories can be used in leu of the Singleton Design Pattern, or even the Parametric Singleton Design Pattern. As I see in [Gof]: Factory Method: Intent "Define an interface for creating an object, but let subclasses decide which class to instantiate. Factory Method lets a class defer instantiation to subclasses." The Singleton Design Pattern is a concrete class, which is rather different, right? Also, subclasses are not permitted with Singleton, as they are final. Naturally, I could use an abstract factory as a parent for a singleton. I could even design a facade that could be implemented with the singleton....but that is not the intention of the design. Unless you want a mock-up, as discussed, below: More below: >Hello, > >> The Parametric Singleton Design Pattern > >The Singleton is the most abused design pattern ever. Good use-cases >for this pattern are extremely >rare and mostly confined to problems related to hardware resources, >like serial ports. > > >> Applicability >> >> Use the Parametric Singleton Design Pattern when: >> 1. There must be exactly one instance of a class with the given >> parameters. >OK. As I said above, this case this actually very unusual. The >Singleton pattern is mostly used when : >> 2. The instances must be accessible to clients from a well-known >> access point. > >Using the singleton pattern in this case is just convenient for the >programmer. Problems arises >pretty quickly, especially if you attempt to unit-test your classes. > >1) If your singleton is stateful, or hold on to stateful objects, it >means that two different unit >tests are not actually independent. Instead of starting with a brand >new environment, the result of >a test may be affected by the result of a previous test. This >problem also arise when with your >class relies on a database. In both cases, the solution is to reset >your "unique" resource >(Singleton or database) at the beginning of the test, which is a >pain. Also, while most projects >connect to a single database, projects that allow the use of >Singletons usually contain several of >thems, and new ones may cropped up unnoticed. You quickly end up >with test cases that only pass in a >certain order, which is a royal pain. There are basic problems with communicating finite state machines that include reachability and deadlock analysis. These are addressed with petri net analysis and are beyond the scope of the design pattern. As you quite rightly pointed out; the parametric singleton pattern (or the singleton pattern, for that matter) enable multiple threads to gain access to the same instance. The only way that I can see to block others from gaining access to the reference is the synchronize keyword. This is putting a spin-lock (or MUTEX) on the reference. The question of how to unit-test a design pattern like the parametric singleton remains open. Perhaps this is a deficiency. > >2) You cannot mockup a singleton. Once everyone calls the >SomeSingleton class statically, you can't >replace your class by SomeSingletonMockup. Acutally, I am not sure that this is true. If the Singleton implements a Facade interface, it should be possible to make the replacement. Right? > >Furthermore, even for hardware services, the Singleton pattern does >not really prevent concurrent >accesses. If you start the same program in two different JVMs, >unless they somehow shared the state >of their "Singletons" (through lock files for example), the >Singleton pattern will not prevent >concurrent access. Good Point!! You have sharp eyes! The singleton design pattern should/could take responsibility for this. In fact, you may notice that my code does have an implementation (LocateRegistry) that can work across JVM's. The LocateRegistry will even work across the Internet! LocateRegistry takes both a host name and a Port (lock files just don't do this). I did not think to implement this beyond the local machine, but, in its present form, it will work across different processes. > >Our application uses RXTX, and we routinely encounter cases where >another (native) application has >already locked the port. Since we cannot modify the native >application to recognize lock files, >OS-level control is irreplaceable. The singleton design pattern is not meant to replace OS-level control, but to centralize the Java programmers access to it. If lock files, for example, are used for serial ports, the Singleton Design Pattern should be able to work with them. > > >> >> Consequences >> The Parametric Singleton Design Pattern has several benefits: >> > > 1. Controlled access to parametrically defined instances. Since >> the Parametric Singleton class encapsulates its instances, there is >> control over how and when clients access it. > >Not really. Once you've returned the instance to a client, you've >lost control over it. The client >can to whatever it wants with it. You cannot "recall" the instance >or claim it back. Good point, this should read: > 1. Controll when parametrically defined instances are created. Since > > the Parametric Singleton class encapsulates its instances, there is > > control over how and when they are instanced. > >> 2. Reduced name space. The Parametric Singleton pattern avoids >> global variables that store instances created from the same parameter. > >Sure, but you don't have to rely on a Singleton for that. Just >create a single Factory. > > Thank you for your thoughtful and prompt response! Regards, - Doug From dmarkman at mac.com Wed Mar 22 21:21:55 2006 From: dmarkman at mac.com (Dmitry Markman) Date: Wed, 22 Mar 2006 23:21:55 -0500 Subject: [Rxtx] sole of a new design pattern In-Reply-To: <442160DA.80107@trusted-logic.com> References: <442160DA.80107@trusted-logic.com> Message-ID: I don't think I get it On Mar 22, 2006, at 9:36 AM, David Garnier wrote: > Using the singleton pattern in this case is just convenient for the > programmer. Problems arises > pretty quickly, especially if you attempt to unit-test your classes. so you're saying that something isn't so good because you can not test it in the convenient way? if that's true, I'm totally disagree change your test, debug whatever, but if software is efficient at runtime, works fine and only problem is some unit test (which is some kind of framework for testing) then dump that unit test , dump that unit framework and make something appropriate to the software you're testing so if Douglas want to use singletons, what's the problem? and what do you mean by abusing of singleton usage? of course singleton doesn't prevent concurrent access to the resource across the processes unless you're using some OS facility to prevent it, besides singleton as it was introduced is relevant only and only inside of the same process otherwise it's not singleton it's something else (let's say network singleton: so you have remote invocation facility and some factory method that return object created by that facility) I don't have any problem with using any kind of singletons. Parametric Singleton idea (if I understand it right) could be easily implemented in the following way: use a map populate map with instances of some class and key is your parameter (you can use lazy population too) if somebody ask the key check the value if it's null so resource is taken if somebody returns the resource put it back to the map public synchronized static Object getSomeResource(Object parameter); public synchronized static void returnResource(Object parameter); getSomeResource (inside of the same process) could return null in 2 cases 1. if somebody (from other thread for example) already took that resource 2. if OS API said that resource corresponded to that parameter (serial port with parameter = 1 (port #)) is locked and unavailable; I'm not sure that in case of serial ports we even need those Parametric Singletons (unless lock checking is a very expensive operation) just ask the OS about availability of that resource and if it's available give it away and then OS will lock it and therefore in next time somebody ask it just answer that resource is locked and return null for example system has 2 serial ports available so I ask getResource("tty"); or I ask getResource("Bluetooth-Modem"); and if OS is ok you can give tty or Bluetooth-Modem or both no need for any additional pattern I think back to the problem mac os x doesn't recognize locking via files, so it handles locking via some API an instance of the singleton in each process should recognize that resource is locked (by using that API) that's all we don't have to make things more complicate then they are just because there is some nice design pattern or nice unit test framework or whatever keep things simple, make them work fast, don't introduce middle layers unless you have really good reason to do so of course I could be entirely wrong, so sorry about that in advance thanks Dmitry Markman From tjarvi at qbang.org Wed Mar 22 22:31:41 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 22 Mar 2006 22:31:41 -0700 (MST) Subject: [Rxtx] sole of a new design pattern In-Reply-To: References: Message-ID: Hi Doug Interesting reading. So far I'm just reading and thinking. I have one question so far. " Clients obtain a reference to a Parametric Singleton instance only through the parametric singleton design pattern. If the instance is left in an improper state (e.g., the serial port was left open) it is NOT the role of the Parametric Singleton Design Pattern to close the IO port. Nor is it the role of the Parametric Singleton Design Pattern to open the port. That role is delegate to some other part of the system. " So when the clients obtain a reference to the singleton, can they assume the port is there? IE, would it be the singletons role to handle things like USB dongles being removed with event hints comming from the underlying OS. Hardware abstraction layer/HAL on Linux is an example of underlying OS events. I assume that role too is delegated to other parts of the system? -- Trent Jarvi tjarvi at qbang.org From lyon at docjava.com Thu Mar 23 08:10:33 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Thu, 23 Mar 2006 10:10:33 -0500 Subject: [Rxtx] Classes don't need goals, they need roles! In-Reply-To: References: Message-ID: Hi Trent, Yes, I think that the role of the Parametric Singleton Pattern is not to open or close serial ports, nor is it to perform error checking. On the other hand, if you were to combine the role of the Parametric Singleton Pattern with another role (like that of error checking) it might not be amiss. However, I generally caution programmers against adding multiple roles to classes, as this leads to monolithic designs. Thus a different class (NativeLibDetect) could have the role of determining if the native library can be loaded. Another class (SerialPortBean) can have the role of serializing the default state of the serial port, so that it can be recovered, from user preferences, at a later time. The SerialPortDetect could have the role of determining if the serial port is removed (i.e., a USB port was unplugged). My guess is that each class should have a different role in the system, in order to ease maintenance and testing...but I could be wrong about that. Thanks! - Doug >Hi Doug > >Interesting reading. So far I'm just reading and thinking. I have >one question so far. > >" > Clients obtain a reference to a Parametric Singleton instance only >through the parametric singleton design pattern. If the instance is >left in an improper state (e.g., the serial port was left open) it is >NOT the role of the Parametric Singleton Design Pattern to close the >IO port. Nor is it the role of the Parametric Singleton Design Pattern >to >open the port. That role is delegate to some other part of the system. >" > >So when the clients obtain a reference to the singleton, can they >assume the port is there? IE, would it be the singletons role to >handle things like USB dongles being removed with event hints >comming from the underlying OS. Hardware abstraction layer/HAL on >Linux is an example of underlying OS events. > >I assume that role too is delegated to other parts of the system? > >-- >Trent Jarvi >tjarvi at qbang.org >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From maximulo at yahoo.com Fri Mar 24 01:22:38 2006 From: maximulo at yahoo.com (Maximulo Majir) Date: Fri, 24 Mar 2006 00:22:38 -0800 (PST) Subject: [Rxtx] JavaPOS Message-ID: <20060324082238.66371.qmail@web38214.mail.mud.yahoo.com> Hi all! Hello Trent! From what i understand, RXTX or JavaComm APIs were not created solely for JavaPOS. In JavaPOS, we have the virtual method claim() which is separate from open(), but in our RXTX API, claiming is done every call to open(), we cant open the port if its claimed by another application. Would it be alright to suggest or ask to create a new method called claim(..)? Is there such thing as forceclaim() in RXTX? this could be the same as portownership transfer or its equivalent. ForceClaim is in JSR80. Do you have some samples using RXTX as the lower layer for the Device Service Objects in JavaPOS? I have tried it, i just want to compare. Thank you all! maxim __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060324/496adba2/attachment-0039.html From tjarvi at qbang.org Fri Mar 24 11:28:19 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 24 Mar 2006 11:28:19 -0700 (MST) Subject: [Rxtx] Re: RXTX 2.1 Solaris Problems In-Reply-To: <3691.1143210578@www045.gmx.net> References: <3691.1143210578@www045.gmx.net> Message-ID: On Fri, 24 Mar 2006, Andreas Guenther wrote: > Hi all, > > the solaris problem was not the lock file only. > > Ok, I had to create the directory /var/spool/locks myself. > /var/spool/uucp exists. > > But rxtx didn't find any port. > > I compiled the source with my own debug-informations > and I tried to isolate the problem. > > The problem is the testRead-call in SerialImp.c > > JNIEXPORT jboolean JNICALL RXTXCommDriver(testRead)( > > ... > if ( READ( fd, &c, 1 ) < 0 ) > { > if ( errno != EAGAIN ) { > report( "testRead() read failed\n" ); > ret = JNI_FALSE; > } > } > Thanks Andreas I'm packing up to move. I'll be more or less away for a couple weeks here. I'll be checking email but my workstation is going into a box soon. This isn't hard to fix as this port should be enumerated when EWOULDBLOCK is recieved. Thats error is OK for enumeration just as EAGAIN is. I've put the bug into bugzilla so we dont forget to get to it. http://bugzilla.qbang.org/show_bug.cgi?id=42 You can add yourself to the CC list if you wish to test fixes we provide or even put a patch into bugzilla yourself. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Fri Mar 24 11:51:52 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 24 Mar 2006 11:51:52 -0700 (MST) Subject: [Rxtx] JavaPOS In-Reply-To: <20060324082238.66371.qmail@web38214.mail.mud.yahoo.com> References: <20060324082238.66371.qmail@web38214.mail.mud.yahoo.com> Message-ID: On Fri, 24 Mar 2006, Maximulo Majir wrote: > Hi all! Hello Trent! > > > From what i understand, RXTX or JavaComm APIs were not > created solely for JavaPOS. In JavaPOS, we have the virtual method > claim() which is separate from open(), but in our RXTX API, claiming is > done every call to open(), we cant open the port if its claimed by > another application. Would it be alright to suggest or ask to create a > new method called claim(..)? Is there such thing as forceclaim() in > RXTX? this could be the same as portownership transfer or its > equivalent. ForceClaim is in JSR80. > Do you have some samples using RXTX as the lower layer for the Device > Service Objects in JavaPOS? I have tried it, i just want to compare. > maxim Hi Maxim JSR80 is the USB API IBM/Sun put together. The problem is they have a richer kernel/API underneath that can handle such things. With Serial Ports, there isnt anything there other than an ioctl that says don't let anyone touch this and lockfiles that are more of a 'lets be nice.' At times we may be using USB ports but it is through the termios layer with the limitations mentioned. The advantage is that not only USB will work with rxtx. Anything that has a termios layer should work (to the extent that termios layer is complete). I don't know how forceclaim() would help you. Lets say someone has a programmer working on /dev/ttyS0 and you take it. Now you both race each other to read data first. There isn't a mechanism I know of that will solve this problem in termios. The most obvious test being a native app and a Java app trying to take the port. There is the potential of requestion ownership from other Java Applications but the use for that is very rare. Did you have something more specific in mind that I'm missing? I'm not sure that claim() and forceclaim() would help you with rxtx other than maybe locking the port with claim() without opening it. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sat Mar 25 23:42:08 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 25 Mar 2006 23:42:08 -0700 (MST) Subject: [Rxtx] Serial snoop Message-ID: I was reading the Linux kernel mail-list tonight and ran past a thread that mentioned sersnoop. This looks like a handy tool for people dealing with new toys. "a simple command-line tool for linux that echoes bytes to and from any two serial ports, ptys, or network sockets, and prints all traffic to stdout, in hex and ascii." http://www.restivo.org/projects/sersnoop/ It works on Linux only at this time (debian package available). -- Trent Jarvi tjarvi at qbang.org From beat.arnet at gmail.com Sun Mar 26 07:32:35 2006 From: beat.arnet at gmail.com (Beat Arnet) Date: Sun, 26 Mar 2006 09:32:35 -0500 Subject: [Rxtx] Error 0x5 at /home/bob/foo/tar/rxtx-2.1-7/build/../src/termios.c(860): Access is, denied. Message-ID: <4426A603.80508@gmail.com> Dear all, When trying to open the serial port, I sometimes (not always) run into the following exception (when opening the serialPort): Error 0x5 at /home/bob/foo/tar/rxtx-2.1-7/build/../src/termios.c(860): Access is denied. java.lang.UnsatisfiedLinkError: native_psmisc_report_owner at gnu.io.CommPortIdentifier.native_psmisc_report_owner(Native Method) at gnu.io.CommPortIdentifier.open(CommPortIdentifier.java:354) at codeskin.tools.CLLoader.open(CLLoader.java:79) at codeskin.tools.C2000Programmer.run(C2000Programmer.java:220) at java.lang.Thread.run(Unknown Source) Is this the type of error where I should just try to open the port again, or can it be avoided? Regards, Beat From tjarvi at qbang.org Sun Mar 26 11:40:12 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 26 Mar 2006 11:40:12 -0700 (MST) Subject: [Rxtx] Error 0x5 at /home/bob/foo/tar/rxtx-2.1-7/build/../src/termios.c(860): Access is, denied. In-Reply-To: <4426A603.80508@gmail.com> References: <4426A603.80508@gmail.com> Message-ID: On Sun, 26 Mar 2006, Beat Arnet wrote: > Dear all, > > When trying to open the serial port, I sometimes (not always) run into > the following exception (when opening the serialPort): > > Error 0x5 at /home/bob/foo/tar/rxtx-2.1-7/build/../src/termios.c(860): > Access is > denied. > > java.lang.UnsatisfiedLinkError: native_psmisc_report_owner > at gnu.io.CommPortIdentifier.native_psmisc_report_owner(Native > Method) > at gnu.io.CommPortIdentifier.open(CommPortIdentifier.java:354) > at codeskin.tools.CLLoader.open(CLLoader.java:79) > at codeskin.tools.C2000Programmer.run(C2000Programmer.java:220) > at java.lang.Thread.run(Unknown Source) > > Is this the type of error where I should just try to open the port again, > or can it be avoided? > Hi Beat We did a second build of rxtx 2.1-7 to resolve that unsatisfied link error. It should work now. rxtx is trying to tell you it thinks someone else has the serial port open. You can try to open the port again but maybe you already have a copy of the program running when it happens? ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7r2.zip fixed build. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sun Mar 26 11:44:23 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 26 Mar 2006 11:44:23 -0700 (MST) Subject: [Rxtx] RXTX spec file (fwd) Message-ID: This is probably interesting for fedora/suse users. ---------- Forwarded message ---------- Date: Sun, 26 Mar 2006 16:25:45 +0200 To: taj at www.linux.org.uk Subject: RXTX spec file I send you this spec file which allows to create a RPM for Fedora 4, 5 (x86, x86_64) with Java Sun. -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: rxtx.spec Url: http://mailman.qbang.org/pipermail/rxtx/attachments/20060326/6c7b6af6/rxtx-0035.pl From tjarvi at qbang.org Sun Mar 26 23:42:59 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 26 Mar 2006 23:42:59 -0700 (MST) Subject: [Rxtx] Upcomming events. Message-ID: This Wednesday we will be announcing a new "Maintainer" for the rxtx project. The position is more like neutral leader. I wont be going away or doing less. This is just the right thing to do as it turns out the two people with CVS write access will be at the same company. We need a third and we need neutrality. The maintainer will have final say in any conflict and will try to be neutral. It will be open for discussion. Then we will do it :) I'll still do most of the footwork I do now. But. I'm falling behind. I should have gone through the mail-list and posted the next round of changes this weekend. I'm packing to move and its going so so - 13 years of toys collected. I suspect there will be a dead period on my part (a couple weeks) comming up. But if you get it on the mail-list, we will get it in if there are no objections. I may well not be reading the mail-list during this period as I look for a house and many other things. I hope everyone will help out. Thanks -- Trent Jarvi tjarvi at qbang.org From mahmoud_hadad at yahoo.com Sun Mar 26 07:31:19 2006 From: mahmoud_hadad at yahoo.com (ronan nick) Date: Sun, 26 Mar 2006 06:31:19 -0800 (PST) Subject: [Rxtx] a question about the COMM API Message-ID: <20060326143119.54919.qmail@web60014.mail.yahoo.com> hi, i was intrested in knowing how i can communicate with my internal modem using java? for example if i want to make a phone dialer application or a caller id application where should i be looking at? and as i understood the COMM API is for devices that is attached to the computer through serial ports. --------------------------------- New Yahoo! Messenger with Voice. Call regular phones from your PC and save big. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060326/ce8329f0/attachment-0037.html From dmarkman at mac.com Mon Mar 20 00:20:43 2006 From: dmarkman at mac.com (Dmitry Markman) Date: Mon, 20 Mar 2006 02:20:43 -0500 Subject: [Rxtx] Mac OS X RXTX java installer In-Reply-To: References: <07D0DE29-BA32-4CFE-B036-66BC6423D385@buechse.de> <441AE3E0.2030503@willicon.de> <12531986.1142622114996.JavaMail.dmarkman@mac.com> <441B2674.9010409@willicon.de> <13577405.1142634732776.JavaMail.dmarkman@mac.com> <441B4182.8010407@willicon.de> <92CD0D6C-5BE8-426E-A46D-99452059FF49@mac.com> <441BBB2D.8030305@willicon.de> <441C4088.5090905@willicon.de> Message-ID: <64BC1E23-FDDE-4CE6-8863-CFC881CBC224@mac.com> Hi all I put RXTX installer that will install everything (and will create / var/lock if necessary and add user to the uucp group) for mac os x from Java into the rxtx's CVS repository it could be easily modified to install files for any platform it uses Greg Guerin's AuthKit for authentication and authorization Greg released that kit under artistic license, so Trent, please take a look we, probably, can negotiate license with Greg if it's necessary Greg's AuthKit could be downloaded from http://www.amug.org/~glguerin/ sw/#authkit Michael Hall (mikehall at spacestar dot net) had a suggestion to make implementation of the jaas LoginModule based on Greg's AuthKit (his modification of the Greg's AuthKit could be found at http:// www.spacestar.net/users/mikehall/authkit.dmg) but Michael's AuthKitLoginModule does only half a job: it does authenticate but it can not run any external unix process in privileged mode (at least I wasn't able to do so) possible explanation could be found in conversation between Greg and Michael at Apple's java-dev list (look for archives) so I didn't use jaas API for rxtxinstaller I created folder MacOSX in the contrib folder comment 1. if you want to run that installer as standalone application all you need that RXTXInstaller.jar 2. if you want to use webstart you have to add Greg's libAuthKit.jnilib to the mac os x's resources in theory RXTXInstaller.jar doesn't need it, but there is a problem with loading libAuthKit.jnilib from webstart authkit uses loadLibrary method to load library and it failed (from webstart) for standalone application I extract libAuthKit.jnilib from the RXTXInstaller.jar and put it into the /Library/Java/Extensions or ~/Library/Java/Extensions folder that file will be deleted after installer quit unfortunately I didn't have time to put documentation there but it is mostly self-explanatory I took installer code from my gl4java installer that I did about 3 years ago (with small modifications) it would be very nice if Apple will release LoginModule that really will do the job (com.apple.security.auth.module package????? ) (UnixLoginModule is pretty useless) From lyon at docjava.com Mon Mar 20 06:34:39 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Mon, 20 Mar 2006 08:34:39 -0500 Subject: [Rxtx] Mac OS X RXTX java installer In-Reply-To: <64BC1E23-FDDE-4CE6-8863-CFC881CBC224@mac.com> References: <07D0DE29-BA32-4CFE-B036-66BC6423D385@buechse.de> <441AE3E0.2030503@willicon.de> <12531986.1142622114996.JavaMail.dmarkman@mac.com> <441B2674.9010409@willicon.de> <13577405.1142634732776.JavaMail.dmarkman@mac.com> <441B4182.8010407@willicon.de> <92CD0D6C-5BE8-426E-A46D-99452059FF49@mac.com> <441BBB2D.8030305@willicon.de> <441C4088.5090905@willicon.de> <64BC1E23-FDDE-4CE6-8863-CFC881CBC224@mac.com> Message-ID: Hi Dimitry, This sounds like great work. Just a couple of questions; After the check out of the CVS files, using: setenv CVSROOT :pserver:anonymous at cvs.milestonesolutions.com:/usr/local/cvsroot 53 8:28 setenv PASSWORD mousy 54 8:29 cvs login 55 8:29 cvs checkout rxtx-devel I cd'd over to: rxtx-devel/MACOSX_IDE And found: CVS/ CW/ ForPackageMaker/ PB/ Where is the installer? Thanks! - Doug From tjarvi at qbang.org Mon Mar 20 06:39:37 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 20 Mar 2006 06:39:37 -0700 (MST) Subject: [Rxtx] Mac OS X RXTX java installer In-Reply-To: References: <07D0DE29-BA32-4CFE-B036-66BC6423D385@buechse.de> <441AE3E0.2030503@willicon.de> <12531986.1142622114996.JavaMail.dmarkman@mac.com> <441B2674.9010409@willicon.de> <13577405.1142634732776.JavaMail.dmarkman@mac.com> <441B4182.8010407@willicon.de> <92CD0D6C-5BE8-426E-A46D-99452059FF49@mac.com> <441BBB2D.8030305@willicon.de> <441C4088.5090905@willicon.de> <64BC1E23-FDDE-4CE6-8863-CFC881CBC224@mac.com> Message-ID: On Mon, 20 Mar 2006, Dr. Douglas Lyon wrote: > Hi Dimitry, > This sounds like great work. Just a couple of questions; > After the check out of the CVS files, using: > setenv CVSROOT > :pserver:anonymous at cvs.milestonesolutions.com:/usr/local/cvsroot > 53 8:28 setenv PASSWORD mousy > 54 8:29 cvs login > 55 8:29 cvs checkout rxtx-devel Hi Doug You want "cvs checkout -r commapi-0-0-1 rxtx-devel" to get RXTX 2.1 The default branch is rxtx 2.0 which isn't very active right now. -- Trent Jarvi tjarvi at qbang.org From lyon at docjava.com Mon Mar 20 07:05:44 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Mon, 20 Mar 2006 09:05:44 -0500 Subject: [Rxtx] Mac OS X RXTX java installer In-Reply-To: References: <07D0DE29-BA32-4CFE-B036-66BC6423D385@buechse.de> <441AE3E0.2030503@willicon.de> <12531986.1142622114996.JavaMail.dmarkman@mac.com> <441B2674.9010409@willicon.de> <13577405.1142634732776.JavaMail.dmarkman@mac.com> <441B4182.8010407@willicon.de> <92CD0D6C-5BE8-426E-A46D-99452059FF49@mac.com> <441BBB2D.8030305@willicon.de> <441C4088.5090905@willicon.de> <64BC1E23-FDDE-4CE6-8863-CFC881CBC224@mac.com> Message-ID: Hi Trent, Thanks for the info on the CVS checkout procedure. I did that and am still not sure where the installer is. Here is what I have: cd MACOSX_IDE/ p4.docjava.com{lyon}121: ls CVS/ ForPackageMaker/ PB/ p4.docjava.com{lyon}122: find . | more . ./ForPackageMaker ./ForPackageMaker/RXTX.pkg.sit.hqx ./ForPackageMaker/Resources ./ForPackageMaker/Resources/ReadMe.rtf ./ForPackageMaker/Resources/Welcome.rtf ./ForPackageMaker/Resources/CVS ./ForPackageMaker/Resources/CVS/Entries ./ForPackageMaker/Resources/CVS/Repository ./ForPackageMaker/Resources/CVS/Tag ./ForPackageMaker/Resources/CVS/Root ./ForPackageMaker/Resources/preinstall ./ForPackageMaker/Resources/License.rtf ./ForPackageMaker/Resources/preupgrade ./ForPackageMaker/RXTX.pmsp ./ForPackageMaker/CVS ./ForPackageMaker/CVS/Entries ./ForPackageMaker/CVS/Repository ./ForPackageMaker/CVS/Entries.Log ./ForPackageMaker/CVS/Tag ./ForPackageMaker/CVS/Root ./ForPackageMaker/RXTX_Tiger.pkg.sitx.hqx ./ForPackageMaker/RXTX_Jag.pkg.sit.hqx ./ForPackageMaker/Install ./ForPackageMaker/Install/CVS ./ForPackageMaker/Install/CVS/Entries ./ForPackageMaker/Install/CVS/Repository ./ForPackageMaker/Install/CVS/Tag ./ForPackageMaker/Install/CVS/Root ./ForPackageMaker/Install/Library ./ForPackageMaker/Install/Library/CVS ./ForPackageMaker/Install/Library/CVS/Entries ./ForPackageMaker/Install/Library/CVS/Repository ./ForPackageMaker/Install/Library/CVS/Tag ./ForPackageMaker/Install/Library/CVS/Root ./ForPackageMaker/Install/Library/Java ./ForPackageMaker/Install/Library/Java/Extensions ./ForPackageMaker/Install/Library/Java/Extensions/RXTXcomm.jar ./ForPackageMaker/Install/Library/Java/Extensions/CVS ./ForPackageMaker/Install/Library/Java/Extensions/CVS/Entries ./ForPackageMaker/Install/Library/Java/Extensions/CVS/Repository ./ForPackageMaker/Install/Library/Java/Extensions/CVS/Tag ./ForPackageMaker/Install/Library/Java/Extensions/CVS/Root ./ForPackageMaker/Install/Library/Java/Extensions/librxtxSerial.jnilib ./ForPackageMaker/Install/Library/Java/CVS ./ForPackageMaker/Install/Library/Java/CVS/Entries ./ForPackageMaker/Install/Library/Java/CVS/Repository ./ForPackageMaker/Install/Library/Java/CVS/Entries.Log ./ForPackageMaker/Install/Library/Java/CVS/Tag ./ForPackageMaker/Install/Library/Java/CVS/Root ./ForPackageMaker/RXTX_Tiger.pmproj.sitx.hqx ./CVS ./CVS/Entries ./CVS/Repository ./CVS/Entries.Log ./CVS/Tag ./CVS/Root ./PB ./PB/LibSerialUniversal.xcodeproj.sitx.hqx ./PB/CVS ./PB/CVS/Entries ./PB/CVS/Repository ./PB/CVS/Entries.Log ./PB/CVS/Tag ./PB/CVS/Root ./PB/LibSerial.pbproj.sit.hqx ./PB/startpoint.c ./PB/config.h What is the procedure to run this installer? Do we need a README in: /rxtx-devel/MACOSX_IDE Here is what we have: CVS/ ForPackageMaker/ PB/ Thanks! - DL >On Mon, 20 Mar 2006, Dr. Douglas Lyon wrote: > >>Hi Dimitry, >>This sounds like great work. Just a couple of questions; >>After the check out of the CVS files, using: >>setenv CVSROOT >>:pserver:anonymous at cvs.milestonesolutions.com:/usr/local/cvsroot >> 53 8:28 setenv PASSWORD mousy >> 54 8:29 cvs login >> 55 8:29 cvs checkout rxtx-devel > >Hi Doug > >You want "cvs checkout -r commapi-0-0-1 rxtx-devel" to get RXTX 2.1 >The default branch is rxtx 2.0 which isn't very active right now. > >-- >Trent Jarvi >tjarvi at qbang.org From tjarvi at qbang.org Mon Mar 20 07:25:30 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 20 Mar 2006 07:25:30 -0700 (MST) Subject: [Rxtx] Mac OS X RXTX java installer In-Reply-To: References: <07D0DE29-BA32-4CFE-B036-66BC6423D385@buechse.de> <441AE3E0.2030503@willicon.de> <12531986.1142622114996.JavaMail.dmarkman@mac.com> <441B2674.9010409@willicon.de> <13577405.1142634732776.JavaMail.dmarkman@mac.com> <441B4182.8010407@willicon.de> <92CD0D6C-5BE8-426E-A46D-99452059FF49@mac.com> <441BBB2D.8030305@willicon.de> <441C4088.5090905@willicon.de> <64BC1E23-FDDE-4CE6-8863-CFC881CBC224@mac.com> Message-ID: On Mon, 20 Mar 2006, Dr. Douglas Lyon wrote: > Hi Trent, > Thanks for the info on the CVS checkout procedure. > I did that and am still not sure where the installer is. Hi Doug It does look like it was not cvs committed. There is no rxtx-devel/contrib/MacOSX directory in there at the moment. It was mentioned that it was put under contrib. -- Trent Jarvi tjarvi at qbang.org From dmarkman at mac.com Mon Mar 20 07:29:56 2006 From: dmarkman at mac.com (Dmitry Markman) Date: Mon, 20 Mar 2006 09:29:56 -0500 Subject: [Rxtx] Mac OS X RXTX java installer In-Reply-To: References: <07D0DE29-BA32-4CFE-B036-66BC6423D385@buechse.de> <441AE3E0.2030503@willicon.de> <12531986.1142622114996.JavaMail.dmarkman@mac.com> <441B2674.9010409@willicon.de> <13577405.1142634732776.JavaMail.dmarkman@mac.com> <441B4182.8010407@willicon.de> <92CD0D6C-5BE8-426E-A46D-99452059FF49@mac.com> <441BBB2D.8030305@willicon.de> <441C4088.5090905@willicon.de> <64BC1E23-FDDE-4CE6-8863-CFC881CBC224@mac.com> Message-ID: <6054EB4E-F7E0-4A9C-BDDA-D582D6D8826F@mac.com> you can find it in the rxtx-devel/contrib folder On Mar 20, 2006, at 9:05 AM, Dr. Douglas Lyon wrote: > Hi Trent, > Thanks for the info on the CVS checkout procedure. > I did that and am still not sure where the installer is. > Here is what I have: > cd MACOSX_IDE/ > p4.docjava.com{lyon}121: ls > CVS/ ForPackageMaker/ PB/ > p4.docjava.com{lyon}122: find . | more > . > ./ForPackageMaker > ./ForPackageMaker/RXTX.pkg.sit.hqx > ./ForPackageMaker/Resources > ./ForPackageMaker/Resources/ReadMe.rtf > ./ForPackageMaker/Resources/Welcome.rtf > ./ForPackageMaker/Resources/CVS > ./ForPackageMaker/Resources/CVS/Entries > ./ForPackageMaker/Resources/CVS/Repository > ./ForPackageMaker/Resources/CVS/Tag > ./ForPackageMaker/Resources/CVS/Root > ./ForPackageMaker/Resources/preinstall > ./ForPackageMaker/Resources/License.rtf > ./ForPackageMaker/Resources/preupgrade > ./ForPackageMaker/RXTX.pmsp > ./ForPackageMaker/CVS > ./ForPackageMaker/CVS/Entries > ./ForPackageMaker/CVS/Repository > ./ForPackageMaker/CVS/Entries.Log > ./ForPackageMaker/CVS/Tag > ./ForPackageMaker/CVS/Root > ./ForPackageMaker/RXTX_Tiger.pkg.sitx.hqx > ./ForPackageMaker/RXTX_Jag.pkg.sit.hqx > ./ForPackageMaker/Install > ./ForPackageMaker/Install/CVS > ./ForPackageMaker/Install/CVS/Entries > ./ForPackageMaker/Install/CVS/Repository > ./ForPackageMaker/Install/CVS/Tag > ./ForPackageMaker/Install/CVS/Root > ./ForPackageMaker/Install/Library > ./ForPackageMaker/Install/Library/CVS > ./ForPackageMaker/Install/Library/CVS/Entries > ./ForPackageMaker/Install/Library/CVS/Repository > ./ForPackageMaker/Install/Library/CVS/Tag > ./ForPackageMaker/Install/Library/CVS/Root > ./ForPackageMaker/Install/Library/Java > ./ForPackageMaker/Install/Library/Java/Extensions > ./ForPackageMaker/Install/Library/Java/Extensions/RXTXcomm.jar > ./ForPackageMaker/Install/Library/Java/Extensions/CVS > ./ForPackageMaker/Install/Library/Java/Extensions/CVS/Entries > ./ForPackageMaker/Install/Library/Java/Extensions/CVS/Repository > ./ForPackageMaker/Install/Library/Java/Extensions/CVS/Tag > ./ForPackageMaker/Install/Library/Java/Extensions/CVS/Root > ./ForPackageMaker/Install/Library/Java/Extensions/librxtxSerial.jnilib > ./ForPackageMaker/Install/Library/Java/CVS > ./ForPackageMaker/Install/Library/Java/CVS/Entries > ./ForPackageMaker/Install/Library/Java/CVS/Repository > ./ForPackageMaker/Install/Library/Java/CVS/Entries.Log > ./ForPackageMaker/Install/Library/Java/CVS/Tag > ./ForPackageMaker/Install/Library/Java/CVS/Root > ./ForPackageMaker/RXTX_Tiger.pmproj.sitx.hqx > ./CVS > ./CVS/Entries > ./CVS/Repository > ./CVS/Entries.Log > ./CVS/Tag > ./CVS/Root > ./PB > ./PB/LibSerialUniversal.xcodeproj.sitx.hqx > ./PB/CVS > ./PB/CVS/Entries > ./PB/CVS/Repository > ./PB/CVS/Entries.Log > ./PB/CVS/Tag > ./PB/CVS/Root > ./PB/LibSerial.pbproj.sit.hqx > ./PB/startpoint.c > ./PB/config.h > > What is the procedure to run this installer? > Do we need a README in: > /rxtx-devel/MACOSX_IDE > Here is what we have: > CVS/ ForPackageMaker/ PB/ > > > Thanks! > - DL > >> On Mon, 20 Mar 2006, Dr. Douglas Lyon wrote: >> >>> Hi Dimitry, >>> This sounds like great work. Just a couple of questions; >>> After the check out of the CVS files, using: >>> setenv CVSROOT :pserver:anonymous at cvs.milestonesolutions.com:/usr/ >>> local/cvsroot >>> 53 8:28 setenv PASSWORD mousy >>> 54 8:29 cvs login >>> 55 8:29 cvs checkout rxtx-devel >> >> Hi Doug >> >> You want "cvs checkout -r commapi-0-0-1 rxtx-devel" to get RXTX 2.1 >> The default branch is rxtx 2.0 which isn't very active right now. >> >> -- >> Trent Jarvi >> tjarvi at qbang.org > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx Dmitry Markman From mikehall at spacestar.net Mon Mar 20 05:25:25 2006 From: mikehall at spacestar.net (Michael Hall) Date: Mon, 20 Mar 2006 06:25:25 -0600 Subject: [Rxtx] Re: Mac OS X RXTX java installer In-Reply-To: <64BC1E23-FDDE-4CE6-8863-CFC881CBC224@mac.com> References: <07D0DE29-BA32-4CFE-B036-66BC6423D385@buechse.de> <441AE3E0.2030503@willicon.de> <12531986.1142622114996.JavaMail.dmarkman@mac.com> <441B2674.9010409@willicon.de> <13577405.1142634732776.JavaMail.dmarkman@mac.com> <441B4182.8010407@willicon.de> <92CD0D6C-5BE8-426E-A46D-99452059FF49@mac.com> <441BBB2D.8030305@willicon.de> <441C4088.5090905@willicon.de> <64BC1E23-FDDE-4CE6-8863-CFC881CBC224@mac.com> Message-ID: <247EB61F-5CD1-4132-89A2-FC105B6CF9A5@spacestar.net> On Mar 20, 2006, at 1:20 AM, Dmitry Markman wrote: > > Michael Hall (mikehall at spacestar dot net) had a suggestion to > make implementation of the jaas LoginModule > based on Greg's AuthKit > (his modification of the Greg's AuthKit could be found at http:// > www.spacestar.net/users/mikehall/authkit.dmg) > but Michael's AuthKitLoginModule does only half a job: > it does authenticate > but it can not run any external unix process in privileged mode (at > least I wasn't able to do so) If you got it working directly with Greg's the point is moot. But to clarify it anyhow. The login module does not allow you to do anything anything privileged on return as was explained by Greg. You need to work with a separate privileged process using the execPrivileged method of his API. I assume you did something similar although I haven't looked at how you are using it yet. I allowed instead for a action to be performed at the same time you login/authenticate,this... System.setProperty("authkit.action","/usr/bin/id"); just before this... lc.login(); To clarify, safely ignored as you are already complete. Mike Hall mikehall at spacestar dot net http://www.spacestar.net/users/mikehall http://sourceforge.net/projects/macnative -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2427 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20060320/f6e18202/smime-0040.bin From dmarkman at mac.com Mon Mar 20 07:36:47 2006 From: dmarkman at mac.com (Dmitry Markman) Date: Mon, 20 Mar 2006 09:36:47 -0500 Subject: [Rxtx] Re: Mac OS X RXTX java installer In-Reply-To: <247EB61F-5CD1-4132-89A2-FC105B6CF9A5@spacestar.net> References: <07D0DE29-BA32-4CFE-B036-66BC6423D385@buechse.de> <441AE3E0.2030503@willicon.de> <12531986.1142622114996.JavaMail.dmarkman@mac.com> <441B2674.9010409@willicon.de> <13577405.1142634732776.JavaMail.dmarkman@mac.com> <441B4182.8010407@willicon.de> <92CD0D6C-5BE8-426E-A46D-99452059FF49@mac.com> <441BBB2D.8030305@willicon.de> <441C4088.5090905@willicon.de> <64BC1E23-FDDE-4CE6-8863-CFC881CBC224@mac.com> <247EB61F-5CD1-4132-89A2-FC105B6CF9A5@spacestar.net> Message-ID: Hi, Michael all I have to do is to run some shell script I tried to use your action mechanism and it worked great so I just System.setProperty ("authkit.action","" ) and after that I even don't need to run anything like subject.doAs.... but after few thoughts I choose to use plain Greg's approach, because in that case I don't have to deal with various java's configurations files and therefore to use 2-3 -D parameters in the java command line especially it's useful for java web start (it's so fragile :-( ) thanks for the great job On Mar 20, 2006, at 7:25 AM, Michael Hall wrote: > > On Mar 20, 2006, at 1:20 AM, Dmitry Markman wrote: >> >> Michael Hall (mikehall at spacestar dot net) had a suggestion to >> make implementation of the jaas LoginModule >> based on Greg's AuthKit >> (his modification of the Greg's AuthKit could be found at http:// >> www.spacestar.net/users/mikehall/authkit.dmg) >> but Michael's AuthKitLoginModule does only half a job: >> it does authenticate >> but it can not run any external unix process in privileged mode >> (at least I wasn't able to do so) > > If you got it working directly with Greg's the point is moot. > > But to clarify it anyhow. > The login module does not allow you to do anything anything > privileged on return as was explained by Greg. You need to work > with a separate privileged process using the execPrivileged method > of his API. I assume you did something similar although I haven't > looked at how you are using it yet. > I allowed instead for a action to be performed at the same time you > login/authenticate,this... > System.setProperty("authkit.action","/usr/bin/id"); > just before this... > lc.login(); > To clarify, safely ignored as you are already complete. > > Mike Hall mikehall at spacestar dot net > http://www.spacestar.net/users/mikehall > http://sourceforge.net/projects/macnative > > > Dmitry Markman From dmarkman at mac.com Mon Mar 20 07:44:45 2006 From: dmarkman at mac.com (Dmitry Markman) Date: Mon, 20 Mar 2006 09:44:45 -0500 Subject: [Rxtx] Mac OS X RXTX java installer In-Reply-To: References: <07D0DE29-BA32-4CFE-B036-66BC6423D385@buechse.de> <441AE3E0.2030503@willicon.de> <12531986.1142622114996.JavaMail.dmarkman@mac.com> <441B2674.9010409@willicon.de> <13577405.1142634732776.JavaMail.dmarkman@mac.com> <441B4182.8010407@willicon.de> <92CD0D6C-5BE8-426E-A46D-99452059FF49@mac.com> <441BBB2D.8030305@willicon.de> <441C4088.5090905@willicon.de> <64BC1E23-FDDE-4CE6-8863-CFC881CBC224@mac.com> Message-ID: it's in the commapi-0-0-1 branch I tested it right now: cvs co -r commapi-0-0-1 rxtx-devel and I got everything On Mar 20, 2006, at 9:25 AM, Trent Jarvi wrote: > On Mon, 20 Mar 2006, Dr. Douglas Lyon wrote: > >> Hi Trent, >> Thanks for the info on the CVS checkout procedure. >> I did that and am still not sure where the installer is. > > Hi Doug > > It does look like it was not cvs committed. There is no rxtx-devel/ > contrib/MacOSX directory in there at the moment. It was mentioned > that it was put under contrib. > > -- > Trent Jarvi > tjarvi at qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx Dmitry Markman From tjarvi at qbang.org Mon Mar 20 07:52:57 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 20 Mar 2006 07:52:57 -0700 (MST) Subject: [Rxtx] Mac OS X RXTX java installer In-Reply-To: References: <07D0DE29-BA32-4CFE-B036-66BC6423D385@buechse.de> <441AE3E0.2030503@willicon.de> <12531986.1142622114996.JavaMail.dmarkman@mac.com> <441B2674.9010409@willicon.de> <13577405.1142634732776.JavaMail.dmarkman@mac.com> <441B4182.8010407@willicon.de> <92CD0D6C-5BE8-426E-A46D-99452059FF49@mac.com> <441BBB2D.8030305@willicon.de> <441C4088.5090905@willicon.de> <64BC1E23-FDDE-4CE6-8863-CFC881CBC224@mac.com> Message-ID: On Mon, 20 Mar 2006, Dmitry Markman wrote: > it's in the commapi-0-0-1 branch > > I tested it right now: > cvs co -r commapi-0-0-1 rxtx-devel > > and I got everything > A fresh checkout worked. Here is a copy of the tree (just the installer bits) ftp://ftp.qbang.org/pub/rxtx/MacOSX-installer.zip -- Trent Jarvi tjarvi at qbang.org From lyon at docjava.com Mon Mar 20 08:08:26 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Mon, 20 Mar 2006 10:08:26 -0500 Subject: [Rxtx] Mac OS X RXTX java installer In-Reply-To: References: <07D0DE29-BA32-4CFE-B036-66BC6423D385@buechse.de> <441AE3E0.2030503@willicon.de> <12531986.1142622114996.JavaMail.dmarkman@mac.com> <441B2674.9010409@willicon.de> <13577405.1142634732776.JavaMail.dmarkman@mac.com> <441B4182.8010407@willicon.de> <92CD0D6C-5BE8-426E-A46D-99452059FF49@mac.com> <441BBB2D.8030305@willicon.de> <441C4088.5090905@willicon.de> <64BC1E23-FDDE-4CE6-8863-CFC881CBC224@mac.com> Message-ID: Hi All, Is the Auth package able to work properly on non Mac OS's? It was not clear from the doc or download. Thanks! - Doug From dmarkman at mac.com Mon Mar 20 08:15:22 2006 From: dmarkman at mac.com (Dmitry Markman) Date: Mon, 20 Mar 2006 10:15:22 -0500 Subject: [Rxtx] Mac OS X RXTX java installer In-Reply-To: References: <07D0DE29-BA32-4CFE-B036-66BC6423D385@buechse.de> <441AE3E0.2030503@willicon.de> <12531986.1142622114996.JavaMail.dmarkman@mac.com> <441B2674.9010409@willicon.de> <13577405.1142634732776.JavaMail.dmarkman@mac.com> <441B4182.8010407@willicon.de> <92CD0D6C-5BE8-426E-A46D-99452059FF49@mac.com> <441BBB2D.8030305@willicon.de> <441C4088.5090905@willicon.de> <64BC1E23-FDDE-4CE6-8863-CFC881CBC224@mac.com> Message-ID: <217312D8-CCCA-4859-ABA6-32DF1CC817B9@mac.com> thanks Trent, for putting it on ftp server On Mar 20, 2006, at 9:52 AM, Trent Jarvi wrote: > A fresh checkout worked. Here is a copy of the tree (just the > installer bits) > > ftp://ftp.qbang.org/pub/rxtx/MacOSX-installer.zip > Dmitry Markman From dmarkman at mac.com Mon Mar 20 09:14:03 2006 From: dmarkman at mac.com (Dmitry Markman) Date: Mon, 20 Mar 2006 11:14:03 -0500 Subject: [Rxtx] Mac OS X RXTX java installer In-Reply-To: References: <07D0DE29-BA32-4CFE-B036-66BC6423D385@buechse.de> <441AE3E0.2030503@willicon.de> <12531986.1142622114996.JavaMail.dmarkman@mac.com> <441B2674.9010409@willicon.de> <13577405.1142634732776.JavaMail.dmarkman@mac.com> <441B4182.8010407@willicon.de> <92CD0D6C-5BE8-426E-A46D-99452059FF49@mac.com> <441BBB2D.8030305@willicon.de> <441C4088.5090905@willicon.de> <64BC1E23-FDDE-4CE6-8863-CFC881CBC224@mac.com> Message-ID: <4DEBA6F0-DA45-4E84-823E-1F1AC48BDCCC@mac.com> no it will work only on mac os x however it's harmless to run it on other platform if you want to use it for other platform you have to do the following (I'll do it for linux) 1. modify RXTXInstaller class method public static RXTXInstaller getInstance() public static RXTXInstaller getInstance() { String osName = System.getProperty("os.name").toLowerCase(); if(osName.startsWith("mac")){ return new gnu.io.installer.macosx.MACOSXRXTXInstaller(); } else if(osName.startsWith("windows")){ return new gnu.io.installer.windows.WindowsRXTXInstaller(); }else if(osName.startsWith("linux")){ return new gnu.io.installer.linux.LinuxRXTXInstaller(); } return null; } 2. create folder gnu/io/installer/linux/ 3. create class Linux386RXTXInstaller package gnu.io.installer.linux; import java.io.File; public class Linux386RXTXInstaller extends gnu.io.installer.RXTXInstaller{ public Linux386RXTXInstaller(){ createJarFolder(); createLibFolder(); addJarResource("RXTXcomm.jar","/gnu/io/installer/resources/ linux/jar/RXTXcomm.dat"); addLibResource("librxtxSerial.so","/gnu/io/installer/ resources/linux/lib/librxtxSerial.so"); } protected void createJarFolder(){ String javaHome = System.getProperty("java.home"); char separator = File.separatorChar; jarFolder = new File(javaHome+separator+"lib"+separator+"ext"); } protected void createLibFolder(){ String javaHome = System.getProperty("java.home"); char separator = File.separatorChar; libFolder = new File(javaHome+separator+"bin"); } public void runPreProcess() {} //put here some action you need public void runPostProcess() {} //put here some action you need } 4. create folder /gnu/io/installer/resources/linux/jar and put there linux's version of RXTXcomm.dat (which is renamed RXTXcomm.jar) 5. create folder /gnu/io/installer/resources/linux/lib and put there linux's version of librxtxSerial. so 6. make sure that RXTXInstaller.jar has the following items: /gnu/io/installer/resources/linux/jar/RXTXcomm.jar /gnu/io/installer/resources/linux/lib/librxtxSerial.so 7. modify file installer.pref: jar file RXTXInstaller.jar must have the following item /gnu/io/installer/installer.pref that's basically it for windows you have to do the similar things: just replace linux to windows and librxtxSerial.so to rxtxSerial.dll and create appropriate gnu.io.installer.windows.WindowsRXTXInstaller class package gnu.io.installer.windows; import java.io.File; public class WindowsRXTXInstaller extends gnu.io.installer.RXTXInstaller{ public WindowsRXTXInstaller(){ createJarFolder(); createLibFolder(); addJarResource("RXTXcomm.jar","/gnu/io/installer/resources/ windows/jar/RXTXcomm.dat"); addLibResource("librxtxSerial.so","/gnu/io/installer/ resources/windows/lib/rxtxSerial.dll"); } protected void createJarFolder(){ String javaHome = System.getProperty("java.home"); char separator = File.separatorChar; jarFolder = new File(javaHome+separator+"lib"+separator+"ext"); } protected void createLibFolder(){ String javaHome = System.getProperty("java.home"); char separator = File.separatorChar; libFolder = new File(javaHome+separator+"bin"); } public void runPreProcess() {} //put here some action you need public void runPostProcess() {} //put here some action you need } installer.pref will look like On Mar 20, 2006, at 10:08 AM, Dr. Douglas Lyon wrote: > Hi All, > Is the Auth package able to work properly on > non Mac OS's? > It was not clear from the doc or download. > > Thanks! > - Doug > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx Dmitry Markman From joachim at buechse.de Mon Mar 20 10:49:06 2006 From: joachim at buechse.de (Joachim Buechse) Date: Mon, 20 Mar 2006 18:49:06 +0100 Subject: [Rxtx] BUG: Lock file stays even if port opening fails Message-ID: This was only tested on MacOSX but looking at the code, it should be true for all systems that use lock_uucp. I am opening a port which can not be opened (dialup port of a telephone paired via bluetooth but currently not reachable). The lock file is created and stays arround, even though the port open failed. After looking a bit through the code (of 2.17), I really wonder if it wouldn't be a good idea to make the "locking" an explicit operation called from the java code. This would certainly simplify the generation of meaningfull exceptions (and java based debugging). Maybe even the handling of "preopened" ports should be in the Java part of the lib (again for java based debugging puposes). That beeing said, I have no idea if this would be possible for the 2.07 implementation. Regards, Joachim From tjarvi at qbang.org Mon Mar 20 11:24:22 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 20 Mar 2006 11:24:22 -0700 (MST) Subject: [Rxtx] BUG: Lock file stays even if port opening fails In-Reply-To: References: Message-ID: On Mon, 20 Mar 2006, Joachim Buechse wrote: > This was only tested on MacOSX but looking at the code, it should be true > for all systems that use lock_uucp. > > I am opening a port which can not be opened (dialup port of a telephone > paired via bluetooth but currently not reachable). The lock file is > created and stays arround, even though the port open failed. > > > After looking a bit through the code (of 2.17), I really wonder if it > wouldn't be a good idea to make the "locking" an explicit operation > called from the java code. This would certainly simplify the generation > of meaningfull exceptions (and java based debugging). > Maybe even the handling of "preopened" ports should be in the Java part > of the lib (again for java based debugging puposes). That beeing said, I > have no idea if this would be possible for the 2.07 implementation. > > Regards, Hi Joachim It should be possible in the 2.0-7 implementation too. The calls to RXTXPort.java would not change. We would just do more there Moving more of that logic into Java would be better as many people don't like to look at C code. There is a liblockdev on most Linux distros that can do most of the C code and would be easier to use. The problem is embeded devices will not have that library. The preopened port code has not been really tested. That was a last minute request in a product cycle. I expect it will be tested this year though. As I recall, some devices really do not like CD raising on open. The preopened ports then allow people to mess around in java without power cycling the devices or losing data. -- Trent Jarvi tjarvi at qbang.org From joachim at buechse.de Mon Mar 20 12:01:08 2006 From: joachim at buechse.de (Joachim Buechse) Date: Mon, 20 Mar 2006 20:01:08 +0100 Subject: [Rxtx] BUG: Lock file stays even if port opening fails In-Reply-To: References: Message-ID: Hi Trent, What is your general feeling about moving code to Java? The last days I have been reading quite a bit of the code and there are several things, that might not work as expected. I'll give you two examples from is_device_locked: if LOCKDIR == /var/spool/locks the directory /var/spool/lock will not be checked. LOCKDIR is not checked for lockfiles with unexpected pefixes While these things have probably never been discovered in production, they are still possibly incorrect implementations. If it was Java code, I would write some unit tests producing the errors that could later be corrected. PS: One could imagine to actually implement the whole lockfile handling in Java using some native routines to get the values required (pid, st_dev, st_rdev, ...). On 20.03.2006, at 19:24, Trent Jarvi wrote: > On Mon, 20 Mar 2006, Joachim Buechse wrote: > >> This was only tested on MacOSX but looking at the code, it should >> be true for all systems that use lock_uucp. >> >> I am opening a port which can not be opened (dialup port of a >> telephone paired via bluetooth but currently not reachable). The >> lock file is created and stays arround, even though the port open >> failed. >> >> >> After looking a bit through the code (of 2.17), I really wonder if >> it wouldn't be a good idea to make the "locking" an explicit >> operation called from the java code. This would certainly simplify >> the generation of meaningfull exceptions (and java based debugging). >> Maybe even the handling of "preopened" ports should be in the Java >> part of the lib (again for java based debugging puposes). That >> beeing said, I have no idea if this would be possible for the 2.07 >> implementation. >> >> Regards, > > Hi Joachim > > It should be possible in the 2.0-7 implementation too. The calls > to RXTXPort.java would not change. We would just do more there > Moving more of that logic into Java would be better as many people > don't like to look at C code. There is a liblockdev on most Linux > distros that can do most of the C code and would be easier to use. > The problem is embeded devices will not have that library. > > The preopened port code has not been really tested. That was a > last minute request in a product cycle. I expect it will be tested > this year though. As I recall, some devices really do not like CD > raising on open. The preopened ports then allow people to mess > around in java without power cycling the devices or losing data. > > -- > Trent Jarvi > tjarvi at qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Mon Mar 20 12:21:02 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 20 Mar 2006 12:21:02 -0700 (MST) Subject: [Rxtx] BUG: Lock file stays even if port opening fails In-Reply-To: References: Message-ID: On Mon, 20 Mar 2006, Joachim Buechse wrote: > Hi Trent, > > What is your general feeling about moving code to Java? The last days I > have been reading quite a bit of the code and there are several things, > that might not work as expected. > > I'll give you two examples from is_device_locked: > > if LOCKDIR == /var/spool/locks the directory /var/spool/lock will not be > checked. > LOCKDIR is not checked for lockfiles with unexpected pefixes > > While these things have probably never been discovered in production, > they are still possibly incorrect implementations. If it was Java code, I > would write some unit tests producing the errors that could later be > corrected. > > PS: One could imagine to actually implement the whole lockfile handling > in Java using some native routines to get the values required (pid, > st_dev, st_rdev, ...). Hi Joachim I like the idea of moving more of the code into java but there are some things to consider. If you break this into multiple JNI calls, the performance will drop considerably during enumeration of ports. We are looking for 256 ports per dev type vs (16? in Sun's 2.0 and fewer types). Its hard to make assumptions. I've seen virtual ports start at /dev/foo100 for instance. It works out to over 7500 ports on Linux if you enable them all. We already trim that back by default. See Linux-all-ports in RXTXCommDriver.java. There are also native libraries that rxtx can link to. If you move too much into Java, linking to 'standard' libraries with distros will break. "configure --enable-liblock=yes" will not be doable. This is probably a favorable way with RedHat, Debian, Suse and others. Thats the right thing to do if there will be rpms, dpkg, .. For those reasons, I think it still make sense to keep it to a minimal ~3 calls to JNI code that we can use for speed and versatility. lock() isLocked(), unlock() perhaps. When I say speed, its more about avoiding crossing the JNI layer multiple times than java vs C performance. With versatility I think liblock is the right way for most but not all (embeded) linux distros. -- Trent Jarvi tjarvi at qbang.org From joachim at buechse.de Mon Mar 20 12:42:04 2006 From: joachim at buechse.de (Joachim Buechse) Date: Mon, 20 Mar 2006 20:42:04 +0100 Subject: [Rxtx] BUG: Lock file stays even if port opening fails In-Reply-To: References: Message-ID: <82C19FE7-DDCB-45B6-B2C9-7606B66F0124@buechse.de> Ok, what about providing a default implementation in Java? The RXTXCommDriver would call a (native) function useNativeLocking and if it returns true, call the native functions for lock() isLocked (), unlock(), else is would use the Java based default implementation. This could possibly be overriden by a property (again for debugging). Joachim On 20.03.2006, at 20:21, Trent Jarvi wrote: > On Mon, 20 Mar 2006, Joachim Buechse wrote: > >> Hi Trent, >> >> What is your general feeling about moving code to Java? The last >> days I have been reading quite a bit of the code and there are >> several things, that might not work as expected. >> >> I'll give you two examples from is_device_locked: >> >> if LOCKDIR == /var/spool/locks the directory /var/spool/lock will >> not be checked. >> LOCKDIR is not checked for lockfiles with unexpected pefixes >> >> While these things have probably never been discovered in >> production, they are still possibly incorrect implementations. If >> it was Java code, I would write some unit tests producing the >> errors that could later be corrected. >> >> PS: One could imagine to actually implement the whole lockfile >> handling in Java using some native routines to get the values >> required (pid, st_dev, st_rdev, ...). > > Hi Joachim > > I like the idea of moving more of the code into java but there are > some things to consider. > > If you break this into multiple JNI calls, the performance will > drop considerably during enumeration of ports. We are looking for > 256 ports per dev type vs (16? in Sun's 2.0 and fewer types). Its > hard to make assumptions. I've seen virtual ports start at /dev/ > foo100 for instance. > > It works out to over 7500 ports on Linux if you enable them all. > We already trim that back by default. See Linux-all-ports in > RXTXCommDriver.java. > > There are also native libraries that rxtx can link to. If you move > too much into Java, linking to 'standard' libraries with distros > will break. "configure --enable-liblock=yes" will not be doable. > This is probably a favorable way with RedHat, Debian, Suse and > others. Thats the right thing to do if there will be rpms, dpkg, .. > > For those reasons, I think it still make sense to keep it to a > minimal ~3 calls to JNI code that we can use for speed and > versatility. lock() isLocked(), unlock() perhaps. When I say > speed, its more about avoiding crossing the JNI layer multiple > times than java vs C performance. With versatility I think liblock > is the right way for most but not all (embeded) linux distros. > > -- > Trent Jarvi > tjarvi at qbang.org > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Mon Mar 20 12:44:47 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 20 Mar 2006 12:44:47 -0700 (MST) Subject: [Rxtx] BUG: Lock file stays even if port opening fails In-Reply-To: <82C19FE7-DDCB-45B6-B2C9-7606B66F0124@buechse.de> References: <82C19FE7-DDCB-45B6-B2C9-7606B66F0124@buechse.de> Message-ID: On Mon, 20 Mar 2006, Joachim Buechse wrote: > Ok, what about providing a default implementation in Java? > > The RXTXCommDriver would call a (native) function useNativeLocking and if > it returns true, call the native functions for lock() isLocked(), > unlock(), else is would use the Java based default implementation. This > could possibly be overriden by a property (again for debugging). > Hi Joachim That would be OK with me. -- Trent Jarvi tjarvi at qbang.org From dmarkman at mac.com Mon Mar 20 22:27:45 2006 From: dmarkman at mac.com (Dmitry Markman) Date: Tue, 21 Mar 2006 00:27:45 -0500 Subject: [Rxtx] binaries request Message-ID: <42702213-C222-4937-A585-7CFB17E47608@mac.com> Hi can somebody send me latest linux and windows binaries, please? or where I can find them (I didn't find them in the latest tareball) I gave up with my cygwin: something wrong I have no idea what java doesn't understand /cygwin/c syntax after I changed makefile it did java part but after that gcc 3.4.4 started to complain I set buffer length to 999 lines but I didn't get beginning of the story something wrong with my 1.4.2_09/include/jni.h gcc doesn't like it anyway I gave up thanks in advance Dmitry Markman -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060320/f8cbc57c/attachment-0040.html From tjarvi at qbang.org Mon Mar 20 22:36:48 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 20 Mar 2006 22:36:48 -0700 (MST) Subject: [Rxtx] binaries request In-Reply-To: <42702213-C222-4937-A585-7CFB17E47608@mac.com> References: <42702213-C222-4937-A585-7CFB17E47608@mac.com> Message-ID: On Tue, 21 Mar 2006, Dmitry Markman wrote: > Hi > can somebody send me latest linux and windows binaries, please? > > or where I can find them (I didn't find them in the latest tareball) > > I gave up with my cygwin: something wrong I have no idea what > java doesn't understand /cygwin/c syntax > after I changed makefile it did java part > but after that gcc 3.4.4 started to complain > I set buffer length to 999 lines but I didn't get beginning of the story > something wrong with my 1.4.2_09/include/jni.h gcc doesn't like it > anyway I gave up > > thanks in advance > Hi Dmitry The bins are here: ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7-bins-r2.zip Here are the files in the zip you want. Jar: rxtx-2.1-7-bins-r2/RXTXcomm.jar Windows: rxtx-2.1-7-bins-r2/Windows/i368-mingw32/rxtxSerial.dll Linux (x86) rxtx-2.1-7-bins-r2/Linux/i686-unknown-linux-gnu/librxtxSerial.so There are others in there including Parallel port support but those are the main ones for testing. -- Trent Jarvi tjarvi at qbang.org From dmarkman at mac.com Mon Mar 20 23:05:59 2006 From: dmarkman at mac.com (Dmitry Markman) Date: Tue, 21 Mar 2006 01:05:59 -0500 Subject: [Rxtx] binaries request In-Reply-To: References: <42702213-C222-4937-A585-7CFB17E47608@mac.com> Message-ID: thank you very much but windows's readme says: rxtxSerial.dll had to be recomopiled to link in missing native methods. should I ignore it? or what? thanks again also I understand that I should use mingw not cygwin I'll try to install mingw On Mar 21, 2006, at 12:36 AM, Trent Jarvi wrote: > On Tue, 21 Mar 2006, Dmitry Markman wrote: > >> Hi >> can somebody send me latest linux and windows binaries, please? >> >> or where I can find them (I didn't find them in the latest tareball) >> >> I gave up with my cygwin: something wrong I have no idea what >> java doesn't understand /cygwin/c syntax >> after I changed makefile it did java part >> but after that gcc 3.4.4 started to complain >> I set buffer length to 999 lines but I didn't get beginning of the >> story >> something wrong with my 1.4.2_09/include/jni.h gcc doesn't like it >> anyway I gave up >> >> thanks in advance >> > > Hi Dmitry > > The bins are here: > > ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7-bins-r2.zip > > Here are the files in the zip you want. > > Jar: > > rxtx-2.1-7-bins-r2/RXTXcomm.jar > > Windows: > > rxtx-2.1-7-bins-r2/Windows/i368-mingw32/rxtxSerial.dll > > Linux (x86) > > rxtx-2.1-7-bins-r2/Linux/i686-unknown-linux-gnu/librxtxSerial.so > > There are others in there including Parallel port support but those > are the main ones for testing. > > -- > Trent Jarvi > tjarvi at qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx Dmitry Markman From tjarvi at qbang.org Mon Mar 20 23:20:33 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 20 Mar 2006 23:20:33 -0700 (MST) Subject: [Rxtx] binaries request In-Reply-To: References: <42702213-C222-4937-A585-7CFB17E47608@mac.com> Message-ID: On Tue, 21 Mar 2006, Dmitry Markman wrote: > thank you very much > > but windows's readme says: > rxtxSerial.dll had to be recomopiled to link in missing native methods. > > should I ignore it? or what? > Hi Dmitry That dll should be OK. r2 is the recompile linked to the missing native method. The readme explains why it was recompiled; fuser.o was not linked into the dll in the first release. -- Trent Jarvi tjarvi at qbang.org From ariantristan at yahoo.com Mon Mar 20 23:55:24 2006 From: ariantristan at yahoo.com (Lambok Sianturi) Date: Mon, 20 Mar 2006 22:55:24 -0800 (PST) Subject: [Rxtx] jvm issue Message-ID: <20060321065524.94779.qmail@web50701.mail.yahoo.com> Hi All, This is my first time to join RxTx mailing list. I thank you all for allowing others to sign in in requests help. I use the latest RxTx lib in Fedora 3 with java version 1.4.2_09 b05. And I got this error: # # An unexpected error has been detected by HotSpot Virtual Machine: # # SIGSEGV (0xb) at pc=0x00bf27f3, pid=2633, tid=3086112448 # # Java VM: Java HotSpot(TM) Client VM (1.4.2_09-b05 mixed mode) # Problematic frame: # C [ld-linux.so.2+0xa7f3] # # An error report file with more information is saved as hs_err_pid2633.log # # If you would like to submit a bug report, please visit: # http://java.sun.com/webapps/bugreport/crash.jsp # ./run.sh: line 3: 2633 Aborted /usr/local/java/bin/java -Djava.library.path=/usr/local/java/jre/lib/ -Djsmsengine.debug=true -classpath jsmsengine.jar:smsgateway.jar:classes12.jar:RXTXcomm.jar:. com.api.sms.SMSServer What is the jvm depedency for the latest library? Can I use 1.4.2_09 b05? Thanks in advance. Arian --------------------------------- Yahoo! Mail Use Photomail to share photos without annoying attachments. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060320/83d58dd7/attachment-0040.html From f.frumento at ngi.it Tue Mar 21 00:21:47 2006 From: f.frumento at ngi.it (Fabio Frumento) Date: Tue, 21 Mar 2006 08:21:47 +0100 Subject: [Rxtx] Javadoc on the go Message-ID: <441FA98B.9050701@ngi.it> Hi Trent, sorry for the big delay but my job is running wild, i was out for some time but now i'm back and ready to continue the javadoc for Rxtx. Did you used the last javadoc patch i sent you ? let me know if i have to send it to you again or not. regards Fabio From lyon at docjava.com Tue Mar 21 00:51:18 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Tue, 21 Mar 2006 02:51:18 -0500 Subject: [Rxtx] lock files Message-ID: Hi All, You know, if the use of lock files were under Java control (rather than a build-time decision), it might enable a more unified binary distro. It might also facilitate quick prototyping of non-lock file approaches to resolving serial port contention issues (i.e., mac-like approaches vs. linux approaches, etc.). I realize that this is a radical overhaul of the lock file policy issue. Also, it may harm performance. On the other hand, our benchmarks on JNI overhead for modern processors indicate performance impact should be minimal. Perhaps it is more of an issue with the toybox systems. Suppose there were a class with a reasonable default...someone might write: SerialPortLockPolicy.setPolicy(SerialPortLockPolicy.UNIX_LOCK_FILE); SerialPortLockPolicy.setPolicy(SerialPortLockPolicy.NO_LOCK_CHECKING); SerialPortLockPolicy.setPolicy(SerialPortLockPolicy.MAC_STYLE); Thus, we could have a run-time reconfiguration of the serial port lock policy. A special NO_LOCK version of the binary would no longer be required. Any thoughts on this? Thanks! - Doug From joachim at buechse.de Tue Mar 21 03:09:09 2006 From: joachim at buechse.de (Joachim Buechse) Date: Tue, 21 Mar 2006 11:09:09 +0100 Subject: [Rxtx] lock files In-Reply-To: References: Message-ID: <8E12916A-1B9A-4FF2-B684-E2D1C794221B@buechse.de> This is pretty much what I thought about when I suggested, that the default behaviour could be overwritten with a property. I am very much in favor of this approach. In particular this allows much easier debugging for PC based java developers. I think big parts of the Java (and maybe some parts of the C code) could use a bit of a structural workover (unit tests, javadoc, synchronization, etc). Maybe there should be a CVS branch for this experimental version. I'd be happy to contribute a first workover for some of the Java code. Designing for testability and implementing a good bunch of unit tests has been a strategy that worked quite well in the Java projects I lead. And it ultimately allows more liberal change permission. Regards, Joachim On 21.03.2006, at 08:51, Dr. Douglas Lyon wrote: > Hi All, > You know, if the use of lock files were > under Java control (rather than a build-time decision), > it might enable a more unified binary distro. It might also > facilitate quick prototyping of non-lock file approaches > to resolving serial port contention issues (i.e., mac-like > approaches vs. linux approaches, etc.). > > I realize that this is a radical overhaul of the lock file policy > issue. Also, it may harm performance. On the other hand, > our benchmarks on JNI overhead for modern processors indicate > performance impact should be minimal. Perhaps it is more of > an issue with the toybox systems. > > Suppose there were a class with a reasonable default...someone > might write: > SerialPortLockPolicy.setPolicy(SerialPortLockPolicy.UNIX_LOCK_FILE); > SerialPortLockPolicy.setPolicy(SerialPortLockPolicy.NO_LOCK_CHECKING); > SerialPortLockPolicy.setPolicy(SerialPortLockPolicy.MAC_STYLE); > > Thus, we could have a run-time reconfiguration of the serial port lock > policy. A special NO_LOCK version of the binary would no longer > be required. > > Any thoughts on this? > > Thanks! > - Doug > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From joachim at buechse.de Tue Mar 21 06:23:08 2006 From: joachim at buechse.de (Joachim Buechse) Date: Tue, 21 Mar 2006 14:23:08 +0100 Subject: [Rxtx] PATCH: use of ioctl(fd, TIOCEXCL) instead of lockfiles Message-ID: <923AE774-EEA2-4911-92D8-32BB27802C8B@buechse.de> Here is the patch for the ioctl(fd, TIOCEXCL). I have verified this only for OSX 10.4.5, hence it is only defined for APPLE. However, it should work at least for Solaris as well. If a process has requested TIOEXCL further open calls by other user processes will fail. The patch also disables uucp style locking for APPLE. Obviously this is discussable. I think it is the way to go, as it eliminates creating the lock directory which doesnt exist on the standard installation and it eliminates messing with the system group definitions (adding users to group uucp). Regarding the possibility of root processes opening a device which is locked - I consider this a feature not a potential problem. It is highly unlikely, that somebody is crazy enough to run a JavaVM as root (unless he has no other means of getting a restricted IP port opened, ie doesnt understand ipfw). Anyway, even if the process runs as root, it fails when calling ioctl(fd, TIOCEXCL). It could however still open the port to listen for RING events. I.e. a fax server which needs to see incoming calls but otherwise doesnt want to block the port. So the only case where the proposed mechanism fails is, if an incorrectly implemented process running as root conflicts with a user process. I think this can be accepted. Regards, Joachim PS: If this patch is generally accepted, the installer and Mac doku should obviously be changed as well. Index: SerialImp.c =================================================================== RCS file: /usr/local/cvsroot/rxtx-devel/src/SerialImp.c,v retrieving revision 1.46.2.187 diff -u -r1.46.2.187 SerialImp.c --- SerialImp.c 29 Jan 2006 22:19:04 -0000 1.46.2.187 +++ SerialImp.c 21 Mar 2006 12:59:16 -0000 @@ -656,6 +656,25 @@ fd=OPEN (filename, O_RDWR | O_NOCTTY | O_NONBLOCK ); } while (fd < 0 && errno==EINTR); +#ifdef OPEN_EXCL + // Note that open() follows POSIX semantics: multiple open() calls to + // the same file will succeed unless the TIOCEXCL ioctl is issued. + // This will prevent additional opens except by root-owned processes. + // See tty(4) ("man 4 tty") and ioctl(2) ("man 2 ioctl") for details. + + if (fd >= 0 && (ioctl(fd, TIOCEXCL) == -1)) + { + sprintf( message, "open: exclusive access denied for % s\n", + filename ); + report( message ); + report_error( message ); + + close(fd); + goto fail; + } +#endif /* OPEN_EXCL */ + + if( configure_port( fd ) ) goto fail; (*env)->ReleaseStringUTFChars( env, jstr, filename ); sprintf( message, "open: fd returned is %i\n", fd ); Index: SerialImp.h =================================================================== RCS file: /usr/local/cvsroot/rxtx-devel/src/SerialImp.h,v retrieving revision 1.11.2.49 diff -u -r1.11.2.49 SerialImp.h --- SerialImp.h 5 Jul 2005 17:47:21 -0000 1.11.2.49 +++ SerialImp.h 21 Mar 2006 12:59:17 -0000 @@ -135,7 +135,8 @@ /*# define LOCKDIR "/var/spool/uucp"*/ # define LOCKDIR "/var/lock" # define LOCKFILEPREFIX "LK." -# define UUCP +/*# define UUCP*/ +# define OPEN_EXCL #endif /* __APPLE__ */ #if defined(__NetBSD__) # define DEVICEDIR "/dev/" From tjarvi at qbang.org Tue Mar 21 10:26:08 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 21 Mar 2006 10:26:08 -0700 (MST) Subject: [Rxtx] Javadoc on the go In-Reply-To: <441FA98B.9050701@ngi.it> References: <441FA98B.9050701@ngi.it> Message-ID: On Tue, 21 Mar 2006, Fabio Frumento wrote: > Hi Trent, > > sorry for the big delay but my job is running wild, i was out for some > time but now i'm back and ready to continue the javadoc for Rxtx. > > Did you used the last javadoc patch i sent you ? let me know if i have to > send it to you again or not. > > regards > > Fabio Hi Fabio The patch is in the rxtx mail-list archives. It will be going in soon. I did not see a time critical portion. I'll probably be going through the list since the last batch of patches this weekend and putting them into CVS. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Tue Mar 21 10:57:18 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 21 Mar 2006 10:57:18 -0700 (MST) Subject: [Rxtx] jvm issue In-Reply-To: <20060321065524.94779.qmail@web50701.mail.yahoo.com> References: <20060321065524.94779.qmail@web50701.mail.yahoo.com> Message-ID: On Mon, 20 Mar 2006, Lambok Sianturi wrote: > Hi All, > This is my first time to join RxTx mailing list. I thank you all for allowing others to sign in in requests help. > I use the latest RxTx lib in Fedora 3 with java version 1.4.2_09 b05. And I got this error: > > # > # An unexpected error has been detected by HotSpot Virtual Machine: > # > # SIGSEGV (0xb) at pc=0x00bf27f3, pid=2633, tid=3086112448 > # > # Java VM: Java HotSpot(TM) Client VM (1.4.2_09-b05 mixed mode) > # Problematic frame: > # C [ld-linux.so.2+0xa7f3] A native library loading error? What happens if you recompile rxtx on your system and install that? This sounds like an ABI problem? rxtx 2.1-7 was compiled with a gcc 2.96 toolchain as I recall. The hope is newer system will be backwards compatible. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Tue Mar 21 11:05:29 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 21 Mar 2006 11:05:29 -0700 (MST) Subject: [Rxtx] PATCH: use of ioctl(fd, TIOCEXCL) instead of lockfiles In-Reply-To: <923AE774-EEA2-4911-92D8-32BB27802C8B@buechse.de> References: <923AE774-EEA2-4911-92D8-32BB27802C8B@buechse.de> Message-ID: On Tue, 21 Mar 2006, Joachim Buechse wrote: > Here is the patch for the ioctl(fd, TIOCEXCL). I have verified this only > for OSX 10.4.5, hence it is only defined for APPLE. However, it should > work at least for Solaris as well. > > If a process has requested TIOEXCL further open calls by other user > processes will fail. > > The patch also disables uucp style locking for APPLE. Obviously this is > discussable. I think it is the way to go, as it eliminates creating the > lock directory which doesnt exist on the standard installation and it > eliminates messing with the system group definitions (adding users to > group uucp). > > Regarding the possibility of root processes opening a device which is > locked - I consider this a feature not a potential problem. It is highly > unlikely, that somebody is crazy enough to run a JavaVM as root (unless > he has no other means of getting a restricted IP port opened, ie doesnt > understand ipfw). Anyway, even if the process runs as root, it fails when > calling ioctl(fd, TIOCEXCL). It could however still open the port to > listen for RING events. I.e. a fax server which needs to see incoming > calls but otherwise doesnt want to block the port. So the only case where > the proposed mechanism fails is, if an incorrectly implemented process > running as root conflicts with a user process. I think this can be > accepted. > > Regards, > Joachim > > PS: If this patch is generally accepted, the installer and Mac doku > should obviously be changed as well. > > > Index: SerialImp.c > =================================================================== > RCS file: /usr/local/cvsroot/rxtx-devel/src/SerialImp.c,v > retrieving revision 1.46.2.187 > diff -u -r1.46.2.187 SerialImp.c > --- SerialImp.c 29 Jan 2006 22:19:04 -0000 1.46.2.187 > +++ SerialImp.c 21 Mar 2006 12:59:16 -0000 > @@ -656,6 +656,25 @@ > fd=OPEN (filename, O_RDWR | O_NOCTTY | O_NONBLOCK ); > } while (fd < 0 && errno==EINTR); > > +#ifdef OPEN_EXCL > + // Note that open() follows POSIX semantics: multiple open() > calls to > + // the same file will succeed unless the TIOCEXCL ioctl is > issued. > + // This will prevent additional opens except by root-owned > processes. > + // See tty(4) ("man 4 tty") and ioctl(2) ("man 2 ioctl") for > details. > + > + if (fd >= 0 && (ioctl(fd, TIOCEXCL) == -1)) > + { > + sprintf( message, "open: exclusive access denied for % > s\n", > + filename ); > + report( message ); > + report_error( message ); > + > + close(fd); > + goto fail; > + } > +#endif /* OPEN_EXCL */ > + > + > if( configure_port( fd ) ) goto fail; > (*env)->ReleaseStringUTFChars( env, jstr, filename ); > sprintf( message, "open: fd returned is %i\n", fd ); > Index: SerialImp.h > =================================================================== > RCS file: /usr/local/cvsroot/rxtx-devel/src/SerialImp.h,v > retrieving revision 1.11.2.49 > diff -u -r1.11.2.49 SerialImp.h > --- SerialImp.h 5 Jul 2005 17:47:21 -0000 1.11.2.49 > +++ SerialImp.h 21 Mar 2006 12:59:17 -0000 > @@ -135,7 +135,8 @@ > /*# define LOCKDIR "/var/spool/uucp"*/ > # define LOCKDIR "/var/lock" > # define LOCKFILEPREFIX "LK." > -# define UUCP > +/*# define UUCP*/ > +# define OPEN_EXCL > #endif /* __APPLE__ */ > #if defined(__NetBSD__) > # define DEVICEDIR "/dev/" > This looks like a good start. What do you think Dmitry? Perhaps all systems with TIOCEXCL defined should use that though. Even if they use lockfiles. It wont hurt anything. That would catch people hacking their own serial apps without checking lockfiles. Its a good idea to avoid C++ style comments in the C portions. Some older systems don't deal with them well. If it's just for Mac OS X, it isn't a big deal. I think it was the Irix compiler that was problematic? -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Tue Mar 21 11:22:05 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 21 Mar 2006 11:22:05 -0700 (MST) Subject: [Rxtx] lock files In-Reply-To: <8E12916A-1B9A-4FF2-B684-E2D1C794221B@buechse.de> References: <8E12916A-1B9A-4FF2-B684-E2D1C794221B@buechse.de> Message-ID: We can try it. Maybe the JNI is much improved. The nice thing about linking into liblock is distros then worry about lockfiles on their systems. This way, we have to deal with any changes that may show up. On Tue, 21 Mar 2006, Joachim Buechse wrote: > This is pretty much what I thought about when I suggested, that the > default behaviour could be overwritten with a property. I am very much in > favor of this approach. In particular this allows much easier debugging > for PC based java developers. > > I think big parts of the Java (and maybe some parts of the C code) could > use a bit of a structural workover (unit tests, javadoc, synchronization, > etc). Maybe there should be a CVS branch for this experimental version. > I'd be happy to contribute a first workover for some of the Java code. > Designing for testability and implementing a good bunch of unit tests has > been a strategy that worked quite well in the Java projects I lead. And > it ultimately allows more liberal change permission. > > Regards, > Joachim > > > On 21.03.2006, at 08:51, Dr. Douglas Lyon wrote: > >> Hi All, >> You know, if the use of lock files were >> under Java control (rather than a build-time decision), >> it might enable a more unified binary distro. It might also >> facilitate quick prototyping of non-lock file approaches >> to resolving serial port contention issues (i.e., mac-like >> approaches vs. linux approaches, etc.). >> >> I realize that this is a radical overhaul of the lock file policy >> issue. Also, it may harm performance. On the other hand, >> our benchmarks on JNI overhead for modern processors indicate >> performance impact should be minimal. Perhaps it is more of >> an issue with the toybox systems. >> >> Suppose there were a class with a reasonable default...someone >> might write: >> SerialPortLockPolicy.setPolicy(SerialPortLockPolicy.UNIX_LOCK_FILE); >> SerialPortLockPolicy.setPolicy(SerialPortLockPolicy.NO_LOCK_CHECKING); >> SerialPortLockPolicy.setPolicy(SerialPortLockPolicy.MAC_STYLE); >> >> Thus, we could have a run-time reconfiguration of the serial port lock >> policy. A special NO_LOCK version of the binary would no longer >> be required. >> >> Any thoughts on this? >> >> Thanks! >> - Doug >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From dmarkman at mac.com Tue Mar 21 16:05:17 2006 From: dmarkman at mac.com (Dmitry Markman) Date: Tue, 21 Mar 2006 18:05:17 -0500 Subject: [Rxtx] PATCH: use of ioctl(fd, TIOCEXCL) instead of lockfiles In-Reply-To: References: <923AE774-EEA2-4911-92D8-32BB27802C8B@buechse.de> Message-ID: <512AC70C-BB86-48F2-A83C-023F35C23BAB@mac.com> I think it's cool, but I'd like to have that property implementation when user can choose between locking mechanism about comments: it's easy to change comments to the C style or we can use extensions of the file to cpp so c++ compiler will be used On Mar 21, 2006, at 1:05 PM, Trent Jarvi wrote: > This looks like a good start. What do you think Dmitry? Perhaps > all systems with TIOCEXCL defined should use that though. Even if > they use lockfiles. It wont hurt anything. That would catch > people hacking their own serial apps without checking lockfiles. > > Its a good idea to avoid C++ style comments in the C portions. > Some older systems don't deal with them well. If it's just for Mac > OS X, it isn't a big deal. I think it was the Irix compiler that > was problematic? Dmitry Markman From dmarkman at mac.com Tue Mar 21 16:13:00 2006 From: dmarkman at mac.com (Dmitry Markman) Date: Tue, 21 Mar 2006 18:13:00 -0500 Subject: [Rxtx] PATCH: use of ioctl(fd, TIOCEXCL) instead of lockfiles In-Reply-To: References: <923AE774-EEA2-4911-92D8-32BB27802C8B@buechse.de> Message-ID: I'd like to add that creating locking folder isn't a big deal we never had a problem related to the lock folders, because we always used installer on mac os x from other hand I'm not very much familiar with iotcl locking approach and I'm not sure it's more efficient Joachim wrote "I think it is the way to go, as it eliminates creating the lock directory which doesnt exist on the standard installation and it eliminates messing with the system group definitions (adding users to group uucp)." but I really didn't have any problem with that 1. doesn't exist on the standard installation there are many-many things that don't exist in the standard installation so I don't think that argument is strong enough 2. messing with the system group definitions I don't think we're messing with the group definition mac os x provides very clear way to set up group's members and together with Greg Guerin AuthKit there is no problem to set those definitions so I don't think that argument is strong either but from other hand using iotcl is more promising and is more elegant On Mar 21, 2006, at 1:05 PM, Trent Jarvi wrote: > > This looks like a good start. What do you think Dmitry? Perhaps > all systems with TIOCEXCL defined should use that though. Even if > they use lockfiles. It wont hurt anything. That would catch > people hacking their own serial apps without checking lockfiles. Dmitry Markman From joachim at buechse.de Wed Mar 22 04:46:45 2006 From: joachim at buechse.de (Joachim Buechse) Date: Wed, 22 Mar 2006 12:46:45 +0100 Subject: [Rxtx] PATCH: use of ioctl(fd, TIOCEXCL) instead of lockfiles In-Reply-To: References: <923AE774-EEA2-4911-92D8-32BB27802C8B@buechse.de> Message-ID: Sorry, I was not very clear with my arguments, so I will try again;-) Please, don't take this as an attack against work that has been done. I think the contributions that have been made in the past were made in a good spirit. But I really believe, that the current solution for OSX has many shortcomings and should be changed as soon as possible. lock files --- The /var/lock folder does not exist on the standard OSX installation, however the standard installation includes several applications that use serial ports (i.e. the FAX capability). This indicates, that the lock folder approach will not work well with system components. Applications for OSX will generally try to live in harmony with system components (except for HP print drivers of course). I think RXTX should follow this approach as well. uucp group --- Accessing serial ports is not an admin privileged operation on OSX. Any user (world) has read/write privileges on /dev/tty*. So the system default is to not enforce any group membership to access these ports. The group uucp however is a system group on all unix systems I know. It exists for certain system processes. A non admin user should in general not be a member of this group. Quite arguably no user should ever be a member of this group. Installer --- My general opinion is, that - no Installer should touch user or group data without warning - no Application Installer should touch groups which are not specific to the very application installed - no Installer should ever add regular users to a system group The current installer injects the installing user in the group uucp without warning about this change and without giving the option to "opt out" of this change. This is a potential security risk (but not currently a real one, as OSX contains no folders belonging to group uucp). The current installer does not work for multi user systems. It puts the installing user in the uucp group. However the installing user is not necessarily the user that will use the application. Putting all users that may use a serial port application in the system group uucp seems like a very invasive approach to me. Besides that, newly created users will not automatically be in the group and hence, serial applications will "break" for new users without obvious reasons. Avoiding the lock files will allow self contained applications (i.e. drag&drop installation). In my eyes this is largely preferable over an installer that requests admin privileges. Adding up all these points indicates very strongly, that the lock-file implementation is not the way to go on OSX. Regards, Joachim On 22.03.2006, at 00:13, Dmitry Markman wrote: > I'd like to add that > > creating locking folder isn't a big deal > we never had a problem related to the lock folders, because we > always used installer on mac os x > from other hand I'm not very much familiar with iotcl locking > approach and I'm not sure it's more efficient > > Joachim wrote "I think it is the way to go, as it eliminates > creating the lock directory which doesnt exist on the standard > installation and it eliminates messing with the system group > definitions (adding users to group uucp)." but I really didn't have > any problem with that > > 1. doesn't exist on the standard installation > there are many-many things that don't exist in the standard > installation so I don't think that argument is strong enough > 2. messing with the system group definitions > I don't think we're messing with the group definition > mac os x provides very clear way to set up group's members and > together with Greg Guerin AuthKit there is no problem to set those > definitions > so I don't think that argument is strong either > but from other hand using iotcl is more promising and is more elegant > > > > On Mar 21, 2006, at 1:05 PM, Trent Jarvi wrote: > >> >> This looks like a good start. What do you think Dmitry? Perhaps >> all systems with TIOCEXCL defined should use that though. Even if >> they use lockfiles. It wont hurt anything. That would catch >> people hacking their own serial apps without checking lockfiles. > > Dmitry Markman > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From dmarkman at mac.com Wed Mar 22 05:27:13 2006 From: dmarkman at mac.com (Dmitry Markman) Date: Wed, 22 Mar 2006 07:27:13 -0500 Subject: [Rxtx] PATCH: use of ioctl(fd, TIOCEXCL) instead of lockfiles In-Reply-To: References: <923AE774-EEA2-4911-92D8-32BB27802C8B@buechse.de> Message-ID: <83440CF3-DCD8-41C1-B941-F227232C27E3@mac.com> thanks for the very good explanation I didn't think that you were attacking any thing, so don't worry I just had feeling, that there were more aesthetic reasons for going to ioctl then real necessity now you explained everything quite well (BTW, asfar as I remember installer asks admin password so it wasn't quiet, but it really doesn't matter now) thanks On Mar 22, 2006, at 6:46 AM, Joachim Buechse wrote: > Sorry, I was not very clear with my arguments, so I will try again;-) > > Please, don't take this as an attack against work that has been > done. I think the contributions that have been made in the past > were made in a good spirit. But I really believe, that the current > solution for OSX has many shortcomings and should be changed as > soon as possible. > > lock files > --- > The /var/lock folder does not exist on the standard OSX > installation, however the standard installation includes several > applications that use serial ports (i.e. the FAX capability). This > indicates, that the lock folder approach will not work well with > system components. Applications for OSX will generally try to live > in harmony with system components (except for HP print drivers of > course). I think RXTX should follow this approach as well. > > uucp group > --- > Accessing serial ports is not an admin privileged operation on OSX. > Any user (world) has read/write privileges on /dev/tty*. So the > system default is to not enforce any group membership to access > these ports. The group uucp however is a system group on all unix > systems I know. It exists for certain system processes. A non admin > user should in general not be a member of this group. Quite > arguably no user should ever be a member of this group. > > Installer > --- > My general opinion is, that > - no Installer should touch user or group data without warning > - no Application Installer should touch groups which are not > specific to the very application installed > - no Installer should ever add regular users to a system group > > The current installer injects the installing user in the group uucp > without warning about this change and without giving the option to > "opt out" of this change. This is a potential security risk (but > not currently a real one, as OSX contains no folders belonging to > group uucp). > > The current installer does not work for multi user systems. It puts > the installing user in the uucp group. However the installing user > is not necessarily the user that will use the application. Putting > all users that may use a serial port application in the system > group uucp seems like a very invasive approach to me. Besides that, > newly created users will not automatically be in the group and > hence, serial applications will "break" for new users without > obvious reasons. > > > Avoiding the lock files will allow self contained applications > (i.e. drag&drop installation). In my eyes this is largely > preferable over an installer that requests admin privileges. Adding > up all these points indicates very strongly, that the lock-file > implementation is not the way to go on OSX. > > Regards, > Joachim > > > On 22.03.2006, at 00:13, Dmitry Markman wrote: > >> I'd like to add that >> >> creating locking folder isn't a big deal >> we never had a problem related to the lock folders, because we >> always used installer on mac os x >> from other hand I'm not very much familiar with iotcl locking >> approach and I'm not sure it's more efficient >> >> Joachim wrote "I think it is the way to go, as it eliminates >> creating the lock directory which doesnt exist on the standard >> installation and it eliminates messing with the system group >> definitions (adding users to group uucp)." but I really didn't >> have any problem with that >> >> 1. doesn't exist on the standard installation >> there are many-many things that don't exist in the standard >> installation so I don't think that argument is strong enough >> 2. messing with the system group definitions >> I don't think we're messing with the group definition >> mac os x provides very clear way to set up group's members and >> together with Greg Guerin AuthKit there is no problem to set those >> definitions >> so I don't think that argument is strong either >> but from other hand using iotcl is more promising and is more elegant >> >> >> >> On Mar 21, 2006, at 1:05 PM, Trent Jarvi wrote: >> >>> >>> This looks like a good start. What do you think Dmitry? Perhaps >>> all systems with TIOCEXCL defined should use that though. Even >>> if they use lockfiles. It wont hurt anything. That would catch >>> people hacking their own serial apps without checking lockfiles. >> >> Dmitry Markman >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx Dmitry Markman From lyon at docjava.com Wed Mar 22 06:12:18 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Wed, 22 Mar 2006 08:12:18 -0500 Subject: [Rxtx] sole of a new design pattern Message-ID: Hi All, I have been thinking about how we design the serial port software. I think we need a new design pattern. For lack of a better term, I shall call it: The Parametric Singleton Design Pattern By Douglas A. Lyon ABSTRACT The goal of the singleton design pattern is to make sure that there is one, and only one, instance of a given class. The goal of the parametric singleton design pattern is to make sure that there is one, and only one, instance of a given class with the given parametric values. We parametric singleton design pattern combines the singleton design pattern with a parameter that enables unique creation of instances of a class. These instances are cached. When a user asks for an instance with these parameters, the cache is checked. If the instance is in the cache, the instance is returned, otherwise it is created, added to the cache and then returned. We apply our parametric singleton design pattern to the retrieval of RMI registries bound to a given port. The goal of our system is to make sure that no two RMI registries are listening to the same socket and to make use of the RMI registries after they have been created. RMI registries are used in distributed computation. Introduction The singleton design pattern is meant to ensure that on a single instance of a class exists. It is also meant to provide a global point of access to it. The intent of the parametric singleton design pattern is to ensure that a class has only one instance for a given set of parameter values. It also provides a global point of access to it. Motivation A system cannot tolerate multiple instances of some classes with identical parameters. For example, you cannot have two instances making use of the same serial port, at the same time. You cannot have two instances that are trying to listen to the same socket connection. You cannot have two instances writing to the same file structure at the same time. As the operating system is often thought of as the arbiter of consumed resources (i.e., tape drives, serial ports, etc.) we frequently leave it to an operating system implementation to resolve these contention issues. Even for similar resources (like serial ports) there are few standards for handling contention. For example, serial ports on Linux are locked using a "/var/lock" file. POSIX, on the other hand, uses ioctl mechanisms to prevent contention. A better solution is to make a class that is responsible for keeping track of the instances created from the class. The class is declared final, so that it cannot be subclassed. The class also has a private constructor, so that other classes cannot instance it. The new design pattern is called the parametric singleton design pattern and it provides a way to access and create instances with given parameters. Applicability Use the Parametric Singleton Design Pattern when: 1. There must be exactly one instance of a class with the given parameters. 2. The instances must be accessible to clients from a well-known access point. Structure Insert UML diagram here. Participants The Parametric Singleton Clients that need instances 1. The Parametric Singleton defines an instance upon request from a client, if, and only if, the instance does not already exist. 2. The Parametric Singleton returns the instance to the client. 3. The Parametric Singleton is responsible for creating unique instances from given parameters. Collaborations Clients obtain a reference to a Parametric Singleton instance only through the parametric singleton design pattern. If the instance is left in an improper state (e.g., the serial port was left open) it is NOT the role of the Parametric Singleton Design Pattern to close the IO port. Nor is it the role of the Parametric Singleton Design Pattern to open the port. That role is delegate to some other part of the system. Further, it is not the role of the Parametric Singleton Design Pattern to check out resources. That is, multiple threads can have multiple references to the same resource at the same time. MUTEX locking is delegated to some other part of the system. Consequences The Parametric Singleton Design Pattern has several benefits: 1. Controlled access to parametrically defined instances. Since the Parametric Singleton class encapsulates its instances, there is control over how and when clients access it. 2. Reduced name space. The Parametric Singleton pattern avoids global variables that store instances created from the same parameter. Implementation Here are implementation issues to consider when using the Parametric Singleton pattern: 1. Unique mapping of parameters. The Parametric Singleton pattern requires that there be a mean to isomorphically map the parameter space into the instance space and back again. 2. Ensure unique instances. The Parametric Singleton pattern makes unique instances from parameters, and it does so only once. 3. Cache instances for fast retrieval. The Parametric Singleton pattern must be able to look up instances, given some set of parameters, and do so from some data structure. That is, there must be enough space to hold references to all the instances the program will need. Also, a mechanism is needed to look up and retrieve the instances quickly enough to satisfy the clients. Sample Code public final class ParametricSingletonRmiRegistry { private static Hashtable registry = new Hashtable(100); // use singleton pattern and??????????????????????????????????????????????? // prevent instantiation of RmiRegistryUtils.?????????????????????????????? private ParametricSingletonRmiRegistry() { } // the only instance of the Registry held by the RmiRegistryUtils?????????? public static void listNames(Integer port) { if (!isInCacheAndRunning(port)) return; Registry r = (Registry) registry.get(port); System.out.println("registry on port: " + port); System.out.println("registry: " + r); System.out.println("names: "); try { print(r.list()); } catch (RemoteException e) { In.message(e); } System.out.println("------------------------"); } /**???????????????????????????????????????????????????????????????????????? * Checks whether a Registry has been started on this host????????????????? * in the specified port.?????????????????????????????????????????????????? * If not, it tries to start one.?????????????????????????????????????????? * when it fails to start a Registry, it exits the program????????????????? * with exit code 1.??????????????????????????????????????????????????????? */ public static void restart(int port) { if (isInCacheAndRunning(port)) return; try { startRegistry(port); } catch (RemoteException e) { In.message(e); } } /**???????????????????????????????????????????????????????????????????????? * @param port????????????????????????????????????????????????????????????? * @return true if registry is in cache and running???????????????????????? */ private static boolean isInCacheAndRunning(Integer port) { if (!isRegistryRunning(port.intValue())) return false; if (!isRegistryInCache(port.intValue())) return false; return true; } /**???????????????????????????????????????????????????????????????????????? * @param port????????????????????????????????????????????????????????????? * @return true if we are able to locate a local registry on port.??????????????????????????????????????????????????????????????????????????? */ private static boolean isRegistryRunning(int port) { try { Registry r = LocateRegistry.getRegistry(port); if (r != null) return true; } catch (RemoteException e) { return false; } return false; } /**???????????????????????????????????????????????????????????????????????? * @param port????????????????????????????????????????????????????????????? * @return return true if registry is in cache????????????????????????????? */ private static boolean isRegistryInCache(int port) { if (registry.get(new Integer(port)) == null) return false; return true; } /**???????????????????????????????????????????????????????????????????????? * Restart the registry, if needed.???????????????????????????????????????? * Return the only instance of the registry for consistent global?????????? * using by making use of the Singleton Design Pattern????????????????????? *????????????????????????????????????????????????????????????????????????? * @return the internally held registry instance.?????????????????????????? */ public static Registry getRegistry(Integer port) { restart(port); return (Registry) registry.get(port); } private static void startRegistry(Integer port) throws RemoteException { Registry r; try { r = LocateRegistry.createRegistry(port.intValue()); registry.put(port, r); //r = new sun.rmi.registry.RegistryImpl???????????????????????????? /// (port.intValue());?????????????????????????????????????? // registry.put(port, r);?????????????????????????????????????????? } catch (Exception e) { //e.printStackTrace();????????????????????????????????????????????? r = LocateRegistry.getRegistry(port.intValue()); registry.put(port, r); } } public static void main(String args[]) throws RemoteException { //restart(port);??????????????????????????????????????????????????????? restart(5001); restart(5002); restart(5002); Registry r = LocateRegistry.getRegistry(5002); System.out.println("registry="+r); } } I would very much like to get your feedback on this new design pattern idea. Thank you for your time. Regards, - Doug From david.garnier at trusted-logic.com Wed Mar 22 07:36:10 2006 From: david.garnier at trusted-logic.com (David Garnier) Date: Wed, 22 Mar 2006 15:36:10 +0100 Subject: [Rxtx] sole of a new design pattern In-Reply-To: References: Message-ID: <442160DA.80107@trusted-logic.com> Hello, > The Parametric Singleton Design Pattern The Singleton is the most abused design pattern ever. Good use-cases for this pattern are extremely rare and mostly confined to problems related to hardware resources, like serial ports. > Applicability > > Use the Parametric Singleton Design Pattern when: > 1. There must be exactly one instance of a class with the given > parameters. OK. As I said above, this case this actually very unusual. The Singleton pattern is mostly used when : > 2. The instances must be accessible to clients from a well-known > access point. Using the singleton pattern in this case is just convenient for the programmer. Problems arises pretty quickly, especially if you attempt to unit-test your classes. 1) If your singleton is stateful, or hold on to stateful objects, it means that two different unit tests are not actually independent. Instead of starting with a brand new environment, the result of a test may be affected by the result of a previous test. This problem also arise when with your class relies on a database. In both cases, the solution is to reset your "unique" resource (Singleton or database) at the beginning of the test, which is a pain. Also, while most projects connect to a single database, projects that allow the use of Singletons usually contain several of thems, and new ones may cropped up unnoticed. You quickly end up with test cases that only pass in a certain order, which is a royal pain. 2) You cannot mockup a singleton. Once everyone calls the SomeSingleton class statically, you can't replace your class by SomeSingletonMockup. Furthermore, even for hardware services, the Singleton pattern does not really prevent concurrent accesses. If you start the same program in two different JVMs, unless they somehow shared the state of their "Singletons" (through lock files for example), the Singleton pattern will not prevent concurrent access. Our application uses RXTX, and we routinely encounter cases where another (native) application has already locked the port. Since we cannot modify the native application to recognize lock files, OS-level control is irreplaceable. > > Consequences > The Parametric Singleton Design Pattern has several benefits: > > 1. Controlled access to parametrically defined instances. Since > the Parametric Singleton class encapsulates its instances, there is > control over how and when clients access it. Not really. Once you've returned the instance to a client, you've lost control over it. The client can to whatever it wants with it. You cannot "recall" the instance or claim it back. > 2. Reduced name space. The Parametric Singleton pattern avoids > global variables that store instances created from the same parameter. Sure, but you don't have to rely on a Singleton for that. Just create a single Factory. > I would very much like to get your feedback on this new design > pattern idea. Well, it's nothing new. Some may say that it is the point of design patterns: formalizes the designs that occur again and again. However, this design is simply a combination of the Singleton and Factory patterns. I did use it in the past, but now I've been exposed to the shortcomings of the Singleton pattern, so I limit myself to Factories. Regards, David From sean_montgomery at baseview.com Wed Mar 22 08:35:28 2006 From: sean_montgomery at baseview.com (Sean Montgomery) Date: Wed, 22 Mar 2006 10:35:28 -0500 Subject: [Rxtx] sole of a new design pattern In-Reply-To: <442160DA.80107@trusted-logic.com> References: <442160DA.80107@trusted-logic.com> Message-ID: <05769CA7-A51B-4CF0-BAA0-E02DD905F5A4@baseview.com> On Mar 22, 2006, at 9:36 AM, David Garnier wrote: > Furthermore, even for hardware services, the Singleton pattern does > not really prevent concurrent > accesses. If you start the same program in two different JVMs, > unless they somehow shared the state > of their "Singletons" (through lock files for example), the > Singleton pattern will not prevent > concurrent access. > Multiple class loaders in a single JVM can be tricky, too. Then there's synchronization, lazy initialization and serialization of singletons to contend with. Bloch's Effective Java covers these, and here's a few articles: http://www.javaworld.com/javaworld/jw-04-2003/jw-0425-designpatterns- p3.html http://java.sun.com/developer/technicalArticles/Programming/singletons/ Just FYI :-) From lyon at docjava.com Wed Mar 22 08:50:48 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Wed, 22 Mar 2006 10:50:48 -0500 Subject: [Rxtx] sole of a new design pattern In-Reply-To: <442160DA.80107@trusted-logic.com> References: <442160DA.80107@trusted-logic.com> Message-ID: Hi All, First, I would like to thank David for his prompt and thoughtful remarks. I had no idea people that feel strongly about a design patterns! Wow! Feedback (particularly critical feedback) is greatly appreciated. Starting at the end, first: >I did use it in >the past, but now I've been exposed to the shortcomings of the >Singleton pattern, so I limit myself to Factories. David, if I understood your comments correctly, you suggested that Factories can be used in leu of the Singleton Design Pattern, or even the Parametric Singleton Design Pattern. As I see in [Gof]: Factory Method: Intent "Define an interface for creating an object, but let subclasses decide which class to instantiate. Factory Method lets a class defer instantiation to subclasses." The Singleton Design Pattern is a concrete class, which is rather different, right? Also, subclasses are not permitted with Singleton, as they are final. Naturally, I could use an abstract factory as a parent for a singleton. I could even design a facade that could be implemented with the singleton....but that is not the intention of the design. Unless you want a mock-up, as discussed, below: More below: >Hello, > >> The Parametric Singleton Design Pattern > >The Singleton is the most abused design pattern ever. Good use-cases >for this pattern are extremely >rare and mostly confined to problems related to hardware resources, >like serial ports. > > >> Applicability >> >> Use the Parametric Singleton Design Pattern when: >> 1. There must be exactly one instance of a class with the given >> parameters. >OK. As I said above, this case this actually very unusual. The >Singleton pattern is mostly used when : >> 2. The instances must be accessible to clients from a well-known >> access point. > >Using the singleton pattern in this case is just convenient for the >programmer. Problems arises >pretty quickly, especially if you attempt to unit-test your classes. > >1) If your singleton is stateful, or hold on to stateful objects, it >means that two different unit >tests are not actually independent. Instead of starting with a brand >new environment, the result of >a test may be affected by the result of a previous test. This >problem also arise when with your >class relies on a database. In both cases, the solution is to reset >your "unique" resource >(Singleton or database) at the beginning of the test, which is a >pain. Also, while most projects >connect to a single database, projects that allow the use of >Singletons usually contain several of >thems, and new ones may cropped up unnoticed. You quickly end up >with test cases that only pass in a >certain order, which is a royal pain. There are basic problems with communicating finite state machines that include reachability and deadlock analysis. These are addressed with petri net analysis and are beyond the scope of the design pattern. As you quite rightly pointed out; the parametric singleton pattern (or the singleton pattern, for that matter) enable multiple threads to gain access to the same instance. The only way that I can see to block others from gaining access to the reference is the synchronize keyword. This is putting a spin-lock (or MUTEX) on the reference. The question of how to unit-test a design pattern like the parametric singleton remains open. Perhaps this is a deficiency. > >2) You cannot mockup a singleton. Once everyone calls the >SomeSingleton class statically, you can't >replace your class by SomeSingletonMockup. Acutally, I am not sure that this is true. If the Singleton implements a Facade interface, it should be possible to make the replacement. Right? > >Furthermore, even for hardware services, the Singleton pattern does >not really prevent concurrent >accesses. If you start the same program in two different JVMs, >unless they somehow shared the state >of their "Singletons" (through lock files for example), the >Singleton pattern will not prevent >concurrent access. Good Point!! You have sharp eyes! The singleton design pattern should/could take responsibility for this. In fact, you may notice that my code does have an implementation (LocateRegistry) that can work across JVM's. The LocateRegistry will even work across the Internet! LocateRegistry takes both a host name and a Port (lock files just don't do this). I did not think to implement this beyond the local machine, but, in its present form, it will work across different processes. > >Our application uses RXTX, and we routinely encounter cases where >another (native) application has >already locked the port. Since we cannot modify the native >application to recognize lock files, >OS-level control is irreplaceable. The singleton design pattern is not meant to replace OS-level control, but to centralize the Java programmers access to it. If lock files, for example, are used for serial ports, the Singleton Design Pattern should be able to work with them. > > >> >> Consequences >> The Parametric Singleton Design Pattern has several benefits: >> > > 1. Controlled access to parametrically defined instances. Since >> the Parametric Singleton class encapsulates its instances, there is >> control over how and when clients access it. > >Not really. Once you've returned the instance to a client, you've >lost control over it. The client >can to whatever it wants with it. You cannot "recall" the instance >or claim it back. Good point, this should read: > 1. Controll when parametrically defined instances are created. Since > > the Parametric Singleton class encapsulates its instances, there is > > control over how and when they are instanced. > >> 2. Reduced name space. The Parametric Singleton pattern avoids >> global variables that store instances created from the same parameter. > >Sure, but you don't have to rely on a Singleton for that. Just >create a single Factory. > > Thank you for your thoughtful and prompt response! Regards, - Doug From dmarkman at mac.com Wed Mar 22 21:21:55 2006 From: dmarkman at mac.com (Dmitry Markman) Date: Wed, 22 Mar 2006 23:21:55 -0500 Subject: [Rxtx] sole of a new design pattern In-Reply-To: <442160DA.80107@trusted-logic.com> References: <442160DA.80107@trusted-logic.com> Message-ID: I don't think I get it On Mar 22, 2006, at 9:36 AM, David Garnier wrote: > Using the singleton pattern in this case is just convenient for the > programmer. Problems arises > pretty quickly, especially if you attempt to unit-test your classes. so you're saying that something isn't so good because you can not test it in the convenient way? if that's true, I'm totally disagree change your test, debug whatever, but if software is efficient at runtime, works fine and only problem is some unit test (which is some kind of framework for testing) then dump that unit test , dump that unit framework and make something appropriate to the software you're testing so if Douglas want to use singletons, what's the problem? and what do you mean by abusing of singleton usage? of course singleton doesn't prevent concurrent access to the resource across the processes unless you're using some OS facility to prevent it, besides singleton as it was introduced is relevant only and only inside of the same process otherwise it's not singleton it's something else (let's say network singleton: so you have remote invocation facility and some factory method that return object created by that facility) I don't have any problem with using any kind of singletons. Parametric Singleton idea (if I understand it right) could be easily implemented in the following way: use a map populate map with instances of some class and key is your parameter (you can use lazy population too) if somebody ask the key check the value if it's null so resource is taken if somebody returns the resource put it back to the map public synchronized static Object getSomeResource(Object parameter); public synchronized static void returnResource(Object parameter); getSomeResource (inside of the same process) could return null in 2 cases 1. if somebody (from other thread for example) already took that resource 2. if OS API said that resource corresponded to that parameter (serial port with parameter = 1 (port #)) is locked and unavailable; I'm not sure that in case of serial ports we even need those Parametric Singletons (unless lock checking is a very expensive operation) just ask the OS about availability of that resource and if it's available give it away and then OS will lock it and therefore in next time somebody ask it just answer that resource is locked and return null for example system has 2 serial ports available so I ask getResource("tty"); or I ask getResource("Bluetooth-Modem"); and if OS is ok you can give tty or Bluetooth-Modem or both no need for any additional pattern I think back to the problem mac os x doesn't recognize locking via files, so it handles locking via some API an instance of the singleton in each process should recognize that resource is locked (by using that API) that's all we don't have to make things more complicate then they are just because there is some nice design pattern or nice unit test framework or whatever keep things simple, make them work fast, don't introduce middle layers unless you have really good reason to do so of course I could be entirely wrong, so sorry about that in advance thanks Dmitry Markman From tjarvi at qbang.org Wed Mar 22 22:31:41 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 22 Mar 2006 22:31:41 -0700 (MST) Subject: [Rxtx] sole of a new design pattern In-Reply-To: References: Message-ID: Hi Doug Interesting reading. So far I'm just reading and thinking. I have one question so far. " Clients obtain a reference to a Parametric Singleton instance only through the parametric singleton design pattern. If the instance is left in an improper state (e.g., the serial port was left open) it is NOT the role of the Parametric Singleton Design Pattern to close the IO port. Nor is it the role of the Parametric Singleton Design Pattern to open the port. That role is delegate to some other part of the system. " So when the clients obtain a reference to the singleton, can they assume the port is there? IE, would it be the singletons role to handle things like USB dongles being removed with event hints comming from the underlying OS. Hardware abstraction layer/HAL on Linux is an example of underlying OS events. I assume that role too is delegated to other parts of the system? -- Trent Jarvi tjarvi at qbang.org From lyon at docjava.com Thu Mar 23 08:10:33 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Thu, 23 Mar 2006 10:10:33 -0500 Subject: [Rxtx] Classes don't need goals, they need roles! In-Reply-To: References: Message-ID: Hi Trent, Yes, I think that the role of the Parametric Singleton Pattern is not to open or close serial ports, nor is it to perform error checking. On the other hand, if you were to combine the role of the Parametric Singleton Pattern with another role (like that of error checking) it might not be amiss. However, I generally caution programmers against adding multiple roles to classes, as this leads to monolithic designs. Thus a different class (NativeLibDetect) could have the role of determining if the native library can be loaded. Another class (SerialPortBean) can have the role of serializing the default state of the serial port, so that it can be recovered, from user preferences, at a later time. The SerialPortDetect could have the role of determining if the serial port is removed (i.e., a USB port was unplugged). My guess is that each class should have a different role in the system, in order to ease maintenance and testing...but I could be wrong about that. Thanks! - Doug >Hi Doug > >Interesting reading. So far I'm just reading and thinking. I have >one question so far. > >" > Clients obtain a reference to a Parametric Singleton instance only >through the parametric singleton design pattern. If the instance is >left in an improper state (e.g., the serial port was left open) it is >NOT the role of the Parametric Singleton Design Pattern to close the >IO port. Nor is it the role of the Parametric Singleton Design Pattern >to >open the port. That role is delegate to some other part of the system. >" > >So when the clients obtain a reference to the singleton, can they >assume the port is there? IE, would it be the singletons role to >handle things like USB dongles being removed with event hints >comming from the underlying OS. Hardware abstraction layer/HAL on >Linux is an example of underlying OS events. > >I assume that role too is delegated to other parts of the system? > >-- >Trent Jarvi >tjarvi at qbang.org >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From maximulo at yahoo.com Fri Mar 24 01:22:38 2006 From: maximulo at yahoo.com (Maximulo Majir) Date: Fri, 24 Mar 2006 00:22:38 -0800 (PST) Subject: [Rxtx] JavaPOS Message-ID: <20060324082238.66371.qmail@web38214.mail.mud.yahoo.com> Hi all! Hello Trent! From what i understand, RXTX or JavaComm APIs were not created solely for JavaPOS. In JavaPOS, we have the virtual method claim() which is separate from open(), but in our RXTX API, claiming is done every call to open(), we cant open the port if its claimed by another application. Would it be alright to suggest or ask to create a new method called claim(..)? Is there such thing as forceclaim() in RXTX? this could be the same as portownership transfer or its equivalent. ForceClaim is in JSR80. Do you have some samples using RXTX as the lower layer for the Device Service Objects in JavaPOS? I have tried it, i just want to compare. Thank you all! maxim __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060324/496adba2/attachment-0040.html From tjarvi at qbang.org Fri Mar 24 11:28:19 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 24 Mar 2006 11:28:19 -0700 (MST) Subject: [Rxtx] Re: RXTX 2.1 Solaris Problems In-Reply-To: <3691.1143210578@www045.gmx.net> References: <3691.1143210578@www045.gmx.net> Message-ID: On Fri, 24 Mar 2006, Andreas Guenther wrote: > Hi all, > > the solaris problem was not the lock file only. > > Ok, I had to create the directory /var/spool/locks myself. > /var/spool/uucp exists. > > But rxtx didn't find any port. > > I compiled the source with my own debug-informations > and I tried to isolate the problem. > > The problem is the testRead-call in SerialImp.c > > JNIEXPORT jboolean JNICALL RXTXCommDriver(testRead)( > > ... > if ( READ( fd, &c, 1 ) < 0 ) > { > if ( errno != EAGAIN ) { > report( "testRead() read failed\n" ); > ret = JNI_FALSE; > } > } > Thanks Andreas I'm packing up to move. I'll be more or less away for a couple weeks here. I'll be checking email but my workstation is going into a box soon. This isn't hard to fix as this port should be enumerated when EWOULDBLOCK is recieved. Thats error is OK for enumeration just as EAGAIN is. I've put the bug into bugzilla so we dont forget to get to it. http://bugzilla.qbang.org/show_bug.cgi?id=42 You can add yourself to the CC list if you wish to test fixes we provide or even put a patch into bugzilla yourself. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Fri Mar 24 11:51:52 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 24 Mar 2006 11:51:52 -0700 (MST) Subject: [Rxtx] JavaPOS In-Reply-To: <20060324082238.66371.qmail@web38214.mail.mud.yahoo.com> References: <20060324082238.66371.qmail@web38214.mail.mud.yahoo.com> Message-ID: On Fri, 24 Mar 2006, Maximulo Majir wrote: > Hi all! Hello Trent! > > > From what i understand, RXTX or JavaComm APIs were not > created solely for JavaPOS. In JavaPOS, we have the virtual method > claim() which is separate from open(), but in our RXTX API, claiming is > done every call to open(), we cant open the port if its claimed by > another application. Would it be alright to suggest or ask to create a > new method called claim(..)? Is there such thing as forceclaim() in > RXTX? this could be the same as portownership transfer or its > equivalent. ForceClaim is in JSR80. > Do you have some samples using RXTX as the lower layer for the Device > Service Objects in JavaPOS? I have tried it, i just want to compare. > maxim Hi Maxim JSR80 is the USB API IBM/Sun put together. The problem is they have a richer kernel/API underneath that can handle such things. With Serial Ports, there isnt anything there other than an ioctl that says don't let anyone touch this and lockfiles that are more of a 'lets be nice.' At times we may be using USB ports but it is through the termios layer with the limitations mentioned. The advantage is that not only USB will work with rxtx. Anything that has a termios layer should work (to the extent that termios layer is complete). I don't know how forceclaim() would help you. Lets say someone has a programmer working on /dev/ttyS0 and you take it. Now you both race each other to read data first. There isn't a mechanism I know of that will solve this problem in termios. The most obvious test being a native app and a Java app trying to take the port. There is the potential of requestion ownership from other Java Applications but the use for that is very rare. Did you have something more specific in mind that I'm missing? I'm not sure that claim() and forceclaim() would help you with rxtx other than maybe locking the port with claim() without opening it. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sat Mar 25 23:42:08 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 25 Mar 2006 23:42:08 -0700 (MST) Subject: [Rxtx] Serial snoop Message-ID: I was reading the Linux kernel mail-list tonight and ran past a thread that mentioned sersnoop. This looks like a handy tool for people dealing with new toys. "a simple command-line tool for linux that echoes bytes to and from any two serial ports, ptys, or network sockets, and prints all traffic to stdout, in hex and ascii." http://www.restivo.org/projects/sersnoop/ It works on Linux only at this time (debian package available). -- Trent Jarvi tjarvi at qbang.org From beat.arnet at gmail.com Sun Mar 26 07:32:35 2006 From: beat.arnet at gmail.com (Beat Arnet) Date: Sun, 26 Mar 2006 09:32:35 -0500 Subject: [Rxtx] Error 0x5 at /home/bob/foo/tar/rxtx-2.1-7/build/../src/termios.c(860): Access is, denied. Message-ID: <4426A603.80508@gmail.com> Dear all, When trying to open the serial port, I sometimes (not always) run into the following exception (when opening the serialPort): Error 0x5 at /home/bob/foo/tar/rxtx-2.1-7/build/../src/termios.c(860): Access is denied. java.lang.UnsatisfiedLinkError: native_psmisc_report_owner at gnu.io.CommPortIdentifier.native_psmisc_report_owner(Native Method) at gnu.io.CommPortIdentifier.open(CommPortIdentifier.java:354) at codeskin.tools.CLLoader.open(CLLoader.java:79) at codeskin.tools.C2000Programmer.run(C2000Programmer.java:220) at java.lang.Thread.run(Unknown Source) Is this the type of error where I should just try to open the port again, or can it be avoided? Regards, Beat From tjarvi at qbang.org Sun Mar 26 11:40:12 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 26 Mar 2006 11:40:12 -0700 (MST) Subject: [Rxtx] Error 0x5 at /home/bob/foo/tar/rxtx-2.1-7/build/../src/termios.c(860): Access is, denied. In-Reply-To: <4426A603.80508@gmail.com> References: <4426A603.80508@gmail.com> Message-ID: On Sun, 26 Mar 2006, Beat Arnet wrote: > Dear all, > > When trying to open the serial port, I sometimes (not always) run into > the following exception (when opening the serialPort): > > Error 0x5 at /home/bob/foo/tar/rxtx-2.1-7/build/../src/termios.c(860): > Access is > denied. > > java.lang.UnsatisfiedLinkError: native_psmisc_report_owner > at gnu.io.CommPortIdentifier.native_psmisc_report_owner(Native > Method) > at gnu.io.CommPortIdentifier.open(CommPortIdentifier.java:354) > at codeskin.tools.CLLoader.open(CLLoader.java:79) > at codeskin.tools.C2000Programmer.run(C2000Programmer.java:220) > at java.lang.Thread.run(Unknown Source) > > Is this the type of error where I should just try to open the port again, > or can it be avoided? > Hi Beat We did a second build of rxtx 2.1-7 to resolve that unsatisfied link error. It should work now. rxtx is trying to tell you it thinks someone else has the serial port open. You can try to open the port again but maybe you already have a copy of the program running when it happens? ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7r2.zip fixed build. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sun Mar 26 11:44:23 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 26 Mar 2006 11:44:23 -0700 (MST) Subject: [Rxtx] RXTX spec file (fwd) Message-ID: This is probably interesting for fedora/suse users. ---------- Forwarded message ---------- Date: Sun, 26 Mar 2006 16:25:45 +0200 To: taj at www.linux.org.uk Subject: RXTX spec file I send you this spec file which allows to create a RPM for Fedora 4, 5 (x86, x86_64) with Java Sun. -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: rxtx.spec Url: http://mailman.qbang.org/pipermail/rxtx/attachments/20060326/6c7b6af6/rxtx-0036.pl From tjarvi at qbang.org Sun Mar 26 23:42:59 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 26 Mar 2006 23:42:59 -0700 (MST) Subject: [Rxtx] Upcomming events. Message-ID: This Wednesday we will be announcing a new "Maintainer" for the rxtx project. The position is more like neutral leader. I wont be going away or doing less. This is just the right thing to do as it turns out the two people with CVS write access will be at the same company. We need a third and we need neutrality. The maintainer will have final say in any conflict and will try to be neutral. It will be open for discussion. Then we will do it :) I'll still do most of the footwork I do now. But. I'm falling behind. I should have gone through the mail-list and posted the next round of changes this weekend. I'm packing to move and its going so so - 13 years of toys collected. I suspect there will be a dead period on my part (a couple weeks) comming up. But if you get it on the mail-list, we will get it in if there are no objections. I may well not be reading the mail-list during this period as I look for a house and many other things. I hope everyone will help out. Thanks -- Trent Jarvi tjarvi at qbang.org From mahmoud_hadad at yahoo.com Sun Mar 26 07:31:19 2006 From: mahmoud_hadad at yahoo.com (ronan nick) Date: Sun, 26 Mar 2006 06:31:19 -0800 (PST) Subject: [Rxtx] a question about the COMM API Message-ID: <20060326143119.54919.qmail@web60014.mail.yahoo.com> hi, i was intrested in knowing how i can communicate with my internal modem using java? for example if i want to make a phone dialer application or a caller id application where should i be looking at? and as i understood the COMM API is for devices that is attached to the computer through serial ports. --------------------------------- New Yahoo! Messenger with Voice. Call regular phones from your PC and save big. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060326/ce8329f0/attachment-0038.html From dmarkman at mac.com Mon Mar 20 00:20:43 2006 From: dmarkman at mac.com (Dmitry Markman) Date: Mon, 20 Mar 2006 02:20:43 -0500 Subject: [Rxtx] Mac OS X RXTX java installer In-Reply-To: References: <07D0DE29-BA32-4CFE-B036-66BC6423D385@buechse.de> <441AE3E0.2030503@willicon.de> <12531986.1142622114996.JavaMail.dmarkman@mac.com> <441B2674.9010409@willicon.de> <13577405.1142634732776.JavaMail.dmarkman@mac.com> <441B4182.8010407@willicon.de> <92CD0D6C-5BE8-426E-A46D-99452059FF49@mac.com> <441BBB2D.8030305@willicon.de> <441C4088.5090905@willicon.de> Message-ID: <64BC1E23-FDDE-4CE6-8863-CFC881CBC224@mac.com> Hi all I put RXTX installer that will install everything (and will create / var/lock if necessary and add user to the uucp group) for mac os x from Java into the rxtx's CVS repository it could be easily modified to install files for any platform it uses Greg Guerin's AuthKit for authentication and authorization Greg released that kit under artistic license, so Trent, please take a look we, probably, can negotiate license with Greg if it's necessary Greg's AuthKit could be downloaded from http://www.amug.org/~glguerin/ sw/#authkit Michael Hall (mikehall at spacestar dot net) had a suggestion to make implementation of the jaas LoginModule based on Greg's AuthKit (his modification of the Greg's AuthKit could be found at http:// www.spacestar.net/users/mikehall/authkit.dmg) but Michael's AuthKitLoginModule does only half a job: it does authenticate but it can not run any external unix process in privileged mode (at least I wasn't able to do so) possible explanation could be found in conversation between Greg and Michael at Apple's java-dev list (look for archives) so I didn't use jaas API for rxtxinstaller I created folder MacOSX in the contrib folder comment 1. if you want to run that installer as standalone application all you need that RXTXInstaller.jar 2. if you want to use webstart you have to add Greg's libAuthKit.jnilib to the mac os x's resources in theory RXTXInstaller.jar doesn't need it, but there is a problem with loading libAuthKit.jnilib from webstart authkit uses loadLibrary method to load library and it failed (from webstart) for standalone application I extract libAuthKit.jnilib from the RXTXInstaller.jar and put it into the /Library/Java/Extensions or ~/Library/Java/Extensions folder that file will be deleted after installer quit unfortunately I didn't have time to put documentation there but it is mostly self-explanatory I took installer code from my gl4java installer that I did about 3 years ago (with small modifications) it would be very nice if Apple will release LoginModule that really will do the job (com.apple.security.auth.module package????? ) (UnixLoginModule is pretty useless) From lyon at docjava.com Mon Mar 20 06:34:39 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Mon, 20 Mar 2006 08:34:39 -0500 Subject: [Rxtx] Mac OS X RXTX java installer In-Reply-To: <64BC1E23-FDDE-4CE6-8863-CFC881CBC224@mac.com> References: <07D0DE29-BA32-4CFE-B036-66BC6423D385@buechse.de> <441AE3E0.2030503@willicon.de> <12531986.1142622114996.JavaMail.dmarkman@mac.com> <441B2674.9010409@willicon.de> <13577405.1142634732776.JavaMail.dmarkman@mac.com> <441B4182.8010407@willicon.de> <92CD0D6C-5BE8-426E-A46D-99452059FF49@mac.com> <441BBB2D.8030305@willicon.de> <441C4088.5090905@willicon.de> <64BC1E23-FDDE-4CE6-8863-CFC881CBC224@mac.com> Message-ID: Hi Dimitry, This sounds like great work. Just a couple of questions; After the check out of the CVS files, using: setenv CVSROOT :pserver:anonymous at cvs.milestonesolutions.com:/usr/local/cvsroot 53 8:28 setenv PASSWORD mousy 54 8:29 cvs login 55 8:29 cvs checkout rxtx-devel I cd'd over to: rxtx-devel/MACOSX_IDE And found: CVS/ CW/ ForPackageMaker/ PB/ Where is the installer? Thanks! - Doug From tjarvi at qbang.org Mon Mar 20 06:39:37 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 20 Mar 2006 06:39:37 -0700 (MST) Subject: [Rxtx] Mac OS X RXTX java installer In-Reply-To: References: <07D0DE29-BA32-4CFE-B036-66BC6423D385@buechse.de> <441AE3E0.2030503@willicon.de> <12531986.1142622114996.JavaMail.dmarkman@mac.com> <441B2674.9010409@willicon.de> <13577405.1142634732776.JavaMail.dmarkman@mac.com> <441B4182.8010407@willicon.de> <92CD0D6C-5BE8-426E-A46D-99452059FF49@mac.com> <441BBB2D.8030305@willicon.de> <441C4088.5090905@willicon.de> <64BC1E23-FDDE-4CE6-8863-CFC881CBC224@mac.com> Message-ID: On Mon, 20 Mar 2006, Dr. Douglas Lyon wrote: > Hi Dimitry, > This sounds like great work. Just a couple of questions; > After the check out of the CVS files, using: > setenv CVSROOT > :pserver:anonymous at cvs.milestonesolutions.com:/usr/local/cvsroot > 53 8:28 setenv PASSWORD mousy > 54 8:29 cvs login > 55 8:29 cvs checkout rxtx-devel Hi Doug You want "cvs checkout -r commapi-0-0-1 rxtx-devel" to get RXTX 2.1 The default branch is rxtx 2.0 which isn't very active right now. -- Trent Jarvi tjarvi at qbang.org From lyon at docjava.com Mon Mar 20 07:05:44 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Mon, 20 Mar 2006 09:05:44 -0500 Subject: [Rxtx] Mac OS X RXTX java installer In-Reply-To: References: <07D0DE29-BA32-4CFE-B036-66BC6423D385@buechse.de> <441AE3E0.2030503@willicon.de> <12531986.1142622114996.JavaMail.dmarkman@mac.com> <441B2674.9010409@willicon.de> <13577405.1142634732776.JavaMail.dmarkman@mac.com> <441B4182.8010407@willicon.de> <92CD0D6C-5BE8-426E-A46D-99452059FF49@mac.com> <441BBB2D.8030305@willicon.de> <441C4088.5090905@willicon.de> <64BC1E23-FDDE-4CE6-8863-CFC881CBC224@mac.com> Message-ID: Hi Trent, Thanks for the info on the CVS checkout procedure. I did that and am still not sure where the installer is. Here is what I have: cd MACOSX_IDE/ p4.docjava.com{lyon}121: ls CVS/ ForPackageMaker/ PB/ p4.docjava.com{lyon}122: find . | more . ./ForPackageMaker ./ForPackageMaker/RXTX.pkg.sit.hqx ./ForPackageMaker/Resources ./ForPackageMaker/Resources/ReadMe.rtf ./ForPackageMaker/Resources/Welcome.rtf ./ForPackageMaker/Resources/CVS ./ForPackageMaker/Resources/CVS/Entries ./ForPackageMaker/Resources/CVS/Repository ./ForPackageMaker/Resources/CVS/Tag ./ForPackageMaker/Resources/CVS/Root ./ForPackageMaker/Resources/preinstall ./ForPackageMaker/Resources/License.rtf ./ForPackageMaker/Resources/preupgrade ./ForPackageMaker/RXTX.pmsp ./ForPackageMaker/CVS ./ForPackageMaker/CVS/Entries ./ForPackageMaker/CVS/Repository ./ForPackageMaker/CVS/Entries.Log ./ForPackageMaker/CVS/Tag ./ForPackageMaker/CVS/Root ./ForPackageMaker/RXTX_Tiger.pkg.sitx.hqx ./ForPackageMaker/RXTX_Jag.pkg.sit.hqx ./ForPackageMaker/Install ./ForPackageMaker/Install/CVS ./ForPackageMaker/Install/CVS/Entries ./ForPackageMaker/Install/CVS/Repository ./ForPackageMaker/Install/CVS/Tag ./ForPackageMaker/Install/CVS/Root ./ForPackageMaker/Install/Library ./ForPackageMaker/Install/Library/CVS ./ForPackageMaker/Install/Library/CVS/Entries ./ForPackageMaker/Install/Library/CVS/Repository ./ForPackageMaker/Install/Library/CVS/Tag ./ForPackageMaker/Install/Library/CVS/Root ./ForPackageMaker/Install/Library/Java ./ForPackageMaker/Install/Library/Java/Extensions ./ForPackageMaker/Install/Library/Java/Extensions/RXTXcomm.jar ./ForPackageMaker/Install/Library/Java/Extensions/CVS ./ForPackageMaker/Install/Library/Java/Extensions/CVS/Entries ./ForPackageMaker/Install/Library/Java/Extensions/CVS/Repository ./ForPackageMaker/Install/Library/Java/Extensions/CVS/Tag ./ForPackageMaker/Install/Library/Java/Extensions/CVS/Root ./ForPackageMaker/Install/Library/Java/Extensions/librxtxSerial.jnilib ./ForPackageMaker/Install/Library/Java/CVS ./ForPackageMaker/Install/Library/Java/CVS/Entries ./ForPackageMaker/Install/Library/Java/CVS/Repository ./ForPackageMaker/Install/Library/Java/CVS/Entries.Log ./ForPackageMaker/Install/Library/Java/CVS/Tag ./ForPackageMaker/Install/Library/Java/CVS/Root ./ForPackageMaker/RXTX_Tiger.pmproj.sitx.hqx ./CVS ./CVS/Entries ./CVS/Repository ./CVS/Entries.Log ./CVS/Tag ./CVS/Root ./PB ./PB/LibSerialUniversal.xcodeproj.sitx.hqx ./PB/CVS ./PB/CVS/Entries ./PB/CVS/Repository ./PB/CVS/Entries.Log ./PB/CVS/Tag ./PB/CVS/Root ./PB/LibSerial.pbproj.sit.hqx ./PB/startpoint.c ./PB/config.h What is the procedure to run this installer? Do we need a README in: /rxtx-devel/MACOSX_IDE Here is what we have: CVS/ ForPackageMaker/ PB/ Thanks! - DL >On Mon, 20 Mar 2006, Dr. Douglas Lyon wrote: > >>Hi Dimitry, >>This sounds like great work. Just a couple of questions; >>After the check out of the CVS files, using: >>setenv CVSROOT >>:pserver:anonymous at cvs.milestonesolutions.com:/usr/local/cvsroot >> 53 8:28 setenv PASSWORD mousy >> 54 8:29 cvs login >> 55 8:29 cvs checkout rxtx-devel > >Hi Doug > >You want "cvs checkout -r commapi-0-0-1 rxtx-devel" to get RXTX 2.1 >The default branch is rxtx 2.0 which isn't very active right now. > >-- >Trent Jarvi >tjarvi at qbang.org From tjarvi at qbang.org Mon Mar 20 07:25:30 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 20 Mar 2006 07:25:30 -0700 (MST) Subject: [Rxtx] Mac OS X RXTX java installer In-Reply-To: References: <07D0DE29-BA32-4CFE-B036-66BC6423D385@buechse.de> <441AE3E0.2030503@willicon.de> <12531986.1142622114996.JavaMail.dmarkman@mac.com> <441B2674.9010409@willicon.de> <13577405.1142634732776.JavaMail.dmarkman@mac.com> <441B4182.8010407@willicon.de> <92CD0D6C-5BE8-426E-A46D-99452059FF49@mac.com> <441BBB2D.8030305@willicon.de> <441C4088.5090905@willicon.de> <64BC1E23-FDDE-4CE6-8863-CFC881CBC224@mac.com> Message-ID: On Mon, 20 Mar 2006, Dr. Douglas Lyon wrote: > Hi Trent, > Thanks for the info on the CVS checkout procedure. > I did that and am still not sure where the installer is. Hi Doug It does look like it was not cvs committed. There is no rxtx-devel/contrib/MacOSX directory in there at the moment. It was mentioned that it was put under contrib. -- Trent Jarvi tjarvi at qbang.org From dmarkman at mac.com Mon Mar 20 07:29:56 2006 From: dmarkman at mac.com (Dmitry Markman) Date: Mon, 20 Mar 2006 09:29:56 -0500 Subject: [Rxtx] Mac OS X RXTX java installer In-Reply-To: References: <07D0DE29-BA32-4CFE-B036-66BC6423D385@buechse.de> <441AE3E0.2030503@willicon.de> <12531986.1142622114996.JavaMail.dmarkman@mac.com> <441B2674.9010409@willicon.de> <13577405.1142634732776.JavaMail.dmarkman@mac.com> <441B4182.8010407@willicon.de> <92CD0D6C-5BE8-426E-A46D-99452059FF49@mac.com> <441BBB2D.8030305@willicon.de> <441C4088.5090905@willicon.de> <64BC1E23-FDDE-4CE6-8863-CFC881CBC224@mac.com> Message-ID: <6054EB4E-F7E0-4A9C-BDDA-D582D6D8826F@mac.com> you can find it in the rxtx-devel/contrib folder On Mar 20, 2006, at 9:05 AM, Dr. Douglas Lyon wrote: > Hi Trent, > Thanks for the info on the CVS checkout procedure. > I did that and am still not sure where the installer is. > Here is what I have: > cd MACOSX_IDE/ > p4.docjava.com{lyon}121: ls > CVS/ ForPackageMaker/ PB/ > p4.docjava.com{lyon}122: find . | more > . > ./ForPackageMaker > ./ForPackageMaker/RXTX.pkg.sit.hqx > ./ForPackageMaker/Resources > ./ForPackageMaker/Resources/ReadMe.rtf > ./ForPackageMaker/Resources/Welcome.rtf > ./ForPackageMaker/Resources/CVS > ./ForPackageMaker/Resources/CVS/Entries > ./ForPackageMaker/Resources/CVS/Repository > ./ForPackageMaker/Resources/CVS/Tag > ./ForPackageMaker/Resources/CVS/Root > ./ForPackageMaker/Resources/preinstall > ./ForPackageMaker/Resources/License.rtf > ./ForPackageMaker/Resources/preupgrade > ./ForPackageMaker/RXTX.pmsp > ./ForPackageMaker/CVS > ./ForPackageMaker/CVS/Entries > ./ForPackageMaker/CVS/Repository > ./ForPackageMaker/CVS/Entries.Log > ./ForPackageMaker/CVS/Tag > ./ForPackageMaker/CVS/Root > ./ForPackageMaker/RXTX_Tiger.pkg.sitx.hqx > ./ForPackageMaker/RXTX_Jag.pkg.sit.hqx > ./ForPackageMaker/Install > ./ForPackageMaker/Install/CVS > ./ForPackageMaker/Install/CVS/Entries > ./ForPackageMaker/Install/CVS/Repository > ./ForPackageMaker/Install/CVS/Tag > ./ForPackageMaker/Install/CVS/Root > ./ForPackageMaker/Install/Library > ./ForPackageMaker/Install/Library/CVS > ./ForPackageMaker/Install/Library/CVS/Entries > ./ForPackageMaker/Install/Library/CVS/Repository > ./ForPackageMaker/Install/Library/CVS/Tag > ./ForPackageMaker/Install/Library/CVS/Root > ./ForPackageMaker/Install/Library/Java > ./ForPackageMaker/Install/Library/Java/Extensions > ./ForPackageMaker/Install/Library/Java/Extensions/RXTXcomm.jar > ./ForPackageMaker/Install/Library/Java/Extensions/CVS > ./ForPackageMaker/Install/Library/Java/Extensions/CVS/Entries > ./ForPackageMaker/Install/Library/Java/Extensions/CVS/Repository > ./ForPackageMaker/Install/Library/Java/Extensions/CVS/Tag > ./ForPackageMaker/Install/Library/Java/Extensions/CVS/Root > ./ForPackageMaker/Install/Library/Java/Extensions/librxtxSerial.jnilib > ./ForPackageMaker/Install/Library/Java/CVS > ./ForPackageMaker/Install/Library/Java/CVS/Entries > ./ForPackageMaker/Install/Library/Java/CVS/Repository > ./ForPackageMaker/Install/Library/Java/CVS/Entries.Log > ./ForPackageMaker/Install/Library/Java/CVS/Tag > ./ForPackageMaker/Install/Library/Java/CVS/Root > ./ForPackageMaker/RXTX_Tiger.pmproj.sitx.hqx > ./CVS > ./CVS/Entries > ./CVS/Repository > ./CVS/Entries.Log > ./CVS/Tag > ./CVS/Root > ./PB > ./PB/LibSerialUniversal.xcodeproj.sitx.hqx > ./PB/CVS > ./PB/CVS/Entries > ./PB/CVS/Repository > ./PB/CVS/Entries.Log > ./PB/CVS/Tag > ./PB/CVS/Root > ./PB/LibSerial.pbproj.sit.hqx > ./PB/startpoint.c > ./PB/config.h > > What is the procedure to run this installer? > Do we need a README in: > /rxtx-devel/MACOSX_IDE > Here is what we have: > CVS/ ForPackageMaker/ PB/ > > > Thanks! > - DL > >> On Mon, 20 Mar 2006, Dr. Douglas Lyon wrote: >> >>> Hi Dimitry, >>> This sounds like great work. Just a couple of questions; >>> After the check out of the CVS files, using: >>> setenv CVSROOT :pserver:anonymous at cvs.milestonesolutions.com:/usr/ >>> local/cvsroot >>> 53 8:28 setenv PASSWORD mousy >>> 54 8:29 cvs login >>> 55 8:29 cvs checkout rxtx-devel >> >> Hi Doug >> >> You want "cvs checkout -r commapi-0-0-1 rxtx-devel" to get RXTX 2.1 >> The default branch is rxtx 2.0 which isn't very active right now. >> >> -- >> Trent Jarvi >> tjarvi at qbang.org > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx Dmitry Markman From mikehall at spacestar.net Mon Mar 20 05:25:25 2006 From: mikehall at spacestar.net (Michael Hall) Date: Mon, 20 Mar 2006 06:25:25 -0600 Subject: [Rxtx] Re: Mac OS X RXTX java installer In-Reply-To: <64BC1E23-FDDE-4CE6-8863-CFC881CBC224@mac.com> References: <07D0DE29-BA32-4CFE-B036-66BC6423D385@buechse.de> <441AE3E0.2030503@willicon.de> <12531986.1142622114996.JavaMail.dmarkman@mac.com> <441B2674.9010409@willicon.de> <13577405.1142634732776.JavaMail.dmarkman@mac.com> <441B4182.8010407@willicon.de> <92CD0D6C-5BE8-426E-A46D-99452059FF49@mac.com> <441BBB2D.8030305@willicon.de> <441C4088.5090905@willicon.de> <64BC1E23-FDDE-4CE6-8863-CFC881CBC224@mac.com> Message-ID: <247EB61F-5CD1-4132-89A2-FC105B6CF9A5@spacestar.net> On Mar 20, 2006, at 1:20 AM, Dmitry Markman wrote: > > Michael Hall (mikehall at spacestar dot net) had a suggestion to > make implementation of the jaas LoginModule > based on Greg's AuthKit > (his modification of the Greg's AuthKit could be found at http:// > www.spacestar.net/users/mikehall/authkit.dmg) > but Michael's AuthKitLoginModule does only half a job: > it does authenticate > but it can not run any external unix process in privileged mode (at > least I wasn't able to do so) If you got it working directly with Greg's the point is moot. But to clarify it anyhow. The login module does not allow you to do anything anything privileged on return as was explained by Greg. You need to work with a separate privileged process using the execPrivileged method of his API. I assume you did something similar although I haven't looked at how you are using it yet. I allowed instead for a action to be performed at the same time you login/authenticate,this... System.setProperty("authkit.action","/usr/bin/id"); just before this... lc.login(); To clarify, safely ignored as you are already complete. Mike Hall mikehall at spacestar dot net http://www.spacestar.net/users/mikehall http://sourceforge.net/projects/macnative -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2427 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20060320/f6e18202/smime-0041.bin From dmarkman at mac.com Mon Mar 20 07:36:47 2006 From: dmarkman at mac.com (Dmitry Markman) Date: Mon, 20 Mar 2006 09:36:47 -0500 Subject: [Rxtx] Re: Mac OS X RXTX java installer In-Reply-To: <247EB61F-5CD1-4132-89A2-FC105B6CF9A5@spacestar.net> References: <07D0DE29-BA32-4CFE-B036-66BC6423D385@buechse.de> <441AE3E0.2030503@willicon.de> <12531986.1142622114996.JavaMail.dmarkman@mac.com> <441B2674.9010409@willicon.de> <13577405.1142634732776.JavaMail.dmarkman@mac.com> <441B4182.8010407@willicon.de> <92CD0D6C-5BE8-426E-A46D-99452059FF49@mac.com> <441BBB2D.8030305@willicon.de> <441C4088.5090905@willicon.de> <64BC1E23-FDDE-4CE6-8863-CFC881CBC224@mac.com> <247EB61F-5CD1-4132-89A2-FC105B6CF9A5@spacestar.net> Message-ID: Hi, Michael all I have to do is to run some shell script I tried to use your action mechanism and it worked great so I just System.setProperty ("authkit.action","" ) and after that I even don't need to run anything like subject.doAs.... but after few thoughts I choose to use plain Greg's approach, because in that case I don't have to deal with various java's configurations files and therefore to use 2-3 -D parameters in the java command line especially it's useful for java web start (it's so fragile :-( ) thanks for the great job On Mar 20, 2006, at 7:25 AM, Michael Hall wrote: > > On Mar 20, 2006, at 1:20 AM, Dmitry Markman wrote: >> >> Michael Hall (mikehall at spacestar dot net) had a suggestion to >> make implementation of the jaas LoginModule >> based on Greg's AuthKit >> (his modification of the Greg's AuthKit could be found at http:// >> www.spacestar.net/users/mikehall/authkit.dmg) >> but Michael's AuthKitLoginModule does only half a job: >> it does authenticate >> but it can not run any external unix process in privileged mode >> (at least I wasn't able to do so) > > If you got it working directly with Greg's the point is moot. > > But to clarify it anyhow. > The login module does not allow you to do anything anything > privileged on return as was explained by Greg. You need to work > with a separate privileged process using the execPrivileged method > of his API. I assume you did something similar although I haven't > looked at how you are using it yet. > I allowed instead for a action to be performed at the same time you > login/authenticate,this... > System.setProperty("authkit.action","/usr/bin/id"); > just before this... > lc.login(); > To clarify, safely ignored as you are already complete. > > Mike Hall mikehall at spacestar dot net > http://www.spacestar.net/users/mikehall > http://sourceforge.net/projects/macnative > > > Dmitry Markman From dmarkman at mac.com Mon Mar 20 07:44:45 2006 From: dmarkman at mac.com (Dmitry Markman) Date: Mon, 20 Mar 2006 09:44:45 -0500 Subject: [Rxtx] Mac OS X RXTX java installer In-Reply-To: References: <07D0DE29-BA32-4CFE-B036-66BC6423D385@buechse.de> <441AE3E0.2030503@willicon.de> <12531986.1142622114996.JavaMail.dmarkman@mac.com> <441B2674.9010409@willicon.de> <13577405.1142634732776.JavaMail.dmarkman@mac.com> <441B4182.8010407@willicon.de> <92CD0D6C-5BE8-426E-A46D-99452059FF49@mac.com> <441BBB2D.8030305@willicon.de> <441C4088.5090905@willicon.de> <64BC1E23-FDDE-4CE6-8863-CFC881CBC224@mac.com> Message-ID: it's in the commapi-0-0-1 branch I tested it right now: cvs co -r commapi-0-0-1 rxtx-devel and I got everything On Mar 20, 2006, at 9:25 AM, Trent Jarvi wrote: > On Mon, 20 Mar 2006, Dr. Douglas Lyon wrote: > >> Hi Trent, >> Thanks for the info on the CVS checkout procedure. >> I did that and am still not sure where the installer is. > > Hi Doug > > It does look like it was not cvs committed. There is no rxtx-devel/ > contrib/MacOSX directory in there at the moment. It was mentioned > that it was put under contrib. > > -- > Trent Jarvi > tjarvi at qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx Dmitry Markman From tjarvi at qbang.org Mon Mar 20 07:52:57 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 20 Mar 2006 07:52:57 -0700 (MST) Subject: [Rxtx] Mac OS X RXTX java installer In-Reply-To: References: <07D0DE29-BA32-4CFE-B036-66BC6423D385@buechse.de> <441AE3E0.2030503@willicon.de> <12531986.1142622114996.JavaMail.dmarkman@mac.com> <441B2674.9010409@willicon.de> <13577405.1142634732776.JavaMail.dmarkman@mac.com> <441B4182.8010407@willicon.de> <92CD0D6C-5BE8-426E-A46D-99452059FF49@mac.com> <441BBB2D.8030305@willicon.de> <441C4088.5090905@willicon.de> <64BC1E23-FDDE-4CE6-8863-CFC881CBC224@mac.com> Message-ID: On Mon, 20 Mar 2006, Dmitry Markman wrote: > it's in the commapi-0-0-1 branch > > I tested it right now: > cvs co -r commapi-0-0-1 rxtx-devel > > and I got everything > A fresh checkout worked. Here is a copy of the tree (just the installer bits) ftp://ftp.qbang.org/pub/rxtx/MacOSX-installer.zip -- Trent Jarvi tjarvi at qbang.org From lyon at docjava.com Mon Mar 20 08:08:26 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Mon, 20 Mar 2006 10:08:26 -0500 Subject: [Rxtx] Mac OS X RXTX java installer In-Reply-To: References: <07D0DE29-BA32-4CFE-B036-66BC6423D385@buechse.de> <441AE3E0.2030503@willicon.de> <12531986.1142622114996.JavaMail.dmarkman@mac.com> <441B2674.9010409@willicon.de> <13577405.1142634732776.JavaMail.dmarkman@mac.com> <441B4182.8010407@willicon.de> <92CD0D6C-5BE8-426E-A46D-99452059FF49@mac.com> <441BBB2D.8030305@willicon.de> <441C4088.5090905@willicon.de> <64BC1E23-FDDE-4CE6-8863-CFC881CBC224@mac.com> Message-ID: Hi All, Is the Auth package able to work properly on non Mac OS's? It was not clear from the doc or download. Thanks! - Doug From dmarkman at mac.com Mon Mar 20 08:15:22 2006 From: dmarkman at mac.com (Dmitry Markman) Date: Mon, 20 Mar 2006 10:15:22 -0500 Subject: [Rxtx] Mac OS X RXTX java installer In-Reply-To: References: <07D0DE29-BA32-4CFE-B036-66BC6423D385@buechse.de> <441AE3E0.2030503@willicon.de> <12531986.1142622114996.JavaMail.dmarkman@mac.com> <441B2674.9010409@willicon.de> <13577405.1142634732776.JavaMail.dmarkman@mac.com> <441B4182.8010407@willicon.de> <92CD0D6C-5BE8-426E-A46D-99452059FF49@mac.com> <441BBB2D.8030305@willicon.de> <441C4088.5090905@willicon.de> <64BC1E23-FDDE-4CE6-8863-CFC881CBC224@mac.com> Message-ID: <217312D8-CCCA-4859-ABA6-32DF1CC817B9@mac.com> thanks Trent, for putting it on ftp server On Mar 20, 2006, at 9:52 AM, Trent Jarvi wrote: > A fresh checkout worked. Here is a copy of the tree (just the > installer bits) > > ftp://ftp.qbang.org/pub/rxtx/MacOSX-installer.zip > Dmitry Markman From dmarkman at mac.com Mon Mar 20 09:14:03 2006 From: dmarkman at mac.com (Dmitry Markman) Date: Mon, 20 Mar 2006 11:14:03 -0500 Subject: [Rxtx] Mac OS X RXTX java installer In-Reply-To: References: <07D0DE29-BA32-4CFE-B036-66BC6423D385@buechse.de> <441AE3E0.2030503@willicon.de> <12531986.1142622114996.JavaMail.dmarkman@mac.com> <441B2674.9010409@willicon.de> <13577405.1142634732776.JavaMail.dmarkman@mac.com> <441B4182.8010407@willicon.de> <92CD0D6C-5BE8-426E-A46D-99452059FF49@mac.com> <441BBB2D.8030305@willicon.de> <441C4088.5090905@willicon.de> <64BC1E23-FDDE-4CE6-8863-CFC881CBC224@mac.com> Message-ID: <4DEBA6F0-DA45-4E84-823E-1F1AC48BDCCC@mac.com> no it will work only on mac os x however it's harmless to run it on other platform if you want to use it for other platform you have to do the following (I'll do it for linux) 1. modify RXTXInstaller class method public static RXTXInstaller getInstance() public static RXTXInstaller getInstance() { String osName = System.getProperty("os.name").toLowerCase(); if(osName.startsWith("mac")){ return new gnu.io.installer.macosx.MACOSXRXTXInstaller(); } else if(osName.startsWith("windows")){ return new gnu.io.installer.windows.WindowsRXTXInstaller(); }else if(osName.startsWith("linux")){ return new gnu.io.installer.linux.LinuxRXTXInstaller(); } return null; } 2. create folder gnu/io/installer/linux/ 3. create class Linux386RXTXInstaller package gnu.io.installer.linux; import java.io.File; public class Linux386RXTXInstaller extends gnu.io.installer.RXTXInstaller{ public Linux386RXTXInstaller(){ createJarFolder(); createLibFolder(); addJarResource("RXTXcomm.jar","/gnu/io/installer/resources/ linux/jar/RXTXcomm.dat"); addLibResource("librxtxSerial.so","/gnu/io/installer/ resources/linux/lib/librxtxSerial.so"); } protected void createJarFolder(){ String javaHome = System.getProperty("java.home"); char separator = File.separatorChar; jarFolder = new File(javaHome+separator+"lib"+separator+"ext"); } protected void createLibFolder(){ String javaHome = System.getProperty("java.home"); char separator = File.separatorChar; libFolder = new File(javaHome+separator+"bin"); } public void runPreProcess() {} //put here some action you need public void runPostProcess() {} //put here some action you need } 4. create folder /gnu/io/installer/resources/linux/jar and put there linux's version of RXTXcomm.dat (which is renamed RXTXcomm.jar) 5. create folder /gnu/io/installer/resources/linux/lib and put there linux's version of librxtxSerial. so 6. make sure that RXTXInstaller.jar has the following items: /gnu/io/installer/resources/linux/jar/RXTXcomm.jar /gnu/io/installer/resources/linux/lib/librxtxSerial.so 7. modify file installer.pref: jar file RXTXInstaller.jar must have the following item /gnu/io/installer/installer.pref that's basically it for windows you have to do the similar things: just replace linux to windows and librxtxSerial.so to rxtxSerial.dll and create appropriate gnu.io.installer.windows.WindowsRXTXInstaller class package gnu.io.installer.windows; import java.io.File; public class WindowsRXTXInstaller extends gnu.io.installer.RXTXInstaller{ public WindowsRXTXInstaller(){ createJarFolder(); createLibFolder(); addJarResource("RXTXcomm.jar","/gnu/io/installer/resources/ windows/jar/RXTXcomm.dat"); addLibResource("librxtxSerial.so","/gnu/io/installer/ resources/windows/lib/rxtxSerial.dll"); } protected void createJarFolder(){ String javaHome = System.getProperty("java.home"); char separator = File.separatorChar; jarFolder = new File(javaHome+separator+"lib"+separator+"ext"); } protected void createLibFolder(){ String javaHome = System.getProperty("java.home"); char separator = File.separatorChar; libFolder = new File(javaHome+separator+"bin"); } public void runPreProcess() {} //put here some action you need public void runPostProcess() {} //put here some action you need } installer.pref will look like On Mar 20, 2006, at 10:08 AM, Dr. Douglas Lyon wrote: > Hi All, > Is the Auth package able to work properly on > non Mac OS's? > It was not clear from the doc or download. > > Thanks! > - Doug > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx Dmitry Markman From joachim at buechse.de Mon Mar 20 10:49:06 2006 From: joachim at buechse.de (Joachim Buechse) Date: Mon, 20 Mar 2006 18:49:06 +0100 Subject: [Rxtx] BUG: Lock file stays even if port opening fails Message-ID: This was only tested on MacOSX but looking at the code, it should be true for all systems that use lock_uucp. I am opening a port which can not be opened (dialup port of a telephone paired via bluetooth but currently not reachable). The lock file is created and stays arround, even though the port open failed. After looking a bit through the code (of 2.17), I really wonder if it wouldn't be a good idea to make the "locking" an explicit operation called from the java code. This would certainly simplify the generation of meaningfull exceptions (and java based debugging). Maybe even the handling of "preopened" ports should be in the Java part of the lib (again for java based debugging puposes). That beeing said, I have no idea if this would be possible for the 2.07 implementation. Regards, Joachim From tjarvi at qbang.org Mon Mar 20 11:24:22 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 20 Mar 2006 11:24:22 -0700 (MST) Subject: [Rxtx] BUG: Lock file stays even if port opening fails In-Reply-To: References: Message-ID: On Mon, 20 Mar 2006, Joachim Buechse wrote: > This was only tested on MacOSX but looking at the code, it should be true > for all systems that use lock_uucp. > > I am opening a port which can not be opened (dialup port of a telephone > paired via bluetooth but currently not reachable). The lock file is > created and stays arround, even though the port open failed. > > > After looking a bit through the code (of 2.17), I really wonder if it > wouldn't be a good idea to make the "locking" an explicit operation > called from the java code. This would certainly simplify the generation > of meaningfull exceptions (and java based debugging). > Maybe even the handling of "preopened" ports should be in the Java part > of the lib (again for java based debugging puposes). That beeing said, I > have no idea if this would be possible for the 2.07 implementation. > > Regards, Hi Joachim It should be possible in the 2.0-7 implementation too. The calls to RXTXPort.java would not change. We would just do more there Moving more of that logic into Java would be better as many people don't like to look at C code. There is a liblockdev on most Linux distros that can do most of the C code and would be easier to use. The problem is embeded devices will not have that library. The preopened port code has not been really tested. That was a last minute request in a product cycle. I expect it will be tested this year though. As I recall, some devices really do not like CD raising on open. The preopened ports then allow people to mess around in java without power cycling the devices or losing data. -- Trent Jarvi tjarvi at qbang.org From joachim at buechse.de Mon Mar 20 12:01:08 2006 From: joachim at buechse.de (Joachim Buechse) Date: Mon, 20 Mar 2006 20:01:08 +0100 Subject: [Rxtx] BUG: Lock file stays even if port opening fails In-Reply-To: References: Message-ID: Hi Trent, What is your general feeling about moving code to Java? The last days I have been reading quite a bit of the code and there are several things, that might not work as expected. I'll give you two examples from is_device_locked: if LOCKDIR == /var/spool/locks the directory /var/spool/lock will not be checked. LOCKDIR is not checked for lockfiles with unexpected pefixes While these things have probably never been discovered in production, they are still possibly incorrect implementations. If it was Java code, I would write some unit tests producing the errors that could later be corrected. PS: One could imagine to actually implement the whole lockfile handling in Java using some native routines to get the values required (pid, st_dev, st_rdev, ...). On 20.03.2006, at 19:24, Trent Jarvi wrote: > On Mon, 20 Mar 2006, Joachim Buechse wrote: > >> This was only tested on MacOSX but looking at the code, it should >> be true for all systems that use lock_uucp. >> >> I am opening a port which can not be opened (dialup port of a >> telephone paired via bluetooth but currently not reachable). The >> lock file is created and stays arround, even though the port open >> failed. >> >> >> After looking a bit through the code (of 2.17), I really wonder if >> it wouldn't be a good idea to make the "locking" an explicit >> operation called from the java code. This would certainly simplify >> the generation of meaningfull exceptions (and java based debugging). >> Maybe even the handling of "preopened" ports should be in the Java >> part of the lib (again for java based debugging puposes). That >> beeing said, I have no idea if this would be possible for the 2.07 >> implementation. >> >> Regards, > > Hi Joachim > > It should be possible in the 2.0-7 implementation too. The calls > to RXTXPort.java would not change. We would just do more there > Moving more of that logic into Java would be better as many people > don't like to look at C code. There is a liblockdev on most Linux > distros that can do most of the C code and would be easier to use. > The problem is embeded devices will not have that library. > > The preopened port code has not been really tested. That was a > last minute request in a product cycle. I expect it will be tested > this year though. As I recall, some devices really do not like CD > raising on open. The preopened ports then allow people to mess > around in java without power cycling the devices or losing data. > > -- > Trent Jarvi > tjarvi at qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Mon Mar 20 12:21:02 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 20 Mar 2006 12:21:02 -0700 (MST) Subject: [Rxtx] BUG: Lock file stays even if port opening fails In-Reply-To: References: Message-ID: On Mon, 20 Mar 2006, Joachim Buechse wrote: > Hi Trent, > > What is your general feeling about moving code to Java? The last days I > have been reading quite a bit of the code and there are several things, > that might not work as expected. > > I'll give you two examples from is_device_locked: > > if LOCKDIR == /var/spool/locks the directory /var/spool/lock will not be > checked. > LOCKDIR is not checked for lockfiles with unexpected pefixes > > While these things have probably never been discovered in production, > they are still possibly incorrect implementations. If it was Java code, I > would write some unit tests producing the errors that could later be > corrected. > > PS: One could imagine to actually implement the whole lockfile handling > in Java using some native routines to get the values required (pid, > st_dev, st_rdev, ...). Hi Joachim I like the idea of moving more of the code into java but there are some things to consider. If you break this into multiple JNI calls, the performance will drop considerably during enumeration of ports. We are looking for 256 ports per dev type vs (16? in Sun's 2.0 and fewer types). Its hard to make assumptions. I've seen virtual ports start at /dev/foo100 for instance. It works out to over 7500 ports on Linux if you enable them all. We already trim that back by default. See Linux-all-ports in RXTXCommDriver.java. There are also native libraries that rxtx can link to. If you move too much into Java, linking to 'standard' libraries with distros will break. "configure --enable-liblock=yes" will not be doable. This is probably a favorable way with RedHat, Debian, Suse and others. Thats the right thing to do if there will be rpms, dpkg, .. For those reasons, I think it still make sense to keep it to a minimal ~3 calls to JNI code that we can use for speed and versatility. lock() isLocked(), unlock() perhaps. When I say speed, its more about avoiding crossing the JNI layer multiple times than java vs C performance. With versatility I think liblock is the right way for most but not all (embeded) linux distros. -- Trent Jarvi tjarvi at qbang.org From joachim at buechse.de Mon Mar 20 12:42:04 2006 From: joachim at buechse.de (Joachim Buechse) Date: Mon, 20 Mar 2006 20:42:04 +0100 Subject: [Rxtx] BUG: Lock file stays even if port opening fails In-Reply-To: References: Message-ID: <82C19FE7-DDCB-45B6-B2C9-7606B66F0124@buechse.de> Ok, what about providing a default implementation in Java? The RXTXCommDriver would call a (native) function useNativeLocking and if it returns true, call the native functions for lock() isLocked (), unlock(), else is would use the Java based default implementation. This could possibly be overriden by a property (again for debugging). Joachim On 20.03.2006, at 20:21, Trent Jarvi wrote: > On Mon, 20 Mar 2006, Joachim Buechse wrote: > >> Hi Trent, >> >> What is your general feeling about moving code to Java? The last >> days I have been reading quite a bit of the code and there are >> several things, that might not work as expected. >> >> I'll give you two examples from is_device_locked: >> >> if LOCKDIR == /var/spool/locks the directory /var/spool/lock will >> not be checked. >> LOCKDIR is not checked for lockfiles with unexpected pefixes >> >> While these things have probably never been discovered in >> production, they are still possibly incorrect implementations. If >> it was Java code, I would write some unit tests producing the >> errors that could later be corrected. >> >> PS: One could imagine to actually implement the whole lockfile >> handling in Java using some native routines to get the values >> required (pid, st_dev, st_rdev, ...). > > Hi Joachim > > I like the idea of moving more of the code into java but there are > some things to consider. > > If you break this into multiple JNI calls, the performance will > drop considerably during enumeration of ports. We are looking for > 256 ports per dev type vs (16? in Sun's 2.0 and fewer types). Its > hard to make assumptions. I've seen virtual ports start at /dev/ > foo100 for instance. > > It works out to over 7500 ports on Linux if you enable them all. > We already trim that back by default. See Linux-all-ports in > RXTXCommDriver.java. > > There are also native libraries that rxtx can link to. If you move > too much into Java, linking to 'standard' libraries with distros > will break. "configure --enable-liblock=yes" will not be doable. > This is probably a favorable way with RedHat, Debian, Suse and > others. Thats the right thing to do if there will be rpms, dpkg, .. > > For those reasons, I think it still make sense to keep it to a > minimal ~3 calls to JNI code that we can use for speed and > versatility. lock() isLocked(), unlock() perhaps. When I say > speed, its more about avoiding crossing the JNI layer multiple > times than java vs C performance. With versatility I think liblock > is the right way for most but not all (embeded) linux distros. > > -- > Trent Jarvi > tjarvi at qbang.org > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Mon Mar 20 12:44:47 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 20 Mar 2006 12:44:47 -0700 (MST) Subject: [Rxtx] BUG: Lock file stays even if port opening fails In-Reply-To: <82C19FE7-DDCB-45B6-B2C9-7606B66F0124@buechse.de> References: <82C19FE7-DDCB-45B6-B2C9-7606B66F0124@buechse.de> Message-ID: On Mon, 20 Mar 2006, Joachim Buechse wrote: > Ok, what about providing a default implementation in Java? > > The RXTXCommDriver would call a (native) function useNativeLocking and if > it returns true, call the native functions for lock() isLocked(), > unlock(), else is would use the Java based default implementation. This > could possibly be overriden by a property (again for debugging). > Hi Joachim That would be OK with me. -- Trent Jarvi tjarvi at qbang.org From dmarkman at mac.com Mon Mar 20 22:27:45 2006 From: dmarkman at mac.com (Dmitry Markman) Date: Tue, 21 Mar 2006 00:27:45 -0500 Subject: [Rxtx] binaries request Message-ID: <42702213-C222-4937-A585-7CFB17E47608@mac.com> Hi can somebody send me latest linux and windows binaries, please? or where I can find them (I didn't find them in the latest tareball) I gave up with my cygwin: something wrong I have no idea what java doesn't understand /cygwin/c syntax after I changed makefile it did java part but after that gcc 3.4.4 started to complain I set buffer length to 999 lines but I didn't get beginning of the story something wrong with my 1.4.2_09/include/jni.h gcc doesn't like it anyway I gave up thanks in advance Dmitry Markman -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060320/f8cbc57c/attachment-0041.html From tjarvi at qbang.org Mon Mar 20 22:36:48 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 20 Mar 2006 22:36:48 -0700 (MST) Subject: [Rxtx] binaries request In-Reply-To: <42702213-C222-4937-A585-7CFB17E47608@mac.com> References: <42702213-C222-4937-A585-7CFB17E47608@mac.com> Message-ID: On Tue, 21 Mar 2006, Dmitry Markman wrote: > Hi > can somebody send me latest linux and windows binaries, please? > > or where I can find them (I didn't find them in the latest tareball) > > I gave up with my cygwin: something wrong I have no idea what > java doesn't understand /cygwin/c syntax > after I changed makefile it did java part > but after that gcc 3.4.4 started to complain > I set buffer length to 999 lines but I didn't get beginning of the story > something wrong with my 1.4.2_09/include/jni.h gcc doesn't like it > anyway I gave up > > thanks in advance > Hi Dmitry The bins are here: ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7-bins-r2.zip Here are the files in the zip you want. Jar: rxtx-2.1-7-bins-r2/RXTXcomm.jar Windows: rxtx-2.1-7-bins-r2/Windows/i368-mingw32/rxtxSerial.dll Linux (x86) rxtx-2.1-7-bins-r2/Linux/i686-unknown-linux-gnu/librxtxSerial.so There are others in there including Parallel port support but those are the main ones for testing. -- Trent Jarvi tjarvi at qbang.org From dmarkman at mac.com Mon Mar 20 23:05:59 2006 From: dmarkman at mac.com (Dmitry Markman) Date: Tue, 21 Mar 2006 01:05:59 -0500 Subject: [Rxtx] binaries request In-Reply-To: References: <42702213-C222-4937-A585-7CFB17E47608@mac.com> Message-ID: thank you very much but windows's readme says: rxtxSerial.dll had to be recomopiled to link in missing native methods. should I ignore it? or what? thanks again also I understand that I should use mingw not cygwin I'll try to install mingw On Mar 21, 2006, at 12:36 AM, Trent Jarvi wrote: > On Tue, 21 Mar 2006, Dmitry Markman wrote: > >> Hi >> can somebody send me latest linux and windows binaries, please? >> >> or where I can find them (I didn't find them in the latest tareball) >> >> I gave up with my cygwin: something wrong I have no idea what >> java doesn't understand /cygwin/c syntax >> after I changed makefile it did java part >> but after that gcc 3.4.4 started to complain >> I set buffer length to 999 lines but I didn't get beginning of the >> story >> something wrong with my 1.4.2_09/include/jni.h gcc doesn't like it >> anyway I gave up >> >> thanks in advance >> > > Hi Dmitry > > The bins are here: > > ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7-bins-r2.zip > > Here are the files in the zip you want. > > Jar: > > rxtx-2.1-7-bins-r2/RXTXcomm.jar > > Windows: > > rxtx-2.1-7-bins-r2/Windows/i368-mingw32/rxtxSerial.dll > > Linux (x86) > > rxtx-2.1-7-bins-r2/Linux/i686-unknown-linux-gnu/librxtxSerial.so > > There are others in there including Parallel port support but those > are the main ones for testing. > > -- > Trent Jarvi > tjarvi at qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx Dmitry Markman From tjarvi at qbang.org Mon Mar 20 23:20:33 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 20 Mar 2006 23:20:33 -0700 (MST) Subject: [Rxtx] binaries request In-Reply-To: References: <42702213-C222-4937-A585-7CFB17E47608@mac.com> Message-ID: On Tue, 21 Mar 2006, Dmitry Markman wrote: > thank you very much > > but windows's readme says: > rxtxSerial.dll had to be recomopiled to link in missing native methods. > > should I ignore it? or what? > Hi Dmitry That dll should be OK. r2 is the recompile linked to the missing native method. The readme explains why it was recompiled; fuser.o was not linked into the dll in the first release. -- Trent Jarvi tjarvi at qbang.org From ariantristan at yahoo.com Mon Mar 20 23:55:24 2006 From: ariantristan at yahoo.com (Lambok Sianturi) Date: Mon, 20 Mar 2006 22:55:24 -0800 (PST) Subject: [Rxtx] jvm issue Message-ID: <20060321065524.94779.qmail@web50701.mail.yahoo.com> Hi All, This is my first time to join RxTx mailing list. I thank you all for allowing others to sign in in requests help. I use the latest RxTx lib in Fedora 3 with java version 1.4.2_09 b05. And I got this error: # # An unexpected error has been detected by HotSpot Virtual Machine: # # SIGSEGV (0xb) at pc=0x00bf27f3, pid=2633, tid=3086112448 # # Java VM: Java HotSpot(TM) Client VM (1.4.2_09-b05 mixed mode) # Problematic frame: # C [ld-linux.so.2+0xa7f3] # # An error report file with more information is saved as hs_err_pid2633.log # # If you would like to submit a bug report, please visit: # http://java.sun.com/webapps/bugreport/crash.jsp # ./run.sh: line 3: 2633 Aborted /usr/local/java/bin/java -Djava.library.path=/usr/local/java/jre/lib/ -Djsmsengine.debug=true -classpath jsmsengine.jar:smsgateway.jar:classes12.jar:RXTXcomm.jar:. com.api.sms.SMSServer What is the jvm depedency for the latest library? Can I use 1.4.2_09 b05? Thanks in advance. Arian --------------------------------- Yahoo! Mail Use Photomail to share photos without annoying attachments. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060320/83d58dd7/attachment-0041.html From f.frumento at ngi.it Tue Mar 21 00:21:47 2006 From: f.frumento at ngi.it (Fabio Frumento) Date: Tue, 21 Mar 2006 08:21:47 +0100 Subject: [Rxtx] Javadoc on the go Message-ID: <441FA98B.9050701@ngi.it> Hi Trent, sorry for the big delay but my job is running wild, i was out for some time but now i'm back and ready to continue the javadoc for Rxtx. Did you used the last javadoc patch i sent you ? let me know if i have to send it to you again or not. regards Fabio From lyon at docjava.com Tue Mar 21 00:51:18 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Tue, 21 Mar 2006 02:51:18 -0500 Subject: [Rxtx] lock files Message-ID: Hi All, You know, if the use of lock files were under Java control (rather than a build-time decision), it might enable a more unified binary distro. It might also facilitate quick prototyping of non-lock file approaches to resolving serial port contention issues (i.e., mac-like approaches vs. linux approaches, etc.). I realize that this is a radical overhaul of the lock file policy issue. Also, it may harm performance. On the other hand, our benchmarks on JNI overhead for modern processors indicate performance impact should be minimal. Perhaps it is more of an issue with the toybox systems. Suppose there were a class with a reasonable default...someone might write: SerialPortLockPolicy.setPolicy(SerialPortLockPolicy.UNIX_LOCK_FILE); SerialPortLockPolicy.setPolicy(SerialPortLockPolicy.NO_LOCK_CHECKING); SerialPortLockPolicy.setPolicy(SerialPortLockPolicy.MAC_STYLE); Thus, we could have a run-time reconfiguration of the serial port lock policy. A special NO_LOCK version of the binary would no longer be required. Any thoughts on this? Thanks! - Doug From joachim at buechse.de Tue Mar 21 03:09:09 2006 From: joachim at buechse.de (Joachim Buechse) Date: Tue, 21 Mar 2006 11:09:09 +0100 Subject: [Rxtx] lock files In-Reply-To: References: Message-ID: <8E12916A-1B9A-4FF2-B684-E2D1C794221B@buechse.de> This is pretty much what I thought about when I suggested, that the default behaviour could be overwritten with a property. I am very much in favor of this approach. In particular this allows much easier debugging for PC based java developers. I think big parts of the Java (and maybe some parts of the C code) could use a bit of a structural workover (unit tests, javadoc, synchronization, etc). Maybe there should be a CVS branch for this experimental version. I'd be happy to contribute a first workover for some of the Java code. Designing for testability and implementing a good bunch of unit tests has been a strategy that worked quite well in the Java projects I lead. And it ultimately allows more liberal change permission. Regards, Joachim On 21.03.2006, at 08:51, Dr. Douglas Lyon wrote: > Hi All, > You know, if the use of lock files were > under Java control (rather than a build-time decision), > it might enable a more unified binary distro. It might also > facilitate quick prototyping of non-lock file approaches > to resolving serial port contention issues (i.e., mac-like > approaches vs. linux approaches, etc.). > > I realize that this is a radical overhaul of the lock file policy > issue. Also, it may harm performance. On the other hand, > our benchmarks on JNI overhead for modern processors indicate > performance impact should be minimal. Perhaps it is more of > an issue with the toybox systems. > > Suppose there were a class with a reasonable default...someone > might write: > SerialPortLockPolicy.setPolicy(SerialPortLockPolicy.UNIX_LOCK_FILE); > SerialPortLockPolicy.setPolicy(SerialPortLockPolicy.NO_LOCK_CHECKING); > SerialPortLockPolicy.setPolicy(SerialPortLockPolicy.MAC_STYLE); > > Thus, we could have a run-time reconfiguration of the serial port lock > policy. A special NO_LOCK version of the binary would no longer > be required. > > Any thoughts on this? > > Thanks! > - Doug > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From joachim at buechse.de Tue Mar 21 06:23:08 2006 From: joachim at buechse.de (Joachim Buechse) Date: Tue, 21 Mar 2006 14:23:08 +0100 Subject: [Rxtx] PATCH: use of ioctl(fd, TIOCEXCL) instead of lockfiles Message-ID: <923AE774-EEA2-4911-92D8-32BB27802C8B@buechse.de> Here is the patch for the ioctl(fd, TIOCEXCL). I have verified this only for OSX 10.4.5, hence it is only defined for APPLE. However, it should work at least for Solaris as well. If a process has requested TIOEXCL further open calls by other user processes will fail. The patch also disables uucp style locking for APPLE. Obviously this is discussable. I think it is the way to go, as it eliminates creating the lock directory which doesnt exist on the standard installation and it eliminates messing with the system group definitions (adding users to group uucp). Regarding the possibility of root processes opening a device which is locked - I consider this a feature not a potential problem. It is highly unlikely, that somebody is crazy enough to run a JavaVM as root (unless he has no other means of getting a restricted IP port opened, ie doesnt understand ipfw). Anyway, even if the process runs as root, it fails when calling ioctl(fd, TIOCEXCL). It could however still open the port to listen for RING events. I.e. a fax server which needs to see incoming calls but otherwise doesnt want to block the port. So the only case where the proposed mechanism fails is, if an incorrectly implemented process running as root conflicts with a user process. I think this can be accepted. Regards, Joachim PS: If this patch is generally accepted, the installer and Mac doku should obviously be changed as well. Index: SerialImp.c =================================================================== RCS file: /usr/local/cvsroot/rxtx-devel/src/SerialImp.c,v retrieving revision 1.46.2.187 diff -u -r1.46.2.187 SerialImp.c --- SerialImp.c 29 Jan 2006 22:19:04 -0000 1.46.2.187 +++ SerialImp.c 21 Mar 2006 12:59:16 -0000 @@ -656,6 +656,25 @@ fd=OPEN (filename, O_RDWR | O_NOCTTY | O_NONBLOCK ); } while (fd < 0 && errno==EINTR); +#ifdef OPEN_EXCL + // Note that open() follows POSIX semantics: multiple open() calls to + // the same file will succeed unless the TIOCEXCL ioctl is issued. + // This will prevent additional opens except by root-owned processes. + // See tty(4) ("man 4 tty") and ioctl(2) ("man 2 ioctl") for details. + + if (fd >= 0 && (ioctl(fd, TIOCEXCL) == -1)) + { + sprintf( message, "open: exclusive access denied for % s\n", + filename ); + report( message ); + report_error( message ); + + close(fd); + goto fail; + } +#endif /* OPEN_EXCL */ + + if( configure_port( fd ) ) goto fail; (*env)->ReleaseStringUTFChars( env, jstr, filename ); sprintf( message, "open: fd returned is %i\n", fd ); Index: SerialImp.h =================================================================== RCS file: /usr/local/cvsroot/rxtx-devel/src/SerialImp.h,v retrieving revision 1.11.2.49 diff -u -r1.11.2.49 SerialImp.h --- SerialImp.h 5 Jul 2005 17:47:21 -0000 1.11.2.49 +++ SerialImp.h 21 Mar 2006 12:59:17 -0000 @@ -135,7 +135,8 @@ /*# define LOCKDIR "/var/spool/uucp"*/ # define LOCKDIR "/var/lock" # define LOCKFILEPREFIX "LK." -# define UUCP +/*# define UUCP*/ +# define OPEN_EXCL #endif /* __APPLE__ */ #if defined(__NetBSD__) # define DEVICEDIR "/dev/" From tjarvi at qbang.org Tue Mar 21 10:26:08 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 21 Mar 2006 10:26:08 -0700 (MST) Subject: [Rxtx] Javadoc on the go In-Reply-To: <441FA98B.9050701@ngi.it> References: <441FA98B.9050701@ngi.it> Message-ID: On Tue, 21 Mar 2006, Fabio Frumento wrote: > Hi Trent, > > sorry for the big delay but my job is running wild, i was out for some > time but now i'm back and ready to continue the javadoc for Rxtx. > > Did you used the last javadoc patch i sent you ? let me know if i have to > send it to you again or not. > > regards > > Fabio Hi Fabio The patch is in the rxtx mail-list archives. It will be going in soon. I did not see a time critical portion. I'll probably be going through the list since the last batch of patches this weekend and putting them into CVS. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Tue Mar 21 10:57:18 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 21 Mar 2006 10:57:18 -0700 (MST) Subject: [Rxtx] jvm issue In-Reply-To: <20060321065524.94779.qmail@web50701.mail.yahoo.com> References: <20060321065524.94779.qmail@web50701.mail.yahoo.com> Message-ID: On Mon, 20 Mar 2006, Lambok Sianturi wrote: > Hi All, > This is my first time to join RxTx mailing list. I thank you all for allowing others to sign in in requests help. > I use the latest RxTx lib in Fedora 3 with java version 1.4.2_09 b05. And I got this error: > > # > # An unexpected error has been detected by HotSpot Virtual Machine: > # > # SIGSEGV (0xb) at pc=0x00bf27f3, pid=2633, tid=3086112448 > # > # Java VM: Java HotSpot(TM) Client VM (1.4.2_09-b05 mixed mode) > # Problematic frame: > # C [ld-linux.so.2+0xa7f3] A native library loading error? What happens if you recompile rxtx on your system and install that? This sounds like an ABI problem? rxtx 2.1-7 was compiled with a gcc 2.96 toolchain as I recall. The hope is newer system will be backwards compatible. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Tue Mar 21 11:05:29 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 21 Mar 2006 11:05:29 -0700 (MST) Subject: [Rxtx] PATCH: use of ioctl(fd, TIOCEXCL) instead of lockfiles In-Reply-To: <923AE774-EEA2-4911-92D8-32BB27802C8B@buechse.de> References: <923AE774-EEA2-4911-92D8-32BB27802C8B@buechse.de> Message-ID: On Tue, 21 Mar 2006, Joachim Buechse wrote: > Here is the patch for the ioctl(fd, TIOCEXCL). I have verified this only > for OSX 10.4.5, hence it is only defined for APPLE. However, it should > work at least for Solaris as well. > > If a process has requested TIOEXCL further open calls by other user > processes will fail. > > The patch also disables uucp style locking for APPLE. Obviously this is > discussable. I think it is the way to go, as it eliminates creating the > lock directory which doesnt exist on the standard installation and it > eliminates messing with the system group definitions (adding users to > group uucp). > > Regarding the possibility of root processes opening a device which is > locked - I consider this a feature not a potential problem. It is highly > unlikely, that somebody is crazy enough to run a JavaVM as root (unless > he has no other means of getting a restricted IP port opened, ie doesnt > understand ipfw). Anyway, even if the process runs as root, it fails when > calling ioctl(fd, TIOCEXCL). It could however still open the port to > listen for RING events. I.e. a fax server which needs to see incoming > calls but otherwise doesnt want to block the port. So the only case where > the proposed mechanism fails is, if an incorrectly implemented process > running as root conflicts with a user process. I think this can be > accepted. > > Regards, > Joachim > > PS: If this patch is generally accepted, the installer and Mac doku > should obviously be changed as well. > > > Index: SerialImp.c > =================================================================== > RCS file: /usr/local/cvsroot/rxtx-devel/src/SerialImp.c,v > retrieving revision 1.46.2.187 > diff -u -r1.46.2.187 SerialImp.c > --- SerialImp.c 29 Jan 2006 22:19:04 -0000 1.46.2.187 > +++ SerialImp.c 21 Mar 2006 12:59:16 -0000 > @@ -656,6 +656,25 @@ > fd=OPEN (filename, O_RDWR | O_NOCTTY | O_NONBLOCK ); > } while (fd < 0 && errno==EINTR); > > +#ifdef OPEN_EXCL > + // Note that open() follows POSIX semantics: multiple open() > calls to > + // the same file will succeed unless the TIOCEXCL ioctl is > issued. > + // This will prevent additional opens except by root-owned > processes. > + // See tty(4) ("man 4 tty") and ioctl(2) ("man 2 ioctl") for > details. > + > + if (fd >= 0 && (ioctl(fd, TIOCEXCL) == -1)) > + { > + sprintf( message, "open: exclusive access denied for % > s\n", > + filename ); > + report( message ); > + report_error( message ); > + > + close(fd); > + goto fail; > + } > +#endif /* OPEN_EXCL */ > + > + > if( configure_port( fd ) ) goto fail; > (*env)->ReleaseStringUTFChars( env, jstr, filename ); > sprintf( message, "open: fd returned is %i\n", fd ); > Index: SerialImp.h > =================================================================== > RCS file: /usr/local/cvsroot/rxtx-devel/src/SerialImp.h,v > retrieving revision 1.11.2.49 > diff -u -r1.11.2.49 SerialImp.h > --- SerialImp.h 5 Jul 2005 17:47:21 -0000 1.11.2.49 > +++ SerialImp.h 21 Mar 2006 12:59:17 -0000 > @@ -135,7 +135,8 @@ > /*# define LOCKDIR "/var/spool/uucp"*/ > # define LOCKDIR "/var/lock" > # define LOCKFILEPREFIX "LK." > -# define UUCP > +/*# define UUCP*/ > +# define OPEN_EXCL > #endif /* __APPLE__ */ > #if defined(__NetBSD__) > # define DEVICEDIR "/dev/" > This looks like a good start. What do you think Dmitry? Perhaps all systems with TIOCEXCL defined should use that though. Even if they use lockfiles. It wont hurt anything. That would catch people hacking their own serial apps without checking lockfiles. Its a good idea to avoid C++ style comments in the C portions. Some older systems don't deal with them well. If it's just for Mac OS X, it isn't a big deal. I think it was the Irix compiler that was problematic? -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Tue Mar 21 11:22:05 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 21 Mar 2006 11:22:05 -0700 (MST) Subject: [Rxtx] lock files In-Reply-To: <8E12916A-1B9A-4FF2-B684-E2D1C794221B@buechse.de> References: <8E12916A-1B9A-4FF2-B684-E2D1C794221B@buechse.de> Message-ID: We can try it. Maybe the JNI is much improved. The nice thing about linking into liblock is distros then worry about lockfiles on their systems. This way, we have to deal with any changes that may show up. On Tue, 21 Mar 2006, Joachim Buechse wrote: > This is pretty much what I thought about when I suggested, that the > default behaviour could be overwritten with a property. I am very much in > favor of this approach. In particular this allows much easier debugging > for PC based java developers. > > I think big parts of the Java (and maybe some parts of the C code) could > use a bit of a structural workover (unit tests, javadoc, synchronization, > etc). Maybe there should be a CVS branch for this experimental version. > I'd be happy to contribute a first workover for some of the Java code. > Designing for testability and implementing a good bunch of unit tests has > been a strategy that worked quite well in the Java projects I lead. And > it ultimately allows more liberal change permission. > > Regards, > Joachim > > > On 21.03.2006, at 08:51, Dr. Douglas Lyon wrote: > >> Hi All, >> You know, if the use of lock files were >> under Java control (rather than a build-time decision), >> it might enable a more unified binary distro. It might also >> facilitate quick prototyping of non-lock file approaches >> to resolving serial port contention issues (i.e., mac-like >> approaches vs. linux approaches, etc.). >> >> I realize that this is a radical overhaul of the lock file policy >> issue. Also, it may harm performance. On the other hand, >> our benchmarks on JNI overhead for modern processors indicate >> performance impact should be minimal. Perhaps it is more of >> an issue with the toybox systems. >> >> Suppose there were a class with a reasonable default...someone >> might write: >> SerialPortLockPolicy.setPolicy(SerialPortLockPolicy.UNIX_LOCK_FILE); >> SerialPortLockPolicy.setPolicy(SerialPortLockPolicy.NO_LOCK_CHECKING); >> SerialPortLockPolicy.setPolicy(SerialPortLockPolicy.MAC_STYLE); >> >> Thus, we could have a run-time reconfiguration of the serial port lock >> policy. A special NO_LOCK version of the binary would no longer >> be required. >> >> Any thoughts on this? >> >> Thanks! >> - Doug >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From dmarkman at mac.com Tue Mar 21 16:05:17 2006 From: dmarkman at mac.com (Dmitry Markman) Date: Tue, 21 Mar 2006 18:05:17 -0500 Subject: [Rxtx] PATCH: use of ioctl(fd, TIOCEXCL) instead of lockfiles In-Reply-To: References: <923AE774-EEA2-4911-92D8-32BB27802C8B@buechse.de> Message-ID: <512AC70C-BB86-48F2-A83C-023F35C23BAB@mac.com> I think it's cool, but I'd like to have that property implementation when user can choose between locking mechanism about comments: it's easy to change comments to the C style or we can use extensions of the file to cpp so c++ compiler will be used On Mar 21, 2006, at 1:05 PM, Trent Jarvi wrote: > This looks like a good start. What do you think Dmitry? Perhaps > all systems with TIOCEXCL defined should use that though. Even if > they use lockfiles. It wont hurt anything. That would catch > people hacking their own serial apps without checking lockfiles. > > Its a good idea to avoid C++ style comments in the C portions. > Some older systems don't deal with them well. If it's just for Mac > OS X, it isn't a big deal. I think it was the Irix compiler that > was problematic? Dmitry Markman From dmarkman at mac.com Tue Mar 21 16:13:00 2006 From: dmarkman at mac.com (Dmitry Markman) Date: Tue, 21 Mar 2006 18:13:00 -0500 Subject: [Rxtx] PATCH: use of ioctl(fd, TIOCEXCL) instead of lockfiles In-Reply-To: References: <923AE774-EEA2-4911-92D8-32BB27802C8B@buechse.de> Message-ID: I'd like to add that creating locking folder isn't a big deal we never had a problem related to the lock folders, because we always used installer on mac os x from other hand I'm not very much familiar with iotcl locking approach and I'm not sure it's more efficient Joachim wrote "I think it is the way to go, as it eliminates creating the lock directory which doesnt exist on the standard installation and it eliminates messing with the system group definitions (adding users to group uucp)." but I really didn't have any problem with that 1. doesn't exist on the standard installation there are many-many things that don't exist in the standard installation so I don't think that argument is strong enough 2. messing with the system group definitions I don't think we're messing with the group definition mac os x provides very clear way to set up group's members and together with Greg Guerin AuthKit there is no problem to set those definitions so I don't think that argument is strong either but from other hand using iotcl is more promising and is more elegant On Mar 21, 2006, at 1:05 PM, Trent Jarvi wrote: > > This looks like a good start. What do you think Dmitry? Perhaps > all systems with TIOCEXCL defined should use that though. Even if > they use lockfiles. It wont hurt anything. That would catch > people hacking their own serial apps without checking lockfiles. Dmitry Markman From joachim at buechse.de Wed Mar 22 04:46:45 2006 From: joachim at buechse.de (Joachim Buechse) Date: Wed, 22 Mar 2006 12:46:45 +0100 Subject: [Rxtx] PATCH: use of ioctl(fd, TIOCEXCL) instead of lockfiles In-Reply-To: References: <923AE774-EEA2-4911-92D8-32BB27802C8B@buechse.de> Message-ID: Sorry, I was not very clear with my arguments, so I will try again;-) Please, don't take this as an attack against work that has been done. I think the contributions that have been made in the past were made in a good spirit. But I really believe, that the current solution for OSX has many shortcomings and should be changed as soon as possible. lock files --- The /var/lock folder does not exist on the standard OSX installation, however the standard installation includes several applications that use serial ports (i.e. the FAX capability). This indicates, that the lock folder approach will not work well with system components. Applications for OSX will generally try to live in harmony with system components (except for HP print drivers of course). I think RXTX should follow this approach as well. uucp group --- Accessing serial ports is not an admin privileged operation on OSX. Any user (world) has read/write privileges on /dev/tty*. So the system default is to not enforce any group membership to access these ports. The group uucp however is a system group on all unix systems I know. It exists for certain system processes. A non admin user should in general not be a member of this group. Quite arguably no user should ever be a member of this group. Installer --- My general opinion is, that - no Installer should touch user or group data without warning - no Application Installer should touch groups which are not specific to the very application installed - no Installer should ever add regular users to a system group The current installer injects the installing user in the group uucp without warning about this change and without giving the option to "opt out" of this change. This is a potential security risk (but not currently a real one, as OSX contains no folders belonging to group uucp). The current installer does not work for multi user systems. It puts the installing user in the uucp group. However the installing user is not necessarily the user that will use the application. Putting all users that may use a serial port application in the system group uucp seems like a very invasive approach to me. Besides that, newly created users will not automatically be in the group and hence, serial applications will "break" for new users without obvious reasons. Avoiding the lock files will allow self contained applications (i.e. drag&drop installation). In my eyes this is largely preferable over an installer that requests admin privileges. Adding up all these points indicates very strongly, that the lock-file implementation is not the way to go on OSX. Regards, Joachim On 22.03.2006, at 00:13, Dmitry Markman wrote: > I'd like to add that > > creating locking folder isn't a big deal > we never had a problem related to the lock folders, because we > always used installer on mac os x > from other hand I'm not very much familiar with iotcl locking > approach and I'm not sure it's more efficient > > Joachim wrote "I think it is the way to go, as it eliminates > creating the lock directory which doesnt exist on the standard > installation and it eliminates messing with the system group > definitions (adding users to group uucp)." but I really didn't have > any problem with that > > 1. doesn't exist on the standard installation > there are many-many things that don't exist in the standard > installation so I don't think that argument is strong enough > 2. messing with the system group definitions > I don't think we're messing with the group definition > mac os x provides very clear way to set up group's members and > together with Greg Guerin AuthKit there is no problem to set those > definitions > so I don't think that argument is strong either > but from other hand using iotcl is more promising and is more elegant > > > > On Mar 21, 2006, at 1:05 PM, Trent Jarvi wrote: > >> >> This looks like a good start. What do you think Dmitry? Perhaps >> all systems with TIOCEXCL defined should use that though. Even if >> they use lockfiles. It wont hurt anything. That would catch >> people hacking their own serial apps without checking lockfiles. > > Dmitry Markman > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From dmarkman at mac.com Wed Mar 22 05:27:13 2006 From: dmarkman at mac.com (Dmitry Markman) Date: Wed, 22 Mar 2006 07:27:13 -0500 Subject: [Rxtx] PATCH: use of ioctl(fd, TIOCEXCL) instead of lockfiles In-Reply-To: References: <923AE774-EEA2-4911-92D8-32BB27802C8B@buechse.de> Message-ID: <83440CF3-DCD8-41C1-B941-F227232C27E3@mac.com> thanks for the very good explanation I didn't think that you were attacking any thing, so don't worry I just had feeling, that there were more aesthetic reasons for going to ioctl then real necessity now you explained everything quite well (BTW, asfar as I remember installer asks admin password so it wasn't quiet, but it really doesn't matter now) thanks On Mar 22, 2006, at 6:46 AM, Joachim Buechse wrote: > Sorry, I was not very clear with my arguments, so I will try again;-) > > Please, don't take this as an attack against work that has been > done. I think the contributions that have been made in the past > were made in a good spirit. But I really believe, that the current > solution for OSX has many shortcomings and should be changed as > soon as possible. > > lock files > --- > The /var/lock folder does not exist on the standard OSX > installation, however the standard installation includes several > applications that use serial ports (i.e. the FAX capability). This > indicates, that the lock folder approach will not work well with > system components. Applications for OSX will generally try to live > in harmony with system components (except for HP print drivers of > course). I think RXTX should follow this approach as well. > > uucp group > --- > Accessing serial ports is not an admin privileged operation on OSX. > Any user (world) has read/write privileges on /dev/tty*. So the > system default is to not enforce any group membership to access > these ports. The group uucp however is a system group on all unix > systems I know. It exists for certain system processes. A non admin > user should in general not be a member of this group. Quite > arguably no user should ever be a member of this group. > > Installer > --- > My general opinion is, that > - no Installer should touch user or group data without warning > - no Application Installer should touch groups which are not > specific to the very application installed > - no Installer should ever add regular users to a system group > > The current installer injects the installing user in the group uucp > without warning about this change and without giving the option to > "opt out" of this change. This is a potential security risk (but > not currently a real one, as OSX contains no folders belonging to > group uucp). > > The current installer does not work for multi user systems. It puts > the installing user in the uucp group. However the installing user > is not necessarily the user that will use the application. Putting > all users that may use a serial port application in the system > group uucp seems like a very invasive approach to me. Besides that, > newly created users will not automatically be in the group and > hence, serial applications will "break" for new users without > obvious reasons. > > > Avoiding the lock files will allow self contained applications > (i.e. drag&drop installation). In my eyes this is largely > preferable over an installer that requests admin privileges. Adding > up all these points indicates very strongly, that the lock-file > implementation is not the way to go on OSX. > > Regards, > Joachim > > > On 22.03.2006, at 00:13, Dmitry Markman wrote: > >> I'd like to add that >> >> creating locking folder isn't a big deal >> we never had a problem related to the lock folders, because we >> always used installer on mac os x >> from other hand I'm not very much familiar with iotcl locking >> approach and I'm not sure it's more efficient >> >> Joachim wrote "I think it is the way to go, as it eliminates >> creating the lock directory which doesnt exist on the standard >> installation and it eliminates messing with the system group >> definitions (adding users to group uucp)." but I really didn't >> have any problem with that >> >> 1. doesn't exist on the standard installation >> there are many-many things that don't exist in the standard >> installation so I don't think that argument is strong enough >> 2. messing with the system group definitions >> I don't think we're messing with the group definition >> mac os x provides very clear way to set up group's members and >> together with Greg Guerin AuthKit there is no problem to set those >> definitions >> so I don't think that argument is strong either >> but from other hand using iotcl is more promising and is more elegant >> >> >> >> On Mar 21, 2006, at 1:05 PM, Trent Jarvi wrote: >> >>> >>> This looks like a good start. What do you think Dmitry? Perhaps >>> all systems with TIOCEXCL defined should use that though. Even >>> if they use lockfiles. It wont hurt anything. That would catch >>> people hacking their own serial apps without checking lockfiles. >> >> Dmitry Markman >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx Dmitry Markman From lyon at docjava.com Wed Mar 22 06:12:18 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Wed, 22 Mar 2006 08:12:18 -0500 Subject: [Rxtx] sole of a new design pattern Message-ID: Hi All, I have been thinking about how we design the serial port software. I think we need a new design pattern. For lack of a better term, I shall call it: The Parametric Singleton Design Pattern By Douglas A. Lyon ABSTRACT The goal of the singleton design pattern is to make sure that there is one, and only one, instance of a given class. The goal of the parametric singleton design pattern is to make sure that there is one, and only one, instance of a given class with the given parametric values. We parametric singleton design pattern combines the singleton design pattern with a parameter that enables unique creation of instances of a class. These instances are cached. When a user asks for an instance with these parameters, the cache is checked. If the instance is in the cache, the instance is returned, otherwise it is created, added to the cache and then returned. We apply our parametric singleton design pattern to the retrieval of RMI registries bound to a given port. The goal of our system is to make sure that no two RMI registries are listening to the same socket and to make use of the RMI registries after they have been created. RMI registries are used in distributed computation. Introduction The singleton design pattern is meant to ensure that on a single instance of a class exists. It is also meant to provide a global point of access to it. The intent of the parametric singleton design pattern is to ensure that a class has only one instance for a given set of parameter values. It also provides a global point of access to it. Motivation A system cannot tolerate multiple instances of some classes with identical parameters. For example, you cannot have two instances making use of the same serial port, at the same time. You cannot have two instances that are trying to listen to the same socket connection. You cannot have two instances writing to the same file structure at the same time. As the operating system is often thought of as the arbiter of consumed resources (i.e., tape drives, serial ports, etc.) we frequently leave it to an operating system implementation to resolve these contention issues. Even for similar resources (like serial ports) there are few standards for handling contention. For example, serial ports on Linux are locked using a "/var/lock" file. POSIX, on the other hand, uses ioctl mechanisms to prevent contention. A better solution is to make a class that is responsible for keeping track of the instances created from the class. The class is declared final, so that it cannot be subclassed. The class also has a private constructor, so that other classes cannot instance it. The new design pattern is called the parametric singleton design pattern and it provides a way to access and create instances with given parameters. Applicability Use the Parametric Singleton Design Pattern when: 1. There must be exactly one instance of a class with the given parameters. 2. The instances must be accessible to clients from a well-known access point. Structure Insert UML diagram here. Participants The Parametric Singleton Clients that need instances 1. The Parametric Singleton defines an instance upon request from a client, if, and only if, the instance does not already exist. 2. The Parametric Singleton returns the instance to the client. 3. The Parametric Singleton is responsible for creating unique instances from given parameters. Collaborations Clients obtain a reference to a Parametric Singleton instance only through the parametric singleton design pattern. If the instance is left in an improper state (e.g., the serial port was left open) it is NOT the role of the Parametric Singleton Design Pattern to close the IO port. Nor is it the role of the Parametric Singleton Design Pattern to open the port. That role is delegate to some other part of the system. Further, it is not the role of the Parametric Singleton Design Pattern to check out resources. That is, multiple threads can have multiple references to the same resource at the same time. MUTEX locking is delegated to some other part of the system. Consequences The Parametric Singleton Design Pattern has several benefits: 1. Controlled access to parametrically defined instances. Since the Parametric Singleton class encapsulates its instances, there is control over how and when clients access it. 2. Reduced name space. The Parametric Singleton pattern avoids global variables that store instances created from the same parameter. Implementation Here are implementation issues to consider when using the Parametric Singleton pattern: 1. Unique mapping of parameters. The Parametric Singleton pattern requires that there be a mean to isomorphically map the parameter space into the instance space and back again. 2. Ensure unique instances. The Parametric Singleton pattern makes unique instances from parameters, and it does so only once. 3. Cache instances for fast retrieval. The Parametric Singleton pattern must be able to look up instances, given some set of parameters, and do so from some data structure. That is, there must be enough space to hold references to all the instances the program will need. Also, a mechanism is needed to look up and retrieve the instances quickly enough to satisfy the clients. Sample Code public final class ParametricSingletonRmiRegistry { private static Hashtable registry = new Hashtable(100); // use singleton pattern and??????????????????????????????????????????????? // prevent instantiation of RmiRegistryUtils.?????????????????????????????? private ParametricSingletonRmiRegistry() { } // the only instance of the Registry held by the RmiRegistryUtils?????????? public static void listNames(Integer port) { if (!isInCacheAndRunning(port)) return; Registry r = (Registry) registry.get(port); System.out.println("registry on port: " + port); System.out.println("registry: " + r); System.out.println("names: "); try { print(r.list()); } catch (RemoteException e) { In.message(e); } System.out.println("------------------------"); } /**???????????????????????????????????????????????????????????????????????? * Checks whether a Registry has been started on this host????????????????? * in the specified port.?????????????????????????????????????????????????? * If not, it tries to start one.?????????????????????????????????????????? * when it fails to start a Registry, it exits the program????????????????? * with exit code 1.??????????????????????????????????????????????????????? */ public static void restart(int port) { if (isInCacheAndRunning(port)) return; try { startRegistry(port); } catch (RemoteException e) { In.message(e); } } /**???????????????????????????????????????????????????????????????????????? * @param port????????????????????????????????????????????????????????????? * @return true if registry is in cache and running???????????????????????? */ private static boolean isInCacheAndRunning(Integer port) { if (!isRegistryRunning(port.intValue())) return false; if (!isRegistryInCache(port.intValue())) return false; return true; } /**???????????????????????????????????????????????????????????????????????? * @param port????????????????????????????????????????????????????????????? * @return true if we are able to locate a local registry on port.??????????????????????????????????????????????????????????????????????????? */ private static boolean isRegistryRunning(int port) { try { Registry r = LocateRegistry.getRegistry(port); if (r != null) return true; } catch (RemoteException e) { return false; } return false; } /**???????????????????????????????????????????????????????????????????????? * @param port????????????????????????????????????????????????????????????? * @return return true if registry is in cache????????????????????????????? */ private static boolean isRegistryInCache(int port) { if (registry.get(new Integer(port)) == null) return false; return true; } /**???????????????????????????????????????????????????????????????????????? * Restart the registry, if needed.???????????????????????????????????????? * Return the only instance of the registry for consistent global?????????? * using by making use of the Singleton Design Pattern????????????????????? *????????????????????????????????????????????????????????????????????????? * @return the internally held registry instance.?????????????????????????? */ public static Registry getRegistry(Integer port) { restart(port); return (Registry) registry.get(port); } private static void startRegistry(Integer port) throws RemoteException { Registry r; try { r = LocateRegistry.createRegistry(port.intValue()); registry.put(port, r); //r = new sun.rmi.registry.RegistryImpl???????????????????????????? /// (port.intValue());?????????????????????????????????????? // registry.put(port, r);?????????????????????????????????????????? } catch (Exception e) { //e.printStackTrace();????????????????????????????????????????????? r = LocateRegistry.getRegistry(port.intValue()); registry.put(port, r); } } public static void main(String args[]) throws RemoteException { //restart(port);??????????????????????????????????????????????????????? restart(5001); restart(5002); restart(5002); Registry r = LocateRegistry.getRegistry(5002); System.out.println("registry="+r); } } I would very much like to get your feedback on this new design pattern idea. Thank you for your time. Regards, - Doug From david.garnier at trusted-logic.com Wed Mar 22 07:36:10 2006 From: david.garnier at trusted-logic.com (David Garnier) Date: Wed, 22 Mar 2006 15:36:10 +0100 Subject: [Rxtx] sole of a new design pattern In-Reply-To: References: Message-ID: <442160DA.80107@trusted-logic.com> Hello, > The Parametric Singleton Design Pattern The Singleton is the most abused design pattern ever. Good use-cases for this pattern are extremely rare and mostly confined to problems related to hardware resources, like serial ports. > Applicability > > Use the Parametric Singleton Design Pattern when: > 1. There must be exactly one instance of a class with the given > parameters. OK. As I said above, this case this actually very unusual. The Singleton pattern is mostly used when : > 2. The instances must be accessible to clients from a well-known > access point. Using the singleton pattern in this case is just convenient for the programmer. Problems arises pretty quickly, especially if you attempt to unit-test your classes. 1) If your singleton is stateful, or hold on to stateful objects, it means that two different unit tests are not actually independent. Instead of starting with a brand new environment, the result of a test may be affected by the result of a previous test. This problem also arise when with your class relies on a database. In both cases, the solution is to reset your "unique" resource (Singleton or database) at the beginning of the test, which is a pain. Also, while most projects connect to a single database, projects that allow the use of Singletons usually contain several of thems, and new ones may cropped up unnoticed. You quickly end up with test cases that only pass in a certain order, which is a royal pain. 2) You cannot mockup a singleton. Once everyone calls the SomeSingleton class statically, you can't replace your class by SomeSingletonMockup. Furthermore, even for hardware services, the Singleton pattern does not really prevent concurrent accesses. If you start the same program in two different JVMs, unless they somehow shared the state of their "Singletons" (through lock files for example), the Singleton pattern will not prevent concurrent access. Our application uses RXTX, and we routinely encounter cases where another (native) application has already locked the port. Since we cannot modify the native application to recognize lock files, OS-level control is irreplaceable. > > Consequences > The Parametric Singleton Design Pattern has several benefits: > > 1. Controlled access to parametrically defined instances. Since > the Parametric Singleton class encapsulates its instances, there is > control over how and when clients access it. Not really. Once you've returned the instance to a client, you've lost control over it. The client can to whatever it wants with it. You cannot "recall" the instance or claim it back. > 2. Reduced name space. The Parametric Singleton pattern avoids > global variables that store instances created from the same parameter. Sure, but you don't have to rely on a Singleton for that. Just create a single Factory. > I would very much like to get your feedback on this new design > pattern idea. Well, it's nothing new. Some may say that it is the point of design patterns: formalizes the designs that occur again and again. However, this design is simply a combination of the Singleton and Factory patterns. I did use it in the past, but now I've been exposed to the shortcomings of the Singleton pattern, so I limit myself to Factories. Regards, David From sean_montgomery at baseview.com Wed Mar 22 08:35:28 2006 From: sean_montgomery at baseview.com (Sean Montgomery) Date: Wed, 22 Mar 2006 10:35:28 -0500 Subject: [Rxtx] sole of a new design pattern In-Reply-To: <442160DA.80107@trusted-logic.com> References: <442160DA.80107@trusted-logic.com> Message-ID: <05769CA7-A51B-4CF0-BAA0-E02DD905F5A4@baseview.com> On Mar 22, 2006, at 9:36 AM, David Garnier wrote: > Furthermore, even for hardware services, the Singleton pattern does > not really prevent concurrent > accesses. If you start the same program in two different JVMs, > unless they somehow shared the state > of their "Singletons" (through lock files for example), the > Singleton pattern will not prevent > concurrent access. > Multiple class loaders in a single JVM can be tricky, too. Then there's synchronization, lazy initialization and serialization of singletons to contend with. Bloch's Effective Java covers these, and here's a few articles: http://www.javaworld.com/javaworld/jw-04-2003/jw-0425-designpatterns- p3.html http://java.sun.com/developer/technicalArticles/Programming/singletons/ Just FYI :-) From lyon at docjava.com Wed Mar 22 08:50:48 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Wed, 22 Mar 2006 10:50:48 -0500 Subject: [Rxtx] sole of a new design pattern In-Reply-To: <442160DA.80107@trusted-logic.com> References: <442160DA.80107@trusted-logic.com> Message-ID: Hi All, First, I would like to thank David for his prompt and thoughtful remarks. I had no idea people that feel strongly about a design patterns! Wow! Feedback (particularly critical feedback) is greatly appreciated. Starting at the end, first: >I did use it in >the past, but now I've been exposed to the shortcomings of the >Singleton pattern, so I limit myself to Factories. David, if I understood your comments correctly, you suggested that Factories can be used in leu of the Singleton Design Pattern, or even the Parametric Singleton Design Pattern. As I see in [Gof]: Factory Method: Intent "Define an interface for creating an object, but let subclasses decide which class to instantiate. Factory Method lets a class defer instantiation to subclasses." The Singleton Design Pattern is a concrete class, which is rather different, right? Also, subclasses are not permitted with Singleton, as they are final. Naturally, I could use an abstract factory as a parent for a singleton. I could even design a facade that could be implemented with the singleton....but that is not the intention of the design. Unless you want a mock-up, as discussed, below: More below: >Hello, > >> The Parametric Singleton Design Pattern > >The Singleton is the most abused design pattern ever. Good use-cases >for this pattern are extremely >rare and mostly confined to problems related to hardware resources, >like serial ports. > > >> Applicability >> >> Use the Parametric Singleton Design Pattern when: >> 1. There must be exactly one instance of a class with the given >> parameters. >OK. As I said above, this case this actually very unusual. The >Singleton pattern is mostly used when : >> 2. The instances must be accessible to clients from a well-known >> access point. > >Using the singleton pattern in this case is just convenient for the >programmer. Problems arises >pretty quickly, especially if you attempt to unit-test your classes. > >1) If your singleton is stateful, or hold on to stateful objects, it >means that two different unit >tests are not actually independent. Instead of starting with a brand >new environment, the result of >a test may be affected by the result of a previous test. This >problem also arise when with your >class relies on a database. In both cases, the solution is to reset >your "unique" resource >(Singleton or database) at the beginning of the test, which is a >pain. Also, while most projects >connect to a single database, projects that allow the use of >Singletons usually contain several of >thems, and new ones may cropped up unnoticed. You quickly end up >with test cases that only pass in a >certain order, which is a royal pain. There are basic problems with communicating finite state machines that include reachability and deadlock analysis. These are addressed with petri net analysis and are beyond the scope of the design pattern. As you quite rightly pointed out; the parametric singleton pattern (or the singleton pattern, for that matter) enable multiple threads to gain access to the same instance. The only way that I can see to block others from gaining access to the reference is the synchronize keyword. This is putting a spin-lock (or MUTEX) on the reference. The question of how to unit-test a design pattern like the parametric singleton remains open. Perhaps this is a deficiency. > >2) You cannot mockup a singleton. Once everyone calls the >SomeSingleton class statically, you can't >replace your class by SomeSingletonMockup. Acutally, I am not sure that this is true. If the Singleton implements a Facade interface, it should be possible to make the replacement. Right? > >Furthermore, even for hardware services, the Singleton pattern does >not really prevent concurrent >accesses. If you start the same program in two different JVMs, >unless they somehow shared the state >of their "Singletons" (through lock files for example), the >Singleton pattern will not prevent >concurrent access. Good Point!! You have sharp eyes! The singleton design pattern should/could take responsibility for this. In fact, you may notice that my code does have an implementation (LocateRegistry) that can work across JVM's. The LocateRegistry will even work across the Internet! LocateRegistry takes both a host name and a Port (lock files just don't do this). I did not think to implement this beyond the local machine, but, in its present form, it will work across different processes. > >Our application uses RXTX, and we routinely encounter cases where >another (native) application has >already locked the port. Since we cannot modify the native >application to recognize lock files, >OS-level control is irreplaceable. The singleton design pattern is not meant to replace OS-level control, but to centralize the Java programmers access to it. If lock files, for example, are used for serial ports, the Singleton Design Pattern should be able to work with them. > > >> >> Consequences >> The Parametric Singleton Design Pattern has several benefits: >> > > 1. Controlled access to parametrically defined instances. Since >> the Parametric Singleton class encapsulates its instances, there is >> control over how and when clients access it. > >Not really. Once you've returned the instance to a client, you've >lost control over it. The client >can to whatever it wants with it. You cannot "recall" the instance >or claim it back. Good point, this should read: > 1. Controll when parametrically defined instances are created. Since > > the Parametric Singleton class encapsulates its instances, there is > > control over how and when they are instanced. > >> 2. Reduced name space. The Parametric Singleton pattern avoids >> global variables that store instances created from the same parameter. > >Sure, but you don't have to rely on a Singleton for that. Just >create a single Factory. > > Thank you for your thoughtful and prompt response! Regards, - Doug From dmarkman at mac.com Wed Mar 22 21:21:55 2006 From: dmarkman at mac.com (Dmitry Markman) Date: Wed, 22 Mar 2006 23:21:55 -0500 Subject: [Rxtx] sole of a new design pattern In-Reply-To: <442160DA.80107@trusted-logic.com> References: <442160DA.80107@trusted-logic.com> Message-ID: I don't think I get it On Mar 22, 2006, at 9:36 AM, David Garnier wrote: > Using the singleton pattern in this case is just convenient for the > programmer. Problems arises > pretty quickly, especially if you attempt to unit-test your classes. so you're saying that something isn't so good because you can not test it in the convenient way? if that's true, I'm totally disagree change your test, debug whatever, but if software is efficient at runtime, works fine and only problem is some unit test (which is some kind of framework for testing) then dump that unit test , dump that unit framework and make something appropriate to the software you're testing so if Douglas want to use singletons, what's the problem? and what do you mean by abusing of singleton usage? of course singleton doesn't prevent concurrent access to the resource across the processes unless you're using some OS facility to prevent it, besides singleton as it was introduced is relevant only and only inside of the same process otherwise it's not singleton it's something else (let's say network singleton: so you have remote invocation facility and some factory method that return object created by that facility) I don't have any problem with using any kind of singletons. Parametric Singleton idea (if I understand it right) could be easily implemented in the following way: use a map populate map with instances of some class and key is your parameter (you can use lazy population too) if somebody ask the key check the value if it's null so resource is taken if somebody returns the resource put it back to the map public synchronized static Object getSomeResource(Object parameter); public synchronized static void returnResource(Object parameter); getSomeResource (inside of the same process) could return null in 2 cases 1. if somebody (from other thread for example) already took that resource 2. if OS API said that resource corresponded to that parameter (serial port with parameter = 1 (port #)) is locked and unavailable; I'm not sure that in case of serial ports we even need those Parametric Singletons (unless lock checking is a very expensive operation) just ask the OS about availability of that resource and if it's available give it away and then OS will lock it and therefore in next time somebody ask it just answer that resource is locked and return null for example system has 2 serial ports available so I ask getResource("tty"); or I ask getResource("Bluetooth-Modem"); and if OS is ok you can give tty or Bluetooth-Modem or both no need for any additional pattern I think back to the problem mac os x doesn't recognize locking via files, so it handles locking via some API an instance of the singleton in each process should recognize that resource is locked (by using that API) that's all we don't have to make things more complicate then they are just because there is some nice design pattern or nice unit test framework or whatever keep things simple, make them work fast, don't introduce middle layers unless you have really good reason to do so of course I could be entirely wrong, so sorry about that in advance thanks Dmitry Markman From tjarvi at qbang.org Wed Mar 22 22:31:41 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 22 Mar 2006 22:31:41 -0700 (MST) Subject: [Rxtx] sole of a new design pattern In-Reply-To: References: Message-ID: Hi Doug Interesting reading. So far I'm just reading and thinking. I have one question so far. " Clients obtain a reference to a Parametric Singleton instance only through the parametric singleton design pattern. If the instance is left in an improper state (e.g., the serial port was left open) it is NOT the role of the Parametric Singleton Design Pattern to close the IO port. Nor is it the role of the Parametric Singleton Design Pattern to open the port. That role is delegate to some other part of the system. " So when the clients obtain a reference to the singleton, can they assume the port is there? IE, would it be the singletons role to handle things like USB dongles being removed with event hints comming from the underlying OS. Hardware abstraction layer/HAL on Linux is an example of underlying OS events. I assume that role too is delegated to other parts of the system? -- Trent Jarvi tjarvi at qbang.org From lyon at docjava.com Thu Mar 23 08:10:33 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Thu, 23 Mar 2006 10:10:33 -0500 Subject: [Rxtx] Classes don't need goals, they need roles! In-Reply-To: References: Message-ID: Hi Trent, Yes, I think that the role of the Parametric Singleton Pattern is not to open or close serial ports, nor is it to perform error checking. On the other hand, if you were to combine the role of the Parametric Singleton Pattern with another role (like that of error checking) it might not be amiss. However, I generally caution programmers against adding multiple roles to classes, as this leads to monolithic designs. Thus a different class (NativeLibDetect) could have the role of determining if the native library can be loaded. Another class (SerialPortBean) can have the role of serializing the default state of the serial port, so that it can be recovered, from user preferences, at a later time. The SerialPortDetect could have the role of determining if the serial port is removed (i.e., a USB port was unplugged). My guess is that each class should have a different role in the system, in order to ease maintenance and testing...but I could be wrong about that. Thanks! - Doug >Hi Doug > >Interesting reading. So far I'm just reading and thinking. I have >one question so far. > >" > Clients obtain a reference to a Parametric Singleton instance only >through the parametric singleton design pattern. If the instance is >left in an improper state (e.g., the serial port was left open) it is >NOT the role of the Parametric Singleton Design Pattern to close the >IO port. Nor is it the role of the Parametric Singleton Design Pattern >to >open the port. That role is delegate to some other part of the system. >" > >So when the clients obtain a reference to the singleton, can they >assume the port is there? IE, would it be the singletons role to >handle things like USB dongles being removed with event hints >comming from the underlying OS. Hardware abstraction layer/HAL on >Linux is an example of underlying OS events. > >I assume that role too is delegated to other parts of the system? > >-- >Trent Jarvi >tjarvi at qbang.org >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From maximulo at yahoo.com Fri Mar 24 01:22:38 2006 From: maximulo at yahoo.com (Maximulo Majir) Date: Fri, 24 Mar 2006 00:22:38 -0800 (PST) Subject: [Rxtx] JavaPOS Message-ID: <20060324082238.66371.qmail@web38214.mail.mud.yahoo.com> Hi all! Hello Trent! From what i understand, RXTX or JavaComm APIs were not created solely for JavaPOS. In JavaPOS, we have the virtual method claim() which is separate from open(), but in our RXTX API, claiming is done every call to open(), we cant open the port if its claimed by another application. Would it be alright to suggest or ask to create a new method called claim(..)? Is there such thing as forceclaim() in RXTX? this could be the same as portownership transfer or its equivalent. ForceClaim is in JSR80. Do you have some samples using RXTX as the lower layer for the Device Service Objects in JavaPOS? I have tried it, i just want to compare. Thank you all! maxim __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060324/496adba2/attachment-0041.html From tjarvi at qbang.org Fri Mar 24 11:28:19 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 24 Mar 2006 11:28:19 -0700 (MST) Subject: [Rxtx] Re: RXTX 2.1 Solaris Problems In-Reply-To: <3691.1143210578@www045.gmx.net> References: <3691.1143210578@www045.gmx.net> Message-ID: On Fri, 24 Mar 2006, Andreas Guenther wrote: > Hi all, > > the solaris problem was not the lock file only. > > Ok, I had to create the directory /var/spool/locks myself. > /var/spool/uucp exists. > > But rxtx didn't find any port. > > I compiled the source with my own debug-informations > and I tried to isolate the problem. > > The problem is the testRead-call in SerialImp.c > > JNIEXPORT jboolean JNICALL RXTXCommDriver(testRead)( > > ... > if ( READ( fd, &c, 1 ) < 0 ) > { > if ( errno != EAGAIN ) { > report( "testRead() read failed\n" ); > ret = JNI_FALSE; > } > } > Thanks Andreas I'm packing up to move. I'll be more or less away for a couple weeks here. I'll be checking email but my workstation is going into a box soon. This isn't hard to fix as this port should be enumerated when EWOULDBLOCK is recieved. Thats error is OK for enumeration just as EAGAIN is. I've put the bug into bugzilla so we dont forget to get to it. http://bugzilla.qbang.org/show_bug.cgi?id=42 You can add yourself to the CC list if you wish to test fixes we provide or even put a patch into bugzilla yourself. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Fri Mar 24 11:51:52 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 24 Mar 2006 11:51:52 -0700 (MST) Subject: [Rxtx] JavaPOS In-Reply-To: <20060324082238.66371.qmail@web38214.mail.mud.yahoo.com> References: <20060324082238.66371.qmail@web38214.mail.mud.yahoo.com> Message-ID: On Fri, 24 Mar 2006, Maximulo Majir wrote: > Hi all! Hello Trent! > > > From what i understand, RXTX or JavaComm APIs were not > created solely for JavaPOS. In JavaPOS, we have the virtual method > claim() which is separate from open(), but in our RXTX API, claiming is > done every call to open(), we cant open the port if its claimed by > another application. Would it be alright to suggest or ask to create a > new method called claim(..)? Is there such thing as forceclaim() in > RXTX? this could be the same as portownership transfer or its > equivalent. ForceClaim is in JSR80. > Do you have some samples using RXTX as the lower layer for the Device > Service Objects in JavaPOS? I have tried it, i just want to compare. > maxim Hi Maxim JSR80 is the USB API IBM/Sun put together. The problem is they have a richer kernel/API underneath that can handle such things. With Serial Ports, there isnt anything there other than an ioctl that says don't let anyone touch this and lockfiles that are more of a 'lets be nice.' At times we may be using USB ports but it is through the termios layer with the limitations mentioned. The advantage is that not only USB will work with rxtx. Anything that has a termios layer should work (to the extent that termios layer is complete). I don't know how forceclaim() would help you. Lets say someone has a programmer working on /dev/ttyS0 and you take it. Now you both race each other to read data first. There isn't a mechanism I know of that will solve this problem in termios. The most obvious test being a native app and a Java app trying to take the port. There is the potential of requestion ownership from other Java Applications but the use for that is very rare. Did you have something more specific in mind that I'm missing? I'm not sure that claim() and forceclaim() would help you with rxtx other than maybe locking the port with claim() without opening it. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sat Mar 25 23:42:08 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 25 Mar 2006 23:42:08 -0700 (MST) Subject: [Rxtx] Serial snoop Message-ID: I was reading the Linux kernel mail-list tonight and ran past a thread that mentioned sersnoop. This looks like a handy tool for people dealing with new toys. "a simple command-line tool for linux that echoes bytes to and from any two serial ports, ptys, or network sockets, and prints all traffic to stdout, in hex and ascii." http://www.restivo.org/projects/sersnoop/ It works on Linux only at this time (debian package available). -- Trent Jarvi tjarvi at qbang.org From beat.arnet at gmail.com Sun Mar 26 07:32:35 2006 From: beat.arnet at gmail.com (Beat Arnet) Date: Sun, 26 Mar 2006 09:32:35 -0500 Subject: [Rxtx] Error 0x5 at /home/bob/foo/tar/rxtx-2.1-7/build/../src/termios.c(860): Access is, denied. Message-ID: <4426A603.80508@gmail.com> Dear all, When trying to open the serial port, I sometimes (not always) run into the following exception (when opening the serialPort): Error 0x5 at /home/bob/foo/tar/rxtx-2.1-7/build/../src/termios.c(860): Access is denied. java.lang.UnsatisfiedLinkError: native_psmisc_report_owner at gnu.io.CommPortIdentifier.native_psmisc_report_owner(Native Method) at gnu.io.CommPortIdentifier.open(CommPortIdentifier.java:354) at codeskin.tools.CLLoader.open(CLLoader.java:79) at codeskin.tools.C2000Programmer.run(C2000Programmer.java:220) at java.lang.Thread.run(Unknown Source) Is this the type of error where I should just try to open the port again, or can it be avoided? Regards, Beat From tjarvi at qbang.org Sun Mar 26 11:40:12 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 26 Mar 2006 11:40:12 -0700 (MST) Subject: [Rxtx] Error 0x5 at /home/bob/foo/tar/rxtx-2.1-7/build/../src/termios.c(860): Access is, denied. In-Reply-To: <4426A603.80508@gmail.com> References: <4426A603.80508@gmail.com> Message-ID: On Sun, 26 Mar 2006, Beat Arnet wrote: > Dear all, > > When trying to open the serial port, I sometimes (not always) run into > the following exception (when opening the serialPort): > > Error 0x5 at /home/bob/foo/tar/rxtx-2.1-7/build/../src/termios.c(860): > Access is > denied. > > java.lang.UnsatisfiedLinkError: native_psmisc_report_owner > at gnu.io.CommPortIdentifier.native_psmisc_report_owner(Native > Method) > at gnu.io.CommPortIdentifier.open(CommPortIdentifier.java:354) > at codeskin.tools.CLLoader.open(CLLoader.java:79) > at codeskin.tools.C2000Programmer.run(C2000Programmer.java:220) > at java.lang.Thread.run(Unknown Source) > > Is this the type of error where I should just try to open the port again, > or can it be avoided? > Hi Beat We did a second build of rxtx 2.1-7 to resolve that unsatisfied link error. It should work now. rxtx is trying to tell you it thinks someone else has the serial port open. You can try to open the port again but maybe you already have a copy of the program running when it happens? ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7r2.zip fixed build. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sun Mar 26 11:44:23 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 26 Mar 2006 11:44:23 -0700 (MST) Subject: [Rxtx] RXTX spec file (fwd) Message-ID: This is probably interesting for fedora/suse users. ---------- Forwarded message ---------- Date: Sun, 26 Mar 2006 16:25:45 +0200 To: taj at www.linux.org.uk Subject: RXTX spec file I send you this spec file which allows to create a RPM for Fedora 4, 5 (x86, x86_64) with Java Sun. -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: rxtx.spec Url: http://mailman.qbang.org/pipermail/rxtx/attachments/20060326/6c7b6af6/rxtx-0037.pl From tjarvi at qbang.org Sun Mar 26 23:42:59 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 26 Mar 2006 23:42:59 -0700 (MST) Subject: [Rxtx] Upcomming events. Message-ID: This Wednesday we will be announcing a new "Maintainer" for the rxtx project. The position is more like neutral leader. I wont be going away or doing less. This is just the right thing to do as it turns out the two people with CVS write access will be at the same company. We need a third and we need neutrality. The maintainer will have final say in any conflict and will try to be neutral. It will be open for discussion. Then we will do it :) I'll still do most of the footwork I do now. But. I'm falling behind. I should have gone through the mail-list and posted the next round of changes this weekend. I'm packing to move and its going so so - 13 years of toys collected. I suspect there will be a dead period on my part (a couple weeks) comming up. But if you get it on the mail-list, we will get it in if there are no objections. I may well not be reading the mail-list during this period as I look for a house and many other things. I hope everyone will help out. Thanks -- Trent Jarvi tjarvi at qbang.org From mahmoud_hadad at yahoo.com Sun Mar 26 07:31:19 2006 From: mahmoud_hadad at yahoo.com (ronan nick) Date: Sun, 26 Mar 2006 06:31:19 -0800 (PST) Subject: [Rxtx] a question about the COMM API Message-ID: <20060326143119.54919.qmail@web60014.mail.yahoo.com> hi, i was intrested in knowing how i can communicate with my internal modem using java? for example if i want to make a phone dialer application or a caller id application where should i be looking at? and as i understood the COMM API is for devices that is attached to the computer through serial ports. --------------------------------- New Yahoo! Messenger with Voice. Call regular phones from your PC and save big. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060326/ce8329f0/attachment-0039.html From dmarkman at mac.com Mon Mar 20 00:20:43 2006 From: dmarkman at mac.com (Dmitry Markman) Date: Mon, 20 Mar 2006 02:20:43 -0500 Subject: [Rxtx] Mac OS X RXTX java installer In-Reply-To: References: <07D0DE29-BA32-4CFE-B036-66BC6423D385@buechse.de> <441AE3E0.2030503@willicon.de> <12531986.1142622114996.JavaMail.dmarkman@mac.com> <441B2674.9010409@willicon.de> <13577405.1142634732776.JavaMail.dmarkman@mac.com> <441B4182.8010407@willicon.de> <92CD0D6C-5BE8-426E-A46D-99452059FF49@mac.com> <441BBB2D.8030305@willicon.de> <441C4088.5090905@willicon.de> Message-ID: <64BC1E23-FDDE-4CE6-8863-CFC881CBC224@mac.com> Hi all I put RXTX installer that will install everything (and will create / var/lock if necessary and add user to the uucp group) for mac os x from Java into the rxtx's CVS repository it could be easily modified to install files for any platform it uses Greg Guerin's AuthKit for authentication and authorization Greg released that kit under artistic license, so Trent, please take a look we, probably, can negotiate license with Greg if it's necessary Greg's AuthKit could be downloaded from http://www.amug.org/~glguerin/ sw/#authkit Michael Hall (mikehall at spacestar dot net) had a suggestion to make implementation of the jaas LoginModule based on Greg's AuthKit (his modification of the Greg's AuthKit could be found at http:// www.spacestar.net/users/mikehall/authkit.dmg) but Michael's AuthKitLoginModule does only half a job: it does authenticate but it can not run any external unix process in privileged mode (at least I wasn't able to do so) possible explanation could be found in conversation between Greg and Michael at Apple's java-dev list (look for archives) so I didn't use jaas API for rxtxinstaller I created folder MacOSX in the contrib folder comment 1. if you want to run that installer as standalone application all you need that RXTXInstaller.jar 2. if you want to use webstart you have to add Greg's libAuthKit.jnilib to the mac os x's resources in theory RXTXInstaller.jar doesn't need it, but there is a problem with loading libAuthKit.jnilib from webstart authkit uses loadLibrary method to load library and it failed (from webstart) for standalone application I extract libAuthKit.jnilib from the RXTXInstaller.jar and put it into the /Library/Java/Extensions or ~/Library/Java/Extensions folder that file will be deleted after installer quit unfortunately I didn't have time to put documentation there but it is mostly self-explanatory I took installer code from my gl4java installer that I did about 3 years ago (with small modifications) it would be very nice if Apple will release LoginModule that really will do the job (com.apple.security.auth.module package????? ) (UnixLoginModule is pretty useless) From lyon at docjava.com Mon Mar 20 06:34:39 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Mon, 20 Mar 2006 08:34:39 -0500 Subject: [Rxtx] Mac OS X RXTX java installer In-Reply-To: <64BC1E23-FDDE-4CE6-8863-CFC881CBC224@mac.com> References: <07D0DE29-BA32-4CFE-B036-66BC6423D385@buechse.de> <441AE3E0.2030503@willicon.de> <12531986.1142622114996.JavaMail.dmarkman@mac.com> <441B2674.9010409@willicon.de> <13577405.1142634732776.JavaMail.dmarkman@mac.com> <441B4182.8010407@willicon.de> <92CD0D6C-5BE8-426E-A46D-99452059FF49@mac.com> <441BBB2D.8030305@willicon.de> <441C4088.5090905@willicon.de> <64BC1E23-FDDE-4CE6-8863-CFC881CBC224@mac.com> Message-ID: Hi Dimitry, This sounds like great work. Just a couple of questions; After the check out of the CVS files, using: setenv CVSROOT :pserver:anonymous at cvs.milestonesolutions.com:/usr/local/cvsroot 53 8:28 setenv PASSWORD mousy 54 8:29 cvs login 55 8:29 cvs checkout rxtx-devel I cd'd over to: rxtx-devel/MACOSX_IDE And found: CVS/ CW/ ForPackageMaker/ PB/ Where is the installer? Thanks! - Doug From tjarvi at qbang.org Mon Mar 20 06:39:37 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 20 Mar 2006 06:39:37 -0700 (MST) Subject: [Rxtx] Mac OS X RXTX java installer In-Reply-To: References: <07D0DE29-BA32-4CFE-B036-66BC6423D385@buechse.de> <441AE3E0.2030503@willicon.de> <12531986.1142622114996.JavaMail.dmarkman@mac.com> <441B2674.9010409@willicon.de> <13577405.1142634732776.JavaMail.dmarkman@mac.com> <441B4182.8010407@willicon.de> <92CD0D6C-5BE8-426E-A46D-99452059FF49@mac.com> <441BBB2D.8030305@willicon.de> <441C4088.5090905@willicon.de> <64BC1E23-FDDE-4CE6-8863-CFC881CBC224@mac.com> Message-ID: On Mon, 20 Mar 2006, Dr. Douglas Lyon wrote: > Hi Dimitry, > This sounds like great work. Just a couple of questions; > After the check out of the CVS files, using: > setenv CVSROOT > :pserver:anonymous at cvs.milestonesolutions.com:/usr/local/cvsroot > 53 8:28 setenv PASSWORD mousy > 54 8:29 cvs login > 55 8:29 cvs checkout rxtx-devel Hi Doug You want "cvs checkout -r commapi-0-0-1 rxtx-devel" to get RXTX 2.1 The default branch is rxtx 2.0 which isn't very active right now. -- Trent Jarvi tjarvi at qbang.org From lyon at docjava.com Mon Mar 20 07:05:44 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Mon, 20 Mar 2006 09:05:44 -0500 Subject: [Rxtx] Mac OS X RXTX java installer In-Reply-To: References: <07D0DE29-BA32-4CFE-B036-66BC6423D385@buechse.de> <441AE3E0.2030503@willicon.de> <12531986.1142622114996.JavaMail.dmarkman@mac.com> <441B2674.9010409@willicon.de> <13577405.1142634732776.JavaMail.dmarkman@mac.com> <441B4182.8010407@willicon.de> <92CD0D6C-5BE8-426E-A46D-99452059FF49@mac.com> <441BBB2D.8030305@willicon.de> <441C4088.5090905@willicon.de> <64BC1E23-FDDE-4CE6-8863-CFC881CBC224@mac.com> Message-ID: Hi Trent, Thanks for the info on the CVS checkout procedure. I did that and am still not sure where the installer is. Here is what I have: cd MACOSX_IDE/ p4.docjava.com{lyon}121: ls CVS/ ForPackageMaker/ PB/ p4.docjava.com{lyon}122: find . | more . ./ForPackageMaker ./ForPackageMaker/RXTX.pkg.sit.hqx ./ForPackageMaker/Resources ./ForPackageMaker/Resources/ReadMe.rtf ./ForPackageMaker/Resources/Welcome.rtf ./ForPackageMaker/Resources/CVS ./ForPackageMaker/Resources/CVS/Entries ./ForPackageMaker/Resources/CVS/Repository ./ForPackageMaker/Resources/CVS/Tag ./ForPackageMaker/Resources/CVS/Root ./ForPackageMaker/Resources/preinstall ./ForPackageMaker/Resources/License.rtf ./ForPackageMaker/Resources/preupgrade ./ForPackageMaker/RXTX.pmsp ./ForPackageMaker/CVS ./ForPackageMaker/CVS/Entries ./ForPackageMaker/CVS/Repository ./ForPackageMaker/CVS/Entries.Log ./ForPackageMaker/CVS/Tag ./ForPackageMaker/CVS/Root ./ForPackageMaker/RXTX_Tiger.pkg.sitx.hqx ./ForPackageMaker/RXTX_Jag.pkg.sit.hqx ./ForPackageMaker/Install ./ForPackageMaker/Install/CVS ./ForPackageMaker/Install/CVS/Entries ./ForPackageMaker/Install/CVS/Repository ./ForPackageMaker/Install/CVS/Tag ./ForPackageMaker/Install/CVS/Root ./ForPackageMaker/Install/Library ./ForPackageMaker/Install/Library/CVS ./ForPackageMaker/Install/Library/CVS/Entries ./ForPackageMaker/Install/Library/CVS/Repository ./ForPackageMaker/Install/Library/CVS/Tag ./ForPackageMaker/Install/Library/CVS/Root ./ForPackageMaker/Install/Library/Java ./ForPackageMaker/Install/Library/Java/Extensions ./ForPackageMaker/Install/Library/Java/Extensions/RXTXcomm.jar ./ForPackageMaker/Install/Library/Java/Extensions/CVS ./ForPackageMaker/Install/Library/Java/Extensions/CVS/Entries ./ForPackageMaker/Install/Library/Java/Extensions/CVS/Repository ./ForPackageMaker/Install/Library/Java/Extensions/CVS/Tag ./ForPackageMaker/Install/Library/Java/Extensions/CVS/Root ./ForPackageMaker/Install/Library/Java/Extensions/librxtxSerial.jnilib ./ForPackageMaker/Install/Library/Java/CVS ./ForPackageMaker/Install/Library/Java/CVS/Entries ./ForPackageMaker/Install/Library/Java/CVS/Repository ./ForPackageMaker/Install/Library/Java/CVS/Entries.Log ./ForPackageMaker/Install/Library/Java/CVS/Tag ./ForPackageMaker/Install/Library/Java/CVS/Root ./ForPackageMaker/RXTX_Tiger.pmproj.sitx.hqx ./CVS ./CVS/Entries ./CVS/Repository ./CVS/Entries.Log ./CVS/Tag ./CVS/Root ./PB ./PB/LibSerialUniversal.xcodeproj.sitx.hqx ./PB/CVS ./PB/CVS/Entries ./PB/CVS/Repository ./PB/CVS/Entries.Log ./PB/CVS/Tag ./PB/CVS/Root ./PB/LibSerial.pbproj.sit.hqx ./PB/startpoint.c ./PB/config.h What is the procedure to run this installer? Do we need a README in: /rxtx-devel/MACOSX_IDE Here is what we have: CVS/ ForPackageMaker/ PB/ Thanks! - DL >On Mon, 20 Mar 2006, Dr. Douglas Lyon wrote: > >>Hi Dimitry, >>This sounds like great work. Just a couple of questions; >>After the check out of the CVS files, using: >>setenv CVSROOT >>:pserver:anonymous at cvs.milestonesolutions.com:/usr/local/cvsroot >> 53 8:28 setenv PASSWORD mousy >> 54 8:29 cvs login >> 55 8:29 cvs checkout rxtx-devel > >Hi Doug > >You want "cvs checkout -r commapi-0-0-1 rxtx-devel" to get RXTX 2.1 >The default branch is rxtx 2.0 which isn't very active right now. > >-- >Trent Jarvi >tjarvi at qbang.org From tjarvi at qbang.org Mon Mar 20 07:25:30 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 20 Mar 2006 07:25:30 -0700 (MST) Subject: [Rxtx] Mac OS X RXTX java installer In-Reply-To: References: <07D0DE29-BA32-4CFE-B036-66BC6423D385@buechse.de> <441AE3E0.2030503@willicon.de> <12531986.1142622114996.JavaMail.dmarkman@mac.com> <441B2674.9010409@willicon.de> <13577405.1142634732776.JavaMail.dmarkman@mac.com> <441B4182.8010407@willicon.de> <92CD0D6C-5BE8-426E-A46D-99452059FF49@mac.com> <441BBB2D.8030305@willicon.de> <441C4088.5090905@willicon.de> <64BC1E23-FDDE-4CE6-8863-CFC881CBC224@mac.com> Message-ID: On Mon, 20 Mar 2006, Dr. Douglas Lyon wrote: > Hi Trent, > Thanks for the info on the CVS checkout procedure. > I did that and am still not sure where the installer is. Hi Doug It does look like it was not cvs committed. There is no rxtx-devel/contrib/MacOSX directory in there at the moment. It was mentioned that it was put under contrib. -- Trent Jarvi tjarvi at qbang.org From dmarkman at mac.com Mon Mar 20 07:29:56 2006 From: dmarkman at mac.com (Dmitry Markman) Date: Mon, 20 Mar 2006 09:29:56 -0500 Subject: [Rxtx] Mac OS X RXTX java installer In-Reply-To: References: <07D0DE29-BA32-4CFE-B036-66BC6423D385@buechse.de> <441AE3E0.2030503@willicon.de> <12531986.1142622114996.JavaMail.dmarkman@mac.com> <441B2674.9010409@willicon.de> <13577405.1142634732776.JavaMail.dmarkman@mac.com> <441B4182.8010407@willicon.de> <92CD0D6C-5BE8-426E-A46D-99452059FF49@mac.com> <441BBB2D.8030305@willicon.de> <441C4088.5090905@willicon.de> <64BC1E23-FDDE-4CE6-8863-CFC881CBC224@mac.com> Message-ID: <6054EB4E-F7E0-4A9C-BDDA-D582D6D8826F@mac.com> you can find it in the rxtx-devel/contrib folder On Mar 20, 2006, at 9:05 AM, Dr. Douglas Lyon wrote: > Hi Trent, > Thanks for the info on the CVS checkout procedure. > I did that and am still not sure where the installer is. > Here is what I have: > cd MACOSX_IDE/ > p4.docjava.com{lyon}121: ls > CVS/ ForPackageMaker/ PB/ > p4.docjava.com{lyon}122: find . | more > . > ./ForPackageMaker > ./ForPackageMaker/RXTX.pkg.sit.hqx > ./ForPackageMaker/Resources > ./ForPackageMaker/Resources/ReadMe.rtf > ./ForPackageMaker/Resources/Welcome.rtf > ./ForPackageMaker/Resources/CVS > ./ForPackageMaker/Resources/CVS/Entries > ./ForPackageMaker/Resources/CVS/Repository > ./ForPackageMaker/Resources/CVS/Tag > ./ForPackageMaker/Resources/CVS/Root > ./ForPackageMaker/Resources/preinstall > ./ForPackageMaker/Resources/License.rtf > ./ForPackageMaker/Resources/preupgrade > ./ForPackageMaker/RXTX.pmsp > ./ForPackageMaker/CVS > ./ForPackageMaker/CVS/Entries > ./ForPackageMaker/CVS/Repository > ./ForPackageMaker/CVS/Entries.Log > ./ForPackageMaker/CVS/Tag > ./ForPackageMaker/CVS/Root > ./ForPackageMaker/RXTX_Tiger.pkg.sitx.hqx > ./ForPackageMaker/RXTX_Jag.pkg.sit.hqx > ./ForPackageMaker/Install > ./ForPackageMaker/Install/CVS > ./ForPackageMaker/Install/CVS/Entries > ./ForPackageMaker/Install/CVS/Repository > ./ForPackageMaker/Install/CVS/Tag > ./ForPackageMaker/Install/CVS/Root > ./ForPackageMaker/Install/Library > ./ForPackageMaker/Install/Library/CVS > ./ForPackageMaker/Install/Library/CVS/Entries > ./ForPackageMaker/Install/Library/CVS/Repository > ./ForPackageMaker/Install/Library/CVS/Tag > ./ForPackageMaker/Install/Library/CVS/Root > ./ForPackageMaker/Install/Library/Java > ./ForPackageMaker/Install/Library/Java/Extensions > ./ForPackageMaker/Install/Library/Java/Extensions/RXTXcomm.jar > ./ForPackageMaker/Install/Library/Java/Extensions/CVS > ./ForPackageMaker/Install/Library/Java/Extensions/CVS/Entries > ./ForPackageMaker/Install/Library/Java/Extensions/CVS/Repository > ./ForPackageMaker/Install/Library/Java/Extensions/CVS/Tag > ./ForPackageMaker/Install/Library/Java/Extensions/CVS/Root > ./ForPackageMaker/Install/Library/Java/Extensions/librxtxSerial.jnilib > ./ForPackageMaker/Install/Library/Java/CVS > ./ForPackageMaker/Install/Library/Java/CVS/Entries > ./ForPackageMaker/Install/Library/Java/CVS/Repository > ./ForPackageMaker/Install/Library/Java/CVS/Entries.Log > ./ForPackageMaker/Install/Library/Java/CVS/Tag > ./ForPackageMaker/Install/Library/Java/CVS/Root > ./ForPackageMaker/RXTX_Tiger.pmproj.sitx.hqx > ./CVS > ./CVS/Entries > ./CVS/Repository > ./CVS/Entries.Log > ./CVS/Tag > ./CVS/Root > ./PB > ./PB/LibSerialUniversal.xcodeproj.sitx.hqx > ./PB/CVS > ./PB/CVS/Entries > ./PB/CVS/Repository > ./PB/CVS/Entries.Log > ./PB/CVS/Tag > ./PB/CVS/Root > ./PB/LibSerial.pbproj.sit.hqx > ./PB/startpoint.c > ./PB/config.h > > What is the procedure to run this installer? > Do we need a README in: > /rxtx-devel/MACOSX_IDE > Here is what we have: > CVS/ ForPackageMaker/ PB/ > > > Thanks! > - DL > >> On Mon, 20 Mar 2006, Dr. Douglas Lyon wrote: >> >>> Hi Dimitry, >>> This sounds like great work. Just a couple of questions; >>> After the check out of the CVS files, using: >>> setenv CVSROOT :pserver:anonymous at cvs.milestonesolutions.com:/usr/ >>> local/cvsroot >>> 53 8:28 setenv PASSWORD mousy >>> 54 8:29 cvs login >>> 55 8:29 cvs checkout rxtx-devel >> >> Hi Doug >> >> You want "cvs checkout -r commapi-0-0-1 rxtx-devel" to get RXTX 2.1 >> The default branch is rxtx 2.0 which isn't very active right now. >> >> -- >> Trent Jarvi >> tjarvi at qbang.org > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx Dmitry Markman From mikehall at spacestar.net Mon Mar 20 05:25:25 2006 From: mikehall at spacestar.net (Michael Hall) Date: Mon, 20 Mar 2006 06:25:25 -0600 Subject: [Rxtx] Re: Mac OS X RXTX java installer In-Reply-To: <64BC1E23-FDDE-4CE6-8863-CFC881CBC224@mac.com> References: <07D0DE29-BA32-4CFE-B036-66BC6423D385@buechse.de> <441AE3E0.2030503@willicon.de> <12531986.1142622114996.JavaMail.dmarkman@mac.com> <441B2674.9010409@willicon.de> <13577405.1142634732776.JavaMail.dmarkman@mac.com> <441B4182.8010407@willicon.de> <92CD0D6C-5BE8-426E-A46D-99452059FF49@mac.com> <441BBB2D.8030305@willicon.de> <441C4088.5090905@willicon.de> <64BC1E23-FDDE-4CE6-8863-CFC881CBC224@mac.com> Message-ID: <247EB61F-5CD1-4132-89A2-FC105B6CF9A5@spacestar.net> On Mar 20, 2006, at 1:20 AM, Dmitry Markman wrote: > > Michael Hall (mikehall at spacestar dot net) had a suggestion to > make implementation of the jaas LoginModule > based on Greg's AuthKit > (his modification of the Greg's AuthKit could be found at http:// > www.spacestar.net/users/mikehall/authkit.dmg) > but Michael's AuthKitLoginModule does only half a job: > it does authenticate > but it can not run any external unix process in privileged mode (at > least I wasn't able to do so) If you got it working directly with Greg's the point is moot. But to clarify it anyhow. The login module does not allow you to do anything anything privileged on return as was explained by Greg. You need to work with a separate privileged process using the execPrivileged method of his API. I assume you did something similar although I haven't looked at how you are using it yet. I allowed instead for a action to be performed at the same time you login/authenticate,this... System.setProperty("authkit.action","/usr/bin/id"); just before this... lc.login(); To clarify, safely ignored as you are already complete. Mike Hall mikehall at spacestar dot net http://www.spacestar.net/users/mikehall http://sourceforge.net/projects/macnative -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2427 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20060320/f6e18202/smime-0042.bin From dmarkman at mac.com Mon Mar 20 07:36:47 2006 From: dmarkman at mac.com (Dmitry Markman) Date: Mon, 20 Mar 2006 09:36:47 -0500 Subject: [Rxtx] Re: Mac OS X RXTX java installer In-Reply-To: <247EB61F-5CD1-4132-89A2-FC105B6CF9A5@spacestar.net> References: <07D0DE29-BA32-4CFE-B036-66BC6423D385@buechse.de> <441AE3E0.2030503@willicon.de> <12531986.1142622114996.JavaMail.dmarkman@mac.com> <441B2674.9010409@willicon.de> <13577405.1142634732776.JavaMail.dmarkman@mac.com> <441B4182.8010407@willicon.de> <92CD0D6C-5BE8-426E-A46D-99452059FF49@mac.com> <441BBB2D.8030305@willicon.de> <441C4088.5090905@willicon.de> <64BC1E23-FDDE-4CE6-8863-CFC881CBC224@mac.com> <247EB61F-5CD1-4132-89A2-FC105B6CF9A5@spacestar.net> Message-ID: Hi, Michael all I have to do is to run some shell script I tried to use your action mechanism and it worked great so I just System.setProperty ("authkit.action","" ) and after that I even don't need to run anything like subject.doAs.... but after few thoughts I choose to use plain Greg's approach, because in that case I don't have to deal with various java's configurations files and therefore to use 2-3 -D parameters in the java command line especially it's useful for java web start (it's so fragile :-( ) thanks for the great job On Mar 20, 2006, at 7:25 AM, Michael Hall wrote: > > On Mar 20, 2006, at 1:20 AM, Dmitry Markman wrote: >> >> Michael Hall (mikehall at spacestar dot net) had a suggestion to >> make implementation of the jaas LoginModule >> based on Greg's AuthKit >> (his modification of the Greg's AuthKit could be found at http:// >> www.spacestar.net/users/mikehall/authkit.dmg) >> but Michael's AuthKitLoginModule does only half a job: >> it does authenticate >> but it can not run any external unix process in privileged mode >> (at least I wasn't able to do so) > > If you got it working directly with Greg's the point is moot. > > But to clarify it anyhow. > The login module does not allow you to do anything anything > privileged on return as was explained by Greg. You need to work > with a separate privileged process using the execPrivileged method > of his API. I assume you did something similar although I haven't > looked at how you are using it yet. > I allowed instead for a action to be performed at the same time you > login/authenticate,this... > System.setProperty("authkit.action","/usr/bin/id"); > just before this... > lc.login(); > To clarify, safely ignored as you are already complete. > > Mike Hall mikehall at spacestar dot net > http://www.spacestar.net/users/mikehall > http://sourceforge.net/projects/macnative > > > Dmitry Markman From dmarkman at mac.com Mon Mar 20 07:44:45 2006 From: dmarkman at mac.com (Dmitry Markman) Date: Mon, 20 Mar 2006 09:44:45 -0500 Subject: [Rxtx] Mac OS X RXTX java installer In-Reply-To: References: <07D0DE29-BA32-4CFE-B036-66BC6423D385@buechse.de> <441AE3E0.2030503@willicon.de> <12531986.1142622114996.JavaMail.dmarkman@mac.com> <441B2674.9010409@willicon.de> <13577405.1142634732776.JavaMail.dmarkman@mac.com> <441B4182.8010407@willicon.de> <92CD0D6C-5BE8-426E-A46D-99452059FF49@mac.com> <441BBB2D.8030305@willicon.de> <441C4088.5090905@willicon.de> <64BC1E23-FDDE-4CE6-8863-CFC881CBC224@mac.com> Message-ID: it's in the commapi-0-0-1 branch I tested it right now: cvs co -r commapi-0-0-1 rxtx-devel and I got everything On Mar 20, 2006, at 9:25 AM, Trent Jarvi wrote: > On Mon, 20 Mar 2006, Dr. Douglas Lyon wrote: > >> Hi Trent, >> Thanks for the info on the CVS checkout procedure. >> I did that and am still not sure where the installer is. > > Hi Doug > > It does look like it was not cvs committed. There is no rxtx-devel/ > contrib/MacOSX directory in there at the moment. It was mentioned > that it was put under contrib. > > -- > Trent Jarvi > tjarvi at qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx Dmitry Markman From tjarvi at qbang.org Mon Mar 20 07:52:57 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 20 Mar 2006 07:52:57 -0700 (MST) Subject: [Rxtx] Mac OS X RXTX java installer In-Reply-To: References: <07D0DE29-BA32-4CFE-B036-66BC6423D385@buechse.de> <441AE3E0.2030503@willicon.de> <12531986.1142622114996.JavaMail.dmarkman@mac.com> <441B2674.9010409@willicon.de> <13577405.1142634732776.JavaMail.dmarkman@mac.com> <441B4182.8010407@willicon.de> <92CD0D6C-5BE8-426E-A46D-99452059FF49@mac.com> <441BBB2D.8030305@willicon.de> <441C4088.5090905@willicon.de> <64BC1E23-FDDE-4CE6-8863-CFC881CBC224@mac.com> Message-ID: On Mon, 20 Mar 2006, Dmitry Markman wrote: > it's in the commapi-0-0-1 branch > > I tested it right now: > cvs co -r commapi-0-0-1 rxtx-devel > > and I got everything > A fresh checkout worked. Here is a copy of the tree (just the installer bits) ftp://ftp.qbang.org/pub/rxtx/MacOSX-installer.zip -- Trent Jarvi tjarvi at qbang.org From lyon at docjava.com Mon Mar 20 08:08:26 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Mon, 20 Mar 2006 10:08:26 -0500 Subject: [Rxtx] Mac OS X RXTX java installer In-Reply-To: References: <07D0DE29-BA32-4CFE-B036-66BC6423D385@buechse.de> <441AE3E0.2030503@willicon.de> <12531986.1142622114996.JavaMail.dmarkman@mac.com> <441B2674.9010409@willicon.de> <13577405.1142634732776.JavaMail.dmarkman@mac.com> <441B4182.8010407@willicon.de> <92CD0D6C-5BE8-426E-A46D-99452059FF49@mac.com> <441BBB2D.8030305@willicon.de> <441C4088.5090905@willicon.de> <64BC1E23-FDDE-4CE6-8863-CFC881CBC224@mac.com> Message-ID: Hi All, Is the Auth package able to work properly on non Mac OS's? It was not clear from the doc or download. Thanks! - Doug From dmarkman at mac.com Mon Mar 20 08:15:22 2006 From: dmarkman at mac.com (Dmitry Markman) Date: Mon, 20 Mar 2006 10:15:22 -0500 Subject: [Rxtx] Mac OS X RXTX java installer In-Reply-To: References: <07D0DE29-BA32-4CFE-B036-66BC6423D385@buechse.de> <441AE3E0.2030503@willicon.de> <12531986.1142622114996.JavaMail.dmarkman@mac.com> <441B2674.9010409@willicon.de> <13577405.1142634732776.JavaMail.dmarkman@mac.com> <441B4182.8010407@willicon.de> <92CD0D6C-5BE8-426E-A46D-99452059FF49@mac.com> <441BBB2D.8030305@willicon.de> <441C4088.5090905@willicon.de> <64BC1E23-FDDE-4CE6-8863-CFC881CBC224@mac.com> Message-ID: <217312D8-CCCA-4859-ABA6-32DF1CC817B9@mac.com> thanks Trent, for putting it on ftp server On Mar 20, 2006, at 9:52 AM, Trent Jarvi wrote: > A fresh checkout worked. Here is a copy of the tree (just the > installer bits) > > ftp://ftp.qbang.org/pub/rxtx/MacOSX-installer.zip > Dmitry Markman From dmarkman at mac.com Mon Mar 20 09:14:03 2006 From: dmarkman at mac.com (Dmitry Markman) Date: Mon, 20 Mar 2006 11:14:03 -0500 Subject: [Rxtx] Mac OS X RXTX java installer In-Reply-To: References: <07D0DE29-BA32-4CFE-B036-66BC6423D385@buechse.de> <441AE3E0.2030503@willicon.de> <12531986.1142622114996.JavaMail.dmarkman@mac.com> <441B2674.9010409@willicon.de> <13577405.1142634732776.JavaMail.dmarkman@mac.com> <441B4182.8010407@willicon.de> <92CD0D6C-5BE8-426E-A46D-99452059FF49@mac.com> <441BBB2D.8030305@willicon.de> <441C4088.5090905@willicon.de> <64BC1E23-FDDE-4CE6-8863-CFC881CBC224@mac.com> Message-ID: <4DEBA6F0-DA45-4E84-823E-1F1AC48BDCCC@mac.com> no it will work only on mac os x however it's harmless to run it on other platform if you want to use it for other platform you have to do the following (I'll do it for linux) 1. modify RXTXInstaller class method public static RXTXInstaller getInstance() public static RXTXInstaller getInstance() { String osName = System.getProperty("os.name").toLowerCase(); if(osName.startsWith("mac")){ return new gnu.io.installer.macosx.MACOSXRXTXInstaller(); } else if(osName.startsWith("windows")){ return new gnu.io.installer.windows.WindowsRXTXInstaller(); }else if(osName.startsWith("linux")){ return new gnu.io.installer.linux.LinuxRXTXInstaller(); } return null; } 2. create folder gnu/io/installer/linux/ 3. create class Linux386RXTXInstaller package gnu.io.installer.linux; import java.io.File; public class Linux386RXTXInstaller extends gnu.io.installer.RXTXInstaller{ public Linux386RXTXInstaller(){ createJarFolder(); createLibFolder(); addJarResource("RXTXcomm.jar","/gnu/io/installer/resources/ linux/jar/RXTXcomm.dat"); addLibResource("librxtxSerial.so","/gnu/io/installer/ resources/linux/lib/librxtxSerial.so"); } protected void createJarFolder(){ String javaHome = System.getProperty("java.home"); char separator = File.separatorChar; jarFolder = new File(javaHome+separator+"lib"+separator+"ext"); } protected void createLibFolder(){ String javaHome = System.getProperty("java.home"); char separator = File.separatorChar; libFolder = new File(javaHome+separator+"bin"); } public void runPreProcess() {} //put here some action you need public void runPostProcess() {} //put here some action you need } 4. create folder /gnu/io/installer/resources/linux/jar and put there linux's version of RXTXcomm.dat (which is renamed RXTXcomm.jar) 5. create folder /gnu/io/installer/resources/linux/lib and put there linux's version of librxtxSerial. so 6. make sure that RXTXInstaller.jar has the following items: /gnu/io/installer/resources/linux/jar/RXTXcomm.jar /gnu/io/installer/resources/linux/lib/librxtxSerial.so 7. modify file installer.pref: jar file RXTXInstaller.jar must have the following item /gnu/io/installer/installer.pref that's basically it for windows you have to do the similar things: just replace linux to windows and librxtxSerial.so to rxtxSerial.dll and create appropriate gnu.io.installer.windows.WindowsRXTXInstaller class package gnu.io.installer.windows; import java.io.File; public class WindowsRXTXInstaller extends gnu.io.installer.RXTXInstaller{ public WindowsRXTXInstaller(){ createJarFolder(); createLibFolder(); addJarResource("RXTXcomm.jar","/gnu/io/installer/resources/ windows/jar/RXTXcomm.dat"); addLibResource("librxtxSerial.so","/gnu/io/installer/ resources/windows/lib/rxtxSerial.dll"); } protected void createJarFolder(){ String javaHome = System.getProperty("java.home"); char separator = File.separatorChar; jarFolder = new File(javaHome+separator+"lib"+separator+"ext"); } protected void createLibFolder(){ String javaHome = System.getProperty("java.home"); char separator = File.separatorChar; libFolder = new File(javaHome+separator+"bin"); } public void runPreProcess() {} //put here some action you need public void runPostProcess() {} //put here some action you need } installer.pref will look like On Mar 20, 2006, at 10:08 AM, Dr. Douglas Lyon wrote: > Hi All, > Is the Auth package able to work properly on > non Mac OS's? > It was not clear from the doc or download. > > Thanks! > - Doug > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx Dmitry Markman From joachim at buechse.de Mon Mar 20 10:49:06 2006 From: joachim at buechse.de (Joachim Buechse) Date: Mon, 20 Mar 2006 18:49:06 +0100 Subject: [Rxtx] BUG: Lock file stays even if port opening fails Message-ID: This was only tested on MacOSX but looking at the code, it should be true for all systems that use lock_uucp. I am opening a port which can not be opened (dialup port of a telephone paired via bluetooth but currently not reachable). The lock file is created and stays arround, even though the port open failed. After looking a bit through the code (of 2.17), I really wonder if it wouldn't be a good idea to make the "locking" an explicit operation called from the java code. This would certainly simplify the generation of meaningfull exceptions (and java based debugging). Maybe even the handling of "preopened" ports should be in the Java part of the lib (again for java based debugging puposes). That beeing said, I have no idea if this would be possible for the 2.07 implementation. Regards, Joachim From tjarvi at qbang.org Mon Mar 20 11:24:22 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 20 Mar 2006 11:24:22 -0700 (MST) Subject: [Rxtx] BUG: Lock file stays even if port opening fails In-Reply-To: References: Message-ID: On Mon, 20 Mar 2006, Joachim Buechse wrote: > This was only tested on MacOSX but looking at the code, it should be true > for all systems that use lock_uucp. > > I am opening a port which can not be opened (dialup port of a telephone > paired via bluetooth but currently not reachable). The lock file is > created and stays arround, even though the port open failed. > > > After looking a bit through the code (of 2.17), I really wonder if it > wouldn't be a good idea to make the "locking" an explicit operation > called from the java code. This would certainly simplify the generation > of meaningfull exceptions (and java based debugging). > Maybe even the handling of "preopened" ports should be in the Java part > of the lib (again for java based debugging puposes). That beeing said, I > have no idea if this would be possible for the 2.07 implementation. > > Regards, Hi Joachim It should be possible in the 2.0-7 implementation too. The calls to RXTXPort.java would not change. We would just do more there Moving more of that logic into Java would be better as many people don't like to look at C code. There is a liblockdev on most Linux distros that can do most of the C code and would be easier to use. The problem is embeded devices will not have that library. The preopened port code has not been really tested. That was a last minute request in a product cycle. I expect it will be tested this year though. As I recall, some devices really do not like CD raising on open. The preopened ports then allow people to mess around in java without power cycling the devices or losing data. -- Trent Jarvi tjarvi at qbang.org From joachim at buechse.de Mon Mar 20 12:01:08 2006 From: joachim at buechse.de (Joachim Buechse) Date: Mon, 20 Mar 2006 20:01:08 +0100 Subject: [Rxtx] BUG: Lock file stays even if port opening fails In-Reply-To: References: Message-ID: Hi Trent, What is your general feeling about moving code to Java? The last days I have been reading quite a bit of the code and there are several things, that might not work as expected. I'll give you two examples from is_device_locked: if LOCKDIR == /var/spool/locks the directory /var/spool/lock will not be checked. LOCKDIR is not checked for lockfiles with unexpected pefixes While these things have probably never been discovered in production, they are still possibly incorrect implementations. If it was Java code, I would write some unit tests producing the errors that could later be corrected. PS: One could imagine to actually implement the whole lockfile handling in Java using some native routines to get the values required (pid, st_dev, st_rdev, ...). On 20.03.2006, at 19:24, Trent Jarvi wrote: > On Mon, 20 Mar 2006, Joachim Buechse wrote: > >> This was only tested on MacOSX but looking at the code, it should >> be true for all systems that use lock_uucp. >> >> I am opening a port which can not be opened (dialup port of a >> telephone paired via bluetooth but currently not reachable). The >> lock file is created and stays arround, even though the port open >> failed. >> >> >> After looking a bit through the code (of 2.17), I really wonder if >> it wouldn't be a good idea to make the "locking" an explicit >> operation called from the java code. This would certainly simplify >> the generation of meaningfull exceptions (and java based debugging). >> Maybe even the handling of "preopened" ports should be in the Java >> part of the lib (again for java based debugging puposes). That >> beeing said, I have no idea if this would be possible for the 2.07 >> implementation. >> >> Regards, > > Hi Joachim > > It should be possible in the 2.0-7 implementation too. The calls > to RXTXPort.java would not change. We would just do more there > Moving more of that logic into Java would be better as many people > don't like to look at C code. There is a liblockdev on most Linux > distros that can do most of the C code and would be easier to use. > The problem is embeded devices will not have that library. > > The preopened port code has not been really tested. That was a > last minute request in a product cycle. I expect it will be tested > this year though. As I recall, some devices really do not like CD > raising on open. The preopened ports then allow people to mess > around in java without power cycling the devices or losing data. > > -- > Trent Jarvi > tjarvi at qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Mon Mar 20 12:21:02 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 20 Mar 2006 12:21:02 -0700 (MST) Subject: [Rxtx] BUG: Lock file stays even if port opening fails In-Reply-To: References: Message-ID: On Mon, 20 Mar 2006, Joachim Buechse wrote: > Hi Trent, > > What is your general feeling about moving code to Java? The last days I > have been reading quite a bit of the code and there are several things, > that might not work as expected. > > I'll give you two examples from is_device_locked: > > if LOCKDIR == /var/spool/locks the directory /var/spool/lock will not be > checked. > LOCKDIR is not checked for lockfiles with unexpected pefixes > > While these things have probably never been discovered in production, > they are still possibly incorrect implementations. If it was Java code, I > would write some unit tests producing the errors that could later be > corrected. > > PS: One could imagine to actually implement the whole lockfile handling > in Java using some native routines to get the values required (pid, > st_dev, st_rdev, ...). Hi Joachim I like the idea of moving more of the code into java but there are some things to consider. If you break this into multiple JNI calls, the performance will drop considerably during enumeration of ports. We are looking for 256 ports per dev type vs (16? in Sun's 2.0 and fewer types). Its hard to make assumptions. I've seen virtual ports start at /dev/foo100 for instance. It works out to over 7500 ports on Linux if you enable them all. We already trim that back by default. See Linux-all-ports in RXTXCommDriver.java. There are also native libraries that rxtx can link to. If you move too much into Java, linking to 'standard' libraries with distros will break. "configure --enable-liblock=yes" will not be doable. This is probably a favorable way with RedHat, Debian, Suse and others. Thats the right thing to do if there will be rpms, dpkg, .. For those reasons, I think it still make sense to keep it to a minimal ~3 calls to JNI code that we can use for speed and versatility. lock() isLocked(), unlock() perhaps. When I say speed, its more about avoiding crossing the JNI layer multiple times than java vs C performance. With versatility I think liblock is the right way for most but not all (embeded) linux distros. -- Trent Jarvi tjarvi at qbang.org From joachim at buechse.de Mon Mar 20 12:42:04 2006 From: joachim at buechse.de (Joachim Buechse) Date: Mon, 20 Mar 2006 20:42:04 +0100 Subject: [Rxtx] BUG: Lock file stays even if port opening fails In-Reply-To: References: Message-ID: <82C19FE7-DDCB-45B6-B2C9-7606B66F0124@buechse.de> Ok, what about providing a default implementation in Java? The RXTXCommDriver would call a (native) function useNativeLocking and if it returns true, call the native functions for lock() isLocked (), unlock(), else is would use the Java based default implementation. This could possibly be overriden by a property (again for debugging). Joachim On 20.03.2006, at 20:21, Trent Jarvi wrote: > On Mon, 20 Mar 2006, Joachim Buechse wrote: > >> Hi Trent, >> >> What is your general feeling about moving code to Java? The last >> days I have been reading quite a bit of the code and there are >> several things, that might not work as expected. >> >> I'll give you two examples from is_device_locked: >> >> if LOCKDIR == /var/spool/locks the directory /var/spool/lock will >> not be checked. >> LOCKDIR is not checked for lockfiles with unexpected pefixes >> >> While these things have probably never been discovered in >> production, they are still possibly incorrect implementations. If >> it was Java code, I would write some unit tests producing the >> errors that could later be corrected. >> >> PS: One could imagine to actually implement the whole lockfile >> handling in Java using some native routines to get the values >> required (pid, st_dev, st_rdev, ...). > > Hi Joachim > > I like the idea of moving more of the code into java but there are > some things to consider. > > If you break this into multiple JNI calls, the performance will > drop considerably during enumeration of ports. We are looking for > 256 ports per dev type vs (16? in Sun's 2.0 and fewer types). Its > hard to make assumptions. I've seen virtual ports start at /dev/ > foo100 for instance. > > It works out to over 7500 ports on Linux if you enable them all. > We already trim that back by default. See Linux-all-ports in > RXTXCommDriver.java. > > There are also native libraries that rxtx can link to. If you move > too much into Java, linking to 'standard' libraries with distros > will break. "configure --enable-liblock=yes" will not be doable. > This is probably a favorable way with RedHat, Debian, Suse and > others. Thats the right thing to do if there will be rpms, dpkg, .. > > For those reasons, I think it still make sense to keep it to a > minimal ~3 calls to JNI code that we can use for speed and > versatility. lock() isLocked(), unlock() perhaps. When I say > speed, its more about avoiding crossing the JNI layer multiple > times than java vs C performance. With versatility I think liblock > is the right way for most but not all (embeded) linux distros. > > -- > Trent Jarvi > tjarvi at qbang.org > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Mon Mar 20 12:44:47 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 20 Mar 2006 12:44:47 -0700 (MST) Subject: [Rxtx] BUG: Lock file stays even if port opening fails In-Reply-To: <82C19FE7-DDCB-45B6-B2C9-7606B66F0124@buechse.de> References: <82C19FE7-DDCB-45B6-B2C9-7606B66F0124@buechse.de> Message-ID: On Mon, 20 Mar 2006, Joachim Buechse wrote: > Ok, what about providing a default implementation in Java? > > The RXTXCommDriver would call a (native) function useNativeLocking and if > it returns true, call the native functions for lock() isLocked(), > unlock(), else is would use the Java based default implementation. This > could possibly be overriden by a property (again for debugging). > Hi Joachim That would be OK with me. -- Trent Jarvi tjarvi at qbang.org From dmarkman at mac.com Mon Mar 20 22:27:45 2006 From: dmarkman at mac.com (Dmitry Markman) Date: Tue, 21 Mar 2006 00:27:45 -0500 Subject: [Rxtx] binaries request Message-ID: <42702213-C222-4937-A585-7CFB17E47608@mac.com> Hi can somebody send me latest linux and windows binaries, please? or where I can find them (I didn't find them in the latest tareball) I gave up with my cygwin: something wrong I have no idea what java doesn't understand /cygwin/c syntax after I changed makefile it did java part but after that gcc 3.4.4 started to complain I set buffer length to 999 lines but I didn't get beginning of the story something wrong with my 1.4.2_09/include/jni.h gcc doesn't like it anyway I gave up thanks in advance Dmitry Markman -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060320/f8cbc57c/attachment-0042.html From tjarvi at qbang.org Mon Mar 20 22:36:48 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 20 Mar 2006 22:36:48 -0700 (MST) Subject: [Rxtx] binaries request In-Reply-To: <42702213-C222-4937-A585-7CFB17E47608@mac.com> References: <42702213-C222-4937-A585-7CFB17E47608@mac.com> Message-ID: On Tue, 21 Mar 2006, Dmitry Markman wrote: > Hi > can somebody send me latest linux and windows binaries, please? > > or where I can find them (I didn't find them in the latest tareball) > > I gave up with my cygwin: something wrong I have no idea what > java doesn't understand /cygwin/c syntax > after I changed makefile it did java part > but after that gcc 3.4.4 started to complain > I set buffer length to 999 lines but I didn't get beginning of the story > something wrong with my 1.4.2_09/include/jni.h gcc doesn't like it > anyway I gave up > > thanks in advance > Hi Dmitry The bins are here: ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7-bins-r2.zip Here are the files in the zip you want. Jar: rxtx-2.1-7-bins-r2/RXTXcomm.jar Windows: rxtx-2.1-7-bins-r2/Windows/i368-mingw32/rxtxSerial.dll Linux (x86) rxtx-2.1-7-bins-r2/Linux/i686-unknown-linux-gnu/librxtxSerial.so There are others in there including Parallel port support but those are the main ones for testing. -- Trent Jarvi tjarvi at qbang.org From dmarkman at mac.com Mon Mar 20 23:05:59 2006 From: dmarkman at mac.com (Dmitry Markman) Date: Tue, 21 Mar 2006 01:05:59 -0500 Subject: [Rxtx] binaries request In-Reply-To: References: <42702213-C222-4937-A585-7CFB17E47608@mac.com> Message-ID: thank you very much but windows's readme says: rxtxSerial.dll had to be recomopiled to link in missing native methods. should I ignore it? or what? thanks again also I understand that I should use mingw not cygwin I'll try to install mingw On Mar 21, 2006, at 12:36 AM, Trent Jarvi wrote: > On Tue, 21 Mar 2006, Dmitry Markman wrote: > >> Hi >> can somebody send me latest linux and windows binaries, please? >> >> or where I can find them (I didn't find them in the latest tareball) >> >> I gave up with my cygwin: something wrong I have no idea what >> java doesn't understand /cygwin/c syntax >> after I changed makefile it did java part >> but after that gcc 3.4.4 started to complain >> I set buffer length to 999 lines but I didn't get beginning of the >> story >> something wrong with my 1.4.2_09/include/jni.h gcc doesn't like it >> anyway I gave up >> >> thanks in advance >> > > Hi Dmitry > > The bins are here: > > ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7-bins-r2.zip > > Here are the files in the zip you want. > > Jar: > > rxtx-2.1-7-bins-r2/RXTXcomm.jar > > Windows: > > rxtx-2.1-7-bins-r2/Windows/i368-mingw32/rxtxSerial.dll > > Linux (x86) > > rxtx-2.1-7-bins-r2/Linux/i686-unknown-linux-gnu/librxtxSerial.so > > There are others in there including Parallel port support but those > are the main ones for testing. > > -- > Trent Jarvi > tjarvi at qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx Dmitry Markman From tjarvi at qbang.org Mon Mar 20 23:20:33 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 20 Mar 2006 23:20:33 -0700 (MST) Subject: [Rxtx] binaries request In-Reply-To: References: <42702213-C222-4937-A585-7CFB17E47608@mac.com> Message-ID: On Tue, 21 Mar 2006, Dmitry Markman wrote: > thank you very much > > but windows's readme says: > rxtxSerial.dll had to be recomopiled to link in missing native methods. > > should I ignore it? or what? > Hi Dmitry That dll should be OK. r2 is the recompile linked to the missing native method. The readme explains why it was recompiled; fuser.o was not linked into the dll in the first release. -- Trent Jarvi tjarvi at qbang.org From ariantristan at yahoo.com Mon Mar 20 23:55:24 2006 From: ariantristan at yahoo.com (Lambok Sianturi) Date: Mon, 20 Mar 2006 22:55:24 -0800 (PST) Subject: [Rxtx] jvm issue Message-ID: <20060321065524.94779.qmail@web50701.mail.yahoo.com> Hi All, This is my first time to join RxTx mailing list. I thank you all for allowing others to sign in in requests help. I use the latest RxTx lib in Fedora 3 with java version 1.4.2_09 b05. And I got this error: # # An unexpected error has been detected by HotSpot Virtual Machine: # # SIGSEGV (0xb) at pc=0x00bf27f3, pid=2633, tid=3086112448 # # Java VM: Java HotSpot(TM) Client VM (1.4.2_09-b05 mixed mode) # Problematic frame: # C [ld-linux.so.2+0xa7f3] # # An error report file with more information is saved as hs_err_pid2633.log # # If you would like to submit a bug report, please visit: # http://java.sun.com/webapps/bugreport/crash.jsp # ./run.sh: line 3: 2633 Aborted /usr/local/java/bin/java -Djava.library.path=/usr/local/java/jre/lib/ -Djsmsengine.debug=true -classpath jsmsengine.jar:smsgateway.jar:classes12.jar:RXTXcomm.jar:. com.api.sms.SMSServer What is the jvm depedency for the latest library? Can I use 1.4.2_09 b05? Thanks in advance. Arian --------------------------------- Yahoo! Mail Use Photomail to share photos without annoying attachments. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060320/83d58dd7/attachment-0042.html From f.frumento at ngi.it Tue Mar 21 00:21:47 2006 From: f.frumento at ngi.it (Fabio Frumento) Date: Tue, 21 Mar 2006 08:21:47 +0100 Subject: [Rxtx] Javadoc on the go Message-ID: <441FA98B.9050701@ngi.it> Hi Trent, sorry for the big delay but my job is running wild, i was out for some time but now i'm back and ready to continue the javadoc for Rxtx. Did you used the last javadoc patch i sent you ? let me know if i have to send it to you again or not. regards Fabio From lyon at docjava.com Tue Mar 21 00:51:18 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Tue, 21 Mar 2006 02:51:18 -0500 Subject: [Rxtx] lock files Message-ID: Hi All, You know, if the use of lock files were under Java control (rather than a build-time decision), it might enable a more unified binary distro. It might also facilitate quick prototyping of non-lock file approaches to resolving serial port contention issues (i.e., mac-like approaches vs. linux approaches, etc.). I realize that this is a radical overhaul of the lock file policy issue. Also, it may harm performance. On the other hand, our benchmarks on JNI overhead for modern processors indicate performance impact should be minimal. Perhaps it is more of an issue with the toybox systems. Suppose there were a class with a reasonable default...someone might write: SerialPortLockPolicy.setPolicy(SerialPortLockPolicy.UNIX_LOCK_FILE); SerialPortLockPolicy.setPolicy(SerialPortLockPolicy.NO_LOCK_CHECKING); SerialPortLockPolicy.setPolicy(SerialPortLockPolicy.MAC_STYLE); Thus, we could have a run-time reconfiguration of the serial port lock policy. A special NO_LOCK version of the binary would no longer be required. Any thoughts on this? Thanks! - Doug From joachim at buechse.de Tue Mar 21 03:09:09 2006 From: joachim at buechse.de (Joachim Buechse) Date: Tue, 21 Mar 2006 11:09:09 +0100 Subject: [Rxtx] lock files In-Reply-To: References: Message-ID: <8E12916A-1B9A-4FF2-B684-E2D1C794221B@buechse.de> This is pretty much what I thought about when I suggested, that the default behaviour could be overwritten with a property. I am very much in favor of this approach. In particular this allows much easier debugging for PC based java developers. I think big parts of the Java (and maybe some parts of the C code) could use a bit of a structural workover (unit tests, javadoc, synchronization, etc). Maybe there should be a CVS branch for this experimental version. I'd be happy to contribute a first workover for some of the Java code. Designing for testability and implementing a good bunch of unit tests has been a strategy that worked quite well in the Java projects I lead. And it ultimately allows more liberal change permission. Regards, Joachim On 21.03.2006, at 08:51, Dr. Douglas Lyon wrote: > Hi All, > You know, if the use of lock files were > under Java control (rather than a build-time decision), > it might enable a more unified binary distro. It might also > facilitate quick prototyping of non-lock file approaches > to resolving serial port contention issues (i.e., mac-like > approaches vs. linux approaches, etc.). > > I realize that this is a radical overhaul of the lock file policy > issue. Also, it may harm performance. On the other hand, > our benchmarks on JNI overhead for modern processors indicate > performance impact should be minimal. Perhaps it is more of > an issue with the toybox systems. > > Suppose there were a class with a reasonable default...someone > might write: > SerialPortLockPolicy.setPolicy(SerialPortLockPolicy.UNIX_LOCK_FILE); > SerialPortLockPolicy.setPolicy(SerialPortLockPolicy.NO_LOCK_CHECKING); > SerialPortLockPolicy.setPolicy(SerialPortLockPolicy.MAC_STYLE); > > Thus, we could have a run-time reconfiguration of the serial port lock > policy. A special NO_LOCK version of the binary would no longer > be required. > > Any thoughts on this? > > Thanks! > - Doug > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From joachim at buechse.de Tue Mar 21 06:23:08 2006 From: joachim at buechse.de (Joachim Buechse) Date: Tue, 21 Mar 2006 14:23:08 +0100 Subject: [Rxtx] PATCH: use of ioctl(fd, TIOCEXCL) instead of lockfiles Message-ID: <923AE774-EEA2-4911-92D8-32BB27802C8B@buechse.de> Here is the patch for the ioctl(fd, TIOCEXCL). I have verified this only for OSX 10.4.5, hence it is only defined for APPLE. However, it should work at least for Solaris as well. If a process has requested TIOEXCL further open calls by other user processes will fail. The patch also disables uucp style locking for APPLE. Obviously this is discussable. I think it is the way to go, as it eliminates creating the lock directory which doesnt exist on the standard installation and it eliminates messing with the system group definitions (adding users to group uucp). Regarding the possibility of root processes opening a device which is locked - I consider this a feature not a potential problem. It is highly unlikely, that somebody is crazy enough to run a JavaVM as root (unless he has no other means of getting a restricted IP port opened, ie doesnt understand ipfw). Anyway, even if the process runs as root, it fails when calling ioctl(fd, TIOCEXCL). It could however still open the port to listen for RING events. I.e. a fax server which needs to see incoming calls but otherwise doesnt want to block the port. So the only case where the proposed mechanism fails is, if an incorrectly implemented process running as root conflicts with a user process. I think this can be accepted. Regards, Joachim PS: If this patch is generally accepted, the installer and Mac doku should obviously be changed as well. Index: SerialImp.c =================================================================== RCS file: /usr/local/cvsroot/rxtx-devel/src/SerialImp.c,v retrieving revision 1.46.2.187 diff -u -r1.46.2.187 SerialImp.c --- SerialImp.c 29 Jan 2006 22:19:04 -0000 1.46.2.187 +++ SerialImp.c 21 Mar 2006 12:59:16 -0000 @@ -656,6 +656,25 @@ fd=OPEN (filename, O_RDWR | O_NOCTTY | O_NONBLOCK ); } while (fd < 0 && errno==EINTR); +#ifdef OPEN_EXCL + // Note that open() follows POSIX semantics: multiple open() calls to + // the same file will succeed unless the TIOCEXCL ioctl is issued. + // This will prevent additional opens except by root-owned processes. + // See tty(4) ("man 4 tty") and ioctl(2) ("man 2 ioctl") for details. + + if (fd >= 0 && (ioctl(fd, TIOCEXCL) == -1)) + { + sprintf( message, "open: exclusive access denied for % s\n", + filename ); + report( message ); + report_error( message ); + + close(fd); + goto fail; + } +#endif /* OPEN_EXCL */ + + if( configure_port( fd ) ) goto fail; (*env)->ReleaseStringUTFChars( env, jstr, filename ); sprintf( message, "open: fd returned is %i\n", fd ); Index: SerialImp.h =================================================================== RCS file: /usr/local/cvsroot/rxtx-devel/src/SerialImp.h,v retrieving revision 1.11.2.49 diff -u -r1.11.2.49 SerialImp.h --- SerialImp.h 5 Jul 2005 17:47:21 -0000 1.11.2.49 +++ SerialImp.h 21 Mar 2006 12:59:17 -0000 @@ -135,7 +135,8 @@ /*# define LOCKDIR "/var/spool/uucp"*/ # define LOCKDIR "/var/lock" # define LOCKFILEPREFIX "LK." -# define UUCP +/*# define UUCP*/ +# define OPEN_EXCL #endif /* __APPLE__ */ #if defined(__NetBSD__) # define DEVICEDIR "/dev/" From tjarvi at qbang.org Tue Mar 21 10:26:08 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 21 Mar 2006 10:26:08 -0700 (MST) Subject: [Rxtx] Javadoc on the go In-Reply-To: <441FA98B.9050701@ngi.it> References: <441FA98B.9050701@ngi.it> Message-ID: On Tue, 21 Mar 2006, Fabio Frumento wrote: > Hi Trent, > > sorry for the big delay but my job is running wild, i was out for some > time but now i'm back and ready to continue the javadoc for Rxtx. > > Did you used the last javadoc patch i sent you ? let me know if i have to > send it to you again or not. > > regards > > Fabio Hi Fabio The patch is in the rxtx mail-list archives. It will be going in soon. I did not see a time critical portion. I'll probably be going through the list since the last batch of patches this weekend and putting them into CVS. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Tue Mar 21 10:57:18 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 21 Mar 2006 10:57:18 -0700 (MST) Subject: [Rxtx] jvm issue In-Reply-To: <20060321065524.94779.qmail@web50701.mail.yahoo.com> References: <20060321065524.94779.qmail@web50701.mail.yahoo.com> Message-ID: On Mon, 20 Mar 2006, Lambok Sianturi wrote: > Hi All, > This is my first time to join RxTx mailing list. I thank you all for allowing others to sign in in requests help. > I use the latest RxTx lib in Fedora 3 with java version 1.4.2_09 b05. And I got this error: > > # > # An unexpected error has been detected by HotSpot Virtual Machine: > # > # SIGSEGV (0xb) at pc=0x00bf27f3, pid=2633, tid=3086112448 > # > # Java VM: Java HotSpot(TM) Client VM (1.4.2_09-b05 mixed mode) > # Problematic frame: > # C [ld-linux.so.2+0xa7f3] A native library loading error? What happens if you recompile rxtx on your system and install that? This sounds like an ABI problem? rxtx 2.1-7 was compiled with a gcc 2.96 toolchain as I recall. The hope is newer system will be backwards compatible. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Tue Mar 21 11:05:29 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 21 Mar 2006 11:05:29 -0700 (MST) Subject: [Rxtx] PATCH: use of ioctl(fd, TIOCEXCL) instead of lockfiles In-Reply-To: <923AE774-EEA2-4911-92D8-32BB27802C8B@buechse.de> References: <923AE774-EEA2-4911-92D8-32BB27802C8B@buechse.de> Message-ID: On Tue, 21 Mar 2006, Joachim Buechse wrote: > Here is the patch for the ioctl(fd, TIOCEXCL). I have verified this only > for OSX 10.4.5, hence it is only defined for APPLE. However, it should > work at least for Solaris as well. > > If a process has requested TIOEXCL further open calls by other user > processes will fail. > > The patch also disables uucp style locking for APPLE. Obviously this is > discussable. I think it is the way to go, as it eliminates creating the > lock directory which doesnt exist on the standard installation and it > eliminates messing with the system group definitions (adding users to > group uucp). > > Regarding the possibility of root processes opening a device which is > locked - I consider this a feature not a potential problem. It is highly > unlikely, that somebody is crazy enough to run a JavaVM as root (unless > he has no other means of getting a restricted IP port opened, ie doesnt > understand ipfw). Anyway, even if the process runs as root, it fails when > calling ioctl(fd, TIOCEXCL). It could however still open the port to > listen for RING events. I.e. a fax server which needs to see incoming > calls but otherwise doesnt want to block the port. So the only case where > the proposed mechanism fails is, if an incorrectly implemented process > running as root conflicts with a user process. I think this can be > accepted. > > Regards, > Joachim > > PS: If this patch is generally accepted, the installer and Mac doku > should obviously be changed as well. > > > Index: SerialImp.c > =================================================================== > RCS file: /usr/local/cvsroot/rxtx-devel/src/SerialImp.c,v > retrieving revision 1.46.2.187 > diff -u -r1.46.2.187 SerialImp.c > --- SerialImp.c 29 Jan 2006 22:19:04 -0000 1.46.2.187 > +++ SerialImp.c 21 Mar 2006 12:59:16 -0000 > @@ -656,6 +656,25 @@ > fd=OPEN (filename, O_RDWR | O_NOCTTY | O_NONBLOCK ); > } while (fd < 0 && errno==EINTR); > > +#ifdef OPEN_EXCL > + // Note that open() follows POSIX semantics: multiple open() > calls to > + // the same file will succeed unless the TIOCEXCL ioctl is > issued. > + // This will prevent additional opens except by root-owned > processes. > + // See tty(4) ("man 4 tty") and ioctl(2) ("man 2 ioctl") for > details. > + > + if (fd >= 0 && (ioctl(fd, TIOCEXCL) == -1)) > + { > + sprintf( message, "open: exclusive access denied for % > s\n", > + filename ); > + report( message ); > + report_error( message ); > + > + close(fd); > + goto fail; > + } > +#endif /* OPEN_EXCL */ > + > + > if( configure_port( fd ) ) goto fail; > (*env)->ReleaseStringUTFChars( env, jstr, filename ); > sprintf( message, "open: fd returned is %i\n", fd ); > Index: SerialImp.h > =================================================================== > RCS file: /usr/local/cvsroot/rxtx-devel/src/SerialImp.h,v > retrieving revision 1.11.2.49 > diff -u -r1.11.2.49 SerialImp.h > --- SerialImp.h 5 Jul 2005 17:47:21 -0000 1.11.2.49 > +++ SerialImp.h 21 Mar 2006 12:59:17 -0000 > @@ -135,7 +135,8 @@ > /*# define LOCKDIR "/var/spool/uucp"*/ > # define LOCKDIR "/var/lock" > # define LOCKFILEPREFIX "LK." > -# define UUCP > +/*# define UUCP*/ > +# define OPEN_EXCL > #endif /* __APPLE__ */ > #if defined(__NetBSD__) > # define DEVICEDIR "/dev/" > This looks like a good start. What do you think Dmitry? Perhaps all systems with TIOCEXCL defined should use that though. Even if they use lockfiles. It wont hurt anything. That would catch people hacking their own serial apps without checking lockfiles. Its a good idea to avoid C++ style comments in the C portions. Some older systems don't deal with them well. If it's just for Mac OS X, it isn't a big deal. I think it was the Irix compiler that was problematic? -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Tue Mar 21 11:22:05 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 21 Mar 2006 11:22:05 -0700 (MST) Subject: [Rxtx] lock files In-Reply-To: <8E12916A-1B9A-4FF2-B684-E2D1C794221B@buechse.de> References: <8E12916A-1B9A-4FF2-B684-E2D1C794221B@buechse.de> Message-ID: We can try it. Maybe the JNI is much improved. The nice thing about linking into liblock is distros then worry about lockfiles on their systems. This way, we have to deal with any changes that may show up. On Tue, 21 Mar 2006, Joachim Buechse wrote: > This is pretty much what I thought about when I suggested, that the > default behaviour could be overwritten with a property. I am very much in > favor of this approach. In particular this allows much easier debugging > for PC based java developers. > > I think big parts of the Java (and maybe some parts of the C code) could > use a bit of a structural workover (unit tests, javadoc, synchronization, > etc). Maybe there should be a CVS branch for this experimental version. > I'd be happy to contribute a first workover for some of the Java code. > Designing for testability and implementing a good bunch of unit tests has > been a strategy that worked quite well in the Java projects I lead. And > it ultimately allows more liberal change permission. > > Regards, > Joachim > > > On 21.03.2006, at 08:51, Dr. Douglas Lyon wrote: > >> Hi All, >> You know, if the use of lock files were >> under Java control (rather than a build-time decision), >> it might enable a more unified binary distro. It might also >> facilitate quick prototyping of non-lock file approaches >> to resolving serial port contention issues (i.e., mac-like >> approaches vs. linux approaches, etc.). >> >> I realize that this is a radical overhaul of the lock file policy >> issue. Also, it may harm performance. On the other hand, >> our benchmarks on JNI overhead for modern processors indicate >> performance impact should be minimal. Perhaps it is more of >> an issue with the toybox systems. >> >> Suppose there were a class with a reasonable default...someone >> might write: >> SerialPortLockPolicy.setPolicy(SerialPortLockPolicy.UNIX_LOCK_FILE); >> SerialPortLockPolicy.setPolicy(SerialPortLockPolicy.NO_LOCK_CHECKING); >> SerialPortLockPolicy.setPolicy(SerialPortLockPolicy.MAC_STYLE); >> >> Thus, we could have a run-time reconfiguration of the serial port lock >> policy. A special NO_LOCK version of the binary would no longer >> be required. >> >> Any thoughts on this? >> >> Thanks! >> - Doug >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From dmarkman at mac.com Tue Mar 21 16:05:17 2006 From: dmarkman at mac.com (Dmitry Markman) Date: Tue, 21 Mar 2006 18:05:17 -0500 Subject: [Rxtx] PATCH: use of ioctl(fd, TIOCEXCL) instead of lockfiles In-Reply-To: References: <923AE774-EEA2-4911-92D8-32BB27802C8B@buechse.de> Message-ID: <512AC70C-BB86-48F2-A83C-023F35C23BAB@mac.com> I think it's cool, but I'd like to have that property implementation when user can choose between locking mechanism about comments: it's easy to change comments to the C style or we can use extensions of the file to cpp so c++ compiler will be used On Mar 21, 2006, at 1:05 PM, Trent Jarvi wrote: > This looks like a good start. What do you think Dmitry? Perhaps > all systems with TIOCEXCL defined should use that though. Even if > they use lockfiles. It wont hurt anything. That would catch > people hacking their own serial apps without checking lockfiles. > > Its a good idea to avoid C++ style comments in the C portions. > Some older systems don't deal with them well. If it's just for Mac > OS X, it isn't a big deal. I think it was the Irix compiler that > was problematic? Dmitry Markman From dmarkman at mac.com Tue Mar 21 16:13:00 2006 From: dmarkman at mac.com (Dmitry Markman) Date: Tue, 21 Mar 2006 18:13:00 -0500 Subject: [Rxtx] PATCH: use of ioctl(fd, TIOCEXCL) instead of lockfiles In-Reply-To: References: <923AE774-EEA2-4911-92D8-32BB27802C8B@buechse.de> Message-ID: I'd like to add that creating locking folder isn't a big deal we never had a problem related to the lock folders, because we always used installer on mac os x from other hand I'm not very much familiar with iotcl locking approach and I'm not sure it's more efficient Joachim wrote "I think it is the way to go, as it eliminates creating the lock directory which doesnt exist on the standard installation and it eliminates messing with the system group definitions (adding users to group uucp)." but I really didn't have any problem with that 1. doesn't exist on the standard installation there are many-many things that don't exist in the standard installation so I don't think that argument is strong enough 2. messing with the system group definitions I don't think we're messing with the group definition mac os x provides very clear way to set up group's members and together with Greg Guerin AuthKit there is no problem to set those definitions so I don't think that argument is strong either but from other hand using iotcl is more promising and is more elegant On Mar 21, 2006, at 1:05 PM, Trent Jarvi wrote: > > This looks like a good start. What do you think Dmitry? Perhaps > all systems with TIOCEXCL defined should use that though. Even if > they use lockfiles. It wont hurt anything. That would catch > people hacking their own serial apps without checking lockfiles. Dmitry Markman From joachim at buechse.de Wed Mar 22 04:46:45 2006 From: joachim at buechse.de (Joachim Buechse) Date: Wed, 22 Mar 2006 12:46:45 +0100 Subject: [Rxtx] PATCH: use of ioctl(fd, TIOCEXCL) instead of lockfiles In-Reply-To: References: <923AE774-EEA2-4911-92D8-32BB27802C8B@buechse.de> Message-ID: Sorry, I was not very clear with my arguments, so I will try again;-) Please, don't take this as an attack against work that has been done. I think the contributions that have been made in the past were made in a good spirit. But I really believe, that the current solution for OSX has many shortcomings and should be changed as soon as possible. lock files --- The /var/lock folder does not exist on the standard OSX installation, however the standard installation includes several applications that use serial ports (i.e. the FAX capability). This indicates, that the lock folder approach will not work well with system components. Applications for OSX will generally try to live in harmony with system components (except for HP print drivers of course). I think RXTX should follow this approach as well. uucp group --- Accessing serial ports is not an admin privileged operation on OSX. Any user (world) has read/write privileges on /dev/tty*. So the system default is to not enforce any group membership to access these ports. The group uucp however is a system group on all unix systems I know. It exists for certain system processes. A non admin user should in general not be a member of this group. Quite arguably no user should ever be a member of this group. Installer --- My general opinion is, that - no Installer should touch user or group data without warning - no Application Installer should touch groups which are not specific to the very application installed - no Installer should ever add regular users to a system group The current installer injects the installing user in the group uucp without warning about this change and without giving the option to "opt out" of this change. This is a potential security risk (but not currently a real one, as OSX contains no folders belonging to group uucp). The current installer does not work for multi user systems. It puts the installing user in the uucp group. However the installing user is not necessarily the user that will use the application. Putting all users that may use a serial port application in the system group uucp seems like a very invasive approach to me. Besides that, newly created users will not automatically be in the group and hence, serial applications will "break" for new users without obvious reasons. Avoiding the lock files will allow self contained applications (i.e. drag&drop installation). In my eyes this is largely preferable over an installer that requests admin privileges. Adding up all these points indicates very strongly, that the lock-file implementation is not the way to go on OSX. Regards, Joachim On 22.03.2006, at 00:13, Dmitry Markman wrote: > I'd like to add that > > creating locking folder isn't a big deal > we never had a problem related to the lock folders, because we > always used installer on mac os x > from other hand I'm not very much familiar with iotcl locking > approach and I'm not sure it's more efficient > > Joachim wrote "I think it is the way to go, as it eliminates > creating the lock directory which doesnt exist on the standard > installation and it eliminates messing with the system group > definitions (adding users to group uucp)." but I really didn't have > any problem with that > > 1. doesn't exist on the standard installation > there are many-many things that don't exist in the standard > installation so I don't think that argument is strong enough > 2. messing with the system group definitions > I don't think we're messing with the group definition > mac os x provides very clear way to set up group's members and > together with Greg Guerin AuthKit there is no problem to set those > definitions > so I don't think that argument is strong either > but from other hand using iotcl is more promising and is more elegant > > > > On Mar 21, 2006, at 1:05 PM, Trent Jarvi wrote: > >> >> This looks like a good start. What do you think Dmitry? Perhaps >> all systems with TIOCEXCL defined should use that though. Even if >> they use lockfiles. It wont hurt anything. That would catch >> people hacking their own serial apps without checking lockfiles. > > Dmitry Markman > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From dmarkman at mac.com Wed Mar 22 05:27:13 2006 From: dmarkman at mac.com (Dmitry Markman) Date: Wed, 22 Mar 2006 07:27:13 -0500 Subject: [Rxtx] PATCH: use of ioctl(fd, TIOCEXCL) instead of lockfiles In-Reply-To: References: <923AE774-EEA2-4911-92D8-32BB27802C8B@buechse.de> Message-ID: <83440CF3-DCD8-41C1-B941-F227232C27E3@mac.com> thanks for the very good explanation I didn't think that you were attacking any thing, so don't worry I just had feeling, that there were more aesthetic reasons for going to ioctl then real necessity now you explained everything quite well (BTW, asfar as I remember installer asks admin password so it wasn't quiet, but it really doesn't matter now) thanks On Mar 22, 2006, at 6:46 AM, Joachim Buechse wrote: > Sorry, I was not very clear with my arguments, so I will try again;-) > > Please, don't take this as an attack against work that has been > done. I think the contributions that have been made in the past > were made in a good spirit. But I really believe, that the current > solution for OSX has many shortcomings and should be changed as > soon as possible. > > lock files > --- > The /var/lock folder does not exist on the standard OSX > installation, however the standard installation includes several > applications that use serial ports (i.e. the FAX capability). This > indicates, that the lock folder approach will not work well with > system components. Applications for OSX will generally try to live > in harmony with system components (except for HP print drivers of > course). I think RXTX should follow this approach as well. > > uucp group > --- > Accessing serial ports is not an admin privileged operation on OSX. > Any user (world) has read/write privileges on /dev/tty*. So the > system default is to not enforce any group membership to access > these ports. The group uucp however is a system group on all unix > systems I know. It exists for certain system processes. A non admin > user should in general not be a member of this group. Quite > arguably no user should ever be a member of this group. > > Installer > --- > My general opinion is, that > - no Installer should touch user or group data without warning > - no Application Installer should touch groups which are not > specific to the very application installed > - no Installer should ever add regular users to a system group > > The current installer injects the installing user in the group uucp > without warning about this change and without giving the option to > "opt out" of this change. This is a potential security risk (but > not currently a real one, as OSX contains no folders belonging to > group uucp). > > The current installer does not work for multi user systems. It puts > the installing user in the uucp group. However the installing user > is not necessarily the user that will use the application. Putting > all users that may use a serial port application in the system > group uucp seems like a very invasive approach to me. Besides that, > newly created users will not automatically be in the group and > hence, serial applications will "break" for new users without > obvious reasons. > > > Avoiding the lock files will allow self contained applications > (i.e. drag&drop installation). In my eyes this is largely > preferable over an installer that requests admin privileges. Adding > up all these points indicates very strongly, that the lock-file > implementation is not the way to go on OSX. > > Regards, > Joachim > > > On 22.03.2006, at 00:13, Dmitry Markman wrote: > >> I'd like to add that >> >> creating locking folder isn't a big deal >> we never had a problem related to the lock folders, because we >> always used installer on mac os x >> from other hand I'm not very much familiar with iotcl locking >> approach and I'm not sure it's more efficient >> >> Joachim wrote "I think it is the way to go, as it eliminates >> creating the lock directory which doesnt exist on the standard >> installation and it eliminates messing with the system group >> definitions (adding users to group uucp)." but I really didn't >> have any problem with that >> >> 1. doesn't exist on the standard installation >> there are many-many things that don't exist in the standard >> installation so I don't think that argument is strong enough >> 2. messing with the system group definitions >> I don't think we're messing with the group definition >> mac os x provides very clear way to set up group's members and >> together with Greg Guerin AuthKit there is no problem to set those >> definitions >> so I don't think that argument is strong either >> but from other hand using iotcl is more promising and is more elegant >> >> >> >> On Mar 21, 2006, at 1:05 PM, Trent Jarvi wrote: >> >>> >>> This looks like a good start. What do you think Dmitry? Perhaps >>> all systems with TIOCEXCL defined should use that though. Even >>> if they use lockfiles. It wont hurt anything. That would catch >>> people hacking their own serial apps without checking lockfiles. >> >> Dmitry Markman >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx Dmitry Markman From lyon at docjava.com Wed Mar 22 06:12:18 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Wed, 22 Mar 2006 08:12:18 -0500 Subject: [Rxtx] sole of a new design pattern Message-ID: Hi All, I have been thinking about how we design the serial port software. I think we need a new design pattern. For lack of a better term, I shall call it: The Parametric Singleton Design Pattern By Douglas A. Lyon ABSTRACT The goal of the singleton design pattern is to make sure that there is one, and only one, instance of a given class. The goal of the parametric singleton design pattern is to make sure that there is one, and only one, instance of a given class with the given parametric values. We parametric singleton design pattern combines the singleton design pattern with a parameter that enables unique creation of instances of a class. These instances are cached. When a user asks for an instance with these parameters, the cache is checked. If the instance is in the cache, the instance is returned, otherwise it is created, added to the cache and then returned. We apply our parametric singleton design pattern to the retrieval of RMI registries bound to a given port. The goal of our system is to make sure that no two RMI registries are listening to the same socket and to make use of the RMI registries after they have been created. RMI registries are used in distributed computation. Introduction The singleton design pattern is meant to ensure that on a single instance of a class exists. It is also meant to provide a global point of access to it. The intent of the parametric singleton design pattern is to ensure that a class has only one instance for a given set of parameter values. It also provides a global point of access to it. Motivation A system cannot tolerate multiple instances of some classes with identical parameters. For example, you cannot have two instances making use of the same serial port, at the same time. You cannot have two instances that are trying to listen to the same socket connection. You cannot have two instances writing to the same file structure at the same time. As the operating system is often thought of as the arbiter of consumed resources (i.e., tape drives, serial ports, etc.) we frequently leave it to an operating system implementation to resolve these contention issues. Even for similar resources (like serial ports) there are few standards for handling contention. For example, serial ports on Linux are locked using a "/var/lock" file. POSIX, on the other hand, uses ioctl mechanisms to prevent contention. A better solution is to make a class that is responsible for keeping track of the instances created from the class. The class is declared final, so that it cannot be subclassed. The class also has a private constructor, so that other classes cannot instance it. The new design pattern is called the parametric singleton design pattern and it provides a way to access and create instances with given parameters. Applicability Use the Parametric Singleton Design Pattern when: 1. There must be exactly one instance of a class with the given parameters. 2. The instances must be accessible to clients from a well-known access point. Structure Insert UML diagram here. Participants The Parametric Singleton Clients that need instances 1. The Parametric Singleton defines an instance upon request from a client, if, and only if, the instance does not already exist. 2. The Parametric Singleton returns the instance to the client. 3. The Parametric Singleton is responsible for creating unique instances from given parameters. Collaborations Clients obtain a reference to a Parametric Singleton instance only through the parametric singleton design pattern. If the instance is left in an improper state (e.g., the serial port was left open) it is NOT the role of the Parametric Singleton Design Pattern to close the IO port. Nor is it the role of the Parametric Singleton Design Pattern to open the port. That role is delegate to some other part of the system. Further, it is not the role of the Parametric Singleton Design Pattern to check out resources. That is, multiple threads can have multiple references to the same resource at the same time. MUTEX locking is delegated to some other part of the system. Consequences The Parametric Singleton Design Pattern has several benefits: 1. Controlled access to parametrically defined instances. Since the Parametric Singleton class encapsulates its instances, there is control over how and when clients access it. 2. Reduced name space. The Parametric Singleton pattern avoids global variables that store instances created from the same parameter. Implementation Here are implementation issues to consider when using the Parametric Singleton pattern: 1. Unique mapping of parameters. The Parametric Singleton pattern requires that there be a mean to isomorphically map the parameter space into the instance space and back again. 2. Ensure unique instances. The Parametric Singleton pattern makes unique instances from parameters, and it does so only once. 3. Cache instances for fast retrieval. The Parametric Singleton pattern must be able to look up instances, given some set of parameters, and do so from some data structure. That is, there must be enough space to hold references to all the instances the program will need. Also, a mechanism is needed to look up and retrieve the instances quickly enough to satisfy the clients. Sample Code public final class ParametricSingletonRmiRegistry { private static Hashtable registry = new Hashtable(100); // use singleton pattern and??????????????????????????????????????????????? // prevent instantiation of RmiRegistryUtils.?????????????????????????????? private ParametricSingletonRmiRegistry() { } // the only instance of the Registry held by the RmiRegistryUtils?????????? public static void listNames(Integer port) { if (!isInCacheAndRunning(port)) return; Registry r = (Registry) registry.get(port); System.out.println("registry on port: " + port); System.out.println("registry: " + r); System.out.println("names: "); try { print(r.list()); } catch (RemoteException e) { In.message(e); } System.out.println("------------------------"); } /**???????????????????????????????????????????????????????????????????????? * Checks whether a Registry has been started on this host????????????????? * in the specified port.?????????????????????????????????????????????????? * If not, it tries to start one.?????????????????????????????????????????? * when it fails to start a Registry, it exits the program????????????????? * with exit code 1.??????????????????????????????????????????????????????? */ public static void restart(int port) { if (isInCacheAndRunning(port)) return; try { startRegistry(port); } catch (RemoteException e) { In.message(e); } } /**???????????????????????????????????????????????????????????????????????? * @param port????????????????????????????????????????????????????????????? * @return true if registry is in cache and running???????????????????????? */ private static boolean isInCacheAndRunning(Integer port) { if (!isRegistryRunning(port.intValue())) return false; if (!isRegistryInCache(port.intValue())) return false; return true; } /**???????????????????????????????????????????????????????????????????????? * @param port????????????????????????????????????????????????????????????? * @return true if we are able to locate a local registry on port.??????????????????????????????????????????????????????????????????????????? */ private static boolean isRegistryRunning(int port) { try { Registry r = LocateRegistry.getRegistry(port); if (r != null) return true; } catch (RemoteException e) { return false; } return false; } /**???????????????????????????????????????????????????????????????????????? * @param port????????????????????????????????????????????????????????????? * @return return true if registry is in cache????????????????????????????? */ private static boolean isRegistryInCache(int port) { if (registry.get(new Integer(port)) == null) return false; return true; } /**???????????????????????????????????????????????????????????????????????? * Restart the registry, if needed.???????????????????????????????????????? * Return the only instance of the registry for consistent global?????????? * using by making use of the Singleton Design Pattern????????????????????? *????????????????????????????????????????????????????????????????????????? * @return the internally held registry instance.?????????????????????????? */ public static Registry getRegistry(Integer port) { restart(port); return (Registry) registry.get(port); } private static void startRegistry(Integer port) throws RemoteException { Registry r; try { r = LocateRegistry.createRegistry(port.intValue()); registry.put(port, r); //r = new sun.rmi.registry.RegistryImpl???????????????????????????? /// (port.intValue());?????????????????????????????????????? // registry.put(port, r);?????????????????????????????????????????? } catch (Exception e) { //e.printStackTrace();????????????????????????????????????????????? r = LocateRegistry.getRegistry(port.intValue()); registry.put(port, r); } } public static void main(String args[]) throws RemoteException { //restart(port);??????????????????????????????????????????????????????? restart(5001); restart(5002); restart(5002); Registry r = LocateRegistry.getRegistry(5002); System.out.println("registry="+r); } } I would very much like to get your feedback on this new design pattern idea. Thank you for your time. Regards, - Doug From david.garnier at trusted-logic.com Wed Mar 22 07:36:10 2006 From: david.garnier at trusted-logic.com (David Garnier) Date: Wed, 22 Mar 2006 15:36:10 +0100 Subject: [Rxtx] sole of a new design pattern In-Reply-To: References: Message-ID: <442160DA.80107@trusted-logic.com> Hello, > The Parametric Singleton Design Pattern The Singleton is the most abused design pattern ever. Good use-cases for this pattern are extremely rare and mostly confined to problems related to hardware resources, like serial ports. > Applicability > > Use the Parametric Singleton Design Pattern when: > 1. There must be exactly one instance of a class with the given > parameters. OK. As I said above, this case this actually very unusual. The Singleton pattern is mostly used when : > 2. The instances must be accessible to clients from a well-known > access point. Using the singleton pattern in this case is just convenient for the programmer. Problems arises pretty quickly, especially if you attempt to unit-test your classes. 1) If your singleton is stateful, or hold on to stateful objects, it means that two different unit tests are not actually independent. Instead of starting with a brand new environment, the result of a test may be affected by the result of a previous test. This problem also arise when with your class relies on a database. In both cases, the solution is to reset your "unique" resource (Singleton or database) at the beginning of the test, which is a pain. Also, while most projects connect to a single database, projects that allow the use of Singletons usually contain several of thems, and new ones may cropped up unnoticed. You quickly end up with test cases that only pass in a certain order, which is a royal pain. 2) You cannot mockup a singleton. Once everyone calls the SomeSingleton class statically, you can't replace your class by SomeSingletonMockup. Furthermore, even for hardware services, the Singleton pattern does not really prevent concurrent accesses. If you start the same program in two different JVMs, unless they somehow shared the state of their "Singletons" (through lock files for example), the Singleton pattern will not prevent concurrent access. Our application uses RXTX, and we routinely encounter cases where another (native) application has already locked the port. Since we cannot modify the native application to recognize lock files, OS-level control is irreplaceable. > > Consequences > The Parametric Singleton Design Pattern has several benefits: > > 1. Controlled access to parametrically defined instances. Since > the Parametric Singleton class encapsulates its instances, there is > control over how and when clients access it. Not really. Once you've returned the instance to a client, you've lost control over it. The client can to whatever it wants with it. You cannot "recall" the instance or claim it back. > 2. Reduced name space. The Parametric Singleton pattern avoids > global variables that store instances created from the same parameter. Sure, but you don't have to rely on a Singleton for that. Just create a single Factory. > I would very much like to get your feedback on this new design > pattern idea. Well, it's nothing new. Some may say that it is the point of design patterns: formalizes the designs that occur again and again. However, this design is simply a combination of the Singleton and Factory patterns. I did use it in the past, but now I've been exposed to the shortcomings of the Singleton pattern, so I limit myself to Factories. Regards, David From sean_montgomery at baseview.com Wed Mar 22 08:35:28 2006 From: sean_montgomery at baseview.com (Sean Montgomery) Date: Wed, 22 Mar 2006 10:35:28 -0500 Subject: [Rxtx] sole of a new design pattern In-Reply-To: <442160DA.80107@trusted-logic.com> References: <442160DA.80107@trusted-logic.com> Message-ID: <05769CA7-A51B-4CF0-BAA0-E02DD905F5A4@baseview.com> On Mar 22, 2006, at 9:36 AM, David Garnier wrote: > Furthermore, even for hardware services, the Singleton pattern does > not really prevent concurrent > accesses. If you start the same program in two different JVMs, > unless they somehow shared the state > of their "Singletons" (through lock files for example), the > Singleton pattern will not prevent > concurrent access. > Multiple class loaders in a single JVM can be tricky, too. Then there's synchronization, lazy initialization and serialization of singletons to contend with. Bloch's Effective Java covers these, and here's a few articles: http://www.javaworld.com/javaworld/jw-04-2003/jw-0425-designpatterns- p3.html http://java.sun.com/developer/technicalArticles/Programming/singletons/ Just FYI :-) From lyon at docjava.com Wed Mar 22 08:50:48 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Wed, 22 Mar 2006 10:50:48 -0500 Subject: [Rxtx] sole of a new design pattern In-Reply-To: <442160DA.80107@trusted-logic.com> References: <442160DA.80107@trusted-logic.com> Message-ID: Hi All, First, I would like to thank David for his prompt and thoughtful remarks. I had no idea people that feel strongly about a design patterns! Wow! Feedback (particularly critical feedback) is greatly appreciated. Starting at the end, first: >I did use it in >the past, but now I've been exposed to the shortcomings of the >Singleton pattern, so I limit myself to Factories. David, if I understood your comments correctly, you suggested that Factories can be used in leu of the Singleton Design Pattern, or even the Parametric Singleton Design Pattern. As I see in [Gof]: Factory Method: Intent "Define an interface for creating an object, but let subclasses decide which class to instantiate. Factory Method lets a class defer instantiation to subclasses." The Singleton Design Pattern is a concrete class, which is rather different, right? Also, subclasses are not permitted with Singleton, as they are final. Naturally, I could use an abstract factory as a parent for a singleton. I could even design a facade that could be implemented with the singleton....but that is not the intention of the design. Unless you want a mock-up, as discussed, below: More below: >Hello, > >> The Parametric Singleton Design Pattern > >The Singleton is the most abused design pattern ever. Good use-cases >for this pattern are extremely >rare and mostly confined to problems related to hardware resources, >like serial ports. > > >> Applicability >> >> Use the Parametric Singleton Design Pattern when: >> 1. There must be exactly one instance of a class with the given >> parameters. >OK. As I said above, this case this actually very unusual. The >Singleton pattern is mostly used when : >> 2. The instances must be accessible to clients from a well-known >> access point. > >Using the singleton pattern in this case is just convenient for the >programmer. Problems arises >pretty quickly, especially if you attempt to unit-test your classes. > >1) If your singleton is stateful, or hold on to stateful objects, it >means that two different unit >tests are not actually independent. Instead of starting with a brand >new environment, the result of >a test may be affected by the result of a previous test. This >problem also arise when with your >class relies on a database. In both cases, the solution is to reset >your "unique" resource >(Singleton or database) at the beginning of the test, which is a >pain. Also, while most projects >connect to a single database, projects that allow the use of >Singletons usually contain several of >thems, and new ones may cropped up unnoticed. You quickly end up >with test cases that only pass in a >certain order, which is a royal pain. There are basic problems with communicating finite state machines that include reachability and deadlock analysis. These are addressed with petri net analysis and are beyond the scope of the design pattern. As you quite rightly pointed out; the parametric singleton pattern (or the singleton pattern, for that matter) enable multiple threads to gain access to the same instance. The only way that I can see to block others from gaining access to the reference is the synchronize keyword. This is putting a spin-lock (or MUTEX) on the reference. The question of how to unit-test a design pattern like the parametric singleton remains open. Perhaps this is a deficiency. > >2) You cannot mockup a singleton. Once everyone calls the >SomeSingleton class statically, you can't >replace your class by SomeSingletonMockup. Acutally, I am not sure that this is true. If the Singleton implements a Facade interface, it should be possible to make the replacement. Right? > >Furthermore, even for hardware services, the Singleton pattern does >not really prevent concurrent >accesses. If you start the same program in two different JVMs, >unless they somehow shared the state >of their "Singletons" (through lock files for example), the >Singleton pattern will not prevent >concurrent access. Good Point!! You have sharp eyes! The singleton design pattern should/could take responsibility for this. In fact, you may notice that my code does have an implementation (LocateRegistry) that can work across JVM's. The LocateRegistry will even work across the Internet! LocateRegistry takes both a host name and a Port (lock files just don't do this). I did not think to implement this beyond the local machine, but, in its present form, it will work across different processes. > >Our application uses RXTX, and we routinely encounter cases where >another (native) application has >already locked the port. Since we cannot modify the native >application to recognize lock files, >OS-level control is irreplaceable. The singleton design pattern is not meant to replace OS-level control, but to centralize the Java programmers access to it. If lock files, for example, are used for serial ports, the Singleton Design Pattern should be able to work with them. > > >> >> Consequences >> The Parametric Singleton Design Pattern has several benefits: >> > > 1. Controlled access to parametrically defined instances. Since >> the Parametric Singleton class encapsulates its instances, there is >> control over how and when clients access it. > >Not really. Once you've returned the instance to a client, you've >lost control over it. The client >can to whatever it wants with it. You cannot "recall" the instance >or claim it back. Good point, this should read: > 1. Controll when parametrically defined instances are created. Since > > the Parametric Singleton class encapsulates its instances, there is > > control over how and when they are instanced. > >> 2. Reduced name space. The Parametric Singleton pattern avoids >> global variables that store instances created from the same parameter. > >Sure, but you don't have to rely on a Singleton for that. Just >create a single Factory. > > Thank you for your thoughtful and prompt response! Regards, - Doug From dmarkman at mac.com Wed Mar 22 21:21:55 2006 From: dmarkman at mac.com (Dmitry Markman) Date: Wed, 22 Mar 2006 23:21:55 -0500 Subject: [Rxtx] sole of a new design pattern In-Reply-To: <442160DA.80107@trusted-logic.com> References: <442160DA.80107@trusted-logic.com> Message-ID: I don't think I get it On Mar 22, 2006, at 9:36 AM, David Garnier wrote: > Using the singleton pattern in this case is just convenient for the > programmer. Problems arises > pretty quickly, especially if you attempt to unit-test your classes. so you're saying that something isn't so good because you can not test it in the convenient way? if that's true, I'm totally disagree change your test, debug whatever, but if software is efficient at runtime, works fine and only problem is some unit test (which is some kind of framework for testing) then dump that unit test , dump that unit framework and make something appropriate to the software you're testing so if Douglas want to use singletons, what's the problem? and what do you mean by abusing of singleton usage? of course singleton doesn't prevent concurrent access to the resource across the processes unless you're using some OS facility to prevent it, besides singleton as it was introduced is relevant only and only inside of the same process otherwise it's not singleton it's something else (let's say network singleton: so you have remote invocation facility and some factory method that return object created by that facility) I don't have any problem with using any kind of singletons. Parametric Singleton idea (if I understand it right) could be easily implemented in the following way: use a map populate map with instances of some class and key is your parameter (you can use lazy population too) if somebody ask the key check the value if it's null so resource is taken if somebody returns the resource put it back to the map public synchronized static Object getSomeResource(Object parameter); public synchronized static void returnResource(Object parameter); getSomeResource (inside of the same process) could return null in 2 cases 1. if somebody (from other thread for example) already took that resource 2. if OS API said that resource corresponded to that parameter (serial port with parameter = 1 (port #)) is locked and unavailable; I'm not sure that in case of serial ports we even need those Parametric Singletons (unless lock checking is a very expensive operation) just ask the OS about availability of that resource and if it's available give it away and then OS will lock it and therefore in next time somebody ask it just answer that resource is locked and return null for example system has 2 serial ports available so I ask getResource("tty"); or I ask getResource("Bluetooth-Modem"); and if OS is ok you can give tty or Bluetooth-Modem or both no need for any additional pattern I think back to the problem mac os x doesn't recognize locking via files, so it handles locking via some API an instance of the singleton in each process should recognize that resource is locked (by using that API) that's all we don't have to make things more complicate then they are just because there is some nice design pattern or nice unit test framework or whatever keep things simple, make them work fast, don't introduce middle layers unless you have really good reason to do so of course I could be entirely wrong, so sorry about that in advance thanks Dmitry Markman From tjarvi at qbang.org Wed Mar 22 22:31:41 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 22 Mar 2006 22:31:41 -0700 (MST) Subject: [Rxtx] sole of a new design pattern In-Reply-To: References: Message-ID: Hi Doug Interesting reading. So far I'm just reading and thinking. I have one question so far. " Clients obtain a reference to a Parametric Singleton instance only through the parametric singleton design pattern. If the instance is left in an improper state (e.g., the serial port was left open) it is NOT the role of the Parametric Singleton Design Pattern to close the IO port. Nor is it the role of the Parametric Singleton Design Pattern to open the port. That role is delegate to some other part of the system. " So when the clients obtain a reference to the singleton, can they assume the port is there? IE, would it be the singletons role to handle things like USB dongles being removed with event hints comming from the underlying OS. Hardware abstraction layer/HAL on Linux is an example of underlying OS events. I assume that role too is delegated to other parts of the system? -- Trent Jarvi tjarvi at qbang.org From lyon at docjava.com Thu Mar 23 08:10:33 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Thu, 23 Mar 2006 10:10:33 -0500 Subject: [Rxtx] Classes don't need goals, they need roles! In-Reply-To: References: Message-ID: Hi Trent, Yes, I think that the role of the Parametric Singleton Pattern is not to open or close serial ports, nor is it to perform error checking. On the other hand, if you were to combine the role of the Parametric Singleton Pattern with another role (like that of error checking) it might not be amiss. However, I generally caution programmers against adding multiple roles to classes, as this leads to monolithic designs. Thus a different class (NativeLibDetect) could have the role of determining if the native library can be loaded. Another class (SerialPortBean) can have the role of serializing the default state of the serial port, so that it can be recovered, from user preferences, at a later time. The SerialPortDetect could have the role of determining if the serial port is removed (i.e., a USB port was unplugged). My guess is that each class should have a different role in the system, in order to ease maintenance and testing...but I could be wrong about that. Thanks! - Doug >Hi Doug > >Interesting reading. So far I'm just reading and thinking. I have >one question so far. > >" > Clients obtain a reference to a Parametric Singleton instance only >through the parametric singleton design pattern. If the instance is >left in an improper state (e.g., the serial port was left open) it is >NOT the role of the Parametric Singleton Design Pattern to close the >IO port. Nor is it the role of the Parametric Singleton Design Pattern >to >open the port. That role is delegate to some other part of the system. >" > >So when the clients obtain a reference to the singleton, can they >assume the port is there? IE, would it be the singletons role to >handle things like USB dongles being removed with event hints >comming from the underlying OS. Hardware abstraction layer/HAL on >Linux is an example of underlying OS events. > >I assume that role too is delegated to other parts of the system? > >-- >Trent Jarvi >tjarvi at qbang.org >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From maximulo at yahoo.com Fri Mar 24 01:22:38 2006 From: maximulo at yahoo.com (Maximulo Majir) Date: Fri, 24 Mar 2006 00:22:38 -0800 (PST) Subject: [Rxtx] JavaPOS Message-ID: <20060324082238.66371.qmail@web38214.mail.mud.yahoo.com> Hi all! Hello Trent! From what i understand, RXTX or JavaComm APIs were not created solely for JavaPOS. In JavaPOS, we have the virtual method claim() which is separate from open(), but in our RXTX API, claiming is done every call to open(), we cant open the port if its claimed by another application. Would it be alright to suggest or ask to create a new method called claim(..)? Is there such thing as forceclaim() in RXTX? this could be the same as portownership transfer or its equivalent. ForceClaim is in JSR80. Do you have some samples using RXTX as the lower layer for the Device Service Objects in JavaPOS? I have tried it, i just want to compare. Thank you all! maxim __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060324/496adba2/attachment-0042.html From tjarvi at qbang.org Fri Mar 24 11:28:19 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 24 Mar 2006 11:28:19 -0700 (MST) Subject: [Rxtx] Re: RXTX 2.1 Solaris Problems In-Reply-To: <3691.1143210578@www045.gmx.net> References: <3691.1143210578@www045.gmx.net> Message-ID: On Fri, 24 Mar 2006, Andreas Guenther wrote: > Hi all, > > the solaris problem was not the lock file only. > > Ok, I had to create the directory /var/spool/locks myself. > /var/spool/uucp exists. > > But rxtx didn't find any port. > > I compiled the source with my own debug-informations > and I tried to isolate the problem. > > The problem is the testRead-call in SerialImp.c > > JNIEXPORT jboolean JNICALL RXTXCommDriver(testRead)( > > ... > if ( READ( fd, &c, 1 ) < 0 ) > { > if ( errno != EAGAIN ) { > report( "testRead() read failed\n" ); > ret = JNI_FALSE; > } > } > Thanks Andreas I'm packing up to move. I'll be more or less away for a couple weeks here. I'll be checking email but my workstation is going into a box soon. This isn't hard to fix as this port should be enumerated when EWOULDBLOCK is recieved. Thats error is OK for enumeration just as EAGAIN is. I've put the bug into bugzilla so we dont forget to get to it. http://bugzilla.qbang.org/show_bug.cgi?id=42 You can add yourself to the CC list if you wish to test fixes we provide or even put a patch into bugzilla yourself. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Fri Mar 24 11:51:52 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 24 Mar 2006 11:51:52 -0700 (MST) Subject: [Rxtx] JavaPOS In-Reply-To: <20060324082238.66371.qmail@web38214.mail.mud.yahoo.com> References: <20060324082238.66371.qmail@web38214.mail.mud.yahoo.com> Message-ID: On Fri, 24 Mar 2006, Maximulo Majir wrote: > Hi all! Hello Trent! > > > From what i understand, RXTX or JavaComm APIs were not > created solely for JavaPOS. In JavaPOS, we have the virtual method > claim() which is separate from open(), but in our RXTX API, claiming is > done every call to open(), we cant open the port if its claimed by > another application. Would it be alright to suggest or ask to create a > new method called claim(..)? Is there such thing as forceclaim() in > RXTX? this could be the same as portownership transfer or its > equivalent. ForceClaim is in JSR80. > Do you have some samples using RXTX as the lower layer for the Device > Service Objects in JavaPOS? I have tried it, i just want to compare. > maxim Hi Maxim JSR80 is the USB API IBM/Sun put together. The problem is they have a richer kernel/API underneath that can handle such things. With Serial Ports, there isnt anything there other than an ioctl that says don't let anyone touch this and lockfiles that are more of a 'lets be nice.' At times we may be using USB ports but it is through the termios layer with the limitations mentioned. The advantage is that not only USB will work with rxtx. Anything that has a termios layer should work (to the extent that termios layer is complete). I don't know how forceclaim() would help you. Lets say someone has a programmer working on /dev/ttyS0 and you take it. Now you both race each other to read data first. There isn't a mechanism I know of that will solve this problem in termios. The most obvious test being a native app and a Java app trying to take the port. There is the potential of requestion ownership from other Java Applications but the use for that is very rare. Did you have something more specific in mind that I'm missing? I'm not sure that claim() and forceclaim() would help you with rxtx other than maybe locking the port with claim() without opening it. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sat Mar 25 23:42:08 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 25 Mar 2006 23:42:08 -0700 (MST) Subject: [Rxtx] Serial snoop Message-ID: I was reading the Linux kernel mail-list tonight and ran past a thread that mentioned sersnoop. This looks like a handy tool for people dealing with new toys. "a simple command-line tool for linux that echoes bytes to and from any two serial ports, ptys, or network sockets, and prints all traffic to stdout, in hex and ascii." http://www.restivo.org/projects/sersnoop/ It works on Linux only at this time (debian package available). -- Trent Jarvi tjarvi at qbang.org From beat.arnet at gmail.com Sun Mar 26 07:32:35 2006 From: beat.arnet at gmail.com (Beat Arnet) Date: Sun, 26 Mar 2006 09:32:35 -0500 Subject: [Rxtx] Error 0x5 at /home/bob/foo/tar/rxtx-2.1-7/build/../src/termios.c(860): Access is, denied. Message-ID: <4426A603.80508@gmail.com> Dear all, When trying to open the serial port, I sometimes (not always) run into the following exception (when opening the serialPort): Error 0x5 at /home/bob/foo/tar/rxtx-2.1-7/build/../src/termios.c(860): Access is denied. java.lang.UnsatisfiedLinkError: native_psmisc_report_owner at gnu.io.CommPortIdentifier.native_psmisc_report_owner(Native Method) at gnu.io.CommPortIdentifier.open(CommPortIdentifier.java:354) at codeskin.tools.CLLoader.open(CLLoader.java:79) at codeskin.tools.C2000Programmer.run(C2000Programmer.java:220) at java.lang.Thread.run(Unknown Source) Is this the type of error where I should just try to open the port again, or can it be avoided? Regards, Beat From tjarvi at qbang.org Sun Mar 26 11:40:12 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 26 Mar 2006 11:40:12 -0700 (MST) Subject: [Rxtx] Error 0x5 at /home/bob/foo/tar/rxtx-2.1-7/build/../src/termios.c(860): Access is, denied. In-Reply-To: <4426A603.80508@gmail.com> References: <4426A603.80508@gmail.com> Message-ID: On Sun, 26 Mar 2006, Beat Arnet wrote: > Dear all, > > When trying to open the serial port, I sometimes (not always) run into > the following exception (when opening the serialPort): > > Error 0x5 at /home/bob/foo/tar/rxtx-2.1-7/build/../src/termios.c(860): > Access is > denied. > > java.lang.UnsatisfiedLinkError: native_psmisc_report_owner > at gnu.io.CommPortIdentifier.native_psmisc_report_owner(Native > Method) > at gnu.io.CommPortIdentifier.open(CommPortIdentifier.java:354) > at codeskin.tools.CLLoader.open(CLLoader.java:79) > at codeskin.tools.C2000Programmer.run(C2000Programmer.java:220) > at java.lang.Thread.run(Unknown Source) > > Is this the type of error where I should just try to open the port again, > or can it be avoided? > Hi Beat We did a second build of rxtx 2.1-7 to resolve that unsatisfied link error. It should work now. rxtx is trying to tell you it thinks someone else has the serial port open. You can try to open the port again but maybe you already have a copy of the program running when it happens? ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7r2.zip fixed build. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sun Mar 26 11:44:23 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 26 Mar 2006 11:44:23 -0700 (MST) Subject: [Rxtx] RXTX spec file (fwd) Message-ID: This is probably interesting for fedora/suse users. ---------- Forwarded message ---------- Date: Sun, 26 Mar 2006 16:25:45 +0200 To: taj at www.linux.org.uk Subject: RXTX spec file I send you this spec file which allows to create a RPM for Fedora 4, 5 (x86, x86_64) with Java Sun. -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: rxtx.spec Url: http://mailman.qbang.org/pipermail/rxtx/attachments/20060326/6c7b6af6/rxtx-0038.pl From tjarvi at qbang.org Sun Mar 26 23:42:59 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 26 Mar 2006 23:42:59 -0700 (MST) Subject: [Rxtx] Upcomming events. Message-ID: This Wednesday we will be announcing a new "Maintainer" for the rxtx project. The position is more like neutral leader. I wont be going away or doing less. This is just the right thing to do as it turns out the two people with CVS write access will be at the same company. We need a third and we need neutrality. The maintainer will have final say in any conflict and will try to be neutral. It will be open for discussion. Then we will do it :) I'll still do most of the footwork I do now. But. I'm falling behind. I should have gone through the mail-list and posted the next round of changes this weekend. I'm packing to move and its going so so - 13 years of toys collected. I suspect there will be a dead period on my part (a couple weeks) comming up. But if you get it on the mail-list, we will get it in if there are no objections. I may well not be reading the mail-list during this period as I look for a house and many other things. I hope everyone will help out. Thanks -- Trent Jarvi tjarvi at qbang.org From mahmoud_hadad at yahoo.com Sun Mar 26 07:31:19 2006 From: mahmoud_hadad at yahoo.com (ronan nick) Date: Sun, 26 Mar 2006 06:31:19 -0800 (PST) Subject: [Rxtx] a question about the COMM API Message-ID: <20060326143119.54919.qmail@web60014.mail.yahoo.com> hi, i was intrested in knowing how i can communicate with my internal modem using java? for example if i want to make a phone dialer application or a caller id application where should i be looking at? and as i understood the COMM API is for devices that is attached to the computer through serial ports. --------------------------------- New Yahoo! Messenger with Voice. Call regular phones from your PC and save big. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060326/ce8329f0/attachment-0040.html From dmarkman at mac.com Mon Mar 20 00:20:43 2006 From: dmarkman at mac.com (Dmitry Markman) Date: Mon, 20 Mar 2006 02:20:43 -0500 Subject: [Rxtx] Mac OS X RXTX java installer In-Reply-To: References: <07D0DE29-BA32-4CFE-B036-66BC6423D385@buechse.de> <441AE3E0.2030503@willicon.de> <12531986.1142622114996.JavaMail.dmarkman@mac.com> <441B2674.9010409@willicon.de> <13577405.1142634732776.JavaMail.dmarkman@mac.com> <441B4182.8010407@willicon.de> <92CD0D6C-5BE8-426E-A46D-99452059FF49@mac.com> <441BBB2D.8030305@willicon.de> <441C4088.5090905@willicon.de> Message-ID: <64BC1E23-FDDE-4CE6-8863-CFC881CBC224@mac.com> Hi all I put RXTX installer that will install everything (and will create / var/lock if necessary and add user to the uucp group) for mac os x from Java into the rxtx's CVS repository it could be easily modified to install files for any platform it uses Greg Guerin's AuthKit for authentication and authorization Greg released that kit under artistic license, so Trent, please take a look we, probably, can negotiate license with Greg if it's necessary Greg's AuthKit could be downloaded from http://www.amug.org/~glguerin/ sw/#authkit Michael Hall (mikehall at spacestar dot net) had a suggestion to make implementation of the jaas LoginModule based on Greg's AuthKit (his modification of the Greg's AuthKit could be found at http:// www.spacestar.net/users/mikehall/authkit.dmg) but Michael's AuthKitLoginModule does only half a job: it does authenticate but it can not run any external unix process in privileged mode (at least I wasn't able to do so) possible explanation could be found in conversation between Greg and Michael at Apple's java-dev list (look for archives) so I didn't use jaas API for rxtxinstaller I created folder MacOSX in the contrib folder comment 1. if you want to run that installer as standalone application all you need that RXTXInstaller.jar 2. if you want to use webstart you have to add Greg's libAuthKit.jnilib to the mac os x's resources in theory RXTXInstaller.jar doesn't need it, but there is a problem with loading libAuthKit.jnilib from webstart authkit uses loadLibrary method to load library and it failed (from webstart) for standalone application I extract libAuthKit.jnilib from the RXTXInstaller.jar and put it into the /Library/Java/Extensions or ~/Library/Java/Extensions folder that file will be deleted after installer quit unfortunately I didn't have time to put documentation there but it is mostly self-explanatory I took installer code from my gl4java installer that I did about 3 years ago (with small modifications) it would be very nice if Apple will release LoginModule that really will do the job (com.apple.security.auth.module package????? ) (UnixLoginModule is pretty useless) From lyon at docjava.com Mon Mar 20 06:34:39 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Mon, 20 Mar 2006 08:34:39 -0500 Subject: [Rxtx] Mac OS X RXTX java installer In-Reply-To: <64BC1E23-FDDE-4CE6-8863-CFC881CBC224@mac.com> References: <07D0DE29-BA32-4CFE-B036-66BC6423D385@buechse.de> <441AE3E0.2030503@willicon.de> <12531986.1142622114996.JavaMail.dmarkman@mac.com> <441B2674.9010409@willicon.de> <13577405.1142634732776.JavaMail.dmarkman@mac.com> <441B4182.8010407@willicon.de> <92CD0D6C-5BE8-426E-A46D-99452059FF49@mac.com> <441BBB2D.8030305@willicon.de> <441C4088.5090905@willicon.de> <64BC1E23-FDDE-4CE6-8863-CFC881CBC224@mac.com> Message-ID: Hi Dimitry, This sounds like great work. Just a couple of questions; After the check out of the CVS files, using: setenv CVSROOT :pserver:anonymous at cvs.milestonesolutions.com:/usr/local/cvsroot 53 8:28 setenv PASSWORD mousy 54 8:29 cvs login 55 8:29 cvs checkout rxtx-devel I cd'd over to: rxtx-devel/MACOSX_IDE And found: CVS/ CW/ ForPackageMaker/ PB/ Where is the installer? Thanks! - Doug From tjarvi at qbang.org Mon Mar 20 06:39:37 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 20 Mar 2006 06:39:37 -0700 (MST) Subject: [Rxtx] Mac OS X RXTX java installer In-Reply-To: References: <07D0DE29-BA32-4CFE-B036-66BC6423D385@buechse.de> <441AE3E0.2030503@willicon.de> <12531986.1142622114996.JavaMail.dmarkman@mac.com> <441B2674.9010409@willicon.de> <13577405.1142634732776.JavaMail.dmarkman@mac.com> <441B4182.8010407@willicon.de> <92CD0D6C-5BE8-426E-A46D-99452059FF49@mac.com> <441BBB2D.8030305@willicon.de> <441C4088.5090905@willicon.de> <64BC1E23-FDDE-4CE6-8863-CFC881CBC224@mac.com> Message-ID: On Mon, 20 Mar 2006, Dr. Douglas Lyon wrote: > Hi Dimitry, > This sounds like great work. Just a couple of questions; > After the check out of the CVS files, using: > setenv CVSROOT > :pserver:anonymous at cvs.milestonesolutions.com:/usr/local/cvsroot > 53 8:28 setenv PASSWORD mousy > 54 8:29 cvs login > 55 8:29 cvs checkout rxtx-devel Hi Doug You want "cvs checkout -r commapi-0-0-1 rxtx-devel" to get RXTX 2.1 The default branch is rxtx 2.0 which isn't very active right now. -- Trent Jarvi tjarvi at qbang.org From lyon at docjava.com Mon Mar 20 07:05:44 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Mon, 20 Mar 2006 09:05:44 -0500 Subject: [Rxtx] Mac OS X RXTX java installer In-Reply-To: References: <07D0DE29-BA32-4CFE-B036-66BC6423D385@buechse.de> <441AE3E0.2030503@willicon.de> <12531986.1142622114996.JavaMail.dmarkman@mac.com> <441B2674.9010409@willicon.de> <13577405.1142634732776.JavaMail.dmarkman@mac.com> <441B4182.8010407@willicon.de> <92CD0D6C-5BE8-426E-A46D-99452059FF49@mac.com> <441BBB2D.8030305@willicon.de> <441C4088.5090905@willicon.de> <64BC1E23-FDDE-4CE6-8863-CFC881CBC224@mac.com> Message-ID: Hi Trent, Thanks for the info on the CVS checkout procedure. I did that and am still not sure where the installer is. Here is what I have: cd MACOSX_IDE/ p4.docjava.com{lyon}121: ls CVS/ ForPackageMaker/ PB/ p4.docjava.com{lyon}122: find . | more . ./ForPackageMaker ./ForPackageMaker/RXTX.pkg.sit.hqx ./ForPackageMaker/Resources ./ForPackageMaker/Resources/ReadMe.rtf ./ForPackageMaker/Resources/Welcome.rtf ./ForPackageMaker/Resources/CVS ./ForPackageMaker/Resources/CVS/Entries ./ForPackageMaker/Resources/CVS/Repository ./ForPackageMaker/Resources/CVS/Tag ./ForPackageMaker/Resources/CVS/Root ./ForPackageMaker/Resources/preinstall ./ForPackageMaker/Resources/License.rtf ./ForPackageMaker/Resources/preupgrade ./ForPackageMaker/RXTX.pmsp ./ForPackageMaker/CVS ./ForPackageMaker/CVS/Entries ./ForPackageMaker/CVS/Repository ./ForPackageMaker/CVS/Entries.Log ./ForPackageMaker/CVS/Tag ./ForPackageMaker/CVS/Root ./ForPackageMaker/RXTX_Tiger.pkg.sitx.hqx ./ForPackageMaker/RXTX_Jag.pkg.sit.hqx ./ForPackageMaker/Install ./ForPackageMaker/Install/CVS ./ForPackageMaker/Install/CVS/Entries ./ForPackageMaker/Install/CVS/Repository ./ForPackageMaker/Install/CVS/Tag ./ForPackageMaker/Install/CVS/Root ./ForPackageMaker/Install/Library ./ForPackageMaker/Install/Library/CVS ./ForPackageMaker/Install/Library/CVS/Entries ./ForPackageMaker/Install/Library/CVS/Repository ./ForPackageMaker/Install/Library/CVS/Tag ./ForPackageMaker/Install/Library/CVS/Root ./ForPackageMaker/Install/Library/Java ./ForPackageMaker/Install/Library/Java/Extensions ./ForPackageMaker/Install/Library/Java/Extensions/RXTXcomm.jar ./ForPackageMaker/Install/Library/Java/Extensions/CVS ./ForPackageMaker/Install/Library/Java/Extensions/CVS/Entries ./ForPackageMaker/Install/Library/Java/Extensions/CVS/Repository ./ForPackageMaker/Install/Library/Java/Extensions/CVS/Tag ./ForPackageMaker/Install/Library/Java/Extensions/CVS/Root ./ForPackageMaker/Install/Library/Java/Extensions/librxtxSerial.jnilib ./ForPackageMaker/Install/Library/Java/CVS ./ForPackageMaker/Install/Library/Java/CVS/Entries ./ForPackageMaker/Install/Library/Java/CVS/Repository ./ForPackageMaker/Install/Library/Java/CVS/Entries.Log ./ForPackageMaker/Install/Library/Java/CVS/Tag ./ForPackageMaker/Install/Library/Java/CVS/Root ./ForPackageMaker/RXTX_Tiger.pmproj.sitx.hqx ./CVS ./CVS/Entries ./CVS/Repository ./CVS/Entries.Log ./CVS/Tag ./CVS/Root ./PB ./PB/LibSerialUniversal.xcodeproj.sitx.hqx ./PB/CVS ./PB/CVS/Entries ./PB/CVS/Repository ./PB/CVS/Entries.Log ./PB/CVS/Tag ./PB/CVS/Root ./PB/LibSerial.pbproj.sit.hqx ./PB/startpoint.c ./PB/config.h What is the procedure to run this installer? Do we need a README in: /rxtx-devel/MACOSX_IDE Here is what we have: CVS/ ForPackageMaker/ PB/ Thanks! - DL >On Mon, 20 Mar 2006, Dr. Douglas Lyon wrote: > >>Hi Dimitry, >>This sounds like great work. Just a couple of questions; >>After the check out of the CVS files, using: >>setenv CVSROOT >>:pserver:anonymous at cvs.milestonesolutions.com:/usr/local/cvsroot >> 53 8:28 setenv PASSWORD mousy >> 54 8:29 cvs login >> 55 8:29 cvs checkout rxtx-devel > >Hi Doug > >You want "cvs checkout -r commapi-0-0-1 rxtx-devel" to get RXTX 2.1 >The default branch is rxtx 2.0 which isn't very active right now. > >-- >Trent Jarvi >tjarvi at qbang.org From tjarvi at qbang.org Mon Mar 20 07:25:30 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 20 Mar 2006 07:25:30 -0700 (MST) Subject: [Rxtx] Mac OS X RXTX java installer In-Reply-To: References: <07D0DE29-BA32-4CFE-B036-66BC6423D385@buechse.de> <441AE3E0.2030503@willicon.de> <12531986.1142622114996.JavaMail.dmarkman@mac.com> <441B2674.9010409@willicon.de> <13577405.1142634732776.JavaMail.dmarkman@mac.com> <441B4182.8010407@willicon.de> <92CD0D6C-5BE8-426E-A46D-99452059FF49@mac.com> <441BBB2D.8030305@willicon.de> <441C4088.5090905@willicon.de> <64BC1E23-FDDE-4CE6-8863-CFC881CBC224@mac.com> Message-ID: On Mon, 20 Mar 2006, Dr. Douglas Lyon wrote: > Hi Trent, > Thanks for the info on the CVS checkout procedure. > I did that and am still not sure where the installer is. Hi Doug It does look like it was not cvs committed. There is no rxtx-devel/contrib/MacOSX directory in there at the moment. It was mentioned that it was put under contrib. -- Trent Jarvi tjarvi at qbang.org From dmarkman at mac.com Mon Mar 20 07:29:56 2006 From: dmarkman at mac.com (Dmitry Markman) Date: Mon, 20 Mar 2006 09:29:56 -0500 Subject: [Rxtx] Mac OS X RXTX java installer In-Reply-To: References: <07D0DE29-BA32-4CFE-B036-66BC6423D385@buechse.de> <441AE3E0.2030503@willicon.de> <12531986.1142622114996.JavaMail.dmarkman@mac.com> <441B2674.9010409@willicon.de> <13577405.1142634732776.JavaMail.dmarkman@mac.com> <441B4182.8010407@willicon.de> <92CD0D6C-5BE8-426E-A46D-99452059FF49@mac.com> <441BBB2D.8030305@willicon.de> <441C4088.5090905@willicon.de> <64BC1E23-FDDE-4CE6-8863-CFC881CBC224@mac.com> Message-ID: <6054EB4E-F7E0-4A9C-BDDA-D582D6D8826F@mac.com> you can find it in the rxtx-devel/contrib folder On Mar 20, 2006, at 9:05 AM, Dr. Douglas Lyon wrote: > Hi Trent, > Thanks for the info on the CVS checkout procedure. > I did that and am still not sure where the installer is. > Here is what I have: > cd MACOSX_IDE/ > p4.docjava.com{lyon}121: ls > CVS/ ForPackageMaker/ PB/ > p4.docjava.com{lyon}122: find . | more > . > ./ForPackageMaker > ./ForPackageMaker/RXTX.pkg.sit.hqx > ./ForPackageMaker/Resources > ./ForPackageMaker/Resources/ReadMe.rtf > ./ForPackageMaker/Resources/Welcome.rtf > ./ForPackageMaker/Resources/CVS > ./ForPackageMaker/Resources/CVS/Entries > ./ForPackageMaker/Resources/CVS/Repository > ./ForPackageMaker/Resources/CVS/Tag > ./ForPackageMaker/Resources/CVS/Root > ./ForPackageMaker/Resources/preinstall > ./ForPackageMaker/Resources/License.rtf > ./ForPackageMaker/Resources/preupgrade > ./ForPackageMaker/RXTX.pmsp > ./ForPackageMaker/CVS > ./ForPackageMaker/CVS/Entries > ./ForPackageMaker/CVS/Repository > ./ForPackageMaker/CVS/Entries.Log > ./ForPackageMaker/CVS/Tag > ./ForPackageMaker/CVS/Root > ./ForPackageMaker/RXTX_Tiger.pkg.sitx.hqx > ./ForPackageMaker/RXTX_Jag.pkg.sit.hqx > ./ForPackageMaker/Install > ./ForPackageMaker/Install/CVS > ./ForPackageMaker/Install/CVS/Entries > ./ForPackageMaker/Install/CVS/Repository > ./ForPackageMaker/Install/CVS/Tag > ./ForPackageMaker/Install/CVS/Root > ./ForPackageMaker/Install/Library > ./ForPackageMaker/Install/Library/CVS > ./ForPackageMaker/Install/Library/CVS/Entries > ./ForPackageMaker/Install/Library/CVS/Repository > ./ForPackageMaker/Install/Library/CVS/Tag > ./ForPackageMaker/Install/Library/CVS/Root > ./ForPackageMaker/Install/Library/Java > ./ForPackageMaker/Install/Library/Java/Extensions > ./ForPackageMaker/Install/Library/Java/Extensions/RXTXcomm.jar > ./ForPackageMaker/Install/Library/Java/Extensions/CVS > ./ForPackageMaker/Install/Library/Java/Extensions/CVS/Entries > ./ForPackageMaker/Install/Library/Java/Extensions/CVS/Repository > ./ForPackageMaker/Install/Library/Java/Extensions/CVS/Tag > ./ForPackageMaker/Install/Library/Java/Extensions/CVS/Root > ./ForPackageMaker/Install/Library/Java/Extensions/librxtxSerial.jnilib > ./ForPackageMaker/Install/Library/Java/CVS > ./ForPackageMaker/Install/Library/Java/CVS/Entries > ./ForPackageMaker/Install/Library/Java/CVS/Repository > ./ForPackageMaker/Install/Library/Java/CVS/Entries.Log > ./ForPackageMaker/Install/Library/Java/CVS/Tag > ./ForPackageMaker/Install/Library/Java/CVS/Root > ./ForPackageMaker/RXTX_Tiger.pmproj.sitx.hqx > ./CVS > ./CVS/Entries > ./CVS/Repository > ./CVS/Entries.Log > ./CVS/Tag > ./CVS/Root > ./PB > ./PB/LibSerialUniversal.xcodeproj.sitx.hqx > ./PB/CVS > ./PB/CVS/Entries > ./PB/CVS/Repository > ./PB/CVS/Entries.Log > ./PB/CVS/Tag > ./PB/CVS/Root > ./PB/LibSerial.pbproj.sit.hqx > ./PB/startpoint.c > ./PB/config.h > > What is the procedure to run this installer? > Do we need a README in: > /rxtx-devel/MACOSX_IDE > Here is what we have: > CVS/ ForPackageMaker/ PB/ > > > Thanks! > - DL > >> On Mon, 20 Mar 2006, Dr. Douglas Lyon wrote: >> >>> Hi Dimitry, >>> This sounds like great work. Just a couple of questions; >>> After the check out of the CVS files, using: >>> setenv CVSROOT :pserver:anonymous at cvs.milestonesolutions.com:/usr/ >>> local/cvsroot >>> 53 8:28 setenv PASSWORD mousy >>> 54 8:29 cvs login >>> 55 8:29 cvs checkout rxtx-devel >> >> Hi Doug >> >> You want "cvs checkout -r commapi-0-0-1 rxtx-devel" to get RXTX 2.1 >> The default branch is rxtx 2.0 which isn't very active right now. >> >> -- >> Trent Jarvi >> tjarvi at qbang.org > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx Dmitry Markman From mikehall at spacestar.net Mon Mar 20 05:25:25 2006 From: mikehall at spacestar.net (Michael Hall) Date: Mon, 20 Mar 2006 06:25:25 -0600 Subject: [Rxtx] Re: Mac OS X RXTX java installer In-Reply-To: <64BC1E23-FDDE-4CE6-8863-CFC881CBC224@mac.com> References: <07D0DE29-BA32-4CFE-B036-66BC6423D385@buechse.de> <441AE3E0.2030503@willicon.de> <12531986.1142622114996.JavaMail.dmarkman@mac.com> <441B2674.9010409@willicon.de> <13577405.1142634732776.JavaMail.dmarkman@mac.com> <441B4182.8010407@willicon.de> <92CD0D6C-5BE8-426E-A46D-99452059FF49@mac.com> <441BBB2D.8030305@willicon.de> <441C4088.5090905@willicon.de> <64BC1E23-FDDE-4CE6-8863-CFC881CBC224@mac.com> Message-ID: <247EB61F-5CD1-4132-89A2-FC105B6CF9A5@spacestar.net> On Mar 20, 2006, at 1:20 AM, Dmitry Markman wrote: > > Michael Hall (mikehall at spacestar dot net) had a suggestion to > make implementation of the jaas LoginModule > based on Greg's AuthKit > (his modification of the Greg's AuthKit could be found at http:// > www.spacestar.net/users/mikehall/authkit.dmg) > but Michael's AuthKitLoginModule does only half a job: > it does authenticate > but it can not run any external unix process in privileged mode (at > least I wasn't able to do so) If you got it working directly with Greg's the point is moot. But to clarify it anyhow. The login module does not allow you to do anything anything privileged on return as was explained by Greg. You need to work with a separate privileged process using the execPrivileged method of his API. I assume you did something similar although I haven't looked at how you are using it yet. I allowed instead for a action to be performed at the same time you login/authenticate,this... System.setProperty("authkit.action","/usr/bin/id"); just before this... lc.login(); To clarify, safely ignored as you are already complete. Mike Hall mikehall at spacestar dot net http://www.spacestar.net/users/mikehall http://sourceforge.net/projects/macnative -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2427 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20060320/f6e18202/smime-0043.bin From dmarkman at mac.com Mon Mar 20 07:36:47 2006 From: dmarkman at mac.com (Dmitry Markman) Date: Mon, 20 Mar 2006 09:36:47 -0500 Subject: [Rxtx] Re: Mac OS X RXTX java installer In-Reply-To: <247EB61F-5CD1-4132-89A2-FC105B6CF9A5@spacestar.net> References: <07D0DE29-BA32-4CFE-B036-66BC6423D385@buechse.de> <441AE3E0.2030503@willicon.de> <12531986.1142622114996.JavaMail.dmarkman@mac.com> <441B2674.9010409@willicon.de> <13577405.1142634732776.JavaMail.dmarkman@mac.com> <441B4182.8010407@willicon.de> <92CD0D6C-5BE8-426E-A46D-99452059FF49@mac.com> <441BBB2D.8030305@willicon.de> <441C4088.5090905@willicon.de> <64BC1E23-FDDE-4CE6-8863-CFC881CBC224@mac.com> <247EB61F-5CD1-4132-89A2-FC105B6CF9A5@spacestar.net> Message-ID: Hi, Michael all I have to do is to run some shell script I tried to use your action mechanism and it worked great so I just System.setProperty ("authkit.action","" ) and after that I even don't need to run anything like subject.doAs.... but after few thoughts I choose to use plain Greg's approach, because in that case I don't have to deal with various java's configurations files and therefore to use 2-3 -D parameters in the java command line especially it's useful for java web start (it's so fragile :-( ) thanks for the great job On Mar 20, 2006, at 7:25 AM, Michael Hall wrote: > > On Mar 20, 2006, at 1:20 AM, Dmitry Markman wrote: >> >> Michael Hall (mikehall at spacestar dot net) had a suggestion to >> make implementation of the jaas LoginModule >> based on Greg's AuthKit >> (his modification of the Greg's AuthKit could be found at http:// >> www.spacestar.net/users/mikehall/authkit.dmg) >> but Michael's AuthKitLoginModule does only half a job: >> it does authenticate >> but it can not run any external unix process in privileged mode >> (at least I wasn't able to do so) > > If you got it working directly with Greg's the point is moot. > > But to clarify it anyhow. > The login module does not allow you to do anything anything > privileged on return as was explained by Greg. You need to work > with a separate privileged process using the execPrivileged method > of his API. I assume you did something similar although I haven't > looked at how you are using it yet. > I allowed instead for a action to be performed at the same time you > login/authenticate,this... > System.setProperty("authkit.action","/usr/bin/id"); > just before this... > lc.login(); > To clarify, safely ignored as you are already complete. > > Mike Hall mikehall at spacestar dot net > http://www.spacestar.net/users/mikehall > http://sourceforge.net/projects/macnative > > > Dmitry Markman From dmarkman at mac.com Mon Mar 20 07:44:45 2006 From: dmarkman at mac.com (Dmitry Markman) Date: Mon, 20 Mar 2006 09:44:45 -0500 Subject: [Rxtx] Mac OS X RXTX java installer In-Reply-To: References: <07D0DE29-BA32-4CFE-B036-66BC6423D385@buechse.de> <441AE3E0.2030503@willicon.de> <12531986.1142622114996.JavaMail.dmarkman@mac.com> <441B2674.9010409@willicon.de> <13577405.1142634732776.JavaMail.dmarkman@mac.com> <441B4182.8010407@willicon.de> <92CD0D6C-5BE8-426E-A46D-99452059FF49@mac.com> <441BBB2D.8030305@willicon.de> <441C4088.5090905@willicon.de> <64BC1E23-FDDE-4CE6-8863-CFC881CBC224@mac.com> Message-ID: it's in the commapi-0-0-1 branch I tested it right now: cvs co -r commapi-0-0-1 rxtx-devel and I got everything On Mar 20, 2006, at 9:25 AM, Trent Jarvi wrote: > On Mon, 20 Mar 2006, Dr. Douglas Lyon wrote: > >> Hi Trent, >> Thanks for the info on the CVS checkout procedure. >> I did that and am still not sure where the installer is. > > Hi Doug > > It does look like it was not cvs committed. There is no rxtx-devel/ > contrib/MacOSX directory in there at the moment. It was mentioned > that it was put under contrib. > > -- > Trent Jarvi > tjarvi at qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx Dmitry Markman From tjarvi at qbang.org Mon Mar 20 07:52:57 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 20 Mar 2006 07:52:57 -0700 (MST) Subject: [Rxtx] Mac OS X RXTX java installer In-Reply-To: References: <07D0DE29-BA32-4CFE-B036-66BC6423D385@buechse.de> <441AE3E0.2030503@willicon.de> <12531986.1142622114996.JavaMail.dmarkman@mac.com> <441B2674.9010409@willicon.de> <13577405.1142634732776.JavaMail.dmarkman@mac.com> <441B4182.8010407@willicon.de> <92CD0D6C-5BE8-426E-A46D-99452059FF49@mac.com> <441BBB2D.8030305@willicon.de> <441C4088.5090905@willicon.de> <64BC1E23-FDDE-4CE6-8863-CFC881CBC224@mac.com> Message-ID: On Mon, 20 Mar 2006, Dmitry Markman wrote: > it's in the commapi-0-0-1 branch > > I tested it right now: > cvs co -r commapi-0-0-1 rxtx-devel > > and I got everything > A fresh checkout worked. Here is a copy of the tree (just the installer bits) ftp://ftp.qbang.org/pub/rxtx/MacOSX-installer.zip -- Trent Jarvi tjarvi at qbang.org From lyon at docjava.com Mon Mar 20 08:08:26 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Mon, 20 Mar 2006 10:08:26 -0500 Subject: [Rxtx] Mac OS X RXTX java installer In-Reply-To: References: <07D0DE29-BA32-4CFE-B036-66BC6423D385@buechse.de> <441AE3E0.2030503@willicon.de> <12531986.1142622114996.JavaMail.dmarkman@mac.com> <441B2674.9010409@willicon.de> <13577405.1142634732776.JavaMail.dmarkman@mac.com> <441B4182.8010407@willicon.de> <92CD0D6C-5BE8-426E-A46D-99452059FF49@mac.com> <441BBB2D.8030305@willicon.de> <441C4088.5090905@willicon.de> <64BC1E23-FDDE-4CE6-8863-CFC881CBC224@mac.com> Message-ID: Hi All, Is the Auth package able to work properly on non Mac OS's? It was not clear from the doc or download. Thanks! - Doug From dmarkman at mac.com Mon Mar 20 08:15:22 2006 From: dmarkman at mac.com (Dmitry Markman) Date: Mon, 20 Mar 2006 10:15:22 -0500 Subject: [Rxtx] Mac OS X RXTX java installer In-Reply-To: References: <07D0DE29-BA32-4CFE-B036-66BC6423D385@buechse.de> <441AE3E0.2030503@willicon.de> <12531986.1142622114996.JavaMail.dmarkman@mac.com> <441B2674.9010409@willicon.de> <13577405.1142634732776.JavaMail.dmarkman@mac.com> <441B4182.8010407@willicon.de> <92CD0D6C-5BE8-426E-A46D-99452059FF49@mac.com> <441BBB2D.8030305@willicon.de> <441C4088.5090905@willicon.de> <64BC1E23-FDDE-4CE6-8863-CFC881CBC224@mac.com> Message-ID: <217312D8-CCCA-4859-ABA6-32DF1CC817B9@mac.com> thanks Trent, for putting it on ftp server On Mar 20, 2006, at 9:52 AM, Trent Jarvi wrote: > A fresh checkout worked. Here is a copy of the tree (just the > installer bits) > > ftp://ftp.qbang.org/pub/rxtx/MacOSX-installer.zip > Dmitry Markman From dmarkman at mac.com Mon Mar 20 09:14:03 2006 From: dmarkman at mac.com (Dmitry Markman) Date: Mon, 20 Mar 2006 11:14:03 -0500 Subject: [Rxtx] Mac OS X RXTX java installer In-Reply-To: References: <07D0DE29-BA32-4CFE-B036-66BC6423D385@buechse.de> <441AE3E0.2030503@willicon.de> <12531986.1142622114996.JavaMail.dmarkman@mac.com> <441B2674.9010409@willicon.de> <13577405.1142634732776.JavaMail.dmarkman@mac.com> <441B4182.8010407@willicon.de> <92CD0D6C-5BE8-426E-A46D-99452059FF49@mac.com> <441BBB2D.8030305@willicon.de> <441C4088.5090905@willicon.de> <64BC1E23-FDDE-4CE6-8863-CFC881CBC224@mac.com> Message-ID: <4DEBA6F0-DA45-4E84-823E-1F1AC48BDCCC@mac.com> no it will work only on mac os x however it's harmless to run it on other platform if you want to use it for other platform you have to do the following (I'll do it for linux) 1. modify RXTXInstaller class method public static RXTXInstaller getInstance() public static RXTXInstaller getInstance() { String osName = System.getProperty("os.name").toLowerCase(); if(osName.startsWith("mac")){ return new gnu.io.installer.macosx.MACOSXRXTXInstaller(); } else if(osName.startsWith("windows")){ return new gnu.io.installer.windows.WindowsRXTXInstaller(); }else if(osName.startsWith("linux")){ return new gnu.io.installer.linux.LinuxRXTXInstaller(); } return null; } 2. create folder gnu/io/installer/linux/ 3. create class Linux386RXTXInstaller package gnu.io.installer.linux; import java.io.File; public class Linux386RXTXInstaller extends gnu.io.installer.RXTXInstaller{ public Linux386RXTXInstaller(){ createJarFolder(); createLibFolder(); addJarResource("RXTXcomm.jar","/gnu/io/installer/resources/ linux/jar/RXTXcomm.dat"); addLibResource("librxtxSerial.so","/gnu/io/installer/ resources/linux/lib/librxtxSerial.so"); } protected void createJarFolder(){ String javaHome = System.getProperty("java.home"); char separator = File.separatorChar; jarFolder = new File(javaHome+separator+"lib"+separator+"ext"); } protected void createLibFolder(){ String javaHome = System.getProperty("java.home"); char separator = File.separatorChar; libFolder = new File(javaHome+separator+"bin"); } public void runPreProcess() {} //put here some action you need public void runPostProcess() {} //put here some action you need } 4. create folder /gnu/io/installer/resources/linux/jar and put there linux's version of RXTXcomm.dat (which is renamed RXTXcomm.jar) 5. create folder /gnu/io/installer/resources/linux/lib and put there linux's version of librxtxSerial. so 6. make sure that RXTXInstaller.jar has the following items: /gnu/io/installer/resources/linux/jar/RXTXcomm.jar /gnu/io/installer/resources/linux/lib/librxtxSerial.so 7. modify file installer.pref: jar file RXTXInstaller.jar must have the following item /gnu/io/installer/installer.pref that's basically it for windows you have to do the similar things: just replace linux to windows and librxtxSerial.so to rxtxSerial.dll and create appropriate gnu.io.installer.windows.WindowsRXTXInstaller class package gnu.io.installer.windows; import java.io.File; public class WindowsRXTXInstaller extends gnu.io.installer.RXTXInstaller{ public WindowsRXTXInstaller(){ createJarFolder(); createLibFolder(); addJarResource("RXTXcomm.jar","/gnu/io/installer/resources/ windows/jar/RXTXcomm.dat"); addLibResource("librxtxSerial.so","/gnu/io/installer/ resources/windows/lib/rxtxSerial.dll"); } protected void createJarFolder(){ String javaHome = System.getProperty("java.home"); char separator = File.separatorChar; jarFolder = new File(javaHome+separator+"lib"+separator+"ext"); } protected void createLibFolder(){ String javaHome = System.getProperty("java.home"); char separator = File.separatorChar; libFolder = new File(javaHome+separator+"bin"); } public void runPreProcess() {} //put here some action you need public void runPostProcess() {} //put here some action you need } installer.pref will look like On Mar 20, 2006, at 10:08 AM, Dr. Douglas Lyon wrote: > Hi All, > Is the Auth package able to work properly on > non Mac OS's? > It was not clear from the doc or download. > > Thanks! > - Doug > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx Dmitry Markman From joachim at buechse.de Mon Mar 20 10:49:06 2006 From: joachim at buechse.de (Joachim Buechse) Date: Mon, 20 Mar 2006 18:49:06 +0100 Subject: [Rxtx] BUG: Lock file stays even if port opening fails Message-ID: This was only tested on MacOSX but looking at the code, it should be true for all systems that use lock_uucp. I am opening a port which can not be opened (dialup port of a telephone paired via bluetooth but currently not reachable). The lock file is created and stays arround, even though the port open failed. After looking a bit through the code (of 2.17), I really wonder if it wouldn't be a good idea to make the "locking" an explicit operation called from the java code. This would certainly simplify the generation of meaningfull exceptions (and java based debugging). Maybe even the handling of "preopened" ports should be in the Java part of the lib (again for java based debugging puposes). That beeing said, I have no idea if this would be possible for the 2.07 implementation. Regards, Joachim From tjarvi at qbang.org Mon Mar 20 11:24:22 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 20 Mar 2006 11:24:22 -0700 (MST) Subject: [Rxtx] BUG: Lock file stays even if port opening fails In-Reply-To: References: Message-ID: On Mon, 20 Mar 2006, Joachim Buechse wrote: > This was only tested on MacOSX but looking at the code, it should be true > for all systems that use lock_uucp. > > I am opening a port which can not be opened (dialup port of a telephone > paired via bluetooth but currently not reachable). The lock file is > created and stays arround, even though the port open failed. > > > After looking a bit through the code (of 2.17), I really wonder if it > wouldn't be a good idea to make the "locking" an explicit operation > called from the java code. This would certainly simplify the generation > of meaningfull exceptions (and java based debugging). > Maybe even the handling of "preopened" ports should be in the Java part > of the lib (again for java based debugging puposes). That beeing said, I > have no idea if this would be possible for the 2.07 implementation. > > Regards, Hi Joachim It should be possible in the 2.0-7 implementation too. The calls to RXTXPort.java would not change. We would just do more there Moving more of that logic into Java would be better as many people don't like to look at C code. There is a liblockdev on most Linux distros that can do most of the C code and would be easier to use. The problem is embeded devices will not have that library. The preopened port code has not been really tested. That was a last minute request in a product cycle. I expect it will be tested this year though. As I recall, some devices really do not like CD raising on open. The preopened ports then allow people to mess around in java without power cycling the devices or losing data. -- Trent Jarvi tjarvi at qbang.org From joachim at buechse.de Mon Mar 20 12:01:08 2006 From: joachim at buechse.de (Joachim Buechse) Date: Mon, 20 Mar 2006 20:01:08 +0100 Subject: [Rxtx] BUG: Lock file stays even if port opening fails In-Reply-To: References: Message-ID: Hi Trent, What is your general feeling about moving code to Java? The last days I have been reading quite a bit of the code and there are several things, that might not work as expected. I'll give you two examples from is_device_locked: if LOCKDIR == /var/spool/locks the directory /var/spool/lock will not be checked. LOCKDIR is not checked for lockfiles with unexpected pefixes While these things have probably never been discovered in production, they are still possibly incorrect implementations. If it was Java code, I would write some unit tests producing the errors that could later be corrected. PS: One could imagine to actually implement the whole lockfile handling in Java using some native routines to get the values required (pid, st_dev, st_rdev, ...). On 20.03.2006, at 19:24, Trent Jarvi wrote: > On Mon, 20 Mar 2006, Joachim Buechse wrote: > >> This was only tested on MacOSX but looking at the code, it should >> be true for all systems that use lock_uucp. >> >> I am opening a port which can not be opened (dialup port of a >> telephone paired via bluetooth but currently not reachable). The >> lock file is created and stays arround, even though the port open >> failed. >> >> >> After looking a bit through the code (of 2.17), I really wonder if >> it wouldn't be a good idea to make the "locking" an explicit >> operation called from the java code. This would certainly simplify >> the generation of meaningfull exceptions (and java based debugging). >> Maybe even the handling of "preopened" ports should be in the Java >> part of the lib (again for java based debugging puposes). That >> beeing said, I have no idea if this would be possible for the 2.07 >> implementation. >> >> Regards, > > Hi Joachim > > It should be possible in the 2.0-7 implementation too. The calls > to RXTXPort.java would not change. We would just do more there > Moving more of that logic into Java would be better as many people > don't like to look at C code. There is a liblockdev on most Linux > distros that can do most of the C code and would be easier to use. > The problem is embeded devices will not have that library. > > The preopened port code has not been really tested. That was a > last minute request in a product cycle. I expect it will be tested > this year though. As I recall, some devices really do not like CD > raising on open. The preopened ports then allow people to mess > around in java without power cycling the devices or losing data. > > -- > Trent Jarvi > tjarvi at qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Mon Mar 20 12:21:02 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 20 Mar 2006 12:21:02 -0700 (MST) Subject: [Rxtx] BUG: Lock file stays even if port opening fails In-Reply-To: References: Message-ID: On Mon, 20 Mar 2006, Joachim Buechse wrote: > Hi Trent, > > What is your general feeling about moving code to Java? The last days I > have been reading quite a bit of the code and there are several things, > that might not work as expected. > > I'll give you two examples from is_device_locked: > > if LOCKDIR == /var/spool/locks the directory /var/spool/lock will not be > checked. > LOCKDIR is not checked for lockfiles with unexpected pefixes > > While these things have probably never been discovered in production, > they are still possibly incorrect implementations. If it was Java code, I > would write some unit tests producing the errors that could later be > corrected. > > PS: One could imagine to actually implement the whole lockfile handling > in Java using some native routines to get the values required (pid, > st_dev, st_rdev, ...). Hi Joachim I like the idea of moving more of the code into java but there are some things to consider. If you break this into multiple JNI calls, the performance will drop considerably during enumeration of ports. We are looking for 256 ports per dev type vs (16? in Sun's 2.0 and fewer types). Its hard to make assumptions. I've seen virtual ports start at /dev/foo100 for instance. It works out to over 7500 ports on Linux if you enable them all. We already trim that back by default. See Linux-all-ports in RXTXCommDriver.java. There are also native libraries that rxtx can link to. If you move too much into Java, linking to 'standard' libraries with distros will break. "configure --enable-liblock=yes" will not be doable. This is probably a favorable way with RedHat, Debian, Suse and others. Thats the right thing to do if there will be rpms, dpkg, .. For those reasons, I think it still make sense to keep it to a minimal ~3 calls to JNI code that we can use for speed and versatility. lock() isLocked(), unlock() perhaps. When I say speed, its more about avoiding crossing the JNI layer multiple times than java vs C performance. With versatility I think liblock is the right way for most but not all (embeded) linux distros. -- Trent Jarvi tjarvi at qbang.org From joachim at buechse.de Mon Mar 20 12:42:04 2006 From: joachim at buechse.de (Joachim Buechse) Date: Mon, 20 Mar 2006 20:42:04 +0100 Subject: [Rxtx] BUG: Lock file stays even if port opening fails In-Reply-To: References: Message-ID: <82C19FE7-DDCB-45B6-B2C9-7606B66F0124@buechse.de> Ok, what about providing a default implementation in Java? The RXTXCommDriver would call a (native) function useNativeLocking and if it returns true, call the native functions for lock() isLocked (), unlock(), else is would use the Java based default implementation. This could possibly be overriden by a property (again for debugging). Joachim On 20.03.2006, at 20:21, Trent Jarvi wrote: > On Mon, 20 Mar 2006, Joachim Buechse wrote: > >> Hi Trent, >> >> What is your general feeling about moving code to Java? The last >> days I have been reading quite a bit of the code and there are >> several things, that might not work as expected. >> >> I'll give you two examples from is_device_locked: >> >> if LOCKDIR == /var/spool/locks the directory /var/spool/lock will >> not be checked. >> LOCKDIR is not checked for lockfiles with unexpected pefixes >> >> While these things have probably never been discovered in >> production, they are still possibly incorrect implementations. If >> it was Java code, I would write some unit tests producing the >> errors that could later be corrected. >> >> PS: One could imagine to actually implement the whole lockfile >> handling in Java using some native routines to get the values >> required (pid, st_dev, st_rdev, ...). > > Hi Joachim > > I like the idea of moving more of the code into java but there are > some things to consider. > > If you break this into multiple JNI calls, the performance will > drop considerably during enumeration of ports. We are looking for > 256 ports per dev type vs (16? in Sun's 2.0 and fewer types). Its > hard to make assumptions. I've seen virtual ports start at /dev/ > foo100 for instance. > > It works out to over 7500 ports on Linux if you enable them all. > We already trim that back by default. See Linux-all-ports in > RXTXCommDriver.java. > > There are also native libraries that rxtx can link to. If you move > too much into Java, linking to 'standard' libraries with distros > will break. "configure --enable-liblock=yes" will not be doable. > This is probably a favorable way with RedHat, Debian, Suse and > others. Thats the right thing to do if there will be rpms, dpkg, .. > > For those reasons, I think it still make sense to keep it to a > minimal ~3 calls to JNI code that we can use for speed and > versatility. lock() isLocked(), unlock() perhaps. When I say > speed, its more about avoiding crossing the JNI layer multiple > times than java vs C performance. With versatility I think liblock > is the right way for most but not all (embeded) linux distros. > > -- > Trent Jarvi > tjarvi at qbang.org > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Mon Mar 20 12:44:47 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 20 Mar 2006 12:44:47 -0700 (MST) Subject: [Rxtx] BUG: Lock file stays even if port opening fails In-Reply-To: <82C19FE7-DDCB-45B6-B2C9-7606B66F0124@buechse.de> References: <82C19FE7-DDCB-45B6-B2C9-7606B66F0124@buechse.de> Message-ID: On Mon, 20 Mar 2006, Joachim Buechse wrote: > Ok, what about providing a default implementation in Java? > > The RXTXCommDriver would call a (native) function useNativeLocking and if > it returns true, call the native functions for lock() isLocked(), > unlock(), else is would use the Java based default implementation. This > could possibly be overriden by a property (again for debugging). > Hi Joachim That would be OK with me. -- Trent Jarvi tjarvi at qbang.org From dmarkman at mac.com Mon Mar 20 22:27:45 2006 From: dmarkman at mac.com (Dmitry Markman) Date: Tue, 21 Mar 2006 00:27:45 -0500 Subject: [Rxtx] binaries request Message-ID: <42702213-C222-4937-A585-7CFB17E47608@mac.com> Hi can somebody send me latest linux and windows binaries, please? or where I can find them (I didn't find them in the latest tareball) I gave up with my cygwin: something wrong I have no idea what java doesn't understand /cygwin/c syntax after I changed makefile it did java part but after that gcc 3.4.4 started to complain I set buffer length to 999 lines but I didn't get beginning of the story something wrong with my 1.4.2_09/include/jni.h gcc doesn't like it anyway I gave up thanks in advance Dmitry Markman -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060320/f8cbc57c/attachment-0043.html From tjarvi at qbang.org Mon Mar 20 22:36:48 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 20 Mar 2006 22:36:48 -0700 (MST) Subject: [Rxtx] binaries request In-Reply-To: <42702213-C222-4937-A585-7CFB17E47608@mac.com> References: <42702213-C222-4937-A585-7CFB17E47608@mac.com> Message-ID: On Tue, 21 Mar 2006, Dmitry Markman wrote: > Hi > can somebody send me latest linux and windows binaries, please? > > or where I can find them (I didn't find them in the latest tareball) > > I gave up with my cygwin: something wrong I have no idea what > java doesn't understand /cygwin/c syntax > after I changed makefile it did java part > but after that gcc 3.4.4 started to complain > I set buffer length to 999 lines but I didn't get beginning of the story > something wrong with my 1.4.2_09/include/jni.h gcc doesn't like it > anyway I gave up > > thanks in advance > Hi Dmitry The bins are here: ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7-bins-r2.zip Here are the files in the zip you want. Jar: rxtx-2.1-7-bins-r2/RXTXcomm.jar Windows: rxtx-2.1-7-bins-r2/Windows/i368-mingw32/rxtxSerial.dll Linux (x86) rxtx-2.1-7-bins-r2/Linux/i686-unknown-linux-gnu/librxtxSerial.so There are others in there including Parallel port support but those are the main ones for testing. -- Trent Jarvi tjarvi at qbang.org From dmarkman at mac.com Mon Mar 20 23:05:59 2006 From: dmarkman at mac.com (Dmitry Markman) Date: Tue, 21 Mar 2006 01:05:59 -0500 Subject: [Rxtx] binaries request In-Reply-To: References: <42702213-C222-4937-A585-7CFB17E47608@mac.com> Message-ID: thank you very much but windows's readme says: rxtxSerial.dll had to be recomopiled to link in missing native methods. should I ignore it? or what? thanks again also I understand that I should use mingw not cygwin I'll try to install mingw On Mar 21, 2006, at 12:36 AM, Trent Jarvi wrote: > On Tue, 21 Mar 2006, Dmitry Markman wrote: > >> Hi >> can somebody send me latest linux and windows binaries, please? >> >> or where I can find them (I didn't find them in the latest tareball) >> >> I gave up with my cygwin: something wrong I have no idea what >> java doesn't understand /cygwin/c syntax >> after I changed makefile it did java part >> but after that gcc 3.4.4 started to complain >> I set buffer length to 999 lines but I didn't get beginning of the >> story >> something wrong with my 1.4.2_09/include/jni.h gcc doesn't like it >> anyway I gave up >> >> thanks in advance >> > > Hi Dmitry > > The bins are here: > > ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7-bins-r2.zip > > Here are the files in the zip you want. > > Jar: > > rxtx-2.1-7-bins-r2/RXTXcomm.jar > > Windows: > > rxtx-2.1-7-bins-r2/Windows/i368-mingw32/rxtxSerial.dll > > Linux (x86) > > rxtx-2.1-7-bins-r2/Linux/i686-unknown-linux-gnu/librxtxSerial.so > > There are others in there including Parallel port support but those > are the main ones for testing. > > -- > Trent Jarvi > tjarvi at qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx Dmitry Markman From tjarvi at qbang.org Mon Mar 20 23:20:33 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 20 Mar 2006 23:20:33 -0700 (MST) Subject: [Rxtx] binaries request In-Reply-To: References: <42702213-C222-4937-A585-7CFB17E47608@mac.com> Message-ID: On Tue, 21 Mar 2006, Dmitry Markman wrote: > thank you very much > > but windows's readme says: > rxtxSerial.dll had to be recomopiled to link in missing native methods. > > should I ignore it? or what? > Hi Dmitry That dll should be OK. r2 is the recompile linked to the missing native method. The readme explains why it was recompiled; fuser.o was not linked into the dll in the first release. -- Trent Jarvi tjarvi at qbang.org From ariantristan at yahoo.com Mon Mar 20 23:55:24 2006 From: ariantristan at yahoo.com (Lambok Sianturi) Date: Mon, 20 Mar 2006 22:55:24 -0800 (PST) Subject: [Rxtx] jvm issue Message-ID: <20060321065524.94779.qmail@web50701.mail.yahoo.com> Hi All, This is my first time to join RxTx mailing list. I thank you all for allowing others to sign in in requests help. I use the latest RxTx lib in Fedora 3 with java version 1.4.2_09 b05. And I got this error: # # An unexpected error has been detected by HotSpot Virtual Machine: # # SIGSEGV (0xb) at pc=0x00bf27f3, pid=2633, tid=3086112448 # # Java VM: Java HotSpot(TM) Client VM (1.4.2_09-b05 mixed mode) # Problematic frame: # C [ld-linux.so.2+0xa7f3] # # An error report file with more information is saved as hs_err_pid2633.log # # If you would like to submit a bug report, please visit: # http://java.sun.com/webapps/bugreport/crash.jsp # ./run.sh: line 3: 2633 Aborted /usr/local/java/bin/java -Djava.library.path=/usr/local/java/jre/lib/ -Djsmsengine.debug=true -classpath jsmsengine.jar:smsgateway.jar:classes12.jar:RXTXcomm.jar:. com.api.sms.SMSServer What is the jvm depedency for the latest library? Can I use 1.4.2_09 b05? Thanks in advance. Arian --------------------------------- Yahoo! Mail Use Photomail to share photos without annoying attachments. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060320/83d58dd7/attachment-0043.html From f.frumento at ngi.it Tue Mar 21 00:21:47 2006 From: f.frumento at ngi.it (Fabio Frumento) Date: Tue, 21 Mar 2006 08:21:47 +0100 Subject: [Rxtx] Javadoc on the go Message-ID: <441FA98B.9050701@ngi.it> Hi Trent, sorry for the big delay but my job is running wild, i was out for some time but now i'm back and ready to continue the javadoc for Rxtx. Did you used the last javadoc patch i sent you ? let me know if i have to send it to you again or not. regards Fabio From lyon at docjava.com Tue Mar 21 00:51:18 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Tue, 21 Mar 2006 02:51:18 -0500 Subject: [Rxtx] lock files Message-ID: Hi All, You know, if the use of lock files were under Java control (rather than a build-time decision), it might enable a more unified binary distro. It might also facilitate quick prototyping of non-lock file approaches to resolving serial port contention issues (i.e., mac-like approaches vs. linux approaches, etc.). I realize that this is a radical overhaul of the lock file policy issue. Also, it may harm performance. On the other hand, our benchmarks on JNI overhead for modern processors indicate performance impact should be minimal. Perhaps it is more of an issue with the toybox systems. Suppose there were a class with a reasonable default...someone might write: SerialPortLockPolicy.setPolicy(SerialPortLockPolicy.UNIX_LOCK_FILE); SerialPortLockPolicy.setPolicy(SerialPortLockPolicy.NO_LOCK_CHECKING); SerialPortLockPolicy.setPolicy(SerialPortLockPolicy.MAC_STYLE); Thus, we could have a run-time reconfiguration of the serial port lock policy. A special NO_LOCK version of the binary would no longer be required. Any thoughts on this? Thanks! - Doug From joachim at buechse.de Tue Mar 21 03:09:09 2006 From: joachim at buechse.de (Joachim Buechse) Date: Tue, 21 Mar 2006 11:09:09 +0100 Subject: [Rxtx] lock files In-Reply-To: References: Message-ID: <8E12916A-1B9A-4FF2-B684-E2D1C794221B@buechse.de> This is pretty much what I thought about when I suggested, that the default behaviour could be overwritten with a property. I am very much in favor of this approach. In particular this allows much easier debugging for PC based java developers. I think big parts of the Java (and maybe some parts of the C code) could use a bit of a structural workover (unit tests, javadoc, synchronization, etc). Maybe there should be a CVS branch for this experimental version. I'd be happy to contribute a first workover for some of the Java code. Designing for testability and implementing a good bunch of unit tests has been a strategy that worked quite well in the Java projects I lead. And it ultimately allows more liberal change permission. Regards, Joachim On 21.03.2006, at 08:51, Dr. Douglas Lyon wrote: > Hi All, > You know, if the use of lock files were > under Java control (rather than a build-time decision), > it might enable a more unified binary distro. It might also > facilitate quick prototyping of non-lock file approaches > to resolving serial port contention issues (i.e., mac-like > approaches vs. linux approaches, etc.). > > I realize that this is a radical overhaul of the lock file policy > issue. Also, it may harm performance. On the other hand, > our benchmarks on JNI overhead for modern processors indicate > performance impact should be minimal. Perhaps it is more of > an issue with the toybox systems. > > Suppose there were a class with a reasonable default...someone > might write: > SerialPortLockPolicy.setPolicy(SerialPortLockPolicy.UNIX_LOCK_FILE); > SerialPortLockPolicy.setPolicy(SerialPortLockPolicy.NO_LOCK_CHECKING); > SerialPortLockPolicy.setPolicy(SerialPortLockPolicy.MAC_STYLE); > > Thus, we could have a run-time reconfiguration of the serial port lock > policy. A special NO_LOCK version of the binary would no longer > be required. > > Any thoughts on this? > > Thanks! > - Doug > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From joachim at buechse.de Tue Mar 21 06:23:08 2006 From: joachim at buechse.de (Joachim Buechse) Date: Tue, 21 Mar 2006 14:23:08 +0100 Subject: [Rxtx] PATCH: use of ioctl(fd, TIOCEXCL) instead of lockfiles Message-ID: <923AE774-EEA2-4911-92D8-32BB27802C8B@buechse.de> Here is the patch for the ioctl(fd, TIOCEXCL). I have verified this only for OSX 10.4.5, hence it is only defined for APPLE. However, it should work at least for Solaris as well. If a process has requested TIOEXCL further open calls by other user processes will fail. The patch also disables uucp style locking for APPLE. Obviously this is discussable. I think it is the way to go, as it eliminates creating the lock directory which doesnt exist on the standard installation and it eliminates messing with the system group definitions (adding users to group uucp). Regarding the possibility of root processes opening a device which is locked - I consider this a feature not a potential problem. It is highly unlikely, that somebody is crazy enough to run a JavaVM as root (unless he has no other means of getting a restricted IP port opened, ie doesnt understand ipfw). Anyway, even if the process runs as root, it fails when calling ioctl(fd, TIOCEXCL). It could however still open the port to listen for RING events. I.e. a fax server which needs to see incoming calls but otherwise doesnt want to block the port. So the only case where the proposed mechanism fails is, if an incorrectly implemented process running as root conflicts with a user process. I think this can be accepted. Regards, Joachim PS: If this patch is generally accepted, the installer and Mac doku should obviously be changed as well. Index: SerialImp.c =================================================================== RCS file: /usr/local/cvsroot/rxtx-devel/src/SerialImp.c,v retrieving revision 1.46.2.187 diff -u -r1.46.2.187 SerialImp.c --- SerialImp.c 29 Jan 2006 22:19:04 -0000 1.46.2.187 +++ SerialImp.c 21 Mar 2006 12:59:16 -0000 @@ -656,6 +656,25 @@ fd=OPEN (filename, O_RDWR | O_NOCTTY | O_NONBLOCK ); } while (fd < 0 && errno==EINTR); +#ifdef OPEN_EXCL + // Note that open() follows POSIX semantics: multiple open() calls to + // the same file will succeed unless the TIOCEXCL ioctl is issued. + // This will prevent additional opens except by root-owned processes. + // See tty(4) ("man 4 tty") and ioctl(2) ("man 2 ioctl") for details. + + if (fd >= 0 && (ioctl(fd, TIOCEXCL) == -1)) + { + sprintf( message, "open: exclusive access denied for % s\n", + filename ); + report( message ); + report_error( message ); + + close(fd); + goto fail; + } +#endif /* OPEN_EXCL */ + + if( configure_port( fd ) ) goto fail; (*env)->ReleaseStringUTFChars( env, jstr, filename ); sprintf( message, "open: fd returned is %i\n", fd ); Index: SerialImp.h =================================================================== RCS file: /usr/local/cvsroot/rxtx-devel/src/SerialImp.h,v retrieving revision 1.11.2.49 diff -u -r1.11.2.49 SerialImp.h --- SerialImp.h 5 Jul 2005 17:47:21 -0000 1.11.2.49 +++ SerialImp.h 21 Mar 2006 12:59:17 -0000 @@ -135,7 +135,8 @@ /*# define LOCKDIR "/var/spool/uucp"*/ # define LOCKDIR "/var/lock" # define LOCKFILEPREFIX "LK." -# define UUCP +/*# define UUCP*/ +# define OPEN_EXCL #endif /* __APPLE__ */ #if defined(__NetBSD__) # define DEVICEDIR "/dev/" From tjarvi at qbang.org Tue Mar 21 10:26:08 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 21 Mar 2006 10:26:08 -0700 (MST) Subject: [Rxtx] Javadoc on the go In-Reply-To: <441FA98B.9050701@ngi.it> References: <441FA98B.9050701@ngi.it> Message-ID: On Tue, 21 Mar 2006, Fabio Frumento wrote: > Hi Trent, > > sorry for the big delay but my job is running wild, i was out for some > time but now i'm back and ready to continue the javadoc for Rxtx. > > Did you used the last javadoc patch i sent you ? let me know if i have to > send it to you again or not. > > regards > > Fabio Hi Fabio The patch is in the rxtx mail-list archives. It will be going in soon. I did not see a time critical portion. I'll probably be going through the list since the last batch of patches this weekend and putting them into CVS. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Tue Mar 21 10:57:18 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 21 Mar 2006 10:57:18 -0700 (MST) Subject: [Rxtx] jvm issue In-Reply-To: <20060321065524.94779.qmail@web50701.mail.yahoo.com> References: <20060321065524.94779.qmail@web50701.mail.yahoo.com> Message-ID: On Mon, 20 Mar 2006, Lambok Sianturi wrote: > Hi All, > This is my first time to join RxTx mailing list. I thank you all for allowing others to sign in in requests help. > I use the latest RxTx lib in Fedora 3 with java version 1.4.2_09 b05. And I got this error: > > # > # An unexpected error has been detected by HotSpot Virtual Machine: > # > # SIGSEGV (0xb) at pc=0x00bf27f3, pid=2633, tid=3086112448 > # > # Java VM: Java HotSpot(TM) Client VM (1.4.2_09-b05 mixed mode) > # Problematic frame: > # C [ld-linux.so.2+0xa7f3] A native library loading error? What happens if you recompile rxtx on your system and install that? This sounds like an ABI problem? rxtx 2.1-7 was compiled with a gcc 2.96 toolchain as I recall. The hope is newer system will be backwards compatible. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Tue Mar 21 11:05:29 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 21 Mar 2006 11:05:29 -0700 (MST) Subject: [Rxtx] PATCH: use of ioctl(fd, TIOCEXCL) instead of lockfiles In-Reply-To: <923AE774-EEA2-4911-92D8-32BB27802C8B@buechse.de> References: <923AE774-EEA2-4911-92D8-32BB27802C8B@buechse.de> Message-ID: On Tue, 21 Mar 2006, Joachim Buechse wrote: > Here is the patch for the ioctl(fd, TIOCEXCL). I have verified this only > for OSX 10.4.5, hence it is only defined for APPLE. However, it should > work at least for Solaris as well. > > If a process has requested TIOEXCL further open calls by other user > processes will fail. > > The patch also disables uucp style locking for APPLE. Obviously this is > discussable. I think it is the way to go, as it eliminates creating the > lock directory which doesnt exist on the standard installation and it > eliminates messing with the system group definitions (adding users to > group uucp). > > Regarding the possibility of root processes opening a device which is > locked - I consider this a feature not a potential problem. It is highly > unlikely, that somebody is crazy enough to run a JavaVM as root (unless > he has no other means of getting a restricted IP port opened, ie doesnt > understand ipfw). Anyway, even if the process runs as root, it fails when > calling ioctl(fd, TIOCEXCL). It could however still open the port to > listen for RING events. I.e. a fax server which needs to see incoming > calls but otherwise doesnt want to block the port. So the only case where > the proposed mechanism fails is, if an incorrectly implemented process > running as root conflicts with a user process. I think this can be > accepted. > > Regards, > Joachim > > PS: If this patch is generally accepted, the installer and Mac doku > should obviously be changed as well. > > > Index: SerialImp.c > =================================================================== > RCS file: /usr/local/cvsroot/rxtx-devel/src/SerialImp.c,v > retrieving revision 1.46.2.187 > diff -u -r1.46.2.187 SerialImp.c > --- SerialImp.c 29 Jan 2006 22:19:04 -0000 1.46.2.187 > +++ SerialImp.c 21 Mar 2006 12:59:16 -0000 > @@ -656,6 +656,25 @@ > fd=OPEN (filename, O_RDWR | O_NOCTTY | O_NONBLOCK ); > } while (fd < 0 && errno==EINTR); > > +#ifdef OPEN_EXCL > + // Note that open() follows POSIX semantics: multiple open() > calls to > + // the same file will succeed unless the TIOCEXCL ioctl is > issued. > + // This will prevent additional opens except by root-owned > processes. > + // See tty(4) ("man 4 tty") and ioctl(2) ("man 2 ioctl") for > details. > + > + if (fd >= 0 && (ioctl(fd, TIOCEXCL) == -1)) > + { > + sprintf( message, "open: exclusive access denied for % > s\n", > + filename ); > + report( message ); > + report_error( message ); > + > + close(fd); > + goto fail; > + } > +#endif /* OPEN_EXCL */ > + > + > if( configure_port( fd ) ) goto fail; > (*env)->ReleaseStringUTFChars( env, jstr, filename ); > sprintf( message, "open: fd returned is %i\n", fd ); > Index: SerialImp.h > =================================================================== > RCS file: /usr/local/cvsroot/rxtx-devel/src/SerialImp.h,v > retrieving revision 1.11.2.49 > diff -u -r1.11.2.49 SerialImp.h > --- SerialImp.h 5 Jul 2005 17:47:21 -0000 1.11.2.49 > +++ SerialImp.h 21 Mar 2006 12:59:17 -0000 > @@ -135,7 +135,8 @@ > /*# define LOCKDIR "/var/spool/uucp"*/ > # define LOCKDIR "/var/lock" > # define LOCKFILEPREFIX "LK." > -# define UUCP > +/*# define UUCP*/ > +# define OPEN_EXCL > #endif /* __APPLE__ */ > #if defined(__NetBSD__) > # define DEVICEDIR "/dev/" > This looks like a good start. What do you think Dmitry? Perhaps all systems with TIOCEXCL defined should use that though. Even if they use lockfiles. It wont hurt anything. That would catch people hacking their own serial apps without checking lockfiles. Its a good idea to avoid C++ style comments in the C portions. Some older systems don't deal with them well. If it's just for Mac OS X, it isn't a big deal. I think it was the Irix compiler that was problematic? -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Tue Mar 21 11:22:05 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 21 Mar 2006 11:22:05 -0700 (MST) Subject: [Rxtx] lock files In-Reply-To: <8E12916A-1B9A-4FF2-B684-E2D1C794221B@buechse.de> References: <8E12916A-1B9A-4FF2-B684-E2D1C794221B@buechse.de> Message-ID: We can try it. Maybe the JNI is much improved. The nice thing about linking into liblock is distros then worry about lockfiles on their systems. This way, we have to deal with any changes that may show up. On Tue, 21 Mar 2006, Joachim Buechse wrote: > This is pretty much what I thought about when I suggested, that the > default behaviour could be overwritten with a property. I am very much in > favor of this approach. In particular this allows much easier debugging > for PC based java developers. > > I think big parts of the Java (and maybe some parts of the C code) could > use a bit of a structural workover (unit tests, javadoc, synchronization, > etc). Maybe there should be a CVS branch for this experimental version. > I'd be happy to contribute a first workover for some of the Java code. > Designing for testability and implementing a good bunch of unit tests has > been a strategy that worked quite well in the Java projects I lead. And > it ultimately allows more liberal change permission. > > Regards, > Joachim > > > On 21.03.2006, at 08:51, Dr. Douglas Lyon wrote: > >> Hi All, >> You know, if the use of lock files were >> under Java control (rather than a build-time decision), >> it might enable a more unified binary distro. It might also >> facilitate quick prototyping of non-lock file approaches >> to resolving serial port contention issues (i.e., mac-like >> approaches vs. linux approaches, etc.). >> >> I realize that this is a radical overhaul of the lock file policy >> issue. Also, it may harm performance. On the other hand, >> our benchmarks on JNI overhead for modern processors indicate >> performance impact should be minimal. Perhaps it is more of >> an issue with the toybox systems. >> >> Suppose there were a class with a reasonable default...someone >> might write: >> SerialPortLockPolicy.setPolicy(SerialPortLockPolicy.UNIX_LOCK_FILE); >> SerialPortLockPolicy.setPolicy(SerialPortLockPolicy.NO_LOCK_CHECKING); >> SerialPortLockPolicy.setPolicy(SerialPortLockPolicy.MAC_STYLE); >> >> Thus, we could have a run-time reconfiguration of the serial port lock >> policy. A special NO_LOCK version of the binary would no longer >> be required. >> >> Any thoughts on this? >> >> Thanks! >> - Doug >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From dmarkman at mac.com Tue Mar 21 16:05:17 2006 From: dmarkman at mac.com (Dmitry Markman) Date: Tue, 21 Mar 2006 18:05:17 -0500 Subject: [Rxtx] PATCH: use of ioctl(fd, TIOCEXCL) instead of lockfiles In-Reply-To: References: <923AE774-EEA2-4911-92D8-32BB27802C8B@buechse.de> Message-ID: <512AC70C-BB86-48F2-A83C-023F35C23BAB@mac.com> I think it's cool, but I'd like to have that property implementation when user can choose between locking mechanism about comments: it's easy to change comments to the C style or we can use extensions of the file to cpp so c++ compiler will be used On Mar 21, 2006, at 1:05 PM, Trent Jarvi wrote: > This looks like a good start. What do you think Dmitry? Perhaps > all systems with TIOCEXCL defined should use that though. Even if > they use lockfiles. It wont hurt anything. That would catch > people hacking their own serial apps without checking lockfiles. > > Its a good idea to avoid C++ style comments in the C portions. > Some older systems don't deal with them well. If it's just for Mac > OS X, it isn't a big deal. I think it was the Irix compiler that > was problematic? Dmitry Markman From dmarkman at mac.com Tue Mar 21 16:13:00 2006 From: dmarkman at mac.com (Dmitry Markman) Date: Tue, 21 Mar 2006 18:13:00 -0500 Subject: [Rxtx] PATCH: use of ioctl(fd, TIOCEXCL) instead of lockfiles In-Reply-To: References: <923AE774-EEA2-4911-92D8-32BB27802C8B@buechse.de> Message-ID: I'd like to add that creating locking folder isn't a big deal we never had a problem related to the lock folders, because we always used installer on mac os x from other hand I'm not very much familiar with iotcl locking approach and I'm not sure it's more efficient Joachim wrote "I think it is the way to go, as it eliminates creating the lock directory which doesnt exist on the standard installation and it eliminates messing with the system group definitions (adding users to group uucp)." but I really didn't have any problem with that 1. doesn't exist on the standard installation there are many-many things that don't exist in the standard installation so I don't think that argument is strong enough 2. messing with the system group definitions I don't think we're messing with the group definition mac os x provides very clear way to set up group's members and together with Greg Guerin AuthKit there is no problem to set those definitions so I don't think that argument is strong either but from other hand using iotcl is more promising and is more elegant On Mar 21, 2006, at 1:05 PM, Trent Jarvi wrote: > > This looks like a good start. What do you think Dmitry? Perhaps > all systems with TIOCEXCL defined should use that though. Even if > they use lockfiles. It wont hurt anything. That would catch > people hacking their own serial apps without checking lockfiles. Dmitry Markman From joachim at buechse.de Wed Mar 22 04:46:45 2006 From: joachim at buechse.de (Joachim Buechse) Date: Wed, 22 Mar 2006 12:46:45 +0100 Subject: [Rxtx] PATCH: use of ioctl(fd, TIOCEXCL) instead of lockfiles In-Reply-To: References: <923AE774-EEA2-4911-92D8-32BB27802C8B@buechse.de> Message-ID: Sorry, I was not very clear with my arguments, so I will try again;-) Please, don't take this as an attack against work that has been done. I think the contributions that have been made in the past were made in a good spirit. But I really believe, that the current solution for OSX has many shortcomings and should be changed as soon as possible. lock files --- The /var/lock folder does not exist on the standard OSX installation, however the standard installation includes several applications that use serial ports (i.e. the FAX capability). This indicates, that the lock folder approach will not work well with system components. Applications for OSX will generally try to live in harmony with system components (except for HP print drivers of course). I think RXTX should follow this approach as well. uucp group --- Accessing serial ports is not an admin privileged operation on OSX. Any user (world) has read/write privileges on /dev/tty*. So the system default is to not enforce any group membership to access these ports. The group uucp however is a system group on all unix systems I know. It exists for certain system processes. A non admin user should in general not be a member of this group. Quite arguably no user should ever be a member of this group. Installer --- My general opinion is, that - no Installer should touch user or group data without warning - no Application Installer should touch groups which are not specific to the very application installed - no Installer should ever add regular users to a system group The current installer injects the installing user in the group uucp without warning about this change and without giving the option to "opt out" of this change. This is a potential security risk (but not currently a real one, as OSX contains no folders belonging to group uucp). The current installer does not work for multi user systems. It puts the installing user in the uucp group. However the installing user is not necessarily the user that will use the application. Putting all users that may use a serial port application in the system group uucp seems like a very invasive approach to me. Besides that, newly created users will not automatically be in the group and hence, serial applications will "break" for new users without obvious reasons. Avoiding the lock files will allow self contained applications (i.e. drag&drop installation). In my eyes this is largely preferable over an installer that requests admin privileges. Adding up all these points indicates very strongly, that the lock-file implementation is not the way to go on OSX. Regards, Joachim On 22.03.2006, at 00:13, Dmitry Markman wrote: > I'd like to add that > > creating locking folder isn't a big deal > we never had a problem related to the lock folders, because we > always used installer on mac os x > from other hand I'm not very much familiar with iotcl locking > approach and I'm not sure it's more efficient > > Joachim wrote "I think it is the way to go, as it eliminates > creating the lock directory which doesnt exist on the standard > installation and it eliminates messing with the system group > definitions (adding users to group uucp)." but I really didn't have > any problem with that > > 1. doesn't exist on the standard installation > there are many-many things that don't exist in the standard > installation so I don't think that argument is strong enough > 2. messing with the system group definitions > I don't think we're messing with the group definition > mac os x provides very clear way to set up group's members and > together with Greg Guerin AuthKit there is no problem to set those > definitions > so I don't think that argument is strong either > but from other hand using iotcl is more promising and is more elegant > > > > On Mar 21, 2006, at 1:05 PM, Trent Jarvi wrote: > >> >> This looks like a good start. What do you think Dmitry? Perhaps >> all systems with TIOCEXCL defined should use that though. Even if >> they use lockfiles. It wont hurt anything. That would catch >> people hacking their own serial apps without checking lockfiles. > > Dmitry Markman > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From dmarkman at mac.com Wed Mar 22 05:27:13 2006 From: dmarkman at mac.com (Dmitry Markman) Date: Wed, 22 Mar 2006 07:27:13 -0500 Subject: [Rxtx] PATCH: use of ioctl(fd, TIOCEXCL) instead of lockfiles In-Reply-To: References: <923AE774-EEA2-4911-92D8-32BB27802C8B@buechse.de> Message-ID: <83440CF3-DCD8-41C1-B941-F227232C27E3@mac.com> thanks for the very good explanation I didn't think that you were attacking any thing, so don't worry I just had feeling, that there were more aesthetic reasons for going to ioctl then real necessity now you explained everything quite well (BTW, asfar as I remember installer asks admin password so it wasn't quiet, but it really doesn't matter now) thanks On Mar 22, 2006, at 6:46 AM, Joachim Buechse wrote: > Sorry, I was not very clear with my arguments, so I will try again;-) > > Please, don't take this as an attack against work that has been > done. I think the contributions that have been made in the past > were made in a good spirit. But I really believe, that the current > solution for OSX has many shortcomings and should be changed as > soon as possible. > > lock files > --- > The /var/lock folder does not exist on the standard OSX > installation, however the standard installation includes several > applications that use serial ports (i.e. the FAX capability). This > indicates, that the lock folder approach will not work well with > system components. Applications for OSX will generally try to live > in harmony with system components (except for HP print drivers of > course). I think RXTX should follow this approach as well. > > uucp group > --- > Accessing serial ports is not an admin privileged operation on OSX. > Any user (world) has read/write privileges on /dev/tty*. So the > system default is to not enforce any group membership to access > these ports. The group uucp however is a system group on all unix > systems I know. It exists for certain system processes. A non admin > user should in general not be a member of this group. Quite > arguably no user should ever be a member of this group. > > Installer > --- > My general opinion is, that > - no Installer should touch user or group data without warning > - no Application Installer should touch groups which are not > specific to the very application installed > - no Installer should ever add regular users to a system group > > The current installer injects the installing user in the group uucp > without warning about this change and without giving the option to > "opt out" of this change. This is a potential security risk (but > not currently a real one, as OSX contains no folders belonging to > group uucp). > > The current installer does not work for multi user systems. It puts > the installing user in the uucp group. However the installing user > is not necessarily the user that will use the application. Putting > all users that may use a serial port application in the system > group uucp seems like a very invasive approach to me. Besides that, > newly created users will not automatically be in the group and > hence, serial applications will "break" for new users without > obvious reasons. > > > Avoiding the lock files will allow self contained applications > (i.e. drag&drop installation). In my eyes this is largely > preferable over an installer that requests admin privileges. Adding > up all these points indicates very strongly, that the lock-file > implementation is not the way to go on OSX. > > Regards, > Joachim > > > On 22.03.2006, at 00:13, Dmitry Markman wrote: > >> I'd like to add that >> >> creating locking folder isn't a big deal >> we never had a problem related to the lock folders, because we >> always used installer on mac os x >> from other hand I'm not very much familiar with iotcl locking >> approach and I'm not sure it's more efficient >> >> Joachim wrote "I think it is the way to go, as it eliminates >> creating the lock directory which doesnt exist on the standard >> installation and it eliminates messing with the system group >> definitions (adding users to group uucp)." but I really didn't >> have any problem with that >> >> 1. doesn't exist on the standard installation >> there are many-many things that don't exist in the standard >> installation so I don't think that argument is strong enough >> 2. messing with the system group definitions >> I don't think we're messing with the group definition >> mac os x provides very clear way to set up group's members and >> together with Greg Guerin AuthKit there is no problem to set those >> definitions >> so I don't think that argument is strong either >> but from other hand using iotcl is more promising and is more elegant >> >> >> >> On Mar 21, 2006, at 1:05 PM, Trent Jarvi wrote: >> >>> >>> This looks like a good start. What do you think Dmitry? Perhaps >>> all systems with TIOCEXCL defined should use that though. Even >>> if they use lockfiles. It wont hurt anything. That would catch >>> people hacking their own serial apps without checking lockfiles. >> >> Dmitry Markman >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx Dmitry Markman From lyon at docjava.com Wed Mar 22 06:12:18 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Wed, 22 Mar 2006 08:12:18 -0500 Subject: [Rxtx] sole of a new design pattern Message-ID: Hi All, I have been thinking about how we design the serial port software. I think we need a new design pattern. For lack of a better term, I shall call it: The Parametric Singleton Design Pattern By Douglas A. Lyon ABSTRACT The goal of the singleton design pattern is to make sure that there is one, and only one, instance of a given class. The goal of the parametric singleton design pattern is to make sure that there is one, and only one, instance of a given class with the given parametric values. We parametric singleton design pattern combines the singleton design pattern with a parameter that enables unique creation of instances of a class. These instances are cached. When a user asks for an instance with these parameters, the cache is checked. If the instance is in the cache, the instance is returned, otherwise it is created, added to the cache and then returned. We apply our parametric singleton design pattern to the retrieval of RMI registries bound to a given port. The goal of our system is to make sure that no two RMI registries are listening to the same socket and to make use of the RMI registries after they have been created. RMI registries are used in distributed computation. Introduction The singleton design pattern is meant to ensure that on a single instance of a class exists. It is also meant to provide a global point of access to it. The intent of the parametric singleton design pattern is to ensure that a class has only one instance for a given set of parameter values. It also provides a global point of access to it. Motivation A system cannot tolerate multiple instances of some classes with identical parameters. For example, you cannot have two instances making use of the same serial port, at the same time. You cannot have two instances that are trying to listen to the same socket connection. You cannot have two instances writing to the same file structure at the same time. As the operating system is often thought of as the arbiter of consumed resources (i.e., tape drives, serial ports, etc.) we frequently leave it to an operating system implementation to resolve these contention issues. Even for similar resources (like serial ports) there are few standards for handling contention. For example, serial ports on Linux are locked using a "/var/lock" file. POSIX, on the other hand, uses ioctl mechanisms to prevent contention. A better solution is to make a class that is responsible for keeping track of the instances created from the class. The class is declared final, so that it cannot be subclassed. The class also has a private constructor, so that other classes cannot instance it. The new design pattern is called the parametric singleton design pattern and it provides a way to access and create instances with given parameters. Applicability Use the Parametric Singleton Design Pattern when: 1. There must be exactly one instance of a class with the given parameters. 2. The instances must be accessible to clients from a well-known access point. Structure Insert UML diagram here. Participants The Parametric Singleton Clients that need instances 1. The Parametric Singleton defines an instance upon request from a client, if, and only if, the instance does not already exist. 2. The Parametric Singleton returns the instance to the client. 3. The Parametric Singleton is responsible for creating unique instances from given parameters. Collaborations Clients obtain a reference to a Parametric Singleton instance only through the parametric singleton design pattern. If the instance is left in an improper state (e.g., the serial port was left open) it is NOT the role of the Parametric Singleton Design Pattern to close the IO port. Nor is it the role of the Parametric Singleton Design Pattern to open the port. That role is delegate to some other part of the system. Further, it is not the role of the Parametric Singleton Design Pattern to check out resources. That is, multiple threads can have multiple references to the same resource at the same time. MUTEX locking is delegated to some other part of the system. Consequences The Parametric Singleton Design Pattern has several benefits: 1. Controlled access to parametrically defined instances. Since the Parametric Singleton class encapsulates its instances, there is control over how and when clients access it. 2. Reduced name space. The Parametric Singleton pattern avoids global variables that store instances created from the same parameter. Implementation Here are implementation issues to consider when using the Parametric Singleton pattern: 1. Unique mapping of parameters. The Parametric Singleton pattern requires that there be a mean to isomorphically map the parameter space into the instance space and back again. 2. Ensure unique instances. The Parametric Singleton pattern makes unique instances from parameters, and it does so only once. 3. Cache instances for fast retrieval. The Parametric Singleton pattern must be able to look up instances, given some set of parameters, and do so from some data structure. That is, there must be enough space to hold references to all the instances the program will need. Also, a mechanism is needed to look up and retrieve the instances quickly enough to satisfy the clients. Sample Code public final class ParametricSingletonRmiRegistry { private static Hashtable registry = new Hashtable(100); // use singleton pattern and??????????????????????????????????????????????? // prevent instantiation of RmiRegistryUtils.?????????????????????????????? private ParametricSingletonRmiRegistry() { } // the only instance of the Registry held by the RmiRegistryUtils?????????? public static void listNames(Integer port) { if (!isInCacheAndRunning(port)) return; Registry r = (Registry) registry.get(port); System.out.println("registry on port: " + port); System.out.println("registry: " + r); System.out.println("names: "); try { print(r.list()); } catch (RemoteException e) { In.message(e); } System.out.println("------------------------"); } /**???????????????????????????????????????????????????????????????????????? * Checks whether a Registry has been started on this host????????????????? * in the specified port.?????????????????????????????????????????????????? * If not, it tries to start one.?????????????????????????????????????????? * when it fails to start a Registry, it exits the program????????????????? * with exit code 1.??????????????????????????????????????????????????????? */ public static void restart(int port) { if (isInCacheAndRunning(port)) return; try { startRegistry(port); } catch (RemoteException e) { In.message(e); } } /**???????????????????????????????????????????????????????????????????????? * @param port????????????????????????????????????????????????????????????? * @return true if registry is in cache and running???????????????????????? */ private static boolean isInCacheAndRunning(Integer port) { if (!isRegistryRunning(port.intValue())) return false; if (!isRegistryInCache(port.intValue())) return false; return true; } /**???????????????????????????????????????????????????????????????????????? * @param port????????????????????????????????????????????????????????????? * @return true if we are able to locate a local registry on port.??????????????????????????????????????????????????????????????????????????? */ private static boolean isRegistryRunning(int port) { try { Registry r = LocateRegistry.getRegistry(port); if (r != null) return true; } catch (RemoteException e) { return false; } return false; } /**???????????????????????????????????????????????????????????????????????? * @param port????????????????????????????????????????????????????????????? * @return return true if registry is in cache????????????????????????????? */ private static boolean isRegistryInCache(int port) { if (registry.get(new Integer(port)) == null) return false; return true; } /**???????????????????????????????????????????????????????????????????????? * Restart the registry, if needed.???????????????????????????????????????? * Return the only instance of the registry for consistent global?????????? * using by making use of the Singleton Design Pattern????????????????????? *????????????????????????????????????????????????????????????????????????? * @return the internally held registry instance.?????????????????????????? */ public static Registry getRegistry(Integer port) { restart(port); return (Registry) registry.get(port); } private static void startRegistry(Integer port) throws RemoteException { Registry r; try { r = LocateRegistry.createRegistry(port.intValue()); registry.put(port, r); //r = new sun.rmi.registry.RegistryImpl???????????????????????????? /// (port.intValue());?????????????????????????????????????? // registry.put(port, r);?????????????????????????????????????????? } catch (Exception e) { //e.printStackTrace();????????????????????????????????????????????? r = LocateRegistry.getRegistry(port.intValue()); registry.put(port, r); } } public static void main(String args[]) throws RemoteException { //restart(port);??????????????????????????????????????????????????????? restart(5001); restart(5002); restart(5002); Registry r = LocateRegistry.getRegistry(5002); System.out.println("registry="+r); } } I would very much like to get your feedback on this new design pattern idea. Thank you for your time. Regards, - Doug From david.garnier at trusted-logic.com Wed Mar 22 07:36:10 2006 From: david.garnier at trusted-logic.com (David Garnier) Date: Wed, 22 Mar 2006 15:36:10 +0100 Subject: [Rxtx] sole of a new design pattern In-Reply-To: References: Message-ID: <442160DA.80107@trusted-logic.com> Hello, > The Parametric Singleton Design Pattern The Singleton is the most abused design pattern ever. Good use-cases for this pattern are extremely rare and mostly confined to problems related to hardware resources, like serial ports. > Applicability > > Use the Parametric Singleton Design Pattern when: > 1. There must be exactly one instance of a class with the given > parameters. OK. As I said above, this case this actually very unusual. The Singleton pattern is mostly used when : > 2. The instances must be accessible to clients from a well-known > access point. Using the singleton pattern in this case is just convenient for the programmer. Problems arises pretty quickly, especially if you attempt to unit-test your classes. 1) If your singleton is stateful, or hold on to stateful objects, it means that two different unit tests are not actually independent. Instead of starting with a brand new environment, the result of a test may be affected by the result of a previous test. This problem also arise when with your class relies on a database. In both cases, the solution is to reset your "unique" resource (Singleton or database) at the beginning of the test, which is a pain. Also, while most projects connect to a single database, projects that allow the use of Singletons usually contain several of thems, and new ones may cropped up unnoticed. You quickly end up with test cases that only pass in a certain order, which is a royal pain. 2) You cannot mockup a singleton. Once everyone calls the SomeSingleton class statically, you can't replace your class by SomeSingletonMockup. Furthermore, even for hardware services, the Singleton pattern does not really prevent concurrent accesses. If you start the same program in two different JVMs, unless they somehow shared the state of their "Singletons" (through lock files for example), the Singleton pattern will not prevent concurrent access. Our application uses RXTX, and we routinely encounter cases where another (native) application has already locked the port. Since we cannot modify the native application to recognize lock files, OS-level control is irreplaceable. > > Consequences > The Parametric Singleton Design Pattern has several benefits: > > 1. Controlled access to parametrically defined instances. Since > the Parametric Singleton class encapsulates its instances, there is > control over how and when clients access it. Not really. Once you've returned the instance to a client, you've lost control over it. The client can to whatever it wants with it. You cannot "recall" the instance or claim it back. > 2. Reduced name space. The Parametric Singleton pattern avoids > global variables that store instances created from the same parameter. Sure, but you don't have to rely on a Singleton for that. Just create a single Factory. > I would very much like to get your feedback on this new design > pattern idea. Well, it's nothing new. Some may say that it is the point of design patterns: formalizes the designs that occur again and again. However, this design is simply a combination of the Singleton and Factory patterns. I did use it in the past, but now I've been exposed to the shortcomings of the Singleton pattern, so I limit myself to Factories. Regards, David From sean_montgomery at baseview.com Wed Mar 22 08:35:28 2006 From: sean_montgomery at baseview.com (Sean Montgomery) Date: Wed, 22 Mar 2006 10:35:28 -0500 Subject: [Rxtx] sole of a new design pattern In-Reply-To: <442160DA.80107@trusted-logic.com> References: <442160DA.80107@trusted-logic.com> Message-ID: <05769CA7-A51B-4CF0-BAA0-E02DD905F5A4@baseview.com> On Mar 22, 2006, at 9:36 AM, David Garnier wrote: > Furthermore, even for hardware services, the Singleton pattern does > not really prevent concurrent > accesses. If you start the same program in two different JVMs, > unless they somehow shared the state > of their "Singletons" (through lock files for example), the > Singleton pattern will not prevent > concurrent access. > Multiple class loaders in a single JVM can be tricky, too. Then there's synchronization, lazy initialization and serialization of singletons to contend with. Bloch's Effective Java covers these, and here's a few articles: http://www.javaworld.com/javaworld/jw-04-2003/jw-0425-designpatterns- p3.html http://java.sun.com/developer/technicalArticles/Programming/singletons/ Just FYI :-) From lyon at docjava.com Wed Mar 22 08:50:48 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Wed, 22 Mar 2006 10:50:48 -0500 Subject: [Rxtx] sole of a new design pattern In-Reply-To: <442160DA.80107@trusted-logic.com> References: <442160DA.80107@trusted-logic.com> Message-ID: Hi All, First, I would like to thank David for his prompt and thoughtful remarks. I had no idea people that feel strongly about a design patterns! Wow! Feedback (particularly critical feedback) is greatly appreciated. Starting at the end, first: >I did use it in >the past, but now I've been exposed to the shortcomings of the >Singleton pattern, so I limit myself to Factories. David, if I understood your comments correctly, you suggested that Factories can be used in leu of the Singleton Design Pattern, or even the Parametric Singleton Design Pattern. As I see in [Gof]: Factory Method: Intent "Define an interface for creating an object, but let subclasses decide which class to instantiate. Factory Method lets a class defer instantiation to subclasses." The Singleton Design Pattern is a concrete class, which is rather different, right? Also, subclasses are not permitted with Singleton, as they are final. Naturally, I could use an abstract factory as a parent for a singleton. I could even design a facade that could be implemented with the singleton....but that is not the intention of the design. Unless you want a mock-up, as discussed, below: More below: >Hello, > >> The Parametric Singleton Design Pattern > >The Singleton is the most abused design pattern ever. Good use-cases >for this pattern are extremely >rare and mostly confined to problems related to hardware resources, >like serial ports. > > >> Applicability >> >> Use the Parametric Singleton Design Pattern when: >> 1. There must be exactly one instance of a class with the given >> parameters. >OK. As I said above, this case this actually very unusual. The >Singleton pattern is mostly used when : >> 2. The instances must be accessible to clients from a well-known >> access point. > >Using the singleton pattern in this case is just convenient for the >programmer. Problems arises >pretty quickly, especially if you attempt to unit-test your classes. > >1) If your singleton is stateful, or hold on to stateful objects, it >means that two different unit >tests are not actually independent. Instead of starting with a brand >new environment, the result of >a test may be affected by the result of a previous test. This >problem also arise when with your >class relies on a database. In both cases, the solution is to reset >your "unique" resource >(Singleton or database) at the beginning of the test, which is a >pain. Also, while most projects >connect to a single database, projects that allow the use of >Singletons usually contain several of >thems, and new ones may cropped up unnoticed. You quickly end up >with test cases that only pass in a >certain order, which is a royal pain. There are basic problems with communicating finite state machines that include reachability and deadlock analysis. These are addressed with petri net analysis and are beyond the scope of the design pattern. As you quite rightly pointed out; the parametric singleton pattern (or the singleton pattern, for that matter) enable multiple threads to gain access to the same instance. The only way that I can see to block others from gaining access to the reference is the synchronize keyword. This is putting a spin-lock (or MUTEX) on the reference. The question of how to unit-test a design pattern like the parametric singleton remains open. Perhaps this is a deficiency. > >2) You cannot mockup a singleton. Once everyone calls the >SomeSingleton class statically, you can't >replace your class by SomeSingletonMockup. Acutally, I am not sure that this is true. If the Singleton implements a Facade interface, it should be possible to make the replacement. Right? > >Furthermore, even for hardware services, the Singleton pattern does >not really prevent concurrent >accesses. If you start the same program in two different JVMs, >unless they somehow shared the state >of their "Singletons" (through lock files for example), the >Singleton pattern will not prevent >concurrent access. Good Point!! You have sharp eyes! The singleton design pattern should/could take responsibility for this. In fact, you may notice that my code does have an implementation (LocateRegistry) that can work across JVM's. The LocateRegistry will even work across the Internet! LocateRegistry takes both a host name and a Port (lock files just don't do this). I did not think to implement this beyond the local machine, but, in its present form, it will work across different processes. > >Our application uses RXTX, and we routinely encounter cases where >another (native) application has >already locked the port. Since we cannot modify the native >application to recognize lock files, >OS-level control is irreplaceable. The singleton design pattern is not meant to replace OS-level control, but to centralize the Java programmers access to it. If lock files, for example, are used for serial ports, the Singleton Design Pattern should be able to work with them. > > >> >> Consequences >> The Parametric Singleton Design Pattern has several benefits: >> > > 1. Controlled access to parametrically defined instances. Since >> the Parametric Singleton class encapsulates its instances, there is >> control over how and when clients access it. > >Not really. Once you've returned the instance to a client, you've >lost control over it. The client >can to whatever it wants with it. You cannot "recall" the instance >or claim it back. Good point, this should read: > 1. Controll when parametrically defined instances are created. Since > > the Parametric Singleton class encapsulates its instances, there is > > control over how and when they are instanced. > >> 2. Reduced name space. The Parametric Singleton pattern avoids >> global variables that store instances created from the same parameter. > >Sure, but you don't have to rely on a Singleton for that. Just >create a single Factory. > > Thank you for your thoughtful and prompt response! Regards, - Doug From dmarkman at mac.com Wed Mar 22 21:21:55 2006 From: dmarkman at mac.com (Dmitry Markman) Date: Wed, 22 Mar 2006 23:21:55 -0500 Subject: [Rxtx] sole of a new design pattern In-Reply-To: <442160DA.80107@trusted-logic.com> References: <442160DA.80107@trusted-logic.com> Message-ID: I don't think I get it On Mar 22, 2006, at 9:36 AM, David Garnier wrote: > Using the singleton pattern in this case is just convenient for the > programmer. Problems arises > pretty quickly, especially if you attempt to unit-test your classes. so you're saying that something isn't so good because you can not test it in the convenient way? if that's true, I'm totally disagree change your test, debug whatever, but if software is efficient at runtime, works fine and only problem is some unit test (which is some kind of framework for testing) then dump that unit test , dump that unit framework and make something appropriate to the software you're testing so if Douglas want to use singletons, what's the problem? and what do you mean by abusing of singleton usage? of course singleton doesn't prevent concurrent access to the resource across the processes unless you're using some OS facility to prevent it, besides singleton as it was introduced is relevant only and only inside of the same process otherwise it's not singleton it's something else (let's say network singleton: so you have remote invocation facility and some factory method that return object created by that facility) I don't have any problem with using any kind of singletons. Parametric Singleton idea (if I understand it right) could be easily implemented in the following way: use a map populate map with instances of some class and key is your parameter (you can use lazy population too) if somebody ask the key check the value if it's null so resource is taken if somebody returns the resource put it back to the map public synchronized static Object getSomeResource(Object parameter); public synchronized static void returnResource(Object parameter); getSomeResource (inside of the same process) could return null in 2 cases 1. if somebody (from other thread for example) already took that resource 2. if OS API said that resource corresponded to that parameter (serial port with parameter = 1 (port #)) is locked and unavailable; I'm not sure that in case of serial ports we even need those Parametric Singletons (unless lock checking is a very expensive operation) just ask the OS about availability of that resource and if it's available give it away and then OS will lock it and therefore in next time somebody ask it just answer that resource is locked and return null for example system has 2 serial ports available so I ask getResource("tty"); or I ask getResource("Bluetooth-Modem"); and if OS is ok you can give tty or Bluetooth-Modem or both no need for any additional pattern I think back to the problem mac os x doesn't recognize locking via files, so it handles locking via some API an instance of the singleton in each process should recognize that resource is locked (by using that API) that's all we don't have to make things more complicate then they are just because there is some nice design pattern or nice unit test framework or whatever keep things simple, make them work fast, don't introduce middle layers unless you have really good reason to do so of course I could be entirely wrong, so sorry about that in advance thanks Dmitry Markman From tjarvi at qbang.org Wed Mar 22 22:31:41 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 22 Mar 2006 22:31:41 -0700 (MST) Subject: [Rxtx] sole of a new design pattern In-Reply-To: References: Message-ID: Hi Doug Interesting reading. So far I'm just reading and thinking. I have one question so far. " Clients obtain a reference to a Parametric Singleton instance only through the parametric singleton design pattern. If the instance is left in an improper state (e.g., the serial port was left open) it is NOT the role of the Parametric Singleton Design Pattern to close the IO port. Nor is it the role of the Parametric Singleton Design Pattern to open the port. That role is delegate to some other part of the system. " So when the clients obtain a reference to the singleton, can they assume the port is there? IE, would it be the singletons role to handle things like USB dongles being removed with event hints comming from the underlying OS. Hardware abstraction layer/HAL on Linux is an example of underlying OS events. I assume that role too is delegated to other parts of the system? -- Trent Jarvi tjarvi at qbang.org From lyon at docjava.com Thu Mar 23 08:10:33 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Thu, 23 Mar 2006 10:10:33 -0500 Subject: [Rxtx] Classes don't need goals, they need roles! In-Reply-To: References: Message-ID: Hi Trent, Yes, I think that the role of the Parametric Singleton Pattern is not to open or close serial ports, nor is it to perform error checking. On the other hand, if you were to combine the role of the Parametric Singleton Pattern with another role (like that of error checking) it might not be amiss. However, I generally caution programmers against adding multiple roles to classes, as this leads to monolithic designs. Thus a different class (NativeLibDetect) could have the role of determining if the native library can be loaded. Another class (SerialPortBean) can have the role of serializing the default state of the serial port, so that it can be recovered, from user preferences, at a later time. The SerialPortDetect could have the role of determining if the serial port is removed (i.e., a USB port was unplugged). My guess is that each class should have a different role in the system, in order to ease maintenance and testing...but I could be wrong about that. Thanks! - Doug >Hi Doug > >Interesting reading. So far I'm just reading and thinking. I have >one question so far. > >" > Clients obtain a reference to a Parametric Singleton instance only >through the parametric singleton design pattern. If the instance is >left in an improper state (e.g., the serial port was left open) it is >NOT the role of the Parametric Singleton Design Pattern to close the >IO port. Nor is it the role of the Parametric Singleton Design Pattern >to >open the port. That role is delegate to some other part of the system. >" > >So when the clients obtain a reference to the singleton, can they >assume the port is there? IE, would it be the singletons role to >handle things like USB dongles being removed with event hints >comming from the underlying OS. Hardware abstraction layer/HAL on >Linux is an example of underlying OS events. > >I assume that role too is delegated to other parts of the system? > >-- >Trent Jarvi >tjarvi at qbang.org >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From maximulo at yahoo.com Fri Mar 24 01:22:38 2006 From: maximulo at yahoo.com (Maximulo Majir) Date: Fri, 24 Mar 2006 00:22:38 -0800 (PST) Subject: [Rxtx] JavaPOS Message-ID: <20060324082238.66371.qmail@web38214.mail.mud.yahoo.com> Hi all! Hello Trent! From what i understand, RXTX or JavaComm APIs were not created solely for JavaPOS. In JavaPOS, we have the virtual method claim() which is separate from open(), but in our RXTX API, claiming is done every call to open(), we cant open the port if its claimed by another application. Would it be alright to suggest or ask to create a new method called claim(..)? Is there such thing as forceclaim() in RXTX? this could be the same as portownership transfer or its equivalent. ForceClaim is in JSR80. Do you have some samples using RXTX as the lower layer for the Device Service Objects in JavaPOS? I have tried it, i just want to compare. Thank you all! maxim __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060324/496adba2/attachment-0043.html From tjarvi at qbang.org Fri Mar 24 11:28:19 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 24 Mar 2006 11:28:19 -0700 (MST) Subject: [Rxtx] Re: RXTX 2.1 Solaris Problems In-Reply-To: <3691.1143210578@www045.gmx.net> References: <3691.1143210578@www045.gmx.net> Message-ID: On Fri, 24 Mar 2006, Andreas Guenther wrote: > Hi all, > > the solaris problem was not the lock file only. > > Ok, I had to create the directory /var/spool/locks myself. > /var/spool/uucp exists. > > But rxtx didn't find any port. > > I compiled the source with my own debug-informations > and I tried to isolate the problem. > > The problem is the testRead-call in SerialImp.c > > JNIEXPORT jboolean JNICALL RXTXCommDriver(testRead)( > > ... > if ( READ( fd, &c, 1 ) < 0 ) > { > if ( errno != EAGAIN ) { > report( "testRead() read failed\n" ); > ret = JNI_FALSE; > } > } > Thanks Andreas I'm packing up to move. I'll be more or less away for a couple weeks here. I'll be checking email but my workstation is going into a box soon. This isn't hard to fix as this port should be enumerated when EWOULDBLOCK is recieved. Thats error is OK for enumeration just as EAGAIN is. I've put the bug into bugzilla so we dont forget to get to it. http://bugzilla.qbang.org/show_bug.cgi?id=42 You can add yourself to the CC list if you wish to test fixes we provide or even put a patch into bugzilla yourself. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Fri Mar 24 11:51:52 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 24 Mar 2006 11:51:52 -0700 (MST) Subject: [Rxtx] JavaPOS In-Reply-To: <20060324082238.66371.qmail@web38214.mail.mud.yahoo.com> References: <20060324082238.66371.qmail@web38214.mail.mud.yahoo.com> Message-ID: On Fri, 24 Mar 2006, Maximulo Majir wrote: > Hi all! Hello Trent! > > > From what i understand, RXTX or JavaComm APIs were not > created solely for JavaPOS. In JavaPOS, we have the virtual method > claim() which is separate from open(), but in our RXTX API, claiming is > done every call to open(), we cant open the port if its claimed by > another application. Would it be alright to suggest or ask to create a > new method called claim(..)? Is there such thing as forceclaim() in > RXTX? this could be the same as portownership transfer or its > equivalent. ForceClaim is in JSR80. > Do you have some samples using RXTX as the lower layer for the Device > Service Objects in JavaPOS? I have tried it, i just want to compare. > maxim Hi Maxim JSR80 is the USB API IBM/Sun put together. The problem is they have a richer kernel/API underneath that can handle such things. With Serial Ports, there isnt anything there other than an ioctl that says don't let anyone touch this and lockfiles that are more of a 'lets be nice.' At times we may be using USB ports but it is through the termios layer with the limitations mentioned. The advantage is that not only USB will work with rxtx. Anything that has a termios layer should work (to the extent that termios layer is complete). I don't know how forceclaim() would help you. Lets say someone has a programmer working on /dev/ttyS0 and you take it. Now you both race each other to read data first. There isn't a mechanism I know of that will solve this problem in termios. The most obvious test being a native app and a Java app trying to take the port. There is the potential of requestion ownership from other Java Applications but the use for that is very rare. Did you have something more specific in mind that I'm missing? I'm not sure that claim() and forceclaim() would help you with rxtx other than maybe locking the port with claim() without opening it. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sat Mar 25 23:42:08 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 25 Mar 2006 23:42:08 -0700 (MST) Subject: [Rxtx] Serial snoop Message-ID: I was reading the Linux kernel mail-list tonight and ran past a thread that mentioned sersnoop. This looks like a handy tool for people dealing with new toys. "a simple command-line tool for linux that echoes bytes to and from any two serial ports, ptys, or network sockets, and prints all traffic to stdout, in hex and ascii." http://www.restivo.org/projects/sersnoop/ It works on Linux only at this time (debian package available). -- Trent Jarvi tjarvi at qbang.org From beat.arnet at gmail.com Sun Mar 26 07:32:35 2006 From: beat.arnet at gmail.com (Beat Arnet) Date: Sun, 26 Mar 2006 09:32:35 -0500 Subject: [Rxtx] Error 0x5 at /home/bob/foo/tar/rxtx-2.1-7/build/../src/termios.c(860): Access is, denied. Message-ID: <4426A603.80508@gmail.com> Dear all, When trying to open the serial port, I sometimes (not always) run into the following exception (when opening the serialPort): Error 0x5 at /home/bob/foo/tar/rxtx-2.1-7/build/../src/termios.c(860): Access is denied. java.lang.UnsatisfiedLinkError: native_psmisc_report_owner at gnu.io.CommPortIdentifier.native_psmisc_report_owner(Native Method) at gnu.io.CommPortIdentifier.open(CommPortIdentifier.java:354) at codeskin.tools.CLLoader.open(CLLoader.java:79) at codeskin.tools.C2000Programmer.run(C2000Programmer.java:220) at java.lang.Thread.run(Unknown Source) Is this the type of error where I should just try to open the port again, or can it be avoided? Regards, Beat From tjarvi at qbang.org Sun Mar 26 11:40:12 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 26 Mar 2006 11:40:12 -0700 (MST) Subject: [Rxtx] Error 0x5 at /home/bob/foo/tar/rxtx-2.1-7/build/../src/termios.c(860): Access is, denied. In-Reply-To: <4426A603.80508@gmail.com> References: <4426A603.80508@gmail.com> Message-ID: On Sun, 26 Mar 2006, Beat Arnet wrote: > Dear all, > > When trying to open the serial port, I sometimes (not always) run into > the following exception (when opening the serialPort): > > Error 0x5 at /home/bob/foo/tar/rxtx-2.1-7/build/../src/termios.c(860): > Access is > denied. > > java.lang.UnsatisfiedLinkError: native_psmisc_report_owner > at gnu.io.CommPortIdentifier.native_psmisc_report_owner(Native > Method) > at gnu.io.CommPortIdentifier.open(CommPortIdentifier.java:354) > at codeskin.tools.CLLoader.open(CLLoader.java:79) > at codeskin.tools.C2000Programmer.run(C2000Programmer.java:220) > at java.lang.Thread.run(Unknown Source) > > Is this the type of error where I should just try to open the port again, > or can it be avoided? > Hi Beat We did a second build of rxtx 2.1-7 to resolve that unsatisfied link error. It should work now. rxtx is trying to tell you it thinks someone else has the serial port open. You can try to open the port again but maybe you already have a copy of the program running when it happens? ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7r2.zip fixed build. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sun Mar 26 11:44:23 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 26 Mar 2006 11:44:23 -0700 (MST) Subject: [Rxtx] RXTX spec file (fwd) Message-ID: This is probably interesting for fedora/suse users. ---------- Forwarded message ---------- Date: Sun, 26 Mar 2006 16:25:45 +0200 To: taj at www.linux.org.uk Subject: RXTX spec file I send you this spec file which allows to create a RPM for Fedora 4, 5 (x86, x86_64) with Java Sun. -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: rxtx.spec Url: http://mailman.qbang.org/pipermail/rxtx/attachments/20060326/6c7b6af6/rxtx-0039.pl From tjarvi at qbang.org Sun Mar 26 23:42:59 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 26 Mar 2006 23:42:59 -0700 (MST) Subject: [Rxtx] Upcomming events. Message-ID: This Wednesday we will be announcing a new "Maintainer" for the rxtx project. The position is more like neutral leader. I wont be going away or doing less. This is just the right thing to do as it turns out the two people with CVS write access will be at the same company. We need a third and we need neutrality. The maintainer will have final say in any conflict and will try to be neutral. It will be open for discussion. Then we will do it :) I'll still do most of the footwork I do now. But. I'm falling behind. I should have gone through the mail-list and posted the next round of changes this weekend. I'm packing to move and its going so so - 13 years of toys collected. I suspect there will be a dead period on my part (a couple weeks) comming up. But if you get it on the mail-list, we will get it in if there are no objections. I may well not be reading the mail-list during this period as I look for a house and many other things. I hope everyone will help out. Thanks -- Trent Jarvi tjarvi at qbang.org From mahmoud_hadad at yahoo.com Sun Mar 26 07:31:19 2006 From: mahmoud_hadad at yahoo.com (ronan nick) Date: Sun, 26 Mar 2006 06:31:19 -0800 (PST) Subject: [Rxtx] a question about the COMM API Message-ID: <20060326143119.54919.qmail@web60014.mail.yahoo.com> hi, i was intrested in knowing how i can communicate with my internal modem using java? for example if i want to make a phone dialer application or a caller id application where should i be looking at? and as i understood the COMM API is for devices that is attached to the computer through serial ports. --------------------------------- New Yahoo! Messenger with Voice. Call regular phones from your PC and save big. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060326/ce8329f0/attachment-0041.html From dmarkman at mac.com Mon Mar 20 00:20:43 2006 From: dmarkman at mac.com (Dmitry Markman) Date: Mon, 20 Mar 2006 02:20:43 -0500 Subject: [Rxtx] Mac OS X RXTX java installer In-Reply-To: References: <07D0DE29-BA32-4CFE-B036-66BC6423D385@buechse.de> <441AE3E0.2030503@willicon.de> <12531986.1142622114996.JavaMail.dmarkman@mac.com> <441B2674.9010409@willicon.de> <13577405.1142634732776.JavaMail.dmarkman@mac.com> <441B4182.8010407@willicon.de> <92CD0D6C-5BE8-426E-A46D-99452059FF49@mac.com> <441BBB2D.8030305@willicon.de> <441C4088.5090905@willicon.de> Message-ID: <64BC1E23-FDDE-4CE6-8863-CFC881CBC224@mac.com> Hi all I put RXTX installer that will install everything (and will create / var/lock if necessary and add user to the uucp group) for mac os x from Java into the rxtx's CVS repository it could be easily modified to install files for any platform it uses Greg Guerin's AuthKit for authentication and authorization Greg released that kit under artistic license, so Trent, please take a look we, probably, can negotiate license with Greg if it's necessary Greg's AuthKit could be downloaded from http://www.amug.org/~glguerin/ sw/#authkit Michael Hall (mikehall at spacestar dot net) had a suggestion to make implementation of the jaas LoginModule based on Greg's AuthKit (his modification of the Greg's AuthKit could be found at http:// www.spacestar.net/users/mikehall/authkit.dmg) but Michael's AuthKitLoginModule does only half a job: it does authenticate but it can not run any external unix process in privileged mode (at least I wasn't able to do so) possible explanation could be found in conversation between Greg and Michael at Apple's java-dev list (look for archives) so I didn't use jaas API for rxtxinstaller I created folder MacOSX in the contrib folder comment 1. if you want to run that installer as standalone application all you need that RXTXInstaller.jar 2. if you want to use webstart you have to add Greg's libAuthKit.jnilib to the mac os x's resources in theory RXTXInstaller.jar doesn't need it, but there is a problem with loading libAuthKit.jnilib from webstart authkit uses loadLibrary method to load library and it failed (from webstart) for standalone application I extract libAuthKit.jnilib from the RXTXInstaller.jar and put it into the /Library/Java/Extensions or ~/Library/Java/Extensions folder that file will be deleted after installer quit unfortunately I didn't have time to put documentation there but it is mostly self-explanatory I took installer code from my gl4java installer that I did about 3 years ago (with small modifications) it would be very nice if Apple will release LoginModule that really will do the job (com.apple.security.auth.module package????? ) (UnixLoginModule is pretty useless) From lyon at docjava.com Mon Mar 20 06:34:39 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Mon, 20 Mar 2006 08:34:39 -0500 Subject: [Rxtx] Mac OS X RXTX java installer In-Reply-To: <64BC1E23-FDDE-4CE6-8863-CFC881CBC224@mac.com> References: <07D0DE29-BA32-4CFE-B036-66BC6423D385@buechse.de> <441AE3E0.2030503@willicon.de> <12531986.1142622114996.JavaMail.dmarkman@mac.com> <441B2674.9010409@willicon.de> <13577405.1142634732776.JavaMail.dmarkman@mac.com> <441B4182.8010407@willicon.de> <92CD0D6C-5BE8-426E-A46D-99452059FF49@mac.com> <441BBB2D.8030305@willicon.de> <441C4088.5090905@willicon.de> <64BC1E23-FDDE-4CE6-8863-CFC881CBC224@mac.com> Message-ID: Hi Dimitry, This sounds like great work. Just a couple of questions; After the check out of the CVS files, using: setenv CVSROOT :pserver:anonymous at cvs.milestonesolutions.com:/usr/local/cvsroot 53 8:28 setenv PASSWORD mousy 54 8:29 cvs login 55 8:29 cvs checkout rxtx-devel I cd'd over to: rxtx-devel/MACOSX_IDE And found: CVS/ CW/ ForPackageMaker/ PB/ Where is the installer? Thanks! - Doug From tjarvi at qbang.org Mon Mar 20 06:39:37 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 20 Mar 2006 06:39:37 -0700 (MST) Subject: [Rxtx] Mac OS X RXTX java installer In-Reply-To: References: <07D0DE29-BA32-4CFE-B036-66BC6423D385@buechse.de> <441AE3E0.2030503@willicon.de> <12531986.1142622114996.JavaMail.dmarkman@mac.com> <441B2674.9010409@willicon.de> <13577405.1142634732776.JavaMail.dmarkman@mac.com> <441B4182.8010407@willicon.de> <92CD0D6C-5BE8-426E-A46D-99452059FF49@mac.com> <441BBB2D.8030305@willicon.de> <441C4088.5090905@willicon.de> <64BC1E23-FDDE-4CE6-8863-CFC881CBC224@mac.com> Message-ID: On Mon, 20 Mar 2006, Dr. Douglas Lyon wrote: > Hi Dimitry, > This sounds like great work. Just a couple of questions; > After the check out of the CVS files, using: > setenv CVSROOT > :pserver:anonymous at cvs.milestonesolutions.com:/usr/local/cvsroot > 53 8:28 setenv PASSWORD mousy > 54 8:29 cvs login > 55 8:29 cvs checkout rxtx-devel Hi Doug You want "cvs checkout -r commapi-0-0-1 rxtx-devel" to get RXTX 2.1 The default branch is rxtx 2.0 which isn't very active right now. -- Trent Jarvi tjarvi at qbang.org From lyon at docjava.com Mon Mar 20 07:05:44 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Mon, 20 Mar 2006 09:05:44 -0500 Subject: [Rxtx] Mac OS X RXTX java installer In-Reply-To: References: <07D0DE29-BA32-4CFE-B036-66BC6423D385@buechse.de> <441AE3E0.2030503@willicon.de> <12531986.1142622114996.JavaMail.dmarkman@mac.com> <441B2674.9010409@willicon.de> <13577405.1142634732776.JavaMail.dmarkman@mac.com> <441B4182.8010407@willicon.de> <92CD0D6C-5BE8-426E-A46D-99452059FF49@mac.com> <441BBB2D.8030305@willicon.de> <441C4088.5090905@willicon.de> <64BC1E23-FDDE-4CE6-8863-CFC881CBC224@mac.com> Message-ID: Hi Trent, Thanks for the info on the CVS checkout procedure. I did that and am still not sure where the installer is. Here is what I have: cd MACOSX_IDE/ p4.docjava.com{lyon}121: ls CVS/ ForPackageMaker/ PB/ p4.docjava.com{lyon}122: find . | more . ./ForPackageMaker ./ForPackageMaker/RXTX.pkg.sit.hqx ./ForPackageMaker/Resources ./ForPackageMaker/Resources/ReadMe.rtf ./ForPackageMaker/Resources/Welcome.rtf ./ForPackageMaker/Resources/CVS ./ForPackageMaker/Resources/CVS/Entries ./ForPackageMaker/Resources/CVS/Repository ./ForPackageMaker/Resources/CVS/Tag ./ForPackageMaker/Resources/CVS/Root ./ForPackageMaker/Resources/preinstall ./ForPackageMaker/Resources/License.rtf ./ForPackageMaker/Resources/preupgrade ./ForPackageMaker/RXTX.pmsp ./ForPackageMaker/CVS ./ForPackageMaker/CVS/Entries ./ForPackageMaker/CVS/Repository ./ForPackageMaker/CVS/Entries.Log ./ForPackageMaker/CVS/Tag ./ForPackageMaker/CVS/Root ./ForPackageMaker/RXTX_Tiger.pkg.sitx.hqx ./ForPackageMaker/RXTX_Jag.pkg.sit.hqx ./ForPackageMaker/Install ./ForPackageMaker/Install/CVS ./ForPackageMaker/Install/CVS/Entries ./ForPackageMaker/Install/CVS/Repository ./ForPackageMaker/Install/CVS/Tag ./ForPackageMaker/Install/CVS/Root ./ForPackageMaker/Install/Library ./ForPackageMaker/Install/Library/CVS ./ForPackageMaker/Install/Library/CVS/Entries ./ForPackageMaker/Install/Library/CVS/Repository ./ForPackageMaker/Install/Library/CVS/Tag ./ForPackageMaker/Install/Library/CVS/Root ./ForPackageMaker/Install/Library/Java ./ForPackageMaker/Install/Library/Java/Extensions ./ForPackageMaker/Install/Library/Java/Extensions/RXTXcomm.jar ./ForPackageMaker/Install/Library/Java/Extensions/CVS ./ForPackageMaker/Install/Library/Java/Extensions/CVS/Entries ./ForPackageMaker/Install/Library/Java/Extensions/CVS/Repository ./ForPackageMaker/Install/Library/Java/Extensions/CVS/Tag ./ForPackageMaker/Install/Library/Java/Extensions/CVS/Root ./ForPackageMaker/Install/Library/Java/Extensions/librxtxSerial.jnilib ./ForPackageMaker/Install/Library/Java/CVS ./ForPackageMaker/Install/Library/Java/CVS/Entries ./ForPackageMaker/Install/Library/Java/CVS/Repository ./ForPackageMaker/Install/Library/Java/CVS/Entries.Log ./ForPackageMaker/Install/Library/Java/CVS/Tag ./ForPackageMaker/Install/Library/Java/CVS/Root ./ForPackageMaker/RXTX_Tiger.pmproj.sitx.hqx ./CVS ./CVS/Entries ./CVS/Repository ./CVS/Entries.Log ./CVS/Tag ./CVS/Root ./PB ./PB/LibSerialUniversal.xcodeproj.sitx.hqx ./PB/CVS ./PB/CVS/Entries ./PB/CVS/Repository ./PB/CVS/Entries.Log ./PB/CVS/Tag ./PB/CVS/Root ./PB/LibSerial.pbproj.sit.hqx ./PB/startpoint.c ./PB/config.h What is the procedure to run this installer? Do we need a README in: /rxtx-devel/MACOSX_IDE Here is what we have: CVS/ ForPackageMaker/ PB/ Thanks! - DL >On Mon, 20 Mar 2006, Dr. Douglas Lyon wrote: > >>Hi Dimitry, >>This sounds like great work. Just a couple of questions; >>After the check out of the CVS files, using: >>setenv CVSROOT >>:pserver:anonymous at cvs.milestonesolutions.com:/usr/local/cvsroot >> 53 8:28 setenv PASSWORD mousy >> 54 8:29 cvs login >> 55 8:29 cvs checkout rxtx-devel > >Hi Doug > >You want "cvs checkout -r commapi-0-0-1 rxtx-devel" to get RXTX 2.1 >The default branch is rxtx 2.0 which isn't very active right now. > >-- >Trent Jarvi >tjarvi at qbang.org From tjarvi at qbang.org Mon Mar 20 07:25:30 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 20 Mar 2006 07:25:30 -0700 (MST) Subject: [Rxtx] Mac OS X RXTX java installer In-Reply-To: References: <07D0DE29-BA32-4CFE-B036-66BC6423D385@buechse.de> <441AE3E0.2030503@willicon.de> <12531986.1142622114996.JavaMail.dmarkman@mac.com> <441B2674.9010409@willicon.de> <13577405.1142634732776.JavaMail.dmarkman@mac.com> <441B4182.8010407@willicon.de> <92CD0D6C-5BE8-426E-A46D-99452059FF49@mac.com> <441BBB2D.8030305@willicon.de> <441C4088.5090905@willicon.de> <64BC1E23-FDDE-4CE6-8863-CFC881CBC224@mac.com> Message-ID: On Mon, 20 Mar 2006, Dr. Douglas Lyon wrote: > Hi Trent, > Thanks for the info on the CVS checkout procedure. > I did that and am still not sure where the installer is. Hi Doug It does look like it was not cvs committed. There is no rxtx-devel/contrib/MacOSX directory in there at the moment. It was mentioned that it was put under contrib. -- Trent Jarvi tjarvi at qbang.org From dmarkman at mac.com Mon Mar 20 07:29:56 2006 From: dmarkman at mac.com (Dmitry Markman) Date: Mon, 20 Mar 2006 09:29:56 -0500 Subject: [Rxtx] Mac OS X RXTX java installer In-Reply-To: References: <07D0DE29-BA32-4CFE-B036-66BC6423D385@buechse.de> <441AE3E0.2030503@willicon.de> <12531986.1142622114996.JavaMail.dmarkman@mac.com> <441B2674.9010409@willicon.de> <13577405.1142634732776.JavaMail.dmarkman@mac.com> <441B4182.8010407@willicon.de> <92CD0D6C-5BE8-426E-A46D-99452059FF49@mac.com> <441BBB2D.8030305@willicon.de> <441C4088.5090905@willicon.de> <64BC1E23-FDDE-4CE6-8863-CFC881CBC224@mac.com> Message-ID: <6054EB4E-F7E0-4A9C-BDDA-D582D6D8826F@mac.com> you can find it in the rxtx-devel/contrib folder On Mar 20, 2006, at 9:05 AM, Dr. Douglas Lyon wrote: > Hi Trent, > Thanks for the info on the CVS checkout procedure. > I did that and am still not sure where the installer is. > Here is what I have: > cd MACOSX_IDE/ > p4.docjava.com{lyon}121: ls > CVS/ ForPackageMaker/ PB/ > p4.docjava.com{lyon}122: find . | more > . > ./ForPackageMaker > ./ForPackageMaker/RXTX.pkg.sit.hqx > ./ForPackageMaker/Resources > ./ForPackageMaker/Resources/ReadMe.rtf > ./ForPackageMaker/Resources/Welcome.rtf > ./ForPackageMaker/Resources/CVS > ./ForPackageMaker/Resources/CVS/Entries > ./ForPackageMaker/Resources/CVS/Repository > ./ForPackageMaker/Resources/CVS/Tag > ./ForPackageMaker/Resources/CVS/Root > ./ForPackageMaker/Resources/preinstall > ./ForPackageMaker/Resources/License.rtf > ./ForPackageMaker/Resources/preupgrade > ./ForPackageMaker/RXTX.pmsp > ./ForPackageMaker/CVS > ./ForPackageMaker/CVS/Entries > ./ForPackageMaker/CVS/Repository > ./ForPackageMaker/CVS/Entries.Log > ./ForPackageMaker/CVS/Tag > ./ForPackageMaker/CVS/Root > ./ForPackageMaker/RXTX_Tiger.pkg.sitx.hqx > ./ForPackageMaker/RXTX_Jag.pkg.sit.hqx > ./ForPackageMaker/Install > ./ForPackageMaker/Install/CVS > ./ForPackageMaker/Install/CVS/Entries > ./ForPackageMaker/Install/CVS/Repository > ./ForPackageMaker/Install/CVS/Tag > ./ForPackageMaker/Install/CVS/Root > ./ForPackageMaker/Install/Library > ./ForPackageMaker/Install/Library/CVS > ./ForPackageMaker/Install/Library/CVS/Entries > ./ForPackageMaker/Install/Library/CVS/Repository > ./ForPackageMaker/Install/Library/CVS/Tag > ./ForPackageMaker/Install/Library/CVS/Root > ./ForPackageMaker/Install/Library/Java > ./ForPackageMaker/Install/Library/Java/Extensions > ./ForPackageMaker/Install/Library/Java/Extensions/RXTXcomm.jar > ./ForPackageMaker/Install/Library/Java/Extensions/CVS > ./ForPackageMaker/Install/Library/Java/Extensions/CVS/Entries > ./ForPackageMaker/Install/Library/Java/Extensions/CVS/Repository > ./ForPackageMaker/Install/Library/Java/Extensions/CVS/Tag > ./ForPackageMaker/Install/Library/Java/Extensions/CVS/Root > ./ForPackageMaker/Install/Library/Java/Extensions/librxtxSerial.jnilib > ./ForPackageMaker/Install/Library/Java/CVS > ./ForPackageMaker/Install/Library/Java/CVS/Entries > ./ForPackageMaker/Install/Library/Java/CVS/Repository > ./ForPackageMaker/Install/Library/Java/CVS/Entries.Log > ./ForPackageMaker/Install/Library/Java/CVS/Tag > ./ForPackageMaker/Install/Library/Java/CVS/Root > ./ForPackageMaker/RXTX_Tiger.pmproj.sitx.hqx > ./CVS > ./CVS/Entries > ./CVS/Repository > ./CVS/Entries.Log > ./CVS/Tag > ./CVS/Root > ./PB > ./PB/LibSerialUniversal.xcodeproj.sitx.hqx > ./PB/CVS > ./PB/CVS/Entries > ./PB/CVS/Repository > ./PB/CVS/Entries.Log > ./PB/CVS/Tag > ./PB/CVS/Root > ./PB/LibSerial.pbproj.sit.hqx > ./PB/startpoint.c > ./PB/config.h > > What is the procedure to run this installer? > Do we need a README in: > /rxtx-devel/MACOSX_IDE > Here is what we have: > CVS/ ForPackageMaker/ PB/ > > > Thanks! > - DL > >> On Mon, 20 Mar 2006, Dr. Douglas Lyon wrote: >> >>> Hi Dimitry, >>> This sounds like great work. Just a couple of questions; >>> After the check out of the CVS files, using: >>> setenv CVSROOT :pserver:anonymous at cvs.milestonesolutions.com:/usr/ >>> local/cvsroot >>> 53 8:28 setenv PASSWORD mousy >>> 54 8:29 cvs login >>> 55 8:29 cvs checkout rxtx-devel >> >> Hi Doug >> >> You want "cvs checkout -r commapi-0-0-1 rxtx-devel" to get RXTX 2.1 >> The default branch is rxtx 2.0 which isn't very active right now. >> >> -- >> Trent Jarvi >> tjarvi at qbang.org > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx Dmitry Markman From mikehall at spacestar.net Mon Mar 20 05:25:25 2006 From: mikehall at spacestar.net (Michael Hall) Date: Mon, 20 Mar 2006 06:25:25 -0600 Subject: [Rxtx] Re: Mac OS X RXTX java installer In-Reply-To: <64BC1E23-FDDE-4CE6-8863-CFC881CBC224@mac.com> References: <07D0DE29-BA32-4CFE-B036-66BC6423D385@buechse.de> <441AE3E0.2030503@willicon.de> <12531986.1142622114996.JavaMail.dmarkman@mac.com> <441B2674.9010409@willicon.de> <13577405.1142634732776.JavaMail.dmarkman@mac.com> <441B4182.8010407@willicon.de> <92CD0D6C-5BE8-426E-A46D-99452059FF49@mac.com> <441BBB2D.8030305@willicon.de> <441C4088.5090905@willicon.de> <64BC1E23-FDDE-4CE6-8863-CFC881CBC224@mac.com> Message-ID: <247EB61F-5CD1-4132-89A2-FC105B6CF9A5@spacestar.net> On Mar 20, 2006, at 1:20 AM, Dmitry Markman wrote: > > Michael Hall (mikehall at spacestar dot net) had a suggestion to > make implementation of the jaas LoginModule > based on Greg's AuthKit > (his modification of the Greg's AuthKit could be found at http:// > www.spacestar.net/users/mikehall/authkit.dmg) > but Michael's AuthKitLoginModule does only half a job: > it does authenticate > but it can not run any external unix process in privileged mode (at > least I wasn't able to do so) If you got it working directly with Greg's the point is moot. But to clarify it anyhow. The login module does not allow you to do anything anything privileged on return as was explained by Greg. You need to work with a separate privileged process using the execPrivileged method of his API. I assume you did something similar although I haven't looked at how you are using it yet. I allowed instead for a action to be performed at the same time you login/authenticate,this... System.setProperty("authkit.action","/usr/bin/id"); just before this... lc.login(); To clarify, safely ignored as you are already complete. Mike Hall mikehall at spacestar dot net http://www.spacestar.net/users/mikehall http://sourceforge.net/projects/macnative -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2427 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20060320/f6e18202/smime-0044.bin From dmarkman at mac.com Mon Mar 20 07:36:47 2006 From: dmarkman at mac.com (Dmitry Markman) Date: Mon, 20 Mar 2006 09:36:47 -0500 Subject: [Rxtx] Re: Mac OS X RXTX java installer In-Reply-To: <247EB61F-5CD1-4132-89A2-FC105B6CF9A5@spacestar.net> References: <07D0DE29-BA32-4CFE-B036-66BC6423D385@buechse.de> <441AE3E0.2030503@willicon.de> <12531986.1142622114996.JavaMail.dmarkman@mac.com> <441B2674.9010409@willicon.de> <13577405.1142634732776.JavaMail.dmarkman@mac.com> <441B4182.8010407@willicon.de> <92CD0D6C-5BE8-426E-A46D-99452059FF49@mac.com> <441BBB2D.8030305@willicon.de> <441C4088.5090905@willicon.de> <64BC1E23-FDDE-4CE6-8863-CFC881CBC224@mac.com> <247EB61F-5CD1-4132-89A2-FC105B6CF9A5@spacestar.net> Message-ID: Hi, Michael all I have to do is to run some shell script I tried to use your action mechanism and it worked great so I just System.setProperty ("authkit.action","" ) and after that I even don't need to run anything like subject.doAs.... but after few thoughts I choose to use plain Greg's approach, because in that case I don't have to deal with various java's configurations files and therefore to use 2-3 -D parameters in the java command line especially it's useful for java web start (it's so fragile :-( ) thanks for the great job On Mar 20, 2006, at 7:25 AM, Michael Hall wrote: > > On Mar 20, 2006, at 1:20 AM, Dmitry Markman wrote: >> >> Michael Hall (mikehall at spacestar dot net) had a suggestion to >> make implementation of the jaas LoginModule >> based on Greg's AuthKit >> (his modification of the Greg's AuthKit could be found at http:// >> www.spacestar.net/users/mikehall/authkit.dmg) >> but Michael's AuthKitLoginModule does only half a job: >> it does authenticate >> but it can not run any external unix process in privileged mode >> (at least I wasn't able to do so) > > If you got it working directly with Greg's the point is moot. > > But to clarify it anyhow. > The login module does not allow you to do anything anything > privileged on return as was explained by Greg. You need to work > with a separate privileged process using the execPrivileged method > of his API. I assume you did something similar although I haven't > looked at how you are using it yet. > I allowed instead for a action to be performed at the same time you > login/authenticate,this... > System.setProperty("authkit.action","/usr/bin/id"); > just before this... > lc.login(); > To clarify, safely ignored as you are already complete. > > Mike Hall mikehall at spacestar dot net > http://www.spacestar.net/users/mikehall > http://sourceforge.net/projects/macnative > > > Dmitry Markman From dmarkman at mac.com Mon Mar 20 07:44:45 2006 From: dmarkman at mac.com (Dmitry Markman) Date: Mon, 20 Mar 2006 09:44:45 -0500 Subject: [Rxtx] Mac OS X RXTX java installer In-Reply-To: References: <07D0DE29-BA32-4CFE-B036-66BC6423D385@buechse.de> <441AE3E0.2030503@willicon.de> <12531986.1142622114996.JavaMail.dmarkman@mac.com> <441B2674.9010409@willicon.de> <13577405.1142634732776.JavaMail.dmarkman@mac.com> <441B4182.8010407@willicon.de> <92CD0D6C-5BE8-426E-A46D-99452059FF49@mac.com> <441BBB2D.8030305@willicon.de> <441C4088.5090905@willicon.de> <64BC1E23-FDDE-4CE6-8863-CFC881CBC224@mac.com> Message-ID: it's in the commapi-0-0-1 branch I tested it right now: cvs co -r commapi-0-0-1 rxtx-devel and I got everything On Mar 20, 2006, at 9:25 AM, Trent Jarvi wrote: > On Mon, 20 Mar 2006, Dr. Douglas Lyon wrote: > >> Hi Trent, >> Thanks for the info on the CVS checkout procedure. >> I did that and am still not sure where the installer is. > > Hi Doug > > It does look like it was not cvs committed. There is no rxtx-devel/ > contrib/MacOSX directory in there at the moment. It was mentioned > that it was put under contrib. > > -- > Trent Jarvi > tjarvi at qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx Dmitry Markman From tjarvi at qbang.org Mon Mar 20 07:52:57 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 20 Mar 2006 07:52:57 -0700 (MST) Subject: [Rxtx] Mac OS X RXTX java installer In-Reply-To: References: <07D0DE29-BA32-4CFE-B036-66BC6423D385@buechse.de> <441AE3E0.2030503@willicon.de> <12531986.1142622114996.JavaMail.dmarkman@mac.com> <441B2674.9010409@willicon.de> <13577405.1142634732776.JavaMail.dmarkman@mac.com> <441B4182.8010407@willicon.de> <92CD0D6C-5BE8-426E-A46D-99452059FF49@mac.com> <441BBB2D.8030305@willicon.de> <441C4088.5090905@willicon.de> <64BC1E23-FDDE-4CE6-8863-CFC881CBC224@mac.com> Message-ID: On Mon, 20 Mar 2006, Dmitry Markman wrote: > it's in the commapi-0-0-1 branch > > I tested it right now: > cvs co -r commapi-0-0-1 rxtx-devel > > and I got everything > A fresh checkout worked. Here is a copy of the tree (just the installer bits) ftp://ftp.qbang.org/pub/rxtx/MacOSX-installer.zip -- Trent Jarvi tjarvi at qbang.org From lyon at docjava.com Mon Mar 20 08:08:26 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Mon, 20 Mar 2006 10:08:26 -0500 Subject: [Rxtx] Mac OS X RXTX java installer In-Reply-To: References: <07D0DE29-BA32-4CFE-B036-66BC6423D385@buechse.de> <441AE3E0.2030503@willicon.de> <12531986.1142622114996.JavaMail.dmarkman@mac.com> <441B2674.9010409@willicon.de> <13577405.1142634732776.JavaMail.dmarkman@mac.com> <441B4182.8010407@willicon.de> <92CD0D6C-5BE8-426E-A46D-99452059FF49@mac.com> <441BBB2D.8030305@willicon.de> <441C4088.5090905@willicon.de> <64BC1E23-FDDE-4CE6-8863-CFC881CBC224@mac.com> Message-ID: Hi All, Is the Auth package able to work properly on non Mac OS's? It was not clear from the doc or download. Thanks! - Doug From dmarkman at mac.com Mon Mar 20 08:15:22 2006 From: dmarkman at mac.com (Dmitry Markman) Date: Mon, 20 Mar 2006 10:15:22 -0500 Subject: [Rxtx] Mac OS X RXTX java installer In-Reply-To: References: <07D0DE29-BA32-4CFE-B036-66BC6423D385@buechse.de> <441AE3E0.2030503@willicon.de> <12531986.1142622114996.JavaMail.dmarkman@mac.com> <441B2674.9010409@willicon.de> <13577405.1142634732776.JavaMail.dmarkman@mac.com> <441B4182.8010407@willicon.de> <92CD0D6C-5BE8-426E-A46D-99452059FF49@mac.com> <441BBB2D.8030305@willicon.de> <441C4088.5090905@willicon.de> <64BC1E23-FDDE-4CE6-8863-CFC881CBC224@mac.com> Message-ID: <217312D8-CCCA-4859-ABA6-32DF1CC817B9@mac.com> thanks Trent, for putting it on ftp server On Mar 20, 2006, at 9:52 AM, Trent Jarvi wrote: > A fresh checkout worked. Here is a copy of the tree (just the > installer bits) > > ftp://ftp.qbang.org/pub/rxtx/MacOSX-installer.zip > Dmitry Markman From dmarkman at mac.com Mon Mar 20 09:14:03 2006 From: dmarkman at mac.com (Dmitry Markman) Date: Mon, 20 Mar 2006 11:14:03 -0500 Subject: [Rxtx] Mac OS X RXTX java installer In-Reply-To: References: <07D0DE29-BA32-4CFE-B036-66BC6423D385@buechse.de> <441AE3E0.2030503@willicon.de> <12531986.1142622114996.JavaMail.dmarkman@mac.com> <441B2674.9010409@willicon.de> <13577405.1142634732776.JavaMail.dmarkman@mac.com> <441B4182.8010407@willicon.de> <92CD0D6C-5BE8-426E-A46D-99452059FF49@mac.com> <441BBB2D.8030305@willicon.de> <441C4088.5090905@willicon.de> <64BC1E23-FDDE-4CE6-8863-CFC881CBC224@mac.com> Message-ID: <4DEBA6F0-DA45-4E84-823E-1F1AC48BDCCC@mac.com> no it will work only on mac os x however it's harmless to run it on other platform if you want to use it for other platform you have to do the following (I'll do it for linux) 1. modify RXTXInstaller class method public static RXTXInstaller getInstance() public static RXTXInstaller getInstance() { String osName = System.getProperty("os.name").toLowerCase(); if(osName.startsWith("mac")){ return new gnu.io.installer.macosx.MACOSXRXTXInstaller(); } else if(osName.startsWith("windows")){ return new gnu.io.installer.windows.WindowsRXTXInstaller(); }else if(osName.startsWith("linux")){ return new gnu.io.installer.linux.LinuxRXTXInstaller(); } return null; } 2. create folder gnu/io/installer/linux/ 3. create class Linux386RXTXInstaller package gnu.io.installer.linux; import java.io.File; public class Linux386RXTXInstaller extends gnu.io.installer.RXTXInstaller{ public Linux386RXTXInstaller(){ createJarFolder(); createLibFolder(); addJarResource("RXTXcomm.jar","/gnu/io/installer/resources/ linux/jar/RXTXcomm.dat"); addLibResource("librxtxSerial.so","/gnu/io/installer/ resources/linux/lib/librxtxSerial.so"); } protected void createJarFolder(){ String javaHome = System.getProperty("java.home"); char separator = File.separatorChar; jarFolder = new File(javaHome+separator+"lib"+separator+"ext"); } protected void createLibFolder(){ String javaHome = System.getProperty("java.home"); char separator = File.separatorChar; libFolder = new File(javaHome+separator+"bin"); } public void runPreProcess() {} //put here some action you need public void runPostProcess() {} //put here some action you need } 4. create folder /gnu/io/installer/resources/linux/jar and put there linux's version of RXTXcomm.dat (which is renamed RXTXcomm.jar) 5. create folder /gnu/io/installer/resources/linux/lib and put there linux's version of librxtxSerial. so 6. make sure that RXTXInstaller.jar has the following items: /gnu/io/installer/resources/linux/jar/RXTXcomm.jar /gnu/io/installer/resources/linux/lib/librxtxSerial.so 7. modify file installer.pref: jar file RXTXInstaller.jar must have the following item /gnu/io/installer/installer.pref that's basically it for windows you have to do the similar things: just replace linux to windows and librxtxSerial.so to rxtxSerial.dll and create appropriate gnu.io.installer.windows.WindowsRXTXInstaller class package gnu.io.installer.windows; import java.io.File; public class WindowsRXTXInstaller extends gnu.io.installer.RXTXInstaller{ public WindowsRXTXInstaller(){ createJarFolder(); createLibFolder(); addJarResource("RXTXcomm.jar","/gnu/io/installer/resources/ windows/jar/RXTXcomm.dat"); addLibResource("librxtxSerial.so","/gnu/io/installer/ resources/windows/lib/rxtxSerial.dll"); } protected void createJarFolder(){ String javaHome = System.getProperty("java.home"); char separator = File.separatorChar; jarFolder = new File(javaHome+separator+"lib"+separator+"ext"); } protected void createLibFolder(){ String javaHome = System.getProperty("java.home"); char separator = File.separatorChar; libFolder = new File(javaHome+separator+"bin"); } public void runPreProcess() {} //put here some action you need public void runPostProcess() {} //put here some action you need } installer.pref will look like On Mar 20, 2006, at 10:08 AM, Dr. Douglas Lyon wrote: > Hi All, > Is the Auth package able to work properly on > non Mac OS's? > It was not clear from the doc or download. > > Thanks! > - Doug > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx Dmitry Markman From joachim at buechse.de Mon Mar 20 10:49:06 2006 From: joachim at buechse.de (Joachim Buechse) Date: Mon, 20 Mar 2006 18:49:06 +0100 Subject: [Rxtx] BUG: Lock file stays even if port opening fails Message-ID: This was only tested on MacOSX but looking at the code, it should be true for all systems that use lock_uucp. I am opening a port which can not be opened (dialup port of a telephone paired via bluetooth but currently not reachable). The lock file is created and stays arround, even though the port open failed. After looking a bit through the code (of 2.17), I really wonder if it wouldn't be a good idea to make the "locking" an explicit operation called from the java code. This would certainly simplify the generation of meaningfull exceptions (and java based debugging). Maybe even the handling of "preopened" ports should be in the Java part of the lib (again for java based debugging puposes). That beeing said, I have no idea if this would be possible for the 2.07 implementation. Regards, Joachim From tjarvi at qbang.org Mon Mar 20 11:24:22 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 20 Mar 2006 11:24:22 -0700 (MST) Subject: [Rxtx] BUG: Lock file stays even if port opening fails In-Reply-To: References: Message-ID: On Mon, 20 Mar 2006, Joachim Buechse wrote: > This was only tested on MacOSX but looking at the code, it should be true > for all systems that use lock_uucp. > > I am opening a port which can not be opened (dialup port of a telephone > paired via bluetooth but currently not reachable). The lock file is > created and stays arround, even though the port open failed. > > > After looking a bit through the code (of 2.17), I really wonder if it > wouldn't be a good idea to make the "locking" an explicit operation > called from the java code. This would certainly simplify the generation > of meaningfull exceptions (and java based debugging). > Maybe even the handling of "preopened" ports should be in the Java part > of the lib (again for java based debugging puposes). That beeing said, I > have no idea if this would be possible for the 2.07 implementation. > > Regards, Hi Joachim It should be possible in the 2.0-7 implementation too. The calls to RXTXPort.java would not change. We would just do more there Moving more of that logic into Java would be better as many people don't like to look at C code. There is a liblockdev on most Linux distros that can do most of the C code and would be easier to use. The problem is embeded devices will not have that library. The preopened port code has not been really tested. That was a last minute request in a product cycle. I expect it will be tested this year though. As I recall, some devices really do not like CD raising on open. The preopened ports then allow people to mess around in java without power cycling the devices or losing data. -- Trent Jarvi tjarvi at qbang.org From joachim at buechse.de Mon Mar 20 12:01:08 2006 From: joachim at buechse.de (Joachim Buechse) Date: Mon, 20 Mar 2006 20:01:08 +0100 Subject: [Rxtx] BUG: Lock file stays even if port opening fails In-Reply-To: References: Message-ID: Hi Trent, What is your general feeling about moving code to Java? The last days I have been reading quite a bit of the code and there are several things, that might not work as expected. I'll give you two examples from is_device_locked: if LOCKDIR == /var/spool/locks the directory /var/spool/lock will not be checked. LOCKDIR is not checked for lockfiles with unexpected pefixes While these things have probably never been discovered in production, they are still possibly incorrect implementations. If it was Java code, I would write some unit tests producing the errors that could later be corrected. PS: One could imagine to actually implement the whole lockfile handling in Java using some native routines to get the values required (pid, st_dev, st_rdev, ...). On 20.03.2006, at 19:24, Trent Jarvi wrote: > On Mon, 20 Mar 2006, Joachim Buechse wrote: > >> This was only tested on MacOSX but looking at the code, it should >> be true for all systems that use lock_uucp. >> >> I am opening a port which can not be opened (dialup port of a >> telephone paired via bluetooth but currently not reachable). The >> lock file is created and stays arround, even though the port open >> failed. >> >> >> After looking a bit through the code (of 2.17), I really wonder if >> it wouldn't be a good idea to make the "locking" an explicit >> operation called from the java code. This would certainly simplify >> the generation of meaningfull exceptions (and java based debugging). >> Maybe even the handling of "preopened" ports should be in the Java >> part of the lib (again for java based debugging puposes). That >> beeing said, I have no idea if this would be possible for the 2.07 >> implementation. >> >> Regards, > > Hi Joachim > > It should be possible in the 2.0-7 implementation too. The calls > to RXTXPort.java would not change. We would just do more there > Moving more of that logic into Java would be better as many people > don't like to look at C code. There is a liblockdev on most Linux > distros that can do most of the C code and would be easier to use. > The problem is embeded devices will not have that library. > > The preopened port code has not been really tested. That was a > last minute request in a product cycle. I expect it will be tested > this year though. As I recall, some devices really do not like CD > raising on open. The preopened ports then allow people to mess > around in java without power cycling the devices or losing data. > > -- > Trent Jarvi > tjarvi at qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Mon Mar 20 12:21:02 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 20 Mar 2006 12:21:02 -0700 (MST) Subject: [Rxtx] BUG: Lock file stays even if port opening fails In-Reply-To: References: Message-ID: On Mon, 20 Mar 2006, Joachim Buechse wrote: > Hi Trent, > > What is your general feeling about moving code to Java? The last days I > have been reading quite a bit of the code and there are several things, > that might not work as expected. > > I'll give you two examples from is_device_locked: > > if LOCKDIR == /var/spool/locks the directory /var/spool/lock will not be > checked. > LOCKDIR is not checked for lockfiles with unexpected pefixes > > While these things have probably never been discovered in production, > they are still possibly incorrect implementations. If it was Java code, I > would write some unit tests producing the errors that could later be > corrected. > > PS: One could imagine to actually implement the whole lockfile handling > in Java using some native routines to get the values required (pid, > st_dev, st_rdev, ...). Hi Joachim I like the idea of moving more of the code into java but there are some things to consider. If you break this into multiple JNI calls, the performance will drop considerably during enumeration of ports. We are looking for 256 ports per dev type vs (16? in Sun's 2.0 and fewer types). Its hard to make assumptions. I've seen virtual ports start at /dev/foo100 for instance. It works out to over 7500 ports on Linux if you enable them all. We already trim that back by default. See Linux-all-ports in RXTXCommDriver.java. There are also native libraries that rxtx can link to. If you move too much into Java, linking to 'standard' libraries with distros will break. "configure --enable-liblock=yes" will not be doable. This is probably a favorable way with RedHat, Debian, Suse and others. Thats the right thing to do if there will be rpms, dpkg, .. For those reasons, I think it still make sense to keep it to a minimal ~3 calls to JNI code that we can use for speed and versatility. lock() isLocked(), unlock() perhaps. When I say speed, its more about avoiding crossing the JNI layer multiple times than java vs C performance. With versatility I think liblock is the right way for most but not all (embeded) linux distros. -- Trent Jarvi tjarvi at qbang.org From joachim at buechse.de Mon Mar 20 12:42:04 2006 From: joachim at buechse.de (Joachim Buechse) Date: Mon, 20 Mar 2006 20:42:04 +0100 Subject: [Rxtx] BUG: Lock file stays even if port opening fails In-Reply-To: References: Message-ID: <82C19FE7-DDCB-45B6-B2C9-7606B66F0124@buechse.de> Ok, what about providing a default implementation in Java? The RXTXCommDriver would call a (native) function useNativeLocking and if it returns true, call the native functions for lock() isLocked (), unlock(), else is would use the Java based default implementation. This could possibly be overriden by a property (again for debugging). Joachim On 20.03.2006, at 20:21, Trent Jarvi wrote: > On Mon, 20 Mar 2006, Joachim Buechse wrote: > >> Hi Trent, >> >> What is your general feeling about moving code to Java? The last >> days I have been reading quite a bit of the code and there are >> several things, that might not work as expected. >> >> I'll give you two examples from is_device_locked: >> >> if LOCKDIR == /var/spool/locks the directory /var/spool/lock will >> not be checked. >> LOCKDIR is not checked for lockfiles with unexpected pefixes >> >> While these things have probably never been discovered in >> production, they are still possibly incorrect implementations. If >> it was Java code, I would write some unit tests producing the >> errors that could later be corrected. >> >> PS: One could imagine to actually implement the whole lockfile >> handling in Java using some native routines to get the values >> required (pid, st_dev, st_rdev, ...). > > Hi Joachim > > I like the idea of moving more of the code into java but there are > some things to consider. > > If you break this into multiple JNI calls, the performance will > drop considerably during enumeration of ports. We are looking for > 256 ports per dev type vs (16? in Sun's 2.0 and fewer types). Its > hard to make assumptions. I've seen virtual ports start at /dev/ > foo100 for instance. > > It works out to over 7500 ports on Linux if you enable them all. > We already trim that back by default. See Linux-all-ports in > RXTXCommDriver.java. > > There are also native libraries that rxtx can link to. If you move > too much into Java, linking to 'standard' libraries with distros > will break. "configure --enable-liblock=yes" will not be doable. > This is probably a favorable way with RedHat, Debian, Suse and > others. Thats the right thing to do if there will be rpms, dpkg, .. > > For those reasons, I think it still make sense to keep it to a > minimal ~3 calls to JNI code that we can use for speed and > versatility. lock() isLocked(), unlock() perhaps. When I say > speed, its more about avoiding crossing the JNI layer multiple > times than java vs C performance. With versatility I think liblock > is the right way for most but not all (embeded) linux distros. > > -- > Trent Jarvi > tjarvi at qbang.org > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Mon Mar 20 12:44:47 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 20 Mar 2006 12:44:47 -0700 (MST) Subject: [Rxtx] BUG: Lock file stays even if port opening fails In-Reply-To: <82C19FE7-DDCB-45B6-B2C9-7606B66F0124@buechse.de> References: <82C19FE7-DDCB-45B6-B2C9-7606B66F0124@buechse.de> Message-ID: On Mon, 20 Mar 2006, Joachim Buechse wrote: > Ok, what about providing a default implementation in Java? > > The RXTXCommDriver would call a (native) function useNativeLocking and if > it returns true, call the native functions for lock() isLocked(), > unlock(), else is would use the Java based default implementation. This > could possibly be overriden by a property (again for debugging). > Hi Joachim That would be OK with me. -- Trent Jarvi tjarvi at qbang.org From dmarkman at mac.com Mon Mar 20 22:27:45 2006 From: dmarkman at mac.com (Dmitry Markman) Date: Tue, 21 Mar 2006 00:27:45 -0500 Subject: [Rxtx] binaries request Message-ID: <42702213-C222-4937-A585-7CFB17E47608@mac.com> Hi can somebody send me latest linux and windows binaries, please? or where I can find them (I didn't find them in the latest tareball) I gave up with my cygwin: something wrong I have no idea what java doesn't understand /cygwin/c syntax after I changed makefile it did java part but after that gcc 3.4.4 started to complain I set buffer length to 999 lines but I didn't get beginning of the story something wrong with my 1.4.2_09/include/jni.h gcc doesn't like it anyway I gave up thanks in advance Dmitry Markman -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060320/f8cbc57c/attachment-0044.html From tjarvi at qbang.org Mon Mar 20 22:36:48 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 20 Mar 2006 22:36:48 -0700 (MST) Subject: [Rxtx] binaries request In-Reply-To: <42702213-C222-4937-A585-7CFB17E47608@mac.com> References: <42702213-C222-4937-A585-7CFB17E47608@mac.com> Message-ID: On Tue, 21 Mar 2006, Dmitry Markman wrote: > Hi > can somebody send me latest linux and windows binaries, please? > > or where I can find them (I didn't find them in the latest tareball) > > I gave up with my cygwin: something wrong I have no idea what > java doesn't understand /cygwin/c syntax > after I changed makefile it did java part > but after that gcc 3.4.4 started to complain > I set buffer length to 999 lines but I didn't get beginning of the story > something wrong with my 1.4.2_09/include/jni.h gcc doesn't like it > anyway I gave up > > thanks in advance > Hi Dmitry The bins are here: ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7-bins-r2.zip Here are the files in the zip you want. Jar: rxtx-2.1-7-bins-r2/RXTXcomm.jar Windows: rxtx-2.1-7-bins-r2/Windows/i368-mingw32/rxtxSerial.dll Linux (x86) rxtx-2.1-7-bins-r2/Linux/i686-unknown-linux-gnu/librxtxSerial.so There are others in there including Parallel port support but those are the main ones for testing. -- Trent Jarvi tjarvi at qbang.org From dmarkman at mac.com Mon Mar 20 23:05:59 2006 From: dmarkman at mac.com (Dmitry Markman) Date: Tue, 21 Mar 2006 01:05:59 -0500 Subject: [Rxtx] binaries request In-Reply-To: References: <42702213-C222-4937-A585-7CFB17E47608@mac.com> Message-ID: thank you very much but windows's readme says: rxtxSerial.dll had to be recomopiled to link in missing native methods. should I ignore it? or what? thanks again also I understand that I should use mingw not cygwin I'll try to install mingw On Mar 21, 2006, at 12:36 AM, Trent Jarvi wrote: > On Tue, 21 Mar 2006, Dmitry Markman wrote: > >> Hi >> can somebody send me latest linux and windows binaries, please? >> >> or where I can find them (I didn't find them in the latest tareball) >> >> I gave up with my cygwin: something wrong I have no idea what >> java doesn't understand /cygwin/c syntax >> after I changed makefile it did java part >> but after that gcc 3.4.4 started to complain >> I set buffer length to 999 lines but I didn't get beginning of the >> story >> something wrong with my 1.4.2_09/include/jni.h gcc doesn't like it >> anyway I gave up >> >> thanks in advance >> > > Hi Dmitry > > The bins are here: > > ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7-bins-r2.zip > > Here are the files in the zip you want. > > Jar: > > rxtx-2.1-7-bins-r2/RXTXcomm.jar > > Windows: > > rxtx-2.1-7-bins-r2/Windows/i368-mingw32/rxtxSerial.dll > > Linux (x86) > > rxtx-2.1-7-bins-r2/Linux/i686-unknown-linux-gnu/librxtxSerial.so > > There are others in there including Parallel port support but those > are the main ones for testing. > > -- > Trent Jarvi > tjarvi at qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx Dmitry Markman From tjarvi at qbang.org Mon Mar 20 23:20:33 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 20 Mar 2006 23:20:33 -0700 (MST) Subject: [Rxtx] binaries request In-Reply-To: References: <42702213-C222-4937-A585-7CFB17E47608@mac.com> Message-ID: On Tue, 21 Mar 2006, Dmitry Markman wrote: > thank you very much > > but windows's readme says: > rxtxSerial.dll had to be recomopiled to link in missing native methods. > > should I ignore it? or what? > Hi Dmitry That dll should be OK. r2 is the recompile linked to the missing native method. The readme explains why it was recompiled; fuser.o was not linked into the dll in the first release. -- Trent Jarvi tjarvi at qbang.org From ariantristan at yahoo.com Mon Mar 20 23:55:24 2006 From: ariantristan at yahoo.com (Lambok Sianturi) Date: Mon, 20 Mar 2006 22:55:24 -0800 (PST) Subject: [Rxtx] jvm issue Message-ID: <20060321065524.94779.qmail@web50701.mail.yahoo.com> Hi All, This is my first time to join RxTx mailing list. I thank you all for allowing others to sign in in requests help. I use the latest RxTx lib in Fedora 3 with java version 1.4.2_09 b05. And I got this error: # # An unexpected error has been detected by HotSpot Virtual Machine: # # SIGSEGV (0xb) at pc=0x00bf27f3, pid=2633, tid=3086112448 # # Java VM: Java HotSpot(TM) Client VM (1.4.2_09-b05 mixed mode) # Problematic frame: # C [ld-linux.so.2+0xa7f3] # # An error report file with more information is saved as hs_err_pid2633.log # # If you would like to submit a bug report, please visit: # http://java.sun.com/webapps/bugreport/crash.jsp # ./run.sh: line 3: 2633 Aborted /usr/local/java/bin/java -Djava.library.path=/usr/local/java/jre/lib/ -Djsmsengine.debug=true -classpath jsmsengine.jar:smsgateway.jar:classes12.jar:RXTXcomm.jar:. com.api.sms.SMSServer What is the jvm depedency for the latest library? Can I use 1.4.2_09 b05? Thanks in advance. Arian --------------------------------- Yahoo! Mail Use Photomail to share photos without annoying attachments. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060320/83d58dd7/attachment-0044.html From f.frumento at ngi.it Tue Mar 21 00:21:47 2006 From: f.frumento at ngi.it (Fabio Frumento) Date: Tue, 21 Mar 2006 08:21:47 +0100 Subject: [Rxtx] Javadoc on the go Message-ID: <441FA98B.9050701@ngi.it> Hi Trent, sorry for the big delay but my job is running wild, i was out for some time but now i'm back and ready to continue the javadoc for Rxtx. Did you used the last javadoc patch i sent you ? let me know if i have to send it to you again or not. regards Fabio From lyon at docjava.com Tue Mar 21 00:51:18 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Tue, 21 Mar 2006 02:51:18 -0500 Subject: [Rxtx] lock files Message-ID: Hi All, You know, if the use of lock files were under Java control (rather than a build-time decision), it might enable a more unified binary distro. It might also facilitate quick prototyping of non-lock file approaches to resolving serial port contention issues (i.e., mac-like approaches vs. linux approaches, etc.). I realize that this is a radical overhaul of the lock file policy issue. Also, it may harm performance. On the other hand, our benchmarks on JNI overhead for modern processors indicate performance impact should be minimal. Perhaps it is more of an issue with the toybox systems. Suppose there were a class with a reasonable default...someone might write: SerialPortLockPolicy.setPolicy(SerialPortLockPolicy.UNIX_LOCK_FILE); SerialPortLockPolicy.setPolicy(SerialPortLockPolicy.NO_LOCK_CHECKING); SerialPortLockPolicy.setPolicy(SerialPortLockPolicy.MAC_STYLE); Thus, we could have a run-time reconfiguration of the serial port lock policy. A special NO_LOCK version of the binary would no longer be required. Any thoughts on this? Thanks! - Doug From joachim at buechse.de Tue Mar 21 03:09:09 2006 From: joachim at buechse.de (Joachim Buechse) Date: Tue, 21 Mar 2006 11:09:09 +0100 Subject: [Rxtx] lock files In-Reply-To: References: Message-ID: <8E12916A-1B9A-4FF2-B684-E2D1C794221B@buechse.de> This is pretty much what I thought about when I suggested, that the default behaviour could be overwritten with a property. I am very much in favor of this approach. In particular this allows much easier debugging for PC based java developers. I think big parts of the Java (and maybe some parts of the C code) could use a bit of a structural workover (unit tests, javadoc, synchronization, etc). Maybe there should be a CVS branch for this experimental version. I'd be happy to contribute a first workover for some of the Java code. Designing for testability and implementing a good bunch of unit tests has been a strategy that worked quite well in the Java projects I lead. And it ultimately allows more liberal change permission. Regards, Joachim On 21.03.2006, at 08:51, Dr. Douglas Lyon wrote: > Hi All, > You know, if the use of lock files were > under Java control (rather than a build-time decision), > it might enable a more unified binary distro. It might also > facilitate quick prototyping of non-lock file approaches > to resolving serial port contention issues (i.e., mac-like > approaches vs. linux approaches, etc.). > > I realize that this is a radical overhaul of the lock file policy > issue. Also, it may harm performance. On the other hand, > our benchmarks on JNI overhead for modern processors indicate > performance impact should be minimal. Perhaps it is more of > an issue with the toybox systems. > > Suppose there were a class with a reasonable default...someone > might write: > SerialPortLockPolicy.setPolicy(SerialPortLockPolicy.UNIX_LOCK_FILE); > SerialPortLockPolicy.setPolicy(SerialPortLockPolicy.NO_LOCK_CHECKING); > SerialPortLockPolicy.setPolicy(SerialPortLockPolicy.MAC_STYLE); > > Thus, we could have a run-time reconfiguration of the serial port lock > policy. A special NO_LOCK version of the binary would no longer > be required. > > Any thoughts on this? > > Thanks! > - Doug > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From joachim at buechse.de Tue Mar 21 06:23:08 2006 From: joachim at buechse.de (Joachim Buechse) Date: Tue, 21 Mar 2006 14:23:08 +0100 Subject: [Rxtx] PATCH: use of ioctl(fd, TIOCEXCL) instead of lockfiles Message-ID: <923AE774-EEA2-4911-92D8-32BB27802C8B@buechse.de> Here is the patch for the ioctl(fd, TIOCEXCL). I have verified this only for OSX 10.4.5, hence it is only defined for APPLE. However, it should work at least for Solaris as well. If a process has requested TIOEXCL further open calls by other user processes will fail. The patch also disables uucp style locking for APPLE. Obviously this is discussable. I think it is the way to go, as it eliminates creating the lock directory which doesnt exist on the standard installation and it eliminates messing with the system group definitions (adding users to group uucp). Regarding the possibility of root processes opening a device which is locked - I consider this a feature not a potential problem. It is highly unlikely, that somebody is crazy enough to run a JavaVM as root (unless he has no other means of getting a restricted IP port opened, ie doesnt understand ipfw). Anyway, even if the process runs as root, it fails when calling ioctl(fd, TIOCEXCL). It could however still open the port to listen for RING events. I.e. a fax server which needs to see incoming calls but otherwise doesnt want to block the port. So the only case where the proposed mechanism fails is, if an incorrectly implemented process running as root conflicts with a user process. I think this can be accepted. Regards, Joachim PS: If this patch is generally accepted, the installer and Mac doku should obviously be changed as well. Index: SerialImp.c =================================================================== RCS file: /usr/local/cvsroot/rxtx-devel/src/SerialImp.c,v retrieving revision 1.46.2.187 diff -u -r1.46.2.187 SerialImp.c --- SerialImp.c 29 Jan 2006 22:19:04 -0000 1.46.2.187 +++ SerialImp.c 21 Mar 2006 12:59:16 -0000 @@ -656,6 +656,25 @@ fd=OPEN (filename, O_RDWR | O_NOCTTY | O_NONBLOCK ); } while (fd < 0 && errno==EINTR); +#ifdef OPEN_EXCL + // Note that open() follows POSIX semantics: multiple open() calls to + // the same file will succeed unless the TIOCEXCL ioctl is issued. + // This will prevent additional opens except by root-owned processes. + // See tty(4) ("man 4 tty") and ioctl(2) ("man 2 ioctl") for details. + + if (fd >= 0 && (ioctl(fd, TIOCEXCL) == -1)) + { + sprintf( message, "open: exclusive access denied for % s\n", + filename ); + report( message ); + report_error( message ); + + close(fd); + goto fail; + } +#endif /* OPEN_EXCL */ + + if( configure_port( fd ) ) goto fail; (*env)->ReleaseStringUTFChars( env, jstr, filename ); sprintf( message, "open: fd returned is %i\n", fd ); Index: SerialImp.h =================================================================== RCS file: /usr/local/cvsroot/rxtx-devel/src/SerialImp.h,v retrieving revision 1.11.2.49 diff -u -r1.11.2.49 SerialImp.h --- SerialImp.h 5 Jul 2005 17:47:21 -0000 1.11.2.49 +++ SerialImp.h 21 Mar 2006 12:59:17 -0000 @@ -135,7 +135,8 @@ /*# define LOCKDIR "/var/spool/uucp"*/ # define LOCKDIR "/var/lock" # define LOCKFILEPREFIX "LK." -# define UUCP +/*# define UUCP*/ +# define OPEN_EXCL #endif /* __APPLE__ */ #if defined(__NetBSD__) # define DEVICEDIR "/dev/" From tjarvi at qbang.org Tue Mar 21 10:26:08 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 21 Mar 2006 10:26:08 -0700 (MST) Subject: [Rxtx] Javadoc on the go In-Reply-To: <441FA98B.9050701@ngi.it> References: <441FA98B.9050701@ngi.it> Message-ID: On Tue, 21 Mar 2006, Fabio Frumento wrote: > Hi Trent, > > sorry for the big delay but my job is running wild, i was out for some > time but now i'm back and ready to continue the javadoc for Rxtx. > > Did you used the last javadoc patch i sent you ? let me know if i have to > send it to you again or not. > > regards > > Fabio Hi Fabio The patch is in the rxtx mail-list archives. It will be going in soon. I did not see a time critical portion. I'll probably be going through the list since the last batch of patches this weekend and putting them into CVS. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Tue Mar 21 10:57:18 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 21 Mar 2006 10:57:18 -0700 (MST) Subject: [Rxtx] jvm issue In-Reply-To: <20060321065524.94779.qmail@web50701.mail.yahoo.com> References: <20060321065524.94779.qmail@web50701.mail.yahoo.com> Message-ID: On Mon, 20 Mar 2006, Lambok Sianturi wrote: > Hi All, > This is my first time to join RxTx mailing list. I thank you all for allowing others to sign in in requests help. > I use the latest RxTx lib in Fedora 3 with java version 1.4.2_09 b05. And I got this error: > > # > # An unexpected error has been detected by HotSpot Virtual Machine: > # > # SIGSEGV (0xb) at pc=0x00bf27f3, pid=2633, tid=3086112448 > # > # Java VM: Java HotSpot(TM) Client VM (1.4.2_09-b05 mixed mode) > # Problematic frame: > # C [ld-linux.so.2+0xa7f3] A native library loading error? What happens if you recompile rxtx on your system and install that? This sounds like an ABI problem? rxtx 2.1-7 was compiled with a gcc 2.96 toolchain as I recall. The hope is newer system will be backwards compatible. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Tue Mar 21 11:05:29 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 21 Mar 2006 11:05:29 -0700 (MST) Subject: [Rxtx] PATCH: use of ioctl(fd, TIOCEXCL) instead of lockfiles In-Reply-To: <923AE774-EEA2-4911-92D8-32BB27802C8B@buechse.de> References: <923AE774-EEA2-4911-92D8-32BB27802C8B@buechse.de> Message-ID: On Tue, 21 Mar 2006, Joachim Buechse wrote: > Here is the patch for the ioctl(fd, TIOCEXCL). I have verified this only > for OSX 10.4.5, hence it is only defined for APPLE. However, it should > work at least for Solaris as well. > > If a process has requested TIOEXCL further open calls by other user > processes will fail. > > The patch also disables uucp style locking for APPLE. Obviously this is > discussable. I think it is the way to go, as it eliminates creating the > lock directory which doesnt exist on the standard installation and it > eliminates messing with the system group definitions (adding users to > group uucp). > > Regarding the possibility of root processes opening a device which is > locked - I consider this a feature not a potential problem. It is highly > unlikely, that somebody is crazy enough to run a JavaVM as root (unless > he has no other means of getting a restricted IP port opened, ie doesnt > understand ipfw). Anyway, even if the process runs as root, it fails when > calling ioctl(fd, TIOCEXCL). It could however still open the port to > listen for RING events. I.e. a fax server which needs to see incoming > calls but otherwise doesnt want to block the port. So the only case where > the proposed mechanism fails is, if an incorrectly implemented process > running as root conflicts with a user process. I think this can be > accepted. > > Regards, > Joachim > > PS: If this patch is generally accepted, the installer and Mac doku > should obviously be changed as well. > > > Index: SerialImp.c > =================================================================== > RCS file: /usr/local/cvsroot/rxtx-devel/src/SerialImp.c,v > retrieving revision 1.46.2.187 > diff -u -r1.46.2.187 SerialImp.c > --- SerialImp.c 29 Jan 2006 22:19:04 -0000 1.46.2.187 > +++ SerialImp.c 21 Mar 2006 12:59:16 -0000 > @@ -656,6 +656,25 @@ > fd=OPEN (filename, O_RDWR | O_NOCTTY | O_NONBLOCK ); > } while (fd < 0 && errno==EINTR); > > +#ifdef OPEN_EXCL > + // Note that open() follows POSIX semantics: multiple open() > calls to > + // the same file will succeed unless the TIOCEXCL ioctl is > issued. > + // This will prevent additional opens except by root-owned > processes. > + // See tty(4) ("man 4 tty") and ioctl(2) ("man 2 ioctl") for > details. > + > + if (fd >= 0 && (ioctl(fd, TIOCEXCL) == -1)) > + { > + sprintf( message, "open: exclusive access denied for % > s\n", > + filename ); > + report( message ); > + report_error( message ); > + > + close(fd); > + goto fail; > + } > +#endif /* OPEN_EXCL */ > + > + > if( configure_port( fd ) ) goto fail; > (*env)->ReleaseStringUTFChars( env, jstr, filename ); > sprintf( message, "open: fd returned is %i\n", fd ); > Index: SerialImp.h > =================================================================== > RCS file: /usr/local/cvsroot/rxtx-devel/src/SerialImp.h,v > retrieving revision 1.11.2.49 > diff -u -r1.11.2.49 SerialImp.h > --- SerialImp.h 5 Jul 2005 17:47:21 -0000 1.11.2.49 > +++ SerialImp.h 21 Mar 2006 12:59:17 -0000 > @@ -135,7 +135,8 @@ > /*# define LOCKDIR "/var/spool/uucp"*/ > # define LOCKDIR "/var/lock" > # define LOCKFILEPREFIX "LK." > -# define UUCP > +/*# define UUCP*/ > +# define OPEN_EXCL > #endif /* __APPLE__ */ > #if defined(__NetBSD__) > # define DEVICEDIR "/dev/" > This looks like a good start. What do you think Dmitry? Perhaps all systems with TIOCEXCL defined should use that though. Even if they use lockfiles. It wont hurt anything. That would catch people hacking their own serial apps without checking lockfiles. Its a good idea to avoid C++ style comments in the C portions. Some older systems don't deal with them well. If it's just for Mac OS X, it isn't a big deal. I think it was the Irix compiler that was problematic? -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Tue Mar 21 11:22:05 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 21 Mar 2006 11:22:05 -0700 (MST) Subject: [Rxtx] lock files In-Reply-To: <8E12916A-1B9A-4FF2-B684-E2D1C794221B@buechse.de> References: <8E12916A-1B9A-4FF2-B684-E2D1C794221B@buechse.de> Message-ID: We can try it. Maybe the JNI is much improved. The nice thing about linking into liblock is distros then worry about lockfiles on their systems. This way, we have to deal with any changes that may show up. On Tue, 21 Mar 2006, Joachim Buechse wrote: > This is pretty much what I thought about when I suggested, that the > default behaviour could be overwritten with a property. I am very much in > favor of this approach. In particular this allows much easier debugging > for PC based java developers. > > I think big parts of the Java (and maybe some parts of the C code) could > use a bit of a structural workover (unit tests, javadoc, synchronization, > etc). Maybe there should be a CVS branch for this experimental version. > I'd be happy to contribute a first workover for some of the Java code. > Designing for testability and implementing a good bunch of unit tests has > been a strategy that worked quite well in the Java projects I lead. And > it ultimately allows more liberal change permission. > > Regards, > Joachim > > > On 21.03.2006, at 08:51, Dr. Douglas Lyon wrote: > >> Hi All, >> You know, if the use of lock files were >> under Java control (rather than a build-time decision), >> it might enable a more unified binary distro. It might also >> facilitate quick prototyping of non-lock file approaches >> to resolving serial port contention issues (i.e., mac-like >> approaches vs. linux approaches, etc.). >> >> I realize that this is a radical overhaul of the lock file policy >> issue. Also, it may harm performance. On the other hand, >> our benchmarks on JNI overhead for modern processors indicate >> performance impact should be minimal. Perhaps it is more of >> an issue with the toybox systems. >> >> Suppose there were a class with a reasonable default...someone >> might write: >> SerialPortLockPolicy.setPolicy(SerialPortLockPolicy.UNIX_LOCK_FILE); >> SerialPortLockPolicy.setPolicy(SerialPortLockPolicy.NO_LOCK_CHECKING); >> SerialPortLockPolicy.setPolicy(SerialPortLockPolicy.MAC_STYLE); >> >> Thus, we could have a run-time reconfiguration of the serial port lock >> policy. A special NO_LOCK version of the binary would no longer >> be required. >> >> Any thoughts on this? >> >> Thanks! >> - Doug >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From dmarkman at mac.com Tue Mar 21 16:05:17 2006 From: dmarkman at mac.com (Dmitry Markman) Date: Tue, 21 Mar 2006 18:05:17 -0500 Subject: [Rxtx] PATCH: use of ioctl(fd, TIOCEXCL) instead of lockfiles In-Reply-To: References: <923AE774-EEA2-4911-92D8-32BB27802C8B@buechse.de> Message-ID: <512AC70C-BB86-48F2-A83C-023F35C23BAB@mac.com> I think it's cool, but I'd like to have that property implementation when user can choose between locking mechanism about comments: it's easy to change comments to the C style or we can use extensions of the file to cpp so c++ compiler will be used On Mar 21, 2006, at 1:05 PM, Trent Jarvi wrote: > This looks like a good start. What do you think Dmitry? Perhaps > all systems with TIOCEXCL defined should use that though. Even if > they use lockfiles. It wont hurt anything. That would catch > people hacking their own serial apps without checking lockfiles. > > Its a good idea to avoid C++ style comments in the C portions. > Some older systems don't deal with them well. If it's just for Mac > OS X, it isn't a big deal. I think it was the Irix compiler that > was problematic? Dmitry Markman From dmarkman at mac.com Tue Mar 21 16:13:00 2006 From: dmarkman at mac.com (Dmitry Markman) Date: Tue, 21 Mar 2006 18:13:00 -0500 Subject: [Rxtx] PATCH: use of ioctl(fd, TIOCEXCL) instead of lockfiles In-Reply-To: References: <923AE774-EEA2-4911-92D8-32BB27802C8B@buechse.de> Message-ID: I'd like to add that creating locking folder isn't a big deal we never had a problem related to the lock folders, because we always used installer on mac os x from other hand I'm not very much familiar with iotcl locking approach and I'm not sure it's more efficient Joachim wrote "I think it is the way to go, as it eliminates creating the lock directory which doesnt exist on the standard installation and it eliminates messing with the system group definitions (adding users to group uucp)." but I really didn't have any problem with that 1. doesn't exist on the standard installation there are many-many things that don't exist in the standard installation so I don't think that argument is strong enough 2. messing with the system group definitions I don't think we're messing with the group definition mac os x provides very clear way to set up group's members and together with Greg Guerin AuthKit there is no problem to set those definitions so I don't think that argument is strong either but from other hand using iotcl is more promising and is more elegant On Mar 21, 2006, at 1:05 PM, Trent Jarvi wrote: > > This looks like a good start. What do you think Dmitry? Perhaps > all systems with TIOCEXCL defined should use that though. Even if > they use lockfiles. It wont hurt anything. That would catch > people hacking their own serial apps without checking lockfiles. Dmitry Markman From joachim at buechse.de Wed Mar 22 04:46:45 2006 From: joachim at buechse.de (Joachim Buechse) Date: Wed, 22 Mar 2006 12:46:45 +0100 Subject: [Rxtx] PATCH: use of ioctl(fd, TIOCEXCL) instead of lockfiles In-Reply-To: References: <923AE774-EEA2-4911-92D8-32BB27802C8B@buechse.de> Message-ID: Sorry, I was not very clear with my arguments, so I will try again;-) Please, don't take this as an attack against work that has been done. I think the contributions that have been made in the past were made in a good spirit. But I really believe, that the current solution for OSX has many shortcomings and should be changed as soon as possible. lock files --- The /var/lock folder does not exist on the standard OSX installation, however the standard installation includes several applications that use serial ports (i.e. the FAX capability). This indicates, that the lock folder approach will not work well with system components. Applications for OSX will generally try to live in harmony with system components (except for HP print drivers of course). I think RXTX should follow this approach as well. uucp group --- Accessing serial ports is not an admin privileged operation on OSX. Any user (world) has read/write privileges on /dev/tty*. So the system default is to not enforce any group membership to access these ports. The group uucp however is a system group on all unix systems I know. It exists for certain system processes. A non admin user should in general not be a member of this group. Quite arguably no user should ever be a member of this group. Installer --- My general opinion is, that - no Installer should touch user or group data without warning - no Application Installer should touch groups which are not specific to the very application installed - no Installer should ever add regular users to a system group The current installer injects the installing user in the group uucp without warning about this change and without giving the option to "opt out" of this change. This is a potential security risk (but not currently a real one, as OSX contains no folders belonging to group uucp). The current installer does not work for multi user systems. It puts the installing user in the uucp group. However the installing user is not necessarily the user that will use the application. Putting all users that may use a serial port application in the system group uucp seems like a very invasive approach to me. Besides that, newly created users will not automatically be in the group and hence, serial applications will "break" for new users without obvious reasons. Avoiding the lock files will allow self contained applications (i.e. drag&drop installation). In my eyes this is largely preferable over an installer that requests admin privileges. Adding up all these points indicates very strongly, that the lock-file implementation is not the way to go on OSX. Regards, Joachim On 22.03.2006, at 00:13, Dmitry Markman wrote: > I'd like to add that > > creating locking folder isn't a big deal > we never had a problem related to the lock folders, because we > always used installer on mac os x > from other hand I'm not very much familiar with iotcl locking > approach and I'm not sure it's more efficient > > Joachim wrote "I think it is the way to go, as it eliminates > creating the lock directory which doesnt exist on the standard > installation and it eliminates messing with the system group > definitions (adding users to group uucp)." but I really didn't have > any problem with that > > 1. doesn't exist on the standard installation > there are many-many things that don't exist in the standard > installation so I don't think that argument is strong enough > 2. messing with the system group definitions > I don't think we're messing with the group definition > mac os x provides very clear way to set up group's members and > together with Greg Guerin AuthKit there is no problem to set those > definitions > so I don't think that argument is strong either > but from other hand using iotcl is more promising and is more elegant > > > > On Mar 21, 2006, at 1:05 PM, Trent Jarvi wrote: > >> >> This looks like a good start. What do you think Dmitry? Perhaps >> all systems with TIOCEXCL defined should use that though. Even if >> they use lockfiles. It wont hurt anything. That would catch >> people hacking their own serial apps without checking lockfiles. > > Dmitry Markman > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From dmarkman at mac.com Wed Mar 22 05:27:13 2006 From: dmarkman at mac.com (Dmitry Markman) Date: Wed, 22 Mar 2006 07:27:13 -0500 Subject: [Rxtx] PATCH: use of ioctl(fd, TIOCEXCL) instead of lockfiles In-Reply-To: References: <923AE774-EEA2-4911-92D8-32BB27802C8B@buechse.de> Message-ID: <83440CF3-DCD8-41C1-B941-F227232C27E3@mac.com> thanks for the very good explanation I didn't think that you were attacking any thing, so don't worry I just had feeling, that there were more aesthetic reasons for going to ioctl then real necessity now you explained everything quite well (BTW, asfar as I remember installer asks admin password so it wasn't quiet, but it really doesn't matter now) thanks On Mar 22, 2006, at 6:46 AM, Joachim Buechse wrote: > Sorry, I was not very clear with my arguments, so I will try again;-) > > Please, don't take this as an attack against work that has been > done. I think the contributions that have been made in the past > were made in a good spirit. But I really believe, that the current > solution for OSX has many shortcomings and should be changed as > soon as possible. > > lock files > --- > The /var/lock folder does not exist on the standard OSX > installation, however the standard installation includes several > applications that use serial ports (i.e. the FAX capability). This > indicates, that the lock folder approach will not work well with > system components. Applications for OSX will generally try to live > in harmony with system components (except for HP print drivers of > course). I think RXTX should follow this approach as well. > > uucp group > --- > Accessing serial ports is not an admin privileged operation on OSX. > Any user (world) has read/write privileges on /dev/tty*. So the > system default is to not enforce any group membership to access > these ports. The group uucp however is a system group on all unix > systems I know. It exists for certain system processes. A non admin > user should in general not be a member of this group. Quite > arguably no user should ever be a member of this group. > > Installer > --- > My general opinion is, that > - no Installer should touch user or group data without warning > - no Application Installer should touch groups which are not > specific to the very application installed > - no Installer should ever add regular users to a system group > > The current installer injects the installing user in the group uucp > without warning about this change and without giving the option to > "opt out" of this change. This is a potential security risk (but > not currently a real one, as OSX contains no folders belonging to > group uucp). > > The current installer does not work for multi user systems. It puts > the installing user in the uucp group. However the installing user > is not necessarily the user that will use the application. Putting > all users that may use a serial port application in the system > group uucp seems like a very invasive approach to me. Besides that, > newly created users will not automatically be in the group and > hence, serial applications will "break" for new users without > obvious reasons. > > > Avoiding the lock files will allow self contained applications > (i.e. drag&drop installation). In my eyes this is largely > preferable over an installer that requests admin privileges. Adding > up all these points indicates very strongly, that the lock-file > implementation is not the way to go on OSX. > > Regards, > Joachim > > > On 22.03.2006, at 00:13, Dmitry Markman wrote: > >> I'd like to add that >> >> creating locking folder isn't a big deal >> we never had a problem related to the lock folders, because we >> always used installer on mac os x >> from other hand I'm not very much familiar with iotcl locking >> approach and I'm not sure it's more efficient >> >> Joachim wrote "I think it is the way to go, as it eliminates >> creating the lock directory which doesnt exist on the standard >> installation and it eliminates messing with the system group >> definitions (adding users to group uucp)." but I really didn't >> have any problem with that >> >> 1. doesn't exist on the standard installation >> there are many-many things that don't exist in the standard >> installation so I don't think that argument is strong enough >> 2. messing with the system group definitions >> I don't think we're messing with the group definition >> mac os x provides very clear way to set up group's members and >> together with Greg Guerin AuthKit there is no problem to set those >> definitions >> so I don't think that argument is strong either >> but from other hand using iotcl is more promising and is more elegant >> >> >> >> On Mar 21, 2006, at 1:05 PM, Trent Jarvi wrote: >> >>> >>> This looks like a good start. What do you think Dmitry? Perhaps >>> all systems with TIOCEXCL defined should use that though. Even >>> if they use lockfiles. It wont hurt anything. That would catch >>> people hacking their own serial apps without checking lockfiles. >> >> Dmitry Markman >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx Dmitry Markman From lyon at docjava.com Wed Mar 22 06:12:18 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Wed, 22 Mar 2006 08:12:18 -0500 Subject: [Rxtx] sole of a new design pattern Message-ID: Hi All, I have been thinking about how we design the serial port software. I think we need a new design pattern. For lack of a better term, I shall call it: The Parametric Singleton Design Pattern By Douglas A. Lyon ABSTRACT The goal of the singleton design pattern is to make sure that there is one, and only one, instance of a given class. The goal of the parametric singleton design pattern is to make sure that there is one, and only one, instance of a given class with the given parametric values. We parametric singleton design pattern combines the singleton design pattern with a parameter that enables unique creation of instances of a class. These instances are cached. When a user asks for an instance with these parameters, the cache is checked. If the instance is in the cache, the instance is returned, otherwise it is created, added to the cache and then returned. We apply our parametric singleton design pattern to the retrieval of RMI registries bound to a given port. The goal of our system is to make sure that no two RMI registries are listening to the same socket and to make use of the RMI registries after they have been created. RMI registries are used in distributed computation. Introduction The singleton design pattern is meant to ensure that on a single instance of a class exists. It is also meant to provide a global point of access to it. The intent of the parametric singleton design pattern is to ensure that a class has only one instance for a given set of parameter values. It also provides a global point of access to it. Motivation A system cannot tolerate multiple instances of some classes with identical parameters. For example, you cannot have two instances making use of the same serial port, at the same time. You cannot have two instances that are trying to listen to the same socket connection. You cannot have two instances writing to the same file structure at the same time. As the operating system is often thought of as the arbiter of consumed resources (i.e., tape drives, serial ports, etc.) we frequently leave it to an operating system implementation to resolve these contention issues. Even for similar resources (like serial ports) there are few standards for handling contention. For example, serial ports on Linux are locked using a "/var/lock" file. POSIX, on the other hand, uses ioctl mechanisms to prevent contention. A better solution is to make a class that is responsible for keeping track of the instances created from the class. The class is declared final, so that it cannot be subclassed. The class also has a private constructor, so that other classes cannot instance it. The new design pattern is called the parametric singleton design pattern and it provides a way to access and create instances with given parameters. Applicability Use the Parametric Singleton Design Pattern when: 1. There must be exactly one instance of a class with the given parameters. 2. The instances must be accessible to clients from a well-known access point. Structure Insert UML diagram here. Participants The Parametric Singleton Clients that need instances 1. The Parametric Singleton defines an instance upon request from a client, if, and only if, the instance does not already exist. 2. The Parametric Singleton returns the instance to the client. 3. The Parametric Singleton is responsible for creating unique instances from given parameters. Collaborations Clients obtain a reference to a Parametric Singleton instance only through the parametric singleton design pattern. If the instance is left in an improper state (e.g., the serial port was left open) it is NOT the role of the Parametric Singleton Design Pattern to close the IO port. Nor is it the role of the Parametric Singleton Design Pattern to open the port. That role is delegate to some other part of the system. Further, it is not the role of the Parametric Singleton Design Pattern to check out resources. That is, multiple threads can have multiple references to the same resource at the same time. MUTEX locking is delegated to some other part of the system. Consequences The Parametric Singleton Design Pattern has several benefits: 1. Controlled access to parametrically defined instances. Since the Parametric Singleton class encapsulates its instances, there is control over how and when clients access it. 2. Reduced name space. The Parametric Singleton pattern avoids global variables that store instances created from the same parameter. Implementation Here are implementation issues to consider when using the Parametric Singleton pattern: 1. Unique mapping of parameters. The Parametric Singleton pattern requires that there be a mean to isomorphically map the parameter space into the instance space and back again. 2. Ensure unique instances. The Parametric Singleton pattern makes unique instances from parameters, and it does so only once. 3. Cache instances for fast retrieval. The Parametric Singleton pattern must be able to look up instances, given some set of parameters, and do so from some data structure. That is, there must be enough space to hold references to all the instances the program will need. Also, a mechanism is needed to look up and retrieve the instances quickly enough to satisfy the clients. Sample Code public final class ParametricSingletonRmiRegistry { private static Hashtable registry = new Hashtable(100); // use singleton pattern and??????????????????????????????????????????????? // prevent instantiation of RmiRegistryUtils.?????????????????????????????? private ParametricSingletonRmiRegistry() { } // the only instance of the Registry held by the RmiRegistryUtils?????????? public static void listNames(Integer port) { if (!isInCacheAndRunning(port)) return; Registry r = (Registry) registry.get(port); System.out.println("registry on port: " + port); System.out.println("registry: " + r); System.out.println("names: "); try { print(r.list()); } catch (RemoteException e) { In.message(e); } System.out.println("------------------------"); } /**???????????????????????????????????????????????????????????????????????? * Checks whether a Registry has been started on this host????????????????? * in the specified port.?????????????????????????????????????????????????? * If not, it tries to start one.?????????????????????????????????????????? * when it fails to start a Registry, it exits the program????????????????? * with exit code 1.??????????????????????????????????????????????????????? */ public static void restart(int port) { if (isInCacheAndRunning(port)) return; try { startRegistry(port); } catch (RemoteException e) { In.message(e); } } /**???????????????????????????????????????????????????????????????????????? * @param port????????????????????????????????????????????????????????????? * @return true if registry is in cache and running???????????????????????? */ private static boolean isInCacheAndRunning(Integer port) { if (!isRegistryRunning(port.intValue())) return false; if (!isRegistryInCache(port.intValue())) return false; return true; } /**???????????????????????????????????????????????????????????????????????? * @param port????????????????????????????????????????????????????????????? * @return true if we are able to locate a local registry on port.??????????????????????????????????????????????????????????????????????????? */ private static boolean isRegistryRunning(int port) { try { Registry r = LocateRegistry.getRegistry(port); if (r != null) return true; } catch (RemoteException e) { return false; } return false; } /**???????????????????????????????????????????????????????????????????????? * @param port????????????????????????????????????????????????????????????? * @return return true if registry is in cache????????????????????????????? */ private static boolean isRegistryInCache(int port) { if (registry.get(new Integer(port)) == null) return false; return true; } /**???????????????????????????????????????????????????????????????????????? * Restart the registry, if needed.???????????????????????????????????????? * Return the only instance of the registry for consistent global?????????? * using by making use of the Singleton Design Pattern????????????????????? *????????????????????????????????????????????????????????????????????????? * @return the internally held registry instance.?????????????????????????? */ public static Registry getRegistry(Integer port) { restart(port); return (Registry) registry.get(port); } private static void startRegistry(Integer port) throws RemoteException { Registry r; try { r = LocateRegistry.createRegistry(port.intValue()); registry.put(port, r); //r = new sun.rmi.registry.RegistryImpl???????????????????????????? /// (port.intValue());?????????????????????????????????????? // registry.put(port, r);?????????????????????????????????????????? } catch (Exception e) { //e.printStackTrace();????????????????????????????????????????????? r = LocateRegistry.getRegistry(port.intValue()); registry.put(port, r); } } public static void main(String args[]) throws RemoteException { //restart(port);??????????????????????????????????????????????????????? restart(5001); restart(5002); restart(5002); Registry r = LocateRegistry.getRegistry(5002); System.out.println("registry="+r); } } I would very much like to get your feedback on this new design pattern idea. Thank you for your time. Regards, - Doug From david.garnier at trusted-logic.com Wed Mar 22 07:36:10 2006 From: david.garnier at trusted-logic.com (David Garnier) Date: Wed, 22 Mar 2006 15:36:10 +0100 Subject: [Rxtx] sole of a new design pattern In-Reply-To: References: Message-ID: <442160DA.80107@trusted-logic.com> Hello, > The Parametric Singleton Design Pattern The Singleton is the most abused design pattern ever. Good use-cases for this pattern are extremely rare and mostly confined to problems related to hardware resources, like serial ports. > Applicability > > Use the Parametric Singleton Design Pattern when: > 1. There must be exactly one instance of a class with the given > parameters. OK. As I said above, this case this actually very unusual. The Singleton pattern is mostly used when : > 2. The instances must be accessible to clients from a well-known > access point. Using the singleton pattern in this case is just convenient for the programmer. Problems arises pretty quickly, especially if you attempt to unit-test your classes. 1) If your singleton is stateful, or hold on to stateful objects, it means that two different unit tests are not actually independent. Instead of starting with a brand new environment, the result of a test may be affected by the result of a previous test. This problem also arise when with your class relies on a database. In both cases, the solution is to reset your "unique" resource (Singleton or database) at the beginning of the test, which is a pain. Also, while most projects connect to a single database, projects that allow the use of Singletons usually contain several of thems, and new ones may cropped up unnoticed. You quickly end up with test cases that only pass in a certain order, which is a royal pain. 2) You cannot mockup a singleton. Once everyone calls the SomeSingleton class statically, you can't replace your class by SomeSingletonMockup. Furthermore, even for hardware services, the Singleton pattern does not really prevent concurrent accesses. If you start the same program in two different JVMs, unless they somehow shared the state of their "Singletons" (through lock files for example), the Singleton pattern will not prevent concurrent access. Our application uses RXTX, and we routinely encounter cases where another (native) application has already locked the port. Since we cannot modify the native application to recognize lock files, OS-level control is irreplaceable. > > Consequences > The Parametric Singleton Design Pattern has several benefits: > > 1. Controlled access to parametrically defined instances. Since > the Parametric Singleton class encapsulates its instances, there is > control over how and when clients access it. Not really. Once you've returned the instance to a client, you've lost control over it. The client can to whatever it wants with it. You cannot "recall" the instance or claim it back. > 2. Reduced name space. The Parametric Singleton pattern avoids > global variables that store instances created from the same parameter. Sure, but you don't have to rely on a Singleton for that. Just create a single Factory. > I would very much like to get your feedback on this new design > pattern idea. Well, it's nothing new. Some may say that it is the point of design patterns: formalizes the designs that occur again and again. However, this design is simply a combination of the Singleton and Factory patterns. I did use it in the past, but now I've been exposed to the shortcomings of the Singleton pattern, so I limit myself to Factories. Regards, David From sean_montgomery at baseview.com Wed Mar 22 08:35:28 2006 From: sean_montgomery at baseview.com (Sean Montgomery) Date: Wed, 22 Mar 2006 10:35:28 -0500 Subject: [Rxtx] sole of a new design pattern In-Reply-To: <442160DA.80107@trusted-logic.com> References: <442160DA.80107@trusted-logic.com> Message-ID: <05769CA7-A51B-4CF0-BAA0-E02DD905F5A4@baseview.com> On Mar 22, 2006, at 9:36 AM, David Garnier wrote: > Furthermore, even for hardware services, the Singleton pattern does > not really prevent concurrent > accesses. If you start the same program in two different JVMs, > unless they somehow shared the state > of their "Singletons" (through lock files for example), the > Singleton pattern will not prevent > concurrent access. > Multiple class loaders in a single JVM can be tricky, too. Then there's synchronization, lazy initialization and serialization of singletons to contend with. Bloch's Effective Java covers these, and here's a few articles: http://www.javaworld.com/javaworld/jw-04-2003/jw-0425-designpatterns- p3.html http://java.sun.com/developer/technicalArticles/Programming/singletons/ Just FYI :-) From lyon at docjava.com Wed Mar 22 08:50:48 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Wed, 22 Mar 2006 10:50:48 -0500 Subject: [Rxtx] sole of a new design pattern In-Reply-To: <442160DA.80107@trusted-logic.com> References: <442160DA.80107@trusted-logic.com> Message-ID: Hi All, First, I would like to thank David for his prompt and thoughtful remarks. I had no idea people that feel strongly about a design patterns! Wow! Feedback (particularly critical feedback) is greatly appreciated. Starting at the end, first: >I did use it in >the past, but now I've been exposed to the shortcomings of the >Singleton pattern, so I limit myself to Factories. David, if I understood your comments correctly, you suggested that Factories can be used in leu of the Singleton Design Pattern, or even the Parametric Singleton Design Pattern. As I see in [Gof]: Factory Method: Intent "Define an interface for creating an object, but let subclasses decide which class to instantiate. Factory Method lets a class defer instantiation to subclasses." The Singleton Design Pattern is a concrete class, which is rather different, right? Also, subclasses are not permitted with Singleton, as they are final. Naturally, I could use an abstract factory as a parent for a singleton. I could even design a facade that could be implemented with the singleton....but that is not the intention of the design. Unless you want a mock-up, as discussed, below: More below: >Hello, > >> The Parametric Singleton Design Pattern > >The Singleton is the most abused design pattern ever. Good use-cases >for this pattern are extremely >rare and mostly confined to problems related to hardware resources, >like serial ports. > > >> Applicability >> >> Use the Parametric Singleton Design Pattern when: >> 1. There must be exactly one instance of a class with the given >> parameters. >OK. As I said above, this case this actually very unusual. The >Singleton pattern is mostly used when : >> 2. The instances must be accessible to clients from a well-known >> access point. > >Using the singleton pattern in this case is just convenient for the >programmer. Problems arises >pretty quickly, especially if you attempt to unit-test your classes. > >1) If your singleton is stateful, or hold on to stateful objects, it >means that two different unit >tests are not actually independent. Instead of starting with a brand >new environment, the result of >a test may be affected by the result of a previous test. This >problem also arise when with your >class relies on a database. In both cases, the solution is to reset >your "unique" resource >(Singleton or database) at the beginning of the test, which is a >pain. Also, while most projects >connect to a single database, projects that allow the use of >Singletons usually contain several of >thems, and new ones may cropped up unnoticed. You quickly end up >with test cases that only pass in a >certain order, which is a royal pain. There are basic problems with communicating finite state machines that include reachability and deadlock analysis. These are addressed with petri net analysis and are beyond the scope of the design pattern. As you quite rightly pointed out; the parametric singleton pattern (or the singleton pattern, for that matter) enable multiple threads to gain access to the same instance. The only way that I can see to block others from gaining access to the reference is the synchronize keyword. This is putting a spin-lock (or MUTEX) on the reference. The question of how to unit-test a design pattern like the parametric singleton remains open. Perhaps this is a deficiency. > >2) You cannot mockup a singleton. Once everyone calls the >SomeSingleton class statically, you can't >replace your class by SomeSingletonMockup. Acutally, I am not sure that this is true. If the Singleton implements a Facade interface, it should be possible to make the replacement. Right? > >Furthermore, even for hardware services, the Singleton pattern does >not really prevent concurrent >accesses. If you start the same program in two different JVMs, >unless they somehow shared the state >of their "Singletons" (through lock files for example), the >Singleton pattern will not prevent >concurrent access. Good Point!! You have sharp eyes! The singleton design pattern should/could take responsibility for this. In fact, you may notice that my code does have an implementation (LocateRegistry) that can work across JVM's. The LocateRegistry will even work across the Internet! LocateRegistry takes both a host name and a Port (lock files just don't do this). I did not think to implement this beyond the local machine, but, in its present form, it will work across different processes. > >Our application uses RXTX, and we routinely encounter cases where >another (native) application has >already locked the port. Since we cannot modify the native >application to recognize lock files, >OS-level control is irreplaceable. The singleton design pattern is not meant to replace OS-level control, but to centralize the Java programmers access to it. If lock files, for example, are used for serial ports, the Singleton Design Pattern should be able to work with them. > > >> >> Consequences >> The Parametric Singleton Design Pattern has several benefits: >> > > 1. Controlled access to parametrically defined instances. Since >> the Parametric Singleton class encapsulates its instances, there is >> control over how and when clients access it. > >Not really. Once you've returned the instance to a client, you've >lost control over it. The client >can to whatever it wants with it. You cannot "recall" the instance >or claim it back. Good point, this should read: > 1. Controll when parametrically defined instances are created. Since > > the Parametric Singleton class encapsulates its instances, there is > > control over how and when they are instanced. > >> 2. Reduced name space. The Parametric Singleton pattern avoids >> global variables that store instances created from the same parameter. > >Sure, but you don't have to rely on a Singleton for that. Just >create a single Factory. > > Thank you for your thoughtful and prompt response! Regards, - Doug From dmarkman at mac.com Wed Mar 22 21:21:55 2006 From: dmarkman at mac.com (Dmitry Markman) Date: Wed, 22 Mar 2006 23:21:55 -0500 Subject: [Rxtx] sole of a new design pattern In-Reply-To: <442160DA.80107@trusted-logic.com> References: <442160DA.80107@trusted-logic.com> Message-ID: I don't think I get it On Mar 22, 2006, at 9:36 AM, David Garnier wrote: > Using the singleton pattern in this case is just convenient for the > programmer. Problems arises > pretty quickly, especially if you attempt to unit-test your classes. so you're saying that something isn't so good because you can not test it in the convenient way? if that's true, I'm totally disagree change your test, debug whatever, but if software is efficient at runtime, works fine and only problem is some unit test (which is some kind of framework for testing) then dump that unit test , dump that unit framework and make something appropriate to the software you're testing so if Douglas want to use singletons, what's the problem? and what do you mean by abusing of singleton usage? of course singleton doesn't prevent concurrent access to the resource across the processes unless you're using some OS facility to prevent it, besides singleton as it was introduced is relevant only and only inside of the same process otherwise it's not singleton it's something else (let's say network singleton: so you have remote invocation facility and some factory method that return object created by that facility) I don't have any problem with using any kind of singletons. Parametric Singleton idea (if I understand it right) could be easily implemented in the following way: use a map populate map with instances of some class and key is your parameter (you can use lazy population too) if somebody ask the key check the value if it's null so resource is taken if somebody returns the resource put it back to the map public synchronized static Object getSomeResource(Object parameter); public synchronized static void returnResource(Object parameter); getSomeResource (inside of the same process) could return null in 2 cases 1. if somebody (from other thread for example) already took that resource 2. if OS API said that resource corresponded to that parameter (serial port with parameter = 1 (port #)) is locked and unavailable; I'm not sure that in case of serial ports we even need those Parametric Singletons (unless lock checking is a very expensive operation) just ask the OS about availability of that resource and if it's available give it away and then OS will lock it and therefore in next time somebody ask it just answer that resource is locked and return null for example system has 2 serial ports available so I ask getResource("tty"); or I ask getResource("Bluetooth-Modem"); and if OS is ok you can give tty or Bluetooth-Modem or both no need for any additional pattern I think back to the problem mac os x doesn't recognize locking via files, so it handles locking via some API an instance of the singleton in each process should recognize that resource is locked (by using that API) that's all we don't have to make things more complicate then they are just because there is some nice design pattern or nice unit test framework or whatever keep things simple, make them work fast, don't introduce middle layers unless you have really good reason to do so of course I could be entirely wrong, so sorry about that in advance thanks Dmitry Markman From tjarvi at qbang.org Wed Mar 22 22:31:41 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 22 Mar 2006 22:31:41 -0700 (MST) Subject: [Rxtx] sole of a new design pattern In-Reply-To: References: Message-ID: Hi Doug Interesting reading. So far I'm just reading and thinking. I have one question so far. " Clients obtain a reference to a Parametric Singleton instance only through the parametric singleton design pattern. If the instance is left in an improper state (e.g., the serial port was left open) it is NOT the role of the Parametric Singleton Design Pattern to close the IO port. Nor is it the role of the Parametric Singleton Design Pattern to open the port. That role is delegate to some other part of the system. " So when the clients obtain a reference to the singleton, can they assume the port is there? IE, would it be the singletons role to handle things like USB dongles being removed with event hints comming from the underlying OS. Hardware abstraction layer/HAL on Linux is an example of underlying OS events. I assume that role too is delegated to other parts of the system? -- Trent Jarvi tjarvi at qbang.org From lyon at docjava.com Thu Mar 23 08:10:33 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Thu, 23 Mar 2006 10:10:33 -0500 Subject: [Rxtx] Classes don't need goals, they need roles! In-Reply-To: References: Message-ID: Hi Trent, Yes, I think that the role of the Parametric Singleton Pattern is not to open or close serial ports, nor is it to perform error checking. On the other hand, if you were to combine the role of the Parametric Singleton Pattern with another role (like that of error checking) it might not be amiss. However, I generally caution programmers against adding multiple roles to classes, as this leads to monolithic designs. Thus a different class (NativeLibDetect) could have the role of determining if the native library can be loaded. Another class (SerialPortBean) can have the role of serializing the default state of the serial port, so that it can be recovered, from user preferences, at a later time. The SerialPortDetect could have the role of determining if the serial port is removed (i.e., a USB port was unplugged). My guess is that each class should have a different role in the system, in order to ease maintenance and testing...but I could be wrong about that. Thanks! - Doug >Hi Doug > >Interesting reading. So far I'm just reading and thinking. I have >one question so far. > >" > Clients obtain a reference to a Parametric Singleton instance only >through the parametric singleton design pattern. If the instance is >left in an improper state (e.g., the serial port was left open) it is >NOT the role of the Parametric Singleton Design Pattern to close the >IO port. Nor is it the role of the Parametric Singleton Design Pattern >to >open the port. That role is delegate to some other part of the system. >" > >So when the clients obtain a reference to the singleton, can they >assume the port is there? IE, would it be the singletons role to >handle things like USB dongles being removed with event hints >comming from the underlying OS. Hardware abstraction layer/HAL on >Linux is an example of underlying OS events. > >I assume that role too is delegated to other parts of the system? > >-- >Trent Jarvi >tjarvi at qbang.org >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From maximulo at yahoo.com Fri Mar 24 01:22:38 2006 From: maximulo at yahoo.com (Maximulo Majir) Date: Fri, 24 Mar 2006 00:22:38 -0800 (PST) Subject: [Rxtx] JavaPOS Message-ID: <20060324082238.66371.qmail@web38214.mail.mud.yahoo.com> Hi all! Hello Trent! From what i understand, RXTX or JavaComm APIs were not created solely for JavaPOS. In JavaPOS, we have the virtual method claim() which is separate from open(), but in our RXTX API, claiming is done every call to open(), we cant open the port if its claimed by another application. Would it be alright to suggest or ask to create a new method called claim(..)? Is there such thing as forceclaim() in RXTX? this could be the same as portownership transfer or its equivalent. ForceClaim is in JSR80. Do you have some samples using RXTX as the lower layer for the Device Service Objects in JavaPOS? I have tried it, i just want to compare. Thank you all! maxim __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060324/496adba2/attachment-0044.html From tjarvi at qbang.org Fri Mar 24 11:28:19 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 24 Mar 2006 11:28:19 -0700 (MST) Subject: [Rxtx] Re: RXTX 2.1 Solaris Problems In-Reply-To: <3691.1143210578@www045.gmx.net> References: <3691.1143210578@www045.gmx.net> Message-ID: On Fri, 24 Mar 2006, Andreas Guenther wrote: > Hi all, > > the solaris problem was not the lock file only. > > Ok, I had to create the directory /var/spool/locks myself. > /var/spool/uucp exists. > > But rxtx didn't find any port. > > I compiled the source with my own debug-informations > and I tried to isolate the problem. > > The problem is the testRead-call in SerialImp.c > > JNIEXPORT jboolean JNICALL RXTXCommDriver(testRead)( > > ... > if ( READ( fd, &c, 1 ) < 0 ) > { > if ( errno != EAGAIN ) { > report( "testRead() read failed\n" ); > ret = JNI_FALSE; > } > } > Thanks Andreas I'm packing up to move. I'll be more or less away for a couple weeks here. I'll be checking email but my workstation is going into a box soon. This isn't hard to fix as this port should be enumerated when EWOULDBLOCK is recieved. Thats error is OK for enumeration just as EAGAIN is. I've put the bug into bugzilla so we dont forget to get to it. http://bugzilla.qbang.org/show_bug.cgi?id=42 You can add yourself to the CC list if you wish to test fixes we provide or even put a patch into bugzilla yourself. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Fri Mar 24 11:51:52 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 24 Mar 2006 11:51:52 -0700 (MST) Subject: [Rxtx] JavaPOS In-Reply-To: <20060324082238.66371.qmail@web38214.mail.mud.yahoo.com> References: <20060324082238.66371.qmail@web38214.mail.mud.yahoo.com> Message-ID: On Fri, 24 Mar 2006, Maximulo Majir wrote: > Hi all! Hello Trent! > > > From what i understand, RXTX or JavaComm APIs were not > created solely for JavaPOS. In JavaPOS, we have the virtual method > claim() which is separate from open(), but in our RXTX API, claiming is > done every call to open(), we cant open the port if its claimed by > another application. Would it be alright to suggest or ask to create a > new method called claim(..)? Is there such thing as forceclaim() in > RXTX? this could be the same as portownership transfer or its > equivalent. ForceClaim is in JSR80. > Do you have some samples using RXTX as the lower layer for the Device > Service Objects in JavaPOS? I have tried it, i just want to compare. > maxim Hi Maxim JSR80 is the USB API IBM/Sun put together. The problem is they have a richer kernel/API underneath that can handle such things. With Serial Ports, there isnt anything there other than an ioctl that says don't let anyone touch this and lockfiles that are more of a 'lets be nice.' At times we may be using USB ports but it is through the termios layer with the limitations mentioned. The advantage is that not only USB will work with rxtx. Anything that has a termios layer should work (to the extent that termios layer is complete). I don't know how forceclaim() would help you. Lets say someone has a programmer working on /dev/ttyS0 and you take it. Now you both race each other to read data first. There isn't a mechanism I know of that will solve this problem in termios. The most obvious test being a native app and a Java app trying to take the port. There is the potential of requestion ownership from other Java Applications but the use for that is very rare. Did you have something more specific in mind that I'm missing? I'm not sure that claim() and forceclaim() would help you with rxtx other than maybe locking the port with claim() without opening it. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sat Mar 25 23:42:08 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 25 Mar 2006 23:42:08 -0700 (MST) Subject: [Rxtx] Serial snoop Message-ID: I was reading the Linux kernel mail-list tonight and ran past a thread that mentioned sersnoop. This looks like a handy tool for people dealing with new toys. "a simple command-line tool for linux that echoes bytes to and from any two serial ports, ptys, or network sockets, and prints all traffic to stdout, in hex and ascii." http://www.restivo.org/projects/sersnoop/ It works on Linux only at this time (debian package available). -- Trent Jarvi tjarvi at qbang.org From beat.arnet at gmail.com Sun Mar 26 07:32:35 2006 From: beat.arnet at gmail.com (Beat Arnet) Date: Sun, 26 Mar 2006 09:32:35 -0500 Subject: [Rxtx] Error 0x5 at /home/bob/foo/tar/rxtx-2.1-7/build/../src/termios.c(860): Access is, denied. Message-ID: <4426A603.80508@gmail.com> Dear all, When trying to open the serial port, I sometimes (not always) run into the following exception (when opening the serialPort): Error 0x5 at /home/bob/foo/tar/rxtx-2.1-7/build/../src/termios.c(860): Access is denied. java.lang.UnsatisfiedLinkError: native_psmisc_report_owner at gnu.io.CommPortIdentifier.native_psmisc_report_owner(Native Method) at gnu.io.CommPortIdentifier.open(CommPortIdentifier.java:354) at codeskin.tools.CLLoader.open(CLLoader.java:79) at codeskin.tools.C2000Programmer.run(C2000Programmer.java:220) at java.lang.Thread.run(Unknown Source) Is this the type of error where I should just try to open the port again, or can it be avoided? Regards, Beat From tjarvi at qbang.org Sun Mar 26 11:40:12 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 26 Mar 2006 11:40:12 -0700 (MST) Subject: [Rxtx] Error 0x5 at /home/bob/foo/tar/rxtx-2.1-7/build/../src/termios.c(860): Access is, denied. In-Reply-To: <4426A603.80508@gmail.com> References: <4426A603.80508@gmail.com> Message-ID: On Sun, 26 Mar 2006, Beat Arnet wrote: > Dear all, > > When trying to open the serial port, I sometimes (not always) run into > the following exception (when opening the serialPort): > > Error 0x5 at /home/bob/foo/tar/rxtx-2.1-7/build/../src/termios.c(860): > Access is > denied. > > java.lang.UnsatisfiedLinkError: native_psmisc_report_owner > at gnu.io.CommPortIdentifier.native_psmisc_report_owner(Native > Method) > at gnu.io.CommPortIdentifier.open(CommPortIdentifier.java:354) > at codeskin.tools.CLLoader.open(CLLoader.java:79) > at codeskin.tools.C2000Programmer.run(C2000Programmer.java:220) > at java.lang.Thread.run(Unknown Source) > > Is this the type of error where I should just try to open the port again, > or can it be avoided? > Hi Beat We did a second build of rxtx 2.1-7 to resolve that unsatisfied link error. It should work now. rxtx is trying to tell you it thinks someone else has the serial port open. You can try to open the port again but maybe you already have a copy of the program running when it happens? ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7r2.zip fixed build. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sun Mar 26 11:44:23 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 26 Mar 2006 11:44:23 -0700 (MST) Subject: [Rxtx] RXTX spec file (fwd) Message-ID: This is probably interesting for fedora/suse users. ---------- Forwarded message ---------- Date: Sun, 26 Mar 2006 16:25:45 +0200 To: taj at www.linux.org.uk Subject: RXTX spec file I send you this spec file which allows to create a RPM for Fedora 4, 5 (x86, x86_64) with Java Sun. -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: rxtx.spec Url: http://mailman.qbang.org/pipermail/rxtx/attachments/20060326/6c7b6af6/rxtx-0040.pl From tjarvi at qbang.org Sun Mar 26 23:42:59 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 26 Mar 2006 23:42:59 -0700 (MST) Subject: [Rxtx] Upcomming events. Message-ID: This Wednesday we will be announcing a new "Maintainer" for the rxtx project. The position is more like neutral leader. I wont be going away or doing less. This is just the right thing to do as it turns out the two people with CVS write access will be at the same company. We need a third and we need neutrality. The maintainer will have final say in any conflict and will try to be neutral. It will be open for discussion. Then we will do it :) I'll still do most of the footwork I do now. But. I'm falling behind. I should have gone through the mail-list and posted the next round of changes this weekend. I'm packing to move and its going so so - 13 years of toys collected. I suspect there will be a dead period on my part (a couple weeks) comming up. But if you get it on the mail-list, we will get it in if there are no objections. I may well not be reading the mail-list during this period as I look for a house and many other things. I hope everyone will help out. Thanks -- Trent Jarvi tjarvi at qbang.org From mahmoud_hadad at yahoo.com Sun Mar 26 07:31:19 2006 From: mahmoud_hadad at yahoo.com (ronan nick) Date: Sun, 26 Mar 2006 06:31:19 -0800 (PST) Subject: [Rxtx] a question about the COMM API Message-ID: <20060326143119.54919.qmail@web60014.mail.yahoo.com> hi, i was intrested in knowing how i can communicate with my internal modem using java? for example if i want to make a phone dialer application or a caller id application where should i be looking at? and as i understood the COMM API is for devices that is attached to the computer through serial ports. --------------------------------- New Yahoo! Messenger with Voice. Call regular phones from your PC and save big. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060326/ce8329f0/attachment-0042.html From dmarkman at mac.com Mon Mar 20 00:20:43 2006 From: dmarkman at mac.com (Dmitry Markman) Date: Mon, 20 Mar 2006 02:20:43 -0500 Subject: [Rxtx] Mac OS X RXTX java installer In-Reply-To: References: <07D0DE29-BA32-4CFE-B036-66BC6423D385@buechse.de> <441AE3E0.2030503@willicon.de> <12531986.1142622114996.JavaMail.dmarkman@mac.com> <441B2674.9010409@willicon.de> <13577405.1142634732776.JavaMail.dmarkman@mac.com> <441B4182.8010407@willicon.de> <92CD0D6C-5BE8-426E-A46D-99452059FF49@mac.com> <441BBB2D.8030305@willicon.de> <441C4088.5090905@willicon.de> Message-ID: <64BC1E23-FDDE-4CE6-8863-CFC881CBC224@mac.com> Hi all I put RXTX installer that will install everything (and will create / var/lock if necessary and add user to the uucp group) for mac os x from Java into the rxtx's CVS repository it could be easily modified to install files for any platform it uses Greg Guerin's AuthKit for authentication and authorization Greg released that kit under artistic license, so Trent, please take a look we, probably, can negotiate license with Greg if it's necessary Greg's AuthKit could be downloaded from http://www.amug.org/~glguerin/ sw/#authkit Michael Hall (mikehall at spacestar dot net) had a suggestion to make implementation of the jaas LoginModule based on Greg's AuthKit (his modification of the Greg's AuthKit could be found at http:// www.spacestar.net/users/mikehall/authkit.dmg) but Michael's AuthKitLoginModule does only half a job: it does authenticate but it can not run any external unix process in privileged mode (at least I wasn't able to do so) possible explanation could be found in conversation between Greg and Michael at Apple's java-dev list (look for archives) so I didn't use jaas API for rxtxinstaller I created folder MacOSX in the contrib folder comment 1. if you want to run that installer as standalone application all you need that RXTXInstaller.jar 2. if you want to use webstart you have to add Greg's libAuthKit.jnilib to the mac os x's resources in theory RXTXInstaller.jar doesn't need it, but there is a problem with loading libAuthKit.jnilib from webstart authkit uses loadLibrary method to load library and it failed (from webstart) for standalone application I extract libAuthKit.jnilib from the RXTXInstaller.jar and put it into the /Library/Java/Extensions or ~/Library/Java/Extensions folder that file will be deleted after installer quit unfortunately I didn't have time to put documentation there but it is mostly self-explanatory I took installer code from my gl4java installer that I did about 3 years ago (with small modifications) it would be very nice if Apple will release LoginModule that really will do the job (com.apple.security.auth.module package????? ) (UnixLoginModule is pretty useless) From lyon at docjava.com Mon Mar 20 06:34:39 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Mon, 20 Mar 2006 08:34:39 -0500 Subject: [Rxtx] Mac OS X RXTX java installer In-Reply-To: <64BC1E23-FDDE-4CE6-8863-CFC881CBC224@mac.com> References: <07D0DE29-BA32-4CFE-B036-66BC6423D385@buechse.de> <441AE3E0.2030503@willicon.de> <12531986.1142622114996.JavaMail.dmarkman@mac.com> <441B2674.9010409@willicon.de> <13577405.1142634732776.JavaMail.dmarkman@mac.com> <441B4182.8010407@willicon.de> <92CD0D6C-5BE8-426E-A46D-99452059FF49@mac.com> <441BBB2D.8030305@willicon.de> <441C4088.5090905@willicon.de> <64BC1E23-FDDE-4CE6-8863-CFC881CBC224@mac.com> Message-ID: Hi Dimitry, This sounds like great work. Just a couple of questions; After the check out of the CVS files, using: setenv CVSROOT :pserver:anonymous at cvs.milestonesolutions.com:/usr/local/cvsroot 53 8:28 setenv PASSWORD mousy 54 8:29 cvs login 55 8:29 cvs checkout rxtx-devel I cd'd over to: rxtx-devel/MACOSX_IDE And found: CVS/ CW/ ForPackageMaker/ PB/ Where is the installer? Thanks! - Doug From tjarvi at qbang.org Mon Mar 20 06:39:37 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 20 Mar 2006 06:39:37 -0700 (MST) Subject: [Rxtx] Mac OS X RXTX java installer In-Reply-To: References: <07D0DE29-BA32-4CFE-B036-66BC6423D385@buechse.de> <441AE3E0.2030503@willicon.de> <12531986.1142622114996.JavaMail.dmarkman@mac.com> <441B2674.9010409@willicon.de> <13577405.1142634732776.JavaMail.dmarkman@mac.com> <441B4182.8010407@willicon.de> <92CD0D6C-5BE8-426E-A46D-99452059FF49@mac.com> <441BBB2D.8030305@willicon.de> <441C4088.5090905@willicon.de> <64BC1E23-FDDE-4CE6-8863-CFC881CBC224@mac.com> Message-ID: On Mon, 20 Mar 2006, Dr. Douglas Lyon wrote: > Hi Dimitry, > This sounds like great work. Just a couple of questions; > After the check out of the CVS files, using: > setenv CVSROOT > :pserver:anonymous at cvs.milestonesolutions.com:/usr/local/cvsroot > 53 8:28 setenv PASSWORD mousy > 54 8:29 cvs login > 55 8:29 cvs checkout rxtx-devel Hi Doug You want "cvs checkout -r commapi-0-0-1 rxtx-devel" to get RXTX 2.1 The default branch is rxtx 2.0 which isn't very active right now. -- Trent Jarvi tjarvi at qbang.org From lyon at docjava.com Mon Mar 20 07:05:44 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Mon, 20 Mar 2006 09:05:44 -0500 Subject: [Rxtx] Mac OS X RXTX java installer In-Reply-To: References: <07D0DE29-BA32-4CFE-B036-66BC6423D385@buechse.de> <441AE3E0.2030503@willicon.de> <12531986.1142622114996.JavaMail.dmarkman@mac.com> <441B2674.9010409@willicon.de> <13577405.1142634732776.JavaMail.dmarkman@mac.com> <441B4182.8010407@willicon.de> <92CD0D6C-5BE8-426E-A46D-99452059FF49@mac.com> <441BBB2D.8030305@willicon.de> <441C4088.5090905@willicon.de> <64BC1E23-FDDE-4CE6-8863-CFC881CBC224@mac.com> Message-ID: Hi Trent, Thanks for the info on the CVS checkout procedure. I did that and am still not sure where the installer is. Here is what I have: cd MACOSX_IDE/ p4.docjava.com{lyon}121: ls CVS/ ForPackageMaker/ PB/ p4.docjava.com{lyon}122: find . | more . ./ForPackageMaker ./ForPackageMaker/RXTX.pkg.sit.hqx ./ForPackageMaker/Resources ./ForPackageMaker/Resources/ReadMe.rtf ./ForPackageMaker/Resources/Welcome.rtf ./ForPackageMaker/Resources/CVS ./ForPackageMaker/Resources/CVS/Entries ./ForPackageMaker/Resources/CVS/Repository ./ForPackageMaker/Resources/CVS/Tag ./ForPackageMaker/Resources/CVS/Root ./ForPackageMaker/Resources/preinstall ./ForPackageMaker/Resources/License.rtf ./ForPackageMaker/Resources/preupgrade ./ForPackageMaker/RXTX.pmsp ./ForPackageMaker/CVS ./ForPackageMaker/CVS/Entries ./ForPackageMaker/CVS/Repository ./ForPackageMaker/CVS/Entries.Log ./ForPackageMaker/CVS/Tag ./ForPackageMaker/CVS/Root ./ForPackageMaker/RXTX_Tiger.pkg.sitx.hqx ./ForPackageMaker/RXTX_Jag.pkg.sit.hqx ./ForPackageMaker/Install ./ForPackageMaker/Install/CVS ./ForPackageMaker/Install/CVS/Entries ./ForPackageMaker/Install/CVS/Repository ./ForPackageMaker/Install/CVS/Tag ./ForPackageMaker/Install/CVS/Root ./ForPackageMaker/Install/Library ./ForPackageMaker/Install/Library/CVS ./ForPackageMaker/Install/Library/CVS/Entries ./ForPackageMaker/Install/Library/CVS/Repository ./ForPackageMaker/Install/Library/CVS/Tag ./ForPackageMaker/Install/Library/CVS/Root ./ForPackageMaker/Install/Library/Java ./ForPackageMaker/Install/Library/Java/Extensions ./ForPackageMaker/Install/Library/Java/Extensions/RXTXcomm.jar ./ForPackageMaker/Install/Library/Java/Extensions/CVS ./ForPackageMaker/Install/Library/Java/Extensions/CVS/Entries ./ForPackageMaker/Install/Library/Java/Extensions/CVS/Repository ./ForPackageMaker/Install/Library/Java/Extensions/CVS/Tag ./ForPackageMaker/Install/Library/Java/Extensions/CVS/Root ./ForPackageMaker/Install/Library/Java/Extensions/librxtxSerial.jnilib ./ForPackageMaker/Install/Library/Java/CVS ./ForPackageMaker/Install/Library/Java/CVS/Entries ./ForPackageMaker/Install/Library/Java/CVS/Repository ./ForPackageMaker/Install/Library/Java/CVS/Entries.Log ./ForPackageMaker/Install/Library/Java/CVS/Tag ./ForPackageMaker/Install/Library/Java/CVS/Root ./ForPackageMaker/RXTX_Tiger.pmproj.sitx.hqx ./CVS ./CVS/Entries ./CVS/Repository ./CVS/Entries.Log ./CVS/Tag ./CVS/Root ./PB ./PB/LibSerialUniversal.xcodeproj.sitx.hqx ./PB/CVS ./PB/CVS/Entries ./PB/CVS/Repository ./PB/CVS/Entries.Log ./PB/CVS/Tag ./PB/CVS/Root ./PB/LibSerial.pbproj.sit.hqx ./PB/startpoint.c ./PB/config.h What is the procedure to run this installer? Do we need a README in: /rxtx-devel/MACOSX_IDE Here is what we have: CVS/ ForPackageMaker/ PB/ Thanks! - DL >On Mon, 20 Mar 2006, Dr. Douglas Lyon wrote: > >>Hi Dimitry, >>This sounds like great work. Just a couple of questions; >>After the check out of the CVS files, using: >>setenv CVSROOT >>:pserver:anonymous at cvs.milestonesolutions.com:/usr/local/cvsroot >> 53 8:28 setenv PASSWORD mousy >> 54 8:29 cvs login >> 55 8:29 cvs checkout rxtx-devel > >Hi Doug > >You want "cvs checkout -r commapi-0-0-1 rxtx-devel" to get RXTX 2.1 >The default branch is rxtx 2.0 which isn't very active right now. > >-- >Trent Jarvi >tjarvi at qbang.org From tjarvi at qbang.org Mon Mar 20 07:25:30 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 20 Mar 2006 07:25:30 -0700 (MST) Subject: [Rxtx] Mac OS X RXTX java installer In-Reply-To: References: <07D0DE29-BA32-4CFE-B036-66BC6423D385@buechse.de> <441AE3E0.2030503@willicon.de> <12531986.1142622114996.JavaMail.dmarkman@mac.com> <441B2674.9010409@willicon.de> <13577405.1142634732776.JavaMail.dmarkman@mac.com> <441B4182.8010407@willicon.de> <92CD0D6C-5BE8-426E-A46D-99452059FF49@mac.com> <441BBB2D.8030305@willicon.de> <441C4088.5090905@willicon.de> <64BC1E23-FDDE-4CE6-8863-CFC881CBC224@mac.com> Message-ID: On Mon, 20 Mar 2006, Dr. Douglas Lyon wrote: > Hi Trent, > Thanks for the info on the CVS checkout procedure. > I did that and am still not sure where the installer is. Hi Doug It does look like it was not cvs committed. There is no rxtx-devel/contrib/MacOSX directory in there at the moment. It was mentioned that it was put under contrib. -- Trent Jarvi tjarvi at qbang.org From dmarkman at mac.com Mon Mar 20 07:29:56 2006 From: dmarkman at mac.com (Dmitry Markman) Date: Mon, 20 Mar 2006 09:29:56 -0500 Subject: [Rxtx] Mac OS X RXTX java installer In-Reply-To: References: <07D0DE29-BA32-4CFE-B036-66BC6423D385@buechse.de> <441AE3E0.2030503@willicon.de> <12531986.1142622114996.JavaMail.dmarkman@mac.com> <441B2674.9010409@willicon.de> <13577405.1142634732776.JavaMail.dmarkman@mac.com> <441B4182.8010407@willicon.de> <92CD0D6C-5BE8-426E-A46D-99452059FF49@mac.com> <441BBB2D.8030305@willicon.de> <441C4088.5090905@willicon.de> <64BC1E23-FDDE-4CE6-8863-CFC881CBC224@mac.com> Message-ID: <6054EB4E-F7E0-4A9C-BDDA-D582D6D8826F@mac.com> you can find it in the rxtx-devel/contrib folder On Mar 20, 2006, at 9:05 AM, Dr. Douglas Lyon wrote: > Hi Trent, > Thanks for the info on the CVS checkout procedure. > I did that and am still not sure where the installer is. > Here is what I have: > cd MACOSX_IDE/ > p4.docjava.com{lyon}121: ls > CVS/ ForPackageMaker/ PB/ > p4.docjava.com{lyon}122: find . | more > . > ./ForPackageMaker > ./ForPackageMaker/RXTX.pkg.sit.hqx > ./ForPackageMaker/Resources > ./ForPackageMaker/Resources/ReadMe.rtf > ./ForPackageMaker/Resources/Welcome.rtf > ./ForPackageMaker/Resources/CVS > ./ForPackageMaker/Resources/CVS/Entries > ./ForPackageMaker/Resources/CVS/Repository > ./ForPackageMaker/Resources/CVS/Tag > ./ForPackageMaker/Resources/CVS/Root > ./ForPackageMaker/Resources/preinstall > ./ForPackageMaker/Resources/License.rtf > ./ForPackageMaker/Resources/preupgrade > ./ForPackageMaker/RXTX.pmsp > ./ForPackageMaker/CVS > ./ForPackageMaker/CVS/Entries > ./ForPackageMaker/CVS/Repository > ./ForPackageMaker/CVS/Entries.Log > ./ForPackageMaker/CVS/Tag > ./ForPackageMaker/CVS/Root > ./ForPackageMaker/RXTX_Tiger.pkg.sitx.hqx > ./ForPackageMaker/RXTX_Jag.pkg.sit.hqx > ./ForPackageMaker/Install > ./ForPackageMaker/Install/CVS > ./ForPackageMaker/Install/CVS/Entries > ./ForPackageMaker/Install/CVS/Repository > ./ForPackageMaker/Install/CVS/Tag > ./ForPackageMaker/Install/CVS/Root > ./ForPackageMaker/Install/Library > ./ForPackageMaker/Install/Library/CVS > ./ForPackageMaker/Install/Library/CVS/Entries > ./ForPackageMaker/Install/Library/CVS/Repository > ./ForPackageMaker/Install/Library/CVS/Tag > ./ForPackageMaker/Install/Library/CVS/Root > ./ForPackageMaker/Install/Library/Java > ./ForPackageMaker/Install/Library/Java/Extensions > ./ForPackageMaker/Install/Library/Java/Extensions/RXTXcomm.jar > ./ForPackageMaker/Install/Library/Java/Extensions/CVS > ./ForPackageMaker/Install/Library/Java/Extensions/CVS/Entries > ./ForPackageMaker/Install/Library/Java/Extensions/CVS/Repository > ./ForPackageMaker/Install/Library/Java/Extensions/CVS/Tag > ./ForPackageMaker/Install/Library/Java/Extensions/CVS/Root > ./ForPackageMaker/Install/Library/Java/Extensions/librxtxSerial.jnilib > ./ForPackageMaker/Install/Library/Java/CVS > ./ForPackageMaker/Install/Library/Java/CVS/Entries > ./ForPackageMaker/Install/Library/Java/CVS/Repository > ./ForPackageMaker/Install/Library/Java/CVS/Entries.Log > ./ForPackageMaker/Install/Library/Java/CVS/Tag > ./ForPackageMaker/Install/Library/Java/CVS/Root > ./ForPackageMaker/RXTX_Tiger.pmproj.sitx.hqx > ./CVS > ./CVS/Entries > ./CVS/Repository > ./CVS/Entries.Log > ./CVS/Tag > ./CVS/Root > ./PB > ./PB/LibSerialUniversal.xcodeproj.sitx.hqx > ./PB/CVS > ./PB/CVS/Entries > ./PB/CVS/Repository > ./PB/CVS/Entries.Log > ./PB/CVS/Tag > ./PB/CVS/Root > ./PB/LibSerial.pbproj.sit.hqx > ./PB/startpoint.c > ./PB/config.h > > What is the procedure to run this installer? > Do we need a README in: > /rxtx-devel/MACOSX_IDE > Here is what we have: > CVS/ ForPackageMaker/ PB/ > > > Thanks! > - DL > >> On Mon, 20 Mar 2006, Dr. Douglas Lyon wrote: >> >>> Hi Dimitry, >>> This sounds like great work. Just a couple of questions; >>> After the check out of the CVS files, using: >>> setenv CVSROOT :pserver:anonymous at cvs.milestonesolutions.com:/usr/ >>> local/cvsroot >>> 53 8:28 setenv PASSWORD mousy >>> 54 8:29 cvs login >>> 55 8:29 cvs checkout rxtx-devel >> >> Hi Doug >> >> You want "cvs checkout -r commapi-0-0-1 rxtx-devel" to get RXTX 2.1 >> The default branch is rxtx 2.0 which isn't very active right now. >> >> -- >> Trent Jarvi >> tjarvi at qbang.org > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx Dmitry Markman From mikehall at spacestar.net Mon Mar 20 05:25:25 2006 From: mikehall at spacestar.net (Michael Hall) Date: Mon, 20 Mar 2006 06:25:25 -0600 Subject: [Rxtx] Re: Mac OS X RXTX java installer In-Reply-To: <64BC1E23-FDDE-4CE6-8863-CFC881CBC224@mac.com> References: <07D0DE29-BA32-4CFE-B036-66BC6423D385@buechse.de> <441AE3E0.2030503@willicon.de> <12531986.1142622114996.JavaMail.dmarkman@mac.com> <441B2674.9010409@willicon.de> <13577405.1142634732776.JavaMail.dmarkman@mac.com> <441B4182.8010407@willicon.de> <92CD0D6C-5BE8-426E-A46D-99452059FF49@mac.com> <441BBB2D.8030305@willicon.de> <441C4088.5090905@willicon.de> <64BC1E23-FDDE-4CE6-8863-CFC881CBC224@mac.com> Message-ID: <247EB61F-5CD1-4132-89A2-FC105B6CF9A5@spacestar.net> On Mar 20, 2006, at 1:20 AM, Dmitry Markman wrote: > > Michael Hall (mikehall at spacestar dot net) had a suggestion to > make implementation of the jaas LoginModule > based on Greg's AuthKit > (his modification of the Greg's AuthKit could be found at http:// > www.spacestar.net/users/mikehall/authkit.dmg) > but Michael's AuthKitLoginModule does only half a job: > it does authenticate > but it can not run any external unix process in privileged mode (at > least I wasn't able to do so) If you got it working directly with Greg's the point is moot. But to clarify it anyhow. The login module does not allow you to do anything anything privileged on return as was explained by Greg. You need to work with a separate privileged process using the execPrivileged method of his API. I assume you did something similar although I haven't looked at how you are using it yet. I allowed instead for a action to be performed at the same time you login/authenticate,this... System.setProperty("authkit.action","/usr/bin/id"); just before this... lc.login(); To clarify, safely ignored as you are already complete. Mike Hall mikehall at spacestar dot net http://www.spacestar.net/users/mikehall http://sourceforge.net/projects/macnative -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2427 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20060320/f6e18202/smime-0045.bin From dmarkman at mac.com Mon Mar 20 07:36:47 2006 From: dmarkman at mac.com (Dmitry Markman) Date: Mon, 20 Mar 2006 09:36:47 -0500 Subject: [Rxtx] Re: Mac OS X RXTX java installer In-Reply-To: <247EB61F-5CD1-4132-89A2-FC105B6CF9A5@spacestar.net> References: <07D0DE29-BA32-4CFE-B036-66BC6423D385@buechse.de> <441AE3E0.2030503@willicon.de> <12531986.1142622114996.JavaMail.dmarkman@mac.com> <441B2674.9010409@willicon.de> <13577405.1142634732776.JavaMail.dmarkman@mac.com> <441B4182.8010407@willicon.de> <92CD0D6C-5BE8-426E-A46D-99452059FF49@mac.com> <441BBB2D.8030305@willicon.de> <441C4088.5090905@willicon.de> <64BC1E23-FDDE-4CE6-8863-CFC881CBC224@mac.com> <247EB61F-5CD1-4132-89A2-FC105B6CF9A5@spacestar.net> Message-ID: Hi, Michael all I have to do is to run some shell script I tried to use your action mechanism and it worked great so I just System.setProperty ("authkit.action","" ) and after that I even don't need to run anything like subject.doAs.... but after few thoughts I choose to use plain Greg's approach, because in that case I don't have to deal with various java's configurations files and therefore to use 2-3 -D parameters in the java command line especially it's useful for java web start (it's so fragile :-( ) thanks for the great job On Mar 20, 2006, at 7:25 AM, Michael Hall wrote: > > On Mar 20, 2006, at 1:20 AM, Dmitry Markman wrote: >> >> Michael Hall (mikehall at spacestar dot net) had a suggestion to >> make implementation of the jaas LoginModule >> based on Greg's AuthKit >> (his modification of the Greg's AuthKit could be found at http:// >> www.spacestar.net/users/mikehall/authkit.dmg) >> but Michael's AuthKitLoginModule does only half a job: >> it does authenticate >> but it can not run any external unix process in privileged mode >> (at least I wasn't able to do so) > > If you got it working directly with Greg's the point is moot. > > But to clarify it anyhow. > The login module does not allow you to do anything anything > privileged on return as was explained by Greg. You need to work > with a separate privileged process using the execPrivileged method > of his API. I assume you did something similar although I haven't > looked at how you are using it yet. > I allowed instead for a action to be performed at the same time you > login/authenticate,this... > System.setProperty("authkit.action","/usr/bin/id"); > just before this... > lc.login(); > To clarify, safely ignored as you are already complete. > > Mike Hall mikehall at spacestar dot net > http://www.spacestar.net/users/mikehall > http://sourceforge.net/projects/macnative > > > Dmitry Markman From dmarkman at mac.com Mon Mar 20 07:44:45 2006 From: dmarkman at mac.com (Dmitry Markman) Date: Mon, 20 Mar 2006 09:44:45 -0500 Subject: [Rxtx] Mac OS X RXTX java installer In-Reply-To: References: <07D0DE29-BA32-4CFE-B036-66BC6423D385@buechse.de> <441AE3E0.2030503@willicon.de> <12531986.1142622114996.JavaMail.dmarkman@mac.com> <441B2674.9010409@willicon.de> <13577405.1142634732776.JavaMail.dmarkman@mac.com> <441B4182.8010407@willicon.de> <92CD0D6C-5BE8-426E-A46D-99452059FF49@mac.com> <441BBB2D.8030305@willicon.de> <441C4088.5090905@willicon.de> <64BC1E23-FDDE-4CE6-8863-CFC881CBC224@mac.com> Message-ID: it's in the commapi-0-0-1 branch I tested it right now: cvs co -r commapi-0-0-1 rxtx-devel and I got everything On Mar 20, 2006, at 9:25 AM, Trent Jarvi wrote: > On Mon, 20 Mar 2006, Dr. Douglas Lyon wrote: > >> Hi Trent, >> Thanks for the info on the CVS checkout procedure. >> I did that and am still not sure where the installer is. > > Hi Doug > > It does look like it was not cvs committed. There is no rxtx-devel/ > contrib/MacOSX directory in there at the moment. It was mentioned > that it was put under contrib. > > -- > Trent Jarvi > tjarvi at qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx Dmitry Markman From tjarvi at qbang.org Mon Mar 20 07:52:57 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 20 Mar 2006 07:52:57 -0700 (MST) Subject: [Rxtx] Mac OS X RXTX java installer In-Reply-To: References: <07D0DE29-BA32-4CFE-B036-66BC6423D385@buechse.de> <441AE3E0.2030503@willicon.de> <12531986.1142622114996.JavaMail.dmarkman@mac.com> <441B2674.9010409@willicon.de> <13577405.1142634732776.JavaMail.dmarkman@mac.com> <441B4182.8010407@willicon.de> <92CD0D6C-5BE8-426E-A46D-99452059FF49@mac.com> <441BBB2D.8030305@willicon.de> <441C4088.5090905@willicon.de> <64BC1E23-FDDE-4CE6-8863-CFC881CBC224@mac.com> Message-ID: On Mon, 20 Mar 2006, Dmitry Markman wrote: > it's in the commapi-0-0-1 branch > > I tested it right now: > cvs co -r commapi-0-0-1 rxtx-devel > > and I got everything > A fresh checkout worked. Here is a copy of the tree (just the installer bits) ftp://ftp.qbang.org/pub/rxtx/MacOSX-installer.zip -- Trent Jarvi tjarvi at qbang.org From lyon at docjava.com Mon Mar 20 08:08:26 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Mon, 20 Mar 2006 10:08:26 -0500 Subject: [Rxtx] Mac OS X RXTX java installer In-Reply-To: References: <07D0DE29-BA32-4CFE-B036-66BC6423D385@buechse.de> <441AE3E0.2030503@willicon.de> <12531986.1142622114996.JavaMail.dmarkman@mac.com> <441B2674.9010409@willicon.de> <13577405.1142634732776.JavaMail.dmarkman@mac.com> <441B4182.8010407@willicon.de> <92CD0D6C-5BE8-426E-A46D-99452059FF49@mac.com> <441BBB2D.8030305@willicon.de> <441C4088.5090905@willicon.de> <64BC1E23-FDDE-4CE6-8863-CFC881CBC224@mac.com> Message-ID: Hi All, Is the Auth package able to work properly on non Mac OS's? It was not clear from the doc or download. Thanks! - Doug From dmarkman at mac.com Mon Mar 20 08:15:22 2006 From: dmarkman at mac.com (Dmitry Markman) Date: Mon, 20 Mar 2006 10:15:22 -0500 Subject: [Rxtx] Mac OS X RXTX java installer In-Reply-To: References: <07D0DE29-BA32-4CFE-B036-66BC6423D385@buechse.de> <441AE3E0.2030503@willicon.de> <12531986.1142622114996.JavaMail.dmarkman@mac.com> <441B2674.9010409@willicon.de> <13577405.1142634732776.JavaMail.dmarkman@mac.com> <441B4182.8010407@willicon.de> <92CD0D6C-5BE8-426E-A46D-99452059FF49@mac.com> <441BBB2D.8030305@willicon.de> <441C4088.5090905@willicon.de> <64BC1E23-FDDE-4CE6-8863-CFC881CBC224@mac.com> Message-ID: <217312D8-CCCA-4859-ABA6-32DF1CC817B9@mac.com> thanks Trent, for putting it on ftp server On Mar 20, 2006, at 9:52 AM, Trent Jarvi wrote: > A fresh checkout worked. Here is a copy of the tree (just the > installer bits) > > ftp://ftp.qbang.org/pub/rxtx/MacOSX-installer.zip > Dmitry Markman From dmarkman at mac.com Mon Mar 20 09:14:03 2006 From: dmarkman at mac.com (Dmitry Markman) Date: Mon, 20 Mar 2006 11:14:03 -0500 Subject: [Rxtx] Mac OS X RXTX java installer In-Reply-To: References: <07D0DE29-BA32-4CFE-B036-66BC6423D385@buechse.de> <441AE3E0.2030503@willicon.de> <12531986.1142622114996.JavaMail.dmarkman@mac.com> <441B2674.9010409@willicon.de> <13577405.1142634732776.JavaMail.dmarkman@mac.com> <441B4182.8010407@willicon.de> <92CD0D6C-5BE8-426E-A46D-99452059FF49@mac.com> <441BBB2D.8030305@willicon.de> <441C4088.5090905@willicon.de> <64BC1E23-FDDE-4CE6-8863-CFC881CBC224@mac.com> Message-ID: <4DEBA6F0-DA45-4E84-823E-1F1AC48BDCCC@mac.com> no it will work only on mac os x however it's harmless to run it on other platform if you want to use it for other platform you have to do the following (I'll do it for linux) 1. modify RXTXInstaller class method public static RXTXInstaller getInstance() public static RXTXInstaller getInstance() { String osName = System.getProperty("os.name").toLowerCase(); if(osName.startsWith("mac")){ return new gnu.io.installer.macosx.MACOSXRXTXInstaller(); } else if(osName.startsWith("windows")){ return new gnu.io.installer.windows.WindowsRXTXInstaller(); }else if(osName.startsWith("linux")){ return new gnu.io.installer.linux.LinuxRXTXInstaller(); } return null; } 2. create folder gnu/io/installer/linux/ 3. create class Linux386RXTXInstaller package gnu.io.installer.linux; import java.io.File; public class Linux386RXTXInstaller extends gnu.io.installer.RXTXInstaller{ public Linux386RXTXInstaller(){ createJarFolder(); createLibFolder(); addJarResource("RXTXcomm.jar","/gnu/io/installer/resources/ linux/jar/RXTXcomm.dat"); addLibResource("librxtxSerial.so","/gnu/io/installer/ resources/linux/lib/librxtxSerial.so"); } protected void createJarFolder(){ String javaHome = System.getProperty("java.home"); char separator = File.separatorChar; jarFolder = new File(javaHome+separator+"lib"+separator+"ext"); } protected void createLibFolder(){ String javaHome = System.getProperty("java.home"); char separator = File.separatorChar; libFolder = new File(javaHome+separator+"bin"); } public void runPreProcess() {} //put here some action you need public void runPostProcess() {} //put here some action you need } 4. create folder /gnu/io/installer/resources/linux/jar and put there linux's version of RXTXcomm.dat (which is renamed RXTXcomm.jar) 5. create folder /gnu/io/installer/resources/linux/lib and put there linux's version of librxtxSerial. so 6. make sure that RXTXInstaller.jar has the following items: /gnu/io/installer/resources/linux/jar/RXTXcomm.jar /gnu/io/installer/resources/linux/lib/librxtxSerial.so 7. modify file installer.pref: jar file RXTXInstaller.jar must have the following item /gnu/io/installer/installer.pref that's basically it for windows you have to do the similar things: just replace linux to windows and librxtxSerial.so to rxtxSerial.dll and create appropriate gnu.io.installer.windows.WindowsRXTXInstaller class package gnu.io.installer.windows; import java.io.File; public class WindowsRXTXInstaller extends gnu.io.installer.RXTXInstaller{ public WindowsRXTXInstaller(){ createJarFolder(); createLibFolder(); addJarResource("RXTXcomm.jar","/gnu/io/installer/resources/ windows/jar/RXTXcomm.dat"); addLibResource("librxtxSerial.so","/gnu/io/installer/ resources/windows/lib/rxtxSerial.dll"); } protected void createJarFolder(){ String javaHome = System.getProperty("java.home"); char separator = File.separatorChar; jarFolder = new File(javaHome+separator+"lib"+separator+"ext"); } protected void createLibFolder(){ String javaHome = System.getProperty("java.home"); char separator = File.separatorChar; libFolder = new File(javaHome+separator+"bin"); } public void runPreProcess() {} //put here some action you need public void runPostProcess() {} //put here some action you need } installer.pref will look like On Mar 20, 2006, at 10:08 AM, Dr. Douglas Lyon wrote: > Hi All, > Is the Auth package able to work properly on > non Mac OS's? > It was not clear from the doc or download. > > Thanks! > - Doug > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx Dmitry Markman From joachim at buechse.de Mon Mar 20 10:49:06 2006 From: joachim at buechse.de (Joachim Buechse) Date: Mon, 20 Mar 2006 18:49:06 +0100 Subject: [Rxtx] BUG: Lock file stays even if port opening fails Message-ID: This was only tested on MacOSX but looking at the code, it should be true for all systems that use lock_uucp. I am opening a port which can not be opened (dialup port of a telephone paired via bluetooth but currently not reachable). The lock file is created and stays arround, even though the port open failed. After looking a bit through the code (of 2.17), I really wonder if it wouldn't be a good idea to make the "locking" an explicit operation called from the java code. This would certainly simplify the generation of meaningfull exceptions (and java based debugging). Maybe even the handling of "preopened" ports should be in the Java part of the lib (again for java based debugging puposes). That beeing said, I have no idea if this would be possible for the 2.07 implementation. Regards, Joachim From tjarvi at qbang.org Mon Mar 20 11:24:22 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 20 Mar 2006 11:24:22 -0700 (MST) Subject: [Rxtx] BUG: Lock file stays even if port opening fails In-Reply-To: References: Message-ID: On Mon, 20 Mar 2006, Joachim Buechse wrote: > This was only tested on MacOSX but looking at the code, it should be true > for all systems that use lock_uucp. > > I am opening a port which can not be opened (dialup port of a telephone > paired via bluetooth but currently not reachable). The lock file is > created and stays arround, even though the port open failed. > > > After looking a bit through the code (of 2.17), I really wonder if it > wouldn't be a good idea to make the "locking" an explicit operation > called from the java code. This would certainly simplify the generation > of meaningfull exceptions (and java based debugging). > Maybe even the handling of "preopened" ports should be in the Java part > of the lib (again for java based debugging puposes). That beeing said, I > have no idea if this would be possible for the 2.07 implementation. > > Regards, Hi Joachim It should be possible in the 2.0-7 implementation too. The calls to RXTXPort.java would not change. We would just do more there Moving more of that logic into Java would be better as many people don't like to look at C code. There is a liblockdev on most Linux distros that can do most of the C code and would be easier to use. The problem is embeded devices will not have that library. The preopened port code has not been really tested. That was a last minute request in a product cycle. I expect it will be tested this year though. As I recall, some devices really do not like CD raising on open. The preopened ports then allow people to mess around in java without power cycling the devices or losing data. -- Trent Jarvi tjarvi at qbang.org From joachim at buechse.de Mon Mar 20 12:01:08 2006 From: joachim at buechse.de (Joachim Buechse) Date: Mon, 20 Mar 2006 20:01:08 +0100 Subject: [Rxtx] BUG: Lock file stays even if port opening fails In-Reply-To: References: Message-ID: Hi Trent, What is your general feeling about moving code to Java? The last days I have been reading quite a bit of the code and there are several things, that might not work as expected. I'll give you two examples from is_device_locked: if LOCKDIR == /var/spool/locks the directory /var/spool/lock will not be checked. LOCKDIR is not checked for lockfiles with unexpected pefixes While these things have probably never been discovered in production, they are still possibly incorrect implementations. If it was Java code, I would write some unit tests producing the errors that could later be corrected. PS: One could imagine to actually implement the whole lockfile handling in Java using some native routines to get the values required (pid, st_dev, st_rdev, ...). On 20.03.2006, at 19:24, Trent Jarvi wrote: > On Mon, 20 Mar 2006, Joachim Buechse wrote: > >> This was only tested on MacOSX but looking at the code, it should >> be true for all systems that use lock_uucp. >> >> I am opening a port which can not be opened (dialup port of a >> telephone paired via bluetooth but currently not reachable). The >> lock file is created and stays arround, even though the port open >> failed. >> >> >> After looking a bit through the code (of 2.17), I really wonder if >> it wouldn't be a good idea to make the "locking" an explicit >> operation called from the java code. This would certainly simplify >> the generation of meaningfull exceptions (and java based debugging). >> Maybe even the handling of "preopened" ports should be in the Java >> part of the lib (again for java based debugging puposes). That >> beeing said, I have no idea if this would be possible for the 2.07 >> implementation. >> >> Regards, > > Hi Joachim > > It should be possible in the 2.0-7 implementation too. The calls > to RXTXPort.java would not change. We would just do more there > Moving more of that logic into Java would be better as many people > don't like to look at C code. There is a liblockdev on most Linux > distros that can do most of the C code and would be easier to use. > The problem is embeded devices will not have that library. > > The preopened port code has not been really tested. That was a > last minute request in a product cycle. I expect it will be tested > this year though. As I recall, some devices really do not like CD > raising on open. The preopened ports then allow people to mess > around in java without power cycling the devices or losing data. > > -- > Trent Jarvi > tjarvi at qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Mon Mar 20 12:21:02 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 20 Mar 2006 12:21:02 -0700 (MST) Subject: [Rxtx] BUG: Lock file stays even if port opening fails In-Reply-To: References: Message-ID: On Mon, 20 Mar 2006, Joachim Buechse wrote: > Hi Trent, > > What is your general feeling about moving code to Java? The last days I > have been reading quite a bit of the code and there are several things, > that might not work as expected. > > I'll give you two examples from is_device_locked: > > if LOCKDIR == /var/spool/locks the directory /var/spool/lock will not be > checked. > LOCKDIR is not checked for lockfiles with unexpected pefixes > > While these things have probably never been discovered in production, > they are still possibly incorrect implementations. If it was Java code, I > would write some unit tests producing the errors that could later be > corrected. > > PS: One could imagine to actually implement the whole lockfile handling > in Java using some native routines to get the values required (pid, > st_dev, st_rdev, ...). Hi Joachim I like the idea of moving more of the code into java but there are some things to consider. If you break this into multiple JNI calls, the performance will drop considerably during enumeration of ports. We are looking for 256 ports per dev type vs (16? in Sun's 2.0 and fewer types). Its hard to make assumptions. I've seen virtual ports start at /dev/foo100 for instance. It works out to over 7500 ports on Linux if you enable them all. We already trim that back by default. See Linux-all-ports in RXTXCommDriver.java. There are also native libraries that rxtx can link to. If you move too much into Java, linking to 'standard' libraries with distros will break. "configure --enable-liblock=yes" will not be doable. This is probably a favorable way with RedHat, Debian, Suse and others. Thats the right thing to do if there will be rpms, dpkg, .. For those reasons, I think it still make sense to keep it to a minimal ~3 calls to JNI code that we can use for speed and versatility. lock() isLocked(), unlock() perhaps. When I say speed, its more about avoiding crossing the JNI layer multiple times than java vs C performance. With versatility I think liblock is the right way for most but not all (embeded) linux distros. -- Trent Jarvi tjarvi at qbang.org From joachim at buechse.de Mon Mar 20 12:42:04 2006 From: joachim at buechse.de (Joachim Buechse) Date: Mon, 20 Mar 2006 20:42:04 +0100 Subject: [Rxtx] BUG: Lock file stays even if port opening fails In-Reply-To: References: Message-ID: <82C19FE7-DDCB-45B6-B2C9-7606B66F0124@buechse.de> Ok, what about providing a default implementation in Java? The RXTXCommDriver would call a (native) function useNativeLocking and if it returns true, call the native functions for lock() isLocked (), unlock(), else is would use the Java based default implementation. This could possibly be overriden by a property (again for debugging). Joachim On 20.03.2006, at 20:21, Trent Jarvi wrote: > On Mon, 20 Mar 2006, Joachim Buechse wrote: > >> Hi Trent, >> >> What is your general feeling about moving code to Java? The last >> days I have been reading quite a bit of the code and there are >> several things, that might not work as expected. >> >> I'll give you two examples from is_device_locked: >> >> if LOCKDIR == /var/spool/locks the directory /var/spool/lock will >> not be checked. >> LOCKDIR is not checked for lockfiles with unexpected pefixes >> >> While these things have probably never been discovered in >> production, they are still possibly incorrect implementations. If >> it was Java code, I would write some unit tests producing the >> errors that could later be corrected. >> >> PS: One could imagine to actually implement the whole lockfile >> handling in Java using some native routines to get the values >> required (pid, st_dev, st_rdev, ...). > > Hi Joachim > > I like the idea of moving more of the code into java but there are > some things to consider. > > If you break this into multiple JNI calls, the performance will > drop considerably during enumeration of ports. We are looking for > 256 ports per dev type vs (16? in Sun's 2.0 and fewer types). Its > hard to make assumptions. I've seen virtual ports start at /dev/ > foo100 for instance. > > It works out to over 7500 ports on Linux if you enable them all. > We already trim that back by default. See Linux-all-ports in > RXTXCommDriver.java. > > There are also native libraries that rxtx can link to. If you move > too much into Java, linking to 'standard' libraries with distros > will break. "configure --enable-liblock=yes" will not be doable. > This is probably a favorable way with RedHat, Debian, Suse and > others. Thats the right thing to do if there will be rpms, dpkg, .. > > For those reasons, I think it still make sense to keep it to a > minimal ~3 calls to JNI code that we can use for speed and > versatility. lock() isLocked(), unlock() perhaps. When I say > speed, its more about avoiding crossing the JNI layer multiple > times than java vs C performance. With versatility I think liblock > is the right way for most but not all (embeded) linux distros. > > -- > Trent Jarvi > tjarvi at qbang.org > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Mon Mar 20 12:44:47 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 20 Mar 2006 12:44:47 -0700 (MST) Subject: [Rxtx] BUG: Lock file stays even if port opening fails In-Reply-To: <82C19FE7-DDCB-45B6-B2C9-7606B66F0124@buechse.de> References: <82C19FE7-DDCB-45B6-B2C9-7606B66F0124@buechse.de> Message-ID: On Mon, 20 Mar 2006, Joachim Buechse wrote: > Ok, what about providing a default implementation in Java? > > The RXTXCommDriver would call a (native) function useNativeLocking and if > it returns true, call the native functions for lock() isLocked(), > unlock(), else is would use the Java based default implementation. This > could possibly be overriden by a property (again for debugging). > Hi Joachim That would be OK with me. -- Trent Jarvi tjarvi at qbang.org From dmarkman at mac.com Mon Mar 20 22:27:45 2006 From: dmarkman at mac.com (Dmitry Markman) Date: Tue, 21 Mar 2006 00:27:45 -0500 Subject: [Rxtx] binaries request Message-ID: <42702213-C222-4937-A585-7CFB17E47608@mac.com> Hi can somebody send me latest linux and windows binaries, please? or where I can find them (I didn't find them in the latest tareball) I gave up with my cygwin: something wrong I have no idea what java doesn't understand /cygwin/c syntax after I changed makefile it did java part but after that gcc 3.4.4 started to complain I set buffer length to 999 lines but I didn't get beginning of the story something wrong with my 1.4.2_09/include/jni.h gcc doesn't like it anyway I gave up thanks in advance Dmitry Markman -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060320/f8cbc57c/attachment-0045.html From tjarvi at qbang.org Mon Mar 20 22:36:48 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 20 Mar 2006 22:36:48 -0700 (MST) Subject: [Rxtx] binaries request In-Reply-To: <42702213-C222-4937-A585-7CFB17E47608@mac.com> References: <42702213-C222-4937-A585-7CFB17E47608@mac.com> Message-ID: On Tue, 21 Mar 2006, Dmitry Markman wrote: > Hi > can somebody send me latest linux and windows binaries, please? > > or where I can find them (I didn't find them in the latest tareball) > > I gave up with my cygwin: something wrong I have no idea what > java doesn't understand /cygwin/c syntax > after I changed makefile it did java part > but after that gcc 3.4.4 started to complain > I set buffer length to 999 lines but I didn't get beginning of the story > something wrong with my 1.4.2_09/include/jni.h gcc doesn't like it > anyway I gave up > > thanks in advance > Hi Dmitry The bins are here: ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7-bins-r2.zip Here are the files in the zip you want. Jar: rxtx-2.1-7-bins-r2/RXTXcomm.jar Windows: rxtx-2.1-7-bins-r2/Windows/i368-mingw32/rxtxSerial.dll Linux (x86) rxtx-2.1-7-bins-r2/Linux/i686-unknown-linux-gnu/librxtxSerial.so There are others in there including Parallel port support but those are the main ones for testing. -- Trent Jarvi tjarvi at qbang.org From dmarkman at mac.com Mon Mar 20 23:05:59 2006 From: dmarkman at mac.com (Dmitry Markman) Date: Tue, 21 Mar 2006 01:05:59 -0500 Subject: [Rxtx] binaries request In-Reply-To: References: <42702213-C222-4937-A585-7CFB17E47608@mac.com> Message-ID: thank you very much but windows's readme says: rxtxSerial.dll had to be recomopiled to link in missing native methods. should I ignore it? or what? thanks again also I understand that I should use mingw not cygwin I'll try to install mingw On Mar 21, 2006, at 12:36 AM, Trent Jarvi wrote: > On Tue, 21 Mar 2006, Dmitry Markman wrote: > >> Hi >> can somebody send me latest linux and windows binaries, please? >> >> or where I can find them (I didn't find them in the latest tareball) >> >> I gave up with my cygwin: something wrong I have no idea what >> java doesn't understand /cygwin/c syntax >> after I changed makefile it did java part >> but after that gcc 3.4.4 started to complain >> I set buffer length to 999 lines but I didn't get beginning of the >> story >> something wrong with my 1.4.2_09/include/jni.h gcc doesn't like it >> anyway I gave up >> >> thanks in advance >> > > Hi Dmitry > > The bins are here: > > ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7-bins-r2.zip > > Here are the files in the zip you want. > > Jar: > > rxtx-2.1-7-bins-r2/RXTXcomm.jar > > Windows: > > rxtx-2.1-7-bins-r2/Windows/i368-mingw32/rxtxSerial.dll > > Linux (x86) > > rxtx-2.1-7-bins-r2/Linux/i686-unknown-linux-gnu/librxtxSerial.so > > There are others in there including Parallel port support but those > are the main ones for testing. > > -- > Trent Jarvi > tjarvi at qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx Dmitry Markman From tjarvi at qbang.org Mon Mar 20 23:20:33 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 20 Mar 2006 23:20:33 -0700 (MST) Subject: [Rxtx] binaries request In-Reply-To: References: <42702213-C222-4937-A585-7CFB17E47608@mac.com> Message-ID: On Tue, 21 Mar 2006, Dmitry Markman wrote: > thank you very much > > but windows's readme says: > rxtxSerial.dll had to be recomopiled to link in missing native methods. > > should I ignore it? or what? > Hi Dmitry That dll should be OK. r2 is the recompile linked to the missing native method. The readme explains why it was recompiled; fuser.o was not linked into the dll in the first release. -- Trent Jarvi tjarvi at qbang.org From ariantristan at yahoo.com Mon Mar 20 23:55:24 2006 From: ariantristan at yahoo.com (Lambok Sianturi) Date: Mon, 20 Mar 2006 22:55:24 -0800 (PST) Subject: [Rxtx] jvm issue Message-ID: <20060321065524.94779.qmail@web50701.mail.yahoo.com> Hi All, This is my first time to join RxTx mailing list. I thank you all for allowing others to sign in in requests help. I use the latest RxTx lib in Fedora 3 with java version 1.4.2_09 b05. And I got this error: # # An unexpected error has been detected by HotSpot Virtual Machine: # # SIGSEGV (0xb) at pc=0x00bf27f3, pid=2633, tid=3086112448 # # Java VM: Java HotSpot(TM) Client VM (1.4.2_09-b05 mixed mode) # Problematic frame: # C [ld-linux.so.2+0xa7f3] # # An error report file with more information is saved as hs_err_pid2633.log # # If you would like to submit a bug report, please visit: # http://java.sun.com/webapps/bugreport/crash.jsp # ./run.sh: line 3: 2633 Aborted /usr/local/java/bin/java -Djava.library.path=/usr/local/java/jre/lib/ -Djsmsengine.debug=true -classpath jsmsengine.jar:smsgateway.jar:classes12.jar:RXTXcomm.jar:. com.api.sms.SMSServer What is the jvm depedency for the latest library? Can I use 1.4.2_09 b05? Thanks in advance. Arian --------------------------------- Yahoo! Mail Use Photomail to share photos without annoying attachments. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060320/83d58dd7/attachment-0045.html From f.frumento at ngi.it Tue Mar 21 00:21:47 2006 From: f.frumento at ngi.it (Fabio Frumento) Date: Tue, 21 Mar 2006 08:21:47 +0100 Subject: [Rxtx] Javadoc on the go Message-ID: <441FA98B.9050701@ngi.it> Hi Trent, sorry for the big delay but my job is running wild, i was out for some time but now i'm back and ready to continue the javadoc for Rxtx. Did you used the last javadoc patch i sent you ? let me know if i have to send it to you again or not. regards Fabio From lyon at docjava.com Tue Mar 21 00:51:18 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Tue, 21 Mar 2006 02:51:18 -0500 Subject: [Rxtx] lock files Message-ID: Hi All, You know, if the use of lock files were under Java control (rather than a build-time decision), it might enable a more unified binary distro. It might also facilitate quick prototyping of non-lock file approaches to resolving serial port contention issues (i.e., mac-like approaches vs. linux approaches, etc.). I realize that this is a radical overhaul of the lock file policy issue. Also, it may harm performance. On the other hand, our benchmarks on JNI overhead for modern processors indicate performance impact should be minimal. Perhaps it is more of an issue with the toybox systems. Suppose there were a class with a reasonable default...someone might write: SerialPortLockPolicy.setPolicy(SerialPortLockPolicy.UNIX_LOCK_FILE); SerialPortLockPolicy.setPolicy(SerialPortLockPolicy.NO_LOCK_CHECKING); SerialPortLockPolicy.setPolicy(SerialPortLockPolicy.MAC_STYLE); Thus, we could have a run-time reconfiguration of the serial port lock policy. A special NO_LOCK version of the binary would no longer be required. Any thoughts on this? Thanks! - Doug From joachim at buechse.de Tue Mar 21 03:09:09 2006 From: joachim at buechse.de (Joachim Buechse) Date: Tue, 21 Mar 2006 11:09:09 +0100 Subject: [Rxtx] lock files In-Reply-To: References: Message-ID: <8E12916A-1B9A-4FF2-B684-E2D1C794221B@buechse.de> This is pretty much what I thought about when I suggested, that the default behaviour could be overwritten with a property. I am very much in favor of this approach. In particular this allows much easier debugging for PC based java developers. I think big parts of the Java (and maybe some parts of the C code) could use a bit of a structural workover (unit tests, javadoc, synchronization, etc). Maybe there should be a CVS branch for this experimental version. I'd be happy to contribute a first workover for some of the Java code. Designing for testability and implementing a good bunch of unit tests has been a strategy that worked quite well in the Java projects I lead. And it ultimately allows more liberal change permission. Regards, Joachim On 21.03.2006, at 08:51, Dr. Douglas Lyon wrote: > Hi All, > You know, if the use of lock files were > under Java control (rather than a build-time decision), > it might enable a more unified binary distro. It might also > facilitate quick prototyping of non-lock file approaches > to resolving serial port contention issues (i.e., mac-like > approaches vs. linux approaches, etc.). > > I realize that this is a radical overhaul of the lock file policy > issue. Also, it may harm performance. On the other hand, > our benchmarks on JNI overhead for modern processors indicate > performance impact should be minimal. Perhaps it is more of > an issue with the toybox systems. > > Suppose there were a class with a reasonable default...someone > might write: > SerialPortLockPolicy.setPolicy(SerialPortLockPolicy.UNIX_LOCK_FILE); > SerialPortLockPolicy.setPolicy(SerialPortLockPolicy.NO_LOCK_CHECKING); > SerialPortLockPolicy.setPolicy(SerialPortLockPolicy.MAC_STYLE); > > Thus, we could have a run-time reconfiguration of the serial port lock > policy. A special NO_LOCK version of the binary would no longer > be required. > > Any thoughts on this? > > Thanks! > - Doug > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From joachim at buechse.de Tue Mar 21 06:23:08 2006 From: joachim at buechse.de (Joachim Buechse) Date: Tue, 21 Mar 2006 14:23:08 +0100 Subject: [Rxtx] PATCH: use of ioctl(fd, TIOCEXCL) instead of lockfiles Message-ID: <923AE774-EEA2-4911-92D8-32BB27802C8B@buechse.de> Here is the patch for the ioctl(fd, TIOCEXCL). I have verified this only for OSX 10.4.5, hence it is only defined for APPLE. However, it should work at least for Solaris as well. If a process has requested TIOEXCL further open calls by other user processes will fail. The patch also disables uucp style locking for APPLE. Obviously this is discussable. I think it is the way to go, as it eliminates creating the lock directory which doesnt exist on the standard installation and it eliminates messing with the system group definitions (adding users to group uucp). Regarding the possibility of root processes opening a device which is locked - I consider this a feature not a potential problem. It is highly unlikely, that somebody is crazy enough to run a JavaVM as root (unless he has no other means of getting a restricted IP port opened, ie doesnt understand ipfw). Anyway, even if the process runs as root, it fails when calling ioctl(fd, TIOCEXCL). It could however still open the port to listen for RING events. I.e. a fax server which needs to see incoming calls but otherwise doesnt want to block the port. So the only case where the proposed mechanism fails is, if an incorrectly implemented process running as root conflicts with a user process. I think this can be accepted. Regards, Joachim PS: If this patch is generally accepted, the installer and Mac doku should obviously be changed as well. Index: SerialImp.c =================================================================== RCS file: /usr/local/cvsroot/rxtx-devel/src/SerialImp.c,v retrieving revision 1.46.2.187 diff -u -r1.46.2.187 SerialImp.c --- SerialImp.c 29 Jan 2006 22:19:04 -0000 1.46.2.187 +++ SerialImp.c 21 Mar 2006 12:59:16 -0000 @@ -656,6 +656,25 @@ fd=OPEN (filename, O_RDWR | O_NOCTTY | O_NONBLOCK ); } while (fd < 0 && errno==EINTR); +#ifdef OPEN_EXCL + // Note that open() follows POSIX semantics: multiple open() calls to + // the same file will succeed unless the TIOCEXCL ioctl is issued. + // This will prevent additional opens except by root-owned processes. + // See tty(4) ("man 4 tty") and ioctl(2) ("man 2 ioctl") for details. + + if (fd >= 0 && (ioctl(fd, TIOCEXCL) == -1)) + { + sprintf( message, "open: exclusive access denied for % s\n", + filename ); + report( message ); + report_error( message ); + + close(fd); + goto fail; + } +#endif /* OPEN_EXCL */ + + if( configure_port( fd ) ) goto fail; (*env)->ReleaseStringUTFChars( env, jstr, filename ); sprintf( message, "open: fd returned is %i\n", fd ); Index: SerialImp.h =================================================================== RCS file: /usr/local/cvsroot/rxtx-devel/src/SerialImp.h,v retrieving revision 1.11.2.49 diff -u -r1.11.2.49 SerialImp.h --- SerialImp.h 5 Jul 2005 17:47:21 -0000 1.11.2.49 +++ SerialImp.h 21 Mar 2006 12:59:17 -0000 @@ -135,7 +135,8 @@ /*# define LOCKDIR "/var/spool/uucp"*/ # define LOCKDIR "/var/lock" # define LOCKFILEPREFIX "LK." -# define UUCP +/*# define UUCP*/ +# define OPEN_EXCL #endif /* __APPLE__ */ #if defined(__NetBSD__) # define DEVICEDIR "/dev/" From tjarvi at qbang.org Tue Mar 21 10:26:08 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 21 Mar 2006 10:26:08 -0700 (MST) Subject: [Rxtx] Javadoc on the go In-Reply-To: <441FA98B.9050701@ngi.it> References: <441FA98B.9050701@ngi.it> Message-ID: On Tue, 21 Mar 2006, Fabio Frumento wrote: > Hi Trent, > > sorry for the big delay but my job is running wild, i was out for some > time but now i'm back and ready to continue the javadoc for Rxtx. > > Did you used the last javadoc patch i sent you ? let me know if i have to > send it to you again or not. > > regards > > Fabio Hi Fabio The patch is in the rxtx mail-list archives. It will be going in soon. I did not see a time critical portion. I'll probably be going through the list since the last batch of patches this weekend and putting them into CVS. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Tue Mar 21 10:57:18 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 21 Mar 2006 10:57:18 -0700 (MST) Subject: [Rxtx] jvm issue In-Reply-To: <20060321065524.94779.qmail@web50701.mail.yahoo.com> References: <20060321065524.94779.qmail@web50701.mail.yahoo.com> Message-ID: On Mon, 20 Mar 2006, Lambok Sianturi wrote: > Hi All, > This is my first time to join RxTx mailing list. I thank you all for allowing others to sign in in requests help. > I use the latest RxTx lib in Fedora 3 with java version 1.4.2_09 b05. And I got this error: > > # > # An unexpected error has been detected by HotSpot Virtual Machine: > # > # SIGSEGV (0xb) at pc=0x00bf27f3, pid=2633, tid=3086112448 > # > # Java VM: Java HotSpot(TM) Client VM (1.4.2_09-b05 mixed mode) > # Problematic frame: > # C [ld-linux.so.2+0xa7f3] A native library loading error? What happens if you recompile rxtx on your system and install that? This sounds like an ABI problem? rxtx 2.1-7 was compiled with a gcc 2.96 toolchain as I recall. The hope is newer system will be backwards compatible. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Tue Mar 21 11:05:29 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 21 Mar 2006 11:05:29 -0700 (MST) Subject: [Rxtx] PATCH: use of ioctl(fd, TIOCEXCL) instead of lockfiles In-Reply-To: <923AE774-EEA2-4911-92D8-32BB27802C8B@buechse.de> References: <923AE774-EEA2-4911-92D8-32BB27802C8B@buechse.de> Message-ID: On Tue, 21 Mar 2006, Joachim Buechse wrote: > Here is the patch for the ioctl(fd, TIOCEXCL). I have verified this only > for OSX 10.4.5, hence it is only defined for APPLE. However, it should > work at least for Solaris as well. > > If a process has requested TIOEXCL further open calls by other user > processes will fail. > > The patch also disables uucp style locking for APPLE. Obviously this is > discussable. I think it is the way to go, as it eliminates creating the > lock directory which doesnt exist on the standard installation and it > eliminates messing with the system group definitions (adding users to > group uucp). > > Regarding the possibility of root processes opening a device which is > locked - I consider this a feature not a potential problem. It is highly > unlikely, that somebody is crazy enough to run a JavaVM as root (unless > he has no other means of getting a restricted IP port opened, ie doesnt > understand ipfw). Anyway, even if the process runs as root, it fails when > calling ioctl(fd, TIOCEXCL). It could however still open the port to > listen for RING events. I.e. a fax server which needs to see incoming > calls but otherwise doesnt want to block the port. So the only case where > the proposed mechanism fails is, if an incorrectly implemented process > running as root conflicts with a user process. I think this can be > accepted. > > Regards, > Joachim > > PS: If this patch is generally accepted, the installer and Mac doku > should obviously be changed as well. > > > Index: SerialImp.c > =================================================================== > RCS file: /usr/local/cvsroot/rxtx-devel/src/SerialImp.c,v > retrieving revision 1.46.2.187 > diff -u -r1.46.2.187 SerialImp.c > --- SerialImp.c 29 Jan 2006 22:19:04 -0000 1.46.2.187 > +++ SerialImp.c 21 Mar 2006 12:59:16 -0000 > @@ -656,6 +656,25 @@ > fd=OPEN (filename, O_RDWR | O_NOCTTY | O_NONBLOCK ); > } while (fd < 0 && errno==EINTR); > > +#ifdef OPEN_EXCL > + // Note that open() follows POSIX semantics: multiple open() > calls to > + // the same file will succeed unless the TIOCEXCL ioctl is > issued. > + // This will prevent additional opens except by root-owned > processes. > + // See tty(4) ("man 4 tty") and ioctl(2) ("man 2 ioctl") for > details. > + > + if (fd >= 0 && (ioctl(fd, TIOCEXCL) == -1)) > + { > + sprintf( message, "open: exclusive access denied for % > s\n", > + filename ); > + report( message ); > + report_error( message ); > + > + close(fd); > + goto fail; > + } > +#endif /* OPEN_EXCL */ > + > + > if( configure_port( fd ) ) goto fail; > (*env)->ReleaseStringUTFChars( env, jstr, filename ); > sprintf( message, "open: fd returned is %i\n", fd ); > Index: SerialImp.h > =================================================================== > RCS file: /usr/local/cvsroot/rxtx-devel/src/SerialImp.h,v > retrieving revision 1.11.2.49 > diff -u -r1.11.2.49 SerialImp.h > --- SerialImp.h 5 Jul 2005 17:47:21 -0000 1.11.2.49 > +++ SerialImp.h 21 Mar 2006 12:59:17 -0000 > @@ -135,7 +135,8 @@ > /*# define LOCKDIR "/var/spool/uucp"*/ > # define LOCKDIR "/var/lock" > # define LOCKFILEPREFIX "LK." > -# define UUCP > +/*# define UUCP*/ > +# define OPEN_EXCL > #endif /* __APPLE__ */ > #if defined(__NetBSD__) > # define DEVICEDIR "/dev/" > This looks like a good start. What do you think Dmitry? Perhaps all systems with TIOCEXCL defined should use that though. Even if they use lockfiles. It wont hurt anything. That would catch people hacking their own serial apps without checking lockfiles. Its a good idea to avoid C++ style comments in the C portions. Some older systems don't deal with them well. If it's just for Mac OS X, it isn't a big deal. I think it was the Irix compiler that was problematic? -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Tue Mar 21 11:22:05 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 21 Mar 2006 11:22:05 -0700 (MST) Subject: [Rxtx] lock files In-Reply-To: <8E12916A-1B9A-4FF2-B684-E2D1C794221B@buechse.de> References: <8E12916A-1B9A-4FF2-B684-E2D1C794221B@buechse.de> Message-ID: We can try it. Maybe the JNI is much improved. The nice thing about linking into liblock is distros then worry about lockfiles on their systems. This way, we have to deal with any changes that may show up. On Tue, 21 Mar 2006, Joachim Buechse wrote: > This is pretty much what I thought about when I suggested, that the > default behaviour could be overwritten with a property. I am very much in > favor of this approach. In particular this allows much easier debugging > for PC based java developers. > > I think big parts of the Java (and maybe some parts of the C code) could > use a bit of a structural workover (unit tests, javadoc, synchronization, > etc). Maybe there should be a CVS branch for this experimental version. > I'd be happy to contribute a first workover for some of the Java code. > Designing for testability and implementing a good bunch of unit tests has > been a strategy that worked quite well in the Java projects I lead. And > it ultimately allows more liberal change permission. > > Regards, > Joachim > > > On 21.03.2006, at 08:51, Dr. Douglas Lyon wrote: > >> Hi All, >> You know, if the use of lock files were >> under Java control (rather than a build-time decision), >> it might enable a more unified binary distro. It might also >> facilitate quick prototyping of non-lock file approaches >> to resolving serial port contention issues (i.e., mac-like >> approaches vs. linux approaches, etc.). >> >> I realize that this is a radical overhaul of the lock file policy >> issue. Also, it may harm performance. On the other hand, >> our benchmarks on JNI overhead for modern processors indicate >> performance impact should be minimal. Perhaps it is more of >> an issue with the toybox systems. >> >> Suppose there were a class with a reasonable default...someone >> might write: >> SerialPortLockPolicy.setPolicy(SerialPortLockPolicy.UNIX_LOCK_FILE); >> SerialPortLockPolicy.setPolicy(SerialPortLockPolicy.NO_LOCK_CHECKING); >> SerialPortLockPolicy.setPolicy(SerialPortLockPolicy.MAC_STYLE); >> >> Thus, we could have a run-time reconfiguration of the serial port lock >> policy. A special NO_LOCK version of the binary would no longer >> be required. >> >> Any thoughts on this? >> >> Thanks! >> - Doug >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From dmarkman at mac.com Tue Mar 21 16:05:17 2006 From: dmarkman at mac.com (Dmitry Markman) Date: Tue, 21 Mar 2006 18:05:17 -0500 Subject: [Rxtx] PATCH: use of ioctl(fd, TIOCEXCL) instead of lockfiles In-Reply-To: References: <923AE774-EEA2-4911-92D8-32BB27802C8B@buechse.de> Message-ID: <512AC70C-BB86-48F2-A83C-023F35C23BAB@mac.com> I think it's cool, but I'd like to have that property implementation when user can choose between locking mechanism about comments: it's easy to change comments to the C style or we can use extensions of the file to cpp so c++ compiler will be used On Mar 21, 2006, at 1:05 PM, Trent Jarvi wrote: > This looks like a good start. What do you think Dmitry? Perhaps > all systems with TIOCEXCL defined should use that though. Even if > they use lockfiles. It wont hurt anything. That would catch > people hacking their own serial apps without checking lockfiles. > > Its a good idea to avoid C++ style comments in the C portions. > Some older systems don't deal with them well. If it's just for Mac > OS X, it isn't a big deal. I think it was the Irix compiler that > was problematic? Dmitry Markman From dmarkman at mac.com Tue Mar 21 16:13:00 2006 From: dmarkman at mac.com (Dmitry Markman) Date: Tue, 21 Mar 2006 18:13:00 -0500 Subject: [Rxtx] PATCH: use of ioctl(fd, TIOCEXCL) instead of lockfiles In-Reply-To: References: <923AE774-EEA2-4911-92D8-32BB27802C8B@buechse.de> Message-ID: I'd like to add that creating locking folder isn't a big deal we never had a problem related to the lock folders, because we always used installer on mac os x from other hand I'm not very much familiar with iotcl locking approach and I'm not sure it's more efficient Joachim wrote "I think it is the way to go, as it eliminates creating the lock directory which doesnt exist on the standard installation and it eliminates messing with the system group definitions (adding users to group uucp)." but I really didn't have any problem with that 1. doesn't exist on the standard installation there are many-many things that don't exist in the standard installation so I don't think that argument is strong enough 2. messing with the system group definitions I don't think we're messing with the group definition mac os x provides very clear way to set up group's members and together with Greg Guerin AuthKit there is no problem to set those definitions so I don't think that argument is strong either but from other hand using iotcl is more promising and is more elegant On Mar 21, 2006, at 1:05 PM, Trent Jarvi wrote: > > This looks like a good start. What do you think Dmitry? Perhaps > all systems with TIOCEXCL defined should use that though. Even if > they use lockfiles. It wont hurt anything. That would catch > people hacking their own serial apps without checking lockfiles. Dmitry Markman From joachim at buechse.de Wed Mar 22 04:46:45 2006 From: joachim at buechse.de (Joachim Buechse) Date: Wed, 22 Mar 2006 12:46:45 +0100 Subject: [Rxtx] PATCH: use of ioctl(fd, TIOCEXCL) instead of lockfiles In-Reply-To: References: <923AE774-EEA2-4911-92D8-32BB27802C8B@buechse.de> Message-ID: Sorry, I was not very clear with my arguments, so I will try again;-) Please, don't take this as an attack against work that has been done. I think the contributions that have been made in the past were made in a good spirit. But I really believe, that the current solution for OSX has many shortcomings and should be changed as soon as possible. lock files --- The /var/lock folder does not exist on the standard OSX installation, however the standard installation includes several applications that use serial ports (i.e. the FAX capability). This indicates, that the lock folder approach will not work well with system components. Applications for OSX will generally try to live in harmony with system components (except for HP print drivers of course). I think RXTX should follow this approach as well. uucp group --- Accessing serial ports is not an admin privileged operation on OSX. Any user (world) has read/write privileges on /dev/tty*. So the system default is to not enforce any group membership to access these ports. The group uucp however is a system group on all unix systems I know. It exists for certain system processes. A non admin user should in general not be a member of this group. Quite arguably no user should ever be a member of this group. Installer --- My general opinion is, that - no Installer should touch user or group data without warning - no Application Installer should touch groups which are not specific to the very application installed - no Installer should ever add regular users to a system group The current installer injects the installing user in the group uucp without warning about this change and without giving the option to "opt out" of this change. This is a potential security risk (but not currently a real one, as OSX contains no folders belonging to group uucp). The current installer does not work for multi user systems. It puts the installing user in the uucp group. However the installing user is not necessarily the user that will use the application. Putting all users that may use a serial port application in the system group uucp seems like a very invasive approach to me. Besides that, newly created users will not automatically be in the group and hence, serial applications will "break" for new users without obvious reasons. Avoiding the lock files will allow self contained applications (i.e. drag&drop installation). In my eyes this is largely preferable over an installer that requests admin privileges. Adding up all these points indicates very strongly, that the lock-file implementation is not the way to go on OSX. Regards, Joachim On 22.03.2006, at 00:13, Dmitry Markman wrote: > I'd like to add that > > creating locking folder isn't a big deal > we never had a problem related to the lock folders, because we > always used installer on mac os x > from other hand I'm not very much familiar with iotcl locking > approach and I'm not sure it's more efficient > > Joachim wrote "I think it is the way to go, as it eliminates > creating the lock directory which doesnt exist on the standard > installation and it eliminates messing with the system group > definitions (adding users to group uucp)." but I really didn't have > any problem with that > > 1. doesn't exist on the standard installation > there are many-many things that don't exist in the standard > installation so I don't think that argument is strong enough > 2. messing with the system group definitions > I don't think we're messing with the group definition > mac os x provides very clear way to set up group's members and > together with Greg Guerin AuthKit there is no problem to set those > definitions > so I don't think that argument is strong either > but from other hand using iotcl is more promising and is more elegant > > > > On Mar 21, 2006, at 1:05 PM, Trent Jarvi wrote: > >> >> This looks like a good start. What do you think Dmitry? Perhaps >> all systems with TIOCEXCL defined should use that though. Even if >> they use lockfiles. It wont hurt anything. That would catch >> people hacking their own serial apps without checking lockfiles. > > Dmitry Markman > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From dmarkman at mac.com Wed Mar 22 05:27:13 2006 From: dmarkman at mac.com (Dmitry Markman) Date: Wed, 22 Mar 2006 07:27:13 -0500 Subject: [Rxtx] PATCH: use of ioctl(fd, TIOCEXCL) instead of lockfiles In-Reply-To: References: <923AE774-EEA2-4911-92D8-32BB27802C8B@buechse.de> Message-ID: <83440CF3-DCD8-41C1-B941-F227232C27E3@mac.com> thanks for the very good explanation I didn't think that you were attacking any thing, so don't worry I just had feeling, that there were more aesthetic reasons for going to ioctl then real necessity now you explained everything quite well (BTW, asfar as I remember installer asks admin password so it wasn't quiet, but it really doesn't matter now) thanks On Mar 22, 2006, at 6:46 AM, Joachim Buechse wrote: > Sorry, I was not very clear with my arguments, so I will try again;-) > > Please, don't take this as an attack against work that has been > done. I think the contributions that have been made in the past > were made in a good spirit. But I really believe, that the current > solution for OSX has many shortcomings and should be changed as > soon as possible. > > lock files > --- > The /var/lock folder does not exist on the standard OSX > installation, however the standard installation includes several > applications that use serial ports (i.e. the FAX capability). This > indicates, that the lock folder approach will not work well with > system components. Applications for OSX will generally try to live > in harmony with system components (except for HP print drivers of > course). I think RXTX should follow this approach as well. > > uucp group > --- > Accessing serial ports is not an admin privileged operation on OSX. > Any user (world) has read/write privileges on /dev/tty*. So the > system default is to not enforce any group membership to access > these ports. The group uucp however is a system group on all unix > systems I know. It exists for certain system processes. A non admin > user should in general not be a member of this group. Quite > arguably no user should ever be a member of this group. > > Installer > --- > My general opinion is, that > - no Installer should touch user or group data without warning > - no Application Installer should touch groups which are not > specific to the very application installed > - no Installer should ever add regular users to a system group > > The current installer injects the installing user in the group uucp > without warning about this change and without giving the option to > "opt out" of this change. This is a potential security risk (but > not currently a real one, as OSX contains no folders belonging to > group uucp). > > The current installer does not work for multi user systems. It puts > the installing user in the uucp group. However the installing user > is not necessarily the user that will use the application. Putting > all users that may use a serial port application in the system > group uucp seems like a very invasive approach to me. Besides that, > newly created users will not automatically be in the group and > hence, serial applications will "break" for new users without > obvious reasons. > > > Avoiding the lock files will allow self contained applications > (i.e. drag&drop installation). In my eyes this is largely > preferable over an installer that requests admin privileges. Adding > up all these points indicates very strongly, that the lock-file > implementation is not the way to go on OSX. > > Regards, > Joachim > > > On 22.03.2006, at 00:13, Dmitry Markman wrote: > >> I'd like to add that >> >> creating locking folder isn't a big deal >> we never had a problem related to the lock folders, because we >> always used installer on mac os x >> from other hand I'm not very much familiar with iotcl locking >> approach and I'm not sure it's more efficient >> >> Joachim wrote "I think it is the way to go, as it eliminates >> creating the lock directory which doesnt exist on the standard >> installation and it eliminates messing with the system group >> definitions (adding users to group uucp)." but I really didn't >> have any problem with that >> >> 1. doesn't exist on the standard installation >> there are many-many things that don't exist in the standard >> installation so I don't think that argument is strong enough >> 2. messing with the system group definitions >> I don't think we're messing with the group definition >> mac os x provides very clear way to set up group's members and >> together with Greg Guerin AuthKit there is no problem to set those >> definitions >> so I don't think that argument is strong either >> but from other hand using iotcl is more promising and is more elegant >> >> >> >> On Mar 21, 2006, at 1:05 PM, Trent Jarvi wrote: >> >>> >>> This looks like a good start. What do you think Dmitry? Perhaps >>> all systems with TIOCEXCL defined should use that though. Even >>> if they use lockfiles. It wont hurt anything. That would catch >>> people hacking their own serial apps without checking lockfiles. >> >> Dmitry Markman >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx Dmitry Markman From lyon at docjava.com Wed Mar 22 06:12:18 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Wed, 22 Mar 2006 08:12:18 -0500 Subject: [Rxtx] sole of a new design pattern Message-ID: Hi All, I have been thinking about how we design the serial port software. I think we need a new design pattern. For lack of a better term, I shall call it: The Parametric Singleton Design Pattern By Douglas A. Lyon ABSTRACT The goal of the singleton design pattern is to make sure that there is one, and only one, instance of a given class. The goal of the parametric singleton design pattern is to make sure that there is one, and only one, instance of a given class with the given parametric values. We parametric singleton design pattern combines the singleton design pattern with a parameter that enables unique creation of instances of a class. These instances are cached. When a user asks for an instance with these parameters, the cache is checked. If the instance is in the cache, the instance is returned, otherwise it is created, added to the cache and then returned. We apply our parametric singleton design pattern to the retrieval of RMI registries bound to a given port. The goal of our system is to make sure that no two RMI registries are listening to the same socket and to make use of the RMI registries after they have been created. RMI registries are used in distributed computation. Introduction The singleton design pattern is meant to ensure that on a single instance of a class exists. It is also meant to provide a global point of access to it. The intent of the parametric singleton design pattern is to ensure that a class has only one instance for a given set of parameter values. It also provides a global point of access to it. Motivation A system cannot tolerate multiple instances of some classes with identical parameters. For example, you cannot have two instances making use of the same serial port, at the same time. You cannot have two instances that are trying to listen to the same socket connection. You cannot have two instances writing to the same file structure at the same time. As the operating system is often thought of as the arbiter of consumed resources (i.e., tape drives, serial ports, etc.) we frequently leave it to an operating system implementation to resolve these contention issues. Even for similar resources (like serial ports) there are few standards for handling contention. For example, serial ports on Linux are locked using a "/var/lock" file. POSIX, on the other hand, uses ioctl mechanisms to prevent contention. A better solution is to make a class that is responsible for keeping track of the instances created from the class. The class is declared final, so that it cannot be subclassed. The class also has a private constructor, so that other classes cannot instance it. The new design pattern is called the parametric singleton design pattern and it provides a way to access and create instances with given parameters. Applicability Use the Parametric Singleton Design Pattern when: 1. There must be exactly one instance of a class with the given parameters. 2. The instances must be accessible to clients from a well-known access point. Structure Insert UML diagram here. Participants The Parametric Singleton Clients that need instances 1. The Parametric Singleton defines an instance upon request from a client, if, and only if, the instance does not already exist. 2. The Parametric Singleton returns the instance to the client. 3. The Parametric Singleton is responsible for creating unique instances from given parameters. Collaborations Clients obtain a reference to a Parametric Singleton instance only through the parametric singleton design pattern. If the instance is left in an improper state (e.g., the serial port was left open) it is NOT the role of the Parametric Singleton Design Pattern to close the IO port. Nor is it the role of the Parametric Singleton Design Pattern to open the port. That role is delegate to some other part of the system. Further, it is not the role of the Parametric Singleton Design Pattern to check out resources. That is, multiple threads can have multiple references to the same resource at the same time. MUTEX locking is delegated to some other part of the system. Consequences The Parametric Singleton Design Pattern has several benefits: 1. Controlled access to parametrically defined instances. Since the Parametric Singleton class encapsulates its instances, there is control over how and when clients access it. 2. Reduced name space. The Parametric Singleton pattern avoids global variables that store instances created from the same parameter. Implementation Here are implementation issues to consider when using the Parametric Singleton pattern: 1. Unique mapping of parameters. The Parametric Singleton pattern requires that there be a mean to isomorphically map the parameter space into the instance space and back again. 2. Ensure unique instances. The Parametric Singleton pattern makes unique instances from parameters, and it does so only once. 3. Cache instances for fast retrieval. The Parametric Singleton pattern must be able to look up instances, given some set of parameters, and do so from some data structure. That is, there must be enough space to hold references to all the instances the program will need. Also, a mechanism is needed to look up and retrieve the instances quickly enough to satisfy the clients. Sample Code public final class ParametricSingletonRmiRegistry { private static Hashtable registry = new Hashtable(100); // use singleton pattern and??????????????????????????????????????????????? // prevent instantiation of RmiRegistryUtils.?????????????????????????????? private ParametricSingletonRmiRegistry() { } // the only instance of the Registry held by the RmiRegistryUtils?????????? public static void listNames(Integer port) { if (!isInCacheAndRunning(port)) return; Registry r = (Registry) registry.get(port); System.out.println("registry on port: " + port); System.out.println("registry: " + r); System.out.println("names: "); try { print(r.list()); } catch (RemoteException e) { In.message(e); } System.out.println("------------------------"); } /**???????????????????????????????????????????????????????????????????????? * Checks whether a Registry has been started on this host????????????????? * in the specified port.?????????????????????????????????????????????????? * If not, it tries to start one.?????????????????????????????????????????? * when it fails to start a Registry, it exits the program????????????????? * with exit code 1.??????????????????????????????????????????????????????? */ public static void restart(int port) { if (isInCacheAndRunning(port)) return; try { startRegistry(port); } catch (RemoteException e) { In.message(e); } } /**???????????????????????????????????????????????????????????????????????? * @param port????????????????????????????????????????????????????????????? * @return true if registry is in cache and running???????????????????????? */ private static boolean isInCacheAndRunning(Integer port) { if (!isRegistryRunning(port.intValue())) return false; if (!isRegistryInCache(port.intValue())) return false; return true; } /**???????????????????????????????????????????????????????????????????????? * @param port????????????????????????????????????????????????????????????? * @return true if we are able to locate a local registry on port.??????????????????????????????????????????????????????????????????????????? */ private static boolean isRegistryRunning(int port) { try { Registry r = LocateRegistry.getRegistry(port); if (r != null) return true; } catch (RemoteException e) { return false; } return false; } /**???????????????????????????????????????????????????????????????????????? * @param port????????????????????????????????????????????????????????????? * @return return true if registry is in cache????????????????????????????? */ private static boolean isRegistryInCache(int port) { if (registry.get(new Integer(port)) == null) return false; return true; } /**???????????????????????????????????????????????????????????????????????? * Restart the registry, if needed.???????????????????????????????????????? * Return the only instance of the registry for consistent global?????????? * using by making use of the Singleton Design Pattern????????????????????? *????????????????????????????????????????????????????????????????????????? * @return the internally held registry instance.?????????????????????????? */ public static Registry getRegistry(Integer port) { restart(port); return (Registry) registry.get(port); } private static void startRegistry(Integer port) throws RemoteException { Registry r; try { r = LocateRegistry.createRegistry(port.intValue()); registry.put(port, r); //r = new sun.rmi.registry.RegistryImpl???????????????????????????? /// (port.intValue());?????????????????????????????????????? // registry.put(port, r);?????????????????????????????????????????? } catch (Exception e) { //e.printStackTrace();????????????????????????????????????????????? r = LocateRegistry.getRegistry(port.intValue()); registry.put(port, r); } } public static void main(String args[]) throws RemoteException { //restart(port);??????????????????????????????????????????????????????? restart(5001); restart(5002); restart(5002); Registry r = LocateRegistry.getRegistry(5002); System.out.println("registry="+r); } } I would very much like to get your feedback on this new design pattern idea. Thank you for your time. Regards, - Doug From david.garnier at trusted-logic.com Wed Mar 22 07:36:10 2006 From: david.garnier at trusted-logic.com (David Garnier) Date: Wed, 22 Mar 2006 15:36:10 +0100 Subject: [Rxtx] sole of a new design pattern In-Reply-To: References: Message-ID: <442160DA.80107@trusted-logic.com> Hello, > The Parametric Singleton Design Pattern The Singleton is the most abused design pattern ever. Good use-cases for this pattern are extremely rare and mostly confined to problems related to hardware resources, like serial ports. > Applicability > > Use the Parametric Singleton Design Pattern when: > 1. There must be exactly one instance of a class with the given > parameters. OK. As I said above, this case this actually very unusual. The Singleton pattern is mostly used when : > 2. The instances must be accessible to clients from a well-known > access point. Using the singleton pattern in this case is just convenient for the programmer. Problems arises pretty quickly, especially if you attempt to unit-test your classes. 1) If your singleton is stateful, or hold on to stateful objects, it means that two different unit tests are not actually independent. Instead of starting with a brand new environment, the result of a test may be affected by the result of a previous test. This problem also arise when with your class relies on a database. In both cases, the solution is to reset your "unique" resource (Singleton or database) at the beginning of the test, which is a pain. Also, while most projects connect to a single database, projects that allow the use of Singletons usually contain several of thems, and new ones may cropped up unnoticed. You quickly end up with test cases that only pass in a certain order, which is a royal pain. 2) You cannot mockup a singleton. Once everyone calls the SomeSingleton class statically, you can't replace your class by SomeSingletonMockup. Furthermore, even for hardware services, the Singleton pattern does not really prevent concurrent accesses. If you start the same program in two different JVMs, unless they somehow shared the state of their "Singletons" (through lock files for example), the Singleton pattern will not prevent concurrent access. Our application uses RXTX, and we routinely encounter cases where another (native) application has already locked the port. Since we cannot modify the native application to recognize lock files, OS-level control is irreplaceable. > > Consequences > The Parametric Singleton Design Pattern has several benefits: > > 1. Controlled access to parametrically defined instances. Since > the Parametric Singleton class encapsulates its instances, there is > control over how and when clients access it. Not really. Once you've returned the instance to a client, you've lost control over it. The client can to whatever it wants with it. You cannot "recall" the instance or claim it back. > 2. Reduced name space. The Parametric Singleton pattern avoids > global variables that store instances created from the same parameter. Sure, but you don't have to rely on a Singleton for that. Just create a single Factory. > I would very much like to get your feedback on this new design > pattern idea. Well, it's nothing new. Some may say that it is the point of design patterns: formalizes the designs that occur again and again. However, this design is simply a combination of the Singleton and Factory patterns. I did use it in the past, but now I've been exposed to the shortcomings of the Singleton pattern, so I limit myself to Factories. Regards, David From sean_montgomery at baseview.com Wed Mar 22 08:35:28 2006 From: sean_montgomery at baseview.com (Sean Montgomery) Date: Wed, 22 Mar 2006 10:35:28 -0500 Subject: [Rxtx] sole of a new design pattern In-Reply-To: <442160DA.80107@trusted-logic.com> References: <442160DA.80107@trusted-logic.com> Message-ID: <05769CA7-A51B-4CF0-BAA0-E02DD905F5A4@baseview.com> On Mar 22, 2006, at 9:36 AM, David Garnier wrote: > Furthermore, even for hardware services, the Singleton pattern does > not really prevent concurrent > accesses. If you start the same program in two different JVMs, > unless they somehow shared the state > of their "Singletons" (through lock files for example), the > Singleton pattern will not prevent > concurrent access. > Multiple class loaders in a single JVM can be tricky, too. Then there's synchronization, lazy initialization and serialization of singletons to contend with. Bloch's Effective Java covers these, and here's a few articles: http://www.javaworld.com/javaworld/jw-04-2003/jw-0425-designpatterns- p3.html http://java.sun.com/developer/technicalArticles/Programming/singletons/ Just FYI :-) From lyon at docjava.com Wed Mar 22 08:50:48 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Wed, 22 Mar 2006 10:50:48 -0500 Subject: [Rxtx] sole of a new design pattern In-Reply-To: <442160DA.80107@trusted-logic.com> References: <442160DA.80107@trusted-logic.com> Message-ID: Hi All, First, I would like to thank David for his prompt and thoughtful remarks. I had no idea people that feel strongly about a design patterns! Wow! Feedback (particularly critical feedback) is greatly appreciated. Starting at the end, first: >I did use it in >the past, but now I've been exposed to the shortcomings of the >Singleton pattern, so I limit myself to Factories. David, if I understood your comments correctly, you suggested that Factories can be used in leu of the Singleton Design Pattern, or even the Parametric Singleton Design Pattern. As I see in [Gof]: Factory Method: Intent "Define an interface for creating an object, but let subclasses decide which class to instantiate. Factory Method lets a class defer instantiation to subclasses." The Singleton Design Pattern is a concrete class, which is rather different, right? Also, subclasses are not permitted with Singleton, as they are final. Naturally, I could use an abstract factory as a parent for a singleton. I could even design a facade that could be implemented with the singleton....but that is not the intention of the design. Unless you want a mock-up, as discussed, below: More below: >Hello, > >> The Parametric Singleton Design Pattern > >The Singleton is the most abused design pattern ever. Good use-cases >for this pattern are extremely >rare and mostly confined to problems related to hardware resources, >like serial ports. > > >> Applicability >> >> Use the Parametric Singleton Design Pattern when: >> 1. There must be exactly one instance of a class with the given >> parameters. >OK. As I said above, this case this actually very unusual. The >Singleton pattern is mostly used when : >> 2. The instances must be accessible to clients from a well-known >> access point. > >Using the singleton pattern in this case is just convenient for the >programmer. Problems arises >pretty quickly, especially if you attempt to unit-test your classes. > >1) If your singleton is stateful, or hold on to stateful objects, it >means that two different unit >tests are not actually independent. Instead of starting with a brand >new environment, the result of >a test may be affected by the result of a previous test. This >problem also arise when with your >class relies on a database. In both cases, the solution is to reset >your "unique" resource >(Singleton or database) at the beginning of the test, which is a >pain. Also, while most projects >connect to a single database, projects that allow the use of >Singletons usually contain several of >thems, and new ones may cropped up unnoticed. You quickly end up >with test cases that only pass in a >certain order, which is a royal pain. There are basic problems with communicating finite state machines that include reachability and deadlock analysis. These are addressed with petri net analysis and are beyond the scope of the design pattern. As you quite rightly pointed out; the parametric singleton pattern (or the singleton pattern, for that matter) enable multiple threads to gain access to the same instance. The only way that I can see to block others from gaining access to the reference is the synchronize keyword. This is putting a spin-lock (or MUTEX) on the reference. The question of how to unit-test a design pattern like the parametric singleton remains open. Perhaps this is a deficiency. > >2) You cannot mockup a singleton. Once everyone calls the >SomeSingleton class statically, you can't >replace your class by SomeSingletonMockup. Acutally, I am not sure that this is true. If the Singleton implements a Facade interface, it should be possible to make the replacement. Right? > >Furthermore, even for hardware services, the Singleton pattern does >not really prevent concurrent >accesses. If you start the same program in two different JVMs, >unless they somehow shared the state >of their "Singletons" (through lock files for example), the >Singleton pattern will not prevent >concurrent access. Good Point!! You have sharp eyes! The singleton design pattern should/could take responsibility for this. In fact, you may notice that my code does have an implementation (LocateRegistry) that can work across JVM's. The LocateRegistry will even work across the Internet! LocateRegistry takes both a host name and a Port (lock files just don't do this). I did not think to implement this beyond the local machine, but, in its present form, it will work across different processes. > >Our application uses RXTX, and we routinely encounter cases where >another (native) application has >already locked the port. Since we cannot modify the native >application to recognize lock files, >OS-level control is irreplaceable. The singleton design pattern is not meant to replace OS-level control, but to centralize the Java programmers access to it. If lock files, for example, are used for serial ports, the Singleton Design Pattern should be able to work with them. > > >> >> Consequences >> The Parametric Singleton Design Pattern has several benefits: >> > > 1. Controlled access to parametrically defined instances. Since >> the Parametric Singleton class encapsulates its instances, there is >> control over how and when clients access it. > >Not really. Once you've returned the instance to a client, you've >lost control over it. The client >can to whatever it wants with it. You cannot "recall" the instance >or claim it back. Good point, this should read: > 1. Controll when parametrically defined instances are created. Since > > the Parametric Singleton class encapsulates its instances, there is > > control over how and when they are instanced. > >> 2. Reduced name space. The Parametric Singleton pattern avoids >> global variables that store instances created from the same parameter. > >Sure, but you don't have to rely on a Singleton for that. Just >create a single Factory. > > Thank you for your thoughtful and prompt response! Regards, - Doug From dmarkman at mac.com Wed Mar 22 21:21:55 2006 From: dmarkman at mac.com (Dmitry Markman) Date: Wed, 22 Mar 2006 23:21:55 -0500 Subject: [Rxtx] sole of a new design pattern In-Reply-To: <442160DA.80107@trusted-logic.com> References: <442160DA.80107@trusted-logic.com> Message-ID: I don't think I get it On Mar 22, 2006, at 9:36 AM, David Garnier wrote: > Using the singleton pattern in this case is just convenient for the > programmer. Problems arises > pretty quickly, especially if you attempt to unit-test your classes. so you're saying that something isn't so good because you can not test it in the convenient way? if that's true, I'm totally disagree change your test, debug whatever, but if software is efficient at runtime, works fine and only problem is some unit test (which is some kind of framework for testing) then dump that unit test , dump that unit framework and make something appropriate to the software you're testing so if Douglas want to use singletons, what's the problem? and what do you mean by abusing of singleton usage? of course singleton doesn't prevent concurrent access to the resource across the processes unless you're using some OS facility to prevent it, besides singleton as it was introduced is relevant only and only inside of the same process otherwise it's not singleton it's something else (let's say network singleton: so you have remote invocation facility and some factory method that return object created by that facility) I don't have any problem with using any kind of singletons. Parametric Singleton idea (if I understand it right) could be easily implemented in the following way: use a map populate map with instances of some class and key is your parameter (you can use lazy population too) if somebody ask the key check the value if it's null so resource is taken if somebody returns the resource put it back to the map public synchronized static Object getSomeResource(Object parameter); public synchronized static void returnResource(Object parameter); getSomeResource (inside of the same process) could return null in 2 cases 1. if somebody (from other thread for example) already took that resource 2. if OS API said that resource corresponded to that parameter (serial port with parameter = 1 (port #)) is locked and unavailable; I'm not sure that in case of serial ports we even need those Parametric Singletons (unless lock checking is a very expensive operation) just ask the OS about availability of that resource and if it's available give it away and then OS will lock it and therefore in next time somebody ask it just answer that resource is locked and return null for example system has 2 serial ports available so I ask getResource("tty"); or I ask getResource("Bluetooth-Modem"); and if OS is ok you can give tty or Bluetooth-Modem or both no need for any additional pattern I think back to the problem mac os x doesn't recognize locking via files, so it handles locking via some API an instance of the singleton in each process should recognize that resource is locked (by using that API) that's all we don't have to make things more complicate then they are just because there is some nice design pattern or nice unit test framework or whatever keep things simple, make them work fast, don't introduce middle layers unless you have really good reason to do so of course I could be entirely wrong, so sorry about that in advance thanks Dmitry Markman From tjarvi at qbang.org Wed Mar 22 22:31:41 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 22 Mar 2006 22:31:41 -0700 (MST) Subject: [Rxtx] sole of a new design pattern In-Reply-To: References: Message-ID: Hi Doug Interesting reading. So far I'm just reading and thinking. I have one question so far. " Clients obtain a reference to a Parametric Singleton instance only through the parametric singleton design pattern. If the instance is left in an improper state (e.g., the serial port was left open) it is NOT the role of the Parametric Singleton Design Pattern to close the IO port. Nor is it the role of the Parametric Singleton Design Pattern to open the port. That role is delegate to some other part of the system. " So when the clients obtain a reference to the singleton, can they assume the port is there? IE, would it be the singletons role to handle things like USB dongles being removed with event hints comming from the underlying OS. Hardware abstraction layer/HAL on Linux is an example of underlying OS events. I assume that role too is delegated to other parts of the system? -- Trent Jarvi tjarvi at qbang.org From lyon at docjava.com Thu Mar 23 08:10:33 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Thu, 23 Mar 2006 10:10:33 -0500 Subject: [Rxtx] Classes don't need goals, they need roles! In-Reply-To: References: Message-ID: Hi Trent, Yes, I think that the role of the Parametric Singleton Pattern is not to open or close serial ports, nor is it to perform error checking. On the other hand, if you were to combine the role of the Parametric Singleton Pattern with another role (like that of error checking) it might not be amiss. However, I generally caution programmers against adding multiple roles to classes, as this leads to monolithic designs. Thus a different class (NativeLibDetect) could have the role of determining if the native library can be loaded. Another class (SerialPortBean) can have the role of serializing the default state of the serial port, so that it can be recovered, from user preferences, at a later time. The SerialPortDetect could have the role of determining if the serial port is removed (i.e., a USB port was unplugged). My guess is that each class should have a different role in the system, in order to ease maintenance and testing...but I could be wrong about that. Thanks! - Doug >Hi Doug > >Interesting reading. So far I'm just reading and thinking. I have >one question so far. > >" > Clients obtain a reference to a Parametric Singleton instance only >through the parametric singleton design pattern. If the instance is >left in an improper state (e.g., the serial port was left open) it is >NOT the role of the Parametric Singleton Design Pattern to close the >IO port. Nor is it the role of the Parametric Singleton Design Pattern >to >open the port. That role is delegate to some other part of the system. >" > >So when the clients obtain a reference to the singleton, can they >assume the port is there? IE, would it be the singletons role to >handle things like USB dongles being removed with event hints >comming from the underlying OS. Hardware abstraction layer/HAL on >Linux is an example of underlying OS events. > >I assume that role too is delegated to other parts of the system? > >-- >Trent Jarvi >tjarvi at qbang.org >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From maximulo at yahoo.com Fri Mar 24 01:22:38 2006 From: maximulo at yahoo.com (Maximulo Majir) Date: Fri, 24 Mar 2006 00:22:38 -0800 (PST) Subject: [Rxtx] JavaPOS Message-ID: <20060324082238.66371.qmail@web38214.mail.mud.yahoo.com> Hi all! Hello Trent! From what i understand, RXTX or JavaComm APIs were not created solely for JavaPOS. In JavaPOS, we have the virtual method claim() which is separate from open(), but in our RXTX API, claiming is done every call to open(), we cant open the port if its claimed by another application. Would it be alright to suggest or ask to create a new method called claim(..)? Is there such thing as forceclaim() in RXTX? this could be the same as portownership transfer or its equivalent. ForceClaim is in JSR80. Do you have some samples using RXTX as the lower layer for the Device Service Objects in JavaPOS? I have tried it, i just want to compare. Thank you all! maxim __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060324/496adba2/attachment-0045.html From tjarvi at qbang.org Fri Mar 24 11:28:19 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 24 Mar 2006 11:28:19 -0700 (MST) Subject: [Rxtx] Re: RXTX 2.1 Solaris Problems In-Reply-To: <3691.1143210578@www045.gmx.net> References: <3691.1143210578@www045.gmx.net> Message-ID: On Fri, 24 Mar 2006, Andreas Guenther wrote: > Hi all, > > the solaris problem was not the lock file only. > > Ok, I had to create the directory /var/spool/locks myself. > /var/spool/uucp exists. > > But rxtx didn't find any port. > > I compiled the source with my own debug-informations > and I tried to isolate the problem. > > The problem is the testRead-call in SerialImp.c > > JNIEXPORT jboolean JNICALL RXTXCommDriver(testRead)( > > ... > if ( READ( fd, &c, 1 ) < 0 ) > { > if ( errno != EAGAIN ) { > report( "testRead() read failed\n" ); > ret = JNI_FALSE; > } > } > Thanks Andreas I'm packing up to move. I'll be more or less away for a couple weeks here. I'll be checking email but my workstation is going into a box soon. This isn't hard to fix as this port should be enumerated when EWOULDBLOCK is recieved. Thats error is OK for enumeration just as EAGAIN is. I've put the bug into bugzilla so we dont forget to get to it. http://bugzilla.qbang.org/show_bug.cgi?id=42 You can add yourself to the CC list if you wish to test fixes we provide or even put a patch into bugzilla yourself. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Fri Mar 24 11:51:52 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 24 Mar 2006 11:51:52 -0700 (MST) Subject: [Rxtx] JavaPOS In-Reply-To: <20060324082238.66371.qmail@web38214.mail.mud.yahoo.com> References: <20060324082238.66371.qmail@web38214.mail.mud.yahoo.com> Message-ID: On Fri, 24 Mar 2006, Maximulo Majir wrote: > Hi all! Hello Trent! > > > From what i understand, RXTX or JavaComm APIs were not > created solely for JavaPOS. In JavaPOS, we have the virtual method > claim() which is separate from open(), but in our RXTX API, claiming is > done every call to open(), we cant open the port if its claimed by > another application. Would it be alright to suggest or ask to create a > new method called claim(..)? Is there such thing as forceclaim() in > RXTX? this could be the same as portownership transfer or its > equivalent. ForceClaim is in JSR80. > Do you have some samples using RXTX as the lower layer for the Device > Service Objects in JavaPOS? I have tried it, i just want to compare. > maxim Hi Maxim JSR80 is the USB API IBM/Sun put together. The problem is they have a richer kernel/API underneath that can handle such things. With Serial Ports, there isnt anything there other than an ioctl that says don't let anyone touch this and lockfiles that are more of a 'lets be nice.' At times we may be using USB ports but it is through the termios layer with the limitations mentioned. The advantage is that not only USB will work with rxtx. Anything that has a termios layer should work (to the extent that termios layer is complete). I don't know how forceclaim() would help you. Lets say someone has a programmer working on /dev/ttyS0 and you take it. Now you both race each other to read data first. There isn't a mechanism I know of that will solve this problem in termios. The most obvious test being a native app and a Java app trying to take the port. There is the potential of requestion ownership from other Java Applications but the use for that is very rare. Did you have something more specific in mind that I'm missing? I'm not sure that claim() and forceclaim() would help you with rxtx other than maybe locking the port with claim() without opening it. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sat Mar 25 23:42:08 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 25 Mar 2006 23:42:08 -0700 (MST) Subject: [Rxtx] Serial snoop Message-ID: I was reading the Linux kernel mail-list tonight and ran past a thread that mentioned sersnoop. This looks like a handy tool for people dealing with new toys. "a simple command-line tool for linux that echoes bytes to and from any two serial ports, ptys, or network sockets, and prints all traffic to stdout, in hex and ascii." http://www.restivo.org/projects/sersnoop/ It works on Linux only at this time (debian package available). -- Trent Jarvi tjarvi at qbang.org From beat.arnet at gmail.com Sun Mar 26 07:32:35 2006 From: beat.arnet at gmail.com (Beat Arnet) Date: Sun, 26 Mar 2006 09:32:35 -0500 Subject: [Rxtx] Error 0x5 at /home/bob/foo/tar/rxtx-2.1-7/build/../src/termios.c(860): Access is, denied. Message-ID: <4426A603.80508@gmail.com> Dear all, When trying to open the serial port, I sometimes (not always) run into the following exception (when opening the serialPort): Error 0x5 at /home/bob/foo/tar/rxtx-2.1-7/build/../src/termios.c(860): Access is denied. java.lang.UnsatisfiedLinkError: native_psmisc_report_owner at gnu.io.CommPortIdentifier.native_psmisc_report_owner(Native Method) at gnu.io.CommPortIdentifier.open(CommPortIdentifier.java:354) at codeskin.tools.CLLoader.open(CLLoader.java:79) at codeskin.tools.C2000Programmer.run(C2000Programmer.java:220) at java.lang.Thread.run(Unknown Source) Is this the type of error where I should just try to open the port again, or can it be avoided? Regards, Beat From tjarvi at qbang.org Sun Mar 26 11:40:12 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 26 Mar 2006 11:40:12 -0700 (MST) Subject: [Rxtx] Error 0x5 at /home/bob/foo/tar/rxtx-2.1-7/build/../src/termios.c(860): Access is, denied. In-Reply-To: <4426A603.80508@gmail.com> References: <4426A603.80508@gmail.com> Message-ID: On Sun, 26 Mar 2006, Beat Arnet wrote: > Dear all, > > When trying to open the serial port, I sometimes (not always) run into > the following exception (when opening the serialPort): > > Error 0x5 at /home/bob/foo/tar/rxtx-2.1-7/build/../src/termios.c(860): > Access is > denied. > > java.lang.UnsatisfiedLinkError: native_psmisc_report_owner > at gnu.io.CommPortIdentifier.native_psmisc_report_owner(Native > Method) > at gnu.io.CommPortIdentifier.open(CommPortIdentifier.java:354) > at codeskin.tools.CLLoader.open(CLLoader.java:79) > at codeskin.tools.C2000Programmer.run(C2000Programmer.java:220) > at java.lang.Thread.run(Unknown Source) > > Is this the type of error where I should just try to open the port again, > or can it be avoided? > Hi Beat We did a second build of rxtx 2.1-7 to resolve that unsatisfied link error. It should work now. rxtx is trying to tell you it thinks someone else has the serial port open. You can try to open the port again but maybe you already have a copy of the program running when it happens? ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7r2.zip fixed build. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sun Mar 26 11:44:23 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 26 Mar 2006 11:44:23 -0700 (MST) Subject: [Rxtx] RXTX spec file (fwd) Message-ID: This is probably interesting for fedora/suse users. ---------- Forwarded message ---------- Date: Sun, 26 Mar 2006 16:25:45 +0200 To: taj at www.linux.org.uk Subject: RXTX spec file I send you this spec file which allows to create a RPM for Fedora 4, 5 (x86, x86_64) with Java Sun. -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: rxtx.spec Url: http://mailman.qbang.org/pipermail/rxtx/attachments/20060326/6c7b6af6/rxtx-0041.pl From tjarvi at qbang.org Sun Mar 26 23:42:59 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 26 Mar 2006 23:42:59 -0700 (MST) Subject: [Rxtx] Upcomming events. Message-ID: This Wednesday we will be announcing a new "Maintainer" for the rxtx project. The position is more like neutral leader. I wont be going away or doing less. This is just the right thing to do as it turns out the two people with CVS write access will be at the same company. We need a third and we need neutrality. The maintainer will have final say in any conflict and will try to be neutral. It will be open for discussion. Then we will do it :) I'll still do most of the footwork I do now. But. I'm falling behind. I should have gone through the mail-list and posted the next round of changes this weekend. I'm packing to move and its going so so - 13 years of toys collected. I suspect there will be a dead period on my part (a couple weeks) comming up. But if you get it on the mail-list, we will get it in if there are no objections. I may well not be reading the mail-list during this period as I look for a house and many other things. I hope everyone will help out. Thanks -- Trent Jarvi tjarvi at qbang.org From mahmoud_hadad at yahoo.com Sun Mar 26 07:31:19 2006 From: mahmoud_hadad at yahoo.com (ronan nick) Date: Sun, 26 Mar 2006 06:31:19 -0800 (PST) Subject: [Rxtx] a question about the COMM API Message-ID: <20060326143119.54919.qmail@web60014.mail.yahoo.com> hi, i was intrested in knowing how i can communicate with my internal modem using java? for example if i want to make a phone dialer application or a caller id application where should i be looking at? and as i understood the COMM API is for devices that is attached to the computer through serial ports. --------------------------------- New Yahoo! Messenger with Voice. Call regular phones from your PC and save big. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060326/ce8329f0/attachment-0043.html From dmarkman at mac.com Mon Mar 20 00:20:43 2006 From: dmarkman at mac.com (Dmitry Markman) Date: Mon, 20 Mar 2006 02:20:43 -0500 Subject: [Rxtx] Mac OS X RXTX java installer In-Reply-To: References: <07D0DE29-BA32-4CFE-B036-66BC6423D385@buechse.de> <441AE3E0.2030503@willicon.de> <12531986.1142622114996.JavaMail.dmarkman@mac.com> <441B2674.9010409@willicon.de> <13577405.1142634732776.JavaMail.dmarkman@mac.com> <441B4182.8010407@willicon.de> <92CD0D6C-5BE8-426E-A46D-99452059FF49@mac.com> <441BBB2D.8030305@willicon.de> <441C4088.5090905@willicon.de> Message-ID: <64BC1E23-FDDE-4CE6-8863-CFC881CBC224@mac.com> Hi all I put RXTX installer that will install everything (and will create / var/lock if necessary and add user to the uucp group) for mac os x from Java into the rxtx's CVS repository it could be easily modified to install files for any platform it uses Greg Guerin's AuthKit for authentication and authorization Greg released that kit under artistic license, so Trent, please take a look we, probably, can negotiate license with Greg if it's necessary Greg's AuthKit could be downloaded from http://www.amug.org/~glguerin/ sw/#authkit Michael Hall (mikehall at spacestar dot net) had a suggestion to make implementation of the jaas LoginModule based on Greg's AuthKit (his modification of the Greg's AuthKit could be found at http:// www.spacestar.net/users/mikehall/authkit.dmg) but Michael's AuthKitLoginModule does only half a job: it does authenticate but it can not run any external unix process in privileged mode (at least I wasn't able to do so) possible explanation could be found in conversation between Greg and Michael at Apple's java-dev list (look for archives) so I didn't use jaas API for rxtxinstaller I created folder MacOSX in the contrib folder comment 1. if you want to run that installer as standalone application all you need that RXTXInstaller.jar 2. if you want to use webstart you have to add Greg's libAuthKit.jnilib to the mac os x's resources in theory RXTXInstaller.jar doesn't need it, but there is a problem with loading libAuthKit.jnilib from webstart authkit uses loadLibrary method to load library and it failed (from webstart) for standalone application I extract libAuthKit.jnilib from the RXTXInstaller.jar and put it into the /Library/Java/Extensions or ~/Library/Java/Extensions folder that file will be deleted after installer quit unfortunately I didn't have time to put documentation there but it is mostly self-explanatory I took installer code from my gl4java installer that I did about 3 years ago (with small modifications) it would be very nice if Apple will release LoginModule that really will do the job (com.apple.security.auth.module package????? ) (UnixLoginModule is pretty useless) From lyon at docjava.com Mon Mar 20 06:34:39 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Mon, 20 Mar 2006 08:34:39 -0500 Subject: [Rxtx] Mac OS X RXTX java installer In-Reply-To: <64BC1E23-FDDE-4CE6-8863-CFC881CBC224@mac.com> References: <07D0DE29-BA32-4CFE-B036-66BC6423D385@buechse.de> <441AE3E0.2030503@willicon.de> <12531986.1142622114996.JavaMail.dmarkman@mac.com> <441B2674.9010409@willicon.de> <13577405.1142634732776.JavaMail.dmarkman@mac.com> <441B4182.8010407@willicon.de> <92CD0D6C-5BE8-426E-A46D-99452059FF49@mac.com> <441BBB2D.8030305@willicon.de> <441C4088.5090905@willicon.de> <64BC1E23-FDDE-4CE6-8863-CFC881CBC224@mac.com> Message-ID: Hi Dimitry, This sounds like great work. Just a couple of questions; After the check out of the CVS files, using: setenv CVSROOT :pserver:anonymous at cvs.milestonesolutions.com:/usr/local/cvsroot 53 8:28 setenv PASSWORD mousy 54 8:29 cvs login 55 8:29 cvs checkout rxtx-devel I cd'd over to: rxtx-devel/MACOSX_IDE And found: CVS/ CW/ ForPackageMaker/ PB/ Where is the installer? Thanks! - Doug From tjarvi at qbang.org Mon Mar 20 06:39:37 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 20 Mar 2006 06:39:37 -0700 (MST) Subject: [Rxtx] Mac OS X RXTX java installer In-Reply-To: References: <07D0DE29-BA32-4CFE-B036-66BC6423D385@buechse.de> <441AE3E0.2030503@willicon.de> <12531986.1142622114996.JavaMail.dmarkman@mac.com> <441B2674.9010409@willicon.de> <13577405.1142634732776.JavaMail.dmarkman@mac.com> <441B4182.8010407@willicon.de> <92CD0D6C-5BE8-426E-A46D-99452059FF49@mac.com> <441BBB2D.8030305@willicon.de> <441C4088.5090905@willicon.de> <64BC1E23-FDDE-4CE6-8863-CFC881CBC224@mac.com> Message-ID: On Mon, 20 Mar 2006, Dr. Douglas Lyon wrote: > Hi Dimitry, > This sounds like great work. Just a couple of questions; > After the check out of the CVS files, using: > setenv CVSROOT > :pserver:anonymous at cvs.milestonesolutions.com:/usr/local/cvsroot > 53 8:28 setenv PASSWORD mousy > 54 8:29 cvs login > 55 8:29 cvs checkout rxtx-devel Hi Doug You want "cvs checkout -r commapi-0-0-1 rxtx-devel" to get RXTX 2.1 The default branch is rxtx 2.0 which isn't very active right now. -- Trent Jarvi tjarvi at qbang.org From lyon at docjava.com Mon Mar 20 07:05:44 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Mon, 20 Mar 2006 09:05:44 -0500 Subject: [Rxtx] Mac OS X RXTX java installer In-Reply-To: References: <07D0DE29-BA32-4CFE-B036-66BC6423D385@buechse.de> <441AE3E0.2030503@willicon.de> <12531986.1142622114996.JavaMail.dmarkman@mac.com> <441B2674.9010409@willicon.de> <13577405.1142634732776.JavaMail.dmarkman@mac.com> <441B4182.8010407@willicon.de> <92CD0D6C-5BE8-426E-A46D-99452059FF49@mac.com> <441BBB2D.8030305@willicon.de> <441C4088.5090905@willicon.de> <64BC1E23-FDDE-4CE6-8863-CFC881CBC224@mac.com> Message-ID: Hi Trent, Thanks for the info on the CVS checkout procedure. I did that and am still not sure where the installer is. Here is what I have: cd MACOSX_IDE/ p4.docjava.com{lyon}121: ls CVS/ ForPackageMaker/ PB/ p4.docjava.com{lyon}122: find . | more . ./ForPackageMaker ./ForPackageMaker/RXTX.pkg.sit.hqx ./ForPackageMaker/Resources ./ForPackageMaker/Resources/ReadMe.rtf ./ForPackageMaker/Resources/Welcome.rtf ./ForPackageMaker/Resources/CVS ./ForPackageMaker/Resources/CVS/Entries ./ForPackageMaker/Resources/CVS/Repository ./ForPackageMaker/Resources/CVS/Tag ./ForPackageMaker/Resources/CVS/Root ./ForPackageMaker/Resources/preinstall ./ForPackageMaker/Resources/License.rtf ./ForPackageMaker/Resources/preupgrade ./ForPackageMaker/RXTX.pmsp ./ForPackageMaker/CVS ./ForPackageMaker/CVS/Entries ./ForPackageMaker/CVS/Repository ./ForPackageMaker/CVS/Entries.Log ./ForPackageMaker/CVS/Tag ./ForPackageMaker/CVS/Root ./ForPackageMaker/RXTX_Tiger.pkg.sitx.hqx ./ForPackageMaker/RXTX_Jag.pkg.sit.hqx ./ForPackageMaker/Install ./ForPackageMaker/Install/CVS ./ForPackageMaker/Install/CVS/Entries ./ForPackageMaker/Install/CVS/Repository ./ForPackageMaker/Install/CVS/Tag ./ForPackageMaker/Install/CVS/Root ./ForPackageMaker/Install/Library ./ForPackageMaker/Install/Library/CVS ./ForPackageMaker/Install/Library/CVS/Entries ./ForPackageMaker/Install/Library/CVS/Repository ./ForPackageMaker/Install/Library/CVS/Tag ./ForPackageMaker/Install/Library/CVS/Root ./ForPackageMaker/Install/Library/Java ./ForPackageMaker/Install/Library/Java/Extensions ./ForPackageMaker/Install/Library/Java/Extensions/RXTXcomm.jar ./ForPackageMaker/Install/Library/Java/Extensions/CVS ./ForPackageMaker/Install/Library/Java/Extensions/CVS/Entries ./ForPackageMaker/Install/Library/Java/Extensions/CVS/Repository ./ForPackageMaker/Install/Library/Java/Extensions/CVS/Tag ./ForPackageMaker/Install/Library/Java/Extensions/CVS/Root ./ForPackageMaker/Install/Library/Java/Extensions/librxtxSerial.jnilib ./ForPackageMaker/Install/Library/Java/CVS ./ForPackageMaker/Install/Library/Java/CVS/Entries ./ForPackageMaker/Install/Library/Java/CVS/Repository ./ForPackageMaker/Install/Library/Java/CVS/Entries.Log ./ForPackageMaker/Install/Library/Java/CVS/Tag ./ForPackageMaker/Install/Library/Java/CVS/Root ./ForPackageMaker/RXTX_Tiger.pmproj.sitx.hqx ./CVS ./CVS/Entries ./CVS/Repository ./CVS/Entries.Log ./CVS/Tag ./CVS/Root ./PB ./PB/LibSerialUniversal.xcodeproj.sitx.hqx ./PB/CVS ./PB/CVS/Entries ./PB/CVS/Repository ./PB/CVS/Entries.Log ./PB/CVS/Tag ./PB/CVS/Root ./PB/LibSerial.pbproj.sit.hqx ./PB/startpoint.c ./PB/config.h What is the procedure to run this installer? Do we need a README in: /rxtx-devel/MACOSX_IDE Here is what we have: CVS/ ForPackageMaker/ PB/ Thanks! - DL >On Mon, 20 Mar 2006, Dr. Douglas Lyon wrote: > >>Hi Dimitry, >>This sounds like great work. Just a couple of questions; >>After the check out of the CVS files, using: >>setenv CVSROOT >>:pserver:anonymous at cvs.milestonesolutions.com:/usr/local/cvsroot >> 53 8:28 setenv PASSWORD mousy >> 54 8:29 cvs login >> 55 8:29 cvs checkout rxtx-devel > >Hi Doug > >You want "cvs checkout -r commapi-0-0-1 rxtx-devel" to get RXTX 2.1 >The default branch is rxtx 2.0 which isn't very active right now. > >-- >Trent Jarvi >tjarvi at qbang.org From tjarvi at qbang.org Mon Mar 20 07:25:30 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 20 Mar 2006 07:25:30 -0700 (MST) Subject: [Rxtx] Mac OS X RXTX java installer In-Reply-To: References: <07D0DE29-BA32-4CFE-B036-66BC6423D385@buechse.de> <441AE3E0.2030503@willicon.de> <12531986.1142622114996.JavaMail.dmarkman@mac.com> <441B2674.9010409@willicon.de> <13577405.1142634732776.JavaMail.dmarkman@mac.com> <441B4182.8010407@willicon.de> <92CD0D6C-5BE8-426E-A46D-99452059FF49@mac.com> <441BBB2D.8030305@willicon.de> <441C4088.5090905@willicon.de> <64BC1E23-FDDE-4CE6-8863-CFC881CBC224@mac.com> Message-ID: On Mon, 20 Mar 2006, Dr. Douglas Lyon wrote: > Hi Trent, > Thanks for the info on the CVS checkout procedure. > I did that and am still not sure where the installer is. Hi Doug It does look like it was not cvs committed. There is no rxtx-devel/contrib/MacOSX directory in there at the moment. It was mentioned that it was put under contrib. -- Trent Jarvi tjarvi at qbang.org From dmarkman at mac.com Mon Mar 20 07:29:56 2006 From: dmarkman at mac.com (Dmitry Markman) Date: Mon, 20 Mar 2006 09:29:56 -0500 Subject: [Rxtx] Mac OS X RXTX java installer In-Reply-To: References: <07D0DE29-BA32-4CFE-B036-66BC6423D385@buechse.de> <441AE3E0.2030503@willicon.de> <12531986.1142622114996.JavaMail.dmarkman@mac.com> <441B2674.9010409@willicon.de> <13577405.1142634732776.JavaMail.dmarkman@mac.com> <441B4182.8010407@willicon.de> <92CD0D6C-5BE8-426E-A46D-99452059FF49@mac.com> <441BBB2D.8030305@willicon.de> <441C4088.5090905@willicon.de> <64BC1E23-FDDE-4CE6-8863-CFC881CBC224@mac.com> Message-ID: <6054EB4E-F7E0-4A9C-BDDA-D582D6D8826F@mac.com> you can find it in the rxtx-devel/contrib folder On Mar 20, 2006, at 9:05 AM, Dr. Douglas Lyon wrote: > Hi Trent, > Thanks for the info on the CVS checkout procedure. > I did that and am still not sure where the installer is. > Here is what I have: > cd MACOSX_IDE/ > p4.docjava.com{lyon}121: ls > CVS/ ForPackageMaker/ PB/ > p4.docjava.com{lyon}122: find . | more > . > ./ForPackageMaker > ./ForPackageMaker/RXTX.pkg.sit.hqx > ./ForPackageMaker/Resources > ./ForPackageMaker/Resources/ReadMe.rtf > ./ForPackageMaker/Resources/Welcome.rtf > ./ForPackageMaker/Resources/CVS > ./ForPackageMaker/Resources/CVS/Entries > ./ForPackageMaker/Resources/CVS/Repository > ./ForPackageMaker/Resources/CVS/Tag > ./ForPackageMaker/Resources/CVS/Root > ./ForPackageMaker/Resources/preinstall > ./ForPackageMaker/Resources/License.rtf > ./ForPackageMaker/Resources/preupgrade > ./ForPackageMaker/RXTX.pmsp > ./ForPackageMaker/CVS > ./ForPackageMaker/CVS/Entries > ./ForPackageMaker/CVS/Repository > ./ForPackageMaker/CVS/Entries.Log > ./ForPackageMaker/CVS/Tag > ./ForPackageMaker/CVS/Root > ./ForPackageMaker/RXTX_Tiger.pkg.sitx.hqx > ./ForPackageMaker/RXTX_Jag.pkg.sit.hqx > ./ForPackageMaker/Install > ./ForPackageMaker/Install/CVS > ./ForPackageMaker/Install/CVS/Entries > ./ForPackageMaker/Install/CVS/Repository > ./ForPackageMaker/Install/CVS/Tag > ./ForPackageMaker/Install/CVS/Root > ./ForPackageMaker/Install/Library > ./ForPackageMaker/Install/Library/CVS > ./ForPackageMaker/Install/Library/CVS/Entries > ./ForPackageMaker/Install/Library/CVS/Repository > ./ForPackageMaker/Install/Library/CVS/Tag > ./ForPackageMaker/Install/Library/CVS/Root > ./ForPackageMaker/Install/Library/Java > ./ForPackageMaker/Install/Library/Java/Extensions > ./ForPackageMaker/Install/Library/Java/Extensions/RXTXcomm.jar > ./ForPackageMaker/Install/Library/Java/Extensions/CVS > ./ForPackageMaker/Install/Library/Java/Extensions/CVS/Entries > ./ForPackageMaker/Install/Library/Java/Extensions/CVS/Repository > ./ForPackageMaker/Install/Library/Java/Extensions/CVS/Tag > ./ForPackageMaker/Install/Library/Java/Extensions/CVS/Root > ./ForPackageMaker/Install/Library/Java/Extensions/librxtxSerial.jnilib > ./ForPackageMaker/Install/Library/Java/CVS > ./ForPackageMaker/Install/Library/Java/CVS/Entries > ./ForPackageMaker/Install/Library/Java/CVS/Repository > ./ForPackageMaker/Install/Library/Java/CVS/Entries.Log > ./ForPackageMaker/Install/Library/Java/CVS/Tag > ./ForPackageMaker/Install/Library/Java/CVS/Root > ./ForPackageMaker/RXTX_Tiger.pmproj.sitx.hqx > ./CVS > ./CVS/Entries > ./CVS/Repository > ./CVS/Entries.Log > ./CVS/Tag > ./CVS/Root > ./PB > ./PB/LibSerialUniversal.xcodeproj.sitx.hqx > ./PB/CVS > ./PB/CVS/Entries > ./PB/CVS/Repository > ./PB/CVS/Entries.Log > ./PB/CVS/Tag > ./PB/CVS/Root > ./PB/LibSerial.pbproj.sit.hqx > ./PB/startpoint.c > ./PB/config.h > > What is the procedure to run this installer? > Do we need a README in: > /rxtx-devel/MACOSX_IDE > Here is what we have: > CVS/ ForPackageMaker/ PB/ > > > Thanks! > - DL > >> On Mon, 20 Mar 2006, Dr. Douglas Lyon wrote: >> >>> Hi Dimitry, >>> This sounds like great work. Just a couple of questions; >>> After the check out of the CVS files, using: >>> setenv CVSROOT :pserver:anonymous at cvs.milestonesolutions.com:/usr/ >>> local/cvsroot >>> 53 8:28 setenv PASSWORD mousy >>> 54 8:29 cvs login >>> 55 8:29 cvs checkout rxtx-devel >> >> Hi Doug >> >> You want "cvs checkout -r commapi-0-0-1 rxtx-devel" to get RXTX 2.1 >> The default branch is rxtx 2.0 which isn't very active right now. >> >> -- >> Trent Jarvi >> tjarvi at qbang.org > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx Dmitry Markman From mikehall at spacestar.net Mon Mar 20 05:25:25 2006 From: mikehall at spacestar.net (Michael Hall) Date: Mon, 20 Mar 2006 06:25:25 -0600 Subject: [Rxtx] Re: Mac OS X RXTX java installer In-Reply-To: <64BC1E23-FDDE-4CE6-8863-CFC881CBC224@mac.com> References: <07D0DE29-BA32-4CFE-B036-66BC6423D385@buechse.de> <441AE3E0.2030503@willicon.de> <12531986.1142622114996.JavaMail.dmarkman@mac.com> <441B2674.9010409@willicon.de> <13577405.1142634732776.JavaMail.dmarkman@mac.com> <441B4182.8010407@willicon.de> <92CD0D6C-5BE8-426E-A46D-99452059FF49@mac.com> <441BBB2D.8030305@willicon.de> <441C4088.5090905@willicon.de> <64BC1E23-FDDE-4CE6-8863-CFC881CBC224@mac.com> Message-ID: <247EB61F-5CD1-4132-89A2-FC105B6CF9A5@spacestar.net> On Mar 20, 2006, at 1:20 AM, Dmitry Markman wrote: > > Michael Hall (mikehall at spacestar dot net) had a suggestion to > make implementation of the jaas LoginModule > based on Greg's AuthKit > (his modification of the Greg's AuthKit could be found at http:// > www.spacestar.net/users/mikehall/authkit.dmg) > but Michael's AuthKitLoginModule does only half a job: > it does authenticate > but it can not run any external unix process in privileged mode (at > least I wasn't able to do so) If you got it working directly with Greg's the point is moot. But to clarify it anyhow. The login module does not allow you to do anything anything privileged on return as was explained by Greg. You need to work with a separate privileged process using the execPrivileged method of his API. I assume you did something similar although I haven't looked at how you are using it yet. I allowed instead for a action to be performed at the same time you login/authenticate,this... System.setProperty("authkit.action","/usr/bin/id"); just before this... lc.login(); To clarify, safely ignored as you are already complete. Mike Hall mikehall at spacestar dot net http://www.spacestar.net/users/mikehall http://sourceforge.net/projects/macnative -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2427 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20060320/f6e18202/smime-0046.bin From dmarkman at mac.com Mon Mar 20 07:36:47 2006 From: dmarkman at mac.com (Dmitry Markman) Date: Mon, 20 Mar 2006 09:36:47 -0500 Subject: [Rxtx] Re: Mac OS X RXTX java installer In-Reply-To: <247EB61F-5CD1-4132-89A2-FC105B6CF9A5@spacestar.net> References: <07D0DE29-BA32-4CFE-B036-66BC6423D385@buechse.de> <441AE3E0.2030503@willicon.de> <12531986.1142622114996.JavaMail.dmarkman@mac.com> <441B2674.9010409@willicon.de> <13577405.1142634732776.JavaMail.dmarkman@mac.com> <441B4182.8010407@willicon.de> <92CD0D6C-5BE8-426E-A46D-99452059FF49@mac.com> <441BBB2D.8030305@willicon.de> <441C4088.5090905@willicon.de> <64BC1E23-FDDE-4CE6-8863-CFC881CBC224@mac.com> <247EB61F-5CD1-4132-89A2-FC105B6CF9A5@spacestar.net> Message-ID: Hi, Michael all I have to do is to run some shell script I tried to use your action mechanism and it worked great so I just System.setProperty ("authkit.action","" ) and after that I even don't need to run anything like subject.doAs.... but after few thoughts I choose to use plain Greg's approach, because in that case I don't have to deal with various java's configurations files and therefore to use 2-3 -D parameters in the java command line especially it's useful for java web start (it's so fragile :-( ) thanks for the great job On Mar 20, 2006, at 7:25 AM, Michael Hall wrote: > > On Mar 20, 2006, at 1:20 AM, Dmitry Markman wrote: >> >> Michael Hall (mikehall at spacestar dot net) had a suggestion to >> make implementation of the jaas LoginModule >> based on Greg's AuthKit >> (his modification of the Greg's AuthKit could be found at http:// >> www.spacestar.net/users/mikehall/authkit.dmg) >> but Michael's AuthKitLoginModule does only half a job: >> it does authenticate >> but it can not run any external unix process in privileged mode >> (at least I wasn't able to do so) > > If you got it working directly with Greg's the point is moot. > > But to clarify it anyhow. > The login module does not allow you to do anything anything > privileged on return as was explained by Greg. You need to work > with a separate privileged process using the execPrivileged method > of his API. I assume you did something similar although I haven't > looked at how you are using it yet. > I allowed instead for a action to be performed at the same time you > login/authenticate,this... > System.setProperty("authkit.action","/usr/bin/id"); > just before this... > lc.login(); > To clarify, safely ignored as you are already complete. > > Mike Hall mikehall at spacestar dot net > http://www.spacestar.net/users/mikehall > http://sourceforge.net/projects/macnative > > > Dmitry Markman From dmarkman at mac.com Mon Mar 20 07:44:45 2006 From: dmarkman at mac.com (Dmitry Markman) Date: Mon, 20 Mar 2006 09:44:45 -0500 Subject: [Rxtx] Mac OS X RXTX java installer In-Reply-To: References: <07D0DE29-BA32-4CFE-B036-66BC6423D385@buechse.de> <441AE3E0.2030503@willicon.de> <12531986.1142622114996.JavaMail.dmarkman@mac.com> <441B2674.9010409@willicon.de> <13577405.1142634732776.JavaMail.dmarkman@mac.com> <441B4182.8010407@willicon.de> <92CD0D6C-5BE8-426E-A46D-99452059FF49@mac.com> <441BBB2D.8030305@willicon.de> <441C4088.5090905@willicon.de> <64BC1E23-FDDE-4CE6-8863-CFC881CBC224@mac.com> Message-ID: it's in the commapi-0-0-1 branch I tested it right now: cvs co -r commapi-0-0-1 rxtx-devel and I got everything On Mar 20, 2006, at 9:25 AM, Trent Jarvi wrote: > On Mon, 20 Mar 2006, Dr. Douglas Lyon wrote: > >> Hi Trent, >> Thanks for the info on the CVS checkout procedure. >> I did that and am still not sure where the installer is. > > Hi Doug > > It does look like it was not cvs committed. There is no rxtx-devel/ > contrib/MacOSX directory in there at the moment. It was mentioned > that it was put under contrib. > > -- > Trent Jarvi > tjarvi at qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx Dmitry Markman From tjarvi at qbang.org Mon Mar 20 07:52:57 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 20 Mar 2006 07:52:57 -0700 (MST) Subject: [Rxtx] Mac OS X RXTX java installer In-Reply-To: References: <07D0DE29-BA32-4CFE-B036-66BC6423D385@buechse.de> <441AE3E0.2030503@willicon.de> <12531986.1142622114996.JavaMail.dmarkman@mac.com> <441B2674.9010409@willicon.de> <13577405.1142634732776.JavaMail.dmarkman@mac.com> <441B4182.8010407@willicon.de> <92CD0D6C-5BE8-426E-A46D-99452059FF49@mac.com> <441BBB2D.8030305@willicon.de> <441C4088.5090905@willicon.de> <64BC1E23-FDDE-4CE6-8863-CFC881CBC224@mac.com> Message-ID: On Mon, 20 Mar 2006, Dmitry Markman wrote: > it's in the commapi-0-0-1 branch > > I tested it right now: > cvs co -r commapi-0-0-1 rxtx-devel > > and I got everything > A fresh checkout worked. Here is a copy of the tree (just the installer bits) ftp://ftp.qbang.org/pub/rxtx/MacOSX-installer.zip -- Trent Jarvi tjarvi at qbang.org From lyon at docjava.com Mon Mar 20 08:08:26 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Mon, 20 Mar 2006 10:08:26 -0500 Subject: [Rxtx] Mac OS X RXTX java installer In-Reply-To: References: <07D0DE29-BA32-4CFE-B036-66BC6423D385@buechse.de> <441AE3E0.2030503@willicon.de> <12531986.1142622114996.JavaMail.dmarkman@mac.com> <441B2674.9010409@willicon.de> <13577405.1142634732776.JavaMail.dmarkman@mac.com> <441B4182.8010407@willicon.de> <92CD0D6C-5BE8-426E-A46D-99452059FF49@mac.com> <441BBB2D.8030305@willicon.de> <441C4088.5090905@willicon.de> <64BC1E23-FDDE-4CE6-8863-CFC881CBC224@mac.com> Message-ID: Hi All, Is the Auth package able to work properly on non Mac OS's? It was not clear from the doc or download. Thanks! - Doug From dmarkman at mac.com Mon Mar 20 08:15:22 2006 From: dmarkman at mac.com (Dmitry Markman) Date: Mon, 20 Mar 2006 10:15:22 -0500 Subject: [Rxtx] Mac OS X RXTX java installer In-Reply-To: References: <07D0DE29-BA32-4CFE-B036-66BC6423D385@buechse.de> <441AE3E0.2030503@willicon.de> <12531986.1142622114996.JavaMail.dmarkman@mac.com> <441B2674.9010409@willicon.de> <13577405.1142634732776.JavaMail.dmarkman@mac.com> <441B4182.8010407@willicon.de> <92CD0D6C-5BE8-426E-A46D-99452059FF49@mac.com> <441BBB2D.8030305@willicon.de> <441C4088.5090905@willicon.de> <64BC1E23-FDDE-4CE6-8863-CFC881CBC224@mac.com> Message-ID: <217312D8-CCCA-4859-ABA6-32DF1CC817B9@mac.com> thanks Trent, for putting it on ftp server On Mar 20, 2006, at 9:52 AM, Trent Jarvi wrote: > A fresh checkout worked. Here is a copy of the tree (just the > installer bits) > > ftp://ftp.qbang.org/pub/rxtx/MacOSX-installer.zip > Dmitry Markman From dmarkman at mac.com Mon Mar 20 09:14:03 2006 From: dmarkman at mac.com (Dmitry Markman) Date: Mon, 20 Mar 2006 11:14:03 -0500 Subject: [Rxtx] Mac OS X RXTX java installer In-Reply-To: References: <07D0DE29-BA32-4CFE-B036-66BC6423D385@buechse.de> <441AE3E0.2030503@willicon.de> <12531986.1142622114996.JavaMail.dmarkman@mac.com> <441B2674.9010409@willicon.de> <13577405.1142634732776.JavaMail.dmarkman@mac.com> <441B4182.8010407@willicon.de> <92CD0D6C-5BE8-426E-A46D-99452059FF49@mac.com> <441BBB2D.8030305@willicon.de> <441C4088.5090905@willicon.de> <64BC1E23-FDDE-4CE6-8863-CFC881CBC224@mac.com> Message-ID: <4DEBA6F0-DA45-4E84-823E-1F1AC48BDCCC@mac.com> no it will work only on mac os x however it's harmless to run it on other platform if you want to use it for other platform you have to do the following (I'll do it for linux) 1. modify RXTXInstaller class method public static RXTXInstaller getInstance() public static RXTXInstaller getInstance() { String osName = System.getProperty("os.name").toLowerCase(); if(osName.startsWith("mac")){ return new gnu.io.installer.macosx.MACOSXRXTXInstaller(); } else if(osName.startsWith("windows")){ return new gnu.io.installer.windows.WindowsRXTXInstaller(); }else if(osName.startsWith("linux")){ return new gnu.io.installer.linux.LinuxRXTXInstaller(); } return null; } 2. create folder gnu/io/installer/linux/ 3. create class Linux386RXTXInstaller package gnu.io.installer.linux; import java.io.File; public class Linux386RXTXInstaller extends gnu.io.installer.RXTXInstaller{ public Linux386RXTXInstaller(){ createJarFolder(); createLibFolder(); addJarResource("RXTXcomm.jar","/gnu/io/installer/resources/ linux/jar/RXTXcomm.dat"); addLibResource("librxtxSerial.so","/gnu/io/installer/ resources/linux/lib/librxtxSerial.so"); } protected void createJarFolder(){ String javaHome = System.getProperty("java.home"); char separator = File.separatorChar; jarFolder = new File(javaHome+separator+"lib"+separator+"ext"); } protected void createLibFolder(){ String javaHome = System.getProperty("java.home"); char separator = File.separatorChar; libFolder = new File(javaHome+separator+"bin"); } public void runPreProcess() {} //put here some action you need public void runPostProcess() {} //put here some action you need } 4. create folder /gnu/io/installer/resources/linux/jar and put there linux's version of RXTXcomm.dat (which is renamed RXTXcomm.jar) 5. create folder /gnu/io/installer/resources/linux/lib and put there linux's version of librxtxSerial. so 6. make sure that RXTXInstaller.jar has the following items: /gnu/io/installer/resources/linux/jar/RXTXcomm.jar /gnu/io/installer/resources/linux/lib/librxtxSerial.so 7. modify file installer.pref: jar file RXTXInstaller.jar must have the following item /gnu/io/installer/installer.pref that's basically it for windows you have to do the similar things: just replace linux to windows and librxtxSerial.so to rxtxSerial.dll and create appropriate gnu.io.installer.windows.WindowsRXTXInstaller class package gnu.io.installer.windows; import java.io.File; public class WindowsRXTXInstaller extends gnu.io.installer.RXTXInstaller{ public WindowsRXTXInstaller(){ createJarFolder(); createLibFolder(); addJarResource("RXTXcomm.jar","/gnu/io/installer/resources/ windows/jar/RXTXcomm.dat"); addLibResource("librxtxSerial.so","/gnu/io/installer/ resources/windows/lib/rxtxSerial.dll"); } protected void createJarFolder(){ String javaHome = System.getProperty("java.home"); char separator = File.separatorChar; jarFolder = new File(javaHome+separator+"lib"+separator+"ext"); } protected void createLibFolder(){ String javaHome = System.getProperty("java.home"); char separator = File.separatorChar; libFolder = new File(javaHome+separator+"bin"); } public void runPreProcess() {} //put here some action you need public void runPostProcess() {} //put here some action you need } installer.pref will look like On Mar 20, 2006, at 10:08 AM, Dr. Douglas Lyon wrote: > Hi All, > Is the Auth package able to work properly on > non Mac OS's? > It was not clear from the doc or download. > > Thanks! > - Doug > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx Dmitry Markman From joachim at buechse.de Mon Mar 20 10:49:06 2006 From: joachim at buechse.de (Joachim Buechse) Date: Mon, 20 Mar 2006 18:49:06 +0100 Subject: [Rxtx] BUG: Lock file stays even if port opening fails Message-ID: This was only tested on MacOSX but looking at the code, it should be true for all systems that use lock_uucp. I am opening a port which can not be opened (dialup port of a telephone paired via bluetooth but currently not reachable). The lock file is created and stays arround, even though the port open failed. After looking a bit through the code (of 2.17), I really wonder if it wouldn't be a good idea to make the "locking" an explicit operation called from the java code. This would certainly simplify the generation of meaningfull exceptions (and java based debugging). Maybe even the handling of "preopened" ports should be in the Java part of the lib (again for java based debugging puposes). That beeing said, I have no idea if this would be possible for the 2.07 implementation. Regards, Joachim From tjarvi at qbang.org Mon Mar 20 11:24:22 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 20 Mar 2006 11:24:22 -0700 (MST) Subject: [Rxtx] BUG: Lock file stays even if port opening fails In-Reply-To: References: Message-ID: On Mon, 20 Mar 2006, Joachim Buechse wrote: > This was only tested on MacOSX but looking at the code, it should be true > for all systems that use lock_uucp. > > I am opening a port which can not be opened (dialup port of a telephone > paired via bluetooth but currently not reachable). The lock file is > created and stays arround, even though the port open failed. > > > After looking a bit through the code (of 2.17), I really wonder if it > wouldn't be a good idea to make the "locking" an explicit operation > called from the java code. This would certainly simplify the generation > of meaningfull exceptions (and java based debugging). > Maybe even the handling of "preopened" ports should be in the Java part > of the lib (again for java based debugging puposes). That beeing said, I > have no idea if this would be possible for the 2.07 implementation. > > Regards, Hi Joachim It should be possible in the 2.0-7 implementation too. The calls to RXTXPort.java would not change. We would just do more there Moving more of that logic into Java would be better as many people don't like to look at C code. There is a liblockdev on most Linux distros that can do most of the C code and would be easier to use. The problem is embeded devices will not have that library. The preopened port code has not been really tested. That was a last minute request in a product cycle. I expect it will be tested this year though. As I recall, some devices really do not like CD raising on open. The preopened ports then allow people to mess around in java without power cycling the devices or losing data. -- Trent Jarvi tjarvi at qbang.org From joachim at buechse.de Mon Mar 20 12:01:08 2006 From: joachim at buechse.de (Joachim Buechse) Date: Mon, 20 Mar 2006 20:01:08 +0100 Subject: [Rxtx] BUG: Lock file stays even if port opening fails In-Reply-To: References: Message-ID: Hi Trent, What is your general feeling about moving code to Java? The last days I have been reading quite a bit of the code and there are several things, that might not work as expected. I'll give you two examples from is_device_locked: if LOCKDIR == /var/spool/locks the directory /var/spool/lock will not be checked. LOCKDIR is not checked for lockfiles with unexpected pefixes While these things have probably never been discovered in production, they are still possibly incorrect implementations. If it was Java code, I would write some unit tests producing the errors that could later be corrected. PS: One could imagine to actually implement the whole lockfile handling in Java using some native routines to get the values required (pid, st_dev, st_rdev, ...). On 20.03.2006, at 19:24, Trent Jarvi wrote: > On Mon, 20 Mar 2006, Joachim Buechse wrote: > >> This was only tested on MacOSX but looking at the code, it should >> be true for all systems that use lock_uucp. >> >> I am opening a port which can not be opened (dialup port of a >> telephone paired via bluetooth but currently not reachable). The >> lock file is created and stays arround, even though the port open >> failed. >> >> >> After looking a bit through the code (of 2.17), I really wonder if >> it wouldn't be a good idea to make the "locking" an explicit >> operation called from the java code. This would certainly simplify >> the generation of meaningfull exceptions (and java based debugging). >> Maybe even the handling of "preopened" ports should be in the Java >> part of the lib (again for java based debugging puposes). That >> beeing said, I have no idea if this would be possible for the 2.07 >> implementation. >> >> Regards, > > Hi Joachim > > It should be possible in the 2.0-7 implementation too. The calls > to RXTXPort.java would not change. We would just do more there > Moving more of that logic into Java would be better as many people > don't like to look at C code. There is a liblockdev on most Linux > distros that can do most of the C code and would be easier to use. > The problem is embeded devices will not have that library. > > The preopened port code has not been really tested. That was a > last minute request in a product cycle. I expect it will be tested > this year though. As I recall, some devices really do not like CD > raising on open. The preopened ports then allow people to mess > around in java without power cycling the devices or losing data. > > -- > Trent Jarvi > tjarvi at qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Mon Mar 20 12:21:02 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 20 Mar 2006 12:21:02 -0700 (MST) Subject: [Rxtx] BUG: Lock file stays even if port opening fails In-Reply-To: References: Message-ID: On Mon, 20 Mar 2006, Joachim Buechse wrote: > Hi Trent, > > What is your general feeling about moving code to Java? The last days I > have been reading quite a bit of the code and there are several things, > that might not work as expected. > > I'll give you two examples from is_device_locked: > > if LOCKDIR == /var/spool/locks the directory /var/spool/lock will not be > checked. > LOCKDIR is not checked for lockfiles with unexpected pefixes > > While these things have probably never been discovered in production, > they are still possibly incorrect implementations. If it was Java code, I > would write some unit tests producing the errors that could later be > corrected. > > PS: One could imagine to actually implement the whole lockfile handling > in Java using some native routines to get the values required (pid, > st_dev, st_rdev, ...). Hi Joachim I like the idea of moving more of the code into java but there are some things to consider. If you break this into multiple JNI calls, the performance will drop considerably during enumeration of ports. We are looking for 256 ports per dev type vs (16? in Sun's 2.0 and fewer types). Its hard to make assumptions. I've seen virtual ports start at /dev/foo100 for instance. It works out to over 7500 ports on Linux if you enable them all. We already trim that back by default. See Linux-all-ports in RXTXCommDriver.java. There are also native libraries that rxtx can link to. If you move too much into Java, linking to 'standard' libraries with distros will break. "configure --enable-liblock=yes" will not be doable. This is probably a favorable way with RedHat, Debian, Suse and others. Thats the right thing to do if there will be rpms, dpkg, .. For those reasons, I think it still make sense to keep it to a minimal ~3 calls to JNI code that we can use for speed and versatility. lock() isLocked(), unlock() perhaps. When I say speed, its more about avoiding crossing the JNI layer multiple times than java vs C performance. With versatility I think liblock is the right way for most but not all (embeded) linux distros. -- Trent Jarvi tjarvi at qbang.org From joachim at buechse.de Mon Mar 20 12:42:04 2006 From: joachim at buechse.de (Joachim Buechse) Date: Mon, 20 Mar 2006 20:42:04 +0100 Subject: [Rxtx] BUG: Lock file stays even if port opening fails In-Reply-To: References: Message-ID: <82C19FE7-DDCB-45B6-B2C9-7606B66F0124@buechse.de> Ok, what about providing a default implementation in Java? The RXTXCommDriver would call a (native) function useNativeLocking and if it returns true, call the native functions for lock() isLocked (), unlock(), else is would use the Java based default implementation. This could possibly be overriden by a property (again for debugging). Joachim On 20.03.2006, at 20:21, Trent Jarvi wrote: > On Mon, 20 Mar 2006, Joachim Buechse wrote: > >> Hi Trent, >> >> What is your general feeling about moving code to Java? The last >> days I have been reading quite a bit of the code and there are >> several things, that might not work as expected. >> >> I'll give you two examples from is_device_locked: >> >> if LOCKDIR == /var/spool/locks the directory /var/spool/lock will >> not be checked. >> LOCKDIR is not checked for lockfiles with unexpected pefixes >> >> While these things have probably never been discovered in >> production, they are still possibly incorrect implementations. If >> it was Java code, I would write some unit tests producing the >> errors that could later be corrected. >> >> PS: One could imagine to actually implement the whole lockfile >> handling in Java using some native routines to get the values >> required (pid, st_dev, st_rdev, ...). > > Hi Joachim > > I like the idea of moving more of the code into java but there are > some things to consider. > > If you break this into multiple JNI calls, the performance will > drop considerably during enumeration of ports. We are looking for > 256 ports per dev type vs (16? in Sun's 2.0 and fewer types). Its > hard to make assumptions. I've seen virtual ports start at /dev/ > foo100 for instance. > > It works out to over 7500 ports on Linux if you enable them all. > We already trim that back by default. See Linux-all-ports in > RXTXCommDriver.java. > > There are also native libraries that rxtx can link to. If you move > too much into Java, linking to 'standard' libraries with distros > will break. "configure --enable-liblock=yes" will not be doable. > This is probably a favorable way with RedHat, Debian, Suse and > others. Thats the right thing to do if there will be rpms, dpkg, .. > > For those reasons, I think it still make sense to keep it to a > minimal ~3 calls to JNI code that we can use for speed and > versatility. lock() isLocked(), unlock() perhaps. When I say > speed, its more about avoiding crossing the JNI layer multiple > times than java vs C performance. With versatility I think liblock > is the right way for most but not all (embeded) linux distros. > > -- > Trent Jarvi > tjarvi at qbang.org > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Mon Mar 20 12:44:47 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 20 Mar 2006 12:44:47 -0700 (MST) Subject: [Rxtx] BUG: Lock file stays even if port opening fails In-Reply-To: <82C19FE7-DDCB-45B6-B2C9-7606B66F0124@buechse.de> References: <82C19FE7-DDCB-45B6-B2C9-7606B66F0124@buechse.de> Message-ID: On Mon, 20 Mar 2006, Joachim Buechse wrote: > Ok, what about providing a default implementation in Java? > > The RXTXCommDriver would call a (native) function useNativeLocking and if > it returns true, call the native functions for lock() isLocked(), > unlock(), else is would use the Java based default implementation. This > could possibly be overriden by a property (again for debugging). > Hi Joachim That would be OK with me. -- Trent Jarvi tjarvi at qbang.org From dmarkman at mac.com Mon Mar 20 22:27:45 2006 From: dmarkman at mac.com (Dmitry Markman) Date: Tue, 21 Mar 2006 00:27:45 -0500 Subject: [Rxtx] binaries request Message-ID: <42702213-C222-4937-A585-7CFB17E47608@mac.com> Hi can somebody send me latest linux and windows binaries, please? or where I can find them (I didn't find them in the latest tareball) I gave up with my cygwin: something wrong I have no idea what java doesn't understand /cygwin/c syntax after I changed makefile it did java part but after that gcc 3.4.4 started to complain I set buffer length to 999 lines but I didn't get beginning of the story something wrong with my 1.4.2_09/include/jni.h gcc doesn't like it anyway I gave up thanks in advance Dmitry Markman -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060320/f8cbc57c/attachment-0046.html From tjarvi at qbang.org Mon Mar 20 22:36:48 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 20 Mar 2006 22:36:48 -0700 (MST) Subject: [Rxtx] binaries request In-Reply-To: <42702213-C222-4937-A585-7CFB17E47608@mac.com> References: <42702213-C222-4937-A585-7CFB17E47608@mac.com> Message-ID: On Tue, 21 Mar 2006, Dmitry Markman wrote: > Hi > can somebody send me latest linux and windows binaries, please? > > or where I can find them (I didn't find them in the latest tareball) > > I gave up with my cygwin: something wrong I have no idea what > java doesn't understand /cygwin/c syntax > after I changed makefile it did java part > but after that gcc 3.4.4 started to complain > I set buffer length to 999 lines but I didn't get beginning of the story > something wrong with my 1.4.2_09/include/jni.h gcc doesn't like it > anyway I gave up > > thanks in advance > Hi Dmitry The bins are here: ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7-bins-r2.zip Here are the files in the zip you want. Jar: rxtx-2.1-7-bins-r2/RXTXcomm.jar Windows: rxtx-2.1-7-bins-r2/Windows/i368-mingw32/rxtxSerial.dll Linux (x86) rxtx-2.1-7-bins-r2/Linux/i686-unknown-linux-gnu/librxtxSerial.so There are others in there including Parallel port support but those are the main ones for testing. -- Trent Jarvi tjarvi at qbang.org From dmarkman at mac.com Mon Mar 20 23:05:59 2006 From: dmarkman at mac.com (Dmitry Markman) Date: Tue, 21 Mar 2006 01:05:59 -0500 Subject: [Rxtx] binaries request In-Reply-To: References: <42702213-C222-4937-A585-7CFB17E47608@mac.com> Message-ID: thank you very much but windows's readme says: rxtxSerial.dll had to be recomopiled to link in missing native methods. should I ignore it? or what? thanks again also I understand that I should use mingw not cygwin I'll try to install mingw On Mar 21, 2006, at 12:36 AM, Trent Jarvi wrote: > On Tue, 21 Mar 2006, Dmitry Markman wrote: > >> Hi >> can somebody send me latest linux and windows binaries, please? >> >> or where I can find them (I didn't find them in the latest tareball) >> >> I gave up with my cygwin: something wrong I have no idea what >> java doesn't understand /cygwin/c syntax >> after I changed makefile it did java part >> but after that gcc 3.4.4 started to complain >> I set buffer length to 999 lines but I didn't get beginning of the >> story >> something wrong with my 1.4.2_09/include/jni.h gcc doesn't like it >> anyway I gave up >> >> thanks in advance >> > > Hi Dmitry > > The bins are here: > > ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7-bins-r2.zip > > Here are the files in the zip you want. > > Jar: > > rxtx-2.1-7-bins-r2/RXTXcomm.jar > > Windows: > > rxtx-2.1-7-bins-r2/Windows/i368-mingw32/rxtxSerial.dll > > Linux (x86) > > rxtx-2.1-7-bins-r2/Linux/i686-unknown-linux-gnu/librxtxSerial.so > > There are others in there including Parallel port support but those > are the main ones for testing. > > -- > Trent Jarvi > tjarvi at qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx Dmitry Markman From tjarvi at qbang.org Mon Mar 20 23:20:33 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 20 Mar 2006 23:20:33 -0700 (MST) Subject: [Rxtx] binaries request In-Reply-To: References: <42702213-C222-4937-A585-7CFB17E47608@mac.com> Message-ID: On Tue, 21 Mar 2006, Dmitry Markman wrote: > thank you very much > > but windows's readme says: > rxtxSerial.dll had to be recomopiled to link in missing native methods. > > should I ignore it? or what? > Hi Dmitry That dll should be OK. r2 is the recompile linked to the missing native method. The readme explains why it was recompiled; fuser.o was not linked into the dll in the first release. -- Trent Jarvi tjarvi at qbang.org From ariantristan at yahoo.com Mon Mar 20 23:55:24 2006 From: ariantristan at yahoo.com (Lambok Sianturi) Date: Mon, 20 Mar 2006 22:55:24 -0800 (PST) Subject: [Rxtx] jvm issue Message-ID: <20060321065524.94779.qmail@web50701.mail.yahoo.com> Hi All, This is my first time to join RxTx mailing list. I thank you all for allowing others to sign in in requests help. I use the latest RxTx lib in Fedora 3 with java version 1.4.2_09 b05. And I got this error: # # An unexpected error has been detected by HotSpot Virtual Machine: # # SIGSEGV (0xb) at pc=0x00bf27f3, pid=2633, tid=3086112448 # # Java VM: Java HotSpot(TM) Client VM (1.4.2_09-b05 mixed mode) # Problematic frame: # C [ld-linux.so.2+0xa7f3] # # An error report file with more information is saved as hs_err_pid2633.log # # If you would like to submit a bug report, please visit: # http://java.sun.com/webapps/bugreport/crash.jsp # ./run.sh: line 3: 2633 Aborted /usr/local/java/bin/java -Djava.library.path=/usr/local/java/jre/lib/ -Djsmsengine.debug=true -classpath jsmsengine.jar:smsgateway.jar:classes12.jar:RXTXcomm.jar:. com.api.sms.SMSServer What is the jvm depedency for the latest library? Can I use 1.4.2_09 b05? Thanks in advance. Arian --------------------------------- Yahoo! Mail Use Photomail to share photos without annoying attachments. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060320/83d58dd7/attachment-0046.html From f.frumento at ngi.it Tue Mar 21 00:21:47 2006 From: f.frumento at ngi.it (Fabio Frumento) Date: Tue, 21 Mar 2006 08:21:47 +0100 Subject: [Rxtx] Javadoc on the go Message-ID: <441FA98B.9050701@ngi.it> Hi Trent, sorry for the big delay but my job is running wild, i was out for some time but now i'm back and ready to continue the javadoc for Rxtx. Did you used the last javadoc patch i sent you ? let me know if i have to send it to you again or not. regards Fabio From lyon at docjava.com Tue Mar 21 00:51:18 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Tue, 21 Mar 2006 02:51:18 -0500 Subject: [Rxtx] lock files Message-ID: Hi All, You know, if the use of lock files were under Java control (rather than a build-time decision), it might enable a more unified binary distro. It might also facilitate quick prototyping of non-lock file approaches to resolving serial port contention issues (i.e., mac-like approaches vs. linux approaches, etc.). I realize that this is a radical overhaul of the lock file policy issue. Also, it may harm performance. On the other hand, our benchmarks on JNI overhead for modern processors indicate performance impact should be minimal. Perhaps it is more of an issue with the toybox systems. Suppose there were a class with a reasonable default...someone might write: SerialPortLockPolicy.setPolicy(SerialPortLockPolicy.UNIX_LOCK_FILE); SerialPortLockPolicy.setPolicy(SerialPortLockPolicy.NO_LOCK_CHECKING); SerialPortLockPolicy.setPolicy(SerialPortLockPolicy.MAC_STYLE); Thus, we could have a run-time reconfiguration of the serial port lock policy. A special NO_LOCK version of the binary would no longer be required. Any thoughts on this? Thanks! - Doug From joachim at buechse.de Tue Mar 21 03:09:09 2006 From: joachim at buechse.de (Joachim Buechse) Date: Tue, 21 Mar 2006 11:09:09 +0100 Subject: [Rxtx] lock files In-Reply-To: References: Message-ID: <8E12916A-1B9A-4FF2-B684-E2D1C794221B@buechse.de> This is pretty much what I thought about when I suggested, that the default behaviour could be overwritten with a property. I am very much in favor of this approach. In particular this allows much easier debugging for PC based java developers. I think big parts of the Java (and maybe some parts of the C code) could use a bit of a structural workover (unit tests, javadoc, synchronization, etc). Maybe there should be a CVS branch for this experimental version. I'd be happy to contribute a first workover for some of the Java code. Designing for testability and implementing a good bunch of unit tests has been a strategy that worked quite well in the Java projects I lead. And it ultimately allows more liberal change permission. Regards, Joachim On 21.03.2006, at 08:51, Dr. Douglas Lyon wrote: > Hi All, > You know, if the use of lock files were > under Java control (rather than a build-time decision), > it might enable a more unified binary distro. It might also > facilitate quick prototyping of non-lock file approaches > to resolving serial port contention issues (i.e., mac-like > approaches vs. linux approaches, etc.). > > I realize that this is a radical overhaul of the lock file policy > issue. Also, it may harm performance. On the other hand, > our benchmarks on JNI overhead for modern processors indicate > performance impact should be minimal. Perhaps it is more of > an issue with the toybox systems. > > Suppose there were a class with a reasonable default...someone > might write: > SerialPortLockPolicy.setPolicy(SerialPortLockPolicy.UNIX_LOCK_FILE); > SerialPortLockPolicy.setPolicy(SerialPortLockPolicy.NO_LOCK_CHECKING); > SerialPortLockPolicy.setPolicy(SerialPortLockPolicy.MAC_STYLE); > > Thus, we could have a run-time reconfiguration of the serial port lock > policy. A special NO_LOCK version of the binary would no longer > be required. > > Any thoughts on this? > > Thanks! > - Doug > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From joachim at buechse.de Tue Mar 21 06:23:08 2006 From: joachim at buechse.de (Joachim Buechse) Date: Tue, 21 Mar 2006 14:23:08 +0100 Subject: [Rxtx] PATCH: use of ioctl(fd, TIOCEXCL) instead of lockfiles Message-ID: <923AE774-EEA2-4911-92D8-32BB27802C8B@buechse.de> Here is the patch for the ioctl(fd, TIOCEXCL). I have verified this only for OSX 10.4.5, hence it is only defined for APPLE. However, it should work at least for Solaris as well. If a process has requested TIOEXCL further open calls by other user processes will fail. The patch also disables uucp style locking for APPLE. Obviously this is discussable. I think it is the way to go, as it eliminates creating the lock directory which doesnt exist on the standard installation and it eliminates messing with the system group definitions (adding users to group uucp). Regarding the possibility of root processes opening a device which is locked - I consider this a feature not a potential problem. It is highly unlikely, that somebody is crazy enough to run a JavaVM as root (unless he has no other means of getting a restricted IP port opened, ie doesnt understand ipfw). Anyway, even if the process runs as root, it fails when calling ioctl(fd, TIOCEXCL). It could however still open the port to listen for RING events. I.e. a fax server which needs to see incoming calls but otherwise doesnt want to block the port. So the only case where the proposed mechanism fails is, if an incorrectly implemented process running as root conflicts with a user process. I think this can be accepted. Regards, Joachim PS: If this patch is generally accepted, the installer and Mac doku should obviously be changed as well. Index: SerialImp.c =================================================================== RCS file: /usr/local/cvsroot/rxtx-devel/src/SerialImp.c,v retrieving revision 1.46.2.187 diff -u -r1.46.2.187 SerialImp.c --- SerialImp.c 29 Jan 2006 22:19:04 -0000 1.46.2.187 +++ SerialImp.c 21 Mar 2006 12:59:16 -0000 @@ -656,6 +656,25 @@ fd=OPEN (filename, O_RDWR | O_NOCTTY | O_NONBLOCK ); } while (fd < 0 && errno==EINTR); +#ifdef OPEN_EXCL + // Note that open() follows POSIX semantics: multiple open() calls to + // the same file will succeed unless the TIOCEXCL ioctl is issued. + // This will prevent additional opens except by root-owned processes. + // See tty(4) ("man 4 tty") and ioctl(2) ("man 2 ioctl") for details. + + if (fd >= 0 && (ioctl(fd, TIOCEXCL) == -1)) + { + sprintf( message, "open: exclusive access denied for % s\n", + filename ); + report( message ); + report_error( message ); + + close(fd); + goto fail; + } +#endif /* OPEN_EXCL */ + + if( configure_port( fd ) ) goto fail; (*env)->ReleaseStringUTFChars( env, jstr, filename ); sprintf( message, "open: fd returned is %i\n", fd ); Index: SerialImp.h =================================================================== RCS file: /usr/local/cvsroot/rxtx-devel/src/SerialImp.h,v retrieving revision 1.11.2.49 diff -u -r1.11.2.49 SerialImp.h --- SerialImp.h 5 Jul 2005 17:47:21 -0000 1.11.2.49 +++ SerialImp.h 21 Mar 2006 12:59:17 -0000 @@ -135,7 +135,8 @@ /*# define LOCKDIR "/var/spool/uucp"*/ # define LOCKDIR "/var/lock" # define LOCKFILEPREFIX "LK." -# define UUCP +/*# define UUCP*/ +# define OPEN_EXCL #endif /* __APPLE__ */ #if defined(__NetBSD__) # define DEVICEDIR "/dev/" From tjarvi at qbang.org Tue Mar 21 10:26:08 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 21 Mar 2006 10:26:08 -0700 (MST) Subject: [Rxtx] Javadoc on the go In-Reply-To: <441FA98B.9050701@ngi.it> References: <441FA98B.9050701@ngi.it> Message-ID: On Tue, 21 Mar 2006, Fabio Frumento wrote: > Hi Trent, > > sorry for the big delay but my job is running wild, i was out for some > time but now i'm back and ready to continue the javadoc for Rxtx. > > Did you used the last javadoc patch i sent you ? let me know if i have to > send it to you again or not. > > regards > > Fabio Hi Fabio The patch is in the rxtx mail-list archives. It will be going in soon. I did not see a time critical portion. I'll probably be going through the list since the last batch of patches this weekend and putting them into CVS. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Tue Mar 21 10:57:18 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 21 Mar 2006 10:57:18 -0700 (MST) Subject: [Rxtx] jvm issue In-Reply-To: <20060321065524.94779.qmail@web50701.mail.yahoo.com> References: <20060321065524.94779.qmail@web50701.mail.yahoo.com> Message-ID: On Mon, 20 Mar 2006, Lambok Sianturi wrote: > Hi All, > This is my first time to join RxTx mailing list. I thank you all for allowing others to sign in in requests help. > I use the latest RxTx lib in Fedora 3 with java version 1.4.2_09 b05. And I got this error: > > # > # An unexpected error has been detected by HotSpot Virtual Machine: > # > # SIGSEGV (0xb) at pc=0x00bf27f3, pid=2633, tid=3086112448 > # > # Java VM: Java HotSpot(TM) Client VM (1.4.2_09-b05 mixed mode) > # Problematic frame: > # C [ld-linux.so.2+0xa7f3] A native library loading error? What happens if you recompile rxtx on your system and install that? This sounds like an ABI problem? rxtx 2.1-7 was compiled with a gcc 2.96 toolchain as I recall. The hope is newer system will be backwards compatible. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Tue Mar 21 11:05:29 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 21 Mar 2006 11:05:29 -0700 (MST) Subject: [Rxtx] PATCH: use of ioctl(fd, TIOCEXCL) instead of lockfiles In-Reply-To: <923AE774-EEA2-4911-92D8-32BB27802C8B@buechse.de> References: <923AE774-EEA2-4911-92D8-32BB27802C8B@buechse.de> Message-ID: On Tue, 21 Mar 2006, Joachim Buechse wrote: > Here is the patch for the ioctl(fd, TIOCEXCL). I have verified this only > for OSX 10.4.5, hence it is only defined for APPLE. However, it should > work at least for Solaris as well. > > If a process has requested TIOEXCL further open calls by other user > processes will fail. > > The patch also disables uucp style locking for APPLE. Obviously this is > discussable. I think it is the way to go, as it eliminates creating the > lock directory which doesnt exist on the standard installation and it > eliminates messing with the system group definitions (adding users to > group uucp). > > Regarding the possibility of root processes opening a device which is > locked - I consider this a feature not a potential problem. It is highly > unlikely, that somebody is crazy enough to run a JavaVM as root (unless > he has no other means of getting a restricted IP port opened, ie doesnt > understand ipfw). Anyway, even if the process runs as root, it fails when > calling ioctl(fd, TIOCEXCL). It could however still open the port to > listen for RING events. I.e. a fax server which needs to see incoming > calls but otherwise doesnt want to block the port. So the only case where > the proposed mechanism fails is, if an incorrectly implemented process > running as root conflicts with a user process. I think this can be > accepted. > > Regards, > Joachim > > PS: If this patch is generally accepted, the installer and Mac doku > should obviously be changed as well. > > > Index: SerialImp.c > =================================================================== > RCS file: /usr/local/cvsroot/rxtx-devel/src/SerialImp.c,v > retrieving revision 1.46.2.187 > diff -u -r1.46.2.187 SerialImp.c > --- SerialImp.c 29 Jan 2006 22:19:04 -0000 1.46.2.187 > +++ SerialImp.c 21 Mar 2006 12:59:16 -0000 > @@ -656,6 +656,25 @@ > fd=OPEN (filename, O_RDWR | O_NOCTTY | O_NONBLOCK ); > } while (fd < 0 && errno==EINTR); > > +#ifdef OPEN_EXCL > + // Note that open() follows POSIX semantics: multiple open() > calls to > + // the same file will succeed unless the TIOCEXCL ioctl is > issued. > + // This will prevent additional opens except by root-owned > processes. > + // See tty(4) ("man 4 tty") and ioctl(2) ("man 2 ioctl") for > details. > + > + if (fd >= 0 && (ioctl(fd, TIOCEXCL) == -1)) > + { > + sprintf( message, "open: exclusive access denied for % > s\n", > + filename ); > + report( message ); > + report_error( message ); > + > + close(fd); > + goto fail; > + } > +#endif /* OPEN_EXCL */ > + > + > if( configure_port( fd ) ) goto fail; > (*env)->ReleaseStringUTFChars( env, jstr, filename ); > sprintf( message, "open: fd returned is %i\n", fd ); > Index: SerialImp.h > =================================================================== > RCS file: /usr/local/cvsroot/rxtx-devel/src/SerialImp.h,v > retrieving revision 1.11.2.49 > diff -u -r1.11.2.49 SerialImp.h > --- SerialImp.h 5 Jul 2005 17:47:21 -0000 1.11.2.49 > +++ SerialImp.h 21 Mar 2006 12:59:17 -0000 > @@ -135,7 +135,8 @@ > /*# define LOCKDIR "/var/spool/uucp"*/ > # define LOCKDIR "/var/lock" > # define LOCKFILEPREFIX "LK." > -# define UUCP > +/*# define UUCP*/ > +# define OPEN_EXCL > #endif /* __APPLE__ */ > #if defined(__NetBSD__) > # define DEVICEDIR "/dev/" > This looks like a good start. What do you think Dmitry? Perhaps all systems with TIOCEXCL defined should use that though. Even if they use lockfiles. It wont hurt anything. That would catch people hacking their own serial apps without checking lockfiles. Its a good idea to avoid C++ style comments in the C portions. Some older systems don't deal with them well. If it's just for Mac OS X, it isn't a big deal. I think it was the Irix compiler that was problematic? -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Tue Mar 21 11:22:05 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 21 Mar 2006 11:22:05 -0700 (MST) Subject: [Rxtx] lock files In-Reply-To: <8E12916A-1B9A-4FF2-B684-E2D1C794221B@buechse.de> References: <8E12916A-1B9A-4FF2-B684-E2D1C794221B@buechse.de> Message-ID: We can try it. Maybe the JNI is much improved. The nice thing about linking into liblock is distros then worry about lockfiles on their systems. This way, we have to deal with any changes that may show up. On Tue, 21 Mar 2006, Joachim Buechse wrote: > This is pretty much what I thought about when I suggested, that the > default behaviour could be overwritten with a property. I am very much in > favor of this approach. In particular this allows much easier debugging > for PC based java developers. > > I think big parts of the Java (and maybe some parts of the C code) could > use a bit of a structural workover (unit tests, javadoc, synchronization, > etc). Maybe there should be a CVS branch for this experimental version. > I'd be happy to contribute a first workover for some of the Java code. > Designing for testability and implementing a good bunch of unit tests has > been a strategy that worked quite well in the Java projects I lead. And > it ultimately allows more liberal change permission. > > Regards, > Joachim > > > On 21.03.2006, at 08:51, Dr. Douglas Lyon wrote: > >> Hi All, >> You know, if the use of lock files were >> under Java control (rather than a build-time decision), >> it might enable a more unified binary distro. It might also >> facilitate quick prototyping of non-lock file approaches >> to resolving serial port contention issues (i.e., mac-like >> approaches vs. linux approaches, etc.). >> >> I realize that this is a radical overhaul of the lock file policy >> issue. Also, it may harm performance. On the other hand, >> our benchmarks on JNI overhead for modern processors indicate >> performance impact should be minimal. Perhaps it is more of >> an issue with the toybox systems. >> >> Suppose there were a class with a reasonable default...someone >> might write: >> SerialPortLockPolicy.setPolicy(SerialPortLockPolicy.UNIX_LOCK_FILE); >> SerialPortLockPolicy.setPolicy(SerialPortLockPolicy.NO_LOCK_CHECKING); >> SerialPortLockPolicy.setPolicy(SerialPortLockPolicy.MAC_STYLE); >> >> Thus, we could have a run-time reconfiguration of the serial port lock >> policy. A special NO_LOCK version of the binary would no longer >> be required. >> >> Any thoughts on this? >> >> Thanks! >> - Doug >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From dmarkman at mac.com Tue Mar 21 16:05:17 2006 From: dmarkman at mac.com (Dmitry Markman) Date: Tue, 21 Mar 2006 18:05:17 -0500 Subject: [Rxtx] PATCH: use of ioctl(fd, TIOCEXCL) instead of lockfiles In-Reply-To: References: <923AE774-EEA2-4911-92D8-32BB27802C8B@buechse.de> Message-ID: <512AC70C-BB86-48F2-A83C-023F35C23BAB@mac.com> I think it's cool, but I'd like to have that property implementation when user can choose between locking mechanism about comments: it's easy to change comments to the C style or we can use extensions of the file to cpp so c++ compiler will be used On Mar 21, 2006, at 1:05 PM, Trent Jarvi wrote: > This looks like a good start. What do you think Dmitry? Perhaps > all systems with TIOCEXCL defined should use that though. Even if > they use lockfiles. It wont hurt anything. That would catch > people hacking their own serial apps without checking lockfiles. > > Its a good idea to avoid C++ style comments in the C portions. > Some older systems don't deal with them well. If it's just for Mac > OS X, it isn't a big deal. I think it was the Irix compiler that > was problematic? Dmitry Markman From dmarkman at mac.com Tue Mar 21 16:13:00 2006 From: dmarkman at mac.com (Dmitry Markman) Date: Tue, 21 Mar 2006 18:13:00 -0500 Subject: [Rxtx] PATCH: use of ioctl(fd, TIOCEXCL) instead of lockfiles In-Reply-To: References: <923AE774-EEA2-4911-92D8-32BB27802C8B@buechse.de> Message-ID: I'd like to add that creating locking folder isn't a big deal we never had a problem related to the lock folders, because we always used installer on mac os x from other hand I'm not very much familiar with iotcl locking approach and I'm not sure it's more efficient Joachim wrote "I think it is the way to go, as it eliminates creating the lock directory which doesnt exist on the standard installation and it eliminates messing with the system group definitions (adding users to group uucp)." but I really didn't have any problem with that 1. doesn't exist on the standard installation there are many-many things that don't exist in the standard installation so I don't think that argument is strong enough 2. messing with the system group definitions I don't think we're messing with the group definition mac os x provides very clear way to set up group's members and together with Greg Guerin AuthKit there is no problem to set those definitions so I don't think that argument is strong either but from other hand using iotcl is more promising and is more elegant On Mar 21, 2006, at 1:05 PM, Trent Jarvi wrote: > > This looks like a good start. What do you think Dmitry? Perhaps > all systems with TIOCEXCL defined should use that though. Even if > they use lockfiles. It wont hurt anything. That would catch > people hacking their own serial apps without checking lockfiles. Dmitry Markman From joachim at buechse.de Wed Mar 22 04:46:45 2006 From: joachim at buechse.de (Joachim Buechse) Date: Wed, 22 Mar 2006 12:46:45 +0100 Subject: [Rxtx] PATCH: use of ioctl(fd, TIOCEXCL) instead of lockfiles In-Reply-To: References: <923AE774-EEA2-4911-92D8-32BB27802C8B@buechse.de> Message-ID: Sorry, I was not very clear with my arguments, so I will try again;-) Please, don't take this as an attack against work that has been done. I think the contributions that have been made in the past were made in a good spirit. But I really believe, that the current solution for OSX has many shortcomings and should be changed as soon as possible. lock files --- The /var/lock folder does not exist on the standard OSX installation, however the standard installation includes several applications that use serial ports (i.e. the FAX capability). This indicates, that the lock folder approach will not work well with system components. Applications for OSX will generally try to live in harmony with system components (except for HP print drivers of course). I think RXTX should follow this approach as well. uucp group --- Accessing serial ports is not an admin privileged operation on OSX. Any user (world) has read/write privileges on /dev/tty*. So the system default is to not enforce any group membership to access these ports. The group uucp however is a system group on all unix systems I know. It exists for certain system processes. A non admin user should in general not be a member of this group. Quite arguably no user should ever be a member of this group. Installer --- My general opinion is, that - no Installer should touch user or group data without warning - no Application Installer should touch groups which are not specific to the very application installed - no Installer should ever add regular users to a system group The current installer injects the installing user in the group uucp without warning about this change and without giving the option to "opt out" of this change. This is a potential security risk (but not currently a real one, as OSX contains no folders belonging to group uucp). The current installer does not work for multi user systems. It puts the installing user in the uucp group. However the installing user is not necessarily the user that will use the application. Putting all users that may use a serial port application in the system group uucp seems like a very invasive approach to me. Besides that, newly created users will not automatically be in the group and hence, serial applications will "break" for new users without obvious reasons. Avoiding the lock files will allow self contained applications (i.e. drag&drop installation). In my eyes this is largely preferable over an installer that requests admin privileges. Adding up all these points indicates very strongly, that the lock-file implementation is not the way to go on OSX. Regards, Joachim On 22.03.2006, at 00:13, Dmitry Markman wrote: > I'd like to add that > > creating locking folder isn't a big deal > we never had a problem related to the lock folders, because we > always used installer on mac os x > from other hand I'm not very much familiar with iotcl locking > approach and I'm not sure it's more efficient > > Joachim wrote "I think it is the way to go, as it eliminates > creating the lock directory which doesnt exist on the standard > installation and it eliminates messing with the system group > definitions (adding users to group uucp)." but I really didn't have > any problem with that > > 1. doesn't exist on the standard installation > there are many-many things that don't exist in the standard > installation so I don't think that argument is strong enough > 2. messing with the system group definitions > I don't think we're messing with the group definition > mac os x provides very clear way to set up group's members and > together with Greg Guerin AuthKit there is no problem to set those > definitions > so I don't think that argument is strong either > but from other hand using iotcl is more promising and is more elegant > > > > On Mar 21, 2006, at 1:05 PM, Trent Jarvi wrote: > >> >> This looks like a good start. What do you think Dmitry? Perhaps >> all systems with TIOCEXCL defined should use that though. Even if >> they use lockfiles. It wont hurt anything. That would catch >> people hacking their own serial apps without checking lockfiles. > > Dmitry Markman > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From dmarkman at mac.com Wed Mar 22 05:27:13 2006 From: dmarkman at mac.com (Dmitry Markman) Date: Wed, 22 Mar 2006 07:27:13 -0500 Subject: [Rxtx] PATCH: use of ioctl(fd, TIOCEXCL) instead of lockfiles In-Reply-To: References: <923AE774-EEA2-4911-92D8-32BB27802C8B@buechse.de> Message-ID: <83440CF3-DCD8-41C1-B941-F227232C27E3@mac.com> thanks for the very good explanation I didn't think that you were attacking any thing, so don't worry I just had feeling, that there were more aesthetic reasons for going to ioctl then real necessity now you explained everything quite well (BTW, asfar as I remember installer asks admin password so it wasn't quiet, but it really doesn't matter now) thanks On Mar 22, 2006, at 6:46 AM, Joachim Buechse wrote: > Sorry, I was not very clear with my arguments, so I will try again;-) > > Please, don't take this as an attack against work that has been > done. I think the contributions that have been made in the past > were made in a good spirit. But I really believe, that the current > solution for OSX has many shortcomings and should be changed as > soon as possible. > > lock files > --- > The /var/lock folder does not exist on the standard OSX > installation, however the standard installation includes several > applications that use serial ports (i.e. the FAX capability). This > indicates, that the lock folder approach will not work well with > system components. Applications for OSX will generally try to live > in harmony with system components (except for HP print drivers of > course). I think RXTX should follow this approach as well. > > uucp group > --- > Accessing serial ports is not an admin privileged operation on OSX. > Any user (world) has read/write privileges on /dev/tty*. So the > system default is to not enforce any group membership to access > these ports. The group uucp however is a system group on all unix > systems I know. It exists for certain system processes. A non admin > user should in general not be a member of this group. Quite > arguably no user should ever be a member of this group. > > Installer > --- > My general opinion is, that > - no Installer should touch user or group data without warning > - no Application Installer should touch groups which are not > specific to the very application installed > - no Installer should ever add regular users to a system group > > The current installer injects the installing user in the group uucp > without warning about this change and without giving the option to > "opt out" of this change. This is a potential security risk (but > not currently a real one, as OSX contains no folders belonging to > group uucp). > > The current installer does not work for multi user systems. It puts > the installing user in the uucp group. However the installing user > is not necessarily the user that will use the application. Putting > all users that may use a serial port application in the system > group uucp seems like a very invasive approach to me. Besides that, > newly created users will not automatically be in the group and > hence, serial applications will "break" for new users without > obvious reasons. > > > Avoiding the lock files will allow self contained applications > (i.e. drag&drop installation). In my eyes this is largely > preferable over an installer that requests admin privileges. Adding > up all these points indicates very strongly, that the lock-file > implementation is not the way to go on OSX. > > Regards, > Joachim > > > On 22.03.2006, at 00:13, Dmitry Markman wrote: > >> I'd like to add that >> >> creating locking folder isn't a big deal >> we never had a problem related to the lock folders, because we >> always used installer on mac os x >> from other hand I'm not very much familiar with iotcl locking >> approach and I'm not sure it's more efficient >> >> Joachim wrote "I think it is the way to go, as it eliminates >> creating the lock directory which doesnt exist on the standard >> installation and it eliminates messing with the system group >> definitions (adding users to group uucp)." but I really didn't >> have any problem with that >> >> 1. doesn't exist on the standard installation >> there are many-many things that don't exist in the standard >> installation so I don't think that argument is strong enough >> 2. messing with the system group definitions >> I don't think we're messing with the group definition >> mac os x provides very clear way to set up group's members and >> together with Greg Guerin AuthKit there is no problem to set those >> definitions >> so I don't think that argument is strong either >> but from other hand using iotcl is more promising and is more elegant >> >> >> >> On Mar 21, 2006, at 1:05 PM, Trent Jarvi wrote: >> >>> >>> This looks like a good start. What do you think Dmitry? Perhaps >>> all systems with TIOCEXCL defined should use that though. Even >>> if they use lockfiles. It wont hurt anything. That would catch >>> people hacking their own serial apps without checking lockfiles. >> >> Dmitry Markman >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx Dmitry Markman From lyon at docjava.com Wed Mar 22 06:12:18 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Wed, 22 Mar 2006 08:12:18 -0500 Subject: [Rxtx] sole of a new design pattern Message-ID: Hi All, I have been thinking about how we design the serial port software. I think we need a new design pattern. For lack of a better term, I shall call it: The Parametric Singleton Design Pattern By Douglas A. Lyon ABSTRACT The goal of the singleton design pattern is to make sure that there is one, and only one, instance of a given class. The goal of the parametric singleton design pattern is to make sure that there is one, and only one, instance of a given class with the given parametric values. We parametric singleton design pattern combines the singleton design pattern with a parameter that enables unique creation of instances of a class. These instances are cached. When a user asks for an instance with these parameters, the cache is checked. If the instance is in the cache, the instance is returned, otherwise it is created, added to the cache and then returned. We apply our parametric singleton design pattern to the retrieval of RMI registries bound to a given port. The goal of our system is to make sure that no two RMI registries are listening to the same socket and to make use of the RMI registries after they have been created. RMI registries are used in distributed computation. Introduction The singleton design pattern is meant to ensure that on a single instance of a class exists. It is also meant to provide a global point of access to it. The intent of the parametric singleton design pattern is to ensure that a class has only one instance for a given set of parameter values. It also provides a global point of access to it. Motivation A system cannot tolerate multiple instances of some classes with identical parameters. For example, you cannot have two instances making use of the same serial port, at the same time. You cannot have two instances that are trying to listen to the same socket connection. You cannot have two instances writing to the same file structure at the same time. As the operating system is often thought of as the arbiter of consumed resources (i.e., tape drives, serial ports, etc.) we frequently leave it to an operating system implementation to resolve these contention issues. Even for similar resources (like serial ports) there are few standards for handling contention. For example, serial ports on Linux are locked using a "/var/lock" file. POSIX, on the other hand, uses ioctl mechanisms to prevent contention. A better solution is to make a class that is responsible for keeping track of the instances created from the class. The class is declared final, so that it cannot be subclassed. The class also has a private constructor, so that other classes cannot instance it. The new design pattern is called the parametric singleton design pattern and it provides a way to access and create instances with given parameters. Applicability Use the Parametric Singleton Design Pattern when: 1. There must be exactly one instance of a class with the given parameters. 2. The instances must be accessible to clients from a well-known access point. Structure Insert UML diagram here. Participants The Parametric Singleton Clients that need instances 1. The Parametric Singleton defines an instance upon request from a client, if, and only if, the instance does not already exist. 2. The Parametric Singleton returns the instance to the client. 3. The Parametric Singleton is responsible for creating unique instances from given parameters. Collaborations Clients obtain a reference to a Parametric Singleton instance only through the parametric singleton design pattern. If the instance is left in an improper state (e.g., the serial port was left open) it is NOT the role of the Parametric Singleton Design Pattern to close the IO port. Nor is it the role of the Parametric Singleton Design Pattern to open the port. That role is delegate to some other part of the system. Further, it is not the role of the Parametric Singleton Design Pattern to check out resources. That is, multiple threads can have multiple references to the same resource at the same time. MUTEX locking is delegated to some other part of the system. Consequences The Parametric Singleton Design Pattern has several benefits: 1. Controlled access to parametrically defined instances. Since the Parametric Singleton class encapsulates its instances, there is control over how and when clients access it. 2. Reduced name space. The Parametric Singleton pattern avoids global variables that store instances created from the same parameter. Implementation Here are implementation issues to consider when using the Parametric Singleton pattern: 1. Unique mapping of parameters. The Parametric Singleton pattern requires that there be a mean to isomorphically map the parameter space into the instance space and back again. 2. Ensure unique instances. The Parametric Singleton pattern makes unique instances from parameters, and it does so only once. 3. Cache instances for fast retrieval. The Parametric Singleton pattern must be able to look up instances, given some set of parameters, and do so from some data structure. That is, there must be enough space to hold references to all the instances the program will need. Also, a mechanism is needed to look up and retrieve the instances quickly enough to satisfy the clients. Sample Code public final class ParametricSingletonRmiRegistry { private static Hashtable registry = new Hashtable(100); // use singleton pattern and??????????????????????????????????????????????? // prevent instantiation of RmiRegistryUtils.?????????????????????????????? private ParametricSingletonRmiRegistry() { } // the only instance of the Registry held by the RmiRegistryUtils?????????? public static void listNames(Integer port) { if (!isInCacheAndRunning(port)) return; Registry r = (Registry) registry.get(port); System.out.println("registry on port: " + port); System.out.println("registry: " + r); System.out.println("names: "); try { print(r.list()); } catch (RemoteException e) { In.message(e); } System.out.println("------------------------"); } /**???????????????????????????????????????????????????????????????????????? * Checks whether a Registry has been started on this host????????????????? * in the specified port.?????????????????????????????????????????????????? * If not, it tries to start one.?????????????????????????????????????????? * when it fails to start a Registry, it exits the program????????????????? * with exit code 1.??????????????????????????????????????????????????????? */ public static void restart(int port) { if (isInCacheAndRunning(port)) return; try { startRegistry(port); } catch (RemoteException e) { In.message(e); } } /**???????????????????????????????????????????????????????????????????????? * @param port????????????????????????????????????????????????????????????? * @return true if registry is in cache and running???????????????????????? */ private static boolean isInCacheAndRunning(Integer port) { if (!isRegistryRunning(port.intValue())) return false; if (!isRegistryInCache(port.intValue())) return false; return true; } /**???????????????????????????????????????????????????????????????????????? * @param port????????????????????????????????????????????????????????????? * @return true if we are able to locate a local registry on port.??????????????????????????????????????????????????????????????????????????? */ private static boolean isRegistryRunning(int port) { try { Registry r = LocateRegistry.getRegistry(port); if (r != null) return true; } catch (RemoteException e) { return false; } return false; } /**???????????????????????????????????????????????????????????????????????? * @param port????????????????????????????????????????????????????????????? * @return return true if registry is in cache????????????????????????????? */ private static boolean isRegistryInCache(int port) { if (registry.get(new Integer(port)) == null) return false; return true; } /**???????????????????????????????????????????????????????????????????????? * Restart the registry, if needed.???????????????????????????????????????? * Return the only instance of the registry for consistent global?????????? * using by making use of the Singleton Design Pattern????????????????????? *????????????????????????????????????????????????????????????????????????? * @return the internally held registry instance.?????????????????????????? */ public static Registry getRegistry(Integer port) { restart(port); return (Registry) registry.get(port); } private static void startRegistry(Integer port) throws RemoteException { Registry r; try { r = LocateRegistry.createRegistry(port.intValue()); registry.put(port, r); //r = new sun.rmi.registry.RegistryImpl???????????????????????????? /// (port.intValue());?????????????????????????????????????? // registry.put(port, r);?????????????????????????????????????????? } catch (Exception e) { //e.printStackTrace();????????????????????????????????????????????? r = LocateRegistry.getRegistry(port.intValue()); registry.put(port, r); } } public static void main(String args[]) throws RemoteException { //restart(port);??????????????????????????????????????????????????????? restart(5001); restart(5002); restart(5002); Registry r = LocateRegistry.getRegistry(5002); System.out.println("registry="+r); } } I would very much like to get your feedback on this new design pattern idea. Thank you for your time. Regards, - Doug From david.garnier at trusted-logic.com Wed Mar 22 07:36:10 2006 From: david.garnier at trusted-logic.com (David Garnier) Date: Wed, 22 Mar 2006 15:36:10 +0100 Subject: [Rxtx] sole of a new design pattern In-Reply-To: References: Message-ID: <442160DA.80107@trusted-logic.com> Hello, > The Parametric Singleton Design Pattern The Singleton is the most abused design pattern ever. Good use-cases for this pattern are extremely rare and mostly confined to problems related to hardware resources, like serial ports. > Applicability > > Use the Parametric Singleton Design Pattern when: > 1. There must be exactly one instance of a class with the given > parameters. OK. As I said above, this case this actually very unusual. The Singleton pattern is mostly used when : > 2. The instances must be accessible to clients from a well-known > access point. Using the singleton pattern in this case is just convenient for the programmer. Problems arises pretty quickly, especially if you attempt to unit-test your classes. 1) If your singleton is stateful, or hold on to stateful objects, it means that two different unit tests are not actually independent. Instead of starting with a brand new environment, the result of a test may be affected by the result of a previous test. This problem also arise when with your class relies on a database. In both cases, the solution is to reset your "unique" resource (Singleton or database) at the beginning of the test, which is a pain. Also, while most projects connect to a single database, projects that allow the use of Singletons usually contain several of thems, and new ones may cropped up unnoticed. You quickly end up with test cases that only pass in a certain order, which is a royal pain. 2) You cannot mockup a singleton. Once everyone calls the SomeSingleton class statically, you can't replace your class by SomeSingletonMockup. Furthermore, even for hardware services, the Singleton pattern does not really prevent concurrent accesses. If you start the same program in two different JVMs, unless they somehow shared the state of their "Singletons" (through lock files for example), the Singleton pattern will not prevent concurrent access. Our application uses RXTX, and we routinely encounter cases where another (native) application has already locked the port. Since we cannot modify the native application to recognize lock files, OS-level control is irreplaceable. > > Consequences > The Parametric Singleton Design Pattern has several benefits: > > 1. Controlled access to parametrically defined instances. Since > the Parametric Singleton class encapsulates its instances, there is > control over how and when clients access it. Not really. Once you've returned the instance to a client, you've lost control over it. The client can to whatever it wants with it. You cannot "recall" the instance or claim it back. > 2. Reduced name space. The Parametric Singleton pattern avoids > global variables that store instances created from the same parameter. Sure, but you don't have to rely on a Singleton for that. Just create a single Factory. > I would very much like to get your feedback on this new design > pattern idea. Well, it's nothing new. Some may say that it is the point of design patterns: formalizes the designs that occur again and again. However, this design is simply a combination of the Singleton and Factory patterns. I did use it in the past, but now I've been exposed to the shortcomings of the Singleton pattern, so I limit myself to Factories. Regards, David From sean_montgomery at baseview.com Wed Mar 22 08:35:28 2006 From: sean_montgomery at baseview.com (Sean Montgomery) Date: Wed, 22 Mar 2006 10:35:28 -0500 Subject: [Rxtx] sole of a new design pattern In-Reply-To: <442160DA.80107@trusted-logic.com> References: <442160DA.80107@trusted-logic.com> Message-ID: <05769CA7-A51B-4CF0-BAA0-E02DD905F5A4@baseview.com> On Mar 22, 2006, at 9:36 AM, David Garnier wrote: > Furthermore, even for hardware services, the Singleton pattern does > not really prevent concurrent > accesses. If you start the same program in two different JVMs, > unless they somehow shared the state > of their "Singletons" (through lock files for example), the > Singleton pattern will not prevent > concurrent access. > Multiple class loaders in a single JVM can be tricky, too. Then there's synchronization, lazy initialization and serialization of singletons to contend with. Bloch's Effective Java covers these, and here's a few articles: http://www.javaworld.com/javaworld/jw-04-2003/jw-0425-designpatterns- p3.html http://java.sun.com/developer/technicalArticles/Programming/singletons/ Just FYI :-) From lyon at docjava.com Wed Mar 22 08:50:48 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Wed, 22 Mar 2006 10:50:48 -0500 Subject: [Rxtx] sole of a new design pattern In-Reply-To: <442160DA.80107@trusted-logic.com> References: <442160DA.80107@trusted-logic.com> Message-ID: Hi All, First, I would like to thank David for his prompt and thoughtful remarks. I had no idea people that feel strongly about a design patterns! Wow! Feedback (particularly critical feedback) is greatly appreciated. Starting at the end, first: >I did use it in >the past, but now I've been exposed to the shortcomings of the >Singleton pattern, so I limit myself to Factories. David, if I understood your comments correctly, you suggested that Factories can be used in leu of the Singleton Design Pattern, or even the Parametric Singleton Design Pattern. As I see in [Gof]: Factory Method: Intent "Define an interface for creating an object, but let subclasses decide which class to instantiate. Factory Method lets a class defer instantiation to subclasses." The Singleton Design Pattern is a concrete class, which is rather different, right? Also, subclasses are not permitted with Singleton, as they are final. Naturally, I could use an abstract factory as a parent for a singleton. I could even design a facade that could be implemented with the singleton....but that is not the intention of the design. Unless you want a mock-up, as discussed, below: More below: >Hello, > >> The Parametric Singleton Design Pattern > >The Singleton is the most abused design pattern ever. Good use-cases >for this pattern are extremely >rare and mostly confined to problems related to hardware resources, >like serial ports. > > >> Applicability >> >> Use the Parametric Singleton Design Pattern when: >> 1. There must be exactly one instance of a class with the given >> parameters. >OK. As I said above, this case this actually very unusual. The >Singleton pattern is mostly used when : >> 2. The instances must be accessible to clients from a well-known >> access point. > >Using the singleton pattern in this case is just convenient for the >programmer. Problems arises >pretty quickly, especially if you attempt to unit-test your classes. > >1) If your singleton is stateful, or hold on to stateful objects, it >means that two different unit >tests are not actually independent. Instead of starting with a brand >new environment, the result of >a test may be affected by the result of a previous test. This >problem also arise when with your >class relies on a database. In both cases, the solution is to reset >your "unique" resource >(Singleton or database) at the beginning of the test, which is a >pain. Also, while most projects >connect to a single database, projects that allow the use of >Singletons usually contain several of >thems, and new ones may cropped up unnoticed. You quickly end up >with test cases that only pass in a >certain order, which is a royal pain. There are basic problems with communicating finite state machines that include reachability and deadlock analysis. These are addressed with petri net analysis and are beyond the scope of the design pattern. As you quite rightly pointed out; the parametric singleton pattern (or the singleton pattern, for that matter) enable multiple threads to gain access to the same instance. The only way that I can see to block others from gaining access to the reference is the synchronize keyword. This is putting a spin-lock (or MUTEX) on the reference. The question of how to unit-test a design pattern like the parametric singleton remains open. Perhaps this is a deficiency. > >2) You cannot mockup a singleton. Once everyone calls the >SomeSingleton class statically, you can't >replace your class by SomeSingletonMockup. Acutally, I am not sure that this is true. If the Singleton implements a Facade interface, it should be possible to make the replacement. Right? > >Furthermore, even for hardware services, the Singleton pattern does >not really prevent concurrent >accesses. If you start the same program in two different JVMs, >unless they somehow shared the state >of their "Singletons" (through lock files for example), the >Singleton pattern will not prevent >concurrent access. Good Point!! You have sharp eyes! The singleton design pattern should/could take responsibility for this. In fact, you may notice that my code does have an implementation (LocateRegistry) that can work across JVM's. The LocateRegistry will even work across the Internet! LocateRegistry takes both a host name and a Port (lock files just don't do this). I did not think to implement this beyond the local machine, but, in its present form, it will work across different processes. > >Our application uses RXTX, and we routinely encounter cases where >another (native) application has >already locked the port. Since we cannot modify the native >application to recognize lock files, >OS-level control is irreplaceable. The singleton design pattern is not meant to replace OS-level control, but to centralize the Java programmers access to it. If lock files, for example, are used for serial ports, the Singleton Design Pattern should be able to work with them. > > >> >> Consequences >> The Parametric Singleton Design Pattern has several benefits: >> > > 1. Controlled access to parametrically defined instances. Since >> the Parametric Singleton class encapsulates its instances, there is >> control over how and when clients access it. > >Not really. Once you've returned the instance to a client, you've >lost control over it. The client >can to whatever it wants with it. You cannot "recall" the instance >or claim it back. Good point, this should read: > 1. Controll when parametrically defined instances are created. Since > > the Parametric Singleton class encapsulates its instances, there is > > control over how and when they are instanced. > >> 2. Reduced name space. The Parametric Singleton pattern avoids >> global variables that store instances created from the same parameter. > >Sure, but you don't have to rely on a Singleton for that. Just >create a single Factory. > > Thank you for your thoughtful and prompt response! Regards, - Doug From dmarkman at mac.com Wed Mar 22 21:21:55 2006 From: dmarkman at mac.com (Dmitry Markman) Date: Wed, 22 Mar 2006 23:21:55 -0500 Subject: [Rxtx] sole of a new design pattern In-Reply-To: <442160DA.80107@trusted-logic.com> References: <442160DA.80107@trusted-logic.com> Message-ID: I don't think I get it On Mar 22, 2006, at 9:36 AM, David Garnier wrote: > Using the singleton pattern in this case is just convenient for the > programmer. Problems arises > pretty quickly, especially if you attempt to unit-test your classes. so you're saying that something isn't so good because you can not test it in the convenient way? if that's true, I'm totally disagree change your test, debug whatever, but if software is efficient at runtime, works fine and only problem is some unit test (which is some kind of framework for testing) then dump that unit test , dump that unit framework and make something appropriate to the software you're testing so if Douglas want to use singletons, what's the problem? and what do you mean by abusing of singleton usage? of course singleton doesn't prevent concurrent access to the resource across the processes unless you're using some OS facility to prevent it, besides singleton as it was introduced is relevant only and only inside of the same process otherwise it's not singleton it's something else (let's say network singleton: so you have remote invocation facility and some factory method that return object created by that facility) I don't have any problem with using any kind of singletons. Parametric Singleton idea (if I understand it right) could be easily implemented in the following way: use a map populate map with instances of some class and key is your parameter (you can use lazy population too) if somebody ask the key check the value if it's null so resource is taken if somebody returns the resource put it back to the map public synchronized static Object getSomeResource(Object parameter); public synchronized static void returnResource(Object parameter); getSomeResource (inside of the same process) could return null in 2 cases 1. if somebody (from other thread for example) already took that resource 2. if OS API said that resource corresponded to that parameter (serial port with parameter = 1 (port #)) is locked and unavailable; I'm not sure that in case of serial ports we even need those Parametric Singletons (unless lock checking is a very expensive operation) just ask the OS about availability of that resource and if it's available give it away and then OS will lock it and therefore in next time somebody ask it just answer that resource is locked and return null for example system has 2 serial ports available so I ask getResource("tty"); or I ask getResource("Bluetooth-Modem"); and if OS is ok you can give tty or Bluetooth-Modem or both no need for any additional pattern I think back to the problem mac os x doesn't recognize locking via files, so it handles locking via some API an instance of the singleton in each process should recognize that resource is locked (by using that API) that's all we don't have to make things more complicate then they are just because there is some nice design pattern or nice unit test framework or whatever keep things simple, make them work fast, don't introduce middle layers unless you have really good reason to do so of course I could be entirely wrong, so sorry about that in advance thanks Dmitry Markman From tjarvi at qbang.org Wed Mar 22 22:31:41 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 22 Mar 2006 22:31:41 -0700 (MST) Subject: [Rxtx] sole of a new design pattern In-Reply-To: References: Message-ID: Hi Doug Interesting reading. So far I'm just reading and thinking. I have one question so far. " Clients obtain a reference to a Parametric Singleton instance only through the parametric singleton design pattern. If the instance is left in an improper state (e.g., the serial port was left open) it is NOT the role of the Parametric Singleton Design Pattern to close the IO port. Nor is it the role of the Parametric Singleton Design Pattern to open the port. That role is delegate to some other part of the system. " So when the clients obtain a reference to the singleton, can they assume the port is there? IE, would it be the singletons role to handle things like USB dongles being removed with event hints comming from the underlying OS. Hardware abstraction layer/HAL on Linux is an example of underlying OS events. I assume that role too is delegated to other parts of the system? -- Trent Jarvi tjarvi at qbang.org From lyon at docjava.com Thu Mar 23 08:10:33 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Thu, 23 Mar 2006 10:10:33 -0500 Subject: [Rxtx] Classes don't need goals, they need roles! In-Reply-To: References: Message-ID: Hi Trent, Yes, I think that the role of the Parametric Singleton Pattern is not to open or close serial ports, nor is it to perform error checking. On the other hand, if you were to combine the role of the Parametric Singleton Pattern with another role (like that of error checking) it might not be amiss. However, I generally caution programmers against adding multiple roles to classes, as this leads to monolithic designs. Thus a different class (NativeLibDetect) could have the role of determining if the native library can be loaded. Another class (SerialPortBean) can have the role of serializing the default state of the serial port, so that it can be recovered, from user preferences, at a later time. The SerialPortDetect could have the role of determining if the serial port is removed (i.e., a USB port was unplugged). My guess is that each class should have a different role in the system, in order to ease maintenance and testing...but I could be wrong about that. Thanks! - Doug >Hi Doug > >Interesting reading. So far I'm just reading and thinking. I have >one question so far. > >" > Clients obtain a reference to a Parametric Singleton instance only >through the parametric singleton design pattern. If the instance is >left in an improper state (e.g., the serial port was left open) it is >NOT the role of the Parametric Singleton Design Pattern to close the >IO port. Nor is it the role of the Parametric Singleton Design Pattern >to >open the port. That role is delegate to some other part of the system. >" > >So when the clients obtain a reference to the singleton, can they >assume the port is there? IE, would it be the singletons role to >handle things like USB dongles being removed with event hints >comming from the underlying OS. Hardware abstraction layer/HAL on >Linux is an example of underlying OS events. > >I assume that role too is delegated to other parts of the system? > >-- >Trent Jarvi >tjarvi at qbang.org >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From maximulo at yahoo.com Fri Mar 24 01:22:38 2006 From: maximulo at yahoo.com (Maximulo Majir) Date: Fri, 24 Mar 2006 00:22:38 -0800 (PST) Subject: [Rxtx] JavaPOS Message-ID: <20060324082238.66371.qmail@web38214.mail.mud.yahoo.com> Hi all! Hello Trent! From what i understand, RXTX or JavaComm APIs were not created solely for JavaPOS. In JavaPOS, we have the virtual method claim() which is separate from open(), but in our RXTX API, claiming is done every call to open(), we cant open the port if its claimed by another application. Would it be alright to suggest or ask to create a new method called claim(..)? Is there such thing as forceclaim() in RXTX? this could be the same as portownership transfer or its equivalent. ForceClaim is in JSR80. Do you have some samples using RXTX as the lower layer for the Device Service Objects in JavaPOS? I have tried it, i just want to compare. Thank you all! maxim __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060324/496adba2/attachment-0046.html From tjarvi at qbang.org Fri Mar 24 11:28:19 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 24 Mar 2006 11:28:19 -0700 (MST) Subject: [Rxtx] Re: RXTX 2.1 Solaris Problems In-Reply-To: <3691.1143210578@www045.gmx.net> References: <3691.1143210578@www045.gmx.net> Message-ID: On Fri, 24 Mar 2006, Andreas Guenther wrote: > Hi all, > > the solaris problem was not the lock file only. > > Ok, I had to create the directory /var/spool/locks myself. > /var/spool/uucp exists. > > But rxtx didn't find any port. > > I compiled the source with my own debug-informations > and I tried to isolate the problem. > > The problem is the testRead-call in SerialImp.c > > JNIEXPORT jboolean JNICALL RXTXCommDriver(testRead)( > > ... > if ( READ( fd, &c, 1 ) < 0 ) > { > if ( errno != EAGAIN ) { > report( "testRead() read failed\n" ); > ret = JNI_FALSE; > } > } > Thanks Andreas I'm packing up to move. I'll be more or less away for a couple weeks here. I'll be checking email but my workstation is going into a box soon. This isn't hard to fix as this port should be enumerated when EWOULDBLOCK is recieved. Thats error is OK for enumeration just as EAGAIN is. I've put the bug into bugzilla so we dont forget to get to it. http://bugzilla.qbang.org/show_bug.cgi?id=42 You can add yourself to the CC list if you wish to test fixes we provide or even put a patch into bugzilla yourself. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Fri Mar 24 11:51:52 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 24 Mar 2006 11:51:52 -0700 (MST) Subject: [Rxtx] JavaPOS In-Reply-To: <20060324082238.66371.qmail@web38214.mail.mud.yahoo.com> References: <20060324082238.66371.qmail@web38214.mail.mud.yahoo.com> Message-ID: On Fri, 24 Mar 2006, Maximulo Majir wrote: > Hi all! Hello Trent! > > > From what i understand, RXTX or JavaComm APIs were not > created solely for JavaPOS. In JavaPOS, we have the virtual method > claim() which is separate from open(), but in our RXTX API, claiming is > done every call to open(), we cant open the port if its claimed by > another application. Would it be alright to suggest or ask to create a > new method called claim(..)? Is there such thing as forceclaim() in > RXTX? this could be the same as portownership transfer or its > equivalent. ForceClaim is in JSR80. > Do you have some samples using RXTX as the lower layer for the Device > Service Objects in JavaPOS? I have tried it, i just want to compare. > maxim Hi Maxim JSR80 is the USB API IBM/Sun put together. The problem is they have a richer kernel/API underneath that can handle such things. With Serial Ports, there isnt anything there other than an ioctl that says don't let anyone touch this and lockfiles that are more of a 'lets be nice.' At times we may be using USB ports but it is through the termios layer with the limitations mentioned. The advantage is that not only USB will work with rxtx. Anything that has a termios layer should work (to the extent that termios layer is complete). I don't know how forceclaim() would help you. Lets say someone has a programmer working on /dev/ttyS0 and you take it. Now you both race each other to read data first. There isn't a mechanism I know of that will solve this problem in termios. The most obvious test being a native app and a Java app trying to take the port. There is the potential of requestion ownership from other Java Applications but the use for that is very rare. Did you have something more specific in mind that I'm missing? I'm not sure that claim() and forceclaim() would help you with rxtx other than maybe locking the port with claim() without opening it. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sat Mar 25 23:42:08 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 25 Mar 2006 23:42:08 -0700 (MST) Subject: [Rxtx] Serial snoop Message-ID: I was reading the Linux kernel mail-list tonight and ran past a thread that mentioned sersnoop. This looks like a handy tool for people dealing with new toys. "a simple command-line tool for linux that echoes bytes to and from any two serial ports, ptys, or network sockets, and prints all traffic to stdout, in hex and ascii." http://www.restivo.org/projects/sersnoop/ It works on Linux only at this time (debian package available). -- Trent Jarvi tjarvi at qbang.org From beat.arnet at gmail.com Sun Mar 26 07:32:35 2006 From: beat.arnet at gmail.com (Beat Arnet) Date: Sun, 26 Mar 2006 09:32:35 -0500 Subject: [Rxtx] Error 0x5 at /home/bob/foo/tar/rxtx-2.1-7/build/../src/termios.c(860): Access is, denied. Message-ID: <4426A603.80508@gmail.com> Dear all, When trying to open the serial port, I sometimes (not always) run into the following exception (when opening the serialPort): Error 0x5 at /home/bob/foo/tar/rxtx-2.1-7/build/../src/termios.c(860): Access is denied. java.lang.UnsatisfiedLinkError: native_psmisc_report_owner at gnu.io.CommPortIdentifier.native_psmisc_report_owner(Native Method) at gnu.io.CommPortIdentifier.open(CommPortIdentifier.java:354) at codeskin.tools.CLLoader.open(CLLoader.java:79) at codeskin.tools.C2000Programmer.run(C2000Programmer.java:220) at java.lang.Thread.run(Unknown Source) Is this the type of error where I should just try to open the port again, or can it be avoided? Regards, Beat From tjarvi at qbang.org Sun Mar 26 11:40:12 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 26 Mar 2006 11:40:12 -0700 (MST) Subject: [Rxtx] Error 0x5 at /home/bob/foo/tar/rxtx-2.1-7/build/../src/termios.c(860): Access is, denied. In-Reply-To: <4426A603.80508@gmail.com> References: <4426A603.80508@gmail.com> Message-ID: On Sun, 26 Mar 2006, Beat Arnet wrote: > Dear all, > > When trying to open the serial port, I sometimes (not always) run into > the following exception (when opening the serialPort): > > Error 0x5 at /home/bob/foo/tar/rxtx-2.1-7/build/../src/termios.c(860): > Access is > denied. > > java.lang.UnsatisfiedLinkError: native_psmisc_report_owner > at gnu.io.CommPortIdentifier.native_psmisc_report_owner(Native > Method) > at gnu.io.CommPortIdentifier.open(CommPortIdentifier.java:354) > at codeskin.tools.CLLoader.open(CLLoader.java:79) > at codeskin.tools.C2000Programmer.run(C2000Programmer.java:220) > at java.lang.Thread.run(Unknown Source) > > Is this the type of error where I should just try to open the port again, > or can it be avoided? > Hi Beat We did a second build of rxtx 2.1-7 to resolve that unsatisfied link error. It should work now. rxtx is trying to tell you it thinks someone else has the serial port open. You can try to open the port again but maybe you already have a copy of the program running when it happens? ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7r2.zip fixed build. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sun Mar 26 11:44:23 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 26 Mar 2006 11:44:23 -0700 (MST) Subject: [Rxtx] RXTX spec file (fwd) Message-ID: This is probably interesting for fedora/suse users. ---------- Forwarded message ---------- Date: Sun, 26 Mar 2006 16:25:45 +0200 To: taj at www.linux.org.uk Subject: RXTX spec file I send you this spec file which allows to create a RPM for Fedora 4, 5 (x86, x86_64) with Java Sun. -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: rxtx.spec Url: http://mailman.qbang.org/pipermail/rxtx/attachments/20060326/6c7b6af6/rxtx-0042.pl From tjarvi at qbang.org Sun Mar 26 23:42:59 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 26 Mar 2006 23:42:59 -0700 (MST) Subject: [Rxtx] Upcomming events. Message-ID: This Wednesday we will be announcing a new "Maintainer" for the rxtx project. The position is more like neutral leader. I wont be going away or doing less. This is just the right thing to do as it turns out the two people with CVS write access will be at the same company. We need a third and we need neutrality. The maintainer will have final say in any conflict and will try to be neutral. It will be open for discussion. Then we will do it :) I'll still do most of the footwork I do now. But. I'm falling behind. I should have gone through the mail-list and posted the next round of changes this weekend. I'm packing to move and its going so so - 13 years of toys collected. I suspect there will be a dead period on my part (a couple weeks) comming up. But if you get it on the mail-list, we will get it in if there are no objections. I may well not be reading the mail-list during this period as I look for a house and many other things. I hope everyone will help out. Thanks -- Trent Jarvi tjarvi at qbang.org From mahmoud_hadad at yahoo.com Sun Mar 26 07:31:19 2006 From: mahmoud_hadad at yahoo.com (ronan nick) Date: Sun, 26 Mar 2006 06:31:19 -0800 (PST) Subject: [Rxtx] a question about the COMM API Message-ID: <20060326143119.54919.qmail@web60014.mail.yahoo.com> hi, i was intrested in knowing how i can communicate with my internal modem using java? for example if i want to make a phone dialer application or a caller id application where should i be looking at? and as i understood the COMM API is for devices that is attached to the computer through serial ports. --------------------------------- New Yahoo! Messenger with Voice. Call regular phones from your PC and save big. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060326/ce8329f0/attachment-0044.html From dmarkman at mac.com Mon Mar 20 00:20:43 2006 From: dmarkman at mac.com (Dmitry Markman) Date: Mon, 20 Mar 2006 02:20:43 -0500 Subject: [Rxtx] Mac OS X RXTX java installer In-Reply-To: References: <07D0DE29-BA32-4CFE-B036-66BC6423D385@buechse.de> <441AE3E0.2030503@willicon.de> <12531986.1142622114996.JavaMail.dmarkman@mac.com> <441B2674.9010409@willicon.de> <13577405.1142634732776.JavaMail.dmarkman@mac.com> <441B4182.8010407@willicon.de> <92CD0D6C-5BE8-426E-A46D-99452059FF49@mac.com> <441BBB2D.8030305@willicon.de> <441C4088.5090905@willicon.de> Message-ID: <64BC1E23-FDDE-4CE6-8863-CFC881CBC224@mac.com> Hi all I put RXTX installer that will install everything (and will create / var/lock if necessary and add user to the uucp group) for mac os x from Java into the rxtx's CVS repository it could be easily modified to install files for any platform it uses Greg Guerin's AuthKit for authentication and authorization Greg released that kit under artistic license, so Trent, please take a look we, probably, can negotiate license with Greg if it's necessary Greg's AuthKit could be downloaded from http://www.amug.org/~glguerin/ sw/#authkit Michael Hall (mikehall at spacestar dot net) had a suggestion to make implementation of the jaas LoginModule based on Greg's AuthKit (his modification of the Greg's AuthKit could be found at http:// www.spacestar.net/users/mikehall/authkit.dmg) but Michael's AuthKitLoginModule does only half a job: it does authenticate but it can not run any external unix process in privileged mode (at least I wasn't able to do so) possible explanation could be found in conversation between Greg and Michael at Apple's java-dev list (look for archives) so I didn't use jaas API for rxtxinstaller I created folder MacOSX in the contrib folder comment 1. if you want to run that installer as standalone application all you need that RXTXInstaller.jar 2. if you want to use webstart you have to add Greg's libAuthKit.jnilib to the mac os x's resources in theory RXTXInstaller.jar doesn't need it, but there is a problem with loading libAuthKit.jnilib from webstart authkit uses loadLibrary method to load library and it failed (from webstart) for standalone application I extract libAuthKit.jnilib from the RXTXInstaller.jar and put it into the /Library/Java/Extensions or ~/Library/Java/Extensions folder that file will be deleted after installer quit unfortunately I didn't have time to put documentation there but it is mostly self-explanatory I took installer code from my gl4java installer that I did about 3 years ago (with small modifications) it would be very nice if Apple will release LoginModule that really will do the job (com.apple.security.auth.module package????? ) (UnixLoginModule is pretty useless) From lyon at docjava.com Mon Mar 20 06:34:39 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Mon, 20 Mar 2006 08:34:39 -0500 Subject: [Rxtx] Mac OS X RXTX java installer In-Reply-To: <64BC1E23-FDDE-4CE6-8863-CFC881CBC224@mac.com> References: <07D0DE29-BA32-4CFE-B036-66BC6423D385@buechse.de> <441AE3E0.2030503@willicon.de> <12531986.1142622114996.JavaMail.dmarkman@mac.com> <441B2674.9010409@willicon.de> <13577405.1142634732776.JavaMail.dmarkman@mac.com> <441B4182.8010407@willicon.de> <92CD0D6C-5BE8-426E-A46D-99452059FF49@mac.com> <441BBB2D.8030305@willicon.de> <441C4088.5090905@willicon.de> <64BC1E23-FDDE-4CE6-8863-CFC881CBC224@mac.com> Message-ID: Hi Dimitry, This sounds like great work. Just a couple of questions; After the check out of the CVS files, using: setenv CVSROOT :pserver:anonymous at cvs.milestonesolutions.com:/usr/local/cvsroot 53 8:28 setenv PASSWORD mousy 54 8:29 cvs login 55 8:29 cvs checkout rxtx-devel I cd'd over to: rxtx-devel/MACOSX_IDE And found: CVS/ CW/ ForPackageMaker/ PB/ Where is the installer? Thanks! - Doug From tjarvi at qbang.org Mon Mar 20 06:39:37 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 20 Mar 2006 06:39:37 -0700 (MST) Subject: [Rxtx] Mac OS X RXTX java installer In-Reply-To: References: <07D0DE29-BA32-4CFE-B036-66BC6423D385@buechse.de> <441AE3E0.2030503@willicon.de> <12531986.1142622114996.JavaMail.dmarkman@mac.com> <441B2674.9010409@willicon.de> <13577405.1142634732776.JavaMail.dmarkman@mac.com> <441B4182.8010407@willicon.de> <92CD0D6C-5BE8-426E-A46D-99452059FF49@mac.com> <441BBB2D.8030305@willicon.de> <441C4088.5090905@willicon.de> <64BC1E23-FDDE-4CE6-8863-CFC881CBC224@mac.com> Message-ID: On Mon, 20 Mar 2006, Dr. Douglas Lyon wrote: > Hi Dimitry, > This sounds like great work. Just a couple of questions; > After the check out of the CVS files, using: > setenv CVSROOT > :pserver:anonymous at cvs.milestonesolutions.com:/usr/local/cvsroot > 53 8:28 setenv PASSWORD mousy > 54 8:29 cvs login > 55 8:29 cvs checkout rxtx-devel Hi Doug You want "cvs checkout -r commapi-0-0-1 rxtx-devel" to get RXTX 2.1 The default branch is rxtx 2.0 which isn't very active right now. -- Trent Jarvi tjarvi at qbang.org From lyon at docjava.com Mon Mar 20 07:05:44 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Mon, 20 Mar 2006 09:05:44 -0500 Subject: [Rxtx] Mac OS X RXTX java installer In-Reply-To: References: <07D0DE29-BA32-4CFE-B036-66BC6423D385@buechse.de> <441AE3E0.2030503@willicon.de> <12531986.1142622114996.JavaMail.dmarkman@mac.com> <441B2674.9010409@willicon.de> <13577405.1142634732776.JavaMail.dmarkman@mac.com> <441B4182.8010407@willicon.de> <92CD0D6C-5BE8-426E-A46D-99452059FF49@mac.com> <441BBB2D.8030305@willicon.de> <441C4088.5090905@willicon.de> <64BC1E23-FDDE-4CE6-8863-CFC881CBC224@mac.com> Message-ID: Hi Trent, Thanks for the info on the CVS checkout procedure. I did that and am still not sure where the installer is. Here is what I have: cd MACOSX_IDE/ p4.docjava.com{lyon}121: ls CVS/ ForPackageMaker/ PB/ p4.docjava.com{lyon}122: find . | more . ./ForPackageMaker ./ForPackageMaker/RXTX.pkg.sit.hqx ./ForPackageMaker/Resources ./ForPackageMaker/Resources/ReadMe.rtf ./ForPackageMaker/Resources/Welcome.rtf ./ForPackageMaker/Resources/CVS ./ForPackageMaker/Resources/CVS/Entries ./ForPackageMaker/Resources/CVS/Repository ./ForPackageMaker/Resources/CVS/Tag ./ForPackageMaker/Resources/CVS/Root ./ForPackageMaker/Resources/preinstall ./ForPackageMaker/Resources/License.rtf ./ForPackageMaker/Resources/preupgrade ./ForPackageMaker/RXTX.pmsp ./ForPackageMaker/CVS ./ForPackageMaker/CVS/Entries ./ForPackageMaker/CVS/Repository ./ForPackageMaker/CVS/Entries.Log ./ForPackageMaker/CVS/Tag ./ForPackageMaker/CVS/Root ./ForPackageMaker/RXTX_Tiger.pkg.sitx.hqx ./ForPackageMaker/RXTX_Jag.pkg.sit.hqx ./ForPackageMaker/Install ./ForPackageMaker/Install/CVS ./ForPackageMaker/Install/CVS/Entries ./ForPackageMaker/Install/CVS/Repository ./ForPackageMaker/Install/CVS/Tag ./ForPackageMaker/Install/CVS/Root ./ForPackageMaker/Install/Library ./ForPackageMaker/Install/Library/CVS ./ForPackageMaker/Install/Library/CVS/Entries ./ForPackageMaker/Install/Library/CVS/Repository ./ForPackageMaker/Install/Library/CVS/Tag ./ForPackageMaker/Install/Library/CVS/Root ./ForPackageMaker/Install/Library/Java ./ForPackageMaker/Install/Library/Java/Extensions ./ForPackageMaker/Install/Library/Java/Extensions/RXTXcomm.jar ./ForPackageMaker/Install/Library/Java/Extensions/CVS ./ForPackageMaker/Install/Library/Java/Extensions/CVS/Entries ./ForPackageMaker/Install/Library/Java/Extensions/CVS/Repository ./ForPackageMaker/Install/Library/Java/Extensions/CVS/Tag ./ForPackageMaker/Install/Library/Java/Extensions/CVS/Root ./ForPackageMaker/Install/Library/Java/Extensions/librxtxSerial.jnilib ./ForPackageMaker/Install/Library/Java/CVS ./ForPackageMaker/Install/Library/Java/CVS/Entries ./ForPackageMaker/Install/Library/Java/CVS/Repository ./ForPackageMaker/Install/Library/Java/CVS/Entries.Log ./ForPackageMaker/Install/Library/Java/CVS/Tag ./ForPackageMaker/Install/Library/Java/CVS/Root ./ForPackageMaker/RXTX_Tiger.pmproj.sitx.hqx ./CVS ./CVS/Entries ./CVS/Repository ./CVS/Entries.Log ./CVS/Tag ./CVS/Root ./PB ./PB/LibSerialUniversal.xcodeproj.sitx.hqx ./PB/CVS ./PB/CVS/Entries ./PB/CVS/Repository ./PB/CVS/Entries.Log ./PB/CVS/Tag ./PB/CVS/Root ./PB/LibSerial.pbproj.sit.hqx ./PB/startpoint.c ./PB/config.h What is the procedure to run this installer? Do we need a README in: /rxtx-devel/MACOSX_IDE Here is what we have: CVS/ ForPackageMaker/ PB/ Thanks! - DL >On Mon, 20 Mar 2006, Dr. Douglas Lyon wrote: > >>Hi Dimitry, >>This sounds like great work. Just a couple of questions; >>After the check out of the CVS files, using: >>setenv CVSROOT >>:pserver:anonymous at cvs.milestonesolutions.com:/usr/local/cvsroot >> 53 8:28 setenv PASSWORD mousy >> 54 8:29 cvs login >> 55 8:29 cvs checkout rxtx-devel > >Hi Doug > >You want "cvs checkout -r commapi-0-0-1 rxtx-devel" to get RXTX 2.1 >The default branch is rxtx 2.0 which isn't very active right now. > >-- >Trent Jarvi >tjarvi at qbang.org From tjarvi at qbang.org Mon Mar 20 07:25:30 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 20 Mar 2006 07:25:30 -0700 (MST) Subject: [Rxtx] Mac OS X RXTX java installer In-Reply-To: References: <07D0DE29-BA32-4CFE-B036-66BC6423D385@buechse.de> <441AE3E0.2030503@willicon.de> <12531986.1142622114996.JavaMail.dmarkman@mac.com> <441B2674.9010409@willicon.de> <13577405.1142634732776.JavaMail.dmarkman@mac.com> <441B4182.8010407@willicon.de> <92CD0D6C-5BE8-426E-A46D-99452059FF49@mac.com> <441BBB2D.8030305@willicon.de> <441C4088.5090905@willicon.de> <64BC1E23-FDDE-4CE6-8863-CFC881CBC224@mac.com> Message-ID: On Mon, 20 Mar 2006, Dr. Douglas Lyon wrote: > Hi Trent, > Thanks for the info on the CVS checkout procedure. > I did that and am still not sure where the installer is. Hi Doug It does look like it was not cvs committed. There is no rxtx-devel/contrib/MacOSX directory in there at the moment. It was mentioned that it was put under contrib. -- Trent Jarvi tjarvi at qbang.org From dmarkman at mac.com Mon Mar 20 07:29:56 2006 From: dmarkman at mac.com (Dmitry Markman) Date: Mon, 20 Mar 2006 09:29:56 -0500 Subject: [Rxtx] Mac OS X RXTX java installer In-Reply-To: References: <07D0DE29-BA32-4CFE-B036-66BC6423D385@buechse.de> <441AE3E0.2030503@willicon.de> <12531986.1142622114996.JavaMail.dmarkman@mac.com> <441B2674.9010409@willicon.de> <13577405.1142634732776.JavaMail.dmarkman@mac.com> <441B4182.8010407@willicon.de> <92CD0D6C-5BE8-426E-A46D-99452059FF49@mac.com> <441BBB2D.8030305@willicon.de> <441C4088.5090905@willicon.de> <64BC1E23-FDDE-4CE6-8863-CFC881CBC224@mac.com> Message-ID: <6054EB4E-F7E0-4A9C-BDDA-D582D6D8826F@mac.com> you can find it in the rxtx-devel/contrib folder On Mar 20, 2006, at 9:05 AM, Dr. Douglas Lyon wrote: > Hi Trent, > Thanks for the info on the CVS checkout procedure. > I did that and am still not sure where the installer is. > Here is what I have: > cd MACOSX_IDE/ > p4.docjava.com{lyon}121: ls > CVS/ ForPackageMaker/ PB/ > p4.docjava.com{lyon}122: find . | more > . > ./ForPackageMaker > ./ForPackageMaker/RXTX.pkg.sit.hqx > ./ForPackageMaker/Resources > ./ForPackageMaker/Resources/ReadMe.rtf > ./ForPackageMaker/Resources/Welcome.rtf > ./ForPackageMaker/Resources/CVS > ./ForPackageMaker/Resources/CVS/Entries > ./ForPackageMaker/Resources/CVS/Repository > ./ForPackageMaker/Resources/CVS/Tag > ./ForPackageMaker/Resources/CVS/Root > ./ForPackageMaker/Resources/preinstall > ./ForPackageMaker/Resources/License.rtf > ./ForPackageMaker/Resources/preupgrade > ./ForPackageMaker/RXTX.pmsp > ./ForPackageMaker/CVS > ./ForPackageMaker/CVS/Entries > ./ForPackageMaker/CVS/Repository > ./ForPackageMaker/CVS/Entries.Log > ./ForPackageMaker/CVS/Tag > ./ForPackageMaker/CVS/Root > ./ForPackageMaker/RXTX_Tiger.pkg.sitx.hqx > ./ForPackageMaker/RXTX_Jag.pkg.sit.hqx > ./ForPackageMaker/Install > ./ForPackageMaker/Install/CVS > ./ForPackageMaker/Install/CVS/Entries > ./ForPackageMaker/Install/CVS/Repository > ./ForPackageMaker/Install/CVS/Tag > ./ForPackageMaker/Install/CVS/Root > ./ForPackageMaker/Install/Library > ./ForPackageMaker/Install/Library/CVS > ./ForPackageMaker/Install/Library/CVS/Entries > ./ForPackageMaker/Install/Library/CVS/Repository > ./ForPackageMaker/Install/Library/CVS/Tag > ./ForPackageMaker/Install/Library/CVS/Root > ./ForPackageMaker/Install/Library/Java > ./ForPackageMaker/Install/Library/Java/Extensions > ./ForPackageMaker/Install/Library/Java/Extensions/RXTXcomm.jar > ./ForPackageMaker/Install/Library/Java/Extensions/CVS > ./ForPackageMaker/Install/Library/Java/Extensions/CVS/Entries > ./ForPackageMaker/Install/Library/Java/Extensions/CVS/Repository > ./ForPackageMaker/Install/Library/Java/Extensions/CVS/Tag > ./ForPackageMaker/Install/Library/Java/Extensions/CVS/Root > ./ForPackageMaker/Install/Library/Java/Extensions/librxtxSerial.jnilib > ./ForPackageMaker/Install/Library/Java/CVS > ./ForPackageMaker/Install/Library/Java/CVS/Entries > ./ForPackageMaker/Install/Library/Java/CVS/Repository > ./ForPackageMaker/Install/Library/Java/CVS/Entries.Log > ./ForPackageMaker/Install/Library/Java/CVS/Tag > ./ForPackageMaker/Install/Library/Java/CVS/Root > ./ForPackageMaker/RXTX_Tiger.pmproj.sitx.hqx > ./CVS > ./CVS/Entries > ./CVS/Repository > ./CVS/Entries.Log > ./CVS/Tag > ./CVS/Root > ./PB > ./PB/LibSerialUniversal.xcodeproj.sitx.hqx > ./PB/CVS > ./PB/CVS/Entries > ./PB/CVS/Repository > ./PB/CVS/Entries.Log > ./PB/CVS/Tag > ./PB/CVS/Root > ./PB/LibSerial.pbproj.sit.hqx > ./PB/startpoint.c > ./PB/config.h > > What is the procedure to run this installer? > Do we need a README in: > /rxtx-devel/MACOSX_IDE > Here is what we have: > CVS/ ForPackageMaker/ PB/ > > > Thanks! > - DL > >> On Mon, 20 Mar 2006, Dr. Douglas Lyon wrote: >> >>> Hi Dimitry, >>> This sounds like great work. Just a couple of questions; >>> After the check out of the CVS files, using: >>> setenv CVSROOT :pserver:anonymous at cvs.milestonesolutions.com:/usr/ >>> local/cvsroot >>> 53 8:28 setenv PASSWORD mousy >>> 54 8:29 cvs login >>> 55 8:29 cvs checkout rxtx-devel >> >> Hi Doug >> >> You want "cvs checkout -r commapi-0-0-1 rxtx-devel" to get RXTX 2.1 >> The default branch is rxtx 2.0 which isn't very active right now. >> >> -- >> Trent Jarvi >> tjarvi at qbang.org > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx Dmitry Markman From mikehall at spacestar.net Mon Mar 20 05:25:25 2006 From: mikehall at spacestar.net (Michael Hall) Date: Mon, 20 Mar 2006 06:25:25 -0600 Subject: [Rxtx] Re: Mac OS X RXTX java installer In-Reply-To: <64BC1E23-FDDE-4CE6-8863-CFC881CBC224@mac.com> References: <07D0DE29-BA32-4CFE-B036-66BC6423D385@buechse.de> <441AE3E0.2030503@willicon.de> <12531986.1142622114996.JavaMail.dmarkman@mac.com> <441B2674.9010409@willicon.de> <13577405.1142634732776.JavaMail.dmarkman@mac.com> <441B4182.8010407@willicon.de> <92CD0D6C-5BE8-426E-A46D-99452059FF49@mac.com> <441BBB2D.8030305@willicon.de> <441C4088.5090905@willicon.de> <64BC1E23-FDDE-4CE6-8863-CFC881CBC224@mac.com> Message-ID: <247EB61F-5CD1-4132-89A2-FC105B6CF9A5@spacestar.net> On Mar 20, 2006, at 1:20 AM, Dmitry Markman wrote: > > Michael Hall (mikehall at spacestar dot net) had a suggestion to > make implementation of the jaas LoginModule > based on Greg's AuthKit > (his modification of the Greg's AuthKit could be found at http:// > www.spacestar.net/users/mikehall/authkit.dmg) > but Michael's AuthKitLoginModule does only half a job: > it does authenticate > but it can not run any external unix process in privileged mode (at > least I wasn't able to do so) If you got it working directly with Greg's the point is moot. But to clarify it anyhow. The login module does not allow you to do anything anything privileged on return as was explained by Greg. You need to work with a separate privileged process using the execPrivileged method of his API. I assume you did something similar although I haven't looked at how you are using it yet. I allowed instead for a action to be performed at the same time you login/authenticate,this... System.setProperty("authkit.action","/usr/bin/id"); just before this... lc.login(); To clarify, safely ignored as you are already complete. Mike Hall mikehall at spacestar dot net http://www.spacestar.net/users/mikehall http://sourceforge.net/projects/macnative -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2427 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20060320/f6e18202/smime-0047.bin From dmarkman at mac.com Mon Mar 20 07:36:47 2006 From: dmarkman at mac.com (Dmitry Markman) Date: Mon, 20 Mar 2006 09:36:47 -0500 Subject: [Rxtx] Re: Mac OS X RXTX java installer In-Reply-To: <247EB61F-5CD1-4132-89A2-FC105B6CF9A5@spacestar.net> References: <07D0DE29-BA32-4CFE-B036-66BC6423D385@buechse.de> <441AE3E0.2030503@willicon.de> <12531986.1142622114996.JavaMail.dmarkman@mac.com> <441B2674.9010409@willicon.de> <13577405.1142634732776.JavaMail.dmarkman@mac.com> <441B4182.8010407@willicon.de> <92CD0D6C-5BE8-426E-A46D-99452059FF49@mac.com> <441BBB2D.8030305@willicon.de> <441C4088.5090905@willicon.de> <64BC1E23-FDDE-4CE6-8863-CFC881CBC224@mac.com> <247EB61F-5CD1-4132-89A2-FC105B6CF9A5@spacestar.net> Message-ID: Hi, Michael all I have to do is to run some shell script I tried to use your action mechanism and it worked great so I just System.setProperty ("authkit.action","" ) and after that I even don't need to run anything like subject.doAs.... but after few thoughts I choose to use plain Greg's approach, because in that case I don't have to deal with various java's configurations files and therefore to use 2-3 -D parameters in the java command line especially it's useful for java web start (it's so fragile :-( ) thanks for the great job On Mar 20, 2006, at 7:25 AM, Michael Hall wrote: > > On Mar 20, 2006, at 1:20 AM, Dmitry Markman wrote: >> >> Michael Hall (mikehall at spacestar dot net) had a suggestion to >> make implementation of the jaas LoginModule >> based on Greg's AuthKit >> (his modification of the Greg's AuthKit could be found at http:// >> www.spacestar.net/users/mikehall/authkit.dmg) >> but Michael's AuthKitLoginModule does only half a job: >> it does authenticate >> but it can not run any external unix process in privileged mode >> (at least I wasn't able to do so) > > If you got it working directly with Greg's the point is moot. > > But to clarify it anyhow. > The login module does not allow you to do anything anything > privileged on return as was explained by Greg. You need to work > with a separate privileged process using the execPrivileged method > of his API. I assume you did something similar although I haven't > looked at how you are using it yet. > I allowed instead for a action to be performed at the same time you > login/authenticate,this... > System.setProperty("authkit.action","/usr/bin/id"); > just before this... > lc.login(); > To clarify, safely ignored as you are already complete. > > Mike Hall mikehall at spacestar dot net > http://www.spacestar.net/users/mikehall > http://sourceforge.net/projects/macnative > > > Dmitry Markman From dmarkman at mac.com Mon Mar 20 07:44:45 2006 From: dmarkman at mac.com (Dmitry Markman) Date: Mon, 20 Mar 2006 09:44:45 -0500 Subject: [Rxtx] Mac OS X RXTX java installer In-Reply-To: References: <07D0DE29-BA32-4CFE-B036-66BC6423D385@buechse.de> <441AE3E0.2030503@willicon.de> <12531986.1142622114996.JavaMail.dmarkman@mac.com> <441B2674.9010409@willicon.de> <13577405.1142634732776.JavaMail.dmarkman@mac.com> <441B4182.8010407@willicon.de> <92CD0D6C-5BE8-426E-A46D-99452059FF49@mac.com> <441BBB2D.8030305@willicon.de> <441C4088.5090905@willicon.de> <64BC1E23-FDDE-4CE6-8863-CFC881CBC224@mac.com> Message-ID: it's in the commapi-0-0-1 branch I tested it right now: cvs co -r commapi-0-0-1 rxtx-devel and I got everything On Mar 20, 2006, at 9:25 AM, Trent Jarvi wrote: > On Mon, 20 Mar 2006, Dr. Douglas Lyon wrote: > >> Hi Trent, >> Thanks for the info on the CVS checkout procedure. >> I did that and am still not sure where the installer is. > > Hi Doug > > It does look like it was not cvs committed. There is no rxtx-devel/ > contrib/MacOSX directory in there at the moment. It was mentioned > that it was put under contrib. > > -- > Trent Jarvi > tjarvi at qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx Dmitry Markman From tjarvi at qbang.org Mon Mar 20 07:52:57 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 20 Mar 2006 07:52:57 -0700 (MST) Subject: [Rxtx] Mac OS X RXTX java installer In-Reply-To: References: <07D0DE29-BA32-4CFE-B036-66BC6423D385@buechse.de> <441AE3E0.2030503@willicon.de> <12531986.1142622114996.JavaMail.dmarkman@mac.com> <441B2674.9010409@willicon.de> <13577405.1142634732776.JavaMail.dmarkman@mac.com> <441B4182.8010407@willicon.de> <92CD0D6C-5BE8-426E-A46D-99452059FF49@mac.com> <441BBB2D.8030305@willicon.de> <441C4088.5090905@willicon.de> <64BC1E23-FDDE-4CE6-8863-CFC881CBC224@mac.com> Message-ID: On Mon, 20 Mar 2006, Dmitry Markman wrote: > it's in the commapi-0-0-1 branch > > I tested it right now: > cvs co -r commapi-0-0-1 rxtx-devel > > and I got everything > A fresh checkout worked. Here is a copy of the tree (just the installer bits) ftp://ftp.qbang.org/pub/rxtx/MacOSX-installer.zip -- Trent Jarvi tjarvi at qbang.org From lyon at docjava.com Mon Mar 20 08:08:26 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Mon, 20 Mar 2006 10:08:26 -0500 Subject: [Rxtx] Mac OS X RXTX java installer In-Reply-To: References: <07D0DE29-BA32-4CFE-B036-66BC6423D385@buechse.de> <441AE3E0.2030503@willicon.de> <12531986.1142622114996.JavaMail.dmarkman@mac.com> <441B2674.9010409@willicon.de> <13577405.1142634732776.JavaMail.dmarkman@mac.com> <441B4182.8010407@willicon.de> <92CD0D6C-5BE8-426E-A46D-99452059FF49@mac.com> <441BBB2D.8030305@willicon.de> <441C4088.5090905@willicon.de> <64BC1E23-FDDE-4CE6-8863-CFC881CBC224@mac.com> Message-ID: Hi All, Is the Auth package able to work properly on non Mac OS's? It was not clear from the doc or download. Thanks! - Doug From dmarkman at mac.com Mon Mar 20 08:15:22 2006 From: dmarkman at mac.com (Dmitry Markman) Date: Mon, 20 Mar 2006 10:15:22 -0500 Subject: [Rxtx] Mac OS X RXTX java installer In-Reply-To: References: <07D0DE29-BA32-4CFE-B036-66BC6423D385@buechse.de> <441AE3E0.2030503@willicon.de> <12531986.1142622114996.JavaMail.dmarkman@mac.com> <441B2674.9010409@willicon.de> <13577405.1142634732776.JavaMail.dmarkman@mac.com> <441B4182.8010407@willicon.de> <92CD0D6C-5BE8-426E-A46D-99452059FF49@mac.com> <441BBB2D.8030305@willicon.de> <441C4088.5090905@willicon.de> <64BC1E23-FDDE-4CE6-8863-CFC881CBC224@mac.com> Message-ID: <217312D8-CCCA-4859-ABA6-32DF1CC817B9@mac.com> thanks Trent, for putting it on ftp server On Mar 20, 2006, at 9:52 AM, Trent Jarvi wrote: > A fresh checkout worked. Here is a copy of the tree (just the > installer bits) > > ftp://ftp.qbang.org/pub/rxtx/MacOSX-installer.zip > Dmitry Markman From dmarkman at mac.com Mon Mar 20 09:14:03 2006 From: dmarkman at mac.com (Dmitry Markman) Date: Mon, 20 Mar 2006 11:14:03 -0500 Subject: [Rxtx] Mac OS X RXTX java installer In-Reply-To: References: <07D0DE29-BA32-4CFE-B036-66BC6423D385@buechse.de> <441AE3E0.2030503@willicon.de> <12531986.1142622114996.JavaMail.dmarkman@mac.com> <441B2674.9010409@willicon.de> <13577405.1142634732776.JavaMail.dmarkman@mac.com> <441B4182.8010407@willicon.de> <92CD0D6C-5BE8-426E-A46D-99452059FF49@mac.com> <441BBB2D.8030305@willicon.de> <441C4088.5090905@willicon.de> <64BC1E23-FDDE-4CE6-8863-CFC881CBC224@mac.com> Message-ID: <4DEBA6F0-DA45-4E84-823E-1F1AC48BDCCC@mac.com> no it will work only on mac os x however it's harmless to run it on other platform if you want to use it for other platform you have to do the following (I'll do it for linux) 1. modify RXTXInstaller class method public static RXTXInstaller getInstance() public static RXTXInstaller getInstance() { String osName = System.getProperty("os.name").toLowerCase(); if(osName.startsWith("mac")){ return new gnu.io.installer.macosx.MACOSXRXTXInstaller(); } else if(osName.startsWith("windows")){ return new gnu.io.installer.windows.WindowsRXTXInstaller(); }else if(osName.startsWith("linux")){ return new gnu.io.installer.linux.LinuxRXTXInstaller(); } return null; } 2. create folder gnu/io/installer/linux/ 3. create class Linux386RXTXInstaller package gnu.io.installer.linux; import java.io.File; public class Linux386RXTXInstaller extends gnu.io.installer.RXTXInstaller{ public Linux386RXTXInstaller(){ createJarFolder(); createLibFolder(); addJarResource("RXTXcomm.jar","/gnu/io/installer/resources/ linux/jar/RXTXcomm.dat"); addLibResource("librxtxSerial.so","/gnu/io/installer/ resources/linux/lib/librxtxSerial.so"); } protected void createJarFolder(){ String javaHome = System.getProperty("java.home"); char separator = File.separatorChar; jarFolder = new File(javaHome+separator+"lib"+separator+"ext"); } protected void createLibFolder(){ String javaHome = System.getProperty("java.home"); char separator = File.separatorChar; libFolder = new File(javaHome+separator+"bin"); } public void runPreProcess() {} //put here some action you need public void runPostProcess() {} //put here some action you need } 4. create folder /gnu/io/installer/resources/linux/jar and put there linux's version of RXTXcomm.dat (which is renamed RXTXcomm.jar) 5. create folder /gnu/io/installer/resources/linux/lib and put there linux's version of librxtxSerial. so 6. make sure that RXTXInstaller.jar has the following items: /gnu/io/installer/resources/linux/jar/RXTXcomm.jar /gnu/io/installer/resources/linux/lib/librxtxSerial.so 7. modify file installer.pref: jar file RXTXInstaller.jar must have the following item /gnu/io/installer/installer.pref that's basically it for windows you have to do the similar things: just replace linux to windows and librxtxSerial.so to rxtxSerial.dll and create appropriate gnu.io.installer.windows.WindowsRXTXInstaller class package gnu.io.installer.windows; import java.io.File; public class WindowsRXTXInstaller extends gnu.io.installer.RXTXInstaller{ public WindowsRXTXInstaller(){ createJarFolder(); createLibFolder(); addJarResource("RXTXcomm.jar","/gnu/io/installer/resources/ windows/jar/RXTXcomm.dat"); addLibResource("librxtxSerial.so","/gnu/io/installer/ resources/windows/lib/rxtxSerial.dll"); } protected void createJarFolder(){ String javaHome = System.getProperty("java.home"); char separator = File.separatorChar; jarFolder = new File(javaHome+separator+"lib"+separator+"ext"); } protected void createLibFolder(){ String javaHome = System.getProperty("java.home"); char separator = File.separatorChar; libFolder = new File(javaHome+separator+"bin"); } public void runPreProcess() {} //put here some action you need public void runPostProcess() {} //put here some action you need } installer.pref will look like On Mar 20, 2006, at 10:08 AM, Dr. Douglas Lyon wrote: > Hi All, > Is the Auth package able to work properly on > non Mac OS's? > It was not clear from the doc or download. > > Thanks! > - Doug > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx Dmitry Markman From joachim at buechse.de Mon Mar 20 10:49:06 2006 From: joachim at buechse.de (Joachim Buechse) Date: Mon, 20 Mar 2006 18:49:06 +0100 Subject: [Rxtx] BUG: Lock file stays even if port opening fails Message-ID: This was only tested on MacOSX but looking at the code, it should be true for all systems that use lock_uucp. I am opening a port which can not be opened (dialup port of a telephone paired via bluetooth but currently not reachable). The lock file is created and stays arround, even though the port open failed. After looking a bit through the code (of 2.17), I really wonder if it wouldn't be a good idea to make the "locking" an explicit operation called from the java code. This would certainly simplify the generation of meaningfull exceptions (and java based debugging). Maybe even the handling of "preopened" ports should be in the Java part of the lib (again for java based debugging puposes). That beeing said, I have no idea if this would be possible for the 2.07 implementation. Regards, Joachim From tjarvi at qbang.org Mon Mar 20 11:24:22 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 20 Mar 2006 11:24:22 -0700 (MST) Subject: [Rxtx] BUG: Lock file stays even if port opening fails In-Reply-To: References: Message-ID: On Mon, 20 Mar 2006, Joachim Buechse wrote: > This was only tested on MacOSX but looking at the code, it should be true > for all systems that use lock_uucp. > > I am opening a port which can not be opened (dialup port of a telephone > paired via bluetooth but currently not reachable). The lock file is > created and stays arround, even though the port open failed. > > > After looking a bit through the code (of 2.17), I really wonder if it > wouldn't be a good idea to make the "locking" an explicit operation > called from the java code. This would certainly simplify the generation > of meaningfull exceptions (and java based debugging). > Maybe even the handling of "preopened" ports should be in the Java part > of the lib (again for java based debugging puposes). That beeing said, I > have no idea if this would be possible for the 2.07 implementation. > > Regards, Hi Joachim It should be possible in the 2.0-7 implementation too. The calls to RXTXPort.java would not change. We would just do more there Moving more of that logic into Java would be better as many people don't like to look at C code. There is a liblockdev on most Linux distros that can do most of the C code and would be easier to use. The problem is embeded devices will not have that library. The preopened port code has not been really tested. That was a last minute request in a product cycle. I expect it will be tested this year though. As I recall, some devices really do not like CD raising on open. The preopened ports then allow people to mess around in java without power cycling the devices or losing data. -- Trent Jarvi tjarvi at qbang.org From joachim at buechse.de Mon Mar 20 12:01:08 2006 From: joachim at buechse.de (Joachim Buechse) Date: Mon, 20 Mar 2006 20:01:08 +0100 Subject: [Rxtx] BUG: Lock file stays even if port opening fails In-Reply-To: References: Message-ID: Hi Trent, What is your general feeling about moving code to Java? The last days I have been reading quite a bit of the code and there are several things, that might not work as expected. I'll give you two examples from is_device_locked: if LOCKDIR == /var/spool/locks the directory /var/spool/lock will not be checked. LOCKDIR is not checked for lockfiles with unexpected pefixes While these things have probably never been discovered in production, they are still possibly incorrect implementations. If it was Java code, I would write some unit tests producing the errors that could later be corrected. PS: One could imagine to actually implement the whole lockfile handling in Java using some native routines to get the values required (pid, st_dev, st_rdev, ...). On 20.03.2006, at 19:24, Trent Jarvi wrote: > On Mon, 20 Mar 2006, Joachim Buechse wrote: > >> This was only tested on MacOSX but looking at the code, it should >> be true for all systems that use lock_uucp. >> >> I am opening a port which can not be opened (dialup port of a >> telephone paired via bluetooth but currently not reachable). The >> lock file is created and stays arround, even though the port open >> failed. >> >> >> After looking a bit through the code (of 2.17), I really wonder if >> it wouldn't be a good idea to make the "locking" an explicit >> operation called from the java code. This would certainly simplify >> the generation of meaningfull exceptions (and java based debugging). >> Maybe even the handling of "preopened" ports should be in the Java >> part of the lib (again for java based debugging puposes). That >> beeing said, I have no idea if this would be possible for the 2.07 >> implementation. >> >> Regards, > > Hi Joachim > > It should be possible in the 2.0-7 implementation too. The calls > to RXTXPort.java would not change. We would just do more there > Moving more of that logic into Java would be better as many people > don't like to look at C code. There is a liblockdev on most Linux > distros that can do most of the C code and would be easier to use. > The problem is embeded devices will not have that library. > > The preopened port code has not been really tested. That was a > last minute request in a product cycle. I expect it will be tested > this year though. As I recall, some devices really do not like CD > raising on open. The preopened ports then allow people to mess > around in java without power cycling the devices or losing data. > > -- > Trent Jarvi > tjarvi at qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Mon Mar 20 12:21:02 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 20 Mar 2006 12:21:02 -0700 (MST) Subject: [Rxtx] BUG: Lock file stays even if port opening fails In-Reply-To: References: Message-ID: On Mon, 20 Mar 2006, Joachim Buechse wrote: > Hi Trent, > > What is your general feeling about moving code to Java? The last days I > have been reading quite a bit of the code and there are several things, > that might not work as expected. > > I'll give you two examples from is_device_locked: > > if LOCKDIR == /var/spool/locks the directory /var/spool/lock will not be > checked. > LOCKDIR is not checked for lockfiles with unexpected pefixes > > While these things have probably never been discovered in production, > they are still possibly incorrect implementations. If it was Java code, I > would write some unit tests producing the errors that could later be > corrected. > > PS: One could imagine to actually implement the whole lockfile handling > in Java using some native routines to get the values required (pid, > st_dev, st_rdev, ...). Hi Joachim I like the idea of moving more of the code into java but there are some things to consider. If you break this into multiple JNI calls, the performance will drop considerably during enumeration of ports. We are looking for 256 ports per dev type vs (16? in Sun's 2.0 and fewer types). Its hard to make assumptions. I've seen virtual ports start at /dev/foo100 for instance. It works out to over 7500 ports on Linux if you enable them all. We already trim that back by default. See Linux-all-ports in RXTXCommDriver.java. There are also native libraries that rxtx can link to. If you move too much into Java, linking to 'standard' libraries with distros will break. "configure --enable-liblock=yes" will not be doable. This is probably a favorable way with RedHat, Debian, Suse and others. Thats the right thing to do if there will be rpms, dpkg, .. For those reasons, I think it still make sense to keep it to a minimal ~3 calls to JNI code that we can use for speed and versatility. lock() isLocked(), unlock() perhaps. When I say speed, its more about avoiding crossing the JNI layer multiple times than java vs C performance. With versatility I think liblock is the right way for most but not all (embeded) linux distros. -- Trent Jarvi tjarvi at qbang.org From joachim at buechse.de Mon Mar 20 12:42:04 2006 From: joachim at buechse.de (Joachim Buechse) Date: Mon, 20 Mar 2006 20:42:04 +0100 Subject: [Rxtx] BUG: Lock file stays even if port opening fails In-Reply-To: References: Message-ID: <82C19FE7-DDCB-45B6-B2C9-7606B66F0124@buechse.de> Ok, what about providing a default implementation in Java? The RXTXCommDriver would call a (native) function useNativeLocking and if it returns true, call the native functions for lock() isLocked (), unlock(), else is would use the Java based default implementation. This could possibly be overriden by a property (again for debugging). Joachim On 20.03.2006, at 20:21, Trent Jarvi wrote: > On Mon, 20 Mar 2006, Joachim Buechse wrote: > >> Hi Trent, >> >> What is your general feeling about moving code to Java? The last >> days I have been reading quite a bit of the code and there are >> several things, that might not work as expected. >> >> I'll give you two examples from is_device_locked: >> >> if LOCKDIR == /var/spool/locks the directory /var/spool/lock will >> not be checked. >> LOCKDIR is not checked for lockfiles with unexpected pefixes >> >> While these things have probably never been discovered in >> production, they are still possibly incorrect implementations. If >> it was Java code, I would write some unit tests producing the >> errors that could later be corrected. >> >> PS: One could imagine to actually implement the whole lockfile >> handling in Java using some native routines to get the values >> required (pid, st_dev, st_rdev, ...). > > Hi Joachim > > I like the idea of moving more of the code into java but there are > some things to consider. > > If you break this into multiple JNI calls, the performance will > drop considerably during enumeration of ports. We are looking for > 256 ports per dev type vs (16? in Sun's 2.0 and fewer types). Its > hard to make assumptions. I've seen virtual ports start at /dev/ > foo100 for instance. > > It works out to over 7500 ports on Linux if you enable them all. > We already trim that back by default. See Linux-all-ports in > RXTXCommDriver.java. > > There are also native libraries that rxtx can link to. If you move > too much into Java, linking to 'standard' libraries with distros > will break. "configure --enable-liblock=yes" will not be doable. > This is probably a favorable way with RedHat, Debian, Suse and > others. Thats the right thing to do if there will be rpms, dpkg, .. > > For those reasons, I think it still make sense to keep it to a > minimal ~3 calls to JNI code that we can use for speed and > versatility. lock() isLocked(), unlock() perhaps. When I say > speed, its more about avoiding crossing the JNI layer multiple > times than java vs C performance. With versatility I think liblock > is the right way for most but not all (embeded) linux distros. > > -- > Trent Jarvi > tjarvi at qbang.org > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Mon Mar 20 12:44:47 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 20 Mar 2006 12:44:47 -0700 (MST) Subject: [Rxtx] BUG: Lock file stays even if port opening fails In-Reply-To: <82C19FE7-DDCB-45B6-B2C9-7606B66F0124@buechse.de> References: <82C19FE7-DDCB-45B6-B2C9-7606B66F0124@buechse.de> Message-ID: On Mon, 20 Mar 2006, Joachim Buechse wrote: > Ok, what about providing a default implementation in Java? > > The RXTXCommDriver would call a (native) function useNativeLocking and if > it returns true, call the native functions for lock() isLocked(), > unlock(), else is would use the Java based default implementation. This > could possibly be overriden by a property (again for debugging). > Hi Joachim That would be OK with me. -- Trent Jarvi tjarvi at qbang.org From dmarkman at mac.com Mon Mar 20 22:27:45 2006 From: dmarkman at mac.com (Dmitry Markman) Date: Tue, 21 Mar 2006 00:27:45 -0500 Subject: [Rxtx] binaries request Message-ID: <42702213-C222-4937-A585-7CFB17E47608@mac.com> Hi can somebody send me latest linux and windows binaries, please? or where I can find them (I didn't find them in the latest tareball) I gave up with my cygwin: something wrong I have no idea what java doesn't understand /cygwin/c syntax after I changed makefile it did java part but after that gcc 3.4.4 started to complain I set buffer length to 999 lines but I didn't get beginning of the story something wrong with my 1.4.2_09/include/jni.h gcc doesn't like it anyway I gave up thanks in advance Dmitry Markman -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060320/f8cbc57c/attachment-0047.html From tjarvi at qbang.org Mon Mar 20 22:36:48 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 20 Mar 2006 22:36:48 -0700 (MST) Subject: [Rxtx] binaries request In-Reply-To: <42702213-C222-4937-A585-7CFB17E47608@mac.com> References: <42702213-C222-4937-A585-7CFB17E47608@mac.com> Message-ID: On Tue, 21 Mar 2006, Dmitry Markman wrote: > Hi > can somebody send me latest linux and windows binaries, please? > > or where I can find them (I didn't find them in the latest tareball) > > I gave up with my cygwin: something wrong I have no idea what > java doesn't understand /cygwin/c syntax > after I changed makefile it did java part > but after that gcc 3.4.4 started to complain > I set buffer length to 999 lines but I didn't get beginning of the story > something wrong with my 1.4.2_09/include/jni.h gcc doesn't like it > anyway I gave up > > thanks in advance > Hi Dmitry The bins are here: ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7-bins-r2.zip Here are the files in the zip you want. Jar: rxtx-2.1-7-bins-r2/RXTXcomm.jar Windows: rxtx-2.1-7-bins-r2/Windows/i368-mingw32/rxtxSerial.dll Linux (x86) rxtx-2.1-7-bins-r2/Linux/i686-unknown-linux-gnu/librxtxSerial.so There are others in there including Parallel port support but those are the main ones for testing. -- Trent Jarvi tjarvi at qbang.org From dmarkman at mac.com Mon Mar 20 23:05:59 2006 From: dmarkman at mac.com (Dmitry Markman) Date: Tue, 21 Mar 2006 01:05:59 -0500 Subject: [Rxtx] binaries request In-Reply-To: References: <42702213-C222-4937-A585-7CFB17E47608@mac.com> Message-ID: thank you very much but windows's readme says: rxtxSerial.dll had to be recomopiled to link in missing native methods. should I ignore it? or what? thanks again also I understand that I should use mingw not cygwin I'll try to install mingw On Mar 21, 2006, at 12:36 AM, Trent Jarvi wrote: > On Tue, 21 Mar 2006, Dmitry Markman wrote: > >> Hi >> can somebody send me latest linux and windows binaries, please? >> >> or where I can find them (I didn't find them in the latest tareball) >> >> I gave up with my cygwin: something wrong I have no idea what >> java doesn't understand /cygwin/c syntax >> after I changed makefile it did java part >> but after that gcc 3.4.4 started to complain >> I set buffer length to 999 lines but I didn't get beginning of the >> story >> something wrong with my 1.4.2_09/include/jni.h gcc doesn't like it >> anyway I gave up >> >> thanks in advance >> > > Hi Dmitry > > The bins are here: > > ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7-bins-r2.zip > > Here are the files in the zip you want. > > Jar: > > rxtx-2.1-7-bins-r2/RXTXcomm.jar > > Windows: > > rxtx-2.1-7-bins-r2/Windows/i368-mingw32/rxtxSerial.dll > > Linux (x86) > > rxtx-2.1-7-bins-r2/Linux/i686-unknown-linux-gnu/librxtxSerial.so > > There are others in there including Parallel port support but those > are the main ones for testing. > > -- > Trent Jarvi > tjarvi at qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx Dmitry Markman From tjarvi at qbang.org Mon Mar 20 23:20:33 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 20 Mar 2006 23:20:33 -0700 (MST) Subject: [Rxtx] binaries request In-Reply-To: References: <42702213-C222-4937-A585-7CFB17E47608@mac.com> Message-ID: On Tue, 21 Mar 2006, Dmitry Markman wrote: > thank you very much > > but windows's readme says: > rxtxSerial.dll had to be recomopiled to link in missing native methods. > > should I ignore it? or what? > Hi Dmitry That dll should be OK. r2 is the recompile linked to the missing native method. The readme explains why it was recompiled; fuser.o was not linked into the dll in the first release. -- Trent Jarvi tjarvi at qbang.org From ariantristan at yahoo.com Mon Mar 20 23:55:24 2006 From: ariantristan at yahoo.com (Lambok Sianturi) Date: Mon, 20 Mar 2006 22:55:24 -0800 (PST) Subject: [Rxtx] jvm issue Message-ID: <20060321065524.94779.qmail@web50701.mail.yahoo.com> Hi All, This is my first time to join RxTx mailing list. I thank you all for allowing others to sign in in requests help. I use the latest RxTx lib in Fedora 3 with java version 1.4.2_09 b05. And I got this error: # # An unexpected error has been detected by HotSpot Virtual Machine: # # SIGSEGV (0xb) at pc=0x00bf27f3, pid=2633, tid=3086112448 # # Java VM: Java HotSpot(TM) Client VM (1.4.2_09-b05 mixed mode) # Problematic frame: # C [ld-linux.so.2+0xa7f3] # # An error report file with more information is saved as hs_err_pid2633.log # # If you would like to submit a bug report, please visit: # http://java.sun.com/webapps/bugreport/crash.jsp # ./run.sh: line 3: 2633 Aborted /usr/local/java/bin/java -Djava.library.path=/usr/local/java/jre/lib/ -Djsmsengine.debug=true -classpath jsmsengine.jar:smsgateway.jar:classes12.jar:RXTXcomm.jar:. com.api.sms.SMSServer What is the jvm depedency for the latest library? Can I use 1.4.2_09 b05? Thanks in advance. Arian --------------------------------- Yahoo! Mail Use Photomail to share photos without annoying attachments. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060320/83d58dd7/attachment-0047.html From f.frumento at ngi.it Tue Mar 21 00:21:47 2006 From: f.frumento at ngi.it (Fabio Frumento) Date: Tue, 21 Mar 2006 08:21:47 +0100 Subject: [Rxtx] Javadoc on the go Message-ID: <441FA98B.9050701@ngi.it> Hi Trent, sorry for the big delay but my job is running wild, i was out for some time but now i'm back and ready to continue the javadoc for Rxtx. Did you used the last javadoc patch i sent you ? let me know if i have to send it to you again or not. regards Fabio From lyon at docjava.com Tue Mar 21 00:51:18 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Tue, 21 Mar 2006 02:51:18 -0500 Subject: [Rxtx] lock files Message-ID: Hi All, You know, if the use of lock files were under Java control (rather than a build-time decision), it might enable a more unified binary distro. It might also facilitate quick prototyping of non-lock file approaches to resolving serial port contention issues (i.e., mac-like approaches vs. linux approaches, etc.). I realize that this is a radical overhaul of the lock file policy issue. Also, it may harm performance. On the other hand, our benchmarks on JNI overhead for modern processors indicate performance impact should be minimal. Perhaps it is more of an issue with the toybox systems. Suppose there were a class with a reasonable default...someone might write: SerialPortLockPolicy.setPolicy(SerialPortLockPolicy.UNIX_LOCK_FILE); SerialPortLockPolicy.setPolicy(SerialPortLockPolicy.NO_LOCK_CHECKING); SerialPortLockPolicy.setPolicy(SerialPortLockPolicy.MAC_STYLE); Thus, we could have a run-time reconfiguration of the serial port lock policy. A special NO_LOCK version of the binary would no longer be required. Any thoughts on this? Thanks! - Doug From joachim at buechse.de Tue Mar 21 03:09:09 2006 From: joachim at buechse.de (Joachim Buechse) Date: Tue, 21 Mar 2006 11:09:09 +0100 Subject: [Rxtx] lock files In-Reply-To: References: Message-ID: <8E12916A-1B9A-4FF2-B684-E2D1C794221B@buechse.de> This is pretty much what I thought about when I suggested, that the default behaviour could be overwritten with a property. I am very much in favor of this approach. In particular this allows much easier debugging for PC based java developers. I think big parts of the Java (and maybe some parts of the C code) could use a bit of a structural workover (unit tests, javadoc, synchronization, etc). Maybe there should be a CVS branch for this experimental version. I'd be happy to contribute a first workover for some of the Java code. Designing for testability and implementing a good bunch of unit tests has been a strategy that worked quite well in the Java projects I lead. And it ultimately allows more liberal change permission. Regards, Joachim On 21.03.2006, at 08:51, Dr. Douglas Lyon wrote: > Hi All, > You know, if the use of lock files were > under Java control (rather than a build-time decision), > it might enable a more unified binary distro. It might also > facilitate quick prototyping of non-lock file approaches > to resolving serial port contention issues (i.e., mac-like > approaches vs. linux approaches, etc.). > > I realize that this is a radical overhaul of the lock file policy > issue. Also, it may harm performance. On the other hand, > our benchmarks on JNI overhead for modern processors indicate > performance impact should be minimal. Perhaps it is more of > an issue with the toybox systems. > > Suppose there were a class with a reasonable default...someone > might write: > SerialPortLockPolicy.setPolicy(SerialPortLockPolicy.UNIX_LOCK_FILE); > SerialPortLockPolicy.setPolicy(SerialPortLockPolicy.NO_LOCK_CHECKING); > SerialPortLockPolicy.setPolicy(SerialPortLockPolicy.MAC_STYLE); > > Thus, we could have a run-time reconfiguration of the serial port lock > policy. A special NO_LOCK version of the binary would no longer > be required. > > Any thoughts on this? > > Thanks! > - Doug > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From joachim at buechse.de Tue Mar 21 06:23:08 2006 From: joachim at buechse.de (Joachim Buechse) Date: Tue, 21 Mar 2006 14:23:08 +0100 Subject: [Rxtx] PATCH: use of ioctl(fd, TIOCEXCL) instead of lockfiles Message-ID: <923AE774-EEA2-4911-92D8-32BB27802C8B@buechse.de> Here is the patch for the ioctl(fd, TIOCEXCL). I have verified this only for OSX 10.4.5, hence it is only defined for APPLE. However, it should work at least for Solaris as well. If a process has requested TIOEXCL further open calls by other user processes will fail. The patch also disables uucp style locking for APPLE. Obviously this is discussable. I think it is the way to go, as it eliminates creating the lock directory which doesnt exist on the standard installation and it eliminates messing with the system group definitions (adding users to group uucp). Regarding the possibility of root processes opening a device which is locked - I consider this a feature not a potential problem. It is highly unlikely, that somebody is crazy enough to run a JavaVM as root (unless he has no other means of getting a restricted IP port opened, ie doesnt understand ipfw). Anyway, even if the process runs as root, it fails when calling ioctl(fd, TIOCEXCL). It could however still open the port to listen for RING events. I.e. a fax server which needs to see incoming calls but otherwise doesnt want to block the port. So the only case where the proposed mechanism fails is, if an incorrectly implemented process running as root conflicts with a user process. I think this can be accepted. Regards, Joachim PS: If this patch is generally accepted, the installer and Mac doku should obviously be changed as well. Index: SerialImp.c =================================================================== RCS file: /usr/local/cvsroot/rxtx-devel/src/SerialImp.c,v retrieving revision 1.46.2.187 diff -u -r1.46.2.187 SerialImp.c --- SerialImp.c 29 Jan 2006 22:19:04 -0000 1.46.2.187 +++ SerialImp.c 21 Mar 2006 12:59:16 -0000 @@ -656,6 +656,25 @@ fd=OPEN (filename, O_RDWR | O_NOCTTY | O_NONBLOCK ); } while (fd < 0 && errno==EINTR); +#ifdef OPEN_EXCL + // Note that open() follows POSIX semantics: multiple open() calls to + // the same file will succeed unless the TIOCEXCL ioctl is issued. + // This will prevent additional opens except by root-owned processes. + // See tty(4) ("man 4 tty") and ioctl(2) ("man 2 ioctl") for details. + + if (fd >= 0 && (ioctl(fd, TIOCEXCL) == -1)) + { + sprintf( message, "open: exclusive access denied for % s\n", + filename ); + report( message ); + report_error( message ); + + close(fd); + goto fail; + } +#endif /* OPEN_EXCL */ + + if( configure_port( fd ) ) goto fail; (*env)->ReleaseStringUTFChars( env, jstr, filename ); sprintf( message, "open: fd returned is %i\n", fd ); Index: SerialImp.h =================================================================== RCS file: /usr/local/cvsroot/rxtx-devel/src/SerialImp.h,v retrieving revision 1.11.2.49 diff -u -r1.11.2.49 SerialImp.h --- SerialImp.h 5 Jul 2005 17:47:21 -0000 1.11.2.49 +++ SerialImp.h 21 Mar 2006 12:59:17 -0000 @@ -135,7 +135,8 @@ /*# define LOCKDIR "/var/spool/uucp"*/ # define LOCKDIR "/var/lock" # define LOCKFILEPREFIX "LK." -# define UUCP +/*# define UUCP*/ +# define OPEN_EXCL #endif /* __APPLE__ */ #if defined(__NetBSD__) # define DEVICEDIR "/dev/" From tjarvi at qbang.org Tue Mar 21 10:26:08 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 21 Mar 2006 10:26:08 -0700 (MST) Subject: [Rxtx] Javadoc on the go In-Reply-To: <441FA98B.9050701@ngi.it> References: <441FA98B.9050701@ngi.it> Message-ID: On Tue, 21 Mar 2006, Fabio Frumento wrote: > Hi Trent, > > sorry for the big delay but my job is running wild, i was out for some > time but now i'm back and ready to continue the javadoc for Rxtx. > > Did you used the last javadoc patch i sent you ? let me know if i have to > send it to you again or not. > > regards > > Fabio Hi Fabio The patch is in the rxtx mail-list archives. It will be going in soon. I did not see a time critical portion. I'll probably be going through the list since the last batch of patches this weekend and putting them into CVS. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Tue Mar 21 10:57:18 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 21 Mar 2006 10:57:18 -0700 (MST) Subject: [Rxtx] jvm issue In-Reply-To: <20060321065524.94779.qmail@web50701.mail.yahoo.com> References: <20060321065524.94779.qmail@web50701.mail.yahoo.com> Message-ID: On Mon, 20 Mar 2006, Lambok Sianturi wrote: > Hi All, > This is my first time to join RxTx mailing list. I thank you all for allowing others to sign in in requests help. > I use the latest RxTx lib in Fedora 3 with java version 1.4.2_09 b05. And I got this error: > > # > # An unexpected error has been detected by HotSpot Virtual Machine: > # > # SIGSEGV (0xb) at pc=0x00bf27f3, pid=2633, tid=3086112448 > # > # Java VM: Java HotSpot(TM) Client VM (1.4.2_09-b05 mixed mode) > # Problematic frame: > # C [ld-linux.so.2+0xa7f3] A native library loading error? What happens if you recompile rxtx on your system and install that? This sounds like an ABI problem? rxtx 2.1-7 was compiled with a gcc 2.96 toolchain as I recall. The hope is newer system will be backwards compatible. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Tue Mar 21 11:05:29 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 21 Mar 2006 11:05:29 -0700 (MST) Subject: [Rxtx] PATCH: use of ioctl(fd, TIOCEXCL) instead of lockfiles In-Reply-To: <923AE774-EEA2-4911-92D8-32BB27802C8B@buechse.de> References: <923AE774-EEA2-4911-92D8-32BB27802C8B@buechse.de> Message-ID: On Tue, 21 Mar 2006, Joachim Buechse wrote: > Here is the patch for the ioctl(fd, TIOCEXCL). I have verified this only > for OSX 10.4.5, hence it is only defined for APPLE. However, it should > work at least for Solaris as well. > > If a process has requested TIOEXCL further open calls by other user > processes will fail. > > The patch also disables uucp style locking for APPLE. Obviously this is > discussable. I think it is the way to go, as it eliminates creating the > lock directory which doesnt exist on the standard installation and it > eliminates messing with the system group definitions (adding users to > group uucp). > > Regarding the possibility of root processes opening a device which is > locked - I consider this a feature not a potential problem. It is highly > unlikely, that somebody is crazy enough to run a JavaVM as root (unless > he has no other means of getting a restricted IP port opened, ie doesnt > understand ipfw). Anyway, even if the process runs as root, it fails when > calling ioctl(fd, TIOCEXCL). It could however still open the port to > listen for RING events. I.e. a fax server which needs to see incoming > calls but otherwise doesnt want to block the port. So the only case where > the proposed mechanism fails is, if an incorrectly implemented process > running as root conflicts with a user process. I think this can be > accepted. > > Regards, > Joachim > > PS: If this patch is generally accepted, the installer and Mac doku > should obviously be changed as well. > > > Index: SerialImp.c > =================================================================== > RCS file: /usr/local/cvsroot/rxtx-devel/src/SerialImp.c,v > retrieving revision 1.46.2.187 > diff -u -r1.46.2.187 SerialImp.c > --- SerialImp.c 29 Jan 2006 22:19:04 -0000 1.46.2.187 > +++ SerialImp.c 21 Mar 2006 12:59:16 -0000 > @@ -656,6 +656,25 @@ > fd=OPEN (filename, O_RDWR | O_NOCTTY | O_NONBLOCK ); > } while (fd < 0 && errno==EINTR); > > +#ifdef OPEN_EXCL > + // Note that open() follows POSIX semantics: multiple open() > calls to > + // the same file will succeed unless the TIOCEXCL ioctl is > issued. > + // This will prevent additional opens except by root-owned > processes. > + // See tty(4) ("man 4 tty") and ioctl(2) ("man 2 ioctl") for > details. > + > + if (fd >= 0 && (ioctl(fd, TIOCEXCL) == -1)) > + { > + sprintf( message, "open: exclusive access denied for % > s\n", > + filename ); > + report( message ); > + report_error( message ); > + > + close(fd); > + goto fail; > + } > +#endif /* OPEN_EXCL */ > + > + > if( configure_port( fd ) ) goto fail; > (*env)->ReleaseStringUTFChars( env, jstr, filename ); > sprintf( message, "open: fd returned is %i\n", fd ); > Index: SerialImp.h > =================================================================== > RCS file: /usr/local/cvsroot/rxtx-devel/src/SerialImp.h,v > retrieving revision 1.11.2.49 > diff -u -r1.11.2.49 SerialImp.h > --- SerialImp.h 5 Jul 2005 17:47:21 -0000 1.11.2.49 > +++ SerialImp.h 21 Mar 2006 12:59:17 -0000 > @@ -135,7 +135,8 @@ > /*# define LOCKDIR "/var/spool/uucp"*/ > # define LOCKDIR "/var/lock" > # define LOCKFILEPREFIX "LK." > -# define UUCP > +/*# define UUCP*/ > +# define OPEN_EXCL > #endif /* __APPLE__ */ > #if defined(__NetBSD__) > # define DEVICEDIR "/dev/" > This looks like a good start. What do you think Dmitry? Perhaps all systems with TIOCEXCL defined should use that though. Even if they use lockfiles. It wont hurt anything. That would catch people hacking their own serial apps without checking lockfiles. Its a good idea to avoid C++ style comments in the C portions. Some older systems don't deal with them well. If it's just for Mac OS X, it isn't a big deal. I think it was the Irix compiler that was problematic? -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Tue Mar 21 11:22:05 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 21 Mar 2006 11:22:05 -0700 (MST) Subject: [Rxtx] lock files In-Reply-To: <8E12916A-1B9A-4FF2-B684-E2D1C794221B@buechse.de> References: <8E12916A-1B9A-4FF2-B684-E2D1C794221B@buechse.de> Message-ID: We can try it. Maybe the JNI is much improved. The nice thing about linking into liblock is distros then worry about lockfiles on their systems. This way, we have to deal with any changes that may show up. On Tue, 21 Mar 2006, Joachim Buechse wrote: > This is pretty much what I thought about when I suggested, that the > default behaviour could be overwritten with a property. I am very much in > favor of this approach. In particular this allows much easier debugging > for PC based java developers. > > I think big parts of the Java (and maybe some parts of the C code) could > use a bit of a structural workover (unit tests, javadoc, synchronization, > etc). Maybe there should be a CVS branch for this experimental version. > I'd be happy to contribute a first workover for some of the Java code. > Designing for testability and implementing a good bunch of unit tests has > been a strategy that worked quite well in the Java projects I lead. And > it ultimately allows more liberal change permission. > > Regards, > Joachim > > > On 21.03.2006, at 08:51, Dr. Douglas Lyon wrote: > >> Hi All, >> You know, if the use of lock files were >> under Java control (rather than a build-time decision), >> it might enable a more unified binary distro. It might also >> facilitate quick prototyping of non-lock file approaches >> to resolving serial port contention issues (i.e., mac-like >> approaches vs. linux approaches, etc.). >> >> I realize that this is a radical overhaul of the lock file policy >> issue. Also, it may harm performance. On the other hand, >> our benchmarks on JNI overhead for modern processors indicate >> performance impact should be minimal. Perhaps it is more of >> an issue with the toybox systems. >> >> Suppose there were a class with a reasonable default...someone >> might write: >> SerialPortLockPolicy.setPolicy(SerialPortLockPolicy.UNIX_LOCK_FILE); >> SerialPortLockPolicy.setPolicy(SerialPortLockPolicy.NO_LOCK_CHECKING); >> SerialPortLockPolicy.setPolicy(SerialPortLockPolicy.MAC_STYLE); >> >> Thus, we could have a run-time reconfiguration of the serial port lock >> policy. A special NO_LOCK version of the binary would no longer >> be required. >> >> Any thoughts on this? >> >> Thanks! >> - Doug >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From dmarkman at mac.com Tue Mar 21 16:05:17 2006 From: dmarkman at mac.com (Dmitry Markman) Date: Tue, 21 Mar 2006 18:05:17 -0500 Subject: [Rxtx] PATCH: use of ioctl(fd, TIOCEXCL) instead of lockfiles In-Reply-To: References: <923AE774-EEA2-4911-92D8-32BB27802C8B@buechse.de> Message-ID: <512AC70C-BB86-48F2-A83C-023F35C23BAB@mac.com> I think it's cool, but I'd like to have that property implementation when user can choose between locking mechanism about comments: it's easy to change comments to the C style or we can use extensions of the file to cpp so c++ compiler will be used On Mar 21, 2006, at 1:05 PM, Trent Jarvi wrote: > This looks like a good start. What do you think Dmitry? Perhaps > all systems with TIOCEXCL defined should use that though. Even if > they use lockfiles. It wont hurt anything. That would catch > people hacking their own serial apps without checking lockfiles. > > Its a good idea to avoid C++ style comments in the C portions. > Some older systems don't deal with them well. If it's just for Mac > OS X, it isn't a big deal. I think it was the Irix compiler that > was problematic? Dmitry Markman From dmarkman at mac.com Tue Mar 21 16:13:00 2006 From: dmarkman at mac.com (Dmitry Markman) Date: Tue, 21 Mar 2006 18:13:00 -0500 Subject: [Rxtx] PATCH: use of ioctl(fd, TIOCEXCL) instead of lockfiles In-Reply-To: References: <923AE774-EEA2-4911-92D8-32BB27802C8B@buechse.de> Message-ID: I'd like to add that creating locking folder isn't a big deal we never had a problem related to the lock folders, because we always used installer on mac os x from other hand I'm not very much familiar with iotcl locking approach and I'm not sure it's more efficient Joachim wrote "I think it is the way to go, as it eliminates creating the lock directory which doesnt exist on the standard installation and it eliminates messing with the system group definitions (adding users to group uucp)." but I really didn't have any problem with that 1. doesn't exist on the standard installation there are many-many things that don't exist in the standard installation so I don't think that argument is strong enough 2. messing with the system group definitions I don't think we're messing with the group definition mac os x provides very clear way to set up group's members and together with Greg Guerin AuthKit there is no problem to set those definitions so I don't think that argument is strong either but from other hand using iotcl is more promising and is more elegant On Mar 21, 2006, at 1:05 PM, Trent Jarvi wrote: > > This looks like a good start. What do you think Dmitry? Perhaps > all systems with TIOCEXCL defined should use that though. Even if > they use lockfiles. It wont hurt anything. That would catch > people hacking their own serial apps without checking lockfiles. Dmitry Markman From joachim at buechse.de Wed Mar 22 04:46:45 2006 From: joachim at buechse.de (Joachim Buechse) Date: Wed, 22 Mar 2006 12:46:45 +0100 Subject: [Rxtx] PATCH: use of ioctl(fd, TIOCEXCL) instead of lockfiles In-Reply-To: References: <923AE774-EEA2-4911-92D8-32BB27802C8B@buechse.de> Message-ID: Sorry, I was not very clear with my arguments, so I will try again;-) Please, don't take this as an attack against work that has been done. I think the contributions that have been made in the past were made in a good spirit. But I really believe, that the current solution for OSX has many shortcomings and should be changed as soon as possible. lock files --- The /var/lock folder does not exist on the standard OSX installation, however the standard installation includes several applications that use serial ports (i.e. the FAX capability). This indicates, that the lock folder approach will not work well with system components. Applications for OSX will generally try to live in harmony with system components (except for HP print drivers of course). I think RXTX should follow this approach as well. uucp group --- Accessing serial ports is not an admin privileged operation on OSX. Any user (world) has read/write privileges on /dev/tty*. So the system default is to not enforce any group membership to access these ports. The group uucp however is a system group on all unix systems I know. It exists for certain system processes. A non admin user should in general not be a member of this group. Quite arguably no user should ever be a member of this group. Installer --- My general opinion is, that - no Installer should touch user or group data without warning - no Application Installer should touch groups which are not specific to the very application installed - no Installer should ever add regular users to a system group The current installer injects the installing user in the group uucp without warning about this change and without giving the option to "opt out" of this change. This is a potential security risk (but not currently a real one, as OSX contains no folders belonging to group uucp). The current installer does not work for multi user systems. It puts the installing user in the uucp group. However the installing user is not necessarily the user that will use the application. Putting all users that may use a serial port application in the system group uucp seems like a very invasive approach to me. Besides that, newly created users will not automatically be in the group and hence, serial applications will "break" for new users without obvious reasons. Avoiding the lock files will allow self contained applications (i.e. drag&drop installation). In my eyes this is largely preferable over an installer that requests admin privileges. Adding up all these points indicates very strongly, that the lock-file implementation is not the way to go on OSX. Regards, Joachim On 22.03.2006, at 00:13, Dmitry Markman wrote: > I'd like to add that > > creating locking folder isn't a big deal > we never had a problem related to the lock folders, because we > always used installer on mac os x > from other hand I'm not very much familiar with iotcl locking > approach and I'm not sure it's more efficient > > Joachim wrote "I think it is the way to go, as it eliminates > creating the lock directory which doesnt exist on the standard > installation and it eliminates messing with the system group > definitions (adding users to group uucp)." but I really didn't have > any problem with that > > 1. doesn't exist on the standard installation > there are many-many things that don't exist in the standard > installation so I don't think that argument is strong enough > 2. messing with the system group definitions > I don't think we're messing with the group definition > mac os x provides very clear way to set up group's members and > together with Greg Guerin AuthKit there is no problem to set those > definitions > so I don't think that argument is strong either > but from other hand using iotcl is more promising and is more elegant > > > > On Mar 21, 2006, at 1:05 PM, Trent Jarvi wrote: > >> >> This looks like a good start. What do you think Dmitry? Perhaps >> all systems with TIOCEXCL defined should use that though. Even if >> they use lockfiles. It wont hurt anything. That would catch >> people hacking their own serial apps without checking lockfiles. > > Dmitry Markman > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From dmarkman at mac.com Wed Mar 22 05:27:13 2006 From: dmarkman at mac.com (Dmitry Markman) Date: Wed, 22 Mar 2006 07:27:13 -0500 Subject: [Rxtx] PATCH: use of ioctl(fd, TIOCEXCL) instead of lockfiles In-Reply-To: References: <923AE774-EEA2-4911-92D8-32BB27802C8B@buechse.de> Message-ID: <83440CF3-DCD8-41C1-B941-F227232C27E3@mac.com> thanks for the very good explanation I didn't think that you were attacking any thing, so don't worry I just had feeling, that there were more aesthetic reasons for going to ioctl then real necessity now you explained everything quite well (BTW, asfar as I remember installer asks admin password so it wasn't quiet, but it really doesn't matter now) thanks On Mar 22, 2006, at 6:46 AM, Joachim Buechse wrote: > Sorry, I was not very clear with my arguments, so I will try again;-) > > Please, don't take this as an attack against work that has been > done. I think the contributions that have been made in the past > were made in a good spirit. But I really believe, that the current > solution for OSX has many shortcomings and should be changed as > soon as possible. > > lock files > --- > The /var/lock folder does not exist on the standard OSX > installation, however the standard installation includes several > applications that use serial ports (i.e. the FAX capability). This > indicates, that the lock folder approach will not work well with > system components. Applications for OSX will generally try to live > in harmony with system components (except for HP print drivers of > course). I think RXTX should follow this approach as well. > > uucp group > --- > Accessing serial ports is not an admin privileged operation on OSX. > Any user (world) has read/write privileges on /dev/tty*. So the > system default is to not enforce any group membership to access > these ports. The group uucp however is a system group on all unix > systems I know. It exists for certain system processes. A non admin > user should in general not be a member of this group. Quite > arguably no user should ever be a member of this group. > > Installer > --- > My general opinion is, that > - no Installer should touch user or group data without warning > - no Application Installer should touch groups which are not > specific to the very application installed > - no Installer should ever add regular users to a system group > > The current installer injects the installing user in the group uucp > without warning about this change and without giving the option to > "opt out" of this change. This is a potential security risk (but > not currently a real one, as OSX contains no folders belonging to > group uucp). > > The current installer does not work for multi user systems. It puts > the installing user in the uucp group. However the installing user > is not necessarily the user that will use the application. Putting > all users that may use a serial port application in the system > group uucp seems like a very invasive approach to me. Besides that, > newly created users will not automatically be in the group and > hence, serial applications will "break" for new users without > obvious reasons. > > > Avoiding the lock files will allow self contained applications > (i.e. drag&drop installation). In my eyes this is largely > preferable over an installer that requests admin privileges. Adding > up all these points indicates very strongly, that the lock-file > implementation is not the way to go on OSX. > > Regards, > Joachim > > > On 22.03.2006, at 00:13, Dmitry Markman wrote: > >> I'd like to add that >> >> creating locking folder isn't a big deal >> we never had a problem related to the lock folders, because we >> always used installer on mac os x >> from other hand I'm not very much familiar with iotcl locking >> approach and I'm not sure it's more efficient >> >> Joachim wrote "I think it is the way to go, as it eliminates >> creating the lock directory which doesnt exist on the standard >> installation and it eliminates messing with the system group >> definitions (adding users to group uucp)." but I really didn't >> have any problem with that >> >> 1. doesn't exist on the standard installation >> there are many-many things that don't exist in the standard >> installation so I don't think that argument is strong enough >> 2. messing with the system group definitions >> I don't think we're messing with the group definition >> mac os x provides very clear way to set up group's members and >> together with Greg Guerin AuthKit there is no problem to set those >> definitions >> so I don't think that argument is strong either >> but from other hand using iotcl is more promising and is more elegant >> >> >> >> On Mar 21, 2006, at 1:05 PM, Trent Jarvi wrote: >> >>> >>> This looks like a good start. What do you think Dmitry? Perhaps >>> all systems with TIOCEXCL defined should use that though. Even >>> if they use lockfiles. It wont hurt anything. That would catch >>> people hacking their own serial apps without checking lockfiles. >> >> Dmitry Markman >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx Dmitry Markman From lyon at docjava.com Wed Mar 22 06:12:18 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Wed, 22 Mar 2006 08:12:18 -0500 Subject: [Rxtx] sole of a new design pattern Message-ID: Hi All, I have been thinking about how we design the serial port software. I think we need a new design pattern. For lack of a better term, I shall call it: The Parametric Singleton Design Pattern By Douglas A. Lyon ABSTRACT The goal of the singleton design pattern is to make sure that there is one, and only one, instance of a given class. The goal of the parametric singleton design pattern is to make sure that there is one, and only one, instance of a given class with the given parametric values. We parametric singleton design pattern combines the singleton design pattern with a parameter that enables unique creation of instances of a class. These instances are cached. When a user asks for an instance with these parameters, the cache is checked. If the instance is in the cache, the instance is returned, otherwise it is created, added to the cache and then returned. We apply our parametric singleton design pattern to the retrieval of RMI registries bound to a given port. The goal of our system is to make sure that no two RMI registries are listening to the same socket and to make use of the RMI registries after they have been created. RMI registries are used in distributed computation. Introduction The singleton design pattern is meant to ensure that on a single instance of a class exists. It is also meant to provide a global point of access to it. The intent of the parametric singleton design pattern is to ensure that a class has only one instance for a given set of parameter values. It also provides a global point of access to it. Motivation A system cannot tolerate multiple instances of some classes with identical parameters. For example, you cannot have two instances making use of the same serial port, at the same time. You cannot have two instances that are trying to listen to the same socket connection. You cannot have two instances writing to the same file structure at the same time. As the operating system is often thought of as the arbiter of consumed resources (i.e., tape drives, serial ports, etc.) we frequently leave it to an operating system implementation to resolve these contention issues. Even for similar resources (like serial ports) there are few standards for handling contention. For example, serial ports on Linux are locked using a "/var/lock" file. POSIX, on the other hand, uses ioctl mechanisms to prevent contention. A better solution is to make a class that is responsible for keeping track of the instances created from the class. The class is declared final, so that it cannot be subclassed. The class also has a private constructor, so that other classes cannot instance it. The new design pattern is called the parametric singleton design pattern and it provides a way to access and create instances with given parameters. Applicability Use the Parametric Singleton Design Pattern when: 1. There must be exactly one instance of a class with the given parameters. 2. The instances must be accessible to clients from a well-known access point. Structure Insert UML diagram here. Participants The Parametric Singleton Clients that need instances 1. The Parametric Singleton defines an instance upon request from a client, if, and only if, the instance does not already exist. 2. The Parametric Singleton returns the instance to the client. 3. The Parametric Singleton is responsible for creating unique instances from given parameters. Collaborations Clients obtain a reference to a Parametric Singleton instance only through the parametric singleton design pattern. If the instance is left in an improper state (e.g., the serial port was left open) it is NOT the role of the Parametric Singleton Design Pattern to close the IO port. Nor is it the role of the Parametric Singleton Design Pattern to open the port. That role is delegate to some other part of the system. Further, it is not the role of the Parametric Singleton Design Pattern to check out resources. That is, multiple threads can have multiple references to the same resource at the same time. MUTEX locking is delegated to some other part of the system. Consequences The Parametric Singleton Design Pattern has several benefits: 1. Controlled access to parametrically defined instances. Since the Parametric Singleton class encapsulates its instances, there is control over how and when clients access it. 2. Reduced name space. The Parametric Singleton pattern avoids global variables that store instances created from the same parameter. Implementation Here are implementation issues to consider when using the Parametric Singleton pattern: 1. Unique mapping of parameters. The Parametric Singleton pattern requires that there be a mean to isomorphically map the parameter space into the instance space and back again. 2. Ensure unique instances. The Parametric Singleton pattern makes unique instances from parameters, and it does so only once. 3. Cache instances for fast retrieval. The Parametric Singleton pattern must be able to look up instances, given some set of parameters, and do so from some data structure. That is, there must be enough space to hold references to all the instances the program will need. Also, a mechanism is needed to look up and retrieve the instances quickly enough to satisfy the clients. Sample Code public final class ParametricSingletonRmiRegistry { private static Hashtable registry = new Hashtable(100); // use singleton pattern and??????????????????????????????????????????????? // prevent instantiation of RmiRegistryUtils.?????????????????????????????? private ParametricSingletonRmiRegistry() { } // the only instance of the Registry held by the RmiRegistryUtils?????????? public static void listNames(Integer port) { if (!isInCacheAndRunning(port)) return; Registry r = (Registry) registry.get(port); System.out.println("registry on port: " + port); System.out.println("registry: " + r); System.out.println("names: "); try { print(r.list()); } catch (RemoteException e) { In.message(e); } System.out.println("------------------------"); } /**???????????????????????????????????????????????????????????????????????? * Checks whether a Registry has been started on this host????????????????? * in the specified port.?????????????????????????????????????????????????? * If not, it tries to start one.?????????????????????????????????????????? * when it fails to start a Registry, it exits the program????????????????? * with exit code 1.??????????????????????????????????????????????????????? */ public static void restart(int port) { if (isInCacheAndRunning(port)) return; try { startRegistry(port); } catch (RemoteException e) { In.message(e); } } /**???????????????????????????????????????????????????????????????????????? * @param port????????????????????????????????????????????????????????????? * @return true if registry is in cache and running???????????????????????? */ private static boolean isInCacheAndRunning(Integer port) { if (!isRegistryRunning(port.intValue())) return false; if (!isRegistryInCache(port.intValue())) return false; return true; } /**???????????????????????????????????????????????????????????????????????? * @param port????????????????????????????????????????????????????????????? * @return true if we are able to locate a local registry on port.??????????????????????????????????????????????????????????????????????????? */ private static boolean isRegistryRunning(int port) { try { Registry r = LocateRegistry.getRegistry(port); if (r != null) return true; } catch (RemoteException e) { return false; } return false; } /**???????????????????????????????????????????????????????????????????????? * @param port????????????????????????????????????????????????????????????? * @return return true if registry is in cache????????????????????????????? */ private static boolean isRegistryInCache(int port) { if (registry.get(new Integer(port)) == null) return false; return true; } /**???????????????????????????????????????????????????????????????????????? * Restart the registry, if needed.???????????????????????????????????????? * Return the only instance of the registry for consistent global?????????? * using by making use of the Singleton Design Pattern????????????????????? *????????????????????????????????????????????????????????????????????????? * @return the internally held registry instance.?????????????????????????? */ public static Registry getRegistry(Integer port) { restart(port); return (Registry) registry.get(port); } private static void startRegistry(Integer port) throws RemoteException { Registry r; try { r = LocateRegistry.createRegistry(port.intValue()); registry.put(port, r); //r = new sun.rmi.registry.RegistryImpl???????????????????????????? /// (port.intValue());?????????????????????????????????????? // registry.put(port, r);?????????????????????????????????????????? } catch (Exception e) { //e.printStackTrace();????????????????????????????????????????????? r = LocateRegistry.getRegistry(port.intValue()); registry.put(port, r); } } public static void main(String args[]) throws RemoteException { //restart(port);??????????????????????????????????????????????????????? restart(5001); restart(5002); restart(5002); Registry r = LocateRegistry.getRegistry(5002); System.out.println("registry="+r); } } I would very much like to get your feedback on this new design pattern idea. Thank you for your time. Regards, - Doug From david.garnier at trusted-logic.com Wed Mar 22 07:36:10 2006 From: david.garnier at trusted-logic.com (David Garnier) Date: Wed, 22 Mar 2006 15:36:10 +0100 Subject: [Rxtx] sole of a new design pattern In-Reply-To: References: Message-ID: <442160DA.80107@trusted-logic.com> Hello, > The Parametric Singleton Design Pattern The Singleton is the most abused design pattern ever. Good use-cases for this pattern are extremely rare and mostly confined to problems related to hardware resources, like serial ports. > Applicability > > Use the Parametric Singleton Design Pattern when: > 1. There must be exactly one instance of a class with the given > parameters. OK. As I said above, this case this actually very unusual. The Singleton pattern is mostly used when : > 2. The instances must be accessible to clients from a well-known > access point. Using the singleton pattern in this case is just convenient for the programmer. Problems arises pretty quickly, especially if you attempt to unit-test your classes. 1) If your singleton is stateful, or hold on to stateful objects, it means that two different unit tests are not actually independent. Instead of starting with a brand new environment, the result of a test may be affected by the result of a previous test. This problem also arise when with your class relies on a database. In both cases, the solution is to reset your "unique" resource (Singleton or database) at the beginning of the test, which is a pain. Also, while most projects connect to a single database, projects that allow the use of Singletons usually contain several of thems, and new ones may cropped up unnoticed. You quickly end up with test cases that only pass in a certain order, which is a royal pain. 2) You cannot mockup a singleton. Once everyone calls the SomeSingleton class statically, you can't replace your class by SomeSingletonMockup. Furthermore, even for hardware services, the Singleton pattern does not really prevent concurrent accesses. If you start the same program in two different JVMs, unless they somehow shared the state of their "Singletons" (through lock files for example), the Singleton pattern will not prevent concurrent access. Our application uses RXTX, and we routinely encounter cases where another (native) application has already locked the port. Since we cannot modify the native application to recognize lock files, OS-level control is irreplaceable. > > Consequences > The Parametric Singleton Design Pattern has several benefits: > > 1. Controlled access to parametrically defined instances. Since > the Parametric Singleton class encapsulates its instances, there is > control over how and when clients access it. Not really. Once you've returned the instance to a client, you've lost control over it. The client can to whatever it wants with it. You cannot "recall" the instance or claim it back. > 2. Reduced name space. The Parametric Singleton pattern avoids > global variables that store instances created from the same parameter. Sure, but you don't have to rely on a Singleton for that. Just create a single Factory. > I would very much like to get your feedback on this new design > pattern idea. Well, it's nothing new. Some may say that it is the point of design patterns: formalizes the designs that occur again and again. However, this design is simply a combination of the Singleton and Factory patterns. I did use it in the past, but now I've been exposed to the shortcomings of the Singleton pattern, so I limit myself to Factories. Regards, David From sean_montgomery at baseview.com Wed Mar 22 08:35:28 2006 From: sean_montgomery at baseview.com (Sean Montgomery) Date: Wed, 22 Mar 2006 10:35:28 -0500 Subject: [Rxtx] sole of a new design pattern In-Reply-To: <442160DA.80107@trusted-logic.com> References: <442160DA.80107@trusted-logic.com> Message-ID: <05769CA7-A51B-4CF0-BAA0-E02DD905F5A4@baseview.com> On Mar 22, 2006, at 9:36 AM, David Garnier wrote: > Furthermore, even for hardware services, the Singleton pattern does > not really prevent concurrent > accesses. If you start the same program in two different JVMs, > unless they somehow shared the state > of their "Singletons" (through lock files for example), the > Singleton pattern will not prevent > concurrent access. > Multiple class loaders in a single JVM can be tricky, too. Then there's synchronization, lazy initialization and serialization of singletons to contend with. Bloch's Effective Java covers these, and here's a few articles: http://www.javaworld.com/javaworld/jw-04-2003/jw-0425-designpatterns- p3.html http://java.sun.com/developer/technicalArticles/Programming/singletons/ Just FYI :-) From lyon at docjava.com Wed Mar 22 08:50:48 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Wed, 22 Mar 2006 10:50:48 -0500 Subject: [Rxtx] sole of a new design pattern In-Reply-To: <442160DA.80107@trusted-logic.com> References: <442160DA.80107@trusted-logic.com> Message-ID: Hi All, First, I would like to thank David for his prompt and thoughtful remarks. I had no idea people that feel strongly about a design patterns! Wow! Feedback (particularly critical feedback) is greatly appreciated. Starting at the end, first: >I did use it in >the past, but now I've been exposed to the shortcomings of the >Singleton pattern, so I limit myself to Factories. David, if I understood your comments correctly, you suggested that Factories can be used in leu of the Singleton Design Pattern, or even the Parametric Singleton Design Pattern. As I see in [Gof]: Factory Method: Intent "Define an interface for creating an object, but let subclasses decide which class to instantiate. Factory Method lets a class defer instantiation to subclasses." The Singleton Design Pattern is a concrete class, which is rather different, right? Also, subclasses are not permitted with Singleton, as they are final. Naturally, I could use an abstract factory as a parent for a singleton. I could even design a facade that could be implemented with the singleton....but that is not the intention of the design. Unless you want a mock-up, as discussed, below: More below: >Hello, > >> The Parametric Singleton Design Pattern > >The Singleton is the most abused design pattern ever. Good use-cases >for this pattern are extremely >rare and mostly confined to problems related to hardware resources, >like serial ports. > > >> Applicability >> >> Use the Parametric Singleton Design Pattern when: >> 1. There must be exactly one instance of a class with the given >> parameters. >OK. As I said above, this case this actually very unusual. The >Singleton pattern is mostly used when : >> 2. The instances must be accessible to clients from a well-known >> access point. > >Using the singleton pattern in this case is just convenient for the >programmer. Problems arises >pretty quickly, especially if you attempt to unit-test your classes. > >1) If your singleton is stateful, or hold on to stateful objects, it >means that two different unit >tests are not actually independent. Instead of starting with a brand >new environment, the result of >a test may be affected by the result of a previous test. This >problem also arise when with your >class relies on a database. In both cases, the solution is to reset >your "unique" resource >(Singleton or database) at the beginning of the test, which is a >pain. Also, while most projects >connect to a single database, projects that allow the use of >Singletons usually contain several of >thems, and new ones may cropped up unnoticed. You quickly end up >with test cases that only pass in a >certain order, which is a royal pain. There are basic problems with communicating finite state machines that include reachability and deadlock analysis. These are addressed with petri net analysis and are beyond the scope of the design pattern. As you quite rightly pointed out; the parametric singleton pattern (or the singleton pattern, for that matter) enable multiple threads to gain access to the same instance. The only way that I can see to block others from gaining access to the reference is the synchronize keyword. This is putting a spin-lock (or MUTEX) on the reference. The question of how to unit-test a design pattern like the parametric singleton remains open. Perhaps this is a deficiency. > >2) You cannot mockup a singleton. Once everyone calls the >SomeSingleton class statically, you can't >replace your class by SomeSingletonMockup. Acutally, I am not sure that this is true. If the Singleton implements a Facade interface, it should be possible to make the replacement. Right? > >Furthermore, even for hardware services, the Singleton pattern does >not really prevent concurrent >accesses. If you start the same program in two different JVMs, >unless they somehow shared the state >of their "Singletons" (through lock files for example), the >Singleton pattern will not prevent >concurrent access. Good Point!! You have sharp eyes! The singleton design pattern should/could take responsibility for this. In fact, you may notice that my code does have an implementation (LocateRegistry) that can work across JVM's. The LocateRegistry will even work across the Internet! LocateRegistry takes both a host name and a Port (lock files just don't do this). I did not think to implement this beyond the local machine, but, in its present form, it will work across different processes. > >Our application uses RXTX, and we routinely encounter cases where >another (native) application has >already locked the port. Since we cannot modify the native >application to recognize lock files, >OS-level control is irreplaceable. The singleton design pattern is not meant to replace OS-level control, but to centralize the Java programmers access to it. If lock files, for example, are used for serial ports, the Singleton Design Pattern should be able to work with them. > > >> >> Consequences >> The Parametric Singleton Design Pattern has several benefits: >> > > 1. Controlled access to parametrically defined instances. Since >> the Parametric Singleton class encapsulates its instances, there is >> control over how and when clients access it. > >Not really. Once you've returned the instance to a client, you've >lost control over it. The client >can to whatever it wants with it. You cannot "recall" the instance >or claim it back. Good point, this should read: > 1. Controll when parametrically defined instances are created. Since > > the Parametric Singleton class encapsulates its instances, there is > > control over how and when they are instanced. > >> 2. Reduced name space. The Parametric Singleton pattern avoids >> global variables that store instances created from the same parameter. > >Sure, but you don't have to rely on a Singleton for that. Just >create a single Factory. > > Thank you for your thoughtful and prompt response! Regards, - Doug From dmarkman at mac.com Wed Mar 22 21:21:55 2006 From: dmarkman at mac.com (Dmitry Markman) Date: Wed, 22 Mar 2006 23:21:55 -0500 Subject: [Rxtx] sole of a new design pattern In-Reply-To: <442160DA.80107@trusted-logic.com> References: <442160DA.80107@trusted-logic.com> Message-ID: I don't think I get it On Mar 22, 2006, at 9:36 AM, David Garnier wrote: > Using the singleton pattern in this case is just convenient for the > programmer. Problems arises > pretty quickly, especially if you attempt to unit-test your classes. so you're saying that something isn't so good because you can not test it in the convenient way? if that's true, I'm totally disagree change your test, debug whatever, but if software is efficient at runtime, works fine and only problem is some unit test (which is some kind of framework for testing) then dump that unit test , dump that unit framework and make something appropriate to the software you're testing so if Douglas want to use singletons, what's the problem? and what do you mean by abusing of singleton usage? of course singleton doesn't prevent concurrent access to the resource across the processes unless you're using some OS facility to prevent it, besides singleton as it was introduced is relevant only and only inside of the same process otherwise it's not singleton it's something else (let's say network singleton: so you have remote invocation facility and some factory method that return object created by that facility) I don't have any problem with using any kind of singletons. Parametric Singleton idea (if I understand it right) could be easily implemented in the following way: use a map populate map with instances of some class and key is your parameter (you can use lazy population too) if somebody ask the key check the value if it's null so resource is taken if somebody returns the resource put it back to the map public synchronized static Object getSomeResource(Object parameter); public synchronized static void returnResource(Object parameter); getSomeResource (inside of the same process) could return null in 2 cases 1. if somebody (from other thread for example) already took that resource 2. if OS API said that resource corresponded to that parameter (serial port with parameter = 1 (port #)) is locked and unavailable; I'm not sure that in case of serial ports we even need those Parametric Singletons (unless lock checking is a very expensive operation) just ask the OS about availability of that resource and if it's available give it away and then OS will lock it and therefore in next time somebody ask it just answer that resource is locked and return null for example system has 2 serial ports available so I ask getResource("tty"); or I ask getResource("Bluetooth-Modem"); and if OS is ok you can give tty or Bluetooth-Modem or both no need for any additional pattern I think back to the problem mac os x doesn't recognize locking via files, so it handles locking via some API an instance of the singleton in each process should recognize that resource is locked (by using that API) that's all we don't have to make things more complicate then they are just because there is some nice design pattern or nice unit test framework or whatever keep things simple, make them work fast, don't introduce middle layers unless you have really good reason to do so of course I could be entirely wrong, so sorry about that in advance thanks Dmitry Markman From tjarvi at qbang.org Wed Mar 22 22:31:41 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 22 Mar 2006 22:31:41 -0700 (MST) Subject: [Rxtx] sole of a new design pattern In-Reply-To: References: Message-ID: Hi Doug Interesting reading. So far I'm just reading and thinking. I have one question so far. " Clients obtain a reference to a Parametric Singleton instance only through the parametric singleton design pattern. If the instance is left in an improper state (e.g., the serial port was left open) it is NOT the role of the Parametric Singleton Design Pattern to close the IO port. Nor is it the role of the Parametric Singleton Design Pattern to open the port. That role is delegate to some other part of the system. " So when the clients obtain a reference to the singleton, can they assume the port is there? IE, would it be the singletons role to handle things like USB dongles being removed with event hints comming from the underlying OS. Hardware abstraction layer/HAL on Linux is an example of underlying OS events. I assume that role too is delegated to other parts of the system? -- Trent Jarvi tjarvi at qbang.org From lyon at docjava.com Thu Mar 23 08:10:33 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Thu, 23 Mar 2006 10:10:33 -0500 Subject: [Rxtx] Classes don't need goals, they need roles! In-Reply-To: References: Message-ID: Hi Trent, Yes, I think that the role of the Parametric Singleton Pattern is not to open or close serial ports, nor is it to perform error checking. On the other hand, if you were to combine the role of the Parametric Singleton Pattern with another role (like that of error checking) it might not be amiss. However, I generally caution programmers against adding multiple roles to classes, as this leads to monolithic designs. Thus a different class (NativeLibDetect) could have the role of determining if the native library can be loaded. Another class (SerialPortBean) can have the role of serializing the default state of the serial port, so that it can be recovered, from user preferences, at a later time. The SerialPortDetect could have the role of determining if the serial port is removed (i.e., a USB port was unplugged). My guess is that each class should have a different role in the system, in order to ease maintenance and testing...but I could be wrong about that. Thanks! - Doug >Hi Doug > >Interesting reading. So far I'm just reading and thinking. I have >one question so far. > >" > Clients obtain a reference to a Parametric Singleton instance only >through the parametric singleton design pattern. If the instance is >left in an improper state (e.g., the serial port was left open) it is >NOT the role of the Parametric Singleton Design Pattern to close the >IO port. Nor is it the role of the Parametric Singleton Design Pattern >to >open the port. That role is delegate to some other part of the system. >" > >So when the clients obtain a reference to the singleton, can they >assume the port is there? IE, would it be the singletons role to >handle things like USB dongles being removed with event hints >comming from the underlying OS. Hardware abstraction layer/HAL on >Linux is an example of underlying OS events. > >I assume that role too is delegated to other parts of the system? > >-- >Trent Jarvi >tjarvi at qbang.org >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From maximulo at yahoo.com Fri Mar 24 01:22:38 2006 From: maximulo at yahoo.com (Maximulo Majir) Date: Fri, 24 Mar 2006 00:22:38 -0800 (PST) Subject: [Rxtx] JavaPOS Message-ID: <20060324082238.66371.qmail@web38214.mail.mud.yahoo.com> Hi all! Hello Trent! From what i understand, RXTX or JavaComm APIs were not created solely for JavaPOS. In JavaPOS, we have the virtual method claim() which is separate from open(), but in our RXTX API, claiming is done every call to open(), we cant open the port if its claimed by another application. Would it be alright to suggest or ask to create a new method called claim(..)? Is there such thing as forceclaim() in RXTX? this could be the same as portownership transfer or its equivalent. ForceClaim is in JSR80. Do you have some samples using RXTX as the lower layer for the Device Service Objects in JavaPOS? I have tried it, i just want to compare. Thank you all! maxim __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060324/496adba2/attachment-0047.html From tjarvi at qbang.org Fri Mar 24 11:28:19 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 24 Mar 2006 11:28:19 -0700 (MST) Subject: [Rxtx] Re: RXTX 2.1 Solaris Problems In-Reply-To: <3691.1143210578@www045.gmx.net> References: <3691.1143210578@www045.gmx.net> Message-ID: On Fri, 24 Mar 2006, Andreas Guenther wrote: > Hi all, > > the solaris problem was not the lock file only. > > Ok, I had to create the directory /var/spool/locks myself. > /var/spool/uucp exists. > > But rxtx didn't find any port. > > I compiled the source with my own debug-informations > and I tried to isolate the problem. > > The problem is the testRead-call in SerialImp.c > > JNIEXPORT jboolean JNICALL RXTXCommDriver(testRead)( > > ... > if ( READ( fd, &c, 1 ) < 0 ) > { > if ( errno != EAGAIN ) { > report( "testRead() read failed\n" ); > ret = JNI_FALSE; > } > } > Thanks Andreas I'm packing up to move. I'll be more or less away for a couple weeks here. I'll be checking email but my workstation is going into a box soon. This isn't hard to fix as this port should be enumerated when EWOULDBLOCK is recieved. Thats error is OK for enumeration just as EAGAIN is. I've put the bug into bugzilla so we dont forget to get to it. http://bugzilla.qbang.org/show_bug.cgi?id=42 You can add yourself to the CC list if you wish to test fixes we provide or even put a patch into bugzilla yourself. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Fri Mar 24 11:51:52 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 24 Mar 2006 11:51:52 -0700 (MST) Subject: [Rxtx] JavaPOS In-Reply-To: <20060324082238.66371.qmail@web38214.mail.mud.yahoo.com> References: <20060324082238.66371.qmail@web38214.mail.mud.yahoo.com> Message-ID: On Fri, 24 Mar 2006, Maximulo Majir wrote: > Hi all! Hello Trent! > > > From what i understand, RXTX or JavaComm APIs were not > created solely for JavaPOS. In JavaPOS, we have the virtual method > claim() which is separate from open(), but in our RXTX API, claiming is > done every call to open(), we cant open the port if its claimed by > another application. Would it be alright to suggest or ask to create a > new method called claim(..)? Is there such thing as forceclaim() in > RXTX? this could be the same as portownership transfer or its > equivalent. ForceClaim is in JSR80. > Do you have some samples using RXTX as the lower layer for the Device > Service Objects in JavaPOS? I have tried it, i just want to compare. > maxim Hi Maxim JSR80 is the USB API IBM/Sun put together. The problem is they have a richer kernel/API underneath that can handle such things. With Serial Ports, there isnt anything there other than an ioctl that says don't let anyone touch this and lockfiles that are more of a 'lets be nice.' At times we may be using USB ports but it is through the termios layer with the limitations mentioned. The advantage is that not only USB will work with rxtx. Anything that has a termios layer should work (to the extent that termios layer is complete). I don't know how forceclaim() would help you. Lets say someone has a programmer working on /dev/ttyS0 and you take it. Now you both race each other to read data first. There isn't a mechanism I know of that will solve this problem in termios. The most obvious test being a native app and a Java app trying to take the port. There is the potential of requestion ownership from other Java Applications but the use for that is very rare. Did you have something more specific in mind that I'm missing? I'm not sure that claim() and forceclaim() would help you with rxtx other than maybe locking the port with claim() without opening it. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sat Mar 25 23:42:08 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 25 Mar 2006 23:42:08 -0700 (MST) Subject: [Rxtx] Serial snoop Message-ID: I was reading the Linux kernel mail-list tonight and ran past a thread that mentioned sersnoop. This looks like a handy tool for people dealing with new toys. "a simple command-line tool for linux that echoes bytes to and from any two serial ports, ptys, or network sockets, and prints all traffic to stdout, in hex and ascii." http://www.restivo.org/projects/sersnoop/ It works on Linux only at this time (debian package available). -- Trent Jarvi tjarvi at qbang.org From beat.arnet at gmail.com Sun Mar 26 07:32:35 2006 From: beat.arnet at gmail.com (Beat Arnet) Date: Sun, 26 Mar 2006 09:32:35 -0500 Subject: [Rxtx] Error 0x5 at /home/bob/foo/tar/rxtx-2.1-7/build/../src/termios.c(860): Access is, denied. Message-ID: <4426A603.80508@gmail.com> Dear all, When trying to open the serial port, I sometimes (not always) run into the following exception (when opening the serialPort): Error 0x5 at /home/bob/foo/tar/rxtx-2.1-7/build/../src/termios.c(860): Access is denied. java.lang.UnsatisfiedLinkError: native_psmisc_report_owner at gnu.io.CommPortIdentifier.native_psmisc_report_owner(Native Method) at gnu.io.CommPortIdentifier.open(CommPortIdentifier.java:354) at codeskin.tools.CLLoader.open(CLLoader.java:79) at codeskin.tools.C2000Programmer.run(C2000Programmer.java:220) at java.lang.Thread.run(Unknown Source) Is this the type of error where I should just try to open the port again, or can it be avoided? Regards, Beat From tjarvi at qbang.org Sun Mar 26 11:40:12 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 26 Mar 2006 11:40:12 -0700 (MST) Subject: [Rxtx] Error 0x5 at /home/bob/foo/tar/rxtx-2.1-7/build/../src/termios.c(860): Access is, denied. In-Reply-To: <4426A603.80508@gmail.com> References: <4426A603.80508@gmail.com> Message-ID: On Sun, 26 Mar 2006, Beat Arnet wrote: > Dear all, > > When trying to open the serial port, I sometimes (not always) run into > the following exception (when opening the serialPort): > > Error 0x5 at /home/bob/foo/tar/rxtx-2.1-7/build/../src/termios.c(860): > Access is > denied. > > java.lang.UnsatisfiedLinkError: native_psmisc_report_owner > at gnu.io.CommPortIdentifier.native_psmisc_report_owner(Native > Method) > at gnu.io.CommPortIdentifier.open(CommPortIdentifier.java:354) > at codeskin.tools.CLLoader.open(CLLoader.java:79) > at codeskin.tools.C2000Programmer.run(C2000Programmer.java:220) > at java.lang.Thread.run(Unknown Source) > > Is this the type of error where I should just try to open the port again, > or can it be avoided? > Hi Beat We did a second build of rxtx 2.1-7 to resolve that unsatisfied link error. It should work now. rxtx is trying to tell you it thinks someone else has the serial port open. You can try to open the port again but maybe you already have a copy of the program running when it happens? ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7r2.zip fixed build. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sun Mar 26 11:44:23 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 26 Mar 2006 11:44:23 -0700 (MST) Subject: [Rxtx] RXTX spec file (fwd) Message-ID: This is probably interesting for fedora/suse users. ---------- Forwarded message ---------- Date: Sun, 26 Mar 2006 16:25:45 +0200 To: taj at www.linux.org.uk Subject: RXTX spec file I send you this spec file which allows to create a RPM for Fedora 4, 5 (x86, x86_64) with Java Sun. -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: rxtx.spec Url: http://mailman.qbang.org/pipermail/rxtx/attachments/20060326/6c7b6af6/rxtx-0043.pl From tjarvi at qbang.org Sun Mar 26 23:42:59 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 26 Mar 2006 23:42:59 -0700 (MST) Subject: [Rxtx] Upcomming events. Message-ID: This Wednesday we will be announcing a new "Maintainer" for the rxtx project. The position is more like neutral leader. I wont be going away or doing less. This is just the right thing to do as it turns out the two people with CVS write access will be at the same company. We need a third and we need neutrality. The maintainer will have final say in any conflict and will try to be neutral. It will be open for discussion. Then we will do it :) I'll still do most of the footwork I do now. But. I'm falling behind. I should have gone through the mail-list and posted the next round of changes this weekend. I'm packing to move and its going so so - 13 years of toys collected. I suspect there will be a dead period on my part (a couple weeks) comming up. But if you get it on the mail-list, we will get it in if there are no objections. I may well not be reading the mail-list during this period as I look for a house and many other things. I hope everyone will help out. Thanks -- Trent Jarvi tjarvi at qbang.org From mahmoud_hadad at yahoo.com Sun Mar 26 07:31:19 2006 From: mahmoud_hadad at yahoo.com (ronan nick) Date: Sun, 26 Mar 2006 06:31:19 -0800 (PST) Subject: [Rxtx] a question about the COMM API Message-ID: <20060326143119.54919.qmail@web60014.mail.yahoo.com> hi, i was intrested in knowing how i can communicate with my internal modem using java? for example if i want to make a phone dialer application or a caller id application where should i be looking at? and as i understood the COMM API is for devices that is attached to the computer through serial ports. --------------------------------- New Yahoo! Messenger with Voice. Call regular phones from your PC and save big. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060326/ce8329f0/attachment-0045.html From dmarkman at mac.com Mon Mar 20 00:20:43 2006 From: dmarkman at mac.com (Dmitry Markman) Date: Mon, 20 Mar 2006 02:20:43 -0500 Subject: [Rxtx] Mac OS X RXTX java installer In-Reply-To: References: <07D0DE29-BA32-4CFE-B036-66BC6423D385@buechse.de> <441AE3E0.2030503@willicon.de> <12531986.1142622114996.JavaMail.dmarkman@mac.com> <441B2674.9010409@willicon.de> <13577405.1142634732776.JavaMail.dmarkman@mac.com> <441B4182.8010407@willicon.de> <92CD0D6C-5BE8-426E-A46D-99452059FF49@mac.com> <441BBB2D.8030305@willicon.de> <441C4088.5090905@willicon.de> Message-ID: <64BC1E23-FDDE-4CE6-8863-CFC881CBC224@mac.com> Hi all I put RXTX installer that will install everything (and will create / var/lock if necessary and add user to the uucp group) for mac os x from Java into the rxtx's CVS repository it could be easily modified to install files for any platform it uses Greg Guerin's AuthKit for authentication and authorization Greg released that kit under artistic license, so Trent, please take a look we, probably, can negotiate license with Greg if it's necessary Greg's AuthKit could be downloaded from http://www.amug.org/~glguerin/ sw/#authkit Michael Hall (mikehall at spacestar dot net) had a suggestion to make implementation of the jaas LoginModule based on Greg's AuthKit (his modification of the Greg's AuthKit could be found at http:// www.spacestar.net/users/mikehall/authkit.dmg) but Michael's AuthKitLoginModule does only half a job: it does authenticate but it can not run any external unix process in privileged mode (at least I wasn't able to do so) possible explanation could be found in conversation between Greg and Michael at Apple's java-dev list (look for archives) so I didn't use jaas API for rxtxinstaller I created folder MacOSX in the contrib folder comment 1. if you want to run that installer as standalone application all you need that RXTXInstaller.jar 2. if you want to use webstart you have to add Greg's libAuthKit.jnilib to the mac os x's resources in theory RXTXInstaller.jar doesn't need it, but there is a problem with loading libAuthKit.jnilib from webstart authkit uses loadLibrary method to load library and it failed (from webstart) for standalone application I extract libAuthKit.jnilib from the RXTXInstaller.jar and put it into the /Library/Java/Extensions or ~/Library/Java/Extensions folder that file will be deleted after installer quit unfortunately I didn't have time to put documentation there but it is mostly self-explanatory I took installer code from my gl4java installer that I did about 3 years ago (with small modifications) it would be very nice if Apple will release LoginModule that really will do the job (com.apple.security.auth.module package????? ) (UnixLoginModule is pretty useless) From lyon at docjava.com Mon Mar 20 06:34:39 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Mon, 20 Mar 2006 08:34:39 -0500 Subject: [Rxtx] Mac OS X RXTX java installer In-Reply-To: <64BC1E23-FDDE-4CE6-8863-CFC881CBC224@mac.com> References: <07D0DE29-BA32-4CFE-B036-66BC6423D385@buechse.de> <441AE3E0.2030503@willicon.de> <12531986.1142622114996.JavaMail.dmarkman@mac.com> <441B2674.9010409@willicon.de> <13577405.1142634732776.JavaMail.dmarkman@mac.com> <441B4182.8010407@willicon.de> <92CD0D6C-5BE8-426E-A46D-99452059FF49@mac.com> <441BBB2D.8030305@willicon.de> <441C4088.5090905@willicon.de> <64BC1E23-FDDE-4CE6-8863-CFC881CBC224@mac.com> Message-ID: Hi Dimitry, This sounds like great work. Just a couple of questions; After the check out of the CVS files, using: setenv CVSROOT :pserver:anonymous at cvs.milestonesolutions.com:/usr/local/cvsroot 53 8:28 setenv PASSWORD mousy 54 8:29 cvs login 55 8:29 cvs checkout rxtx-devel I cd'd over to: rxtx-devel/MACOSX_IDE And found: CVS/ CW/ ForPackageMaker/ PB/ Where is the installer? Thanks! - Doug From tjarvi at qbang.org Mon Mar 20 06:39:37 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 20 Mar 2006 06:39:37 -0700 (MST) Subject: [Rxtx] Mac OS X RXTX java installer In-Reply-To: References: <07D0DE29-BA32-4CFE-B036-66BC6423D385@buechse.de> <441AE3E0.2030503@willicon.de> <12531986.1142622114996.JavaMail.dmarkman@mac.com> <441B2674.9010409@willicon.de> <13577405.1142634732776.JavaMail.dmarkman@mac.com> <441B4182.8010407@willicon.de> <92CD0D6C-5BE8-426E-A46D-99452059FF49@mac.com> <441BBB2D.8030305@willicon.de> <441C4088.5090905@willicon.de> <64BC1E23-FDDE-4CE6-8863-CFC881CBC224@mac.com> Message-ID: On Mon, 20 Mar 2006, Dr. Douglas Lyon wrote: > Hi Dimitry, > This sounds like great work. Just a couple of questions; > After the check out of the CVS files, using: > setenv CVSROOT > :pserver:anonymous at cvs.milestonesolutions.com:/usr/local/cvsroot > 53 8:28 setenv PASSWORD mousy > 54 8:29 cvs login > 55 8:29 cvs checkout rxtx-devel Hi Doug You want "cvs checkout -r commapi-0-0-1 rxtx-devel" to get RXTX 2.1 The default branch is rxtx 2.0 which isn't very active right now. -- Trent Jarvi tjarvi at qbang.org From lyon at docjava.com Mon Mar 20 07:05:44 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Mon, 20 Mar 2006 09:05:44 -0500 Subject: [Rxtx] Mac OS X RXTX java installer In-Reply-To: References: <07D0DE29-BA32-4CFE-B036-66BC6423D385@buechse.de> <441AE3E0.2030503@willicon.de> <12531986.1142622114996.JavaMail.dmarkman@mac.com> <441B2674.9010409@willicon.de> <13577405.1142634732776.JavaMail.dmarkman@mac.com> <441B4182.8010407@willicon.de> <92CD0D6C-5BE8-426E-A46D-99452059FF49@mac.com> <441BBB2D.8030305@willicon.de> <441C4088.5090905@willicon.de> <64BC1E23-FDDE-4CE6-8863-CFC881CBC224@mac.com> Message-ID: Hi Trent, Thanks for the info on the CVS checkout procedure. I did that and am still not sure where the installer is. Here is what I have: cd MACOSX_IDE/ p4.docjava.com{lyon}121: ls CVS/ ForPackageMaker/ PB/ p4.docjava.com{lyon}122: find . | more . ./ForPackageMaker ./ForPackageMaker/RXTX.pkg.sit.hqx ./ForPackageMaker/Resources ./ForPackageMaker/Resources/ReadMe.rtf ./ForPackageMaker/Resources/Welcome.rtf ./ForPackageMaker/Resources/CVS ./ForPackageMaker/Resources/CVS/Entries ./ForPackageMaker/Resources/CVS/Repository ./ForPackageMaker/Resources/CVS/Tag ./ForPackageMaker/Resources/CVS/Root ./ForPackageMaker/Resources/preinstall ./ForPackageMaker/Resources/License.rtf ./ForPackageMaker/Resources/preupgrade ./ForPackageMaker/RXTX.pmsp ./ForPackageMaker/CVS ./ForPackageMaker/CVS/Entries ./ForPackageMaker/CVS/Repository ./ForPackageMaker/CVS/Entries.Log ./ForPackageMaker/CVS/Tag ./ForPackageMaker/CVS/Root ./ForPackageMaker/RXTX_Tiger.pkg.sitx.hqx ./ForPackageMaker/RXTX_Jag.pkg.sit.hqx ./ForPackageMaker/Install ./ForPackageMaker/Install/CVS ./ForPackageMaker/Install/CVS/Entries ./ForPackageMaker/Install/CVS/Repository ./ForPackageMaker/Install/CVS/Tag ./ForPackageMaker/Install/CVS/Root ./ForPackageMaker/Install/Library ./ForPackageMaker/Install/Library/CVS ./ForPackageMaker/Install/Library/CVS/Entries ./ForPackageMaker/Install/Library/CVS/Repository ./ForPackageMaker/Install/Library/CVS/Tag ./ForPackageMaker/Install/Library/CVS/Root ./ForPackageMaker/Install/Library/Java ./ForPackageMaker/Install/Library/Java/Extensions ./ForPackageMaker/Install/Library/Java/Extensions/RXTXcomm.jar ./ForPackageMaker/Install/Library/Java/Extensions/CVS ./ForPackageMaker/Install/Library/Java/Extensions/CVS/Entries ./ForPackageMaker/Install/Library/Java/Extensions/CVS/Repository ./ForPackageMaker/Install/Library/Java/Extensions/CVS/Tag ./ForPackageMaker/Install/Library/Java/Extensions/CVS/Root ./ForPackageMaker/Install/Library/Java/Extensions/librxtxSerial.jnilib ./ForPackageMaker/Install/Library/Java/CVS ./ForPackageMaker/Install/Library/Java/CVS/Entries ./ForPackageMaker/Install/Library/Java/CVS/Repository ./ForPackageMaker/Install/Library/Java/CVS/Entries.Log ./ForPackageMaker/Install/Library/Java/CVS/Tag ./ForPackageMaker/Install/Library/Java/CVS/Root ./ForPackageMaker/RXTX_Tiger.pmproj.sitx.hqx ./CVS ./CVS/Entries ./CVS/Repository ./CVS/Entries.Log ./CVS/Tag ./CVS/Root ./PB ./PB/LibSerialUniversal.xcodeproj.sitx.hqx ./PB/CVS ./PB/CVS/Entries ./PB/CVS/Repository ./PB/CVS/Entries.Log ./PB/CVS/Tag ./PB/CVS/Root ./PB/LibSerial.pbproj.sit.hqx ./PB/startpoint.c ./PB/config.h What is the procedure to run this installer? Do we need a README in: /rxtx-devel/MACOSX_IDE Here is what we have: CVS/ ForPackageMaker/ PB/ Thanks! - DL >On Mon, 20 Mar 2006, Dr. Douglas Lyon wrote: > >>Hi Dimitry, >>This sounds like great work. Just a couple of questions; >>After the check out of the CVS files, using: >>setenv CVSROOT >>:pserver:anonymous at cvs.milestonesolutions.com:/usr/local/cvsroot >> 53 8:28 setenv PASSWORD mousy >> 54 8:29 cvs login >> 55 8:29 cvs checkout rxtx-devel > >Hi Doug > >You want "cvs checkout -r commapi-0-0-1 rxtx-devel" to get RXTX 2.1 >The default branch is rxtx 2.0 which isn't very active right now. > >-- >Trent Jarvi >tjarvi at qbang.org From tjarvi at qbang.org Mon Mar 20 07:25:30 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 20 Mar 2006 07:25:30 -0700 (MST) Subject: [Rxtx] Mac OS X RXTX java installer In-Reply-To: References: <07D0DE29-BA32-4CFE-B036-66BC6423D385@buechse.de> <441AE3E0.2030503@willicon.de> <12531986.1142622114996.JavaMail.dmarkman@mac.com> <441B2674.9010409@willicon.de> <13577405.1142634732776.JavaMail.dmarkman@mac.com> <441B4182.8010407@willicon.de> <92CD0D6C-5BE8-426E-A46D-99452059FF49@mac.com> <441BBB2D.8030305@willicon.de> <441C4088.5090905@willicon.de> <64BC1E23-FDDE-4CE6-8863-CFC881CBC224@mac.com> Message-ID: On Mon, 20 Mar 2006, Dr. Douglas Lyon wrote: > Hi Trent, > Thanks for the info on the CVS checkout procedure. > I did that and am still not sure where the installer is. Hi Doug It does look like it was not cvs committed. There is no rxtx-devel/contrib/MacOSX directory in there at the moment. It was mentioned that it was put under contrib. -- Trent Jarvi tjarvi at qbang.org From dmarkman at mac.com Mon Mar 20 07:29:56 2006 From: dmarkman at mac.com (Dmitry Markman) Date: Mon, 20 Mar 2006 09:29:56 -0500 Subject: [Rxtx] Mac OS X RXTX java installer In-Reply-To: References: <07D0DE29-BA32-4CFE-B036-66BC6423D385@buechse.de> <441AE3E0.2030503@willicon.de> <12531986.1142622114996.JavaMail.dmarkman@mac.com> <441B2674.9010409@willicon.de> <13577405.1142634732776.JavaMail.dmarkman@mac.com> <441B4182.8010407@willicon.de> <92CD0D6C-5BE8-426E-A46D-99452059FF49@mac.com> <441BBB2D.8030305@willicon.de> <441C4088.5090905@willicon.de> <64BC1E23-FDDE-4CE6-8863-CFC881CBC224@mac.com> Message-ID: <6054EB4E-F7E0-4A9C-BDDA-D582D6D8826F@mac.com> you can find it in the rxtx-devel/contrib folder On Mar 20, 2006, at 9:05 AM, Dr. Douglas Lyon wrote: > Hi Trent, > Thanks for the info on the CVS checkout procedure. > I did that and am still not sure where the installer is. > Here is what I have: > cd MACOSX_IDE/ > p4.docjava.com{lyon}121: ls > CVS/ ForPackageMaker/ PB/ > p4.docjava.com{lyon}122: find . | more > . > ./ForPackageMaker > ./ForPackageMaker/RXTX.pkg.sit.hqx > ./ForPackageMaker/Resources > ./ForPackageMaker/Resources/ReadMe.rtf > ./ForPackageMaker/Resources/Welcome.rtf > ./ForPackageMaker/Resources/CVS > ./ForPackageMaker/Resources/CVS/Entries > ./ForPackageMaker/Resources/CVS/Repository > ./ForPackageMaker/Resources/CVS/Tag > ./ForPackageMaker/Resources/CVS/Root > ./ForPackageMaker/Resources/preinstall > ./ForPackageMaker/Resources/License.rtf > ./ForPackageMaker/Resources/preupgrade > ./ForPackageMaker/RXTX.pmsp > ./ForPackageMaker/CVS > ./ForPackageMaker/CVS/Entries > ./ForPackageMaker/CVS/Repository > ./ForPackageMaker/CVS/Entries.Log > ./ForPackageMaker/CVS/Tag > ./ForPackageMaker/CVS/Root > ./ForPackageMaker/RXTX_Tiger.pkg.sitx.hqx > ./ForPackageMaker/RXTX_Jag.pkg.sit.hqx > ./ForPackageMaker/Install > ./ForPackageMaker/Install/CVS > ./ForPackageMaker/Install/CVS/Entries > ./ForPackageMaker/Install/CVS/Repository > ./ForPackageMaker/Install/CVS/Tag > ./ForPackageMaker/Install/CVS/Root > ./ForPackageMaker/Install/Library > ./ForPackageMaker/Install/Library/CVS > ./ForPackageMaker/Install/Library/CVS/Entries > ./ForPackageMaker/Install/Library/CVS/Repository > ./ForPackageMaker/Install/Library/CVS/Tag > ./ForPackageMaker/Install/Library/CVS/Root > ./ForPackageMaker/Install/Library/Java > ./ForPackageMaker/Install/Library/Java/Extensions > ./ForPackageMaker/Install/Library/Java/Extensions/RXTXcomm.jar > ./ForPackageMaker/Install/Library/Java/Extensions/CVS > ./ForPackageMaker/Install/Library/Java/Extensions/CVS/Entries > ./ForPackageMaker/Install/Library/Java/Extensions/CVS/Repository > ./ForPackageMaker/Install/Library/Java/Extensions/CVS/Tag > ./ForPackageMaker/Install/Library/Java/Extensions/CVS/Root > ./ForPackageMaker/Install/Library/Java/Extensions/librxtxSerial.jnilib > ./ForPackageMaker/Install/Library/Java/CVS > ./ForPackageMaker/Install/Library/Java/CVS/Entries > ./ForPackageMaker/Install/Library/Java/CVS/Repository > ./ForPackageMaker/Install/Library/Java/CVS/Entries.Log > ./ForPackageMaker/Install/Library/Java/CVS/Tag > ./ForPackageMaker/Install/Library/Java/CVS/Root > ./ForPackageMaker/RXTX_Tiger.pmproj.sitx.hqx > ./CVS > ./CVS/Entries > ./CVS/Repository > ./CVS/Entries.Log > ./CVS/Tag > ./CVS/Root > ./PB > ./PB/LibSerialUniversal.xcodeproj.sitx.hqx > ./PB/CVS > ./PB/CVS/Entries > ./PB/CVS/Repository > ./PB/CVS/Entries.Log > ./PB/CVS/Tag > ./PB/CVS/Root > ./PB/LibSerial.pbproj.sit.hqx > ./PB/startpoint.c > ./PB/config.h > > What is the procedure to run this installer? > Do we need a README in: > /rxtx-devel/MACOSX_IDE > Here is what we have: > CVS/ ForPackageMaker/ PB/ > > > Thanks! > - DL > >> On Mon, 20 Mar 2006, Dr. Douglas Lyon wrote: >> >>> Hi Dimitry, >>> This sounds like great work. Just a couple of questions; >>> After the check out of the CVS files, using: >>> setenv CVSROOT :pserver:anonymous at cvs.milestonesolutions.com:/usr/ >>> local/cvsroot >>> 53 8:28 setenv PASSWORD mousy >>> 54 8:29 cvs login >>> 55 8:29 cvs checkout rxtx-devel >> >> Hi Doug >> >> You want "cvs checkout -r commapi-0-0-1 rxtx-devel" to get RXTX 2.1 >> The default branch is rxtx 2.0 which isn't very active right now. >> >> -- >> Trent Jarvi >> tjarvi at qbang.org > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx Dmitry Markman From mikehall at spacestar.net Mon Mar 20 05:25:25 2006 From: mikehall at spacestar.net (Michael Hall) Date: Mon, 20 Mar 2006 06:25:25 -0600 Subject: [Rxtx] Re: Mac OS X RXTX java installer In-Reply-To: <64BC1E23-FDDE-4CE6-8863-CFC881CBC224@mac.com> References: <07D0DE29-BA32-4CFE-B036-66BC6423D385@buechse.de> <441AE3E0.2030503@willicon.de> <12531986.1142622114996.JavaMail.dmarkman@mac.com> <441B2674.9010409@willicon.de> <13577405.1142634732776.JavaMail.dmarkman@mac.com> <441B4182.8010407@willicon.de> <92CD0D6C-5BE8-426E-A46D-99452059FF49@mac.com> <441BBB2D.8030305@willicon.de> <441C4088.5090905@willicon.de> <64BC1E23-FDDE-4CE6-8863-CFC881CBC224@mac.com> Message-ID: <247EB61F-5CD1-4132-89A2-FC105B6CF9A5@spacestar.net> On Mar 20, 2006, at 1:20 AM, Dmitry Markman wrote: > > Michael Hall (mikehall at spacestar dot net) had a suggestion to > make implementation of the jaas LoginModule > based on Greg's AuthKit > (his modification of the Greg's AuthKit could be found at http:// > www.spacestar.net/users/mikehall/authkit.dmg) > but Michael's AuthKitLoginModule does only half a job: > it does authenticate > but it can not run any external unix process in privileged mode (at > least I wasn't able to do so) If you got it working directly with Greg's the point is moot. But to clarify it anyhow. The login module does not allow you to do anything anything privileged on return as was explained by Greg. You need to work with a separate privileged process using the execPrivileged method of his API. I assume you did something similar although I haven't looked at how you are using it yet. I allowed instead for a action to be performed at the same time you login/authenticate,this... System.setProperty("authkit.action","/usr/bin/id"); just before this... lc.login(); To clarify, safely ignored as you are already complete. Mike Hall mikehall at spacestar dot net http://www.spacestar.net/users/mikehall http://sourceforge.net/projects/macnative -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2427 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20060320/f6e18202/smime-0048.bin From dmarkman at mac.com Mon Mar 20 07:36:47 2006 From: dmarkman at mac.com (Dmitry Markman) Date: Mon, 20 Mar 2006 09:36:47 -0500 Subject: [Rxtx] Re: Mac OS X RXTX java installer In-Reply-To: <247EB61F-5CD1-4132-89A2-FC105B6CF9A5@spacestar.net> References: <07D0DE29-BA32-4CFE-B036-66BC6423D385@buechse.de> <441AE3E0.2030503@willicon.de> <12531986.1142622114996.JavaMail.dmarkman@mac.com> <441B2674.9010409@willicon.de> <13577405.1142634732776.JavaMail.dmarkman@mac.com> <441B4182.8010407@willicon.de> <92CD0D6C-5BE8-426E-A46D-99452059FF49@mac.com> <441BBB2D.8030305@willicon.de> <441C4088.5090905@willicon.de> <64BC1E23-FDDE-4CE6-8863-CFC881CBC224@mac.com> <247EB61F-5CD1-4132-89A2-FC105B6CF9A5@spacestar.net> Message-ID: Hi, Michael all I have to do is to run some shell script I tried to use your action mechanism and it worked great so I just System.setProperty ("authkit.action","" ) and after that I even don't need to run anything like subject.doAs.... but after few thoughts I choose to use plain Greg's approach, because in that case I don't have to deal with various java's configurations files and therefore to use 2-3 -D parameters in the java command line especially it's useful for java web start (it's so fragile :-( ) thanks for the great job On Mar 20, 2006, at 7:25 AM, Michael Hall wrote: > > On Mar 20, 2006, at 1:20 AM, Dmitry Markman wrote: >> >> Michael Hall (mikehall at spacestar dot net) had a suggestion to >> make implementation of the jaas LoginModule >> based on Greg's AuthKit >> (his modification of the Greg's AuthKit could be found at http:// >> www.spacestar.net/users/mikehall/authkit.dmg) >> but Michael's AuthKitLoginModule does only half a job: >> it does authenticate >> but it can not run any external unix process in privileged mode >> (at least I wasn't able to do so) > > If you got it working directly with Greg's the point is moot. > > But to clarify it anyhow. > The login module does not allow you to do anything anything > privileged on return as was explained by Greg. You need to work > with a separate privileged process using the execPrivileged method > of his API. I assume you did something similar although I haven't > looked at how you are using it yet. > I allowed instead for a action to be performed at the same time you > login/authenticate,this... > System.setProperty("authkit.action","/usr/bin/id"); > just before this... > lc.login(); > To clarify, safely ignored as you are already complete. > > Mike Hall mikehall at spacestar dot net > http://www.spacestar.net/users/mikehall > http://sourceforge.net/projects/macnative > > > Dmitry Markman From dmarkman at mac.com Mon Mar 20 07:44:45 2006 From: dmarkman at mac.com (Dmitry Markman) Date: Mon, 20 Mar 2006 09:44:45 -0500 Subject: [Rxtx] Mac OS X RXTX java installer In-Reply-To: References: <07D0DE29-BA32-4CFE-B036-66BC6423D385@buechse.de> <441AE3E0.2030503@willicon.de> <12531986.1142622114996.JavaMail.dmarkman@mac.com> <441B2674.9010409@willicon.de> <13577405.1142634732776.JavaMail.dmarkman@mac.com> <441B4182.8010407@willicon.de> <92CD0D6C-5BE8-426E-A46D-99452059FF49@mac.com> <441BBB2D.8030305@willicon.de> <441C4088.5090905@willicon.de> <64BC1E23-FDDE-4CE6-8863-CFC881CBC224@mac.com> Message-ID: it's in the commapi-0-0-1 branch I tested it right now: cvs co -r commapi-0-0-1 rxtx-devel and I got everything On Mar 20, 2006, at 9:25 AM, Trent Jarvi wrote: > On Mon, 20 Mar 2006, Dr. Douglas Lyon wrote: > >> Hi Trent, >> Thanks for the info on the CVS checkout procedure. >> I did that and am still not sure where the installer is. > > Hi Doug > > It does look like it was not cvs committed. There is no rxtx-devel/ > contrib/MacOSX directory in there at the moment. It was mentioned > that it was put under contrib. > > -- > Trent Jarvi > tjarvi at qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx Dmitry Markman From tjarvi at qbang.org Mon Mar 20 07:52:57 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 20 Mar 2006 07:52:57 -0700 (MST) Subject: [Rxtx] Mac OS X RXTX java installer In-Reply-To: References: <07D0DE29-BA32-4CFE-B036-66BC6423D385@buechse.de> <441AE3E0.2030503@willicon.de> <12531986.1142622114996.JavaMail.dmarkman@mac.com> <441B2674.9010409@willicon.de> <13577405.1142634732776.JavaMail.dmarkman@mac.com> <441B4182.8010407@willicon.de> <92CD0D6C-5BE8-426E-A46D-99452059FF49@mac.com> <441BBB2D.8030305@willicon.de> <441C4088.5090905@willicon.de> <64BC1E23-FDDE-4CE6-8863-CFC881CBC224@mac.com> Message-ID: On Mon, 20 Mar 2006, Dmitry Markman wrote: > it's in the commapi-0-0-1 branch > > I tested it right now: > cvs co -r commapi-0-0-1 rxtx-devel > > and I got everything > A fresh checkout worked. Here is a copy of the tree (just the installer bits) ftp://ftp.qbang.org/pub/rxtx/MacOSX-installer.zip -- Trent Jarvi tjarvi at qbang.org From lyon at docjava.com Mon Mar 20 08:08:26 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Mon, 20 Mar 2006 10:08:26 -0500 Subject: [Rxtx] Mac OS X RXTX java installer In-Reply-To: References: <07D0DE29-BA32-4CFE-B036-66BC6423D385@buechse.de> <441AE3E0.2030503@willicon.de> <12531986.1142622114996.JavaMail.dmarkman@mac.com> <441B2674.9010409@willicon.de> <13577405.1142634732776.JavaMail.dmarkman@mac.com> <441B4182.8010407@willicon.de> <92CD0D6C-5BE8-426E-A46D-99452059FF49@mac.com> <441BBB2D.8030305@willicon.de> <441C4088.5090905@willicon.de> <64BC1E23-FDDE-4CE6-8863-CFC881CBC224@mac.com> Message-ID: Hi All, Is the Auth package able to work properly on non Mac OS's? It was not clear from the doc or download. Thanks! - Doug From dmarkman at mac.com Mon Mar 20 08:15:22 2006 From: dmarkman at mac.com (Dmitry Markman) Date: Mon, 20 Mar 2006 10:15:22 -0500 Subject: [Rxtx] Mac OS X RXTX java installer In-Reply-To: References: <07D0DE29-BA32-4CFE-B036-66BC6423D385@buechse.de> <441AE3E0.2030503@willicon.de> <12531986.1142622114996.JavaMail.dmarkman@mac.com> <441B2674.9010409@willicon.de> <13577405.1142634732776.JavaMail.dmarkman@mac.com> <441B4182.8010407@willicon.de> <92CD0D6C-5BE8-426E-A46D-99452059FF49@mac.com> <441BBB2D.8030305@willicon.de> <441C4088.5090905@willicon.de> <64BC1E23-FDDE-4CE6-8863-CFC881CBC224@mac.com> Message-ID: <217312D8-CCCA-4859-ABA6-32DF1CC817B9@mac.com> thanks Trent, for putting it on ftp server On Mar 20, 2006, at 9:52 AM, Trent Jarvi wrote: > A fresh checkout worked. Here is a copy of the tree (just the > installer bits) > > ftp://ftp.qbang.org/pub/rxtx/MacOSX-installer.zip > Dmitry Markman From dmarkman at mac.com Mon Mar 20 09:14:03 2006 From: dmarkman at mac.com (Dmitry Markman) Date: Mon, 20 Mar 2006 11:14:03 -0500 Subject: [Rxtx] Mac OS X RXTX java installer In-Reply-To: References: <07D0DE29-BA32-4CFE-B036-66BC6423D385@buechse.de> <441AE3E0.2030503@willicon.de> <12531986.1142622114996.JavaMail.dmarkman@mac.com> <441B2674.9010409@willicon.de> <13577405.1142634732776.JavaMail.dmarkman@mac.com> <441B4182.8010407@willicon.de> <92CD0D6C-5BE8-426E-A46D-99452059FF49@mac.com> <441BBB2D.8030305@willicon.de> <441C4088.5090905@willicon.de> <64BC1E23-FDDE-4CE6-8863-CFC881CBC224@mac.com> Message-ID: <4DEBA6F0-DA45-4E84-823E-1F1AC48BDCCC@mac.com> no it will work only on mac os x however it's harmless to run it on other platform if you want to use it for other platform you have to do the following (I'll do it for linux) 1. modify RXTXInstaller class method public static RXTXInstaller getInstance() public static RXTXInstaller getInstance() { String osName = System.getProperty("os.name").toLowerCase(); if(osName.startsWith("mac")){ return new gnu.io.installer.macosx.MACOSXRXTXInstaller(); } else if(osName.startsWith("windows")){ return new gnu.io.installer.windows.WindowsRXTXInstaller(); }else if(osName.startsWith("linux")){ return new gnu.io.installer.linux.LinuxRXTXInstaller(); } return null; } 2. create folder gnu/io/installer/linux/ 3. create class Linux386RXTXInstaller package gnu.io.installer.linux; import java.io.File; public class Linux386RXTXInstaller extends gnu.io.installer.RXTXInstaller{ public Linux386RXTXInstaller(){ createJarFolder(); createLibFolder(); addJarResource("RXTXcomm.jar","/gnu/io/installer/resources/ linux/jar/RXTXcomm.dat"); addLibResource("librxtxSerial.so","/gnu/io/installer/ resources/linux/lib/librxtxSerial.so"); } protected void createJarFolder(){ String javaHome = System.getProperty("java.home"); char separator = File.separatorChar; jarFolder = new File(javaHome+separator+"lib"+separator+"ext"); } protected void createLibFolder(){ String javaHome = System.getProperty("java.home"); char separator = File.separatorChar; libFolder = new File(javaHome+separator+"bin"); } public void runPreProcess() {} //put here some action you need public void runPostProcess() {} //put here some action you need } 4. create folder /gnu/io/installer/resources/linux/jar and put there linux's version of RXTXcomm.dat (which is renamed RXTXcomm.jar) 5. create folder /gnu/io/installer/resources/linux/lib and put there linux's version of librxtxSerial. so 6. make sure that RXTXInstaller.jar has the following items: /gnu/io/installer/resources/linux/jar/RXTXcomm.jar /gnu/io/installer/resources/linux/lib/librxtxSerial.so 7. modify file installer.pref: jar file RXTXInstaller.jar must have the following item /gnu/io/installer/installer.pref that's basically it for windows you have to do the similar things: just replace linux to windows and librxtxSerial.so to rxtxSerial.dll and create appropriate gnu.io.installer.windows.WindowsRXTXInstaller class package gnu.io.installer.windows; import java.io.File; public class WindowsRXTXInstaller extends gnu.io.installer.RXTXInstaller{ public WindowsRXTXInstaller(){ createJarFolder(); createLibFolder(); addJarResource("RXTXcomm.jar","/gnu/io/installer/resources/ windows/jar/RXTXcomm.dat"); addLibResource("librxtxSerial.so","/gnu/io/installer/ resources/windows/lib/rxtxSerial.dll"); } protected void createJarFolder(){ String javaHome = System.getProperty("java.home"); char separator = File.separatorChar; jarFolder = new File(javaHome+separator+"lib"+separator+"ext"); } protected void createLibFolder(){ String javaHome = System.getProperty("java.home"); char separator = File.separatorChar; libFolder = new File(javaHome+separator+"bin"); } public void runPreProcess() {} //put here some action you need public void runPostProcess() {} //put here some action you need } installer.pref will look like On Mar 20, 2006, at 10:08 AM, Dr. Douglas Lyon wrote: > Hi All, > Is the Auth package able to work properly on > non Mac OS's? > It was not clear from the doc or download. > > Thanks! > - Doug > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx Dmitry Markman From joachim at buechse.de Mon Mar 20 10:49:06 2006 From: joachim at buechse.de (Joachim Buechse) Date: Mon, 20 Mar 2006 18:49:06 +0100 Subject: [Rxtx] BUG: Lock file stays even if port opening fails Message-ID: This was only tested on MacOSX but looking at the code, it should be true for all systems that use lock_uucp. I am opening a port which can not be opened (dialup port of a telephone paired via bluetooth but currently not reachable). The lock file is created and stays arround, even though the port open failed. After looking a bit through the code (of 2.17), I really wonder if it wouldn't be a good idea to make the "locking" an explicit operation called from the java code. This would certainly simplify the generation of meaningfull exceptions (and java based debugging). Maybe even the handling of "preopened" ports should be in the Java part of the lib (again for java based debugging puposes). That beeing said, I have no idea if this would be possible for the 2.07 implementation. Regards, Joachim From tjarvi at qbang.org Mon Mar 20 11:24:22 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 20 Mar 2006 11:24:22 -0700 (MST) Subject: [Rxtx] BUG: Lock file stays even if port opening fails In-Reply-To: References: Message-ID: On Mon, 20 Mar 2006, Joachim Buechse wrote: > This was only tested on MacOSX but looking at the code, it should be true > for all systems that use lock_uucp. > > I am opening a port which can not be opened (dialup port of a telephone > paired via bluetooth but currently not reachable). The lock file is > created and stays arround, even though the port open failed. > > > After looking a bit through the code (of 2.17), I really wonder if it > wouldn't be a good idea to make the "locking" an explicit operation > called from the java code. This would certainly simplify the generation > of meaningfull exceptions (and java based debugging). > Maybe even the handling of "preopened" ports should be in the Java part > of the lib (again for java based debugging puposes). That beeing said, I > have no idea if this would be possible for the 2.07 implementation. > > Regards, Hi Joachim It should be possible in the 2.0-7 implementation too. The calls to RXTXPort.java would not change. We would just do more there Moving more of that logic into Java would be better as many people don't like to look at C code. There is a liblockdev on most Linux distros that can do most of the C code and would be easier to use. The problem is embeded devices will not have that library. The preopened port code has not been really tested. That was a last minute request in a product cycle. I expect it will be tested this year though. As I recall, some devices really do not like CD raising on open. The preopened ports then allow people to mess around in java without power cycling the devices or losing data. -- Trent Jarvi tjarvi at qbang.org From joachim at buechse.de Mon Mar 20 12:01:08 2006 From: joachim at buechse.de (Joachim Buechse) Date: Mon, 20 Mar 2006 20:01:08 +0100 Subject: [Rxtx] BUG: Lock file stays even if port opening fails In-Reply-To: References: Message-ID: Hi Trent, What is your general feeling about moving code to Java? The last days I have been reading quite a bit of the code and there are several things, that might not work as expected. I'll give you two examples from is_device_locked: if LOCKDIR == /var/spool/locks the directory /var/spool/lock will not be checked. LOCKDIR is not checked for lockfiles with unexpected pefixes While these things have probably never been discovered in production, they are still possibly incorrect implementations. If it was Java code, I would write some unit tests producing the errors that could later be corrected. PS: One could imagine to actually implement the whole lockfile handling in Java using some native routines to get the values required (pid, st_dev, st_rdev, ...). On 20.03.2006, at 19:24, Trent Jarvi wrote: > On Mon, 20 Mar 2006, Joachim Buechse wrote: > >> This was only tested on MacOSX but looking at the code, it should >> be true for all systems that use lock_uucp. >> >> I am opening a port which can not be opened (dialup port of a >> telephone paired via bluetooth but currently not reachable). The >> lock file is created and stays arround, even though the port open >> failed. >> >> >> After looking a bit through the code (of 2.17), I really wonder if >> it wouldn't be a good idea to make the "locking" an explicit >> operation called from the java code. This would certainly simplify >> the generation of meaningfull exceptions (and java based debugging). >> Maybe even the handling of "preopened" ports should be in the Java >> part of the lib (again for java based debugging puposes). That >> beeing said, I have no idea if this would be possible for the 2.07 >> implementation. >> >> Regards, > > Hi Joachim > > It should be possible in the 2.0-7 implementation too. The calls > to RXTXPort.java would not change. We would just do more there > Moving more of that logic into Java would be better as many people > don't like to look at C code. There is a liblockdev on most Linux > distros that can do most of the C code and would be easier to use. > The problem is embeded devices will not have that library. > > The preopened port code has not been really tested. That was a > last minute request in a product cycle. I expect it will be tested > this year though. As I recall, some devices really do not like CD > raising on open. The preopened ports then allow people to mess > around in java without power cycling the devices or losing data. > > -- > Trent Jarvi > tjarvi at qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Mon Mar 20 12:21:02 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 20 Mar 2006 12:21:02 -0700 (MST) Subject: [Rxtx] BUG: Lock file stays even if port opening fails In-Reply-To: References: Message-ID: On Mon, 20 Mar 2006, Joachim Buechse wrote: > Hi Trent, > > What is your general feeling about moving code to Java? The last days I > have been reading quite a bit of the code and there are several things, > that might not work as expected. > > I'll give you two examples from is_device_locked: > > if LOCKDIR == /var/spool/locks the directory /var/spool/lock will not be > checked. > LOCKDIR is not checked for lockfiles with unexpected pefixes > > While these things have probably never been discovered in production, > they are still possibly incorrect implementations. If it was Java code, I > would write some unit tests producing the errors that could later be > corrected. > > PS: One could imagine to actually implement the whole lockfile handling > in Java using some native routines to get the values required (pid, > st_dev, st_rdev, ...). Hi Joachim I like the idea of moving more of the code into java but there are some things to consider. If you break this into multiple JNI calls, the performance will drop considerably during enumeration of ports. We are looking for 256 ports per dev type vs (16? in Sun's 2.0 and fewer types). Its hard to make assumptions. I've seen virtual ports start at /dev/foo100 for instance. It works out to over 7500 ports on Linux if you enable them all. We already trim that back by default. See Linux-all-ports in RXTXCommDriver.java. There are also native libraries that rxtx can link to. If you move too much into Java, linking to 'standard' libraries with distros will break. "configure --enable-liblock=yes" will not be doable. This is probably a favorable way with RedHat, Debian, Suse and others. Thats the right thing to do if there will be rpms, dpkg, .. For those reasons, I think it still make sense to keep it to a minimal ~3 calls to JNI code that we can use for speed and versatility. lock() isLocked(), unlock() perhaps. When I say speed, its more about avoiding crossing the JNI layer multiple times than java vs C performance. With versatility I think liblock is the right way for most but not all (embeded) linux distros. -- Trent Jarvi tjarvi at qbang.org From joachim at buechse.de Mon Mar 20 12:42:04 2006 From: joachim at buechse.de (Joachim Buechse) Date: Mon, 20 Mar 2006 20:42:04 +0100 Subject: [Rxtx] BUG: Lock file stays even if port opening fails In-Reply-To: References: Message-ID: <82C19FE7-DDCB-45B6-B2C9-7606B66F0124@buechse.de> Ok, what about providing a default implementation in Java? The RXTXCommDriver would call a (native) function useNativeLocking and if it returns true, call the native functions for lock() isLocked (), unlock(), else is would use the Java based default implementation. This could possibly be overriden by a property (again for debugging). Joachim On 20.03.2006, at 20:21, Trent Jarvi wrote: > On Mon, 20 Mar 2006, Joachim Buechse wrote: > >> Hi Trent, >> >> What is your general feeling about moving code to Java? The last >> days I have been reading quite a bit of the code and there are >> several things, that might not work as expected. >> >> I'll give you two examples from is_device_locked: >> >> if LOCKDIR == /var/spool/locks the directory /var/spool/lock will >> not be checked. >> LOCKDIR is not checked for lockfiles with unexpected pefixes >> >> While these things have probably never been discovered in >> production, they are still possibly incorrect implementations. If >> it was Java code, I would write some unit tests producing the >> errors that could later be corrected. >> >> PS: One could imagine to actually implement the whole lockfile >> handling in Java using some native routines to get the values >> required (pid, st_dev, st_rdev, ...). > > Hi Joachim > > I like the idea of moving more of the code into java but there are > some things to consider. > > If you break this into multiple JNI calls, the performance will > drop considerably during enumeration of ports. We are looking for > 256 ports per dev type vs (16? in Sun's 2.0 and fewer types). Its > hard to make assumptions. I've seen virtual ports start at /dev/ > foo100 for instance. > > It works out to over 7500 ports on Linux if you enable them all. > We already trim that back by default. See Linux-all-ports in > RXTXCommDriver.java. > > There are also native libraries that rxtx can link to. If you move > too much into Java, linking to 'standard' libraries with distros > will break. "configure --enable-liblock=yes" will not be doable. > This is probably a favorable way with RedHat, Debian, Suse and > others. Thats the right thing to do if there will be rpms, dpkg, .. > > For those reasons, I think it still make sense to keep it to a > minimal ~3 calls to JNI code that we can use for speed and > versatility. lock() isLocked(), unlock() perhaps. When I say > speed, its more about avoiding crossing the JNI layer multiple > times than java vs C performance. With versatility I think liblock > is the right way for most but not all (embeded) linux distros. > > -- > Trent Jarvi > tjarvi at qbang.org > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Mon Mar 20 12:44:47 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 20 Mar 2006 12:44:47 -0700 (MST) Subject: [Rxtx] BUG: Lock file stays even if port opening fails In-Reply-To: <82C19FE7-DDCB-45B6-B2C9-7606B66F0124@buechse.de> References: <82C19FE7-DDCB-45B6-B2C9-7606B66F0124@buechse.de> Message-ID: On Mon, 20 Mar 2006, Joachim Buechse wrote: > Ok, what about providing a default implementation in Java? > > The RXTXCommDriver would call a (native) function useNativeLocking and if > it returns true, call the native functions for lock() isLocked(), > unlock(), else is would use the Java based default implementation. This > could possibly be overriden by a property (again for debugging). > Hi Joachim That would be OK with me. -- Trent Jarvi tjarvi at qbang.org From dmarkman at mac.com Mon Mar 20 22:27:45 2006 From: dmarkman at mac.com (Dmitry Markman) Date: Tue, 21 Mar 2006 00:27:45 -0500 Subject: [Rxtx] binaries request Message-ID: <42702213-C222-4937-A585-7CFB17E47608@mac.com> Hi can somebody send me latest linux and windows binaries, please? or where I can find them (I didn't find them in the latest tareball) I gave up with my cygwin: something wrong I have no idea what java doesn't understand /cygwin/c syntax after I changed makefile it did java part but after that gcc 3.4.4 started to complain I set buffer length to 999 lines but I didn't get beginning of the story something wrong with my 1.4.2_09/include/jni.h gcc doesn't like it anyway I gave up thanks in advance Dmitry Markman -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060320/f8cbc57c/attachment-0048.html From tjarvi at qbang.org Mon Mar 20 22:36:48 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 20 Mar 2006 22:36:48 -0700 (MST) Subject: [Rxtx] binaries request In-Reply-To: <42702213-C222-4937-A585-7CFB17E47608@mac.com> References: <42702213-C222-4937-A585-7CFB17E47608@mac.com> Message-ID: On Tue, 21 Mar 2006, Dmitry Markman wrote: > Hi > can somebody send me latest linux and windows binaries, please? > > or where I can find them (I didn't find them in the latest tareball) > > I gave up with my cygwin: something wrong I have no idea what > java doesn't understand /cygwin/c syntax > after I changed makefile it did java part > but after that gcc 3.4.4 started to complain > I set buffer length to 999 lines but I didn't get beginning of the story > something wrong with my 1.4.2_09/include/jni.h gcc doesn't like it > anyway I gave up > > thanks in advance > Hi Dmitry The bins are here: ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7-bins-r2.zip Here are the files in the zip you want. Jar: rxtx-2.1-7-bins-r2/RXTXcomm.jar Windows: rxtx-2.1-7-bins-r2/Windows/i368-mingw32/rxtxSerial.dll Linux (x86) rxtx-2.1-7-bins-r2/Linux/i686-unknown-linux-gnu/librxtxSerial.so There are others in there including Parallel port support but those are the main ones for testing. -- Trent Jarvi tjarvi at qbang.org From dmarkman at mac.com Mon Mar 20 23:05:59 2006 From: dmarkman at mac.com (Dmitry Markman) Date: Tue, 21 Mar 2006 01:05:59 -0500 Subject: [Rxtx] binaries request In-Reply-To: References: <42702213-C222-4937-A585-7CFB17E47608@mac.com> Message-ID: thank you very much but windows's readme says: rxtxSerial.dll had to be recomopiled to link in missing native methods. should I ignore it? or what? thanks again also I understand that I should use mingw not cygwin I'll try to install mingw On Mar 21, 2006, at 12:36 AM, Trent Jarvi wrote: > On Tue, 21 Mar 2006, Dmitry Markman wrote: > >> Hi >> can somebody send me latest linux and windows binaries, please? >> >> or where I can find them (I didn't find them in the latest tareball) >> >> I gave up with my cygwin: something wrong I have no idea what >> java doesn't understand /cygwin/c syntax >> after I changed makefile it did java part >> but after that gcc 3.4.4 started to complain >> I set buffer length to 999 lines but I didn't get beginning of the >> story >> something wrong with my 1.4.2_09/include/jni.h gcc doesn't like it >> anyway I gave up >> >> thanks in advance >> > > Hi Dmitry > > The bins are here: > > ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7-bins-r2.zip > > Here are the files in the zip you want. > > Jar: > > rxtx-2.1-7-bins-r2/RXTXcomm.jar > > Windows: > > rxtx-2.1-7-bins-r2/Windows/i368-mingw32/rxtxSerial.dll > > Linux (x86) > > rxtx-2.1-7-bins-r2/Linux/i686-unknown-linux-gnu/librxtxSerial.so > > There are others in there including Parallel port support but those > are the main ones for testing. > > -- > Trent Jarvi > tjarvi at qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx Dmitry Markman From tjarvi at qbang.org Mon Mar 20 23:20:33 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 20 Mar 2006 23:20:33 -0700 (MST) Subject: [Rxtx] binaries request In-Reply-To: References: <42702213-C222-4937-A585-7CFB17E47608@mac.com> Message-ID: On Tue, 21 Mar 2006, Dmitry Markman wrote: > thank you very much > > but windows's readme says: > rxtxSerial.dll had to be recomopiled to link in missing native methods. > > should I ignore it? or what? > Hi Dmitry That dll should be OK. r2 is the recompile linked to the missing native method. The readme explains why it was recompiled; fuser.o was not linked into the dll in the first release. -- Trent Jarvi tjarvi at qbang.org From ariantristan at yahoo.com Mon Mar 20 23:55:24 2006 From: ariantristan at yahoo.com (Lambok Sianturi) Date: Mon, 20 Mar 2006 22:55:24 -0800 (PST) Subject: [Rxtx] jvm issue Message-ID: <20060321065524.94779.qmail@web50701.mail.yahoo.com> Hi All, This is my first time to join RxTx mailing list. I thank you all for allowing others to sign in in requests help. I use the latest RxTx lib in Fedora 3 with java version 1.4.2_09 b05. And I got this error: # # An unexpected error has been detected by HotSpot Virtual Machine: # # SIGSEGV (0xb) at pc=0x00bf27f3, pid=2633, tid=3086112448 # # Java VM: Java HotSpot(TM) Client VM (1.4.2_09-b05 mixed mode) # Problematic frame: # C [ld-linux.so.2+0xa7f3] # # An error report file with more information is saved as hs_err_pid2633.log # # If you would like to submit a bug report, please visit: # http://java.sun.com/webapps/bugreport/crash.jsp # ./run.sh: line 3: 2633 Aborted /usr/local/java/bin/java -Djava.library.path=/usr/local/java/jre/lib/ -Djsmsengine.debug=true -classpath jsmsengine.jar:smsgateway.jar:classes12.jar:RXTXcomm.jar:. com.api.sms.SMSServer What is the jvm depedency for the latest library? Can I use 1.4.2_09 b05? Thanks in advance. Arian --------------------------------- Yahoo! Mail Use Photomail to share photos without annoying attachments. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060320/83d58dd7/attachment-0048.html From f.frumento at ngi.it Tue Mar 21 00:21:47 2006 From: f.frumento at ngi.it (Fabio Frumento) Date: Tue, 21 Mar 2006 08:21:47 +0100 Subject: [Rxtx] Javadoc on the go Message-ID: <441FA98B.9050701@ngi.it> Hi Trent, sorry for the big delay but my job is running wild, i was out for some time but now i'm back and ready to continue the javadoc for Rxtx. Did you used the last javadoc patch i sent you ? let me know if i have to send it to you again or not. regards Fabio From lyon at docjava.com Tue Mar 21 00:51:18 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Tue, 21 Mar 2006 02:51:18 -0500 Subject: [Rxtx] lock files Message-ID: Hi All, You know, if the use of lock files were under Java control (rather than a build-time decision), it might enable a more unified binary distro. It might also facilitate quick prototyping of non-lock file approaches to resolving serial port contention issues (i.e., mac-like approaches vs. linux approaches, etc.). I realize that this is a radical overhaul of the lock file policy issue. Also, it may harm performance. On the other hand, our benchmarks on JNI overhead for modern processors indicate performance impact should be minimal. Perhaps it is more of an issue with the toybox systems. Suppose there were a class with a reasonable default...someone might write: SerialPortLockPolicy.setPolicy(SerialPortLockPolicy.UNIX_LOCK_FILE); SerialPortLockPolicy.setPolicy(SerialPortLockPolicy.NO_LOCK_CHECKING); SerialPortLockPolicy.setPolicy(SerialPortLockPolicy.MAC_STYLE); Thus, we could have a run-time reconfiguration of the serial port lock policy. A special NO_LOCK version of the binary would no longer be required. Any thoughts on this? Thanks! - Doug From joachim at buechse.de Tue Mar 21 03:09:09 2006 From: joachim at buechse.de (Joachim Buechse) Date: Tue, 21 Mar 2006 11:09:09 +0100 Subject: [Rxtx] lock files In-Reply-To: References: Message-ID: <8E12916A-1B9A-4FF2-B684-E2D1C794221B@buechse.de> This is pretty much what I thought about when I suggested, that the default behaviour could be overwritten with a property. I am very much in favor of this approach. In particular this allows much easier debugging for PC based java developers. I think big parts of the Java (and maybe some parts of the C code) could use a bit of a structural workover (unit tests, javadoc, synchronization, etc). Maybe there should be a CVS branch for this experimental version. I'd be happy to contribute a first workover for some of the Java code. Designing for testability and implementing a good bunch of unit tests has been a strategy that worked quite well in the Java projects I lead. And it ultimately allows more liberal change permission. Regards, Joachim On 21.03.2006, at 08:51, Dr. Douglas Lyon wrote: > Hi All, > You know, if the use of lock files were > under Java control (rather than a build-time decision), > it might enable a more unified binary distro. It might also > facilitate quick prototyping of non-lock file approaches > to resolving serial port contention issues (i.e., mac-like > approaches vs. linux approaches, etc.). > > I realize that this is a radical overhaul of the lock file policy > issue. Also, it may harm performance. On the other hand, > our benchmarks on JNI overhead for modern processors indicate > performance impact should be minimal. Perhaps it is more of > an issue with the toybox systems. > > Suppose there were a class with a reasonable default...someone > might write: > SerialPortLockPolicy.setPolicy(SerialPortLockPolicy.UNIX_LOCK_FILE); > SerialPortLockPolicy.setPolicy(SerialPortLockPolicy.NO_LOCK_CHECKING); > SerialPortLockPolicy.setPolicy(SerialPortLockPolicy.MAC_STYLE); > > Thus, we could have a run-time reconfiguration of the serial port lock > policy. A special NO_LOCK version of the binary would no longer > be required. > > Any thoughts on this? > > Thanks! > - Doug > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From joachim at buechse.de Tue Mar 21 06:23:08 2006 From: joachim at buechse.de (Joachim Buechse) Date: Tue, 21 Mar 2006 14:23:08 +0100 Subject: [Rxtx] PATCH: use of ioctl(fd, TIOCEXCL) instead of lockfiles Message-ID: <923AE774-EEA2-4911-92D8-32BB27802C8B@buechse.de> Here is the patch for the ioctl(fd, TIOCEXCL). I have verified this only for OSX 10.4.5, hence it is only defined for APPLE. However, it should work at least for Solaris as well. If a process has requested TIOEXCL further open calls by other user processes will fail. The patch also disables uucp style locking for APPLE. Obviously this is discussable. I think it is the way to go, as it eliminates creating the lock directory which doesnt exist on the standard installation and it eliminates messing with the system group definitions (adding users to group uucp). Regarding the possibility of root processes opening a device which is locked - I consider this a feature not a potential problem. It is highly unlikely, that somebody is crazy enough to run a JavaVM as root (unless he has no other means of getting a restricted IP port opened, ie doesnt understand ipfw). Anyway, even if the process runs as root, it fails when calling ioctl(fd, TIOCEXCL). It could however still open the port to listen for RING events. I.e. a fax server which needs to see incoming calls but otherwise doesnt want to block the port. So the only case where the proposed mechanism fails is, if an incorrectly implemented process running as root conflicts with a user process. I think this can be accepted. Regards, Joachim PS: If this patch is generally accepted, the installer and Mac doku should obviously be changed as well. Index: SerialImp.c =================================================================== RCS file: /usr/local/cvsroot/rxtx-devel/src/SerialImp.c,v retrieving revision 1.46.2.187 diff -u -r1.46.2.187 SerialImp.c --- SerialImp.c 29 Jan 2006 22:19:04 -0000 1.46.2.187 +++ SerialImp.c 21 Mar 2006 12:59:16 -0000 @@ -656,6 +656,25 @@ fd=OPEN (filename, O_RDWR | O_NOCTTY | O_NONBLOCK ); } while (fd < 0 && errno==EINTR); +#ifdef OPEN_EXCL + // Note that open() follows POSIX semantics: multiple open() calls to + // the same file will succeed unless the TIOCEXCL ioctl is issued. + // This will prevent additional opens except by root-owned processes. + // See tty(4) ("man 4 tty") and ioctl(2) ("man 2 ioctl") for details. + + if (fd >= 0 && (ioctl(fd, TIOCEXCL) == -1)) + { + sprintf( message, "open: exclusive access denied for % s\n", + filename ); + report( message ); + report_error( message ); + + close(fd); + goto fail; + } +#endif /* OPEN_EXCL */ + + if( configure_port( fd ) ) goto fail; (*env)->ReleaseStringUTFChars( env, jstr, filename ); sprintf( message, "open: fd returned is %i\n", fd ); Index: SerialImp.h =================================================================== RCS file: /usr/local/cvsroot/rxtx-devel/src/SerialImp.h,v retrieving revision 1.11.2.49 diff -u -r1.11.2.49 SerialImp.h --- SerialImp.h 5 Jul 2005 17:47:21 -0000 1.11.2.49 +++ SerialImp.h 21 Mar 2006 12:59:17 -0000 @@ -135,7 +135,8 @@ /*# define LOCKDIR "/var/spool/uucp"*/ # define LOCKDIR "/var/lock" # define LOCKFILEPREFIX "LK." -# define UUCP +/*# define UUCP*/ +# define OPEN_EXCL #endif /* __APPLE__ */ #if defined(__NetBSD__) # define DEVICEDIR "/dev/" From tjarvi at qbang.org Tue Mar 21 10:26:08 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 21 Mar 2006 10:26:08 -0700 (MST) Subject: [Rxtx] Javadoc on the go In-Reply-To: <441FA98B.9050701@ngi.it> References: <441FA98B.9050701@ngi.it> Message-ID: On Tue, 21 Mar 2006, Fabio Frumento wrote: > Hi Trent, > > sorry for the big delay but my job is running wild, i was out for some > time but now i'm back and ready to continue the javadoc for Rxtx. > > Did you used the last javadoc patch i sent you ? let me know if i have to > send it to you again or not. > > regards > > Fabio Hi Fabio The patch is in the rxtx mail-list archives. It will be going in soon. I did not see a time critical portion. I'll probably be going through the list since the last batch of patches this weekend and putting them into CVS. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Tue Mar 21 10:57:18 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 21 Mar 2006 10:57:18 -0700 (MST) Subject: [Rxtx] jvm issue In-Reply-To: <20060321065524.94779.qmail@web50701.mail.yahoo.com> References: <20060321065524.94779.qmail@web50701.mail.yahoo.com> Message-ID: On Mon, 20 Mar 2006, Lambok Sianturi wrote: > Hi All, > This is my first time to join RxTx mailing list. I thank you all for allowing others to sign in in requests help. > I use the latest RxTx lib in Fedora 3 with java version 1.4.2_09 b05. And I got this error: > > # > # An unexpected error has been detected by HotSpot Virtual Machine: > # > # SIGSEGV (0xb) at pc=0x00bf27f3, pid=2633, tid=3086112448 > # > # Java VM: Java HotSpot(TM) Client VM (1.4.2_09-b05 mixed mode) > # Problematic frame: > # C [ld-linux.so.2+0xa7f3] A native library loading error? What happens if you recompile rxtx on your system and install that? This sounds like an ABI problem? rxtx 2.1-7 was compiled with a gcc 2.96 toolchain as I recall. The hope is newer system will be backwards compatible. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Tue Mar 21 11:05:29 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 21 Mar 2006 11:05:29 -0700 (MST) Subject: [Rxtx] PATCH: use of ioctl(fd, TIOCEXCL) instead of lockfiles In-Reply-To: <923AE774-EEA2-4911-92D8-32BB27802C8B@buechse.de> References: <923AE774-EEA2-4911-92D8-32BB27802C8B@buechse.de> Message-ID: On Tue, 21 Mar 2006, Joachim Buechse wrote: > Here is the patch for the ioctl(fd, TIOCEXCL). I have verified this only > for OSX 10.4.5, hence it is only defined for APPLE. However, it should > work at least for Solaris as well. > > If a process has requested TIOEXCL further open calls by other user > processes will fail. > > The patch also disables uucp style locking for APPLE. Obviously this is > discussable. I think it is the way to go, as it eliminates creating the > lock directory which doesnt exist on the standard installation and it > eliminates messing with the system group definitions (adding users to > group uucp). > > Regarding the possibility of root processes opening a device which is > locked - I consider this a feature not a potential problem. It is highly > unlikely, that somebody is crazy enough to run a JavaVM as root (unless > he has no other means of getting a restricted IP port opened, ie doesnt > understand ipfw). Anyway, even if the process runs as root, it fails when > calling ioctl(fd, TIOCEXCL). It could however still open the port to > listen for RING events. I.e. a fax server which needs to see incoming > calls but otherwise doesnt want to block the port. So the only case where > the proposed mechanism fails is, if an incorrectly implemented process > running as root conflicts with a user process. I think this can be > accepted. > > Regards, > Joachim > > PS: If this patch is generally accepted, the installer and Mac doku > should obviously be changed as well. > > > Index: SerialImp.c > =================================================================== > RCS file: /usr/local/cvsroot/rxtx-devel/src/SerialImp.c,v > retrieving revision 1.46.2.187 > diff -u -r1.46.2.187 SerialImp.c > --- SerialImp.c 29 Jan 2006 22:19:04 -0000 1.46.2.187 > +++ SerialImp.c 21 Mar 2006 12:59:16 -0000 > @@ -656,6 +656,25 @@ > fd=OPEN (filename, O_RDWR | O_NOCTTY | O_NONBLOCK ); > } while (fd < 0 && errno==EINTR); > > +#ifdef OPEN_EXCL > + // Note that open() follows POSIX semantics: multiple open() > calls to > + // the same file will succeed unless the TIOCEXCL ioctl is > issued. > + // This will prevent additional opens except by root-owned > processes. > + // See tty(4) ("man 4 tty") and ioctl(2) ("man 2 ioctl") for > details. > + > + if (fd >= 0 && (ioctl(fd, TIOCEXCL) == -1)) > + { > + sprintf( message, "open: exclusive access denied for % > s\n", > + filename ); > + report( message ); > + report_error( message ); > + > + close(fd); > + goto fail; > + } > +#endif /* OPEN_EXCL */ > + > + > if( configure_port( fd ) ) goto fail; > (*env)->ReleaseStringUTFChars( env, jstr, filename ); > sprintf( message, "open: fd returned is %i\n", fd ); > Index: SerialImp.h > =================================================================== > RCS file: /usr/local/cvsroot/rxtx-devel/src/SerialImp.h,v > retrieving revision 1.11.2.49 > diff -u -r1.11.2.49 SerialImp.h > --- SerialImp.h 5 Jul 2005 17:47:21 -0000 1.11.2.49 > +++ SerialImp.h 21 Mar 2006 12:59:17 -0000 > @@ -135,7 +135,8 @@ > /*# define LOCKDIR "/var/spool/uucp"*/ > # define LOCKDIR "/var/lock" > # define LOCKFILEPREFIX "LK." > -# define UUCP > +/*# define UUCP*/ > +# define OPEN_EXCL > #endif /* __APPLE__ */ > #if defined(__NetBSD__) > # define DEVICEDIR "/dev/" > This looks like a good start. What do you think Dmitry? Perhaps all systems with TIOCEXCL defined should use that though. Even if they use lockfiles. It wont hurt anything. That would catch people hacking their own serial apps without checking lockfiles. Its a good idea to avoid C++ style comments in the C portions. Some older systems don't deal with them well. If it's just for Mac OS X, it isn't a big deal. I think it was the Irix compiler that was problematic? -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Tue Mar 21 11:22:05 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 21 Mar 2006 11:22:05 -0700 (MST) Subject: [Rxtx] lock files In-Reply-To: <8E12916A-1B9A-4FF2-B684-E2D1C794221B@buechse.de> References: <8E12916A-1B9A-4FF2-B684-E2D1C794221B@buechse.de> Message-ID: We can try it. Maybe the JNI is much improved. The nice thing about linking into liblock is distros then worry about lockfiles on their systems. This way, we have to deal with any changes that may show up. On Tue, 21 Mar 2006, Joachim Buechse wrote: > This is pretty much what I thought about when I suggested, that the > default behaviour could be overwritten with a property. I am very much in > favor of this approach. In particular this allows much easier debugging > for PC based java developers. > > I think big parts of the Java (and maybe some parts of the C code) could > use a bit of a structural workover (unit tests, javadoc, synchronization, > etc). Maybe there should be a CVS branch for this experimental version. > I'd be happy to contribute a first workover for some of the Java code. > Designing for testability and implementing a good bunch of unit tests has > been a strategy that worked quite well in the Java projects I lead. And > it ultimately allows more liberal change permission. > > Regards, > Joachim > > > On 21.03.2006, at 08:51, Dr. Douglas Lyon wrote: > >> Hi All, >> You know, if the use of lock files were >> under Java control (rather than a build-time decision), >> it might enable a more unified binary distro. It might also >> facilitate quick prototyping of non-lock file approaches >> to resolving serial port contention issues (i.e., mac-like >> approaches vs. linux approaches, etc.). >> >> I realize that this is a radical overhaul of the lock file policy >> issue. Also, it may harm performance. On the other hand, >> our benchmarks on JNI overhead for modern processors indicate >> performance impact should be minimal. Perhaps it is more of >> an issue with the toybox systems. >> >> Suppose there were a class with a reasonable default...someone >> might write: >> SerialPortLockPolicy.setPolicy(SerialPortLockPolicy.UNIX_LOCK_FILE); >> SerialPortLockPolicy.setPolicy(SerialPortLockPolicy.NO_LOCK_CHECKING); >> SerialPortLockPolicy.setPolicy(SerialPortLockPolicy.MAC_STYLE); >> >> Thus, we could have a run-time reconfiguration of the serial port lock >> policy. A special NO_LOCK version of the binary would no longer >> be required. >> >> Any thoughts on this? >> >> Thanks! >> - Doug >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From dmarkman at mac.com Tue Mar 21 16:05:17 2006 From: dmarkman at mac.com (Dmitry Markman) Date: Tue, 21 Mar 2006 18:05:17 -0500 Subject: [Rxtx] PATCH: use of ioctl(fd, TIOCEXCL) instead of lockfiles In-Reply-To: References: <923AE774-EEA2-4911-92D8-32BB27802C8B@buechse.de> Message-ID: <512AC70C-BB86-48F2-A83C-023F35C23BAB@mac.com> I think it's cool, but I'd like to have that property implementation when user can choose between locking mechanism about comments: it's easy to change comments to the C style or we can use extensions of the file to cpp so c++ compiler will be used On Mar 21, 2006, at 1:05 PM, Trent Jarvi wrote: > This looks like a good start. What do you think Dmitry? Perhaps > all systems with TIOCEXCL defined should use that though. Even if > they use lockfiles. It wont hurt anything. That would catch > people hacking their own serial apps without checking lockfiles. > > Its a good idea to avoid C++ style comments in the C portions. > Some older systems don't deal with them well. If it's just for Mac > OS X, it isn't a big deal. I think it was the Irix compiler that > was problematic? Dmitry Markman From dmarkman at mac.com Tue Mar 21 16:13:00 2006 From: dmarkman at mac.com (Dmitry Markman) Date: Tue, 21 Mar 2006 18:13:00 -0500 Subject: [Rxtx] PATCH: use of ioctl(fd, TIOCEXCL) instead of lockfiles In-Reply-To: References: <923AE774-EEA2-4911-92D8-32BB27802C8B@buechse.de> Message-ID: I'd like to add that creating locking folder isn't a big deal we never had a problem related to the lock folders, because we always used installer on mac os x from other hand I'm not very much familiar with iotcl locking approach and I'm not sure it's more efficient Joachim wrote "I think it is the way to go, as it eliminates creating the lock directory which doesnt exist on the standard installation and it eliminates messing with the system group definitions (adding users to group uucp)." but I really didn't have any problem with that 1. doesn't exist on the standard installation there are many-many things that don't exist in the standard installation so I don't think that argument is strong enough 2. messing with the system group definitions I don't think we're messing with the group definition mac os x provides very clear way to set up group's members and together with Greg Guerin AuthKit there is no problem to set those definitions so I don't think that argument is strong either but from other hand using iotcl is more promising and is more elegant On Mar 21, 2006, at 1:05 PM, Trent Jarvi wrote: > > This looks like a good start. What do you think Dmitry? Perhaps > all systems with TIOCEXCL defined should use that though. Even if > they use lockfiles. It wont hurt anything. That would catch > people hacking their own serial apps without checking lockfiles. Dmitry Markman From joachim at buechse.de Wed Mar 22 04:46:45 2006 From: joachim at buechse.de (Joachim Buechse) Date: Wed, 22 Mar 2006 12:46:45 +0100 Subject: [Rxtx] PATCH: use of ioctl(fd, TIOCEXCL) instead of lockfiles In-Reply-To: References: <923AE774-EEA2-4911-92D8-32BB27802C8B@buechse.de> Message-ID: Sorry, I was not very clear with my arguments, so I will try again;-) Please, don't take this as an attack against work that has been done. I think the contributions that have been made in the past were made in a good spirit. But I really believe, that the current solution for OSX has many shortcomings and should be changed as soon as possible. lock files --- The /var/lock folder does not exist on the standard OSX installation, however the standard installation includes several applications that use serial ports (i.e. the FAX capability). This indicates, that the lock folder approach will not work well with system components. Applications for OSX will generally try to live in harmony with system components (except for HP print drivers of course). I think RXTX should follow this approach as well. uucp group --- Accessing serial ports is not an admin privileged operation on OSX. Any user (world) has read/write privileges on /dev/tty*. So the system default is to not enforce any group membership to access these ports. The group uucp however is a system group on all unix systems I know. It exists for certain system processes. A non admin user should in general not be a member of this group. Quite arguably no user should ever be a member of this group. Installer --- My general opinion is, that - no Installer should touch user or group data without warning - no Application Installer should touch groups which are not specific to the very application installed - no Installer should ever add regular users to a system group The current installer injects the installing user in the group uucp without warning about this change and without giving the option to "opt out" of this change. This is a potential security risk (but not currently a real one, as OSX contains no folders belonging to group uucp). The current installer does not work for multi user systems. It puts the installing user in the uucp group. However the installing user is not necessarily the user that will use the application. Putting all users that may use a serial port application in the system group uucp seems like a very invasive approach to me. Besides that, newly created users will not automatically be in the group and hence, serial applications will "break" for new users without obvious reasons. Avoiding the lock files will allow self contained applications (i.e. drag&drop installation). In my eyes this is largely preferable over an installer that requests admin privileges. Adding up all these points indicates very strongly, that the lock-file implementation is not the way to go on OSX. Regards, Joachim On 22.03.2006, at 00:13, Dmitry Markman wrote: > I'd like to add that > > creating locking folder isn't a big deal > we never had a problem related to the lock folders, because we > always used installer on mac os x > from other hand I'm not very much familiar with iotcl locking > approach and I'm not sure it's more efficient > > Joachim wrote "I think it is the way to go, as it eliminates > creating the lock directory which doesnt exist on the standard > installation and it eliminates messing with the system group > definitions (adding users to group uucp)." but I really didn't have > any problem with that > > 1. doesn't exist on the standard installation > there are many-many things that don't exist in the standard > installation so I don't think that argument is strong enough > 2. messing with the system group definitions > I don't think we're messing with the group definition > mac os x provides very clear way to set up group's members and > together with Greg Guerin AuthKit there is no problem to set those > definitions > so I don't think that argument is strong either > but from other hand using iotcl is more promising and is more elegant > > > > On Mar 21, 2006, at 1:05 PM, Trent Jarvi wrote: > >> >> This looks like a good start. What do you think Dmitry? Perhaps >> all systems with TIOCEXCL defined should use that though. Even if >> they use lockfiles. It wont hurt anything. That would catch >> people hacking their own serial apps without checking lockfiles. > > Dmitry Markman > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From dmarkman at mac.com Wed Mar 22 05:27:13 2006 From: dmarkman at mac.com (Dmitry Markman) Date: Wed, 22 Mar 2006 07:27:13 -0500 Subject: [Rxtx] PATCH: use of ioctl(fd, TIOCEXCL) instead of lockfiles In-Reply-To: References: <923AE774-EEA2-4911-92D8-32BB27802C8B@buechse.de> Message-ID: <83440CF3-DCD8-41C1-B941-F227232C27E3@mac.com> thanks for the very good explanation I didn't think that you were attacking any thing, so don't worry I just had feeling, that there were more aesthetic reasons for going to ioctl then real necessity now you explained everything quite well (BTW, asfar as I remember installer asks admin password so it wasn't quiet, but it really doesn't matter now) thanks On Mar 22, 2006, at 6:46 AM, Joachim Buechse wrote: > Sorry, I was not very clear with my arguments, so I will try again;-) > > Please, don't take this as an attack against work that has been > done. I think the contributions that have been made in the past > were made in a good spirit. But I really believe, that the current > solution for OSX has many shortcomings and should be changed as > soon as possible. > > lock files > --- > The /var/lock folder does not exist on the standard OSX > installation, however the standard installation includes several > applications that use serial ports (i.e. the FAX capability). This > indicates, that the lock folder approach will not work well with > system components. Applications for OSX will generally try to live > in harmony with system components (except for HP print drivers of > course). I think RXTX should follow this approach as well. > > uucp group > --- > Accessing serial ports is not an admin privileged operation on OSX. > Any user (world) has read/write privileges on /dev/tty*. So the > system default is to not enforce any group membership to access > these ports. The group uucp however is a system group on all unix > systems I know. It exists for certain system processes. A non admin > user should in general not be a member of this group. Quite > arguably no user should ever be a member of this group. > > Installer > --- > My general opinion is, that > - no Installer should touch user or group data without warning > - no Application Installer should touch groups which are not > specific to the very application installed > - no Installer should ever add regular users to a system group > > The current installer injects the installing user in the group uucp > without warning about this change and without giving the option to > "opt out" of this change. This is a potential security risk (but > not currently a real one, as OSX contains no folders belonging to > group uucp). > > The current installer does not work for multi user systems. It puts > the installing user in the uucp group. However the installing user > is not necessarily the user that will use the application. Putting > all users that may use a serial port application in the system > group uucp seems like a very invasive approach to me. Besides that, > newly created users will not automatically be in the group and > hence, serial applications will "break" for new users without > obvious reasons. > > > Avoiding the lock files will allow self contained applications > (i.e. drag&drop installation). In my eyes this is largely > preferable over an installer that requests admin privileges. Adding > up all these points indicates very strongly, that the lock-file > implementation is not the way to go on OSX. > > Regards, > Joachim > > > On 22.03.2006, at 00:13, Dmitry Markman wrote: > >> I'd like to add that >> >> creating locking folder isn't a big deal >> we never had a problem related to the lock folders, because we >> always used installer on mac os x >> from other hand I'm not very much familiar with iotcl locking >> approach and I'm not sure it's more efficient >> >> Joachim wrote "I think it is the way to go, as it eliminates >> creating the lock directory which doesnt exist on the standard >> installation and it eliminates messing with the system group >> definitions (adding users to group uucp)." but I really didn't >> have any problem with that >> >> 1. doesn't exist on the standard installation >> there are many-many things that don't exist in the standard >> installation so I don't think that argument is strong enough >> 2. messing with the system group definitions >> I don't think we're messing with the group definition >> mac os x provides very clear way to set up group's members and >> together with Greg Guerin AuthKit there is no problem to set those >> definitions >> so I don't think that argument is strong either >> but from other hand using iotcl is more promising and is more elegant >> >> >> >> On Mar 21, 2006, at 1:05 PM, Trent Jarvi wrote: >> >>> >>> This looks like a good start. What do you think Dmitry? Perhaps >>> all systems with TIOCEXCL defined should use that though. Even >>> if they use lockfiles. It wont hurt anything. That would catch >>> people hacking their own serial apps without checking lockfiles. >> >> Dmitry Markman >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx Dmitry Markman From lyon at docjava.com Wed Mar 22 06:12:18 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Wed, 22 Mar 2006 08:12:18 -0500 Subject: [Rxtx] sole of a new design pattern Message-ID: Hi All, I have been thinking about how we design the serial port software. I think we need a new design pattern. For lack of a better term, I shall call it: The Parametric Singleton Design Pattern By Douglas A. Lyon ABSTRACT The goal of the singleton design pattern is to make sure that there is one, and only one, instance of a given class. The goal of the parametric singleton design pattern is to make sure that there is one, and only one, instance of a given class with the given parametric values. We parametric singleton design pattern combines the singleton design pattern with a parameter that enables unique creation of instances of a class. These instances are cached. When a user asks for an instance with these parameters, the cache is checked. If the instance is in the cache, the instance is returned, otherwise it is created, added to the cache and then returned. We apply our parametric singleton design pattern to the retrieval of RMI registries bound to a given port. The goal of our system is to make sure that no two RMI registries are listening to the same socket and to make use of the RMI registries after they have been created. RMI registries are used in distributed computation. Introduction The singleton design pattern is meant to ensure that on a single instance of a class exists. It is also meant to provide a global point of access to it. The intent of the parametric singleton design pattern is to ensure that a class has only one instance for a given set of parameter values. It also provides a global point of access to it. Motivation A system cannot tolerate multiple instances of some classes with identical parameters. For example, you cannot have two instances making use of the same serial port, at the same time. You cannot have two instances that are trying to listen to the same socket connection. You cannot have two instances writing to the same file structure at the same time. As the operating system is often thought of as the arbiter of consumed resources (i.e., tape drives, serial ports, etc.) we frequently leave it to an operating system implementation to resolve these contention issues. Even for similar resources (like serial ports) there are few standards for handling contention. For example, serial ports on Linux are locked using a "/var/lock" file. POSIX, on the other hand, uses ioctl mechanisms to prevent contention. A better solution is to make a class that is responsible for keeping track of the instances created from the class. The class is declared final, so that it cannot be subclassed. The class also has a private constructor, so that other classes cannot instance it. The new design pattern is called the parametric singleton design pattern and it provides a way to access and create instances with given parameters. Applicability Use the Parametric Singleton Design Pattern when: 1. There must be exactly one instance of a class with the given parameters. 2. The instances must be accessible to clients from a well-known access point. Structure Insert UML diagram here. Participants The Parametric Singleton Clients that need instances 1. The Parametric Singleton defines an instance upon request from a client, if, and only if, the instance does not already exist. 2. The Parametric Singleton returns the instance to the client. 3. The Parametric Singleton is responsible for creating unique instances from given parameters. Collaborations Clients obtain a reference to a Parametric Singleton instance only through the parametric singleton design pattern. If the instance is left in an improper state (e.g., the serial port was left open) it is NOT the role of the Parametric Singleton Design Pattern to close the IO port. Nor is it the role of the Parametric Singleton Design Pattern to open the port. That role is delegate to some other part of the system. Further, it is not the role of the Parametric Singleton Design Pattern to check out resources. That is, multiple threads can have multiple references to the same resource at the same time. MUTEX locking is delegated to some other part of the system. Consequences The Parametric Singleton Design Pattern has several benefits: 1. Controlled access to parametrically defined instances. Since the Parametric Singleton class encapsulates its instances, there is control over how and when clients access it. 2. Reduced name space. The Parametric Singleton pattern avoids global variables that store instances created from the same parameter. Implementation Here are implementation issues to consider when using the Parametric Singleton pattern: 1. Unique mapping of parameters. The Parametric Singleton pattern requires that there be a mean to isomorphically map the parameter space into the instance space and back again. 2. Ensure unique instances. The Parametric Singleton pattern makes unique instances from parameters, and it does so only once. 3. Cache instances for fast retrieval. The Parametric Singleton pattern must be able to look up instances, given some set of parameters, and do so from some data structure. That is, there must be enough space to hold references to all the instances the program will need. Also, a mechanism is needed to look up and retrieve the instances quickly enough to satisfy the clients. Sample Code public final class ParametricSingletonRmiRegistry { private static Hashtable registry = new Hashtable(100); // use singleton pattern and??????????????????????????????????????????????? // prevent instantiation of RmiRegistryUtils.?????????????????????????????? private ParametricSingletonRmiRegistry() { } // the only instance of the Registry held by the RmiRegistryUtils?????????? public static void listNames(Integer port) { if (!isInCacheAndRunning(port)) return; Registry r = (Registry) registry.get(port); System.out.println("registry on port: " + port); System.out.println("registry: " + r); System.out.println("names: "); try { print(r.list()); } catch (RemoteException e) { In.message(e); } System.out.println("------------------------"); } /**???????????????????????????????????????????????????????????????????????? * Checks whether a Registry has been started on this host????????????????? * in the specified port.?????????????????????????????????????????????????? * If not, it tries to start one.?????????????????????????????????????????? * when it fails to start a Registry, it exits the program????????????????? * with exit code 1.??????????????????????????????????????????????????????? */ public static void restart(int port) { if (isInCacheAndRunning(port)) return; try { startRegistry(port); } catch (RemoteException e) { In.message(e); } } /**???????????????????????????????????????????????????????????????????????? * @param port????????????????????????????????????????????????????????????? * @return true if registry is in cache and running???????????????????????? */ private static boolean isInCacheAndRunning(Integer port) { if (!isRegistryRunning(port.intValue())) return false; if (!isRegistryInCache(port.intValue())) return false; return true; } /**???????????????????????????????????????????????????????????????????????? * @param port????????????????????????????????????????????????????????????? * @return true if we are able to locate a local registry on port.??????????????????????????????????????????????????????????????????????????? */ private static boolean isRegistryRunning(int port) { try { Registry r = LocateRegistry.getRegistry(port); if (r != null) return true; } catch (RemoteException e) { return false; } return false; } /**???????????????????????????????????????????????????????????????????????? * @param port????????????????????????????????????????????????????????????? * @return return true if registry is in cache????????????????????????????? */ private static boolean isRegistryInCache(int port) { if (registry.get(new Integer(port)) == null) return false; return true; } /**???????????????????????????????????????????????????????????????????????? * Restart the registry, if needed.???????????????????????????????????????? * Return the only instance of the registry for consistent global?????????? * using by making use of the Singleton Design Pattern????????????????????? *????????????????????????????????????????????????????????????????????????? * @return the internally held registry instance.?????????????????????????? */ public static Registry getRegistry(Integer port) { restart(port); return (Registry) registry.get(port); } private static void startRegistry(Integer port) throws RemoteException { Registry r; try { r = LocateRegistry.createRegistry(port.intValue()); registry.put(port, r); //r = new sun.rmi.registry.RegistryImpl???????????????????????????? /// (port.intValue());?????????????????????????????????????? // registry.put(port, r);?????????????????????????????????????????? } catch (Exception e) { //e.printStackTrace();????????????????????????????????????????????? r = LocateRegistry.getRegistry(port.intValue()); registry.put(port, r); } } public static void main(String args[]) throws RemoteException { //restart(port);??????????????????????????????????????????????????????? restart(5001); restart(5002); restart(5002); Registry r = LocateRegistry.getRegistry(5002); System.out.println("registry="+r); } } I would very much like to get your feedback on this new design pattern idea. Thank you for your time. Regards, - Doug From david.garnier at trusted-logic.com Wed Mar 22 07:36:10 2006 From: david.garnier at trusted-logic.com (David Garnier) Date: Wed, 22 Mar 2006 15:36:10 +0100 Subject: [Rxtx] sole of a new design pattern In-Reply-To: References: Message-ID: <442160DA.80107@trusted-logic.com> Hello, > The Parametric Singleton Design Pattern The Singleton is the most abused design pattern ever. Good use-cases for this pattern are extremely rare and mostly confined to problems related to hardware resources, like serial ports. > Applicability > > Use the Parametric Singleton Design Pattern when: > 1. There must be exactly one instance of a class with the given > parameters. OK. As I said above, this case this actually very unusual. The Singleton pattern is mostly used when : > 2. The instances must be accessible to clients from a well-known > access point. Using the singleton pattern in this case is just convenient for the programmer. Problems arises pretty quickly, especially if you attempt to unit-test your classes. 1) If your singleton is stateful, or hold on to stateful objects, it means that two different unit tests are not actually independent. Instead of starting with a brand new environment, the result of a test may be affected by the result of a previous test. This problem also arise when with your class relies on a database. In both cases, the solution is to reset your "unique" resource (Singleton or database) at the beginning of the test, which is a pain. Also, while most projects connect to a single database, projects that allow the use of Singletons usually contain several of thems, and new ones may cropped up unnoticed. You quickly end up with test cases that only pass in a certain order, which is a royal pain. 2) You cannot mockup a singleton. Once everyone calls the SomeSingleton class statically, you can't replace your class by SomeSingletonMockup. Furthermore, even for hardware services, the Singleton pattern does not really prevent concurrent accesses. If you start the same program in two different JVMs, unless they somehow shared the state of their "Singletons" (through lock files for example), the Singleton pattern will not prevent concurrent access. Our application uses RXTX, and we routinely encounter cases where another (native) application has already locked the port. Since we cannot modify the native application to recognize lock files, OS-level control is irreplaceable. > > Consequences > The Parametric Singleton Design Pattern has several benefits: > > 1. Controlled access to parametrically defined instances. Since > the Parametric Singleton class encapsulates its instances, there is > control over how and when clients access it. Not really. Once you've returned the instance to a client, you've lost control over it. The client can to whatever it wants with it. You cannot "recall" the instance or claim it back. > 2. Reduced name space. The Parametric Singleton pattern avoids > global variables that store instances created from the same parameter. Sure, but you don't have to rely on a Singleton for that. Just create a single Factory. > I would very much like to get your feedback on this new design > pattern idea. Well, it's nothing new. Some may say that it is the point of design patterns: formalizes the designs that occur again and again. However, this design is simply a combination of the Singleton and Factory patterns. I did use it in the past, but now I've been exposed to the shortcomings of the Singleton pattern, so I limit myself to Factories. Regards, David From sean_montgomery at baseview.com Wed Mar 22 08:35:28 2006 From: sean_montgomery at baseview.com (Sean Montgomery) Date: Wed, 22 Mar 2006 10:35:28 -0500 Subject: [Rxtx] sole of a new design pattern In-Reply-To: <442160DA.80107@trusted-logic.com> References: <442160DA.80107@trusted-logic.com> Message-ID: <05769CA7-A51B-4CF0-BAA0-E02DD905F5A4@baseview.com> On Mar 22, 2006, at 9:36 AM, David Garnier wrote: > Furthermore, even for hardware services, the Singleton pattern does > not really prevent concurrent > accesses. If you start the same program in two different JVMs, > unless they somehow shared the state > of their "Singletons" (through lock files for example), the > Singleton pattern will not prevent > concurrent access. > Multiple class loaders in a single JVM can be tricky, too. Then there's synchronization, lazy initialization and serialization of singletons to contend with. Bloch's Effective Java covers these, and here's a few articles: http://www.javaworld.com/javaworld/jw-04-2003/jw-0425-designpatterns- p3.html http://java.sun.com/developer/technicalArticles/Programming/singletons/ Just FYI :-) From lyon at docjava.com Wed Mar 22 08:50:48 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Wed, 22 Mar 2006 10:50:48 -0500 Subject: [Rxtx] sole of a new design pattern In-Reply-To: <442160DA.80107@trusted-logic.com> References: <442160DA.80107@trusted-logic.com> Message-ID: Hi All, First, I would like to thank David for his prompt and thoughtful remarks. I had no idea people that feel strongly about a design patterns! Wow! Feedback (particularly critical feedback) is greatly appreciated. Starting at the end, first: >I did use it in >the past, but now I've been exposed to the shortcomings of the >Singleton pattern, so I limit myself to Factories. David, if I understood your comments correctly, you suggested that Factories can be used in leu of the Singleton Design Pattern, or even the Parametric Singleton Design Pattern. As I see in [Gof]: Factory Method: Intent "Define an interface for creating an object, but let subclasses decide which class to instantiate. Factory Method lets a class defer instantiation to subclasses." The Singleton Design Pattern is a concrete class, which is rather different, right? Also, subclasses are not permitted with Singleton, as they are final. Naturally, I could use an abstract factory as a parent for a singleton. I could even design a facade that could be implemented with the singleton....but that is not the intention of the design. Unless you want a mock-up, as discussed, below: More below: >Hello, > >> The Parametric Singleton Design Pattern > >The Singleton is the most abused design pattern ever. Good use-cases >for this pattern are extremely >rare and mostly confined to problems related to hardware resources, >like serial ports. > > >> Applicability >> >> Use the Parametric Singleton Design Pattern when: >> 1. There must be exactly one instance of a class with the given >> parameters. >OK. As I said above, this case this actually very unusual. The >Singleton pattern is mostly used when : >> 2. The instances must be accessible to clients from a well-known >> access point. > >Using the singleton pattern in this case is just convenient for the >programmer. Problems arises >pretty quickly, especially if you attempt to unit-test your classes. > >1) If your singleton is stateful, or hold on to stateful objects, it >means that two different unit >tests are not actually independent. Instead of starting with a brand >new environment, the result of >a test may be affected by the result of a previous test. This >problem also arise when with your >class relies on a database. In both cases, the solution is to reset >your "unique" resource >(Singleton or database) at the beginning of the test, which is a >pain. Also, while most projects >connect to a single database, projects that allow the use of >Singletons usually contain several of >thems, and new ones may cropped up unnoticed. You quickly end up >with test cases that only pass in a >certain order, which is a royal pain. There are basic problems with communicating finite state machines that include reachability and deadlock analysis. These are addressed with petri net analysis and are beyond the scope of the design pattern. As you quite rightly pointed out; the parametric singleton pattern (or the singleton pattern, for that matter) enable multiple threads to gain access to the same instance. The only way that I can see to block others from gaining access to the reference is the synchronize keyword. This is putting a spin-lock (or MUTEX) on the reference. The question of how to unit-test a design pattern like the parametric singleton remains open. Perhaps this is a deficiency. > >2) You cannot mockup a singleton. Once everyone calls the >SomeSingleton class statically, you can't >replace your class by SomeSingletonMockup. Acutally, I am not sure that this is true. If the Singleton implements a Facade interface, it should be possible to make the replacement. Right? > >Furthermore, even for hardware services, the Singleton pattern does >not really prevent concurrent >accesses. If you start the same program in two different JVMs, >unless they somehow shared the state >of their "Singletons" (through lock files for example), the >Singleton pattern will not prevent >concurrent access. Good Point!! You have sharp eyes! The singleton design pattern should/could take responsibility for this. In fact, you may notice that my code does have an implementation (LocateRegistry) that can work across JVM's. The LocateRegistry will even work across the Internet! LocateRegistry takes both a host name and a Port (lock files just don't do this). I did not think to implement this beyond the local machine, but, in its present form, it will work across different processes. > >Our application uses RXTX, and we routinely encounter cases where >another (native) application has >already locked the port. Since we cannot modify the native >application to recognize lock files, >OS-level control is irreplaceable. The singleton design pattern is not meant to replace OS-level control, but to centralize the Java programmers access to it. If lock files, for example, are used for serial ports, the Singleton Design Pattern should be able to work with them. > > >> >> Consequences >> The Parametric Singleton Design Pattern has several benefits: >> > > 1. Controlled access to parametrically defined instances. Since >> the Parametric Singleton class encapsulates its instances, there is >> control over how and when clients access it. > >Not really. Once you've returned the instance to a client, you've >lost control over it. The client >can to whatever it wants with it. You cannot "recall" the instance >or claim it back. Good point, this should read: > 1. Controll when parametrically defined instances are created. Since > > the Parametric Singleton class encapsulates its instances, there is > > control over how and when they are instanced. > >> 2. Reduced name space. The Parametric Singleton pattern avoids >> global variables that store instances created from the same parameter. > >Sure, but you don't have to rely on a Singleton for that. Just >create a single Factory. > > Thank you for your thoughtful and prompt response! Regards, - Doug From dmarkman at mac.com Wed Mar 22 21:21:55 2006 From: dmarkman at mac.com (Dmitry Markman) Date: Wed, 22 Mar 2006 23:21:55 -0500 Subject: [Rxtx] sole of a new design pattern In-Reply-To: <442160DA.80107@trusted-logic.com> References: <442160DA.80107@trusted-logic.com> Message-ID: I don't think I get it On Mar 22, 2006, at 9:36 AM, David Garnier wrote: > Using the singleton pattern in this case is just convenient for the > programmer. Problems arises > pretty quickly, especially if you attempt to unit-test your classes. so you're saying that something isn't so good because you can not test it in the convenient way? if that's true, I'm totally disagree change your test, debug whatever, but if software is efficient at runtime, works fine and only problem is some unit test (which is some kind of framework for testing) then dump that unit test , dump that unit framework and make something appropriate to the software you're testing so if Douglas want to use singletons, what's the problem? and what do you mean by abusing of singleton usage? of course singleton doesn't prevent concurrent access to the resource across the processes unless you're using some OS facility to prevent it, besides singleton as it was introduced is relevant only and only inside of the same process otherwise it's not singleton it's something else (let's say network singleton: so you have remote invocation facility and some factory method that return object created by that facility) I don't have any problem with using any kind of singletons. Parametric Singleton idea (if I understand it right) could be easily implemented in the following way: use a map populate map with instances of some class and key is your parameter (you can use lazy population too) if somebody ask the key check the value if it's null so resource is taken if somebody returns the resource put it back to the map public synchronized static Object getSomeResource(Object parameter); public synchronized static void returnResource(Object parameter); getSomeResource (inside of the same process) could return null in 2 cases 1. if somebody (from other thread for example) already took that resource 2. if OS API said that resource corresponded to that parameter (serial port with parameter = 1 (port #)) is locked and unavailable; I'm not sure that in case of serial ports we even need those Parametric Singletons (unless lock checking is a very expensive operation) just ask the OS about availability of that resource and if it's available give it away and then OS will lock it and therefore in next time somebody ask it just answer that resource is locked and return null for example system has 2 serial ports available so I ask getResource("tty"); or I ask getResource("Bluetooth-Modem"); and if OS is ok you can give tty or Bluetooth-Modem or both no need for any additional pattern I think back to the problem mac os x doesn't recognize locking via files, so it handles locking via some API an instance of the singleton in each process should recognize that resource is locked (by using that API) that's all we don't have to make things more complicate then they are just because there is some nice design pattern or nice unit test framework or whatever keep things simple, make them work fast, don't introduce middle layers unless you have really good reason to do so of course I could be entirely wrong, so sorry about that in advance thanks Dmitry Markman From tjarvi at qbang.org Wed Mar 22 22:31:41 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 22 Mar 2006 22:31:41 -0700 (MST) Subject: [Rxtx] sole of a new design pattern In-Reply-To: References: Message-ID: Hi Doug Interesting reading. So far I'm just reading and thinking. I have one question so far. " Clients obtain a reference to a Parametric Singleton instance only through the parametric singleton design pattern. If the instance is left in an improper state (e.g., the serial port was left open) it is NOT the role of the Parametric Singleton Design Pattern to close the IO port. Nor is it the role of the Parametric Singleton Design Pattern to open the port. That role is delegate to some other part of the system. " So when the clients obtain a reference to the singleton, can they assume the port is there? IE, would it be the singletons role to handle things like USB dongles being removed with event hints comming from the underlying OS. Hardware abstraction layer/HAL on Linux is an example of underlying OS events. I assume that role too is delegated to other parts of the system? -- Trent Jarvi tjarvi at qbang.org From lyon at docjava.com Thu Mar 23 08:10:33 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Thu, 23 Mar 2006 10:10:33 -0500 Subject: [Rxtx] Classes don't need goals, they need roles! In-Reply-To: References: Message-ID: Hi Trent, Yes, I think that the role of the Parametric Singleton Pattern is not to open or close serial ports, nor is it to perform error checking. On the other hand, if you were to combine the role of the Parametric Singleton Pattern with another role (like that of error checking) it might not be amiss. However, I generally caution programmers against adding multiple roles to classes, as this leads to monolithic designs. Thus a different class (NativeLibDetect) could have the role of determining if the native library can be loaded. Another class (SerialPortBean) can have the role of serializing the default state of the serial port, so that it can be recovered, from user preferences, at a later time. The SerialPortDetect could have the role of determining if the serial port is removed (i.e., a USB port was unplugged). My guess is that each class should have a different role in the system, in order to ease maintenance and testing...but I could be wrong about that. Thanks! - Doug >Hi Doug > >Interesting reading. So far I'm just reading and thinking. I have >one question so far. > >" > Clients obtain a reference to a Parametric Singleton instance only >through the parametric singleton design pattern. If the instance is >left in an improper state (e.g., the serial port was left open) it is >NOT the role of the Parametric Singleton Design Pattern to close the >IO port. Nor is it the role of the Parametric Singleton Design Pattern >to >open the port. That role is delegate to some other part of the system. >" > >So when the clients obtain a reference to the singleton, can they >assume the port is there? IE, would it be the singletons role to >handle things like USB dongles being removed with event hints >comming from the underlying OS. Hardware abstraction layer/HAL on >Linux is an example of underlying OS events. > >I assume that role too is delegated to other parts of the system? > >-- >Trent Jarvi >tjarvi at qbang.org >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From maximulo at yahoo.com Fri Mar 24 01:22:38 2006 From: maximulo at yahoo.com (Maximulo Majir) Date: Fri, 24 Mar 2006 00:22:38 -0800 (PST) Subject: [Rxtx] JavaPOS Message-ID: <20060324082238.66371.qmail@web38214.mail.mud.yahoo.com> Hi all! Hello Trent! From what i understand, RXTX or JavaComm APIs were not created solely for JavaPOS. In JavaPOS, we have the virtual method claim() which is separate from open(), but in our RXTX API, claiming is done every call to open(), we cant open the port if its claimed by another application. Would it be alright to suggest or ask to create a new method called claim(..)? Is there such thing as forceclaim() in RXTX? this could be the same as portownership transfer or its equivalent. ForceClaim is in JSR80. Do you have some samples using RXTX as the lower layer for the Device Service Objects in JavaPOS? I have tried it, i just want to compare. Thank you all! maxim __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060324/496adba2/attachment-0048.html From tjarvi at qbang.org Fri Mar 24 11:28:19 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 24 Mar 2006 11:28:19 -0700 (MST) Subject: [Rxtx] Re: RXTX 2.1 Solaris Problems In-Reply-To: <3691.1143210578@www045.gmx.net> References: <3691.1143210578@www045.gmx.net> Message-ID: On Fri, 24 Mar 2006, Andreas Guenther wrote: > Hi all, > > the solaris problem was not the lock file only. > > Ok, I had to create the directory /var/spool/locks myself. > /var/spool/uucp exists. > > But rxtx didn't find any port. > > I compiled the source with my own debug-informations > and I tried to isolate the problem. > > The problem is the testRead-call in SerialImp.c > > JNIEXPORT jboolean JNICALL RXTXCommDriver(testRead)( > > ... > if ( READ( fd, &c, 1 ) < 0 ) > { > if ( errno != EAGAIN ) { > report( "testRead() read failed\n" ); > ret = JNI_FALSE; > } > } > Thanks Andreas I'm packing up to move. I'll be more or less away for a couple weeks here. I'll be checking email but my workstation is going into a box soon. This isn't hard to fix as this port should be enumerated when EWOULDBLOCK is recieved. Thats error is OK for enumeration just as EAGAIN is. I've put the bug into bugzilla so we dont forget to get to it. http://bugzilla.qbang.org/show_bug.cgi?id=42 You can add yourself to the CC list if you wish to test fixes we provide or even put a patch into bugzilla yourself. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Fri Mar 24 11:51:52 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 24 Mar 2006 11:51:52 -0700 (MST) Subject: [Rxtx] JavaPOS In-Reply-To: <20060324082238.66371.qmail@web38214.mail.mud.yahoo.com> References: <20060324082238.66371.qmail@web38214.mail.mud.yahoo.com> Message-ID: On Fri, 24 Mar 2006, Maximulo Majir wrote: > Hi all! Hello Trent! > > > From what i understand, RXTX or JavaComm APIs were not > created solely for JavaPOS. In JavaPOS, we have the virtual method > claim() which is separate from open(), but in our RXTX API, claiming is > done every call to open(), we cant open the port if its claimed by > another application. Would it be alright to suggest or ask to create a > new method called claim(..)? Is there such thing as forceclaim() in > RXTX? this could be the same as portownership transfer or its > equivalent. ForceClaim is in JSR80. > Do you have some samples using RXTX as the lower layer for the Device > Service Objects in JavaPOS? I have tried it, i just want to compare. > maxim Hi Maxim JSR80 is the USB API IBM/Sun put together. The problem is they have a richer kernel/API underneath that can handle such things. With Serial Ports, there isnt anything there other than an ioctl that says don't let anyone touch this and lockfiles that are more of a 'lets be nice.' At times we may be using USB ports but it is through the termios layer with the limitations mentioned. The advantage is that not only USB will work with rxtx. Anything that has a termios layer should work (to the extent that termios layer is complete). I don't know how forceclaim() would help you. Lets say someone has a programmer working on /dev/ttyS0 and you take it. Now you both race each other to read data first. There isn't a mechanism I know of that will solve this problem in termios. The most obvious test being a native app and a Java app trying to take the port. There is the potential of requestion ownership from other Java Applications but the use for that is very rare. Did you have something more specific in mind that I'm missing? I'm not sure that claim() and forceclaim() would help you with rxtx other than maybe locking the port with claim() without opening it. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sat Mar 25 23:42:08 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 25 Mar 2006 23:42:08 -0700 (MST) Subject: [Rxtx] Serial snoop Message-ID: I was reading the Linux kernel mail-list tonight and ran past a thread that mentioned sersnoop. This looks like a handy tool for people dealing with new toys. "a simple command-line tool for linux that echoes bytes to and from any two serial ports, ptys, or network sockets, and prints all traffic to stdout, in hex and ascii." http://www.restivo.org/projects/sersnoop/ It works on Linux only at this time (debian package available). -- Trent Jarvi tjarvi at qbang.org From beat.arnet at gmail.com Sun Mar 26 07:32:35 2006 From: beat.arnet at gmail.com (Beat Arnet) Date: Sun, 26 Mar 2006 09:32:35 -0500 Subject: [Rxtx] Error 0x5 at /home/bob/foo/tar/rxtx-2.1-7/build/../src/termios.c(860): Access is, denied. Message-ID: <4426A603.80508@gmail.com> Dear all, When trying to open the serial port, I sometimes (not always) run into the following exception (when opening the serialPort): Error 0x5 at /home/bob/foo/tar/rxtx-2.1-7/build/../src/termios.c(860): Access is denied. java.lang.UnsatisfiedLinkError: native_psmisc_report_owner at gnu.io.CommPortIdentifier.native_psmisc_report_owner(Native Method) at gnu.io.CommPortIdentifier.open(CommPortIdentifier.java:354) at codeskin.tools.CLLoader.open(CLLoader.java:79) at codeskin.tools.C2000Programmer.run(C2000Programmer.java:220) at java.lang.Thread.run(Unknown Source) Is this the type of error where I should just try to open the port again, or can it be avoided? Regards, Beat From tjarvi at qbang.org Sun Mar 26 11:40:12 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 26 Mar 2006 11:40:12 -0700 (MST) Subject: [Rxtx] Error 0x5 at /home/bob/foo/tar/rxtx-2.1-7/build/../src/termios.c(860): Access is, denied. In-Reply-To: <4426A603.80508@gmail.com> References: <4426A603.80508@gmail.com> Message-ID: On Sun, 26 Mar 2006, Beat Arnet wrote: > Dear all, > > When trying to open the serial port, I sometimes (not always) run into > the following exception (when opening the serialPort): > > Error 0x5 at /home/bob/foo/tar/rxtx-2.1-7/build/../src/termios.c(860): > Access is > denied. > > java.lang.UnsatisfiedLinkError: native_psmisc_report_owner > at gnu.io.CommPortIdentifier.native_psmisc_report_owner(Native > Method) > at gnu.io.CommPortIdentifier.open(CommPortIdentifier.java:354) > at codeskin.tools.CLLoader.open(CLLoader.java:79) > at codeskin.tools.C2000Programmer.run(C2000Programmer.java:220) > at java.lang.Thread.run(Unknown Source) > > Is this the type of error where I should just try to open the port again, > or can it be avoided? > Hi Beat We did a second build of rxtx 2.1-7 to resolve that unsatisfied link error. It should work now. rxtx is trying to tell you it thinks someone else has the serial port open. You can try to open the port again but maybe you already have a copy of the program running when it happens? ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7r2.zip fixed build. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sun Mar 26 11:44:23 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 26 Mar 2006 11:44:23 -0700 (MST) Subject: [Rxtx] RXTX spec file (fwd) Message-ID: This is probably interesting for fedora/suse users. ---------- Forwarded message ---------- Date: Sun, 26 Mar 2006 16:25:45 +0200 To: taj at www.linux.org.uk Subject: RXTX spec file I send you this spec file which allows to create a RPM for Fedora 4, 5 (x86, x86_64) with Java Sun. -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: rxtx.spec Url: http://mailman.qbang.org/pipermail/rxtx/attachments/20060326/6c7b6af6/rxtx-0044.pl From tjarvi at qbang.org Sun Mar 26 23:42:59 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 26 Mar 2006 23:42:59 -0700 (MST) Subject: [Rxtx] Upcomming events. Message-ID: This Wednesday we will be announcing a new "Maintainer" for the rxtx project. The position is more like neutral leader. I wont be going away or doing less. This is just the right thing to do as it turns out the two people with CVS write access will be at the same company. We need a third and we need neutrality. The maintainer will have final say in any conflict and will try to be neutral. It will be open for discussion. Then we will do it :) I'll still do most of the footwork I do now. But. I'm falling behind. I should have gone through the mail-list and posted the next round of changes this weekend. I'm packing to move and its going so so - 13 years of toys collected. I suspect there will be a dead period on my part (a couple weeks) comming up. But if you get it on the mail-list, we will get it in if there are no objections. I may well not be reading the mail-list during this period as I look for a house and many other things. I hope everyone will help out. Thanks -- Trent Jarvi tjarvi at qbang.org From mahmoud_hadad at yahoo.com Sun Mar 26 07:31:19 2006 From: mahmoud_hadad at yahoo.com (ronan nick) Date: Sun, 26 Mar 2006 06:31:19 -0800 (PST) Subject: [Rxtx] a question about the COMM API Message-ID: <20060326143119.54919.qmail@web60014.mail.yahoo.com> hi, i was intrested in knowing how i can communicate with my internal modem using java? for example if i want to make a phone dialer application or a caller id application where should i be looking at? and as i understood the COMM API is for devices that is attached to the computer through serial ports. --------------------------------- New Yahoo! Messenger with Voice. Call regular phones from your PC and save big. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060326/ce8329f0/attachment-0046.html From dmarkman at mac.com Mon Mar 20 00:20:43 2006 From: dmarkman at mac.com (Dmitry Markman) Date: Mon, 20 Mar 2006 02:20:43 -0500 Subject: [Rxtx] Mac OS X RXTX java installer In-Reply-To: References: <07D0DE29-BA32-4CFE-B036-66BC6423D385@buechse.de> <441AE3E0.2030503@willicon.de> <12531986.1142622114996.JavaMail.dmarkman@mac.com> <441B2674.9010409@willicon.de> <13577405.1142634732776.JavaMail.dmarkman@mac.com> <441B4182.8010407@willicon.de> <92CD0D6C-5BE8-426E-A46D-99452059FF49@mac.com> <441BBB2D.8030305@willicon.de> <441C4088.5090905@willicon.de> Message-ID: <64BC1E23-FDDE-4CE6-8863-CFC881CBC224@mac.com> Hi all I put RXTX installer that will install everything (and will create / var/lock if necessary and add user to the uucp group) for mac os x from Java into the rxtx's CVS repository it could be easily modified to install files for any platform it uses Greg Guerin's AuthKit for authentication and authorization Greg released that kit under artistic license, so Trent, please take a look we, probably, can negotiate license with Greg if it's necessary Greg's AuthKit could be downloaded from http://www.amug.org/~glguerin/ sw/#authkit Michael Hall (mikehall at spacestar dot net) had a suggestion to make implementation of the jaas LoginModule based on Greg's AuthKit (his modification of the Greg's AuthKit could be found at http:// www.spacestar.net/users/mikehall/authkit.dmg) but Michael's AuthKitLoginModule does only half a job: it does authenticate but it can not run any external unix process in privileged mode (at least I wasn't able to do so) possible explanation could be found in conversation between Greg and Michael at Apple's java-dev list (look for archives) so I didn't use jaas API for rxtxinstaller I created folder MacOSX in the contrib folder comment 1. if you want to run that installer as standalone application all you need that RXTXInstaller.jar 2. if you want to use webstart you have to add Greg's libAuthKit.jnilib to the mac os x's resources in theory RXTXInstaller.jar doesn't need it, but there is a problem with loading libAuthKit.jnilib from webstart authkit uses loadLibrary method to load library and it failed (from webstart) for standalone application I extract libAuthKit.jnilib from the RXTXInstaller.jar and put it into the /Library/Java/Extensions or ~/Library/Java/Extensions folder that file will be deleted after installer quit unfortunately I didn't have time to put documentation there but it is mostly self-explanatory I took installer code from my gl4java installer that I did about 3 years ago (with small modifications) it would be very nice if Apple will release LoginModule that really will do the job (com.apple.security.auth.module package????? ) (UnixLoginModule is pretty useless) From lyon at docjava.com Mon Mar 20 06:34:39 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Mon, 20 Mar 2006 08:34:39 -0500 Subject: [Rxtx] Mac OS X RXTX java installer In-Reply-To: <64BC1E23-FDDE-4CE6-8863-CFC881CBC224@mac.com> References: <07D0DE29-BA32-4CFE-B036-66BC6423D385@buechse.de> <441AE3E0.2030503@willicon.de> <12531986.1142622114996.JavaMail.dmarkman@mac.com> <441B2674.9010409@willicon.de> <13577405.1142634732776.JavaMail.dmarkman@mac.com> <441B4182.8010407@willicon.de> <92CD0D6C-5BE8-426E-A46D-99452059FF49@mac.com> <441BBB2D.8030305@willicon.de> <441C4088.5090905@willicon.de> <64BC1E23-FDDE-4CE6-8863-CFC881CBC224@mac.com> Message-ID: Hi Dimitry, This sounds like great work. Just a couple of questions; After the check out of the CVS files, using: setenv CVSROOT :pserver:anonymous at cvs.milestonesolutions.com:/usr/local/cvsroot 53 8:28 setenv PASSWORD mousy 54 8:29 cvs login 55 8:29 cvs checkout rxtx-devel I cd'd over to: rxtx-devel/MACOSX_IDE And found: CVS/ CW/ ForPackageMaker/ PB/ Where is the installer? Thanks! - Doug From tjarvi at qbang.org Mon Mar 20 06:39:37 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 20 Mar 2006 06:39:37 -0700 (MST) Subject: [Rxtx] Mac OS X RXTX java installer In-Reply-To: References: <07D0DE29-BA32-4CFE-B036-66BC6423D385@buechse.de> <441AE3E0.2030503@willicon.de> <12531986.1142622114996.JavaMail.dmarkman@mac.com> <441B2674.9010409@willicon.de> <13577405.1142634732776.JavaMail.dmarkman@mac.com> <441B4182.8010407@willicon.de> <92CD0D6C-5BE8-426E-A46D-99452059FF49@mac.com> <441BBB2D.8030305@willicon.de> <441C4088.5090905@willicon.de> <64BC1E23-FDDE-4CE6-8863-CFC881CBC224@mac.com> Message-ID: On Mon, 20 Mar 2006, Dr. Douglas Lyon wrote: > Hi Dimitry, > This sounds like great work. Just a couple of questions; > After the check out of the CVS files, using: > setenv CVSROOT > :pserver:anonymous at cvs.milestonesolutions.com:/usr/local/cvsroot > 53 8:28 setenv PASSWORD mousy > 54 8:29 cvs login > 55 8:29 cvs checkout rxtx-devel Hi Doug You want "cvs checkout -r commapi-0-0-1 rxtx-devel" to get RXTX 2.1 The default branch is rxtx 2.0 which isn't very active right now. -- Trent Jarvi tjarvi at qbang.org From lyon at docjava.com Mon Mar 20 07:05:44 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Mon, 20 Mar 2006 09:05:44 -0500 Subject: [Rxtx] Mac OS X RXTX java installer In-Reply-To: References: <07D0DE29-BA32-4CFE-B036-66BC6423D385@buechse.de> <441AE3E0.2030503@willicon.de> <12531986.1142622114996.JavaMail.dmarkman@mac.com> <441B2674.9010409@willicon.de> <13577405.1142634732776.JavaMail.dmarkman@mac.com> <441B4182.8010407@willicon.de> <92CD0D6C-5BE8-426E-A46D-99452059FF49@mac.com> <441BBB2D.8030305@willicon.de> <441C4088.5090905@willicon.de> <64BC1E23-FDDE-4CE6-8863-CFC881CBC224@mac.com> Message-ID: Hi Trent, Thanks for the info on the CVS checkout procedure. I did that and am still not sure where the installer is. Here is what I have: cd MACOSX_IDE/ p4.docjava.com{lyon}121: ls CVS/ ForPackageMaker/ PB/ p4.docjava.com{lyon}122: find . | more . ./ForPackageMaker ./ForPackageMaker/RXTX.pkg.sit.hqx ./ForPackageMaker/Resources ./ForPackageMaker/Resources/ReadMe.rtf ./ForPackageMaker/Resources/Welcome.rtf ./ForPackageMaker/Resources/CVS ./ForPackageMaker/Resources/CVS/Entries ./ForPackageMaker/Resources/CVS/Repository ./ForPackageMaker/Resources/CVS/Tag ./ForPackageMaker/Resources/CVS/Root ./ForPackageMaker/Resources/preinstall ./ForPackageMaker/Resources/License.rtf ./ForPackageMaker/Resources/preupgrade ./ForPackageMaker/RXTX.pmsp ./ForPackageMaker/CVS ./ForPackageMaker/CVS/Entries ./ForPackageMaker/CVS/Repository ./ForPackageMaker/CVS/Entries.Log ./ForPackageMaker/CVS/Tag ./ForPackageMaker/CVS/Root ./ForPackageMaker/RXTX_Tiger.pkg.sitx.hqx ./ForPackageMaker/RXTX_Jag.pkg.sit.hqx ./ForPackageMaker/Install ./ForPackageMaker/Install/CVS ./ForPackageMaker/Install/CVS/Entries ./ForPackageMaker/Install/CVS/Repository ./ForPackageMaker/Install/CVS/Tag ./ForPackageMaker/Install/CVS/Root ./ForPackageMaker/Install/Library ./ForPackageMaker/Install/Library/CVS ./ForPackageMaker/Install/Library/CVS/Entries ./ForPackageMaker/Install/Library/CVS/Repository ./ForPackageMaker/Install/Library/CVS/Tag ./ForPackageMaker/Install/Library/CVS/Root ./ForPackageMaker/Install/Library/Java ./ForPackageMaker/Install/Library/Java/Extensions ./ForPackageMaker/Install/Library/Java/Extensions/RXTXcomm.jar ./ForPackageMaker/Install/Library/Java/Extensions/CVS ./ForPackageMaker/Install/Library/Java/Extensions/CVS/Entries ./ForPackageMaker/Install/Library/Java/Extensions/CVS/Repository ./ForPackageMaker/Install/Library/Java/Extensions/CVS/Tag ./ForPackageMaker/Install/Library/Java/Extensions/CVS/Root ./ForPackageMaker/Install/Library/Java/Extensions/librxtxSerial.jnilib ./ForPackageMaker/Install/Library/Java/CVS ./ForPackageMaker/Install/Library/Java/CVS/Entries ./ForPackageMaker/Install/Library/Java/CVS/Repository ./ForPackageMaker/Install/Library/Java/CVS/Entries.Log ./ForPackageMaker/Install/Library/Java/CVS/Tag ./ForPackageMaker/Install/Library/Java/CVS/Root ./ForPackageMaker/RXTX_Tiger.pmproj.sitx.hqx ./CVS ./CVS/Entries ./CVS/Repository ./CVS/Entries.Log ./CVS/Tag ./CVS/Root ./PB ./PB/LibSerialUniversal.xcodeproj.sitx.hqx ./PB/CVS ./PB/CVS/Entries ./PB/CVS/Repository ./PB/CVS/Entries.Log ./PB/CVS/Tag ./PB/CVS/Root ./PB/LibSerial.pbproj.sit.hqx ./PB/startpoint.c ./PB/config.h What is the procedure to run this installer? Do we need a README in: /rxtx-devel/MACOSX_IDE Here is what we have: CVS/ ForPackageMaker/ PB/ Thanks! - DL >On Mon, 20 Mar 2006, Dr. Douglas Lyon wrote: > >>Hi Dimitry, >>This sounds like great work. Just a couple of questions; >>After the check out of the CVS files, using: >>setenv CVSROOT >>:pserver:anonymous at cvs.milestonesolutions.com:/usr/local/cvsroot >> 53 8:28 setenv PASSWORD mousy >> 54 8:29 cvs login >> 55 8:29 cvs checkout rxtx-devel > >Hi Doug > >You want "cvs checkout -r commapi-0-0-1 rxtx-devel" to get RXTX 2.1 >The default branch is rxtx 2.0 which isn't very active right now. > >-- >Trent Jarvi >tjarvi at qbang.org From tjarvi at qbang.org Mon Mar 20 07:25:30 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 20 Mar 2006 07:25:30 -0700 (MST) Subject: [Rxtx] Mac OS X RXTX java installer In-Reply-To: References: <07D0DE29-BA32-4CFE-B036-66BC6423D385@buechse.de> <441AE3E0.2030503@willicon.de> <12531986.1142622114996.JavaMail.dmarkman@mac.com> <441B2674.9010409@willicon.de> <13577405.1142634732776.JavaMail.dmarkman@mac.com> <441B4182.8010407@willicon.de> <92CD0D6C-5BE8-426E-A46D-99452059FF49@mac.com> <441BBB2D.8030305@willicon.de> <441C4088.5090905@willicon.de> <64BC1E23-FDDE-4CE6-8863-CFC881CBC224@mac.com> Message-ID: On Mon, 20 Mar 2006, Dr. Douglas Lyon wrote: > Hi Trent, > Thanks for the info on the CVS checkout procedure. > I did that and am still not sure where the installer is. Hi Doug It does look like it was not cvs committed. There is no rxtx-devel/contrib/MacOSX directory in there at the moment. It was mentioned that it was put under contrib. -- Trent Jarvi tjarvi at qbang.org From dmarkman at mac.com Mon Mar 20 07:29:56 2006 From: dmarkman at mac.com (Dmitry Markman) Date: Mon, 20 Mar 2006 09:29:56 -0500 Subject: [Rxtx] Mac OS X RXTX java installer In-Reply-To: References: <07D0DE29-BA32-4CFE-B036-66BC6423D385@buechse.de> <441AE3E0.2030503@willicon.de> <12531986.1142622114996.JavaMail.dmarkman@mac.com> <441B2674.9010409@willicon.de> <13577405.1142634732776.JavaMail.dmarkman@mac.com> <441B4182.8010407@willicon.de> <92CD0D6C-5BE8-426E-A46D-99452059FF49@mac.com> <441BBB2D.8030305@willicon.de> <441C4088.5090905@willicon.de> <64BC1E23-FDDE-4CE6-8863-CFC881CBC224@mac.com> Message-ID: <6054EB4E-F7E0-4A9C-BDDA-D582D6D8826F@mac.com> you can find it in the rxtx-devel/contrib folder On Mar 20, 2006, at 9:05 AM, Dr. Douglas Lyon wrote: > Hi Trent, > Thanks for the info on the CVS checkout procedure. > I did that and am still not sure where the installer is. > Here is what I have: > cd MACOSX_IDE/ > p4.docjava.com{lyon}121: ls > CVS/ ForPackageMaker/ PB/ > p4.docjava.com{lyon}122: find . | more > . > ./ForPackageMaker > ./ForPackageMaker/RXTX.pkg.sit.hqx > ./ForPackageMaker/Resources > ./ForPackageMaker/Resources/ReadMe.rtf > ./ForPackageMaker/Resources/Welcome.rtf > ./ForPackageMaker/Resources/CVS > ./ForPackageMaker/Resources/CVS/Entries > ./ForPackageMaker/Resources/CVS/Repository > ./ForPackageMaker/Resources/CVS/Tag > ./ForPackageMaker/Resources/CVS/Root > ./ForPackageMaker/Resources/preinstall > ./ForPackageMaker/Resources/License.rtf > ./ForPackageMaker/Resources/preupgrade > ./ForPackageMaker/RXTX.pmsp > ./ForPackageMaker/CVS > ./ForPackageMaker/CVS/Entries > ./ForPackageMaker/CVS/Repository > ./ForPackageMaker/CVS/Entries.Log > ./ForPackageMaker/CVS/Tag > ./ForPackageMaker/CVS/Root > ./ForPackageMaker/RXTX_Tiger.pkg.sitx.hqx > ./ForPackageMaker/RXTX_Jag.pkg.sit.hqx > ./ForPackageMaker/Install > ./ForPackageMaker/Install/CVS > ./ForPackageMaker/Install/CVS/Entries > ./ForPackageMaker/Install/CVS/Repository > ./ForPackageMaker/Install/CVS/Tag > ./ForPackageMaker/Install/CVS/Root > ./ForPackageMaker/Install/Library > ./ForPackageMaker/Install/Library/CVS > ./ForPackageMaker/Install/Library/CVS/Entries > ./ForPackageMaker/Install/Library/CVS/Repository > ./ForPackageMaker/Install/Library/CVS/Tag > ./ForPackageMaker/Install/Library/CVS/Root > ./ForPackageMaker/Install/Library/Java > ./ForPackageMaker/Install/Library/Java/Extensions > ./ForPackageMaker/Install/Library/Java/Extensions/RXTXcomm.jar > ./ForPackageMaker/Install/Library/Java/Extensions/CVS > ./ForPackageMaker/Install/Library/Java/Extensions/CVS/Entries > ./ForPackageMaker/Install/Library/Java/Extensions/CVS/Repository > ./ForPackageMaker/Install/Library/Java/Extensions/CVS/Tag > ./ForPackageMaker/Install/Library/Java/Extensions/CVS/Root > ./ForPackageMaker/Install/Library/Java/Extensions/librxtxSerial.jnilib > ./ForPackageMaker/Install/Library/Java/CVS > ./ForPackageMaker/Install/Library/Java/CVS/Entries > ./ForPackageMaker/Install/Library/Java/CVS/Repository > ./ForPackageMaker/Install/Library/Java/CVS/Entries.Log > ./ForPackageMaker/Install/Library/Java/CVS/Tag > ./ForPackageMaker/Install/Library/Java/CVS/Root > ./ForPackageMaker/RXTX_Tiger.pmproj.sitx.hqx > ./CVS > ./CVS/Entries > ./CVS/Repository > ./CVS/Entries.Log > ./CVS/Tag > ./CVS/Root > ./PB > ./PB/LibSerialUniversal.xcodeproj.sitx.hqx > ./PB/CVS > ./PB/CVS/Entries > ./PB/CVS/Repository > ./PB/CVS/Entries.Log > ./PB/CVS/Tag > ./PB/CVS/Root > ./PB/LibSerial.pbproj.sit.hqx > ./PB/startpoint.c > ./PB/config.h > > What is the procedure to run this installer? > Do we need a README in: > /rxtx-devel/MACOSX_IDE > Here is what we have: > CVS/ ForPackageMaker/ PB/ > > > Thanks! > - DL > >> On Mon, 20 Mar 2006, Dr. Douglas Lyon wrote: >> >>> Hi Dimitry, >>> This sounds like great work. Just a couple of questions; >>> After the check out of the CVS files, using: >>> setenv CVSROOT :pserver:anonymous at cvs.milestonesolutions.com:/usr/ >>> local/cvsroot >>> 53 8:28 setenv PASSWORD mousy >>> 54 8:29 cvs login >>> 55 8:29 cvs checkout rxtx-devel >> >> Hi Doug >> >> You want "cvs checkout -r commapi-0-0-1 rxtx-devel" to get RXTX 2.1 >> The default branch is rxtx 2.0 which isn't very active right now. >> >> -- >> Trent Jarvi >> tjarvi at qbang.org > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx Dmitry Markman From mikehall at spacestar.net Mon Mar 20 05:25:25 2006 From: mikehall at spacestar.net (Michael Hall) Date: Mon, 20 Mar 2006 06:25:25 -0600 Subject: [Rxtx] Re: Mac OS X RXTX java installer In-Reply-To: <64BC1E23-FDDE-4CE6-8863-CFC881CBC224@mac.com> References: <07D0DE29-BA32-4CFE-B036-66BC6423D385@buechse.de> <441AE3E0.2030503@willicon.de> <12531986.1142622114996.JavaMail.dmarkman@mac.com> <441B2674.9010409@willicon.de> <13577405.1142634732776.JavaMail.dmarkman@mac.com> <441B4182.8010407@willicon.de> <92CD0D6C-5BE8-426E-A46D-99452059FF49@mac.com> <441BBB2D.8030305@willicon.de> <441C4088.5090905@willicon.de> <64BC1E23-FDDE-4CE6-8863-CFC881CBC224@mac.com> Message-ID: <247EB61F-5CD1-4132-89A2-FC105B6CF9A5@spacestar.net> On Mar 20, 2006, at 1:20 AM, Dmitry Markman wrote: > > Michael Hall (mikehall at spacestar dot net) had a suggestion to > make implementation of the jaas LoginModule > based on Greg's AuthKit > (his modification of the Greg's AuthKit could be found at http:// > www.spacestar.net/users/mikehall/authkit.dmg) > but Michael's AuthKitLoginModule does only half a job: > it does authenticate > but it can not run any external unix process in privileged mode (at > least I wasn't able to do so) If you got it working directly with Greg's the point is moot. But to clarify it anyhow. The login module does not allow you to do anything anything privileged on return as was explained by Greg. You need to work with a separate privileged process using the execPrivileged method of his API. I assume you did something similar although I haven't looked at how you are using it yet. I allowed instead for a action to be performed at the same time you login/authenticate,this... System.setProperty("authkit.action","/usr/bin/id"); just before this... lc.login(); To clarify, safely ignored as you are already complete. Mike Hall mikehall at spacestar dot net http://www.spacestar.net/users/mikehall http://sourceforge.net/projects/macnative -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2427 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20060320/f6e18202/smime-0049.bin From dmarkman at mac.com Mon Mar 20 07:36:47 2006 From: dmarkman at mac.com (Dmitry Markman) Date: Mon, 20 Mar 2006 09:36:47 -0500 Subject: [Rxtx] Re: Mac OS X RXTX java installer In-Reply-To: <247EB61F-5CD1-4132-89A2-FC105B6CF9A5@spacestar.net> References: <07D0DE29-BA32-4CFE-B036-66BC6423D385@buechse.de> <441AE3E0.2030503@willicon.de> <12531986.1142622114996.JavaMail.dmarkman@mac.com> <441B2674.9010409@willicon.de> <13577405.1142634732776.JavaMail.dmarkman@mac.com> <441B4182.8010407@willicon.de> <92CD0D6C-5BE8-426E-A46D-99452059FF49@mac.com> <441BBB2D.8030305@willicon.de> <441C4088.5090905@willicon.de> <64BC1E23-FDDE-4CE6-8863-CFC881CBC224@mac.com> <247EB61F-5CD1-4132-89A2-FC105B6CF9A5@spacestar.net> Message-ID: Hi, Michael all I have to do is to run some shell script I tried to use your action mechanism and it worked great so I just System.setProperty ("authkit.action","" ) and after that I even don't need to run anything like subject.doAs.... but after few thoughts I choose to use plain Greg's approach, because in that case I don't have to deal with various java's configurations files and therefore to use 2-3 -D parameters in the java command line especially it's useful for java web start (it's so fragile :-( ) thanks for the great job On Mar 20, 2006, at 7:25 AM, Michael Hall wrote: > > On Mar 20, 2006, at 1:20 AM, Dmitry Markman wrote: >> >> Michael Hall (mikehall at spacestar dot net) had a suggestion to >> make implementation of the jaas LoginModule >> based on Greg's AuthKit >> (his modification of the Greg's AuthKit could be found at http:// >> www.spacestar.net/users/mikehall/authkit.dmg) >> but Michael's AuthKitLoginModule does only half a job: >> it does authenticate >> but it can not run any external unix process in privileged mode >> (at least I wasn't able to do so) > > If you got it working directly with Greg's the point is moot. > > But to clarify it anyhow. > The login module does not allow you to do anything anything > privileged on return as was explained by Greg. You need to work > with a separate privileged process using the execPrivileged method > of his API. I assume you did something similar although I haven't > looked at how you are using it yet. > I allowed instead for a action to be performed at the same time you > login/authenticate,this... > System.setProperty("authkit.action","/usr/bin/id"); > just before this... > lc.login(); > To clarify, safely ignored as you are already complete. > > Mike Hall mikehall at spacestar dot net > http://www.spacestar.net/users/mikehall > http://sourceforge.net/projects/macnative > > > Dmitry Markman From dmarkman at mac.com Mon Mar 20 07:44:45 2006 From: dmarkman at mac.com (Dmitry Markman) Date: Mon, 20 Mar 2006 09:44:45 -0500 Subject: [Rxtx] Mac OS X RXTX java installer In-Reply-To: References: <07D0DE29-BA32-4CFE-B036-66BC6423D385@buechse.de> <441AE3E0.2030503@willicon.de> <12531986.1142622114996.JavaMail.dmarkman@mac.com> <441B2674.9010409@willicon.de> <13577405.1142634732776.JavaMail.dmarkman@mac.com> <441B4182.8010407@willicon.de> <92CD0D6C-5BE8-426E-A46D-99452059FF49@mac.com> <441BBB2D.8030305@willicon.de> <441C4088.5090905@willicon.de> <64BC1E23-FDDE-4CE6-8863-CFC881CBC224@mac.com> Message-ID: it's in the commapi-0-0-1 branch I tested it right now: cvs co -r commapi-0-0-1 rxtx-devel and I got everything On Mar 20, 2006, at 9:25 AM, Trent Jarvi wrote: > On Mon, 20 Mar 2006, Dr. Douglas Lyon wrote: > >> Hi Trent, >> Thanks for the info on the CVS checkout procedure. >> I did that and am still not sure where the installer is. > > Hi Doug > > It does look like it was not cvs committed. There is no rxtx-devel/ > contrib/MacOSX directory in there at the moment. It was mentioned > that it was put under contrib. > > -- > Trent Jarvi > tjarvi at qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx Dmitry Markman From tjarvi at qbang.org Mon Mar 20 07:52:57 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 20 Mar 2006 07:52:57 -0700 (MST) Subject: [Rxtx] Mac OS X RXTX java installer In-Reply-To: References: <07D0DE29-BA32-4CFE-B036-66BC6423D385@buechse.de> <441AE3E0.2030503@willicon.de> <12531986.1142622114996.JavaMail.dmarkman@mac.com> <441B2674.9010409@willicon.de> <13577405.1142634732776.JavaMail.dmarkman@mac.com> <441B4182.8010407@willicon.de> <92CD0D6C-5BE8-426E-A46D-99452059FF49@mac.com> <441BBB2D.8030305@willicon.de> <441C4088.5090905@willicon.de> <64BC1E23-FDDE-4CE6-8863-CFC881CBC224@mac.com> Message-ID: On Mon, 20 Mar 2006, Dmitry Markman wrote: > it's in the commapi-0-0-1 branch > > I tested it right now: > cvs co -r commapi-0-0-1 rxtx-devel > > and I got everything > A fresh checkout worked. Here is a copy of the tree (just the installer bits) ftp://ftp.qbang.org/pub/rxtx/MacOSX-installer.zip -- Trent Jarvi tjarvi at qbang.org From lyon at docjava.com Mon Mar 20 08:08:26 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Mon, 20 Mar 2006 10:08:26 -0500 Subject: [Rxtx] Mac OS X RXTX java installer In-Reply-To: References: <07D0DE29-BA32-4CFE-B036-66BC6423D385@buechse.de> <441AE3E0.2030503@willicon.de> <12531986.1142622114996.JavaMail.dmarkman@mac.com> <441B2674.9010409@willicon.de> <13577405.1142634732776.JavaMail.dmarkman@mac.com> <441B4182.8010407@willicon.de> <92CD0D6C-5BE8-426E-A46D-99452059FF49@mac.com> <441BBB2D.8030305@willicon.de> <441C4088.5090905@willicon.de> <64BC1E23-FDDE-4CE6-8863-CFC881CBC224@mac.com> Message-ID: Hi All, Is the Auth package able to work properly on non Mac OS's? It was not clear from the doc or download. Thanks! - Doug From dmarkman at mac.com Mon Mar 20 08:15:22 2006 From: dmarkman at mac.com (Dmitry Markman) Date: Mon, 20 Mar 2006 10:15:22 -0500 Subject: [Rxtx] Mac OS X RXTX java installer In-Reply-To: References: <07D0DE29-BA32-4CFE-B036-66BC6423D385@buechse.de> <441AE3E0.2030503@willicon.de> <12531986.1142622114996.JavaMail.dmarkman@mac.com> <441B2674.9010409@willicon.de> <13577405.1142634732776.JavaMail.dmarkman@mac.com> <441B4182.8010407@willicon.de> <92CD0D6C-5BE8-426E-A46D-99452059FF49@mac.com> <441BBB2D.8030305@willicon.de> <441C4088.5090905@willicon.de> <64BC1E23-FDDE-4CE6-8863-CFC881CBC224@mac.com> Message-ID: <217312D8-CCCA-4859-ABA6-32DF1CC817B9@mac.com> thanks Trent, for putting it on ftp server On Mar 20, 2006, at 9:52 AM, Trent Jarvi wrote: > A fresh checkout worked. Here is a copy of the tree (just the > installer bits) > > ftp://ftp.qbang.org/pub/rxtx/MacOSX-installer.zip > Dmitry Markman From dmarkman at mac.com Mon Mar 20 09:14:03 2006 From: dmarkman at mac.com (Dmitry Markman) Date: Mon, 20 Mar 2006 11:14:03 -0500 Subject: [Rxtx] Mac OS X RXTX java installer In-Reply-To: References: <07D0DE29-BA32-4CFE-B036-66BC6423D385@buechse.de> <441AE3E0.2030503@willicon.de> <12531986.1142622114996.JavaMail.dmarkman@mac.com> <441B2674.9010409@willicon.de> <13577405.1142634732776.JavaMail.dmarkman@mac.com> <441B4182.8010407@willicon.de> <92CD0D6C-5BE8-426E-A46D-99452059FF49@mac.com> <441BBB2D.8030305@willicon.de> <441C4088.5090905@willicon.de> <64BC1E23-FDDE-4CE6-8863-CFC881CBC224@mac.com> Message-ID: <4DEBA6F0-DA45-4E84-823E-1F1AC48BDCCC@mac.com> no it will work only on mac os x however it's harmless to run it on other platform if you want to use it for other platform you have to do the following (I'll do it for linux) 1. modify RXTXInstaller class method public static RXTXInstaller getInstance() public static RXTXInstaller getInstance() { String osName = System.getProperty("os.name").toLowerCase(); if(osName.startsWith("mac")){ return new gnu.io.installer.macosx.MACOSXRXTXInstaller(); } else if(osName.startsWith("windows")){ return new gnu.io.installer.windows.WindowsRXTXInstaller(); }else if(osName.startsWith("linux")){ return new gnu.io.installer.linux.LinuxRXTXInstaller(); } return null; } 2. create folder gnu/io/installer/linux/ 3. create class Linux386RXTXInstaller package gnu.io.installer.linux; import java.io.File; public class Linux386RXTXInstaller extends gnu.io.installer.RXTXInstaller{ public Linux386RXTXInstaller(){ createJarFolder(); createLibFolder(); addJarResource("RXTXcomm.jar","/gnu/io/installer/resources/ linux/jar/RXTXcomm.dat"); addLibResource("librxtxSerial.so","/gnu/io/installer/ resources/linux/lib/librxtxSerial.so"); } protected void createJarFolder(){ String javaHome = System.getProperty("java.home"); char separator = File.separatorChar; jarFolder = new File(javaHome+separator+"lib"+separator+"ext"); } protected void createLibFolder(){ String javaHome = System.getProperty("java.home"); char separator = File.separatorChar; libFolder = new File(javaHome+separator+"bin"); } public void runPreProcess() {} //put here some action you need public void runPostProcess() {} //put here some action you need } 4. create folder /gnu/io/installer/resources/linux/jar and put there linux's version of RXTXcomm.dat (which is renamed RXTXcomm.jar) 5. create folder /gnu/io/installer/resources/linux/lib and put there linux's version of librxtxSerial. so 6. make sure that RXTXInstaller.jar has the following items: /gnu/io/installer/resources/linux/jar/RXTXcomm.jar /gnu/io/installer/resources/linux/lib/librxtxSerial.so 7. modify file installer.pref: jar file RXTXInstaller.jar must have the following item /gnu/io/installer/installer.pref that's basically it for windows you have to do the similar things: just replace linux to windows and librxtxSerial.so to rxtxSerial.dll and create appropriate gnu.io.installer.windows.WindowsRXTXInstaller class package gnu.io.installer.windows; import java.io.File; public class WindowsRXTXInstaller extends gnu.io.installer.RXTXInstaller{ public WindowsRXTXInstaller(){ createJarFolder(); createLibFolder(); addJarResource("RXTXcomm.jar","/gnu/io/installer/resources/ windows/jar/RXTXcomm.dat"); addLibResource("librxtxSerial.so","/gnu/io/installer/ resources/windows/lib/rxtxSerial.dll"); } protected void createJarFolder(){ String javaHome = System.getProperty("java.home"); char separator = File.separatorChar; jarFolder = new File(javaHome+separator+"lib"+separator+"ext"); } protected void createLibFolder(){ String javaHome = System.getProperty("java.home"); char separator = File.separatorChar; libFolder = new File(javaHome+separator+"bin"); } public void runPreProcess() {} //put here some action you need public void runPostProcess() {} //put here some action you need } installer.pref will look like On Mar 20, 2006, at 10:08 AM, Dr. Douglas Lyon wrote: > Hi All, > Is the Auth package able to work properly on > non Mac OS's? > It was not clear from the doc or download. > > Thanks! > - Doug > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx Dmitry Markman From joachim at buechse.de Mon Mar 20 10:49:06 2006 From: joachim at buechse.de (Joachim Buechse) Date: Mon, 20 Mar 2006 18:49:06 +0100 Subject: [Rxtx] BUG: Lock file stays even if port opening fails Message-ID: This was only tested on MacOSX but looking at the code, it should be true for all systems that use lock_uucp. I am opening a port which can not be opened (dialup port of a telephone paired via bluetooth but currently not reachable). The lock file is created and stays arround, even though the port open failed. After looking a bit through the code (of 2.17), I really wonder if it wouldn't be a good idea to make the "locking" an explicit operation called from the java code. This would certainly simplify the generation of meaningfull exceptions (and java based debugging). Maybe even the handling of "preopened" ports should be in the Java part of the lib (again for java based debugging puposes). That beeing said, I have no idea if this would be possible for the 2.07 implementation. Regards, Joachim From tjarvi at qbang.org Mon Mar 20 11:24:22 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 20 Mar 2006 11:24:22 -0700 (MST) Subject: [Rxtx] BUG: Lock file stays even if port opening fails In-Reply-To: References: Message-ID: On Mon, 20 Mar 2006, Joachim Buechse wrote: > This was only tested on MacOSX but looking at the code, it should be true > for all systems that use lock_uucp. > > I am opening a port which can not be opened (dialup port of a telephone > paired via bluetooth but currently not reachable). The lock file is > created and stays arround, even though the port open failed. > > > After looking a bit through the code (of 2.17), I really wonder if it > wouldn't be a good idea to make the "locking" an explicit operation > called from the java code. This would certainly simplify the generation > of meaningfull exceptions (and java based debugging). > Maybe even the handling of "preopened" ports should be in the Java part > of the lib (again for java based debugging puposes). That beeing said, I > have no idea if this would be possible for the 2.07 implementation. > > Regards, Hi Joachim It should be possible in the 2.0-7 implementation too. The calls to RXTXPort.java would not change. We would just do more there Moving more of that logic into Java would be better as many people don't like to look at C code. There is a liblockdev on most Linux distros that can do most of the C code and would be easier to use. The problem is embeded devices will not have that library. The preopened port code has not been really tested. That was a last minute request in a product cycle. I expect it will be tested this year though. As I recall, some devices really do not like CD raising on open. The preopened ports then allow people to mess around in java without power cycling the devices or losing data. -- Trent Jarvi tjarvi at qbang.org From joachim at buechse.de Mon Mar 20 12:01:08 2006 From: joachim at buechse.de (Joachim Buechse) Date: Mon, 20 Mar 2006 20:01:08 +0100 Subject: [Rxtx] BUG: Lock file stays even if port opening fails In-Reply-To: References: Message-ID: Hi Trent, What is your general feeling about moving code to Java? The last days I have been reading quite a bit of the code and there are several things, that might not work as expected. I'll give you two examples from is_device_locked: if LOCKDIR == /var/spool/locks the directory /var/spool/lock will not be checked. LOCKDIR is not checked for lockfiles with unexpected pefixes While these things have probably never been discovered in production, they are still possibly incorrect implementations. If it was Java code, I would write some unit tests producing the errors that could later be corrected. PS: One could imagine to actually implement the whole lockfile handling in Java using some native routines to get the values required (pid, st_dev, st_rdev, ...). On 20.03.2006, at 19:24, Trent Jarvi wrote: > On Mon, 20 Mar 2006, Joachim Buechse wrote: > >> This was only tested on MacOSX but looking at the code, it should >> be true for all systems that use lock_uucp. >> >> I am opening a port which can not be opened (dialup port of a >> telephone paired via bluetooth but currently not reachable). The >> lock file is created and stays arround, even though the port open >> failed. >> >> >> After looking a bit through the code (of 2.17), I really wonder if >> it wouldn't be a good idea to make the "locking" an explicit >> operation called from the java code. This would certainly simplify >> the generation of meaningfull exceptions (and java based debugging). >> Maybe even the handling of "preopened" ports should be in the Java >> part of the lib (again for java based debugging puposes). That >> beeing said, I have no idea if this would be possible for the 2.07 >> implementation. >> >> Regards, > > Hi Joachim > > It should be possible in the 2.0-7 implementation too. The calls > to RXTXPort.java would not change. We would just do more there > Moving more of that logic into Java would be better as many people > don't like to look at C code. There is a liblockdev on most Linux > distros that can do most of the C code and would be easier to use. > The problem is embeded devices will not have that library. > > The preopened port code has not been really tested. That was a > last minute request in a product cycle. I expect it will be tested > this year though. As I recall, some devices really do not like CD > raising on open. The preopened ports then allow people to mess > around in java without power cycling the devices or losing data. > > -- > Trent Jarvi > tjarvi at qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Mon Mar 20 12:21:02 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 20 Mar 2006 12:21:02 -0700 (MST) Subject: [Rxtx] BUG: Lock file stays even if port opening fails In-Reply-To: References: Message-ID: On Mon, 20 Mar 2006, Joachim Buechse wrote: > Hi Trent, > > What is your general feeling about moving code to Java? The last days I > have been reading quite a bit of the code and there are several things, > that might not work as expected. > > I'll give you two examples from is_device_locked: > > if LOCKDIR == /var/spool/locks the directory /var/spool/lock will not be > checked. > LOCKDIR is not checked for lockfiles with unexpected pefixes > > While these things have probably never been discovered in production, > they are still possibly incorrect implementations. If it was Java code, I > would write some unit tests producing the errors that could later be > corrected. > > PS: One could imagine to actually implement the whole lockfile handling > in Java using some native routines to get the values required (pid, > st_dev, st_rdev, ...). Hi Joachim I like the idea of moving more of the code into java but there are some things to consider. If you break this into multiple JNI calls, the performance will drop considerably during enumeration of ports. We are looking for 256 ports per dev type vs (16? in Sun's 2.0 and fewer types). Its hard to make assumptions. I've seen virtual ports start at /dev/foo100 for instance. It works out to over 7500 ports on Linux if you enable them all. We already trim that back by default. See Linux-all-ports in RXTXCommDriver.java. There are also native libraries that rxtx can link to. If you move too much into Java, linking to 'standard' libraries with distros will break. "configure --enable-liblock=yes" will not be doable. This is probably a favorable way with RedHat, Debian, Suse and others. Thats the right thing to do if there will be rpms, dpkg, .. For those reasons, I think it still make sense to keep it to a minimal ~3 calls to JNI code that we can use for speed and versatility. lock() isLocked(), unlock() perhaps. When I say speed, its more about avoiding crossing the JNI layer multiple times than java vs C performance. With versatility I think liblock is the right way for most but not all (embeded) linux distros. -- Trent Jarvi tjarvi at qbang.org From joachim at buechse.de Mon Mar 20 12:42:04 2006 From: joachim at buechse.de (Joachim Buechse) Date: Mon, 20 Mar 2006 20:42:04 +0100 Subject: [Rxtx] BUG: Lock file stays even if port opening fails In-Reply-To: References: Message-ID: <82C19FE7-DDCB-45B6-B2C9-7606B66F0124@buechse.de> Ok, what about providing a default implementation in Java? The RXTXCommDriver would call a (native) function useNativeLocking and if it returns true, call the native functions for lock() isLocked (), unlock(), else is would use the Java based default implementation. This could possibly be overriden by a property (again for debugging). Joachim On 20.03.2006, at 20:21, Trent Jarvi wrote: > On Mon, 20 Mar 2006, Joachim Buechse wrote: > >> Hi Trent, >> >> What is your general feeling about moving code to Java? The last >> days I have been reading quite a bit of the code and there are >> several things, that might not work as expected. >> >> I'll give you two examples from is_device_locked: >> >> if LOCKDIR == /var/spool/locks the directory /var/spool/lock will >> not be checked. >> LOCKDIR is not checked for lockfiles with unexpected pefixes >> >> While these things have probably never been discovered in >> production, they are still possibly incorrect implementations. If >> it was Java code, I would write some unit tests producing the >> errors that could later be corrected. >> >> PS: One could imagine to actually implement the whole lockfile >> handling in Java using some native routines to get the values >> required (pid, st_dev, st_rdev, ...). > > Hi Joachim > > I like the idea of moving more of the code into java but there are > some things to consider. > > If you break this into multiple JNI calls, the performance will > drop considerably during enumeration of ports. We are looking for > 256 ports per dev type vs (16? in Sun's 2.0 and fewer types). Its > hard to make assumptions. I've seen virtual ports start at /dev/ > foo100 for instance. > > It works out to over 7500 ports on Linux if you enable them all. > We already trim that back by default. See Linux-all-ports in > RXTXCommDriver.java. > > There are also native libraries that rxtx can link to. If you move > too much into Java, linking to 'standard' libraries with distros > will break. "configure --enable-liblock=yes" will not be doable. > This is probably a favorable way with RedHat, Debian, Suse and > others. Thats the right thing to do if there will be rpms, dpkg, .. > > For those reasons, I think it still make sense to keep it to a > minimal ~3 calls to JNI code that we can use for speed and > versatility. lock() isLocked(), unlock() perhaps. When I say > speed, its more about avoiding crossing the JNI layer multiple > times than java vs C performance. With versatility I think liblock > is the right way for most but not all (embeded) linux distros. > > -- > Trent Jarvi > tjarvi at qbang.org > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Mon Mar 20 12:44:47 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 20 Mar 2006 12:44:47 -0700 (MST) Subject: [Rxtx] BUG: Lock file stays even if port opening fails In-Reply-To: <82C19FE7-DDCB-45B6-B2C9-7606B66F0124@buechse.de> References: <82C19FE7-DDCB-45B6-B2C9-7606B66F0124@buechse.de> Message-ID: On Mon, 20 Mar 2006, Joachim Buechse wrote: > Ok, what about providing a default implementation in Java? > > The RXTXCommDriver would call a (native) function useNativeLocking and if > it returns true, call the native functions for lock() isLocked(), > unlock(), else is would use the Java based default implementation. This > could possibly be overriden by a property (again for debugging). > Hi Joachim That would be OK with me. -- Trent Jarvi tjarvi at qbang.org From dmarkman at mac.com Mon Mar 20 22:27:45 2006 From: dmarkman at mac.com (Dmitry Markman) Date: Tue, 21 Mar 2006 00:27:45 -0500 Subject: [Rxtx] binaries request Message-ID: <42702213-C222-4937-A585-7CFB17E47608@mac.com> Hi can somebody send me latest linux and windows binaries, please? or where I can find them (I didn't find them in the latest tareball) I gave up with my cygwin: something wrong I have no idea what java doesn't understand /cygwin/c syntax after I changed makefile it did java part but after that gcc 3.4.4 started to complain I set buffer length to 999 lines but I didn't get beginning of the story something wrong with my 1.4.2_09/include/jni.h gcc doesn't like it anyway I gave up thanks in advance Dmitry Markman -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060320/f8cbc57c/attachment-0049.html From tjarvi at qbang.org Mon Mar 20 22:36:48 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 20 Mar 2006 22:36:48 -0700 (MST) Subject: [Rxtx] binaries request In-Reply-To: <42702213-C222-4937-A585-7CFB17E47608@mac.com> References: <42702213-C222-4937-A585-7CFB17E47608@mac.com> Message-ID: On Tue, 21 Mar 2006, Dmitry Markman wrote: > Hi > can somebody send me latest linux and windows binaries, please? > > or where I can find them (I didn't find them in the latest tareball) > > I gave up with my cygwin: something wrong I have no idea what > java doesn't understand /cygwin/c syntax > after I changed makefile it did java part > but after that gcc 3.4.4 started to complain > I set buffer length to 999 lines but I didn't get beginning of the story > something wrong with my 1.4.2_09/include/jni.h gcc doesn't like it > anyway I gave up > > thanks in advance > Hi Dmitry The bins are here: ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7-bins-r2.zip Here are the files in the zip you want. Jar: rxtx-2.1-7-bins-r2/RXTXcomm.jar Windows: rxtx-2.1-7-bins-r2/Windows/i368-mingw32/rxtxSerial.dll Linux (x86) rxtx-2.1-7-bins-r2/Linux/i686-unknown-linux-gnu/librxtxSerial.so There are others in there including Parallel port support but those are the main ones for testing. -- Trent Jarvi tjarvi at qbang.org From dmarkman at mac.com Mon Mar 20 23:05:59 2006 From: dmarkman at mac.com (Dmitry Markman) Date: Tue, 21 Mar 2006 01:05:59 -0500 Subject: [Rxtx] binaries request In-Reply-To: References: <42702213-C222-4937-A585-7CFB17E47608@mac.com> Message-ID: thank you very much but windows's readme says: rxtxSerial.dll had to be recomopiled to link in missing native methods. should I ignore it? or what? thanks again also I understand that I should use mingw not cygwin I'll try to install mingw On Mar 21, 2006, at 12:36 AM, Trent Jarvi wrote: > On Tue, 21 Mar 2006, Dmitry Markman wrote: > >> Hi >> can somebody send me latest linux and windows binaries, please? >> >> or where I can find them (I didn't find them in the latest tareball) >> >> I gave up with my cygwin: something wrong I have no idea what >> java doesn't understand /cygwin/c syntax >> after I changed makefile it did java part >> but after that gcc 3.4.4 started to complain >> I set buffer length to 999 lines but I didn't get beginning of the >> story >> something wrong with my 1.4.2_09/include/jni.h gcc doesn't like it >> anyway I gave up >> >> thanks in advance >> > > Hi Dmitry > > The bins are here: > > ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7-bins-r2.zip > > Here are the files in the zip you want. > > Jar: > > rxtx-2.1-7-bins-r2/RXTXcomm.jar > > Windows: > > rxtx-2.1-7-bins-r2/Windows/i368-mingw32/rxtxSerial.dll > > Linux (x86) > > rxtx-2.1-7-bins-r2/Linux/i686-unknown-linux-gnu/librxtxSerial.so > > There are others in there including Parallel port support but those > are the main ones for testing. > > -- > Trent Jarvi > tjarvi at qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx Dmitry Markman From tjarvi at qbang.org Mon Mar 20 23:20:33 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 20 Mar 2006 23:20:33 -0700 (MST) Subject: [Rxtx] binaries request In-Reply-To: References: <42702213-C222-4937-A585-7CFB17E47608@mac.com> Message-ID: On Tue, 21 Mar 2006, Dmitry Markman wrote: > thank you very much > > but windows's readme says: > rxtxSerial.dll had to be recomopiled to link in missing native methods. > > should I ignore it? or what? > Hi Dmitry That dll should be OK. r2 is the recompile linked to the missing native method. The readme explains why it was recompiled; fuser.o was not linked into the dll in the first release. -- Trent Jarvi tjarvi at qbang.org From ariantristan at yahoo.com Mon Mar 20 23:55:24 2006 From: ariantristan at yahoo.com (Lambok Sianturi) Date: Mon, 20 Mar 2006 22:55:24 -0800 (PST) Subject: [Rxtx] jvm issue Message-ID: <20060321065524.94779.qmail@web50701.mail.yahoo.com> Hi All, This is my first time to join RxTx mailing list. I thank you all for allowing others to sign in in requests help. I use the latest RxTx lib in Fedora 3 with java version 1.4.2_09 b05. And I got this error: # # An unexpected error has been detected by HotSpot Virtual Machine: # # SIGSEGV (0xb) at pc=0x00bf27f3, pid=2633, tid=3086112448 # # Java VM: Java HotSpot(TM) Client VM (1.4.2_09-b05 mixed mode) # Problematic frame: # C [ld-linux.so.2+0xa7f3] # # An error report file with more information is saved as hs_err_pid2633.log # # If you would like to submit a bug report, please visit: # http://java.sun.com/webapps/bugreport/crash.jsp # ./run.sh: line 3: 2633 Aborted /usr/local/java/bin/java -Djava.library.path=/usr/local/java/jre/lib/ -Djsmsengine.debug=true -classpath jsmsengine.jar:smsgateway.jar:classes12.jar:RXTXcomm.jar:. com.api.sms.SMSServer What is the jvm depedency for the latest library? Can I use 1.4.2_09 b05? Thanks in advance. Arian --------------------------------- Yahoo! Mail Use Photomail to share photos without annoying attachments. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060320/83d58dd7/attachment-0049.html From f.frumento at ngi.it Tue Mar 21 00:21:47 2006 From: f.frumento at ngi.it (Fabio Frumento) Date: Tue, 21 Mar 2006 08:21:47 +0100 Subject: [Rxtx] Javadoc on the go Message-ID: <441FA98B.9050701@ngi.it> Hi Trent, sorry for the big delay but my job is running wild, i was out for some time but now i'm back and ready to continue the javadoc for Rxtx. Did you used the last javadoc patch i sent you ? let me know if i have to send it to you again or not. regards Fabio From lyon at docjava.com Tue Mar 21 00:51:18 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Tue, 21 Mar 2006 02:51:18 -0500 Subject: [Rxtx] lock files Message-ID: Hi All, You know, if the use of lock files were under Java control (rather than a build-time decision), it might enable a more unified binary distro. It might also facilitate quick prototyping of non-lock file approaches to resolving serial port contention issues (i.e., mac-like approaches vs. linux approaches, etc.). I realize that this is a radical overhaul of the lock file policy issue. Also, it may harm performance. On the other hand, our benchmarks on JNI overhead for modern processors indicate performance impact should be minimal. Perhaps it is more of an issue with the toybox systems. Suppose there were a class with a reasonable default...someone might write: SerialPortLockPolicy.setPolicy(SerialPortLockPolicy.UNIX_LOCK_FILE); SerialPortLockPolicy.setPolicy(SerialPortLockPolicy.NO_LOCK_CHECKING); SerialPortLockPolicy.setPolicy(SerialPortLockPolicy.MAC_STYLE); Thus, we could have a run-time reconfiguration of the serial port lock policy. A special NO_LOCK version of the binary would no longer be required. Any thoughts on this? Thanks! - Doug From joachim at buechse.de Tue Mar 21 03:09:09 2006 From: joachim at buechse.de (Joachim Buechse) Date: Tue, 21 Mar 2006 11:09:09 +0100 Subject: [Rxtx] lock files In-Reply-To: References: Message-ID: <8E12916A-1B9A-4FF2-B684-E2D1C794221B@buechse.de> This is pretty much what I thought about when I suggested, that the default behaviour could be overwritten with a property. I am very much in favor of this approach. In particular this allows much easier debugging for PC based java developers. I think big parts of the Java (and maybe some parts of the C code) could use a bit of a structural workover (unit tests, javadoc, synchronization, etc). Maybe there should be a CVS branch for this experimental version. I'd be happy to contribute a first workover for some of the Java code. Designing for testability and implementing a good bunch of unit tests has been a strategy that worked quite well in the Java projects I lead. And it ultimately allows more liberal change permission. Regards, Joachim On 21.03.2006, at 08:51, Dr. Douglas Lyon wrote: > Hi All, > You know, if the use of lock files were > under Java control (rather than a build-time decision), > it might enable a more unified binary distro. It might also > facilitate quick prototyping of non-lock file approaches > to resolving serial port contention issues (i.e., mac-like > approaches vs. linux approaches, etc.). > > I realize that this is a radical overhaul of the lock file policy > issue. Also, it may harm performance. On the other hand, > our benchmarks on JNI overhead for modern processors indicate > performance impact should be minimal. Perhaps it is more of > an issue with the toybox systems. > > Suppose there were a class with a reasonable default...someone > might write: > SerialPortLockPolicy.setPolicy(SerialPortLockPolicy.UNIX_LOCK_FILE); > SerialPortLockPolicy.setPolicy(SerialPortLockPolicy.NO_LOCK_CHECKING); > SerialPortLockPolicy.setPolicy(SerialPortLockPolicy.MAC_STYLE); > > Thus, we could have a run-time reconfiguration of the serial port lock > policy. A special NO_LOCK version of the binary would no longer > be required. > > Any thoughts on this? > > Thanks! > - Doug > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From joachim at buechse.de Tue Mar 21 06:23:08 2006 From: joachim at buechse.de (Joachim Buechse) Date: Tue, 21 Mar 2006 14:23:08 +0100 Subject: [Rxtx] PATCH: use of ioctl(fd, TIOCEXCL) instead of lockfiles Message-ID: <923AE774-EEA2-4911-92D8-32BB27802C8B@buechse.de> Here is the patch for the ioctl(fd, TIOCEXCL). I have verified this only for OSX 10.4.5, hence it is only defined for APPLE. However, it should work at least for Solaris as well. If a process has requested TIOEXCL further open calls by other user processes will fail. The patch also disables uucp style locking for APPLE. Obviously this is discussable. I think it is the way to go, as it eliminates creating the lock directory which doesnt exist on the standard installation and it eliminates messing with the system group definitions (adding users to group uucp). Regarding the possibility of root processes opening a device which is locked - I consider this a feature not a potential problem. It is highly unlikely, that somebody is crazy enough to run a JavaVM as root (unless he has no other means of getting a restricted IP port opened, ie doesnt understand ipfw). Anyway, even if the process runs as root, it fails when calling ioctl(fd, TIOCEXCL). It could however still open the port to listen for RING events. I.e. a fax server which needs to see incoming calls but otherwise doesnt want to block the port. So the only case where the proposed mechanism fails is, if an incorrectly implemented process running as root conflicts with a user process. I think this can be accepted. Regards, Joachim PS: If this patch is generally accepted, the installer and Mac doku should obviously be changed as well. Index: SerialImp.c =================================================================== RCS file: /usr/local/cvsroot/rxtx-devel/src/SerialImp.c,v retrieving revision 1.46.2.187 diff -u -r1.46.2.187 SerialImp.c --- SerialImp.c 29 Jan 2006 22:19:04 -0000 1.46.2.187 +++ SerialImp.c 21 Mar 2006 12:59:16 -0000 @@ -656,6 +656,25 @@ fd=OPEN (filename, O_RDWR | O_NOCTTY | O_NONBLOCK ); } while (fd < 0 && errno==EINTR); +#ifdef OPEN_EXCL + // Note that open() follows POSIX semantics: multiple open() calls to + // the same file will succeed unless the TIOCEXCL ioctl is issued. + // This will prevent additional opens except by root-owned processes. + // See tty(4) ("man 4 tty") and ioctl(2) ("man 2 ioctl") for details. + + if (fd >= 0 && (ioctl(fd, TIOCEXCL) == -1)) + { + sprintf( message, "open: exclusive access denied for % s\n", + filename ); + report( message ); + report_error( message ); + + close(fd); + goto fail; + } +#endif /* OPEN_EXCL */ + + if( configure_port( fd ) ) goto fail; (*env)->ReleaseStringUTFChars( env, jstr, filename ); sprintf( message, "open: fd returned is %i\n", fd ); Index: SerialImp.h =================================================================== RCS file: /usr/local/cvsroot/rxtx-devel/src/SerialImp.h,v retrieving revision 1.11.2.49 diff -u -r1.11.2.49 SerialImp.h --- SerialImp.h 5 Jul 2005 17:47:21 -0000 1.11.2.49 +++ SerialImp.h 21 Mar 2006 12:59:17 -0000 @@ -135,7 +135,8 @@ /*# define LOCKDIR "/var/spool/uucp"*/ # define LOCKDIR "/var/lock" # define LOCKFILEPREFIX "LK." -# define UUCP +/*# define UUCP*/ +# define OPEN_EXCL #endif /* __APPLE__ */ #if defined(__NetBSD__) # define DEVICEDIR "/dev/" From tjarvi at qbang.org Tue Mar 21 10:26:08 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 21 Mar 2006 10:26:08 -0700 (MST) Subject: [Rxtx] Javadoc on the go In-Reply-To: <441FA98B.9050701@ngi.it> References: <441FA98B.9050701@ngi.it> Message-ID: On Tue, 21 Mar 2006, Fabio Frumento wrote: > Hi Trent, > > sorry for the big delay but my job is running wild, i was out for some > time but now i'm back and ready to continue the javadoc for Rxtx. > > Did you used the last javadoc patch i sent you ? let me know if i have to > send it to you again or not. > > regards > > Fabio Hi Fabio The patch is in the rxtx mail-list archives. It will be going in soon. I did not see a time critical portion. I'll probably be going through the list since the last batch of patches this weekend and putting them into CVS. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Tue Mar 21 10:57:18 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 21 Mar 2006 10:57:18 -0700 (MST) Subject: [Rxtx] jvm issue In-Reply-To: <20060321065524.94779.qmail@web50701.mail.yahoo.com> References: <20060321065524.94779.qmail@web50701.mail.yahoo.com> Message-ID: On Mon, 20 Mar 2006, Lambok Sianturi wrote: > Hi All, > This is my first time to join RxTx mailing list. I thank you all for allowing others to sign in in requests help. > I use the latest RxTx lib in Fedora 3 with java version 1.4.2_09 b05. And I got this error: > > # > # An unexpected error has been detected by HotSpot Virtual Machine: > # > # SIGSEGV (0xb) at pc=0x00bf27f3, pid=2633, tid=3086112448 > # > # Java VM: Java HotSpot(TM) Client VM (1.4.2_09-b05 mixed mode) > # Problematic frame: > # C [ld-linux.so.2+0xa7f3] A native library loading error? What happens if you recompile rxtx on your system and install that? This sounds like an ABI problem? rxtx 2.1-7 was compiled with a gcc 2.96 toolchain as I recall. The hope is newer system will be backwards compatible. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Tue Mar 21 11:05:29 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 21 Mar 2006 11:05:29 -0700 (MST) Subject: [Rxtx] PATCH: use of ioctl(fd, TIOCEXCL) instead of lockfiles In-Reply-To: <923AE774-EEA2-4911-92D8-32BB27802C8B@buechse.de> References: <923AE774-EEA2-4911-92D8-32BB27802C8B@buechse.de> Message-ID: On Tue, 21 Mar 2006, Joachim Buechse wrote: > Here is the patch for the ioctl(fd, TIOCEXCL). I have verified this only > for OSX 10.4.5, hence it is only defined for APPLE. However, it should > work at least for Solaris as well. > > If a process has requested TIOEXCL further open calls by other user > processes will fail. > > The patch also disables uucp style locking for APPLE. Obviously this is > discussable. I think it is the way to go, as it eliminates creating the > lock directory which doesnt exist on the standard installation and it > eliminates messing with the system group definitions (adding users to > group uucp). > > Regarding the possibility of root processes opening a device which is > locked - I consider this a feature not a potential problem. It is highly > unlikely, that somebody is crazy enough to run a JavaVM as root (unless > he has no other means of getting a restricted IP port opened, ie doesnt > understand ipfw). Anyway, even if the process runs as root, it fails when > calling ioctl(fd, TIOCEXCL). It could however still open the port to > listen for RING events. I.e. a fax server which needs to see incoming > calls but otherwise doesnt want to block the port. So the only case where > the proposed mechanism fails is, if an incorrectly implemented process > running as root conflicts with a user process. I think this can be > accepted. > > Regards, > Joachim > > PS: If this patch is generally accepted, the installer and Mac doku > should obviously be changed as well. > > > Index: SerialImp.c > =================================================================== > RCS file: /usr/local/cvsroot/rxtx-devel/src/SerialImp.c,v > retrieving revision 1.46.2.187 > diff -u -r1.46.2.187 SerialImp.c > --- SerialImp.c 29 Jan 2006 22:19:04 -0000 1.46.2.187 > +++ SerialImp.c 21 Mar 2006 12:59:16 -0000 > @@ -656,6 +656,25 @@ > fd=OPEN (filename, O_RDWR | O_NOCTTY | O_NONBLOCK ); > } while (fd < 0 && errno==EINTR); > > +#ifdef OPEN_EXCL > + // Note that open() follows POSIX semantics: multiple open() > calls to > + // the same file will succeed unless the TIOCEXCL ioctl is > issued. > + // This will prevent additional opens except by root-owned > processes. > + // See tty(4) ("man 4 tty") and ioctl(2) ("man 2 ioctl") for > details. > + > + if (fd >= 0 && (ioctl(fd, TIOCEXCL) == -1)) > + { > + sprintf( message, "open: exclusive access denied for % > s\n", > + filename ); > + report( message ); > + report_error( message ); > + > + close(fd); > + goto fail; > + } > +#endif /* OPEN_EXCL */ > + > + > if( configure_port( fd ) ) goto fail; > (*env)->ReleaseStringUTFChars( env, jstr, filename ); > sprintf( message, "open: fd returned is %i\n", fd ); > Index: SerialImp.h > =================================================================== > RCS file: /usr/local/cvsroot/rxtx-devel/src/SerialImp.h,v > retrieving revision 1.11.2.49 > diff -u -r1.11.2.49 SerialImp.h > --- SerialImp.h 5 Jul 2005 17:47:21 -0000 1.11.2.49 > +++ SerialImp.h 21 Mar 2006 12:59:17 -0000 > @@ -135,7 +135,8 @@ > /*# define LOCKDIR "/var/spool/uucp"*/ > # define LOCKDIR "/var/lock" > # define LOCKFILEPREFIX "LK." > -# define UUCP > +/*# define UUCP*/ > +# define OPEN_EXCL > #endif /* __APPLE__ */ > #if defined(__NetBSD__) > # define DEVICEDIR "/dev/" > This looks like a good start. What do you think Dmitry? Perhaps all systems with TIOCEXCL defined should use that though. Even if they use lockfiles. It wont hurt anything. That would catch people hacking their own serial apps without checking lockfiles. Its a good idea to avoid C++ style comments in the C portions. Some older systems don't deal with them well. If it's just for Mac OS X, it isn't a big deal. I think it was the Irix compiler that was problematic? -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Tue Mar 21 11:22:05 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 21 Mar 2006 11:22:05 -0700 (MST) Subject: [Rxtx] lock files In-Reply-To: <8E12916A-1B9A-4FF2-B684-E2D1C794221B@buechse.de> References: <8E12916A-1B9A-4FF2-B684-E2D1C794221B@buechse.de> Message-ID: We can try it. Maybe the JNI is much improved. The nice thing about linking into liblock is distros then worry about lockfiles on their systems. This way, we have to deal with any changes that may show up. On Tue, 21 Mar 2006, Joachim Buechse wrote: > This is pretty much what I thought about when I suggested, that the > default behaviour could be overwritten with a property. I am very much in > favor of this approach. In particular this allows much easier debugging > for PC based java developers. > > I think big parts of the Java (and maybe some parts of the C code) could > use a bit of a structural workover (unit tests, javadoc, synchronization, > etc). Maybe there should be a CVS branch for this experimental version. > I'd be happy to contribute a first workover for some of the Java code. > Designing for testability and implementing a good bunch of unit tests has > been a strategy that worked quite well in the Java projects I lead. And > it ultimately allows more liberal change permission. > > Regards, > Joachim > > > On 21.03.2006, at 08:51, Dr. Douglas Lyon wrote: > >> Hi All, >> You know, if the use of lock files were >> under Java control (rather than a build-time decision), >> it might enable a more unified binary distro. It might also >> facilitate quick prototyping of non-lock file approaches >> to resolving serial port contention issues (i.e., mac-like >> approaches vs. linux approaches, etc.). >> >> I realize that this is a radical overhaul of the lock file policy >> issue. Also, it may harm performance. On the other hand, >> our benchmarks on JNI overhead for modern processors indicate >> performance impact should be minimal. Perhaps it is more of >> an issue with the toybox systems. >> >> Suppose there were a class with a reasonable default...someone >> might write: >> SerialPortLockPolicy.setPolicy(SerialPortLockPolicy.UNIX_LOCK_FILE); >> SerialPortLockPolicy.setPolicy(SerialPortLockPolicy.NO_LOCK_CHECKING); >> SerialPortLockPolicy.setPolicy(SerialPortLockPolicy.MAC_STYLE); >> >> Thus, we could have a run-time reconfiguration of the serial port lock >> policy. A special NO_LOCK version of the binary would no longer >> be required. >> >> Any thoughts on this? >> >> Thanks! >> - Doug >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From dmarkman at mac.com Tue Mar 21 16:05:17 2006 From: dmarkman at mac.com (Dmitry Markman) Date: Tue, 21 Mar 2006 18:05:17 -0500 Subject: [Rxtx] PATCH: use of ioctl(fd, TIOCEXCL) instead of lockfiles In-Reply-To: References: <923AE774-EEA2-4911-92D8-32BB27802C8B@buechse.de> Message-ID: <512AC70C-BB86-48F2-A83C-023F35C23BAB@mac.com> I think it's cool, but I'd like to have that property implementation when user can choose between locking mechanism about comments: it's easy to change comments to the C style or we can use extensions of the file to cpp so c++ compiler will be used On Mar 21, 2006, at 1:05 PM, Trent Jarvi wrote: > This looks like a good start. What do you think Dmitry? Perhaps > all systems with TIOCEXCL defined should use that though. Even if > they use lockfiles. It wont hurt anything. That would catch > people hacking their own serial apps without checking lockfiles. > > Its a good idea to avoid C++ style comments in the C portions. > Some older systems don't deal with them well. If it's just for Mac > OS X, it isn't a big deal. I think it was the Irix compiler that > was problematic? Dmitry Markman From dmarkman at mac.com Tue Mar 21 16:13:00 2006 From: dmarkman at mac.com (Dmitry Markman) Date: Tue, 21 Mar 2006 18:13:00 -0500 Subject: [Rxtx] PATCH: use of ioctl(fd, TIOCEXCL) instead of lockfiles In-Reply-To: References: <923AE774-EEA2-4911-92D8-32BB27802C8B@buechse.de> Message-ID: I'd like to add that creating locking folder isn't a big deal we never had a problem related to the lock folders, because we always used installer on mac os x from other hand I'm not very much familiar with iotcl locking approach and I'm not sure it's more efficient Joachim wrote "I think it is the way to go, as it eliminates creating the lock directory which doesnt exist on the standard installation and it eliminates messing with the system group definitions (adding users to group uucp)." but I really didn't have any problem with that 1. doesn't exist on the standard installation there are many-many things that don't exist in the standard installation so I don't think that argument is strong enough 2. messing with the system group definitions I don't think we're messing with the group definition mac os x provides very clear way to set up group's members and together with Greg Guerin AuthKit there is no problem to set those definitions so I don't think that argument is strong either but from other hand using iotcl is more promising and is more elegant On Mar 21, 2006, at 1:05 PM, Trent Jarvi wrote: > > This looks like a good start. What do you think Dmitry? Perhaps > all systems with TIOCEXCL defined should use that though. Even if > they use lockfiles. It wont hurt anything. That would catch > people hacking their own serial apps without checking lockfiles. Dmitry Markman From joachim at buechse.de Wed Mar 22 04:46:45 2006 From: joachim at buechse.de (Joachim Buechse) Date: Wed, 22 Mar 2006 12:46:45 +0100 Subject: [Rxtx] PATCH: use of ioctl(fd, TIOCEXCL) instead of lockfiles In-Reply-To: References: <923AE774-EEA2-4911-92D8-32BB27802C8B@buechse.de> Message-ID: Sorry, I was not very clear with my arguments, so I will try again;-) Please, don't take this as an attack against work that has been done. I think the contributions that have been made in the past were made in a good spirit. But I really believe, that the current solution for OSX has many shortcomings and should be changed as soon as possible. lock files --- The /var/lock folder does not exist on the standard OSX installation, however the standard installation includes several applications that use serial ports (i.e. the FAX capability). This indicates, that the lock folder approach will not work well with system components. Applications for OSX will generally try to live in harmony with system components (except for HP print drivers of course). I think RXTX should follow this approach as well. uucp group --- Accessing serial ports is not an admin privileged operation on OSX. Any user (world) has read/write privileges on /dev/tty*. So the system default is to not enforce any group membership to access these ports. The group uucp however is a system group on all unix systems I know. It exists for certain system processes. A non admin user should in general not be a member of this group. Quite arguably no user should ever be a member of this group. Installer --- My general opinion is, that - no Installer should touch user or group data without warning - no Application Installer should touch groups which are not specific to the very application installed - no Installer should ever add regular users to a system group The current installer injects the installing user in the group uucp without warning about this change and without giving the option to "opt out" of this change. This is a potential security risk (but not currently a real one, as OSX contains no folders belonging to group uucp). The current installer does not work for multi user systems. It puts the installing user in the uucp group. However the installing user is not necessarily the user that will use the application. Putting all users that may use a serial port application in the system group uucp seems like a very invasive approach to me. Besides that, newly created users will not automatically be in the group and hence, serial applications will "break" for new users without obvious reasons. Avoiding the lock files will allow self contained applications (i.e. drag&drop installation). In my eyes this is largely preferable over an installer that requests admin privileges. Adding up all these points indicates very strongly, that the lock-file implementation is not the way to go on OSX. Regards, Joachim On 22.03.2006, at 00:13, Dmitry Markman wrote: > I'd like to add that > > creating locking folder isn't a big deal > we never had a problem related to the lock folders, because we > always used installer on mac os x > from other hand I'm not very much familiar with iotcl locking > approach and I'm not sure it's more efficient > > Joachim wrote "I think it is the way to go, as it eliminates > creating the lock directory which doesnt exist on the standard > installation and it eliminates messing with the system group > definitions (adding users to group uucp)." but I really didn't have > any problem with that > > 1. doesn't exist on the standard installation > there are many-many things that don't exist in the standard > installation so I don't think that argument is strong enough > 2. messing with the system group definitions > I don't think we're messing with the group definition > mac os x provides very clear way to set up group's members and > together with Greg Guerin AuthKit there is no problem to set those > definitions > so I don't think that argument is strong either > but from other hand using iotcl is more promising and is more elegant > > > > On Mar 21, 2006, at 1:05 PM, Trent Jarvi wrote: > >> >> This looks like a good start. What do you think Dmitry? Perhaps >> all systems with TIOCEXCL defined should use that though. Even if >> they use lockfiles. It wont hurt anything. That would catch >> people hacking their own serial apps without checking lockfiles. > > Dmitry Markman > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From dmarkman at mac.com Wed Mar 22 05:27:13 2006 From: dmarkman at mac.com (Dmitry Markman) Date: Wed, 22 Mar 2006 07:27:13 -0500 Subject: [Rxtx] PATCH: use of ioctl(fd, TIOCEXCL) instead of lockfiles In-Reply-To: References: <923AE774-EEA2-4911-92D8-32BB27802C8B@buechse.de> Message-ID: <83440CF3-DCD8-41C1-B941-F227232C27E3@mac.com> thanks for the very good explanation I didn't think that you were attacking any thing, so don't worry I just had feeling, that there were more aesthetic reasons for going to ioctl then real necessity now you explained everything quite well (BTW, asfar as I remember installer asks admin password so it wasn't quiet, but it really doesn't matter now) thanks On Mar 22, 2006, at 6:46 AM, Joachim Buechse wrote: > Sorry, I was not very clear with my arguments, so I will try again;-) > > Please, don't take this as an attack against work that has been > done. I think the contributions that have been made in the past > were made in a good spirit. But I really believe, that the current > solution for OSX has many shortcomings and should be changed as > soon as possible. > > lock files > --- > The /var/lock folder does not exist on the standard OSX > installation, however the standard installation includes several > applications that use serial ports (i.e. the FAX capability). This > indicates, that the lock folder approach will not work well with > system components. Applications for OSX will generally try to live > in harmony with system components (except for HP print drivers of > course). I think RXTX should follow this approach as well. > > uucp group > --- > Accessing serial ports is not an admin privileged operation on OSX. > Any user (world) has read/write privileges on /dev/tty*. So the > system default is to not enforce any group membership to access > these ports. The group uucp however is a system group on all unix > systems I know. It exists for certain system processes. A non admin > user should in general not be a member of this group. Quite > arguably no user should ever be a member of this group. > > Installer > --- > My general opinion is, that > - no Installer should touch user or group data without warning > - no Application Installer should touch groups which are not > specific to the very application installed > - no Installer should ever add regular users to a system group > > The current installer injects the installing user in the group uucp > without warning about this change and without giving the option to > "opt out" of this change. This is a potential security risk (but > not currently a real one, as OSX contains no folders belonging to > group uucp). > > The current installer does not work for multi user systems. It puts > the installing user in the uucp group. However the installing user > is not necessarily the user that will use the application. Putting > all users that may use a serial port application in the system > group uucp seems like a very invasive approach to me. Besides that, > newly created users will not automatically be in the group and > hence, serial applications will "break" for new users without > obvious reasons. > > > Avoiding the lock files will allow self contained applications > (i.e. drag&drop installation). In my eyes this is largely > preferable over an installer that requests admin privileges. Adding > up all these points indicates very strongly, that the lock-file > implementation is not the way to go on OSX. > > Regards, > Joachim > > > On 22.03.2006, at 00:13, Dmitry Markman wrote: > >> I'd like to add that >> >> creating locking folder isn't a big deal >> we never had a problem related to the lock folders, because we >> always used installer on mac os x >> from other hand I'm not very much familiar with iotcl locking >> approach and I'm not sure it's more efficient >> >> Joachim wrote "I think it is the way to go, as it eliminates >> creating the lock directory which doesnt exist on the standard >> installation and it eliminates messing with the system group >> definitions (adding users to group uucp)." but I really didn't >> have any problem with that >> >> 1. doesn't exist on the standard installation >> there are many-many things that don't exist in the standard >> installation so I don't think that argument is strong enough >> 2. messing with the system group definitions >> I don't think we're messing with the group definition >> mac os x provides very clear way to set up group's members and >> together with Greg Guerin AuthKit there is no problem to set those >> definitions >> so I don't think that argument is strong either >> but from other hand using iotcl is more promising and is more elegant >> >> >> >> On Mar 21, 2006, at 1:05 PM, Trent Jarvi wrote: >> >>> >>> This looks like a good start. What do you think Dmitry? Perhaps >>> all systems with TIOCEXCL defined should use that though. Even >>> if they use lockfiles. It wont hurt anything. That would catch >>> people hacking their own serial apps without checking lockfiles. >> >> Dmitry Markman >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx Dmitry Markman From lyon at docjava.com Wed Mar 22 06:12:18 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Wed, 22 Mar 2006 08:12:18 -0500 Subject: [Rxtx] sole of a new design pattern Message-ID: Hi All, I have been thinking about how we design the serial port software. I think we need a new design pattern. For lack of a better term, I shall call it: The Parametric Singleton Design Pattern By Douglas A. Lyon ABSTRACT The goal of the singleton design pattern is to make sure that there is one, and only one, instance of a given class. The goal of the parametric singleton design pattern is to make sure that there is one, and only one, instance of a given class with the given parametric values. We parametric singleton design pattern combines the singleton design pattern with a parameter that enables unique creation of instances of a class. These instances are cached. When a user asks for an instance with these parameters, the cache is checked. If the instance is in the cache, the instance is returned, otherwise it is created, added to the cache and then returned. We apply our parametric singleton design pattern to the retrieval of RMI registries bound to a given port. The goal of our system is to make sure that no two RMI registries are listening to the same socket and to make use of the RMI registries after they have been created. RMI registries are used in distributed computation. Introduction The singleton design pattern is meant to ensure that on a single instance of a class exists. It is also meant to provide a global point of access to it. The intent of the parametric singleton design pattern is to ensure that a class has only one instance for a given set of parameter values. It also provides a global point of access to it. Motivation A system cannot tolerate multiple instances of some classes with identical parameters. For example, you cannot have two instances making use of the same serial port, at the same time. You cannot have two instances that are trying to listen to the same socket connection. You cannot have two instances writing to the same file structure at the same time. As the operating system is often thought of as the arbiter of consumed resources (i.e., tape drives, serial ports, etc.) we frequently leave it to an operating system implementation to resolve these contention issues. Even for similar resources (like serial ports) there are few standards for handling contention. For example, serial ports on Linux are locked using a "/var/lock" file. POSIX, on the other hand, uses ioctl mechanisms to prevent contention. A better solution is to make a class that is responsible for keeping track of the instances created from the class. The class is declared final, so that it cannot be subclassed. The class also has a private constructor, so that other classes cannot instance it. The new design pattern is called the parametric singleton design pattern and it provides a way to access and create instances with given parameters. Applicability Use the Parametric Singleton Design Pattern when: 1. There must be exactly one instance of a class with the given parameters. 2. The instances must be accessible to clients from a well-known access point. Structure Insert UML diagram here. Participants The Parametric Singleton Clients that need instances 1. The Parametric Singleton defines an instance upon request from a client, if, and only if, the instance does not already exist. 2. The Parametric Singleton returns the instance to the client. 3. The Parametric Singleton is responsible for creating unique instances from given parameters. Collaborations Clients obtain a reference to a Parametric Singleton instance only through the parametric singleton design pattern. If the instance is left in an improper state (e.g., the serial port was left open) it is NOT the role of the Parametric Singleton Design Pattern to close the IO port. Nor is it the role of the Parametric Singleton Design Pattern to open the port. That role is delegate to some other part of the system. Further, it is not the role of the Parametric Singleton Design Pattern to check out resources. That is, multiple threads can have multiple references to the same resource at the same time. MUTEX locking is delegated to some other part of the system. Consequences The Parametric Singleton Design Pattern has several benefits: 1. Controlled access to parametrically defined instances. Since the Parametric Singleton class encapsulates its instances, there is control over how and when clients access it. 2. Reduced name space. The Parametric Singleton pattern avoids global variables that store instances created from the same parameter. Implementation Here are implementation issues to consider when using the Parametric Singleton pattern: 1. Unique mapping of parameters. The Parametric Singleton pattern requires that there be a mean to isomorphically map the parameter space into the instance space and back again. 2. Ensure unique instances. The Parametric Singleton pattern makes unique instances from parameters, and it does so only once. 3. Cache instances for fast retrieval. The Parametric Singleton pattern must be able to look up instances, given some set of parameters, and do so from some data structure. That is, there must be enough space to hold references to all the instances the program will need. Also, a mechanism is needed to look up and retrieve the instances quickly enough to satisfy the clients. Sample Code public final class ParametricSingletonRmiRegistry { private static Hashtable registry = new Hashtable(100); // use singleton pattern and??????????????????????????????????????????????? // prevent instantiation of RmiRegistryUtils.?????????????????????????????? private ParametricSingletonRmiRegistry() { } // the only instance of the Registry held by the RmiRegistryUtils?????????? public static void listNames(Integer port) { if (!isInCacheAndRunning(port)) return; Registry r = (Registry) registry.get(port); System.out.println("registry on port: " + port); System.out.println("registry: " + r); System.out.println("names: "); try { print(r.list()); } catch (RemoteException e) { In.message(e); } System.out.println("------------------------"); } /**???????????????????????????????????????????????????????????????????????? * Checks whether a Registry has been started on this host????????????????? * in the specified port.?????????????????????????????????????????????????? * If not, it tries to start one.?????????????????????????????????????????? * when it fails to start a Registry, it exits the program????????????????? * with exit code 1.??????????????????????????????????????????????????????? */ public static void restart(int port) { if (isInCacheAndRunning(port)) return; try { startRegistry(port); } catch (RemoteException e) { In.message(e); } } /**???????????????????????????????????????????????????????????????????????? * @param port????????????????????????????????????????????????????????????? * @return true if registry is in cache and running???????????????????????? */ private static boolean isInCacheAndRunning(Integer port) { if (!isRegistryRunning(port.intValue())) return false; if (!isRegistryInCache(port.intValue())) return false; return true; } /**???????????????????????????????????????????????????????????????????????? * @param port????????????????????????????????????????????????????????????? * @return true if we are able to locate a local registry on port.??????????????????????????????????????????????????????????????????????????? */ private static boolean isRegistryRunning(int port) { try { Registry r = LocateRegistry.getRegistry(port); if (r != null) return true; } catch (RemoteException e) { return false; } return false; } /**???????????????????????????????????????????????????????????????????????? * @param port????????????????????????????????????????????????????????????? * @return return true if registry is in cache????????????????????????????? */ private static boolean isRegistryInCache(int port) { if (registry.get(new Integer(port)) == null) return false; return true; } /**???????????????????????????????????????????????????????????????????????? * Restart the registry, if needed.???????????????????????????????????????? * Return the only instance of the registry for consistent global?????????? * using by making use of the Singleton Design Pattern????????????????????? *????????????????????????????????????????????????????????????????????????? * @return the internally held registry instance.?????????????????????????? */ public static Registry getRegistry(Integer port) { restart(port); return (Registry) registry.get(port); } private static void startRegistry(Integer port) throws RemoteException { Registry r; try { r = LocateRegistry.createRegistry(port.intValue()); registry.put(port, r); //r = new sun.rmi.registry.RegistryImpl???????????????????????????? /// (port.intValue());?????????????????????????????????????? // registry.put(port, r);?????????????????????????????????????????? } catch (Exception e) { //e.printStackTrace();????????????????????????????????????????????? r = LocateRegistry.getRegistry(port.intValue()); registry.put(port, r); } } public static void main(String args[]) throws RemoteException { //restart(port);??????????????????????????????????????????????????????? restart(5001); restart(5002); restart(5002); Registry r = LocateRegistry.getRegistry(5002); System.out.println("registry="+r); } } I would very much like to get your feedback on this new design pattern idea. Thank you for your time. Regards, - Doug From david.garnier at trusted-logic.com Wed Mar 22 07:36:10 2006 From: david.garnier at trusted-logic.com (David Garnier) Date: Wed, 22 Mar 2006 15:36:10 +0100 Subject: [Rxtx] sole of a new design pattern In-Reply-To: References: Message-ID: <442160DA.80107@trusted-logic.com> Hello, > The Parametric Singleton Design Pattern The Singleton is the most abused design pattern ever. Good use-cases for this pattern are extremely rare and mostly confined to problems related to hardware resources, like serial ports. > Applicability > > Use the Parametric Singleton Design Pattern when: > 1. There must be exactly one instance of a class with the given > parameters. OK. As I said above, this case this actually very unusual. The Singleton pattern is mostly used when : > 2. The instances must be accessible to clients from a well-known > access point. Using the singleton pattern in this case is just convenient for the programmer. Problems arises pretty quickly, especially if you attempt to unit-test your classes. 1) If your singleton is stateful, or hold on to stateful objects, it means that two different unit tests are not actually independent. Instead of starting with a brand new environment, the result of a test may be affected by the result of a previous test. This problem also arise when with your class relies on a database. In both cases, the solution is to reset your "unique" resource (Singleton or database) at the beginning of the test, which is a pain. Also, while most projects connect to a single database, projects that allow the use of Singletons usually contain several of thems, and new ones may cropped up unnoticed. You quickly end up with test cases that only pass in a certain order, which is a royal pain. 2) You cannot mockup a singleton. Once everyone calls the SomeSingleton class statically, you can't replace your class by SomeSingletonMockup. Furthermore, even for hardware services, the Singleton pattern does not really prevent concurrent accesses. If you start the same program in two different JVMs, unless they somehow shared the state of their "Singletons" (through lock files for example), the Singleton pattern will not prevent concurrent access. Our application uses RXTX, and we routinely encounter cases where another (native) application has already locked the port. Since we cannot modify the native application to recognize lock files, OS-level control is irreplaceable. > > Consequences > The Parametric Singleton Design Pattern has several benefits: > > 1. Controlled access to parametrically defined instances. Since > the Parametric Singleton class encapsulates its instances, there is > control over how and when clients access it. Not really. Once you've returned the instance to a client, you've lost control over it. The client can to whatever it wants with it. You cannot "recall" the instance or claim it back. > 2. Reduced name space. The Parametric Singleton pattern avoids > global variables that store instances created from the same parameter. Sure, but you don't have to rely on a Singleton for that. Just create a single Factory. > I would very much like to get your feedback on this new design > pattern idea. Well, it's nothing new. Some may say that it is the point of design patterns: formalizes the designs that occur again and again. However, this design is simply a combination of the Singleton and Factory patterns. I did use it in the past, but now I've been exposed to the shortcomings of the Singleton pattern, so I limit myself to Factories. Regards, David From sean_montgomery at baseview.com Wed Mar 22 08:35:28 2006 From: sean_montgomery at baseview.com (Sean Montgomery) Date: Wed, 22 Mar 2006 10:35:28 -0500 Subject: [Rxtx] sole of a new design pattern In-Reply-To: <442160DA.80107@trusted-logic.com> References: <442160DA.80107@trusted-logic.com> Message-ID: <05769CA7-A51B-4CF0-BAA0-E02DD905F5A4@baseview.com> On Mar 22, 2006, at 9:36 AM, David Garnier wrote: > Furthermore, even for hardware services, the Singleton pattern does > not really prevent concurrent > accesses. If you start the same program in two different JVMs, > unless they somehow shared the state > of their "Singletons" (through lock files for example), the > Singleton pattern will not prevent > concurrent access. > Multiple class loaders in a single JVM can be tricky, too. Then there's synchronization, lazy initialization and serialization of singletons to contend with. Bloch's Effective Java covers these, and here's a few articles: http://www.javaworld.com/javaworld/jw-04-2003/jw-0425-designpatterns- p3.html http://java.sun.com/developer/technicalArticles/Programming/singletons/ Just FYI :-) From lyon at docjava.com Wed Mar 22 08:50:48 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Wed, 22 Mar 2006 10:50:48 -0500 Subject: [Rxtx] sole of a new design pattern In-Reply-To: <442160DA.80107@trusted-logic.com> References: <442160DA.80107@trusted-logic.com> Message-ID: Hi All, First, I would like to thank David for his prompt and thoughtful remarks. I had no idea people that feel strongly about a design patterns! Wow! Feedback (particularly critical feedback) is greatly appreciated. Starting at the end, first: >I did use it in >the past, but now I've been exposed to the shortcomings of the >Singleton pattern, so I limit myself to Factories. David, if I understood your comments correctly, you suggested that Factories can be used in leu of the Singleton Design Pattern, or even the Parametric Singleton Design Pattern. As I see in [Gof]: Factory Method: Intent "Define an interface for creating an object, but let subclasses decide which class to instantiate. Factory Method lets a class defer instantiation to subclasses." The Singleton Design Pattern is a concrete class, which is rather different, right? Also, subclasses are not permitted with Singleton, as they are final. Naturally, I could use an abstract factory as a parent for a singleton. I could even design a facade that could be implemented with the singleton....but that is not the intention of the design. Unless you want a mock-up, as discussed, below: More below: >Hello, > >> The Parametric Singleton Design Pattern > >The Singleton is the most abused design pattern ever. Good use-cases >for this pattern are extremely >rare and mostly confined to problems related to hardware resources, >like serial ports. > > >> Applicability >> >> Use the Parametric Singleton Design Pattern when: >> 1. There must be exactly one instance of a class with the given >> parameters. >OK. As I said above, this case this actually very unusual. The >Singleton pattern is mostly used when : >> 2. The instances must be accessible to clients from a well-known >> access point. > >Using the singleton pattern in this case is just convenient for the >programmer. Problems arises >pretty quickly, especially if you attempt to unit-test your classes. > >1) If your singleton is stateful, or hold on to stateful objects, it >means that two different unit >tests are not actually independent. Instead of starting with a brand >new environment, the result of >a test may be affected by the result of a previous test. This >problem also arise when with your >class relies on a database. In both cases, the solution is to reset >your "unique" resource >(Singleton or database) at the beginning of the test, which is a >pain. Also, while most projects >connect to a single database, projects that allow the use of >Singletons usually contain several of >thems, and new ones may cropped up unnoticed. You quickly end up >with test cases that only pass in a >certain order, which is a royal pain. There are basic problems with communicating finite state machines that include reachability and deadlock analysis. These are addressed with petri net analysis and are beyond the scope of the design pattern. As you quite rightly pointed out; the parametric singleton pattern (or the singleton pattern, for that matter) enable multiple threads to gain access to the same instance. The only way that I can see to block others from gaining access to the reference is the synchronize keyword. This is putting a spin-lock (or MUTEX) on the reference. The question of how to unit-test a design pattern like the parametric singleton remains open. Perhaps this is a deficiency. > >2) You cannot mockup a singleton. Once everyone calls the >SomeSingleton class statically, you can't >replace your class by SomeSingletonMockup. Acutally, I am not sure that this is true. If the Singleton implements a Facade interface, it should be possible to make the replacement. Right? > >Furthermore, even for hardware services, the Singleton pattern does >not really prevent concurrent >accesses. If you start the same program in two different JVMs, >unless they somehow shared the state >of their "Singletons" (through lock files for example), the >Singleton pattern will not prevent >concurrent access. Good Point!! You have sharp eyes! The singleton design pattern should/could take responsibility for this. In fact, you may notice that my code does have an implementation (LocateRegistry) that can work across JVM's. The LocateRegistry will even work across the Internet! LocateRegistry takes both a host name and a Port (lock files just don't do this). I did not think to implement this beyond the local machine, but, in its present form, it will work across different processes. > >Our application uses RXTX, and we routinely encounter cases where >another (native) application has >already locked the port. Since we cannot modify the native >application to recognize lock files, >OS-level control is irreplaceable. The singleton design pattern is not meant to replace OS-level control, but to centralize the Java programmers access to it. If lock files, for example, are used for serial ports, the Singleton Design Pattern should be able to work with them. > > >> >> Consequences >> The Parametric Singleton Design Pattern has several benefits: >> > > 1. Controlled access to parametrically defined instances. Since >> the Parametric Singleton class encapsulates its instances, there is >> control over how and when clients access it. > >Not really. Once you've returned the instance to a client, you've >lost control over it. The client >can to whatever it wants with it. You cannot "recall" the instance >or claim it back. Good point, this should read: > 1. Controll when parametrically defined instances are created. Since > > the Parametric Singleton class encapsulates its instances, there is > > control over how and when they are instanced. > >> 2. Reduced name space. The Parametric Singleton pattern avoids >> global variables that store instances created from the same parameter. > >Sure, but you don't have to rely on a Singleton for that. Just >create a single Factory. > > Thank you for your thoughtful and prompt response! Regards, - Doug From dmarkman at mac.com Wed Mar 22 21:21:55 2006 From: dmarkman at mac.com (Dmitry Markman) Date: Wed, 22 Mar 2006 23:21:55 -0500 Subject: [Rxtx] sole of a new design pattern In-Reply-To: <442160DA.80107@trusted-logic.com> References: <442160DA.80107@trusted-logic.com> Message-ID: I don't think I get it On Mar 22, 2006, at 9:36 AM, David Garnier wrote: > Using the singleton pattern in this case is just convenient for the > programmer. Problems arises > pretty quickly, especially if you attempt to unit-test your classes. so you're saying that something isn't so good because you can not test it in the convenient way? if that's true, I'm totally disagree change your test, debug whatever, but if software is efficient at runtime, works fine and only problem is some unit test (which is some kind of framework for testing) then dump that unit test , dump that unit framework and make something appropriate to the software you're testing so if Douglas want to use singletons, what's the problem? and what do you mean by abusing of singleton usage? of course singleton doesn't prevent concurrent access to the resource across the processes unless you're using some OS facility to prevent it, besides singleton as it was introduced is relevant only and only inside of the same process otherwise it's not singleton it's something else (let's say network singleton: so you have remote invocation facility and some factory method that return object created by that facility) I don't have any problem with using any kind of singletons. Parametric Singleton idea (if I understand it right) could be easily implemented in the following way: use a map populate map with instances of some class and key is your parameter (you can use lazy population too) if somebody ask the key check the value if it's null so resource is taken if somebody returns the resource put it back to the map public synchronized static Object getSomeResource(Object parameter); public synchronized static void returnResource(Object parameter); getSomeResource (inside of the same process) could return null in 2 cases 1. if somebody (from other thread for example) already took that resource 2. if OS API said that resource corresponded to that parameter (serial port with parameter = 1 (port #)) is locked and unavailable; I'm not sure that in case of serial ports we even need those Parametric Singletons (unless lock checking is a very expensive operation) just ask the OS about availability of that resource and if it's available give it away and then OS will lock it and therefore in next time somebody ask it just answer that resource is locked and return null for example system has 2 serial ports available so I ask getResource("tty"); or I ask getResource("Bluetooth-Modem"); and if OS is ok you can give tty or Bluetooth-Modem or both no need for any additional pattern I think back to the problem mac os x doesn't recognize locking via files, so it handles locking via some API an instance of the singleton in each process should recognize that resource is locked (by using that API) that's all we don't have to make things more complicate then they are just because there is some nice design pattern or nice unit test framework or whatever keep things simple, make them work fast, don't introduce middle layers unless you have really good reason to do so of course I could be entirely wrong, so sorry about that in advance thanks Dmitry Markman From tjarvi at qbang.org Wed Mar 22 22:31:41 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 22 Mar 2006 22:31:41 -0700 (MST) Subject: [Rxtx] sole of a new design pattern In-Reply-To: References: Message-ID: Hi Doug Interesting reading. So far I'm just reading and thinking. I have one question so far. " Clients obtain a reference to a Parametric Singleton instance only through the parametric singleton design pattern. If the instance is left in an improper state (e.g., the serial port was left open) it is NOT the role of the Parametric Singleton Design Pattern to close the IO port. Nor is it the role of the Parametric Singleton Design Pattern to open the port. That role is delegate to some other part of the system. " So when the clients obtain a reference to the singleton, can they assume the port is there? IE, would it be the singletons role to handle things like USB dongles being removed with event hints comming from the underlying OS. Hardware abstraction layer/HAL on Linux is an example of underlying OS events. I assume that role too is delegated to other parts of the system? -- Trent Jarvi tjarvi at qbang.org From lyon at docjava.com Thu Mar 23 08:10:33 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Thu, 23 Mar 2006 10:10:33 -0500 Subject: [Rxtx] Classes don't need goals, they need roles! In-Reply-To: References: Message-ID: Hi Trent, Yes, I think that the role of the Parametric Singleton Pattern is not to open or close serial ports, nor is it to perform error checking. On the other hand, if you were to combine the role of the Parametric Singleton Pattern with another role (like that of error checking) it might not be amiss. However, I generally caution programmers against adding multiple roles to classes, as this leads to monolithic designs. Thus a different class (NativeLibDetect) could have the role of determining if the native library can be loaded. Another class (SerialPortBean) can have the role of serializing the default state of the serial port, so that it can be recovered, from user preferences, at a later time. The SerialPortDetect could have the role of determining if the serial port is removed (i.e., a USB port was unplugged). My guess is that each class should have a different role in the system, in order to ease maintenance and testing...but I could be wrong about that. Thanks! - Doug >Hi Doug > >Interesting reading. So far I'm just reading and thinking. I have >one question so far. > >" > Clients obtain a reference to a Parametric Singleton instance only >through the parametric singleton design pattern. If the instance is >left in an improper state (e.g., the serial port was left open) it is >NOT the role of the Parametric Singleton Design Pattern to close the >IO port. Nor is it the role of the Parametric Singleton Design Pattern >to >open the port. That role is delegate to some other part of the system. >" > >So when the clients obtain a reference to the singleton, can they >assume the port is there? IE, would it be the singletons role to >handle things like USB dongles being removed with event hints >comming from the underlying OS. Hardware abstraction layer/HAL on >Linux is an example of underlying OS events. > >I assume that role too is delegated to other parts of the system? > >-- >Trent Jarvi >tjarvi at qbang.org >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From maximulo at yahoo.com Fri Mar 24 01:22:38 2006 From: maximulo at yahoo.com (Maximulo Majir) Date: Fri, 24 Mar 2006 00:22:38 -0800 (PST) Subject: [Rxtx] JavaPOS Message-ID: <20060324082238.66371.qmail@web38214.mail.mud.yahoo.com> Hi all! Hello Trent! From what i understand, RXTX or JavaComm APIs were not created solely for JavaPOS. In JavaPOS, we have the virtual method claim() which is separate from open(), but in our RXTX API, claiming is done every call to open(), we cant open the port if its claimed by another application. Would it be alright to suggest or ask to create a new method called claim(..)? Is there such thing as forceclaim() in RXTX? this could be the same as portownership transfer or its equivalent. ForceClaim is in JSR80. Do you have some samples using RXTX as the lower layer for the Device Service Objects in JavaPOS? I have tried it, i just want to compare. Thank you all! maxim __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060324/496adba2/attachment-0049.html From tjarvi at qbang.org Fri Mar 24 11:28:19 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 24 Mar 2006 11:28:19 -0700 (MST) Subject: [Rxtx] Re: RXTX 2.1 Solaris Problems In-Reply-To: <3691.1143210578@www045.gmx.net> References: <3691.1143210578@www045.gmx.net> Message-ID: On Fri, 24 Mar 2006, Andreas Guenther wrote: > Hi all, > > the solaris problem was not the lock file only. > > Ok, I had to create the directory /var/spool/locks myself. > /var/spool/uucp exists. > > But rxtx didn't find any port. > > I compiled the source with my own debug-informations > and I tried to isolate the problem. > > The problem is the testRead-call in SerialImp.c > > JNIEXPORT jboolean JNICALL RXTXCommDriver(testRead)( > > ... > if ( READ( fd, &c, 1 ) < 0 ) > { > if ( errno != EAGAIN ) { > report( "testRead() read failed\n" ); > ret = JNI_FALSE; > } > } > Thanks Andreas I'm packing up to move. I'll be more or less away for a couple weeks here. I'll be checking email but my workstation is going into a box soon. This isn't hard to fix as this port should be enumerated when EWOULDBLOCK is recieved. Thats error is OK for enumeration just as EAGAIN is. I've put the bug into bugzilla so we dont forget to get to it. http://bugzilla.qbang.org/show_bug.cgi?id=42 You can add yourself to the CC list if you wish to test fixes we provide or even put a patch into bugzilla yourself. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Fri Mar 24 11:51:52 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 24 Mar 2006 11:51:52 -0700 (MST) Subject: [Rxtx] JavaPOS In-Reply-To: <20060324082238.66371.qmail@web38214.mail.mud.yahoo.com> References: <20060324082238.66371.qmail@web38214.mail.mud.yahoo.com> Message-ID: On Fri, 24 Mar 2006, Maximulo Majir wrote: > Hi all! Hello Trent! > > > From what i understand, RXTX or JavaComm APIs were not > created solely for JavaPOS. In JavaPOS, we have the virtual method > claim() which is separate from open(), but in our RXTX API, claiming is > done every call to open(), we cant open the port if its claimed by > another application. Would it be alright to suggest or ask to create a > new method called claim(..)? Is there such thing as forceclaim() in > RXTX? this could be the same as portownership transfer or its > equivalent. ForceClaim is in JSR80. > Do you have some samples using RXTX as the lower layer for the Device > Service Objects in JavaPOS? I have tried it, i just want to compare. > maxim Hi Maxim JSR80 is the USB API IBM/Sun put together. The problem is they have a richer kernel/API underneath that can handle such things. With Serial Ports, there isnt anything there other than an ioctl that says don't let anyone touch this and lockfiles that are more of a 'lets be nice.' At times we may be using USB ports but it is through the termios layer with the limitations mentioned. The advantage is that not only USB will work with rxtx. Anything that has a termios layer should work (to the extent that termios layer is complete). I don't know how forceclaim() would help you. Lets say someone has a programmer working on /dev/ttyS0 and you take it. Now you both race each other to read data first. There isn't a mechanism I know of that will solve this problem in termios. The most obvious test being a native app and a Java app trying to take the port. There is the potential of requestion ownership from other Java Applications but the use for that is very rare. Did you have something more specific in mind that I'm missing? I'm not sure that claim() and forceclaim() would help you with rxtx other than maybe locking the port with claim() without opening it. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sat Mar 25 23:42:08 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 25 Mar 2006 23:42:08 -0700 (MST) Subject: [Rxtx] Serial snoop Message-ID: I was reading the Linux kernel mail-list tonight and ran past a thread that mentioned sersnoop. This looks like a handy tool for people dealing with new toys. "a simple command-line tool for linux that echoes bytes to and from any two serial ports, ptys, or network sockets, and prints all traffic to stdout, in hex and ascii." http://www.restivo.org/projects/sersnoop/ It works on Linux only at this time (debian package available). -- Trent Jarvi tjarvi at qbang.org From beat.arnet at gmail.com Sun Mar 26 07:32:35 2006 From: beat.arnet at gmail.com (Beat Arnet) Date: Sun, 26 Mar 2006 09:32:35 -0500 Subject: [Rxtx] Error 0x5 at /home/bob/foo/tar/rxtx-2.1-7/build/../src/termios.c(860): Access is, denied. Message-ID: <4426A603.80508@gmail.com> Dear all, When trying to open the serial port, I sometimes (not always) run into the following exception (when opening the serialPort): Error 0x5 at /home/bob/foo/tar/rxtx-2.1-7/build/../src/termios.c(860): Access is denied. java.lang.UnsatisfiedLinkError: native_psmisc_report_owner at gnu.io.CommPortIdentifier.native_psmisc_report_owner(Native Method) at gnu.io.CommPortIdentifier.open(CommPortIdentifier.java:354) at codeskin.tools.CLLoader.open(CLLoader.java:79) at codeskin.tools.C2000Programmer.run(C2000Programmer.java:220) at java.lang.Thread.run(Unknown Source) Is this the type of error where I should just try to open the port again, or can it be avoided? Regards, Beat From tjarvi at qbang.org Sun Mar 26 11:40:12 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 26 Mar 2006 11:40:12 -0700 (MST) Subject: [Rxtx] Error 0x5 at /home/bob/foo/tar/rxtx-2.1-7/build/../src/termios.c(860): Access is, denied. In-Reply-To: <4426A603.80508@gmail.com> References: <4426A603.80508@gmail.com> Message-ID: On Sun, 26 Mar 2006, Beat Arnet wrote: > Dear all, > > When trying to open the serial port, I sometimes (not always) run into > the following exception (when opening the serialPort): > > Error 0x5 at /home/bob/foo/tar/rxtx-2.1-7/build/../src/termios.c(860): > Access is > denied. > > java.lang.UnsatisfiedLinkError: native_psmisc_report_owner > at gnu.io.CommPortIdentifier.native_psmisc_report_owner(Native > Method) > at gnu.io.CommPortIdentifier.open(CommPortIdentifier.java:354) > at codeskin.tools.CLLoader.open(CLLoader.java:79) > at codeskin.tools.C2000Programmer.run(C2000Programmer.java:220) > at java.lang.Thread.run(Unknown Source) > > Is this the type of error where I should just try to open the port again, > or can it be avoided? > Hi Beat We did a second build of rxtx 2.1-7 to resolve that unsatisfied link error. It should work now. rxtx is trying to tell you it thinks someone else has the serial port open. You can try to open the port again but maybe you already have a copy of the program running when it happens? ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7r2.zip fixed build. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sun Mar 26 11:44:23 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 26 Mar 2006 11:44:23 -0700 (MST) Subject: [Rxtx] RXTX spec file (fwd) Message-ID: This is probably interesting for fedora/suse users. ---------- Forwarded message ---------- Date: Sun, 26 Mar 2006 16:25:45 +0200 To: taj at www.linux.org.uk Subject: RXTX spec file I send you this spec file which allows to create a RPM for Fedora 4, 5 (x86, x86_64) with Java Sun. -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: rxtx.spec Url: http://mailman.qbang.org/pipermail/rxtx/attachments/20060326/6c7b6af6/rxtx-0045.pl From tjarvi at qbang.org Sun Mar 26 23:42:59 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 26 Mar 2006 23:42:59 -0700 (MST) Subject: [Rxtx] Upcomming events. Message-ID: This Wednesday we will be announcing a new "Maintainer" for the rxtx project. The position is more like neutral leader. I wont be going away or doing less. This is just the right thing to do as it turns out the two people with CVS write access will be at the same company. We need a third and we need neutrality. The maintainer will have final say in any conflict and will try to be neutral. It will be open for discussion. Then we will do it :) I'll still do most of the footwork I do now. But. I'm falling behind. I should have gone through the mail-list and posted the next round of changes this weekend. I'm packing to move and its going so so - 13 years of toys collected. I suspect there will be a dead period on my part (a couple weeks) comming up. But if you get it on the mail-list, we will get it in if there are no objections. I may well not be reading the mail-list during this period as I look for a house and many other things. I hope everyone will help out. Thanks -- Trent Jarvi tjarvi at qbang.org From mahmoud_hadad at yahoo.com Sun Mar 26 07:31:19 2006 From: mahmoud_hadad at yahoo.com (ronan nick) Date: Sun, 26 Mar 2006 06:31:19 -0800 (PST) Subject: [Rxtx] a question about the COMM API Message-ID: <20060326143119.54919.qmail@web60014.mail.yahoo.com> hi, i was intrested in knowing how i can communicate with my internal modem using java? for example if i want to make a phone dialer application or a caller id application where should i be looking at? and as i understood the COMM API is for devices that is attached to the computer through serial ports. --------------------------------- New Yahoo! Messenger with Voice. Call regular phones from your PC and save big. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060326/ce8329f0/attachment-0047.html From dmarkman at mac.com Mon Mar 20 00:20:43 2006 From: dmarkman at mac.com (Dmitry Markman) Date: Mon, 20 Mar 2006 02:20:43 -0500 Subject: [Rxtx] Mac OS X RXTX java installer In-Reply-To: References: <07D0DE29-BA32-4CFE-B036-66BC6423D385@buechse.de> <441AE3E0.2030503@willicon.de> <12531986.1142622114996.JavaMail.dmarkman@mac.com> <441B2674.9010409@willicon.de> <13577405.1142634732776.JavaMail.dmarkman@mac.com> <441B4182.8010407@willicon.de> <92CD0D6C-5BE8-426E-A46D-99452059FF49@mac.com> <441BBB2D.8030305@willicon.de> <441C4088.5090905@willicon.de> Message-ID: <64BC1E23-FDDE-4CE6-8863-CFC881CBC224@mac.com> Hi all I put RXTX installer that will install everything (and will create / var/lock if necessary and add user to the uucp group) for mac os x from Java into the rxtx's CVS repository it could be easily modified to install files for any platform it uses Greg Guerin's AuthKit for authentication and authorization Greg released that kit under artistic license, so Trent, please take a look we, probably, can negotiate license with Greg if it's necessary Greg's AuthKit could be downloaded from http://www.amug.org/~glguerin/ sw/#authkit Michael Hall (mikehall at spacestar dot net) had a suggestion to make implementation of the jaas LoginModule based on Greg's AuthKit (his modification of the Greg's AuthKit could be found at http:// www.spacestar.net/users/mikehall/authkit.dmg) but Michael's AuthKitLoginModule does only half a job: it does authenticate but it can not run any external unix process in privileged mode (at least I wasn't able to do so) possible explanation could be found in conversation between Greg and Michael at Apple's java-dev list (look for archives) so I didn't use jaas API for rxtxinstaller I created folder MacOSX in the contrib folder comment 1. if you want to run that installer as standalone application all you need that RXTXInstaller.jar 2. if you want to use webstart you have to add Greg's libAuthKit.jnilib to the mac os x's resources in theory RXTXInstaller.jar doesn't need it, but there is a problem with loading libAuthKit.jnilib from webstart authkit uses loadLibrary method to load library and it failed (from webstart) for standalone application I extract libAuthKit.jnilib from the RXTXInstaller.jar and put it into the /Library/Java/Extensions or ~/Library/Java/Extensions folder that file will be deleted after installer quit unfortunately I didn't have time to put documentation there but it is mostly self-explanatory I took installer code from my gl4java installer that I did about 3 years ago (with small modifications) it would be very nice if Apple will release LoginModule that really will do the job (com.apple.security.auth.module package????? ) (UnixLoginModule is pretty useless) From lyon at docjava.com Mon Mar 20 06:34:39 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Mon, 20 Mar 2006 08:34:39 -0500 Subject: [Rxtx] Mac OS X RXTX java installer In-Reply-To: <64BC1E23-FDDE-4CE6-8863-CFC881CBC224@mac.com> References: <07D0DE29-BA32-4CFE-B036-66BC6423D385@buechse.de> <441AE3E0.2030503@willicon.de> <12531986.1142622114996.JavaMail.dmarkman@mac.com> <441B2674.9010409@willicon.de> <13577405.1142634732776.JavaMail.dmarkman@mac.com> <441B4182.8010407@willicon.de> <92CD0D6C-5BE8-426E-A46D-99452059FF49@mac.com> <441BBB2D.8030305@willicon.de> <441C4088.5090905@willicon.de> <64BC1E23-FDDE-4CE6-8863-CFC881CBC224@mac.com> Message-ID: Hi Dimitry, This sounds like great work. Just a couple of questions; After the check out of the CVS files, using: setenv CVSROOT :pserver:anonymous at cvs.milestonesolutions.com:/usr/local/cvsroot 53 8:28 setenv PASSWORD mousy 54 8:29 cvs login 55 8:29 cvs checkout rxtx-devel I cd'd over to: rxtx-devel/MACOSX_IDE And found: CVS/ CW/ ForPackageMaker/ PB/ Where is the installer? Thanks! - Doug From tjarvi at qbang.org Mon Mar 20 06:39:37 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 20 Mar 2006 06:39:37 -0700 (MST) Subject: [Rxtx] Mac OS X RXTX java installer In-Reply-To: References: <07D0DE29-BA32-4CFE-B036-66BC6423D385@buechse.de> <441AE3E0.2030503@willicon.de> <12531986.1142622114996.JavaMail.dmarkman@mac.com> <441B2674.9010409@willicon.de> <13577405.1142634732776.JavaMail.dmarkman@mac.com> <441B4182.8010407@willicon.de> <92CD0D6C-5BE8-426E-A46D-99452059FF49@mac.com> <441BBB2D.8030305@willicon.de> <441C4088.5090905@willicon.de> <64BC1E23-FDDE-4CE6-8863-CFC881CBC224@mac.com> Message-ID: On Mon, 20 Mar 2006, Dr. Douglas Lyon wrote: > Hi Dimitry, > This sounds like great work. Just a couple of questions; > After the check out of the CVS files, using: > setenv CVSROOT > :pserver:anonymous at cvs.milestonesolutions.com:/usr/local/cvsroot > 53 8:28 setenv PASSWORD mousy > 54 8:29 cvs login > 55 8:29 cvs checkout rxtx-devel Hi Doug You want "cvs checkout -r commapi-0-0-1 rxtx-devel" to get RXTX 2.1 The default branch is rxtx 2.0 which isn't very active right now. -- Trent Jarvi tjarvi at qbang.org From lyon at docjava.com Mon Mar 20 07:05:44 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Mon, 20 Mar 2006 09:05:44 -0500 Subject: [Rxtx] Mac OS X RXTX java installer In-Reply-To: References: <07D0DE29-BA32-4CFE-B036-66BC6423D385@buechse.de> <441AE3E0.2030503@willicon.de> <12531986.1142622114996.JavaMail.dmarkman@mac.com> <441B2674.9010409@willicon.de> <13577405.1142634732776.JavaMail.dmarkman@mac.com> <441B4182.8010407@willicon.de> <92CD0D6C-5BE8-426E-A46D-99452059FF49@mac.com> <441BBB2D.8030305@willicon.de> <441C4088.5090905@willicon.de> <64BC1E23-FDDE-4CE6-8863-CFC881CBC224@mac.com> Message-ID: Hi Trent, Thanks for the info on the CVS checkout procedure. I did that and am still not sure where the installer is. Here is what I have: cd MACOSX_IDE/ p4.docjava.com{lyon}121: ls CVS/ ForPackageMaker/ PB/ p4.docjava.com{lyon}122: find . | more . ./ForPackageMaker ./ForPackageMaker/RXTX.pkg.sit.hqx ./ForPackageMaker/Resources ./ForPackageMaker/Resources/ReadMe.rtf ./ForPackageMaker/Resources/Welcome.rtf ./ForPackageMaker/Resources/CVS ./ForPackageMaker/Resources/CVS/Entries ./ForPackageMaker/Resources/CVS/Repository ./ForPackageMaker/Resources/CVS/Tag ./ForPackageMaker/Resources/CVS/Root ./ForPackageMaker/Resources/preinstall ./ForPackageMaker/Resources/License.rtf ./ForPackageMaker/Resources/preupgrade ./ForPackageMaker/RXTX.pmsp ./ForPackageMaker/CVS ./ForPackageMaker/CVS/Entries ./ForPackageMaker/CVS/Repository ./ForPackageMaker/CVS/Entries.Log ./ForPackageMaker/CVS/Tag ./ForPackageMaker/CVS/Root ./ForPackageMaker/RXTX_Tiger.pkg.sitx.hqx ./ForPackageMaker/RXTX_Jag.pkg.sit.hqx ./ForPackageMaker/Install ./ForPackageMaker/Install/CVS ./ForPackageMaker/Install/CVS/Entries ./ForPackageMaker/Install/CVS/Repository ./ForPackageMaker/Install/CVS/Tag ./ForPackageMaker/Install/CVS/Root ./ForPackageMaker/Install/Library ./ForPackageMaker/Install/Library/CVS ./ForPackageMaker/Install/Library/CVS/Entries ./ForPackageMaker/Install/Library/CVS/Repository ./ForPackageMaker/Install/Library/CVS/Tag ./ForPackageMaker/Install/Library/CVS/Root ./ForPackageMaker/Install/Library/Java ./ForPackageMaker/Install/Library/Java/Extensions ./ForPackageMaker/Install/Library/Java/Extensions/RXTXcomm.jar ./ForPackageMaker/Install/Library/Java/Extensions/CVS ./ForPackageMaker/Install/Library/Java/Extensions/CVS/Entries ./ForPackageMaker/Install/Library/Java/Extensions/CVS/Repository ./ForPackageMaker/Install/Library/Java/Extensions/CVS/Tag ./ForPackageMaker/Install/Library/Java/Extensions/CVS/Root ./ForPackageMaker/Install/Library/Java/Extensions/librxtxSerial.jnilib ./ForPackageMaker/Install/Library/Java/CVS ./ForPackageMaker/Install/Library/Java/CVS/Entries ./ForPackageMaker/Install/Library/Java/CVS/Repository ./ForPackageMaker/Install/Library/Java/CVS/Entries.Log ./ForPackageMaker/Install/Library/Java/CVS/Tag ./ForPackageMaker/Install/Library/Java/CVS/Root ./ForPackageMaker/RXTX_Tiger.pmproj.sitx.hqx ./CVS ./CVS/Entries ./CVS/Repository ./CVS/Entries.Log ./CVS/Tag ./CVS/Root ./PB ./PB/LibSerialUniversal.xcodeproj.sitx.hqx ./PB/CVS ./PB/CVS/Entries ./PB/CVS/Repository ./PB/CVS/Entries.Log ./PB/CVS/Tag ./PB/CVS/Root ./PB/LibSerial.pbproj.sit.hqx ./PB/startpoint.c ./PB/config.h What is the procedure to run this installer? Do we need a README in: /rxtx-devel/MACOSX_IDE Here is what we have: CVS/ ForPackageMaker/ PB/ Thanks! - DL >On Mon, 20 Mar 2006, Dr. Douglas Lyon wrote: > >>Hi Dimitry, >>This sounds like great work. Just a couple of questions; >>After the check out of the CVS files, using: >>setenv CVSROOT >>:pserver:anonymous at cvs.milestonesolutions.com:/usr/local/cvsroot >> 53 8:28 setenv PASSWORD mousy >> 54 8:29 cvs login >> 55 8:29 cvs checkout rxtx-devel > >Hi Doug > >You want "cvs checkout -r commapi-0-0-1 rxtx-devel" to get RXTX 2.1 >The default branch is rxtx 2.0 which isn't very active right now. > >-- >Trent Jarvi >tjarvi at qbang.org From tjarvi at qbang.org Mon Mar 20 07:25:30 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 20 Mar 2006 07:25:30 -0700 (MST) Subject: [Rxtx] Mac OS X RXTX java installer In-Reply-To: References: <07D0DE29-BA32-4CFE-B036-66BC6423D385@buechse.de> <441AE3E0.2030503@willicon.de> <12531986.1142622114996.JavaMail.dmarkman@mac.com> <441B2674.9010409@willicon.de> <13577405.1142634732776.JavaMail.dmarkman@mac.com> <441B4182.8010407@willicon.de> <92CD0D6C-5BE8-426E-A46D-99452059FF49@mac.com> <441BBB2D.8030305@willicon.de> <441C4088.5090905@willicon.de> <64BC1E23-FDDE-4CE6-8863-CFC881CBC224@mac.com> Message-ID: On Mon, 20 Mar 2006, Dr. Douglas Lyon wrote: > Hi Trent, > Thanks for the info on the CVS checkout procedure. > I did that and am still not sure where the installer is. Hi Doug It does look like it was not cvs committed. There is no rxtx-devel/contrib/MacOSX directory in there at the moment. It was mentioned that it was put under contrib. -- Trent Jarvi tjarvi at qbang.org From dmarkman at mac.com Mon Mar 20 07:29:56 2006 From: dmarkman at mac.com (Dmitry Markman) Date: Mon, 20 Mar 2006 09:29:56 -0500 Subject: [Rxtx] Mac OS X RXTX java installer In-Reply-To: References: <07D0DE29-BA32-4CFE-B036-66BC6423D385@buechse.de> <441AE3E0.2030503@willicon.de> <12531986.1142622114996.JavaMail.dmarkman@mac.com> <441B2674.9010409@willicon.de> <13577405.1142634732776.JavaMail.dmarkman@mac.com> <441B4182.8010407@willicon.de> <92CD0D6C-5BE8-426E-A46D-99452059FF49@mac.com> <441BBB2D.8030305@willicon.de> <441C4088.5090905@willicon.de> <64BC1E23-FDDE-4CE6-8863-CFC881CBC224@mac.com> Message-ID: <6054EB4E-F7E0-4A9C-BDDA-D582D6D8826F@mac.com> you can find it in the rxtx-devel/contrib folder On Mar 20, 2006, at 9:05 AM, Dr. Douglas Lyon wrote: > Hi Trent, > Thanks for the info on the CVS checkout procedure. > I did that and am still not sure where the installer is. > Here is what I have: > cd MACOSX_IDE/ > p4.docjava.com{lyon}121: ls > CVS/ ForPackageMaker/ PB/ > p4.docjava.com{lyon}122: find . | more > . > ./ForPackageMaker > ./ForPackageMaker/RXTX.pkg.sit.hqx > ./ForPackageMaker/Resources > ./ForPackageMaker/Resources/ReadMe.rtf > ./ForPackageMaker/Resources/Welcome.rtf > ./ForPackageMaker/Resources/CVS > ./ForPackageMaker/Resources/CVS/Entries > ./ForPackageMaker/Resources/CVS/Repository > ./ForPackageMaker/Resources/CVS/Tag > ./ForPackageMaker/Resources/CVS/Root > ./ForPackageMaker/Resources/preinstall > ./ForPackageMaker/Resources/License.rtf > ./ForPackageMaker/Resources/preupgrade > ./ForPackageMaker/RXTX.pmsp > ./ForPackageMaker/CVS > ./ForPackageMaker/CVS/Entries > ./ForPackageMaker/CVS/Repository > ./ForPackageMaker/CVS/Entries.Log > ./ForPackageMaker/CVS/Tag > ./ForPackageMaker/CVS/Root > ./ForPackageMaker/RXTX_Tiger.pkg.sitx.hqx > ./ForPackageMaker/RXTX_Jag.pkg.sit.hqx > ./ForPackageMaker/Install > ./ForPackageMaker/Install/CVS > ./ForPackageMaker/Install/CVS/Entries > ./ForPackageMaker/Install/CVS/Repository > ./ForPackageMaker/Install/CVS/Tag > ./ForPackageMaker/Install/CVS/Root > ./ForPackageMaker/Install/Library > ./ForPackageMaker/Install/Library/CVS > ./ForPackageMaker/Install/Library/CVS/Entries > ./ForPackageMaker/Install/Library/CVS/Repository > ./ForPackageMaker/Install/Library/CVS/Tag > ./ForPackageMaker/Install/Library/CVS/Root > ./ForPackageMaker/Install/Library/Java > ./ForPackageMaker/Install/Library/Java/Extensions > ./ForPackageMaker/Install/Library/Java/Extensions/RXTXcomm.jar > ./ForPackageMaker/Install/Library/Java/Extensions/CVS > ./ForPackageMaker/Install/Library/Java/Extensions/CVS/Entries > ./ForPackageMaker/Install/Library/Java/Extensions/CVS/Repository > ./ForPackageMaker/Install/Library/Java/Extensions/CVS/Tag > ./ForPackageMaker/Install/Library/Java/Extensions/CVS/Root > ./ForPackageMaker/Install/Library/Java/Extensions/librxtxSerial.jnilib > ./ForPackageMaker/Install/Library/Java/CVS > ./ForPackageMaker/Install/Library/Java/CVS/Entries > ./ForPackageMaker/Install/Library/Java/CVS/Repository > ./ForPackageMaker/Install/Library/Java/CVS/Entries.Log > ./ForPackageMaker/Install/Library/Java/CVS/Tag > ./ForPackageMaker/Install/Library/Java/CVS/Root > ./ForPackageMaker/RXTX_Tiger.pmproj.sitx.hqx > ./CVS > ./CVS/Entries > ./CVS/Repository > ./CVS/Entries.Log > ./CVS/Tag > ./CVS/Root > ./PB > ./PB/LibSerialUniversal.xcodeproj.sitx.hqx > ./PB/CVS > ./PB/CVS/Entries > ./PB/CVS/Repository > ./PB/CVS/Entries.Log > ./PB/CVS/Tag > ./PB/CVS/Root > ./PB/LibSerial.pbproj.sit.hqx > ./PB/startpoint.c > ./PB/config.h > > What is the procedure to run this installer? > Do we need a README in: > /rxtx-devel/MACOSX_IDE > Here is what we have: > CVS/ ForPackageMaker/ PB/ > > > Thanks! > - DL > >> On Mon, 20 Mar 2006, Dr. Douglas Lyon wrote: >> >>> Hi Dimitry, >>> This sounds like great work. Just a couple of questions; >>> After the check out of the CVS files, using: >>> setenv CVSROOT :pserver:anonymous at cvs.milestonesolutions.com:/usr/ >>> local/cvsroot >>> 53 8:28 setenv PASSWORD mousy >>> 54 8:29 cvs login >>> 55 8:29 cvs checkout rxtx-devel >> >> Hi Doug >> >> You want "cvs checkout -r commapi-0-0-1 rxtx-devel" to get RXTX 2.1 >> The default branch is rxtx 2.0 which isn't very active right now. >> >> -- >> Trent Jarvi >> tjarvi at qbang.org > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx Dmitry Markman From mikehall at spacestar.net Mon Mar 20 05:25:25 2006 From: mikehall at spacestar.net (Michael Hall) Date: Mon, 20 Mar 2006 06:25:25 -0600 Subject: [Rxtx] Re: Mac OS X RXTX java installer In-Reply-To: <64BC1E23-FDDE-4CE6-8863-CFC881CBC224@mac.com> References: <07D0DE29-BA32-4CFE-B036-66BC6423D385@buechse.de> <441AE3E0.2030503@willicon.de> <12531986.1142622114996.JavaMail.dmarkman@mac.com> <441B2674.9010409@willicon.de> <13577405.1142634732776.JavaMail.dmarkman@mac.com> <441B4182.8010407@willicon.de> <92CD0D6C-5BE8-426E-A46D-99452059FF49@mac.com> <441BBB2D.8030305@willicon.de> <441C4088.5090905@willicon.de> <64BC1E23-FDDE-4CE6-8863-CFC881CBC224@mac.com> Message-ID: <247EB61F-5CD1-4132-89A2-FC105B6CF9A5@spacestar.net> On Mar 20, 2006, at 1:20 AM, Dmitry Markman wrote: > > Michael Hall (mikehall at spacestar dot net) had a suggestion to > make implementation of the jaas LoginModule > based on Greg's AuthKit > (his modification of the Greg's AuthKit could be found at http:// > www.spacestar.net/users/mikehall/authkit.dmg) > but Michael's AuthKitLoginModule does only half a job: > it does authenticate > but it can not run any external unix process in privileged mode (at > least I wasn't able to do so) If you got it working directly with Greg's the point is moot. But to clarify it anyhow. The login module does not allow you to do anything anything privileged on return as was explained by Greg. You need to work with a separate privileged process using the execPrivileged method of his API. I assume you did something similar although I haven't looked at how you are using it yet. I allowed instead for a action to be performed at the same time you login/authenticate,this... System.setProperty("authkit.action","/usr/bin/id"); just before this... lc.login(); To clarify, safely ignored as you are already complete. Mike Hall mikehall at spacestar dot net http://www.spacestar.net/users/mikehall http://sourceforge.net/projects/macnative -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2427 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20060320/f6e18202/smime-0050.bin From dmarkman at mac.com Mon Mar 20 07:36:47 2006 From: dmarkman at mac.com (Dmitry Markman) Date: Mon, 20 Mar 2006 09:36:47 -0500 Subject: [Rxtx] Re: Mac OS X RXTX java installer In-Reply-To: <247EB61F-5CD1-4132-89A2-FC105B6CF9A5@spacestar.net> References: <07D0DE29-BA32-4CFE-B036-66BC6423D385@buechse.de> <441AE3E0.2030503@willicon.de> <12531986.1142622114996.JavaMail.dmarkman@mac.com> <441B2674.9010409@willicon.de> <13577405.1142634732776.JavaMail.dmarkman@mac.com> <441B4182.8010407@willicon.de> <92CD0D6C-5BE8-426E-A46D-99452059FF49@mac.com> <441BBB2D.8030305@willicon.de> <441C4088.5090905@willicon.de> <64BC1E23-FDDE-4CE6-8863-CFC881CBC224@mac.com> <247EB61F-5CD1-4132-89A2-FC105B6CF9A5@spacestar.net> Message-ID: Hi, Michael all I have to do is to run some shell script I tried to use your action mechanism and it worked great so I just System.setProperty ("authkit.action","" ) and after that I even don't need to run anything like subject.doAs.... but after few thoughts I choose to use plain Greg's approach, because in that case I don't have to deal with various java's configurations files and therefore to use 2-3 -D parameters in the java command line especially it's useful for java web start (it's so fragile :-( ) thanks for the great job On Mar 20, 2006, at 7:25 AM, Michael Hall wrote: > > On Mar 20, 2006, at 1:20 AM, Dmitry Markman wrote: >> >> Michael Hall (mikehall at spacestar dot net) had a suggestion to >> make implementation of the jaas LoginModule >> based on Greg's AuthKit >> (his modification of the Greg's AuthKit could be found at http:// >> www.spacestar.net/users/mikehall/authkit.dmg) >> but Michael's AuthKitLoginModule does only half a job: >> it does authenticate >> but it can not run any external unix process in privileged mode >> (at least I wasn't able to do so) > > If you got it working directly with Greg's the point is moot. > > But to clarify it anyhow. > The login module does not allow you to do anything anything > privileged on return as was explained by Greg. You need to work > with a separate privileged process using the execPrivileged method > of his API. I assume you did something similar although I haven't > looked at how you are using it yet. > I allowed instead for a action to be performed at the same time you > login/authenticate,this... > System.setProperty("authkit.action","/usr/bin/id"); > just before this... > lc.login(); > To clarify, safely ignored as you are already complete. > > Mike Hall mikehall at spacestar dot net > http://www.spacestar.net/users/mikehall > http://sourceforge.net/projects/macnative > > > Dmitry Markman From dmarkman at mac.com Mon Mar 20 07:44:45 2006 From: dmarkman at mac.com (Dmitry Markman) Date: Mon, 20 Mar 2006 09:44:45 -0500 Subject: [Rxtx] Mac OS X RXTX java installer In-Reply-To: References: <07D0DE29-BA32-4CFE-B036-66BC6423D385@buechse.de> <441AE3E0.2030503@willicon.de> <12531986.1142622114996.JavaMail.dmarkman@mac.com> <441B2674.9010409@willicon.de> <13577405.1142634732776.JavaMail.dmarkman@mac.com> <441B4182.8010407@willicon.de> <92CD0D6C-5BE8-426E-A46D-99452059FF49@mac.com> <441BBB2D.8030305@willicon.de> <441C4088.5090905@willicon.de> <64BC1E23-FDDE-4CE6-8863-CFC881CBC224@mac.com> Message-ID: it's in the commapi-0-0-1 branch I tested it right now: cvs co -r commapi-0-0-1 rxtx-devel and I got everything On Mar 20, 2006, at 9:25 AM, Trent Jarvi wrote: > On Mon, 20 Mar 2006, Dr. Douglas Lyon wrote: > >> Hi Trent, >> Thanks for the info on the CVS checkout procedure. >> I did that and am still not sure where the installer is. > > Hi Doug > > It does look like it was not cvs committed. There is no rxtx-devel/ > contrib/MacOSX directory in there at the moment. It was mentioned > that it was put under contrib. > > -- > Trent Jarvi > tjarvi at qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx Dmitry Markman From tjarvi at qbang.org Mon Mar 20 07:52:57 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 20 Mar 2006 07:52:57 -0700 (MST) Subject: [Rxtx] Mac OS X RXTX java installer In-Reply-To: References: <07D0DE29-BA32-4CFE-B036-66BC6423D385@buechse.de> <441AE3E0.2030503@willicon.de> <12531986.1142622114996.JavaMail.dmarkman@mac.com> <441B2674.9010409@willicon.de> <13577405.1142634732776.JavaMail.dmarkman@mac.com> <441B4182.8010407@willicon.de> <92CD0D6C-5BE8-426E-A46D-99452059FF49@mac.com> <441BBB2D.8030305@willicon.de> <441C4088.5090905@willicon.de> <64BC1E23-FDDE-4CE6-8863-CFC881CBC224@mac.com> Message-ID: On Mon, 20 Mar 2006, Dmitry Markman wrote: > it's in the commapi-0-0-1 branch > > I tested it right now: > cvs co -r commapi-0-0-1 rxtx-devel > > and I got everything > A fresh checkout worked. Here is a copy of the tree (just the installer bits) ftp://ftp.qbang.org/pub/rxtx/MacOSX-installer.zip -- Trent Jarvi tjarvi at qbang.org From lyon at docjava.com Mon Mar 20 08:08:26 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Mon, 20 Mar 2006 10:08:26 -0500 Subject: [Rxtx] Mac OS X RXTX java installer In-Reply-To: References: <07D0DE29-BA32-4CFE-B036-66BC6423D385@buechse.de> <441AE3E0.2030503@willicon.de> <12531986.1142622114996.JavaMail.dmarkman@mac.com> <441B2674.9010409@willicon.de> <13577405.1142634732776.JavaMail.dmarkman@mac.com> <441B4182.8010407@willicon.de> <92CD0D6C-5BE8-426E-A46D-99452059FF49@mac.com> <441BBB2D.8030305@willicon.de> <441C4088.5090905@willicon.de> <64BC1E23-FDDE-4CE6-8863-CFC881CBC224@mac.com> Message-ID: Hi All, Is the Auth package able to work properly on non Mac OS's? It was not clear from the doc or download. Thanks! - Doug From dmarkman at mac.com Mon Mar 20 08:15:22 2006 From: dmarkman at mac.com (Dmitry Markman) Date: Mon, 20 Mar 2006 10:15:22 -0500 Subject: [Rxtx] Mac OS X RXTX java installer In-Reply-To: References: <07D0DE29-BA32-4CFE-B036-66BC6423D385@buechse.de> <441AE3E0.2030503@willicon.de> <12531986.1142622114996.JavaMail.dmarkman@mac.com> <441B2674.9010409@willicon.de> <13577405.1142634732776.JavaMail.dmarkman@mac.com> <441B4182.8010407@willicon.de> <92CD0D6C-5BE8-426E-A46D-99452059FF49@mac.com> <441BBB2D.8030305@willicon.de> <441C4088.5090905@willicon.de> <64BC1E23-FDDE-4CE6-8863-CFC881CBC224@mac.com> Message-ID: <217312D8-CCCA-4859-ABA6-32DF1CC817B9@mac.com> thanks Trent, for putting it on ftp server On Mar 20, 2006, at 9:52 AM, Trent Jarvi wrote: > A fresh checkout worked. Here is a copy of the tree (just the > installer bits) > > ftp://ftp.qbang.org/pub/rxtx/MacOSX-installer.zip > Dmitry Markman From dmarkman at mac.com Mon Mar 20 09:14:03 2006 From: dmarkman at mac.com (Dmitry Markman) Date: Mon, 20 Mar 2006 11:14:03 -0500 Subject: [Rxtx] Mac OS X RXTX java installer In-Reply-To: References: <07D0DE29-BA32-4CFE-B036-66BC6423D385@buechse.de> <441AE3E0.2030503@willicon.de> <12531986.1142622114996.JavaMail.dmarkman@mac.com> <441B2674.9010409@willicon.de> <13577405.1142634732776.JavaMail.dmarkman@mac.com> <441B4182.8010407@willicon.de> <92CD0D6C-5BE8-426E-A46D-99452059FF49@mac.com> <441BBB2D.8030305@willicon.de> <441C4088.5090905@willicon.de> <64BC1E23-FDDE-4CE6-8863-CFC881CBC224@mac.com> Message-ID: <4DEBA6F0-DA45-4E84-823E-1F1AC48BDCCC@mac.com> no it will work only on mac os x however it's harmless to run it on other platform if you want to use it for other platform you have to do the following (I'll do it for linux) 1. modify RXTXInstaller class method public static RXTXInstaller getInstance() public static RXTXInstaller getInstance() { String osName = System.getProperty("os.name").toLowerCase(); if(osName.startsWith("mac")){ return new gnu.io.installer.macosx.MACOSXRXTXInstaller(); } else if(osName.startsWith("windows")){ return new gnu.io.installer.windows.WindowsRXTXInstaller(); }else if(osName.startsWith("linux")){ return new gnu.io.installer.linux.LinuxRXTXInstaller(); } return null; } 2. create folder gnu/io/installer/linux/ 3. create class Linux386RXTXInstaller package gnu.io.installer.linux; import java.io.File; public class Linux386RXTXInstaller extends gnu.io.installer.RXTXInstaller{ public Linux386RXTXInstaller(){ createJarFolder(); createLibFolder(); addJarResource("RXTXcomm.jar","/gnu/io/installer/resources/ linux/jar/RXTXcomm.dat"); addLibResource("librxtxSerial.so","/gnu/io/installer/ resources/linux/lib/librxtxSerial.so"); } protected void createJarFolder(){ String javaHome = System.getProperty("java.home"); char separator = File.separatorChar; jarFolder = new File(javaHome+separator+"lib"+separator+"ext"); } protected void createLibFolder(){ String javaHome = System.getProperty("java.home"); char separator = File.separatorChar; libFolder = new File(javaHome+separator+"bin"); } public void runPreProcess() {} //put here some action you need public void runPostProcess() {} //put here some action you need } 4. create folder /gnu/io/installer/resources/linux/jar and put there linux's version of RXTXcomm.dat (which is renamed RXTXcomm.jar) 5. create folder /gnu/io/installer/resources/linux/lib and put there linux's version of librxtxSerial. so 6. make sure that RXTXInstaller.jar has the following items: /gnu/io/installer/resources/linux/jar/RXTXcomm.jar /gnu/io/installer/resources/linux/lib/librxtxSerial.so 7. modify file installer.pref: jar file RXTXInstaller.jar must have the following item /gnu/io/installer/installer.pref that's basically it for windows you have to do the similar things: just replace linux to windows and librxtxSerial.so to rxtxSerial.dll and create appropriate gnu.io.installer.windows.WindowsRXTXInstaller class package gnu.io.installer.windows; import java.io.File; public class WindowsRXTXInstaller extends gnu.io.installer.RXTXInstaller{ public WindowsRXTXInstaller(){ createJarFolder(); createLibFolder(); addJarResource("RXTXcomm.jar","/gnu/io/installer/resources/ windows/jar/RXTXcomm.dat"); addLibResource("librxtxSerial.so","/gnu/io/installer/ resources/windows/lib/rxtxSerial.dll"); } protected void createJarFolder(){ String javaHome = System.getProperty("java.home"); char separator = File.separatorChar; jarFolder = new File(javaHome+separator+"lib"+separator+"ext"); } protected void createLibFolder(){ String javaHome = System.getProperty("java.home"); char separator = File.separatorChar; libFolder = new File(javaHome+separator+"bin"); } public void runPreProcess() {} //put here some action you need public void runPostProcess() {} //put here some action you need } installer.pref will look like On Mar 20, 2006, at 10:08 AM, Dr. Douglas Lyon wrote: > Hi All, > Is the Auth package able to work properly on > non Mac OS's? > It was not clear from the doc or download. > > Thanks! > - Doug > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx Dmitry Markman From joachim at buechse.de Mon Mar 20 10:49:06 2006 From: joachim at buechse.de (Joachim Buechse) Date: Mon, 20 Mar 2006 18:49:06 +0100 Subject: [Rxtx] BUG: Lock file stays even if port opening fails Message-ID: This was only tested on MacOSX but looking at the code, it should be true for all systems that use lock_uucp. I am opening a port which can not be opened (dialup port of a telephone paired via bluetooth but currently not reachable). The lock file is created and stays arround, even though the port open failed. After looking a bit through the code (of 2.17), I really wonder if it wouldn't be a good idea to make the "locking" an explicit operation called from the java code. This would certainly simplify the generation of meaningfull exceptions (and java based debugging). Maybe even the handling of "preopened" ports should be in the Java part of the lib (again for java based debugging puposes). That beeing said, I have no idea if this would be possible for the 2.07 implementation. Regards, Joachim From tjarvi at qbang.org Mon Mar 20 11:24:22 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 20 Mar 2006 11:24:22 -0700 (MST) Subject: [Rxtx] BUG: Lock file stays even if port opening fails In-Reply-To: References: Message-ID: On Mon, 20 Mar 2006, Joachim Buechse wrote: > This was only tested on MacOSX but looking at the code, it should be true > for all systems that use lock_uucp. > > I am opening a port which can not be opened (dialup port of a telephone > paired via bluetooth but currently not reachable). The lock file is > created and stays arround, even though the port open failed. > > > After looking a bit through the code (of 2.17), I really wonder if it > wouldn't be a good idea to make the "locking" an explicit operation > called from the java code. This would certainly simplify the generation > of meaningfull exceptions (and java based debugging). > Maybe even the handling of "preopened" ports should be in the Java part > of the lib (again for java based debugging puposes). That beeing said, I > have no idea if this would be possible for the 2.07 implementation. > > Regards, Hi Joachim It should be possible in the 2.0-7 implementation too. The calls to RXTXPort.java would not change. We would just do more there Moving more of that logic into Java would be better as many people don't like to look at C code. There is a liblockdev on most Linux distros that can do most of the C code and would be easier to use. The problem is embeded devices will not have that library. The preopened port code has not been really tested. That was a last minute request in a product cycle. I expect it will be tested this year though. As I recall, some devices really do not like CD raising on open. The preopened ports then allow people to mess around in java without power cycling the devices or losing data. -- Trent Jarvi tjarvi at qbang.org From joachim at buechse.de Mon Mar 20 12:01:08 2006 From: joachim at buechse.de (Joachim Buechse) Date: Mon, 20 Mar 2006 20:01:08 +0100 Subject: [Rxtx] BUG: Lock file stays even if port opening fails In-Reply-To: References: Message-ID: Hi Trent, What is your general feeling about moving code to Java? The last days I have been reading quite a bit of the code and there are several things, that might not work as expected. I'll give you two examples from is_device_locked: if LOCKDIR == /var/spool/locks the directory /var/spool/lock will not be checked. LOCKDIR is not checked for lockfiles with unexpected pefixes While these things have probably never been discovered in production, they are still possibly incorrect implementations. If it was Java code, I would write some unit tests producing the errors that could later be corrected. PS: One could imagine to actually implement the whole lockfile handling in Java using some native routines to get the values required (pid, st_dev, st_rdev, ...). On 20.03.2006, at 19:24, Trent Jarvi wrote: > On Mon, 20 Mar 2006, Joachim Buechse wrote: > >> This was only tested on MacOSX but looking at the code, it should >> be true for all systems that use lock_uucp. >> >> I am opening a port which can not be opened (dialup port of a >> telephone paired via bluetooth but currently not reachable). The >> lock file is created and stays arround, even though the port open >> failed. >> >> >> After looking a bit through the code (of 2.17), I really wonder if >> it wouldn't be a good idea to make the "locking" an explicit >> operation called from the java code. This would certainly simplify >> the generation of meaningfull exceptions (and java based debugging). >> Maybe even the handling of "preopened" ports should be in the Java >> part of the lib (again for java based debugging puposes). That >> beeing said, I have no idea if this would be possible for the 2.07 >> implementation. >> >> Regards, > > Hi Joachim > > It should be possible in the 2.0-7 implementation too. The calls > to RXTXPort.java would not change. We would just do more there > Moving more of that logic into Java would be better as many people > don't like to look at C code. There is a liblockdev on most Linux > distros that can do most of the C code and would be easier to use. > The problem is embeded devices will not have that library. > > The preopened port code has not been really tested. That was a > last minute request in a product cycle. I expect it will be tested > this year though. As I recall, some devices really do not like CD > raising on open. The preopened ports then allow people to mess > around in java without power cycling the devices or losing data. > > -- > Trent Jarvi > tjarvi at qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Mon Mar 20 12:21:02 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 20 Mar 2006 12:21:02 -0700 (MST) Subject: [Rxtx] BUG: Lock file stays even if port opening fails In-Reply-To: References: Message-ID: On Mon, 20 Mar 2006, Joachim Buechse wrote: > Hi Trent, > > What is your general feeling about moving code to Java? The last days I > have been reading quite a bit of the code and there are several things, > that might not work as expected. > > I'll give you two examples from is_device_locked: > > if LOCKDIR == /var/spool/locks the directory /var/spool/lock will not be > checked. > LOCKDIR is not checked for lockfiles with unexpected pefixes > > While these things have probably never been discovered in production, > they are still possibly incorrect implementations. If it was Java code, I > would write some unit tests producing the errors that could later be > corrected. > > PS: One could imagine to actually implement the whole lockfile handling > in Java using some native routines to get the values required (pid, > st_dev, st_rdev, ...). Hi Joachim I like the idea of moving more of the code into java but there are some things to consider. If you break this into multiple JNI calls, the performance will drop considerably during enumeration of ports. We are looking for 256 ports per dev type vs (16? in Sun's 2.0 and fewer types). Its hard to make assumptions. I've seen virtual ports start at /dev/foo100 for instance. It works out to over 7500 ports on Linux if you enable them all. We already trim that back by default. See Linux-all-ports in RXTXCommDriver.java. There are also native libraries that rxtx can link to. If you move too much into Java, linking to 'standard' libraries with distros will break. "configure --enable-liblock=yes" will not be doable. This is probably a favorable way with RedHat, Debian, Suse and others. Thats the right thing to do if there will be rpms, dpkg, .. For those reasons, I think it still make sense to keep it to a minimal ~3 calls to JNI code that we can use for speed and versatility. lock() isLocked(), unlock() perhaps. When I say speed, its more about avoiding crossing the JNI layer multiple times than java vs C performance. With versatility I think liblock is the right way for most but not all (embeded) linux distros. -- Trent Jarvi tjarvi at qbang.org From joachim at buechse.de Mon Mar 20 12:42:04 2006 From: joachim at buechse.de (Joachim Buechse) Date: Mon, 20 Mar 2006 20:42:04 +0100 Subject: [Rxtx] BUG: Lock file stays even if port opening fails In-Reply-To: References: Message-ID: <82C19FE7-DDCB-45B6-B2C9-7606B66F0124@buechse.de> Ok, what about providing a default implementation in Java? The RXTXCommDriver would call a (native) function useNativeLocking and if it returns true, call the native functions for lock() isLocked (), unlock(), else is would use the Java based default implementation. This could possibly be overriden by a property (again for debugging). Joachim On 20.03.2006, at 20:21, Trent Jarvi wrote: > On Mon, 20 Mar 2006, Joachim Buechse wrote: > >> Hi Trent, >> >> What is your general feeling about moving code to Java? The last >> days I have been reading quite a bit of the code and there are >> several things, that might not work as expected. >> >> I'll give you two examples from is_device_locked: >> >> if LOCKDIR == /var/spool/locks the directory /var/spool/lock will >> not be checked. >> LOCKDIR is not checked for lockfiles with unexpected pefixes >> >> While these things have probably never been discovered in >> production, they are still possibly incorrect implementations. If >> it was Java code, I would write some unit tests producing the >> errors that could later be corrected. >> >> PS: One could imagine to actually implement the whole lockfile >> handling in Java using some native routines to get the values >> required (pid, st_dev, st_rdev, ...). > > Hi Joachim > > I like the idea of moving more of the code into java but there are > some things to consider. > > If you break this into multiple JNI calls, the performance will > drop considerably during enumeration of ports. We are looking for > 256 ports per dev type vs (16? in Sun's 2.0 and fewer types). Its > hard to make assumptions. I've seen virtual ports start at /dev/ > foo100 for instance. > > It works out to over 7500 ports on Linux if you enable them all. > We already trim that back by default. See Linux-all-ports in > RXTXCommDriver.java. > > There are also native libraries that rxtx can link to. If you move > too much into Java, linking to 'standard' libraries with distros > will break. "configure --enable-liblock=yes" will not be doable. > This is probably a favorable way with RedHat, Debian, Suse and > others. Thats the right thing to do if there will be rpms, dpkg, .. > > For those reasons, I think it still make sense to keep it to a > minimal ~3 calls to JNI code that we can use for speed and > versatility. lock() isLocked(), unlock() perhaps. When I say > speed, its more about avoiding crossing the JNI layer multiple > times than java vs C performance. With versatility I think liblock > is the right way for most but not all (embeded) linux distros. > > -- > Trent Jarvi > tjarvi at qbang.org > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Mon Mar 20 12:44:47 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 20 Mar 2006 12:44:47 -0700 (MST) Subject: [Rxtx] BUG: Lock file stays even if port opening fails In-Reply-To: <82C19FE7-DDCB-45B6-B2C9-7606B66F0124@buechse.de> References: <82C19FE7-DDCB-45B6-B2C9-7606B66F0124@buechse.de> Message-ID: On Mon, 20 Mar 2006, Joachim Buechse wrote: > Ok, what about providing a default implementation in Java? > > The RXTXCommDriver would call a (native) function useNativeLocking and if > it returns true, call the native functions for lock() isLocked(), > unlock(), else is would use the Java based default implementation. This > could possibly be overriden by a property (again for debugging). > Hi Joachim That would be OK with me. -- Trent Jarvi tjarvi at qbang.org From dmarkman at mac.com Mon Mar 20 22:27:45 2006 From: dmarkman at mac.com (Dmitry Markman) Date: Tue, 21 Mar 2006 00:27:45 -0500 Subject: [Rxtx] binaries request Message-ID: <42702213-C222-4937-A585-7CFB17E47608@mac.com> Hi can somebody send me latest linux and windows binaries, please? or where I can find them (I didn't find them in the latest tareball) I gave up with my cygwin: something wrong I have no idea what java doesn't understand /cygwin/c syntax after I changed makefile it did java part but after that gcc 3.4.4 started to complain I set buffer length to 999 lines but I didn't get beginning of the story something wrong with my 1.4.2_09/include/jni.h gcc doesn't like it anyway I gave up thanks in advance Dmitry Markman -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060320/f8cbc57c/attachment-0050.html From tjarvi at qbang.org Mon Mar 20 22:36:48 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 20 Mar 2006 22:36:48 -0700 (MST) Subject: [Rxtx] binaries request In-Reply-To: <42702213-C222-4937-A585-7CFB17E47608@mac.com> References: <42702213-C222-4937-A585-7CFB17E47608@mac.com> Message-ID: On Tue, 21 Mar 2006, Dmitry Markman wrote: > Hi > can somebody send me latest linux and windows binaries, please? > > or where I can find them (I didn't find them in the latest tareball) > > I gave up with my cygwin: something wrong I have no idea what > java doesn't understand /cygwin/c syntax > after I changed makefile it did java part > but after that gcc 3.4.4 started to complain > I set buffer length to 999 lines but I didn't get beginning of the story > something wrong with my 1.4.2_09/include/jni.h gcc doesn't like it > anyway I gave up > > thanks in advance > Hi Dmitry The bins are here: ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7-bins-r2.zip Here are the files in the zip you want. Jar: rxtx-2.1-7-bins-r2/RXTXcomm.jar Windows: rxtx-2.1-7-bins-r2/Windows/i368-mingw32/rxtxSerial.dll Linux (x86) rxtx-2.1-7-bins-r2/Linux/i686-unknown-linux-gnu/librxtxSerial.so There are others in there including Parallel port support but those are the main ones for testing. -- Trent Jarvi tjarvi at qbang.org From dmarkman at mac.com Mon Mar 20 23:05:59 2006 From: dmarkman at mac.com (Dmitry Markman) Date: Tue, 21 Mar 2006 01:05:59 -0500 Subject: [Rxtx] binaries request In-Reply-To: References: <42702213-C222-4937-A585-7CFB17E47608@mac.com> Message-ID: thank you very much but windows's readme says: rxtxSerial.dll had to be recomopiled to link in missing native methods. should I ignore it? or what? thanks again also I understand that I should use mingw not cygwin I'll try to install mingw On Mar 21, 2006, at 12:36 AM, Trent Jarvi wrote: > On Tue, 21 Mar 2006, Dmitry Markman wrote: > >> Hi >> can somebody send me latest linux and windows binaries, please? >> >> or where I can find them (I didn't find them in the latest tareball) >> >> I gave up with my cygwin: something wrong I have no idea what >> java doesn't understand /cygwin/c syntax >> after I changed makefile it did java part >> but after that gcc 3.4.4 started to complain >> I set buffer length to 999 lines but I didn't get beginning of the >> story >> something wrong with my 1.4.2_09/include/jni.h gcc doesn't like it >> anyway I gave up >> >> thanks in advance >> > > Hi Dmitry > > The bins are here: > > ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7-bins-r2.zip > > Here are the files in the zip you want. > > Jar: > > rxtx-2.1-7-bins-r2/RXTXcomm.jar > > Windows: > > rxtx-2.1-7-bins-r2/Windows/i368-mingw32/rxtxSerial.dll > > Linux (x86) > > rxtx-2.1-7-bins-r2/Linux/i686-unknown-linux-gnu/librxtxSerial.so > > There are others in there including Parallel port support but those > are the main ones for testing. > > -- > Trent Jarvi > tjarvi at qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx Dmitry Markman From tjarvi at qbang.org Mon Mar 20 23:20:33 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 20 Mar 2006 23:20:33 -0700 (MST) Subject: [Rxtx] binaries request In-Reply-To: References: <42702213-C222-4937-A585-7CFB17E47608@mac.com> Message-ID: On Tue, 21 Mar 2006, Dmitry Markman wrote: > thank you very much > > but windows's readme says: > rxtxSerial.dll had to be recomopiled to link in missing native methods. > > should I ignore it? or what? > Hi Dmitry That dll should be OK. r2 is the recompile linked to the missing native method. The readme explains why it was recompiled; fuser.o was not linked into the dll in the first release. -- Trent Jarvi tjarvi at qbang.org From ariantristan at yahoo.com Mon Mar 20 23:55:24 2006 From: ariantristan at yahoo.com (Lambok Sianturi) Date: Mon, 20 Mar 2006 22:55:24 -0800 (PST) Subject: [Rxtx] jvm issue Message-ID: <20060321065524.94779.qmail@web50701.mail.yahoo.com> Hi All, This is my first time to join RxTx mailing list. I thank you all for allowing others to sign in in requests help. I use the latest RxTx lib in Fedora 3 with java version 1.4.2_09 b05. And I got this error: # # An unexpected error has been detected by HotSpot Virtual Machine: # # SIGSEGV (0xb) at pc=0x00bf27f3, pid=2633, tid=3086112448 # # Java VM: Java HotSpot(TM) Client VM (1.4.2_09-b05 mixed mode) # Problematic frame: # C [ld-linux.so.2+0xa7f3] # # An error report file with more information is saved as hs_err_pid2633.log # # If you would like to submit a bug report, please visit: # http://java.sun.com/webapps/bugreport/crash.jsp # ./run.sh: line 3: 2633 Aborted /usr/local/java/bin/java -Djava.library.path=/usr/local/java/jre/lib/ -Djsmsengine.debug=true -classpath jsmsengine.jar:smsgateway.jar:classes12.jar:RXTXcomm.jar:. com.api.sms.SMSServer What is the jvm depedency for the latest library? Can I use 1.4.2_09 b05? Thanks in advance. Arian --------------------------------- Yahoo! Mail Use Photomail to share photos without annoying attachments. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060320/83d58dd7/attachment-0050.html From f.frumento at ngi.it Tue Mar 21 00:21:47 2006 From: f.frumento at ngi.it (Fabio Frumento) Date: Tue, 21 Mar 2006 08:21:47 +0100 Subject: [Rxtx] Javadoc on the go Message-ID: <441FA98B.9050701@ngi.it> Hi Trent, sorry for the big delay but my job is running wild, i was out for some time but now i'm back and ready to continue the javadoc for Rxtx. Did you used the last javadoc patch i sent you ? let me know if i have to send it to you again or not. regards Fabio From lyon at docjava.com Tue Mar 21 00:51:18 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Tue, 21 Mar 2006 02:51:18 -0500 Subject: [Rxtx] lock files Message-ID: Hi All, You know, if the use of lock files were under Java control (rather than a build-time decision), it might enable a more unified binary distro. It might also facilitate quick prototyping of non-lock file approaches to resolving serial port contention issues (i.e., mac-like approaches vs. linux approaches, etc.). I realize that this is a radical overhaul of the lock file policy issue. Also, it may harm performance. On the other hand, our benchmarks on JNI overhead for modern processors indicate performance impact should be minimal. Perhaps it is more of an issue with the toybox systems. Suppose there were a class with a reasonable default...someone might write: SerialPortLockPolicy.setPolicy(SerialPortLockPolicy.UNIX_LOCK_FILE); SerialPortLockPolicy.setPolicy(SerialPortLockPolicy.NO_LOCK_CHECKING); SerialPortLockPolicy.setPolicy(SerialPortLockPolicy.MAC_STYLE); Thus, we could have a run-time reconfiguration of the serial port lock policy. A special NO_LOCK version of the binary would no longer be required. Any thoughts on this? Thanks! - Doug From joachim at buechse.de Tue Mar 21 03:09:09 2006 From: joachim at buechse.de (Joachim Buechse) Date: Tue, 21 Mar 2006 11:09:09 +0100 Subject: [Rxtx] lock files In-Reply-To: References: Message-ID: <8E12916A-1B9A-4FF2-B684-E2D1C794221B@buechse.de> This is pretty much what I thought about when I suggested, that the default behaviour could be overwritten with a property. I am very much in favor of this approach. In particular this allows much easier debugging for PC based java developers. I think big parts of the Java (and maybe some parts of the C code) could use a bit of a structural workover (unit tests, javadoc, synchronization, etc). Maybe there should be a CVS branch for this experimental version. I'd be happy to contribute a first workover for some of the Java code. Designing for testability and implementing a good bunch of unit tests has been a strategy that worked quite well in the Java projects I lead. And it ultimately allows more liberal change permission. Regards, Joachim On 21.03.2006, at 08:51, Dr. Douglas Lyon wrote: > Hi All, > You know, if the use of lock files were > under Java control (rather than a build-time decision), > it might enable a more unified binary distro. It might also > facilitate quick prototyping of non-lock file approaches > to resolving serial port contention issues (i.e., mac-like > approaches vs. linux approaches, etc.). > > I realize that this is a radical overhaul of the lock file policy > issue. Also, it may harm performance. On the other hand, > our benchmarks on JNI overhead for modern processors indicate > performance impact should be minimal. Perhaps it is more of > an issue with the toybox systems. > > Suppose there were a class with a reasonable default...someone > might write: > SerialPortLockPolicy.setPolicy(SerialPortLockPolicy.UNIX_LOCK_FILE); > SerialPortLockPolicy.setPolicy(SerialPortLockPolicy.NO_LOCK_CHECKING); > SerialPortLockPolicy.setPolicy(SerialPortLockPolicy.MAC_STYLE); > > Thus, we could have a run-time reconfiguration of the serial port lock > policy. A special NO_LOCK version of the binary would no longer > be required. > > Any thoughts on this? > > Thanks! > - Doug > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From joachim at buechse.de Tue Mar 21 06:23:08 2006 From: joachim at buechse.de (Joachim Buechse) Date: Tue, 21 Mar 2006 14:23:08 +0100 Subject: [Rxtx] PATCH: use of ioctl(fd, TIOCEXCL) instead of lockfiles Message-ID: <923AE774-EEA2-4911-92D8-32BB27802C8B@buechse.de> Here is the patch for the ioctl(fd, TIOCEXCL). I have verified this only for OSX 10.4.5, hence it is only defined for APPLE. However, it should work at least for Solaris as well. If a process has requested TIOEXCL further open calls by other user processes will fail. The patch also disables uucp style locking for APPLE. Obviously this is discussable. I think it is the way to go, as it eliminates creating the lock directory which doesnt exist on the standard installation and it eliminates messing with the system group definitions (adding users to group uucp). Regarding the possibility of root processes opening a device which is locked - I consider this a feature not a potential problem. It is highly unlikely, that somebody is crazy enough to run a JavaVM as root (unless he has no other means of getting a restricted IP port opened, ie doesnt understand ipfw). Anyway, even if the process runs as root, it fails when calling ioctl(fd, TIOCEXCL). It could however still open the port to listen for RING events. I.e. a fax server which needs to see incoming calls but otherwise doesnt want to block the port. So the only case where the proposed mechanism fails is, if an incorrectly implemented process running as root conflicts with a user process. I think this can be accepted. Regards, Joachim PS: If this patch is generally accepted, the installer and Mac doku should obviously be changed as well. Index: SerialImp.c =================================================================== RCS file: /usr/local/cvsroot/rxtx-devel/src/SerialImp.c,v retrieving revision 1.46.2.187 diff -u -r1.46.2.187 SerialImp.c --- SerialImp.c 29 Jan 2006 22:19:04 -0000 1.46.2.187 +++ SerialImp.c 21 Mar 2006 12:59:16 -0000 @@ -656,6 +656,25 @@ fd=OPEN (filename, O_RDWR | O_NOCTTY | O_NONBLOCK ); } while (fd < 0 && errno==EINTR); +#ifdef OPEN_EXCL + // Note that open() follows POSIX semantics: multiple open() calls to + // the same file will succeed unless the TIOCEXCL ioctl is issued. + // This will prevent additional opens except by root-owned processes. + // See tty(4) ("man 4 tty") and ioctl(2) ("man 2 ioctl") for details. + + if (fd >= 0 && (ioctl(fd, TIOCEXCL) == -1)) + { + sprintf( message, "open: exclusive access denied for % s\n", + filename ); + report( message ); + report_error( message ); + + close(fd); + goto fail; + } +#endif /* OPEN_EXCL */ + + if( configure_port( fd ) ) goto fail; (*env)->ReleaseStringUTFChars( env, jstr, filename ); sprintf( message, "open: fd returned is %i\n", fd ); Index: SerialImp.h =================================================================== RCS file: /usr/local/cvsroot/rxtx-devel/src/SerialImp.h,v retrieving revision 1.11.2.49 diff -u -r1.11.2.49 SerialImp.h --- SerialImp.h 5 Jul 2005 17:47:21 -0000 1.11.2.49 +++ SerialImp.h 21 Mar 2006 12:59:17 -0000 @@ -135,7 +135,8 @@ /*# define LOCKDIR "/var/spool/uucp"*/ # define LOCKDIR "/var/lock" # define LOCKFILEPREFIX "LK." -# define UUCP +/*# define UUCP*/ +# define OPEN_EXCL #endif /* __APPLE__ */ #if defined(__NetBSD__) # define DEVICEDIR "/dev/" From tjarvi at qbang.org Tue Mar 21 10:26:08 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 21 Mar 2006 10:26:08 -0700 (MST) Subject: [Rxtx] Javadoc on the go In-Reply-To: <441FA98B.9050701@ngi.it> References: <441FA98B.9050701@ngi.it> Message-ID: On Tue, 21 Mar 2006, Fabio Frumento wrote: > Hi Trent, > > sorry for the big delay but my job is running wild, i was out for some > time but now i'm back and ready to continue the javadoc for Rxtx. > > Did you used the last javadoc patch i sent you ? let me know if i have to > send it to you again or not. > > regards > > Fabio Hi Fabio The patch is in the rxtx mail-list archives. It will be going in soon. I did not see a time critical portion. I'll probably be going through the list since the last batch of patches this weekend and putting them into CVS. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Tue Mar 21 10:57:18 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 21 Mar 2006 10:57:18 -0700 (MST) Subject: [Rxtx] jvm issue In-Reply-To: <20060321065524.94779.qmail@web50701.mail.yahoo.com> References: <20060321065524.94779.qmail@web50701.mail.yahoo.com> Message-ID: On Mon, 20 Mar 2006, Lambok Sianturi wrote: > Hi All, > This is my first time to join RxTx mailing list. I thank you all for allowing others to sign in in requests help. > I use the latest RxTx lib in Fedora 3 with java version 1.4.2_09 b05. And I got this error: > > # > # An unexpected error has been detected by HotSpot Virtual Machine: > # > # SIGSEGV (0xb) at pc=0x00bf27f3, pid=2633, tid=3086112448 > # > # Java VM: Java HotSpot(TM) Client VM (1.4.2_09-b05 mixed mode) > # Problematic frame: > # C [ld-linux.so.2+0xa7f3] A native library loading error? What happens if you recompile rxtx on your system and install that? This sounds like an ABI problem? rxtx 2.1-7 was compiled with a gcc 2.96 toolchain as I recall. The hope is newer system will be backwards compatible. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Tue Mar 21 11:05:29 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 21 Mar 2006 11:05:29 -0700 (MST) Subject: [Rxtx] PATCH: use of ioctl(fd, TIOCEXCL) instead of lockfiles In-Reply-To: <923AE774-EEA2-4911-92D8-32BB27802C8B@buechse.de> References: <923AE774-EEA2-4911-92D8-32BB27802C8B@buechse.de> Message-ID: On Tue, 21 Mar 2006, Joachim Buechse wrote: > Here is the patch for the ioctl(fd, TIOCEXCL). I have verified this only > for OSX 10.4.5, hence it is only defined for APPLE. However, it should > work at least for Solaris as well. > > If a process has requested TIOEXCL further open calls by other user > processes will fail. > > The patch also disables uucp style locking for APPLE. Obviously this is > discussable. I think it is the way to go, as it eliminates creating the > lock directory which doesnt exist on the standard installation and it > eliminates messing with the system group definitions (adding users to > group uucp). > > Regarding the possibility of root processes opening a device which is > locked - I consider this a feature not a potential problem. It is highly > unlikely, that somebody is crazy enough to run a JavaVM as root (unless > he has no other means of getting a restricted IP port opened, ie doesnt > understand ipfw). Anyway, even if the process runs as root, it fails when > calling ioctl(fd, TIOCEXCL). It could however still open the port to > listen for RING events. I.e. a fax server which needs to see incoming > calls but otherwise doesnt want to block the port. So the only case where > the proposed mechanism fails is, if an incorrectly implemented process > running as root conflicts with a user process. I think this can be > accepted. > > Regards, > Joachim > > PS: If this patch is generally accepted, the installer and Mac doku > should obviously be changed as well. > > > Index: SerialImp.c > =================================================================== > RCS file: /usr/local/cvsroot/rxtx-devel/src/SerialImp.c,v > retrieving revision 1.46.2.187 > diff -u -r1.46.2.187 SerialImp.c > --- SerialImp.c 29 Jan 2006 22:19:04 -0000 1.46.2.187 > +++ SerialImp.c 21 Mar 2006 12:59:16 -0000 > @@ -656,6 +656,25 @@ > fd=OPEN (filename, O_RDWR | O_NOCTTY | O_NONBLOCK ); > } while (fd < 0 && errno==EINTR); > > +#ifdef OPEN_EXCL > + // Note that open() follows POSIX semantics: multiple open() > calls to > + // the same file will succeed unless the TIOCEXCL ioctl is > issued. > + // This will prevent additional opens except by root-owned > processes. > + // See tty(4) ("man 4 tty") and ioctl(2) ("man 2 ioctl") for > details. > + > + if (fd >= 0 && (ioctl(fd, TIOCEXCL) == -1)) > + { > + sprintf( message, "open: exclusive access denied for % > s\n", > + filename ); > + report( message ); > + report_error( message ); > + > + close(fd); > + goto fail; > + } > +#endif /* OPEN_EXCL */ > + > + > if( configure_port( fd ) ) goto fail; > (*env)->ReleaseStringUTFChars( env, jstr, filename ); > sprintf( message, "open: fd returned is %i\n", fd ); > Index: SerialImp.h > =================================================================== > RCS file: /usr/local/cvsroot/rxtx-devel/src/SerialImp.h,v > retrieving revision 1.11.2.49 > diff -u -r1.11.2.49 SerialImp.h > --- SerialImp.h 5 Jul 2005 17:47:21 -0000 1.11.2.49 > +++ SerialImp.h 21 Mar 2006 12:59:17 -0000 > @@ -135,7 +135,8 @@ > /*# define LOCKDIR "/var/spool/uucp"*/ > # define LOCKDIR "/var/lock" > # define LOCKFILEPREFIX "LK." > -# define UUCP > +/*# define UUCP*/ > +# define OPEN_EXCL > #endif /* __APPLE__ */ > #if defined(__NetBSD__) > # define DEVICEDIR "/dev/" > This looks like a good start. What do you think Dmitry? Perhaps all systems with TIOCEXCL defined should use that though. Even if they use lockfiles. It wont hurt anything. That would catch people hacking their own serial apps without checking lockfiles. Its a good idea to avoid C++ style comments in the C portions. Some older systems don't deal with them well. If it's just for Mac OS X, it isn't a big deal. I think it was the Irix compiler that was problematic? -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Tue Mar 21 11:22:05 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 21 Mar 2006 11:22:05 -0700 (MST) Subject: [Rxtx] lock files In-Reply-To: <8E12916A-1B9A-4FF2-B684-E2D1C794221B@buechse.de> References: <8E12916A-1B9A-4FF2-B684-E2D1C794221B@buechse.de> Message-ID: We can try it. Maybe the JNI is much improved. The nice thing about linking into liblock is distros then worry about lockfiles on their systems. This way, we have to deal with any changes that may show up. On Tue, 21 Mar 2006, Joachim Buechse wrote: > This is pretty much what I thought about when I suggested, that the > default behaviour could be overwritten with a property. I am very much in > favor of this approach. In particular this allows much easier debugging > for PC based java developers. > > I think big parts of the Java (and maybe some parts of the C code) could > use a bit of a structural workover (unit tests, javadoc, synchronization, > etc). Maybe there should be a CVS branch for this experimental version. > I'd be happy to contribute a first workover for some of the Java code. > Designing for testability and implementing a good bunch of unit tests has > been a strategy that worked quite well in the Java projects I lead. And > it ultimately allows more liberal change permission. > > Regards, > Joachim > > > On 21.03.2006, at 08:51, Dr. Douglas Lyon wrote: > >> Hi All, >> You know, if the use of lock files were >> under Java control (rather than a build-time decision), >> it might enable a more unified binary distro. It might also >> facilitate quick prototyping of non-lock file approaches >> to resolving serial port contention issues (i.e., mac-like >> approaches vs. linux approaches, etc.). >> >> I realize that this is a radical overhaul of the lock file policy >> issue. Also, it may harm performance. On the other hand, >> our benchmarks on JNI overhead for modern processors indicate >> performance impact should be minimal. Perhaps it is more of >> an issue with the toybox systems. >> >> Suppose there were a class with a reasonable default...someone >> might write: >> SerialPortLockPolicy.setPolicy(SerialPortLockPolicy.UNIX_LOCK_FILE); >> SerialPortLockPolicy.setPolicy(SerialPortLockPolicy.NO_LOCK_CHECKING); >> SerialPortLockPolicy.setPolicy(SerialPortLockPolicy.MAC_STYLE); >> >> Thus, we could have a run-time reconfiguration of the serial port lock >> policy. A special NO_LOCK version of the binary would no longer >> be required. >> >> Any thoughts on this? >> >> Thanks! >> - Doug >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From dmarkman at mac.com Tue Mar 21 16:05:17 2006 From: dmarkman at mac.com (Dmitry Markman) Date: Tue, 21 Mar 2006 18:05:17 -0500 Subject: [Rxtx] PATCH: use of ioctl(fd, TIOCEXCL) instead of lockfiles In-Reply-To: References: <923AE774-EEA2-4911-92D8-32BB27802C8B@buechse.de> Message-ID: <512AC70C-BB86-48F2-A83C-023F35C23BAB@mac.com> I think it's cool, but I'd like to have that property implementation when user can choose between locking mechanism about comments: it's easy to change comments to the C style or we can use extensions of the file to cpp so c++ compiler will be used On Mar 21, 2006, at 1:05 PM, Trent Jarvi wrote: > This looks like a good start. What do you think Dmitry? Perhaps > all systems with TIOCEXCL defined should use that though. Even if > they use lockfiles. It wont hurt anything. That would catch > people hacking their own serial apps without checking lockfiles. > > Its a good idea to avoid C++ style comments in the C portions. > Some older systems don't deal with them well. If it's just for Mac > OS X, it isn't a big deal. I think it was the Irix compiler that > was problematic? Dmitry Markman From dmarkman at mac.com Tue Mar 21 16:13:00 2006 From: dmarkman at mac.com (Dmitry Markman) Date: Tue, 21 Mar 2006 18:13:00 -0500 Subject: [Rxtx] PATCH: use of ioctl(fd, TIOCEXCL) instead of lockfiles In-Reply-To: References: <923AE774-EEA2-4911-92D8-32BB27802C8B@buechse.de> Message-ID: I'd like to add that creating locking folder isn't a big deal we never had a problem related to the lock folders, because we always used installer on mac os x from other hand I'm not very much familiar with iotcl locking approach and I'm not sure it's more efficient Joachim wrote "I think it is the way to go, as it eliminates creating the lock directory which doesnt exist on the standard installation and it eliminates messing with the system group definitions (adding users to group uucp)." but I really didn't have any problem with that 1. doesn't exist on the standard installation there are many-many things that don't exist in the standard installation so I don't think that argument is strong enough 2. messing with the system group definitions I don't think we're messing with the group definition mac os x provides very clear way to set up group's members and together with Greg Guerin AuthKit there is no problem to set those definitions so I don't think that argument is strong either but from other hand using iotcl is more promising and is more elegant On Mar 21, 2006, at 1:05 PM, Trent Jarvi wrote: > > This looks like a good start. What do you think Dmitry? Perhaps > all systems with TIOCEXCL defined should use that though. Even if > they use lockfiles. It wont hurt anything. That would catch > people hacking their own serial apps without checking lockfiles. Dmitry Markman From joachim at buechse.de Wed Mar 22 04:46:45 2006 From: joachim at buechse.de (Joachim Buechse) Date: Wed, 22 Mar 2006 12:46:45 +0100 Subject: [Rxtx] PATCH: use of ioctl(fd, TIOCEXCL) instead of lockfiles In-Reply-To: References: <923AE774-EEA2-4911-92D8-32BB27802C8B@buechse.de> Message-ID: Sorry, I was not very clear with my arguments, so I will try again;-) Please, don't take this as an attack against work that has been done. I think the contributions that have been made in the past were made in a good spirit. But I really believe, that the current solution for OSX has many shortcomings and should be changed as soon as possible. lock files --- The /var/lock folder does not exist on the standard OSX installation, however the standard installation includes several applications that use serial ports (i.e. the FAX capability). This indicates, that the lock folder approach will not work well with system components. Applications for OSX will generally try to live in harmony with system components (except for HP print drivers of course). I think RXTX should follow this approach as well. uucp group --- Accessing serial ports is not an admin privileged operation on OSX. Any user (world) has read/write privileges on /dev/tty*. So the system default is to not enforce any group membership to access these ports. The group uucp however is a system group on all unix systems I know. It exists for certain system processes. A non admin user should in general not be a member of this group. Quite arguably no user should ever be a member of this group. Installer --- My general opinion is, that - no Installer should touch user or group data without warning - no Application Installer should touch groups which are not specific to the very application installed - no Installer should ever add regular users to a system group The current installer injects the installing user in the group uucp without warning about this change and without giving the option to "opt out" of this change. This is a potential security risk (but not currently a real one, as OSX contains no folders belonging to group uucp). The current installer does not work for multi user systems. It puts the installing user in the uucp group. However the installing user is not necessarily the user that will use the application. Putting all users that may use a serial port application in the system group uucp seems like a very invasive approach to me. Besides that, newly created users will not automatically be in the group and hence, serial applications will "break" for new users without obvious reasons. Avoiding the lock files will allow self contained applications (i.e. drag&drop installation). In my eyes this is largely preferable over an installer that requests admin privileges. Adding up all these points indicates very strongly, that the lock-file implementation is not the way to go on OSX. Regards, Joachim On 22.03.2006, at 00:13, Dmitry Markman wrote: > I'd like to add that > > creating locking folder isn't a big deal > we never had a problem related to the lock folders, because we > always used installer on mac os x > from other hand I'm not very much familiar with iotcl locking > approach and I'm not sure it's more efficient > > Joachim wrote "I think it is the way to go, as it eliminates > creating the lock directory which doesnt exist on the standard > installation and it eliminates messing with the system group > definitions (adding users to group uucp)." but I really didn't have > any problem with that > > 1. doesn't exist on the standard installation > there are many-many things that don't exist in the standard > installation so I don't think that argument is strong enough > 2. messing with the system group definitions > I don't think we're messing with the group definition > mac os x provides very clear way to set up group's members and > together with Greg Guerin AuthKit there is no problem to set those > definitions > so I don't think that argument is strong either > but from other hand using iotcl is more promising and is more elegant > > > > On Mar 21, 2006, at 1:05 PM, Trent Jarvi wrote: > >> >> This looks like a good start. What do you think Dmitry? Perhaps >> all systems with TIOCEXCL defined should use that though. Even if >> they use lockfiles. It wont hurt anything. That would catch >> people hacking their own serial apps without checking lockfiles. > > Dmitry Markman > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From dmarkman at mac.com Wed Mar 22 05:27:13 2006 From: dmarkman at mac.com (Dmitry Markman) Date: Wed, 22 Mar 2006 07:27:13 -0500 Subject: [Rxtx] PATCH: use of ioctl(fd, TIOCEXCL) instead of lockfiles In-Reply-To: References: <923AE774-EEA2-4911-92D8-32BB27802C8B@buechse.de> Message-ID: <83440CF3-DCD8-41C1-B941-F227232C27E3@mac.com> thanks for the very good explanation I didn't think that you were attacking any thing, so don't worry I just had feeling, that there were more aesthetic reasons for going to ioctl then real necessity now you explained everything quite well (BTW, asfar as I remember installer asks admin password so it wasn't quiet, but it really doesn't matter now) thanks On Mar 22, 2006, at 6:46 AM, Joachim Buechse wrote: > Sorry, I was not very clear with my arguments, so I will try again;-) > > Please, don't take this as an attack against work that has been > done. I think the contributions that have been made in the past > were made in a good spirit. But I really believe, that the current > solution for OSX has many shortcomings and should be changed as > soon as possible. > > lock files > --- > The /var/lock folder does not exist on the standard OSX > installation, however the standard installation includes several > applications that use serial ports (i.e. the FAX capability). This > indicates, that the lock folder approach will not work well with > system components. Applications for OSX will generally try to live > in harmony with system components (except for HP print drivers of > course). I think RXTX should follow this approach as well. > > uucp group > --- > Accessing serial ports is not an admin privileged operation on OSX. > Any user (world) has read/write privileges on /dev/tty*. So the > system default is to not enforce any group membership to access > these ports. The group uucp however is a system group on all unix > systems I know. It exists for certain system processes. A non admin > user should in general not be a member of this group. Quite > arguably no user should ever be a member of this group. > > Installer > --- > My general opinion is, that > - no Installer should touch user or group data without warning > - no Application Installer should touch groups which are not > specific to the very application installed > - no Installer should ever add regular users to a system group > > The current installer injects the installing user in the group uucp > without warning about this change and without giving the option to > "opt out" of this change. This is a potential security risk (but > not currently a real one, as OSX contains no folders belonging to > group uucp). > > The current installer does not work for multi user systems. It puts > the installing user in the uucp group. However the installing user > is not necessarily the user that will use the application. Putting > all users that may use a serial port application in the system > group uucp seems like a very invasive approach to me. Besides that, > newly created users will not automatically be in the group and > hence, serial applications will "break" for new users without > obvious reasons. > > > Avoiding the lock files will allow self contained applications > (i.e. drag&drop installation). In my eyes this is largely > preferable over an installer that requests admin privileges. Adding > up all these points indicates very strongly, that the lock-file > implementation is not the way to go on OSX. > > Regards, > Joachim > > > On 22.03.2006, at 00:13, Dmitry Markman wrote: > >> I'd like to add that >> >> creating locking folder isn't a big deal >> we never had a problem related to the lock folders, because we >> always used installer on mac os x >> from other hand I'm not very much familiar with iotcl locking >> approach and I'm not sure it's more efficient >> >> Joachim wrote "I think it is the way to go, as it eliminates >> creating the lock directory which doesnt exist on the standard >> installation and it eliminates messing with the system group >> definitions (adding users to group uucp)." but I really didn't >> have any problem with that >> >> 1. doesn't exist on the standard installation >> there are many-many things that don't exist in the standard >> installation so I don't think that argument is strong enough >> 2. messing with the system group definitions >> I don't think we're messing with the group definition >> mac os x provides very clear way to set up group's members and >> together with Greg Guerin AuthKit there is no problem to set those >> definitions >> so I don't think that argument is strong either >> but from other hand using iotcl is more promising and is more elegant >> >> >> >> On Mar 21, 2006, at 1:05 PM, Trent Jarvi wrote: >> >>> >>> This looks like a good start. What do you think Dmitry? Perhaps >>> all systems with TIOCEXCL defined should use that though. Even >>> if they use lockfiles. It wont hurt anything. That would catch >>> people hacking their own serial apps without checking lockfiles. >> >> Dmitry Markman >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx Dmitry Markman From lyon at docjava.com Wed Mar 22 06:12:18 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Wed, 22 Mar 2006 08:12:18 -0500 Subject: [Rxtx] sole of a new design pattern Message-ID: Hi All, I have been thinking about how we design the serial port software. I think we need a new design pattern. For lack of a better term, I shall call it: The Parametric Singleton Design Pattern By Douglas A. Lyon ABSTRACT The goal of the singleton design pattern is to make sure that there is one, and only one, instance of a given class. The goal of the parametric singleton design pattern is to make sure that there is one, and only one, instance of a given class with the given parametric values. We parametric singleton design pattern combines the singleton design pattern with a parameter that enables unique creation of instances of a class. These instances are cached. When a user asks for an instance with these parameters, the cache is checked. If the instance is in the cache, the instance is returned, otherwise it is created, added to the cache and then returned. We apply our parametric singleton design pattern to the retrieval of RMI registries bound to a given port. The goal of our system is to make sure that no two RMI registries are listening to the same socket and to make use of the RMI registries after they have been created. RMI registries are used in distributed computation. Introduction The singleton design pattern is meant to ensure that on a single instance of a class exists. It is also meant to provide a global point of access to it. The intent of the parametric singleton design pattern is to ensure that a class has only one instance for a given set of parameter values. It also provides a global point of access to it. Motivation A system cannot tolerate multiple instances of some classes with identical parameters. For example, you cannot have two instances making use of the same serial port, at the same time. You cannot have two instances that are trying to listen to the same socket connection. You cannot have two instances writing to the same file structure at the same time. As the operating system is often thought of as the arbiter of consumed resources (i.e., tape drives, serial ports, etc.) we frequently leave it to an operating system implementation to resolve these contention issues. Even for similar resources (like serial ports) there are few standards for handling contention. For example, serial ports on Linux are locked using a "/var/lock" file. POSIX, on the other hand, uses ioctl mechanisms to prevent contention. A better solution is to make a class that is responsible for keeping track of the instances created from the class. The class is declared final, so that it cannot be subclassed. The class also has a private constructor, so that other classes cannot instance it. The new design pattern is called the parametric singleton design pattern and it provides a way to access and create instances with given parameters. Applicability Use the Parametric Singleton Design Pattern when: 1. There must be exactly one instance of a class with the given parameters. 2. The instances must be accessible to clients from a well-known access point. Structure Insert UML diagram here. Participants The Parametric Singleton Clients that need instances 1. The Parametric Singleton defines an instance upon request from a client, if, and only if, the instance does not already exist. 2. The Parametric Singleton returns the instance to the client. 3. The Parametric Singleton is responsible for creating unique instances from given parameters. Collaborations Clients obtain a reference to a Parametric Singleton instance only through the parametric singleton design pattern. If the instance is left in an improper state (e.g., the serial port was left open) it is NOT the role of the Parametric Singleton Design Pattern to close the IO port. Nor is it the role of the Parametric Singleton Design Pattern to open the port. That role is delegate to some other part of the system. Further, it is not the role of the Parametric Singleton Design Pattern to check out resources. That is, multiple threads can have multiple references to the same resource at the same time. MUTEX locking is delegated to some other part of the system. Consequences The Parametric Singleton Design Pattern has several benefits: 1. Controlled access to parametrically defined instances. Since the Parametric Singleton class encapsulates its instances, there is control over how and when clients access it. 2. Reduced name space. The Parametric Singleton pattern avoids global variables that store instances created from the same parameter. Implementation Here are implementation issues to consider when using the Parametric Singleton pattern: 1. Unique mapping of parameters. The Parametric Singleton pattern requires that there be a mean to isomorphically map the parameter space into the instance space and back again. 2. Ensure unique instances. The Parametric Singleton pattern makes unique instances from parameters, and it does so only once. 3. Cache instances for fast retrieval. The Parametric Singleton pattern must be able to look up instances, given some set of parameters, and do so from some data structure. That is, there must be enough space to hold references to all the instances the program will need. Also, a mechanism is needed to look up and retrieve the instances quickly enough to satisfy the clients. Sample Code public final class ParametricSingletonRmiRegistry { private static Hashtable registry = new Hashtable(100); // use singleton pattern and??????????????????????????????????????????????? // prevent instantiation of RmiRegistryUtils.?????????????????????????????? private ParametricSingletonRmiRegistry() { } // the only instance of the Registry held by the RmiRegistryUtils?????????? public static void listNames(Integer port) { if (!isInCacheAndRunning(port)) return; Registry r = (Registry) registry.get(port); System.out.println("registry on port: " + port); System.out.println("registry: " + r); System.out.println("names: "); try { print(r.list()); } catch (RemoteException e) { In.message(e); } System.out.println("------------------------"); } /**???????????????????????????????????????????????????????????????????????? * Checks whether a Registry has been started on this host????????????????? * in the specified port.?????????????????????????????????????????????????? * If not, it tries to start one.?????????????????????????????????????????? * when it fails to start a Registry, it exits the program????????????????? * with exit code 1.??????????????????????????????????????????????????????? */ public static void restart(int port) { if (isInCacheAndRunning(port)) return; try { startRegistry(port); } catch (RemoteException e) { In.message(e); } } /**???????????????????????????????????????????????????????????????????????? * @param port????????????????????????????????????????????????????????????? * @return true if registry is in cache and running???????????????????????? */ private static boolean isInCacheAndRunning(Integer port) { if (!isRegistryRunning(port.intValue())) return false; if (!isRegistryInCache(port.intValue())) return false; return true; } /**???????????????????????????????????????????????????????????????????????? * @param port????????????????????????????????????????????????????????????? * @return true if we are able to locate a local registry on port.??????????????????????????????????????????????????????????????????????????? */ private static boolean isRegistryRunning(int port) { try { Registry r = LocateRegistry.getRegistry(port); if (r != null) return true; } catch (RemoteException e) { return false; } return false; } /**???????????????????????????????????????????????????????????????????????? * @param port????????????????????????????????????????????????????????????? * @return return true if registry is in cache????????????????????????????? */ private static boolean isRegistryInCache(int port) { if (registry.get(new Integer(port)) == null) return false; return true; } /**???????????????????????????????????????????????????????????????????????? * Restart the registry, if needed.???????????????????????????????????????? * Return the only instance of the registry for consistent global?????????? * using by making use of the Singleton Design Pattern????????????????????? *????????????????????????????????????????????????????????????????????????? * @return the internally held registry instance.?????????????????????????? */ public static Registry getRegistry(Integer port) { restart(port); return (Registry) registry.get(port); } private static void startRegistry(Integer port) throws RemoteException { Registry r; try { r = LocateRegistry.createRegistry(port.intValue()); registry.put(port, r); //r = new sun.rmi.registry.RegistryImpl???????????????????????????? /// (port.intValue());?????????????????????????????????????? // registry.put(port, r);?????????????????????????????????????????? } catch (Exception e) { //e.printStackTrace();????????????????????????????????????????????? r = LocateRegistry.getRegistry(port.intValue()); registry.put(port, r); } } public static void main(String args[]) throws RemoteException { //restart(port);??????????????????????????????????????????????????????? restart(5001); restart(5002); restart(5002); Registry r = LocateRegistry.getRegistry(5002); System.out.println("registry="+r); } } I would very much like to get your feedback on this new design pattern idea. Thank you for your time. Regards, - Doug From david.garnier at trusted-logic.com Wed Mar 22 07:36:10 2006 From: david.garnier at trusted-logic.com (David Garnier) Date: Wed, 22 Mar 2006 15:36:10 +0100 Subject: [Rxtx] sole of a new design pattern In-Reply-To: References: Message-ID: <442160DA.80107@trusted-logic.com> Hello, > The Parametric Singleton Design Pattern The Singleton is the most abused design pattern ever. Good use-cases for this pattern are extremely rare and mostly confined to problems related to hardware resources, like serial ports. > Applicability > > Use the Parametric Singleton Design Pattern when: > 1. There must be exactly one instance of a class with the given > parameters. OK. As I said above, this case this actually very unusual. The Singleton pattern is mostly used when : > 2. The instances must be accessible to clients from a well-known > access point. Using the singleton pattern in this case is just convenient for the programmer. Problems arises pretty quickly, especially if you attempt to unit-test your classes. 1) If your singleton is stateful, or hold on to stateful objects, it means that two different unit tests are not actually independent. Instead of starting with a brand new environment, the result of a test may be affected by the result of a previous test. This problem also arise when with your class relies on a database. In both cases, the solution is to reset your "unique" resource (Singleton or database) at the beginning of the test, which is a pain. Also, while most projects connect to a single database, projects that allow the use of Singletons usually contain several of thems, and new ones may cropped up unnoticed. You quickly end up with test cases that only pass in a certain order, which is a royal pain. 2) You cannot mockup a singleton. Once everyone calls the SomeSingleton class statically, you can't replace your class by SomeSingletonMockup. Furthermore, even for hardware services, the Singleton pattern does not really prevent concurrent accesses. If you start the same program in two different JVMs, unless they somehow shared the state of their "Singletons" (through lock files for example), the Singleton pattern will not prevent concurrent access. Our application uses RXTX, and we routinely encounter cases where another (native) application has already locked the port. Since we cannot modify the native application to recognize lock files, OS-level control is irreplaceable. > > Consequences > The Parametric Singleton Design Pattern has several benefits: > > 1. Controlled access to parametrically defined instances. Since > the Parametric Singleton class encapsulates its instances, there is > control over how and when clients access it. Not really. Once you've returned the instance to a client, you've lost control over it. The client can to whatever it wants with it. You cannot "recall" the instance or claim it back. > 2. Reduced name space. The Parametric Singleton pattern avoids > global variables that store instances created from the same parameter. Sure, but you don't have to rely on a Singleton for that. Just create a single Factory. > I would very much like to get your feedback on this new design > pattern idea. Well, it's nothing new. Some may say that it is the point of design patterns: formalizes the designs that occur again and again. However, this design is simply a combination of the Singleton and Factory patterns. I did use it in the past, but now I've been exposed to the shortcomings of the Singleton pattern, so I limit myself to Factories. Regards, David From sean_montgomery at baseview.com Wed Mar 22 08:35:28 2006 From: sean_montgomery at baseview.com (Sean Montgomery) Date: Wed, 22 Mar 2006 10:35:28 -0500 Subject: [Rxtx] sole of a new design pattern In-Reply-To: <442160DA.80107@trusted-logic.com> References: <442160DA.80107@trusted-logic.com> Message-ID: <05769CA7-A51B-4CF0-BAA0-E02DD905F5A4@baseview.com> On Mar 22, 2006, at 9:36 AM, David Garnier wrote: > Furthermore, even for hardware services, the Singleton pattern does > not really prevent concurrent > accesses. If you start the same program in two different JVMs, > unless they somehow shared the state > of their "Singletons" (through lock files for example), the > Singleton pattern will not prevent > concurrent access. > Multiple class loaders in a single JVM can be tricky, too. Then there's synchronization, lazy initialization and serialization of singletons to contend with. Bloch's Effective Java covers these, and here's a few articles: http://www.javaworld.com/javaworld/jw-04-2003/jw-0425-designpatterns- p3.html http://java.sun.com/developer/technicalArticles/Programming/singletons/ Just FYI :-) From lyon at docjava.com Wed Mar 22 08:50:48 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Wed, 22 Mar 2006 10:50:48 -0500 Subject: [Rxtx] sole of a new design pattern In-Reply-To: <442160DA.80107@trusted-logic.com> References: <442160DA.80107@trusted-logic.com> Message-ID: Hi All, First, I would like to thank David for his prompt and thoughtful remarks. I had no idea people that feel strongly about a design patterns! Wow! Feedback (particularly critical feedback) is greatly appreciated. Starting at the end, first: >I did use it in >the past, but now I've been exposed to the shortcomings of the >Singleton pattern, so I limit myself to Factories. David, if I understood your comments correctly, you suggested that Factories can be used in leu of the Singleton Design Pattern, or even the Parametric Singleton Design Pattern. As I see in [Gof]: Factory Method: Intent "Define an interface for creating an object, but let subclasses decide which class to instantiate. Factory Method lets a class defer instantiation to subclasses." The Singleton Design Pattern is a concrete class, which is rather different, right? Also, subclasses are not permitted with Singleton, as they are final. Naturally, I could use an abstract factory as a parent for a singleton. I could even design a facade that could be implemented with the singleton....but that is not the intention of the design. Unless you want a mock-up, as discussed, below: More below: >Hello, > >> The Parametric Singleton Design Pattern > >The Singleton is the most abused design pattern ever. Good use-cases >for this pattern are extremely >rare and mostly confined to problems related to hardware resources, >like serial ports. > > >> Applicability >> >> Use the Parametric Singleton Design Pattern when: >> 1. There must be exactly one instance of a class with the given >> parameters. >OK. As I said above, this case this actually very unusual. The >Singleton pattern is mostly used when : >> 2. The instances must be accessible to clients from a well-known >> access point. > >Using the singleton pattern in this case is just convenient for the >programmer. Problems arises >pretty quickly, especially if you attempt to unit-test your classes. > >1) If your singleton is stateful, or hold on to stateful objects, it >means that two different unit >tests are not actually independent. Instead of starting with a brand >new environment, the result of >a test may be affected by the result of a previous test. This >problem also arise when with your >class relies on a database. In both cases, the solution is to reset >your "unique" resource >(Singleton or database) at the beginning of the test, which is a >pain. Also, while most projects >connect to a single database, projects that allow the use of >Singletons usually contain several of >thems, and new ones may cropped up unnoticed. You quickly end up >with test cases that only pass in a >certain order, which is a royal pain. There are basic problems with communicating finite state machines that include reachability and deadlock analysis. These are addressed with petri net analysis and are beyond the scope of the design pattern. As you quite rightly pointed out; the parametric singleton pattern (or the singleton pattern, for that matter) enable multiple threads to gain access to the same instance. The only way that I can see to block others from gaining access to the reference is the synchronize keyword. This is putting a spin-lock (or MUTEX) on the reference. The question of how to unit-test a design pattern like the parametric singleton remains open. Perhaps this is a deficiency. > >2) You cannot mockup a singleton. Once everyone calls the >SomeSingleton class statically, you can't >replace your class by SomeSingletonMockup. Acutally, I am not sure that this is true. If the Singleton implements a Facade interface, it should be possible to make the replacement. Right? > >Furthermore, even for hardware services, the Singleton pattern does >not really prevent concurrent >accesses. If you start the same program in two different JVMs, >unless they somehow shared the state >of their "Singletons" (through lock files for example), the >Singleton pattern will not prevent >concurrent access. Good Point!! You have sharp eyes! The singleton design pattern should/could take responsibility for this. In fact, you may notice that my code does have an implementation (LocateRegistry) that can work across JVM's. The LocateRegistry will even work across the Internet! LocateRegistry takes both a host name and a Port (lock files just don't do this). I did not think to implement this beyond the local machine, but, in its present form, it will work across different processes. > >Our application uses RXTX, and we routinely encounter cases where >another (native) application has >already locked the port. Since we cannot modify the native >application to recognize lock files, >OS-level control is irreplaceable. The singleton design pattern is not meant to replace OS-level control, but to centralize the Java programmers access to it. If lock files, for example, are used for serial ports, the Singleton Design Pattern should be able to work with them. > > >> >> Consequences >> The Parametric Singleton Design Pattern has several benefits: >> > > 1. Controlled access to parametrically defined instances. Since >> the Parametric Singleton class encapsulates its instances, there is >> control over how and when clients access it. > >Not really. Once you've returned the instance to a client, you've >lost control over it. The client >can to whatever it wants with it. You cannot "recall" the instance >or claim it back. Good point, this should read: > 1. Controll when parametrically defined instances are created. Since > > the Parametric Singleton class encapsulates its instances, there is > > control over how and when they are instanced. > >> 2. Reduced name space. The Parametric Singleton pattern avoids >> global variables that store instances created from the same parameter. > >Sure, but you don't have to rely on a Singleton for that. Just >create a single Factory. > > Thank you for your thoughtful and prompt response! Regards, - Doug From dmarkman at mac.com Wed Mar 22 21:21:55 2006 From: dmarkman at mac.com (Dmitry Markman) Date: Wed, 22 Mar 2006 23:21:55 -0500 Subject: [Rxtx] sole of a new design pattern In-Reply-To: <442160DA.80107@trusted-logic.com> References: <442160DA.80107@trusted-logic.com> Message-ID: I don't think I get it On Mar 22, 2006, at 9:36 AM, David Garnier wrote: > Using the singleton pattern in this case is just convenient for the > programmer. Problems arises > pretty quickly, especially if you attempt to unit-test your classes. so you're saying that something isn't so good because you can not test it in the convenient way? if that's true, I'm totally disagree change your test, debug whatever, but if software is efficient at runtime, works fine and only problem is some unit test (which is some kind of framework for testing) then dump that unit test , dump that unit framework and make something appropriate to the software you're testing so if Douglas want to use singletons, what's the problem? and what do you mean by abusing of singleton usage? of course singleton doesn't prevent concurrent access to the resource across the processes unless you're using some OS facility to prevent it, besides singleton as it was introduced is relevant only and only inside of the same process otherwise it's not singleton it's something else (let's say network singleton: so you have remote invocation facility and some factory method that return object created by that facility) I don't have any problem with using any kind of singletons. Parametric Singleton idea (if I understand it right) could be easily implemented in the following way: use a map populate map with instances of some class and key is your parameter (you can use lazy population too) if somebody ask the key check the value if it's null so resource is taken if somebody returns the resource put it back to the map public synchronized static Object getSomeResource(Object parameter); public synchronized static void returnResource(Object parameter); getSomeResource (inside of the same process) could return null in 2 cases 1. if somebody (from other thread for example) already took that resource 2. if OS API said that resource corresponded to that parameter (serial port with parameter = 1 (port #)) is locked and unavailable; I'm not sure that in case of serial ports we even need those Parametric Singletons (unless lock checking is a very expensive operation) just ask the OS about availability of that resource and if it's available give it away and then OS will lock it and therefore in next time somebody ask it just answer that resource is locked and return null for example system has 2 serial ports available so I ask getResource("tty"); or I ask getResource("Bluetooth-Modem"); and if OS is ok you can give tty or Bluetooth-Modem or both no need for any additional pattern I think back to the problem mac os x doesn't recognize locking via files, so it handles locking via some API an instance of the singleton in each process should recognize that resource is locked (by using that API) that's all we don't have to make things more complicate then they are just because there is some nice design pattern or nice unit test framework or whatever keep things simple, make them work fast, don't introduce middle layers unless you have really good reason to do so of course I could be entirely wrong, so sorry about that in advance thanks Dmitry Markman From tjarvi at qbang.org Wed Mar 22 22:31:41 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 22 Mar 2006 22:31:41 -0700 (MST) Subject: [Rxtx] sole of a new design pattern In-Reply-To: References: Message-ID: Hi Doug Interesting reading. So far I'm just reading and thinking. I have one question so far. " Clients obtain a reference to a Parametric Singleton instance only through the parametric singleton design pattern. If the instance is left in an improper state (e.g., the serial port was left open) it is NOT the role of the Parametric Singleton Design Pattern to close the IO port. Nor is it the role of the Parametric Singleton Design Pattern to open the port. That role is delegate to some other part of the system. " So when the clients obtain a reference to the singleton, can they assume the port is there? IE, would it be the singletons role to handle things like USB dongles being removed with event hints comming from the underlying OS. Hardware abstraction layer/HAL on Linux is an example of underlying OS events. I assume that role too is delegated to other parts of the system? -- Trent Jarvi tjarvi at qbang.org From lyon at docjava.com Thu Mar 23 08:10:33 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Thu, 23 Mar 2006 10:10:33 -0500 Subject: [Rxtx] Classes don't need goals, they need roles! In-Reply-To: References: Message-ID: Hi Trent, Yes, I think that the role of the Parametric Singleton Pattern is not to open or close serial ports, nor is it to perform error checking. On the other hand, if you were to combine the role of the Parametric Singleton Pattern with another role (like that of error checking) it might not be amiss. However, I generally caution programmers against adding multiple roles to classes, as this leads to monolithic designs. Thus a different class (NativeLibDetect) could have the role of determining if the native library can be loaded. Another class (SerialPortBean) can have the role of serializing the default state of the serial port, so that it can be recovered, from user preferences, at a later time. The SerialPortDetect could have the role of determining if the serial port is removed (i.e., a USB port was unplugged). My guess is that each class should have a different role in the system, in order to ease maintenance and testing...but I could be wrong about that. Thanks! - Doug >Hi Doug > >Interesting reading. So far I'm just reading and thinking. I have >one question so far. > >" > Clients obtain a reference to a Parametric Singleton instance only >through the parametric singleton design pattern. If the instance is >left in an improper state (e.g., the serial port was left open) it is >NOT the role of the Parametric Singleton Design Pattern to close the >IO port. Nor is it the role of the Parametric Singleton Design Pattern >to >open the port. That role is delegate to some other part of the system. >" > >So when the clients obtain a reference to the singleton, can they >assume the port is there? IE, would it be the singletons role to >handle things like USB dongles being removed with event hints >comming from the underlying OS. Hardware abstraction layer/HAL on >Linux is an example of underlying OS events. > >I assume that role too is delegated to other parts of the system? > >-- >Trent Jarvi >tjarvi at qbang.org >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From maximulo at yahoo.com Fri Mar 24 01:22:38 2006 From: maximulo at yahoo.com (Maximulo Majir) Date: Fri, 24 Mar 2006 00:22:38 -0800 (PST) Subject: [Rxtx] JavaPOS Message-ID: <20060324082238.66371.qmail@web38214.mail.mud.yahoo.com> Hi all! Hello Trent! From what i understand, RXTX or JavaComm APIs were not created solely for JavaPOS. In JavaPOS, we have the virtual method claim() which is separate from open(), but in our RXTX API, claiming is done every call to open(), we cant open the port if its claimed by another application. Would it be alright to suggest or ask to create a new method called claim(..)? Is there such thing as forceclaim() in RXTX? this could be the same as portownership transfer or its equivalent. ForceClaim is in JSR80. Do you have some samples using RXTX as the lower layer for the Device Service Objects in JavaPOS? I have tried it, i just want to compare. Thank you all! maxim __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060324/496adba2/attachment-0050.html From tjarvi at qbang.org Fri Mar 24 11:28:19 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 24 Mar 2006 11:28:19 -0700 (MST) Subject: [Rxtx] Re: RXTX 2.1 Solaris Problems In-Reply-To: <3691.1143210578@www045.gmx.net> References: <3691.1143210578@www045.gmx.net> Message-ID: On Fri, 24 Mar 2006, Andreas Guenther wrote: > Hi all, > > the solaris problem was not the lock file only. > > Ok, I had to create the directory /var/spool/locks myself. > /var/spool/uucp exists. > > But rxtx didn't find any port. > > I compiled the source with my own debug-informations > and I tried to isolate the problem. > > The problem is the testRead-call in SerialImp.c > > JNIEXPORT jboolean JNICALL RXTXCommDriver(testRead)( > > ... > if ( READ( fd, &c, 1 ) < 0 ) > { > if ( errno != EAGAIN ) { > report( "testRead() read failed\n" ); > ret = JNI_FALSE; > } > } > Thanks Andreas I'm packing up to move. I'll be more or less away for a couple weeks here. I'll be checking email but my workstation is going into a box soon. This isn't hard to fix as this port should be enumerated when EWOULDBLOCK is recieved. Thats error is OK for enumeration just as EAGAIN is. I've put the bug into bugzilla so we dont forget to get to it. http://bugzilla.qbang.org/show_bug.cgi?id=42 You can add yourself to the CC list if you wish to test fixes we provide or even put a patch into bugzilla yourself. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Fri Mar 24 11:51:52 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 24 Mar 2006 11:51:52 -0700 (MST) Subject: [Rxtx] JavaPOS In-Reply-To: <20060324082238.66371.qmail@web38214.mail.mud.yahoo.com> References: <20060324082238.66371.qmail@web38214.mail.mud.yahoo.com> Message-ID: On Fri, 24 Mar 2006, Maximulo Majir wrote: > Hi all! Hello Trent! > > > From what i understand, RXTX or JavaComm APIs were not > created solely for JavaPOS. In JavaPOS, we have the virtual method > claim() which is separate from open(), but in our RXTX API, claiming is > done every call to open(), we cant open the port if its claimed by > another application. Would it be alright to suggest or ask to create a > new method called claim(..)? Is there such thing as forceclaim() in > RXTX? this could be the same as portownership transfer or its > equivalent. ForceClaim is in JSR80. > Do you have some samples using RXTX as the lower layer for the Device > Service Objects in JavaPOS? I have tried it, i just want to compare. > maxim Hi Maxim JSR80 is the USB API IBM/Sun put together. The problem is they have a richer kernel/API underneath that can handle such things. With Serial Ports, there isnt anything there other than an ioctl that says don't let anyone touch this and lockfiles that are more of a 'lets be nice.' At times we may be using USB ports but it is through the termios layer with the limitations mentioned. The advantage is that not only USB will work with rxtx. Anything that has a termios layer should work (to the extent that termios layer is complete). I don't know how forceclaim() would help you. Lets say someone has a programmer working on /dev/ttyS0 and you take it. Now you both race each other to read data first. There isn't a mechanism I know of that will solve this problem in termios. The most obvious test being a native app and a Java app trying to take the port. There is the potential of requestion ownership from other Java Applications but the use for that is very rare. Did you have something more specific in mind that I'm missing? I'm not sure that claim() and forceclaim() would help you with rxtx other than maybe locking the port with claim() without opening it. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sat Mar 25 23:42:08 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 25 Mar 2006 23:42:08 -0700 (MST) Subject: [Rxtx] Serial snoop Message-ID: I was reading the Linux kernel mail-list tonight and ran past a thread that mentioned sersnoop. This looks like a handy tool for people dealing with new toys. "a simple command-line tool for linux that echoes bytes to and from any two serial ports, ptys, or network sockets, and prints all traffic to stdout, in hex and ascii." http://www.restivo.org/projects/sersnoop/ It works on Linux only at this time (debian package available). -- Trent Jarvi tjarvi at qbang.org From beat.arnet at gmail.com Sun Mar 26 07:32:35 2006 From: beat.arnet at gmail.com (Beat Arnet) Date: Sun, 26 Mar 2006 09:32:35 -0500 Subject: [Rxtx] Error 0x5 at /home/bob/foo/tar/rxtx-2.1-7/build/../src/termios.c(860): Access is, denied. Message-ID: <4426A603.80508@gmail.com> Dear all, When trying to open the serial port, I sometimes (not always) run into the following exception (when opening the serialPort): Error 0x5 at /home/bob/foo/tar/rxtx-2.1-7/build/../src/termios.c(860): Access is denied. java.lang.UnsatisfiedLinkError: native_psmisc_report_owner at gnu.io.CommPortIdentifier.native_psmisc_report_owner(Native Method) at gnu.io.CommPortIdentifier.open(CommPortIdentifier.java:354) at codeskin.tools.CLLoader.open(CLLoader.java:79) at codeskin.tools.C2000Programmer.run(C2000Programmer.java:220) at java.lang.Thread.run(Unknown Source) Is this the type of error where I should just try to open the port again, or can it be avoided? Regards, Beat From tjarvi at qbang.org Sun Mar 26 11:40:12 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 26 Mar 2006 11:40:12 -0700 (MST) Subject: [Rxtx] Error 0x5 at /home/bob/foo/tar/rxtx-2.1-7/build/../src/termios.c(860): Access is, denied. In-Reply-To: <4426A603.80508@gmail.com> References: <4426A603.80508@gmail.com> Message-ID: On Sun, 26 Mar 2006, Beat Arnet wrote: > Dear all, > > When trying to open the serial port, I sometimes (not always) run into > the following exception (when opening the serialPort): > > Error 0x5 at /home/bob/foo/tar/rxtx-2.1-7/build/../src/termios.c(860): > Access is > denied. > > java.lang.UnsatisfiedLinkError: native_psmisc_report_owner > at gnu.io.CommPortIdentifier.native_psmisc_report_owner(Native > Method) > at gnu.io.CommPortIdentifier.open(CommPortIdentifier.java:354) > at codeskin.tools.CLLoader.open(CLLoader.java:79) > at codeskin.tools.C2000Programmer.run(C2000Programmer.java:220) > at java.lang.Thread.run(Unknown Source) > > Is this the type of error where I should just try to open the port again, > or can it be avoided? > Hi Beat We did a second build of rxtx 2.1-7 to resolve that unsatisfied link error. It should work now. rxtx is trying to tell you it thinks someone else has the serial port open. You can try to open the port again but maybe you already have a copy of the program running when it happens? ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7r2.zip fixed build. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sun Mar 26 11:44:23 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 26 Mar 2006 11:44:23 -0700 (MST) Subject: [Rxtx] RXTX spec file (fwd) Message-ID: This is probably interesting for fedora/suse users. ---------- Forwarded message ---------- Date: Sun, 26 Mar 2006 16:25:45 +0200 To: taj at www.linux.org.uk Subject: RXTX spec file I send you this spec file which allows to create a RPM for Fedora 4, 5 (x86, x86_64) with Java Sun. -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: rxtx.spec Url: http://mailman.qbang.org/pipermail/rxtx/attachments/20060326/6c7b6af6/rxtx-0046.pl From tjarvi at qbang.org Sun Mar 26 23:42:59 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 26 Mar 2006 23:42:59 -0700 (MST) Subject: [Rxtx] Upcomming events. Message-ID: This Wednesday we will be announcing a new "Maintainer" for the rxtx project. The position is more like neutral leader. I wont be going away or doing less. This is just the right thing to do as it turns out the two people with CVS write access will be at the same company. We need a third and we need neutrality. The maintainer will have final say in any conflict and will try to be neutral. It will be open for discussion. Then we will do it :) I'll still do most of the footwork I do now. But. I'm falling behind. I should have gone through the mail-list and posted the next round of changes this weekend. I'm packing to move and its going so so - 13 years of toys collected. I suspect there will be a dead period on my part (a couple weeks) comming up. But if you get it on the mail-list, we will get it in if there are no objections. I may well not be reading the mail-list during this period as I look for a house and many other things. I hope everyone will help out. Thanks -- Trent Jarvi tjarvi at qbang.org From mahmoud_hadad at yahoo.com Sun Mar 26 07:31:19 2006 From: mahmoud_hadad at yahoo.com (ronan nick) Date: Sun, 26 Mar 2006 06:31:19 -0800 (PST) Subject: [Rxtx] a question about the COMM API Message-ID: <20060326143119.54919.qmail@web60014.mail.yahoo.com> hi, i was intrested in knowing how i can communicate with my internal modem using java? for example if i want to make a phone dialer application or a caller id application where should i be looking at? and as i understood the COMM API is for devices that is attached to the computer through serial ports. --------------------------------- New Yahoo! Messenger with Voice. Call regular phones from your PC and save big. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060326/ce8329f0/attachment-0048.html From dmarkman at mac.com Mon Mar 20 00:20:43 2006 From: dmarkman at mac.com (Dmitry Markman) Date: Mon, 20 Mar 2006 02:20:43 -0500 Subject: [Rxtx] Mac OS X RXTX java installer In-Reply-To: References: <07D0DE29-BA32-4CFE-B036-66BC6423D385@buechse.de> <441AE3E0.2030503@willicon.de> <12531986.1142622114996.JavaMail.dmarkman@mac.com> <441B2674.9010409@willicon.de> <13577405.1142634732776.JavaMail.dmarkman@mac.com> <441B4182.8010407@willicon.de> <92CD0D6C-5BE8-426E-A46D-99452059FF49@mac.com> <441BBB2D.8030305@willicon.de> <441C4088.5090905@willicon.de> Message-ID: <64BC1E23-FDDE-4CE6-8863-CFC881CBC224@mac.com> Hi all I put RXTX installer that will install everything (and will create / var/lock if necessary and add user to the uucp group) for mac os x from Java into the rxtx's CVS repository it could be easily modified to install files for any platform it uses Greg Guerin's AuthKit for authentication and authorization Greg released that kit under artistic license, so Trent, please take a look we, probably, can negotiate license with Greg if it's necessary Greg's AuthKit could be downloaded from http://www.amug.org/~glguerin/ sw/#authkit Michael Hall (mikehall at spacestar dot net) had a suggestion to make implementation of the jaas LoginModule based on Greg's AuthKit (his modification of the Greg's AuthKit could be found at http:// www.spacestar.net/users/mikehall/authkit.dmg) but Michael's AuthKitLoginModule does only half a job: it does authenticate but it can not run any external unix process in privileged mode (at least I wasn't able to do so) possible explanation could be found in conversation between Greg and Michael at Apple's java-dev list (look for archives) so I didn't use jaas API for rxtxinstaller I created folder MacOSX in the contrib folder comment 1. if you want to run that installer as standalone application all you need that RXTXInstaller.jar 2. if you want to use webstart you have to add Greg's libAuthKit.jnilib to the mac os x's resources in theory RXTXInstaller.jar doesn't need it, but there is a problem with loading libAuthKit.jnilib from webstart authkit uses loadLibrary method to load library and it failed (from webstart) for standalone application I extract libAuthKit.jnilib from the RXTXInstaller.jar and put it into the /Library/Java/Extensions or ~/Library/Java/Extensions folder that file will be deleted after installer quit unfortunately I didn't have time to put documentation there but it is mostly self-explanatory I took installer code from my gl4java installer that I did about 3 years ago (with small modifications) it would be very nice if Apple will release LoginModule that really will do the job (com.apple.security.auth.module package????? ) (UnixLoginModule is pretty useless) From lyon at docjava.com Mon Mar 20 06:34:39 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Mon, 20 Mar 2006 08:34:39 -0500 Subject: [Rxtx] Mac OS X RXTX java installer In-Reply-To: <64BC1E23-FDDE-4CE6-8863-CFC881CBC224@mac.com> References: <07D0DE29-BA32-4CFE-B036-66BC6423D385@buechse.de> <441AE3E0.2030503@willicon.de> <12531986.1142622114996.JavaMail.dmarkman@mac.com> <441B2674.9010409@willicon.de> <13577405.1142634732776.JavaMail.dmarkman@mac.com> <441B4182.8010407@willicon.de> <92CD0D6C-5BE8-426E-A46D-99452059FF49@mac.com> <441BBB2D.8030305@willicon.de> <441C4088.5090905@willicon.de> <64BC1E23-FDDE-4CE6-8863-CFC881CBC224@mac.com> Message-ID: Hi Dimitry, This sounds like great work. Just a couple of questions; After the check out of the CVS files, using: setenv CVSROOT :pserver:anonymous at cvs.milestonesolutions.com:/usr/local/cvsroot 53 8:28 setenv PASSWORD mousy 54 8:29 cvs login 55 8:29 cvs checkout rxtx-devel I cd'd over to: rxtx-devel/MACOSX_IDE And found: CVS/ CW/ ForPackageMaker/ PB/ Where is the installer? Thanks! - Doug From tjarvi at qbang.org Mon Mar 20 06:39:37 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 20 Mar 2006 06:39:37 -0700 (MST) Subject: [Rxtx] Mac OS X RXTX java installer In-Reply-To: References: <07D0DE29-BA32-4CFE-B036-66BC6423D385@buechse.de> <441AE3E0.2030503@willicon.de> <12531986.1142622114996.JavaMail.dmarkman@mac.com> <441B2674.9010409@willicon.de> <13577405.1142634732776.JavaMail.dmarkman@mac.com> <441B4182.8010407@willicon.de> <92CD0D6C-5BE8-426E-A46D-99452059FF49@mac.com> <441BBB2D.8030305@willicon.de> <441C4088.5090905@willicon.de> <64BC1E23-FDDE-4CE6-8863-CFC881CBC224@mac.com> Message-ID: On Mon, 20 Mar 2006, Dr. Douglas Lyon wrote: > Hi Dimitry, > This sounds like great work. Just a couple of questions; > After the check out of the CVS files, using: > setenv CVSROOT > :pserver:anonymous at cvs.milestonesolutions.com:/usr/local/cvsroot > 53 8:28 setenv PASSWORD mousy > 54 8:29 cvs login > 55 8:29 cvs checkout rxtx-devel Hi Doug You want "cvs checkout -r commapi-0-0-1 rxtx-devel" to get RXTX 2.1 The default branch is rxtx 2.0 which isn't very active right now. -- Trent Jarvi tjarvi at qbang.org From lyon at docjava.com Mon Mar 20 07:05:44 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Mon, 20 Mar 2006 09:05:44 -0500 Subject: [Rxtx] Mac OS X RXTX java installer In-Reply-To: References: <07D0DE29-BA32-4CFE-B036-66BC6423D385@buechse.de> <441AE3E0.2030503@willicon.de> <12531986.1142622114996.JavaMail.dmarkman@mac.com> <441B2674.9010409@willicon.de> <13577405.1142634732776.JavaMail.dmarkman@mac.com> <441B4182.8010407@willicon.de> <92CD0D6C-5BE8-426E-A46D-99452059FF49@mac.com> <441BBB2D.8030305@willicon.de> <441C4088.5090905@willicon.de> <64BC1E23-FDDE-4CE6-8863-CFC881CBC224@mac.com> Message-ID: Hi Trent, Thanks for the info on the CVS checkout procedure. I did that and am still not sure where the installer is. Here is what I have: cd MACOSX_IDE/ p4.docjava.com{lyon}121: ls CVS/ ForPackageMaker/ PB/ p4.docjava.com{lyon}122: find . | more . ./ForPackageMaker ./ForPackageMaker/RXTX.pkg.sit.hqx ./ForPackageMaker/Resources ./ForPackageMaker/Resources/ReadMe.rtf ./ForPackageMaker/Resources/Welcome.rtf ./ForPackageMaker/Resources/CVS ./ForPackageMaker/Resources/CVS/Entries ./ForPackageMaker/Resources/CVS/Repository ./ForPackageMaker/Resources/CVS/Tag ./ForPackageMaker/Resources/CVS/Root ./ForPackageMaker/Resources/preinstall ./ForPackageMaker/Resources/License.rtf ./ForPackageMaker/Resources/preupgrade ./ForPackageMaker/RXTX.pmsp ./ForPackageMaker/CVS ./ForPackageMaker/CVS/Entries ./ForPackageMaker/CVS/Repository ./ForPackageMaker/CVS/Entries.Log ./ForPackageMaker/CVS/Tag ./ForPackageMaker/CVS/Root ./ForPackageMaker/RXTX_Tiger.pkg.sitx.hqx ./ForPackageMaker/RXTX_Jag.pkg.sit.hqx ./ForPackageMaker/Install ./ForPackageMaker/Install/CVS ./ForPackageMaker/Install/CVS/Entries ./ForPackageMaker/Install/CVS/Repository ./ForPackageMaker/Install/CVS/Tag ./ForPackageMaker/Install/CVS/Root ./ForPackageMaker/Install/Library ./ForPackageMaker/Install/Library/CVS ./ForPackageMaker/Install/Library/CVS/Entries ./ForPackageMaker/Install/Library/CVS/Repository ./ForPackageMaker/Install/Library/CVS/Tag ./ForPackageMaker/Install/Library/CVS/Root ./ForPackageMaker/Install/Library/Java ./ForPackageMaker/Install/Library/Java/Extensions ./ForPackageMaker/Install/Library/Java/Extensions/RXTXcomm.jar ./ForPackageMaker/Install/Library/Java/Extensions/CVS ./ForPackageMaker/Install/Library/Java/Extensions/CVS/Entries ./ForPackageMaker/Install/Library/Java/Extensions/CVS/Repository ./ForPackageMaker/Install/Library/Java/Extensions/CVS/Tag ./ForPackageMaker/Install/Library/Java/Extensions/CVS/Root ./ForPackageMaker/Install/Library/Java/Extensions/librxtxSerial.jnilib ./ForPackageMaker/Install/Library/Java/CVS ./ForPackageMaker/Install/Library/Java/CVS/Entries ./ForPackageMaker/Install/Library/Java/CVS/Repository ./ForPackageMaker/Install/Library/Java/CVS/Entries.Log ./ForPackageMaker/Install/Library/Java/CVS/Tag ./ForPackageMaker/Install/Library/Java/CVS/Root ./ForPackageMaker/RXTX_Tiger.pmproj.sitx.hqx ./CVS ./CVS/Entries ./CVS/Repository ./CVS/Entries.Log ./CVS/Tag ./CVS/Root ./PB ./PB/LibSerialUniversal.xcodeproj.sitx.hqx ./PB/CVS ./PB/CVS/Entries ./PB/CVS/Repository ./PB/CVS/Entries.Log ./PB/CVS/Tag ./PB/CVS/Root ./PB/LibSerial.pbproj.sit.hqx ./PB/startpoint.c ./PB/config.h What is the procedure to run this installer? Do we need a README in: /rxtx-devel/MACOSX_IDE Here is what we have: CVS/ ForPackageMaker/ PB/ Thanks! - DL >On Mon, 20 Mar 2006, Dr. Douglas Lyon wrote: > >>Hi Dimitry, >>This sounds like great work. Just a couple of questions; >>After the check out of the CVS files, using: >>setenv CVSROOT >>:pserver:anonymous at cvs.milestonesolutions.com:/usr/local/cvsroot >> 53 8:28 setenv PASSWORD mousy >> 54 8:29 cvs login >> 55 8:29 cvs checkout rxtx-devel > >Hi Doug > >You want "cvs checkout -r commapi-0-0-1 rxtx-devel" to get RXTX 2.1 >The default branch is rxtx 2.0 which isn't very active right now. > >-- >Trent Jarvi >tjarvi at qbang.org From tjarvi at qbang.org Mon Mar 20 07:25:30 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 20 Mar 2006 07:25:30 -0700 (MST) Subject: [Rxtx] Mac OS X RXTX java installer In-Reply-To: References: <07D0DE29-BA32-4CFE-B036-66BC6423D385@buechse.de> <441AE3E0.2030503@willicon.de> <12531986.1142622114996.JavaMail.dmarkman@mac.com> <441B2674.9010409@willicon.de> <13577405.1142634732776.JavaMail.dmarkman@mac.com> <441B4182.8010407@willicon.de> <92CD0D6C-5BE8-426E-A46D-99452059FF49@mac.com> <441BBB2D.8030305@willicon.de> <441C4088.5090905@willicon.de> <64BC1E23-FDDE-4CE6-8863-CFC881CBC224@mac.com> Message-ID: On Mon, 20 Mar 2006, Dr. Douglas Lyon wrote: > Hi Trent, > Thanks for the info on the CVS checkout procedure. > I did that and am still not sure where the installer is. Hi Doug It does look like it was not cvs committed. There is no rxtx-devel/contrib/MacOSX directory in there at the moment. It was mentioned that it was put under contrib. -- Trent Jarvi tjarvi at qbang.org From dmarkman at mac.com Mon Mar 20 07:29:56 2006 From: dmarkman at mac.com (Dmitry Markman) Date: Mon, 20 Mar 2006 09:29:56 -0500 Subject: [Rxtx] Mac OS X RXTX java installer In-Reply-To: References: <07D0DE29-BA32-4CFE-B036-66BC6423D385@buechse.de> <441AE3E0.2030503@willicon.de> <12531986.1142622114996.JavaMail.dmarkman@mac.com> <441B2674.9010409@willicon.de> <13577405.1142634732776.JavaMail.dmarkman@mac.com> <441B4182.8010407@willicon.de> <92CD0D6C-5BE8-426E-A46D-99452059FF49@mac.com> <441BBB2D.8030305@willicon.de> <441C4088.5090905@willicon.de> <64BC1E23-FDDE-4CE6-8863-CFC881CBC224@mac.com> Message-ID: <6054EB4E-F7E0-4A9C-BDDA-D582D6D8826F@mac.com> you can find it in the rxtx-devel/contrib folder On Mar 20, 2006, at 9:05 AM, Dr. Douglas Lyon wrote: > Hi Trent, > Thanks for the info on the CVS checkout procedure. > I did that and am still not sure where the installer is. > Here is what I have: > cd MACOSX_IDE/ > p4.docjava.com{lyon}121: ls > CVS/ ForPackageMaker/ PB/ > p4.docjava.com{lyon}122: find . | more > . > ./ForPackageMaker > ./ForPackageMaker/RXTX.pkg.sit.hqx > ./ForPackageMaker/Resources > ./ForPackageMaker/Resources/ReadMe.rtf > ./ForPackageMaker/Resources/Welcome.rtf > ./ForPackageMaker/Resources/CVS > ./ForPackageMaker/Resources/CVS/Entries > ./ForPackageMaker/Resources/CVS/Repository > ./ForPackageMaker/Resources/CVS/Tag > ./ForPackageMaker/Resources/CVS/Root > ./ForPackageMaker/Resources/preinstall > ./ForPackageMaker/Resources/License.rtf > ./ForPackageMaker/Resources/preupgrade > ./ForPackageMaker/RXTX.pmsp > ./ForPackageMaker/CVS > ./ForPackageMaker/CVS/Entries > ./ForPackageMaker/CVS/Repository > ./ForPackageMaker/CVS/Entries.Log > ./ForPackageMaker/CVS/Tag > ./ForPackageMaker/CVS/Root > ./ForPackageMaker/RXTX_Tiger.pkg.sitx.hqx > ./ForPackageMaker/RXTX_Jag.pkg.sit.hqx > ./ForPackageMaker/Install > ./ForPackageMaker/Install/CVS > ./ForPackageMaker/Install/CVS/Entries > ./ForPackageMaker/Install/CVS/Repository > ./ForPackageMaker/Install/CVS/Tag > ./ForPackageMaker/Install/CVS/Root > ./ForPackageMaker/Install/Library > ./ForPackageMaker/Install/Library/CVS > ./ForPackageMaker/Install/Library/CVS/Entries > ./ForPackageMaker/Install/Library/CVS/Repository > ./ForPackageMaker/Install/Library/CVS/Tag > ./ForPackageMaker/Install/Library/CVS/Root > ./ForPackageMaker/Install/Library/Java > ./ForPackageMaker/Install/Library/Java/Extensions > ./ForPackageMaker/Install/Library/Java/Extensions/RXTXcomm.jar > ./ForPackageMaker/Install/Library/Java/Extensions/CVS > ./ForPackageMaker/Install/Library/Java/Extensions/CVS/Entries > ./ForPackageMaker/Install/Library/Java/Extensions/CVS/Repository > ./ForPackageMaker/Install/Library/Java/Extensions/CVS/Tag > ./ForPackageMaker/Install/Library/Java/Extensions/CVS/Root > ./ForPackageMaker/Install/Library/Java/Extensions/librxtxSerial.jnilib > ./ForPackageMaker/Install/Library/Java/CVS > ./ForPackageMaker/Install/Library/Java/CVS/Entries > ./ForPackageMaker/Install/Library/Java/CVS/Repository > ./ForPackageMaker/Install/Library/Java/CVS/Entries.Log > ./ForPackageMaker/Install/Library/Java/CVS/Tag > ./ForPackageMaker/Install/Library/Java/CVS/Root > ./ForPackageMaker/RXTX_Tiger.pmproj.sitx.hqx > ./CVS > ./CVS/Entries > ./CVS/Repository > ./CVS/Entries.Log > ./CVS/Tag > ./CVS/Root > ./PB > ./PB/LibSerialUniversal.xcodeproj.sitx.hqx > ./PB/CVS > ./PB/CVS/Entries > ./PB/CVS/Repository > ./PB/CVS/Entries.Log > ./PB/CVS/Tag > ./PB/CVS/Root > ./PB/LibSerial.pbproj.sit.hqx > ./PB/startpoint.c > ./PB/config.h > > What is the procedure to run this installer? > Do we need a README in: > /rxtx-devel/MACOSX_IDE > Here is what we have: > CVS/ ForPackageMaker/ PB/ > > > Thanks! > - DL > >> On Mon, 20 Mar 2006, Dr. Douglas Lyon wrote: >> >>> Hi Dimitry, >>> This sounds like great work. Just a couple of questions; >>> After the check out of the CVS files, using: >>> setenv CVSROOT :pserver:anonymous at cvs.milestonesolutions.com:/usr/ >>> local/cvsroot >>> 53 8:28 setenv PASSWORD mousy >>> 54 8:29 cvs login >>> 55 8:29 cvs checkout rxtx-devel >> >> Hi Doug >> >> You want "cvs checkout -r commapi-0-0-1 rxtx-devel" to get RXTX 2.1 >> The default branch is rxtx 2.0 which isn't very active right now. >> >> -- >> Trent Jarvi >> tjarvi at qbang.org > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx Dmitry Markman From mikehall at spacestar.net Mon Mar 20 05:25:25 2006 From: mikehall at spacestar.net (Michael Hall) Date: Mon, 20 Mar 2006 06:25:25 -0600 Subject: [Rxtx] Re: Mac OS X RXTX java installer In-Reply-To: <64BC1E23-FDDE-4CE6-8863-CFC881CBC224@mac.com> References: <07D0DE29-BA32-4CFE-B036-66BC6423D385@buechse.de> <441AE3E0.2030503@willicon.de> <12531986.1142622114996.JavaMail.dmarkman@mac.com> <441B2674.9010409@willicon.de> <13577405.1142634732776.JavaMail.dmarkman@mac.com> <441B4182.8010407@willicon.de> <92CD0D6C-5BE8-426E-A46D-99452059FF49@mac.com> <441BBB2D.8030305@willicon.de> <441C4088.5090905@willicon.de> <64BC1E23-FDDE-4CE6-8863-CFC881CBC224@mac.com> Message-ID: <247EB61F-5CD1-4132-89A2-FC105B6CF9A5@spacestar.net> On Mar 20, 2006, at 1:20 AM, Dmitry Markman wrote: > > Michael Hall (mikehall at spacestar dot net) had a suggestion to > make implementation of the jaas LoginModule > based on Greg's AuthKit > (his modification of the Greg's AuthKit could be found at http:// > www.spacestar.net/users/mikehall/authkit.dmg) > but Michael's AuthKitLoginModule does only half a job: > it does authenticate > but it can not run any external unix process in privileged mode (at > least I wasn't able to do so) If you got it working directly with Greg's the point is moot. But to clarify it anyhow. The login module does not allow you to do anything anything privileged on return as was explained by Greg. You need to work with a separate privileged process using the execPrivileged method of his API. I assume you did something similar although I haven't looked at how you are using it yet. I allowed instead for a action to be performed at the same time you login/authenticate,this... System.setProperty("authkit.action","/usr/bin/id"); just before this... lc.login(); To clarify, safely ignored as you are already complete. Mike Hall mikehall at spacestar dot net http://www.spacestar.net/users/mikehall http://sourceforge.net/projects/macnative -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2427 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20060320/f6e18202/smime-0051.bin From dmarkman at mac.com Mon Mar 20 07:36:47 2006 From: dmarkman at mac.com (Dmitry Markman) Date: Mon, 20 Mar 2006 09:36:47 -0500 Subject: [Rxtx] Re: Mac OS X RXTX java installer In-Reply-To: <247EB61F-5CD1-4132-89A2-FC105B6CF9A5@spacestar.net> References: <07D0DE29-BA32-4CFE-B036-66BC6423D385@buechse.de> <441AE3E0.2030503@willicon.de> <12531986.1142622114996.JavaMail.dmarkman@mac.com> <441B2674.9010409@willicon.de> <13577405.1142634732776.JavaMail.dmarkman@mac.com> <441B4182.8010407@willicon.de> <92CD0D6C-5BE8-426E-A46D-99452059FF49@mac.com> <441BBB2D.8030305@willicon.de> <441C4088.5090905@willicon.de> <64BC1E23-FDDE-4CE6-8863-CFC881CBC224@mac.com> <247EB61F-5CD1-4132-89A2-FC105B6CF9A5@spacestar.net> Message-ID: Hi, Michael all I have to do is to run some shell script I tried to use your action mechanism and it worked great so I just System.setProperty ("authkit.action","" ) and after that I even don't need to run anything like subject.doAs.... but after few thoughts I choose to use plain Greg's approach, because in that case I don't have to deal with various java's configurations files and therefore to use 2-3 -D parameters in the java command line especially it's useful for java web start (it's so fragile :-( ) thanks for the great job On Mar 20, 2006, at 7:25 AM, Michael Hall wrote: > > On Mar 20, 2006, at 1:20 AM, Dmitry Markman wrote: >> >> Michael Hall (mikehall at spacestar dot net) had a suggestion to >> make implementation of the jaas LoginModule >> based on Greg's AuthKit >> (his modification of the Greg's AuthKit could be found at http:// >> www.spacestar.net/users/mikehall/authkit.dmg) >> but Michael's AuthKitLoginModule does only half a job: >> it does authenticate >> but it can not run any external unix process in privileged mode >> (at least I wasn't able to do so) > > If you got it working directly with Greg's the point is moot. > > But to clarify it anyhow. > The login module does not allow you to do anything anything > privileged on return as was explained by Greg. You need to work > with a separate privileged process using the execPrivileged method > of his API. I assume you did something similar although I haven't > looked at how you are using it yet. > I allowed instead for a action to be performed at the same time you > login/authenticate,this... > System.setProperty("authkit.action","/usr/bin/id"); > just before this... > lc.login(); > To clarify, safely ignored as you are already complete. > > Mike Hall mikehall at spacestar dot net > http://www.spacestar.net/users/mikehall > http://sourceforge.net/projects/macnative > > > Dmitry Markman From dmarkman at mac.com Mon Mar 20 07:44:45 2006 From: dmarkman at mac.com (Dmitry Markman) Date: Mon, 20 Mar 2006 09:44:45 -0500 Subject: [Rxtx] Mac OS X RXTX java installer In-Reply-To: References: <07D0DE29-BA32-4CFE-B036-66BC6423D385@buechse.de> <441AE3E0.2030503@willicon.de> <12531986.1142622114996.JavaMail.dmarkman@mac.com> <441B2674.9010409@willicon.de> <13577405.1142634732776.JavaMail.dmarkman@mac.com> <441B4182.8010407@willicon.de> <92CD0D6C-5BE8-426E-A46D-99452059FF49@mac.com> <441BBB2D.8030305@willicon.de> <441C4088.5090905@willicon.de> <64BC1E23-FDDE-4CE6-8863-CFC881CBC224@mac.com> Message-ID: it's in the commapi-0-0-1 branch I tested it right now: cvs co -r commapi-0-0-1 rxtx-devel and I got everything On Mar 20, 2006, at 9:25 AM, Trent Jarvi wrote: > On Mon, 20 Mar 2006, Dr. Douglas Lyon wrote: > >> Hi Trent, >> Thanks for the info on the CVS checkout procedure. >> I did that and am still not sure where the installer is. > > Hi Doug > > It does look like it was not cvs committed. There is no rxtx-devel/ > contrib/MacOSX directory in there at the moment. It was mentioned > that it was put under contrib. > > -- > Trent Jarvi > tjarvi at qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx Dmitry Markman From tjarvi at qbang.org Mon Mar 20 07:52:57 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 20 Mar 2006 07:52:57 -0700 (MST) Subject: [Rxtx] Mac OS X RXTX java installer In-Reply-To: References: <07D0DE29-BA32-4CFE-B036-66BC6423D385@buechse.de> <441AE3E0.2030503@willicon.de> <12531986.1142622114996.JavaMail.dmarkman@mac.com> <441B2674.9010409@willicon.de> <13577405.1142634732776.JavaMail.dmarkman@mac.com> <441B4182.8010407@willicon.de> <92CD0D6C-5BE8-426E-A46D-99452059FF49@mac.com> <441BBB2D.8030305@willicon.de> <441C4088.5090905@willicon.de> <64BC1E23-FDDE-4CE6-8863-CFC881CBC224@mac.com> Message-ID: On Mon, 20 Mar 2006, Dmitry Markman wrote: > it's in the commapi-0-0-1 branch > > I tested it right now: > cvs co -r commapi-0-0-1 rxtx-devel > > and I got everything > A fresh checkout worked. Here is a copy of the tree (just the installer bits) ftp://ftp.qbang.org/pub/rxtx/MacOSX-installer.zip -- Trent Jarvi tjarvi at qbang.org From lyon at docjava.com Mon Mar 20 08:08:26 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Mon, 20 Mar 2006 10:08:26 -0500 Subject: [Rxtx] Mac OS X RXTX java installer In-Reply-To: References: <07D0DE29-BA32-4CFE-B036-66BC6423D385@buechse.de> <441AE3E0.2030503@willicon.de> <12531986.1142622114996.JavaMail.dmarkman@mac.com> <441B2674.9010409@willicon.de> <13577405.1142634732776.JavaMail.dmarkman@mac.com> <441B4182.8010407@willicon.de> <92CD0D6C-5BE8-426E-A46D-99452059FF49@mac.com> <441BBB2D.8030305@willicon.de> <441C4088.5090905@willicon.de> <64BC1E23-FDDE-4CE6-8863-CFC881CBC224@mac.com> Message-ID: Hi All, Is the Auth package able to work properly on non Mac OS's? It was not clear from the doc or download. Thanks! - Doug From dmarkman at mac.com Mon Mar 20 08:15:22 2006 From: dmarkman at mac.com (Dmitry Markman) Date: Mon, 20 Mar 2006 10:15:22 -0500 Subject: [Rxtx] Mac OS X RXTX java installer In-Reply-To: References: <07D0DE29-BA32-4CFE-B036-66BC6423D385@buechse.de> <441AE3E0.2030503@willicon.de> <12531986.1142622114996.JavaMail.dmarkman@mac.com> <441B2674.9010409@willicon.de> <13577405.1142634732776.JavaMail.dmarkman@mac.com> <441B4182.8010407@willicon.de> <92CD0D6C-5BE8-426E-A46D-99452059FF49@mac.com> <441BBB2D.8030305@willicon.de> <441C4088.5090905@willicon.de> <64BC1E23-FDDE-4CE6-8863-CFC881CBC224@mac.com> Message-ID: <217312D8-CCCA-4859-ABA6-32DF1CC817B9@mac.com> thanks Trent, for putting it on ftp server On Mar 20, 2006, at 9:52 AM, Trent Jarvi wrote: > A fresh checkout worked. Here is a copy of the tree (just the > installer bits) > > ftp://ftp.qbang.org/pub/rxtx/MacOSX-installer.zip > Dmitry Markman From dmarkman at mac.com Mon Mar 20 09:14:03 2006 From: dmarkman at mac.com (Dmitry Markman) Date: Mon, 20 Mar 2006 11:14:03 -0500 Subject: [Rxtx] Mac OS X RXTX java installer In-Reply-To: References: <07D0DE29-BA32-4CFE-B036-66BC6423D385@buechse.de> <441AE3E0.2030503@willicon.de> <12531986.1142622114996.JavaMail.dmarkman@mac.com> <441B2674.9010409@willicon.de> <13577405.1142634732776.JavaMail.dmarkman@mac.com> <441B4182.8010407@willicon.de> <92CD0D6C-5BE8-426E-A46D-99452059FF49@mac.com> <441BBB2D.8030305@willicon.de> <441C4088.5090905@willicon.de> <64BC1E23-FDDE-4CE6-8863-CFC881CBC224@mac.com> Message-ID: <4DEBA6F0-DA45-4E84-823E-1F1AC48BDCCC@mac.com> no it will work only on mac os x however it's harmless to run it on other platform if you want to use it for other platform you have to do the following (I'll do it for linux) 1. modify RXTXInstaller class method public static RXTXInstaller getInstance() public static RXTXInstaller getInstance() { String osName = System.getProperty("os.name").toLowerCase(); if(osName.startsWith("mac")){ return new gnu.io.installer.macosx.MACOSXRXTXInstaller(); } else if(osName.startsWith("windows")){ return new gnu.io.installer.windows.WindowsRXTXInstaller(); }else if(osName.startsWith("linux")){ return new gnu.io.installer.linux.LinuxRXTXInstaller(); } return null; } 2. create folder gnu/io/installer/linux/ 3. create class Linux386RXTXInstaller package gnu.io.installer.linux; import java.io.File; public class Linux386RXTXInstaller extends gnu.io.installer.RXTXInstaller{ public Linux386RXTXInstaller(){ createJarFolder(); createLibFolder(); addJarResource("RXTXcomm.jar","/gnu/io/installer/resources/ linux/jar/RXTXcomm.dat"); addLibResource("librxtxSerial.so","/gnu/io/installer/ resources/linux/lib/librxtxSerial.so"); } protected void createJarFolder(){ String javaHome = System.getProperty("java.home"); char separator = File.separatorChar; jarFolder = new File(javaHome+separator+"lib"+separator+"ext"); } protected void createLibFolder(){ String javaHome = System.getProperty("java.home"); char separator = File.separatorChar; libFolder = new File(javaHome+separator+"bin"); } public void runPreProcess() {} //put here some action you need public void runPostProcess() {} //put here some action you need } 4. create folder /gnu/io/installer/resources/linux/jar and put there linux's version of RXTXcomm.dat (which is renamed RXTXcomm.jar) 5. create folder /gnu/io/installer/resources/linux/lib and put there linux's version of librxtxSerial. so 6. make sure that RXTXInstaller.jar has the following items: /gnu/io/installer/resources/linux/jar/RXTXcomm.jar /gnu/io/installer/resources/linux/lib/librxtxSerial.so 7. modify file installer.pref: jar file RXTXInstaller.jar must have the following item /gnu/io/installer/installer.pref that's basically it for windows you have to do the similar things: just replace linux to windows and librxtxSerial.so to rxtxSerial.dll and create appropriate gnu.io.installer.windows.WindowsRXTXInstaller class package gnu.io.installer.windows; import java.io.File; public class WindowsRXTXInstaller extends gnu.io.installer.RXTXInstaller{ public WindowsRXTXInstaller(){ createJarFolder(); createLibFolder(); addJarResource("RXTXcomm.jar","/gnu/io/installer/resources/ windows/jar/RXTXcomm.dat"); addLibResource("librxtxSerial.so","/gnu/io/installer/ resources/windows/lib/rxtxSerial.dll"); } protected void createJarFolder(){ String javaHome = System.getProperty("java.home"); char separator = File.separatorChar; jarFolder = new File(javaHome+separator+"lib"+separator+"ext"); } protected void createLibFolder(){ String javaHome = System.getProperty("java.home"); char separator = File.separatorChar; libFolder = new File(javaHome+separator+"bin"); } public void runPreProcess() {} //put here some action you need public void runPostProcess() {} //put here some action you need } installer.pref will look like On Mar 20, 2006, at 10:08 AM, Dr. Douglas Lyon wrote: > Hi All, > Is the Auth package able to work properly on > non Mac OS's? > It was not clear from the doc or download. > > Thanks! > - Doug > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx Dmitry Markman From joachim at buechse.de Mon Mar 20 10:49:06 2006 From: joachim at buechse.de (Joachim Buechse) Date: Mon, 20 Mar 2006 18:49:06 +0100 Subject: [Rxtx] BUG: Lock file stays even if port opening fails Message-ID: This was only tested on MacOSX but looking at the code, it should be true for all systems that use lock_uucp. I am opening a port which can not be opened (dialup port of a telephone paired via bluetooth but currently not reachable). The lock file is created and stays arround, even though the port open failed. After looking a bit through the code (of 2.17), I really wonder if it wouldn't be a good idea to make the "locking" an explicit operation called from the java code. This would certainly simplify the generation of meaningfull exceptions (and java based debugging). Maybe even the handling of "preopened" ports should be in the Java part of the lib (again for java based debugging puposes). That beeing said, I have no idea if this would be possible for the 2.07 implementation. Regards, Joachim From tjarvi at qbang.org Mon Mar 20 11:24:22 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 20 Mar 2006 11:24:22 -0700 (MST) Subject: [Rxtx] BUG: Lock file stays even if port opening fails In-Reply-To: References: Message-ID: On Mon, 20 Mar 2006, Joachim Buechse wrote: > This was only tested on MacOSX but looking at the code, it should be true > for all systems that use lock_uucp. > > I am opening a port which can not be opened (dialup port of a telephone > paired via bluetooth but currently not reachable). The lock file is > created and stays arround, even though the port open failed. > > > After looking a bit through the code (of 2.17), I really wonder if it > wouldn't be a good idea to make the "locking" an explicit operation > called from the java code. This would certainly simplify the generation > of meaningfull exceptions (and java based debugging). > Maybe even the handling of "preopened" ports should be in the Java part > of the lib (again for java based debugging puposes). That beeing said, I > have no idea if this would be possible for the 2.07 implementation. > > Regards, Hi Joachim It should be possible in the 2.0-7 implementation too. The calls to RXTXPort.java would not change. We would just do more there Moving more of that logic into Java would be better as many people don't like to look at C code. There is a liblockdev on most Linux distros that can do most of the C code and would be easier to use. The problem is embeded devices will not have that library. The preopened port code has not been really tested. That was a last minute request in a product cycle. I expect it will be tested this year though. As I recall, some devices really do not like CD raising on open. The preopened ports then allow people to mess around in java without power cycling the devices or losing data. -- Trent Jarvi tjarvi at qbang.org From joachim at buechse.de Mon Mar 20 12:01:08 2006 From: joachim at buechse.de (Joachim Buechse) Date: Mon, 20 Mar 2006 20:01:08 +0100 Subject: [Rxtx] BUG: Lock file stays even if port opening fails In-Reply-To: References: Message-ID: Hi Trent, What is your general feeling about moving code to Java? The last days I have been reading quite a bit of the code and there are several things, that might not work as expected. I'll give you two examples from is_device_locked: if LOCKDIR == /var/spool/locks the directory /var/spool/lock will not be checked. LOCKDIR is not checked for lockfiles with unexpected pefixes While these things have probably never been discovered in production, they are still possibly incorrect implementations. If it was Java code, I would write some unit tests producing the errors that could later be corrected. PS: One could imagine to actually implement the whole lockfile handling in Java using some native routines to get the values required (pid, st_dev, st_rdev, ...). On 20.03.2006, at 19:24, Trent Jarvi wrote: > On Mon, 20 Mar 2006, Joachim Buechse wrote: > >> This was only tested on MacOSX but looking at the code, it should >> be true for all systems that use lock_uucp. >> >> I am opening a port which can not be opened (dialup port of a >> telephone paired via bluetooth but currently not reachable). The >> lock file is created and stays arround, even though the port open >> failed. >> >> >> After looking a bit through the code (of 2.17), I really wonder if >> it wouldn't be a good idea to make the "locking" an explicit >> operation called from the java code. This would certainly simplify >> the generation of meaningfull exceptions (and java based debugging). >> Maybe even the handling of "preopened" ports should be in the Java >> part of the lib (again for java based debugging puposes). That >> beeing said, I have no idea if this would be possible for the 2.07 >> implementation. >> >> Regards, > > Hi Joachim > > It should be possible in the 2.0-7 implementation too. The calls > to RXTXPort.java would not change. We would just do more there > Moving more of that logic into Java would be better as many people > don't like to look at C code. There is a liblockdev on most Linux > distros that can do most of the C code and would be easier to use. > The problem is embeded devices will not have that library. > > The preopened port code has not been really tested. That was a > last minute request in a product cycle. I expect it will be tested > this year though. As I recall, some devices really do not like CD > raising on open. The preopened ports then allow people to mess > around in java without power cycling the devices or losing data. > > -- > Trent Jarvi > tjarvi at qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Mon Mar 20 12:21:02 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 20 Mar 2006 12:21:02 -0700 (MST) Subject: [Rxtx] BUG: Lock file stays even if port opening fails In-Reply-To: References: Message-ID: On Mon, 20 Mar 2006, Joachim Buechse wrote: > Hi Trent, > > What is your general feeling about moving code to Java? The last days I > have been reading quite a bit of the code and there are several things, > that might not work as expected. > > I'll give you two examples from is_device_locked: > > if LOCKDIR == /var/spool/locks the directory /var/spool/lock will not be > checked. > LOCKDIR is not checked for lockfiles with unexpected pefixes > > While these things have probably never been discovered in production, > they are still possibly incorrect implementations. If it was Java code, I > would write some unit tests producing the errors that could later be > corrected. > > PS: One could imagine to actually implement the whole lockfile handling > in Java using some native routines to get the values required (pid, > st_dev, st_rdev, ...). Hi Joachim I like the idea of moving more of the code into java but there are some things to consider. If you break this into multiple JNI calls, the performance will drop considerably during enumeration of ports. We are looking for 256 ports per dev type vs (16? in Sun's 2.0 and fewer types). Its hard to make assumptions. I've seen virtual ports start at /dev/foo100 for instance. It works out to over 7500 ports on Linux if you enable them all. We already trim that back by default. See Linux-all-ports in RXTXCommDriver.java. There are also native libraries that rxtx can link to. If you move too much into Java, linking to 'standard' libraries with distros will break. "configure --enable-liblock=yes" will not be doable. This is probably a favorable way with RedHat, Debian, Suse and others. Thats the right thing to do if there will be rpms, dpkg, .. For those reasons, I think it still make sense to keep it to a minimal ~3 calls to JNI code that we can use for speed and versatility. lock() isLocked(), unlock() perhaps. When I say speed, its more about avoiding crossing the JNI layer multiple times than java vs C performance. With versatility I think liblock is the right way for most but not all (embeded) linux distros. -- Trent Jarvi tjarvi at qbang.org From joachim at buechse.de Mon Mar 20 12:42:04 2006 From: joachim at buechse.de (Joachim Buechse) Date: Mon, 20 Mar 2006 20:42:04 +0100 Subject: [Rxtx] BUG: Lock file stays even if port opening fails In-Reply-To: References: Message-ID: <82C19FE7-DDCB-45B6-B2C9-7606B66F0124@buechse.de> Ok, what about providing a default implementation in Java? The RXTXCommDriver would call a (native) function useNativeLocking and if it returns true, call the native functions for lock() isLocked (), unlock(), else is would use the Java based default implementation. This could possibly be overriden by a property (again for debugging). Joachim On 20.03.2006, at 20:21, Trent Jarvi wrote: > On Mon, 20 Mar 2006, Joachim Buechse wrote: > >> Hi Trent, >> >> What is your general feeling about moving code to Java? The last >> days I have been reading quite a bit of the code and there are >> several things, that might not work as expected. >> >> I'll give you two examples from is_device_locked: >> >> if LOCKDIR == /var/spool/locks the directory /var/spool/lock will >> not be checked. >> LOCKDIR is not checked for lockfiles with unexpected pefixes >> >> While these things have probably never been discovered in >> production, they are still possibly incorrect implementations. If >> it was Java code, I would write some unit tests producing the >> errors that could later be corrected. >> >> PS: One could imagine to actually implement the whole lockfile >> handling in Java using some native routines to get the values >> required (pid, st_dev, st_rdev, ...). > > Hi Joachim > > I like the idea of moving more of the code into java but there are > some things to consider. > > If you break this into multiple JNI calls, the performance will > drop considerably during enumeration of ports. We are looking for > 256 ports per dev type vs (16? in Sun's 2.0 and fewer types). Its > hard to make assumptions. I've seen virtual ports start at /dev/ > foo100 for instance. > > It works out to over 7500 ports on Linux if you enable them all. > We already trim that back by default. See Linux-all-ports in > RXTXCommDriver.java. > > There are also native libraries that rxtx can link to. If you move > too much into Java, linking to 'standard' libraries with distros > will break. "configure --enable-liblock=yes" will not be doable. > This is probably a favorable way with RedHat, Debian, Suse and > others. Thats the right thing to do if there will be rpms, dpkg, .. > > For those reasons, I think it still make sense to keep it to a > minimal ~3 calls to JNI code that we can use for speed and > versatility. lock() isLocked(), unlock() perhaps. When I say > speed, its more about avoiding crossing the JNI layer multiple > times than java vs C performance. With versatility I think liblock > is the right way for most but not all (embeded) linux distros. > > -- > Trent Jarvi > tjarvi at qbang.org > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Mon Mar 20 12:44:47 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 20 Mar 2006 12:44:47 -0700 (MST) Subject: [Rxtx] BUG: Lock file stays even if port opening fails In-Reply-To: <82C19FE7-DDCB-45B6-B2C9-7606B66F0124@buechse.de> References: <82C19FE7-DDCB-45B6-B2C9-7606B66F0124@buechse.de> Message-ID: On Mon, 20 Mar 2006, Joachim Buechse wrote: > Ok, what about providing a default implementation in Java? > > The RXTXCommDriver would call a (native) function useNativeLocking and if > it returns true, call the native functions for lock() isLocked(), > unlock(), else is would use the Java based default implementation. This > could possibly be overriden by a property (again for debugging). > Hi Joachim That would be OK with me. -- Trent Jarvi tjarvi at qbang.org From dmarkman at mac.com Mon Mar 20 22:27:45 2006 From: dmarkman at mac.com (Dmitry Markman) Date: Tue, 21 Mar 2006 00:27:45 -0500 Subject: [Rxtx] binaries request Message-ID: <42702213-C222-4937-A585-7CFB17E47608@mac.com> Hi can somebody send me latest linux and windows binaries, please? or where I can find them (I didn't find them in the latest tareball) I gave up with my cygwin: something wrong I have no idea what java doesn't understand /cygwin/c syntax after I changed makefile it did java part but after that gcc 3.4.4 started to complain I set buffer length to 999 lines but I didn't get beginning of the story something wrong with my 1.4.2_09/include/jni.h gcc doesn't like it anyway I gave up thanks in advance Dmitry Markman -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060320/f8cbc57c/attachment-0051.html From tjarvi at qbang.org Mon Mar 20 22:36:48 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 20 Mar 2006 22:36:48 -0700 (MST) Subject: [Rxtx] binaries request In-Reply-To: <42702213-C222-4937-A585-7CFB17E47608@mac.com> References: <42702213-C222-4937-A585-7CFB17E47608@mac.com> Message-ID: On Tue, 21 Mar 2006, Dmitry Markman wrote: > Hi > can somebody send me latest linux and windows binaries, please? > > or where I can find them (I didn't find them in the latest tareball) > > I gave up with my cygwin: something wrong I have no idea what > java doesn't understand /cygwin/c syntax > after I changed makefile it did java part > but after that gcc 3.4.4 started to complain > I set buffer length to 999 lines but I didn't get beginning of the story > something wrong with my 1.4.2_09/include/jni.h gcc doesn't like it > anyway I gave up > > thanks in advance > Hi Dmitry The bins are here: ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7-bins-r2.zip Here are the files in the zip you want. Jar: rxtx-2.1-7-bins-r2/RXTXcomm.jar Windows: rxtx-2.1-7-bins-r2/Windows/i368-mingw32/rxtxSerial.dll Linux (x86) rxtx-2.1-7-bins-r2/Linux/i686-unknown-linux-gnu/librxtxSerial.so There are others in there including Parallel port support but those are the main ones for testing. -- Trent Jarvi tjarvi at qbang.org From dmarkman at mac.com Mon Mar 20 23:05:59 2006 From: dmarkman at mac.com (Dmitry Markman) Date: Tue, 21 Mar 2006 01:05:59 -0500 Subject: [Rxtx] binaries request In-Reply-To: References: <42702213-C222-4937-A585-7CFB17E47608@mac.com> Message-ID: thank you very much but windows's readme says: rxtxSerial.dll had to be recomopiled to link in missing native methods. should I ignore it? or what? thanks again also I understand that I should use mingw not cygwin I'll try to install mingw On Mar 21, 2006, at 12:36 AM, Trent Jarvi wrote: > On Tue, 21 Mar 2006, Dmitry Markman wrote: > >> Hi >> can somebody send me latest linux and windows binaries, please? >> >> or where I can find them (I didn't find them in the latest tareball) >> >> I gave up with my cygwin: something wrong I have no idea what >> java doesn't understand /cygwin/c syntax >> after I changed makefile it did java part >> but after that gcc 3.4.4 started to complain >> I set buffer length to 999 lines but I didn't get beginning of the >> story >> something wrong with my 1.4.2_09/include/jni.h gcc doesn't like it >> anyway I gave up >> >> thanks in advance >> > > Hi Dmitry > > The bins are here: > > ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7-bins-r2.zip > > Here are the files in the zip you want. > > Jar: > > rxtx-2.1-7-bins-r2/RXTXcomm.jar > > Windows: > > rxtx-2.1-7-bins-r2/Windows/i368-mingw32/rxtxSerial.dll > > Linux (x86) > > rxtx-2.1-7-bins-r2/Linux/i686-unknown-linux-gnu/librxtxSerial.so > > There are others in there including Parallel port support but those > are the main ones for testing. > > -- > Trent Jarvi > tjarvi at qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx Dmitry Markman From tjarvi at qbang.org Mon Mar 20 23:20:33 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 20 Mar 2006 23:20:33 -0700 (MST) Subject: [Rxtx] binaries request In-Reply-To: References: <42702213-C222-4937-A585-7CFB17E47608@mac.com> Message-ID: On Tue, 21 Mar 2006, Dmitry Markman wrote: > thank you very much > > but windows's readme says: > rxtxSerial.dll had to be recomopiled to link in missing native methods. > > should I ignore it? or what? > Hi Dmitry That dll should be OK. r2 is the recompile linked to the missing native method. The readme explains why it was recompiled; fuser.o was not linked into the dll in the first release. -- Trent Jarvi tjarvi at qbang.org From ariantristan at yahoo.com Mon Mar 20 23:55:24 2006 From: ariantristan at yahoo.com (Lambok Sianturi) Date: Mon, 20 Mar 2006 22:55:24 -0800 (PST) Subject: [Rxtx] jvm issue Message-ID: <20060321065524.94779.qmail@web50701.mail.yahoo.com> Hi All, This is my first time to join RxTx mailing list. I thank you all for allowing others to sign in in requests help. I use the latest RxTx lib in Fedora 3 with java version 1.4.2_09 b05. And I got this error: # # An unexpected error has been detected by HotSpot Virtual Machine: # # SIGSEGV (0xb) at pc=0x00bf27f3, pid=2633, tid=3086112448 # # Java VM: Java HotSpot(TM) Client VM (1.4.2_09-b05 mixed mode) # Problematic frame: # C [ld-linux.so.2+0xa7f3] # # An error report file with more information is saved as hs_err_pid2633.log # # If you would like to submit a bug report, please visit: # http://java.sun.com/webapps/bugreport/crash.jsp # ./run.sh: line 3: 2633 Aborted /usr/local/java/bin/java -Djava.library.path=/usr/local/java/jre/lib/ -Djsmsengine.debug=true -classpath jsmsengine.jar:smsgateway.jar:classes12.jar:RXTXcomm.jar:. com.api.sms.SMSServer What is the jvm depedency for the latest library? Can I use 1.4.2_09 b05? Thanks in advance. Arian --------------------------------- Yahoo! Mail Use Photomail to share photos without annoying attachments. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060320/83d58dd7/attachment-0051.html From f.frumento at ngi.it Tue Mar 21 00:21:47 2006 From: f.frumento at ngi.it (Fabio Frumento) Date: Tue, 21 Mar 2006 08:21:47 +0100 Subject: [Rxtx] Javadoc on the go Message-ID: <441FA98B.9050701@ngi.it> Hi Trent, sorry for the big delay but my job is running wild, i was out for some time but now i'm back and ready to continue the javadoc for Rxtx. Did you used the last javadoc patch i sent you ? let me know if i have to send it to you again or not. regards Fabio From lyon at docjava.com Tue Mar 21 00:51:18 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Tue, 21 Mar 2006 02:51:18 -0500 Subject: [Rxtx] lock files Message-ID: Hi All, You know, if the use of lock files were under Java control (rather than a build-time decision), it might enable a more unified binary distro. It might also facilitate quick prototyping of non-lock file approaches to resolving serial port contention issues (i.e., mac-like approaches vs. linux approaches, etc.). I realize that this is a radical overhaul of the lock file policy issue. Also, it may harm performance. On the other hand, our benchmarks on JNI overhead for modern processors indicate performance impact should be minimal. Perhaps it is more of an issue with the toybox systems. Suppose there were a class with a reasonable default...someone might write: SerialPortLockPolicy.setPolicy(SerialPortLockPolicy.UNIX_LOCK_FILE); SerialPortLockPolicy.setPolicy(SerialPortLockPolicy.NO_LOCK_CHECKING); SerialPortLockPolicy.setPolicy(SerialPortLockPolicy.MAC_STYLE); Thus, we could have a run-time reconfiguration of the serial port lock policy. A special NO_LOCK version of the binary would no longer be required. Any thoughts on this? Thanks! - Doug From joachim at buechse.de Tue Mar 21 03:09:09 2006 From: joachim at buechse.de (Joachim Buechse) Date: Tue, 21 Mar 2006 11:09:09 +0100 Subject: [Rxtx] lock files In-Reply-To: References: Message-ID: <8E12916A-1B9A-4FF2-B684-E2D1C794221B@buechse.de> This is pretty much what I thought about when I suggested, that the default behaviour could be overwritten with a property. I am very much in favor of this approach. In particular this allows much easier debugging for PC based java developers. I think big parts of the Java (and maybe some parts of the C code) could use a bit of a structural workover (unit tests, javadoc, synchronization, etc). Maybe there should be a CVS branch for this experimental version. I'd be happy to contribute a first workover for some of the Java code. Designing for testability and implementing a good bunch of unit tests has been a strategy that worked quite well in the Java projects I lead. And it ultimately allows more liberal change permission. Regards, Joachim On 21.03.2006, at 08:51, Dr. Douglas Lyon wrote: > Hi All, > You know, if the use of lock files were > under Java control (rather than a build-time decision), > it might enable a more unified binary distro. It might also > facilitate quick prototyping of non-lock file approaches > to resolving serial port contention issues (i.e., mac-like > approaches vs. linux approaches, etc.). > > I realize that this is a radical overhaul of the lock file policy > issue. Also, it may harm performance. On the other hand, > our benchmarks on JNI overhead for modern processors indicate > performance impact should be minimal. Perhaps it is more of > an issue with the toybox systems. > > Suppose there were a class with a reasonable default...someone > might write: > SerialPortLockPolicy.setPolicy(SerialPortLockPolicy.UNIX_LOCK_FILE); > SerialPortLockPolicy.setPolicy(SerialPortLockPolicy.NO_LOCK_CHECKING); > SerialPortLockPolicy.setPolicy(SerialPortLockPolicy.MAC_STYLE); > > Thus, we could have a run-time reconfiguration of the serial port lock > policy. A special NO_LOCK version of the binary would no longer > be required. > > Any thoughts on this? > > Thanks! > - Doug > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From joachim at buechse.de Tue Mar 21 06:23:08 2006 From: joachim at buechse.de (Joachim Buechse) Date: Tue, 21 Mar 2006 14:23:08 +0100 Subject: [Rxtx] PATCH: use of ioctl(fd, TIOCEXCL) instead of lockfiles Message-ID: <923AE774-EEA2-4911-92D8-32BB27802C8B@buechse.de> Here is the patch for the ioctl(fd, TIOCEXCL). I have verified this only for OSX 10.4.5, hence it is only defined for APPLE. However, it should work at least for Solaris as well. If a process has requested TIOEXCL further open calls by other user processes will fail. The patch also disables uucp style locking for APPLE. Obviously this is discussable. I think it is the way to go, as it eliminates creating the lock directory which doesnt exist on the standard installation and it eliminates messing with the system group definitions (adding users to group uucp). Regarding the possibility of root processes opening a device which is locked - I consider this a feature not a potential problem. It is highly unlikely, that somebody is crazy enough to run a JavaVM as root (unless he has no other means of getting a restricted IP port opened, ie doesnt understand ipfw). Anyway, even if the process runs as root, it fails when calling ioctl(fd, TIOCEXCL). It could however still open the port to listen for RING events. I.e. a fax server which needs to see incoming calls but otherwise doesnt want to block the port. So the only case where the proposed mechanism fails is, if an incorrectly implemented process running as root conflicts with a user process. I think this can be accepted. Regards, Joachim PS: If this patch is generally accepted, the installer and Mac doku should obviously be changed as well. Index: SerialImp.c =================================================================== RCS file: /usr/local/cvsroot/rxtx-devel/src/SerialImp.c,v retrieving revision 1.46.2.187 diff -u -r1.46.2.187 SerialImp.c --- SerialImp.c 29 Jan 2006 22:19:04 -0000 1.46.2.187 +++ SerialImp.c 21 Mar 2006 12:59:16 -0000 @@ -656,6 +656,25 @@ fd=OPEN (filename, O_RDWR | O_NOCTTY | O_NONBLOCK ); } while (fd < 0 && errno==EINTR); +#ifdef OPEN_EXCL + // Note that open() follows POSIX semantics: multiple open() calls to + // the same file will succeed unless the TIOCEXCL ioctl is issued. + // This will prevent additional opens except by root-owned processes. + // See tty(4) ("man 4 tty") and ioctl(2) ("man 2 ioctl") for details. + + if (fd >= 0 && (ioctl(fd, TIOCEXCL) == -1)) + { + sprintf( message, "open: exclusive access denied for % s\n", + filename ); + report( message ); + report_error( message ); + + close(fd); + goto fail; + } +#endif /* OPEN_EXCL */ + + if( configure_port( fd ) ) goto fail; (*env)->ReleaseStringUTFChars( env, jstr, filename ); sprintf( message, "open: fd returned is %i\n", fd ); Index: SerialImp.h =================================================================== RCS file: /usr/local/cvsroot/rxtx-devel/src/SerialImp.h,v retrieving revision 1.11.2.49 diff -u -r1.11.2.49 SerialImp.h --- SerialImp.h 5 Jul 2005 17:47:21 -0000 1.11.2.49 +++ SerialImp.h 21 Mar 2006 12:59:17 -0000 @@ -135,7 +135,8 @@ /*# define LOCKDIR "/var/spool/uucp"*/ # define LOCKDIR "/var/lock" # define LOCKFILEPREFIX "LK." -# define UUCP +/*# define UUCP*/ +# define OPEN_EXCL #endif /* __APPLE__ */ #if defined(__NetBSD__) # define DEVICEDIR "/dev/" From tjarvi at qbang.org Tue Mar 21 10:26:08 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 21 Mar 2006 10:26:08 -0700 (MST) Subject: [Rxtx] Javadoc on the go In-Reply-To: <441FA98B.9050701@ngi.it> References: <441FA98B.9050701@ngi.it> Message-ID: On Tue, 21 Mar 2006, Fabio Frumento wrote: > Hi Trent, > > sorry for the big delay but my job is running wild, i was out for some > time but now i'm back and ready to continue the javadoc for Rxtx. > > Did you used the last javadoc patch i sent you ? let me know if i have to > send it to you again or not. > > regards > > Fabio Hi Fabio The patch is in the rxtx mail-list archives. It will be going in soon. I did not see a time critical portion. I'll probably be going through the list since the last batch of patches this weekend and putting them into CVS. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Tue Mar 21 10:57:18 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 21 Mar 2006 10:57:18 -0700 (MST) Subject: [Rxtx] jvm issue In-Reply-To: <20060321065524.94779.qmail@web50701.mail.yahoo.com> References: <20060321065524.94779.qmail@web50701.mail.yahoo.com> Message-ID: On Mon, 20 Mar 2006, Lambok Sianturi wrote: > Hi All, > This is my first time to join RxTx mailing list. I thank you all for allowing others to sign in in requests help. > I use the latest RxTx lib in Fedora 3 with java version 1.4.2_09 b05. And I got this error: > > # > # An unexpected error has been detected by HotSpot Virtual Machine: > # > # SIGSEGV (0xb) at pc=0x00bf27f3, pid=2633, tid=3086112448 > # > # Java VM: Java HotSpot(TM) Client VM (1.4.2_09-b05 mixed mode) > # Problematic frame: > # C [ld-linux.so.2+0xa7f3] A native library loading error? What happens if you recompile rxtx on your system and install that? This sounds like an ABI problem? rxtx 2.1-7 was compiled with a gcc 2.96 toolchain as I recall. The hope is newer system will be backwards compatible. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Tue Mar 21 11:05:29 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 21 Mar 2006 11:05:29 -0700 (MST) Subject: [Rxtx] PATCH: use of ioctl(fd, TIOCEXCL) instead of lockfiles In-Reply-To: <923AE774-EEA2-4911-92D8-32BB27802C8B@buechse.de> References: <923AE774-EEA2-4911-92D8-32BB27802C8B@buechse.de> Message-ID: On Tue, 21 Mar 2006, Joachim Buechse wrote: > Here is the patch for the ioctl(fd, TIOCEXCL). I have verified this only > for OSX 10.4.5, hence it is only defined for APPLE. However, it should > work at least for Solaris as well. > > If a process has requested TIOEXCL further open calls by other user > processes will fail. > > The patch also disables uucp style locking for APPLE. Obviously this is > discussable. I think it is the way to go, as it eliminates creating the > lock directory which doesnt exist on the standard installation and it > eliminates messing with the system group definitions (adding users to > group uucp). > > Regarding the possibility of root processes opening a device which is > locked - I consider this a feature not a potential problem. It is highly > unlikely, that somebody is crazy enough to run a JavaVM as root (unless > he has no other means of getting a restricted IP port opened, ie doesnt > understand ipfw). Anyway, even if the process runs as root, it fails when > calling ioctl(fd, TIOCEXCL). It could however still open the port to > listen for RING events. I.e. a fax server which needs to see incoming > calls but otherwise doesnt want to block the port. So the only case where > the proposed mechanism fails is, if an incorrectly implemented process > running as root conflicts with a user process. I think this can be > accepted. > > Regards, > Joachim > > PS: If this patch is generally accepted, the installer and Mac doku > should obviously be changed as well. > > > Index: SerialImp.c > =================================================================== > RCS file: /usr/local/cvsroot/rxtx-devel/src/SerialImp.c,v > retrieving revision 1.46.2.187 > diff -u -r1.46.2.187 SerialImp.c > --- SerialImp.c 29 Jan 2006 22:19:04 -0000 1.46.2.187 > +++ SerialImp.c 21 Mar 2006 12:59:16 -0000 > @@ -656,6 +656,25 @@ > fd=OPEN (filename, O_RDWR | O_NOCTTY | O_NONBLOCK ); > } while (fd < 0 && errno==EINTR); > > +#ifdef OPEN_EXCL > + // Note that open() follows POSIX semantics: multiple open() > calls to > + // the same file will succeed unless the TIOCEXCL ioctl is > issued. > + // This will prevent additional opens except by root-owned > processes. > + // See tty(4) ("man 4 tty") and ioctl(2) ("man 2 ioctl") for > details. > + > + if (fd >= 0 && (ioctl(fd, TIOCEXCL) == -1)) > + { > + sprintf( message, "open: exclusive access denied for % > s\n", > + filename ); > + report( message ); > + report_error( message ); > + > + close(fd); > + goto fail; > + } > +#endif /* OPEN_EXCL */ > + > + > if( configure_port( fd ) ) goto fail; > (*env)->ReleaseStringUTFChars( env, jstr, filename ); > sprintf( message, "open: fd returned is %i\n", fd ); > Index: SerialImp.h > =================================================================== > RCS file: /usr/local/cvsroot/rxtx-devel/src/SerialImp.h,v > retrieving revision 1.11.2.49 > diff -u -r1.11.2.49 SerialImp.h > --- SerialImp.h 5 Jul 2005 17:47:21 -0000 1.11.2.49 > +++ SerialImp.h 21 Mar 2006 12:59:17 -0000 > @@ -135,7 +135,8 @@ > /*# define LOCKDIR "/var/spool/uucp"*/ > # define LOCKDIR "/var/lock" > # define LOCKFILEPREFIX "LK." > -# define UUCP > +/*# define UUCP*/ > +# define OPEN_EXCL > #endif /* __APPLE__ */ > #if defined(__NetBSD__) > # define DEVICEDIR "/dev/" > This looks like a good start. What do you think Dmitry? Perhaps all systems with TIOCEXCL defined should use that though. Even if they use lockfiles. It wont hurt anything. That would catch people hacking their own serial apps without checking lockfiles. Its a good idea to avoid C++ style comments in the C portions. Some older systems don't deal with them well. If it's just for Mac OS X, it isn't a big deal. I think it was the Irix compiler that was problematic? -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Tue Mar 21 11:22:05 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 21 Mar 2006 11:22:05 -0700 (MST) Subject: [Rxtx] lock files In-Reply-To: <8E12916A-1B9A-4FF2-B684-E2D1C794221B@buechse.de> References: <8E12916A-1B9A-4FF2-B684-E2D1C794221B@buechse.de> Message-ID: We can try it. Maybe the JNI is much improved. The nice thing about linking into liblock is distros then worry about lockfiles on their systems. This way, we have to deal with any changes that may show up. On Tue, 21 Mar 2006, Joachim Buechse wrote: > This is pretty much what I thought about when I suggested, that the > default behaviour could be overwritten with a property. I am very much in > favor of this approach. In particular this allows much easier debugging > for PC based java developers. > > I think big parts of the Java (and maybe some parts of the C code) could > use a bit of a structural workover (unit tests, javadoc, synchronization, > etc). Maybe there should be a CVS branch for this experimental version. > I'd be happy to contribute a first workover for some of the Java code. > Designing for testability and implementing a good bunch of unit tests has > been a strategy that worked quite well in the Java projects I lead. And > it ultimately allows more liberal change permission. > > Regards, > Joachim > > > On 21.03.2006, at 08:51, Dr. Douglas Lyon wrote: > >> Hi All, >> You know, if the use of lock files were >> under Java control (rather than a build-time decision), >> it might enable a more unified binary distro. It might also >> facilitate quick prototyping of non-lock file approaches >> to resolving serial port contention issues (i.e., mac-like >> approaches vs. linux approaches, etc.). >> >> I realize that this is a radical overhaul of the lock file policy >> issue. Also, it may harm performance. On the other hand, >> our benchmarks on JNI overhead for modern processors indicate >> performance impact should be minimal. Perhaps it is more of >> an issue with the toybox systems. >> >> Suppose there were a class with a reasonable default...someone >> might write: >> SerialPortLockPolicy.setPolicy(SerialPortLockPolicy.UNIX_LOCK_FILE); >> SerialPortLockPolicy.setPolicy(SerialPortLockPolicy.NO_LOCK_CHECKING); >> SerialPortLockPolicy.setPolicy(SerialPortLockPolicy.MAC_STYLE); >> >> Thus, we could have a run-time reconfiguration of the serial port lock >> policy. A special NO_LOCK version of the binary would no longer >> be required. >> >> Any thoughts on this? >> >> Thanks! >> - Doug >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From dmarkman at mac.com Tue Mar 21 16:05:17 2006 From: dmarkman at mac.com (Dmitry Markman) Date: Tue, 21 Mar 2006 18:05:17 -0500 Subject: [Rxtx] PATCH: use of ioctl(fd, TIOCEXCL) instead of lockfiles In-Reply-To: References: <923AE774-EEA2-4911-92D8-32BB27802C8B@buechse.de> Message-ID: <512AC70C-BB86-48F2-A83C-023F35C23BAB@mac.com> I think it's cool, but I'd like to have that property implementation when user can choose between locking mechanism about comments: it's easy to change comments to the C style or we can use extensions of the file to cpp so c++ compiler will be used On Mar 21, 2006, at 1:05 PM, Trent Jarvi wrote: > This looks like a good start. What do you think Dmitry? Perhaps > all systems with TIOCEXCL defined should use that though. Even if > they use lockfiles. It wont hurt anything. That would catch > people hacking their own serial apps without checking lockfiles. > > Its a good idea to avoid C++ style comments in the C portions. > Some older systems don't deal with them well. If it's just for Mac > OS X, it isn't a big deal. I think it was the Irix compiler that > was problematic? Dmitry Markman From dmarkman at mac.com Tue Mar 21 16:13:00 2006 From: dmarkman at mac.com (Dmitry Markman) Date: Tue, 21 Mar 2006 18:13:00 -0500 Subject: [Rxtx] PATCH: use of ioctl(fd, TIOCEXCL) instead of lockfiles In-Reply-To: References: <923AE774-EEA2-4911-92D8-32BB27802C8B@buechse.de> Message-ID: I'd like to add that creating locking folder isn't a big deal we never had a problem related to the lock folders, because we always used installer on mac os x from other hand I'm not very much familiar with iotcl locking approach and I'm not sure it's more efficient Joachim wrote "I think it is the way to go, as it eliminates creating the lock directory which doesnt exist on the standard installation and it eliminates messing with the system group definitions (adding users to group uucp)." but I really didn't have any problem with that 1. doesn't exist on the standard installation there are many-many things that don't exist in the standard installation so I don't think that argument is strong enough 2. messing with the system group definitions I don't think we're messing with the group definition mac os x provides very clear way to set up group's members and together with Greg Guerin AuthKit there is no problem to set those definitions so I don't think that argument is strong either but from other hand using iotcl is more promising and is more elegant On Mar 21, 2006, at 1:05 PM, Trent Jarvi wrote: > > This looks like a good start. What do you think Dmitry? Perhaps > all systems with TIOCEXCL defined should use that though. Even if > they use lockfiles. It wont hurt anything. That would catch > people hacking their own serial apps without checking lockfiles. Dmitry Markman From joachim at buechse.de Wed Mar 22 04:46:45 2006 From: joachim at buechse.de (Joachim Buechse) Date: Wed, 22 Mar 2006 12:46:45 +0100 Subject: [Rxtx] PATCH: use of ioctl(fd, TIOCEXCL) instead of lockfiles In-Reply-To: References: <923AE774-EEA2-4911-92D8-32BB27802C8B@buechse.de> Message-ID: Sorry, I was not very clear with my arguments, so I will try again;-) Please, don't take this as an attack against work that has been done. I think the contributions that have been made in the past were made in a good spirit. But I really believe, that the current solution for OSX has many shortcomings and should be changed as soon as possible. lock files --- The /var/lock folder does not exist on the standard OSX installation, however the standard installation includes several applications that use serial ports (i.e. the FAX capability). This indicates, that the lock folder approach will not work well with system components. Applications for OSX will generally try to live in harmony with system components (except for HP print drivers of course). I think RXTX should follow this approach as well. uucp group --- Accessing serial ports is not an admin privileged operation on OSX. Any user (world) has read/write privileges on /dev/tty*. So the system default is to not enforce any group membership to access these ports. The group uucp however is a system group on all unix systems I know. It exists for certain system processes. A non admin user should in general not be a member of this group. Quite arguably no user should ever be a member of this group. Installer --- My general opinion is, that - no Installer should touch user or group data without warning - no Application Installer should touch groups which are not specific to the very application installed - no Installer should ever add regular users to a system group The current installer injects the installing user in the group uucp without warning about this change and without giving the option to "opt out" of this change. This is a potential security risk (but not currently a real one, as OSX contains no folders belonging to group uucp). The current installer does not work for multi user systems. It puts the installing user in the uucp group. However the installing user is not necessarily the user that will use the application. Putting all users that may use a serial port application in the system group uucp seems like a very invasive approach to me. Besides that, newly created users will not automatically be in the group and hence, serial applications will "break" for new users without obvious reasons. Avoiding the lock files will allow self contained applications (i.e. drag&drop installation). In my eyes this is largely preferable over an installer that requests admin privileges. Adding up all these points indicates very strongly, that the lock-file implementation is not the way to go on OSX. Regards, Joachim On 22.03.2006, at 00:13, Dmitry Markman wrote: > I'd like to add that > > creating locking folder isn't a big deal > we never had a problem related to the lock folders, because we > always used installer on mac os x > from other hand I'm not very much familiar with iotcl locking > approach and I'm not sure it's more efficient > > Joachim wrote "I think it is the way to go, as it eliminates > creating the lock directory which doesnt exist on the standard > installation and it eliminates messing with the system group > definitions (adding users to group uucp)." but I really didn't have > any problem with that > > 1. doesn't exist on the standard installation > there are many-many things that don't exist in the standard > installation so I don't think that argument is strong enough > 2. messing with the system group definitions > I don't think we're messing with the group definition > mac os x provides very clear way to set up group's members and > together with Greg Guerin AuthKit there is no problem to set those > definitions > so I don't think that argument is strong either > but from other hand using iotcl is more promising and is more elegant > > > > On Mar 21, 2006, at 1:05 PM, Trent Jarvi wrote: > >> >> This looks like a good start. What do you think Dmitry? Perhaps >> all systems with TIOCEXCL defined should use that though. Even if >> they use lockfiles. It wont hurt anything. That would catch >> people hacking their own serial apps without checking lockfiles. > > Dmitry Markman > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From dmarkman at mac.com Wed Mar 22 05:27:13 2006 From: dmarkman at mac.com (Dmitry Markman) Date: Wed, 22 Mar 2006 07:27:13 -0500 Subject: [Rxtx] PATCH: use of ioctl(fd, TIOCEXCL) instead of lockfiles In-Reply-To: References: <923AE774-EEA2-4911-92D8-32BB27802C8B@buechse.de> Message-ID: <83440CF3-DCD8-41C1-B941-F227232C27E3@mac.com> thanks for the very good explanation I didn't think that you were attacking any thing, so don't worry I just had feeling, that there were more aesthetic reasons for going to ioctl then real necessity now you explained everything quite well (BTW, asfar as I remember installer asks admin password so it wasn't quiet, but it really doesn't matter now) thanks On Mar 22, 2006, at 6:46 AM, Joachim Buechse wrote: > Sorry, I was not very clear with my arguments, so I will try again;-) > > Please, don't take this as an attack against work that has been > done. I think the contributions that have been made in the past > were made in a good spirit. But I really believe, that the current > solution for OSX has many shortcomings and should be changed as > soon as possible. > > lock files > --- > The /var/lock folder does not exist on the standard OSX > installation, however the standard installation includes several > applications that use serial ports (i.e. the FAX capability). This > indicates, that the lock folder approach will not work well with > system components. Applications for OSX will generally try to live > in harmony with system components (except for HP print drivers of > course). I think RXTX should follow this approach as well. > > uucp group > --- > Accessing serial ports is not an admin privileged operation on OSX. > Any user (world) has read/write privileges on /dev/tty*. So the > system default is to not enforce any group membership to access > these ports. The group uucp however is a system group on all unix > systems I know. It exists for certain system processes. A non admin > user should in general not be a member of this group. Quite > arguably no user should ever be a member of this group. > > Installer > --- > My general opinion is, that > - no Installer should touch user or group data without warning > - no Application Installer should touch groups which are not > specific to the very application installed > - no Installer should ever add regular users to a system group > > The current installer injects the installing user in the group uucp > without warning about this change and without giving the option to > "opt out" of this change. This is a potential security risk (but > not currently a real one, as OSX contains no folders belonging to > group uucp). > > The current installer does not work for multi user systems. It puts > the installing user in the uucp group. However the installing user > is not necessarily the user that will use the application. Putting > all users that may use a serial port application in the system > group uucp seems like a very invasive approach to me. Besides that, > newly created users will not automatically be in the group and > hence, serial applications will "break" for new users without > obvious reasons. > > > Avoiding the lock files will allow self contained applications > (i.e. drag&drop installation). In my eyes this is largely > preferable over an installer that requests admin privileges. Adding > up all these points indicates very strongly, that the lock-file > implementation is not the way to go on OSX. > > Regards, > Joachim > > > On 22.03.2006, at 00:13, Dmitry Markman wrote: > >> I'd like to add that >> >> creating locking folder isn't a big deal >> we never had a problem related to the lock folders, because we >> always used installer on mac os x >> from other hand I'm not very much familiar with iotcl locking >> approach and I'm not sure it's more efficient >> >> Joachim wrote "I think it is the way to go, as it eliminates >> creating the lock directory which doesnt exist on the standard >> installation and it eliminates messing with the system group >> definitions (adding users to group uucp)." but I really didn't >> have any problem with that >> >> 1. doesn't exist on the standard installation >> there are many-many things that don't exist in the standard >> installation so I don't think that argument is strong enough >> 2. messing with the system group definitions >> I don't think we're messing with the group definition >> mac os x provides very clear way to set up group's members and >> together with Greg Guerin AuthKit there is no problem to set those >> definitions >> so I don't think that argument is strong either >> but from other hand using iotcl is more promising and is more elegant >> >> >> >> On Mar 21, 2006, at 1:05 PM, Trent Jarvi wrote: >> >>> >>> This looks like a good start. What do you think Dmitry? Perhaps >>> all systems with TIOCEXCL defined should use that though. Even >>> if they use lockfiles. It wont hurt anything. That would catch >>> people hacking their own serial apps without checking lockfiles. >> >> Dmitry Markman >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx Dmitry Markman From lyon at docjava.com Wed Mar 22 06:12:18 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Wed, 22 Mar 2006 08:12:18 -0500 Subject: [Rxtx] sole of a new design pattern Message-ID: Hi All, I have been thinking about how we design the serial port software. I think we need a new design pattern. For lack of a better term, I shall call it: The Parametric Singleton Design Pattern By Douglas A. Lyon ABSTRACT The goal of the singleton design pattern is to make sure that there is one, and only one, instance of a given class. The goal of the parametric singleton design pattern is to make sure that there is one, and only one, instance of a given class with the given parametric values. We parametric singleton design pattern combines the singleton design pattern with a parameter that enables unique creation of instances of a class. These instances are cached. When a user asks for an instance with these parameters, the cache is checked. If the instance is in the cache, the instance is returned, otherwise it is created, added to the cache and then returned. We apply our parametric singleton design pattern to the retrieval of RMI registries bound to a given port. The goal of our system is to make sure that no two RMI registries are listening to the same socket and to make use of the RMI registries after they have been created. RMI registries are used in distributed computation. Introduction The singleton design pattern is meant to ensure that on a single instance of a class exists. It is also meant to provide a global point of access to it. The intent of the parametric singleton design pattern is to ensure that a class has only one instance for a given set of parameter values. It also provides a global point of access to it. Motivation A system cannot tolerate multiple instances of some classes with identical parameters. For example, you cannot have two instances making use of the same serial port, at the same time. You cannot have two instances that are trying to listen to the same socket connection. You cannot have two instances writing to the same file structure at the same time. As the operating system is often thought of as the arbiter of consumed resources (i.e., tape drives, serial ports, etc.) we frequently leave it to an operating system implementation to resolve these contention issues. Even for similar resources (like serial ports) there are few standards for handling contention. For example, serial ports on Linux are locked using a "/var/lock" file. POSIX, on the other hand, uses ioctl mechanisms to prevent contention. A better solution is to make a class that is responsible for keeping track of the instances created from the class. The class is declared final, so that it cannot be subclassed. The class also has a private constructor, so that other classes cannot instance it. The new design pattern is called the parametric singleton design pattern and it provides a way to access and create instances with given parameters. Applicability Use the Parametric Singleton Design Pattern when: 1. There must be exactly one instance of a class with the given parameters. 2. The instances must be accessible to clients from a well-known access point. Structure Insert UML diagram here. Participants The Parametric Singleton Clients that need instances 1. The Parametric Singleton defines an instance upon request from a client, if, and only if, the instance does not already exist. 2. The Parametric Singleton returns the instance to the client. 3. The Parametric Singleton is responsible for creating unique instances from given parameters. Collaborations Clients obtain a reference to a Parametric Singleton instance only through the parametric singleton design pattern. If the instance is left in an improper state (e.g., the serial port was left open) it is NOT the role of the Parametric Singleton Design Pattern to close the IO port. Nor is it the role of the Parametric Singleton Design Pattern to open the port. That role is delegate to some other part of the system. Further, it is not the role of the Parametric Singleton Design Pattern to check out resources. That is, multiple threads can have multiple references to the same resource at the same time. MUTEX locking is delegated to some other part of the system. Consequences The Parametric Singleton Design Pattern has several benefits: 1. Controlled access to parametrically defined instances. Since the Parametric Singleton class encapsulates its instances, there is control over how and when clients access it. 2. Reduced name space. The Parametric Singleton pattern avoids global variables that store instances created from the same parameter. Implementation Here are implementation issues to consider when using the Parametric Singleton pattern: 1. Unique mapping of parameters. The Parametric Singleton pattern requires that there be a mean to isomorphically map the parameter space into the instance space and back again. 2. Ensure unique instances. The Parametric Singleton pattern makes unique instances from parameters, and it does so only once. 3. Cache instances for fast retrieval. The Parametric Singleton pattern must be able to look up instances, given some set of parameters, and do so from some data structure. That is, there must be enough space to hold references to all the instances the program will need. Also, a mechanism is needed to look up and retrieve the instances quickly enough to satisfy the clients. Sample Code public final class ParametricSingletonRmiRegistry { private static Hashtable registry = new Hashtable(100); // use singleton pattern and??????????????????????????????????????????????? // prevent instantiation of RmiRegistryUtils.?????????????????????????????? private ParametricSingletonRmiRegistry() { } // the only instance of the Registry held by the RmiRegistryUtils?????????? public static void listNames(Integer port) { if (!isInCacheAndRunning(port)) return; Registry r = (Registry) registry.get(port); System.out.println("registry on port: " + port); System.out.println("registry: " + r); System.out.println("names: "); try { print(r.list()); } catch (RemoteException e) { In.message(e); } System.out.println("------------------------"); } /**???????????????????????????????????????????????????????????????????????? * Checks whether a Registry has been started on this host????????????????? * in the specified port.?????????????????????????????????????????????????? * If not, it tries to start one.?????????????????????????????????????????? * when it fails to start a Registry, it exits the program????????????????? * with exit code 1.??????????????????????????????????????????????????????? */ public static void restart(int port) { if (isInCacheAndRunning(port)) return; try { startRegistry(port); } catch (RemoteException e) { In.message(e); } } /**???????????????????????????????????????????????????????????????????????? * @param port????????????????????????????????????????????????????????????? * @return true if registry is in cache and running???????????????????????? */ private static boolean isInCacheAndRunning(Integer port) { if (!isRegistryRunning(port.intValue())) return false; if (!isRegistryInCache(port.intValue())) return false; return true; } /**???????????????????????????????????????????????????????????????????????? * @param port????????????????????????????????????????????????????????????? * @return true if we are able to locate a local registry on port.??????????????????????????????????????????????????????????????????????????? */ private static boolean isRegistryRunning(int port) { try { Registry r = LocateRegistry.getRegistry(port); if (r != null) return true; } catch (RemoteException e) { return false; } return false; } /**???????????????????????????????????????????????????????????????????????? * @param port????????????????????????????????????????????????????????????? * @return return true if registry is in cache????????????????????????????? */ private static boolean isRegistryInCache(int port) { if (registry.get(new Integer(port)) == null) return false; return true; } /**???????????????????????????????????????????????????????????????????????? * Restart the registry, if needed.???????????????????????????????????????? * Return the only instance of the registry for consistent global?????????? * using by making use of the Singleton Design Pattern????????????????????? *????????????????????????????????????????????????????????????????????????? * @return the internally held registry instance.?????????????????????????? */ public static Registry getRegistry(Integer port) { restart(port); return (Registry) registry.get(port); } private static void startRegistry(Integer port) throws RemoteException { Registry r; try { r = LocateRegistry.createRegistry(port.intValue()); registry.put(port, r); //r = new sun.rmi.registry.RegistryImpl???????????????????????????? /// (port.intValue());?????????????????????????????????????? // registry.put(port, r);?????????????????????????????????????????? } catch (Exception e) { //e.printStackTrace();????????????????????????????????????????????? r = LocateRegistry.getRegistry(port.intValue()); registry.put(port, r); } } public static void main(String args[]) throws RemoteException { //restart(port);??????????????????????????????????????????????????????? restart(5001); restart(5002); restart(5002); Registry r = LocateRegistry.getRegistry(5002); System.out.println("registry="+r); } } I would very much like to get your feedback on this new design pattern idea. Thank you for your time. Regards, - Doug From david.garnier at trusted-logic.com Wed Mar 22 07:36:10 2006 From: david.garnier at trusted-logic.com (David Garnier) Date: Wed, 22 Mar 2006 15:36:10 +0100 Subject: [Rxtx] sole of a new design pattern In-Reply-To: References: Message-ID: <442160DA.80107@trusted-logic.com> Hello, > The Parametric Singleton Design Pattern The Singleton is the most abused design pattern ever. Good use-cases for this pattern are extremely rare and mostly confined to problems related to hardware resources, like serial ports. > Applicability > > Use the Parametric Singleton Design Pattern when: > 1. There must be exactly one instance of a class with the given > parameters. OK. As I said above, this case this actually very unusual. The Singleton pattern is mostly used when : > 2. The instances must be accessible to clients from a well-known > access point. Using the singleton pattern in this case is just convenient for the programmer. Problems arises pretty quickly, especially if you attempt to unit-test your classes. 1) If your singleton is stateful, or hold on to stateful objects, it means that two different unit tests are not actually independent. Instead of starting with a brand new environment, the result of a test may be affected by the result of a previous test. This problem also arise when with your class relies on a database. In both cases, the solution is to reset your "unique" resource (Singleton or database) at the beginning of the test, which is a pain. Also, while most projects connect to a single database, projects that allow the use of Singletons usually contain several of thems, and new ones may cropped up unnoticed. You quickly end up with test cases that only pass in a certain order, which is a royal pain. 2) You cannot mockup a singleton. Once everyone calls the SomeSingleton class statically, you can't replace your class by SomeSingletonMockup. Furthermore, even for hardware services, the Singleton pattern does not really prevent concurrent accesses. If you start the same program in two different JVMs, unless they somehow shared the state of their "Singletons" (through lock files for example), the Singleton pattern will not prevent concurrent access. Our application uses RXTX, and we routinely encounter cases where another (native) application has already locked the port. Since we cannot modify the native application to recognize lock files, OS-level control is irreplaceable. > > Consequences > The Parametric Singleton Design Pattern has several benefits: > > 1. Controlled access to parametrically defined instances. Since > the Parametric Singleton class encapsulates its instances, there is > control over how and when clients access it. Not really. Once you've returned the instance to a client, you've lost control over it. The client can to whatever it wants with it. You cannot "recall" the instance or claim it back. > 2. Reduced name space. The Parametric Singleton pattern avoids > global variables that store instances created from the same parameter. Sure, but you don't have to rely on a Singleton for that. Just create a single Factory. > I would very much like to get your feedback on this new design > pattern idea. Well, it's nothing new. Some may say that it is the point of design patterns: formalizes the designs that occur again and again. However, this design is simply a combination of the Singleton and Factory patterns. I did use it in the past, but now I've been exposed to the shortcomings of the Singleton pattern, so I limit myself to Factories. Regards, David From sean_montgomery at baseview.com Wed Mar 22 08:35:28 2006 From: sean_montgomery at baseview.com (Sean Montgomery) Date: Wed, 22 Mar 2006 10:35:28 -0500 Subject: [Rxtx] sole of a new design pattern In-Reply-To: <442160DA.80107@trusted-logic.com> References: <442160DA.80107@trusted-logic.com> Message-ID: <05769CA7-A51B-4CF0-BAA0-E02DD905F5A4@baseview.com> On Mar 22, 2006, at 9:36 AM, David Garnier wrote: > Furthermore, even for hardware services, the Singleton pattern does > not really prevent concurrent > accesses. If you start the same program in two different JVMs, > unless they somehow shared the state > of their "Singletons" (through lock files for example), the > Singleton pattern will not prevent > concurrent access. > Multiple class loaders in a single JVM can be tricky, too. Then there's synchronization, lazy initialization and serialization of singletons to contend with. Bloch's Effective Java covers these, and here's a few articles: http://www.javaworld.com/javaworld/jw-04-2003/jw-0425-designpatterns- p3.html http://java.sun.com/developer/technicalArticles/Programming/singletons/ Just FYI :-) From lyon at docjava.com Wed Mar 22 08:50:48 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Wed, 22 Mar 2006 10:50:48 -0500 Subject: [Rxtx] sole of a new design pattern In-Reply-To: <442160DA.80107@trusted-logic.com> References: <442160DA.80107@trusted-logic.com> Message-ID: Hi All, First, I would like to thank David for his prompt and thoughtful remarks. I had no idea people that feel strongly about a design patterns! Wow! Feedback (particularly critical feedback) is greatly appreciated. Starting at the end, first: >I did use it in >the past, but now I've been exposed to the shortcomings of the >Singleton pattern, so I limit myself to Factories. David, if I understood your comments correctly, you suggested that Factories can be used in leu of the Singleton Design Pattern, or even the Parametric Singleton Design Pattern. As I see in [Gof]: Factory Method: Intent "Define an interface for creating an object, but let subclasses decide which class to instantiate. Factory Method lets a class defer instantiation to subclasses." The Singleton Design Pattern is a concrete class, which is rather different, right? Also, subclasses are not permitted with Singleton, as they are final. Naturally, I could use an abstract factory as a parent for a singleton. I could even design a facade that could be implemented with the singleton....but that is not the intention of the design. Unless you want a mock-up, as discussed, below: More below: >Hello, > >> The Parametric Singleton Design Pattern > >The Singleton is the most abused design pattern ever. Good use-cases >for this pattern are extremely >rare and mostly confined to problems related to hardware resources, >like serial ports. > > >> Applicability >> >> Use the Parametric Singleton Design Pattern when: >> 1. There must be exactly one instance of a class with the given >> parameters. >OK. As I said above, this case this actually very unusual. The >Singleton pattern is mostly used when : >> 2. The instances must be accessible to clients from a well-known >> access point. > >Using the singleton pattern in this case is just convenient for the >programmer. Problems arises >pretty quickly, especially if you attempt to unit-test your classes. > >1) If your singleton is stateful, or hold on to stateful objects, it >means that two different unit >tests are not actually independent. Instead of starting with a brand >new environment, the result of >a test may be affected by the result of a previous test. This >problem also arise when with your >class relies on a database. In both cases, the solution is to reset >your "unique" resource >(Singleton or database) at the beginning of the test, which is a >pain. Also, while most projects >connect to a single database, projects that allow the use of >Singletons usually contain several of >thems, and new ones may cropped up unnoticed. You quickly end up >with test cases that only pass in a >certain order, which is a royal pain. There are basic problems with communicating finite state machines that include reachability and deadlock analysis. These are addressed with petri net analysis and are beyond the scope of the design pattern. As you quite rightly pointed out; the parametric singleton pattern (or the singleton pattern, for that matter) enable multiple threads to gain access to the