[kaffe] jboss vs. java.util.zip

[Helmer Krämer]

Hi all,

I tried to find out why it was necessary to modify java.util.zip in
order to get jboss to run, and the results were a bit surprising.

The exception that is thrown when the patch is not applied is this
one:

java.io.IOException: Bogus signature: 0x6d783f3c
   at java.util.zip.ZipInputStream.getNextEntry (ZipInputStream.java:52)
   at org.jboss.mx.loading.ClassLoaderUtils$ClassPathIterator.getNextEntry (ClassLoaderUtils.java:533)
   at org.jboss.mx.loading.ClassLoaderUtils.updatePackageMap (ClassLoaderUtils.java:245)
   at org.jboss.mx.loading.ClassLoaderUtils.updatePackageMap (ClassLoaderUtils.java:179)
   at org.jboss.mx.loading.UnifiedLoaderRepository3.updatePackageMap (UnifiedLoaderRepository3.java:651)
   at org.jboss.mx.loading.UnifiedLoaderRepository3.addUnifiedClassLoader (UnifiedLoaderRepository3.java:633)
   at org.jboss.mx.loading.UnifiedLoaderRepository3.addClassLoader (UnifiedLoaderRepository3.java:572)
   at org.jboss.mx.loading.UnifiedLoaderRepository3.registerClassLoader (UnifiedLoaderRepository3.java:796)
   at org.jboss.mx.loading.UnifiedLoaderRepository3.newClassLoader (UnifiedLoaderRepository3.java:134)
   at java.lang.reflect.Method.invoke0 (Method.java)
   at java.lang.reflect.Method.invoke (Method.java:255)
   at org.jboss.mx.capability.ReflectedMBeanDispatcher.invoke (ReflectedMBeanDispatcher.java:284)
   at org.jboss.mx.server.MBeanServerImpl.invoke (MBeanServerImpl.java:546)
   at org.jboss.deployment.DeploymentInfo.createClassLoaders (DeploymentInfo.java:223)
   at org.jboss.deployment.MainDeployer.init (MainDeployer.java:688)
   at org.jboss.deployment.MainDeployer.deploy (MainDeployer.java:629)
   at org.jboss.deployment.MainDeployer.deploy (MainDeployer.java:605)
   at org.jboss.deployment.MainDeployer.deploy (MainDeployer.java:589)
   at java.lang.reflect.Method.invoke0 (Method.java)
   at java.lang.reflect.Method.invoke (Method.java:255)
   at org.jboss.mx.capability.ReflectedMBeanDispatcher.invoke (ReflectedMBeanDispatcher.java:284)
   at org.jboss.mx.server.MBeanServerImpl.invoke (MBeanServerImpl.java:546)
   at org.jboss.mx.util.MBeanProxyExt.invoke (MBeanProxyExt.java:177)
   at $Proxy5.deploy (source file unknown)
   at org.jboss.system.server.ServerImpl.doStart (ServerImpl.java:384)
   at org.jboss.system.server.ServerImpl.start (ServerImpl.java:291)
   at org.jboss.Main.boot (Main.java:150)
   at org.jboss.Main$1.run (Main.java:388)
   at java.lang.Thread.run (Thread.java:310)

Inspecting the bogus signature a little bit more, I found out that
0x6d783f3c is "<?xm", which looks a lot like the first four bytes
of an xml file.

In order to debug this a little bit more, I inserted a few debugging
messages:

java.io.FileInputStream at 8685dbc is for /cvsstuff/tmp/jboss-3.2.2RC4/server/default/tmp/deploy/tmp1067099841870jboss-service.xml
java.lang.Throwable
   at java.lang.Thread.dumpStack (Thread.java:157)
   at java.io.FileInputStream.<init> (FileInputStream.java:111)
   at org.jboss.mx.loading.ClassLoaderUtils$ClassPathIterator.<init> (ClassLoaderUtils.java:516)
   at org.jboss.mx.loading.ClassLoaderUtils.updatePackageMap (ClassLoaderUtils.java:177)
   at org.jboss.mx.loading.UnifiedLoaderRepository3.updatePackageMap (UnifiedLoaderRepository3.java:651)
   at org.jboss.mx.loading.UnifiedLoaderRepository3.addUnifiedClassLoader (UnifiedLoaderRepository3.java:633)
   at org.jboss.mx.loading.UnifiedLoaderRepository3.addClassLoader (UnifiedLoaderRepository3.java:572)
   at org.jboss.mx.loading.UnifiedLoaderRepository3.registerClassLoader (UnifiedLoaderRepository3.java:796)
   at org.jboss.mx.loading.UnifiedLoaderRepository3.newClassLoader (UnifiedLoaderRepository3.java:134)
   at java.lang.reflect.Method.invoke0 (Method.java)
   at java.lang.reflect.Method.invoke (Method.java:255)
   at org.jboss.mx.capability.ReflectedMBeanDispatcher.invoke (ReflectedMBeanDispatcher.java:284)
   at org.jboss.mx.server.MBeanServerImpl.invoke (MBeanServerImpl.java:546)
   at org.jboss.deployment.DeploymentInfo.createClassLoaders (DeploymentInfo.java:223)
   at org.jboss.deployment.MainDeployer.init (MainDeployer.java:688)
   at org.jboss.deployment.MainDeployer.deploy (MainDeployer.java:629)
   at org.jboss.deployment.MainDeployer.deploy (MainDeployer.java:605)
   at org.jboss.deployment.MainDeployer.deploy (MainDeployer.java:589)
   at java.lang.reflect.Method.invoke0 (Method.java)
   at java.lang.reflect.Method.invoke (Method.java:255)
   at org.jboss.mx.capability.ReflectedMBeanDispatcher.invoke (ReflectedMBeanDispatcher.java:284)
   at org.jboss.mx.server.MBeanServerImpl.invoke (MBeanServerImpl.java:546)
   at org.jboss.mx.util.MBeanProxyExt.invoke (MBeanProxyExt.java:177)
   at $Proxy5.deploy (source file unknown)
   at org.jboss.system.server.ServerImpl.doStart (ServerImpl.java:384)
   at org.jboss.system.server.ServerImpl.start (ServerImpl.java:291)
   at org.jboss.Main.boot (Main.java:150)
   at org.jboss.Main$1.run (Main.java:388)
   at java.lang.Thread.run (Thread.java:310)
inputstream is java.io.FileInputStream at 8685dbc

So the underlying input stream of the ZipInputStream that
throws the IOException is indeed an xml file. No clue why
they're doing this, but it means that the exception is not
thrown because of some bug in the implementation of kaffe
or of classpath.

Regards,
Helmer