Bugzilla – Full Text Bug Listing
| Summary: | Servlet Bridge using Web Application Specification | ||||||
|---|---|---|---|---|---|---|---|
| Product: | [Eclipse Project] Equinox | Reporter: | Ralf Zahn <ralf.zahn> | ||||
| Component: | Server-Side | Assignee: | equinox.server-side-inbox <equinox.server-side-inbox> | ||||
| Status: | CLOSED WONTFIX | QA Contact: | |||||
| Severity: | normal | ||||||
| Priority: | P3 | CC: | alasdair, gunnar, raymond.auge, tjwatson | ||||
| Version: | unspecified | ||||||
| Target Milestone: | --- | ||||||
| Hardware: | PC | ||||||
| OS: | Windows 7 | ||||||
| Whiteboard: | |||||||
| Attachments: |
|
||||||
|
Description
Ralf Zahn
Created attachment 190849 [details]
Solution for the BridgeServlet
See my patch for a possible solution. This solution does not influence any existing usage of the BridgeServlet.
(In reply to comment #0) > Build Identifier: > > I want to use the BridgeServlet within WebSphere Application Server, which > provides an OSGi platform to the Java EE developer. The BridgeServlet currently > internally launches an OSGi framework. An init parameter of the servlet should > influence it to prevent launching a framework. > > Reproducible: Always > > Steps to Reproduce: > 1. Run the Bridge Servlet within WebSphere Application Server (V7 with OSGi FEP > or V8) Can you include more information about what is failing here. My understanding of the OSGi FEP is that it embeds an Equinox OSGi runtime similar to how the servlet bridge does. Both embedded Equinox frameworks should be able to run independently from each other. Maybe they can run independently. But the framework embedded by the BridgeServlet is not used. (And it needs time to start, memory ...) In general, the BridgeServlet has the responsibility to forward incoming requests from the web container to an OSGi framework (using the OSGi Http Service). Always forwarding to an embedded OSGi framework is a strategy that does not match the architecture of WebSphere (incl. Apache Aries) So the developer (or the deployer) has to decide whether or not an OSGi platform with Http Service is already provided by the runtime. (In reply to comment #3) > Maybe they can run independently. But the framework embedded by the > BridgeServlet is not used. (And it needs time to start, memory ...) > > In general, the BridgeServlet has the responsibility to forward incoming > requests from the web container to an OSGi framework (using the OSGi Http > Service). > Always forwarding to an embedded OSGi framework is a strategy that does not > match the architecture of WebSphere (incl. Apache Aries) > So the developer (or the deployer) has to decide whether or not an OSGi > platform with Http Service is already provided by the runtime. But why are you using the serlvet bridge when developing an application for apache aries? Is this because you need an HttpService implementation for an application you are deploying to Aries? Instead of using the BridgeServlet you can use the HttpServiceServlet (from org.eclipse.equinox.http.servlet) to expose a web container as a HttpService directly if the web container already exposes an OSGi framework. But I'm not sure how this will work. The HttpService is bound to the servlet which is bound to the session and context from the single web application. Thus, the framework provided by the application server somehow must ensure that only the bundles within the same web application can see the HttpService. I have generalized the title of this bug, because I guess the problem is the missing of another Bridge Servlet that uses the OSGi Web Application Specification to - read the BundleContext from the ServletContext, - register a Service Tracker at the OSGi platform to listen to the lifecycle of the OSGi HttpService and - delegate incoming requests to the OSGi Http Service, if available Disable to framework launching within the BridgeServlet was one part of the solution, but there are still some classloader-specific things (like the static BridgeServlet reference). I guess there should be another class providing the WAB-2-HttpService bridge. I plan to write and test such a solution at the end of this week. @Gunnar
Seems that the HttpServiceServlet is what I need.
> Thus, the framework
> provided by the application server somehow must ensure that only the bundles
> within the same web application can see the HttpService.
Yes, it does. Bundles within one EBA are isolated from other bundles. An EBA is started within its own framework on the server, so the HttpService is only accessible from within the EBA.
Closing due to inactivity. |