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] > > > >
