If get(String) only returns a string, how do you imagine it should be used
by real apps.
Configuration config = ...
String minAsString = config.get("min.value");
int minValue = Integer.parseInt(minAsString);
String maxAsString = config.get("max.value");
int maxValue = Integer.parseInt(maxAsString);
...
If the rest is "sugar" as you say that boilerplate code is left to
Archaius, btw. using Apache Commons Config in production already on
https://github.com/Netflix/archaius has the top most feature
- Dynamic, Typed Properties
If the configuration was so crippled, then why not just scrap it along the
lines of
// Change this interface to whatever you want
public interface SampleConfig {
Integer birthYear();
List<String> friends();
URL homepage();
Map<String, Character> grades();
}
public static void main(String... args) {
ConfigurationSource source = new GitConfigurationSourceBuilder()
.withRepositoryURI("https://github.com/cfg4j/cfg4j-git-sample-config.git";)
.build();
ConfigurationProvider provider = new ConfigurationProviderBuilder()
.withConfigurationSource(source)
.build();
SampleConfig config = configurationProvider.bind("reksio",
SampleConfig.class);
// Use it!
System.out.println(config.homepage());
}
That pretty much goes along the Option Pattern also found in .NET
https://docs.asp.net/en/latest/fundamentals/configuration.html#options-config-objects
Btw. believe it or not, a lot of that is also under Apache 2 now coming
from Microsoft;-)
https://github.com/aspnet/Options
Werner
On Tue, Jul 19, 2016 at 1:57 PM, Mark Struberg <[email protected]>
wrote:
> Thanks Anatole, It’s a start.
>
> But this only covers the consumer part, or did I miss something?
> What about the SPI part?
>
> Do you think we can live without a way to declare where the configuration
> comes from?
> Would this be totally up to the container vendor?
> How to provide default configuration inside e.g. a jar?
>
> @Romain: yes, I also think get(String) is enough, rest is probably sugar.
> The getProperties() actually makes mostly sense on the ConfigSources (e.g.
> for an admin/control page) but probably not on the final Configuration
> instance.
>
> txs and LieGrue,
> strub
>
>
> > Am 19.07.2016 um 13:38 schrieb Romain Manni-Bucau <[email protected]
> >:
> >
> > 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(); }
> >
> >
> > 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 13:18 GMT+02:00 Werner Keil <[email protected]>:
> >
> >> Sounds like a plan.
> >>
> >> Not sure, if a "general" top level configuration type specialized for
> >> String allows extending it in another model without some restrictions,
> but
> >> if the java.util.Properties like get(String) is of minimalistic use,
> e.g.
> >> where it's backed by "good old Properties" anyway why not. Extending it
> it
> >> with a flexible type-system would still be possible.
> >>
> >> Supplier<String> sounds Java SE 8, so in an API that works both in Java
> SE
> >> 6/7 or Java ME 8 that cannot exist.
> >>
> >> If a type like ConfigurationProvider is optional, then it would be
> better
> >> to put it to another package. Makes building smaller modules easier
> IMHO,
> >> otherwise you probably have to use filtering and "Maven magic" to ensure
> >> only the mandatory or core types are packaged for a "minimal" profile or
> >> situation while everything is built for a "full" scope.
> >>
> >> Werner
> >>
> >>
> >>
> >> On Tue, Jul 19, 2016 at 12:39 PM, Anatole Tresch <[email protected]>
> >> wrote:
> >>
> >>> For me a point is that I would like to see the API being complete,
> >> meaning
> >>> all I need is the API to get a Configuration. Using Java 8 I don't need
> >> it,
> >>> so I can provide the ConfigurationProvider for Java 7 only.
> >> ConfigOperator
> >>> and -Query are only there for Java 7, they easily vould be removed from
> >> the
> >>> API as well.
> >>> But talking about minimal: a*lso the idea of organizing configuration
> as
> >>> property sources is already a design decision the API should not care
> >> about
> >>> IMO*. So being really minimal, we need:
> >>>
> >>> - Configuration (interface)
> >>> - ConfigException (exception)
> >>> - ConfigurationProvider (optional)
> >>>
> >>> The key here is Configuration. We agree IMO to provide *single* key
> >> access
> >>> for String values. IMO people also expect access to non-String values,
> >> but
> >>> this must not be part of the core Configuration interface since it
> could
> >>> easily be added as a facade functionality for example, so it can be
> >>> realized as an extension module!
> >>> Accessing a Map<String,String> of properties IMO, and also from user
> >>> feedback, is a wanted functionality. In most cases also the result can
> be
> >>> well calculated and further functionality added on top that most people
> >>> expect from a Configuration solution. This is also what we have done in
> >> the
> >>> current source tree (see tamaya-functions module).
> >>>
> >>> So my proposal would be:
> >>>
> >>> - reduce the API to these 3 artifacts (including ConfigProvider - it
> >>> doesnt hurt and makes migration from Java 7 to 8 much easier).
> >>> - Remove type support from Configuration, it can be added in a
> >> separate
> >>> module
> >>> , which is not too much change needed).
> >>> .
> >>> - discuss how the ConfigurationProvider loads the Configuration
> >>> instance to be returned (service loader, OSGI service).
> >>> - move all the rest of artifacts into separate modules. This also
> >>> includes the DS inspired parts of PropertySource handling currently
> in
> >>> the
> >>> core module.
> >>>
> >>>
> >>> People already using deltaspike can easily plugin in the DS logic
> without
> >>> having to rewrite anything and start using the new API. In CDI
> >>> Configuration can be determined from using the CDI context (os
> something
> >>> else in stages, where CDI is not yet loaded). Same story for Spring and
> >>> more.
> >>>
> >>> This is basically what I proposed in the* tamaya-next branch*: So our
> >>> complete core API fits into half a page!
> >>>
> >>> public interface Configuration {
> >>> String get(String key);
> >>> default String getOrDefault(String key, final String
> defaultValue){...}
> >>> default String getOrDefault(String key, Supplier<String>
> >>> defaultValueSupplier){...}
> >>> Map<String,String> getProperties();
> >>> }
> >>> public final class ConfigurationProvider {
> >>> [...]
> >>> Configuration getConfiguration(){
> >>> // tbd
> >>> }
> >>> }
> >>> public class ConfigException extends RuntimeException{
> >>> private static final long serialVersionUID = -5886094818057522680L;
> >>> public ConfigException(String message){
> >>> super(message);
> >>> }
> >>> public ConfigException(String message, Throwable t){
> >>> super(message, t);
> >>> }
> >>> }
> >>>
> >>> J Anatole
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>
> >>> 2016-07-19 9:08 GMT+02:00 Werner Keil <[email protected]>:
> >>>
> >>>> tamaya-api-0.2-incubating.jar is just 30 kb right now.
> >>>> While the exact set of methods is questionable in the "design study"
> >>> (just
> >>>> leave it as that and thanks to EC members like myself or Ben there's
> no
> >>>> further damage done by the way it was presented, we're not talking
> >> about
> >>>> JCP aspects here now ;-) a minimalistic approach may leave
> >> Configuration
> >>>> and ConfigException pretty much the only core elements. Not even sure
> >>> about
> >>>> the *Provider. As the name suggests it could be in an SPI, take JCache
> >>>> (where only its Caching static facade mixes the two and makes clean
> >>>> separation impossible, CacheProvider is in an SPI package though)
> >>>>
> >>>> *Operator and *Query feel a bit redundant and both can be seen as
> >>> optional.
> >>>> Especially for implementations based on Java 8 one could probably
> stick
> >>> to
> >>>> Function<Configuration, Configuration> or similar to accomplish that.
> >> If
> >>>> Tamaya needs a Java 7 compatibility layer (it'll take years before
> >>>> especially the Enterprise sector will fully adopt even Java SE and EE
> >> 7,
> >>> I
> >>>> work there all the time and see what's used;-) then it could be in a
> >>>> different package/jar, but doesn't have to be in a core API.
> >>>>
> >>>> Cheers,
> >>>> Werner
> >>>>
> >>>>
> >>>> On Tue, Jul 19, 2016 at 3:57 AM, Mark Struberg
> >> <[email protected]
> >>>>
> >>>> wrote:
> >>>>
> >>>>> Then see it as the smallest possible core. It has only 30 kByte
> >> (api+RI
> >>>>> jars).
> >>>>> It even works on ME or Android.
> >>>>>
> >>>>> LieGrue,
> >>>>> Strub
> >>>>>
> >>>>>> Am 19.07.2016 um 01:00 schrieb Werner Keil <[email protected]
> >>> :
> >>>>>>
> >>>>>> We're not talking about the API when it comes to Spring, OSGi or
> >> even
> >>>> CDI
> >>>>>> support. Same for say a YAML module, etc.
> >>>>>> Those are implementation specific.
> >>>>>>
> >>>>>> The more modular and fine-grained the API (of Tamaya) can get, the
> >>>>> better.
> >>>>>>
> >>>>>> CDI has to learn that with V2 only, but for relatively new JSRs or
> >>>> modern
> >>>>>> projects it should be considered right from the start.
> >>>>>> The most basic core API may or may not work even on Java ME
> >> Embedded.
> >>>>>> JSR 363, which has a core of only 4 mandatory core types plus 3
> >>>>> exceptions.
> >>>>>> If put in a separate JAR those would only take around 5k. Fits even
> >>> the
> >>>>>> smallest Java ME device out there. You may not always be able to
> >> cut
> >>>>> things
> >>>>>> as small in "Server Land" but getting the idea and trying to be
> >>> modular
> >>>>>> even before the JDK starts to enforce that with Java 9 is the right
> >>>>>> approach.
> >>>>>>
> >>>>>>
> >>>>>> On Mon, Jul 18, 2016 at 11:13 PM, Romain Manni-Bucau <
> >>>>> [email protected]>
> >>>>>> wrote:
> >>>>>>
> >>>>>>> Le 18 juil. 2016 23:04, "Werner Keil" <[email protected]> a
> >>>> écrit :
> >>>>>>>>
> >>>>>>>> Tamaya already works with e.g. Spring despite Spring Framework
> >>>> offering
> >>>>>>>> Config functionality of its own;-)
> >>>>>>>>
> >>>>>>>
> >>>>>>> Yes but libs cant rely on spring config api without bringing back
> >>>> spring
> >>>>>>> core
> >>>>>>>
> >>>>>>>> So as there are other config solutions at Apache like Commons
> >>> Config,
> >>>>>>>> exclusing CDI because DeltaSpike already uses it sounds odd.
> >>>>>>>>
> >>>>>>>
> >>>>>>> Commons config has no link afaik since it provides nice low level
> >>> impl
> >>>>> but
> >>>>>>> no good end user api/integration. It is also too opiniated to be
> >>> good
> >>>>> for a
> >>>>>>> spec since it has a lot of core methods making it hard to
> >> integrate
> >>>> with
> >>>>>>> all frameworks without limitations.
> >>>>>>>
> >>>>>>> That is why tamaya core should be minimal IMO.
> >>>>>>>
> >>>>>>>> There are even Apache projects like Tapestry that still offer
> >> their
> >>>> own
> >>>>>>> DI
> >>>>>>>> mechanism beside a JSR 330/CDI one, so I hope you're not
> >> suggesting
> >>>>>>> Tamaya
> >>>>>>>> should do the same just to "avoid" DeltaSpike?;-O
> >>>>>>>>
> >>>>>>>
> >>>>>>> I'm saying that tamaya core should be light enough to work with
> >> any
> >>>>> context
> >>>>>>> impl and never conflict with them, ie not implementing another
> >>>> context,
> >>>>> ie
> >>>>>>> providing built Config but not store them itself.
> >>>>>>>
> >>>>>>>>
> >>>>>>>> On Mon, Jul 18, 2016 at 10:53 PM, Romain Manni-Bucau <
> >>>>>>> [email protected]>
> >>>>>>>> wrote:
> >>>>>>>>
> >>>>>>>>> Trying to get back on track...
> >>>>>>>>>
> >>>>>>>>> If Tamaya targets CDI it will compete in a useless manner with
> >> DS
> >>> or
> >>>>>>> any
> >>>>>>>>> specific config API, if it targets contextuality it will with
> >> any
> >>>> IoC,
> >>>>>>> if
> >>>>>>>>> it targets coercing it will as well with one or both of previous
> >>>>>>> points.
> >>>>>>>>>
> >>>>>>>>> So IMO Tamaya API should be as Mark explained about handling
> >>> sources
> >>>>>>> and
> >>>>>>>>> filters to build on Config which can provide string access - and
> >>> not
> >>>>>>>>> properties cause it shouldnt be listable by default IMO.
> >>>>>>>>>
> >>>>>>>>> In term of API design I would align it on bval - a factory with
> >> a
> >>>>>>> builder
> >>>>>>>>> or a default loading to get a Config. It is core for me. Mark
> >>> likes
> >>>> to
> >>>>>>>>> count classes: factory + config + provider + source + source
> >>>> provider
> >>>>> +
> >>>>>>>>> filter (we can merge few of them using j8, not sure it is good
> >> but
> >>>>>>> would
> >>>>>>>>> work).
> >>>>>>>>>
> >>>>>>>>> Once we agree on that we will have to discuss on top of that:
> >>>>>>>>>
> >>>>>>>>> - integrations
> >>>>>>>>> - injections (injection points vs proxy Bean)
> >>>>>>>>> - coercion
> >>>>>>>>> - default impls
> >>>>>>>>> - ....
> >>>>>>>>>
> >>>>>>>>> But making the API small, strong and usable by all is important
> >>> IMHO
> >>>>>>>>>
> >>>>>>>>> Le 18 juil. 2016 22:41, "Werner Keil" <[email protected]> a
> >>>> écrit
> >>>>>>> :
> >>>>>>>>>
> >>>>>>>>>> Sorry to dissapoint you, but I was involved at least in Tamaya
> >>>> before
> >>>>>>>>>> Anatole even proposed it.
> >>>>>>>>>> I was nearly asked to give the presentation on what later
> >> became
> >>>>>>> Tamaya
> >>>>>>>>> by
> >>>>>>>>>> Mike Keith when he was stuck in heavy Monsoon rain at GIDS
> >>> 2011;-)
> >>>>>>>>>>
> >>>>>>>>>> I know what Commons Config, Tamaya or DeltaSpike can be used
> >> for.
> >>>> And
> >>>>>>>>>> helped clients who found e.g. DeltaSpike too complex and
> >>> overloaded
> >>>>>>> by
> >>>>>>>>>> contributing to their in-house CDI-based configuration
> >> framework
> >>>>>>>>> "inspired"
> >>>>>>>>>> by it. So Tamaya isn't the only example of API that some find
> >>> "too
> >>>>>>>>> much"...
> >>>>>>>>>>
> >>>>>>>>>> Werner
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>> On Mon, Jul 18, 2016 at 10:08 PM, Mark Struberg
> >>>>>>>>> <[email protected]
> >>>>>>>>>>>
> >>>>>>>>>> wrote:
> >>>>>>>>>>
> >>>>>>>>>>> It seems you do not yet understand the mechanics behind
> >>> DeltaSpike
> >>>>>>> and
> >>>>>>>>>>> Tamaya. Let me elaborate: Properties (and commons-config1&2 as
> >>>> well
> >>>>>>> for
> >>>>>>>>>>> that matter) only handle information from a SINGLE file.
> >>>>>>>>>>>
> >>>>>>>>>>> Whereas the ConfigSource approach abstracts that into an
> >> ordered
> >>>>>>> stack
> >>>>>>>>> of
> >>>>>>>>>>> _multiple_ such 'sources'. And such a
> >>> ConfigSource/PropertySource
> >>>>>>> also
> >>>>>>>>>>> doesn't need to be a single property file. It can be anything
> >>>> which
> >>>>>>>>> gives
> >>>>>>>>>>> access to configuration information.
> >>>>>>>>>>>
> >>>>>>>>>>> So yes, it should imo be as easy as property files - even
> >>> easier.
> >>>>>>> But
> >>>>>>>>> it
> >>>>>>>>>>> is not a _single_ file but many of them. And not only property
> >>>>>>> files
> >>>>>>>>> but
> >>>>>>>>>> a
> >>>>>>>>>>> freely extensible bunch of different such configuration
> >> sources!
> >>>>>>>>>>>
> >>>>>>>>>>> I hope you _now_ see the huge difference.
> >>>>>>>>>>> Regarding type-safety: I already wrote that twice: check out
> >>>>>>>>> ConfigValue.
> >>>>>>>>>>> (copying the example again):
> >>>>>>>>>>>
> >>>>>>>>>>> ---
> >>>>>>>>>>>> This allows for things like
> >>>>>>>>>>>
> >>>>>>>>>>>> ConfigValue<Integer> reloadAfterCfg =
> >>>>>>>>>>>>
> >> ConfigProvider.getConfig().access("myproject.mydb.reloadAfter")
> >>>>>>>>>>>> .as(Integer.class)
> >>>>>>>>>>>> .withDefault(1000)
> >>>>>>>>>>>> .cacheFor(5, TimeUnit.MINUTES)
> >>>>>>>>>>>> .evaluateVariables(true)
> >>>>>>>>>>>> .withLookupPath(config.getValue("myproject.dbvendor"),
> >>>>>>>>> projectStage);
> >>>>>>>>>>>>
> >>>>>>>>>>>> And later use
> >>>>>>>>>>>> reloadAfterCfg.getValue()---
> >>>>>>>>>>>
> >>>>>>>>>>> LieGrue,
> >>>>>>>>>>> strub
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>> On Monday, 18 July 2016, 21:53, Werner Keil <
> >>>> [email protected]
> >>>>>>>>
> >>>>>>>>>> wrote:
> >>>>>>>>>>>> To consider possible simplification and common denominators,
> >> it
> >>>>>>> seems
> >>>>>>>>>>> good to have a look at Tamaya's base interface:
> >>>>>>>>>>>
> >>>>>>>
> >>> http://tamaya.apache.org/apidocs/org/apache/tamaya/Configuration.html
> >>>>>>>>>>>> and
> >>>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>
> >>>>
> >>>
> >>
> https://commons.apache.org/proper/commons-configuration/apidocs/org/apache/commons/configuration2/ImmutableConfiguration.html
> >>>>>>>>>>>>
> >>>>>>>>>>>> they have at least some very basic methods in common. Leaving
> >>> the
> >>>>>>>>> order
> >>>>>>>>>>> of key or type aside.
> >>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>> In your proposed Config interface I only saw a
> >>>>>>>>>>>> String get(String) method, but for that sorry, we could just
> >>>> stick
> >>>>>>> to
> >>>>>>>>>> the
> >>>>>>>>>>> good old Properties and forget about the whole thing ;-|
> >>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>> A default or convenience method (what Commons Config 2 calls
> >>>>>>>>>> getString())
> >>>>>>>>>>> why not, but without type-safe yet extensible getters, there
> >> is
> >>>>>>> little
> >>>>>>>>>>> value to create a new API with more or less the same value
> >>>>>>> (literally)
> >>>>>>>>>> than
> >>>>>>>>>>> java.util.Properties.
> >>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>> I know you're on the CDI EG, other than that, not sure,
> >> which
> >>>>>>> others
> >>>>>>>>>>> (according to JCP.org, not mailing lists or other forms of
> >>>>>>>>> contribution)
> >>>>>>>>>>>> Being on both sides (EG and EC) in many cases, I am used to
> >>>>>>> question
> >>>>>>>>>> JSRs
> >>>>>>>>>>> and their Spec Leads, so it's not bad if this happens before
> >> any
> >>>> of
> >>>>>>>>> that
> >>>>>>>>>>> was filed or sonsidered towards a JSR.
> >>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>> Although there had been 2 attempt (one even by Adam Bien at a
> >>>> very
> >>>>>>>>> early
> >>>>>>>>>>> stage of his efforts in the JCP) JSR 377 is an example for a
> >>>>>>> seemingly
> >>>>>>>>>>> premature JSR proposal. And unless Andres does some "miracle"
> >> it
> >>>>>>> may
> >>>>>>>>>> likely
> >>>>>>>>>>> be shut down by the EC with the next Renewal Ballot.
> >>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>> So JCP.next introduced a few measures to avoid "neverending
> >>> JSRs"
> >>>>>>> like
> >>>>>>>>>>> 107 or 310 now, but sometimes it isn't a bad thing to wait or
> >>> file
> >>>>>>> it
> >>>>>>>>>> based
> >>>>>>>>>>> on experience by one or several Open Source projects.
> >> Hibernate
> >>>> was
> >>>>>>>>> one,
> >>>>>>>>>>> but considering the JPA RI is based on TopLink (now
> >> EclipseLink)
> >>>> it
> >>>>>>>>>>> certainly isn't the only project behind what became JPA
> >> either.
> >>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>> Cheers,
> >>>>>>>>>>>> Werner
> >>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>> On Mon, Jul 18, 2016 at 9:15 PM, Mark Struberg
> >>>>>>>>>> <[email protected]>
> >>>>>>>>>>> wrote:
> >>>>>>>>>>>>
> >>>>>>>>>>>> Yes Werner, we know.
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> But nonetheless Hibernate managed to
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> a.) get the spec on the ground pretty efficiently
> >>>>>>>>>>>>> b.) implemented the JPA specification on top of their own
> >>> logic
> >>>>>>> in a
> >>>>>>>>>>> timely fashion.
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> As you know I'm contributing to a number of specifications
> >> as
> >>> an
> >>>>>>>>>>> _active_ JCP EG member myself for many years now, so I really
> >>> know
> >>>>>>> all
> >>>>>>>>>> this
> >>>>>>>>>>> stuff!
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> On the original topic: if I say '5 interfaces' than those
> >>> don't
> >>>>>>> need
> >>>>>>>>> to
> >>>>>>>>>>> be exactly the ones I proposed. I also don't care whether we
> >>> call
> >>>>>>> them
> >>>>>>>>>>> ConfigSource or PropertySource (as example). All I like to do
> >> is
> >>>> to
> >>>>>>>>>> review
> >>>>>>>>>>> and clean up the API. After all this is a community decision.
> >>> If a
> >>>>>>>>>> majority
> >>>>>>>>>>> of Tamaya committers say I'm nuts and the current API is fine,
> >>>> then
> >>>>>>> be
> >>>>>>>>>> it.
> >>>>>>>>>>> Otoh if the majority is to do the cleanup then we should do it
> >>>>>>>>> properly.
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> LieGrue,
> >>>>>>>>>>>>> strub
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>> On Monday, 18 July 2016, 20:55, Werner Keil <
> >>>>>>> [email protected]
> >>>>>>>>>>
> >>>>>>>>>>> wrote:
> >>>>>>>>>>>>>>> Hibernate vs. JPA is also an interesting read:
> >>>>>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>
> >>>>
> >>>
> >>
> http://stackoverflow.com/questions/9881611/whats-the-difference-between-jpa-and-hibernate
> >>>>>>>>>>>>>> Like Tamaya, Apache Commons Config or other config
> >> solutions,
> >>>>>>>>>>> Hibernate was
> >>>>>>>>>>>>>> there before JPA. Its creators were involved as well as
> >> many
> >>>>>>> others
> >>>>>>>>>>> (even
> >>>>>>>>>>>>>> Apache or Novell;-)
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> Werner
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> On Mon, Jul 18, 2016 at 7:56 PM, Gerhard Petracek <
> >>>>>>>>>>> [email protected]>
> >>>>>>>>>>>>>> wrote:
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> before i vote, i would like to hear if there is a real
> >>>>>>> blocker
> >>>>>>>>> for
> >>>>>>>>>> a
> >>>>>>>>>>>>>>> simpler api (besides collections).
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> regards,
> >>>>>>>>>>>>>>> gerhard
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>
> >>>>>>>
> >>>>>
> >>>>>
> >>>>
> >>>
> >>>
> >>>
> >>> --
> >>> *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*
> >>>
> >>
>
>
