[jira] [Commented] (JCR-4460) allow to run remoted conformance tests with a custom servlet context path

[Felix Meschberger (JIRA)]

[ 
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 being used in the Sling JCR WebDAV bundles for 
some more insight, [~reschke]

> allow to run remoted conformance tests with a custom servlet context path
> -
>
> Key: JCR-4460
> URL: https://issues.apache.org/jira/browse/JCR-4460
> Project: Jackrabbit Content Repository
>  Issue Type: Task
>  Components: jackrabbit-jcr2dav
>Reporter: Julian Reschke
>Assignee: Julian Reschke
>Priority: Minor
>  Labels: candidate_jcr_2_16
> Fix For: 2.20, 2.19.4, 2.18.3
>
> Attachments: use-context-path.diff
>
>
> Add a system property that selects a servlet context path for testing.
> To run tests with non-root path:
> {noformat}
> mvn clean install -PintegrationTesting -DWebDAVServletContext="/foobar/"
> {noformat}



--
This message was sent by Atlassian JIRA
(v7.6.14#76016)

[jira] [Commented] (JCR-4460) allow to run remoted conformance tests with a custom servlet context path

[Felix Meschberger (JIRA)]

[ 
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 reason for it's introduction
{quote}
I guess so, yes. But I cannot remember. One explanation I would have is usage 
inside an OSGi framework where the servlet context path might be injected 
differently... But honestly, I do not remember ...

> allow to run remoted conformance tests with a custom servlet context path
> -
>
> Key: JCR-4460
> URL: https://issues.apache.org/jira/browse/JCR-4460
> Project: Jackrabbit Content Repository
>  Issue Type: Task
>  Components: jackrabbit-jcr2dav
>Reporter: Julian Reschke
>Assignee: Julian Reschke
>Priority: Minor
>  Labels: candidate_jcr_2_16
> Fix For: 2.20, 2.19.4, 2.18.3
>
> Attachments: use-context-path.diff
>
>
> Add a system property that selects a servlet context path for testing.
> To run tests with non-root path:
> {noformat}
> mvn clean install -PintegrationTesting -DWebDAVServletContext="/foobar/"
> {noformat}



--
This message was sent by Atlassian JIRA
(v7.6.14#76016)

Re: [FileVault][discuss] performance improvement proposal

[Felix Meschberger]

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/desire.

Regards
Felix

Am 06.03.2017 um 16:43 schrieb Timothée Maret 
mailto:timothee.ma...@gmail.com>>:

Hi,

With Sling content distribution (using FileVault), we observe a significantly 
lower throughput for content packages containing binaries.
The main bottleneck seems to be the compression algorithm applied to every 
element contained in the content package.

I think that we could improve the throughput significantly, simply by avoiding 
to re-compress binaries that are already compressed.
In order to figure out what binaries are already compressed, we could use match 
the content type stored along the binary against a list of configurable content 
types.

I have done some micro tests with this idea (patch in [0]). I think that the 
results are promising.

Exporting a single 250 MB JPEG is 80% faster (22.4 sec -> 4.3 sec) for a 3% 
bigger content package (233.2 MB -> 240.4 MB)
Exporting AEM OOTB /content/dam is 50% faster (11.9 sec -> 5.9 sec) for a 5% 
bigger content package (92.8 MB -> 97.4 MB)
Import for the same cases is 66% faster respectively 32% faster.

I think this could either be done by default and allowing to configure the list 
of types that skip compression.
Alternatively, it could be done on a project level, by extending FileVault with 
the following

1. For each package, allow to define the default compression level (best 
compression, best speed)
2. Expose an API that allow to plugin a custom logic to decide how to compress 
a given artefact

In any case, the changes would be backward compatible. Content packages created 
with the new code would be installable on instances running the old code and 
vice versa.

wdyt ?

Regards,

Timothee


[0] 
https://github.com/tmaret/jackrabbit-filevault/tree/performance-avoid-compressing-already-compressed-binaries-based-on-content-type-detection
[1] 
https://docs.oracle.com/javase/7/docs/api/java/util/zip/Deflater.html#BEST_SPEED

[jira] [Commented] (JCR-4060) unintended export versions due to changed defaults in maven bundle plugin

[Felix Meschberger (JIRA)]

[ 
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 due to changed defaults in maven bundle plugin
> -
>
> Key: JCR-4060
> URL: https://issues.apache.org/jira/browse/JCR-4060
> Project: Jackrabbit Content Repository
>  Issue Type: Bug
>Affects Versions: 2.12.5, 2.13.4
>Reporter: Julian Reschke
>Priority: Blocker
> Fix For: 2.13.6, 2.14, 2.12.7
>
> Attachments: ExportVersionChecker.jar, ExportVersionChecker.java
>
>
> It appears that the maven bundle plugin change for JCR-3937 has caused 
> default export version numbers to be assigned where before we hadn't any.
> For instance, in jackrabbit-api, the package "o.a.j.api" has a 
> package-info.java setting the version to 2.4, and this is what get's exported.
> However, o.a.j.api.query does not have a package-info, and now gets exported 
> with a version number of 2.13.5, whereas previously it didn't get any version 
> number.
> a) Does anybody know whether this change in behavior of the bundle plugin is 
> documented anywhere?
> b) Do we need to fix something here, or are automatically assigned version 
> numbers indeed ok? If we need to do something, what is the correct fix? 
> Freeze the version numbers at the currently assigned version?



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (JCR-4060) unintended export versions due to changed defaults in maven bundle plugin

[Felix Meschberger (JIRA)]

[ 
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 to do would be to create java-package.info 
files in all the exported packages exporting these packages at the latest 
bundle release version. This way you don't break existing consumers and make 
sure that going forward, the export versions should be properly managed as the 
packages may evolve (well probably not any more, so having a fixed version 
number is even better).

... and then not having full-blown all-in releases any more also will help, but 
that is for another day ;-)

> unintended export versions due to changed defaults in maven bundle plugin
> -
>
> Key: JCR-4060
> URL: https://issues.apache.org/jira/browse/JCR-4060
> Project: Jackrabbit Content Repository
>  Issue Type: Bug
>Affects Versions: 2.12.5, 2.13.4
>Reporter: Julian Reschke
>Priority: Blocker
> Fix For: 2.13.6, 2.14, 2.12.7
>
> Attachments: ExportVersionChecker.jar, ExportVersionChecker.java
>
>
> It appears that the maven bundle plugin change for JCR-3937 has caused 
> default export version numbers to be assigned where before we hadn't any.
> For instance, in jackrabbit-api, the package "o.a.j.api" has a 
> package-info.java setting the version to 2.4, and this is what get's exported.
> However, o.a.j.api.query does not have a package-info, and now gets exported 
> with a version number of 2.13.5, whereas previously it didn't get any version 
> number.
> a) Does anybody know whether this change in behavior of the bundle plugin is 
> documented anywhere?
> b) Do we need to fix something here, or are automatically assigned version 
> numbers indeed ok? If we need to do something, what is the correct fix? 
> Freeze the version numbers at the currently assigned version?



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (JCR-3870) Export SessionImpl#getItemOrNull in JackrabbitSession

[Felix Meschberger (JIRA)]

[ 
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 has always been there.

> Export SessionImpl#getItemOrNull in JackrabbitSession
> -
>
> Key: JCR-3870
> URL: https://issues.apache.org/jira/browse/JCR-3870
> Project: Jackrabbit Content Repository
>  Issue Type: Improvement
>  Components: jackrabbit-api
>Affects Versions: 2.10
>Reporter: Joel Richard
>Priority: Critical
>  Labels: performance
>
> getItemOrNull should be exported in JackrabbitSession. This would allow to 
> combine itemExists and getItem in Sling which would reduce the rendering time 
> by 8%.
> See the following mail thread for more information: 
> http://mail-archives.apache.org/mod_mbox/jackrabbit-oak-dev/201504.mbox/%3CD1495A09.3B670%25anchela%40adobe.com%3E



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (JCR-3870) Export SessionImpl#getItemOrNull in JackrabbitSession

[Felix Meschberger (JIRA)]

[ 
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, where sling is optimized around how the JCR 
implementation behaves

Really ? Off the top of my head I know of the Oak Observer (falling back to 
regular JCR Observation is not available). Others ?

Indeed, at one point in early time, Sling had JCR Session pooling until 
Jackrabbit Repository.login became drammatically faster than pooled session 
cleanup. At which time we happily removed Session pooling from Sling.

> Export SessionImpl#getItemOrNull in JackrabbitSession
> -
>
> Key: JCR-3870
> URL: https://issues.apache.org/jira/browse/JCR-3870
> Project: Jackrabbit Content Repository
>  Issue Type: Improvement
>  Components: jackrabbit-api
>Affects Versions: 2.10
>Reporter: Joel Richard
>Priority: Critical
>  Labels: performance
>
> getItemOrNull should be exported in JackrabbitSession. This would allow to 
> combine itemExists and getItem in Sling which would reduce the rendering time 
> by 8%.
> See the following mail thread for more information: 
> http://mail-archives.apache.org/mod_mbox/jackrabbit-oak-dev/201504.mbox/%3CD1495A09.3B670%25anchela%40adobe.com%3E



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Comment Edited] (JCR-3870) Export SessionImpl#getItemOrNull in JackrabbitSession

[Felix Meschberger (JIRA)]

[ 
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:55 AM:


I don't think it is worth exporting such a method.

The most basic problem is the JCR API requesting the getItem method to throw in 
case the item does not exist. So the itemExists method has been added to be 
able to check the existence (or visibility, actually) of the item before trying 
to access it.

So, the actual performance problem boils down to being an implementation 
problem: The API specification, as [~mreutegg] pointed out, suggests to check 
for existence before accessing the item and this is what Sling does. In other 
word Sling follows the API specification guidance.

As such Sling is expecting the implementation to do the best to support the API 
and the API guidance.


was (Author: fmeschbe):
I don't think it is worth exporting such a method.

The most basic problem is the JCR API requesting the getItem method to throw in 
case the item does not exist. So the itemExists method has been added to be 
able to check the existence (or visibility, actually) of the item before trying 
to access it.

So, the actual performance problem boils down to being an implementation 
problem: The API specification as [~mreutegg] pointed out suggest to check for 
existence before accessing the item and this is what Sling does. In other word 
Sling follows the API specification guidance.

As such Sling is expecting the implementation to do the best to support the API 
and the API guidance.

> Export SessionImpl#getItemOrNull in JackrabbitSession
> -
>
> Key: JCR-3870
> URL: https://issues.apache.org/jira/browse/JCR-3870
> Project: Jackrabbit Content Repository
>  Issue Type: Improvement
>  Components: jackrabbit-api
>Affects Versions: 2.10
>Reporter: Joel Richard
>Priority: Critical
>  Labels: performance
>
> getItemOrNull should be exported in JackrabbitSession. This would allow to 
> combine itemExists and getItem in Sling which would reduce the rendering time 
> by 8%.
> See the following mail thread for more information: 
> http://mail-archives.apache.org/mod_mbox/jackrabbit-oak-dev/201504.mbox/%3CD1495A09.3B670%25anchela%40adobe.com%3E



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (JCR-3870) Export SessionImpl#getItemOrNull in JackrabbitSession

[Felix Meschberger (JIRA)]

[ 
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 exporting such a method.

The most basic problem is the JCR API requesting the getItem method to throw in 
case the item does not exist. So the itemExists method has been added to be 
able to check the existence (or visibility, actually) of the item before trying 
to access it.

So, the actual performance problem boils down to being an implementation 
problem: The API specification as [~mreutegg] pointed out suggest to check for 
existence before accessing the item and this is what Sling does. In other word 
Sling follows the API specification guidance.

As such Sling is expecting the implementation to do the best to support the API 
and the API guidance.

> Export SessionImpl#getItemOrNull in JackrabbitSession
> -
>
> Key: JCR-3870
> URL: https://issues.apache.org/jira/browse/JCR-3870
> Project: Jackrabbit Content Repository
>  Issue Type: Improvement
>  Components: jackrabbit-api
>Affects Versions: 2.10
>Reporter: Joel Richard
>Priority: Critical
>  Labels: performance
>
> getItemOrNull should be exported in JackrabbitSession. This would allow to 
> combine itemExists and getItem in Sling which would reduce the rendering time 
> by 8%.
> See the following mail thread for more information: 
> http://mail-archives.apache.org/mod_mbox/jackrabbit-oak-dev/201504.mbox/%3CD1495A09.3B670%25anchela%40adobe.com%3E



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (JCR-3802) User Management: API for System Users

[Felix Meschberger (JIRA)]

[ 
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 defines the properties of a system user. But what is the use case 
for system users from a pure Jackrabbit point of view ? I understand the 
support for Sling's SlingRepository.loginService method and I think that makes 
sense. Is that enough to justify the introduction of system users in Jackrabbit 
?

(Don't get me wrong. I think the idea is perfectly valid and with my Sling hat 
on, I welcome it very much.)

And some comments on the POC patch:

* SystemUserImpl.checkValidTree checks for type AuthorizableType.USER to check 
whether the tree is of the correct type. Is that correct or should that be 
AuthorizableType.SYSTEM_USER ?
* UserValidator prohibits disabling system users. What is the reason ? I would 
think we should be able to disable these users just as any other users for some 
quick stop-gap security measures.
* UserUtil.isSystemUser is missing from the POC patch
* UserManagerImpl adds use of com.google.common.base.Strings[.isNullOrEmpty]. 
Is that by intent or should this rather be org.apache.lang.StringUtil ?

> User Management: API for System Users
> -
>
> Key: JCR-3802
> URL: https://issues.apache.org/jira/browse/JCR-3802
> Project: Jackrabbit Content Repository
>  Issue Type: New Feature
>  Components: jackrabbit-api
>Reporter: angela
> Attachments: JCR-3802___POC_implementation_for_Oak.patch, 
> JCR-3802_proposed_API.patch
>
>
> Apache Sling recently added the ability to define dedicated service users 
> that allows to replace the troublesome 
> {{SlingRepository.loginAdministrative}} with {{SlingRepository.loginService}}.
> In a default Sling repository backed by a Jackrabbit/Oak content repository 
> this results in user accounts being created for these service users.
> Since these service users are never expected to represent a real subject that 
> has a userId/password pair or profile information editable by this very 
> subject, I figured out that it may be useful to cover these service users 
> with the following API extensions, which would allow us to identify if a 
> given user account is in fact a service (or system) user. 



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Commented] (JCR-3745) Add JackrabbitObservationManager with additional methods for registering event listeners

[Felix Meschberger (JIRA)]

[ 
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's the use of extending it ? The ObservationManager is the consumer of the 
instance and it can only support what it can support and thus is exposed in 
this base class. If we later see, that extension makes sense we can still make 
it non-final. But making a non-final class final is essentially killing 
backwards compatibility.

> Add JackrabbitObservationManager with additional methods for registering 
> event listeners
> 
>
> Key: JCR-3745
> URL: https://issues.apache.org/jira/browse/JCR-3745
> Project: Jackrabbit Content Repository
>  Issue Type: New Feature
>  Components: jackrabbit-api
>Reporter: Michael Dürig
>Assignee: Michael Dürig
> Attachments: JCR-3745.patch
>
>
> I'd like to add an additional method for adding event listeners to the 
> Jackrabbit API: 
> void addEventListener(EventListener listener, int eventTypes, String[] 
> absPaths, boolean isDeep, String[] uuid, String[] nodeTypeName, boolean 
> noLocal, boolean noExternal) throws RepositoryException; 
> Compared to the JCR method of the same name, this method takes an array of 
> absPath and additional boolean argument: 
> Only events whose associated parent node is at one of the paths in 
> absPaths (or within its subgraph, if isDeep is 
> true) will be received. 
> and 
> Additionally, if noExternal is true, then events 
> from external cluster nodes are ignored. Otherwise, they are not ignored.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Commented] (JCR-3745) Add JackrabbitObservationManager with additional methods for registering event listeners

[Felix Meschberger (JIRA)]

[ 
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 both methods and should be fine.

[~mduerig] I seem to understand we agree on the setter methods for interfaces: 
How about defining JackrabbitEventListener as a final class ? 

(NB: Actually it just occurrs to me why setters on interfaces are a really bad 
idea: This basically defines a mutable object and so the filter used for 
registration cannot be used by the ObservationManager essentially causing the 
latter to clone (or otherwise copy) the settings for internal use. Slightly 
better would be a builder interface with setters and the actual interface with 
getters -- still two objects, though ...)

> Add JackrabbitObservationManager with additional methods for registering 
> event listeners
> 
>
> Key: JCR-3745
> URL: https://issues.apache.org/jira/browse/JCR-3745
> Project: Jackrabbit Content Repository
>  Issue Type: New Feature
>  Components: jackrabbit-api
>Reporter: Michael Dürig
>Assignee: Michael Dürig
> Attachments: JCR-3745.patch
>
>
> I'd like to add an additional method for adding event listeners to the 
> Jackrabbit API: 
> void addEventListener(EventListener listener, int eventTypes, String[] 
> absPaths, boolean isDeep, String[] uuid, String[] nodeTypeName, boolean 
> noLocal, boolean noExternal) throws RepositoryException; 
> Compared to the JCR method of the same name, this method takes an array of 
> absPath and additional boolean argument: 
> Only events whose associated parent node is at one of the paths in 
> absPaths (or within its subgraph, if isDeep is 
> true) will be received. 
> and 
> Additionally, if noExternal is true, then events 
> from external cluster nodes are ignored. Otherwise, they are not ignored.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Commented] (JCR-3745) Add JackrabbitObservationManager with additional methods for registering event listeners

[Felix Meschberger (JIRA)]

[ 
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 it is strange to have an interface defining 
a Bean API instead of just have the simple flat bean class. Alternatively the 
interface would just define getter methods.

> Add JackrabbitObservationManager with additional methods for registering 
> event listeners
> 
>
> Key: JCR-3745
> URL: https://issues.apache.org/jira/browse/JCR-3745
> Project: Jackrabbit Content Repository
>  Issue Type: New Feature
>  Components: jackrabbit-api
>Reporter: Michael Dürig
>Assignee: Michael Dürig
>
> I'd like to add an additional method for adding event listeners to the 
> Jackrabbit API: 
> void addEventListener(EventListener listener, int eventTypes, String[] 
> absPaths, boolean isDeep, String[] uuid, String[] nodeTypeName, boolean 
> noLocal, boolean noExternal) throws RepositoryException; 
> Compared to the JCR method of the same name, this method takes an array of 
> absPath and additional boolean argument: 
> Only events whose associated parent node is at one of the paths in 
> absPaths (or within its subgraph, if isDeep is 
> true) will be received. 
> and 
> Additionally, if noExternal is true, then events 
> from external cluster nodes are ignored. Otherwise, they are not ignored.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

Re: Roadmap for Jackrabbit 2.x and 3.0

[Felix Meschberger]

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 impact on how people can migrate existing Jackrabbit
> repositories to Oak, or is migration a separate concern and plan?

Yes, please !

Regards
Felix

> 
> -Bertrand

Re: Roadmap for Jackrabbit 2.x and 3.0

[Felix Meschberger]

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!
> 
> On Thu, Jan 17, 2013 at 6:00 AM, Jukka Zitting  
> wrote:
>>> * Jackrabbit 3.0: Early next year, after the 2.6 and 2.x branches have
>>> been created, we'd replace the current trunk with an Oak-based JCR
>>> implementation.
>> 
>> As mentioned above, instead of replacing the trunk entirely, I'd keep
>> both codebases in trunk for now and include *both* the 2.x and Oak
>> repositories in things like jackrabbit-webapp and
>> jackrabbit-standalone, with a configuration option to decide which
>> repository implementation should be used in each particular
>> deployment.
> 
> I was looking at this a few months ago, and there's one big blocker
> that makes such a double deployment somewhat complicated: Since
> Jackrabbit 2.x ("Jackrabbit Classic"?) still uses an older version of
> Lucene, it's hard merge with Oak where Lucene 4 is used. I have a few
> ideas on how this problem could be resolved:
> 
> a) Upgrade Jackrabbit Classic to use Lucene 4. As discussed earlier
> (http://markmail.org/message/nv5jeeoda7qe5qen) this is pretty hard,
> and it's questionable whether the benefits are worth the effort.
> 
> b) Downgrade Oak to use Lucene 3. This should be doable with not much
> effort, as the Lucene integration in Oak is much simpler than in
> Jackrabbit Classic. It might even be possible to make oak-lucene
> version-independent, so it would work with both Lucene 3 and 4.
> 
> c) Ship the jackrabbit deployment packages without Lucene integration
> for Oak. This would allow people to start playing with Oak in their
> existing deployments, but require some deployment changes for full Oak
> functionality.
> 
> d) Use the class rewriting tricks in something like the Shade plugin
> [1] to be able to include both Lucene 3 *and* 4 in the same deployment
> packages. I'm not sure if this is even possible with Lucene, or how
> much effort it would require.
> 
> e) Use a custom classloader setup to load the correct version of
> Lucene depending on the selected Jackrabbit mode.
> 
> f) Adjust the Jackrabbit deployment packages to use an embedded OSGi
> container, and use it to selectively deploy the required
> implementation components, including the correct version of Lucene.
> 
> 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.
> 
> I'm thinking of trying to implement one or two of these alternatives
> within the next few weeks, and cut Jackrabbit 2.8 based on that work
> and including something like Oak 0.16 as a beta feature. Assuming that
> approach works and Oak stabilizes as planned, we could then follow up
> with Jackrabbit 3.0 fairly soon after 2.8.
> 
> [1] http://maven.apache.org/plugins/maven-shade-plugin/
> 
> BR,
> 
> Jukka Zitting

[jira] [Commented] (JCR-3705) Extract data store API and implementations from jackrabbit-core

[Felix Meschberger (JIRA)]

[ 
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 component

> Extract data store API and implementations from jackrabbit-core
> ---
>
> Key: JCR-3705
> URL: https://issues.apache.org/jira/browse/JCR-3705
> Project: Jackrabbit Content Repository
>  Issue Type: Improvement
>  Components: jackrabbit-core
>Reporter: Jukka Zitting
>
> In Oak we'd like to use the Jackrabbit data stores (OAK-805). Doing so would 
> currently require a direct dependency to jackrabbit-core, which is 
> troublesome for various reasons.
> Since the DataStore interface and its implementations are mostly independent 
> of the rest of Jackrabbit internals, it should be possible to avoid that 
> dependency by moving the data store bits to some other component.
> One alternative would be to place them in jackrabbit-jcr-commons, another to 
> create a separate new jackrabbit-data component for this purpose. WDYT?



--
This message was sent by Atlassian JIRA
(v6.1#6144)

[jira] [Commented] (JCR-3293) AbstractLoginModule: get rid of trust_credentials_attribute

[Felix Meschberger (JIRA)]

[ 
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 think:

{code}
Subject s = getAndPopulateTheSubject();
Session session = Subject.doAs(s, new PrivilegedExceptionAction() {
public Session run() throws RepositoryException {
return repository.login();
}
});
{code}

(plus proper exception handling and unwrapping, of course)

> AbstractLoginModule: get rid of trust_credentials_attribute
> ---
>
> Key: JCR-3293
> URL: https://issues.apache.org/jira/browse/JCR-3293
> Project: Jackrabbit Content Repository
>  Issue Type: Bug
>  Components: jackrabbit-core
>Affects Versions: 2.4
>Reporter: angela
>
> based on JCR-2355 we added a very simplistic way to indicate to the login 
> module that the given credentials have
> been preauthenticated. as already stated in the original issue this poses a 
> major security issue as it leaves the
> repository access untrusted.
> i would like to raise those security concern again and would therefore like 
> to get rid of that hack in the long run.
> the suggested procedure:
> - deprecate the attribute (immediately)
> - log a warning if it is used (immediately)
> - document how to fix code that is currently relying on that attribute
> - remove support altogether for the next major release



--
This message was sent by Atlassian JIRA
(v6.1#6144)

[jira] [Commented] (JCRVLT-18) Set default autosave threshold based on repository implementation

[Felix Meschberger (JIRA)]

[ 
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 package installation, stability is more important than 
performance. The main drawback of autosave (which is why I really don't like 
it) is that it is not atomic and may leave partially installed packages behind 
which are hard to cleanup.

I would suggest to remove auto save alltogether and rather instruct users to 
use smaller packages.

> Set default autosave threshold based on repository implementation
> -
>
> Key: JCRVLT-18
> URL: https://issues.apache.org/jira/browse/JCRVLT-18
> Project: Jackrabbit FileVault
>  Issue Type: Improvement
>Reporter: Tobias Bocanegra
>Priority: Minor
>
> with jackrabbit 2.0 we had a limitation of the size of the transient space as 
> it is held in memory. in order to support large packages, the AutoSave 
> threshold is set to 1024 nodes.
> with jackrabbit 3.0 the transient space is more or less unlimited in size, 
> and we can install large packages in 1 save, which improves installation 
> atomicity.
> however, the bigger the transient size, the higher the chance for collisions 
> during installation of large packages, so saving in chunks yields to a more 
> robust installation behavior.
> suggestions:
> - autosave threshold of 0 should mean 'auto'
> - autosave threshold of -1 should mean 'never'
> - packages can provide their desired autosave threshold via properties



--
This message was sent by Atlassian JIRA
(v6.1#6144)

Re: [OT] Donation of Adobe's "File Vault" and packaging tools

[Felix Meschberger]

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 vs. direct SVN
> commits).

Since this is an existing code base: wouldn't we need proper IP-clearance [1] ?

Regards
Felix

[1] http://incubator.apache.org/ip-clearance/index.html

[jira] [Commented] (JCR-3534) Add JackrabbitSession.getValueByContentId method

[Felix Meschberger (JIRA)]

[ 
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 access token.

If that would be the case, this would be bad design. The message data must not 
be a general access token.

> A key-value list would be nice

This sounds like YAGNI -- I doubt we are going to use it. And if so, we can 
still adapt. There is just one place in the code involved which knows how to 
talk to itself

> Add JackrabbitSession.getValueByContentId method
> 
>
> Key: JCR-3534
> URL: https://issues.apache.org/jira/browse/JCR-3534
> Project: Jackrabbit Content Repository
>  Issue Type: New Feature
>  Components: jackrabbit-api, jackrabbit-core
>Affects Versions: 2.6
>Reporter: Felix Meschberger
> Attachments: JCR-3534.patch
>
>
> we have a couple of use cases, where we would like to leverage the global 
> data store to prevent sending around and copying around large binary data 
> unnecessarily: We have two separate Jackrabbit instances configured to use 
> the same DataStore (for the sake of this discussion assume we have the 
> problems of concurrent access and garbage collection under control). When 
> sending content from one instance to the other instance we don't want to send 
> potentially large binary data (e.g. video files) if not needed.
> The idea is for the sender to just send the content identity from 
> JackrabbitValue.getContentIdentity(). The receiver would then check whether 
> the such content already exists and would reuse if so:
> String ci = contentIdentity_from_sender;
> try {
> Value v = session.getValueByContentIdentity(ci);
> Property p = targetNode.setProperty(propName, v);
> } catch (ItemNotFoundException ie) {
> // unknown or invalid content Identity
> } catch (RepositoryException re) {
> // some other exception
> }
> Thus the proposed JackrabbitSession.getValueByContentIdentity(String) method 
> would allow for round tripping the JackrabbitValue.getContentIdentity() 
> preventing superfluous binary data copying and moving. 
> See also the dev@ thread 
> http://jackrabbit.markmail.org/thread/gedk5jsrp6offkhi

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (JCR-3534) Add JackrabbitSession.getValueByContentId method

[Felix Meschberger (JIRA)]

[ 
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/support, the message should readable, for example 
> JSON or an URL. Example (shortened)

This sounds like the old mantra in the XML-days: Everything had to be XML, bla, 
bla, bla. Please just keep this simple and don't overexagerate. Having a string 
of colon separated values (if the value is structured in some way) is more that 
enough. Otherwise you incurr the price of parsing JSON ... Not worth it IMHO.

> Having expiry and encrypting the identifier would prevent further damage in 
> case the BinaryReferenceMessage leaks.

What is the problem with this message leaking as opposed to the actual data 
leaking which would be transported over the same channel completely unencrypted 
? Again, this sounds like over-engineering to me.

We should leave data protection to the transport layer (e.g. SSL) and just care 
to make sure that a data reference cannot be made up by an attacker (in the 
sense of "try to find out whether a document exists").

> Add JackrabbitSession.getValueByContentId method
> 
>
> Key: JCR-3534
> URL: https://issues.apache.org/jira/browse/JCR-3534
> Project: Jackrabbit Content Repository
>  Issue Type: New Feature
>  Components: jackrabbit-api, jackrabbit-core
>Affects Versions: 2.6
>Reporter: Felix Meschberger
> Attachments: JCR-3534.patch
>
>
> we have a couple of use cases, where we would like to leverage the global 
> data store to prevent sending around and copying around large binary data 
> unnecessarily: We have two separate Jackrabbit instances configured to use 
> the same DataStore (for the sake of this discussion assume we have the 
> problems of concurrent access and garbage collection under control). When 
> sending content from one instance to the other instance we don't want to send 
> potentially large binary data (e.g. video files) if not needed.
> The idea is for the sender to just send the content identity from 
> JackrabbitValue.getContentIdentity(). The receiver would then check whether 
> the such content already exists and would reuse if so:
> String ci = contentIdentity_from_sender;
> try {
> Value v = session.getValueByContentIdentity(ci);
> Property p = targetNode.setProperty(propName, v);
> } catch (ItemNotFoundException ie) {
> // unknown or invalid content Identity
> } catch (RepositoryException re) {
> // some other exception
> }
> Thus the proposed JackrabbitSession.getValueByContentIdentity(String) method 
> would allow for round tripping the JackrabbitValue.getContentIdentity() 
> preventing superfluous binary data copying and moving. 
> See also the dev@ thread 
> http://jackrabbit.markmail.org/thread/gedk5jsrp6offkhi

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (JCR-3534) Add JackrabbitSession.getValueByContentId method

[Felix Meschberger (JIRA)]

[ 
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 custom Binary implementation, we could also fail early when trying 
to create that instance: If the content Id cannot be resolved to a valid entry, 
the Binary object cannot be created and thus there is no need to call 
createValue(Binary) at all.

> Add JackrabbitSession.getValueByContentId method
> 
>
> Key: JCR-3534
> URL: https://issues.apache.org/jira/browse/JCR-3534
> Project: Jackrabbit Content Repository
>  Issue Type: New Feature
>  Components: jackrabbit-api, jackrabbit-core
>Affects Versions: 2.6
>    Reporter: Felix Meschberger
> Attachments: JCR-3534.patch
>
>
> we have a couple of use cases, where we would like to leverage the global 
> data store to prevent sending around and copying around large binary data 
> unnecessarily: We have two separate Jackrabbit instances configured to use 
> the same DataStore (for the sake of this discussion assume we have the 
> problems of concurrent access and garbage collection under control). When 
> sending content from one instance to the other instance we don't want to send 
> potentially large binary data (e.g. video files) if not needed.
> The idea is for the sender to just send the content identity from 
> JackrabbitValue.getContentIdentity(). The receiver would then check whether 
> the such content already exists and would reuse if so:
> String ci = contentIdentity_from_sender;
> try {
> Value v = session.getValueByContentIdentity(ci);
> Property p = targetNode.setProperty(propName, v);
> } catch (ItemNotFoundException ie) {
> // unknown or invalid content Identity
> } catch (RepositoryException re) {
> // some other exception
> }
> Thus the proposed JackrabbitSession.getValueByContentIdentity(String) method 
> would allow for round tripping the JackrabbitValue.getContentIdentity() 
> preventing superfluous binary data copying and moving. 
> See also the dev@ thread 
> http://jackrabbit.markmail.org/thread/gedk5jsrp6offkhi

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (JCR-3534) Add JackrabbitSession.getValueByContentId method

[Felix Meschberger (JIRA)]

[ 
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(String, PropertyType.BINARY)

Some thought on this: The implementation must make sure to (a) properly 
identify the hashed/signed/whatever value as being an identifier (no false 
positives or negatives!) and (b) reject identifiers for which there is no data 
store entry.

> Add JackrabbitSession.getValueByContentId method
> 
>
> Key: JCR-3534
> URL: https://issues.apache.org/jira/browse/JCR-3534
> Project: Jackrabbit Content Repository
>  Issue Type: New Feature
>  Components: jackrabbit-api, jackrabbit-core
>Affects Versions: 2.6
>    Reporter: Felix Meschberger
> Attachments: JCR-3534.patch
>
>
> we have a couple of use cases, where we would like to leverage the global 
> data store to prevent sending around and copying around large binary data 
> unnecessarily: We have two separate Jackrabbit instances configured to use 
> the same DataStore (for the sake of this discussion assume we have the 
> problems of concurrent access and garbage collection under control). When 
> sending content from one instance to the other instance we don't want to send 
> potentially large binary data (e.g. video files) if not needed.
> The idea is for the sender to just send the content identity from 
> JackrabbitValue.getContentIdentity(). The receiver would then check whether 
> the such content already exists and would reuse if so:
> String ci = contentIdentity_from_sender;
> try {
> Value v = session.getValueByContentIdentity(ci);
> Property p = targetNode.setProperty(propName, v);
> } catch (ItemNotFoundException ie) {
> // unknown or invalid content Identity
> } catch (RepositoryException re) {
> // some other exception
> }
> Thus the proposed JackrabbitSession.getValueByContentIdentity(String) method 
> would allow for round tripping the JackrabbitValue.getContentIdentity() 
> preventing superfluous binary data copying and moving. 
> See also the dev@ thread 
> http://jackrabbit.markmail.org/thread/gedk5jsrp6offkhi

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (JCR-3534) Add JackrabbitSession.getValueByContentId method

[Felix Meschberger (JIRA)]

[ 
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

I agree with Jukka: The user id cannot be part of this transaction because 
there is no reason to assume that to be the same. Even if the "name" is the 
same the actual entity represented by the name need not be the same. This is 
essentially the same issue that NFS is faced with the numeric user and group 
IDs.

But: we also need a way to inject that value through some public API such as 
the ValueFactory or some other means. Assuming RMI or Davex is not the  going 
to work because we have two separate systems where the data is extracted 
through the JackrabbitValue.getContentIdentifier() (or some new API) method, 
serialized in a custom way and then reinjected through some new API (or the 
ValueFactory if that can differentiate between a "message" binary and a real 
binary !).

Re. Future Proof

Angela is quite right: It is essential, that whatever mechanism we implement 
for Jackrabbit 2 should also be available for Oak.

> Add JackrabbitSession.getValueByContentId method
> 
>
> Key: JCR-3534
> URL: https://issues.apache.org/jira/browse/JCR-3534
> Project: Jackrabbit Content Repository
>  Issue Type: New Feature
>  Components: jackrabbit-api, jackrabbit-core
>Affects Versions: 2.6
>Reporter: Felix Meschberger
> Attachments: JCR-3534.patch
>
>
> we have a couple of use cases, where we would like to leverage the global 
> data store to prevent sending around and copying around large binary data 
> unnecessarily: We have two separate Jackrabbit instances configured to use 
> the same DataStore (for the sake of this discussion assume we have the 
> problems of concurrent access and garbage collection under control). When 
> sending content from one instance to the other instance we don't want to send 
> potentially large binary data (e.g. video files) if not needed.
> The idea is for the sender to just send the content identity from 
> JackrabbitValue.getContentIdentity(). The receiver would then check whether 
> the such content already exists and would reuse if so:
> String ci = contentIdentity_from_sender;
> try {
> Value v = session.getValueByContentIdentity(ci);
> Property p = targetNode.setProperty(propName, v);
> } catch (ItemNotFoundException ie) {
> // unknown or invalid content Identity
> } catch (RepositoryException re) {
> // some other exception
> }
> Thus the proposed JackrabbitSession.getValueByContentIdentity(String) method 
> would allow for round tripping the JackrabbitValue.getContentIdentity() 
> preventing superfluous binary data copying and moving. 
> See also the dev@ thread 
> http://jackrabbit.markmail.org/thread/gedk5jsrp6offkhi

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (JCR-3534) Add JackrabbitSession.getValueByContentId method

[Felix Meschberger (JIRA)]

[ 
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 enough to justify the leak in the abstraction

well, copying lots of 20MB binaries ? instead of lots of 50 character strings ? 
Do the math ;-)

The abstraction already leaked with the JackrabbitValue.getContentIdentitiy 
method (ok, that would be the broken window ;-) ).

> Add JackrabbitSession.getValueByContentId method
> 
>
> Key: JCR-3534
> URL: https://issues.apache.org/jira/browse/JCR-3534
> Project: Jackrabbit Content Repository
>  Issue Type: New Feature
>  Components: jackrabbit-api, jackrabbit-core
>Affects Versions: 2.6
>    Reporter: Felix Meschberger
> Attachments: JCR-3534.patch
>
>
> we have a couple of use cases, where we would like to leverage the global 
> data store to prevent sending around and copying around large binary data 
> unnecessarily: We have two separate Jackrabbit instances configured to use 
> the same DataStore (for the sake of this discussion assume we have the 
> problems of concurrent access and garbage collection under control). When 
> sending content from one instance to the other instance we don't want to send 
> potentially large binary data (e.g. video files) if not needed.
> The idea is for the sender to just send the content identity from 
> JackrabbitValue.getContentIdentity(). The receiver would then check whether 
> the such content already exists and would reuse if so:
> String ci = contentIdentity_from_sender;
> try {
> Value v = session.getValueByContentIdentity(ci);
> Property p = targetNode.setProperty(propName, v);
> } catch (ItemNotFoundException ie) {
> // unknown or invalid content Identity
> } catch (RepositoryException re) {
> // some other exception
> }
> Thus the proposed JackrabbitSession.getValueByContentIdentity(String) method 
> would allow for round tripping the JackrabbitValue.getContentIdentity() 
> preventing superfluous binary data copying and moving. 
> See also the dev@ thread 
> http://jackrabbit.markmail.org/thread/gedk5jsrp6offkhi

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (JCR-3534) Add JackrabbitSession.getValueByContentId method

[Felix Meschberger (JIRA)]

[ 
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() method wouldn't work with Oak

So JackrabbitValue.getContentIdentifier will not be supported in Oak, either ?

> I'd adjust the deployment configuration if you want to make those 
> repositories share data more intimately.

How if clustering is not an option ?

Consider for example, I have an author box and a publish box. For various 
reasons both share the same Data Store. The straight forward approach to send 
binaries from the author box to the publish box would be to extract the binary 
from the Data Store on the author box and push it back in to the Data Store on 
the publish box, just for the Data Store to realize the binary is actually the 
same. On the reading side we can retrieve an identifier 
(JackrabbitValue.getContentIdentifier). I just need a way to reuse the binary 
data referred to by that content Identifier on the publish side.

> Add JackrabbitSession.getValueByContentId method
> 
>
> Key: JCR-3534
> URL: https://issues.apache.org/jira/browse/JCR-3534
> Project: Jackrabbit Content Repository
>  Issue Type: New Feature
>  Components: jackrabbit-api, jackrabbit-core
>Affects Versions: 2.6
>Reporter: Felix Meschberger
> Attachments: JCR-3534.patch
>
>
> we have a couple of use cases, where we would like to leverage the global 
> data store to prevent sending around and copying around large binary data 
> unnecessarily: We have two separate Jackrabbit instances configured to use 
> the same DataStore (for the sake of this discussion assume we have the 
> problems of concurrent access and garbage collection under control). When 
> sending content from one instance to the other instance we don't want to send 
> potentially large binary data (e.g. video files) if not needed.
> The idea is for the sender to just send the content identity from 
> JackrabbitValue.getContentIdentity(). The receiver would then check whether 
> the such content already exists and would reuse if so:
> String ci = contentIdentity_from_sender;
> try {
> Value v = session.getValueByContentIdentity(ci);
> Property p = targetNode.setProperty(propName, v);
> } catch (ItemNotFoundException ie) {
> // unknown or invalid content Identity
> } catch (RepositoryException re) {
> // some other exception
> }
> Thus the proposed JackrabbitSession.getValueByContentIdentity(String) method 
> would allow for round tripping the JackrabbitValue.getContentIdentity() 
> preventing superfluous binary data copying and moving. 
> See also the dev@ thread 
> http://jackrabbit.markmail.org/thread/gedk5jsrp6offkhi

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (JCR-3534) Add JackrabbitSession.getValueByContentId method

[Felix Meschberger (JIRA)]

[ 
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 all: I have two separate systems (separate 
JVMs and  no clustering but shared data store) involved. So a Binary object 
from one system cannot be used on the other system without serializing and 
deserializing it.

My proposal uses the data store identity as the serialization mechanism and 
uses the new JackrabbitSesssion.getValueByContentIdentity as the 
deserialization mechanism.

Another option would be to have such a method on a new JackrabbitValueFactory 
class. But since we have a content identifier and want to get at content, we 
need some level of access control. So we need that access control in the 
JackrabbitValueFactory which would be the only method in the 
JackrabbitValueFactory which employs access control to create a value


> Add JackrabbitSession.getValueByContentId method
> 
>
> Key: JCR-3534
> URL: https://issues.apache.org/jira/browse/JCR-3534
> Project: Jackrabbit Content Repository
>  Issue Type: New Feature
>  Components: jackrabbit-api, jackrabbit-core
>Affects Versions: 2.6
>    Reporter: Felix Meschberger
> Attachments: JCR-3534.patch
>
>
> we have a couple of use cases, where we would like to leverage the global 
> data store to prevent sending around and copying around large binary data 
> unnecessarily: We have two separate Jackrabbit instances configured to use 
> the same DataStore (for the sake of this discussion assume we have the 
> problems of concurrent access and garbage collection under control). When 
> sending content from one instance to the other instance we don't want to send 
> potentially large binary data (e.g. video files) if not needed.
> The idea is for the sender to just send the content identity from 
> JackrabbitValue.getContentIdentity(). The receiver would then check whether 
> the such content already exists and would reuse if so:
> String ci = contentIdentity_from_sender;
> try {
> Value v = session.getValueByContentIdentity(ci);
> Property p = targetNode.setProperty(propName, v);
> } catch (ItemNotFoundException ie) {
> // unknown or invalid content Identity
> } catch (RepositoryException re) {
> // some other exception
> }
> Thus the proposed JackrabbitSession.getValueByContentIdentity(String) method 
> would allow for round tripping the JackrabbitValue.getContentIdentity() 
> preventing superfluous binary data copying and moving. 
> See also the dev@ thread 
> http://jackrabbit.markmail.org/thread/gedk5jsrp6offkhi

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Updated] (JCR-3534) Add JackrabbitSession.getValueByContentId method

[Felix Meschberger (JIRA)]

 [ 
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: 2.6

> Add JackrabbitSession.getValueByContentId method
> 
>
> Key: JCR-3534
> URL: https://issues.apache.org/jira/browse/JCR-3534
> Project: Jackrabbit Content Repository
>  Issue Type: New Feature
>  Components: jackrabbit-api, jackrabbit-core
>Affects Versions: 2.6
>    Reporter: Felix Meschberger
> Attachments: JCR-3534.patch
>
>
> we have a couple of use cases, where we would like to leverage the global 
> data store to prevent sending around and copying around large binary data 
> unnecessarily: We have two separate Jackrabbit instances configured to use 
> the same DataStore (for the sake of this discussion assume we have the 
> problems of concurrent access and garbage collection under control). When 
> sending content from one instance to the other instance we don't want to send 
> potentially large binary data (e.g. video files) if not needed.
> The idea is for the sender to just send the content identity from 
> JackrabbitValue.getContentIdentity(). The receiver would then check whether 
> the such content already exists and would reuse if so:
> String ci = contentIdentity_from_sender;
> try {
> Value v = session.getValueByContentIdentity(ci);
> Property p = targetNode.setProperty(propName, v);
> } catch (ItemNotFoundException ie) {
> // unknown or invalid content Identity
> } catch (RepositoryException re) {
> // some other exception
> }
> Thus the proposed JackrabbitSession.getValueByContentIdentity(String) method 
> would allow for round tripping the JackrabbitValue.getContentIdentity() 
> preventing superfluous binary data copying and moving. 
> See also the dev@ thread 
> http://jackrabbit.markmail.org/thread/gedk5jsrp6offkhi

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

Re: Getting a value by its data identifier

[Felix Meschberger]

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 would like to leverage the global 
> data store to prevent sending around and copying around large binary data 
> unnecessarily: We have two separate Jackrabbit instances configured to use 
> the same DataStore (for the sake of this discussion assume we have the 
> problems of concurrent access and garbage collection under control). When 
> sending content from one instance to the other instance we don't want to send 
> potentially large binary data (e.g. video files) if not needed.
> 
> The idea is for the sender to just send the content identity from 
> JackrabbitValue.getContentIdentity(). The receiver would then check whether 
> the such content already exists and would reuse if so:
> 
>  String ci = contentIdentity_from_sender;
>  try {
>Value v = session.getValueByContentIdentity(ci);
>Property p = targetNode.setProperty(propName, v);
>  } catch (ItemNotFoundException ie) {
>// unknown or invalid content Identity
>  } catch (RepositoryException re) {
>// some other exception
>  }
> 
> Thus the proposed JackrabbitSession.getValueByContentIdentity(String) method 
> would allow for round tripping the JackrabbitValue.getContentIdentity() 
> preventing 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 | Principal Scientist | Adobe
> 
> 
> 
> 
> 
> 
> 


--
Felix Meschberger | Principal Scientist | Adobe

[jira] [Updated] (JCR-3534) Add JackrabbitSession.getValueByContentId method

[Felix Meschberger (JIRA)]

 [ 
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 its ID I converted one method from 
InternalValue from package private to public since the 
InternvalValue.create(DataStore, String) method cannot be used: The 
getContentIdentifier method does not return the store prefix required by the 
create(DataStore, String) method. Also the create method does not validate the 
existence of a data store entry for the provided identifier.

> Add JackrabbitSession.getValueByContentId method
> 
>
> Key: JCR-3534
> URL: https://issues.apache.org/jira/browse/JCR-3534
> Project: Jackrabbit Content Repository
>  Issue Type: New Feature
>    Reporter: Felix Meschberger
> Attachments: JCR-3534.patch
>
>
> we have a couple of use cases, where we would like to leverage the global 
> data store to prevent sending around and copying around large binary data 
> unnecessarily: We have two separate Jackrabbit instances configured to use 
> the same DataStore (for the sake of this discussion assume we have the 
> problems of concurrent access and garbage collection under control). When 
> sending content from one instance to the other instance we don't want to send 
> potentially large binary data (e.g. video files) if not needed.
> The idea is for the sender to just send the content identity from 
> JackrabbitValue.getContentIdentity(). The receiver would then check whether 
> the such content already exists and would reuse if so:
> String ci = contentIdentity_from_sender;
> try {
> Value v = session.getValueByContentIdentity(ci);
> Property p = targetNode.setProperty(propName, v);
> } catch (ItemNotFoundException ie) {
> // unknown or invalid content Identity
> } catch (RepositoryException re) {
> // some other exception
> }
> Thus the proposed JackrabbitSession.getValueByContentIdentity(String) method 
> would allow for round tripping the JackrabbitValue.getContentIdentity() 
> preventing superfluous binary data copying and moving. 
> See also the dev@ thread 
> http://jackrabbit.markmail.org/thread/gedk5jsrp6offkhi

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Created] (JCR-3534) Add JackrabbitSession.getValueByContentId method

[Felix Meschberger (JIRA)]

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
  Issue Type: New Feature
Reporter: Felix Meschberger


we have a couple of use cases, where we would like to leverage the global data 
store to prevent sending around and copying around large binary data 
unnecessarily: We have two separate Jackrabbit instances configured to use the 
same DataStore (for the sake of this discussion assume we have the problems of 
concurrent access and garbage collection under control). When sending content 
from one instance to the other instance we don't want to send potentially large 
binary data (e.g. video files) if not needed.

The idea is for the sender to just send the content identity from 
JackrabbitValue.getContentIdentity(). The receiver would then check whether the 
such content already exists and would reuse if so:

String ci = contentIdentity_from_sender;
try {
Value v = session.getValueByContentIdentity(ci);
Property p = targetNode.setProperty(propName, v);
} catch (ItemNotFoundException ie) {
// unknown or invalid content Identity
} catch (RepositoryException re) {
// some other exception
}

Thus the proposed JackrabbitSession.getValueByContentIdentity(String) method 
would allow for round tripping the JackrabbitValue.getContentIdentity() 
preventing superfluous binary data copying and moving. 

See also the dev@ thread http://jackrabbit.markmail.org/thread/gedk5jsrp6offkhi

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

Re: Getting a value by its data identifier

[Felix Meschberger]

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() 
>> preventing superfluous binary data copying and moving.
> 
> The idea sounds good to me :-) (Disclaimer: discussed this with Felix f2f 
> before)
> 
>> Questions:
>> 
>> (c) Can we and if yes, how can we control access ?
> 
> It's a bit tricky, and I think the best way to do it is:
> - by default no access at all (getValueByContentIdentity() returns null aka 
> not found)

I would prefer a SecurityException, but JCR has a notion of "no access looks 
the same as non-existing", so an ItemNotFoundException would probably be thrown 
in this case (due to JCR throwing an exception if something does not exist 
instead of just returning null).

> - have a special privilege for this feature, that you only want to enable for 
> users that need this feature
> - because such a repository-wide optimization feature generally does require 
> a user with wide permissions

+1

We could use a repository level permission like we have to workspace creation.

> - nice to have: avoid that the content ID is a hash of the binary, so that an 
> attacker (who already go the above privilege) still cannot infer existence of 
> a binary he knows; but then he might have enough read & write access already, 
> as a user with that permission is likely to have broad rights, as for copying 
> things over from one instance to another requires that

We don't do such "security by obscurity" things for regular path and node ID 
acces. So we might not want to try it here. Rather we should provide proper 
access control on access.

> 
>> (d) What else ?
> 
> This is practically only about Binaries and the FileDataStore, but the 
> JackrabbitValue.getContentIdentity() is generic across all value types. If 
> there might be such a store for other properties in the future, the content 
> id must uniquely identify that store (e.g. value type) as well.

I would expect such a content identity to be "globally unique" and internally 
handled by the repository such that roundtripping between getContentIdentity 
and getValueByContentIdentity can be guaranteed (provided access control allows 
for it.

Regards
Felix

> 
> Cheers,
> Alex
> 
> 


--
Felix Meschberger | Principal Scientist | Adobe

Re: Getting a value by its data identifier

[Felix Meschberger]

Hi,

I think there really are two sides to the story:

(a) getting an ID
(b) getting the data for that ID

We may or may not be able -- on a large scale -- to prevent (a). After all 
"getting an ID" might just be the result of wold guessing and doing a brute 
force attack.

We have to be able to limit (b): While restricting to "admin" sessions might be 
an option, I think that is not the right way to do it. I tend to agree with 
AlexK that a permission might be the way to do it. The problematic thing really 
is that permission checking is hooked to a repository path (and thus related to 
an Item) whereas here we don't have an item: The DataStore BLOB does not know 
where it belongs to -- and in a shared DataStore setup, there might not even be 
an "owner" property.

In short: forget about (a). For(b) use a custom permission on / to grant access 
to the new method (denied by default, of course).

Regards
Felix

Am 12.03.2013 um 16:09 schrieb Thomas Mueller:

> Hi,
> 
>> (a) Would such a method technically be possible (preventing actual large
>> binary data copy !) ?
> 
> Yes I think it's possible. Would this be needed for Oak or Jackrabbit 2.x
> or both?
> 
>> (c) Can we and if yes, how can we control access ?
> 
> Currently the content identifier is the content hash (SHA-1), so there is
> no risk of "enumeration" or "scanning" attack (not sure what is the right
> word for this - where the attacker blindly tries out many possible ids in
> the hope to find one).
> 
> One risk is that an attacker can "prove" a certain document is stored in
> the repository, where the attacker already has the document or at least
> knows the hash code. For example he could prove the "wikileaks file x" is
> stored in the repository, which might be a problem if possession of the
> "wikileaks file x" is illegal. Not sure if we need protection against
> that; if yes, we might only allow this method to be called for admin
> 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 a bigger risk. One way to protect
> against that might be to encrypt the SHA-1 hash code with a
> repository-wide, configurable "private key" or so.
> 
> Regards,
> Thomas
> 


--
Felix Meschberger | Principal Scientist | Adobe

Getting a value by its data identifier

[Felix Meschberger]

Hi all

we have a couple of use cases, where we would like to leverage the global data 
store to prevent sending around and copying around large binary data 
unnecessarily: We have two separate Jackrabbit instances configured to use the 
same DataStore (for the sake of this discussion assume we have the problems of 
concurrent access and garbage collection under control). When sending content 
from one instance to the other instance we don't want to send potentially large 
binary data (e.g. video files) if not needed.

The idea is for the sender to just send the content identity from 
JackrabbitValue.getContentIdentity(). The receiver would then check whether the 
such content already exists and would reuse if so:

  String ci = contentIdentity_from_sender;
  try {
Value v = session.getValueByContentIdentity(ci);
Property p = targetNode.setProperty(propName, v);
  } catch (ItemNotFoundException ie) {
// unknown or invalid content Identity
  } catch (RepositoryException re) {
// some other exception
  }

Thus the proposed JackrabbitSession.getValueByContentIdentity(String) method 
would allow for round tripping the JackrabbitValue.getContentIdentity() 
preventing 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 | Principal Scientist | Adobe

Re: New Jackrabbit committer: Cédric Damioli

[Felix Meschberger]

Welcome and Congratulations !

Regards
Felix

Am 20.02.2013 um 15:44 schrieb Michael Dürig:

> Hi,
> 
> Please welcome Cédric Damioli as a new committer and PMC member of
> the Apache Jackrabbit project. The Jackrabbit PMC recently decided to
> offer Cédric committership 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, Cédric!
> 
> Michael
> 


--
Felix Meschberger | Principal Scientist | Adobe

Re: New Jackrabbit committer: Tommaso Teofili

[Felix Meschberger]

Welcome and Congratulations !

Regards
Felix

Am 20.02.2013 um 15:43 schrieb Michael Dürig:

> Hi,
> 
> Please welcome Tommaso Teofili as a new committer and PMC member of
> the Apache Jackrabbit project. The Jackrabbit PMC recently decided to
> offer Tommaso committership 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

[jira] [Commented] (JCR-3489) enhance get/set Property value access, expanding the supported types set

[Felix Meschberger (JIRA)]

[ 
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 based on the Adaptable interface with the 
ValueMap is only a secondary benefit of the Resource API we did to abstract the 
complex JCR API with checked exceptions into a simpler, easier to use API which 
also allows for much simpler and easier extension by other implementations.

I seriously doubt our Sling implementation will be changed to use this new 
functionality because our implementation exists and is proven and is embedded 
in a larger context (Adaptable with AdapterFactory).

> enhance get/set Property value access, expanding the supported types set
> 
>
> Key: JCR-3489
> URL: https://issues.apache.org/jira/browse/JCR-3489
> Project: Jackrabbit Content Repository
>  Issue Type: Improvement
>  Components: jackrabbit-jcr-commons
>Affects Versions: 2.5.2
>Reporter: Simone Tripodi
>Priority: Minor
> Fix For: 2.6
>
> Attachments: JCR-3489.patch
>
>
> The idea is having a small EDSL that simplifies the access to {{Property}} 
> value, so rather than coding the following:
> {code}
> Property property = ...;
> boolean oldValue = property.getBoolean();
> boolean newValue = !oldValue;
> property.setValue(newValue);
> {code}
> it could be simplified specifying wich type the users are interested on:
> {code}
> PropertyAccessors propertiesAccessor = ...;
> boolean oldValue = propertiesAccessor.get(property).to(boolean.class);
> boolean newValue = !oldValue;
> propertiesAccessor.set(newValue).to(property);
> {code}
> where {{PropertiesAccessor}} is the delegated to handle right types handling. 
> By default it supports default {{Property}} value types, but it could be 
> extended.
> It could happen also that users would like to support a larger set of types, 
> maybe performing conversions to/from default {{Property}} types, so rather 
> than inserting the custom code in the app when required, they could  use the 
> {{PropertiesAccessor}}; they first need to register the Accessor 
> implementation to (un)bind the type:
> {code}
> propertiesAccessor.handle(URI.class).with(new PropertyAccessor() {
> @Override
> public void set(URI value, Property target) throws 
> ValueFormatException, RepositoryException {
> // ...
> }
> @Override
> public URI get(Property property) throws ValueFormatException, 
> RepositoryException {
> // TODO ...
> return null;
> }
> });
> {code}
> so they can use the accessor via the {{PropertiesAccessor}}:
> {code}
> URI oldValue = propertiesAccessor.get(property).to(URI.class);
> URI newValue = URI.create("http://jackrabbit.apache.org/";);
> propertiesAccessor.set(newValue).to(property);
> {code}
> Patch coming soon!

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (JCR-3465) JcrUtils.getOrCreateByPath() creates a whole subtree instead of a single branch

[Felix Meschberger (JIRA)]

[ 
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 the JavaDoc support for "a/b/../../c/d../../e/f" is not 
implied. In fact I even consider this an unexpected side effect.

> JcrUtils.getOrCreateByPath() creates a whole subtree instead of a single 
> branch
> ---
>
> Key: JCR-3465
> URL: https://issues.apache.org/jira/browse/JCR-3465
> Project: Jackrabbit Content Repository
>  Issue Type: Bug
>Reporter: Michael Dürig
>Priority: Minor
>
> Given a leaf node n,
> JcrUtils.getOrCreateByPath(n, "a/b/../../c/d/../../e/f", false, null, null, 
> true);
> will result in paths a/b, c/d and e/f being added to n where I'd only expect 
> the path e/f.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

Re: New Jackrabbit committer: Philipp Marx

[Felix Meschberger]

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 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, Philipp!
> 
> Michael

Re: New Jackrabbit committer: Randall Hauch

[Felix Meschberger]

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 project. The Jackrabbit PMC recently decided to
> offer Randall committership 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, Randall!
> 
> Michael
> 

Re: New Jackrabbit committer: Chetan Mehrotra

[Felix Meschberger]

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 committership 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, Chetan!
> 
> Michael
> 

[jira] [Commented] (JCR-3350) Easy-to-use utility class for adding ACEs to nodes

[Felix Meschberger (JIRA)]

[ 
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 the RepositoryException inside a generic RuntimeException. This 
makes handling unduly hard and inside a Jackrabbit class, it is probably 
appropriate to have RepositoryExceptions thrown. But those should be documented
* Is it required to check for the existence of the item first ? In other words, 
would setting the ACL fail if the item would not exist ? What if the item is a 
property ?
* I would get rid of the autoSave flag and just document this method does not 
save or rollback at all.

> Easy-to-use utility class for adding ACEs to nodes
> --
>
> Key: JCR-3350
> URL: https://issues.apache.org/jira/browse/JCR-3350
> Project: Jackrabbit Content Repository
>  Issue Type: Improvement
>  Components: jackrabbit-jcr-commons
>Reporter: Jeff Young
>Assignee: angela
>  Labels: newbie, patch
> Attachments: AccessControlUtils.java, 
> JCR-3350_-_Easy-to-use_utility_class_for_adding_ACEs_to_nodes.patch
>
>
> There should be any easy (one-line) method for adding an ACE to a node in a 
> repo supporting resource-based ACLs.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

Re: time for JDK 1.6?

[Felix Meschberger]

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 
essentially no more.

On the other hand: In Sling we have setup the Codehaus Animal Sniffer plugin to 
verify Java 5 API use only and fail the build otherwise.

Regards
Felix


> 
> But it makes me wonder whether it makes sense to use 1.6 in OAK, but 1.5 
> in Jackrabbit (given the fact that we use subprojects from jackrabbit, 
> such as -tests and -commons).
> 
> Best regards, Julian

Re: New Jackrabbit PMC chair

[Felix Meschberger]

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 all,
>> 
>> After 5+ years as the chairman of the Jackrabbit PMC, it was time for
>> me to pass that task to someone else. Thanks, everyone, for the smooth
>> ride!
>> 
>> The PMC has unanimously selected Michael Dürig as my successor and in
>> their meeting yesterday the ASF board ratified the change. I think
>> he'll be an excellent chairman for Jackrabbit.
>> 
>> Please join me in welcoming and supporting Michael in his new role!
>> 
>> PS. In case someone's wondering, more details about the PMC chair role
>> can be found at [1].
>> 
>> [1] http://www.apache.org/foundation/how-it-works.html#pmc-chair
>> 
>> BR,
>> 
>> Jukka Zitting
> 

Re: Developed jackrabbit-webdav client for Android

[Felix Meschberger]

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 against the SVN trunk (as opposed to the dated 
2.2.5 version you are currently using). And while attaching the patch, you 
should make sure to tick the "Granite license..." checkmark.

Regards
Felix

Am 12.04.2012 um 18:13 schrieb ashimita:

Hi,

I am new to this group.

I have developed a jar using the jackrabbit-webdav (2.2.5) to work on Android 
platform. The jar was built using maven and existing pom.xml.

The source code had to modified and some of the libraries not supported by 
Android had to be replaced.

This jar (Apache license remained the same) was used by me and I have 
distributed to few other users through my personal 
blog.
  I have tested the same on Gingerbread and it worked well so far.

Kindly guide me as to how I can contribute this code to ASF.

If allowed, I would like to develop the same using the latest version of 
Jackrabbit to work with later versions of Android (Honeycomb and ICS).

Thanks and Regards,

Ashimita

[jira] [Updated] (JCR-3293) AbstractLoginModule: get rid of trust_credentials_attribute

[Felix Meschberger (Updated) (JIRA)]

 [ 
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 that the given credentials have
been preauthenticated. as already stated in the original issue this poses a 
major security issue as it leaves the
repository access untrusted.

i would like to raise those security concern again and would therefore like to 
get rid of that hack in the long run.
the suggested procedure:

- deprecate the attribute (immediately)
- log a warning if it is used (immediately)
- document how to fix code that is currently relying on that attribute
- remove support altogether for the next major release

  was:
based on JCR 2355 we added a very simplistic way to indicate to the login 
module that the given credentials have
been preauthenticated. as already stated in the original issue this poses a 
major security issue as it leaves the
repository access untrusted.

i would like to raise those security concern again and would therefore like to 
get rid of that hack in the long run.
the suggested procedure:

- deprecate the attribute (immediately)
- log a warning if it is used (immediately)
- document how to fix code that is currently relying on that attribute
- remove support altogether for the next major release


> AbstractLoginModule: get rid of trust_credentials_attribute
> ---
>
> Key: JCR-3293
> URL: https://issues.apache.org/jira/browse/JCR-3293
> Project: Jackrabbit Content Repository
>  Issue Type: Bug
>  Components: jackrabbit-core
>Affects Versions: 2.4
>Reporter: angela
>
> based on JCR-2355 we added a very simplistic way to indicate to the login 
> module that the given credentials have
> been preauthenticated. as already stated in the original issue this poses a 
> major security issue as it leaves the
> repository access untrusted.
> i would like to raise those security concern again and would therefore like 
> to get rid of that hack in the long run.
> the suggested procedure:
> - deprecate the attribute (immediately)
> - log a warning if it is used (immediately)
> - document how to fix code that is currently relying on that attribute
> - remove support altogether for the next major release

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (JCR-3294) AbstractLoginModule: get rid of trust_credentials_attribute

[Felix Meschberger (Commented) (JIRA)]

[ 
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-3293 ?

> AbstractLoginModule: get rid of trust_credentials_attribute
> ---
>
> Key: JCR-3294
> URL: https://issues.apache.org/jira/browse/JCR-3294
> Project: Jackrabbit Content Repository
>  Issue Type: Bug
>  Components: jackrabbit-core
>Affects Versions: 2.4
>Reporter: angela
>
> based on JCR 2355 we added a very simplistic way to indicate to the login 
> module that the given credentials have
> been preauthenticated. as already stated in the original issue this poses a 
> major security issue as it leaves the
> repository access untrusted.
> i would like to raise those security concern again and would therefore like 
> to get rid of that hack in the long run.
> the suggested procedure:
> - deprecate the attribute (immediately)
> - log a warning if it is used (immediately)
> - document how to fix code that is currently relying on that attribute
> - remove support altogether for the next major release

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Issue Comment Edited] (JCR-3288) ConnectionFactory.getDriverClass() should use Thread.currentThread().getContextClassLoader(); instead of Class.forName()

[Felix Meschberger (Issue Comment Edited) (JIRA)]

[ 
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:13 AM:
-

Whatever the final solution, using Class.forName(String) is *really* 
problematic in OSGi scenarios since there is some hard reference kept in the 
system preventing the class from being (garbage) collected.

So this call should be replaced in any case.

See http://blog.bjhargrave.com/2007/07/why-do-classforname-and.html and 
http://blog.bjhargrave.com/2007/09/classforname-caches-defined-class-in.html

  was (Author: fmeschbe):
Whatever the final solution, using Class.forName(String) is *really* 
problematic in OSGi scenarios since there is some hard reference kept in the 
system preventing the class from being (garbage) collected.

See http://blog.bjhargrave.com/2007/07/why-do-classforname-and.html and 
http://blog.bjhargrave.com/2007/09/classforname-caches-defined-class-in.html
  
> ConnectionFactory.getDriverClass() should use 
> Thread.currentThread().getContextClassLoader(); instead of Class.forName()
> 
>
> Key: JCR-3288
> URL: https://issues.apache.org/jira/browse/JCR-3288
> Project: Jackrabbit Content Repository
>  Issue Type: Bug
>  Components: jackrabbit-core
>Affects Versions: 2.3.3
> Environment: WXP Sun JDK 1.6.0_30 Derby database
>Reporter: Francis ANDRE
>Priority: Critical
>
> Hi
> The ConnectionFactory.getDriverClass() should use 
> Thread.currentThread().getContextClassLoader(); instead of Class.forName() 
> otherwise dynamically added jdbc drivers to the classpath are not found;
>   ClassLoader cl = Thread.currentThread().getContextClassLoader();
>   return cl.loadClass(driver);
> //return Class.forName(driver);

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (JCR-3288) ConnectionFactory.getDriverClass() should use Thread.currentThread().getContextClassLoader(); instead of Class.forName()

[Felix Meschberger (Commented) (JIRA)]

[ 
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, using Class.forName(String) is *really* 
problematic in OSGi scenarios since there is some hard reference kept in the 
system preventing the class from being (garbage) collected.

See http://blog.bjhargrave.com/2007/07/why-do-classforname-and.html and 
http://blog.bjhargrave.com/2007/09/classforname-caches-defined-class-in.html

> ConnectionFactory.getDriverClass() should use 
> Thread.currentThread().getContextClassLoader(); instead of Class.forName()
> 
>
> Key: JCR-3288
> URL: https://issues.apache.org/jira/browse/JCR-3288
> Project: Jackrabbit Content Repository
>  Issue Type: Bug
>  Components: jackrabbit-core
>Affects Versions: 2.3.3
> Environment: WXP Sun JDK 1.6.0_30 Derby database
>Reporter: Francis ANDRE
>Priority: Critical
>
> Hi
> The ConnectionFactory.getDriverClass() should use 
> Thread.currentThread().getContextClassLoader(); instead of Class.forName() 
> otherwise dynamically added jdbc drivers to the classpath are not found;
>   ClassLoader cl = Thread.currentThread().getContextClassLoader();
>   return cl.loadClass(driver);
> //return Class.forName(driver);

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

Re: Online backup

[Felix Meschberger]

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...
> 
> Right, but a backup tool is not a normal JCR client.

Ok, that makes a difference of course, thanks.

Regards
Felix

> 
>> As such a backup solution, should well be possible on-top of the JCR API
>> regardless of how the internal implementation distributes data etc., right ?
> 
> Why? The JCR API does not cover all the functionality needed to fully
> recover a repository from a backup (and offers no bulk-read or
> incremental update feature needed for fast backups), so a backup
> client in any case needs to use a lower level API.
> 
> Whether and how such an API exposes features like sharding is an issue
> we still need to sort out. It's good to remember that use cases like
> backup can be significantly affected by the design we select.
> 
> BR,
> 
> Jukka Zitting

Re: Integration Tests with TCK

[Felix Meschberger]

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 the JCR specification early in the
> process.
> 
> this will not only allow us to take conscious
> decisions regarding compliance violations but will also
> be very important to spot possible issues that will arise
> with migration of JCR applications to jackrabbit3.
> (thinking of apps like sling or cq that relying on quite
>  some jr2 implementation details that are also reflected
>  in the TCK :-).

Good point. Of course, I would be very interested to hear about such 
implementation dependencies to be able to fix them in Sling.


> 
> what do you think?

Absolutey !

I even would go a step further: A new persistence abstraction - the Mikrokernel 
API - is defined. We might even create kind of TCK for this API such that 
multiple implementation (we expect to come up over time) can be tested against 
that common TCK and the rest of Oak using the Mikrokernel can depend on the 
Mikrokernel contracts.

Regards
Felix

> 
> angela

Re: Setting up Oak (Was: [RESULT] [VOTE] Codename for the jr3 implementation effort)

[Felix Meschberger]

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
> https://issues.apache.org/jira/browse/OAK and the svn space is at
> http://svn.apache.org/repos/asf/jackrabbit/oak/ (I'll set up a Git
> mirror later today). The oak-dev@ mailing list should follow up
> shortly, see INFRA-4514 [1].
> 
> To get us started, I'll set up a basic multimodule build in oak/trunk
> along the lines of what we have in jackrabbit/trunk. As initial
> components I propose the following:
> 
>   * oak-core, for the main codebase (incl. unit tests)
>   * oak-run, for a runnable jar packaging
>   * oak-it, for integration tests
>   * oak-bench, for performance tests

If we assume a modular piece of code, just having oak-core proably goes in the 
wrong direction.

At least I would factor out anything that would be something like a plugin or 
extension API, like the Mikrokernel API itself.

Regards
Felix

> 
> We'll start building the Oak codebase under org.apache.jackrabbit.oak
> in oak-core. To avoid having to start from scratch, I propose that we
> copy the existing MK work from org.apache.jackrabbit.mk to under
> oak-core and gradually clean up and refactor relevant parts of the
> codebase to subpackages under o.a.j.oak. Other existing code from
> above the MK should probably treated similarly.
> 
> [1] https://issues.apache.org/jira/browse/INFRA-4514
> 
> BR,
> 
> Jukka Zitting

Re: [jr3] Index on randomly distributed data

[Felix Meschberger]

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 
Mikrokernel API ?

If it would be the Mikrokernel impl. itself (thus below the API), why would it 
matter to the upper layers ?

Regards
Felix

Am 06.03.2012 um 01:34 schrieb Thomas Mueller:

> Hi,
> 
> In Jackrabbit 2, we currently use a randomly generated UUID as the node
> id. For Jackrabbit 3 this is an option question. I was looking for ways to
> index randomly distributed data, but so far didn't find a solution. A
> Google query for "uuid primary key performance" gave me:
> 
> http://stackoverflow.com/questions/2365132/uuid-performance-in-mysql "At
> my job, we use UUID as PKs. What I can tell you from experience is DO NOT
> USE THEM as PKs ... It's one of those things that when you have less than
> 1000 records it;s ok, but when you have millions, it's the worst thing you
> can do. Why? Because UUID are not sequential..."
> 
> http://kccoder.com/mysql/uuid-vs-int-insert-performance/ "it takes 25
> hours to insert 15 million records into an empty UUID table"
> 
> http://www.mysqlperformanceblog.com/2007/03/13/to-uuid-or-not-to-uuid/
> "For auto_increment key load process took 1 hour 50 minutes ... For UUID
> process took over 12 hours and is still going...  So in this little case
> we have about 200 times performance difference"
> 
> I believe if we rely on an index on randomly distributed data, performance
> will degrade (factor 10 or more, depending on the repository size, the
> memory, and potentially on the number of changes). For Jackrabbit 2, to
> solve this performance problem, we can actually switch to sequential node
> ids - see JCR-2857. For Jackrabbit 3, if we use the content hash as the
> node id, then it wouldn't be possible to switch (it is not possible to
> generate sequential content hashes). With content hashes, one option is to
> make sure the index is always in memory. However, I believe we should not
> build a system that has such constraints, unless the alternative
> (sequential node ids) has problems we can not solve otherwise.
> 
> Regards,
> Thomas
> 

Re: [jr3] Tree model

[Felix Meschberger]

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 with strength in different areas 
and use cases for both ...

Regards
Felix

Re: [jr3] Tree model

[Felix Meschberger]

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.

I don't have a real test case. But assume this:

  * 50 people updating content (in different areas of the tree)
  * another 100 people reading from the repository
  * digital asset import with workflow processing (involving repository
updates, too).

Regards
Felix

Re: [jr3] Tree model

[Felix Meschberger]

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, this is not the case, and sometimes it's the exact
> opposite.

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.


> Write throughput will also decrease if data structures are
> always immutable (see above).

Not necessairily 

Regards
Felix

Re: [jr3] Tree model

[Felix Meschberger]

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 detail.

Other language are even object oriented.

> 
> * An object-oriented one for Java (to avoid serialization)

I don't think we should really care about non-object oriented programming 
languages any longer nowadays.

Regards
Felix

Re: [jr3] Tree model

[Felix Meschberger]

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 structure has many benefits
>  (for example concurrency).
> 
> * Mutable data strucutures also have benefits:
>  it avoids creating lots of garbage and a new root node
>  for each and every modification.

I don't really care for garbage: In fact Java is even better at allocating and 
cleaning up short-lived small objects than C is.

While I cannot comment on other details, I have one to this:

> * Stefan believes concurrent write operations are very important while I
> believe this will not increase write throughput as much as it complicates
> the implementation (Stefan implementations merges changes while my
> implementation does not).

As a user of the JCR API I really do care about concurrent writes. And whatever 
is done on the MK level or any level between my JCR application and persistence 
doesn't really matter as long as concurrent writes are a lot more performing 
that today, where each write blocks any other repository use

Regards
Felix

Re: [jr3] Tree model

[Felix Meschberger]

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

As has been said other places: Requiring a wrapper indicates a general issue 
with the API...

While the wrapper gets you somewhere it does not really solve the problem.

Regards
Felix

Re: [jr3] Tree model

[Felix Meschberger]

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 its parent
>  * Names are just opaque strings
>  * Leaves contain typed data (strings, numbers, binaries, etc.)
>  * Content trees are *immutable* except in specific circumstances
> (transient changes)

I like this idea (and would love to see such a data structure to replace the 
String parameters in the existig MK API drafts).

Yet, I have an issue with "Leaf extends Tree". I think this is not true in this 
case.

I understand that an abstract tree is made up of interior nodes and leaf nodes 
and so for ease of implementation etc. we have some common API (maybe empty) 
and specialized API (child (interior or leaf) nodes or properties).

  // this is anything part of a tree
  public interface TreePart {
 boolean isLeaf();
  }

  // this is a subtree of a tree
  public interface Tree extends TreePart, Map {
 ... contents is child TreeParts ...
  }

  // this is the leaf of a tree
  public interface Leaf extends TreePart, Map {
 ... contents is properties ...
  }


I don't particularly like the isLeaf() method because it is implying that the 
base interface knows about all extensions and is duplicate to "treePart 
instanceof Leaf". But in light of supporting other languages it might be 
acceptable.


Another questions: interior nodes thus don't have properties ? How would this 
map to JCR Nodes which have JCR Properties ?

Regards
Felix

Re: [jr3] Tree model

[Felix Meschberger]

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 the idea of a Tree being a Map. In fact it is so IMHO.

Regards
Felix

> 
> Regards,
> Thomas
> 
> 
> 
> 
> 
> On 2/28/12 4:08 PM, "Thomas Mueller"  wrote:
> 
>> Hi,
>> 
>> What is your use case, meaning where would this interface be used and why?
>> 
>> Regards,
>> Thomas
>> 
>> 
>> On 2/28/12 3:59 PM, "Jukka Zitting"  wrote:
>> 
>>> Hi,
>>> 
>>> [Here's me looking at lower-level details for a change.]
>>> 
>>> I was going through the prototype codebases in the sandbox, trying to
>>> come up with some clean and simple lowest-common-denominator -style
>>> interface for representing content trees. Basically a replacement for
>>> the ItemState model in current Jackrabbit.
>>> 
>>> The trouble I find with both the current Jackrabbit ItemState model
>>> and the efforts in the sandbox is that this key concept is modeled as
>>> concrete classes instead of as interfaces. Using an interface to
>>> describe and document the fundamental tree model gives us a lot of
>>> extra freedom on the implementation side (lazy loading, decoration,
>>> virtual content, etc.).
>>> 
>>> So, how should we go about constructing such an interface? I started
>>> by laying some ground rules based on concepts from the sandbox and
>>> past jr3 discussions:
>>> 
>>> * 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 its parent
>>> * Names are just opaque strings
>>> * Leaves contain typed data (strings, numbers, binaries, etc.)
>>> * Content trees are *immutable* except in specific circumstances
>>> (transient changes)
>>> 
>>> As a corollary of such a proposed design, the following features (that
>>> with a different tree model could be a part of the underlying storage
>>> model) would need to be handled as higher level constructs:
>>> 
>>> * Same-name-siblings (perhaps by name-mangling)
>>> * Namespaces and other name semantics
>>> * Ordering of child nodes (perhaps with a custom order property)
>>> * Path handling
>>> * Identifiers and references
>>> * Node types
>>> * Versioning
>>> * etc., etc.
>>> 
>>> As you can see, it's a very low-level interface I'm talking about.
>>> With that background, here's what I'm proposing:
>>> https://gist.github.com/1932695 (also included as text at the end of
>>> this message). Note that this proposal covers only the interfaces for
>>> accessing content (with a big TODO in the Leaf interface). A separate
>>> builder or factory interface will be needed for content changes in
>>> case this design is adopted.
>>> 
>>> Please criticize, as this is just a quick draft and I'm likely to miss
>>> something fairly important. I'm hoping to evolve this to something we
>>> could use as a well-documented and thought-of internal abstraction for
>>> jr3. Or, if this idea is too broken, to provoke someone to provide a
>>> good counter-proposal. :-)
>>> 
>>> BR,
>>> 
>>> Jukka Zitting
>>> 
>>> 
>>> 
>>> import java.util.Map;
>>> 
>>> /**
>>> * Trees are the key concept in a hierarchical content repository.
>>> * This interface is a low-level tree node representation that just
>>> * maps zero or more string names to corresponding child nodes.
>>> * Depending on context, a Tree instance can be interpreted as
>>> * representing just that tree node, the subtree starting at that node,
>>> * or an entire tree in case it's a root node.
>>> * 
>>> * For familiarity and easy integration with existing libraries this
>>> * interface extends the generic {@link Map} interface instead of
>>> * providing a custom alternative. Note also that this interface is
>>> * named Tree instead of something like Item or Node to avoid confusion
>>> * with the related JCR interfaces.
>>> * 
>>> *
>>> * Leaves and non-leaves
>>> * 
>>> * Normal tree nodes only contain structural information expressed as
>>> * the set of child nodes and their names. The content of a tree,
>>> expressed
>>> * in data types like strings, numbers and binaries, is stored in special
>>> * leaf nodes with no children. Such leaf nodes implement the {@link
>>> Leaf}
>>> * sub-interface and can be identified and accessed using the
>>> * {@link #isLeaf()} and {@link #asLeaf()} methods.
>>> * 
>>> * 
>>> * Note that even tough such leaf nodes are guaranteed to have no
>>> children
>>> * (i.e. {@link #isLeaf()} implies {@link #isEmpty()}), the reverse is
>>> not
>>> * necessarily true. It's possible for a non-leaf node to contain no
>>> children,
>>> * though such cases occur normally only transiently when new subtrees
>>> are
>>> * being constructed.
>>> * 
>>> *
>>> * Mutability and

Re: [jr3] Tree model

[Felix Meschberger]

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 step further and change the MK API to transfer data 
structures back and forth to prevent repeated serialization and deserialization.

Regards
Felix

Re: [jr3] Codename

[Felix Meschberger]

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 (especially not being unique enough), leaving the
> following alternatives:
> 
>[ ] Arnabu
>[ ] Blackrabbit
>[ ] Carota
>[ ] Jonsai
>[ ] Leporid
>[ ] Tapeti
>[ ] Tupaia
> 
> Let's have a quick poll on these at
> http://www.doodle.com/zpnpmcv69pfaw73f. Please pick your favorites! If
> a reasonable consensus emerges on one of the alternatives, then we'll
> simply pick that one. Otherwise we'll have a followup vote on the two
> most popular alternatives.
> 
> Note that for now this is just a codename for the jr3 implementation
> effort. Once we get close to production quality we still need to
> decide whether to promote the codename for wider use, brand the
> implementation as "Jackrabbit 3.0" like originally planned, or perhaps
> come up with a completely new name.
> 
> PS. If I missed a good alternative or one that wasn't brought up yet,
> let me know so I can add it to the poll.
> 
> BR,
> 
> Jukka Zitting

Re: [jr3] On pluggability and OSGi (Was: [jr3] Release roadmap)

[Felix Meschberger]

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 default is that it brings in a massive and
> pretty complex dependency with it. If you build your code with the
> OSGi service registry in mind, it becomes difficult to run it in any
> other environment, including in a simple JUnit test case. You're
> basically making an assumption that all your deployment environments
> will be OSGi frameworks, which dramatically reduces your potential
> user-base.
> 
> I don't want us to make that assumption. It should IMHO be possible to
> embed the repository implementation to for example an Android app, to
> a Maven plugin or a J2EE CMS without having to OSGify the entire
> application.
> 
> That doesn't mean we couldn't or shouldn't use OSGi for wiring things
> up when the repository *is* deployed to an OSGi environment. Indeed
> that's why I explicitly included those points in the roadmap. It's
> just that we shouldn't make the core architecture depend on constructs
> like ServiceTracker that don't work outside the scope of OSGi.

Hmm, ok, let me rephrase it a bit (still I have OSGi in mind and my absolute 
requirement is that JR 3 must be deployable in an OSGi framework more easily 
than JR2).

Here's my list of requirements :

  * Dependency Injection -- known to be a good thing for testing
  and supported not only by Spring but also by OSGi (Declarative
  Services and Blueprint and other non-standard ones).
  * Clear picture of configuration -- again injected à-la DI.
  * Proper separation of public API/packages and private
  implementation packages.
  * No static factories. These are a pain in standard Java but are
  dreadful in pluggable frameworks.
  * Create bundles from the start. These don't harm but allow us
  to testdrive in OSGi frameworks right away.

Regards
Felix

Re: [jr3 http api as a first class citizen]

[Felix Meschberger]

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.
>> 
>> 
>> Could you provide some examples what is not there yet?
> 
> This https://issues.apache.org/jira/browse/JCR-2003 is a pretty complete
> list.

Hmm, this reads like "remoting over HTTP". This is not really REST in my book.

Regards
Felix

> 
> 
>> For performance, the transient space should be on the client, so it
>> would be batch operations, and not directly mapping JCR methods calls,
>> right?
> 
> Not sure what exactly you mean. For saving stuff, yes, the transient
> space is on the client side and we batch them on save. But we still need
> somehow a way to map all JCR methods to PHPCR (the JCR for PHP). How
> that's done on the HTTP level doesn't really matter, as long as it's
> somehow possible.
> 
> Currently it seems that the HTTP "API" is just an afterthought and
> therefore sometimes neglected. It would be great if that would be
> different in JR3. Like in other newer approaches lately, eg. in couchdb
> (that's just the example which popped up in my mind, I'm not saying,
> that's a perfect example :))
> 
> 
>> I don't think this will be part of JCR-333, but probably another
>> standard (JSOP).
> 
> I don't see this going into JSR-333 either.
> 
> Greetings
> 
> chregu
> 
>> Regards,
>> Thomas
> 
> -- 
> Liip AG  //  Feldstrasse 133 //  CH-8004 Zurich
> Tel +41 43 500 39 81 // Mobile +41 76 561 88 60
> www.liip.ch // blog.liip.ch // GnuPG 0x0748D5FE
> 

Re: [jr3] Release roadmap

[Felix Meschberger]

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 arrange. And it's more of a guideline
> than a fixed plan, we can proceed faster on some issues if possible or
> postpone others where needed. We may even decide to drop some items
> entirely or introduce new items to the plan.

Makes sense.

As for extensibility and pluggability...

> * 0.2 - April 2012
>  * Extension model for plugging in alternative storage backends
> 
> * 0.3 - May 2012
>  * OSGi bundle packaging
> 
> * 0.4 - June 2012
>  * OSGi/Spring/etc. pluggability of extensions


IMHO extensibilty and pluggability (indexing, access control, user management 
have been mentioned) should be built into it right from the start and there 
should be a single model being used. And we should not reinvent the wheel.

Taken all together we should probably shoot for OSGi right from the start. We 
get the rest "for free":

  - Standalone Java Application and Web App using the Sling Launchpad
  - Testbed for applications and test cases
  - OSGi services being the extension model 

Hence I would go with OSGi from Day 0 and use the OSGi Service Registry as the 
mechanic for pluggability.

Regards
Felix

Re: [jr3 optional features]

[Felix Meschberger]

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 < 2000 ;-)

Yet, this might introduce an inconsistency: Create a parent with order child 
nodes. Add 1999 children which are kept ordered. Add another 2 and you loose 
ordering. Be prepared for bug reports ;-)

Regards
Felix

Re: [jr3 optional features]

[Felix Meschberger]

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 
enterprise environment ...

> 
>> shareable nodes
>> it shouldn't be hard to implement them properly when starting from
>> scratch.
> 
> In my (old) prototype they caused a rather big architectural change. I
> wouldn't support them if possible.
> 
> 
>>> node.type.management.orderable.child.nodes.supported = false
>> 
>> why? in CQ we rely on the ability to have orderable child nodes.
> 
> The problem is we want to support large child node lists, and for this
> case keeping them ordered is expensive (possible, but more complex, and
> will slow down adding/removing child nodes to such nodes by factor 2-3).
> 
> Currently, small child node lists (less than 2000 child nodes or so) are
> orderable, but large ones are not.

I understand, but we need it ;-)

> 
>> i would appreciate if XPATH was still being supported.
> 
> What about if we support a (to be defined) subset of XPATH? For example by
> converting it to SQL2.

Whatever the definition will be, chances are that a subset would be sufficient.

Yet, I would assume XPath would be internally converted to JQOM and not to 
SQL2-to-JQOM ... But this is another story, probably.

Regards
Felix


> 
> Regards,
> Thomas
> 

Re: [jr3 optional features]

[Felix Meschberger]

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.supported = true
> 
> this is something i would get rid of. i don't see the
> use case for it and it currently doesn't properly work with
> remoting as getting a node by path cannot be distinguished
> from getting the property with the same path.
> 
>> node.type.management.orderable.child.nodes.supported = false
> 
> why? in CQ we rely on the ability to have orderable child nodes.
> 
>> node.type.management.value.constraints.supported = false
> 
> i don't agree here. if we support node types we should
> also support value constraints.
> 
> regarding the descriptors with a question mark, my
> position was as follows
> 
>> node.type.management.inheritance.minimal = ? -> true
>> node.type.management.inheritance.multiple = ? -> true
>> node.type.management.overrides.supported = ? -> true
>> node.type.management.property.types = ? -> true
> 
>> query.languages = ? -> JCR-SQL2, JCR-JQOM. and i would appreciate if XPATH 
>> was still being supported.

With my Sling hat on, I would appreciate support for XPath

Regards
Felix

>> query.stored.queries.supported = ? -> i never used that. but maybe that was 
>> useful.
>> query.joins = ? -> true
>> option.query.sql.supported = ? -> depends on query.languages. rather false.
>> query.xpath.pos.index = ? -> depends on query.languages.
>> query.xpath.doc.orderable = ? -> depends on query.languages
> 
> regards
> angela

Re: [jira] [Resolved] (JCR-3237) add missing name constants for mix:title

[Felix Meschberger]

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 taking care of that as a part of cutting a release.
> Meanwhile if the package-info update is needed (for OSGi dependency
> reasons) already for the SNAPSHOT, any committer can go ahead and
> update the version.

Thanks, as long as it doesn't go unnoticed.

Regards
Felix

Re: [jira] [Resolved] (JCR-3237) add missing name constants for mix:title

[Felix Meschberger]

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.system.issuetabpanels:all-tabpanel
>  ]
> 
> Julian Reschke resolved JCR-3237.
> -
> 
>   Resolution: Fixed
>Fix Version/s: 2.6
>   2.4.1
> 
>> add missing name constants for mix:title
>> 
>> 
>>Key: JCR-3237
>>URL: https://issues.apache.org/jira/browse/JCR-3237
>>Project: Jackrabbit Content Repository
>> Issue Type: Improvement
>> Components: jackrabbit-spi-commons, JCR 2.0
>>   Affects Versions: 2.4.1, 2.6
>>   Reporter: Julian Reschke
>>   Assignee: Julian Reschke
>>   Priority: Minor
>>Fix For: 2.4.1, 2.6
>> 
>> 
> 
> 
> --
> This message is automatically generated by JIRA.
> If you think it was sent incorrectly, please contact your JIRA 
> administrators: 
> https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
> For more information on JIRA, see: http://www.atlassian.com/software/jira
> 
> 

[jira] [Commented] (JCR-3228) WebDav/DavEx remoting throws workspace missmatch exceptions when running on port 80.

[Felix Meschberger (Commented) (JIRA)]

[ 
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 the port number in the Host header. So it 
is not appropriate to expect the client to include the port number. So the 
server must cope with this situation appropriately, namely re-insert the 
default port number if required.

> WebDav/DavEx remoting throws workspace missmatch exceptions when running on 
> port 80. 
> -
>
> Key: JCR-3228
> URL: https://issues.apache.org/jira/browse/JCR-3228
> Project: Jackrabbit Content Repository
>  Issue Type: Bug
>  Components: jackrabbit-spi2dav, jackrabbit-webdav
>Affects Versions: 2.2.9
>Reporter: Timothee Maret
>
> When running on port 80, the webdav remoting shows unexpected behavior such 
> as listing incomplete folder content.
> Moreover the following exception is thrown:
> The exception I get: java.lang.IllegalArgumentException: Workspace missmatch.
> [org.apache.jackrabbit.spi2dav.IdURICache.add(IdURICache.java:60),
> org.apache.jackrabbit.spi2dav.URIResolverImpl.getItemUri(URIResolverImpl.java:129),
> org.apache.jackrabbit.spi2dav.RepositoryServiceImpl.getItemUri(RepositoryServiceImpl.java:391),
> org.apache.jackrabbit.spi2davex.RepositoryServiceImpl.getPath(RepositoryServiceImpl.java:149),
> org.apache.jackrabbit.spi2davex.RepositoryServiceImpl.getPath(RepositoryServiceImpl.java:138),
> org.apache.jackrabbit.spi2davex.RepositoryServiceImpl.getItemInfos(RepositoryServiceImpl.java:265),
> org.apache.jackrabbit.jcr2spi.state.WorkspaceItemStateFactory.createNodeState(WorkspaceItemStateFactory.java:93),
> org.apache.jackrabbit.jcr2spi.state.TransientISFactory.createNodeState(TransientISFactory.java:97),
> org.apache.jackrabbit.jcr2spi.hierarchy.NodeEntryImpl.doResolve(NodeEntryImpl.java:990),
> org.apache.jackrabbit.jcr2spi.hierarchy.HierarchyEntryImpl.resolve(HierarchyEntryImpl.java:133),
> org.apache.jackrabbit.jcr2spi.hierarchy.HierarchyEntryImpl.getItemState(HierarchyEntryImpl.java:252),
> org.apache.jackrabbit.jcr2spi.hierarchy.NodeEntryImpl.getItemState(NodeEntryImpl.java:71),
> org.apache.jackrabbit.jcr2spi.ItemManagerImpl.getItem(ItemManagerImpl.java:199),
> org.apache.jackrabbit.jcr2spi.LazyItemIterator.prefetchNext(LazyItemIterator.java:138),
> org.apache.jackrabbit.jcr2spi.LazyItemIterator.next(LazyItemIterator.java:251),
> org.apache.jackrabbit.jcr2spi.LazyItemIterator.nextNode(LazyItemIterator.java:154),
> com.adobe.drive.connector.adep.GetChildrenHandler.execute(GetChildrenHandler.java:121),
> com.adobe.drive.connector.adep.GetChildrenHandler.execute(GetChildrenHandler.java:43),
> com.adobe.drive.model.internal.synchronization.AssetSynchronizer.execute(AssetSynchronizer.java:432),
> com.adobe.drive.model.internal.synchronization.AssetSynchronizer.synchronizeStructure(AssetSynchronizer.java:352),
> com.adobe.drive.internal.data.manager.DataManager.getChildren(DataManager.java:2602),
> com.adobe.drive.internal.biz.versioncue.service.call.GetChildren$1.call(GetChildren.java:98),
> com.adobe.drive.internal.biz.versioncue.service.call.GetChildren$1.call(GetChildren.java:73),
> com.adobe.drive.model.context.Context.run(Context.java:88),
> com.adobe.drive.internal.biz.versioncue.service.call.GetChildren.executeItem(GetChildren.java:126),
> com.adobe.drive.internal.biz.versioncue.service.call.GetChildren.executeItem(GetChildren.java:50),
> com.adobe.drive.internal.biz.versioncue.service.call.VersionCueCall$1.run(VersionCueCall.java:125),
> com.adobe.drive.internal.biz.versioncue.service.call.VersionCueCall$1.run(VersionCueCall.java:119),
> com.adobe.drive.data.internal.persistence.PersistenceRunner.run(PersistenceRunner.java:119),
> com.adobe.drive.internal.biz.versioncue.service.call.VersionCueCall.execute(VersionCueCall.java:134),
> com.adobe.drive.internal.biz.versioncue.service.VersionCueService.getChildren(VersionCueService.java:269),
> com.adobe.drive.ncomm.versioncue.GetChildren.handle(GetChildren.java:59),
> com.adobe.drive.ncomm.versioncue.VersionCueRequestHandler$1.run(VersionCueRequestHandler.java:185),
> com.adobe.drive.core.internal.jobs.JobHandler$JobWrapper.run(JobHandler.java:270),
> com.adobe.drive.core.internal.jobs.JobHandler$JobWrapper.run(JobHandler.java:286),
> java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886),
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908),
> java.lang.Thread.run(Thread.java:680)]
> I have tracked this issue and actually t

Re: [jr3 microkernel] Change log consolidation

[Felix Meschberger]

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 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 ?
Because there is a conflict on the target name.

> Eg. "mv /a/b/c /a" resulting in /a/b and /a/c
No. This means moving node /a/b/c to the root with name a. But /a exists 
already.

Ok, now I understand. Thanks.

Regards
Felix


Michael

>
> Did miss(-understand) something ?
>
> Regards
> Felix

Re: [jr3 microkernel] Change log consolidation

[Felix Meschberger]

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" resulting in /a/b and /a/c 

Did miss(-understand) something ?

Regards
Felix

Re: [jr3 Microkernel] compiler settings in pom.xml

[Felix Meschberger]

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
>>> 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 fundamental concurrency tenets like for 
>> example immutable objects ... In fact it is a long-standing recommendation 
>> to strive for immutable objects.
> Which includes the whole Java collection framework: mutability around 
> every corner ready to bite...

Well, this framework is built around this --- after all a collection is here to 
be modified.

But then they knew what they did and documented it ...

Regards
Felix

Re: [jr3 Microkernel] compiler settings in pom.xml

[Felix Meschberger]

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 fundamental concurrency tenets like for example 
immutable objects ... In fact it is a long-standing recommendation to strive 
for immutable objects.

Regards
Felix

Re: [jr3 Microkernel] compiler settings in pom.xml

[Felix Meschberger]

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 of it ;)

> 
> Indeed, that's another point I've been thinking about

I am not really sure, whether we should really open this can of worms ...

I for my part I would expect JR 3 to still be easily embedded in a JVM 
(deployed in an OSGi framework running in a JVM, actually), which pretty much 
excludes anything not being compiled to Java Byte Code executable by the JVM.

Regards
Felix

Re: [jr3 Microkernel] compiler settings in pom.xml

[Felix Meschberger]

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
> 
> 
> 
> When actually _using_ a 1.5 jdk (on Mac OS X this can be done with the  
> Java Preferences tool), the maven-compiler-plugin will report 12  
> errors due to use of Java 1.6 methods.

Using the animal sniffer plugin would help, yet ...
> 
> So my question is: should we change this setting from 1.5 to 1.6  
> (which I favor) or review our code?

I agree that it is about time to abandon Java 5 ...

Regards
Felix

[jira] [Commented] (JCR-3222) Allow servlet filters to specify custom session providers

[Felix Meschberger (Commented) (JIRA)]

[ 
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's what the HttpContext.handleSecurity() method does, right? It's needs 
> to be able to take over the entire processing of a request. 

No, this is called by the Http Service before calling the servlet. The 
handleSecurity method either returns true in which case the servlet is called 
or false in which case the request is terminated and the servlet is not called.

The handleSecurity method must set up to three request attributes which are 
used to implement HttpServletRequest methods (getRemoteUser, getAuthType, 
getUserPrincipal). In addition the Sling implementation could provide the 
ResourceResolver (what we do in the Sling DavEx bundle.

The handleSecurity method could of course set the SessionProvider, too. But I 
don't like this -- special case handling affecting all but used by one only.

In addtion: unless you will be implementing a special proxy SessionProvider 
looking for the actual provider on each request, the getSessionProvider() 
method is AFAICT only called once no matter how many different SessionProviders 
are found in the request attributes... The SessionProvider is not something 
request specific but something setup specific. Hence a service and not request 
attribute.

> Allow servlet filters to specify custom session providers
> -
>
> Key: JCR-3222
> URL: https://issues.apache.org/jira/browse/JCR-3222
> Project: Jackrabbit Content Repository
>  Issue Type: Improvement
>  Components: jackrabbit-jcr-server
>Reporter: Jukka Zitting
>Priority: Minor
> Attachments: JCR-3222-fmeschbe.patch, 
> jackrabbit-jcr-server-2.6-SNAPSHOT.jar
>
>
> In order to integrate the Jackrabbit davex server functionality with their 
> custom authentication logic, the Sling project currently needs to embed and 
> subclass the davex servlet classes. It would be cleaner if such tight 
> coupling wasn't needed.
> One way to achieve something like that would be to allow external components 
> to provide a custom SessionProvider instance as an extra request attribute. 
> This way for example a servlet filter that implements such custom 
> authentication logic could easily make its functionality available to the 
> standard davex servlet in Jackrabbit.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (JCR-3222) Allow servlet filters to specify custom session providers

[Felix Meschberger (Commented) (JIRA)]

[ 
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 needs to be able to take over the entire 
> processing of a request instead of just servicing a getSession() call. 

This is wrong.

The DavexServletService is registered as a servlet service and gets processing 
the request from the service call. A service in OSGi registered along with an 
Osgi HttpContext object which has a handleSecurity method, which handles 
authentication before the servlet is even called. By having a contextId service 
property a whiteboard servlet service can refer to a whiteboard HttpContext 
service which implements that method accordingly.

Thus my patch allows to plug a HttpContext service which we in Sling can 
provide to call the Sling authentication processing. This then makes the 
ResourceResolver and hence the Session available to the servlet.

Inside the servlet, the patch implements the getSessionProvider method to 
return a proxy SessionProvider which either provides a registered 
SessionProvider service or returns the default from the parent class. Sling 
will den provide a SessionProvider service which knows about the Sling 
authentication and can extract the session from the ResourceResolver.

Existing uses of the JcrRemotingServlet need not be changed as does the 
JcrRemotingServlet. Everything is done in the DavexServletService with proper 
OSGi oriented actions -- except for the ResourceResolver defined as a request 
attribute, which we already have.

> Allow servlet filters to specify custom session providers
> -
>
> Key: JCR-3222
> URL: https://issues.apache.org/jira/browse/JCR-3222
> Project: Jackrabbit Content Repository
>  Issue Type: Improvement
>  Components: jackrabbit-jcr-server
>Reporter: Jukka Zitting
>Priority: Minor
> Attachments: JCR-3222-fmeschbe.patch, 
> jackrabbit-jcr-server-2.6-SNAPSHOT.jar
>
>
> In order to integrate the Jackrabbit davex server functionality with their 
> custom authentication logic, the Sling project currently needs to embed and 
> subclass the davex servlet classes. It would be cleaner if such tight 
> coupling wasn't needed.
> One way to achieve something like that would be to allow external components 
> to provide a custom SessionProvider instance as an extra request attribute. 
> This way for example a servlet filter that implements such custom 
> authentication logic could easily make its functionality available to the 
> standard davex servlet in Jackrabbit.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Updated] (JCR-3222) Allow servlet filters to specify custom session providers

[Felix Meschberger (Updated) (JIRA)]

 [ 
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

> Allow servlet filters to specify custom session providers
> -
>
> Key: JCR-3222
> URL: https://issues.apache.org/jira/browse/JCR-3222
> Project: Jackrabbit Content Repository
>  Issue Type: Improvement
>  Components: jackrabbit-jcr-server
>Reporter: Jukka Zitting
>Priority: Minor
> Attachments: JCR-3222-fmeschbe.patch, 
> jackrabbit-jcr-server-2.6-SNAPSHOT.jar
>
>
> In order to integrate the Jackrabbit davex server functionality with their 
> custom authentication logic, the Sling project currently needs to embed and 
> subclass the davex servlet classes. It would be cleaner if such tight 
> coupling wasn't needed.
> One way to achieve something like that would be to allow external components 
> to provide a custom SessionProvider instance as an extra request attribute. 
> This way for example a servlet filter that implements such custom 
> authentication logic could easily make its functionality available to the 
> standard davex servlet in Jackrabbit.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (JCR-3222) Allow servlet filters to specify custom session providers

[Felix Meschberger (Commented) (JIRA)]

[ 
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 library and I cannot see, what's changed 

But then, somehow this feels like official Reflection Programming 

How about using OSGi services ?

(0) The DavexServletService is already registered as a Servlet service for 
Whiteboard Http Service registration
(1) We could add a contextId configuration which could be configured to refer 
to a HttpContext service used by the Whiteboard registration
(2) Support a SessionProvider service providing pluggability

Sling (or other OSGi based use cases) could then just provide the missing 
pieces.

Will provide a proposed patch.

> Allow servlet filters to specify custom session providers
> -
>
> Key: JCR-3222
> URL: https://issues.apache.org/jira/browse/JCR-3222
> Project: Jackrabbit Content Repository
>  Issue Type: Improvement
>  Components: jackrabbit-jcr-server
>Reporter: Jukka Zitting
>Priority: Minor
> Attachments: jackrabbit-jcr-server-2.6-SNAPSHOT.jar
>
>
> In order to integrate the Jackrabbit davex server functionality with their 
> custom authentication logic, the Sling project currently needs to embed and 
> subclass the davex servlet classes. It would be cleaner if such tight 
> coupling wasn't needed.
> One way to achieve something like that would be to allow external components 
> to provide a custom SessionProvider instance as an extra request attribute. 
> This way for example a servlet filter that implements such custom 
> authentication logic could easily make its functionality available to the 
> standard davex servlet in Jackrabbit.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

Re: Jackrabbit SPI export version

[Felix Meschberger]

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 the only ones using and implementing
> this interface.

True, but think about downstream deployers and secondary users like Sling.

But, hmm, hmm, hmm, I may have made a mistake .. updating the SPI, SPI Commons, 
WebDav, and JCR Commons bundles to 2.3.7 while still having had an old DavEx 
build embedding JCR Server 2.3.4 (or another pre-2.3.7 version).

This bombed because the DavEx bundle imported spi at [2.4,3) thus precluding to 
operate with SPI 2.3.7 exporting spi at 3.

> 
> And (correct me if I'm wrong), isn't the OSGi framework supposed to be
> able to deal with cases where for backwards compatibility reasons more
> than one version of a package needs to be present?

You don't want to enter the arena of deploying the same bundle in different 
versions. The framework perfectly knows how to deal with this. Our software 
probably not ... Point is building a consistent class space where different 
actors use the same classes.

> 
> I'd understand this desire better if the objection was about 1233468
> (the actual API change) rather than 1227240 (the OSGi package version
> update). Is there any actual client or implementation code that gets
> broken by revision 1233468 but that I didn't already update? Why then
> is revision 1227240 causing trouble?

The export version changed caused the problem to be flagged. Given the API 
change, the version change was the right thing to do such that the issue could 
be flagged. I tried to make this clear in my follow-up.

Maybe the real problem is with the setup of the JCR Server library: we made 
this a bundle without any exports but with a Declarative Services descriptor 
for the added DavexServletService.

This requires me in Sling to embed the JCR Server library to implement 
something slightly different on-top of the JcrRemotingServlet.

Maybe we should export packages from the JCR Server library and modify the 
DavexServletService setup such that it is inoperable unless configuration is 
provided (or support configuration to disable it). This would help me in Sling 
to my stuff based on JcrRemotingServlet and be less bound to Jackrabbit 
internal dependencies.

Nevertheless, I think that breaking backwards compatibility in exported 
packages should not have been done.

Regards
Felix

> 
> BR,
> 
> Jukka Zitting

Re: Jackrabbit SPI export version

[Felix Meschberger]

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 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.

Yes, I changed the SPI in a minor but backwards-incompatible way in
JCR-3198 (the QueryInfo.getSelectorNames signature was clearly wrong,
as selector names are opaque strings, not qualified names). Thus the
increase in the package version.

> Consequence of this is, that I have a hard time updating the Sling DavEx
> bundle to this latest release ...

What's the exact problem you're having?

BR,

Jukka Zitting

Re: Jackrabbit SPI export version

[Felix Meschberger]

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,
> 
> 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 1233468 (Update OSGi package 
> versions for a new release.)
> 
> Consequence of this is, that I have a hard time updating the Sling DavEx 
> bundle to this latest release ... But not updating and running in a framework 
> with the new bundle will also prevent Sling DavEx from running.
> 
> Regards
> Felix

Jackrabbit SPI export version

[Felix Meschberger]

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 1233468 (Update OSGi package 
versions for a new release.)

Consequence of this is, that I have a hard time updating the Sling DavEx bundle 
to this latest release ... But not updating and running in a framework with the 
new bundle will also prevent Sling DavEx from running.

Regards
Felix

Re: [jr3] Orderable child nodes: required (to be the default)?

[Felix Meschberger]

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 orderable node
> (like nt:unstructured), then the repository should keep track of the
> order of child nodes regardless of how many they are. IMHO it's OK for
> the repository *not* to scale up or perform well if someone dumps a
> million child nodes to an orderable parent.
> 
> However, it would be great if we could implement efficient storage for
> nodes with lots (i.e. millions) of unorderable children. In such a
> case I'd say we can expect the client to explicitly use a parent node
> with a custom node type that doesn't require orderability.

I am not sure, whether this proposal does not open a can of worms: Consider 
using a node for child nodes whose retrieval should be ordered by insertion 
order. This is currently guaranteed by switching on ordered child nodes on the 
parent node, right ?

So, applications using this will always use ordered nodes and thus suffer from 
performance again ... not good.


> 
> I wouldn't even promise a stable iteration order for such cases. The
> repository should be free to for example reorder the internal data
> structure based on frequent access patterns.

+1

Though paging to the list will then not be possible at all !

Wouldn't it be such, that "unordered" might mean "no defined but stable 
ordering" while ordered means "insertion order unless eplicitly changed" ?

Both must really perform well or we get bad press again

Regards
Felix

[jira] [Commented] (JCR-2859) Make open scoped locks recoverable

[Felix Meschberger (Commented) (JIRA)]

[ 
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.

Shouldn't we push this a step forward and rename the isAdmin method to 
isLockbreaker and introduce a "lockbreaker" group and require the session to be 
a member of that group ? Kind of like a well known group name like 
administrators and everyone ?

> Make open scoped locks recoverable
> --
>
> Key: JCR-2859
> URL: https://issues.apache.org/jira/browse/JCR-2859
> Project: Jackrabbit Content Repository
>  Issue Type: New Feature
>  Components: locks
>Affects Versions: 2.2
>Reporter: Carsten Ziegeler
>Assignee: Julian Reschke
> Attachments: JCR-2859.diff, JCR-2859.patch, OpenScopeLockTest.java
>
>
> The lock tokens for open scoped locks are currently tied to the session which 
> created the lock. If the session dies (for whatever reason) there is no way 
> to recover the lock and unlock the node.
> There is a theoretical way of adding the lock token to another session, but 
> in most cases the lock token is not available.
> Fortunately, the spec allows to relax this behaviour and I think it would 
> make sense to allow all sessions from the same user to unlock the node - this 
> is still in compliance with the spec but would make unlocked locked nodes 
> possible in a programmatic way.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

Re: [Jackrabbit Wiki] Update of "Jsop" by stefan

[Felix Meschberger]

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" [#before|#after], which
> is problematic from a parser point of view, because optional token at the
> end of "logical line" are ambiguous (the token might belong to the next
> logical line).
> 
>> Sling JSOP
> 
> I believe the 'diff' part within Sling isn't implemented yet, right? I
> guess The Sling JSOP should be compatible with what we do for Jackrabbit 3
> as much as possible, but the use cases might be slightly different.

Absolutely. I tend to think any Sling JSOP implementation would best reuse an 
existing parser instead of writing its own stuff.

> 
>> IETF JSON Diff
> 
> I think our work will influence IETF JSON Diff. The "test" and "move"
> operation were already added, I guess the "copy" operations will be added
> as well, because it simply makes sense to have such an operation.
> 
> I think the standards are still ambiguous in a few areas. One is the exact
> specification of a "path" and "path element". I saw that
> draft-pbryan-json-patch-02.txt assumes a number at the end of a path is an
> array index: "Moving an Array Element" - "/foo/1" refers to the second
> element in the array "/foo". That could mean number are not allowed as
> path elements (there could be no node called "/foo/1"). Another problem we
> ran into is adding a 'options mechanism' in the getNodes call. One idea is
> to append ";hash" to the path if the server should include the content
> hash for each node. That means getNode("/foo;hash") would return the node
> "/foo", together with the ":hash" property (in our implementation).

Is this IETF draft or your extension ? Anyways, it feels extremely strange.

Regards
Felix

[jira] [Commented] (JCR-3170) Precompile JavaCC parsers in jackrabbit-spi-commons

[Felix Meschberger (Commented) (JIRA)]

[ 
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't think, that I really like this ...

If you want to integrate this you can have an Maven Eclipse plugin setup to 
have the JavaCC process run on demand. Checking in generated code as primary 
source does not feel right.

> Precompile JavaCC parsers in jackrabbit-spi-commons
> ---
>
> Key: JCR-3170
> URL: https://issues.apache.org/jira/browse/JCR-3170
> Project: Jackrabbit Content Repository
>  Issue Type: Improvement
>  Components: jackrabbit-spi-commons
>Reporter: Jukka Zitting
>Assignee: Jukka Zitting
>Priority: Minor
>  Labels: javacc
> Fix For: 2.3.5
>
>
> The JavaCC-generated Java source files in jackrabbit-spi-commons require 
> special configuration when importing Jackrabbit sources to an IDE like 
> Eclipse. To make IDE integration smoother it would be nice if precompiled 
> copies of the Java files existed the src/main/java folder.
> Precompiling the sources would also allow us to avoid the JavaCC processing 
> step during each Jackrabbit build. Instead we could have a separate profile 
> for explicitly recompiling the JavaCC sources when they have been modified. 
> In the past three years that has happened only once (JCR-952), so I think a 
> bit of extra complexity there is justified by the simplification we can 
> achieve in normal builds and IDE integration.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

Re: [jr3 microkernel] Write skew

[Felix Meschberger]

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... ;)
> 
> I do. That's exactly why we should challenge it: to discover possible 
> paint points and to discuss how to handle them.

Ok, I am out-a-here -- I cannot paint ;-)

Regards
Felix

Re: [jr3 microkernel] Write skew

[Felix Meschberger]

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 method (in case long lived sessions are used).
> 
> For obvious reasons a snapshot-based implementation would need to
> implicitly call refresh(true) on a session before delivering
> observation events.

I don't think so, I would even deem it dangerous. Rather I would accept the 
fact of the session not being accurate (since this is ok per the spec) and have 
the listeners refresh themselves as needed.

Maybe there are listeners, that do not even use the session, with which they 
have been registered in the first place. Then such a refresh by the repository 
would just burn cycles to no avail.

Regards
Felix

[jira] [Resolved] (JCR-3164) Add minimal maintenance API to TokenBasedAuthentication

[Felix Meschberger (Resolved) (JIRA)]

 [ 
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 think the minimal API would not make much sense. For 
real management you might also want to query existing tokens etc.

So lets drop this for now and pick it up on a real "Token Administration API" 
level after the refactoring.

> Add minimal maintenance API to TokenBasedAuthentication
> ---
>
> Key: JCR-3164
> URL: https://issues.apache.org/jira/browse/JCR-3164
> Project: Jackrabbit Content Repository
>  Issue Type: Improvement
>  Components: jackrabbit-core
>Affects Versions: 2.3.4
>Reporter: Felix Meschberger
>Assignee: angela
>
> 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 token maintenance in down stream code (for 
> example in a Sling Authentication Handler), some maintenance API would be 
> helpful:
>   String createToken(String username, long initialExpiry, Session session) 
> throws RepositoryException;
>   void removeToken(String token, Session session) throws RepositoryException;
> Will attach a proposed patch.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

Re: [jr3 microkernel] Write skew

[Felix Meschberger]

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.
> 
> Section 10.11.1 of JSR 283 [1] explicitly allows changes to become
> visible only after a refresh: "[...] items that do not have changes
> pending have their state refreshed to reflect the current persisted
> state, thus revealing changes made by other sessions."

Ok. Thanks for the clarification.

I always thought, what Jackrabbit currently does is required ... 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 method (in 
case long lived sessions are used).

> 
> More generally about the write skew -issue; I don't think that's a
> common problem in practice. There aren't too many clients that
> explicitly interleave operations of multiple sessions within a single
> thread. And in a multithreaded setup a client would even with
> Jackrabbit 2.x need to use explicit synchronization to enforce more
> complex content constraints.

Sure. I think the main problem with long lived sessions I know of (in Sling 
based applications) is with Observation Listeners which are quite isolated and 
can be "fixed" easily -- there just has to be awareness.

Regards
Felix

[jira] [Created] (JCR-3164) Add minimal maintenance API to TokenBasedAuthentication

[Felix Meschberger (Created) (JIRA)]

Add minimal maintenance API to TokenBasedAuthentication
---

 Key: JCR-3164
 URL: https://issues.apache.org/jira/browse/JCR-3164
 Project: Jackrabbit Content Repository
  Issue Type: Improvement
  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 token maintenance in down stream code (for example in a 
Sling Authentication Handler), some maintenance API would be helpful:

  String createToken(String username, long initialExpiry, Session session) 
throws RepositoryException;
  void removeToken(String token, Session session) throws RepositoryException;

Will attach a proposed patch.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

Re: [jr3 microkernel] Write skew

[Felix Meschberger]

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 isolation (which would be
>> copy-on-read IIUC) would break those cases (but usually these errors
>> will depend on concurrency, thus hard to spot).
>> 
>> Now looking at the specs, I am confused: in JCR 1.0 it was up to the
>> implementation to be using copy-on-read or copy-on-write [0]. In JCR 2.0
>> that text was replaced by [1] (IIUC, didn't find anything else) which
>> seems to be defining copy-on-write as the standard behavior now:
>> 
>> "A change that is persisted is visible to all other sessions bound to
>> the same persistent workspace that have sufficient read permission."
>> 
>> That would mean that JR 3 cannot do snapshot isolation! But I might be
>> missing something...
> 
> 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.

Well "visible after refresh" is a conditional visibility IMHO, while "visible" 
as in the spec is more like unconditional (always under the assumption of 
having read access, of course).

Regards
Felix

Re: [jr3 microkernel] Write skew

[Felix Meschberger]

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 IMHO .. Even more so than 
performance !

Any implementation which is not compliant may be as compliant as it may be is 
not worth it because the user never knows what to expect.

Regards
Felix

Re: [jr3 microkernel] Write skew

[Felix Meschberger]

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 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 reverse from the situation in JR2.

Hmm, this will probably effectively break many if not most current 
ObservationListener implementations. Good to know.

Still what could listeners possibly do here ? Sesssion.refresh ? Or create a 
short-lived session to handle the event ?

Regards
Felix

Re: [jr3 microkernel] Write skew

[Felix Meschberger]

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 sessions backing ObservationListeners (which are inherently long-lived) ? 
Do they get accurate data back ?

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 ?


Regards
Felix

Am 30.11.2011 um 14:02 schrieb Michael Dürig:

> 
> 
>> 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 inherent to snapshot isolation.
> 
> [1] http://dl.acm.org/citation.cfm?id=1376690
> 
> 
>> 
>> Regards
>> Felix
>> 
>> Am 30.11.2011 um 13:38 schrieb Michael Dürig:
>> 
>>> 
>>> 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 session) but might fail globally. That is, in order to enforce
>>> some constraints, applications might need to implement explicit cross
>>> session synchronization mechanisms instead of being able to rely on
>>> session isolation. The following test case demonstrates the issue.
>>> 
>>> /**
>>>  * Trans-session isolation differs from Jackrabbit 2.
>>>  * Snapshot isolation can result in write skew as this
>>>  * test demonstrates: the check method enforces an
>>>  * application logic constraint which says that the sum
>>>  * of the properties p1 and p2 must not be negative. While
>>>  * session1 and session2 each enforce this constraint before
>>>  * saving, the constraint might not hold globally as can be
>>>  * seen in session3.
>>>  */
>>> @Test
>>> public void testSessionIsolation() throws RepositoryException {
>>> Repository repository = getRepository();
>>> 
>>> Session session0 = repository.login();
>>> Node testNode = session0.getNode("/").addNode("testNode");
>>> testNode.setProperty("p1", 1);
>>> testNode.setProperty("p2", 1);
>>> session0.save();
>>> check(getSession());
>>> 
>>> Session session1 = repository.login();
>>> Session session2 = repository.login();
>>> 
>>> session1.getNode("/testNode").setProperty("p1", -1);
>>> check(session1);
>>> session1.save();
>>> 
>>> session2.getNode("/testNode").setProperty("p2", -1);
>>> check(session2);  // Throws on JR2 but not on JR3
>>> session2.save();
>>> 
>>> Session session3 = repository.login();
>>> check(session3);  // Throws on JR3
>>> }
>>> 
>>> private static void check(Session session) throws RepositoryException {
>>> if (session.getNode("/testNode").getProperty("p1").getLong() +
>>> session.getNode("/testNode").getProperty("p2").getLong()<  0) {
>>>   fail("p1 + p2<  0");
>>>   }
>>> }
>>> 
>>> Michael
>>> 
>>> [1]
>>> http://wiki.apache.org/jackrabbit/Transactional%20model%20of%20the%20Microkernel%20based%20Jackrabbit%20prototype
>> 

Re: [jr3 microkernel] Write skew

[Felix Meschberger]

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 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 session) but might fail globally. That is, in order to enforce 
> some constraints, applications might need to implement explicit cross 
> session synchronization mechanisms instead of being able to rely on 
> session isolation. The following test case demonstrates the issue.
> 
> /**
>  * Trans-session isolation differs from Jackrabbit 2.
>  * Snapshot isolation can result in write skew as this
>  * test demonstrates: the check method enforces an
>  * application logic constraint which says that the sum
>  * of the properties p1 and p2 must not be negative. While
>  * session1 and session2 each enforce this constraint before
>  * saving, the constraint might not hold globally as can be
>  * seen in session3.
>  */
> @Test
> public void testSessionIsolation() throws RepositoryException {
> Repository repository = getRepository();
> 
> Session session0 = repository.login();
> Node testNode = session0.getNode("/").addNode("testNode");
> testNode.setProperty("p1", 1);
> testNode.setProperty("p2", 1);
> session0.save();
> check(getSession());
> 
> Session session1 = repository.login();
> Session session2 = repository.login();
> 
> session1.getNode("/testNode").setProperty("p1", -1);
> check(session1);
> session1.save();
> 
> session2.getNode("/testNode").setProperty("p2", -1);
> check(session2);  // Throws on JR2 but not on JR3
> session2.save();
> 
> Session session3 = repository.login();
> check(session3);  // Throws on JR3
> }
> 
> private static void check(Session session) throws RepositoryException {
> if (session.getNode("/testNode").getProperty("p1").getLong() +
> session.getNode("/testNode").getProperty("p2").getLong() < 0) {
>   fail("p1 + p2 < 0");
>   }
> }
> 
> Michael
> 
> [1] 
> http://wiki.apache.org/jackrabbit/Transactional%20model%20of%20the%20Microkernel%20based%20Jackrabbit%20prototype