[jira] Commented: (JCR-134) Unreferenced VersionHistory should be deleted automatically.
[ http://issues.apache.org/jira/browse/JCR-134?page=comments#action_12457629 ] Tobias Bocanegra commented on JCR-134: -- yes, of course: empty VH, no references - remove non-empty VH, no references - keep (or at least configurable). Unreferenced VersionHistory should be deleted automatically. Key: JCR-134 URL: http://issues.apache.org/jira/browse/JCR-134 Project: Jackrabbit Issue Type: New Feature Components: versioning Reporter: Tobias Bocanegra Assigned To: Tobias Bocanegra Priority: Minor since the creation of a VersionHistory is triggered by the creation of a mix:versionable node, the removal should happen automatically, as soon as no references to that version histroy exist anymore. this is the case, when all mix:versionable nodes (in all workspaces) belonging to that VH are deleted, and all the versions in the VH are removed i.e. only the jcr:rootVersion is left. At this point, the VH should be deleted aswell. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: [jira] Commented: (JCR-134) Unreferenced VersionHistory should be deleted automatically.
Paul J DeCoursey a écrit : Cédric Damioli (JIRA) wrote: [ http://issues.apache.org/jira/browse/JCR-134?page=comments#action_12457455 ] Cédric Damioli commented on JCR-134: The VH need only to be kept when there are remaining Version attached to it. In many apps, it would be great to get rid of empty VH (ie no more Version, and no more Node referencing it). This doesn't seem right to me. Kind of defeats the purpose of Versioning if we start removing deleted items, deleted is just another state in the history that should be tracked and preserved. Deleting Versions means actually deleting these history states. Its no more than an administrative task, which in some cases may be very useful, eg. to maintain the repository as small as possible, or to keep only important versions (up to the app, of course). The point of this JCR-134 issue is only that when there is no more Version in the VH (they have all been deleted) and no more Node in any workspace referencing this VH, there should be a way to also delete the VH, which can't be useful anymore. Regards, Cédric
[jira] Updated: (JCR-97) Improve Checkstyle conformance
[ http://issues.apache.org/jira/browse/JCR-97?page=all ] Jan Kuzniak updated JCR-97: --- Attachment: jackrabbit.core.config_imports.patch Imports organized in jackrabbit.core.config package Improve Checkstyle conformance -- Key: JCR-97 URL: http://issues.apache.org/jira/browse/JCR-97 Project: Jackrabbit Issue Type: Improvement Reporter: Jukka Zitting Priority: Minor Attachments: jackrabbit.core.cluster_imports.patch, jackrabbit.core.config_imports.patch, jackrabbit.core.jndi.patch, jackrabbit.core.lock.patch, jackrabbitAPICheckstylePatch.patch, jackrabbitCoreClusterCleanup.patch, jackrabbitCoreConfigCleanup.patch, jackrabbitCoreFsDbCleanup.patch, jackrabbitCoreFsDbCleanup.patch, jackrabbitCoreUnnecessaryCodeCleanup.patch This is an ongoing meta-issue for improving the Checkstyle conformance of the Jackrabbit codebase. Checkstyle (http://checkstyle.sourceforge.net/) is an automated tool for checking conformance with coding standard and good coding style. A Checkstyle report for Jackrabbit can be generated by running maven checkstyle. Currently the Jackrabbit Checkstyle report contains thousands of trivial problems like unused imports and minor formatting issues. While it would be possible to just remove those checks from the Jackrabbit Checkstyle configuration, it would certainly be better to fix the real issues. After fixing the trivial problems, the Checkstyle reports become much more valuable tools in locating troublesome code and identifying chances for improvement. While this issue remains open, you have an open mandate to improve the standards conformance and coding style of the Jackrabbit sources. This mandate applies only to changes that fix problems reported by Checkstyle while making no changes to the external interface or behaviour of the changed code. The commit messages of such Checkstyle improvements should be labeled with the Jira key of this issue (JCR-97) to mark the changes as style-only. This way other committers will have easier time reviewing your changes for bugs or other unexpected side-effects. If you are not a Jackrabbit committer, but want to help improve the Checkstyle conformance, you can make your changes using sources from anonymous subversion and send your changes as an attachment to this issue. Please see the Javadoc improvement issue JCR-73 for details. PS. Blind conformance to style guides is seldom beneficial. Please remember that the goal of this issue is to improve Jackrabbit code, not just the Checkstyle output! -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (JCR-97) Improve Checkstyle conformance
[ http://issues.apache.org/jira/browse/JCR-97?page=all ] Jan Kuzniak updated JCR-97: --- Attachment: jackrabbit.core.fs_imports.patch Imports organized in jackrabbit.core.fs package Improve Checkstyle conformance -- Key: JCR-97 URL: http://issues.apache.org/jira/browse/JCR-97 Project: Jackrabbit Issue Type: Improvement Reporter: Jukka Zitting Priority: Minor Attachments: jackrabbit.core.cluster_imports.patch, jackrabbit.core.config_imports.patch, jackrabbit.core.fs_imports.patch, jackrabbit.core.jndi.patch, jackrabbit.core.lock.patch, jackrabbitAPICheckstylePatch.patch, jackrabbitCoreClusterCleanup.patch, jackrabbitCoreConfigCleanup.patch, jackrabbitCoreFsDbCleanup.patch, jackrabbitCoreFsDbCleanup.patch, jackrabbitCoreUnnecessaryCodeCleanup.patch This is an ongoing meta-issue for improving the Checkstyle conformance of the Jackrabbit codebase. Checkstyle (http://checkstyle.sourceforge.net/) is an automated tool for checking conformance with coding standard and good coding style. A Checkstyle report for Jackrabbit can be generated by running maven checkstyle. Currently the Jackrabbit Checkstyle report contains thousands of trivial problems like unused imports and minor formatting issues. While it would be possible to just remove those checks from the Jackrabbit Checkstyle configuration, it would certainly be better to fix the real issues. After fixing the trivial problems, the Checkstyle reports become much more valuable tools in locating troublesome code and identifying chances for improvement. While this issue remains open, you have an open mandate to improve the standards conformance and coding style of the Jackrabbit sources. This mandate applies only to changes that fix problems reported by Checkstyle while making no changes to the external interface or behaviour of the changed code. The commit messages of such Checkstyle improvements should be labeled with the Jira key of this issue (JCR-97) to mark the changes as style-only. This way other committers will have easier time reviewing your changes for bugs or other unexpected side-effects. If you are not a Jackrabbit committer, but want to help improve the Checkstyle conformance, you can make your changes using sources from anonymous subversion and send your changes as an attachment to this issue. Please see the Javadoc improvement issue JCR-73 for details. PS. Blind conformance to style guides is seldom beneficial. Please remember that the goal of this issue is to improve Jackrabbit code, not just the Checkstyle output! -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (JCR-670) LocalNamespaceMappings does not make use of NameCache in NamespaceRegistryImpl
LocalNamespaceMappings does not make use of NameCache in NamespaceRegistryImpl -- Key: JCR-670 URL: http://issues.apache.org/jira/browse/JCR-670 Project: Jackrabbit Issue Type: Improvement Components: core Affects Versions: 1.1, 1.1.1 Reporter: Marcel Reutegger Priority: Minor Fix For: 1.2 This basically means that the NameCache in NamespaceRegistryImpl is never used. The LocalNamespaceMappings should also implement NameCache and forward calls to the NamespaceRegistryImpl for names with namespace URIs that are not locally remapped. See proposed patch. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (JCR-670) LocalNamespaceMappings does not make use of NameCache in NamespaceRegistryImpl
[ http://issues.apache.org/jira/browse/JCR-670?page=all ] Marcel Reutegger updated JCR-670: - Attachment: LocalNamespaceMappings-485608.patch LocalNamespaceMappings does not make use of NameCache in NamespaceRegistryImpl -- Key: JCR-670 URL: http://issues.apache.org/jira/browse/JCR-670 Project: Jackrabbit Issue Type: Improvement Components: core Affects Versions: 1.1, 1.1.1 Reporter: Marcel Reutegger Priority: Minor Fix For: 1.2 Attachments: LocalNamespaceMappings-485608.patch This basically means that the NameCache in NamespaceRegistryImpl is never used. The LocalNamespaceMappings should also implement NameCache and forward calls to the NamespaceRegistryImpl for names with namespace URIs that are not locally remapped. See proposed patch. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Resolved: (JCR-669) Move NamespaceMappings/Index from lucene to namespace registry.
[ http://issues.apache.org/jira/browse/JCR-669?page=all ] Tobias Bocanegra resolved JCR-669. -- Resolution: Fixed fixed. Committed revision 486082. Move NamespaceMappings/Index from lucene to namespace registry. --- Key: JCR-669 URL: http://issues.apache.org/jira/browse/JCR-669 Project: Jackrabbit Issue Type: Improvement Components: indexing Reporter: Tobias Bocanegra Assigned To: Tobias Bocanegra The NamespaceMappings class in the indexer is used for generating small prefixes for namespace uris that are stored in the index. This mechanism of stable prefixes could be used in other places as well, for example in the persistence managers. Suggest to introduce general methods in the namespace registry: int getURIIndex(String uri) String getURI(int index) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (JCR-672) Deadlock on concurrent save/checkin operations possible
[ http://issues.apache.org/jira/browse/JCR-672?page=comments#action_12457666 ] Tobias Bocanegra commented on JCR-672: -- could have been introduced by JCR-546. Deadlock on concurrent save/checkin operations possible --- Key: JCR-672 URL: http://issues.apache.org/jira/browse/JCR-672 Project: Jackrabbit Issue Type: Bug Components: versioning Affects Versions: 1.1 Reporter: Przemo Pakulski Save and checkin operations are trying to acquire 2 locks in different order, what leads to deadlock. -save 1.SharedItemStateManager.acquireWriteLock 2.AbstractVersionManager.acquireWriteLock - locked -checkin 1.AbstractVersionManager.acquireWriteLock 2.SharedItemStateManager.acquireReadLock - locked Thread-4 prio=6 tid=0x0312d840 nid=0x824 in Object.wait() [0x03cef000..0x03cefa68] at java.lang.Object.wait(Native Method) - waiting on 0x23210968 (a EDU.oswego.cs.dl.util.concurrent.WriterPreferenceReadWriteLock$WriterLock) at java.lang.Object.wait(Unknown Source) at EDU.oswego.cs.dl.util.concurrent.WriterPreferenceReadWriteLock$WriterLock.acquire(Unknown Source) - locked 0x23210968 (a EDU.oswego.cs.dl.util.concurrent.WriterPreferenceReadWriteLock$WriterLock) at org.apache.jackrabbit.core.version.AbstractVersionManager.acquireWriteLock(AbstractVersionManager.java:124) at org.apache.jackrabbit.core.version.VersionManagerImpl.setNodeReferences(VersionManagerImpl.java:413) at org.apache.jackrabbit.core.version.VersionItemStateProvider.setNodeReferences(VersionItemStateProvider.java:125) at org.apache.jackrabbit.core.state.SharedItemStateManager$Update.end(SharedItemStateManager.java:699) at org.apache.jackrabbit.core.state.SharedItemStateManager.update(SharedItemStateManager.java:810) at org.apache.jackrabbit.core.state.LocalItemStateManager.update(LocalItemStateManager.java:326) at org.apache.jackrabbit.core.state.XAItemStateManager.update(XAItemStateManager.java:313) at org.apache.jackrabbit.core.state.LocalItemStateManager.update(LocalItemStateManager.java:302) at org.apache.jackrabbit.core.state.SessionItemStateManager.update(SessionItemStateManager.java:295) at org.apache.jackrabbit.core.ItemImpl.save(ItemImpl.java:1204) - locked 0x2332eaa0 (a org.apache.jackrabbit.core.XASessionImpl) at JrTestDeadlock.run(JrTestDeadlock.java:87) Thread-3 prio=6 tid=0x0312db18 nid=0xa04 in Object.wait() [0x03caf000..0x03cafae8] at java.lang.Object.wait(Native Method) - waiting on 0x232d1360 (a EDU.oswego.cs.dl.util.concurrent.WriterPreferenceReadWriteLock$ReaderLock) at java.lang.Object.wait(Unknown Source) at EDU.oswego.cs.dl.util.concurrent.WriterPreferenceReadWriteLock$ReaderLock.acquire(Unknown Source) - locked 0x232d1360 (a EDU.oswego.cs.dl.util.concurrent.WriterPreferenceReadWriteLock$ReaderLock) at org.apache.jackrabbit.core.state.SharedItemStateManager.acquireReadLock(SharedItemStateManager.java:1361) at org.apache.jackrabbit.core.state.SharedItemStateManager.hasItemState(SharedItemStateManager.java:270) at org.apache.jackrabbit.core.state.LocalItemStateManager.hasItemState(LocalItemStateManager.java:180) at org.apache.jackrabbit.core.state.XAItemStateManager.hasItemState(XAItemStateManager.java:252) at org.apache.jackrabbit.core.state.SessionItemStateManager.hasItemState(SessionItemStateManager.java:188) at org.apache.jackrabbit.core.ItemManager.itemExists(ItemManager.java:256) at org.apache.jackrabbit.core.NodeImpl.hasProperty(NodeImpl.java:1509) at org.apache.jackrabbit.core.version.InternalFrozenNodeImpl.checkin(InternalFrozenNodeImpl.java:276) at org.apache.jackrabbit.core.version.InternalFrozenNodeImpl.checkin(InternalFrozenNodeImpl.java:248) at org.apache.jackrabbit.core.version.InternalVersionHistoryImpl.checkin(InternalVersionHistoryImpl.java:440) at org.apache.jackrabbit.core.version.AbstractVersionManager.checkin(AbstractVersionManager.java:397) at org.apache.jackrabbit.core.version.VersionManagerImpl$2.run(VersionManagerImpl.java:289) at org.apache.jackrabbit.core.version.VersionManagerImpl$DynamicESCFactory.doSourced(VersionManagerImpl.java:611) - locked 0x2320c5d8 (a org.apache.jackrabbit.core.version.VersionManagerImpl$DynamicESCFactory) at org.apache.jackrabbit.core.version.VersionManagerImpl.checkin(VersionManagerImpl.java:285) at org.apache.jackrabbit.core.version.XAVersionManager.checkin(XAVersionManager.java:161) at org.apache.jackrabbit.core.NodeImpl.checkin(NodeImpl.java:2944) at JrTestDeadlock.run(JrTestDeadlock.java:103) -- This message is
[jira] Resolved: (JCR-669) Move NamespaceMappings/Index from lucene to namespace registry.
[ http://issues.apache.org/jira/browse/JCR-669?page=all ] Marcel Reutegger resolved JCR-669. -- Fix Version/s: 1.2 Resolution: Fixed The query handler now uses the stable index prefix from the namespace registry. This change is backward compatible in a sense that the lucene query handler will still use the old mechanism if it discovers an existing ns_mappings.properties file in the index directory. A new jackrabbit installation will therefore use the new mechanism while an upgraded jackrabbit installation will still use the old mechanism. If you want to use the stable index prefixes from the namespace registry in an existing jackrabbit installation you need to re-index the repository (stop jackrabbit, delete the index directories and start jackrabbit again). Fixed in revision: 486099 Move NamespaceMappings/Index from lucene to namespace registry. --- Key: JCR-669 URL: http://issues.apache.org/jira/browse/JCR-669 Project: Jackrabbit Issue Type: Improvement Components: indexing Reporter: Tobias Bocanegra Assigned To: Marcel Reutegger Fix For: 1.2 The NamespaceMappings class in the indexer is used for generating small prefixes for namespace uris that are stored in the index. This mechanism of stable prefixes could be used in other places as well, for example in the persistence managers. Suggest to introduce general methods in the namespace registry: int getURIIndex(String uri) String getURI(int index) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
what wrong when I compile the jackrabbit-core
I just update the source code to newest version ,when I run mvn install .there are some error in the test . --- T E S T S --- Running org.apache.jackrabbit.init.ExportDocViewTestData Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 7.109 sec FA ILURE! Running org.apache.jackrabbit.init.PropertyTestData Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 0.063 sec FA ILURE! Running org.apache.jackrabbit.init.NodeTestData Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 0.046 sec FA ILURE! Running org.apache.jackrabbit.init.QueryTestData Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 0.047 sec FA ILURE! Results : Tests run: 4, Failures: 0, Errors: 4, Skipped: 0 [INFO] [ERROR] BUILD FAILURE [INFO] [INFO] There are test failures. [INFO] [INFO] Trace org.apache.maven.BuildFailureException: There are test failures. at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals (Defa ultLifecycleExecutor.java:555) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLi fecycle(DefaultLifecycleExecutor.java:475) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal (Defau ltLifecycleExecutor.java:454) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHan dleFailures(DefaultLifecycleExecutor.java:306) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegmen ts(DefaultLifecycleExecutor.java:273) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute (DefaultLi fecycleExecutor.java:140) at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:322) at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:115) at org.apache.maven.cli.MavenCli.main(MavenCli.java:256) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke (NativeMethodAccessorImpl. java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke (DelegatingMethodAcces sorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java :315) at org.codehaus.classworlds.Launcher.launch(Launcher.java:255) at org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java :430) at org.codehaus.classworlds.Launcher.main(Launcher.java:375) Caused by: org.apache.maven.plugin.MojoFailureException: There are test failures . at org.apache.maven.plugin.surefire.SurefirePlugin.execute (SurefirePlugi n.java:403) at org.apache.maven.plugin.DefaultPluginManager.executeMojo (DefaultPlugi nManager.java:412) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals (Defa ultLifecycleExecutor.java:534) ... 16 more [INFO] [INFO] Total time: 19 seconds [INFO] Finished at: Tue Dec 12 20:00:38 CST 2006 [INFO] Final Memory: 7M/21M [INFO]
Re: what wrong when I compile the jackrabbit-core
Hi, On 12/12/06, wendy Lee [EMAIL PROTECTED] wrote: I just update the source code to newest version ,when I run mvn install .there are some error in the test . Looks like a local issue. Check the test reports in target/surefire-reports/ or run mvn clean install to start over. One issue I've seen every now and then is that if I cancel (Ctrl-C) mvn while it's running the unit tests, the test process remains in the background and the .lock file in the test repository stays active. Thus all subsequent test runs will fail until the background process is either killed or ends normally. BR, Jukka Zitting
[jira] Commented: (JCR-672) Deadlock on concurrent save/checkin operations possible
[ http://issues.apache.org/jira/browse/JCR-672?page=comments#action_12457695 ] Jukka Zitting commented on JCR-672: --- The proper solution to this issue would probably be to acquire the SharedItemStateManager read lock for the entire checkin operation. Deadlock on concurrent save/checkin operations possible --- Key: JCR-672 URL: http://issues.apache.org/jira/browse/JCR-672 Project: Jackrabbit Issue Type: Bug Components: versioning Affects Versions: 1.1 Reporter: Przemo Pakulski Save and checkin operations are trying to acquire 2 locks in different order, what leads to deadlock. -save 1.SharedItemStateManager.acquireWriteLock 2.AbstractVersionManager.acquireWriteLock - locked -checkin 1.AbstractVersionManager.acquireWriteLock 2.SharedItemStateManager.acquireReadLock - locked Thread-4 prio=6 tid=0x0312d840 nid=0x824 in Object.wait() [0x03cef000..0x03cefa68] at java.lang.Object.wait(Native Method) - waiting on 0x23210968 (a EDU.oswego.cs.dl.util.concurrent.WriterPreferenceReadWriteLock$WriterLock) at java.lang.Object.wait(Unknown Source) at EDU.oswego.cs.dl.util.concurrent.WriterPreferenceReadWriteLock$WriterLock.acquire(Unknown Source) - locked 0x23210968 (a EDU.oswego.cs.dl.util.concurrent.WriterPreferenceReadWriteLock$WriterLock) at org.apache.jackrabbit.core.version.AbstractVersionManager.acquireWriteLock(AbstractVersionManager.java:124) at org.apache.jackrabbit.core.version.VersionManagerImpl.setNodeReferences(VersionManagerImpl.java:413) at org.apache.jackrabbit.core.version.VersionItemStateProvider.setNodeReferences(VersionItemStateProvider.java:125) at org.apache.jackrabbit.core.state.SharedItemStateManager$Update.end(SharedItemStateManager.java:699) at org.apache.jackrabbit.core.state.SharedItemStateManager.update(SharedItemStateManager.java:810) at org.apache.jackrabbit.core.state.LocalItemStateManager.update(LocalItemStateManager.java:326) at org.apache.jackrabbit.core.state.XAItemStateManager.update(XAItemStateManager.java:313) at org.apache.jackrabbit.core.state.LocalItemStateManager.update(LocalItemStateManager.java:302) at org.apache.jackrabbit.core.state.SessionItemStateManager.update(SessionItemStateManager.java:295) at org.apache.jackrabbit.core.ItemImpl.save(ItemImpl.java:1204) - locked 0x2332eaa0 (a org.apache.jackrabbit.core.XASessionImpl) at JrTestDeadlock.run(JrTestDeadlock.java:87) Thread-3 prio=6 tid=0x0312db18 nid=0xa04 in Object.wait() [0x03caf000..0x03cafae8] at java.lang.Object.wait(Native Method) - waiting on 0x232d1360 (a EDU.oswego.cs.dl.util.concurrent.WriterPreferenceReadWriteLock$ReaderLock) at java.lang.Object.wait(Unknown Source) at EDU.oswego.cs.dl.util.concurrent.WriterPreferenceReadWriteLock$ReaderLock.acquire(Unknown Source) - locked 0x232d1360 (a EDU.oswego.cs.dl.util.concurrent.WriterPreferenceReadWriteLock$ReaderLock) at org.apache.jackrabbit.core.state.SharedItemStateManager.acquireReadLock(SharedItemStateManager.java:1361) at org.apache.jackrabbit.core.state.SharedItemStateManager.hasItemState(SharedItemStateManager.java:270) at org.apache.jackrabbit.core.state.LocalItemStateManager.hasItemState(LocalItemStateManager.java:180) at org.apache.jackrabbit.core.state.XAItemStateManager.hasItemState(XAItemStateManager.java:252) at org.apache.jackrabbit.core.state.SessionItemStateManager.hasItemState(SessionItemStateManager.java:188) at org.apache.jackrabbit.core.ItemManager.itemExists(ItemManager.java:256) at org.apache.jackrabbit.core.NodeImpl.hasProperty(NodeImpl.java:1509) at org.apache.jackrabbit.core.version.InternalFrozenNodeImpl.checkin(InternalFrozenNodeImpl.java:276) at org.apache.jackrabbit.core.version.InternalFrozenNodeImpl.checkin(InternalFrozenNodeImpl.java:248) at org.apache.jackrabbit.core.version.InternalVersionHistoryImpl.checkin(InternalVersionHistoryImpl.java:440) at org.apache.jackrabbit.core.version.AbstractVersionManager.checkin(AbstractVersionManager.java:397) at org.apache.jackrabbit.core.version.VersionManagerImpl$2.run(VersionManagerImpl.java:289) at org.apache.jackrabbit.core.version.VersionManagerImpl$DynamicESCFactory.doSourced(VersionManagerImpl.java:611) - locked 0x2320c5d8 (a org.apache.jackrabbit.core.version.VersionManagerImpl$DynamicESCFactory) at org.apache.jackrabbit.core.version.VersionManagerImpl.checkin(VersionManagerImpl.java:285) at org.apache.jackrabbit.core.version.XAVersionManager.checkin(XAVersionManager.java:161) at
[jira] Updated: (JCR-656) JCR-Server: Allow header misses colong (RootCollection, WorkspaceResourceImpl)
[ http://issues.apache.org/jira/browse/JCR-656?page=all ] Jukka Zitting updated JCR-656: -- Component/s: webdav Fix Version/s: 1.2 Affects Version/s: 1.1.1 1.1 1.0.1 1.0 0.9 JCR-Server: Allow header misses colong (RootCollection, WorkspaceResourceImpl) -- Key: JCR-656 URL: http://issues.apache.org/jira/browse/JCR-656 Project: Jackrabbit Issue Type: Bug Components: webdav Affects Versions: 1.0, 1.0.1, 1.1, 0.9, 1.1.1 Reporter: angela Assigned To: angela Priority: Minor Fix For: 1.2 List of supported dav methods misses some colons. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (JCR-658) CanAddChildNodeCallWithNodeTypeTest.testDefinedAndLegalType() may fail if protected child node definition is picked
[ http://issues.apache.org/jira/browse/JCR-658?page=all ] Jukka Zitting closed JCR-658. - CanAddChildNodeCallWithNodeTypeTest.testDefinedAndLegalType() may fail if protected child node definition is picked --- Key: JCR-658 URL: http://issues.apache.org/jira/browse/JCR-658 Project: Jackrabbit Issue Type: Bug Components: JCR TCK Affects Versions: 1.0 Reporter: Marcel Reutegger Assigned To: Marcel Reutegger Priority: Minor If the utility NodeTypeUtil.locateChildNodeDef() picks a protected child node definition the test case will fail because it is not allowed add a protected child node. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (JCR-655) PropertyReadMethodsTest should also work on NAME property
[ http://issues.apache.org/jira/browse/JCR-655?page=all ] Jukka Zitting closed JCR-655. - PropertyReadMethodsTest should also work on NAME property - Key: JCR-655 URL: http://issues.apache.org/jira/browse/JCR-655 Project: Jackrabbit Issue Type: Bug Components: JCR TCK Affects Versions: 1.0 Reporter: Marcel Reutegger Assigned To: Marcel Reutegger Priority: Minor Some test cases in PropertyReadMethodsTest require a String property even though a NAME property like jcr:primaryType would be sufficient. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (JCR-672) Deadlock on concurrent save/checkin operations possible
[ http://issues.apache.org/jira/browse/JCR-672?page=comments#action_12457693 ] Jukka Zitting commented on JCR-672: --- You marked this as occurring in 1.1? If correct, then it shouldn't be caused by JCR-546, since it's not included in either 1.1 or 1.1.1. Deadlock on concurrent save/checkin operations possible --- Key: JCR-672 URL: http://issues.apache.org/jira/browse/JCR-672 Project: Jackrabbit Issue Type: Bug Components: versioning Affects Versions: 1.1 Reporter: Przemo Pakulski Save and checkin operations are trying to acquire 2 locks in different order, what leads to deadlock. -save 1.SharedItemStateManager.acquireWriteLock 2.AbstractVersionManager.acquireWriteLock - locked -checkin 1.AbstractVersionManager.acquireWriteLock 2.SharedItemStateManager.acquireReadLock - locked Thread-4 prio=6 tid=0x0312d840 nid=0x824 in Object.wait() [0x03cef000..0x03cefa68] at java.lang.Object.wait(Native Method) - waiting on 0x23210968 (a EDU.oswego.cs.dl.util.concurrent.WriterPreferenceReadWriteLock$WriterLock) at java.lang.Object.wait(Unknown Source) at EDU.oswego.cs.dl.util.concurrent.WriterPreferenceReadWriteLock$WriterLock.acquire(Unknown Source) - locked 0x23210968 (a EDU.oswego.cs.dl.util.concurrent.WriterPreferenceReadWriteLock$WriterLock) at org.apache.jackrabbit.core.version.AbstractVersionManager.acquireWriteLock(AbstractVersionManager.java:124) at org.apache.jackrabbit.core.version.VersionManagerImpl.setNodeReferences(VersionManagerImpl.java:413) at org.apache.jackrabbit.core.version.VersionItemStateProvider.setNodeReferences(VersionItemStateProvider.java:125) at org.apache.jackrabbit.core.state.SharedItemStateManager$Update.end(SharedItemStateManager.java:699) at org.apache.jackrabbit.core.state.SharedItemStateManager.update(SharedItemStateManager.java:810) at org.apache.jackrabbit.core.state.LocalItemStateManager.update(LocalItemStateManager.java:326) at org.apache.jackrabbit.core.state.XAItemStateManager.update(XAItemStateManager.java:313) at org.apache.jackrabbit.core.state.LocalItemStateManager.update(LocalItemStateManager.java:302) at org.apache.jackrabbit.core.state.SessionItemStateManager.update(SessionItemStateManager.java:295) at org.apache.jackrabbit.core.ItemImpl.save(ItemImpl.java:1204) - locked 0x2332eaa0 (a org.apache.jackrabbit.core.XASessionImpl) at JrTestDeadlock.run(JrTestDeadlock.java:87) Thread-3 prio=6 tid=0x0312db18 nid=0xa04 in Object.wait() [0x03caf000..0x03cafae8] at java.lang.Object.wait(Native Method) - waiting on 0x232d1360 (a EDU.oswego.cs.dl.util.concurrent.WriterPreferenceReadWriteLock$ReaderLock) at java.lang.Object.wait(Unknown Source) at EDU.oswego.cs.dl.util.concurrent.WriterPreferenceReadWriteLock$ReaderLock.acquire(Unknown Source) - locked 0x232d1360 (a EDU.oswego.cs.dl.util.concurrent.WriterPreferenceReadWriteLock$ReaderLock) at org.apache.jackrabbit.core.state.SharedItemStateManager.acquireReadLock(SharedItemStateManager.java:1361) at org.apache.jackrabbit.core.state.SharedItemStateManager.hasItemState(SharedItemStateManager.java:270) at org.apache.jackrabbit.core.state.LocalItemStateManager.hasItemState(LocalItemStateManager.java:180) at org.apache.jackrabbit.core.state.XAItemStateManager.hasItemState(XAItemStateManager.java:252) at org.apache.jackrabbit.core.state.SessionItemStateManager.hasItemState(SessionItemStateManager.java:188) at org.apache.jackrabbit.core.ItemManager.itemExists(ItemManager.java:256) at org.apache.jackrabbit.core.NodeImpl.hasProperty(NodeImpl.java:1509) at org.apache.jackrabbit.core.version.InternalFrozenNodeImpl.checkin(InternalFrozenNodeImpl.java:276) at org.apache.jackrabbit.core.version.InternalFrozenNodeImpl.checkin(InternalFrozenNodeImpl.java:248) at org.apache.jackrabbit.core.version.InternalVersionHistoryImpl.checkin(InternalVersionHistoryImpl.java:440) at org.apache.jackrabbit.core.version.AbstractVersionManager.checkin(AbstractVersionManager.java:397) at org.apache.jackrabbit.core.version.VersionManagerImpl$2.run(VersionManagerImpl.java:289) at org.apache.jackrabbit.core.version.VersionManagerImpl$DynamicESCFactory.doSourced(VersionManagerImpl.java:611) - locked 0x2320c5d8 (a org.apache.jackrabbit.core.version.VersionManagerImpl$DynamicESCFactory) at org.apache.jackrabbit.core.version.VersionManagerImpl.checkin(VersionManagerImpl.java:285) at org.apache.jackrabbit.core.version.XAVersionManager.checkin(XAVersionManager.java:161) at
[jira] Closed: (JCR-654) Some implementations require a save() after a mixin has been assigned
[ http://issues.apache.org/jira/browse/JCR-654?page=all ] Jukka Zitting closed JCR-654. - Some implementations require a save() after a mixin has been assigned - Key: JCR-654 URL: http://issues.apache.org/jira/browse/JCR-654 Project: Jackrabbit Issue Type: Bug Components: JCR TCK Affects Versions: 1.0 Reporter: Marcel Reutegger Assigned To: Marcel Reutegger Priority: Minor Some test cases do not call save() after a mixin has been added. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (JCR-652) NodeCanAddMixinTest.testCheckedIn() has wrong option check
[ http://issues.apache.org/jira/browse/JCR-652?page=all ] Jukka Zitting closed JCR-652. - NodeCanAddMixinTest.testCheckedIn() has wrong option check -- Key: JCR-652 URL: http://issues.apache.org/jira/browse/JCR-652 Project: Jackrabbit Issue Type: Bug Components: JCR TCK Affects Versions: 1.0 Reporter: Marcel Reutegger Assigned To: Marcel Reutegger NodeCanAddMixinTest.testCheckedIn() checks for locking option instead of versioning option. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (JCR-621) create jcr-browser contrib project
[ http://issues.apache.org/jira/browse/JCR-621?page=all ] Jukka Zitting closed JCR-621. - create jcr-browser contrib project -- Key: JCR-621 URL: http://issues.apache.org/jira/browse/JCR-621 Project: Jackrabbit Issue Type: New Feature Reporter: Edgar Poce Priority: Minor If noone oposes I'll start a contrib project called jcr-browser. A live demo of the initial code is available at http://edgarpoce.dyndns.org:8080/jcr-browser/ -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (JCR-673) Add seperate configuration for blobstore
Add seperate configuration for blobstore Key: JCR-673 URL: http://issues.apache.org/jira/browse/JCR-673 Project: Jackrabbit Issue Type: New Feature Affects Versions: 1.1.1, 1.1, 1.0.1, 1.0, 0.9 Reporter: Tobias Bocanegra currently the blobstore of a persistence manager cannot be configured individually. its is implied in the configuration of the persistence manager (e.g. useExternalBlobs param). suggest to introduce new BlobStore/ configuration as nested element of the PersistenceManager configuration. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (JCR-672) Deadlock on concurrent save/checkin operations possible
[ http://issues.apache.org/jira/browse/JCR-672?page=comments#action_12457707 ] Przemo Pakulski commented on JCR-672: - It is occuring in trunk. I have checked 1.1 by accident then I couldn't change this ... Deadlock on concurrent save/checkin operations possible --- Key: JCR-672 URL: http://issues.apache.org/jira/browse/JCR-672 Project: Jackrabbit Issue Type: Bug Components: versioning Affects Versions: 1.1 Reporter: Przemo Pakulski Save and checkin operations are trying to acquire 2 locks in different order, what leads to deadlock. -save 1.SharedItemStateManager.acquireWriteLock 2.AbstractVersionManager.acquireWriteLock - locked -checkin 1.AbstractVersionManager.acquireWriteLock 2.SharedItemStateManager.acquireReadLock - locked Thread-4 prio=6 tid=0x0312d840 nid=0x824 in Object.wait() [0x03cef000..0x03cefa68] at java.lang.Object.wait(Native Method) - waiting on 0x23210968 (a EDU.oswego.cs.dl.util.concurrent.WriterPreferenceReadWriteLock$WriterLock) at java.lang.Object.wait(Unknown Source) at EDU.oswego.cs.dl.util.concurrent.WriterPreferenceReadWriteLock$WriterLock.acquire(Unknown Source) - locked 0x23210968 (a EDU.oswego.cs.dl.util.concurrent.WriterPreferenceReadWriteLock$WriterLock) at org.apache.jackrabbit.core.version.AbstractVersionManager.acquireWriteLock(AbstractVersionManager.java:124) at org.apache.jackrabbit.core.version.VersionManagerImpl.setNodeReferences(VersionManagerImpl.java:413) at org.apache.jackrabbit.core.version.VersionItemStateProvider.setNodeReferences(VersionItemStateProvider.java:125) at org.apache.jackrabbit.core.state.SharedItemStateManager$Update.end(SharedItemStateManager.java:699) at org.apache.jackrabbit.core.state.SharedItemStateManager.update(SharedItemStateManager.java:810) at org.apache.jackrabbit.core.state.LocalItemStateManager.update(LocalItemStateManager.java:326) at org.apache.jackrabbit.core.state.XAItemStateManager.update(XAItemStateManager.java:313) at org.apache.jackrabbit.core.state.LocalItemStateManager.update(LocalItemStateManager.java:302) at org.apache.jackrabbit.core.state.SessionItemStateManager.update(SessionItemStateManager.java:295) at org.apache.jackrabbit.core.ItemImpl.save(ItemImpl.java:1204) - locked 0x2332eaa0 (a org.apache.jackrabbit.core.XASessionImpl) at JrTestDeadlock.run(JrTestDeadlock.java:87) Thread-3 prio=6 tid=0x0312db18 nid=0xa04 in Object.wait() [0x03caf000..0x03cafae8] at java.lang.Object.wait(Native Method) - waiting on 0x232d1360 (a EDU.oswego.cs.dl.util.concurrent.WriterPreferenceReadWriteLock$ReaderLock) at java.lang.Object.wait(Unknown Source) at EDU.oswego.cs.dl.util.concurrent.WriterPreferenceReadWriteLock$ReaderLock.acquire(Unknown Source) - locked 0x232d1360 (a EDU.oswego.cs.dl.util.concurrent.WriterPreferenceReadWriteLock$ReaderLock) at org.apache.jackrabbit.core.state.SharedItemStateManager.acquireReadLock(SharedItemStateManager.java:1361) at org.apache.jackrabbit.core.state.SharedItemStateManager.hasItemState(SharedItemStateManager.java:270) at org.apache.jackrabbit.core.state.LocalItemStateManager.hasItemState(LocalItemStateManager.java:180) at org.apache.jackrabbit.core.state.XAItemStateManager.hasItemState(XAItemStateManager.java:252) at org.apache.jackrabbit.core.state.SessionItemStateManager.hasItemState(SessionItemStateManager.java:188) at org.apache.jackrabbit.core.ItemManager.itemExists(ItemManager.java:256) at org.apache.jackrabbit.core.NodeImpl.hasProperty(NodeImpl.java:1509) at org.apache.jackrabbit.core.version.InternalFrozenNodeImpl.checkin(InternalFrozenNodeImpl.java:276) at org.apache.jackrabbit.core.version.InternalFrozenNodeImpl.checkin(InternalFrozenNodeImpl.java:248) at org.apache.jackrabbit.core.version.InternalVersionHistoryImpl.checkin(InternalVersionHistoryImpl.java:440) at org.apache.jackrabbit.core.version.AbstractVersionManager.checkin(AbstractVersionManager.java:397) at org.apache.jackrabbit.core.version.VersionManagerImpl$2.run(VersionManagerImpl.java:289) at org.apache.jackrabbit.core.version.VersionManagerImpl$DynamicESCFactory.doSourced(VersionManagerImpl.java:611) - locked 0x2320c5d8 (a org.apache.jackrabbit.core.version.VersionManagerImpl$DynamicESCFactory) at org.apache.jackrabbit.core.version.VersionManagerImpl.checkin(VersionManagerImpl.java:285) at org.apache.jackrabbit.core.version.XAVersionManager.checkin(XAVersionManager.java:161) at org.apache.jackrabbit.core.NodeImpl.checkin(NodeImpl.java:2944) at
[jira] Commented: (JCR-134) Unreferenced VersionHistory should be deleted automatically.
[ http://issues.apache.org/jira/browse/JCR-134?page=comments#action_12457736 ] Cédric Damioli commented on JCR-134: Concerning the eventual ref count kept on VHs, is it allowed to store it in the repository, as a new property of the VH ? If yes there would be a compatibility problem whith existing repositories. Otherwise, how would you see the storage of this ref count ? Unreferenced VersionHistory should be deleted automatically. Key: JCR-134 URL: http://issues.apache.org/jira/browse/JCR-134 Project: Jackrabbit Issue Type: New Feature Components: versioning Reporter: Tobias Bocanegra Assigned To: Tobias Bocanegra Priority: Minor since the creation of a VersionHistory is triggered by the creation of a mix:versionable node, the removal should happen automatically, as soon as no references to that version histroy exist anymore. this is the case, when all mix:versionable nodes (in all workspaces) belonging to that VH are deleted, and all the versions in the VH are removed i.e. only the jcr:rootVersion is left. At this point, the VH should be deleted aswell. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (JCR-352) Upgrade to Lucene 2.0
[ http://issues.apache.org/jira/browse/JCR-352?page=all ] Przemo Pakulski updated JCR-352: Attachment: updated-lucene2.patch Attached updated lucene2 patch. Patch had to be updated because of recent changes in indexing. Patch contains also fix for issues raised by Topi and Marcel . Since maven2 is used as build system it could be applied I think. Upgrade to Lucene 2.0 - Key: JCR-352 URL: http://issues.apache.org/jira/browse/JCR-352 Project: Jackrabbit Issue Type: Improvement Components: indexing Affects Versions: 1.0, 0.9, 1.0.1 Environment: All Reporter: Michael Young Assigned To: Jukka Zitting Priority: Minor Fix For: 1.2 Attachments: lucene2-pom.xml.patch, lucene2-project.xml.patch, lucene2.patch, updated-lucene2.patch We would like to upgrade to Lucene 1.9.1. There are jar conflicts when integrating with other projects such as Liferay Portal -- which uses v 1.9.1. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Problems with XPath querying of Multivalue properties
Hi, I am trying to perform the following query: /jcr:root/some/path/(@lastName, @articles) On the 1.1.1 RMI jackrabbit service running on rmi:localhost:1099/jackrabbit.repository The problem I am getting is that the 'articles' property is multi-valued and when I call the RowIterator method getValues(articles); on the returned rows it always fails with a NullPointerException. However if I obtain the node via the 'jcr:path' value returned and then call node.getProperty(articles).getValues(); This returns the correct values. Is there an issue with querying properties with multiple values in the XPath query engine? I know that predicating properties with multivalues works as I am also doing the following: /jcr:root/some/path/[EMAIL PROTECTED] 'aabb-aabbdd-a2203a'] which returns all the nodes which have the uuid as one of their articles. Thanks for any help. Shane Preater.
[jira] Resolved: (JCR-352) Upgrade to Lucene 2.0
[ http://issues.apache.org/jira/browse/JCR-352?page=all ] Jukka Zitting resolved JCR-352. --- Resolution: Fixed Committed the latest patch in revision 486281. Like with the Derby upgrade (JCR-610), Lucene 2.0 is backwards compatible with indexes created with version 1.4.x. Thus there should be no need for manual upgrade procedures. Thanks Przemo and everyone else who participated in this! Upgrade to Lucene 2.0 - Key: JCR-352 URL: http://issues.apache.org/jira/browse/JCR-352 Project: Jackrabbit Issue Type: Improvement Components: indexing Affects Versions: 1.0, 0.9, 1.0.1 Environment: All Reporter: Michael Young Assigned To: Jukka Zitting Priority: Minor Fix For: 1.2 Attachments: lucene2-pom.xml.patch, lucene2-project.xml.patch, lucene2.patch, updated-lucene2.patch We would like to upgrade to Lucene 1.9.1. There are jar conflicts when integrating with other projects such as Liferay Portal -- which uses v 1.9.1. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (JCR-626) Move document type definition out of repository.xml
[ http://issues.apache.org/jira/browse/JCR-626?page=comments#action_12457931 ] Jukka Zitting commented on JCR-626: --- Rationale for using a different DTD URL: It's better if the version number is included in the file name and not only in the directory. This way you can easily determine the contents of a DTD file even after you've downloaded it. Move document type definition out of repository.xml --- Key: JCR-626 URL: http://issues.apache.org/jira/browse/JCR-626 Project: Jackrabbit Issue Type: Improvement Components: config Affects Versions: 1.1 Reporter: Jan Kuzniak Assigned To: Jukka Zitting Priority: Minor Fix For: 1.2 Attachments: reposiory.dtd.patch Hello! Here at Cognifide, Przemo and I we got a bit confused while trying to solve JCR-202. There was a need to modify repository.xml configuration file and it's DTD, and we have found that there are different repository.xml files within trunk that differs this definition. I think that it is a good idea to extract this definition to a one separate file (and maybe .xsd instead of .dtd) and then link it in other files. It would be also nice to put this file somewhere on the Web and reference it via URL. I am waiting for your comments. Regards, Jan -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Assigned: (JCR-667) Variant spelling Trasaction and Transaction now in codebase
[ http://issues.apache.org/jira/browse/JCR-667?page=all ] Jukka Zitting reassigned JCR-667: - Assignee: Jukka Zitting Variant spelling Trasaction and Transaction now in codebase --- Key: JCR-667 URL: http://issues.apache.org/jira/browse/JCR-667 Project: Jackrabbit Issue Type: Improvement Components: jca Reporter: Lance Zechinato Assigned To: Jukka Zitting Incorrectly spelled Trasaction now in codebase. The correctly spelled Transaction appears a far greater number of times. Isolated to package: org.apache.jackrabbit.jca Incorrectly spelled Trasaction found in: (3x) JCAManagedConnection.java (7x) JCAManagedConnectionFActory.java Correctly spelled Transaction found in: (20x) JCAManagedConnection.java (2x) JCAManagedConnectionFActory.java (1x) JCAResourceAdapter.java (12x) TransactionBoundXAResource.java -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (JCR-667) Variant spelling Trasaction and Transaction now in codebase
[ http://issues.apache.org/jira/browse/JCR-667?page=all ] Jukka Zitting updated JCR-667: -- Component/s: jca (was: transactions) Affects Version/s: (was: 1.1) Priority: Trivial (was: Major) Variant spelling Trasaction and Transaction now in codebase --- Key: JCR-667 URL: http://issues.apache.org/jira/browse/JCR-667 Project: Jackrabbit Issue Type: Improvement Components: jca Reporter: Lance Zechinato Assigned To: Jukka Zitting Priority: Trivial Incorrectly spelled Trasaction now in codebase. The correctly spelled Transaction appears a far greater number of times. Isolated to package: org.apache.jackrabbit.jca Incorrectly spelled Trasaction found in: (3x) JCAManagedConnection.java (7x) JCAManagedConnectionFActory.java Correctly spelled Transaction found in: (20x) JCAManagedConnection.java (2x) JCAManagedConnectionFActory.java (1x) JCAResourceAdapter.java (12x) TransactionBoundXAResource.java -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Resolved: (JCR-667) Variant spelling Trasaction and Transaction now in codebase
[ http://issues.apache.org/jira/browse/JCR-667?page=all ] Jukka Zitting resolved JCR-667. --- Fix Version/s: 1.2 Resolution: Fixed Fixed in revision 486405. Thanks for reporting this! Variant spelling Trasaction and Transaction now in codebase --- Key: JCR-667 URL: http://issues.apache.org/jira/browse/JCR-667 Project: Jackrabbit Issue Type: Improvement Components: jca Reporter: Lance Zechinato Assigned To: Jukka Zitting Priority: Trivial Fix For: 1.2 Incorrectly spelled Trasaction now in codebase. The correctly spelled Transaction appears a far greater number of times. Isolated to package: org.apache.jackrabbit.jca Incorrectly spelled Trasaction found in: (3x) JCAManagedConnection.java (7x) JCAManagedConnectionFActory.java Correctly spelled Transaction found in: (20x) JCAManagedConnection.java (2x) JCAManagedConnectionFActory.java (1x) JCAResourceAdapter.java (12x) TransactionBoundXAResource.java -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (JCR-674) String properties with invalid XML characters export as invalid XML
String properties with invalid XML characters export as invalid XML --- Key: JCR-674 URL: http://issues.apache.org/jira/browse/JCR-674 Project: Jackrabbit Issue Type: Bug Components: xml Affects Versions: 1.1.1 Reporter: Joshua Levy As noted in the current JCR 1.0.1 maintenance draft, sections 6.4.1, 6.4.2.6, XML export of string properties that contain invalid XML characters isn't well-defined currently, since those characters are not permissible in XML. The proposed fix is to use base64 encoding for such values in System View. Most characters below #x20 are examples of this. Currently, these are escaped numerically in output (such as (amp)#0; ) but such escape sequences can't be parsed by the XML import methods. The current behavior is particularly problematic, because the user doesn't know the output is corrupt until later, when they try to import it and get InvalidSerializedDataException. If for some reason the base64 option is delayed, it might make sense, as an interim solution, to fail on export or to somehow patch import to relax its parsing and allow these escape codes. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
