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 wate*r!
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/
<http://javaremarkables.blogspot.ch/>*
*Google: atsticksMobile +41-76 344 62 79*
