hmm whats the zip exception? Where is it thown?

Hello, we reverted back to IBM 1.3.0 after running into this problem, has anyone made any progress here?

Okay, after many lost hours, I've figured out the problem with using the IBM VM.

The problem lies with the IBM JRE 1.3.1's implementation of java.net.URLClassLoader. More specifically, it lies with IBM's unjarring code called from within that code.

When you call java.net.URLClassLoader using a search URL that is not referencing a ".jar" file or a directory, it will barf with a ZipException.

JBoss, for complicated reasons, calls this class's "findClass" method when the URL is pointing to an .xml file.

The IBM environment attempts to "unjar" the .xml file resulting in an ZipException.

The Sun environment probably does the same thing, except that it doesn't throw the ZipException and instead throws the ClassNotFoundException.

Since the ZipException is a checked exception (and the classes in the IBM environment from which it is thrown don't declare that they throw it) this is a pretty interesting bug. For instance, it is impossible to compile something that catches this exception. ;) It's probably thrown from inside JNI code.

This is definitely a bug with the IBM JRE, and I will report it to IBM.

However, in the meantime I've implemented a workaround for Jboss.

Jboss regularly passes around URL's other than ones pointing to .jar files and directories. The reason for this is that it has many, many ClassLoaders that are (directly or indirectly) subclasses of UseClassLoader, some of which understand these weird URLS, some of which don't.

These class loaders are iterated through as appropriate to find a class. Unfortunately, the first one hit (after a caching class loader) is org.jboss.mx.loading.UnifiedClassLoader which directly extends UseClassLoader.

This class calls methods on its superclass (UseClassLoader) sometimes using Url's its not designed to handle.

In most environments this merely means that a lot of "bad" urls are "unjarred" unsuccessfully. This could have a large negative performance impact in some circumstances.

In the IBM environment, because of the ZipException bug, these bad URL's are fatal.

I've implemented a workaround by modifying the UnifiedClassLoader's constructor to only set a URL in the superClass (using super.AddURL) if it is a valid URL (IE--ends with ".jar" or "/").

This fixes the problem with the IBM runtime environment, and potentially improves performance for other environments.

I have not tested this much beyond just starting the server. My environment is not set up yet, and I am a Jboss neophyte. I don't even know how to run the regression tests yet. Haven't been able to get the blasted thing working until now.

That said, the server now starts up beautifully.

Attached is a replacement jboss-3.0.4-src/jmx/src/main/org/jboss/mx/loading/
UnifiedClassLoader.java file that fixes the problem.

Replace the file, recompile, and run with it.

Tell me if you run into any problems.
Then after it gets a little more testing I'll try to get the the fix rolled into the distibution proper.


Ack, file attachments seem broken in here.. Let me post this and try adding the attachment in a second.


-Scott Dossey
seveirein@yahoo.com
[Extremely poor programmer! Will hack JBoss for free hardcover documentation.]

---------------------------------------------------------
NOTE: This may be a duplicate post--I seem to be having problems with the Forums.
---------------------------------------------------------

Okay, after many lost hours, I've figured out the problem with using the IBM VM.

The problem lies with the IBM JRE 1.3.1's implementation of java.net.URLClassLoader. More specifically, it lies with IBM's unjarring code called from within that code.

When you call java.net.URLClassLoader using a search URL that is not referencing a ".jar" file or a directory, it will barf with a ZipException.

JBoss, for complicated reasons, calls this class's "findClass" method when the URL is pointing to an .xml file.

The IBM environment attempts to "unjar" the .xml file resulting in an ZipException.

The Sun environment probably does the same thing, except that it doesn't throw the ZipException and instead throws the ClassNotFoundException.

Since the ZipException is a checked exception (and the classes in the IBM environment from which it is thrown don't declare that they throw it) this is a pretty interesting bug. For instance, it is impossible to compile something that catches this exception. ;) It's probably thrown from inside JNI code.

This is definitely a bug with the IBM JRE, and I will report it to IBM.

However, in the meantime I've implemented a workaround for Jboss.

Jboss regularly passes around URL's other than ones pointing to .jar files and directories. The reason for this is that it has many, many ClassLoaders that are (directly or indirectly) subclasses of UseClassLoader, some of which understand these weird URLS, some of which don't.

These class loaders are iterated through as appropriate to find a class. Unfortunately, the first one hit (after a caching class loader) is org.jboss.mx.loading.UnifiedClassLoader which directly extends UseClassLoader.

This class calls methods on its superclass (UseClassLoader) sometimes using Url's its not designed to handle.

In most environments this merely means that a lot of "bad" urls are "unjarred" unsuccessfully. This could have a large negative performance impact in some circumstances.

In the IBM environment, because of the ZipException bug, these bad URL's are fatal.

I've implemented a workaround by modifying the UnifiedClassLoader's constructor to only set a URL in the superClass (using super.AddURL) if it is a valid URL (IE--ends with ".jar" or "/").

This fixes the problem with the IBM runtime environment, and potentially improves performance for other environments.

I have not tested this much beyond just starting the server. My environment is not set up yet, and I am a Jboss neophyte. I don't even know how to run the regression tests yet. Haven't been able to get the blasted thing working until now.

That said, the server now starts up beautifully.

Attached is a replacement jboss-3.0.4-src/jmx/src/main/org/jboss/mx/loading/
UnifiedClassLoader.java file that fixes the problem.

Replace the file, recompile, and run with it.

Tell me if you run into any problems.
Then after it gets a little more testing I'll try to get the the fix rolled into the distibution proper.

-Scott Dossey
seveirein@yahoo.com
[Extremely poor programmer! Will hack JBoss for free hardcover documentation.]

This is the aforementioned attachment to fix the problem.
-Scott Dossey
seveirein@yahoo.com

Hmm, I've posted three posts to this forum thread that show up using searches but don't display on the actual page.

I posted on another forum thread and it works.

Consider this a test message. This Jboss site may has ties into sourceforge and I'm thinking I posted at a bad time during sourceforge maintenance.

ACID would be nice. ;)

-Scott