[jira] [Comment Edited] (JCR-4028) Artifact for jackrabbit-spi:2.6.6 is missing in Maven central repository

[ https://issues.apache.org/jira/browse/JCR-4028?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15515499#comment-15515499 ] Julian Reschke edited comment on JCR-4028 at 9/23/16 5:56 AM: -- Interesting.

[jira] [Commented] (JCR-4028) Artifact for jackrabbit-spi:2.6.6 is missing in Maven central repository

[ https://issues.apache.org/jira/browse/JCR-4028?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15515499#comment-15515499 ] Julian Reschke commented on JCR-4028: - Interesting. Some projects are missing, and

Re: [discuss] Stop wrapping unknown NodeState instances with a MemoryNodeStore?

Hi, I think the core of the problem is that the memory node store doesn't always behave properly when initialised with something else than a MemoryNodeState. Consider: NodeState base = new AlienNodeState(); NodeStore store = new MemoryNodeStore(base); NodeBuilder builder =

[jira] [Created] (JCR-4028) Artifact for jackrabbit-spi:2.6.6 is missing in Maven central repository

Torsten Friebe created JCR-4028: --- Summary: Artifact for jackrabbit-spi:2.6.6 is missing in Maven central repository Key: JCR-4028 URL: https://issues.apache.org/jira/browse/JCR-4028 Project: Jackrabbit

RE: oak-upgrade problems migrating from Jackrabbit 2 to Oak

Ignore that last message. I thought it was logging every node, not every 10,000 nodes :D -Original Message- From: Robert Haycock [mailto:robert.hayc...@artificial-solutions.com] Sent: 22 September 2016 16:34 To: oak-dev@jackrabbit.apache.org Subject: RE: oak-upgrade problems migrating

RE: oak-upgrade problems migrating from Jackrabbit 2 to Oak

I've removed (for now) the large strings and now the upgrade has started. I have to say, it's a lot slower than I anticipated but its running :) Thanks. -Original Message- From: Robert Haycock [mailto:robert.hayc...@artificial-solutions.com] Sent: 22 September 2016 15:33 To:

RE: oak-upgrade problems migrating from Jackrabbit 2 to Oak

Hi Tomek, We are aiming at having a cluster of Oaks . I'll see if I can find the offending large string. Thanks. -Original Message- From: Tomek Rekawek [mailto:reka...@adobe.com] Sent: 22 September 2016 15:29 To: oak-dev@jackrabbit.apache.org Subject: Re: oak-upgrade problems

Re: oak-upgrade problems migrating from Jackrabbit 2 to Oak

Hi Robert, I think the quoted exception may be caused by some long string stored in the Jackrabbit 2 repository. In MongoMK all the strings are inlined in the Mongo documents, while the binaries are extracted to the blob store. Therefore, string properties longer than ~15MB are not supported.

RE: oak-upgrade problems migrating from Jackrabbit 2 to Oak

I can't find any docs either under the project or online regarding this. -Original Message- From: Torgeir Veimo [mailto:torgeir.ve...@gmail.com] Sent: 22 September 2016 15:10 To: oak-dev@jackrabbit.apache.org Subject: Re: oak-upgrade problems migrating from Jackrabbit 2 to Oak Maybe you

Re: oak-upgrade problems migrating from Jackrabbit 2 to Oak

Maybe you can work around it by upgrading using tarmk, then copying to a mongodb repository when it's all done. On 23 September 2016 at 00:08, Robert Haycock < robert.hayc...@artificial-solutions.com> wrote: > Thanks Tomek, > > Getting closer! > > Looks like a setting somewhere needs

RE: oak-upgrade problems migrating from Jackrabbit 2 to Oak

Thanks Tomek, Getting closer! Looks like a setting somewhere needs increasing... Exception in thread "main" java.lang.RuntimeException: javax.jcr.RepositoryException: Failed to copy content at com.google.common.io.Closer.rethrow(Closer.java:149) at

Re: [discuss] Stop wrapping unknown NodeState instances with a MemoryNodeStore?

Hi Robert, Thanks for the feedback. > On 22 Sep 2016, at 15:13, Robert Munteanu wrote: > > Only thing I'm wondering is whether there is a scenario where > performance would be greatly impacted since the NodeState contains lots > of entries _and_ it's not a MemoryNodeState,

Re: [discuss] Stop wrapping unknown NodeState instances with a MemoryNodeStore?

On Thu, 2016-09-22 at 12:49 +, Tomek Rekawek wrote: > Hi, > > I’ve looked into this issue. I think it’s caused by the fact that the > squeeze() method sometimes doesn’t wrap the passed node state with > MemoryNodeStates, but return it as-is. I tried to wrap the state > unconditionally in the

Jackrabbit-trunk - Build # 2389 - Fixed

The Apache Jenkins build system has built Jackrabbit-trunk (build #2389) Status: Fixed Check console output at https://builds.apache.org/job/Jackrabbit-trunk/2389/ to view the results.

Re: [discuss] Stop wrapping unknown NodeState instances with a MemoryNodeStore?

Hi, I’ve looked into this issue. I think it’s caused by the fact that the squeeze() method sometimes doesn’t wrap the passed node state with MemoryNodeStates, but return it as-is. I tried to wrap the state unconditionally in the initializers and it fixed the issue. Michael, Robert - do you

[jira] [Updated] (JCR-4027) NPE in JcrRemotingServlet.canHandle() when content-type is missing

[ https://issues.apache.org/jira/browse/JCR-4027?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Julian Reschke updated JCR-4027: Summary: NPE in JcrRemotingServlet.canHandle() when content-type is missing (was: NPE

[jira] [Created] (JCR-4027) NPE inJcrRemotingServlet.canHandle() when content-type is missing

Julian Reschke created JCR-4027: --- Summary: NPE inJcrRemotingServlet.canHandle() when content-type is missing Key: JCR-4027 URL: https://issues.apache.org/jira/browse/JCR-4027 Project: Jackrabbit

[jira] [Commented] (JCR-4009) CSRF in Jackrabbit-Webdav (CVE-2016-6801)

[ https://issues.apache.org/jira/browse/JCR-4009?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15513104#comment-15513104 ] Julian Reschke commented on JCR-4009: - trunk: [r1761909|http://svn.apache.org/r1761909]

Re: [VOTE] checking JDK compliance of old Jackrabbit branches / call to EOL Jackrabbit 2.4

[X] declare end-of-life for Jackrabbit 2.4 after the upcoming 2.4.6 release Davide

Re: oak-upgrade problems migrating from Jackrabbit 2 to Oak

Hi Robert, thanks for noticing this. It seems you’ve run into another bug: OAK-4842[1]. I fixed it. Also, I backported the previous fix to the 1.4 branch. Feel free to try the SNAPSHOTs: 1.4 (preferred if you want to use Oak 1.4.x):

Re: Jackrabbit and JDK versions

On 21/09/2016 14:45, Julian Reschke wrote: > 3) Switch trunk and 2.12 to JDK 7. +1 Davide

Oak 1.5.11 release plan

Hello team, I'm planning to cut Oak 1.5.11 on 28th September AM BST. If there are any objections please let me know. Otherwise I will re-schedule any non-resolved issue for the next iteration. Thanks Davide

[Oak origin/1.4] Apache Jackrabbit Oak matrix - Build # 1169 - Failure

The Apache Jenkins build system has built Apache Jackrabbit Oak matrix (build #1169) Status: Failure Check console output at https://builds.apache.org/job/Apache%20Jackrabbit%20Oak%20matrix/1169/ to view the results. Changes: [reschke] OAK-4583: RDB*Store: update Tomcat JDBC pool dependency

[ANNOUNCE] Apache Jackrabbit 2.4.6 released

The Apache Jackrabbit community is pleased to announce the release of Apache Jackrabbit 2.4.6. The release is available for download at: http://jackrabbit.apache.org/downloads.html See the full release notes below for details about this release: Release Notes -- Apache Jackrabbit --

Re: [VOTE] Release Apache Jackrabbit 2.4.6

On 2016-09-19 07:59, Julian Reschke wrote: ... Hello Team, the vote passes as follows: +1 Claus Köll +1 Dominique Jaeggi +1 Julian Reschke +1 Marcel Reutegger +1 Michael Dürig