Hi Yeah Environment is surely optional in practise.
Wonder if we didnt think in the wrong way. I mean if you start from an IoC usages then API is always smarter than from SE case. Then aligning SE on IoC is quite easier than the opposite. For IoC side the DeltaSpike API is great. What do we miss then? Mainly 3 things not working out of the box: distributed configs - we can start as easy as reading a database but i would like to be able to rely on local files and move this distributed logic in a separate module reading a database or anything else to push files on disk to avoid issues if the db is down, write part of the config ie how do I update it - it include crud api but also a GUI - and listeners/update events. In terms of API it is quite easy and all the power would come from the impl IMO. Le 23 déc. 2014 01:56, "Anatole Tresch" <[email protected]> a écrit : > ... and BTW, what a meant with the "guts feeling": I would like to see > concrete proposals: just say what you want to change IN CODE, or at least > more precisely. Just saying it is too complex is IMO not very constructive. > Also it is more concrete for everybody here on the list. > > Some examples: > If you would ask me e.g. to replace the ConfigManager and > EnvironmentManager in API by simply accessing the ServiceContext from the > facade artifacts, I would agree. > If you ask for reducing the number of SPIs in core and perhaps move a more > complex environment singleton implementation out to somewhere else, I would > agree. > Theoretically we could even move the Environment part into a separate > module and simply let the Configuration part be the core part of the API... > > Just my few cents here. > > Cheers, > Anatole > > > > 2014-12-23 1:01 GMT+01:00 Oliver B. Fischer <[email protected]>: > > > Hi all, I think we need this discussion. Let me list my points: > > > > 1. Yes, Tamaya is to complex at the moment. > > 2. It seems to be to complex. > > 3. We do not finish discussions on the list and start to early to > > implement things. > > > > How can we change this? > > > > 1. Let us write down a list of use cases we would like to support. > > 2. Let us discuss how to support these use cases. > > > > Without this approach we will have the same discussions again and again. > > > > Second we should try to keep the API as elegant and minimal as possible > > for simple use cases. Tamaya should also be possible go handle complex > use > > cases. > > > > May we shouldn't have started with an existing code base. > > > > Best, > > > > Oliver > > > > > > Von meinem iPhone gesendet > > > > > Am 22.12.2014 um 17:36 schrieb Mark Struberg <[email protected]>: > > > > > > Hi! > > > > > > I have a very fundamental problem with the current state of Tamaya. It > > grows and grows and grows and grows. But what for? What are the key > > benefits of all those classes? > > > > > > I bet I don't see all the details, so please lets get a discussion > > started. > > > > > > > > > As a simple start I just like to compare 2 known mechanisms: > > > > > > 1.) DeltaSpike > > > The whole configuration system consists of 5 classes with in summary > 800 > > lines of code (including license headers, tons of javadoc, etc). > > > > > > > > > 2.) Tamaya > > > 123 classes with 7500 lines of code > > > > > > > > > So as you can see there is a HUGE difference in complexity. And to be > > honest I cannot see much justification yet. > > > > > > > > > > > > Even if you add the ProjectStage (3 classes, 500 LOC) and the full CDI > > integration (4 classes, 400 LOC) to DeltaSpikes configuration (features > > Tamaya don't yet have) then you are still way below Tamaya. But even with > > way more functionality. > > > To be honest, I was reading through JavaDocs and sources and so far it > > was by far more WTFs than aha. > > > > > > > > > > > > Of course I most probably miss some features, so please help me to find > > those gaps and fill them. > > > I'd like to suggest that we start a small game and collect use cases > and > > how those might get solved with Tamaya and with DeltaSpike-config. > > > > > > > > > In general we have to abstract 4 different aspects: > > > > > > 1.) the API/SPI > > > 2.) the server provided functionality > > > 3.) a user way to customize/extend the configuration functionality > > > 4.) the user way to read the configured values > > > > > > > > > I'll give you an example of a use case: > > > > > > A company uses REST endpoints and need to talk to those. > > > So we need to configure a few things: > > > 1.) the endpoint URL > > > 2.) the username which should be used to connect (e.g. over https, > BASIC > > auth, whatever) > > > 3.) the passphrase which should be used to connect. > > > > > > The security credentials (passphrase) should not get stored in > plaintext > > but encrypted using PKI. It should of course also not get logged out in > > clear text but shall get masked if logging out the configured values is > > enabled. > > > > > > > > > In DeltaSpike I'd just register a ConfigFilter to do the password > > decoding on the fly. So this is pretty much straight forward. How is this > > handled in Tamaya? > > > > > > > > > Now it's your turn: give me some use case where you think the current > > tamaya source is strong. And then we gonna discuss it. If something is > not > > needed or easily solvable otherwise then we gonna drop those parts which > > are superfluous. NOW is the time to do such things! If all features and > > sources turn out to be there for a good reason than I'm happy to keep > them. > > If there is no VERY GOOD reason, then it will get cut out. Not sure about > > the others around here, but I personally am a really big fan of KISS > (Keep > > It Simple and Stupid) when it comes to such fundamental (in the sense of > > important fundament and foundation) pieces. > > > > > > > > > txs and 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* >
