[hibernate-dev] API/SPI in 5.0

[Emmanuel Bernard]

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 at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev