First of all ProcessorContext is missing;-|

There's a lot of cleaning and even more documenting to do now.
The chain and possible combinations of various API elements draws a pretty
confusing picture. I.E. what possible combinations of

   - MutableConfiguration
   - ScannableConfiguration and the newly introduced
   - TypedConfiguration

 should there be?;-O

The most basic examples all fail, especially because getProperties() no
longer exists. Even java.util.Properties had more than one variation of
that:
https://docs.oracle.com/javase/7/docs/api/java/util/Properties.html#stringPropertyNames()

The statement
>Properties whose key or value is not of type String are omitted.
sounds a bit weird because like the newly-proposed Configuration interface
java.util.Properties only returns String values;-)

Would be interesting to see it working, also down to at least the most
basic examples.

Regards,

Werner



On Sun, Jul 31, 2016 at 4:52 PM, Werner Keil <[email protected]> wrote:

> Hi,
>
> How did a "bloated" Tamaya with a total codebase of just under 2MB in
> master suddenly become over 20 MB in the "lean" version?;-O
>
> Also the "code" part (which is what should be sufficient to build the
> minimalistic API) does not compile with Maven.
>
> [ERROR]
> /C:/Users/Werner/git/tamaya-next-tamaya-next/code/api/src/main/java/org/apache/tamaya/spi/ConfigurationProcessor.java:[74,28]
> cannot find symbol
>   symbol:   class ProcessorContext
>   location: interface org.apache.tamaya.spi.ConfigurationProcessor
> [INFO] 1 error
>
> I'm not sure, if the term "ConfigurationProcessor" for what used to be a
> "*Source" really sticks. But being able to compile and run it especially
> with real life use cases (e.g. how the Joda module now works after those
> changes I'd be happy to start with.
>
> Regards,
>
> Werner
>
>
> On Sun, Jul 31, 2016 at 1:55 AM, Anatole Tresch <[email protected]>
> wrote:
>
>> Hi guys
>>
>> as promised I have put together the current state of a streamlines API
>> including adaptions needed on all the current codebase. This can be found at
>>
>> https://github.com/atsticks/tamaya-next
>>
>> The API especially is here:
>>
>>
>> https://github.com/atsticks/tamaya-next/tree/tamaya-next/code/api/src/main/java/org/apache/tamaya
>>
>> Short summary of the ideas:
>>
>>    - define *Configuration* by simply providing String get(String key).
>>    - organize configuration as an ordered list of "
>>    *ConfigurationProcessor*" instances aka *processor chain*, which
>>    basically are a more generic combination of PropertySource and
>>    PropertyFilter, thus removing the need for PropertyFilter as well as
>>    other heavy decision such as when to filter. The data access call is 
>> simply String
>>    get(String key, ConfigurationProcessorContext context);
>>    - The *ConfigurationProcessorContext* gives access to the remaining
>>    procerssor chain and also helps to reduce boilerplate code in the
>>    implementations.
>>    - The Configuration itself can be created using a
>>    *ConfigurationBuilder*, which basically is a programmatic API to
>>    construct the processor chain. This builder is provided by a
>>    *ConfigurationBuilderFactory*.
>>    - The factory also can load the default chain, which is the basic
>>    mechanism we had in place, loading sources, source providers and use their
>>    ordinals for priorization. Nevertheless the factor allows to build up your
>>    own thing, or allows to reproduce the "default" configuration bas calling
>>    factory.loadDefaults().build();
>>    - So the ConfigurationFactory is also the SPI used by the
>>    ConfigurationProvider using the default functionality as described
>>    above.
>>
>> This results in 4 API artifacts and a SPI with another 4 artifacts, which
>> allow us to do anything we already have with relatively controllable
>> efforts:
>> [image: Inline-Bild 1]
>>
>>
>> ​Just a few side nodes:
>>
>>
>>    - there is the adapter extension (*tamaya-adapter*), which allows you
>>    give an adapter singleton to adapt configuration to something else. E.g.
>>    this allows us to add functionality for types and defaults:
>>    TypedConfiguration cfg =
>>    ConfigAdapterManager.adapt(TypedConfiguration.class);
>>    ConfigWithDefaults cfg2 =
>>    ConfigAdapterManager.adapt(ConfigWithDefaults.class);
>>    ...
>>    - ​Similarly ConfigProcessor instances can implement Mixin Interfaces
>>    such as Scannable (another module SPI from *tamaya-scannable*) to
>>    provide additional capabilities. This can similalry used to provide access
>>    with getProperties().
>>
>> ​I will be now on holidays for 2 weeks. I will be able to answer mails,
>> but will not have access to a notebook or a computer bigger than my
>> smartphone. So hangouts work well, coding will be limited ;). Please look
>> at the code (especially the API and core parts, the modules are not yet
>> fully buildable ;) ).​
>>
>> ​J Anatole​
>>
>> ​Suggestion/question: next hangout on Monday evening ?​
>>
>>
>> --
>> *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*
>>
>>
>

Reply via email to