Attached is a patch (I'm not sure how you typically like to receive patches) for the automatic registration of namespaces on import of xml or cnd nodetype files (JCR-349).  A little info about the changes:
I didn't want the readers to have knowledge of workspaces or registries so I basically added additional methods to the NodeTypeManagerImpl that would take a registry in which the namespaces should be registered.  The code will ignore a namespace if it has already been registered (I can change it to throw an exception if the registered uri is different than what's in the file).  I've also included a test for each type of file.  The tests will fail if run a second time against the same repository, but not because of the namespace registration, but because the nodetypes already exist.  This brings up another suggestion.  What do you think about an enhancement in which we add another registerNodeTypes method which takes a flag to determine whether it should bypass existing registeredNodeTypes?  This would permit the user/developers to run their code that imports the same nodetypes without having to clean out the registries.

Let me know what you think and if you'd like patches in a different format.


"Jukka Zitting" <jukka.zitting@gmail.com>

04/18/2006 05:06 PM
Please respond to

Re: Can the NodeTypeReader classes be changed to automatically register the namespaces?


On 4/18/06, David Kennedy <davek@us.ibm.com> wrote:
> The NodeTypeReader and CompactNodeTypeDefReader classes parse node type
> definition files and discover any referenced namespace definitions, but do
> not register them.  Can the readers be changed to automatically register
> the namespace definitions in addition to the nodetype definitions?

There's already an improvement request about this (see JCR-349), but
it hasn't yet been taken up by anyone. You can vote for the request
(or, if you're adventurous enough, submit a patch) to speed things up.


Jukka Zitting

Yukatan - http://yukatan.fi/ - info@yukatan.fi
Software craftsmanship, JCR consulting, and Java development