You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@sling.apache.org by Carsten Ziegeler <cz...@apache.org> on 2009/06/22 21:16:03 UTC
[RT] Script Resolution
Hi,
I'm currently working on improving the script resolution in terms of
performance.
While looking at how it works today, I've discovered two problematic points:
1) Currently the scripts are searched by using the session of the
current request. Now, I think using the user session to search the
script is wrong. The content, the user requests, is already retrieved
with the user session and its the content (or the acl's on the content)
who define if the user is allowed to access something.
The script should always be executable (and I'm speaking of execution
not reading, writing etc.) for any user. This also matches the current
handling for scripts which are not stored in the repository like the
servlets or scripts contained in bundle resources.
Therefore I suggest to change the script resolution to use the admin
session.
Btw, this would also make caching the script resolution easier as the
current approach requires the caching of the script resolution to be a
per user cache. With the changes from above the cache can be global.
2) Resource events
We need to implement https://issues.apache.org/jira/browse/SLING-944 and
some extension of this to properly update the cache if scripts are
changed, added removed. As scripts can be coming from any data source
(jcr, file system, bundle, database etc.) we need a generic mechanism here.
For now I think we could start with OSGi events for
- Resource added, removed, changed
- Resource Provider added, removed
WDYT?
Carsten
--
Carsten Ziegeler
cziegeler@apache.org
Re: [RT] Script Resolution
Posted by Felix Meschberger <fm...@gmail.com>.
Hi,
Carsten Ziegeler schrieb:
> Another minor issue are the helper methods of the JcrResourceUtil class
> (the getResourceSuperType, resourceTypeToPath methods). I think we can
> make them completly JCR free and move them to the ResourceUtil class in
> the API.
+1
But leave the methods in the JcrResourceUtil forwarding to the new
mehotds in the ResoureUtil class and deprecate them.
Regards
Felix
>
> Carsten
>
> Carsten Ziegeler wrote:
>> Hi,
>>
>> I'm currently working on improving the script resolution in terms of
>> performance.
>> While looking at how it works today, I've discovered two problematic points:
>>
>> 1) Currently the scripts are searched by using the session of the
>> current request. Now, I think using the user session to search the
>> script is wrong. The content, the user requests, is already retrieved
>> with the user session and its the content (or the acl's on the content)
>> who define if the user is allowed to access something.
>> The script should always be executable (and I'm speaking of execution
>> not reading, writing etc.) for any user. This also matches the current
>> handling for scripts which are not stored in the repository like the
>> servlets or scripts contained in bundle resources.
>>
>> Therefore I suggest to change the script resolution to use the admin
>> session.
>>
>> Btw, this would also make caching the script resolution easier as the
>> current approach requires the caching of the script resolution to be a
>> per user cache. With the changes from above the cache can be global.
>>
>> 2) Resource events
>>
>> We need to implement https://issues.apache.org/jira/browse/SLING-944 and
>> some extension of this to properly update the cache if scripts are
>> changed, added removed. As scripts can be coming from any data source
>> (jcr, file system, bundle, database etc.) we need a generic mechanism here.
>> For now I think we could start with OSGi events for
>> - Resource added, removed, changed
>> - Resource Provider added, removed
>>
>> WDYT?
>>
>> Carsten
>
>
Re: [RT] Script Resolution
Posted by Ian Boston <ie...@tfd.co.uk>.
On 23 Jun 2009, at 15:17, Felix Meschberger wrote:
> Correct, so I would then say: the actual user is to be configurable
> but
> default to admin. Would that be ok for you ?
Yes, that would work for me,
Thanks
Ian
Re: [RT] Script Resolution
Posted by Felix Meschberger <fm...@gmail.com>.
Hi Ian,
Ian Boston schrieb:
>
> On 23 Jun 2009, at 14:06, Felix Meschberger wrote:
>
>> Hi,
>>
>> Ian Boston schrieb:
>>>
>>> On 23 Jun 2009, at 12:28, Bertrand Delacretaz wrote:
>>>>> Although Sling might choose to ignore this, I/we (sakai) are going
>>>>> to need to do something since all our users have write access to the
>>>>> repo, and at least 10% of them are Computer Science first year
>>>>> students just itching to prove their prowess by hacking/defacing an
>>>>> institutional system :)
>>>>
>>>> Brings back memories ;-)
>>>>
>>>> If we're using a distinct session for script resolution, we might want
>>>> to make its credentials configurable, and setup that user to see
>>>> scripts only under /libs and /apps. Would that suit your needs?
>>>
>>> yes,
>>> certainly would,
>>> We already have a "securityloader" along the same lines as the
>>> "contentloader" so configuration of that would be easy for us.
>>
>> The first step will be to use an admin session to access the scripts. So
>> you may lock down read-access on these areas, where you deam read-access
>> is not suitable.
>
>
> Forgive me, this might sound dumb (and it wont the fist time).
Or maybe it was me ... and not the first time, either.
> If the admin session is used to *load* scripts for execute, then surely
> it can load scripts from anywhere ?
Yes.
> I agree users wont be able to write or read scripts in the special
> area... but my concern is not stopping them reading scripts that might
> run, or uploading scripts to somewhere where they can write, but to stop
> untrusted scripts from executing.
I see.
> I the absence of any other control, the admin session will allow execute
> of all scripts on the content system.
>
> Please tell me I have missed something, and I am being dumb :)
Correct, so I would then say: the actual user is to be configurable but
default to admin. Would that be ok for you ?
Regards
Felix
Re: [RT] Script Resolution
Posted by Ian Boston <ie...@tfd.co.uk>.
On 23 Jun 2009, at 14:06, Felix Meschberger wrote:
> Hi,
>
> Ian Boston schrieb:
>>
>> On 23 Jun 2009, at 12:28, Bertrand Delacretaz wrote:
>>>> Although Sling might choose to ignore this, I/we (sakai) are going
>>>> to need to do something since all our users have write access to
>>>> the
>>>> repo, and at least 10% of them are Computer Science first year
>>>> students just itching to prove their prowess by hacking/defacing an
>>>> institutional system :)
>>>
>>> Brings back memories ;-)
>>>
>>> If we're using a distinct session for script resolution, we might
>>> want
>>> to make its credentials configurable, and setup that user to see
>>> scripts only under /libs and /apps. Would that suit your needs?
>>
>> yes,
>> certainly would,
>> We already have a "securityloader" along the same lines as the
>> "contentloader" so configuration of that would be easy for us.
>
> The first step will be to use an admin session to access the
> scripts. So
> you may lock down read-access on these areas, where you deam read-
> access
> is not suitable.
Forgive me, this might sound dumb (and it wont the fist time).
If the admin session is used to *load* scripts for execute, then
surely it can load scripts from anywhere ?
I agree users wont be able to write or read scripts in the special
area... but my concern is not stopping them reading scripts that might
run, or uploading scripts to somewhere where they can write, but to
stop untrusted scripts from executing.
I the absence of any other control, the admin session will allow
execute of all scripts on the content system.
Please tell me I have missed something, and I am being dumb :)
Ian
>
> Of course, extending this to be able to provide configuration with
> credentials of a user to use to access the scripts is simple.
>
> Regards
> Felix
Re: [RT] Script Resolution
Posted by Felix Meschberger <fm...@gmail.com>.
Hi,
Ian Boston schrieb:
>
> On 23 Jun 2009, at 12:28, Bertrand Delacretaz wrote:
>>> Although Sling might choose to ignore this, I/we (sakai) are going
>>> to need to do something since all our users have write access to the
>>> repo, and at least 10% of them are Computer Science first year
>>> students just itching to prove their prowess by hacking/defacing an
>>> institutional system :)
>>
>> Brings back memories ;-)
>>
>> If we're using a distinct session for script resolution, we might want
>> to make its credentials configurable, and setup that user to see
>> scripts only under /libs and /apps. Would that suit your needs?
>
> yes,
> certainly would,
> We already have a "securityloader" along the same lines as the
> "contentloader" so configuration of that would be easy for us.
The first step will be to use an admin session to access the scripts. So
you may lock down read-access on these areas, where you deam read-access
is not suitable.
Of course, extending this to be able to provide configuration with
credentials of a user to use to access the scripts is simple.
Regards
Felix
Re: [RT] Script Resolution
Posted by Ian Boston <ie...@tfd.co.uk>.
On 23 Jun 2009, at 12:28, Bertrand Delacretaz wrote:
> Hi,
>
> On Tue, Jun 23, 2009 at 12:03 PM, Ian Boston<ie...@tfd.co.uk> wrote:
>> On 23 Jun 2009, at 09:42, Felix Meschberger wrote:
>>> ... What exact problem do you want to solve with the restriction
>>> on script
>>> access ? Do you have some kind of "x-bit" in mind ? The repository
>>> itself has no support for (and cannot support) this kind of
>>> permission
>>> itself....
>
> Doesn't JCR 2.0 support arbitrary permissions? The spec says
>
> "A privilege represents the ability to perform a particular set of
> operations on a node. Each privilege is identified by a JCR name.
> JCR defines a set of standard privileges within the Privilege
> interface. An implementation may add additional privileges, using an
> appropriate implementation specific namespace for their names"
>
> So IIUC we (or rather Jackrabbit) might be able to define a
> jackrabbit:execute privilege?
The issue might be space in the compiled bitmap, which is quite full.
And then there is the binding into the Jackrabbit implementation that
doing this would imply.
>
>> Although Sling might choose to ignore this, I/we (sakai) are going
>> to need to do something since all our users have write access to
>> the repo, and at least 10% of them are Computer Science first year
>> students just itching to prove their prowess by hacking/defacing an
>> institutional system :)
>
> Brings back memories ;-)
>
> If we're using a distinct session for script resolution, we might want
> to make its credentials configurable, and setup that user to see
> scripts only under /libs and /apps. Would that suit your needs?
yes,
certainly would,
We already have a "securityloader" along the same lines as the
"contentloader" so configuration of that would be easy for us.
Ian
>
> -Bertrand
Re: [RT] Script Resolution
Posted by Felix Meschberger <fm...@gmail.com>.
Hi,
Bertrand Delacretaz schrieb:
> Hi,
>
> On Tue, Jun 23, 2009 at 12:03 PM, Ian Boston<ie...@tfd.co.uk> wrote:
>> On 23 Jun 2009, at 09:42, Felix Meschberger wrote:
>>> ... What exact problem do you want to solve with the restriction on script
>>> access ? Do you have some kind of "x-bit" in mind ? The repository
>>> itself has no support for (and cannot support) this kind of permission
>>> itself....
>
> Doesn't JCR 2.0 support arbitrary permissions? The spec says
>
> "A privilege represents the ability to perform a particular set of
> operations on a node. Each privilege is identified by a JCR name.
> JCR defines a set of standard privileges within the Privilege
> interface. An implementation may add additional privileges, using an
> appropriate implementation specific namespace for their names"
>
> So IIUC we (or rather Jackrabbit) might be able to define a
> jackrabbit:execute privilege?
Yes, that's the line of thinking here.
Regards
Felix
Re: [RT] Script Resolution
Posted by Bertrand Delacretaz <bd...@apache.org>.
Hi,
On Tue, Jun 23, 2009 at 12:03 PM, Ian Boston<ie...@tfd.co.uk> wrote:
> On 23 Jun 2009, at 09:42, Felix Meschberger wrote:
>>... What exact problem do you want to solve with the restriction on script
>> access ? Do you have some kind of "x-bit" in mind ? The repository
>> itself has no support for (and cannot support) this kind of permission
>> itself....
Doesn't JCR 2.0 support arbitrary permissions? The spec says
"A privilege represents the ability to perform a particular set of
operations on a node. Each privilege is identified by a JCR name.
JCR defines a set of standard privileges within the Privilege
interface. An implementation may add additional privileges, using an
appropriate implementation specific namespace for their names"
So IIUC we (or rather Jackrabbit) might be able to define a
jackrabbit:execute privilege?
> Although Sling might choose to ignore this, I/we (sakai) are going to need to do something since all our users have write access to the repo, and at least 10% of them are Computer Science first year students just itching to prove their prowess by hacking/defacing an institutional system :)
Brings back memories ;-)
If we're using a distinct session for script resolution, we might want
to make its credentials configurable, and setup that user to see
scripts only under /libs and /apps. Would that suit your needs?
-Bertrand
Re: [RT] Script Resolution
Posted by Bertrand Delacretaz <bd...@apache.org>.
Hi,
On Tue, Jun 23, 2009 at 12:03 PM, Ian Boston<ie...@tfd.co.uk> wrote:
> On 23 Jun 2009, at 09:42, Felix Meschberger wrote:
>>... What exact problem do you want to solve with the restriction on script
>> access ? Do you have some kind of "x-bit" in mind ? The repository
>> itself has no support for (and cannot support) this kind of permission
>> itself....
Doesn't JCR 2.0 support arbitrary permissions? The spec says
"A privilege represents the ability to perform a particular set of
operations on a
node. Each privilege is identified by a JCR name.
JCR defines a set of standard privileges within the Privilege interface. An
implementation may add additional privileges, using an appropriate
implementation
Re: [RT] Script Resolution
Posted by Bertrand Delacretaz <bd...@apache.org>.
On Tue, Jun 23, 2009 at 1:23 PM, Bertrand Delacretaz
<bd...@apache.org> wrote:
>
> (hit send too early - ignore previous message)
Sorry about that - Gmail is *eating* parts of my messages today...back in a sec.
-Bertrand
Re: [RT] Script Resolution
Posted by Bertrand Delacretaz <bd...@apache.org>.
(hit send too early - ignore previous message)
Hi,
On Tue, Jun 23, 2009 at 12:03 PM, Ian Boston<ie...@tfd.co.uk> wrote:
> On 23 Jun 2009, at 09:42, Felix Meschberger wrote:
>>... What exact problem do you want to solve with the restriction on script
>> access ? Do you have some kind of "x-bit" in mind ? The repository
>> itself has no support for (and cannot support) this kind of permission
>> itself....
Doesn't JCR 2.0 support arbitrary permissions? The spec says
"A privilege represents the ability to perform a particular set of
operations on a node. Each privilege is identified by a JCR name.
JCR defines a set of standard privileges within the Privilege
interface. An implementation may add additional privileges, using an
appropriate implementation-
Re: [RT] Script Resolution
Posted by Ian Boston <ie...@tfd.co.uk>.
On 23 Jun 2009, at 09:42, Felix Meschberger wrote:
> Hi,
>
> Dominik Süß schrieb:
>> Wouldn't this take us the ability to restrict allowed actions by
>> taking
>> reading rights of the scriptlocation by ACLs?
>> How would you solve restriction on scriptaccess?
>
> What exact problem do you want to solve with the restriction on script
> access ? Do you have some kind of "x-bit" in mind ? The repository
> itself has no support for (and cannot support) this kind of permission
> itself.
>
> As Bertrand already said, lets ignore this for now and add it later
> (proabbly to the scripting infrastructure in the scripting/core
> bundle).
Although Sling might choose to ignore this, I/we (sakai) are going to
need to do something since all our users have write access to the
repo, and at least 10% of them are Computer Science first year
students just itching to prove their prowess by hacking/defacing an
institutional system :)
If I understand the issue correctly, if I have write access to the
repo, I can upload a JSP file and get access to all the classes in the
JVM, and using reflection (as in AccessControlUtils) I circumvent any
bundle boundaries.
There was talk at some point in using a special principal to read the
script files for execution, so that a standard JCR ACL could control
what could be loaded for execution. That would work for us... but we
wont be able to ignore this issue.
Happy to look into a patch if that would help.
Ian
>
> Regards
> Felix
>
>>
>> Best regards,
>> Dominik
>>
>> On Mon, Jun 22, 2009 at 9:20 PM, Carsten Ziegeler <cziegeler@apache.org
>> >wrote:
>>
>>> Another minor issue are the helper methods of the JcrResourceUtil
>>> class
>>> (the getResourceSuperType, resourceTypeToPath methods). I think we
>>> can
>>> make them completly JCR free and move them to the ResourceUtil
>>> class in
>>> the API.
>>>
>>> Carsten
>>>
>>> Carsten Ziegeler wrote:
>>>> Hi,
>>>>
>>>> I'm currently working on improving the script resolution in terms
>>>> of
>>>> performance.
>>>> While looking at how it works today, I've discovered two
>>>> problematic
>>> points:
>>>> 1) Currently the scripts are searched by using the session of the
>>>> current request. Now, I think using the user session to search the
>>>> script is wrong. The content, the user requests, is already
>>>> retrieved
>>>> with the user session and its the content (or the acl's on the
>>>> content)
>>>> who define if the user is allowed to access something.
>>>> The script should always be executable (and I'm speaking of
>>>> execution
>>>> not reading, writing etc.) for any user. This also matches the
>>>> current
>>>> handling for scripts which are not stored in the repository like
>>>> the
>>>> servlets or scripts contained in bundle resources.
>>>>
>>>> Therefore I suggest to change the script resolution to use the
>>>> admin
>>>> session.
>>>>
>>>> Btw, this would also make caching the script resolution easier as
>>>> the
>>>> current approach requires the caching of the script resolution to
>>>> be a
>>>> per user cache. With the changes from above the cache can be
>>>> global.
>>>>
>>>> 2) Resource events
>>>>
>>>> We need to implement https://issues.apache.org/jira/browse/SLING-944
>>>> and
>>>> some extension of this to properly update the cache if scripts are
>>>> changed, added removed. As scripts can be coming from any data
>>>> source
>>>> (jcr, file system, bundle, database etc.) we need a generic
>>>> mechanism
>>> here.
>>>> For now I think we could start with OSGi events for
>>>> - Resource added, removed, changed
>>>> - Resource Provider added, removed
>>>>
>>>> WDYT?
>>>>
>>>> Carsten
>>>
>>> --
>>> Carsten Ziegeler
>>> cziegeler@apache.org
>>>
>>
>
Re: [RT] Script Resolution
Posted by Felix Meschberger <fm...@gmail.com>.
Hi,
Dominik Süß schrieb:
> Wouldn't this take us the ability to restrict allowed actions by taking
> reading rights of the scriptlocation by ACLs?
> How would you solve restriction on scriptaccess?
What exact problem do you want to solve with the restriction on script
access ? Do you have some kind of "x-bit" in mind ? The repository
itself has no support for (and cannot support) this kind of permission
itself.
As Bertrand already said, lets ignore this for now and add it later
(proabbly to the scripting infrastructure in the scripting/core bundle).
Regards
Felix
>
> Best regards,
> Dominik
>
> On Mon, Jun 22, 2009 at 9:20 PM, Carsten Ziegeler <cz...@apache.org>wrote:
>
>> Another minor issue are the helper methods of the JcrResourceUtil class
>> (the getResourceSuperType, resourceTypeToPath methods). I think we can
>> make them completly JCR free and move them to the ResourceUtil class in
>> the API.
>>
>> Carsten
>>
>> Carsten Ziegeler wrote:
>>> Hi,
>>>
>>> I'm currently working on improving the script resolution in terms of
>>> performance.
>>> While looking at how it works today, I've discovered two problematic
>> points:
>>> 1) Currently the scripts are searched by using the session of the
>>> current request. Now, I think using the user session to search the
>>> script is wrong. The content, the user requests, is already retrieved
>>> with the user session and its the content (or the acl's on the content)
>>> who define if the user is allowed to access something.
>>> The script should always be executable (and I'm speaking of execution
>>> not reading, writing etc.) for any user. This also matches the current
>>> handling for scripts which are not stored in the repository like the
>>> servlets or scripts contained in bundle resources.
>>>
>>> Therefore I suggest to change the script resolution to use the admin
>>> session.
>>>
>>> Btw, this would also make caching the script resolution easier as the
>>> current approach requires the caching of the script resolution to be a
>>> per user cache. With the changes from above the cache can be global.
>>>
>>> 2) Resource events
>>>
>>> We need to implement https://issues.apache.org/jira/browse/SLING-944 and
>>> some extension of this to properly update the cache if scripts are
>>> changed, added removed. As scripts can be coming from any data source
>>> (jcr, file system, bundle, database etc.) we need a generic mechanism
>> here.
>>> For now I think we could start with OSGi events for
>>> - Resource added, removed, changed
>>> - Resource Provider added, removed
>>>
>>> WDYT?
>>>
>>> Carsten
>>
>> --
>> Carsten Ziegeler
>> cziegeler@apache.org
>>
>
Re: [RT] Script Resolution
Posted by Dominik Süß <do...@gmail.com>.
Wouldn't this take us the ability to restrict allowed actions by taking
reading rights of the scriptlocation by ACLs?
How would you solve restriction on scriptaccess?
Best regards,
Dominik
On Mon, Jun 22, 2009 at 9:20 PM, Carsten Ziegeler <cz...@apache.org>wrote:
> Another minor issue are the helper methods of the JcrResourceUtil class
> (the getResourceSuperType, resourceTypeToPath methods). I think we can
> make them completly JCR free and move them to the ResourceUtil class in
> the API.
>
> Carsten
>
> Carsten Ziegeler wrote:
> > Hi,
> >
> > I'm currently working on improving the script resolution in terms of
> > performance.
> > While looking at how it works today, I've discovered two problematic
> points:
> >
> > 1) Currently the scripts are searched by using the session of the
> > current request. Now, I think using the user session to search the
> > script is wrong. The content, the user requests, is already retrieved
> > with the user session and its the content (or the acl's on the content)
> > who define if the user is allowed to access something.
> > The script should always be executable (and I'm speaking of execution
> > not reading, writing etc.) for any user. This also matches the current
> > handling for scripts which are not stored in the repository like the
> > servlets or scripts contained in bundle resources.
> >
> > Therefore I suggest to change the script resolution to use the admin
> > session.
> >
> > Btw, this would also make caching the script resolution easier as the
> > current approach requires the caching of the script resolution to be a
> > per user cache. With the changes from above the cache can be global.
> >
> > 2) Resource events
> >
> > We need to implement https://issues.apache.org/jira/browse/SLING-944 and
> > some extension of this to properly update the cache if scripts are
> > changed, added removed. As scripts can be coming from any data source
> > (jcr, file system, bundle, database etc.) we need a generic mechanism
> here.
> > For now I think we could start with OSGi events for
> > - Resource added, removed, changed
> > - Resource Provider added, removed
> >
> > WDYT?
> >
> > Carsten
>
>
> --
> Carsten Ziegeler
> cziegeler@apache.org
>
Re: [RT] Script Resolution
Posted by Carsten Ziegeler <cz...@apache.org>.
Another minor issue are the helper methods of the JcrResourceUtil class
(the getResourceSuperType, resourceTypeToPath methods). I think we can
make them completly JCR free and move them to the ResourceUtil class in
the API.
Carsten
Carsten Ziegeler wrote:
> Hi,
>
> I'm currently working on improving the script resolution in terms of
> performance.
> While looking at how it works today, I've discovered two problematic points:
>
> 1) Currently the scripts are searched by using the session of the
> current request. Now, I think using the user session to search the
> script is wrong. The content, the user requests, is already retrieved
> with the user session and its the content (or the acl's on the content)
> who define if the user is allowed to access something.
> The script should always be executable (and I'm speaking of execution
> not reading, writing etc.) for any user. This also matches the current
> handling for scripts which are not stored in the repository like the
> servlets or scripts contained in bundle resources.
>
> Therefore I suggest to change the script resolution to use the admin
> session.
>
> Btw, this would also make caching the script resolution easier as the
> current approach requires the caching of the script resolution to be a
> per user cache. With the changes from above the cache can be global.
>
> 2) Resource events
>
> We need to implement https://issues.apache.org/jira/browse/SLING-944 and
> some extension of this to properly update the cache if scripts are
> changed, added removed. As scripts can be coming from any data source
> (jcr, file system, bundle, database etc.) we need a generic mechanism here.
> For now I think we could start with OSGi events for
> - Resource added, removed, changed
> - Resource Provider added, removed
>
> WDYT?
>
> Carsten
--
Carsten Ziegeler
cziegeler@apache.org
Re: [RT] Script Resolution
Posted by Bertrand Delacretaz <bd...@apache.org>.
Hi,
On Mon, Jun 22, 2009 at 9:16 PM, Carsten Ziegeler<cz...@apache.org> wrote:
> ...I suggest to change the script resolution to use the admin
> session....
Sounds good for now, though we might later want to use specific
credentials for that.
When working with JCR, I miss the unixish execute permission bit, user
owner and group owner attributes, and (maybe) setuid bit, we might
want to introduce such concepts later. But not right now, no time for
that ;-)
>... Btw, this would also make caching the script resolution easier as the
> current approach requires the caching of the script resolution to be a
> per user cache. With the changes from above the cache can be global...
Cool.
> ...2) Resource events
>
> We need to implement https://issues.apache.org/jira/browse/SLING-944 and
> some extension of this to properly update the cache if scripts are
> changed, added removed. As scripts can be coming from any data source
> (jcr, file system, bundle, database etc.) we need a generic mechanism here.
> For now I think we could start with OSGi events for
> - Resource added, removed, changed
> - Resource Provider added, removed...
Ok, as long as this doesn't lead to duplicating JCR functionality.
-Bertrand