Community
Participate
Working Groups
CQ 3547 has been approved which includes the necessary classes for jsp 2.1 support. The rt.jetty project would like to have these added to orbit.
Are you an Orbit committer? Are you volunteering yourself to maintain that library?
(In reply to comment #1) > Are you an Orbit committer? > > Are you volunteering yourself to maintain that library? Yes, I'm an orbit committer, You nominated me several years ago Chris. :) I can help maintain and get this into orbit. Copying Simon on this as well since he helped get the other jsp items in place so just want to keep him in the loop.
(In reply to comment #2) > I can help maintain and get this into orbit. Go for it and thanks. The platform is not using this at the moment but likely will be soon and happy to get a hand.
JSF in WTP needs this too.
Hugues Malphettes will be working on this. He's going through Orbit committer voting process now. Once that is complete we'll get this started and in place for M6.
The CQ to add this library is filed (3832). Here is my current suggestion for the logical break-outs of the jsp-api-2.1: 2 bundles: - javax.el-2.1.0.qualifier Depends on javax.servlet-2.5.0 (via Import-Packages) Exports a single package: javax.el - javax.servlet.jsp-2.1.0.qualifier javax.jsp should be a branch of the existing javax.jsp-2.0 maintained by Simon. javax.jsp would contain new sub-packages all as the 2.1 version: javax.servlet.jsp.jstl.core, javax.servlet.jsp.jstl.fmt, javax.servlet.jsp.jstl.sql, javax.servlet.jsp.jstl.tlv, javax.servlet.jsp.resources, javax.servlet.jsp.tagext javax.jsp would depend on javax.el-2.1.0 via an optional Import-Packages. This would in fact add runtime support to javax.servlet.jsp.el which already exists in javax.servlet.jsp-2.0 but lacks the dependency on javax.el to execute. We would make this dependency optional so that projects this new version is backward compatible with the 2.0 version. David Carver was kind enough to review with me whether we should make more bundles to contain those new sub-packages. I believe those packages are best packaged with javax.servlet.jsp: - they are all part of the same spec. - they are still there in the draft of the later version of this spec. - javax.servlet.jsp.resources contains xsd and dtd files and I have seen client libraries of those jsp apis that happily use AClassInJavaxServletJSP.getClassLoader().getResourceAsStream to load those files. Packaging everything in the same bundle will ensure that the client code will work with the bundle in an OSGi container. Please let me know if you would rather have a different packaging of jsp-api. Thanks! Hugues.
After further study: we must separate javax.servlet.jsp and javax.servlet.jsp.jstl javax.servlet.jsp will export the version 2.1.0 of: * javax.servlet.jsp * javax.servlet.jsp.el * javax.servlet.jsp.resources * javax.servlet.jsp.tagext and javax.servlet.jsp.jstl will export the version 1.2.0 of: * javax.servlet.jsp.jstl.core * javax.servlet.jsp.jstl.fmt * javax.servlet.jsp.jstl.sql * javax.servlet.jsp.jstl.tlv I was mislead by the current OSGi packaging of jetty's jsp-api bundle where all those packages are exported under version 2.1.0: this is in fact a bug.
(In reply to comment #7) > After further study: we must separate javax.servlet.jsp and > javax.servlet.jsp.jstl > > javax.servlet.jsp will export the version 2.1.0 of: > * javax.servlet.jsp > * javax.servlet.jsp.el > * javax.servlet.jsp.resources > * javax.servlet.jsp.tagext > > and javax.servlet.jsp.jstl will export the version 1.2.0 of: > * javax.servlet.jsp.jstl.core > * javax.servlet.jsp.jstl.fmt > * javax.servlet.jsp.jstl.sql > * javax.servlet.jsp.jstl.tlv > > I was mislead by the current OSGi packaging of jetty's jsp-api bundle where all > those packages are exported under version 2.1.0: this is in fact a bug. You know they dont' have to be in seperate bundles, to be exported as different versions, right? I am concerned though, if there are packages "in the wild" already exported (incorrectly) as "2.1.0" then exporting these as "1.2.0" even if correct, may cause breakage or not even work. So, this deserves some careful thought and review. Thanks,
(In reply to comment #8) > You know they dont' have to be in seperate bundles, to be exported as different > versions, right? Thanks for the review David. Yes, I am aware that the version exported by a package is actually defined on each package. > > I am concerned though, if there are packages "in the wild" already exported > (incorrectly) as "2.1.0" then exporting these as "1.2.0" even if correct, may > cause breakage or not even work. So, this deserves some careful thought and > review. This jsp-api jar that was contributed to eclipse is a custom packaging of glassfish's sources. The MANIFEST.MF was generated with maven's BND and as far as I know: almost no one uses it in an OSGi environment. I think most people who are developing web-applications in OSGi are relying on spring-DM packages. Those packages are exporting the proper version of jstl: http://www.springsource.com/repository/app/bundle/version/detail?name=com.springsource.javax.servlet.jsp.jstl&version=1.2.0 They are also keeping apart the jstl and the jsp api bundles: http://www.springsource.com/repository/app/bundle/version/detail?name=com.springsource.javax.servlet.jsp.jstl&version=1.2.0&searchType=bundlesByPackage&searchQuery=javax.servlet.jsp.jstl.core In fact, I was porting a spring-web-mvc application to a web-bundle when I found out about this package versioning issue: my experience is that packages in the wild are most likely requiring the jstl packages version to be 1.2.0; I had to repackage my local javax.servlet.jsp.jstl packages to 1.2.0 in order for my application to be able to use spring-webmvc bundle. Would you like to do further investigations regarding possible breakage ? Thanks, Hugues > > Thanks,
(In reply to comment #9) > (In reply to comment #8) > > > Would you like to do further investigations regarding possible breakage ? > Well, I would appreciate if some other "users" of the previous bundles could comment ... Simon? Sounds like you are doing all the right things, but ... just makes me rest easier if others review also. Are you still planning this for M7, as the target field says? I think that'd be best, given the "change" in versioning, etc., I'd prefer people test and/or find problems with an I-build, rather than a milestone build. But, I'm not all that concerned ... if you have reason to push it in today? I'll be promoting the S-build for Helios M6 in a bit. thanks,
(In reply to comment #10) >Sounds like you are doing all the right things, but ... just makes me >rest easier if others review also. I am certainly looking forward to hear from the rest of the team. > Are you still planning this for M7, as the target field says? Yes. > But, I'm not all that concerned ... if you have reason to push it in today? No I am not planning to commit this today: - don't mess up with M6 - more time for review - Wait for one early morning to commit and make sure I am available the rest of the day to correct things with your kind advice. Should I plan tomorrow or sometimes this week? Cheers.
(In reply to comment #11) > (In reply to comment #10) > Should I plan tomorrow or sometimes this week? You could put into cvs anytime, but as for adding it to an Orbit build, for me, the ideal time would be next week. This week many teams will be adopting the latest S-build, and there's some probability we might have to re-create the Orbit S-build if problem are found. In that event, its always easier for me, if there's been no other changes in the build. But, if its important for you or your workflow, I can adapt to any thing (with some simple branching). M6 for all of Helios is not until the 19th, but there's no reason to wait until its completely done. It'd be pretty unlikely we'd respin for any reason next week. Thanks
I think I know one scenario where the "down versioning" will be an issue. Galileo release of Java EE IDE, contains javax.servlet.jsp_2.0.0.v200806031607 javax.servlet_2.5.0.v200806031605 So ... if someone tried to update directly from Galileo to Helios, the "lower" versioned packages would not be "seen" (for any code that specified a range such as [2.0, 3.0). In the past, we've always told people they just had to "start with Helios" and could not update from previous release, but we are trying to change that (see bug 303583). So, what to do? If required, we could just still tell people they had to start fresh ... but, would be good to think through other solutions, if any.
I think it would be good to get this in CVS if it isn't already to take a look as it is starting to get late in the release. I agree that this work should be done in a separate branch from 2.0 vs. a sub-branch and unless there is a really great reason likely would also suggest facturing the JSTL stuff off into it's own bundle. We likely need to be a bit careful here as the platform uses JSP 2.0 to render all the help content and we cannot switch this in this release because of Execution Environment requirements (e.g. run on 1.4 VMs). What this means is that we will likely need to verify that anyone using JSP for Help has got their imports resticted to just 2.0 and not 2.1 as this will end up causing all sorts of class loading problems. JSP 2.1 is clearly going to be used in the various RT projects however my main concern is the IDE. David, is WTP offering tooling that uses JSP 2.1? If so that's the one to watch to see what we bust. We need to avoid breaking Eclipse Help as it used in fair number of commercial products from different companies. Obviously some of these issues are in how we define the platform and not really to do with how JSP 2.1 is bundled however this bug seemed as good a place as any to bring up those concerns even if this discussion later moves to a more appropriate bug.
Yes, WTP will use it for Java EE 6 support. As far as I know, there's nothing tightly coupled to the exact version ... which ever version is "highest" is what will determine what content assist is available, etc. But, Nitin and Raghu would be in a better position to know details.
Taking a look through the platform... we need to update the following bundles with a more restricted import: Orbit ------ org.apache.commons.el 1.0.x org.apache.jasper 5.5.x org.mortbay.server 6.1.x Platform -------- org.eclipse.equinox.jsp.jasper 1.x I'll do this first thing after M6.
(In reply to comment #16) > Taking a look through the platform... we need to update the following bundles > with a more restricted import: > > Orbit > ------ > org.apache.commons.el 1.0.x > org.apache.jasper 5.5.x > org.mortbay.server 6.1.x > > Platform > -------- > org.eclipse.equinox.jsp.jasper 1.x > > I'll do this first thing after M6. Thanks Simon and David for the review and the investigation. One naive question: the version number for javax.servlet.jsp will in fact be higher: 2.1.0.qualifier Only the javax.servlet.jsp.jstl will in fact have a 1.2.0.qualifier version number. I don't think any bundles in eclipse will be affected. Furthermore these new packages will be isolated in a different bundle: javax.servlet.jsp.jstl Am I missing something? Hugues.
(In reply to comment #17) > (In reply to comment #16) > Am I missing something? I think for Simon's comments, he just meant they _want_ to use jsp 2.0, and not 2.1, probably (I'm guessing) since 2.0 is what's been "tested" with the help system since forever, and they have no need for 2.1 features. Also,, I think there's some issues with VM pre-req (I'm guessing) 2.0 requires 1.4, and 2.1 requires 1.5? There might be ways around this last issue, since in a 1.4 environment, the 1.5 bundles simply wouldn't be loaded so as long as 2.0 was also available, all would continue to run. But if nothing else, I'm sure that'd just mean even more testing. There could be other twists and turns I'm not aware of, but suspect that's the basics. My concern would be if anyone used "import package" for, say, javax.servlet.jsp.jstl.core [2.1, 3.0) then they either won't find new one at all, or they my be getting an "old" version, instead of the newer 1.2. I haven't looked for any uses, so far, so just a concern, not a known problem. We need to find some way to communicate this to other projects and adopters and make recommendations for how they should migrate or react under what conditions.
(In reply to comment #18) Ok understood, I was missing on that. Please note that javax.servlet.jsp_2.0 does not export javax.servlet.jsp.jstl.* So a project that would import this would be depending on libraries that are not maintained by Orbit. I am slow on committing those packages to cvs: as part of the preparation to the RT tutorial next week, I was making sure the new packaging of jsp will work nicely with apache-my-faces. As far as Apache Myfaces is concerned they impose a fairly strict range on the version of javax.servlet.jstl.core that they import: [1.2.0,2.0.0) So an erroneous versions of that library would not support myfaces. I had to re-do those bundles anyways as they have a split-package issue. So tomorrow will be ripe for commit in cvs for further review.
Hi David, Just to clarify, javaee 6 requires jsp 2.2, not jsp 2.1. So we will need to add another set of bundles to satisfy that. regards, Jan (In reply to comment #15) > Yes, WTP will use it for Java EE 6 support. As far as I know, there's nothing > tightly coupled to the exact version ... which ever version is "highest" is > what will determine what content assist is available, etc. > > But, Nitin and Raghu would be in a better position to know details.
OK I have finally committed the 3 bundles javax.el, javax.servlet.jsp and javax.servlet.jsp.jstl When I used Sun's reference implementation of java faces with these bundles I found out that sun requires javax.el to use the version number 2.1. So both javax.el, javax.servlet.jsp are committed under the version 2.1 javax.servlet.jsp.jstl is committed under the version 1.2.
I have reviewed the OSGi-entreprise spec that is public since the 23rd of March. Table 128.1 page 418 dictates the versions of the exported packages. They match what the current version of the javax.servlet.jsp* bundles I committed in orbit's cvs. The spec omits to specify the version of javax.el. So let's stick to publishing it under the version 2.1: that is required by Sun's reference implemtation of JSF and it is tolerated by Apache's MyFaces.
I have added the libraries to the orbit build. They are tagged v201003291035 I hope I have not missed something and I am monitoring http://build.eclipse.org:9777/cruisecontrol/ Let me know if I should consider triggering an integration build myself.
OK the bundles are in and they are working for my Web Bundles with jetty-osgi.
I've tightened the import metadata as described in comment 16
To cross reference, see bug 317133 for complications caused by some changes falling out of the changes stemming from this bugzilla. I've not thought through the issues ... just wanted to document there are problems.
