8:37 a.m.
I see that tomcat5 is in rawhide now - thanks Gary!
I started it up, and saw the process running until I tried to view a
page, then the process died. Here are the contents
of /var/log/tomcat5/catalina.out. Any ideas?
Thanks,
AG
8:48 a.m.
On Tuesday 08 March 2005 09:37, Anthony Green wrote:
I started it up, and saw the process running until I tried to view a
page, then the process died. Here are the contents
of /var/log/tomcat5/catalina.out. Any ideas?
Caused by: java.io.FileNotFoundException:
/usr/share/tomcat5/common/lib/[jdbc-stdext].jar (No such file or
directory)
at gnu.java.nio.channels.FileChannelImpl.open(java.lang.String, int)
(/usr/lib/libgcj.so.6.0.0)
Is there /usr/share/tomcat5/common/lib/[jdbc-stdext].jar on your
machine?
9:15 a.m.
On Tue, 2005-03-08 at 09:48 -0500, Vadim Nasardinov wrote:
Is there /usr/share/tomcat5/common/lib/[jdbc-stdext].jar on your
machine?
lrwxrwxrwx 1 root root 38 Mar 8 06:40 [jdbc-stdext].jar ->
/could/not/find/extension/for/this/jvm
lrwxrwxrwx 1 root root 38 Mar 8 06:40 [jndi].jar ->
/could/not/find/extension/for/this/jvm
Bah. Ok, the java-1.4.2-gcj-compat spec file says:
Provides: jndi, jdbc-stdext
So, do we need to play tricks for these, like I suggested for jta?
AG
10:16 a.m.
Anthony Green wrote:
I see that tomcat5 is in rawhide now - thanks Gary!
You're welcome :)
I started it up, and saw the process running until I tried to
view a page, then the process died. Here are the contents of
/var/log/tomcat5/catalina.out. Any ideas?
Not a clue, sorry: I haven't tried running it at all yet!
I just needed it built in time for FC4t1...
Cheers,
Gary
12:13 p.m.
Le mardi 08 mars 2005 à 07:15 -0800, Anthony Green a écrit :
On Tue, 2005-03-08 at 09:48 -0500, Vadim Nasardinov wrote:
> Is there /usr/share/tomcat5/common/lib/[jdbc-stdext].jar on your
> machine?
lrwxrwxrwx 1 root root 38 Mar 8 06:40 [jdbc-stdext].jar ->
/could/not/find/extension/for/this/jvm
lrwxrwxrwx 1 root root 38 Mar 8 06:40 [jndi].jar ->
/could/not/find/extension/for/this/jvm
Bah. Ok, the java-1.4.2-gcj-compat spec file says:
Provides: jndi, jdbc-stdext
So, do we need to play tricks for these, like I suggested for jta?
Yep. The jvm framework does not actually cares about the rpm provides.
What it wants is a jar in the places it scans (a symlink to another jar
is fine).
Typically for an in-jvm implementation you have to put a symlink in
/usr/lib/jvm-exports/my_jvm_name/
to the jar providing the implementation in
/usr/lib/jvm/my_jvm_name/
The symlink must have the standard name the apps want (in this case
jdbc-stdext.jar and jndi.jar)
This way the common scripts don't require any deep knowledge about every
single jvm layout or capabilities - it's the jvm packager responsibility
to create the few symlinks in its package that will inform the rest of
the system of what his jvm can actually do.
(this was originally done because IBM and SUN jvms had very different
layouts but it should help even more for gcj since it does not even
share the same roots as these other two).
When stuff moves in-jvm all you have to do is create a symlink with the
same name the jar in /usr/share/java used to have and you're done (plus
of course add the relevant provides to the spec). Symlinks
in /usr/lib/jvm-exports/my_jvm_name/ have priority wrt to stuff
in /usr/share/java so you can even install simultaneously a jvm that
absolutely want to use its own implementation and another that relies on
the external /usr/share/java one.
(this is all part of the JPackage framework - when in doubt you can
consult the policy document in jpackage-utils %doc or ask on the
jpackage-discuss ML)
Regards,
--
Nicolas Mailhot
12:17 p.m.
Le mardi 08 mars 2005 à 09:48 -0500, Vadim Nasardinov a écrit :
On Tuesday 08 March 2005 09:37, Anthony Green wrote:
> I started it up, and saw the process running until I tried to view a
> page, then the process died. Here are the contents
> of /var/log/tomcat5/catalina.out. Any ideas?
>
> Caused by: java.io.FileNotFoundException:
> /usr/share/tomcat5/common/lib/[jdbc-stdext].jar (No such file or
> directory)
BTW it's wonderful that gcj actually gives a meaningful error on
dangling symlinks instead of the strange crashes proprietary JVMs are
prone to.
Regards,
--
Nicolas Mailhot
12:34 p.m.
>>>> "Anthony" == Anthony Green
<green(a)redhat.com> writes:
Anthony> lrwxrwxrwx 1 root root 38 Mar 8 06:40 [jdbc-stdext].jar ->
/could/not/find/extension/for/this/jvm
Anthony> lrwxrwxrwx 1 root root 38 Mar 8 06:40 [jndi].jar ->
/could/not/find/extension/for/this/jvm
Anthony> Bah. Ok, the java-1.4.2-gcj-compat spec file says:
Anthony> Provides: jndi, jdbc-stdext
Anthony> So, do we need to play tricks for these, like I suggested for jta?
When I look at my JDK installs, I don't see separate jdbc or jndi jars.
Did something change here? (This machine is still on FC2...)
Plus, afaik, jndi is in j2se.
Tom
12:49 p.m.
On Tue, 2005-03-08 at 07:15 -0800, Anthony Green wrote:
On Tue, 2005-03-08 at 09:48 -0500, Vadim Nasardinov wrote:
> Is there /usr/share/tomcat5/common/lib/[jdbc-stdext].jar on your
> machine?
lrwxrwxrwx 1 root root 38 Mar 8 06:40 [jdbc-stdext].jar ->
/could/not/find/extension/for/this/jvm
lrwxrwxrwx 1 root root 38 Mar 8 06:40 [jndi].jar ->
/could/not/find/extension/for/this/jvm
Bah. Ok, the java-1.4.2-gcj-compat spec file says:
Provides: jndi, jdbc-stdext
Yeah, as far as I know, these are just empty provides right now. We
need to fill them in with actual jars -- the question is, where do the
free implementations come from?
Tom
1:11 p.m.
Le mardi 08 mars 2005 à 11:34 -0700, Tom Tromey a écrit :
>>>>> "Anthony" == Anthony Green
<green(a)redhat.com> writes:
Anthony> lrwxrwxrwx 1 root root 38 Mar 8 06:40 [jdbc-stdext].jar ->
/could/not/find/extension/for/this/jvm
Anthony> lrwxrwxrwx 1 root root 38 Mar 8 06:40 [jndi].jar ->
/could/not/find/extension/for/this/jvm
Anthony> Bah. Ok, the java-1.4.2-gcj-compat spec file says:
Anthony> Provides: jndi, jdbc-stdext
Anthony> So, do we need to play tricks for these, like I suggested for jta?
When I look at my JDK installs, I don't see separate jdbc or jndi jars.
Did something change here? (This machine is still on FC2...)
Plus, afaik, jndi is in j2se.
Tomcat5 was originally packaged for java 1.3.x - at that time jdbc and
jndi lived outside the JVM. It's a testament to the framework strength
that the same package works without changes on java 1.4.x.
I agree now that all the JVMs JPackage supports include these bits both
the requires and the symlinks seeds could be removed from the package.
You have to remember though things move in-jvm every release and it's
mightily nice to be able to hide these changes from the packages so you
don't have to rewrite specs all the time (and you can use the same
packages with a 1.x.y jvm and a 1.x+1.z jvm - think when Red Hat
includes preview versions of the next gcc release along the current one
in RHEL or FC)
Of course pass must be able to use either the old out-of-jvm jar or the
new in-jvm one without rebuild. This is usually the case for big
projects like Tomcat.
Regards,
--
Nicolas Mailhot
1:24 p.m.
>>>> "Nicolas" == Nicolas Mailhot
<Nicolas.Mailhot(a)laPoste.net> writes:
Nicolas> You have to remember though things move in-jvm every release
Nicolas> and it's mightily nice to be able to hide these changes from
Nicolas> the packages so you don't have to rewrite specs all the time
Yeah... actually I'm fine with leaving things as they are. I just
wasn't sure where these symlinks should point for libgcj. But it
sounds like just pointing them at libgcj.jar should work.
Tom
1:40 p.m.
Le mardi 08 mars 2005 à 12:24 -0700, Tom Tromey a écrit :
>>>>> "Nicolas" == Nicolas Mailhot
<Nicolas.Mailhot(a)laPoste.net> writes:
Nicolas> You have to remember though things move in-jvm every release
Nicolas> and it's mightily nice to be able to hide these changes from
Nicolas> the packages so you don't have to rewrite specs all the time
Yeah... actually I'm fine with leaving things as they are. I just
wasn't sure where these symlinks should point for libgcj. But it
sounds like just pointing them at libgcj.jar should work.
The symlinks are actually just a security (yes the jvm includes stuff we
need). You can probably point them to any jar you like - if the stuff in
internal to the jvm it'll be added to the classpath anyway.
It's nicer to point them to the real implementation though, if only to
document the jvm internal layout.
regards,
--
Nicolas Mailhot
2:56 a.m.
On Tue, 2005-03-08 at 13:49 -0500, Thomas Fitzsimmons wrote:
>
>Bah. Ok, the java-1.4.2-gcj-compat spec file says:
>
>Provides: jndi, jdbc-stdext
>
Yeah, as far as I know, these are just empty provides right now. We
need to fill them in with actual jars -- the question is, where do the
free implementations come from?
Aren't they already in libgcj.jar? The only problem is how to make them
available as jndi.jar and jdbc-stdext.jar (I guess).
AG
2:57 a.m.
On Tue, 2005-03-08 at 12:24 -0700, Tom Tromey wrote:
>>>>> "Nicolas" == Nicolas Mailhot
<Nicolas.Mailhot(a)laPoste.net> writes:
Nicolas> You have to remember though things move in-jvm every release
Nicolas> and it's mightily nice to be able to hide these changes from
Nicolas> the packages so you don't have to rewrite specs all the time
Yeah... actually I'm fine with leaving things as they are. I just
wasn't sure where these symlinks should point for libgcj. But it
sounds like just pointing them at libgcj.jar should work.
Are you sure this won't cause problems for proprietary VMs when they
want to load jndi.jar? They'll be looking at a jar file with all of the
core classes.
AG
4:10 a.m.
On Mer 9 mars 2005 9:57, Anthony Green a écrit :
On Tue, 2005-03-08 at 12:24 -0700, Tom Tromey wrote:
> >>>>> "Nicolas" == Nicolas Mailhot
<Nicolas.Mailhot(a)laPoste.net> writes:
>
> Nicolas> You have to remember though things move in-jvm every release
> Nicolas> and it's mightily nice to be able to hide these changes from
> Nicolas> the packages so you don't have to rewrite specs all the time
>
> Yeah... actually I'm fine with leaving things as they are. I just
> wasn't sure where these symlinks should point for libgcj. But it
> sounds like just pointing them at libgcj.jar should work.
Are you sure this won't cause problems for proprietary VMs when they
want to load jndi.jar? They'll be looking at a jar file with all of the
core classes.
That's why you put the symlinks in a very particular location (_NOT_
/usr/share/java) that is only inspected buy the common classpath scripts
if the corresponding JVM is used.
This is one of the main differences between Debian packaging and JPackage
packaging - jars are not lumped in a single directory, they are isolated
in separate parts of the filesystem to make sure they are never exposed to
the wrong jvm.
Regards,
--
Nicolas Mailhot
4:12 a.m.
On Mer 9 mars 2005 9:56, Anthony Green a écrit :
On Tue, 2005-03-08 at 13:49 -0500, Thomas Fitzsimmons wrote:
> >
> >Bah. Ok, the java-1.4.2-gcj-compat spec file says:
> >
> >Provides: jndi, jdbc-stdext
> >
>
> Yeah, as far as I know, these are just empty provides right now. We
> need to fill them in with actual jars -- the question is, where do the
> free implementations come from?
Aren't they already in libgcj.jar? The only problem is how to make them
available as jndi.jar and jdbc-stdext.jar (I guess).
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.
Regards,
--
Nicolas Mailhot
5:39 a.m.
Nicolas Mailhot wrote:
Le mardi 08 mars 2005 à 12:24 -0700, Tom Tromey a écrit :
> >>>>> "Nicolas" == Nicolas Mailhot
<Nicolas.Mailhot(a)laPoste.net> writes:
>
> Nicolas> You have to remember though things move in-jvm
every
> Nicolas> release and it's mightily nice to be able to hide these
> Nicolas> changes from the packages so you don't have to rewrite
> Nicolas> specs all the time
>
> Yeah... actually I'm fine with leaving things as they are. I just
> wasn't sure where these symlinks should point for libgcj. But it
> sounds like just pointing them at libgcj.jar should work.
The symlinks are actually just a security (yes the jvm includes
stuff we need). You can probably point them to any jar you like - if
the stuff in internal to the jvm it'll be added to the classpath
anyway.
It's nicer to point them to the real implementation though, if only
to document the jvm internal layout.
Would it be better perhaps to replace the symlinks with empty jar
files? Or maybe jarfiles containing only a README to indicate that
the classes that would be in there are now in the core classpath?
Cheers,
Gary
6:50 a.m.
On Mer 9 mars 2005 12:39, Gary Benson a écrit :
Nicolas Mailhot wrote:
> The symlinks are actually just a security (yes the jvm includes
> stuff we need). You can probably point them to any jar you like - if
> the stuff in internal to the jvm it'll be added to the classpath
> anyway.
>
> It's nicer to point them to the real implementation though, if only
> to document the jvm internal layout.
Would it be better perhaps to replace the symlinks with empty jar
files? Or maybe jarfiles containing only a README to indicate that
the classes that would be in there are now in the core classpath?
Both would work - the classpath builder only cares about finding a file
with the right name in the right place, and jvms only require real jar
files (they don't handle well files with .jar extensions that are not a
jar archive).
I like symlinking the bits which provide the extension better (sometimes
when you need to debug a crash it's convenient to have a symlink that
shows you for example that the xml parser inside IBM jvms is just some
xerces version), but that might only be pedantic me.
I must say that if the problem is no one knows where the gcj bits that do
jndi are it's a bit worrying in itself ;)
Regards,
--
Nicolas Mailhot
6:52 a.m.
Nicolas Mailhot wrote:
I like symlinking the bits which provide the extension better
(sometimes when you need to debug a crash it's convenient to have a
symlink that shows you for example that the xml parser inside IBM
jvms is just some xerces version), but that might only be pedantic
me.
No, sounds reasonable to me.
Cheers,
Gary
9:25 a.m.
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?
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}}
at java.net.URLClassLoader.findClass(java.lang.String) (/usr/lib/libgcj.so.6.0.0)
at java.lang.ClassLoader.loadClass(java.lang.String, boolean)
(/usr/lib/libgcj.so.6.0.0)
at java.lang.Class.forName(java.lang.String, boolean, java.lang.ClassLoader)
(/usr/lib/libgcj.so.6.0.0)
...8 more
We have this class installed, so presumably the class loader's class path is wrong
somehow.
AG
10:24 a.m.
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
11:20 a.m.
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.
jmx is also set up to use "alternatives".
I don't know what the right answer is. Suggestions?
AG
11:31 a.m.
On Wednesday 09 March 2005 12:20, Anthony Green wrote:
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.
This doesn't parse. What's included in Sun's rt.jar? MX4J?
11:51 a.m.
On Wed, 2005-03-09 at 12:31 -0500, Vadim Nasardinov wrote:
On Wednesday 09 March 2005 12:20, Anthony Green wrote:
> 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.
This doesn't parse. What's included in Sun's rt.jar? MX4J?
Yes, it looks that way.
AG
12:03 p.m.
New subject: JMX and JMX Remote (was: Re: tomcat5)
On Wednesday 09 March 2005 12:51, Anthony Green wrote:
> This doesn't parse. What's included in Sun's
rt.jar? MX4J?
Yes, it looks that way.
It doesn't quite look that way from where I sit. MX4J is an
implementation of JMX and JMX Remote. These *are* included
in J2SE 1.5 (5.0):
http://java.sun.com/j2se/1.5.0/docs/api/javax/management/package-frame.html
http://java.sun.com/j2se/1.5.0/docs/api/javax/management/remote/package-f...
However, they are not part of J2SE 1.4:
http://java.sun.com/j2se/1.4.2/docs/api/overview-frame.html
You have to download these separately, if you want to use Sun's
reference implementation under JDK 1.4:
http://java.sun.com/products/JavaManagement/download.html
Are we both looking at the same thing?
12:03 p.m.
Le mercredi 09 mars 2005 à 09:51 -0800, Anthony Green a écrit :
On Wed, 2005-03-09 at 12:31 -0500, Vadim Nasardinov wrote:
> On Wednesday 09 March 2005 12:20, Anthony Green wrote:
> > 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.
>
> This doesn't parse. What's included in Sun's rt.jar? MX4J?
Yes, it looks that way.
Are you sure you're not talking about jmx
(http://java.sun.com/products/JavaManagement/ ?)
I'd be astounded if Sun dropped its own implementation for a FOSS clone.
Regards,
--
Nicolas Mailhot
12:17 p.m.
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
12:27 p.m.
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
12:34 p.m.
>>>> "Tom" == Thomas Fitzsimmons
<fitzsim(a)redhat.com> writes:
Tom> I've been seeing that message too. First of all, why does the urls
Tom> field of VMClassLoader not print *all* jars in the extensions directory?
I looked into this. The problem is, URLClassLoader caches the
toString() result but does not reset it when a new URL is added.
Whoops.
All the jars definitely do end up in there though, at least in my
simple test.
Tom> We either need to change the JPackage standard to point
Tom> to /usr/share/java/ext or we need to hard-code /usr/share/java-ext
Tom> and /usr/lib/java-ext into libgcj as extensions directories.
We can easily add a configuration option for this. If we only need
one directory we could just have our RPM install a symlink (the
compiled-in extdir is not created by the gcc install process).
Tom
12:47 p.m.
Tom Tromey writes:
>>>>> "Tom" == Thomas Fitzsimmons
<fitzsim(a)redhat.com> writes:
Tom> I've been seeing that message too. First of all, why does the urls
Tom> field of VMClassLoader not print *all* jars in the extensions directory?
I looked into this. The problem is, URLClassLoader caches the
toString() result but does not reset it when a new URL is added.
Whoops.
Where's this?
Andrew.
12:47 p.m.
Le mercredi 09 mars 2005 à 13:17 -0500, Thomas Fitzsimmons a écrit :
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?
Please don't use /usr/share/java/ext. You'll get into big problems the
day two gcj versions are deployed in parallel (think gcc4) if they share
the same extension dir. It's much easier to have separate dirs (possibly
with symlinks pointing to a common pool) than to handle things like "I
want to include all the jars in this dir except this one which is used
by another version".
This being said, the way JPackage does stuff is not fixed in stone, it
can change for the next release if people think it could get better.
(only please remember we have already a full repo built around the
current rules, so don't ask for changes just for cosmetic value)
Regards,
--
Nicolas Mailhot
3:01 p.m.
New subject: mx4j (Was: tomcat5)
I looked at this a little further...
On Wed, 2005-03-09 at 07:25 -0800, Anthony Green wrote:
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}}
at java.net.URLClassLoader.findClass(java.lang.String) (/usr/lib/libgcj.so.6.0.0)
at java.lang.ClassLoader.loadClass(java.lang.String, boolean)
(/usr/lib/libgcj.so.6.0.0)
at java.lang.Class.forName(java.lang.String, boolean, java.lang.ClassLoader)
(/usr/lib/libgcj.so.6.0.0)
...8 more
The tomcat5 startup script uses JPackage's rebuild-jar-repository script
to construct a directory of jar files for the server to use. One of
these is [jmxri].jar. So it symlinks to /usr/share/java/jmxri.jar,
which is itself a symlink since jmx appears to be managed by
alternatives. We eventually get to /usr/share/java/mx4j/mx4j-jmx.jar.
Unfortunately, this jar has external dependencies on other jar files
in /usr/share/java/mx4j. How is rebuild-jar-repository or tomcat5
supposed to know this? We end up with an incomplete jar repository,
which is causing this problem. Is there a good and simple solution to
this problem?
AG
3:06 p.m.
>>>> "Andrew" == Andrew Haley
<aph(a)redhat.com> writes:
> I looked into this. The problem is, URLClassLoader caches the
> toString() result but does not reset it when a new URL is added.
> Whoops.
Andrew> Where's this?
We talked about this on irc but I thought I'd follow-up for the record.
It is just a small bug in URLClassLoader; addURL has to clear the
cached toString() result. This is now fixed in libgcj and classpath.
Tom
6985
days inactive
6986
days old
java-devel@lists.fedoraproject.org
32 comments
8 participants
participants (8)
-
Andrew Haley -
Anthony Green -
Gary Benson -
Nicolas Mailhot -
Nicolas Mailhot
-
Thomas Fitzsimmons -
Tom Tromey -
Vadim Nasardinov