On Wed, 2005-03-09 at 13:17 -0500, Thomas Fitzsimmons wrote: >On Wed, 2005-03-09 at 09:20 -0800, Anthony Green wrote: >>On Wed, 2005-03-09 at 11:24 -0500, Thomas Fitzsimmons wrote: >>> I've been seeing that message too. First of all, why does the urls >>> field of VMClassLoader not print *all* jars in the extensions directory? >>> Is this a libgcj bug? >> >>It certainly looks that way. >> >>> The other annoying thing is the difference >>> between /usr/share/java-ext, /usr/lib/java-ext and /usr/share/java/ext. >>> We either need to change the JPackage standard to point >>> to /usr/share/java/ext or we need to hard-code /usr/share/java-ext >>> and /usr/lib/java-ext into libgcj as extensions directories. Defining >>> java.ext.dirs in all the wrapper scripts is turning out to be quite >>> fragile. In this case the mx4j jar probably installs >>> in /usr/share/java-ext and it doesn't look like java.ext.dirs is getting >>> set properly (to /usr/share/java-ext:/usr/lib/java-ext) for you. >> >>I don't think that's really the problem, since mx4j doesn't install in >>any extensions directory. It probably should for gcj at least, since >>it's included in Sun's rt.jar. >> >>But it seems that gcj should have it's own extension directory. >> > >That's a good idea. Then we wouldn't have all these problems associated >with trying to match Sun's JAR layouts (e.g. classpathx-mail embedding >an inetlib implementation, ugh). We could just create jar file symlinks >(mostly to libgcj.jar) for programs that look for the actual jars. >Everything else they needed (e.g. providers) would transparently be >included on CLASSPATH by way of the gcj extensions directory. In fact, >we could just keep using /usr/share/java/ext for that purpose. What are >the ramifications of putting jars in the extension directories? > I guess there's a problem with this from the JPackage-purity perspective. Should the JPackage conventions mandate putting jar files in /usr/share/java/ext, where they're necessary for gcj inter-operation? Tom
