-
-
2. Re: IBM VM installation
joelvogt Nov 10, 2002 8:45 PM (in response to jbone)hmm whats the zip exception? Where is it thown?
-
3. Re: IBM VM installation
jbone Nov 13, 2002 2:10 PM (in response to jbone)This one is thrown all during startup:
2002-11-13 12:45:41,152 ERROR [STDERR] java.util.zip.ZipException: error in opening zip file
2002-11-13 12:45:41,165 ERROR [STDERR] at java.util.zip.ZipFile.open(Native Method)
2002-11-13 12:45:41,177 ERROR [STDERR] at java.util.zip.ZipFile.(ZipFile.java:127)
2002-11-13 12:45:41,188 ERROR [STDERR] at java.util.jar.JarFile.(JarFile.java:138)
2002-11-13 12:45:41,200 ERROR [STDERR] at java.util.jar.JarFile.(JarFile.java:80)
2002-11-13 12:45:41,212 ERROR [STDERR] at sun.misc.URLClassPath$JarLoader.getJarFile(URLClassPath.java:526)
2002-11-13 12:45:41,224 ERROR [STDERR] at sun.misc.URLClassPath$JarLoader.(URLClassPath.java:491)
2002-11-13 12:45:41,237 ERROR [STDERR] at sun.misc.URLClassPath$2.run(URLClassPath.java:287)
2002-11-13 12:45:41,250 ERROR [STDERR] at java.security.AccessController.doPrivileged(Native Method)
2002-11-13 12:45:41,263 ERROR [STDERR] at sun.misc.URLClassPath.getLoader(URLClassPath.java(Compiled Code))
2002-11-13 12:45:41,275 ERROR [STDERR] at sun.misc.URLClassPath.getLoader(URLClassPath.java(Compiled Code))
2002-11-13 12:45:41,287 ERROR [STDERR] at sun.misc.URLClassPath.access$000(URLClassPath.java:85)
2002-11-13 12:45:41,299 ERROR [STDERR] at sun.misc.URLClassPath$1.next(URLClassPath.java:193)
2002-11-13 12:45:41,311 ERROR [STDERR] at sun.misc.URLClassPath$1.hasMoreElements(URLClassPath.java:204)
2002-11-13 12:45:41,324 ERROR [STDERR] at java.net.URLClassLoader$4.run(URLClassLoader.java:523)
2002-11-13 12:45:41,337 ERROR [STDERR] at java.security.AccessController.doPrivileged(Native Method)
2002-11-13 12:45:41,350 ERROR [STDERR] at java.net.URLClassLoader$3.hasMoreElements(URLClassLoader.java:520)
2002-11-13 12:45:41,361 ERROR [STDERR] at sun.misc.CompoundEnumeration.next(CompoundEnumeration.java:43)
2002-11-13 12:45:41,372 ERROR [STDERR] at sun.misc.CompoundEnumeration.hasMoreElements(CompoundEnumeration.java:52)
2002-11-13 12:45:41,384 ERROR [STDERR] at com.sun.naming.internal.VersionHelper12$7.run(VersionHelper12.java:208)
2002-11-13 12:45:41,397 ERROR [STDERR] at java.security.AccessController.doPrivileged(Native Method)
2002-11-13 12:45:41,410 ERROR [STDERR] at com.sun.naming.internal.VersionHelper12$InputStreamEnumeration.getNextElement(VersionHelper12.java:205)
2002-11-13 12:45:41,422 ERROR [STDERR] at com.sun.naming.internal.VersionHelper12$InputStreamEnumeration.hasMore(VersionHelper12.java:225)
2002-11-13 12:45:41,435 ERROR [STDERR] at com.sun.naming.internal.ResourceManager.getApplicationResources(ResourceManager.java:450)
2002-11-13 12:45:41,446 ERROR [STDERR] at com.sun.naming.internal.ResourceManager.getInitialEnvironment(ResourceManager.java:164)
2002-11-13 12:45:41,458 ERROR [STDERR] at javax.naming.InitialContext.init(InitialContext.java:227)
2002-11-13 12:45:41,470 ERROR [STDERR] at javax.naming.InitialContext.(InitialContext.java:187)
2002-11-13 12:45:41,481 ERROR [STDERR] at org.jboss.naming.NamingService.startService(NamingService.java:164)
2002-11-13 12:45:41,492 ERROR [STDERR] at org.jboss.system.ServiceMBeanSupport.start(ServiceMBeanSupport.java:164)
2002-11-13 12:45:41,503 ERROR [STDERR] at java.lang.reflect.Method.invoke(Native Method)
2002-11-13 12:45:41,514 ERROR [STDERR] at org.jboss.mx.capability.ReflectedMBeanDispatcher.invoke(ReflectedMBeanDispatcher.java:284)
2002-11-13 12:45:41,524 ERROR [STDERR] at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:517)
2002-11-13 12:45:41,536 ERROR [STDERR] at org.jboss.system.ServiceController$ServiceProxy.invoke(ServiceController.java:976)
2002-11-13 12:45:41,546 ERROR [STDERR] at $Proxy0.start(Unknown Source)
2002-11-13 12:45:41,557 ERROR [STDERR] at org.jboss.system.ServiceController.start(ServiceController.java:397)
2002-11-13 12:45:41,558 ERROR [STDERR] at java.lang.reflect.Method.invoke(Native Method)
2002-11-13 12:45:41,559 ERROR [STDERR] at org.jboss.mx.capability.ReflectedMBeanDispatcher.invoke(ReflectedMBeanDispatcher.java:284)
2002-11-13 12:45:41,560 ERROR [STDERR] at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:517)
2002-11-13 12:45:41,562 ERROR [STDERR] at org.jboss.util.jmx.MBeanProxy.invoke(MBeanProxy.java:174)
2002-11-13 12:45:41,563 ERROR [STDERR] at $Proxy3.start(Unknown Source)
2002-11-13 12:45:41,564 ERROR [STDERR] at org.jboss.deployment.SARDeployer.start(SARDeployer.java:249)
2002-11-13 12:45:41,565 ERROR [STDERR] at org.jboss.deployment.MainDeployer.start(MainDeployer.java:802)
2002-11-13 12:45:41,566 ERROR [STDERR] at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:616)
2002-11-13 12:45:41,568 ERROR [STDERR] at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:580)
2002-11-13 12:45:41,569 ERROR [STDERR] at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:564)
2002-11-13 12:45:41,571 ERROR [STDERR] at java.lang.reflect.Method.invoke(Native Method)
2002-11-13 12:45:41,572 ERROR [STDERR] at org.jboss.mx.capability.ReflectedMBeanDispatcher.invoke(ReflectedMBeanDispatcher.java:284)
2002-11-13 12:45:41,573 ERROR [STDERR] at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:517)
2002-11-13 12:45:41,574 ERROR [STDERR] at org.jboss.system.server.ServerImpl.doStart(ServerImpl.java:324)
2002-11-13 12:45:41,576 ERROR [STDERR] at org.jboss.system.server.ServerImpl.start(ServerImpl.java:221)
2002-11-13 12:45:41,577 ERROR [STDERR] at org.jboss.Main.boot(Main.java:148)
2002-11-13 12:45:41,579 ERROR [STDERR] at org.jboss.Main$1.run(Main.java:381)
2002-11-13 12:45:41,581 ERROR [STDERR] at java.lang.Thread.run(Thread.java:512) -
4. Re: IBM VM installation
hoos Nov 13, 2002 6:56 PM (in response to jbone)Hello, we reverted back to IBM 1.3.0 after running into this problem, has anyone made any progress here?
-
5. Re: IBM VM installation
sdossey Nov 14, 2002 11:59 PM (in response to jbone)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.] -
6. Re: IBM VM installation
sdossey Nov 15, 2002 12:02 AM (in response to jbone)---------------------------------------------------------
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.] -
7. Re: IBM VM installation
sdossey Nov 15, 2002 12:10 AM (in response to jbone)This is the aforementioned attachment to fix the problem.
-Scott Dossey
seveirein@yahoo.com -
8. Re: IBM VM installation
sdossey Nov 15, 2002 4:32 AM (in response to jbone)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