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 Fri, 02 Feb 2007 15:19:04 GMT

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?  


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:
>>>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,
>>>>like to contribute source.  unregisterNodeTypes() doesnt work without
>>>>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
>>>>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
>>>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.
>>>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.

View raw message