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
