Community
Participate
Working Groups
Currently the org.eclipse.jst.pagedesigner.jsp.core includes jsp-api.jar and servlet-api.jar files. I might be mistaken, but shouldn't it be using the javax.servlet and javax.servet.jsp Orbit bundles in the WTP builds instead?
The orbit map files in WTP has the version 1.2.0 and 2.0.0 plugin@javax.servlet.jsp,1.2.0=GET,http://download.eclipse.org/tools/orbit/downloads/drops/I200705130851/bundles/javax.servlet.jsp_1.2.0.v200612120445.jar plugin@javax.servlet.jsp,2.0.0=GET,http://download.eclipse.org/tools/orbit/downloads/drops/I200705130851/bundles/javax.servlet.jsp_2.0.0.v200703221034.jar How is the bundle version range relate to the version mentioned in the map file? javax.servlet.jsp;bundle-version="[2.0.0,3.0.0)"
There are two versions available (in Orbit) for anyone to use, so the versions in the map files are the "trick" to get the desired one included. Those values are used to "match up" based on what is said in the feature.xml file. So we could use <plugin id="javax.servlet" download-size="100" install-size="100" version="1.2.0" unpack="false"/> if that's the one we wanted. And, I see now we say just "0.0.0" ... what should be changed to the specific one we want ... is "2.0.0" ok with you?
Created attachment 70435 [details] Use Orbit bundles
Use of Orbit bundles for javax.servlet, javax.servlet.jsp and org.apache.commons.el. Do we need to update releng->orbitbundle*.map file to include commons.el or is that file generated from the feature.xml? Related issue: We(JSP+JSF) are not using the 2.5 version of the javax.servlet and the latest (1.2?) version of commons.el. These are not in the Orbit bundles. I suspect we will uncover some limitations.
Yes, your patch is correct. And no, nothing you need to do for orbit map. That map is generated during the orbit build, and we simply snag what ever copy of it we want. (and then our reference in feature.xml is all that's needed to get the map to work). As for your "Related issue: ", are you saying that the lower levels is true whether we make this change or not? Right? If so, then yes ... good to be aware of that and get started on updates for next cycle (or service) but .... if you are saying you in JSF would be "moving down" because of using orbit stuff, then certainly I would not recommend this change and don't feel it's required if there's any change of losing function or introducing something different.
Raising for PMC review. I have tested this locally and see no issues. The preview page of the WPE uses these jars when resolving references to resource bundle and they work fine. Note that all the jars that are bing replaced are already being included and installed due to other project dependencies.
Sounds good to me ... I think less redundancy in shipped code is worthwhile.
Fixed for RC3.
the build.properties file still contains lib/,\ which can be removed now.
Preview functionality is broken in RC4. Investigating.
java.lang.LinkageError: Class javax/servlet/jsp/el/VariableResolver violates loader constraints at java.lang.ClassLoader.defineClass1(Native Method) at java.lang.ClassLoader.defineClass(ClassLoader.java:620) at org.eclipse.osgi.internal.baseadaptor.DefaultClassLoader.defineClass(DefaultClassLoader.java:161) at org.eclipse.osgi.baseadaptor.loader.ClasspathManager.defineClass(ClasspathManager.java:501) at org.eclipse.osgi.baseadaptor.loader.ClasspathManager.findClassImpl(ClasspathManager.java:471) at org.eclipse.osgi.baseadaptor.loader.ClasspathManager.findLocalClassImpl(ClasspathManager.java:430) at org.eclipse.osgi.baseadaptor.loader.ClasspathManager.findLocalClass(ClasspathManager.java:413) at org.eclipse.osgi.internal.baseadaptor.DefaultClassLoader.findLocalClass(DefaultClassLoader.java:189) at org.eclipse.osgi.framework.internal.core.BundleLoader.findLocalClass(BundleLoader.java:340) at org.eclipse.osgi.framework.internal.core.SingleSourcePackage.loadClass(SingleSourcePackage.java:37) at org.eclipse.osgi.framework.internal.core.BundleLoader.findClassInternal(BundleLoader.java:396) at org.eclipse.osgi.framework.internal.core.BundleLoader.findClass(BundleLoader.java:369) at org.eclipse.osgi.framework.internal.core.BundleLoader.findClass(BundleLoader.java:357) at org.eclipse.osgi.internal.baseadaptor.DefaultClassLoader.loadClass(DefaultClassLoader.java:83) at java.lang.ClassLoader.loadClass(ClassLoader.java:251) at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:319) 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) at org.apache.commons.el.ExpressionEvaluatorImpl.evaluate(ExpressionEvaluatorImpl.java:190) at org.eclipse.jst.pagedesigner.preview.PageExpressionContext.evaluateExpression(PageExpressionContext.java:115) at org.eclipse.jst.pagedesigner.dtmanager.converter.internal.DTTagConverterDecorator.resolveChildText(DTTagConverterDecorator.java:149) at org.eclipse.jst.pagedesigner.dtmanager.converter.internal.DTTagConverterDecorator.decorateFromDTInfo(DTTagConverterDecorator.java:82) at org.eclipse.jst.pagedesigner.dtmanager.converter.internal.DTTagConverterDecorator.decorate(DTTagConverterDecorator.java:52) at org.eclipse.jst.pagedesigner.dtmanager.converter.internal.DTTagConverter.convertRefresh(DTTagConverter.java:75) at org.eclipse.jst.pagedesigner.preview.PreviewConvertContext.previewConvertElement(PreviewConvertContext.java:93) at org.eclipse.jst.pagedesigner.preview.PreviewConvertContext.previewConvert(PreviewConvertContext.java:56) at org.eclipse.jst.pagedesigner.preview.PreviewConvertContext.previewConvertElement(PreviewConvertContext.java:100) at org.eclipse.jst.pagedesigner.preview.PreviewConvertContext.previewConvert(PreviewConvertContext.java:56) at org.eclipse.jst.pagedesigner.preview.PreviewConvertContext.previewConvertElement(PreviewConvertContext.java:100) at org.eclipse.jst.pagedesigner.preview.PreviewConvertContext.previewConvert(PreviewConvertContext.java:56) at org.eclipse.jst.pagedesigner.preview.PreviewConvertContext.previewConvertElement(PreviewConvertContext.java:100) at org.eclipse.jst.pagedesigner.preview.PreviewConvertContext.previewConvert(PreviewConvertContext.java:56) at org.eclipse.jst.pagedesigner.preview.PreviewConvertContext.previewConvertElement(PreviewConvertContext.java:100) at org.eclipse.jst.pagedesigner.preview.PreviewConvertContext.previewConvert(PreviewConvertContext.java:56) at org.eclipse.jst.pagedesigner.preview.PreviewConvertContext.previewConvertElement(PreviewConvertContext.java:100) at org.eclipse.jst.pagedesigner.preview.PreviewConvertContext.previewConvert(PreviewConvertContext.java:56) at org.eclipse.jst.pagedesigner.preview.PreviewHandlerNew.generatePreview(PreviewHandlerNew.java:97) at org.eclipse.jst.pagedesigner.editors.HTMLEditor.pageChange(HTMLEditor.java:942) at org.eclipse.ui.part.MultiPageEditorPart$2.widgetSelected(MultiPageEditorPart.java:239) at org.eclipse.swt.widgets.TypedListener.handleEvent(TypedListener.java:227) at org.eclipse.swt.widgets.EventTable.sendEvent(EventTable.java:66) at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:938) at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:962) at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:947) at org.eclipse.swt.widgets.Widget.notifyListeners(Widget.java:706) at org.eclipse.swt.custom.CTabFolder.setSelection(CTabFolder.java:3227) at org.eclipse.swt.custom.CTabFolder.onMouse(CTabFolder.java:2005) at org.eclipse.swt.custom.CTabFolder$1.handleEvent(CTabFolder.java:316) at org.eclipse.swt.widgets.EventTable.sendEvent(EventTable.java:66) at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:938) at org.eclipse.swt.widgets.Display.runDeferredEvents(Display.java:3682) at org.eclipse.swt.widgets.Display.readAndDispatch(Display.java:3293) at org.eclipse.ui.internal.Workbench.runEventLoop(Workbench.java:2389) at org.eclipse.ui.internal.Workbench.runUI(Workbench.java:2353) at org.eclipse.ui.internal.Workbench.access$4(Workbench.java:2219) at org.eclipse.ui.internal.Workbench$4.run(Workbench.java:466) at org.eclipse.core.databinding.observable.Realm.runWithDefault(Realm.java:289) at org.eclipse.ui.internal.Workbench.createAndRunWorkbench(Workbench.java:461) at org.eclipse.ui.PlatformUI.createAndRunWorkbench(PlatformUI.java:149) at org.eclipse.ui.internal.ide.application.IDEApplication.start(IDEApplication.java:106) at org.eclipse.equinox.internal.app.EclipseAppHandle.run(EclipseAppHandle.java:153) at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.runApplication(EclipseAppLauncher.java:106) at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.start(EclipseAppLauncher.java:76) at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:363) at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:176) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at org.eclipse.equinox.launcher.Main.invokeFramework(Main.java:504) at org.eclipse.equinox.launcher.Main.basicRun(Main.java:443) at org.eclipse.equinox.launcher.Main.run(Main.java:1169) at org.eclipse.equinox.launcher.Main.main(Main.java:1144)
Created attachment 71982 [details] Rolls back servlet and el dependencies to local jars instead of orbit This patch is intended as plan B if we cannot resolve current LinkageError issues with the orbit jars for el-common and servlet.
I would like to have PMC approval to rollback to using local jars. It is not clear if the versions of JSF required jars in Orbit are compatible with each other. We are continuing to investigate.
BTW, if we go with Plan B, I'd recommend you use the latest known tagged version that used the jars, which I see as v200705302227. (instead of "applying the patch" ... "patching" with binary data, as the jars are, may not always work, I've heard. Do you have a small sample project that demonstrates the problem?
+1 on rolling back if necessary.
There are two versions of javax.servlet.jsp and javax.servlet bundles. David discovered that removing one of the javax.servlet.jsp bundle fixes the issue. He is following up with the Platfrom folks to make sure we ship only one version. We will wait for the feedback to decide if we need to rollback. (Thanks to David for working on this till 3.00 AM!)
+1 pre-approval. I'd prefer if we can resolve the current issue and keep using the Orbit jars, but if that's not going well then let's roll this back and open a new bug to track using Orbit for 3.0.
(In reply to comment #16) > There are two versions of javax.servlet.jsp and javax.servlet bundles. I should clarify that these are two installs of the same version with different file sizes! For example, javax.servlet.jsp_2.0.0.v200705231728.jar - 58KB javax.servlet.jsp_2.0.0.v200706191603.jar - 56KB
The platform has confirmed they will move to the "final" orbit build, I think today, so until we re-synch with the Platform's RC5, or what ever they call it, we'll have to "manually" delete the older one from installs. I'd prefer then to leave as is now until we understand this better, and make sure we fix the correct way. Essentially, there's some code that does a live "evaluation" of some snippet of code, calling beaninfo even, so there are is another, non-OSGI classloader created to handle that, and I'm not sure if that's the behavior we want. That non-OSGI classloader, I suspect, somehow finds the older javax.servlet.jar first, instead of the one with the higher qualifier, as OSGi does. And, just to document my quick glance at the code, there is some code in a jst.pagedesigner package that triggers this "eval", and also it's doing some funky stuff with jar files directly ... so it _might_ be in this "find jar" code that something is going wrong. My main concern is that having our own "private jar" might actually be masking a larger classpath/lookup problem that will only surface later in another form. So, since there's a known workaround that isn't too bad (and only needed in the off chance some one _else_ installs yet another javax.servlet.jsp bundle) ... then I'd recommend we track this down for service release so it's more bullet proof. Of course, if something happens and the Platform doesn't line up ... then I'd still recommend reverting, since "out of the box" experience would be bad. As it is, I suspect no one will hit this in practice ... at least, before the service release :) Next week, we'll need to monitor the "total Europa install" and make sure everyone is using the right bundle. Similarly, this looks like a prime test case to install, with update manager, the platform in one location and all of WTP in another location. This then will end up purposely with two copies of the javax.servlet.jsp bundle, with exact same qualifier. Only one will be activated ... so would be important to see if the issue re-surfaces in that use-case. If so, I'd still recommend a "release note" until we really understand it. Opps ... planes about to board :)
The following versions (all others removed) are producing correct preview behaviour: javax.servlet.jsp_2.0.0.v200706191603.jar javax.servlet_2.4.0.v200706111738.jar org.apache.commons.el_1.0.0.v200706111724.jar These are all the latest versions in the build S-2.0RC4-200706201726. I would like to make sure these are the jars that get picked in the final build.
(In reply to comment #19) > And, just to document my quick glance at the code, there is some code in a > jst.pagedesigner package that triggers this "eval", and also it's doing some > funky stuff with jar files directly ... so it _might_ be in this "find jar" > code that something is going wrong. David, could you please provide more specific information on where we can find the code that's "...doing some funky stuff with jar files directly..."? We've sifted through our code but have yet to find anything like this. Thanks, - Ian
(In reply to comment #21) > (In reply to comment #19) > > the code that's "...doing some funky stuff with jar files directly..."? We've > sifted through our code but have yet to find anything like this. > Well, looking at it again, not sure its about "jars", but I think what I saw was in LoadBundleOperation .. I saw some classpath entries, and some "findMembers" in project .... so, by "funky" I just meant I didn't understand what it was doing. It seems a "hard way" to find resources on the classpath ... as opposed to classloader.getResouce(). But, like I said, I just meant to be writing down some ideas ... I haven't studies it all that much.
(In reply to comment #22) > (In reply to comment #21) > Well, looking at it again, not sure its about "jars", but I think what I saw > was in LoadBundleOperation .. I saw some classpath entries, and some > "findMembers" in project .... so, by "funky" I just meant I didn't understand > what it was doing. > It seems a "hard way" to find resources on the classpath ... as opposed to > classloader.getResouce(). But, like I said, I just meant to be writing down > some ideas ... I haven't studies it all that much. I agree, the code in LoadBundleOperation does seem oddly-structured for what it is doing, and I appreciate your mentioning it; looks like something for us to clean up in a future release. However, I don't feel that this would trigger loading of any specific plugin over any other. Thanks for the clarification, - Ian
JSF Web Page Editor Preview functionality works correctly with Eclipse I20070621-1340 and WTP S-2.0RC4-200706212235 (and prereqs). The following files installed by Eclipse and WTP have the same file name but have different sizes. Shouldn’t we be shipping the same bits? javax.servlet.jsp_2.0.0.v200706191603.jar – 62 KB (Eclipse install), 56KB (WTP install) javax.servlet_2.4.0.v200706111738.jar – 106 KB (Eclipse install), 99 KB (WTP install) org.apache.commons.el_1.0.0.v200706111724.jar – 125 KB (Eclipse install), 118 KB (WTP install) Marking this as Fixed. We will open a new bug to track jars with same name and different size.
