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 >> >> >>
