Re: Cannot get full-text searching to work
On Mon, Dec 8, 2008 at 11:13 PM, pkrishna [EMAIL PROTECTED] wrote: String query = //*[jcr:contains(jcr:content, 'Test')]; String query = //jcr:content[jcr:contains(., 'Test')]; The first argument of jcr:contains() is either ., which refers to the local node and by default means all properties of the current node (you can configure that, see the aggregation in [1]), or can be the name of a property, prefixed with an @. So your query probably should look like: //*[jcr:contains(., 'Test')] This will give you back all jcr:content nodes. If you want to retrieve the parent nodes, you can change the aggregation to include the jcr:content subnode and its properties for your ecr:ecisContentItem nodes [1]. For the definition of the jcr:contains function, see section 6.6.5.2 of the JCR 1.0 spec [2]. [1] http://wiki.apache.org/jackrabbit/IndexingConfiguration [2] http://jcp.org/en/jsr/detail?id=170 Regards, Alex -- Alexander Klimetschek [EMAIL PROTECTED]
Re: JDBC to JCR
On Tue, Dec 9, 2008 at 12:46 PM, Jukka Zitting [EMAIL PROTECTED] wrote: I'm planning to do some experiments with the Derby saucer separation mechanism (see [1]) as a way to implement a JDBC driver for accessing JCR content repositories. :-) Interesting ;-) Is the way using these virtual function tables simpler than directly implementing the JDBC API? I think the JDBC API is not so difficult Regards, Alex -- Alexander Klimetschek [EMAIL PROTECTED]
Re: JDBC to JCR
Hi, On Tue, Dec 9, 2008 at 12:52 PM, Alexander Klimetschek [EMAIL PROTECTED] wrote: Interesting ;-) Is the way using these virtual function tables simpler than directly implementing the JDBC API? I think the JDBC API is not so difficult The benefit of using Derby saucer separation is that Derby will do all the query execution based on the table data you return. You'll actually have JOINs, GROUP BYs, subselects, and all kinds of other nice features that JCR lacks. Of course it'll be dog-slow, but it opens up a whole new range of functionality and lots of integration options. BR, Jukka Zitting
Re: JDBC to JCR
Hi, Did you have a look at the JDBC to JCR bridge: http://wiki.apache.org/jackrabbit/QueryUsingJdbc Regards, Thomas On Tue, Dec 9, 2008 at 1:46 PM, Jukka Zitting [EMAIL PROTECTED] wrote: Hi, On Tue, Dec 9, 2008 at 12:52 PM, Alexander Klimetschek [EMAIL PROTECTED] wrote: Interesting ;-) Is the way using these virtual function tables simpler than directly implementing the JDBC API? I think the JDBC API is not so difficult The benefit of using Derby saucer separation is that Derby will do all the query execution based on the table data you return. You'll actually have JOINs, GROUP BYs, subselects, and all kinds of other nice features that JCR lacks. Of course it'll be dog-slow, but it opens up a whole new range of functionality and lots of integration options. BR, Jukka Zitting
Re: JDBC to JCR
Hi, On Tue, Dec 9, 2008 at 1:49 PM, Thomas Müller [EMAIL PROTECTED] wrote: Did you have a look at the JDBC to JCR bridge: http://wiki.apache.org/jackrabbit/QueryUsingJdbc Yes, I saw that. I'm looking for a more generic alternative, one that exposes all available node types (or other criteria for selecting nodes) as virtual tables and allows you to perform arbitrary joins across those tables. BR, Jukka Zitting
Re: jcr-cmis WS volounteers/approach
Hi Gabriele, On Tue, Dec 9, 2008 at 1:13 PM, Gabriele Columbro [EMAIL PROTECTED] wrote: Hi all, as this is my first post on the JackRabbit @dev list, I guess a bit of introduction is needed: together with my colleague Paolo Mottadelli, I have been following the jcr-cmis sandbox thread with a lot of interest. Searching how we could help, we noticed the WS component of the jcr-cmis connector is ATM quite short handed, so we started having a look at the jcr-cmis REsT branch to try and have a unified strategy and reuse the most between the two implementations. BTW, not having committership rights, I would probably be bugging you a lot with Jira issues and kinda long emails like this one (soffy for that), but hopefully you can still find value in the contribution :) To speed up things, I'll kick Paolo (which is POI committer) to commit to the sandbox possible patches I may attach to issues ;) So, we tried to have a look to the existing codebase and approach for the REsT part and came up with the following approach/findings for the WS part (I would have opened Jira issues already, but not sure which component to use, maybe sandbox [1] or better have a specific component for jcr-cmis) : __Maven parent In the superpom I find a parent reference to the 1.5-SNAPSHOT of Jackrabbit which is neither the last development version (1.5 has been released) nor it's available in any of the POM specified repositoritories (I guess most of you have apache.snapshots repo in their settings.xml) . My question here is: - is there a real need for the parent reference here? - If so, why can't we depend on 1.5 released version? (or on 1.6-SNAPSHOT still adding apache.snapshots repo in the POM) By the time, I created this pom.xml, 1.5 was not officially released yet, and I copied a pom.xml from some other sandbox project. We could very well depend on the latest development version or on the released version, whatever seems more appropriate, or even drop the parent reference as well. __Testing framework In the quasi-pure TDD spirit, we started by thinking about the testing framework (to create a RepositoryServiceTest), also looking at what's in the REsT part. My idea, please correct me if I'm wrong, was to have a: - maven-jetty-plugin configured in the build to run a jackrabbit war bundled with the jcr-cmis extension - configure maven-surefire-plugin to run integration tests after jetty - tear down the jetty instance I see instead there that an instance of Jetty is programmatically created and bound to the abdera servlet in the REsT part. Is it a best practice/approach we could reuse for both implementations? I'm not familiar with using Jetty programmatically so I may just be being so old ;) Sorry, this was my just initial approach. I quickly felt that abdera was extensible enough to fill the atompub binding part. In order to have a minimal startup time, so that I could tweak the responses the way I wanted them, I used this programmatical test setup. It surely makes more sense to have jackrabbit.war extended by jcr-cmis, as you suggest. I'm not sure, however, whether we can still use the abdera servlet then. __Core technologies (Axis or CXF) Which WS framework would you suggest? At the moment I have a better feeling for CXF with respect to Axis(2), maybe for the lower footprint it seems to have, but I never had hands on expertise with both frameworks. Any suggestion/direction here of course more than welcome. Axis is the only framework I heard of right now, but I was hoping that there is some better approach ;) __'jcr-cmis' component in Jira As I mentioned before, does it make sense to have a specific component for this bit of the sandbox or just use the 'sandbox' component? I'd prefer having a specific component. __Design document to map JCR - CIMS objects I read someone mentioning the creation of a 'mapping design' document. Has this been done and I'm missing something or someone can create it already? As far as I know, this hasn't been done yet. __Dynamically generate services interfaces and commit wsdl files? As a starting point, we were thinking of generating the Java interfaces from committed WSDL files with cxf as described here [3]. Also committing the WSDL, we could automatically regenerate the interfaces upon specs changes using the maven plugin [4]. Do you have any objections/suggestions for this approach? Sounds good to me. I started creating a couple of interfaces from the spec, but if we can have them generated through WSDL and use them in the atompub part as well, even better :) Kind regards Dominique Eager to hear your comments/suggestions (if you could make it trough this long email :). Ciao, Gab [1] https://issues.apache.org/jira/secure/IssueNavigator.jspa?reset=truepid=10591component=12310830resolution=-1sorter/field=prioritysorter/order=DESC : [2] http://people.apache.org/repo/m2-snapshot-repository [3]
Re: jcr-cmis WS volounteers/approach
Dominique Pfister wrote: On Tue, Dec 9, 2008 at 1:13 PM, Gabriele Columbro [EMAIL PROTECTED] wrote: __Core technologies (Axis or CXF) Which WS framework would you suggest? At the moment I have a better feeling for CXF with respect to Axis(2), maybe for the lower footprint it seems to have, but I never had hands on expertise with both frameworks. Any suggestion/direction here of course more than welcome. Axis is the only framework I heard of right now, but I was hoping that there is some better approach ;) some time ago I found this comparison quite helpful. but I'm not sure whether it is still up to date: http://wiki.apache.org/ws/StackComparison regards marcel
Re: jcr-cmis WS volounteers/approach
Hi all, find my comments below. By the time, I created this pom.xml, 1.5 was not officially released yet, and I copied a pom.xml from some other sandbox project. We could very well depend on the latest development version or on the released version, whatever seems more appropriate, or even drop the parent reference as well. In the spirit of implementing a JCR compliant CMIS, if we don't have any technical reason of having Jackrabbit as a parent project, I'd opt for dropping the parent reference untill we'll need it. __Core technologies (Axis or CXF) Which WS framework would you suggest? At the moment I have a better feeling for CXF with respect to Axis(2), maybe for the lower footprint it seems to have, but I never had hands on expertise with both frameworks. Any suggestion/direction here of course more than welcome. Axis is the only framework I heard of right now, but I was hoping that there is some better approach ;) ATM I'm playing with CXF and it is making me confident enough; the main reasons for which I've chosen it for these test are: _ they say CXF has better support for JAX-WS _ it has a simpler approach to make things start __'jcr-cmis' component in Jira As I mentioned before, does it make sense to have a specific component for this bit of the sandbox or just use the 'sandbox' component? I'd prefer having a specific component. +1 for a specific component for me, as well __Dynamically generate services interfaces and commit wsdl files? As a starting point, we were thinking of generating the Java interfaces from committed WSDL files with cxf as described here [3]. Also committing the WSDL, we could automatically regenerate the interfaces upon specs changes using the maven plugin [4]. Do you have any objections/suggestions for this approach? Sounds good to me. I started creating a couple of interfaces from the spec, but if we can have them generated through WSDL and use them in the atompub part as well, even better :) I've generated interfaces starting from the WSDL using the CXF wsdl2java command. For this first phase, it would be reasonable to consider these as a commodity we could add; I'd focus more on validating the better technology for us. Cheers, -- Paolo Kind regards Dominique Eager to hear your comments/suggestions (if you could make it trough this long email :). Ciao, Gab [1] https://issues.apache.org/jira/secure/IssueNavigator.jspa?reset=truepid=10591component=12310830resolution=-1sorter/field=prioritysorter/order=DESC : [2] http://people.apache.org/repo/m2-snapshot-repository [3] http://cwiki.apache.org/CXF20DOC/wsdl-to-java.html [4] http://cwiki.apache.org/CXF20DOC/maven-integration-and-plugin.html -- Gabriele Columbro Alfresco ECM Product Strategy Consultant +31 627 565 103 Sourcesense - Making sense of open Source (http://www.sourcesense.com) -- Paolo Mottadelli: http://www.paolomottadelli.com Sourcesense - making sense of Open Source: http://www.sourcesense.com
Re: jcr-cmis WS volounteers/approach
Hi Jukka, On Tue, Dec 9, 2008 at 3:00 PM, Jukka Zitting [EMAIL PROTECTED] wrote: How about if I created a new Jira project like JCRCMIS for this? Having sandbox issues in the JCR project has always been a bit distracting for release management purposes, and with a specialized Jira project for the CMIS effort you could also have more fine-grained component labels like ws or atompub. From our perspective it sounds better for the same reason :-) +1 for me -- Paolo Mottadelli: http://www.paolomottadelli.com Sourcesense - making sense of Open Source: http://www.sourcesense.com
jcr-cmis WS volounteers/approach
Hi all, as this is my first post on the JackRabbit @dev list, I guess a bit of introduction is needed: together with my colleague Paolo Mottadelli, I have been following the jcr-cmis sandbox thread with a lot of interest. Searching how we could help, we noticed the WS component of the jcr-cmis connector is ATM quite short handed, so we started having a look at the jcr-cmis REsT branch to try and have a unified strategy and reuse the most between the two implementations. BTW, not having committership rights, I would probably be bugging you a lot with Jira issues and kinda long emails like this one (soffy for that), but hopefully you can still find value in the contribution :) To speed up things, I'll kick Paolo (which is POI committer) to commit to the sandbox possible patches I may attach to issues ;) So, we tried to have a look to the existing codebase and approach for the REsT part and came up with the following approach/findings for the WS part (I would have opened Jira issues already, but not sure which component to use, maybe sandbox [1] or better have a specific component for jcr-cmis) : __Maven parent In the superpom I find a parent reference to the 1.5-SNAPSHOT of Jackrabbit which is neither the last development version (1.5 has been released) nor it's available in any of the POM specified repositoritories (I guess most of you have apache.snapshots repo in their settings.xml) . My question here is: - is there a real need for the parent reference here? - If so, why can't we depend on 1.5 released version? (or on 1.6-SNAPSHOT still adding apache.snapshots repo in the POM) __Testing framework In the quasi-pure TDD spirit, we started by thinking about the testing framework (to create a RepositoryServiceTest), also looking at what's in the REsT part. My idea, please correct me if I'm wrong, was to have a: - maven-jetty-plugin configured in the build to run a jackrabbit war bundled with the jcr-cmis extension - configure maven-surefire-plugin to run integration tests after jetty - tear down the jetty instance I see instead there that an instance of Jetty is programmatically created and bound to the abdera servlet in the REsT part. Is it a best practice/approach we could reuse for both implementations? I'm not familiar with using Jetty programmatically so I may just be being so old ;) __Core technologies (Axis or CXF) Which WS framework would you suggest? At the moment I have a better feeling for CXF with respect to Axis(2), maybe for the lower footprint it seems to have, but I never had hands on expertise with both frameworks. Any suggestion/direction here of course more than welcome. __'jcr-cmis' component in Jira As I mentioned before, does it make sense to have a specific component for this bit of the sandbox or just use the 'sandbox' component? __Design document to map JCR - CIMS objects I read someone mentioning the creation of a 'mapping design' document. Has this been done and I'm missing something or someone can create it already? __Dynamically generate services interfaces and commit wsdl files? As a starting point, we were thinking of generating the Java interfaces from committed WSDL files with cxf as described here [3]. Also committing the WSDL, we could automatically regenerate the interfaces upon specs changes using the maven plugin [4]. Do you have any objections/suggestions for this approach? Eager to hear your comments/suggestions (if you could make it trough this long email :). Ciao, Gab [1] https://issues.apache.org/jira/secure/IssueNavigator.jspa?reset=truepid=10591component=12310830resolution=-1sorter/field=prioritysorter/order=DESC : [2] http://people.apache.org/repo/m2-snapshot-repository [3] http://cwiki.apache.org/CXF20DOC/wsdl-to-java.html [4] http://cwiki.apache.org/CXF20DOC/maven-integration-and-plugin.html -- Gabriele Columbro Alfresco ECM Product Strategy Consultant +31 627 565 103 Sourcesense - Making sense of open Source (http://www.sourcesense.com)
JDBC to JCR
Hi, I'm planning to do some experiments with the Derby saucer separation mechanism (see [1]) as a way to implement a JDBC driver for accessing JCR content repositories. :-) Let's see how it turns out... I'll be setting up a jdbc2jcr component in the sandbox for any prototype code I come up with. [1] http://people.apache.org/~rhillegas/vtiDemo/doc/saucerSeparation.html BR, Jukka Zitting
Re: Apache JCR Commons
Hi, On Thu, Dec 4, 2008 at 4:40 PM, Jukka Zitting [EMAIL PROTECTED] wrote: Thanks for all the comments, keep 'em coming! Here's an updated version of the JCR Commons subproject proposal. This version should address most of the concerns and issues that were raised. I plan to call a vote on the updated proposal next week. Some minor tweaks: a) I don't think we need a new JCR Commons category in Jira, we can just put all the new projects under Jackrabbit. b) Would it make sense to merge the ocm and ocm-nodemanagement components back together? The dependency issue should be covered by setting the jackrabbit-core dependency to optional. c) Here's a list of Jira project keys that I think we could use: * jackrabbit-parent / JCRPARENT * jackrabbit-jcr-tests / JCRTEST * jackrabbit-jcr-benchmark / JCRBENCH * jackrabbit-jcr-rmi / JCRRMI * jackrabbit-jcr-servlet / JCRSERVLET * jackrabbit-classloader / JCRCL * jackrabbit-ocm / JCROCM d) Not strictly a part of this proposal, but somewhat related: We could set up a new JCRSITE project in Jira for tracking issues related to the Jackrabbit web site and other non-code issues that are not bound to normal release cycles. BR, Jukka Zitting
Re: Apache JCR Commons
On Tue, Dec 9, 2008 at 3:31 PM, Jukka Zitting [EMAIL PROTECTED] wrote: c) Here's a list of Jira project keys that I think we could use: * jackrabbit-parent / JCRPARENT * jackrabbit-jcr-tests / JCRTEST * jackrabbit-jcr-benchmark / JCRBENCH * jackrabbit-jcr-rmi / JCRRMI * jackrabbit-jcr-servlet / JCRSERVLET * jackrabbit-classloader / JCRCL * jackrabbit-ocm / JCROCM A separate Jira project for each of it? That somehow adds a lot of projects to Jira, which doesn't feel right to me. I would prefer a JCRCOMMONS project with each of the maven projects being a subproject. I know that this might be difficult for releasing the stuff, but some are IMHO just too small and have low activity for having their own top-level Jira project (eg. jackrabbit-classloader). Regards, Alex -- Alexander Klimetschek [EMAIL PROTECTED]
Re: jcr-cmis WS volounteers/approach
Hi, On Tue, Dec 9, 2008 at 3:00 PM, Jukka Zitting [EMAIL PROTECTED] wrote: How about if I created a new Jira project like JCRCMIS for this? Jira projects are cheap so I just went ahead and created the JCRCMIS project, see [1]. I've given the all-developers group the Committer role in JCRCMIS, so all Apache committers (with a developer role in some Jira project) should have the right to resolve issues and update the project configuration (create new components, etc.). The project is setup like the existing JCR project, for example the notification messages should work the same way. There are two differences though: I've enabled wiki markup for description and comment fields and used the 'no-reopen-closed, patch-avail workflow scheme. The latter means that there is a nice new Patch Available state for issues and that a closed (as opposed to just resolved) issue can not be reopened (it's better to create a new issue in such cases). Let's see how the wiki markup and workflow settings work in practice. I'd like to start using them in the JCR project as well if the experience from JCRCMIS is good. [1] https://issues.apache.org/jira/browse/JCRCMIS BR, Jukka Zitting
Re: Apache JCR Commons
Hi, On Tue, Dec 9, 2008 at 4:09 PM, Alexander Klimetschek [EMAIL PROTECTED] wrote: A separate Jira project for each of it? That somehow adds a lot of projects to Jira, which doesn't feel right to me. I would prefer a JCRCOMMONS project with each of the maven projects being a subproject. I know that this might be difficult for releasing the stuff, but some are IMHO just too small and have low activity for having their own top-level Jira project (eg. jackrabbit-classloader). Managing separate release cycles within a single Jira project is quite painful. Just look at the version fields in the SLING project for an example. And that's just a single release per component so far... The Apache Commons project has a separate Jira project for each component and that setup works fine. If a component is too small to even have it's own issues (!), then there's not much point in even having such a component, is there? ;-) BR, Jukka Zitting
[jira] Commented: (JCR-1883) Moved node disappears
[
https://issues.apache.org/jira/browse/JCR-1883?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12654836#action_12654836
]
Thomas Mueller commented on JCR-1883:
-
There are multiple solutions to the problem.
One is, refresh will undo the move operation. But that would also change the
old parent node, which may not be expected.
Another solution is to reject refreshing this node. This is what I have
implemented. Here is a proposed patch. I also want to add a test case for this
issue.
Index: src/main/java/org/apache/jackrabbit/core/ItemImpl.java
===
--- src/main/java/org/apache/jackrabbit/core/ItemImpl.java (revision
722453)
+++ src/main/java/org/apache/jackrabbit/core/ItemImpl.java (working copy)
@@ -1171,10 +1171,19 @@
switch (transientState.getStatus()) {
case ItemState.STATUS_STALE_MODIFIED:
case ItemState.STATUS_STALE_DESTROYED:
-case ItemState.STATUS_EXISTING_MODIFIED:
// add this item's state to the list
list.add(transientState);
break;
+
+case ItemState.STATUS_EXISTING_MODIFIED:
+if (!transientState.getParentId().equals(
+transientState.getOverlayedState().getParentId()))
{
+throw new RepositoryException(
+Cannot refresh a moved item: + this +
+ - possible solution: refresh the parent);
+}
+list.add(transientState);
+break;
case ItemState.STATUS_NEW:
throw new RepositoryException(
Moved node disappears
-
Key: JCR-1883
URL: https://issues.apache.org/jira/browse/JCR-1883
Project: Jackrabbit
Issue Type: Bug
Components: jackrabbit-core
Reporter: Thomas Mueller
Priority: Minor
Moving a node and then refreshing it can make it disappear.
deleteDirectory(new File(repository));
Repository rep = new TransientRepository();
Session session = rep.login(new SimpleCredentials(, new char[0]));
Node root = session.getRootNode();
Node a = root.addNode(a);
Node b = a.addNode(b);
session.save();
session.move(/a/b, /b);
b.refresh(false);
// session.save(); // no effect
for (NodeIterator it = root.getNodes(); it.hasNext();) {
Node n = it.nextNode();
System.out.println(n.getName());
for (NodeIterator it2 = n.getNodes(); it2.hasNext();) {
System.out.println( + it2.nextNode().getName());
}
}
In the trunk, the node 'b' is not listed after the refresh (not under the
root page, and not under a). The output is:
jcr:system
jcr:versionStorage
jcr:nodeTypes
a
Jackrabbit 1.4.x throws an exception:
jcr:system
jcr:versionStorage
jcr:nodeTypes
a
Exception in thread main javax.jcr.RepositoryException: failed to resolve
name of acee31c4-c33b-4ed4-b1b5-39db6f17fb09
at
org.apache.jackrabbit.core.HierarchyManagerImpl.getName(HierarchyManagerImpl.java:451)
at
org.apache.jackrabbit.core.CachingHierarchyManager.getName(CachingHierarchyManager.java:287)
at org.apache.jackrabbit.core.NodeImpl.getName(NodeImpl.java:1931)
at
org.apache.jackrabbit.core.fuzz.TestMoveRemoveRefresh.test(TestMoveRemoveRefresh.java:33)
at
org.apache.jackrabbit.core.fuzz.TestMoveRemoveRefresh.main(TestMoveRemoveRefresh.java:15)
void deleteDirectory(File file) {
if (file.isDirectory()) {
File[] list = file.listFiles();
for(int i=0; ilist.length; i++) {
deleteDirectory(list[i]);
}
}
file.delete();
}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
Re: Apache JCR Commons
On Tue, Dec 9, 2008 at 4:21 PM, Jukka Zitting [EMAIL PROTECTED] wrote: Managing separate release cycles within a single Jira project is quite painful. Just look at the version fields in the SLING project for an example. And that's just a single release per component so far... Looks a bit weird, but in the end it shouldn't be a difference in amount of work. The only difference I see is that you always see the versions of other components that are unrelated to the current component (in the Sling project). And the overview pages are a bit cluttered. But this could be seen as a missing feature in Jira... The Apache Commons project has a separate Jira project for each component and that setup works fine. Ok, so this style seems to be accepted, then Jackrabbit couldn't be made responsible for cluttering the Apache Jira ;-) If a component is too small to even have it's own issues (!), then there's not much point in even having such a component, is there? ;-) I didn't said it had no issues, I just proposed the granularity to be the one of a Jira component. It might be painful to release components separately, but that's simply because Jira doesn't allow a matrix-style versioning and/or forces release units to be a separate project. As it seems, releases are the major driver for this decision, so I can live with the separate Jira projects. Regards, Alex -- Alexander Klimetschek [EMAIL PROTECTED]
Re: Apache JCR Commons
Hi, On Tue, Dec 9, 2008 at 5:40 PM, Alexander Klimetschek [EMAIL PROTECTED] wrote: As it seems, releases are the major driver for this decision, [...] Yep, the demand for smaller and quicker releases (see [1]) started the whole component release debate almost a year ago, and with this proposal I think we're finally reaching a solution that should work well in the long run (as opposed to the temporary solutions we have for 1.4.x and 1.5.x). [1] http://markmail.org/message/y4iogyl74xde55bb BR, Jukka Zitting
[jira] Created: (JCR-1906) Make observation polling time configurable
Make observation polling time configurable -- Key: JCR-1906 URL: https://issues.apache.org/jira/browse/JCR-1906 Project: Jackrabbit Issue Type: Improvement Components: jackrabbit-jcr2spi Reporter: Michael Dürig Priority: Minor Currently the polling time is hard coded to 3 seconds in org.apache.jackrabbit.jcr2spi.WorkspaceImpl. I suggest to make it configurable similar to CacheBehaviour. That is, add a respective setting to org.apache.jackrabbit.jcr2spi.config.RepositoryConfig -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
