Re: [hibernate-dev] API/SPI in 5.0
I have looked at Search and identified the elements that use
Configuration and it's access to mapping.
During bootstrap via an Integrator, we use
Configuration.getProperties()
Configuration.getreflectionManager (optional)
cfg.getClassMappings()
The properties are used to bootstrap Hibernate Search as we receive our
properties form the Hibernate ORM configurations
The class mappings is necessary for us as it offers the list of entities
we need to look at. From them, we bootstrap with the subsection that are
@Indexed entities.
We do that by associating a SF Observer and passing in the Configuration
object and using the SF instance passed.
This observer is initialized by the Integrator.
From what I understand the replacement for
Integrator.integrate(Configuration, SessionFactoryImplementor,
SessionFactoryServiceRegistry)
is
Integrator.integrate(MetadataImplementor, SessionFactoryImplementor,
SessionFactoryServiceRegistry)
How we get access to the properties and the list of mapped classes in
the new form?
Emmanuel
On Fri 2014-01-31 14:14, Steve Ebersole wrote:
As we transition to 5.0 we have to make a lot of decisions wrt
API/SPI
methods that are no longer relevant. I think it is better to look at
these individually.
== Configuration
I went ahead and made a preliminary decision here as I discussed in
HHH-7164. The thinking is that we had some leeway here because
Configuration had been deprecated (and pretty widely known to be
deprecated based on StackOverflow and other sources). Basically I made
Configuration a simple delegate to the new Metadata building code. I
removed all the methods that exposed access to the org.hibernate.mapping
objects that Configuration used to manage.
---
== Integrator
This one is a little tougher. In retrospect I think I would have just
gone for a number of discrete contributor contracts. For example,
usually Integrator is used to add event listeners, so an
EventListenerContributor would have worked. Then I would have used
Integrator as a grouping of contributors.
== PersisterFactory (and persister constructors)
Forms taking Configuration and org.hibernate.mapping objects should,
imo, get removed. But I can live with deprecation if someone wants to
"pound the table" for that. But realize that the
Configuration+org.hibernate.mapping forms would not be called ever.
_______________________________________________
hibernate-dev mailing list
hibernate-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev