Hi, On 2/26/07, ruchi goel <[EMAIL PROTECTED]> wrote:
OK. But if you want to check if a nodetype is already registered, ( and reregister or do not register depending on your requirement) , you still need to iterate and register nodes one by one.So, what s the advantage of manager.registerNodeTypes(xml, JackrabbitNodeTypeManager.TEXT_XML); as opposed to ntReg.registerNodeType(def); I understand that manager.registerNodeTypes(xml, JackrabbitNodeTypeManager.TEXT_XML); can register in one shot , but may be it is a good idea to use it at the end of development , when you know you will not be registering or reregistering the nodes again and again.
You could achieve the same effect by putting each additional node type (or set of them) in a new node type definition file. But you're right, the JackrabbitNodeTypeManager interface is (intentionally) not as powerful as the underlying NodeTypeManagerImpl and NodeTypeRegistry classes. The problem with your approach is that it requires explicit care from the node type definition writer to put the definitions in such an order that any dependencies between types are correctly ordered and that there are no circular dependencies. Another problem is that there are no guarantees that the internal methods (or their semantics) remain the same across Jackrabbit releases, as we only guarantee backwards compatibility for the JCR API and the extension interfaces defined in jackrabbit-api. More generally, the node type management support in Jackrabbit is still quite limited, i.e. you're restricted to just adding new types and making only trivial changes to existing types. Thus, during development I generally recreate the entire test repository when I need to make changes to my node type definitions. Obviously this is a poor solution when you need to upgrade production repositories. :-( BR, Jukka Zitting
