[jira] [Commented] (JCR-4463) Update JavaDoc for completeBinaryUpload explaining idempotency
[
https://issues.apache.org/jira/browse/JCR-4463?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16903525#comment-16903525
]
Alexander Klimetschek commented on JCR-4463:
LGTM
> Update JavaDoc for completeBinaryUpload explaining idempotency
> --
>
> Key: JCR-4463
> URL: https://issues.apache.org/jira/browse/JCR-4463
> Project: Jackrabbit Content Repository
> Issue Type: Improvement
> Components: jackrabbit-api
>Affects Versions: 2.18.2
>Reporter: Matt Ryan
>Assignee: Matt Ryan
>Priority: Minor
> Fix For: 2.18.3
>
>
> In OAK-8520 a fix was added in the direct binary upload implementation so
> that if a client calls {{completeBinaryUpload()}} multiple times with the
> same upload token, subsequent calls will return the already-uploaded binary
> without making any change to the backend. It would be good to reflect this
> case in the JavaDocs for {{JackrabbitValueFactory.completeBinaryUpload()}}.
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
[jira] [Commented] (JCR-4355) Javadoc fixes and improvements for new direct binary access API
[
https://issues.apache.org/jira/browse/JCR-4355?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16588519#comment-16588519
]
Alexander Klimetschek commented on JCR-4355:
Latest patch:
* [^JCR-4355-v3.patch]
* [^JCR-4355-v3-javadoc-html.zip]
I took [~reschke]'s patch and did these further changes:
* better formatting and formulas in upload algorithm
* removed unclear "support multi-part uploads by reusing a single URI multiple
times" paragraph as mentioned above
* using "if the media type defines a charset" everywhere
* fixed some formatting issues: {{}} and {{}} inside methods (security
consideration)
I consider the patch ready for committing.
> Javadoc fixes and improvements for new direct binary access API
> ---
>
> Key: JCR-4355
> URL: https://issues.apache.org/jira/browse/JCR-4355
> Project: Jackrabbit Content Repository
> Issue Type: Improvement
> Components: jackrabbit-api
>Reporter: Alexander Klimetschek
>Priority: Major
> Fix For: 2.18
>
> Attachments: JCR-4355-jr.diff, JCR-4355-v2-javadoc-html.zip,
> JCR-4355-v2.patch, JCR-4355-v3-javadoc-html.zip, JCR-4355-v3.patch,
> JCR-4355.diff
>
>
> Here are some changes to the javadocs for the new API:
> [OAK-7569-api-javadoc-improvements.patch|https://issues.apache.org/jira/secure/attachment/12934364/12934364_OAK-7569-api-javadoc-improvements.patch]
> * more concise descriptions
> * correcting some inaccuracies (clients cannot choose whether to do single or
> multipart upload, multipart might be strictly required depending on the size)
> * most importantly the upload algorithm (standard partSize calculation was
> wrong)
> * focus on API users, separated notes to implementors
> * for BinaryDownloadOptions added note from which jcr properties a client
> would normally take these values from
> * added security considerations
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (JCR-4355) Javadoc fixes and improvements for new direct binary access API
[ https://issues.apache.org/jira/browse/JCR-4355?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexander Klimetschek updated JCR-4355: --- Attachment: JCR-4355-v3-javadoc-html.zip > Javadoc fixes and improvements for new direct binary access API > --- > > Key: JCR-4355 > URL: https://issues.apache.org/jira/browse/JCR-4355 > Project: Jackrabbit Content Repository > Issue Type: Improvement > Components: jackrabbit-api > Reporter: Alexander Klimetschek >Priority: Major > Fix For: 2.18 > > Attachments: JCR-4355-jr.diff, JCR-4355-v2-javadoc-html.zip, > JCR-4355-v2.patch, JCR-4355-v3-javadoc-html.zip, JCR-4355-v3.patch, > JCR-4355.diff > > > Here are some changes to the javadocs for the new API: > [OAK-7569-api-javadoc-improvements.patch|https://issues.apache.org/jira/secure/attachment/12934364/12934364_OAK-7569-api-javadoc-improvements.patch] > * more concise descriptions > * correcting some inaccuracies (clients cannot choose whether to do single or > multipart upload, multipart might be strictly required depending on the size) > * most importantly the upload algorithm (standard partSize calculation was > wrong) > * focus on API users, separated notes to implementors > * for BinaryDownloadOptions added note from which jcr properties a client > would normally take these values from > * added security considerations -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (JCR-4355) Javadoc fixes and improvements for new direct binary access API
[ https://issues.apache.org/jira/browse/JCR-4355?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexander Klimetschek updated JCR-4355: --- Attachment: (was: JCR-4355-v3-javadoc-html.zip) > Javadoc fixes and improvements for new direct binary access API > --- > > Key: JCR-4355 > URL: https://issues.apache.org/jira/browse/JCR-4355 > Project: Jackrabbit Content Repository > Issue Type: Improvement > Components: jackrabbit-api > Reporter: Alexander Klimetschek >Priority: Major > Fix For: 2.18 > > Attachments: JCR-4355-jr.diff, JCR-4355-v2-javadoc-html.zip, > JCR-4355-v2.patch, JCR-4355-v3-javadoc-html.zip, JCR-4355-v3.patch, > JCR-4355.diff > > > Here are some changes to the javadocs for the new API: > [OAK-7569-api-javadoc-improvements.patch|https://issues.apache.org/jira/secure/attachment/12934364/12934364_OAK-7569-api-javadoc-improvements.patch] > * more concise descriptions > * correcting some inaccuracies (clients cannot choose whether to do single or > multipart upload, multipart might be strictly required depending on the size) > * most importantly the upload algorithm (standard partSize calculation was > wrong) > * focus on API users, separated notes to implementors > * for BinaryDownloadOptions added note from which jcr properties a client > would normally take these values from > * added security considerations -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (JCR-4355) Javadoc fixes and improvements for new direct binary access API
[ https://issues.apache.org/jira/browse/JCR-4355?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexander Klimetschek updated JCR-4355: --- Attachment: JCR-4355-v3.patch JCR-4355-v3-javadoc-html.zip > Javadoc fixes and improvements for new direct binary access API > --- > > Key: JCR-4355 > URL: https://issues.apache.org/jira/browse/JCR-4355 > Project: Jackrabbit Content Repository > Issue Type: Improvement > Components: jackrabbit-api > Reporter: Alexander Klimetschek >Priority: Major > Fix For: 2.18 > > Attachments: JCR-4355-jr.diff, JCR-4355-v2-javadoc-html.zip, > JCR-4355-v2.patch, JCR-4355-v3-javadoc-html.zip, JCR-4355-v3.patch, > JCR-4355.diff > > > Here are some changes to the javadocs for the new API: > [OAK-7569-api-javadoc-improvements.patch|https://issues.apache.org/jira/secure/attachment/12934364/12934364_OAK-7569-api-javadoc-improvements.patch] > * more concise descriptions > * correcting some inaccuracies (clients cannot choose whether to do single or > multipart upload, multipart might be strictly required depending on the size) > * most importantly the upload algorithm (standard partSize calculation was > wrong) > * focus on API users, separated notes to implementors > * for BinaryDownloadOptions added note from which jcr properties a client > would normally take these values from > * added security considerations -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (JCR-4355) Javadoc fixes and improvements for new direct binary access API
[ https://issues.apache.org/jira/browse/JCR-4355?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexander Klimetschek updated JCR-4355: --- Attachment: (was: JCR-4355-v3-javadoc-html.zip) > Javadoc fixes and improvements for new direct binary access API > --- > > Key: JCR-4355 > URL: https://issues.apache.org/jira/browse/JCR-4355 > Project: Jackrabbit Content Repository > Issue Type: Improvement > Components: jackrabbit-api > Reporter: Alexander Klimetschek >Priority: Major > Fix For: 2.18 > > Attachments: JCR-4355-jr.diff, JCR-4355-v2-javadoc-html.zip, > JCR-4355-v2.patch, JCR-4355.diff > > > Here are some changes to the javadocs for the new API: > [OAK-7569-api-javadoc-improvements.patch|https://issues.apache.org/jira/secure/attachment/12934364/12934364_OAK-7569-api-javadoc-improvements.patch] > * more concise descriptions > * correcting some inaccuracies (clients cannot choose whether to do single or > multipart upload, multipart might be strictly required depending on the size) > * most importantly the upload algorithm (standard partSize calculation was > wrong) > * focus on API users, separated notes to implementors > * for BinaryDownloadOptions added note from which jcr properties a client > would normally take these values from > * added security considerations -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (JCR-4355) Javadoc fixes and improvements for new direct binary access API
[ https://issues.apache.org/jira/browse/JCR-4355?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexander Klimetschek updated JCR-4355: --- Attachment: (was: JCR-4355-v3.patch) > Javadoc fixes and improvements for new direct binary access API > --- > > Key: JCR-4355 > URL: https://issues.apache.org/jira/browse/JCR-4355 > Project: Jackrabbit Content Repository > Issue Type: Improvement > Components: jackrabbit-api > Reporter: Alexander Klimetschek >Priority: Major > Fix For: 2.18 > > Attachments: JCR-4355-jr.diff, JCR-4355-v2-javadoc-html.zip, > JCR-4355-v2.patch, JCR-4355.diff > > > Here are some changes to the javadocs for the new API: > [OAK-7569-api-javadoc-improvements.patch|https://issues.apache.org/jira/secure/attachment/12934364/12934364_OAK-7569-api-javadoc-improvements.patch] > * more concise descriptions > * correcting some inaccuracies (clients cannot choose whether to do single or > multipart upload, multipart might be strictly required depending on the size) > * most importantly the upload algorithm (standard partSize calculation was > wrong) > * focus on API users, separated notes to implementors > * for BinaryDownloadOptions added note from which jcr properties a client > would normally take these values from > * added security considerations -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (JCR-4355) Javadoc fixes and improvements for new direct binary access API
[ https://issues.apache.org/jira/browse/JCR-4355?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexander Klimetschek updated JCR-4355: --- Attachment: JCR-4355-v3-javadoc-html.zip JCR-4355-v3.patch > Javadoc fixes and improvements for new direct binary access API > --- > > Key: JCR-4355 > URL: https://issues.apache.org/jira/browse/JCR-4355 > Project: Jackrabbit Content Repository > Issue Type: Improvement > Components: jackrabbit-api > Reporter: Alexander Klimetschek >Priority: Major > Fix For: 2.18 > > Attachments: JCR-4355-jr.diff, JCR-4355-v2-javadoc-html.zip, > JCR-4355-v2.patch, JCR-4355-v3-javadoc-html.zip, JCR-4355-v3.patch, > JCR-4355.diff > > > Here are some changes to the javadocs for the new API: > [OAK-7569-api-javadoc-improvements.patch|https://issues.apache.org/jira/secure/attachment/12934364/12934364_OAK-7569-api-javadoc-improvements.patch] > * more concise descriptions > * correcting some inaccuracies (clients cannot choose whether to do single or > multipart upload, multipart might be strictly required depending on the size) > * most importantly the upload algorithm (standard partSize calculation was > wrong) > * focus on API users, separated notes to implementors > * for BinaryDownloadOptions added note from which jcr properties a client > would normally take these values from > * added security considerations -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (JCR-4355) Javadoc fixes and improvements for new direct binary access API
[
https://issues.apache.org/jira/browse/JCR-4355?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16576874#comment-16576874
]
Alexander Klimetschek commented on JCR-4355:
Thanks for the review. It would actually be nice to have a github workflow to
view and discuss these changes...
{quote}charset issue
{quote}
Ok to use _if the media type defines a "charset"_ in all places? (Your patch
just adapted one)
{quote}reduces the amount of @link tags having in-line prose (which I find
confusing to read)
{quote}
I used them (with just the method name w/o classname and parameters) to
increase readability in the final rendered HTML, otherwise there are repeated
very long {{JackrabbitValueFactory.somelongmethod(with, many, params)}} in
there. Wanted the docs be optimized for their html reading, not the java
sources.
Note in at least one place, your changes reformatted lists to an inline
text block (probably IDE reformatting), making them hard to follow in the
sources.
+1 for the direct link to upload algorithm.
{quote}Some storage providers also support multi-part uploads by reusing a
single URI multiple times, in which case the implementation may also return a
single URI regardless of the size of the data being uploaded
{quote}
I did not touch that text. This refers to Google Cloud Storage, which is the
only one of the major providers (AWS, Azure, Rackspace, Google) to support
[multipart via standard Content-Range headers on
PUT|https://cloud.google.com/storage/docs/json_api/v1/how-tos/resumable-upload],
without requiring separate part URLs. Which would be more standards-compliant
and simplifies the whole approach to a single URL, but, well... Anyway, we
don't support Google as DataStore right now, so there is no end-to-end
integration of that approach, nor is there a description of that in the upload
algorithm.
If we would add this, with the current API, a client could potentially detect
this case if getMaxPartSize() is smaller than the original file size AND a
single URI is provided. But I fear that might be a bit too fragile, and we
probably need a flag for that in the BinaryUpload instructions, such as
{{canUseContentRange()}}.
Maybe for now it's best to take that out of the javadoc, and only add this in
the future, when needed and it's clear how it can work.
I'll work on a new iteration of the docs.
> Javadoc fixes and improvements for new direct binary access API
> ---
>
> Key: JCR-4355
> URL: https://issues.apache.org/jira/browse/JCR-4355
> Project: Jackrabbit Content Repository
> Issue Type: Improvement
> Components: jackrabbit-api
>Reporter: Alexander Klimetschek
>Priority: Major
> Fix For: 2.18
>
> Attachments: JCR-4355-jr.diff, JCR-4355-v2-javadoc-html.zip,
> JCR-4355-v2.patch, JCR-4355.diff
>
>
> Here are some changes to the javadocs for the new API:
> [OAK-7569-api-javadoc-improvements.patch|https://issues.apache.org/jira/secure/attachment/12934364/12934364_OAK-7569-api-javadoc-improvements.patch]
> * more concise descriptions
> * correcting some inaccuracies (clients cannot choose whether to do single or
> multipart upload, multipart might be strictly required depending on the size)
> * most importantly the upload algorithm (standard partSize calculation was
> wrong)
> * focus on API users, separated notes to implementors
> * for BinaryDownloadOptions added note from which jcr properties a client
> would normally take these values from
> * added security considerations
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (JCR-4355) Javadoc fixes and improvements for new direct binary access API
[ https://issues.apache.org/jira/browse/JCR-4355?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16575757#comment-16575757 ] Alexander Klimetschek commented on JCR-4355: How complete does the description have to be here? List all mime types where this could apply? Clients will take it based on the availability of the jcr:encoding property and that is covered in the javadoc. > Javadoc fixes and improvements for new direct binary access API > --- > > Key: JCR-4355 > URL: https://issues.apache.org/jira/browse/JCR-4355 > Project: Jackrabbit Content Repository > Issue Type: Improvement > Components: jackrabbit-api > Reporter: Alexander Klimetschek >Priority: Major > Attachments: JCR-4355-v2-javadoc-html.zip, JCR-4355-v2.patch, > JCR-4355.diff > > > Here are some changes to the javadocs for the new API: > [OAK-7569-api-javadoc-improvements.patch|https://issues.apache.org/jira/secure/attachment/12934364/12934364_OAK-7569-api-javadoc-improvements.patch] > * more concise descriptions > * correcting some inaccuracies (clients cannot choose whether to do single or > multipart upload, multipart might be strictly required depending on the size) > * most importantly the upload algorithm (standard partSize calculation was > wrong) > * focus on API users, separated notes to implementors > * for BinaryDownloadOptions added note from which jcr properties a client > would normally take these values from > * added security considerations -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (JCR-4355) Javadoc fixes and improvements for new direct binary access API
[ https://issues.apache.org/jira/browse/JCR-4355?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexander Klimetschek updated JCR-4355: --- Attachment: (was: JCR-4355-v2.patch) > Javadoc fixes and improvements for new direct binary access API > --- > > Key: JCR-4355 > URL: https://issues.apache.org/jira/browse/JCR-4355 > Project: Jackrabbit Content Repository > Issue Type: Improvement > Components: jackrabbit-api > Reporter: Alexander Klimetschek >Priority: Major > Attachments: JCR-4355-v2-javadoc-html.zip, JCR-4355-v2.patch, > JCR-4355.diff > > > Here are some changes to the javadocs for the new API: > [OAK-7569-api-javadoc-improvements.patch|https://issues.apache.org/jira/secure/attachment/12934364/12934364_OAK-7569-api-javadoc-improvements.patch] > * more concise descriptions > * correcting some inaccuracies (clients cannot choose whether to do single or > multipart upload, multipart might be strictly required depending on the size) > * most importantly the upload algorithm (standard partSize calculation was > wrong) > * focus on API users, separated notes to implementors > * for BinaryDownloadOptions added note from which jcr properties a client > would normally take these values from > * added security considerations -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (JCR-4355) Javadoc fixes and improvements for new direct binary access API
[ https://issues.apache.org/jira/browse/JCR-4355?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexander Klimetschek updated JCR-4355: --- Attachment: (was: JCR-4355-v2-javadoc-html.zip) > Javadoc fixes and improvements for new direct binary access API > --- > > Key: JCR-4355 > URL: https://issues.apache.org/jira/browse/JCR-4355 > Project: Jackrabbit Content Repository > Issue Type: Improvement > Components: jackrabbit-api > Reporter: Alexander Klimetschek >Priority: Major > Attachments: JCR-4355-v2-javadoc-html.zip, JCR-4355-v2.patch, > JCR-4355.diff > > > Here are some changes to the javadocs for the new API: > [OAK-7569-api-javadoc-improvements.patch|https://issues.apache.org/jira/secure/attachment/12934364/12934364_OAK-7569-api-javadoc-improvements.patch] > * more concise descriptions > * correcting some inaccuracies (clients cannot choose whether to do single or > multipart upload, multipart might be strictly required depending on the size) > * most importantly the upload algorithm (standard partSize calculation was > wrong) > * focus on API users, separated notes to implementors > * for BinaryDownloadOptions added note from which jcr properties a client > would normally take these values from > * added security considerations -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (JCR-4355) Javadoc fixes and improvements for new direct binary access API
[ https://issues.apache.org/jira/browse/JCR-4355?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexander Klimetschek updated JCR-4355: --- Attachment: JCR-4355-v2.patch JCR-4355-v2-javadoc-html.zip > Javadoc fixes and improvements for new direct binary access API > --- > > Key: JCR-4355 > URL: https://issues.apache.org/jira/browse/JCR-4355 > Project: Jackrabbit Content Repository > Issue Type: Improvement > Components: jackrabbit-api > Reporter: Alexander Klimetschek >Priority: Major > Attachments: JCR-4355-v2-javadoc-html.zip, JCR-4355-v2.patch, > JCR-4355.diff > > > Here are some changes to the javadocs for the new API: > [OAK-7569-api-javadoc-improvements.patch|https://issues.apache.org/jira/secure/attachment/12934364/12934364_OAK-7569-api-javadoc-improvements.patch] > * more concise descriptions > * correcting some inaccuracies (clients cannot choose whether to do single or > multipart upload, multipart might be strictly required depending on the size) > * most importantly the upload algorithm (standard partSize calculation was > wrong) > * focus on API users, separated notes to implementors > * for BinaryDownloadOptions added note from which jcr properties a client > would normally take these values from > * added security considerations -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (JCR-4355) Javadoc fixes and improvements for new direct binary access API
[ https://issues.apache.org/jira/browse/JCR-4355?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16575334#comment-16575334 ] Alexander Klimetschek commented on JCR-4355: To make it easier to review, I attached generated javadocs in [^JCR-4355-v2-javadoc-html.zip] > Javadoc fixes and improvements for new direct binary access API > --- > > Key: JCR-4355 > URL: https://issues.apache.org/jira/browse/JCR-4355 > Project: Jackrabbit Content Repository > Issue Type: Improvement > Components: jackrabbit-api > Reporter: Alexander Klimetschek >Priority: Major > Attachments: JCR-4355-v2-javadoc-html.zip, JCR-4355-v2.patch, > JCR-4355.diff > > > Here are some changes to the javadocs for the new API: > [OAK-7569-api-javadoc-improvements.patch|https://issues.apache.org/jira/secure/attachment/12934364/12934364_OAK-7569-api-javadoc-improvements.patch] > * more concise descriptions > * correcting some inaccuracies (clients cannot choose whether to do single or > multipart upload, multipart might be strictly required depending on the size) > * most importantly the upload algorithm (standard partSize calculation was > wrong) > * focus on API users, separated notes to implementors > * for BinaryDownloadOptions added note from which jcr properties a client > would normally take these values from > * added security considerations -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (JCR-4355) Javadoc fixes and improvements for new direct binary access API
[ https://issues.apache.org/jira/browse/JCR-4355?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexander Klimetschek updated JCR-4355: --- Attachment: (was: JCR-4355-javadoc-html.zip) > Javadoc fixes and improvements for new direct binary access API > --- > > Key: JCR-4355 > URL: https://issues.apache.org/jira/browse/JCR-4355 > Project: Jackrabbit Content Repository > Issue Type: Improvement > Components: jackrabbit-api > Reporter: Alexander Klimetschek >Priority: Major > Attachments: JCR-4355-v2-javadoc-html.zip, JCR-4355-v2.patch, > JCR-4355.diff > > > Here are some changes to the javadocs for the new API: > [OAK-7569-api-javadoc-improvements.patch|https://issues.apache.org/jira/secure/attachment/12934364/12934364_OAK-7569-api-javadoc-improvements.patch] > * more concise descriptions > * correcting some inaccuracies (clients cannot choose whether to do single or > multipart upload, multipart might be strictly required depending on the size) > * most importantly the upload algorithm (standard partSize calculation was > wrong) > * focus on API users, separated notes to implementors > * for BinaryDownloadOptions added note from which jcr properties a client > would normally take these values from > * added security considerations -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (JCR-4355) Javadoc fixes and improvements for new direct binary access API
[ https://issues.apache.org/jira/browse/JCR-4355?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexander Klimetschek updated JCR-4355: --- Attachment: JCR-4355-v2-javadoc-html.zip > Javadoc fixes and improvements for new direct binary access API > --- > > Key: JCR-4355 > URL: https://issues.apache.org/jira/browse/JCR-4355 > Project: Jackrabbit Content Repository > Issue Type: Improvement > Components: jackrabbit-api > Reporter: Alexander Klimetschek >Priority: Major > Attachments: JCR-4355-v2-javadoc-html.zip, JCR-4355-v2.patch, > JCR-4355.diff > > > Here are some changes to the javadocs for the new API: > [OAK-7569-api-javadoc-improvements.patch|https://issues.apache.org/jira/secure/attachment/12934364/12934364_OAK-7569-api-javadoc-improvements.patch] > * more concise descriptions > * correcting some inaccuracies (clients cannot choose whether to do single or > multipart upload, multipart might be strictly required depending on the size) > * most importantly the upload algorithm (standard partSize calculation was > wrong) > * focus on API users, separated notes to implementors > * for BinaryDownloadOptions added note from which jcr properties a client > would normally take these values from > * added security considerations -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (JCR-4355) Javadoc fixes and improvements for new direct binary access API
[ https://issues.apache.org/jira/browse/JCR-4355?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexander Klimetschek updated JCR-4355: --- Attachment: JCR-4355-javadoc-html.zip > Javadoc fixes and improvements for new direct binary access API > --- > > Key: JCR-4355 > URL: https://issues.apache.org/jira/browse/JCR-4355 > Project: Jackrabbit Content Repository > Issue Type: Improvement > Components: jackrabbit-api > Reporter: Alexander Klimetschek >Priority: Major > Attachments: JCR-4355-v2-javadoc-html.zip, JCR-4355-v2.patch, > JCR-4355.diff > > > Here are some changes to the javadocs for the new API: > [OAK-7569-api-javadoc-improvements.patch|https://issues.apache.org/jira/secure/attachment/12934364/12934364_OAK-7569-api-javadoc-improvements.patch] > * more concise descriptions > * correcting some inaccuracies (clients cannot choose whether to do single or > multipart upload, multipart might be strictly required depending on the size) > * most importantly the upload algorithm (standard partSize calculation was > wrong) > * focus on API users, separated notes to implementors > * for BinaryDownloadOptions added note from which jcr properties a client > would normally take these values from > * added security considerations -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (JCR-4355) Javadoc fixes and improvements for new direct binary access API
[
https://issues.apache.org/jira/browse/JCR-4355?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16575325#comment-16575325
]
Alexander Klimetschek commented on JCR-4355:
Thanks for the feedback!
Here is an updated patch: [^JCR-4355-v2.patch]
* Changed "text-based" to "character-based"
* The current javadoc has a lot of duplication too :) I changed the part to
"\{@link BinaryDownloadOptions} includes, but is not limited to:" and added a
note on Content-Disposition type: "Content-Disposition type: whether to show
the content inline of a page (inline) or enforce a download/save as
(attachment)". Also linked to the different {{with*()}} methods. Wanted to
highlight the important settings that a caller needs to be aware of and which
JCR properties would usually be the source. For the details, one can follow the
links to BinaryDownloadOptions javadoc then.
* Added to security considerations of getURI: "If the client is a browser,
consider use of Content-Disposition type = attachment for executable media
types such as HTML or Javascript if the content cannot be trusted."
> Javadoc fixes and improvements for new direct binary access API
> ---
>
> Key: JCR-4355
> URL: https://issues.apache.org/jira/browse/JCR-4355
> Project: Jackrabbit Content Repository
> Issue Type: Improvement
> Components: jackrabbit-api
>Reporter: Alexander Klimetschek
>Priority: Major
> Attachments: JCR-4355-v2.patch, JCR-4355.diff
>
>
> Here are some changes to the javadocs for the new API:
> [OAK-7569-api-javadoc-improvements.patch|https://issues.apache.org/jira/secure/attachment/12934364/12934364_OAK-7569-api-javadoc-improvements.patch]
> * more concise descriptions
> * correcting some inaccuracies (clients cannot choose whether to do single or
> multipart upload, multipart might be strictly required depending on the size)
> * most importantly the upload algorithm (standard partSize calculation was
> wrong)
> * focus on API users, separated notes to implementors
> * for BinaryDownloadOptions added note from which jcr properties a client
> would normally take these values from
> * added security considerations
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (JCR-4355) Javadoc fixes and improvements for new direct binary access API
[ https://issues.apache.org/jira/browse/JCR-4355?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexander Klimetschek updated JCR-4355: --- Attachment: JCR-4355-v2.patch > Javadoc fixes and improvements for new direct binary access API > --- > > Key: JCR-4355 > URL: https://issues.apache.org/jira/browse/JCR-4355 > Project: Jackrabbit Content Repository > Issue Type: Improvement > Components: jackrabbit-api > Reporter: Alexander Klimetschek >Priority: Major > Attachments: JCR-4355-v2.patch, JCR-4355.diff > > > Here are some changes to the javadocs for the new API: > [OAK-7569-api-javadoc-improvements.patch|https://issues.apache.org/jira/secure/attachment/12934364/12934364_OAK-7569-api-javadoc-improvements.patch] > * more concise descriptions > * correcting some inaccuracies (clients cannot choose whether to do single or > multipart upload, multipart might be strictly required depending on the size) > * most importantly the upload algorithm (standard partSize calculation was > wrong) > * focus on API users, separated notes to implementors > * for BinaryDownloadOptions added note from which jcr properties a client > would normally take these values from > * added security considerations -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (JCR-4355) Javadoc fixes and improvements for new direct binary access API
[ https://issues.apache.org/jira/browse/JCR-4355?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexander Klimetschek updated JCR-4355: --- Description: Here are some changes to the javadocs for the new API: [OAK-7569-api-javadoc-improvements.patch|https://issues.apache.org/jira/secure/attachment/12934364/12934364_OAK-7569-api-javadoc-improvements.patch] * more concise descriptions * correcting some inaccuracies (clients cannot choose whether to do single or multipart upload, multipart might be strictly required depending on the size) * most importantly the upload algorithm (standard partSize calculation was wrong) * focus on API users, separated notes to implementors * for BinaryDownloadOptions added note from which jcr properties a client would normally take these values from * added security considerations was: Here are some changes to the javadocs for the new API: OAK-7569-api-javadoc-improvements.patch * more concise descriptions * correcting some inaccuracies (clients cannot choose whether to do single or multipart upload, multipart might be strictly required depending on the size) * most importantly the upload algorithm (standard partSize calculation was wrong) * focus on API users, separated notes to implementors * for BinaryDownloadOptions added note from which jcr properties a client would normally take these values from * added security considerations > Javadoc fixes and improvements for new direct binary access API > --- > > Key: JCR-4355 > URL: https://issues.apache.org/jira/browse/JCR-4355 > Project: Jackrabbit Content Repository > Issue Type: Improvement > Components: jackrabbit-api > Reporter: Alexander Klimetschek >Priority: Major > Attachments: JCR-4355.diff > > > Here are some changes to the javadocs for the new API: > [OAK-7569-api-javadoc-improvements.patch|https://issues.apache.org/jira/secure/attachment/12934364/12934364_OAK-7569-api-javadoc-improvements.patch] > * more concise descriptions > * correcting some inaccuracies (clients cannot choose whether to do single or > multipart upload, multipart might be strictly required depending on the size) > * most importantly the upload algorithm (standard partSize calculation was > wrong) > * focus on API users, separated notes to implementors > * for BinaryDownloadOptions added note from which jcr properties a client > would normally take these values from > * added security considerations -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (JCR-4355) Javadoc fixes and improvements for new direct binary access API
[ https://issues.apache.org/jira/browse/JCR-4355?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexander Klimetschek updated JCR-4355: --- Description: Here are some changes to the javadocs for the new API: OAK-7569-api-javadoc-improvements.patch * more concise descriptions * correcting some inaccuracies (clients cannot choose whether to do single or multipart upload, multipart might be strictly required depending on the size) * most importantly the upload algorithm (standard partSize calculation was wrong) * focus on API users, separated notes to implementors * for BinaryDownloadOptions added note from which jcr properties a client would normally take these values from * added security considerations was: Here are some changes to the javadocs for the new API: OAK-7569-api-javadoc-improvements.patch more concise descriptions correcting some inaccuracies (clients cannot choose whether to do single or multipart upload, multipart might be strictly required depending on the size) most importantly the upload algorithm (standard partSize calculation was wrong) focus on API users, separated notes to implementors for BinaryDownloadOptions added note from which jcr properties a client would normally take these values from added security considerations > Javadoc fixes and improvements for new direct binary access API > --- > > Key: JCR-4355 > URL: https://issues.apache.org/jira/browse/JCR-4355 > Project: Jackrabbit Content Repository > Issue Type: Improvement > Components: jackrabbit-api > Reporter: Alexander Klimetschek >Priority: Major > > Here are some changes to the javadocs for the new API: > OAK-7569-api-javadoc-improvements.patch > * more concise descriptions > * correcting some inaccuracies (clients cannot choose whether to do single or > multipart upload, multipart might be strictly required depending on the size) > * most importantly the upload algorithm (standard partSize calculation was > wrong) > * focus on API users, separated notes to implementors > * for BinaryDownloadOptions added note from which jcr properties a client > would normally take these values from > * added security considerations -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (JCR-4355) Javadoc fixes and improvements for new direct binary access API
[ https://issues.apache.org/jira/browse/JCR-4355?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexander Klimetschek updated JCR-4355: --- Description: Here are some changes to the javadocs for the new API: OAK-7569-api-javadoc-improvements.patch * more concise descriptions * correcting some inaccuracies (clients cannot choose whether to do single or multipart upload, multipart might be strictly required depending on the size) * most importantly the upload algorithm (standard partSize calculation was wrong) * focus on API users, separated notes to implementors * for BinaryDownloadOptions added note from which jcr properties a client would normally take these values from * added security considerations was: Here are some changes to the javadocs for the new API: OAK-7569-api-javadoc-improvements.patch * more concise descriptions * correcting some inaccuracies (clients cannot choose whether to do single or multipart upload, multipart might be strictly required depending on the size) * most importantly the upload algorithm (standard partSize calculation was wrong) * focus on API users, separated notes to implementors * for BinaryDownloadOptions added note from which jcr properties a client would normally take these values from * added security considerations > Javadoc fixes and improvements for new direct binary access API > --- > > Key: JCR-4355 > URL: https://issues.apache.org/jira/browse/JCR-4355 > Project: Jackrabbit Content Repository > Issue Type: Improvement > Components: jackrabbit-api > Reporter: Alexander Klimetschek >Priority: Major > > Here are some changes to the javadocs for the new API: > OAK-7569-api-javadoc-improvements.patch > * more concise descriptions > * correcting some inaccuracies (clients cannot choose whether to do single or > multipart upload, multipart might be strictly required depending on the size) > * most importantly the upload algorithm (standard partSize calculation was > wrong) > * focus on API users, separated notes to implementors > * for BinaryDownloadOptions added note from which jcr properties a client > would normally take these values from > * added security considerations -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (JCR-4355) Javadoc fixes and improvements for new direct binary access API
[ https://issues.apache.org/jira/browse/JCR-4355?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexander Klimetschek updated JCR-4355: --- Description: Here are some changes to the javadocs for the new API: OAK-7569-api-javadoc-improvements.patch more concise descriptions correcting some inaccuracies (clients cannot choose whether to do single or multipart upload, multipart might be strictly required depending on the size) most importantly the upload algorithm (standard partSize calculation was wrong) focus on API users, separated notes to implementors for BinaryDownloadOptions added note from which jcr properties a client would normally take these values from added security considerations > Javadoc fixes and improvements for new direct binary access API > --- > > Key: JCR-4355 > URL: https://issues.apache.org/jira/browse/JCR-4355 > Project: Jackrabbit Content Repository > Issue Type: Improvement > Components: jackrabbit-api > Reporter: Alexander Klimetschek >Priority: Major > > Here are some changes to the javadocs for the new API: > OAK-7569-api-javadoc-improvements.patch > more concise descriptions > correcting some inaccuracies (clients cannot choose whether to do single or > multipart upload, multipart might be strictly required depending on the size) > most importantly the upload algorithm (standard partSize calculation was > wrong) > focus on API users, separated notes to implementors > for BinaryDownloadOptions added note from which jcr properties a client would > normally take these values from > added security considerations -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (JCR-4355) Javadoc fixes and improvements for new direct binary access API
Alexander Klimetschek created JCR-4355: -- Summary: Javadoc fixes and improvements for new direct binary access API Key: JCR-4355 URL: https://issues.apache.org/jira/browse/JCR-4355 Project: Jackrabbit Content Repository Issue Type: Improvement Components: jackrabbit-api Reporter: Alexander Klimetschek -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (JCR-2233) mix:lastModified - auto-set but allow modification for imports
[ https://issues.apache.org/jira/browse/JCR-2233?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16190242#comment-16190242 ] Alexander Klimetschek commented on JCR-2233: [~supadhyay7] Neither Jackrabbit 1 or 2, nor Oak implement automatic setting of these properties. This issue is still open and I feel might never be done for existing property names, since there might be strong backwards compatibility concerns apart from the challenge of implementing this in a safe manner. To my knowledge there are no properties that are automatically set by the repository and that can be modified by applications (i.e. are not restricted). jcr:created as another example is automatically set, but then immutable. > mix:lastModified - auto-set but allow modification for imports > -- > > Key: JCR-2233 > URL: https://issues.apache.org/jira/browse/JCR-2233 > Project: Jackrabbit Content Repository > Issue Type: Improvement > Components: jackrabbit-core, JCR 2.0 > Reporter: Alexander Klimetschek >Priority: Minor > > Following the discussion in JCR-2116, I propose it would be a good idea to > have jcr:created, jcr:createdBy (from mix:created) and jcr:lastModified, > jcr:lastModifiedBy (mix:lastModified) not protected, but still automatically > set those properties in case they were not modified by the client. > Three advantages: > a) This allows for importing content with these properties, where eg. the > jcr:created should point to the original creation date of the content, not > when it was imported. > b) Same for jcr:lastModified, which often must be set manually for ensuring > correct behaviour when doing synchronizations etc. > c) In order to take advantage of the automatically-set behaviour mentioned in > the spec, it would be nice if the repository would set them in the case the > client is not writing those properties. This way you can ensure the > properties are correctly set when you cannot control all client-code > modifying the content (eg. webdav). > Question: would this be in line with the spec? I would say, yes, since we say > we don't implement "protected", which is allowed, but add a hybrid approach > (which is not explicitly forbidden, IIUC). > For the reference, here is the definition from the latest JSR-283 doc: > [mix:lastModified] mixin > - jcr:lastModified (DATE) autocreated protected? OPV? > - jcr:lastModifiedBy (STRING) autocreated protected? OPV? > [mix:created] mixin > - jcr:created (DATE) autocreated protected? OPV? > - jcr:createdBy (STRING) autocreated protected? OPV? > And here is the current cnd definition in JR 2.0: > http://svn.apache.org/viewvc/jackrabbit/trunk/jackrabbit-core/src/main/resources/org/apache/jackrabbit/core/nodetype/builtin_nodetypes.cnd?view=co -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (JCR-4085) DavEx json should always add type information for Doubles
[ https://issues.apache.org/jira/browse/JCR-4085?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15754799#comment-15754799 ] Alexander Klimetschek commented on JCR-4085: Thanks Julian. No backport needed I think. > DavEx json should always add type information for Doubles > - > > Key: JCR-4085 > URL: https://issues.apache.org/jira/browse/JCR-4085 > Project: Jackrabbit Content Repository > Issue Type: Bug > Components: jackrabbit-jcr-server >Affects Versions: 2.12.6 > Reporter: Alexander Klimetschek >Assignee: Julian Reschke > Fix For: 2.14, 2.13.7 > > > In JSON, there is only a single numeric type which can be both integer and > floating point. A floating point with a ".0" decimal will look like an > integer, e.g. "5.0" => "5", serialized or interpreted as such by parsers. > Hence to correctly keep the type information for davex clients, the type > information in the separate ":" property should always be included for > double jcr properties, in > [JsonWriter.requiresTypeInfo()|https://github.com/apache/jackrabbit/blob/trunk/jackrabbit-jcr-server/src/main/java/org/apache/jackrabbit/server/remoting/davex/JsonWriter.java#L221-L236]. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (JCR-4085) DavEx json should always add type information for Doubles
Alexander Klimetschek created JCR-4085: -- Summary: DavEx json should always add type information for Doubles Key: JCR-4085 URL: https://issues.apache.org/jira/browse/JCR-4085 Project: Jackrabbit Content Repository Issue Type: Bug Components: jackrabbit-jcr-server Affects Versions: 2.12.6 Reporter: Alexander Klimetschek In JSON, there is only a single numeric type which can be both integer and floating point. A floating point with a ".0" decimal will look like an integer, e.g. "5.0" => "5", serialized or interpreted as such by parsers. Hence to correctly keep the type information for davex clients, the type information in the separate ":" property should always be included for double jcr properties, in [JsonWriter.requiresTypeInfo()|https://github.com/apache/jackrabbit/blob/trunk/jackrabbit-jcr-server/src/main/java/org/apache/jackrabbit/server/remoting/davex/JsonWriter.java#L221-L236]. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (JCR-3966) AccessControlUtils should not depend on ability to read other users
[
https://issues.apache.org/jira/browse/JCR-3966?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15241638#comment-15241638
]
Alexander Klimetschek commented on JCR-3966:
{quote}JCR API contract requires the Principal to be known and existing and
accessible on the repository{quote}
But this is not enforced in the implementation (otherwise filevault would not
work, and probably other use cases). Please note that this is about the
AccessControlUtils in jackrabbit-jcr-commons, which does this check by itself,
outside the JCR/Jackrabbit API.
Here is our use case: we have a collaboration application, where users can
share folders which each other, meaning they need to grant ACs for other
users/principals on the folders they own.
As per the security team recommendation, we are using public user profiles
(i.e. subfolders inside the user homes that are open to the other users), so
that the actual user home = user is not readable by other users. When this was
discussed, it was pointed out by the security folks that setting ACs for
another principal does not require read access to the user behind it.
What you say presents a conflict now. Quo vadis?
It works with a custom copy of these helper methods we have in our code, but it
would be great to not duplicate common utility code.
> AccessControlUtils should not depend on ability to read other users
> ---
>
> Key: JCR-3966
> URL: https://issues.apache.org/jira/browse/JCR-3966
> Project: Jackrabbit Content Repository
> Issue Type: Improvement
> Components: jackrabbit-jcr-commons
>Affects Versions: 2.12.1
> Reporter: Alexander Klimetschek
>
> Most methods in
> [AccessControlUtils|https://github.com/apache/jackrabbit/blob/trunk/jackrabbit-jcr-commons/src/main/java/org/apache/jackrabbit/commons/jackrabbit/authorization/AccessControlUtils.java]
> - while taking the principal name as argument - always [fetch the
> principal|https://github.com/apache/jackrabbit/blob/trunk/jackrabbit-jcr-commons/src/main/java/org/apache/jackrabbit/commons/jackrabbit/authorization/AccessControlUtils.java#L369]
> via the jackrabbit PrincipalManager.
> This (at least in Oak) requires the user to have read access on the user
> behind the principal, otherwise it returns null and an NPE is thrown and no
> ACs are set.
> Setting an AC however does not (and should not) require access to the
> complete user, and can be done by implementing the principal on the spot:
> {code}
> new JackrabbitPrincipal() {
> @Override
> public String getName() {
> return principalName;
> }
> };
> {code}
> This uses the JackrabbitPrincipal as the [PrincipalImpl in Oak
> casts|https://github.com/apache/jackrabbit-oak/blob/trunk/oak-core/src/main/java/org/apache/jackrabbit/oak/spi/security/principal/PrincipalImpl.java#L51]
> to this one for the equality test.
> Filevault does the
> [same|https://github.com/apache/jackrabbit-filevault/blob/64caa29325452c1adf968ae05e2308b37f3600cc/vault-core/src/main/java/org/apache/jackrabbit/vault/fs/impl/io/JackrabbitACLImporter.java#L246].
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Comment Edited] (JCR-3966) AccessControlUtils should not depend on ability to read other users
[
https://issues.apache.org/jira/browse/JCR-3966?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15238349#comment-15238349
]
Alexander Klimetschek edited comment on JCR-3966 at 4/13/16 1:00 AM:
-
Note for reading ACs there is no problem: AccessControlEntry.getPrincipal()
returns you a principal, even though you can’t get it from the PrincipalManager
(all when you don't have any permissions on the authorizable/home node behind
the principal).
was (Author: alexander.klimetschek):
Note for reading ACs there is no problem: AccessControlEntry.getPrincipal()
returns you a principal, even though you can’t get it from the PrincipalManager.
> AccessControlUtils should not depend on ability to read other users
> ---
>
> Key: JCR-3966
> URL: https://issues.apache.org/jira/browse/JCR-3966
> Project: Jackrabbit Content Repository
> Issue Type: Improvement
> Components: jackrabbit-jcr-commons
>Affects Versions: 2.12.1
>Reporter: Alexander Klimetschek
>
> Most methods in
> [AccessControlUtils|https://github.com/apache/jackrabbit/blob/trunk/jackrabbit-jcr-commons/src/main/java/org/apache/jackrabbit/commons/jackrabbit/authorization/AccessControlUtils.java]
> - while taking the principal name as argument - always [fetch the
> principal|https://github.com/apache/jackrabbit/blob/trunk/jackrabbit-jcr-commons/src/main/java/org/apache/jackrabbit/commons/jackrabbit/authorization/AccessControlUtils.java#L369]
> via the jackrabbit PrincipalManager.
> This (at least in Oak) requires the user to have read access on the user
> behind the principal, otherwise it returns null and an NPE is thrown and no
> ACs are set.
> Setting an AC however does not (and should not) require access to the
> complete user, and can be done by implementing the principal on the spot:
> {code}
> new JackrabbitPrincipal() {
> @Override
> public String getName() {
> return principalName;
> }
> };
> {code}
> This uses the JackrabbitPrincipal as the [PrincipalImpl in Oak
> casts|https://github.com/apache/jackrabbit-oak/blob/trunk/oak-core/src/main/java/org/apache/jackrabbit/oak/spi/security/principal/PrincipalImpl.java#L51]
> to this one for the equality test.
> Filevault does the
> [same|https://github.com/apache/jackrabbit-filevault/blob/64caa29325452c1adf968ae05e2308b37f3600cc/vault-core/src/main/java/org/apache/jackrabbit/vault/fs/impl/io/JackrabbitACLImporter.java#L246].
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (JCR-3966) AccessControlUtils should not depend on ability to read other users
[
https://issues.apache.org/jira/browse/JCR-3966?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15238349#comment-15238349
]
Alexander Klimetschek commented on JCR-3966:
Note for reading ACs there is no problem: AccessControlEntry.getPrincipal()
returns you a principal, even though you can’t get it from the PrincipalManager.
> AccessControlUtils should not depend on ability to read other users
> ---
>
> Key: JCR-3966
> URL: https://issues.apache.org/jira/browse/JCR-3966
> Project: Jackrabbit Content Repository
> Issue Type: Improvement
> Components: jackrabbit-jcr-commons
>Affects Versions: 2.12.1
> Reporter: Alexander Klimetschek
>
> Most methods in
> [AccessControlUtils|https://github.com/apache/jackrabbit/blob/trunk/jackrabbit-jcr-commons/src/main/java/org/apache/jackrabbit/commons/jackrabbit/authorization/AccessControlUtils.java]
> - while taking the principal name as argument - always [fetch the
> principal|https://github.com/apache/jackrabbit/blob/trunk/jackrabbit-jcr-commons/src/main/java/org/apache/jackrabbit/commons/jackrabbit/authorization/AccessControlUtils.java#L369]
> via the jackrabbit PrincipalManager.
> This (at least in Oak) requires the user to have read access on the user
> behind the principal, otherwise it returns null and an NPE is thrown and no
> ACs are set.
> Setting an AC however does not (and should not) require access to the
> complete user, and can be done by implementing the principal on the spot:
> {code}
> new JackrabbitPrincipal() {
> @Override
> public String getName() {
> return principalName;
> }
> };
> {code}
> This uses the JackrabbitPrincipal as the [PrincipalImpl in Oak
> casts|https://github.com/apache/jackrabbit-oak/blob/trunk/oak-core/src/main/java/org/apache/jackrabbit/oak/spi/security/principal/PrincipalImpl.java#L51]
> to this one for the equality test.
> Filevault does the
> [same|https://github.com/apache/jackrabbit-filevault/blob/64caa29325452c1adf968ae05e2308b37f3600cc/vault-core/src/main/java/org/apache/jackrabbit/vault/fs/impl/io/JackrabbitACLImporter.java#L246].
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (JCR-3966) AccessControlUtils should not depend on ability to read other users
[
https://issues.apache.org/jira/browse/JCR-3966?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexander Klimetschek updated JCR-3966:
---
Description:
Most methods in AccessControlUtils - while taking the principal name as
argument - always [fetch the
principal|https://github.com/apache/jackrabbit/blob/trunk/jackrabbit-jcr-commons/src/main/java/org/apache/jackrabbit/commons/jackrabbit/authorization/AccessControlUtils.java#L369]
via the jackrabbit PrincipalManager.
This (at least in Oak) requires the user to have read access on the user behind
the principal, otherwise it returns null and an NPE is thrown and no ACs are
set.
Setting an AC however does not (and should not) require access to the complete
user, and can be done by implementing the principal on the spot:
{code}
new JackrabbitPrincipal() {
@Override
public String getName() {
return principalName;
}
};
{code}
This uses the JackrabbitPrincipal as the [PrincipalImpl in Oak
casts|https://github.com/apache/jackrabbit-oak/blob/trunk/oak-core/src/main/java/org/apache/jackrabbit/oak/spi/security/principal/PrincipalImpl.java#L51]
to this one for the equality test.
Filevault does the
[same|https://github.com/apache/jackrabbit-filevault/blob/64caa29325452c1adf968ae05e2308b37f3600cc/vault-core/src/main/java/org/apache/jackrabbit/vault/fs/impl/io/JackrabbitACLImporter.java#L246].
was:
Most methods in AccessControlUtils - while taking the principal name as
argument - always [fetch the
principal|https://github.com/apache/jackrabbit/blob/trunk/jackrabbit-jcr-commons/src/main/java/org/apache/jackrabbit/commons/jackrabbit/authorization/AccessControlUtils.java#L369]
via the jackrabbit PrincipalManager.
This (at least in Oak) requires the user to have read access on the user behind
the principal, otherwise it returns null and an NPE is thrown and no ACs are
set.
Setting an AC however does not (and should not) require access to the complete
user, and can be done by implementing the principal on the spot:
{code}
new JackrabbitPrincipal() {
@Override
public String getName() {
return principalName;
}
};
{code}
This uses the JackrabbitPrincipal as the [PrincipalImpl in Oak
casts|https://github.com/apache/jackrabbit-oak/blob/trunk/oak-core/src/main/java/org/apache/jackrabbit/oak/spi/security/principal/PrincipalImpl.java#L51]
to this one for the equality test.
> AccessControlUtils should not depend on ability to read other users
> ---
>
> Key: JCR-3966
> URL: https://issues.apache.org/jira/browse/JCR-3966
> Project: Jackrabbit Content Repository
> Issue Type: Improvement
> Components: jackrabbit-jcr-commons
>Affects Versions: 2.12.1
> Reporter: Alexander Klimetschek
>
> Most methods in AccessControlUtils - while taking the principal name as
> argument - always [fetch the
> principal|https://github.com/apache/jackrabbit/blob/trunk/jackrabbit-jcr-commons/src/main/java/org/apache/jackrabbit/commons/jackrabbit/authorization/AccessControlUtils.java#L369]
> via the jackrabbit PrincipalManager.
> This (at least in Oak) requires the user to have read access on the user
> behind the principal, otherwise it returns null and an NPE is thrown and no
> ACs are set.
> Setting an AC however does not (and should not) require access to the
> complete user, and can be done by implementing the principal on the spot:
> {code}
> new JackrabbitPrincipal() {
> @Override
> public String getName() {
> return principalName;
> }
> };
> {code}
> This uses the JackrabbitPrincipal as the [PrincipalImpl in Oak
> casts|https://github.com/apache/jackrabbit-oak/blob/trunk/oak-core/src/main/java/org/apache/jackrabbit/oak/spi/security/principal/PrincipalImpl.java#L51]
> to this one for the equality test.
> Filevault does the
> [same|https://github.com/apache/jackrabbit-filevault/blob/64caa29325452c1adf968ae05e2308b37f3600cc/vault-core/src/main/java/org/apache/jackrabbit/vault/fs/impl/io/JackrabbitACLImporter.java#L246].
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (JCR-3966) AccessControlUtils should not depend on ability to read other users
[
https://issues.apache.org/jira/browse/JCR-3966?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexander Klimetschek updated JCR-3966:
---
Description:
Most methods in
[AccessControlUtils|https://github.com/apache/jackrabbit/blob/trunk/jackrabbit-jcr-commons/src/main/java/org/apache/jackrabbit/commons/jackrabbit/authorization/AccessControlUtils.java]
- while taking the principal name as argument - always [fetch the
principal|https://github.com/apache/jackrabbit/blob/trunk/jackrabbit-jcr-commons/src/main/java/org/apache/jackrabbit/commons/jackrabbit/authorization/AccessControlUtils.java#L369]
via the jackrabbit PrincipalManager.
This (at least in Oak) requires the user to have read access on the user behind
the principal, otherwise it returns null and an NPE is thrown and no ACs are
set.
Setting an AC however does not (and should not) require access to the complete
user, and can be done by implementing the principal on the spot:
{code}
new JackrabbitPrincipal() {
@Override
public String getName() {
return principalName;
}
};
{code}
This uses the JackrabbitPrincipal as the [PrincipalImpl in Oak
casts|https://github.com/apache/jackrabbit-oak/blob/trunk/oak-core/src/main/java/org/apache/jackrabbit/oak/spi/security/principal/PrincipalImpl.java#L51]
to this one for the equality test.
Filevault does the
[same|https://github.com/apache/jackrabbit-filevault/blob/64caa29325452c1adf968ae05e2308b37f3600cc/vault-core/src/main/java/org/apache/jackrabbit/vault/fs/impl/io/JackrabbitACLImporter.java#L246].
was:
Most methods in AccessControlUtils - while taking the principal name as
argument - always [fetch the
principal|https://github.com/apache/jackrabbit/blob/trunk/jackrabbit-jcr-commons/src/main/java/org/apache/jackrabbit/commons/jackrabbit/authorization/AccessControlUtils.java#L369]
via the jackrabbit PrincipalManager.
This (at least in Oak) requires the user to have read access on the user behind
the principal, otherwise it returns null and an NPE is thrown and no ACs are
set.
Setting an AC however does not (and should not) require access to the complete
user, and can be done by implementing the principal on the spot:
{code}
new JackrabbitPrincipal() {
@Override
public String getName() {
return principalName;
}
};
{code}
This uses the JackrabbitPrincipal as the [PrincipalImpl in Oak
casts|https://github.com/apache/jackrabbit-oak/blob/trunk/oak-core/src/main/java/org/apache/jackrabbit/oak/spi/security/principal/PrincipalImpl.java#L51]
to this one for the equality test.
Filevault does the
[same|https://github.com/apache/jackrabbit-filevault/blob/64caa29325452c1adf968ae05e2308b37f3600cc/vault-core/src/main/java/org/apache/jackrabbit/vault/fs/impl/io/JackrabbitACLImporter.java#L246].
> AccessControlUtils should not depend on ability to read other users
> ---
>
> Key: JCR-3966
> URL: https://issues.apache.org/jira/browse/JCR-3966
> Project: Jackrabbit Content Repository
> Issue Type: Improvement
> Components: jackrabbit-jcr-commons
>Affects Versions: 2.12.1
> Reporter: Alexander Klimetschek
>
> Most methods in
> [AccessControlUtils|https://github.com/apache/jackrabbit/blob/trunk/jackrabbit-jcr-commons/src/main/java/org/apache/jackrabbit/commons/jackrabbit/authorization/AccessControlUtils.java]
> - while taking the principal name as argument - always [fetch the
> principal|https://github.com/apache/jackrabbit/blob/trunk/jackrabbit-jcr-commons/src/main/java/org/apache/jackrabbit/commons/jackrabbit/authorization/AccessControlUtils.java#L369]
> via the jackrabbit PrincipalManager.
> This (at least in Oak) requires the user to have read access on the user
> behind the principal, otherwise it returns null and an NPE is thrown and no
> ACs are set.
> Setting an AC however does not (and should not) require access to the
> complete user, and can be done by implementing the principal on the spot:
> {code}
> new JackrabbitPrincipal() {
> @Override
> public String getName() {
> return principalName;
> }
> };
> {code}
> This uses the JackrabbitPrincipal as the [PrincipalImpl in Oak
> casts|https://github.com/apache/jackrabbit-oak/blob/trunk/oak-core/src/main/java/org/apache/jackrabbit/oak/spi/security/principal/PrincipalImpl.java#L51]
> to this one for the equality test.
> Filevault does the
> [same|https://github.com/apache/jackrabbit-filevault/blob/64caa29325452c1adf968ae05e2308b37f3600cc/vault-core/src/main/java/org/apache/jackrabbit/vault/fs/impl/io/JackrabbitACLImporter.java#L246].
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (JCR-3966) AccessControlUtils should not depend on ability to read other users
[
https://issues.apache.org/jira/browse/JCR-3966?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexander Klimetschek updated JCR-3966:
---
Description:
Most methods in AccessControlUtils - while taking the principal name as
argument - always [fetch the
principal|https://github.com/apache/jackrabbit/blob/trunk/jackrabbit-jcr-commons/src/main/java/org/apache/jackrabbit/commons/jackrabbit/authorization/AccessControlUtils.java#L369]
via the jackrabbit PrincipalManager.
This (at least in Oak) requires the user to have read access on the user behind
the principal, otherwise it returns null and an NPE is thrown and no ACs are
set.
Setting an AC however does not (and should not) require access to the complete
user, and can be done by implementing the principal on the spot:
{code}
new JackrabbitPrincipal() {
@Override
public String getName() {
return principalName;
}
};
{code}
This uses the JackrabbitPrincipal as the [PrincipalImpl in Oak
casts|https://github.com/apache/jackrabbit-oak/blob/trunk/oak-core/src/main/java/org/apache/jackrabbit/oak/spi/security/principal/PrincipalImpl.java#L51]
to this one for the equality test.
was:
Most methods in AccessControlUtils - while taking the principal name as
argument - always [fetch the
principal|https://github.com/apache/jackrabbit/blob/trunk/jackrabbit-jcr-commons/src/main/java/org/apache/jackrabbit/commons/jackrabbit/authorization/AccessControlUtils.java#L369]
via the jackrabbit PrincipalManager.
This (at least in Oak) requires the user to have read access on the user behind
the principal, otherwise it returns null and an NPE is thrown.
Setting an AC however does not (and should not) require access to the complete
user, and can be done by implementing the principal on the spot:
{code}
new JackrabbitPrincipal() {
@Override
public String getName() {
return principalName;
}
};
{code}
This uses the JackrabbitPrincipal as the [PrincipalImpl in Oak
casts|https://github.com/apache/jackrabbit-oak/blob/trunk/oak-core/src/main/java/org/apache/jackrabbit/oak/spi/security/principal/PrincipalImpl.java#L51]
to this one for the equality test.
> AccessControlUtils should not depend on ability to read other users
> ---
>
> Key: JCR-3966
> URL: https://issues.apache.org/jira/browse/JCR-3966
> Project: Jackrabbit Content Repository
> Issue Type: Improvement
> Components: jackrabbit-jcr-commons
>Affects Versions: 2.12.1
> Reporter: Alexander Klimetschek
>
> Most methods in AccessControlUtils - while taking the principal name as
> argument - always [fetch the
> principal|https://github.com/apache/jackrabbit/blob/trunk/jackrabbit-jcr-commons/src/main/java/org/apache/jackrabbit/commons/jackrabbit/authorization/AccessControlUtils.java#L369]
> via the jackrabbit PrincipalManager.
> This (at least in Oak) requires the user to have read access on the user
> behind the principal, otherwise it returns null and an NPE is thrown and no
> ACs are set.
> Setting an AC however does not (and should not) require access to the
> complete user, and can be done by implementing the principal on the spot:
> {code}
> new JackrabbitPrincipal() {
> @Override
> public String getName() {
> return principalName;
> }
> };
> {code}
> This uses the JackrabbitPrincipal as the [PrincipalImpl in Oak
> casts|https://github.com/apache/jackrabbit-oak/blob/trunk/oak-core/src/main/java/org/apache/jackrabbit/oak/spi/security/principal/PrincipalImpl.java#L51]
> to this one for the equality test.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (JCR-3966) AccessControlUtils should not depend on ability to read other users
Alexander Klimetschek created JCR-3966:
--
Summary: AccessControlUtils should not depend on ability to read
other users
Key: JCR-3966
URL: https://issues.apache.org/jira/browse/JCR-3966
Project: Jackrabbit Content Repository
Issue Type: Improvement
Components: jackrabbit-jcr-commons
Affects Versions: 2.12.1
Reporter: Alexander Klimetschek
Most methods in AccessControlUtils - while taking the principal name as
argument - always [fetch the
principal|https://github.com/apache/jackrabbit/blob/trunk/jackrabbit-jcr-commons/src/main/java/org/apache/jackrabbit/commons/jackrabbit/authorization/AccessControlUtils.java#L369]
via the jackrabbit PrincipalManager.
This (at least in Oak) requires the user to have read access on the user behind
the principal, otherwise it returns null and an NPE is thrown.
Setting an AC however does not (and should not) require access to the complete
user, and can be done by implementing the principal on the spot:
{code}
new JackrabbitPrincipal() {
@Override
public String getName() {
return principalName;
}
};
{code}
This uses the JackrabbitPrincipal as the [PrincipalImpl in Oak
casts|https://github.com/apache/jackrabbit-oak/blob/trunk/oak-core/src/main/java/org/apache/jackrabbit/oak/spi/security/principal/PrincipalImpl.java#L51]
to this one for the equality test.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (JCRRMI-34) Support Jackrabbit API over RMI
[ https://issues.apache.org/jira/browse/JCRRMI-34?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14901825#comment-14901825 ] Alexander Klimetschek commented on JCRRMI-34: - I moved the issue to the right project, changed the title and made it a new feature. I am not sure how much interest there will be... so feel free to provide patches! > Support Jackrabbit API over RMI > --- > > Key: JCRRMI-34 > URL: https://issues.apache.org/jira/browse/JCRRMI-34 > Project: Jackrabbit JCR-RMI > Issue Type: New Feature >Reporter: x_nljh1 > > HI ,I want to add access control with Jackrabbit, why I get > org.apache.jackrabbit.rmi.client.clientXASession cannot be cast to > org.apache.jackrabbit.api.jackrabbitSession, > please give me a help, thank you -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (JCRRMI-34) Support Jackrabbit API over RMI
[ https://issues.apache.org/jira/browse/JCRRMI-34?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexander Klimetschek updated JCRRMI-34: Summary: Support Jackrabbit API over RMI (was: ClientXASession Cannot be cast to JackrabbitSession) > Support Jackrabbit API over RMI > --- > > Key: JCRRMI-34 > URL: https://issues.apache.org/jira/browse/JCRRMI-34 > Project: Jackrabbit JCR-RMI > Issue Type: New Feature >Reporter: x_nljh1 > > HI ,I want to add access control with Jackrabbit, why I get > org.apache.jackrabbit.rmi.client.clientXASession cannot be cast to > org.apache.jackrabbit.api.jackrabbitSession, > please give me a help, thank you -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (JCR-3908) ClientXASession Cannot be cast to JackrabbitSession
[ https://issues.apache.org/jira/browse/JCR-3908?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14901823#comment-14901823 ] Alexander Klimetschek commented on JCR-3908: I think that the extended jackrabbit API (as provided by the JackrabbitSession interface) is not available / implemented over RMI. It doesn't even fully implement JCR 2.0 yet, afaik: JCRRMI-26 > ClientXASession Cannot be cast to JackrabbitSession > --- > > Key: JCR-3908 > URL: https://issues.apache.org/jira/browse/JCR-3908 > Project: Jackrabbit Content Repository > Issue Type: Bug >Reporter: x_nljh1 > > HI ,I want to add access control with Jackrabbit, why I get > org.apache.jackrabbit.rmi.client.clientXASession cannot be cast to > org.apache.jackrabbit.api.jackrabbitSession, > please give me a help, thank you -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Moved] (JCRRMI-34) ClientXASession Cannot be cast to JackrabbitSession
[ https://issues.apache.org/jira/browse/JCRRMI-34?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexander Klimetschek moved JCR-3908 to JCRRMI-34: -- Issue Type: New Feature (was: Bug) Key: JCRRMI-34 (was: JCR-3908) Project: Jackrabbit JCR-RMI (was: Jackrabbit Content Repository) > ClientXASession Cannot be cast to JackrabbitSession > --- > > Key: JCRRMI-34 > URL: https://issues.apache.org/jira/browse/JCRRMI-34 > Project: Jackrabbit JCR-RMI > Issue Type: New Feature >Reporter: x_nljh1 > > HI ,I want to add access control with Jackrabbit, why I get > org.apache.jackrabbit.rmi.client.clientXASession cannot be cast to > org.apache.jackrabbit.api.jackrabbitSession, > please give me a help, thank you -- This message was sent by Atlassian JIRA (v6.3.4#6332)
Re: New committer: Dominique Jäggi
Welcome! Cheers, Alex > On 29.07.2015, at 14:52, Michael Dürig wrote: > > Hi, > > Please welcome Dominique as a new committer and PMC member of the Apache > Jackrabbit project. The Jackrabbit PMC recently decided to offer Dominique > 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, Dominique! > > Michael
[jira] [Created] (JCR-3875) S3 data store: maxConnections <= writeThreads leads to exception
Alexander Klimetschek created JCR-3875:
--
Summary: S3 data store: maxConnections <= writeThreads leads to
exception
Key: JCR-3875
URL: https://issues.apache.org/jira/browse/JCR-3875
Project: Jackrabbit Content Repository
Issue Type: Bug
Components: jackrabbit-data
Reporter: Alexander Klimetschek
Priority: Critical
The S3 data store [tries to create a thread
pool|https://github.com/apache/jackrabbit/blob/a9e005191a63078abdcaeace50887f79c79415cb/jackrabbit-aws-ext/src/main/java/org/apache/jackrabbit/aws/ext/ds/S3Backend.java#L170-L171]
with
{{maxConnections - writeThreads}}
but this will fail if you specify the same value for both or less
maxConnections than writeThreads, and throw:
{noformat}
Caused by: org.apache.jackrabbit.core.data.DataStoreException: Could not
initialize S3 from {s3Encryption=SSE_S3,
component.name=org.apache.jackrabbit.oak.plugins.blob.datastore.S3DataStore,
maxConnections=40, secretKey=XXX, writeThreads=40, service.vendor=The
Apache Software Foundation, s3Bucket=X, socketTimeout=12,
service.pid=org.apache.jackrabbit.oak.plugins.blob.datastore.S3DataStore,
component.id=79, connectionTimeout=12, accessKey=XXX,
s3EndPoint=s3.amazonaws.com, s3Region=us-standard, maxErrorRetry=10,
path=./crx-quickstart/repository/datastore}
at org.apache.jackrabbit.aws.ext.ds.S3Backend.init(S3Backend.java:188)
at org.apache.jackrabbit.aws.ext.ds.S3Backend.init(S3Backend.java:121)
at
org.apache.jackrabbit.core.data.CachingDataStore.init(CachingDataStore.java:267)
... 23 common frames omitted
Caused by: java.lang.IllegalArgumentException: null
at
java.util.concurrent.ThreadPoolExecutor.(ThreadPoolExecutor.java:1310)
at
java.util.concurrent.ThreadPoolExecutor.(ThreadPoolExecutor.java:1233)
at java.util.concurrent.Executors.newFixedThreadPool(Executors.java:114)
at org.apache.jackrabbit.aws.ext.ds.S3Backend.init(S3Backend.java:174)
... 25 common frames omitted
{noformat}
It's also not intuitive at all. Maybe it's better to specify the thread pools
explicitly, i.e. {{writeThreads}} and {{otherThreads}} (whatever that 2nd pool
exactly is).
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (JCR-3873) CachingDataStore not safe against crashes, corrupted uploads file will prevent system startup
[
https://issues.apache.org/jira/browse/JCR-3873?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexander Klimetschek updated JCR-3873:
---
Description:
An NPE in OAK-2811 lead to the data store not being closed normally on
shutdown, in turn leaving the {{async-pending-uploads.ser}} file corrupted (on
this system, binaries were constantly uploaded, so likely the queue to upload
it to S3 in this case was still full) and then on the next startup, the
CachingDataStore failed to start up, preventing the repository and the system
from starting:
{noformat}
24.04.2015 13:21:28.602 *ERROR* [FelixStartLevel]
org.apache.jackrabbit.oak-core
[org.apache.jackrabbit.oak.plugins.blob.datastore.S3DataStore(79)] The activate
method has thrown an exception (javax.jcr.RepositoryException:
java.io.EOFException)
javax.jcr.RepositoryException: java.io.EOFException
at
org.apache.jackrabbit.core.data.CachingDataStore.init(CachingDataStore.java:337)
at
org.apache.jackrabbit.oak.plugins.blob.datastore.AbstractDataStoreService.activate(AbstractDataStoreService.java:61)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:606)
at
org.apache.felix.scr.impl.helper.BaseMethod.invokeMethod(BaseMethod.java:222)
at
org.apache.felix.scr.impl.helper.BaseMethod.access$500(BaseMethod.java:37)
at
org.apache.felix.scr.impl.helper.BaseMethod$Resolved.invoke(BaseMethod.java:615)
at
org.apache.felix.scr.impl.helper.BaseMethod.invoke(BaseMethod.java:499)
at
org.apache.felix.scr.impl.helper.ActivateMethod.invoke(ActivateMethod.java:295)
at
org.apache.felix.scr.impl.manager.SingleComponentManager.createImplementationObject(SingleComponentManager.java:302)
at
org.apache.felix.scr.impl.manager.SingleComponentManager.createComponent(SingleComponentManager.java:113)
at
org.apache.felix.scr.impl.manager.SingleComponentManager.getService(SingleComponentManager.java:832)
at
org.apache.felix.scr.impl.manager.SingleComponentManager.getServiceInternal(SingleComponentManager.java:799)
at
org.apache.felix.scr.impl.manager.AbstractComponentManager.activateInternal(AbstractComponentManager.java:724)
at
org.apache.felix.scr.impl.manager.AbstractComponentManager.enable(AbstractComponentManager.java:399)
at
org.apache.felix.scr.impl.config.ConfigurableComponentHolder.enableComponents(ConfigurableComponentHolder.java:669)
at
org.apache.felix.scr.impl.BundleComponentActivator.initialEnable(BundleComponentActivator.java:184)
at
org.apache.felix.scr.impl.Activator.loadComponents(Activator.java:332)
at org.apache.felix.scr.impl.Activator.access$000(Activator.java:49)
at
org.apache.felix.scr.impl.Activator$ScrExtension.start(Activator.java:257)
at
org.apache.felix.utils.extender.AbstractExtender.createExtension(AbstractExtender.java:259)
at
org.apache.felix.utils.extender.AbstractExtender.modifiedBundle(AbstractExtender.java:232)
at
org.osgi.util.tracker.BundleTracker$Tracked.customizerModified(BundleTracker.java:482)
at
org.osgi.util.tracker.BundleTracker$Tracked.customizerModified(BundleTracker.java:415)
at org.osgi.util.tracker.AbstractTracked.track(AbstractTracked.java:232)
at
org.osgi.util.tracker.BundleTracker$Tracked.bundleChanged(BundleTracker.java:444)
at
org.apache.felix.framework.util.EventDispatcher.invokeBundleListenerCallback(EventDispatcher.java:913)
at
org.apache.felix.framework.util.EventDispatcher.fireEventImmediately(EventDispatcher.java:834)
at
org.apache.felix.framework.util.EventDispatcher.fireBundleEvent(EventDispatcher.java:516)
at org.apache.felix.framework.Felix.fireBundleEvent(Felix.java:4531)
at org.apache.felix.framework.Felix.startBundle(Felix.java:2169)
at org.apache.felix.framework.Felix.setActiveStartLevel(Felix.java:1368)
at
org.apache.felix.framework.FrameworkStartLevelImpl.run(FrameworkStartLevelImpl.java:308)
at java.lang.Thread.run(Thread.java:745)
Caused by: java.io.EOFException: null
at
java.io.ObjectInputStream$PeekInputStream.readFully(ObjectInputStream.java:2325)
at
java.io.ObjectInputStream$BlockDataInputStream.readShort(ObjectInputStream.java:2794)
at
java.io.ObjectInputStream.readStreamHeader(ObjectInputStream.java:801)
at java.io.ObjectInputStream.(ObjectInputStream.java:299)
at
org.apache.jackrabbit.core.data.AsyncUploadCache.deserializeAsyncUploadMap(AsyncUploadCache.java:311)
at
org.apache.jackrabbit.core.data.AsyncUploadCache.init(AsyncUploadCache.java:243
[jira] [Updated] (JCR-3873) CachingDataStore not safe against crashes, corrupted uploads file will prevent system startup
[
https://issues.apache.org/jira/browse/JCR-3873?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexander Klimetschek updated JCR-3873:
---
Description:
An NPE in OAK-2811 lead to the data store not being closed normally on
shutdown, in turn leaving the {{async-pending-uploads.ser}} file corrupted (on
this system, binaries were constantly uploaded, so likely the queue to upload
it to S3 in this case was still full) and then on the next startup, the
CachingDataStore failed to start up, preventing the repository and the system
from starting:
{noformat}
24.04.2015 13:21:28.602 *ERROR* [FelixStartLevel]
org.apache.jackrabbit.oak-core
[org.apache.jackrabbit.oak.plugins.blob.datastore.S3DataStore(79)] The activate
method has thrown an exception (javax.jcr.RepositoryException:
java.io.EOFException)
javax.jcr.RepositoryException: java.io.EOFException
at
org.apache.jackrabbit.core.data.CachingDataStore.init(CachingDataStore.java:337)
at
org.apache.jackrabbit.oak.plugins.blob.datastore.AbstractDataStoreService.activate(AbstractDataStoreService.java:61)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:606)
at
org.apache.felix.scr.impl.helper.BaseMethod.invokeMethod(BaseMethod.java:222)
at
org.apache.felix.scr.impl.helper.BaseMethod.access$500(BaseMethod.java:37)
at
org.apache.felix.scr.impl.helper.BaseMethod$Resolved.invoke(BaseMethod.java:615)
at
org.apache.felix.scr.impl.helper.BaseMethod.invoke(BaseMethod.java:499)
at
org.apache.felix.scr.impl.helper.ActivateMethod.invoke(ActivateMethod.java:295)
at
org.apache.felix.scr.impl.manager.SingleComponentManager.createImplementationObject(SingleComponentManager.java:302)
at
org.apache.felix.scr.impl.manager.SingleComponentManager.createComponent(SingleComponentManager.java:113)
at
org.apache.felix.scr.impl.manager.SingleComponentManager.getService(SingleComponentManager.java:832)
at
org.apache.felix.scr.impl.manager.SingleComponentManager.getServiceInternal(SingleComponentManager.java:799)
at
org.apache.felix.scr.impl.manager.AbstractComponentManager.activateInternal(AbstractComponentManager.java:724)
at
org.apache.felix.scr.impl.manager.AbstractComponentManager.enable(AbstractComponentManager.java:399)
at
org.apache.felix.scr.impl.config.ConfigurableComponentHolder.enableComponents(ConfigurableComponentHolder.java:669)
at
org.apache.felix.scr.impl.BundleComponentActivator.initialEnable(BundleComponentActivator.java:184)
at
org.apache.felix.scr.impl.Activator.loadComponents(Activator.java:332)
at org.apache.felix.scr.impl.Activator.access$000(Activator.java:49)
at
org.apache.felix.scr.impl.Activator$ScrExtension.start(Activator.java:257)
at
org.apache.felix.utils.extender.AbstractExtender.createExtension(AbstractExtender.java:259)
at
org.apache.felix.utils.extender.AbstractExtender.modifiedBundle(AbstractExtender.java:232)
at
org.osgi.util.tracker.BundleTracker$Tracked.customizerModified(BundleTracker.java:482)
at
org.osgi.util.tracker.BundleTracker$Tracked.customizerModified(BundleTracker.java:415)
at org.osgi.util.tracker.AbstractTracked.track(AbstractTracked.java:232)
at
org.osgi.util.tracker.BundleTracker$Tracked.bundleChanged(BundleTracker.java:444)
at
org.apache.felix.framework.util.EventDispatcher.invokeBundleListenerCallback(EventDispatcher.java:913)
at
org.apache.felix.framework.util.EventDispatcher.fireEventImmediately(EventDispatcher.java:834)
at
org.apache.felix.framework.util.EventDispatcher.fireBundleEvent(EventDispatcher.java:516)
at org.apache.felix.framework.Felix.fireBundleEvent(Felix.java:4531)
at org.apache.felix.framework.Felix.startBundle(Felix.java:2169)
at org.apache.felix.framework.Felix.setActiveStartLevel(Felix.java:1368)
at
org.apache.felix.framework.FrameworkStartLevelImpl.run(FrameworkStartLevelImpl.java:308)
at java.lang.Thread.run(Thread.java:745)
Caused by: java.io.EOFException: null
at
java.io.ObjectInputStream$PeekInputStream.readFully(ObjectInputStream.java:2325)
at
java.io.ObjectInputStream$BlockDataInputStream.readShort(ObjectInputStream.java:2794)
at
java.io.ObjectInputStream.readStreamHeader(ObjectInputStream.java:801)
at java.io.ObjectInputStream.(ObjectInputStream.java:299)
at
org.apache.jackrabbit.core.data.AsyncUploadCache.deserializeAsyncUploadMap(AsyncUploadCache.java:311)
at
org.apache.jackrabbit.core.data.AsyncUploadCache.init(AsyncUploadCache.java:243
[jira] [Updated] (JCR-3873) CachingDataStore not safe against crashes, corrupted uploads file will prevent system startup
[
https://issues.apache.org/jira/browse/JCR-3873?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexander Klimetschek updated JCR-3873:
---
Summary: CachingDataStore not safe against crashes, corrupted uploads file
will prevent system startup (was: CachingDataStore not safe against crashes,
corrupted uploads file will prevent system from starting up)
> CachingDataStore not safe against crashes, corrupted uploads file will
> prevent system startup
> -
>
> Key: JCR-3873
> URL: https://issues.apache.org/jira/browse/JCR-3873
> Project: Jackrabbit Content Repository
> Issue Type: Bug
> Components: jackrabbit-data
>Affects Versions: 2.9.1
> Reporter: Alexander Klimetschek
>
> An NPE in OAK-2811 lead to the data store not being closed normally on
> shutdown, in turn leaving the {{async-pending-uploads.ser}} file corrupted
> and then on the next startup, the CachingDataStore failed to start up,
> preventing the repository and the system from starting:
> {noformat}
> 24.04.2015 13:21:28.602 *ERROR* [FelixStartLevel]
> org.apache.jackrabbit.oak-core
> [org.apache.jackrabbit.oak.plugins.blob.datastore.S3DataStore(79)] The
> activate method has thrown an exception (javax.jcr.RepositoryException:
> java.io.EOFException)
> javax.jcr.RepositoryException: java.io.EOFException
> at
> org.apache.jackrabbit.core.data.CachingDataStore.init(CachingDataStore.java:337)
> at
> org.apache.jackrabbit.oak.plugins.blob.datastore.AbstractDataStoreService.activate(AbstractDataStoreService.java:61)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:606)
> at
> org.apache.felix.scr.impl.helper.BaseMethod.invokeMethod(BaseMethod.java:222)
> at
> org.apache.felix.scr.impl.helper.BaseMethod.access$500(BaseMethod.java:37)
> at
> org.apache.felix.scr.impl.helper.BaseMethod$Resolved.invoke(BaseMethod.java:615)
> at
> org.apache.felix.scr.impl.helper.BaseMethod.invoke(BaseMethod.java:499)
> at
> org.apache.felix.scr.impl.helper.ActivateMethod.invoke(ActivateMethod.java:295)
> at
> org.apache.felix.scr.impl.manager.SingleComponentManager.createImplementationObject(SingleComponentManager.java:302)
> at
> org.apache.felix.scr.impl.manager.SingleComponentManager.createComponent(SingleComponentManager.java:113)
> at
> org.apache.felix.scr.impl.manager.SingleComponentManager.getService(SingleComponentManager.java:832)
> at
> org.apache.felix.scr.impl.manager.SingleComponentManager.getServiceInternal(SingleComponentManager.java:799)
> at
> org.apache.felix.scr.impl.manager.AbstractComponentManager.activateInternal(AbstractComponentManager.java:724)
> at
> org.apache.felix.scr.impl.manager.AbstractComponentManager.enable(AbstractComponentManager.java:399)
> at
> org.apache.felix.scr.impl.config.ConfigurableComponentHolder.enableComponents(ConfigurableComponentHolder.java:669)
> at
> org.apache.felix.scr.impl.BundleComponentActivator.initialEnable(BundleComponentActivator.java:184)
> at
> org.apache.felix.scr.impl.Activator.loadComponents(Activator.java:332)
> at org.apache.felix.scr.impl.Activator.access$000(Activator.java:49)
> at
> org.apache.felix.scr.impl.Activator$ScrExtension.start(Activator.java:257)
> at
> org.apache.felix.utils.extender.AbstractExtender.createExtension(AbstractExtender.java:259)
> at
> org.apache.felix.utils.extender.AbstractExtender.modifiedBundle(AbstractExtender.java:232)
> at
> org.osgi.util.tracker.BundleTracker$Tracked.customizerModified(BundleTracker.java:482)
> at
> org.osgi.util.tracker.BundleTracker$Tracked.customizerModified(BundleTracker.java:415)
> at org.osgi.util.tracker.AbstractTracked.track(AbstractTracked.java:232)
> at
> org.osgi.util.tracker.BundleTracker$Tracked.bundleChanged(BundleTracker.java:444)
> at
> org.apache.felix.framework.util.EventDispatcher.invokeBundleListenerCallback(EventDispatcher.java:913)
> at
> org.apache.felix.framework.util.EventDispatcher.fireEventImmediately(EventDispatcher.java:834)
> at
> org.apache.felix.framework.util.EventDispatcher.fireBundleEvent(EventDispatcher.java:516)
> at org.apache.felix.framework.Felix.fireBundl
[jira] [Updated] (JCR-3873) CachingDataStore not safe against crashes, corrupted uploads file will prevent system from starting up
[
https://issues.apache.org/jira/browse/JCR-3873?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexander Klimetschek updated JCR-3873:
---
Summary: CachingDataStore not safe against crashes, corrupted uploads file
will prevent system from starting up (was: CachingDataStore not safe against
crashes, corrupted uploads file will prevent system to start up again)
> CachingDataStore not safe against crashes, corrupted uploads file will
> prevent system from starting up
> --
>
> Key: JCR-3873
> URL: https://issues.apache.org/jira/browse/JCR-3873
> Project: Jackrabbit Content Repository
> Issue Type: Bug
> Components: jackrabbit-data
>Affects Versions: 2.9.1
> Reporter: Alexander Klimetschek
>
> An NPE in OAK-2811 lead to the data store not being closed normally on
> shutdown, in turn leaving the {{async-pending-uploads.ser}} file corrupted
> and then on the next startup, the CachingDataStore failed to start up,
> preventing the repository and the system from starting:
> {noformat}
> 24.04.2015 13:21:28.602 *ERROR* [FelixStartLevel]
> org.apache.jackrabbit.oak-core
> [org.apache.jackrabbit.oak.plugins.blob.datastore.S3DataStore(79)] The
> activate method has thrown an exception (javax.jcr.RepositoryException:
> java.io.EOFException)
> javax.jcr.RepositoryException: java.io.EOFException
> at
> org.apache.jackrabbit.core.data.CachingDataStore.init(CachingDataStore.java:337)
> at
> org.apache.jackrabbit.oak.plugins.blob.datastore.AbstractDataStoreService.activate(AbstractDataStoreService.java:61)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:606)
> at
> org.apache.felix.scr.impl.helper.BaseMethod.invokeMethod(BaseMethod.java:222)
> at
> org.apache.felix.scr.impl.helper.BaseMethod.access$500(BaseMethod.java:37)
> at
> org.apache.felix.scr.impl.helper.BaseMethod$Resolved.invoke(BaseMethod.java:615)
> at
> org.apache.felix.scr.impl.helper.BaseMethod.invoke(BaseMethod.java:499)
> at
> org.apache.felix.scr.impl.helper.ActivateMethod.invoke(ActivateMethod.java:295)
> at
> org.apache.felix.scr.impl.manager.SingleComponentManager.createImplementationObject(SingleComponentManager.java:302)
> at
> org.apache.felix.scr.impl.manager.SingleComponentManager.createComponent(SingleComponentManager.java:113)
> at
> org.apache.felix.scr.impl.manager.SingleComponentManager.getService(SingleComponentManager.java:832)
> at
> org.apache.felix.scr.impl.manager.SingleComponentManager.getServiceInternal(SingleComponentManager.java:799)
> at
> org.apache.felix.scr.impl.manager.AbstractComponentManager.activateInternal(AbstractComponentManager.java:724)
> at
> org.apache.felix.scr.impl.manager.AbstractComponentManager.enable(AbstractComponentManager.java:399)
> at
> org.apache.felix.scr.impl.config.ConfigurableComponentHolder.enableComponents(ConfigurableComponentHolder.java:669)
> at
> org.apache.felix.scr.impl.BundleComponentActivator.initialEnable(BundleComponentActivator.java:184)
> at
> org.apache.felix.scr.impl.Activator.loadComponents(Activator.java:332)
> at org.apache.felix.scr.impl.Activator.access$000(Activator.java:49)
> at
> org.apache.felix.scr.impl.Activator$ScrExtension.start(Activator.java:257)
> at
> org.apache.felix.utils.extender.AbstractExtender.createExtension(AbstractExtender.java:259)
> at
> org.apache.felix.utils.extender.AbstractExtender.modifiedBundle(AbstractExtender.java:232)
> at
> org.osgi.util.tracker.BundleTracker$Tracked.customizerModified(BundleTracker.java:482)
> at
> org.osgi.util.tracker.BundleTracker$Tracked.customizerModified(BundleTracker.java:415)
> at org.osgi.util.tracker.AbstractTracked.track(AbstractTracked.java:232)
> at
> org.osgi.util.tracker.BundleTracker$Tracked.bundleChanged(BundleTracker.java:444)
> at
> org.apache.felix.framework.util.EventDispatcher.invokeBundleListenerCallback(EventDispatcher.java:913)
> at
> org.apache.felix.framework.util.EventDispatcher.fireEventImmediately(EventDispatcher.java:834)
> at
> org.apache.felix.framework.util.EventDispatcher.fireBundleEvent(EventDispatcher.java:516
[jira] [Created] (JCR-3873) CachingDataStore not safe against crashes, corrupted uploads file will prevent system to start up again
Alexander Klimetschek created JCR-3873:
--
Summary: CachingDataStore not safe against crashes, corrupted
uploads file will prevent system to start up again
Key: JCR-3873
URL: https://issues.apache.org/jira/browse/JCR-3873
Project: Jackrabbit Content Repository
Issue Type: Bug
Components: jackrabbit-data
Affects Versions: 2.9.1
Reporter: Alexander Klimetschek
An NPE in OAK-2811 lead to the data store not being closed normally on
shutdown, in turn leaving the {{async-pending-uploads.ser}} file corrupted and
then on the next startup, the CachingDataStore failed to start up, preventing
the repository and the system from starting:
{noformat}
24.04.2015 13:21:28.602 *ERROR* [FelixStartLevel]
org.apache.jackrabbit.oak-core
[org.apache.jackrabbit.oak.plugins.blob.datastore.S3DataStore(79)] The activate
method has thrown an exception (javax.jcr.RepositoryException:
java.io.EOFException)
javax.jcr.RepositoryException: java.io.EOFException
at
org.apache.jackrabbit.core.data.CachingDataStore.init(CachingDataStore.java:337)
at
org.apache.jackrabbit.oak.plugins.blob.datastore.AbstractDataStoreService.activate(AbstractDataStoreService.java:61)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:606)
at
org.apache.felix.scr.impl.helper.BaseMethod.invokeMethod(BaseMethod.java:222)
at
org.apache.felix.scr.impl.helper.BaseMethod.access$500(BaseMethod.java:37)
at
org.apache.felix.scr.impl.helper.BaseMethod$Resolved.invoke(BaseMethod.java:615)
at
org.apache.felix.scr.impl.helper.BaseMethod.invoke(BaseMethod.java:499)
at
org.apache.felix.scr.impl.helper.ActivateMethod.invoke(ActivateMethod.java:295)
at
org.apache.felix.scr.impl.manager.SingleComponentManager.createImplementationObject(SingleComponentManager.java:302)
at
org.apache.felix.scr.impl.manager.SingleComponentManager.createComponent(SingleComponentManager.java:113)
at
org.apache.felix.scr.impl.manager.SingleComponentManager.getService(SingleComponentManager.java:832)
at
org.apache.felix.scr.impl.manager.SingleComponentManager.getServiceInternal(SingleComponentManager.java:799)
at
org.apache.felix.scr.impl.manager.AbstractComponentManager.activateInternal(AbstractComponentManager.java:724)
at
org.apache.felix.scr.impl.manager.AbstractComponentManager.enable(AbstractComponentManager.java:399)
at
org.apache.felix.scr.impl.config.ConfigurableComponentHolder.enableComponents(ConfigurableComponentHolder.java:669)
at
org.apache.felix.scr.impl.BundleComponentActivator.initialEnable(BundleComponentActivator.java:184)
at
org.apache.felix.scr.impl.Activator.loadComponents(Activator.java:332)
at org.apache.felix.scr.impl.Activator.access$000(Activator.java:49)
at
org.apache.felix.scr.impl.Activator$ScrExtension.start(Activator.java:257)
at
org.apache.felix.utils.extender.AbstractExtender.createExtension(AbstractExtender.java:259)
at
org.apache.felix.utils.extender.AbstractExtender.modifiedBundle(AbstractExtender.java:232)
at
org.osgi.util.tracker.BundleTracker$Tracked.customizerModified(BundleTracker.java:482)
at
org.osgi.util.tracker.BundleTracker$Tracked.customizerModified(BundleTracker.java:415)
at org.osgi.util.tracker.AbstractTracked.track(AbstractTracked.java:232)
at
org.osgi.util.tracker.BundleTracker$Tracked.bundleChanged(BundleTracker.java:444)
at
org.apache.felix.framework.util.EventDispatcher.invokeBundleListenerCallback(EventDispatcher.java:913)
at
org.apache.felix.framework.util.EventDispatcher.fireEventImmediately(EventDispatcher.java:834)
at
org.apache.felix.framework.util.EventDispatcher.fireBundleEvent(EventDispatcher.java:516)
at org.apache.felix.framework.Felix.fireBundleEvent(Felix.java:4531)
at org.apache.felix.framework.Felix.startBundle(Felix.java:2169)
at org.apache.felix.framework.Felix.setActiveStartLevel(Felix.java:1368)
at
org.apache.felix.framework.FrameworkStartLevelImpl.run(FrameworkStartLevelImpl.java:308)
at java.lang.Thread.run(Thread.java:745)
Caused by: java.io.EOFException: null
at
java.io.ObjectInputStream$PeekInputStream.readFully(ObjectInputStream.java:2325)
at
java.io.ObjectInputStream$BlockDataInputStream.readShort(ObjectInputStream.java:2794)
at
java.io.ObjectInputStream.readStreamHeader(ObjectInputStream.java:801)
at java.io.ObjectInputStream.(ObjectInputStream.java:299)
at
Re: How to restore deleted Jackrabbit Repository directory?
On 08.08.2014, at 07:50, cpaulson wrote:
> Repository home directory is crashed/deleted. But the DB system configured
> with repository still holds its data.
>
> After the crash, I run the repository again and repository home directory is
> restored back. But Workspace that i have created is lost not restored back.
Depending on the configuration, there are some vital things stored in the home
and workspace dirs, including node types, namespaces, search indexes (inside
the workspace). If these have changes compared to the out of the box defaults,
they are lost. But maybe you are lucky and most data is in the DB.
But I see you are using the FileDataStore, which by default is under
repository/datastore IIRC, if that is really lost, all your binaries (nt:files)
will be gone...
When there is no home directory, Jackrabbit will create a plain one, that's not
actually "restoring" (since there is no backup to restore from).
For the workspaces, you need to set up a workspace directory plus a
workspace.xml for the specific workspace(s) you had. (The part in
repository.xml is only used as template when you call
Repository.createWorkspace() or whatever the name of the API is).
What I would do is:
- make a backup of your DB and everything that's still there (to avoid
overwriting it when trying the steps below)
- add the workspace directory with a workspace.xml based on and
replace the placeholders such as ${wsp.name}
- (you might want to create a new workspace to see how it looks like)
- ensure the settings map to your existing DB
- if still available, restore the file data store at repository/datastore
(please check, not sure if that is the default location)
- start Jackrabbit
- the search index should reindex itself from scratch, would block the startup
until it's down IIRC
- figure out if you had any custom node types etc., check the logs on errors
and/or simply test your application
Good luck!
Alex
Re: Shellshock (CVE-2014-6271, CVE-2014-7169, CVE-2014-7186, CVE-2014-7187, CVE-2014-6277)
Jackrabbit itself doesn't use cgi or bash scripts. Cheers, Alex On 29.09.2014, at 12:59, Ricardo Iramar dos Santos wrote: > Hi All, > > Probably you've already heard about Shellshock > (https://shellshocker.net) in the last few days and I didn't find any > discussion about it here. > Some of the projects that I work for are using jackrabbit 2.8 and I'd > like to know from jackrabbit developers if we should concerning about > shellshock. > I don't think that it could have any impact but I decided just open > the discussion here so maybe any expert could give some tip. > > Thanks > Ricardo
Re: New Jackrabbit committer: Amit Jain
Welcome, Amit! Alex On 26.08.2014, at 13:06, Michael Dürig wrote: > Hi, > > Please welcome Amit Jain as a new committer and PMC member of > the Apache Jackrabbit project. The Jackrabbit PMC recently decided to > offer Amit 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, Amit! > > Michael >
Re: How to do Multiple repository system
On 05.08.2014, at 23:50, cpaulson wrote: > I am trying to design multi-tenant system. Need to create separate repository > for each organization. Is that possible to do that. Generally, you have 2 options: a) share the repository, design multi-tenant content structures, make sure to shield them from each other using ACLs; can be more efficient (just on JVM etc.) b) use separate repositories; requires one JVM for each, separate underlying storage, request routing to different instances, more outside configuration/deployment overhead > If it is possible then > how to share User management information between repositories. With a), you can use the built-in user management, you just have to make sure user ids from different tenants are separate, e.g. "b...@foocompany.com" vs. "b...@acme.com". With b), you could use ldap (built in with Oak) or another external mechanism by using JAAS / a custom LoginModule. [1] http://jackrabbit.apache.org/oak/docs/security/authentication/ldap.html HTH, Alex
Re: Adding further filtering capabilities to JackrabbitEventFilter
On 04.08.2014, at 00:41, Michael Dürig wrote: >> I think it would be more useful to allow globbing paths. The current >> getAdditionalPaths() could be changed to allow path globbing. > > This already exists in Oak. See > org.apache.jackrabbit.oak.plugins.observation.filter.GlobbingPathFilter. Ah, great. But I can't register this using the JCR API, right? I would need to set up the whole observation listener through oak apis? Cheers, Alex
Re: Adding further filtering capabilities to JackrabbitEventFilter
On 21.07.2014, at 00:23, Michael Dürig wrote: > On 16.7.14 4:12 , Michael Dürig wrote: >> >> - Path exclusion would allow certain paths to be excluded from sending >> events. This is helpful if you want to listen to say /content but not to >> /content/foo. Relieving event handlers from handling such exclusions >> will lower client code complexity and increase performance. > > I created JCR-3797 and OAK-1978 to track this. I think it would be more useful to allow globbing paths. The current getAdditionalPaths() could be changed to allow path globbing. For example /home/users/**/mail/**/sentitems/** (Could also be regular expressions) This when you don't use very detailed node types, but rely more on path structures. We have a lot of use cases of that in our product. I have previously mentioned that over in [1]. [1] https://issues.apache.org/jira/browse/OAK-1133 Cheers, Alex
[jira] [Commented] (JCR-3799) Setting large binary value on jcr:data property fails over RMI
[ https://issues.apache.org/jira/browse/JCR-3799?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14083250#comment-14083250 ] Alexander Klimetschek commented on JCR-3799: There was JCR-2531 and the fix https://fisheye6.atlassian.com/changelog/jackrabbit?cs=918496. Maybe it's simply the maximum serialization size that RMI allows? > Setting large binary value on jcr:data property fails over RMI > -- > > Key: JCR-3799 > URL: https://issues.apache.org/jira/browse/JCR-3799 > Project: Jackrabbit Content Repository > Issue Type: Bug > Components: jackrabbit-jcr-rmi >Affects Versions: 2.6.5 > Environment: Any >Reporter: Harish Reddy > > Setting a very large binary value on the jcr:data property fails and throws > an an exception at line 187 in the 2.6.5 source > (org.apache.jackrabbit.rmi.value.SerializableBinary.java) > This appears to be a problem with converting a long variable into a > int at line 187. > n = stream.read(buffer, 0, Math.min( > buffer.length, (int) (length - count))); > The problem occurs only when the length of the binary exceeds a number that > can't fit in an int (in my test case, length was 3245027213). > Other parts of SerializableBinary.java also appear to be casting length to an > int, so I'm guessing all instances of this pattern will need to be fixed. > I'm using 2.6.5, so don't know if the issue exists in earlier 2.x versions as > well. This used to work in v 1.5.4. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (JCR-3799) Setting large binary value on jcr:data property fails over RMI
[ https://issues.apache.org/jira/browse/JCR-3799?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexander Klimetschek updated JCR-3799: --- Summary: Setting large binary value on jcr:data property fails over RMI (was: Setting large binary value on jcr:data property fails) > Setting large binary value on jcr:data property fails over RMI > -- > > Key: JCR-3799 > URL: https://issues.apache.org/jira/browse/JCR-3799 > Project: Jackrabbit Content Repository > Issue Type: Bug > Components: jackrabbit-jcr-rmi >Affects Versions: 2.6.5 > Environment: Any >Reporter: Harish Reddy > > Setting a very large binary value on the jcr:data property fails and throws > an an exception at line 187 in the 2.6.5 source > (org.apache.jackrabbit.rmi.value.SerializableBinary.java) > This appears to be a problem with converting a long variable into a > int at line 187. > n = stream.read(buffer, 0, Math.min( > buffer.length, (int) (length - count))); > The problem occurs only when the length of the binary exceeds a number that > can't fit in an int (in my test case, length was 3245027213). > Other parts of SerializableBinary.java also appear to be casting length to an > int, so I'm guessing all instances of this pattern will need to be fixed. > I'm using 2.6.5, so don't know if the issue exists in earlier 2.x versions as > well. This used to work in v 1.5.4. -- This message was sent by Atlassian JIRA (v6.2#6252)
Re: New Jackrabbit committer: Davide Giannella
Welcome! Nice to see you landing at Apache after we first met at a customer in the UK a couple years ago :) Cheers, Alex On 04.06.2014, at 06:17, Jukka Zitting wrote: > Hi, > > Please welcome Davide Giannella as a new committer and PMC member of > the Apache Jackrabbit project. The Jackrabbit PMC recently decided to > offer Davide committership based on his contributions and continuing > work to Oak. He accepted the offer and has just made his first commit. > > Welcome to the team, Davide! > > BR, > > Jukka Zitting
Re: Post Jackrabbit 2.8
On 27.05.2014, at 06:54, Angela Schreiber wrote: > makes sense to me... if you don't mind i would opt for keeping > 3.0 reserved for that unified *rabbit and set the current > version to 2.9-SNAPSHOT to avoid confusions and not putting > too much pressure on us to complete the merge. +1 To the outside, Oak = Jackrabbit 3.0, it would be hard to change that perception :) Cheers, Alex
[jira] [Updated] (JCR-3777) Add simple allow/deny/clear convenience methods to AccessControlUtils
[
https://issues.apache.org/jira/browse/JCR-3777?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexander Klimetschek updated JCR-3777:
---
Fix Version/s: (was: 2.8)
> Add simple allow/deny/clear convenience methods to AccessControlUtils
> -
>
> Key: JCR-3777
> URL: https://issues.apache.org/jira/browse/JCR-3777
> Project: Jackrabbit Content Repository
> Issue Type: Improvement
> Components: jackrabbit-jcr-commons
> Reporter: Alexander Klimetschek
> Assignee: Alexander Klimetschek
>Priority: Minor
> Attachments: JCR-3777.patch
>
>
> Add these short convenience methods:
> {code}
> AccessControlUtils.clear(node, "user");
> AccessControlUtils.allow(node, "user", Privilege.JCR_READ,
> Privilege.JCR_WRITE);
> AccessControlUtils.deny(node, "user", Privilege.JCR_REMOVE_NODE);
> AccessControlUtils.clear(node); // remove all entries for all users
> {code}
> Useful for unit tests or other places where you need to set ACLs from code.
> Uses varargs for the privilege list, and uses the first argument node for
> both the path and the session to use.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Resolved] (JCR-3777) Add simple allow/deny/clear convenience methods to AccessControlUtils
[
https://issues.apache.org/jira/browse/JCR-3777?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexander Klimetschek resolved JCR-3777.
Resolution: Fixed
> Add simple allow/deny/clear convenience methods to AccessControlUtils
> -
>
> Key: JCR-3777
> URL: https://issues.apache.org/jira/browse/JCR-3777
> Project: Jackrabbit Content Repository
> Issue Type: Improvement
> Components: jackrabbit-jcr-commons
> Reporter: Alexander Klimetschek
> Assignee: Alexander Klimetschek
>Priority: Minor
> Attachments: JCR-3777.patch
>
>
> Add these short convenience methods:
> {code}
> AccessControlUtils.clear(node, "user");
> AccessControlUtils.allow(node, "user", Privilege.JCR_READ,
> Privilege.JCR_WRITE);
> AccessControlUtils.deny(node, "user", Privilege.JCR_REMOVE_NODE);
> AccessControlUtils.clear(node); // remove all entries for all users
> {code}
> Useful for unit tests or other places where you need to set ACLs from code.
> Uses varargs for the privilege list, and uses the first argument node for
> both the path and the session to use.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
Re: Add simple allow/deny/clear convenience methods to AccessControlUtils
ping... just wanted quick feedback before pushing these few utility methods. Alex On 30.04.2014, at 17:38, Alexander Klimetschek wrote: > See https://issues.apache.org/jira/browse/JCR-3777 > > WDYT? > > Patch is attached. If ok, I can commit it (would be my first commit in ages > :)). > > Cheers, > Alex
Add simple allow/deny/clear convenience methods to AccessControlUtils
See https://issues.apache.org/jira/browse/JCR-3777 WDYT? Patch is attached. If ok, I can commit it (would be my first commit in ages :)). Cheers, Alex
[jira] [Updated] (JCR-3777) Add simple allow/deny/clear convenience methods to AccessControlUtils
[
https://issues.apache.org/jira/browse/JCR-3777?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexander Klimetschek updated JCR-3777:
---
Attachment: JCR-3777.patch
Attached patch: [^JCR-3777.patch]
> Add simple allow/deny/clear convenience methods to AccessControlUtils
> -
>
> Key: JCR-3777
> URL: https://issues.apache.org/jira/browse/JCR-3777
> Project: Jackrabbit Content Repository
> Issue Type: Improvement
> Components: jackrabbit-jcr-commons
> Reporter: Alexander Klimetschek
>Priority: Minor
> Fix For: 2.8
>
> Attachments: JCR-3777.patch
>
>
> Add these short convenience methods:
> {code}
> AccessControlUtils.clear(node, "user");
> AccessControlUtils.allow(node, "user", Privilege.JCR_READ,
> Privilege.JCR_WRITE);
> AccessControlUtils.deny(node, "user", Privilege.JCR_REMOVE_NODE);
> AccessControlUtils.clear(node); // remove all entries for all users
> {code}
> Useful for unit tests or other places where you need to set ACLs from code.
> Uses varargs for the privilege list, and uses the first argument node for
> both the path and the session to use.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Assigned] (JCR-3777) Add simple allow/deny/clear convenience methods to AccessControlUtils
[
https://issues.apache.org/jira/browse/JCR-3777?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexander Klimetschek reassigned JCR-3777:
--
Assignee: Alexander Klimetschek
> Add simple allow/deny/clear convenience methods to AccessControlUtils
> -
>
> Key: JCR-3777
> URL: https://issues.apache.org/jira/browse/JCR-3777
> Project: Jackrabbit Content Repository
> Issue Type: Improvement
> Components: jackrabbit-jcr-commons
> Reporter: Alexander Klimetschek
> Assignee: Alexander Klimetschek
>Priority: Minor
> Fix For: 2.8
>
> Attachments: JCR-3777.patch
>
>
> Add these short convenience methods:
> {code}
> AccessControlUtils.clear(node, "user");
> AccessControlUtils.allow(node, "user", Privilege.JCR_READ,
> Privilege.JCR_WRITE);
> AccessControlUtils.deny(node, "user", Privilege.JCR_REMOVE_NODE);
> AccessControlUtils.clear(node); // remove all entries for all users
> {code}
> Useful for unit tests or other places where you need to set ACLs from code.
> Uses varargs for the privilege list, and uses the first argument node for
> both the path and the session to use.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Created] (JCR-3777) Add simple allow/deny/clear convenience methods to AccessControlUtils
Alexander Klimetschek created JCR-3777:
--
Summary: Add simple allow/deny/clear convenience methods to
AccessControlUtils
Key: JCR-3777
URL: https://issues.apache.org/jira/browse/JCR-3777
Project: Jackrabbit Content Repository
Issue Type: Improvement
Components: jackrabbit-jcr-commons
Reporter: Alexander Klimetschek
Priority: Minor
Fix For: 2.8
Add these short convenience methods:
{code}
AccessControlUtils.clear(node, "user");
AccessControlUtils.allow(node, "user", Privilege.JCR_READ, Privilege.JCR_WRITE);
AccessControlUtils.deny(node, "user", Privilege.JCR_REMOVE_NODE);
AccessControlUtils.clear(node); // remove all entries for all users
{code}
Useful for unit tests or other places where you need to set ACLs from code.
Uses varargs for the privilege list, and uses the first argument node for both
the path and the session to use.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
Re: Webdav upload large files
Guessing: This might be a request body size limit in the servlet container being used. Cheers, Alex On 24.02.2014, at 03:41, Станиславский Константин wrote: > Hello, > > I am trying to use jackrabbit and Sardine library to upload files to Webdav > server. > Everything is just perfect excepti uploading big files. > When I try to upload bigger than several KB files, > the httpclient used by both libraries returns java.net.SocketException: > Connection reset by peer: socket write error > > In Sardine it is hidden (by showing the first lines without the exception) > but the real error is: > > From Sardine: > Feb 24, 2014 1:36:38 PM org.apache.http.impl.client.DefaultHttpClient > tryExecute > INFO: I/O exception (java.net.SocketException) caught when processing > request: Socket Closed > Feb 24, 2014 1:36:38 PM org.apache.http.impl.client.DefaultHttpClient > tryExecute > INFO: Retrying request > > From Jackrabbit: > Feb 24, 2014 1:22:40 PM org.apache.commons.httpclient.HttpMethodDirector > executeWithRetry > INFO: I/O exception (java.net.SocketException) caught when processing > request: Connection reset by peer: socket write error > Feb 24, 2014 1:22:40 PM org.apache.commons.httpclient.HttpMethodDirector > executeWithRetry > INFO: Retrying request > ERR C:\Test\TestWebDav.zip > java.net.SocketException: Connection reset by peer: socket write error > at java.net.SocketOutputStream.socketWrite0(Native Method) > at java.net.SocketOutputStream.socketWrite(SocketOutputStream.java:113) > at java.net.SocketOutputStream.write(SocketOutputStream.java:159) > at sun.security.ssl.OutputRecord.writeBuffer(OutputRecord.java:377) > at sun.security.ssl.OutputRecord.write(OutputRecord.java:363) > at > sun.security.ssl.SSLSocketImpl.writeRecordInternal(SSLSocketImpl.java:830) > at sun.security.ssl.SSLSocketImpl.writeRecord(SSLSocketImpl.java:801) > at sun.security.ssl.AppOutputStream.write(AppOutputStream.java:122) > at java.io.BufferedOutputStream.write(BufferedOutputStream.java:122) > at java.io.FilterOutputStream.write(FilterOutputStream.java:97) > at > org.apache.commons.httpclient.methods.InputStreamRequestEntity.writeRequest(InputStreamRequestEntity.java:175) > at > org.apache.commons.httpclient.methods.EntityEnclosingMethod.writeRequestBody(EntityEnclosingMethod.java:499) > at > org.apache.commons.httpclient.HttpMethodBase.writeRequest(HttpMethodBase.java:2114) > at > org.apache.commons.httpclient.HttpMethodBase.execute(HttpMethodBase.java:1096) > at > org.apache.commons.httpclient.HttpMethodDirector.executeWithRetry(HttpMethodDirector.java:398) > at > org.apache.commons.httpclient.HttpMethodDirector.executeMethod(HttpMethodDirector.java:171) > at > org.apache.commons.httpclient.HttpClient.executeMethod(HttpClient.java:397) > at > org.apache.commons.httpclient.HttpClient.executeMethod(HttpClient.java:323) > at com.transfer.JackrabbitManager.uploadFile(JackrabbitManager.java:287) > at Main.main(Main.java:38) > > They use different versions of httpclient (~v 3.1). > > Do you have an Idea how to fix this problem?
[jira] [Commented] (JCR-3705) Extract data store API and implementations from jackrabbit-core
[ https://issues.apache.org/jira/browse/JCR-3705?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13886642#comment-13886642 ] Alexander Klimetschek commented on JCR-3705: Renaming packages & moving classes between packages should be ok, since all the jackrabbit-core classes haven't been exposed as external API yet. > 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 > Labels: patch > Attachments: JCR-3705.patch > > > 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.5#6160)
[jira] [Commented] (JCR-3705) Extract data store API and implementations from jackrabbit-core
[ https://issues.apache.org/jira/browse/JCR-3705?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13886039#comment-13886039 ] Alexander Klimetschek commented on JCR-3705: I don't think this belongs into jackrabbit-jcr-commons. Commons is something that is intended to be used by JCR API clients as well, which I don't see for many of those classes. These are a kind of SPI commons - some base classes that a custom DataStore implementation would find useful, but that is an SPI for extending Jackrabbit, not an API. For that I think there is jackrabbit-spi-commons, although I wonder why this can't be in jackrabbit-data, and jackrabbit-core has a dependency on it? > 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 > Labels: patch > Attachments: JCR-3705.patch > > > 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.5#6160)
[jira] [Commented] (JCR-3713) NPE in GQL if it starts with OR expression
[
https://issues.apache.org/jira/browse/JCR-3713?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13866260#comment-13866260
]
Alexander Klimetschek commented on JCR-3713:
The fix should be simple: if "conditions" is empty, simply add the expression
directly and ignore optional (OR).
> NPE in GQL if it starts with OR expression
> --
>
> Key: JCR-3713
> URL: https://issues.apache.org/jira/browse/JCR-3713
> Project: Jackrabbit Content Repository
> Issue Type: Bug
> Components: jackrabbit-jcr-commons
>Affects Versions: 2.7.3
>Reporter: Alexander Klimetschek
>
> These GQL queries lead to an NPE:
> OR property:something
> path:/content OR property:something
> This is because GQL#pushExpression() will blindly replace the previous entry
> in the "conditions" list, even if it is still empty.
> {code}
> Caused by: java.lang.ArrayIndexOutOfBoundsException: -1
> at java.util.ArrayList.get(ArrayList.java:324)
> at org.apache.jackrabbit.commons.query.GQL.pushExpression(GQL.java:798)
> at org.apache.jackrabbit.commons.query.GQL.access$000(GQL.java:133)
> at org.apache.jackrabbit.commons.query.GQL$1.term(GQL.java:426)
> at org.apache.jackrabbit.commons.query.GQL.parse(GQL.java:682)
> at
> org.apache.jackrabbit.commons.query.GQL.translateStatement(GQL.java:423)
> at org.apache.jackrabbit.commons.query.GQL.execute(GQL.java:389)
> at org.apache.jackrabbit.commons.query.GQL.execute(GQL.java:322)
> {code}
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
[jira] [Updated] (JCR-3713) Exception in GQL if it starts with OR expression
[
https://issues.apache.org/jira/browse/JCR-3713?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexander Klimetschek updated JCR-3713:
---
Summary: Exception in GQL if it starts with OR expression (was: NPE in GQL
if it starts with OR expression)
> Exception in GQL if it starts with OR expression
>
>
> Key: JCR-3713
> URL: https://issues.apache.org/jira/browse/JCR-3713
> Project: Jackrabbit Content Repository
> Issue Type: Bug
> Components: jackrabbit-jcr-commons
>Affects Versions: 2.7.3
> Reporter: Alexander Klimetschek
>
> These GQL queries lead to an NPE:
> OR property:something
> path:/content OR property:something
> This is because GQL#pushExpression() will blindly replace the previous entry
> in the "conditions" list, even if it is still empty.
> {code}
> Caused by: java.lang.ArrayIndexOutOfBoundsException: -1
> at java.util.ArrayList.get(ArrayList.java:324)
> at org.apache.jackrabbit.commons.query.GQL.pushExpression(GQL.java:798)
> at org.apache.jackrabbit.commons.query.GQL.access$000(GQL.java:133)
> at org.apache.jackrabbit.commons.query.GQL$1.term(GQL.java:426)
> at org.apache.jackrabbit.commons.query.GQL.parse(GQL.java:682)
> at
> org.apache.jackrabbit.commons.query.GQL.translateStatement(GQL.java:423)
> at org.apache.jackrabbit.commons.query.GQL.execute(GQL.java:389)
> at org.apache.jackrabbit.commons.query.GQL.execute(GQL.java:322)
> {code}
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
[jira] [Updated] (JCR-3713) Exception in GQL if it starts with OR expression
[
https://issues.apache.org/jira/browse/JCR-3713?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexander Klimetschek updated JCR-3713:
---
Description:
These GQL queries lead to an ArrayIndexOutOfBoundsException:
OR property:something
path:/content OR property:something
This is because GQL#pushExpression() will blindly replace the previous entry in
the "conditions" list, even if it is still empty.
{code}
Caused by: java.lang.ArrayIndexOutOfBoundsException: -1
at java.util.ArrayList.get(ArrayList.java:324)
at org.apache.jackrabbit.commons.query.GQL.pushExpression(GQL.java:798)
at org.apache.jackrabbit.commons.query.GQL.access$000(GQL.java:133)
at org.apache.jackrabbit.commons.query.GQL$1.term(GQL.java:426)
at org.apache.jackrabbit.commons.query.GQL.parse(GQL.java:682)
at
org.apache.jackrabbit.commons.query.GQL.translateStatement(GQL.java:423)
at org.apache.jackrabbit.commons.query.GQL.execute(GQL.java:389)
at org.apache.jackrabbit.commons.query.GQL.execute(GQL.java:322)
{code}
was:
These GQL queries lead to an NPE:
OR property:something
path:/content OR property:something
This is because GQL#pushExpression() will blindly replace the previous entry in
the "conditions" list, even if it is still empty.
{code}
Caused by: java.lang.ArrayIndexOutOfBoundsException: -1
at java.util.ArrayList.get(ArrayList.java:324)
at org.apache.jackrabbit.commons.query.GQL.pushExpression(GQL.java:798)
at org.apache.jackrabbit.commons.query.GQL.access$000(GQL.java:133)
at org.apache.jackrabbit.commons.query.GQL$1.term(GQL.java:426)
at org.apache.jackrabbit.commons.query.GQL.parse(GQL.java:682)
at
org.apache.jackrabbit.commons.query.GQL.translateStatement(GQL.java:423)
at org.apache.jackrabbit.commons.query.GQL.execute(GQL.java:389)
at org.apache.jackrabbit.commons.query.GQL.execute(GQL.java:322)
{code}
> Exception in GQL if it starts with OR expression
>
>
> Key: JCR-3713
> URL: https://issues.apache.org/jira/browse/JCR-3713
> Project: Jackrabbit Content Repository
> Issue Type: Bug
> Components: jackrabbit-jcr-commons
>Affects Versions: 2.7.3
>Reporter: Alexander Klimetschek
>
> These GQL queries lead to an ArrayIndexOutOfBoundsException:
> OR property:something
> path:/content OR property:something
> This is because GQL#pushExpression() will blindly replace the previous entry
> in the "conditions" list, even if it is still empty.
> {code}
> Caused by: java.lang.ArrayIndexOutOfBoundsException: -1
> at java.util.ArrayList.get(ArrayList.java:324)
> at org.apache.jackrabbit.commons.query.GQL.pushExpression(GQL.java:798)
> at org.apache.jackrabbit.commons.query.GQL.access$000(GQL.java:133)
> at org.apache.jackrabbit.commons.query.GQL$1.term(GQL.java:426)
> at org.apache.jackrabbit.commons.query.GQL.parse(GQL.java:682)
> at
> org.apache.jackrabbit.commons.query.GQL.translateStatement(GQL.java:423)
> at org.apache.jackrabbit.commons.query.GQL.execute(GQL.java:389)
> at org.apache.jackrabbit.commons.query.GQL.execute(GQL.java:322)
> {code}
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
[jira] [Created] (JCR-3713) NPE in GQL if it starts with OR expression
Alexander Klimetschek created JCR-3713:
--
Summary: NPE in GQL if it starts with OR expression
Key: JCR-3713
URL: https://issues.apache.org/jira/browse/JCR-3713
Project: Jackrabbit Content Repository
Issue Type: Bug
Components: jackrabbit-jcr-commons
Affects Versions: 2.7.3
Reporter: Alexander Klimetschek
These GQL queries lead to an NPE:
OR property:something
path:/content OR property:something
This is because GQL#pushExpression() will blindly replace the previous entry in
the "conditions" list, even if it is still empty.
{code}
Caused by: java.lang.ArrayIndexOutOfBoundsException: -1
at java.util.ArrayList.get(ArrayList.java:324)
at org.apache.jackrabbit.commons.query.GQL.pushExpression(GQL.java:798)
at org.apache.jackrabbit.commons.query.GQL.access$000(GQL.java:133)
at org.apache.jackrabbit.commons.query.GQL$1.term(GQL.java:426)
at org.apache.jackrabbit.commons.query.GQL.parse(GQL.java:682)
at
org.apache.jackrabbit.commons.query.GQL.translateStatement(GQL.java:423)
at org.apache.jackrabbit.commons.query.GQL.execute(GQL.java:389)
at org.apache.jackrabbit.commons.query.GQL.execute(GQL.java:322)
{code}
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
[jira] [Commented] (JCR-3705) Extract data store API and implementations from jackrabbit-core
[ https://issues.apache.org/jira/browse/JCR-3705?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13838624#comment-13838624 ] Alexander Klimetschek commented on JCR-3705: You are right. I was just looking at the [published javadoc|http://jackrabbit.apache.org/api/2.0/org/apache/jackrabbit/core/data/DataStore.html] which says "Jackrabbit API 2.0" in the title, but didn't notice the different package name. I guess the javadocs are aggregated from not just the jackrabbit-api module. > 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-3705) Extract data store API and implementations from jackrabbit-core
[ https://issues.apache.org/jira/browse/JCR-3705?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13838058#comment-13838058 ] Alexander Klimetschek commented on JCR-3705: +1 for a new jackrabbit-data component (the [DataStore API is in jackrabbit-api|http://jackrabbit.apache.org/api/2.0/org/apache/jackrabbit/core/data/DataStore.html], but I assume oak depends on that anyway) > 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)
Re: Spring jcr version to use with Jack Rabbit 2.6.3
The spring jcr module is not developed by the Apache Jackrabbit. AFAIU it is inactive for a number of years already. But you don't need it to use JCR withing Spring applications. What it does is IMHO a bad approach with JCR anyway - it sees JCR as just another DAO/OCR framework and uses template callbacks etc. to make it completely transparent to the user how the JCR session underneath is managed. This is a bad thing, it is important to control the session (login, lifecycle usually per request, and exact save() or refresh() points) yourself. A usueful approach is: - to have maybe a servlet filter etc. auto-create the session at the start of the request and use whatever authentication you have over HTTP coming in to login the right user for the session and - provide that to your servlets in e.g. a request attribute. - session.save() would be up to servlets that actually change something (e.g. POST or PUT requests) - background services outside a request would create their own session with e.g. a service user You don't need the spring jcr module for this. Also, you might want to look at Apache Sling, which follows the above pattern. Cheers, Alex On 29.08.2013, at 02:35, sumit tiwari wrote: > Hi All, > > I am planning to use jack rabbit with spring. I am seeing that spring jcr > version 0.8 and 0.9 looks for old jsr170 jar and fails out. > > > [ERROR] Failed to execute goal on project xyz: Could not resolve dependencies > for project com.test.xyq:war:2.4.2: The following artifacts could not be > resolved: jsr170:jsr170:jar:1.0, jeceira:jeceira:jar:0.1.3, > aparzev:doka:jar:0.1, aparzev:commons:jar:0.2, jug:jug-asl:jar:2.0.0: Failure > to find jsr170:jsr170:jar:1.0 in http:///nexus/content/groups/cliqrthirdparty > was cached in the local repository, resolution will not be reattempted until > the update interval of has elapsed > http:///nexus/content/groups/cliqrthirdparty or updates are forced -> [Help 1] > > I did the exclusion > > > org.springmodules > spring-modules-jcr > 0.8 > true > > > jackrabbit-core > org.apache.jackrabbit > > > jackrabbit-jca > org.apache.jackrabbit > > > > > I am using it in application-context.xml > > class="org.springmodules.jcr.jackrabbit.RepositoryFactoryBean"> > > value="classpath:/jackrabbit-repository.xml" /> > > > > > Is there any recent spring document which I can refer. I am not keen on using > spring jcr but a good approach in which I can integrate the latest version of > jack rabbit with spring. > > > -- > Thanks, > Sumit > signature.asc Description: Message signed with OpenPGP using GPGMail
Re: [VLT] JIRA component or project?
On 19.08.2013, at 14:23, Tobias Bocanegra wrote: > I suggest to add a new project: > > JCRVLT: Jackrabbit FileVault +1 Cheers, Alex signature.asc Description: Message signed with OpenPGP using GPGMail
Re: Externalizing search
On 31.05.2013, at 17:03, sephiroth75 wrote: > Just another question...theoretically, to obtain what I've described the > only class I've to implement is QueryHandler, haven't I? Not really, as mentioned, this is going to be quite some work if you want to replace it with your own implementation without breaking existing JCR client code relying on JCR queries. I say "replace" since you mention you want to avoid a second index, and existing client code compatibility since you mention this is for a "another sw on top of jackrabbit". Just look at [0] for the curent Lucene implementation that is behind the SearchIndex class. Just to warn you :-) [0] http://svn.apache.org/viewvc/jackrabbit/trunk/jackrabbit-core/src/main/java/org/apache/jackrabbit/core/query/lucene/ Cheers, Alex
Re: Externalizing search
The problem is that this search implementation needs to follow the JCR specification and it does quite a bit of custom code to map JCR properties to Lucene, needs to be fast to not block save() calls too long etc. Some features (user management) might depend on the full JCR query support. So "switching it out with SOLR" is not easy and might lead to more problems than it solves. In Oak [0] therefore the search is seen as a pluggable thing, where you might have the JCR query compatible search index but also others. Oak experts can probably say more about what is currently available or is planned (on oak-...@jackrabbit.apache.org). There is an experimental oak solr integration [1]. What you can do with the existing Jackrabbit is to use an observation listener to update an external index such as Solr asynchronously. [0] http://wiki.apache.org/jackrabbit/Jackrabbit%203 [1] http://slideshare.net/teofili/oak-solr-integration HTH, Alex On 30.05.2013, at 11:24, sephiroth75 wrote: > As far as I understood to substitute the integrated search engine Lucene, > I've to extends the class > org.apache.jackrabbit.core.query.lucene.SearchIndex or implementing > org.apache.jackrabbit.core.query.QueryHandler. How tight is the integration > of Lucene, may I replace it with an external instance for example of SOLR? > Is there any guideline to do it? > The idea is to implement a mechanism of marshalling and unmarshalling of the > parameters passed by method of QueryHandler. > > Thanks in advance for every information about it. > > MC > > > > -- > View this message in context: > http://jackrabbit.510166.n4.nabble.com/Externalizing-search-tp4658790.html > Sent from the Jackrabbit - Dev mailing list archive at Nabble.com.
[jira] [Comment Edited] (JCR-3534) Efficient copying of binaries across repositories with the same data store
[
https://issues.apache.org/jira/browse/JCR-3534?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13659715#comment-13659715
]
Alexander Klimetschek edited comment on JCR-3534 at 5/16/13 5:08 PM:
-
@Tommaso: if storing the key is always data-store specific (such as a special
file in the FileDataStore, which is by far the most important data store, not
sure if anyone is using the slow database data store), you only need a
getSecret() method on the AbstractDataStore class. See my post from above:
https://issues.apache.org/jira/browse/JCR-3534?focusedCommentId=13653621&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13653621
was (Author: alexander.klimetschek):
@Tommaso: if the key is always stored data-store specific (such as a
special file in the FileDataStore, which is by far the most important data
store, not sure if anyone is using the slow database data store), you only need
a getSecret() method on the AbstractDataStore class. See my post from above:
https://issues.apache.org/jira/browse/JCR-3534?focusedCommentId=13653621&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13653621
> Efficient copying of binaries across repositories with the same data store
> --
>
> 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
>Assignee: Tommaso Teofili
> Attachments: JCR-3534.2.patch, JCR-3534.3.patch, JCR-3534.4.patch,
> JCR-3534.6.patch, JCR-3534.patch, 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) Efficient copying of binaries across repositories with the same data store
[
https://issues.apache.org/jira/browse/JCR-3534?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13659715#comment-13659715
]
Alexander Klimetschek commented on JCR-3534:
@Tommaso: if the key is always stored data-store specific (such as a special
file in the FileDataStore, which is by far the most important data store, not
sure if anyone is using the slow database data store), you only need a
getSecret() method on the AbstractDataStore class. See my post from above:
https://issues.apache.org/jira/browse/JCR-3534?focusedCommentId=13653621&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13653621
> Efficient copying of binaries across repositories with the same data store
> --
>
> 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
>Assignee: Tommaso Teofili
> Attachments: JCR-3534.2.patch, JCR-3534.3.patch, JCR-3534.4.patch,
> JCR-3534.6.patch, JCR-3534.patch, 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) Efficient copying of binaries across repositories with the same data store
[
https://issues.apache.org/jira/browse/JCR-3534?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13659466#comment-13659466
]
Alexander Klimetschek commented on JCR-3534:
Putting it in the datastore as outlined above would not necessarily make access
more difficult (assuming repository.xml and datastore directory have similar
ACLs on the file system), but it would reduce user errors:
- blindly copying repository.xml over from another instance with the same
shared secret
- users using weak secrets (instead of a long random auto generated key)
- users having to make sure the secret is synced in addition to sharing the
data store directory
> Efficient copying of binaries across repositories with the same data store
> --
>
> 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
>Assignee: Tommaso Teofili
> Attachments: JCR-3534.2.patch, JCR-3534.3.patch, JCR-3534.4.patch,
> JCR-3534.patch, 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) Efficient copying of binaries across repositories with the same data store
[
https://issues.apache.org/jira/browse/JCR-3534?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13654623#comment-13654623
]
Alexander Klimetschek commented on JCR-3534:
The longer I think about it, we should not have the configuration option at
all. It is not required for now and would avoid all the possible issues such as
accidentally sharing the key etc.
> Efficient copying of binaries across repositories with the same data store
> --
>
> 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
>Assignee: Tommaso Teofili
> Attachments: JCR-3534.2.patch, JCR-3534.3.patch, JCR-3534.4.patch,
> JCR-3534.patch, 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) Efficient copying of binaries across repositories with the same data store
[
https://issues.apache.org/jira/browse/JCR-3534?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13654425#comment-13654425
]
Alexander Klimetschek commented on JCR-3534:
My proposal above could actually be implemented now without much effort - it
has the big advantage of being configuration-less while at the same time
ensuring a different secret for different data stores (i.e. avoiding people
copying the config files and thus the same secret).
> Efficient copying of binaries across repositories with the same data store
> --
>
> 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
>Assignee: Tommaso Teofili
> Attachments: JCR-3534.2.patch, JCR-3534.3.patch, JCR-3534.4.patch,
> JCR-3534.patch, 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) Efficient copying of binaries across repositories with the same data store
[
https://issues.apache.org/jira/browse/JCR-3534?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13653621#comment-13653621
]
Alexander Klimetschek commented on JCR-3534:
The DataStore could generate this shared secret the first time it is started
(i.e. no secret present), store it in a file in the root folder in case of the
FileDataStore, and then every shared usage will have access to it anyway. Then
this secret can be a secure long random string.
Implementation wise, AbstractDataStore would remove setSecret(), and add a
getSecret(), which it implements returning null - which means no reference
binaries are supported here (i.e. the DataIdentifier would get a null
reference). Then DataStore implementations would override the getSecret()
method, which would look for the secret, and id not present, create it.
AbstractDataStore should provide a generateSecret() method to use. The
FileDataStore would then define the name and location of the file. Something
like "secret" in the root folder of the storage should work - afaics it cannot
conflict with normal entries, since they are always in "hash" subdirectories.
For the DbDataStore it could be an special named entry that cannot collide with
binaries. For the MultiDataStore I don't know.
> Efficient copying of binaries across repositories with the same data store
> --
>
> 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
>Assignee: Tommaso Teofili
> Attachments: JCR-3534.2.patch, JCR-3534.3.patch, JCR-3534.4.patch,
> JCR-3534.patch, 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) Efficient copying of binaries across repositories with the same data store
[
https://issues.apache.org/jira/browse/JCR-3534?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13653091#comment-13653091
]
Alexander Klimetschek commented on JCR-3534:
Looks great!
We should document the new feature and in particular the "secret" parameter for
the DataStore when there is time:
* on the http://wiki.apache.org/jackrabbit/DataStore wiki page (with an example
on how to use it and a note it only applies to File & DbDataStore)
* in the javadocs of AbstractDataStore.setSecret
* in "default" repository xml (maybe):
http://svn.apache.org/repos/asf/jackrabbit/trunk/jackrabbit-core/src/main/resources/org/apache/jackrabbit/core/repository.xml
* on the configuration page (with version info):
http://jackrabbit.apache.org/jackrabbit-configuration.html#JackrabbitConfiguration-Datastoreconfiguration
> Efficient copying of binaries across repositories with the same data store
> --
>
> 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
>Assignee: Tommaso Teofili
> Attachments: JCR-3534.2.patch, JCR-3534.3.patch, JCR-3534.4.patch,
> JCR-3534.patch, 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) Efficient copying of binaries across repositories with the same data store
[
https://issues.apache.org/jira/browse/JCR-3534?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13651138#comment-13651138
]
Alexander Klimetschek commented on JCR-3534:
The main point is actually that the signature MUST be created inside the
repository implementation, I can't see how client code would have access to the
data store secret which is required to create the signature.
This leads to changing JackrabbitValue#getContentIdentity(): I did not find a
use of getContentIdentity() in our proprietary code; jackrabbit itself only
provides it, but there is no utility etc. making use of it. I wonder what you
could actually do with it so far other than checking for equality to a content
id fetched from somewhere else? But if the hmac signature is expected to change
every time, this would break the api contract afaics, which clearly states "If
two values have the same identifier, the content of the value is guaranteed to
be the same". This forces to add a new API that gives this signed message, no
way around that afaics.
That would be my proposal:
- BinaryReferenceMessage just a data object holding a "token/message" string
(passed via constructor and read via getter)
- other Binary methods empty/no-op
- message format creation including signature done inside new API (e.g.
JackrabbitValue#getSecureContentIdentity())
- message format parsing and signature validation all happening inside
createValue(Binary) when it sees a BinaryReferenceMessage
> Efficient copying of binaries across repositories with the same data store
> --
>
> 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
>Assignee: Tommaso Teofili
> Attachments: JCR-3534.2.patch, JCR-3534.3.patch, JCR-3534.patch,
> 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) Efficient copying of binaries across repositories with the same data store
[
https://issues.apache.org/jira/browse/JCR-3534?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13651079#comment-13651079
]
Alexander Klimetschek commented on JCR-3534:
Because client code must not use jackrabbit-core inner classes, nor should
jackrabbit-core export any APIs.
> Efficient copying of binaries across repositories with the same data store
> --
>
> 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
>Assignee: Tommaso Teofili
> Attachments: JCR-3534.2.patch, JCR-3534.3.patch, JCR-3534.patch,
> 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) Efficient copying of binaries across repositories with the same data store
[
https://issues.apache.org/jira/browse/JCR-3534?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13651045#comment-13651045
]
Alexander Klimetschek commented on JCR-3534:
Yeah, but then you can't use it for the intended use case...
> Efficient copying of binaries across repositories with the same data store
> --
>
> 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
>Assignee: Tommaso Teofili
> Attachments: JCR-3534.2.patch, JCR-3534.3.patch, JCR-3534.patch,
> 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
JCR-3534 - New Binary implementation
Hi everyone, Tommaso and me were having a little 1:1 discussion in JCR-3534 starting at [0], and would love to hear some input on the open points discussed. Otherwise we keep repeating ourselves :-) Most notably, I see no clear API boundary yet and would not like to have this new jackrabbit feature partly being implemented in jackrabbit-jcr-commons. [0] https://issues.apache.org/jira/browse/JCR-3534?focusedCommentId=13649625&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13649625 Cheers, Alex
[jira] [Commented] (JCR-3534) Efficient copying of binaries across repositories with the same data store
[
https://issues.apache.org/jira/browse/JCR-3534?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13651020#comment-13651020
]
Alexander Klimetschek commented on JCR-3534:
I think on the API level we want a single string (token) - the repository
implementation generates and also handles it, all with a minimum of API
additions.
> otherwise it seems to me this is not "that" high level to justify its
> belonging to jackrabbit-api
IMO there is no gray area - either we say it's an API feature or it's not a
feature at all.
(BTW, to me jackrabbit-jcr-commons is a big chunk of utilities and it's already
suboptimal that both repository implementation and jcr client code depend on
it).
> that's basically for compatibility with existing code where you may now
> receive such an object and you wouldn't expect that to return null.
There is no way that you can "accidentally" get the BinaryReferenceMessage. The
repository would never return it (via getProperty() etc.), the only way it can
exist is between an API client instantiating it itself and passing it to
ValueFactory.createValue(Binary).
But maybe this is an indication that this Binary trick is too fuzzy from an API
design standpoint...
Some others should share their opinions.
> Efficient copying of binaries across repositories with the same data store
> --
>
> 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
>Assignee: Tommaso Teofili
> Attachments: JCR-3534.2.patch, JCR-3534.3.patch, JCR-3534.patch,
> 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) Efficient copying of binaries across repositories with the same data store
[
https://issues.apache.org/jira/browse/JCR-3534?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13650878#comment-13650878
]
Alexander Klimetschek commented on JCR-3534:
Looks good. But some more comments ;-)
Since the BinaryReferenceMessage is API, I would keep it as minimal as possible:
- Any key generation should come from the repository itself. Currently it's
mixed - generating is done by the client (needs to know the right format) and
later reading & validating is done by the repository in createValue(). It
should all be done by the repository, the client code should not have to know
the format of the signature. I was thinking that we change the
JackrabbitValue#getContentIdentity() [0] to return the final secure/signed
token format. Should be possible to detect old and new IDs IMHO. This requires
that other code (where?) that uses the content identity can work with the new
format as well.
- BinaryReferenceMessage should go into jackrabbit-api instead of
jackrabbit-jcr-commons since it's a specific Jackrabbit API and jcr-commons is
more about utilities around both JCR API users and JCR implementors, which
makes it hard to find actual jackrabbit specific features
- BinaryReferenceMessage also implements getStream(), read() and getSize() by
providing the message token - IMHO that is misleading if it is used as special
interface only. These should probably return null. The repository itself would
never return such a Binary itself.
[0]
http://jackrabbit.apache.org/api/2.4/org/apache/jackrabbit/api/JackrabbitValue.html#getContentIdentity()
> Efficient copying of binaries across repositories with the same data store
> --
>
> 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
>Assignee: Tommaso Teofili
> Attachments: JCR-3534.2.patch, JCR-3534.3.patch, JCR-3534.patch,
> 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) Efficient copying of binaries across repositories with the same data store
[
https://issues.apache.org/jira/browse/JCR-3534?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13649962#comment-13649962
]
Alexander Klimetschek commented on JCR-3534:
@Tommaso: There are 2 things:
a) api or not for creating the binary: since the requirement here is an
application level protocol, there must be an API, otherwise it could not know
if it should resend the full binary or not. The application level protocol
currently cannot and should not know if the datastores are shared or not.
AFAICS, the discussion so far did not result in avoiding an API, just to make
sure it's a _secure_ API.
In my above comments I missed the proposed trick to use
"createValue(java.lang.String value, PropertyType.BINARY)" - but I don't see
that in the patch either. This would look something like this IIUC, instead of
the getBinaryFromSecureID() in my above snippet:
Node node = ... // current node written
Binary binary;
if (messageData.hasBinaryStream()) {
binary = getBinaryFromStream(messageData, session);
} else {
String message = messageData.getBinaryMessage(); // get from custom
protocol
try {
binary = session.getValueFactory().createValue(message,
PropertyType.BINARY);
} catch (ValueFormatException e) {
// not supported / wrong secret / referenced binary not found
return ASK_FOR_BINARY_STREAM;
}
}
node.setProperty("jcr:data", binary);
It is important however that createValue() will only return a binary if the
message is right; if it creates a binary of the string contents (not sure if
that is currently the case if you call createValue() this way, then this trick
cannot work and we do need another API.
b) reading the binary: could you show me the application code reading such a
binary just using the JCR API how it gets the actual data? This is completely
missing yet (the test in the patch uses DataStore.getRecord(), but that is
Jackrabbit internal).
> Efficient copying of binaries across repositories with the same data store
> --
>
> 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
>Assignee: Tommaso Teofili
> Attachments: JCR-3534.2.patch, JCR-3534.patch, 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] [Comment Edited] (JCR-3534) Efficient copying of binaries across repositories with the same data store
[
https://issues.apache.org/jira/browse/JCR-3534?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13649645#comment-13649645
]
Alexander Klimetschek edited comment on JCR-3534 at 5/6/13 10:55 AM:
-
@Tommaso: In the current patch, the binary stores the HMAC message/reference,
but not the real binary. This it not transparent for JCR API users. How do they
get the actual binary? They don't have access to the DataStore at all, and they
should not have to know about this special mechanism at all (otherwise all code
would have to be rewritten).
What I think we need on the API client side:
a) creating binary
Node node = ... // current node written
Binary binary;
if (messageData.hasBinaryStream()) {
binary = getBinaryFromStream(messageData, session);
} else {
String message = messageData.getBinaryMessage(); // get from custom protocol
binary = jackrabbitSession.getBinaryBySecureID(message);
if (binary == null) {
// protocol does an extra step and transfers the full binary itself
return ASK_FOR_BINARY_STREAM;
}
}
node.setProperty("jcr:data", binary);
b) code reading the data - plain jcr api
InputStream is = node.getProperty("jcr:data").getBinary().getInputStream();
was (Author: alexander.klimetschek):
[~teofili] In the current patch, the binary stores the HMAC message, but
not the real binary. This it not transparent for JCR API users. How do they get
the actual binary? They don't have access to the DataStore at all, and they
should not have to know about this special mechanism at all (otherwise all code
would have to be rewritten).
What I think we need on the API client side:
a) creating binary
Node node = ... // current node written
Binary binary;
if (messageData.hasBinaryStream()) {
binary = getBinaryFromStream(messageData, session);
} else {
String message = messageData.getBinaryMessage(); // get from custom protocol
binary = jackrabbitSession.getBinaryBySecureID(message);
if (binary == null) {
// protocol does an extra step and transfers the full binary itself
return ASK_FOR_BINARY_STREAM;
}
}
node.setProperty("jcr:data", binary);
b) code reading the data - plain jcr api
InputStream is = node.getProperty("jcr:data").getBinary().getInputStream();
> Efficient copying of binaries across repositories with the same data store
> --
>
> 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
>Assignee: Tommaso Teofili
> Attachments: JCR-3534.2.patch, JCR-3534.patch, 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) Efficient copying of binaries across repositories with the same data store
[
https://issues.apache.org/jira/browse/JCR-3534?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13649645#comment-13649645
]
Alexander Klimetschek commented on JCR-3534:
[~teofili] In the current patch, the binary stores the HMAC message, but not
the real binary. This it not transparent for JCR API users. How do they get the
actual binary? They don't have access to the DataStore at all, and they should
not have to know about this special mechanism at all (otherwise all code would
have to be rewritten).
What I think we need on the API client side:
a) creating binary
Node node = ... // current node written
Binary binary;
if (messageData.hasBinaryStream()) {
binary = getBinaryFromStream(messageData, session);
} else {
String message = messageData.getBinaryMessage(); // get from custom protocol
binary = jackrabbitSession.getBinaryBySecureID(message);
if (binary == null) {
// protocol does an extra step and transfers the full binary itself
return ASK_FOR_BINARY_STREAM;
}
}
node.setProperty("jcr:data", binary);
b) code reading the data - plain jcr api
InputStream is = node.getProperty("jcr:data").getBinary().getInputStream();
> Efficient copying of binaries across repositories with the same data store
> --
>
> 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
>Assignee: Tommaso Teofili
> Attachments: JCR-3534.2.patch, JCR-3534.patch, 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
[
https://issues.apache.org/jira/browse/JCR-3534?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13648576#comment-13648576
]
Alexander Klimetschek commented on JCR-3534:
HMAC stuff is good afaics (not an expert), but some things are missing:
- it's on the Binary level and not on the more generic Value level (but ok for
me)
- instead of resolving the message upon writing to the repository, it is
instead written as Binary (with the message as contents)
- but it's never resolved to the final binary that you want (if the message is
valid)
- the public API is still missing (BinaryReferenceMessage is in a jackrabbit
internal package); I think a public api Binary getBinaryBySecureID() (or
similar) like in the first patch is still required
- and then you'd write the returned Binary right to the repository (no delayed
resolution)
- this is important, since the application level code needs to know if that
getBinaryBySecureID() worked or not (returns non-null or not) so it can handle
the case by asking for the full binary as stream over its own message protocol
- btw, some lucene-related java files are accidentally included in the patch
with import reorgs
> 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
>Assignee: Tommaso Teofili
> Attachments: JCR-3534.patch, 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
[
https://issues.apache.org/jira/browse/JCR-3534?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13640457#comment-13640457
]
Alexander Klimetschek commented on JCR-3534:
I agree with Jukka - we are not talking about a protocol here that needs to be
protected, but an API access. A replication protocol that would make use of
this on top of Jackrabbit would need its own protection (e.g. SSL) to protect
the message contents, but that should be clearly separated.
BTW, yesterday I came across another use case that the solution should include:
not only a shared DataStore between sender and receiver of that
application-level replication mechanism, but also the case of multiple
receivers (horizontally scaled boxes) that share one datastore. In this
scenario the sender sends N replication messages to N receivers. Ideally you
want to avoid sending large binaries N times, so one could imagine the
receivers sharing a common DataStore (but not with the sender, as their is
usually a strict firewall separation between sender and receiver and possibly a
higher latency as they might reside in different data centers). In that case I
imagine that after the first successful transfer of the binary to receiver 1
and storage in the DataStore, the other replications to the other receivers see
that the binary is present already and don't need to send it over again
(although one has to avoid that all replications happen at the same time to
benefit from that).
This means that one should be able to configure a shared secret in both the
sender and receiver DataStores, so they could "trust" each other, but wouldn't
necessarily have shared content.
IMHO this case is even more applicable to real-world scenarios and performance
benefits - because a shared DataStore between sender and receiver is definitely
less possible than a shared DataStore among multiple receivers.
> 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-3568) Property.getBinary().getStream() files in tempDir not removed by InputStream.close() nor by Binary.dispose()
[
https://issues.apache.org/jira/browse/JCR-3568?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13636468#comment-13636468
]
Alexander Klimetschek commented on JCR-3568:
javax.jcr.Binary is an interface, so the JCR API itself cannot be the culprit.
As Jukka mentioned, it seems the webdav Binary.dispose() implementation doesn't
do the necessary cleanup
> Property.getBinary().getStream() files in tempDir not removed by
> InputStream.close() nor by Binary.dispose()
> -
>
> Key: JCR-3568
> URL: https://issues.apache.org/jira/browse/JCR-3568
> Project: Jackrabbit Content Repository
> Issue Type: Bug
> Components: jackrabbit-webdav
>Affects Versions: 2.6
> Environment: Windows 7 Pro, Java 6.0.39, WebDAV, JCR 2.0
>Reporter: Ulrich Schmidt
>
> I need to inspect the the files stored to the jcr:data-Property in Node
> jcr:content which is a subnode of a nt:fille-Node. Access mode is WebDAV
> using JCR 2.0-API.
> Jackrabbit does not drop the tempfiles created by the command
> Property.getBinary().getStream() by the closing instruchtions
> InputStream.close() nor Binary.dispose(). I get a RepositoryException "No
> space left on device" when der tempsace becomes full.
> The executed code is;
> public class DownloadLoopMain {
> private final static Logger LOGGER =
> LoggerFactory.getLogger("Test.DownloadLoopMain");
> String repository = "http://localhost:8080/server";;
> String user="admin";
> String password="admin";
> Session session;
> File temp = new File(System.getProperty("java.io.tmpdir"));
> List nodeList = new ArrayList();
> public DownloadLoopMain() throws Exception {
> LOGGER.info("TempDir=" + temp.getPath());
> long totalsize=0;
>
> connectRepository();
> buildNodeList();
> List tempfiles = getTempFiles(temp.listFiles());
> LOGGER.info("Start with number of files in Tempdir:" +
> tempfiles.size());
> for (String node : nodeList) {
> LOGGER.info("Retrieve node " + node);
> Node currentNode=session.getNode(node);
> Node fileNode = currentNode.getNode("jcr:content");
> Property jcrdata = fileNode.getProperty("jcr:data");
> Binary fileBin=jcrdata.getBinary();
> long filesize=fileBin.getSize();
> totalsize+=filesize;
> InputStream file = fileBin.getStream();
>
> LOGGER.info("Now we have number of files in Tempdir:" +
> tempfiles.size());
>
> List newTempfiles =
> getTempFiles(temp.listFiles());
> // Display new files in temp-directory
> compareTempfiles("new", newTempfiles, tempfiles);
>
> // Display files gone from temp-directory
> compareTempfiles("gone", tempfiles, newTempfiles);
>
> tempfiles=newTempfiles;
>
> file.close();
> fileBin.dispose();
> }
> }
>
>
> /**
>* Compare List of tempfiles.
>* @param intend
>* @param list1
>* @param list2
>*/
> public void compareTempfiles(String intend, List list1,
> List list2 ) {
> for (String[] list1file : list1) {
> boolean known=false;
> for (int i=0; i< list2.size(); i++) {
> String[] list2file=list2.get(i);
> if (list1file[0].equals(list2file[0])) {
> known=true;
> break;
> }
> }
> if (!known) {
> LOGGER.info(intend + " tempfile=" +
> list1file[0]+ " " + list1file[1]);
> }
> }
> }
> public List getTempFiles
[jira] [Commented] (JCR-3572) Optimization in NodeImpl.getNodes(String) and getNodes(String[])
[
https://issues.apache.org/jira/browse/JCR-3572?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13635100#comment-13635100
]
Alexander Klimetschek commented on JCR-3572:
Usually things are done on the trunk and backported afterwards, depending on
the need.
> Optimization in NodeImpl.getNodes(String) and getNodes(String[])
>
>
> Key: JCR-3572
> URL: https://issues.apache.org/jira/browse/JCR-3572
> Project: Jackrabbit Content Repository
> Issue Type: Improvement
> Components: jackrabbit-core
>Affects Versions: 2.2.13, 2.4.3, 2.5.3, 2.6
>Reporter: Sergiy Shyrkov
>Priority: Minor
>
> We were doing some refactoring/optimization of our code (we are using
> Jackrabbit 2.2.x code) and replacing in some places traversal over child
> nodes (node.getNodes()) with node.getNodes(namePattern) as it suppose to
> speed up the things by only returning children, matching particular name
> pattern (in our case those our internationalization nodes, starting with
> "translation-").
> Profiling the code after we noticed that node.getNodes(namePattern) is
> actually slower than simple traversal over all children checking their name
> match.
> We can down to the org.apache.jackrabbit.util.ChildrenCollectorFilter which
> is used in the NodeImpl.getNodes(String) and getNodes(String[])
> Even if the instance of the filter is created with collectProperties set to
> false the parent (javax.jcr.util.TraversingItemVisitor.visit(Node)) still
> reads the properties of the nodes and iterates over them which seems useless.
> Digging deeper it seems there is an optimization which can be done to
> getNodes(String) and getNodes(String[]) earlier.
> Those methods could call the itemMgr.getChildNodes(), like the getNodes()
> does, passing additionally namePattern / nameGlobs.
> The ItemManager.ChildNodeEntry() already iterates on ChildNodeEntry
> instances, which have Name, so the filtering can be done here, i.e. much
> earlier, than in the LazyItemIterator.prefetchNext().
> The adjusted code for org.apache.jackrabbit.core.ItemManager.getChildNodes(),
> we've tested on our side looks as follows:
> synchronized NodeIterator getChildNodes(NodeId parentId)
> throws ItemNotFoundException, AccessDeniedException,
> RepositoryException {
> return getChildNodesInternal(parentId, null, null);
> }
> synchronized NodeIterator getChildNodes(NodeId parentId, String
> namePattern, String[] nameGlobs)
> throws ItemNotFoundException, AccessDeniedException,
> RepositoryException {
> return getChildNodesInternal(parentId, namePattern, nameGlobs);
> }
> private NodeIterator getChildNodesInternal(NodeId parentId, String
> namePattern, String[] nameGlobs)
> throws ItemNotFoundException, AccessDeniedException,
> RepositoryException {
> sanityCheck();
> ItemData data = getItemData(parentId);
> if (!data.isNode()) {
> String msg = "can't list child nodes of property " + parentId;
> log.debug(msg);
> throw new RepositoryException(msg);
> }
> ArrayList childIds = new ArrayList();
> Iterator iter = ((NodeState)
> data.getState()).getChildNodeEntries().iterator();
> while (iter.hasNext()) {
> ChildNodeEntry entry = iter.next();
> // delay check for read-access until item is being built
> // thus avoid duplicate check
>
> // check for name
> if (namePattern == null && nameGlobs == null ||
> namePattern != null
> &&
> ChildrenCollectorFilter.matches(sessionContext.getJCRName(entry.getName()),
> namePattern)
> || nameGlobs != null
> &&
> ChildrenCollectorFilter.matches(sessionContext.getJCRName(entry.getName()),
> nameGlobs)) {
> childIds.add(entry.getId());
> }
> }
> return new LazyItemIterator(sessionContext, childIds, parentId);
> }
> and in the NodeImpl we call ItemManager.getChildNodes() as follows:
> public NodeIterator getNodes(String namePattern) throws
> RepositoryException {
> return getNodesInternal(namePattern, null);
> }
> public NodeIterator getNodes(final String[] nameGlobs)
> throws RepositoryException {
> return getNodesInternal(null, nameGlobs);
&g
[jira] [Commented] (JCR-3572) Optimization in NodeImpl.getNodes(String) and getNodes(String[])
[
https://issues.apache.org/jira/browse/JCR-3572?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13634287#comment-13634287
]
Alexander Klimetschek commented on JCR-3572:
Could you provide a patch?
> Optimization in NodeImpl.getNodes(String) and getNodes(String[])
>
>
> Key: JCR-3572
> URL: https://issues.apache.org/jira/browse/JCR-3572
> Project: Jackrabbit Content Repository
> Issue Type: Improvement
> Components: jackrabbit-core
>Affects Versions: 2.2.13, 2.4.3, 2.5.3, 2.6
>Reporter: Sergiy Shyrkov
>Priority: Minor
>
> We were doing some refactoring/optimization of our code (we are using
> Jackrabbit 2.2.x code) and replacing in some places traversal over child
> nodes (node.getNodes()) with node.getNodes(namePattern) as it suppose to
> speed up the things by only returning children, matching particular name
> pattern (in our case those our internationalization nodes, starting with
> "translation-").
> Profiling the code after we noticed that node.getNodes(namePattern) is
> actually slower than simple traversal over all children checking their name
> match.
> We can down to the org.apache.jackrabbit.util.ChildrenCollectorFilter which
> is used in the NodeImpl.getNodes(String) and getNodes(String[])
> Even if the instance of the filter is created with collectProperties set to
> false the parent (javax.jcr.util.TraversingItemVisitor.visit(Node)) still
> reads the properties of the nodes and iterates over them which seems useless.
> Digging deeper it seems there is an optimization which can be done to
> getNodes(String) and getNodes(String[]) earlier.
> Those methods could call the itemMgr.getChildNodes(), like the getNodes()
> does, passing additionally namePattern / nameGlobs.
> The ItemManager.ChildNodeEntry() already iterates on ChildNodeEntry
> instances, which have Name, so the filtering can be done here, i.e. much
> earlier, than in the LazyItemIterator.prefetchNext().
> The adjusted code for org.apache.jackrabbit.core.ItemManager.getChildNodes(),
> we've tested on our side looks as follows:
> synchronized NodeIterator getChildNodes(NodeId parentId)
> throws ItemNotFoundException, AccessDeniedException,
> RepositoryException {
> return getChildNodesInternal(parentId, null, null);
> }
> synchronized NodeIterator getChildNodes(NodeId parentId, String
> namePattern, String[] nameGlobs)
> throws ItemNotFoundException, AccessDeniedException,
> RepositoryException {
> return getChildNodesInternal(parentId, namePattern, nameGlobs);
> }
> private NodeIterator getChildNodesInternal(NodeId parentId, String
> namePattern, String[] nameGlobs)
> throws ItemNotFoundException, AccessDeniedException,
> RepositoryException {
> sanityCheck();
> ItemData data = getItemData(parentId);
> if (!data.isNode()) {
> String msg = "can't list child nodes of property " + parentId;
> log.debug(msg);
> throw new RepositoryException(msg);
> }
> ArrayList childIds = new ArrayList();
> Iterator iter = ((NodeState)
> data.getState()).getChildNodeEntries().iterator();
> while (iter.hasNext()) {
> ChildNodeEntry entry = iter.next();
> // delay check for read-access until item is being built
> // thus avoid duplicate check
>
> // check for name
> if (namePattern == null && nameGlobs == null ||
> namePattern != null
> &&
> ChildrenCollectorFilter.matches(sessionContext.getJCRName(entry.getName()),
> namePattern)
> || nameGlobs != null
> &&
> ChildrenCollectorFilter.matches(sessionContext.getJCRName(entry.getName()),
> nameGlobs)) {
> childIds.add(entry.getId());
> }
> }
> return new LazyItemIterator(sessionContext, childIds, parentId);
> }
> and in the NodeImpl we call ItemManager.getChildNodes() as follows:
> public NodeIterator getNodes(String namePattern) throws
> RepositoryException {
> return getNodesInternal(namePattern, null);
> }
> public NodeIterator getNodes(final String[] nameGlobs)
> throws RepositoryException {
> return getNodesInternal(null, nameGlobs);
> }
> private NodeIterator getNodesInternal(final Str
[jira] [Commented] (JCR-3562) Adding a child node named {foo fails but bar} works
[
https://issues.apache.org/jira/browse/JCR-3562?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13626567#comment-13626567
]
Alexander Klimetschek commented on JCR-3562:
Why is that wrong? The spec isn't mentioning that if { is followed by an
invalid URI it should just see it as normal name - I'd read it as "throw an
exception that this does not refer to a valid namespace URI".
Also, the spec says: "A repository may further restrict the names of entities
to a subset of JCR names and in most cases is encouraged to do so."
> Adding a child node named {foo fails but bar} works
> ---
>
> Key: JCR-3562
> URL: https://issues.apache.org/jira/browse/JCR-3562
> Project: Jackrabbit Content Repository
> Issue Type: Bug
> Components: jackrabbit-core
>Affects Versions: 2.6
>Reporter: Bertrand Delacretaz
>Priority: Minor
> Attachments: failure-trace.txt, testBracketsInNodeName.patch
>
>
> I'll attach a test patch that demonstrates that addNode("bar}") works but
> addNode("{foo") fails.
> AFAIK both are valid child node names.
--
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-3562) Adding a child node named {foo fails but bar} works
[
https://issues.apache.org/jira/browse/JCR-3562?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13626538#comment-13626538
]
Alexander Klimetschek commented on JCR-3562:
No, that behavior seems right: A "{" starts a qualified name, with the part
inside the curly braces addressing the full namespace URL:
"{namespace-uri}local-name"
See
http://www.day.com/specs/jcr/2.0/3_Repository_Model.html#3.2.5.1%20Expanded%20Form
> Adding a child node named {foo fails but bar} works
> ---
>
> Key: JCR-3562
> URL: https://issues.apache.org/jira/browse/JCR-3562
> Project: Jackrabbit Content Repository
> Issue Type: Bug
> Components: jackrabbit-core
>Affects Versions: 2.6
>Reporter: Bertrand Delacretaz
>Priority: Minor
> Attachments: failure-trace.txt, testBracketsInNodeName.patch
>
>
> I'll attach a test patch that demonstrates that addNode("bar}") works but
> addNode("{foo") fails.
> AFAIK both are valid child node names.
--
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-2233) mix:lastModified - auto-set but allow modification for imports
[ https://issues.apache.org/jira/browse/JCR-2233?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13610060#comment-13610060 ] Alexander Klimetschek commented on JCR-2233: No plans that I know... not sure if that was discussed for Oak or not. > mix:lastModified - auto-set but allow modification for imports > -- > > Key: JCR-2233 > URL: https://issues.apache.org/jira/browse/JCR-2233 > Project: Jackrabbit Content Repository > Issue Type: Improvement > Components: jackrabbit-core, JCR 2.0 > Reporter: Alexander Klimetschek >Priority: Minor > > Following the discussion in JCR-2116, I propose it would be a good idea to > have jcr:created, jcr:createdBy (from mix:created) and jcr:lastModified, > jcr:lastModifiedBy (mix:lastModified) not protected, but still automatically > set those properties in case they were not modified by the client. > Three advantages: > a) This allows for importing content with these properties, where eg. the > jcr:created should point to the original creation date of the content, not > when it was imported. > b) Same for jcr:lastModified, which often must be set manually for ensuring > correct behaviour when doing synchronizations etc. > c) In order to take advantage of the automatically-set behaviour mentioned in > the spec, it would be nice if the repository would set them in the case the > client is not writing those properties. This way you can ensure the > properties are correctly set when you cannot control all client-code > modifying the content (eg. webdav). > Question: would this be in line with the spec? I would say, yes, since we say > we don't implement "protected", which is allowed, but add a hybrid approach > (which is not explicitly forbidden, IIUC). > For the reference, here is the definition from the latest JSR-283 doc: > [mix:lastModified] mixin > - jcr:lastModified (DATE) autocreated protected? OPV? > - jcr:lastModifiedBy (STRING) autocreated protected? OPV? > [mix:created] mixin > - jcr:created (DATE) autocreated protected? OPV? > - jcr:createdBy (STRING) autocreated protected? OPV? > And here is the current cnd definition in JR 2.0: > http://svn.apache.org/viewvc/jackrabbit/trunk/jackrabbit-core/src/main/resources/org/apache/jackrabbit/core/nodetype/builtin_nodetypes.cnd?view=co -- 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] [Comment Edited] (JCR-3534) Add JackrabbitSession.getValueByContentId method
[
https://issues.apache.org/jira/browse/JCR-3534?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13606270#comment-13606270
]
Alexander Klimetschek edited comment on JCR-3534 at 3/19/13 12:05 PM:
--
I agree that the security aspect of this seems problematic - but I think they
go away if we look at the larger picture.
What we want to use this feature for is for a "replication" feature in our app,
which is really an infrastructure service and already uses an *admin* (or
similar highly privileged user) session on the target jackrabbit instance to
copy over content from another one. Having this special
"access-by-datastore-id" permission flag would only be used for that case
anyway.
Now if we ensure the data store IDs are not guessable, then there is no option
to browse the repository's binaries. If we avoid using simple hashes of the
binary for the (exposed) ID, it will not be possible to check for the existence
of certain documents known to an attacker. In fact, an attacker will only be
able to get to the ID if he has the access rights to the content in the first
place.
IMHO that is all acceptable; except for such a special replication system user,
no normal JCR user would ever need to have that permission turned on (and
documentation should say so).
If not, we really need to think of bringing a similar performance-optimized
replication feature into Jackrabbit / Oak itself.
was (Author: alexander.klimetschek):
I agree that the security aspect of this seems problematic - but I think
they go away if we look at the larger picture.
What we want to use this feature for is for a "replication" feature in our app,
which is really an infrastructure service and already uses an *admin* (or
similar highly privileged user) session on the target jackrabbit instance to
copy over content from another one. Having this special
"access-by-datastore-id" permission flag is actually slightly better than
before with no restriction options at all.
Now if we ensure the data store IDs are not guessable, then there is no option
to browse the repository's binaries. If we avoid using simple hashes of the
binary for the (exposed) ID, it will not be possible to check for the existence
of certain documents known to an attacker. In fact, an attacker will only be
able to get to the ID if he has the access rights to the content in the first
place.
IMHO that is all acceptable; except for such a special replication system user,
no normal JCR user would ever need to have that permission turned on (and
documentation should say so).
If not, we really need to think of bringing a similar performance-optimized
replication feature into Jackrabbit / Oak 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
