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

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 _______________________________________________ hibernate-dev mailing list hibernate-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev

On Thu, Feb 6, 2014 at 7:01 AM, Emmanuel Bernard <emmanuel(a)hibernate.org&gt; wrote: For OGM the impact is less but in Integrator.integrate we use Configuration to be able to conditionally add a naming strategy configuration.setNamingStrategy(). See this actually illustrates the problems with Configuration, so thanks for that :). Setting the naming strategy there would have had no effect because its "too late in the game". And there is really no corollary in the new code because of that (setting the naming strategy is available earlier).

On Thu, Feb 6, 2014 at 6:46 AM, Emmanuel Bernard <emmanuel(a)hibernate.org&gt;wrote: Configuration.getreflectionManager (optional) > We do not use commons-annotations anymore at all (yaay!). If you need access to this type of functionality, I have been thinking about passing along access to the Jandex index we use.

> 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. > "Mapping information" is MetadataImplementor. Though tbh it sounds like you really just want/need Jandex.