jackrabbit-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jukka Zitting" <jukka.zitt...@gmail.com>
Subject Re: [jira] Resolved: (JCR-349) New node type namespaces should be automatically registered
Date Mon, 24 Apr 2006 08:14:53 GMT
Hi,

On 4/24/06, David Kennedy <davek@us.ibm.com> wrote:
> I looked at the changes you made to the registerNamespace method in the
> NodeTypeManagerImpl to find a unique prefix and was hoping you could shed
> some light on why you continue to try to find a different unique prefix if
> the original prefix is already registered.

Certainly. I believe you have a misunderstood how namespaces are used in JCR.

The prefix associated with a namespace is just a shorthand for the
full URI that uniquely identifies the namespace. Internally all
content (including node type definitions) is stored and accessed using
the namespace URI to denote the namespace in use. Names and paths are
converted to and from the prefixed format using the session namespace
mappings just before they are returned by and just after they are
passed to JCR methods.

It is possible for the prefix mapped to a namespace to change, but the
URI remains. Thus in general your application shouldn't rely on any
specific prefix (other than the ones reserved in the JCR
specification) if you want to make it work also when namespace
registry is outside your direct control.

> Won't it be a problem not that my nodetypes and code are referencing nodes
> and types in the http://someother.namespace space since I'm using the foo
> prefix and don't know about the foo2 prefix?

Yes, it is a problem, but one that you need to address either manually
by 1) explicitly changing the registered prefix to match those that
your application expects, or automatically by 2) rewriting all the
hardcoded names and paths in your application (something like:
session.getNamespacePrefix() + ":foo") or 3) using
Session.setNamespacePrefix() to remap the namespace prefixes the way
your application expects them.

Unless we do generate a unique prefix in case of conflicts, the node
type import in your version of the patch would fail with an exception,
forcing the user to either remap the existing prefix in the namespace
registry (option 1) or to rewrite the node type definition file to use
another prefix (option 2).

It is quite unfortunate that the current JCR API makes it quite hard
to use Session.setNamespacePrefix() (option 3) correctly in the event
of prefix collisions. Below is my current best attempt at using the
API safely (i.e. automatically circumventing the possible
NamespaceExceptions):

    try {
        // Prefix "foo" already bound?
        String uri = session.getNamespaceURI("foo");
        // Bound to the correct namespace?
        boolean mapped = uri.equals("http://myfoo.namespace");
        // Try to remap namespace to another prefix
        for (int i = 0; !mapped; i++) {
            try {
                 session.setNamespacePrefix("ns" + i, uri);
                 // remapping succeeded, "foo" can now be mapped
                 session.setNamespacePrefix(
                     "foo", "http://myfoo.namespace");
                 mapped = true;
            } catch (NamespaceException e2) {
                 // failed to remap, try next prefix
            }
        }
    } catch (NamespaceException e1) {
        // Prefix "foo" not previously bound
        session.setNamespacePrefix("foo", "http://myfoo.namespace");
    }

I've filed an issue for JSR 283 to make this easier in JCR 2.0, but
we'll need to wait and see how that turns out.

BR,

Jukka Zitting

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