Hi,
On Wed, Oct 2, 2013 at 11:13 AM, Julian Reschke wrote:
> On 2013-10-02 16:29, Jukka Zitting wrote:
>> Only if you're already prepared to deal with such changes. If you're
>> not, I think it'll be clearer to fail fast (with a good enough
>> explanation in the exception message) than to silentl
The Buildbot has detected a new failure on builder oak-trunk while building ASF
Buildbot.
Full details are available at:
http://ci.apache.org/builders/oak-trunk/builds/3374
Buildbot URL: http://ci.apache.org/
Buildslave for this Build: osiris_ubuntu
Build Reason: scheduler
Build Source Stamp:
On 2013-10-02 16:32, Jukka Zitting wrote:
Hi,
On Wed, Oct 2, 2013 at 10:19 AM, Julian Reschke wrote:
Like this:
https://issues.apache.org/jira/secure/attachment/12606362/JCR-3675.diff
+1 looks good.
BTW, I'm not a fan of the '+ " Call chain: "' pattern in exception
messages. The logging con
[
https://issues.apache.org/jira/browse/JCR-3675?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Julian Reschke updated JCR-3675:
Attachment: (was: JCR-3675.diff)
> test cases for "similarly" named nodes
> -
[
https://issues.apache.org/jira/browse/JCR-3675?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Julian Reschke updated JCR-3675:
Attachment: JCR-3675.diff
> test cases for "similarly" named nodes
>
On 2013-10-02 16:29, Jukka Zitting wrote:
Hi,
On Tue, Oct 1, 2013 at 10:31 AM, Julian Reschke wrote:
Well, the call could either fail (in which case the client would have a hard
time to figure out how to proceed), or it can pass (and the returned node
would "know" its name).
I think I'd pref
Hi,
On Wed, Oct 2, 2013 at 10:19 AM, Julian Reschke wrote:
> Like this:
> https://issues.apache.org/jira/secure/attachment/12606362/JCR-3675.diff
+1 looks good.
BTW, I'm not a fan of the '+ " Call chain: "' pattern in exception
messages. The logging configuration should take care of how (and if
Hi,
On Tue, Oct 1, 2013 at 10:31 AM, Julian Reschke wrote:
> Well, the call could either fail (in which case the client would have a hard
> time to figure out how to proceed), or it can pass (and the returned node
> would "know" its name).
>
> I think I'd prefer the latter.
Only if you're alrea
[
https://issues.apache.org/jira/browse/JCR-3675?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Julian Reschke updated JCR-3675:
Attachment: JCR-3675.diff
Updated patch, now containing NodeNameNormalizer for better visibility of
On 2013-10-02 12:41, Julian Reschke wrote:
On 2013-10-01 16:31, Julian Reschke wrote:
Well, the call could either fail (in which case the client would have a
hard time to figure out how to proceed), or it can pass (and the
returned node would "know" its name).
I think I'd prefer the latter.
Q
On 2013-10-01 16:31, Julian Reschke wrote:
Well, the call could either fail (in which case the client would have a
hard time to figure out how to proceed), or it can pass (and the
returned node would "know" its name).
I think I'd prefer the latter.
Questions:
1) Is this something the spec nee
[
https://issues.apache.org/jira/browse/JCR-3676?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13783727#comment-13783727
]
Ard Schrijvers commented on JCR-3676:
-
ps commit checked in on 'CR-3676' instead of "JCR
12 matches
Mail list logo