jackrabbit-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Kennedy <da...@us.ibm.com>
Subject Re: Can the NodeTypeReader classes be changed to automatically register the namespaces?
Date Thu, 20 Apr 2006 19:40:35 GMT
Hi,  I attached the requested changes to JCR-349....also see below for 
comments (also included in JCR-349).


"Jukka Zitting" <jukka.zitting@gmail.com> wrote on 04/20/2006 12:29:23 PM:

> Hi,
> On 4/20/06, David Kennedy <davek@us.ibm.com> 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 
> > 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 
> > 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 
> > 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 
> > 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 
> 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/ - info@yukatan.fi
> Software craftsmanship, JCR consulting, and Java development

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message