I've sent a pull request which contains the proposed change [1]. With that change, GridDialects can now also be configured as instance or class type, and they can be a Configurable or ServiceRegistryAwareService. Any feedback welcome.
--Gunnar [1] https://github.com/hibernate/hibernate-ogm/pull/266 2013/12/17 Gunnar Morling <gun...@hibernate.org> > Hi, > > We currently have a custom mechanism for providing the current GridDialect > to components and I'm wondering about the motivation for this mechanism. > > More specifically there is GridDialectFactory which instantiates the > dialect type and DatastoreServices which provides access to this instance. > So we have two services and initiators just dealing with providing access > to the current grid dialect. > > Couldn't there simply be a GridDialectInitiator which instantiates the > GridDialect type and registers the dialect itself as service in the > registry? This seems beneficial to me: > > * GridDialect implementations can leverage all benefits of being a > service, e.g. they can implement Configurable to access the configuration > or ServiceRegistryAwareService to access other services (including the > DatastoreProvider). Note that GridDialect extends Service already today > which seems confusing as it is no service managed by the registry. > * We could remove DatastoreProvider, GridDialectFactory and their > initiators > * One indirection less for users of the GridDialect as they can get it > directly from the registry > > Any thoughts? Is there a specific reason for the current design which I'm > missing? > > Thanks, > > --Gunnar > > _______________________________________________ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
