Hi Romain/all sounds good. I started already shortly a branch and removed much things:
https://github.com/apache/incubator-tamaya/tree/tamaya-next/code/api/src/main/java/org/apache/tamaya The point about resolution is not yet done. I would suggest focusing our discussions first on the Configuration class: 1) Do we want to support non String values, including type literals? 2) Do we want to support mutability? OOTB as part of the Configuration interface, or indirectly, e.g. by applying some kind of Adapter pattern? 3) Anything else? I will have time to help again with the implementation. I think Phil and Oliver are also motivated, if we we see a good chance to progress with our initiative... ;) So would be great if the other guys could at least join discussions here on the list and actively help directing us to do the right things... J Anatole 2016-07-15 14:09 GMT+02:00 Romain Manni-Bucau <[email protected]>: > 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* > > > -- *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*
