Re: New Jackrabbit Committer: Nitin Gupta
Welcome Nitin! Chetan Mehrotra On Thu, Aug 15, 2019 at 7:26 PM Matt Ryan wrote: > > Welcome Nitin! > > > -MR > > On Thu, Aug 15, 2019 at 6:51 AM Julian Sedding wrote: >> >> Welcome Nitin! >> >> Regards >> Julian >> >> On Wed, Aug 14, 2019 at 3:24 PM Woonsan Ko wrote: >> > >> > Welcome, Nitin! >> > >> > Cheers, >> > >> > Woonsan >> > >> > On Wed, Aug 14, 2019 at 2:30 AM Tommaso Teofili >> > wrote: >> > > >> > > Welcome to the team Nitin! >> > > >> > > Regards, >> > > Tommaso >> > > >> > > On Thu, 8 Aug 2019 at 08:31, Marcel Reutegger wrote: >> > >> >> > >> Hi, >> > >> >> > >> Please welcome Nitin Gupta as a new committer and PMC member of >> > >> the Apache Jackrabbit project. The Jackrabbit PMC recently decided to >> > >> offer Nitin 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, Nitin! >> > >> >> > >> Regards >> > >> Marcel >> > >>
Re: Jackrabbit oak: Want these two (OAK-7304 and OAK-7265) fixes in 1.8.3 release.
OAK-7304 is now backported. As Marcel and Torgeir suggested for now you can build from source untill 1.8.3 is released Chetan Mehrotra On Thu, Mar 22, 2018 at 1:46 PM, Marcel Reutegger wrote: > Hi, > > On 21.03.18 13:43, rajesh wrote: >> >> I am using jackrabbit oak (1.8.2 ) in my spring boot application. Even >> though we are not using OSGI environment, we are using oak-pojosr packages >> which uses the OSGI kind of environment to configure the FileDataStore, >> S3DataStore and AzureDataStore etc. (Since documentation and examples are >> using OSGI kind of things only.) I need the following two fixes >> immediately >> in the next realease ( 1.8.3 ) so that i can proceed further. >> >> https://issues.apache.org/jira/browse/OAK-7304 > > > This issue is about deploying the release to the maven repository. You can > build and deploy this module from the source release yourself. > >> https://issues.apache.org/jira/browse/OAK-7265. > > > Please note, this is only an example and not meant to be used as is. Feel > free to copy the example and adjust to your needs. > > Regards > Marcel
Re: [IP CLEARANCE][VOTE] FileVault Package Maven Plugin Contribution
+1 Accept FileVault Package Maven Plugin into Apache Jackrabbit Chetan Mehrotra On Tue, Sep 12, 2017 at 8:18 AM, Tobias Bocanegra wrote: > [ ] +1 Accept FileVault Package Maven Plugin into Apache Jackrabbit > > > Regards, Toby
Re: Using JCR APIs in a Python script
Hi Vaibhav, JCR API are only supported on JVM. So you cannot use them from python. If you have Sling based app then you can use the Sling REST support to access repository content via HTTP. Or you can use Jackrabbit WebDAV support to access same content via web dav calls over HTTP Chetan Mehrotra On Wed, Sep 6, 2017 at 9:32 PM, Vaibhav Kumar Sharma wrote: > Hi Team, > > > > I was just curious to know how can I use the JCR API in my python script to > perform operations on my repo? > > > > Is that possible? Or Is there an implementation for JCR API in python? > > > > Thanks in advance!! > > > Regards, > > Vaibhav
Re: [VOTE] Release Apache Jackrabbit 2.4.8
+1 Chetan Mehrotra On Mon, Jul 17, 2017 at 4:24 PM, Julian Reschke wrote: > On 2017-07-17 12:01, Marcel Reutegger wrote: >> >> On 17/07/17 10:50, "Julian Reschke" wrote: >>> >>> Please vote on releasing this package as Apache Jackrabbit 2.4.8. The >>> vote is open for the next 72 hours and passes if a majority of at >>> least three +1 Jackrabbit PMC votes are cast. >> >> >> All checks OK. >> +1 Release this package as Apache Jackrabbit 2.4.8 >> >> Wasn't the plan to EOL the 2.4 branch with this release? I was expecting >> to see sentence in the release notes regarding this. It may be good to add a >> note to the announcement email about this decision. > > > Yes, that's the plan -- see separate mail thread. > > My plan though was to make the release now, and then to decide about EOL > later this year, that's why I don't mention it in the release notes... > > Best regards, Julian
Re: [VOTE] Release Apache Jackrabbit 2.14.1
+1 Chetan Mehrotra On Tue, May 30, 2017 at 2:21 PM, KÖLL Claus wrote: > +1 > > greets > claus
Re: [VOTE] Release Apache Jackrabbit 2.15.2
+1 Release this package as Apache Jackrabbit 2.15.2 Chetan Mehrotra On Tue, May 2, 2017 at 3:39 PM, Julian Reschke wrote: > On 2017-05-02 12:02, Julian Reschke wrote: >> >> On 2017-05-02 11:35, Marcel Reutegger wrote: >>> >>> On 01/05/17 17:05, Julian Reschke wrote: >>>> >>>> Please vote on releasing this package as Apache Jackrabbit 2.15.2. >>>> The vote is open for the next 72 hours and passes if a majority of at >>>> least three +1 Jackrabbit PMC votes are cast. >>> >>> >>> All checks OK. >>> >>> +1 Release this package as Apache Jackrabbit 2.15.2 >>> >>> Just one minor comment, the README.txt needs an update. It still says, >>> the minimum Java version is 6. >>> >>> Regards >>> Marcel >> >> >> Oh. Will do (for the next release). Thanks. > > > -> https://issues.apache.org/jira/browse/JCR-4134 > >
Re: New Jackrabbit Committer: Andrei Dulceanu
Welcome, Andrei! Chetan Mehrotra
Re: Mandatory property jcr:predecessors not found in a new node
Hi Mathias, On Tue, Dec 20, 2016 at 1:31 AM, mathiasconradt wrote: > However, the problem DOES NOT occur when I don't use the default repo > configuration but get the session from my own repository configuration Thanks for digging into this. I have opened OAK-5349 for this. Can you try with current trunk and let us know if it works for you? Chetan Mehrotra
[jira] [Updated] (JCR-3943) [jackrabbi-aws-ext] Data inconsistency due to race condition during async uploads
[
https://issues.apache.org/jira/browse/JCR-3943?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Chetan Mehrotra updated JCR-3943:
-
Fix Version/s: 2.13.5
> [jackrabbi-aws-ext] Data inconsistency due to race condition during async
> uploads
> -
>
> Key: JCR-3943
> URL: https://issues.apache.org/jira/browse/JCR-3943
> Project: Jackrabbit Content Repository
> Issue Type: Bug
> Components: jackrabbit-data
>Reporter: Amit Jain
>Priority: Critical
> Fix For: 2.13.5
>
> Attachments: coredata14Nov5Dec.txt
>
>
> There is a race condition when {{LocalCache}} is used where if an upload
> ({{file_u}}) has entered the cache but not the {{AsyncUploadCache}} and a
> simultaneous PurgeJob is running, then the uploaded file {{file_u}} can be
> purged from the cache.
> When the async job ultimately runs it fails silently (S3 client fails to
> calculate the hash because of the missing file), thus leaving dangling
> references in the node store as well as the {{AsyncUploadCache}}.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (JCR-4048) add applyOnChild property to JackrabbitEventFilter
[
https://issues.apache.org/jira/browse/JCR-4048?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15602696#comment-15602696
]
Chetan Mehrotra commented on JCR-4048:
--
+1. I have also got bitten by current behaviour which to me was not intuitive!
bq. applyOnChild
child again is bit misleading. May be {{applyOnSelf}} or {{forCurrentNode}}.
And may be prefer no arg variant for boolean property i.e. method invocation
itself is indication to make it true
{code}
+public JackrabbitEventFilter applyOnCurrentNode() {
+this.applyOnChild = true;
+return this;
+}
{code}
Not able to come up with good name though ...
> add applyOnChild property to JackrabbitEventFilter
> --
>
> Key: JCR-4048
> URL: https://issues.apache.org/jira/browse/JCR-4048
> Project: Jackrabbit Content Repository
> Issue Type: Improvement
> Components: observation
>Affects Versions: 2.13.4
>Reporter: Stefan Egli
> Attachments: JCR-4048.patch
>
>
> There seems to be a rather frequent use case of observation around which
> would like to create a filter on a _child_ rather than on a _parent_:
> consider the case when you'd like to filter for the removal of a node that
> has a particular nodeType. This can't be achieved atm as the nodeType is
> applicable to the parent of the node that changes, not the node itself (ie
> child).
> Therefore suggesting the introduction of a flag similar to the following:
> {code}
> boolean applyOnChild;
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Comment Edited] (JCR-4046) Improve observation of files
[
https://issues.apache.org/jira/browse/JCR-4046?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15602570#comment-15602570
]
Chetan Mehrotra edited comment on JCR-4046 at 10/24/16 5:35 PM:
This looks useful but we would need to see feasibility of supporting this under
the event listener approach. Supporting this via
{{org.apache.jackrabbit.oak.plugins.observation.NodeObserver}} would have been
much more simpler as its easy to maintain context.
Similar requirement can be seen for other nodetype where changes in specific
micro tree need to be reported at micro tree root level. For e.g. in AEM for a
dam:Asset a workflow would be configured to be triggered if change happens in
jcr:content/renditions/original.
Similar problem was solved in oak-lucene for doing aggregation where the
problem statement was that if any change happens in aggregated path
'jcr:content' then root node for that path should be reindexed. This was solved
with a Matcher like pattern which transitions from one state to another as diff
editor traverse down the tree.
So we can have support for *aggregating change listener* where a listener
provides
* nodetype - The root type of micro tree whose changes it is interested in
* aggregating paths - Set of relative path patterns which define what all
relative nodes changes should be attributed to root of that micro tree
So one can say I am interested in
* nt:file -> jcr:content
* dam:Asset -> jcr:content/**
And any change there would be reported as property changed event with property
names being relative paths
was (Author: chetanm):
This looks useful but we would need to see feasibility of supporting this under
the event listener approach. Supporting this via
{{org.apache.jackrabbit.oak.plugins.observation.NodeObserver}} would have been
much more simpler as its easy to maintain context.
Similar requirement can be seen for other nodetype where changes in specific
micro tree need to be reported at micro tree root level. For e.g. in AEM for a
dam:Asset a workflow would be configured to be triggered if change happens in
jcr:content/renditions/original.
Similar problem was solved in oak-lucene for doing aggregation where the
problem statement was that if any change happens in aggregated path
'jcr:content' then root node for that path should be reindexed. This was solved
with a Matcher like pattern which transitions from one state to another as diff
editor traverse down the tree
> Improve observation of files
>
>
> Key: JCR-4046
> URL: https://issues.apache.org/jira/browse/JCR-4046
> Project: Jackrabbit Content Repository
> Issue Type: Improvement
> Components: core
>Reporter: Carsten Ziegeler
> Attachments: JCR-4046.patch
>
>
> A file in JCR is represented by at least two nodes, the nt:file node and a
> child node named jcr:content holding the contents of the file (and metadata).
> This has the consequence that if the contents of a file changes, a change
> event of the jcr:content node is reported - but not of the nt:file node.
> This makes creating listeners listening for changes in files complicated, as
> you can't use the file name to filter - especially with glob patterns (see
> JCR-4044) this becomes troublesome.
> In addition, whenever you get a change for a jcr:content node, you have to
> check if the parent is a nt:file node and decide based on the result.
> It would be great to have a flag on the JackrabbitEventFilter to enable
> smarter reporting just for nt:files: if a property on jcr:content is changed,
> a change to the nt:file node is reported.
> See also SLING-6163 and OAK-4940
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (JCR-4044) Support glob patterns through JackrabbitEventFilter
[
https://issues.apache.org/jira/browse/JCR-4044?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15602577#comment-15602577
]
Chetan Mehrotra commented on JCR-4044:
--
I would prefer we have a single {{globPaths}}.
absPath and absPaths were probably done as absPath was part of
ObservationManager registration api itself.
> Support glob patterns through JackrabbitEventFilter
> ---
>
> Key: JCR-4044
> URL: https://issues.apache.org/jira/browse/JCR-4044
> Project: Jackrabbit Content Repository
> Issue Type: Improvement
> Components: core
>Reporter: Carsten Ziegeler
> Attachments: JCR-4044.patch
>
>
> In the Sling project, we would like to register JCR listeners based on glob
> patterns as defined in
> https://jackrabbit.apache.org/oak/docs/apidocs/org/apache/jackrabbit/oak/plugins/observation/filter/GlobbingPathFilter.html
> So basically instead (or in addition) to specifying an absolute path,
> defining patterns.
> [Discussion
> thread|https://lists.apache.org/thread.html/300f84574bbb039cebe35aab1afc21e043560a1c0471e456a2f5c0be@%3Cdev.jackrabbit.apache.org%3E]
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (JCR-4046) Improve observation of files
[
https://issues.apache.org/jira/browse/JCR-4046?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15602570#comment-15602570
]
Chetan Mehrotra commented on JCR-4046:
--
This looks useful but we would need to see feasibility of supporting this under
the event listener approach. Supporting this via
{{org.apache.jackrabbit.oak.plugins.observation.NodeObserver}} would have been
much more simpler as its easy to maintain context.
Similar requirement can be seen for other nodetype where changes in specific
micro tree need to be reported at micro tree root level. For e.g. in AEM for a
dam:Asset a workflow would be configured to be triggered if change happens in
jcr:content/renditions/original.
Similar problem was solved in oak-lucene for doing aggregation where the
problem statement was that if any change happens in aggregated path
'jcr:content' then root node for that path should be reindexed. This was solved
with a Matcher like pattern which transitions from one state to another as diff
editor traverse down the tree
> Improve observation of files
>
>
> Key: JCR-4046
> URL: https://issues.apache.org/jira/browse/JCR-4046
> Project: Jackrabbit Content Repository
> Issue Type: Improvement
> Components: core
>Reporter: Carsten Ziegeler
> Attachments: JCR-4046.patch
>
>
> A file in JCR is represented by at least two nodes, the nt:file node and a
> child node named jcr:content holding the contents of the file (and metadata).
> This has the consequence that if the contents of a file changes, a change
> event of the jcr:content node is reported - but not of the nt:file node.
> This makes creating listeners listening for changes in files complicated, as
> you can't use the file name to filter - especially with glob patterns (see
> JCR-4044) this becomes troublesome.
> In addition, whenever you get a change for a jcr:content node, you have to
> check if the parent is a nt:file node and decide based on the result.
> It would be great to have a flag on the JackrabbitEventFilter to enable
> smarter reporting just for nt:files: if a property on jcr:content is changed,
> a change to the nt:file node is reported.
> See also SLING-6163 and OAK-4940
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (JCR-4044) Support glob patterns through JackrabbitEventFilter
[ https://issues.apache.org/jira/browse/JCR-4044?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chetan Mehrotra updated JCR-4044: - Description: In the Sling project, we would like to register JCR listeners based on glob patterns as defined in https://jackrabbit.apache.org/oak/docs/apidocs/org/apache/jackrabbit/oak/plugins/observation/filter/GlobbingPathFilter.html So basically instead (or in addition) to specifying an absolute path, defining patterns. [Discussion thread|https://lists.apache.org/thread.html/300f84574bbb039cebe35aab1afc21e043560a1c0471e456a2f5c0be@%3Cdev.jackrabbit.apache.org%3E] was: In the Sling project, we would like to register JCR listeners based on glob patterns as defined in https://jackrabbit.apache.org/oak/docs/apidocs/org/apache/jackrabbit/oak/plugins/observation/filter/GlobbingPathFilter.html So basically instead (or in addition) to specifying an absolute path, defining patterns. > Support glob patterns through JackrabbitEventFilter > --- > > Key: JCR-4044 > URL: https://issues.apache.org/jira/browse/JCR-4044 > Project: Jackrabbit Content Repository > Issue Type: Improvement > Components: core >Reporter: Carsten Ziegeler > > In the Sling project, we would like to register JCR listeners based on glob > patterns as defined in > https://jackrabbit.apache.org/oak/docs/apidocs/org/apache/jackrabbit/oak/plugins/observation/filter/GlobbingPathFilter.html > So basically instead (or in addition) to specifying an absolute path, > defining patterns. > [Discussion > thread|https://lists.apache.org/thread.html/300f84574bbb039cebe35aab1afc21e043560a1c0471e456a2f5c0be@%3Cdev.jackrabbit.apache.org%3E] -- This message was sent by Atlassian JIRA (v6.3.4#6332)
Re: Can i reindex a node which is in cluster
Is this a Jackrabbit or Jackrabbit Oak cluster? If Jackrabbit Oak then whats the type of property index Chetan Mehrotra On Tue, Oct 18, 2016 at 8:33 PM, Kishore Ohal wrote: > Hi, > > I have 5 nodes inside the cluster. My question is Can I just reindex one > node keeping other nodes on? > > > > Regards, > > Kishore Ohal
Re: Glob filtering of JCR events?
I think this can be exposed that. Given we also need to expose support for propertyName based filter and few other new filtering criteria its time we have JackrabbitEventFilter updated for that Chetan Mehrotra On Tue, Oct 18, 2016 at 8:33 PM, Carsten Ziegeler wrote: > Stefan Egli wrote >> On 18/10/16 16:44, "Michael Dürig" wrote: >> >>> On 18.10.16 4:39 , Stefan Egli wrote: >>>> On 18/10/16 16:09, "Michael Dürig" wrote: >>>> >>>>> Oak has some support for glob filters. An official API has yet to be >>>>> built though. >>>> >>>> What API changes were you thinking of? This sounds like implying that we >>>> can't declare the current JackrabbitEventFilter to now support glob >>>> filters? >>> >>> The glob support we have in Oak is currently not exposed through an >>> official API. >>> >>> I'm not implying that it cannot be exposed in any way. Neither am I >>> implying that it is the right kind of glob support for Sling's use case >>> nor anything else ;-) >> >> Sure. Taking the 'imply' part back then ;) >> >> My 'implied' assumption though was that it would be possible to support >> glob filtering through the JackrabbitEventFilter's already existing >> properties, namely the (include) paths. So atm we don't support glob for >> those paths. But to add support could perhaps be done by 'just' changing >> the javadoc (and of course the underlying implementation - but not the >> interface itself). But perhaps I'm missing some parts of the picture here. >> There might then of course be some question as to what and where exactly >> glob wildcards are supported (and does that match what Sling needs). >> > I think the requirement is easy: glob support which afaik are well > defined patterns, e.g. > documented at > https://jackrabbit.apache.org/oak/docs/apidocs/org/apache/jackrabbit/oak/plugins/observation/filter/GlobbingPathFilter.html > > In Sling we use that definition for observation paths. SO if an > observation path matches that pattern, the listener gets the event > (respecting change type of course) > > Regards > > Carsten > > -- > Carsten Ziegeler > Adobe Research Switzerland > cziege...@apache.org >
Re: Use of Repository for Test Case in jackrabbit-jcr-commons bundle
Looks like there are no integration test there. So you can possibly have a test case based on mocks. @Angela/Marcel - Any guidance on writing test for code in jackrabbit-jcr-commons. Here the requirement is to write test for FilteringItemVisitor regards Chetan Chetan Mehrotra On Tue, Aug 2, 2016 at 3:57 PM, Ankit Agarwal wrote: > Hi All, > > I am trying to write a test case for pull request [0]. > > For writing a test case for this, I will be needing to create a node but > there is no repository resource available in this bundle. > > So can you please let me do I need to add repository resource in this > bundle or is there any other way to create a test repository ? > > > > > > Thanks and Regards, > > Ankit Agarwal > > > > [0] https://github.com/apache/jackrabbit/pull/36
[jira] [Commented] (JCR-3997) TraversingItemVisitor causes stackoverflowexception with breadth first traversal
[ https://issues.apache.org/jira/browse/JCR-3997?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15391292#comment-15391292 ] Chetan Mehrotra commented on JCR-3997: -- [~anagarwa] Can you also provide a test case coverage for the changes done > TraversingItemVisitor causes stackoverflowexception with breadth first > traversal > > > Key: JCR-3997 > URL: https://issues.apache.org/jira/browse/JCR-3997 > Project: Jackrabbit Content Repository > Issue Type: Bug > Components: jackrabbit-jcr-commons > Reporter: Chetan Mehrotra > Fix For: 2.13.2 > > Attachments: OAK-4549-test.patch > > > [TraversingItemVisitor|https://docs.adobe.com/docs/en/spec/jsr170/javadocs/jcr-1.0/javax/jcr/util/TraversingItemVisitor.html] > when used in breadth first traversal mode can lead to StackOverflowException > with very flat child list. This happens because it uses recursion [1] instead > of plain iteration which would increase the stack size proportional to number > of immediate child node. > The code technically belong to JSR-283 project. For now creating the issue > here > [1] > https://java.net/projects/jsr-283/sources/svn/content/trunk/src/java/javax/jcr/util/TraversingItemVisitor.java?rev=967 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (JCR-3998) New putFile method which uses non referenceable oak:Resource nodetype
[
https://issues.apache.org/jira/browse/JCR-3998?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15385339#comment-15385339
]
Chetan Mehrotra commented on JCR-3998:
--
bq. Wouldn't it make more sense to create an oak specific class; let's say
JcrOakUtils in oak-commons and add such method in there?
Can be done however for this case we can avoid that as most people would miss
that out and would not get aware of this new method
The new method can check if {{oak:Resource}} nodetype is present then use that
otherwise fallsback to {{nt:resource}}. So as such it would not have dependency
on any Oak API but just an Oak specific nodetype
> New putFile method which uses non referenceable oak:Resource nodetype
> -
>
> Key: JCR-3998
> URL: https://issues.apache.org/jira/browse/JCR-3998
> Project: Jackrabbit Content Repository
> Issue Type: Improvement
> Components: jackrabbit-jcr-commons
>Reporter: Chetan Mehrotra
>Assignee: Chetan Mehrotra
> Fix For: 2.13.2
>
>
> With OAK-4567 a new oak:Resource type is being introduced which is a
> replacement for nt:resource for cases where referenceable nodes are not
> required.
> To make use of that we should add new variants of putFile in JcrUtil which
> make use of that
> See also http://jackrabbit-oak.markmail.org/thread/qicpzm5ltnzfsd42
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (JCR-3998) New putFile method which uses non referenceable oak:Resource nodetype
Chetan Mehrotra created JCR-3998: Summary: New putFile method which uses non referenceable oak:Resource nodetype Key: JCR-3998 URL: https://issues.apache.org/jira/browse/JCR-3998 Project: Jackrabbit Content Repository Issue Type: Improvement Components: jackrabbit-jcr-commons Reporter: Chetan Mehrotra Assignee: Chetan Mehrotra Fix For: 2.13.2 With OAK-4567 a new oak:Resource type is being introduced which is a replacement for nt:resource for cases where referenceable nodes are not required. To make use of that we should add new variants of putFile in JcrUtil which make use of that See also http://jackrabbit-oak.markmail.org/thread/qicpzm5ltnzfsd42 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (JCR-3997) TraversingItemVisitor causes stackoverflowexception with breadth first traversal
[ https://issues.apache.org/jira/browse/JCR-3997?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15378958#comment-15378958 ] Chetan Mehrotra commented on JCR-3997: -- Similar issue exists in [FilteringItemVisitor|https://github.com/apache/jackrabbit/blob/trunk/jackrabbit-jcr-commons/src/main/java/org/apache/jackrabbit/commons/visitor/FilteringItemVisitor.java] > TraversingItemVisitor causes stackoverflowexception with breadth first > traversal > > > Key: JCR-3997 > URL: https://issues.apache.org/jira/browse/JCR-3997 > Project: Jackrabbit Content Repository > Issue Type: Bug > Components: jackrabbit-jcr-commons > Reporter: Chetan Mehrotra > Fix For: 2.13.2 > > Attachments: OAK-4549-test.patch > > > [TraversingItemVisitor|https://docs.adobe.com/docs/en/spec/jsr170/javadocs/jcr-1.0/javax/jcr/util/TraversingItemVisitor.html] > when used in breadth first traversal mode can lead to StackOverflowException > with very flat child list. This happens because it uses recursion [1] instead > of plain iteration which would increase the stack size proportional to number > of immediate child node. > The code technically belong to JSR-283 project. For now creating the issue > here > [1] > https://java.net/projects/jsr-283/sources/svn/content/trunk/src/java/javax/jcr/util/TraversingItemVisitor.java?rev=967 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Moved] (JCR-3997) TraversingItemVisitor causes stackoverflowexception with breadth first traversal
[ https://issues.apache.org/jira/browse/JCR-3997?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chetan Mehrotra moved OAK-4549 to JCR-3997: --- Fix Version/s: (was: 1.6) 2.13.2 Component/s: (was: jcr) jackrabbit-jcr-commons Workflow: no-reopen-closed, patch-avail (was: no-reopen-closed) Key: JCR-3997 (was: OAK-4549) Project: Jackrabbit Content Repository (was: Jackrabbit Oak) > TraversingItemVisitor causes stackoverflowexception with breadth first > traversal > > > Key: JCR-3997 > URL: https://issues.apache.org/jira/browse/JCR-3997 > Project: Jackrabbit Content Repository > Issue Type: Bug > Components: jackrabbit-jcr-commons > Reporter: Chetan Mehrotra > Fix For: 2.13.2 > > Attachments: OAK-4549-test.patch > > > [TraversingItemVisitor|https://docs.adobe.com/docs/en/spec/jsr170/javadocs/jcr-1.0/javax/jcr/util/TraversingItemVisitor.html] > when used in breadth first traversal mode can lead to StackOverflowException > with very flat child list. This happens because it uses recursion [1] instead > of plain iteration which would increase the stack size proportional to number > of immediate child node. > The code technically belong to JSR-283 project. For now creating the issue > here > [1] > https://java.net/projects/jsr-283/sources/svn/content/trunk/src/java/javax/jcr/util/TraversingItemVisitor.java?rev=967 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
Re: New Jackrabbit committer: Tomek Rękawek
Welcome Tomek! Chetan Mehrotra On Mon, Mar 21, 2016 at 10:51 PM, Michael Dürig wrote: > Hi, > > Please welcome Tomek as a new committer and PMC member of the Apache > Jackrabbit project. The Jackrabbit PMC recently decided to offer Tomek > 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, Tomek! > > Michael
Re: [VOTE] Release Apache Jackrabbit Filevault 3.1.26
All test pass on the tag jackrabbit-filevault-3.1.26/ +1 Release this package as Apache Jackrabbit Filevault 3.1.26 Chetan Mehrotra On Wed, Jan 6, 2016 at 1:22 PM, Marcel Reutegger wrote: > On 06/01/16 02:57, "Tobias Bocanegra" wrote: >>Please vote on releasing this package as Apache Jackrabbit Filevault >>3.1.26. >>The vote is open for the next 72 hours and passes if a majority of at >>least three +1 Jackrabbit PMC votes are cast. > > All checks OK. > > +1 Release this package as Apache Jackrabbit Filevault 3.1.26 > > Regards > Marcel >
Re: Jackrabbit-trunk - Build # 2337 - Failure
Failure in Maven build --- [INFO] Internal error in the plugin manager executing goal 'org.apache.felix:maven-bundle-plugin:3.0.1:bundle': Unable to load the mojo 'org.apache.felix:maven-bundle-plugin:3.0.1:bundle' in the plugin 'org.apache.felix:maven-bundle-plugin'. A required class is missing: org/apache/maven/project/DependencyResolutionException org.apache.maven.project.DependencyResolutionException --- Looks like Jenkins is currently using Maven 2.x and we most likely newer version of maven-bundle-plugin requires Maven 3.x. So we would need to change Maven version configured with Jenkins --- maven2.1-interceptor.jar already up to date [trunk] $ /home/jenkins/jenkins-slave/tools/hudson.model.JDK/JDK_1.7_latest_/bin/java -Xmx1g -XX:MaxPermSize=300m -cp /home/jenkins/jenkins-slave/maven-agent.jar:/home/jenkins/jenkins-slave/classworlds.jar hudson.maven.agent.Main /home/jenkins/tools/maven/apache-maven-2.2.1 /x1/jenkins/jenkins-slave/slave.jar /home/jenkins/jenkins-slave/maven-interceptor.jar 41960 /home/jenkins/jenkins-slave/maven2.1-interceptor.jar --- Chetan Mehrotra On Tue, Dec 15, 2015 at 2:44 PM, Apache Jenkins Server wrote: > The Apache Jenkins build system has built Jackrabbit-trunk (build #2337) > > Status: Failure > > Check console output at https://builds.apache.org/job/Jackrabbit-trunk/2337/ > to view the results.
Re: [release blocked] Re: Jackrabbit 2.11.3 release plan
Thanks Angela for the pointer!. Would keep that in mind if I make any change in that area going forward Chetan Mehrotra On Thu, Dec 3, 2015 at 9:38 PM, Angela Schreiber wrote: > hi chetan > > and just for the record: if you changes something in any of the > *2spi or spi2* or the webdav modules you have to run the complete > jr build with -PintegrationTesting in order to trigger the tck being > run agains the different setup variants. they are not enabled > by default because it takes a while. > > thanks > angela > > On 03/12/15 13:23, "Davide Giannella" wrote: > >>On 03/12/2015 12:03, Davide Giannella wrote: >>> >>> The build is constantly failing, which means we can't release. >>> >>> https://builds.apache.org/job/Jackrabbit-trunk/2334/ >>> >>> >>>AccessControlManagerImplTest>AbstractJCRTest.run:464->testRemovePolicyAft >>>erASaveCall:120 >>> Repository >>> >>> >>I've reverted locally >>https://svn.apache.org/viewvc?view=revision&revision=1717620 and it >>succeed. >> >>@Chetan could you please have a look and fix please? >> >>Cheers >>Davide >
[jira] [Commented] (JCR-3934) Error occured while loading protected handler config in JcrRemotingServlet
[
https://issues.apache.org/jira/browse/JCR-3934?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15037215#comment-15037215
]
Chetan Mehrotra commented on JCR-3934:
--
[~alfu] [r1695294|http://svn.apache.org/viewvc?view=revision&revision=1695294]
looks like did not add the xml to the
[jackrabbit-webapp|https://github.com/apache/jackrabbit/tree/trunk/jackrabbit-webapp/src/main/webapp/WEB-INF]
module and only web.xml is updated.
bq. so am a bit confuse how a /WEB-INF/protectedHandlers.properties file is
used in your setup. did you explicitly made this modification to your local
checkout?
The above exception was for another [webapp
module|https://github.com/apache/jackrabbit-oak/tree/trunk/oak-examples/webapp/src/main/webapp/WEB-INF]
that is being implemented in oak and was derived from jackrabbit-webapp. I
have updated that to now use xml based config with
[1717633|https://github.com/apache/jackrabbit-oak/commit/19db8486e0d76807d9e2d00574c2335969423a9c].
Hope the changes done are correct!
> Error occured while loading protected handler config in JcrRemotingServlet
> --
>
> Key: JCR-3934
> URL: https://issues.apache.org/jira/browse/JCR-3934
> Project: Jackrabbit Content Repository
> Issue Type: Bug
> Components: jackrabbit-jcr-server
>Affects Versions: 2.9.1
>Reporter: Chetan Mehrotra
>Assignee: Chetan Mehrotra
>Priority: Minor
> Fix For: 2.11.3
>
> Attachments: JCR-3934.patch
>
>
> Currently in webapp the JcrRemotingServlet has config like
> {code:xml}
>
> protectedhandlers-config
> /WEB-INF/protectedHandlers.properties
> JcrRemotingServlet: Handlers for removing protected
> items.
>
> {code}
> This causes exception in loading like
> {noformat}
> 01.12.2015 11:10:36.194 *ERROR* [main]
> org.apache.jackrabbit.server.remoting.davex.ProtectedRemoveManager
> /WEB-INF/protectedHandlers.properties
> java.lang.ClassNotFoundException: /WEB-INF/protectedHandlers.properties
> at java.lang.Class.forName0(Native Method) ~[na:1.7.0_55]
> at java.lang.Class.forName(Class.java:190) ~[na:1.7.0_55]
> at
> org.apache.jackrabbit.server.remoting.davex.ProtectedRemoveManager.createHandler(ProtectedRemoveManager.java:84)
> [jackrabbit-jcr-server-2.11.3-SNAPSHOT.jar:na]
> at
> org.apache.jackrabbit.server.remoting.davex.ProtectedRemoveManager.(ProtectedRemoveManager.java:56)
> [jackrabbit-jcr-server-2.11.3-SNAPSHOT.jar:na]
> at
> org.apache.jackrabbit.server.remoting.davex.JcrRemotingServlet.init(JcrRemotingServlet.java:276)
> [jackrabbit-jcr-server-2.11.3-SNAPSHOT.jar:na]
> at javax.servlet.GenericServlet.init(GenericServlet.java:244)
> [javax.servlet-api-3.1.0.jar:3.1.0]
> at
> org.eclipse.jetty.servlet.ServletHolder.initServlet(ServletHolder.java:612)
> [jetty-servlet-9.2.8.v20150217.jar:9.2.8.v20150217]
> at
> org.eclipse.jetty.servlet.ServletHolder.initialize(ServletHolder.java:395)
> [jetty-servlet-9.2.8.v20150217.jar:9.2.8.v20150217]
> at
> org.eclipse.jetty.servlet.ServletHandler.initialize(ServletHandler.java:871)
> [jetty-servlet-9.2.8.v20150217.jar:9.2.8.v20150217]
> at
> org.eclipse.jetty.servlet.ServletContextHandler.startContext(ServletContextHandler.java:298)
> [jetty-servlet-9.2.8.v20150217.jar:9.2.8.v20150217]
> at
> org.eclipse.jetty.webapp.WebAppContext.startWebapp(WebAppContext.java:1349)
> [jetty-webapp-9.2.8.v20150217.jar:9.2.8.v20150217]
> at
> org.eclipse.jetty.maven.plugin.JettyWebAppContext.startWebapp(JettyWebAppContext.java:296)
> [jetty-maven-plugin-9.2.8.v20150217.jar:9.2.8.v20150217]
> {noformat}
> This happens because
> [ProtectedRemoveManager|https://github.com/apache/jackrabbit/blob/2.11.2/jackrabbit-jcr-server/src/main/java/org/apache/jackrabbit/server/remoting/davex/ProtectedRemoveManager.java#L39]
> tries to load the config file directly by treating it as a file on
> filesystem. Instead it should be passed a input stream.
> For now as the config has single handle one can just specify the class
> directly
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Resolved] (JCR-3934) Error occured while loading protected handler config in JcrRemotingServlet
[
https://issues.apache.org/jira/browse/JCR-3934?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Chetan Mehrotra resolved JCR-3934.
--
Resolution: Fixed
Assignee: Chetan Mehrotra
Modified the init logic to get inputstream from servlet context and use that to
initialize ProtectedRemoveManager
rev 1717620
> Error occured while loading protected handler config in JcrRemotingServlet
> --
>
> Key: JCR-3934
> URL: https://issues.apache.org/jira/browse/JCR-3934
> Project: Jackrabbit Content Repository
> Issue Type: Bug
> Components: jackrabbit-jcr-server
>Affects Versions: 2.9.1
> Reporter: Chetan Mehrotra
>Assignee: Chetan Mehrotra
>Priority: Minor
> Fix For: 2.11.3
>
> Attachments: JCR-3934.patch
>
>
> Currently in webapp the JcrRemotingServlet has config like
> {code:xml}
>
> protectedhandlers-config
> /WEB-INF/protectedHandlers.properties
> JcrRemotingServlet: Handlers for removing protected
> items.
>
> {code}
> This causes exception in loading like
> {noformat}
> 01.12.2015 11:10:36.194 *ERROR* [main]
> org.apache.jackrabbit.server.remoting.davex.ProtectedRemoveManager
> /WEB-INF/protectedHandlers.properties
> java.lang.ClassNotFoundException: /WEB-INF/protectedHandlers.properties
> at java.lang.Class.forName0(Native Method) ~[na:1.7.0_55]
> at java.lang.Class.forName(Class.java:190) ~[na:1.7.0_55]
> at
> org.apache.jackrabbit.server.remoting.davex.ProtectedRemoveManager.createHandler(ProtectedRemoveManager.java:84)
> [jackrabbit-jcr-server-2.11.3-SNAPSHOT.jar:na]
> at
> org.apache.jackrabbit.server.remoting.davex.ProtectedRemoveManager.(ProtectedRemoveManager.java:56)
> [jackrabbit-jcr-server-2.11.3-SNAPSHOT.jar:na]
> at
> org.apache.jackrabbit.server.remoting.davex.JcrRemotingServlet.init(JcrRemotingServlet.java:276)
> [jackrabbit-jcr-server-2.11.3-SNAPSHOT.jar:na]
> at javax.servlet.GenericServlet.init(GenericServlet.java:244)
> [javax.servlet-api-3.1.0.jar:3.1.0]
> at
> org.eclipse.jetty.servlet.ServletHolder.initServlet(ServletHolder.java:612)
> [jetty-servlet-9.2.8.v20150217.jar:9.2.8.v20150217]
> at
> org.eclipse.jetty.servlet.ServletHolder.initialize(ServletHolder.java:395)
> [jetty-servlet-9.2.8.v20150217.jar:9.2.8.v20150217]
> at
> org.eclipse.jetty.servlet.ServletHandler.initialize(ServletHandler.java:871)
> [jetty-servlet-9.2.8.v20150217.jar:9.2.8.v20150217]
> at
> org.eclipse.jetty.servlet.ServletContextHandler.startContext(ServletContextHandler.java:298)
> [jetty-servlet-9.2.8.v20150217.jar:9.2.8.v20150217]
> at
> org.eclipse.jetty.webapp.WebAppContext.startWebapp(WebAppContext.java:1349)
> [jetty-webapp-9.2.8.v20150217.jar:9.2.8.v20150217]
> at
> org.eclipse.jetty.maven.plugin.JettyWebAppContext.startWebapp(JettyWebAppContext.java:296)
> [jetty-maven-plugin-9.2.8.v20150217.jar:9.2.8.v20150217]
> {noformat}
> This happens because
> [ProtectedRemoveManager|https://github.com/apache/jackrabbit/blob/2.11.2/jackrabbit-jcr-server/src/main/java/org/apache/jackrabbit/server/remoting/davex/ProtectedRemoveManager.java#L39]
> tries to load the config file directly by treating it as a file on
> filesystem. Instead it should be passed a input stream.
> For now as the config has single handle one can just specify the class
> directly
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (JCR-3934) Error occured while loading protected handler config in JcrRemotingServlet
[
https://issues.apache.org/jira/browse/JCR-3934?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Chetan Mehrotra updated JCR-3934:
-
Attachment: JCR-3934.patch
[patch|^JCR-3934.patch] for the same
[~alfu] Can you have a look this is part of JCR-2113 feature which you worked
upon
> Error occured while loading protected handler config in JcrRemotingServlet
> --
>
> Key: JCR-3934
> URL: https://issues.apache.org/jira/browse/JCR-3934
> Project: Jackrabbit Content Repository
> Issue Type: Bug
> Components: jackrabbit-jcr-server
>Affects Versions: 2.9.1
> Reporter: Chetan Mehrotra
>Priority: Minor
> Fix For: 2.11.3
>
> Attachments: JCR-3934.patch
>
>
> Currently in webapp the JcrRemotingServlet has config like
> {code:xml}
>
> protectedhandlers-config
> /WEB-INF/protectedHandlers.properties
> JcrRemotingServlet: Handlers for removing protected
> items.
>
> {code}
> This causes exception in loading like
> {noformat}
> 01.12.2015 11:10:36.194 *ERROR* [main]
> org.apache.jackrabbit.server.remoting.davex.ProtectedRemoveManager
> /WEB-INF/protectedHandlers.properties
> java.lang.ClassNotFoundException: /WEB-INF/protectedHandlers.properties
> at java.lang.Class.forName0(Native Method) ~[na:1.7.0_55]
> at java.lang.Class.forName(Class.java:190) ~[na:1.7.0_55]
> at
> org.apache.jackrabbit.server.remoting.davex.ProtectedRemoveManager.createHandler(ProtectedRemoveManager.java:84)
> [jackrabbit-jcr-server-2.11.3-SNAPSHOT.jar:na]
> at
> org.apache.jackrabbit.server.remoting.davex.ProtectedRemoveManager.(ProtectedRemoveManager.java:56)
> [jackrabbit-jcr-server-2.11.3-SNAPSHOT.jar:na]
> at
> org.apache.jackrabbit.server.remoting.davex.JcrRemotingServlet.init(JcrRemotingServlet.java:276)
> [jackrabbit-jcr-server-2.11.3-SNAPSHOT.jar:na]
> at javax.servlet.GenericServlet.init(GenericServlet.java:244)
> [javax.servlet-api-3.1.0.jar:3.1.0]
> at
> org.eclipse.jetty.servlet.ServletHolder.initServlet(ServletHolder.java:612)
> [jetty-servlet-9.2.8.v20150217.jar:9.2.8.v20150217]
> at
> org.eclipse.jetty.servlet.ServletHolder.initialize(ServletHolder.java:395)
> [jetty-servlet-9.2.8.v20150217.jar:9.2.8.v20150217]
> at
> org.eclipse.jetty.servlet.ServletHandler.initialize(ServletHandler.java:871)
> [jetty-servlet-9.2.8.v20150217.jar:9.2.8.v20150217]
> at
> org.eclipse.jetty.servlet.ServletContextHandler.startContext(ServletContextHandler.java:298)
> [jetty-servlet-9.2.8.v20150217.jar:9.2.8.v20150217]
> at
> org.eclipse.jetty.webapp.WebAppContext.startWebapp(WebAppContext.java:1349)
> [jetty-webapp-9.2.8.v20150217.jar:9.2.8.v20150217]
> at
> org.eclipse.jetty.maven.plugin.JettyWebAppContext.startWebapp(JettyWebAppContext.java:296)
> [jetty-maven-plugin-9.2.8.v20150217.jar:9.2.8.v20150217]
> {noformat}
> This happens because
> [ProtectedRemoveManager|https://github.com/apache/jackrabbit/blob/2.11.2/jackrabbit-jcr-server/src/main/java/org/apache/jackrabbit/server/remoting/davex/ProtectedRemoveManager.java#L39]
> tries to load the config file directly by treating it as a file on
> filesystem. Instead it should be passed a input stream.
> For now as the config has single handle one can just specify the class
> directly
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (JCR-3934) Error occured while loading protected handler config in JcrRemotingServlet
[
https://issues.apache.org/jira/browse/JCR-3934?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Chetan Mehrotra updated JCR-3934:
-
Fix Version/s: 2.11.3
> Error occured while loading protected handler config in JcrRemotingServlet
> --
>
> Key: JCR-3934
> URL: https://issues.apache.org/jira/browse/JCR-3934
> Project: Jackrabbit Content Repository
> Issue Type: Bug
> Components: jackrabbit-jcr-server
>Affects Versions: 2.9.1
> Reporter: Chetan Mehrotra
>Priority: Minor
> Fix For: 2.11.3
>
>
> Currently in webapp the JcrRemotingServlet has config like
> {code:xml}
>
> protectedhandlers-config
> /WEB-INF/protectedHandlers.properties
> JcrRemotingServlet: Handlers for removing protected
> items.
>
> {code}
> This causes exception in loading like
> {noformat}
> 01.12.2015 11:10:36.194 *ERROR* [main]
> org.apache.jackrabbit.server.remoting.davex.ProtectedRemoveManager
> /WEB-INF/protectedHandlers.properties
> java.lang.ClassNotFoundException: /WEB-INF/protectedHandlers.properties
> at java.lang.Class.forName0(Native Method) ~[na:1.7.0_55]
> at java.lang.Class.forName(Class.java:190) ~[na:1.7.0_55]
> at
> org.apache.jackrabbit.server.remoting.davex.ProtectedRemoveManager.createHandler(ProtectedRemoveManager.java:84)
> [jackrabbit-jcr-server-2.11.3-SNAPSHOT.jar:na]
> at
> org.apache.jackrabbit.server.remoting.davex.ProtectedRemoveManager.(ProtectedRemoveManager.java:56)
> [jackrabbit-jcr-server-2.11.3-SNAPSHOT.jar:na]
> at
> org.apache.jackrabbit.server.remoting.davex.JcrRemotingServlet.init(JcrRemotingServlet.java:276)
> [jackrabbit-jcr-server-2.11.3-SNAPSHOT.jar:na]
> at javax.servlet.GenericServlet.init(GenericServlet.java:244)
> [javax.servlet-api-3.1.0.jar:3.1.0]
> at
> org.eclipse.jetty.servlet.ServletHolder.initServlet(ServletHolder.java:612)
> [jetty-servlet-9.2.8.v20150217.jar:9.2.8.v20150217]
> at
> org.eclipse.jetty.servlet.ServletHolder.initialize(ServletHolder.java:395)
> [jetty-servlet-9.2.8.v20150217.jar:9.2.8.v20150217]
> at
> org.eclipse.jetty.servlet.ServletHandler.initialize(ServletHandler.java:871)
> [jetty-servlet-9.2.8.v20150217.jar:9.2.8.v20150217]
> at
> org.eclipse.jetty.servlet.ServletContextHandler.startContext(ServletContextHandler.java:298)
> [jetty-servlet-9.2.8.v20150217.jar:9.2.8.v20150217]
> at
> org.eclipse.jetty.webapp.WebAppContext.startWebapp(WebAppContext.java:1349)
> [jetty-webapp-9.2.8.v20150217.jar:9.2.8.v20150217]
> at
> org.eclipse.jetty.maven.plugin.JettyWebAppContext.startWebapp(JettyWebAppContext.java:296)
> [jetty-maven-plugin-9.2.8.v20150217.jar:9.2.8.v20150217]
> {noformat}
> This happens because
> [ProtectedRemoveManager|https://github.com/apache/jackrabbit/blob/2.11.2/jackrabbit-jcr-server/src/main/java/org/apache/jackrabbit/server/remoting/davex/ProtectedRemoveManager.java#L39]
> tries to load the config file directly by treating it as a file on
> filesystem. Instead it should be passed a input stream.
> For now as the config has single handle one can just specify the class
> directly
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (JCR-3934) Error occured while loading protected handler config in JcrRemotingServlet
Chetan Mehrotra created JCR-3934:
Summary: Error occured while loading protected handler config in
JcrRemotingServlet
Key: JCR-3934
URL: https://issues.apache.org/jira/browse/JCR-3934
Project: Jackrabbit Content Repository
Issue Type: Bug
Components: jackrabbit-jcr-server
Affects Versions: 2.9.1
Reporter: Chetan Mehrotra
Priority: Minor
Currently in webapp the JcrRemotingServlet has config like
{code:xml}
protectedhandlers-config
/WEB-INF/protectedHandlers.properties
JcrRemotingServlet: Handlers for removing protected
items.
{code}
This causes exception in loading like
{noformat}
01.12.2015 11:10:36.194 *ERROR* [main]
org.apache.jackrabbit.server.remoting.davex.ProtectedRemoveManager
/WEB-INF/protectedHandlers.properties
java.lang.ClassNotFoundException: /WEB-INF/protectedHandlers.properties
at java.lang.Class.forName0(Native Method) ~[na:1.7.0_55]
at java.lang.Class.forName(Class.java:190) ~[na:1.7.0_55]
at
org.apache.jackrabbit.server.remoting.davex.ProtectedRemoveManager.createHandler(ProtectedRemoveManager.java:84)
[jackrabbit-jcr-server-2.11.3-SNAPSHOT.jar:na]
at
org.apache.jackrabbit.server.remoting.davex.ProtectedRemoveManager.(ProtectedRemoveManager.java:56)
[jackrabbit-jcr-server-2.11.3-SNAPSHOT.jar:na]
at
org.apache.jackrabbit.server.remoting.davex.JcrRemotingServlet.init(JcrRemotingServlet.java:276)
[jackrabbit-jcr-server-2.11.3-SNAPSHOT.jar:na]
at javax.servlet.GenericServlet.init(GenericServlet.java:244)
[javax.servlet-api-3.1.0.jar:3.1.0]
at
org.eclipse.jetty.servlet.ServletHolder.initServlet(ServletHolder.java:612)
[jetty-servlet-9.2.8.v20150217.jar:9.2.8.v20150217]
at
org.eclipse.jetty.servlet.ServletHolder.initialize(ServletHolder.java:395)
[jetty-servlet-9.2.8.v20150217.jar:9.2.8.v20150217]
at
org.eclipse.jetty.servlet.ServletHandler.initialize(ServletHandler.java:871)
[jetty-servlet-9.2.8.v20150217.jar:9.2.8.v20150217]
at
org.eclipse.jetty.servlet.ServletContextHandler.startContext(ServletContextHandler.java:298)
[jetty-servlet-9.2.8.v20150217.jar:9.2.8.v20150217]
at
org.eclipse.jetty.webapp.WebAppContext.startWebapp(WebAppContext.java:1349)
[jetty-webapp-9.2.8.v20150217.jar:9.2.8.v20150217]
at
org.eclipse.jetty.maven.plugin.JettyWebAppContext.startWebapp(JettyWebAppContext.java:296)
[jetty-maven-plugin-9.2.8.v20150217.jar:9.2.8.v20150217]
{noformat}
This happens because
[ProtectedRemoveManager|https://github.com/apache/jackrabbit/blob/2.11.2/jackrabbit-jcr-server/src/main/java/org/apache/jackrabbit/server/remoting/davex/ProtectedRemoveManager.java#L39]
tries to load the config file directly by treating it as a file on filesystem.
Instead it should be passed a input stream.
For now as the config has single handle one can just specify the class directly
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
Re: New Jackrabbit committer: Vikas Saurabh
Welcome Vikas ! Chetan Mehrotra On Fri, Nov 6, 2015 at 6:38 PM, Michael Dürig wrote: > Hi, > > Please welcome Vikas as a new committer and PMC member of the Apache > Jackrabbit project. The Jackrabbit PMC recently decided to offer Vikas > 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, Vikas! > > Michael
Re: Unable to open Lucene Index
Hi Clay,
For past few days I have played with your application (its nice!) and
tried to reproduce the issue. I saw the above error once and then did
not observed it. So I would try further to see whats the issue here.
Technically Lucene indexes should not get corrupted like this and be
resilient.
On a side note - I have modified your app at [1] to try out a new way
of setting up in non OSGi env. The repository is now able to come up
fine. It uses Oak PojoSR module [2]. You can possibly give it a try!
For more details and background refer to the thread on oak-dev [3].
Thanks again for your effort here. It helps us to understand
requirement of end user application easily and enables us to test out
new approaches.!
Chetan Mehrotra
[1] https://github.com/chetanmeh/meta64
[2] https://github.com/apache/jackrabbit-oak/tree/trunk/oak-pojosr
[3] http://markmail.org/thread/b32cuw5xpcuvypsv
On Sun, Aug 16, 2015 at 9:48 PM, Clay Ferguson wrote:
> Fellow Jackrabbits:
>
> Encountered the unrecoverable Lucene error again yesterday:
>
> Could not access the Lucene index at /oak:index/lastModifiedIndex
> java.io.FileNotFoundException: _g.si
>
> The next time it happens I'll try and debug it. But I glanced at the code in
> OakDirectory.openInput, and my gut feeling is that the locking and recovery
> mechanisms are not robust enough to survive an abrupt shutdown of server, by
> clicking "stop running" button in Eclipse IDE for example. Or there's a
> chance I'm not shutting down correctly?? The code for open/close of
> repository is here (it's a tiny file):
>
> https://github.com/Clay-Ferguson/meta64/blob/master/src/main/java/com/meta64/mobile/repo/OakRepository.java
>
> The only way to recover is to restart the server with
> OakRepository.indexEnabled=false, and then delete the Index Nodes (i'm using
> MongoDB, based index storage), and then restart with index reenabled.
>
> Also, perhaps I need a shutdown hook like this?
> Runtime.getRuntime().addShutdownHook(new Thread(new Runnable() {
> @Override
> public void run() {
> store.close();
> }
> }));
>
> I'll add that shutdown hook and see if the problem persists. I guess it's my
> fault if the shutdownhook is 'required', but still there is always a chance
> for power outage or hardware failure, so the Lucene index should be robust
> enough to never become unrecoverable, IMO.
>
> Finally here's the error:
>
>
> 2015-08-16 03:00:04.610 INFO 4452 --- [ main]
> s.b.c.e.t.TomcatEmbeddedServletContainer : Tomcat initialized with port(s):
> 80 (http)
> 2015-08-16 03:00:04.869 INFO 4452 --- [ main]
> o.apache.catalina.core.StandardService : Starting service Tomcat
> 2015-08-16 03:00:04.870 INFO 4452 --- [ main]
> org.apache.catalina.core.StandardEngine : Starting Servlet Engine: Apache
> Tomcat/8.0.23
> 2015-08-16 03:00:05.060 INFO 4452 --- [ost-startStop-1]
> o.a.c.c.C.[Tomcat].[localhost].[/] : Initializing Spring embedded
> WebApplicationContext
> 2015-08-16 03:00:05.060 INFO 4452 --- [ost-startStop-1]
> o.s.web.context.ContextLoader: Root WebApplicationContext:
> initialization completed in 3237 ms
> 2015-08-16 03:00:06.180 INFO 4452 --- [ost-startStop-1]
> o.s.b.c.e.ServletRegistrationBean: Mapping servlet:
> 'dispatcherServlet' to [/]
> 2015-08-16 03:00:06.184 INFO 4452 --- [ost-startStop-1]
> o.s.b.c.embedded.FilterRegistrationBean : Mapping filter:
> 'characterEncodingFilter' to: [/*]
> 2015-08-16 03:00:06.184 INFO 4452 --- [ost-startStop-1]
> o.s.b.c.embedded.FilterRegistrationBean : Mapping filter:
> 'hiddenHttpMethodFilter' to: [/*]
> 2015-08-16 03:00:06.563 INFO 4452 --- [ main]
> o.a.j.o.p.d.mongo.MongoDocumentStore : Configuration
> maxReplicationLagMillis 2160, maxDeltaForModTimeIdxSecs 60,
> disableIndexHint false
> 2015-08-16 03:00:06.719 INFO 4452 --- [ main]
> o.a.j.o.p.document.LastRevRecoveryAgent : Recovering candidates modified
> after: [2015-08-16 02:55:31.451] for clusterId [1]
> 2015-08-16 03:00:06.750 INFO 4452 --- [ main]
> o.a.j.o.p.document.LastRevRecoveryAgent : Updated lastRev of [0] documents
> while performing lastRev recovery for cluster node [1]: {}
> 2015-08-16 03:00:06.759 INFO 4452 --- [ main]
> o.a.j.o.p.document.DocumentNodeStore : Initialized DocumentNodeStore
> with clusterNodeId: 1
> 2015-08-16 03:00:07.389 DEBUG 4452 --- [ main]
> c.m.m.repo.LuceneFullTextInitializer : Index node already exists:
> oak:index/contentIndex so it will not be created.
> 2015-08-16 03:00:07.392 DEBUG 4452 --- [ main]
> c.m.mobile.
Re: [VOTE] Release Apache Jackrabbit 2.10.2
On Thu, Aug 6, 2015 at 2:21 PM, Angela Schreiber wrote: > i am fine... > quite frankly i am surprised to see that there is no 2.10 > branch. I think this was discussed earlier [1]. Looks like we would have to revisit that decision and continue with stable/unstable releases Chetan Mehrotra [1] http://markmail.org/thread/p7k6lzbebgrgoz63
Re: JCR + MongoDb + Lucene Holy Grail Finally Found
Thanks Clay for putting this together. Current documentation is not good for standalone usage as quite a bit of logic of configuring Oak is based on OSGi. Due to that using Oak as is in standalone environment is tricky The oak-pojosr [1] was intended to enable use of Oak with all its OSGi based config in non OSGi env like say war deployment. Need to get some time to finish it and adopt the standalone web example to use that Chetan Mehrotra [1] https://github.com/apache/jackrabbit-oak/tree/trunk/oak-pojosr On Sun, Aug 2, 2015 at 11:26 PM, Clay Ferguson wrote: > Fellow Jackrabbits, > > I discovered it was a *huge* effort and there is a *huge* lack in the > examples related to simply getting MongoDb up and running (as JCR) with > Lucene indexes getting properly used. Since this effort took me 2 solid days > and there are no great examples that come up via google i'm sharing my > example: > > This code creates a Full Text Search on jcr:content, and an sorting > capability on jcr:lastModified: > > https://github.com/Clay-Ferguson/meta64/blob/master/src/main/java/com/meta64/mobile/repo/OakRepository.java > > I also just updated meta64 project to be using the 1.0.18 branch of the > Jackrabbit code, so it's all up to date stuff. I would highly recommend > adding this or a similar example right onto the Lucene page of the Oak docs, > because what I'm doing is exactly what everyone else wants, and the > documentation itself is just completely confusing and mind boggling without > a real example. > > Cheers, and happy jackrabbiting. > > Best regards, > Clay Ferguson > wcl...@gmail.com > meta64.com >
Re: New committer: Stefan Egli
Welcome Stefan! Chetan Mehrotra On Mon, Jul 20, 2015 at 1:56 PM, Michael Dürig wrote: > > Hi, > > Please welcome Stefan as a new committer and PMC member of the Apache > Jackrabbit project. The Jackrabbit PMC recently decided to offer Stefan > 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, Stefan! > > Michael
[jira] [Commented] (JCR-3865) Use markdown to generate Jackrabbit Site
[
https://issues.apache.org/jira/browse/JCR-3865?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14486716#comment-14486716
]
Chetan Mehrotra commented on JCR-3865:
--
bq. note that the site only updates the 'jackrabbit/site/live/jcr' directory.
handling the entire site is very slow, since scm-publish checks out the entire
tree.
In Oak I avoid doing the complete checkin by first running the build with
{{-Dscmpublish.skipCheckin=true}} and then just checkin in the changed html
files. But yes it still has the drawback of checking out whole site which might
be slow
> Use markdown to generate Jackrabbit Site
>
>
> Key: JCR-3865
> URL: https://issues.apache.org/jira/browse/JCR-3865
> Project: Jackrabbit Content Repository
> Issue Type: Improvement
> Components: docs
>Reporter: Tobias Bocanegra
>Assignee: Tobias Bocanegra
>Priority: Minor
>
> The current jackrabbit site is nor well maintained, mainly because we need to
> edit directly the HTML. most of the content is already available as markdown.
> goal is to automate the site generation via maven and svn pubsub.
> 1. phase is to reuse the same template/skin as in oak and to get the content
> right.
> 2. phase is to beautify it.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
Re: [VOTE] Release Apache Jackrabbit Filevault 3.1.18
+1 Chetan Mehrotra On Thu, Apr 2, 2015 at 2:55 AM, Tobias Bocanegra wrote: > > [ ] +1 Release this package as Apache Jackrabbit Filevault 3.1.18 > > [ ] -1 Do not release this package because... > > Here's my +1 >
Re: New committer: Shashank Gupta
Welcome Shashank! Chetan Mehrotra On Thu, Mar 26, 2015 at 8:56 AM, Amit Jain wrote: > Welcome Shashank!! > > On Thu, Mar 26, 2015 at 2:20 AM, Michael Dürig wrote: > >> Hi, >> >> Please welcome Shashank Gupta as a new committer and PMC member of >> the Apache Jackrabbit project. The Jackrabbit PMC recently decided to >> offer Shashank 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, Shashank! >> >> Michael >> > >
[jira] [Commented] (JCR-3862) [FileDataStore]: deleteRecord leaves the parent directories empty
[ https://issues.apache.org/jira/browse/JCR-3862?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14375782#comment-14375782 ] Chetan Mehrotra commented on JCR-3862: -- +1. Patch looks fine > [FileDataStore]: deleteRecord leaves the parent directories empty > - > > Key: JCR-3862 > URL: https://issues.apache.org/jira/browse/JCR-3862 > Project: Jackrabbit Content Repository > Issue Type: Bug > Components: jackrabbit-data >Reporter: Amit Jain >Assignee: Amit Jain > Attachments: JCR-3862-mreutegg.patch, JCR-3862.patch > > > Calling deleteRecord to delete a particular record does not delete any empty > parent directories empty. Oak uses this particular method for garbage > collection due to which after a while large number of empty directories keep > lying around, making the process increasingly slower. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
Re: [VOTE] Release Apache Jackrabbit Filevault 3.1.10
+1, all checks ok. Chetan Mehrotra
[jira] [Commented] (JCRSITE-47) Site is completely broken
[ https://issues.apache.org/jira/browse/JCRSITE-47?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14201755#comment-14201755 ] Chetan Mehrotra commented on JCRSITE-47: The site is back up again > Site is completely broken > - > > Key: JCRSITE-47 > URL: https://issues.apache.org/jira/browse/JCRSITE-47 > Project: Jackrabbit Site > Issue Type: Bug > Components: site >Reporter: Rick Herrick >Priority: Blocker > Attachments: Screen Shot 2014-11-05 at 7.27.14 AM.png > > > The [Jackrabbit site|http://jackrabbit.apache.org] is completely broken and > unusable. It has been for at least a couple of days. We're trying to decide > if we should be using Jackrabbit as a back-end storage system. Does this > indicate we shouldn't be using Jackrabbit as it's not being maintained? > Should we be looking to Oak instead? -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (JCRSITE-47) Site is completely broken
[
https://issues.apache.org/jira/browse/JCRSITE-47?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14201721#comment-14201721
]
Chetan Mehrotra commented on JCRSITE-47:
Checked with [~humbedooh] from ASF Infra on HipChat and got a quick response
(Thanks Daniel! )
{quote}
this looks to be an issue of htaccess files not being explicitly allowed on the
new machine hosting the US version of your website - I have pushed a change to
it, which should go live within 30 minutes time
{quote}
So should get back soon.
> Site is completely broken
> -
>
> Key: JCRSITE-47
> URL: https://issues.apache.org/jira/browse/JCRSITE-47
> Project: Jackrabbit Site
> Issue Type: Bug
> Components: site
>Reporter: Rick Herrick
>Priority: Blocker
> Attachments: Screen Shot 2014-11-05 at 7.27.14 AM.png
>
>
> The [Jackrabbit site|http://jackrabbit.apache.org] is completely broken and
> unusable. It has been for at least a couple of days. We're trying to decide
> if we should be using Jackrabbit as a back-end storage system. Does this
> indicate we shouldn't be using Jackrabbit as it's not being maintained?
> Should we be looking to Oak instead?
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (JCRSITE-47) Site is completely broken
[
https://issues.apache.org/jira/browse/JCRSITE-47?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14201697#comment-14201697
]
Chetan Mehrotra commented on JCRSITE-47:
Looks like {{.htaccess}} is not being honoured at all. Tried using
RedirectMatch also but that did not helped. Would look further
> Site is completely broken
> -
>
> Key: JCRSITE-47
> URL: https://issues.apache.org/jira/browse/JCRSITE-47
> Project: Jackrabbit Site
> Issue Type: Bug
> Components: site
>Reporter: Rick Herrick
>Priority: Blocker
> Attachments: Screen Shot 2014-11-05 at 7.27.14 AM.png
>
>
> The [Jackrabbit site|http://jackrabbit.apache.org] is completely broken and
> unusable. It has been for at least a couple of days. We're trying to decide
> if we should be using Jackrabbit as a back-end storage system. Does this
> indicate we shouldn't be using Jackrabbit as it's not being maintained?
> Should we be looking to Oak instead?
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
Re: New Jackrabbit committer: Amit Jain
Welcome Amit!! Chetan Mehrotra On Wed, Aug 27, 2014 at 12:51 PM, Tommaso Teofili wrote: > welcome Amit! > > Regards, > Tommaso > > > 2014-08-26 22:06 GMT+02:00 Michael Dürig : > >> 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 >> >
Avoiding intermediate saves while installing packages via File Vault
Hi, Currently JR FileVault supports 'noIntermediateSaves' property which indicates that no intermediate save would be performed while a package is being installed. However it does not appear to work as expected 1. AutoSave Usage For this it uses AutoSave class which commits the change if certain threshold is reached. If 'noIntermediateSaves' is set then this threshold is set to Integer.MAX thus effectively disabling intermediate commits. I see AutoSave being used at two placed in Importer. One of them is guarded by autoSave.needsSave but other one is not [1]. Would that be a bug? 2. Sub Packages - Other place where it does not work properly is when a package contains sub packages as Vault needs to save details regarding intermediate packages at various stages which causes any content changes also getting committed. I see quite a few calls to Item.save in vault codebase for the path taken by package installation. It might be possible to use a sub session to perform internal bookkeeping task by vault and use ther other session to save the package content and thus avoid intermediate save. Chetan Mehrotra [1] https://github.com/apache/jackrabbit-filevault/blob/trunk/vault-core/src/main/java/org/apache/jackrabbit/vault/fs/io/Importer.java#L402
[jira] [Updated] (JCR-3788) S3DataStore require to set endpoint for thirdparty cloud provider (IDCF)
[ https://issues.apache.org/jira/browse/JCR-3788?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chetan Mehrotra updated JCR-3788: - Fix Version/s: (was: 2.7.5) 2.9 > S3DataStore require to set endpoint for thirdparty cloud provider (IDCF) > - > > Key: JCR-3788 > URL: https://issues.apache.org/jira/browse/JCR-3788 > Project: Jackrabbit Content Repository > Issue Type: Improvement > Components: jackrabbit-data >Affects Versions: 2.7.5 >Reporter: Shashank Gupta >Assignee: Chetan Mehrotra > Fix For: 2.9 > > Attachments: JCR-3788.patch > > > For IDCF cloud provider API are compatible to AWS S3 SDK. > We can access S3 without any endpoint since S3 API should be designed and > include S3 URL or address so that it can access to S3 if there are not any > endpoint. > However, any address or endpoint needs to be set for 3rd party cloud provider. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (JCR-3788) S3DataStore require to set endpoint for thirdparty cloud provider (IDCF)
[ https://issues.apache.org/jira/browse/JCR-3788?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chetan Mehrotra updated JCR-3788: - Resolution: Fixed Assignee: Chetan Mehrotra Status: Resolved (was: Patch Available) Applied the patch in http://svn.apache.org/r1601550. The region would now be specified before the call to check for bucket existence would be made > S3DataStore require to set endpoint for thirdparty cloud provider (IDCF) > - > > Key: JCR-3788 > URL: https://issues.apache.org/jira/browse/JCR-3788 > Project: Jackrabbit Content Repository > Issue Type: Improvement > Components: jackrabbit-data >Affects Versions: 2.7.5 >Reporter: Shashank Gupta >Assignee: Chetan Mehrotra > Fix For: 2.7.5 > > Attachments: JCR-3788.patch > > > For IDCF cloud provider API are compatible to AWS S3 SDK. > We can access S3 without any endpoint since S3 API should be designed and > include S3 URL or address so that it can access to S3 if there are not any > endpoint. > However, any address or endpoint needs to be set for 3rd party cloud provider. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (JCR-3786) Incompatible CachingDataStore's path & FileDataStore's path configuration
[
https://issues.apache.org/jira/browse/JCR-3786?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Chetan Mehrotra updated JCR-3786:
-
Resolution: Fixed
Assignee: Chetan Mehrotra
Status: Resolved (was: Patch Available)
Applied the patch in http://svn.apache.org/r1600880
> Incompatible CachingDataStore's path & FileDataStore's path configuration
> --
>
> Key: JCR-3786
> URL: https://issues.apache.org/jira/browse/JCR-3786
> Project: Jackrabbit Content Repository
> Issue Type: Bug
> Components: jackrabbit-data
>Affects Versions: 2.8
>Reporter: Shashank Gupta
>Assignee: Chetan Mehrotra
> Fix For: 2.9
>
> Attachments: JCR-3786.patch
>
>
> 1. FileDataStore#path is location where binaries are stored.
> 2. CachingDatastore assumes binaries are stored in
> {path}/repository/datastore.
> 3. This creates incompatibility between FileDataStore & CachingDatastore
> Workaround is to move files from {path} to {path}/repository/datastore.
> Expectation is that it should work without moving files.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
Re: New Jackrabbit committer: Davide Giannella
Welcome Davide !! Chetan Mehrotra On Wed, Jun 4, 2014 at 6:47 PM, 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
[jira] [Updated] (JCR-3772) Local File cache is not reduced to zero size after specifying in confuguration
[
https://issues.apache.org/jira/browse/JCR-3772?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Chetan Mehrotra updated JCR-3772:
-
Resolution: Fixed
Assignee: Chetan Mehrotra
Status: Resolved (was: Patch Available)
Applied the patch in http://svn.apache.org/r1589926
> Local File cache is not reduced to zero size after specifying in confuguration
> --
>
> Key: JCR-3772
> URL: https://issues.apache.org/jira/browse/JCR-3772
> Project: Jackrabbit Content Repository
> Issue Type: Bug
>Affects Versions: 2.7.5
>Reporter: Shashank Gupta
> Assignee: Chetan Mehrotra
>Priority: Minor
> Fix For: 2.8
>
> Attachments: JCR-3772.patch
>
>
> The local cache size is specified in repository.xml
> {noformat}
>
>
>
>
>
>
>
>
>
>
>
>
> {noformat}
> To disable local cache, {{cacheSize}} is set to 0. Upon setting it to 0 and
> restart, the expectation is that all files in cache would be deleted and
> local cache won't be used in any operation.
> The issue is that local cache is not resetting to 0 size.
> *WorkAround*: set it to 1.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Resolved] (JCR-3771) Pending async uploads fails to get uploaded on restart.
[ https://issues.apache.org/jira/browse/JCR-3771?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chetan Mehrotra resolved JCR-3771. -- Resolution: Fixed Assignee: Chetan Mehrotra Applied the patch in http://svn.apache.org/r1588850 > Pending async uploads fails to get uploaded on restart. > > > Key: JCR-3771 > URL: https://issues.apache.org/jira/browse/JCR-3771 > Project: Jackrabbit Content Repository > Issue Type: Bug > Components: jackrabbit-data >Affects Versions: 2.7.5 >Reporter: Shashank Gupta >Assignee: Chetan Mehrotra >Priority: Critical > Fix For: 2.8 > > Attachments: JCR-3771.patch > > > Steps to reproduce: > # Configure CachingDataStore to use S3Backend > # Upload few large files to repository. Note ongoing uploads in > AysncUploadCache. > # Kill the server > # Start the server. > # The ongoing uploads failed to gets uploaded to S3. > # The expectation is that all ongoing uploads should be synchronously > uploaded to S3 on restart. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (JCR-3754) [jackrabbit-aws-ext] Add retry logic to S3 asynchronous failed upload
[ https://issues.apache.org/jira/browse/JCR-3754?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chetan Mehrotra updated JCR-3754: - Resolution: Fixed Status: Resolved (was: Patch Available) Applied the patch in # http://svn.apache.org/r1585459 # http://svn.apache.org/r1585460 # http://svn.apache.org/r1585461 > [jackrabbit-aws-ext] Add retry logic to S3 asynchronous failed upload > - > > Key: JCR-3754 > URL: https://issues.apache.org/jira/browse/JCR-3754 > Project: Jackrabbit Content Repository > Issue Type: Improvement > Components: jackrabbit-data >Affects Versions: 2.7.5 >Reporter: Shashank Gupta >Assignee: Chetan Mehrotra > Fix For: 2.7.6 > > Attachments: JCR-3754.patch, JCR-3754V2.patch > > > Currently s3 asynchronous uploads are not retried after failure. since > failed upload file is served from local cache it doesn't hamper datastore > functionality. During next restart all accumulated failed upload files are > uploaded to s3 in synchronized manner. > There should be retry logic for failed s3 asynchronous upload so that failed > uploads are not accumulated. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Created] (JCR-3764) Provide an option to disable use of inUseMap in FileDataStore
Chetan Mehrotra created JCR-3764: Summary: Provide an option to disable use of inUseMap in FileDataStore Key: JCR-3764 URL: https://issues.apache.org/jira/browse/JCR-3764 Project: Jackrabbit Content Repository Issue Type: Improvement Components: jackrabbit-data Reporter: Chetan Mehrotra Assignee: Chetan Mehrotra Priority: Minor JR2 FileDataStore#inUseMap [1] is currently a synchronized map and that at times causes contention concurrent env. This map is used for supporting the Blob GC logic for JR2. When used in Oak the GC logic does not rely on isUseMap. So to reduce any overhead FDS should provide an option to disable use of this map [1] https://github.com/apache/jackrabbit/blob/trunk/jackrabbit-data/src/main/java/org/apache/jackrabbit/core/data/FileDataStore.java#L118 -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (JCR-3760) FileDataStore: reduce synchronization
[
https://issues.apache.org/jira/browse/JCR-3760?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Chetan Mehrotra updated JCR-3760:
-
Fix Version/s: 2.7.6
> FileDataStore: reduce synchronization
> -
>
> Key: JCR-3760
> URL: https://issues.apache.org/jira/browse/JCR-3760
> Project: Jackrabbit Content Repository
> Issue Type: Improvement
> Components: jackrabbit-data
>Reporter: Thomas Mueller
>Assignee: Thomas Mueller
> Fix For: 2.7.6
>
>
> The FileDataStore uses the following synchronization:
> synchronized (this) {
> if (!file.exists()) {
> return null;
> }
> ...
> File.exists calls are very slow, it would be better if this check could be
> done outside of the synchronized block. I don't think this would cause any
> issues.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Commented] (JCR-3754) [jackrabbit-aws-ext] Add retry logic to S3 asynchronous failed upload
[
https://issues.apache.org/jira/browse/JCR-3754?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13941445#comment-13941445
]
Chetan Mehrotra commented on JCR-3754:
--
Couple of comments wrt patch
{code:java}
public interface AsyncUploadCallback {
public void call(DataIdentifier identifier, File file, RESULT result,
Map args);
public static String EXCEPTION_ARG = "exceptionArg";
public enum RESULT {
/**
* Asynchronous upload has succeeded.
*/
SUCCESS,
/**
* Asynchronous upload has failed.
*/
FAILED,
/**
* Asynchronous upload has been aborted.
*/
ABORTED
};
}
{code}
* As {{AsyncUploadCallback}} is part of API it needs to be documented better.
What is the purpose of file and identifier and what is callback used for
* Using a generic argument map should be avoided. I would prefer if the
callback is modelled on
[FutureCallback|http://docs.guava-libraries.googlecode.com/git-history/v14.0/javadoc/com/google/common/util/concurrent/FutureCallback.html].
The current impl leads to if-else mode of logic in call. Instead they should
be in different methods
{noformat}
+ */
+protected volatile Map uploadRetryMap =
Collections.synchronizedMap(new HashMap());
{noformat}
Use final instead of volatile
{noformat}
+if (asyncWriteCache.hasEntry(fileName, false)) {
+synchronized (uploadRetryMap) {
+Integer retry = uploadRetryMap.get(identifier);
+if (retry == null) {
+retry = new Integer(1);
+} else {
+retry++;
+}
+if (retry <= uploadRetries) {
+uploadRetryMap.put(identifier, retry);
+LOG.info("Retring [" + retry
++ "] times failed upload for dataidentifer [ "
++ identifier + "]");
+try {
+backend.writeAsync(identifier, file, this);
+} catch (DataStoreException e) {
+
+}
+} else {
+LOG.info("Retries [" + (retry - 1)
++ "] exhausted for dataidentifer [ "
++ identifier + "]");
+uploadRetryMap.remove(identifier);
+}
+}
+}
+} catch (IOException ie) {
+LOG.warn(
+"Cannot retry failed async file upload. Dataidentifer [ "
++ identifier + "], file [" + file.getAbsolutePath()
++ "]", ie);
+}
{noformat}
* DataStoreException getting lost
* Logs should be warning
> [jackrabbit-aws-ext] Add retry logic to S3 asynchronous failed upload
> -
>
> Key: JCR-3754
> URL: https://issues.apache.org/jira/browse/JCR-3754
> Project: Jackrabbit Content Repository
> Issue Type: Improvement
> Components: jackrabbit-data
>Affects Versions: 2.7.5
>Reporter: Shashank Gupta
>Assignee: Chetan Mehrotra
> Fix For: 2.7.6
>
> Attachments: JCR-3754.patch
>
>
> Currently s3 asynchronous uploads are not retried after failure. since
> failed upload file is served from local cache it doesn't hamper datastore
> functionality. During next restart all accumulated failed upload files are
> uploaded to s3 in synchronized manner.
> There should be retry logic for failed s3 asynchronous upload so that failed
> uploads are not accumulated.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Updated] (JCR-3755) Export S3DataStore package to enable osgi resolution
[ https://issues.apache.org/jira/browse/JCR-3755?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chetan Mehrotra updated JCR-3755: - Affects Version/s: 2.7.5 > Export S3DataStore package to enable osgi resolution > > > Key: JCR-3755 > URL: https://issues.apache.org/jira/browse/JCR-3755 > Project: Jackrabbit Content Repository > Issue Type: Improvement > Components: jackrabbit-data >Affects Versions: 2.7.5 >Reporter: Amit Jain >Assignee: Chetan Mehrotra >Priority: Minor > Fix For: 2.7.6 > > Attachments: JCR_3755.patch > > > S3DataStore package org.apache.jackrabbit.ext.ds should be exported from the > bundle so that osgi resolution is possible on bundles depending on this. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (JCR-3755) Export S3DataStore package to enable osgi resolution
[ https://issues.apache.org/jira/browse/JCR-3755?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chetan Mehrotra updated JCR-3755: - Fix Version/s: 2.7.6 > Export S3DataStore package to enable osgi resolution > > > Key: JCR-3755 > URL: https://issues.apache.org/jira/browse/JCR-3755 > Project: Jackrabbit Content Repository > Issue Type: Improvement > Components: jackrabbit-data >Affects Versions: 2.7.5 >Reporter: Amit Jain >Assignee: Chetan Mehrotra >Priority: Minor > Fix For: 2.7.6 > > Attachments: JCR_3755.patch > > > S3DataStore package org.apache.jackrabbit.ext.ds should be exported from the > bundle so that osgi resolution is possible on bundles depending on this. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (JCR-3755) Export S3DataStore package to enable osgi resolution
[ https://issues.apache.org/jira/browse/JCR-3755?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chetan Mehrotra updated JCR-3755: - Resolution: Fixed Status: Resolved (was: Patch Available) Applied a slightly modified patch in 1579543. * slf4j-api is required * DynamicImport-Package instruction was not correct. So fixed that Thanks for patch! > Export S3DataStore package to enable osgi resolution > > > Key: JCR-3755 > URL: https://issues.apache.org/jira/browse/JCR-3755 > Project: Jackrabbit Content Repository > Issue Type: Improvement > Components: jackrabbit-data >Affects Versions: 2.7.5 >Reporter: Amit Jain >Assignee: Chetan Mehrotra >Priority: Minor > Attachments: JCR_3755.patch > > > S3DataStore package org.apache.jackrabbit.ext.ds should be exported from the > bundle so that osgi resolution is possible on bundles depending on this. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Assigned] (JCR-3754) [jackrabbit-aws-ext] Add retry logic to S3 asynchronous failed upload
[ https://issues.apache.org/jira/browse/JCR-3754?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chetan Mehrotra reassigned JCR-3754: Assignee: Chetan Mehrotra > [jackrabbit-aws-ext] Add retry logic to S3 asynchronous failed upload > - > > Key: JCR-3754 > URL: https://issues.apache.org/jira/browse/JCR-3754 > Project: Jackrabbit Content Repository > Issue Type: Improvement > Components: jackrabbit-data >Affects Versions: 2.7.5 >Reporter: Shashank Gupta >Assignee: Chetan Mehrotra > Fix For: 2.7.6 > > Attachments: JCR-3754.patch > > > Currently s3 asynchronous uploads are not retried after failure. since > failed upload file is served from local cache it doesn't hamper datastore > functionality. During next restart all accumulated failed upload files are > uploaded to s3 in synchronized manner. > There should be retry logic for failed s3 asynchronous upload so that failed > uploads are not accumulated. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Assigned] (JCR-3755) Export S3DataStore package to enable osgi resolution
[ https://issues.apache.org/jira/browse/JCR-3755?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chetan Mehrotra reassigned JCR-3755: Assignee: Chetan Mehrotra > Export S3DataStore package to enable osgi resolution > > > Key: JCR-3755 > URL: https://issues.apache.org/jira/browse/JCR-3755 > Project: Jackrabbit Content Repository > Issue Type: Improvement > Components: jackrabbit-data >Reporter: Amit Jain > Assignee: Chetan Mehrotra >Priority: Minor > Attachments: JCR_3755.patch > > > S3DataStore package org.apache.jackrabbit.ext.ds should be exported from the > bundle so that osgi resolution is possible on bundles depending on this. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Assigned] (JCR-3752) [jackrabbit-aws-ext] Upgrade to latest aws sdk version ( 1.7.3)
[ https://issues.apache.org/jira/browse/JCR-3752?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chetan Mehrotra reassigned JCR-3752: Assignee: Chetan Mehrotra > [jackrabbit-aws-ext] Upgrade to latest aws sdk version ( 1.7.3) > --- > > Key: JCR-3752 > URL: https://issues.apache.org/jira/browse/JCR-3752 > Project: Jackrabbit Content Repository > Issue Type: Improvement > Components: jackrabbit-data >Affects Versions: 2.7.5 >Reporter: Shashank Gupta >Assignee: Chetan Mehrotra > Fix For: 2.7.6 > > Attachments: JCR-3752.patch > > -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (JCR-3752) [jackrabbit-aws-ext] Upgrade to latest aws sdk version ( 1.7.3)
[ https://issues.apache.org/jira/browse/JCR-3752?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chetan Mehrotra updated JCR-3752: - Resolution: Fixed Status: Resolved (was: Patch Available) Applied the patch in [r1579119|http://svn.apache.org/r1579119] > [jackrabbit-aws-ext] Upgrade to latest aws sdk version ( 1.7.3) > --- > > Key: JCR-3752 > URL: https://issues.apache.org/jira/browse/JCR-3752 > Project: Jackrabbit Content Repository > Issue Type: Improvement > Components: jackrabbit-data >Affects Versions: 2.7.5 >Reporter: Shashank Gupta >Assignee: Chetan Mehrotra > Fix For: 2.7.6 > > Attachments: JCR-3752.patch > > -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (JCR-3751) S3Backend fails to initializate from file system based configuration file
[ https://issues.apache.org/jira/browse/JCR-3751?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chetan Mehrotra updated JCR-3751: - Resolution: Fixed Status: Resolved (was: Patch Available) My fault as the regression was introduced with fix for JCR-3748. Thanks for the patch. Fixed in http://svn.apache.org/r1578774 > S3Backend fails to initializate from file system based configuration file > -- > > Key: JCR-3751 > URL: https://issues.apache.org/jira/browse/JCR-3751 > Project: Jackrabbit Content Repository > Issue Type: Bug > Components: jackrabbit-data >Affects Versions: 2.7.5 >Reporter: Shashank Gupta >Assignee: Chetan Mehrotra > Fix For: 2.7.6 > > Attachments: JCR-3751.patch > > -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (JCR-3751) S3Backend fails to initializate from file system based configuration file
[ https://issues.apache.org/jira/browse/JCR-3751?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chetan Mehrotra updated JCR-3751: - Labels: (was: regr) > S3Backend fails to initializate from file system based configuration file > -- > > Key: JCR-3751 > URL: https://issues.apache.org/jira/browse/JCR-3751 > Project: Jackrabbit Content Repository > Issue Type: Bug > Components: jackrabbit-data >Affects Versions: 2.7.5 >Reporter: Shashank Gupta >Assignee: Chetan Mehrotra > Fix For: 2.7.6 > > Attachments: JCR-3751.patch > > -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (JCR-3751) S3Backend fails to initializate from file system based configuration file
[ https://issues.apache.org/jira/browse/JCR-3751?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chetan Mehrotra updated JCR-3751: - Labels: regr (was: ) > S3Backend fails to initializate from file system based configuration file > -- > > Key: JCR-3751 > URL: https://issues.apache.org/jira/browse/JCR-3751 > Project: Jackrabbit Content Repository > Issue Type: Bug > Components: jackrabbit-data >Affects Versions: 2.7.5 >Reporter: Shashank Gupta >Assignee: Chetan Mehrotra > Labels: regr > Fix For: 2.7.6 > > Attachments: JCR-3751.patch > > -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Assigned] (JCR-3751) S3Backend fails to initializate from file system based configuration file
[ https://issues.apache.org/jira/browse/JCR-3751?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chetan Mehrotra reassigned JCR-3751: Assignee: Chetan Mehrotra > S3Backend fails to initializate from file system based configuration file > -- > > Key: JCR-3751 > URL: https://issues.apache.org/jira/browse/JCR-3751 > Project: Jackrabbit Content Repository > Issue Type: Bug > Components: jackrabbit-data >Affects Versions: 2.7.5 >Reporter: Shashank Gupta >Assignee: Chetan Mehrotra > Fix For: 2.7.6 > > Attachments: JCR-3751.patch > > -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Resolved] (JCR-3748) Allow configuring S3Backend programatically
[ https://issues.apache.org/jira/browse/JCR-3748?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chetan Mehrotra resolved JCR-3748. -- Resolution: Fixed Fix Version/s: 2.7.5 Added support in http://svn.apache.org/r1577481 > Allow configuring S3Backend programatically > --- > > Key: JCR-3748 > URL: https://issues.apache.org/jira/browse/JCR-3748 > Project: Jackrabbit Content Repository > Issue Type: Improvement > Components: jackrabbit-data > Reporter: Chetan Mehrotra > Assignee: Chetan Mehrotra >Priority: Minor > Fix For: 2.7.5 > > > S3Backend currently initializes itself via path to a property file. To > simplify configuration in other env it would be better if it can take a > properties object also as part of init params -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (JCR-3748) Allow configuring S3Backend programatically
[ https://issues.apache.org/jira/browse/JCR-3748?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chetan Mehrotra updated JCR-3748: - Component/s: (was: jackrabbit-core) > Allow configuring S3Backend programatically > --- > > Key: JCR-3748 > URL: https://issues.apache.org/jira/browse/JCR-3748 > Project: Jackrabbit Content Repository > Issue Type: Improvement > Components: jackrabbit-data > Reporter: Chetan Mehrotra > Assignee: Chetan Mehrotra >Priority: Minor > > S3Backend currently initializes itself via path to a property file. To > simplify configuration in other env it would be better if it can take a > properties object also as part of init params -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (JCR-3748) Allow configuring S3Backend programatically
[ https://issues.apache.org/jira/browse/JCR-3748?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chetan Mehrotra updated JCR-3748: - Component/s: jackrabbit-data > Allow configuring S3Backend programatically > --- > > Key: JCR-3748 > URL: https://issues.apache.org/jira/browse/JCR-3748 > Project: Jackrabbit Content Repository > Issue Type: Improvement > Components: jackrabbit-data > Reporter: Chetan Mehrotra > Assignee: Chetan Mehrotra >Priority: Minor > > S3Backend currently initializes itself via path to a property file. To > simplify configuration in other env it would be better if it can take a > properties object also as part of init params -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Moved] (JCR-3748) Allow confiruing S3Backend programatically
[ https://issues.apache.org/jira/browse/JCR-3748?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chetan Mehrotra moved OAK-1542 to JCR-3748: --- Component/s: (was: core) Workflow: no-reopen-closed, patch-avail (was: no-reopen-closed) Key: JCR-3748 (was: OAK-1542) Project: Jackrabbit Content Repository (was: Jackrabbit Oak) > Allow confiruing S3Backend programatically > -- > > Key: JCR-3748 > URL: https://issues.apache.org/jira/browse/JCR-3748 > Project: Jackrabbit Content Repository > Issue Type: Improvement > Reporter: Chetan Mehrotra > Assignee: Chetan Mehrotra >Priority: Minor > > S3Backend currently initializes itself via path to a property file. To > simplify configuration in other env it would be better if it can take a > properties object also as part of init params -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (JCR-3748) Allow configuring S3Backend programatically
[ https://issues.apache.org/jira/browse/JCR-3748?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chetan Mehrotra updated JCR-3748: - Summary: Allow configuring S3Backend programatically (was: Allow confiruing S3Backend programatically) > Allow configuring S3Backend programatically > --- > > Key: JCR-3748 > URL: https://issues.apache.org/jira/browse/JCR-3748 > Project: Jackrabbit Content Repository > Issue Type: Improvement > Components: jackrabbit-core > Reporter: Chetan Mehrotra > Assignee: Chetan Mehrotra >Priority: Minor > > S3Backend currently initializes itself via path to a property file. To > simplify configuration in other env it would be better if it can take a > properties object also as part of init params -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (JCR-3748) Allow configuring S3Backend programatically
[ https://issues.apache.org/jira/browse/JCR-3748?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chetan Mehrotra updated JCR-3748: - Component/s: jackrabbit-core > Allow configuring S3Backend programatically > --- > > Key: JCR-3748 > URL: https://issues.apache.org/jira/browse/JCR-3748 > Project: Jackrabbit Content Repository > Issue Type: Improvement > Components: jackrabbit-core > Reporter: Chetan Mehrotra > Assignee: Chetan Mehrotra >Priority: Minor > > S3Backend currently initializes itself via path to a property file. To > simplify configuration in other env it would be better if it can take a > properties object also as part of init params -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (JCR-3742) Have DB related dependencies as optional in jackrabbit-data
[ https://issues.apache.org/jira/browse/JCR-3742?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chetan Mehrotra updated JCR-3742: - Fix Version/s: 2.7.5 > Have DB related dependencies as optional in jackrabbit-data > --- > > Key: JCR-3742 > URL: https://issues.apache.org/jira/browse/JCR-3742 > Project: Jackrabbit Content Repository > Issue Type: Improvement >Affects Versions: 2.7.4 >Reporter: Amit Jain > Assignee: Chetan Mehrotra > Fix For: 2.7.5 > > Attachments: JCR-3742.patch > > > Mark commons-dbcp as optional dependency in jackrabbit-data. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (JCR-3742) Have DB related dependencies as optional in jackrabbit-data
[ https://issues.apache.org/jira/browse/JCR-3742?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chetan Mehrotra updated JCR-3742: - Resolution: Fixed Status: Resolved (was: Patch Available) Applied slightly modified patch in http://svn.apache.org/r1577422. Thanks Amit! > Have DB related dependencies as optional in jackrabbit-data > --- > > Key: JCR-3742 > URL: https://issues.apache.org/jira/browse/JCR-3742 > Project: Jackrabbit Content Repository > Issue Type: Improvement >Affects Versions: 2.7.4 >Reporter: Amit Jain > Assignee: Chetan Mehrotra > Attachments: JCR-3742.patch > > > Mark commons-dbcp as optional dependency in jackrabbit-data. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Assigned] (JCR-3742) Have DB related dependencies as optional in jackrabbit-data
[ https://issues.apache.org/jira/browse/JCR-3742?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chetan Mehrotra reassigned JCR-3742: Assignee: Chetan Mehrotra > Have DB related dependencies as optional in jackrabbit-data > --- > > Key: JCR-3742 > URL: https://issues.apache.org/jira/browse/JCR-3742 > Project: Jackrabbit Content Repository > Issue Type: Improvement >Affects Versions: 2.7.4 >Reporter: Amit Jain > Assignee: Chetan Mehrotra > Attachments: JCR-3742.patch > > > Mark commons-dbcp as optional dependency in jackrabbit-data. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (JCR-3737) ConnectionHelper eating up original exception in execute
[
https://issues.apache.org/jira/browse/JCR-3737?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13915533#comment-13915533
]
Chetan Mehrotra commented on JCR-3737:
--
Looking at the code not sure on the fix
# Pass the original exception as part of RuntimeException
# OR Implement support for STORE_TEMP_FILE in Journal also and create
TempFileInputStream from the InputStream as done in DbDataStore. Such that on
retry the binary is used properly
> ConnectionHelper eating up original exception in execute
>
>
> Key: JCR-3737
> URL: https://issues.apache.org/jira/browse/JCR-3737
> Project: Jackrabbit Content Repository
> Issue Type: Bug
> Components: jackrabbit-core
>Affects Versions: 2.7.4
> Reporter: Chetan Mehrotra
>Priority: Minor
>
> While inserting blob the ConnectionHelper tries to reset the InputStream [1]
> {code:java}
> } catch (SQLException e) {
> //Reset Stream for retry ...
> for (int i = 0; params != null && i < params.length; i++) {
> Object p = params[i];
> if (p instanceof StreamWrapper) {
> StreamWrapper wrapper = (StreamWrapper) p;
> if(!wrapper.resetStream()) {
> wrapper.cleanupResources();
> throw new RuntimeException("Unable to reset the
> Stream.");
> }
> }
> }
> throw e;
> }
> {code}
> In above code flow if there is an issue in resetting the StreamWrapper then
> original exception would be lost.
> [1]
> https://github.com/apache/jackrabbit/blob/trunk/jackrabbit-data/src/main/java/org/apache/jackrabbit/core/util/db/ConnectionHelper.java#L519
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
[jira] [Created] (JCR-3737) ConnectionHelper eating up original exception in execute
Chetan Mehrotra created JCR-3737:
Summary: ConnectionHelper eating up original exception in execute
Key: JCR-3737
URL: https://issues.apache.org/jira/browse/JCR-3737
Project: Jackrabbit Content Repository
Issue Type: Bug
Components: jackrabbit-core
Affects Versions: 2.7.4
Reporter: Chetan Mehrotra
Priority: Minor
While inserting blob the ConnectionHelper tries to reset the InputStream [1]
{code:java}
} catch (SQLException e) {
//Reset Stream for retry ...
for (int i = 0; params != null && i < params.length; i++) {
Object p = params[i];
if (p instanceof StreamWrapper) {
StreamWrapper wrapper = (StreamWrapper) p;
if(!wrapper.resetStream()) {
wrapper.cleanupResources();
throw new RuntimeException("Unable to reset the Stream.");
}
}
}
throw e;
}
{code}
In above code flow if there is an issue in resetting the StreamWrapper then
original exception would be lost.
[1]
https://github.com/apache/jackrabbit/blob/trunk/jackrabbit-data/src/main/java/org/apache/jackrabbit/core/util/db/ConnectionHelper.java#L519
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
[jira] [Updated] (JCR-3629) [jcr2spi]RepositoryException lost in org.apache.jackrabbit.jcr2spi.ItemManagerImpl while querying on remote nodes exposed by jackrabbit-spi
[
https://issues.apache.org/jira/browse/JCR-3629?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Chetan Mehrotra updated JCR-3629:
-
Fix Version/s: 2.1.7
> [jcr2spi]RepositoryException lost in
> org.apache.jackrabbit.jcr2spi.ItemManagerImpl while querying on remote nodes
> exposed by jackrabbit-spi
> ---
>
> Key: JCR-3629
> URL: https://issues.apache.org/jira/browse/JCR-3629
> Project: Jackrabbit Content Repository
> Issue Type: Bug
> Components: jackrabbit-jcr2spi
>Affects Versions: 2.5.3
>Reporter: Abhinav Atul
>Assignee: Chetan Mehrotra
> Fix For: 2.1.7, 2.7.1
>
> Attachments: JCR-3629.patch
>
>
> RepositoryException lost in ItemManagerImpl#nodeExists,
> ItemManagerImpl#itemExists(HierarchyEntry), ItemManagerImpl#propertyExists,
> ItemManagerImpl#itemExists(ItemState)
> /**
> * @see ItemManager#nodeExists(Path)
> */
> public boolean nodeExists(Path path) {
> try {
> // session-sanity & permissions are checked upon
> itemExists(ItemState)
> NodeState nodeState = hierMgr.getNodeState(path);
> return itemExists(nodeState);
> } catch (PathNotFoundException pnfe) {
> return false;
> } catch (ItemNotFoundException infe) {
> return false;
> } catch (RepositoryException re) {
> return false;
> }
> }
> The catch block for RepositoryException should probably wrap the exception as
> a RuntimeException as it might happen for unknown reason.
> Changing this might break backward compatibility.
> The issue was detected when trying to implement a synchronization service
> with a content repository exposed by a jackrabbit-spi implementation. If the
> content repository becomes non-responsive while checking whether a node
> exists or not, the RepositoryException is lost in ItemManager#nodeExists
> resulting in deletion of the local node corresponding to the remote node.
--
This message was sent by Atlassian JIRA
(v6.1.4#6159)
[jira] [Commented] (JCR-3629) [jcr2spi]RepositoryException lost in org.apache.jackrabbit.jcr2spi.ItemManagerImpl while querying on remote nodes exposed by jackrabbit-spi
[
https://issues.apache.org/jira/browse/JCR-3629?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13847461#comment-13847461
]
Chetan Mehrotra commented on JCR-3629:
--
Fixed in 2.1.7 with revision 1550719.
> [jcr2spi]RepositoryException lost in
> org.apache.jackrabbit.jcr2spi.ItemManagerImpl while querying on remote nodes
> exposed by jackrabbit-spi
> ---
>
> Key: JCR-3629
> URL: https://issues.apache.org/jira/browse/JCR-3629
> Project: Jackrabbit Content Repository
> Issue Type: Bug
> Components: jackrabbit-jcr2spi
>Affects Versions: 2.5.3
>Reporter: Abhinav Atul
>Assignee: Chetan Mehrotra
> Fix For: 2.1.7, 2.7.1
>
> Attachments: JCR-3629.patch
>
>
> RepositoryException lost in ItemManagerImpl#nodeExists,
> ItemManagerImpl#itemExists(HierarchyEntry), ItemManagerImpl#propertyExists,
> ItemManagerImpl#itemExists(ItemState)
> /**
> * @see ItemManager#nodeExists(Path)
> */
> public boolean nodeExists(Path path) {
> try {
> // session-sanity & permissions are checked upon
> itemExists(ItemState)
> NodeState nodeState = hierMgr.getNodeState(path);
> return itemExists(nodeState);
> } catch (PathNotFoundException pnfe) {
> return false;
> } catch (ItemNotFoundException infe) {
> return false;
> } catch (RepositoryException re) {
> return false;
> }
> }
> The catch block for RepositoryException should probably wrap the exception as
> a RuntimeException as it might happen for unknown reason.
> Changing this might break backward compatibility.
> The issue was detected when trying to implement a synchronization service
> with a content repository exposed by a jackrabbit-spi implementation. If the
> content repository becomes non-responsive while checking whether a node
> exists or not, the RepositoryException is lost in ItemManager#nodeExists
> resulting in deletion of the local node corresponding to the remote node.
--
This message was sent by Atlassian JIRA
(v6.1.4#6159)
[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=13838569#comment-13838569
]
Chetan Mehrotra commented on JCR-3705:
--
+1 for making it part of API
bq. (the DataStore API is in jackrabbit-api, but I assume oak depends on that
anyway)
It falls under {{org.apache.jackrabbit.core}} package and is not part of API
module [1]. Having a new component jackrabbit-data would enable moving all the
common stuff like CachingDataStore [2] and MultiDataStore at one place and can
then be used in Oak
[1] https://svn.apache.org/repos/asf/jackrabbit/trunk/jackrabbit-api/
[2]
https://svn.apache.org/repos/asf/jackrabbit/trunk/jackrabbit-aws-ext/src/main/java/org/apache/jackrabbit/aws/ext/ds/CachingDataStore.java
> 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] [Resolved] (JCR-3629) [jcr2spi]RepositoryException lost in org.apache.jackrabbit.jcr2spi.ItemManagerImpl while querying on remote nodes exposed by jackrabbit-spi
[
https://issues.apache.org/jira/browse/JCR-3629?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Chetan Mehrotra resolved JCR-3629.
--
Resolution: Fixed
Assignee: Chetan Mehrotra
Checked in modified patch at revision 1507190. All relevant testcases passed
> [jcr2spi]RepositoryException lost in
> org.apache.jackrabbit.jcr2spi.ItemManagerImpl while querying on remote nodes
> exposed by jackrabbit-spi
> ---
>
> Key: JCR-3629
> URL: https://issues.apache.org/jira/browse/JCR-3629
> Project: Jackrabbit Content Repository
> Issue Type: Bug
> Components: jackrabbit-jcr2spi
>Affects Versions: 2.5.3
>Reporter: Abhinav Atul
>Assignee: Chetan Mehrotra
> Attachments: JCR-3629.patch
>
>
> RepositoryException lost in ItemManagerImpl#nodeExists,
> ItemManagerImpl#itemExists(HierarchyEntry), ItemManagerImpl#propertyExists,
> ItemManagerImpl#itemExists(ItemState)
> /**
> * @see ItemManager#nodeExists(Path)
> */
> public boolean nodeExists(Path path) {
> try {
> // session-sanity & permissions are checked upon
> itemExists(ItemState)
> NodeState nodeState = hierMgr.getNodeState(path);
> return itemExists(nodeState);
> } catch (PathNotFoundException pnfe) {
> return false;
> } catch (ItemNotFoundException infe) {
> return false;
> } catch (RepositoryException re) {
> return false;
> }
> }
> The catch block for RepositoryException should probably wrap the exception as
> a RuntimeException as it might happen for unknown reason.
> Changing this might break backward compatibility.
> The issue was detected when trying to implement a synchronization service
> with a content repository exposed by a jackrabbit-spi implementation. If the
> content repository becomes non-responsive while checking whether a node
> exists or not, the RepositoryException is lost in ItemManager#nodeExists
> resulting in deletion of the local node corresponding to the remote node.
--
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-3629) [jcr2spi]RepositoryException lost in org.apache.jackrabbit.jcr2spi.ItemManagerImpl while querying on remote nodes exposed by jackrabbit-spi
[
https://issues.apache.org/jira/browse/JCR-3629?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13719588#comment-13719588
]
Chetan Mehrotra commented on JCR-3629:
--
>jcr2spi doesn't run any test. please run a complete build of all of jackrabbit
>with -PintegrationTesting. this will run all tests for all jcr2spi -
>spi2something setup scenarios present in jackrabbit core including the
>jcr-remoting.
Did not realized that. Would run test from the top.
>regarding public and non-public API: you kept struggling with that distinction
>in the past when adding functionality to sling that used internal, non-public
>API.
it's very simple: everything in jackrabbit-api and jackrabbit-spi is public API
everything else is internal API and may change any time.
Got it. Would follow that as a thumb rule!!
> [jcr2spi]RepositoryException lost in
> org.apache.jackrabbit.jcr2spi.ItemManagerImpl while querying on remote nodes
> exposed by jackrabbit-spi
> ---
>
> Key: JCR-3629
> URL: https://issues.apache.org/jira/browse/JCR-3629
> Project: Jackrabbit Content Repository
> Issue Type: Bug
> Components: jackrabbit-jcr2spi
>Affects Versions: 2.5.3
>Reporter: Abhinav Atul
> Attachments: JCR-3629.patch
>
>
> RepositoryException lost in ItemManagerImpl#nodeExists,
> ItemManagerImpl#itemExists(HierarchyEntry), ItemManagerImpl#propertyExists,
> ItemManagerImpl#itemExists(ItemState)
> /**
> * @see ItemManager#nodeExists(Path)
> */
> public boolean nodeExists(Path path) {
> try {
> // session-sanity & permissions are checked upon
> itemExists(ItemState)
> NodeState nodeState = hierMgr.getNodeState(path);
> return itemExists(nodeState);
> } catch (PathNotFoundException pnfe) {
> return false;
> } catch (ItemNotFoundException infe) {
> return false;
> } catch (RepositoryException re) {
> return false;
> }
> }
> The catch block for RepositoryException should probably wrap the exception as
> a RuntimeException as it might happen for unknown reason.
> Changing this might break backward compatibility.
> The issue was detected when trying to implement a synchronization service
> with a content repository exposed by a jackrabbit-spi implementation. If the
> content repository becomes non-responsive while checking whether a node
> exists or not, the RepositoryException is lost in ItemManager#nodeExists
> resulting in deletion of the local node corresponding to the remote node.
--
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-3629) [jcr2spi]RepositoryException lost in org.apache.jackrabbit.jcr2spi.ItemManagerImpl while querying on remote nodes exposed by jackrabbit-spi
[
https://issues.apache.org/jira/browse/JCR-3629?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13719574#comment-13719574
]
Chetan Mehrotra commented on JCR-3629:
--
Tried doing that but still no test run. There are no test with name *IT either
> [jcr2spi]RepositoryException lost in
> org.apache.jackrabbit.jcr2spi.ItemManagerImpl while querying on remote nodes
> exposed by jackrabbit-spi
> ---
>
> Key: JCR-3629
> URL: https://issues.apache.org/jira/browse/JCR-3629
> Project: Jackrabbit Content Repository
> Issue Type: Bug
> Components: jackrabbit-jcr2spi
>Affects Versions: 2.5.3
>Reporter: Abhinav Atul
> Attachments: JCR-3629.patch
>
>
> RepositoryException lost in ItemManagerImpl#nodeExists,
> ItemManagerImpl#itemExists(HierarchyEntry), ItemManagerImpl#propertyExists,
> ItemManagerImpl#itemExists(ItemState)
> /**
> * @see ItemManager#nodeExists(Path)
> */
> public boolean nodeExists(Path path) {
> try {
> // session-sanity & permissions are checked upon
> itemExists(ItemState)
> NodeState nodeState = hierMgr.getNodeState(path);
> return itemExists(nodeState);
> } catch (PathNotFoundException pnfe) {
> return false;
> } catch (ItemNotFoundException infe) {
> return false;
> } catch (RepositoryException re) {
> return false;
> }
> }
> The catch block for RepositoryException should probably wrap the exception as
> a RuntimeException as it might happen for unknown reason.
> Changing this might break backward compatibility.
> The issue was detected when trying to implement a synchronization service
> with a content repository exposed by a jackrabbit-spi implementation. If the
> content repository becomes non-responsive while checking whether a node
> exists or not, the RepositoryException is lost in ItemManager#nodeExists
> resulting in deletion of the local node corresponding to the remote node.
--
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] [Resolved] (JCR-3628) Embed cause in org.apache.jackrabbit.core.SessionImpl#getNodeByIdentifier while rethrowing IllegalArgumentException
[
https://issues.apache.org/jira/browse/JCR-3628?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Chetan Mehrotra resolved JCR-3628.
--
Resolution: Fixed
Assignee: Chetan Mehrotra
> Embed cause in org.apache.jackrabbit.core.SessionImpl#getNodeByIdentifier
> while rethrowing IllegalArgumentException
> ---
>
> Key: JCR-3628
> URL: https://issues.apache.org/jira/browse/JCR-3628
> Project: Jackrabbit Content Repository
> Issue Type: Improvement
> Components: jackrabbit-core
>Affects Versions: 2.5.3
>Reporter: Abhinav Atul
> Assignee: Chetan Mehrotra
>Priority: Minor
>
> This is needed for reasonable exception handling. The below is the
> changelist(org.apache.jackrabbit.core.SessionImpl#getNodeByIdentifier ):
> } catch (IllegalArgumentException iae) {
> -throw new RepositoryException("invalid identifier: " + id);
> +throw new RepositoryException("invalid identifier: " + id,iae);
> }
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (JCR-3628) Embed cause in org.apache.jackrabbit.core.SessionImpl#getNodeByIdentifier while rethrowing IllegalArgumentException
[
https://issues.apache.org/jira/browse/JCR-3628?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Chetan Mehrotra updated JCR-3628:
-
Priority: Minor (was: Major)
> Embed cause in org.apache.jackrabbit.core.SessionImpl#getNodeByIdentifier
> while rethrowing IllegalArgumentException
> ---
>
> Key: JCR-3628
> URL: https://issues.apache.org/jira/browse/JCR-3628
> Project: Jackrabbit Content Repository
> Issue Type: Improvement
> Components: jackrabbit-core
>Affects Versions: 2.5.3
>Reporter: Abhinav Atul
>Priority: Minor
>
> This is needed for reasonable exception handling. The below is the
> changelist(org.apache.jackrabbit.core.SessionImpl#getNodeByIdentifier ):
> } catch (IllegalArgumentException iae) {
> -throw new RepositoryException("invalid identifier: " + id);
> +throw new RepositoryException("invalid identifier: " + id,iae);
> }
--
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-3628) Embed cause in org.apache.jackrabbit.core.SessionImpl#getNodeByIdentifier while rethrowing IllegalArgumentException
[
https://issues.apache.org/jira/browse/JCR-3628?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13719488#comment-13719488
]
Chetan Mehrotra commented on JCR-3628:
--
Fixed in trunk with revision 1506877
> Embed cause in org.apache.jackrabbit.core.SessionImpl#getNodeByIdentifier
> while rethrowing IllegalArgumentException
> ---
>
> Key: JCR-3628
> URL: https://issues.apache.org/jira/browse/JCR-3628
> Project: Jackrabbit Content Repository
> Issue Type: Improvement
> Components: jackrabbit-core
>Affects Versions: 2.5.3
>Reporter: Abhinav Atul
>
> This is needed for reasonable exception handling. The below is the
> changelist(org.apache.jackrabbit.core.SessionImpl#getNodeByIdentifier ):
> } catch (IllegalArgumentException iae) {
> -throw new RepositoryException("invalid identifier: " + id);
> +throw new RepositoryException("invalid identifier: " + id,iae);
> }
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (JCR-3629) [jcr2spi]RepositoryException lost in org.apache.jackrabbit.jcr2spi.ItemManagerImpl while querying on remote nodes exposed by jackrabbit-spi
[
https://issues.apache.org/jira/browse/JCR-3629?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Chetan Mehrotra updated JCR-3629:
-
Attachment: JCR-3629.patch
Patch (for current trunk code) which enables propagation of RepositoryException
Tried to run the testcases in the jackrabbit-jcr2spi but was unsuccessful. The
maven-surefire-plugin excludes all the testcases and only some of the testcase
which extend the AbstractJCR2SPITest can be run. Rest all fail to run as
corresponding RepositoryStubImpl for jcr2spi is missing
> [jcr2spi]RepositoryException lost in
> org.apache.jackrabbit.jcr2spi.ItemManagerImpl while querying on remote nodes
> exposed by jackrabbit-spi
> ---
>
> Key: JCR-3629
> URL: https://issues.apache.org/jira/browse/JCR-3629
> Project: Jackrabbit Content Repository
> Issue Type: Bug
> Components: jackrabbit-jcr2spi
>Affects Versions: 2.5.3
>Reporter: Abhinav Atul
> Attachments: JCR-3629.patch
>
>
> RepositoryException lost in ItemManagerImpl#nodeExists,
> ItemManagerImpl#itemExists(HierarchyEntry), ItemManagerImpl#propertyExists,
> ItemManagerImpl#itemExists(ItemState)
> /**
> * @see ItemManager#nodeExists(Path)
> */
> public boolean nodeExists(Path path) {
> try {
> // session-sanity & permissions are checked upon
> itemExists(ItemState)
> NodeState nodeState = hierMgr.getNodeState(path);
> return itemExists(nodeState);
> } catch (PathNotFoundException pnfe) {
> return false;
> } catch (ItemNotFoundException infe) {
> return false;
> } catch (RepositoryException re) {
> return false;
> }
> }
> The catch block for RepositoryException should probably wrap the exception as
> a RuntimeException as it might happen for unknown reason.
> Changing this might break backward compatibility.
> The issue was detected when trying to implement a synchronization service
> with a content repository exposed by a jackrabbit-spi implementation. If the
> content repository becomes non-responsive while checking whether a node
> exists or not, the RepositoryException is lost in ItemManager#nodeExists
> resulting in deletion of the local node corresponding to the remote node.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: [jcr2spi] RepositoryException lost in ItemManager#nodeExists
On Thu, Jul 25, 2013 at 1:39 PM, Angela Schreiber wrote: > the ItemManager is an internal interface which can be changed. Ah ... did not realized that its an internal interface. Fine then we can change its method signature to throw RepositoryException. Makes sense Chetan Mehrotra
Re: [jcr2spi] RepositoryException lost in ItemManager#nodeExists
Also looking at org.apache.jackrabbit.jcr2spi.ItemManager [1] the
method signature for nodeExists, itemExists and propertyExists should
have thrown RepositoryException just like other methods of the
interface. But that not the case :( And changing that now is not an
option
So best way to move forward would be to wrap it in RuntimeException
[1]
https://github.com/apache/jackrabbit/blob/trunk/jackrabbit-jcr2spi/src/main/java/org/apache/jackrabbit/jcr2spi/ItemManager.java
Chetan Mehrotra
On Thu, Jul 25, 2013 at 1:16 PM, Chetan Mehrotra
wrote:
> Hi Angela,
>
> But then returning false gives a wrong indication to the caller that
> node/item does not exist and then it would cause issues in the
> business logic implemented on top of that. So exception has to be
> propagated upward. Now as method signature does not have the
> RepositoryException then probably have to wrap it in some
> RuntimeException.
>
> Chetan Mehrotra
>
>
> On Thu, Jul 25, 2013 at 1:09 PM, Angela Schreiber wrote:
>> hi chetan
>>
>> i wouldn't do that as we generally avoid runtimeexceptions in jackrabbit.
>> instead i would log an error.
>>
>>
>> angela
>>
>> On 7/24/13 3:01 PM, "Chetan Mehrotra" wrote:
>>
>>>Looking at the code [1]
>>>
>>>/**
>>> * @see ItemManager#nodeExists(Path)
>>> */
>>>public boolean nodeExists(Path path) {
>>>try {
>>>// session-sanity & permissions are checked upon
>>>itemExists(ItemState)
>>>NodeState nodeState = hierMgr.getNodeState(path);
>>>return itemExists(nodeState);
>>>} catch (PathNotFoundException pnfe) {
>>>return false;
>>>} catch (ItemNotFoundException infe) {
>>>return false;
>>>} catch (RepositoryException re) {
>>>return false;
>>>}
>>>}
>>>
>>>The catch block for RepositoryException should probably wrap the
>>>exception as a RuntimeException as it might happen for unknown reason.
>>>Changing this might break backward compatibility. Would it be fine to
>>>do that?
>>>
>>>@abhinav - Can you open a bug for this?
>>>
>>>[1]
>>>https://github.com/apache/jackrabbit/blob/trunk/jackrabbit-jcr2spi/src/mai
>>>n/java/org/apache/jackrabbit/jcr2spi/ItemManagerImpl.java#L115
>>>Chetan Mehrotra
>>>
>>>
>>>On Tue, Jul 23, 2013 at 7:42 PM, Abhinav Atul wrote:
>>>> Just in case if this would be the right place to find a solution.
>>>>Please let me know if anything is unclear.
>>>>
>>>> Thanks
>>>> Abhinav
>>>>
>>>> -Original Message-
>>>> From: Abhinav Atul [mailto:aa...@adobe.com]
>>>> Sent: 22 July 2013 14:58
>>>> To: Jackrabbit Users
>>>> Subject: [jcr2spi] RepositoryException lost in ItemManager#nodeExists
>>>>
>>>> Hi,
>>>> I am trying to implement a synchronization service
>>>>using the jcr connector for Documentum. The issue I am facing is if the
>>>>Documentum server becomes non-responsive while trying to check if a node
>>>>has been updated or deleted at Documentum, the RepositoryException is
>>>>lost in ItemManagerImpl#nodeExists and the synchronization service is
>>>>communicated that the node does not exists which may not be the case.
>>>>Could the RepositoryException be communicated further?
>>>>
>>>> Thanks
>>>> Abhinav
>>>>
>>
Re: [jcr2spi] RepositoryException lost in ItemManager#nodeExists
Hi Angela,
But then returning false gives a wrong indication to the caller that
node/item does not exist and then it would cause issues in the
business logic implemented on top of that. So exception has to be
propagated upward. Now as method signature does not have the
RepositoryException then probably have to wrap it in some
RuntimeException.
Chetan Mehrotra
On Thu, Jul 25, 2013 at 1:09 PM, Angela Schreiber wrote:
> hi chetan
>
> i wouldn't do that as we generally avoid runtimeexceptions in jackrabbit.
> instead i would log an error.
>
>
> angela
>
> On 7/24/13 3:01 PM, "Chetan Mehrotra" wrote:
>
>>Looking at the code [1]
>>
>>/**
>> * @see ItemManager#nodeExists(Path)
>> */
>>public boolean nodeExists(Path path) {
>>try {
>>// session-sanity & permissions are checked upon
>>itemExists(ItemState)
>>NodeState nodeState = hierMgr.getNodeState(path);
>>return itemExists(nodeState);
>>} catch (PathNotFoundException pnfe) {
>>return false;
>>} catch (ItemNotFoundException infe) {
>>return false;
>>} catch (RepositoryException re) {
>>return false;
>>}
>>}
>>
>>The catch block for RepositoryException should probably wrap the
>>exception as a RuntimeException as it might happen for unknown reason.
>>Changing this might break backward compatibility. Would it be fine to
>>do that?
>>
>>@abhinav - Can you open a bug for this?
>>
>>[1]
>>https://github.com/apache/jackrabbit/blob/trunk/jackrabbit-jcr2spi/src/mai
>>n/java/org/apache/jackrabbit/jcr2spi/ItemManagerImpl.java#L115
>>Chetan Mehrotra
>>
>>
>>On Tue, Jul 23, 2013 at 7:42 PM, Abhinav Atul wrote:
>>> Just in case if this would be the right place to find a solution.
>>>Please let me know if anything is unclear.
>>>
>>> Thanks
>>> Abhinav
>>>
>>> -Original Message-
>>> From: Abhinav Atul [mailto:aa...@adobe.com]
>>> Sent: 22 July 2013 14:58
>>> To: Jackrabbit Users
>>> Subject: [jcr2spi] RepositoryException lost in ItemManager#nodeExists
>>>
>>> Hi,
>>> I am trying to implement a synchronization service
>>>using the jcr connector for Documentum. The issue I am facing is if the
>>>Documentum server becomes non-responsive while trying to check if a node
>>>has been updated or deleted at Documentum, the RepositoryException is
>>>lost in ItemManagerImpl#nodeExists and the synchronization service is
>>>communicated that the node does not exists which may not be the case.
>>>Could the RepositoryException be communicated further?
>>>
>>> Thanks
>>> Abhinav
>>>
>
Re: FW: [jcr2spi] RepositoryException lost in ItemManager#nodeExists
Looking at the code [1]
/**
* @see ItemManager#nodeExists(Path)
*/
public boolean nodeExists(Path path) {
try {
// session-sanity & permissions are checked upon
itemExists(ItemState)
NodeState nodeState = hierMgr.getNodeState(path);
return itemExists(nodeState);
} catch (PathNotFoundException pnfe) {
return false;
} catch (ItemNotFoundException infe) {
return false;
} catch (RepositoryException re) {
return false;
}
}
The catch block for RepositoryException should probably wrap the
exception as a RuntimeException as it might happen for unknown reason.
Changing this might break backward compatibility. Would it be fine to
do that?
@abhinav - Can you open a bug for this?
[1]
https://github.com/apache/jackrabbit/blob/trunk/jackrabbit-jcr2spi/src/main/java/org/apache/jackrabbit/jcr2spi/ItemManagerImpl.java#L115
Chetan Mehrotra
On Tue, Jul 23, 2013 at 7:42 PM, Abhinav Atul wrote:
> Just in case if this would be the right place to find a solution. Please let
> me know if anything is unclear.
>
> Thanks
> Abhinav
>
> -Original Message-
> From: Abhinav Atul [mailto:aa...@adobe.com]
> Sent: 22 July 2013 14:58
> To: Jackrabbit Users
> Subject: [jcr2spi] RepositoryException lost in ItemManager#nodeExists
>
> Hi,
> I am trying to implement a synchronization service using the
> jcr connector for Documentum. The issue I am facing is if the Documentum
> server becomes non-responsive while trying to check if a node has been
> updated or deleted at Documentum, the RepositoryException is lost in
> ItemManagerImpl#nodeExists and the synchronization service is communicated
> that the node does not exists which may not be the case. Could the
> RepositoryException be communicated further?
>
> Thanks
> Abhinav
>
Re: FW: [jackrabbit][core] Invalid node identifier
Hi Abhinav,
Looks reasonable. Can you create a bug for this?
Chetan Mehrotra
On Tue, Jul 23, 2013 at 7:51 PM, Abhinav Atul wrote:
> Any help on the below issue would be highly appreciated.
>
> Thanks
> Abhinav
>
> -Original Message-
> From: Abhinav Atul [mailto:aa...@adobe.com]
> Sent: 22 July 2013 15:45
> To: Jackrabbit Users (us...@jackrabbit.apache.org)
> Subject: [jackrabbit][core] Invalid node identifier
>
> Hi,
>Is there some way to verify beforehand whether an identifier is a valid
> node identifier without depending on concrete implementations? Or could the
> cause(IllegalArgumentException) be embedded in
> org.apache.jackrabbit.core.SessionImpl#getNodeByIdentifier as below
>
>
> } catch (IllegalArgumentException iae) {
> -throw new RepositoryException("invalid identifier: " + id);
> +throw new RepositoryException("invalid identifier: " + id,iae);
> }
>
> Thanks
> Abhinav
>
Re: svn:eol-style reminder (Was: svn commit: r1464328 [1/2] - in /jackrabbit/oak/trunk: oak-core/src/main/java/org/apache/jackrabbit/oak/ oak-core/src/main/java/org/apache/jackrabbit/oak/api/ oak-core
Hi Jukka, Would this work with git-svn also or I would have to tweak somewhere else also? Chetan Mehrotra On Thu, Apr 4, 2013 at 1:16 PM, Jukka Zitting wrote: > Hi, > > On Thu, Apr 4, 2013 at 10:38 AM, wrote: > > add missing svn:eol-style settings > > A reminder to myself and others: Please check that your > ~/.subversion/config file contains the automatic eol-style settings > from http://www.apache.org/dev/svn-eol-style.txt. > > BR, > > Jukka Zitting >
[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=13606097#comment-13606097
]
Chetan Mehrotra commented on JCR-3534:
--
+1 for the new feature
JCR-3448 talks about similar requirement. At that time the thought was to use a
custom Binary implementation which can be serialized and deserialzed. The
requirement for that issue was more around DataStore backed by S3. To address
the security concern we could have used S3 Signed URL which are valid for
certain duration [1] as the opaque identifier which is passed around. So may be
we can have some service provided by DataStore which can provide such safe ids
which can be passed around and still be secure
[1]
http://stackoverflow.com/questions/5419264/best-practice-amazons3-url-sharing
> Add JackrabbitSession.getValueByContentId method
>
>
> Key: JCR-3534
> URL: https://issues.apache.org/jira/browse/JCR-3534
> Project: Jackrabbit Content Repository
> Issue Type: New Feature
> Components: jackrabbit-api, jackrabbit-core
>Affects Versions: 2.6
>Reporter: Felix Meschberger
> Attachments: JCR-3534.patch
>
>
> we have a couple of use cases, where we would like to leverage the global
> data store to prevent sending around and copying around large binary data
> unnecessarily: We have two separate Jackrabbit instances configured to use
> the same DataStore (for the sake of this discussion assume we have the
> problems of concurrent access and garbage collection under control). When
> sending content from one instance to the other instance we don't want to send
> potentially large binary data (e.g. video files) if not needed.
> The idea is for the sender to just send the content identity from
> JackrabbitValue.getContentIdentity(). The receiver would then check whether
> the such content already exists and would reuse if so:
> String ci = contentIdentity_from_sender;
> try {
> Value v = session.getValueByContentIdentity(ci);
> Property p = targetNode.setProperty(propName, v);
> } catch (ItemNotFoundException ie) {
> // unknown or invalid content Identity
> } catch (RepositoryException re) {
> // some other exception
> }
> Thus the proposed JackrabbitSession.getValueByContentIdentity(String) method
> would allow for round tripping the JackrabbitValue.getContentIdentity()
> preventing superfluous binary data copying and moving.
> See also the dev@ thread
> http://jackrabbit.markmail.org/thread/gedk5jsrp6offkhi
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (JCR-3521) IllegalArgumentException thrown on a box running java7 with a sorted query
[ https://issues.apache.org/jira/browse/JCR-3521?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chetan Mehrotra updated JCR-3521: - Attachment: JCR-3521-2.patch Updated patch to include fix for other method highlighted by Alexander > IllegalArgumentException thrown on a box running java7 with a sorted query > -- > > Key: JCR-3521 > URL: https://issues.apache.org/jira/browse/JCR-3521 > Project: Jackrabbit Content Repository > Issue Type: Bug > Components: indexing >Affects Versions: 2.5.3 > Environment: JDK 7 >Reporter: Chetan Mehrotra > Attachments: JCR-3521-2.patch, JCR-3521.patch > > > Today we were running into this nice exception on a box running java7 with a > sorted query (by lastModified DESC): > java.lang.IllegalArgumentException: Comparison method violates its general > contract! > at java.util.TimSort.mergeHi(TimSort.java:868) > at java.util.TimSort.mergeAt(TimSort.java:485) > at java.util.TimSort.mergeForceCollapse(TimSort.java:426) > at java.util.TimSort.sort(TimSort.java:223) > at java.util.TimSort.sort(TimSort.java:173) > at java.util.Arrays.sort(Arrays.java:659) > at java.util.Collections.sort(Collections.java:217) > at > org.apache.jackrabbit.core.query.lucene.join.QueryEngine.sort(QueryEngine.j > ava:625) > at > org.apache.jackrabbit.core.query.lucene.join.QueryEngine.execute(QueryEngin > e.java:484) > at > org.apache.jackrabbit.core.query.lucene.join.QueryEngine.execute(QueryEngin > e.java:126) > at > org.apache.jackrabbit.core.query.lucene.join.QueryEngine.execute(QueryEngin > e.java:115) > at > org.apache.jackrabbit.core.query.QueryObjectModelImpl$2.perform(QueryObject > ModelImpl.java:129) > at > org.apache.jackrabbit.core.query.QueryObjectModelImpl$2.perform(QueryObject > ModelImpl.java:124) > at > org.apache.jackrabbit.core.session.SessionState.perform(SessionState.java:2 > 16) > at > org.apache.jackrabbit.core.query.QueryObjectModelImpl.execute(QueryObjectMo > delImpl.java:123) -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (JCR-3521) IllegalArgumentException thrown on a box running java7 with a sorted query
[ https://issues.apache.org/jira/browse/JCR-3521?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chetan Mehrotra updated JCR-3521: - Attachment: JCR-3521.patch Patch with the testcase. Note that the testcase would only fail on JDK 7 > IllegalArgumentException thrown on a box running java7 with a sorted query > -- > > Key: JCR-3521 > URL: https://issues.apache.org/jira/browse/JCR-3521 > Project: Jackrabbit Content Repository > Issue Type: Bug > Components: indexing >Affects Versions: 2.5.3 > Environment: JDK 7 >Reporter: Chetan Mehrotra > Attachments: JCR-3521.patch > > > Today we were running into this nice exception on a box running java7 with a > sorted query (by lastModified DESC): > java.lang.IllegalArgumentException: Comparison method violates its general > contract! > at java.util.TimSort.mergeHi(TimSort.java:868) > at java.util.TimSort.mergeAt(TimSort.java:485) > at java.util.TimSort.mergeForceCollapse(TimSort.java:426) > at java.util.TimSort.sort(TimSort.java:223) > at java.util.TimSort.sort(TimSort.java:173) > at java.util.Arrays.sort(Arrays.java:659) > at java.util.Collections.sort(Collections.java:217) > at > org.apache.jackrabbit.core.query.lucene.join.QueryEngine.sort(QueryEngine.j > ava:625) > at > org.apache.jackrabbit.core.query.lucene.join.QueryEngine.execute(QueryEngin > e.java:484) > at > org.apache.jackrabbit.core.query.lucene.join.QueryEngine.execute(QueryEngin > e.java:126) > at > org.apache.jackrabbit.core.query.lucene.join.QueryEngine.execute(QueryEngin > e.java:115) > at > org.apache.jackrabbit.core.query.QueryObjectModelImpl$2.perform(QueryObject > ModelImpl.java:129) > at > org.apache.jackrabbit.core.query.QueryObjectModelImpl$2.perform(QueryObject > ModelImpl.java:124) > at > org.apache.jackrabbit.core.session.SessionState.perform(SessionState.java:2 > 16) > at > org.apache.jackrabbit.core.query.QueryObjectModelImpl.execute(QueryObjectMo > delImpl.java:123) -- 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-3521) IllegalArgumentException thrown on a box running java7 with a sorted query
[ https://issues.apache.org/jira/browse/JCR-3521?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13577511#comment-13577511 ] Chetan Mehrotra commented on JCR-3521: -- The issue happens on JDK 7 due to more stringent check for Comparable contract [1]. To workaround this issue you can pass -Djava.util.Arrays.useLegacyMergeSort=true. The issue occurs org.apache.jackrabbit.core.query.lucene.Util#compare(Value[] a, Value[] b) [2] method does not return 0 when both arguments are null.This breaks the transitive nature of the comparable contract [1] http://dertompson.com/2012/11/23/sort-algorithm-changes-in-java-7/ [2] https://github.com/apache/jackrabbit/blob/trunk/jackrabbit-core/src/main/java/org/apache/jackrabbit/core/query/lucene/Util.java#L259 > IllegalArgumentException thrown on a box running java7 with a sorted query > -- > > Key: JCR-3521 > URL: https://issues.apache.org/jira/browse/JCR-3521 > Project: Jackrabbit Content Repository > Issue Type: Bug > Components: indexing >Affects Versions: 2.5.3 > Environment: JDK 7 >Reporter: Chetan Mehrotra > > Today we were running into this nice exception on a box running java7 with a > sorted query (by lastModified DESC): > java.lang.IllegalArgumentException: Comparison method violates its general > contract! > at java.util.TimSort.mergeHi(TimSort.java:868) > at java.util.TimSort.mergeAt(TimSort.java:485) > at java.util.TimSort.mergeForceCollapse(TimSort.java:426) > at java.util.TimSort.sort(TimSort.java:223) > at java.util.TimSort.sort(TimSort.java:173) > at java.util.Arrays.sort(Arrays.java:659) > at java.util.Collections.sort(Collections.java:217) > at > org.apache.jackrabbit.core.query.lucene.join.QueryEngine.sort(QueryEngine.j > ava:625) > at > org.apache.jackrabbit.core.query.lucene.join.QueryEngine.execute(QueryEngin > e.java:484) > at > org.apache.jackrabbit.core.query.lucene.join.QueryEngine.execute(QueryEngin > e.java:126) > at > org.apache.jackrabbit.core.query.lucene.join.QueryEngine.execute(QueryEngin > e.java:115) > at > org.apache.jackrabbit.core.query.QueryObjectModelImpl$2.perform(QueryObject > ModelImpl.java:129) > at > org.apache.jackrabbit.core.query.QueryObjectModelImpl$2.perform(QueryObject > ModelImpl.java:124) > at > org.apache.jackrabbit.core.session.SessionState.perform(SessionState.java:2 > 16) > at > org.apache.jackrabbit.core.query.QueryObjectModelImpl.execute(QueryObjectMo > delImpl.java:123) -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (JCR-3521) IllegalArgumentException thrown on a box running java7 with a sorted query
Chetan Mehrotra created JCR-3521: Summary: IllegalArgumentException thrown on a box running java7 with a sorted query Key: JCR-3521 URL: https://issues.apache.org/jira/browse/JCR-3521 Project: Jackrabbit Content Repository Issue Type: Bug Components: indexing Affects Versions: 2.5.3 Environment: JDK 7 Reporter: Chetan Mehrotra Today we were running into this nice exception on a box running java7 with a sorted query (by lastModified DESC): java.lang.IllegalArgumentException: Comparison method violates its general contract! at java.util.TimSort.mergeHi(TimSort.java:868) at java.util.TimSort.mergeAt(TimSort.java:485) at java.util.TimSort.mergeForceCollapse(TimSort.java:426) at java.util.TimSort.sort(TimSort.java:223) at java.util.TimSort.sort(TimSort.java:173) at java.util.Arrays.sort(Arrays.java:659) at java.util.Collections.sort(Collections.java:217) at org.apache.jackrabbit.core.query.lucene.join.QueryEngine.sort(QueryEngine.j ava:625) at org.apache.jackrabbit.core.query.lucene.join.QueryEngine.execute(QueryEngin e.java:484) at org.apache.jackrabbit.core.query.lucene.join.QueryEngine.execute(QueryEngin e.java:126) at org.apache.jackrabbit.core.query.lucene.join.QueryEngine.execute(QueryEngin e.java:115) at org.apache.jackrabbit.core.query.QueryObjectModelImpl$2.perform(QueryObject ModelImpl.java:129) at org.apache.jackrabbit.core.query.QueryObjectModelImpl$2.perform(QueryObject ModelImpl.java:124) at org.apache.jackrabbit.core.session.SessionState.perform(SessionState.java:2 16) at org.apache.jackrabbit.core.query.QueryObjectModelImpl.execute(QueryObjectMo delImpl.java:123) -- 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
