To be concrete it means: 1. removing auto resolution from tamaya (and provide it through integration modules, cdi/spring/guice/OSGi...) 2. ensure the API is minimal (can be the case, didnt check since few months but last time it got considerations which were not relevant IMO cause of 1 mainly and impl details)
I sadly can't help much now but hope to be able to join the effort end of the year (if I don't shout my way, I'll do my best to make it possible ~october) One thing I'd love once the API will be reviewed is to provide a simple tomee-embedded-tamaya-server fatjar providing a REST application and a client "source" to fill the config entries. We would then have a fullstack solution ready to use. 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-15 13:02 GMT+02:00 Anatole Tresch <[email protected]>: > Not sure, if I get all (from a language perspective), but overall I think > we may be on the same page... > > 2016-07-15 12:33 GMT+02:00 Romain Manni-Bucau <[email protected]>: > > > 2016-07-15 12:06 GMT+02:00 Anatole Tresch <[email protected]>: > > > > > Yep ;). IMO we need > > > > > > - *ConfigurationProvider* (basically only for being compatible with > > Java > > > 7, with Java 8 we can use a static method on the *Configuration* > > > interface), which serves as an singleton access point for > > > *Configuration*. > > > > > > - We might further (re)discuss the feature set provided by > > > *Configuration* (interface). > > > - Finally the *Configuration* used actually must be resolved by some > > SPI > > > defined by the ConfigurationProvider. > > > > > > > > That's my main issue ATM, the resolution > > > > I'd see the config "solution/JSR" to provide a way to configure a > > Configuration instance (can be with annotation for CDI or whatever but > > finally it builds a Configuration) then let the framework you integrate > > with (CDI if we continue previous example) to contextualize it. > > > > What does it mean? > > > > - it will work with spring/guice/standalone/cdi/OSGi > > - you can configure multiple configurations > > - you never hit a "key" issue on the config side and delegates this > problem > > to the framework you work with which already solved it which will avoid > to > > mix resolution between frameworks > > > > > > > That's it. All the other stuff we have currently in the SPI could be > > moved > > > outside, e.g. to the builder module. This way we get a super simple > API, > > > just serving config and no more. We can delegate completely to whatever > > > backend we want to use, including externalizing everything to Consul > or a > > > simple properties file or whatever is appropriate. > > > > > > We can use ServiceLoader/@Priority for selecting the right > Configuration > > > instance, possibly overridable by a system property. > > > > > > We should also also shortly discuss on mutability of configuration. > > > > > > That would be what I think is minimal... (I guess depending on the > > outcome > > > we should have no more than 10 artifacts overall) is that a base for > > > discussion? I would then create a discussion branch and put together a > > > small proposal unless somebody else wants to do that. > > > > > > I think with such a small proposal we have a good chance to start > > > discussions also with the JCP ;) > > > > > > WDYT? > > > > > > J Anatole > > > > > > > > > > > > 2016-07-15 11:16 GMT+02:00 Mark Struberg <[email protected]>: > > > > > > > > > > > > Am 15.07.2016 um 09:31 schrieb Romain Manni-Bucau < > > > [email protected] > > > > >: > > > > > > > > > > @Anatole: think we communicated about the design choice we don't > like > > > in > > > > tamaya and answer was "you are alone" IIRC but let's try to review > some > > > of > > > > them now maybe > > > > > > > > > > > > > Well, actually it was you, Gerhard, Reinhard and me who wanted a much > > > > smaller and cleaner API. > > > > > > > > Probably a possibly solution would be to have a part which is > > explicitly > > > > devoted for a JSR candidate. Only the most important parts. API + RI > + > > > spec > > > > + TCK. > > > > > > > > And then there is another API which then adds all the icing on top of > > it? > > > > > > > > LieGrue, > > > > strub > > > > > > > > > > > > > > > -- > > > *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* >
