I think we should follow suit to what specs such as websockets did for bootstrapping purposes.
PropertyProviders defaultPropertyProviders = ConfigurationContainer.getDefaultPropertyProviders(); this way we can avoid the static methods. That method getDefaultPropertyProviders would be the spot to put a service loader. John On Mon Dec 01 2014 at 5:32:23 AM Romain Manni-Bucau <[email protected]> wrote: > 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 > > >
