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
