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