Is it possible to add new mixin by reloading CND file without restarting the repository ?

[penkween]

Hi,

      For Filesystem Connector repository used in App server. Basically, we use Modeshape (JCR)  mainly to store extra Metadata along side with File(nt:file) and Folder(nt:folder), but situation may arise when we might want to add new Metadata field (or remove old Metadata) from time to time.  Normally, we add Metadata by using Mixin and we define Mixin in CND file which is refered inside RepositoryConfig.xml eg. <jcr:nodeTypes mode:resource="./repository/myMixin.cnd" />  and after the JcrEngine&Repository is started , our program later can then add Mixin to node using eg. node.addMixin("my:author").

       I am wondering how do we add new Mixin without restarting the repository ? Is there anyway to reload the modified CND file so that we can add the new Mixin on the fly ? Complication also arise if we delete mixin inside CND, not sure how Modeshape is going to handle that when we read the Nodes.

Thanks in advance.

[rhauch]

Yes, you can use the JCR 2.0 API to register new node types or update existing node types. This is done with the NodeTypeManager object that is accessed from the session's workspace, and with ModeShape you can pass any classes that properly implement the NodeType interface to the 'registerNodeTypes' method. ModeShape even supports the JCR API's template interfaces for programmatically creating and/or modifying node type definitions.

Unfortunately, the one thing that the JCR API does not provide is a utility for reading in a CND file and constructing the node type definition templates. This is a shame, because everything I talked about above is part of the standard JCR API. So to make this easier, ModeShape provides a CndNodeTypeReader utility class that will read a CND file and return the javax.jcr.nodetype.NodeType instances, which you can then register using the standard API. For details on how to use the class, the JavaDoc.

Note: it is critical that your node type modifications be done carefully. There are lots of ways of safely evolving node type definitions, even when those node type definitions are used in existing content. However, changing registered node types in a way that is not compatible with existing content will almost certainly result in errors when reading in that content. If this happens, all you have to do is change the node type definitions so that all your content is again compatible with it, and then your content can be accessed again.

[penkween]

Hi Randall,

Firstly

==============================

Thank for your reply. Have tested with the CndNodeTypeManager and it work. Just have to find out way to unregister nodetype before register nodetype to avoid having to create a new CND file each time for adding new nodetype. How we wish we do have such :

unRegisterNodeTypes(NodeTypeDefinition ntd, boolean allowUpdate)

      Anyway, even with the above command,  nothing much we can do because we can only unRegister existing nodeType only if the nodeType is not referenced with any existing Nodes or else we will get this error "Cannot unregister type 'bplet:tagdata' because it is currently being used on at least one node" mean we have to remove Mixin attachment with every Nodes before we can unregister its nodeType.

Secondly

==============================

Facing one issue, Just now when testing adding new mixin via CndNodeTypeManage, I found out that those Folder Nodes (nt:folder) created with Mixin attached cannot be retrieved after restarting the repository. In fact, the JcrEngine return Repository=NULL when started. Same thing happen when only using mixin CND inside RepositoryConfig.xml (Means not using any CndNodeTypeManager). This problem never happen before and previously tested with the same CND file is OK.

Further testing: I found out that this problem only happen when using <mode:option jcr:name="rebuildQueryIndexOnStartup" mode:value="always"/> and is OK when using <mode:option jcr:name="rebuildQueryIndexOnStartup" mode:value="ifMissing"/>

[rhauch]

      Anyway, even with the above command,  nothing much we can do because we can only unRegister existing nodeType only if the nodeType is not referenced with any existing Nodes or else we will get this error "Cannot unregister type 'bplet:tagdata' because it is currently being used on at least one node" mean we have to remove Mixin attachment with every Nodes before we can unregister its nodeType.

That's correct. You have to remove the mixin on the nodes (or the nodes themselves) before you can unregister it. However, if you're just updating the node type, you can simply re-register the (updated) node type definition.

Facing one issue, Just now when testing adding new mixin via CndNodeTypeManage, I found out that those Folder Nodes (nt:folder) created with Mixin attached cannot be retrieved after restarting the repository. In fact, the JcrEngine return Repository=NULL when started. Same thing happen when only using mixin CND inside RepositoryConfig.xml (Means not using any CndNodeTypeManager). This problem never happen before and previously tested with the same CND file is OK.

This is what I was saying before about modifying a node type definition if it is used by content. Any such modifications have to be backward compatible with all the existing content that used the old definition.

Further testing: I found out that this problem only happen when using <mode:option jcr:name="rebuildQueryIndexOnStartup" mode:value="always"/> and is OK when using <mode:option jcr:name="rebuildQueryIndexOnStartup" mode:value="ifMissing"/>

This configuration setting makes indexing happen every time the repository is started up, and it accesses all content in the repository. Therefore, you probably just never ran into the problem before.

[penkween]

Hi Randall,

The second issue however has nothing to do with NodeType or Mixin Modification. It seem like the indexing fail to reindex existing Nodes with Mixin after restarting the repository. Previously, from what has been resolved in Mode-1263 where the Indexer won't even reindex File system nodes (even without Mixin).

Thanks.