Community
Participate
Working Groups
This request is to refactor the internal tomcat and appserver classes and interfaces so that plug-ins can use them. For example org.eclipse.help.internal.appserver.IWebappserver, org.eclipse.tomcat.internal.TomcatAppServer, and related classes. The use case is to enable server-like applications to be embedded in Eclipse, the way the help system works now. Also it may make jsp and servlet development be easier (a plug-in could work with an known version of a servlet container for example).
Originally, the interfaces were meant to be public, but it was thought to not be necessary in the short term, and better j2ee support was likely to be contributed by 3rd party plugins. The request is valid, and we will look at it in the context of the next release.
Marking as P4 - unlikely to be looked at for 3.1.
We have a similar need at another Eclipse open source project ---- BIRT (Business Intellogence & Reporting Rools). We submitted a bug 95063. Unlike this one, however, it was rejected. We feel there will be a stronger need for this feature as more users are now using the embeded Tomcat in Eclipse platform.
Eclipse WTP has a dependency upon the Eclipse Tomcat engine. Will this RFE be implemented in 3.2?
I checked the code and it seems to me that you need the following: 1) Remove the 'internal' references in org.eclipse.help.appserver.server extension point 2) Make 'IWebappServer' interface API 3) Make 'WebappManager' class API Is this all that is needed?
From a code perspective, yes. The decision to have those interfaces internal was concluded by a dynamic team during the 2.1 release. I would vote +1 for making the interfaces public.
Sounds promising - thanks very much. In Eclipse WTP we currently use the AppserverPlugin and WebappManager classes as summarized here. For gory details, see our "CatalinaRunnable.java" file [1] - AppserverPlugin.getDefault().getAppServer().isRunning() - WebappManager.getPort() - WebappManager.start(...) Provided there is public API for this sort of stuff, then from my perspective we'll be happy campers. [1] http://dev.eclipse.org/viewcvs/index.cgi/wst/components/ws/plugins/org.eclipse.w st.ws.explorer/src/org/eclipse/wst/ws/internal/explorer/CatalinaRunnable.java? rev=1.1&cvsroot=WebTools_Project&content-type=text/vnd.viewcvs-markup
Another vote from me! Even though the APIs are unsupported, we have started using them to deploy a plugin/RCP app that generates HTML reports to be viewed in an embedded browser. This is great functionality and it was easy to use (once I figured out the APIs)! If it only takes a little work to expose those APIs, I think you'll see a great ROI on the work.
Please see the OSGi R4 Compendium Spec section on the HTTP service. Does this spec meet your needs? This spec is being implemented in the new org.eclipse.equinox.http bundle at http://eclipse.org/equinox/bundles The HTTP service supports both static content and servlets, so you can do dynamic content as well. It is based on the Java Servlet API v2.1. The service API is not tied to any particular servlet container implementation, however I believe the initial implementation will use Tomcat, although this could potentially change in the future (the API would remain the same though). The reason I would be reluctant to open this is that we would be duplicating the effort of the HTTP service. However, if there is something you cannot do with the HTTP service that you would have been able to do had we opened the appserver, then we need to find a solution.
I can't be sure - I didn't find much in the way of a description of how it would work. Looking at the code for HttpService, I would have to say that while it could be usable, it looks like it would be significantly more effort to use. It appears that servlets would have to be registered manually, via code, with the HttpService. The WebappManager implementation is significantly easier to use and develop for a number of reasons. The most significant being that it allows us to provide a packaged web app (WAR file). This has 2 big benefits for us. First, we deploy our reports in a standalone server version that does not use the Eclipse framework. We already build a WAR file, so packaging is already done. Second, there are good tools for developing a "webapp", including deployment and debugger support. The code I saw would be more like a regular Java app, which would be a big change for experienced webapp developers. I can see a third benefit to this in other contexts - deploying pre-bundled 3rd party apps, which also come as a WAR file. And of course there is the maturity issue. The WebappManager stuff has been around the block and seems pretty solid. The Equinox HTTP looks brand new. In short, it appears that Equinox HTTP is much lower level. While you might want to make use of Equinox in implementing the WebappManager you've already built, the higher-level funcationality that WebappManager seems to provide makes it a better choice for those of us needing to deploy webapps within the Eclipse framework.
Now that we have server functionality and API from Equinox (which we are using in Help now, no longer using Tomcat), I am closing this request. The Tomcat bundle we currently have in help (org.eclipse.tomcat) will eventually be removed, along with org.eclipse.help.appserver. I encourage everyone to use the new Equinox server API. I've done it with Help and it was fairly straightforward, especially with the registry extension points. For those who find that the API is not as high-level/useful/easy-to-use as the internal Help interfaces, you may open an enhancement on Equinox to request improvements. Help is simply not the right component to own general purpose server API (it should be a client of it).
