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]
