few comments inline 2015-01-07 22:14 GMT+01:00 Anatole Tresch <[email protected]>: > 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
Not exactly, AFAIK users want a contextual config - me too ;) - but as a user you dont care if that's the config which is contextual or its integration which makes it contextual. > - 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. Not sure where it conflicts > - *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.* Sadly wrong - at least in 2 companies. > - 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. Also means out of the box it is not well integrated which in practise if often enough to not use an open source product. > - *it defines a clear separation between configuration consumer and > configuration provider and configuration designer.* Same here, not sure why it conflicts. > - *it shields users from the innerworking details* Idem > - *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. False in practise - sadly once again - and I dont get why it conflicts. > - it is highly inefficient to load the config every time you need it > again. > same > *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! > Would this solution be a compromise: We use the standard pattern ConfigurationFactory (delegates to a provider) -> Configuration in core. During the same time we create a module (extension but "core extension" so not sure where to put it) with the current approch (in ContextualConfiguration.current()?). I agree it split Configuration and current() but to start and ask for feedback it can maybe be better. It would also allow us to see the factory pattern in place - do we want to do so in a branch?. Note that since we'll integrate with other libs/cotainer context will need start and stop methods so the lifecycle will be manual, the same as if we let the user handle it completely IMO. > 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*
