You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@jackrabbit.apache.org by anton_slutsky <as...@applevac.com> on 2007/02/02 16:19:04 UTC
Re: NodeTypeRegistry.checkForReferencesInContent()
I think the issue here is what to do with the already existing nodes rather
then the new node creation (like you said, a NodeTypeNotFound can always be
thrown). But if there are nodes out there with the type we are trying to
delete, we need to make sure something is done to those orphan nodes.
Personally, I wouldnt reassign them to nt:base. I'd check for nodes of the
given type, and if any are found, I'd throw a RepositoryException of some
kind and have people deal with their data before they can drop a type. But
thats just a suggestion. You guys know this stuff better then I do :)
But either way, we'll have to traverse each and every workspace to find
those typed nodes. And here we'll be running into security issues if custom
security/access managers are provided. In theory, we should be able to
somehow get a SystemPrincipal session for each workspace and that should
work because SystemPrincipal should have access to everything, but having
recently implemented a custom security manger, I'm pretty sure people who
will be doing the same will forget to account for the SystemPrincipal. I
guess what we could do here is decouple the LoginModule the JAAS interface,
provide corresponding template methods for both the LoginModule and
AccessManager, create internal instances of
javax.security.auth.spi.LoginModule and AccessManager and delegate calls to
templates after making sure SystemPrincipal is allowed through (phhuphh!
that was a mouthfull. hope it makes sense :-) ). But here, what we'll be
doing is basically saying to all the users "nomatter what you do,
SystemPrincipal is getting through". What do you think?
Thanks,
Anton
Sandro Böhme wrote:
>
> Hello,
>
> I guess the deep lock is needed to avoid new creation of nodes after
> the search for nodes with the node type that has to be unregistered.
> If that's the case maybe there is a way to avoid the deep lock.
> If a user tries to add a node with a node type that is currently
> being unregistered a NodeTypeNotFoundException (or similar) could
> already be thrown. This way it's possible to search for all nodes with
> this type and change the type to nt:base while the amount of nodes
> with this type will not change anymore.
> To search for nodes by type the following query should work
> "//element(*, nt:nodeType)". Of course this needs to be done for
> every workspace.
> Do you think that could work?
>
> Best regards,
>
> Sandro
>
> anton_slutsky wrote:
>> Hm. Doesnt look like our implementation will work. It works for us
>> because
>> its our application specific, but I doubt it'll work for the project.
>> Looks
>> like there are a couple of issues here. 1. The deep locks solutions wont
>> work because it's not always possible to get all workspaces or all root
>> nodes given the custom security managers. 2. The single-user solution
>> would work, but once we figure out how to place the repository into a
>> single-user mode, we run into the same issue as in #1, i.e., how do we
>> inspect nodes if we are not guaranteed to be able to get to them?
>>
>> Obviously, there is a bunch of possible solutions here. Figured I'd run
>> it
>> by you, see what you all think.
>>
>> 1. Add a concept of a system superuser. Will work, but kind of ugly and
>> adds complexity to authentication
>> 2. Develop some sort of a "metadata" storage. Some sort of a persistent
>> structure that will keep track of references for each given type.
>> Probably
>> the best thing in the long run, but requires things like hidden,system
>> stores. Kind of complicated.
>> 3. Add a reference counter on NodeTypeImpl itself. Probably the simplest
>> solution. Modifications will need to be made to the logic of persisting
>> new
>> and deleting items (as it would have to be in #2), but this way provides
>> for
>> the cheapest and quickest way to see if there are live nodes of a certain
>> type
>>
>>
>> Jukka Zitting wrote:
>>
>>>Hi,
>>>
>>>On 12/26/06, anton_slutsky <as...@applevac.com> wrote:
>>>
>>>>I'm wondering if anyone's actively working on implementing the
>>>>checkForReferencesInContent() method (quoted below). Because if not,
>>>>we'd
>>>>like to contribute source. unregisterNodeTypes() doesnt work without
it.
>>>>Makes it a bit of a pain to write unit tests as well as some application
>>>>functionality. Please let me know if anyone's doing this already so we
>>>>dont
>>>>duplicate effort.
>>>
>>>There's a long-standing feature request JCR-322 about this, but
>>>although it's popped up in discussion every now and then, there hasn't
>>>yet been much real effort to resolve it. Contributions would be very
>>>welcome!
>>>
>>>Note that implementing the method is somewhat hard, as you'd
>>>essentially need to get a global write lock on the entire repository
>>>and traverse all the content to find the node type references. This
>>>operation might also interfere with any pending transient or
>>>transactional changes.
>>>
>>>BR,
>>>
>>>Jukka Zitting
>>>
>>>
>>
>>
>
>
>
>
--
View this message in context: http://www.nabble.com/NodeTypeRegistry.checkForReferencesInContent%28%29-tf2882955.html#a8768745
Sent from the Jackrabbit - Users mailing list archive at Nabble.com.
Re: NodeTypeRegistry.checkForReferencesInContent()
Posted by anton_slutsky <as...@applevac.com>.
Alrighty. Reworked the patch slightly and attached it with a whole lot of
comments to JCR-322. Tried to move the thread to the dev forum, but it
barked at me and told me that I ask the impossible. Oh well ....
Jukka Zitting wrote:
>
> Hi,
>
> On 2/7/07, anton_slutsky <as...@applevac.com> wrote:
>> I agree, examining each node manually would be safer, but, like you said,
>> it
>> probably wont scale performancewise.
>
> Perhaps we could extend the persistence manager interface to support
> something like this...
>
>> Concurrency is an issue. I was thinking on setting a semaphore or a
>> mutex
>> flag on the RepositoryImpl instance, but I was sure if it's possible to
>> have
>> two RepositoryImpl instances working on the same physical repository.
>> From
>> what I've read so far, it doesnt appear that such a behavior is
>> supported.
>> If this can be confirmed to be a fact, the mutex solution should really
>> do
>> the trick.
>
> Confirmed, your approach sounds good.
>
>> Please pardon the ignorance, but what is an improvement request, and
>> where
>> can I file one? :-)
>
> The Jackrabbit issue tracker is at
> http://issues.apache.org/jira/browse/JCR. You can file a new issue
> (improvement requests are one type of issues) once you've registered
> an account. See also http://issues.apache.org/jira/browse/JCR-322 for
> the full feature request related to this. If you want you can also
> attach your patch there.
>
> BR,
>
> Jukka Zitting
>
>
--
View this message in context: http://www.nabble.com/NodeTypeRegistry.checkForReferencesInContent%28%29-tf2882955.html#a8850220
Sent from the Jackrabbit - Users mailing list archive at Nabble.com.
Re: NodeTypeRegistry.checkForReferencesInContent()
Posted by Jukka Zitting <ju...@gmail.com>.
Hi,
On 2/7/07, anton_slutsky <as...@applevac.com> wrote:
> I agree, examining each node manually would be safer, but, like you said, it
> probably wont scale performancewise.
Perhaps we could extend the persistence manager interface to support
something like this...
> Concurrency is an issue. I was thinking on setting a semaphore or a mutex
> flag on the RepositoryImpl instance, but I was sure if it's possible to have
> two RepositoryImpl instances working on the same physical repository. From
> what I've read so far, it doesnt appear that such a behavior is supported.
> If this can be confirmed to be a fact, the mutex solution should really do
> the trick.
Confirmed, your approach sounds good.
> Please pardon the ignorance, but what is an improvement request, and where
> can I file one? :-)
The Jackrabbit issue tracker is at
http://issues.apache.org/jira/browse/JCR. You can file a new issue
(improvement requests are one type of issues) once you've registered
an account. See also http://issues.apache.org/jira/browse/JCR-322 for
the full feature request related to this. If you want you can also
attach your patch there.
BR,
Jukka Zitting
Re: NodeTypeRegistry.checkForReferencesInContent()
Posted by anton_slutsky <as...@applevac.com>.
I agree, examining each node manually would be safer, but, like you said, it
probably wont scale performancewise.
Concurrency is an issue. I was thinking on setting a semaphore or a mutex
flag on the RepositoryImpl instance, but I was sure if it's possible to have
two RepositoryImpl instances working on the same physical repository. From
what I've read so far, it doesnt appear that such a behavior is supported.
If this can be confirmed to be a fact, the mutex solution should really do
the trick.
Please pardon the ignorance, but what is an improvement request, and where
can I file one? :-)
Thanks,
Anton
Jukka Zitting wrote:
>
> Hi,
>
> On 2/7/07, anton_slutsky <as...@applevac.com> wrote:
>> So what do you guys think of my implementation? I really hate to deploy
>> my
>> apps with customized code. I'd rather have it out there with an
>> out-of-the-box jackrabbit.
>
> Looks cool, though I have some concerns.
>
> My main concern is about using search to find the node type
> references. Normally this shouldn't be a problem, but since the search
> index is a separate copy of the persisted content there is a chance of
> coherence issues. More notably the search engine is pluggable and in
> some cases it has been disabled alltogether. Using the actual item
> state and persistence managers to look for references would IMHO be
> safer, though as of now there are no access paths outside the search
> index that would perform reasonably.
>
> Another concern is concurrency. How can we make sure that there are no
> concurrent modifications going on that might introduce new references
> to the node type in question?
>
> I think your patch is a good starting point but we still need work to
> sort out all the relevant details. You may want to attach your patch
> to JCR-322 or file it as a separate improvement request. I'd also
> suggest that you take this thread to the developer mailing list.
>
> BR,
>
> Jukka Zitting
>
>
--
View this message in context: http://www.nabble.com/NodeTypeRegistry.checkForReferencesInContent%28%29-tf2882955.html#a8847994
Sent from the Jackrabbit - Users mailing list archive at Nabble.com.
Re: NodeTypeRegistry.checkForReferencesInContent()
Posted by Jukka Zitting <ju...@gmail.com>.
Hi,
On 2/7/07, anton_slutsky <as...@applevac.com> wrote:
> So what do you guys think of my implementation? I really hate to deploy my
> apps with customized code. I'd rather have it out there with an
> out-of-the-box jackrabbit.
Looks cool, though I have some concerns.
My main concern is about using search to find the node type
references. Normally this shouldn't be a problem, but since the search
index is a separate copy of the persisted content there is a chance of
coherence issues. More notably the search engine is pluggable and in
some cases it has been disabled alltogether. Using the actual item
state and persistence managers to look for references would IMHO be
safer, though as of now there are no access paths outside the search
index that would perform reasonably.
Another concern is concurrency. How can we make sure that there are no
concurrent modifications going on that might introduce new references
to the node type in question?
I think your patch is a good starting point but we still need work to
sort out all the relevant details. You may want to attach your patch
to JCR-322 or file it as a separate improvement request. I'd also
suggest that you take this thread to the developer mailing list.
BR,
Jukka Zitting
Re: NodeTypeRegistry.checkForReferencesInContent()
Posted by anton_slutsky <as...@applevac.com>.
So what do you guys think of my implementation? I really hate to deploy my
apps with customized code. I'd rather have it out there with an
out-of-the-box jackrabbit.
anton_slutsky wrote:
>
> yeah, I figured the security thing out. Took me long enough, but better
> late then never :-). If you dont mind, could you look at the attached
> patch file? This implementation just throws an exception if a conflict is
> found. Naturally, type reassignment can also work, but I'm thinking that
> it could open a door to a bunch of issues with things like child nodes of
> the conflict node, parent node type definitions, and reference properties
> on other node.
>
>
> http://www.nabble.com/file/6235/nodetyperegistry.patch
> nodetyperegistry.patch
>
>
> Tobias Bocanegra wrote:
>>
>> hi anton,
>> as the nodetype registry has access to the "lowlevel' item states, it
>> can bypass any access control when checking the content. instead of
>> reassigning nt:base which would render the content invalid, i would
>> use a nodetype: nt:conflict (extends nt:unstructured), which could
>> have a property jcr:formerPrimaryType and jcr:formerMixinTypes
>>
>> regads, toby
>>
>> On 2/4/07, anton_slutsky <as...@applevac.com> wrote:
>>>
>>> Looks like I spoke without thinking. SystemSession already implementes
>>> its
>>> own AccessManager!
>>>
>>>
>>> anton_slutsky wrote:
>>> >
>>> > I think the issue here is what to do with the already existing nodes
>>> > rather then the new node creation (like you said, a NodeTypeNotFound
>>> can
>>> > always be thrown). But if there are nodes out there with the type we
>>> are
>>> > trying to delete, we need to make sure something is done to those
>>> orphan
>>> > nodes. Personally, I wouldnt reassign them to nt:base. I'd check for
>>> > nodes of the given type, and if any are found, I'd throw a
>>> > RepositoryException of some kind and have people deal with their data
>>> > before they can drop a type. But thats just a suggestion. You guys
>>> know
>>> > this stuff better then I do :)
>>> >
>>> > But either way, we'll have to traverse each and every workspace to
>>> find
>>> > those typed nodes. And here we'll be running into security issues if
>>> > custom security/access managers are provided. In theory, we should be
>>> > able to somehow get a SystemPrincipal session for each workspace and
>>> that
>>> > should work because SystemPrincipal should have access to everything,
>>> but
>>> > having recently implemented a custom security manger, I'm pretty sure
>>> > people who will be doing the same will forget to account for the
>>> > SystemPrincipal. I guess what we could do here is decouple the
>>> > LoginModule the JAAS interface, provide corresponding template methods
>>> for
>>> > both the LoginModule and AccessManager, create internal instances of
>>> > javax.security.auth.spi.LoginModule and AccessManager and delegate
>>> calls
>>> > to templates after making sure SystemPrincipal is allowed through
>>> > (phhuphh! that was a mouthfull. hope it makes sense :-) ). But
>>> here,
>>> > what we'll be doing is basically saying to all the users "nomatter
>>> what
>>> > you do, SystemPrincipal is getting through". What do you think?
>>> >
>>> > Thanks,
>>> > Anton
>>> >
>>> >
>>> > Sandro Böhme wrote:
>>> >>
>>> >> Hello,
>>> >>
>>> >> I guess the deep lock is needed to avoid new creation of nodes after
>>> >> the search for nodes with the node type that has to be unregistered.
>>> >> If that's the case maybe there is a way to avoid the deep lock.
>>> >> If a user tries to add a node with a node type that is currently
>>> >> being unregistered a NodeTypeNotFoundException (or similar) could
>>> >> already be thrown. This way it's possible to search for all nodes
>>> with
>>> >> this type and change the type to nt:base while the amount of nodes
>>> >> with this type will not change anymore.
>>> >> To search for nodes by type the following query should work
>>> >> "//element(*, nt:nodeType)". Of course this needs to be done for
>>> >> every workspace.
>>> >> Do you think that could work?
>>> >>
>>> >> Best regards,
>>> >>
>>> >> Sandro
>>> >>
>>> >> anton_slutsky wrote:
>>> >>> Hm. Doesnt look like our implementation will work. It works for us
>>> >>> because
>>> >>> its our application specific, but I doubt it'll work for the
>>> project.
>>> >>> Looks
>>> >>> like there are a couple of issues here. 1. The deep locks solutions
>>> >>> wont
>>> >>> work because it's not always possible to get all workspaces or all
>>> root
>>> >>> nodes given the custom security managers. 2. The single-user
>>> solution
>>> >>> would work, but once we figure out how to place the repository into
>>> a
>>> >>> single-user mode, we run into the same issue as in #1, i.e., how do
>>> we
>>> >>> inspect nodes if we are not guaranteed to be able to get to them?
>>> >>>
>>> >>> Obviously, there is a bunch of possible solutions here. Figured I'd
>>> run
>>> >>> it
>>> >>> by you, see what you all think.
>>> >>>
>>> >>> 1. Add a concept of a system superuser. Will work, but kind of ugly
>>> and
>>> >>> adds complexity to authentication
>>> >>> 2. Develop some sort of a "metadata" storage. Some sort of a
>>> persistent
>>> >>> structure that will keep track of references for each given type.
>>> >>> Probably
>>> >>> the best thing in the long run, but requires things like
>>> hidden,system
>>> >>> stores. Kind of complicated.
>>> >>> 3. Add a reference counter on NodeTypeImpl itself. Probably the
>>> >>> simplest
>>> >>> solution. Modifications will need to be made to the logic of
>>> persisting
>>> >>> new
>>> >>> and deleting items (as it would have to be in #2), but this way
>>> provides
>>> >>> for
>>> >>> the cheapest and quickest way to see if there are live nodes of a
>>> >>> certain
>>> >>> type
>>> >>>
>>> >>>
>>> >>> Jukka Zitting wrote:
>>> >>>
>>> >>>>Hi,
>>> >>>>
>>> >>>>On 12/26/06, anton_slutsky <as...@applevac.com> wrote:
>>> >>>>
>>> >>>>>I'm wondering if anyone's actively working on implementing the
>>> >>>>>checkForReferencesInContent() method (quoted below). Because if
>>> not,
>>> >>>>>we'd
>>> >>>>>like to contribute source. unregisterNodeTypes() doesnt work
>>> without
>>> it.
>>> >>>>>Makes it a bit of a pain to write unit tests as well as some
>>> application
>>> >>>>>functionality. Please let me know if anyone's doing this already
>>> so we
>>> >>>>>dont
>>> >>>>>duplicate effort.
>>> >>>>
>>> >>>>There's a long-standing feature request JCR-322 about this, but
>>> >>>>although it's popped up in discussion every now and then, there
>>> hasn't
>>> >>>>yet been much real effort to resolve it. Contributions would be very
>>> >>>>welcome!
>>> >>>>
>>> >>>>Note that implementing the method is somewhat hard, as you'd
>>> >>>>essentially need to get a global write lock on the entire repository
>>> >>>>and traverse all the content to find the node type references. This
>>> >>>>operation might also interfere with any pending transient or
>>> >>>>transactional changes.
>>> >>>>
>>> >>>>BR,
>>> >>>>
>>> >>>>Jukka Zitting
>>> >>>>
>>> >>>>
>>> >>>
>>> >>>
>>> >>
>>> >>
>>> >>
>>> >>
>>> >
>>> >
>>>
>>> --
>>> View this message in context:
>>> http://www.nabble.com/NodeTypeRegistry.checkForReferencesInContent%28%29-tf2882955.html#a8793775
>>> Sent from the Jackrabbit - Users mailing list archive at Nabble.com.
>>>
>>>
>>
>>
>> --
>> -----------------------------------------< tobias.bocanegra@day.com >---
>> Tobias Bocanegra, Day Management AG, Barfuesserplatz 6, CH - 4001 Basel
>> T +41 61 226 98 98, F +41 61 226 98 97
>> -----------------------------------------------< http://www.day.com >---
>>
>>
>
>
--
View this message in context: http://www.nabble.com/NodeTypeRegistry.checkForReferencesInContent%28%29-tf2882955.html#a8844504
Sent from the Jackrabbit - Users mailing list archive at Nabble.com.
Re: NodeTypeRegistry.checkForReferencesInContent()
Posted by anton_slutsky <as...@applevac.com>.
yeah, I figured the security thing out. Took me long enough, but better late
then never :-). If you dont mind, could you look at the attached patch
file? This implementation just throws an exception if a conflict is found.
Naturally, type reassignment can also work, but I'm thinking that it could
open a door to a bunch of issues with things like child nodes of the
conflict node, parent node type definitions, and reference properties on
other node.
http://www.nabble.com/file/6235/nodetyperegistry.patch
nodetyperegistry.patch
Tobias Bocanegra wrote:
>
> hi anton,
> as the nodetype registry has access to the "lowlevel' item states, it
> can bypass any access control when checking the content. instead of
> reassigning nt:base which would render the content invalid, i would
> use a nodetype: nt:conflict (extends nt:unstructured), which could
> have a property jcr:formerPrimaryType and jcr:formerMixinTypes
>
> regads, toby
>
> On 2/4/07, anton_slutsky <as...@applevac.com> wrote:
>>
>> Looks like I spoke without thinking. SystemSession already implementes
>> its
>> own AccessManager!
>>
>>
>> anton_slutsky wrote:
>> >
>> > I think the issue here is what to do with the already existing nodes
>> > rather then the new node creation (like you said, a NodeTypeNotFound
>> can
>> > always be thrown). But if there are nodes out there with the type we
>> are
>> > trying to delete, we need to make sure something is done to those
>> orphan
>> > nodes. Personally, I wouldnt reassign them to nt:base. I'd check for
>> > nodes of the given type, and if any are found, I'd throw a
>> > RepositoryException of some kind and have people deal with their data
>> > before they can drop a type. But thats just a suggestion. You guys
>> know
>> > this stuff better then I do :)
>> >
>> > But either way, we'll have to traverse each and every workspace to find
>> > those typed nodes. And here we'll be running into security issues if
>> > custom security/access managers are provided. In theory, we should be
>> > able to somehow get a SystemPrincipal session for each workspace and
>> that
>> > should work because SystemPrincipal should have access to everything,
>> but
>> > having recently implemented a custom security manger, I'm pretty sure
>> > people who will be doing the same will forget to account for the
>> > SystemPrincipal. I guess what we could do here is decouple the
>> > LoginModule the JAAS interface, provide corresponding template methods
>> for
>> > both the LoginModule and AccessManager, create internal instances of
>> > javax.security.auth.spi.LoginModule and AccessManager and delegate
>> calls
>> > to templates after making sure SystemPrincipal is allowed through
>> > (phhuphh! that was a mouthfull. hope it makes sense :-) ). But here,
>> > what we'll be doing is basically saying to all the users "nomatter what
>> > you do, SystemPrincipal is getting through". What do you think?
>> >
>> > Thanks,
>> > Anton
>> >
>> >
>> > Sandro Böhme wrote:
>> >>
>> >> Hello,
>> >>
>> >> I guess the deep lock is needed to avoid new creation of nodes after
>> >> the search for nodes with the node type that has to be unregistered.
>> >> If that's the case maybe there is a way to avoid the deep lock.
>> >> If a user tries to add a node with a node type that is currently
>> >> being unregistered a NodeTypeNotFoundException (or similar) could
>> >> already be thrown. This way it's possible to search for all nodes with
>> >> this type and change the type to nt:base while the amount of nodes
>> >> with this type will not change anymore.
>> >> To search for nodes by type the following query should work
>> >> "//element(*, nt:nodeType)". Of course this needs to be done for
>> >> every workspace.
>> >> Do you think that could work?
>> >>
>> >> Best regards,
>> >>
>> >> Sandro
>> >>
>> >> anton_slutsky wrote:
>> >>> Hm. Doesnt look like our implementation will work. It works for us
>> >>> because
>> >>> its our application specific, but I doubt it'll work for the project.
>> >>> Looks
>> >>> like there are a couple of issues here. 1. The deep locks solutions
>> >>> wont
>> >>> work because it's not always possible to get all workspaces or all
>> root
>> >>> nodes given the custom security managers. 2. The single-user
>> solution
>> >>> would work, but once we figure out how to place the repository into a
>> >>> single-user mode, we run into the same issue as in #1, i.e., how do
>> we
>> >>> inspect nodes if we are not guaranteed to be able to get to them?
>> >>>
>> >>> Obviously, there is a bunch of possible solutions here. Figured I'd
>> run
>> >>> it
>> >>> by you, see what you all think.
>> >>>
>> >>> 1. Add a concept of a system superuser. Will work, but kind of ugly
>> and
>> >>> adds complexity to authentication
>> >>> 2. Develop some sort of a "metadata" storage. Some sort of a
>> persistent
>> >>> structure that will keep track of references for each given type.
>> >>> Probably
>> >>> the best thing in the long run, but requires things like
>> hidden,system
>> >>> stores. Kind of complicated.
>> >>> 3. Add a reference counter on NodeTypeImpl itself. Probably the
>> >>> simplest
>> >>> solution. Modifications will need to be made to the logic of
>> persisting
>> >>> new
>> >>> and deleting items (as it would have to be in #2), but this way
>> provides
>> >>> for
>> >>> the cheapest and quickest way to see if there are live nodes of a
>> >>> certain
>> >>> type
>> >>>
>> >>>
>> >>> Jukka Zitting wrote:
>> >>>
>> >>>>Hi,
>> >>>>
>> >>>>On 12/26/06, anton_slutsky <as...@applevac.com> wrote:
>> >>>>
>> >>>>>I'm wondering if anyone's actively working on implementing the
>> >>>>>checkForReferencesInContent() method (quoted below). Because if
>> not,
>> >>>>>we'd
>> >>>>>like to contribute source. unregisterNodeTypes() doesnt work
>> without
>> it.
>> >>>>>Makes it a bit of a pain to write unit tests as well as some
>> application
>> >>>>>functionality. Please let me know if anyone's doing this already so
>> we
>> >>>>>dont
>> >>>>>duplicate effort.
>> >>>>
>> >>>>There's a long-standing feature request JCR-322 about this, but
>> >>>>although it's popped up in discussion every now and then, there
>> hasn't
>> >>>>yet been much real effort to resolve it. Contributions would be very
>> >>>>welcome!
>> >>>>
>> >>>>Note that implementing the method is somewhat hard, as you'd
>> >>>>essentially need to get a global write lock on the entire repository
>> >>>>and traverse all the content to find the node type references. This
>> >>>>operation might also interfere with any pending transient or
>> >>>>transactional changes.
>> >>>>
>> >>>>BR,
>> >>>>
>> >>>>Jukka Zitting
>> >>>>
>> >>>>
>> >>>
>> >>>
>> >>
>> >>
>> >>
>> >>
>> >
>> >
>>
>> --
>> View this message in context:
>> http://www.nabble.com/NodeTypeRegistry.checkForReferencesInContent%28%29-tf2882955.html#a8793775
>> Sent from the Jackrabbit - Users mailing list archive at Nabble.com.
>>
>>
>
>
> --
> -----------------------------------------< tobias.bocanegra@day.com >---
> Tobias Bocanegra, Day Management AG, Barfuesserplatz 6, CH - 4001 Basel
> T +41 61 226 98 98, F +41 61 226 98 97
> -----------------------------------------------< http://www.day.com >---
>
>
--
View this message in context: http://www.nabble.com/NodeTypeRegistry.checkForReferencesInContent%28%29-tf2882955.html#a8796602
Sent from the Jackrabbit - Users mailing list archive at Nabble.com.
Re: NodeTypeRegistry.checkForReferencesInContent()
Posted by Tobias Bocanegra <to...@day.com>.
hi anton,
as the nodetype registry has access to the "lowlevel' item states, it
can bypass any access control when checking the content. instead of
reassigning nt:base which would render the content invalid, i would
use a nodetype: nt:conflict (extends nt:unstructured), which could
have a property jcr:formerPrimaryType and jcr:formerMixinTypes
regads, toby
On 2/4/07, anton_slutsky <as...@applevac.com> wrote:
>
> Looks like I spoke without thinking. SystemSession already implementes its
> own AccessManager!
>
>
> anton_slutsky wrote:
> >
> > I think the issue here is what to do with the already existing nodes
> > rather then the new node creation (like you said, a NodeTypeNotFound can
> > always be thrown). But if there are nodes out there with the type we are
> > trying to delete, we need to make sure something is done to those orphan
> > nodes. Personally, I wouldnt reassign them to nt:base. I'd check for
> > nodes of the given type, and if any are found, I'd throw a
> > RepositoryException of some kind and have people deal with their data
> > before they can drop a type. But thats just a suggestion. You guys know
> > this stuff better then I do :)
> >
> > But either way, we'll have to traverse each and every workspace to find
> > those typed nodes. And here we'll be running into security issues if
> > custom security/access managers are provided. In theory, we should be
> > able to somehow get a SystemPrincipal session for each workspace and that
> > should work because SystemPrincipal should have access to everything, but
> > having recently implemented a custom security manger, I'm pretty sure
> > people who will be doing the same will forget to account for the
> > SystemPrincipal. I guess what we could do here is decouple the
> > LoginModule the JAAS interface, provide corresponding template methods for
> > both the LoginModule and AccessManager, create internal instances of
> > javax.security.auth.spi.LoginModule and AccessManager and delegate calls
> > to templates after making sure SystemPrincipal is allowed through
> > (phhuphh! that was a mouthfull. hope it makes sense :-) ). But here,
> > what we'll be doing is basically saying to all the users "nomatter what
> > you do, SystemPrincipal is getting through". What do you think?
> >
> > Thanks,
> > Anton
> >
> >
> > Sandro Böhme wrote:
> >>
> >> Hello,
> >>
> >> I guess the deep lock is needed to avoid new creation of nodes after
> >> the search for nodes with the node type that has to be unregistered.
> >> If that's the case maybe there is a way to avoid the deep lock.
> >> If a user tries to add a node with a node type that is currently
> >> being unregistered a NodeTypeNotFoundException (or similar) could
> >> already be thrown. This way it's possible to search for all nodes with
> >> this type and change the type to nt:base while the amount of nodes
> >> with this type will not change anymore.
> >> To search for nodes by type the following query should work
> >> "//element(*, nt:nodeType)". Of course this needs to be done for
> >> every workspace.
> >> Do you think that could work?
> >>
> >> Best regards,
> >>
> >> Sandro
> >>
> >> anton_slutsky wrote:
> >>> Hm. Doesnt look like our implementation will work. It works for us
> >>> because
> >>> its our application specific, but I doubt it'll work for the project.
> >>> Looks
> >>> like there are a couple of issues here. 1. The deep locks solutions
> >>> wont
> >>> work because it's not always possible to get all workspaces or all root
> >>> nodes given the custom security managers. 2. The single-user solution
> >>> would work, but once we figure out how to place the repository into a
> >>> single-user mode, we run into the same issue as in #1, i.e., how do we
> >>> inspect nodes if we are not guaranteed to be able to get to them?
> >>>
> >>> Obviously, there is a bunch of possible solutions here. Figured I'd run
> >>> it
> >>> by you, see what you all think.
> >>>
> >>> 1. Add a concept of a system superuser. Will work, but kind of ugly and
> >>> adds complexity to authentication
> >>> 2. Develop some sort of a "metadata" storage. Some sort of a persistent
> >>> structure that will keep track of references for each given type.
> >>> Probably
> >>> the best thing in the long run, but requires things like hidden,system
> >>> stores. Kind of complicated.
> >>> 3. Add a reference counter on NodeTypeImpl itself. Probably the
> >>> simplest
> >>> solution. Modifications will need to be made to the logic of persisting
> >>> new
> >>> and deleting items (as it would have to be in #2), but this way provides
> >>> for
> >>> the cheapest and quickest way to see if there are live nodes of a
> >>> certain
> >>> type
> >>>
> >>>
> >>> Jukka Zitting wrote:
> >>>
> >>>>Hi,
> >>>>
> >>>>On 12/26/06, anton_slutsky <as...@applevac.com> wrote:
> >>>>
> >>>>>I'm wondering if anyone's actively working on implementing the
> >>>>>checkForReferencesInContent() method (quoted below). Because if not,
> >>>>>we'd
> >>>>>like to contribute source. unregisterNodeTypes() doesnt work without
> it.
> >>>>>Makes it a bit of a pain to write unit tests as well as some
> application
> >>>>>functionality. Please let me know if anyone's doing this already so we
> >>>>>dont
> >>>>>duplicate effort.
> >>>>
> >>>>There's a long-standing feature request JCR-322 about this, but
> >>>>although it's popped up in discussion every now and then, there hasn't
> >>>>yet been much real effort to resolve it. Contributions would be very
> >>>>welcome!
> >>>>
> >>>>Note that implementing the method is somewhat hard, as you'd
> >>>>essentially need to get a global write lock on the entire repository
> >>>>and traverse all the content to find the node type references. This
> >>>>operation might also interfere with any pending transient or
> >>>>transactional changes.
> >>>>
> >>>>BR,
> >>>>
> >>>>Jukka Zitting
> >>>>
> >>>>
> >>>
> >>>
> >>
> >>
> >>
> >>
> >
> >
>
> --
> View this message in context: http://www.nabble.com/NodeTypeRegistry.checkForReferencesInContent%28%29-tf2882955.html#a8793775
> Sent from the Jackrabbit - Users mailing list archive at Nabble.com.
>
>
--
-----------------------------------------< tobias.bocanegra@day.com >---
Tobias Bocanegra, Day Management AG, Barfuesserplatz 6, CH - 4001 Basel
T +41 61 226 98 98, F +41 61 226 98 97
-----------------------------------------------< http://www.day.com >---
Re: NodeTypeRegistry.checkForReferencesInContent()
Posted by anton_slutsky <as...@applevac.com>.
Looks like I spoke without thinking. SystemSession already implementes its
own AccessManager!
anton_slutsky wrote:
>
> I think the issue here is what to do with the already existing nodes
> rather then the new node creation (like you said, a NodeTypeNotFound can
> always be thrown). But if there are nodes out there with the type we are
> trying to delete, we need to make sure something is done to those orphan
> nodes. Personally, I wouldnt reassign them to nt:base. I'd check for
> nodes of the given type, and if any are found, I'd throw a
> RepositoryException of some kind and have people deal with their data
> before they can drop a type. But thats just a suggestion. You guys know
> this stuff better then I do :)
>
> But either way, we'll have to traverse each and every workspace to find
> those typed nodes. And here we'll be running into security issues if
> custom security/access managers are provided. In theory, we should be
> able to somehow get a SystemPrincipal session for each workspace and that
> should work because SystemPrincipal should have access to everything, but
> having recently implemented a custom security manger, I'm pretty sure
> people who will be doing the same will forget to account for the
> SystemPrincipal. I guess what we could do here is decouple the
> LoginModule the JAAS interface, provide corresponding template methods for
> both the LoginModule and AccessManager, create internal instances of
> javax.security.auth.spi.LoginModule and AccessManager and delegate calls
> to templates after making sure SystemPrincipal is allowed through
> (phhuphh! that was a mouthfull. hope it makes sense :-) ). But here,
> what we'll be doing is basically saying to all the users "nomatter what
> you do, SystemPrincipal is getting through". What do you think?
>
> Thanks,
> Anton
>
>
> Sandro Böhme wrote:
>>
>> Hello,
>>
>> I guess the deep lock is needed to avoid new creation of nodes after
>> the search for nodes with the node type that has to be unregistered.
>> If that's the case maybe there is a way to avoid the deep lock.
>> If a user tries to add a node with a node type that is currently
>> being unregistered a NodeTypeNotFoundException (or similar) could
>> already be thrown. This way it's possible to search for all nodes with
>> this type and change the type to nt:base while the amount of nodes
>> with this type will not change anymore.
>> To search for nodes by type the following query should work
>> "//element(*, nt:nodeType)". Of course this needs to be done for
>> every workspace.
>> Do you think that could work?
>>
>> Best regards,
>>
>> Sandro
>>
>> anton_slutsky wrote:
>>> Hm. Doesnt look like our implementation will work. It works for us
>>> because
>>> its our application specific, but I doubt it'll work for the project.
>>> Looks
>>> like there are a couple of issues here. 1. The deep locks solutions
>>> wont
>>> work because it's not always possible to get all workspaces or all root
>>> nodes given the custom security managers. 2. The single-user solution
>>> would work, but once we figure out how to place the repository into a
>>> single-user mode, we run into the same issue as in #1, i.e., how do we
>>> inspect nodes if we are not guaranteed to be able to get to them?
>>>
>>> Obviously, there is a bunch of possible solutions here. Figured I'd run
>>> it
>>> by you, see what you all think.
>>>
>>> 1. Add a concept of a system superuser. Will work, but kind of ugly and
>>> adds complexity to authentication
>>> 2. Develop some sort of a "metadata" storage. Some sort of a persistent
>>> structure that will keep track of references for each given type.
>>> Probably
>>> the best thing in the long run, but requires things like hidden,system
>>> stores. Kind of complicated.
>>> 3. Add a reference counter on NodeTypeImpl itself. Probably the
>>> simplest
>>> solution. Modifications will need to be made to the logic of persisting
>>> new
>>> and deleting items (as it would have to be in #2), but this way provides
>>> for
>>> the cheapest and quickest way to see if there are live nodes of a
>>> certain
>>> type
>>>
>>>
>>> Jukka Zitting wrote:
>>>
>>>>Hi,
>>>>
>>>>On 12/26/06, anton_slutsky <as...@applevac.com> wrote:
>>>>
>>>>>I'm wondering if anyone's actively working on implementing the
>>>>>checkForReferencesInContent() method (quoted below). Because if not,
>>>>>we'd
>>>>>like to contribute source. unregisterNodeTypes() doesnt work without
it.
>>>>>Makes it a bit of a pain to write unit tests as well as some
application
>>>>>functionality. Please let me know if anyone's doing this already so we
>>>>>dont
>>>>>duplicate effort.
>>>>
>>>>There's a long-standing feature request JCR-322 about this, but
>>>>although it's popped up in discussion every now and then, there hasn't
>>>>yet been much real effort to resolve it. Contributions would be very
>>>>welcome!
>>>>
>>>>Note that implementing the method is somewhat hard, as you'd
>>>>essentially need to get a global write lock on the entire repository
>>>>and traverse all the content to find the node type references. This
>>>>operation might also interfere with any pending transient or
>>>>transactional changes.
>>>>
>>>>BR,
>>>>
>>>>Jukka Zitting
>>>>
>>>>
>>>
>>>
>>
>>
>>
>>
>
>
--
View this message in context: http://www.nabble.com/NodeTypeRegistry.checkForReferencesInContent%28%29-tf2882955.html#a8793775
Sent from the Jackrabbit - Users mailing list archive at Nabble.com.