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