java.util.zip.ZipException в развертывании приложения Glassfish (v3)

У меня есть странное исключение с моим приложением EJB3.1, во время развертывания приложения выдается ZipException:

[#|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 com.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)
|#]

Я действительно не знаю, как исследовать эту ошибку; Я знаю, что это не связано с установкой Glassfish (такая же проблема на Ubuntu и Mac).


EDIT: (детали classpath кажутся бесполезными)

проблема с .../WebAlbums3-ea/dist/gfdeploy/WebAlbums3-Service.jar заключается в том, что этого файла на самом деле нет там, где его ищет Glassfish... Вместо этого у меня есть папка с именем WebAlbums3-Service_jar


(Я использую Netbeans 6.8, Glassfish v3, Servlet3, EJB 3.1, JPA/Hibernate)

Спасибо за помощь

EDIT: Проблема (как с ZipException, так и с уже загруженными EJB) была решена путем извлечения интерфейсов EJB вне того места, где была определена реализация (классы реализации загружались с каждым из модулей, отсюда и исключение EJB)


person Kevin    schedule 15.05.2010    source источник
comment
Что бы это ни стоило, я время от времени получаю подобное исключение при развертывании под SpringSource dm Server. Это происходит всегда или только иногда?   -  person Eric J.    schedule 15.05.2010
comment
нет, это действительно для всех моих развертываний   -  person Kevin    schedule 15.05.2010
comment
Наличие «_» вместо «.» нормально, когда вы используете разнесенное развертывание (именно так должен быть развернут разнесенный артефакт).   -  person Pascal Thivent    schedule 15.05.2010
comment
Может ли это произойти, если GlassFish начнет развертывание до завершения копирования файла? Медленная загрузка?   -  person Thorbjørn Ravn Andersen    schedule 21.05.2010
comment
@ Thorbjørn нет, я так не думаю, это действительно происходит постоянно, даже если здание было закончено задолго до этого   -  person Kevin    schedule 22.05.2010
comment
Прежде всего, проверьте файл jar с помощью unzip -t. Он действительно может быть сломан!   -  person Thorbjørn Ravn Andersen    schedule 22.05.2010
comment
нет, нет, взгляните на другие ответы/комментарии, это не банка, это папка, которая используется   -  person Kevin    schedule 22.05.2010


Ответы (4)


Я видел несколько упоминаний об этой проблеме в Интернете, например это который упоминает его как неблокирующий:

Если вы получите следующую ошибку после развертывания EAR, не волнуйтесь, это вполне нормально: «WEB9051: Ошибка при попытке сканирования классов в .../eclipseApps/Seven/SevenEJB.jar на наличие аннотаций, в которых ServletContainerInitializer выразил интерес ". Глянь сюда.

А также в проблеме 11149 или Ошибка 11341. Ваш случай кажется другим, но если это не так (если у вас есть банка со знаком «+» в имени файла), это должно быть исправлено в GF v3.0.1.

Если это не относится к вам, я предлагаю создать задачу. Даже если не блокируется, это явно не нормально.

person Pascal Thivent    schedule 15.05.2010
comment
В именах банок нет +, так что это действительно другое, и в моем случае это также не блокирует. Я поднял ‹a href=glassfish.dev.java .net/issues/ 11911‹/a›. Спасибо! - person Kevin; 15.05.2010
comment
хм, как мне вручную развернуть мой проект ea-project? когда я развертываю EAR, я получаю исключение (2 ejb с одним и тем же интерфейсом - неправда, я имею в виду, что это проблема упаковки), тогда как развертывание Netbeans?path=.../WebAlbums3-ea/dist/gfdeploy в порядке (Я хотел присоединиться к этому EAR с отчетом о проблеме) - person Kevin; 15.05.2010
comment
@Kevin Самый простой способ - скопировать его в каталог autodeploy вашего домена. - person Pascal Thivent; 16.05.2010
comment
нет, это та же проблема, EJB видны как «дублированные», (Servlet-›Service-›DAO) EJB в DAO будут видны 3 раза, а в Service дважды... - person Kevin; 16.05.2010
comment
@Kevin Вы уверены, что код netbeans не развернут? Что вы видите в консоли администратора GlassFish в разделе «Приложения»? - person Pascal Thivent; 16.05.2010
comment
@Pascal, да, я уверен, я только что все удалил, снова возникает то же исключение ... - person Kevin; 17.05.2010

Ошибка при попытке сканирования классов в /Users/kevin/Documents/netbeans/WebAlbums/trunk/WebAlbums3/WebAlbums3-ea/dist/gfdeploy/WebAlbums3-Service.jar на наличие аннотаций, в которых ServletContainerInitializer выразил интерес

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

Похоже, файл JAR поврежден. Перекомпилируйте/замените его. Если вы используете FTP во время развертывания, позаботьтесь о том, чтобы отправлять двоичные файлы как двоичные данные, а не как текстовые данные.

Это также может быть вызвано тем, что временное хранилище заполнено или недоступно для записи.

Обновление: Google узнал, что это также может быть связано с JDK. Попробуйте обновить JDK до последней версии.

person BalusC    schedule 15.05.2010
comment
если вы про WebAlbums3-Service.jar, то этого не может быть, это основной jar моего приложения, он каждый день перекомпилируется, а не переносится (netbeans/glassfish на одном компьютере); проблем с местом тоже нет... - person Kevin; 15.05.2010
comment
Как бы то ни было, когда у меня была аналогичная проблема с SpringServer, банка не была повреждена. Повторное развертывание обычно работает. - person Eric J.; 15.05.2010
comment
У меня есть обновленные JDK, OpenJDK 1.0_18 на Ubuntu, HotSpot 1.6.0_17 на Mac - person Kevin; 15.05.2010
comment
Это была моя проблема. Быстрый просмотр файла ‹jarfile.jar› показал, что у меня текстовый файл, а не jar. - person nettie; 09.08.2017

Можете ли вы открыть zip-файл с помощью winzip или 7zip? Можете ли вы открыть файл программно, используя ZipFile? Я уверен, что один из этих вопросов будет оценен как ложный.

Некоторое время назад у меня были странные zip-ошибки, связанные со специальными символами в именах содержащихся файлов (где специальные средства, не-ASCII-символы).

person Daniel    schedule 15.05.2010
comment
На самом деле это не zip-файл, OP использует развернутое развертывание. - person Pascal Thivent; 15.05.2010

Наличие «_» вместо «.» нормально, когда вы используете разнесенное развертывание (именно так должен быть развернут разнесенный артефакт)

Это может быть «нормально», но GF ищет файл myEJB.jar, которого там нет. Есть только взорванный артефакт, который потом не разворачивается.

Проблема (как ZipException, так и уже загруженные EJB) была решена путем извлечения интерфейсов EJB вне того места, где была определена реализация (классы реализации были загружены с каждым из модулей, следовательно, исключение EJB)

Не уверен, что понимаю, как это лечит вышеуказанную проблему. Мой класс реализации — это отдельный bean-компонент сообщений.

person RogerP    schedule 06.01.2011
comment
я чувствую, что извлечение интерфейсов решило проблему, потому что 1-я реализация не следовала «рекомендациям», отсюда и неожиданное поведение, но, возможно, это было просто совпадение! - person Kevin; 06.01.2011