Re: Test failure: testSelector(org.apache.jackrabbit.test.api.query.qom.SelectorTest
Hi, On Wed, Jul 25, 2012 at 11:12 AM, Dominique Pfister wrote: > The garbage collector currently keeps commits that were created within 60 > minutes of > the current head commit's creation time: do the integration tests run for > such a long time? Then it's probably some other bug in the MicroKernel. For some reason it's no longer finding a revision that was there before. BR, Jukka Zitting
Re: Release notes without dates
Hi, On Wed, Jul 25, 2012 at 12:54 PM, KÖLL Claus wrote: > Not the same topic but i also found that we do not have the dtd files of > 2.4.0 release > on http://jackrabbit.apache.org/dtd/. In that release a new dtd file was > introduced ... Good point, we should upload the DTD. > should I open a jira issue ? Yes, or just upload the file yourself. See http://svn.apache.org/repos/asf/jackrabbit/site/trunk/content/dtd/. BR, Jukka Zitting
Re: Release notes without dates
Hi, On Wed, Jul 25, 2012 at 12:33 PM, Alexander Klimetschek wrote: > I just noted that the release notes (e.g. [0]) and download page [1] do not > contain > the dates of the releases. I think that would be a useful metadata. The release notes are prepared already before the release candidate is cut, and modifying them afterwards would be a bit tricky. But adding release dates to the downloads page would certainly be a good idea. So far we've only had them on the front page as a part of the news feed. BR, Jukka Zitting
[jira] [Created] (OAK-184) Allow PropertyState.getValues() to work on single-valued properties
Jukka Zitting created OAK-184:
-
Summary: Allow PropertyState.getValues() to work on single-valued
properties
Key: OAK-184
URL: https://issues.apache.org/jira/browse/OAK-184
Project: Jackrabbit Oak
Issue Type: Improvement
Components: core
Reporter: Jukka Zitting
Assignee: Jukka Zitting
Currently the {{PropertyState}} contract specifies that an
{{IllegalStateException}} gets thrown if a single-valued property is accessed
as a multi-valued one (and vice versa).
This leads to cumbersome if statements in code that simply wants to go through
all the values of a property. To avoid that complexity it would be useful if,
instead of throwing an exception, the {{getValues()}} method simply returned an
iterable containing the one value of a single-valued property. A client that
wants to explicitly check that a property really is multi-valued can still do
so simply enough by calling the {{isArray()} method.
A somewhat similar case can be made also for {{getValue()}} on a multi-valued
property, but that's a bit trickier so let's leave it outside the scope of this
issue.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (JCR-3385) DbClusterTest fails when port is already in use
[ https://issues.apache.org/jira/browse/JCR-3385?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13412813#comment-13412813 ] Jukka Zitting commented on JCR-3385: > The problem is that the ports are also hardcoded in the repository-h2.xml > file. My patch uses variable expansion in the config file to get around that problem. > Alternative patch using an embedded database - a bit less "real world" but > results in simpler test cases Sounds good too, +1. > DbClusterTest fails when port is already in use > --- > > Key: JCR-3385 > URL: https://issues.apache.org/jira/browse/JCR-3385 > Project: Jackrabbit Content Repository > Issue Type: Bug > Components: clustering, jackrabbit-core > Affects Versions: 2.5 >Reporter: Jukka Zitting >Assignee: Thomas Mueller >Priority: Minor > Attachments: > 0001-JCR-3385-DbClusterTest-fails-when-port-is-already-in.patch, > JCR-3385-embedded-shared-db.patch > > > The DbClusterTest and DbClusterTestJCR3162 classes use hard-coded TCP port > numbes 9001 and 9002 which make the tests fail whenever there already is some > process listening on those ports. > It would be better if the classes automatically looked for unused ports for > the tests. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (JCR-3384) TCK: BinaryPropertyTest.testGetLengthJcr2() fails with a multi-valued binary property
[
https://issues.apache.org/jira/browse/JCR-3384?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jukka Zitting resolved JCR-3384.
Resolution: Fixed
Fix Version/s: 2.5.1
Assignee: Jukka Zitting
Indeed. Fixed in revision 1360650.
> TCK: BinaryPropertyTest.testGetLengthJcr2() fails with a multi-valued binary
> property
> -
>
> Key: JCR-3384
> URL: https://issues.apache.org/jira/browse/JCR-3384
> Project: Jackrabbit Content Repository
> Issue Type: Bug
> Components: jackrabbit-jcr-tests
>Affects Versions: 2.5
> Reporter: Jukka Zitting
>Assignee: Jukka Zitting
> Fix For: 2.5.1
>
>
> The {{BinaryPropertyTest}} class returns {{null}} from
> {{getPropertyIsMultivalued}}, meaning that it doesn't care if the property
> being tested is multi-valued or not. And in most cases that is true since the
> class uses {{PropertyUtil.getValue}} utility method to get the (first) value
> of the property. However, the {{testGetLengthJcr2}} method calls
> {{Property.getValue}} directly, which breaks the test if the property being
> tested happens to be multi-valued.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (JCR-3385) DbClusterTest fails when port is already in use
[ https://issues.apache.org/jira/browse/JCR-3385?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jukka Zitting updated JCR-3385: --- Attachment: 0001-JCR-3385-DbClusterTest-fails-when-port-is-already-in.patch The attached patch seems to solve this problem. > DbClusterTest fails when port is already in use > --- > > Key: JCR-3385 > URL: https://issues.apache.org/jira/browse/JCR-3385 > Project: Jackrabbit Content Repository > Issue Type: Bug > Components: clustering, jackrabbit-core >Affects Versions: 2.5 > Reporter: Jukka Zitting >Assignee: Thomas Mueller >Priority: Minor > Attachments: > 0001-JCR-3385-DbClusterTest-fails-when-port-is-already-in.patch > > > The DbClusterTest and DbClusterTestJCR3162 classes use hard-coded TCP port > numbes 9001 and 9002 which make the tests fail whenever there already is some > process listening on those ports. > It would be better if the classes automatically looked for unused ports for > the tests. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (JCR-3385) DbClusterTest fails when port is already in use
Jukka Zitting created JCR-3385: -- Summary: DbClusterTest fails when port is already in use Key: JCR-3385 URL: https://issues.apache.org/jira/browse/JCR-3385 Project: Jackrabbit Content Repository Issue Type: Bug Components: clustering, jackrabbit-core Affects Versions: 2.5 Reporter: Jukka Zitting Priority: Minor The DbClusterTest and DbClusterTestJCR3162 classes use hard-coded TCP port numbes 9001 and 9002 which make the tests fail whenever there already is some process listening on those ports. It would be better if the classes automatically looked for unused ports for the tests. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (JCR-3384) TCK: BinaryPropertyTest.testGetLengthJcr2() fails with a multi-valued binary property
Jukka Zitting created JCR-3384:
--
Summary: TCK: BinaryPropertyTest.testGetLengthJcr2() fails with a
multi-valued binary property
Key: JCR-3384
URL: https://issues.apache.org/jira/browse/JCR-3384
Project: Jackrabbit Content Repository
Issue Type: Bug
Components: jackrabbit-jcr-tests
Affects Versions: 2.5
Reporter: Jukka Zitting
The {{BinaryPropertyTest}} class returns {{null}} from
{{getPropertyIsMultivalued}}, meaning that it doesn't care if the property
being tested is multi-valued or not. And in most cases that is true since the
class uses {{PropertyUtil.getValue}} utility method to get the (first) value of
the property. However, the {{testGetLengthJcr2}} method calls
{{Property.getValue}} directly, which breaks the test if the property being
tested happens to be multi-valued.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (OAK-173) MicroKernel filter syntax is not proper JSON
Jukka Zitting created OAK-173: - Summary: MicroKernel filter syntax is not proper JSON Key: OAK-173 URL: https://issues.apache.org/jira/browse/OAK-173 Project: Jackrabbit Oak Issue Type: Bug Components: mk Reporter: Jukka Zitting Assignee: Jukka Zitting Priority: Minor Since we're leveraging JSON quite a bit around the MicroKernel, it would be good if the syntax of the filter argument to getNodes was that of a proper JSON object. Currently the MicroKernel expects names in the filter to be raw tokens instead of quoted strings, as they should be in a normal JSON object. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: [VOTE] Release Apache Jackrabbit OCM 2.0.0
Hi, On Mon, Jul 9, 2012 at 12:13 PM, Ard Schrijvers wrote: > Isn't the source zip available at [1] not the way it is normally also > done by you? No, see the [DISCUSS] thread I started. > Regarding the PGP signature: Do you mean I should create a KEYS file > at ~ard like you have your KEYS file at [2] ? We already have the KEYS file in http://svn.apache.org/repos/asf/jackrabbit/dist/ and http://www.apache.org/dist/jackrabbit/ so it isn't needed to go with each individual release. What I meant instead is the .asc file that contains your signature for the specific release archive. Currently http://people.apache.org/~ard/ocm/2.0.0/ only comes with the MD5 and SHA1 checksums. BR, Jukka Zitting
[jira] [Resolved] (OAK-163) Move the JCR TCK back to the integrationTesting profile
[ https://issues.apache.org/jira/browse/OAK-163?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jukka Zitting resolved OAK-163. --- Resolution: Fixed Fix Version/s: 0.4 Assignee: Jukka Zitting Noting the above objections, I still decided to implement this change in revision 1359014. It's possible to switch back to the previous build behavior by setting the OAK_INTEGRATION_TESTING environment variable in your environment, and we can always move the TCK back to the default build if we start having trouble with broken builds because of this. > Move the JCR TCK back to the integrationTesting profile > --- > > Key: OAK-163 > URL: https://issues.apache.org/jira/browse/OAK-163 > Project: Jackrabbit Oak > Issue Type: Improvement > Components: jcr > Reporter: Jukka Zitting >Assignee: Jukka Zitting >Priority: Minor > Labels: tck > Fix For: 0.4 > > Attachments: > 0001-OAK-163-Move-the-JCR-TCK-back-to-the-integrationTest.patch > > > In revision 1325811 the JCR TCK tests were moved from the integrationTesting > profile to a normal build. However, since then the execution time of the TCK > has grown to 3+ minutes, which is more than the rest of the Oak build > combined. To keep the build time down to at most a couple of minutes, I'd > like to move the TCK run back to the integrationTesting profile where it will > get executed only when explicitly requested (typically manually before a > commit or after one in a CI build). -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[DISCUSS] Re: Release Apache Jackrabbit OCM 2.0.0
Hi,
[forking a separate discuss thread]
On Mon, Jul 9, 2012 at 11:30 AM, Ard Schrijvers
wrote:
> On Mon, Jul 9, 2012 at 10:51 AM, Bart van der Schans
> wrote:
>> The src zip now contains a NOTICE.txt and NOTICE file as well as a
>> LICENSE.txt as a LICENSE file.
That's a consequence of using the source-release zip generated by the
release profile as the release artifact. Even though it meets the
formal Apache release guidelines, I'm not entirely happy with the way
it's produced.
Instead, if you look at the main Jackrabbit or Oak trunk builds, there
we have a custom assembly plugin configuration specified in the
release profile:
maven-assembly-plugin
single
package
assembly.xml
source-release-assembly
true
Basically this overrides the default source-release assembly
(skipAssembly=true) defined in the Apache parent POM, and replaces it
with a custom one defined in the assembly.xml descriptor that looks
like this:
src
zip
${project.basedir}
**/target/**
**/.*/**
The idea here is to copy everything in the current checkout, excluding
generated files, so that the source archive ends up containing an
exact copy of the sources that were used to generate the rest of the
release. This is IMHO a better approach than the default
source-release assembly that treats the source archive as another
generated artifact that'll then get to include the autogenerated
LICENSE/NOTICE/DEPENDENCIES files, a process that was originally
designed just for binary artifacts..
> I am not sure how to fix this. Should I remove the LICENCE.txt and
> NOTICE.txt from svn? Or rename them to LICENCE and NOTICE?
>
> Also not sure about the DEPENDENCIES. Anybody?
For now I'd just leave them in. For the next release I'd recommend
going with the separate src assembly approach described above, as
that'll take care of this.
> Ah, that stupid derby.log file. I already explicitly ignored it in the
> 'pedantic' profile. Not sure what the best way is to get rid of the
> annoying derby.log file.. ideas are welcome
The best solution to the derby.log file is to add the following
configuration setting to the maven-surefire-plugin:
derby.stream.error.file
target/derby.log
That way the derby.log file goes into target/ and won't clutter the
rest of the checkout.
BR,
Jukka Zitting
Re: [VOTE] Release Apache Jackrabbit OCM 2.0.0
Hi, On Fri, Jul 6, 2012 at 5:39 PM, Ard Schrijvers wrote: > Please vote on releasing this package as Apache Jackrabbit OCM 2.0.0 [x] +1 Release this package as Apache Jackrabbit OCM 2.0.0 PS. You should make the PGP signature available with the source zip file also outside the staged Maven repository. BR, Jukka Zitting
[jira] [Reopened] (JCR-3376) TCK: SQLPathTest.testChildAxisRoot expected root node not in result
[
https://issues.apache.org/jira/browse/JCR-3376?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jukka Zitting reopened JCR-3376:
Revision 1357596 broke the Jackrabbit build since the query engine rejects two
jcr:path constraints in one query.
It sounds like we should rather fix Jackrabbit than this test case, but until
someone has time to look at the details it's best to avoid failing the build,
so I reverted the change for now in revision 1358567. Reopening until we have a
better solution.
> TCK: SQLPathTest.testChildAxisRoot expected root node not in result
> ---
>
> Key: JCR-3376
> URL: https://issues.apache.org/jira/browse/JCR-3376
> Project: Jackrabbit Content Repository
> Issue Type: Improvement
>Reporter: Thomas Mueller
>Assignee: Thomas Mueller
>Priority: Minor
> Fix For: 2.6
>
>
> The TCK test SQLPathTest.testChildAxisRoot runs the following SQL-1 query:
> SELECT * FROM nt:base WHERE jcr:path LIKE '/%' AND NOT jcr:path LIKE
> '/%/%'
> It expected the result to be
> /jcr:system, /testroot, /testdata
> It does not allow the implementation to return the root node ('/'). According
> to the specification, a JCR implementation may filter the root node, as noted
> by Randall Hauch -
> http://jackrabbit.510166.n4.nabble.com/TCK-SQLPathTest-testChildAxisRoot-td4655670.html
> - quote:
> "
> Section 6.6.5.1 ("jcr:like function") defines the semantics of the wildcard
> characters as generally used within LIKE predicates (and "jcr:like" in XPath):
> "As in SQL, the character '%' represents any string of zero or more
> characters, and the character '_' (underscore) represents any
> single character."
> while Section 8.5.2.2 ("Pseudo-property jcr:path") specifies the semantics
> "jcr:path" pseudo column and narrows the semantics of using LIKE with
> "jcr:path" in the second-to-last bullet point:
> "Predicates in the WHERE clause that test jcr:path are only required to
> support the operators =, <> and LIKE. In the case of LIKE predicates,
> support is only required for tests using the % wildcard character as a
> match for a whole path segment (the part between two / characters)
> or within index brackets"
> Because the '%' matches only a whole path segment, the "/%" literal only
> matches paths that have at least one path segment, which means that it
> matches all descendants of the root node.
> "
> the specification says "In the case of LIKE predicates, support is only
> required for tests using the % wildcard character as a match for a whole path
> segment (the part between two / characters)..." but it doesn't specify it
> needs to do so.
> To allow an implementation to return the root node, I suggest to change the
> test as follows:
> ... AND NOT jcr:path LIKE '/%/%' AND jcr:path <> '/'
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: Jackrabbit-trunk - Build # 1936 - Unstable
Hi, On Sat, Jul 7, 2012 at 3:05 PM, Apache Jenkins Server wrote: > Status: Unstable That's SQLPathTest.testChildAxisRoot() failing. Looks like a regression from revision 1357596 for JCR-3376. I reverted the change in revision 1358567 and reopened JCR-3376 until we figure out what needs to be done to avoid breaking the build. BR, Jukka Zitting
Re: MultiDataStore ...
Hi, On Wed, Jul 4, 2012 at 7:27 AM, KÖLL Claus wrote: > I'm implementing at the moment a MultiDataStore and want to know if > someone else is interested so i would provide a patch. Sound useful. A somewhat similar case I've been thinking about is a local datastore cache that could act as a decorator to another, remote datastore backend. The MultiDataStore approach should be helpful in implementing also something like that. > The configuration could look like: > > > This is the tricky bit, as our XML-based configuration mechanism isn't very easy to adjust for such features. Instead of extending the XML configuration format with yet another custom structure, how about we allow the existing elements to specify custom objects instead of just scalar values. That would turn the above configuration to: ... ... Such a feature should come in handy also for many other custom configuration needs. BR, Jukka Zitting
Re: Release JR OCM 2.0.0
Hi, On Sun, Jul 1, 2012 at 12:07 PM, Ard Schrijvers wrote: > I'd like to release JR OCM [1] version 2.0.0 at the end of next week. [...] Sounds like a plan. Before cutting the release, it might be a good idea to check that OCM uses the latest parent POM and add the nice release automation bits that we have in the main trunk and in Oak. Let me (or Alex) know if you need any help with that. BR, Jukka Zitting
Re: Build failed in Jenkins: Jackrabbit-2.2 #77
Hi, On Tue, Jul 3, 2012 at 9:47 PM, Apache Jenkins Server wrote: > Jul 3, 2012 7:47:21 PM > hudson.remoting.SynchronousCommandTransport$ReaderThread run > SEVERE: I/O error in channel channel > java.io.StreamCorruptedException Looks like a Jenkins problem. BR, Jukka Zitting
[jira] [Resolved] (OAK-158) Specify fixed memory settings for unit and integration tests
[ https://issues.apache.org/jira/browse/OAK-158?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jukka Zitting resolved OAK-158. --- Resolution: Fixed Fix Version/s: 0.4 I committed the patch with some modifications (add -XX:MaxPermSize=32m, use the settings also for integration tests, allow override with a -Dtest.opts=... option) in revision 1356715. > Specify fixed memory settings for unit and integration tests > > > Key: OAK-158 > URL: https://issues.apache.org/jira/browse/OAK-158 > Project: Jackrabbit Oak > Issue Type: Improvement > Components: parent > Reporter: Jukka Zitting > Assignee: Jukka Zitting >Priority: Minor > Fix For: 0.4 > > Attachments: OAK-158.diff > > > To reduce the chance of different build results on different platforms, it > would be good to specify fixed memory limits for our unit and integration > tests. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: Question about same name siblings and authorization
Hi, On Tue, Jul 3, 2012 at 10:55 AM, Bart van der Schans wrote: > We running into a (potential) issue with same name siblings and > authorization and I would like to have some feedback before we try to > fix this (if needed at all). Your problem boils down to having "same name siblings" and "authorization" in the same sentence, or perhaps even having same name siblings in the first place. You're probably better off if you try to avoid the SNS feature entirely. > Which is a bit odd, because how can the session know there is more > than one item sibling? Does anybody knows what the spec has to say > about this? The spec leaves this open by explicitly allowing access control to leave gaps in the SNS sequence. It's not an elegant solution, but AFAIUI nobody really considered such interactions when the SNS feature was specified (IIUC it came up just as a logical consequence of the XML import feature). BR, Jukka Zitting
[jira] [Commented] (JCR-3357) Allow TimeSeries to track external counters
[ https://issues.apache.org/jira/browse/JCR-3357?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13405042#comment-13405042 ] Jukka Zitting commented on JCR-3357: The code looks reasonable to me, though it seems like we're already entering the territory of something that's beyond the scope of Jackrabbit. Why do such external time series need to be exposed through the RepositoryStatistics mechanism? Instead of registering them with the repository, couldn't a deployment simply make such time series directly available to clients through JMX or some other management/monitoring interface? > Allow TimeSeries to track external counters > --- > > Key: JCR-3357 > URL: https://issues.apache.org/jira/browse/JCR-3357 > Project: Jackrabbit Content Repository > Issue Type: Improvement > Components: jackrabbit-core >Reporter: Alex Parvulescu >Assignee: Alex Parvulescu > Attachments: JCR-3357.patch > > > We should extend the current TimeSeries to be able to track external > counters. > This would facilitate the exposure of potentially already existing > information by simply wrapping it into counters that will then be tracked by > a normal TimeSeries and exposed as a repository statistic. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (OAK-119) Oak performance benchmark
[ https://issues.apache.org/jira/browse/OAK-119?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jukka Zitting resolved OAK-119. --- Resolution: Fixed Resolving as fixed for 0.3 based on the above work. > Oak performance benchmark > - > > Key: OAK-119 > URL: https://issues.apache.org/jira/browse/OAK-119 > Project: Jackrabbit Oak > Issue Type: New Feature > Components: bench > Reporter: Jukka Zitting > Assignee: Jukka Zitting > Labels: performance > Fix For: 0.3 > > > We need a performance test suite for benchmarking Oak against previous > versions (to detect regressions) and other comparable repositories (to know > where we stand). -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (OAK-114) MicroKernel API: specify retention policy for old revisions
[ https://issues.apache.org/jira/browse/OAK-114?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jukka Zitting updated OAK-114: -- Fix Version/s: (was: 0.3) > MicroKernel API: specify retention policy for old revisions > --- > > Key: OAK-114 > URL: https://issues.apache.org/jira/browse/OAK-114 > Project: Jackrabbit Oak > Issue Type: Improvement > Components: mk >Reporter: Stefan Guggisberg >Assignee: Stefan Guggisberg > > the MicroKernel API javadoc should specify the minimal guaranteed retention > period for old revisions. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: Native HTTP bindings for Oak
Hi, On Wed, Jun 27, 2012 at 3:58 PM, Thomas Mueller wrote: > But this feature is unrelated to the branch/merge / workspace feature that > Jukka proposed here (at least as far as I understand). The branch feature goes a bit beyond what Bertrand describes in that it is read-write instead of just a read-only view of a given revision. But yes, it does support also Bertrand's use case. BR, Jukka Zitting
[jira] [Commented] (OAK-153) Split the CommitHook interface
[
https://issues.apache.org/jira/browse/OAK-153?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13401411#comment-13401411
]
Jukka Zitting commented on OAK-153:
---
The lifecycle of such hooks is up to the deployment - oak-core only cares about
the hooks that are made available to it by the deployment at any given point of
time. For example in an OSGi deployment oak-core would use the whiteboard
pattern to access such hooks.
It should be fine for a class to implement both interfaces if it wants to. But
note that, as explained above, there are few guarantees about causality between
before- and afterCommit() calls. Thus there isn't much that such a combined
class could do that two independent classes couldn't.
> Split the CommitHook interface
> --
>
> Key: OAK-153
> URL: https://issues.apache.org/jira/browse/OAK-153
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: core
>Reporter: Jukka Zitting
>Assignee: Jukka Zitting
>
> The {{CommitHook}} interface has two methods, {{beforeCommit()}} and
> {{afterCommit()}}, since the symmetry originally seemed like a good idea.
> However, in practice these methods are not really so symmetric after all.
> For example, unlike {{afterCommit()}} the {{beforeCommit()}} method may end
> up being called multiple times for a given changeset if it needs to be
> repeatedly rebased or otherwise revised before it can be committed. There
> isn't even any guarantee that a particular changeset on which
> {{beforeCommit()}} has been called ever gets committed. And on the other hand
> there are good reasons to avoid calling {{afterCommit()}} on each and every
> commit that has been made. Instead it could be called only every now and then
> to cover larger sets of changes.
> Thus I'd like to split the {{CommitHook}} interface to two parts that I'd
> tentatively call {{CommitEditor}} and {{Observer}}.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: XA help needed ...
Hi, On Mon, Jun 25, 2012 at 8:12 AM, KÖLL Claus wrote: > Is it possible to create the Lock on the Global Revison Table only in one > phase > (commit phase) and not spanned over prepare and commit ? Ideally that should be possible (true two-phase commit), but I don't think the current Jackrabbit architecture can bend to do that. The main problem is that the prepare phase needs to be able to ensure that no concurrent change can invalidate the prepared changes before they get committed. We currently have no way of doing that without the lock that spans both prepare and commit. BR, Jukka Zitting
Re: deepTree.xml (Was: svn commit: r1352905 - in /jackrabbit/trunk/test/performance/base/src/main: java/org/apache/jackrabbit/performance/ resources/)
Hi, On Mon, Jun 25, 2012 at 4:22 PM, Angela Schreiber wrote: > it wasn't program-generated but instead was in a content package > that i was using since the early days of performance measurements. > since jr 1.x didn't have access control and i was in fact interested > in crx performance rather than jr, it never made into jackrabbit ;-) > jukka, feel free to write a setup that generates that content. OK, cool. I'll take a shot at reproducing the deepTree content programmatically. BR, Jukka Zitting
Re: Jackrabbit-trunk - Build # 1919 - Still Failing
H, On Mon, Jun 25, 2012 at 3:45 PM, Apache Jenkins Server wrote: > The Apache Jenkins build system has built Jackrabbit-trunk (build #1919) > > Status: Still Failing The build was complaining about a missing license header in deepTree.xml. Fixed by excluding the file from header checks in revision 1353548. BR, Jukka Zitting
[jira] [Commented] (OAK-150) Basic JCR LockManager support
[ https://issues.apache.org/jira/browse/OAK-150?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13400477#comment-13400477 ] Jukka Zitting commented on OAK-150: --- In revision 1353536 I added a basic LockManager implementation and a naive locking implementation that simply uses the presence of the jcr:lockOwner and jcr:lockIsDeep properties to determine whether a node is locked or not. No synchronization or even validation of locking status is present for now. > Basic JCR LockManager support > - > > Key: OAK-150 > URL: https://issues.apache.org/jira/browse/OAK-150 > Project: Jackrabbit Oak > Issue Type: Improvement > Components: jcr >Reporter: Jukka Zitting > Assignee: Jukka Zitting > Labels: locking > > Even though we currently don't (and perhaps never will) support full JCR > locking functionality in Oak, it would still be good to have a basic > LockManager implementation for clients that assume it's present and use it > simply to access lock tokens and to ask whether a particular node is locked > or not. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
deepTree.xml (Was: svn commit: r1352905 - in /jackrabbit/trunk/test/performance/base/src/main: java/org/apache/jackrabbit/performance/ resources/)
Hi, On Fri, Jun 22, 2012 at 4:39 PM, wrote: > jackrabbit/trunk/test/performance/base/src/main/resources/deepTree.xml This looks like an program-generated content tree. Instead of storing the tree as an export, it would be better if we just kept the program that generates such a tree. That way we avoid a 11MB blob in the source tree and have a much easier time tweaking the content structure to better match real-world scenarios if needed. BR, Jukka Zitting
[jira] [Resolved] (JCR-3358) Allow null type in JcrUtils.getOrAddNode(parent, name, type)
[ https://issues.apache.org/jira/browse/JCR-3358?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jukka Zitting resolved JCR-3358. Resolution: Fixed Fix Version/s: 2.5.1 Done in revision 1353450. > Allow null type in JcrUtils.getOrAddNode(parent, name, type) > > > Key: JCR-3358 > URL: https://issues.apache.org/jira/browse/JCR-3358 > Project: Jackrabbit Content Repository > Issue Type: Improvement > Components: jackrabbit-jcr-commons > Reporter: Jukka Zitting > Assignee: Jukka Zitting > Fix For: 2.5.1 > > > It would be convenient if the JcrUtils.getOrAddNode(parent, name, type) > method fell back to JcrUtils.getOrAddNode(parent, name) semantics if the > given type is null. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (JCR-3358) Allow null type in JcrUtils.getOrAddNode(parent, name, type)
Jukka Zitting created JCR-3358: -- Summary: Allow null type in JcrUtils.getOrAddNode(parent, name, type) Key: JCR-3358 URL: https://issues.apache.org/jira/browse/JCR-3358 Project: Jackrabbit Content Repository Issue Type: Improvement Components: jackrabbit-jcr-commons Reporter: Jukka Zitting Assignee: Jukka Zitting It would be convenient if the JcrUtils.getOrAddNode(parent, name, type) method fell back to JcrUtils.getOrAddNode(parent, name) semantics if the given type is null. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (OAK-149) Automatic session refresh after namespace registry changes
[ https://issues.apache.org/jira/browse/OAK-149?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jukka Zitting resolved OAK-149. --- Resolution: Fixed Fix Version/s: 0.3 In fact the session should be automatically refreshed whenever the namespace registry is explicitly accessed, be it for read or write. That way the client has a consistent view of the repository at all times. Done in revision 1352901. > Automatic session refresh after namespace registry changes > -- > > Key: OAK-149 > URL: https://issues.apache.org/jira/browse/OAK-149 > Project: Jackrabbit Oak > Issue Type: Improvement > Components: jcr > Reporter: Jukka Zitting >Priority: Minor > Fix For: 0.3 > > > The registerNamespace() and unregisterNamespace() methods of > NamespaceRegistry should cause the session from which the registry instance > was acquired to refresh its state. Otherwise code that first registers a new > namespace and then tries to use it might end up failing because the session > is still seeing and older version of the content tree. Potential other > sessions should remain as they are and only start seeing the modified > namespaces once they're separately refreshed. > PS. Similar refresh requirements probably also affect things like node type > registration, versioning, direct-to-workspace writes, etc. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (JCR-3355) Unable to create performance tests using JCR 2.0 API
[ https://issues.apache.org/jira/browse/JCR-3355?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13399321#comment-13399321 ] Jukka Zitting commented on JCR-3355: +1 We originally used 1.0 as the base dependency so that we could compare performance across both Jackrabbit 1.x and 2.x, but nowadays that all Jackrabbit 1.x versions are obsolete we can well focus on just JCR 2.0. > Unable to create performance tests using JCR 2.0 API > > > Key: JCR-3355 > URL: https://issues.apache.org/jira/browse/JCR-3355 > Project: Jackrabbit Content Repository > Issue Type: Bug > Components: test >Reporter: angela > > the jcr dependency of the performance-base module is still set to jcr 1.0. > in order to to be able to write test using JCR 2.0 functionality and given > the fact that jackrabbit 1.x was probably not used that often any more i > would suggest to > - set dependency to 2.0 > - comment the 1.x modules in the performance pom.xml > what do you think? -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (JCR-3263) Consistency checker performance improvements
[ https://issues.apache.org/jira/browse/JCR-3263?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13399265#comment-13399265 ] Jukka Zitting commented on JCR-3263: I adjusted the code slightly in revision 1352849 by adding a basic getAllNodeInfos() implementation in AbstractBundlePersistenceManager so that only those PMs that can implement the logic more efficiently need to override the method. > Consistency checker performance improvements > > > Key: JCR-3263 > URL: https://issues.apache.org/jira/browse/JCR-3263 > Project: Jackrabbit Content Repository > Issue Type: Improvement >Reporter: Unico Hommes > Fix For: 2.6 > > Attachments: checkerperformance.patch > > > Currently the consistency checker loads in a batch of node ids and for each > node id fetches the corresponding bundle, its child bundles, and parent > bundle separately. This makes the consistency checker perform less than > optimal and may take hours (days?) to complete for large repositories. > I've been able to make the checker execute about 20 times faster on my local > machine by loading in batches of node prop bundles at once. For 17000 nodes > in the workspace the current implementation ran for about 23 seconds whereas > with the enhancements I made it finished in 1.2 seconds. > Now the problem lies in the fact that loading in node prop bundles in batches > may require a lot of memory. And it is not very predictable how much per > batch size because the sizes of the individual bundles are unpredictable. > Also the node prop bundle contains much more information than is needed for a > consistency check. > What would be ideal in this situation is to introduce a new type - call it > NodeInfo - that contains only the structural information the checker needs to > do its work. Meaning the node id, the parent id and the child ids. In order > to allow for a possible future referential integrity check perhaps also its > reference type propeties. > The IterablePersistenceManager interface would then get an additional method: > Map getAllNodeInfos(); > If this is an acceptable proposal I would like to work on this and contribute > a patch. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: jackrabbit-core integration tests memory/GC problems
Hi, On Thu, Jun 21, 2012 at 3:14 PM, Julian Reschke wrote: > are there recommended maven_opts for running with -PintegrationTesting? > > The only results I currently get are either out of memory exceptions *or* GC > timeouts. (jdk1.6, win64, on org.apache.jackrabbit.core.data.TestAll) I haven't encountered the problem (Java 7 on Linux), and it looks like our Jenkins build (Java 6 on Solaris) that doesn't use any specific MAVEN_OPTS setting is also fine. It looks like a platform-specific problem, either caused by too little memory used by the default JVM settings or by some problem in the way our code interacts with the host platform. Is this a recent issue, i.e. can you reproduce it in the same environment with an older revision of Jackrabbit trunk? BR, Jukka Zitting
Re: Unsubscribe
Hi, On Thu, Jun 21, 2012 at 3:22 PM, John Bradway wrote: > Unsubscribe See http://jackrabbit.apache.org/mailing-lists.html for instructions on how to unsubscribe. BR, Jukka Zitting
[jira] [Resolved] (JCR-3347) Searches on properties of type Double give unexpected results
[ https://issues.apache.org/jira/browse/JCR-3347?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jukka Zitting resolved JCR-3347. Resolution: Not A Problem Assignee: Jukka Zitting You need to be careful with data typing in queries because of the way the underlying index works and because the query as specified has no way of guessing the actual data type of the referenced "price" property. Using "price > 50.0" is better than "price > 50" as it uses double comparison instead of integer comparison. Alternatively you can use explicit type casting for the constant value. > Searches on properties of type Double give unexpected results > - > > Key: JCR-3347 > URL: https://issues.apache.org/jira/browse/JCR-3347 > Project: Jackrabbit Content Repository > Issue Type: Bug > Environment: Linux (Ubuntu 12.04), Oracle Java 1.6.0_31 > Reporter: Felix Oghină >Assignee: Jukka Zitting > > Example: > * have a node with a Double property, e.g. price=25 > * The following query returns the node, although it shouldn't: > SELECT * FROM [nt:unstructured] WHERE price > 50 -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (OAK-145) Set up Travis CI builds
[ https://issues.apache.org/jira/browse/OAK-145?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jukka Zitting resolved OAK-145. --- Resolution: Fixed Fix Version/s: 0.3 Travis builds are now up at http://travis-ci.org/apache/jackrabbit-oak. Since Travis uses GitHub and currently the github.com/apache mirrors aren't updated in real-time (see INFRA-4641), there's some extra delay between commits and when they trigger builds on Travis. But apart from that everything seems OK, so resolving as fixed. > Set up Travis CI builds > --- > > Key: OAK-145 > URL: https://issues.apache.org/jira/browse/OAK-145 > Project: Jackrabbit Oak > Issue Type: Task > Reporter: Jukka Zitting >Assignee: Jukka Zitting > Fix For: 0.3 > > > It would be nice to have an Oak CI build on http://travis-ci.org/ -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (JCR-3306) JSR 283 Transactions
[ https://issues.apache.org/jira/browse/JCR-3306?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13294119#comment-13294119 ] Jukka Zitting commented on JCR-3306: This shouldn't be too difficult to implement. See the XASession code in JCR-RMI for an example of the bits that a remoting layer needs to keep track of. > JSR 283 Transactions > > > Key: JCR-3306 > URL: https://issues.apache.org/jira/browse/JCR-3306 > Project: Jackrabbit Content Repository > Issue Type: Sub-task > Components: jackrabbit-jcr2spi, jackrabbit-spi, > jackrabbit-spi-commons, jackrabbit-spi2dav, jackrabbit-spi2jcr, JCR 2.0, > sandbox >Reporter: David Buchmann > > following from the discussion [1] on the dev mailinglist, we are missing > transaction support in the jcr-remoting. would be great to have it (for phpcr > we only care about the server side but i guess the client side could be > useful for others). is it hard to do? > [1] > http://mail-archives.apache.org/mod_mbox/jackrabbit-dev/201203.mbox/browser -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (JCR-3242) Update to Lucene 3.5
[ https://issues.apache.org/jira/browse/JCR-3242?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13294111#comment-13294111 ] Jukka Zitting commented on JCR-3242: > Where are the rules for the code format ? For the most part we follow the standard Java coding conventions. Note that Alex' comment on formatting wasn't about the conventions you we're following but rather about your patch containing formatting changes unrelated to this issue. > Update to Lucene 3.5 > > > Key: JCR-3242 > URL: https://issues.apache.org/jira/browse/JCR-3242 > Project: Jackrabbit Content Repository > Issue Type: Improvement > Components: jackrabbit-core >Affects Versions: 2.4.1 >Reporter: Sascha Rodekamp > Labels: patch > Attachments: JCR-3242-jr-core-v0.patch, > JCR-3242_lucene_update_3.5.patch, JCR-3242_lucene_update_3.5.patch, > JCR-3242_lucene_update_3.6.patch, JCR-3242_lucene_update_3.6_v2.patch, > lucene_3.6.0_updated.patch, surefire-reports.7z, surefire-reports.7z > > > Hi, > i want to update lucene to version 3.5. After making a few code changes the > tests fail. > I'll attach the patch with the changes plus the surfire logs. It would be > great if someone found the time to have a short look and have an idea how to > fix this issue. > Main Problem: > Caused by: java.lang.UnsupportedOperationException: IndexReader is read-only > at > org.apache.jackrabbit.core.query.lucene.ReadOnlyIndexReader.doCommit(ReadOnlyIndexReader.java:175) > at org.apache.lucene.index.IndexReader.commit(IndexReader.java:1464) > at org.apache.lucene.index.MultiReader.doCommit(MultiReader.java:413) > at org.apache.lucene.index.IndexReader.commit(IndexReader.java:1464) > at org.apache.lucene.index.IndexReader.commit(IndexReader.java:1450) > at org.apache.lucene.index.IndexReader.decRef(IndexReader.java:273) > at org.apache.lucene.index.IndexReader.close(IndexReader.java:1479) > at > org.apache.jackrabbit.core.query.lucene.CachingMultiIndexReader.release(CachingMultiIndexReader.java:157) > at > org.apache.jackrabbit.core.query.lucene.MultiIndex.releaseMultiReader(MultiIndex.java:1001) > at > org.apache.jackrabbit.core.query.lucene.MultiIndex.safeFlush(MultiIndex.java:1318) > at > org.apache.jackrabbit.core.query.lucene.Recovery.run(Recovery.java:170) > at > org.apache.jackrabbit.core.query.lucene.Recovery.run(Recovery.java:84) > at > org.apache.jackrabbit.core.query.lucene.MultiIndex.(MultiIndex.java:314) > at > org.apache.jackrabbit.core.query.lucene.SearchIndex.doInit(SearchIndex.java:555) > at > org.apache.jackrabbit.core.query.AbstractQueryHandler.init(AbstractQueryHandler.java:78) > at > org.apache.jackrabbit.core.config.RepositoryConfigurationParser$1.getQueryHandler(RepositoryConfigurationParser.java:655) > at > org.apache.jackrabbit.core.config.RepositoryConfig.getQueryHandler(RepositoryConfig.java:1037) > at > org.apache.jackrabbit.core.SearchManager.(SearchManager.java:171) > at > org.apache.jackrabbit.core.RepositoryImpl.getSystemSearchManager(RepositoryImpl.java:607) > at > org.apache.jackrabbit.core.RepositoryImpl.access$100(RepositoryImpl.java:124) > at > org.apache.jackrabbit.core.RepositoryImpl$WorkspaceInfo.getSearchManager(RepositoryImpl.java:1855) > at > org.apache.jackrabbit.core.RepositoryImpl$WorkspaceInfo.doPostInitialize(RepositoryImpl.java:2092) > at > org.apache.jackrabbit.core.RepositoryImpl$WorkspaceInfo.initialize(RepositoryImpl.java:1997) > at > org.apache.jackrabbit.core.RepositoryImpl.initStartupWorkspaces(RepositoryImpl.java:510) > at > org.apache.jackrabbit.core.RepositoryImpl.(RepositoryImpl.java:318) > at > org.apache.jackrabbit.core.RepositoryImpl.create(RepositoryImpl.java:582) > at > org.apache.jackrabbit.core.JackrabbitRepositoryStub.createRepository(JackrabbitRepositoryStub.java:185) > at > org.apache.jackrabbit.core.JackrabbitRepositoryStub.getOrCreateRepository(JackrabbitRepositoryStub.java:193) > at > org.apache.jackrabbit.core.JackrabbitRepositoryStub.getRepository(JackrabbitRepositoryStub.java:156) > ... 19 more > Best Regards, > Sascha -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: access request
Hi, On Tue, Jun 12, 2012 at 12:35 PM, Hendry Betts wrote: > I would like to help with the Jackrabbit Wiki. > > I recently encountered a problem actually configuring Jackrabbit to work > with MSSQL. I have figured it out and would like to be able to share this > information as well as assist in documentation. Great! I added your account to the ContributorsGroup, so you should now have write access to the wiki. BR, Jukka Zitting
Re: Mongodb bundle persistence manager
Hi, On Sat, Jun 9, 2012 at 4:50 AM, Hui Lin wrote: > i can certainly make a patch for you to test if you can give me some lead > how to do it. i never involved with open source development before. Welcome, you're in for a fun ride! Basically what you need to do to create a patch for us to review, is to first checkout the latest trunk from svn: $ svn checkout https://svn.apache.org/repos/asf/jackrabbit/trunk jackrabbit-trunk Make sure you can build the source tree: $ cd jackrabbit-trunk $ mvn clean install Then add your code to appropriate places in the Jackrabbit source tree, and make sure all are tracked by svn: $ svn status # shows you all the files you've added or modified $ svn add ... # for each file that you've added For example, in your case you'd add the extra persistence manager to a new org.apache.jackrabbit.core.persistence.mongodb package under jackrabbit-core/src/main/java and put any test code under jackrabbit-core/src/test/java. Make sure that the main build still works, and use "svn diff" to generate the patch: $ mvn clean install $ svn diff > mongodb.patch Check that the patch looks OK and either send it here to the mailing list or (better yet) create a new feature request in the Jackrabbit issue tracker and attach the patch there. Do that a few times, and you'll become a Jackrabbit committer. :-) BR, Jukka Zitting
[jira] [Commented] (JCR-3327) Upgrade to Java SE 6
[ https://issues.apache.org/jira/browse/JCR-3327?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13292113#comment-13292113 ] Jukka Zitting commented on JCR-3327: > We should update our Jenkins build. Done. > Upgrade to Java SE 6 > > > Key: JCR-3327 > URL: https://issues.apache.org/jira/browse/JCR-3327 > Project: Jackrabbit Content Repository > Issue Type: Improvement >Affects Versions: 2.6 >Reporter: Julian Reschke >Assignee: Julian Reschke > > See <http://java.sun.com/j2se/1.5/> > We should switch to 1.6 (minimally). -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (JCR-3327) Upgrade to Java SE 6
[ https://issues.apache.org/jira/browse/JCR-3327?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13291790#comment-13291790 ] Jukka Zitting commented on JCR-3327: > Not sure whether build/test server infrastructure needs to be reconfigured? We should update our Jenkins build. Unfortunately the Apache build server seems to be down ATM. > Upgrade to Java SE 6 > > > Key: JCR-3327 > URL: https://issues.apache.org/jira/browse/JCR-3327 > Project: Jackrabbit Content Repository > Issue Type: Improvement >Affects Versions: 2.6 >Reporter: Julian Reschke >Assignee: Julian Reschke > > See <http://java.sun.com/j2se/1.5/> > We should switch to 1.6 (minimally). -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: Mongodb bundle persistence manager
Hi, On Thu, Jun 7, 2012 at 11:45 PM, Hui Lin wrote: > anybody get a change to test the code? it would be something nice to have in > additional to the persistence managers out there already. Can you test the code against plain Jackrabbit instead of CRX/CQ? Also, it would be easier for us to help if you had a simple test case that illustrates the problem. Having the MongoDB PM code you included earlier and the test case as a patch that I can apply against Jackrabbit trunk would be ideal. Note that there's been other efforts to implement the Jackrabbit PM interface based on NoSQL databases, but such efforts commonly encounter the issue that Jackrabbit 2.x expects the operation of saving transient changes to be atomic. Do you have a way to ensure that with MongoDB? BR, Jukka Zitting
Re: Mongodb bundle persistence manager
Hi, On Wed, Jun 6, 2012 at 4:14 PM, Hui Lin wrote: > hey folks, i am working on mongodb persistence manager in CQ. I implemented > all the methods but the repository shutdown due to unknown error during the > startup. Can anybody help me look at the code? It would be useful if you also included the "unknown error" you mentioned. BR, Jukka Zitting
Re: Jackrabbit 2.4.2 release plan
Hi, On Wed, Jun 6, 2012 at 11:03 AM, Julian Reschke wrote: > Bart, any news on this? I'd prefer a 2.4.2 release as soon as possible, no > matter whether this fix makes it or not :-) We can well cut 2.4.2 now and do a 2.4.3 release later as soon as Bart's fix is in. Any committer can cut a new release, so if Bart's busy with other stuff you or Alex could also take care of it. BR, Jukka Zitting
Re: June board report
Hi, On Tue, Jun 5, 2012 at 5:04 PM, Michael Dürig wrote: > I've assembled a preliminary board report: > > http://wiki.apache.org/jackrabbit/Board%20Report%20June%202012 > > Please comment/add/change if required. I plan to submit the report beginning > of next week. Looks good, nice work! Some extra things that might be worth mentioning: * Alex Parvulescu has successfully taken up the role of a release manager. * There is renewed interest on the OCM codebase, driven by Ard Schrijvers. We expect to be able to cut a new, long overdue OCM release in near future. * ModeShape, a JCR implementation from JBoss, is working with us to improve the JCR test suite. To better facilitate this cooperation we may want to split the test suite away from the main Jackrabbit release schedule. BR, Jukka Zitting
Re: 2.5.0 release in Maven repository?
Hi, On Tue, Jun 5, 2012 at 6:50 PM, Randall Hauch wrote: > I understand that the 2.5.0 release is not a stable release, but I'm > interested in it to get some fixes for several TCK tests. The release was > approved on May 31 [1], but I still don't see it in the Apache Maven > repository [2] or Maven Central [3]. Sorry about that, I missed pushing the release out also through Maven (too busy lately...). I fixed that now, and the 2.5.0 release should show up on Maven Central in a few hours. BR, Jukka Zitting
[jira] [Commented] (JCR-3327) Upgrade to Java SE 6
[ https://issues.apache.org/jira/browse/JCR-3327?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13287965#comment-13287965 ] Jukka Zitting commented on JCR-3327: We've been fairly consistent in putting only bug fixes and other low-risk changes to maintenance branches. The basic rule is that a patch level upgrade should never break a working system. Upgrading the Java version doesn't meet that requirement (it by design breaks all Java 5 deployments), which is why we shouldn't do it in the 2.4 branch. > Upgrade to Java SE 6 > > > Key: JCR-3327 > URL: https://issues.apache.org/jira/browse/JCR-3327 > Project: Jackrabbit Content Repository > Issue Type: Improvement >Affects Versions: 2.6 >Reporter: Julian Reschke > > See <http://java.sun.com/j2se/1.5/> > We should switch to 1.6 (minimally). -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (JCR-3327) Upgrade to Java SE 6
[ https://issues.apache.org/jira/browse/JCR-3327?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jukka Zitting updated JCR-3327: --- Affects Version/s: (was: 2.4.2) Issue Type: Improvement (was: Bug) Summary: Upgrade to Java SE 6 (was: Java SE 5.0 has been end-of-lifed) [updated issue summary and type to better describe the proposed action] +1 to switching to Java 6 in Jackrabbit trunk. If someone still needs Java 5 support, they can still use Jackrabbit 2.4 or provide a patch that restores Java 5 compatibility for the upcoming Jackrabbit 2.6 release branch. > Upgrade to Java SE 6 > > > Key: JCR-3327 > URL: https://issues.apache.org/jira/browse/JCR-3327 > Project: Jackrabbit Content Repository > Issue Type: Improvement >Affects Versions: 2.6 >Reporter: Julian Reschke > > See <http://java.sun.com/j2se/1.5/> > We should switch to 1.6 (minimally). -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (JCR-3313) JCR TCK Test for expanding column names is too restrictive
[ https://issues.apache.org/jira/browse/JCR-3313?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jukka Zitting updated JCR-3313: --- Fix Version/s: 2.5.1 Typically the release version is set to the next trunk release version (in this case 2.5.1) when the issue is resolved. Alternatively the release manager will go through all resolved issues without a release version before the next release and update the issue metadata as needed. I set the release version to 2.5.1 for now. > JCR TCK Test for expanding column names is too restrictive > -- > > Key: JCR-3313 > URL: https://issues.apache.org/jira/browse/JCR-3313 > Project: Jackrabbit Content Repository > Issue Type: Bug > Components: jackrabbit-jcr-tests, JCR 2.0 >Affects Versions: 2.4.1 >Reporter: Randall Hauch > Fix For: 2.5.1 > > Attachments: > 0001-JCR-3313-Changed-a-ColumnTest-test-to-only-check-for.patch, > 0002-JCR-3313-Changed-a-ColumnTest-test-to-only-check-for.patch > > > The > 'org.apache.jackrabbit.test.api.query.qom.ColumnTest.testExpandColumnsForNodeType()' > test method issues the following query: > SELECT s.* FROM [nt:unstructured] AS s > and then proceeds to check that the columns in the results set. However, a > problem with the expectations in the test: the test assumes that the result > set *only* contains columns for the single-valued, non-residual property > definitions for the selected node type. Clearly this is overly constraining, > since Section 6.7.1 of the JSR-283 specification clearly allows an > implementation to return additional columns (e.g., multi-valued property > definitions). Here's the relevant parts of this section: > A Query consists of: > ... > • A list of zero or more Columns to include in the tabular view of the > query results. > If no columns are specified, the columns available in the tabular view > are implementation > determined, but minimally include, for each selector, a column for each > single-valued > non-residual property of the selector's node type. > In the test's query, no columns are specified for the selector 's', so the > result set must to have AT A MINIMUM the columns for the single-valued > non-residual property defined on the selector's node type, but an > implementation CAN include columns for other properties defined on the > selector's node type. An implementation is even allowed to include columns > that do not map to properties defined on the selector's node type (e.g., > pseudo-columns that don't really exist as properties). > The test's query uses "nt:unstructured" for the test node type (if not > overridden by the test environment), and in this case an implementation > should be allowed to include the 'jcr:mixinTypes' multi-valued property. > Therefore, the test is overly strict and should not fail when extra columns > are included. The correct behavior is to test only that the result includes > AT LEAST a column for each single-valued non-residual property on the > selector's node type. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[RESULT] [VOTE] Release Apache Jackrabbit 2.5.0
Hi, On Mon, May 28, 2012 at 11:32 AM, Jukka Zitting wrote: > Please vote on releasing this package as Apache Jackrabbit 2.5.0. The vote passes as follows: +1 Alex Parvulescu +1 Bart van der Schans +1 Jukka Zitting +1 Michael Dürig Thanks! I'll push the release out. BR, Jukka Zitting
[VOTE] Release Apache Jackrabbit 2.5.0
Hi, A candidate for the Jackrabbit 2.5.0 release is available at: http://people.apache.org/~jukka/jackrabbit/2.5.0/ The release candidate is a zip archive of the sources in: http://svn.apache.org/repos/asf/jackrabbit/tags/2.5.0/ The SHA1 checksum of the archive is 7cd40182f6957a50aeab87a9c2aabe8d8a9cb17c A staged Maven repository is available for review at: https://repository.apache.org/content/repositories/orgapachejackrabbit-143/ The command for running automated checks against this release candidate is: $ sh check-release.sh jukka 2.5.0 7cd40182f6957a50aeab87a9c2aabe8d8a9cb17c Please vote on releasing this package as Apache Jackrabbit 2.5.0. The vote is open for the next 72 hours and passes if a majority of at least three +1 Jackrabbit PMC votes are cast. [ ] +1 Release this package as Apache Jackrabbit 2.5.0 [ ] -1 Do not release this package because... My vote is +1. BR, Jukka Zitting
[jira] [Updated] (JCR-3191) Update commons-io dependency from versiom 1.4 to 2.0.1
[ https://issues.apache.org/jira/browse/JCR-3191?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jukka Zitting updated JCR-3191: --- Issue Type: Improvement (was: Wish) Summary: Update commons-io dependency from versiom 1.4 to 2.0.1 (was: I would like to update commons-io dependency from versiom 1.4 to 2.0.1 ) > Update commons-io dependency from versiom 1.4 to 2.0.1 > --- > > Key: JCR-3191 > URL: https://issues.apache.org/jira/browse/JCR-3191 > Project: Jackrabbit Content Repository > Issue Type: Improvement > Components: maven >Affects Versions: 2.3.5 >Reporter: Gustavo Orair >Priority: Trivial > Labels: dependency > Fix For: 2.5 > > Original Estimate: 0.25h > Remaining Estimate: 0.25h > > Jackrabbit may be used as JackRabbit-JCA. In many application servers we need > to change the classloading policy to "global" or "flat". These classloading > policies result in many conflicts between versions of own server > implementation or version of applications. It would be diminished if > Jackrabbit dependences are keep "up-to-date". > > commons-io > commons-io > 2.0.1 > -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (JCR-3232) Improve FileRevision extensibility
[ https://issues.apache.org/jira/browse/JCR-3232?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jukka Zitting updated JCR-3232: --- Issue Type: Improvement (was: Wish) Summary: Improve FileRevision extensibility (was: FileRevision extensibility issues) > Improve FileRevision extensibility > -- > > Key: JCR-3232 > URL: https://issues.apache.org/jira/browse/JCR-3232 > Project: Jackrabbit Content Repository > Issue Type: Improvement > Components: jackrabbit-core >Reporter: Mete Atamel >Priority: Trivial > Fix For: 2.5 > > Attachments: FileRevision.patch > > Original Estimate: 24h > Remaining Estimate: 24h > > It'd be nice to make FileRevision more extensible by chaning some of its > private variables to protected so it can be extended easier when needed. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (JCR-3316) invalid namespace URI in AbstractImportXmlTest
[ https://issues.apache.org/jira/browse/JCR-3316?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jukka Zitting updated JCR-3316: --- Affects Version/s: (was: 2.6) 2.4 Fix Version/s: 2.5 > invalid namespace URI in AbstractImportXmlTest > -- > > Key: JCR-3316 > URL: https://issues.apache.org/jira/browse/JCR-3316 > Project: Jackrabbit Content Repository > Issue Type: Bug > Components: jackrabbit-jcr-tests >Affects Versions: 2.4 >Reporter: Julian Reschke >Assignee: Julian Reschke >Priority: Trivial > Fix For: 2.5 > > > The test case uses > www.apache.org/jackrabbit/test/namespace/ImportTest > as a namespace URI, however this is not an absolute URI. > This doesn't affect the test, but it still is misleading and a bad choice for > a namespace URI. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (JCR-3270) Error instantiating lucene search index in Turkish Regional Setting
[ https://issues.apache.org/jira/browse/JCR-3270?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jukka Zitting updated JCR-3270: --- Fix Version/s: 2.5 > Error instantiating lucene search index in Turkish Regional Setting > --- > > Key: JCR-3270 > URL: https://issues.apache.org/jira/browse/JCR-3270 > Project: Jackrabbit Content Repository > Issue Type: Bug > Components: jackrabbit-core >Affects Versions: 2.2.1 >Reporter: Adrien DE GEORGES > Fix For: 2.4.1, 2.5 > > Attachments: JCR-3270.patch > > > There is an issue when changing regional setting to Turkish. > It fails when starting a repository, instantiating the lucene search index > due to the following issue : > org.apache.jackrabbit.core.config.ConfigurationException: Configured class > org.apache.jackrabbit.core.query.lucene.SearchIndex does not contain a > property named indexingConfiguration > at > org.apache.jackrabbit.core.config.BeanConfig.newInstance(BeanConfig.java > :205) > at > org.apache.jackrabbit.core.config.RepositoryConfigurationParser$1.getQue > ryHandler(RepositoryConfigurationParser.java:631) > at > org.apache.jackrabbit.core.config.RepositoryConfig.getQueryHandler(Repos > itoryConfig.java:1013) > This issue is known in java world, due to lower case conversion of 'I' > character (in Turkish locale). JackRabbit source code try to instantiate the > indexing configuration during the repository starting and is accessing > indexingConfiguration property. It instantiates a setter for this property > with a bad 'i' character. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (JCR-3236) Can not instantiate lucene Analyzer in SearchIndex
[ https://issues.apache.org/jira/browse/JCR-3236?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jukka Zitting updated JCR-3236: --- Fix Version/s: 2.5 > Can not instantiate lucene Analyzer in SearchIndex > -- > > Key: JCR-3236 > URL: https://issues.apache.org/jira/browse/JCR-3236 > Project: Jackrabbit Content Repository > Issue Type: Bug > Components: jackrabbit-core >Affects Versions: 2.4 >Reporter: YP > Assignee: Jukka Zitting > Fix For: 2.4.1, 2.5 > > > In the Lucene 3, the there is no default constructor anymore in Analyzer > classes > 11:46:45.946 [main] WARN o.a.j.core.query.lucene.SearchIndex - Invalid > Analyzer class: org.apache.lucene.analysis.standard.StandardAnalyzer > java.lang.InstantiationException: > org.apache.lucene.analysis.standard.StandardAnalyzer > at java.lang.Class.newInstance0(Class.java:340) ~[na:1.6.0_26] > at java.lang.Class.newInstance(Class.java:308) ~[na:1.6.0_26] > at > org.apache.jackrabbit.core.query.lucene.SearchIndex.setAnalyzer(SearchIndex.java:1892) > ~[jackrabbit-core-2.4.0.jar:2.4.0] > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > ~[na:1.6.0_26] > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) > ~[na:1.6.0_26] > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) > ~[na:1.6.0_26] > at java.lang.reflect.Method.invoke(Method.java:597) ~[na:1.6.0_26] > at > org.apache.jackrabbit.core.config.BeanConfig.setProperty(BeanConfig.java:255) > [jackrabbit-core-2.4.0.jar:2.4.0] > at > org.apache.jackrabbit.core.config.BeanConfig.newInstance(BeanConfig.java:203) > [jackrabbit-core-2.4.0.jar:2.4.0] > at > org.apache.jackrabbit.core.config.RepositoryConfigurationParser$1.getQueryHandler(RepositoryConfigurationParser.java:652) > [jackrabbit-core-2.4.0.jar:2.4.0] > at > org.apache.jackrabbit.core.config.WorkspaceConfig.getQueryHandler(WorkspaceConfig.java:251) > [jackrabbit-core-2.4.0.jar:2.4.0] > at > org.apache.jackrabbit.core.SearchManager.(SearchManager.java:171) > [jackrabbit-core-2.4.0.jar:2.4.0] > at > org.apache.jackrabbit.core.RepositoryImpl$WorkspaceInfo.getSearchManager(RepositoryImpl.java:1855) > [jackrabbit-core-2.4.0.jar:2.4.0] > at > org.apache.jackrabbit.core.RepositoryImpl$WorkspaceInfo.doPostInitialize(RepositoryImpl.java:2092) > [jackrabbit-core-2.4.0.jar:2.4.0] > at > org.apache.jackrabbit.core.RepositoryImpl$WorkspaceInfo.initialize(RepositoryImpl.java:1997) > [jackrabbit-core-2.4.0.jar:2.4.0] > at > org.apache.jackrabbit.core.RepositoryImpl.initStartupWorkspaces(RepositoryImpl.java:510) > [jackrabbit-core-2.4.0.jar:2.4.0] > at > org.apache.jackrabbit.core.RepositoryImpl.(RepositoryImpl.java:318) > [jackrabbit-core-2.4.0.jar:2.4.0] > at > org.apache.jackrabbit.core.RepositoryImpl.create(RepositoryImpl.java:582) > [jackrabbit-core-2.4.0.jar:2.4.0] > at > org.apache.jackrabbit.core.jndi.BindableRepository.createRepository(BindableRepository.java:141) > [jackrabbit-core-2.4.0.jar:2.4.0] > at > org.apache.jackrabbit.core.jndi.BindableRepository.init(BindableRepository.java:117) > [jackrabbit-core-2.4.0.jar:2.4.0] > at > org.apache.jackrabbit.core.jndi.BindableRepository.(BindableRepository.java:106) > [jackrabbit-core-2.4.0.jar:2.4.0] > at > org.apache.jackrabbit.core.jndi.BindableRepositoryFactory.getObjectInstance(BindableRepositoryFactory.java:52) > [jackrabbit-core-2.4.0.jar:2.4.0] -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (JCR-3317) Set the MaxTotalConnections on ConnectionManager to prevent bottleneck
[ https://issues.apache.org/jira/browse/JCR-3317?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jukka Zitting updated JCR-3317: --- Fix Version/s: 2.5 Merged to the 2.4 branch in revision 1343019. > Set the MaxTotalConnections on ConnectionManager to prevent bottleneck > -- > > Key: JCR-3317 > URL: https://issues.apache.org/jira/browse/JCR-3317 > Project: Jackrabbit Content Repository > Issue Type: Bug > Components: jackrabbit-spi2dav >Affects Versions: 2.4.1 >Reporter: Claus Köll >Assignee: Claus Köll > Fix For: 2.4.2, 2.5 > > > The changes from JCR-3026 and JCR-3027 made it possible to configure the > "org.apache.jackrabbit.spi2dav.MaxConnections". This value will be set as > DefaultMaxConnectionsPerHost on the connectionParams, but it must be also be > set as MaxTotalConnections (default is 20) -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (JCR-3262) Oracle JDBC Class Cast Exception
[ https://issues.apache.org/jira/browse/JCR-3262?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jukka Zitting updated JCR-3262: --- Fix Version/s: 2.5 > Oracle JDBC Class Cast Exception > > > Key: JCR-3262 > URL: https://issues.apache.org/jira/browse/JCR-3262 > Project: Jackrabbit Content Repository > Issue Type: Bug > Components: jackrabbit-core >Affects Versions: 2.2.11 > Environment: Windows (32-bit, 64-bit), Unix/Linux, JBoss AS 4.0.1sp1 >Reporter: Harald Scheckenbacher >Assignee: Jukka Zitting > Fix For: 2.2.12, 2.4.2, 2.5 > > > When utilizing the OraclePersistenceManager (package > org.apache.jackrabbit.core.persistence.db) (I realize this is marked as > deprecated) we noticed during our migration from Jackrabbit 1.6.1 to > 2.2.10/11 that when starting the application server an error message is > displayed to us that indicates that the Connection object passed to the > createTemporaryBlob method of the BLOB class can't be cast to > oracle.jdbc.OracleConnection > Here the interesting lines from our log: > 2012-03-15 17:15:47,926 ERROR > [org.apache.jackrabbit.core.persistence.db.OraclePersistenceManager] failed > to write node state: cafebabe-cafe-babe-cafe-babecafebabe > java.lang.ClassCastException: > org.apache.commons.dbcp.PoolingDataSource$PoolGuardConnectionWrapper cannot > be cast to oracle.jdbc.OracleConnection > at oracle.sql.BLOB.createTemporary(BLOB.java:708) > at > org.apache.jackrabbit.core.persistence.db.OraclePersistenceManager.createTemporaryBlob(OraclePersistenceManager.java:375) > I want to highlight at this point that the do not see the issue when using > the Oracle Bundled persistence manager, however due to the fact that we > haven't used the bundled version in the past we have a lot of customers with > repo layouts that can not be used by the bundled persistence manager - we ran > some tests and noticed that the consistency check fails. > -> At the moment there is no good upgrade path to move a repo to the bundled > structure, the paths provided thus far are shaky at best. > I did find a solution to the problem that has shown no issues thus far and > wanted to share this with you: > It is a one line change that can be made before the wrapped connection is > passed to the Oracle driver: > org.apache.jackrabbit.core.util.db.ConnectionFactory.unwrap(con); > This then solves the problem, I also wanted to share that we are using an XA > datasource. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (JCR-3307) JCR test org.apache.jackrabbit.test.api.version.MergeActivityTest doesn't check whether the repository supports activities
[
https://issues.apache.org/jira/browse/JCR-3307?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jukka Zitting updated JCR-3307:
---
Fix Version/s: 2.5
> JCR test org.apache.jackrabbit.test.api.version.MergeActivityTest doesn't
> check whether the repository supports activities
> --
>
> Key: JCR-3307
> URL: https://issues.apache.org/jira/browse/JCR-3307
> Project: Jackrabbit Content Repository
> Issue Type: Bug
> Components: jackrabbit-jcr-tests
>Affects Versions: 2.4.1
>Reporter: Horia Chiorean
>Assignee: Julian Reschke
> Fix For: 2.4.2, 2.5
>
>
> The test: org.apache.jackrabbit.test.api.version.MergeActivityTest, during
> setup (the initNodes method call) does not handle the case when activities
> are not supported by the repository. Therefore, if the
> versionManager.createActivity("foobar") call fails with an
> UnsupportedRepositoryOperationException, the whole test fails.
> The setup of the test should do something similar to
> org.apache.jackrabbit.test.api.version.ActivitiesTest:
> checkSupportedOption(Repository.OPTION_ACTIVITIES_SUPPORTED);
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (JCR-3158) Deadlock in DBCP when accessing node
[
https://issues.apache.org/jira/browse/JCR-3158?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jukka Zitting updated JCR-3158:
---
Fix Version/s: (was: 2.6)
2.5
> Deadlock in DBCP when accessing node
>
>
> Key: JCR-3158
> URL: https://issues.apache.org/jira/browse/JCR-3158
> Project: Jackrabbit Content Repository
> Issue Type: Bug
> Components: jackrabbit-core
>Affects Versions: 2.2.10, 2.3.3, 2.4
> Environment: Java 6
> Jackrabbit 2.2.10
> Derby
>Reporter: Tobias Mattsson
>Priority: Critical
> Fix For: 2.2.12, 2.4.1, 2.5
>
>
> I found a deadlock situation using JR 2.2.10, the problem is with DBCP 1.2.2
> and is fixed in DBCP 1.3, JR trunk also uses DBCP 1.2.2 and should also be
> updated
> The ticket in dbcp is #DBCP-270, related tickets are #DBCP-65 #DBCP-281
> #DBCP-271
> Stack trace of where my call is stalled:
> {code}
> main@1, prio=5, in group 'main', status: 'MONITOR'
>blocks Timer-1@2545
>waiting for Timer-1@2545 to release lock on {1}
> at
> org.apache.commons.pool.impl.GenericObjectPool.addObjectToPool(GenericObjectPool.java:1137)
> at
> org.apache.commons.pool.impl.GenericObjectPool.returnObject(GenericObjectPool.java:1076)
> at
> org.apache.commons.dbcp.PoolableConnection.close(PoolableConnection.java:87)
> at
> org.apache.commons.dbcp.PoolingDataSource$PoolGuardConnectionWrapper.close(PoolingDataSource.java:181)
> at
> org.apache.jackrabbit.core.util.db.DbUtility.close(DbUtility.java:75)
> at
> org.apache.jackrabbit.core.util.db.ResultSetWrapper.invoke(ResultSetWrapper.java:63)
> at $Proxy12.close(Unknown Source:-1)
> at
> org.apache.jackrabbit.core.persistence.pool.BundleDbPersistenceManager.loadBundle(BundleDbPersistenceManager.java:1042)
> at
> org.apache.jackrabbit.core.persistence.bundle.AbstractBundlePersistenceManager.getBundle(AbstractBundlePersistenceManager.java:669)
> at
> org.apache.jackrabbit.core.persistence.bundle.AbstractBundlePersistenceManager.load(AbstractBundlePersistenceManager.java:415)
> at
> org.apache.jackrabbit.core.state.SharedItemStateManager.loadItemState(SharedItemStateManager.java:1830)
> at
> org.apache.jackrabbit.core.state.SharedItemStateManager.getNonVirtualItemState(SharedItemStateManager.java:1750)
> at
> org.apache.jackrabbit.core.state.SharedItemStateManager.getItemState(SharedItemStateManager.java:265)
> at
> org.apache.jackrabbit.core.state.LocalItemStateManager.getNodeState(LocalItemStateManager.java:109)
> at
> org.apache.jackrabbit.core.state.LocalItemStateManager.getItemState(LocalItemStateManager.java:174)
> at
> org.apache.jackrabbit.core.state.XAItemStateManager.getItemState(XAItemStateManager.java:260)
> at
> org.apache.jackrabbit.core.state.SessionItemStateManager.getItemState(SessionItemStateManager.java:161)
> at
> org.apache.jackrabbit.core.ItemManager.getItemData(ItemManager.java:382)
> at
> org.apache.jackrabbit.core.ItemManager.getNode(ItemManager.java:669)
> at
> org.apache.jackrabbit.core.ItemManager.getNode(ItemManager.java:647)
> at
> org.apache.jackrabbit.core.LazyItemIterator.prefetchNext(LazyItemIterator.java:120)
> at
> org.apache.jackrabbit.core.LazyItemIterator.next(LazyItemIterator.java:257)
> at
> info.magnolia.jcr.iterator.DelegatingNodeIterator.next(DelegatingNodeIterator.java:79)
> {code}
> This is the offending thread:
> {code}
> Timer-1@2545 daemon, prio=5, in group 'main', status: 'MONITOR'
>blocks main@1
>waiting for main@1 to release lock on {1}
> at
> org.apache.commons.dbcp.AbandonedTrace.addTrace(AbandonedTrace.java:176)
> at org.apache.commons.dbcp.AbandonedTrace.init(AbandonedTrace.java:92)
> at
> org.apache.commons.dbcp.AbandonedTrace.(AbandonedTrace.java:82)
> at
> org.apache.commons.dbcp.DelegatingStatement.(DelegatingStatement.java:61)
> at
> org.apache.commons.dbcp.DelegatingConnection.createStatement(DelegatingConnection.java:224)
> at
> org.apache.commons.dbcp.PoolableConnectionFactory.validateConnection(PoolableConnectionFactory.java:331)
> at
> org.apache.commons.dbcp.PoolableConnectionFactory.validateObject(PoolableConnectionFactory.java:312)
> at
> org.apache.commons.pool.impl.GenericObjectPool.evict(GenericObjectPool.java:1217)
> at
&g
[jira] [Updated] (JCR-2662) JCR unit tests for journaled observation do not check capabilities and require implementation, contrary to JCR 2.0 specification
[ https://issues.apache.org/jira/browse/JCR-2662?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jukka Zitting updated JCR-2662: --- Fix Version/s: (was: 2.6) 2.5 > JCR unit tests for journaled observation do not check capabilities and > require implementation, contrary to JCR 2.0 specification > > > Key: JCR-2662 > URL: https://issues.apache.org/jira/browse/JCR-2662 > Project: Jackrabbit Content Repository > Issue Type: Bug > Components: jackrabbit-jcr-tests, JCR 2.0 >Affects Versions: 2.4 >Reporter: Randall Hauch >Assignee: Julian Reschke > Fix For: 2.4.2, 2.5 > > Attachments: JCR-2662.patch > > > The org.apache.jackrabbit.test.api.observation.EventJournalTest class obtains > the EventJournal from the observation manager, but does not check the > capabilities of the JCR implementation before running these tests. > Therefore, these tests always fail when run against any implementation that > chooses not to implement the _optional_ journaled observation feature. > Per the second paragraph in chapter 12 of the JCR 2.0 specification, any > implementation that does support journaled observation should have in its > descriptors a value of "true" for the > Repository.OPTION_JOURNALED_OBSERVATION_SUPPORTED key. See [1] > The EventJournalTest methods should check this value and skip their tests, or > simply check that the two ObservationManager.getEventJournal(...) methods do > return null references if the feature is not supported (per the JavaDoc, see > [2] and [3]). > [1] http://www.day.com/specs/jcr/2.0/12_Observation.html > [2] > http://www.day.com/maven/javax.jcr/javadocs/jcr-2.0/javax/jcr/observation/ObservationManager.html#getEventJournal() > [3] > http://www.day.com/maven/javax.jcr/javadocs/jcr-2.0/javax/jcr/observation/ObservationManager.html#getEventJournal(int,%20java.lang.String,%20boolean,%20java.lang.String[],%20java.lang.String[]) -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (JCR-3181) add test case for recovering from broken version history hierarchy
[ https://issues.apache.org/jira/browse/JCR-3181?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jukka Zitting updated JCR-3181: --- Fix Version/s: (was: 2.6) 2.5 > add test case for recovering from broken version history hierarchy > -- > > Key: JCR-3181 > URL: https://issues.apache.org/jira/browse/JCR-3181 > Project: Jackrabbit Content Repository > Issue Type: Improvement > Components: jackrabbit-core, versioning >Affects Versions: 2.4 >Reporter: Julian Reschke >Assignee: Julian Reschke >Priority: Minor > Fix For: 2.5 > > > The test should exercise recovery from a missing parent node of a VHR. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (JCR-3192) Javadoc in jackrabbit-jcr-rmi is missing an ending ">"
[ https://issues.apache.org/jira/browse/JCR-3192?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jukka Zitting updated JCR-3192: --- Fix Version/s: (was: 2.6) 2.5 > Javadoc in jackrabbit-jcr-rmi is missing an ending ">" > --- > > Key: JCR-3192 > URL: https://issues.apache.org/jira/browse/JCR-3192 > Project: Jackrabbit Content Repository > Issue Type: Bug > Components: jackrabbit-jcr-rmi >Affects Versions: 2.3.5 >Reporter: Pontus Amberg >Priority: Trivial > Fix For: 2.5 > > Original Estimate: 1m > Remaining Estimate: 1m > > The javadoc file > /jackrabbit-jcr-rmi/src/main/javadoc/apache/rmi/observation/package.html is > missing the final ">" from the ending body tag. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (JCR-3212) add TCK test for Info map of NODE_MOVED event on node reordering
[ https://issues.apache.org/jira/browse/JCR-3212?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jukka Zitting updated JCR-3212: --- Fix Version/s: (was: 2.6) 2.5 > add TCK test for Info map of NODE_MOVED event on node reordering > > > Key: JCR-3212 > URL: https://issues.apache.org/jira/browse/JCR-3212 > Project: Jackrabbit Content Repository > Issue Type: Sub-task > Components: jackrabbit-jcr-tests, observation >Reporter: Julian Reschke >Assignee: Julian Reschke >Priority: Minor > Fix For: 2.5 > > > add the TCK test for this problem, and mark this as known test failure for now -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (JCR-3209) lock token validity
[ https://issues.apache.org/jira/browse/JCR-3209?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jukka Zitting updated JCR-3209: --- Fix Version/s: (was: 2.6) 2.5 > lock token validity > --- > > Key: JCR-3209 > URL: https://issues.apache.org/jira/browse/JCR-3209 > Project: Jackrabbit Content Repository > Issue Type: Improvement > Components: jackrabbit-jcr-server, jackrabbit-spi2dav, locks >Reporter: Julian Reschke >Assignee: Julian Reschke >Priority: Minor > Fix For: 2.5 > > Attachments: JCR-3209.diff > > > There are several minor issues in the mapping between JCR lock tokens and > WebDAV lock tokens: > 1) WebDAV lock tokens are supposed to use URI syntax (such as > opaquelocktoken: or urn:uuid:) > 2) The server currently computes lock tokens for session-scoped locks based > on the node id; these are not valid JCR lock tokens though and cause > exceptions when they are re-added when they appear in a Lock-Token header or > an If header. This will likely cause requests to fail that use both types of > locks (yes, maybe academic but should be fixed anyway) > Proposal: > a) Map lock tokens to oqaquelocktoken URIs, using a constant UUID plus a > postfix encoding the original lock token > b) Use a syntax that allows to distinguish between tokens for open-scoped > locks or session-scoped locks, so that we do not try to add the latter type > to the Session (alternatively, handle exceptions doing so gracefully) -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (JCR-3191) I would like to update commons-io dependency from versiom 1.4 to 2.0.1
[ https://issues.apache.org/jira/browse/JCR-3191?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jukka Zitting updated JCR-3191: --- Fix Version/s: (was: 2.6) 2.5 > I would like to update commons-io dependency from versiom 1.4 to 2.0.1 > --- > > Key: JCR-3191 > URL: https://issues.apache.org/jira/browse/JCR-3191 > Project: Jackrabbit Content Repository > Issue Type: Wish > Components: maven >Affects Versions: 2.3.5 >Reporter: Gustavo Orair >Priority: Trivial > Labels: dependency > Fix For: 2.5 > > Original Estimate: 0.25h > Remaining Estimate: 0.25h > > Jackrabbit may be used as JackRabbit-JCA. In many application servers we need > to change the classloading policy to "global" or "flat". These classloading > policies result in many conflicts between versions of own server > implementation or version of applications. It would be diminished if > Jackrabbit dependences are keep "up-to-date". > > commons-io > commons-io > 2.0.1 > -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (JCR-3227) VolatileIndex not closed properly
[ https://issues.apache.org/jira/browse/JCR-3227?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jukka Zitting updated JCR-3227: --- Fix Version/s: (was: 2.6) 2.5 > VolatileIndex not closed properly > - > > Key: JCR-3227 > URL: https://issues.apache.org/jira/browse/JCR-3227 > Project: Jackrabbit Content Repository > Issue Type: Bug > Components: jackrabbit-core >Affects Versions: 2.4 > Reporter: Jukka Zitting >Priority: Minor > Fix For: 2.4.1, 2.5 > > Attachments: JCR-3227.patch > > > The MultiIndex.resetVolatileIndex() method doesn't properly close the > existing VolatileIndex instance before creating a new one. This can confuse > the DynamicPooledExecutor reference count added in JCR-2836, leading to a > background thread leak. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (JCR-3233) Provide callback for consistency checker
[ https://issues.apache.org/jira/browse/JCR-3233?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jukka Zitting updated JCR-3233: --- Fix Version/s: (was: 2.6) 2.5 > Provide callback for consistency checker > > > Key: JCR-3233 > URL: https://issues.apache.org/jira/browse/JCR-3233 > Project: Jackrabbit Content Repository > Issue Type: New Feature > Components: jackrabbit-core >Reporter: Martin Böttcher >Assignee: Julian Reschke > Fix For: 2.4.2, 2.5 > > Attachments: 3233.diff > > > Allow caller to specify a listener that will be called for each node being > checked. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (JCR-3254) make max size of CachingEntryCollector's cache configurable
[ https://issues.apache.org/jira/browse/JCR-3254?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jukka Zitting updated JCR-3254: --- Fix Version/s: (was: 2.6) 2.5 > make max size of CachingEntryCollector's cache configurable > --- > > Key: JCR-3254 > URL: https://issues.apache.org/jira/browse/JCR-3254 > Project: Jackrabbit Content Repository > Issue Type: Sub-task > Components: jackrabbit-core >Affects Versions: 2.2.11, 2.4 >Reporter: Julian Reschke >Assignee: Julian Reschke >Priority: Minor > Fix For: 2.2.12, 2.4.1, 2.5 > > > To assist in analyzing the bottleneck it would be good if it was easy to > change the max size, currently hard-wired to 5000. Suggest to be pragmatic > and do that through a system property. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (JCR-3255) Access cluster node id
[ https://issues.apache.org/jira/browse/JCR-3255?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jukka Zitting updated JCR-3255: --- Fix Version/s: (was: 2.6) 2.5 > Access cluster node id > -- > > Key: JCR-3255 > URL: https://issues.apache.org/jira/browse/JCR-3255 > Project: Jackrabbit Content Repository > Issue Type: New Feature >Reporter: Unico Hommes >Assignee: Bart van der Schans >Priority: Minor > Fix For: 2.2.12, 2.4.1, 2.5 > > Attachments: RepositoryConfigurationParser.patch > > > I need to know the cluster node id in my application. I didn't find any other > way than to cast to org.apache.jackrabbit.core.RepositoryImpl : > ((RepositoryImpl) > session.getRepository()).getConfig().getClusterConfig().getId() > I would appreciate it if I could get to this using the system property > ClusterNode.SYSTEM_PROPERTY_NODE_ID. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (JCR-3234) QueryStat getPopularQueries doesn't set the proper position
[ https://issues.apache.org/jira/browse/JCR-3234?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jukka Zitting updated JCR-3234: --- Fix Version/s: (was: 2.6) 2.5 > QueryStat getPopularQueries doesn't set the proper position > --- > > Key: JCR-3234 > URL: https://issues.apache.org/jira/browse/JCR-3234 > Project: Jackrabbit Content Repository > Issue Type: Bug > Components: jackrabbit-core >Reporter: Alex Parvulescu >Assignee: Alex Parvulescu >Priority: Trivial > Fix For: 2.4.2, 2.5 > > > Embarrassing copy/paste error. I was updating the wrong array and the > position info was never returned. > This made any jmx client to fail with: > at > javax.management.openmbean.TabularDataSupport.checkValueAndIndex(TabularDataSupport.java:871) > > at > javax.management.openmbean.TabularDataSupport.internalPut(TabularDataSupport.java:331) > > at > javax.management.openmbean.TabularDataSupport.put(TabularDataSupport.java:323) > > at > org.apache.jackrabbit.core.jmx.QueryStatManager.asTabularData(QueryStatManager.java:103) -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (JCR-3250) webapp welcome page shows incorrect port when port is the default port
[ https://issues.apache.org/jira/browse/JCR-3250?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jukka Zitting updated JCR-3250: --- Affects Version/s: (was: 2.6) Fix Version/s: (was: 2.6) 2.5 > webapp welcome page shows incorrect port when port is the default port > -- > > Key: JCR-3250 > URL: https://issues.apache.org/jira/browse/JCR-3250 > Project: Jackrabbit Content Repository > Issue Type: Bug > Components: jackrabbit-webapp >Affects Versions: 2.4.1 >Reporter: Julian Reschke >Assignee: Julian Reschke >Priority: Minor > Fix For: 2.4.1, 2.5 > > > See summary. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (JCR-3253) Set omit term freq positions flag on parent field in the index
[ https://issues.apache.org/jira/browse/JCR-3253?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jukka Zitting updated JCR-3253: --- Fix Version/s: (was: 2.6) 2.5 > Set omit term freq positions flag on parent field in the index > -- > > Key: JCR-3253 > URL: https://issues.apache.org/jira/browse/JCR-3253 > Project: Jackrabbit Content Repository > Issue Type: Improvement > Components: indexing >Reporter: Alex Parvulescu >Assignee: Alex Parvulescu > Fix For: 2.5 > > > The flag to omit term frequencies is set to true by default and it is not > changed by any of the constructors on the Field class. > We don't use this info in the index anyway, so it is safe to remove it. > The index size gain for 130K nodes (3 leves, ~50 nodes per level) is around > 150kb for a 30mb index. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (JCR-3259) augment logging information around CachingEntryCollector
[ https://issues.apache.org/jira/browse/JCR-3259?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jukka Zitting updated JCR-3259: --- Fix Version/s: (was: 2.6) 2.5 > augment logging information around CachingEntryCollector > > > Key: JCR-3259 > URL: https://issues.apache.org/jira/browse/JCR-3259 > Project: Jackrabbit Content Repository > Issue Type: Sub-task > Components: jackrabbit-core >Reporter: Julian Reschke >Assignee: Julian Reschke >Priority: Minor > Fix For: 2.2.12, 2.4.1, 2.5 > > Attachments: JCR-3259.diff > > > add more logging information for the purpose of debugging > CachingEntryCollector bottlenecks -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (JCR-3237) add missing name constants for mix:title
[ https://issues.apache.org/jira/browse/JCR-3237?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jukka Zitting updated JCR-3237: --- Affects Version/s: (was: 2.6) Fix Version/s: (was: 2.6) 2.5 > add missing name constants for mix:title > > > Key: JCR-3237 > URL: https://issues.apache.org/jira/browse/JCR-3237 > Project: Jackrabbit Content Repository > Issue Type: Improvement > Components: jackrabbit-spi-commons, JCR 2.0 >Affects Versions: 2.4.1 >Reporter: Julian Reschke >Assignee: Julian Reschke >Priority: Minor > Fix For: 2.4.1, 2.5 > > -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (JCR-3261) Problems with BundleDbPersistenceManager getAllNodeIds
[
https://issues.apache.org/jira/browse/JCR-3261?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jukka Zitting updated JCR-3261:
---
Fix Version/s: (was: 2.6)
2.5
> Problems with BundleDbPersistenceManager getAllNodeIds
> --
>
> Key: JCR-3261
> URL: https://issues.apache.org/jira/browse/JCR-3261
> Project: Jackrabbit Content Repository
> Issue Type: Bug
>Affects Versions: 2.4
>Reporter: Unico Hommes
>Assignee: Bart van der Schans
> Fix For: 2.4.1, 2.5
>
> Attachments: bdbpm_allids.patch
>
>
> When using MySQL:
> The problem arises when the method parameter maxcount is less than the total
> amount of records in the bundle table.
> First of all I found out that mysql orders the nodeid objects different than
> jackrabbit does. The following test describes this idea:
> public void testMySQLOrderByNodeId() throws Exception {
> NodeId nodeId1 = new NodeId("7ff9e87c-f87f-4d35-9d61-2e298e56ac37");
> NodeId nodeId2 = new NodeId("9fd0d452-b5d0-426b-8a0f-bef830ba0495");
> PreparedStatement stmt = connection.prepareStatement("SELECT NODE_ID
> FROM DEFAULT_BUNDLE WHERE NODE_ID = ? OR NODE_ID = ? ORDER BY NODE_ID");
> Object[] params = new Object[] { nodeId1.getRawBytes(),
> nodeId2.getRawBytes() };
> stmt.setObject(1, params[0]);
> stmt.setObject(2, params[1]);
> ArrayList nodeIds = new ArrayList();
> ResultSet resultSet = stmt.executeQuery();
> while(resultSet.next()) {
> NodeId nodeId = new NodeId(resultSet.getBytes(1));
> System.out.println(nodeId);
> nodeIds.add(nodeId);
> }
> Collections.sort(nodeIds);
> for (NodeId nodeId : nodeIds) {
> System.out.println(nodeId);
> }
> }
> Which results in the following output:
> 7ff9e87c-f87f-4d35-9d61-2e298e56ac37
> 9fd0d452-b5d0-426b-8a0f-bef830ba0495
> 9fd0d452-b5d0-426b-8a0f-bef830ba0495
> 7ff9e87c-f87f-4d35-9d61-2e298e56ac37
> Now the problem with the getAllNodeIds method is that it fetches an extra 10
> records on top of maxcount (to avoid a problem where the first key is not the
> one you that is wanted). Afterwards it skips a number of records again, this
> time using nodeid.compareto. This compareto statement returns true
> unexpectedly for mysql because the code doesn't expect the mysql ordering.
> I had the situation where I had about 17000 records in the bundle table but
> consecutively getting the ids a thousand records at a time returned only
> about 8000 records in all.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (JCR-3280) SQL2 joins on empty sets are not efficient
[ https://issues.apache.org/jira/browse/JCR-3280?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jukka Zitting updated JCR-3280: --- Fix Version/s: (was: 2.6) 2.5 > SQL2 joins on empty sets are not efficient > -- > > Key: JCR-3280 > URL: https://issues.apache.org/jira/browse/JCR-3280 > Project: Jackrabbit Content Repository > Issue Type: Improvement >Reporter: Alex Parvulescu >Assignee: Alex Parvulescu > Fix For: 2.4.1, 2.5 > > Attachments: JCR-3280.patch > > > It seems that in the cases where the LEFT side of the join doesn't contain > any hits, the QueryEngine in unable to generate an efficient query for the > RIGHT side, so it basically select all the possible nodes. > See this discussion as context [0]. > Example: > LEFT side has hits, RIGHT side select is fast given some conditions: > > SQL2 JOIN LEFT SIDE took 18 ms. fetched 145 rows. > > SQL2 JOIN RIGHT SIDE took 67 ms. fetched 0 rows. > LEFT side has no hits, RIGHT select everything > > SQL2 JOIN LEFT SIDE took 8 ms. fetched 0 rows. > > SQL2 JOIN RIGHT SIDE took 845 ms. fetched 13055 rows. > ...so it fetches 130k nodes and doesn't keep any of them. > [0] > http://jackrabbit.510166.n4.nabble.com/Strange-Search-Performance-problem-with-OR-td4507121.html -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (JCR-3266) JCR-SQL2 query with multiple columns in result only returns last column when using Row.getValues()
[
https://issues.apache.org/jira/browse/JCR-3266?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jukka Zitting updated JCR-3266:
---
Fix Version/s: (was: 2.6)
2.5
> JCR-SQL2 query with multiple columns in result only returns last column when
> using Row.getValues()
> --
>
> Key: JCR-3266
> URL: https://issues.apache.org/jira/browse/JCR-3266
> Project: Jackrabbit Content Repository
> Issue Type: Bug
>Affects Versions: 2.2.4, 2.4
>Reporter: Nick Tuckett
>Assignee: Julian Reschke
> Fix For: 2.2.12, 2.4.1, 2.5
>
>
> When running a query like below on an in-process repository (via
> TransientRepository) or via RMI access, a call to Row.getValues() only
> returns the last column selected:
>SELECT property1, property2 FROM [nodetype]
> QueryResult.getColumnNames() returns the right set of columns.
> Stepping through the code shows that
> org.apache.jackrabbit.core.query.lucene.join.AbstractRow has the
> implementation of getValues() - this creates a new Values array, then
> overwrites it multiple times in a for loop that iterates once per column.
> That doesn't sound like the desired behaviour.
> Getting values via individual calls to Row.getValue("property1") gives the
> correct results.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (JCR-3289) Remove operation right after move operation causes missing child inconsistency
[ https://issues.apache.org/jira/browse/JCR-3289?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jukka Zitting updated JCR-3289: --- Fix Version/s: (was: 2.6) 2.5 > Remove operation right after move operation causes missing child inconsistency > -- > > Key: JCR-3289 > URL: https://issues.apache.org/jira/browse/JCR-3289 > Project: Jackrabbit Content Repository > Issue Type: Bug >Affects Versions: 2.2.11, 2.4 >Reporter: Unico Hommes >Assignee: Bart van der Schans >Priority: Critical > Fix For: 2.2.12, 2.4.2, 2.5 > > Attachments: ItemSaveOperation.patch, MoveRemoveTest.patch > > > The scenario is as follows: > 1. Session s1 does a move operation on node /folder1/node to destination > /folder2/node > 2. Session s2 does a remove operation on node /folder1/node > 3. Session s1 is saved > 4. Session s2 is saved > A consistency check shows that /folder2 has a child node entry for inexistent > child node node. > The problem is that step 4. should fail whereas it doesn't. > This is caused by the fact that the ItemSaveOperation.removeTransientItems > puts the overlayed state of the transient state in the changelog instead of > the transient state itself. But the overlayed state has the updated modcount > of the previous move operation. Therefore when the shared item state manager > persists the changelog it doesn't detect that the remove was done on a stale > item and so the update can succeed. > Attached is a patch containing a testcase that reproduces the inconsistency > with this scenario. > Another patch is for the ItemSaveOperation class which fixes the issue. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (JCR-3268) Re-index fails on corrupt bundle
[ https://issues.apache.org/jira/browse/JCR-3268?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jukka Zitting updated JCR-3268: --- Fix Version/s: (was: 2.6) 2.5 > Re-index fails on corrupt bundle > > > Key: JCR-3268 > URL: https://issues.apache.org/jira/browse/JCR-3268 > Project: Jackrabbit Content Repository > Issue Type: Bug > Components: indexing, jackrabbit-core >Reporter: Alex Parvulescu >Assignee: Alex Parvulescu > Fix For: 2.4.1, 2.5 > > > The re-indexing process should be more resilient, log an error and simply > continue with the next node. It doesn't seem useful to refuse repository > startup in this case. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (JCR-3282) Optimize usage of norms
[ https://issues.apache.org/jira/browse/JCR-3282?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jukka Zitting updated JCR-3282: --- Fix Version/s: (was: 2.6) 2.5 > Optimize usage of norms > --- > > Key: JCR-3282 > URL: https://issues.apache.org/jira/browse/JCR-3282 > Project: Jackrabbit Content Repository > Issue Type: Improvement > Components: indexing, jackrabbit-core >Reporter: Alex Parvulescu >Assignee: Alex Parvulescu > Fix For: 2.5 > > Attachments: JCR-3282.patch > > > There is a very significant potential for optimizing the size of the search > index. > We have seen a case where there were multiple segments with about the same > number of nodes (roughly 10 million), but the size on disk was very different. > One segment was 19 GB while all others where around 3 GB. The major > difference was the number of fields indexed. The large segment had > significantly more fields, which resulted in a large norms file. > We should go through our implementation and see where norms are really > necessary and disable tracking of norms wherever possible. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (JCR-3286) InternalVersionManagerBase.calculateCheckinVersionName will fail with NPE upon empty predecessors property
[ https://issues.apache.org/jira/browse/JCR-3286?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jukka Zitting updated JCR-3286: --- Affects Version/s: (was: 2.6) Fix Version/s: (was: 2.6) 2.5 > InternalVersionManagerBase.calculateCheckinVersionName will fail with NPE > upon empty predecessors property > -- > > Key: JCR-3286 > URL: https://issues.apache.org/jira/browse/JCR-3286 > Project: Jackrabbit Content Repository > Issue Type: Improvement > Components: jackrabbit-core, versioning >Affects Versions: 2.2.11, 2.4 >Reporter: Julian Reschke >Assignee: Julian Reschke >Priority: Trivial > Fix For: 2.2.12, 2.4.2, 2.5 > > > (Note: this can only happen on inconsistent version storage) > We should add a check here, and throw a more descriptive exception. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (JCR-3292) Workspace move in concurrent environment causes inconsistencies
[ https://issues.apache.org/jira/browse/JCR-3292?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jukka Zitting updated JCR-3292: --- Fix Version/s: (was: 2.6) 2.5 > Workspace move in concurrent environment causes inconsistencies > --- > > Key: JCR-3292 > URL: https://issues.apache.org/jira/browse/JCR-3292 > Project: Jackrabbit Content Repository > Issue Type: Bug >Affects Versions: 2.2.11, 2.4 >Reporter: Unico Hommes >Assignee: Bart van der Schans > Fix For: 2.2.12, 2.4.2, 2.5 > > Attachments: JCR-3292.patch, WorkspaceMoveTest.patch > > > Attached is a test case that shows that using workspace move concurrent with > other write operations causes inconsistencies. > The problem is that unlike session move, workspace move operates on the local > item state directly (session move operates on transient item state). When a > concurrent modification occurs on for instance the source parent of the moved > target the modification that the move operation was trying to do is > overwritten as the changes from the concurrent session are pulled in: > - on thread 1 a workspace.move is initiated on /folder1/node to > /folder2/node, removing the child node entry from /folder1 a.o.t. > - session 2 on thread 2 modifies and saves /folder1, overwriting the changes > on the local item state of /folder1 in session 1 > - thread 1, still in the workspace move operation, sends the updates to the > shared item state manager -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (JCR-3290) Concurrent add and move can cause inconsistency
[ https://issues.apache.org/jira/browse/JCR-3290?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jukka Zitting updated JCR-3290: --- Fix Version/s: (was: 2.6) 2.5 > Concurrent add and move can cause inconsistency > --- > > Key: JCR-3290 > URL: https://issues.apache.org/jira/browse/JCR-3290 > Project: Jackrabbit Content Repository > Issue Type: Bug >Affects Versions: 2.2.11, 2.4 >Reporter: Unico Hommes >Assignee: Bart van der Schans >Priority: Critical > Fix For: 2.2.12, 2.4.2, 2.5 > > Attachments: AddMoveTest.patch, SISMMerger.patch > > > The scenario is as follows: > We start out with the following repository structure: > /folder1/node1 > /folder2 > Session s1 modifies /folder1 (for instance set a property or add a node, it > doesn't matter, as long as it creates a transient item state for /folder1) > Session s2 moves /folder1/node1 to /folder2/node1 > Session s2 does a save > Session s1 modifies /folder2/node1 (for instance set a property or add a > node, it doesn't matter, as long as it creates a transient item state for > node2) > Session s1 does a save > The repository is now inconsistent: /folder1 has a child node entry for node1 > whereas node1 has parent id for /folder2 > The problem is in the NodeStateMerger.merge method. When on s1.save a merge > is attempted on the child node entries of /folder1 the transient state has a > child node entry for node1 (which was actually moved to /folder2). This > expected. The merger decides to add this node if one of two conditions is > true: the child node entry is either in the added set of the change log or it > is in the modified set of the change log (the latter because the child node > will be in the modified set if it was moved to this node). The latter > condition is the problem. Because node1 was modified it is indeed in the > modified set and thus added. > However it has a different parent id (the parent id of the folder it was > moved to). That means that /folder1 is saved with a child node entry for > node1. > Attached is a test case that shows that the above scenario leads to an > inconsistency. > Also attached is a proposal for a fix. The fix checks whether the child node > entry to be added actually has the state that is currently being merged as > its parent and only adds it when it does. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (JCR-3291) Stack overflow in multi-session test with moves
[ https://issues.apache.org/jira/browse/JCR-3291?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jukka Zitting updated JCR-3291: --- Fix Version/s: (was: 2.6) 2.5 > Stack overflow in multi-session test with moves > --- > > Key: JCR-3291 > URL: https://issues.apache.org/jira/browse/JCR-3291 > Project: Jackrabbit Content Repository > Issue Type: Bug > Components: jackrabbit-core >Reporter: Frank van Lankvelt >Assignee: Bart van der Schans > Fix For: 2.2.12, 2.4.2, 2.5 > > Attachments: JCR-3291-test.patch, JCR-3291.patch > > > When two sessions move nodes in incompatible ways (see test), the hierarchy > manager can get into an infinite recursion when building paths. > Setup: nodes /a/aa & /b. > // results in /b/a/aa > session1.move(testRootPath + "/a", testRootPath + "/b/a"); > // results in aa/b/aa/b/aa/b/aa/etc. > session2.move(testRootPath + "/b", testRootPath + "/a/aa/b"); > session1.save(); > session2.save(); > The problem arises when the hierarchy manager uses a mix of transient states > and unmodified states managed by the local item state manager. > When session 1 is saved, the state change of node a is dispatched to session > 2. Node "a" is not changed in session 2, so it's new shared state will be > used as-is. > It will have parent "b" according to the hierarchy manager in session 2. > The proposed solution is to keep track of the nodes that have been used in > building up the path. This has the downside that building up paths becomes > more expensive. > I haven't done any performance measurements yet on the impact of the change. > If performance is an issue, perhaps the implementation can be limited to the > case that the consistencyCheckEnabled flag is set. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (JCR-3312) AbstractSession.getItem should deal with identifier paths
[
https://issues.apache.org/jira/browse/JCR-3312?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jukka Zitting updated JCR-3312:
---
Fix Version/s: (was: 2.6)
2.5
> AbstractSession.getItem should deal with identifier paths
> -
>
> Key: JCR-3312
> URL: https://issues.apache.org/jira/browse/JCR-3312
> Project: Jackrabbit Content Repository
> Issue Type: Bug
> Components: jackrabbit-jcr-commons
>Reporter: Julian Reschke
>Assignee: Julian Reschke
> Fix For: 2.5
>
>
> In OAK's SessionImpl, we currently do:
> @Override
> public Item getItem(String absPath) throws PathNotFoundException,
> RepositoryException {
> if (absPath.startsWith("[") && absPath.endsWith("]")) {
> // TODO OAK-23 - maybe this code should be added in
> AbstractSession
> return getNodeByIdentifier(absPath.substring(1, absPath.length()
> - 1));
> } else {
> return super.getItem(absPath);
> }
> }
> AbstractSession could do this on it's own.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (JCR-3296) Indexing ignored file types creates some garbage
[ https://issues.apache.org/jira/browse/JCR-3296?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jukka Zitting updated JCR-3296: --- Fix Version/s: (was: 2.6) 2.5 > Indexing ignored file types creates some garbage > > > Key: JCR-3296 > URL: https://issues.apache.org/jira/browse/JCR-3296 > Project: Jackrabbit Content Repository > Issue Type: Improvement > Components: jackrabbit-core >Reporter: Alex Parvulescu >Assignee: Alex Parvulescu >Priority: Minor > Fix For: 2.5 > > > The lucene index entries for file types that should not be indexed has 5 > extra newline characters in the :FULLTEXT field that should have been empty. > Did a little pair programming with Jukka, fix will follow shortly. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (JCR-3300) tests should consistently check for repository support and fail with NotExecutableException when the repo does not support the feature
[ https://issues.apache.org/jira/browse/JCR-3300?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jukka Zitting updated JCR-3300: --- Fix Version/s: (was: 2.6) > tests should consistently check for repository support and fail with > NotExecutableException when the repo does not support the feature > -- > > Key: JCR-3300 > URL: https://issues.apache.org/jira/browse/JCR-3300 > Project: Jackrabbit Content Repository > Issue Type: Bug > Components: jackrabbit-jcr-tests >Affects Versions: 2.4.1, 2.6 >Reporter: Julian Reschke >Assignee: Julian Reschke >Priority: Minor > Fix For: 2.4.2, 2.5 > > > AbstractVersionTest should check for Repository.OPTION_VERSIONING_SUPPORTED > and throw NotExecutableException when not set > RSessionAccessControlTest needs to extend from AbstractAccessControlTest > instead of AbstractJCRTest > etc. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (JCR-3298) jackrabbit-core RepositoryChecker.fix() can fail with OOM
[ https://issues.apache.org/jira/browse/JCR-3298?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jukka Zitting updated JCR-3298: --- Fix Version/s: (was: 2.6) 2.5 > jackrabbit-core RepositoryChecker.fix() can fail with OOM > - > > Key: JCR-3298 > URL: https://issues.apache.org/jira/browse/JCR-3298 > Project: Jackrabbit Content Repository > Issue Type: Bug > Components: jackrabbit-core >Affects Versions: 2.2.11, 2.4, 2.6 >Reporter: Julian Reschke >Assignee: Julian Reschke > Fix For: 2.2.12, 2.4.2, 2.5 > > Attachments: JCR-3298.patch > > > It appears that people are (ab)using the RepositoryChecker to fix the > versioning information in their repo after *removing* the version storage. > (It would be good to understand why this happens, but anyway...) > The RepositoryChecker, as currently implemented, walks the repository, > collects changes, and, when done, submits them as a single repository > ChangeLog. > This will not work if the number of affected nodes is big. > Unfortunately, the checker is currently designed to do things to two steps; > we could of course stop collecting changes after a threshold, then apply what > we have, then re-run the checker. That would probably work, but would be slow > on huge repositories. > The best alternative I see is to add a checkAndFix() method that is allowed > to apply ChangeLogs to the repository on the run (and of course to use that > variant from within RepositoryImpl.doVersionRecovery()). -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (JCR-3300) tests should consistently check for repository support and fail with NotExecutableException when the repo does not support the feature
[ https://issues.apache.org/jira/browse/JCR-3300?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jukka Zitting updated JCR-3300: --- Fix Version/s: 2.5 > tests should consistently check for repository support and fail with > NotExecutableException when the repo does not support the feature > -- > > Key: JCR-3300 > URL: https://issues.apache.org/jira/browse/JCR-3300 > Project: Jackrabbit Content Repository > Issue Type: Bug > Components: jackrabbit-jcr-tests >Affects Versions: 2.4.1, 2.6 >Reporter: Julian Reschke >Assignee: Julian Reschke >Priority: Minor > Fix For: 2.4.2, 2.5 > > > AbstractVersionTest should check for Repository.OPTION_VERSIONING_SUPPORTED > and throw NotExecutableException when not set > RSessionAccessControlTest needs to extend from AbstractAccessControlTest > instead of AbstractJCRTest > etc. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (JCR-3307) JCR test org.apache.jackrabbit.test.api.version.MergeActivityTest doesn't check whether the repository supports activities
[
https://issues.apache.org/jira/browse/JCR-3307?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jukka Zitting updated JCR-3307:
---
Fix Version/s: (was: 2.6)
> JCR test org.apache.jackrabbit.test.api.version.MergeActivityTest doesn't
> check whether the repository supports activities
> --
>
> Key: JCR-3307
> URL: https://issues.apache.org/jira/browse/JCR-3307
> Project: Jackrabbit Content Repository
> Issue Type: Bug
> Components: jackrabbit-jcr-tests
>Affects Versions: 2.4.1
>Reporter: Horia Chiorean
>Assignee: Julian Reschke
> Fix For: 2.4.2
>
>
> The test: org.apache.jackrabbit.test.api.version.MergeActivityTest, during
> setup (the initNodes method call) does not handle the case when activities
> are not supported by the repository. Therefore, if the
> versionManager.createActivity("foobar") call fails with an
> UnsupportedRepositoryOperationException, the whole test fails.
> The setup of the test should do something similar to
> org.apache.jackrabbit.test.api.version.ActivitiesTest:
> checkSupportedOption(Repository.OPTION_ACTIVITIES_SUPPORTED);
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: expanded names vs node types
Hi, On Fri, May 25, 2012 at 3:08 PM, Julian Reschke wrote: > I just realized that in JCR 2.0, we may have forgotten to specify whether > node type related methods (addMixin, isNodeType etc) are supposed to take > expanded names. > > I believe they should, but I can't find anything related to it in the > JavaDocs. Should we raise this as a JSR-333 issue? JCR 2.0 is already pretty clear on this. Section 3.2.6 [1] says: "When a JCR name is passed as an argument to a JCR method it may be in either expanded or qualified form." [1] http://www.day.com/specs/jcr/2.0/3_Repository_Model.html#3.2.6%20Use%20of%20Qualified%20and%20Expanded%20Names BR, Jukka Zitting
Re: Moving OCM issues to backlog version
Hi, On Fri, May 25, 2012 at 2:18 PM, Ard Schrijvers wrote: > Let's see what others prefer I generally find that sorting open issues by the last update is enough to filter out old and inactive issues. The other alternatives are either quickly outdated (who'll take care of updating the list of "backlog" issues over time?) or incorrect (inactivity does not necessarily mean an issue is resolved or no longer relevant). The best way to deal with old issues is for someone to actually spend a few minutes per issue to review what's the current status and update or resolve the issue accordingly. Until someone has the time and energy for that I'd rather just leave the issues untouched. Anyway, given that you're the first one to seriously use the OCM tracker for a while, I'd say whatever works for you is best. :-) BR, Jukka Zitting
Re: generating identifiers
Hi, On Fri, May 25, 2012 at 4:46 PM, Julian Reschke wrote: > For OAK, we need to decide how to generate identifiers for nodes that aren't > referenceable. > > In Jackrabbit, we simply assign UUIDs to every node, referenceable or not. > > My assumption was that we don't want that here, right? I'd say so, right. > The obvious alternative is to use the identifier of the closest > referenceable ancestor, and combine it with a relative path. That would make > the identifier stable across certain move/rename operations. Yes. > If we want to do this, we'll need to walk the tree up, and consider what it > would mean for a parent node not to be readable. Both for this and for the tree traversal case I think it would be useful if we could distinguish between a node being "readable" and "traversable", a bit like how the execute bit on directories works on unix platforms. A non-readable node could still allow a subtree to be accessed with proper access controls, but a non-traversable node would in effect deny read access to the entire subtree for the affected users. BR, Jukka Zitting
[jira] [Commented] (JCR-3300) tests should consistently check for repository support and fail with NotExecutableException when the repo does not support the feature
[ https://issues.apache.org/jira/browse/JCR-3300?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13283423#comment-13283423 ] Jukka Zitting commented on JCR-3300: > We actually *do* have features that are written per the specification that > are failing > several TCK tests because of bugs in the TCK tests themselves. Do you have fixes for those test cases? It would be great to have them in jackrabbit-jcr-tests so that they can be easily incorporated to JSR 333. > If 2.6 is going to be a bit, we really would love to have these issues fixed > in 2.4.2. There's no immediate plan for 2.6, but I was thinking of cutting an unstable 2.5.0 release from trunk within the next few days. Will that work for you? > tests should consistently check for repository support and fail with > NotExecutableException when the repo does not support the feature > -- > > Key: JCR-3300 > URL: https://issues.apache.org/jira/browse/JCR-3300 > Project: Jackrabbit Content Repository > Issue Type: Bug > Components: jackrabbit-jcr-tests >Affects Versions: 2.4.1, 2.6 >Reporter: Julian Reschke >Assignee: Julian Reschke >Priority: Minor > Fix For: 2.4.2, 2.6 > > > AbstractVersionTest should check for Repository.OPTION_VERSIONING_SUPPORTED > and throw NotExecutableException when not set > RSessionAccessControlTest needs to extend from AbstractAccessControlTest > instead of AbstractJCRTest > etc. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
