[fedora-java] tomcat5

[Thomas Fitzsimmons]

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?

Tom