Yes but WHO does provided this ConfigurationFactory? WE do already. And the SPI even allows containers to replace the impl of the factory with their own. Imo this is enough.
LieGrue, strub > On Wednesday, 7 January 2015, 22:27, Romain Manni-Bucau > <[email protected]> wrote: > > 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* >
