Mailing-List: contact dev-help@jackrabbit.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@jackrabbit.apache.org
Message-ID: <652083148.1222204064335.JavaMail.jira@brutus>
Date: Tue, 23 Sep 2008 14:07:44 -0700 (PDT)
From: "Jukka Zitting (JIRA)" <jira@apache.org>
To: dev@jackrabbit.apache.org
Subject: [jira] Commented: (JCR-1328) Session.itemExists implementation
 wrong
In-Reply-To: <15439262.1200665793834.JavaMail.jira@brutus>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


    [ https://issues.apache.org/jira/browse/JCR-1328?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12633899#action_12633899 ] 

Jukka Zitting commented on JCR-1328:
------------------------------------

In spi-commons there's already a MalformedPathException class that extends NameException (and through it RepositoryException). Adding another exception with the same name would be confusing and removing the class from spi-commons would be a backwards compatibility issue. And because of the NameException superclass, we can't even play tricks by letting one similarly named exception extend the other.

So, can we come up with some other name for this exception? PathSyntaxException?

> Session.itemExists implementation wrong
> ---------------------------------------
>
>                 Key: JCR-1328
>                 URL: https://issues.apache.org/jira/browse/JCR-1328
>             Project: Jackrabbit
>          Issue Type: Improvement
>          Components: jackrabbit-core
>            Reporter: Felix Meschberger
>            Priority: Minor
>         Attachments: JCR-1328.patch
>
>
> IMHO the implementation of the Session.itemExists(String) method is wrong when called with a malformed path such as "/a/b/c/*" (note the trailing star). According to the spec, the method must return "false" for a malformed path like this.
> In reality, the method throws a RepositoryException which is allowed to be thrown by the spec "if an error occurrs" (whatever that means). But catching this exception means, we cannot handle it: Is it a connection issue or a general repository problem ? If so, I cannot do anything about it. It is really a path problem, I can do something about it. But how do I know (without rebuilding internals) ?
> See also SLING-152 for  more info.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.