[jira] Created: (JCR-962) Deadlocks in ConcurrentVersioningWithTransactionsTest
Deadlocks in ConcurrentVersioningWithTransactionsTest
-
Key: JCR-962
URL: https://issues.apache.org/jira/browse/JCR-962
Project: Jackrabbit
Issue Type: Bug
Components: core
Reporter: Bertrand Delacretaz
Patch follows for a ConcurrentVersioningWithTransactionsTest, based on the
existing ConcurrentVersioningTest but using transactions around the versioning
operations.
On my macbook, running the test with CONCURRENCY = 100 and NUM_OPERATIONS = 100
causes a deadlock after a few seconds, thread dumps follow.
Note that I had to ignore StaleItemStateException (which is probably justified,
due to not locking stuff IIUC) to let the threads run long enough to show the
problem.
Running the test a few times showed the same locking pattern several times:
some threads are locked at line 87 (session.save(), no transaction) while
others are at line 93 (transaction.commit()), in
testConcurrentCheckinInTransaction():
80public void testConcurrentCheckinInTransaction() throws
RepositoryException {
81 runTask(new Task() {
82public void execute(Session session, Node test) throws
RepositoryException {
83 int i = 0;
84 try {
85Node n = test.addNode(test);
86n.addMixin(mixVersionable);
87session.save();
88for (i = 0; i NUM_OPERATIONS / CONCURRENCY; i++) {
89 final UserTransaction utx = new
UserTransactionImpl(test.getSession());
90 utx.begin();
91 n.checkout();
92 n.checkin();
93 utx.commit();
94}
95n.checkout();
96 } catch (Exception e) {
97final String threadName = Thread.currentThread().getName();
98final Throwable deepCause = getLevel2Cause(e);
99if(deepCause!=null deepCause instanceof
StaleItemStateException) {
100 // ignore
101} else {
102 throw new RepositoryException(threadName + , i= + i + :
+ e.getClass().getName(), e);
103}
104 }
105}
106 }, CONCURRENCY);
107}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (JCR-962) Deadlocks in ConcurrentVersioningWithTransactionsTest
[
https://issues.apache.org/jira/browse/JCR-962?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Bertrand Delacretaz updated JCR-962:
Attachment: JCR-962-ConcurrentVersioningWithTransactionsTest.patch
ConcurrentVersioningWithTransactionsTest patch, must be enabled in
org.apache.jackrabbit.core.TestAll
Deadlocks in ConcurrentVersioningWithTransactionsTest
-
Key: JCR-962
URL: https://issues.apache.org/jira/browse/JCR-962
Project: Jackrabbit
Issue Type: Bug
Components: core
Reporter: Bertrand Delacretaz
Attachments: 10-threads-dump.txt,
JCR-962-ConcurrentVersioningWithTransactionsTest.patch
Patch follows for a ConcurrentVersioningWithTransactionsTest, based on the
existing ConcurrentVersioningTest but using transactions around the
versioning operations.
On my macbook, running the test with CONCURRENCY = 100 and NUM_OPERATIONS =
100 causes a deadlock after a few seconds, thread dumps follow.
Note that I had to ignore StaleItemStateException (which is probably
justified, due to not locking stuff IIUC) to let the threads run long enough
to show the problem.
Running the test a few times showed the same locking pattern several times:
some threads are locked at line 87 (session.save(), no transaction) while
others are at line 93 (transaction.commit()), in
testConcurrentCheckinInTransaction():
80public void testConcurrentCheckinInTransaction() throws
RepositoryException {
81 runTask(new Task() {
82public void execute(Session session, Node test) throws
RepositoryException {
83 int i = 0;
84 try {
85Node n = test.addNode(test);
86n.addMixin(mixVersionable);
87session.save();
88for (i = 0; i NUM_OPERATIONS / CONCURRENCY; i++) {
89 final UserTransaction utx = new
UserTransactionImpl(test.getSession());
90 utx.begin();
91 n.checkout();
92 n.checkin();
93 utx.commit();
94}
95n.checkout();
96 } catch (Exception e) {
97final String threadName = Thread.currentThread().getName();
98final Throwable deepCause = getLevel2Cause(e);
99if(deepCause!=null deepCause instanceof
StaleItemStateException) {
100 // ignore
101} else {
102 throw new RepositoryException(threadName + , i= + i +
: + e.getClass().getName(), e);
103}
104 }
105}
106 }, CONCURRENCY);
107}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (JCR-962) Deadlocks in ConcurrentVersioningWithTransactionsTest
[
https://issues.apache.org/jira/browse/JCR-962?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Bertrand Delacretaz updated JCR-962:
Attachment: 10-threads-dump.txt
Deadlocked threads dump with 10 concurrent tasks
Deadlocks in ConcurrentVersioningWithTransactionsTest
-
Key: JCR-962
URL: https://issues.apache.org/jira/browse/JCR-962
Project: Jackrabbit
Issue Type: Bug
Components: core
Reporter: Bertrand Delacretaz
Attachments: 10-threads-dump.txt,
JCR-962-ConcurrentVersioningWithTransactionsTest.patch
Patch follows for a ConcurrentVersioningWithTransactionsTest, based on the
existing ConcurrentVersioningTest but using transactions around the
versioning operations.
On my macbook, running the test with CONCURRENCY = 100 and NUM_OPERATIONS =
100 causes a deadlock after a few seconds, thread dumps follow.
Note that I had to ignore StaleItemStateException (which is probably
justified, due to not locking stuff IIUC) to let the threads run long enough
to show the problem.
Running the test a few times showed the same locking pattern several times:
some threads are locked at line 87 (session.save(), no transaction) while
others are at line 93 (transaction.commit()), in
testConcurrentCheckinInTransaction():
80public void testConcurrentCheckinInTransaction() throws
RepositoryException {
81 runTask(new Task() {
82public void execute(Session session, Node test) throws
RepositoryException {
83 int i = 0;
84 try {
85Node n = test.addNode(test);
86n.addMixin(mixVersionable);
87session.save();
88for (i = 0; i NUM_OPERATIONS / CONCURRENCY; i++) {
89 final UserTransaction utx = new
UserTransactionImpl(test.getSession());
90 utx.begin();
91 n.checkout();
92 n.checkin();
93 utx.commit();
94}
95n.checkout();
96 } catch (Exception e) {
97final String threadName = Thread.currentThread().getName();
98final Throwable deepCause = getLevel2Cause(e);
99if(deepCause!=null deepCause instanceof
StaleItemStateException) {
100 // ignore
101} else {
102 throw new RepositoryException(threadName + , i= + i +
: + e.getClass().getName(), e);
103}
104 }
105}
106 }, CONCURRENCY);
107}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (JCR-962) Deadlocks in ConcurrentVersioningWithTransactionsTest
[
https://issues.apache.org/jira/browse/JCR-962?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Bertrand Delacretaz updated JCR-962:
Attachment: 100-threads-dump.txt
Deadlocked threads dump with 100 concurrent tasks
Deadlocks in ConcurrentVersioningWithTransactionsTest
-
Key: JCR-962
URL: https://issues.apache.org/jira/browse/JCR-962
Project: Jackrabbit
Issue Type: Bug
Components: core
Reporter: Bertrand Delacretaz
Attachments: 10-threads-dump.txt, 100-threads-dump.txt,
JCR-962-ConcurrentVersioningWithTransactionsTest.patch
Patch follows for a ConcurrentVersioningWithTransactionsTest, based on the
existing ConcurrentVersioningTest but using transactions around the
versioning operations.
On my macbook, running the test with CONCURRENCY = 100 and NUM_OPERATIONS =
100 causes a deadlock after a few seconds, thread dumps follow.
Note that I had to ignore StaleItemStateException (which is probably
justified, due to not locking stuff IIUC) to let the threads run long enough
to show the problem.
Running the test a few times showed the same locking pattern several times:
some threads are locked at line 87 (session.save(), no transaction) while
others are at line 93 (transaction.commit()), in
testConcurrentCheckinInTransaction():
80public void testConcurrentCheckinInTransaction() throws
RepositoryException {
81 runTask(new Task() {
82public void execute(Session session, Node test) throws
RepositoryException {
83 int i = 0;
84 try {
85Node n = test.addNode(test);
86n.addMixin(mixVersionable);
87session.save();
88for (i = 0; i NUM_OPERATIONS / CONCURRENCY; i++) {
89 final UserTransaction utx = new
UserTransactionImpl(test.getSession());
90 utx.begin();
91 n.checkout();
92 n.checkin();
93 utx.commit();
94}
95n.checkout();
96 } catch (Exception e) {
97final String threadName = Thread.currentThread().getName();
98final Throwable deepCause = getLevel2Cause(e);
99if(deepCause!=null deepCause instanceof
StaleItemStateException) {
100 // ignore
101} else {
102 throw new RepositoryException(threadName + , i= + i +
: + e.getClass().getName(), e);
103}
104 }
105}
106 }, CONCURRENCY);
107}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (JCR-260) Implement the count( ) function in XPATH query
[ https://issues.apache.org/jira/browse/JCR-260?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12501542 ] Frederic Esnault commented on JCR-260: -- I agree this function is a must-have in any query manager. Even thoug it's potentially (very) difficult to implement, as it has to be reflected to the SQL query handler and so to the jackrabbit abstract query language, this function is a basic and necessary query functionnality. Without it, the query handler seems very light. It definitely should be implemented. Implement the count( ) function in XPATH query -- Key: JCR-260 URL: https://issues.apache.org/jira/browse/JCR-260 Project: Jackrabbit Issue Type: Improvement Components: query Reporter: Harrison.Yao We've got the requirement for many times that to calculate the nodes amount which to fit the bill when query the tree, and the count( ) function is a part in the core function library with XPath 1.0 spec ( see http://www.w3.org/TR/xpath#corelib ). So , I suggested to support the count( ) function in xpath query with jackrabbit. Thanks ! -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Issue Comment Edited: (JCR-260) Implement the count( ) function in XPATH query
[ https://issues.apache.org/jira/browse/JCR-260?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12501542 ] Frederic Esnault edited comment on JCR-260 at 6/5/07 5:21 AM: -- I agree this function is a must-have in any query manager. Even though it's potentially (very) difficult to implement, as it has to be reflected to the SQL query handler and so to the jackrabbit abstract query language, this function is a basic and necessary query functionnality. Without it, the query handler seems very light. It definitely should be implemented. was: I agree this function is a must-have in any query manager. Even thoug it's potentially (very) difficult to implement, as it has to be reflected to the SQL query handler and so to the jackrabbit abstract query language, this function is a basic and necessary query functionnality. Without it, the query handler seems very light. It definitely should be implemented. Implement the count( ) function in XPATH query -- Key: JCR-260 URL: https://issues.apache.org/jira/browse/JCR-260 Project: Jackrabbit Issue Type: Improvement Components: query Reporter: Harrison.Yao We've got the requirement for many times that to calculate the nodes amount which to fit the bill when query the tree, and the count( ) function is a part in the core function library with XPath 1.0 spec ( see http://www.w3.org/TR/xpath#corelib ). So , I suggested to support the count( ) function in xpath query with jackrabbit. Thanks ! -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: S3 persistence manager
Hi, On 6/4/07, Martin Perez [EMAIL PROTECTED] wrote: Is there anyone developing something like a Amazon S3 persistence manager? If not, it seems to me like a good candidate for a new project ( it is too late for SOC ), or perhaps it is an insane idea? I haven't heard of anyone actively working on something like that, but I agree that it would be a cool idea. Actually S3 was floating around in my mind when I wrote the NGP proposal (http://jackrabbit.apache.org/dev/ngp.html). S3 or another similar massively distributed storage mechanism would work very well with the NGP concepts. I'm currently working on a related more short-term idea of adding a global data store that would handle all binary properties (and possibly other data like item bundles as well). The data store concept is designed to work very well with remote or distributed storage, so S3 would be an interesting option there as well. BR, Jukka Zitting
[jira] Commented: (JCR-922) jcr mapping layer (OCM) should expose lock owner
[ https://issues.apache.org/jira/browse/JCR-922?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12501584 ] ruchi goel commented on JCR-922: This looks good. I think this meets all requirements. But I am not still able to build the new jcr-mapping jar . Still getting the same errors. Can you please comment on my last mail with subject : error compiling jcr-mapping in Jackrabbit source tree jcr mapping layer (OCM) should expose lock owner Key: JCR-922 URL: https://issues.apache.org/jira/browse/JCR-922 Project: Jackrabbit Issue Type: Improvement Components: jcr-mapping Reporter: ruchi goel Assignee: Christophe Lombart Fix For: 1.4 jcr mapping layer 's persistencemanager.java does not expose an API for returning lockowner. Ideally , the following method public String lock(final String absPath, final boolean isDeep, final boolean isSessionScoped) should return a hashmap/String array containing locktoken as well as lockowner. I tried having lockowner as a field in my java object and mapping it to jcr:lockOwner , so that I can just use getLockOwner() . But the problem is this property gets introduced in the node only if the node is locked. So, when I try to insert a node , before I can even lock it , the insertion fails since there is no property like jcr:lockOwner till then . So, I feel there is need for the above API. It is ok to have it exposed via separate call in order to maintain backward compatability -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Newbie Maven question
Hi, please excuse the newbie Maven question...: How are dependencies between things in the Jackrabbit source tree meant to work? For instance, contrib/jcr-navigator wants jackrabbit-core version 1.1-SNAPSHOT, which I can't (?) build from trunk, nor is available from repo1.maven.org. Best regards, Julian
Re: Newbie Maven question
Julian Reschke wrote: For instance, contrib/jcr-navigator wants jackrabbit-core version 1.1-SNAPSHOT, which I can't (?) build from trunk, nor is available from repo1.maven.org. repo1.maven.org doesn't host SNAPSHOT dependencies. AFAIK Jackrabbit SNAPSHOT dependencies are hosted by this repository: http://people.apache.org/repo/m2-snapshot-repository/ But in this repository there is no 1.1-SNAPSHOT version. Since the reason for using a SNAPSHOT version is most likely to become aware of integration problems early it makes almost no sense to use 1.1-SNAPSHOT here. I would use either a stable version like 1.1, 1.2, 1.3 or use the current snapshot which is 1.4-SNAPSHOT. To use the snapshot versions you have to add the following section to the pom.xml or your local settings.xml: repositories repository idapache.snapshots/id nameApache Development Repository/name urlhttp://people.apache.org/repo/m2-snapshot-repository/url /repository /repositories Cheers, Christoph
Re: Newbie Maven question
Christoph Kiehl wrote: Julian Reschke wrote: For instance, contrib/jcr-navigator wants jackrabbit-core version 1.1-SNAPSHOT, which I can't (?) build from trunk, nor is available from repo1.maven.org. repo1.maven.org doesn't host SNAPSHOT dependencies. AFAIK Jackrabbit SNAPSHOT dependencies are hosted by this repository: http://people.apache.org/repo/m2-snapshot-repository/ But in this repository there is no 1.1-SNAPSHOT version. Since the reason for using a SNAPSHOT version is most likely to become aware of integration problems early it makes almost no sense to use 1.1-SNAPSHOT here. I would use either a stable version like 1.1, 1.2, 1.3 or use the current snapshot which is 1.4-SNAPSHOT. ... Understood. So these contrib projects probably just need to be updated to require 1.4-SNAPSHOT, right? Best regards, Julian
Re: Newbie Maven question
On 6/5/07, Julian Reschke [EMAIL PROTECTED] wrote: Christoph Kiehl wrote: Julian Reschke wrote: For instance, contrib/jcr-navigator wants jackrabbit-core version 1.1-SNAPSHOT, which I can't (?) build from trunk, nor is available from repo1.maven.org. repo1.maven.org doesn't host SNAPSHOT dependencies. AFAIK Jackrabbit SNAPSHOT dependencies are hosted by this repository: http://people.apache.org/repo/m2-snapshot-repository/ But in this repository there is no 1.1-SNAPSHOT version. Since the reason for using a SNAPSHOT version is most likely to become aware of integration problems early it makes almost no sense to use 1.1-SNAPSHOT here. I would use either a stable version like 1.1, 1.2, 1.3 or use the current snapshot which is 1.4-SNAPSHOT. ... Understood. So these contrib projects probably just need to be updated to require 1.4-SNAPSHOT, right? You should probably change it to 1.1, jcr-navigator project uses some classes from jcr-server that changed in the next versions. Best regards, Julian
removing projects from contrib
Hello, It's my understanding that projects under contrib should be there only if it's planned to release them. However, there are a few contrib projects I contributed that I think don't match this criteria because it's been a while since they are in contrib and there's no interest from the community. If no one opposes I'd like to remove the following projects. - vfs - sanitycheck - jcr-taglib - jcr-commands - jcr-navigator I have interest in jcr-taglib, commands and navigator, I used them in previous projects and I'll probably use them again, so if no one opposes I'd like move them to google code or sourceforge. br, edgar
Re: Newbie Maven question
Julian Reschke wrote: But in this repository there is no 1.1-SNAPSHOT version. Since the reason for using a SNAPSHOT version is most likely to become aware of integration problems early it makes almost no sense to use 1.1-SNAPSHOT here. I would use either a stable version like 1.1, 1.2, 1.3 or use the current snapshot which is 1.4-SNAPSHOT. ... Understood. So these contrib projects probably just need to be updated to require 1.4-SNAPSHOT, right? Yes, that should do the job. If you then just do a mvn install in the project root all the deps like api, core etc. should be installed into your local repository, thus making it unnecessary to add the repository section to your pom.xml/settings.xml I mentioned in my last mail. Cheers, Christoph
[jira] Created: (JCR-963) Failed to build path error in cluster environment
Failed to build path error in cluster environment - Key: JCR-963 URL: https://issues.apache.org/jira/browse/JCR-963 Project: Jackrabbit Issue Type: Bug Affects Versions: 1.3 Reporter: Xiaohua Lu we have a 4 machine cluster setup based on Jackrabbit 1.3. We have noticed the following error on one of the four nodes javax.jcr.ItemNotFoundException: failed to build path of 22b7932e-d2c2-46b6-90ee-66acfa8f4bb4: ef223e61-d6d3-49ec-8fb5-5e4668877d39 has no child entry for 22b7932e-d2c2-46b6-90ee-66acfa8f4bb4 at org.apache.jackrabbit.core.HierarchyManagerImpl.buildPath(HierarchyManagerImpl.java:308) at org.apache.jackrabbit.core.CachingHierarchyManager.buildPath(CachingHierarchyManager.java:163) at org.apache.jackrabbit.core.HierarchyManagerImpl.getPath(HierarchyManagerImpl.java:356) at org.apache.jackrabbit.core.CachingHierarchyManager.getPath(CachingHierarchyManager.java:224) at org.apache.jackrabbit.core.ItemImpl.getPrimaryPath(ItemImpl.java:295) at org.apache.jackrabbit.core.ItemImpl.getPath(ItemImpl.java:1381) at mycompany.repository.jackrabbit.cache.SystemCache.cacheItem(SystemCache.java:338) at mycompany.repository.jackrabbit.cache.SystemCache.getItemPath(SystemCache.java:297) at mycompany.repository.jackrabbit.cache.SystemCache.getItemPath(SystemCache.java:271) at mycompany.repository.jackrabbit.cache.SystemCache.getPermission(SystemCache.java:135) at mycompany.repository.jackrabbit.cache.AccessControlPermissionCacheImpl.getPermission(AccessControlPermissionCacheImpl.java:38) at mycompany.repository.jackrabbit.AccessControlManager.isGranted(AccessControlManager.java:238) at mycompany.repository.jackrabbit.AccessControlManager.isGrantedBySubject(AccessControlManager.java:223) at mycompany.repository.jackrabbit.AccessControlManager.isGranted(AccessControlManager.java:139) at org.apache.jackrabbit.core.query.lucene.LazyQueryResultImpl.getResults(LazyQueryResultImpl.java:270) at org.apache.jackrabbit.core.query.lucene.LazyQueryResultImpl.init(LazyQueryResultImpl.java:166) at org.apache.jackrabbit.core.query.lucene.QueryImpl.execute(QueryImpl.java:164) at org.apache.jackrabbit.core.query.QueryImpl.execute(QueryImpl.java:139) at net.maven.mcr.base.JCRSessionWrapper.executeQuery(JCRSessionWrapper.java:222) at net.maven.mcr.service.ServiceImpl.executeNodeQuery(ServiceImpl.java:303) When we look up for nodes with the given uuid 22b7932e-d2c2-46b6-90ee-66acfa8f4bb4, it doesn't exist in the repository, I am confused why this uuid is provided to our implementation of access control manager and how we can fix it without cleanup the repository? -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (JCR-964) Cannot rebuild corrupt or missing search index from DataSource
Cannot rebuild corrupt or missing search index from DataSource -- Key: JCR-964 URL: https://issues.apache.org/jira/browse/JCR-964 Project: Jackrabbit Issue Type: Bug Components: indexing Affects Versions: 1.3 Reporter: Noah Vihinen Priority: Critical If the search index becomes corrupt, and the auto-repair process cannot fix the search index (which is common in our experience), there is no way to recover the jackrabbit instance. The only possible work-around is when you're working with a cluster, and you manually copy an intact index from one of the other clusters. It hasn't been determined whether this leads to other issues though. Given a Jackrabbit repository, shouldn't it be possible to start the repository on top of that single data source in the absence of a search index, and have the search index rebuilt from the information in the DB? Below is the stack trace we get when restarting a repository with no search index. 15:32:13,622 ERROR RepositoryImpl:389 - [main] Failed to initialize workspace 'default' javax.jcr.RepositoryException: Error indexing root node: a7479d92-4b59-4f44-978a-06da1ec7b8d1: Error indexing root node: a7479d92-4b59-4f44-978a-06da1ec7b8d1: Error indexing root node: a7479d92-4b59-4f44-978a-06da1ec7b8d1 at org.apache.jackrabbit.core.SearchManager.initializeQueryHandler(SearchManager.java:476) at org.apache.jackrabbit.core.SearchManager.init(SearchManager.java:231) at org.apache.jackrabbit.core.RepositoryImpl$WorkspaceInfo.getSearchManager(RepositoryImpl.java:1643) at org.apache.jackrabbit.core.RepositoryImpl.initWorkspace(RepositoryImpl.java:633) at org.apache.jackrabbit.core.RepositoryImpl.initStartupWorkspaces(RepositoryImpl.java:386) at org.apache.jackrabbit.core.RepositoryImpl.init(RepositoryImpl.java:293) at org.apache.jackrabbit.core.RepositoryImpl.create(RepositoryImpl.java:584) at org.apache.jackrabbit.core.jndi.BindableRepository.createRepository(BindableRepository.java:174) at org.apache.jackrabbit.core.jndi.BindableRepository.init(BindableRepository.java:138) at org.apache.jackrabbit.core.jndi.BindableRepository.create(BindableRepository.java:125) at org.apache.jackrabbit.core.jndi.BindableRepositoryFactory.createInstance(BindableRepositoryFactory.java:59) at org.apache.jackrabbit.core.jndi.BindableRepositoryFactory.getObjectInstance(BindableRepositoryFactory.java:81) at org.apache.naming.factory.ResourceFactory.getObjectInstance(ResourceFactory.java:140) at javax.naming.spi.NamingManager.getObjectInstance(NamingManager.java:304) at org.apache.naming.NamingContext.lookup(NamingContext.java:793) at org.apache.naming.NamingContext.lookup(NamingContext.java:140) at org.apache.naming.NamingContext.lookup(NamingContext.java:781) at org.apache.naming.NamingContext.lookup(NamingContext.java:140) at org.apache.naming.NamingContext.lookup(NamingContext.java:781) at org.apache.naming.NamingContext.lookup(NamingContext.java:140) at org.apache.naming.NamingContext.lookup(NamingContext.java:781) at org.apache.naming.NamingContext.lookup(NamingContext.java:153) at org.apache.naming.SelectorContext.lookup(SelectorContext.java:137) at javax.naming.InitialContext.lookup(InitialContext.java:351) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (JCR-965) On an XP machine, unit test provides some error with the Derby persistence manager
On an XP machine, unit test provides some error with the Derby persistence manager -- Key: JCR-965 URL: https://issues.apache.org/jira/browse/JCR-965 Project: Jackrabbit Issue Type: Bug Components: jcr-mapping Reporter: Christophe Lombart Fix For: 1.3.1 On a XP machine, the some ocm unit tests are not working with the derby persistence manager. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
OCM - Mixin node type support
Hi all, Right now, the OCM framework is supporting the mixin node type for different purposes (versionning, locking, ...). It is possible to specify the desired mixin node types into the class descriptor but today the ocm persistence manager cannot assign dynamically a new mixin node type to an object. Do you see some interesting use cases that requires a dynamic support ? If yes, how the ocm persistence manager can map the mixin node type properties and child nodes into the object attributes ? All ideas are welcome. I would like to know if the current support is sufficient for the first OCM release. br, Christophe
Re: error compiling jcr-mapping in Jackrabbit source tree
Ruchi, I made some tests on another pc and i can compile jackrabbit and the jcr-mapping (ocm) subproject. I didn't get the JTA dependency error. I'm just wondering if others have the same problem ? If you want, we can make a chat and try to review this issue together. Let me know when you have time tommorow. br, christophe On 6/1/07, ruchi goel [EMAIL PROTECTED] wrote: Christophe Lombart wrote: On 5/31/07, ruchi goel [EMAIL PROTECTED] wrote: Christophe Lombart wrote: Hi Ruchi, Sorry for the delay. It was a long wk here. I don't understand your compile issue. It is not necessary to download manually the JTA jar. It is a Jackrabbit dependency. Do you have in your m2 repo the following folder : repository/org/apache/geronimo/specs/geronimo-jta_1.0.1B_spec/1.0.1 ? Yes, I have this. Did you run mvn install from the Jackrabbit home folder ? I first tried mvn install from Jackrabbit home folder but it did not create targets for jcr-mapping. Right. All projects in contrib are not installed auto. Then I tried building jcr-maping layer separately. Is it working now ? No. I did svn update. I have in my m2 repo the following folder : : repository/org/apache/geronimo/specs/geronimo-jta_1.0.1B_spec/1.0.1 Added following dependency in pom.xml dependency groupIdorg.apache.geronimo.specs/groupId artifactIdgeronimo-jta_1.0.1B_spec/artifactId version1.0.1/version /dependency !-- Test -- dependency groupIdorg.apache.geronimo.specs/groupId artifactIdgeronimo-jta_1.0.1B_spec/artifactId version1.0.1/version scopetest/scope /dependency Still I get the following error : [INFO] Compilation failure *E:\cms\JackrabbitNew\contrib\jackrabbit-jcr-mapping\jcr-mapping\src\main\java\org\apache\jackrabbit\ocm\transaction\jackrabbit\UserTransactionImpl.java:[22,25] cannot find symbol symbol : class UserTransaction location: package javax.transaction and similar errors. Basically compiler is not able to find javax.transaction. * What is it that I am missing ? regards, Ruchi
[jira] Updated: (JCR-965) On an XP machine, unit test provides some error with the Derby persistence manager
[ https://issues.apache.org/jira/browse/JCR-965?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christophe Lombart updated JCR-965: --- Fix Version/s: (was: 1.3.1) 1.4 On an XP machine, unit test provides some error with the Derby persistence manager -- Key: JCR-965 URL: https://issues.apache.org/jira/browse/JCR-965 Project: Jackrabbit Issue Type: Bug Components: jcr-mapping Reporter: Christophe Lombart Fix For: 1.4 On a XP machine, the some ocm unit tests are not working with the derby persistence manager. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (JCR-966) Add unit tests with BundleDbPersistenceManager
Add unit tests with BundleDbPersistenceManager -- Key: JCR-966 URL: https://issues.apache.org/jira/browse/JCR-966 Project: Jackrabbit Issue Type: Improvement Reporter: Christophe Lombart Fix For: 1.4 Until now, we have not yet check the ocm framework with the BundleDbPersistenceManager -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (JCR-930) [OCM] rename o.a.j.ocm.persistence.PersistenceManager to avoid confusion with core component
[ https://issues.apache.org/jira/browse/JCR-930?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12501695 ] Christophe Lombart commented on JCR-930: Why not ObjectManager ? [OCM] rename o.a.j.ocm.persistence.PersistenceManager to avoid confusion with core component Key: JCR-930 URL: https://issues.apache.org/jira/browse/JCR-930 Project: Jackrabbit Issue Type: Task Components: jcr-mapping Affects Versions: 1.3 Reporter: Stefan Guggisberg Priority: Minor Fix For: 1.4 PersistenceManager is a well known and established interface in jackrabbit's architecture. the same-named class in the jcr-mapping contrib project should IMO be renamed in order to avoid confusion in mailing list threads and jira issues, -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
How to configure a virtual file system for the search index component?
Hi; According to the information on the 'Configuring Jackrabbit' page, http://jackrabbit.apache.org/doc/config.html, it says An optional virtual file system component can be specified for the search index as well. Can anyone show me any example on how to specify a virtual file system for the search index component?
Re: Newbie Maven question
Hi, On 6/5/07, Julian Reschke [EMAIL PROTECTED] wrote: For instance, contrib/jcr-navigator wants jackrabbit-core version 1.1-SNAPSHOT, which I can't (?) build from trunk, nor is available from repo1.maven.org. As you noticed, the contrib subtree lives outside the main Jackrabbit build system. Since the contrib components are not included in Jackrabbit releases there isn't much effort in keeping their code or build scripts up to date at all times. You are of course free to update any contrib components if and when you need them. Also, once a component in contrib starts seeing more active use it makes sense to promote it into a release component and to integrate it with the main build system. All release components will be kept up to date with latest changes on a regular basis since they all get built and tested at least whenever there's a new release. BR, Jukka Zitting
Re: removing projects from contrib
Hi, On 6/5/07, Edgar Poce [EMAIL PROTECTED] wrote: It's my understanding that projects under contrib should be there only if it's planned to release them. However, there are a few contrib projects I contributed that I think don't match this criteria because it's been a while since they are in contrib and there's no interest from the community. You're correct about the release requirement; we shouldn't keep code that we have no intention of ever releasing. This however doesn't meant that each of the contrib components should have a tight roadmap of when and how they will be included in Jackrabbit releases. I'm happy to keep contrib components around as long as they are related to JCR and have at least a remote chance of getting released in the future. If no one opposes I'd like to remove the following projects. - vfs - sanitycheck - jcr-taglib - jcr-commands - jcr-navigator I have interest in jcr-taglib, commands and navigator, I used them in previous projects and I'll probably use them again, so if no one opposes I'd like move them to google code or sourceforge. All of those components are cool stuff that I'd love to see released at some point with Jackrabbit. You're of course free to take the code elsewhere, but if you do see yourself working with them also in the future, then I would instead suggest that we push to get the components promoted to release status within Jackrabbit. Having the components integrated in the main buid system and included in official release would likely lower the bar for more people to use them. All the above components pass at least my informal code and design quality metrics for inclusion in Jackrabbit releases. BR, Jukka Zitting
[jira] Commented: (JCR-960) Duplicate Folder of the same name in JCR webdav, could be a core issue
[ https://issues.apache.org/jira/browse/JCR-960?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12501759 ] Jukka Zitting commented on JCR-960: --- Could this be related to the recent JCR-950 issue? Duplicate Folder of the same name in JCR webdav, could be a core issue -- Key: JCR-960 URL: https://issues.apache.org/jira/browse/JCR-960 Project: Jackrabbit Issue Type: Bug Components: core, webapp, webdav Affects Versions: 1.3 Environment: OSX, JDK 1.5 running standard webdav webapp on a non clustered JVM, SimpleDbPerisistanceManager on MySQL InnoDB with read-committed transaction isolation Reporter: Ian Boston Attachments: create_second_new_folder.png, create_test1_folder.png, remount_webdav_mount.png, rename_second_new_folder.png, repository.xml 1. Deploy the standard JCR webapp war to tomcat 2. change the repository template to the attached (uses a SimpleDbPersistanceManager connected to MySQL 3. go to http://localhost:8080/jcrdav/ and create a default repository 4. mount http://localhost:8080/jcrdav/repository/default in OSX Finder 5. Create a new Folder, initiallyt called unnamed folder 6. rename to test1 7. Create a second new Folder At this point both folders become named unnamed folder 8. rename second folder to test2 Both folders now named test2 (as per attached screen shot) 9. Browse in web browser to http://localhost:8080/jcrdav/repository/default/ 2 folders, one named test1 and other named test2 10. Unmount OSX Finder mount and re-mount, test1 and test2 folders appear in OSX finder, but steps 5-9 can be repeated again. Is this a problem with OSX Finder or something up with the JCR webdav implementation or possibly something to do with the ItemState caches inside the core ? -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: error compiling jcr-mapping in Jackrabbit source tree
Hi, On 6/6/07, Christophe Lombart [EMAIL PROTECTED] wrote: I made some tests on another pc and i can compile jackrabbit and the jcr-mapping (ocm) subproject. I didn't get the JTA dependency error. I'm just wondering if others have the same problem ? I'm not seeing it either, mvn install works fine for me in jcr-mapping. Ruchi, perhaps there's something wrong with your enviroment. Can you try clearing your local Maven repository and getting a fresh checkout of jcr-mapping? BR, Jukka Zitting
GSoC 2007 - jcr-jackrabbit-demo - Update
Hi, I'm Nandana Mihindukulasooriya and I got selected for a Google Summer of Code project this year to develop a JCR demo application based on Jackrabbit. My proposal can be found herehttp://wiki.apache.org/general/NandanaMihindukulasooriya/GSoC2007/jackrabbit-jcr-demo. I have started the project but these days I'm going at a slow phase as my final year exam is on. It will be over soon ( 14th ) then I can contribute to the project in full phase. Initial discussions about the project can be found herehttp://www.nabble.com/How-to-start-thinking-in-JCR-tf3452522.htmland herehttp://www.nabble.com/Google-Summer-of-Code-2007---jackrabbit-jcr-demo-t3428515.html. I hope all the developers here in the mailing list will help me with comments and feedback. Thank you, Nandana Mihindukulasooriya.
