Embedding Sling

[Felix Meschberger <fm...@adobe.com>]

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

Re: Embedding Sling

[Justin Edelson <ju...@justinedelson.com>]

+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 <fm...@adobe.com> 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

Re: Embedding Sling

[Ian Boston <ie...@tfd.co.uk>]

On 18 February 2012 05:55, Felix Meschberger <fm...@adobe.com> 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 ?


I assume by embedding you mean not using the Sling bootstrap to
configure the OSGi container ?

The effective fallback at the moment is ./sling which works quite well
as many deployers ensure that the current process starts in a place
where ./sling is the right thing.

user.home or user.dir are going to be frustrating since often a single
user runs many copies inn different processes and doesn't want them to
share the same space.

My experience with wrapping larger apps around Sling has been that
./sling works well.


Ian

>
> Regards
> Felix