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 <[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] > >
