hi @ all,
@anatole: thx for starting this thread.
let's start/continue with the first part - the equivalent in deltaspike is:
String myValue = ConfigResolver.getPropertyValue("myKey");
as a precondition for this call, you need 1-n registered config-source(s)
(= std. spi config -> in this case in:
META-INF/services/org.apache.deltaspike.core.spi.config.ConfigSource).
this approach is nice for >applications<, because everything is done
automatically based on the "visible" configs.
furthermore, it's very flexible, because a config-source encapsulates the
logic for different config-locations (files, jndi, db,...).
mark wrote that part -> he might add some details which are important to
him (for the >current< use-case):
regards,
gerhard
2014-12-01 11:30 GMT+01:00 Romain Manni-Bucau <[email protected]>:
> Looks like a good entry point, I like the "prefixing" to switch of
> "reader". However I don't like to be forced to use an Optional. In
> several cases I prefer to stick to properties API ie get something or
> a default, default being null if not set when queried. Optional is not
> bad but makes code very verbose for pretty much nothing is several
> cases (of config).
>
>
> wdyt?
>
>
> Romain Manni-Bucau
> @rmannibucau
> http://www.tomitribe.com
> http://rmannibucau.wordpress.com
> https://github.com/rmannibucau
>
>
> 2014-12-01 11:15 GMT+01:00 Anatole Tresch <[email protected]>:
> > Hi all
> >
> > I have put together a first couple of simple use cases. It is targeting
> SE
> > level only (as many use cases will do, especially the basic ones).
> >
> > *Basic use case 1:*
> > We want to write some properties file and read it from a file or the
> > classpath into a Configuration instance. This is done by
> >
> > Configuration config = PropertyProviders.fromPaths(
> > "classpath:ucs/UC1ReadProperties/UC1ReadPropertiesTest.properties")
> > .toConfiguration();
> >
> > The PropertyProvider which is created here by
> > PropertyProviders.fromPaths hereby
> > is a simplified version that can be easily aggregated (for composites)
> and
> > only provides String values (no type support yet). Nevertheless
> > mapping to Configuration
> > is trivial.
> >
> > Given that we then can access different values. Since we return Optional
> as
> > a result type the values returned are never null. For showing the
> > capabilities I added multiple examples of types:
> >
> > String name = config.get("name").orElse("Anatole");
> > BigDecimal bigNum = config.get("num.BD", BigDecimal.class)
> > .orElseThrow(() -> new
> > IllegalStateException("Sorry"));
> > double anotherNum = config.getDouble("num.Double").getAsDouble();
> > long longNum = config.getLong("num.Long").orElse(288900L);
> >
> > Finally plugins or modules often only want a view on their subset of
> > entries. This can be achieved easily by using
> >
> > Configuration areaConfig2 =
> config.with(ConfigFunctions.selectArea("num"));
> >
> > This will return a Configuration subset, which will only contain the
> child
> > values of the num area, which are BD, double, ... ConfigFunctions BTW is
> a
> > dingleton accessot, which serves
> > ConfigOperator functional extensions (there is also a ConfigQuery), so
> this
> > is a common pattern for adding whatever extension needed to
> > Configuration instances
> > without having them to directly implement/provide on Configuration
> itself.
> >
> > All the features are reflected in the test class (in the core module):
> > org.apache.tamaya.uc.UC1ReadProperties.UC1ReadPropertiesTest (we should
> > lower case the package name ;) ).
> >
> > This test also contains additional features/use cases...
> >
> > *Extended use case 1.1: multiple formats*
> > It is possible to read multiple file formats, by default the following
> > formats are supported
> >
> > - .properties (as defined by java.util.Properties)
> > - .xml properties (as defined by java.util.Properties)
> > - .ini format
> >
> > Configuration config = PropertyProviders.fromPaths(
> > "classpath:ucs/UC1ReadProperties/UC1ReadPropertiesTest.properties",
> > "classpath:ucs/UC1ReadProperties/UC1ReadPropertiesTest.xml",
> > "file:c:/temp/myProps.properties")
> > .toConfiguration();
> >
> >
> > In the back format resolution is handled by an SPI, which is
> > extendable/pluggable.
> > The basic component here ist the ConfigurationFormats singleton and
> > the ConfigurationFormat
> > interfaCE.
> >
> >
> > *Extended use case 1.2: multiple sources*
> > It is possible to read multiple files, by adding
> >
> > - additional paths (see above)
> > - ant styled expressions
> >
> > Configuration config = PropertyProviders.fromPaths(
> > "classpath:ucs/UC1ReadProperties/UC1ReadPropertiesTest.*",
> > "classpath*:ucs/UC1ReadProperties/**/*.properties")
> > .toConfiguration();
> >
> > In the back resource resolution is handled by an SPI, which is
> > extendable/pluggable as well. file,file*,classpath,classpath* are the
> > locator ids which are implemented based on a subset of the Spring
> resource
> > loader is working. Additional resource location mechanism could be
> > easily added by implementing the
> > org.apache.tamaya.core.internal.resources.PathResolver interface. If one
> > implements and registers (using the Bootstrap component, by default using
> > ServiceLoader), e.g. a resolver called "foo", the expression would look
> > like:
> >
> > Configuration config = PropertyProviders.fromPaths(
> > "foo:myResourceExpression");
> >
> > Next variants would be reading properties from other resources. We could
> > e.g. create a programmatic random resource and also use a database, or
> > remote resource.
> >
> > Cheers,
> > Anatole
> >
>
