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*
