[hibernate-dev] org.hibernate.cfg.Settings deprecated

[Steve Ebersole]

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 <manderse at 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 <steve at 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 at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>
>
>
> /max
> http://about.me/maxandersen
>