I also find the contextual approach a far better fit. This did already work very well in CODI and DeltaSpike. But I'm sure we can improve this even more in the area of container integration.
I also agree with the user aspect. Somehow it is really similar to Loggers with their factories. @Anatole I don't question everything, but as the discussions are still ongoing I wanted to have a clean sheet discussion about it. LieGrue, strub On Wednesday, 7 January 2015, 22:14, Anatole Tresch <[email protected]> wrote: > > >Hi > > >I heavily would recommend the contextual approach (1) since > * it is the one almost all users I have talked with expect and is the > benefit Tamaya provides compared to other solutions > * if you write a component you simply know where to put your defaults in > CP, so you do that, implement your component with config access, test it and > you are done. > * it works very well in Credit Suisse and other companies since decades > also in very complex environments, including low latency stuff. To claim the > opposite is useless IMO. > * can be implemented in various ways for different context designs (it is > not constraint to Java EE). We have in CS tomcat only installations as well > as full stacked Weblogic Java EE with EE 5 and EE 6. > * it defines a clear separation between configuration consumer and > configuration provider and configuration designer. > * it shields users from the innerworking details > * for complex environments it is the only way to go. If you let all > developers put together their configs manually they will miserably fail to > configure their applications correctly. > * it is highly inefficient to load the config every time you need it again. >Additionally the second option (builder) can still be combined with the first: > * you can register a Configuration instance that exactly does this and is > backed up by some other singleton you have written, e.g. as an extension. > * You can then use this extension API to build and register your > configuration into the main Tamaya API. >So it is possible to do both as a matter of taste. There is no need to throw >the child out with your bath water! > > >Cheers >ANATOLE > > > > > > >2015-01-07 20:40 GMT+01:00 Mark Struberg <[email protected]>: > >Hi! >> >>We had great discussions and many valid and important aspects did came up. >>Too bad they were spread all over the place in various threads ;) >> >>So let's again pick up the discussion. >> >>We basically have 2 options. >> >> >>1.) a 'contextual' approach like we currently have with our ServiceContext. >>There is exactly 1 Configuration 'per application'. >> >> >>2.) a 'builder' approach. The configuration system gets built by the user as >>often as the user likes and in exactly the way the user likes. In that case >>andling the configuration for whole application is _not_ part of this >>project. Means any contextually would need to be provided as >>@ApplicationScoped producer bean or in other ways. >> >>Now it's your turn. Gimme all the pros and cons ;) >> >> >> >>LieGrue, >>strub >> > > > >-- > >Anatole Tresch >Java Engineer & Architect, JSR Spec Lead >Glärnischweg 10 >CH - 8620 Wetzikon > > >Switzerland, Europe Zurich, GMT+1 >Twitter: @atsticks >Blogs: http://javaremarkables.blogspot.ch/ >Google: atsticks >Mobile +41-76 344 62 79 > >
