That's really more a function of bootstrapping, not the actual Settings object. And yes, these hibernate.properties et al are still picked up and used.
On Tue, Apr 21, 2015 at 4:14 PM, Max Rydahl Andersen <mande...@redhat.com> wrote: > As long as we can explicitly disable things via API like we could in past > this should be fine. > > i.e. in tools we used setting properties to disable second level caching, > hibernate validator, connection pooling, tx management and search setup > since it just doesn't either make sense or won't work when trying > to load hibernate model outside an app server. > > /max > > Ok, silence will be taken as a vote to do whatever I feel is best >> regardless of impact on these integration impls... So anyone? >> >> On Thu, Apr 16, 2015 at 7:20 AM, Steve Ebersole <st...@hibernate.org> >> wrote: >> >> Last night I pushed some changes which included deprecating >>> org.hibernate.cfg.Settings in favor >>> of org.hibernate.boot.spi.SessionFactoryOptions. The main reason for >>> this >>> was to make it easier for OGM and others to hook into the SessionFactory >>> creation process. For now, I have made Settings delegate >>> to SessionFactoryOptions. >>> >>> I am not sure if anything external relies on this Settings contract. But >>> there are a few usages I wanted to discuss. >>> >>> First is caching. Part of the SPI for building RegionFactrory is passing >>> along the Settings object. Ideally I'd just swap this with >>> SessionFactoryOptions. And given that this targets a major release >>> (5.0), >>> that should be ok. Anyone against that? Sanne? Galder? Alex? >>> >>> Second is the initiation of BV integration. The TypesafeActivator >>> accesses the Settings object in order to >>> call org.hibernate.cfg.Settings#setCheckNullability. As of now, this is >>> the only setter method I have left on Settings (it simply passes that >>> call >>> on to the SessionFactoryOptions, which exposes just this one setter for >>> just this one case). I'd like to make it so that SessionFactoryOptions >>> is >>> immutable at the time SessionFactory is built. This was largely true for >>> Settings already aside from this one use case. I am just not sure yet of >>> the best way to allow an Integrator to affect this SessionFactoryBuilder >>> process. Thoughts? >>> >>> _______________________________________________ >> hibernate-dev mailing list >> hibernate-dev@lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/hibernate-dev >> > > > /max > http://about.me/maxandersen > _______________________________________________ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
