OK. But quick question (and then maybe we'll move this discussion to the sling list)... do I need to specify the sling.home init param? I remember getting tripped up on this before because the web.xml said something like "this would override whatever you have in repository.xml" and, of course, there is no repository.xml in a non-JCR app (or shouldn't need to be).
________________________________ From: Felix Meschberger [mailto:[email protected]] Sent: Fri 10/9/2009 8:11 AM To: [email protected] Subject: Re: Default web app integration behavior Hi, Edelson, Justin schrieb: > It sounds like the thing to do is for me to take a look at what's involved in > using Sling without Sling (i.e. just the launcher). It seems like this might > be just a matter of providing an example webapp or Wiki pages. Separately, I > can look at creating some patches against Sling that do the following: Just take the Sling launchpad/base maven module and build this. This gives your a primary artifact which is the framework plus common launcher stuff. The app.jar is the standalone application (without the framework and the webapp.war is the web application (without the framework). Look at the launchpad/app and launchpad/webapp modules: these take the launchpad/base stuff and include the launchpad/bundles artifact. Just rip off the launchpad/bundles reference and you get a plain launcher without any bundles installed. > * Switch from Equinox to Felix's HttpService bridge impl. That would be very welcome ! > * Add SNAPSHOT version support (i.e. always upgrade SNAPSHOTs) Same here > * Add .war file support ... and same here. > > Are you confident that the whiteboards in Felix HttpService and those in > Sling don't collide? I'm pretty sure of this, but I think it warrants some > validation. I cannot tell about the Sten's HttpService, but I am pretty sure they because in Sling the Servlet whiteboard support requires at least one Sling specific property to be set to pick up the servlet. Otherwise it is just ignored. For filters we have a problem because Sling just picks up all filters, we will have to fix this in Sling. > > 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." Yes. Regards Felix > > 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]
