You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tamaya.apache.org by Werner Keil <we...@gmail.com> on 2016/07/19 15:21:51 UTC
General types of config frameworks
Hi,
Starting another thread because the "Vote" that wasn't really an official
vote at this point has outlived itself.
Without going into details about what each of the underlying mechanisms
(DI, etc.) are there are two main categories of config solutions:
1. Annotated POJOS
That includes the likes of Spring Config, Cfg4J or DeltaSpike. None of
them has its own "Config" or "Configuration value holder. That's up to the
application. You may find examples calling it AppConfig or e.g. Agorava
uses DeltaSpike for OAuthAppSettings (backed by a simple properties file
right now)
2. Value holder
That includes Tamaya as of now, Typesafe Config or Apache Commons Config.
None of the Tamaya proposal stated which of the two directions it shall use.
The smaller the value holder gets, the more the question could arise what
remains its purpose.
I'm not suggesting either, just mention the two general directions.
Regards,
Werner
Re: General types of config frameworks
Posted by Werner Keil <we...@gmail.com>.
With "value holder" I was talking about even the most basic "Configuration"
or "Config" bean with getters.
Do you suggest that should be completely outside the API?
I'm not talking about the "ConfigProvider" or whatever *Provider, that
could be in an optional package or the SPI.
On Tue, Jul 19, 2016 at 6:19 PM, Anatole Tresch <at...@gmail.com> wrote:
> ;) As I said, if we try to also define the value provider we probably will
> fail as a future JSR...
> and we can still provide our proposal as an extension module. Even the code
> we have as of today is so modular that these aspects easily can be
> separated...
>
> 2016-07-19 18:08 GMT+02:00 Werner Keil <we...@gmail.com>:
>
> > This was mainly the question of whether or not the value holder (also
> > towards a possible standard) itself should be mandated by the API or not.
> >
> > Not what Tamaya can or could support or be backed by;-)
> >
> > Werner Keil | JCP Executive Committee Member, JSR 363 Co Spec Lead |
> > Eclipse UOMo Lead, Babel Language Champion | Apache Committer
> >
> > Twitter @wernerkeil | @UnitAPI | @JSR354 | @AgoravaProj | @DeviceMap
> > | #DevOps | #EclipseUOMo
> > Skype werner.keil | Google+ gplus.to/wernerkeil
> >
> >
> >
> > On Tue, Jul 19, 2016 at 6:04 PM, Anatole Tresch <at...@gmail.com>
> > wrote:
> >
> > > +1 not forking to much here.
> > >
> > > As of now we already have a common injection API for CDI, SE basewd
> > > injection, Sprring, OSGI services and an example based on SE injection
> > also
> > > seemlessly working with vertx.
> > > Given even the smallest low level API and some more extensions easily
> > > addable on top of it, we can implement a good and comfortable user
> > > (configuration) experience ;)
> > >
> > > But we must come to a point, where we all together push this project
> > > forward. If we are fighting each other our time here is useless. It
> would
> > > be simpler for me, building my own project on github ;)
> > > And looking what kind of discussions we have here, these discussions
> > > exactly reflect the main problem for a configuration standardization.
> > There
> > > is no common sense on how configuration should be built and organized.
> So
> > > the only chance to get it widely used is to simply omit this aspect and
> > > focus on a clean and resuable/extensible API. Given that we have
> already
> > > won a lot, since all the advantages of a common API are taken by us. If
> > we
> > > need another decade or two until we have a common sense on how
> > > configuration should be organized (I doubt we will even achieve that),
> > thia
> > > does not affect the realization of the advantages of a common API IMO
> ;)
> > >
> > >
> > >
> > >
> > > 2016-07-19 17:25 GMT+02:00 Romain Manni-Bucau <rm...@gmail.com>:
> > >
> > > > 3. proxy based configuration like owner
> > > >
> > > > Typically I think that in spring - to handle only this obvious case -
> > we
> > > > can just provide the loaded values and let spring handle the
> > > > coercion/injections.
> > > > It will make spring users in a known land but on stereoid since they
> > will
> > > > reuse Tamaya "company" backend which can be spread other all
> > > applications.
> > > >
> > > > that said what about fixing low level API before digging in how any
> > high
> > > > level API will use it?
> > > >
> > > >
> > > >
> > > > Romain Manni-Bucau
> > > > @rmannibucau <https://twitter.com/rmannibucau> | Blog
> > > > <https://blog-rmannibucau.rhcloud.com> | Old Wordpress Blog
> > > > <http://rmannibucau.wordpress.com> | Github <
> > > > https://github.com/rmannibucau> |
> > > > LinkedIn <https://www.linkedin.com/in/rmannibucau> | Tomitriber
> > > > <http://www.tomitribe.com> | JavaEE Factory
> > > > <https://javaeefactory-rmannibucau.rhcloud.com>
> > > >
> > > > 2016-07-19 17:21 GMT+02:00 Werner Keil <we...@gmail.com>:
> > > >
> > > > > Hi,
> > > > >
> > > > > Starting another thread because the "Vote" that wasn't really an
> > > official
> > > > > vote at this point has outlived itself.
> > > > >
> > > > > Without going into details about what each of the underlying
> > mechanisms
> > > > > (DI, etc.) are there are two main categories of config solutions:
> > > > >
> > > > > 1. Annotated POJOS
> > > > > That includes the likes of Spring Config, Cfg4J or DeltaSpike.
> > None
> > > of
> > > > > them has its own "Config" or "Configuration value holder. That's
> > up
> > > to
> > > > > the
> > > > > application. You may find examples calling it AppConfig or e.g.
> > > > Agorava
> > > > > uses DeltaSpike for OAuthAppSettings (backed by a simple
> > properties
> > > > file
> > > > > right now)
> > > > > 2. Value holder
> > > > > That includes Tamaya as of now, Typesafe Config or Apache
> Commons
> > > > > Config.
> > > > >
> > > > > None of the Tamaya proposal stated which of the two directions it
> > shall
> > > > > use.
> > > > > The smaller the value holder gets, the more the question could
> arise
> > > what
> > > > > remains its purpose.
> > > > > I'm not suggesting either, just mention the two general directions.
> > > > >
> > > > > Regards,
> > > > >
> > > > > Werner
> > > > >
> > > >
> > >
> > >
> > >
> > > --
> > > *Anatole Tresch*
> > > PPMC Member Apache Tamaya
> > > JCP Star Spec Lead
> > > *Switzerland, Europe Zurich, GMT+1*
> > > *maketechsimple.wordpress.com <http://maketechsimple.wordpress.com/> *
> > > *Twitter: @atsticks, @tamayaconf*
> > >
> >
>
>
>
> --
> *Anatole Tresch*
> PPMC Member Apache Tamaya
> JCP Star Spec Lead
> *Switzerland, Europe Zurich, GMT+1*
> *maketechsimple.wordpress.com <http://maketechsimple.wordpress.com/> *
> *Twitter: @atsticks, @tamayaconf*
>
Re: General types of config frameworks
Posted by Anatole Tresch <at...@gmail.com>.
;) As I said, if we try to also define the value provider we probably will
fail as a future JSR...
and we can still provide our proposal as an extension module. Even the code
we have as of today is so modular that these aspects easily can be
separated...
2016-07-19 18:08 GMT+02:00 Werner Keil <we...@gmail.com>:
> This was mainly the question of whether or not the value holder (also
> towards a possible standard) itself should be mandated by the API or not.
>
> Not what Tamaya can or could support or be backed by;-)
>
> Werner Keil | JCP Executive Committee Member, JSR 363 Co Spec Lead |
> Eclipse UOMo Lead, Babel Language Champion | Apache Committer
>
> Twitter @wernerkeil | @UnitAPI | @JSR354 | @AgoravaProj | @DeviceMap
> | #DevOps | #EclipseUOMo
> Skype werner.keil | Google+ gplus.to/wernerkeil
>
>
>
> On Tue, Jul 19, 2016 at 6:04 PM, Anatole Tresch <at...@gmail.com>
> wrote:
>
> > +1 not forking to much here.
> >
> > As of now we already have a common injection API for CDI, SE basewd
> > injection, Sprring, OSGI services and an example based on SE injection
> also
> > seemlessly working with vertx.
> > Given even the smallest low level API and some more extensions easily
> > addable on top of it, we can implement a good and comfortable user
> > (configuration) experience ;)
> >
> > But we must come to a point, where we all together push this project
> > forward. If we are fighting each other our time here is useless. It would
> > be simpler for me, building my own project on github ;)
> > And looking what kind of discussions we have here, these discussions
> > exactly reflect the main problem for a configuration standardization.
> There
> > is no common sense on how configuration should be built and organized. So
> > the only chance to get it widely used is to simply omit this aspect and
> > focus on a clean and resuable/extensible API. Given that we have already
> > won a lot, since all the advantages of a common API are taken by us. If
> we
> > need another decade or two until we have a common sense on how
> > configuration should be organized (I doubt we will even achieve that),
> thia
> > does not affect the realization of the advantages of a common API IMO ;)
> >
> >
> >
> >
> > 2016-07-19 17:25 GMT+02:00 Romain Manni-Bucau <rm...@gmail.com>:
> >
> > > 3. proxy based configuration like owner
> > >
> > > Typically I think that in spring - to handle only this obvious case -
> we
> > > can just provide the loaded values and let spring handle the
> > > coercion/injections.
> > > It will make spring users in a known land but on stereoid since they
> will
> > > reuse Tamaya "company" backend which can be spread other all
> > applications.
> > >
> > > that said what about fixing low level API before digging in how any
> high
> > > level API will use it?
> > >
> > >
> > >
> > > Romain Manni-Bucau
> > > @rmannibucau <https://twitter.com/rmannibucau> | Blog
> > > <https://blog-rmannibucau.rhcloud.com> | Old Wordpress Blog
> > > <http://rmannibucau.wordpress.com> | Github <
> > > https://github.com/rmannibucau> |
> > > LinkedIn <https://www.linkedin.com/in/rmannibucau> | Tomitriber
> > > <http://www.tomitribe.com> | JavaEE Factory
> > > <https://javaeefactory-rmannibucau.rhcloud.com>
> > >
> > > 2016-07-19 17:21 GMT+02:00 Werner Keil <we...@gmail.com>:
> > >
> > > > Hi,
> > > >
> > > > Starting another thread because the "Vote" that wasn't really an
> > official
> > > > vote at this point has outlived itself.
> > > >
> > > > Without going into details about what each of the underlying
> mechanisms
> > > > (DI, etc.) are there are two main categories of config solutions:
> > > >
> > > > 1. Annotated POJOS
> > > > That includes the likes of Spring Config, Cfg4J or DeltaSpike.
> None
> > of
> > > > them has its own "Config" or "Configuration value holder. That's
> up
> > to
> > > > the
> > > > application. You may find examples calling it AppConfig or e.g.
> > > Agorava
> > > > uses DeltaSpike for OAuthAppSettings (backed by a simple
> properties
> > > file
> > > > right now)
> > > > 2. Value holder
> > > > That includes Tamaya as of now, Typesafe Config or Apache Commons
> > > > Config.
> > > >
> > > > None of the Tamaya proposal stated which of the two directions it
> shall
> > > > use.
> > > > The smaller the value holder gets, the more the question could arise
> > what
> > > > remains its purpose.
> > > > I'm not suggesting either, just mention the two general directions.
> > > >
> > > > Regards,
> > > >
> > > > Werner
> > > >
> > >
> >
> >
> >
> > --
> > *Anatole Tresch*
> > PPMC Member Apache Tamaya
> > JCP Star Spec Lead
> > *Switzerland, Europe Zurich, GMT+1*
> > *maketechsimple.wordpress.com <http://maketechsimple.wordpress.com/> *
> > *Twitter: @atsticks, @tamayaconf*
> >
>
--
*Anatole Tresch*
PPMC Member Apache Tamaya
JCP Star Spec Lead
*Switzerland, Europe Zurich, GMT+1*
*maketechsimple.wordpress.com <http://maketechsimple.wordpress.com/> *
*Twitter: @atsticks, @tamayaconf*
Re: General types of config frameworks
Posted by Werner Keil <we...@gmail.com>.
This was mainly the question of whether or not the value holder (also
towards a possible standard) itself should be mandated by the API or not.
Not what Tamaya can or could support or be backed by;-)
Werner Keil | JCP Executive Committee Member, JSR 363 Co Spec Lead |
Eclipse UOMo Lead, Babel Language Champion | Apache Committer
Twitter @wernerkeil | @UnitAPI | @JSR354 | @AgoravaProj | @DeviceMap
| #DevOps | #EclipseUOMo
Skype werner.keil | Google+ gplus.to/wernerkeil
On Tue, Jul 19, 2016 at 6:04 PM, Anatole Tresch <at...@gmail.com> wrote:
> +1 not forking to much here.
>
> As of now we already have a common injection API for CDI, SE basewd
> injection, Sprring, OSGI services and an example based on SE injection also
> seemlessly working with vertx.
> Given even the smallest low level API and some more extensions easily
> addable on top of it, we can implement a good and comfortable user
> (configuration) experience ;)
>
> But we must come to a point, where we all together push this project
> forward. If we are fighting each other our time here is useless. It would
> be simpler for me, building my own project on github ;)
> And looking what kind of discussions we have here, these discussions
> exactly reflect the main problem for a configuration standardization. There
> is no common sense on how configuration should be built and organized. So
> the only chance to get it widely used is to simply omit this aspect and
> focus on a clean and resuable/extensible API. Given that we have already
> won a lot, since all the advantages of a common API are taken by us. If we
> need another decade or two until we have a common sense on how
> configuration should be organized (I doubt we will even achieve that), thia
> does not affect the realization of the advantages of a common API IMO ;)
>
>
>
>
> 2016-07-19 17:25 GMT+02:00 Romain Manni-Bucau <rm...@gmail.com>:
>
> > 3. proxy based configuration like owner
> >
> > Typically I think that in spring - to handle only this obvious case - we
> > can just provide the loaded values and let spring handle the
> > coercion/injections.
> > It will make spring users in a known land but on stereoid since they will
> > reuse Tamaya "company" backend which can be spread other all
> applications.
> >
> > that said what about fixing low level API before digging in how any high
> > level API will use it?
> >
> >
> >
> > Romain Manni-Bucau
> > @rmannibucau <https://twitter.com/rmannibucau> | Blog
> > <https://blog-rmannibucau.rhcloud.com> | Old Wordpress Blog
> > <http://rmannibucau.wordpress.com> | Github <
> > https://github.com/rmannibucau> |
> > LinkedIn <https://www.linkedin.com/in/rmannibucau> | Tomitriber
> > <http://www.tomitribe.com> | JavaEE Factory
> > <https://javaeefactory-rmannibucau.rhcloud.com>
> >
> > 2016-07-19 17:21 GMT+02:00 Werner Keil <we...@gmail.com>:
> >
> > > Hi,
> > >
> > > Starting another thread because the "Vote" that wasn't really an
> official
> > > vote at this point has outlived itself.
> > >
> > > Without going into details about what each of the underlying mechanisms
> > > (DI, etc.) are there are two main categories of config solutions:
> > >
> > > 1. Annotated POJOS
> > > That includes the likes of Spring Config, Cfg4J or DeltaSpike. None
> of
> > > them has its own "Config" or "Configuration value holder. That's up
> to
> > > the
> > > application. You may find examples calling it AppConfig or e.g.
> > Agorava
> > > uses DeltaSpike for OAuthAppSettings (backed by a simple properties
> > file
> > > right now)
> > > 2. Value holder
> > > That includes Tamaya as of now, Typesafe Config or Apache Commons
> > > Config.
> > >
> > > None of the Tamaya proposal stated which of the two directions it shall
> > > use.
> > > The smaller the value holder gets, the more the question could arise
> what
> > > remains its purpose.
> > > I'm not suggesting either, just mention the two general directions.
> > >
> > > Regards,
> > >
> > > Werner
> > >
> >
>
>
>
> --
> *Anatole Tresch*
> PPMC Member Apache Tamaya
> JCP Star Spec Lead
> *Switzerland, Europe Zurich, GMT+1*
> *maketechsimple.wordpress.com <http://maketechsimple.wordpress.com/> *
> *Twitter: @atsticks, @tamayaconf*
>
Re: General types of config frameworks
Posted by Anatole Tresch <at...@gmail.com>.
+1 not forking to much here.
As of now we already have a common injection API for CDI, SE basewd
injection, Sprring, OSGI services and an example based on SE injection also
seemlessly working with vertx.
Given even the smallest low level API and some more extensions easily
addable on top of it, we can implement a good and comfortable user
(configuration) experience ;)
But we must come to a point, where we all together push this project
forward. If we are fighting each other our time here is useless. It would
be simpler for me, building my own project on github ;)
And looking what kind of discussions we have here, these discussions
exactly reflect the main problem for a configuration standardization. There
is no common sense on how configuration should be built and organized. So
the only chance to get it widely used is to simply omit this aspect and
focus on a clean and resuable/extensible API. Given that we have already
won a lot, since all the advantages of a common API are taken by us. If we
need another decade or two until we have a common sense on how
configuration should be organized (I doubt we will even achieve that), thia
does not affect the realization of the advantages of a common API IMO ;)
2016-07-19 17:25 GMT+02:00 Romain Manni-Bucau <rm...@gmail.com>:
> 3. proxy based configuration like owner
>
> Typically I think that in spring - to handle only this obvious case - we
> can just provide the loaded values and let spring handle the
> coercion/injections.
> It will make spring users in a known land but on stereoid since they will
> reuse Tamaya "company" backend which can be spread other all applications.
>
> that said what about fixing low level API before digging in how any high
> level API will use it?
>
>
>
> Romain Manni-Bucau
> @rmannibucau <https://twitter.com/rmannibucau> | Blog
> <https://blog-rmannibucau.rhcloud.com> | Old Wordpress Blog
> <http://rmannibucau.wordpress.com> | Github <
> https://github.com/rmannibucau> |
> LinkedIn <https://www.linkedin.com/in/rmannibucau> | Tomitriber
> <http://www.tomitribe.com> | JavaEE Factory
> <https://javaeefactory-rmannibucau.rhcloud.com>
>
> 2016-07-19 17:21 GMT+02:00 Werner Keil <we...@gmail.com>:
>
> > Hi,
> >
> > Starting another thread because the "Vote" that wasn't really an official
> > vote at this point has outlived itself.
> >
> > Without going into details about what each of the underlying mechanisms
> > (DI, etc.) are there are two main categories of config solutions:
> >
> > 1. Annotated POJOS
> > That includes the likes of Spring Config, Cfg4J or DeltaSpike. None of
> > them has its own "Config" or "Configuration value holder. That's up to
> > the
> > application. You may find examples calling it AppConfig or e.g.
> Agorava
> > uses DeltaSpike for OAuthAppSettings (backed by a simple properties
> file
> > right now)
> > 2. Value holder
> > That includes Tamaya as of now, Typesafe Config or Apache Commons
> > Config.
> >
> > None of the Tamaya proposal stated which of the two directions it shall
> > use.
> > The smaller the value holder gets, the more the question could arise what
> > remains its purpose.
> > I'm not suggesting either, just mention the two general directions.
> >
> > Regards,
> >
> > Werner
> >
>
--
*Anatole Tresch*
PPMC Member Apache Tamaya
JCP Star Spec Lead
*Switzerland, Europe Zurich, GMT+1*
*maketechsimple.wordpress.com <http://maketechsimple.wordpress.com/> *
*Twitter: @atsticks, @tamayaconf*
Re: General types of config frameworks
Posted by Romain Manni-Bucau <rm...@gmail.com>.
3. proxy based configuration like owner
Typically I think that in spring - to handle only this obvious case - we
can just provide the loaded values and let spring handle the
coercion/injections.
It will make spring users in a known land but on stereoid since they will
reuse Tamaya "company" backend which can be spread other all applications.
that said what about fixing low level API before digging in how any high
level API will use it?
Romain Manni-Bucau
@rmannibucau <https://twitter.com/rmannibucau> | Blog
<https://blog-rmannibucau.rhcloud.com> | Old Wordpress Blog
<http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> |
LinkedIn <https://www.linkedin.com/in/rmannibucau> | Tomitriber
<http://www.tomitribe.com> | JavaEE Factory
<https://javaeefactory-rmannibucau.rhcloud.com>
2016-07-19 17:21 GMT+02:00 Werner Keil <we...@gmail.com>:
> Hi,
>
> Starting another thread because the "Vote" that wasn't really an official
> vote at this point has outlived itself.
>
> Without going into details about what each of the underlying mechanisms
> (DI, etc.) are there are two main categories of config solutions:
>
> 1. Annotated POJOS
> That includes the likes of Spring Config, Cfg4J or DeltaSpike. None of
> them has its own "Config" or "Configuration value holder. That's up to
> the
> application. You may find examples calling it AppConfig or e.g. Agorava
> uses DeltaSpike for OAuthAppSettings (backed by a simple properties file
> right now)
> 2. Value holder
> That includes Tamaya as of now, Typesafe Config or Apache Commons
> Config.
>
> None of the Tamaya proposal stated which of the two directions it shall
> use.
> The smaller the value holder gets, the more the question could arise what
> remains its purpose.
> I'm not suggesting either, just mention the two general directions.
>
> Regards,
>
> Werner
>