For me the propsal looks Ok. As a consequence I will branch away master later and then start the discussions on PropertySource ;)
Romain Manni-Bucau <[email protected]> schrieb am Mi., 24. Dez. 2014 um 13:57: > 2014-12-24 13:11 GMT+01:00 Anatole Tresch <[email protected]>: > > To which part of the api do you refer? I don't see the coincidence... > > You want a class? noone. The contract here is not in Java but in plain > String - but it is still an API or better a better wording would be a > user contract. > > > > > > About the topics you mention: > - configuration > - property adapter (functional interface) > - configQuery (funct.interface) > - propertysource > - annotations (tbd, we could move them also to an injection module > separately) > - configurationspi > - servicecontext stuff > > I propose to open 1 thread by topic at a time, we all try to not > "leak" on another topic in these threads and once it is validated it > goes to the source code - it means we start from a clean branch > otherwise we'll fight with existing code again. > > I'd do this order: > 1) PropertySource > 2) PropertySource "aggregator" - how are merged conflicting property > sources. > 3) adapters > 4) query > 5) Configuration + Configuration SPI - guess this one will be trivial > and ends with up something like Bean Validation or JPA. > 6) if needed, service context (5 can make it obsolete IMO) > 7) annotations - I guess here we can discuss just before if we speak > about IoC or not. A little stufy of potential integrations could help > as well before getting in the concrete thread IMO > > > wdyt? > > > Romain Manni-Bucau <[email protected]> schrieb am Mi., 24. Dez. > 2014 um > > 12:54: > > > >> the point is while Configuration relies on them imlpicitely (string > >> locations for instance) it is part of the api even if located in the > >> core. > >> > >> > >> Romain Manni-Bucau > >> @rmannibucau > >> http://www.tomitribe.com > >> http://rmannibucau.wordpress.com > >> https://github.com/rmannibucau > >> > >> > >> 2014-12-24 12:45 GMT+01:00 Anatole Tresch <[email protected]>: > >> > Hi Romain/all > >> > > >> > Just to clarify: All formats are already part of the core > implementation. > >> > The api even has no abstraction for formats. In the api its all about > >> > PropertySource and Configuration, plus functional interfaces to hook > in > >> > code for use cases, not more... > >> > > >> > Anatole > >> > Anatole Tresch <[email protected]> schrieb am Mi., 24. Dez. 2014 um > >> 11:22: > >> > > >> >> Hi Mark > >> >> > >> >> sorry, but I actually overlooked that mail, when you first wrote it, > so > >> I > >> >> will answer it now ;) > >> >> > >> >> *Size Comparison, *you stated: > >> >> > >> >> > 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 > >> >> > >> >> Despite the fact that Tamaya is much smaller in size the comparison > IMO > >> is > >> >> completely invliad the ways you did it, beacuse: > >> >> - Deltaspike config relies on CDI, which does context management, > >> >> injection, provides extension and injection SPI, all used by the > overall > >> >> code. Tamaya has to do that kind of things on its own, because it > cannot > >> >> and should not rely on CDI. For a correct comparison you should add > up > >> the > >> >> code e.g. from Weld on top and - bingo - Tamaya would be much > smaller. > >> >> - When we would compare filtes and other stuff, I am quite sure, > Tamaya > >> >> will be not bigger in many cases. If you like, we can do that kind of > >> >> comparison, I would love to face that challenge... ;) > >> >> > >> >> *Use Case:* > >> >> > >> >> From your description I suggest there are two ways to solve that > >> >> > >> >> 1) The caller that reads the configuration is managing the filter. > >> >> 2) The filter is built in implicitly by some framework configuration > >> that > >> >> provides it along the configuration definition (metamodel). > >> >> > >> >> And here's the code (assuming String MyPKI.decrypt(String) provides > the > >> >> required decryption : > >> >> > >> >> *1) * > >> >> URL endPoint = Configuration.current().get("endPointURL", > >> URL.class).get(); > >> >> String uid = Configuration.current().get("endPointURL.user").get(); > >> >> String pwd = Configuration.current().*getAdapted("endPointURL. > >> password", > >> >> (v) -> MyPKI.decrypt(v)};* > >> >> ** > >> >> > >> >> *2) In this case the SPI implementation that provides the correct > >> >> configuration adds the filter:* > >> >> > >> >> ConfigurationBuilder.of().addPaths(...)*.filterValues((k,v) -> > >> >> k.equals("endPointURL.password")?MyPKI.decrypt(v):v)*.build(); > >> >> > >> >> The API part then is completely transparent: > >> >> > >> >> URL endPoint = Configuration.current().get("endPointURL", > >> URL.class).get(); > >> >> String uid = Configuration.current().get("endPointURL.user").get(); > >> >> String pwd = Configuration.current().get(" > endPointURL.password").get(); > >> >> > >> >> Adding a filter to the current classloader could be added as a > feature > >> as > >> >> well, but is not the case. Especially classloaders are only one of > >> possible > >> >> isolation strategies. If we want to add that kind of future to > Tamaya as > >> >> well, it would be something like: > >> >> > >> >> Configuration.current().addFilter( > >> >> (k,v) -> k.equals("endPointURL.password")?MyPKI.decrypt(v):v) > >> >> ; > >> >> > >> >> Cheers, > >> >> Anatole > >> >> > >> >> > >> >> - > >> >> Anatole Tresch > >> >> Glärnischweg 10 > >> >> 8620 Wetzikon > >> >> Tel +41 (43) 317 05 30 > >> >> - > >> >> Send from Mobile > >> >> > >> >> > 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 > >> >> > >> >
