Bean Validation yet again (like JCache) has its own Configuration element, actually even 2 of them;-)
One (Configuration) quite user and app facing, the other (BootstrapConfiguration) more hidden behind the scene. There are many interfaces on the top level so maybe JCache could be easier: http://ignite.apache.org/jcache/1.0.0/javadoc/index.html?javax/cache/package-summary.html The top level contains only one vital element Cache. Beside CacheManager a general CacheException and a static accessor facade Caching. (for an API that's always a question if you need to add it or leave to implementations) CachingProvider is the only SPI element. Also in Bean Validation btw. a ValidationProvider is found in the SPI package. On Tue, Jul 19, 2016 at 5:10 PM, Romain Manni-Bucau <[email protected]> wrote: > no to reuse the API design of bean validation adapted to loading > abstraction of tamaya: > > quoting myself: > > """ > Ok for ConfigException, ConfigProvider with some rework (see end of the > mail) is ok however I think that: > > - Configuration (as a core API) shouldn't get more than get(String). The > "or default" is sugar we'll add on top of that anyway and getProperties() > implies you can list all entries which can not be possible so I wouldn't do > it in the main core part (DS did it for historical reasons and I think > today it is not the best it could have done) > - I tend to think Filter and Source can be part of the core cause otherwise > you have an entry supplier without any way to provide values. > > > Then about provider: what about just applying bean validation model blindy > first (provider to load a factory to create through a builder API or > through default loading mecanism an instance - of Configuration for us)? I > don't think we can get rid of the provider layer cause it will likely use > ServiceLoader - even in OSGi since it will be part of the impl so fine - > and the provider will then use what is adapted to its env to load other SPI > like sources/filters. > > So it would make a core of (feel free to change name): > > - Configuration { > String get(String); > static Configuration buildDefaultConfiguration() { > > byProvider(...loadDefault()...).withSources(...loadDefaults()...).withDeciphers(...loadDefaults()...).build(); > } > static BootConfig byProvider(String); > } > - ConfigurationProvider { > Configuration build(BootConfig) > } > - BootConfig { > withSources(sources...); > withDeciphers(filters...); > Configuration build(); > } > - ConfigurationSource { String get(String); String name(); } // but don't > impl Configuration for future > - ConfigurationDecipher { String decipher(String); String name(); } > """ > > provider is where impl will do their stuff, Configuration will be the user > (consumer) facing API, source/decipher will be the user (provider) facing > API. I'm happy to move the 2 static methods from configuration to > ConfigurationFactory if you prefer (don't care much there). > > wdyt? > > > > 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-19 17:07 GMT+02:00 Werner Keil <[email protected]>: > > > Do you suggest to use Bean Validation for Tamaya? > > > > Werner > > > > > > > > On Tue, Jul 19, 2016 at 5:04 PM, Romain Manni-Bucau < > [email protected] > > > > > wrote: > > > > > Guys, > > > > > > Can we stop there and can you review the proposal based on bval? > > > > > > Negative answers should say why and propose an alternative. > > > > > > This thread starts to be long and not sure we ll see the end if we dont > > > focus on small steps. > > > > > > Thanks > > > > > > Le 19 juil. 2016 16:58, "Mark Struberg" <[email protected]> a > > > écrit : > > > > > > > > Typesafe (I don't suggest you took it from there, just applied > > similar > > > > > code;-) > > > > > > > > That ConfigValue<T> is taken from TypedResolver<T> from DeltaSpike. > > > Mostly > > > > written by Ron Smeral and Gerhard. > > > > > > > > > Btw. it's not even remotely Java ME 8 compliant, but let's not > > > > > bother discussing it here any more. > > > > > > > > > > > > Target is Java SE and EE, not ME. > > > > ME is dead as Elvis, let’s face it ;) > > > > > > > > LieGrue, > > > > strub > > > > > > > > > > > > > Am 19.07.2016 um 16:40 schrieb Werner Keil <[email protected] > >: > > > > > > > > > > On the top-most API level you'll clearly find some common elements, > > > > > regardless of each solution's limitations. > > > > > > > > > > NetFlix more or less seems to compensate some when it comes to > > > > > Commons-configuration. > > > > > Your "probe" in the impl class showed a few similarities with > > > ConfigImpl > > > > by > > > > > Typesafe (I don't suggest you took it from there, just applied > > similar > > > > > code;-) Btw. it's not even remotely Java ME 8 compliant, but let's > > not > > > > > bother discussing it here any more. > > > > > > > > > > Cheers, > > > > > Werner > > > > > > > > > > > > > > > On Tue, Jul 19, 2016 at 4:34 PM, Mark Struberg > > > <[email protected] > > > > > > > > > > wrote: > > > > > > > > > >> I’ll try to explain this once again. Though this has already > > > extensively > > > > >> been covered even in the initial incubator proposal ;) > > > > >> > > > > >> Commons-configuration and DeltaSpike Config / Tamaya do _not_ > > overlap! > > > > >> > > > > >> * commons-configuration is a collection of tools to read and write > > > > various > > > > >> configuration formats from Java. > > > > >> * Tamaya aggregates a freely extensible list of such configuration > > > > sources > > > > >> in a well specified (ordered) way to a single uniform solution > > > suitable > > > > for > > > > >> consumption by the user. > > > > >> > > > > >> To make it clear: Tamaya is the end-user facing API + the > > integration > > > > SPI. > > > > >> commons-configuration could be used in custom ConfigSources to > > > leverage > > > > >> various configuration formats. > > > > >> > > > > >> Regarding ‚enhanced Properties‘. That is actually not that far > away > > > from > > > > >> what it is! > > > > >> The difference is that a ConfigSource has a name (for > > > > debugging/analysis) > > > > >> and most important: an ordinal number for sorting. > > > > >> And the ‚Configuration‘ interface is basically a way to merge n of > > > those > > > > >> Properties together. > > > > >> > > > > >> Is this part clear now? > > > > >> > > > > >> If so, let’s please come back to Anatoles proposal and my > question: > > > > >> If we only have a user facing API but no SPI, how would someone > > plugin > > > > >> e.g. his default-config into the application? > > > > >> > > > > >> LieGrue, > > > > >> strub > > > > >> > > > > >> > > > > >>> Am 19.07.2016 um 15:52 schrieb Werner Keil < > [email protected] > > >: > > > > >>> > > > > >>> Unless configuration ends with String jsonBlob = config.get(JSON) > > or > > > > >>> xmlBlob = config.get(XML) etc. (could be YAML, too, leaving > > > everything > > > > up > > > > >>> to users of course) the majority of solutions offer a somewhat > > > flexible > > > > >>> type-system at least within what the JDK has to offer (if nothing > > > else > > > > >> then > > > > >>> at least Number and its subtypes) > > > > >>> > > > > >>> Even the specialized JCache config subsystem returns more than > just > > > > >> strings > > > > >>> and I would not say it's a very good example either. > > > > >>> > > > > >>> However, if a "tamaya-minimal-api" defined some Configuration > type > > > and > > > > as > > > > >>> Anatole also hinted you extend that in a "tamaya-typesafe-api" > > where > > > a > > > > >>> TypeSafeConfiguration (names only as examples) offers a more > > > flexible T > > > > >>> get(String) or similar, nothing is lost. The minimalistic use > cases > > > can > > > > >> use > > > > >>> the tiny JAR in ME there could be use for that at least and other > > > > >>> downstream apps and solutions have the choice at which level they > > use > > > > the > > > > >>> API. > > > > >>> > > > > >>> Sounds fine to me. > > > > >>> > > > > >>> In any case until Tamaya is used at least by a small fraction of > > > > today's > > > > >>> users of Apache Commons Config (mostly 1, around 4k other apps > and > > > > >>> projects, only 22 so far switched to V2) it's likely too soon to > > > > consider > > > > >>> any standardization based on it. > > > > >>> > > > > >>> > > > > >>> On Tue, Jul 19, 2016 at 3:30 PM, Romain Manni-Bucau < > > > > >> [email protected]> > > > > >>> wrote: > > > > >>> > > > > >>>> 2016-07-19 15:22 GMT+02:00 Werner Keil <[email protected]>: > > > > >>>> > > > > >>>>> Well the question is and remains who needs a Properties reboot > > and > > > > how > > > > >>>> are > > > > >>>>> applications supposed to use it? > > > > >>>>> > > > > >>>>> > > > > >>>> You don't get our need I think: it is more about the composition > > > than > > > > >> how > > > > >>>> it is stored. > > > > >>>> > > > > >>>> > > > > >>>>> Other than commons config or Spring there are no real > production > > > > usages > > > > >>>> out > > > > >>>>> there at the moment. > > > > >>>>> > > > > >>>>> > > > > >>>> Guess the 10* of config solution will thanks you for that. There > > > are a > > > > >> lot > > > > >>>> of alternatives and what I'd want we target is the one where the > > > > >> storage is > > > > >>>> an implementation detail but enabling the loading of any format. > > > > >>>> > > > > >>>> Then I think you focus on how to use it which is not the central > > > point > > > > >> of > > > > >>>> the proposal done by DS and CODI. This is often then delegated > to > > > the > > > > >>>> englobing framework and in tamaya it will be in extensions for > now > > > > >> until we > > > > >>>> got enough adoption to understand what is the righ cursor IMHO. > > > > >>>> > > > > >>>> > > > > >>>>> > > > > >>>>> > > > > >>>>> On Tue, Jul 19, 2016 at 3:09 PM, Mark Struberg > > > > >> <[email protected] > > > > >>>>> > > > > >>>>> wrote: > > > > >>>>> > > > > >>>>>>> In DS Configuration is just a tagging interface, but has no > > > method > > > > >>>>>>> signature. > > > > >>>>>> > > > > >>>>>> Did you even bother to read the JavaDoc? > > > > >>>>>> > > > > >>>>>> > > > > >>>>> > > > > >>>> > > > > >> > > > > > > > > > > https://github.com/apache/deltaspike/blob/master/deltaspike/core/api/src/main/java/org/apache/deltaspike/core/api/config/DeltaSpikeConfig.java#L33 > > > > >>>>>> > > > > >>>>>> This has absolutely nothing to do with the ConfigResolver + > > > > >>>> ConfigSource > > > > >>>>>> approach: > > > > >>>>>> > > > > >>>>>> > > > > >>>>> > > > > >>>> > > > > >> > > > > > > > > > > https://github.com/apache/deltaspike/blob/master/deltaspike/core/api/src/main/java/org/apache/deltaspike/core/api/config/ConfigResolver.java > > > > >>>>>> > > > > >>>>>> > > > > >>>>> > > > > >>>> > > > > >> > > > > > > > > > > https://github.com/apache/deltaspike/blob/master/deltaspike/core/api/src/main/java/org/apache/deltaspike/core/spi/config/ConfigSource.java > > > > >>>>>> > > > > >>>>>> Would you PLEASE finally stop sidetracking and get back to the > > > > >> original > > > > >>>>>> questions? > > > > >>>>>> > > > > >>>>>> txs and LieGrue, > > > > >>>>>> strub > > > > >>>>>> > > > > >>>>>> > > > > >>>>> > > > > >>>> > > > > >> > > > > >> > > > > > > > > > > > > > >
