[ http://opensource.atlassian.com/projects/hibernate/browse/METAGEN-54?page... ] Hardy Ferentschik commented on METAGEN-54: ------------------------------------------ Thanks Martijn, I'll have a look at your changes asap. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://opensource.atlassian.com/projects/hibernate/secure/Administrators.... - For more information on JIRA, see: http://www.atlassian.com/software/jira

[ http://opensource.atlassian.com/projects/hibernate/browse/METAGEN-54?page... ] Hardy Ferentschik resolved METAGEN-54. -------------------------------------- Resolution: Fixed Fix Version/s: 1.x -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://opensource.atlassian.com/projects/hibernate/secure/Administrators.... - For more information on JIRA, see: http://www.atlassian.com/software/jira

[ http://opensource.atlassian.com/projects/hibernate/browse/METAGEN-54?page... ] Hardy Ferentschik updated METAGEN-54: ------------------------------------- Description: I have a xml-only mapping with no target-entity attribute specified on collections. For the collections generics were used, so type information was available. The collections were not generated by the generator in the meta-model classes. I have checked out the current version of the source from Git and made the changes (testcases and solution). You find these files attached to this bugreport. It is not a very 'clean' solution yet, but I wanted to shared the bug and possible solution first. When I run maven just after checkout I had 4 failing testcases: * testAccessTypeForXmlConfiguredEmbeddables(org.hibernate.jpamodelgen.test.mixedmode.MixedConfigurationTest) * testDefaultAccessTypeApplied(org.hibernate.jpamodelgen.test.mixedmode.MixedConfigurationTest) * testExplicitXmlConfiguredAccessTypeApplied(org.hibernate.jpamodelgen.test.mixedmode.MixedConfigurationTest) * testMixedConfiguration(org.hibernate.jpamodelgen.test.mixedmode.MixedConfigurationTest) I still had these 4 failing testcase with my solution and I have not investigated this further. In my search for the answer (error in my mapping, incorrect understanding of the generator or a bug in the Generator) I found a couple of points I got confused about. First is that the access type on the XML entity was not set if it was specified only on the entity (not in the persistence unit default or on the collection itself). It then defaulted to METHOD (a.k.a. property access) In XmlMetaEntity (line 542) {code} return TypeUtils.getElementKindForAccessType( accessTypeInfo.getDefaultAccessType() ); {code} probably should be {code} return TypeUtils.getElementKindForAccessType( accessTypeInfo.getAccessType() ); {code} which was good because line 196 would lead the code to look for attributes (not methods) to compare to the property-name. If the element was not the same one as was expected, the loop would skip that element. This seemed strange to me. {code} if ( expectedElementKind.equals( elem.getKind() ) ) { continue; } {code} As I said, attached is my solution in which, I hope, will confirm to the JPA-specification ;-). Regards, Martijn Blankestijn was: I have a xml-only mapping with no target-entity attribute specified on collections. For the collections generics were used, so type information was available. The collections were not generated by the generator in the meta-model classes. I have checked out the current version of the source from Git and made the changes (testcases and solution). You find these files attached to this bugreport. It is not a very 'clean' solution yet, but I wanted to shared the bug and possible solution first. When I run maven just after checkout I had 4 failing testcases: * testAccessTypeForXmlConfiguredEmbeddables(org.hibernate.jpamodelgen.test.mixedmode.MixedConfigurationTest) * testDefaultAccessTypeApplied(org.hibernate.jpamodelgen.test.mixedmode.MixedConfigurationTest) * testExplicitXmlConfiguredAccessTypeApplied(org.hibernate.jpamodelgen.test.mixedmode.MixedConfigurationTest) * testMixedConfiguration(org.hibernate.jpamodelgen.test.mixedmode.MixedConfigurationTest) I still had these 4 failing testcase with my solution and I have not investigated this further. In my search for the answer (error in my mapping, incorrect understanding of the generator or a bug in the Generator) I found a couple of points I got confused about. First is that the access type on the XML entity was not set if it was specified only on the entity (not in the persistence unit default or on the collection itself). It then defaulted to METHOD (a.k.a. property access) In XmlMetaEntity (line 542) {code} return TypeUtils.getElementKindForAccessType( accessTypeInfo.getDefaultAccessType() ); {code} probably should be {code} return TypeUtils.getElementKindForAccessType( accessTypeInfo.getAccessType() ); {code} which was good because line 196 would lead the code to look for attributes (not methods) to compare to the property-name. If the element was not the same one as was expected, the loop would skip that element. This seemed strange to me. {code} if ( expectedElementKind.equals( elem.getKind() ) ) { continue; } {code} As I said, attached is my solution in which, I hope, will confirm to the JPA-specification ;-). Regards, Martijn Blankestijn -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://opensource.atlassian.com/projects/hibernate/secure/Administrators.... - For more information on JIRA, see: http://www.atlassian.com/software/jira

[ http://opensource.atlassian.com/projects/hibernate/browse/METAGEN-54?page... ] Fyrn Jilot commented on METAGEN-54: ----------------------------------- Useful [advice | http://customized-dog-collars.com/leather-dog-collars.html] -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira