Sriram, In my view the answer is in the message you replayed to. An extender/whiteboard bundle will do the trick for your requirements. As I see there is a request for such a feature and can be a good addition to pax extender "family". So, why don't you start to implement it under Pax umbrella? I'm pretty much busy right now with some other requirements so I cannot do it right away but I can "help" if necessary. And here here can be at least two approaches:
1. Using an white board pattern as pax web extender whiteboard and then based on the context id (already in place) share the http context between the bundle. You can start from the current code by allowing bundles to share the context by id and changing HttpContextProxy in order to use all the bundles/registered context. 2. For the ones that do not want to use the whiteboard approach and want to use something similar to HttpService approach you can have a kind of proxy bundle that registers a service with the same interface as HttpService/WebContainer (from pax web) and act as a composite service. So, when do you start? :) Alin On Tue, Mar 11, 2008 at 2:55 AM, Sriram Muthuswamy Chittathoor <[EMAIL PROTECTED]> wrote: > The following statements summarizes my need as well. > > 1. Bundles need to share the HttpSession and the > > ability to forward from a servlet in one bundle to a servlet/JSP in > another > > 2. Modular web application where different bundles > > contribute servlets, JSPs, and resources to a single logical > application" > > So what are the possible approaches available today to solve these. > > > Thx > > Sriram C > > > > > > -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of Alin Dreghiciu > Sent: Sunday, February 24, 2008 10:51 PM > To: General OPS4J > Subject: Re: Sharing an HttpContext between bundles > > On Mon, Feb 25, 2008 at 12:18 AM, Michael <[EMAIL PROTECTED]> wrote: > > Hi Alin, > > > > > > > 1. we do not allow an http context to be registered by more bundles. > > > Simple to implement, blocks your use case, but not really. What you > > > could do is that you could register an http context that delegates > to > > > your shared between bundles context. Right away I see a disadvantage > > > of not being possible to share servlet context attributes between > > > bundles. Do yo need that? If yes I may come up with a solution where > > > if your registered http context implements a custom interface that > can > > > set/get attributes, then attributes handling will be delegated to > http > > > context and you can further delegate to the shared context. > > > > Specifically, I need the bundles to share the HttpSession and the > ability to > > forward from a servlet in one bundle to a servlet/JSP in another. I > could > > delegate to a shared HttpContext but that only helps with resource > loading > > if I'm not mistaken. Each bundle would still have its own > ServletContext > > and hence, my two use cases aren't satisfied. > > Correct. > > > > > > > > Now your use case. Let me know that I understood correctly that you > > > basically want to share a servlet context between more bundles and > you > > > want to do so by sharing the http context between those bundles, > http > > > context that acts as a composite context by being able to load > > > resources from bundles that share the same http context. Correct? > > > > > > > Yep, that's what I'd like to do. Ultimately, I want a single servlet > > context for all of my application bundles. Shared HttpSession, > forwards, > > attributes, etc. > > > > My current work around is to write an extender bundle that is > responsible > > for registering all servlets and JSPs. It will discover the servlets > and > > JSPs that my application bundles provide and then register them with > the > > WebContainer. I'll have to write a custom HttpContext that knows how > to > > load resources from the discovered bundles. One disadvantage to this > > approach is that JSP TLDs will have to be in the extender bundle, not > the > > application bundles. If the JSP support searched imported packages > for > > TLDs, I could avoid that. > > Your approach with an extender bundle sounds good to me. Even if we > allow bundles to register using a shared http context you will still > have to somehow let the bundles that registers servlets know about > that shared http context and the shared context know how to use the > bundles to search for resources. The extender approach looks more > elegant to me and you can do more as you can simplify the registration > process using the extender. > > About the TLDs, I was planing to implement this feature = search also > the imported packages for TLDs files. Question is it should search for > all files with a TLD extension regardless their path (as in /**/*.tld) > or should as in a normal web app search only WEB-INF and > subdirectories (as in /WEB-INF/**/*.tld) ? > Create a jira issue for it and I will work on it by the end of next > week. Or you can work on it, after all is open participation :) > > > > > Is there a simpler way to share a ServletContext across bundles? > Not as now and adding it I would say that it only brings n complexity. > But you never know. > > > > > Thanks, > > Michael > > _______________________________________________ > > general mailing list > > general@lists.ops4j.org > > http://lists.ops4j.org/mailman/listinfo/general > > > > > > _______________________________________________ > general mailing list > general@lists.ops4j.org > http://lists.ops4j.org/mailman/listinfo/general > > _______________________________________________ > general mailing list > general@lists.ops4j.org > http://lists.ops4j.org/mailman/listinfo/general > _______________________________________________ general mailing list general@lists.ops4j.org http://lists.ops4j.org/mailman/listinfo/general
