Community
Participate
Working Groups
The current org.eclipse.equinox.http.registry plugin is supporting three extension points, which enable the usage of the OSGi based HTTP service via Eclipse styled extension point mechanism: httpcontexts, servlets, resources. These extension points duplicates more or less the J2EE compliant configuration which is typically made within WEB-INF/web.xml. This enhancement request addresses this issue designing an additional extension point which is better supporting the J2EE compliant project style. A folder can be contributed to this extension point, which is structured like a standard J2EE web application. All resources available within this web application will be dynamically registered, so that there will be no need for manual registration each individual servlet or resource. A given WEB-INF/web.xml file can be used to retrieve - all servlets - all filters - welcome pages - security configuration A typical example how to use could be: <extension point="org.eclipse.equinox.http.registry.webapp"> <webapp alias="/" path="/WebContent"> </webapp> </extension> A detailled specification including extension point schema is attached, discussion with Simon Kaegi has been done in advance. Implementation will be started now, and contributed to this bugreport.
Created attachment 52625 [details] Specification of webapp extension point
cool
Attached a first implementation of the webapp extension point and more. I attached a ZIP file with all implementation and test bundles, and a docs project (just started a tutorial). I also attach a PSF file, where you can directly import from CVS HEAD at sse-examples@SF. I split the implementation into three parts: - org.eclipse.equinox.webpp.service - org.eclipse.equinox.webpp.registry - org.eclipse.equinox.webpp.extender The overall web.xml processing will be done in webapp.service. The registry is (as http.registry) same functionality as extension point. I just started work on an "extender" pattern, which will observe all started/stopped bundles, checks for existence of WEB-INF/web.xml, and then automatically registers a web application at HttpService. This is my long term goal, to support transparent web application deployment into OSGi platform. It supports now Filters and welcome files. The registration of resources, servlets will be done via a registration policy, where I support two different: "simple", where each context will be registered at its root, or "cluttered", where only the leafs of the resource tree will be registered. This allows mixing resources from different bundles, which we need for our purposes. There will be a OSGI-INF/default-web.xml, where JspServlet, Mime-types will be supported as a default. My goal is to make jsp-examples, struts-examples, etc. directly runnable without any adaption of web.xml. See also launch configurations and tests: There is for each scenario a launch configuration and corresponding test cases. Major open issues are: - welcome files does not yet work with simple registration policies - JSP files will not be compiled when the bundleResourcePath is "/" (it is a bug somewhere between JSP and webapp) - support listeners - think about dependencies between webapps - cleanup of a lot of code - start handling declarative security. Any feedback welcome.
Created attachment 78481 [details] WebApp implementation, test cases, docs (part1)
Created attachment 78482 [details] WebApp implementation, test cases, docs (part2)
Created attachment 78483 [details] WebApp implementation, test cases, docs (part3)
Created attachment 78484 [details] Project Set File for sourceforge.net/projects/sse-examples, webapp-incubator (HEAD)
Any update?
We have had and will have almost no time to work on the server side in the coming release. Without solid/ready to use contribution very little will happen in the server side area.
This extension point sounds like something we can really make use of for the Web Services Explorer webapp in WTP. In previous releases, the WSE was pre-compiled and packaged as a WAR and runs on the internal Tomcat engine. In WTP 3.0, we switched to using Jetty but we are no longer pre-compiling the pages because that will result in over 300 servlets, and it's not that practical to register each one of them. The pre-compile already gens a web.xml full of servlet mappings and it would be great if we have this new extension point to parse that and register the servlets.
I've been doing some progress on this bug developing a web application service and extension point, which provides a first implementation draft. The basic idea has been posted to Equinox mailing list, see [1]. For more information see also slides from a short talk I had at EclipseCon 2008 [2]. The current state of implementation is: - core functionality is available: web.xml parser, registering servlets and filters, jsp compiling, API draft, extension point - planned features are: welcome files, listeners - postponed features are: security I've to be honest that there are too few test cases, and a documentation/tutorial is missing. I am doing development in an incubator area at a sourceforge project shared with Simon Kaegi: See [3] or use project set file at [4]. I would like to propose (to avoid blocking bug 214166): - I will provide WTP project a first version which can be included for a first integration test (hopefully in 1-2 weeks) - If the API and implementation is applicable, we should move the implementation to Equinox incubator project - gather feedback from Equinox project and community about API and its implementation Feedback welcome. References: [1] http://dev.eclipse.org/mhonarc/lists/equinox-dev/msg02957.html [2] http://www.eclipsecon.org/2008/?page=sub/&id=244 [3] http://sse-examples.cvs.sourceforge.net/sse-examples/webapp-incubator/ [4] http://sse-examples.cvs.sourceforge.net/*checkout*/sse-examples/webapp-incubator/org.eclipse.equinox.webapp.docs/docs/org.eclipse.equinox.webapp-HEAD.psf?revision=1.2
Is there a plan for when this enhancement will be completed? As Andrew mentioned in comment 10 it would be great if we could go back to pre-compiling the Web Services Explorer.
vote + 1 for this. It's really confusion that this extension point not there. And Google takes me to this bug.
This type of thing should be done the OSGi R6 Http whiteboard specification which has been implemented in Mars. No plans to enhance the http registry implementation in Equinox to do this.
