[jira] Created: (GRFT-98) Archive links are broken on Mailing Lists page.
Archive links are broken on Mailing Lists page. --- Key: GRFT-98 URL: http://issues.apache.org/jira/browse/GRFT-98 Project: Graffito Issue Type: Bug Components: Documentation Reporter: Dan Connelly "The requested URL /mail/graffito-dev/ was not found on this server." -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (GRFT-99) ManageableCollectionUtil should not throw "unsupported" JcrMapping exception
ManageableCollectionUtil should not throw "unsupported" JcrMapping exception
Key: GRFT-99
URL: http://issues.apache.org/jira/browse/GRFT-99
Project: Graffito
Issue Type: Improvement
Components: JCR-Mapping
Affects Versions: 1.0-a1-dev
Environment: All
Reporter: Dan Connelly
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.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (GRFT-40) Advanced support for JCR properties and node
[ http://issues.apache.org/jira/browse/GRFT-40?page=comments#action_12434095 ] Dan Connelly commented on GRFT-40: -- Please increase the priority for implementation of the unsupported JCR PropertyTypes. I want Jackrabbit to enforce referential integrity through PropteryType.PATH and PropertyType.REFERENCE. If this csudrd a problem in Jackrabbit, yjrm I want to raise the Jackrabbit Jira over the Graffito implementation, not over my custom implementation. > Advanced support for JCR properties and node > > > Key: GRFT-40 > URL: http://issues.apache.org/jira/browse/GRFT-40 > Project: Graffito > Issue Type: Task > Components: JCR-Mapping >Reporter: Christophe Lombart > Fix For: 1.0-a1-dev > > > - We have to support the following JCR Types : >* PropertyType.NAME >* PropertyType.PATH >* PropertyType.REFERENCE >* PropertyType.UNDEFINED > - Map UUID and the path into the POJO object > - Check if mandatory & auto created properties are well managed. More unit > test are required. > - Support for same-name siblings : the query service should supported it ans > we have also to support the method : node.getNodes(nodepattern). We have > also to check if the insert, update and delete methods support correctly the > same-name sibling. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (GRFT-101) Allow developer to supply "newInstace" method in subclass of ObjectConverterImpl
Allow developer to supply "newInstace" method in subclass of ObjectConverterImpl
Key: GRFT-101
URL: http://issues.apache.org/jira/browse/GRFT-101
Project: Graffito
Issue Type: Improvement
Affects Versions: 1.0-a1-dev
Environment: JCR Mapping
Reporter: Dan Connelly
I used a simple change in ObjectConverterImpl. This allows me to use a
Factory class (in place of JavaBean constructors) in my object model.
I added the following method to ObjectConverterImpl.:
protected Object newInstance(String className) {
return ReflectionUtils.newInstance(className);
}
Elsewhere in ObjectConverterImpl, it will now invoke
this.newInstance(classDescriptor.getClassName());
every where that is previously invoked
ReflectionUtils.newInstance(classDescriptor.getClassName());
Now I can over-ride the newInstance method in MyObjectConverterImpl (which
subclasses ObjectConverterImpl). This allows me to construct objects for my
model using its Factory class.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (GRFT-101) Allow developer to supply "newInstace" method in subclass of ObjectConverterImpl
[
http://issues.apache.org/jira/browse/GRFT-101?page=comments#action_12434654 ]
Dan Connelly commented on GRFT-101:
---
Also, since collection may be an immutable (where collection cannot be set in
an object, but items in the existing collection can be aded and removed), a
similar hook in ObjectConverterImpl is needed to support an escape from having
ReflectionUtils attempt to forace a NEW collection instance into the object:
protected void setCollection(Object object, String fieldName,
ManageableCollection collection) {
ReflectionUtils.setNestedProperty(object, fieldName,
collection);
}
Then change collection setter in retrieveCollectionField method to:
this.setCollection(object, collectionDescriptor.getFieldName(),
collection);
> Allow developer to supply "newInstace" method in subclass of
> ObjectConverterImpl
>
>
> Key: GRFT-101
> URL: http://issues.apache.org/jira/browse/GRFT-101
> Project: Graffito
> Issue Type: Improvement
>Affects Versions: 1.0-a1-dev
> Environment: JCR Mapping
>Reporter: Dan Connelly
>
> I used a simple change in ObjectConverterImpl. This allows me to use a
> Factory class (in place of JavaBean constructors) in my object model.
> I added the following method to ObjectConverterImpl.:
>protected Object newInstance(String className) {
>return ReflectionUtils.newInstance(className);
>}
> Elsewhere in ObjectConverterImpl, it will now invoke
>this.newInstance(classDescriptor.getClassName());
> every where that is previously invoked
>ReflectionUtils.newInstance(classDescriptor.getClassName());
> Now I can over-ride the newInstance method in MyObjectConverterImpl (which
> subclasses ObjectConverterImpl). This allows me to construct objects for my
> model using its Factory class.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (GRFT-103) AtomicTypeConversion on retrieve omitted (fails) when NodeTypePerHierarchy && Discriminator
AtomicTypeConversion on retrieve omitted (fails) when NodeTypePerHierarchy && Discriminator --- Key: GRFT-103 URL: http://issues.apache.org/jira/browse/GRFT-103 Project: Graffito Issue Type: Bug Components: JCR-Mapping Reporter: Dan Connelly Priority: Critical ObjectConverterImpl#retrieveSimpleFields has this guard for one branch of its logic: for populating the retrieved object: if (classDescriptor.usesNodeTypePerHierarchyStrategy() && classDescriptor.hasDiscriminator()) When this test is true, then there is *no type conversion* on fields. The code attempts to set object field directly from the string, getValue().getString(), value for the node property. This fails for an "int" field mapped from the object. If I force this test the *false*, then the retrieve works and there is no failure. While it is not entirely clear to me how the inheritance maaping strategy is chosen or how it is implemented, it does not seem reasonable that the strategy selection should affect field conversions. In my code, the same mapping file is used for the write and the read whatever variations in mapping I choose. One variation I have tried is to remove all extend="" class attributes in the mapping. However, he inheritance strategy remained at NodeTypePerHiearchy and the retrieve continued to fail. BTW: The DTD comment says "extends" but the !ATTLIST requires it to be "extend". Confusing.Since "extend" is optional and not ambiguous, why would I ever want to provide it in the mapping? -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (GRFT-99) ManageableCollectionUtil should not throw "unsupported" JcrMapping exception
[
http://issues.apache.org/jira/browse/GRFT-99?page=comments#action_12436657 ]
Dan Connelly commented on GRFT-99:
--
Two things are needed to implement this fix:
1) A new class ManageableCollectionImpl (or ManageableCollectionWrapper
if you prefer.
Wraps any Collection under ManageableCollection interface.
2) A final test in ManageableCollectionUtil.getManageableCollection(Object
object) that returns the wrapped Collection
when object's own class is not directly a ManageableCollection.
I implemented this code in a local copy for myself at the same time that I
generated the JIRA.This has been working wiht no problems for lots of EMF
object model testing for 2 weeks.(But I do not have a simple JUnit for you.
Suggest you use a LinkedList in some object model.)
It should eliminate the exception in most case for arbitrary object models
where code is either not available or not easily changed.
Note: I did NOT mean that the "unsupported" exception should be removed
Just that it gets thrown when it really doesn't need to be. Keep throwing the
exception where object is not a Collection.
> ManageableCollectionUtil should not throw "unsupported" JcrMapping exception
>
>
> Key: GRFT-99
> URL: http://issues.apache.org/jira/browse/GRFT-99
> Project: Graffito
> Issue Type: Improvement
> Components: JCR-Mapping
>Affects Versions: 1.0-a1-dev
> Environment: All
>Reporter: Dan Connelly
>
> 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.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (GRFT-99) ManageableCollectionUtil should not throw "unsupported" JcrMapping exception
[
http://issues.apache.org/jira/browse/GRFT-99?page=comments#action_12436662 ]
Dan Connelly commented on GRFT-99:
--
Of course, the user will need to implement a custom CollectionConvert when his
object model as a Collection that is not a standard ManageableCollection. He
has to build his Collection by iterating on the ManageableCollection that is
supplied.
> ManageableCollectionUtil should not throw "unsupported" JcrMapping exception
>
>
> Key: GRFT-99
> URL: http://issues.apache.org/jira/browse/GRFT-99
> Project: Graffito
> Issue Type: Improvement
> Components: JCR-Mapping
>Affects Versions: 1.0-a1-dev
> Environment: All
>Reporter: Dan Connelly
>
> 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.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (GRFT-101) Allow developer to supply "newInstace" method in subclass of ObjectConverterImpl
[
http://issues.apache.org/jira/browse/GRFT-101?page=comments#action_12436668 ]
Dan Connelly commented on GRFT-101:
---
A proper patch just for this issue would take more] time than I have because I
have other changes in this code, particularly an implementation of REFERENCE
fields.I can within a few days submit a patch for the combined issues if
that is needed.
Actually for this JIRA, the code change is easy. No need to wait for a grand
patch.No new JUnits needed for this change.
Add the following methods to ObjectConverterImpl:
protected Object newInstance(String className) {
return ReflectionUtils.newInstance(className);
}
protected void setNestedProperty(Object object, String fieldName,
Object value) {
ReflectionUtils.setNestedProperty(object, fieldName, value);
}
Then modify ALL invocations of ReflectionUtils.newInstance and
ReflectionUtils.setNestedProperty in the code.
Make those invocations this.newInstance and this.setNestedProperty,
respectively.
> Allow developer to supply "newInstace" method in subclass of
> ObjectConverterImpl
>
>
> Key: GRFT-101
> URL: http://issues.apache.org/jira/browse/GRFT-101
> Project: Graffito
> Issue Type: Improvement
>Affects Versions: 1.0-a1-dev
> Environment: JCR Mapping
>Reporter: Dan Connelly
>
> I used a simple change in ObjectConverterImpl. This allows me to use a
> Factory class (in place of JavaBean constructors) in my object model.
> I added the following method to ObjectConverterImpl.:
>protected Object newInstance(String className) {
>return ReflectionUtils.newInstance(className);
>}
> Elsewhere in ObjectConverterImpl, it will now invoke
>this.newInstance(classDescriptor.getClassName());
> every where that is previously invoked
>ReflectionUtils.newInstance(classDescriptor.getClassName());
> Now I can over-ride the newInstance method in MyObjectConverterImpl (which
> subclasses ObjectConverterImpl). This allows me to construct objects for my
> model using its Factory class.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (GRFT-101) Allow developer to supply "newInstace" method in subclass of ObjectConverterImpl
[
http://issues.apache.org/jira/browse/GRFT-101?page=comments#action_12436669 ]
Dan Connelly commented on GRFT-101:
---
The setCollection method in a previous comment is not necessary. Its the same
as the setNestedProperty method.
> Allow developer to supply "newInstace" method in subclass of
> ObjectConverterImpl
>
>
> Key: GRFT-101
> URL: http://issues.apache.org/jira/browse/GRFT-101
> Project: Graffito
> Issue Type: Improvement
>Affects Versions: 1.0-a1-dev
> Environment: JCR Mapping
>Reporter: Dan Connelly
>
> I used a simple change in ObjectConverterImpl. This allows me to use a
> Factory class (in place of JavaBean constructors) in my object model.
> I added the following method to ObjectConverterImpl.:
>protected Object newInstance(String className) {
>return ReflectionUtils.newInstance(className);
>}
> Elsewhere in ObjectConverterImpl, it will now invoke
>this.newInstance(classDescriptor.getClassName());
> every where that is previously invoked
>ReflectionUtils.newInstance(classDescriptor.getClassName());
> Now I can over-ride the newInstance method in MyObjectConverterImpl (which
> subclasses ObjectConverterImpl). This allows me to construct objects for my
> model using its Factory class.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (GRFT-105) Allow custom ProxyManager
Allow custom ProxyManager - Key: GRFT-105 URL: http://issues.apache.org/jira/browse/GRFT-105 Project: Graffito Issue Type: Improvement Components: JCR-Mapping Reporter: Dan Connelly Kindly 1) Make ProxyManager an interface. 2) Provide a 3-arg consttructor for ObjectConverterImpl. Allow some ProxyManagerImpl as the 3rd arg. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (GRFT-106) Avoid INFINITE RECURSION when Object Model has cycles.
Avoid INFINITE RECURSION when Object Model has cycles. -- Key: GRFT-106 URL: http://issues.apache.org/jira/browse/GRFT-106 Project: Graffito Issue Type: Improvement Components: JCR-Mapping Reporter: Dan Connelly Priority: Critical The default ObjectConverterImpl is restricted to acyclic graphs in the object model. Many Java object models are NOT acyclic. For instance, I am on your Friends list. Yoar are on my Friends list. Java encourages such structures. Almost any large object model in Java will have hidden cycles. Saving an Object Model that contains cycles using Graffito causes an infinite recursion. Clearly, it is important to maintain a 1-to-1 correspondence between Nodes and Objects to prevent this. In the absence of Multiple Parent Nodes, it will be necessary to use REFERENCE or UNDEFINED Items in place of the 2nd (or greater) Node representing a given Object. My preference si that the default ObjectConverterImpl should support REFERENCE.,Failing this, use of UNDEFINED also solves this problem and would acceptable (as default). Whether or not REFERENCE is used, both insertion and retrieval must provide a reasonable result. A custom ojbect converter should be available to switch UNDEFINED to REFERENCE, or vice versa. Also, it is probably best to keep the targeted, well-defined Nodes close to the Root Node.This implies that the default ObjectConverterImpl should implement a Breadth-First, rather than a Depth-First, traversal of the Object Model on both insertion and retrieval. Again, if the default is Depth-First, a custom object converter should be available that implements Breadth-First. Admittedly, support for (2 representations) X (2 traversals) implies a drastic refactoring and/or rewriting of the ObjectConverterImpl class. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (GRFT-106) Avoid INFINITE RECURSION when Object Model has cycles.
[ http://issues.apache.org/jira/browse/GRFT-106?page=comments#action_12437212 ] Dan Connelly commented on GRFT-106: --- The use of UNDEFINED would also affect the selection of the default or custom ProxyManager. UNDEFINED Beans and collection Items might be translated to Proxies that execute a lookup based on some Path Conversion scheme. The Path Conversions could be either stored in the Repository or provided by a custom ProxyManager. > Avoid INFINITE RECURSION when Object Model has cycles. > -- > > Key: GRFT-106 > URL: http://issues.apache.org/jira/browse/GRFT-106 > Project: Graffito > Issue Type: Improvement > Components: JCR-Mapping >Reporter: Dan Connelly >Priority: Critical > > The default ObjectConverterImpl is restricted to acyclic graphs in the object > model. > Many Java object models are NOT acyclic. For instance, I am on your Friends > list. Yoar are on my Friends list. Java encourages such structures. > Almost any large object model in Java will have hidden cycles. > Saving an Object Model that contains cycles using Graffito causes an infinite > recursion. > Clearly, it is important to maintain a 1-to-1 correspondence between Nodes > and Objects to prevent this. In the absence of Multiple Parent Nodes, it > will be necessary to use REFERENCE or UNDEFINED Items in place of the 2nd (or > greater) Node representing a given Object. My preference si that the > default ObjectConverterImpl should support REFERENCE.,Failing this, use > of UNDEFINED also solves this problem and would acceptable (as default). > Whether or not REFERENCE is used, both insertion and retrieval must provide a > reasonable result. A custom ojbect converter should be available to switch > UNDEFINED to REFERENCE, or vice versa. > Also, it is probably best to keep the targeted, well-defined Nodes close to > the Root Node.This implies that the default ObjectConverterImpl should > implement a Breadth-First, rather than a Depth-First, traversal of the Object > Model on both insertion and retrieval. Again, if the default is > Depth-First, a custom object converter should be available that implements > Breadth-First. > Admittedly, support for (2 representations) X (2 traversals) implies a > drastic refactoring and/or rewriting of the ObjectConverterImpl class. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
