Community
Participate
Working Groups
While debugging some Content Model related issues, I ran into a problem with CM* classes not loading properly sometime. Depending on how I have my development environment set up, I sometimes get ClassDefNotFound or Verify exceptions for CM* classes in org.eclipse.wst.xml.core.* packages. Looks like the same class is being loaded from different sources at the same time, causing a collision. I found that MANIFEST file in jsf.facelet.core uses both Require-Bundle and Import-Package for org.eclipse.wst.xml.core classes, ie: Require-Bundle: org.eclipse.wst.xml.core Import-Package: org.eclipse.wst.xml.core.internal.contentmodel, org.eclipse.wst.xml.core.internal.contentmodel.factory, org.eclipse.wst.xml.core.internal.regions If I remove org.eclipse.wst.xml.core.* from Import-Package section, the problem goes away. I am not quite sure how Eclipse handles Require-Bundle vs Import-Package, but I do see Import-Package causing a problem in this particular case. Can it be removed so that only Require-Bundle is used? Thanks.
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.
