[hibernate-dev] Design : delegates and constructors

Design question on how we want to handle this notion of delegates that ogm, search, etc extend and constructors... Specifically the notion that Sanne has asked for where ORM provides implementations of stuff that OGM, Search, etc can just extend. So, for example, AbstractEntityManagerImpl. AbstractEntityManagerImpl defines a (what I call) "strict verbose" constructor. It takes 4 constructor args. However, now take the case of JPA 2.1 where there is a new argument (via new overloaded method) for EM opening (new SynchronizationType enum) that we will need to pass along to the constructor of AbstractEntityManagerImpl. This is where, IMO, this concept of delegates starts to break down *as we generally define ctors today*. IMO, for this notion of delegates to work as intended, I think we needs to provide "bundled" constructor forms. Again, taking AbstractEntityManagerImpl as the example, today we have: protected AbstractEntityManagerImpl( EntityManagerFactoryImpl entityManagerFactory, PersistenceContextType type, PersistenceUnitTransactionType transactionType, Map properties) { ... } Leaving aside the passing of a Map for now... What I think works best in terms of maintaining the intention of these delegates is: protected AbstractEntityManagerImpl( AbstractEntityManagerImpl.Options options, Map properties) { ... } or maybe even: protected AbstractEntityManagerImpl( EntityManagerFactoryImpl entityManagerFactory, AbstractEntityManagerImpl.Options options, Map properties) { ... } Where Options contains the things AbstractEntityManagerImpl needs to initialize itself. Currently that would be 'type' and 'transactionType', but JPA 2.1 would add 'synchronizationType' as well. The point though is that OGM, Search etc would not need to be changed at all here if the constructor had been defined to accept AbstractEntityManagerImpl.Options before and we added 'synchronizationType' in implementation of JPA 2.1. Or is moving from JPA 2.0 to 2.1 going to warrant changes in OGM, Search anyway that circumventing constructor signature changes is irrelevant? -- steve(a)hibernate.org http://hibernate.org