[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.
[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.
[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.
[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.
[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.
[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.
[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.
[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.
if
[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.
[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.
[jira] Assigned: (JCR-1467) Hide ugly repository init code for OCM
[ https://issues.apache.org/jira/browse/JCR-1467?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christophe Lombart reassigned JCR-1467: --- Assignee: Christophe Lombart Hide ugly repository init code for OCM -- Key: JCR-1467 URL: https://issues.apache.org/jira/browse/JCR-1467 Project: Jackrabbit Issue Type: New Feature Components: jackrabbit-ocm Environment: All Reporter: Alex Lukin Assignee: Christophe Lombart Fix For: 1.5 Attachments: jackrabbit-OCM-repoinit.patch Original Estimate: 1h Remaining Estimate: 1h Hide repository namespace registration and ocm:discriminator node type registration in implementation of OCM -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (JCR-1467) Hide ugly repository init code for OCM
[ https://issues.apache.org/jira/browse/JCR-1467?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christophe Lombart resolved JCR-1467. - Resolution: Fixed I made patch. Can you check it ? It is no longer necessary to use the ocm namespace and the ocm:discriminator mixin type. Here is a summary of the current situation : 1. If the jcr node type is map to only java class, it is always possible to find the class name to instantiate. So, a discriminator (an extra property which will contains the class name) is not necessary. 2. if the same node type is mapped to different java classes, we have different situations : a. If the class is mapped to the unstructured node type or a node type that gives you the possibility to add extra properties, OCM will create a new property ocm_classname. b. If it is not possible to add this property due to strong constrains in the corresponding node type, OCM will try to add the mixin type ocm:discriminator. Hide ugly repository init code for OCM -- Key: JCR-1467 URL: https://issues.apache.org/jira/browse/JCR-1467 Project: Jackrabbit Issue Type: New Feature Components: jackrabbit-ocm Environment: All Reporter: Alex Lukin Assignee: Christophe Lombart Fix For: 1.5 Attachments: jackrabbit-OCM-repoinit.patch Original Estimate: 1h Remaining Estimate: 1h Hide repository namespace registration and ocm:discriminator node type registration in implementation of OCM -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (JCR-1467) Hide ugly repository init code for OCM
[ https://issues.apache.org/jira/browse/JCR-1467?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12577787#action_12577787 ] Christophe Lombart commented on JCR-1467: - The full story : http://www.mail-archive.com/dev@jackrabbit.apache.org/msg11205.html Hide ugly repository init code for OCM -- Key: JCR-1467 URL: https://issues.apache.org/jira/browse/JCR-1467 Project: Jackrabbit Issue Type: New Feature Components: jackrabbit-ocm Environment: All Reporter: Alex Lukin Fix For: 1.5 Attachments: jackrabbit-OCM-repoinit.patch Original Estimate: 1h Remaining Estimate: 1h Hide repository namespace registration and ocm:discriminator node type registration in implementation of OCM -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Assigned: (JCR-1385) UUID field not populated when saving a new node
[
https://issues.apache.org/jira/browse/JCR-1385?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Christophe Lombart reassigned JCR-1385:
---
Assignee: Christophe Lombart
UUID field not populated when saving a new node
---
Key: JCR-1385
URL: https://issues.apache.org/jira/browse/JCR-1385
Project: Jackrabbit
Issue Type: Bug
Components: jackrabbit-ocm
Affects Versions: 1.4
Reporter: Xavier Coulon
Assignee: Christophe Lombart
In the following 'Article' class, there is are fields set to true for 'path'
and 'uuid' jcr properties.
The mixins for referencing (hence, support for UUID) are declared at the
@Node level of the class.
After saving the node with the ObjectContentManager, the uuid field is not
populated as it could be expected
@Node(jcrMixinTypes=mix:referenceable,mix:lockable,mix:versionable)
public class Article {
@Field(uuid=true)
private String id = null;
@Field(path=true)
private String path = null;
@Field
private String content = null;
... constructor, getters and setters
}
The full discussion is here :
http://www.nabble.com/OCM-issues-with-path-and-id-fields-%28annotations%29-tt15460625.html#a15460625
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Assigned: (JCR-1381) Path is not indexed when inserting a new node with SNS
[
https://issues.apache.org/jira/browse/JCR-1381?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Christophe Lombart reassigned JCR-1381:
---
Assignee: Christophe Lombart
Path is not indexed when inserting a new node with SNS
--
Key: JCR-1381
URL: https://issues.apache.org/jira/browse/JCR-1381
Project: Jackrabbit
Issue Type: Bug
Components: jackrabbit-ocm
Affects Versions: 1.4
Reporter: Xavier Coulon
Assignee: Christophe Lombart
Using Jackrabbit OCM, when inserting two nodes with the same path, the second
node's path is not indexed.
Both nodes have the same path, and a search by path retrieves the first node
only.
The node mapping included the following annotations:
@Node(jcrMixinTypes=mix:referenceable,mix:lockable,mix:versionable)
public class Article {
@Field(uuid=true)
private String id = null;
@Field(path=true)
private String path = null;
}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Resolved: (JCR-1381) Path is not indexed when inserting a new node with SNS
[
https://issues.apache.org/jira/browse/JCR-1381?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Christophe Lombart resolved JCR-1381.
-
Resolution: Fixed
I just fixed this issue. Can you check if it is ok for you ?
Now, the path is updated after calling the method insert.
Path is not indexed when inserting a new node with SNS
--
Key: JCR-1381
URL: https://issues.apache.org/jira/browse/JCR-1381
Project: Jackrabbit
Issue Type: Bug
Components: jackrabbit-ocm
Affects Versions: 1.4
Reporter: Xavier Coulon
Assignee: Christophe Lombart
Using Jackrabbit OCM, when inserting two nodes with the same path, the second
node's path is not indexed.
Both nodes have the same path, and a search by path retrieves the first node
only.
The node mapping included the following annotations:
@Node(jcrMixinTypes=mix:referenceable,mix:lockable,mix:versionable)
public class Article {
@Field(uuid=true)
private String id = null;
@Field(path=true)
private String path = null;
}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (JCR-1381) Path is not indexed when inserting a new node with SNS
[
https://issues.apache.org/jira/browse/JCR-1381?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Christophe Lombart updated JCR-1381:
Fix Version/s: 1.5
Path is not indexed when inserting a new node with SNS
--
Key: JCR-1381
URL: https://issues.apache.org/jira/browse/JCR-1381
Project: Jackrabbit
Issue Type: Bug
Components: jackrabbit-ocm
Affects Versions: 1.4
Reporter: Xavier Coulon
Assignee: Christophe Lombart
Fix For: 1.5
Using Jackrabbit OCM, when inserting two nodes with the same path, the second
node's path is not indexed.
Both nodes have the same path, and a search by path retrieves the first node
only.
The node mapping included the following annotations:
@Node(jcrMixinTypes=mix:referenceable,mix:lockable,mix:versionable)
public class Article {
@Field(uuid=true)
private String id = null;
@Field(path=true)
private String path = null;
}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Resolved: (JCR-1385) UUID field not populated when saving a new node
[
https://issues.apache.org/jira/browse/JCR-1385?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Christophe Lombart resolved JCR-1385.
-
Resolution: Fixed
Fix Version/s: 1.5
I just fixed this issue. Can you check if it is ok for you ?
Now, the uuid field is refreshed after calling the method insert or update.
UUID field not populated when saving a new node
---
Key: JCR-1385
URL: https://issues.apache.org/jira/browse/JCR-1385
Project: Jackrabbit
Issue Type: Bug
Components: jackrabbit-ocm
Affects Versions: 1.4
Reporter: Xavier Coulon
Assignee: Christophe Lombart
Fix For: 1.5
In the following 'Article' class, there is are fields set to true for 'path'
and 'uuid' jcr properties.
The mixins for referencing (hence, support for UUID) are declared at the
@Node level of the class.
After saving the node with the ObjectContentManager, the uuid field is not
populated as it could be expected
@Node(jcrMixinTypes=mix:referenceable,mix:lockable,mix:versionable)
public class Article {
@Field(uuid=true)
private String id = null;
@Field(path=true)
private String path = null;
@Field
private String content = null;
... constructor, getters and setters
}
The full discussion is here :
http://www.nabble.com/OCM-issues-with-path-and-id-fields-%28annotations%29-tt15460625.html#a15460625
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Assigned: (JCR-1336) Bug in duplicate mapping check
[
https://issues.apache.org/jira/browse/JCR-1336?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Christophe Lombart reassigned JCR-1336:
---
Assignee: Christophe Lombart
Bug in duplicate mapping check
--
Key: JCR-1336
URL: https://issues.apache.org/jira/browse/JCR-1336
Project: Jackrabbit
Issue Type: Bug
Components: jackrabbit-ocm
Affects Versions: 1.4
Reporter: Carsten Ziegeler
Assignee: Christophe Lombart
There is a bug in the MappingDescriptor for checking if a mapping for a node
type is already available. The following patch solves this problem:
Index:
/Users/cziegeler/Developer/workspaces/default/jackrabbit/jackrabbit-ocm/src/main/java/org/apache/jackrabbit/ocm/mapper/model/MappingDescriptor.java
===
---
/Users/cziegeler/Developer/workspaces/default/jackrabbit/jackrabbit-ocm/src/main/java/org/apache/jackrabbit/ocm/mapper/model/MappingDescriptor.java
(revision 614136)
+++
/Users/cziegeler/Developer/workspaces/default/jackrabbit/jackrabbit-ocm/src/main/java/org/apache/jackrabbit/ocm/mapper/model/MappingDescriptor.java
(working copy)
@@ -75,7 +75,7 @@
if (null != classDescriptor.getJcrType() !
.equals(classDescriptor.getJcrType())
!
ManagerConstant.NT_UNSTRUCTURED.equals(classDescriptor.getJcrType()))
{
- if
((classDescriptorsByNodeType.get(classDescriptor.getClassName()) != null)
+ if
((classDescriptorsByNodeType.get(classDescriptor.getJcrType()) != null)
classDescriptor.usesNodeTypePerConcreteClassStrategy()
)
{
log.warn(Duplicate classdescriptor for node type : +
classDescriptor.getJcrType());
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Resolved: (JCR-1336) Bug in duplicate mapping check
[
https://issues.apache.org/jira/browse/JCR-1336?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Christophe Lombart resolved JCR-1336.
-
Resolution: Fixed
Fix Version/s: 1.5
Patch applied. Thanks
Sorry for the delay. Can you check if it is ok for you ?
Bug in duplicate mapping check
--
Key: JCR-1336
URL: https://issues.apache.org/jira/browse/JCR-1336
Project: Jackrabbit
Issue Type: Bug
Components: jackrabbit-ocm
Affects Versions: 1.4
Reporter: Carsten Ziegeler
Assignee: Christophe Lombart
Fix For: 1.5
There is a bug in the MappingDescriptor for checking if a mapping for a node
type is already available. The following patch solves this problem:
Index:
/Users/cziegeler/Developer/workspaces/default/jackrabbit/jackrabbit-ocm/src/main/java/org/apache/jackrabbit/ocm/mapper/model/MappingDescriptor.java
===
---
/Users/cziegeler/Developer/workspaces/default/jackrabbit/jackrabbit-ocm/src/main/java/org/apache/jackrabbit/ocm/mapper/model/MappingDescriptor.java
(revision 614136)
+++
/Users/cziegeler/Developer/workspaces/default/jackrabbit/jackrabbit-ocm/src/main/java/org/apache/jackrabbit/ocm/mapper/model/MappingDescriptor.java
(working copy)
@@ -75,7 +75,7 @@
if (null != classDescriptor.getJcrType() !
.equals(classDescriptor.getJcrType())
!
ManagerConstant.NT_UNSTRUCTURED.equals(classDescriptor.getJcrType()))
{
- if
((classDescriptorsByNodeType.get(classDescriptor.getClassName()) != null)
+ if
((classDescriptorsByNodeType.get(classDescriptor.getJcrType()) != null)
classDescriptor.usesNodeTypePerConcreteClassStrategy()
)
{
log.warn(Duplicate classdescriptor for node type : +
classDescriptor.getJcrType());
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Assigned: (JCR-1398) [PATCH] ClassDescriptor.hasIdField uses faulty logic
[
https://issues.apache.org/jira/browse/JCR-1398?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Christophe Lombart reassigned JCR-1398:
---
Assignee: Christophe Lombart
[PATCH] ClassDescriptor.hasIdField uses faulty logic
Key: JCR-1398
URL: https://issues.apache.org/jira/browse/JCR-1398
Project: Jackrabbit
Issue Type: Bug
Components: jackrabbit-ocm
Affects Versions: 1.4
Reporter: Dave Brosius
Assignee: Christophe Lombart
Priority: Minor
Fix For: 1.4.1
Attachments: classdescriptor_isid.patch
hasIdField tries to compare a FieldDescriptor to an empty string, which
doesn't make sense, here:
public boolean hasIdField() {
return (this.idFieldDescriptor != null !
this.idFieldDescriptor.equals());
}
i'm assuming it should be
return (this.idFieldDescriptor != null
this.idFieldDescriptor.isId());
patch does this
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Assigned: (JCR-1316) ID Field Descriptor is not inherited as is the case with UUID Field Descriptor
[ https://issues.apache.org/jira/browse/JCR-1316?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christophe Lombart reassigned JCR-1316: --- Assignee: Christophe Lombart ID Field Descriptor is not inherited as is the case with UUID Field Descriptor -- Key: JCR-1316 URL: https://issues.apache.org/jira/browse/JCR-1316 Project: Jackrabbit Issue Type: Improvement Components: jackrabbit-ocm Affects Versions: 1.4 Reporter: Nimesh Muley Assignee: Christophe Lombart Fix For: 1.4.1 Attachments: InheritedIDFieldDescriptor.patch ID Field descriptor when defined in the base class in jcr-mapping is not inherited. The child class also has to define it again. A patch for the same is attached herewith. Patch is on similar lines of UUID Field Descriptor -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (JCR-1303) Missing derby dependency
[ https://issues.apache.org/jira/browse/JCR-1303?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12558789#action_12558789 ] Christophe Lombart commented on JCR-1303: - I dropped the derby dependency. Certainly a too long vacation. After an update, it works fine with 1.4 and head. Sorry to this issue. Missing derby dependency Key: JCR-1303 URL: https://issues.apache.org/jira/browse/JCR-1303 Project: Jackrabbit Issue Type: Bug Components: jackrabbit-ocm Affects Versions: 1.4 Reporter: Christophe Lombart Priority: Blocker Fix For: 1.5 the derby dependency is missing in the OCM subproject. So, the unit tests cannot be executed. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (JCR-1303) Missing derby dependency
[ https://issues.apache.org/jira/browse/JCR-1303?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12558455#action_12558455 ] Christophe Lombart commented on JCR-1303: - I don't find the cause of my problem. If I remove the derby depency from the OCM pom.xml, the unit tests don't work because mvn doesn't find derby. Any idea ? Here is the result of mvn dependency:resolve (Derby is not in the list). [EMAIL PROTECTED]:~/javaprojects/jackrabbit/jackrabbit-ocm$ mvn dependency:resolve [INFO] Scanning for projects... [INFO] Searching repository for plugin with prefix: 'dependency'. [INFO] [INFO] Building Jackrabbit Object Content Mapping [INFO]task-segment: [dependency:resolve] [INFO] [INFO] [dependency:resolve] [INFO] [INFO] The following files have been resolved: [INFO]asm:asm:jar:1.5.3 (scope = compile) [INFO]cglib:cglib:jar:2.1_3 (scope = compile) [INFO]commons-beanutils:commons-beanutils:jar:1.7.0 (scope = compile) [INFO]commons-collections:commons-collections:jar:3.1 (scope = compile) [INFO]commons-digester:commons-digester:jar:1.7 (scope = compile) [INFO]commons-lang:commons-lang:jar:2.1 (scope = compile) [INFO]commons-logging:commons-logging:jar:1.0 (scope = compile) [INFO]concurrent:concurrent:jar:1.3.4 (scope = test) [INFO]javax.jcr:jcr:jar:1.0 (scope = provided) [INFO]junit:junit:jar:3.8.1 (scope = test) [INFO]log4j:log4j:jar:1.2.13 (scope = test) [INFO]nekohtml:nekohtml:jar:0.9.4 (scope = test) [INFO]org.apache.geronimo.specs:geronimo-jta_1.0.1B_spec:jar:1.0.1 (scope = test) [INFO]org.apache.jackrabbit:jackrabbit-api:jar:1.5-SNAPSHOT (scope = test) [INFO]org.apache.jackrabbit:jackrabbit-core:jar:1.5-SNAPSHOT (scope = test) [INFO]org.apache.jackrabbit:jackrabbit-jcr-commons:jar:1.5-SNAPSHOT (scope = test) [INFO]org.apache.jackrabbit:jackrabbit-spi:jar:1.5-SNAPSHOT (scope = test) [INFO]org.apache.jackrabbit:jackrabbit-spi-commons:jar:1.5-SNAPSHOT (scope = test) [INFO]org.apache.jackrabbit:jackrabbit-text-extractors:jar:1.5-SNAPSHOT (scope = test) [INFO]org.apache.lucene:lucene-core:jar:2.2.0 (scope = test) [INFO]org.slf4j:slf4j-api:jar:1.3.0 (scope = compile) [INFO]org.slf4j:slf4j-log4j12:jar:1.3.0 (scope = test) [INFO]org.textmining:tm-extractors:jar:0.4 (scope = test) [INFO]pdfbox:pdfbox:jar:0.6.4 (scope = test) [INFO]poi:poi:jar:2.5.1-final-20040804 (scope = test) [INFO]xerces:xercesImpl:jar:2.8.1 (scope = test) [INFO]xml-apis:xml-apis:jar:1.0.b2 (scope = compile) Missing derby dependency Key: JCR-1303 URL: https://issues.apache.org/jira/browse/JCR-1303 Project: Jackrabbit Issue Type: Bug Components: jackrabbit-ocm Affects Versions: 1.4 Reporter: Christophe Lombart Priority: Blocker Fix For: 1.5 the derby dependency is missing in the OCM subproject. So, the unit tests cannot be executed. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (JCR-1303) Missing derby dependency
Missing derby dependency Key: JCR-1303 URL: https://issues.apache.org/jira/browse/JCR-1303 Project: Jackrabbit Issue Type: Bug Components: jackrabbit-ocm Affects Versions: 1.4 Reporter: Christophe Lombart Priority: Blocker the derby dependency is missing in the OCM subproject. So, the unit tests cannot be executed. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (JCR-1303) Missing derby dependency
[ https://issues.apache.org/jira/browse/JCR-1303?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christophe Lombart resolved JCR-1303. - Resolution: Fixed Fix Version/s: 1.5 Fixed in 1.5-snapshot. Do we have to fix it in the 1.4 branch ? Missing derby dependency Key: JCR-1303 URL: https://issues.apache.org/jira/browse/JCR-1303 Project: Jackrabbit Issue Type: Bug Components: jackrabbit-ocm Affects Versions: 1.4 Reporter: Christophe Lombart Priority: Blocker Fix For: 1.5 the derby dependency is missing in the OCM subproject. So, the unit tests cannot be executed. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (JCR-1303) Missing derby dependency
[ https://issues.apache.org/jira/browse/JCR-1303?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12557550#action_12557550 ] Christophe Lombart commented on JCR-1303: - Ha yes ! I'm just wondering why is not working on my machine. I'm going to check and remove my change. thanks Missing derby dependency Key: JCR-1303 URL: https://issues.apache.org/jira/browse/JCR-1303 Project: Jackrabbit Issue Type: Bug Components: jackrabbit-ocm Affects Versions: 1.4 Reporter: Christophe Lombart Priority: Blocker Fix For: 1.5 the derby dependency is missing in the OCM subproject. So, the unit tests cannot be executed. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (JCR-995) Release the OCM component
[ https://issues.apache.org/jira/browse/JCR-995?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12553820 ] Christophe Lombart commented on JCR-995: Yes I think so. I just made a small fix in the nodemanagement (pck change). I'm working with Sébastien Deleuze on the Spring integration. We will send the patch the Spring module team. So, it is not necessary to move the Spring subproject to the trunk. Release the OCM component - Key: JCR-995 URL: https://issues.apache.org/jira/browse/JCR-995 Project: Jackrabbit Issue Type: New Feature Reporter: Jukka Zitting Assignee: Jukka Zitting Priority: Blocker Fix For: 1.4 The contrib/jackrabbit-jcr-mapping/jcr-mapping should be promoted from contrib into a jackrabbit-jcr-ocm component. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
