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]
