Default web app integration behavior

[justinedelson]

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?

[Richard S. Hall]

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: users-unsubscribe@...
For additional commands, e-mail: users-help@...

[justinedelson]

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:heavy@...]
Sent: Tue 10/6/2009 7:31 PM
To: users@...
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: users-unsubscribe@...
For additional commands, e-mail: users-help@...

[Sten Roger Sandvik]

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 <Justin.Edelson@...
> 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:heavy@...]
> Sent: Tue 10/6/2009 7:31 PM
> To: users@...
> 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: users-unsubscribe@...
> For additional commands, e-mail: users-help@...
>
>
>
>

[Rémon. Sinnema]

----- Original Message ----

From: "Edelson, Justin" <Justin.Edelson@...>
To: users@...
Sent: Wed, October 7, 2009 2:17:50 AM
Subject: RE: Default web app integration behavior

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

+1





---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@...
For additional commands, e-mail: users-help@...

[Richard S. Hall]

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:heavy@...]
> Sent: Tue 10/6/2009 7:31 PM
> To: users@...
> 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: users-unsubscribe@...
> For additional commands, e-mail: users-help@...
>
>
>
>
>    

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@...
For additional commands, e-mail: users-help@...

[justinedelson]

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:srs@...]
Sent: Wednesday, October 07, 2009 3:26 AM
To: users@...
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
<Justin.Edelson@...
> 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:heavy@...]
> Sent: Tue 10/6/2009 7:31 PM
> To: users@...
> 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: users-unsubscribe@...
> For additional commands, e-mail: users-help@...
>
>
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@...
For additional commands, e-mail: users-help@...

[Sten Roger Sandvik]

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 <Justin.Edelson@...
> 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:srs@...]
> Sent: Wednesday, October 07, 2009 3:26 AM
> To: users@...
> 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
> <Justin.Edelson@...
> > 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:heavy@...]
> > Sent: Tue 10/6/2009 7:31 PM
> > To: users@...
> > 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: users-unsubscribe@...
> > For additional commands, e-mail: users-help@...
> >
> >
> >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@...
> For additional commands, e-mail: users-help@...
>
>

[justinedelson]

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)?

Justin

-----Original Message-----
From: Sten Roger Sandvik [mailto:srs@...]
Sent: Wednesday, October 07, 2009 11:23 AM
To: users@...
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
<Justin.Edelson@...
> 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:srs@...]
> Sent: Wednesday, October 07, 2009 3:26 AM
> To: users@...
> 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
> <Justin.Edelson@...
> > 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:heavy@...]
> > Sent: Tue 10/6/2009 7:31 PM
> > To: users@...
> > 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: users-unsubscribe@...
> > For additional commands, e-mail: users-help@...
> >
> >
> >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@...
> For additional commands, e-mail: users-help@...
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@...
For additional commands, e-mail: users-help@...

[Richard S. Hall]

I guess the question to ask, is if there is value for being able to do
this without Karaf? If not, then Karaf is the way to go, but if the same
webapp launcher could be used in Karaf and independently, then perhaps
that'd even be more flexible.

Granted, I don't really know what I am talking about when it comes to
this stuff. ;-)

-> richard

On 10/7/09 16:44, Edelson, Justin 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:srs@...]
> Sent: Wednesday, October 07, 2009 3:26 AM
> To: users@...
> 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
> <Justin.Edelson@...
>    
>> 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:heavy@...]
>> Sent: Tue 10/6/2009 7:31 PM
>> To: users@...
>> 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: users-unsubscribe@...
>> For additional commands, e-mail: users-help@...
>>
>>
>>
>>
>>      
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@...
> For additional commands, e-mail: users-help@...
>
>    

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@...
For additional commands, e-mail: users-help@...

[Sten Roger Sandvik]

// srs

Den 7. okt. 2009 kl. 17.46 skrev "Edelson, Justin" <Justin.Edelson@...
 >:

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

> Justin
>
> -----Original Message-----
> From: Sten Roger Sandvik [mailto:srs@...]
> Sent: Wednesday, October 07, 2009 11:23 AM
> To: users@...
> 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
> <Justin.Edelson@...
>> 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:srs@...]
>> Sent: Wednesday, October 07, 2009 3:26 AM
>> To: users@...
>> 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
>> <Justin.Edelson@...
>>> 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:heavy@...]
>>> Sent: Tue 10/6/2009 7:31 PM
>>> To: users@...
>>> 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: users-unsubscribe@...
>>> For additional commands, e-mail: users-help@...
>>>
>>>
>>>
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@...
>> For additional commands, e-mail: users-help@...
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@...
> For additional commands, e-mail: users-help@...
>

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@...
For additional commands, e-mail: users-help@...

[Richard S. Hall]

On 10/7/09 17:57, Sten Roger Sandvik wrote:

>
>
> // srs
>
> Den 7. okt. 2009 kl. 17.46 skrev "Edelson, Justin"
> <Justin.Edelson@...>:
>
>> 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:srs@...]
>> Sent: Wednesday, October 07, 2009 11:23 AM
>> To: users@...
>> 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
>> <Justin.Edelson@...
>>> 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:srs@...]
>>> Sent: Wednesday, October 07, 2009 3:26 AM
>>> To: users@...
>>> 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
>>> <Justin.Edelson@...
>>>> 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:heavy@...]
>>>> Sent: Tue 10/6/2009 7:31 PM
>>>> To: users@...
>>>> 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: users-unsubscribe@...
>>>> For additional commands, e-mail: users-help@...
>>>>
>>>>
>>>>
>>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe@...
>>> For additional commands, e-mail: users-help@...
>>>
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@...
>> For additional commands, e-mail: users-help@...
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@...
> For additional commands, e-mail: users-help@...
>

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@...
For additional commands, e-mail: users-help@...

[justinedelson]

I don't think I've fully groked Karaf, but it seems to do a lot of
stuff, not all of which is strictly necessary. So yes, I'd rather see
something simple, yet useable and useful, provided as a standalone
module and let Karaf, Sling, and anyone else build upon this. Again, my
desire is not to say that this is the one true way to embed an OSGi
framework into a J2EE container, but I do think there should be a
sensible default path to do so. Still, it'd be interested to hear
feedback from the people more intimately involved with Karaf.

Justin

-----Original Message-----
From: Richard S. Hall [mailto:heavy@...]
Sent: Wednesday, October 07, 2009 11:47 AM
To: users@...
Subject: Re: Default web app integration behavior

I guess the question to ask, is if there is value for being able to do
this without Karaf? If not, then Karaf is the way to go, but if the same
webapp launcher could be used in Karaf and independently, then perhaps
that'd even be more flexible.

Granted, I don't really know what I am talking about when it comes to
this stuff. ;-)

-> richard

On 10/7/09 16:44, Edelson, Justin 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:srs@...]
> Sent: Wednesday, October 07, 2009 3:26 AM
> To: users@...
> 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
> <Justin.Edelson@...
>    
>> 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:heavy@...]
>> Sent: Tue 10/6/2009 7:31 PM
>> To: users@...
>> 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: users-unsubscribe@...
>> For additional commands, e-mail: users-help@...
>>
>>
>>
>>
>>      
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@...
> For additional commands, e-mail: users-help@...
>
>    

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@...
For additional commands, e-mail: users-help@...


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@...
For additional commands, e-mail: users-help@...

[Felix Meschberger-2]

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: users-unsubscribe@...
For additional commands, e-mail: users-help@...

[justinedelson]

Felix Meschberger wrote:
> 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.

Not because I don't like Sling :) Mostly because what I did was to take things away from Sling's launcher (I think I said somewhere in this thread that I'd like Felix to do a subset of what Sling does). Specifically, as you noted, Sling shares launcher code between the standalone and webapp versions and there's some added complexity as a result. IIRC, there's also a fair bit of code in there which appears to allow for the launcher to be replaced at runtime and I haven't had the time to research why this was done (and didn't want to post a question to the dev list without doing the necessary research). Also, the initial project where this came up is distinct from our Sling projects, i.e. it doesn't use JCR and is more "service-orientated" than "resource-orientated."

Also, in Sling, Filter support is limited to wrapping Sling resources. For example (and correct me if I'm wrong), there's no way with Sling currently to put a filter in front of the web console (and part of this project is to put LDAP auth in front of the console). As a result, I implemented my own "Filter Bridge" based on the Equinox Servlet Bridge which I'm now in a position to throw away because Felix HttpService bridge supports Filters. I'd certainly be interested in seeing how/if Sling is going to move away from the Equinox bridge now that Felix provides a suitable replacement and whether or not one this will result in the ability to use Filters across all HttpService-based requests.

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

Good to know. What do you think about looking for a system property which controls whether or not system properties are added to the configuration map? It could (should?) default to false.

> This SNAPSHOT support might be an interesting add-on to the Sling
> launcher. Could you provide a patch ?

Sure. What about .war support? This is probably unnecessary for the vast majority of Sling users, but I don't see the harm (if you don't want to have WAR files in the bundles directory tree, don't put them there).

Justin

[gnodet]

That makes sense to have a standalone module I think.  Is it possible
to have this bridge independant from the used OSGi HTTP service ?

The example in Karaf should be enhanced to use this module when it's
done, as there is a JIRA issue to include the equinox bridge in this
example atm.

On Wed, Oct 7, 2009 at 18:24, Edelson, Justin
<Justin.Edelson@...> wrote:

> I don't think I've fully groked Karaf, but it seems to do a lot of
> stuff, not all of which is strictly necessary. So yes, I'd rather see
> something simple, yet useable and useful, provided as a standalone
> module and let Karaf, Sling, and anyone else build upon this. Again, my
> desire is not to say that this is the one true way to embed an OSGi
> framework into a J2EE container, but I do think there should be a
> sensible default path to do so. Still, it'd be interested to hear
> feedback from the people more intimately involved with Karaf.
>
> Justin
>
> -----Original Message-----
> From: Richard S. Hall [mailto:heavy@...]
> Sent: Wednesday, October 07, 2009 11:47 AM
> To: users@...
> Subject: Re: Default web app integration behavior
>
> I guess the question to ask, is if there is value for being able to do
> this without Karaf? If not, then Karaf is the way to go, but if the same
> webapp launcher could be used in Karaf and independently, then perhaps
> that'd even be more flexible.
>
> Granted, I don't really know what I am talking about when it comes to
> this stuff. ;-)
>
> -> richard
>
> On 10/7/09 16:44, Edelson, Justin 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:srs@...]
>> Sent: Wednesday, October 07, 2009 3:26 AM
>> To: users@...
>> 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
>> <Justin.Edelson@...
>>
>>> 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:heavy@...]
>>> Sent: Tue 10/6/2009 7:31 PM
>>> To: users@...
>>> 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: users-unsubscribe@...
>>> For additional commands, e-mail: users-help@...
>>>
>>>
>>>
>>>
>>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@...
>> For additional commands, e-mail: users-help@...
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@...
> For additional commands, e-mail: users-help@...
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@...
> For additional commands, e-mail: users-help@...
>
>

--
Cheers,
Guillaume Nodet
------------------------
Blog: http://gnodet.blogspot.com/
------------------------
Open Source SOA
http://fusesource.com

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@...
For additional commands, e-mail: users-help@...

[Felix Meschberger-2]

Edelson, Justin schrieb:
> Felix Meschberger wrote:
>> 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.
>
> Not because I don't like Sling :)

I am far from assuming that, of course ;-)


> Mostly because what I did was to take things away from Sling's launcher (I think I said somewhere in this thread that I'd like Felix to do a subset of what Sling does). Specifically, as you noted, Sling shares launcher code between the standalone and webapp versions and there's some added complexity as a result. IIRC, there's also a fair bit of code in there which appears to allow for the launcher to be replaced at runtime and I haven't had the time to research why this was done (and didn't want to post a question to the dev list without doing the necessary research). Also, the initial project where this came up is distinct from our Sling projects, i.e. it doesn't use JCR and is more "service-orientated" than "resource-orientated."

Please keep in mind, that the Sling launcher has nothing really to do
with Sling, though currently in the sling.properties file there are a
few Sling specific properties ...

The point about "launcher to be replaced at runtime" is not exactly
correct. The functionality is to allow to update the framework  at
runtime by updating the system bundle (as it is stipulated by the core
spec). This is something which must be done outside of the framework and
proves very useful.

>
> Also, in Sling, Filter support is limited to wrapping Sling resources. For example (and correct me if I'm wrong), there's no way with Sling currently to put a filter in front of the web console (and part of this project is to put LDAP auth in front of the console). As a result, I implemented my own "Filter Bridge" based on the Equinox Servlet Bridge which I'm now in a position to throw away because Felix HttpService bridge supports Filters. I'd certainly be interested in seeing how/if Sling is going to move away from the Equinox bridge now that Felix provides a suitable replacement and whether or not one this will result in the ability to use Filters across all HttpService-based requests.

Yes, that's true, the Sling launcher does not currently support the full
scope of what is possible in a general web application.

With the advent of Sten's new HTTP Service implementation, it would
finally be possible to allow for servlet container level filters to be
supported in an environment agnostic way.

This is also something on a virtual todo list of mine with respect to
the Sling launcher.

>
>>> 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.
>
> Good to know. What do you think about looking for a system property which controls whether or not system properties are added to the configuration map? It could (should?) default to false.

There is such a property. It is named "sling.ignoreSystemProperties" and
defaults to true in the Servlet container case and to false in the
standalone application case.

>
>> This SNAPSHOT support might be an interesting add-on to the Sling
>> launcher. Could you provide a patch ?
>
> Sure. What about .war support? This is probably unnecessary for the vast majority of Sling users, but I don't see the harm (if you don't want to have WAR files in the bundles directory tree, don't put them there).

In fact we at Day might also have such a requirement. With Sten's
implementation this might finally come true (right we could have done
this with PAX already ... but again, if we can do it in a container
agnostic way, it is much better.

So nothing, we would not be eager to add in Sling's implementation.

Regards
Felix

>
> Justin
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@...
For additional commands, e-mail: users-help@...

[justinedelson]

It sounds like the thing to do is for me to take a look at what's involved in using Sling without Sling (i.e. just the launcher). It seems like this might be just a matter of providing an example webapp or Wiki pages. Separately, I can look at creating some patches against Sling that do the following:
* Switch from Equinox to Felix's HttpService bridge impl.
* Add SNAPSHOT version support (i.e. always upgrade SNAPSHOTs)
* Add .war file support
 
Are you confident that the whiteboards in Felix HttpService and those in Sling don't collide? I'm pretty sure of this, but I think it warrants some validation.
 
Finally, I do think it's a worthwhile discussion to see if the Sling launcher should be better housed in the Felix or Karaf projects, merely because, as you point out, it "has nothing really to do with Sling."
 
Justin

________________________________

From: Felix Meschberger [mailto:fmeschbe@...]
Sent: Fri 10/9/2009 6:51 AM
To: users@...
Subject: Re: Default web app integration behavior





Edelson, Justin schrieb:
> Felix Meschberger wrote:
>> 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.
>
> Not because I don't like Sling :)

I am far from assuming that, of course ;-)


> Mostly because what I did was to take things away from Sling's launcher (I think I said somewhere in this thread that I'd like Felix to do a subset of what Sling does). Specifically, as you noted, Sling shares launcher code between the standalone and webapp versions and there's some added complexity as a result. IIRC, there's also a fair bit of code in there which appears to allow for the launcher to be replaced at runtime and I haven't had the time to research why this was done (and didn't want to post a question to the dev list without doing the necessary research). Also, the initial project where this came up is distinct from our Sling projects, i.e. it doesn't use JCR and is more "service-orientated" than "resource-orientated."

Please keep in mind, that the Sling launcher has nothing really to do
with Sling, though currently in the sling.properties file there are a
few Sling specific properties ...

The point about "launcher to be replaced at runtime" is not exactly
correct. The functionality is to allow to update the framework  at
runtime by updating the system bundle (as it is stipulated by the core
spec). This is something which must be done outside of the framework and
proves very useful.

>
> Also, in Sling, Filter support is limited to wrapping Sling resources. For example (and correct me if I'm wrong), there's no way with Sling currently to put a filter in front of the web console (and part of this project is to put LDAP auth in front of the console). As a result, I implemented my own "Filter Bridge" based on the Equinox Servlet Bridge which I'm now in a position to throw away because Felix HttpService bridge supports Filters. I'd certainly be interested in seeing how/if Sling is going to move away from the Equinox bridge now that Felix provides a suitable replacement and whether or not one this will result in the ability to use Filters across all HttpService-based requests.

Yes, that's true, the Sling launcher does not currently support the full
scope of what is possible in a general web application.

With the advent of Sten's new HTTP Service implementation, it would
finally be possible to allow for servlet container level filters to be
supported in an environment agnostic way.

This is also something on a virtual todo list of mine with respect to
the Sling launcher.

>
>>> 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.
>
> Good to know. What do you think about looking for a system property which controls whether or not system properties are added to the configuration map? It could (should?) default to false.

There is such a property. It is named "sling.ignoreSystemProperties" and
defaults to true in the Servlet container case and to false in the
standalone application case.

>
>> This SNAPSHOT support might be an interesting add-on to the Sling
>> launcher. Could you provide a patch ?
>
> Sure. What about .war support? This is probably unnecessary for the vast majority of Sling users, but I don't see the harm (if you don't want to have WAR files in the bundles directory tree, don't put them there).

In fact we at Day might also have such a requirement. With Sten's
implementation this might finally come true (right we could have done
this with PAX already ... but again, if we can do it in a container
agnostic way, it is much better.

So nothing, we would not be eager to add in Sling's implementation.

Regards
Felix

>
> Justin
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@...
For additional commands, e-mail: users-help@...

[Felix Meschberger-2]

Hi,

Edelson, Justin schrieb:
> It sounds like the thing to do is for me to take a look at what's involved in using Sling without Sling (i.e. just the launcher). It seems like this might be just a matter of providing an example webapp or Wiki pages. Separately, I can look at creating some patches against Sling that do the following:

Just take the Sling launchpad/base maven module and build this. This
gives your a primary artifact which is the framework plus common
launcher stuff. The app.jar is the standalone application (without the
framework and the webapp.war is the web application (without the framework).

Look at the launchpad/app and launchpad/webapp modules: these take the
launchpad/base stuff and include the launchpad/bundles artifact. Just
rip off the launchpad/bundles reference and you get a plain launcher
without any bundles installed.

> * Switch from Equinox to Felix's HttpService bridge impl.

That would be very welcome  !

> * Add SNAPSHOT version support (i.e. always upgrade SNAPSHOTs)

Same here

> * Add .war file support

... and same here.

>  
> Are you confident that the whiteboards in Felix HttpService and those in Sling don't collide? I'm pretty sure of this, but I think it warrants some validation.

I cannot tell about the Sten's HttpService, but I am pretty sure they
because in Sling the Servlet whiteboard support requires at least one
Sling specific property to be set to pick up the servlet. Otherwise it
is just ignored.

For filters we have a problem because Sling just picks up all filters,
we will have to fix this in Sling.

>  
> Finally, I do think it's a worthwhile discussion to see if the Sling launcher should be better housed in the Felix or Karaf projects, merely because, as you point out, it "has nothing really to do with Sling."

Yes.

Regards
Felix

>  
> Justin
>
> ________________________________
>
> From: Felix Meschberger [mailto:fmeschbe@...]
> Sent: Fri 10/9/2009 6:51 AM
> To: users@...
> Subject: Re: Default web app integration behavior
>
>
>
>
>
> Edelson, Justin schrieb:
>> Felix Meschberger wrote:
>>> 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.
>> Not because I don't like Sling :)
>
> I am far from assuming that, of course ;-)
>
>
>> Mostly because what I did was to take things away from Sling's launcher (I think I said somewhere in this thread that I'd like Felix to do a subset of what Sling does). Specifically, as you noted, Sling shares launcher code between the standalone and webapp versions and there's some added complexity as a result. IIRC, there's also a fair bit of code in there which appears to allow for the launcher to be replaced at runtime and I haven't had the time to research why this was done (and didn't want to post a question to the dev list without doing the necessary research). Also, the initial project where this came up is distinct from our Sling projects, i.e. it doesn't use JCR and is more "service-orientated" than "resource-orientated."
>
> Please keep in mind, that the Sling launcher has nothing really to do
> with Sling, though currently in the sling.properties file there are a
> few Sling specific properties ...
>
> The point about "launcher to be replaced at runtime" is not exactly
> correct. The functionality is to allow to update the framework  at
> runtime by updating the system bundle (as it is stipulated by the core
> spec). This is something which must be done outside of the framework and
> proves very useful.
>
>> Also, in Sling, Filter support is limited to wrapping Sling resources. For example (and correct me if I'm wrong), there's no way with Sling currently to put a filter in front of the web console (and part of this project is to put LDAP auth in front of the console). As a result, I implemented my own "Filter Bridge" based on the Equinox Servlet Bridge which I'm now in a position to throw away because Felix HttpService bridge supports Filters. I'd certainly be interested in seeing how/if Sling is going to move away from the Equinox bridge now that Felix provides a suitable replacement and whether or not one this will result in the ability to use Filters across all HttpService-based requests.
>
> Yes, that's true, the Sling launcher does not currently support the full
> scope of what is possible in a general web application.
>
> With the advent of Sten's new HTTP Service implementation, it would
> finally be possible to allow for servlet container level filters to be
> supported in an environment agnostic way.
>
> This is also something on a virtual todo list of mine with respect to
> the Sling launcher.
>
>>>> 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.
>> Good to know. What do you think about looking for a system property which controls whether or not system properties are added to the configuration map? It could (should?) default to false.
>
> There is such a property. It is named "sling.ignoreSystemProperties" and
> defaults to true in the Servlet container case and to false in the
> standalone application case.
>
>>> This SNAPSHOT support might be an interesting add-on to the Sling
>>> launcher. Could you provide a patch ?
>> Sure. What about .war support? This is probably unnecessary for the vast majority of Sling users, but I don't see the harm (if you don't want to have WAR files in the bundles directory tree, don't put them there).
>
> In fact we at Day might also have such a requirement. With Sten's
> implementation this might finally come true (right we could have done
> this with PAX already ... but again, if we can do it in a container
> agnostic way, it is much better.
>
> So nothing, we would not be eager to add in Sling's implementation.
>
> Regards
> Felix
>
>> Justin
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@...
> For additional commands, e-mail: users-help@...
>
>
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@...
For additional commands, e-mail: users-help@...

[justinedelson]

Yes and no. The launcher can be independent of the HttpService bridge implementation if the bridge implementation allows it. With Felix, all that is required of the launcher is to store the bundle context in a servlet context attribute. However, with Equinox, this is not the case - you need to invoke a BundleActivator. See http://svn.apache.org/repos/asf/sling/trunk/launchpad/base/src/main/java/org/apache/sling/launchpad/base/webapp/SlingBridge.java for an example.
 
In a generic launcher module, I think the way to enable this would be to allow for the list of system bundle activators to be expandable, either by subclassing the servlet context listener or by adding some init params.
 
Justin
 

________________________________

From: Guillaume Nodet [mailto:gnodet@...]
Sent: Fri 10/9/2009 3:47 AM
To: users@...
Subject: Re: Default web app integration behavior



That makes sense to have a standalone module I think.  Is it possible
to have this bridge independant from the used OSGi HTTP service ?

The example in Karaf should be enhanced to use this module when it's
done, as there is a JIRA issue to include the equinox bridge in this
example atm.

On Wed, Oct 7, 2009 at 18:24, Edelson, Justin
<Justin.Edelson@...> wrote:

> I don't think I've fully groked Karaf, but it seems to do a lot of
> stuff, not all of which is strictly necessary. So yes, I'd rather see
> something simple, yet useable and useful, provided as a standalone
> module and let Karaf, Sling, and anyone else build upon this. Again, my
> desire is not to say that this is the one true way to embed an OSGi
> framework into a J2EE container, but I do think there should be a
> sensible default path to do so. Still, it'd be interested to hear
> feedback from the people more intimately involved with Karaf.
>
> Justin
>
> -----Original Message-----
> From: Richard S. Hall [mailto:heavy@...]
> Sent: Wednesday, October 07, 2009 11:47 AM
> To: users@...
> Subject: Re: Default web app integration behavior
>
> I guess the question to ask, is if there is value for being able to do
> this without Karaf? If not, then Karaf is the way to go, but if the same
> webapp launcher could be used in Karaf and independently, then perhaps
> that'd even be more flexible.
>
> Granted, I don't really know what I am talking about when it comes to
> this stuff. ;-)
>
> -> richard
>
> On 10/7/09 16:44, Edelson, Justin 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:srs@...]
>> Sent: Wednesday, October 07, 2009 3:26 AM
>> To: users@...
>> 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
>> <Justin.Edelson@...
>>
>>> 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:heavy@...]
>>> Sent: Tue 10/6/2009 7:31 PM
>>> To: users@...
>>> 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: users-unsubscribe@...
>>> For additional commands, e-mail: users-help@...
>>>
>>>
>>>
>>>
>>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@...
>> For additional commands, e-mail: users-help@...
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@...
> For additional commands, e-mail: users-help@...
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@...
> For additional commands, e-mail: users-help@...
>
>

--
Cheers,
Guillaume Nodet
------------------------
Blog: http://gnodet.blogspot.com/
------------------------
Open Source SOA
http://fusesource.com <http://fusesource.com/>

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@...
For additional commands, e-mail: users-help@...