Hi Gerhard What you describe is use case that will follow later. You asked me to start with a simple one, so this is the most simple one. Next use cases will add aadditional sources, then we will combine things (aka complex overridings). After that we will emphasize on the environment model, because this defines the context, which determines which config is appropriate. The user in most cases will call Configuration.of() to access.the current configuration. This method then is backed by a config provider. This provider decides how the current environment is determining the config to be returned (aka defines implements the config metamodel). This metamodel can be defined rather differently depending your target runtime and require config solutions. And for this we require the basics (where I started).
What is in Deltaspike as of now is only a subset of what I see necessary to build a compelling config system. We will be able to cover that functionality easily and it will be easy to use. So please have some patience and let me post the use cases and solutions one by one and focus on these. I try to post them if possible on a daily basis. Hopefully we will have then a common terminology and architectural view on the whole topic that helps us discuss things efficiently ;) Cheers Anatole Gerhard Petracek <[email protected]> schrieb am Mo., 1. Dez. 2014 um 13:58: > 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 > > > > > >
