Hadn't thought about that. But now that you mention it, there isn't a dependency between this embedded launcher and the proxy module.
So are you thinking of "launcher(s)" as a new top-level directory under http://svn.apache.org/repos/asf/felix/trunk/ and "webapp" as a module under that? Would it then make sense to move main under launcher(s)? Justin -----Original Message----- From: Sten Roger Sandvik [mailto:[email protected]] Sent: Wednesday, October 07, 2009 11:23 AM To: [email protected] Subject: Re: Default web app integration behavior I also like the start-level-based directory approach. Been using that in my own project for a while now. But, I'm not sure if the launcher should be placed in http submodule. Maybe we should have a launcher subproject? On Wed, Oct 7, 2009 at 4:44 PM, Edelson, Justin <[email protected] > 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]
