sounds great Anatole, don't hesitate to ping me if I miss one of these topic, would be happy to participate to these dicussions
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 14:42 GMT+02:00 Anatole Tresch <[email protected]>: > 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* >
