[ http://opensource.atlassian.com/projects/hibernate/browse/HHH-3439?page=c... ] Steve Ebersole commented on HHH-3439: ------------------------------------- I've been thinking about it as well ;) Its not Emmanuel. Mappings are constructed via the Configuration#createMappings. You (annotations) extend Configuration therefore in your theory you do have control over how Mappings are constructed. The issue is that that is not *really* the case because Mappings is a class with a very specific constructor; and since you also extend Mappings (you have to since the class itself is the contract rather than an interface) you must comply with that constructor signature. As I mentioned to you on IRC, I see 2 solutions as being viable: 1) Make Mappings an interface, and have an impl of that interface as a non-static inner class of Configuration giving it access to those collections directly on Configuration (the Collection on Mappings *are* the ones dirdctly from Configuration now anyway). Configuration extenders can then simply define a new Mappings class extending Configuration#MappingsImpl. Had we done that prior to adding fetch profiles, for example, there would have been no signature changes affecting your code here since all pertinent changes would have been handled for you in Configuration#MappingsImpl which is where that stuff is actually a concern (almost like real OO programming!) ;) 2) Make Mappings a delegate for Configuration. The essential change here is to have Mappings itself instantiate and manage these collections instead of Configuration doing it and passing them in as ctor args. Now this does change the current semantics of Mappings slightly in that we currently build a new Mappings instance for each <hibernate-mapping/> we encounter. And in fact the javadocs for Mappings even assert this usage. *However* that semantic is completely anecdotal. All these collections on Mappings are not segmented by the Mappings instance because they are the collection instances maintained on Configuration! The only Mappings attributed that are truly used in that fashion are the non-collection member attributes (schemaName, catalogName, etc) which come directly from the <hibernate-mapping/> element. And that is easily "corrected" for this approach by resetting those to null/etc when we start processing a new <hibernate-mapping/> element. -- 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/HHH-3439?page=c... ] Max Rydahl Andersen commented on HHH-3439: ------------------------------------------ I looked at my usage of Mappings and in tools I do not extend the class. I just use it in custom secondpass for reverse engineering to access and manipulate via the public api on it.. For code generation I "just" uses whatever Configuration is passed to me and don't do any magic. p.s. It took me a while to realize we were talking about Mappings and not Mapping (which i do have custom implementation of in reverse engineering ,) -- 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