And ignore the benefits of reusability and finer grainef modularity on the implementation level. This would mean we only ship the api and nothing else. If you are serious about that we should stop any work immedeately it renders Tamaya to be useless. I will nevertheless provide an overview of all main building blocks later. This is better than just rausing gut feelings ;)
Cheers Anatole - Anatole Tresch Glärnischweg 10 8620 Wetzikon Tel +41 (43) 317 05 30 - Send from Mobile > Am 22.12.2014 um 21:10 schrieb Gerhard Petracek <[email protected]>: > > i agree with mark and that was the reason i stopped with my participation > in the previous threads. > > i saw several complex config frameworks and most parts were just ignored by > (customer-)projects. > others used the whole complexity without a real justification (what they > really needed could be solved way easier). > > imo a better way is to provide a small but extensible framework + a > reasonable documentation which illustrates how to handle more complex cases > with the concise api. > > regards, > gerhard > > > > 2014-12-22 20:33 GMT+01:00 Mark Struberg <[email protected]>: > >> Hi John! >> >> >>> The DeltaSpike configuration module is very simple. It's smaller >> >>> than even what I use in my application code (taking out javadocs, >> >>> headers, etc). I also doubt you're taking into account project stage, >> etc. >> >> >> I even counted parts of the ProjectStage mechanism. E.g. >> getProjectStageAwarePropertyValue and stuff. >> Fully adding the ProjectStage would be another 450 LOC. But with @Exclude >> etc this is sooo much more functionality than what Tamaya offers right now. >> At least if I didn't miss parts from Tamaya. >> >> >> Werner, >> >>> Not sure, if DeltaSpike Config aims at multi-purpose configuration >> >> >> It does. And it works pretty well. >> >> >> >>> the recently rewritten Apache Commons Config 2 >> >>> consists of 228 class files >> >> commons-configuration is a.) pretty ancient (even the 2.x version is as it >> tries to partly be backward compat from the features) and b.) has a >> different goal. It provides readers for various config inputs, like windows >> ini files, xml, property files, windows registry, beaninfo, etc. Even a >> reader for GnuStep/OpenStep is there. >> >> DeltaSpike otoh is not about those readers at all. Actually we only >> provide property file readers, JNDI, System and Environment variables out >> of the box. BUT we allow to easily write those yourself. Adding an own >> ConfigSource which reads whatever format you like is just a few lines of >> code. >> >> The most important aspect of the DeltaSpike Config is a totally different >> one: It has the capability to MERGE configuration from different >> ConfigSources together. Thus it allows to have a default configuration >> somewhere and 'tweak' it e.g. via JNDI or a -Ddatabase.connection.url=xxx >> or any other DataSource. >> >> It is actually more like a freely configurable 'configuration bus' than a >> reader/writer system like commons-configurations. >> >> >> >> LieGrue, >> strub >> >> >> On Monday, 22 December 2014, 17:43, John D. Ament <[email protected]> >> wrote: >>> >>> The DeltaSpike configuration module is very simple. It's smaller than >> even what I use in my application code (taking out javadocs, headers, >> etc). I also doubt you're taking into account project stage, etc. >>> >>> >>>> On Mon Dec 22 2014 at 11:38:09 AM Mark Struberg <[email protected]> >>> wrote: >>> >>> 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 >>
