Bugzilla – Full Text Bug Listing
| Summary: | Migrate equinox to jetty8 | ||||||||
|---|---|---|---|---|---|---|---|---|---|
| Product: | [Eclipse Project] Equinox | Reporter: | Hugues Malphettes <hmalphettes> | ||||||
| Component: | Compendium | Assignee: | Simon Archer <sja.eclipse> | ||||||
| Status: | RESOLVED FIXED | QA Contact: | |||||||
| Severity: | normal | ||||||||
| Priority: | P3 | CC: | cgold, d_a_carver, eclipse, gunnar, holger.staudacher, irbull, janb, jeffmcaffer, jesse.mcconnell, john.arthorne, ljelinek, mark.ludwig, markusb, overholt, pwebster, rgrunber, rsternberg, ruediger.herrmann, simon_kaegi, tjwatson, tseidel | ||||||
| Version: | 3.6 | Keywords: | plan | ||||||
| Target Milestone: | Juno M4 | ||||||||
| Hardware: | All | ||||||||
| OS: | All | ||||||||
| Whiteboard: | |||||||||
| Bug Depends on: | 341643, 360245 | ||||||||
| Bug Blocks: | 346446 | ||||||||
| Attachments: |
|
||||||||
|
Description
Hugues Malphettes
IMHO ti would be great to have the Jetty project supply the required Jetty-based HTTP service implementation as well as appropriate Jetty features for use in Equinox and the Eclipse SDK. I'd be happy to advise and guide. Simon has way more indepth info on what the issues would be in our use/requirements. It would be great if you could commit the new Jetty bundle somewhere so we could try it out. Jetty incubator is fine or I can nominate you for the Equinox incubator if you would prefer. I think we probably will want to continue to have the Jetty 6 bundle around still at Equinox however once the SDK's base requirements allow general use of Java 5 we should upgrade the version in the platform. OK. Jesse agreed to let us prototype org.eclipse.equinox.jetty7 somewhere in the jetty svn. We will be able to prototype that bundle and the "jetty-for-equinox" feature at once that way. I'll point you to these once it is committed. Cheers! Created attachment 165167 [details] org.eclipse.equinox.http.jetty bundle and org.eclipse.equinox.http.server feature Committed the sources of the org.eclipse.equinox.http.jetty7 project here: http://dev.eclipse.org/svnroot/rt/org.eclipse.jetty/eclipse/trunk/equinox-incubation/ They are attached to this bug for your convenience. My current test consists of self-launching eclipse-SDK. In the launch configuration, I have removed all org.mortbay.* bundles. I have also disabled all org.eclipse.jetty.* bundles except the ones in the feature attached here: <?xml version="1.0" encoding="UTF-8"?> <feature id="org.eclipse.equinox.server.jetty" label="%featureName" version="1.0.0.qualifier" provider-name="%providerName"> <copyright> %copyright </copyright> <license url="%licenseURL"> %license </license> <plugin id="javax.servlet" download-size="0" install-size="0" version="0.0.0" unpack="false"/> <plugin id="org.eclipse.equinox.http.jetty" download-size="0" install-size="0" version="0.0.0" unpack="false"/> <plugin id="org.eclipse.equinox.http.servlet" download-size="0" install-size="0" version="0.0.0" unpack="false"/> <plugin id="org.eclipse.jetty.continuation" download-size="0" install-size="0" version="0.0.0" unpack="false"/> <plugin id="org.eclipse.jetty.http" download-size="0" install-size="0" version="0.0.0" unpack="false"/> <plugin id="org.eclipse.jetty.io" download-size="0" install-size="0" version="0.0.0" unpack="false"/> <plugin id="org.eclipse.jetty.security" download-size="0" install-size="0" version="0.0.0" unpack="false"/> <plugin id="org.eclipse.jetty.server" download-size="0" install-size="0" version="0.0.0" unpack="false"/> <plugin id="org.eclipse.jetty.servlet" download-size="0" install-size="0" version="0.0.0" unpack="false"/> <plugin id="org.eclipse.jetty.util" download-size="0" install-size="0" version="0.0.0" unpack="false"/> </feature> Created attachment 165168 [details]
patch to transform org.eclipse.equinox.http.jetty6 into org.eclipse.equinox.http.jetty7
Here is the diff against CVS.
I re-did the migration from scratch against a fresh checkout of org.eclipse.equinox.http.jetty6
I only changed what was required for jetty7: I did not touch anything to prepare a future integration of other jetty projects.
where are we with this? I thought this was done long time back In the Equinox team call today we discussed. General sense was that we should adopt Jetty 7 but that there are likely a number of outstanding issues that need to be addressed before that adoption can be completed. Simon is willing to participated in making this happen but will need help from the community. Specifically I think there were things around logging, the new JSP support and security. Basically it is work to cover all the details. On a separate note for the future, I'd like to see the Jetty team supplying the OSGi integration and HttpService implementation and then we'll just consume whatever you give us. Forgot to say: Perhaps Simon and Hugues should summarize where we are at and then we can divvy up remaining items. ping Thanks for pinging us Jeff. On the jetty side we are publishing jetty bundles alone on a regular basis in a p2 repository. They are ready to be consumed. We could definitely provide a build of org.eclipse.equinox.http.jetty based on jetty7. One important question: jetty-7 requires Java SE 5. In http://www.eclipse.org/projects/project-plan.php?projectid=rt.equinox#appendix I can see that the target environment for org.eclipse.equinox.http.jetty is 1.4 Is this a blocker for 3.7 to move on to jetty-7? Its not a blocker for the platform itself. Its more whether or not you want Jetty more widely adopted :-) If we have it in equinox then people doing server side stuff with equinox will be directed to Jetty 7 by default as that is what will be in our features etc. The Java 5 thing is interesting. We would have to make it more widely known but I think we can do this. IMHO it would be great if the Jetty team essentially took over responsibility for delivering the HTTP service implementation with JSP support etc. This is not going to happen for 3.7. Simon please correct me if I am wrong. Move all 3.8 bugs to Juno. Jeff, Thomas and Simon, Could you give the Jetty team an update on which release you plan on targetting the upgrade to jetty-7? As I read the history of this issue, it seems we are waiting on you guys for feedback as to jetty-7's dependence on jdk 1.5 before being able to move forward with offering further assistance ... thanks in advance, Jan (In reply to comment #14) > Jeff, Thomas and Simon, > > Could you give the Jetty team an update on which release you plan on targetting > the upgrade to jetty-7? As I read the history of this issue, it seems we are > waiting on you guys for feedback as to jetty-7's dependence on jdk 1.5 before > being able to move forward with offering further assistance ... > > thanks in advance, > Jan The dependency on jdk 1.5 should not be an issue. We would like to move to a newer version of jetty at eclipse see bug346446. Perhaps for Juno that should be Jetty 8? Related to jetty 8 (actually to servlet 3.0) see bug341643. I think that would need to be addressed if we were to use jetty 8. So is bug 271042 now deprecated, as it also asks for jetty 7. I just want to ask how this will be done and kept to a single bundle or have I made an assumption there. It's actually really nice to have a really simple, minimal, single bundle Http service. Sometime you just want to serve up HTTP and not a full blown website etc... So, will it really be the whole of Jetty and will there still be a single bundle version. Changing the title to reflect the intent of moving to jetty 8. (In reply to comment #17) > I just want to ask how this will be done and kept to a single bundle or have I > made an assumption there. It's actually really nice to have a really simple, > minimal, single bundle Http service. Sometime you just want to serve up HTTP > and not a full blown website etc... So, will it really be the whole of Jetty > and will there still be a single bundle version. This bug is about using jetty 8 to implement the OSGi http service. The Equinox team is not going to repackage the jetty bundles. We plan to use them as is from the jetty project. So this will involve multiple bundles to implement the http service. This is no different that our story for using jetty 6 to implement the http service. Hugues, while this bug is about Jetty 8, none of the attachments appear to be related to Jetty 8. I'd like to discuss this with you. Thanks. this bug is really old and was 7 back then, someone recently changed the title I believe (In reply to comment #21) > this bug is really old and was 7 back then, someone recently changed the title > I believe That was me. I was under the impression that the jetty APIs for launching jetty did not change much between jetty 7 and jetty 8 so that the attached patches would be useful for a solution using jetty 8. I believe they should be yes Simon, Thomas and all, I rushed into the code and made sure we can run the platform's help webapp with jetty-8-servlet-3.0. - branched rt.equinox.bundles: https://github.com/hmalphettes/rt.equinox.bundles/tree/servlet3-jetty8 - put together a workspace based on PDE-3.8M1 where I have removed all jetty6-servlet-2.5-jsp-2.1 and put in jetty-8-servlet-3.0-jsp-2.2 bundles. - remove the reference to jasper inside the org.eclipse.help.webapp bundle The changes in the equinox code are mostly related to: - jetty8 and jetty7 APIs are identical all code is committed here: https://github.com/hmalphettes/rt.equinox.bundles/tree/servlet3-jetty8/bundles/org.eclipse.equinox.http.jetty8 - update the implementation of the servlet APIs to comply with servlet-3.0: https://github.com/hmalphettes/rt.equinox.bundles/commit/719f9543edc38844dc0a0514cd744bb9135ec6d3 I am guessing we could review the code changes, the changes in the dependencies. If that looks like it is acceptable we can check the impact on the existing bundles and look at who is building and packaging things. Let me know how to proceed. Thanks! (In reply to comment #24) > Simon, Thomas and all, > I rushed into the code and made sure we can run the platform's help webapp with Thanks Hugues! I have looked at the changes. Simon A. is looking at the changes necessary for equinox.http.servlet project. We think we would like to go the route of creating dynamic proxies for the ServletContext instead of implementing the actual ServletContext inteface. This way we don't have to keep playing catchup each time they add a new method to this interface. > jetty-8-servlet-3.0. > - branched rt.equinox.bundles: > https://github.com/hmalphettes/rt.equinox.bundles/tree/servlet3-jetty8 > - put together a workspace based on PDE-3.8M1 where I have removed all > jetty6-servlet-2.5-jsp-2.1 and put in jetty-8-servlet-3.0-jsp-2.2 bundles. > - remove the reference to jasper inside the org.eclipse.help.webapp bundle What needed to change for this to work? Did you also need to get updated apache jasper bundles? > > The changes in the equinox code are mostly related to: > - jetty8 and jetty7 APIs are identical all code is committed here: > https://github.com/hmalphettes/rt.equinox.bundles/tree/servlet3-jetty8/bundles/org.eclipse.equinox.http.jetty8 > - update the implementation of the servlet APIs to comply with servlet-3.0: > https://github.com/hmalphettes/rt.equinox.bundles/commit/719f9543edc38844dc0a0514cd744bb9135ec6d3 > > I am guessing we could review the code changes, the changes in the > dependencies. > If that looks like it is acceptable we can check the impact on the existing > bundles and look at who is building and packaging things. > > Let me know how to proceed. > Thanks! I would prefer to get the jetty8 bundle into the git repo ASAP. If I may be so bold I would also like to nominate you as a committer on the equinox bundles project so that you can help us maintain the support for Jetty 8. I think the first step is to get a CQ open with a pointer to the git repo for the contribution for the jetty8 bundle. Thanks again Hughes for getting this to work. I had to use the following bundles to get this functioning: Jetty 8: org.eclipse.jetty.continuation_8.0.1.v20110908 org.eclipse.jetty.http_8.0.1.v20110908 org.eclipse.jetty.io_8.0.1.v20110908 org.eclipse.jetty.security_8.0.1.v20110908 org.eclipse.jetty.server_8.0.1.v20110908 org.eclipse.jetty.servlet_8.0.1.v20110908 org.eclipse.jetty.util_8.0.1.v20110908 org.mortbay.jetty.server_6.1.23.v201012071420 org.mortbay.jetty.util_6.1.23.v201012071420 Servlet/JSP APIs: javax.servlet_3.0.0.v201108011116 javax.servlet.jsp_2.2.0.v201103241009 Java EL: javax.el_2.2.0.v201108011116 Jasper for JSP 2.2: org.apache.jasper.glassfish_2.2.2.v201108011116 In order to get the help webapp to work unmodified I created a (silly) org.apache.jasper bundle which simply required org.apache.jasper.glassfish andr re-exported it. With help from Simon A. I also used the proxy approach to implementing ServletContext and that seems to work nicely. It would be helpful to know if the list of jetty 8 bundles above is the absolute minimum set of bundles we need to support this. (In reply to comment #26) > Jetty 8: ... > org.mortbay.jetty.server_6.1.23.v201012071420 > org.mortbay.jetty.util_6.1.23.v201012071420 > We obviously don't need the mortbay bundles anymore ;-) (In reply to comment #26) > Thanks again Hughes for getting this to work. I had to use the following > bundles to get this functioning: > > Jetty 8: > org.eclipse.jetty.continuation_8.0.1.v20110908 > org.eclipse.jetty.http_8.0.1.v20110908 > org.eclipse.jetty.io_8.0.1.v20110908 > org.eclipse.jetty.security_8.0.1.v20110908 > org.eclipse.jetty.server_8.0.1.v20110908 > org.eclipse.jetty.servlet_8.0.1.v20110908 > org.eclipse.jetty.util_8.0.1.v20110908 and no org.mortbay.* as confirmed in the next comment. > > Servlet/JSP APIs: > javax.servlet_3.0.0.v201108011116 > javax.servlet.jsp_2.2.0.v201103241009 > > Java EL: > javax.el_2.2.0.v201108011116 > > Jasper for JSP 2.2: > org.apache.jasper.glassfish_2.2.2.v201108011116 Correct: note that this bundle requires ecj (Eclipse Compiler for Java) or the jdt.compiler to be present. At the moment it does not contain the ecj classes. If we were to run a p2-director install we might end-up with a few more dependencies: javax.transaction, javax.mail.glassfish. Let me know if we need to investigate that in depth. > > In order to get the help webapp to work unmodified I created a (silly) > org.apache.jasper bundle which simply required org.apache.jasper.glassfish and > re-exported it. With help from Simon A. I also used the proxy approach to > implementing ServletContext and that seems to work nicely. > > It would be helpful to know if the list of jetty 8 bundles above is the > absolute minimum set of bundles we need to support this. To make sure we are getting this right. We are shooting for: - servlet+jsp support. - no impact on existing plugins. This looks right, let's double check with the rest of the jetty developers though. (In reply to comment #28) > > > > Jasper for JSP 2.2: > > org.apache.jasper.glassfish_2.2.2.v201108011116 > Correct: note that this bundle requires ecj (Eclipse Compiler for Java) or the > jdt.compiler to be present. > At the moment it does not contain the ecj classes. > > If we were to run a p2-director install we might end-up with a few more > dependencies: javax.transaction, javax.mail.glassfish. > > Let me know if we need to investigate that in depth. Is this because of optional dependencies that get treated as greedy when provisioning with p2. For Juno I believe p2 has a fix that makes optional dependencies truly optional at deployment time. > > It would be helpful to know if the list of jetty 8 bundles above is the > > absolute minimum set of bundles we need to support this. > To make sure we are getting this right. > We are shooting for: > - servlet+jsp support. Correct. > - no impact on existing plugins. We will update the ua webapp to import packages it needs from jasper instead of doing require bundle. I do not want to ship an org.apache.jasper bundle that simply re-exports org.apache.jasper.glassfish because folks put a brittle require-bundle dependency on the old jasper. > This looks right, let's double check with the rest of the jetty developers > though. Thanks Hughes. FYI, I simply used the list you provided in the feature of comment 4 to determine the jetty 8 bundles to use. I would like this list of jetty 8 bundles to be less if possible. I will start opening piggy back CQs for the bundles in orbit which equinox will need to consume for Juno. I will also open up a CQ to accept your jetty 8 contribution. Hugues, please confirm that you wrote 100% of the changes in the following commit and that you intend to contribute it back to Eclipse under the EPL. Thanks. https://github.com/hmalphettes/rt.equinox.bundles/commit/ccef5527af62fe5bad5c281691772ade48db285e (In reply to comment #29) > > Is this because of optional dependencies that get treated as greedy when > provisioning with p2. For Juno I believe p2 has a fix that makes optional > dependencies truly optional at deployment time. > Cnnfirm that p2 has a fix: https://bugs.eclipse.org/bugs/show_bug.cgi?id=247099#c99 > > We will update the ua webapp to import packages it needs from jasper instead of > doing require bundle. I do not want to ship an org.apache.jasper bundle that > simply re-exports org.apache.jasper.glassfish because folks put a brittle > require-bundle dependency on the old jasper. Great. When I tested the help.webapp I found that this dependency on jasper was simply not necessary. > > > This looks right, let's double check with the rest of the jetty developers > > though. > > Thanks Hughes. FYI, I simply used the list you provided in the feature of > comment 4 to determine the jetty 8 bundles to use. I would like this list of > jetty 8 bundles to be less if possible. I think we are missing one bundle: the Javax-El-2.2-RI: com.sun.el_2.2.0.v201108011116.jar This is the minimum list really. Jesse reviewed the list and we tried to see if security and continuations could be removed. It is not possible. If we must have less jars we could add to the jetty build an aggregate with those jars together. More work on the jetty side: no source bundle and no p2 repository for it at the moment. > > I will start opening piggy back CQs for the bundles in orbit which equinox will > need to consume for Juno. I will also open up a CQ to accept your jetty 8 > contribution. > > Hugues, please confirm that you wrote 100% of the changes in the following > commit and that you intend to contribute it back to Eclipse under the EPL. > Thanks. > > https://github.com/hmalphettes/rt.equinox.bundles/commit/ccef5527af62fe5bad5c281691772ade48db285e I did write 100% of the changes and I intend to contribute them back to Eclipse under the EPL. Let me know if you want a git-patch or something. All my commits were made under my eclipse committer's email. (In reply to comment #30) > Great. When I tested the help.webapp I found that this dependency on jasper was > simply not necessary. Great, I would like Chris to confirm. Chris, if this is try could you simply remove the dependency right now, or is there a reason the webapp requires the jasper bundle? > I think we are missing one bundle: the Javax-El-2.2-RI: > com.sun.el_2.2.0.v201108011116.jar > Hmmm, what bundle has a dependency on the packages from this bundle? > If we must have less jars we could add to the jetty build an aggregate with > those jars together. More work on the jetty side: no source bundle and no p2 > repository for it at the moment. No, I don't want to add unnecessary work to the jetty team. We will go with this list of bundles for now. > I did write 100% of the changes and I intend to contribute them back to Eclipse > under the EPL. Great, thanks! > > Let me know if you want a git-patch or something. All my commits were made > under my eclipse committer's email. No need for git-patch. We will be using the process outlined at http://wiki.eclipse.org/Development_Resources/Handling_Git_Contributions If I understand correctly that does not require a patch attachment. (In reply to comment #31) > (In reply to comment #30) > > Great. When I tested the help.webapp I found that this dependency on jasper was > > simply not necessary. > > Great, I would like Chris to confirm. Chris, if this is try could you simply > remove the dependency right now, or is there a reason the webapp requires the > jasper bundle? > > Sigh, wish I could edit bugzilla comments. that should read: Chris, if this is TRUE could you simply remove the dependency right now, or is there a reason the webapp requires the jasper bundle? I opened cross-project bug 360245 to discuss the unfortunate versioning of javax.servlet packages for the Servlet 3 specification. We will need to decide if anything can be done to reduce this potentially breaking change. I'm going to have to investigate this and get back to you. I seem to remember that there was a reason why jasper was needed but I need to dig through my old notes to find out what that reason was and is still valid. (In reply to comment #32) > (In reply to comment #31) > > (In reply to comment #30) > > > Great. When I tested the help.webapp I found that this dependency on jasper was > > > simply not necessary. > > Chris, if this is TRUE could you simply remove the dependency right now, or is > there a reason the webapp requires the jasper bundle? org.eclipse.help.webapp references org.apache.jasper in two places. One is the dependency you noted in MANIFEST.MF. The other is in buildJSPs.xml where it adds org.apache.jasper*.jar to the build classpath. There is also a dependency on org.eclipse.equinox.jsp.jasper registry. If I remove the dependency to org.eclipse.equinox.jsp.jasper registry the help system will not load, I see this HTTP ERROR 500 Problem accessing /help/index.jsp. Reason: Plug-in org.eclipse.help.webapp was unable to load class org.eclipse.equinox.jsp.jasper.registry.JSPFactory. Caused by: org.eclipse.core.runtime.CoreException: Plug-in org.eclipse.help.webapp was unable to load class org.eclipse.equinox.jsp.jasper.registry.JSPFactory. .... org.apache.jasper can be removed from the dependencies and everything seems to work but that is not surprising since org.eclipse.equinox.jsp.jasper.registry depends on org.apache.jasper. (In reply to comment #31) >> I think we are missing one bundle: the Javax-El-2.2-RI: >> com.sun.el_2.2.0.v201108011116.jar > Hmmm, what bundle has a dependency on the packages from this bundle? javax.el is the api and com.sun.el is the reference implementation. Just like jasper is the implementation for the jsp-api. So there is no explicit dependency to com.sun.el but we support jsp-2.2 only when we add a javax-el implementation. If none of the jsp pages use the jsp-expressions I think we don't really need it. (In reply to comment #35) > > org.apache.jasper can be removed from the dependencies and everything seems to > work but that is not surprising since org.eclipse.equinox.jsp.jasper.registry > depends on org.apache.jasper. Chris, indeed I remember encountering this missing class exception. There are a couple more changes required for this port. Here is how the org.eclipse.equinox.jsp.jasper.registry was modified on jetty8-servlet3 branch of equinox bundles: https://github.com/hmalphettes/rt.equinox.bundles/commit/719f9543edc38844dc0a0514cd744bb9135ec6d3 Let me know. (In reply to comment #36) > (In reply to comment #31) > >> I think we are missing one bundle: the Javax-El-2.2-RI: > >> com.sun.el_2.2.0.v201108011116.jar > > Hmmm, what bundle has a dependency on the packages from this bundle? > javax.el is the api and com.sun.el is the reference implementation. > Just like jasper is the implementation for the jsp-api. > So there is no explicit dependency to com.sun.el but we support jsp-2.2 only > when we add a javax-el implementation. If none of the jsp pages use the > jsp-expressions I think we don't really need it. > I assume some bundle does an optional import of the com.sun.el packages? If not I am not sure how the javax-el implementation gets used. For jasper to be used we actually have to import the jasper packages (from org.eclipse.equinox.jsp.jasper). > (In reply to comment #35) > > > > org.apache.jasper can be removed from the dependencies and everything seems to > > work but that is not surprising since org.eclipse.equinox.jsp.jasper.registry > > depends on org.apache.jasper. > Chris, indeed I remember encountering this missing class exception. > There are a couple more changes required for this port. > Here is how the org.eclipse.equinox.jsp.jasper.registry was modified on > jetty8-servlet3 branch of equinox bundles: > https://github.com/hmalphettes/rt.equinox.bundles/commit/719f9543edc38844dc0a0514cd744bb9135ec6d3 > > Let me know. Chris, Equinox will have to change the org.eclipse.equinox.jsp.jasper bundles to handle the new version of jasper as Hugues indicates in his branch. (In reply to comment #35) > org.eclipse.help.webapp references org.apache.jasper in two places. One is the > dependency you noted in MANIFEST.MF. The other is in buildJSPs.xml where it > adds org.apache.jasper*.jar to the build classpath. When is this script run? Is this done as part of the normal build process? For some reason I thought we compiled the JSPs at runtime. > There is also a dependency > on org.eclipse.equinox.jsp.jasper registry. This will be handled separately, we actually use Import-Package here so it is not as brittle of a dependency which allows us to insert the glassfish impl in easily. > > If I remove the dependency to org.eclipse.equinox.jsp.jasper registry the help > system will not load, I see this > > HTTP ERROR 500 > Problem accessing /help/index.jsp. Reason: > > Plug-in org.eclipse.help.webapp was unable to load class > org.eclipse.equinox.jsp.jasper.registry.JSPFactory. > > Caused by: > org.eclipse.core.runtime.CoreException: Plug-in org.eclipse.help.webapp was > unable to load class org.eclipse.equinox.jsp.jasper.registry.JSPFactory. > .... > > org.apache.jasper can be removed from the dependencies and everything seems to > work but that is not surprising since org.eclipse.equinox.jsp.jasper.registry > depends on org.apache.jasper. Right, jasper.registry should be able to isolate the web app from the jasper version we use. (In reply to comment #38) buildJSPs.xml is invoked at build time so the help webapp jsps are always precompiled. I will remove the dependency from org.eclipse.help.webapp to org.apache.jasper, see Bug 360465. (In reply to comment #37) > > I assume some bundle does an optional import of the com.sun.el packages? If > not I am not sure how the javax-el implementation gets used. For jasper to be > used we actually have to import the jasper packages (from > org.eclipse.equinox.jsp.jasper). > Tom, correct: if we want to use com.sun.el as the javax.el implementation we should have it as an optional import of org.eclipse.equinox.jsp.jasper I had missed that so far. The factory pattern is documented here: http://download.oracle.com/javaee/6/api/javax/el/ExpressionFactory.html#newInstance() In the current glassfish version of javax.el-2.2 that we packaged in orbit, the fallback class is "com.sun.el.ExpressionFactoryImpl". So an optional import of com.sun.el in the org.eclipse.equinox.jsp.jasper would do the job. If we were to switch to the tomcat's implementation we would need to import the package org.apache.el I released Hugues contribution in commit: http://git.eclipse.org/c/equinox/rt.equinox.bundles.git/commit/?id=a18668e8865ae512d2e3fdf2397c95acd64b0275 Here are all my changes to date that have been pushed to: https://github.com/simonjarcher/rt.equinox.bundles/commits/sarcher/servlet30 -- Oct 14, 2011 0264729e44173a17a5acaac6d6b02d83d878be97 (Added optional import package statements for javax.servlet.annotation and javax.servlet.descriptor.) 05061131ff99819ac4b8cc9757b3baf3fdaede81 (Added optional import package statements for javax.servlet.annotation and javax.servlet.descriptor.) d3b7332548dcb5a187c00aec3b1fa2b1e947cd55 (Fixed warnings about synthetic methods in JspServlet.ServletContextAdaptor.) b46e79d2c1332425e40c4ba42cde4f77949cdfb6 (Fixed warning about synthetic method in invoke method.) -- Oct 10, 2011 2c698485a085da2f860bd4861bd88f0007dadddc (Applied polish.) 30689578330be4bb49701aef6e0cd89adad1a8df (Applied polish.) -- Oct 6, 2011 3226bef83e295069111efc0df8443383ce63c043 (Simplify proxy implementation.) 069eef013d86909b0fa26a44f6f744d3213da893 (Update exported javax.* package versions to [2.3,3.1).) b65b3c2bffd5358041a0cebc19e01e25ec61e16a (Initial changes for https://bugs.eclipse.org/bugs/show_bug.cgi?id=341643.) Please ignore Comment 42. These comments were intended for bug 341643. *** Bug 362928 has been marked as a duplicate of this bug. *** (In reply to comment #33) > I opened cross-project bug 360245 to discuss the unfortunate versioning of > javax.servlet packages for the Servlet 3 specification. We will need to decide > if anything can be done to reduce this potentially breaking change. See bug 360245 comment 22. It looks like the javax.servlet 3 bundle in orbit will be exporting the packages at version 2.6. We need to react to this in the equinox/eclipse projects and likely for M4. Notice that if we move up to the latest orbit build to pick up the fix for bug360245 then we will need to also pickup a new version of jetty 8 which imports the correct version of the javax.servlet packages (version 2.6 instead of 3.0). (In reply to comment #46) > Notice that if we move up to the latest orbit build to pick up the fix for > bug360245 then we will need to also pickup a new version of jetty 8 which > imports the correct version of the javax.servlet packages (version 2.6 instead > of 3.0). We can track both changes in bug 365354. Isn't this bug resolved as of M4? Yes this was completed for Juno M4. |