For a hava api the indirection adds complexity, for ee its invisible by using injection or jndi, so i think it is not a good idea ;) Anatole Tresch <[email protected]> schrieb am Mo., 1. Dez. 2014 um 14:22:
> 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.prope >> rties") >> > > .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.prope >> rties", >> > > "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 >> > > >> > >> >
