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]
