[ http://issues.apache.org/jira/browse/GRFT-103?page=all ]
Christophe Lombart reassigned GRFT-103: --------------------------------------- Assignee: Christophe Lombart > 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 > Assigned To: Christophe Lombart > 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="xxxx" 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