You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@sling.apache.org by Juanjo Vázquez <jv...@apache.org> on 2008/11/17 16:44:10 UTC

Customizing the Sling embedded repository

Hi,

Last days I have been thinking about to extend the features of Sling
embedded repository. The main reason for this is configuring it with another
persistent manager and customizing with my own login module and access
manager.

Obviously, I could modify the deployed repository.xml (copied by
SlingServerRepository) but I would prefer not have to do it. I´m using the
web launchpad.

Until now, I have used my own repository instance registered with RMI and
linked in Sling thanks to "sling.repository.url" property [1]. This works
fine but I´m afraid that I´ll be reinventing the wheel because I´d be
comfortable with a customized embedded repository.

Any ideas?

BR,

Juanjo.

[1] https://issues.apache.org/jira/browse/SLING-254

Re: Customizing the Sling embedded repository

Posted by Felix Meschberger <fm...@gmail.com>.
Hi,

Juan José Vázquez Delgado schrieb:
> Hi,
> 
> Agreed. I think if we can present a good use case for the requirement
>> (which IMHO is a good requirement in itself) the Jackrabbit team would
>> be more sensitive to the issue.
>>
>> Until now, they have not been that much sensitive to this because they
>> are more concerned with support for the upcoming JCR 2.0 (JSR-283)
>> standard.
>>
> 
> Understand, the first is first.
> 
> 
>>> Alternatively, you may create your own jackrabbit-server bundle
>>>> including your special PersistenceManager (or whatever it is). But I
>>>> agree, this is not the best of all solutions.
>>>
>>> I know, but sure you hate duplicated code, aren´t you? ;)
>> I do, of course ;-)
>>
>> But you could create a bundle, which depends on Sling's
>> jcr/jackrabbit-server bundle but extends it. When building the final
>> bundle, the jcr/jackrabbit-server bundle stuff would just be included in
>> your own bundle, for example by means of the <Embed-Dependency> element
>> of the bundle plugin or by using svn:externals (though this would be
>> kind of a last ressort IMHO).
>>
> 
> Yep, I had already thought about this solution. It could be works.
> 
> Anyway, I´m still thinking about an eventual jackrabbit-server improvement.
> Are yoy agree?.

Absolutely, this would be the right way to go.

Regards
Felix

> 
> BR,
> 
> Juanjo.
> 


Re: Customizing the Sling embedded repository

Posted by Juan José Vázquez Delgado <ju...@gmail.com>.
Hi,

Agreed. I think if we can present a good use case for the requirement
> (which IMHO is a good requirement in itself) the Jackrabbit team would
> be more sensitive to the issue.
>
> Until now, they have not been that much sensitive to this because they
> are more concerned with support for the upcoming JCR 2.0 (JSR-283)
> standard.
>

Understand, the first is first.


> >
> > Alternatively, you may create your own jackrabbit-server bundle
> >> including your special PersistenceManager (or whatever it is). But I
> >> agree, this is not the best of all solutions.
> >
> >
> > I know, but sure you hate duplicated code, aren´t you? ;)
>
> I do, of course ;-)
>
> But you could create a bundle, which depends on Sling's
> jcr/jackrabbit-server bundle but extends it. When building the final
> bundle, the jcr/jackrabbit-server bundle stuff would just be included in
> your own bundle, for example by means of the <Embed-Dependency> element
> of the bundle plugin or by using svn:externals (though this would be
> kind of a last ressort IMHO).
>

Yep, I had already thought about this solution. It could be works.

Anyway, I´m still thinking about an eventual jackrabbit-server improvement.
Are yoy agree?.

BR,

Juanjo.

Re: Customizing the Sling embedded repository

Posted by Felix Meschberger <fm...@gmail.com>.
Hi Juanjo,

Juanjo Vázquez schrieb:
> Hi,
> 
> On the other hand, the jcr/jackrabbit-server bundle has a
>>  DynamicImport-Package: *
>>
>> header, which allows it to import just about everything which is
>> exported elsewhere, dynamically and on-demand.
>>
>> This means, you could create a bundle, which exports for example your
>> LoginModule and the jcr/jackrabbit-server bundle could pick it up.
>>
> 
> Yes it´s true. That´s the way.
> 
> It gets more complicated with providing a PersistenceManager, because
>> there is no proper API for that, the respective interfaces and abstract
>> classes are intermixed with implementation classes. Thus exporting the
>> required packages is simply not possible.
> 
> 
> Oops, bad news.
> 
> And finally: Jackrabbit setup is static. Jackrabbit is not prepared to
>> implementations going away (or being updated) at runtime. This makes
>> hooking in PersistenceManagers or LoginModules even more problematic.
>> Again, we might raise a case in Jackrabbit and try to convince them
>> about the issues.
> 
> 
> Do you think jackrabbit team could be sensitive to this issue?. IMHO, this
> is an important thing to Sling.

Agreed. I think if we can present a good use case for the requirement
(which IMHO is a good requirement in itself) the Jackrabbit team would
be more sensitive to the issue.

Until now, they have not been that much sensitive to this because they
are more concerned with support for the upcoming JCR 2.0 (JSR-283) standard.

The problem is, that, though it is perfectly feasible, it is probably
quite some work and in addition requires backwards-compatibility
consideration.

> 
> Alternatively, you may create your own jackrabbit-server bundle
>> including your special PersistenceManager (or whatever it is). But I
>> agree, this is not the best of all solutions.
> 
> 
> I know, but sure you hate duplicated code, aren´t you? ;)

I do, of course ;-)

But you could create a bundle, which depends on Sling's
jcr/jackrabbit-server bundle but extends it. When building the final
bundle, the jcr/jackrabbit-server bundle stuff would just be included in
your own bundle, for example by means of the <Embed-Dependency> element
of the bundle plugin or by using svn:externals (though this would be
kind of a last ressort IMHO).

Regards
Felix


Re: Customizing the Sling embedded repository

Posted by Juanjo Vázquez <jv...@apache.org>.
Hi,

On the other hand, the jcr/jackrabbit-server bundle has a
>
>  DynamicImport-Package: *
>
> header, which allows it to import just about everything which is
> exported elsewhere, dynamically and on-demand.
>
> This means, you could create a bundle, which exports for example your
> LoginModule and the jcr/jackrabbit-server bundle could pick it up.
>

Yes it´s true. That´s the way.

It gets more complicated with providing a PersistenceManager, because
> there is no proper API for that, the respective interfaces and abstract
> classes are intermixed with implementation classes. Thus exporting the
> required packages is simply not possible.


Oops, bad news.

And finally: Jackrabbit setup is static. Jackrabbit is not prepared to
> implementations going away (or being updated) at runtime. This makes
> hooking in PersistenceManagers or LoginModules even more problematic.
> Again, we might raise a case in Jackrabbit and try to convince them
> about the issues.


Do you think jackrabbit team could be sensitive to this issue?. IMHO, this
is an important thing to Sling.

Alternatively, you may create your own jackrabbit-server bundle
> including your special PersistenceManager (or whatever it is). But I
> agree, this is not the best of all solutions.


I know, but sure you hate duplicated code, aren´t you? ;)

BR,

Juanjo.

Re: Customizing the Sling embedded repository

Posted by Felix Meschberger <fm...@gmail.com>.
Hi Juanjo,

Juan José Vázquez Delgado schrieb:
> On the other hand, I think any bundle is exporting jcr packages, really?.
> This coulf be a problem if you want to have a login module and access
> manager in their own bundle. Is this true?

This is really a big problem: It is currently rather problematic to use
Jackrabbit in an OSGi environment .. and it took me quite a while to
understand, that the jcr/jackrabbit-server bundle must not export
anything :-(

On the other hand, the jcr/jackrabbit-server bundle has a

  DynamicImport-Package: *

header, which allows it to import just about everything which is
exported elsewhere, dynamically and on-demand.

This means, you could create a bundle, which exports for example your
LoginModule and the jcr/jackrabbit-server bundle could pick it up.

It gets more complicated with providing a PersistenceManager, because
there is no proper API for that, the respective interfaces and abstract
classes are intermixed with implementation classes. Thus exporting the
required packages is simply not possible.

Maybe we could make a case of this and raise the issue again in
Jackrabbit to finally get to a solution.

And finally: Jackrabbit setup is static. Jackrabbit is not prepared to
implementations going away (or being updated) at runtime. This makes
hooking in PersistenceManagers or LoginModules even more problematic.
Again, we might raise a case in Jackrabbit and try to convince them
about the issues.

Alternatively, you may create your own jackrabbit-server bundle
including your special PersistenceManager (or whatever it is). But I
agree, this is not the best of all solutions.

Regards
Felix


Re: Customizing the Sling embedded repository

Posted by Juan José Vázquez Delgado <ju...@gmail.com>.
Hi,

We could add a property to sling.properties (also overwritable through
> web app init-param) which setting the URL to a repository.xml file. Thus
> you could include the repository.xml file in your web app or place it
> somewhere else together with the repository home.


Good.


> We might want to change this code to respect the repository home and
> configuration locations set in the sling.properties (or system
> properties or web app init-param) and only fall back to the old defaults
> if the properties are not set.
>
> You are of course welcome to implement and commit such a patch.


Agreed. I´ll open a jira and implement this stuff.

On the other hand, I think any bundle is exporting jcr packages, really?.
This coulf be a problem if you want to have a login module and access
manager in their own bundle. Is this true?

BR,

Juanjo.

Re: Customizing the Sling embedded repository

Posted by Felix Meschberger <fm...@gmail.com>.
Hi Juanjo,

Juanjo Vázquez schrieb:
> Hi,
> 
> Last days I have been thinking about to extend the features of Sling
> embedded repository. The main reason for this is configuring it with another
> persistent manager and customizing with my own login module and access
> manager.

Good point. I have been thinking on this a while ago, but came to no
conclusion :-(

> 
> Obviously, I could modify the deployed repository.xml (copied by
> SlingServerRepository) but I would prefer not have to do it. I´m using the
> web launchpad.

Makes sense.

> 
> Until now, I have used my own repository instance registered with RMI and
> linked in Sling thanks to "sling.repository.url" property [1]. This works
> fine but I´m afraid that I´ll be reinventing the wheel because I´d be
> comfortable with a customized embedded repository.
> 
> Any ideas?

We could add a property to sling.properties (also overwritable through
web app init-param) which setting the URL to a repository.xml file. Thus
you could include the repository.xml file in your web app or place it
somewhere else together with the repository home.

Currently the jcr/jackrabbit-server bundle contains an Activator class,
which sets up the repository to be located inside sling.home and copying
the repository.xml from the bundle to the sling.home folder.

We might want to change this code to respect the repository home and
configuration locations set in the sling.properties (or system
properties or web app init-param) and only fall back to the old defaults
if the properties are not set.

You are of course welcome to implement and commit such a patch.

WDYT ?

Regards
Felix

> 
> BR,
> 
> Juanjo.
> 
> [1] https://issues.apache.org/jira/browse/SLING-254
> 


Re: Customizing the Sling embedded repository

Posted by Juan José Vázquez Delgado <ju...@gmail.com>.
Hi,

> Last days I have been thinking about to extend the features of Sling
> > embedded repository. The main reason for this is configuring it with
> another
> > persistent manager and customizing with my own login module and access
> > manager.
>
> Hi Juan;
>
> I'll probably have to do something similar one day. I'd highly
> appreciate if you would post your findings to this group, if you get
> some interesting results.


Of course Vidar. I will keep you informed about this.

BR,

Juanjo.

Re: Customizing the Sling embedded repository

Posted by Vidar Ramdal <vi...@idium.no>.
On Mon, Nov 17, 2008 at 4:44 PM, Juanjo Vázquez <jv...@apache.org> wrote:

> Last days I have been thinking about to extend the features of Sling
> embedded repository. The main reason for this is configuring it with another
> persistent manager and customizing with my own login module and access
> manager.

Hi Juan;

I'll probably have to do something similar one day. I'd highly
appreciate if you would post your findings to this group, if you get
some interesting results.

-- 
Vidar S. Ramdal <vi...@idium.no> - http://www.idium.no
Akersgata 16, N-0158 Oslo, Norway