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 <[EMAIL PROTECTED]> 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.
