see org.hibernate.test.annotations.embeddables.EmbeddableIntegratorTest
this test is using Integrator to registerTypeOverride, in the middle of SF
initializing, after Configuration / Metadata built.
so, firstly I want to confirm if this is an expected use case of Integrator,
since at this time, the metadata is supposed to resolved, and no way to apply
the new overrided types.
( This test passes w/ Configuration, since the attribute type is delayed to the
persister initialize time, and the Value holds a reference of
org.hibernate.cfg.Configuration.MappingsImpl, which holds a reference to the
Configuration#typeResolver.
but this also doesn't sound right, since SF also has a typeResolver, which is a
copy of Configuration#typeResolver, and it is copied before the Integrator
applied. )
the process looks like:
1. Configuration creates a new instance of TypeResolver and load default types
( including dialect overrided types and
org.hibernate.metamodel.spi.TypeContributions )
2. SF create a new instance of TypeResolver and copy all types from
Configuration.typeResolver
3. apply integrator and add/override new types to the
Configuration.typeResolver, here we get mismatch between SF.typeResolver and
Configuration.typeResolver
I checked the git history / JIRA and trying to find the background of this
test, but nothing.
if you guys confirm this is not a valid use case, then I'd suggest:
1. give Integrator a better name and clearly add something to the (java) doc
say the expect usage of this Integrator ( maybe DO NOT TRY TO CHANGE THE STATE
OF METADATA / CONFIGURATION AT THIS SATGE?)
2. move the IntegratorService to the SessionFactoryServiceRegistry?
-
Best Regards,
Strong Liu
http://about.me/stliu/bio
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev
