This is not about gut feelings. It is about use cases.
What I like to see is to have 1 system that is flexible enough to handle all the important use cases. What I don't like to see is to have separate spare parts for each and every different use case. And that's how it looks today to me. I personally always prefer to have an API + write a few lines of cody myself than to have a hugely complex system which can do all things - but no one can configure it nor use it correctly. LieGrue, strub > On Monday, 22 December 2014, 21:45, Anatole Tresch <[email protected]> wrote: > > 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 >>> >
