[
https://issues.apache.org/jira/browse/OAK-65?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Dürig resolved OAK-65.
--
Resolution: Fixed
Fix Version/s: 0.3
Resolving as fixed. The API restructuring (ContentSession et. a
[
https://issues.apache.org/jira/browse/OAK-15?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Dürig resolved OAK-15.
--
Resolution: Fixed
Fix Version/s: 0.3
I resolve this as fixed since the main issues are addressed by
[
https://issues.apache.org/jira/browse/OAK-84?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13267866#comment-13267866
]
Michael Dürig commented on OAK-84:
--
bq. Item.getDepth() is already implemented in the Abstrac
[
https://issues.apache.org/jira/browse/OAK-84?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13267749#comment-13267749
]
Michael Dürig commented on OAK-84:
--
bq. Why can't ItemImpl just keep a reference to the relat
[
https://issues.apache.org/jira/browse/OAK-84?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jukka Zitting updated OAK-84:
-
Attachment: 0001-OAK-84-Delegates-for-Session-Node-Property-and-Item.patch
Re: revision 1333500.
Item.getDep
[
https://issues.apache.org/jira/browse/OAK-84?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13267629#comment-13267629
]
Jukka Zitting commented on OAK-84:
--
Why can't ItemImpl just keep a reference to the related S
[
https://issues.apache.org/jira/browse/OAK-84?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13267626#comment-13267626
]
Julian Reschke commented on OAK-84:
---
But there is no other way to find out whether two sessi
[
https://issues.apache.org/jira/browse/OAK-84?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13267600#comment-13267600
]
Michael Dürig commented on OAK-84:
--
Ah... in contrast, Item.getSession() says "Return the Ses
[
https://issues.apache.org/jira/browse/OAK-84?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13267582#comment-13267582
]
Julian Reschke commented on OAK-84:
---
The prose in the spec doesn't seem to say. Item.getSess
[
https://issues.apache.org/jira/browse/OAK-6?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13267572#comment-13267572
]
Julian Reschke commented on OAK-6:
--
TCK status 2012-05-03: Tests: 1905, Errors: 227, Failures:
[
https://issues.apache.org/jira/browse/OAK-84?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13267571#comment-13267571
]
Michael Dürig commented on OAK-84:
--
While working on this for Session, I came across
{code}
[
https://issues.apache.org/jira/browse/OAK-84?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Dürig updated OAK-84:
-
Component/s: (was: it)
jcr
> Delegates for Session, Node, Property and Item
> --
[
https://issues.apache.org/jira/browse/OAK-56?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13267523#comment-13267523
]
Jukka Zitting commented on OAK-56:
--
bq. Your (new) deleteRecursive implementation doesn't det
[
https://issues.apache.org/jira/browse/OAK-56?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13267516#comment-13267516
]
Thomas Mueller commented on OAK-56:
---
> I'm fine with leaving the code in svn for now if ther
[
https://issues.apache.org/jira/browse/OAK-56?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13267514#comment-13267514
]
Thomas Mueller commented on OAK-56:
---
Your (new) deleteRecursive implementation doesn't detec
[
https://issues.apache.org/jira/browse/OAK-56?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13267504#comment-13267504
]
Jukka Zitting commented on OAK-56:
--
I moved the code to oak-mk in revision 1333504 and replac
Michael Dürig created OAK-84:
Summary: Delegates for Session, Node, Property and Item
Key: OAK-84
URL: https://issues.apache.org/jira/browse/OAK-84
Project: Jackrabbit Oak
Issue Type: Improvement
[
https://issues.apache.org/jira/browse/OAK-75?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13267487#comment-13267487
]
Thomas Mueller commented on OAK-75:
---
> my intention was to specify the 'path' filter on getJ
[
https://issues.apache.org/jira/browse/OAK-83?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stefan Guggisberg reassigned OAK-83:
Assignee: Stefan Guggisberg
> Copy operation would recurse indefinitely if memory permitted
[
https://issues.apache.org/jira/browse/OAK-75?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13267469#comment-13267469
]
Stefan Guggisberg commented on OAK-75:
--
> For the one getNodes method, the path is a para
[
https://issues.apache.org/jira/browse/OAK-79?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13267468#comment-13267468
]
Michael Dürig commented on OAK-79:
--
Thanks works now. However, now I run into OAK-83.
Michael Dürig created OAK-83:
Summary: Copy operation would recurse indefinitely if memory
permitted
Key: OAK-83
URL: https://issues.apache.org/jira/browse/OAK-83
Project: Jackrabbit Oak
Issue T
On 3.5.12 13:43, Julian Reschke wrote:
On 2012-05-03 14:26, Thomas Mueller wrote:
Hi,
I wouldn't want to catch RuntimeException. I'd prefer if oak-core would
only throw OakException (extends RuntimeException), as suggested by
Michael Dürig.
+1
I also think it would be good if these Oak e
[
https://issues.apache.org/jira/browse/OAK-79?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stefan Guggisberg resolved OAK-79.
--
Resolution: Fixed
Fix Version/s: 0.3
fixed in svn r1333455
> Copy operation
Hi,
>>Not sure what you mean with re-wrap actually...
>
>Throw a RepositoryException that wraps whatever was sent from below.
OK... I guess this should work:
RepositoryException x = ...
x.setStackTrace(this.getStackTrace()).
return x;
Regards,
Thomas
On 3.5.12 13:43, Julian Reschke wrote:
On 2012-05-03 14:26, Thomas Mueller wrote:
Hi,
I wouldn't want to catch RuntimeException. I'd prefer if oak-core would
only throw OakException (extends RuntimeException), as suggested by
Michael Dürig.
+1
I also think it would be good if these Oak e
On 2012-05-03 14:54, Thomas Mueller wrote:
Hi,
If the OakException wraps a RepositoryException, we extract that one and
rethrow it, it will come with an incorrect stack trace, no?
You mean, if we use "throw ((OakException) e).getOriginalException()" or
something similar when unwrapping?
Yes
Hi,
>If the OakException wraps a RepositoryException, we extract that one and
>rethrow it, it will come with an incorrect stack trace, no?
You mean, if we use "throw ((OakException) e).getOriginalException()" or
something similar when unwrapping?
> So it seems
>we need to re-wrap.
Not sure wha
On 3.5.12 13:05, Thomas Mueller wrote:
Hi,
+1
I also used the check-release.sh script, there were a few minor issues:
- gpg: BAD (but md5 and sha were GOOD)
That's most probably because you don't have Alex' public key in your
local system.
- the script created two directories: "-v" and
On 2012-05-03 14:26, Thomas Mueller wrote:
Hi,
I wouldn't want to catch RuntimeException. I'd prefer if oak-core would
only throw OakException (extends RuntimeException), as suggested by
Michael Dürig.
+1
I also think it would be good if these Oak exceptions could carry
sufficient informati
Hi,
>I wouldn't want to catch RuntimeException. I'd prefer if oak-core would
>only throw OakException (extends RuntimeException), as suggested by
>Michael Dürig.
+1
>I also think it would be good if these Oak exceptions could carry
>sufficient information to generate a JCR exception.
+1
>The m
On Wed, May 2, 2012 at 5:26 PM, Jukka Zitting wrote:
> Hi,
>
> [new thread, since this is a broader issue than OAK-80]
>
> On Wed, May 2, 2012 at 4:50 PM, Thomas Mueller (JIRA) wrote:
>> The question is how would you build an an efficient oak-core remoting, if
>> every
>> Node.setProperty requir
Hi,
>>let's assume CoreValue.getString() could throw a
>> RepositoryException (when there is an error converting the value to a
>> string). If we do that, then we would have to add exception handling to
>>a
>
>That examples seems a bit academic right now, as CoreValue.getString()
>indeed never thr
On 2012-04-27 15:17, Jukka Zitting wrote:
Hi,
Instead of discussing this in the abstract, how about we look at a few
concrete cases to see how those would be best handled?
For example here's what the JCR spec says that the Session.save()
method [1] can throw:
AccessDeniedException - if any of
Hi,
+1
I also used the check-release.sh script, there were a few minor issues:
- gpg: BAD (but md5 and sha were GOOD)
- the script created two directories: "-v" and "-p"
- svn: URL
'http://svn.apache.org/repos/asf/jackrabbit/oak/tags/jackrabbit-oak-0.2.1'
doesn't exist
(there are 0.2.1/ and j
On 2012-04-27 12:29, Thomas Mueller wrote:
Hi,
my preference was to just throw the jcr-exceptions where
ever this was appropriate and unambiguous. for example
namespaceexception, versionexception, constraintviolation...
I can't comment on NamespaceException, VersionException, and so on.
What
[
https://issues.apache.org/jira/browse/OAK-22?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13267375#comment-13267375
]
Julian Reschke commented on OAK-22:
---
This is work in progress; lots of changes have already
This time
+1
Checked using
$ sh check-release.sh alexparvulescu 0.2.1
05e7c8c71769aec9f326f4a377fd6e41fbb735a6
~$ uname -a
Darwin susi.local 11.3.0 Darwin Kernel Version 11.3.0: Thu Jan 12
18:47:41 PST 2012; root:xnu-1699.24.23~1/RELEASE_X86_64 x86_64
~$ java -version
java version "1.6.0_
[
https://issues.apache.org/jira/browse/OAK-56?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13267342#comment-13267342
]
Thomas Mueller commented on OAK-56:
---
> What's the point in keep unused code in the project w
[
https://issues.apache.org/jira/browse/OAK-56?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13267340#comment-13267340
]
Julian Reschke commented on OAK-56:
---
> Julian, what's the point to remove it now if it will
[
https://issues.apache.org/jira/browse/OAK-56?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13267341#comment-13267341
]
Thomas Mueller commented on OAK-56:
---
> I don't see a need for this in the MicroKernel implem
ok, I'm on it :)
Thanks Jukka, good point about the release plugin.
Release vote will follow shortly.
alex
On Thu, May 3, 2012 at 11:37 AM, Jukka Zitting wrote:
> Hi,
>
> On Thu, May 3, 2012 at 11:32 AM, Alex Parvulescu
> wrote:
> > The simplest way is to also include OAK-82 (this morning's c
[
https://issues.apache.org/jira/browse/OAK-56?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13267334#comment-13267334
]
Dominique Pfister commented on OAK-56:
--
> commons and rename the package to o.a.j.commons
Hi,
On Thu, May 3, 2012 at 11:32 AM, Alex Parvulescu
wrote:
> The simplest way is to also include OAK-82 (this morning's commit) so we
> have a clean trunk for 0.2.1.
Sounds good.
> What should the release notes say about the licencing issue?
Something like "The earlier 0.2 release candidate w
[
https://issues.apache.org/jira/browse/OAK-56?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13267331#comment-13267331
]
Dominique Pfister commented on OAK-56:
--
> On a related note, what's the status of the rel
ah, forgot. I also have to rollback the version from 0.3-SNAPSHOT to
0.2.1-SNAPSHOT that also includes the changes.
alex
On Thu, May 3, 2012 at 11:32 AM, Alex Parvulescu
wrote:
> Hi,
>
> > I'd actually prefer to retry the release
> Cool, we can do that.
>
> The simplest way is to also include
Hi,
> I'd actually prefer to retry the release
Cool, we can do that.
The simplest way is to also include OAK-82 (this morning's commit) so we
have a clean trunk for 0.2.1.
What should the release notes say about the licencing issue?
alex
On Thu, May 3, 2012 at 10:42 AM, Michael Dürig wrote
[
https://issues.apache.org/jira/browse/OAK-56?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13267329#comment-13267329
]
Thomas Mueller commented on OAK-56:
---
Julian, what's the point to remove it now if it will be
[
https://issues.apache.org/jira/browse/OAK-56?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13267328#comment-13267328
]
Michael Dürig commented on OAK-56:
--
bq. If it's not needed right now, it (IMHO) shouldn't be
[
https://issues.apache.org/jira/browse/OAK-56?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13267327#comment-13267327
]
Julian Reschke commented on OAK-56:
---
If it's not needed right now, it (IMHO) shouldn't be in
[
https://issues.apache.org/jira/browse/OAK-56?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13267323#comment-13267323
]
Thomas Mueller commented on OAK-56:
---
Is there a particular reason why it needs to be removed
On 3.5.12 9:08, Alex Parvulescu wrote:
So we can consider the vote has failed due to the licencing issue.
Yes.
I see that we already have one commit on the trunk, so in order to minimize
the noise maybe cutting 0.3 at the end of may is a better option?
If it is only about the noise I do
Hi,
On Thu, May 3, 2012 at 9:42 AM, Thomas Mueller wrote:
> Yes, that was a mistake. I wrote those two classes originally, so I can
> relicense them. I have done that in revision 134.
Perfect, thanks!
PS. Thanks also to Michael for updating the rat exclusion settings.
BR,
Jukka Zitting
Hi,
On Thu, May 3, 2012 at 10:08 AM, Alex Parvulescu
wrote:
> So we can consider the vote has failed due to the licencing issue.
Yes.
> I see that we already have one commit on the trunk, so in order to minimize
> the noise maybe cutting 0.3 at the end of may is a better option?
Fine by me.
B
Hi,
So we can consider the vote has failed due to the licencing issue.
I see that we already have one commit on the trunk, so in order to minimize
the noise maybe cutting 0.3 at the end of may is a better option?
alex
On Thu, May 3, 2012 at 9:42 AM, Thomas Mueller wrote:
> Hi,
>
> >The troub
[
https://issues.apache.org/jira/browse/OAK-82?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dominique Pfister resolved OAK-82.
--
Resolution: Fixed
Fixed in revision 139.
> Running MicroKernelIT test with the
Dominique Pfister created OAK-82:
Summary: Running MicroKernelIT test with the InMem persistence
creates a lot of GC threads
Key: OAK-82
URL: https://issues.apache.org/jira/browse/OAK-82
Project: Jack
Hi,
>The troublesome files come with the following header:
>
>/*
> * Copyright 2004-2011 H2 Group. Multiple-Licensed under the H2 License,
> * Version 1.0, and under the Eclipse Public License, Version 1.0
> * (http://h2database.com/html/license.html).
> * Initial Developer: H2 Group
> */
>
>I sup
58 matches
Mail list logo
