Re: JCROM and Jackrabbit OCM
Hi, Concerning Jackrabbit OCM,I am (unfortunately) the only committer for the project. For the moment, I have no time to work on it. That's the reason why the code didn't change for a long time. Maybe I'm wrong but I think it is almost the same for JCROM. In a such situation, it should be nice to know : Who are using OCM or JCROM in the Jackrabbit community ? Who want to contribute to OCM or JCROM (this is certainly the most important question ) ? Will we plan to keep both projects ? Christophe 2009/9/29 Jukka Zitting jukka.zitt...@gmail.com: Hi, On Fri, Sep 18, 2009 at 9:12 PM, Jason Thrasher ja...@coachthrasher.com wrote: What's the status of JCROM - Jackrabbit idea, and OCM in Jackrabbit in general? It's not clear from reading the website, or the lists. There seems to be general interest to bringing JCROM to Jackrabbit, and so far I see nobody objecting to the idea. To move forward on this, we need IP clearance [1] on JCROM and a Jackrabbit VOTE on accepting the codebase. I'm happy to support the process for all the parts that require an ASF officer, but it would be great if we had volunteers for things like filling in the IP clearance template [2]. [1] http://incubator.apache.org/ip-clearance/index.html [2] http://incubator.apache.org/ip-clearance/ip-clearance-template.html BR, Jukka Zitting
[jira] Created: (OCM-36) Query - Add unit test for method Filter.addNotNull(...)
Query - Add unit test for method Filter.addNotNull(...) --- Key: OCM-36 URL: https://issues.apache.org/jira/browse/OCM-36 Project: Jackrabbit OCM Issue Type: Bug Reporter: Christophe Lombart There is an incorrect result when a query is build with a notNull criteria. We have to add more unit tests for the query manager to check what is wrong. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Assigned: (OCM-33) Running the tests without mvn clean provides errors
[ https://issues.apache.org/jira/browse/OCM-33?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christophe Lombart reassigned OCM-33: - Assignee: Christophe Lombart Running the tests without mvn clean provides errors - Key: OCM-33 URL: https://issues.apache.org/jira/browse/OCM-33 Project: Jackrabbit OCM Issue Type: Bug Affects Versions: 1.6.0 Reporter: Christophe Lombart Assignee: Christophe Lombart Running the tests without mvn clean provides errors. Eg.mvn clean test works fine but not mvn test. The unit test used for the node type manager (NodeTypeManagerImplTest) provides some exception on a second run because it creates namespaces node types. We have to setup a clean repo before starting the unit tests. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (OCM-33) Running the tests without mvn clean provides errors
Running the tests without mvn clean provides errors - Key: OCM-33 URL: https://issues.apache.org/jira/browse/OCM-33 Project: Jackrabbit OCM Issue Type: Bug Affects Versions: 1.6.0 Reporter: Christophe Lombart Running the tests without mvn clean provides errors. Eg.mvn clean test works fine but not mvn test. The unit test used for the node type manager (NodeTypeManagerImplTest) provides some exception on a second run because it creates namespaces node types. We have to setup a clean repo before starting the unit tests. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (OCM-33) Running the tests without mvn clean provides errors
[ https://issues.apache.org/jira/browse/OCM-33?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christophe Lombart resolved OCM-33. --- Resolution: Fixed Fix Version/s: 1.6.0 Fixed. Now the unit tests are working. Running the tests without mvn clean provides errors - Key: OCM-33 URL: https://issues.apache.org/jira/browse/OCM-33 Project: Jackrabbit OCM Issue Type: Bug Affects Versions: 1.6.0 Reporter: Christophe Lombart Assignee: Christophe Lombart Fix For: 1.6.0 Running the tests without mvn clean provides errors. Eg.mvn clean test works fine but not mvn test. The unit test used for the node type manager (NodeTypeManagerImplTest) provides some exception on a second run because it creates namespaces node types. We have to setup a clean repo before starting the unit tests. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Assigned: (OCM-2) Different behaviors between insert and update of a collection
[ https://issues.apache.org/jira/browse/OCM-2?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christophe Lombart reassigned OCM-2: Assignee: Christophe Lombart Different behaviors between insert and update of a collection - Key: OCM-2 URL: https://issues.apache.org/jira/browse/OCM-2 Project: Jackrabbit OCM Issue Type: Bug Reporter: Sandrine Raffalli Assignee: Christophe Lombart In the DefaultCollectionConverter in the insert method : if the element has an identifier field it's this field that is taken as the elementJcrName. Else it is the jcrElementName of the collection or the default name. In the update method, if the element has an id field and an uuid field, it's the jcrElementName of the collection or the default name that is taken, not the id field. In case of insert or update, it must take the same identifier to build the path. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: [OCM] Mapping of JPA entities
2009/5/23 Benjamin Rack benjamin.r...@gmx.de Hello, I'm trying to persist JPA entities to a Jackrabbit Repository using the OCM framework. I'm not sure that it will be possible or easy in all cases. There are many JPA annotations that will not be usefull in a JCR context and some annotations are missing in the JPA world to have a full JCR support. Nevertheless, we can start a review and make a prototype. If you are interested to work on that, there is a jira issue ( http://issues.apache.org/jira/browse/OCM-13). The main problem in doing so is that such entities normally do not contain suitable properties for storing the path and uuid, which is required for OCM in order to handle instances of the entity classes. This is certainly a good example on what is missing in the JPA world. Path and UUID have to be supported in an OCM-JPA implementation. My current approach is using Javassist in a preprocessing step and enhancing the given entity classes by adding two special properties and respective get/set methods for these properties. Furthermore the preprocessing step is used for generating the OCM mapping metadata by analyzing the JPA annotations in the given entity classes and transforming them into according OCM mapping metadata. I understand your problem but I'm not a big fan of code enhancement. What are you doing with the entity primary keys (@id or @EmbeddedId)? Is there another approach, which possibly could make the mapping of JPA entities to a Content Repository a bit easier? Perhaps, someone has already solved this problem in a better way. No sorry :-( I'm not sure that we have to support all JPA features. Maybe you can start smoothly even if you have to modify the annotations in your entities. Thanks, Benjamin
Re: Does OCM suppport lifecycle callback?
This kind of features is not yet supported but there is a plan to do it. we should start a Jira issue to find a good solution for this kind of problem. br, Christophe On Fri, Dec 12, 2008 at 08:08, Yonder zy...@yahoo.com.cn wrote: nt:unstructured allows any number of properties with any names. but with OCM, we can only set predefined properties on a jcr node. It's not flexible sometime. for example, a CmsObject may have some optional properties then user can place owner information or something else. Maybe we can add a callback feature in ObjectConverterImpl that allows some annotated methods in an ocm object will be callback during saving or retrieving the object ___ 好玩贺卡等你发，邮箱贺卡全新上线！ http://card.mail.cn.yahoo.com/
[jira] Assigned: (JCR-1889) Incorrect support for java interfaces in typed collection fields
[
https://issues.apache.org/jira/browse/JCR-1889?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Christophe Lombart reassigned JCR-1889:
---
Assignee: Christophe Lombart
Incorrect support for java interfaces in typed collection fields
Key: JCR-1889
URL: https://issues.apache.org/jira/browse/JCR-1889
Project: Jackrabbit
Issue Type: Bug
Affects Versions: 1.4, 1.5.0
Reporter: Christophe Lombart
Assignee: Christophe Lombart
If a typed collection field is defined with an Interface as the type, the
following exception is thrown when the main object is inserted :
org.apache.jackrabbit.ocm.exception.JcrMappingException: Cannot load class
interface [name of the interface];
Here is a example :
@Node
public class EntityA {
@Field(path=true) String path;
@Collection ListMyInterface entityB;
}
When inserting a new instance of EntityA with a not null entityB, the
exception is thrown.
A workaround is to add the elementClassName on the annotation @Collection.
ex. :
@Collection (elementClassName=MyInterface.class) ListMyInterface entityB;
elementClassName is used only for untyped collections but if you specify it
for a typed collection, the ObjectContentManager will not use reflexion to
check the collection class name.
This should be nice to avoid the usage of elementClassName for typed
collections.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Assigned: (JCR-1869) Make lazy loading proxy callback Serializable
[ https://issues.apache.org/jira/browse/JCR-1869?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christophe Lombart reassigned JCR-1869: --- Assignee: Christophe Lombart Make lazy loading proxy callback Serializable - Key: JCR-1869 URL: https://issues.apache.org/jira/browse/JCR-1869 Project: Jackrabbit Issue Type: Improvement Components: jackrabbit-ocm Reporter: Stephane Landelle Assignee: Christophe Lombart Attachments: AbstractLazyLoader.java, BeanLazyLoader.java, CollectionLazyLoader.java Hello (probably Christophe :) ), It would be nice to have the CGLib callbacks Serializable, because if they're not, the proxies are not either, even if the target is. I've seen that you've made BeanLazyLoader Serializable. Wouldn't be better to have AbstractLazyLoader Serializable, so CollectionLazyLoader is too? What I've done is : *) declaring AbstractLazyLoader as Serializable *) declaring non-Serializable resources such as Session as volatile *) throwing an IllegalStateException in BeanLazyLoader.fetch and CollectionLazyLoader.fetch if the Session is null. This case can only happen if the proxy has been serialized without the volatile Session, and it doesn't make sense to lazy load the target then. BTW, I realized I didn't clean up the beanClassDescriptor in BeanLazyLoader.cleanUp, so I corrected this. I'll attach the modified classes. Sincerely, Stéphane Landelle -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (JCR-1869) Make lazy loading proxy callback Serializable
[ https://issues.apache.org/jira/browse/JCR-1869?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christophe Lombart resolved JCR-1869. - Resolution: Fixed Fix Version/s: 1.6.0 Patch applied. Thanks Make lazy loading proxy callback Serializable - Key: JCR-1869 URL: https://issues.apache.org/jira/browse/JCR-1869 Project: Jackrabbit Issue Type: Improvement Components: jackrabbit-ocm Reporter: Stephane Landelle Assignee: Christophe Lombart Fix For: 1.6.0 Attachments: AbstractLazyLoader.java, BeanLazyLoader.java, CollectionLazyLoader.java Hello (probably Christophe :) ), It would be nice to have the CGLib callbacks Serializable, because if they're not, the proxies are not either, even if the target is. I've seen that you've made BeanLazyLoader Serializable. Wouldn't be better to have AbstractLazyLoader Serializable, so CollectionLazyLoader is too? What I've done is : *) declaring AbstractLazyLoader as Serializable *) declaring non-Serializable resources such as Session as volatile *) throwing an IllegalStateException in BeanLazyLoader.fetch and CollectionLazyLoader.fetch if the Session is null. This case can only happen if the proxy has been serialized without the volatile Session, and it doesn't make sense to lazy load the target then. BTW, I realized I didn't clean up the beanClassDescriptor in BeanLazyLoader.cleanUp, so I corrected this. I'll attach the modified classes. Sincerely, Stéphane Landelle -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (JCR-1853) Modified QueryImpl to enable external query builders to read and write JCR expressions in the orderBy Clause
[ https://issues.apache.org/jira/browse/JCR-1853?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christophe Lombart updated JCR-1853: Component/s: jackrabbit-ocm Affects Version/s: 1.5.0 Modified QueryImpl to enable external query builders to read and write JCR expressions in the orderBy Clause Key: JCR-1853 URL: https://issues.apache.org/jira/browse/JCR-1853 Project: Jackrabbit Issue Type: Improvement Components: jackrabbit-ocm Affects Versions: 1.5.0 Reporter: Shrirang Assignee: Christophe Lombart Fix For: 1.6.0 Attachments: OrderByPatch.patch The QueryImpl does not create the JCR expression on the fly. The OrderByExpression does the job. If an external querybuilder class needs to dynamically collect properties against which order by is required, QueryImpl does not support updating the JCR Expression. It can only return the built expression since arrayList is used for collecting the properties. The change enables one to add JCRExpression to the QueryImpl object. A test has been added. Changed files: Path src/main/java/org/apache/jackrabbit/ocm/query/impl/QueryImpl.java src/test/java/org/apache/jackrabbit/ocm/manager/query/DigesterSimpleQueryTest.java -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Assigned: (JCR-1853) Modified QueryImpl to enable external query builders to read and write JCR expressions in the orderBy Clause
[ https://issues.apache.org/jira/browse/JCR-1853?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christophe Lombart reassigned JCR-1853: --- Assignee: Christophe Lombart Modified QueryImpl to enable external query builders to read and write JCR expressions in the orderBy Clause Key: JCR-1853 URL: https://issues.apache.org/jira/browse/JCR-1853 Project: Jackrabbit Issue Type: Improvement Components: jackrabbit-ocm Affects Versions: 1.5.0 Reporter: Shrirang Assignee: Christophe Lombart Fix For: 1.6.0 Attachments: OrderByPatch.patch The QueryImpl does not create the JCR expression on the fly. The OrderByExpression does the job. If an external querybuilder class needs to dynamically collect properties against which order by is required, QueryImpl does not support updating the JCR Expression. It can only return the built expression since arrayList is used for collecting the properties. The change enables one to add JCRExpression to the QueryImpl object. A test has been added. Changed files: Path src/main/java/org/apache/jackrabbit/ocm/query/impl/QueryImpl.java src/test/java/org/apache/jackrabbit/ocm/manager/query/DigesterSimpleQueryTest.java -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (JCR-1853) Modified QueryImpl to enable external query builders to read and write JCR expressions in the orderBy Clause
[ https://issues.apache.org/jira/browse/JCR-1853?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christophe Lombart closed JCR-1853. --- Resolution: Fixed Patch applied. Thanks Let me know if something is wrong. You can close the issue if the commit is good for you Modified QueryImpl to enable external query builders to read and write JCR expressions in the orderBy Clause Key: JCR-1853 URL: https://issues.apache.org/jira/browse/JCR-1853 Project: Jackrabbit Issue Type: Improvement Components: jackrabbit-ocm Affects Versions: 1.5.0 Reporter: Shrirang Assignee: Christophe Lombart Fix For: 1.6.0 Attachments: OrderByPatch.patch The QueryImpl does not create the JCR expression on the fly. The OrderByExpression does the job. If an external querybuilder class needs to dynamically collect properties against which order by is required, QueryImpl does not support updating the JCR Expression. It can only return the built expression since arrayList is used for collecting the properties. The change enables one to add JCRExpression to the QueryImpl object. A test has been added. Changed files: Path src/main/java/org/apache/jackrabbit/ocm/query/impl/QueryImpl.java src/test/java/org/apache/jackrabbit/ocm/manager/query/DigesterSimpleQueryTest.java -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Assigned: (JCR-1859) BeanLazyLoader is not Serializable
[ https://issues.apache.org/jira/browse/JCR-1859?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christophe Lombart reassigned JCR-1859: --- Assignee: Christophe Lombart BeanLazyLoader is not Serializable -- Key: JCR-1859 URL: https://issues.apache.org/jira/browse/JCR-1859 Project: Jackrabbit Issue Type: Improvement Components: jackrabbit-ocm Reporter: Marcin Muras Assignee: Christophe Lombart Fix For: 1.5.0 Class org.apache.jackrabbit.ocm.manager.objectconverter.impl.BeanLazyLoader is not serializable. In ocm module we can mark some property to be lazy loaded. For example @Bean(..., proxy=true) In such scenario instead of object we will have here proxy BeanLazyLoader which is not serializable. It is problematic while using another technologies. For example Spring WebFlow requires objects (model) stored in scope to be Serializable. So when we use proxied model with Spring WebFlow we received exception org.springframework.webflow.execution.repository.snapshot.SnapshotCreationException: Could not serialize flow execution; make sure all objects stored in flow or flash scope are serializable Caused by: java.io.NotSerializableException: org.apache.jackrabbit.ocm.manager.objectconverter.impl.BeanLazyLoader ... Please make BeanLazyLoader Serializable. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (JCR-1859) BeanLazyLoader is not Serializable
[ https://issues.apache.org/jira/browse/JCR-1859?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christophe Lombart closed JCR-1859. --- Resolution: Fixed Fix Version/s: (was: 1.5.0) 1.6.0 Fixed. Thanks Let me know if something is wrong. BeanLazyLoader is not Serializable -- Key: JCR-1859 URL: https://issues.apache.org/jira/browse/JCR-1859 Project: Jackrabbit Issue Type: Improvement Components: jackrabbit-ocm Reporter: Marcin Muras Assignee: Christophe Lombart Fix For: 1.6.0 Class org.apache.jackrabbit.ocm.manager.objectconverter.impl.BeanLazyLoader is not serializable. In ocm module we can mark some property to be lazy loaded. For example @Bean(..., proxy=true) In such scenario instead of object we will have here proxy BeanLazyLoader which is not serializable. It is problematic while using another technologies. For example Spring WebFlow requires objects (model) stored in scope to be Serializable. So when we use proxied model with Spring WebFlow we received exception org.springframework.webflow.execution.repository.snapshot.SnapshotCreationException: Could not serialize flow execution; make sure all objects stored in flow or flash scope are serializable Caused by: java.io.NotSerializableException: org.apache.jackrabbit.ocm.manager.objectconverter.impl.BeanLazyLoader ... Please make BeanLazyLoader Serializable. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (JCR-1858) ClassDescriptor ReflectionUtils ClassLoader Defect
[ https://issues.apache.org/jira/browse/JCR-1858?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12648335#action_12648335 ] Christophe Lombart commented on JCR-1858: - It should be nice to have a smaller test with less dependencies and files. Is it possible to create patch with a unit test ? Thanks ClassDescriptor ReflectionUtils ClassLoader Defect -- Key: JCR-1858 URL: https://issues.apache.org/jira/browse/JCR-1858 Project: Jackrabbit Issue Type: Bug Components: jackrabbit-ocm Affects Versions: 1.4 Environment: JVM 1.6.0.6/Windows XP SP2/Netbeans 6.2 Beta Reporter: V. W. Attachments: TestCase.zip I have stumbuled on a bug in the interaction between ClassDescriptor and ReflectionUtils classes: 1. ClassDescriptor.validateClassName() uses ReflectionUtils.forName(String) to resolve an annotated class by its name 2. ReflectionUtils is an evil stateful statics-based singleton. It has a field of a ClassLoader, which by default is the one that loaded the ReflectionUtils. The method forName(String) uses this ClassLoader to resolve the annotated class. The problem is that the ClassDescriptor assumses that the annotated class comes from a global ClassLoader (the one that loaded the jars), which is not always correct. The workaround is to manually set the ReflectionUtils ClassLoader field for it to use the correct ClassLoader. I've found this bug while working with NetBeans, writing a small Scala application and using ScalaTest TestNG integration for testing. Apparantly many ClassLoader need to by involved to run a single test. I've created a unit test (java only, libraries included) to reproduce the bug. The best solution would be for the ClassDescriptor to use a Class reference (the Class contains its ClassLoader reference) instead of just a class-name or at least pair every class-name with its ClassLoader. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (JCR-1844) Convenience method to Or multiple values with a single filter
[ https://issues.apache.org/jira/browse/JCR-1844?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12646829#action_12646829 ] Christophe Lombart commented on JCR-1844: - You can close issues when it is ok for you. Thanks Convenience method to Or multiple values with a single filter - Key: JCR-1844 URL: https://issues.apache.org/jira/browse/JCR-1844 Project: Jackrabbit Issue Type: Improvement Components: jackrabbit-ocm Reporter: Shrirang Assignee: Christophe Lombart Fix For: 1.6.0 Attachments: OrFilterPatch.patch Added a convenience method to add Or Filter for the same property with multiple values. This is to simulate an IN Clause in JackRabbit. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Assigned: (JCR-1844) Convenience method to Or multiple values with a single filter
[ https://issues.apache.org/jira/browse/JCR-1844?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christophe Lombart reassigned JCR-1844: --- Assignee: Christophe Lombart Convenience method to Or multiple values with a single filter - Key: JCR-1844 URL: https://issues.apache.org/jira/browse/JCR-1844 Project: Jackrabbit Issue Type: Improvement Components: jackrabbit-ocm Reporter: Shrirang Assignee: Christophe Lombart Fix For: 1.6.0 Attachments: OrFilterPatch.patch Added a convenience method to add Or Filter for the same property with multiple values. This is to simulate an IN Clause in JackRabbit. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (JCR-1844) Convenience method to Or multiple values with a single filter
[ https://issues.apache.org/jira/browse/JCR-1844?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christophe Lombart resolved JCR-1844. - Resolution: Fixed Patch applied. Can you check if it is ok for you ? Thank Convenience method to Or multiple values with a single filter - Key: JCR-1844 URL: https://issues.apache.org/jira/browse/JCR-1844 Project: Jackrabbit Issue Type: Improvement Components: jackrabbit-ocm Reporter: Shrirang Assignee: Christophe Lombart Fix For: 1.6.0 Attachments: OrFilterPatch.patch Added a convenience method to add Or Filter for the same property with multiple values. This is to simulate an IN Clause in JackRabbit. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: Alternative OCM (Object Content Mapping )
On Mon, Nov 10, 2008 at 16:25, Fard [EMAIL PROTECTED] wrote: Before I use JCROM I tried using native Jackrabbit OCM but it didn't response to my need. Which one ? thanks, Christophe
Re: Alternative OCM (Object Content Mapping )
make a try with 1.5 which is simpler :-) Christophe On Mon, Nov 10, 2008 at 21:46, Fard [EMAIL PROTECTED] wrote: I have used jackrabbit 1.4. Thanks Maurice Fard Christophe Lombart wrote: On Mon, Nov 10, 2008 at 16:25, Fard [EMAIL PROTECTED] wrote: Before I use JCROM I tried using native Jackrabbit OCM but it didn't response to my need. Which one ? thanks, Christophe -- View this message in context: http://www.nabble.com/Alternative-OCM-%28Object-Content-Mapping-%29-tp20414731p20427613.html Sent from the Jackrabbit - Dev mailing list archive at Nabble.com.
Re: OCM:Supporting nested properties for the FilterImpl
At present, this not possible but I think it should be nice to implement
it.
See the issue http://issues.apache.org/jira/browse/JCR-878 (see the latest
point in this issue). We can split this issue into smaller ones .
On Fri, Oct 17, 2008 at 08:01, Boni Gopalan (BioImagene)
[EMAIL PROTECTED] wrote:
The Filter is a nifty interface that allows hassle free construction of
JCR query strings through a Criterion() like methods. The default
implementation does a remarkably accurate job of building queries that
are one level deep. It would be great if the queries can be any level
deep so that one can fetch back any specific 'Object' representation of
a node or a property.
Eg.
Foo{
String id;
ListBar myBar;
}
Bar{
String id;
String name;
}
Filter(Foo.class); [Not exactly but you get the idea!]
Filter.addEqualsTo(myBar[].name, CA's Pub Pub);
Ocm.getObjects(Filter) , fetches all the Foos with a nested property
name=CA's Pub
Any thoughts? Is it possible with the current API?,
Thanks
Boni
Boni Gopalan
Manager Engineering
BioImagene, Pune
+91-206-609-6579(O)
+91-992-369-9356(C)
Re: [jira] Commented: (JCR-1784) OCM:The UUID of the collection elements changes on update.
If it is not a big deal for you and if it ia a help to keep track on changes, you can do it. Anyway, thanks for the info in subversion. christophe On Thu, Oct 16, 2008 at 12:29, Jukka Zitting [EMAIL PROTECTED]wrote: Hi, On Thu, Oct 16, 2008 at 12:07 PM, Christophe Lombart [EMAIL PROTECTED] wrote: if you want, I can do it in 1.5 It's no big deal for me to do the merging, and doing so helps me keep track of everything that's being included in the release. But if you like to do the merge then that's fine as well. Note however that I'm using the merge tracking feature in Subversion 1.5 to keep track of things in the branch, so if you work there make sure that you are also using svn 1.5.x and follow a workflow like this: 0) Checkout the 1.5 branch: svn co https://svn.apache.org/repos/asf/jackrabbit/branches/1.5 jackrabbit-1.5https://svn.apache.org/repos/asf/jackrabbit/branches/1.5jackrabbit-1.5 cd jackrabbit-1.5 1) List all changes in trunk that are waiting to be merged to the branch svn mergeinfo https://svn.apache.org/repos/asf/jackrabbit/trunk --show-revs https://svn.apache.org/repos/asf/jackrabbit/trunk--show-revseligible 2a) For each change that you want to merge to the branch: svn merge -c $rev https://svn.apache.org/repos/asf/jackrabbit/trunk svn diff# check that everything is ok and modify if needed svn commit -m 1.5: Merged revision $rev ($jira) 2b) For each change that you do not want to merge to the branch: svn merge -c $rev --record-only https://svn.apache.org/repos/asf/jackrabbit/trunk svn commit -m 1.5: Ignore change in trunk BR, Jukka Zitting
[jira] Assigned: (JCR-1816) Provide more options for OCM CRUD API Writers to enhance the functionality
[ https://issues.apache.org/jira/browse/JCR-1816?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christophe Lombart reassigned JCR-1816: --- Assignee: Christophe Lombart Provide more options for OCM CRUD API Writers to enhance the functionality -- Key: JCR-1816 URL: https://issues.apache.org/jira/browse/JCR-1816 Project: Jackrabbit Issue Type: Improvement Reporter: Boni Gopalan Assignee: Christophe Lombart Priority: Trivial Fix For: 1.6.0 Attachments: JCR-1816.bonigopalan.patch I am working on an Extension to Object Content Manager and from that angle require a few methods and variable from the base classes to be exposed with protected access. I have modifier only the getters and these should not cause any issues to the current functionality. Request a review and addition to the trunk. 1. added a clone implementation to FilterImpl 2. Exposed : public CollectionConverter getCollectionConverter(Session session, CollectionDescriptor collectionDescriptor) from ObjectConverter -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: OCM:Supporting nested properties for the FilterImpl
ok. Thanks for your help.
Christophe
On Fri, Oct 17, 2008 at 09:27, Boni Gopalan (BioImagene)
[EMAIL PROTECTED] wrote:
The Mapping file gives a good handle on guessing what the equivalent
node or property name is. I think the current mapping file has all the
information needed to do an OGNL like traversing of the Nodes. Will try
out a testcase to understand the challenges.
-Original Message-
From: Christophe Lombart [mailto:[EMAIL PROTECTED]
Sent: 17 October 2008 12:26
To: dev@jackrabbit.apache.org
Subject: Re: OCM:Supporting nested properties for the FilterImpl
At present, this not possible but I think it should be nice to
implement
it.
See the issue http://issues.apache.org/jira/browse/JCR-878 (see the
latest
point in this issue). We can split this issue into smaller ones .
On Fri, Oct 17, 2008 at 08:01, Boni Gopalan (BioImagene)
[EMAIL PROTECTED] wrote:
The Filter is a nifty interface that allows hassle free construction
of
JCR query strings through a Criterion() like methods. The default
implementation does a remarkably accurate job of building queries that
are one level deep. It would be great if the queries can be any level
deep so that one can fetch back any specific 'Object' representation
of
a node or a property.
Eg.
Foo{
String id;
ListBar myBar;
}
Bar{
String id;
String name;
}
Filter(Foo.class); [Not exactly but you get the idea!]
Filter.addEqualsTo(myBar[].name, CA's Pub Pub);
Ocm.getObjects(Filter) , fetches all the Foos with a nested property
name=CA's Pub
Any thoughts? Is it possible with the current API?,
Thanks
Boni
Boni Gopalan
Manager Engineering
BioImagene, Pune
+91-206-609-6579(O)
+91-992-369-9356(C)
[jira] Resolved: (JCR-1816) Provide more options for OCM CRUD API Writers to enhance the functionality
[ https://issues.apache.org/jira/browse/JCR-1816?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christophe Lombart resolved JCR-1816. - Resolution: Fixed Patch applied. Thanks. Let me know if something is wrong. I'm still interesting to know what kind of extension you are writing :-) Provide more options for OCM CRUD API Writers to enhance the functionality -- Key: JCR-1816 URL: https://issues.apache.org/jira/browse/JCR-1816 Project: Jackrabbit Issue Type: Improvement Reporter: Boni Gopalan Assignee: Christophe Lombart Priority: Trivial Fix For: 1.6.0 Attachments: JCR-1816.bonigopalan.patch I am working on an Extension to Object Content Manager and from that angle require a few methods and variable from the base classes to be exposed with protected access. I have modifier only the getters and these should not cause any issues to the current functionality. Request a review and addition to the trunk. 1. added a clone implementation to FilterImpl 2. Exposed : public CollectionConverter getCollectionConverter(Session session, CollectionDescriptor collectionDescriptor) from ObjectConverter -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (JCR-1816) Provide more options for OCM CRUD API Writers to enhance the functionality
[ https://issues.apache.org/jira/browse/JCR-1816?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christophe Lombart updated JCR-1816: Component/s: jackrabbit-ocm Assign this issue to the ocm component Provide more options for OCM CRUD API Writers to enhance the functionality -- Key: JCR-1816 URL: https://issues.apache.org/jira/browse/JCR-1816 Project: Jackrabbit Issue Type: Improvement Components: jackrabbit-ocm Reporter: Boni Gopalan Assignee: Christophe Lombart Priority: Trivial Fix For: 1.6.0 Attachments: JCR-1816.bonigopalan.patch I am working on an Extension to Object Content Manager and from that angle require a few methods and variable from the base classes to be exposed with protected access. I have modifier only the getters and these should not cause any issues to the current functionality. Request a review and addition to the trunk. 1. added a clone implementation to FilterImpl 2. Exposed : public CollectionConverter getCollectionConverter(Session session, CollectionDescriptor collectionDescriptor) from ObjectConverter -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: [jira] Commented: (JCR-1784) OCM:The UUID of the collection elements changes on update.
Jukka, if you want, I can do it in 1.5 BR, Christophe On Thu, Oct 16, 2008 at 10:35, Jukka Zitting [EMAIL PROTECTED]wrote: Hi, On Thu, Oct 16, 2008 at 6:00 AM, Boni Gopalan (BioImagene) [EMAIL PROTECTED] wrote: I had submitted two patches on this issue. The first one was incomplete as it was not applying the same UUID interpretation to same-name-siblings other than collection elements. I feel both the patches should be applied to the same versions to provide a consistent interpretation. OK, I'll make sure sure that all the parts are included in 1.5. BR, Jukka Zitting
[jira] Commented: (JCR-1784) OCM:The UUID of the collection elements changes on update.
[ https://issues.apache.org/jira/browse/JCR-1784?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12639948#action_12639948 ] Christophe Lombart commented on JCR-1784: - Done. Thanks for your contribution. Do you want to see the latest path in the branch 1.5 ? I'm not sure that is critical for the release 1.5. OCM:The UUID of the collection elements changes on update. -- Key: JCR-1784 URL: https://issues.apache.org/jira/browse/JCR-1784 Project: Jackrabbit Issue Type: Bug Components: jackrabbit-ocm Affects Versions: 1.5.0 Reporter: Boni Gopalan Assignee: Christophe Lombart Fix For: 1.5.0 Attachments: JCR-1784.additional.bonigopalan, JCR-1784.bonigopalan.patch Original Estimate: 3h Remaining Estimate: 3h On ocm.update transaction, the Current implementation of DefaultCollectionConverterImpl recreates the colleciton-element nodes if there is no id field specificaiton. This is completely valid for majority of the cases. But I came across a case where the colleciton element has a uuid field. In this case also what is happening with the current implementation is that it drops all the elements from the old collection-elements and recreates the new ones. The major flip side is that now I am left with brand new UUIDs. I think we should address the uniqueness characteristics specified through UUID also while mapping colleciton elements. I have a patch and a TestCase to verify the same. I have implemented it only for the digester. If people feel the approach is right I will work out an annotation based testcase as well. I do not think it is going to fail even with annotations. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Assigned: (JCR-1804) Added the functionality to Map and Manage Type Enum
[ https://issues.apache.org/jira/browse/JCR-1804?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christophe Lombart reassigned JCR-1804: --- Assignee: Christophe Lombart Added the functionality to Map and Manage Type Enum --- Key: JCR-1804 URL: https://issues.apache.org/jira/browse/JCR-1804 Project: Jackrabbit Issue Type: Improvement Components: jackrabbit-ocm Affects Versions: 1.6.0 Reporter: Boni Gopalan Assignee: Christophe Lombart Priority: Minor Fix For: 1.6.0 Attachments: JCR-1804.bonigopalan.patch OCM API does not come with a mapper that can map Type Enum. I have added this functionality. Attached patch has test cases that tests the feature for Simple fields and Collection fields (For both anotations and digester based implementations) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (JCR-1804) Added the functionality to Map and Manage Type Enum
[ https://issues.apache.org/jira/browse/JCR-1804?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christophe Lombart resolved JCR-1804. - Resolution: Fixed Done. Thanks for the patch. I have only applied on the head (1.6-SNAPSHOT). I think this is not critical for the release 1.5. What do you think about that ? Added the functionality to Map and Manage Type Enum --- Key: JCR-1804 URL: https://issues.apache.org/jira/browse/JCR-1804 Project: Jackrabbit Issue Type: Improvement Components: jackrabbit-ocm Affects Versions: 1.6.0 Reporter: Boni Gopalan Assignee: Christophe Lombart Priority: Minor Fix For: 1.6.0 Attachments: JCR-1804.bonigopalan.patch OCM API does not come with a mapper that can map Type Enum. I have added this functionality. Attached patch has test cases that tests the feature for Simple fields and Collection fields (For both anotations and digester based implementations) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Assigned: (JCR-1784) OCM:The UUID of the collection elements changes on update.
[ https://issues.apache.org/jira/browse/JCR-1784?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christophe Lombart reassigned JCR-1784: --- Assignee: Christophe Lombart OCM:The UUID of the collection elements changes on update. -- Key: JCR-1784 URL: https://issues.apache.org/jira/browse/JCR-1784 Project: Jackrabbit Issue Type: Bug Affects Versions: 1.5 Reporter: Boni Gopalan Assignee: Christophe Lombart Fix For: 1.5 Attachments: JCR-1784.bonigopalan.patch Original Estimate: 3h Remaining Estimate: 3h On ocm.update transaction, the Current implementation of DefaultCollectionConverterImpl recreates the colleciton-element nodes if there is no id field specificaiton. This is completely valid for majority of the cases. But I came across a case where the colleciton element has a uuid field. In this case also what is happening with the current implementation is that it drops all the elements from the old collection-elements and recreates the new ones. The major flip side is that now I am left with brand new UUIDs. I think we should address the uniqueness characteristics specified through UUID also while mapping colleciton elements. I have a patch and a TestCase to verify the same. I have implemented it only for the digester. If people feel the approach is right I will work out an annotation based testcase as well. I do not think it is going to fail even with annotations. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (JCR-1784) OCM:The UUID of the collection elements changes on update.
[ https://issues.apache.org/jira/browse/JCR-1784?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christophe Lombart updated JCR-1784: Component/s: jackrabbit-ocm OCM:The UUID of the collection elements changes on update. -- Key: JCR-1784 URL: https://issues.apache.org/jira/browse/JCR-1784 Project: Jackrabbit Issue Type: Bug Components: jackrabbit-ocm Affects Versions: 1.5 Reporter: Boni Gopalan Assignee: Christophe Lombart Fix For: 1.5 Attachments: JCR-1784.bonigopalan.patch Original Estimate: 3h Remaining Estimate: 3h On ocm.update transaction, the Current implementation of DefaultCollectionConverterImpl recreates the colleciton-element nodes if there is no id field specificaiton. This is completely valid for majority of the cases. But I came across a case where the colleciton element has a uuid field. In this case also what is happening with the current implementation is that it drops all the elements from the old collection-elements and recreates the new ones. The major flip side is that now I am left with brand new UUIDs. I think we should address the uniqueness characteristics specified through UUID also while mapping colleciton elements. I have a patch and a TestCase to verify the same. I have implemented it only for the digester. If people feel the approach is right I will work out an annotation based testcase as well. I do not think it is going to fail even with annotations. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (JCR-1784) OCM:The UUID of the collection elements changes on update.
[
https://issues.apache.org/jira/browse/JCR-1784?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12637177#action_12637177
]
Christophe Lombart commented on JCR-1784:
-
Your patch seems good but I'm wondering why you have modified the class
AbstractMapperImpl ( see [1]).
It works without this modification and we can leave the code as it is (throw an
exception is there is no descriptor).
Are you agree if we don't modify this class ?
[1] Index:
src/main/java/org/apache/jackrabbit/ocm/mapper/impl/AbstractMapperImpl.java
===
--- src/main/java/org/apache/jackrabbit/ocm/mapper/impl/AbstractMapperImpl.java
(revision 701632)
+++ src/main/java/org/apache/jackrabbit/ocm/mapper/impl/AbstractMapperImpl.java
(working copy)
@@ -200,7 +200,7 @@
public ClassDescriptor getClassDescriptorByClass(Class clazz) {
ClassDescriptor descriptor =
mappingDescriptor.getClassDescriptorByName(clazz.getName());
if (descriptor==null) {
- throw new IncorrectPersistentClassException(Class of
type: + clazz.getName() + has no descriptor.);
+ //throw new IncorrectPersistentClassException(Class of
type: + clazz.getName() + has no descriptor.);
}
return descriptor ;
}
Index:
src/main/java/org/apache/jackrabbit/ocm/mapper/impl/AbstractMapperImpl.java
===
--- src/main/java/org/apache/jackrabbit/ocm/mapper/impl/AbstractMapperImpl.java
(revision 701632)
+++ src/main/java/org/apache/jackrabbit/ocm/mapper/impl/AbstractMapperImpl.java
(working copy)
@@ -200,7 +200,7 @@
public ClassDescriptor getClassDescriptorByClass(Class clazz) {
ClassDescriptor descriptor =
mappingDescriptor.getClassDescriptorByName(clazz.getName());
if (descriptor==null) {
- throw new IncorrectPersistentClassException(Class of
type: + clazz.getName() + has no descriptor.);
+ //throw new IncorrectPersistentClassException(Class of
type: + clazz.getName() + has no descriptor.);
}
return descriptor ;
}
OCM:The UUID of the collection elements changes on update.
--
Key: JCR-1784
URL: https://issues.apache.org/jira/browse/JCR-1784
Project: Jackrabbit
Issue Type: Bug
Components: jackrabbit-ocm
Affects Versions: 1.5
Reporter: Boni Gopalan
Assignee: Christophe Lombart
Fix For: 1.5
Attachments: JCR-1784.bonigopalan.patch
Original Estimate: 3h
Remaining Estimate: 3h
On ocm.update transaction, the Current implementation of
DefaultCollectionConverterImpl recreates the colleciton-element nodes if
there is no id field specificaiton. This is completely valid for majority of
the cases. But I came across a case where the colleciton element has a uuid
field. In this case also what is happening with the current implementation
is that it drops all the elements from the old collection-elements and
recreates the new ones. The major flip side is that now I am left with brand
new UUIDs. I think we should address the uniqueness characteristics
specified through UUID also while mapping colleciton elements.
I have a patch and a TestCase to verify the same. I have implemented it only
for the digester. If people feel the approach is right I will work out an
annotation based testcase as well. I do not think it is going to fail even
with annotations.
--
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-1784) OCM:The UUID of the collection elements changes on update.
[
https://issues.apache.org/jira/browse/JCR-1784?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12637177#action_12637177
]
clombart edited comment on JCR-1784 at 10/6/08 12:12 PM:
---
Your patch seems good but I'm wondering why you have modified the class
AbstractMapperImpl ( see [1]).
It works without this modification and we can leave the code as it is (throw an
exception is there is no descriptor).
Are you agree if we don't modify this class ?
[1] Index:
src/main/java/org/apache/jackrabbit/ocm/mapper/impl/AbstractMapperImpl.java
===
--- src/main/java/org/apache/jackrabbit/ocm/mapper/impl/AbstractMapperImpl.java
(revision 701632)
+++ src/main/java/org/apache/jackrabbit/ocm/mapper/impl/AbstractMapperImpl.java
(working copy)
@@ -200,7 +200,7 @@
public ClassDescriptor getClassDescriptorByClass(Class clazz) {
ClassDescriptor descriptor =
mappingDescriptor.getClassDescriptorByName(clazz.getName());
if (descriptor==null) {
- throw new IncorrectPersistentClassException(Class of
type: + clazz.getName() + has no descriptor.);
+ //throw new IncorrectPersistentClassException(Class of
type: + clazz.getName() + has no descriptor.);
}
return descriptor ;
}
was (Author: clombart):
Your patch seems good but I'm wondering why you have modified the class
AbstractMapperImpl ( see [1]).
It works without this modification and we can leave the code as it is (throw an
exception is there is no descriptor).
Are you agree if we don't modify this class ?
[1] Index:
src/main/java/org/apache/jackrabbit/ocm/mapper/impl/AbstractMapperImpl.java
===
--- src/main/java/org/apache/jackrabbit/ocm/mapper/impl/AbstractMapperImpl.java
(revision 701632)
+++ src/main/java/org/apache/jackrabbit/ocm/mapper/impl/AbstractMapperImpl.java
(working copy)
@@ -200,7 +200,7 @@
public ClassDescriptor getClassDescriptorByClass(Class clazz) {
ClassDescriptor descriptor =
mappingDescriptor.getClassDescriptorByName(clazz.getName());
if (descriptor==null) {
- throw new IncorrectPersistentClassException(Class of
type: + clazz.getName() + has no descriptor.);
+ //throw new IncorrectPersistentClassException(Class of
type: + clazz.getName() + has no descriptor.);
}
return descriptor ;
}
Index:
src/main/java/org/apache/jackrabbit/ocm/mapper/impl/AbstractMapperImpl.java
===
--- src/main/java/org/apache/jackrabbit/ocm/mapper/impl/AbstractMapperImpl.java
(revision 701632)
+++ src/main/java/org/apache/jackrabbit/ocm/mapper/impl/AbstractMapperImpl.java
(working copy)
@@ -200,7 +200,7 @@
public ClassDescriptor getClassDescriptorByClass(Class clazz) {
ClassDescriptor descriptor =
mappingDescriptor.getClassDescriptorByName(clazz.getName());
if (descriptor==null) {
- throw new IncorrectPersistentClassException(Class of
type: + clazz.getName() + has no descriptor.);
+ //throw new IncorrectPersistentClassException(Class of
type: + clazz.getName() + has no descriptor.);
}
return descriptor ;
}
OCM:The UUID of the collection elements changes on update.
--
Key: JCR-1784
URL: https://issues.apache.org/jira/browse/JCR-1784
Project: Jackrabbit
Issue Type: Bug
Components: jackrabbit-ocm
Affects Versions: 1.5
Reporter: Boni Gopalan
Assignee: Christophe Lombart
Fix For: 1.5
Attachments: JCR-1784.bonigopalan.patch
Original Estimate: 3h
Remaining Estimate: 3h
On ocm.update transaction, the Current implementation of
DefaultCollectionConverterImpl recreates the colleciton-element nodes if
there is no id field specificaiton. This is completely valid for majority of
the cases. But I came across a case where the colleciton element has a uuid
field. In this case also what is happening with the current implementation
is that it drops all the elements from the old collection-elements and
recreates the new ones. The major flip side is that now I am left with brand
new UUIDs. I think we should address the uniqueness characteristics
specified through UUID also while mapping colleciton elements.
I have a patch and a TestCase to verify the same. I have implemented it only
for the digester. If people feel the approach is right I will work out an
annotation based testcase as well. I do not think it is going to fail even
with annotations.
--
This message
[jira] Resolved: (JCR-1784) OCM:The UUID of the collection elements changes on update.
[ https://issues.apache.org/jira/browse/JCR-1784?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christophe Lombart resolved JCR-1784. - Resolution: Fixed The patch has been applied. thanks and well done ! it was a nice bug :-) I didn't modify the class AbstractMapperImpl. For me, this modification is not necessary. I also added unit tests for the annotation support. Let me know if something is wrong. OCM:The UUID of the collection elements changes on update. -- Key: JCR-1784 URL: https://issues.apache.org/jira/browse/JCR-1784 Project: Jackrabbit Issue Type: Bug Components: jackrabbit-ocm Affects Versions: 1.5 Reporter: Boni Gopalan Assignee: Christophe Lombart Fix For: 1.5 Attachments: JCR-1784.bonigopalan.patch Original Estimate: 3h Remaining Estimate: 3h On ocm.update transaction, the Current implementation of DefaultCollectionConverterImpl recreates the colleciton-element nodes if there is no id field specificaiton. This is completely valid for majority of the cases. But I came across a case where the colleciton element has a uuid field. In this case also what is happening with the current implementation is that it drops all the elements from the old collection-elements and recreates the new ones. The major flip side is that now I am left with brand new UUIDs. I think we should address the uniqueness characteristics specified through UUID also while mapping colleciton elements. I have a patch and a TestCase to verify the same. I have implemented it only for the digester. If people feel the approach is right I will work out an annotation based testcase as well. I do not think it is going to fail even with annotations. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Vote : Add Boni Gopalan to Jackrabbit committers (mainly for the OCM subproject)
Hi all, it is time to consider adding a new contributor to commit status for Jackrabbit OCM. I hereby nominate Boni Gopalan on the basis of his sustained interest, quality of work, and desire to contribute to the OCM project on a long-term basis. Indeed, he is using the OCM project in his own project and he is really interested to join the team. Please vote with your +1 for yes, +0 for abstain, or -1 (not at this time). Naturally, only the votes coming from PMC and Jackrabbit committers currently listed on our project status page will be counted as binding. Best regards, Christophe Lombart Here is my vote : +1
Re: Vote : Add Boni Gopalan to Jackrabbit committers (mainly for the OCM subproject)
ok I'm sorry. On Mon, Oct 6, 2008 at 22:00, Jukka Zitting [EMAIL PROTECTED] wrote: Hi, On Mon, Oct 6, 2008 at 9:54 PM, Christophe Lombart [EMAIL PROTECTED] wrote: it is time to consider adding a new contributor to commit status for Jackrabbit OCM. Typically we conduct personnel votes in private within the Jackrabbit PMC. I suggest that we move this vote to [EMAIL PROTECTED] BR, Jukka Zitting
[jira] Commented: (JCR-1777) OCM:Test Cases that describe how to use OCM with with Spring Dependency Injection
[ https://issues.apache.org/jira/browse/JCR-1777?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12635313#action_12635313 ] Christophe Lombart commented on JCR-1777: - We have also started a subproject for the OCM Spring support. I have no time to work on that but you are welcome to review it. It should be nice to work on it and than move it outside the sandbox. I think it is better to have a nother OCM subproject instead of a Spring dependency on the main OCM project. see on http://svn.apache.org/viewvc/jackrabbit/sandbox/jackrabbit-jcr-mapping/spring/. It is based on Spring Module which already provide a JCR support. What do you think about that ? OCM:Test Cases that describe how to use OCM with with Spring Dependency Injection -- Key: JCR-1777 URL: https://issues.apache.org/jira/browse/JCR-1777 Project: Jackrabbit Issue Type: Test Components: jackrabbit-ocm Affects Versions: 1.5 Reporter: Boni Gopalan Fix For: 1.5 Attachments: JCR-1777.bonigopalan.patch I have written two test cases that describe how to integrate and test OCM with Spring framework. As part of this change I added to bases Test Classes (AnnotationDigester) that overrides the Repository initialization part of the AbstractTestBase. Currently the test cases are for Atomic Fields. I have used the exact tests we are running now for Atomic. I will submit the patch. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (JCR-1762) Improvement to MultiValueCollectionConverterImpl to Map collections with element class Object.class
[
https://issues.apache.org/jira/browse/JCR-1762?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12635225#action_12635225
]
Christophe Lombart commented on JCR-1762:
-
Now it works on my machine with the updated patch - thanks
I have reviewed your patch and I'm wondering why you have modified the class
AbstractMapperImpl with that change :
@@ -198,7 +200,7 @@
public ClassDescriptor getClassDescriptorByClass(Class clazz) {
ClassDescriptor descriptor =
mappingDescriptor.getClassDescriptorByName(clazz.getName());
if (descriptor==null) {
- throw new IncorrectPersistentClassException(Class of
type: + clazz.getName() + has no descriptor.);
+ //throw new IncorrectPersistentClassException(Class of
type: + clazz.getName() + has no descriptor.);
}
return descriptor ;
}
If we keep the old code, your patch is still working.
Improvement to MultiValueCollectionConverterImpl to Map collections with
element class Object.class
---
Key: JCR-1762
URL: https://issues.apache.org/jira/browse/JCR-1762
Project: Jackrabbit
Issue Type: Improvement
Components: jackrabbit-ocm
Affects Versions: 1.5
Environment: Java 5 and Up
Reporter: Boni Gopalan
Assignee: Christophe Lombart
Priority: Minor
Attachments: JCR-1762-updated.patch, JCR-1762.patch, testresults.txt
Original Estimate: 3h
Remaining Estimate: 3h
Currently MultiValueCollectionConverterImpl does not support elements of
type Object.class. The type of the contained class has to be specified
either through the mapping file or through the Bean annotation. Even with
that flexibility Object.class is specifically excluded (For good reasons.).
My view is that by definition MultiValueCollectionConverterImpl should make
a best effort to convert and that best effort should include using Undefined
UndefinedTypeConverterImpl to convert an object when all the other conversion
strategies run out. To this resolve I have patched the OCM source. I have
test cases also. I will upload the patch files right after.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Resolved: (JCR-1762) Improvement to MultiValueCollectionConverterImpl to Map collections with element class Object.class
[ https://issues.apache.org/jira/browse/JCR-1762?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christophe Lombart resolved JCR-1762. - Resolution: Fixed Fix Version/s: 1.5 The patch has been applied - Thanks for your contribution. Improvement to MultiValueCollectionConverterImpl to Map collections with element class Object.class --- Key: JCR-1762 URL: https://issues.apache.org/jira/browse/JCR-1762 Project: Jackrabbit Issue Type: Improvement Components: jackrabbit-ocm Affects Versions: 1.5 Environment: Java 5 and Up Reporter: Boni Gopalan Assignee: Christophe Lombart Priority: Minor Fix For: 1.5 Attachments: JCR-1762-updated.patch, JCR-1762.patch, testresults.txt Original Estimate: 3h Remaining Estimate: 3h Currently MultiValueCollectionConverterImpl does not support elements of type Object.class. The type of the contained class has to be specified either through the mapping file or through the Bean annotation. Even with that flexibility Object.class is specifically excluded (For good reasons.). My view is that by definition MultiValueCollectionConverterImpl should make a best effort to convert and that best effort should include using Undefined UndefinedTypeConverterImpl to convert an object when all the other conversion strategies run out. To this resolve I have patched the OCM source. I have test cases also. I will upload the patch files right after. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (JCR-966) [OCM] Add unit tests with BundleDbPersistenceManager
[ https://issues.apache.org/jira/browse/JCR-966?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christophe Lombart resolved JCR-966. Resolution: Fixed Fix Version/s: 1.5 We can close this issue because we are using org.apache.jackrabbit.core.persistence.bundle.DerbyPersistenceManager for a long time [OCM] Add unit tests with BundleDbPersistenceManager Key: JCR-966 URL: https://issues.apache.org/jira/browse/JCR-966 Project: Jackrabbit Issue Type: Improvement Components: jackrabbit-ocm Reporter: Christophe Lombart Priority: Minor Fix For: 1.5 Until now, we have not yet check the ocm framework with the BundleDbPersistenceManager -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (JCR-1776) Some unit tests are not well configured
Some unit tests are not well configured --- Key: JCR-1776 URL: https://issues.apache.org/jira/browse/JCR-1776 Project: Jackrabbit Issue Type: Bug Components: jackrabbit-ocm Affects Versions: 1.4 Reporter: Christophe Lombart Assignee: Christophe Lombart Fix For: 1.5 Some unit tests used for the annotation support are not well defined. There are inherited from DigesterTestBase instead of AnnotationTestBase -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (JCR-1759) Simplify the usage of OCM annotations
[ https://issues.apache.org/jira/browse/JCR-1759?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christophe Lombart resolved JCR-1759. - Resolution: Fixed Fix Version/s: 1.5 Now, it is simpler to define the mapping for abstract classes, inheritance tree and persistent classes that implement interfaces. See an example in the unit test: http://svn.apache.org/viewvc/jackrabbit/trunk/jackrabbit-ocm/src/test/java/org/apache/jackrabbit/ocm/testmodel/SimpleAnnotedAbstractClass.java http://svn.apache.org/viewvc/jackrabbit/trunk/jackrabbit-ocm/src/test/java/org/apache/jackrabbit/ocm/testmodel/SimpleAnnotedClass.java http://svn.apache.org/viewvc/jackrabbit/trunk/jackrabbit-ocm/src/test/java/org/apache/jackrabbit/ocm/testmodel/SimpleInterface.java Simplify the usage of OCM annotations - Key: JCR-1759 URL: https://issues.apache.org/jira/browse/JCR-1759 Project: Jackrabbit Issue Type: Improvement Components: jackrabbit-ocm Affects Versions: 1.5 Reporter: Christophe Lombart Assignee: Christophe Lombart Fix For: 1.5 If we are using more reflections during the OCM init phase (class descriptor loading), some OCM annotation settings are not necessary : @Node(isAbtract=true) : used to specify an abstract classes @Node(extend=) : used to specify the ancestor class @Node(isInterface= ...) : used to specify the entity as an interface @implement : used to specify the associated interfaces If this refactoring is done, we can set them as deprecated. The performances will not suffer because this is done only once during the application startup (when the ObjectContentManager is initialized). -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (JCR-1776) Some unit tests are not well configured
[ https://issues.apache.org/jira/browse/JCR-1776?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christophe Lombart resolved JCR-1776. - Resolution: Fixed Fixed. Some unit tests are not well configured --- Key: JCR-1776 URL: https://issues.apache.org/jira/browse/JCR-1776 Project: Jackrabbit Issue Type: Bug Components: jackrabbit-ocm Affects Versions: 1.4 Reporter: Christophe Lombart Assignee: Christophe Lombart Fix For: 1.5 Some unit tests used for the annotation support are not well defined. There are inherited from DigesterTestBase instead of AnnotationTestBase -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Assigned: (JCR-1762) Improvement to MultiValueCollectionConverterImpl to Map collections with element class Object.class
[ https://issues.apache.org/jira/browse/JCR-1762?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christophe Lombart reassigned JCR-1762: --- Assignee: Christophe Lombart Improvement to MultiValueCollectionConverterImpl to Map collections with element class Object.class --- Key: JCR-1762 URL: https://issues.apache.org/jira/browse/JCR-1762 Project: Jackrabbit Issue Type: Improvement Components: jackrabbit-ocm Affects Versions: 1.5 Environment: Java 5 and Up Reporter: Boni Gopalan Assignee: Christophe Lombart Priority: Minor Attachments: JCR-1762.patch Original Estimate: 3h Remaining Estimate: 3h Currently MultiValueCollectionConverterImpl does not support elements of type Object.class. The type of the contained class has to be specified either through the mapping file or through the Bean annotation. Even with that flexibility Object.class is specifically excluded (For good reasons.). My view is that by definition MultiValueCollectionConverterImpl should make a best effort to convert and that best effort should include using Undefined UndefinedTypeConverterImpl to convert an object when all the other conversion strategies run out. To this resolve I have patched the OCM source. I have test cases also. I will upload the patch files right after. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (JCR-1762) Improvement to MultiValueCollectionConverterImpl to Map collections with element class Object.class
[ https://issues.apache.org/jira/browse/JCR-1762?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12635148#action_12635148 ] Christophe Lombart commented on JCR-1762: - trying to apply the patch but I got a NullPointerException : java.lang.NullPointerException at org.apache.jackrabbit.ocm.manager.objectconverter.impl.ObjectConverterImpl.getPath(ObjectConverterImpl.java:612) at org.apache.jackrabbit.ocm.manager.impl.ObjectContentManagerImpl.insert(ObjectContentManagerImpl.java:388) at org.apache.jackrabbit.ocm.manager.collectionconverter.AnnotationMultiValueWithObjectCollectionConverterImplTest.checkMultiValue(AnnotationMultiValueWithObjectCollectionConverterImplTest.java:81) at org.apache.jackrabbit.ocm.manager.collectionconverter.AnnotationMultiValueWithObjectCollectionConverterImplTest.testMultiValue(AnnotationMultiValueWithObjectCollectionConverterImplTest.java:59) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at junit.framework.TestCase.runTest(TestCase.java:154) at junit.framework.TestCase.runBare(TestCase.java:127) at junit.framework.TestResult$1.protect(TestResult.java:106) at junit.framework.TestResult.runProtected(TestResult.java:124) at junit.framework.TestResult.run(TestResult.java:109) at junit.framework.TestCase.run(TestCase.java:118) at junit.framework.TestSuite.runTest(TestSuite.java:208) at junit.framework.TestSuite.run(TestSuite.java:203) at junit.extensions.TestDecorator.basicRun(TestDecorator.java:22) at junit.extensions.TestSetup$1.protect(TestSetup.java:19) at junit.framework.TestResult.runProtected(TestResult.java:124) at junit.extensions.TestSetup.run(TestSetup.java:23) at org.eclipse.jdt.internal.junit.runner.junit3.JUnit3TestReference.run(JUnit3TestReference.java:130) at org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38) at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:460) at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:673) at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:386) at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:196) Improvement to MultiValueCollectionConverterImpl to Map collections with element class Object.class --- Key: JCR-1762 URL: https://issues.apache.org/jira/browse/JCR-1762 Project: Jackrabbit Issue Type: Improvement Components: jackrabbit-ocm Affects Versions: 1.5 Environment: Java 5 and Up Reporter: Boni Gopalan Assignee: Christophe Lombart Priority: Minor Attachments: JCR-1762.patch Original Estimate: 3h Remaining Estimate: 3h Currently MultiValueCollectionConverterImpl does not support elements of type Object.class. The type of the contained class has to be specified either through the mapping file or through the Bean annotation. Even with that flexibility Object.class is specifically excluded (For good reasons.). My view is that by definition MultiValueCollectionConverterImpl should make a best effort to convert and that best effort should include using Undefined UndefinedTypeConverterImpl to convert an object when all the other conversion strategies run out. To this resolve I have patched the OCM source. I have test cases also. I will upload the patch files right after. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (JCR-1762) Improvement to MultiValueCollectionConverterImpl to Map collections with element class Object.class
[ https://issues.apache.org/jira/browse/JCR-1762?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12635149#action_12635149 ] Christophe Lombart commented on JCR-1762: - Maybe it is due to my latest changes. I will investigate later. Improvement to MultiValueCollectionConverterImpl to Map collections with element class Object.class --- Key: JCR-1762 URL: https://issues.apache.org/jira/browse/JCR-1762 Project: Jackrabbit Issue Type: Improvement Components: jackrabbit-ocm Affects Versions: 1.5 Environment: Java 5 and Up Reporter: Boni Gopalan Assignee: Christophe Lombart Priority: Minor Attachments: JCR-1762.patch Original Estimate: 3h Remaining Estimate: 3h Currently MultiValueCollectionConverterImpl does not support elements of type Object.class. The type of the contained class has to be specified either through the mapping file or through the Bean annotation. Even with that flexibility Object.class is specifically excluded (For good reasons.). My view is that by definition MultiValueCollectionConverterImpl should make a best effort to convert and that best effort should include using Undefined UndefinedTypeConverterImpl to convert an object when all the other conversion strategies run out. To this resolve I have patched the OCM source. I have test cases also. I will upload the patch files right after. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (JCR-1762) Improvement to MultiValueCollectionConverterImpl to Map collections with element class Object.class
[ https://issues.apache.org/jira/browse/JCR-1762?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12635157#action_12635157 ] Christophe Lombart commented on JCR-1762: - I have committed. You can update the project to get my changes. If you have no sufficient time I will review this problem tomorrow. thanks Improvement to MultiValueCollectionConverterImpl to Map collections with element class Object.class --- Key: JCR-1762 URL: https://issues.apache.org/jira/browse/JCR-1762 Project: Jackrabbit Issue Type: Improvement Components: jackrabbit-ocm Affects Versions: 1.5 Environment: Java 5 and Up Reporter: Boni Gopalan Assignee: Christophe Lombart Priority: Minor Attachments: JCR-1762.patch Original Estimate: 3h Remaining Estimate: 3h Currently MultiValueCollectionConverterImpl does not support elements of type Object.class. The type of the contained class has to be specified either through the mapping file or through the Bean annotation. Even with that flexibility Object.class is specifically excluded (For good reasons.). My view is that by definition MultiValueCollectionConverterImpl should make a best effort to convert and that best effort should include using Undefined UndefinedTypeConverterImpl to convert an object when all the other conversion strategies run out. To this resolve I have patched the OCM source. I have test cases also. I will upload the patch files right after. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (JCR-1721) make collection element names configureable
[ https://issues.apache.org/jira/browse/JCR-1721?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christophe Lombart resolved JCR-1721. - Resolution: Fixed Oh yes I'm stupid - I'm sorry for the noise. make collection element names configureable --- Key: JCR-1721 URL: https://issues.apache.org/jira/browse/JCR-1721 Project: Jackrabbit Issue Type: New Feature Components: jackrabbit-ocm Reporter: Oliver Lietz Assignee: Christophe Lombart Priority: Minor Fix For: 1.5 Attachments: jcrElementName.diff, jcrElementName.diff - add jcrElementName to CollectionDescriptor and Collection annotation - make COLLECTION_ELEMENT_NAME protected instead of private -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (JCR-1762) Improvement to MultiValueCollectionConverterImpl to Map collections with element class Object.class
[ https://issues.apache.org/jira/browse/JCR-1762?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12634406#action_12634406 ] Christophe Lombart commented on JCR-1762: - Hi Boni, Can you provide a patch instead of a full java classes. It will be easier to apply changes because I'm also working AnnotationDescriptorReader AbstractMapperImpl Thanks. Improvement to MultiValueCollectionConverterImpl to Map collections with element class Object.class --- Key: JCR-1762 URL: https://issues.apache.org/jira/browse/JCR-1762 Project: Jackrabbit Issue Type: Improvement Components: jackrabbit-ocm Affects Versions: 1.5 Environment: Java 5 and Up Reporter: Boni Gopalan Priority: Minor Attachments: JCR-1762-patch.zip Original Estimate: 3h Remaining Estimate: 3h Currently MultiValueCollectionConverterImpl does not support elements of type Object.class. The type of the contained class has to be specified either through the mapping file or through the Bean annotation. Even with that flexibility Object.class is specifically excluded (For good reasons.). My view is that by definition MultiValueCollectionConverterImpl should make a best effort to convert and that best effort should include using Undefined UndefinedTypeConverterImpl to convert an object when all the other conversion strategies run out. To this resolve I have patched the OCM source. I have test cases also. I will upload the patch files right after. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Assigned: (JCR-1754) The jackrabbit-ocm DTD 1.5 is missing and has to be publish
[ https://issues.apache.org/jira/browse/JCR-1754?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christophe Lombart reassigned JCR-1754: --- Assignee: Christophe Lombart The jackrabbit-ocm DTD 1.5 is missing and has to be publish Key: JCR-1754 URL: https://issues.apache.org/jira/browse/JCR-1754 Project: Jackrabbit Issue Type: Improvement Components: jackrabbit-ocm, jackrabbit-site Affects Versions: 1.5 Reporter: Christophe Lombart Assignee: Christophe Lombart The jackrabbit-ocm DTD 1.5 is missing and it should be made available for reference on the Jackrabbit web site. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (JCR-1754) The jackrabbit-ocm DTD 1.5 is missing and has to be publish
[ https://issues.apache.org/jira/browse/JCR-1754?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christophe Lombart resolved JCR-1754. - Resolution: Fixed Fix Version/s: 1.5 Thanks Jukka for the info. The OCM 1.5 has beed added into the website. It will available from http://jackrabbit.apache.org/dtd/ This may take some time before seeing it on the site. The jackrabbit-ocm DTD 1.5 is missing and has to be publish Key: JCR-1754 URL: https://issues.apache.org/jira/browse/JCR-1754 Project: Jackrabbit Issue Type: Improvement Components: jackrabbit-ocm, jackrabbit-site Affects Versions: 1.5 Reporter: Christophe Lombart Assignee: Christophe Lombart Fix For: 1.5 The jackrabbit-ocm DTD 1.5 is missing and it should be made available for reference on the Jackrabbit web site. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (JCR-1645) Add support for Map of referenced beans
[ https://issues.apache.org/jira/browse/JCR-1645?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12633751#action_12633751 ] Christophe Lombart commented on JCR-1645: - I'm agree with you but I don't see another solution based on a multi value property. Another solution is to use subnodes instead of a multivalue prop. Those subnodes can match to each element in the map. in each subnode, we can have a prop for the key (or use the subnode name) and another property for the reference value It is also a bit of hack due to the fact that is not possible to store a map of prop in a JCR node. Add support for Map of referenced beans --- Key: JCR-1645 URL: https://issues.apache.org/jira/browse/JCR-1645 Project: Jackrabbit Issue Type: New Feature Components: jackrabbit-ocm Reporter: Vincent Giguère Assignee: Christophe Lombart Fix For: 1.5 Attachments: BeanReferenceMapConverterImpl.java, BeanReferenceMapConverterImplTest.java, MapReferenceValueEncoder.java, MapReferenceValueEncoderTest.java OCM should support the mapping of maps of referenced beans. @Collection(collectionConverter= BeanReferenceCollectionConverterImpl.class) private java.util.MapString, ReferencedBean aMap; BeanReferenceCollectionConverterImpl (mainly the method doGetCollection) needs to be updated to support the interface ManageableMap interface. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (JCR-1759) Simplify the usage of OCM annotations
Simplify the usage of OCM annotations - Key: JCR-1759 URL: https://issues.apache.org/jira/browse/JCR-1759 Project: Jackrabbit Issue Type: Improvement Components: jackrabbit-ocm Affects Versions: 1.5 Reporter: Christophe Lombart If we are using more reflections during the OCM init phase (class descriptor loading), some OCM annotation settings are not necessary : @Node(isAbtract=true) : used to specify an abstract classes @Node(extend=) : used to specify the ancestor class @Node(isInterface= ...) : used to specify the entity as an interface @implement : used to specify the associated interfaces If this refactoring is done, we can set them as deprecated. The performances will not suffer because this is done only once during the application startup (when the ObjectContentManager is initialized). -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (JCR-1760) Review the OCM API and annotations to be more compliant with JPA
Review the OCM API and annotations to be more compliant with JPA Key: JCR-1760 URL: https://issues.apache.org/jira/browse/JCR-1760 Project: Jackrabbit Issue Type: Improvement Components: jackrabbit-ocm Affects Versions: 1.5 Reporter: Christophe Lombart It should be possible to start smoothly the JPA support. Of course, all JPA features are not necessary in the JCR world. For example, the annotations @Table and @Column are not very useful for OCM :-). Nevertheless, using almost the same API and a subset of the JPA annotations could be a great help for people who knows the JPA specification. Here is a list of changes that we can do quickly : - Rename the ObjecContentManager into EntityManager and review some method names. - Rename the OCM annotations : @Node = @Entity @Field = @Basic @Bean = @OneToOne @Collection = @OneToMany. Furthermore, @Collection is not a good name because it also supporting Maps :-) I would like to wait for the JPA query because the upcoming JPA spec will add more flexibility in this area. After, we can review in more details the JPA specification and see if there is a real interest to be more conform to this specification. What do you think about that ? Please, add your comments. thanks -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Assigned: (JCR-1758) Improvement to UndefinedTypeConverterImpl to map super types effectively
[ https://issues.apache.org/jira/browse/JCR-1758?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christophe Lombart reassigned JCR-1758: --- Assignee: Christophe Lombart Improvement to UndefinedTypeConverterImpl to map super types effectively Key: JCR-1758 URL: https://issues.apache.org/jira/browse/JCR-1758 Project: Jackrabbit Issue Type: Improvement Components: jackrabbit-ocm Environment: Any Java Version. Reporter: Boni Gopalan Assignee: Christophe Lombart Priority: Minor Fix For: 1.5 Attachments: UndefinedTypeConverterImpl.java Original Estimate: 1h Remaining Estimate: 1h Improvement to org.apache.jackrabbit.ocm.manager.atomictypeconverter.impl.UndefinedTypeConverterImpl's implementation of public Value getValue(ValueFactory valueFactory, Object propValue) , used equality check of class names to decide whether Object propValue is worthy of any attempt to map to an apropriate property. Since the purpose of the class is to provide a 'best effort' attempt to map an Object of type java.lang.Object it will be better to use 'instanceof'. This approach will convert the specific class as well as any inherited objects. For example using instanceof will let us map a BufferedInputStream, and any other sub classes of InputStream to a Binary Property. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (JCR-1758) Improvement to UndefinedTypeConverterImpl to map super types effectively
[ https://issues.apache.org/jira/browse/JCR-1758?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christophe Lombart resolved JCR-1758. - Resolution: Fixed the patch has been applied. Unit tests are working here. Thanks for the improvement. Let me know if something is wrong. Improvement to UndefinedTypeConverterImpl to map super types effectively Key: JCR-1758 URL: https://issues.apache.org/jira/browse/JCR-1758 Project: Jackrabbit Issue Type: Improvement Components: jackrabbit-ocm Environment: Any Java Version. Reporter: Boni Gopalan Assignee: Christophe Lombart Priority: Minor Fix For: 1.5 Attachments: UndefinedTypeConverterImpl.java Original Estimate: 1h Remaining Estimate: 1h Improvement to org.apache.jackrabbit.ocm.manager.atomictypeconverter.impl.UndefinedTypeConverterImpl's implementation of public Value getValue(ValueFactory valueFactory, Object propValue) , used equality check of class names to decide whether Object propValue is worthy of any attempt to map to an apropriate property. Since the purpose of the class is to provide a 'best effort' attempt to map an Object of type java.lang.Object it will be better to use 'instanceof'. This approach will convert the specific class as well as any inherited objects. For example using instanceof will let us map a BufferedInputStream, and any other sub classes of InputStream to a Binary Property. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Assigned: (JCR-1759) Simplify the usage of OCM annotations
[ https://issues.apache.org/jira/browse/JCR-1759?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christophe Lombart reassigned JCR-1759: --- Assignee: Christophe Lombart Simplify the usage of OCM annotations - Key: JCR-1759 URL: https://issues.apache.org/jira/browse/JCR-1759 Project: Jackrabbit Issue Type: Improvement Components: jackrabbit-ocm Affects Versions: 1.5 Reporter: Christophe Lombart Assignee: Christophe Lombart If we are using more reflections during the OCM init phase (class descriptor loading), some OCM annotation settings are not necessary : @Node(isAbtract=true) : used to specify an abstract classes @Node(extend=) : used to specify the ancestor class @Node(isInterface= ...) : used to specify the entity as an interface @implement : used to specify the associated interfaces If this refactoring is done, we can set them as deprecated. The performances will not suffer because this is done only once during the application startup (when the ObjectContentManager is initialized). -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (JCR-1645) Add support for Map of referenced beans
[ https://issues.apache.org/jira/browse/JCR-1645?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christophe Lombart resolved JCR-1645. - Resolution: Fixed Fix Version/s: 1.5 The patch has been applied. The unit tests are working. I modified the test content class Main otherwise it doesn't compile. Let me know if something is wrong. Thanks Add support for Map of referenced beans --- Key: JCR-1645 URL: https://issues.apache.org/jira/browse/JCR-1645 Project: Jackrabbit Issue Type: New Feature Components: jackrabbit-ocm Reporter: Vincent Giguère Assignee: Christophe Lombart Fix For: 1.5 Attachments: BeanReferenceMapConverterImpl.java, BeanReferenceMapConverterImplTest.java, MapReferenceValueEncoder.java, MapReferenceValueEncoderTest.java OCM should support the mapping of maps of referenced beans. @Collection(collectionConverter= BeanReferenceCollectionConverterImpl.class) private java.util.MapString, ReferencedBean aMap; BeanReferenceCollectionConverterImpl (mainly the method doGetCollection) needs to be updated to support the interface ManageableMap interface. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Assigned: (JCR-1752) Allow users to disable validation
[
https://issues.apache.org/jira/browse/JCR-1752?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Christophe Lombart reassigned JCR-1752:
---
Assignee: Christophe Lombart
Allow users to disable validation
-
Key: JCR-1752
URL: https://issues.apache.org/jira/browse/JCR-1752
Project: Jackrabbit
Issue Type: Improvement
Components: jackrabbit-ocm
Reporter: Stephane Landelle
Assignee: Christophe Lombart
Priority: Minor
Original Estimate: 0.08h
Remaining Estimate: 0.08h
DigesterMapperImpl leaves validating set to default true when creating a
DigesterDescriptorReader.
But as the dtd is not available anywhere (published or in the source), it is
usually not declared in mapping files, and DigesterDescriptorReader complains
about it.
Could it be possible to leave the user a way to configure the validation? The
simpliest way would be to add this constructor to DigesterMapperImpl :
public DigesterMapperImpl(InputStream[] streams, boolean validate) {
descriptorReader = new DigesterDescriptorReader(streams);
DigesterDescriptorReader.class.cast(descriptorReader).setValidating(validate);
this.buildMapper();
}
Best regard,
Stephane Landelle
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Created: (JCR-1754) The jackrabbit-ocm DTD 1.5 is missing and has to be publish
The jackrabbit-ocm DTD 1.5 is missing and has to be publish Key: JCR-1754 URL: https://issues.apache.org/jira/browse/JCR-1754 Project: Jackrabbit Issue Type: Improvement Components: jackrabbit-ocm, jackrabbit-site Affects Versions: 1.5 Reporter: Christophe Lombart The jackrabbit-ocm DTD 1.5 is missing and it should be made available for reference on the Jackrabbit web site. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (JCR-1752) Allow users to disable validation
[
https://issues.apache.org/jira/browse/JCR-1752?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Christophe Lombart resolved JCR-1752.
-
Resolution: Fixed
Fix Version/s: 1.5
I just added your patch. I also create a new jira issue, see JCR-1754, for
creating for OCM 1.5 DTD.
Allow users to disable validation
-
Key: JCR-1752
URL: https://issues.apache.org/jira/browse/JCR-1752
Project: Jackrabbit
Issue Type: Improvement
Components: jackrabbit-ocm
Reporter: Stephane Landelle
Assignee: Christophe Lombart
Priority: Minor
Fix For: 1.5
Original Estimate: 0.08h
Remaining Estimate: 0.08h
DigesterMapperImpl leaves validating set to default true when creating a
DigesterDescriptorReader.
But as the dtd is not available anywhere (published or in the source), it is
usually not declared in mapping files, and DigesterDescriptorReader complains
about it.
Could it be possible to leave the user a way to configure the validation? The
simpliest way would be to add this constructor to DigesterMapperImpl :
public DigesterMapperImpl(InputStream[] streams, boolean validate) {
descriptorReader = new DigesterDescriptorReader(streams);
DigesterDescriptorReader.class.cast(descriptorReader).setValidating(validate);
this.buildMapper();
}
Best regard,
Stephane Landelle
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Assigned: (JCR-1505) Improve handling of inherited mixins
[
https://issues.apache.org/jira/browse/JCR-1505?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Christophe Lombart reassigned JCR-1505:
---
Assignee: Christophe Lombart
Improve handling of inherited mixins
Key: JCR-1505
URL: https://issues.apache.org/jira/browse/JCR-1505
Project: Jackrabbit
Issue Type: Improvement
Components: jackrabbit-ocm
Affects Versions: 1.4
Reporter: Duncan McIntyre
Assignee: Christophe Lombart
Priority: Minor
If an abstract class is annotated with a mixin type, the annotation must be
repeated in concrete classes.
E.g.
@Node(jcrMixinTypes=mix:referenceable, isAbstract=true)
public abstract class Content {
...
...}
/**
* This class will not be referenceable
**/
@Node(extend=Content.class)
public class Page extends Content {
...
...
}
/**
* But this one will
**/
@Node(extend=Content.class, jcrMixinTypes=mix:referenceable)
public class Folder extends Content {
...
...
}
It would be nice if the annotation was inherited by default.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Resolved: (JCR-1505) Improve handling of inherited mixins
[
https://issues.apache.org/jira/browse/JCR-1505?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Christophe Lombart resolved JCR-1505.
-
Resolution: Fixed
Fix Version/s: 1.5
With the current head, this problem is solved. I added unit tests for this use
case.
Improve handling of inherited mixins
Key: JCR-1505
URL: https://issues.apache.org/jira/browse/JCR-1505
Project: Jackrabbit
Issue Type: Improvement
Components: jackrabbit-ocm
Affects Versions: 1.4
Reporter: Duncan McIntyre
Assignee: Christophe Lombart
Priority: Minor
Fix For: 1.5
If an abstract class is annotated with a mixin type, the annotation must be
repeated in concrete classes.
E.g.
@Node(jcrMixinTypes=mix:referenceable, isAbstract=true)
public abstract class Content {
...
...}
/**
* This class will not be referenceable
**/
@Node(extend=Content.class)
public class Page extends Content {
...
...
}
/**
* But this one will
**/
@Node(extend=Content.class, jcrMixinTypes=mix:referenceable)
public class Folder extends Content {
...
...
}
It would be nice if the annotation was inherited by default.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Resolved: (JCR-876) ManageableCollectionUtil should not throw unsupported JcrMapping exception
[
https://issues.apache.org/jira/browse/JCR-876?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Christophe Lombart resolved JCR-876.
Resolution: Fixed
Fix Version/s: 1.5
solved by the resolution of JCR-1325
ManageableCollectionUtil should not throw unsupported JcrMapping exception
Key: JCR-876
URL: https://issues.apache.org/jira/browse/JCR-876
Project: Jackrabbit
Issue Type: Improvement
Components: jackrabbit-ocm
Environment: All
Reporter: Dan Connelly
Fix For: 1.5
Many times, the object model'd code cannot be altered for ocm.
To avoid the unsupported exception in almost all such cases, use a
delegating wrapper class to encapsulate a Collection.The wrapper class
implements MaangeableCollection.
Since delegation is a performance hit, make the test below the last resort
for *object* conversion in the method:
public static ManageableCollection getManageableCollection(Object object)
Proposed catchall test and program action:
if (object instanceof Collection) {
return new ManageableCollectionImpl((Collection)object);
}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Resolved: (JCR-871) Provide Readme's for subprojects jcr-mapping and jcr-nodemanagement
[ https://issues.apache.org/jira/browse/JCR-871?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christophe Lombart resolved JCR-871. Resolution: Fixed Fix Version/s: 1.5 Readme files exist in both projects. Provide Readme's for subprojects jcr-mapping and jcr-nodemanagement --- Key: JCR-871 URL: https://issues.apache.org/jira/browse/JCR-871 Project: Jackrabbit Issue Type: Task Components: jackrabbit-ocm Reporter: Oliver Kießler Priority: Minor Fix For: 1.5 There need to be Readme files in each of the subprojects jcr-mapping and jcr-nodemanagement to provide some information about the scope of the subproject, building and hints on how to get started. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (JCR-1740) Make ObjectIterator implement RangeIterator interface
[ https://issues.apache.org/jira/browse/JCR-1740?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christophe Lombart resolved JCR-1740. - Resolution: Fixed The modified patch has been applied. I also prefer solution 1. The unit test is working here. Thanks for this patch Make ObjectIterator implement RangeIterator interface - Key: JCR-1740 URL: https://issues.apache.org/jira/browse/JCR-1740 Project: Jackrabbit Issue Type: Improvement Components: jackrabbit-ocm Affects Versions: 1.4 Environment: All environments Reporter: Sergey Nebolsin Priority: Minor Fix For: 1.5 Attachments: JCR-1740-solution1.patch, JCR-1740.patch Currently, it's not possible to skip a part of results returned in the form of ObjectIterator (for example, to implement db-like pagination feature with offset/max parameters). It would be great if ObjectIterator implement RangeIterator interface, and it's trivial enough since underlying NodeIterator implements this interface. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Assigned: (JCR-1645) Add support for Map of referenced beans
[ https://issues.apache.org/jira/browse/JCR-1645?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christophe Lombart reassigned JCR-1645: --- Assignee: Christophe Lombart Add support for Map of referenced beans --- Key: JCR-1645 URL: https://issues.apache.org/jira/browse/JCR-1645 Project: Jackrabbit Issue Type: New Feature Components: jackrabbit-ocm Reporter: Vincent Giguère Assignee: Christophe Lombart Attachments: BeanReferenceMapConverterImpl.java, BeanReferenceMapConverterImplTest.java, MapReferenceValueEncoder.java, MapReferenceValueEncoderTest.java OCM should support the mapping of maps of referenced beans. @Collection(collectionConverter= BeanReferenceCollectionConverterImpl.class) private java.util.MapString, ReferencedBean aMap; BeanReferenceCollectionConverterImpl (mainly the method doGetCollection) needs to be updated to support the interface ManageableMap interface. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (JCR-1645) Add support for Map of referenced beans
[ https://issues.apache.org/jira/browse/JCR-1645?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12633054#action_12633054 ] Christophe Lombart commented on JCR-1645: - I am working now on this issue but I got small compile errors. I will fix them. It should be nice to send us a patch instead of new or modified java classes. By this way, we can add new features quickly. Thanks Add support for Map of referenced beans --- Key: JCR-1645 URL: https://issues.apache.org/jira/browse/JCR-1645 Project: Jackrabbit Issue Type: New Feature Components: jackrabbit-ocm Reporter: Vincent Giguère Assignee: Christophe Lombart Attachments: BeanReferenceMapConverterImpl.java, BeanReferenceMapConverterImplTest.java, MapReferenceValueEncoder.java, MapReferenceValueEncoderTest.java OCM should support the mapping of maps of referenced beans. @Collection(collectionConverter= BeanReferenceCollectionConverterImpl.class) private java.util.MapString, ReferencedBean aMap; BeanReferenceCollectionConverterImpl (mainly the method doGetCollection) needs to be updated to support the interface ManageableMap interface. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (JCR-1721) make collection element names configureable
[ https://issues.apache.org/jira/browse/JCR-1721?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christophe Lombart resolved JCR-1721. - Resolution: Fixed Fix Version/s: 1.5 Patch has been applied. Thanks and sorry for the delay. Unit tests are working. I modified the content class Page to use a typed List. Let me know if something is wrong. make collection element names configureable --- Key: JCR-1721 URL: https://issues.apache.org/jira/browse/JCR-1721 Project: Jackrabbit Issue Type: New Feature Components: jackrabbit-ocm Reporter: Oliver Lietz Assignee: Christophe Lombart Priority: Minor Fix For: 1.5 Attachments: jcrElementName.diff, jcrElementName.diff - add jcrElementName to CollectionDescriptor and Collection annotation - make COLLECTION_ELEMENT_NAME protected instead of private -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: Hudson build is back to stable: Jackrabbit-ocm » Jackrabbit Object Content Mapping #118
ok thanks for the info and for your help Christophe On Sat, Sep 20, 2008 at 20:27, Jukka Zitting [EMAIL PROTECTED]wrote: Hi, On Fri, Sep 19, 2008 at 7:01 PM, Jukka Zitting [EMAIL PROTECTED] wrote: Something weird going on with the OCM build. Probably a Hudson issue, I'll look into it. I believe these weird build failures were caused by the newly added Jackrabbit-trunk-java14 build that, like the Jackrabbit-ocm build, is automatically triggered by a successful Jackrabbit-trunk build. With both builds running concurrently, it could be that the Jackrabbit-ocm build was trying to access a dependency jar from the Maven repository right when the Jackrabbit-trunk-java14 build was updating the jar. This would explain why the OCM build failed with a ClassNotFoundException on some very common Jackrabbit classes. I've now added a lock that prevents any two Jackrabbit builds from executing concurrently. This should avoid such race conditions. BR, Jukka Zitting
[jira] Commented: (JCR-1740) Make ObjectIterator implement RangeIterator interface
[ https://issues.apache.org/jira/browse/JCR-1740?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12632670#action_12632670 ] Christophe Lombart commented on JCR-1740: - Please add a unit test Make ObjectIterator implement RangeIterator interface - Key: JCR-1740 URL: https://issues.apache.org/jira/browse/JCR-1740 Project: Jackrabbit Issue Type: Improvement Components: jackrabbit-ocm Affects Versions: 1.4 Environment: All environments Reporter: Sergey Nebolsin Priority: Minor Fix For: 1.5 Attachments: JCR-1740.patch Currently, it's not possible to skip a part of results returned in the form of ObjectIterator (for example, to implement db-like pagination feature with offset/max parameters). It would be great if ObjectIterator implement RangeIterator interface, and it's trivial enough since underlying NodeIterator implements this interface. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (JCR-1740) Make ObjectIterator implement RangeIterator interface
[ https://issues.apache.org/jira/browse/JCR-1740?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christophe Lombart resolved JCR-1740. - Resolution: Fixed The patch has been applied - Thanks Let me know if something is wrong Make ObjectIterator implement RangeIterator interface - Key: JCR-1740 URL: https://issues.apache.org/jira/browse/JCR-1740 Project: Jackrabbit Issue Type: Improvement Components: jackrabbit-ocm Affects Versions: 1.4 Environment: All environments Reporter: Sergey Nebolsin Priority: Minor Fix For: 1.5 Attachments: JCR-1740.patch Currently, it's not possible to skip a part of results returned in the form of ObjectIterator (for example, to implement db-like pagination feature with offset/max parameters). It would be great if ObjectIterator implement RangeIterator interface, and it's trivial enough since underlying NodeIterator implements this interface. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (JCR-1721) make collection element names configureable
[ https://issues.apache.org/jira/browse/JCR-1721?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12632386#action_12632386 ] Christophe Lombart commented on JCR-1721: - Can you check the patch ? I cannot apply it on the head or on rev num 687290. Thanks make collection element names configureable --- Key: JCR-1721 URL: https://issues.apache.org/jira/browse/JCR-1721 Project: Jackrabbit Issue Type: New Feature Components: jackrabbit-ocm Reporter: Oliver Lietz Assignee: Christophe Lombart Priority: Minor Attachments: jcrElementName.diff - add jcrElementName to CollectionDescriptor and Collection annotation - make COLLECTION_ELEMENT_NAME protected instead of private -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Assigned: (JCR-1721) make collection element names configureable
[ https://issues.apache.org/jira/browse/JCR-1721?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christophe Lombart reassigned JCR-1721: --- Assignee: Christophe Lombart make collection element names configureable --- Key: JCR-1721 URL: https://issues.apache.org/jira/browse/JCR-1721 Project: Jackrabbit Issue Type: New Feature Components: jackrabbit-ocm Reporter: Oliver Lietz Assignee: Christophe Lombart Priority: Minor Attachments: jcrElementName.diff - add jcrElementName to CollectionDescriptor and Collection annotation - make COLLECTION_ELEMENT_NAME protected instead of private -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: OCM cahngelog file please!!! :)
Hi Alex, With Jira is easy to make some queries to follow all changes (all recent resolved issues/components, ...) . don't forget that current head is not a final release even if it is a good candidate for a upcoming release because the code looks like quite stable. Concerning the issue about the ocm_classname, you should know the problem from the beginning because you are the reporter ;-) : see on http://issues.apache.org/jira/browse/JCR-1467. Let me know if you see other problems around that. Could you please markup such darmatical changes in few words in some traditional text file like Changelog ? I think Jira is a better tools to see all the changes . PS. I'm developing multimedia web CMS based on latest SVN versions jackrabbit and OCM. As soon as it will be ready for real usage (not more then month) I'll publish it under Apache license. If comeone interested in such stuff, please do not hesitate to contact me at alukin hate-spammers-you-know-what-symbol-is-here gmail.com. I'm interested. is it possible to access to the code ? br, Christophe
[jira] Created: (JCR-1676) Add support for mapping all node properties into a Map
Add support for mapping all node properties into a Map --- Key: JCR-1676 URL: https://issues.apache.org/jira/browse/JCR-1676 Project: Jackrabbit Issue Type: New Feature Components: jackrabbit-ocm Affects Versions: 1.5 Reporter: Christophe Lombart Fix For: 1.5 For some use cases, it should be interesting to map all node properties into a single Map attribute. The map key can be the property name and of course the map value is the property value. This features require the implementation of a new CollectionConverter. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (JCR-1470) NPE in BeanReferenceCollectionConverterImpl on update on empty collection
[
https://issues.apache.org/jira/browse/JCR-1470?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Christophe Lombart resolved JCR-1470.
-
Resolution: Fixed
Fix Version/s: 1.5
Seems to be fixed.
NPE in BeanReferenceCollectionConverterImpl on update on empty collection
-
Key: JCR-1470
URL: https://issues.apache.org/jira/browse/JCR-1470
Project: Jackrabbit
Issue Type: Bug
Components: jackrabbit-ocm
Affects Versions: 1.5
Environment: mac os leopard, java5
Reporter: Stephane Landelle
Assignee: Christophe Lombart
Fix For: 1.5
use case :
in the same transaction :
*) retrieve an object that has a collection of references, yet empty
*) add an element in the collection
*) update the object
consequence :
org.apache.jackrabbit.ocm.exception.ObjectContentManagerException: Cannot
insert collection field : authors of class com.weka.content.api.model.Folder;
nested exception is java.lang.NullPointerException: null
java.lang.NullPointerException
at
org.apache.jackrabbit.ocm.manager.collectionconverter.impl.ManageableArrayList$$EnhancerByCGLIB$$8f15dde4.getSize(generated)
at
org.apache.jackrabbit.ocm.manager.collectionconverter.impl.BeanReferenceCollectionConverterImpl.addUuidProperties(BeanReferenceCollectionConverterImpl.java:154)
at
org.apache.jackrabbit.ocm.manager.collectionconverter.impl.BeanReferenceCollectionConverterImpl.doUpdateCollection(BeanReferenceCollectionConverterImpl.java:101)
The failing line is in addUuidProperties :
Value[] values = new Value[collection.getSize()];
It seems the CGlib enhanced collection fails and needs to be initialized
before.
For example, in doUpdateCollection, if I code :
// Delete existing values
if (parentNode.hasProperty(jcrName)) {
parentNode.setProperty(jcrName, (Value[]) null);
}
if (collection != null) {
collection.getSize();
}
I get a NPE on collection.getSize();
but if I code :
if (collection != null) {
collection.getSize();
}
// Delete existing values
if (parentNode.hasProperty(jcrName)) {
parentNode.setProperty(jcrName, (Value[]) null);
}
everything runs fine?!
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Resolved: (JCR-1448) nt:versionedChild problem
[
https://issues.apache.org/jira/browse/JCR-1448?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Christophe Lombart resolved JCR-1448.
-
Resolution: Fixed
Fix applied. Thanks
I also add a new unit test based on your example.
Let me know if something is wrong.
nt:versionedChild problem
-
Key: JCR-1448
URL: https://issues.apache.org/jira/browse/JCR-1448
Project: Jackrabbit
Issue Type: Bug
Components: jackrabbit-ocm
Affects Versions: 1.4
Reporter: Wes Smoak
Assignee: Christophe Lombart
Original Estimate: 0.5h
Remaining Estimate: 0.5h
Problem occurs when both parent and child beans are versionable. Jackrabbit
creates an nt:versionedChild node that is referenced by the parent node,
referencing the childs versionedHistory node of the child. The current OCM
code does not handle this correctly and produces an error: Node type
'nt:versionedChild' does not match descriptor node type 'nt:unstructured'
Below is a example code of the problem and a patch that appears to correctly
resolve the problem.
Within ObjectConverterImpl created the below method.
public Node getActualNode(Session session,Node node) throws
RepositoryException
{
NodeType type = node.getPrimaryNodeType();
if (type.getName().equals(nt:versionedChild))
{
String uuid =
node.getProperty(jcr:childVersionHistory).getValue().getString();
Node actualNode = session.getNodeByUUID(uuid);
String name = actualNode.getName();
actualNode = session.getNodeByUUID(name);
return actualNode;
}
return node;
}
AND modified the following to call the above method
public Object getObject(Session session, Class clazz, String path)
{
try {
if (!session.itemExists(path)) {
return null;
}
if (requestObjectCache.isCached(path))
{
return requestObjectCache.getObject(path);
}
ClassDescriptor classDescriptor =
getClassDescriptor(clazz);
checkNodeType(session, classDescriptor);
Node node = (Node) session.getItem(path);
if (!classDescriptor.isInterface()) {
{
node = getActualNode(session,node);
checkCompatiblePrimaryNodeTypes(session,
node, classDescriptor, true);
}
}
ClassDescriptor alternativeDescriptor = null;
if
(classDescriptor.usesNodeTypePerHierarchyStrategy())
{
if
(node.hasProperty(ManagerConstant.DISCRIMINATOR_PROPERTY_NAME))
{
String className =
node.getProperty(ManagerConstant.DISCRIMINATOR_PROPERTY_NAME
).getValue().getString();
alternativeDescriptor =
getClassDescriptor(ReflectionUtils.forName(className));
}
} else {
if
(classDescriptor.usesNodeTypePerConcreteClassStrategy())
{
String nodeType =
node.getPrimaryNodeType().getName();
if
(!nodeType.equals(classDescriptor.getJcrType()))
{
alternativeDescriptor =
classDescriptor.getDescendantClassDescriptor(nodeType);
// in case we an alternative
could not be found by walking
// the class descriptor
hierarchy, check whether we
would
// have a descriptor for the
node type directly (which
// may the case if the class
descriptor hierarchy is
// incomplete due to missing
configuration. See JCR-1145
// for details.
if (alternativeDescriptor ==
null) {
alternativeDescriptor =
mapper.getClassDescriptorByNodeType(nodeType);
}
}
}
}
// if we have an alternative class descriptor,
check whether its
[jira] Assigned: (JCR-1448) nt:versionedChild problem
[
https://issues.apache.org/jira/browse/JCR-1448?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Christophe Lombart reassigned JCR-1448:
---
Assignee: Christophe Lombart
nt:versionedChild problem
-
Key: JCR-1448
URL: https://issues.apache.org/jira/browse/JCR-1448
Project: Jackrabbit
Issue Type: Bug
Components: jackrabbit-ocm
Affects Versions: 1.4
Reporter: Wes Smoak
Assignee: Christophe Lombart
Original Estimate: 0.5h
Remaining Estimate: 0.5h
Problem occurs when both parent and child beans are versionable. Jackrabbit
creates an nt:versionedChild node that is referenced by the parent node,
referencing the childs versionedHistory node of the child. The current OCM
code does not handle this correctly and produces an error: Node type
'nt:versionedChild' does not match descriptor node type 'nt:unstructured'
Below is a example code of the problem and a patch that appears to correctly
resolve the problem.
Within ObjectConverterImpl created the below method.
public Node getActualNode(Session session,Node node) throws
RepositoryException
{
NodeType type = node.getPrimaryNodeType();
if (type.getName().equals(nt:versionedChild))
{
String uuid =
node.getProperty(jcr:childVersionHistory).getValue().getString();
Node actualNode = session.getNodeByUUID(uuid);
String name = actualNode.getName();
actualNode = session.getNodeByUUID(name);
return actualNode;
}
return node;
}
AND modified the following to call the above method
public Object getObject(Session session, Class clazz, String path)
{
try {
if (!session.itemExists(path)) {
return null;
}
if (requestObjectCache.isCached(path))
{
return requestObjectCache.getObject(path);
}
ClassDescriptor classDescriptor =
getClassDescriptor(clazz);
checkNodeType(session, classDescriptor);
Node node = (Node) session.getItem(path);
if (!classDescriptor.isInterface()) {
{
node = getActualNode(session,node);
checkCompatiblePrimaryNodeTypes(session,
node, classDescriptor, true);
}
}
ClassDescriptor alternativeDescriptor = null;
if
(classDescriptor.usesNodeTypePerHierarchyStrategy())
{
if
(node.hasProperty(ManagerConstant.DISCRIMINATOR_PROPERTY_NAME))
{
String className =
node.getProperty(ManagerConstant.DISCRIMINATOR_PROPERTY_NAME
).getValue().getString();
alternativeDescriptor =
getClassDescriptor(ReflectionUtils.forName(className));
}
} else {
if
(classDescriptor.usesNodeTypePerConcreteClassStrategy())
{
String nodeType =
node.getPrimaryNodeType().getName();
if
(!nodeType.equals(classDescriptor.getJcrType()))
{
alternativeDescriptor =
classDescriptor.getDescendantClassDescriptor(nodeType);
// in case we an alternative
could not be found by walking
// the class descriptor
hierarchy, check whether we
would
// have a descriptor for the
node type directly (which
// may the case if the class
descriptor hierarchy is
// incomplete due to missing
configuration. See JCR-1145
// for details.
if (alternativeDescriptor ==
null) {
alternativeDescriptor =
mapper.getClassDescriptorByNodeType(nodeType);
}
}
}
}
// if we have an alternative class descriptor,
check whether its
// extends (or is the same) as the requested class
[jira] Assigned: (JCR-1286) FilterImpl.getStringValue() does not use custom converter class specified in @Field annotation
[ https://issues.apache.org/jira/browse/JCR-1286?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christophe Lombart reassigned JCR-1286: --- Assignee: Christophe Lombart FilterImpl.getStringValue() does not use custom converter class specified in @Field annotation -- Key: JCR-1286 URL: https://issues.apache.org/jira/browse/JCR-1286 Project: Jackrabbit Issue Type: Bug Components: jackrabbit-ocm Affects Versions: 1.4 Environment: jackrabbit-ocm-1.4-20071210.145858-1 java version 1.5.0_13 Reporter: Paul Mietz Egli Assignee: Christophe Lombart I have a POJO with the following field: @Field(converter = LocaleConverter.class) private Localelocale; When I attempt to query for objects based on this field, I get a NullPointerException: java.lang.NullPointerException at org.apache.jackrabbit.ocm.query.impl.FilterImpl.getStringValue(FilterImpl.java:281) at org.apache.jackrabbit.ocm.query.impl.FilterImpl.addEqualTo(FilterImpl.java:129) FilterImpl should preferentially use the atomic type converter defined in the @Field annotation to convert the value, then fallback to the global converters. Converting the Locale to a string for use in the query is a workaround, but the logic for string conversion should only reside in my LocaleConverter class. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (JCR-1286) FilterImpl.getStringValue() does not use custom converter class specified in @Field annotation
[ https://issues.apache.org/jira/browse/JCR-1286?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christophe Lombart resolved JCR-1286. - Resolution: Fixed Fix Version/s: 1.5 From now, the Filter is using the converter if it is specified in the mapping definition. Let me know if something is wrong Thanks FilterImpl.getStringValue() does not use custom converter class specified in @Field annotation -- Key: JCR-1286 URL: https://issues.apache.org/jira/browse/JCR-1286 Project: Jackrabbit Issue Type: Bug Components: jackrabbit-ocm Affects Versions: 1.4 Environment: jackrabbit-ocm-1.4-20071210.145858-1 java version 1.5.0_13 Reporter: Paul Mietz Egli Assignee: Christophe Lombart Fix For: 1.5 I have a POJO with the following field: @Field(converter = LocaleConverter.class) private Localelocale; When I attempt to query for objects based on this field, I get a NullPointerException: java.lang.NullPointerException at org.apache.jackrabbit.ocm.query.impl.FilterImpl.getStringValue(FilterImpl.java:281) at org.apache.jackrabbit.ocm.query.impl.FilterImpl.addEqualTo(FilterImpl.java:129) FilterImpl should preferentially use the atomic type converter defined in the @Field annotation to convert the value, then fallback to the global converters. Converting the Locale to a string for use in the query is a workaround, but the logic for string conversion should only reside in my LocaleConverter class. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Assigned: (JCR-1537) ClassDescriptor.hasIdField() fails if id is declared in upper class
[
https://issues.apache.org/jira/browse/JCR-1537?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Christophe Lombart reassigned JCR-1537:
---
Assignee: Christophe Lombart
ClassDescriptor.hasIdField() fails if id is declared in upper class
---
Key: JCR-1537
URL: https://issues.apache.org/jira/browse/JCR-1537
Project: Jackrabbit
Issue Type: Bug
Components: jackrabbit-ocm
Affects Versions: 1.5
Environment: Mac OS X, JVM 1.5
Reporter: Stephane Landelle
Assignee: Christophe Lombart
Attachments: jackrabbit-ocm.patch
Original Estimate: 0.02h
Remaining Estimate: 0.02h
org.apache.jackrabbit.ocm.mapper.model.ClassDescriptor.hasIdField() looks up
only current class and not the whole hierarchy, so it fails when the id field
is declared in a upper class.
hasIdField should use getIdFieldDescriptor and not access idFieldDescriptor
field directly, as follows :
public boolean hasIdField() {
return (this.getIdFieldDescriptor() != null this
.getIdFieldDescriptor().isId());
}
Please find patch enclosed.
Sincerely yours,
Stéphane Landelle
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Resolved: (JCR-1537) ClassDescriptor.hasIdField() fails if id is declared in upper class
[
https://issues.apache.org/jira/browse/JCR-1537?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Christophe Lombart resolved JCR-1537.
-
Resolution: Fixed
Fix Version/s: 1.5
Patch applied - Thanks
Let me know if something is wrong
ClassDescriptor.hasIdField() fails if id is declared in upper class
---
Key: JCR-1537
URL: https://issues.apache.org/jira/browse/JCR-1537
Project: Jackrabbit
Issue Type: Bug
Components: jackrabbit-ocm
Affects Versions: 1.5
Environment: Mac OS X, JVM 1.5
Reporter: Stephane Landelle
Assignee: Christophe Lombart
Fix For: 1.5
Attachments: jackrabbit-ocm.patch
Original Estimate: 0.02h
Remaining Estimate: 0.02h
org.apache.jackrabbit.ocm.mapper.model.ClassDescriptor.hasIdField() looks up
only current class and not the whole hierarchy, so it fails when the id field
is declared in a upper class.
hasIdField should use getIdFieldDescriptor and not access idFieldDescriptor
field directly, as follows :
public boolean hasIdField() {
return (this.getIdFieldDescriptor() != null this
.getIdFieldDescriptor().isId());
}
Please find patch enclosed.
Sincerely yours,
Stéphane Landelle
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Resolved: (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 ] Christophe Lombart resolved JCR-1043. - Resolution: Fixed Fix Version/s: 1.5 The Spring support looks better thanks to the work made by Pradraic Sebastien. I have also review the project : - Use OCM annotations for the unit test - Migrate to junit 4 - Simplify the Spring config file upgrade to the latest version. - Update to the latest Spring module version for the JCR support - Remove the nodetypes which are not necessary from OCM 1.5 snapshot Let me know if something is wrong 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 Environment: All environments Reporter: Padraic Hannon Assignee: Christophe Lombart Priority: Minor Fix For: 1.5 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.
Re: OCM - Hudson
On Sun, May 11, 2008 at 6:29 PM, Jukka Zitting [EMAIL PROTECTED] wrote: PS. See http://wiki.apache.org/general/Hudson for instructions if you (or any other Jackrabbit committer) are interested in directly managing Hudson. ok thanks for the info. Just for the info, I will add a deploy maven goal . br, Christophe
Re: OCM 5min tutorial build error
You have to update the file repository-derby.xml file. There was some
modifications in the latest jackrabbit snapshots.
I will update the tutorial code today.
Thanks for the info.
br
Christophe
On Tue, May 6, 2008 at 9:12 AM, paksegu [EMAIL PROTECTED] wrote:
Hi,
I was trying out the 5mins tutorial in netbeans 6 and I have the
following error also i couldnt run the first hop sucessfully though i have
been able to that a couple months ago. what could be the problem?
Building jar:
C:\serenadeN2\target\jackrabbit-ocm-tutorial-5minutes-1.5-SNAPSHOT.jar
Preparing exec:java
No goals needed for project - skipping
[exec:java]
Register the repository ...
[ERROR]BUILD ERROR
null
Configuration element SecurityManager not found in Security.
For more information, run Maven with the -e switch
Total time: 2 seconds
Finished at: Tue May 06 02:57:46 EDT 2008
Final Memory: 96M/160M
Ransford Segu-Baffoe
[EMAIL PROTECTED]
https://serenade.dev.java.net/
http://www.noqturnalmediasystems.com/
-
Be a better friend, newshound, and know-it-all with Yahoo! Mobile. Try it
now.
?xml version=1.0?
!--
Licensed to the Apache Software Foundation (ASF) under one or more
contributor license agreements. See the NOTICE file distributed with
this work for additional information regarding copyright ownership.
The ASF licenses this file to You under the Apache License, Version 2.0
(the License); you may not use this file except in compliance with
the License. You may obtain a copy of the License at
http://www.apache.org/licenses/LICENSE-2.0
Unless required by applicable law or agreed to in writing, software
distributed under the License is distributed on an AS IS BASIS,
WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
See the License for the specific language governing permissions and
limitations under the License.
--
!DOCTYPE Repository PUBLIC -//The Apache Software Foundation//DTD Jackrabbit 1.5//EN
http://jackrabbit.apache.org/dtd/repository-1.5.dtd;
!-- Example Repository Configuration File
Used by
- org.apache.jackrabbit.core.config.RepositoryConfigTest.java
-
--
Repository
!--
virtual file system where the repository stores global state
(e.g. registered namespaces, custom node types, etc.)
--
FileSystem class=org.apache.jackrabbit.core.fs.local.LocalFileSystem
param name=path value=${rep.home}/repository/
/FileSystem
!--
security configuration
--
Security appName=Jackrabbit
!--
security manager:
class: FQN of class implementing the JackrabbitSecurityManager interface
--
SecurityManager class=org.apache.jackrabbit.core.security.simple.SimpleSecurityManager workspaceName=security
!--
workspace access:
class: FQN of class implementing the WorkspaceAccessManager interface
--
!-- WorkspaceAccessManager class=.../ --
!-- param name=config value=${rep.home}/security.xml/ --
/SecurityManager
!--
access manager:
class: FQN of class implementing the AccessManager interface
--
AccessManager class=org.apache.jackrabbit.core.security.simple.SimpleAccessManager
!-- param name=config value=${rep.home}/access.xml/ --
/AccessManager
LoginModule class=org.apache.jackrabbit.core.security.simple.SimpleLoginModule
!-- anonymous user id --
param name=anonymousId value=anonymous/
!-- administrator user id (default value if param is missing is 'admin') --
param name=adminId value=admin/
!--
default user name to be used instead of the anonymous user
when no login credentials are provided (unset by default)
--
!-- param name=defaultUserId value=superuser/ --
/LoginModule
/Security
!--
location of workspaces root directory and name of default workspace
--
Workspaces rootPath=${rep.home}/workspaces defaultWorkspace=default/
!--
workspace configuration template:
used to create the initial workspace if there's no workspace yet
--
Workspace name=${wsp.name}
!--
virtual file system of the workspace:
class: FQN of class implementing the FileSystem interface
--
FileSystem class=org.apache.jackrabbit.core.fs.local.LocalFileSystem
param name=path
OCM - Hudson
Jukka, Can you help me to add Jackrabbit OCM Jackrabbit OCM node management into Hudson ? Thanks, Christophe
Re: OCM: is project alive?
Hi Alex, I'm still using OCM here but there are some problems with the SVN Apache server. So, I will commit as soon as possible. I don't know if other projects are using it. It should be nice to have this kind of information. Last week, I made some simplifications on how to manage Collection and Map. Now, I'm reviewing the Spring support thanks to the work made by others. I'm going to add more tutorials, more code simplifications and bug fix in the upcoming weeks. After that, it will be the good time to work on a cache support and maybe see the possibilities to support JPA (at least for the main annotations like @Entity and a part of the API). Feel free to suggest simplifications. If you add them into Jira, I will take them in account. Patch are also welcome. Nevertheless, we need more committers on this project. Sorry for the compile error, I will check it. I'm busy with other activities. I will ask to Jukka if it is possible to add OCM into Hudson. br, Christophe On Thu, May 1, 2008 at 8:01 AM, Alex Lukin [EMAIL PROTECTED] wrote: Hi, All! There's no commits in jackrabbit-ocm package for a long time and it does not compile after commit of jackrabbit security classes. Fix is trivial but question is not in fixing code. I'm starting another jackrabit-based project with OCM and I'd like to know what is going on with project. Is OCM still supported? Will it be fully integrated in jackrabbit build and release system? Are developers still in the team? I ought to say that OCM is very important part of jackrabbit project because it simplifies and speeds up development and just makes life easier. BTW, there's another implementation of OCM called JCROM ( http://code.google.com/p/jcrom/) that moves forward very quickly, easier and better documented, but I just do not want use different implementations in my projects. -- SY, Alex Lukin RIPE NIC HDL: LEXA1-RIPE
[jira] Assigned: (JCR-1470) NPE in BeanReferenceCollectionConverterImpl on update on empty collection
[
https://issues.apache.org/jira/browse/JCR-1470?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Christophe Lombart reassigned JCR-1470:
---
Assignee: Christophe Lombart
NPE in BeanReferenceCollectionConverterImpl on update on empty collection
-
Key: JCR-1470
URL: https://issues.apache.org/jira/browse/JCR-1470
Project: Jackrabbit
Issue Type: Bug
Components: jackrabbit-ocm
Affects Versions: 1.5
Environment: mac os leopard, java5
Reporter: Stephane Landelle
Assignee: Christophe Lombart
use case :
in the same transaction :
*) retrieve an object that has a collection of references, yet empty
*) add an element in the collection
*) update the object
consequence :
org.apache.jackrabbit.ocm.exception.ObjectContentManagerException: Cannot
insert collection field : authors of class com.weka.content.api.model.Folder;
nested exception is java.lang.NullPointerException: null
java.lang.NullPointerException
at
org.apache.jackrabbit.ocm.manager.collectionconverter.impl.ManageableArrayList$$EnhancerByCGLIB$$8f15dde4.getSize(generated)
at
org.apache.jackrabbit.ocm.manager.collectionconverter.impl.BeanReferenceCollectionConverterImpl.addUuidProperties(BeanReferenceCollectionConverterImpl.java:154)
at
org.apache.jackrabbit.ocm.manager.collectionconverter.impl.BeanReferenceCollectionConverterImpl.doUpdateCollection(BeanReferenceCollectionConverterImpl.java:101)
The failing line is in addUuidProperties :
Value[] values = new Value[collection.getSize()];
It seems the CGlib enhanced collection fails and needs to be initialized
before.
For example, in doUpdateCollection, if I code :
// Delete existing values
if (parentNode.hasProperty(jcrName)) {
parentNode.setProperty(jcrName, (Value[]) null);
}
if (collection != null) {
collection.getSize();
}
I get a NPE on collection.getSize();
but if I code :
if (collection != null) {
collection.getSize();
}
// Delete existing values
if (parentNode.hasProperty(jcrName)) {
parentNode.setProperty(jcrName, (Value[]) null);
}
everything runs fine?!
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Assigned: (JCR-1548) Several bugs in last SVN commit
[
https://issues.apache.org/jira/browse/JCR-1548?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Christophe Lombart reassigned JCR-1548:
---
Assignee: Christophe Lombart
Several bugs in last SVN commit
---
Key: JCR-1548
URL: https://issues.apache.org/jira/browse/JCR-1548
Project: Jackrabbit
Issue Type: Bug
Components: security
Reporter: Stephane Landelle
Assignee: Christophe Lombart
Fix For: 1.5
Original Estimate: 0.08h
Remaining Estimate: 0.08h
Just a few bugs in the last SVN commit, but since I work with it, i thought
useful to mention them :
1) org.apache.jackrabbit.ocm.reflection.ReflectionUtils should handle Set --
just add it in defaultImplementation
2) in
org.apache.jackrabbit.ocm.manager.collectionconverter.ManageableObjectsUtil.getManageableObjects,
correct defaultImplementation test :
if (defaultImplementation == null)
{
throw new JcrMappingException(No default
implementation for the interface + manageableObjectsClass);
Thank you and keep up the good work!
Sincerely yours,
Stephane
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (JCR-1548) Several bugs in last SVN commit
[
https://issues.apache.org/jira/browse/JCR-1548?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Christophe Lombart updated JCR-1548:
Component/s: (was: security)
jackrabbit-ocm
Several bugs in last SVN commit
---
Key: JCR-1548
URL: https://issues.apache.org/jira/browse/JCR-1548
Project: Jackrabbit
Issue Type: Bug
Components: jackrabbit-ocm
Reporter: Stephane Landelle
Assignee: Christophe Lombart
Fix For: 1.5
Original Estimate: 0.08h
Remaining Estimate: 0.08h
Just a few bugs in the last SVN commit, but since I work with it, i thought
useful to mention them :
1) org.apache.jackrabbit.ocm.reflection.ReflectionUtils should handle Set --
just add it in defaultImplementation
2) in
org.apache.jackrabbit.ocm.manager.collectionconverter.ManageableObjectsUtil.getManageableObjects,
correct defaultImplementation test :
if (defaultImplementation == null)
{
throw new JcrMappingException(No default
implementation for the interface + manageableObjectsClass);
Thank you and keep up the good work!
Sincerely yours,
Stephane
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Resolved: (JCR-1548) Several bugs in last SVN commit
[
https://issues.apache.org/jira/browse/JCR-1548?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Christophe Lombart resolved JCR-1548.
-
Resolution: Fixed
Fixed. Thanks.
Let me know if something is wrong.
Several bugs in last SVN commit
---
Key: JCR-1548
URL: https://issues.apache.org/jira/browse/JCR-1548
Project: Jackrabbit
Issue Type: Bug
Components: jackrabbit-ocm
Reporter: Stephane Landelle
Assignee: Christophe Lombart
Fix For: 1.5
Original Estimate: 0.08h
Remaining Estimate: 0.08h
Just a few bugs in the last SVN commit, but since I work with it, i thought
useful to mention them :
1) org.apache.jackrabbit.ocm.reflection.ReflectionUtils should handle Set --
just add it in defaultImplementation
2) in
org.apache.jackrabbit.ocm.manager.collectionconverter.ManageableObjectsUtil.getManageableObjects,
correct defaultImplementation test :
if (defaultImplementation == null)
{
throw new JcrMappingException(No default
implementation for the interface + manageableObjectsClass);
Thank you and keep up the good work!
Sincerely yours,
Stephane
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Resolved: (JCR-1325) Problems mapping custom collections
[ https://issues.apache.org/jira/browse/JCR-1325?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christophe Lombart resolved JCR-1325. - Resolution: Fixed Fix Version/s: 1.5 Fixed. I also reviewed the support for Collection Map. The mapping definition can be simplified with parameterized classes. In this case the elementClassName setting is not necessary. There is a exemple in the unit tests (see the class org.apache.jackrabbit.ocm.testmodel.collection.Main). Major interfaces and classes are supported (Collection, List, ArrayList, Vector,Map, HashMap, ...) without creating extra code. In summary, there are3 different ways to define a collection or a Map : 1. With a parameterized class, it is not necessary to specify the elementClassName @Collection private ListElement list; 2. Without specifying the element type: in this case, this is mandatory to define the elementClassName @Collection (elementClassName=MyContent.class) private List list; 3. Create a descendant of ManageableCollection ManageableMap for complex collections or maps. elementClassName is still mandatory if the descendant is not parameterized. Problems mapping custom collections --- Key: JCR-1325 URL: https://issues.apache.org/jira/browse/JCR-1325 Project: Jackrabbit Issue Type: Bug Components: jackrabbit-ocm Affects Versions: 1.4 Reporter: Sebastian Gomez Assignee: Christophe Lombart Fix For: 1.5 Attachments: ManageableCollectionUtil.java.patch When using a custom list that extends from java.util.AbstractList, ManageableCollectionUtil.getManageableCollection raises a JcrMappingException because it does not consider the custom list to be a java.util.List. This is because it uses if (object.getClass().equals(List.class)) instead of if (object instanceof List). The same thing will probably happen when using a custom Collection, a custom ArrayList, etc. This is the stack trace: org.apache.jackrabbit.ocm.exception.JcrMappingException: Unsupported collection type : *** (MyCustomList class) at org.apache.jackrabbit.ocm.manager.collectionconverter.ManageableColle ctionUtil.getManageableCollection(ManageableCollectionUtil.java:153) at org.apache.jackrabbit.ocm.manager.objectconverter.impl.ObjectConverte rImpl.insertCollectionFields(ObjectConverterImpl.java:780) at org.apache.jackrabbit.ocm.manager.objectconverter.impl.ObjectConverte rImpl.insert(ObjectConverterImpl.java:221) at org.apache.jackrabbit.ocm.manager.objectconverter.impl.ObjectConverte rImpl.insert(ObjectConverterImpl.java:146) at org.apache.jackrabbit.ocm.manager.impl.ObjectContentManagerImpl.inser t(ObjectContentManagerImpl.java:407) I have come up to this bug using a MyCustomListMyClass, with MyCustomList extending java.util.AbstractListMyClass. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (JCR-1528) CLONE -ManageableCollectionUtil doesn't support Maps
CLONE -ManageableCollectionUtil doesn't support Maps
Key: JCR-1528
URL: https://issues.apache.org/jira/browse/JCR-1528
Project: Jackrabbit
Issue Type: Bug
Components: jackrabbit-ocm
Affects Versions: 1.4
Reporter: Christophe Lombart
ManageableCollectionUtil has two getManageableCollection methods, which do not
currently return a ManageableCollection which wraps Maps.
ManagedHashMap already exists in the codebase which I assume was created for
this purpose, so both getManageableCollection methods could be modified so that
they do something like:
if (object instanceof Map){
return new ManagedHashMap((Map)object);
}
An alternative solution might be to modify the JCR mapping to support
explicitly defining the 'ManagedXXX' class.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Closed: (JCR-1498) ManageableCollectionUtil should support Map and HashMap
[
https://issues.apache.org/jira/browse/JCR-1498?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Christophe Lombart closed JCR-1498.
---
Resolution: Duplicate
Fix Version/s: 1.5
Duplicate of 1339
ManageableCollectionUtil should support Map and HashMap
---
Key: JCR-1498
URL: https://issues.apache.org/jira/browse/JCR-1498
Project: Jackrabbit
Issue Type: Bug
Components: jackrabbit-ocm
Affects Versions: 1.5
Reporter: Stephane Landelle
Fix For: 1.5
Original Estimate: 0.08h
Remaining Estimate: 0.08h
ManageableCollectionUtil doesn't supports Map and HashMap.
just add :
if (collectionClass.equals(Map.class) ||
collectionClass.equals(HashMap.class)) {
return new ManagedHashMap();
}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (JCR-1339) ManageableCollectionUtil doesn't support Maps
[
https://issues.apache.org/jira/browse/JCR-1339?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12587349#action_12587349
]
Christophe Lombart commented on JCR-1339:
-
This patch is not suffisiant because there is a bug in ManagedHashMap. The
method addObject uses the Object for the key and for the value.
We have to find a solution to set correctly the key.
ManageableCollectionUtil doesn't support Maps
-
Key: JCR-1339
URL: https://issues.apache.org/jira/browse/JCR-1339
Project: Jackrabbit
Issue Type: Bug
Components: jackrabbit-ocm
Affects Versions: 1.4
Reporter: Aidan O'Loan
Assignee: Christophe Lombart
Attachments: ManageableCollectionUtil_JCR-1339.txt
Original Estimate: 24h
Remaining Estimate: 24h
ManageableCollectionUtil has two getManageableCollection methods, which do
not currently return a ManageableCollection which wraps Maps.
ManagedHashMap already exists in the codebase which I assume was created for
this purpose, so both getManageableCollection methods could be modified so
that they do something like:
if (object instanceof Map){
return new ManagedHashMap((Map)object);
}
An alternative solution might be to modify the JCR mapping to support
explicitly defining the 'ManagedXXX' class.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
Re: OCM: path as primary key is questionable
Sorry for the delay. Here is a couple of comments On Tue, Mar 18, 2008 at 9:23 AM, Alex Lukin [EMAIL PROTECTED] wrote: Hi! Sunday 16 March 2008 22:32:55 Christophe Lombart написав: So question is: why not to use UUID as primary key for OCM? In my opinion it is only one reliable key in JCR. OCM code may just force all OCM nodes to have jcr:uuid property and relay on it. For me, this is not a good idea because UUID is not mandatory in JCR. OCM is not mandatory by JCR too but this fact does not stop you from development. :) UUID is mentioned many many times in JSR-170 so it is madatory in JCR but optional for some nodes you do not care of. Referencial integrity is not possible without UUID. Implementation of JCR is not possible without UUID. If you are using nt:unstructured type, this is not necessary to use UUID. Furthermore, you are forcing to apply the mixin type mix:referenceable to each node. Is it big deal? In your former implementation you forced ocm:discriminator mixin type for nodes with ugly type registration code. Other solutions are welcome to fix it, depending on your use cases, ocm:discriminator is not always mandatory (see in 1.5 snapshot). OCM supports inheritance and interfaces. In such situation, a discriminator is usefull. This is often used in ORM frameworks. Node with mix:referenceable is quite better because it forces referncial integrity of node and developer can be sure that references to OCM nodes will be OK. What's bad wiht it? Imagine I move some node from user's home to public area. All references made to this node before move will be OK after move. I never said that UUID is bad. I would like to keep it optional in OCM as it is in the JCR spec. That's all. If you want to use UUID in your pojos, that's possible with the current OCM implementation. I'm not sure this is a good idea for all use cases. I can tell you 5 uses cases where path is very questionable idea causing incosistences. Tell me one use case where UUID is bad. :) And by the way, UUID operations are 25-50% faster then path operations. Furthermore, UUID can be used as unique instance ID independent of node location. Fetching by UUID you can always return correct path for oubject. You can place object where you want. ocm.getObject(myUUID) is not suffisant ? PS. Dear Christophe! Please do not think I criticize your implementation because I don't like it. There's anotgher solutions but I use yours. I just want make it better. Unfortunately, it takes time to catch up with code and I can't send you patch right today to check idea with UUID. You are welcome. I do not feel at all attacked :-). That's very interesting to exchange ideas to improve the OCM framework. My current goal for a couple of month is not add new feature. I would like to simplify some aspects. So, all comments, patch, questions are welcome. In the same idea, there was a discussion on making the path optional : http://www.mail-archive.com/dev@jackrabbit.apache.org/msg09960.html Thanks, Christophe
