8 Replies Latest reply on Nov 15, 2002 4:32 AM by Scott Dossey

    IBM VM installation

    Jason Boorn Newbie

      I am trying to deploy jboss-3.03 with IBM VM 1.3.1 and get a zip exception on startup. Is there a setting I should change in config?

      Also get error with Xint in the JAVA_OPTS, but took that out.

      Thanks

        • 1. Re: IBM VM installation
          Jason Boorn Newbie

          Doing this on Linux 6.2

          • 2. Re: IBM VM installation
            Joel Vogt Master

            hmm whats the zip exception? Where is it thown?

            • 3. Re: IBM VM installation
              Jason Boorn Newbie

              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
                Hussein Badakhchani Newbie

                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
                  Scott Dossey Newbie

                  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
                    Scott Dossey Newbie

                    ---------------------------------------------------------
                    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
                      Scott Dossey Newbie

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

                      • 8. Re: IBM VM installation
                        Scott Dossey Newbie

                        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