@john: about ConfigurationContainer it 100% depends on the Configuration: does it need this indirection or not. JCache needs it cause there is close() on the provider which makes sense but WebSocket doesn't really need it even if that's in the API and EJBContainer doesn't have it at all for instance. So I think it is better to not add an indirection making the API less fluent if not needed.
Romain Manni-Bucau @rmannibucau http://www.tomitribe.com http://rmannibucau.wordpress.com https://github.com/rmannibucau 2014-12-01 13:32 GMT+01:00 John D. Ament <[email protected]>: > 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 >> > >>
