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 >
