You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tamaya.apache.org by Mark Struberg <st...@yahoo.de> on 2014/12/22 17:36:15 UTC
[DISCUSS] increasing complexity of Tamaya
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
Re: [DISCUSS] increasing complexity of Tamaya
Posted by "Oliver B. Fischer" <o....@swe-blog.net>.
BTW I will never rate a project based on the number of classes. This is an implementation issue and if it does not hinder me and does not influence the API I don't care.
Von meinem iPhone gesendet
> Am 22.12.2014 um 17:36 schrieb Mark Struberg <st...@yahoo.de>:
>
> 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
Re: [DISCUSS] increasing complexity of Tamaya
Posted by Anatole Tresch <at...@gmail.com>.
For me the propsal looks Ok. As a consequence I will branch away master
later and then start the discussions on PropertySource ;)
Romain Manni-Bucau <rm...@gmail.com> schrieb am Mi., 24. Dez. 2014 um
13:57:
> 2014-12-24 13:11 GMT+01:00 Anatole Tresch <at...@gmail.com>:
> > To which part of the api do you refer? I don't see the coincidence...
>
> You want a class? noone. The contract here is not in Java but in plain
> String - but it is still an API or better a better wording would be a
> user contract.
>
>
>
>
>
> About the topics you mention:
> - configuration
> - property adapter (functional interface)
> - configQuery (funct.interface)
> - propertysource
> - annotations (tbd, we could move them also to an injection module
> separately)
> - configurationspi
> - servicecontext stuff
>
> I propose to open 1 thread by topic at a time, we all try to not
> "leak" on another topic in these threads and once it is validated it
> goes to the source code - it means we start from a clean branch
> otherwise we'll fight with existing code again.
>
> I'd do this order:
> 1) PropertySource
> 2) PropertySource "aggregator" - how are merged conflicting property
> sources.
> 3) adapters
> 4) query
> 5) Configuration + Configuration SPI - guess this one will be trivial
> and ends with up something like Bean Validation or JPA.
> 6) if needed, service context (5 can make it obsolete IMO)
> 7) annotations - I guess here we can discuss just before if we speak
> about IoC or not. A little stufy of potential integrations could help
> as well before getting in the concrete thread IMO
>
>
> wdyt?
>
> > Romain Manni-Bucau <rm...@gmail.com> schrieb am Mi., 24. Dez.
> 2014 um
> > 12:54:
> >
> >> the point is while Configuration relies on them imlpicitely (string
> >> locations for instance) it is part of the api even if located in the
> >> core.
> >>
> >>
> >> Romain Manni-Bucau
> >> @rmannibucau
> >> http://www.tomitribe.com
> >> http://rmannibucau.wordpress.com
> >> https://github.com/rmannibucau
> >>
> >>
> >> 2014-12-24 12:45 GMT+01:00 Anatole Tresch <at...@gmail.com>:
> >> > Hi Romain/all
> >> >
> >> > Just to clarify: All formats are already part of the core
> implementation.
> >> > The api even has no abstraction for formats. In the api its all about
> >> > PropertySource and Configuration, plus functional interfaces to hook
> in
> >> > code for use cases, not more...
> >> >
> >> > Anatole
> >> > Anatole Tresch <at...@gmail.com> schrieb am Mi., 24. Dez. 2014 um
> >> 11:22:
> >> >
> >> >> 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 <st...@yahoo.de>:
> >> >> >
> >> >> > 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
> >> >>
> >>
>
Re: [DISCUSS] increasing complexity of Tamaya
Posted by Romain Manni-Bucau <rm...@gmail.com>.
2014-12-24 13:11 GMT+01:00 Anatole Tresch <at...@gmail.com>:
> To which part of the api do you refer? I don't see the coincidence...
You want a class? noone. The contract here is not in Java but in plain
String - but it is still an API or better a better wording would be a
user contract.
About the topics you mention:
- configuration
- property adapter (functional interface)
- configQuery (funct.interface)
- propertysource
- annotations (tbd, we could move them also to an injection module
separately)
- configurationspi
- servicecontext stuff
I propose to open 1 thread by topic at a time, we all try to not
"leak" on another topic in these threads and once it is validated it
goes to the source code - it means we start from a clean branch
otherwise we'll fight with existing code again.
I'd do this order:
1) PropertySource
2) PropertySource "aggregator" - how are merged conflicting property sources.
3) adapters
4) query
5) Configuration + Configuration SPI - guess this one will be trivial
and ends with up something like Bean Validation or JPA.
6) if needed, service context (5 can make it obsolete IMO)
7) annotations - I guess here we can discuss just before if we speak
about IoC or not. A little stufy of potential integrations could help
as well before getting in the concrete thread IMO
wdyt?
> Romain Manni-Bucau <rm...@gmail.com> schrieb am Mi., 24. Dez. 2014 um
> 12:54:
>
>> the point is while Configuration relies on them imlpicitely (string
>> locations for instance) it is part of the api even if located in the
>> core.
>>
>>
>> Romain Manni-Bucau
>> @rmannibucau
>> http://www.tomitribe.com
>> http://rmannibucau.wordpress.com
>> https://github.com/rmannibucau
>>
>>
>> 2014-12-24 12:45 GMT+01:00 Anatole Tresch <at...@gmail.com>:
>> > Hi Romain/all
>> >
>> > Just to clarify: All formats are already part of the core implementation.
>> > The api even has no abstraction for formats. In the api its all about
>> > PropertySource and Configuration, plus functional interfaces to hook in
>> > code for use cases, not more...
>> >
>> > Anatole
>> > Anatole Tresch <at...@gmail.com> schrieb am Mi., 24. Dez. 2014 um
>> 11:22:
>> >
>> >> 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 <st...@yahoo.de>:
>> >> >
>> >> > 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
>> >>
>>
Re: [DISCUSS] increasing complexity of Tamaya
Posted by Anatole Tresch <at...@gmail.com>.
To which part of the api do you refer? I don't see the coincidence...
Romain Manni-Bucau <rm...@gmail.com> schrieb am Mi., 24. Dez. 2014 um
12:54:
> the point is while Configuration relies on them imlpicitely (string
> locations for instance) it is part of the api even if located in the
> core.
>
>
> Romain Manni-Bucau
> @rmannibucau
> http://www.tomitribe.com
> http://rmannibucau.wordpress.com
> https://github.com/rmannibucau
>
>
> 2014-12-24 12:45 GMT+01:00 Anatole Tresch <at...@gmail.com>:
> > Hi Romain/all
> >
> > Just to clarify: All formats are already part of the core implementation.
> > The api even has no abstraction for formats. In the api its all about
> > PropertySource and Configuration, plus functional interfaces to hook in
> > code for use cases, not more...
> >
> > Anatole
> > Anatole Tresch <at...@gmail.com> schrieb am Mi., 24. Dez. 2014 um
> 11:22:
> >
> >> 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 <st...@yahoo.de>:
> >> >
> >> > 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
> >>
>
Re: [DISCUSS] increasing complexity of Tamaya
Posted by Romain Manni-Bucau <rm...@gmail.com>.
the point is while Configuration relies on them imlpicitely (string
locations for instance) it is part of the api even if located in the
core.
Romain Manni-Bucau
@rmannibucau
http://www.tomitribe.com
http://rmannibucau.wordpress.com
https://github.com/rmannibucau
2014-12-24 12:45 GMT+01:00 Anatole Tresch <at...@gmail.com>:
> Hi Romain/all
>
> Just to clarify: All formats are already part of the core implementation.
> The api even has no abstraction for formats. In the api its all about
> PropertySource and Configuration, plus functional interfaces to hook in
> code for use cases, not more...
>
> Anatole
> Anatole Tresch <at...@gmail.com> schrieb am Mi., 24. Dez. 2014 um 11:22:
>
>> 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 <st...@yahoo.de>:
>> >
>> > 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
>>
Re: [DISCUSS] increasing complexity of Tamaya
Posted by Anatole Tresch <at...@gmail.com>.
We can do that if it helps. Or we can simply focus on the api module only
and discuss what cocerns are there. Build use cases on top of that.
The api currently is quite small ( i further reduced it yesterday).
The main topics to be discussed will not disappear:
1) how, also dtatically (se!) access configuration?
2) is there one config or are there multiple ones? If multiple, how they
are identified?
3) how to add type safety? For me a required api festure, but lets
discuss...
4) how to provide extensibiliy (in java 8 clearly with functional
interfaces)?
5) how to provide configuration (spi) currently modelled as PropertySource,
similar to Deltaspike.
I can tonight also remove write support from the api. Coding of the last
days has shown that it must be modelled separately. Its only rarely used,
and just adding it by default make things much complicated. Given that the
pnly api left would contain:
- configuration
- property adapter (functional interface)
- configQuery (funct.interface)
- propertysource
- annotations (tbd, we could move them also to an injection module
separately)
Spi
- configurationspi
- servicecontext stuff
Wdyt?
Anatole Tresch <at...@gmail.com> schrieb am Mi., 24. Dez. 2014 um 12:45:
> Hi Romain/all
>
> Just to clarify: All formats are already part of the core implementation.
> The api even has no abstraction for formats. In the api its all about
> PropertySource and Configuration, plus functional interfaces to hook in
> code for use cases, not more...
>
> Anatole
> Anatole Tresch <at...@gmail.com> schrieb am Mi., 24. Dez. 2014 um
> 11:22:
>
> 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 <st...@yahoo.de>:
>> >
>> > 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
>>
>
Re: [DISCUSS] increasing complexity of Tamaya
Posted by Anatole Tresch <at...@gmail.com>.
Hi Romain/all
Just to clarify: All formats are already part of the core implementation.
The api even has no abstraction for formats. In the api its all about
PropertySource and Configuration, plus functional interfaces to hook in
code for use cases, not more...
Anatole
Anatole Tresch <at...@gmail.com> schrieb am Mi., 24. Dez. 2014 um 11:22:
> 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 <st...@yahoo.de>:
> >
> > 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
>
Re: [DISCUSS] increasing complexity of Tamaya
Posted by Anatole Tresch <at...@gmail.com>.
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 <st...@yahoo.de>:
>
> 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
Re: [DISCUSS] increasing complexity of Tamaya
Posted by Romain Manni-Bucau <rm...@gmail.com>.
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" <st...@yahoo.de> 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 <at...@gmail.com>
> 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
> > <ge...@gmail.com>:
> >>
> >> 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 <st...@yahoo.de>:
> >>
> >>> 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
> > <jo...@gmail.com>
> >>> 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
> > <st...@yahoo.de>
> >>>> 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
> >>>
> >
>
Re: [DISCUSS] increasing complexity of Tamaya
Posted by Mark Struberg <st...@yahoo.de>.
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 <at...@gmail.com> 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
> <ge...@gmail.com>:
>>
>> 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 <st...@yahoo.de>:
>>
>>> 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
> <jo...@gmail.com>
>>> 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
> <st...@yahoo.de>
>>>> 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
>>>
>
Re: [DISCUSS] increasing complexity of Tamaya
Posted by Anatole Tresch <at...@gmail.com>.
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 <ge...@gmail.com>:
>
> 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 <st...@yahoo.de>:
>
>> 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 <jo...@gmail.com>
>> 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 <st...@yahoo.de>
>>> 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
>>
Re: [DISCUSS] increasing complexity of Tamaya
Posted by Gerhard Petracek <ge...@gmail.com>.
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 <st...@yahoo.de>:
> 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 <jo...@gmail.com>
> 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 <st...@yahoo.de>
> 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
> >>
> >
> >
>
Re: [DISCUSS] increasing complexity of Tamaya
Posted by Mark Struberg <st...@yahoo.de>.
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 <jo...@gmail.com> 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 <st...@yahoo.de> 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
>>
>
>
Re: [DISCUSS] increasing complexity of Tamaya
Posted by "John D. Ament" <jo...@gmail.com>.
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 <st...@yahoo.de> 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
>
Re: [DISCUSS] increasing complexity of Tamaya
Posted by Anatole Tresch <an...@apache.org>.
Hi Oliver
what is for sure: without a starting implementation you well never get
something out. There are too many opinions how things should be and how
not. Not all of us have been facing similar use cases and complexity, and
sometimes it might also be "only" a communication issue. The code forces
you to have a common idea of what should be done. And it is enough precise
to finally know you really understood each other right...
Nevertheless I put together some slides (mostly not in code, attached)
about use cases and the main building blocks. Nothing perfect, but
hopefully it helps to fresh up our minds...
And BTW: I agree, that there is still much room for improvement. I already
removed some classes and artifacts during the last weeks, and I never
stated, everything is in place and finished and ready. But to throw away
everything would be a bad idea, because the existing contains one year plus
of experience, discussions feedback from various experts already. Take it
as a starter and ask questions ;) and hopefully soon most people here on
the list understand, what was the main idea (and basically also what was
implemented). We then can discuss and decide to move things out, be it into
a separate module or into an experimental area.. I assume, we are still in
some kind of first evaluation/getting known phase. I even know of people
that do not have access yet.
Thats similar to a JSR. You simply cannot expect all people to be
streamlined after a few weeks of email discussions. It takes much longer.
Important is that you have respect of each other and their opinions, e.g.
just stating to throw away things and start from scratch is not a very
constructive way to collaborate and does not solve any of the issues and
different view points we face ;).
Best
Anatole
2014-12-23 1:01 GMT+01:00 Oliver B. Fischer <o....@swe-blog.net>:
> Hi all, I think we need this discussion. Let me list my points:
>
> 1. Yes, Tamaya is to complex at the moment.
> 2. It seems to be to complex.
> 3. We do not finish discussions on the list and start to early to
> implement things.
>
> How can we change this?
>
> 1. Let us write down a list of use cases we would like to support.
> 2. Let us discuss how to support these use cases.
>
> Without this approach we will have the same discussions again and again.
>
> Second we should try to keep the API as elegant and minimal as possible
> for simple use cases. Tamaya should also be possible go handle complex use
> cases.
>
> May we shouldn't have started with an existing code base.
>
> Best,
>
> Oliver
>
>
> Von meinem iPhone gesendet
>
> > Am 22.12.2014 um 17:36 schrieb Mark Struberg <st...@yahoo.de>:
> >
> > 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
>
Re: [DISCUSS] increasing complexity of Tamaya
Posted by Werner Keil <we...@gmail.com>.
Werner Keil | JCP Executive Committee Member, JSR 363 Co Spec Lead |
Eclipse UOMo Lead, Babel Language Champion | Apache Committer | Advisory
Board Member, DWX '15
Twitter @wernerkeil | @UnitAPI | @JSR354 | @AgoravaProj | @DeviceMap |
#EclipseUOMo
| #DevOps
Skype werner.keil | Google+ gplus.to/wernerkeil
On Tue, Dec 23, 2014 at 11:04 AM, Romain Manni-Bucau <rm...@gmail.com>
wrote:
>
> >
> >
> >> But it (DeltaSpike) is inheritly connected to CDI and
> >
> > That's just not true. And it's tried and used successfully in many big
> projects (including my own which deals with 50 bn EUR, german stock
> exchange, UK stock exchange, big swiss banks, etc).
> > I'm not saying the DS api is the best, but it is able to do all that and
> is 1/20th of the complexity and size of Tamaya right now. And still being
> more powerful.
> >
>
> It is Mark, at least in term of dependencies, I asked months ago to
> explode core part but it was not the moment I guess ;)
>
>
+1
Even projects deeply inherent to CDI like Agorava use just a few core
modules of DeltaSpike but not config as of now.
I am aware of the history of Commons Config, did use it in a few projects,
but would not do it in many others.
> >
> >>> things not working out of the box: distributed configs
> >
> > For which distributed system?
> > * Ehcache?
> >
> > * Terracotty?
> > * Hadoop like clustering?
> > * a simple shared file store?
> > Where to put the meta-configuration for it? Where to define which one to
> use?
> > What fallback strategies to choose?
> >
>
>
> Never spoke of any technology. Spoke in term of use case: I have 5
> machines which need to read the same config. Constraint I'd like to
> respet is: don't force a "complicated" config like hazelcast one for
> instance.
>
>
Let's not get me started on the Ehcache/JCache issue again;-)
The Cache JSR (107) tried to abstract some of the configuration in ways
one might even find to a small extent in more general purpose configuration
APIs, but it got a rather weird notion and inheritance chain, not really
intuitive, something that better not had been standardized in the first
place, at least not for such a small niche. It does harm to the Java EE (8)
ecosystem as a whole, since there's a large new room in the "Configuration
Hell" already in place;-|
Werner
Re: [DISCUSS] increasing complexity of Tamaya
Posted by Romain Manni-Bucau <rm...@gmail.com>.
2014-12-23 15:33 GMT+01:00 Mark Struberg <st...@yahoo.de>:
> I don't quite get it. All your source pointers to deltaspike did concern the CdiCtrl module. Of course this has CDI dependencies...
>
>
> What I was talking about are the following classes
> https://github.com/apache/deltaspike/blob/master/deltaspike/core/api/src/main/java/org/apache/deltaspike/core/api/config/ConfigResolver.java
> https://github.com/apache/deltaspike/blob/master/deltaspike/core/api/src/main/java/org/apache/deltaspike/core/spi/config/ConfigSource.java
> https://github.com/apache/deltaspike/blob/master/deltaspike/core/api/src/main/java/org/apache/deltaspike/core/spi/config/ConfigFilter.java
> https://github.com/apache/deltaspike/blob/master/deltaspike/core/api/src/main/java/org/apache/deltaspike/core/spi/config/ConfigSourceProvider.java
>
>
> None of them has any CDI dependency. All the CDI functionality is built on top of that.
>
>
>>*About what? Please, please, please give us the concrete use cases, you
>>think Deltaspike supports, or supports better and tamaya does, with as much
>>details possible.
>
> I already gave one. See my first mail. The point is actually the other way around. I'm absolutely sure that we can do the same functionality that Tamaya has today in 1/10 of the code. And having less code usually also means having a much clearer and more flexible system at the end. It's just too bloated and I did read javadocs for two days and had so many wtf moments that all alarm bells did ring.
>
> I understand that the current code is a organically grown system which is tried and proofed in some cases - but that is also it's problem. It's not lean and elegant anymore but just some historically grown piece it seems. I guess that many use cases which are possible within this framework are just not legit anymore.
>
>
>
>>*1) I always stated to have a simple API, just providing a COMPLETE SE API*
>
> Agree
>
>
>>* - config, config templates*
> Agree with config.
>
> But ConfigTemplates are just syntactic sugar. I would not add it. It's just slower and not so easy to grasp for users.
>
>
>>* - injection (also in SE)*
> Disagree. What for? And how? Let's keep this as easy as possible.
>
binding is nice even in SE but I would start with standard injection
cases before to have a common usage.
>
>>* - meta information*
> TOTALLY over engineered. really!
>
>
>>* - support for reacting to config changes.*
> That's trickier. There are 2 ways. Push or Pull.
>
> .) Push means -> sending out an event so config consumers know when to update. The problem is to make this reliable. You e.g. cannot use CDI as this only works with ThreadLocals. You also cannot use Observable as this would cause issues with mem leaks.
>
Not sure I follow you, normally not at all. When using it you have a
"ConfigurationManager" which is just an observer/listener updating the
conf accordingly. Of course its scope should be >= to the conf
one...but if you need this update feature then I'm pretty sure you are
@AppScoped so it is the case.
> .) Pull means -> config consumers who are interested in changed values just call ConfigResolver#getProperty over again. This doesn't cause any performance issues if the config system is well done.
>
This is worse IMO cause it causes refreshing even when not needed and
it impacts directly the app.
>
>
>>* - and support for non String types. *
> We've discussed this in length many times. Every time we started again it became clear pretty quickly that there is such a thing already: JNDI. And that's exactly why it does NOT work. It really sucks.
>
>
>>* - reading config from the classpath, from files and URLs, *
>
> That's the problem. The user is not interested in reading this and that file usually. Like with DI he is usually only interested in the final outcome.
>
>
>
>>* - using properties, xml-properties and ini as file format,*
> Why? The user doesn't care where the values did come from. We should really do this via a pluggable SPI.
> Probably defining a few defaults (which could really include properties, etc). But it's more that we provide a SPI with a few impls of it out of the box. The emphasis is on the SPI and not on those 'sample' impls.
>
>
>
>>* - implementing the type support mentioned, also including collection
>>support (not yet supported)*
> Collections support could be interesting
>
>
>
>>* - and providing configuration combination features.*
> What do you understand by that?
>
>
>>* By default a configuration model is provided, so people can just put
>>their config files at the right locations and start to work. Easy and
>>intuititve. What is wrong here I ask again?*
> Currently we don't provide that. It's just not easy and intuitive right now.
>
>
>
>>*3) ALL THE REST are OPTIONAL EXTENSIONS, like CDI integration,Environment
>>management, more complex configuration models, remote support etc.,
>>remoting, JMX, JAX-RS *
>
> I agree.
>
>
>
> LieGrue,
> strub
>
>
>
>
>
>
>
> On Tuesday, 23 December 2014, 14:37, Anatole Tresch <at...@gmail.com> wrote:
>>Hi Romain/all
>>
>>just a few additions inline...
>>
>>2014-12-23 11:04 GMT+01:00 Romain Manni-Bucau <rm...@gmail.com>:
>>
>>> About Environment and distirbuted system: the issue is the same with
>>> or without. You always need a local config vs the global one but I
>>> strongly think a system property, jndi entry or anything else can be
>>> enough and don't need to be in tamaya itself to start.
>>>
>>> 2014-12-23 10:31 GMT+01:00 Mark Struberg <st...@yahoo.de>:
>>> >> so you can ask the config server for the right config.
>>> > Gosh, that scares me a bit! Don't even think about config servers. Such
>>> things must be totally up to the vendor. We must allow making such things
>>> possible with our API but we shall NOT support such things out of the box!
>>> > The best would be to make our API in a way that even the user
>>> (application programmer) could add such a mechanism to it himself.
>>>
>>*I would not rule that completely out, this is a use case. We should
>>discuss that once we are ready for it (all the basics are in place) how
>>much we can go for it (meaning how much we can support things OOTB)..
>>Definitively it is not part of the core delivery, but could be an optional
>>module to be added.*
>>
>>
>>
>>> >> For me SE comes first. EE builds on top not the other way round!
>>> >
>>> >
>>> > Totally agree with that.
>>> Fine.
>>>
>>
>>
>>> >> But it (DeltaSpike) is inheritly connected to CDI and
>>> >
>>> > That's just not true.
>>
>>*Why, there is a cmpile time depoendency to cdictl-se,
>>see https://git-wip-us.apache.org/repos/asf?p=deltaspike.git;a=blob_plain;f=deltaspike/pom.xml;hb=HEAD
>><https://git-wip-us.apache.org/repos/asf?p=deltaspike.git;a=blob_plain;f=deltaspike/pom.xml;hb=HEAD>*
>>
>>*As a code example people here on the list my have a look at
>>https://git-wip-us.apache.org/repos/asf?p=deltaspike.git;a=blob_plain;f=deltaspike/cdictrl/api/src/main/java/org/apache/deltaspike/cdise/api/CdiContainer.java;hb=HEAD
>><https://git-wip-us.apache.org/repos/asf?p=deltaspike.git;a=blob_plain;f=deltaspike/cdictrl/api/src/main/java/org/apache/deltaspike/cdise/api/CdiContainer.java;hb=HEAD>*
>>**
>>*Or they look at the @ConfiguredPropertyx annotation:
>>https://git-wip-us.apache.org/repos/asf?p=deltaspike.git;a=blob_plain;f=deltaspike/core/api/src/main/java/org/apache/deltaspike/core/api/config/ConfigProperty.java;hb=HEAD
>><https://git-wip-us.apache.org/repos/asf?p=deltaspike.git;a=blob_plain;f=deltaspike/core/api/src/main/java/org/apache/deltaspike/core/api/config/ConfigProperty.java;hb=HEAD>*
>>
>>*and they see:*
>>
>>*import javax.enterprise.util.Nonbinding;
>>import javax.inject.Qualifier;*
>>
>>
>>And it's tried and used successfully in many big projects (including my own
>>> which deals with 50 bn EUR, german stock exchange, UK stock exchange, big
>>> swiss banks, etc).
>>> > I'm not saying the DS api is the best, but it is able to do all that and
>>> is 1/20th of the complexity and size of Tamaya right now. And still being
>>> more powerful.
>>>
>>
>>*About what? Please, please, please give us the concrete use cases, you
>>think Deltaspike supports, or supports better and tamaya does, with as much
>>details possible. That is the only way we*
>>*a) can bullet.proof our considerations and also see, where our use cases
>>differ.*
>>*b) really compare concepts, instead of just arguing that things are much
>>more complex.*
>>*c) help also to get a better understanding of the concepts in place so far
>>and see how things can be improved.*
>>
>>
>>
>>> It is Mark, at least in term of dependencies, I asked months ago to
>>> explode core part but it was not the moment I guess ;)
>>>
>>> >
>>> >>> things not working out of the box: distributed configs
>>> >
>>> > For which distributed system?
>>> > * Ehcache?
>>> >
>>> > * Terracotty?
>>> > * Hadoop like clustering?
>>> > * a simple shared file store?
>>> > Where to put the meta-configuration for it? Where to define which one to
>>> use?
>>> > What fallback strategies to choose?
>>> >
>>>
>>>
>>> Never spoke of any technology. Spoke in term of use case: I have 5
>>> machines which need to read the same config. Constraint I'd like to
>>> respet is: don't force a "complicated" config like hazelcast one for
>>> instance.
>>>
>>> > All that HEAVILY depends on the situation and scenario you have in your
>>> project. There is just nothing we can decide for the customer. All we can
>>> do is to make it VERY EASY to implement it yourself.
>>> >
>>> > For example: In DeltaSpike adding a ConfigSource for a config file on a
>>> shared folder is a mere 7 lines of code..
>>> In Tamaya, it will be about one line ;)
>>>
>>
>>
>>> Here the is issue: it needs you to code. This is not a feature of the
>>> framework.
>>>
>>> > Please don't let us go down the (old) Spring route to have miles of
>>> configuration for stuff which you could hack in just a few lines of code.
>>> >
>>>
>>> In practise you don't always have the choice
>>
>>
>>*It all about options. I did never state that all features must end up in
>>core:*
>>*1) I always stated to have a simple API, just providing a COMPLETE SE API*
>>
>>* - config, config templates*
>>* - injection (also in SE)*
>>* - meta information*
>>* - support for reacting to config changes.*
>>* - and support for non String types. *
>>
>>* There is no more there, so I ask what is really wrong here? If its OK,
>>let's go ahead and focus on core.*
>>
>>*2) In core I would expect to have a minimal runtime implementation that
>>provides all features needed to cover most of the needs, meaning*
>>
>>* - reading config from the classpath, from files and URLs, *
>>* - using properties, xml-properties and ini as file format,*
>>* - implementing the type support mentioned, also including collection
>>support (not yet supported)*
>>* - and providing configuration combination features.*
>>
>>* By default a configuration model is provided, so people can just put
>>their config files at the right locations and start to work. Easy and
>>intuititve. What is wrong here I ask again?*
>>
>>*3) ALL THE REST are OPTIONAL EXTENSIONS, like CDI integration,Environment
>>management, more complex configuration models, remote support etc.,
>>remoting, JMX, JAX-RS *
>>* support and *
>>*whatever we (and users) think would be useful. When users are happy with
>>the module provided (we will hopefully have lots of discussions in the
>>next months and years to do it right), they may *
>>*use it OOTB. If not they can still write their own. It's all about
>>options, like in Java EE (Arun Gupta) ;)*
>>* *
>>
>>>>> we can start as
>>> >>> easy as reading a database
>>> >
>>> > We discussed this in DeltaSpike and deliberately did NOT add it. It's
>>> really really easy to implement a ConfigSource which goes into the DB
>>> yourself in 30 minutes.
>>> >
>>> > If we would provide this feature out of the box, then how would you do
>>> that?
>>> > * which database would you address?
>>> >
>>> > * JPA or JDBC native? again: what about the db vendor?
>>> > * how to configure your db user, your schema, etc?
>>> > * what about update and caching policies?
>>> > We would need some jar with JPA or whatever as dependency. Would need
>>> meta-configuration, yada yada yada. And all to avoid 100 lines of code?
>>> That just doesn't pay off!
>>> >
>>>
>>> That's why I spoke about a "push" system. Then we just use java 7 file
>>> system watch solution.
>>
>>*That is modelled by the ConfigChangeSet, which contains a reference to
>>the current configuration and infos on the properties changed. This change
>>set can be applied to a config (pull scenario) or *
>>*published based on changes in the backenbd (push scenario).*
>>
>>
>>> > Probably add some sample code somewhere. It must be easily doable within
>>> our API but we should not try to implement that by default in our core jar.
>>>
>>
>>*As mentioned it was never targeting core ;)*
>>
>>
>>
>>> >>> it include crud
>>> >
>>> >>> api but also a GUI - and listeners/update events.
>>> >
>>> > Totally overengineered imo. How should a GUI look like which might
>>> change configuration in a Haddop Cluster or in a Docker installation? Or
>>> whatever comes around the corner next year... Just DON'T DO IT.
>>>
>>
>>*Basically, what is possible is to provide introsepction in existing
>>configuration. This is helpful for error analysis. More details here are to
>>be discussed. I don't see this as a core feature, but we must have it in
>>mind. Discussions will show, what is possible, But as before, don't rule
>>out everything, just before you are scared about it. If there is a need,
>>there must be at least a discussion. First things perhaps for @all: always
>>think if a use case should be part of the API, the core minimal
>>implementation, or an optional extension.*
>>
>>
>>
>>
>>> > There is of course an important very basic underlying design question:
>>> How to treat configured values which are non-mutable and might get cached
>>> vs ones which might change during the application lifetime?
>>> > Also: Do we like to introduce an own API for value-reload or do we
>>> leverage JMX?
>>> >
>>> > THOSE are the things I like to get clarified before we touch ANY code!
>>> >
>>> >
>>>
>>> JMX is mandatory IMO but JAXRS as well.
>>>
>>> *+1 *
>>
>>--
>>*Anatole Tresch*
>>Java Engineer & Architect, JSR Spec Lead
>>Glärnischweg 10
>>CH - 8620 Wetzikon
>>
>>*Switzerland, Europe Zurich, GMT+1*
>>*Twitter: @atsticks*
>>*Blogs: **http://javaremarkables.blogspot.ch/
>><http://javaremarkables.blogspot.ch/>*
>>
>>*Google: atsticksMobile +41-76 344 62 79 <%2B41-76%20344%2062%2079>*
>>
>>
Re: [DISCUSS] increasing complexity of Tamaya
Posted by Anatole Tresch <at...@gmail.com>.
Yes, I think this is the best way. I would wait with it until 5th or 6th of
January, when people are back from holidays.
I will later then make a proposal for the vote and if we agree on that, we
should do the vote...
2014-12-27 15:20 GMT+01:00 John D. Ament <jo...@apache.org>:
> As best as I can tell from reading this thread, there is no clear winner.
> I would recommend you guys hold a vote first before making any changes
> requested within here.
>
> On Wed Dec 24 2014 at 10:30:36 AM Werner Keil <we...@gmail.com>
> wrote:
>
> > Huge thread, so I'll stick to the format question for now, see inline.
> >
> > On Wed, Dec 24, 2014 at 9:56 AM, Oliver B. Fischer <
> > o.b.fischer@swe-blog.net
> > > wrote:
> >
> > > See inline...
> > > Am 24.12.14 um 02:07 schrieb Anatole Tresch:
> > >
> > >> 3.) Should we define any configuration formats, and if so which one?
> > >> *-> I would like to see a minimal set of formats in core, so we can
> > >> provide a minimal dependency version that fits most needs.
> > >> .properties,
> > >> .xml(properties) and .ini I think is a good set, but definitively not
> > >> more.*
> > >> *-> We can then leverage apache commons config with bridges in the
> > >> extension modules for suporting additional formats ;). *
> > >>
> > >
> > > At my company we use mostly
> https://github.com/typesafehub/config/blob/
> > > master/HOCON.md and YAML. For me only property files and the other
> > > mentioned formats feel a little bit outdated. Not only because they
> exist
> > > already for a long time but for their usability.
> > >
> > > Writing large configurations is mostly about structuring the
> information
> > > you provide. In this area are property files weak and no one wants XML
> > > again. If I would tell this someone around me the answer would be:
> "Come
> > > back if you have something more usefull."
> > >
> > >
> > In one of the largest clouds outside the infrastructure of the likes of
> > Google, Amazon, Microsoft, etc. (on top of Kokki/Multiconf) we used JSON
> > and some components also used YAML. However, these are just the DevOps
> > duties like build management and processing with some management,
> > provisioning and monitoring of the actual servers, too.
> >
> > When it comes to configuration of various Enterprise Containers and Java
> EE
> > applications to be deployed there in all the various stages, XML rules.
> And
> > those who really think for the actual Java part everything can be done
> > purely with annotations probably also insist, Santa is coming through
> their
> > chimney tonight ;-D
> >
> > Purely annotation based solutions are nice to do quick demos, but if you
> > need true staging all the way from your local development box to a giant
> > cluster in production, at least the server and containers requires loads
> of
> > XML to provision it correctly for each container, and without touching
> and
> > changing the code for every step, there is practically no production
> ready
> > app servers today supporting that, even if the app may truly be written
> > just with annotations supporting everything from local dev boxes to
> > production, then the slightest change in each of these phases would still
> > break everything. And those large cloud solutions by big vendors normally
> > get deployed by others that are not supposed to build and compile your
> app
> > again;-) OSGi sounded promising also for EE containers, but Glassfish
> > (which had some good support for it) is merely the Java EE RI now and
> JBoss
> > WildFly also removed it. So dynamic loading and injection of components
> at
> > runtime becomes harder.
> >
> > I also looked into HOCON which is a nice approach, though a bit limited.
> > Fortunately, what it admits to be missing, Java is getting as a standard
> > these days, a unit subsystem (JSR 363). On the monitoring front, Parfait
> > https://code.google.com/p/parfait/ shows how the earlier JSR (275) is
> used
> > for support of MB, GB, etc. but also other vital signs of the system if
> > needed like temperature (seamless and typesafe whether it's °C or F;-) US
> > Smart Grid vendor Opower wrote a JSON binding solution around Unit-API
> > (0.6, the "missing link" betweeen 275 and 363) so supporting formats like
> > JSON for data exchange also works. There's an upcoming JSR for JSON-B, so
> > maybe under Java EE 8 or with this on its own, you may use Java EE
> > standards there, too, until then alternatives like Jackson or GSON, do,
> > too.
> >
> > Merry Christmas,
> >
> > Werner Keil | JCP Executive Committee Member, JSR 363 Co Spec Lead |
> > Eclipse UOMo Lead, Babel Language Champion | Apache Committer | Advisory
> > Board Member, DWX '15
> >
> > Twitter @wernerkeil | @UnitAPI | @JSR354 | @AgoravaProj | @DeviceMap |
> > #EclipseUOMo
> > | #DevOps
> > Skype werner.keil | Google+ gplus.to/wernerkeil
> >
>
--
*Anatole Tresch*
Java Engineer & Architect, JSR Spec Lead
Glärnischweg 10
CH - 8620 Wetzikon
*Switzerland, Europe Zurich, GMT+1*
*Twitter: @atsticks*
*Blogs: **http://javaremarkables.blogspot.ch/
<http://javaremarkables.blogspot.ch/>*
*Google: atsticksMobile +41-76 344 62 79*
Re: [DISCUSS] increasing complexity of Tamaya
Posted by "John D. Ament" <jo...@apache.org>.
As best as I can tell from reading this thread, there is no clear winner.
I would recommend you guys hold a vote first before making any changes
requested within here.
On Wed Dec 24 2014 at 10:30:36 AM Werner Keil <we...@gmail.com> wrote:
> Huge thread, so I'll stick to the format question for now, see inline.
>
> On Wed, Dec 24, 2014 at 9:56 AM, Oliver B. Fischer <
> o.b.fischer@swe-blog.net
> > wrote:
>
> > See inline...
> > Am 24.12.14 um 02:07 schrieb Anatole Tresch:
> >
> >> 3.) Should we define any configuration formats, and if so which one?
> >> *-> I would like to see a minimal set of formats in core, so we can
> >> provide a minimal dependency version that fits most needs.
> >> .properties,
> >> .xml(properties) and .ini I think is a good set, but definitively not
> >> more.*
> >> *-> We can then leverage apache commons config with bridges in the
> >> extension modules for suporting additional formats ;). *
> >>
> >
> > At my company we use mostly https://github.com/typesafehub/config/blob/
> > master/HOCON.md and YAML. For me only property files and the other
> > mentioned formats feel a little bit outdated. Not only because they exist
> > already for a long time but for their usability.
> >
> > Writing large configurations is mostly about structuring the information
> > you provide. In this area are property files weak and no one wants XML
> > again. If I would tell this someone around me the answer would be: "Come
> > back if you have something more usefull."
> >
> >
> In one of the largest clouds outside the infrastructure of the likes of
> Google, Amazon, Microsoft, etc. (on top of Kokki/Multiconf) we used JSON
> and some components also used YAML. However, these are just the DevOps
> duties like build management and processing with some management,
> provisioning and monitoring of the actual servers, too.
>
> When it comes to configuration of various Enterprise Containers and Java EE
> applications to be deployed there in all the various stages, XML rules. And
> those who really think for the actual Java part everything can be done
> purely with annotations probably also insist, Santa is coming through their
> chimney tonight ;-D
>
> Purely annotation based solutions are nice to do quick demos, but if you
> need true staging all the way from your local development box to a giant
> cluster in production, at least the server and containers requires loads of
> XML to provision it correctly for each container, and without touching and
> changing the code for every step, there is practically no production ready
> app servers today supporting that, even if the app may truly be written
> just with annotations supporting everything from local dev boxes to
> production, then the slightest change in each of these phases would still
> break everything. And those large cloud solutions by big vendors normally
> get deployed by others that are not supposed to build and compile your app
> again;-) OSGi sounded promising also for EE containers, but Glassfish
> (which had some good support for it) is merely the Java EE RI now and JBoss
> WildFly also removed it. So dynamic loading and injection of components at
> runtime becomes harder.
>
> I also looked into HOCON which is a nice approach, though a bit limited.
> Fortunately, what it admits to be missing, Java is getting as a standard
> these days, a unit subsystem (JSR 363). On the monitoring front, Parfait
> https://code.google.com/p/parfait/ shows how the earlier JSR (275) is used
> for support of MB, GB, etc. but also other vital signs of the system if
> needed like temperature (seamless and typesafe whether it's °C or F;-) US
> Smart Grid vendor Opower wrote a JSON binding solution around Unit-API
> (0.6, the "missing link" betweeen 275 and 363) so supporting formats like
> JSON for data exchange also works. There's an upcoming JSR for JSON-B, so
> maybe under Java EE 8 or with this on its own, you may use Java EE
> standards there, too, until then alternatives like Jackson or GSON, do,
> too.
>
> Merry Christmas,
>
> Werner Keil | JCP Executive Committee Member, JSR 363 Co Spec Lead |
> Eclipse UOMo Lead, Babel Language Champion | Apache Committer | Advisory
> Board Member, DWX '15
>
> Twitter @wernerkeil | @UnitAPI | @JSR354 | @AgoravaProj | @DeviceMap |
> #EclipseUOMo
> | #DevOps
> Skype werner.keil | Google+ gplus.to/wernerkeil
>
Re: [DISCUSS] increasing complexity of Tamaya
Posted by Werner Keil <we...@gmail.com>.
Huge thread, so I'll stick to the format question for now, see inline.
On Wed, Dec 24, 2014 at 9:56 AM, Oliver B. Fischer <o.b.fischer@swe-blog.net
> wrote:
> See inline...
> Am 24.12.14 um 02:07 schrieb Anatole Tresch:
>
>> 3.) Should we define any configuration formats, and if so which one?
>> *-> I would like to see a minimal set of formats in core, so we can
>> provide a minimal dependency version that fits most needs.
>> .properties,
>> .xml(properties) and .ini I think is a good set, but definitively not
>> more.*
>> *-> We can then leverage apache commons config with bridges in the
>> extension modules for suporting additional formats ;). *
>>
>
> At my company we use mostly https://github.com/typesafehub/config/blob/
> master/HOCON.md and YAML. For me only property files and the other
> mentioned formats feel a little bit outdated. Not only because they exist
> already for a long time but for their usability.
>
> Writing large configurations is mostly about structuring the information
> you provide. In this area are property files weak and no one wants XML
> again. If I would tell this someone around me the answer would be: "Come
> back if you have something more usefull."
>
>
In one of the largest clouds outside the infrastructure of the likes of
Google, Amazon, Microsoft, etc. (on top of Kokki/Multiconf) we used JSON
and some components also used YAML. However, these are just the DevOps
duties like build management and processing with some management,
provisioning and monitoring of the actual servers, too.
When it comes to configuration of various Enterprise Containers and Java EE
applications to be deployed there in all the various stages, XML rules. And
those who really think for the actual Java part everything can be done
purely with annotations probably also insist, Santa is coming through their
chimney tonight ;-D
Purely annotation based solutions are nice to do quick demos, but if you
need true staging all the way from your local development box to a giant
cluster in production, at least the server and containers requires loads of
XML to provision it correctly for each container, and without touching and
changing the code for every step, there is practically no production ready
app servers today supporting that, even if the app may truly be written
just with annotations supporting everything from local dev boxes to
production, then the slightest change in each of these phases would still
break everything. And those large cloud solutions by big vendors normally
get deployed by others that are not supposed to build and compile your app
again;-) OSGi sounded promising also for EE containers, but Glassfish
(which had some good support for it) is merely the Java EE RI now and JBoss
WildFly also removed it. So dynamic loading and injection of components at
runtime becomes harder.
I also looked into HOCON which is a nice approach, though a bit limited.
Fortunately, what it admits to be missing, Java is getting as a standard
these days, a unit subsystem (JSR 363). On the monitoring front, Parfait
https://code.google.com/p/parfait/ shows how the earlier JSR (275) is used
for support of MB, GB, etc. but also other vital signs of the system if
needed like temperature (seamless and typesafe whether it's °C or F;-) US
Smart Grid vendor Opower wrote a JSON binding solution around Unit-API
(0.6, the "missing link" betweeen 275 and 363) so supporting formats like
JSON for data exchange also works. There's an upcoming JSR for JSON-B, so
maybe under Java EE 8 or with this on its own, you may use Java EE
standards there, too, until then alternatives like Jackson or GSON, do, too.
Merry Christmas,
Werner Keil | JCP Executive Committee Member, JSR 363 Co Spec Lead |
Eclipse UOMo Lead, Babel Language Champion | Apache Committer | Advisory
Board Member, DWX '15
Twitter @wernerkeil | @UnitAPI | @JSR354 | @AgoravaProj | @DeviceMap |
#EclipseUOMo
| #DevOps
Skype werner.keil | Google+ gplus.to/wernerkeil
Re: [DISCUSS] increasing complexity of Tamaya
Posted by Romain Manni-Bucau <rm...@gmail.com>.
as mentionned in another answer I think we can remove it from the API
and add it in our default *implementation* of "configuration
providers". I agree this feature is nice but I also agree with Mark:
this is nota first citizen of the API.
Romain Manni-Bucau
@rmannibucau
http://www.tomitribe.com
http://rmannibucau.wordpress.com
https://github.com/rmannibucau
2014-12-24 10:07 GMT+01:00 Anatole Tresch <at...@gmail.com>:
> Hi Oliver
>
> basic legit arguments, and I agree of the formats mentioned are not the
> ultimate winners. So the question goes to all: what do the other here on
> the list think on a default configuration formats...
>
> Cheers,
> Anatole
>
> 2014-12-24 9:56 GMT+01:00 Oliver B. Fischer <o....@swe-blog.net>:
>
>> See inline...
>> Am 24.12.14 um 02:07 schrieb Anatole Tresch:
>>
>>> 3.) Should we define any configuration formats, and if so which one?
>>> *-> I would like to see a minimal set of formats in core, so we can
>>> provide a minimal dependency version that fits most needs.
>>> .properties,
>>> .xml(properties) and .ini I think is a good set, but definitively not
>>> more.*
>>> *-> We can then leverage apache commons config with bridges in the
>>> extension modules for suporting additional formats ;). *
>>>
>>
>> At my company we use mostly https://github.com/typesafehub/config/blob/
>> master/HOCON.md and YAML. For me only property files and the other
>> mentioned formats feel a little bit outdated. Not only because they exist
>> already for a long time but for their usability.
>>
>> Writing large configurations is mostly about structuring the information
>> you provide. In this area are property files weak and no one wants XML
>> again. If I would tell this someone around me the answer would be: "Come
>> back if you have something more usefull."
>>
>> --
>> N Oliver B. Fischer
>> A Schönhauser Allee 64, 10437 Berlin, Deutschland/Germany
>> P +49 30 44793251
>> M +49 178 7903538
>> E o.b.fischer@swe-blog.net
>> S oliver.b.fischer
>> J oliver.b.fischer@jabber.org
>> X http://xing.to/obf
>>
>>
>
>
> --
> *Anatole Tresch*
> Java Engineer & Architect, JSR Spec Lead
> Glärnischweg 10
> CH - 8620 Wetzikon
>
> *Switzerland, Europe Zurich, GMT+1*
> *Twitter: @atsticks*
> *Blogs: **http://javaremarkables.blogspot.ch/
> <http://javaremarkables.blogspot.ch/>*
>
> *Google: atsticksMobile +41-76 344 62 79*
Re: [DISCUSS] increasing complexity of Tamaya
Posted by Anatole Tresch <at...@gmail.com>.
Hi Oliver
basic legit arguments, and I agree of the formats mentioned are not the
ultimate winners. So the question goes to all: what do the other here on
the list think on a default configuration formats...
Cheers,
Anatole
2014-12-24 9:56 GMT+01:00 Oliver B. Fischer <o....@swe-blog.net>:
> See inline...
> Am 24.12.14 um 02:07 schrieb Anatole Tresch:
>
>> 3.) Should we define any configuration formats, and if so which one?
>> *-> I would like to see a minimal set of formats in core, so we can
>> provide a minimal dependency version that fits most needs.
>> .properties,
>> .xml(properties) and .ini I think is a good set, but definitively not
>> more.*
>> *-> We can then leverage apache commons config with bridges in the
>> extension modules for suporting additional formats ;). *
>>
>
> At my company we use mostly https://github.com/typesafehub/config/blob/
> master/HOCON.md and YAML. For me only property files and the other
> mentioned formats feel a little bit outdated. Not only because they exist
> already for a long time but for their usability.
>
> Writing large configurations is mostly about structuring the information
> you provide. In this area are property files weak and no one wants XML
> again. If I would tell this someone around me the answer would be: "Come
> back if you have something more usefull."
>
> --
> N Oliver B. Fischer
> A Schönhauser Allee 64, 10437 Berlin, Deutschland/Germany
> P +49 30 44793251
> M +49 178 7903538
> E o.b.fischer@swe-blog.net
> S oliver.b.fischer
> J oliver.b.fischer@jabber.org
> X http://xing.to/obf
>
>
--
*Anatole Tresch*
Java Engineer & Architect, JSR Spec Lead
Glärnischweg 10
CH - 8620 Wetzikon
*Switzerland, Europe Zurich, GMT+1*
*Twitter: @atsticks*
*Blogs: **http://javaremarkables.blogspot.ch/
<http://javaremarkables.blogspot.ch/>*
*Google: atsticksMobile +41-76 344 62 79*
Re: [DISCUSS] increasing complexity of Tamaya
Posted by "Oliver B. Fischer" <o....@swe-blog.net>.
See inline...
Am 24.12.14 um 02:07 schrieb Anatole Tresch:
> 3.) Should we define any configuration formats, and if so which one?
> *-> I would like to see a minimal set of formats in core, so we can
> provide a minimal dependency version that fits most needs. .properties,
> .xml(properties) and .ini I think is a good set, but definitively not more.*
> *-> We can then leverage apache commons config with bridges in the
> extension modules for suporting additional formats ;). *
At my company we use mostly
https://github.com/typesafehub/config/blob/master/HOCON.md and YAML. For
me only property files and the other mentioned formats feel a little bit
outdated. Not only because they exist already for a long time but for
their usability.
Writing large configurations is mostly about structuring the information
you provide. In this area are property files weak and no one wants XML
again. If I would tell this someone around me the answer would be: "Come
back if you have something more usefull."
--
N Oliver B. Fischer
A Schönhauser Allee 64, 10437 Berlin, Deutschland/Germany
P +49 30 44793251
M +49 178 7903538
E o.b.fischer@swe-blog.net
S oliver.b.fischer
J oliver.b.fischer@jabber.org
X http://xing.to/obf
Re: [DISCUSS] increasing complexity of Tamaya
Posted by Anatole Tresch <at...@gmail.com>.
Hi Mark
just a few inline...
2014-12-23 23:52 GMT+01:00 Mark Struberg <st...@yahoo.de>:
> Again: I already gave you a use case, please solve it with Tamaya.
> Then tell me your use cases and we gonna do ping pong until we find a
> common understanding and view.
> That's nothing personal, it's just technically trying to deduct the code
> and slice it down to the minimum necessary parts.
> We did the same in CDI and nowadays most people are happy that we e.g.
> didn't leave all the xml configuration stuff in there but instead
> introduced modularity and extensions ...
>
>
> I also don't have much to do with the Apache Brand (besides being an ASF
> member). I'm here as an individual PMC member like every other. My
> mentorship also has not much impact. What does have an impact is that I'm
> reaching for nothing less than the best solution.
>
>
>
> > And you know that all code
> > here is completely legacy, historically grown, ugly, outdated and more.
> You
> > obviously have a crystal ball, i am just wonderin.
>
> At the very beginning we all agreed to first discuss the basic principals.
> But right after that you instead imported your old code base and started to
> hack on it. I had expected that this is just or reviewing pieces and
> 'cherry-pick' parts of it which fit. But instead it was taken 1:1 and just
> 'enhanced'. From the ideas this is basically the same like it used to be 2
> years ago. So yes, this is not new code (you btw said this yourself a dozen
> times). Of course we just blame ourselves that we didn't reach out earlier.
> It's also not all bad, but there are parts which I really think are way out
> of scope to later become a JSR.
*The JSRs main scope will be the API mainly. So core parts are not the
essence here ;) But definitively the code base is not production ready
(there are even no tests). Nevertheless I think hacking was not that bad as
well, since sometimes we also struggled with the English here, so it helps
as well to get an understanding of some ideas, though I agree, some
confusion would be avoidable as well...*
> > Additionally, even your first interface has a dep on the Typed
> annotation for
> > example
> The @Typed is only to make really old Weld impls not blow up when scanning
> this class. It's really not needed anymore today.
>
> *Fair enough. *
>
> We need to finally start with a few very basic decisions and work through
> them. I already enlisted a few of them but I'm happy to enumerate them
> again.
>
> *Thanks. *
>
>
> 1.) Should the configuration mechanism be String or Object?
>
*-> the configuration mechanism IMO should strictly based on Strings.
Types are very simple adaptors on top of the String values, nothing more.
Tamaya should never store non String objects into*
*its properties. *
>
> 2.) Should we have native methods to read and write various ini file
> formats, or is this just not our business?
*-> I would like to help users here to have code at their fingertipps that
helps a lot. The ant-styled resolution of classpath and files has proven to
be very handy. URLs are basically syntactic sugar on top. All the rest I
would like to have better feedback from users, to see what makes sense. But
I definitively do not see anything more as core parts here.*
3.) Should we define any configuration formats, and if so which one?
>
*-> I would like to see a minimal set of formats in core, so we can
provide a minimal dependency version that fits most needs. .properties,
.xml(properties) and .ini I think is a good set, but definitively not more.*
*-> We can then leverage apache commons config with bridges in the
extension modules for suporting additional formats ;). *
>
> 4.) Do we really need writeable configuration in our API?
>
*I also struggled a lot with that. I personally never needed writable
config, but several people explicitly are asking for mutability. What I did
so far, was to try to control the side effects of mutability. I think we
should take that topic up with our colluegues here, I am personally open
to whatever is the outcome here...*
*Anatole*
>
>
>
> LieGrue,
> strub
>
>
>
> > On Tuesday, 23 December 2014, 18:37, Anatole Tresch <at...@gmail.com>
> wrote:
> > > Hi Mark
> >
> > I must say I am totally surprised of your mails. Obviously you know
> things
> > better than all the other people and experts i have talked so far. You
> even know
> > what all users think and what all companies need. And you know that all
> code
> > here is completely legacy, historically grown, ugly, outdated and more.
> You
> > obviously have a crystal ball, i am just wondering
> >
> > I will not reply in detail on the last mail. It is full of fuzzy
> arguments.
> > Nothing concrete. Just claims how things should be iyo. Just claims that
> you can
> > do the same in 1/10, but you even struggle with the basic api, which is
> quite
> > small compared to most other apis in that area. You write about concerns
> about
> > memory leaks though the facts we have more than enough mechanisms to
> manage weak
> > refs and we have a couple of experts in our team that know well both se
> as well
> > as ee both in theory and in practice.
> > Additionally, even your first interface has a dep on the Typed
> annotation for
> > example, so I struggle to take this kind of feedback seriously. Its not
> > constructive, its not precise, I think it is respectless to the people
> working
> > here, and even worse it stops us foing our work and imo it matches not
> what I
> > expected from the Apache Brand, especially a project mentor. Sorry to
> say it so
> > frankly.
> >
> > Other opinions are welcome.
> >
> > -
> > Anatole Tresch
> > Glärnischweg 10
> > 8620 Wetzikon
> > Tel +41 (43) 317 05 30
> > -
> > Send from Mobile
> >
> >
> >> Am 23.12.2014 um 15:33 schrieb Mark Struberg <st...@yahoo.de>:
> >>
> >> I don't quite get it. All your source pointers to deltaspike did
> > concern the CdiCtrl module. Of course this has CDI dependencies...
> >>
> >>
> >> What I was talking about are the following classes
> >>
> >
> https://github.com/apache/deltaspike/blob/master/deltaspike/core/api/src/main/java/org/apache/deltaspike/core/api/config/ConfigResolver.java
> >>
> >
> https://github.com/apache/deltaspike/blob/master/deltaspike/core/api/src/main/java/org/apache/deltaspike/core/spi/config/ConfigSource.java
> >>
> >
> https://github.com/apache/deltaspike/blob/master/deltaspike/core/api/src/main/java/org/apache/deltaspike/core/spi/config/ConfigFilter.java
> >>
> >
> https://github.com/apache/deltaspike/blob/master/deltaspike/core/api/src/main/java/org/apache/deltaspike/core/spi/config/ConfigSourceProvider.java
> >>
> >>
> >> None of them has any CDI dependency. All the CDI functionality is
> built on
> > top of that.
> >>
> >>
> >>> *About what? Please, please, please give us the concrete use cases,
> > you
> >>> think Deltaspike supports, or supports better and tamaya does, with as
> > much
> >>> details possible.
> >>
> >> I already gave one. See my first mail. The point is actually the other
> way
> > around. I'm absolutely sure that we can do the same functionality that
> > Tamaya has today in 1/10 of the code. And having less code usually also
> means
> > having a much clearer and more flexible system at the end. It's just too
> > bloated and I did read javadocs for two days and had so many wtf moments
> that
> > all alarm bells did ring.
> >>
> >> I understand that the current code is a organically grown system which
> is
> > tried and proofed in some cases - but that is also it's problem. It's
> > not lean and elegant anymore but just some historically grown piece it
> seems. I
> > guess that many use cases which are possible within this framework are
> just not
> > legit anymore.
> >>
> >>
> >>
> >>> *1) I always stated to have a simple API, just providing a COMPLETE SE
> > API*
> >>
> >> Agree
> >>
> >>
> >>> * - config, config templates*
> >> Agree with config.
> >>
> >> But ConfigTemplates are just syntactic sugar. I would not add it. It's
> > just slower and not so easy to grasp for users.
> >>
> >>
> >>> * - injection (also in SE)*
> >> Disagree. What for? And how? Let's keep this as easy as possible.
> >>
> >>
> >>> * - meta information*
> >> TOTALLY over engineered. really!
> >>
> >>
> >>> * - support for reacting to config changes.*
> >> That's trickier. There are 2 ways. Push or Pull.
> >>
> >> .) Push means -> sending out an event so config consumers know when to
> > update. The problem is to make this reliable. You e.g. cannot use CDI as
> this
> > only works with ThreadLocals. You also cannot use Observable as this
> would cause
> > issues with mem leaks.
> >>
> >> .) Pull means -> config consumers who are interested in changed values
> > just call ConfigResolver#getProperty over again. This doesn't cause any
> > performance issues if the config system is well done.
> >>
> >>
> >>
> >>> * - and support for non String types. *
> >> We've discussed this in length many times. Every time we started again
> > it became clear pretty quickly that there is such a thing already: JNDI.
> And
> > that's exactly why it does NOT work. It really sucks.
> >>
> >>
> >>> * - reading config from the classpath, from files and URLs, *
> >>
> >> That's the problem. The user is not interested in reading this and that
> > file usually. Like with DI he is usually only interested in the final
> outcome.
> >>
> >>
> >>
> >>> * - using properties, xml-properties and ini as file format,*
> >> Why? The user doesn't care where the values did come from. We should
> > really do this via a pluggable SPI.
> >> Probably defining a few defaults (which could really include
> properties,
> > etc). But it's more that we provide a SPI with a few impls of it out of
> the
> > box. The emphasis is on the SPI and not on those 'sample' impls.
> >>
> >>
> >>
> >>> * - implementing the type support mentioned, also including
> > collection
> >>> support (not yet supported)*
> >> Collections support could be interesting
> >>
> >>
> >>
> >>> * - and providing configuration combination features.*
> >> What do you understand by that?
> >>
> >>
> >>> * By default a configuration model is provided, so people can just
> > put
> >>> their config files at the right locations and start to work. Easy and
> >>> intuititve. What is wrong here I ask again?*
> >> Currently we don't provide that. It's just not easy and intuitive
> > right now.
> >>
> >>
> >>
> >>> *3) ALL THE REST are OPTIONAL EXTENSIONS, like CDI
> > integration,Environment
> >>> management, more complex configuration models, remote support etc.,
> >>> remoting, JMX, JAX-RS *
> >>
> >> I agree.
> >>
> >>
> >>
> >> LieGrue,
> >> strub
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>> On Tuesday, 23 December 2014, 14:37, Anatole Tresch
> > <at...@gmail.com> wrote:
> >>> Hi Romain/all
> >>>
> >>> just a few additions inline...
> >>>
> >>> 2014-12-23 11:04 GMT+01:00 Romain Manni-Bucau
> > <rm...@gmail.com>:
> >>>
> >>>> About Environment and distirbuted system: the issue is the same
> > with
> >>>> or without. You always need a local config vs the global one but I
> >>>> strongly think a system property, jndi entry or anything else can
> > be
> >>>> enough and don't need to be in tamaya itself to start.
> >>>>
> >>>> 2014-12-23 10:31 GMT+01:00 Mark Struberg <st...@yahoo.de>:
> >>>>>> so you can ask the config server for the right config.
> >>>>> Gosh, that scares me a bit! Don't even think about config
> > servers. Such
> >>>> things must be totally up to the vendor. We must allow making such
> > things
> >>>> possible with our API but we shall NOT support such things out of
> > the box!
> >>>>> The best would be to make our API in a way that even the user
> >>>> (application programmer) could add such a mechanism to it himself.
> >>> *I would not rule that completely out, this is a use case. We should
> >>> discuss that once we are ready for it (all the basics are in place)
> how
> >>> much we can go for it (meaning how much we can support things OOTB)..
> >>> Definitively it is not part of the core delivery, but could be an
> > optional
> >>> module to be added.*
> >>>
> >>>
> >>>
> >>>>>> For me SE comes first. EE builds on top not the other way
> > round!
> >>>>>
> >>>>>
> >>>>> Totally agree with that.
> >>>> Fine.
> >>>
> >>>
> >>>>>> But it (DeltaSpike) is inheritly connected to CDI and
> >>>>>
> >>>>> That's just not true.
> >>>
> >>> *Why, there is a cmpile time depoendency to cdictl-se,
> >>> see
> >
> https://git-wip-us.apache.org/repos/asf?p=deltaspike.git;a=blob_plain;f=deltaspike/pom.xml;hb=HEAD
> >>>
> > <
> https://git-wip-us.apache.org/repos/asf?p=deltaspike.git;a=blob_plain;f=deltaspike/pom.xml;hb=HEAD
> >*
> >>>
> >>> *As a code example people here on the list my have a look at
> >>>
> >
> https://git-wip-us.apache.org/repos/asf?p=deltaspike.git;a=blob_plain;f=deltaspike/cdictrl/api/src/main/java/org/apache/deltaspike/cdise/api/CdiContainer.java;hb=HEAD
> >>>
> > <
> https://git-wip-us.apache.org/repos/asf?p=deltaspike.git;a=blob_plain;f=deltaspike/cdictrl/api/src/main/java/org/apache/deltaspike/cdise/api/CdiContainer.java;hb=HEAD
> >*
> >>> **
> >>> *Or they look at the @ConfiguredPropertyx annotation:
> >>>
> >
> https://git-wip-us.apache.org/repos/asf?p=deltaspike.git;a=blob_plain;f=deltaspike/core/api/src/main/java/org/apache/deltaspike/core/api/config/ConfigProperty.java;hb=HEAD
>
> >>>
> > <
> https://git-wip-us.apache.org/repos/asf?p=deltaspike.git;a=blob_plain;f=deltaspike/core/api/src/main/java/org/apache/deltaspike/core/api/config/ConfigProperty.java;hb=HEAD
> >*
> >>>
> >>> *and they see:*
> >>>
> >>> *import javax.enterprise.util.Nonbinding;
> >>> import javax.inject.Qualifier;*
> >>>
> >>>
> >>> And it's tried and used successfully in many big projects
> > (including my own
> >>>> which deals with 50 bn EUR, german stock exchange, UK stock
> > exchange, big
> >>>> swiss banks, etc).
> >>>>> I'm not saying the DS api is the best, but it is able to do
> > all that and
> >>>> is 1/20th of the complexity and size of Tamaya right now. And still
> > being
> >>>> more powerful.
> >>>
> >>> *About what? Please, please, please give us the concrete use cases,
> > you
> >>> think Deltaspike supports, or supports better and tamaya does, with as
> > much
> >>> details possible. That is the only way we*
> >>> *a) can bullet.proof our considerations and also see, where our use
> > cases
> >>> differ.*
> >>> *b) really compare concepts, instead of just arguing that things are
> > much
> >>> more complex.*
> >>> *c) help also to get a better understanding of the concepts in place
> so
> > far
> >>> and see how things can be improved.*
> >>>
> >>>
> >>>
> >>>> It is Mark, at least in term of dependencies, I asked months ago to
> >>>> explode core part but it was not the moment I guess ;)
> >>>>
> >>>>>
> >>>>>>> things not working out of the box: distributed configs
> >>>>>
> >>>>> For which distributed system?
> >>>>> * Ehcache?
> >>>>>
> >>>>> * Terracotty?
> >>>>> * Hadoop like clustering?
> >>>>> * a simple shared file store?
> >>>>> Where to put the meta-configuration for it? Where to define
> > which one to
> >>>> use?
> >>>>> What fallback strategies to choose?
> >>>>
> >>>>
> >>>> Never spoke of any technology. Spoke in term of use case: I have 5
> >>>> machines which need to read the same config. Constraint I'd
> > like to
> >>>> respet is: don't force a "complicated" config like
> > hazelcast one for
> >>>> instance.
> >>>>
> >>>>> All that HEAVILY depends on the situation and scenario you have
> > in your
> >>>> project. There is just nothing we can decide for the customer. All
> > we can
> >>>> do is to make it VERY EASY to implement it yourself.
> >>>>>
> >>>>> For example: In DeltaSpike adding a ConfigSource for a config
> > file on a
> >>>> shared folder is a mere 7 lines of code..
> >>>> In Tamaya, it will be about one line ;)
> >>>
> >>>
> >>>> Here the is issue: it needs you to code. This is not a feature of
> > the
> >>>> framework.
> >>>>
> >>>>> Please don't let us go down the (old) Spring route to have
> > miles of
> >>>> configuration for stuff which you could hack in just a few lines of
> > code.
> >>>>
> >>>> In practise you don't always have the choice
> >>>
> >>>
> >>> *It all about options. I did never state that all features must end
> up
> > in
> >>> core:*
> >>> *1) I always stated to have a simple API, just providing a COMPLETE SE
> > API*
> >>>
> >>> * - config, config templates*
> >>> * - injection (also in SE)*
> >>> * - meta information*
> >>> * - support for reacting to config changes.*
> >>> * - and support for non String types. *
> >>>
> >>> * There is no more there, so I ask what is really wrong here? If its
> > OK,
> >>> let's go ahead and focus on core.*
> >>>
> >>> *2) In core I would expect to have a minimal runtime implementation
> > that
> >>> provides all features needed to cover most of the needs, meaning*
> >>>
> >>> * - reading config from the classpath, from files and URLs, *
> >>> * - using properties, xml-properties and ini as file format,*
> >>> * - implementing the type support mentioned, also including
> > collection
> >>> support (not yet supported)*
> >>> * - and providing configuration combination features.*
> >>>
> >>> * By default a configuration model is provided, so people can just
> > put
> >>> their config files at the right locations and start to work. Easy and
> >>> intuititve. What is wrong here I ask again?*
> >>>
> >>> *3) ALL THE REST are OPTIONAL EXTENSIONS, like CDI
> > integration,Environment
> >>> management, more complex configuration models, remote support etc.,
> >>> remoting, JMX, JAX-RS *
> >>> * support and *
> >>> *whatever we (and users) think would be useful. When users are happy
> > with
> >>> the module provided (we will hopefully have lots of discussions in
> the
> >>> next months and years to do it right), they may *
> >>> *use it OOTB. If not they can still write their own. It's all
> > about
> >>> options, like in Java EE (Arun Gupta) ;)*
> >>> * *
> >>>
> >>>>>> we can start as
> >>>>>>> easy as reading a database
> >>>>>
> >>>>> We discussed this in DeltaSpike and deliberately did NOT add
> > it. It's
> >>>> really really easy to implement a ConfigSource which goes into the
> > DB
> >>>> yourself in 30 minutes.
> >>>>>
> >>>>> If we would provide this feature out of the box, then how would
> > you do
> >>>> that?
> >>>>> * which database would you address?
> >>>>>
> >>>>> * JPA or JDBC native? again: what about the db vendor?
> >>>>> * how to configure your db user, your schema, etc?
> >>>>> * what about update and caching policies?
> >>>>> We would need some jar with JPA or whatever as dependency.
> > Would need
> >>>> meta-configuration, yada yada yada. And all to avoid 100 lines of
> > code?
> >>>> That just doesn't pay off!
> >>>>
> >>>> That's why I spoke about a "push" system. Then we
> > just use java 7 file
> >>>> system watch solution.
> >>>
> >>> *That is modelled by the ConfigChangeSet, which contains a reference
> > to
> >>> the current configuration and infos on the properties changed. This
> > change
> >>> set can be applied to a config (pull scenario) or *
> >>> *published based on changes in the backenbd (push scenario).*
> >>>
> >>>
> >>>>> Probably add some sample code somewhere. It must be easily
> > doable within
> >>>> our API but we should not try to implement that by default in our
> > core jar.
> >>>
> >>> *As mentioned it was never targeting core ;)*
> >>>
> >>>
> >>>
> >>>>>>> it include crud
> >>>>>
> >>>>>>> api but also a GUI - and listeners/update events.
> >>>>>
> >>>>> Totally overengineered imo. How should a GUI look like which
> > might
> >>>> change configuration in a Haddop Cluster or in a Docker
> > installation? Or
> >>>> whatever comes around the corner next year... Just DON'T DO IT.
> >>>
> >>> *Basically, what is possible is to provide introsepction in existing
> >>> configuration. This is helpful for error analysis. More details here
> > are to
> >>> be discussed. I don't see this as a core feature, but we must have
> > it in
> >>> mind. Discussions will show, what is possible, But as before, don't
> > rule
> >>> out everything, just before you are scared about it. If there is a
> > need,
> >>> there must be at least a discussion. First things perhaps for @all:
> > always
> >>> think if a use case should be part of the API, the core minimal
> >>> implementation, or an optional extension.*
> >>>
> >>>
> >>>
> >>>
> >>>>> There is of course an important very basic underlying design
> > question:
> >>>> How to treat configured values which are non-mutable and might get
> > cached
> >>>> vs ones which might change during the application lifetime?
> >>>>> Also: Do we like to introduce an own API for value-reload or do
> > we
> >>>> leverage JMX?
> >>>>>
> >>>>> THOSE are the things I like to get clarified before we touch
> > ANY code!
> >>>>
> >>>> JMX is mandatory IMO but JAXRS as well.
> >>>>
> >>>> *+1 *
> >>>
> >>> --
> >>> *Anatole Tresch*
> >>> Java Engineer & Architect, JSR Spec Lead
> >>> Glärnischweg 10
> >>> CH - 8620 Wetzikon
> >>>
> >>> *Switzerland, Europe Zurich, GMT+1*
> >>> *Twitter: @atsticks*
> >>> *Blogs: **http://javaremarkables.blogspot.ch/
> >>> <http://javaremarkables.blogspot.ch/>*
> >>>
> >>> *Google: atsticksMobile +41-76 344 62 79
> > <%2B41-76%20344%2062%2079>*
> >>>
> >>>
> >
>
--
*Anatole Tresch*
Java Engineer & Architect, JSR Spec Lead
Glärnischweg 10
CH - 8620 Wetzikon
*Switzerland, Europe Zurich, GMT+1*
*Twitter: @atsticks*
*Blogs: **http://javaremarkables.blogspot.ch/
<http://javaremarkables.blogspot.ch/>*
*Google: atsticksMobile +41-76 344 62 79*
Re: [DISCUSS] increasing complexity of Tamaya
Posted by Romain Manni-Bucau <rm...@gmail.com>.
2014-12-23 23:52 GMT+01:00 Mark Struberg <st...@yahoo.de>:
> Again: I already gave you a use case, please solve it with Tamaya.
> Then tell me your use cases and we gonna do ping pong until we find a common understanding and view.
> That's nothing personal, it's just technically trying to deduct the code and slice it down to the minimum necessary parts.
> We did the same in CDI and nowadays most people are happy that we e.g. didn't leave all the xml configuration stuff in there but instead introduced modularity and extensions ...
>
>
> I also don't have much to do with the Apache Brand (besides being an ASF member). I'm here as an individual PMC member like every other. My mentorship also has not much impact. What does have an impact is that I'm reaching for nothing less than the best solution.
>
>
>
>> And you know that all code
>> here is completely legacy, historically grown, ugly, outdated and more. You
>> obviously have a crystal ball, i am just wonderin.
>
> At the very beginning we all agreed to first discuss the basic principals. But right after that you instead imported your old code base and started to hack on it. I had expected that this is just or reviewing pieces and 'cherry-pick' parts of it which fit. But instead it was taken 1:1 and just 'enhanced'. From the ideas this is basically the same like it used to be 2 years ago. So yes, this is not new code (you btw said this yourself a dozen times). Of course we just blame ourselves that we didn't reach out earlier. It's also not all bad, but there are parts which I really think are way out of scope to later become a JSR.
>
>
>
>> Additionally, even your first interface has a dep on the Typed annotation for
>> example
> The @Typed is only to make really old Weld impls not blow up when scanning this class. It's really not needed anymore today.
>
>
> We need to finally start with a few very basic decisions and work through them. I already enlisted a few of them but I'm happy to enumerate them again.
>
>
>
> 1.) Should the configuration mechanism be String or Object?
>
core should be String only IMO, then integrations can coerce as they
want - most of frameworks will have their own coercing logic and we'd
need to be aligned on them.
> 2.) Should we have native methods to read and write various ini file formats, or is this just not our business?
>
This is no more the raw API but I see it as a "tamaya-extras" nice feature
> 3.) Should we define any configuration formats, and if so which one?
>
same
> 4.) Do we really need writeable configuration in our API?
>
I'd like a write-api but clearly not with the main (read)core-api -
can be postpone if it adds to much complexity to bootstrap tamaya IMO.
Globally I think we should maybe branch tamaya current code base and
create an empty master. From my point of view we could start from a
"DS light" - ie a ConfigProvider + a ConfigManager/ConfigAggregator
able to order ConfigProvider and merge them. Nothing static until it
is mandatory! These 2-3 classes should be enough to start. Then we can
add other features in separated modules like cdi, mapping/binding,
writing, gui... or enrich core if needed. Main goal is to start from a
trivial impl everybody can understand in 5mn then add on top of this
basis what we miss.
wdyt?
>
>
> LieGrue,
> strub
>
>
>
>> On Tuesday, 23 December 2014, 18:37, Anatole Tresch <at...@gmail.com> wrote:
>> > Hi Mark
>>
>> I must say I am totally surprised of your mails. Obviously you know things
>> better than all the other people and experts i have talked so far. You even know
>> what all users think and what all companies need. And you know that all code
>> here is completely legacy, historically grown, ugly, outdated and more. You
>> obviously have a crystal ball, i am just wondering
>>
>> I will not reply in detail on the last mail. It is full of fuzzy arguments.
>> Nothing concrete. Just claims how things should be iyo. Just claims that you can
>> do the same in 1/10, but you even struggle with the basic api, which is quite
>> small compared to most other apis in that area. You write about concerns about
>> memory leaks though the facts we have more than enough mechanisms to manage weak
>> refs and we have a couple of experts in our team that know well both se as well
>> as ee both in theory and in practice.
>> Additionally, even your first interface has a dep on the Typed annotation for
>> example, so I struggle to take this kind of feedback seriously. Its not
>> constructive, its not precise, I think it is respectless to the people working
>> here, and even worse it stops us foing our work and imo it matches not what I
>> expected from the Apache Brand, especially a project mentor. Sorry to say it so
>> frankly.
>>
>> Other opinions are welcome.
>>
>> -
>> Anatole Tresch
>> Glärnischweg 10
>> 8620 Wetzikon
>> Tel +41 (43) 317 05 30
>> -
>> Send from Mobile
>>
>>
>>> Am 23.12.2014 um 15:33 schrieb Mark Struberg <st...@yahoo.de>:
>>>
>>> I don't quite get it. All your source pointers to deltaspike did
>> concern the CdiCtrl module. Of course this has CDI dependencies...
>>>
>>>
>>> What I was talking about are the following classes
>>>
>> https://github.com/apache/deltaspike/blob/master/deltaspike/core/api/src/main/java/org/apache/deltaspike/core/api/config/ConfigResolver.java
>>>
>> https://github.com/apache/deltaspike/blob/master/deltaspike/core/api/src/main/java/org/apache/deltaspike/core/spi/config/ConfigSource.java
>>>
>> https://github.com/apache/deltaspike/blob/master/deltaspike/core/api/src/main/java/org/apache/deltaspike/core/spi/config/ConfigFilter.java
>>>
>> https://github.com/apache/deltaspike/blob/master/deltaspike/core/api/src/main/java/org/apache/deltaspike/core/spi/config/ConfigSourceProvider.java
>>>
>>>
>>> None of them has any CDI dependency. All the CDI functionality is built on
>> top of that.
>>>
>>>
>>>> *About what? Please, please, please give us the concrete use cases,
>> you
>>>> think Deltaspike supports, or supports better and tamaya does, with as
>> much
>>>> details possible.
>>>
>>> I already gave one. See my first mail. The point is actually the other way
>> around. I'm absolutely sure that we can do the same functionality that
>> Tamaya has today in 1/10 of the code. And having less code usually also means
>> having a much clearer and more flexible system at the end. It's just too
>> bloated and I did read javadocs for two days and had so many wtf moments that
>> all alarm bells did ring.
>>>
>>> I understand that the current code is a organically grown system which is
>> tried and proofed in some cases - but that is also it's problem. It's
>> not lean and elegant anymore but just some historically grown piece it seems. I
>> guess that many use cases which are possible within this framework are just not
>> legit anymore.
>>>
>>>
>>>
>>>> *1) I always stated to have a simple API, just providing a COMPLETE SE
>> API*
>>>
>>> Agree
>>>
>>>
>>>> * - config, config templates*
>>> Agree with config.
>>>
>>> But ConfigTemplates are just syntactic sugar. I would not add it. It's
>> just slower and not so easy to grasp for users.
>>>
>>>
>>>> * - injection (also in SE)*
>>> Disagree. What for? And how? Let's keep this as easy as possible.
>>>
>>>
>>>> * - meta information*
>>> TOTALLY over engineered. really!
>>>
>>>
>>>> * - support for reacting to config changes.*
>>> That's trickier. There are 2 ways. Push or Pull.
>>>
>>> .) Push means -> sending out an event so config consumers know when to
>> update. The problem is to make this reliable. You e.g. cannot use CDI as this
>> only works with ThreadLocals. You also cannot use Observable as this would cause
>> issues with mem leaks.
>>>
>>> .) Pull means -> config consumers who are interested in changed values
>> just call ConfigResolver#getProperty over again. This doesn't cause any
>> performance issues if the config system is well done.
>>>
>>>
>>>
>>>> * - and support for non String types. *
>>> We've discussed this in length many times. Every time we started again
>> it became clear pretty quickly that there is such a thing already: JNDI. And
>> that's exactly why it does NOT work. It really sucks.
>>>
>>>
>>>> * - reading config from the classpath, from files and URLs, *
>>>
>>> That's the problem. The user is not interested in reading this and that
>> file usually. Like with DI he is usually only interested in the final outcome.
>>>
>>>
>>>
>>>> * - using properties, xml-properties and ini as file format,*
>>> Why? The user doesn't care where the values did come from. We should
>> really do this via a pluggable SPI.
>>> Probably defining a few defaults (which could really include properties,
>> etc). But it's more that we provide a SPI with a few impls of it out of the
>> box. The emphasis is on the SPI and not on those 'sample' impls.
>>>
>>>
>>>
>>>> * - implementing the type support mentioned, also including
>> collection
>>>> support (not yet supported)*
>>> Collections support could be interesting
>>>
>>>
>>>
>>>> * - and providing configuration combination features.*
>>> What do you understand by that?
>>>
>>>
>>>> * By default a configuration model is provided, so people can just
>> put
>>>> their config files at the right locations and start to work. Easy and
>>>> intuititve. What is wrong here I ask again?*
>>> Currently we don't provide that. It's just not easy and intuitive
>> right now.
>>>
>>>
>>>
>>>> *3) ALL THE REST are OPTIONAL EXTENSIONS, like CDI
>> integration,Environment
>>>> management, more complex configuration models, remote support etc.,
>>>> remoting, JMX, JAX-RS *
>>>
>>> I agree.
>>>
>>>
>>>
>>> LieGrue,
>>> strub
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>> On Tuesday, 23 December 2014, 14:37, Anatole Tresch
>> <at...@gmail.com> wrote:
>>>> Hi Romain/all
>>>>
>>>> just a few additions inline...
>>>>
>>>> 2014-12-23 11:04 GMT+01:00 Romain Manni-Bucau
>> <rm...@gmail.com>:
>>>>
>>>>> About Environment and distirbuted system: the issue is the same
>> with
>>>>> or without. You always need a local config vs the global one but I
>>>>> strongly think a system property, jndi entry or anything else can
>> be
>>>>> enough and don't need to be in tamaya itself to start.
>>>>>
>>>>> 2014-12-23 10:31 GMT+01:00 Mark Struberg <st...@yahoo.de>:
>>>>>>> so you can ask the config server for the right config.
>>>>>> Gosh, that scares me a bit! Don't even think about config
>> servers. Such
>>>>> things must be totally up to the vendor. We must allow making such
>> things
>>>>> possible with our API but we shall NOT support such things out of
>> the box!
>>>>>> The best would be to make our API in a way that even the user
>>>>> (application programmer) could add such a mechanism to it himself.
>>>> *I would not rule that completely out, this is a use case. We should
>>>> discuss that once we are ready for it (all the basics are in place) how
>>>> much we can go for it (meaning how much we can support things OOTB)..
>>>> Definitively it is not part of the core delivery, but could be an
>> optional
>>>> module to be added.*
>>>>
>>>>
>>>>
>>>>>>> For me SE comes first. EE builds on top not the other way
>> round!
>>>>>>
>>>>>>
>>>>>> Totally agree with that.
>>>>> Fine.
>>>>
>>>>
>>>>>>> But it (DeltaSpike) is inheritly connected to CDI and
>>>>>>
>>>>>> That's just not true.
>>>>
>>>> *Why, there is a cmpile time depoendency to cdictl-se,
>>>> see
>> https://git-wip-us.apache.org/repos/asf?p=deltaspike.git;a=blob_plain;f=deltaspike/pom.xml;hb=HEAD
>>>>
>> <https://git-wip-us.apache.org/repos/asf?p=deltaspike.git;a=blob_plain;f=deltaspike/pom.xml;hb=HEAD>*
>>>>
>>>> *As a code example people here on the list my have a look at
>>>>
>> https://git-wip-us.apache.org/repos/asf?p=deltaspike.git;a=blob_plain;f=deltaspike/cdictrl/api/src/main/java/org/apache/deltaspike/cdise/api/CdiContainer.java;hb=HEAD
>>>>
>> <https://git-wip-us.apache.org/repos/asf?p=deltaspike.git;a=blob_plain;f=deltaspike/cdictrl/api/src/main/java/org/apache/deltaspike/cdise/api/CdiContainer.java;hb=HEAD>*
>>>> **
>>>> *Or they look at the @ConfiguredPropertyx annotation:
>>>>
>> https://git-wip-us.apache.org/repos/asf?p=deltaspike.git;a=blob_plain;f=deltaspike/core/api/src/main/java/org/apache/deltaspike/core/api/config/ConfigProperty.java;hb=HEAD
>>>>
>> <https://git-wip-us.apache.org/repos/asf?p=deltaspike.git;a=blob_plain;f=deltaspike/core/api/src/main/java/org/apache/deltaspike/core/api/config/ConfigProperty.java;hb=HEAD>*
>>>>
>>>> *and they see:*
>>>>
>>>> *import javax.enterprise.util.Nonbinding;
>>>> import javax.inject.Qualifier;*
>>>>
>>>>
>>>> And it's tried and used successfully in many big projects
>> (including my own
>>>>> which deals with 50 bn EUR, german stock exchange, UK stock
>> exchange, big
>>>>> swiss banks, etc).
>>>>>> I'm not saying the DS api is the best, but it is able to do
>> all that and
>>>>> is 1/20th of the complexity and size of Tamaya right now. And still
>> being
>>>>> more powerful.
>>>>
>>>> *About what? Please, please, please give us the concrete use cases,
>> you
>>>> think Deltaspike supports, or supports better and tamaya does, with as
>> much
>>>> details possible. That is the only way we*
>>>> *a) can bullet.proof our considerations and also see, where our use
>> cases
>>>> differ.*
>>>> *b) really compare concepts, instead of just arguing that things are
>> much
>>>> more complex.*
>>>> *c) help also to get a better understanding of the concepts in place so
>> far
>>>> and see how things can be improved.*
>>>>
>>>>
>>>>
>>>>> It is Mark, at least in term of dependencies, I asked months ago to
>>>>> explode core part but it was not the moment I guess ;)
>>>>>
>>>>>>
>>>>>>>> things not working out of the box: distributed configs
>>>>>>
>>>>>> For which distributed system?
>>>>>> * Ehcache?
>>>>>>
>>>>>> * Terracotty?
>>>>>> * Hadoop like clustering?
>>>>>> * a simple shared file store?
>>>>>> Where to put the meta-configuration for it? Where to define
>> which one to
>>>>> use?
>>>>>> What fallback strategies to choose?
>>>>>
>>>>>
>>>>> Never spoke of any technology. Spoke in term of use case: I have 5
>>>>> machines which need to read the same config. Constraint I'd
>> like to
>>>>> respet is: don't force a "complicated" config like
>> hazelcast one for
>>>>> instance.
>>>>>
>>>>>> All that HEAVILY depends on the situation and scenario you have
>> in your
>>>>> project. There is just nothing we can decide for the customer. All
>> we can
>>>>> do is to make it VERY EASY to implement it yourself.
>>>>>>
>>>>>> For example: In DeltaSpike adding a ConfigSource for a config
>> file on a
>>>>> shared folder is a mere 7 lines of code..
>>>>> In Tamaya, it will be about one line ;)
>>>>
>>>>
>>>>> Here the is issue: it needs you to code. This is not a feature of
>> the
>>>>> framework.
>>>>>
>>>>>> Please don't let us go down the (old) Spring route to have
>> miles of
>>>>> configuration for stuff which you could hack in just a few lines of
>> code.
>>>>>
>>>>> In practise you don't always have the choice
>>>>
>>>>
>>>> *It all about options. I did never state that all features must end up
>> in
>>>> core:*
>>>> *1) I always stated to have a simple API, just providing a COMPLETE SE
>> API*
>>>>
>>>> * - config, config templates*
>>>> * - injection (also in SE)*
>>>> * - meta information*
>>>> * - support for reacting to config changes.*
>>>> * - and support for non String types. *
>>>>
>>>> * There is no more there, so I ask what is really wrong here? If its
>> OK,
>>>> let's go ahead and focus on core.*
>>>>
>>>> *2) In core I would expect to have a minimal runtime implementation
>> that
>>>> provides all features needed to cover most of the needs, meaning*
>>>>
>>>> * - reading config from the classpath, from files and URLs, *
>>>> * - using properties, xml-properties and ini as file format,*
>>>> * - implementing the type support mentioned, also including
>> collection
>>>> support (not yet supported)*
>>>> * - and providing configuration combination features.*
>>>>
>>>> * By default a configuration model is provided, so people can just
>> put
>>>> their config files at the right locations and start to work. Easy and
>>>> intuititve. What is wrong here I ask again?*
>>>>
>>>> *3) ALL THE REST are OPTIONAL EXTENSIONS, like CDI
>> integration,Environment
>>>> management, more complex configuration models, remote support etc.,
>>>> remoting, JMX, JAX-RS *
>>>> * support and *
>>>> *whatever we (and users) think would be useful. When users are happy
>> with
>>>> the module provided (we will hopefully have lots of discussions in the
>>>> next months and years to do it right), they may *
>>>> *use it OOTB. If not they can still write their own. It's all
>> about
>>>> options, like in Java EE (Arun Gupta) ;)*
>>>> * *
>>>>
>>>>>>> we can start as
>>>>>>>> easy as reading a database
>>>>>>
>>>>>> We discussed this in DeltaSpike and deliberately did NOT add
>> it. It's
>>>>> really really easy to implement a ConfigSource which goes into the
>> DB
>>>>> yourself in 30 minutes.
>>>>>>
>>>>>> If we would provide this feature out of the box, then how would
>> you do
>>>>> that?
>>>>>> * which database would you address?
>>>>>>
>>>>>> * JPA or JDBC native? again: what about the db vendor?
>>>>>> * how to configure your db user, your schema, etc?
>>>>>> * what about update and caching policies?
>>>>>> We would need some jar with JPA or whatever as dependency.
>> Would need
>>>>> meta-configuration, yada yada yada. And all to avoid 100 lines of
>> code?
>>>>> That just doesn't pay off!
>>>>>
>>>>> That's why I spoke about a "push" system. Then we
>> just use java 7 file
>>>>> system watch solution.
>>>>
>>>> *That is modelled by the ConfigChangeSet, which contains a reference
>> to
>>>> the current configuration and infos on the properties changed. This
>> change
>>>> set can be applied to a config (pull scenario) or *
>>>> *published based on changes in the backenbd (push scenario).*
>>>>
>>>>
>>>>>> Probably add some sample code somewhere. It must be easily
>> doable within
>>>>> our API but we should not try to implement that by default in our
>> core jar.
>>>>
>>>> *As mentioned it was never targeting core ;)*
>>>>
>>>>
>>>>
>>>>>>>> it include crud
>>>>>>
>>>>>>>> api but also a GUI - and listeners/update events.
>>>>>>
>>>>>> Totally overengineered imo. How should a GUI look like which
>> might
>>>>> change configuration in a Haddop Cluster or in a Docker
>> installation? Or
>>>>> whatever comes around the corner next year... Just DON'T DO IT.
>>>>
>>>> *Basically, what is possible is to provide introsepction in existing
>>>> configuration. This is helpful for error analysis. More details here
>> are to
>>>> be discussed. I don't see this as a core feature, but we must have
>> it in
>>>> mind. Discussions will show, what is possible, But as before, don't
>> rule
>>>> out everything, just before you are scared about it. If there is a
>> need,
>>>> there must be at least a discussion. First things perhaps for @all:
>> always
>>>> think if a use case should be part of the API, the core minimal
>>>> implementation, or an optional extension.*
>>>>
>>>>
>>>>
>>>>
>>>>>> There is of course an important very basic underlying design
>> question:
>>>>> How to treat configured values which are non-mutable and might get
>> cached
>>>>> vs ones which might change during the application lifetime?
>>>>>> Also: Do we like to introduce an own API for value-reload or do
>> we
>>>>> leverage JMX?
>>>>>>
>>>>>> THOSE are the things I like to get clarified before we touch
>> ANY code!
>>>>>
>>>>> JMX is mandatory IMO but JAXRS as well.
>>>>>
>>>>> *+1 *
>>>>
>>>> --
>>>> *Anatole Tresch*
>>>> Java Engineer & Architect, JSR Spec Lead
>>>> Glärnischweg 10
>>>> CH - 8620 Wetzikon
>>>>
>>>> *Switzerland, Europe Zurich, GMT+1*
>>>> *Twitter: @atsticks*
>>>> *Blogs: **http://javaremarkables.blogspot.ch/
>>>> <http://javaremarkables.blogspot.ch/>*
>>>>
>>>> *Google: atsticksMobile +41-76 344 62 79
>> <%2B41-76%20344%2062%2079>*
>>>>
>>>>
>>
Re: [DISCUSS] increasing complexity of Tamaya
Posted by Mark Struberg <st...@yahoo.de>.
Again: I already gave you a use case, please solve it with Tamaya.
Then tell me your use cases and we gonna do ping pong until we find a common understanding and view.
That's nothing personal, it's just technically trying to deduct the code and slice it down to the minimum necessary parts.
We did the same in CDI and nowadays most people are happy that we e.g. didn't leave all the xml configuration stuff in there but instead introduced modularity and extensions ...
I also don't have much to do with the Apache Brand (besides being an ASF member). I'm here as an individual PMC member like every other. My mentorship also has not much impact. What does have an impact is that I'm reaching for nothing less than the best solution.
> And you know that all code
> here is completely legacy, historically grown, ugly, outdated and more. You
> obviously have a crystal ball, i am just wonderin.
At the very beginning we all agreed to first discuss the basic principals. But right after that you instead imported your old code base and started to hack on it. I had expected that this is just or reviewing pieces and 'cherry-pick' parts of it which fit. But instead it was taken 1:1 and just 'enhanced'. From the ideas this is basically the same like it used to be 2 years ago. So yes, this is not new code (you btw said this yourself a dozen times). Of course we just blame ourselves that we didn't reach out earlier. It's also not all bad, but there are parts which I really think are way out of scope to later become a JSR.
> Additionally, even your first interface has a dep on the Typed annotation for
> example
The @Typed is only to make really old Weld impls not blow up when scanning this class. It's really not needed anymore today.
We need to finally start with a few very basic decisions and work through them. I already enlisted a few of them but I'm happy to enumerate them again.
1.) Should the configuration mechanism be String or Object?
2.) Should we have native methods to read and write various ini file formats, or is this just not our business?
3.) Should we define any configuration formats, and if so which one?
4.) Do we really need writeable configuration in our API?
LieGrue,
strub
> On Tuesday, 23 December 2014, 18:37, Anatole Tresch <at...@gmail.com> wrote:
> > Hi Mark
>
> I must say I am totally surprised of your mails. Obviously you know things
> better than all the other people and experts i have talked so far. You even know
> what all users think and what all companies need. And you know that all code
> here is completely legacy, historically grown, ugly, outdated and more. You
> obviously have a crystal ball, i am just wondering
>
> I will not reply in detail on the last mail. It is full of fuzzy arguments.
> Nothing concrete. Just claims how things should be iyo. Just claims that you can
> do the same in 1/10, but you even struggle with the basic api, which is quite
> small compared to most other apis in that area. You write about concerns about
> memory leaks though the facts we have more than enough mechanisms to manage weak
> refs and we have a couple of experts in our team that know well both se as well
> as ee both in theory and in practice.
> Additionally, even your first interface has a dep on the Typed annotation for
> example, so I struggle to take this kind of feedback seriously. Its not
> constructive, its not precise, I think it is respectless to the people working
> here, and even worse it stops us foing our work and imo it matches not what I
> expected from the Apache Brand, especially a project mentor. Sorry to say it so
> frankly.
>
> Other opinions are welcome.
>
> -
> Anatole Tresch
> Glärnischweg 10
> 8620 Wetzikon
> Tel +41 (43) 317 05 30
> -
> Send from Mobile
>
>
>> Am 23.12.2014 um 15:33 schrieb Mark Struberg <st...@yahoo.de>:
>>
>> I don't quite get it. All your source pointers to deltaspike did
> concern the CdiCtrl module. Of course this has CDI dependencies...
>>
>>
>> What I was talking about are the following classes
>>
> https://github.com/apache/deltaspike/blob/master/deltaspike/core/api/src/main/java/org/apache/deltaspike/core/api/config/ConfigResolver.java
>>
> https://github.com/apache/deltaspike/blob/master/deltaspike/core/api/src/main/java/org/apache/deltaspike/core/spi/config/ConfigSource.java
>>
> https://github.com/apache/deltaspike/blob/master/deltaspike/core/api/src/main/java/org/apache/deltaspike/core/spi/config/ConfigFilter.java
>>
> https://github.com/apache/deltaspike/blob/master/deltaspike/core/api/src/main/java/org/apache/deltaspike/core/spi/config/ConfigSourceProvider.java
>>
>>
>> None of them has any CDI dependency. All the CDI functionality is built on
> top of that.
>>
>>
>>> *About what? Please, please, please give us the concrete use cases,
> you
>>> think Deltaspike supports, or supports better and tamaya does, with as
> much
>>> details possible.
>>
>> I already gave one. See my first mail. The point is actually the other way
> around. I'm absolutely sure that we can do the same functionality that
> Tamaya has today in 1/10 of the code. And having less code usually also means
> having a much clearer and more flexible system at the end. It's just too
> bloated and I did read javadocs for two days and had so many wtf moments that
> all alarm bells did ring.
>>
>> I understand that the current code is a organically grown system which is
> tried and proofed in some cases - but that is also it's problem. It's
> not lean and elegant anymore but just some historically grown piece it seems. I
> guess that many use cases which are possible within this framework are just not
> legit anymore.
>>
>>
>>
>>> *1) I always stated to have a simple API, just providing a COMPLETE SE
> API*
>>
>> Agree
>>
>>
>>> * - config, config templates*
>> Agree with config.
>>
>> But ConfigTemplates are just syntactic sugar. I would not add it. It's
> just slower and not so easy to grasp for users.
>>
>>
>>> * - injection (also in SE)*
>> Disagree. What for? And how? Let's keep this as easy as possible.
>>
>>
>>> * - meta information*
>> TOTALLY over engineered. really!
>>
>>
>>> * - support for reacting to config changes.*
>> That's trickier. There are 2 ways. Push or Pull.
>>
>> .) Push means -> sending out an event so config consumers know when to
> update. The problem is to make this reliable. You e.g. cannot use CDI as this
> only works with ThreadLocals. You also cannot use Observable as this would cause
> issues with mem leaks.
>>
>> .) Pull means -> config consumers who are interested in changed values
> just call ConfigResolver#getProperty over again. This doesn't cause any
> performance issues if the config system is well done.
>>
>>
>>
>>> * - and support for non String types. *
>> We've discussed this in length many times. Every time we started again
> it became clear pretty quickly that there is such a thing already: JNDI. And
> that's exactly why it does NOT work. It really sucks.
>>
>>
>>> * - reading config from the classpath, from files and URLs, *
>>
>> That's the problem. The user is not interested in reading this and that
> file usually. Like with DI he is usually only interested in the final outcome.
>>
>>
>>
>>> * - using properties, xml-properties and ini as file format,*
>> Why? The user doesn't care where the values did come from. We should
> really do this via a pluggable SPI.
>> Probably defining a few defaults (which could really include properties,
> etc). But it's more that we provide a SPI with a few impls of it out of the
> box. The emphasis is on the SPI and not on those 'sample' impls.
>>
>>
>>
>>> * - implementing the type support mentioned, also including
> collection
>>> support (not yet supported)*
>> Collections support could be interesting
>>
>>
>>
>>> * - and providing configuration combination features.*
>> What do you understand by that?
>>
>>
>>> * By default a configuration model is provided, so people can just
> put
>>> their config files at the right locations and start to work. Easy and
>>> intuititve. What is wrong here I ask again?*
>> Currently we don't provide that. It's just not easy and intuitive
> right now.
>>
>>
>>
>>> *3) ALL THE REST are OPTIONAL EXTENSIONS, like CDI
> integration,Environment
>>> management, more complex configuration models, remote support etc.,
>>> remoting, JMX, JAX-RS *
>>
>> I agree.
>>
>>
>>
>> LieGrue,
>> strub
>>
>>
>>
>>
>>
>>
>>
>>> On Tuesday, 23 December 2014, 14:37, Anatole Tresch
> <at...@gmail.com> wrote:
>>> Hi Romain/all
>>>
>>> just a few additions inline...
>>>
>>> 2014-12-23 11:04 GMT+01:00 Romain Manni-Bucau
> <rm...@gmail.com>:
>>>
>>>> About Environment and distirbuted system: the issue is the same
> with
>>>> or without. You always need a local config vs the global one but I
>>>> strongly think a system property, jndi entry or anything else can
> be
>>>> enough and don't need to be in tamaya itself to start.
>>>>
>>>> 2014-12-23 10:31 GMT+01:00 Mark Struberg <st...@yahoo.de>:
>>>>>> so you can ask the config server for the right config.
>>>>> Gosh, that scares me a bit! Don't even think about config
> servers. Such
>>>> things must be totally up to the vendor. We must allow making such
> things
>>>> possible with our API but we shall NOT support such things out of
> the box!
>>>>> The best would be to make our API in a way that even the user
>>>> (application programmer) could add such a mechanism to it himself.
>>> *I would not rule that completely out, this is a use case. We should
>>> discuss that once we are ready for it (all the basics are in place) how
>>> much we can go for it (meaning how much we can support things OOTB)..
>>> Definitively it is not part of the core delivery, but could be an
> optional
>>> module to be added.*
>>>
>>>
>>>
>>>>>> For me SE comes first. EE builds on top not the other way
> round!
>>>>>
>>>>>
>>>>> Totally agree with that.
>>>> Fine.
>>>
>>>
>>>>>> But it (DeltaSpike) is inheritly connected to CDI and
>>>>>
>>>>> That's just not true.
>>>
>>> *Why, there is a cmpile time depoendency to cdictl-se,
>>> see
> https://git-wip-us.apache.org/repos/asf?p=deltaspike.git;a=blob_plain;f=deltaspike/pom.xml;hb=HEAD
>>>
> <https://git-wip-us.apache.org/repos/asf?p=deltaspike.git;a=blob_plain;f=deltaspike/pom.xml;hb=HEAD>*
>>>
>>> *As a code example people here on the list my have a look at
>>>
> https://git-wip-us.apache.org/repos/asf?p=deltaspike.git;a=blob_plain;f=deltaspike/cdictrl/api/src/main/java/org/apache/deltaspike/cdise/api/CdiContainer.java;hb=HEAD
>>>
> <https://git-wip-us.apache.org/repos/asf?p=deltaspike.git;a=blob_plain;f=deltaspike/cdictrl/api/src/main/java/org/apache/deltaspike/cdise/api/CdiContainer.java;hb=HEAD>*
>>> **
>>> *Or they look at the @ConfiguredPropertyx annotation:
>>>
> https://git-wip-us.apache.org/repos/asf?p=deltaspike.git;a=blob_plain;f=deltaspike/core/api/src/main/java/org/apache/deltaspike/core/api/config/ConfigProperty.java;hb=HEAD
>>>
> <https://git-wip-us.apache.org/repos/asf?p=deltaspike.git;a=blob_plain;f=deltaspike/core/api/src/main/java/org/apache/deltaspike/core/api/config/ConfigProperty.java;hb=HEAD>*
>>>
>>> *and they see:*
>>>
>>> *import javax.enterprise.util.Nonbinding;
>>> import javax.inject.Qualifier;*
>>>
>>>
>>> And it's tried and used successfully in many big projects
> (including my own
>>>> which deals with 50 bn EUR, german stock exchange, UK stock
> exchange, big
>>>> swiss banks, etc).
>>>>> I'm not saying the DS api is the best, but it is able to do
> all that and
>>>> is 1/20th of the complexity and size of Tamaya right now. And still
> being
>>>> more powerful.
>>>
>>> *About what? Please, please, please give us the concrete use cases,
> you
>>> think Deltaspike supports, or supports better and tamaya does, with as
> much
>>> details possible. That is the only way we*
>>> *a) can bullet.proof our considerations and also see, where our use
> cases
>>> differ.*
>>> *b) really compare concepts, instead of just arguing that things are
> much
>>> more complex.*
>>> *c) help also to get a better understanding of the concepts in place so
> far
>>> and see how things can be improved.*
>>>
>>>
>>>
>>>> It is Mark, at least in term of dependencies, I asked months ago to
>>>> explode core part but it was not the moment I guess ;)
>>>>
>>>>>
>>>>>>> things not working out of the box: distributed configs
>>>>>
>>>>> For which distributed system?
>>>>> * Ehcache?
>>>>>
>>>>> * Terracotty?
>>>>> * Hadoop like clustering?
>>>>> * a simple shared file store?
>>>>> Where to put the meta-configuration for it? Where to define
> which one to
>>>> use?
>>>>> What fallback strategies to choose?
>>>>
>>>>
>>>> Never spoke of any technology. Spoke in term of use case: I have 5
>>>> machines which need to read the same config. Constraint I'd
> like to
>>>> respet is: don't force a "complicated" config like
> hazelcast one for
>>>> instance.
>>>>
>>>>> All that HEAVILY depends on the situation and scenario you have
> in your
>>>> project. There is just nothing we can decide for the customer. All
> we can
>>>> do is to make it VERY EASY to implement it yourself.
>>>>>
>>>>> For example: In DeltaSpike adding a ConfigSource for a config
> file on a
>>>> shared folder is a mere 7 lines of code..
>>>> In Tamaya, it will be about one line ;)
>>>
>>>
>>>> Here the is issue: it needs you to code. This is not a feature of
> the
>>>> framework.
>>>>
>>>>> Please don't let us go down the (old) Spring route to have
> miles of
>>>> configuration for stuff which you could hack in just a few lines of
> code.
>>>>
>>>> In practise you don't always have the choice
>>>
>>>
>>> *It all about options. I did never state that all features must end up
> in
>>> core:*
>>> *1) I always stated to have a simple API, just providing a COMPLETE SE
> API*
>>>
>>> * - config, config templates*
>>> * - injection (also in SE)*
>>> * - meta information*
>>> * - support for reacting to config changes.*
>>> * - and support for non String types. *
>>>
>>> * There is no more there, so I ask what is really wrong here? If its
> OK,
>>> let's go ahead and focus on core.*
>>>
>>> *2) In core I would expect to have a minimal runtime implementation
> that
>>> provides all features needed to cover most of the needs, meaning*
>>>
>>> * - reading config from the classpath, from files and URLs, *
>>> * - using properties, xml-properties and ini as file format,*
>>> * - implementing the type support mentioned, also including
> collection
>>> support (not yet supported)*
>>> * - and providing configuration combination features.*
>>>
>>> * By default a configuration model is provided, so people can just
> put
>>> their config files at the right locations and start to work. Easy and
>>> intuititve. What is wrong here I ask again?*
>>>
>>> *3) ALL THE REST are OPTIONAL EXTENSIONS, like CDI
> integration,Environment
>>> management, more complex configuration models, remote support etc.,
>>> remoting, JMX, JAX-RS *
>>> * support and *
>>> *whatever we (and users) think would be useful. When users are happy
> with
>>> the module provided (we will hopefully have lots of discussions in the
>>> next months and years to do it right), they may *
>>> *use it OOTB. If not they can still write their own. It's all
> about
>>> options, like in Java EE (Arun Gupta) ;)*
>>> * *
>>>
>>>>>> we can start as
>>>>>>> easy as reading a database
>>>>>
>>>>> We discussed this in DeltaSpike and deliberately did NOT add
> it. It's
>>>> really really easy to implement a ConfigSource which goes into the
> DB
>>>> yourself in 30 minutes.
>>>>>
>>>>> If we would provide this feature out of the box, then how would
> you do
>>>> that?
>>>>> * which database would you address?
>>>>>
>>>>> * JPA or JDBC native? again: what about the db vendor?
>>>>> * how to configure your db user, your schema, etc?
>>>>> * what about update and caching policies?
>>>>> We would need some jar with JPA or whatever as dependency.
> Would need
>>>> meta-configuration, yada yada yada. And all to avoid 100 lines of
> code?
>>>> That just doesn't pay off!
>>>>
>>>> That's why I spoke about a "push" system. Then we
> just use java 7 file
>>>> system watch solution.
>>>
>>> *That is modelled by the ConfigChangeSet, which contains a reference
> to
>>> the current configuration and infos on the properties changed. This
> change
>>> set can be applied to a config (pull scenario) or *
>>> *published based on changes in the backenbd (push scenario).*
>>>
>>>
>>>>> Probably add some sample code somewhere. It must be easily
> doable within
>>>> our API but we should not try to implement that by default in our
> core jar.
>>>
>>> *As mentioned it was never targeting core ;)*
>>>
>>>
>>>
>>>>>>> it include crud
>>>>>
>>>>>>> api but also a GUI - and listeners/update events.
>>>>>
>>>>> Totally overengineered imo. How should a GUI look like which
> might
>>>> change configuration in a Haddop Cluster or in a Docker
> installation? Or
>>>> whatever comes around the corner next year... Just DON'T DO IT.
>>>
>>> *Basically, what is possible is to provide introsepction in existing
>>> configuration. This is helpful for error analysis. More details here
> are to
>>> be discussed. I don't see this as a core feature, but we must have
> it in
>>> mind. Discussions will show, what is possible, But as before, don't
> rule
>>> out everything, just before you are scared about it. If there is a
> need,
>>> there must be at least a discussion. First things perhaps for @all:
> always
>>> think if a use case should be part of the API, the core minimal
>>> implementation, or an optional extension.*
>>>
>>>
>>>
>>>
>>>>> There is of course an important very basic underlying design
> question:
>>>> How to treat configured values which are non-mutable and might get
> cached
>>>> vs ones which might change during the application lifetime?
>>>>> Also: Do we like to introduce an own API for value-reload or do
> we
>>>> leverage JMX?
>>>>>
>>>>> THOSE are the things I like to get clarified before we touch
> ANY code!
>>>>
>>>> JMX is mandatory IMO but JAXRS as well.
>>>>
>>>> *+1 *
>>>
>>> --
>>> *Anatole Tresch*
>>> Java Engineer & Architect, JSR Spec Lead
>>> Glärnischweg 10
>>> CH - 8620 Wetzikon
>>>
>>> *Switzerland, Europe Zurich, GMT+1*
>>> *Twitter: @atsticks*
>>> *Blogs: **http://javaremarkables.blogspot.ch/
>>> <http://javaremarkables.blogspot.ch/>*
>>>
>>> *Google: atsticksMobile +41-76 344 62 79
> <%2B41-76%20344%2062%2079>*
>>>
>>>
>
Re: [DISCUSS] increasing complexity of Tamaya
Posted by Anatole Tresch <at...@gmail.com>.
Hi Mark
I must say I am totally surprised of your mails. Obviously you know things better than all the other people and experts i have talked so far. You even know what all users think and what all companies need. And you know that all code here is completely legacy, historically grown, ugly, outdated and more. You obviously have a crystal ball, i am just wondering
I will not reply in detail on the last mail. It is full of fuzzy arguments. Nothing concrete. Just claims how things should be iyo. Just claims that you can do the same in 1/10, but you even struggle with the basic api, which is quite small compared to most other apis in that area. You write about concerns about memory leaks though the facts we have more than enough mechanisms to manage weak refs and we have a couple of experts in our team that know well both se as well as ee both in theory and in practice.
Additionally, even your first interface has a dep on the Typed annotation for example, so I struggle to take this kind of feedback seriously. Its not constructive, its not precise, I think it is respectless to the people working here, and even worse it stops us foing our work and imo it matches not what I expected from the Apache Brand, especially a project mentor. Sorry to say it so frankly.
Other opinions are welcome.
-
Anatole Tresch
Glärnischweg 10
8620 Wetzikon
Tel +41 (43) 317 05 30
-
Send from Mobile
> Am 23.12.2014 um 15:33 schrieb Mark Struberg <st...@yahoo.de>:
>
> I don't quite get it. All your source pointers to deltaspike did concern the CdiCtrl module. Of course this has CDI dependencies...
>
>
> What I was talking about are the following classes
> https://github.com/apache/deltaspike/blob/master/deltaspike/core/api/src/main/java/org/apache/deltaspike/core/api/config/ConfigResolver.java
> https://github.com/apache/deltaspike/blob/master/deltaspike/core/api/src/main/java/org/apache/deltaspike/core/spi/config/ConfigSource.java
> https://github.com/apache/deltaspike/blob/master/deltaspike/core/api/src/main/java/org/apache/deltaspike/core/spi/config/ConfigFilter.java
> https://github.com/apache/deltaspike/blob/master/deltaspike/core/api/src/main/java/org/apache/deltaspike/core/spi/config/ConfigSourceProvider.java
>
>
> None of them has any CDI dependency. All the CDI functionality is built on top of that.
>
>
>> *About what? Please, please, please give us the concrete use cases, you
>> think Deltaspike supports, or supports better and tamaya does, with as much
>> details possible.
>
> I already gave one. See my first mail. The point is actually the other way around. I'm absolutely sure that we can do the same functionality that Tamaya has today in 1/10 of the code. And having less code usually also means having a much clearer and more flexible system at the end. It's just too bloated and I did read javadocs for two days and had so many wtf moments that all alarm bells did ring.
>
> I understand that the current code is a organically grown system which is tried and proofed in some cases - but that is also it's problem. It's not lean and elegant anymore but just some historically grown piece it seems. I guess that many use cases which are possible within this framework are just not legit anymore.
>
>
>
>> *1) I always stated to have a simple API, just providing a COMPLETE SE API*
>
> Agree
>
>
>> * - config, config templates*
> Agree with config.
>
> But ConfigTemplates are just syntactic sugar. I would not add it. It's just slower and not so easy to grasp for users.
>
>
>> * - injection (also in SE)*
> Disagree. What for? And how? Let's keep this as easy as possible.
>
>
>> * - meta information*
> TOTALLY over engineered. really!
>
>
>> * - support for reacting to config changes.*
> That's trickier. There are 2 ways. Push or Pull.
>
> .) Push means -> sending out an event so config consumers know when to update. The problem is to make this reliable. You e.g. cannot use CDI as this only works with ThreadLocals. You also cannot use Observable as this would cause issues with mem leaks.
>
> .) Pull means -> config consumers who are interested in changed values just call ConfigResolver#getProperty over again. This doesn't cause any performance issues if the config system is well done.
>
>
>
>> * - and support for non String types. *
> We've discussed this in length many times. Every time we started again it became clear pretty quickly that there is such a thing already: JNDI. And that's exactly why it does NOT work. It really sucks.
>
>
>> * - reading config from the classpath, from files and URLs, *
>
> That's the problem. The user is not interested in reading this and that file usually. Like with DI he is usually only interested in the final outcome.
>
>
>
>> * - using properties, xml-properties and ini as file format,*
> Why? The user doesn't care where the values did come from. We should really do this via a pluggable SPI.
> Probably defining a few defaults (which could really include properties, etc). But it's more that we provide a SPI with a few impls of it out of the box. The emphasis is on the SPI and not on those 'sample' impls.
>
>
>
>> * - implementing the type support mentioned, also including collection
>> support (not yet supported)*
> Collections support could be interesting
>
>
>
>> * - and providing configuration combination features.*
> What do you understand by that?
>
>
>> * By default a configuration model is provided, so people can just put
>> their config files at the right locations and start to work. Easy and
>> intuititve. What is wrong here I ask again?*
> Currently we don't provide that. It's just not easy and intuitive right now.
>
>
>
>> *3) ALL THE REST are OPTIONAL EXTENSIONS, like CDI integration,Environment
>> management, more complex configuration models, remote support etc.,
>> remoting, JMX, JAX-RS *
>
> I agree.
>
>
>
> LieGrue,
> strub
>
>
>
>
>
>
>
>> On Tuesday, 23 December 2014, 14:37, Anatole Tresch <at...@gmail.com> wrote:
>> Hi Romain/all
>>
>> just a few additions inline...
>>
>> 2014-12-23 11:04 GMT+01:00 Romain Manni-Bucau <rm...@gmail.com>:
>>
>>> About Environment and distirbuted system: the issue is the same with
>>> or without. You always need a local config vs the global one but I
>>> strongly think a system property, jndi entry or anything else can be
>>> enough and don't need to be in tamaya itself to start.
>>>
>>> 2014-12-23 10:31 GMT+01:00 Mark Struberg <st...@yahoo.de>:
>>>>> so you can ask the config server for the right config.
>>>> Gosh, that scares me a bit! Don't even think about config servers. Such
>>> things must be totally up to the vendor. We must allow making such things
>>> possible with our API but we shall NOT support such things out of the box!
>>>> The best would be to make our API in a way that even the user
>>> (application programmer) could add such a mechanism to it himself.
>> *I would not rule that completely out, this is a use case. We should
>> discuss that once we are ready for it (all the basics are in place) how
>> much we can go for it (meaning how much we can support things OOTB)..
>> Definitively it is not part of the core delivery, but could be an optional
>> module to be added.*
>>
>>
>>
>>>>> For me SE comes first. EE builds on top not the other way round!
>>>>
>>>>
>>>> Totally agree with that.
>>> Fine.
>>
>>
>>>>> But it (DeltaSpike) is inheritly connected to CDI and
>>>>
>>>> That's just not true.
>>
>> *Why, there is a cmpile time depoendency to cdictl-se,
>> see https://git-wip-us.apache.org/repos/asf?p=deltaspike.git;a=blob_plain;f=deltaspike/pom.xml;hb=HEAD
>> <https://git-wip-us.apache.org/repos/asf?p=deltaspike.git;a=blob_plain;f=deltaspike/pom.xml;hb=HEAD>*
>>
>> *As a code example people here on the list my have a look at
>> https://git-wip-us.apache.org/repos/asf?p=deltaspike.git;a=blob_plain;f=deltaspike/cdictrl/api/src/main/java/org/apache/deltaspike/cdise/api/CdiContainer.java;hb=HEAD
>> <https://git-wip-us.apache.org/repos/asf?p=deltaspike.git;a=blob_plain;f=deltaspike/cdictrl/api/src/main/java/org/apache/deltaspike/cdise/api/CdiContainer.java;hb=HEAD>*
>> **
>> *Or they look at the @ConfiguredPropertyx annotation:
>> https://git-wip-us.apache.org/repos/asf?p=deltaspike.git;a=blob_plain;f=deltaspike/core/api/src/main/java/org/apache/deltaspike/core/api/config/ConfigProperty.java;hb=HEAD
>> <https://git-wip-us.apache.org/repos/asf?p=deltaspike.git;a=blob_plain;f=deltaspike/core/api/src/main/java/org/apache/deltaspike/core/api/config/ConfigProperty.java;hb=HEAD>*
>>
>> *and they see:*
>>
>> *import javax.enterprise.util.Nonbinding;
>> import javax.inject.Qualifier;*
>>
>>
>> And it's tried and used successfully in many big projects (including my own
>>> which deals with 50 bn EUR, german stock exchange, UK stock exchange, big
>>> swiss banks, etc).
>>>> I'm not saying the DS api is the best, but it is able to do all that and
>>> is 1/20th of the complexity and size of Tamaya right now. And still being
>>> more powerful.
>>
>> *About what? Please, please, please give us the concrete use cases, you
>> think Deltaspike supports, or supports better and tamaya does, with as much
>> details possible. That is the only way we*
>> *a) can bullet.proof our considerations and also see, where our use cases
>> differ.*
>> *b) really compare concepts, instead of just arguing that things are much
>> more complex.*
>> *c) help also to get a better understanding of the concepts in place so far
>> and see how things can be improved.*
>>
>>
>>
>>> It is Mark, at least in term of dependencies, I asked months ago to
>>> explode core part but it was not the moment I guess ;)
>>>
>>>>
>>>>>> things not working out of the box: distributed configs
>>>>
>>>> For which distributed system?
>>>> * Ehcache?
>>>>
>>>> * Terracotty?
>>>> * Hadoop like clustering?
>>>> * a simple shared file store?
>>>> Where to put the meta-configuration for it? Where to define which one to
>>> use?
>>>> What fallback strategies to choose?
>>>
>>>
>>> Never spoke of any technology. Spoke in term of use case: I have 5
>>> machines which need to read the same config. Constraint I'd like to
>>> respet is: don't force a "complicated" config like hazelcast one for
>>> instance.
>>>
>>>> All that HEAVILY depends on the situation and scenario you have in your
>>> project. There is just nothing we can decide for the customer. All we can
>>> do is to make it VERY EASY to implement it yourself.
>>>>
>>>> For example: In DeltaSpike adding a ConfigSource for a config file on a
>>> shared folder is a mere 7 lines of code..
>>> In Tamaya, it will be about one line ;)
>>
>>
>>> Here the is issue: it needs you to code. This is not a feature of the
>>> framework.
>>>
>>>> Please don't let us go down the (old) Spring route to have miles of
>>> configuration for stuff which you could hack in just a few lines of code.
>>>
>>> In practise you don't always have the choice
>>
>>
>> *It all about options. I did never state that all features must end up in
>> core:*
>> *1) I always stated to have a simple API, just providing a COMPLETE SE API*
>>
>> * - config, config templates*
>> * - injection (also in SE)*
>> * - meta information*
>> * - support for reacting to config changes.*
>> * - and support for non String types. *
>>
>> * There is no more there, so I ask what is really wrong here? If its OK,
>> let's go ahead and focus on core.*
>>
>> *2) In core I would expect to have a minimal runtime implementation that
>> provides all features needed to cover most of the needs, meaning*
>>
>> * - reading config from the classpath, from files and URLs, *
>> * - using properties, xml-properties and ini as file format,*
>> * - implementing the type support mentioned, also including collection
>> support (not yet supported)*
>> * - and providing configuration combination features.*
>>
>> * By default a configuration model is provided, so people can just put
>> their config files at the right locations and start to work. Easy and
>> intuititve. What is wrong here I ask again?*
>>
>> *3) ALL THE REST are OPTIONAL EXTENSIONS, like CDI integration,Environment
>> management, more complex configuration models, remote support etc.,
>> remoting, JMX, JAX-RS *
>> * support and *
>> *whatever we (and users) think would be useful. When users are happy with
>> the module provided (we will hopefully have lots of discussions in the
>> next months and years to do it right), they may *
>> *use it OOTB. If not they can still write their own. It's all about
>> options, like in Java EE (Arun Gupta) ;)*
>> * *
>>
>>>>> we can start as
>>>>>> easy as reading a database
>>>>
>>>> We discussed this in DeltaSpike and deliberately did NOT add it. It's
>>> really really easy to implement a ConfigSource which goes into the DB
>>> yourself in 30 minutes.
>>>>
>>>> If we would provide this feature out of the box, then how would you do
>>> that?
>>>> * which database would you address?
>>>>
>>>> * JPA or JDBC native? again: what about the db vendor?
>>>> * how to configure your db user, your schema, etc?
>>>> * what about update and caching policies?
>>>> We would need some jar with JPA or whatever as dependency. Would need
>>> meta-configuration, yada yada yada. And all to avoid 100 lines of code?
>>> That just doesn't pay off!
>>>
>>> That's why I spoke about a "push" system. Then we just use java 7 file
>>> system watch solution.
>>
>> *That is modelled by the ConfigChangeSet, which contains a reference to
>> the current configuration and infos on the properties changed. This change
>> set can be applied to a config (pull scenario) or *
>> *published based on changes in the backenbd (push scenario).*
>>
>>
>>>> Probably add some sample code somewhere. It must be easily doable within
>>> our API but we should not try to implement that by default in our core jar.
>>
>> *As mentioned it was never targeting core ;)*
>>
>>
>>
>>>>>> it include crud
>>>>
>>>>>> api but also a GUI - and listeners/update events.
>>>>
>>>> Totally overengineered imo. How should a GUI look like which might
>>> change configuration in a Haddop Cluster or in a Docker installation? Or
>>> whatever comes around the corner next year... Just DON'T DO IT.
>>
>> *Basically, what is possible is to provide introsepction in existing
>> configuration. This is helpful for error analysis. More details here are to
>> be discussed. I don't see this as a core feature, but we must have it in
>> mind. Discussions will show, what is possible, But as before, don't rule
>> out everything, just before you are scared about it. If there is a need,
>> there must be at least a discussion. First things perhaps for @all: always
>> think if a use case should be part of the API, the core minimal
>> implementation, or an optional extension.*
>>
>>
>>
>>
>>>> There is of course an important very basic underlying design question:
>>> How to treat configured values which are non-mutable and might get cached
>>> vs ones which might change during the application lifetime?
>>>> Also: Do we like to introduce an own API for value-reload or do we
>>> leverage JMX?
>>>>
>>>> THOSE are the things I like to get clarified before we touch ANY code!
>>>
>>> JMX is mandatory IMO but JAXRS as well.
>>>
>>> *+1 *
>>
>> --
>> *Anatole Tresch*
>> Java Engineer & Architect, JSR Spec Lead
>> Glärnischweg 10
>> CH - 8620 Wetzikon
>>
>> *Switzerland, Europe Zurich, GMT+1*
>> *Twitter: @atsticks*
>> *Blogs: **http://javaremarkables.blogspot.ch/
>> <http://javaremarkables.blogspot.ch/>*
>>
>> *Google: atsticksMobile +41-76 344 62 79 <%2B41-76%20344%2062%2079>*
>>
>>
Re: [DISCUSS] increasing complexity of Tamaya
Posted by Mark Struberg <st...@yahoo.de>.
I don't quite get it. All your source pointers to deltaspike did concern the CdiCtrl module. Of course this has CDI dependencies...
What I was talking about are the following classes
https://github.com/apache/deltaspike/blob/master/deltaspike/core/api/src/main/java/org/apache/deltaspike/core/api/config/ConfigResolver.java
https://github.com/apache/deltaspike/blob/master/deltaspike/core/api/src/main/java/org/apache/deltaspike/core/spi/config/ConfigSource.java
https://github.com/apache/deltaspike/blob/master/deltaspike/core/api/src/main/java/org/apache/deltaspike/core/spi/config/ConfigFilter.java
https://github.com/apache/deltaspike/blob/master/deltaspike/core/api/src/main/java/org/apache/deltaspike/core/spi/config/ConfigSourceProvider.java
None of them has any CDI dependency. All the CDI functionality is built on top of that.
>*About what? Please, please, please give us the concrete use cases, you
>think Deltaspike supports, or supports better and tamaya does, with as much
>details possible.
I already gave one. See my first mail. The point is actually the other way around. I'm absolutely sure that we can do the same functionality that Tamaya has today in 1/10 of the code. And having less code usually also means having a much clearer and more flexible system at the end. It's just too bloated and I did read javadocs for two days and had so many wtf moments that all alarm bells did ring.
I understand that the current code is a organically grown system which is tried and proofed in some cases - but that is also it's problem. It's not lean and elegant anymore but just some historically grown piece it seems. I guess that many use cases which are possible within this framework are just not legit anymore.
>*1) I always stated to have a simple API, just providing a COMPLETE SE API*
Agree
>* - config, config templates*
Agree with config.
But ConfigTemplates are just syntactic sugar. I would not add it. It's just slower and not so easy to grasp for users.
>* - injection (also in SE)*
Disagree. What for? And how? Let's keep this as easy as possible.
>* - meta information*
TOTALLY over engineered. really!
>* - support for reacting to config changes.*
That's trickier. There are 2 ways. Push or Pull.
.) Push means -> sending out an event so config consumers know when to update. The problem is to make this reliable. You e.g. cannot use CDI as this only works with ThreadLocals. You also cannot use Observable as this would cause issues with mem leaks.
.) Pull means -> config consumers who are interested in changed values just call ConfigResolver#getProperty over again. This doesn't cause any performance issues if the config system is well done.
>* - and support for non String types. *
We've discussed this in length many times. Every time we started again it became clear pretty quickly that there is such a thing already: JNDI. And that's exactly why it does NOT work. It really sucks.
>* - reading config from the classpath, from files and URLs, *
That's the problem. The user is not interested in reading this and that file usually. Like with DI he is usually only interested in the final outcome.
>* - using properties, xml-properties and ini as file format,*
Why? The user doesn't care where the values did come from. We should really do this via a pluggable SPI.
Probably defining a few defaults (which could really include properties, etc). But it's more that we provide a SPI with a few impls of it out of the box. The emphasis is on the SPI and not on those 'sample' impls.
>* - implementing the type support mentioned, also including collection
>support (not yet supported)*
Collections support could be interesting
>* - and providing configuration combination features.*
What do you understand by that?
>* By default a configuration model is provided, so people can just put
>their config files at the right locations and start to work. Easy and
>intuititve. What is wrong here I ask again?*
Currently we don't provide that. It's just not easy and intuitive right now.
>*3) ALL THE REST are OPTIONAL EXTENSIONS, like CDI integration,Environment
>management, more complex configuration models, remote support etc.,
>remoting, JMX, JAX-RS *
I agree.
LieGrue,
strub
On Tuesday, 23 December 2014, 14:37, Anatole Tresch <at...@gmail.com> wrote:
>Hi Romain/all
>
>just a few additions inline...
>
>2014-12-23 11:04 GMT+01:00 Romain Manni-Bucau <rm...@gmail.com>:
>
>> About Environment and distirbuted system: the issue is the same with
>> or without. You always need a local config vs the global one but I
>> strongly think a system property, jndi entry or anything else can be
>> enough and don't need to be in tamaya itself to start.
>>
>> 2014-12-23 10:31 GMT+01:00 Mark Struberg <st...@yahoo.de>:
>> >> so you can ask the config server for the right config.
>> > Gosh, that scares me a bit! Don't even think about config servers. Such
>> things must be totally up to the vendor. We must allow making such things
>> possible with our API but we shall NOT support such things out of the box!
>> > The best would be to make our API in a way that even the user
>> (application programmer) could add such a mechanism to it himself.
>>
>*I would not rule that completely out, this is a use case. We should
>discuss that once we are ready for it (all the basics are in place) how
>much we can go for it (meaning how much we can support things OOTB)..
>Definitively it is not part of the core delivery, but could be an optional
>module to be added.*
>
>
>
>> >> For me SE comes first. EE builds on top not the other way round!
>> >
>> >
>> > Totally agree with that.
>> Fine.
>>
>
>
>> >> But it (DeltaSpike) is inheritly connected to CDI and
>> >
>> > That's just not true.
>
>*Why, there is a cmpile time depoendency to cdictl-se,
>see https://git-wip-us.apache.org/repos/asf?p=deltaspike.git;a=blob_plain;f=deltaspike/pom.xml;hb=HEAD
><https://git-wip-us.apache.org/repos/asf?p=deltaspike.git;a=blob_plain;f=deltaspike/pom.xml;hb=HEAD>*
>
>*As a code example people here on the list my have a look at
>https://git-wip-us.apache.org/repos/asf?p=deltaspike.git;a=blob_plain;f=deltaspike/cdictrl/api/src/main/java/org/apache/deltaspike/cdise/api/CdiContainer.java;hb=HEAD
><https://git-wip-us.apache.org/repos/asf?p=deltaspike.git;a=blob_plain;f=deltaspike/cdictrl/api/src/main/java/org/apache/deltaspike/cdise/api/CdiContainer.java;hb=HEAD>*
>**
>*Or they look at the @ConfiguredPropertyx annotation:
>https://git-wip-us.apache.org/repos/asf?p=deltaspike.git;a=blob_plain;f=deltaspike/core/api/src/main/java/org/apache/deltaspike/core/api/config/ConfigProperty.java;hb=HEAD
><https://git-wip-us.apache.org/repos/asf?p=deltaspike.git;a=blob_plain;f=deltaspike/core/api/src/main/java/org/apache/deltaspike/core/api/config/ConfigProperty.java;hb=HEAD>*
>
>*and they see:*
>
>*import javax.enterprise.util.Nonbinding;
>import javax.inject.Qualifier;*
>
>
>And it's tried and used successfully in many big projects (including my own
>> which deals with 50 bn EUR, german stock exchange, UK stock exchange, big
>> swiss banks, etc).
>> > I'm not saying the DS api is the best, but it is able to do all that and
>> is 1/20th of the complexity and size of Tamaya right now. And still being
>> more powerful.
>>
>
>*About what? Please, please, please give us the concrete use cases, you
>think Deltaspike supports, or supports better and tamaya does, with as much
>details possible. That is the only way we*
>*a) can bullet.proof our considerations and also see, where our use cases
>differ.*
>*b) really compare concepts, instead of just arguing that things are much
>more complex.*
>*c) help also to get a better understanding of the concepts in place so far
>and see how things can be improved.*
>
>
>
>> It is Mark, at least in term of dependencies, I asked months ago to
>> explode core part but it was not the moment I guess ;)
>>
>> >
>> >>> things not working out of the box: distributed configs
>> >
>> > For which distributed system?
>> > * Ehcache?
>> >
>> > * Terracotty?
>> > * Hadoop like clustering?
>> > * a simple shared file store?
>> > Where to put the meta-configuration for it? Where to define which one to
>> use?
>> > What fallback strategies to choose?
>> >
>>
>>
>> Never spoke of any technology. Spoke in term of use case: I have 5
>> machines which need to read the same config. Constraint I'd like to
>> respet is: don't force a "complicated" config like hazelcast one for
>> instance.
>>
>> > All that HEAVILY depends on the situation and scenario you have in your
>> project. There is just nothing we can decide for the customer. All we can
>> do is to make it VERY EASY to implement it yourself.
>> >
>> > For example: In DeltaSpike adding a ConfigSource for a config file on a
>> shared folder is a mere 7 lines of code..
>> In Tamaya, it will be about one line ;)
>>
>
>
>> Here the is issue: it needs you to code. This is not a feature of the
>> framework.
>>
>> > Please don't let us go down the (old) Spring route to have miles of
>> configuration for stuff which you could hack in just a few lines of code.
>> >
>>
>> In practise you don't always have the choice
>
>
>*It all about options. I did never state that all features must end up in
>core:*
>*1) I always stated to have a simple API, just providing a COMPLETE SE API*
>
>* - config, config templates*
>* - injection (also in SE)*
>* - meta information*
>* - support for reacting to config changes.*
>* - and support for non String types. *
>
>* There is no more there, so I ask what is really wrong here? If its OK,
>let's go ahead and focus on core.*
>
>*2) In core I would expect to have a minimal runtime implementation that
>provides all features needed to cover most of the needs, meaning*
>
>* - reading config from the classpath, from files and URLs, *
>* - using properties, xml-properties and ini as file format,*
>* - implementing the type support mentioned, also including collection
>support (not yet supported)*
>* - and providing configuration combination features.*
>
>* By default a configuration model is provided, so people can just put
>their config files at the right locations and start to work. Easy and
>intuititve. What is wrong here I ask again?*
>
>*3) ALL THE REST are OPTIONAL EXTENSIONS, like CDI integration,Environment
>management, more complex configuration models, remote support etc.,
>remoting, JMX, JAX-RS *
>* support and *
>*whatever we (and users) think would be useful. When users are happy with
>the module provided (we will hopefully have lots of discussions in the
>next months and years to do it right), they may *
>*use it OOTB. If not they can still write their own. It's all about
>options, like in Java EE (Arun Gupta) ;)*
>* *
>
>>>> we can start as
>> >>> easy as reading a database
>> >
>> > We discussed this in DeltaSpike and deliberately did NOT add it. It's
>> really really easy to implement a ConfigSource which goes into the DB
>> yourself in 30 minutes.
>> >
>> > If we would provide this feature out of the box, then how would you do
>> that?
>> > * which database would you address?
>> >
>> > * JPA or JDBC native? again: what about the db vendor?
>> > * how to configure your db user, your schema, etc?
>> > * what about update and caching policies?
>> > We would need some jar with JPA or whatever as dependency. Would need
>> meta-configuration, yada yada yada. And all to avoid 100 lines of code?
>> That just doesn't pay off!
>> >
>>
>> That's why I spoke about a "push" system. Then we just use java 7 file
>> system watch solution.
>
>*That is modelled by the ConfigChangeSet, which contains a reference to
>the current configuration and infos on the properties changed. This change
>set can be applied to a config (pull scenario) or *
>*published based on changes in the backenbd (push scenario).*
>
>
>> > Probably add some sample code somewhere. It must be easily doable within
>> our API but we should not try to implement that by default in our core jar.
>>
>
>*As mentioned it was never targeting core ;)*
>
>
>
>> >>> it include crud
>> >
>> >>> api but also a GUI - and listeners/update events.
>> >
>> > Totally overengineered imo. How should a GUI look like which might
>> change configuration in a Haddop Cluster or in a Docker installation? Or
>> whatever comes around the corner next year... Just DON'T DO IT.
>>
>
>*Basically, what is possible is to provide introsepction in existing
>configuration. This is helpful for error analysis. More details here are to
>be discussed. I don't see this as a core feature, but we must have it in
>mind. Discussions will show, what is possible, But as before, don't rule
>out everything, just before you are scared about it. If there is a need,
>there must be at least a discussion. First things perhaps for @all: always
>think if a use case should be part of the API, the core minimal
>implementation, or an optional extension.*
>
>
>
>
>> > There is of course an important very basic underlying design question:
>> How to treat configured values which are non-mutable and might get cached
>> vs ones which might change during the application lifetime?
>> > Also: Do we like to introduce an own API for value-reload or do we
>> leverage JMX?
>> >
>> > THOSE are the things I like to get clarified before we touch ANY code!
>> >
>> >
>>
>> JMX is mandatory IMO but JAXRS as well.
>>
>> *+1 *
>
>--
>*Anatole Tresch*
>Java Engineer & Architect, JSR Spec Lead
>Glärnischweg 10
>CH - 8620 Wetzikon
>
>*Switzerland, Europe Zurich, GMT+1*
>*Twitter: @atsticks*
>*Blogs: **http://javaremarkables.blogspot.ch/
><http://javaremarkables.blogspot.ch/>*
>
>*Google: atsticksMobile +41-76 344 62 79 <%2B41-76%20344%2062%2079>*
>
>
Re: [DISCUSS] increasing complexity of Tamaya
Posted by Anatole Tresch <at...@gmail.com>.
Hi Romain/all
just a few additions inline...
2014-12-23 11:04 GMT+01:00 Romain Manni-Bucau <rm...@gmail.com>:
> About Environment and distirbuted system: the issue is the same with
> or without. You always need a local config vs the global one but I
> strongly think a system property, jndi entry or anything else can be
> enough and don't need to be in tamaya itself to start.
>
> 2014-12-23 10:31 GMT+01:00 Mark Struberg <st...@yahoo.de>:
> >> so you can ask the config server for the right config.
> > Gosh, that scares me a bit! Don't even think about config servers. Such
> things must be totally up to the vendor. We must allow making such things
> possible with our API but we shall NOT support such things out of the box!
> > The best would be to make our API in a way that even the user
> (application programmer) could add such a mechanism to it himself.
>
*I would not rule that completely out, this is a use case. We should
discuss that once we are ready for it (all the basics are in place) how
much we can go for it (meaning how much we can support things OOTB)..
Definitively it is not part of the core delivery, but could be an optional
module to be added.*
> >> For me SE comes first. EE builds on top not the other way round!
> >
> >
> > Totally agree with that.
> Fine.
>
> >> But it (DeltaSpike) is inheritly connected to CDI and
> >
> > That's just not true.
*Why, there is a cmpile time depoendency to cdictl-se,
see https://git-wip-us.apache.org/repos/asf?p=deltaspike.git;a=blob_plain;f=deltaspike/pom.xml;hb=HEAD
<https://git-wip-us.apache.org/repos/asf?p=deltaspike.git;a=blob_plain;f=deltaspike/pom.xml;hb=HEAD>*
*As a code example people here on the list my have a look at
https://git-wip-us.apache.org/repos/asf?p=deltaspike.git;a=blob_plain;f=deltaspike/cdictrl/api/src/main/java/org/apache/deltaspike/cdise/api/CdiContainer.java;hb=HEAD
<https://git-wip-us.apache.org/repos/asf?p=deltaspike.git;a=blob_plain;f=deltaspike/cdictrl/api/src/main/java/org/apache/deltaspike/cdise/api/CdiContainer.java;hb=HEAD>*
**
*Or they look at the @ConfiguredPropertyx annotation:
https://git-wip-us.apache.org/repos/asf?p=deltaspike.git;a=blob_plain;f=deltaspike/core/api/src/main/java/org/apache/deltaspike/core/api/config/ConfigProperty.java;hb=HEAD
<https://git-wip-us.apache.org/repos/asf?p=deltaspike.git;a=blob_plain;f=deltaspike/core/api/src/main/java/org/apache/deltaspike/core/api/config/ConfigProperty.java;hb=HEAD>*
*and they see:*
*import javax.enterprise.util.Nonbinding;
import javax.inject.Qualifier;*
And it's tried and used successfully in many big projects (including my own
> which deals with 50 bn EUR, german stock exchange, UK stock exchange, big
> swiss banks, etc).
> > I'm not saying the DS api is the best, but it is able to do all that and
> is 1/20th of the complexity and size of Tamaya right now. And still being
> more powerful.
>
*About what? Please, please, please give us the concrete use cases, you
think Deltaspike supports, or supports better and tamaya does, with as much
details possible. That is the only way we*
*a) can bullet.proof our considerations and also see, where our use cases
differ.*
*b) really compare concepts, instead of just arguing that things are much
more complex.*
*c) help also to get a better understanding of the concepts in place so far
and see how things can be improved.*
> It is Mark, at least in term of dependencies, I asked months ago to
> explode core part but it was not the moment I guess ;)
>
> >
> >>> things not working out of the box: distributed configs
> >
> > For which distributed system?
> > * Ehcache?
> >
> > * Terracotty?
> > * Hadoop like clustering?
> > * a simple shared file store?
> > Where to put the meta-configuration for it? Where to define which one to
> use?
> > What fallback strategies to choose?
> >
>
>
> Never spoke of any technology. Spoke in term of use case: I have 5
> machines which need to read the same config. Constraint I'd like to
> respet is: don't force a "complicated" config like hazelcast one for
> instance.
>
> > All that HEAVILY depends on the situation and scenario you have in your
> project. There is just nothing we can decide for the customer. All we can
> do is to make it VERY EASY to implement it yourself.
> >
> > For example: In DeltaSpike adding a ConfigSource for a config file on a
> shared folder is a mere 7 lines of code..
> In Tamaya, it will be about one line ;)
>
> Here the is issue: it needs you to code. This is not a feature of the
> framework.
>
> > Please don't let us go down the (old) Spring route to have miles of
> configuration for stuff which you could hack in just a few lines of code.
> >
>
> In practise you don't always have the choice
*It all about options. I did never state that all features must end up in
core:*
*1) I always stated to have a simple API, just providing a COMPLETE SE API*
* - config, config templates*
* - injection (also in SE)*
* - meta information*
* - support for reacting to config changes.*
* - and support for non String types. *
* There is no more there, so I ask what is really wrong here? If its OK,
let's go ahead and focus on core.*
*2) In core I would expect to have a minimal runtime implementation that
provides all features needed to cover most of the needs, meaning*
* - reading config from the classpath, from files and URLs, *
* - using properties, xml-properties and ini as file format,*
* - implementing the type support mentioned, also including collection
support (not yet supported)*
* - and providing configuration combination features.*
* By default a configuration model is provided, so people can just put
their config files at the right locations and start to work. Easy and
intuititve. What is wrong here I ask again?*
*3) ALL THE REST are OPTIONAL EXTENSIONS, like CDI integration,Environment
management, more complex configuration models, remote support etc.,
remoting, JMX, JAX-RS *
* support and *
*whatever we (and users) think would be useful. When users are happy with
the module provided (we will hopefully have lots of discussions in the
next months and years to do it right), they may *
*use it OOTB. If not they can still write their own. It's all about
options, like in Java EE (Arun Gupta) ;)*
* *
>>> we can start as
> >>> easy as reading a database
> >
> > We discussed this in DeltaSpike and deliberately did NOT add it. It's
> really really easy to implement a ConfigSource which goes into the DB
> yourself in 30 minutes.
> >
> > If we would provide this feature out of the box, then how would you do
> that?
> > * which database would you address?
> >
> > * JPA or JDBC native? again: what about the db vendor?
> > * how to configure your db user, your schema, etc?
> > * what about update and caching policies?
> > We would need some jar with JPA or whatever as dependency. Would need
> meta-configuration, yada yada yada. And all to avoid 100 lines of code?
> That just doesn't pay off!
> >
>
> That's why I spoke about a "push" system. Then we just use java 7 file
> system watch solution.
*That is modelled by the ConfigChangeSet, which contains a reference to
the current configuration and infos on the properties changed. This change
set can be applied to a config (pull scenario) or *
*published based on changes in the backenbd (push scenario).*
> > Probably add some sample code somewhere. It must be easily doable within
> our API but we should not try to implement that by default in our core jar.
>
*As mentioned it was never targeting core ;)*
> >>> it include crud
> >
> >>> api but also a GUI - and listeners/update events.
> >
> > Totally overengineered imo. How should a GUI look like which might
> change configuration in a Haddop Cluster or in a Docker installation? Or
> whatever comes around the corner next year... Just DON'T DO IT.
>
*Basically, what is possible is to provide introsepction in existing
configuration. This is helpful for error analysis. More details here are to
be discussed. I don't see this as a core feature, but we must have it in
mind. Discussions will show, what is possible, But as before, don't rule
out everything, just before you are scared about it. If there is a need,
there must be at least a discussion. First things perhaps for @all: always
think if a use case should be part of the API, the core minimal
implementation, or an optional extension.*
> > There is of course an important very basic underlying design question:
> How to treat configured values which are non-mutable and might get cached
> vs ones which might change during the application lifetime?
> > Also: Do we like to introduce an own API for value-reload or do we
> leverage JMX?
> >
> > THOSE are the things I like to get clarified before we touch ANY code!
> >
> >
>
> JMX is mandatory IMO but JAXRS as well.
>
> *+1 *
--
*Anatole Tresch*
Java Engineer & Architect, JSR Spec Lead
Glärnischweg 10
CH - 8620 Wetzikon
*Switzerland, Europe Zurich, GMT+1*
*Twitter: @atsticks*
*Blogs: **http://javaremarkables.blogspot.ch/
<http://javaremarkables.blogspot.ch/>*
*Google: atsticksMobile +41-76 344 62 79 <%2B41-76%20344%2062%2079>*
Re: [DISCUSS] increasing complexity of Tamaya
Posted by Romain Manni-Bucau <rm...@gmail.com>.
About Environment and distirbuted system: the issue is the same with
or without. You always need a local config vs the global one but I
strongly think a system property, jndi entry or anything else can be
enough and don't need to be in tamaya itself to start.
2014-12-23 10:31 GMT+01:00 Mark Struberg <st...@yahoo.de>:
>> so you can ask the config server for the right config.
>
>
>
> Gosh, that scares me a bit! Don't even think about config servers. Such things must be totally up to the vendor. We must allow making such things possible with our API but we shall NOT support such things out of the box!
> The best would be to make our API in a way that even the user (application programmer) could add such a mechanism to it himself.
>
>
>
>> For me SE comes first. EE builds on top not the other way round!
>
>
> Totally agree with that.
>
>
>
>
>> But it (DeltaSpike) is inheritly connected to CDI and
>
> That's just not true. And it's tried and used successfully in many big projects (including my own which deals with 50 bn EUR, german stock exchange, UK stock exchange, big swiss banks, etc).
> I'm not saying the DS api is the best, but it is able to do all that and is 1/20th of the complexity and size of Tamaya right now. And still being more powerful.
>
It is Mark, at least in term of dependencies, I asked months ago to
explode core part but it was not the moment I guess ;)
>
>>> things not working out of the box: distributed configs
>
> For which distributed system?
> * Ehcache?
>
> * Terracotty?
> * Hadoop like clustering?
> * a simple shared file store?
> Where to put the meta-configuration for it? Where to define which one to use?
> What fallback strategies to choose?
>
Never spoke of any technology. Spoke in term of use case: I have 5
machines which need to read the same config. Constraint I'd like to
respet is: don't force a "complicated" config like hazelcast one for
instance.
> All that HEAVILY depends on the situation and scenario you have in your project. There is just nothing we can decide for the customer. All we can do is to make it VERY EASY to implement it yourself.
>
> For example: In DeltaSpike adding a ConfigSource for a config file on a shared folder is a mere 7 lines of code..
>
Here the is issue: it needs you to code. This is not a feature of the framework.
> Please don't let us go down the (old) Spring route to have miles of configuration for stuff which you could hack in just a few lines of code.
>
In practise you don't always have the choice.
>
>
>>> we can start as
>>> easy as reading a database
>
> We discussed this in DeltaSpike and deliberately did NOT add it. It's really really easy to implement a ConfigSource which goes into the DB yourself in 30 minutes.
>
> If we would provide this feature out of the box, then how would you do that?
> * which database would you address?
>
> * JPA or JDBC native? again: what about the db vendor?
> * how to configure your db user, your schema, etc?
> * what about update and caching policies?
> We would need some jar with JPA or whatever as dependency. Would need meta-configuration, yada yada yada. And all to avoid 100 lines of code? That just doesn't pay off!
>
That's why I spoke about a "push" system. Then we just use java 7 file
system watch solution.
> Probably add some sample code somewhere. It must be easily doable within our API but we should not try to implement that by default in our core jar.
>
>
>
>>> it include crud
>
>>> api but also a GUI - and listeners/update events.
>
> Totally overengineered imo. How should a GUI look like which might change configuration in a Haddop Cluster or in a Docker installation? Or whatever comes around the corner next year... Just DON'T DO IT.
> There is of course an important very basic underlying design question: How to treat configured values which are non-mutable and might get cached vs ones which might change during the application lifetime?
> Also: Do we like to introduce an own API for value-reload or do we leverage JMX?
>
> THOSE are the things I like to get clarified before we touch ANY code!
>
>
JMX is mandatory IMO but JAXRS as well.
>
>
>>>> ... and BTW, what a meant with the "guts feeling": I would
>> like to see
>>>> concrete proposals: just say what you want to change IN CODE, or at
>> least
>>>> more precisely. Just saying it is too complex is IMO not very
>> constructive.
>>>> Also it is more concrete for everybody here on the list.
>
> That's why I gave you a use case in my original post. Solve this problem with the current Tamaya source base please. And also please give me use cases which you think are important and work cool with Tamaya. And then lets discuss whether the use case makes sense and how we could do it in the easiest way.
>
>
>
> LieGrue,
> strub
>
>
>
>> On Tuesday, 23 December 2014, 9:02, Anatole Tresch <at...@gmail.com> wrote:
>> >Good Morning
>>
>> See inline...
>>
>> Anatole
>>
>>
>>> Am 23.12.2014 um 08:25 schrieb Romain Manni-Bucau
>> <rm...@gmail.com>:
>>>
>>> Hi
>>>
>>> Yeah Environment is surely optional in practise.
>> ;) though when you deal with remote configuration it gets more important because
>> you need it to identify, what stage, network zone, deployment type, whatever you
>> are, so you can ask the config server for the right config. Similarly you will
>> have overridings in place that are active depending your environment. As
>> outlined before granularity here may exceed what we have today in Java EE.
>>
>>> Wonder if we didnt think in the wrong way. I mean if you start from an IoC
>>> usages then API is always smarter than from SE case. Then aligning SE on
>>> IoC is quite easier than the opposite.
>> you even dont want to use IoC or even worse, but often reality, you have lots of
>> hardwired legacy code, where IoC is even not an option, even though you are
>> running in a IoC capable container...
>> For me SE comes first. EE builds on top not the other way round!
>>
>>> For IoC side the DeltaSpike API is great. What do we miss then?
>> agree, it was a good first step. But it is inheritly connected to CDI and
>> therefore to the same reasons outlined before is by far not able to cover legacy
>> environments (which is the mast majority in many bigger companies with a
>> mulitmillion investment in IT.
>>
>>> Mainly 3
>>> things not working out of the box: distributed configs - we can start as
>>> easy as reading a database
>> Yep, will add that use case more explicitly.
>>
>>> but i would like to be able to rely on local
>>> files and move this distributed logic in a separate module reading a
>>> database or anything else to push files on disk to avoid issues if the db
>>> is down, write part of the config ie how do I update it - it include crud
>>> api but also a GUI - and listeners/update events.
>> Yeah. That is also where I see options for having buildingblocks provided. Eg
>> not every tamaya user should implement caching/distribution ans security on its
>> own. On the other side I do not expect thatall tthese features will already be
>> existing on the first release...
>> It is similar to Spring security. You dont want all users to implement all the
>> apis, you provide reusable building blocks...
>>
>>> In terms of API it is quite easy and all the power would come from the impl
>>> IMO.
>> Agree. That is the PropertySource currently. Or setters for templates, or
>> apply(ConfigChangeSet) for Confuguration/PropertySource. All the rest can be
>> hidden.
>>
>>
>>> Le 23 déc. 2014 01:56, "Anatole Tresch"
>> <at...@gmail.com> a écrit :
>>>
>>>> ... and BTW, what a meant with the "guts feeling": I would
>> like to see
>>>> concrete proposals: just say what you want to change IN CODE, or at
>> least
>>>> more precisely. Just saying it is too complex is IMO not very
>> constructive.
>>>> Also it is more concrete for everybody here on the list.
>>>>
>>>> Some examples:
>>>> If you would ask me e.g. to replace the ConfigManager and
>>>> EnvironmentManager in API by simply accessing the ServiceContext from
>> the
>>>> facade artifacts, I would agree.
>>>> If you ask for reducing the number of SPIs in core and perhaps move a
>> more
>>>> complex environment singleton implementation out to somewhere else, I
>> would
>>>> agree.
>>>> Theoretically we could even move the Environment part into a separate
>>>> module and simply let the Configuration part be the core part of the
>> API...
>>>>
>>>> Just my few cents here.
>>>>
>>>> Cheers,
>>>> Anatole
>>>>
>>>>
>>>>
>>>> 2014-12-23 1:01 GMT+01:00 Oliver B. Fischer
>> <o....@swe-blog.net>:
>>>>
>>>>> Hi all, I think we need this discussion. Let me list my points:
>>>>>
>>>>> 1. Yes, Tamaya is to complex at the moment.
>>>>> 2. It seems to be to complex.
>>>>> 3. We do not finish discussions on the list and start to early to
>>>>> implement things.
>>>>>
>>>>> How can we change this?
>>>>>
>>>>> 1. Let us write down a list of use cases we would like to support.
>>>>> 2. Let us discuss how to support these use cases.
>>>>>
>>>>> Without this approach we will have the same discussions again and
>> again.
>>>>>
>>>>> Second we should try to keep the API as elegant and minimal as
>> possible
>>>>> for simple use cases. Tamaya should also be possible go handle
>> complex
>>>> use
>>>>> cases.
>>>>>
>>>>> May we shouldn't have started with an existing code base.
>>>>>
>>>>> Best,
>>>>>
>>>>> Oliver
>>>>>
>>>>>
>>>>> Von meinem iPhone gesendet
>>>>>
>>>>>> Am 22.12.2014 um 17:36 schrieb Mark Struberg
>> <st...@yahoo.de>:
>>>>>>
>>>>>> 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
>>>>
>>>>
>>>>
>>>> --
>>>> *Anatole Tresch*
>>>> Java Engineer & Architect, JSR Spec Lead
>>>> Glärnischweg 10
>>>> CH - 8620 Wetzikon
>>>>
>>>> *Switzerland, Europe Zurich, GMT+1*
>>>> *Twitter: @atsticks*
>>>> *Blogs: **http://javaremarkables.blogspot.ch/
>>>> <http://javaremarkables.blogspot.ch/>*
>>>>
>>>> *Google: atsticksMobile +41-76 344 62 79*
>>>>
>>
Re: [DISCUSS] increasing complexity of Tamaya
Posted by Mark Struberg <st...@yahoo.de>.
> so you can ask the config server for the right config.
Gosh, that scares me a bit! Don't even think about config servers. Such things must be totally up to the vendor. We must allow making such things possible with our API but we shall NOT support such things out of the box!
The best would be to make our API in a way that even the user (application programmer) could add such a mechanism to it himself.
> For me SE comes first. EE builds on top not the other way round!
Totally agree with that.
> But it (DeltaSpike) is inheritly connected to CDI and
That's just not true. And it's tried and used successfully in many big projects (including my own which deals with 50 bn EUR, german stock exchange, UK stock exchange, big swiss banks, etc).
I'm not saying the DS api is the best, but it is able to do all that and is 1/20th of the complexity and size of Tamaya right now. And still being more powerful.
>> things not working out of the box: distributed configs
For which distributed system?
* Ehcache?
* Terracotty?
* Hadoop like clustering?
* a simple shared file store?
Where to put the meta-configuration for it? Where to define which one to use?
What fallback strategies to choose?
All that HEAVILY depends on the situation and scenario you have in your project. There is just nothing we can decide for the customer. All we can do is to make it VERY EASY to implement it yourself.
For example: In DeltaSpike adding a ConfigSource for a config file on a shared folder is a mere 7 lines of code..
Please don't let us go down the (old) Spring route to have miles of configuration for stuff which you could hack in just a few lines of code.
>> we can start as
>> easy as reading a database
We discussed this in DeltaSpike and deliberately did NOT add it. It's really really easy to implement a ConfigSource which goes into the DB yourself in 30 minutes.
If we would provide this feature out of the box, then how would you do that?
* which database would you address?
* JPA or JDBC native? again: what about the db vendor?
* how to configure your db user, your schema, etc?
* what about update and caching policies?
We would need some jar with JPA or whatever as dependency. Would need meta-configuration, yada yada yada. And all to avoid 100 lines of code? That just doesn't pay off!
Probably add some sample code somewhere. It must be easily doable within our API but we should not try to implement that by default in our core jar.
>> it include crud
>> api but also a GUI - and listeners/update events.
Totally overengineered imo. How should a GUI look like which might change configuration in a Haddop Cluster or in a Docker installation? Or whatever comes around the corner next year... Just DON'T DO IT.
There is of course an important very basic underlying design question: How to treat configured values which are non-mutable and might get cached vs ones which might change during the application lifetime?
Also: Do we like to introduce an own API for value-reload or do we leverage JMX?
THOSE are the things I like to get clarified before we touch ANY code!
>>> ... and BTW, what a meant with the "guts feeling": I would
> like to see
>>> concrete proposals: just say what you want to change IN CODE, or at
> least
>>> more precisely. Just saying it is too complex is IMO not very
> constructive.
>>> Also it is more concrete for everybody here on the list.
That's why I gave you a use case in my original post. Solve this problem with the current Tamaya source base please. And also please give me use cases which you think are important and work cool with Tamaya. And then lets discuss whether the use case makes sense and how we could do it in the easiest way.
LieGrue,
strub
> On Tuesday, 23 December 2014, 9:02, Anatole Tresch <at...@gmail.com> wrote:
> >Good Morning
>
> See inline...
>
> Anatole
>
>
>> Am 23.12.2014 um 08:25 schrieb Romain Manni-Bucau
> <rm...@gmail.com>:
>>
>> Hi
>>
>> Yeah Environment is surely optional in practise.
> ;) though when you deal with remote configuration it gets more important because
> you need it to identify, what stage, network zone, deployment type, whatever you
> are, so you can ask the config server for the right config. Similarly you will
> have overridings in place that are active depending your environment. As
> outlined before granularity here may exceed what we have today in Java EE.
>
>> Wonder if we didnt think in the wrong way. I mean if you start from an IoC
>> usages then API is always smarter than from SE case. Then aligning SE on
>> IoC is quite easier than the opposite.
> you even dont want to use IoC or even worse, but often reality, you have lots of
> hardwired legacy code, where IoC is even not an option, even though you are
> running in a IoC capable container...
> For me SE comes first. EE builds on top not the other way round!
>
>> For IoC side the DeltaSpike API is great. What do we miss then?
> agree, it was a good first step. But it is inheritly connected to CDI and
> therefore to the same reasons outlined before is by far not able to cover legacy
> environments (which is the mast majority in many bigger companies with a
> mulitmillion investment in IT.
>
>> Mainly 3
>> things not working out of the box: distributed configs - we can start as
>> easy as reading a database
> Yep, will add that use case more explicitly.
>
>> but i would like to be able to rely on local
>> files and move this distributed logic in a separate module reading a
>> database or anything else to push files on disk to avoid issues if the db
>> is down, write part of the config ie how do I update it - it include crud
>> api but also a GUI - and listeners/update events.
> Yeah. That is also where I see options for having buildingblocks provided. Eg
> not every tamaya user should implement caching/distribution ans security on its
> own. On the other side I do not expect thatall tthese features will already be
> existing on the first release...
> It is similar to Spring security. You dont want all users to implement all the
> apis, you provide reusable building blocks...
>
>> In terms of API it is quite easy and all the power would come from the impl
>> IMO.
> Agree. That is the PropertySource currently. Or setters for templates, or
> apply(ConfigChangeSet) for Confuguration/PropertySource. All the rest can be
> hidden.
>
>
>> Le 23 déc. 2014 01:56, "Anatole Tresch"
> <at...@gmail.com> a écrit :
>>
>>> ... and BTW, what a meant with the "guts feeling": I would
> like to see
>>> concrete proposals: just say what you want to change IN CODE, or at
> least
>>> more precisely. Just saying it is too complex is IMO not very
> constructive.
>>> Also it is more concrete for everybody here on the list.
>>>
>>> Some examples:
>>> If you would ask me e.g. to replace the ConfigManager and
>>> EnvironmentManager in API by simply accessing the ServiceContext from
> the
>>> facade artifacts, I would agree.
>>> If you ask for reducing the number of SPIs in core and perhaps move a
> more
>>> complex environment singleton implementation out to somewhere else, I
> would
>>> agree.
>>> Theoretically we could even move the Environment part into a separate
>>> module and simply let the Configuration part be the core part of the
> API...
>>>
>>> Just my few cents here.
>>>
>>> Cheers,
>>> Anatole
>>>
>>>
>>>
>>> 2014-12-23 1:01 GMT+01:00 Oliver B. Fischer
> <o....@swe-blog.net>:
>>>
>>>> Hi all, I think we need this discussion. Let me list my points:
>>>>
>>>> 1. Yes, Tamaya is to complex at the moment.
>>>> 2. It seems to be to complex.
>>>> 3. We do not finish discussions on the list and start to early to
>>>> implement things.
>>>>
>>>> How can we change this?
>>>>
>>>> 1. Let us write down a list of use cases we would like to support.
>>>> 2. Let us discuss how to support these use cases.
>>>>
>>>> Without this approach we will have the same discussions again and
> again.
>>>>
>>>> Second we should try to keep the API as elegant and minimal as
> possible
>>>> for simple use cases. Tamaya should also be possible go handle
> complex
>>> use
>>>> cases.
>>>>
>>>> May we shouldn't have started with an existing code base.
>>>>
>>>> Best,
>>>>
>>>> Oliver
>>>>
>>>>
>>>> Von meinem iPhone gesendet
>>>>
>>>>> Am 22.12.2014 um 17:36 schrieb Mark Struberg
> <st...@yahoo.de>:
>>>>>
>>>>> 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
>>>
>>>
>>>
>>> --
>>> *Anatole Tresch*
>>> Java Engineer & Architect, JSR Spec Lead
>>> Glärnischweg 10
>>> CH - 8620 Wetzikon
>>>
>>> *Switzerland, Europe Zurich, GMT+1*
>>> *Twitter: @atsticks*
>>> *Blogs: **http://javaremarkables.blogspot.ch/
>>> <http://javaremarkables.blogspot.ch/>*
>>>
>>> *Google: atsticksMobile +41-76 344 62 79*
>>>
>
Re: [DISCUSS] increasing complexity of Tamaya
Posted by Anatole Tresch <at...@gmail.com>.
Good Morning
See inline...
Anatole
> Am 23.12.2014 um 08:25 schrieb Romain Manni-Bucau <rm...@gmail.com>:
>
> Hi
>
> Yeah Environment is surely optional in practise.
;) though when you deal with remote configuration it gets more important because you need it to identify, what stage, network zone, deployment type, whatever you are, so you can ask the config server for the right config. Similarly you will have overridings in place that are active depending your environment. As outlined before granularity here may exceed what we have today in Java EE.
> Wonder if we didnt think in the wrong way. I mean if you start from an IoC
> usages then API is always smarter than from SE case. Then aligning SE on
> IoC is quite easier than the opposite.
you even dont want to use IoC or even worse, but often reality, you have lots of hardwired legacy code, where IoC is even not an option, even though you are running in a IoC capable container...
For me SE comes first. EE builds on top not the other way round!
> For IoC side the DeltaSpike API is great. What do we miss then?
agree, it was a good first step. But it is inheritly connected to CDI and therefore to the same reasons outlined before is by far not able to cover legacy environments (which is the mast majority in many bigger companies with a mulitmillion investment in IT.
> Mainly 3
> things not working out of the box: distributed configs - we can start as
> easy as reading a database
Yep, will add that use case more explicitly.
> but i would like to be able to rely on local
> files and move this distributed logic in a separate module reading a
> database or anything else to push files on disk to avoid issues if the db
> is down, write part of the config ie how do I update it - it include crud
> api but also a GUI - and listeners/update events.
Yeah. That is also where I see options for having buildingblocks provided. Eg not every tamaya user should implement caching/distribution ans security on its own. On the other side I do not expect thatall tthese features will already be existing on the first release...
It is similar to Spring security. You dont want all users to implement all the apis, you provide reusable building blocks...
> In terms of API it is quite easy and all the power would come from the impl
> IMO.
Agree. That is the PropertySource currently. Or setters for templates, or apply(ConfigChangeSet) for Confuguration/PropertySource. All the rest can be hidden.
> Le 23 déc. 2014 01:56, "Anatole Tresch" <at...@gmail.com> a écrit :
>
>> ... and BTW, what a meant with the "guts feeling": I would like to see
>> concrete proposals: just say what you want to change IN CODE, or at least
>> more precisely. Just saying it is too complex is IMO not very constructive.
>> Also it is more concrete for everybody here on the list.
>>
>> Some examples:
>> If you would ask me e.g. to replace the ConfigManager and
>> EnvironmentManager in API by simply accessing the ServiceContext from the
>> facade artifacts, I would agree.
>> If you ask for reducing the number of SPIs in core and perhaps move a more
>> complex environment singleton implementation out to somewhere else, I would
>> agree.
>> Theoretically we could even move the Environment part into a separate
>> module and simply let the Configuration part be the core part of the API...
>>
>> Just my few cents here.
>>
>> Cheers,
>> Anatole
>>
>>
>>
>> 2014-12-23 1:01 GMT+01:00 Oliver B. Fischer <o....@swe-blog.net>:
>>
>>> Hi all, I think we need this discussion. Let me list my points:
>>>
>>> 1. Yes, Tamaya is to complex at the moment.
>>> 2. It seems to be to complex.
>>> 3. We do not finish discussions on the list and start to early to
>>> implement things.
>>>
>>> How can we change this?
>>>
>>> 1. Let us write down a list of use cases we would like to support.
>>> 2. Let us discuss how to support these use cases.
>>>
>>> Without this approach we will have the same discussions again and again.
>>>
>>> Second we should try to keep the API as elegant and minimal as possible
>>> for simple use cases. Tamaya should also be possible go handle complex
>> use
>>> cases.
>>>
>>> May we shouldn't have started with an existing code base.
>>>
>>> Best,
>>>
>>> Oliver
>>>
>>>
>>> Von meinem iPhone gesendet
>>>
>>>> Am 22.12.2014 um 17:36 schrieb Mark Struberg <st...@yahoo.de>:
>>>>
>>>> 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
>>
>>
>>
>> --
>> *Anatole Tresch*
>> Java Engineer & Architect, JSR Spec Lead
>> Glärnischweg 10
>> CH - 8620 Wetzikon
>>
>> *Switzerland, Europe Zurich, GMT+1*
>> *Twitter: @atsticks*
>> *Blogs: **http://javaremarkables.blogspot.ch/
>> <http://javaremarkables.blogspot.ch/>*
>>
>> *Google: atsticksMobile +41-76 344 62 79*
>>
Re: [DISCUSS] increasing complexity of Tamaya
Posted by Romain Manni-Bucau <rm...@gmail.com>.
Hi
Yeah Environment is surely optional in practise.
Wonder if we didnt think in the wrong way. I mean if you start from an IoC
usages then API is always smarter than from SE case. Then aligning SE on
IoC is quite easier than the opposite.
For IoC side the DeltaSpike API is great. What do we miss then? Mainly 3
things not working out of the box: distributed configs - we can start as
easy as reading a database but i would like to be able to rely on local
files and move this distributed logic in a separate module reading a
database or anything else to push files on disk to avoid issues if the db
is down, write part of the config ie how do I update it - it include crud
api but also a GUI - and listeners/update events.
In terms of API it is quite easy and all the power would come from the impl
IMO.
Le 23 déc. 2014 01:56, "Anatole Tresch" <at...@gmail.com> a écrit :
> ... and BTW, what a meant with the "guts feeling": I would like to see
> concrete proposals: just say what you want to change IN CODE, or at least
> more precisely. Just saying it is too complex is IMO not very constructive.
> Also it is more concrete for everybody here on the list.
>
> Some examples:
> If you would ask me e.g. to replace the ConfigManager and
> EnvironmentManager in API by simply accessing the ServiceContext from the
> facade artifacts, I would agree.
> If you ask for reducing the number of SPIs in core and perhaps move a more
> complex environment singleton implementation out to somewhere else, I would
> agree.
> Theoretically we could even move the Environment part into a separate
> module and simply let the Configuration part be the core part of the API...
>
> Just my few cents here.
>
> Cheers,
> Anatole
>
>
>
> 2014-12-23 1:01 GMT+01:00 Oliver B. Fischer <o....@swe-blog.net>:
>
> > Hi all, I think we need this discussion. Let me list my points:
> >
> > 1. Yes, Tamaya is to complex at the moment.
> > 2. It seems to be to complex.
> > 3. We do not finish discussions on the list and start to early to
> > implement things.
> >
> > How can we change this?
> >
> > 1. Let us write down a list of use cases we would like to support.
> > 2. Let us discuss how to support these use cases.
> >
> > Without this approach we will have the same discussions again and again.
> >
> > Second we should try to keep the API as elegant and minimal as possible
> > for simple use cases. Tamaya should also be possible go handle complex
> use
> > cases.
> >
> > May we shouldn't have started with an existing code base.
> >
> > Best,
> >
> > Oliver
> >
> >
> > Von meinem iPhone gesendet
> >
> > > Am 22.12.2014 um 17:36 schrieb Mark Struberg <st...@yahoo.de>:
> > >
> > > 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
> >
>
>
>
> --
> *Anatole Tresch*
> Java Engineer & Architect, JSR Spec Lead
> Glärnischweg 10
> CH - 8620 Wetzikon
>
> *Switzerland, Europe Zurich, GMT+1*
> *Twitter: @atsticks*
> *Blogs: **http://javaremarkables.blogspot.ch/
> <http://javaremarkables.blogspot.ch/>*
>
> *Google: atsticksMobile +41-76 344 62 79*
>
Re: [DISCUSS] increasing complexity of Tamaya
Posted by Anatole Tresch <at...@gmail.com>.
... and BTW, what a meant with the "guts feeling": I would like to see
concrete proposals: just say what you want to change IN CODE, or at least
more precisely. Just saying it is too complex is IMO not very constructive.
Also it is more concrete for everybody here on the list.
Some examples:
If you would ask me e.g. to replace the ConfigManager and
EnvironmentManager in API by simply accessing the ServiceContext from the
facade artifacts, I would agree.
If you ask for reducing the number of SPIs in core and perhaps move a more
complex environment singleton implementation out to somewhere else, I would
agree.
Theoretically we could even move the Environment part into a separate
module and simply let the Configuration part be the core part of the API...
Just my few cents here.
Cheers,
Anatole
2014-12-23 1:01 GMT+01:00 Oliver B. Fischer <o....@swe-blog.net>:
> Hi all, I think we need this discussion. Let me list my points:
>
> 1. Yes, Tamaya is to complex at the moment.
> 2. It seems to be to complex.
> 3. We do not finish discussions on the list and start to early to
> implement things.
>
> How can we change this?
>
> 1. Let us write down a list of use cases we would like to support.
> 2. Let us discuss how to support these use cases.
>
> Without this approach we will have the same discussions again and again.
>
> Second we should try to keep the API as elegant and minimal as possible
> for simple use cases. Tamaya should also be possible go handle complex use
> cases.
>
> May we shouldn't have started with an existing code base.
>
> Best,
>
> Oliver
>
>
> Von meinem iPhone gesendet
>
> > Am 22.12.2014 um 17:36 schrieb Mark Struberg <st...@yahoo.de>:
> >
> > 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
>
--
*Anatole Tresch*
Java Engineer & Architect, JSR Spec Lead
Glärnischweg 10
CH - 8620 Wetzikon
*Switzerland, Europe Zurich, GMT+1*
*Twitter: @atsticks*
*Blogs: **http://javaremarkables.blogspot.ch/
<http://javaremarkables.blogspot.ch/>*
*Google: atsticksMobile +41-76 344 62 79*
Re: [DISCUSS] increasing complexity of Tamaya
Posted by "Oliver B. Fischer" <o....@swe-blog.net>.
Hi all, I think we need this discussion. Let me list my points:
1. Yes, Tamaya is to complex at the moment.
2. It seems to be to complex.
3. We do not finish discussions on the list and start to early to implement things.
How can we change this?
1. Let us write down a list of use cases we would like to support.
2. Let us discuss how to support these use cases.
Without this approach we will have the same discussions again and again.
Second we should try to keep the API as elegant and minimal as possible for simple use cases. Tamaya should also be possible go handle complex use cases.
May we shouldn't have started with an existing code base.
Best,
Oliver
Von meinem iPhone gesendet
> Am 22.12.2014 um 17:36 schrieb Mark Struberg <st...@yahoo.de>:
>
> 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
Re: [DISCUSS] increasing complexity of Tamaya
Posted by Werner Keil <we...@gmail.com>.
Mark/all,
Thanks for sharing your desire to keep things simple. That is certainly
good to keep in mind and try archive.
Not sure, if DeltaSpike Config aims at multi-purpose configuration as
opposed to say very limited subsystems like those by JSR 107 (yet it comes
with several layers of interfaces and classes and not much of it sounds so
intuitive or logical either)
While not covering any environment or staging concept, the recently
rewritten Apache Commons Config 2 consists of 228 class files (please
analyse its repo if you want to know hoe many LOC, etc.;-)
There are always extreme cases, e.g. JSR 310 the "new" Java Date/Time
library in Java SE 8 has more types than Tamaya (~150 I recall) and there's
an alternative called Date4J which has no more than 3 to 5 classes for
exactly the same purpose either.
Regards,
Werner
On Mon, Dec 22, 2014 at 5:36 PM, Mark Struberg <st...@yahoo.de> 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
>