hi anatole,
again - yes and no.
no - it wasn't similar before, because you haven't started with the most
trivial usage (supported by tamaya right now).
however, now we are talking about a "different part" of the api which is
very similar -> yes
-> let's discuss
String myValue = Configuration.of().get("myKey").orElse(null);
maybe we can get something better than ".of().get" or we provide a static
helper for it.
currently this first part doesn't read fluently. a lot of users might not
need more than that (at least in the beginning) and therefore it should be
nice.
regards,
gerhard
2014-12-01 16:07 GMT+01:00 Tresch, Anatole <[email protected]
>:
> Hi Gerhard
>
> as I said granularity is not matching in your example. Comparing concepts
> on the same granularity level it would be:
>
> String myValue = ConfigResolver.getPropertyValue("myKey"); //
> Deltaspike
>
> compared to:
>
> String myValue = Configuration.of().get("myKey").orElse(null); //
> Tamaya
>
> So that looks more or less similar (I did not count the characters) ;)
>
> It will be interesting to see how it feels, when defining the model behind
> this facades. Tamaya can support dynamic property providers (aka
> PropertySource) managed by CDI for app config as well. But on top of them
> also will probably be capable to configure CDI and other aspects. Already
> in place is a Properties implementation that can be applied to
> System.setProperties(Properties), which adds dynamic (configurable)system
> properties as a minimal shared level of API already available as of now on
> SE level.
>
> -Anatole
>
>
> -----Original Message-----
> From: Gerhard Petracek [mailto:[email protected]]
> Sent: Montag, 1. Dezember 2014 14:30
> To: [email protected]
> Subject: Re: Use Case 1: Read simple properties and get values.
>
> hi anatole,
>
> yes and no - the part i talked about mainly is:
> String myValue = ConfigResolver.getPropertyValue("myKey");
>
> compared to:
> Configuration config = PropertyProviders.fromPaths(/*...*/);
> String myValue = config.get("myKey", String.class);
>
> regards,
> gerhard
>
>
>
> 2014-12-01 14:22 GMT+01:00 Anatole Tresch <[email protected]>:
>
> > 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
> > > > >
> > > >
> > >
> >
>
