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