Add support for DynamicJava's Servlet Bridge [PAXRUNNER-269]

[ops4j-issues]

Thomas Joseph created PAXRUNNER-269

Originally Suggested by Craig Walls:

The Servlet Bridge provided by DynamicJava (DynamicServlet-Bridge) allows Web Applications to delegate HTTP requests to OSGi services that implement the Servlet interface.

Pax Runner can support this Servlet Bridge by providing a servlet context listener which will start the Pax Runner, and then provide the bundle context to the servlet context, which the Servlet bridge needs to do the bridging.

---

Votes: 0, Watches: 0

[ops4j-issues]

Thomas Joseph commented

Once we have this, we can look forward for something sort of an executor that can produce a standard war file with the bridge configured.

Probably something sort of pax-run.sh --executor=war should give produce the war file that can be deployed on any standard Servlet container.

[ops4j-issues]

CraigC commented

At long last, I'm thinking about this again...

To be clear, what I'd really like to do is build a very skinny WAR file that does little more than (1) start up Pax Runner, placing a bundle context in the servlet context and (2) include a servlet bridge that delegates requests to services that implement the servlet API. The actual bundles that Pax Runner starts up shouldn't be packaged up in the WAR (otherwise, what is the benefit?)--instead, Pax Runner could be configured (I'm thinking via context params or some such in web.xml) to load its contents from elsewhere...perhaps as simple as a composite defined at some location that contains the full Pax Runner provisioning spec.

With the bundles residing elsewhere, you get all of the benefits of OSGi, but the corporate-comfort of deploying a WAR file into whatever web container they support or have invest in.

As far as configuring Pax Runner is concerned, I would want to be able (at minimum) to specify...

• The OSGi implementation (Equinox, Felix, Knopflerfish, etc)
• The location of a composite provisioning specification
• Pax Runner's working directory

Of course, it'd be ideal to be able to configure everything that can be configured.

I can't imagine this being hard. All that's really needed is a context listener to start Pax Runner. What I'm imagining is a context listener that has a line in it that looks something like this (pseudo-ish code):

BundleContext context = new PaxRunner(configuration).start();

This isn't, of course, real code...the class/method names aren't actual parts of the Pax Runner API...but this line serves to describe what I have in mind.

So, the big question for me is: Is it possible to programmatically start Pax Runner and to get a BundleContext from it once it has started? If the answer is "yes", then writing the servlet context listener to tie it up with the servlet bridge will be easy.

[ops4j-issues]

CraigC commented

Further thoughts...

This bridge solution will make it possible to realize the benefits of OSGi even though the app (at least a very skinny front-end portion of the app) is deployed in a traditional Java web server. It does so only for servlet-bound requests, however. What about other types of requests? What if the request is for some static artifact such as an image or CSS file?

With the bridge solution alone, those kinds of files would either need to reside in the WAR file alongside the bridge or be served via some proxy servlet. Neither of these approaches is ideal, IMO.

This led me to thinking about the bridge servlet be paired up with a bundle in the OSGi framework (I'm calling it the delegate bundle for lack of a better name). It would be that delegate bundle's BundleContext that is given to the servlet for bridging purposes. But also, the bridge servlet could use the BundleContext.getBundle().getResource() to retrieve resources that reside in the delegate bundle.

So what? We've shifted static artifacts from being in the WAR to being in the delegate bundle...what good does that do us? Not much...unless the static artifacts aren't really in the delegate bundle but are actually in a fragment that is hosted by the delegate bundle.

Not sure if any of this would work...but I'm offering it here as food for thought.

[ops4j-issues]

Thomas Joseph commented

Craig, some time back I spent few hours on this. I had discussed this in the mailing list http://www.mail-archive.com/general@lists.ops4j.org/msg07635.html.

To get the bridge implemented, it is necessary to get a handle of the started OSGi framework from the Pax Runner, that at present is not implemented. I created an associated issue for this PAXRUNNER-288 . Once this issue is resolved, I guess, making up a bridge for pax runner should be trivial.