java.util.zip.ZipException in Glassfish (v3) application deployment

I've got a strange exception with my EJB3.1 application, a ZipException is thrown during the application deployment:

[#|2010-05-15T16:01:44.688+0100|SEVERE|glassfish3.0.1|javax.enterprise.system.container.web.org.glassfish.web.loader|_ThreadID=22;_ThreadName=Thread-1;|WEB9051: Error trying to scan the classes at /Users/kevin/Documents/netbeans/WebAlbums/trunk/WebAlbums3/WebAlbums3-ea/dist/gfdeploy/WebAlbums3-Service.jar for annotations in which a ServletContainerInitializer has expressed interest
java.util.zip.ZipException: error in opening zip file
    at java.util.zip.ZipFile.open(Native Method)
    at java.util.zip.ZipFile.<init>(ZipFile.java:114)
    at java.util.jar.JarFile.<init>(JarFile.java:133)
    at java.util.jar.JarFile.<init>(JarFile.java:70)
    at org.glassfish.web.loader.ServletContainerInitializerUtil.getInitializerList(ServletContainerInitializerUtil.java:255)
    at org.apache.catalina.core.StandardContext.callServletContainerInitializers(StandardContext.java:5331)
    at com.sun.enterprise.web.WebModule.callServletContainerInitializers(WebModule.java:550)
    at org.apache.catalina.core.StandardContext.start(StandardContext.java:5263)
    at com.sun.enterprise.web.WebModule.start(WebModule.java:499)
    at org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBase.java:928)
    at org.apache.catalina.core.ContainerBase.addChild(ContainerBase.java:912)
    at org.apache.catalina.core.StandardHost.addChild(StandardHost.java:694)
    at com.sun.enterprise.web.WebContainer.loadWebModule(WebContainer.java:1947)
    at com.sun.enterprise.web.WebContainer.loadWebModule(WebContainer.java:1619)
    at com.sun.enterprise.web.WebApplication.start(WebApplication.java:90)
    at org.glassfish.internal.data.EngineRef.start(EngineRef.java:126)
    at org.glassfish.internal.data.ModuleInfo.start(ModuleInfo.java:241)
    at org.glassfish.internal.data.ApplicationInfo.start(ApplicationInfo.java:236)
    at com.sun.enterprise.v3.server.ApplicationLifecycle.deploy(ApplicationLifecycle.java:339)
    at com.sun.enterprise.v3.server.ApplicationLifecycle.deploy(ApplicationLifecycle.java:183)
    at org.glassfish.deployment.admin.DeployCommand.execute(DeployCommand.java:272)
    at com.sun.enterprise.v3.admin.CommandRunnerImpl$1.execute(CommandRunnerImpl.java:305)
    at co开发者_开发问答m.sun.enterprise.v3.admin.CommandRunnerImpl.doCommand(CommandRunnerImpl.java:320)
    at com.sun.enterprise.v3.admin.CommandRunnerImpl.doCommand(CommandRunnerImpl.java:1176)
    at com.sun.enterprise.v3.admin.CommandRunnerImpl.access$900(CommandRunnerImpl.java:83)
    at com.sun.enterprise.v3.admin.CommandRunnerImpl$ExecutionContext.execute(CommandRunnerImpl.java:1235)
    at com.sun.enterprise.v3.admin.CommandRunnerImpl$ExecutionContext.execute(CommandRunnerImpl.java:1224)
    at com.sun.enterprise.v3.admin.AdminAdapter.doCommand(AdminAdapter.java:365)
    at com.sun.enterprise.v3.admin.AdminAdapter.service(AdminAdapter.java:204)
    at com.sun.grizzly.tcp.http11.GrizzlyAdapter.service(GrizzlyAdapter.java:166)
    at com.sun.enterprise.v3.server.HK2Dispatcher.dispath(HK2Dispatcher.java:100)
    at com.sun.enterprise.v3.services.impl.ContainerMapper.service(ContainerMapper.java:245)
    at com.sun.grizzly.http.ProcessorTask.invokeAdapter(ProcessorTask.java:791)
    at com.sun.grizzly.http.ProcessorTask.doProcess(ProcessorTask.java:693)
    at com.sun.grizzly.http.ProcessorTask.process(ProcessorTask.java:954)
    at com.sun.grizzly.http.DefaultProtocolFilter.execute(DefaultProtocolFilter.java:170)
    at com.sun.grizzly.DefaultProtocolChain.executeProtocolFilter(DefaultProtocolChain.java:135)
    at com.sun.grizzly.DefaultProtocolChain.execute(DefaultProtocolChain.java:102)
    at com.sun.grizzly.DefaultProtocolChain.execute(DefaultProtocolChain.java:88)
    at com.sun.grizzly.http.HttpProtocolChain.execute(HttpProtocolChain.java:76)
    at com.sun.grizzly.ProtocolChainContextTask.doCall(ProtocolChainContextTask.java:53)
    at com.sun.grizzly.SelectionKeyContextTask.call(SelectionKeyContextTask.java:57)
    at com.sun.grizzly.ContextTask.run(ContextTask.java:69)
    at com.sun.grizzly.util.AbstractThreadPool$Worker.doWork(AbstractThreadPool.java:330)
    at com.sun.grizzly.util.AbstractThreadPool$Worker.run(AbstractThreadPool.java:309)
    at java.lang.Thread.run(Thread.java:637)
|#]

I don't really know how to investigate this error; I know that it's not related to the Glassfish installation (same problem on Ubuntu and Mac).

EDIT: (the classpath details seem to be useless)

the problem with .../WebAlbums3-ea/dist/gfdeploy/WebAlbums3-Service.jar is that this file is not actually present where Glassfish is looking for it ... Instead, I've got a folder named WebAlbums3-Service_jar

(I'm using Netbeans 6.8, Glassfish v3, Servlet3, EJB 3.1, JPA/Hibernate)

Thank you for your help

EDIT: The issue (both ZipException and already loaded EJBs) was resolved by extracting the EJB interfaces outside of where the implementation was defined (the implementation classes were loaded with each of the modules, hence the EJB exception)

I've seen several mentions of this problem on the web like this one that mentions it as non blocking:

If you get the following error after deploying the EAR, don't worry, it's quite normal: "WEB9051: Error trying to scan the classes at .../eclipseApps/Seven/SevenEJB.jar for annotations in which a ServletContainerInitializer has expressed interest". See here.

And also in Issue 11149 or Issue 11341. Your case seems to be different but if it's not (if you have a jar with a '+' in the file name) it should be fixed in GF v3.0.1.

If this doesn't apply to you, I suggest creating an issue. Even if non blocking, this is clearly not normal.

Error trying to scan the classes at /Users/kevin/Documents/netbeans/WebAlbums/trunk/WebAlbums3/WebAlbums3-ea/dist/gfdeploy/WebAlbums3-Service.jar for annotations in which a ServletContainerInitializer has expressed interest

java.util.zip.ZipException: error in opening zip file

Look like the JAR file is corrupted. Recompile/replace it. If you're FTP'ing this during deploying, take care that you send binary files as binary data, not as text data.

This can also be caused by the temp storage being full or not writable.

Update: Google learns me that this may also be JDK specific. Try upgrading JDK to the latest.

Can you open the zip-file with winzip or 7zip? Can you open the file programmatically using ZipFile? I am sure one of these questions will evaluate to false.

I had some strange zip errors some time ago related to special characters in the names of the contained file (where special means, non-ASCII characters).

Having an '_' instead of a '.' is normal when you use exploded deployment (that's how the exploded artifact is supposed to be deployed)

It may be "normal" but GF is looking for a myEJB.jar file that's not there. There's only an exploded artefact, which then doesn't get deployed.

The issue (both ZipException and already loaded EJBs) was resolved by extracting the EJB interfaces outside of where the implementation was defined (the implementation classes were loaded with each of the modules, hence the EJB exception)

Not sure I understand how this cures the above problem. My implementation class is a solitary message bean.