[jira] Updated: (JCRRMI-29) JSR-283: Add new methods of javax.jcr.query.Query
[ https://issues.apache.org/jira/browse/JCRRMI-29?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Berry van Halderen updated JCRRMI-29: - Attachment: test.patch The earlier patch can be verified using the changes in this attached patch. However these changes use deprecated API and hence probably should not be applied. > JSR-283: Add new methods of javax.jcr.query.Query > - > > Key: JCRRMI-29 > URL: https://issues.apache.org/jira/browse/JCRRMI-29 > Project: Jackrabbit JCR-RMI > Issue Type: Sub-task >Affects Versions: 2.1.0 >Reporter: Berry van Halderen > Attachments: JCRRMI-29.patch, test.patch > > -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (JCRRMI-29) JSR-283: Add new methods of javax.jcr.query.Query
[ https://issues.apache.org/jira/browse/JCRRMI-29?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Berry van Halderen updated JCRRMI-29: - Attachment: JCRRMI-29.patch > JSR-283: Add new methods of javax.jcr.query.Query > - > > Key: JCRRMI-29 > URL: https://issues.apache.org/jira/browse/JCRRMI-29 > Project: Jackrabbit JCR-RMI > Issue Type: Sub-task >Affects Versions: 2.1.0 >Reporter: Berry van Halderen > Attachments: JCRRMI-29.patch > > -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (JCRRMI-29) JSR-283: Add new methods of javax.jcr.query.Query
[ https://issues.apache.org/jira/browse/JCRRMI-29?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Berry van Halderen updated JCRRMI-29: - Affects Version/s: 2.1.0 Status: Patch Available (was: Open) Patch against 2.1 branch revision 1035987. > JSR-283: Add new methods of javax.jcr.query.Query > - > > Key: JCRRMI-29 > URL: https://issues.apache.org/jira/browse/JCRRMI-29 > Project: Jackrabbit JCR-RMI > Issue Type: Sub-task >Affects Versions: 2.1.0 >Reporter: Berry van Halderen > Attachments: JCRRMI-29.patch > > -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (JCRRMI-29) JSR-283: Add new methods of javax.jcr.query.Query
JSR-283: Add new methods of javax.jcr.query.Query - Key: JCRRMI-29 URL: https://issues.apache.org/jira/browse/JCRRMI-29 Project: Jackrabbit JCR-RMI Issue Type: Sub-task Reporter: Berry van Halderen -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (JCR-2812) Allow whitespaces in base64 encoded binary fields of XML import files
[ https://issues.apache.org/jira/browse/JCR-2812?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Berry van Halderen updated JCR-2812: Attachment: patch This is a very simple, but effective way just to strip out whitespaces before the actual import of the Binary properties. Patch against trunk revision 1023682, but equally applicable to 2.1 or earlier versions. > Allow whitespaces in base64 encoded binary fields of XML import files > - > > Key: JCR-2812 > URL: https://issues.apache.org/jira/browse/JCR-2812 > Project: Jackrabbit Content Repository > Issue Type: Improvement > Components: jackrabbit-core >Affects Versions: 2.1.2, 2.2.0 >Reporter: Berry van Halderen >Priority: Minor > Fix For: 2.2.0 > > Attachments: patch > > > When importing files using Session.importXML(), the Binary property values > are Base64 encoded. However you cannot put whitespaces in them, and XML > files with binaries in them become very long lines. The files are more > manageable if whilespaces could be put in them, as is common to do in base > base64 encoded files. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (JCR-2812) Allow whitespaces in base64 encoded binary fields of XML import files
Allow whitespaces in base64 encoded binary fields of XML import files - Key: JCR-2812 URL: https://issues.apache.org/jira/browse/JCR-2812 Project: Jackrabbit Content Repository Issue Type: Improvement Components: jackrabbit-core Affects Versions: 2.1.2, 2.2.0 Reporter: Berry van Halderen Priority: Minor Fix For: 2.2.0 Attachments: patch When importing files using Session.importXML(), the Binary property values are Base64 encoded. However you cannot put whitespaces in them, and XML files with binaries in them become very long lines. The files are more manageable if whilespaces could be put in them, as is common to do in base base64 encoded files. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (JCR-2675) Node.hasProperty() with relative path can throw ClassCastException
Node.hasProperty() with relative path can throw ClassCastException -- Key: JCR-2675 URL: https://issues.apache.org/jira/browse/JCR-2675 Project: Jackrabbit Content Repository Issue Type: Bug Components: jackrabbit-core Affects Versions: 2.1.0, 2.0.0, 1.6.2, 1.5.7 Reporter: Berry van Halderen Calling Node.hasProperty() with a relative path that traverses higher than the root node will throw a ClassCastException because the ItemId returned by HierarchyManagerImpl.resolvePath() will be the root node id. The blind cast in the HierarchyManagerImpl.resolvePropertyPath() will then throw the ClassCastException. This issue is not just with hasProperty/resolvePropertyPath, but any call to resolvePath that goes higher than the root node, will wrongfully get the root node id returned as result. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (JCR-2675) Node.hasProperty() with relative path can throw ClassCastException
[ https://issues.apache.org/jira/browse/JCR-2675?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Berry van Halderen updated JCR-2675: Attachment: patch The attached patch resolves this issue by making sure a path passed to resolvePath can fully be resolved. The patch is against the 1.5.7 patch, but can be applied to jackrabbit-trunk or other versions as well. > Node.hasProperty() with relative path can throw ClassCastException > -- > > Key: JCR-2675 > URL: https://issues.apache.org/jira/browse/JCR-2675 > Project: Jackrabbit Content Repository > Issue Type: Bug > Components: jackrabbit-core >Affects Versions: 1.5.7, 1.6.2, 2.0.0, 2.1.0 >Reporter: Berry van Halderen > Attachments: IssueTest.java, patch > > > Calling Node.hasProperty() with a relative path that traverses higher than > the root node will throw a ClassCastException because the ItemId returned by > HierarchyManagerImpl.resolvePath() will be the root node id. The blind cast > in the HierarchyManagerImpl.resolvePropertyPath() will then throw the > ClassCastException. This issue is not just with > hasProperty/resolvePropertyPath, but any call to resolvePath that goes higher > than the root node, will wrongfully get the root node id returned as result. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (JCR-2675) Node.hasProperty() with relative path can throw ClassCastException
[ https://issues.apache.org/jira/browse/JCR-2675?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Berry van Halderen updated JCR-2675: Attachment: IssueTest.java The following unit test shows the problem, although as indicated, the issue has broader consequences. IssueTest can be placed in jackrabbit-core/src/test/java/org/apache/jackrabbit/core/IssueTest.java and when run will throw the ClassCastException. > Node.hasProperty() with relative path can throw ClassCastException > -- > > Key: JCR-2675 > URL: https://issues.apache.org/jira/browse/JCR-2675 > Project: Jackrabbit Content Repository > Issue Type: Bug > Components: jackrabbit-core >Affects Versions: 1.5.7, 1.6.2, 2.0.0, 2.1.0 >Reporter: Berry van Halderen > Attachments: IssueTest.java > > > Calling Node.hasProperty() with a relative path that traverses higher than > the root node will throw a ClassCastException because the ItemId returned by > HierarchyManagerImpl.resolvePath() will be the root node id. The blind cast > in the HierarchyManagerImpl.resolvePropertyPath() will then throw the > ClassCastException. This issue is not just with > hasProperty/resolvePropertyPath, but any call to resolvePath that goes higher > than the root node, will wrongfully get the root node id returned as result. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (JCR-2633) Modified externally exception when modifying mixinTypes with single session
[
https://issues.apache.org/jira/browse/JCR-2633?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Berry van Halderen updated JCR-2633:
Attachment: holdrefs.patch
persistMixinTypes.patch
The holdrefs.patch patches the issue in a relative ugly way, but effective.
The secondary changes the storage scheme, but is more in line with the intended
implementation IMHO.
> Modified externally exception when modifying mixinTypes with single session
> ---
>
> Key: JCR-2633
> URL: https://issues.apache.org/jira/browse/JCR-2633
> Project: Jackrabbit Content Repository
> Issue Type: Bug
> Components: jackrabbit-core
>Affects Versions: 1.5.7, 2.0.0, 2.1.0
> Environment: Bundle persistency manager based storage, Jackrabbit
> 1.5.7 but issue also present in newer versions
>Reporter: Berry van Halderen
>Priority: Critical
> Attachments: holdrefs.patch, issue.patch, persistMixinTypes.patch
>
>
> When first adding mixins and later removing all mixins, a system under heavy
> stress might experience a modified externally exception even though there is
> only a single session into the repository.
> The unit test with forced GC and shrinking of caches indicates the problem.
> The unit test itself is mostly trivial, the problem arrises when you add a
> mixin to a node, save it, do this again with another mixin and then remove
> both mixins and in the following save the shared item state cache is shrunk,
> and the garbage collectors hits at exactly the right time. In the unit test a
> reference to the jcr:mixinTypes property must have been held.
> What will happen is that the ItemState of the jcr:mixinTypes property will get
> a modification count higher than 0 when addin the mixins. Because a reference
> to the property is kept, it will not be evicted from the primary cache in the
> local item state manager. When removing all mixins, an overlayed state will
> be created of this ItemState. Because the state and overlayed state are
> linked, the ItemState won't be dropped from the primary cache of the shared
> item state manager.
> But is MAY be evicted from the secondary cache implementing the LRU/FIFO
> functionality. If this is the case when while persisting the changes there is
> a small window where the overlayed state will be disconnected from the state.
> This happens just before collecting the changelog at:
> o.a.j.c.state.ItemState.disconnect():211
> o.a.j.c.state.SessionItemStateManager.disconnectTransientItemState():674
> o.a.j.c.PropertyImpl.makePersistent():143
> o.a.j.c.ItemImpl.persistTransientItems():609
> o.a.j.c.ItemImpl.save():1087
> o.a.j.c.SessionImpl.save():858
> Or in the when actually collecting the changelog in one of the methods
> Changelog.{modified(),deleted() or both. I think the latter, but not really
> sure.
> In any case, this breaks the bondage that prevents the cached state in the
> shared item state manager.
> Now if the shared item state cache has been shrunk enough and the GC hits
> before o.a.j.c.state.SharedItemStateManager.Update.begin():650 when the
> disconnected state will be purged from the shared item state cache. Just
> below line 650 the check for stale items will then cause a re-retrieval from
> the persisted store of the property. Because that state will have a
> modification count of 0, it will conflict with the modification count of the
> mixin property type that is being persisted.
> It is true that the GC needs to go off at exactly the right time and the
> secondary cache needs to have shrunk to be able to evict the item. This can
> however happen in extreme cases. The patch that contains the unit test
> contains code that will force the purging of the item.
> There is still the matter why the modcount comes back at 0 when retrieving the
> property from the persistence manager, basically the assumption made in the
> code between session, local, and shared item state managers, their caches,
> etcetera is that the modification count in the shared item state is always
> incremented, and never reset.
> There is an apparent contract (partially documented) that the modification
> count is to be persisted. Which is in fact the case for the InMemPersistence-
> Manager, but all bundle derived persistence managers do not persist the
> jcr:mixinType property at all, but just the mixintypes as part of the
> nodedefinition information. This means that the jcr:mixinTypes property will
> always be re-created with modcount of 0, which leads to clashes.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (JCR-2633) Modified externally exception when modifying mixinTypes with single session
[
https://issues.apache.org/jira/browse/JCR-2633?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Berry van Halderen updated JCR-2633:
Attachment: issue.patch
Unit test including some patch that triggers a GC and shrinking of cache at the
right time to trigger the issue.
> Modified externally exception when modifying mixinTypes with single session
> ---
>
> Key: JCR-2633
> URL: https://issues.apache.org/jira/browse/JCR-2633
> Project: Jackrabbit Content Repository
> Issue Type: Bug
> Components: jackrabbit-core
>Affects Versions: 1.5.7, 2.0.0, 2.1.0
> Environment: Bundle persistency manager based storage, Jackrabbit
> 1.5.7 but issue also present in newer versions
>Reporter: Berry van Halderen
>Priority: Critical
> Attachments: issue.patch
>
>
> When first adding mixins and later removing all mixins, a system under heavy
> stress might experience a modified externally exception even though there is
> only a single session into the repository.
> The unit test with forced GC and shrinking of caches indicates the problem.
> The unit test itself is mostly trivial, the problem arrises when you add a
> mixin to a node, save it, do this again with another mixin and then remove
> both mixins and in the following save the shared item state cache is shrunk,
> and the garbage collectors hits at exactly the right time. In the unit test a
> reference to the jcr:mixinTypes property must have been held.
> What will happen is that the ItemState of the jcr:mixinTypes property will get
> a modification count higher than 0 when addin the mixins. Because a reference
> to the property is kept, it will not be evicted from the primary cache in the
> local item state manager. When removing all mixins, an overlayed state will
> be created of this ItemState. Because the state and overlayed state are
> linked, the ItemState won't be dropped from the primary cache of the shared
> item state manager.
> But is MAY be evicted from the secondary cache implementing the LRU/FIFO
> functionality. If this is the case when while persisting the changes there is
> a small window where the overlayed state will be disconnected from the state.
> This happens just before collecting the changelog at:
> o.a.j.c.state.ItemState.disconnect():211
> o.a.j.c.state.SessionItemStateManager.disconnectTransientItemState():674
> o.a.j.c.PropertyImpl.makePersistent():143
> o.a.j.c.ItemImpl.persistTransientItems():609
> o.a.j.c.ItemImpl.save():1087
> o.a.j.c.SessionImpl.save():858
> Or in the when actually collecting the changelog in one of the methods
> Changelog.{modified(),deleted() or both. I think the latter, but not really
> sure.
> In any case, this breaks the bondage that prevents the cached state in the
> shared item state manager.
> Now if the shared item state cache has been shrunk enough and the GC hits
> before o.a.j.c.state.SharedItemStateManager.Update.begin():650 when the
> disconnected state will be purged from the shared item state cache. Just
> below line 650 the check for stale items will then cause a re-retrieval from
> the persisted store of the property. Because that state will have a
> modification count of 0, it will conflict with the modification count of the
> mixin property type that is being persisted.
> It is true that the GC needs to go off at exactly the right time and the
> secondary cache needs to have shrunk to be able to evict the item. This can
> however happen in extreme cases. The patch that contains the unit test
> contains code that will force the purging of the item.
> There is still the matter why the modcount comes back at 0 when retrieving the
> property from the persistence manager, basically the assumption made in the
> code between session, local, and shared item state managers, their caches,
> etcetera is that the modification count in the shared item state is always
> incremented, and never reset.
> There is an apparent contract (partially documented) that the modification
> count is to be persisted. Which is in fact the case for the InMemPersistence-
> Manager, but all bundle derived persistence managers do not persist the
> jcr:mixinType property at all, but just the mixintypes as part of the
> nodedefinition information. This means that the jcr:mixinTypes property will
> always be re-created with modcount of 0, which leads to clashes.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Created: (JCR-2633) Modified externally exception when modifying mixinTypes with single session
Modified externally exception when modifying mixinTypes with single session
---
Key: JCR-2633
URL: https://issues.apache.org/jira/browse/JCR-2633
Project: Jackrabbit Content Repository
Issue Type: Bug
Components: jackrabbit-core
Affects Versions: 2.1.0, 2.0.0, 1.5.7
Environment: Bundle persistency manager based storage, Jackrabbit
1.5.7 but issue also present in newer versions
Reporter: Berry van Halderen
Priority: Critical
When first adding mixins and later removing all mixins, a system under heavy
stress might experience a modified externally exception even though there is
only a single session into the repository.
The unit test with forced GC and shrinking of caches indicates the problem.
The unit test itself is mostly trivial, the problem arrises when you add a
mixin to a node, save it, do this again with another mixin and then remove
both mixins and in the following save the shared item state cache is shrunk,
and the garbage collectors hits at exactly the right time. In the unit test a
reference to the jcr:mixinTypes property must have been held.
What will happen is that the ItemState of the jcr:mixinTypes property will get
a modification count higher than 0 when addin the mixins. Because a reference
to the property is kept, it will not be evicted from the primary cache in the
local item state manager. When removing all mixins, an overlayed state will
be created of this ItemState. Because the state and overlayed state are
linked, the ItemState won't be dropped from the primary cache of the shared
item state manager.
But is MAY be evicted from the secondary cache implementing the LRU/FIFO
functionality. If this is the case when while persisting the changes there is
a small window where the overlayed state will be disconnected from the state.
This happens just before collecting the changelog at:
o.a.j.c.state.ItemState.disconnect():211
o.a.j.c.state.SessionItemStateManager.disconnectTransientItemState():674
o.a.j.c.PropertyImpl.makePersistent():143
o.a.j.c.ItemImpl.persistTransientItems():609
o.a.j.c.ItemImpl.save():1087
o.a.j.c.SessionImpl.save():858
Or in the when actually collecting the changelog in one of the methods
Changelog.{modified(),deleted() or both. I think the latter, but not really
sure.
In any case, this breaks the bondage that prevents the cached state in the
shared item state manager.
Now if the shared item state cache has been shrunk enough and the GC hits
before o.a.j.c.state.SharedItemStateManager.Update.begin():650 when the
disconnected state will be purged from the shared item state cache. Just
below line 650 the check for stale items will then cause a re-retrieval from
the persisted store of the property. Because that state will have a
modification count of 0, it will conflict with the modification count of the
mixin property type that is being persisted.
It is true that the GC needs to go off at exactly the right time and the
secondary cache needs to have shrunk to be able to evict the item. This can
however happen in extreme cases. The patch that contains the unit test
contains code that will force the purging of the item.
There is still the matter why the modcount comes back at 0 when retrieving the
property from the persistence manager, basically the assumption made in the
code between session, local, and shared item state managers, their caches,
etcetera is that the modification count in the shared item state is always
incremented, and never reset.
There is an apparent contract (partially documented) that the modification
count is to be persisted. Which is in fact the case for the InMemPersistence-
Manager, but all bundle derived persistence managers do not persist the
jcr:mixinType property at all, but just the mixintypes as part of the
nodedefinition information. This means that the jcr:mixinTypes property will
always be re-created with modcount of 0, which leads to clashes.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Closed: (JCR-953) Support for transactions when using JCR over RMI.
[ https://issues.apache.org/jira/browse/JCR-953?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Berry van Halderen closed JCR-953. -- Verified, works. Thanks a bunch. > Support for transactions when using JCR over RMI. > - > > Key: JCR-953 > URL: https://issues.apache.org/jira/browse/JCR-953 > Project: Jackrabbit > Issue Type: Improvement > Components: rmi >Reporter: Berry van Halderen >Assignee: Jukka Zitting >Priority: Minor > Fix For: 1.4 > > Attachments: patch, patch, test.zip > > > At this time, the sessions obtained from o.a.j.rmi.client.LocalAdapterFactory > do not implement the methods for the XASession. Therefor the RMI access > layer does not support a transactional session. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (JCR-953) Support for transactions when using JCR over RMI.
[ https://issues.apache.org/jira/browse/JCR-953?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12526142 ] Berry van Halderen commented on JCR-953: I think that my minor patch from earlier today can be applied without modifications. I've tested with the test application and then it seems to work fine. > Support for transactions when using JCR over RMI. > - > > Key: JCR-953 > URL: https://issues.apache.org/jira/browse/JCR-953 > Project: Jackrabbit > Issue Type: Improvement > Components: rmi >Reporter: Berry van Halderen >Assignee: Jukka Zitting >Priority: Minor > Fix For: 1.4 > > Attachments: patch, patch, test.zip > > > At this time, the sessions obtained from o.a.j.rmi.client.LocalAdapterFactory > do not implement the methods for the XASession. Therefor the RMI access > layer does not support a transactional session. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (JCR-953) Support for transactions when using JCR over RMI.
[ https://issues.apache.org/jira/browse/JCR-953?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Berry van Halderen updated JCR-953: --- Attachment: test.zip Changes to test application to take into account that the XASession has been moved to JackRabbit API iso. core jar. > Support for transactions when using JCR over RMI. > - > > Key: JCR-953 > URL: https://issues.apache.org/jira/browse/JCR-953 > Project: Jackrabbit > Issue Type: Improvement > Components: rmi >Reporter: Berry van Halderen >Assignee: Jukka Zitting >Priority: Minor > Fix For: 1.4 > > Attachments: patch, patch, test.zip > > > At this time, the sessions obtained from o.a.j.rmi.client.LocalAdapterFactory > do not implement the methods for the XASession. Therefor the RMI access > layer does not support a transactional session. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (JCR-953) Support for transactions when using JCR over RMI.
[ https://issues.apache.org/jira/browse/JCR-953?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Berry van Halderen updated JCR-953: --- Attachment: patch Minor patch to earlier changes, as the ServerXAResource needs to be a remote object. > Support for transactions when using JCR over RMI. > - > > Key: JCR-953 > URL: https://issues.apache.org/jira/browse/JCR-953 > Project: Jackrabbit > Issue Type: Improvement > Components: rmi >Reporter: Berry van Halderen >Assignee: Jukka Zitting >Priority: Minor > Fix For: 1.4 > > Attachments: patch, patch > > > At this time, the sessions obtained from o.a.j.rmi.client.LocalAdapterFactory > do not implement the methods for the XASession. Therefor the RMI access > layer does not support a transactional session. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (JCR-953) Support for transactions when using JCR over RMI.
[ https://issues.apache.org/jira/browse/JCR-953?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Berry van Halderen updated JCR-953: --- Attachment: (was: test.zip) > Support for transactions when using JCR over RMI. > - > > Key: JCR-953 > URL: https://issues.apache.org/jira/browse/JCR-953 > Project: Jackrabbit > Issue Type: Improvement > Components: rmi >Reporter: Berry van Halderen >Assignee: Jukka Zitting >Priority: Minor > Fix For: 1.4 > > Attachments: patch > > > At this time, the sessions obtained from o.a.j.rmi.client.LocalAdapterFactory > do not implement the methods for the XASession. Therefor the RMI access > layer does not support a transactional session. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Reopened: (JCR-953) Support for transactions when using JCR over RMI.
[ https://issues.apache.org/jira/browse/JCR-953?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Berry van Halderen reopened JCR-953: Doesn't quite work yet, because SessionXAResource is not available remotely. Will provide easy and small fix in next attached patch. > Support for transactions when using JCR over RMI. > - > > Key: JCR-953 > URL: https://issues.apache.org/jira/browse/JCR-953 > Project: Jackrabbit > Issue Type: Improvement > Components: rmi >Reporter: Berry van Halderen >Assignee: Jukka Zitting >Priority: Minor > Fix For: 1.4 > > Attachments: patch > > > At this time, the sessions obtained from o.a.j.rmi.client.LocalAdapterFactory > do not implement the methods for the XASession. Therefor the RMI access > layer does not support a transactional session. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (JCR-953) Support for transactions when using JCR over RMI.
[ https://issues.apache.org/jira/browse/JCR-953?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12523554 ] Berry van Halderen commented on JCR-953: Indeed, the jackrabbit-core dependency is pretty ugly. There is no proper way other than to pull the XASession out of the core into the api. This would be a simple move operation and would cleanly fix it. It is a pitty that the XASession interface did not make it into the specification. I saw that in earlier draft there was a reference to this: http://www.day.com/maven/jsr170/javadocs/jcr-0.15/javax/jcr/xa/XASession.html But it did not make it into the spec. It strikes me as an omission that the spec defines a level for transaction, but not an interface to obtain a XAResource (as is given by XASession). > Support for transactions when using JCR over RMI. > - > > Key: JCR-953 > URL: https://issues.apache.org/jira/browse/JCR-953 > Project: Jackrabbit > Issue Type: Improvement > Components: rmi >Reporter: Berry van Halderen >Priority: Minor > Attachments: patch, test.zip > > > At this time, the sessions obtained from o.a.j.rmi.client.LocalAdapterFactory > do not implement the methods for the XASession. Therefor the RMI access > layer does not support a transactional session. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (JCR-953) Support for transactions when using JCR over RMI.
[ https://issues.apache.org/jira/browse/JCR-953?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Berry van Halderen updated JCR-953: --- Attachment: test.zip I used the following project to test the transaction support in RMI. The test can be run seperately or as unit test, though these client-server test do not lend themselves for unit test in general. A mock up test is useless in this case anyway. > Support for transactions when using JCR over RMI. > - > > Key: JCR-953 > URL: https://issues.apache.org/jira/browse/JCR-953 > Project: Jackrabbit > Issue Type: Improvement > Components: rmi >Reporter: Berry van Halderen >Priority: Minor > Attachments: patch, test.zip > > > At this time, the sessions obtained from o.a.j.rmi.client.LocalAdapterFactory > do not implement the methods for the XASession. Therefor the RMI access > layer does not support a transactional session. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (JCR-953) Support for transactions when using JCR over RMI.
[ https://issues.apache.org/jira/browse/JCR-953?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Berry van Halderen updated JCR-953: --- Attachment: patch Patch which was made from SVN revision 570736 of the jackrabbit source. This implements transactional based RMI support. > Support for transactions when using JCR over RMI. > - > > Key: JCR-953 > URL: https://issues.apache.org/jira/browse/JCR-953 > Project: Jackrabbit > Issue Type: Improvement > Components: rmi >Reporter: Berry van Halderen >Priority: Minor > Attachments: patch > > > At this time, the sessions obtained from o.a.j.rmi.client.LocalAdapterFactory > do not implement the methods for the XASession. Therefor the RMI access > layer does not support a transactional session. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (JCR-953) Support for transactions when using JCR over RMI.
[ https://issues.apache.org/jira/browse/JCR-953?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12500111 ] Berry van Halderen commented on JCR-953: I think the only thing that needed to be implemented is to extend both client and server side decorator stubs to implement the XAResource interface. The client, when asked for the getXAResource() can just return itself. In the implementation of the XAResource interface the client stub can just call the server side stub over RMI. The server side stub just forwards the call to the actual session. This works because the transaction IDs (Xid) are serializable, and can be passed over RMI. The transactions themselves are managed at the client side. I will be providing a proposal patch for this shortly. > Support for transactions when using JCR over RMI. > - > > Key: JCR-953 > URL: https://issues.apache.org/jira/browse/JCR-953 > Project: Jackrabbit > Issue Type: Improvement > Components: rmi >Reporter: Berry van Halderen >Priority: Minor > > At this time, the sessions obtained from o.a.j.rmi.client.LocalAdapterFactory > do not implement the methods for the XASession. Therefor the RMI access > layer does not support a transactional session. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (JCR-953) Support for transactions when using JCR over RMI.
Support for transactions when using JCR over RMI. - Key: JCR-953 URL: https://issues.apache.org/jira/browse/JCR-953 Project: Jackrabbit Issue Type: Improvement Components: rmi Reporter: Berry van Halderen Priority: Minor At this time, the sessions obtained from o.a.j.rmi.client.LocalAdapterFactory do not implement the methods for the XASession. Therefor the RMI access layer does not support a transactional session. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
