Ok I must be confused as to the specifics of the problem. I created a class "jtest.java" that simply gets the javax.usb root hub and prints out its vendor id. If the javax.usb subsystem can't be accessed, it should throw an Exception and/or Error.
I compiled it, and jar'ed it up into jtest.jar, including a manifest file with only: Main-Class: jtest I then ran: java -jar jtest.jar It ran fine. I'm using the IBM 1.4.2 JRE, is this only a problem on the SUN JRE, or am I missing something? On Tue, 29 Mar 2005, Brad BARCLAY wrote: >On Mar 29, 2005, at 16:39, Dan Streetman wrote: > >> On Mon, 28 Mar 2005, Brad BARCLAY wrote: >> >>> The javax.usb JARs themselves are found due to the copy placed in the >>> jre/lib/ext directory, >> >> I didn't put them there, I assume you copied them there? That should >> be >> ok just checking. > > Good thing you did. I thought the RPMs had put them there, but it's >possible I may have had an older installation of the JARs sitting in >there. > >> I'd like the properties file to be (by default) >> /opt/javax-usb/etc/javax.usb.properties, period...if you modify that >> file, >> you know the changes will get used. > > That's going to be problematic anyone runs any Java application via >the -jar parameter, which would include any Java application which is >launched by double-clicking on its JAR file in any GUI environment. >For some reason, Sun did indeed decide that the CLASSPATH should be >ignored when running with the -jar parameter (yes, it's part of the >launcher spec last time I looked). > >> Is the -jar behavior part of the JVM spec or specific to a single JVM >> implementation? Seems like disregarding the env CLASSPATH is just >> stupid... :) > > I agree -- but for some reason, that's what Sun decided to do. There >may have been a rationale for it at the time -- I suppose it does >permit you to have different versions of the same library JAR file(s) >that you run from during development (for example, in the jSyncManager >we have three JAR files: the Core Application Set (CAS), the jConduit >Plug-In Pack, and the Core Sync engine/API. The CAS JAR references the >jConduits and API JARs via a relative path (ie: it expects to find them >in a 'lib' subdirectory in the same directory as the CAS JAR). Thus, >none of the JARs neds to be in your CLASSPATH at all, and if they >aren't (and aren't in a standard extensions directory somewhere) I >could conceptually have different builds in different directories, and >not have to worry about one version picking up the JARs of a different >version. > > This is the only rationale I can think of for Sun doing this, and it >does make some sense if you think of it as a sort of library versioning >control tool -- but otherwise yes -- it's a huge PITA :). > >> Ick, no idea...I will check on that. Open a bug to track it. > > `Let me double-check my installation first -- if the JARs in my ext >directory are indeed an older version, it could be the cause of the >problem. > >Brad BARCLAY > >=-=-=-=-=-=-=-=-=-= > From the Mac OS X Desktop of Brad BARCLAY >E-Mail: [EMAIL PROTECTED] Web: http://www.jsyncmanager.org > > -- Dan Streetman [EMAIL PROTECTED] --------------------- 186,272 miles per second: It isn't just a good idea, it's the law! ------------------------------------------------------- This SF.net email is sponsored by Demarc: A global provider of Threat Management Solutions. Download our HomeAdmin security software for free today! http://www.demarc.com/info/Sentarus/hamr30 _______________________________________________ javax-usb-devel mailing list javax-usb-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/javax-usb-devel
