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:

[EMAIL PROTECTED] 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 [EMAIL PROTECTED]

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

_______________________________________________
kaffe mailing list
[EMAIL PROTECTED]
http://kaffe.org/cgi-bin/mailman/listinfo/kaffe

Reply via email to