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
smime.p7s
Description: S/MIME cryptographic signature
