On 10/7/09 17:57, Sten Roger Sandvik wrote:
// srs
Den 7. okt. 2009 kl. 17.46 skrev "Edelson, Justin"
<[email protected]>:
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)?
Yes, that would be the best thing I think. Launcher top level, then
base, main, webapp as second level.
If we create a launchers directory, yes, I think main should be moved
too...although this could bum some people out who pull main from the
maven repos...I guess they will have to update their artifactId.
-> richard
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 hasan
earlier version
-- if a bundle with the same symbolic name and version isinstalled,
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]
---------------------------------------------------------------------
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]
