[jira] Commented: (JCR-2197) Support configuration of timeout in Statements for Database implementations
[ https://issues.apache.org/jira/browse/JCR-2197?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12729229#action_12729229 ] Micah Whitacre commented on JCR-2197: - I do not have a data store configured and am storing xml documents that are generally about 10-50k. In a few rare cases the files size is as large as 250k. I remember looking at a data store at a previous point but can't remember why I decided to not use it. Does a data store play nicely in a clustered environment? In my example in the initial description I have multiple JVMs each with its own repository but pointing at the same set of tables in the database. The suggested feature is simply meant to give jackrabbit a bit more robustness in situations where it is controlling the connections with the database. > Support configuration of timeout in Statements for Database implementations > --- > > Key: JCR-2197 > URL: https://issues.apache.org/jira/browse/JCR-2197 > Project: Jackrabbit Content Repository > Issue Type: New Feature > Components: jackrabbit-core >Affects Versions: 1.5.6 >Reporter: Micah Whitacre >Priority: Minor > > Allowing for the configuration and usage of a timeout value for Statements[1] > would provide a means avoiding dead lock when a long running/stalled SQL > Statement holds onto a lock preventing other threads from acquiring locks. > The situation i have seen is where a JVM handling multiple request each in > its own Thread will at some points become stalled. At the start of each > thread processing the request it will acquire its own session to the > repository which stores all information in an an Oracle database. The issue > we are seeing is that deadlock occurs because the SQL write statement to the > VersionManager is taking too long/stalling in the Oracle driver code. Since > it is writing, the write lock is acquired and this prevents other threads > from acquiring a session because they get blocked trying to acquire the read > lock of the Version Manager. > If the SQL statement timed out after a certain time, this would alleviate the > problem of threads continually hanging and make use of the Jackrabbit auto > reconnect functionality. The user of timeout is supported when using JNDI so > this request would move it towards being first class support on the database > implementations. > [1] - > http://java.sun.com/j2se/1.5.0/docs/api/java/sql/Statement.html#setQueryTimeout(int) > [2] - http://forums.sun.com/thread.jspa?threadID=343023&start=30&tstart=0 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (JCR-2197) Support configuration of timeout in Statements for Database implementations
Support configuration of timeout in Statements for Database implementations --- Key: JCR-2197 URL: https://issues.apache.org/jira/browse/JCR-2197 Project: Jackrabbit Content Repository Issue Type: Bug Components: locks Affects Versions: 1.5.6 Reporter: Micah Whitacre Allowing for the configuration and usage of a timeout value for Statements[1] would provide a means avoiding dead lock when a long running/stalled SQL Statement holds onto a lock preventing other threads from acquiring locks. The situation i have seen is where a JVM handling multiple request each in its own Thread will at some points become stalled. At the start of each thread processing the request it will acquire its own session to the repository which stores all information in an an Oracle database. The issue we are seeing is that deadlock occurs because the SQL write statement to the VersionManager is taking too long/stalling in the Oracle driver code. Since it is writing, the write lock is acquired and this prevents other threads from acquiring a session because they get blocked trying to acquire the read lock of the Version Manager. If the SQL statement timed out after a certain time, this would alleviate the problem of threads continually hanging and make use of the Jackrabbit auto reconnect functionality. The user of timeout is supported when using JNDI so this request would move it towards being first class support on the database implementations. [1] - http://java.sun.com/j2se/1.5.0/docs/api/java/sql/Statement.html#setQueryTimeout(int) [2] - http://forums.sun.com/thread.jspa?threadID=343023&start=30&tstart=0 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (JCR-1440) NPE Thrown when two Cluster Nodes are hitting the same underlying database.
[ https://issues.apache.org/jira/browse/JCR-1440?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12727557#action_12727557 ] Micah Whitacre commented on JCR-1440: - What can someone do to help this issue be resolved? A patch and junit have been supplied a long time ago. What else is needed for this to be resolved for one of the official releases? > NPE Thrown when two Cluster Nodes are hitting the same underlying database. > --- > > Key: JCR-1440 > URL: https://issues.apache.org/jira/browse/JCR-1440 > Project: Jackrabbit Content Repository > Issue Type: Bug > Components: clustering, jackrabbit-core >Affects Versions: 1.4, core 1.4.1 > Environment: Vista JDK 1.5.0_12. Using Derby and Derby Client > 10.1.2.1 >Reporter: Micah Whitacre >Priority: Critical > Attachments: jackrabbit-1.5-JCR-1440.tar.gz, > jcr-1440-workaround.patch, repository1.xml, > SimpleJackrabbitConflictTest.java, SimpleJackRabbitTest.zip > > > I've created a test that creates two repositories with clustering enabled > that are backed by the same database. Using the following workflow causes a > NullPointerException to be thrown. > The workflow I'm using is: > The root node is versioned. > ClusterNode1 creates a versioned child node named "foo". > The test waits to make sure the syncDelay has passed so ClusterNode2 will > notice the newly created node. > ClusterNode2 retrieves the "foo" child node and removes it. > The test waits for the change ClusterNode1 to sync with that change. > ClusterNode1 tries to create another new node however a NullPointerException > is thrown when the it tries to checkout the rootNode. > java.lang.NullPointerException: null values not allowed > at > org.apache.commons.collections.map.AbstractReferenceMap.put(AbstractReferenceMap.java:251) > at > org.apache.jackrabbit.core.version.VersionManagerImpl.getItem(VersionManagerImpl.java:280) > at > org.apache.jackrabbit.core.version.XAVersionManager.getItem(XAVersionManager.java:334) > at > org.apache.jackrabbit.core.version.AbstractVersionManager.getVersion(AbstractVersionManager.java:87) > at > org.apache.jackrabbit.core.NodeImpl.getBaseVersion(NodeImpl.java:3198) > at org.apache.jackrabbit.core.NodeImpl.checkout(NodeImpl.java:2991) > at > com.cerner.system.configuration.repository.jcr.SimpleJackrabbitConflictTest.testNullPointerExceptionThrown(SimpleJackrabbitConflictTest.java:96) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (JCR-1961) Improper Exception thrown on concurrent versioned node changes
[
https://issues.apache.org/jira/browse/JCR-1961?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Micah Whitacre updated JCR-1961:
Attachment: concurrent-version-test.tar.gz
A test project that when ran through Maven will run a test that creates two
different repository with the same underlying Derby database. It then creates
two sessions that make non conflicting changes to a version node. However the
versioning mechanism throws an exception being unable to merge its information.
> Improper Exception thrown on concurrent versioned node changes
> --
>
> Key: JCR-1961
> URL: https://issues.apache.org/jira/browse/JCR-1961
> Project: Jackrabbit Content Repository
> Issue Type: Bug
> Components: jackrabbit-core, versioning
>Affects Versions: core 1.4.8
> Environment: ubuntu 7.10 - the Gutsy Gibbon Sun JDK 1.5.0_13
>Reporter: Micah Whitacre
> Attachments: concurrent-version-test.tar.gz
>
>
> When two sessions connected through two separate repositories but backed by
> the same database make non conflicting changes to the same versioned node, an
> InvalidItemStateException is thrown. I'll attach a test project that when
> built displays this error but essentially the code is the following:
> Node node1 = session1.getRootNode().getNode(baseNodeName);
> Node node2 = session2.getRootNode().getNode(baseNodeName);
> node1.checkout();
> Node child1 = node1.addNode(UUID.randomUUID().toString(),
> "nt:folder");
> child1.addMixin("mix:versionable");
> child1.checkout();
> node1.save();
> child1.checkin();
> node1.checkin();
> node2.checkout();
> Node child2 = node2.addNode(UUID.randomUUID().toString(),
> "nt:folder");
> child2.addMixin("mix:versionable");
> child2.checkout();
> node2.save();
> child2.checkin();
> node2.checkin();
> The above code throws the following exception on the node2.checkout() call.
> javax.jcr.InvalidItemStateException:
> de6b39ce-1ec6-43e2-ba0e-2966341e6aff/{http://www.jcp.org/jcr/1.0}predecessors
> has been modified externally
> at org.apache.jackrabbit.core.ItemImpl.save(ItemImpl.java:1251)
> at org.apache.jackrabbit.core.SessionImpl.save(SessionImpl.java:897)
> at org.apache.jackrabbit.core.NodeImpl.checkout(NodeImpl.java:3004)
> at
> concurrent.version.test.ConcurrentVersionNodeAddTest.testConcurrentNodeAdd(ConcurrentVersionNodeAddTest.java:89)
> or
> javax.jcr.InvalidItemStateException:
> e384b5f6-0fcd-4853-962c-0085901cdcce/{http://www.jcp.org/jcr/1.0}isCheckedOut
> has been modified externally
> at org.apache.jackrabbit.core.ItemImpl.save(ItemImpl.java:1251)
> at org.apache.jackrabbit.core.SessionImpl.save(SessionImpl.java:897)
> at org.apache.jackrabbit.core.NodeImpl.checkout(NodeImpl.java:3004)
> at
> concurrent.version.test.ConcurrentVersionNodeAddTest.testConcurrentNodeAdd(ConcurrentVersionNodeAddTest.java:89)
> Based on JCR-584[1], it would seem that since the change to the node is being
> merged properly that the versioning should be able to merge its information
> properly as well. The difference between the merging of nodes and this
> version exception is the fact that one is a node and other are properties.
> Now while I would like properties to be merged nicely (it would eliminate
> some other problems I'm having), since I can't control conflicting changes in
> how the versioning is managed it seems appropriate that it should merge
> nicely.
> [1] -https://issues.apache.org/jira/browse/JCR-584
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Created: (JCR-1961) Improper Exception thrown on concurrent versioned node changes
Improper Exception thrown on concurrent versioned node changes
--
Key: JCR-1961
URL: https://issues.apache.org/jira/browse/JCR-1961
Project: Jackrabbit Content Repository
Issue Type: Bug
Components: jackrabbit-core, versioning
Affects Versions: core 1.4.8
Environment: ubuntu 7.10 - the Gutsy Gibbon Sun JDK 1.5.0_13
Reporter: Micah Whitacre
When two sessions connected through two separate repositories but backed by the
same database make non conflicting changes to the same versioned node, an
InvalidItemStateException is thrown. I'll attach a test project that when
built displays this error but essentially the code is the following:
Node node1 = session1.getRootNode().getNode(baseNodeName);
Node node2 = session2.getRootNode().getNode(baseNodeName);
node1.checkout();
Node child1 = node1.addNode(UUID.randomUUID().toString(), "nt:folder");
child1.addMixin("mix:versionable");
child1.checkout();
node1.save();
child1.checkin();
node1.checkin();
node2.checkout();
Node child2 = node2.addNode(UUID.randomUUID().toString(), "nt:folder");
child2.addMixin("mix:versionable");
child2.checkout();
node2.save();
child2.checkin();
node2.checkin();
The above code throws the following exception on the node2.checkout() call.
javax.jcr.InvalidItemStateException:
de6b39ce-1ec6-43e2-ba0e-2966341e6aff/{http://www.jcp.org/jcr/1.0}predecessors
has been modified externally
at org.apache.jackrabbit.core.ItemImpl.save(ItemImpl.java:1251)
at org.apache.jackrabbit.core.SessionImpl.save(SessionImpl.java:897)
at org.apache.jackrabbit.core.NodeImpl.checkout(NodeImpl.java:3004)
at
concurrent.version.test.ConcurrentVersionNodeAddTest.testConcurrentNodeAdd(ConcurrentVersionNodeAddTest.java:89)
or
javax.jcr.InvalidItemStateException:
e384b5f6-0fcd-4853-962c-0085901cdcce/{http://www.jcp.org/jcr/1.0}isCheckedOut
has been modified externally
at org.apache.jackrabbit.core.ItemImpl.save(ItemImpl.java:1251)
at org.apache.jackrabbit.core.SessionImpl.save(SessionImpl.java:897)
at org.apache.jackrabbit.core.NodeImpl.checkout(NodeImpl.java:3004)
at
concurrent.version.test.ConcurrentVersionNodeAddTest.testConcurrentNodeAdd(ConcurrentVersionNodeAddTest.java:89)
Based on JCR-584[1], it would seem that since the change to the node is being
merged properly that the versioning should be able to merge its information
properly as well. The difference between the merging of nodes and this version
exception is the fact that one is a node and other are properties. Now while I
would like properties to be merged nicely (it would eliminate some other
problems I'm having), since I can't control conflicting changes in how the
versioning is managed it seems appropriate that it should merge nicely.
[1] -https://issues.apache.org/jira/browse/JCR-584
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (JCR-936) Using Oracle bundle PM throws SQL exception (cannot insert NULL)
[
https://issues.apache.org/jira/browse/JCR-936?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12643322#action_12643322
]
Micah Whitacre commented on JCR-936:
What's the status on this bug? This issue has recently popped up for us and
this bug doesn't seem to have been updated in over a year. Is the recommended
fix to create the trigger by hand?
> Using Oracle bundle PM throws SQL exception (cannot insert NULL)
>
>
> Key: JCR-936
> URL: https://issues.apache.org/jira/browse/JCR-936
> Project: Jackrabbit
> Issue Type: Bug
> Components: jackrabbit-core
>Affects Versions: 1.3, 1.3.1, 1.3.3
> Environment: Magnolia 3.1
> Jackrabbit 1.3
> DB: Oracle Database 10g Release 2 (10.2.0.3.0)
> JDBC (thin): Oracle Database 10g Release 2 (10.2.0.2)
>Reporter: Amir Mistric
>
> When using
> org.apache.jackrabbit.core.persistence.bundle.OraclePersistenceManager as a
> PM, empty string (root node???) seems to be causing problems...
> This may be similar to http://issues.apache.org/jira/browse/JCR-748
> Here is the error I get:
> 2007-05-22 09:56:51,880 INFO [STDOUT] INFO
> info.magnolia.cms.beans.config.ContentRepository
> ContentRepository.java(loadRepository:331) 22.05.2007 09:56:51 System :
> loading JCR magnolia
> 2007-05-22 09:56:51,911 INFO [STDOUT] INFO
> info.magnolia.jackrabbit.ProviderImpl ProviderImpl.java(init:143) 22.05.2007
> 09:56:51 Loading repository at
> C:/mycompany/webapp/data/magnolia-cms/repositories/magnolia (config file:
> C:\mycompany\webapp\deploy\magnolia-community-3.1-SNAPSHOT-cms.war\WEB-INF\config\repo-conf\mycompany-jackrabbit-oracle-search.xml)
> 2007-05-22 09:56:53,708 INFO [STDOUT] ERROR
> org.apache.jackrabbit.core.persistence.bundle.BundleDbPersistenceManager
> BundleDbPersistenceManager.java(storeBundle:943) 22.05.2007 09:56:53 failed
> to write bundle: deadbeef-face-babe-cafe-babecafebabe
> java.lang.IllegalStateException: Unable to insert index:
> java.sql.SQLException: ORA-01400: cannot insert NULL into
> ("WAMGNLCMS"."VERSION_NAMES"."ID")
> at
> org.apache.jackrabbit.core.persistence.bundle.util.NGKDbNameIndex.insertString(NGKDbNameIndex.java:76)
> at
> org.apache.jackrabbit.core.persistence.bundle.util.DbNameIndex.stringToIndex(DbNameIndex.java:98)
> at
> org.apache.jackrabbit.core.persistence.bundle.util.BundleBinding.writeBundle(BundleBinding.java:245)
> at
> org.apache.jackrabbit.core.persistence.bundle.BundleDbPersistenceManager.storeBundle(BundleDbPersistenceManager.java:930)
> at
> org.apache.jackrabbit.core.persistence.bundle.AbstractBundlePersistenceManager.putBundle(AbstractBundlePersistenceManager.java:693)
> at
> org.apache.jackrabbit.core.persistence.bundle.AbstractBundlePersistenceManager.store(AbstractBundlePersistenceManager.java:634)
> at
> org.apache.jackrabbit.core.persistence.bundle.BundleDbPersistenceManager.store(BundleDbPersistenceManager.java:495)
> at
> org.apache.jackrabbit.core.version.VersionManagerImpl.(VersionManagerImpl.java:159)
> at
> org.apache.jackrabbit.core.RepositoryImpl.createVersionManager(RepositoryImpl.java:372)
> at
> org.apache.jackrabbit.core.RepositoryImpl.(RepositoryImpl.java:282)
> 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.RegistryHelper.registerRepository(RegistryHelper.java:60)
> at info.magnolia.jackrabbit.ProviderImpl.init(ProviderImpl.java:165)
> at
> info.magnolia.cms.beans.config.ContentRepository.loadRepository(ContentRepository.java:333)
> at
> info.magnolia.cms.beans.config.ContentRepository.loadRepositories(ContentRepository.java:297)
> at
> info.magnolia.cms.beans.config.ContentRepository.init(ContentRepository.java:184)
> at
> info.magnolia.cms.beans.config.ConfigLoader.load(ConfigLoader.java:111)
> at
> info.magnolia.cms.beans.config.ConfigLoader.(ConfigLoader.java:97)
> at
> info.magnolia.cms.servlets.PropertyInitializer.contextInitialized(PropertyInitializer.java:189)
> at
> org.apache.catalina.core.StandardContext.listenerStart(StandardContext.java:3763)
> at
> org.apache.catalina.core.StandardContext.start(StandardContext.java:4211)
> at
> org.apache.catalina.core.ContainerBase.addChildInternal(ContainerB
[jira] Commented: (JCR-1753) Allow means force a Repository to synchronize with the cluster
[ https://issues.apache.org/jira/browse/JCR-1753?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12634140#action_12634140 ] Micah Whitacre commented on JCR-1753: - My use case is described in the mailing list link included in the first comment. I read the article you linked to and it was very interesting. In my situation we are shooting for session consistency however there is not means to guarantee the stickiness of the session on the server side. The setup I have is operations are routed between 3 different JVMs and each JVM is read/writing to the JCR repository. So the use case I'm shooting for is client 1 performs writes which get routed to JVM1. The same client then performs a read on that write however the operation is routed to JVM2. In this situation I know that the write operation has occurred but when retrieving from the repository get a PathNotFoundException. So in that case I'd like to sync to update JVM2. After I sync I attempt to read and either get the value I'm looking for or I don't. If i don't then I know that a concurrent modification has occurred and report the appropriate response back to the client. > Allow means force a Repository to synchronize with the cluster > -- > > Key: JCR-1753 > URL: https://issues.apache.org/jira/browse/JCR-1753 > Project: Jackrabbit > Issue Type: New Feature > Components: clustering, jackrabbit-api, jackrabbit-core >Reporter: Micah Whitacre >Assignee: Jukka Zitting > Fix For: 1.5 > > Attachments: JCR-1753.tar.gz > > > Based on the thread on the user mailing list I'm logging this to propose > adding a sync() method to force cluster synchronization using the > JackrabbitRepository extension API. > The purpose of the method is such that in a distributed clustered environment > sometime cluster synchronization does or has not occurred such that certain > repositories are in a stale state. This method would provide a means to > force a repository to update pull in possible changes made by other > Jackrabbit repositories. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (JCR-1462) repository.xml: throw an exception on error
[ https://issues.apache.org/jira/browse/JCR-1462?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12633868#action_12633868 ] Micah Whitacre commented on JCR-1462: - I'm not sure I have permissions to reopen this bug but was advised to do so. This bug seems to have introduced the requirement that all repository.xml files specify a DOCTYPE. If you don't have a doctype specified you start seeing SAX Parse exceptions like the following: org.xml.sax.SAXParseException: Document root element "Repository", must match DOCTYPE root "null". at com.sun.org.apache.xerces.internal.util.ErrorHandlerWrapper.createSAXParseException(ErrorHandlerWrapper.java:236) at com.sun.org.apache.xerces.internal.util.ErrorHandlerWrapper.error(ErrorHandlerWrapper.java:172) at com.sun.org.apache.xerces.internal.impl.XMLErrorReporter.reportError(XMLErrorReporter.java:382) at com.sun.org.apache.xerces.internal.impl.XMLErrorReporter.reportError(XMLErrorReporter.java:316) at com.sun.org.apache.xerces.internal.impl.dtd.XMLDTDValidator.rootElementSpecified(XMLDTDValidator.java:1652) at com.sun.org.apache.xerces.internal.impl.dtd.XMLDTDValidator.handleStartElement(XMLDTDValidator.java:1931) at com.sun.org.apache.xerces.internal.impl.dtd.XMLDTDValidator.startElement(XMLDTDValidator.java:795) at com.sun.org.apache.xerces.internal.impl.XMLDocumentFragmentScannerImpl.scanStartElement(XMLDocumentFragmentScannerImpl.java:878) at com.sun.org.apache.xerces.internal.impl.XMLDocumentScannerImpl$ContentDispatcher.scanRootElementHook(XMLDocumentScannerImpl.java:1157) at com.sun.org.apache.xerces.internal.impl.XMLDocumentFragmentScannerImpl$FragmentContentDispatcher.dispatch(XMLDocumentFragmentScannerImpl.java:1794) at com.sun.org.apache.xerces.internal.impl.XMLDocumentFragmentScannerImpl.scanDocument(XMLDocumentFragmentScannerImpl.java:368) at com.sun.org.apache.xerces.internal.parsers.XML11Configuration.parse(XML11Configuration.java:834) at com.sun.org.apache.xerces.internal.parsers.XML11Configuration.parse(XML11Configuration.java:764) at com.sun.org.apache.xerces.internal.parsers.XMLParser.parse(XMLParser.java:148) at com.sun.org.apache.xerces.internal.parsers.DOMParser.parse(DOMParser.java:250) at com.sun.org.apache.xerces.internal.jaxp.DocumentBuilderImpl.parse(DocumentBuilderImpl.java:292) at org.apache.jackrabbit.core.config.ConfigurationParser.parseXML(ConfigurationParser.java:215) at org.apache.jackrabbit.core.config.RepositoryConfigurationParser.parseRepositoryConfig(RepositoryConfigurationParser.java:214) at org.apache.jackrabbit.core.config.RepositoryConfig.create(RepositoryConfig.java:144) at org.apache.jackrabbit.core.config.RepositoryConfig.create(RepositoryConfig.java:118) > repository.xml: throw an exception on error > --- > > Key: JCR-1462 > URL: https://issues.apache.org/jira/browse/JCR-1462 > Project: Jackrabbit > Issue Type: New Feature > Components: jackrabbit-core >Reporter: Thomas Mueller >Assignee: Thomas Mueller >Priority: Minor > Fix For: 1.5 > > Attachments: configPatch.txt > > > Currently, unsupported parameters in repository.xml and workspace.xml are > ignored. > To find problems earlier, such problems should result in an exception, > and starting such a repository should not be possible. > The same should happen for unsupported values. > For currently unavailable options > (such as text extraction filter classes if the class is not in the classpath), > at least a warning should be written to the error log, or an error should be > thrown. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (JCR-1751) Update slf4j
[ https://issues.apache.org/jira/browse/JCR-1751?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12633460#action_12633460 ] Micah Whitacre commented on JCR-1751: - What made you pick version 1.5.2 when version 1.5.3 is available? I've tested my assemblies using 1.5-SNAPSHOTs with the 1.5.3 versions of slf4j* endstates and did not receive any errors. > Update slf4j > > > Key: JCR-1751 > URL: https://issues.apache.org/jira/browse/JCR-1751 > Project: Jackrabbit > Issue Type: Improvement >Reporter: Stephane Landelle >Priority: Minor > Original Estimate: 0.08h > Remaining Estimate: 0.08h > > Please update slf4j from 1.3.0 to 1.5.2. > jcl104-over-slf4j has been renamed as jcl-over-slf4j, so if one uses a recent > version, he has to exclude jcl104-over-slf4j for every jackrabbit dependency, > which is quite a pain... > No impact observed. > Best regards, > Stephane Landelle -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (JCR-1753) Allow means force a Repository to synchronize with the data store
[ https://issues.apache.org/jira/browse/JCR-1753?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Micah Whitacre updated JCR-1753: Attachment: JCR-1753.tar.gz I forgot to include the link to the mailing list thread in the original bug description[1]. The attachment contains patches for the 1.4 branch of the jackrabbit-core and jackrabbit-api projects. It adds the method forceClusterSync() to the JackrabbitRepository interface and implements the method in the three implementations of the interface. The patches stray from Jukka's suggestion of naming the method sync() as the use case I was needing solved involved a clustered environment. sync() seems general enough that it might indicate the repository implementation would pick up any changes made to the data store. I know on the mailing list altering the database directly instead of through JCR/Jackrabbit API is discouraged so perhaps that isn't a valid use case. I'm also not completely familiar with all use cases and therefore the implementations of the method only work in a clustered environment. I assume that multiple repositories hitting the same database in an unclustered environment could be considered invalid. However if this assumption is incorrect then the code will need to be changed to handle that. [1] - http://www.nabble.com/Forcing-a-cluster-synch-td19578255.html > Allow means force a Repository to synchronize with the data store > - > > Key: JCR-1753 > URL: https://issues.apache.org/jira/browse/JCR-1753 > Project: Jackrabbit > Issue Type: New Feature > Components: clustering, jackrabbit-api, jackrabbit-core >Affects Versions: core 1.4.5 >Reporter: Micah Whitacre > Attachments: JCR-1753.tar.gz > > > Based on the thread on the user mailing list I'm logging this to propose > adding a sync() method to force cluster synchronization using the > JackrabbitRepository extension API. > The purpose of the method is such that in a distributed clustered environment > sometime cluster synchronization does or has not occurred such that certain > repositories are in a stale state. This method would provide a means to > force a repository to update pull in possible changes made by other > Jackrabbit repositories. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (JCR-1753) Allow means force a Repository to synchronize with the data store
Allow means force a Repository to synchronize with the data store - Key: JCR-1753 URL: https://issues.apache.org/jira/browse/JCR-1753 Project: Jackrabbit Issue Type: New Feature Components: clustering, jackrabbit-api, jackrabbit-core Affects Versions: core 1.4.5 Reporter: Micah Whitacre Based on the thread on the user mailing list I'm logging this to propose adding a sync() method to force cluster synchronization using the JackrabbitRepository extension API. The purpose of the method is such that in a distributed clustered environment sometime cluster synchronization does or has not occurred such that certain repositories are in a stale state. This method would provide a means to force a repository to update pull in possible changes made by other Jackrabbit repositories. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (JCR-1440) NPE Thrown when two Cluster Nodes are hitting the same underlying database.
[ https://issues.apache.org/jira/browse/JCR-1440?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12632294#action_12632294 ] Micah Whitacre commented on JCR-1440: - I applied Ryan's patch to trunk and it fixed the NPE being thrown. > NPE Thrown when two Cluster Nodes are hitting the same underlying database. > --- > > Key: JCR-1440 > URL: https://issues.apache.org/jira/browse/JCR-1440 > Project: Jackrabbit > Issue Type: Bug > Components: clustering, jackrabbit-core >Affects Versions: 1.4, core 1.4.1 > Environment: Vista JDK 1.5.0_12. Using Derby and Derby Client > 10.1.2.1 >Reporter: Micah Whitacre >Priority: Critical > Attachments: jackrabbit-1.5-JCR-1440.tar.gz, > jcr-1440-workaround.patch, repository1.xml, > SimpleJackrabbitConflictTest.java, SimpleJackRabbitTest.zip > > > I've created a test that creates two repositories with clustering enabled > that are backed by the same database. Using the following workflow causes a > NullPointerException to be thrown. > The workflow I'm using is: > The root node is versioned. > ClusterNode1 creates a versioned child node named "foo". > The test waits to make sure the syncDelay has passed so ClusterNode2 will > notice the newly created node. > ClusterNode2 retrieves the "foo" child node and removes it. > The test waits for the change ClusterNode1 to sync with that change. > ClusterNode1 tries to create another new node however a NullPointerException > is thrown when the it tries to checkout the rootNode. > java.lang.NullPointerException: null values not allowed > at > org.apache.commons.collections.map.AbstractReferenceMap.put(AbstractReferenceMap.java:251) > at > org.apache.jackrabbit.core.version.VersionManagerImpl.getItem(VersionManagerImpl.java:280) > at > org.apache.jackrabbit.core.version.XAVersionManager.getItem(XAVersionManager.java:334) > at > org.apache.jackrabbit.core.version.AbstractVersionManager.getVersion(AbstractVersionManager.java:87) > at > org.apache.jackrabbit.core.NodeImpl.getBaseVersion(NodeImpl.java:3198) > at org.apache.jackrabbit.core.NodeImpl.checkout(NodeImpl.java:2991) > at > com.cerner.system.configuration.repository.jcr.SimpleJackrabbitConflictTest.testNullPointerExceptionThrown(SimpleJackrabbitConflictTest.java:96) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (JCR-1440) NPE Thrown when two Cluster Nodes are hitting the same underlying database.
[ https://issues.apache.org/jira/browse/JCR-1440?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Micah Whitacre updated JCR-1440: Attachment: jackrabbit-1.5-JCR-1440.tar.gz While coding against the 1.5-SNAPSHOT I started seeing a different exception being logged[1]. The attachment includes the same test that was previously attached (but modified to run on linux) and it will reliably produce the stack trace. The two repository.xml files were updated to support the newer security configuration needed as well. I have not tried applying Ryan's patch yet to see if it fixes this issue. Could someone look at/comment on the patch? It would be nice if this fix could make it into an upcoming release like 1.4.6 but if not maybe the 1.5. Thanks. [1] java.lang.NullPointerException at org.apache.jackrabbit.core.version.AbstractVersionManager.calculateCheckinVersionName(AbstractVersionManager.java:458) at org.apache.jackrabbit.core.version.AbstractVersionManager.checkin(AbstractVersionManager.java:392) at org.apache.jackrabbit.core.version.VersionManagerImpl$2.run(VersionManagerImpl.java:280) at org.apache.jackrabbit.core.version.VersionManagerImpl$DynamicESCFactory.doSourced(VersionManagerImpl.java:563) at org.apache.jackrabbit.core.version.VersionManagerImpl.checkin(VersionManagerImpl.java:276) at org.apache.jackrabbit.core.version.XAVersionManager.checkin(XAVersionManager.java:155) at org.apache.jackrabbit.core.NodeImpl.checkin(NodeImpl.java:3309) at com.cerner.system.configuration.repository.jcr.SimpleJackrabbitConflictTest.testNullPointerExceptionThrown(SimpleJackrabbitConflictTest.java:105) > NPE Thrown when two Cluster Nodes are hitting the same underlying database. > --- > > Key: JCR-1440 > URL: https://issues.apache.org/jira/browse/JCR-1440 > Project: Jackrabbit > Issue Type: Bug > Components: clustering, jackrabbit-core >Affects Versions: 1.4, core 1.4.1 > Environment: Vista JDK 1.5.0_12. Using Derby and Derby Client > 10.1.2.1 >Reporter: Micah Whitacre >Priority: Critical > Attachments: jackrabbit-1.5-JCR-1440.tar.gz, > jcr-1440-workaround.patch, repository1.xml, > SimpleJackrabbitConflictTest.java, SimpleJackRabbitTest.zip > > > I've created a test that creates two repositories with clustering enabled > that are backed by the same database. Using the following workflow causes a > NullPointerException to be thrown. > The workflow I'm using is: > The root node is versioned. > ClusterNode1 creates a versioned child node named "foo". > The test waits to make sure the syncDelay has passed so ClusterNode2 will > notice the newly created node. > ClusterNode2 retrieves the "foo" child node and removes it. > The test waits for the change ClusterNode1 to sync with that change. > ClusterNode1 tries to create another new node however a NullPointerException > is thrown when the it tries to checkout the rootNode. > java.lang.NullPointerException: null values not allowed > at > org.apache.commons.collections.map.AbstractReferenceMap.put(AbstractReferenceMap.java:251) > at > org.apache.jackrabbit.core.version.VersionManagerImpl.getItem(VersionManagerImpl.java:280) > at > org.apache.jackrabbit.core.version.XAVersionManager.getItem(XAVersionManager.java:334) > at > org.apache.jackrabbit.core.version.AbstractVersionManager.getVersion(AbstractVersionManager.java:87) > at > org.apache.jackrabbit.core.NodeImpl.getBaseVersion(NodeImpl.java:3198) > at org.apache.jackrabbit.core.NodeImpl.checkout(NodeImpl.java:2991) > at > com.cerner.system.configuration.repository.jcr.SimpleJackrabbitConflictTest.testNullPointerExceptionThrown(SimpleJackrabbitConflictTest.java:96) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (JCR-1729) Node#addNode failes with AccessDeniedException if session lacks read-permission to an acestor
[ https://issues.apache.org/jira/browse/JCR-1729?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12628628#action_12628628 ] Micah Whitacre commented on JCR-1729: - what version of jackrabbit-core are you working with? > Node#addNode failes with AccessDeniedException if session lacks > read-permission to an acestor > - > > Key: JCR-1729 > URL: https://issues.apache.org/jira/browse/JCR-1729 > Project: Jackrabbit > Issue Type: Bug > Components: jackrabbit-core >Reporter: christian >Priority: Minor > > Consider a Session that has following permissions: > /home -> no permission > /home/myself -> read|remove|set_property|add_node > if this session tries to add a Node to /home/myself. > An AccessDeniedException is thrown indicateing that it can not read /home. > The Exception is caused by the Node's check, if it is checked-out. > This check asumes that the session has read-access to all its ancestors. > Which breaks in this case: > see NodeImpl internalIsCheckedOut() (ln 3875) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (JCR-1670) NPE when clustered JR queries version history on a node that has just had a version added by another JR in the same cluster
[ https://issues.apache.org/jira/browse/JCR-1670?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12611170#action_12611170 ] Micah Whitacre commented on JCR-1670: - The stack trace and use case seems similar to JCR-1440. > NPE when clustered JR queries version history on a node that has just had a > version added by another JR in the same cluster > --- > > Key: JCR-1670 > URL: https://issues.apache.org/jira/browse/JCR-1670 > Project: Jackrabbit > Issue Type: Bug > Components: clustering >Affects Versions: core 1.4.3 > Environment: Windows XP servers, JDK 1.5.2.02, in process. Microsoft > SQL 2005 bundled persistence manager, datastore. >Reporter: Brett Connor >Priority: Critical > > Two computers A and B running jboss webapp, including in-process Jackrabbit > instances in a cluster. > - A checks out a versioned node, then checks it in and unlocks it > - A notifies B (through a non JR mechanism) that the node has been updated > - B finds the node (by UUID) and calls getVersionHistory().getAllVersions() > This results in java.lang.NullPointerException > at > org.apache.jackrabbit.core.version.VersionIteratorImpl.addVersion(VersionIteratorImpl.java:147) > at org.apache.jackrabbit.core.version.VersionIteratorImpl. > (VersionIteratorImpl.java:68) > at > org.apache.jackrabbit.core.version.VersionHistoryImpl.getAllVersions(VersionHistoryImpl.java:95) > The addVersion() method is synchronized, but looks like it's reading a null > from 'successors'. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (JCR-1641) DefaultLoginModule/SimpleLoginModule don't support custom PrincipalProvider
[ https://issues.apache.org/jira/browse/JCR-1641?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Micah Whitacre updated JCR-1641: Attachment: jcr-1641.patch Here is a quick and dirty patch that adds the needed methods to AbstractLoginModule as well as modifying the LoginModuleConfig constant to be correct. > DefaultLoginModule/SimpleLoginModule don't support custom PrincipalProvider > --- > > Key: JCR-1641 > URL: https://issues.apache.org/jira/browse/JCR-1641 > Project: Jackrabbit > Issue Type: Bug > Components: jackrabbit-core, JCR 2.0, security >Affects Versions: 1.5 > Environment: vista jdk 1.5.0_11 >Reporter: Micah Whitacre > Attachments: jcr-1641.patch, JCR-1641.zip > > > When configuring a custom PrincipalProvider for the SimpleLoginModule or > DefaultLoginModule, inside of a repository.xml file with configuration such > as the following: > > class="org.apache.jackrabbit.core.security.DefaultAccessManager"> > > > class="org.apache.jackrabbit.core.security.authentication.DefaultLoginModule"> > value="com.foo.jcr.BasicPrincipalProvider"/> > >class="org.apache.jackrabbit.core.DefaultSecurityManager"> > > > And that yields the following stacktrace: > javax.jcr.LoginException: > org.apache.jackrabbit.core.security.authentication.DefaultLoginModule does > not support 'principalprovider: > org.apache.jackrabbit.core.security.authentication.DefaultLoginModule does > not support 'principalprovider: > org.apache.jackrabbit.core.security.authentication.DefaultLoginModule does > not support 'principalprovider > at > org.apache.jackrabbit.core.RepositoryImpl.login(RepositoryImpl.java:1353) > at > org.apache.jackrabbit.commons.AbstractRepository.login(AbstractRepository.java:53) > at > com.foo.jcr.PrincipalProviderTest.testPrincipalProvider(PrincipalProviderTest.java:24) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) > at java.lang.reflect.Method.invoke(Method.java:585) > at org.junit.internal.runners.TestMethod.invoke(TestMethod.java:59) > at > org.junit.internal.runners.MethodRoadie.runTestMethod(MethodRoadie.java:98) > at org.junit.internal.runners.MethodRoadie$2.run(MethodRoadie.java:79) > at > org.junit.internal.runners.MethodRoadie.runBeforesThenTestThenAfters(MethodRoadie.java:87) > at org.junit.internal.runners.MethodRoadie.runTest(MethodRoadie.java:77) > at org.junit.internal.runners.MethodRoadie.run(MethodRoadie.java:42) > at > org.junit.internal.runners.JUnit4ClassRunner.invokeTestMethod(JUnit4ClassRunner.java:88) > at > org.junit.internal.runners.JUnit4ClassRunner.runMethods(JUnit4ClassRunner.java:51) > at > org.junit.internal.runners.JUnit4ClassRunner$1.run(JUnit4ClassRunner.java:44) > at > org.junit.internal.runners.ClassRoadie.runUnprotected(ClassRoadie.java:27) > at > org.junit.internal.runners.ClassRoadie.runProtected(ClassRoadie.java:37) > at > org.junit.internal.runners.JUnit4ClassRunner.run(JUnit4ClassRunner.java:42) > at > org.eclipse.jdt.internal.junit4.runner.JUnit4TestReference.run(JUnit4TestReference.java:45) > at > org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38) > at > org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:460) > at > org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:673) > at > org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:386) > at > org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:196) > Caused by: javax.security.auth.login.LoginException: > org.apache.jackrabbit.core.security.authentication.DefaultLoginModule does > not support 'principalprovider > at > org.apache.jackrabbit.core.security.authentication.LocalAuthContext.login(LocalAuthContext.java:68) > at > org.apache.jackrabbit.core.RepositoryImpl.login(RepositoryImpl.java:1346) > ... 24 more > javax.security.auth.login.LoginException: > org.apache.jackrabbit.core.security.authentication.DefaultLoginModule does > not support 'principalprovider > at > org.apache.jackrabbit.core.security.authentication.LocalAuthContext.login(LocalAuthContext.java:68) > at > org.apache.jackrabbit.core.RepositoryImpl.login(RepositoryImpl.java:1346) > at > org.apache.jackrabbit.commons.AbstractRepository.login(AbstractRepo
[jira] Commented: (JCR-1641) DefaultLoginModule/SimpleLoginModule don't support custom PrincipalProvider
[ https://issues.apache.org/jira/browse/JCR-1641?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12603669#action_12603669 ] Micah Whitacre commented on JCR-1641: - I don't have a patch but implementing my own LoginModule I did find that I needed to do two things to get this exception to go away: 1. My custom login module needed to implement public String getPrincipalProvider() and public void setPrincipalProvider(String). 2. The configuration in the repository.xml file needs to be for . Therefore I think the LoginModuleConfig.PARAM_PRINCIPAL_PROVIDER_CLASS contant needs to be changed to equal "principalProvider" instead of being "principalprovider". > DefaultLoginModule/SimpleLoginModule don't support custom PrincipalProvider > --- > > Key: JCR-1641 > URL: https://issues.apache.org/jira/browse/JCR-1641 > Project: Jackrabbit > Issue Type: Bug > Components: jackrabbit-core, JCR 2.0, security >Affects Versions: 1.5 > Environment: vista jdk 1.5.0_11 >Reporter: Micah Whitacre > Attachments: JCR-1641.zip > > > When configuring a custom PrincipalProvider for the SimpleLoginModule or > DefaultLoginModule, inside of a repository.xml file with configuration such > as the following: > > class="org.apache.jackrabbit.core.security.DefaultAccessManager"> > > > class="org.apache.jackrabbit.core.security.authentication.DefaultLoginModule"> > value="com.foo.jcr.BasicPrincipalProvider"/> > >class="org.apache.jackrabbit.core.DefaultSecurityManager"> > > > And that yields the following stacktrace: > javax.jcr.LoginException: > org.apache.jackrabbit.core.security.authentication.DefaultLoginModule does > not support 'principalprovider: > org.apache.jackrabbit.core.security.authentication.DefaultLoginModule does > not support 'principalprovider: > org.apache.jackrabbit.core.security.authentication.DefaultLoginModule does > not support 'principalprovider > at > org.apache.jackrabbit.core.RepositoryImpl.login(RepositoryImpl.java:1353) > at > org.apache.jackrabbit.commons.AbstractRepository.login(AbstractRepository.java:53) > at > com.foo.jcr.PrincipalProviderTest.testPrincipalProvider(PrincipalProviderTest.java:24) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) > at java.lang.reflect.Method.invoke(Method.java:585) > at org.junit.internal.runners.TestMethod.invoke(TestMethod.java:59) > at > org.junit.internal.runners.MethodRoadie.runTestMethod(MethodRoadie.java:98) > at org.junit.internal.runners.MethodRoadie$2.run(MethodRoadie.java:79) > at > org.junit.internal.runners.MethodRoadie.runBeforesThenTestThenAfters(MethodRoadie.java:87) > at org.junit.internal.runners.MethodRoadie.runTest(MethodRoadie.java:77) > at org.junit.internal.runners.MethodRoadie.run(MethodRoadie.java:42) > at > org.junit.internal.runners.JUnit4ClassRunner.invokeTestMethod(JUnit4ClassRunner.java:88) > at > org.junit.internal.runners.JUnit4ClassRunner.runMethods(JUnit4ClassRunner.java:51) > at > org.junit.internal.runners.JUnit4ClassRunner$1.run(JUnit4ClassRunner.java:44) > at > org.junit.internal.runners.ClassRoadie.runUnprotected(ClassRoadie.java:27) > at > org.junit.internal.runners.ClassRoadie.runProtected(ClassRoadie.java:37) > at > org.junit.internal.runners.JUnit4ClassRunner.run(JUnit4ClassRunner.java:42) > at > org.eclipse.jdt.internal.junit4.runner.JUnit4TestReference.run(JUnit4TestReference.java:45) > at > org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38) > at > org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:460) > at > org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:673) > at > org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:386) > at > org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:196) > Caused by: javax.security.auth.login.LoginException: > org.apache.jackrabbit.core.security.authentication.DefaultLoginModule does > not support 'principalprovider > at > org.apache.jackrabbit.core.security.authentication.LocalAuthContext.login(LocalAuthContext.java:68) > at > org.apache.jackrabbit.core.RepositoryImpl.login(RepositoryImpl.java:1346) > ... 24 more > javax.security.auth.login.LoginException: > org.apache.jackrabbit.core.security
[jira] Updated: (JCR-1641) DefaultLoginModule/SimpleLoginModule don't support custom PrincipalProvider
[ https://issues.apache.org/jira/browse/JCR-1641?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Micah Whitacre updated JCR-1641: Attachment: JCR-1641.zip Zip file contains a basic implementation of a PrincipalProvider, a repository.xml file configured to use the PrincipalProvider, and a simple test case that when run generates the previously mentioned stack trace. > DefaultLoginModule/SimpleLoginModule don't support custom PrincipalProvider > --- > > Key: JCR-1641 > URL: https://issues.apache.org/jira/browse/JCR-1641 > Project: Jackrabbit > Issue Type: Bug > Components: jackrabbit-core, JCR 2.0, security >Affects Versions: 1.5 > Environment: vista jdk 1.5.0_11 >Reporter: Micah Whitacre > Attachments: JCR-1641.zip > > > When configuring a custom PrincipalProvider for the SimpleLoginModule or > DefaultLoginModule, inside of a repository.xml file with configuration such > as the following: > > class="org.apache.jackrabbit.core.security.DefaultAccessManager"> > > > class="org.apache.jackrabbit.core.security.authentication.DefaultLoginModule"> > value="com.foo.jcr.BasicPrincipalProvider"/> > >class="org.apache.jackrabbit.core.DefaultSecurityManager"> > > > And that yields the following stacktrace: > javax.jcr.LoginException: > org.apache.jackrabbit.core.security.authentication.DefaultLoginModule does > not support 'principalprovider: > org.apache.jackrabbit.core.security.authentication.DefaultLoginModule does > not support 'principalprovider: > org.apache.jackrabbit.core.security.authentication.DefaultLoginModule does > not support 'principalprovider > at > org.apache.jackrabbit.core.RepositoryImpl.login(RepositoryImpl.java:1353) > at > org.apache.jackrabbit.commons.AbstractRepository.login(AbstractRepository.java:53) > at > com.foo.jcr.PrincipalProviderTest.testPrincipalProvider(PrincipalProviderTest.java:24) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) > at java.lang.reflect.Method.invoke(Method.java:585) > at org.junit.internal.runners.TestMethod.invoke(TestMethod.java:59) > at > org.junit.internal.runners.MethodRoadie.runTestMethod(MethodRoadie.java:98) > at org.junit.internal.runners.MethodRoadie$2.run(MethodRoadie.java:79) > at > org.junit.internal.runners.MethodRoadie.runBeforesThenTestThenAfters(MethodRoadie.java:87) > at org.junit.internal.runners.MethodRoadie.runTest(MethodRoadie.java:77) > at org.junit.internal.runners.MethodRoadie.run(MethodRoadie.java:42) > at > org.junit.internal.runners.JUnit4ClassRunner.invokeTestMethod(JUnit4ClassRunner.java:88) > at > org.junit.internal.runners.JUnit4ClassRunner.runMethods(JUnit4ClassRunner.java:51) > at > org.junit.internal.runners.JUnit4ClassRunner$1.run(JUnit4ClassRunner.java:44) > at > org.junit.internal.runners.ClassRoadie.runUnprotected(ClassRoadie.java:27) > at > org.junit.internal.runners.ClassRoadie.runProtected(ClassRoadie.java:37) > at > org.junit.internal.runners.JUnit4ClassRunner.run(JUnit4ClassRunner.java:42) > at > org.eclipse.jdt.internal.junit4.runner.JUnit4TestReference.run(JUnit4TestReference.java:45) > at > org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38) > at > org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:460) > at > org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:673) > at > org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:386) > at > org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:196) > Caused by: javax.security.auth.login.LoginException: > org.apache.jackrabbit.core.security.authentication.DefaultLoginModule does > not support 'principalprovider > at > org.apache.jackrabbit.core.security.authentication.LocalAuthContext.login(LocalAuthContext.java:68) > at > org.apache.jackrabbit.core.RepositoryImpl.login(RepositoryImpl.java:1346) > ... 24 more > javax.security.auth.login.LoginException: > org.apache.jackrabbit.core.security.authentication.DefaultLoginModule does > not support 'principalprovider > at > org.apache.jackrabbit.core.security.authentication.LocalAuthContext.login(LocalAuthContext.java:68) > at > org.apache.jackrabbit.core.RepositoryImpl.login(RepositoryImpl.java:1346) > at > org.apache.jackrabbit.c
[jira] Created: (JCR-1641) DefaultLoginModule/SimpleLoginModule don't support custom PrincipalProvider
DefaultLoginModule/SimpleLoginModule don't support custom PrincipalProvider --- Key: JCR-1641 URL: https://issues.apache.org/jira/browse/JCR-1641 Project: Jackrabbit Issue Type: Bug Components: jackrabbit-core, JCR 2.0, security Affects Versions: 1.5 Environment: vista jdk 1.5.0_11 Reporter: Micah Whitacre When configuring a custom PrincipalProvider for the SimpleLoginModule or DefaultLoginModule, inside of a repository.xml file with configuration such as the following: And that yields the following stacktrace: javax.jcr.LoginException: org.apache.jackrabbit.core.security.authentication.DefaultLoginModule does not support 'principalprovider: org.apache.jackrabbit.core.security.authentication.DefaultLoginModule does not support 'principalprovider: org.apache.jackrabbit.core.security.authentication.DefaultLoginModule does not support 'principalprovider at org.apache.jackrabbit.core.RepositoryImpl.login(RepositoryImpl.java:1353) at org.apache.jackrabbit.commons.AbstractRepository.login(AbstractRepository.java:53) at com.foo.jcr.PrincipalProviderTest.testPrincipalProvider(PrincipalProviderTest.java:24) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at org.junit.internal.runners.TestMethod.invoke(TestMethod.java:59) at org.junit.internal.runners.MethodRoadie.runTestMethod(MethodRoadie.java:98) at org.junit.internal.runners.MethodRoadie$2.run(MethodRoadie.java:79) at org.junit.internal.runners.MethodRoadie.runBeforesThenTestThenAfters(MethodRoadie.java:87) at org.junit.internal.runners.MethodRoadie.runTest(MethodRoadie.java:77) at org.junit.internal.runners.MethodRoadie.run(MethodRoadie.java:42) at org.junit.internal.runners.JUnit4ClassRunner.invokeTestMethod(JUnit4ClassRunner.java:88) at org.junit.internal.runners.JUnit4ClassRunner.runMethods(JUnit4ClassRunner.java:51) at org.junit.internal.runners.JUnit4ClassRunner$1.run(JUnit4ClassRunner.java:44) at org.junit.internal.runners.ClassRoadie.runUnprotected(ClassRoadie.java:27) at org.junit.internal.runners.ClassRoadie.runProtected(ClassRoadie.java:37) at org.junit.internal.runners.JUnit4ClassRunner.run(JUnit4ClassRunner.java:42) at org.eclipse.jdt.internal.junit4.runner.JUnit4TestReference.run(JUnit4TestReference.java:45) at org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38) at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:460) at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:673) at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:386) at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:196) Caused by: javax.security.auth.login.LoginException: org.apache.jackrabbit.core.security.authentication.DefaultLoginModule does not support 'principalprovider at org.apache.jackrabbit.core.security.authentication.LocalAuthContext.login(LocalAuthContext.java:68) at org.apache.jackrabbit.core.RepositoryImpl.login(RepositoryImpl.java:1346) ... 24 more javax.security.auth.login.LoginException: org.apache.jackrabbit.core.security.authentication.DefaultLoginModule does not support 'principalprovider at org.apache.jackrabbit.core.security.authentication.LocalAuthContext.login(LocalAuthContext.java:68) at org.apache.jackrabbit.core.RepositoryImpl.login(RepositoryImpl.java:1346) at org.apache.jackrabbit.commons.AbstractRepository.login(AbstractRepository.java:53) at com.foo.jcr.PrincipalProviderTest.testPrincipalProvider(PrincipalProviderTest.java:24) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at org.junit.internal.runners.TestMethod.invoke(TestMethod.java:59) at org.junit.internal.runners.MethodRoadie.runTestMethod(MethodRoadie.java:98) at org.junit.internal.runners.MethodRoadie$2.run(MethodRoadie.java:79) at org.junit.internal.runners.MethodRoadie.runBeforesThenTestThenAfters(MethodRoadie.java:87) at org.junit.internal.runners.M
[jira] Commented: (JCR-1639) Setting AccessControlEntry on a versioned Node throws exception
[
https://issues.apache.org/jira/browse/JCR-1639?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12602671#action_12602671
]
Micah Whitacre commented on JCR-1639:
-
So just to be clear my use case of access control on versioned nodes is
invalid? Or the manner in which I'm trying to accomplish it invalid?
> Setting AccessControlEntry on a versioned Node throws exception
> ---
>
> Key: JCR-1639
> URL: https://issues.apache.org/jira/browse/JCR-1639
> Project: Jackrabbit
> Issue Type: Bug
>Affects Versions: 1.5
> Environment: windows vista jdk1.5.0_11
>Reporter: Micah Whitacre
>
> I realized the code is in flux and not released but I figured I'd log a bug
> anyway to track the issue:
> I have a repository where every node has the mixin type of "mix:versionable".
> My repository.xml is setup to use the DefaultAccessManager and when I try to
> make the following call:
> AccessControlManager manager = sessionImpl.getAccessControlManager();
> Privilege[] privs = new Privilege[] {
> PrivilegeRegistry.WRITE_PRIVILEGE };
> AccessControlEntry entry =
> manager.addAccessControlEntry(fooNode.getPath(), principal,
> privs);
> sessionImpl.save();
> on that node it throws the following exception:
> Caused by: javax.jcr.version.VersionException: /cerner/foo: cannot add a
> mixin node type to a checked-in node
> at org.apache.jackrabbit.core.NodeImpl.addMixin(NodeImpl.java:1024)
> at
> org.apache.jackrabbit.core.security.authorization.acl.ACLEditor.createAclNode(ACLEditor.java:299)
> at
> org.apache.jackrabbit.core.security.authorization.acl.ACLEditor.setPolicyTemplate(ACLEditor.java:131)
> at
> org.apache.jackrabbit.core.security.authorization.acl.ACLEditor.addAccessControlEntry(ACLEditor.java:214)
> at
> org.apache.jackrabbit.core.security.DefaultAccessManager.addAccessControlEntry(DefaultAccessManager.java:389)
> It has to do with the fact inside ACLEditor.createACLNode(...) it doesn't
> checkout the node before trying to add the new mixin type of
> NT_REP_ACCESS_CONTROLLABLE.
> I'll work on craating a test case that will generate the stack trace.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (JCR-1640) Not configuring the adminId, anonymousId, or defaultuserId causes login module to ignore credentials
[ https://issues.apache.org/jira/browse/JCR-1640?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Micah Whitacre updated JCR-1640: Attachment: jcr1640.zip Testcase and repository.xml file that shows the configuration that will generate the exception. > Not configuring the adminId, anonymousId, or defaultuserId causes login > module to ignore credentials > > > Key: JCR-1640 > URL: https://issues.apache.org/jira/browse/JCR-1640 > Project: Jackrabbit > Issue Type: Bug > Components: jackrabbit-core, security >Affects Versions: 1.5 > Environment: vista 1.5.0_11 >Reporter: Micah Whitacre > Attachments: jcr1640.zip > > > Using the DefaultLoginModule, DefaultAccessManager, and > DefaultSecurityManager and calling Repository.login(Credentials) causes the > following stack trace to be thrown. > javax.jcr.LoginException: LoginModule ignored Credentials: LoginModule > ignored Credentials: LoginModule ignored Credentials > at > org.apache.jackrabbit.core.RepositoryImpl.login(RepositoryImpl.java:1353) > at > org.apache.jackrabbit.commons.AbstractRepository.login(AbstractRepository.java:53) > at > com.cerner.system.configuration.repository.jcr.JackrabbitTest.testLoginWithCredentials(JackrabbitTest.java:23) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) > at java.lang.reflect.Method.invoke(Method.java:585) > at org.junit.internal.runners.TestMethod.invoke(TestMethod.java:59) > at > org.junit.internal.runners.MethodRoadie.runTestMethod(MethodRoadie.java:98) > at org.junit.internal.runners.MethodRoadie$2.run(MethodRoadie.java:79) > at > org.junit.internal.runners.MethodRoadie.runBeforesThenTestThenAfters(MethodRoadie.java:87) > at org.junit.internal.runners.MethodRoadie.runTest(MethodRoadie.java:77) > at org.junit.internal.runners.MethodRoadie.run(MethodRoadie.java:42) > at > org.junit.internal.runners.JUnit4ClassRunner.invokeTestMethod(JUnit4ClassRunner.java:88) > at > org.junit.internal.runners.JUnit4ClassRunner.runMethods(JUnit4ClassRunner.java:51) > at > org.junit.internal.runners.JUnit4ClassRunner$1.run(JUnit4ClassRunner.java:44) > at > org.junit.internal.runners.ClassRoadie.runUnprotected(ClassRoadie.java:27) > at > org.junit.internal.runners.ClassRoadie.runProtected(ClassRoadie.java:37) > at > org.junit.internal.runners.JUnit4ClassRunner.run(JUnit4ClassRunner.java:42) > at > org.eclipse.jdt.internal.junit4.runner.JUnit4TestReference.run(JUnit4TestReference.java:45) > at > org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38) > at > org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:460) > at > org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:673) > at > org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:386) > at > org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:196) > Caused by: javax.security.auth.login.FailedLoginException: LoginModule > ignored Credentials > at > org.apache.jackrabbit.core.security.authentication.LocalAuthContext.login(LocalAuthContext.java:73) > at > org.apache.jackrabbit.core.RepositoryImpl.login(RepositoryImpl.java:1346) > ... 24 more > javax.security.auth.login.FailedLoginException: LoginModule ignored > Credentials > at > org.apache.jackrabbit.core.security.authentication.LocalAuthContext.login(LocalAuthContext.java:73) > at > org.apache.jackrabbit.core.RepositoryImpl.login(RepositoryImpl.java:1346) > at > org.apache.jackrabbit.commons.AbstractRepository.login(AbstractRepository.java:53) > at > com.cerner.system.configuration.repository.jcr.JackrabbitTest.testLoginWithCredentials(JackrabbitTest.java:23) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) > at java.lang.reflect.Method.invoke(Method.java:585) > at org.junit.internal.runners.TestMethod.invoke(TestMethod.java:59) > at > org.junit.internal.runners.MethodRoadie.runTestMethod(MethodRoadie.java:98) > at org.junit.internal.runners.MethodRoadie$2.run(MethodRoadie.java:79) > at > org.junit.internal.runners.MethodRoadie.runBeforesThenTestThenAfters(MethodRoadie.java:87
[jira] Created: (JCR-1640) Not configuring the adminId, anonymousId, or defaultuserId causes login module to ignore credentials
Not configuring the adminId, anonymousId, or defaultuserId causes login module to ignore credentials Key: JCR-1640 URL: https://issues.apache.org/jira/browse/JCR-1640 Project: Jackrabbit Issue Type: Bug Components: jackrabbit-core, security Affects Versions: 1.5 Environment: vista 1.5.0_11 Reporter: Micah Whitacre Using the DefaultLoginModule, DefaultAccessManager, and DefaultSecurityManager and calling Repository.login(Credentials) causes the following stack trace to be thrown. javax.jcr.LoginException: LoginModule ignored Credentials: LoginModule ignored Credentials: LoginModule ignored Credentials at org.apache.jackrabbit.core.RepositoryImpl.login(RepositoryImpl.java:1353) at org.apache.jackrabbit.commons.AbstractRepository.login(AbstractRepository.java:53) at com.cerner.system.configuration.repository.jcr.JackrabbitTest.testLoginWithCredentials(JackrabbitTest.java:23) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at org.junit.internal.runners.TestMethod.invoke(TestMethod.java:59) at org.junit.internal.runners.MethodRoadie.runTestMethod(MethodRoadie.java:98) at org.junit.internal.runners.MethodRoadie$2.run(MethodRoadie.java:79) at org.junit.internal.runners.MethodRoadie.runBeforesThenTestThenAfters(MethodRoadie.java:87) at org.junit.internal.runners.MethodRoadie.runTest(MethodRoadie.java:77) at org.junit.internal.runners.MethodRoadie.run(MethodRoadie.java:42) at org.junit.internal.runners.JUnit4ClassRunner.invokeTestMethod(JUnit4ClassRunner.java:88) at org.junit.internal.runners.JUnit4ClassRunner.runMethods(JUnit4ClassRunner.java:51) at org.junit.internal.runners.JUnit4ClassRunner$1.run(JUnit4ClassRunner.java:44) at org.junit.internal.runners.ClassRoadie.runUnprotected(ClassRoadie.java:27) at org.junit.internal.runners.ClassRoadie.runProtected(ClassRoadie.java:37) at org.junit.internal.runners.JUnit4ClassRunner.run(JUnit4ClassRunner.java:42) at org.eclipse.jdt.internal.junit4.runner.JUnit4TestReference.run(JUnit4TestReference.java:45) at org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38) at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:460) at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:673) at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:386) at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:196) Caused by: javax.security.auth.login.FailedLoginException: LoginModule ignored Credentials at org.apache.jackrabbit.core.security.authentication.LocalAuthContext.login(LocalAuthContext.java:73) at org.apache.jackrabbit.core.RepositoryImpl.login(RepositoryImpl.java:1346) ... 24 more javax.security.auth.login.FailedLoginException: LoginModule ignored Credentials at org.apache.jackrabbit.core.security.authentication.LocalAuthContext.login(LocalAuthContext.java:73) at org.apache.jackrabbit.core.RepositoryImpl.login(RepositoryImpl.java:1346) at org.apache.jackrabbit.commons.AbstractRepository.login(AbstractRepository.java:53) at com.cerner.system.configuration.repository.jcr.JackrabbitTest.testLoginWithCredentials(JackrabbitTest.java:23) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at org.junit.internal.runners.TestMethod.invoke(TestMethod.java:59) at org.junit.internal.runners.MethodRoadie.runTestMethod(MethodRoadie.java:98) at org.junit.internal.runners.MethodRoadie$2.run(MethodRoadie.java:79) at org.junit.internal.runners.MethodRoadie.runBeforesThenTestThenAfters(MethodRoadie.java:87) at org.junit.internal.runners.MethodRoadie.runTest(MethodRoadie.java:77) at org.junit.internal.runners.MethodRoadie.run(MethodRoadie.java:42) at org.junit.internal.runners.JUnit4ClassRunner.invokeTestMethod(JUnit4ClassRunner.java:88) at org.junit.internal.runners.JUnit4ClassRunner.runMethods(JUnit4ClassRunner.java:51) at org.junit.internal.runners.JUnit4ClassRunner$1.run(JUnit4ClassRunner.java:44)
[jira] Created: (JCR-1639) Setting AccessControlEntry on a versioned Node throws exception
Setting AccessControlEntry on a versioned Node throws exception
---
Key: JCR-1639
URL: https://issues.apache.org/jira/browse/JCR-1639
Project: Jackrabbit
Issue Type: Bug
Affects Versions: 1.5
Environment: windows vista jdk1.5.0_11
Reporter: Micah Whitacre
I realized the code is in flux and not released but I figured I'd log a bug
anyway to track the issue:
I have a repository where every node has the mixin type of "mix:versionable".
My repository.xml is setup to use the DefaultAccessManager and when I try to
make the following call:
AccessControlManager manager = sessionImpl.getAccessControlManager();
Privilege[] privs = new Privilege[] { PrivilegeRegistry.WRITE_PRIVILEGE
};
AccessControlEntry entry =
manager.addAccessControlEntry(fooNode.getPath(), principal,
privs);
sessionImpl.save();
on that node it throws the following exception:
Caused by: javax.jcr.version.VersionException: /cerner/foo: cannot add a mixin
node type to a checked-in node
at org.apache.jackrabbit.core.NodeImpl.addMixin(NodeImpl.java:1024)
at
org.apache.jackrabbit.core.security.authorization.acl.ACLEditor.createAclNode(ACLEditor.java:299)
at
org.apache.jackrabbit.core.security.authorization.acl.ACLEditor.setPolicyTemplate(ACLEditor.java:131)
at
org.apache.jackrabbit.core.security.authorization.acl.ACLEditor.addAccessControlEntry(ACLEditor.java:214)
at
org.apache.jackrabbit.core.security.DefaultAccessManager.addAccessControlEntry(DefaultAccessManager.java:389)
It has to do with the fact inside ACLEditor.createACLNode(...) it doesn't
checkout the node before trying to add the new mixin type of
NT_REP_ACCESS_CONTROLLABLE.
I'll work on craating a test case that will generate the stack trace.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (JCR-1440) NPE Thrown when two Cluster Nodes are hitting the same underlying database.
[ https://issues.apache.org/jira/browse/JCR-1440?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12598468#action_12598468 ] Micah Whitacre commented on JCR-1440: - Ryan's patch fixes the issue I was seeing. I agree it isn't necessarily the most elegant solution. Can someone review his patch and commit it to trunk or perhaps propose a better solution? Thanks. > NPE Thrown when two Cluster Nodes are hitting the same underlying database. > --- > > Key: JCR-1440 > URL: https://issues.apache.org/jira/browse/JCR-1440 > Project: Jackrabbit > Issue Type: Bug > Components: clustering, jackrabbit-core >Affects Versions: 1.4, core 1.4.1 > Environment: Vista JDK 1.5.0_12. Using Derby and Derby Client > 10.1.2.1 >Reporter: Micah Whitacre >Priority: Critical > Attachments: jcr-1440-workaround.patch, repository1.xml, > SimpleJackrabbitConflictTest.java, SimpleJackRabbitTest.zip > > > I've created a test that creates two repositories with clustering enabled > that are backed by the same database. Using the following workflow causes a > NullPointerException to be thrown. > The workflow I'm using is: > The root node is versioned. > ClusterNode1 creates a versioned child node named "foo". > The test waits to make sure the syncDelay has passed so ClusterNode2 will > notice the newly created node. > ClusterNode2 retrieves the "foo" child node and removes it. > The test waits for the change ClusterNode1 to sync with that change. > ClusterNode1 tries to create another new node however a NullPointerException > is thrown when the it tries to checkout the rootNode. > java.lang.NullPointerException: null values not allowed > at > org.apache.commons.collections.map.AbstractReferenceMap.put(AbstractReferenceMap.java:251) > at > org.apache.jackrabbit.core.version.VersionManagerImpl.getItem(VersionManagerImpl.java:280) > at > org.apache.jackrabbit.core.version.XAVersionManager.getItem(XAVersionManager.java:334) > at > org.apache.jackrabbit.core.version.AbstractVersionManager.getVersion(AbstractVersionManager.java:87) > at > org.apache.jackrabbit.core.NodeImpl.getBaseVersion(NodeImpl.java:3198) > at org.apache.jackrabbit.core.NodeImpl.checkout(NodeImpl.java:2991) > at > com.cerner.system.configuration.repository.jcr.SimpleJackrabbitConflictTest.testNullPointerExceptionThrown(SimpleJackrabbitConflictTest.java:96) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (JCR-1553) ClusterNode not properly shutdown when repository has shutdown
ClusterNode not properly shutdown when repository has shutdown -- Key: JCR-1553 URL: https://issues.apache.org/jira/browse/JCR-1553 Project: Jackrabbit Issue Type: Bug Components: clustering, jackrabbit-core Affects Versions: core 1.4.1 Environment: windows vista jdk 1.5.0_11. Reporter: Micah Whitacre Sometimes when the repository is shutdown the ClusterNode is not shutdown and it therefore tries to update records or access a closed Journal file. The setup that generated the exception is I have 3 VMs each with a Repository that are all connected to the same database. In the below stack trace one of the repositories is being shutdown however the ClusterNode thread is also trying to update the repository journal at the same time. Below is a copy of the stack trace. [4/23/08 9:58:52:496 CDT] 0061 SystemOut O 89811653 [WebContainer : 2] INFO org.apache.jackrabbit.core.RepositoryImpl - Shutting down repository... [4/23/08 9:58:52:511 CDT] 054c SystemOut O 89811621 [ClusterNode-b06e4fe7-a602-4a93-b106-e0834046ae0f] INFO org.apache.jackrabbit.core.cluster.ClusterNode - Processing revision: 7174 [4/23/08 9:58:52:527 CDT] 0061 SystemOut O 89811684 [WebContainer : 2] INFO org.apache.jackrabbit.core.RepositoryImpl - shutting down workspace 'default'... [4/23/08 9:58:52:574 CDT] 0061 SystemOut O 89811715 [WebContainer : 2] INFO org.apache.jackrabbit.core.observation.ObservationDispatcher - Notification of EventListeners stopped. [4/23/08 9:58:53:058 CDT] 0061 SystemOut O 89812215 [WebContainer : 2] INFO org.apache.jackrabbit.core.RepositoryImpl - workspace 'default' has been shutdown [4/23/08 9:58:53:308 CDT] 0308 SystemOut O 91641048 [ClusterNode-e609e8a6-320e-44ea-be0f-ab8c5cb89662] INFO org.apache.jackrabbit.core.cluster.ClusterNode - Processing revision: 7165 [4/23/08 9:58:53:324 CDT] 0308 SystemOut O 91641064 [ClusterNode-e609e8a6-320e-44ea-be0f-ab8c5cb89662] INFO org.apache.jackrabbit.core.cluster.ClusterNode - Processing revision: 7166 [4/23/08 9:58:53:324 CDT] 0308 SystemOut O 91641064 [ClusterNode-e609e8a6-320e-44ea-be0f-ab8c5cb89662] INFO org.apache.jackrabbit.core.cluster.ClusterNode - Processing revision: 7167 [4/23/08 9:58:53:339 CDT] 0308 SystemOut O 91641079 [ClusterNode-e609e8a6-320e-44ea-be0f-ab8c5cb89662] INFO org.apache.jackrabbit.core.cluster.ClusterNode - Processing revision: 7168 [4/23/08 9:58:53:339 CDT] 0308 SystemOut O 91641079 [ClusterNode-e609e8a6-320e-44ea-be0f-ab8c5cb89662] INFO org.apache.jackrabbit.core.cluster.ClusterNode - Processing revision: 7169 [4/23/08 9:58:53:355 CDT] 0308 SystemOut O 91641095 [ClusterNode-e609e8a6-320e-44ea-be0f-ab8c5cb89662] INFO org.apache.jackrabbit.core.cluster.ClusterNode - Processing revision: 7170 [4/23/08 9:58:53:371 CDT] 0308 SystemOut O 9164 [ClusterNode-e609e8a6-320e-44ea-be0f-ab8c5cb89662] INFO org.apache.jackrabbit.core.cluster.ClusterNode - Processing revision: 7171 [4/23/08 9:58:53:386 CDT] 0308 SystemOut O 91641126 [ClusterNode-e609e8a6-320e-44ea-be0f-ab8c5cb89662] INFO org.apache.jackrabbit.core.cluster.ClusterNode - Processing revision: 7172 [4/23/08 9:58:53:417 CDT] 0308 SystemOut O 91641157 [ClusterNode-e609e8a6-320e-44ea-be0f-ab8c5cb89662] INFO org.apache.jackrabbit.core.cluster.ClusterNode - Processing revision: 7173 [4/23/08 9:58:53:433 CDT] 0308 SystemOut O 91641173 [ClusterNode-e609e8a6-320e-44ea-be0f-ab8c5cb89662] INFO org.apache.jackrabbit.core.cluster.ClusterNode - Processing revision: 7174 [4/23/08 9:58:53:433 CDT] 0308 SystemOut O 91641173 [ClusterNode-e609e8a6-320e-44ea-be0f-ab8c5cb89662] INFO org.apache.jackrabbit.core.cluster.ClusterNode - Processing revision: 7175 [4/23/08 9:58:53:496 CDT] 0308 SystemOut O 91641236 [ClusterNode-e609e8a6-320e-44ea-be0f-ab8c5cb89662] INFO org.apache.jackrabbit.core.journal.AbstractJournal - Synchronized to revision: 7175 [4/23/08 9:58:54:292 CDT] 0131 SystemOut O 89171473 [ClusterNode-4930503b-ab33--999e-c87fb3681bf7] INFO org.apache.jackrabbit.core.cluster.ClusterNode - Processing revision: 7173 [4/23/08 9:58:54:308 CDT] 0131 SystemOut O 89171504 [ClusterNode-4930503b-ab33--999e-c87fb3681bf7] INFO org.apache.jackrabbit.core.cluster.ClusterNode - Processing revision: 7174 [4/23/08 9:58:54:308 CDT] 0131 SystemOut O 89171504 [ClusterNode-4930503b-ab33--999e-c87fb3681bf7] INFO org.apache.jackrabbit.core.cluster.ClusterNode - Processing revision: 7175 [4/23/08 9:58:54:386 CDT] 0131 SystemOut O 89171582 [ClusterNode-4930503b-ab33--999e-c87fb3681bf7] INFO org.apache.jackrabbit.core.journal.AbstractJournal - Synchronized to revision: 7175 [4/23/08 9:58:55:417 CDT] 0061 S
[jira] Commented: (JCR-1440) NPE Thrown when two Cluster Nodes are hitting the same underlying database.
[ https://issues.apache.org/jira/browse/JCR-1440?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12582058#action_12582058 ] Micah Whitacre commented on JCR-1440: - It should also be noted that this is not purely related to removing nodes. I've changed the test around so the two nodes are adding independent child nodes to the root and it causes the same NPE exception to be thrown when trying to find the item at the item for the given id. > NPE Thrown when two Cluster Nodes are hitting the same underlying database. > --- > > Key: JCR-1440 > URL: https://issues.apache.org/jira/browse/JCR-1440 > Project: Jackrabbit > Issue Type: Bug > Components: clustering, jackrabbit-core >Affects Versions: 1.4, core 1.4.1 > Environment: Vista JDK 1.5.0_12. Using Derby and Derby Client > 10.1.2.1 >Reporter: Micah Whitacre >Priority: Critical > Attachments: repository1.xml, SimpleJackrabbitConflictTest.java, > SimpleJackRabbitTest.zip > > > I've created a test that creates two repositories with clustering enabled > that are backed by the same database. Using the following workflow causes a > NullPointerException to be thrown. > The workflow I'm using is: > The root node is versioned. > ClusterNode1 creates a versioned child node named "foo". > The test waits to make sure the syncDelay has passed so ClusterNode2 will > notice the newly created node. > ClusterNode2 retrieves the "foo" child node and removes it. > The test waits for the change ClusterNode1 to sync with that change. > ClusterNode1 tries to create another new node however a NullPointerException > is thrown when the it tries to checkout the rootNode. > java.lang.NullPointerException: null values not allowed > at > org.apache.commons.collections.map.AbstractReferenceMap.put(AbstractReferenceMap.java:251) > at > org.apache.jackrabbit.core.version.VersionManagerImpl.getItem(VersionManagerImpl.java:280) > at > org.apache.jackrabbit.core.version.XAVersionManager.getItem(XAVersionManager.java:334) > at > org.apache.jackrabbit.core.version.AbstractVersionManager.getVersion(AbstractVersionManager.java:87) > at > org.apache.jackrabbit.core.NodeImpl.getBaseVersion(NodeImpl.java:3198) > at org.apache.jackrabbit.core.NodeImpl.checkout(NodeImpl.java:2991) > at > com.cerner.system.configuration.repository.jcr.SimpleJackrabbitConflictTest.testNullPointerExceptionThrown(SimpleJackrabbitConflictTest.java:96) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (JCR-1440) NPE Thrown when two Cluster Nodes are hitting the same underlying database.
[ https://issues.apache.org/jira/browse/JCR-1440?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12582054#action_12582054 ] Micah Whitacre commented on JCR-1440: - I'm still trying to find a workaround or solution to this issue. Looking at the code the issues comes from the fact that the map, versionItems, of VersionManagerImpl class is never updated/syncrhonized between the two cluster nodes. The only time this method is changed is on calls to itemsUpdated(Collection) which is never called during the synchronization process. So that map becomes stale pretty quickly when multiple nodes are interacting with it. > NPE Thrown when two Cluster Nodes are hitting the same underlying database. > --- > > Key: JCR-1440 > URL: https://issues.apache.org/jira/browse/JCR-1440 > Project: Jackrabbit > Issue Type: Bug > Components: clustering, jackrabbit-core >Affects Versions: 1.4, core 1.4.1 > Environment: Vista JDK 1.5.0_12. Using Derby and Derby Client > 10.1.2.1 >Reporter: Micah Whitacre >Priority: Critical > Attachments: repository1.xml, SimpleJackrabbitConflictTest.java, > SimpleJackRabbitTest.zip > > > I've created a test that creates two repositories with clustering enabled > that are backed by the same database. Using the following workflow causes a > NullPointerException to be thrown. > The workflow I'm using is: > The root node is versioned. > ClusterNode1 creates a versioned child node named "foo". > The test waits to make sure the syncDelay has passed so ClusterNode2 will > notice the newly created node. > ClusterNode2 retrieves the "foo" child node and removes it. > The test waits for the change ClusterNode1 to sync with that change. > ClusterNode1 tries to create another new node however a NullPointerException > is thrown when the it tries to checkout the rootNode. > java.lang.NullPointerException: null values not allowed > at > org.apache.commons.collections.map.AbstractReferenceMap.put(AbstractReferenceMap.java:251) > at > org.apache.jackrabbit.core.version.VersionManagerImpl.getItem(VersionManagerImpl.java:280) > at > org.apache.jackrabbit.core.version.XAVersionManager.getItem(XAVersionManager.java:334) > at > org.apache.jackrabbit.core.version.AbstractVersionManager.getVersion(AbstractVersionManager.java:87) > at > org.apache.jackrabbit.core.NodeImpl.getBaseVersion(NodeImpl.java:3198) > at org.apache.jackrabbit.core.NodeImpl.checkout(NodeImpl.java:2991) > at > com.cerner.system.configuration.repository.jcr.SimpleJackrabbitConflictTest.testNullPointerExceptionThrown(SimpleJackrabbitConflictTest.java:96) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (JCR-1440) NPE Thrown when two Cluster Nodes are hitting the same underlying database.
[
https://issues.apache.org/jira/browse/JCR-1440?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Micah Whitacre updated JCR-1440:
Attachment: SimpleJackrabbitConflictTest.java
I have been playing around with the test a bit and have found that if I don't
wait for the clusters to synchronize after deleting the node "foo" that I will
get the following stack trace when trying to check out the root node of he
first session again.
Not completely related to this bug but thought I'd post what I was finding.
javax.jcr.InvalidItemStateException:
cafebabe-cafe-babe-cafe-babecafebabe/{http://www.jcp.org/jcr/1.0}isCheckedOut
has been modified externally
at org.apache.jackrabbit.core.ItemImpl.save(ItemImpl.java:1248)
at org.apache.jackrabbit.core.SessionImpl.save(SessionImpl.java:896)
at org.apache.jackrabbit.core.NodeImpl.checkout(NodeImpl.java:3001)
at
com.cerner.system.configuration.repository.jcr.SimpleJackrabbitConflictTest.testNullPointerExceptionThrown(SimpleJackrabbitConflictTest.java:99)
> NPE Thrown when two Cluster Nodes are hitting the same underlying database.
> ---
>
> Key: JCR-1440
> URL: https://issues.apache.org/jira/browse/JCR-1440
> Project: Jackrabbit
> Issue Type: Bug
>Affects Versions: 1.4, core 1.4.1
> Environment: Vista JDK 1.5.0_12. Using Derby and Derby Client
> 10.1.2.1
>Reporter: Micah Whitacre
>Priority: Critical
> Attachments: repository1.xml, SimpleJackrabbitConflictTest.java,
> SimpleJackRabbitTest.zip
>
>
> I've created a test that creates two repositories with clustering enabled
> that are backed by the same database. Using the following workflow causes a
> NullPointerException to be thrown.
> The workflow I'm using is:
> The root node is versioned.
> ClusterNode1 creates a versioned child node named "foo".
> The test waits to make sure the syncDelay has passed so ClusterNode2 will
> notice the newly created node.
> ClusterNode2 retrieves the "foo" child node and removes it.
> The test waits for the change ClusterNode1 to sync with that change.
> ClusterNode1 tries to create another new node however a NullPointerException
> is thrown when the it tries to checkout the rootNode.
> java.lang.NullPointerException: null values not allowed
> at
> org.apache.commons.collections.map.AbstractReferenceMap.put(AbstractReferenceMap.java:251)
> at
> org.apache.jackrabbit.core.version.VersionManagerImpl.getItem(VersionManagerImpl.java:280)
> at
> org.apache.jackrabbit.core.version.XAVersionManager.getItem(XAVersionManager.java:334)
> at
> org.apache.jackrabbit.core.version.AbstractVersionManager.getVersion(AbstractVersionManager.java:87)
> at
> org.apache.jackrabbit.core.NodeImpl.getBaseVersion(NodeImpl.java:3198)
> at org.apache.jackrabbit.core.NodeImpl.checkout(NodeImpl.java:2991)
> at
> com.cerner.system.configuration.repository.jcr.SimpleJackrabbitConflictTest.testNullPointerExceptionThrown(SimpleJackrabbitConflictTest.java:96)
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (JCR-1440) NPE Thrown when two Cluster Nodes are hitting the same underlying database.
[ https://issues.apache.org/jira/browse/JCR-1440?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Micah Whitacre updated JCR-1440: Attachment: repository1.xml I've played around with my configuration a bit more and am still not able to get rid of the NPE. In this attachment I modified the repository1.xml file to use the bundle.PersistenceManager and configured a DbDataStore. For the testing purposes repository2.xml is an exact duplicate of the attachment (with a different cluster id). This change in configuration does not fix the NPE. This still seems like an Jackrabbit issue instead of an error in my configuration. > NPE Thrown when two Cluster Nodes are hitting the same underlying database. > --- > > Key: JCR-1440 > URL: https://issues.apache.org/jira/browse/JCR-1440 > Project: Jackrabbit > Issue Type: Bug >Affects Versions: 1.4, core 1.4.1 > Environment: Vista JDK 1.5.0_12. Using Derby and Derby Client > 10.1.2.1 >Reporter: Micah Whitacre >Priority: Critical > Attachments: repository1.xml, SimpleJackRabbitTest.zip > > > I've created a test that creates two repositories with clustering enabled > that are backed by the same database. Using the following workflow causes a > NullPointerException to be thrown. > The workflow I'm using is: > The root node is versioned. > ClusterNode1 creates a versioned child node named "foo". > The test waits to make sure the syncDelay has passed so ClusterNode2 will > notice the newly created node. > ClusterNode2 retrieves the "foo" child node and removes it. > The test waits for the change ClusterNode1 to sync with that change. > ClusterNode1 tries to create another new node however a NullPointerException > is thrown when the it tries to checkout the rootNode. > java.lang.NullPointerException: null values not allowed > at > org.apache.commons.collections.map.AbstractReferenceMap.put(AbstractReferenceMap.java:251) > at > org.apache.jackrabbit.core.version.VersionManagerImpl.getItem(VersionManagerImpl.java:280) > at > org.apache.jackrabbit.core.version.XAVersionManager.getItem(XAVersionManager.java:334) > at > org.apache.jackrabbit.core.version.AbstractVersionManager.getVersion(AbstractVersionManager.java:87) > at > org.apache.jackrabbit.core.NodeImpl.getBaseVersion(NodeImpl.java:3198) > at org.apache.jackrabbit.core.NodeImpl.checkout(NodeImpl.java:2991) > at > com.cerner.system.configuration.repository.jcr.SimpleJackrabbitConflictTest.testNullPointerExceptionThrown(SimpleJackrabbitConflictTest.java:96) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (JCR-1440) NPE Thrown when two Cluster Nodes are hitting the same underlying database.
[ https://issues.apache.org/jira/browse/JCR-1440?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12575431#action_12575431 ] Micah Whitacre commented on JCR-1440: - I changed PMs and the Clustering to use the org.apache.derby.jdbc.Driver30 and I still get the same exception. You mentioned that the PMs needed to use a shared datasource. What additional configuration is needed for me to be able to do that? Do I need to configure a DataSource[1] at the top of the configuration? I've been using the Clustering[2] wiki page as my guide and it doesn't show any special configuration for using the OraclePersistenceManager. I'm actually seeing this issue when hitting an Oracle database. I just used an embedded derby database for this example/tests. [1] - http://wiki.apache.org/jackrabbit/DataStore [2] - http://wiki.apache.org/jackrabbit/Clustering > NPE Thrown when two Cluster Nodes are hitting the same underlying database. > --- > > Key: JCR-1440 > URL: https://issues.apache.org/jira/browse/JCR-1440 > Project: Jackrabbit > Issue Type: Bug >Affects Versions: 1.4, core 1.4.1 > Environment: Vista JDK 1.5.0_12. Using Derby and Derby Client > 10.1.2.1 >Reporter: Micah Whitacre >Priority: Critical > Attachments: SimpleJackRabbitTest.zip > > > I've created a test that creates two repositories with clustering enabled > that are backed by the same database. Using the following workflow causes a > NullPointerException to be thrown. > The workflow I'm using is: > The root node is versioned. > ClusterNode1 creates a versioned child node named "foo". > The test waits to make sure the syncDelay has passed so ClusterNode2 will > notice the newly created node. > ClusterNode2 retrieves the "foo" child node and removes it. > The test waits for the change ClusterNode1 to sync with that change. > ClusterNode1 tries to create another new node however a NullPointerException > is thrown when the it tries to checkout the rootNode. > java.lang.NullPointerException: null values not allowed > at > org.apache.commons.collections.map.AbstractReferenceMap.put(AbstractReferenceMap.java:251) > at > org.apache.jackrabbit.core.version.VersionManagerImpl.getItem(VersionManagerImpl.java:280) > at > org.apache.jackrabbit.core.version.XAVersionManager.getItem(XAVersionManager.java:334) > at > org.apache.jackrabbit.core.version.AbstractVersionManager.getVersion(AbstractVersionManager.java:87) > at > org.apache.jackrabbit.core.NodeImpl.getBaseVersion(NodeImpl.java:3198) > at org.apache.jackrabbit.core.NodeImpl.checkout(NodeImpl.java:2991) > at > com.cerner.system.configuration.repository.jcr.SimpleJackrabbitConflictTest.testNullPointerExceptionThrown(SimpleJackrabbitConflictTest.java:96) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (JCR-1440) NPE Thrown when two Cluster Nodes are hitting the same underlying database.
NPE Thrown when two Cluster Nodes are hitting the same underlying database. --- Key: JCR-1440 URL: https://issues.apache.org/jira/browse/JCR-1440 Project: Jackrabbit Issue Type: Bug Affects Versions: core 1.4.1, 1.4 Environment: Vista JDK 1.5.0_12. Using Derby and Derby Client 10.1.2.1 Reporter: Micah Whitacre Priority: Critical Attachments: SimpleJackRabbitTest.zip I've created a test that creates two repositories with clustering enabled that are backed by the same database. Using the following workflow causes a NullPointerException to be thrown. The workflow I'm using is: The root node is versioned. ClusterNode1 creates a versioned child node named "foo". The test waits to make sure the syncDelay has passed so ClusterNode2 will notice the newly created node. ClusterNode2 retrieves the "foo" child node and removes it. The test waits for the change ClusterNode1 to sync with that change. ClusterNode1 tries to create another new node however a NullPointerException is thrown when the it tries to checkout the rootNode. java.lang.NullPointerException: null values not allowed at org.apache.commons.collections.map.AbstractReferenceMap.put(AbstractReferenceMap.java:251) at org.apache.jackrabbit.core.version.VersionManagerImpl.getItem(VersionManagerImpl.java:280) at org.apache.jackrabbit.core.version.XAVersionManager.getItem(XAVersionManager.java:334) at org.apache.jackrabbit.core.version.AbstractVersionManager.getVersion(AbstractVersionManager.java:87) at org.apache.jackrabbit.core.NodeImpl.getBaseVersion(NodeImpl.java:3198) at org.apache.jackrabbit.core.NodeImpl.checkout(NodeImpl.java:2991) at com.cerner.system.configuration.repository.jcr.SimpleJackrabbitConflictTest.testNullPointerExceptionThrown(SimpleJackrabbitConflictTest.java:96) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (JCR-1440) NPE Thrown when two Cluster Nodes are hitting the same underlying database.
[ https://issues.apache.org/jira/browse/JCR-1440?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Micah Whitacre updated JCR-1440: Attachment: SimpleJackRabbitTest.zip The test I used to create this exception and the two repository configuration files I used to configure the two nodes. > NPE Thrown when two Cluster Nodes are hitting the same underlying database. > --- > > Key: JCR-1440 > URL: https://issues.apache.org/jira/browse/JCR-1440 > Project: Jackrabbit > Issue Type: Bug >Affects Versions: 1.4, core 1.4.1 > Environment: Vista JDK 1.5.0_12. Using Derby and Derby Client > 10.1.2.1 >Reporter: Micah Whitacre >Priority: Critical > Attachments: SimpleJackRabbitTest.zip > > > I've created a test that creates two repositories with clustering enabled > that are backed by the same database. Using the following workflow causes a > NullPointerException to be thrown. > The workflow I'm using is: > The root node is versioned. > ClusterNode1 creates a versioned child node named "foo". > The test waits to make sure the syncDelay has passed so ClusterNode2 will > notice the newly created node. > ClusterNode2 retrieves the "foo" child node and removes it. > The test waits for the change ClusterNode1 to sync with that change. > ClusterNode1 tries to create another new node however a NullPointerException > is thrown when the it tries to checkout the rootNode. > java.lang.NullPointerException: null values not allowed > at > org.apache.commons.collections.map.AbstractReferenceMap.put(AbstractReferenceMap.java:251) > at > org.apache.jackrabbit.core.version.VersionManagerImpl.getItem(VersionManagerImpl.java:280) > at > org.apache.jackrabbit.core.version.XAVersionManager.getItem(XAVersionManager.java:334) > at > org.apache.jackrabbit.core.version.AbstractVersionManager.getVersion(AbstractVersionManager.java:87) > at > org.apache.jackrabbit.core.NodeImpl.getBaseVersion(NodeImpl.java:3198) > at org.apache.jackrabbit.core.NodeImpl.checkout(NodeImpl.java:2991) > at > com.cerner.system.configuration.repository.jcr.SimpleJackrabbitConflictTest.testNullPointerExceptionThrown(SimpleJackrabbitConflictTest.java:96) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (JCR-1415) Clustering configuration documentation for syncDelay doesn't match
Clustering configuration documentation for syncDelay doesn't match -- Key: JCR-1415 URL: https://issues.apache.org/jira/browse/JCR-1415 Project: Jackrabbit Issue Type: Bug Components: clustering Affects Versions: 1.4 Reporter: Micah Whitacre Priority: Minor There is a bit of mismatch in the current documentation that is available on configuring a Cluster node for a repository. If you look at the DTD for repository.xml[1] it states that the syncDelay attribute of the Cluster element is in seconds. However if you read the Javadoc for the ClusterConfig[2] object it states the syncDelay is in milliseconds. I'm guessing that the value is actually in milliseconds but at the very least the two documents should be telling the same story. [1] -http://jackrabbit.apache.org/dtd/repository-1.4.dtd [2] - http://jackrabbit.apache.org/api/1.4/org/apache/jackrabbit/core/config/ClusterConfig.html -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (JCR-1318) Repository Home locked not released despite RepositoryException being thrown.
[ https://issues.apache.org/jira/browse/JCR-1318?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Micah Whitacre updated JCR-1318: Attachment: JCR_1318-patch.txt I created a patch based on the 1.3 branch of jackrabbit-core that isn't necessarily pretty but does at least make the testcase i provided repeatedly generate the same stack trace for attempts to create an instance of RepositoryImpl. This could probably be simplified a bit if the shutdown() method was a little bit more tolerant of everything not necessarily being initialized by that point. > Repository Home locked not released despite RepositoryException being thrown. > - > > Key: JCR-1318 > URL: https://issues.apache.org/jira/browse/JCR-1318 > Project: Jackrabbit > Issue Type: Bug > Components: jackrabbit-core >Affects Versions: 1.3.3 > Environment: windows vista jdk 5 >Reporter: Micah Whitacre > Attachments: JCR_1318-patch.txt, JCR_1318_tests.zip > > > When an exception is thrown when calling RepositoryImpl.create(...) a .lock > file is created in the repository home directory and not removed despite > there no longer being an active connection. If the user attempts to create > the repository again (e.g recover from the exception because the url of the > repository was temporarily unavailable) a RepositoryException is thrown again > indicating that the repository home is locked by another process because > there is a .lock file. If a Repository is not successfully created then the > repository home should not be locked. > The lock is only released when the repository is shutdown but in this case > the Repository object is never created successfully for that method to be > called. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (JCR-1318) Repository Home locked not released despite RepositoryException being thrown.
[ https://issues.apache.org/jira/browse/JCR-1318?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Micah Whitacre updated JCR-1318: Attachment: JCR_1318_tests.zip Created a testcase which will demonstrate the behavior I'm talking about. Dropping the testcase and the repository.xml in the root of a java project that is setup with jackrabbit 1.3.3 as a dependency and JUnit 4.4 is all that should be needed. As mentioned the behavior you should be seeing is that the first attempt to create a RepositoryImpl will fail because there are no suitable drivers to connect to a database whose URL is "jdbc:foo:bar". The second attempt to connect however doesn't fail for the same reason and instead fails because of the .lock file being present. > Repository Home locked not released despite RepositoryException being thrown. > - > > Key: JCR-1318 > URL: https://issues.apache.org/jira/browse/JCR-1318 > Project: Jackrabbit > Issue Type: Bug > Components: jackrabbit-core >Affects Versions: 1.3.3 > Environment: windows vista jdk 5 >Reporter: Micah Whitacre > Attachments: JCR_1318_tests.zip > > > When an exception is thrown when calling RepositoryImpl.create(...) a .lock > file is created in the repository home directory and not removed despite > there no longer being an active connection. If the user attempts to create > the repository again (e.g recover from the exception because the url of the > repository was temporarily unavailable) a RepositoryException is thrown again > indicating that the repository home is locked by another process because > there is a .lock file. If a Repository is not successfully created then the > repository home should not be locked. > The lock is only released when the repository is shutdown but in this case > the Repository object is never created successfully for that method to be > called. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (JCR-1318) Repository Home locked not released despite RepositoryException being thrown.
Repository Home locked not released despite RepositoryException being thrown. - Key: JCR-1318 URL: https://issues.apache.org/jira/browse/JCR-1318 Project: Jackrabbit Issue Type: Bug Components: jackrabbit-core Affects Versions: 1.3.3 Environment: windows vista jdk 5 Reporter: Micah Whitacre When an exception is thrown when calling RepositoryImpl.create(...) a .lock file is created in the repository home directory and not removed despite there no longer being an active connection. If the user attempts to create the repository again (e.g recover from the exception because the url of the repository was temporarily unavailable) a RepositoryException is thrown again indicating that the repository home is locked by another process because there is a .lock file. If a Repository is not successfully created then the repository home should not be locked. The lock is only released when the repository is shutdown but in this case the Repository object is never created successfully for that method to be called. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
