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 <[email protected]>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:[email protected]] >>>>>> Sent: Fri 10/9/2009 6:51 AM >>>>>> To: [email protected] >>>>>> 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: [email protected] >>>>>> For additional commands, e-mail: [email protected] >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>> --------------------------------------------------------------------- >>>>> To unsubscribe, e-mail: [email protected] >>>>> For additional commands, e-mail: [email protected] >>>>> >>>>> >>>>> >>>> --------------------------------------------------------------------- >>>> To unsubscribe, e-mail: [email protected] >>>> For additional commands, e-mail: [email protected] >>>> >>>> >>> --------------------------------------------------------------------- >>> To unsubscribe, e-mail: [email protected] >>> For additional commands, e-mail: [email protected] >>> >>> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: [email protected] >> For additional commands, e-mail: [email protected] >> >> > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
