On Wed, 2005-03-09 at 07:25 -0800, Anthony Green wrote:
>On Wed, 2005-03-09 at 11:12 +0100, Nicolas Mailhot wrote:
>> A look at how JPackage packages other JVMs (closed stuff I know:() would
>> be pretty enlightening I think. I know the documentation can be hard to
>> grasp without concrete examples.
>
>Ok, I think the answer is that java-gcj-compat needs to create the
>following symlinks...
>
># ls -l /usr/lib/jvm-exports/java-1.4.2-gcj-1.4.2.0/
>total 12
>lrwxrwxrwx 1 root root 32 Mar 9 07:13 jaas.jar -> /usr/share/java/libgcj-4.0.0.jar
>lrwxrwxrwx 1 root root 32 Mar 9 07:11 jdbc-stdext.jar -> /usr/share/java/libgcj-4.0.0.jar
>lrwxrwxrwx 1 root root 32 Mar 9 07:11 jndi.jar -> /usr/share/java/libgcj-4.0.0.jar
>
>fitzsim: do you agree?
>
I've got new java-1.4.2-gcj-compat packages here that add these
symlinks. I'm holding off building them into beehive until FC4test1 has
branched.
>Now tomcat5 gets a lot further, and we hit something new....
>
># cat /var/log/tomcat5/catalina.out
>Bootstrap: Class loader creation threw exception
>java.lang.NoClassDefFoundError: while resolving class: javax.management.MBeanServerFactory
> at java.lang.VMClassLoader.transformException(java.lang.Class, java.lang.Throwable) (/usr/lib/libgcj.so.6.0.0)
> at java.lang.VMClassLoader.resolveClass(java.lang.Class) (/usr/lib/libgcj.so.6.0.0)
> at java.lang.Class.initializeClass() (/usr/lib/libgcj.so.6.0.0)
> at org.apache.catalina.startup.Bootstrap.createClassLoader(java.lang.String, java.lang.ClassLoader) (Unknown Source)
> at org.apache.catalina.startup.Bootstrap.initClassLoaders() (Unknown Source)
> at org.apache.catalina.startup.Bootstrap.init() (Unknown Source)
> at org.apache.catalina.startup.Bootstrap.main(java.lang.String[]) (Unknown Source)
> at gnu.java.lang.MainThread.call_main() (/usr/lib/libgcj.so.6.0.0)
> at gnu.java.lang.MainThread.run() (/usr/lib/libgcj.so.6.0.0)
>Caused by: java.lang.ClassNotFoundException: mx4j.log.Logger not found in gnu.gcj.runtime.SystemClassLoader{urls=[], parent=gnu.gcj.runtime.VMClassLoader{urls=[file:/usr/share/java/ext/com-sun-tools-doclets-Taglet-0.7.1.jar], parent=null}}
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? 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.
Tom
