Details

    • Type: New Feature New Feature
    • Status: Closed
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: None
    • Fix Version/s: None
    • Component/s: JCR-Mapping
    • Labels:
      None

      Description

      It registers the node types of the mapping model.

        Activity

        Hide
        Sandro Boehme added a comment -

        As the registration is specific to a JCR implementation, it should pluggable.

        Show
        Sandro Boehme added a comment - As the registration is specific to a JCR implementation, it should pluggable.
        Hide
        Sandro Boehme added a comment -

        Beside others, there a two dependencies when registering a
        node type in Jackrabbit:
        o Supertypes must exist and be registered
        and
        o Default node type in child-node definitions must exist and be registered

        I will call those conditions just "dependencies" now.

        ++ resolving the dependency tree ++
        This creates a tree of dependencies. Because you need to register the dependent node types one after another before the current node type can be registered completely. You can recursively step down the tree until there are no dependencies anymore. Then you can completely register the last node type. This solves a dependency of the parent node type
        you came from.
        In this situation you can step up to the parent node type.
        All other dependencies of that node type and the other parent node types can be resolved the same way: Step down until it can be registered and step up and register if all dependencies are solved.

        ++ resolving circular dependencies ++
        A dependent node type can be of the same node type like the current node type.
        E.g. if you currently want to register a node type "folder" which has a child node
        "first child folder" and this child node has the default node type "folder".
        This turns the tree of dependencies in a graph and creates a circular dependency. The reason is, as you try to register the node type "folder", the dependency (child node's default node type "folder") already needs to be registered.

        Of course the circular dependency can also occur from a dependency further down the tree:
        The described registration procedure can create a path of node types to register. Because you need to step
        deeper to the next branch when dependencies need to be resolved. In this process you can hit three types
        of node types:
        a) node types which are completely registered
        b) node types whose dependencies are partially solved (one in the currently processed path of node types)
        c) not touched node types
        In the case you hit type a) this would resolve a dependency.
        In the case you hit type c) this would mean you need to resolve the not touched node type.
        In the case you hit type b) you have a graph of node types and a circular dependency.

        The solution is pretty simple. When you want to register the node type you can first register it without any dependencies. If you then are in the "c)"-Situation you have a node type which is registered and because of this, it is not a dependency anymore. If all dependencies of a nodetype are solved you can reregister the node type completely with all dependencies.

        Show
        Sandro Boehme added a comment - Beside others, there a two dependencies when registering a node type in Jackrabbit: o Supertypes must exist and be registered and o Default node type in child-node definitions must exist and be registered I will call those conditions just "dependencies" now. ++ resolving the dependency tree ++ This creates a tree of dependencies. Because you need to register the dependent node types one after another before the current node type can be registered completely. You can recursively step down the tree until there are no dependencies anymore. Then you can completely register the last node type. This solves a dependency of the parent node type you came from. In this situation you can step up to the parent node type. All other dependencies of that node type and the other parent node types can be resolved the same way: Step down until it can be registered and step up and register if all dependencies are solved. ++ resolving circular dependencies ++ A dependent node type can be of the same node type like the current node type. E.g. if you currently want to register a node type "folder" which has a child node "first child folder" and this child node has the default node type "folder". This turns the tree of dependencies in a graph and creates a circular dependency. The reason is, as you try to register the node type "folder", the dependency (child node's default node type "folder") already needs to be registered. Of course the circular dependency can also occur from a dependency further down the tree: The described registration procedure can create a path of node types to register. Because you need to step deeper to the next branch when dependencies need to be resolved. In this process you can hit three types of node types: a) node types which are completely registered b) node types whose dependencies are partially solved (one in the currently processed path of node types) c) not touched node types In the case you hit type a) this would resolve a dependency. In the case you hit type c) this would mean you need to resolve the not touched node type. In the case you hit type b) you have a graph of node types and a circular dependency. The solution is pretty simple. When you want to register the node type you can first register it without any dependencies. If you then are in the "c)"-Situation you have a node type which is registered and because of this, it is not a dependency anymore. If all dependencies of a nodetype are solved you can reregister the node type completely with all dependencies.
        Hide
        Martin Kočí added a comment -

        SImple patch - using Jackrabbit internal API.

        Show
        Martin Kočí added a comment - SImple patch - using Jackrabbit internal API.
        Hide
        Martin Kočí added a comment -

        I suggest following:
        decouple API from PersistenceManagerImpl - it can use JCR session or JCR workspace.
        move to jackrabbit sub-package

        Question: when perform custom node type registration? Note types are shared over whole repository, but for registration:
        Session session = repository.login(..)
        session.getWorkspace().getNoteTypeManager()

        is needed - so it relies on logged user?

        Show
        Martin Kočí added a comment - I suggest following: decouple API from PersistenceManagerImpl - it can use JCR session or JCR workspace. move to jackrabbit sub-package Question: when perform custom node type registration? Note types are shared over whole repository, but for registration: Session session = repository.login(..) session.getWorkspace().getNoteTypeManager() is needed - so it relies on logged user?
        Hide
        Oliver Kießler added a comment -

        @Sandro: Are you still working on this? Christophe and I decided to create a new subproject for JCR nodetype management. So if you have some code or ideas, let's try to define a common API and merge it.

        Show
        Oliver Kießler added a comment - @Sandro: Are you still working on this? Christophe and I decided to create a new subproject for JCR nodetype management. So if you have some code or ideas, let's try to define a common API and merge it.
        Hide
        Sandro Boehme added a comment -

        As the Jackrabbit issues JCR-273 and JCR-274 are solved, managing circular dependencies is handled by
        Jackrabbits NodeTypeRegistry.registerNodeTypes(Collection) method. My workaround in this GRFT-23 issue
        hit the problem, that it is not possible at the moment to reregister custom super node types. As custom
        super node types can be registered with the NodeTypeRegistry.registerNodeTypes(Collection) method now,
        this is also not a problem anymore.
        This makes it possible now to register such a Graffito node type structure which contains custom super node types
        and circular dependend node types:

        [CmsObject]
        + parentFolder (Folder)

        [Folder] > CmsObject
        + folders (Folder)
        + documents (Document)

        [Document] > CmsObject

        • size (long)
        Show
        Sandro Boehme added a comment - As the Jackrabbit issues JCR-273 and JCR-274 are solved, managing circular dependencies is handled by Jackrabbits NodeTypeRegistry.registerNodeTypes(Collection) method. My workaround in this GRFT-23 issue hit the problem, that it is not possible at the moment to reregister custom super node types. As custom super node types can be registered with the NodeTypeRegistry.registerNodeTypes(Collection) method now, this is also not a problem anymore. This makes it possible now to register such a Graffito node type structure which contains custom super node types and circular dependend node types: [CmsObject] + parentFolder (Folder) [Folder] > CmsObject + folders (Folder) + documents (Document) [Document] > CmsObject size (long)
        Hide
        Sandro Boehme added a comment -

        Fixed in Jackrabbit

        Show
        Sandro Boehme added a comment - Fixed in Jackrabbit

          People

          • Assignee:
            Sandro Boehme
            Reporter:
            Sandro Boehme
          • Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development