+1 to using SlingSettingsService consistently.
If the problem really is just about not being able to use framework
properties to set sling.home, could we look for an OSGi service
registered using the Properties class and some special service
property, e.g.
ServiceReference[] propsServices =
bc.getServiceReferences(Properties.class.getName(),
"(sling=awesome)");
if (propsService != null) {
// configure sling.home from the first propsService
}
This enables an embedder to set the location simply by registering a
service BEFORE starting the Sling Settings bundle.
Justin
On Fri, Feb 17, 2012 at 1:55 PM, Felix Meschberger <[email protected]> wrote:
> Hi all,
>
> I am thinking about how Sling could be embedded in an existing framework.
> Presumably this is almost only a problem of getting the dependencies right.
>
> The "almost" comes from our famous "sling.home" framework property. This is
> really fundamental and without this, many things like locating the JCR
> repository folder etc. don't work.
>
> Now when embedding in an existing framework the chances to be able to
> influence framework properties in an easy way are low. Yet, we basically have
> a solution to this problem: The SlingSettings service which provides a nice
> API to get at this information.
>
> So I am thinking of two things to fix:
>
> * Have the SlingSettings service implement a good
> fallback if the sling.home framework property is
> not defined -- e.g. user.home, user.dir.
>
> * Change all current pieces directly using the
> sling.home framework property to only use the
> SlingSettings service.
>
> This way, we have a single point of attack to fix the sling.home setup.
>
> WDYT ?
>
> Regards
> Felix
