On 18 February 2012 05:55, 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 ?
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
