> so you can ask the config server for the right config.
Gosh, that scares me a bit! Don't even think about config servers. Such things must be totally up to the vendor. We must allow making such things possible with our API but we shall NOT support such things out of the box! The best would be to make our API in a way that even the user (application programmer) could add such a mechanism to it himself. > For me SE comes first. EE builds on top not the other way round! Totally agree with that. > But it (DeltaSpike) is inheritly connected to CDI and That's just not true. And it's tried and used successfully in many big projects (including my own which deals with 50 bn EUR, german stock exchange, UK stock exchange, big swiss banks, etc). I'm not saying the DS api is the best, but it is able to do all that and is 1/20th of the complexity and size of Tamaya right now. And still being more powerful. >> things not working out of the box: distributed configs For which distributed system? * Ehcache? * Terracotty? * Hadoop like clustering? * a simple shared file store? Where to put the meta-configuration for it? Where to define which one to use? What fallback strategies to choose? All that HEAVILY depends on the situation and scenario you have in your project. There is just nothing we can decide for the customer. All we can do is to make it VERY EASY to implement it yourself. For example: In DeltaSpike adding a ConfigSource for a config file on a shared folder is a mere 7 lines of code.. Please don't let us go down the (old) Spring route to have miles of configuration for stuff which you could hack in just a few lines of code. >> we can start as >> easy as reading a database We discussed this in DeltaSpike and deliberately did NOT add it. It's really really easy to implement a ConfigSource which goes into the DB yourself in 30 minutes. If we would provide this feature out of the box, then how would you do that? * which database would you address? * JPA or JDBC native? again: what about the db vendor? * how to configure your db user, your schema, etc? * what about update and caching policies? We would need some jar with JPA or whatever as dependency. Would need meta-configuration, yada yada yada. And all to avoid 100 lines of code? That just doesn't pay off! Probably add some sample code somewhere. It must be easily doable within our API but we should not try to implement that by default in our core jar. >> it include crud >> api but also a GUI - and listeners/update events. Totally overengineered imo. How should a GUI look like which might change configuration in a Haddop Cluster or in a Docker installation? Or whatever comes around the corner next year... Just DON'T DO IT. There is of course an important very basic underlying design question: How to treat configured values which are non-mutable and might get cached vs ones which might change during the application lifetime? Also: Do we like to introduce an own API for value-reload or do we leverage JMX? THOSE are the things I like to get clarified before we touch ANY code! >>> ... 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. That's why I gave you a use case in my original post. Solve this problem with the current Tamaya source base please. And also please give me use cases which you think are important and work cool with Tamaya. And then lets discuss whether the use case makes sense and how we could do it in the easiest way. LieGrue, strub > On Tuesday, 23 December 2014, 9:02, Anatole Tresch <[email protected]> wrote: > >Good Morning > > See inline... > > Anatole > > >> Am 23.12.2014 um 08:25 schrieb Romain Manni-Bucau > <[email protected]>: >> >> Hi >> >> Yeah Environment is surely optional in practise. > ;) though when you deal with remote configuration it gets more important > because > you need it to identify, what stage, network zone, deployment type, whatever > you > are, so you can ask the config server for the right config. Similarly you > will > have overridings in place that are active depending your environment. As > outlined before granularity here may exceed what we have today in Java EE. > >> 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. > you even dont want to use IoC or even worse, but often reality, you have lots > of > hardwired legacy code, where IoC is even not an option, even though you are > running in a IoC capable container... > For me SE comes first. EE builds on top not the other way round! > >> For IoC side the DeltaSpike API is great. What do we miss then? > agree, it was a good first step. But it is inheritly connected to CDI and > therefore to the same reasons outlined before is by far not able to cover > legacy > environments (which is the mast majority in many bigger companies with a > mulitmillion investment in IT. > >> Mainly 3 >> things not working out of the box: distributed configs - we can start as >> easy as reading a database > Yep, will add that use case more explicitly. > >> 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. > Yeah. That is also where I see options for having buildingblocks provided. Eg > not every tamaya user should implement caching/distribution ans security on > its > own. On the other side I do not expect thatall tthese features will already > be > existing on the first release... > It is similar to Spring security. You dont want all users to implement all > the > apis, you provide reusable building blocks... > >> In terms of API it is quite easy and all the power would come from the impl >> IMO. > Agree. That is the PropertySource currently. Or setters for templates, or > apply(ConfigChangeSet) for Confuguration/PropertySource. All the rest can be > hidden. > > >> 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* >>> >
