Hi, I attached the requested changes to JCR-349....also see below for comments (also included in JCR-349).
David "Jukka Zitting" <[EMAIL PROTECTED]> wrote on 04/20/2006 12:29:23 PM: > Hi, > > On 4/20/06, David Kennedy <[EMAIL PROTECTED]> wrote: > > 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). > > Excellent, thanks! > > > 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. > > How about adding the namespace registry as a private member variable > of the NodeTypeManagerImpl class and have SessionImpl pass the > namespace registry to the node type manager as a constructor argument? > This way the registry handling would be completely transparent to the > user and they could just continue using the existing methods. Yeah, I started out this way, but wasn't sure you'd want the registration to be the default behavior > > > 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). > > This is a good approach. BTW, instead of checking for the prefix you > should be checking for the availability of the namespace URI. The > process should be something like this: > > if URI is not already registered, then > while PREFIX is already registered, do > generate another PREFIX > end while > register the PREFIX -> URI mapping > end if > I don't follow the "generate another PREFIX". I changed the code to check for the uri, but if the uri isn't found, I just try to register the prefix to uri.....if the prefix is already registered to a different uri, we'll get an exception which is what we want. If the prefix isn't registered, we're good to go. Let me know if I'm missing something. > It's a bit cumbersome, especially since the getPrefix() and getURI() > methods throw exceptions to indicate unregistered mappings, *and* it > isn't thread-safe, but this is the best we have at the moment. Perhaps > we could encapsulate this functionality into a custom > NamespaceRegistryImpl method... > > > 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. > > Yeah, that's a problem with the fact that we currently can't modify or > even remove existing node types without manual intervention. I think > it's ok at the moment to just disable the test cases with a logged > warning if the conflicting node types 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. > > This functionality would probably be a good fit for a > reregisterNodeTypes method. See JCR-322 for background. > > > Let me know what you think and if you'd like patches in a different format. > > Looks good. Can you fix the issues I mentioned (ns registry as member > variable, and the namespace registration process)? > > I can use the zip format, but a more convenient alternative would be > the output of "svn diff". Quick steps to do this: > > 1) Checkout the latest sources from SVN as instructed on the > Jackrabbit web site > 2) Make your modifications > 3) Use "svn add ..." to mark any new files and directories you've added > 4) use "svn diff" from the main jackrabbit directory to get a listing > of all the changes > 5) Save the output in a file and attach it to the Jira issue (JCR-349) > 6) Remember to select the license grant option on the attachment form > > BR, > > Jukka Zitting > > -- > Yukatan - http://yukatan.fi/ - [EMAIL PROTECTED] > Software craftsmanship, JCR consulting, and Java development
