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
β
