Bugzilla – Full Text Bug Listing
| Summary: | [Help] Request that servlet.jar be separated into its own bundle | ||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|
| Product: | [Eclipse Project] Equinox | Reporter: | Thomas Watson <tjwatson> | ||||||||
| Component: | Compendium | Assignee: | equinox.compendium-inbox <equinox.compendium-inbox> | ||||||||
| Status: | RESOLVED FIXED | QA Contact: | |||||||||
| Severity: | normal | ||||||||||
| Priority: | P3 | CC: | bogofilter+eclipse.org, dejan, ed.burnette, gunnar, jeffmcaffer, jfogell, kim.moir, simon_kaegi | ||||||||
| Version: | 3.2 | ||||||||||
| Target Milestone: | 3.2 M5 | ||||||||||
| Hardware: | PC | ||||||||||
| OS: | Windows XP | ||||||||||
| Whiteboard: | |||||||||||
| Attachments: |
|
||||||||||
|
Description
Thomas Watson
Created attachment 32028 [details]
Possible content of tomcat.servlet bundle
Created attachment 32029 [details]
patch to tomcat plugin
This is a patch to org.eclipse.tomcat to remove the servlet.jar, remove the javax.servlet* exports and add a Require-Bundle for the new org.eclipse.tomcat.servlet bundle.
*** Bug 122867 has been marked as a duplicate of this bug. *** +1 I understand that this is the servlet imports that org.eclipse.tomcat must use, but I wonder if a slightly more generic bundle name should be considered. e.g. perhaps org.eclipse.servlet javax.servlet org.eclipse.javax.servlet The reason I suggest org.eclipse.tomcat.servlet is because the servlet.jar is code we get from the apache tomcat project. I think keeping "tomcat" in the name of the bundle is probably a good thing. After all it is just a name so we might as well give some indication as to the source of the code ;-) The name of the bundle makes no difference to bundles which simply use Import-Package to access the javax.servlet packages instead of using Require-Bundle. The org.eclipse.equinox.http bundle uses Import-Package so it does not care what the name of the bundle is which is exporting javax.servlet. Ok. I buy it. I see mention of Apache in the servlet.jar Manifest. So... fine makes sense. I agree with Thomas; the name should describe what it actually is. A side question - Thomas, did you make a request to the PMC to introduce this new bundle (or were you assuming we would) ? I need to talk to Jeff about PMC stuff. Jeff is this reasonable? Hmmm, perhaps consider copying the required packages and exporting/importing them. While the approach suggested here is fine in this case, it is not scaleable. It doubles the number of bundles for these kinds of situations. Copying has the downside of impacting dynamic behaviour as it, under the covers, increases the bindings to implementation bundles (since the HTTP serivce bundle would include both the implementation and the interface as would Tomcat). It is not uncommon for service implementation bundles to include the service interfaces that they implement. Any decision here? Jeff seems to be suggesting we put a servlet.jar in the httpservice. I can see an additional benefit for this approach in that an HttpService implementation is pretty much tied to it's particular servlet version. This can still work with an external servlet bundle by doing an optional import and export in the manifest. One way or the other I think we should choose and move on. Given where we are in the project cycle, and the fact that we are currently touching sensitive code in help already to support dynamic content delivery, I would like to avoid adding any more variables into the mix. Help web app critically depends on the current arrangement. If OSGi offers http service and the servler jar in addition to tomcat, we are fine as long as it does not affect help in any way. Post 3.2, we can sandbox this and verify if help functionality is affected in any way. Perhaps the servlet API's can be included in and exported by the org.eclipse.osgi.services bundle? In this case we would not have to create a new bundle which would address Jeff's concern of increasing the number of installed bundles. Also, both TomCat and the HttpService can import the servlet APIs from the same place (TomCat would no longer export or contain the servlet APIs). There would not be the problem of multiple exported Servlet API packages. + 1 on comment 12 It makes more sense to add the servlet.jar to the org.eclispe.osgi.services. The org.eclipse.equinox.http bundle does not export public api but osgi.services does. The osgi.services exports the org.osgi.service.http package which uses the classes from javax.servlet. I propose we add the content of servlet.jar to osgi.services (I would like to extract the binary classes into the root of the bundle just like we did for the osgi ones). Then we would modify the osgi.services exports to be like the following: Export-Package: org.osgi.service.cm; version="1.2", org.osgi.service.component; version="1.0", org.osgi.service.device; version="1.1", org.osgi.service.event; version="1.0.1", org.osgi.service.http; version="1.2"; uses:="javax.servlet,javax.servlet.http", org.osgi.service.io; version="1.0", org.osgi.service.log; version="1.3", org.osgi.service.metatype; version="1.1", org.osgi.service.provisioning; version="1.1", org.osgi.service.upnp; version="1.1", org.osgi.service.useradmin; version="1.1", org.osgi.service.wireadmin; version="1.0", javax.servlet; version=2.3, javax.servlet.http; version=2.3, javax.servlet.jsp; version=1.2, javax.servlet.jsp.resources; version=1.2, javax.servlet.jsp.tagext; version=1.2, javax.servlet.resources; version=2.3 The uses directive on the org.osgi.service.http package ensures that anyone importing the http package must get the same javax.servlet* packages that the exporter does. This will prevent anyone from getting wired to the exports provided by tomcat when using the org.osgi.service.http package. We should also add an Import-Package statement to the osgi.services bundle to allow replacement of the javax.servlet packages: Import-Package: javax.servlet; version=2.3, javax.servlet.http; version=2.3, javax.servlet.jsp; version=1.2, javax.servlet.jsp.resources; version=1.2, javax.servlet.jsp.tagext; version=1.2, javax.servlet.resources; version=2.3 In comment 13 bugzilla wrapped my uses:= line on the org.osgi.service.http package it should be on the same line as org.osgi.service.http Will move this bug to Equinox->Bundles once we agree on the approach. comment 12 and comment 13 seem fine subject to the following reservations: - size increase : this is likely small but it would be good to know how much we are talking about. - not scalable : It would have been good to find an approach that could be applied to there situations. Clearly we cannot just keep adding things to the services bundle. We have not set an example for others. - importing : would services import javax.servlet? What happens when runing on a JRE that has javax.servlet? We might end up in a position where we actually want/need to get the one from the JRE (if there is some interaction with a surrounding container for example. importing - yes in comment 13 I suggest osgi.services bundle importing the javax.servlet packages. If the package happens come from the VM then it will get that package instead. scalable - one option is to move all the packages from the services bundle into the respective bundles which provide implementations for the services. This poses other issues for updatablity. Plus what would we do for packages which we don't have implementations for, leave them in osgi.services? The services bundle is actually pretty small and adding the servlet packages to it will not add much more to it. Ok. My point about scalability did relate to size but also to the general approach. There should probably be some general guidance as to how API should be packaged. Looks ok. Adding "uses" just makes sense. (Note: I used to have problems with this in PDE... haven't tried in a long time though) I'm a little bit concerned about the version interactions. I'm very frequently running on top of a "2.4" container that's going to expose the servlet API from the parent class loader (without the version). Is this going to cause me grief? If someone adds patched osgi.services and tomcat bundles I can try it out. (...or if you wait a few days I can submit these patches) Created attachment 33493 [details] Patch based on comment 13 - merge with osgi.services Tried it out and this approach also works in my environment. The org.eclipse.osgi.services bundle went from 50k to 125k with the addition of the servlet API classes as described above. That's not a big deal in my environment but I suspect this might be a problem in the embedded space if the httpservice is not in use. If it's just a repackaging of an Apache jar file shouldn't it have a name like org.apache.tomcat[.servlet]? Precedents include org.apache.ant and org.junit. The version number would be the Apache version number. Somebody was talking about having "official" plug-in jars for all the Apache projects at one time but I don't know what happened to that. With a few lines added to a jar's manifest, any jar can become an Eclipse compatible library plug-in so maybe the organization responsible for the jar (Apache in this case) could just add what they need to their existing build process to make it spit out Eclipse compatible jars in the first place. Regarding size, please continue to allow the simplest apps to remain as small as possible. Unfortunately at the moment it is not just tomcat but tomcat plus a bit of eclipse glue code (ugh). I agree in the sense that ideally it should be org.apache.tomcat and should contain only tomcat jars and use the tomcat version, etc. I would like to see org.eclipse.tomcat removed in favor of the proper name, eventually. I suspect there may be a reason why it was done this way though. I say this because UA also uses org.apache.lucene for searching, but part of lucene had to be modified in order to work with help, so rather than packaging just jars it contains modified lucene source code that we compile. I would hope that lucene will eventually fix the deficiency/incompatibility (I don't know the details, need to dig into this) and we can eventually move towards "pure" untainted apache bundles that are not specific to the eclipse component that contributes and uses them. I like the idea of official bundles. Thoughts Dejan? It still feels like we should just include the servlet api in the HTTP service bundle. that way the people that need it pay the price and the ones who don't don't. This can result in some update issues however I'm taking a cue here from Peter Kriens who, in another bug in PDE UI, stated that it is "VERY common" for people to include the API types in their implementation bundles. I guess the point hereis that you can include it but there is no guarantee that it will get used. So if someone is worried about update flexibility, they can configure their system with an API bundle and as long as, in this case, the HTTP bundle does import the packages, it can get the API from this other bundle. Adding this to the serivces bundle sets a bad precedent both in terms of mixing concerns and size. ok, I think this fine. I think we should pick an approach and try it out. This is probably one of the better options. Moving forward we may want to move all the service packages out of the osgi.services bundle and into the various service impl bundles? I would be against this because if forces other bundles which import the service packages to have the actual impl bundles to resolve. For example, the equinox.ds bundle imports the org.osgi.service.cm package but it can run just fine with out a cm implemenation. I don't want to prevent equinox.ds from resolving without a cm implemenation. Understood but DS it can import the CM packages optionally right? I don't see any point in refactoring the services bundle as it clearly is a convenience for the OSGi standard services. Adding other stuff (eg., servlet) blurs this. Thus my objection OK, lets make it so. Jennifer, please work on putting the servlet packages in the http bundle. [More debate] Importing as optional is an option :) But it introduces other concerns for the importer because you have to separate all code that references the optional interfaces into separately loaded classes and you have to detect that the optional package is not present and avoid using these classes at runtime. This is probably a good practice, but it is not always the easy thing to do. Another thing about optional imports is that they are not dynamic. If a bundle shows up that exports the optional package then the optional importer needs to be re-resolved to pickup the new package. This has been and continues to be a management issue for us. Hmmm, good point about the optional characteristics. Dare I say DynamicImport-Package? As for the code separation, yes that is true if the types are referenced in the signatures or hierarchy of classes. However, you can have conditional code paths that reference classes that are optional and as long as you don;t execute that code path you are happy. After much disucssion here and elsewhere it seems to have been concluded that we will create a servlet API bundle that will contain the same thing as is in the current 3.2 Tomcat bundle (I believe this is servlet 2.3). we can consider making more versions available if that seems relevant. Again after much discussion the name of the bundle will be org.eclipse.equinox.servlet.api. The fact that it comes from Tomcat does not factor in as there are many sources of this API. The licensing and legal files will correctly attribute the source. The inclusion of "api" in the name positions the bundle as different from an implementation of servlet function. The content should appear soon pending some legal clarifications and wording. Content of new org.eclipse.equinox.servlet.api bundle has been added to the repository. Kim can you update the equinox feature to include this new bundle in the build? Thanks. Done. Also, I had to add org.eclipse.equinox.servlet.api to the core.map for the build to proceed. I just used HEAD as the version, this will have to be changed for the I-build. Thanks Kim, I will tag the new servlet.api project with the rest of the equinox projects for the I-Build today. Is there any plan to remove the servlet.jar from org.eclipse.tomcat or is it being left as is? re: comment 31 I would say it is very unlikely that the tomcat plugin will remove the servlet.jar from their bundle. Given the comments from comment 11 I think the help team views this as too much risk this late in the cycle. That is a correct statement. side note, should this just be supplied as a prebuilt plugin jar? That is, we get the JAR from tomcat and then bundlize it. The contents never change so... also, what did we decide to do about source? The current SDK drop does not have any... - I thought we decided against source. - I'm not sure about the mechanics behind supplying a prebuilt plugin jar. Would we still need a servlet.api project to produce the bundle or is there some other way of doing this. Rumor has it that the Apache Felix project is already building a servlet api bundle. One option would be to somehow use that as is, but it will likely be missing the necessary about.html etc. that we like. I don't think we need the source here. It's easy to get your hands on already and it's really 3rd party stuff so... - I've tried today's SDK drop which works well except I get hundreds of Discouraged Access warnings when creating servlet bundles. Discouraged access: The type HttpServlet is not accessible due to restriction on required library C:\eclipse-SDK-I20060215-0800-win32\eclipse\plugins\org.eclipse.tomcat_4.1.130.v20060212\servlet.jar What do you think the best way to address this is? PDE? remove the x-internal from tomcat's copy? Sorry. I didn't realize that the SDK doesn't include org.eclipse.equinox.servlet.api Adding it to my install or workspace clears up the problem. Seems to me that you should download the equinox feature and use that as your target. Unless you need other bundles from the SDK that are not included in the equinox feature. |