On 10/7/09 2:17, Edelson, Justin 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?
Yep. Makes sense and seems reasonable.
-> richard
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]
