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* >
