Hi Alex, thanks for the suggestion. That could be a good workaround, though it is quite annoying that a bug in Jackrabbit code makes the feature of automatic registration of node types in Sling unusable. I tried to understand what's happening inside Jackrabbit and I am quite confident now that the issue is related to the way in which defaults in node type definition are handled. In particular, it looks like the specific problem about child nodes is caused by the Required Primary Node Types field: if leaved blank in the types.cnd, the field of the class storing the node definition is 'null' in same cases and "nt:base" in others, thus generating a false difference detection. This is confirmed by the fact that, after changing my types.cnd as below, the issue seems to be gone.
[myns:Album] > myns:BaseType - sling:resourceType (string) = 'myns/album' copy autocreated + images (nt:base) = nt:unstructured version autocreated Regards, Davide On Mon, Aug 16, 2010 at 8:41 PM, Alexander Klimetschek <[email protected]>wrote: > On Mon, Aug 16, 2010 at 19:18, Davide Maestroni > <[email protected]> wrote: > > Yes, it could definitely be the same issue, and I see that unfortunately > no > > one fixed it... > > Do you happen to know any workaround? I tried to look into Jackrabbit > 2.1.0. > > but I could not find any major modifications in the related classes. > > This is a real show stopper in case I want to change the node type > > definitions of an existing repository. > > Instead of the commons CND importer utility, you can read the node > type templates from the CND, and then re-register them one by one. > Then you can unregister the node types first and then add the new > ones, which should work for all "conflicting" cases. > > Here is the code I used for a node type upgrade utility. Something > like this gives you the templates (non-jcr-api classes are from > jackrabbit-jcr-commons): > > import org.apache.jackrabbit.commons.cnd.*; > > InputStream in = ... // cnd input stream > > NodeTypeManager nodeTypeManager = > session.getWorkspace().getNodeTypeManager(); > ValueFactory valueFactory = session.getValueFactory(); > NamespaceRegistry namespaceRegistry = > session.getWorkspace().getNamespaceRegistry(); > > DefinitionBuilderFactory<NodeTypeTemplate, NamespaceRegistry> factory = > new TemplateBuilderFactory(nodeTypeManager, valueFactory, > namespaceRegistry); > > CompactNodeTypeDefReader<NodeTypeTemplate, NamespaceRegistry> cndReader > = > new CompactNodeTypeDefReader<NodeTypeTemplate, > NamespaceRegistry>(new InputStreamReader(in), "nodetypes.cnd", > factory); > > List<NodeTypeTemplate> templates = cndReader.getNodeTypeDefinitions(); > > Then you can iterate over the template, find already registered node types > via: > > nodeTypeManager.hasNodeType(template.getName()) > > and unregister (remove) and register (add) the types via: > > nodeTypeManager.unregisterNodeTypes() and registerNodeTypes() > > Hope that helps, > Alex > > -- > Alexander Klimetschek > [email protected] >
