JBoss5: не Может развернуться из-за java.util.zip. ZipException: ошибка во вводном zip-файле

Я видел это когда FTP'ing файл с набором режима передачи к ASCII вместо двоичного файла.

Я просто обнаружил, что, если Вы не указываете номер версии в военном плагине знатока, он будет использовать некоторую альфа-версию. дайте ему номер версии 2.0 для меня, который работал.

У меня также есть это, но когда я добавляю военный плагин знатока и maven-ejb-plugin к моим проектам, все работает снова...

попробуйте платформу веб-инструментов (WTP) установки от обновления затмения... Я слышал, что была некоторая ошибка, Вам будет нужна версия 3.0.4. Я не могу найти ссылку, извините... надеяться, что это поможет!

Могут Вы для открытия файла уха за пределами JBoss (использующий WinZip или WinRAR)? Могло случиться так, что zip-файл повреждается.

Вы могли попытаться писать немного тестовой программы с помощью java.util.zip. ZipFile.open () и видят, можно ли отладить это в большем частном случае.

Иногда эта ошибка отображается из-за того, что версия компиляции jar / ear отличается от версии jdk на сервере.

Это могло быть проблемой полномочий? Я вижу, что Вы работаете в соответствии с Mac OS. Когда Вы успешно открываете файл EAR, какого пользователя Вы выполняете как? Когда Вы выполняете JBoss, какого пользователя он выполняет как? Это имеет доступ для чтения к файлу?

Хорошо, я наконец нашел решение своей проблемы. Кажется, что существует ошибка в Eclipse, которые предотвращают создание .settings/org.eclipse.wst.common.component файла. Этот файл должен быть создан при установке EJB3 и фасетов Java6 в свойствах проекта.

Вот org.eclipse.wst.common.component файл в качестве примера:

<?xml version="1.0" encoding="UTF-8"?>
<project-modules id="moduleCoreId" project-version="1.5.0">
    <wb-module deploy-name="project_name">
        <wb-resource deploy-path="/" source-path="/src/main/java"/>
        <wb-resource deploy-path="/" source-path="/src/main/resources"/>
        <wb-resource deploy-path="/" source-path="/src/test/java"/>
        <wb-resource deploy-path="/" source-path="/src/test/resources"/>
        <property name="java-output-path"/>
    </wb-module>
</project-modules>

Развернуть пути должны быть определены, чтобы смочь создать файл Банки EJB, используемый сервером на развертывании. После того, как созданный, Jboss публикуют модуль EJB правильно.

I have experienced the same problem with JBoss 5.1.0.GA and Seam 2.1.1.GA. The JDK is java jdk1.6.0._07 for both Eclipse 3.5 and JBoss.

I was able to fix the problem. Maybe the origin of the problem has to do with you concrete case, or may not, but in any event, I thought that it may help.

I am creating the application EAR file using the build file that is included in the Seam installation examples; my build file it is a modified version of the one that comes with the bookings example. This sampl build file does an include to the build file that is common to all examples. It provides a lot of functionality that you can take advantage to create your distribution files.

The common build examples offers several fileset and path entries that you can override to include the libraries that are unique to your project.

Concretely, I was overriding "build.classpath.extras" and "ear.lib.extras".

I wanted to include a determined library in the EJB jar file that gets packaged into the EAR file (the jar file where my model and action classes are); so I just overrided "jar.extras" in my build file.

At that time is when I suffered this problem. Although my desired library in the root was copied into the root folder of the EJB jar file, apparently without problems, JBoss was dropping this error message.

So I just stopped using "jar.extras", and I moved the reference to the desired library to "build.classpath.extras": the effect of this action was that the the library was copied to the \lib folder of the EAR file. Now the application seems to work well, and the problem dissapeared.

Well, I'm facing the same problem for three days.. look at your classpath for files with .rar extentions or another type of these files, in my case, I remove a .rar file from my classpath and everthing works great.

У меня была та же проблема, мое решение / проблема заключалась в том, что я добавил банку, которая вызывала проблема как EE-зависимость в моем EJB. Jar-файл был включен в файл EAR, но не был в соответствующем файле org.eclipse.wst.common.component. Я добавил зависимость в файл EAR, и моя проблема была решена (по крайней мере, я думаю, у меня возникла проблема после того, как я сделал это с помощью eclipse, но когда я решил ее, публикация прошла нормально).

Проблема, скорее всего, в низкоуровневом формате ZIP-файла, возможно, в результате попытки JBoss развернуть частично загруженный архив,

Caused by: 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:203)
    at java.util.zip.ZipFile.<init>(ZipFile.java:234

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

Я развертываю архивы с помощью rsync'а в ~ / deployment-unit /, а затем запускаю удаленный скрипт через ssh, чтобы сделать последний переход в каталог развертывания JBoss.

У меня была такая же проблема на моем Mac. Моя машина для разработки Windows (клиент на работе: - /) слишком медленная, чтобы запускать GateIN и eclipse, поэтому я установил GateIN на свой Macbooc Pro и позволил eclipse скопировать на него ухо после сборки. Я видел на консоли: исключение в zip.

Я решил выяснить, могу ли я открыть архив с помощью Stuffit Manager. В тот момент, когда я его открыл, очевидно, что файл каким-то образом «тронул», и сканер GateIN, обнаружив изменение, сразу же развернул заново, на этот раз без ошибок. Так что я полагаю, что Mac был слишком быстрым, чтобы попытаться выполнить повторное развертывание до того, как ухо было полностью скопировано ... Если у вас возникла проблема, просто используйте сенсорную команду ...

Я решил эту проблему, запустив сервер с тем же JDK, который я использовал для компиляции/сборки EAR.

Я видел, что вложенные банки тоже так делают (банка внутри другой банки или пустая банка). В моем случае это был microsoft sql jdbc driver jar. У ОП, похоже, это TwitterPoCEJB.jar, судя по трассировке стека.

Есть много вещей, которые могут вызвать это, хотя, как упоминалось ранее, просто плохой zip и т.д..

Если это проблема вложенных jar, вы можете указать VFS, какие места содержат вложенные jar, хотя по умолчанию каталог ./deploy является одним из них, так что все, что там находится, должно быть в порядке (если только у вас нет jboss-{something}.xml, явно настраивающего все иначе).

Я получил очень похожую ошибку, и это было связано с достижением максимального количества открытых файлов. Я запустил приложение после ulimit -n 8192, и оно смогло "распаковать" файл.