Bugzilla – Full Text Bug Listing
| Summary: | Tomcat Viewer in 2.3 | ||
|---|---|---|---|
| Product: | z_Archived | Reporter: | Scott Rosenbaum <scottr> |
| Component: | BIRT | Assignee: | Zhiqiang Qian <zqian> |
| Status: | VERIFIED FIXED | QA Contact: | Xiaoying Gu <bluesoldier> |
| Severity: | normal | ||
| Priority: | P3 | CC: | clin, cyfgod, foxm, jasonweathersby, simon_kaegi, wenfeng.fwd, zqian |
| Version: | 2.2.0 | ||
| Target Milestone: | 2.3.2 | ||
| Hardware: | PC | ||
| OS: | Windows XP | ||
| Whiteboard: | |||
| Bug Depends on: | 199748 | ||
| Bug Blocks: | |||
|
Description
Scott Rosenbaum
One quick note. I tested BIRT under Jetty 6.1. I had to add commons-logging to the container, but other than that everything seemed to work fine. That said, the entire Jetty download and install process is less professional than Tomcat. My preference is that if we are going to have a reference web container would be to have it stay on Tomcat. sr I got this summarization of the move from Tomcat to Jetty from Jeff McAffer on the platform team. I thought it might help anyone that is tracking on the issue....sr Basically the Jetty move was the result of several disjoint steps. The first was the desire to have a real, fully functioning implemention of the OSGi HTTP service. In Equinox we have had an HTTP service implementation for a while but it has had various issues from functional completeness and currency to performance. After looking around, Jetty was identified as the best candidate for *embedding in Eclipse*. It is small, fast, easily embeddable and there happened to be someone who was volunteering to do that work. To date we have not seen any viable embedded Tomcat (or other reasonable open source server) scenarios implemented. So with that we had a working, in-framework HTTP service as part of the various things that Equinox provides. The second step was the Help team's long standing need to move off the Tomcat they were providing. There were serveral reasons. - Their version of Tomcat was old. - People were pressuring us to expose the Tomcat as API. that is, people wanted to use the Tomcat supplied by us for their own purposes when in fact it was an internal implmentation detail of the Help system - Add 1 + 2 and you get people wanting the Help team to stay current on Tomcat. They are in the Help business no the app server business - Tomcat is relatively large and heavy for what they need An HTTP Service implemenation (any one that supported JSPs etc) supplied by another party (anyone trustworhty) represented a solution to these issues. Jetty was one such implementation that, from their point of view, is available, supported, addressed their requirement and, in the end, is not their problem. So, with the full blessing and support of the Eclipse PMC, they moved to Jetty. Note that we are getting pressure to update the version of Jetty :-) Anyway, with the Help move, there is no need for the Eclipse project to continue managing or shipping Tomcat. For us it was never API. Following the precedence set by the Xerces-situation of the past, we plan to stop shipping that which is no longer required by us. The curent Tomcat (i.e., the old one we have been shipping) can continue to be made available for projects that need it (it can live in Orbit indefinitely) but we have no plans to update the version or do any other work on that front. As for the puzzle, I hope this helps somewhat. I know that there are bugs in the Equinox world talking about using Jetty for an HTTP service. There are also bugs related to moving Help onto Jetty. And there is the bug you see for removing Tomcat. This matches my picture of how this has come about. Jeff McAffer In the Europa time, WTP used tomcat as well. It has already moved onto to JeTTy for the Ganymede release. Has switched to Jetty Http Service. But it still has some issues, for example: doesn't support ServletContext init parameter.... Please check the bug: https://bugs.eclipse.org/bugs/show_bug.cgi?id=199748 That bug does not represent a set of "planned" items, just "proposed" items. Perhaps we can be pragmatic. You mention ServletContext initparams support. Is that all that BIRT requires to make the move? Hi Simon, Thanks for your attention. When I move BIRT Viewer from Tomcat to Jetty Http Service, I met the following issues that will introduce some regression bugs. 1) Can't register servlet context init parameter. Now we just use the default value. 2) Can't register listener and filter. 3) When use ServletContext getRealPath method, it returned null. But support getResource method. ( use a workaround way to handle it ) 4) When use request.getServletPath method in JSP file, it returned null. In servlet, it worked well. ( also use a workaround way to handle it ) So all these issues will depend on Jetty Http Service implementation. Thanks. Please forgive my ignorance. Has BIRT formalized the decision to use Jetty now? (From the previous comments, BIRT appears to be heading in that direction, but still need to get thse 4 issues in Comment #6 resolved.) yes, from 2.3 build, BIRT viewer has been based on Jetty Http Service. Since eclipse Equinox team has no plan to fix it, need defer it. (In reply to comment #9) > Since eclipse Equinox team has no plan to fix it, need defer it. Jerry, please log a bugzilla against the jetty component in the Equinox project, and then mark this bug as blocked by the Equinox bug. (In reply to comment #10) > (In reply to comment #9) > > Since eclipse Equinox team has no plan to fix it, need defer it. > Jerry, please log a bugzilla against the jetty component in the Equinox > project, and then mark this bug as blocked by the Equinox bug. Yes, have done it. Please refer to bug: https://bugs.eclipse.org/bugs/show_bug.cgi?id=199748 I'm closing this now as it's already been a long time since BIRT viewer had migrated to Jetty, and currently it works well under both Embedded Jetty and Tomcat. Verified in <2.5.0.v20081222-0630>. |