Also "plugins" can make use of the general availability of properties. For example Hibernate Search reads everything under hibernate.search (and it's not a limited set of property names). Likewise, HSearch extensions can use whatever property name they want to configure say the custom backend or the directory providers (either custom or even one of the system properties). On 1 févr. 2010, at 00:35, Steve Ebersole wrote:
> On Mon, 2010-01-25 at 10:12 +0100, Emmanuel Bernard wrote: > >> This approach probably works fine for EM but EMF's settings have to be read >> at configuration time as they influence each other in a non trivial way. >> They are basically part of the state machine used to retrieve the list of >> mappings (ann or xml), some of the key configurations (JTA vs non JTA which >> influences how the datasource is provided etc). We would need to read these >> setting at least two times: >> - once at Configuration time >> - once at SF creation time > > Ok, I am seeing this now... and it is causing me some problems (or at > least questions about) reporting back EMF properties. It's very similar > to the way SessionFactory is built. Most of the properties are actually > "consumed" during SettingsFactory processing. So the SessionFactory has > access to both the Settings (consumed properties) and the raw Properties > object from Configuration. In the first case it would need to know how > to extract off all the relevant configuration parameters; in the latter > case it would need to know which to exclude (this Properties holds > *everything*, even System properties generally). > > The problem with the "unroll Settings" approach is that we'd have to go > pretty far down to get them all. > > -- > Steve Ebersole <st...@hibernate.org> > Hibernate.org > _______________________________________________ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
