On Mon, Feb 28, 2011 at 1:55 PM, Neil Bartlett <[email protected]> wrote: > Bram, > > The HttpContext can load resources from wherever it likes, based on > whatever rules it chooses. > > The implementations in Felix etc that you have found are just that: > implementations. They do not imply any constraint on other potential > implementations.
Ok, clear enough. Thank you (and Peter in the other response) for the quick reply and setting my mind at ease :) Regards, Bram > Regards, > Neil > > On Mon, Feb 28, 2011 at 12:36 PM, Bram de Kruijff <[email protected]> > wrote: >> Hello list, >> >> my question is whether it is valid to have a HttpContext that itself >> is backed by multiple bundles that is uses to load whatever resources >> based on its own implementation. The simple straightforward answer, I >> thought, is yes. HttpContext is an interface so it can be anything as >> long as it holds its end of the deal, right? >> >> The reason for asking is that I ran into several implementations >> (Felix Whiteboard / PAX Web) that seem to binding the HttpContext >> instance registration to the Bundle (id) that is registering it >> preventing reuse over multiple bundles (unless you know the other >> bundle's id or some other dirty trick based on impl knowledge). >> >> The spec (R42) as far as I see does not say anything that prevents me >> from taking this approach. However, besides my HttpContext is an >> interface assumption, it also does not explicitly state that it must >> be allowed. So, is it allowed and/or are there pressing reasons why >> this could be considered bad practice that would motivated binding to >> one bundle? >> >> Thanks so much, >> Bram >> _______________________________________________ >> OSGi Developer Mail List >> [email protected] >> https://mail.osgi.org/mailman/listinfo/osgi-dev >> > _______________________________________________ > OSGi Developer Mail List > [email protected] > https://mail.osgi.org/mailman/listinfo/osgi-dev > _______________________________________________ OSGi Developer Mail List [email protected] https://mail.osgi.org/mailman/listinfo/osgi-dev
