cancel
Showing results for 
Search instead for 
Did you mean: 

Archives corrupted after redeployment

Former Member
0 Kudos

Hello everybody,

we're migrating our application from JBoss to SAP Web AS 7.05 SP0 and are facing a problem which seems to be related to container's deployment behavior:

The first time our EAR-file is deployed via deploy.bat all unit-tests finish successfully.

But after deploying the app again (even if the app has not been rebuilded) the following error comes up:

java.lang.InternalError: jzentry == 0,

jzfile = 911870992,

total = 186,

name = C:\usr\sap\CE1\J01\j2ee\cluster\apps\mycomp.com\myapp.core\app_libraries_container\myjar-1.0.27.2.jar,

i = 158,

message = invalid LOC header (bad signature)

at java.util.zip.ZipFile$3.nextElement(ZipFile.java:454)

at java.util.zip.ZipFile$3.nextElement(ZipFile.java:440)

at java.util.jar.JarFile$1.nextElement(JarFile.java:221)

at java.util.jar.JarFile$1.nextElement(JarFile.java:220)

at org.springframework.core.io.support.PathMatchingResourcePatternResolver.doFindPathMatchingJarResources(PathMatchingResourcePatternResolver.java:418)

at org.springframework.core.io.support.PathMatchingResourcePatternResolver.findPathMatchingResources(PathMatchingResourcePatternResolver.java:318)

at org.springframework.core.io.support.PathMatchingResourcePatternResolver.getResources(PathMatchingResourcePatternResolver.java:242)

It seems that spring is not able to load it's context.xml files from the jar-files deployed with the application (in this case myjar-1.0.27.2.jar). But why? After restarting the instance everything works fine again - but only once until the app is redeployed.

Is it possible that redeployment is corrupting archives that already exist in deployment directory?

We tried to undeploy (Telnet REMOVE_APP myapp.core) before redeployment and noticed that not all of the jars existing under C:\usr\sap\CE1\J01\j2ee\cluster\apps\mycomp.com\myapp-core\app_libraries_container where deleted including myjar-1.0.27.2.jar which holds the spring context.xml's and causes the exception described above.

Can anybody help?

Best Regards

Helge

Accepted Solutions (1)

Accepted Solutions (1)

anton_georgiev
Discoverer
0 Kudos

Hi Helge,

Please remove the application, restart Java AS and make sure the application folder is empty before continuing.

1). try to reproduce the issue without executing the unit test

1.1). if not reproducible this might be unit test issue

1.2). if reproducible try to reproduce the issue without executing the unit test and without starting the application after each deployment (see "deploy" cmd in telnet and its help)

1.2.1). if not reproducible this might be application issue

1.2.1.1). is there application logic like following -> InputStream is = (new Object()).getClass().getClassLoader().getResourceAsStream("my_resource"); -> How about -> is.close() in finally;

1.2.2). if reproducible please describe us how to reproduce the issue locally

Kind Regards,

Anton.

Answers (1)

Answers (1)

Former Member
0 Kudos

Hello Anton.

Thank you for the helpful hint. We follow that track and then post the solution.

Regards,

Helge