Well i strongly do believe in future of tamaya but true current cost to start using it is way to high compared to what it offers IMO. Le 22 déc. 2014 21:52, "Mark Struberg" <[email protected]> a écrit :
> 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 > >>> > > >
