[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.
[OCM] Second Level Cache Update
I've been working for a while on implementing a second level cache system
for OCM. I have gone down several routes and finally have one I think works
well. At the moment I am debugging some threading issues (solved via
synchronization, but I'd like to make it safe without doing so if possible)
that cause one of my simple tests to fail. I do have some test that I've
been running with interesting results.
Both versions of the test use OCM to load the same node using an attribute
ie a simple xpath query and convert the node to an object with all bean and
collection references lazy loaded. The lazy loaded beans and collections are
not read during the test. The test starts with two concurrent threads and
grows to 128 threads. There is a single main thread that does 256 get
attempts on the object. Each of the other threads executes as often as
possible (with a 10 ms sleep in between executions) until the primary thread
is finished.
The OCM query code is:
protected Object forId(Class classToFind, Long id) {
org.apache.jackrabbit.ocm.query.QueryManager queryManager =
getJcrMappingTemplate().createQueryManager();
org.apache.jackrabbit.ocm.query.Filter filter =
queryManager.createFilter(classToFind);
filter.addEqualTo("id", id);
Query query = queryManager.createQuery(filter);
return getObjectFromQuery(query);
}
protected Object getObjectFromQuery(Query query) {
Collection results = getJcrMappingTemplate().getObjects(query);
if (results != null && !results.isEmpty()) {
Iterator resIt = results.iterator();
return resIt.next();
}
return null;
}
For the non-cached plain OCM:
testConncurentForId: run [1] threads [2.0] time taken = 2339 ms
testConncurentForId: run [2] threads [4.0] time taken = 3597 ms
testConncurentForId: run [3] threads [8.0] time taken = 9189 ms
testConncurentForId: run [4] threads [16.0] time taken = 22105 ms
testConncurentForId: run [5] threads [32.0] time taken = 47406 ms
testConncurentForId: run [6] threads [64.0] time taken = 96337 ms
testConncurentForId: run [7] threads [128.0] time taken = 236061 ms
For a cached version using EhCache:
testConncurentForId: run [1] threads [2.0] time taken = 508 ms
testConncurentForId: run [2] threads [4.0] time taken = 616 ms
testConncurentForId: run [3] threads [8.0] time taken = 1024 ms
testConncurentForId: run [4] threads [16.0] time taken = 2508 ms
testConncurentForId: run [5] threads [32.0] time taken = 10738 ms
testConncurentForId: run [6] threads [64.0] time taken = 26644 ms
testConncurentForId: run [7] threads [128.0] time taken = 58736 ms
The speed increase is notable, however, my current implementation has a few
problems:
1) Cache flushing is extremely coarse grained (I'm doing a read mostly app
so I haven't focused on this much)
2) Flushing based on observation is currently a bit flaky and has some race
conditions I need to work out
3) The entire system is built around using the ocm-spring infrastructure
4) The cache is assumed to be tied to a specific JcrMappingTemplate instance
and so does not enforce any security constraints on reads.
I am going to spend time over the next week cleaning up 1 and 2 above.
However, for simplicity using the ocm spring infrastructure has been a great
help. I basically created a new JcrMappingTemplate called
CachedJcrMappingTemplate. This handles creating a cached version of the
objectcontentmanager and objectconverter which rely on SessionFactory and
the Jcr callback mechanisms to ensure that the lazy loaded objects can be
loaded even after their originating session is closed. The cache access is
entirely hidden within the CachedObjectContentManager and
CachedObjectConverter instances. All in all, things seem to be working and
the system is much simpler that my previous attempts. In addition, they can
be wholly contained within their own project and one can use spring to
switch in/out the JcrMappingTemplate.
-paddy
Re: Component releases, take 2
Jukka, I fully agree with your proposal. I've been getting developers here up and running with jackrabbit and find the break up difficult to explain. I like the fact the source tree is fairly well organized, however, creating multiple distributions adds complexity for the end developer. It sounds like you and Thomas are basically on the same page? aloha, Paddy
Re: [OCM] The ocm:discriminator
It seems that the discriminator is only needed for the case where you want to map multiple objects to a single node type. Perhaps we can force its use only for that condition? That would allow many use cases to exist without the need for registering special mixin types and without the need for forcing odd data into the repository. -paddy On Feb 7, 2008, at 8:23 AM, Christophe Lombart wrote: Anyway, forget my solution it is not working in all case (of course). it is time to go at home. On Feb 7, 2008 4:08 PM, Alex Lukin <[EMAIL PROTECTED]> wrote: I think that mixin node for ocm is right solution. You may just hide ocm:discriminator node type registration somewhere behind implementation to simplify OCM initialization. That means the ObjectContentManager can be used only with Jackrabbit because node type registration is not standard. Christophe
Re: [OCM] JPA support
Perhaps the first place to start would be to refactor the query
implementation to allow for more JDBC like semantics in terms of
setting query values. This would give us the ability to map to the jpa
query mechanism and allow us to have "named" queries.
For example:
SELECT * FROM my:type WHERE my:title= ?
We should be able to say setString(1, 'foo') or setString("my:title",
"foo"). The problem comes when you have multiple strings with the same
name, for example:
SELECT * FROM my:type WHERE jcr:path LIKE '/some/nodes/%' AND NOT
jcr:path LIKE '/some/nodes/%/%'
One could not call seString("jcr:path", ...) since there are two of
those in the where clause. In this case only numbers work. With JCR I
could see these sort of issues popping up all over the place. Any ideas?
On Feb 6, 2008, at 9:54 AM, Padraic Hannon wrote:
I've started to look into doing this and:
1) javax.persistence.Query doesn't really map well to either the OCM
query class nor to the OCM filter class I think that both classes
would have to be heavily refactored or replaced by an implementation
of the JPA Query class.
2) javax.persistence.EntityManager maps more cleanly, however, given
that one needs to have the ability to create queries using EJB QL we
would have to implement some sort of EJB QL parser to translate to
sql or xpath which would be a bit of a pain
I am sure there are more details I haven't dug up. If JPA is super
important we could start working on this as I think there are
advantages for making JCR usage more widespread (it would be nice
for people to be able to move existing apps to this new paradigm as
I think it has benefits in terms of simplifying object - data store
mapping).
-paddy
[OCM] JPA support
I've started to look into doing this and: 1) javax.persistence.Query doesn't really map well to either the OCM query class nor to the OCM filter class I think that both classes would have to be heavily refactored or replaced by an implementation of the JPA Query class. 2) javax.persistence.EntityManager maps more cleanly, however, given that one needs to have the ability to create queries using EJB QL we would have to implement some sort of EJB QL parser to translate to sql or xpath which would be a bit of a pain I am sure there are more details I haven't dug up. If JPA is super important we could start working on this as I think there are advantages for making JCR usage more widespread (it would be nice for people to be able to move existing apps to this new paradigm as I think it has benefits in terms of simplifying object - data store mapping). -paddy
Re: Content Object Mapping - jcrom.org
We've been using the OCM libraries with a certain amount of success. We have heavily leveraged using the spring modules for configuration and have used the repository pattern with a few base classes which handle most of the OCM specific implementations. Our domain model maps fairly cleanly into trees and nested structures, as I suspect many models would, and we have done some amount of data normalization. Adding JPA support to the OCM code would be a nice benefit for those that have existing models, I'll grab the api docs and some sample code and take a look at how big a change it would be. At first glance we would have to provide a few implementations, but I think we have most of the pieces they just need to be assembled. I have been working on the entity factory with a second level cache, but got pulled away due to "real" work stuff ;-) In general, I feel that having two ocm style projects for such a small group is detrimental, perhaps we could convince the jcrom folks to come over to apache? -paddy On Feb 5, 2008, at 11:38 AM, Jukka Zitting wrote: Hi, On Feb 5, 2008 8:53 PM, Christophe Lombart <[EMAIL PROTECTED] > wrote: Concerning JPA, we can make a small study to check if JPA is really a good solution for a JCR backend ... if someone have time :-) One very interesting use case for that would be to make Apache Roller run on top of Jackrabbit. Roller is using JPA for persistence, and AFAIK their content model doesn't contain anything that a hierarchical content repository couldn't support. BR, Jukka Zitting
Re: Cannot update node's property using JcrTemplate
I've been working on building up test cases around the ocm spring integration and have submitted a patch to upgrade the spring jcr implementation to jackrabbit 1.4. I'll investigate and ensure the test cases I'm working on cover all the basic CRUD operations. -paddy On Jan 30, 2008, at 4:08 AM, Christophe Lombart wrote: The OCM Spring support is still in progress. We are checking with the Spring modules team how both projects can be integrated (either in Jackrabbit or in Spring module). Christophe On Jan 30, 2008 4:19 AM, josephi <[EMAIL PROTECTED]> wrote: Greetings, I am using org.apache.jackrabbit.ocm.spring.JcrMappingTemplate to access the repository. I am able to create/read/delete the mapped object on to the repository, but I cannot update. There are no exception thrown or logged, the jcrMappingTemplate.save() seems to execute successfully, but when I view the repository, I do not see the updated value to the property. The same update operation works when I using JCR api directly, but nothing gets updated when I use the JcrMappingTemplate. Has anyone experienced this behavior? Any advice and suggestion is greatly appreciated. Thanks -- View this message in context: http://www.nabble.com/Cannot-update-node%27s-property-using-JcrTemplate-tp15174683p15174683.html Sent from the Jackrabbit - Dev mailing list archive at Nabble.com.
Re: [OCM] ObjectContentManager and Sessions
The more I dig into the Sling code the more I wonder if the pooled session implementation should be part of the core jackrabbit code. The pooled implementation would be extremely valuable to the OCM part of jackrabbit and would probably be great for others as well. See http://svn.apache.org/repos/asf/incubator/sling/trunk/jcr/api/src/main/java/org/apache/sling/jcr/api/internal/PooledSession.java -paddy On Jan 18, 2008, at 9:13 AM, Padraic Hannon wrote: Yeah I had been looking at that code, perhaps I'll work on moving those concepts into ocm so others can have it. I was going to do our vehicle domain model with sling but right now I think Edmunds isn't ready for that so I am just using straight ocm and spring :( Once that part is done I am going to adapt it to Sling as I think it is a much nicer model than the spring config version. Pih On Jan 18, 2008, at 4:42 AM, Felix Meschberger wrote: Hi Paddy, This is actually more or less, what we are doing in Sling: We are using shared mapping configuration and just creating the mapper (and other helper) objects when creating ObjectContentManager for a session [1]. In the context of an HTTP Request we then have one ObjectContentManager instance per request whereas the mapping configuration is shared by all ObjectContentManager instances. Session management is done in another factory and behind the scenes we in fact have session pooling. Hope this helps. Regards Felix [1] http://svn.apache.org/repos/asf/incubator/sling/trunk/jcr/resource/src/main/java/org/apache/sling/jcr/resource/internal/mapping/ObjectContentManagerFactory.java Am Mittwoch, den 16.01.2008, 09:47 -0800 schrieb Padraic Hannon: While working with the caches and with our own internal content mapping project I have noticed a slight disconnect between how OCM handles sessions and how jackrabbit seems to want to handle them. With the OCM one tends to have a long lived object content manager that is potentially used by multiple threads. This would mean that the session would be re-used across multiple reader and writer threads. See http://markmail.org/message/f5lbenhnmdc2vxhx for details on threading and sessions. I think this points to the need to have sessions opened and closed much like in the hibernate model. To accomplish this I think we should create a ObjectContentManagerFactory which can create the managers so that each thread can get its own copy. When creating a manager the factory could use a session factory much like the one that spring has for JCR (org.springmodules.jcr.JcrSessionFactory). This would allow sessions to be pooled or created as needed and then be passed to ObjectContentManagers. The factory could also preload the mapping classes and other configuration items (like say the cache implementation factory?). The threads could share a cache (if the implementation is EhCache or something intelligent) or the cache could just be a simple hashmap and the assumption would be that the managers are short lived and the cache is there to eliminate the infinite load issue. WDYT? -paddy
Re: [OCM] ObjectContentManager and Sessions
Yeah I had been looking at that code, perhaps I'll work on moving those concepts into ocm so others can have it. I was going to do our vehicle domain model with sling but right now I think Edmunds isn't ready for that so I am just using straight ocm and spring :( Once that part is done I am going to adapt it to Sling as I think it is a much nicer model than the spring config version. Pih On Jan 18, 2008, at 4:42 AM, Felix Meschberger wrote: Hi Paddy, This is actually more or less, what we are doing in Sling: We are using shared mapping configuration and just creating the mapper (and other helper) objects when creating ObjectContentManager for a session [1]. In the context of an HTTP Request we then have one ObjectContentManager instance per request whereas the mapping configuration is shared by all ObjectContentManager instances. Session management is done in another factory and behind the scenes we in fact have session pooling. Hope this helps. Regards Felix [1] http://svn.apache.org/repos/asf/incubator/sling/trunk/jcr/resource/src/main/java/org/apache/sling/jcr/resource/internal/mapping/ObjectContentManagerFactory.java Am Mittwoch, den 16.01.2008, 09:47 -0800 schrieb Padraic Hannon: While working with the caches and with our own internal content mapping project I have noticed a slight disconnect between how OCM handles sessions and how jackrabbit seems to want to handle them. With the OCM one tends to have a long lived object content manager that is potentially used by multiple threads. This would mean that the session would be re-used across multiple reader and writer threads. See http://markmail.org/message/f5lbenhnmdc2vxhx for details on threading and sessions. I think this points to the need to have sessions opened and closed much like in the hibernate model. To accomplish this I think we should create a ObjectContentManagerFactory which can create the managers so that each thread can get its own copy. When creating a manager the factory could use a session factory much like the one that spring has for JCR (org.springmodules.jcr.JcrSessionFactory). This would allow sessions to be pooled or created as needed and then be passed to ObjectContentManagers. The factory could also preload the mapping classes and other configuration items (like say the cache implementation factory?). The threads could share a cache (if the implementation is EhCache or something intelligent) or the cache could just be a simple hashmap and the assumption would be that the managers are short lived and the cache is there to eliminate the infinite load issue. WDYT? -paddy
Re: [OCM] ObjectContentManager and Sessions
Yeah I was thinking of adapting some of the sling stuff (which Felix pointed out in another email) for session management. Then there would be an object content manager factory which would rely on a session factory and a cache factory.A lot of this already exists in the ocm- spring project (Jackrabbit/JCRSessionFactory and JCRMappingTemplate essentially do this), however, it would be nice to have this in the default implementation. I think the object content manager factory would also be a good place to plug in a level 2 cache controller and factory? -paddy On Jan 16, 2008, at 11:54 AM, Christophe Lombart wrote: +1 On Jan 16, 2008 6:47 PM, Padraic Hannon <[EMAIL PROTECTED]> wrote: The factory could also preload the mapping classes and other configuration items (like say the cache implementation factory?). If I understand, there is 3 factories : one for the ObjectcontentManager one for the JCR session one for the Cache impl It is correct ? Christophe
[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.
[OCM] ObjectContentManager and Sessions
While working with the caches and with our own internal content mapping project I have noticed a slight disconnect between how OCM handles sessions and how jackrabbit seems to want to handle them. With the OCM one tends to have a long lived object content manager that is potentially used by multiple threads. This would mean that the session would be re-used across multiple reader and writer threads. See http://markmail.org/message/f5lbenhnmdc2vxhx for details on threading and sessions. I think this points to the need to have sessions opened and closed much like in the hibernate model. To accomplish this I think we should create a ObjectContentManagerFactory which can create the managers so that each thread can get its own copy. When creating a manager the factory could use a session factory much like the one that spring has for JCR (org.springmodules.jcr.JcrSessionFactory). This would allow sessions to be pooled or created as needed and then be passed to ObjectContentManagers. The factory could also preload the mapping classes and other configuration items (like say the cache implementation factory?). The threads could share a cache (if the implementation is EhCache or something intelligent) or the cache could just be a simple hashmap and the assumption would be that the managers are short lived and the cache is there to eliminate the infinite load issue. WDYT? -paddy
[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.
[OCM] ocm cache
There is a simple OCM cache which I would like to remove or at least make optional. Currently there is already a lot of caching going on within jackrabbit and the current cache implementation for OCM is extremely simplistic. For example, if a node changes under the OCM it has no knowledge of this and the cache is not flushed. Until there is robust support for observation and a more plug-able architecture the OCM cache seems like it is more dangerous than helpful. WDYT? paddy
ocm:discriminator
A while ago there was a conversation in which Christophe mentioned a desire to drop ocm:desciminator http://markmail.org/message/hg7qe4a442sl34ky?q=ocm:discriminator FYI, I would like to drop the ocm:discriminator. It is used when the same node type is applied on a complete java class hierarchy in order to find the appropriate descendant class when a new object has to be instantiated. It is tedious to support it just to solve this issue. Has anyone given this more thought? If no one objects I'll open a Jira ticket and work on a patch, I think we could just use the mapping file and node type. This would mean we would loose the ability to map multiple classes to a single node type/mixin set, but I am unsure if that is such a bad thing anyway. -paddy
Re: IoC configuration for Jackrabbit
+1 for me as well. I know that jackrabbit tends to stick to apache only libraries, however, if we could re-wire with Spring I think it would be pretty slick and since most people already use it extensively it wouldn't introduce a new technique for people to learn. I think it would also put us a long way forward in making jackrabbit a bit more modular. -paddy On Jan 14, 2008, at 1:23 AM, David Rauschenbach wrote: +1 for more IoC. We have a lot of code here that is factory wrappers for the proprietary Jackrabbit configuration, plus mock FileSystem implementations where a node type manager is used in a stand-alone fashion. It's all very pre-IoC looking. David -Original Message- From: Jukka Zitting [mailto:[EMAIL PROTECTED] Sent: Sunday, January 13, 2008 7:57 PM To: dev@jackrabbit.apache.org Subject: IoC configuration for Jackrabbit Hi, The current repository.xml configuration file and the related o.a.j.core.config code is quite monolithic and essentially fixes the structure of Jackrabbit internals. For example, almost all notable new features require that you either modify the configuration handling code (clustering, data store, ism locking) or just work around it (indexing). The configuration model also makes us duplicate lots of code. For example, instead of using a single database configuration and an associated class/object, we now need to duplicate database connection code in persistence managers, file systems, cluster journals, and data stores. It's a mess. To fix this, I'd like to make Jackrabbit configuration more IoC-like, eventually making it possible to use an existing IoC library/container to configure Jackrabbit. To make this happen, I'd start by dropping the type-specific SomeConfig classes from o.a.j.core.config and replacing the init(...) methods with setters and more explicit lifecycle management methods. WDYT? This'll probably require some relatively heavy-handed refactoring, changes to the repository.xml structure, and probably some backwards-compatibility code to handle Jackrabbit 1.4 and earlier configuration files, so I won't go forward unless we have a reasonable consensus that the benefits are worth the effort. BR, Jukka Zitting
NGP
Based on some of the questions regarding a jackrabbit roadmap, I was reading through some old threads around thread synchronization and locking, and it seems that a lot of the discussion around NGP has sort of died down. From Jukka's email it sounds like everyone is pushing NGP out for a long ways. I wonder if perhaps before adding too much more functionality (ie JCR 2.0) it may be better to start exploring implementing NGP sooner? -paddy
[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.
Re: synchronization issues
I think it may be best to take a long look at the various *ItemStateManager classes in a holistic manner. It appears that these classes introduce a lot of the locking and synchronization issues (as would be expected from such a key group of classes). The movement towards using more fine grained locking makes a lot of sense, but I think we still have a mix of locking and explicit method level synchronization. In addition, it seems that we do not really look at transaction isolation levels to determine locking strategies. In some instances dirty reads and writes may be acceptable and using configurable tx isolations levels could allow the end consumer to tweak the system for their application environment. I would love to see us move towards having the cache and persistence layers separated and management of the internal hidden from things such as shared item state manager. In my experience most if not all the issues we have seen in our production systems (in terms of where threads lock, and I have tons of thread dumps showing this under load) occur within SharedItemStateManager and ItemManager. As we see these issues pile up I think it behooves us to take a long hard look at these core classes and ensure that we are going down the right path. -paddy On Dec 18, 2007, at 2:23 AM, Marcel Reutegger wrote: hi all, there are a number of synchronization issues I would like to resolve for the 1.4 release. some of them are related to using the new FineGrainedISMLocking but most of them are general synchronization issues that may happen with both DefaultISMLocking and FineGrainedISMLocking, though more visible with the latter. JCR-1271 - this issue happens with both ISMLocking implementations. The cache in LocalItemStateManager is accessed at the same time by the thread using the session and by the thread that notifies ItemState changes. JCR-935 happens for the same reason. JCR-1272 - this issue happens with both ISMLocking implementations. instead of adding synchronization, I suggest to operate on possibly stale states. see patch. JCR-1274 - this is only an issue with the FineGrainedISMLocking. when using the DefaultISMLocking the exclusive write lock prevents any reading from the cache. this is different when using FineGrainedISMLocking. This locking strategy allows reading from the cache while a change is processed. Hence it may happen that reading from and writing to the cache happens concurrently. One solution may be to completely synchronize the ItemStateCache in SharedItemStateManager. This however reduces concurrency on the cache for reading threads. Another solution I can think of is to allow the ISMLocking implementation to wrap the ItemStateCache if necessary. DefaultISMLocking would simply return the cache as is, while FineGrainedISMLocking would have to wrap the cache into a synchronized variant. comments are welcome. regards marcel
Re: Using JSR-107 for jackrabbit caches?
Yeah that is what I was thinking about, this jsr is also known as JCache. Perhaps it is not as supported as I thought, but basically everything looks like a Map. My thought is that by using such an interface or by making the cache system pluggable is that we could swap out cache providers for different scenarios. One thing we are interested in looking at is using Coherence (http://www.tangosol.com/coherence-overview.jsp ) which is used by atlassian and others for to allow for scaling. This combined with a pluggable persistence model would allow for different cluster implementations. I would also be interested in looking at terracotta (http://www.terracotta.org/confluence/display/orgsite/Home) or swarmcache (http://swarmcache.sourceforge.net/). While there could be a lot of work to create a fully clusterable/grid-ed version of jackrabbit with pluggable cache and persistence managers we might be able to do this using existing projects. One cool thing is that a lot of these distributed caches support read-through and write-through (or even write-behind) semantics for caching which could create an extremely scalable solution for accessing content using jcr. -paddy On Dec 6, 2007, at 12:18 AM, Thomas Mueller wrote: Hi, Do you mean https://jsr-107-interest.dev.java.net/ ? I have never heard about this JSR, but it sounds interesting. Is it still active? I saw the last update was on 01/19/2005. It says "Draft Specification: coming soon!". Maybe it would be better to wait until the specification is available? This would enable us to use a more pluggable cache model. Could you explain the use case? Why do you need a more pluggable cache model? Regards, Thomas On Dec 5, 2007 8:39 PM, Padraic I. Hannon <[EMAIL PROTECTED]> wrote: Not sure if this has been brought up, however, has this group considered moving towards using the JSR-107 spec for the internal jackrabbit caching? This would enable us to use a more pluggable cache model. Thoughts? -paddy
[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.
Re: [OCM] Dynamic Mixin Support
On Nov 2, 2007, at 6:53 AM, Christophe Lombart wrote: On 11/1/07, Padraic Hannon <[EMAIL PROTECTED]> wrote: I have been reviewing the implementation I submitted for mixin support in JCR-1100 and am struggling with how to proceed. On the one hand I think the implementation that was submitted is nice since it has some amount of type safety and gives the developer the ability to cast objects. On the other hand, how is a developer to know what to cast the objects to? What do you mean ? For example, I don't see some problems when you search on java class that match to mixin type. That is true, however, for the application developer who may not have as much idea as to the underlying datastore perhaps there is a problem? At the same time this model is fairly different so it could be ok to expect the developer to have a certain amount of knowledge as to the underlying mechanism. I am starting to experiment with using the bean generator cglib code which will allow me to use regular javabeans. My idea is that the mapped node type would be used to instantiate the object and then for mixin properties I would create a new class dynamically which contains all the mixin's properties. ok. I expect "mapped node type" is the primary node type - right ? yes I would modify the object converter to first create the object with its nodes mapped properties then I would take each mixin for its node and grab the attributes for the mixin based on the mixin definition mapped in xml (not sure how to handle this in JDK 1.5 where the mappings are done with annotations) It is done in the same way. This is the same ObjectConverter impl used in both cases (annotation & xml). and add these attributes to a new class which is a subclass of the node's defined class. I don't understand why it is a sublcass of the node's defined class. For example if I have a primary node type of Cat and I load two objects: Tiger and Lilly I could apply a mixin of type Cougar to Lilly. When doing so I would need to create an object with a new dynamically generated class. I would not want to change the current Cat class since there are other objects using it that have not had the Cougar mixin applied. This new class would have properties defined for each property in the mixin. Has anyone else thought about how to handle this? No yet I'm sorry. I will to review your proposal max for monday. Christophe
[OCM] Dynamic Mixin Support
I have been reviewing the implementation I submitted for mixin support in JCR-1100 and am struggling with how to proceed. On the one hand I think the implementation that was submitted is nice since it has some amount of type safety and gives the developer the ability to cast objects. On the other hand, how is a developer to know what to cast the objects to? I am starting to experiment with using the bean generator cglib code which will allow me to use regular javabeans. My idea is that the mapped node type would be used to instantiate the object and then for mixin properties I would create a new class dynamically which contains all the mixin's properties. I would modify the object converter to first create the object with its nodes mapped properties then I would take each mixin for its node and grab the attributes for the mixin based on the mixin definition mapped in xml (not sure how to handle this in JDK 1.5 where the mappings are done with annotations) and add these attributes to a new class which is a subclass of the node's defined class. This new class would have properties defined for each property in the mixin. Has anyone else thought about how to handle this? Is this really a need, or should I just go back to using hashmaps (not something I really like, but) -paddy
[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.
Re: Is this issue resolved?
There isn't much of a reason to be so condescending. I agree that there are some serious issues in the design of the jackrabbit core infrastructure and a number of people have chimed in with similar thoughts. The best way forward is to provide constructive feedback and even patches for issues. I have found that so far the community is very welcoming of such things. The JXInsight tool, which I have experimented with in the past, is a great tool and can be used to detect nasty bits of code. However, I am unsure why the harsh tone (something I have seen on TSS and other forums, and have so far avoided here), again the best way to make this project successful is if we take hard looks at the code and work forward towards resolution. The JCR spec is pretty nice to work against and it is within all our best interests to ensure that there is a healthy successful community supporting it. aloha paddy
[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.
Re: Synchronized methods in ItemManager
Reading this post and going through some of the work I have done re. syncronization in the persistence manager I wonder if the real issue is not threads sharing a session, which it is clear they shouldn't, but that each session is tied to a persistence manager and an item manager which are both heavily synchronized. I understand the need to keep caches in sync etc, but it seems that we could be more performant (and I know I still owe the group numbers for performance :-) if we could use another pattern such as reader/writer locks, etc. to ensure consistency but allow for multiple simultaneous reads and writes. -paddy
[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.
Re: Jackrabbit, the database
I concur, relational semantics should be buried within the persistence managers. However, I think that one can still delegate transaction handling using JTA to the container rather than using synchronization and connection.autocommit(false). Obviously this should be configurable. Regardless of wether Jackrabbit wraps an underlying RDBMS or not transaction management, esp. in a clustered environment, being handled via the facilities available from one's container should reduce application complexity. Otherwise, one has to go to jgroups or some other project and embed that code which makes configuration/management more difficult in a production environment. I suppose one could write an admin console or expose via JMX admin functionality, however, some of this would be duplicative of the configuration of the container. -paddy Jukka Zitting wrote: Hi, On 8/20/07, Thomas Mueller <[EMAIL PROTECTED]> wrote: management won't. political reasons. won't move to Jackrabbit *if* Jackrabbit cannot store it in oracle. I agree. My guess is about 50% of larger organizations want a databases as the backend, even if databases are slower. So about 50% don't really care. Agreed, that's my understanding as well. I don't mind things like the current database persistence managers (as long as the persistence interface doesn't require a database), but I strongly feel that suggestions about pushing relational semantics or other similar database concepts higher up in the Jackrabbit architecture would be taking us to the wrong direction. Even though existing relational databases do provide a solution to many of the currently missing or partially implemented pieces in Jackrabbit (backup, clustering, etc., most notably a huge user and administrator base), a relational database will never be an optimal storage for the hierarchical content model in JCR. Essentially, in 5-10 years when we hopefully will start seriously optimizing for performance and scalability, I don't want us in a situation where we need to change the whole underlying architecture to reach real performance gains. BR, Jukka Zitting
Re: Multiple connections (Was: Jackrabbit, the database)
Weblogic and oracle do something similair as well. Also, the PreparedStatement caches in those pools are configurable. Once I have the chance, hopefully this week, I'll get some testing done with the code I modified. Also, Derby has a pooled connection system as well. -pih Thomas Mueller wrote: Hi, returns a prepared statement back to a pool (instead of really closing it) You are right, that's great! Then we should test if the PooledConnectionPersistenceManager really does improve the performance, and in what cases. Thomas
Re: Jackrabbit, the database
On a similar subject, has any one looked at Freebase? It is built upon Metaweb which is described in their manual as: "A Metaweb database is a sea of knowledge organized as a graph: a set of nodes and a set of links or relationships between those nodes." After playing with it for a while it is very similar in concept to jackrabbit/jcr however it is primarily using json for queries and object representation. This an mix-ins is what is sparking my dynamic typing thoughts. My point in bringing this up is that there seems to be a movement illustrated by both jcr and this metaweb idea which is a step back and at the same time a forward movement towards tree based data structures with reference-able links. Perhaps this also means moving away not only from RDBMS systems as core storage but also away from their query languages such as SQL. The metaweb json system is extremely interesting and seems easy and powerful, worth taking a look at. -paddy
Re: Jackrabbit, the database
If Jackrabbit is to be the database then things such as transaction isolation levels, etc. need to be addressed. If Jackrabbit uses a database (ie derby) some of those can be off loaded to the db. However, in that case Jackrabbit becomes yet another, albeit extremely interesting, wrapper around an RDBMS. I think Jackrabbit is much more than an RDBMS wrapper and that developing the API is just a part of the overall system. IMO, moving away from derby and into a native storage system sounds like the right direction. Jukka Zitting wrote: Hi, Late night ramblings... There's recently been a lot of talk about managing the database connections (and transactions) of the Jackrabbit persistence managers. It was even suggested that Jackrabbit be refactored so that each session would map to a separate database connection. Improvements in the way an underlying database is used are of course welcome, but in the big picture I don't like having the database being a driving factor in Jackrabbit design. The way I see it we should be moving further away from relational databases, towards a native hierarchical storage model. I don't want Jackrabbit using a database, I want Jackrabbit *being* the database! BR, Jukka Zitting
Re: [jira] Created: (JCR-1050) Remove synchronization from JNDI data sources
Looking briefly at the code, it doesn't look like having a single instance of a persistence manager would cause too many issues given the datasourcepersistence manager as I implemented it. I do not have any class level variables that would be used to do work in multiple threads (ie no connection or prepared statement caches, etc). I'll do some testing over the weekend or next week. -paddy Padraic Hannon wrote: I completely agree with that approach (TDD). I think examining how systems like hibernate and toplink handle session/connection relationships would point us in the right direction. Since jackrabbit is seen as something embedded within the servlet container using an embedded db I see the reason for doing a connection per workspace, however, once data grows to a certain point or the db becomes remote I have a feeling that it would be advantageous to allow each worker thread independent access to the repository. This would mean, however, leveraging or creating a more complex transactional framework and dealing with pooling, etc. -paddy
Re: [jira] Created: (JCR-1050) Remove synchronization from JNDI data sources
I completely agree with that approach (TDD). I think examining how systems like hibernate and toplink handle session/connection relationships would point us in the right direction. Since jackrabbit is seen as something embedded within the servlet container using an embedded db I see the reason for doing a connection per workspace, however, once data grows to a certain point or the db becomes remote I have a feeling that it would be advantageous to allow each worker thread independent access to the repository. This would mean, however, leveraging or creating a more complex transactional framework and dealing with pooling, etc. -paddy
dynamic mixins and jcr mapping
I was looking at the default object converter (ObjectConverterImpl) and noticed that it dynamically adds the ocm:discriminator mixin type to the jcr node on insert. Additionally I have been thinking about dynamic languages and looking at Freebase, to make a long story short I am thinking about dynamic typing of java objects. My thought was that through a typing (or tagging) mechanism one could create objects with attribute collections whose values could be validated via jcr if one could dynamically assign mixins based on a field in that object. For example, if you have a vehicle feature you may want to tag it as a transmission and an option. Each tag (or type) would carry a set of attribute definitions that one would want to see on a web page or in a data entry system. If you could inspect the object and look at how it is tagged you could write those tags in as mixins when persisting to jcr. Then jackrabbit could enforce data types, required fields, etc. This sort of functionality is a no brainer in dynamically typed systems such as javascript, ruby, etc. however is not strictly possible in java (or at least is way out of my league) via interfaces or superclasses, but could be done via a contract (getTags() getTypes() something like that) where a method returns mixin names? Does this make anyone immediately repulsed? I could submit a patch or two to jira if anyone is interested... -paddy
[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.
Re: jcr mapping question
As a reference here are diffs...
-paddy
Index: BeanReferenceCollectionConverterImpl.java
===
--- BeanReferenceCollectionConverterImpl.java (revision 566465)
+++ BeanReferenceCollectionConverterImpl.java (working copy)
@@ -168,7 +168,16 @@
}
String uuid = (String)
ReflectionUtils.getNestedProperty(object, fieldDescriptor.getFieldName());
- values[i] =
valueFactory.createValue(uuid, PropertyType.REFERENCE);
+if (uuid == null) {
+super.objectConverter.insert(session, object);
+FieldDescriptor pathDescriptor =
classDescriptor.getPathFieldDescriptor();
+String path = (String)
ReflectionUtils.getNestedProperty(object, pathDescriptor.getFieldName());
+object = objectConverter.getObject(session, path);
+uuid = (String)
ReflectionUtils.getNestedProperty(object, fieldDescriptor.getFieldName());
+} else {
+objectConverter.update(session, object);
+}
+values[i] = valueFactory.createValue(uuid,
PropertyType.REFERENCE);
}
}
Index: ReferenceBeanConverterImpl.java
===
--- ReferenceBeanConverterImpl.java (revision 566465)
+++ ReferenceBeanConverterImpl.java (working copy)
@@ -55,14 +55,13 @@
public void insert(Session session, Node parentNode, BeanDescriptor
beanDescriptor, ClassDescriptor beanClassDescriptor, Object object,
ClassDescriptor parentClassDescriptor, Object parent)
throws ObjectContentManagerException,
RepositoryException, JcrMappingException
{
- updateReferenceProperty(parentNode, beanDescriptor,
beanClassDescriptor, object);
-
- }
+insertOrUpdate(session, parentNode, beanDescriptor,
beanClassDescriptor, object);
+}
- public void update(Session session, Node parentNode, BeanDescriptor
beanDescriptor, ClassDescriptor beanClassDescriptor, Object object,
ClassDescriptor parentClassDescriptor, Object parent)
+public void update(Session session, Node parentNode, BeanDescriptor
beanDescriptor, ClassDescriptor beanClassDescriptor, Object object,
ClassDescriptor parentClassDescriptor, Object parent)
throws ObjectContentManagerException,
RepositoryException, JcrMappingException
{
- updateReferenceProperty(parentNode, beanDescriptor,
beanClassDescriptor, object);
+insertOrUpdate(session, parentNode, beanDescriptor,
beanClassDescriptor, object);
}
public Object getObject(Session session, Node parentNode,
BeanDescriptor beanDescriptor, ClassDescriptor beanClassDescriptor, Class
beanClass, Object parent)
@@ -85,8 +84,37 @@
{
updateReferenceProperty(parentNode, beanDescriptor,
beanClassDescriptor, null);
}
-
- private void updateReferenceProperty(Node parentNode, BeanDescriptor
beanDescriptor,ClassDescriptor beanClassDescriptor, Object object) {
+
+private void insertOrUpdate(Session session, Node parentNode,
BeanDescriptor beanDescriptor, ClassDescriptor beanClassDescriptor, Object
object) {
+try {
+ if (object == null)
+ {
+ parentNode.setProperty(beanDescriptor.getJcrName(), (Value)
null);
+ }
+
+ FieldDescriptor fieldDescriptor =
beanClassDescriptor.getUuidFieldDescriptor();
+ if (fieldDescriptor == null)
+ {
+ throw new JcrMappingException("The bean doesn't have an uuid
- classdescriptor : " + beanClassDescriptor.getClassName());
+ }
+
+ String uuid = (String) ReflectionUtils.getNestedProperty(object,
fieldDescriptor.getFieldName());
+ if (uuid == null) {
+ objectConverter.insert(session, object);
+ FieldDescriptor pathDescriptor =
beanClassDescriptor.getPathFieldDescriptor();
+ String path = (String)
ReflectionUtils.getNestedProperty(object, pathDescriptor.getFieldName());
+ object = objectConverter.getObject(session, path);
+ uuid = (String) ReflectionUtils.getNestedProperty(object,
fieldDescriptor.getFieldName());
+ } else {
+ objectConverter.update(session, object);
+ }
+ parentNode.setProperty(beanDescriptor.getJcrName(), uuid,
PropertyType.REFERENCE);
+ } catch (Exception e) {
+ throw new ObjectContentManagerException("Impossible to insert the
bean attribute into the repository", e);
+ }
+}
+
jcr mapping question
We are using the repository pattern for our object retrieval (http://www.martinfowler.com/eaaCatalog/repository.html) and I am trying to migrate from a typical ORM system (toplink, hibernate, etc) backed by an RDBMS to jackrabbit (actually CRX) using the jcr-mapping project. It appears that for child object the jcr project does what I would assume (NTCollectionConverterImpl) and stores the objects that haven't already been stored. However, if one does not one a referenced object to be a child but rather just a property with a reference then things start to diverge from what I would assume would happen. Perhaps, the error is in my modeling (entirely possible!), however, I would think that the Reference converters for both beans and collections would do more than just persist the UUIDs. Would it be horrible if these where updated to persist the referenced object is a UUID is not present prior to persisting the referenced object? Of course I think it should probably update the referenced objects properties if the object already exists. Does this make sense? It adds complexity, but it seems like that would be the expected functionality. -paddy
Re: Questions about TX in Jackrabbit, JTA and Spec compliance
I logged a similar issue: https://issues.apache.org/jira/browse/JCR-1050. It seems to me that Jackrabbit needs to decide if it is a data store or if it leverages one. If it leverages one it should delegate the transactional handling to the data store. If it is one is, there is a lot of work to be done to ensure that transaction isolation levels are respected, synchronization should not be the default state of the repository. Regardless of this question, it seems that there is a lot of work to be done to rework some of the persistence mechanisms to delegate transaction management to the container. I understand that there is some thought to run jackrabbit in an embedded mechanism, however, so far it seems fairly closely tied to running within (at least) a servlet container. I like the suggestion of creating different PMs for different cases. Further use of OSGi (as suggested by Sling) could create a nice plugin mechanism for leveraging different PMs (although the current xml based configuration files also address this). -paddy Cris Daniluk wrote: Hm, I doubt that. JR at its core stores content with calls to an abstract interface, namely the Persistence Manager. It is this component that may store nodes and properties inside a DBMS, via JDBC calls over a single connection it acquired on startup. Changing this to using a transaction-local JDBC connection looks more complex to me than persisting the change log. Based on that design, persisting the change log is probably the way to go. If you're using a single connection to write back to the DBMS, that log could easily become very lengthy. I think the performance overhead of writing to disk and flushing it would be utterly insignificant (synchronous db writing is far more expensive performance-wise, yet JR still exhibits solid performance). After reviewing some of the code, I think the problem is quite simply that Jackrabbit does something inherently incorrect - it attempts to provide guaranteed transactionality for all persistence managers. I think the transactionality must be applied and enforced at the PM, with help from the core API as well. Not all PMs are transactional, nor are they required to be by the JCR. In other words, a provider could give the optional transactional support for some of its PMs but not all. I think the intent of that decision was for this very reason. I would recommend creating a TransactionalPersistenceManager interface and implementing it where appropriate. If someone tries to register an XA transaction while a non-transactional PM is in use, it would throw an immediate UnsupportedOperationException. - Cris
Re: Better Jira components
Managing releases that span multiple projects does tend to be a pain in Jira as the version field is specific to a project. This means you cannot query for all tasks for a release across multiple projects unless you create a separate release field (at least that has been our experience here at Edmunds). -paddy Jukka Zitting wrote: Hi, On 8/8/07, Stefan Guggisberg <[EMAIL PROTECTED]> wrote: i'd definitely like to keep the finer granularity in core. ideally there should be something like subcomponents but prefixing would be fine with me. Eventually (perhaps starting with Jackrabbit 2.0) we may want to start having separate release cycles for the different subprojects, which means that we would also have separate Jira projects and components for each Jackrabbit subproject. There's some overhead to doing that, so I'd like to do that only when the pain of doing synchronous releases (like nobody being able to review too big release candidates) gets too big. BR, Jukka Zitting
[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.
