lairtonb / jspf

Automatically exported from code.google.com/p/jspf
0 stars 0 forks source link

classpath search ends with " java.util.zip.ZipException: error in opening zip file" #23

Closed GoogleCodeExporter closed 8 years ago

GoogleCodeExporter commented 8 years ago
I created a jar containing a class TestPlugin implementing IPlugin which 
extends the Plugin interface from jspf. This jar is deployed within an EAR.  I 
call an EJB method which starts the PluginManager and tries to add plugins from 
the classpath via 

pm.addPluginsFrom(new URI("classpath://*"));

This results in "ERROR [STDERR] java.util.zip.ZipException: error in opening 
zip file". The jar file has the following content:

$ jar tf lib/plugintest.jar
META-INF/
META-INF/MANIFEST.MF
com/
com/company/
com/company/app/
com/company/app/examples/
com/company/app/examples/plugintest/
com/company/app/examples/plugintest/IPlugin.class
com/company/app/examples/plugintest/TestPlugin.class

- jspf-0.9.0
- latest Java 1.6
- latest Mac OS X 10.6
- jboss 5.1.0.GA

Is this an issue or just me not seeing the problem?

Original issue reported on code.google.com by saschafr...@gmail.com on 16 Nov 2010 at 11:06

GoogleCodeExporter commented 8 years ago
See the attachment, its the Eclipse test project to reproduce the problem. 
Import it to Eclipse and deploy it to JBoss.

Original comment by saschafr...@gmail.com on 16 Nov 2010 at 11:34

Attachments:

GoogleCodeExporter commented 8 years ago
[deleted comment]
GoogleCodeExporter commented 8 years ago
[deleted comment]
GoogleCodeExporter commented 8 years ago
Can you try if the problem persists with 0.9.1beta, and can you also create 
your PluginManager like this:

JSPFProperties pros = new JSPFProperties();
pros.setProperty(PluginManager.class, "logging.level", "ALL");
... = PluginManagerFactory.createPluginManager(pros);

and append a file with the logging output? 

Original comment by r.biedert on 16 Nov 2010 at 6:01

GoogleCodeExporter commented 8 years ago
The log file is attached.

I tried to deploy the EAR as packaged and as exploded bundle, but that doesn't 
matter, the exception is still there (although it seems not to be critical, 
because I get the expected output on client side).

Original comment by saschafr...@gmail.com on 17 Nov 2010 at 12:16

Attachments:

GoogleCodeExporter commented 8 years ago
Given the appended log trace, the error is thrown while processing a "strange" 
JAR. The ZipException is caught with the IOException clause in 
JARClasspathLocation.listAllEntriesFor(). 

The classpath://* search does not end at this step, the exception is first 
printed and then handled gracefully. 

Because we cannot change Java's internal ZIP handling and because errors with 
JARs should be reported, I am closing this issue (not a bug). Please comment if 
you disagree. 

Original comment by r.biedert on 17 Nov 2010 at 1:13