Jackrabbit Content Repository
  1. Jackrabbit Content Repository
  2. JCR-644

Node.isNodeType() throws if namespace is not defined.

    Details

    • Type: Bug Bug
    • Status: Closed
    • Priority: Major Major
    • Resolution: Won't Fix
    • Affects Version/s: 0.9, 1.0, 1.0.1, 1.1
    • Fix Version/s: None
    • Component/s: nodetype
    • Labels:
      None

      Description

      eg: node.isNodeType("foo:MyNodeType")

      throws an exception if 'foo' is not defined. this is incorrect since an application should not need to check if the namespace exists before checking for a nodetype. it should return false.

        Activity

        Hide
        Jukka Zitting added a comment -

        > I think that the would initially setup his namespaces to be mapped on a session basis to
        > whatever makes sense for the application and then use literals throughout the application.
        > [...]
        > With respect to the isNodeType() I would then expect it to fail without an exeception
        > specific to the unknown prefix

        The client should have received a NamespaceException already when trying to setup the "foo" prefix in this case, so I still think it's good form to throw an exception from isNodeType() when encountering an unknown prefix.

        > I guess from an application perspective I would even assume a getItem("/unknownprefix:bar")
        > to throw a PathNotFoundException.

        Without a preceding Session.setNamespacePrefix() call the repository has no way of knowing which namespace the client is referring to with "unknownprefix". There could well be a node "/

        {SomeNamespace}

        bar" that the client actually was trying to locate. If the method call allowed a full namespace, then I think a PathNotFoundException would be appropriate (much like I originally proposed in JCR-472 for invalid UUID strings), but since the repository can't tell what the client is really referring to, throwing a NamespaceException (or a more generic RepositoryException) is IMHO the right thing to do.

        > basically i think that a client that does not map its namespaces on a per session basis is broken.
        > From my perspective I would assume that once the namespaces are mapped, I would like to work
        > in my application code using "static/hardwired"-prefixes only. I think that this makes the code much
        > more readable.

        Agreed, and this actually avoids the whole problem here.

        Unfortunately the JSR 170 Session.setNamespacePrefix() is rather limited, making correct namespace remapping a rather complex process. Thus I believe that many applications simply assume a static set of namespace mappings and leave the details up to the administrator. JSR 283 is addressing this issue.

        Show
        Jukka Zitting added a comment - > I think that the would initially setup his namespaces to be mapped on a session basis to > whatever makes sense for the application and then use literals throughout the application. > [...] > With respect to the isNodeType() I would then expect it to fail without an exeception > specific to the unknown prefix The client should have received a NamespaceException already when trying to setup the "foo" prefix in this case, so I still think it's good form to throw an exception from isNodeType() when encountering an unknown prefix. > I guess from an application perspective I would even assume a getItem("/unknownprefix:bar") > to throw a PathNotFoundException. Without a preceding Session.setNamespacePrefix() call the repository has no way of knowing which namespace the client is referring to with "unknownprefix". There could well be a node "/ {SomeNamespace} bar" that the client actually was trying to locate. If the method call allowed a full namespace, then I think a PathNotFoundException would be appropriate (much like I originally proposed in JCR-472 for invalid UUID strings), but since the repository can't tell what the client is really referring to, throwing a NamespaceException (or a more generic RepositoryException) is IMHO the right thing to do. > basically i think that a client that does not map its namespaces on a per session basis is broken. > From my perspective I would assume that once the namespaces are mapped, I would like to work > in my application code using "static/hardwired"-prefixes only. I think that this makes the code much > more readable. Agreed, and this actually avoids the whole problem here. Unfortunately the JSR 170 Session.setNamespacePrefix() is rather limited, making correct namespace remapping a rather complex process. Thus I believe that many applications simply assume a static set of namespace mappings and leave the details up to the administrator. JSR 283 is addressing this issue.
        Hide
        David Nuescheler added a comment -

        I think that the would initially setup his namespaces to be mapped on a session basis to whatever makes sense for the application and then use literals throughout the application. basically i think that a client that does not map its namespaces on a per session basis is broken.
        From my perspective I would assume that once the namespaces are mapped, I would like to work in my application code
        using "static/hardwired"-prefixes only. I think that this makes the code much more readable.

        With respect to the isNodeType() I would then expect it to fail without an exeception specific to the unknown prefix
        much like a query operation that uses an unregistered nodetype or any other read operation for that matter.
        I guess from an application perspective I would even assume a getItem("/unknownprefix:bar") to throw a PathNotFoundException.
        I believe if the more explicit namespace exception was the intended by the spec, getItem() for example would explicitely throw
        a NamespaceException (or similar).

        Show
        David Nuescheler added a comment - I think that the would initially setup his namespaces to be mapped on a session basis to whatever makes sense for the application and then use literals throughout the application. basically i think that a client that does not map its namespaces on a per session basis is broken. From my perspective I would assume that once the namespaces are mapped, I would like to work in my application code using "static/hardwired"-prefixes only. I think that this makes the code much more readable. With respect to the isNodeType() I would then expect it to fail without an exeception specific to the unknown prefix much like a query operation that uses an unregistered nodetype or any other read operation for that matter. I guess from an application perspective I would even assume a getItem("/unknownprefix:bar") to throw a PathNotFoundException. I believe if the more explicit namespace exception was the intended by the spec, getItem() for example would explicitely throw a NamespaceException (or similar).
        Hide
        Tobias Bocanegra added a comment -

        you're right. that's why i wanted the QName and Path in the API

        i reverted the changes.

        Show
        Tobias Bocanegra added a comment - you're right. that's why i wanted the QName and Path in the API i reverted the changes.
        Hide
        Jukka Zitting added a comment -

        I disagree.

        Assume that in the context of the client application the "foo" prefix corresponds to the namespace "MyNamespace". Now, it could be that "MyNamespace" is actually mapped to the prefix "bar" in my repository for some local administrative reason. Then, a node with the node type "

        {MyNamespace}

        MyNodeType" would return false for node.isNodeType("foo:MyNodeType"), which would obviously be incorrect from the client perspective.

        If a client doesn't check the existence of the namespace with session.getNamespacePrefix("MyNamespace") or explicitly align the naming context with session.setNamespacePrefix("foo", "MyNamespace"), it implicitly assumes that the repository already contains both the namespace and the correct prefix mapping. If these assumptions are incorrect, throwing an exception is IMHO the best the repository can do.

        Show
        Jukka Zitting added a comment - I disagree. Assume that in the context of the client application the "foo" prefix corresponds to the namespace "MyNamespace". Now, it could be that "MyNamespace" is actually mapped to the prefix "bar" in my repository for some local administrative reason. Then, a node with the node type " {MyNamespace} MyNodeType" would return false for node.isNodeType("foo:MyNodeType"), which would obviously be incorrect from the client perspective. If a client doesn't check the existence of the namespace with session.getNamespacePrefix("MyNamespace") or explicitly align the naming context with session.setNamespacePrefix("foo", "MyNamespace"), it implicitly assumes that the repository already contains both the namespace and the correct prefix mapping. If these assumptions are incorrect, throwing an exception is IMHO the best the repository can do.
        Hide
        Tobias Bocanegra added a comment -

        Committed revision 478602.

        Show
        Tobias Bocanegra added a comment - Committed revision 478602.

          People

          • Assignee:
            Tobias Bocanegra
            Reporter:
            Tobias Bocanegra
          • Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development