0

During EAR install, getting NestedJarException: IWAE0008E An error occurred reading Intranet_PropertyService.jar from C:\IBM\SDP75\runtimes\base_v7\profiles\AppSrv01\wstemp\910481153\upload\...

I'm running IBM RAD v7.5.5.5/WAS 7. I've loaded my projects into the IDE/workspace. All the projects build with no problems showing. I added my EAR to the server. With the server started I try to access my app and get "webpage cannot be found" (aka error 404). The console frame shows no activity for that request. So I go into the admin console > Applications > Application types > Websphere enterprise applications and check the status of the EAR. It shows as '?'. So I attempt to start it and it says that 'Start is not a valid operation for the" EAR. So, I right-click on the server and remove the EAR from the server and then return to the admin console and attempt to install the EAR. At the end of the install process, I get:

[2/26/16 6:33:52:558 PST] 0000002b SystemErr     R org.eclipse.jst.j2ee.commonarchivecore.internal.exception.NestedJarException: IWAE0008E An error occurred reading Intranet_PropertyService.jar from C:\IBM\SDP75\runtimes\base_v7\profiles\AppSrv01\wstemp\910481153\upload\RateToolEAR.ear
Stack trace of nested exception:
java.util.zip.ZipException: invalid entry CRC (expected 0xee027fb2 but got 0x55f10074)
    at java.util.zip.ZipInputStream.read(ZipInputStream.java:190)

This is a test machine. I've uninstalled & reinstalled the RAD/WAS application w/o change to the result. When I attempted to install EAR file in question (via the admin console) came from a machine that does not have this problem so the EAR is not "polluted" by this test machine's environment. That other machine is the lead developer's and is daily creating working copy of this application.

I've repeatedly deleted the workspace and recreated it/imported the projects w/o change to the result.

I am able to open the EAR using WinRAR w/o error. I've searched the internet for any possible solutions but am coming up with nothing. Please, does anyone have suggestions to try or actual solutions?

CubeJockey
  • 2,209
  • 8
  • 24
  • 31
Mark
  • 81
  • 12

2 Answers2

2

There are two ways to read a zip file:

  1. Read it as a "stream" of zip entries (ZipInputStream)
  2. Read the central directory and use that to locate entries (ZipFile, WinRAR, etc.).

It is possible to build "irregular" zip/archive files that contain inconsistent data in the stream of entries compared to the central directory (or even "junk" bytes between entries), which will cause the first approach to fail. The validity of such zip files is unclear, but it appears WebSphere Application Server expects this approach to work. This might be considered a bug (or at least a quality of implementation issue), so you could open a PMR with IBM. Alternatively, you can likely work around the issue by manually unzipping and rezipping the archive (perhaps recursively).

Brett Kail
  • 33,593
  • 2
  • 85
  • 90
  • Thanks Brett. It sounds like you're suggesting that I need to write a different method to read the JARs and/or EAR (that's different than the IDE's built-in method). The error generated is coming from RAD's IDE, not from a method written as part of this app. The EAR contains other projects that were written for the application as well as "standard" development JARs. Are you suggesting that there is a CRC problem in those standard JARs or the generated EAR? How can that be since one test was done using an EAR exported from the machine that's reporting no EAR errors? – Mark Feb 29 '16 at 14:14
  • The code that would need to change is part of WebSphere Application Server. The only thing that comes to mind to try is to rezip the archives to avoid "stream" errors, even though there might not be "central directory" errors. I do not know why the problem only happens in one environment. Perhaps full stack trace with all causing/nested exceptions (rather than the single ZipInputStream line) would help explain that. – Brett Kail Feb 29 '16 at 14:31
0

The answer to this issue was I needed to rebase the stream (from the ClearCase repository). There were changes between the time I "initially" installed the source code's view (from ClearCase) and when I rebased it (that eliminated the issue). The thing to consider is the other developer who is primary developer for this application's source code never had this problem so this problem cannot be dismissed that there was just a problem in the source code. There was something else going on "in the background" that was remedied by a "refresh" of the code.

Thanks all for the help.

Mark
  • 81
  • 12