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
