Bugzilla – Full Text Bug Listing
| Summary: | can not pack jsf.core bundle | ||||||
|---|---|---|---|---|---|---|---|
| Product: | [WebTools] Java Server Faces | Reporter: | David Williams <david_williams> | ||||
| Component: | Core | Assignee: | Ian Trimble <ian.trimble> | ||||
| Status: | RESOLVED FIXED | QA Contact: | |||||
| Severity: | major | ||||||
| Priority: | P3 | CC: | neil.hauge, raghunathan.srinivasan | ||||
| Version: | unspecified | Flags: | david_williams:
pmc_approved+
raghunathan.srinivasan: pmc_approved? (naci.dai) raghunathan.srinivasan: pmc_approved? (deboer) neil.hauge: pmc_approved+ raghunathan.srinivasan: pmc_approved? (kaloyan) raghunathan.srinivasan: review+ |
||||
| Target Milestone: | 3.2.3 | ||||||
| Hardware: | PC | ||||||
| OS: | Windows 7 | ||||||
| Whiteboard: | PMC_approved | ||||||
| Attachments: |
|
||||||
|
Description
David Williams
FYI, I've discovered the same problem in our M5 as well. Guess its the same code/bundle. I have also re-discovered I can use an extra step to remove that one specific bundle, so am downgrading to 'major' ... but, hate to depend on that extra step if can be fixed more permanently. Created attachment 188086 [details]
Patch to cause plugin JAR to be excluded from packing.
Raghu, please review for PMC approval. There is nothing odd about the class that is reported as an issue by the pack200 utility, in fact there is another inner class that is almost identical and there is no problem reported for that one. The solution is, therefore, as suggested: adding the appropriate eclipse.inf contents to cause the pack200 utility to skip packing the plug-in's JAR. These tasks were performed locally: - build a JAR for the plug-in (jsf.core) - sign the JAR - run pack200 on the signed JAR - run unpack200 on the packed, signed JAR At no point is there any error, and the JAR is valid at the end of the process. There is nothing even remotely obscure about the ConverterClassValidationVisitor class, and a sibling inner class (ConverterForClassValidationVisitor) that is almost identical has not been reported to cause the same issue. I can see no way to change the class to make it work, since I cannot reproduce the issue to begin with and since there is nothing obviously strange about the class. Requesting PMC review to checkin the workaround to address the error in running pack200 on jsf.core bundle. I approve and think the eclipse.inf solution is the right one.
But, for reference, I think the steps to try and reproduce this should be slightly different; to include a "conditioning" step (marked with '*' below).
- build a JAR for the plug-in (jsf.core)
*- run pack200 on the jar with -unpack option (essentially does pack, and
then unzips it, so the byte code are shuffled around before signing).
- sign the JAR
- run pack200 on the signed JAR
- run unpack200 on the packed, signed JAR
But, I would be very surprised if this reproduced it. I think the cases where this occur are pretty odd, and I'm sure depends on exact versions of VMs, pack/unpack options, libraries ... maybe even day of the week :) That is, in the cases I've seen/read about, there is essentially no "fix" the programmer can make ... its some hole in the process/specs/implementation or something.
Thanks.
Oh, and one other thing about reproducing ... we intentionally use a 1.5 VM to do the pack (not sure if you were or not, but I know that'd make a difference) ... and via the "jarsigner" utilities, we use "-E4" when we do the pack (E4 means "not too much effort" ... supposed to be one of the "safest" levels to use ... but, as I've mentioned ... there have been several other cases of mysterious failures that lead to simply excluding it from being packed at all ... so, just consider this info if you are interested ... I'm not asking for you to do anything different from including the eclipse.inf. Thanks again, With two PMC approvals, checked into 3.2.3 stream at 2011/02/02 10:57AM PDT. Checked into 3.3 stream at 2011/02/02 11:08AM PDT. |