That makes sense to have a standalone module I think. Is it possible to have this bridge independant from the used OSGi HTTP service ?
The example in Karaf should be enhanced to use this module when it's done, as there is a JIRA issue to include the equinox bridge in this example atm. On Wed, Oct 7, 2009 at 18:24, Edelson, Justin <[email protected]> wrote: > I don't think I've fully groked Karaf, but it seems to do a lot of > stuff, not all of which is strictly necessary. So yes, I'd rather see > something simple, yet useable and useful, provided as a standalone > module and let Karaf, Sling, and anyone else build upon this. Again, my > desire is not to say that this is the one true way to embed an OSGi > framework into a J2EE container, but I do think there should be a > sensible default path to do so. Still, it'd be interested to hear > feedback from the people more intimately involved with Karaf. > > Justin > > -----Original Message----- > From: Richard S. Hall [mailto:[email protected]] > Sent: Wednesday, October 07, 2009 11:47 AM > To: [email protected] > Subject: Re: Default web app integration behavior > > I guess the question to ask, is if there is value for being able to do > this without Karaf? If not, then Karaf is the way to go, but if the same > webapp launcher could be used in Karaf and independently, then perhaps > that'd even be more flexible. > > Granted, I don't really know what I am talking about when it comes to > this stuff. ;-) > > -> richard > > On 10/7/09 16:44, Edelson, Justin wrote: >> This seems reasonable enough. It appears to me that Karaf currently >> doesn't really have a webapp launcher. As with the new HttpService >> release, Karaf provides an example to bootstrap Karaf inside a web >> container, but it's just an example, not part of the codebase. I'm >> also not sure if the example will actually work consistently across >> containers - it assumes that ServletContext.getRealPath() will always >> return a non-null value, which isn't the case. >> >> In any case, as I said originally, I'm open to other suggestions on >> how to implement this. I just happen to like the start-level-based >> directory thing that Sling does. >> >> Justin >> >> -----Original Message----- >> From: Sten Roger Sandvik [mailto:[email protected]] >> Sent: Wednesday, October 07, 2009 3:26 AM >> To: [email protected] >> Subject: Re: Default web app integration behavior >> >> I have actually wanted this for a long time. But I always tought this >> was the Karaf idea. Karaf has a webapp launcher, but it's not very >> feature rich. >> Maybe Karaf should have a launcher framework like sling. Possibly >> porting slings launchpad framework to Karaf and make it a little more >> generic. What does the Karaf folks think? >> >> /srs >> >> >> On Wed, Oct 7, 2009 at 2:17 AM, Edelson, Justin >> <[email protected] >> >>> wrote: >>> >> >>> In a sense... One way to look at this is that I'm proposing that the >>> code in >>> http://svn.apache.org/repos/asf/felix/trunk/http/samples/bridge/< >>> http://svn.apache.org/repos/asf/felix/trunk/http/samples/bridge/> > be >>> enhanced, formalized and included as part of the HttpService >>> distribution (in the org.apache.felix.http.proxy jar) rather than >>> having anyone wanting to embed Felix in a webapp write boilerplate >>> >> code based on the sample (or, as I did originally, the Sling > codebase). >> >>> This isn't to say that anyone will be forced to use this; if you want > >>> to write your own ServletContextListener, go at it. I just think >>> Felix >>> >> >>> can establish some default behavior and provide the glue code which >>> implements this behavior. I believe the below defines a reasonable >>> default behavior, but I'm open to other ideas. >>> >>> I am proposing a new launcher in the sense that I'd like to see a >>> standard/default way of embedding Felix in a web container without >>> needing to write any code. Although the 2.0.2 release of HttpService >>> has reduced the amount of code/config necessary to do so (and >>> eliminated a dependency on Equinox's bridge servlet), I think a >>> reasonable default "launcher" is a worthwhile effort, mostly because >>> I >>> >> >>> don't have an overwhelming desire to write the code I describe below >>> more than once and can't imagine I'm the only one who needs/wants to >>> >> do this. >> >>> Does that help to clarify my intent? >>> >>> Justin >>> >>> ________________________________ >>> >>> From: Richard S. Hall [mailto:[email protected]] >>> Sent: Tue 10/6/2009 7:31 PM >>> To: [email protected] >>> Subject: Re: Default web app integration behavior >>> >>> >>> >>> Just to be clear, you are proposing a new launcher for the Felix >>> framework to support web applications? >>> >>> -> richard >>> >>> On 10/7/09 0:27, Edelson, Justin wrote: >>> >>>> As mentioned in the HttpService release thread, I'd like to see a >>>> default >>>> >>> ServletContextListener provided by Felix. I'm happy to provide a >>> patch >>> >> >>> to do this, based on code I've already written (which is, in turn, >>> based on Sling code). Before doing this, I'd like to get some >>> feedback >>> >> >>> on what I believe the default behavior to be. >>> >>>> Here's what I'd like to propose as a starting point for the default >>>> Felix >>>> >>> webapp configuration: >>> >>>> Felix will provide a ServletContextListener in the proxy module >>>> named >>>> >>> DefaultFelixListener. This class will create a configuration map and >>> then instantiate Felix using this map. >>> >>>> The map is populated with: >>>> -- System properties >>>> -- the contents of /WEB-INF/framework.properties >>>> -- servlet context init params >>>> >>>> If this configuration map does not contain either >>>> >>> org.osgi.framework.system.packages >>> org.osgi.framework.system.packages.extra >>> keys, the value of the org.osgi.framework.system.packages.extra >>> property will be created by combining the following: >>> >>>> * the list of compendium packages >>>> * the value of felix.webapp.system.packages.extra (if defined in the >>>> >>> configuration map) >>> >>>> * javax.servlet and javax.servlet.http with a version corresponding >>>> to >>>> >>> the result of >>> ServletContext.getMajorVersion()+"."+ServletContext.getMinorVersion() >>> >>>> The configuration map will also contain an instance of a class >>>> called >>>> >>> BootstrapInstaller (see below), wrapped inside a list, under the >>> felix.systembundles.activators key. Potentially, this this should be >>> extensible using a protected hook method which subclasses can >>> >> implement). >> >>>> (in the example code, #1 and #2 are handled by a separate class, but >>>> >> >>>> I'm >>>> >>> not sure this is a good idea as it makes it harder for downstream >>> users to override the default behavior) >>> >>>> The BootstrapInstaller class, which implements BundleActivator, does >>>> >> >>>> the >>>> >>> following: >>> >>>> * Save the BundleContext in a servlet context attribute named >>>> >>> org.osgi.framework.BundleContext. >>> >>>> * Create a list of subdirectories under /WEB-INF/resources/bundles. >>>> Each >>>> >>> subdirectory name must be parseable as a number. This number will be >>> taken as the start level for the bundles contained within that >>> >> directory. >> >>>> * For each bundle (defined as files ending in .jar or .war) within >>>> each >>>> >>> subdirectory of /WEB-INF/resources/bundles, read the manifest and >>> ensure it has a symbolic name. >>> >>>> * Install or update each bundle: >>>> -- if no bundle with the symbolic name is already installed >>>> -- if a bundle with the same symbolic name is installed, but has an >>>> >>> earlier version >>> >>>> -- if a bundle with the same symbolic name and version is installed, >>>> >> >>>> but >>>> >>> the version ends in "-SNAPSHOT". >>> >>>> * Start all the installed bundles >>>> >>>> This behavior is basically a subset of what Sling currently does >>>> (except >>>> >>> that Sling doesn't deal with war files or have the SNAPSHOT behavior, > >>> both of which I happen to need). Sling also does the "saving the >>> bundle context as a servlet context attribute in a separate >>> BundleActivator, which is reasonable enough). >>> >>>> Thoughts? >>>> >>>> >>>> >>>> >>>> >>> --------------------------------------------------------------------- >>> To unsubscribe, e-mail: [email protected] >>> For additional commands, e-mail: [email protected] >>> >>> >>> >>> >>> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: [email protected] >> For additional commands, e-mail: [email protected] >> >> > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > > -- Cheers, Guillaume Nodet ------------------------ Blog: http://gnodet.blogspot.com/ ------------------------ Open Source SOA http://fusesource.com --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
