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