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]
