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