The* provider implements the metamodel:*
- It defines *which resources/files/whatever are read from which
locations*.
- It defines (optionally) as well, *which formats can be used*.
- It defines how the different *pieces loaded are assembled together*,
in complex cases assembly can be multilayered, depending on the current
environment, when a configuration is accerssed.
The logic *how things are read,* is done by the *ResourceLoader*, therefore
it is extendible. By default classpaths, files and URLs are supported.
The logic* how the InputStreams are converted into key/value pairs* is done
by the *ConfigurationFormat*.
At the end you get something like a "domain language" to define your
configuration policy overall in Java. Users at the end in an enterprise
context simply call:* Configuration.current() *or
*Configuration.current("name")*. Everything else is hidden from them.
Configuration is provided as a service. It is only the power users that
typically are exposed to the inner workings. And obviously these are the
areas, where people have completely different views, how things should be
done.
Summarizing reading some property files in a given format and putting some
kind of Config API over it, is not what makes the difference. You can
already use other solutions for that. The difference is, that you get a
complete toolset for building up a configuration system that exactly fits
your needs, whatever you require it to do. On the other hand the usage API
is damn simple.
And templates help to transparently hook the configuration system in
whatever kind of parts you want to configure easily ;)
All the other things we have seen like Environment, builders, interfaces,
aggregations etc. are the toolset you have to implement the providers
needed.
Clearer now?
Cheers,
Anatole
2014-12-21 15:39 GMT+01:00 Oliver B. Fischer (JIRA) <[email protected]>:
>
>
> [
> https://issues.apache.org/jira/browse/TAMAYA-35?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14255163#comment-14255163
> ]
>
> Oliver B. Fischer commented on TAMAYA-35:
> -----------------------------------------
>
> As far as I remember the provider is responsible for the location while
> the config format is reponsible for the concrete format. Right? If so, how
> does it fit together?
>
> > Add new FilesPropertiesConfigProvider
> > -------------------------------------
> >
> > Key: TAMAYA-35
> > URL: https://issues.apache.org/jira/browse/TAMAYA-35
> > Project: Tamaya
> > Issue Type: Improvement
> > Components: Core
> > Reporter: Otavio Goncalves de Santana
> >
> > Add new provider that read the xml and properties files in below folders
> creates a new configuration.
> > These files should be watched, once modified the configuration should be
> updated automatically.
> > The folders will:
> > * META-INF/cfg/
> > * META-INF/config/
> > * META-INF/tamaya
> > This provider will have less priority than that already exist.
>
>
>
> --
> This message was sent by Atlassian JIRA
> (v6.3.4#6332)
>
--
*Anatole Tresch*
Java Engineer & Architect, JSR Spec Lead
Glärnischweg 10
CH - 8620 Wetzikon
*Switzerland, Europe Zurich, GMT+1*
*Twitter: @atsticks*
*Blogs: **http://javaremarkables.blogspot.ch/
<http://javaremarkables.blogspot.ch/>*
*Google: atsticksMobile +41-76 344 62 79*
