[jira] Updated: (JCR-872) Cache framework integration
[ https://issues.apache.org/jira/browse/JCR-872?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Padraic Hannon updated JCR-872: --- Attachment: ocm_cache.zip Here is the work I have done so far. I do not have test cases specific for this implementation as I have been working on these files against my existing internal test cases. To use this from within Spring (it requires SessionFactory to make everything work), wire it up as a replacement to JcrMappingTemplate: > Cache framework integration > --- > > Key: JCR-872 > URL: https://issues.apache.org/jira/browse/JCR-872 > Project: Jackrabbit > Issue Type: Task > Components: jackrabbit-ocm >Reporter: Christophe Lombart > Attachments: ocm_cache.zip > > > OCM should work with a cache manager. > * The Spring frameworks offer a nice solution to integrate an application > with a cache manager (based on AOP). > * Which cache framework to use ? oscache, JCS, ... > * A more detailled proposal is required -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Issue Comment Edited: (JCR-1312) Get rid of DOM for XML support
[ https://issues.apache.org/jira/browse/JCR-1312?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12560103#action_12560103 ] hannonpi edited comment on JCR-1312 at 1/17/08 2:04 PM: -- All of our current CQ publish instances are currently CPU bound. So, while, XML performance may not be the central issue, anything we can do to reduce CPU overhead would be helpful for us here. That being said it seems that kxml's (and perhaps jixb's) pull parser approach has given us performance gains and lower footprints when compared to jaxb and other mechanisms (http://www.ibm.com/developerworks/library/x-databdopt2/ for info on jixb). was (Author: hannonpi): All of our current CQ publish instances are currently CPU bound. So, while, XML performance may not be the central issue, anything we can do to reduce CPU overhead would be helpful for us here. > Get rid of DOM for XML support > -- > > Key: JCR-1312 > URL: https://issues.apache.org/jira/browse/JCR-1312 > Project: Jackrabbit > Issue Type: Improvement > Components: jackrabbit-webdav >Reporter: Felix Meschberger > > Currently the web dav library uses Xerces and DOM to parse and create XML > data. This mechanism is well-known but has two major issues: It is slow and > it has a big memory footprint. In order to solve these two issues, I suggest > to drop the use of the W3C DOM in webdav in favor of something easier and > more straight forward to use. > One candidate could be (out of my head and based on my bias towards KXml) > KDOM. See also http://www.kxml.org.ww > See also JCR-1261 for more discussions on this issue. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (JCR-1312) Get rid of DOM for XML support
[ https://issues.apache.org/jira/browse/JCR-1312?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12560103#action_12560103 ] Padraic Hannon commented on JCR-1312: - All of our current CQ publish instances are currently CPU bound. So, while, XML performance may not be the central issue, anything we can do to reduce CPU overhead would be helpful for us here. > Get rid of DOM for XML support > -- > > Key: JCR-1312 > URL: https://issues.apache.org/jira/browse/JCR-1312 > Project: Jackrabbit > Issue Type: Improvement > Components: jackrabbit-webdav >Reporter: Felix Meschberger > > Currently the web dav library uses Xerces and DOM to parse and create XML > data. This mechanism is well-known but has two major issues: It is slow and > it has a big memory footprint. In order to solve these two issues, I suggest > to drop the use of the W3C DOM in webdav in favor of something easier and > more straight forward to use. > One candidate could be (out of my head and based on my bias towards KXml) > KDOM. See also http://www.kxml.org.ww > See also JCR-1261 for more discussions on this issue. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Issue Comment Edited: (JCR-872) Cache framework integration
[ https://issues.apache.org/jira/browse/JCR-872?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12559659#action_12559659 ] hannonpi edited comment on JCR-872 at 1/16/08 1:12 PM: - Please disregard the patch I created. I messed up due to not taking the time to understand what was going on. I am going to remove the patch. I thought I was working on a second level cache. The RequestObjectCache is a first level cache which as Christophe pointed out and I didn't follow is basically used only to prevent infinite recursion. was (Author: hannonpi): Please disregard the patch I created. I messed up due to not taking the time to understand what was going on. I am working on revising it now. > Cache framework integration > --- > > Key: JCR-872 > URL: https://issues.apache.org/jira/browse/JCR-872 > Project: Jackrabbit > Issue Type: Task > Components: jackrabbit-ocm >Reporter: Christophe Lombart > > OCM should work with a cache manager. > * The Spring frameworks offer a nice solution to integrate an application > with a cache manager (based on AOP). > * Which cache framework to use ? oscache, JCS, ... > * A more detailled proposal is required -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (JCR-872) Cache framework integration
[ https://issues.apache.org/jira/browse/JCR-872?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Padraic Hannon updated JCR-872: --- Attachment: (was: observableCache.patch) > Cache framework integration > --- > > Key: JCR-872 > URL: https://issues.apache.org/jira/browse/JCR-872 > Project: Jackrabbit > Issue Type: Task > Components: jackrabbit-ocm >Reporter: Christophe Lombart > > OCM should work with a cache manager. > * The Spring frameworks offer a nice solution to integrate an application > with a cache manager (based on AOP). > * Which cache framework to use ? oscache, JCS, ... > * A more detailled proposal is required -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (JCR-872) Cache framework integration
[ https://issues.apache.org/jira/browse/JCR-872?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12559659#action_12559659 ] Padraic Hannon commented on JCR-872: Please disregard the patch I created. I messed up due to not taking the time to understand what was going on. I am working on revising it now. > Cache framework integration > --- > > Key: JCR-872 > URL: https://issues.apache.org/jira/browse/JCR-872 > Project: Jackrabbit > Issue Type: Task > Components: jackrabbit-ocm >Reporter: Christophe Lombart > Attachments: observableCache.patch > > > OCM should work with a cache manager. > * The Spring frameworks offer a nice solution to integrate an application > with a cache manager (based on AOP). > * Which cache framework to use ? oscache, JCS, ... > * A more detailled proposal is required -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (JCR-872) Cache framework integration
[ https://issues.apache.org/jira/browse/JCR-872?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12559597#action_12559597 ] Padraic Hannon commented on JCR-872: I'm working on ehcache now. I probably was confusing in my statement re. hibernate. I was looking at the hibernate Cache/CacheProvider pattern as starting point for how we might want to create a pluggable infrastructure. I *do not* want to rely on their infrastructure. However, since there stuff is easily configurable I thought it would be good to look at what they did as an example. > Cache framework integration > --- > > Key: JCR-872 > URL: https://issues.apache.org/jira/browse/JCR-872 > Project: Jackrabbit > Issue Type: Task > Components: jackrabbit-ocm >Reporter: Christophe Lombart > Attachments: observableCache.patch > > > OCM should work with a cache manager. > * The Spring frameworks offer a nice solution to integrate an application > with a cache manager (based on AOP). > * Which cache framework to use ? oscache, JCS, ... > * A more detailled proposal is required -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (JCR-872) Cache framework integration
[ https://issues.apache.org/jira/browse/JCR-872?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Padraic Hannon updated JCR-872: --- Attachment: observableCache.patch This patch provides the following: 1) Updates to RequestObjectCacheImpl to provide observation to flush based on jcr events 2) Updates ObjectCache interface to extend Map (first step in allowing other caches) 3) Provides the ability to set the cache on the ObjectContentManager and have that ripple to the ObjectConverterImpl (so we can use a config file to set cache after construction of the content manager) 4) Simple cache unit tests I was going to go down the hibernate cache provider route, but felt it was a bit overkill. Tomorrow I will create instances of the cache using EhCache. >From there I think I will try a Tangosol one. > Cache framework integration > --- > > Key: JCR-872 > URL: https://issues.apache.org/jira/browse/JCR-872 > Project: Jackrabbit > Issue Type: Task > Components: jackrabbit-ocm >Reporter: Christophe Lombart > Attachments: observableCache.patch > > > The PersistenceManager should work with a cache manager. > * The Spring frameworks offer a nice solution to integrate an application > with a cache manager (based on AOP). > * Which cache framework to use ? oscache, JCS, ... > * A more detailled proposal is required -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (JCR-872) Cache framework integration
[ https://issues.apache.org/jira/browse/JCR-872?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12559243#action_12559243 ] Padraic Hannon commented on JCR-872: Until we have a robust cache framework we should remove the current implementation as it poses some problems the two that I've run into are: 1) Unbounded HashMap with no size limits 2) No observation mechanism to detect underlying changes to jcr nodes > Cache framework integration > --- > > Key: JCR-872 > URL: https://issues.apache.org/jira/browse/JCR-872 > Project: Jackrabbit > Issue Type: Task > Components: jackrabbit-ocm >Reporter: Christophe Lombart > > The PersistenceManager should work with a cache manager. > * The Spring frameworks offer a nice solution to integrate an application > with a cache manager (based on AOP). > * Which cache framework to use ? oscache, JCS, ... > * A more detailled proposal is required -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (JCR-1218) RepositoryUtil moved outside of main source tree
[ https://issues.apache.org/jira/browse/JCR-1218?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12555994#action_12555994 ] Padraic Hannon commented on JCR-1218: - The problem with there is that the spring part of the ocm project relies on the repository util class. If we do not want this class to exist we need to refactor the spring code and then remove it. > RepositoryUtil moved outside of main source tree > > > Key: JCR-1218 > URL: https://issues.apache.org/jira/browse/JCR-1218 > Project: Jackrabbit > Issue Type: Bug > Components: jackrabbit-ocm >Affects Versions: 1.3.3 >Reporter: Padraic Hannon >Assignee: Christophe Lombart >Priority: Blocker > Fix For: 1.4 > > Attachments: move-repositoryutil.patch > > > It appears that the RepositoryUtil class was moved from src/main to src/test. > This class is used by the ocm-spring project. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (JCR-1218) RepositoryUtil moved outside of main source tree
[ https://issues.apache.org/jira/browse/JCR-1218?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12543244 ] Padraic Hannon commented on JCR-1218: - basically need to move jcr-mapping/src/test/java/org/apache/jackrabbit/ocm/repository/RepositoryUtil.java to jcr-mapping/src/main/java/org/apache/jackrabbit/ocm/repository/RepositoryUtil.java > RepositoryUtil moved outside of main source tree > > > Key: JCR-1218 > URL: https://issues.apache.org/jira/browse/JCR-1218 > Project: Jackrabbit > Issue Type: Bug > Components: jcr-mapping >Affects Versions: 1.3.3 >Reporter: Padraic Hannon >Priority: Blocker > Attachments: move-repositoryutil.patch > > > It appears that the RepositoryUtil class was moved from src/main to src/test. > This class is used by the ocm-spring project. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (JCR-1218) RepositoryUtil moved outside of main source tree
[ https://issues.apache.org/jira/browse/JCR-1218?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Padraic Hannon updated JCR-1218: Priority: Blocker (was: Major) > RepositoryUtil moved outside of main source tree > > > Key: JCR-1218 > URL: https://issues.apache.org/jira/browse/JCR-1218 > Project: Jackrabbit > Issue Type: Bug > Components: jcr-mapping >Affects Versions: 1.3.3 >Reporter: Padraic Hannon >Priority: Blocker > Attachments: move-repositoryutil.patch > > > It appears that the RepositoryUtil class was moved from src/main to src/test. > This class is used by the ocm-spring project. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (JCR-1218) RepositoryUtil moved outside of main source tree
[ https://issues.apache.org/jira/browse/JCR-1218?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Padraic Hannon updated JCR-1218: Attachment: move-repositoryutil.patch > RepositoryUtil moved outside of main source tree > > > Key: JCR-1218 > URL: https://issues.apache.org/jira/browse/JCR-1218 > Project: Jackrabbit > Issue Type: Bug > Components: jcr-mapping >Affects Versions: 1.3.3 >Reporter: Padraic Hannon >Priority: Blocker > Attachments: move-repositoryutil.patch > > > It appears that the RepositoryUtil class was moved from src/main to src/test. > This class is used by the ocm-spring project. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (JCR-1219) RepositoryUtil moved outside of main source tree
[ https://issues.apache.org/jira/browse/JCR-1219?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Padraic Hannon resolved JCR-1219. - Resolution: Duplicate Duplicates JCR-1218 > RepositoryUtil moved outside of main source tree > > > Key: JCR-1219 > URL: https://issues.apache.org/jira/browse/JCR-1219 > Project: Jackrabbit > Issue Type: Bug > Components: jcr-mapping >Affects Versions: 1.3.3 >Reporter: Padraic Hannon > > It appears that the RepositoryUtil class was moved from src/main to src/test. > This class is used by the ocm-spring project. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (JCR-1219) RepositoryUtil moved outside of main source tree
RepositoryUtil moved outside of main source tree Key: JCR-1219 URL: https://issues.apache.org/jira/browse/JCR-1219 Project: Jackrabbit Issue Type: Bug Components: jcr-mapping Affects Versions: 1.3.3 Reporter: Padraic Hannon It appears that the RepositoryUtil class was moved from src/main to src/test. This class is used by the ocm-spring project. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (JCR-1218) RepositoryUtil moved outside of main source tree
RepositoryUtil moved outside of main source tree Key: JCR-1218 URL: https://issues.apache.org/jira/browse/JCR-1218 Project: Jackrabbit Issue Type: Bug Components: jcr-mapping Affects Versions: 1.3.3 Reporter: Padraic Hannon It appears that the RepositoryUtil class was moved from src/main to src/test. This class is used by the ocm-spring project. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (JCR-1043) Package names for spring project do not match update ocm packages
[ https://issues.apache.org/jira/browse/JCR-1043?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Padraic Hannon updated JCR-1043: Attachment: (was: spring-mvn2.patch) > Package names for spring project do not match update ocm packages > - > > Key: JCR-1043 > URL: https://issues.apache.org/jira/browse/JCR-1043 > Project: Jackrabbit > Issue Type: Bug > Components: jcr-mapping >Affects Versions: 1.3 > Environment: All environments >Reporter: Padraic Hannon >Assignee: Christophe Lombart >Priority: Blocker > Attachments: spring-mvn2.patch, spring.patch > > > The spring package and tests reference the old graffitto package naming > scheme. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (JCR-1043) Package names for spring project do not match update ocm packages
[ https://issues.apache.org/jira/browse/JCR-1043?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Padraic Hannon updated JCR-1043: Attachment: spring-mvn2.patch > Package names for spring project do not match update ocm packages > - > > Key: JCR-1043 > URL: https://issues.apache.org/jira/browse/JCR-1043 > Project: Jackrabbit > Issue Type: Bug > Components: jcr-mapping >Affects Versions: 1.3 > Environment: All environments >Reporter: Padraic Hannon >Assignee: Christophe Lombart >Priority: Blocker > Attachments: spring-mvn2.patch, spring.patch > > > The spring package and tests reference the old graffitto package naming > scheme. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (JCR-1043) Package names for spring project do not match update ocm packages
[ https://issues.apache.org/jira/browse/JCR-1043?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Padraic Hannon updated JCR-1043: Attachment: spring-mvn2.patch Updated to move things to maven2 > Package names for spring project do not match update ocm packages > - > > Key: JCR-1043 > URL: https://issues.apache.org/jira/browse/JCR-1043 > Project: Jackrabbit > Issue Type: Bug > Components: jcr-mapping >Affects Versions: 1.3 > Environment: All environments >Reporter: Padraic Hannon >Assignee: Christophe Lombart >Priority: Blocker > Attachments: spring-mvn2.patch, spring.patch > > > The spring package and tests reference the old graffitto package naming > scheme. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (JCR-1043) Package names for spring project do not match update ocm packages
[ https://issues.apache.org/jira/browse/JCR-1043?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12542874 ] Padraic Hannon commented on JCR-1043: - I was about to make a jira ticket for that as well, I already started moving to maven 2 and will make sure yo upgrade to the newest spring. Pih -- Not sent from my iPhone > Package names for spring project do not match update ocm packages > - > > Key: JCR-1043 > URL: https://issues.apache.org/jira/browse/JCR-1043 > Project: Jackrabbit > Issue Type: Bug > Components: jcr-mapping >Affects Versions: 1.3 > Environment: All environments >Reporter: Padraic Hannon >Assignee: Christophe Lombart >Priority: Blocker > Attachments: spring.patch > > > The spring package and tests reference the old graffitto package naming > scheme. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (JCR-1067) Referenced beans in an object graph should be persisted by the ocm automatically
[ https://issues.apache.org/jira/browse/JCR-1067?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12542817 ] Padraic Hannon commented on JCR-1067: - Should I create new converters? We are starting to more actively use OCM and we feel this is an important feature to have. > Referenced beans in an object graph should be persisted by the ocm > automatically > > > Key: JCR-1067 > URL: https://issues.apache.org/jira/browse/JCR-1067 > Project: Jackrabbit > Issue Type: Improvement > Components: jcr-mapping >Affects Versions: 1.3.1 >Reporter: Padraic Hannon > Attachments: BeanReferenceCollectionConverterImpl.diff, > ReferenceBeanConverterImpl.diff > > > Currently the BeanReferenceCollectionConverter and ReferenceBeanConverter > classes only persist the UUID of the referenced object. There should either > be new converter classes that cascade down the object graph to ensure all > referenced items are created or updated, or the existing ones should be > updated to cascade. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (JCR-1043) Package names for spring project do not match update ocm packages
[ https://issues.apache.org/jira/browse/JCR-1043?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Padraic Hannon updated JCR-1043: Attachment: spring.patch Here is a patch based on the latest version of the ocm-mapping project. > Package names for spring project do not match update ocm packages > - > > Key: JCR-1043 > URL: https://issues.apache.org/jira/browse/JCR-1043 > Project: Jackrabbit > Issue Type: Bug > Components: jcr-mapping >Affects Versions: 1.3 > Environment: All environments >Reporter: Padraic Hannon >Assignee: Christophe Lombart >Priority: Blocker > Attachments: spring.patch > > > The spring package and tests reference the old graffitto package naming > scheme. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (JCR-1043) Package names for spring project do not match update ocm packages
[ https://issues.apache.org/jira/browse/JCR-1043?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Padraic Hannon updated JCR-1043: Attachment: (was: spring.tar.gz) > Package names for spring project do not match update ocm packages > - > > Key: JCR-1043 > URL: https://issues.apache.org/jira/browse/JCR-1043 > Project: Jackrabbit > Issue Type: Bug > Components: jcr-mapping >Affects Versions: 1.3 > Environment: All environments >Reporter: Padraic Hannon >Assignee: Christophe Lombart >Priority: Blocker > Attachments: spring.patch > > > The spring package and tests reference the old graffitto package naming > scheme. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (JCR-1050) Remove synchronization from JNDI data sources
[ https://issues.apache.org/jira/browse/JCR-1050?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Padraic Hannon resolved JCR-1050. - Resolution: Invalid > Remove synchronization from JNDI data sources > - > > Key: JCR-1050 > URL: https://issues.apache.org/jira/browse/JCR-1050 > Project: Jackrabbit > Issue Type: Improvement > Components: jackrabbit-core >Reporter: Padraic Hannon > Attachments: DerbyPooledPersistenceManager.java, JCR-1050.patch > > > Using datasources one should be able to rely on the application server to > manage PreparedStatement caches therefore pre-creating and holding onto the > connection for long periods of time should not be needed. This relates to > improvement JCR-313, however, that change did not address the benefits one > could see in using an application server controlled datasource. Even if > jackrabbit does aim to use an embedded database such a system could be > configured to use datasources and could benefit from the removal of the > synchronization. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (JCR-1050) Remove synchronization from JNDI data sources
[ https://issues.apache.org/jira/browse/JCR-1050?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12539212 ] Padraic Hannon commented on JCR-1050: - Based on benchmarks using the DerbyPooledManager (the oracle ones where terrible! I have no idea what I was thinking) I am going to close this issue as I do not think that the problem of synchronization can be handled at this level. Using the ConcurrentReadWrite test I had almost the same number of operations with both the synchronized derbymanager and this pooled one. > Remove synchronization from JNDI data sources > - > > Key: JCR-1050 > URL: https://issues.apache.org/jira/browse/JCR-1050 > Project: Jackrabbit > Issue Type: Improvement > Components: jackrabbit-core >Reporter: Padraic Hannon > Attachments: DerbyPooledPersistenceManager.java, JCR-1050.patch > > > Using datasources one should be able to rely on the application server to > manage PreparedStatement caches therefore pre-creating and holding onto the > connection for long periods of time should not be needed. This relates to > improvement JCR-313, however, that change did not address the benefits one > could see in using an application server controlled datasource. Even if > jackrabbit does aim to use an embedded database such a system could be > configured to use datasources and could benefit from the removal of the > synchronization. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (JCR-1050) Remove synchronization from JNDI data sources
[ https://issues.apache.org/jira/browse/JCR-1050?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Padraic Hannon updated JCR-1050: Attachment: (was: JNDI_Datasource_Changes.diff) > Remove synchronization from JNDI data sources > - > > Key: JCR-1050 > URL: https://issues.apache.org/jira/browse/JCR-1050 > Project: Jackrabbit > Issue Type: Improvement > Components: jackrabbit-core >Reporter: Padraic Hannon > Attachments: DerbyPooledPersistenceManager.java, JCR-1050.patch > > > Using datasources one should be able to rely on the application server to > manage PreparedStatement caches therefore pre-creating and holding onto the > connection for long periods of time should not be needed. This relates to > improvement JCR-313, however, that change did not address the benefits one > could see in using an application server controlled datasource. Even if > jackrabbit does aim to use an embedded database such a system could be > configured to use datasources and could benefit from the removal of the > synchronization. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (JCR-1050) Remove synchronization from JNDI data sources
[ https://issues.apache.org/jira/browse/JCR-1050?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Padraic Hannon updated JCR-1050: Attachment: (was: OracleDatasourcePersistenceManager.java) > Remove synchronization from JNDI data sources > - > > Key: JCR-1050 > URL: https://issues.apache.org/jira/browse/JCR-1050 > Project: Jackrabbit > Issue Type: Improvement > Components: jackrabbit-core >Reporter: Padraic Hannon > Attachments: DerbyPooledPersistenceManager.java, JCR-1050.patch > > > Using datasources one should be able to rely on the application server to > manage PreparedStatement caches therefore pre-creating and holding onto the > connection for long periods of time should not be needed. This relates to > improvement JCR-313, however, that change did not address the benefits one > could see in using an application server controlled datasource. Even if > jackrabbit does aim to use an embedded database such a system could be > configured to use datasources and could benefit from the removal of the > synchronization. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (JCR-1050) Remove synchronization from JNDI data sources
[ https://issues.apache.org/jira/browse/JCR-1050?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Padraic Hannon updated JCR-1050: Attachment: (was: DatasourcePersistenceManager.java) > Remove synchronization from JNDI data sources > - > > Key: JCR-1050 > URL: https://issues.apache.org/jira/browse/JCR-1050 > Project: Jackrabbit > Issue Type: Improvement > Components: jackrabbit-core >Reporter: Padraic Hannon > Attachments: DerbyPooledPersistenceManager.java, JCR-1050.patch > > > Using datasources one should be able to rely on the application server to > manage PreparedStatement caches therefore pre-creating and holding onto the > connection for long periods of time should not be needed. This relates to > improvement JCR-313, however, that change did not address the benefits one > could see in using an application server controlled datasource. Even if > jackrabbit does aim to use an embedded database such a system could be > configured to use datasources and could benefit from the removal of the > synchronization. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (JCR-1050) Remove synchronization from JNDI data sources
[ https://issues.apache.org/jira/browse/JCR-1050?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12538581 ] Padraic Hannon commented on JCR-1050: - I'll spend to work on this this week, I've done some testing, however, I am starting to think the problem is larger than just here, as I get the same performance with or without synchronization. I am thinking I should just close this until we can refactor jackrabbit with the SPI project which should give us more separation of concerns. > Remove synchronization from JNDI data sources > - > > Key: JCR-1050 > URL: https://issues.apache.org/jira/browse/JCR-1050 > Project: Jackrabbit > Issue Type: Improvement > Components: jackrabbit-core >Reporter: Padraic Hannon > Attachments: DatasourcePersistenceManager.java, > DerbyPooledPersistenceManager.java, JCR-1050.patch, > JNDI_Datasource_Changes.diff, OracleDatasourcePersistenceManager.java > > > Using datasources one should be able to rely on the application server to > manage PreparedStatement caches therefore pre-creating and holding onto the > connection for long periods of time should not be needed. This relates to > improvement JCR-313, however, that change did not address the benefits one > could see in using an application server controlled datasource. Even if > jackrabbit does aim to use an embedded database such a system could be > configured to use datasources and could benefit from the removal of the > synchronization. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (JCR-1050) Remove synchronization from JNDI data sources
[ https://issues.apache.org/jira/browse/JCR-1050?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Padraic Hannon updated JCR-1050: Attachment: DerbyPooledPersistenceManager.java Here is a persistence manager which uses embedded derby pools. The storage tests all passed, however, the times were about the same as the synchronized one. > Remove synchronization from JNDI data sources > - > > Key: JCR-1050 > URL: https://issues.apache.org/jira/browse/JCR-1050 > Project: Jackrabbit > Issue Type: Improvement > Components: core >Reporter: Padraic Hannon > Attachments: DatasourcePersistenceManager.java, > DerbyPooledPersistenceManager.java, JNDI_Datasource_Changes.diff, > OracleDatasourcePersistenceManager.java > > > Using datasources one should be able to rely on the application server to > manage PreparedStatement caches therefore pre-creating and holding onto the > connection for long periods of time should not be needed. This relates to > improvement JCR-313, however, that change did not address the benefits one > could see in using an application server controlled datasource. Even if > jackrabbit does aim to use an embedded database such a system could be > configured to use datasources and could benefit from the removal of the > synchronization. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (JCR-890) concurrent read-only access to a session
[ https://issues.apache.org/jira/browse/JCR-890?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12524166 ] Padraic Hannon commented on JCR-890: I think this is similar to the discussion from JCR-1050. Perhaps we need a larger effort to look at synchronization within the lower levels of Jackrabbit? > concurrent read-only access to a session > > > Key: JCR-890 > URL: https://issues.apache.org/jira/browse/JCR-890 > Project: Jackrabbit > Issue Type: Improvement > Components: core >Reporter: David Nuescheler >Assignee: Stefan Guggisberg > > Even though the JCR specification does not make a statement about Sessions > shared across a number of threads I think it would be great for many > applications if we could state that sharing a read-only session is supported > by Jackrabbit. > On many occasions in the mailing lists we stated that there should not be an > issue with sharing a read-only session, however I think it has never been > thoroughly tested or even specified as a "design goal". > If we can come to an agreement that this is desirable I think it would be > great to start including testcases to validate that behaviour and update the > documentation respectively. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (JCR-1050) Remove synchronization from JNDI data sources
[ https://issues.apache.org/jira/browse/JCR-1050?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12524165 ] Padraic Hannon commented on JCR-1050: - I've actually been focusing on creating a CRX based version more than Jackrabbit and have been testing that. I will try get this back into jackrabbit asap. I think this relates to JCR-890 as well. > Remove synchronization from JNDI data sources > - > > Key: JCR-1050 > URL: https://issues.apache.org/jira/browse/JCR-1050 > Project: Jackrabbit > Issue Type: Improvement > Components: core >Reporter: Padraic Hannon > Attachments: DatasourcePersistenceManager.java, > JNDI_Datasource_Changes.diff, OracleDatasourcePersistenceManager.java > > > Using datasources one should be able to rely on the application server to > manage PreparedStatement caches therefore pre-creating and holding onto the > connection for long periods of time should not be needed. This relates to > improvement JCR-313, however, that change did not address the benefits one > could see in using an application server controlled datasource. Even if > jackrabbit does aim to use an embedded database such a system could be > configured to use datasources and could benefit from the removal of the > synchronization. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (JCR-1100) Support for dynamic mixins
[ https://issues.apache.org/jira/browse/JCR-1100?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12524159 ] Padraic Hannon commented on JCR-1100: - I've attached the code as I have it so far. Also included is a simple test case which builds a node, inserts it, adds a mixin stores the updated node and finally retrieves it. > Support for dynamic mixins > -- > > Key: JCR-1100 > URL: https://issues.apache.org/jira/browse/JCR-1100 > Project: Jackrabbit > Issue Type: New Feature > Components: jcr-mapping >Affects Versions: 1.3.1 >Reporter: Padraic Hannon > Attachments: dynamicMixin.diff > > > JCR allows one to add mixins to nodes dynamically. However, within the ocm > code one cannot readily add mixins dynamically to objects. This feature would > allow jcr nodes to be updated with a mixin and ocm to read that node and > ensure an object is created correctly. Additionally for a passed in object > upon storage the ocm would inspect it and ensure all mixed in object fields > are added to the class descriptor. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (JCR-1100) Support for dynamic mixins
[ https://issues.apache.org/jira/browse/JCR-1100?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Padraic Hannon updated JCR-1100: Attachment: dynamicMixin.diff > Support for dynamic mixins > -- > > Key: JCR-1100 > URL: https://issues.apache.org/jira/browse/JCR-1100 > Project: Jackrabbit > Issue Type: New Feature > Components: jcr-mapping >Affects Versions: 1.3.1 >Reporter: Padraic Hannon > Attachments: dynamicMixin.diff > > > JCR allows one to add mixins to nodes dynamically. However, within the ocm > code one cannot readily add mixins dynamically to objects. This feature would > allow jcr nodes to be updated with a mixin and ocm to read that node and > ensure an object is created correctly. Additionally for a passed in object > upon storage the ocm would inspect it and ensure all mixed in object fields > are added to the class descriptor. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (JCR-1100) Support for dynamic mixins
[ https://issues.apache.org/jira/browse/JCR-1100?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12524136 ] Padraic Hannon commented on JCR-1100: - 1) I was thinking the same, but then I thought it might be nice for someone to be able to cast the mixin proxy to an interface for easy coding. Perhaps the mixin proxy is not the best way to go? 2) Working on cleaning up the code to upload some diffs. My original testing got a bit hacky so I want to clean it up before I share it. > Support for dynamic mixins > -- > > Key: JCR-1100 > URL: https://issues.apache.org/jira/browse/JCR-1100 > Project: Jackrabbit > Issue Type: New Feature > Components: jcr-mapping >Affects Versions: 1.3.1 >Reporter: Padraic Hannon > > JCR allows one to add mixins to nodes dynamically. However, within the ocm > code one cannot readily add mixins dynamically to objects. This feature would > allow jcr nodes to be updated with a mixin and ocm to read that node and > ensure an object is created correctly. Additionally for a passed in object > upon storage the ocm would inspect it and ensure all mixed in object fields > are added to the class descriptor. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (JCR-1100) Support for dynamic mixins
Support for dynamic mixins -- Key: JCR-1100 URL: https://issues.apache.org/jira/browse/JCR-1100 Project: Jackrabbit Issue Type: New Feature Components: jcr-mapping Affects Versions: 1.3.1 Reporter: Padraic Hannon JCR allows one to add mixins to nodes dynamically. However, within the ocm code one cannot readily add mixins dynamically to objects. This feature would allow jcr nodes to be updated with a mixin and ocm to read that node and ensure an object is created correctly. Additionally for a passed in object upon storage the ocm would inspect it and ensure all mixed in object fields are added to the class descriptor. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (JCR-1100) Support for dynamic mixins
[ https://issues.apache.org/jira/browse/JCR-1100?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12523960 ] Padraic Hannon commented on JCR-1100: - I currently have this working for persistence using cglib. However, it requires moving away from pojo's and requires having interfaces defined to create the proxy dynamically. I can upload diffs with the code, however, I think the solution would be to not have to resort to creating interfaces for everything. > Support for dynamic mixins > -- > > Key: JCR-1100 > URL: https://issues.apache.org/jira/browse/JCR-1100 > Project: Jackrabbit > Issue Type: New Feature > Components: jcr-mapping >Affects Versions: 1.3.1 >Reporter: Padraic Hannon > > JCR allows one to add mixins to nodes dynamically. However, within the ocm > code one cannot readily add mixins dynamically to objects. This feature would > allow jcr nodes to be updated with a mixin and ocm to read that node and > ensure an object is created correctly. Additionally for a passed in object > upon storage the ocm would inspect it and ensure all mixed in object fields > are added to the class descriptor. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (JCR-1050) Remove synchronization from JNDI data sources
[ https://issues.apache.org/jira/browse/JCR-1050?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Padraic Hannon updated JCR-1050: Attachment: OracleDatasourcePersistenceManager.java > Remove synchronization from JNDI data sources > - > > Key: JCR-1050 > URL: https://issues.apache.org/jira/browse/JCR-1050 > Project: Jackrabbit > Issue Type: Improvement > Components: core >Reporter: Padraic Hannon > Attachments: DatasourcePersistenceManager.java, > JNDI_Datasource_Changes.diff, OracleDatasourcePersistenceManager.java > > > Using datasources one should be able to rely on the application server to > manage PreparedStatement caches therefore pre-creating and holding onto the > connection for long periods of time should not be needed. This relates to > improvement JCR-313, however, that change did not address the benefits one > could see in using an application server controlled datasource. Even if > jackrabbit does aim to use an embedded database such a system could be > configured to use datasources and could benefit from the removal of the > synchronization. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (JCR-1050) Remove synchronization from JNDI data sources
[ https://issues.apache.org/jira/browse/JCR-1050?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Padraic Hannon updated JCR-1050: Attachment: DatasourcePersistenceManager.java This still needs testing and is just for example purposes > Remove synchronization from JNDI data sources > - > > Key: JCR-1050 > URL: https://issues.apache.org/jira/browse/JCR-1050 > Project: Jackrabbit > Issue Type: Improvement > Components: core >Reporter: Padraic Hannon > Attachments: DatasourcePersistenceManager.java, > JNDI_Datasource_Changes.diff > > > Using datasources one should be able to rely on the application server to > manage PreparedStatement caches therefore pre-creating and holding onto the > connection for long periods of time should not be needed. This relates to > improvement JCR-313, however, that change did not address the benefits one > could see in using an application server controlled datasource. Even if > jackrabbit does aim to use an embedded database such a system could be > configured to use datasources and could benefit from the removal of the > synchronization. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (JCR-1067) Referenced beans in an object graph should be persisted by the ocm automatically
[ https://issues.apache.org/jira/browse/JCR-1067?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Padraic Hannon updated JCR-1067: Comment: was deleted > Referenced beans in an object graph should be persisted by the ocm > automatically > > > Key: JCR-1067 > URL: https://issues.apache.org/jira/browse/JCR-1067 > Project: Jackrabbit > Issue Type: Improvement > Components: jcr-mapping >Affects Versions: 1.3.1 >Reporter: Padraic Hannon > Attachments: BeanReferenceCollectionConverterImpl.diff, > ReferenceBeanConverterImpl.diff > > > Currently the BeanReferenceCollectionConverter and ReferenceBeanConverter > classes only persist the UUID of the referenced object. There should either > be new converter classes that cascade down the object graph to ensure all > referenced items are created or updated, or the existing ones should be > updated to cascade. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (JCR-1067) Referenced beans in an object graph should be persisted by the ocm automatically
[ https://issues.apache.org/jira/browse/JCR-1067?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12520314 ] Padraic Hannon commented on JCR-1067: - I have attached to sample diffs. > Referenced beans in an object graph should be persisted by the ocm > automatically > > > Key: JCR-1067 > URL: https://issues.apache.org/jira/browse/JCR-1067 > Project: Jackrabbit > Issue Type: Improvement > Components: jcr-mapping >Affects Versions: 1.3.1 >Reporter: Padraic Hannon > Attachments: BeanReferenceCollectionConverterImpl.diff, > ReferenceBeanConverterImpl.diff > > > Currently the BeanReferenceCollectionConverter and ReferenceBeanConverter > classes only persist the UUID of the referenced object. There should either > be new converter classes that cascade down the object graph to ensure all > referenced items are created or updated, or the existing ones should be > updated to cascade. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (JCR-1067) Referenced beans in an object graph should be persisted by the ocm automatically
[ https://issues.apache.org/jira/browse/JCR-1067?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Padraic Hannon updated JCR-1067: Comment: was deleted > Referenced beans in an object graph should be persisted by the ocm > automatically > > > Key: JCR-1067 > URL: https://issues.apache.org/jira/browse/JCR-1067 > Project: Jackrabbit > Issue Type: Improvement > Components: jcr-mapping >Affects Versions: 1.3.1 >Reporter: Padraic Hannon > Attachments: BeanReferenceCollectionConverterImpl.diff, > ReferenceBeanConverterImpl.diff > > > Currently the BeanReferenceCollectionConverter and ReferenceBeanConverter > classes only persist the UUID of the referenced object. There should either > be new converter classes that cascade down the object graph to ensure all > referenced items are created or updated, or the existing ones should be > updated to cascade. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (JCR-1067) Referenced beans in an object graph should be persisted by the ocm automatically
[ https://issues.apache.org/jira/browse/JCR-1067?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Padraic Hannon updated JCR-1067: Attachment: BeanReferenceCollectionConverterImpl.diff Here is an example for BeanReferenceCollection > Referenced beans in an object graph should be persisted by the ocm > automatically > > > Key: JCR-1067 > URL: https://issues.apache.org/jira/browse/JCR-1067 > Project: Jackrabbit > Issue Type: Improvement > Components: jcr-mapping >Affects Versions: 1.3.1 >Reporter: Padraic Hannon > Attachments: BeanReferenceCollectionConverterImpl.diff, > ReferenceBeanConverterImpl.diff > > > Currently the BeanReferenceCollectionConverter and ReferenceBeanConverter > classes only persist the UUID of the referenced object. There should either > be new converter classes that cascade down the object graph to ensure all > referenced items are created or updated, or the existing ones should be > updated to cascade. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (JCR-1067) Referenced beans in an object graph should be persisted by the ocm automatically
[ https://issues.apache.org/jira/browse/JCR-1067?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Padraic Hannon updated JCR-1067: Attachment: (was: BeanReferenceCollectionConverterImpl.diff) > Referenced beans in an object graph should be persisted by the ocm > automatically > > > Key: JCR-1067 > URL: https://issues.apache.org/jira/browse/JCR-1067 > Project: Jackrabbit > Issue Type: Improvement > Components: jcr-mapping >Affects Versions: 1.3.1 >Reporter: Padraic Hannon > Attachments: BeanReferenceCollectionConverterImpl.diff, > ReferenceBeanConverterImpl.diff > > > Currently the BeanReferenceCollectionConverter and ReferenceBeanConverter > classes only persist the UUID of the referenced object. There should either > be new converter classes that cascade down the object graph to ensure all > referenced items are created or updated, or the existing ones should be > updated to cascade. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (JCR-1067) Referenced beans in an object graph should be persisted by the ocm automatically
[ https://issues.apache.org/jira/browse/JCR-1067?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Padraic Hannon updated JCR-1067: Attachment: ReferenceBeanConverterImpl.diff Here is an example for ReferenceBeanConverter > Referenced beans in an object graph should be persisted by the ocm > automatically > > > Key: JCR-1067 > URL: https://issues.apache.org/jira/browse/JCR-1067 > Project: Jackrabbit > Issue Type: Improvement > Components: jcr-mapping >Affects Versions: 1.3.1 >Reporter: Padraic Hannon > Attachments: BeanReferenceCollectionConverterImpl.diff, > ReferenceBeanConverterImpl.diff > > > Currently the BeanReferenceCollectionConverter and ReferenceBeanConverter > classes only persist the UUID of the referenced object. There should either > be new converter classes that cascade down the object graph to ensure all > referenced items are created or updated, or the existing ones should be > updated to cascade. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (JCR-1067) Referenced beans in an object graph should be persisted by the ocm automatically
[ https://issues.apache.org/jira/browse/JCR-1067?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Padraic Hannon updated JCR-1067: Comment: was deleted > Referenced beans in an object graph should be persisted by the ocm > automatically > > > Key: JCR-1067 > URL: https://issues.apache.org/jira/browse/JCR-1067 > Project: Jackrabbit > Issue Type: Improvement > Components: jcr-mapping >Affects Versions: 1.3.1 >Reporter: Padraic Hannon > Attachments: BeanReferenceCollectionConverterImpl.diff, > ReferenceBeanConverterImpl.diff > > > Currently the BeanReferenceCollectionConverter and ReferenceBeanConverter > classes only persist the UUID of the referenced object. There should either > be new converter classes that cascade down the object graph to ensure all > referenced items are created or updated, or the existing ones should be > updated to cascade. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (JCR-1067) Referenced beans in an object graph should be persisted by the ocm automatically
[ https://issues.apache.org/jira/browse/JCR-1067?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Padraic Hannon updated JCR-1067: Attachment: BeanReferenceCollectionConverterImpl.diff Here is an example implementation for BeanReferenceConverter > Referenced beans in an object graph should be persisted by the ocm > automatically > > > Key: JCR-1067 > URL: https://issues.apache.org/jira/browse/JCR-1067 > Project: Jackrabbit > Issue Type: Improvement > Components: jcr-mapping >Affects Versions: 1.3.1 >Reporter: Padraic Hannon > Attachments: BeanReferenceCollectionConverterImpl.diff > > > Currently the BeanReferenceCollectionConverter and ReferenceBeanConverter > classes only persist the UUID of the referenced object. There should either > be new converter classes that cascade down the object graph to ensure all > referenced items are created or updated, or the existing ones should be > updated to cascade. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (JCR-1067) Referenced beans in an object graph should be persisted by the ocm automatically
Referenced beans in an object graph should be persisted by the ocm automatically Key: JCR-1067 URL: https://issues.apache.org/jira/browse/JCR-1067 Project: Jackrabbit Issue Type: Improvement Components: jcr-mapping Affects Versions: 1.3.1 Reporter: Padraic Hannon Attachments: BeanReferenceCollectionConverterImpl.diff Currently the BeanReferenceCollectionConverter and ReferenceBeanConverter classes only persist the UUID of the referenced object. There should either be new converter classes that cascade down the object graph to ensure all referenced items are created or updated, or the existing ones should be updated to cascade. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (JCR-1050) Remove synchronization from JNDI data sources
[ https://issues.apache.org/jira/browse/JCR-1050?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12520309 ] Padraic Hannon commented on JCR-1050: - That makes sense, I was trying to eliminate duplication of code and ensure that there was a common code base. I will do a more coarse implementation first so we can get a better idea of what the changes are. -Paddy > Remove synchronization from JNDI data sources > - > > Key: JCR-1050 > URL: https://issues.apache.org/jira/browse/JCR-1050 > Project: Jackrabbit > Issue Type: Improvement > Components: core >Reporter: Padraic Hannon > Attachments: JNDI_Datasource_Changes.diff > > > Using datasources one should be able to rely on the application server to > manage PreparedStatement caches therefore pre-creating and holding onto the > connection for long periods of time should not be needed. This relates to > improvement JCR-313, however, that change did not address the benefits one > could see in using an application server controlled datasource. Even if > jackrabbit does aim to use an embedded database such a system could be > configured to use datasources and could benefit from the removal of the > synchronization. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (JCR-1050) Remove synchronization from JNDI data sources
[ https://issues.apache.org/jira/browse/JCR-1050?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12517999 ] Padraic Hannon commented on JCR-1050: - One note on the diff, I am sure there are defects, associated with these files. I am working through the tests now to ensure that I get them all. > Remove synchronization from JNDI data sources > - > > Key: JCR-1050 > URL: https://issues.apache.org/jira/browse/JCR-1050 > Project: Jackrabbit > Issue Type: Improvement > Components: core >Affects Versions: 0.9, 1.0, 1.0.1, 1.1, 1.1.1, 1.2.1, 1.2.2, 1.2.3, 1.3, > 1.3.1, 1.4, 2.0 >Reporter: Padraic Hannon > Attachments: JNDI_Datasource_Changes.diff > > > Using datasources one should be able to rely on the application server to > manage PreparedStatement caches therefore pre-creating and holding onto the > connection for long periods of time should not be needed. This relates to > improvement JCR-313, however, that change did not address the benefits one > could see in using an application server controlled datasource. Even if > jackrabbit does aim to use an embedded database such a system could be > configured to use datasources and could benefit from the removal of the > synchronization. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (JCR-1050) Remove synchronization from JNDI data sources
[ https://issues.apache.org/jira/browse/JCR-1050?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Padraic Hannon updated JCR-1050: Attachment: JNDI_Datasource_Changes.diff Diff file with non-synchronized JNDI datasources. > Remove synchronization from JNDI data sources > - > > Key: JCR-1050 > URL: https://issues.apache.org/jira/browse/JCR-1050 > Project: Jackrabbit > Issue Type: Improvement > Components: core >Affects Versions: 0.9, 1.0, 1.0.1, 1.1, 1.1.1, 1.2.1, 1.2.2, 1.2.3, 1.3, > 1.3.1, 1.4, 2.0 >Reporter: Padraic Hannon > Attachments: JNDI_Datasource_Changes.diff > > > Using datasources one should be able to rely on the application server to > manage PreparedStatement caches therefore pre-creating and holding onto the > connection for long periods of time should not be needed. This relates to > improvement JCR-313, however, that change did not address the benefits one > could see in using an application server controlled datasource. Even if > jackrabbit does aim to use an embedded database such a system could be > configured to use datasources and could benefit from the removal of the > synchronization. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (JCR-1050) Remove synchronization from JNDI data sources
[ https://issues.apache.org/jira/browse/JCR-1050?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12517311 ] Padraic Hannon commented on JCR-1050: - Yeah I saw that in the code. However, from what I can tell the only place where the connection autocommit is explicitly turned off and rollback() and commit() are called is in the method store(ChangeLog). Assuming that one is running in a container and has access to a datasource I would also assume that one has access to a UserTransaction object. If that is the case, rather than using a connection's transaction handling one can delegate the transaction handling to jta. > Remove synchronization from JNDI data sources > - > > Key: JCR-1050 > URL: https://issues.apache.org/jira/browse/JCR-1050 > Project: Jackrabbit > Issue Type: Improvement > Components: core >Affects Versions: 0.9, 1.0, 1.0.1, 1.1, 1.1.1, 1.2.1, 1.2.2, 1.2.3, 1.3, > 1.3.1, 1.4, 2.0 >Reporter: Padraic Hannon > > Using datasources one should be able to rely on the application server to > manage PreparedStatement caches therefore pre-creating and holding onto the > connection for long periods of time should not be needed. This relates to > improvement JCR-313, however, that change did not address the benefits one > could see in using an application server controlled datasource. Even if > jackrabbit does aim to use an embedded database such a system could be > configured to use datasources and could benefit from the removal of the > synchronization. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (JCR-1050) Remove synchronization from JNDI data sources
Remove synchronization from JNDI data sources - Key: JCR-1050 URL: https://issues.apache.org/jira/browse/JCR-1050 Project: Jackrabbit Issue Type: Improvement Components: core Affects Versions: 1.3, 1.2.3, 1.2.2, 1.2.1, 1.1.1, 1.1, 1.0.1, 1.0, 0.9, 1.3.1, 1.4, 2.0 Reporter: Padraic Hannon Using datasources one should be able to rely on the application server to manage PreparedStatement caches therefore pre-creating and holding onto the connection for long periods of time should not be needed. This relates to improvement JCR-313, however, that change did not address the benefits one could see in using an application server controlled datasource. Even if jackrabbit does aim to use an embedded database such a system could be configured to use datasources and could benefit from the removal of the synchronization. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (JCR-1044) NTCollectionConverterImpl throws a null pointer exception on update
[ https://issues.apache.org/jira/browse/JCR-1044?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Padraic Hannon updated JCR-1044: Attachment: NTCollectionConverterImpl.diff This puts a null check around the code which is attempting to delete JCR nodes not present in the current objects collection. > NTCollectionConverterImpl throws a null pointer exception on update > --- > > Key: JCR-1044 > URL: https://issues.apache.org/jira/browse/JCR-1044 > Project: Jackrabbit > Issue Type: Bug > Components: jcr-mapping >Affects Versions: 1.3 > Environment: All >Reporter: Padraic Hannon > Attachments: NTCollectionConverterImpl.diff > > > When calling update on a node which has no child nodes stored (but which can > have child nodes) the code can generate a null pointer exception. In the case > where one goes to remove JCR nodes which are not present in the current > objects collection of child objects the code is calling > getCollectionNodes().iterator(). However, since is not checking for the case > where getCollectionNodes() returns null if there are no child nodes present a > null pointer exception will be generated. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (JCR-1044) NTCollectionConverterImpl throws a null pointer exception on update
NTCollectionConverterImpl throws a null pointer exception on update --- Key: JCR-1044 URL: https://issues.apache.org/jira/browse/JCR-1044 Project: Jackrabbit Issue Type: Bug Components: jcr-mapping Affects Versions: 1.3 Environment: All Reporter: Padraic Hannon When calling update on a node which has no child nodes stored (but which can have child nodes) the code can generate a null pointer exception. In the case where one goes to remove JCR nodes which are not present in the current objects collection of child objects the code is calling getCollectionNodes().iterator(). However, since is not checking for the case where getCollectionNodes() returns null if there are no child nodes present a null pointer exception will be generated. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (JCR-1043) Package names for spring project do not match update ocm packages
[ https://issues.apache.org/jira/browse/JCR-1043?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Padraic Hannon updated JCR-1043: Attachment: spring.tar.gz Here is a directory structure with refactored files that will work. I tried to do a svn diff, but with the directory changes it was fairly unhappy. Not being a subversion expert a tar ball was easier. > Package names for spring project do not match update ocm packages > - > > Key: JCR-1043 > URL: https://issues.apache.org/jira/browse/JCR-1043 > Project: Jackrabbit > Issue Type: Bug > Components: jcr-mapping >Affects Versions: 1.3 > Environment: All environments >Reporter: Padraic Hannon >Priority: Blocker > Attachments: spring.tar.gz > > > The spring package and tests reference the old graffitto package naming > scheme. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (JCR-1043) Package names for spring project do not match update ocm packages
Package names for spring project do not match update ocm packages - Key: JCR-1043 URL: https://issues.apache.org/jira/browse/JCR-1043 Project: Jackrabbit Issue Type: Bug Components: jcr-mapping Affects Versions: 1.3 Environment: All environments Reporter: Padraic Hannon Priority: Blocker The spring package and tests reference the old graffitto package naming scheme. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
