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
