jackrabbit-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From anton_slutsky <aslut...@applevac.com>
Subject Re: NodeTypeRegistry.checkForReferencesInContent()
Date Sun, 04 Feb 2007 15:34:06 GMT

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 <aslutsky@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.


Mime
View raw message