Community
Participate
Working Groups
Any plug-in that provides Servlet/JSP/EL libs newer than platform's Orbit bundles (specifically javax.servlet, javax.servlet.jsp, and org.apache.commons.el) can result in a LinkageError. One very noticeable result of this condition is the inability to use the Web Page Editor's "Preview" page. Attempting to do so results in a blank canvas and a LinkageError in the error log. The issue would appear to involve the fact that Orbit bundles don't use "Require-Bundle", they use "Import-Package". So when org.apache.commons.el attempts to import javax.servlet.jsp.el classes, if a library in the installation provides a version other than the Orbit bundle's version, a LinkageError occurs. (Install Spring IDE and you'll see this.) We can't predict all bundles that will be present that may provide these packages, and so we need to link more flexibly. This appears to be possible to achieve by changing ...pagedesigner and ...pagedesigner.jsp.core plug-ins to also use Import-Package instead of Require-Bundle for these libraries. This is currently impacting at least one adopter (Oracle).
Looks like bug 222675 has resurfaced ... in a slightly different way. The 'requires bundle' approach should work ... IF your code executed first (and I think required all participants "played nice" by not having their own custom classloaders ... and I do not know enough about these three pre-req'd bundles to know if they do or don't). But, since you can't guarantee your code is the first to execute (to require a class) then if the 'import package' solution works for you, then that's great. In what way are the Spring IDE bundles more recent? Higher minor versions? Higher service? I thought we had the highest versions available? (I'm mostly just curious here ... what you say is true, just like the problem we previously had in bug 222675). I'm a little curious if its "higher" versions, per se, or just having alternative bundles which also satisfy the OSGi constraints). I'm a little concerned, that the Orbit jars do not import what they export, so they may not be playing nice according to OSGi specs (See http://www.osgi.org/blog/2007/04/importance-of-exporting-nd-importing.html). Long term those might have to be improved. In the worst case (if some of these bundles do use their own class loaders) then we might have to use the "uses" clause in OSGi manifest, to help OSGi figure out how to wire the classes (and classloaders). I'm adding Simon to CC list, as he is the expert in all things servlet and OSGi. :) Simon, does it surprise you to see this problem? Or that us using 'import package' fixes the problem? Do you think if our WTP bundles use 'import package' that is enough to permanently fix this problem? Or will more have to be done so bundles import what they export?
Oh, and Ian, it would be an interesting experiment if you could "hack" your test installation so those three bundles from Orbit import what they export, it'd be interesting to see if that also fixed the problem. Its kind of trial and error debugging (sort of) and I know its not easy to "hack" jars (especially after they've been signed :) ... just thought I'd mention it.
The Spring IDE bundles (that the adopter is using) provide JSP 2.1, while the platform is using the JSP 2.0 Orbit bundle. Indeed, we cannot find any real solution in expecting any bundle to load first, we can't predict this. So far, testing looks good - it seems if ...pagedesigner and ...pagedesigner.jsp.core use Import-Package and not Require-Bundle, things are working correctly. I'd be willing to give it a shot, but I don't understand importing what you export in the Orbit bundles. Some exports are being provided by the JAR being bundled, and not imported - how can they be imported? Could you provide a brief example, please?
I can help with the import what you export issue long term (that is, provide some test jars) but it may well be that the jsp 2.1 bundle is the one that would have to do it, to work in this case, which we have no control over. Do you need this for WTP 3.1.2? As far as I know, it'd be a perfectly safe fix to change to 'import packages' ... I guess worst case, is the problem might still manifest itself in some "higher" bundle that prereqs one of the JSF ones. To explain, though, the import-what-you-export pattern is just as simple (and goofy looking) as it sounds. Where javax.servlet.jsp currently has Import-Package: javax.servlet; version=2.4, javax.servlet.http; version=2.4, javax.servlet.resources; version=2.4, javax.servlet.jsp; version=2.0 Export-Package: javax.servlet.jsp; version=2.0, javax.servlet.jsp.el; version=2.0, javax.servlet.jsp.resources; version=2.0, javax.servlet.jsp.tagext; version=2.0 it would become Import-Package: javax.servlet; version=2.4, javax.servlet.http; version=2.4, javax.servlet.resources; version=2.4, javax.servlet.jsp; version=2.0, javax.servlet.jsp.el; version=2.0, javax.servlet.jsp.resources; version=2.0, javax.servlet.jsp.tagext; version=2.0 Export-Package: javax.servlet.jsp; version=2.0, javax.servlet.jsp.el; version=2.0, javax.servlet.jsp.resources; version=2.0, javax.servlet.jsp.tagext; version=2.0
(In reply to comment #4) Thanks for your help, David. We are looking into a possible fix in 312 by tomorrow AM. I will raise it for PMC approval to be ready for check-in.
I understand the changes I need to hack into a local copy of an Orbit bundle to test the "import-what-you-export" pattern, but have to admit that I don't understand how a bundle can hope to import what it, itself, provides. This accomplishes what? Bizarre, but hey - I'm game. I'll give it a shot.
* Explain why you believe this is a stop-ship defect. Or, if it is a "hotbug" (requested by an adopter) please document it as such. This issue breaks the Preview feature of the Web Page Editor. * Is there a work-around? If so, why do you believe the work-around is insufficient? The workaround is not practical as it would require not to install any product that ships the above libraries * How has the fix been tested? Is there a test case attached to the bugzilla record? Has a JUnit Test been added? Manual testing * Give a brief technical overview. Who has reviewed this fix? see description * What is the risk associated with this fix? Low-medium
Created attachment 158818 [details] Patch to change some "Require-Bundle" entries to "Import-Package"
(In reply to comment #6) > ... but have to admit that I don't > understand how a bundle can hope to import what it, itself, provides. This > accomplishes what? Well, normally it doesn't, if it happens to be the only provider (which it normally is) ... then it just exports what it has. The difference is if some other bundle also provides it, then the import/export bundle just acts as a "conduit" to what is already loaded ... no sense having two of them. I think conceptually, the best way to understand it, is to imagine some hypothetical other bundle that provided only one of those packages, say javax.servlet.jsp.resources; version=2.0, then you could see how its just want to re-use it, instead of providing a separate copy in memory. If all bundles did this import what you export, then the order that bundles are loaded matters less. I doubt it would actually help in this case ... I'd have to draw a picture, look at the jsp 2.1 bundle, etc. Was just a thought.
I'm in favor of this change, since it'd be a shame to not be able to use JSF with other versions of javax.jsp, etc, until WTP 3.2. I think its safe partially because the 'require to import' change should be safe, and the fact that the pagedesigner bundles are "leaf" bundles in WTP so would not impact other parts of WTP itself.
Is the linkage error you are seeing the same as in bug 222675? Where the problem starts with org.apache.commons.el.ExpressionEvaluatorImpl.evaluate(ExpressionEvaluatorImpl.java:263)
(In reply to comment #11) > Is the linkage error you are seeing the same as in bug 222675? > > Where the problem starts with > > org.apache.commons.el.ExpressionEvaluatorImpl.evaluate(ExpressionEvaluatorImpl.java:263) Yes, its the same exception: java.lang.LinkageError: loader constraint violation: loader (instance of org/eclipse/osgi/internal/baseadaptor/DefaultClassLoader) previously initiated loading for a different type with name "javax/servlet/jsp/el/VariableResolver" at java.lang.ClassLoader.defineClass1(Native Method) at java.lang.ClassLoader.defineClass(Unknown Source) at org.eclipse.osgi.internal.baseadaptor.DefaultClassLoader.defineClass(DefaultClassLoader.java:183) at org.eclipse.osgi.baseadaptor.loader.ClasspathManager.defineClass(ClasspathManager.java:576) at org.eclipse.osgi.baseadaptor.loader.ClasspathManager.findClassImpl(ClasspathManager.java:546) at org.eclipse.osgi.baseadaptor.loader.ClasspathManager.findLocalClassImpl(ClasspathManager.java:477) at org.eclipse.osgi.baseadaptor.loader.ClasspathManager.findLocalClass_LockClassLoader(ClasspathManager.java:465) at org.eclipse.osgi.baseadaptor.loader.ClasspathManager.findLocalClass(ClasspathManager.java:445) at org.eclipse.osgi.internal.baseadaptor.DefaultClassLoader.findLocalClass(DefaultClassLoader.java:211) at org.eclipse.osgi.internal.loader.BundleLoader.findLocalClass(BundleLoader.java:381) at org.eclipse.osgi.internal.loader.SingleSourcePackage.loadClass(SingleSourcePackage.java:33) at org.eclipse.osgi.internal.loader.BundleLoader.findClassInternal(BundleLoader.java:445) at org.eclipse.osgi.internal.loader.BundleLoader.findClass(BundleLoader.java:410) at org.eclipse.osgi.internal.loader.BundleLoader.findClass(BundleLoader.java:398) at org.eclipse.osgi.internal.baseadaptor.DefaultClassLoader.loadClass(DefaultClassLoader.java:105) at java.lang.ClassLoader.loadClass(Unknown Source) at java.lang.ClassLoader.loadClassInternal(Unknown Source) at org.apache.commons.el.NamedValue.evaluate(NamedValue.java:124) at org.apache.commons.el.ComplexValue.evaluate(ComplexValue.java:140) at org.apache.commons.el.ExpressionEvaluatorImpl.evaluate(ExpressionEvaluatorImpl.java:263)
BTW, it kind of sounds like we need JSP 2.1 in Orbit. Have you filed a CQ? Is taht in the works? And servlet 2.5? Are these for Java EE 5? Or EE 6?
(In reply to comment #13) > BTW, it kind of sounds like we need JSP 2.1 in Orbit. Have you filed a CQ? Is > taht in the works? And servlet 2.5? Are these for Java EE 5? Or EE 6? These were done for JSF 1.2 / EE 5. Didn't these make it to Orbit? JSP 2.1 :https://dev.eclipse.org/ipzilla/show_bug.cgi?id=1980 Servlet 2.5: https://dev.eclipse.org/ipzilla/show_bug.cgi?id=1979
(In reply to comment #14) > (In reply to comment #13) > > ... Didn't these make it to Orbit? > JSP 2.1 :https://dev.eclipse.org/ipzilla/show_bug.cgi?id=1980 > Servlet 2.5: https://dev.eclipse.org/ipzilla/show_bug.cgi?id=1979 Glad I asked! looks like servlet 2.5 is there, but not jsp 2.1. I'll get that soon, if Simon doesn't.
> > Glad I asked! looks like servlet 2.5 is there, but not jsp 2.1. > I've tracked this though, and looks like its almost ready to go in. See bug 301263.
Manual tests are all good. JUnit tests are all green. We have three PMC approvals. Patch has been applied and checked in.
Change released to build.
