This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.

Bug 35504

Summary: Jar file corrupted after recompile
Product: obsolete Reporter: John Baker <jbaker>
Component: jarpackagerAssignee: issues@obsolete <issues>
Status: RESOLVED DUPLICATE    
Severity: blocker    
Priority: P2    
Version: 3.x   
Hardware: Sun   
OS: Solaris   
Issue Type: DEFECT Exception Reporter:
Attachments: jarContent file
Original jarContent file
Source used to create the jarRecipe

Description John Baker 2003-08-20 02:46:26 UTC
Using Solaris 9, JDK 1.4.1_02

Jar Recipe was created by adding a com package
which contains
packages and class files. See attachment

The contents of a Jar file are replaced when doing
the following:

1) Mount a filesystem containing the jar recipe
2) Mount a 2nd filesystem
3) Copy the jar recipe to the 2nd filesystem
(check the contents of the Jar - it should be ok)

4) Recompile the Jar Recipe
5) Check the contents:

% jar tvf smart-ticket-client-jar.jar
     2 Tue Aug 19 18:15:18 PDT 2003
META-INF/MANIFEST.MF
  5884 Tue Aug 19 18:15:18 PDT 2003
com/sun/security/auth/SubjectCodeSource.class
   604 Tue Aug 19 18:15:18 PDT 2003
com/sun/security/auth/SubjectCodeSource$1.class
   706 Tue Aug 19 18:15:18 PDT 2003
com/sun/security/auth/SubjectCodeSource$2.class
  1895 Tue Aug 19 18:15:18 PDT 2003
com/sun/security/auth/PropertyExpander.class
   382 Tue Aug 19 18:15:18 PDT 2003
com/sun/security/auth/PropertyExpander$ExpandException.class
  2072 Tue Aug 19 18:15:18 PDT 2003
com/sun/security/auth/Debug.class
   470 Tue Aug 19 18:15:18 PDT 2003
com/sun/security/auth/Debug$1.class
  5237 Tue Aug 19 18:15:18 PDT 2003
com/sun/security/auth/Resources.class
  9337 Tue Aug 19 18:15:18 PDT 2003
com/sun/security/auth/PolicyParser.class
  2539 Tue Aug 19 18:15:18 PDT 2003
com/sun/security/auth/PolicyParser$GrantEntry.class
  1041 Tue Aug 19 18:15:18 PDT 2003
com/sun/security/auth/PolicyParser$ParsingException.class
  1734 Tue Aug 19 18:15:18 PDT 2003
com/sun/security/auth/PolicyParser$PermissionEntry.class
  1012 Tue Aug 19 18:15:18 PDT 2003
com/sun/security/auth/PolicyParser$PrincipalEntry.class
  1018 Tue Aug 19 18:15:18 PDT 2003
com/sun/security/auth/NTSidGroupPrincipal.class
  1560 Tue Aug 19 18:15:18 PDT 2003
com/sun/security/auth/SolarisNumericUserPrincipal.class
  1039 Tue Aug 19 18:15:18 PDT 2003
com/sun/security/auth/NTSidPrimaryGroupPrincipal.class
  1791 Tue Aug 19 18:15:18 PDT 2003
com/sun/security/auth/X500Principal.class
  1907 Tue Aug 19 18:15:18 PDT 2003
com/sun/security/auth/login/PropertyExpander.class
   394 Tue Aug 19 18:15:18 PDT 2003
com/sun/security/auth/login/PropertyExpander$ExpandException.class
  1415 Tue Aug 19 18:15:18 PDT 2003
com/sun/security/auth/NTSid.class
  1021 Tue Aug 19 18:15:18 PDT 2003
com/sun/security/auth/NTSidDomainPrincipal.class
  1848 Tue Aug 19 18:15:18 PDT 2003
com/sun/security/auth/NTDomainPrincipal.class
  1052 Tue Aug 19 18:15:18 PDT 2003
com/sun/security/auth/NTDomainPrincipal$1.class
   194 Tue Aug 19 18:15:18 PDT 2003
com/sun/security/auth/PrincipalComparator.class
  7913 Tue Aug 19 18:15:18 PDT 2003
com/sun/security/auth/login/ConfigFile.class
  3006 Tue Aug 19 18:15:18 PDT 2003
com/sun/security/auth/login/ConfigFile$1.class
  1333 Tue Aug 19 18:15:18 PDT 2003
com/sun/security/auth/SolarisPrincipal.class
  1855 Tue Aug 19 18:15:18 PDT 2003
com/sun/security/auth/SolarisNumericGroupPrincipal.class
  1836 Tue Aug 19 18:15:18 PDT 2003
com/sun/security/auth/NTUserPrincipal.class
  1038 Tue Aug 19 18:15:18 PDT 2003
com/sun/security/auth/NTUserPrincipal$1.class
  1015 Tue Aug 19 18:15:18 PDT 2003
com/sun/security/auth/NTSidUserPrincipal.class
  1670 Tue Aug 19 18:15:18 PDT 2003
com/sun/security/auth/NTNumericCredential.class
  1116 Tue Aug 19 18:15:18 PDT 2003
com/sun/security/auth/NTNumericCredential$1.class
 16523 Tue Aug 19 18:15:18 PDT 2003
com/sun/security/auth/PolicyFile.class
   558 Tue Aug 19 18:15:18 PDT 2003
com/sun/security/auth/PolicyFile$1.class
  1457 Tue Aug 19 18:15:18 PDT 2003
com/sun/security/auth/PolicyFile$2.class
  1445 Tue Aug 19 18:15:18 PDT 2003
com/sun/security/auth/PolicyFile$PolicyEntry.class
  2028 Tue Aug 19 18:15:18 PDT 2003
com/sun/security/auth/PolicyPermissions.class
Comment 1 John Baker 2003-08-20 02:47:44 UTC
Created attachment 11371 [details]
jarContent file
Comment 2 John Baker 2003-08-20 03:36:11 UTC
Created attachment 11373 [details]
Original jarContent file
Comment 3 John Baker 2003-08-20 03:43:08 UTC
Apparently, when compiling the jar content file the source is not
mounted, but there is no indication (no badge on the jarContent
node) to indicate this  (Probably since there may be another com
package that is mounted).  So, it seems that the com package is
replaced with the mounted com package.
Comment 4 Ondrej Rypacek 2003-08-20 14:53:39 UTC
I guess this is another instance of the well known jarPackager issue. 

Could you please describe by words, what happened to the jarContent.
It is impossible to browse it if I don't have exactly the same
filesystems mounted.



Comment 5 John Baker 2003-08-21 21:38:01 UTC
A different "com" package replaced the original "com" package
because the source was not in a mounted filesystem (the IDE
found a different "com" package in the classpath)
Comment 6 John Baker 2003-08-21 21:44:07 UTC
Created attachment 11394 [details]
Source used to create the jarRecipe
Comment 7 John Baker 2003-08-21 21:47:53 UTC
To recreate the original jar content:

1) unzip ejb_all.zip in a filesystem 
2) Mount this filesystem (com should be the first package)
3) Create a new Jar Recipe from only the class files (use the filter)
   and add only the com package
4) Compile the jar recipe

(No need to create a web module for this)
Comment 8 Ondrej Rypacek 2003-08-22 11:01:34 UTC
Thanks for the details. I managed to reproduce the problem on a
simpler filesystem. 

FS A: 
   a 
      A.class

FS B:
   a
      B.class

Now, if jar recipe is created on FS A, with "a" as its content
FS A: 
   a 
      A.class

   JarRecipe
       a

FS B:
   a
      B.class

It can be compiled, the result is a jar file containing a/A.class.
The recipe is then ocpied to FS B and FS A unmounted...

FS B:
   a
      B.class

!  JarRecipe
 !     a

The jar recipe is correctly marked as invalid. But if you compile the
recipe anyway , the exclamation marks disappear and the content
switches to contain the other a package . The compilation finishes
with a jar file containing a/B.class.

The problem here seems to be that the corruption, though detected, is
ignored, compilation runs anyway and the content is somehow corrupted
during it. 

Can you please verify, that in your case the JarRecipe is also
indicated to be invalid after moving it and unmounting the sources,
before the recompilation ? 
Comment 9 Ondrej Rypacek 2003-09-25 13:28:29 UTC
Lowering the priority, as it is not so easy to reproduce. 

Still waiting for the reporter to verify my last question: is the jar
recipe marked to be invalid just before the corrupting recompilation ?
I need to know if I managed to reproduce it or not.
Comment 10 John Baker 2003-09-25 18:29:38 UTC
To answer the question, no, the jar is not marked as invalid (no red
badge).

This defect is easy to reproduce when using the original scenario with
J2EE components.
Comment 11 Ondrej Rypacek 2003-11-28 09:27:11 UTC
This is a long standing architectural issue. JarContent is represented
by a list of DataObjects which get messed up when the mounted
filesystems change substantially, the files change outside of the IDE
,etc.




*** This issue has been marked as a duplicate of 21326 ***