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 <[email protected]> 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 <[email protected]>:
>
> > 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 <[email protected]>:
> >
> > > 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*
>

Reply via email to