[
https://issues.apache.org/jira/browse/JCR-3163?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tobias Bocanegra reassigned JCR-3163:
-
Assignee: angela
> NPE in RepositoryServiceImpl.getPropertyInfo()
> ---
[
https://issues.apache.org/jira/browse/JCR-3163?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13160374#comment-13160374
]
Tobias Bocanegra commented on JCR-3163:
---
committed fix as mentioned above in revision
NPE in RepositoryServiceImpl.getPropertyInfo()
--
Key: JCR-3163
URL: https://issues.apache.org/jira/browse/JCR-3163
Project: Jackrabbit Content Repository
Issue Type: Bug
Components: jack
Hi,
On Wed, Nov 30, 2011 at 3:21 PM, Michael Dürig wrote:
> 1) Does visible mean immediately visible on next access or visible after
> refresh? The second case would work with snapshot isolation.
That's up the implementation.
Section 10.11.1 of JSR 283 [1] explicitly allows changes to become
vi
[
https://issues.apache.org/jira/browse/JCR-2906?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alex Parvulescu updated JCR-2906:
-
Attachment: JCR-2906-v5.patch
yes, as usual you are right!
your solution is a lot clearer, and abov
Hi,
I'm happy to announce that a some weeks ago the Jackrabbit PMC invited
Bart van der Schans and Justin Edelson to become new Jackrabbit
committers and PMC members based on their contributions. Both accepted
the invitation and I've finally now taken care of the last bits of
associated bureaucrac
On 30.11.11 17:13, Stefan Guggisberg wrote:
Good catch! Two points:
1) Does visible mean immediately visible on next access or visible after
refresh? The second case would work with snapshot isolation.
2) Event though I'd like it to be different, spec. compliance hasn't been a
top priority on
[
https://issues.apache.org/jira/browse/JCR-2906?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13160162#comment-13160162
]
Michael Dürig commented on JCR-2906:
Looks better but ;-)... in the // after case I thin
On Wed, Nov 30, 2011 at 3:21 PM, Michael Dürig wrote:
>
>
> On 30.11.11 13:57, Alexander Klimetschek wrote:
>>
>> I expect there is a lot of code outside that relies on the copy-on-write
>> nature of JR 2 - i.e. that anything the session did not touch yet is
>> always "live". Introducing snapshot
Hi,
>>2) Event though I'd like it to be different, spec. compliance hasn't
>> been a top priority on this project so far.
>
>Autsch ! You are going to implement a spec, so compliance is IMHO one of
>the goals and as such is one of the top priorities IMHO .. Even more so
>than performance !
It dep
[
https://issues.apache.org/jira/browse/JCR-3162?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alex Parvulescu updated JCR-3162:
-
Attachment: JCR-3162.patch
attaching patch.
Warning: this is a work in progress, not really tested
[
https://issues.apache.org/jira/browse/JCR-3162?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13160113#comment-13160113
]
Alex Parvulescu commented on JCR-3162:
--
Studying this problem revealed that this issue
Index update overhead on cluster slave due to JCR-905
-
Key: JCR-3162
URL: https://issues.apache.org/jira/browse/JCR-3162
Project: Jackrabbit Content Repository
Issue Type: Improvement
Hi,
Am 30.11.2011 um 15:21 schrieb Michael Dürig:
>
>
> On 30.11.11 13:57, Alexander Klimetschek wrote:
>> I expect there is a lot of code outside that relies on the copy-on-write
>> nature of JR 2 - i.e. that anything the session did not touch yet is
>> always "live". Introducing snapshot isol
Hi,
Am 30.11.2011 um 15:21 schrieb Michael Dürig:
> 2) Event though I'd like it to be different, spec. compliance hasn't
> been a top priority on this project so far.
Autsch ! You are going to implement a spec, so compliance is IMHO one of the
goals and as such is one of the top priorities IMH
[
https://issues.apache.org/jira/browse/JCR-2906?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alex Parvulescu updated JCR-2906:
-
Attachment: JCR-2906-v4.patch
you are right. the sneaky offset tricked me.
turns out that wasn't t
Hi,
at some point we need to answer the questions below:
1) How many diff formats do we want inside Jackrabbit? What can we do to
converge on a single one?
2) Should the diff format we use be applicable to things outside the
Jackrabbit world, that is manipulating pure JSON?
Regarding 1) -
On 30.11.2011 15:40, Thomas Mueller wrote:
Hi,
I happen to disagree with that, and the initial work that has been done
seems to agree with me.
I see.
For the record: I'd be totally ok with minting a set of new names,
"JSOP" for me is to close to "JSON-P" with which we certainly do not
want
Hi,
>I happen to disagree with that, and the initial work that has been done
>seems to agree with me.
I see.
>For the record: I'd be totally ok with minting a set of new names,
>"JSOP" for me is to close to "JSON-P" with which we certainly do not
>want to be confused.
In my view, JSOP stands fo
On 30.11.11 13:57, Alexander Klimetschek wrote:
I expect there is a lot of code outside that relies on the copy-on-write
nature of JR 2 - i.e. that anything the session did not touch yet is
always "live". Introducing snapshot isolation (which would be
copy-on-read IIUC) would break those cases
On 2011-11-30 15:02, Thomas Mueller wrote:
Hi,
JSON is a format. It would confuse people if JSOP is a protocol and not a
format.
I happen to disagree with that, and the initial work that has been done
seems to agree with me.
For the record: I'd be totally ok with minting a set of new names,
Hi,
JSON is a format. It would confuse people if JSOP is a protocol and not a
format.
Regards,
Thomas
On 11/30/11 2:55 PM, "julian.resc...@gmx.de" wrote:
>On 2011-11-30 14:46, Thomas Mueller wrote:
>> Hi,
>>
>>> Are we defining a protocol or an API?
>>
>> A format: the JSOP format. For me th
On 30.11.11 14:27, "Felix Meschberger"
mailto:fmesc...@adobe.com>> wrote:
Am 30.11.2011 um 14:20 schrieb Michael Dürig:
That's a different story for a different thread ;-) In a nutshell: under
snapshot isolation sessions will see ADD events for items which do not
exist for them. OTHO when they get
On 2011-11-30 14:46, Thomas Mueller wrote:
Hi,
Are we defining a protocol or an API?
A format: the JSOP format. For me that's the most important item. I don't
OK, we need to agree on terminology.
The diff format is just one building block for "JSOP".
...
Best regards, Julian
Hi,
>Are we defining a protocol or an API?
A format: the JSOP format. For me that's the most important item. I don't
care too much about the protocol part - actually it doesn't need to be
standardized in my view (the HTTP protocol is sufficient). And the
MicroKernel API doesn't need to be standar
On 30.11.11 13:27, Felix Meschberger wrote:
That's a different story for a different thread ;-) In a nutshell: under
snapshot isolation sessions will see ADD events for items which do not
exist for them. OTHO when they get an DELETE event the item will still
exist for them. Note how this is rev
On 30.11.2011 14:20, Thomas Mueller wrote:
Hi,
If the task is "define a patch format for use over HTTP Patch", then
yes, we can assume HTTP is there.
Yes. But for Jackrabbit 3, we want to define an API that doesn't require
HTTP (or ZIP). Currently it's a Java API, but we might extend it to ot
Hi,
Am 30.11.2011 um 14:20 schrieb Michael Dürig:
>
> On 30.11.11 13:07, Felix Meschberger wrote:
>> Say, s1 listens on changes to node x, s2 updates node x and on receiving the
>> event s1 would access the new property. What happens ?
>
> That's a different story for a different thread ;-) In
On 30.11.11 13:07, Felix Meschberger wrote:
Hi,
Oops, sorry, Tom just hinted at my misreading of the calculation. Of course
session3 is expected to have -1 (the op is + not -).
The problem here is for session2 really. What could session2 possibly do ?
The repository implementation could che
Hi,
>If the task is "define a patch format for use over HTTP Patch", then
>yes, we can assume HTTP is there.
Yes. But for Jackrabbit 3, we want to define an API that doesn't require
HTTP (or ZIP). Currently it's a Java API, but we might extend it to other
programming languages such a PHP, C#, and
Hi,
Oops, sorry, Tom just hinted at my misreading of the calculation. Of course
session3 is expected to have -1 (the op is + not -).
The problem here is for session2 really. What could session2 possibly do ? to a
refresh before calculating ? Are we postulating short-lived sessions ? What
about
[
https://issues.apache.org/jira/browse/JCR-2887?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
angela resolved JCR-2887.
-
Resolution: Fixed
Fix Version/s: (was: 2.4)
2.3.5
resolving this issue fixed. the for
This kind of scares me a bit: What could session3 possibly do about this here ?
It looks like session3 is created after everything is set and done, thus it is
expected that p1==p2==-1 and thus p1-p2==0.
session3 can't do anything about it, session 2 could. See [1]. This is a
consequence in
Hi,
This kind of scares me a bit: What could session3 possibly do about this here ?
It looks like session3 is created after everything is set and done, thus it is
expected that p1==p2==-1 and thus p1-p2==0.
Regards
Felix
Am 30.11.2011 um 13:38 schrieb Michael Dürig:
>
> Hi,
>
> As documente
[
https://issues.apache.org/jira/browse/JCR-3159?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alex Parvulescu updated JCR-3159:
-
Component/s: (was: JCR 2.0)
(was: jackrabbit-core)
q
We still suffer from an agreed-upon set of design goals and constraints.
Ack. That's probably why we have several incompatible ad-hoc
implementation.
If we want to *standardize* something, we need to abstract away things
specific to JCR. Also, we need either to get the features we need into
[
https://issues.apache.org/jira/browse/JCR-3161?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
angela updated JCR-3161:
Fix Version/s: (was: 2.4)
2.3.5
> Add JcrUtils.getPropertyTypeNames
> ---
[
https://issues.apache.org/jira/browse/JCR-3161?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
angela resolved JCR-3161.
-
Resolution: Fixed
> Add JcrUtils.getPropertyTypeNames
> --
>
>
Add JcrUtils.getPropertyTypeNames
--
Key: JCR-3161
URL: https://issues.apache.org/jira/browse/JCR-3161
Project: Jackrabbit Content Repository
Issue Type: Improvement
Components: jackrabbit-jcr-commo
Hi,
As documented earlier [1] new Mircokernel based JCR implementations will
most likely introduce snapshot isolation for sessions. While I think
this is a good thing in general, it also introduces potentially
troublesome write skew: application level constraints might hold locally
(i.e. per
On 30.11.2011 13:19, Thomas Mueller wrote:
Hi,
I agree that this might be useful, but a simpler approach is to use
HTTP's If-Match header. Of course that requires having a sane strategy
to compute ETags.
You are mixing the binding (HTTP) with the format (JSOP).
You can't assume HTTP is used.
Hi,
>I agree that this might be useful, but a simpler approach is to use
>HTTP's If-Match header. Of course that requires having a sane strategy
>to compute ETags.
You are mixing the binding (HTTP) with the format (JSOP).
You can't assume HTTP is used.
Regards,
Thomas
The Apache Jenkins build system has built Jackrabbit-trunk (build #1761)
Status: Fixed
Check console output at https://builds.apache.org/job/Jackrabbit-trunk/1761/ to
view the results.
On 30.11.2011 09:44, Thomas Mueller wrote:
Hi,
Another proposed addition is a 'test' line:
= "/swiss/lx 38/availableSeats": 100
^ "/swiss/lx 38/availableSeats": 99
The meaning of the 'test' line (the one starting with '=') is: before
applying the rest of patch, the value is verified. If it doe
hi
any missing ac related mixins are in fact added automatically
when using AccessControllManager#setPolicy. however, the import
of protected items is not triggered if the session importer
does not recognize the protected nature of the item to be imported.
this is determined by the effective node
Hi,
>Container format: something that wraps multiple single diffs into one
>file. Such as ZIP, multipart/*, or a JSON document that contains an
>array of diffs (something we could do easily if the diff format was JSON).
If you want to call it "container" or not is up to you.
The "@" notation is
On 2011-11-30 07:54, Thomas Mueller wrote:
Hi,
Why do we need multiple commits in one block?
As I have already written, we need to get the information about multiple
commits in one block for the method getJournal. See my previous mail.
Wouldn't it make more sense to either pipeline the req
Hi,
Another proposed addition is a 'test' line:
= "/swiss/lx 38/availableSeats": 100
^ "/swiss/lx 38/availableSeats": 99
The meaning of the 'test' line (the one starting with '=') is: before
applying the rest of patch, the value is verified. If it does not match,
then the subsequent line(s) will
48 matches
Mail list logo
