Hi, Sorry for jumping in late, but let me state my POV living in both the Felix and Sling worlds ...
One goal we have in Sling is to create a launcher which is available as a web application and as a standalone Java application and to have as minimal environment specific code as possible. For now we have two standalone application specific classes and a single web specific class (a Servlet not a ServletContextListener). Everything else is shared so is the complete launchprocess and thus is unified. If the Felix community would be interested to take over the maintainance of the laucher and/or merge it with stuff we already have here (Felix Main and Karaf), fine. And chances are that the Sling community would agree to contribute the launcher to Felix. Edelson, Justin schrieb: > 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. I wonder, why you did not propose your extensions to Sling ? It would be interesting to hear, what you need and whether we could embrace them. > > 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 These are problematic in a servlet and application container environment. For example for the WebSphere App Server which is based on Equinox it contains properties which interfere with the Apache Felix container. As a result in the Sling Web launcher we do *not* include sytsem properties by default. > -- 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). This SNAPSHOT support might be an interesting add-on to the Sling launcher. Could you provide a patch ? Regards Felix --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
