About Environment and distirbuted system: the issue is the same with or without. You always need a local config vs the global one but I strongly think a system property, jndi entry or anything else can be enough and don't need to be in tamaya itself to start.
2014-12-23 10:31 GMT+01:00 Mark Struberg <[email protected]>: >> 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. > It is Mark, at least in term of dependencies, I asked months ago to explode core part but it was not the moment I guess ;) > >>> 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? > Never spoke of any technology. Spoke in term of use case: I have 5 machines which need to read the same config. Constraint I'd like to respet is: don't force a "complicated" config like hazelcast one for instance. > 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.. > Here the is issue: it needs you to code. This is not a feature of the framework. > 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. > In practise you don't always have the choice. > > >>> 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! > That's why I spoke about a "push" system. Then we just use java 7 file system watch solution. > 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! > > JMX is mandatory IMO but JAXRS as well. > > >>>> ... 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* >>>> >>
