Bugzilla – Full Text Bug Listing
| Summary: | [hotbug-request] MANIFEST in jsf.facelet.core: Require-Bundle vs Import-Package | ||||||
|---|---|---|---|---|---|---|---|
| Product: | [WebTools] Java Server Faces | Reporter: | Yury Kats <yurykats> | ||||
| Component: | Core | Assignee: | Ian Trimble <ian.trimble> | ||||
| Status: | RESOLVED FIXED | QA Contact: | |||||
| Severity: | major | ||||||
| Priority: | P3 | CC: | david_williams, raghunathan.srinivasan, ricec, robert_gallagher, thatnitind | ||||
| Version: | 3.2 | ||||||
| Target Milestone: | 3.2.1 | ||||||
| Hardware: | PC | ||||||
| OS: | Windows XP | ||||||
| Whiteboard: | |||||||
| Attachments: |
|
||||||
|
Description
Yury Kats
Created attachment 172554 [details]
MANIFEST patch
In general, this problem would happen when the same class is packaged in multiple plugins (which is the case in the adopter product). If the plugin A uses Require-Bundle to request the class, while plugin B uses Import-Package, a collision is possible, depending on the plugin loading order. Raising severity to major. We just identified this as a source of a real defect in the adopter product. On a Linux machine content assist in a Facelet fails with !ENTRY org.eclipse.ui 4 0 2010-06-29 15:10:23.608 !MESSAGE Unhandled event loop exception !STACK 0 java.lang.IncompatibleClassChangeError at org.eclipse.wst.xml.ui.internal.contentassist.AbstractContentAssistProcessor.addAttributeValueProposals(AbstractContentAssistProcessor.java:276) at org.eclipse.jst.jsf.facelet.ui.internal.contentassist.XHTMLContentAssistProcessor.addAttributeValueProposals(XHTMLContentAssistProcessor.java:168) at org.eclipse.wst.xml.ui.internal.contentassist.AbstractContentAssistProcessor.computeAttributeValueProposals(AbstractContentAssistProcessor.java:1274) at org.eclipse.wst.xml.ui.internal.contentassist.AbstractContentAssistProcessor.computeCompletionProposals(AbstractContentAssistProcessor.java:1308) at org.eclipse.wst.xml.ui.internal.contentassist.AbstractContentAssistProcessor.computeCompletionProposals(AbstractContentAssistProcessor.java:1416) at org.eclipse.jst.jsf.facelet.ui.internal.contentassist.XHTMLContentAssistProcessor.computeCompletionProposals(XHTMLContentAssistProcessor.java:64) at org.eclipse.wst.sse.ui.contentassist.StructuredContentAssistProcessor.collectProposals(StructuredContentAssistProcessor.java:463) at org.eclipse.wst.sse.ui.contentassist.StructuredContentAssistProcessor.computeCompletionProposals(StructuredContentAssistProcessor.java:249) at org.eclipse.wst.sse.ui.internal.contentassist.CompoundContentAssistProcessor.computeCompletionProposals(CompoundContentAssistProcessor.java:126) at org.eclipse.jface.text.contentassist.ContentAssistant.computeCompletionProposals(ContentAssistant.java:1834) at org.eclipse.jface.text.contentassist.CompletionProposalPopup.computeProposals(CompletionProposalPopup.java:556) at org.eclipse.jface.text.contentassist.CompletionProposalPopup.access$16(CompletionProposalPopup.java:553) With the patch applied to MANIFEST, the problem goes away and content assist works. The patch is simple and harmless. Please review and consider for 3.2.1. Thanks. Setting as hotbug-request. 1. Affiliation: IBM 2. Ideally this would be applied to 3.2.1. 3. The use of Import-Package is causing customer-reported issues in valid installations where we have two plug-ins exporting the same package. We're still investigating details, but have verified that this alteration lets the customer scenario proceed. (In reply to comment #2) > In general, this problem would happen when the same class is packaged in > multiple plugins (which is the case in the adopter product). > > If the plugin A uses Require-Bundle to request the class, while plugin B uses > Import-Package, a collision is possible, depending on the plugin loading order. I'm not asking for anything confidential ... but, how is it you end up with the same class packaged in multiple plugins?! That can't be a good practice. Is that actually required by adopter product? Or just a quirk of packaging? Just curious. But, normally, "import package" is useful when "you don't care" where a package comes from, and is often used for things like "javax.xml" or similar ... require-bundle is usually recommended when there is a very tight coupling between bundles, which I think is the case here ... these are all in the wtp release stack (right?) We're still investigating details. The multiple versions/exports appear to be required for different scenarios between design time and run time. Checked into HEAD. This was introduced when the Require-Bundle entry was added but the Import-Package entries were not removed for the fix for bug 312942. I am a bit confused. Why did you remove just the wst.xml.core packages from Import-Package, but left the rest there? I'm also confused - is this not precisely what you detailed as the problem and asked to be fixed? I wanted to minimize the risk, and so removed only the Import-Package entries that were reported as being problematic. If further work is required, please explain what and why. Thanks, - Ian The patch was overlooked previously, hence the confusion about what was changed (I think). Changes as per the patch have now been checked in - there is no longer any use of Import-Package in the facelet core plug-in. (In reply to comment #9) Ian, yes, the problem we ran into was specific to org.eclipse.wst.xml.core. It just seemed to be that Import-Package is prone to issues like this and as long as we were fixing one we might as well fix the rest. Thanks for making the change. |