You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@felix.apache.org by "Edelson, Justin" <Ju...@mtvstaff.com> on 2009/10/07 00:27:16 UTC
Default web app integration behavior
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?
Re: Default web app integration behavior
Posted by Felix Meschberger <fm...@gmail.com>.
Hi Sten,
Sten Roger Sandvik schrieb:
> Hi.
>
> Been away for a week now so just wondering if there was any conclusion here?
> I would personally like a launcher framework for Felix that supports both
> standalone and servlet deployment. But, should Felix roll it's own launcher
> subproject or try to include the one from Sling?
I share your opinion here. Therefore I am currently running an informal
discussion on the Sling dev list on the opinions of the Sling community
to offer the Sling launcher to the Apache Felix project [1].
When I know more, I will post to this list again.
Regards
Felix
[1] http://markmail.org/thread/e3pqzoshqge2ezxb
>
> /srs
>
> On Sun, Oct 11, 2009 at 2:05 PM, Felix Meschberger <fm...@gmail.com>wrote:
>
>> Hi
>>
>> Richard S. Hall schrieb:
>>> On 10/10/09 22:46, Felix Meschberger wrote:
>>>> Hi,
>>>>
>>>> Richard S. Hall schrieb:
>>>>
>>>>> On 10/9/09 14:01, Edelson, Justin wrote:
>>>>>
>>>>>> 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."
>>>>>>
>>>>>>
>>>>> Well, if it makes sense, I think having another launcher subproject
>>>>> isn't a bad idea, especially since we tell people that we don't expect
>>>>> our default launcher to be sufficient for everyone, it is just a basic
>>>>> launcher.
>>>>>
>>>>> Does anyone know if the web app launcher is completely different than
>>>>> Main? Just wondering if there is some synergy...
>>>>>
>>>> I didn't look at our Main recently (actually, I somewhat lost track
>>>> since starting the Sling launcher way back in the framework 1.0.4
>> times).
>>>> But I think functionality wise they are probably close and finding
>>>> synergy would be an optimum to find IMHO. The main difference is that
>>>> the Sling launcher comes in two facets: for the Java standalone
>>>> application case (as Main does) and for the Servlet container case.
>>>>
>>> Well, maybe the Servlet container case could just build on the existing
>>> launcher...
>> Well, that's exactly how the Servlet container case evolved in the Sling
>> launcher: we had the standalone case (actually I started from the 1.0.4
>> Main) and then refactored into a common case with standalone and servlet
>> container embeddings. ;-)
>>
>> Regards
>> Felix
>>
>>> -> richard
>>>
>>>> Regards
>>>> Felix
>>>>
>>>>
>>>>> -> richard
>>>>>
>>>>>
>>>>>> Justin
>>>>>>
>>>>>> ________________________________
>>>>>>
>>>>>> From: Felix Meschberger [mailto:fmeschbe@gmail.com]
>>>>>> Sent: Fri 10/9/2009 6:51 AM
>>>>>> To: users@felix.apache.org
>>>>>> 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@felix.apache.org
>>>>>> For additional commands, e-mail: users-help@felix.apache.org
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>>>>> For additional commands, e-mail: users-help@felix.apache.org
>>>>>
>>>>>
>>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>>>> For additional commands, e-mail: users-help@felix.apache.org
>>>>
>>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>>> For additional commands, e-mail: users-help@felix.apache.org
>>>
>>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>> For additional commands, e-mail: users-help@felix.apache.org
>>
>>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
Re: Default web app integration behavior
Posted by Sten Roger Sandvik <sr...@x3m.com>.
Hi.
Been away for a week now so just wondering if there was any conclusion here?
I would personally like a launcher framework for Felix that supports both
standalone and servlet deployment. But, should Felix roll it's own launcher
subproject or try to include the one from Sling?
/srs
On Sun, Oct 11, 2009 at 2:05 PM, Felix Meschberger <fm...@gmail.com>wrote:
> Hi
>
> Richard S. Hall schrieb:
> > On 10/10/09 22:46, Felix Meschberger wrote:
> >> Hi,
> >>
> >> Richard S. Hall schrieb:
> >>
> >>> On 10/9/09 14:01, Edelson, Justin wrote:
> >>>
> >>>> 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."
> >>>>
> >>>>
> >>> Well, if it makes sense, I think having another launcher subproject
> >>> isn't a bad idea, especially since we tell people that we don't expect
> >>> our default launcher to be sufficient for everyone, it is just a basic
> >>> launcher.
> >>>
> >>> Does anyone know if the web app launcher is completely different than
> >>> Main? Just wondering if there is some synergy...
> >>>
> >> I didn't look at our Main recently (actually, I somewhat lost track
> >> since starting the Sling launcher way back in the framework 1.0.4
> times).
> >>
> >> But I think functionality wise they are probably close and finding
> >> synergy would be an optimum to find IMHO. The main difference is that
> >> the Sling launcher comes in two facets: for the Java standalone
> >> application case (as Main does) and for the Servlet container case.
> >>
> >
> > Well, maybe the Servlet container case could just build on the existing
> > launcher...
>
> Well, that's exactly how the Servlet container case evolved in the Sling
> launcher: we had the standalone case (actually I started from the 1.0.4
> Main) and then refactored into a common case with standalone and servlet
> container embeddings. ;-)
>
> Regards
> Felix
>
> >
> > -> richard
> >
> >> Regards
> >> Felix
> >>
> >>
> >>> -> richard
> >>>
> >>>
> >>>> Justin
> >>>>
> >>>> ________________________________
> >>>>
> >>>> From: Felix Meschberger [mailto:fmeschbe@gmail.com]
> >>>> Sent: Fri 10/9/2009 6:51 AM
> >>>> To: users@felix.apache.org
> >>>> 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@felix.apache.org
> >>>> For additional commands, e-mail: users-help@felix.apache.org
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>> ---------------------------------------------------------------------
> >>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
> >>> For additional commands, e-mail: users-help@felix.apache.org
> >>>
> >>>
> >>>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
> >> For additional commands, e-mail: users-help@felix.apache.org
> >>
> >>
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
> > For additional commands, e-mail: users-help@felix.apache.org
> >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
> For additional commands, e-mail: users-help@felix.apache.org
>
>
Re: Default web app integration behavior
Posted by Felix Meschberger <fm...@gmail.com>.
Hi
Richard S. Hall schrieb:
> On 10/10/09 22:46, Felix Meschberger wrote:
>> Hi,
>>
>> Richard S. Hall schrieb:
>>
>>> On 10/9/09 14:01, Edelson, Justin wrote:
>>>
>>>> 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."
>>>>
>>>>
>>> Well, if it makes sense, I think having another launcher subproject
>>> isn't a bad idea, especially since we tell people that we don't expect
>>> our default launcher to be sufficient for everyone, it is just a basic
>>> launcher.
>>>
>>> Does anyone know if the web app launcher is completely different than
>>> Main? Just wondering if there is some synergy...
>>>
>> I didn't look at our Main recently (actually, I somewhat lost track
>> since starting the Sling launcher way back in the framework 1.0.4 times).
>>
>> But I think functionality wise they are probably close and finding
>> synergy would be an optimum to find IMHO. The main difference is that
>> the Sling launcher comes in two facets: for the Java standalone
>> application case (as Main does) and for the Servlet container case.
>>
>
> Well, maybe the Servlet container case could just build on the existing
> launcher...
Well, that's exactly how the Servlet container case evolved in the Sling
launcher: we had the standalone case (actually I started from the 1.0.4
Main) and then refactored into a common case with standalone and servlet
container embeddings. ;-)
Regards
Felix
>
> -> richard
>
>> Regards
>> Felix
>>
>>
>>> -> richard
>>>
>>>
>>>> Justin
>>>>
>>>> ________________________________
>>>>
>>>> From: Felix Meschberger [mailto:fmeschbe@gmail.com]
>>>> Sent: Fri 10/9/2009 6:51 AM
>>>> To: users@felix.apache.org
>>>> 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@felix.apache.org
>>>> For additional commands, e-mail: users-help@felix.apache.org
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>>> For additional commands, e-mail: users-help@felix.apache.org
>>>
>>>
>>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>> For additional commands, e-mail: users-help@felix.apache.org
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
> For additional commands, e-mail: users-help@felix.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
Re: Default web app integration behavior
Posted by "Richard S. Hall" <he...@ungoverned.org>.
On 10/10/09 22:46, Felix Meschberger wrote:
> Hi,
>
> Richard S. Hall schrieb:
>
>> On 10/9/09 14:01, Edelson, Justin wrote:
>>
>>> 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."
>>>
>>>
>> Well, if it makes sense, I think having another launcher subproject
>> isn't a bad idea, especially since we tell people that we don't expect
>> our default launcher to be sufficient for everyone, it is just a basic
>> launcher.
>>
>> Does anyone know if the web app launcher is completely different than
>> Main? Just wondering if there is some synergy...
>>
> I didn't look at our Main recently (actually, I somewhat lost track
> since starting the Sling launcher way back in the framework 1.0.4 times).
>
> But I think functionality wise they are probably close and finding
> synergy would be an optimum to find IMHO. The main difference is that
> the Sling launcher comes in two facets: for the Java standalone
> application case (as Main does) and for the Servlet container case.
>
Well, maybe the Servlet container case could just build on the existing
launcher...
-> richard
> Regards
> Felix
>
>
>> -> richard
>>
>>
>>> Justin
>>>
>>> ________________________________
>>>
>>> From: Felix Meschberger [mailto:fmeschbe@gmail.com]
>>> Sent: Fri 10/9/2009 6:51 AM
>>> To: users@felix.apache.org
>>> 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@felix.apache.org
>>> For additional commands, e-mail: users-help@felix.apache.org
>>>
>>>
>>>
>>>
>>>
>>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>> For additional commands, e-mail: users-help@felix.apache.org
>>
>>
>>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
> For additional commands, e-mail: users-help@felix.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
Re: Default web app integration behavior
Posted by Felix Meschberger <fm...@gmail.com>.
Hi,
Richard S. Hall schrieb:
> On 10/9/09 14:01, Edelson, Justin wrote:
>> 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."
>>
>
> Well, if it makes sense, I think having another launcher subproject
> isn't a bad idea, especially since we tell people that we don't expect
> our default launcher to be sufficient for everyone, it is just a basic
> launcher.
>
> Does anyone know if the web app launcher is completely different than
> Main? Just wondering if there is some synergy...
I didn't look at our Main recently (actually, I somewhat lost track
since starting the Sling launcher way back in the framework 1.0.4 times).
But I think functionality wise they are probably close and finding
synergy would be an optimum to find IMHO. The main difference is that
the Sling launcher comes in two facets: for the Java standalone
application case (as Main does) and for the Servlet container case.
Regards
Felix
>
> -> richard
>
>>
>> Justin
>>
>> ________________________________
>>
>> From: Felix Meschberger [mailto:fmeschbe@gmail.com]
>> Sent: Fri 10/9/2009 6:51 AM
>> To: users@felix.apache.org
>> 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@felix.apache.org
>> For additional commands, e-mail: users-help@felix.apache.org
>>
>>
>>
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
> For additional commands, e-mail: users-help@felix.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
Re: Default web app integration behavior
Posted by "Richard S. Hall" <he...@ungoverned.org>.
On 10/9/09 14:01, Edelson, Justin wrote:
> 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."
>
Well, if it makes sense, I think having another launcher subproject
isn't a bad idea, especially since we tell people that we don't expect
our default launcher to be sufficient for everyone, it is just a basic
launcher.
Does anyone know if the web app launcher is completely different than
Main? Just wondering if there is some synergy...
-> richard
>
> Justin
>
> ________________________________
>
> From: Felix Meschberger [mailto:fmeschbe@gmail.com]
> Sent: Fri 10/9/2009 6:51 AM
> To: users@felix.apache.org
> 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@felix.apache.org
> For additional commands, e-mail: users-help@felix.apache.org
>
>
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
Re: Default web app integration behavior
Posted by Felix Meschberger <fm...@gmail.com>.
Hi,
Edelson, Justin schrieb:
> (and then maybe we'll move this discussion to the sling list)...
would maybe make sense ;-)
> do I need to specify the sling.home init param? I remember getting tripped up on this before because the web.xml said something like "this would override whatever you have in repository.xml" and, of course, there is no repository.xml in a non-JCR app (or shouldn't need to be).
sling.home is where the Sling launcher puts everything ... it is
basically the parent of the Felix cache directory property. It is not
really required since it defaults to the value of the current working
directory as reported by the "user.dir" system property.
There is no reference to the repository.xml anymore in the web.xml file
nowadays....
But true, Sling depends in a small number of parts on the sling.home
framework property, so for the compatibility case we would have to find
a solution.
Regards
Felix
>
> ________________________________
>
> From: Felix Meschberger [mailto:fmeschbe@gmail.com]
> Sent: Fri 10/9/2009 8:11 AM
> To: users@felix.apache.org
> Subject: Re: Default web app integration behavior
>
>
>
> 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@gmail.com]
>> Sent: Fri 10/9/2009 6:51 AM
>> To: users@felix.apache.org
>> 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@felix.apache.org
>> For additional commands, e-mail: users-help@felix.apache.org
>>
>>
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
> For additional commands, e-mail: users-help@felix.apache.org
>
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
RE: Default web app integration behavior
Posted by "Edelson, Justin" <Ju...@mtvstaff.com>.
OK. But quick question (and then maybe we'll move this discussion to the sling list)... do I need to specify the sling.home init param? I remember getting tripped up on this before because the web.xml said something like "this would override whatever you have in repository.xml" and, of course, there is no repository.xml in a non-JCR app (or shouldn't need to be).
________________________________
From: Felix Meschberger [mailto:fmeschbe@gmail.com]
Sent: Fri 10/9/2009 8:11 AM
To: users@felix.apache.org
Subject: Re: Default web app integration behavior
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@gmail.com]
> Sent: Fri 10/9/2009 6:51 AM
> To: users@felix.apache.org
> 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@felix.apache.org
> For additional commands, e-mail: users-help@felix.apache.org
>
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
Re: Default web app integration behavior
Posted by Felix Meschberger <fm...@gmail.com>.
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@gmail.com]
> Sent: Fri 10/9/2009 6:51 AM
> To: users@felix.apache.org
> 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@felix.apache.org
> For additional commands, e-mail: users-help@felix.apache.org
>
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
Re: Default web app integration behavior
Posted by Bertrand Delacretaz <bd...@apache.org>.
Hi,
On Fri, Oct 9, 2009 at 2:01 PM, Edelson, Justin
<Ju...@mtvstaff.com> wrote:
> ...I can look at creating some patches against Sling that do the following:...
> * Add SNAPSHOT version support (i.e. always upgrade SNAPSHOTs)...
Sling's OSGi installer module (similar to fileinstall, but using
bundles from a JCR repository [1]) does this, and note that there's a
small gotcha: always updating snapshots can slow down startup
significantly if you have many bundles, which is suboptimal for
testing.
That module solves the problem by storing the modification dates of
the snapshots, and not upgrading bundles if those dates don't change.
-Bertrand
[1] http://sling.apache.org/site/jcr-installer-jcrjcrinstall-and-osgiinstaller.html
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
RE: Default web app integration behavior
Posted by "Edelson, Justin" <Ju...@mtvstaff.com>.
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@gmail.com]
Sent: Fri 10/9/2009 6:51 AM
To: users@felix.apache.org
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@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
Re: Default web app integration behavior
Posted by Felix Meschberger <fm...@gmail.com>.
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@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
RE: Default web app integration behavior
Posted by "Edelson, Justin" <Ju...@mtvstaff.com>.
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
Re: Default web app integration behavior
Posted by Felix Meschberger <fm...@gmail.com>.
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@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
Re: Default web app integration behavior
Posted by "Richard S. Hall" <he...@ungoverned.org>.
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@ungoverned.org]
> Sent: Tue 10/6/2009 7:31 PM
> To: users@felix.apache.org
> 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@felix.apache.org
> For additional commands, e-mail: users-help@felix.apache.org
>
>
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
Re: Default web app integration behavior
Posted by "Richard S. Hall" <he...@ungoverned.org>.
On 10/7/09 17:57, Sten Roger Sandvik wrote:
>
>
> // srs
>
> Den 7. okt. 2009 kl. 17.46 skrev "Edelson, Justin"
> <Ju...@mtvstaff.com>:
>
>> 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@x3m.com]
>> Sent: Wednesday, October 07, 2009 11:23 AM
>> To: users@felix.apache.org
>> 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@mtvstaff.com
>>> 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@x3m.com]
>>> Sent: Wednesday, October 07, 2009 3:26 AM
>>> To: users@felix.apache.org
>>> 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@mtvstaff.com
>>>> 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@ungoverned.org]
>>>> Sent: Tue 10/6/2009 7:31 PM
>>>> To: users@felix.apache.org
>>>> 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@felix.apache.org
>>>> For additional commands, e-mail: users-help@felix.apache.org
>>>>
>>>>
>>>>
>>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>>> For additional commands, e-mail: users-help@felix.apache.org
>>>
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>> For additional commands, e-mail: users-help@felix.apache.org
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
> For additional commands, e-mail: users-help@felix.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
Re: Default web app integration behavior
Posted by Sten Roger Sandvik <sr...@x3m.com>.
// srs
Den 7. okt. 2009 kl. 17.46 skrev "Edelson, Justin" <Justin.Edelson@mtvstaff.com
>:
> 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@x3m.com]
> Sent: Wednesday, October 07, 2009 11:23 AM
> To: users@felix.apache.org
> 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@mtvstaff.com
>> 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@x3m.com]
>> Sent: Wednesday, October 07, 2009 3:26 AM
>> To: users@felix.apache.org
>> 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@mtvstaff.com
>>> 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@ungoverned.org]
>>> Sent: Tue 10/6/2009 7:31 PM
>>> To: users@felix.apache.org
>>> 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@felix.apache.org
>>> For additional commands, e-mail: users-help@felix.apache.org
>>>
>>>
>>>
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>> For additional commands, e-mail: users-help@felix.apache.org
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
> For additional commands, e-mail: users-help@felix.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
RE: Default web app integration behavior
Posted by "Edelson, Justin" <Ju...@mtvstaff.com>.
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@x3m.com]
Sent: Wednesday, October 07, 2009 11:23 AM
To: users@felix.apache.org
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@mtvstaff.com
> 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@x3m.com]
> Sent: Wednesday, October 07, 2009 3:26 AM
> To: users@felix.apache.org
> 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@mtvstaff.com
> > 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@ungoverned.org]
> > Sent: Tue 10/6/2009 7:31 PM
> > To: users@felix.apache.org
> > 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@felix.apache.org
> > For additional commands, e-mail: users-help@felix.apache.org
> >
> >
> >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
> For additional commands, e-mail: users-help@felix.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
Re: Default web app integration behavior
Posted by Sten Roger Sandvik <sr...@x3m.com>.
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@mtvstaff.com
> 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@x3m.com]
> Sent: Wednesday, October 07, 2009 3:26 AM
> To: users@felix.apache.org
> 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@mtvstaff.com
> > 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@ungoverned.org]
> > Sent: Tue 10/6/2009 7:31 PM
> > To: users@felix.apache.org
> > 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@felix.apache.org
> > For additional commands, e-mail: users-help@felix.apache.org
> >
> >
> >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
> For additional commands, e-mail: users-help@felix.apache.org
>
>
RE: Default web app integration behavior
Posted by "Edelson, Justin" <Ju...@mtvstaff.com>.
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@gmail.com]
Sent: Fri 10/9/2009 3:47 AM
To: users@felix.apache.org
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
<Ju...@mtvstaff.com> 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@ungoverned.org]
> Sent: Wednesday, October 07, 2009 11:47 AM
> To: users@felix.apache.org
> 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@x3m.com]
>> Sent: Wednesday, October 07, 2009 3:26 AM
>> To: users@felix.apache.org
>> 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@mtvstaff.com
>>
>>> 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@ungoverned.org]
>>> Sent: Tue 10/6/2009 7:31 PM
>>> To: users@felix.apache.org
>>> 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@felix.apache.org
>>> For additional commands, e-mail: users-help@felix.apache.org
>>>
>>>
>>>
>>>
>>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>> For additional commands, e-mail: users-help@felix.apache.org
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
> For additional commands, e-mail: users-help@felix.apache.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
> For additional commands, e-mail: users-help@felix.apache.org
>
>
--
Cheers,
Guillaume Nodet
------------------------
Blog: http://gnodet.blogspot.com/
------------------------
Open Source SOA
http://fusesource.com <http://fusesource.com/>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
Re: Default web app integration behavior
Posted by Guillaume Nodet <gn...@gmail.com>.
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
<Ju...@mtvstaff.com> 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@ungoverned.org]
> Sent: Wednesday, October 07, 2009 11:47 AM
> To: users@felix.apache.org
> 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@x3m.com]
>> Sent: Wednesday, October 07, 2009 3:26 AM
>> To: users@felix.apache.org
>> 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@mtvstaff.com
>>
>>> 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@ungoverned.org]
>>> Sent: Tue 10/6/2009 7:31 PM
>>> To: users@felix.apache.org
>>> 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@felix.apache.org
>>> For additional commands, e-mail: users-help@felix.apache.org
>>>
>>>
>>>
>>>
>>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>> For additional commands, e-mail: users-help@felix.apache.org
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
> For additional commands, e-mail: users-help@felix.apache.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
> For additional commands, e-mail: users-help@felix.apache.org
>
>
--
Cheers,
Guillaume Nodet
------------------------
Blog: http://gnodet.blogspot.com/
------------------------
Open Source SOA
http://fusesource.com
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
RE: Default web app integration behavior
Posted by "Edelson, Justin" <Ju...@mtvstaff.com>.
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@ungoverned.org]
Sent: Wednesday, October 07, 2009 11:47 AM
To: users@felix.apache.org
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@x3m.com]
> Sent: Wednesday, October 07, 2009 3:26 AM
> To: users@felix.apache.org
> 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@mtvstaff.com
>
>> 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@ungoverned.org]
>> Sent: Tue 10/6/2009 7:31 PM
>> To: users@felix.apache.org
>> 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@felix.apache.org
>> For additional commands, e-mail: users-help@felix.apache.org
>>
>>
>>
>>
>>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
> For additional commands, e-mail: users-help@felix.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
Re: Default web app integration behavior
Posted by "Richard S. Hall" <he...@ungoverned.org>.
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@x3m.com]
> Sent: Wednesday, October 07, 2009 3:26 AM
> To: users@felix.apache.org
> 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@mtvstaff.com
>
>> 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@ungoverned.org]
>> Sent: Tue 10/6/2009 7:31 PM
>> To: users@felix.apache.org
>> 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@felix.apache.org
>> For additional commands, e-mail: users-help@felix.apache.org
>>
>>
>>
>>
>>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
> For additional commands, e-mail: users-help@felix.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
RE: Default web app integration behavior
Posted by "Edelson, Justin" <Ju...@mtvstaff.com>.
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@x3m.com]
Sent: Wednesday, October 07, 2009 3:26 AM
To: users@felix.apache.org
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@mtvstaff.com
> 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@ungoverned.org]
> Sent: Tue 10/6/2009 7:31 PM
> To: users@felix.apache.org
> 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@felix.apache.org
> For additional commands, e-mail: users-help@felix.apache.org
>
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
Re: Default web app integration behavior
Posted by Sten Roger Sandvik <sr...@x3m.com>.
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@mtvstaff.com
> 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@ungoverned.org]
> Sent: Tue 10/6/2009 7:31 PM
> To: users@felix.apache.org
> 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@felix.apache.org
> For additional commands, e-mail: users-help@felix.apache.org
>
>
>
>
Re: Default web app integration behavior
Posted by "Rémon. Sinnema" <rs...@yahoo.com>.
----- Original Message ----
From: "Edelson, Justin" <Ju...@mtvstaff.com>
To: users@felix.apache.org
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@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
RE: Default web app integration behavior
Posted by "Edelson, Justin" <Ju...@mtvstaff.com>.
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@ungoverned.org]
Sent: Tue 10/6/2009 7:31 PM
To: users@felix.apache.org
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@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
Re: Default web app integration behavior
Posted by "Richard S. Hall" <he...@ungoverned.org>.
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@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org