[
https://issues.apache.org/jira/browse/JCR-4460?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16892577#comment-16892577
]
Felix Meschberger commented on JCR-4460:
You might want to look how it is b
[
https://issues.apache.org/jira/browse/JCR-4460?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16892531#comment-16892531
]
Felix Meschberger commented on JCR-4460:
{quote}There probably was a good re
Hi
This looks great.
As for configuration: What is the reason for having a configuration option ?
Not being able to decide ? Or real customer need for having it configurable ?
I think we should start with reasonble heuristics first and consider
configuration options in case there is a need/des
[
https://issues.apache.org/jira/browse/JCR-4060?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15747768#comment-15747768
]
Felix Meschberger commented on JCR-4060:
ACK.
> unintended export versions
[
https://issues.apache.org/jira/browse/JCR-4060?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15747595#comment-15747595
]
Felix Meschberger commented on JCR-4060:
I think the most sensible thing t
[
https://issues.apache.org/jira/browse/JCR-3870?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14487313#comment-14487313
]
Felix Meschberger commented on JCR-3870:
This is actually not an edge case and
[
https://issues.apache.org/jira/browse/JCR-3870?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14485513#comment-14485513
]
Felix Meschberger commented on JCR-3870:
bq. there are many other places, w
[
https://issues.apache.org/jira/browse/JCR-3870?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14484909#comment-14484909
]
Felix Meschberger edited comment on JCR-3870 at 4/8/15 7:5
[
https://issues.apache.org/jira/browse/JCR-3870?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14484909#comment-14484909
]
Felix Meschberger commented on JCR-3870:
I don't think it is worth exporti
[
https://issues.apache.org/jira/browse/JCR-3802?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14090775#comment-14090775
]
Felix Meschberger commented on JCR-3802:
Sounds good to me.
The API patch def
[
https://issues.apache.org/jira/browse/JCR-3745?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13933197#comment-13933197
]
Felix Meschberger commented on JCR-3745:
bq. Class yes, final why?
What'
[
https://issues.apache.org/jira/browse/JCR-3745?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13933167#comment-13933167
]
Felix Meschberger commented on JCR-3745:
[~rombert] I think we can just keep
[
https://issues.apache.org/jira/browse/JCR-3745?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13933083#comment-13933083
]
Felix Meschberger commented on JCR-3745:
I like the filter idea, but I think i
Am 17.01.2014 um 11:01 schrieb Bertrand Delacretaz :
> On Wed, Jan 15, 2014 at 7:35 PM, Jukka Zitting
> wrote:
>> g) ...Or as a last resort, abandon the idea of a joint deployment
>> package. Jackrabbit Classic and Oak would be shipped in separate
>> deployment artifacts
>
> Does this have
Hi
While (f-OSGi) has an appeal to me and think should be done in any case, I
would think (g-separate) is the right way to go to prevent complexity with
IMVHO little benefit.
Just my CHF 0.05
Regards
Felix
Am 15.01.2014 um 12:35 schrieb Jukka Zitting :
> Hi,
>
> Let's pick this up again!
>
[
https://issues.apache.org/jira/browse/JCR-3705?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13837643#comment-13837643
]
Felix Meschberger commented on JCR-3705:
+1 for a new jackrabbit-data compo
[
https://issues.apache.org/jira/browse/JCR-3293?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13815935#comment-13815935
]
Felix Meschberger commented on JCR-3293:
Codewise, something like this, I t
[
https://issues.apache.org/jira/browse/JCRVLT-18?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13800429#comment-13800429
]
Felix Meschberger commented on JCRVLT-18:
-
[~tmueller] I think for pac
Hi
Am 24.06.2013 um 23:40 schrieb Tobias Bocanegra:
>> I was wondering what the status for this is?
>
> being buried in day-to-day work the last months, I just now completed
> the preparation for the contribution. I need one or 2 more days to
> find the best way for contributing (e.g. big patch
[
https://issues.apache.org/jira/browse/JCR-3534?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13641519#comment-13641519
]
Felix Meschberger commented on JCR-3534:
> Well, this message is an acces
[
https://issues.apache.org/jira/browse/JCR-3534?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13641019#comment-13641019
]
Felix Meschberger commented on JCR-3534:
> To simplify development/suppo
[
https://issues.apache.org/jira/browse/JCR-3534?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13634974#comment-13634974
]
Felix Meschberger commented on JCR-3534:
> createValue(Binary)
If we have a
[
https://issues.apache.org/jira/browse/JCR-3534?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13634905#comment-13634905
]
Felix Meschberger commented on JCR-3534:
Re. ValueFactory#createValue(St
[
https://issues.apache.org/jira/browse/JCR-3534?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13634889#comment-13634889
]
Felix Meschberger commented on JCR-3534:
Re. signed "message" or HMAC
[
https://issues.apache.org/jira/browse/JCR-3534?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13605083#comment-13605083
]
Felix Meschberger commented on JCR-3534:
> but is the overhead high en
[
https://issues.apache.org/jira/browse/JCR-3534?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13605061#comment-13605061
]
Felix Meschberger commented on JCR-3534:
> suggested getValueByContentId()
[
https://issues.apache.org/jira/browse/JCR-3534?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13604991#comment-13604991
]
Felix Meschberger commented on JCR-3534:
This does not solve my problems at al
[
https://issues.apache.org/jira/browse/JCR-3534?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Felix Meschberger updated JCR-3534:
---
Component/s: jackrabbit-core
jackrabbit-api
Affects Version/s
Hi
I created https://issues.apache.org/jira/browse/JCR-3534 with a patch
implementing the proposed method along with a unit test validating round
tripping.
Regards
Felix
Am 12.03.2013 um 12:32 schrieb Felix Meschberger:
> Hi all
>
> we have a couple of use cases, where we woul
[
https://issues.apache.org/jira/browse/JCR-3534?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Felix Meschberger updated JCR-3534:
---
Attachment: JCR-3534.patch
Proposed patch adding the new API.
To access the DataStore item by
Felix Meschberger created JCR-3534:
--
Summary: Add JackrabbitSession.getValueByContentId method
Key: JCR-3534
URL: https://issues.apache.org/jira/browse/JCR-3534
Project: Jackrabbit Content Repository
Hi,
Am 12.03.2013 um 15:02 schrieb Alexander Klimetschek:
> On 12.03.2013, at 12:32, Felix Meschberger wrote:
>
>> Thus the proposed JackrabbitSession.getValueByContentIdentity(String) method
>> would allow for round tripping the JackrabbitValue.getContentIdentity()
>>
> sessions or so.
>
> Another risk is that an attacker that has a list of identifiers might be
> able to get the documents in that way, if they are stored in the
> repository. The question is how did the attacker get the identifier, but
> if it's a simple SHA-1 it might be
nting superfluous binary data copying and moving.
Questions:
(a) Would such a method technically be possible (preventing actual large binary
data copy !) ?
(b) Would a patch be accepted ?
(c) Can we and if yes, how can we control access ?
(c) What else ?
Regards
Felix
--
Felix Meschberger | Prin
s contributions. I'm happy to
> announce that he accepted the offer and that all the related
> administrative work has now been taken care of.
>
> Welcome to the team, Cédric!
>
> Michael
>
--
Felix Meschberger | Principal Scientist | Adobe
ip based on his contributions. I'm happy to
> announce that he accepted the offer and that all the related
> administrative work has now been taken care of.
>
> Welcome to the team, Tommaso!
>
> Michael
>
--
Felix Meschberger | Principal Scientist | Adobe
[
https://issues.apache.org/jira/browse/JCR-3489?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13536861#comment-13536861
]
Felix Meschberger commented on JCR-3489:
Speaking of Sling: Our solution base
[
https://issues.apache.org/jira/browse/JCR-3465?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13506318#comment-13506318
]
Felix Meschberger commented on JCR-3465:
+1 to fixing.
AFAICT from reading
Welcome and Congratulations !
Regards
Felix
Am 01.11.2012 um 09:57 schrieb Michael Dürig:
>
> Hi,
>
> Please welcome Philipp Marx as a new committer and PMC member of
> the Apache Jackrabbit project. The Jackrabbit PMC recently decided to
> offer Philipp committership based on his contribution
Congratulations and Welcome !
Regards
Felix
Am 21.09.2012 um 09:50 schrieb Michael Dürig:
>
> Hi,
>
> Better a bit late than never. Sorry about that Randall, here is the
> official welcome message!
>
> Please welcome Randall Hauch as a new committer and PMC member of
> the Apache Jackrabbit
Welcome Chetan and Congratulations.
Keep up the good work !
Regards
Felix
Am 21.09.2012 um 09:48 schrieb Michael Dürig:
>
> Hi,
>
> Please welcome Chetan Mehrotra as a new committer and PMC member of
> the Apache Jackrabbit project. The Jackrabbit PMC recently decided to
> offer Chetan commit
[
https://issues.apache.org/jira/browse/JCR-3350?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13403828#comment-13403828
]
Felix Meschberger commented on JCR-3350:
Some comments:
* I would wrap
Hi,
Am 31.05.2012 um 10:22 schrieb Julian Reschke:
> Hi,
>
> yesterday, while working on OAK, I accidentally made a jackrabbit
> (-tests) change containing a 1.6ism (String.isEmpty). Nothing serious,
> and easy to fix.
Technically I am all for dropping the Java 5 requirement -- Java 5 is
ess
Hi
Congratulations Michael !
Have fun and enjoy ;-)
Am 21.04.2012 um 13:07 schrieb Michael Dürig:
> And thank you Jukka for being such a great chair and doing all that work
> for the last couple of years.
+100 !
Regards
Felix
>
> Regards,
> Michael
>
> On 19.4.12 20:35, Jukka Zitting wrote
Hi,
Thanks for the information and your offer.
Depending on the size and number of changes you applied the process is slightly
different.
The best thing to get the process going is to file a JIRA issue for Jackrabbit
attaching a patch showing the required changes.
The patch would best be done
[
https://issues.apache.org/jira/browse/JCR-3293?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Felix Meschberger updated JCR-3293:
---
Description:
based on JCR-2355 we added a very simplistic way to indicate to the login
module
[
https://issues.apache.org/jira/browse/JCR-3294?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13255409#comment-13255409
]
Felix Meschberger commented on JCR-3294:
Looks like a duplicate to JCR-
[
https://issues.apache.org/jira/browse/JCR-3288?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13251408#comment-13251408
]
Felix Meschberger edited comment on JCR-3288 at 4/11/12 8:1
[
https://issues.apache.org/jira/browse/JCR-3288?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13251408#comment-13251408
]
Felix Meschberger commented on JCR-3288:
Whatever the final solution, u
Hi,
Am 12.03.2012 um 14:01 schrieb Jukka Zitting:
> Hi,
>
> On Mon, Mar 12, 2012 at 1:46 PM, Felix Meschberger wrote:
>> But: However the repository implements sharding etc. The user of the
>> JCR API does not have to care about this implementation detail...
>
>
Hi,
Am 08.03.2012 um 06:57 schrieb Angela Schreiber:
> hi
>
> in addition to the proposal by jukka to setup benchmarks
> i would like to suggest to soon setup integration testing
> that also test jr3 against the TCK.
>
> imo it's important that we identify implementation
> details that violate
Hi,
Thanks.
Am 06.03.2012 um 04:00 schrieb Jukka Zitting:
> Hi,
>
> On Tue, Mar 6, 2012 at 9:17 AM, Jukka Zitting wrote:
>> Oak has the advantage and so we'll go with that. I'll set up the new
>> mailing list, issue tracker and svn space in a moment.
>
> The issue tracker is now available at
Hi,
I see and understand your points. But then, when it comes to clustering,
generating a strictly monotone sequential ID without collisions without
tampering performance is probably a hard problem to solve, right ?
I wonder, who defines the node IDs ? Is it the layer above of below the
Mikrok
Hi,
Am 28.02.2012 um 18:21 schrieb Jukka Zitting:
> Otherwise
> we'll just continue down the path where everyone has their own
> MicroKernel implementation.
I don't think this is bad per se .. in fact it could be the source of better
implementations.
It may even end up with two implementations w
Hi,
Am 29.02.2012 um 09:36 schrieb Thomas Mueller:
> Hi,
>
>> I don't want to be nitpicking and whatever implementation you come up
>> with to help my "concurrent write" use case is fine with me.
>
> Could you describe your "concurrent write" use case then please? A test
> case would be best.
Hi,
Am 29.02.2012 um 09:26 schrieb Thomas Mueller:
>> As a user of the JCR API I really do care about concurrent writes.
>
> We discussed that at the F2F. It seems your problem is actually write
> throughput. You *think* that concurrent writes will automatically improve
> write throughput. Well,
Hi,
Am 29.02.2012 um 08:57 schrieb Thomas Mueller:
> Hi,
>
>> As has been said other places: Requiring a wrapper indicates a general
>> issue with the API...
>
> No. We do need two interfaces:
>
> * A stringly typed one for C and for remoting
C has struct and remoting is an implementation det
Hi,
Am 29.02.2012 um 08:55 schrieb Thomas Mueller:
> Hi,
>
> I think we all have more or less the same basic idea. Well, I would call
> it "Node" and not "Tree" because the term node more closely matches what
> we do. But first about what we seem to agree:
>
> * A persistent and immutable data
Hi,
Am 29.02.2012 um 08:39 schrieb Thomas Mueller:
> Hi,
>
>> So, I would even go a step further and change the MK API to transfer data
>> structures back and forth to prevent repeated serialization and
>> deserialization.
>
> This is already available: org.apache.jackrabbit.mk.wrapper.Wrapper
Hi,
Am 28.02.2012 um 15:59 schrieb Jukka Zitting:
> * A content tree is composed of a hierachy of items
> * Tree items are either leaves or non-leaves
> * Non-leaves contain zero or more named child items (*all* other
> data is stored at leaves)
> * Each child item is *uniquely* named within i
Hi,
Am 28.02.2012 um 16:11 schrieb Thomas Mueller:
> Hi,
>
>> import java.util.Map;
>> ... extends Map
>
> For a low level interface, that would be a lot of methods to be
> implemented, with special semantics that might not be desirable (for
> example put returns the old data).
I kind of like
Hi,
I really like this idea because it aligns with my conceptual issue of having
strings in the API which represent serialized data structures.
Having such strings is counter-intuitive to any non-assembler language which
can operate on data structures (even C has struct).
So, I would even go a
Hi
I might have missed a thing, but where has oak gone ?
Reagards
Felix
Am 28.02.2012 um 11:13 schrieb Jukka Zitting:
> Hi,
>
> OK, I think we have quite a few reasonable alternatives here, each
> with their own strengths and weaknesses. I dropped the candidates with
> notable downsides (espec
Hi,
Am 23.02.2012 um 17:33 schrieb Jukka Zitting:
> Hi,
>
> On Thu, Feb 23, 2012 at 4:03 PM, Felix Meschberger wrote:
>> Hence I would go with OSGi from Day 0 and use the OSGi Service
>> Registry as the mechanic for pluggability.
>
> The trouble with OSGi by def
Hi,
Am 23.02.2012 um 15:36 schrieb Christian Stocker:
>
>
> On 23.02.12 15:26, Thomas Mueller wrote:
>> Hi,
>>
>>It would be great if in JR3 all JCR methods would be exposed to a HTTP
>>(REST) API.
>>
>>
>> +1
>>
>>Currently the most important stuff is, but not everthing.
>>
>>
Hi,
Am 23.02.2012 um 15:15 schrieb Jukka Zitting:
> This is a pretty tight schedule mostly to bring up a sense of focus
> that we currently seem to be lacking. The proposed schedule should be
> reachable with a few persons working full time on this, which I think
> (and hope) we should be able to
Hi,
Am 23.02.2012 um 11:04 schrieb Thomas Mueller:
> Hi,
>
>> I understand, but we need it ;-)
>
> Do you have a use cases where there are more than 2000 child nodes, and
> they need to be ordered? Up to what limit do you need to keep them ordered?
If you can guarantee ordering for child nodes
Hi,
Am 23.02.2012 um 10:50 schrieb Thomas Mueller:
> Hi,
>
>> option.transactions.supported = true
>
>
> Is this JTA, right? Is it really required?
While I don't like it either, some people make up a case for it
So, if it can "easily" be supported, I think it would be a plus in the
ente
Hi,
Am 23.02.2012 um 09:17 schrieb Angela Schreiber:
> hi michael
>
>> Looking at the list of repository descriptors [1] we could decide for
>> either of them what we want to support. Here is my take:
>
> i agree with you except for the following:
>
>> option.node.and.property.with.same.name.s
Hi,
Am 17.02.2012 um 15:03 schrieb Jukka Zitting:
> Hi,
>
> On Fri, Feb 17, 2012 at 2:52 PM, Felix Meschberger wrote:
>> Me thinks that the version in o.a.j.spi.commons.name.package-info.java must
>> be increased to 2.4.1 due to this addition.
>
> I've been
Hi
Me thinks that the version in o.a.j.spi.commons.name.package-info.java must be
increased to 2.4.1 due to this addition.
Regards
Felix
Am 17.02.2012 um 14:45 schrieb Julian Reschke (Resolved) (JIRA):
>
> [
> https://issues.apache.org/jira/browse/JCR-3237?page=com.atlassian.jira.plugin.
[
https://issues.apache.org/jira/browse/JCR-3228?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13210096#comment-13210096
]
Felix Meschberger commented on JCR-3228:
The spec does not mandate to include
Hi,
Am 06.02.2012 um 13:38 schrieb Michael Dürig:
On Monday, February 6, 2012, Felix Meschberger
mailto:fmesc...@adobe.com>> wrote:
> Hi,
>
> Am 03.02.2012 um 19:44 schrieb Michael Dürig:
>
>> Invalid moves are exactly those which would result in a node being
Hi,
Am 03.02.2012 um 19:44 schrieb Michael Dürig:
> Invalid moves are exactly those which would result in a node being moved
> to an ancestor/descendant of itself.
I understand why a move to a descendant of self is invalid.
But why is a move to an ancestor of self invalid ?
Eg. "mv /a/b/c /a"
Hi,
Am 31.01.2012 um 17:25 schrieb Michael Dürig:
>
>
> On 31.1.12 16:11, Felix Meschberger wrote:
>> Hi,
>>
>> Am 31.01.2012 um 15:47 schrieb Michael Dürig:
>>
>>> OTOH, sticking with Java might leave us lagging behind, entrapped in
>>&
Hi,
Am 31.01.2012 um 15:47 schrieb Michael Dürig:
> OTOH, sticking with Java might leave us lagging behind, entrapped in
> never ending concurrency night mares and memory contention issues.
This is probably and simply not true: It is not the language's fault that
developers are not adhering to
Hi,
Am 31.01.2012 um 14:31 schrieb Jukka Zitting:
> Hi,
>
> On Tue, Jan 31, 2012 at 2:22 PM, Michael Dürig wrote:
>> I'd rather go for a modern language instead of taping things together ;-)
Michael is certainly thinking of Scala which has its own can of issues ...
Syntax not being the least
Hi,
Am 30.01.2012 um 17:54 schrieb Dominique Pfister:
> Hi,
>
> Just stumbled across this compilation setting in microkernel's pom.xml:
>
>
> maven-compiler-plugin
> 2.3.2
>
> 1.5
> 1.5
>
[
https://issues.apache.org/jira/browse/JCR-3222?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13194699#comment-13194699
]
Felix Meschberger commented on JCR-3222:
> That
[
https://issues.apache.org/jira/browse/JCR-3222?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13194507#comment-13194507
]
Felix Meschberger commented on JCR-3222:
> The Sling authentication code n
[
https://issues.apache.org/jira/browse/JCR-3222?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Felix Meschberger updated JCR-3222:
---
Attachment: JCR-3222-fmeschbe.patch
Proposed patch enhancing DavexServletService
[
https://issues.apache.org/jira/browse/JCR-3222?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13194074#comment-13194074
]
Felix Meschberger commented on JCR-3222:
Unfortunately this is a compiled lib
Hi,
Am 25.01.2012 um 01:37 schrieb Jukka Zitting:
> Hi,
>
> On Wed, Jan 25, 2012 at 1:06 AM, Tobias Bocanegra wrote:
>> how about adding getSelectorJcrNames() and deprecate the other one?
>
> Yes, we can do that. It just feels silly that we have to go through
> hoops like that when AFAICT were
Wanted to upgrade the Sling build to Jacktabbit 2.3.7 bundles .. Due to this
incompatibility this is not possible without updating everything Jackrabbit to
2.3.7...
Regards
Felix
Jukka Zitting schrieb:
Hi,
On Wed, Jan 25, 2012 at 12:36 AM, Felix Meschberger wrote:
> I got a big prob
Hi
Looks like this came in for JCR-3198, which indeed changes signatures on
methods, which is indeed breaking compatiblity.
This should probably not be done (and may new interfaces defined with new API).
Regards
Felix
Am 25.01.2012 um 00:36 schrieb Felix Meschberger:
> Hi all,
>
>
Hi all,
I got a big problem with Jackrabbit SPI version 2.3.7 just released: This
increases the export version of the org.apache.jackrabit.spi package from 2.4.0
to 3.0.0.
The consequence of this is dramatic: It breaks compatibility on all levels !
It looks like this has been done by commit 12
Hi,
Am 23.01.2012 um 10:43 schrieb Jukka Zitting:
> Hi,
>
> On Sat, Jan 21, 2012 at 11:37 PM, Tobias Bocanegra wrote:
>> so for large childnode lists, a stable but uncontrollable order
>> would be ok, although violating the spec?
>
> I wouldn't violate the spec for this. If you have an orderab
[
https://issues.apache.org/jira/browse/JCR-2859?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13176630#comment-13176630
]
Felix Meschberger commented on JCR-2859:
I like the lock breaker idea.
Shoul
Hi,
Am 14.12.2011 um 14:10 schrieb Thomas Mueller:
> Hi,
>
> In my view, we should try to stay compatible with DavEx JSOP, except for
> those cases where DavEx JSOP is problematic:
>
> - I think it didn't require paths to be double quoted?
>
> - Move operations were defined as > "/from": "/to"
[
https://issues.apache.org/jira/browse/JCR-3170?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13163107#comment-13163107
]
Felix Meschberger commented on JCR-3170:
Sorry for being late. But I don
Hi,
Am 01.12.2011 um 14:47 schrieb Michael Dürig:
>
>>> Currently the microkernel does nothing about this. That's what this whole
>>> discussion is about after all ;-)
>>
>> and please bear in mind that the microkernel project in the jackrabbit
>> sandbox
>> is a prototype and represents WIP..
Hi,
Am 01.12.2011 um 13:11 schrieb Jukka Zitting:
> On Thu, Dec 1, 2011 at 11:59 AM, Felix Meschberger wrote:
>
>> So we (thinking of Sling amongst other things) might have to adapt
>> our event listeners to do a Session.refresh at the beginning of the
>> onEvent me
[
https://issues.apache.org/jira/browse/JCR-3164?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Felix Meschberger resolved JCR-3164.
Resolution: Won't Fix
Thanks for the quick reply.
Reconsidering this idea, I thin
Hi,
Am 30.11.2011 um 21:53 schrieb Jukka Zitting:
> 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.
>
> S
Components: jackrabbit-core
Affects Versions: 2.3.4
Reporter: Felix Meschberger
Currently the TokenBasedAuthentication class creates token nodes on demand and
will only remove a token's node if the token is used after it has expired. To
be able to do some
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
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
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
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
1 - 100 of 630 matches
Mail list logo
