One of the curious things I've always noted with Tamaya was that it tries to deal with both the configuration retrieval and configuration creation aspects. Realistically, these are two different concerns. Without me being able to say that a service is able to do updates, I would expect a different set of permissions. John
On Sun, Jul 31, 2016 at 12:42 PM Werner Keil <[email protected]> wrote: > 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* > >> > >> > > >
