You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tamaya.apache.org by Anatole Tresch <an...@apache.org> on 2014/12/01 11:15:35 UTC
Use Case 1: Read simple properties and get values.
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
Re: Use Case 1: Read simple properties and get values.
Posted by Romain Manni-Bucau <rm...@gmail.com>.
@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 <jo...@apache.org>:
> 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 <rm...@gmail.com>
> 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 <an...@apache.org>:
>> > 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
>> >
>>
Re: Use Case 1: Read simple properties and get values.
Posted by "John D. Ament" <jo...@apache.org>.
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 <rm...@gmail.com>
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 <an...@apache.org>:
> > 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
> >
>
Re: Use Case 1: Read simple properties and get values.
Posted by Anatole Tresch <at...@gmail.com>.
*Configuration.current()* I suggest is a good proposal. It depends on the
effective API/metamodel in place if configuration are the same or not.
Typically as far as the runtime context is the same (however there is no
common notion, when this is the case) I tend to expect instances are the
same...
I will continue reading the other mails...
2014-12-01 17:54 GMT+01:00 Romain Manni-Bucau <rm...@gmail.com>:
> Configuration.current() sounds easier to understand first time you see
> it. I like Configuration.newInstance() if that's really what it does
> (ie no caching by classloader or anything else).
>
>
> Romain Manni-Bucau
> @rmannibucau
> http://www.tomitribe.com
> http://rmannibucau.wordpress.com
> https://github.com/rmannibucau
>
>
> 2014-12-01 17:42 GMT+01:00 Anatole Tresch <at...@gmail.com>:
> > There is a naming concept from Stephen Colebourne when to use of, from,
> > with. I try to lookup the link later, see also jsr 310 and 354.
> > getInstance, valueOf are considered to be outdated for modern api design.
> >
> > Adding a helper, why? Another artifact a user must know, makes sense,
> where
> > you have a huge acces api IMO (see PropertyProviders where the factory
> > methods are not part of the PropertyProvider interface. For
> Configuration I
> > prefer having sn intuitive simple/single access...
> >
> > Nevertheless I would like to encourage you to make a concrete proposal
> how
> > would name things, so we can compare what your idea of fluent is ;)
> >
> > -anatole
> > Gerhard Petracek <ge...@gmail.com> schrieb am Mo., 1. Dez.
> 2014
> > um 17:24:
> >
> >> 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
> <anatole.tresch@credit-suisse.
> >> com
> >> >:
> >>
> >> > 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:gerhard.petracek@gmail.com]
> >> > Sent: Montag, 1. Dezember 2014 14:30
> >> > To: dev@tamaya.incubator.apache.org
> >> > 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 <an...@apache.org>:
> >> >
> >> > > 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 <ge...@gmail.com> 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 <
> rmannibucau@gmail.com
> >> >:
> >> > > >
> >> > > > > 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 <an...@apache.org>:
> >> > > > > > 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
> >> > > > > >
> >> > > > >
> >> > > >
> >> > >
> >> >
> >>
>
--
*Anatole Tresch*
Java Engineer & Architect, JSR Spec Lead
Glärnischweg 10
CH - 8620 Wetzikon
*Switzerland, Europe Zurich, GMT+1*
*Twitter: @atsticks*
*Blogs: **http://javaremarkables.blogspot.ch/
<http://javaremarkables.blogspot.ch/>*
*Google: atsticksMobile +41-76 344 62 79*
Re: Use Case 1: Read simple properties and get values.
Posted by Gerhard Petracek <ge...@gmail.com>.
@anatole:
you know the issue with "it's modern" - esp. when it comes to naming (which
is a matter of taste anyway)...
so i would use whatever makes sense and not what's "modern" >currently<.
if it's too bulky, people won't use it or introduce their own static
helpers (once again...).
@romain: +1
regards,
gerhard
2014-12-01 17:54 GMT+01:00 Romain Manni-Bucau <rm...@gmail.com>:
> Configuration.current() sounds easier to understand first time you see
> it. I like Configuration.newInstance() if that's really what it does
> (ie no caching by classloader or anything else).
>
>
> Romain Manni-Bucau
> @rmannibucau
> http://www.tomitribe.com
> http://rmannibucau.wordpress.com
> https://github.com/rmannibucau
>
>
> 2014-12-01 17:42 GMT+01:00 Anatole Tresch <at...@gmail.com>:
> > There is a naming concept from Stephen Colebourne when to use of, from,
> > with. I try to lookup the link later, see also jsr 310 and 354.
> > getInstance, valueOf are considered to be outdated for modern api design.
> >
> > Adding a helper, why? Another artifact a user must know, makes sense,
> where
> > you have a huge acces api IMO (see PropertyProviders where the factory
> > methods are not part of the PropertyProvider interface. For
> Configuration I
> > prefer having sn intuitive simple/single access...
> >
> > Nevertheless I would like to encourage you to make a concrete proposal
> how
> > would name things, so we can compare what your idea of fluent is ;)
> >
> > -anatole
> > Gerhard Petracek <ge...@gmail.com> schrieb am Mo., 1. Dez.
> 2014
> > um 17:24:
> >
> >> 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
> <anatole.tresch@credit-suisse.
> >> com
> >> >:
> >>
> >> > 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:gerhard.petracek@gmail.com]
> >> > Sent: Montag, 1. Dezember 2014 14:30
> >> > To: dev@tamaya.incubator.apache.org
> >> > 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 <an...@apache.org>:
> >> >
> >> > > 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 <ge...@gmail.com> 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 <
> rmannibucau@gmail.com
> >> >:
> >> > > >
> >> > > > > 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 <an...@apache.org>:
> >> > > > > > 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
> >> > > > > >
> >> > > > >
> >> > > >
> >> > >
> >> >
> >>
>
Re: Use Case 1: Read simple properties and get values.
Posted by Romain Manni-Bucau <rm...@gmail.com>.
@Gerhard: ordinal will surely not be enough. I saw cases were I needed
to skip a property in "providers" depending the values. Ie "ferrari"
always wins on "dacia" for instance whatever priority it is. That's
why I spoke about a MergePolicy (surely: merge(provider1, provider2,
key, value1, value2).
Romain Manni-Bucau
@rmannibucau
http://www.tomitribe.com
http://rmannibucau.wordpress.com
https://github.com/rmannibucau
2014-12-01 19:26 GMT+01:00 Gerhard Petracek <ge...@gmail.com>:
> @oliver:
> i'm not sure if you familiar with the ordinal-approach provided by
> deltaspike.
>
> regards,
> gerhard
>
>
>
> 2014-12-01 19:20 GMT+01:00 Werner Keil <we...@gmail.com>:
>
>> If you get one by app, is there any form of "context" you'd pass to such
>> factory method?
>>
>> Currency.getInstance() returns exactly one singleton instance of a Currency
>> class (otherwise has no constructor either) for a given currency code.
>> While Money.of() in JSR 354 RI returns totally different instances
>> depending on the combination of (nearly unlimited) different numbers and
>> currency codes. 354 tries to broaden the definition of Currency, but if you
>> get exactly one distinct instance per VM/app that's a singleton IMHO even
>> if you may call the same application multiple times.
>>
>> On Mon, Dec 1, 2014 at 7:12 PM, Romain Manni-Bucau <rm...@gmail.com>
>> wrote:
>>
>> > Hmm,
>> >
>> > for me getInstance() = singleton in term of instance where
>> > Configuration will be all but a singleton IMO (you'll get at least one
>> > by app and surely a new instance each time you call it) no?
>> >
>> >
>> > Romain Manni-Bucau
>> > @rmannibucau
>> > http://www.tomitribe.com
>> > http://rmannibucau.wordpress.com
>> > https://github.com/rmannibucau
>> >
>> >
>> > 2014-12-01 18:56 GMT+01:00 Werner Keil <we...@gmail.com>:
>> > > Hi,
>> > >
>> > > Adding to the question of convenience factories, there is no such thing
>> > as
>> > > "naming convention" by Stephen Colebourne or JSR 310. In fact, it
>> > violates
>> > > or bends almost every one of them in itself, so a suggestion like
>> > > Configuration.current() would sound very similar to the
>> > LocalDateTime.now()
>> > > ones in 310.
>> > > For several other cases of() or longer variations (like ofMilli()
>> > ofNanos()
>> > > etc.;-O) are used, while static factories from strings similar to what
>> > JSR
>> > > 354 adopted are called parse(String).
>> > >
>> > > Josh Bloch defined a clear distinction between what he then in most
>> cases
>> > > (except EnumSet, that's where he started using of() so Josh also
>> > "invented"
>> > > that while it violated some of his earlier naming conventions;-D)
>> called
>> > > valueOf() and getInstance(), see
>> > >
>> >
>> http://blog.codefront.net/2003/06/21/java-tip-2-static-factory-methods-vs-constructors/
>> > > getInstance() returns a singleton, either the only instance for this
>> type
>> > > of object or the only instance for a distinct code or enum (see
>> > > java.util.Currency)
>> > >
>> > > Very recent APIs and JSRs like MEEP 8 make a clear distinction, and
>> > classes
>> > > like
>> > >
>> >
>> https://docs.oracle.com/javame/8.0/api/meep/api/javax/microedition/event/EventManager.html
>> > > clearly explain that, too. In other places ME 8 uses of() where
>> > appropriate.
>> > > So at least getInstance() is neither outdated nor wrong, it just
>> depends
>> > on
>> > > what you return.
>> > >
>> > > If Configuration returns just a default instance then
>> > > Configuration.getInstance() seems appropriate.
>> > >
>> > >
>> > > Werner Keil | JCP Executive Committee Member, JSR 363 Co Spec Lead |
>> > > Eclipse UOMo Lead, Babel Language Champion | Apache Committer
>> > >
>> > > Twitter @wernerkeil | @UnitAPI | @JSR354 | @DeviceMap | #EclipseUOMo |
>> > > #Java_Social
>> > > | #DevOps
>> > > Skype werner.keil | Google+ gplus.to/wernerkeil
>> > >
>> > > On Mon, Dec 1, 2014 at 6:31 PM, Oliver B. Fischer <
>> > o.b.fischer@swe-blog.net>
>> > > wrote:
>> > >
>> > >> Hi,
>> > >>
>> > >> for me the most simple use case is
>> > >>
>> > >> Configuration conf = new Configuration();
>> > >> String value = conf.get("key")
>> > >>
>> > >> And this use case is already very complex under the hood.
>> > >>
>> > >> Before discussing other details we have to decide how
>> PropertyProviders
>> > >> are activated.
>> > >>
>> > >> I would like to have the following possibilites:
>> > >>
>> > >> 1. Tamaya activates all PropertyProviders found in the classpath and
>> > >> activated via SPI.
>> > >> 2. Tamaya activates only a explicitly named list of Property providers
>> > >> 3. I have the ability to control the order in which the property
>> > solution
>> > >> will be performed
>> > >>
>> > >> Bye,
>> > >>
>> > >> Oliver
>> > >>
>> > >>
>> > >> Am 01.12.14 17:54, schrieb Romain Manni-Bucau:
>> > >>
>> > >>> Configuration.current() sounds easier to understand first time you
>> see
>> > >>> it. I like Configuration.newInstance() if that's really what it does
>> > >>> (ie no caching by classloader or anything else).
>> > >>>
>> > >>>
>> > >>> Romain Manni-Bucau
>> > >>> @rmannibucau
>> > >>> http://www.tomitribe.com
>> > >>> http://rmannibucau.wordpress.com
>> > >>> https://github.com/rmannibucau
>> > >>>
>> > >>>
>> > >>> 2014-12-01 17:42 GMT+01:00 Anatole Tresch <at...@gmail.com>:
>> > >>>
>> > >>>> There is a naming concept from Stephen Colebourne when to use of,
>> > from,
>> > >>>> with. I try to lookup the link later, see also jsr 310 and 354.
>> > >>>> getInstance, valueOf are considered to be outdated for modern api
>> > design.
>> > >>>>
>> > >>>> Adding a helper, why? Another artifact a user must know, makes
>> sense,
>> > >>>> where
>> > >>>> you have a huge acces api IMO (see PropertyProviders where the
>> factory
>> > >>>> methods are not part of the PropertyProvider interface. For
>> > >>>> Configuration I
>> > >>>> prefer having sn intuitive simple/single access...
>> > >>>>
>> > >>>> Nevertheless I would like to encourage you to make a concrete
>> proposal
>> > >>>> how
>> > >>>> would name things, so we can compare what your idea of fluent is ;)
>> > >>>>
>> > >>>> -anatole
>> > >>>> Gerhard Petracek <ge...@gmail.com> schrieb am Mo., 1.
>> Dez.
>> > >>>> 2014
>> > >>>> um 17:24:
>> > >>>>
>> > >>>> 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
>> > >>>>> <anatole.tresch@credit-suisse.
>> > >>>>> com
>> > >>>>>
>> > >>>>>> :
>> > >>>>>> 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:gerhard.petracek@gmail.com]
>> > >>>>>> Sent: Montag, 1. Dezember 2014 14:30
>> > >>>>>> To: dev@tamaya.incubator.apache.org
>> > >>>>>> 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 <an...@apache.org>:
>> > >>>>>>
>> > >>>>>> 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 <ge...@gmail.com> 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 <
>> > rmannibucau@gmail.com
>> > >>>>>>>>
>> > >>>>>>> :
>> > >>>>>>
>> > >>>>>>> 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 <anatole@apache.org
>> >:
>> > >>>>>>>>>
>> > >>>>>>>>>> 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
>> > >>>>>>>>>>
>> > >>>>>>>>>>
>> > >> --
>> > >> N Oliver B. Fischer
>> > >> A Schönhauser Allee 64, 10437 Berlin, Deutschland/Germany
>> > >> P +49 30 44793251
>> > >> M +49 178 7903538
>> > >> E o.b.fischer@swe-blog.net
>> > >> S oliver.b.fischer
>> > >> J oliver.b.fischer@jabber.org
>> > >> X http://xing.to/obf
>> > >>
>> > >>
>> >
>>
Re: Use Case 1: Read simple properties and get values.
Posted by Anatole Tresch <at...@gmail.com>.
+1 will provide the defs for the most important abstractions asap.
Gerhard Petracek <ge...@gmail.com> schrieb am Di., 2. Dez. 2014
um 19:24:
> @anatole: +1
>
> regards,
> gerhard
>
>
>
> 2014-12-02 19:13 GMT+01:00 Anatole Tresch <at...@gmail.com>:
>
> > @gerhard @oliver I tend to pospone this topic as said, one it is time for
> > it. It may be enough, or be improved. Basically that depends on the
> design
> > around providers (single chains, multi chains,...).
> >
> > 2014-12-02 15:08 GMT+01:00 Gerhard Petracek <gerhard.petracek@gmail.com
> >:
> >
> > > @oliver:
> > > deltaspike allows to change the predefined ordinal (per config-source)
> by
> > > adding an entry to the data visible to the config-source.
> > > -> you can change the predefined priority via the config itself.
> > >
> > > regards,
> > > gerhard
> > >
> > >
> > >
> > > 2014-12-02 14:41 GMT+01:00 Oliver B. Fischer <o.b.fischer@swe-blog.net
> >:
> > >
> > > > @Gerhard: I saw it in the API documents of Deltaspike. I think the
> user
> > > of
> > > > Tamaya should be able to decide which provider has the highest
> > priority.
> > > >
> > > > Bye,
> > > >
> > > > Oliver
> > > >
> > > >
> > > > Am 01.12.14 19:26, schrieb Gerhard Petracek:
> > > >
> > > >> @oliver:
> > > >> i'm not sure if you familiar with the ordinal-approach provided by
> > > >> deltaspike.
> > > >>
> > > >> regards,
> > > >> gerhard
> > > >>
> > > >>
> > > > --
> > > > N Oliver B. Fischer
> > > > A Schönhauser Allee 64, 10437 Berlin, Deutschland/Germany
> > > > P +49 30 44793251
> > > > M +49 178 7903538
> > > > E o.b.fischer@swe-blog.net
> > > > S oliver.b.fischer
> > > > J oliver.b.fischer@jabber.org
> > > > X http://xing.to/obf
> > > >
> > > >
> > >
> >
> >
> >
> > --
> > *Anatole Tresch*
> > Java Engineer & Architect, JSR Spec Lead
> > Glärnischweg 10
> > CH - 8620 Wetzikon
> >
> > *Switzerland, Europe Zurich, GMT+1*
> > *Twitter: @atsticks*
> > *Blogs: **http://javaremarkables.blogspot.ch/
> > <http://javaremarkables.blogspot.ch/>*
> >
> > *Google: atsticksMobile +41-76 344 62 79*
> >
>
Re: Use Case 1: Read simple properties and get values.
Posted by Gerhard Petracek <ge...@gmail.com>.
@anatole: +1
regards,
gerhard
2014-12-02 19:13 GMT+01:00 Anatole Tresch <at...@gmail.com>:
> @gerhard @oliver I tend to pospone this topic as said, one it is time for
> it. It may be enough, or be improved. Basically that depends on the design
> around providers (single chains, multi chains,...).
>
> 2014-12-02 15:08 GMT+01:00 Gerhard Petracek <ge...@gmail.com>:
>
> > @oliver:
> > deltaspike allows to change the predefined ordinal (per config-source) by
> > adding an entry to the data visible to the config-source.
> > -> you can change the predefined priority via the config itself.
> >
> > regards,
> > gerhard
> >
> >
> >
> > 2014-12-02 14:41 GMT+01:00 Oliver B. Fischer <o....@swe-blog.net>:
> >
> > > @Gerhard: I saw it in the API documents of Deltaspike. I think the user
> > of
> > > Tamaya should be able to decide which provider has the highest
> priority.
> > >
> > > Bye,
> > >
> > > Oliver
> > >
> > >
> > > Am 01.12.14 19:26, schrieb Gerhard Petracek:
> > >
> > >> @oliver:
> > >> i'm not sure if you familiar with the ordinal-approach provided by
> > >> deltaspike.
> > >>
> > >> regards,
> > >> gerhard
> > >>
> > >>
> > > --
> > > N Oliver B. Fischer
> > > A Schönhauser Allee 64, 10437 Berlin, Deutschland/Germany
> > > P +49 30 44793251
> > > M +49 178 7903538
> > > E o.b.fischer@swe-blog.net
> > > S oliver.b.fischer
> > > J oliver.b.fischer@jabber.org
> > > X http://xing.to/obf
> > >
> > >
> >
>
>
>
> --
> *Anatole Tresch*
> Java Engineer & Architect, JSR Spec Lead
> Glärnischweg 10
> CH - 8620 Wetzikon
>
> *Switzerland, Europe Zurich, GMT+1*
> *Twitter: @atsticks*
> *Blogs: **http://javaremarkables.blogspot.ch/
> <http://javaremarkables.blogspot.ch/>*
>
> *Google: atsticksMobile +41-76 344 62 79*
>
Re: Use Case 1: Read simple properties and get values.
Posted by Anatole Tresch <at...@gmail.com>.
@gerhard @oliver I tend to pospone this topic as said, one it is time for
it. It may be enough, or be improved. Basically that depends on the design
around providers (single chains, multi chains,...).
2014-12-02 15:08 GMT+01:00 Gerhard Petracek <ge...@gmail.com>:
> @oliver:
> deltaspike allows to change the predefined ordinal (per config-source) by
> adding an entry to the data visible to the config-source.
> -> you can change the predefined priority via the config itself.
>
> regards,
> gerhard
>
>
>
> 2014-12-02 14:41 GMT+01:00 Oliver B. Fischer <o....@swe-blog.net>:
>
> > @Gerhard: I saw it in the API documents of Deltaspike. I think the user
> of
> > Tamaya should be able to decide which provider has the highest priority.
> >
> > Bye,
> >
> > Oliver
> >
> >
> > Am 01.12.14 19:26, schrieb Gerhard Petracek:
> >
> >> @oliver:
> >> i'm not sure if you familiar with the ordinal-approach provided by
> >> deltaspike.
> >>
> >> regards,
> >> gerhard
> >>
> >>
> > --
> > N Oliver B. Fischer
> > A Schönhauser Allee 64, 10437 Berlin, Deutschland/Germany
> > P +49 30 44793251
> > M +49 178 7903538
> > E o.b.fischer@swe-blog.net
> > S oliver.b.fischer
> > J oliver.b.fischer@jabber.org
> > X http://xing.to/obf
> >
> >
>
--
*Anatole Tresch*
Java Engineer & Architect, JSR Spec Lead
Glärnischweg 10
CH - 8620 Wetzikon
*Switzerland, Europe Zurich, GMT+1*
*Twitter: @atsticks*
*Blogs: **http://javaremarkables.blogspot.ch/
<http://javaremarkables.blogspot.ch/>*
*Google: atsticksMobile +41-76 344 62 79*
Re: Use Case 1: Read simple properties and get values.
Posted by "Oliver B. Fischer" <o....@swe-blog.net>.
@gerhard: No, I like the idea. Maybe later we have some ideas how to
improve it - if needed.
Am 02.12.14 16:03, schrieb Gerhard Petracek:
> @oliver:
> the point is that it's simple and good enough for a lot of cases.
> if you like, you can discuss the idea itself with mark ;)
>
> regards,
> gerhard
>
>
>
> 2014-12-02 15:12 GMT+01:00 Oliver B. Fischer <o....@swe-blog.net>:
>
>> @gerhard: This is the right to go ;-)
>>
>> Am 02.12.14 15:08, schrieb Gerhard Petracek:
>>
>> @oliver:
>> --
>> N Oliver B. Fischer
>> A Schönhauser Allee 64, 10437 Berlin, Deutschland/Germany
>> P +49 30 44793251
>> M +49 178 7903538
>> E o.b.fischer@swe-blog.net
>> S oliver.b.fischer
>> J oliver.b.fischer@jabber.org
>> X http://xing.to/obf
>>
>>
--
N Oliver B. Fischer
A Schönhauser Allee 64, 10437 Berlin, Deutschland/Germany
P +49 30 44793251
M +49 178 7903538
E o.b.fischer@swe-blog.net
S oliver.b.fischer
J oliver.b.fischer@jabber.org
X http://xing.to/obf
Re: Use Case 1: Read simple properties and get values.
Posted by Gerhard Petracek <ge...@gmail.com>.
@oliver:
the point is that it's simple and good enough for a lot of cases.
if you like, you can discuss the idea itself with mark ;)
regards,
gerhard
2014-12-02 15:12 GMT+01:00 Oliver B. Fischer <o....@swe-blog.net>:
> @gerhard: This is the right to go ;-)
>
> Am 02.12.14 15:08, schrieb Gerhard Petracek:
>
> @oliver:
>> deltaspike allows to change the predefined ordinal (per config-source) by
>> adding an entry to the data visible to the config-source.
>> -> you can change the predefined priority via the config itself.
>>
>> regards,
>> gerhard
>>
>>
>>
>> 2014-12-02 14:41 GMT+01:00 Oliver B. Fischer <o....@swe-blog.net>:
>>
>> @Gerhard: I saw it in the API documents of Deltaspike. I think the user
>>> of
>>> Tamaya should be able to decide which provider has the highest priority.
>>>
>>> Bye,
>>>
>>> Oliver
>>>
>>>
>>> Am 01.12.14 19:26, schrieb Gerhard Petracek:
>>>
>>> @oliver:
>>>> i'm not sure if you familiar with the ordinal-approach provided by
>>>> deltaspike.
>>>>
>>>> regards,
>>>> gerhard
>>>>
>>>>
>>>> --
>>> N Oliver B. Fischer
>>> A Schönhauser Allee 64, 10437 Berlin, Deutschland/Germany
>>> P +49 30 44793251
>>> M +49 178 7903538
>>> E o.b.fischer@swe-blog.net
>>> S oliver.b.fischer
>>> J oliver.b.fischer@jabber.org
>>> X http://xing.to/obf
>>>
>>>
>>>
> --
> N Oliver B. Fischer
> A Schönhauser Allee 64, 10437 Berlin, Deutschland/Germany
> P +49 30 44793251
> M +49 178 7903538
> E o.b.fischer@swe-blog.net
> S oliver.b.fischer
> J oliver.b.fischer@jabber.org
> X http://xing.to/obf
>
>
Re: Use Case 1: Read simple properties and get values.
Posted by "Oliver B. Fischer" <o....@swe-blog.net>.
@gerhard: This is the right to go ;-)
Am 02.12.14 15:08, schrieb Gerhard Petracek:
> @oliver:
> deltaspike allows to change the predefined ordinal (per config-source) by
> adding an entry to the data visible to the config-source.
> -> you can change the predefined priority via the config itself.
>
> regards,
> gerhard
>
>
>
> 2014-12-02 14:41 GMT+01:00 Oliver B. Fischer <o....@swe-blog.net>:
>
>> @Gerhard: I saw it in the API documents of Deltaspike. I think the user of
>> Tamaya should be able to decide which provider has the highest priority.
>>
>> Bye,
>>
>> Oliver
>>
>>
>> Am 01.12.14 19:26, schrieb Gerhard Petracek:
>>
>>> @oliver:
>>> i'm not sure if you familiar with the ordinal-approach provided by
>>> deltaspike.
>>>
>>> regards,
>>> gerhard
>>>
>>>
>> --
>> N Oliver B. Fischer
>> A Schönhauser Allee 64, 10437 Berlin, Deutschland/Germany
>> P +49 30 44793251
>> M +49 178 7903538
>> E o.b.fischer@swe-blog.net
>> S oliver.b.fischer
>> J oliver.b.fischer@jabber.org
>> X http://xing.to/obf
>>
>>
--
N Oliver B. Fischer
A Schönhauser Allee 64, 10437 Berlin, Deutschland/Germany
P +49 30 44793251
M +49 178 7903538
E o.b.fischer@swe-blog.net
S oliver.b.fischer
J oliver.b.fischer@jabber.org
X http://xing.to/obf
Re: Use Case 1: Read simple properties and get values.
Posted by Gerhard Petracek <ge...@gmail.com>.
@oliver:
deltaspike allows to change the predefined ordinal (per config-source) by
adding an entry to the data visible to the config-source.
-> you can change the predefined priority via the config itself.
regards,
gerhard
2014-12-02 14:41 GMT+01:00 Oliver B. Fischer <o....@swe-blog.net>:
> @Gerhard: I saw it in the API documents of Deltaspike. I think the user of
> Tamaya should be able to decide which provider has the highest priority.
>
> Bye,
>
> Oliver
>
>
> Am 01.12.14 19:26, schrieb Gerhard Petracek:
>
>> @oliver:
>> i'm not sure if you familiar with the ordinal-approach provided by
>> deltaspike.
>>
>> regards,
>> gerhard
>>
>>
> --
> N Oliver B. Fischer
> A Schönhauser Allee 64, 10437 Berlin, Deutschland/Germany
> P +49 30 44793251
> M +49 178 7903538
> E o.b.fischer@swe-blog.net
> S oliver.b.fischer
> J oliver.b.fischer@jabber.org
> X http://xing.to/obf
>
>
Re: Use Case 1: Read simple properties and get values.
Posted by "Oliver B. Fischer" <o....@swe-blog.net>.
@Gerhard: I saw it in the API documents of Deltaspike. I think the user
of Tamaya should be able to decide which provider has the highest priority.
Bye,
Oliver
Am 01.12.14 19:26, schrieb Gerhard Petracek:
> @oliver:
> i'm not sure if you familiar with the ordinal-approach provided by
> deltaspike.
>
> regards,
> gerhard
>
--
N Oliver B. Fischer
A Schönhauser Allee 64, 10437 Berlin, Deutschland/Germany
P +49 30 44793251
M +49 178 7903538
E o.b.fischer@swe-blog.net
S oliver.b.fischer
J oliver.b.fischer@jabber.org
X http://xing.to/obf
Re: Use Case 1: Read simple properties and get values.
Posted by Gerhard Petracek <ge...@gmail.com>.
@oliver:
i'm not sure if you familiar with the ordinal-approach provided by
deltaspike.
regards,
gerhard
2014-12-01 19:20 GMT+01:00 Werner Keil <we...@gmail.com>:
> If you get one by app, is there any form of "context" you'd pass to such
> factory method?
>
> Currency.getInstance() returns exactly one singleton instance of a Currency
> class (otherwise has no constructor either) for a given currency code.
> While Money.of() in JSR 354 RI returns totally different instances
> depending on the combination of (nearly unlimited) different numbers and
> currency codes. 354 tries to broaden the definition of Currency, but if you
> get exactly one distinct instance per VM/app that's a singleton IMHO even
> if you may call the same application multiple times.
>
> On Mon, Dec 1, 2014 at 7:12 PM, Romain Manni-Bucau <rm...@gmail.com>
> wrote:
>
> > Hmm,
> >
> > for me getInstance() = singleton in term of instance where
> > Configuration will be all but a singleton IMO (you'll get at least one
> > by app and surely a new instance each time you call it) no?
> >
> >
> > Romain Manni-Bucau
> > @rmannibucau
> > http://www.tomitribe.com
> > http://rmannibucau.wordpress.com
> > https://github.com/rmannibucau
> >
> >
> > 2014-12-01 18:56 GMT+01:00 Werner Keil <we...@gmail.com>:
> > > Hi,
> > >
> > > Adding to the question of convenience factories, there is no such thing
> > as
> > > "naming convention" by Stephen Colebourne or JSR 310. In fact, it
> > violates
> > > or bends almost every one of them in itself, so a suggestion like
> > > Configuration.current() would sound very similar to the
> > LocalDateTime.now()
> > > ones in 310.
> > > For several other cases of() or longer variations (like ofMilli()
> > ofNanos()
> > > etc.;-O) are used, while static factories from strings similar to what
> > JSR
> > > 354 adopted are called parse(String).
> > >
> > > Josh Bloch defined a clear distinction between what he then in most
> cases
> > > (except EnumSet, that's where he started using of() so Josh also
> > "invented"
> > > that while it violated some of his earlier naming conventions;-D)
> called
> > > valueOf() and getInstance(), see
> > >
> >
> http://blog.codefront.net/2003/06/21/java-tip-2-static-factory-methods-vs-constructors/
> > > getInstance() returns a singleton, either the only instance for this
> type
> > > of object or the only instance for a distinct code or enum (see
> > > java.util.Currency)
> > >
> > > Very recent APIs and JSRs like MEEP 8 make a clear distinction, and
> > classes
> > > like
> > >
> >
> https://docs.oracle.com/javame/8.0/api/meep/api/javax/microedition/event/EventManager.html
> > > clearly explain that, too. In other places ME 8 uses of() where
> > appropriate.
> > > So at least getInstance() is neither outdated nor wrong, it just
> depends
> > on
> > > what you return.
> > >
> > > If Configuration returns just a default instance then
> > > Configuration.getInstance() seems appropriate.
> > >
> > >
> > > Werner Keil | JCP Executive Committee Member, JSR 363 Co Spec Lead |
> > > Eclipse UOMo Lead, Babel Language Champion | Apache Committer
> > >
> > > Twitter @wernerkeil | @UnitAPI | @JSR354 | @DeviceMap | #EclipseUOMo |
> > > #Java_Social
> > > | #DevOps
> > > Skype werner.keil | Google+ gplus.to/wernerkeil
> > >
> > > On Mon, Dec 1, 2014 at 6:31 PM, Oliver B. Fischer <
> > o.b.fischer@swe-blog.net>
> > > wrote:
> > >
> > >> Hi,
> > >>
> > >> for me the most simple use case is
> > >>
> > >> Configuration conf = new Configuration();
> > >> String value = conf.get("key")
> > >>
> > >> And this use case is already very complex under the hood.
> > >>
> > >> Before discussing other details we have to decide how
> PropertyProviders
> > >> are activated.
> > >>
> > >> I would like to have the following possibilites:
> > >>
> > >> 1. Tamaya activates all PropertyProviders found in the classpath and
> > >> activated via SPI.
> > >> 2. Tamaya activates only a explicitly named list of Property providers
> > >> 3. I have the ability to control the order in which the property
> > solution
> > >> will be performed
> > >>
> > >> Bye,
> > >>
> > >> Oliver
> > >>
> > >>
> > >> Am 01.12.14 17:54, schrieb Romain Manni-Bucau:
> > >>
> > >>> Configuration.current() sounds easier to understand first time you
> see
> > >>> it. I like Configuration.newInstance() if that's really what it does
> > >>> (ie no caching by classloader or anything else).
> > >>>
> > >>>
> > >>> Romain Manni-Bucau
> > >>> @rmannibucau
> > >>> http://www.tomitribe.com
> > >>> http://rmannibucau.wordpress.com
> > >>> https://github.com/rmannibucau
> > >>>
> > >>>
> > >>> 2014-12-01 17:42 GMT+01:00 Anatole Tresch <at...@gmail.com>:
> > >>>
> > >>>> There is a naming concept from Stephen Colebourne when to use of,
> > from,
> > >>>> with. I try to lookup the link later, see also jsr 310 and 354.
> > >>>> getInstance, valueOf are considered to be outdated for modern api
> > design.
> > >>>>
> > >>>> Adding a helper, why? Another artifact a user must know, makes
> sense,
> > >>>> where
> > >>>> you have a huge acces api IMO (see PropertyProviders where the
> factory
> > >>>> methods are not part of the PropertyProvider interface. For
> > >>>> Configuration I
> > >>>> prefer having sn intuitive simple/single access...
> > >>>>
> > >>>> Nevertheless I would like to encourage you to make a concrete
> proposal
> > >>>> how
> > >>>> would name things, so we can compare what your idea of fluent is ;)
> > >>>>
> > >>>> -anatole
> > >>>> Gerhard Petracek <ge...@gmail.com> schrieb am Mo., 1.
> Dez.
> > >>>> 2014
> > >>>> um 17:24:
> > >>>>
> > >>>> 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
> > >>>>> <anatole.tresch@credit-suisse.
> > >>>>> com
> > >>>>>
> > >>>>>> :
> > >>>>>> 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:gerhard.petracek@gmail.com]
> > >>>>>> Sent: Montag, 1. Dezember 2014 14:30
> > >>>>>> To: dev@tamaya.incubator.apache.org
> > >>>>>> 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 <an...@apache.org>:
> > >>>>>>
> > >>>>>> 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 <ge...@gmail.com> 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 <
> > rmannibucau@gmail.com
> > >>>>>>>>
> > >>>>>>> :
> > >>>>>>
> > >>>>>>> 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 <anatole@apache.org
> >:
> > >>>>>>>>>
> > >>>>>>>>>> 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
> > >>>>>>>>>>
> > >>>>>>>>>>
> > >> --
> > >> N Oliver B. Fischer
> > >> A Schönhauser Allee 64, 10437 Berlin, Deutschland/Germany
> > >> P +49 30 44793251
> > >> M +49 178 7903538
> > >> E o.b.fischer@swe-blog.net
> > >> S oliver.b.fischer
> > >> J oliver.b.fischer@jabber.org
> > >> X http://xing.to/obf
> > >>
> > >>
> >
>
RE: Use Case 1: Read simple properties and get values.
Posted by "Tresch, Anatole " <an...@credit-suisse.com>.
Hi Oli
adding information also to my previous mail I try to provide you an example:
PropertyProvider cfg = PropertyProviders.fromPath(AggregationPolicy.EXCEPTION, "META-INF/cfg/*.xml", "META-INF/cfg/*.ini");
PropertyProvider messages = PropertyProviders.fromPath(AggregationPolicy.EXCEPTION, "META-INF/cfg/res/*.xml", "META-INF/cfg/res/*.properties");
PropertyProvider dbEntries = PropertyProviders.fromPath(AggregationPolicy.LOG_DUPLICATES, "jdbc:myCfgDatasource.dbformat1");
Configuration finalConfig = PropertyProviders.aggregate(AggregationPolicy.IGNORE_DUPLICATES, PropertyProviders.prefix(messages, "msg."), dbEntries, cfg).toConfiguration();
In this case we support different config formats in both cases (sub providers)...
Does that help?
-----Original Message-----
From: Oliver B. Fischer [mailto:o.b.fischer@swe-blog.net]
Sent: Mittwoch, 3. Dezember 2014 08:37
To: dev@tamaya.incubator.apache.org
Subject: Re: Use Case 1: Read simple properties and get values.
So if a new ConfigFormat is required for reading a different data
source: What is the difference between ConfigFormat and
PropertyProvider? Isn't it the same?
IMHO we have to discuss the overall architecture a least a little bit to
see which parts exist, how they interact and who is responsible for what.
Oliver
Am 03.12.14 01:15, schrieb Anatole Tresch:
> BTW, supporting a new ConfigFormat is trivial: implementing ConfigurationFormat
> and register it with as component, by default using the ServiceLoader.
> Then you only to read the file and you are done ;)
>
> 2014-12-01 19:48 GMT+01:00 Gerhard Petracek <ge...@gmail.com>:
>
>
--
N Oliver B. Fischer
A Schönhauser Allee 64, 10437 Berlin, Deutschland/Germany
P +49 30 44793251
M +49 178 7903538
E o.b.fischer@swe-blog.net
S oliver.b.fischer
J oliver.b.fischer@jabber.org
X http://xing.to/obf
Re: Use Case 1: Read simple properties and get values.
Posted by Romain Manni-Bucau <rm...@gmail.com>.
I guess we can have this format: reader:format:url but have defaults
for reader and format. We'll surely change the : delimiter to avoid
conflicts (http://...) but it is not a blocker IMO
Romain Manni-Bucau
@rmannibucau
http://www.tomitribe.com
http://rmannibucau.wordpress.com
https://github.com/rmannibucau
2014-12-04 14:20 GMT+01:00 Anatole Tresch <at...@gmail.com>:
> Hi Oliver
>
> This is possible. It will require the readers to determine if an expression
> is targeting them, but makes it easier for users. Does anybody see a
> technical issue that auto detection does not work?
>
> A
>
>
> Oliver B. Fischer <o....@swe-blog.net> schrieb am Do., 4. Dez. 2014
> um 13:32:
>
>> I don't like this reader:format:whatever thing. IMHO it is to explicit.
>> I would like to be able to write something like
>>
>> fromPath("/etc/app/conf.json")
>>
>> Tamaya should figure out that this points to a file called conf.json in
>> the directory /etc/app. Then Tamaya should pass it to it reads until the
>> first of them accepts it and claims to be able to parse it.
>>
>> Variants of the given example are
>>
>> fromPath("file:///etc/app/conf.json")
>> fromPath("ftp://u:p@host:/config.json)
>> fromPath("https://host:9999/config.yaml")
>>
>> WDYT?
>>
>> Oliver
>>
>> Am 03.12.14 13:08, schrieb Tresch, Anatole:
>> > PropertyProvider prov = PropertyProviders.fromPath("reader:whatever");
>> >
>> >
>>
>> --
>> N Oliver B. Fischer
>> A Schönhauser Allee 64, 10437 Berlin, Deutschland/Germany
>> P +49 30 44793251
>> M +49 178 7903538
>> E o.b.fischer@swe-blog.net
>> S oliver.b.fischer
>> J oliver.b.fischer@jabber.org
>> X http://xing.to/obf
>>
>>
Re: Use Case 1: Read simple properties and get values.
Posted by Anatole Tresch <at...@gmail.com>.
Hi Oliver
This is possible. It will require the readers to determine if an expression
is targeting them, but makes it easier for users. Does anybody see a
technical issue that auto detection does not work?
A
Oliver B. Fischer <o....@swe-blog.net> schrieb am Do., 4. Dez. 2014
um 13:32:
> I don't like this reader:format:whatever thing. IMHO it is to explicit.
> I would like to be able to write something like
>
> fromPath("/etc/app/conf.json")
>
> Tamaya should figure out that this points to a file called conf.json in
> the directory /etc/app. Then Tamaya should pass it to it reads until the
> first of them accepts it and claims to be able to parse it.
>
> Variants of the given example are
>
> fromPath("file:///etc/app/conf.json")
> fromPath("ftp://u:p@host:/config.json)
> fromPath("https://host:9999/config.yaml")
>
> WDYT?
>
> Oliver
>
> Am 03.12.14 13:08, schrieb Tresch, Anatole:
> > PropertyProvider prov = PropertyProviders.fromPath("reader:whatever");
> >
> >
>
> --
> N Oliver B. Fischer
> A Schönhauser Allee 64, 10437 Berlin, Deutschland/Germany
> P +49 30 44793251
> M +49 178 7903538
> E o.b.fischer@swe-blog.net
> S oliver.b.fischer
> J oliver.b.fischer@jabber.org
> X http://xing.to/obf
>
>
Re: Use Case 1: Read simple properties and get values.
Posted by "Oliver B. Fischer" <o....@swe-blog.net>.
I don't like this reader:format:whatever thing. IMHO it is to explicit.
I would like to be able to write something like
fromPath("/etc/app/conf.json")
Tamaya should figure out that this points to a file called conf.json in
the directory /etc/app. Then Tamaya should pass it to it reads until the
first of them accepts it and claims to be able to parse it.
Variants of the given example are
fromPath("file:///etc/app/conf.json")
fromPath("ftp://u:p@host:/config.json)
fromPath("https://host:9999/config.yaml")
WDYT?
Oliver
Am 03.12.14 13:08, schrieb Tresch, Anatole:
> PropertyProvider prov = PropertyProviders.fromPath("reader:whatever");
>
>
--
N Oliver B. Fischer
A Schönhauser Allee 64, 10437 Berlin, Deutschland/Germany
P +49 30 44793251
M +49 178 7903538
E o.b.fischer@swe-blog.net
S oliver.b.fischer
J oliver.b.fischer@jabber.org
X http://xing.to/obf
Re: Use Case 1: Read simple properties and get values.
Posted by "Oliver B. Fischer" <o....@swe-blog.net>.
Ok, so it makes sense to split it up in two parts.
Am 03.12.14 12:13, schrieb Anatole Tresch:
> Far this is not the same. A provider defines where configuration is read.
> The format defines how. Even properties files may lay at multiple
> locations, could be locally , classpath, blobs, remotedly, ... I want to
> support users that they are able to read configuration with minimal coding
> required.
>
> This model is flexible and is the reason we reading in uc1 is so simple and
> will be similar easy also for enterprise specific custom formats. Companies
> will never change their existing formats just to use Tamaya...
> Romain Manni-Bucau <rm...@gmail.com> schrieb am Mi., 3. Dez. 2014 um
> 11:45:
>
>> +1, ConfigFormat or PropertyProvider shouldn't be there.
>>
>>
>> Romain Manni-Bucau
>> @rmannibucau
>> http://www.tomitribe.com
>> http://rmannibucau.wordpress.com
>> https://github.com/rmannibucau
>>
>>
>> 2014-12-03 8:37 GMT+01:00 Oliver B. Fischer <o....@swe-blog.net>:
>> it
>> see
--
N Oliver B. Fischer
A Schönhauser Allee 64, 10437 Berlin, Deutschland/Germany
P +49 30 44793251
M +49 178 7903538
E o.b.fischer@swe-blog.net
S oliver.b.fischer
J oliver.b.fischer@jabber.org
X http://xing.to/obf
RE: Use Case 1: Read simple properties and get values.
Posted by "Tresch, Anatole " <an...@credit-suisse.com>.
BTW: turning PropertyProviders into a builder I think could be a good idea...
So one could write something like
PropertyProvider provider = PropertyProviderBuilder.create("myconfig")
.add("classpath*:ksdhksdh")
.with(AggregationPolicy.OVERRIDE)
.add ("file:myfileLocation")
.aggregate(AggregationPolicy. OVERRIDE,
PropertyProviderBuilder.create("dbConf").add("jdbc:myConfig.format1?dialect=oracle")
.with(AggregationPolicy.OVERRIDE).addSystemProperties().build())
.build();
WDYT?
-----Original Message-----
From: Werner Keil [mailto:werner.keil@gmail.com]
Sent: Mittwoch, 3. Dezember 2014 13:16
To: dev@tamaya.incubator.apache.org
Subject: Re: Use Case 1: Read simple properties and get values.
I would go a bit beyond a simple "ConfigFormat" based on the experience
with Multiconf in a very large Cloud environment.
What was used there aside from obvious (JSON) data exchange or output one
might consider "format" is more towards "ConfigReport" or whatever you
might call that.
We used Asciidoc and with several Asciidoc and Asciidoctor affine members
here I guess that could also work for Tamya;-)
Werner
On Wed, Dec 3, 2014 at 1:08 PM, Tresch, Anatole <
anatole.tresch@credit-suisse.com> wrote:
> @Romain
>
> The concept is - as I said - that you can describe, from which source a
> configuration should be read. This descriptions goes first to a reader,
> which knows how to resolve the location and resolves to a number of
> URIs/input streams.
> These input streams can come in multiple formats (even mixed).
> Configuration Format and reader are the abstraction so you can write
> basically something like
>
> PropertyProvider prov = PropertyProviders.fromPath("reader:whatever");
>
> In the example above you can declaratively define a PropertyProvider, fast
> and easy, and you (by default) do not have to care on the format (BTW it is
> possible that multiple formats register for the same file ending).
> Removing ConfigFormat means, that you
> - only support a limited set of formats, or
> - must implement format parsing logic yourself also for the most common
> cases, and
> - create additional implementation dependencies on the format parsing code
> - and probably you have to duplicate the logic that converts an
> InputStream into a Map<String,String>/ProeprtyProvider.
>
> Finally: the project is internally split up into an API part and an
> implementation part. ConfigFormat is not part of the API (you typically
> will not code against it). If you have really want to write all your
> providers yourself, you can do that. Nobody prevents you doing so, but
> please allow other maybe less sophisticated users to benefit from provided
> features, so they do not have to write them themselves.
> And once more, this feature was a great help for supporting muiltiple
> formats such as .properties, .xml (xml-properties), .ini (ini-Files). I do
> not see any reason we should remove something that has proven to work so
> nicely.
>
> Cheers,
> Anatole
>
>
>
> -----Original Message-----
> From: Romain Manni-Bucau [mailto:rmannibucau@gmail.com]
> Sent: Mittwoch, 3. Dezember 2014 12:18
> To: dev@tamaya.incubator.apache.org
> Subject: Re: Use Case 1: Read simple properties and get values.
>
> I don't fully agree. Where is passed through PropertyProviders so
> basically we don't need this format abstraction. Providers should just
> check it can read it or not. having such an indirection already makes
> the framework "apparently" complex enough to not be used from my point
> of view.
>
> Implementing a custom provider to read what you want is generally
> trivial enough to be where the extenisbility is.
>
>
> Romain Manni-Bucau
> @rmannibucau
> http://www.tomitribe.com
> http://rmannibucau.wordpress.com
> https://github.com/rmannibucau
>
>
> 2014-12-03 12:13 GMT+01:00 Anatole Tresch <at...@gmail.com>:
> > Far this is not the same. A provider defines where configuration is read.
> > The format defines how. Even properties files may lay at multiple
> > locations, could be locally , classpath, blobs, remotedly, ... I want to
> > support users that they are able to read configuration with minimal
> coding
> > required.
> >
> > This model is flexible and is the reason we reading in uc1 is so simple
> and
> > will be similar easy also for enterprise specific custom formats.
> Companies
> > will never change their existing formats just to use Tamaya...
> > Romain Manni-Bucau <rm...@gmail.com> schrieb am Mi., 3. Dez. 2014
> um
> > 11:45:
> >
> >> +1, ConfigFormat or PropertyProvider shouldn't be there.
> >>
> >>
> >> Romain Manni-Bucau
> >> @rmannibucau
> >> http://www.tomitribe.com
> >> http://rmannibucau.wordpress.com
> >> https://github.com/rmannibucau
> >>
> >>
> >> 2014-12-03 8:37 GMT+01:00 Oliver B. Fischer <o....@swe-blog.net>:
> >> > So if a new ConfigFormat is required for reading a different data
> source:
> >> > What is the difference between ConfigFormat and PropertyProvider?
> Isn't
> >> it
> >> > the same?
> >> >
> >> > IMHO we have to discuss the overall architecture a least a little bit
> to
> >> see
> >> > which parts exist, how they interact and who is responsible for what.
> >> >
> >> > Oliver
> >> >
> >> > Am 03.12.14 01:15, schrieb Anatole Tresch:
> >> >>
> >> >> BTW, supporting a new ConfigFormat is trivial: implementing
> >> >> ConfigurationFormat
> >> >> and register it with as component, by default using the
> ServiceLoader.
> >> >> Then you only to read the file and you are done ;)
> >> >>
> >> >> 2014-12-01 19:48 GMT+01:00 Gerhard Petracek <
> gerhard.petracek@gmail.com
> >> >:
> >> >>
> >> >>
> >> >
> >> > --
> >> > N Oliver B. Fischer
> >> > A Schönhauser Allee 64, 10437 Berlin, Deutschland/Germany
> >> > P +49 30 44793251
> >> > M +49 178 7903538
> >> > E o.b.fischer@swe-blog.net
> >> > S oliver.b.fischer
> >> > J oliver.b.fischer@jabber.org
> >> > X http://xing.to/obf
> >> >
> >>
>
Re: Use Case 1: Read simple properties and get values.
Posted by Romain Manni-Bucau <rm...@gmail.com>.
here some samples i'd expect:
- http:properties:http://....
- https:xml:https://....
- classpath:yaml:/foo/bar.yml
- custom:json:myapp # and use a company convention like /foo/bar/app/myapp.json
etc...
Romain Manni-Bucau
@rmannibucau
http://www.tomitribe.com
http://rmannibucau.wordpress.com
https://github.com/rmannibucau
2014-12-03 14:35 GMT+01:00 Werner Keil <we...@gmail.com>:
> What would "reader" or "format" have to to here in a fromPath() method?
> That's more a "reader" or "loader" thing, some may call it "parsing" but
> I'd say that only makes sense if you have a relatively small string, not
> broader source.
>
> It may be a little bit simpler given the input format is only W3C DDR
> compliant XML data, but looking at recently graduated DeviceMap, the
> ".next" Java client offers a variety of "resource loaders" either from
> within an archive, a URL or as file in a file system:
> http://svn.apache.org/repos/asf/devicemap/trunk/devicemap/java/classifier/src/main/java/org/apache/devicemap/loader/
>
> Reporting and output or "formatting" would be something different IMHO, not
> to be mixed with loader or reader.
>
> Werner
>
> On Wed, Dec 3, 2014 at 2:24 PM, Romain Manni-Bucau <rm...@gmail.com>
> wrote:
>
>> Hmm, there is something fishy fo rme in this reader/format/... discussion.
>>
>> From your description I would expect:
>> PropertyProviders.fromPath("reader[:format]whatever"); to be
>> supported. And if it is what there is behind the scene I would like it
>> to be part of the API.
>>
>> One simple use case: support properties, yaml, ini, xml or whatever
>> just be called myconfig.conf or myconfig.config or any other
>> extension.
>>
>> I agree we can guess the format from the extension often enough to not
>> force its usage but since it is important as you mentionned it I think
>> we need to accept it is part of the API.
>>
>> wdyt?
>>
>>
>>
>> Romain Manni-Bucau
>> @rmannibucau
>> http://www.tomitribe.com
>> http://rmannibucau.wordpress.com
>> https://github.com/rmannibucau
>>
>>
>> 2014-12-03 14:02 GMT+01:00 Werner Keil <we...@gmail.com>:
>> > The Asciidoc reporting is not part of the Open Source project AFAIK, but
>> > here's Multiconf on GitHub:
>> > https://github.com/lhupfeldt/multiconf
>> >
>> > For those familiar with scripting languages like Groovy Python should not
>> > feel too strange;-)
>> > Here a quick example on how it can be used:
>> >
>> > # Define environments
>> >
>> > # Use EnvFactory() to create environment or group of environments
>> > ef = EnvFactory()
>> >
>> > # We have five environments and we define them here
>> > devlocal = ef.Env('devlocal')
>> > devi = ef.Env('devi')
>> > devs = ef.Env('devs')
>> > preprod = ef.Env('preprod')
>> > prod = ef.Env('prod')
>> >
>> > # Grouping environments per their roles
>> > g_dev = ef.EnvGroup('g_dev', devlocal, devi, devs)
>> > g_prod = ef.EnvGroup('g_prod', preprod, prod)
>> >
>> >
>> > # This function is used to describe all environments and return an
>> > instantiated environment
>> > # configuration for environment with name 'env_name', which is passed as
>> > parameter
>> > def conf(env_name):
>> > env = ef.env(env_name)
>> >
>> > # This will define a weblogic configuration for all environments
>> > defined above
>> > # But the result of execution of conf() will be the setting for
>> > environment
>> > # passed as argument 'env_name'
>> > # Use EnvFactory 'ef' to define the required/allowed environments
>> > # The 'weblogic_config' class is defined in framework.py
>> > with weblogic_config(env, ef) as dc:
>> > # Set domain base port number for different environments.
>> > # Domain base port is used as base to calculate port offsets
>> > # Here we're saying that Weblogic in g_prod group will have
>> > # attribute base_port set to 7000, and each of the development
>> > environments
>> > # will have unique base_port
>> > dc.setattr('base_port', g_prod=7000, devi=7100, devs=7200,
>> > devlocal=7300)
>> > [...]
>> >
>> > The "DSL" for configuration is almost entirely done in Python, thus could
>> > be compared to annotated Java code where we support that. Multiconf
>> > generates al sorts of files like XML (for WLS and other containers) but
>> > configuration itself is barely done or overridden via XML.
>> >
>> > We may have a slightly broader scope but some aspects and goals are
>> pretty
>> > similar.
>> >
>> > Werner
>> >
>> > On Wed, Dec 3, 2014 at 1:19 PM, Tresch, Anatole <
>> > anatole.tresch@credit-suisse.com> wrote:
>> >
>> >> Can you explain (or post a link) that in more detail, people might not
>> now
>> >> much about Multiconf...
>> >>
>> >> -----Original Message-----
>> >> From: Werner Keil [mailto:werner.keil@gmail.com]
>> >> Sent: Mittwoch, 3. Dezember 2014 13:16
>> >> To: dev@tamaya.incubator.apache.org
>> >> Subject: Re: Use Case 1: Read simple properties and get values.
>> >>
>> >> I would go a bit beyond a simple "ConfigFormat" based on the experience
>> >> with Multiconf in a very large Cloud environment.
>> >> What was used there aside from obvious (JSON) data exchange or output
>> one
>> >> might consider "format" is more towards "ConfigReport" or whatever you
>> >> might call that.
>> >> We used Asciidoc and with several Asciidoc and Asciidoctor affine
>> members
>> >> here I guess that could also work for Tamya;-)
>> >>
>> >> Werner
>> >>
>> >> On Wed, Dec 3, 2014 at 1:08 PM, Tresch, Anatole <
>> >> anatole.tresch@credit-suisse.com> wrote:
>> >>
>> >> > @Romain
>> >> >
>> >> > The concept is - as I said - that you can describe, from which source
>> a
>> >> > configuration should be read. This descriptions goes first to a
>> reader,
>> >> > which knows how to resolve the location and resolves to a number of
>> >> > URIs/input streams.
>> >> > These input streams can come in multiple formats (even mixed).
>> >> > Configuration Format and reader are the abstraction so you can write
>> >> > basically something like
>> >> >
>> >> > PropertyProvider prov = PropertyProviders.fromPath("reader:whatever");
>> >> >
>> >> > In the example above you can declaratively define a PropertyProvider,
>> >> fast
>> >> > and easy, and you (by default) do not have to care on the format (BTW
>> it
>> >> is
>> >> > possible that multiple formats register for the same file ending).
>> >> > Removing ConfigFormat means, that you
>> >> > - only support a limited set of formats, or
>> >> > - must implement format parsing logic yourself also for the most
>> common
>> >> > cases, and
>> >> > - create additional implementation dependencies on the format parsing
>> >> code
>> >> > - and probably you have to duplicate the logic that converts an
>> >> > InputStream into a Map<String,String>/ProeprtyProvider.
>> >> >
>> >> > Finally: the project is internally split up into an API part and an
>> >> > implementation part. ConfigFormat is not part of the API (you
>> typically
>> >> > will not code against it). If you have really want to write all your
>> >> > providers yourself, you can do that. Nobody prevents you doing so, but
>> >> > please allow other maybe less sophisticated users to benefit from
>> >> provided
>> >> > features, so they do not have to write them themselves.
>> >> > And once more, this feature was a great help for supporting muiltiple
>> >> > formats such as .properties, .xml (xml-properties), .ini (ini-Files).
>> I
>> >> do
>> >> > not see any reason we should remove something that has proven to work
>> so
>> >> > nicely.
>> >> >
>> >> > Cheers,
>> >> > Anatole
>> >> >
>> >> >
>> >> >
>> >> > -----Original Message-----
>> >> > From: Romain Manni-Bucau [mailto:rmannibucau@gmail.com]
>> >> > Sent: Mittwoch, 3. Dezember 2014 12:18
>> >> > To: dev@tamaya.incubator.apache.org
>> >> > Subject: Re: Use Case 1: Read simple properties and get values.
>> >> >
>> >> > I don't fully agree. Where is passed through PropertyProviders so
>> >> > basically we don't need this format abstraction. Providers should just
>> >> > check it can read it or not. having such an indirection already makes
>> >> > the framework "apparently" complex enough to not be used from my point
>> >> > of view.
>> >> >
>> >> > Implementing a custom provider to read what you want is generally
>> >> > trivial enough to be where the extenisbility is.
>> >> >
>> >> >
>> >> > Romain Manni-Bucau
>> >> > @rmannibucau
>> >> > http://www.tomitribe.com
>> >> > http://rmannibucau.wordpress.com
>> >> > https://github.com/rmannibucau
>> >> >
>> >> >
>> >> > 2014-12-03 12:13 GMT+01:00 Anatole Tresch <at...@gmail.com>:
>> >> > > Far this is not the same. A provider defines where configuration is
>> >> read.
>> >> > > The format defines how. Even properties files may lay at multiple
>> >> > > locations, could be locally , classpath, blobs, remotedly, ... I
>> want
>> >> to
>> >> > > support users that they are able to read configuration with minimal
>> >> > coding
>> >> > > required.
>> >> > >
>> >> > > This model is flexible and is the reason we reading in uc1 is so
>> simple
>> >> > and
>> >> > > will be similar easy also for enterprise specific custom formats.
>> >> > Companies
>> >> > > will never change their existing formats just to use Tamaya...
>> >> > > Romain Manni-Bucau <rm...@gmail.com> schrieb am Mi., 3. Dez.
>> >> 2014
>> >> > um
>> >> > > 11:45:
>> >> > >
>> >> > >> +1, ConfigFormat or PropertyProvider shouldn't be there.
>> >> > >>
>> >> > >>
>> >> > >> Romain Manni-Bucau
>> >> > >> @rmannibucau
>> >> > >> http://www.tomitribe.com
>> >> > >> http://rmannibucau.wordpress.com
>> >> > >> https://github.com/rmannibucau
>> >> > >>
>> >> > >>
>> >> > >> 2014-12-03 8:37 GMT+01:00 Oliver B. Fischer <
>> o.b.fischer@swe-blog.net
>> >> >:
>> >> > >> > So if a new ConfigFormat is required for reading a different data
>> >> > source:
>> >> > >> > What is the difference between ConfigFormat and PropertyProvider?
>> >> > Isn't
>> >> > >> it
>> >> > >> > the same?
>> >> > >> >
>> >> > >> > IMHO we have to discuss the overall architecture a least a little
>> >> bit
>> >> > to
>> >> > >> see
>> >> > >> > which parts exist, how they interact and who is responsible for
>> >> what.
>> >> > >> >
>> >> > >> > Oliver
>> >> > >> >
>> >> > >> > Am 03.12.14 01:15, schrieb Anatole Tresch:
>> >> > >> >>
>> >> > >> >> BTW, supporting a new ConfigFormat is trivial: implementing
>> >> > >> >> ConfigurationFormat
>> >> > >> >> and register it with as component, by default using the
>> >> > ServiceLoader.
>> >> > >> >> Then you only to read the file and you are done ;)
>> >> > >> >>
>> >> > >> >> 2014-12-01 19:48 GMT+01:00 Gerhard Petracek <
>> >> > gerhard.petracek@gmail.com
>> >> > >> >:
>> >> > >> >>
>> >> > >> >>
>> >> > >> >
>> >> > >> > --
>> >> > >> > N Oliver B. Fischer
>> >> > >> > A Schönhauser Allee 64, 10437 Berlin, Deutschland/Germany
>> >> > >> > P +49 30 44793251
>> >> > >> > M +49 178 7903538
>> >> > >> > E o.b.fischer@swe-blog.net
>> >> > >> > S oliver.b.fischer
>> >> > >> > J oliver.b.fischer@jabber.org
>> >> > >> > X http://xing.to/obf
>> >> > >> >
>> >> > >>
>> >> >
>> >>
>>
Re: Use Case 1: Read simple properties and get values.
Posted by Werner Keil <we...@gmail.com>.
Makes sense, that is also why you don't find the reporting part in the core
Open Source project of Multiconf ;-)
On Wed, Dec 3, 2014 at 2:47 PM, Anatole Tresch <at...@gmail.com> wrote:
> Hmm. Pros abd cons: pro format is important, cons: i tried to minimize the
> api: reader:something -> the reader can be implemented in any way. The
> implementation can decide, if (explit) formats are supported, eg:
> reader:[format]foo. Therefore I moved the format part to the implementation
> completely...
>
> Other opinions?
> Werner Keil <we...@gmail.com> schrieb am Mi., 3. Dez. 2014 um 14:35:
>
> > What would "reader" or "format" have to to here in a fromPath() method?
> > That's more a "reader" or "loader" thing, some may call it "parsing" but
> > I'd say that only makes sense if you have a relatively small string, not
> > broader source.
> >
> > It may be a little bit simpler given the input format is only W3C DDR
> > compliant XML data, but looking at recently graduated DeviceMap, the
> > ".next" Java client offers a variety of "resource loaders" either from
> > within an archive, a URL or as file in a file system:
> > http://svn.apache.org/repos/asf/devicemap/trunk/devicemap/
> > java/classifier/src/main/java/org/apache/devicemap/loader/
> >
> > Reporting and output or "formatting" would be something different IMHO,
> not
> > to be mixed with loader or reader.
> >
> > Werner
> >
> > On Wed, Dec 3, 2014 at 2:24 PM, Romain Manni-Bucau <
> rmannibucau@gmail.com>
> > wrote:
> >
> > > Hmm, there is something fishy fo rme in this reader/format/...
> > discussion.
> > >
> > > From your description I would expect:
> > > PropertyProviders.fromPath("reader[:format]whatever"); to be
> > > supported. And if it is what there is behind the scene I would like it
> > > to be part of the API.
> > >
> > > One simple use case: support properties, yaml, ini, xml or whatever
> > > just be called myconfig.conf or myconfig.config or any other
> > > extension.
> > >
> > > I agree we can guess the format from the extension often enough to not
> > > force its usage but since it is important as you mentionned it I think
> > > we need to accept it is part of the API.
> > >
> > > wdyt?
> > >
> > >
> > >
> > > Romain Manni-Bucau
> > > @rmannibucau
> > > http://www.tomitribe.com
> > > http://rmannibucau.wordpress.com
> > > https://github.com/rmannibucau
> > >
> > >
> > > 2014-12-03 14:02 GMT+01:00 Werner Keil <we...@gmail.com>:
> > > > The Asciidoc reporting is not part of the Open Source project AFAIK,
> > but
> > > > here's Multiconf on GitHub:
> > > > https://github.com/lhupfeldt/multiconf
> > > >
> > > > For those familiar with scripting languages like Groovy Python should
> > not
> > > > feel too strange;-)
> > > > Here a quick example on how it can be used:
> > > >
> > > > # Define environments
> > > >
> > > > # Use EnvFactory() to create environment or group of environments
> > > > ef = EnvFactory()
> > > >
> > > > # We have five environments and we define them here
> > > > devlocal = ef.Env('devlocal')
> > > > devi = ef.Env('devi')
> > > > devs = ef.Env('devs')
> > > > preprod = ef.Env('preprod')
> > > > prod = ef.Env('prod')
> > > >
> > > > # Grouping environments per their roles
> > > > g_dev = ef.EnvGroup('g_dev', devlocal, devi, devs)
> > > > g_prod = ef.EnvGroup('g_prod', preprod, prod)
> > > >
> > > >
> > > > # This function is used to describe all environments and return an
> > > > instantiated environment
> > > > # configuration for environment with name 'env_name', which is passed
> > as
> > > > parameter
> > > > def conf(env_name):
> > > > env = ef.env(env_name)
> > > >
> > > > # This will define a weblogic configuration for all environments
> > > > defined above
> > > > # But the result of execution of conf() will be the setting for
> > > > environment
> > > > # passed as argument 'env_name'
> > > > # Use EnvFactory 'ef' to define the required/allowed environments
> > > > # The 'weblogic_config' class is defined in framework.py
> > > > with weblogic_config(env, ef) as dc:
> > > > # Set domain base port number for different environments.
> > > > # Domain base port is used as base to calculate port offsets
> > > > # Here we're saying that Weblogic in g_prod group will have
> > > > # attribute base_port set to 7000, and each of the
> development
> > > > environments
> > > > # will have unique base_port
> > > > dc.setattr('base_port', g_prod=7000, devi=7100, devs=7200,
> > > > devlocal=7300)
> > > > [...]
> > > >
> > > > The "DSL" for configuration is almost entirely done in Python, thus
> > could
> > > > be compared to annotated Java code where we support that. Multiconf
> > > > generates al sorts of files like XML (for WLS and other containers)
> but
> > > > configuration itself is barely done or overridden via XML.
> > > >
> > > > We may have a slightly broader scope but some aspects and goals are
> > > pretty
> > > > similar.
> > > >
> > > > Werner
> > > >
> > > > On Wed, Dec 3, 2014 at 1:19 PM, Tresch, Anatole <
> > > > anatole.tresch@credit-suisse.com> wrote:
> > > >
> > > >> Can you explain (or post a link) that in more detail, people might
> not
> > > now
> > > >> much about Multiconf...
> > > >>
> > > >> -----Original Message-----
> > > >> From: Werner Keil [mailto:werner.keil@gmail.com]
> > > >> Sent: Mittwoch, 3. Dezember 2014 13:16
> > > >> To: dev@tamaya.incubator.apache.org
> > > >> Subject: Re: Use Case 1: Read simple properties and get values.
> > > >>
> > > >> I would go a bit beyond a simple "ConfigFormat" based on the
> > experience
> > > >> with Multiconf in a very large Cloud environment.
> > > >> What was used there aside from obvious (JSON) data exchange or
> output
> > > one
> > > >> might consider "format" is more towards "ConfigReport" or whatever
> you
> > > >> might call that.
> > > >> We used Asciidoc and with several Asciidoc and Asciidoctor affine
> > > members
> > > >> here I guess that could also work for Tamya;-)
> > > >>
> > > >> Werner
> > > >>
> > > >> On Wed, Dec 3, 2014 at 1:08 PM, Tresch, Anatole <
> > > >> anatole.tresch@credit-suisse.com> wrote:
> > > >>
> > > >> > @Romain
> > > >> >
> > > >> > The concept is - as I said - that you can describe, from which
> > source
> > > a
> > > >> > configuration should be read. This descriptions goes first to a
> > > reader,
> > > >> > which knows how to resolve the location and resolves to a number
> of
> > > >> > URIs/input streams.
> > > >> > These input streams can come in multiple formats (even mixed).
> > > >> > Configuration Format and reader are the abstraction so you can
> write
> > > >> > basically something like
> > > >> >
> > > >> > PropertyProvider prov = PropertyProviders.fromPath("
> > reader:whatever");
> > > >> >
> > > >> > In the example above you can declaratively define a
> > PropertyProvider,
> > > >> fast
> > > >> > and easy, and you (by default) do not have to care on the format
> > (BTW
> > > it
> > > >> is
> > > >> > possible that multiple formats register for the same file ending).
> > > >> > Removing ConfigFormat means, that you
> > > >> > - only support a limited set of formats, or
> > > >> > - must implement format parsing logic yourself also for the most
> > > common
> > > >> > cases, and
> > > >> > - create additional implementation dependencies on the format
> > parsing
> > > >> code
> > > >> > - and probably you have to duplicate the logic that converts an
> > > >> > InputStream into a Map<String,String>/ProeprtyProvider.
> > > >> >
> > > >> > Finally: the project is internally split up into an API part and
> an
> > > >> > implementation part. ConfigFormat is not part of the API (you
> > > typically
> > > >> > will not code against it). If you have really want to write all
> your
> > > >> > providers yourself, you can do that. Nobody prevents you doing so,
> > but
> > > >> > please allow other maybe less sophisticated users to benefit from
> > > >> provided
> > > >> > features, so they do not have to write them themselves.
> > > >> > And once more, this feature was a great help for supporting
> > muiltiple
> > > >> > formats such as .properties, .xml (xml-properties), .ini
> > (ini-Files).
> > > I
> > > >> do
> > > >> > not see any reason we should remove something that has proven to
> > work
> > > so
> > > >> > nicely.
> > > >> >
> > > >> > Cheers,
> > > >> > Anatole
> > > >> >
> > > >> >
> > > >> >
> > > >> > -----Original Message-----
> > > >> > From: Romain Manni-Bucau [mailto:rmannibucau@gmail.com]
> > > >> > Sent: Mittwoch, 3. Dezember 2014 12:18
> > > >> > To: dev@tamaya.incubator.apache.org
> > > >> > Subject: Re: Use Case 1: Read simple properties and get values.
> > > >> >
> > > >> > I don't fully agree. Where is passed through PropertyProviders so
> > > >> > basically we don't need this format abstraction. Providers should
> > just
> > > >> > check it can read it or not. having such an indirection already
> > makes
> > > >> > the framework "apparently" complex enough to not be used from my
> > point
> > > >> > of view.
> > > >> >
> > > >> > Implementing a custom provider to read what you want is generally
> > > >> > trivial enough to be where the extenisbility is.
> > > >> >
> > > >> >
> > > >> > Romain Manni-Bucau
> > > >> > @rmannibucau
> > > >> > http://www.tomitribe.com
> > > >> > http://rmannibucau.wordpress.com
> > > >> > https://github.com/rmannibucau
> > > >> >
> > > >> >
> > > >> > 2014-12-03 12:13 GMT+01:00 Anatole Tresch <at...@gmail.com>:
> > > >> > > Far this is not the same. A provider defines where configuration
> > is
> > > >> read.
> > > >> > > The format defines how. Even properties files may lay at
> multiple
> > > >> > > locations, could be locally , classpath, blobs, remotedly, ... I
> > > want
> > > >> to
> > > >> > > support users that they are able to read configuration with
> > minimal
> > > >> > coding
> > > >> > > required.
> > > >> > >
> > > >> > > This model is flexible and is the reason we reading in uc1 is so
> > > simple
> > > >> > and
> > > >> > > will be similar easy also for enterprise specific custom
> formats.
> > > >> > Companies
> > > >> > > will never change their existing formats just to use Tamaya...
> > > >> > > Romain Manni-Bucau <rm...@gmail.com> schrieb am Mi., 3.
> > Dez.
> > > >> 2014
> > > >> > um
> > > >> > > 11:45:
> > > >> > >
> > > >> > >> +1, ConfigFormat or PropertyProvider shouldn't be there.
> > > >> > >>
> > > >> > >>
> > > >> > >> Romain Manni-Bucau
> > > >> > >> @rmannibucau
> > > >> > >> http://www.tomitribe.com
> > > >> > >> http://rmannibucau.wordpress.com
> > > >> > >> https://github.com/rmannibucau
> > > >> > >>
> > > >> > >>
> > > >> > >> 2014-12-03 8:37 GMT+01:00 Oliver B. Fischer <
> > > o.b.fischer@swe-blog.net
> > > >> >:
> > > >> > >> > So if a new ConfigFormat is required for reading a different
> > data
> > > >> > source:
> > > >> > >> > What is the difference between ConfigFormat and
> > PropertyProvider?
> > > >> > Isn't
> > > >> > >> it
> > > >> > >> > the same?
> > > >> > >> >
> > > >> > >> > IMHO we have to discuss the overall architecture a least a
> > little
> > > >> bit
> > > >> > to
> > > >> > >> see
> > > >> > >> > which parts exist, how they interact and who is responsible
> for
> > > >> what.
> > > >> > >> >
> > > >> > >> > Oliver
> > > >> > >> >
> > > >> > >> > Am 03.12.14 01:15, schrieb Anatole Tresch:
> > > >> > >> >>
> > > >> > >> >> BTW, supporting a new ConfigFormat is trivial: implementing
> > > >> > >> >> ConfigurationFormat
> > > >> > >> >> and register it with as component, by default using the
> > > >> > ServiceLoader.
> > > >> > >> >> Then you only to read the file and you are done ;)
> > > >> > >> >>
> > > >> > >> >> 2014-12-01 19:48 GMT+01:00 Gerhard Petracek <
> > > >> > gerhard.petracek@gmail.com
> > > >> > >> >:
> > > >> > >> >>
> > > >> > >> >>
> > > >> > >> >
> > > >> > >> > --
> > > >> > >> > N Oliver B. Fischer
> > > >> > >> > A Schönhauser Allee 64, 10437 Berlin, Deutschland/Germany
> > > >> > >> > P +49 30 44793251
> > > >> > >> > M +49 178 7903538
> > > >> > >> > E o.b.fischer@swe-blog.net
> > > >> > >> > S oliver.b.fischer
> > > >> > >> > J oliver.b.fischer@jabber.org
> > > >> > >> > X http://xing.to/obf
> > > >> > >> >
> > > >> > >>
> > > >> >
> > > >>
> > >
> >
>
Re: Use Case 1: Read simple properties and get values.
Posted by Anatole Tresch <at...@gmail.com>.
Hmm. Pros abd cons: pro format is important, cons: i tried to minimize the
api: reader:something -> the reader can be implemented in any way. The
implementation can decide, if (explit) formats are supported, eg:
reader:[format]foo. Therefore I moved the format part to the implementation
completely...
Other opinions?
Werner Keil <we...@gmail.com> schrieb am Mi., 3. Dez. 2014 um 14:35:
> What would "reader" or "format" have to to here in a fromPath() method?
> That's more a "reader" or "loader" thing, some may call it "parsing" but
> I'd say that only makes sense if you have a relatively small string, not
> broader source.
>
> It may be a little bit simpler given the input format is only W3C DDR
> compliant XML data, but looking at recently graduated DeviceMap, the
> ".next" Java client offers a variety of "resource loaders" either from
> within an archive, a URL or as file in a file system:
> http://svn.apache.org/repos/asf/devicemap/trunk/devicemap/
> java/classifier/src/main/java/org/apache/devicemap/loader/
>
> Reporting and output or "formatting" would be something different IMHO, not
> to be mixed with loader or reader.
>
> Werner
>
> On Wed, Dec 3, 2014 at 2:24 PM, Romain Manni-Bucau <rm...@gmail.com>
> wrote:
>
> > Hmm, there is something fishy fo rme in this reader/format/...
> discussion.
> >
> > From your description I would expect:
> > PropertyProviders.fromPath("reader[:format]whatever"); to be
> > supported. And if it is what there is behind the scene I would like it
> > to be part of the API.
> >
> > One simple use case: support properties, yaml, ini, xml or whatever
> > just be called myconfig.conf or myconfig.config or any other
> > extension.
> >
> > I agree we can guess the format from the extension often enough to not
> > force its usage but since it is important as you mentionned it I think
> > we need to accept it is part of the API.
> >
> > wdyt?
> >
> >
> >
> > Romain Manni-Bucau
> > @rmannibucau
> > http://www.tomitribe.com
> > http://rmannibucau.wordpress.com
> > https://github.com/rmannibucau
> >
> >
> > 2014-12-03 14:02 GMT+01:00 Werner Keil <we...@gmail.com>:
> > > The Asciidoc reporting is not part of the Open Source project AFAIK,
> but
> > > here's Multiconf on GitHub:
> > > https://github.com/lhupfeldt/multiconf
> > >
> > > For those familiar with scripting languages like Groovy Python should
> not
> > > feel too strange;-)
> > > Here a quick example on how it can be used:
> > >
> > > # Define environments
> > >
> > > # Use EnvFactory() to create environment or group of environments
> > > ef = EnvFactory()
> > >
> > > # We have five environments and we define them here
> > > devlocal = ef.Env('devlocal')
> > > devi = ef.Env('devi')
> > > devs = ef.Env('devs')
> > > preprod = ef.Env('preprod')
> > > prod = ef.Env('prod')
> > >
> > > # Grouping environments per their roles
> > > g_dev = ef.EnvGroup('g_dev', devlocal, devi, devs)
> > > g_prod = ef.EnvGroup('g_prod', preprod, prod)
> > >
> > >
> > > # This function is used to describe all environments and return an
> > > instantiated environment
> > > # configuration for environment with name 'env_name', which is passed
> as
> > > parameter
> > > def conf(env_name):
> > > env = ef.env(env_name)
> > >
> > > # This will define a weblogic configuration for all environments
> > > defined above
> > > # But the result of execution of conf() will be the setting for
> > > environment
> > > # passed as argument 'env_name'
> > > # Use EnvFactory 'ef' to define the required/allowed environments
> > > # The 'weblogic_config' class is defined in framework.py
> > > with weblogic_config(env, ef) as dc:
> > > # Set domain base port number for different environments.
> > > # Domain base port is used as base to calculate port offsets
> > > # Here we're saying that Weblogic in g_prod group will have
> > > # attribute base_port set to 7000, and each of the development
> > > environments
> > > # will have unique base_port
> > > dc.setattr('base_port', g_prod=7000, devi=7100, devs=7200,
> > > devlocal=7300)
> > > [...]
> > >
> > > The "DSL" for configuration is almost entirely done in Python, thus
> could
> > > be compared to annotated Java code where we support that. Multiconf
> > > generates al sorts of files like XML (for WLS and other containers) but
> > > configuration itself is barely done or overridden via XML.
> > >
> > > We may have a slightly broader scope but some aspects and goals are
> > pretty
> > > similar.
> > >
> > > Werner
> > >
> > > On Wed, Dec 3, 2014 at 1:19 PM, Tresch, Anatole <
> > > anatole.tresch@credit-suisse.com> wrote:
> > >
> > >> Can you explain (or post a link) that in more detail, people might not
> > now
> > >> much about Multiconf...
> > >>
> > >> -----Original Message-----
> > >> From: Werner Keil [mailto:werner.keil@gmail.com]
> > >> Sent: Mittwoch, 3. Dezember 2014 13:16
> > >> To: dev@tamaya.incubator.apache.org
> > >> Subject: Re: Use Case 1: Read simple properties and get values.
> > >>
> > >> I would go a bit beyond a simple "ConfigFormat" based on the
> experience
> > >> with Multiconf in a very large Cloud environment.
> > >> What was used there aside from obvious (JSON) data exchange or output
> > one
> > >> might consider "format" is more towards "ConfigReport" or whatever you
> > >> might call that.
> > >> We used Asciidoc and with several Asciidoc and Asciidoctor affine
> > members
> > >> here I guess that could also work for Tamya;-)
> > >>
> > >> Werner
> > >>
> > >> On Wed, Dec 3, 2014 at 1:08 PM, Tresch, Anatole <
> > >> anatole.tresch@credit-suisse.com> wrote:
> > >>
> > >> > @Romain
> > >> >
> > >> > The concept is - as I said - that you can describe, from which
> source
> > a
> > >> > configuration should be read. This descriptions goes first to a
> > reader,
> > >> > which knows how to resolve the location and resolves to a number of
> > >> > URIs/input streams.
> > >> > These input streams can come in multiple formats (even mixed).
> > >> > Configuration Format and reader are the abstraction so you can write
> > >> > basically something like
> > >> >
> > >> > PropertyProvider prov = PropertyProviders.fromPath("
> reader:whatever");
> > >> >
> > >> > In the example above you can declaratively define a
> PropertyProvider,
> > >> fast
> > >> > and easy, and you (by default) do not have to care on the format
> (BTW
> > it
> > >> is
> > >> > possible that multiple formats register for the same file ending).
> > >> > Removing ConfigFormat means, that you
> > >> > - only support a limited set of formats, or
> > >> > - must implement format parsing logic yourself also for the most
> > common
> > >> > cases, and
> > >> > - create additional implementation dependencies on the format
> parsing
> > >> code
> > >> > - and probably you have to duplicate the logic that converts an
> > >> > InputStream into a Map<String,String>/ProeprtyProvider.
> > >> >
> > >> > Finally: the project is internally split up into an API part and an
> > >> > implementation part. ConfigFormat is not part of the API (you
> > typically
> > >> > will not code against it). If you have really want to write all your
> > >> > providers yourself, you can do that. Nobody prevents you doing so,
> but
> > >> > please allow other maybe less sophisticated users to benefit from
> > >> provided
> > >> > features, so they do not have to write them themselves.
> > >> > And once more, this feature was a great help for supporting
> muiltiple
> > >> > formats such as .properties, .xml (xml-properties), .ini
> (ini-Files).
> > I
> > >> do
> > >> > not see any reason we should remove something that has proven to
> work
> > so
> > >> > nicely.
> > >> >
> > >> > Cheers,
> > >> > Anatole
> > >> >
> > >> >
> > >> >
> > >> > -----Original Message-----
> > >> > From: Romain Manni-Bucau [mailto:rmannibucau@gmail.com]
> > >> > Sent: Mittwoch, 3. Dezember 2014 12:18
> > >> > To: dev@tamaya.incubator.apache.org
> > >> > Subject: Re: Use Case 1: Read simple properties and get values.
> > >> >
> > >> > I don't fully agree. Where is passed through PropertyProviders so
> > >> > basically we don't need this format abstraction. Providers should
> just
> > >> > check it can read it or not. having such an indirection already
> makes
> > >> > the framework "apparently" complex enough to not be used from my
> point
> > >> > of view.
> > >> >
> > >> > Implementing a custom provider to read what you want is generally
> > >> > trivial enough to be where the extenisbility is.
> > >> >
> > >> >
> > >> > Romain Manni-Bucau
> > >> > @rmannibucau
> > >> > http://www.tomitribe.com
> > >> > http://rmannibucau.wordpress.com
> > >> > https://github.com/rmannibucau
> > >> >
> > >> >
> > >> > 2014-12-03 12:13 GMT+01:00 Anatole Tresch <at...@gmail.com>:
> > >> > > Far this is not the same. A provider defines where configuration
> is
> > >> read.
> > >> > > The format defines how. Even properties files may lay at multiple
> > >> > > locations, could be locally , classpath, blobs, remotedly, ... I
> > want
> > >> to
> > >> > > support users that they are able to read configuration with
> minimal
> > >> > coding
> > >> > > required.
> > >> > >
> > >> > > This model is flexible and is the reason we reading in uc1 is so
> > simple
> > >> > and
> > >> > > will be similar easy also for enterprise specific custom formats.
> > >> > Companies
> > >> > > will never change their existing formats just to use Tamaya...
> > >> > > Romain Manni-Bucau <rm...@gmail.com> schrieb am Mi., 3.
> Dez.
> > >> 2014
> > >> > um
> > >> > > 11:45:
> > >> > >
> > >> > >> +1, ConfigFormat or PropertyProvider shouldn't be there.
> > >> > >>
> > >> > >>
> > >> > >> Romain Manni-Bucau
> > >> > >> @rmannibucau
> > >> > >> http://www.tomitribe.com
> > >> > >> http://rmannibucau.wordpress.com
> > >> > >> https://github.com/rmannibucau
> > >> > >>
> > >> > >>
> > >> > >> 2014-12-03 8:37 GMT+01:00 Oliver B. Fischer <
> > o.b.fischer@swe-blog.net
> > >> >:
> > >> > >> > So if a new ConfigFormat is required for reading a different
> data
> > >> > source:
> > >> > >> > What is the difference between ConfigFormat and
> PropertyProvider?
> > >> > Isn't
> > >> > >> it
> > >> > >> > the same?
> > >> > >> >
> > >> > >> > IMHO we have to discuss the overall architecture a least a
> little
> > >> bit
> > >> > to
> > >> > >> see
> > >> > >> > which parts exist, how they interact and who is responsible for
> > >> what.
> > >> > >> >
> > >> > >> > Oliver
> > >> > >> >
> > >> > >> > Am 03.12.14 01:15, schrieb Anatole Tresch:
> > >> > >> >>
> > >> > >> >> BTW, supporting a new ConfigFormat is trivial: implementing
> > >> > >> >> ConfigurationFormat
> > >> > >> >> and register it with as component, by default using the
> > >> > ServiceLoader.
> > >> > >> >> Then you only to read the file and you are done ;)
> > >> > >> >>
> > >> > >> >> 2014-12-01 19:48 GMT+01:00 Gerhard Petracek <
> > >> > gerhard.petracek@gmail.com
> > >> > >> >:
> > >> > >> >>
> > >> > >> >>
> > >> > >> >
> > >> > >> > --
> > >> > >> > N Oliver B. Fischer
> > >> > >> > A Schönhauser Allee 64, 10437 Berlin, Deutschland/Germany
> > >> > >> > P +49 30 44793251
> > >> > >> > M +49 178 7903538
> > >> > >> > E o.b.fischer@swe-blog.net
> > >> > >> > S oliver.b.fischer
> > >> > >> > J oliver.b.fischer@jabber.org
> > >> > >> > X http://xing.to/obf
> > >> > >> >
> > >> > >>
> > >> >
> > >>
> >
>
Re: Use Case 1: Read simple properties and get values.
Posted by Werner Keil <we...@gmail.com>.
What would "reader" or "format" have to to here in a fromPath() method?
That's more a "reader" or "loader" thing, some may call it "parsing" but
I'd say that only makes sense if you have a relatively small string, not
broader source.
It may be a little bit simpler given the input format is only W3C DDR
compliant XML data, but looking at recently graduated DeviceMap, the
".next" Java client offers a variety of "resource loaders" either from
within an archive, a URL or as file in a file system:
http://svn.apache.org/repos/asf/devicemap/trunk/devicemap/java/classifier/src/main/java/org/apache/devicemap/loader/
Reporting and output or "formatting" would be something different IMHO, not
to be mixed with loader or reader.
Werner
On Wed, Dec 3, 2014 at 2:24 PM, Romain Manni-Bucau <rm...@gmail.com>
wrote:
> Hmm, there is something fishy fo rme in this reader/format/... discussion.
>
> From your description I would expect:
> PropertyProviders.fromPath("reader[:format]whatever"); to be
> supported. And if it is what there is behind the scene I would like it
> to be part of the API.
>
> One simple use case: support properties, yaml, ini, xml or whatever
> just be called myconfig.conf or myconfig.config or any other
> extension.
>
> I agree we can guess the format from the extension often enough to not
> force its usage but since it is important as you mentionned it I think
> we need to accept it is part of the API.
>
> wdyt?
>
>
>
> Romain Manni-Bucau
> @rmannibucau
> http://www.tomitribe.com
> http://rmannibucau.wordpress.com
> https://github.com/rmannibucau
>
>
> 2014-12-03 14:02 GMT+01:00 Werner Keil <we...@gmail.com>:
> > The Asciidoc reporting is not part of the Open Source project AFAIK, but
> > here's Multiconf on GitHub:
> > https://github.com/lhupfeldt/multiconf
> >
> > For those familiar with scripting languages like Groovy Python should not
> > feel too strange;-)
> > Here a quick example on how it can be used:
> >
> > # Define environments
> >
> > # Use EnvFactory() to create environment or group of environments
> > ef = EnvFactory()
> >
> > # We have five environments and we define them here
> > devlocal = ef.Env('devlocal')
> > devi = ef.Env('devi')
> > devs = ef.Env('devs')
> > preprod = ef.Env('preprod')
> > prod = ef.Env('prod')
> >
> > # Grouping environments per their roles
> > g_dev = ef.EnvGroup('g_dev', devlocal, devi, devs)
> > g_prod = ef.EnvGroup('g_prod', preprod, prod)
> >
> >
> > # This function is used to describe all environments and return an
> > instantiated environment
> > # configuration for environment with name 'env_name', which is passed as
> > parameter
> > def conf(env_name):
> > env = ef.env(env_name)
> >
> > # This will define a weblogic configuration for all environments
> > defined above
> > # But the result of execution of conf() will be the setting for
> > environment
> > # passed as argument 'env_name'
> > # Use EnvFactory 'ef' to define the required/allowed environments
> > # The 'weblogic_config' class is defined in framework.py
> > with weblogic_config(env, ef) as dc:
> > # Set domain base port number for different environments.
> > # Domain base port is used as base to calculate port offsets
> > # Here we're saying that Weblogic in g_prod group will have
> > # attribute base_port set to 7000, and each of the development
> > environments
> > # will have unique base_port
> > dc.setattr('base_port', g_prod=7000, devi=7100, devs=7200,
> > devlocal=7300)
> > [...]
> >
> > The "DSL" for configuration is almost entirely done in Python, thus could
> > be compared to annotated Java code where we support that. Multiconf
> > generates al sorts of files like XML (for WLS and other containers) but
> > configuration itself is barely done or overridden via XML.
> >
> > We may have a slightly broader scope but some aspects and goals are
> pretty
> > similar.
> >
> > Werner
> >
> > On Wed, Dec 3, 2014 at 1:19 PM, Tresch, Anatole <
> > anatole.tresch@credit-suisse.com> wrote:
> >
> >> Can you explain (or post a link) that in more detail, people might not
> now
> >> much about Multiconf...
> >>
> >> -----Original Message-----
> >> From: Werner Keil [mailto:werner.keil@gmail.com]
> >> Sent: Mittwoch, 3. Dezember 2014 13:16
> >> To: dev@tamaya.incubator.apache.org
> >> Subject: Re: Use Case 1: Read simple properties and get values.
> >>
> >> I would go a bit beyond a simple "ConfigFormat" based on the experience
> >> with Multiconf in a very large Cloud environment.
> >> What was used there aside from obvious (JSON) data exchange or output
> one
> >> might consider "format" is more towards "ConfigReport" or whatever you
> >> might call that.
> >> We used Asciidoc and with several Asciidoc and Asciidoctor affine
> members
> >> here I guess that could also work for Tamya;-)
> >>
> >> Werner
> >>
> >> On Wed, Dec 3, 2014 at 1:08 PM, Tresch, Anatole <
> >> anatole.tresch@credit-suisse.com> wrote:
> >>
> >> > @Romain
> >> >
> >> > The concept is - as I said - that you can describe, from which source
> a
> >> > configuration should be read. This descriptions goes first to a
> reader,
> >> > which knows how to resolve the location and resolves to a number of
> >> > URIs/input streams.
> >> > These input streams can come in multiple formats (even mixed).
> >> > Configuration Format and reader are the abstraction so you can write
> >> > basically something like
> >> >
> >> > PropertyProvider prov = PropertyProviders.fromPath("reader:whatever");
> >> >
> >> > In the example above you can declaratively define a PropertyProvider,
> >> fast
> >> > and easy, and you (by default) do not have to care on the format (BTW
> it
> >> is
> >> > possible that multiple formats register for the same file ending).
> >> > Removing ConfigFormat means, that you
> >> > - only support a limited set of formats, or
> >> > - must implement format parsing logic yourself also for the most
> common
> >> > cases, and
> >> > - create additional implementation dependencies on the format parsing
> >> code
> >> > - and probably you have to duplicate the logic that converts an
> >> > InputStream into a Map<String,String>/ProeprtyProvider.
> >> >
> >> > Finally: the project is internally split up into an API part and an
> >> > implementation part. ConfigFormat is not part of the API (you
> typically
> >> > will not code against it). If you have really want to write all your
> >> > providers yourself, you can do that. Nobody prevents you doing so, but
> >> > please allow other maybe less sophisticated users to benefit from
> >> provided
> >> > features, so they do not have to write them themselves.
> >> > And once more, this feature was a great help for supporting muiltiple
> >> > formats such as .properties, .xml (xml-properties), .ini (ini-Files).
> I
> >> do
> >> > not see any reason we should remove something that has proven to work
> so
> >> > nicely.
> >> >
> >> > Cheers,
> >> > Anatole
> >> >
> >> >
> >> >
> >> > -----Original Message-----
> >> > From: Romain Manni-Bucau [mailto:rmannibucau@gmail.com]
> >> > Sent: Mittwoch, 3. Dezember 2014 12:18
> >> > To: dev@tamaya.incubator.apache.org
> >> > Subject: Re: Use Case 1: Read simple properties and get values.
> >> >
> >> > I don't fully agree. Where is passed through PropertyProviders so
> >> > basically we don't need this format abstraction. Providers should just
> >> > check it can read it or not. having such an indirection already makes
> >> > the framework "apparently" complex enough to not be used from my point
> >> > of view.
> >> >
> >> > Implementing a custom provider to read what you want is generally
> >> > trivial enough to be where the extenisbility is.
> >> >
> >> >
> >> > Romain Manni-Bucau
> >> > @rmannibucau
> >> > http://www.tomitribe.com
> >> > http://rmannibucau.wordpress.com
> >> > https://github.com/rmannibucau
> >> >
> >> >
> >> > 2014-12-03 12:13 GMT+01:00 Anatole Tresch <at...@gmail.com>:
> >> > > Far this is not the same. A provider defines where configuration is
> >> read.
> >> > > The format defines how. Even properties files may lay at multiple
> >> > > locations, could be locally , classpath, blobs, remotedly, ... I
> want
> >> to
> >> > > support users that they are able to read configuration with minimal
> >> > coding
> >> > > required.
> >> > >
> >> > > This model is flexible and is the reason we reading in uc1 is so
> simple
> >> > and
> >> > > will be similar easy also for enterprise specific custom formats.
> >> > Companies
> >> > > will never change their existing formats just to use Tamaya...
> >> > > Romain Manni-Bucau <rm...@gmail.com> schrieb am Mi., 3. Dez.
> >> 2014
> >> > um
> >> > > 11:45:
> >> > >
> >> > >> +1, ConfigFormat or PropertyProvider shouldn't be there.
> >> > >>
> >> > >>
> >> > >> Romain Manni-Bucau
> >> > >> @rmannibucau
> >> > >> http://www.tomitribe.com
> >> > >> http://rmannibucau.wordpress.com
> >> > >> https://github.com/rmannibucau
> >> > >>
> >> > >>
> >> > >> 2014-12-03 8:37 GMT+01:00 Oliver B. Fischer <
> o.b.fischer@swe-blog.net
> >> >:
> >> > >> > So if a new ConfigFormat is required for reading a different data
> >> > source:
> >> > >> > What is the difference between ConfigFormat and PropertyProvider?
> >> > Isn't
> >> > >> it
> >> > >> > the same?
> >> > >> >
> >> > >> > IMHO we have to discuss the overall architecture a least a little
> >> bit
> >> > to
> >> > >> see
> >> > >> > which parts exist, how they interact and who is responsible for
> >> what.
> >> > >> >
> >> > >> > Oliver
> >> > >> >
> >> > >> > Am 03.12.14 01:15, schrieb Anatole Tresch:
> >> > >> >>
> >> > >> >> BTW, supporting a new ConfigFormat is trivial: implementing
> >> > >> >> ConfigurationFormat
> >> > >> >> and register it with as component, by default using the
> >> > ServiceLoader.
> >> > >> >> Then you only to read the file and you are done ;)
> >> > >> >>
> >> > >> >> 2014-12-01 19:48 GMT+01:00 Gerhard Petracek <
> >> > gerhard.petracek@gmail.com
> >> > >> >:
> >> > >> >>
> >> > >> >>
> >> > >> >
> >> > >> > --
> >> > >> > N Oliver B. Fischer
> >> > >> > A Schönhauser Allee 64, 10437 Berlin, Deutschland/Germany
> >> > >> > P +49 30 44793251
> >> > >> > M +49 178 7903538
> >> > >> > E o.b.fischer@swe-blog.net
> >> > >> > S oliver.b.fischer
> >> > >> > J oliver.b.fischer@jabber.org
> >> > >> > X http://xing.to/obf
> >> > >> >
> >> > >>
> >> >
> >>
>
Re: Use Case 1: Read simple properties and get values.
Posted by Romain Manni-Bucau <rm...@gmail.com>.
Hmm, there is something fishy fo rme in this reader/format/... discussion.
>From your description I would expect:
PropertyProviders.fromPath("reader[:format]whatever"); to be
supported. And if it is what there is behind the scene I would like it
to be part of the API.
One simple use case: support properties, yaml, ini, xml or whatever
just be called myconfig.conf or myconfig.config or any other
extension.
I agree we can guess the format from the extension often enough to not
force its usage but since it is important as you mentionned it I think
we need to accept it is part of the API.
wdyt?
Romain Manni-Bucau
@rmannibucau
http://www.tomitribe.com
http://rmannibucau.wordpress.com
https://github.com/rmannibucau
2014-12-03 14:02 GMT+01:00 Werner Keil <we...@gmail.com>:
> The Asciidoc reporting is not part of the Open Source project AFAIK, but
> here's Multiconf on GitHub:
> https://github.com/lhupfeldt/multiconf
>
> For those familiar with scripting languages like Groovy Python should not
> feel too strange;-)
> Here a quick example on how it can be used:
>
> # Define environments
>
> # Use EnvFactory() to create environment or group of environments
> ef = EnvFactory()
>
> # We have five environments and we define them here
> devlocal = ef.Env('devlocal')
> devi = ef.Env('devi')
> devs = ef.Env('devs')
> preprod = ef.Env('preprod')
> prod = ef.Env('prod')
>
> # Grouping environments per their roles
> g_dev = ef.EnvGroup('g_dev', devlocal, devi, devs)
> g_prod = ef.EnvGroup('g_prod', preprod, prod)
>
>
> # This function is used to describe all environments and return an
> instantiated environment
> # configuration for environment with name 'env_name', which is passed as
> parameter
> def conf(env_name):
> env = ef.env(env_name)
>
> # This will define a weblogic configuration for all environments
> defined above
> # But the result of execution of conf() will be the setting for
> environment
> # passed as argument 'env_name'
> # Use EnvFactory 'ef' to define the required/allowed environments
> # The 'weblogic_config' class is defined in framework.py
> with weblogic_config(env, ef) as dc:
> # Set domain base port number for different environments.
> # Domain base port is used as base to calculate port offsets
> # Here we're saying that Weblogic in g_prod group will have
> # attribute base_port set to 7000, and each of the development
> environments
> # will have unique base_port
> dc.setattr('base_port', g_prod=7000, devi=7100, devs=7200,
> devlocal=7300)
> [...]
>
> The "DSL" for configuration is almost entirely done in Python, thus could
> be compared to annotated Java code where we support that. Multiconf
> generates al sorts of files like XML (for WLS and other containers) but
> configuration itself is barely done or overridden via XML.
>
> We may have a slightly broader scope but some aspects and goals are pretty
> similar.
>
> Werner
>
> On Wed, Dec 3, 2014 at 1:19 PM, Tresch, Anatole <
> anatole.tresch@credit-suisse.com> wrote:
>
>> Can you explain (or post a link) that in more detail, people might not now
>> much about Multiconf...
>>
>> -----Original Message-----
>> From: Werner Keil [mailto:werner.keil@gmail.com]
>> Sent: Mittwoch, 3. Dezember 2014 13:16
>> To: dev@tamaya.incubator.apache.org
>> Subject: Re: Use Case 1: Read simple properties and get values.
>>
>> I would go a bit beyond a simple "ConfigFormat" based on the experience
>> with Multiconf in a very large Cloud environment.
>> What was used there aside from obvious (JSON) data exchange or output one
>> might consider "format" is more towards "ConfigReport" or whatever you
>> might call that.
>> We used Asciidoc and with several Asciidoc and Asciidoctor affine members
>> here I guess that could also work for Tamya;-)
>>
>> Werner
>>
>> On Wed, Dec 3, 2014 at 1:08 PM, Tresch, Anatole <
>> anatole.tresch@credit-suisse.com> wrote:
>>
>> > @Romain
>> >
>> > The concept is - as I said - that you can describe, from which source a
>> > configuration should be read. This descriptions goes first to a reader,
>> > which knows how to resolve the location and resolves to a number of
>> > URIs/input streams.
>> > These input streams can come in multiple formats (even mixed).
>> > Configuration Format and reader are the abstraction so you can write
>> > basically something like
>> >
>> > PropertyProvider prov = PropertyProviders.fromPath("reader:whatever");
>> >
>> > In the example above you can declaratively define a PropertyProvider,
>> fast
>> > and easy, and you (by default) do not have to care on the format (BTW it
>> is
>> > possible that multiple formats register for the same file ending).
>> > Removing ConfigFormat means, that you
>> > - only support a limited set of formats, or
>> > - must implement format parsing logic yourself also for the most common
>> > cases, and
>> > - create additional implementation dependencies on the format parsing
>> code
>> > - and probably you have to duplicate the logic that converts an
>> > InputStream into a Map<String,String>/ProeprtyProvider.
>> >
>> > Finally: the project is internally split up into an API part and an
>> > implementation part. ConfigFormat is not part of the API (you typically
>> > will not code against it). If you have really want to write all your
>> > providers yourself, you can do that. Nobody prevents you doing so, but
>> > please allow other maybe less sophisticated users to benefit from
>> provided
>> > features, so they do not have to write them themselves.
>> > And once more, this feature was a great help for supporting muiltiple
>> > formats such as .properties, .xml (xml-properties), .ini (ini-Files). I
>> do
>> > not see any reason we should remove something that has proven to work so
>> > nicely.
>> >
>> > Cheers,
>> > Anatole
>> >
>> >
>> >
>> > -----Original Message-----
>> > From: Romain Manni-Bucau [mailto:rmannibucau@gmail.com]
>> > Sent: Mittwoch, 3. Dezember 2014 12:18
>> > To: dev@tamaya.incubator.apache.org
>> > Subject: Re: Use Case 1: Read simple properties and get values.
>> >
>> > I don't fully agree. Where is passed through PropertyProviders so
>> > basically we don't need this format abstraction. Providers should just
>> > check it can read it or not. having such an indirection already makes
>> > the framework "apparently" complex enough to not be used from my point
>> > of view.
>> >
>> > Implementing a custom provider to read what you want is generally
>> > trivial enough to be where the extenisbility is.
>> >
>> >
>> > Romain Manni-Bucau
>> > @rmannibucau
>> > http://www.tomitribe.com
>> > http://rmannibucau.wordpress.com
>> > https://github.com/rmannibucau
>> >
>> >
>> > 2014-12-03 12:13 GMT+01:00 Anatole Tresch <at...@gmail.com>:
>> > > Far this is not the same. A provider defines where configuration is
>> read.
>> > > The format defines how. Even properties files may lay at multiple
>> > > locations, could be locally , classpath, blobs, remotedly, ... I want
>> to
>> > > support users that they are able to read configuration with minimal
>> > coding
>> > > required.
>> > >
>> > > This model is flexible and is the reason we reading in uc1 is so simple
>> > and
>> > > will be similar easy also for enterprise specific custom formats.
>> > Companies
>> > > will never change their existing formats just to use Tamaya...
>> > > Romain Manni-Bucau <rm...@gmail.com> schrieb am Mi., 3. Dez.
>> 2014
>> > um
>> > > 11:45:
>> > >
>> > >> +1, ConfigFormat or PropertyProvider shouldn't be there.
>> > >>
>> > >>
>> > >> Romain Manni-Bucau
>> > >> @rmannibucau
>> > >> http://www.tomitribe.com
>> > >> http://rmannibucau.wordpress.com
>> > >> https://github.com/rmannibucau
>> > >>
>> > >>
>> > >> 2014-12-03 8:37 GMT+01:00 Oliver B. Fischer <o.b.fischer@swe-blog.net
>> >:
>> > >> > So if a new ConfigFormat is required for reading a different data
>> > source:
>> > >> > What is the difference between ConfigFormat and PropertyProvider?
>> > Isn't
>> > >> it
>> > >> > the same?
>> > >> >
>> > >> > IMHO we have to discuss the overall architecture a least a little
>> bit
>> > to
>> > >> see
>> > >> > which parts exist, how they interact and who is responsible for
>> what.
>> > >> >
>> > >> > Oliver
>> > >> >
>> > >> > Am 03.12.14 01:15, schrieb Anatole Tresch:
>> > >> >>
>> > >> >> BTW, supporting a new ConfigFormat is trivial: implementing
>> > >> >> ConfigurationFormat
>> > >> >> and register it with as component, by default using the
>> > ServiceLoader.
>> > >> >> Then you only to read the file and you are done ;)
>> > >> >>
>> > >> >> 2014-12-01 19:48 GMT+01:00 Gerhard Petracek <
>> > gerhard.petracek@gmail.com
>> > >> >:
>> > >> >>
>> > >> >>
>> > >> >
>> > >> > --
>> > >> > N Oliver B. Fischer
>> > >> > A Schönhauser Allee 64, 10437 Berlin, Deutschland/Germany
>> > >> > P +49 30 44793251
>> > >> > M +49 178 7903538
>> > >> > E o.b.fischer@swe-blog.net
>> > >> > S oliver.b.fischer
>> > >> > J oliver.b.fischer@jabber.org
>> > >> > X http://xing.to/obf
>> > >> >
>> > >>
>> >
>>
Re: Use Case 1: Read simple properties and get values.
Posted by Werner Keil <we...@gmail.com>.
The Asciidoc reporting is not part of the Open Source project AFAIK, but
here's Multiconf on GitHub:
https://github.com/lhupfeldt/multiconf
For those familiar with scripting languages like Groovy Python should not
feel too strange;-)
Here a quick example on how it can be used:
# Define environments
# Use EnvFactory() to create environment or group of environments
ef = EnvFactory()
# We have five environments and we define them here
devlocal = ef.Env('devlocal')
devi = ef.Env('devi')
devs = ef.Env('devs')
preprod = ef.Env('preprod')
prod = ef.Env('prod')
# Grouping environments per their roles
g_dev = ef.EnvGroup('g_dev', devlocal, devi, devs)
g_prod = ef.EnvGroup('g_prod', preprod, prod)
# This function is used to describe all environments and return an
instantiated environment
# configuration for environment with name 'env_name', which is passed as
parameter
def conf(env_name):
env = ef.env(env_name)
# This will define a weblogic configuration for all environments
defined above
# But the result of execution of conf() will be the setting for
environment
# passed as argument 'env_name'
# Use EnvFactory 'ef' to define the required/allowed environments
# The 'weblogic_config' class is defined in framework.py
with weblogic_config(env, ef) as dc:
# Set domain base port number for different environments.
# Domain base port is used as base to calculate port offsets
# Here we're saying that Weblogic in g_prod group will have
# attribute base_port set to 7000, and each of the development
environments
# will have unique base_port
dc.setattr('base_port', g_prod=7000, devi=7100, devs=7200,
devlocal=7300)
[...]
The "DSL" for configuration is almost entirely done in Python, thus could
be compared to annotated Java code where we support that. Multiconf
generates al sorts of files like XML (for WLS and other containers) but
configuration itself is barely done or overridden via XML.
We may have a slightly broader scope but some aspects and goals are pretty
similar.
Werner
On Wed, Dec 3, 2014 at 1:19 PM, Tresch, Anatole <
anatole.tresch@credit-suisse.com> wrote:
> Can you explain (or post a link) that in more detail, people might not now
> much about Multiconf...
>
> -----Original Message-----
> From: Werner Keil [mailto:werner.keil@gmail.com]
> Sent: Mittwoch, 3. Dezember 2014 13:16
> To: dev@tamaya.incubator.apache.org
> Subject: Re: Use Case 1: Read simple properties and get values.
>
> I would go a bit beyond a simple "ConfigFormat" based on the experience
> with Multiconf in a very large Cloud environment.
> What was used there aside from obvious (JSON) data exchange or output one
> might consider "format" is more towards "ConfigReport" or whatever you
> might call that.
> We used Asciidoc and with several Asciidoc and Asciidoctor affine members
> here I guess that could also work for Tamya;-)
>
> Werner
>
> On Wed, Dec 3, 2014 at 1:08 PM, Tresch, Anatole <
> anatole.tresch@credit-suisse.com> wrote:
>
> > @Romain
> >
> > The concept is - as I said - that you can describe, from which source a
> > configuration should be read. This descriptions goes first to a reader,
> > which knows how to resolve the location and resolves to a number of
> > URIs/input streams.
> > These input streams can come in multiple formats (even mixed).
> > Configuration Format and reader are the abstraction so you can write
> > basically something like
> >
> > PropertyProvider prov = PropertyProviders.fromPath("reader:whatever");
> >
> > In the example above you can declaratively define a PropertyProvider,
> fast
> > and easy, and you (by default) do not have to care on the format (BTW it
> is
> > possible that multiple formats register for the same file ending).
> > Removing ConfigFormat means, that you
> > - only support a limited set of formats, or
> > - must implement format parsing logic yourself also for the most common
> > cases, and
> > - create additional implementation dependencies on the format parsing
> code
> > - and probably you have to duplicate the logic that converts an
> > InputStream into a Map<String,String>/ProeprtyProvider.
> >
> > Finally: the project is internally split up into an API part and an
> > implementation part. ConfigFormat is not part of the API (you typically
> > will not code against it). If you have really want to write all your
> > providers yourself, you can do that. Nobody prevents you doing so, but
> > please allow other maybe less sophisticated users to benefit from
> provided
> > features, so they do not have to write them themselves.
> > And once more, this feature was a great help for supporting muiltiple
> > formats such as .properties, .xml (xml-properties), .ini (ini-Files). I
> do
> > not see any reason we should remove something that has proven to work so
> > nicely.
> >
> > Cheers,
> > Anatole
> >
> >
> >
> > -----Original Message-----
> > From: Romain Manni-Bucau [mailto:rmannibucau@gmail.com]
> > Sent: Mittwoch, 3. Dezember 2014 12:18
> > To: dev@tamaya.incubator.apache.org
> > Subject: Re: Use Case 1: Read simple properties and get values.
> >
> > I don't fully agree. Where is passed through PropertyProviders so
> > basically we don't need this format abstraction. Providers should just
> > check it can read it or not. having such an indirection already makes
> > the framework "apparently" complex enough to not be used from my point
> > of view.
> >
> > Implementing a custom provider to read what you want is generally
> > trivial enough to be where the extenisbility is.
> >
> >
> > Romain Manni-Bucau
> > @rmannibucau
> > http://www.tomitribe.com
> > http://rmannibucau.wordpress.com
> > https://github.com/rmannibucau
> >
> >
> > 2014-12-03 12:13 GMT+01:00 Anatole Tresch <at...@gmail.com>:
> > > Far this is not the same. A provider defines where configuration is
> read.
> > > The format defines how. Even properties files may lay at multiple
> > > locations, could be locally , classpath, blobs, remotedly, ... I want
> to
> > > support users that they are able to read configuration with minimal
> > coding
> > > required.
> > >
> > > This model is flexible and is the reason we reading in uc1 is so simple
> > and
> > > will be similar easy also for enterprise specific custom formats.
> > Companies
> > > will never change their existing formats just to use Tamaya...
> > > Romain Manni-Bucau <rm...@gmail.com> schrieb am Mi., 3. Dez.
> 2014
> > um
> > > 11:45:
> > >
> > >> +1, ConfigFormat or PropertyProvider shouldn't be there.
> > >>
> > >>
> > >> Romain Manni-Bucau
> > >> @rmannibucau
> > >> http://www.tomitribe.com
> > >> http://rmannibucau.wordpress.com
> > >> https://github.com/rmannibucau
> > >>
> > >>
> > >> 2014-12-03 8:37 GMT+01:00 Oliver B. Fischer <o.b.fischer@swe-blog.net
> >:
> > >> > So if a new ConfigFormat is required for reading a different data
> > source:
> > >> > What is the difference between ConfigFormat and PropertyProvider?
> > Isn't
> > >> it
> > >> > the same?
> > >> >
> > >> > IMHO we have to discuss the overall architecture a least a little
> bit
> > to
> > >> see
> > >> > which parts exist, how they interact and who is responsible for
> what.
> > >> >
> > >> > Oliver
> > >> >
> > >> > Am 03.12.14 01:15, schrieb Anatole Tresch:
> > >> >>
> > >> >> BTW, supporting a new ConfigFormat is trivial: implementing
> > >> >> ConfigurationFormat
> > >> >> and register it with as component, by default using the
> > ServiceLoader.
> > >> >> Then you only to read the file and you are done ;)
> > >> >>
> > >> >> 2014-12-01 19:48 GMT+01:00 Gerhard Petracek <
> > gerhard.petracek@gmail.com
> > >> >:
> > >> >>
> > >> >>
> > >> >
> > >> > --
> > >> > N Oliver B. Fischer
> > >> > A Schönhauser Allee 64, 10437 Berlin, Deutschland/Germany
> > >> > P +49 30 44793251
> > >> > M +49 178 7903538
> > >> > E o.b.fischer@swe-blog.net
> > >> > S oliver.b.fischer
> > >> > J oliver.b.fischer@jabber.org
> > >> > X http://xing.to/obf
> > >> >
> > >>
> >
>
RE: Use Case 1: Read simple properties and get values.
Posted by "Tresch, Anatole " <an...@credit-suisse.com>.
Can you explain (or post a link) that in more detail, people might not now much about Multiconf...
-----Original Message-----
From: Werner Keil [mailto:werner.keil@gmail.com]
Sent: Mittwoch, 3. Dezember 2014 13:16
To: dev@tamaya.incubator.apache.org
Subject: Re: Use Case 1: Read simple properties and get values.
I would go a bit beyond a simple "ConfigFormat" based on the experience
with Multiconf in a very large Cloud environment.
What was used there aside from obvious (JSON) data exchange or output one
might consider "format" is more towards "ConfigReport" or whatever you
might call that.
We used Asciidoc and with several Asciidoc and Asciidoctor affine members
here I guess that could also work for Tamya;-)
Werner
On Wed, Dec 3, 2014 at 1:08 PM, Tresch, Anatole <
anatole.tresch@credit-suisse.com> wrote:
> @Romain
>
> The concept is - as I said - that you can describe, from which source a
> configuration should be read. This descriptions goes first to a reader,
> which knows how to resolve the location and resolves to a number of
> URIs/input streams.
> These input streams can come in multiple formats (even mixed).
> Configuration Format and reader are the abstraction so you can write
> basically something like
>
> PropertyProvider prov = PropertyProviders.fromPath("reader:whatever");
>
> In the example above you can declaratively define a PropertyProvider, fast
> and easy, and you (by default) do not have to care on the format (BTW it is
> possible that multiple formats register for the same file ending).
> Removing ConfigFormat means, that you
> - only support a limited set of formats, or
> - must implement format parsing logic yourself also for the most common
> cases, and
> - create additional implementation dependencies on the format parsing code
> - and probably you have to duplicate the logic that converts an
> InputStream into a Map<String,String>/ProeprtyProvider.
>
> Finally: the project is internally split up into an API part and an
> implementation part. ConfigFormat is not part of the API (you typically
> will not code against it). If you have really want to write all your
> providers yourself, you can do that. Nobody prevents you doing so, but
> please allow other maybe less sophisticated users to benefit from provided
> features, so they do not have to write them themselves.
> And once more, this feature was a great help for supporting muiltiple
> formats such as .properties, .xml (xml-properties), .ini (ini-Files). I do
> not see any reason we should remove something that has proven to work so
> nicely.
>
> Cheers,
> Anatole
>
>
>
> -----Original Message-----
> From: Romain Manni-Bucau [mailto:rmannibucau@gmail.com]
> Sent: Mittwoch, 3. Dezember 2014 12:18
> To: dev@tamaya.incubator.apache.org
> Subject: Re: Use Case 1: Read simple properties and get values.
>
> I don't fully agree. Where is passed through PropertyProviders so
> basically we don't need this format abstraction. Providers should just
> check it can read it or not. having such an indirection already makes
> the framework "apparently" complex enough to not be used from my point
> of view.
>
> Implementing a custom provider to read what you want is generally
> trivial enough to be where the extenisbility is.
>
>
> Romain Manni-Bucau
> @rmannibucau
> http://www.tomitribe.com
> http://rmannibucau.wordpress.com
> https://github.com/rmannibucau
>
>
> 2014-12-03 12:13 GMT+01:00 Anatole Tresch <at...@gmail.com>:
> > Far this is not the same. A provider defines where configuration is read.
> > The format defines how. Even properties files may lay at multiple
> > locations, could be locally , classpath, blobs, remotedly, ... I want to
> > support users that they are able to read configuration with minimal
> coding
> > required.
> >
> > This model is flexible and is the reason we reading in uc1 is so simple
> and
> > will be similar easy also for enterprise specific custom formats.
> Companies
> > will never change their existing formats just to use Tamaya...
> > Romain Manni-Bucau <rm...@gmail.com> schrieb am Mi., 3. Dez. 2014
> um
> > 11:45:
> >
> >> +1, ConfigFormat or PropertyProvider shouldn't be there.
> >>
> >>
> >> Romain Manni-Bucau
> >> @rmannibucau
> >> http://www.tomitribe.com
> >> http://rmannibucau.wordpress.com
> >> https://github.com/rmannibucau
> >>
> >>
> >> 2014-12-03 8:37 GMT+01:00 Oliver B. Fischer <o....@swe-blog.net>:
> >> > So if a new ConfigFormat is required for reading a different data
> source:
> >> > What is the difference between ConfigFormat and PropertyProvider?
> Isn't
> >> it
> >> > the same?
> >> >
> >> > IMHO we have to discuss the overall architecture a least a little bit
> to
> >> see
> >> > which parts exist, how they interact and who is responsible for what.
> >> >
> >> > Oliver
> >> >
> >> > Am 03.12.14 01:15, schrieb Anatole Tresch:
> >> >>
> >> >> BTW, supporting a new ConfigFormat is trivial: implementing
> >> >> ConfigurationFormat
> >> >> and register it with as component, by default using the
> ServiceLoader.
> >> >> Then you only to read the file and you are done ;)
> >> >>
> >> >> 2014-12-01 19:48 GMT+01:00 Gerhard Petracek <
> gerhard.petracek@gmail.com
> >> >:
> >> >>
> >> >>
> >> >
> >> > --
> >> > N Oliver B. Fischer
> >> > A Schönhauser Allee 64, 10437 Berlin, Deutschland/Germany
> >> > P +49 30 44793251
> >> > M +49 178 7903538
> >> > E o.b.fischer@swe-blog.net
> >> > S oliver.b.fischer
> >> > J oliver.b.fischer@jabber.org
> >> > X http://xing.to/obf
> >> >
> >>
>
Re: Use Case 1: Read simple properties and get values.
Posted by Werner Keil <we...@gmail.com>.
I would go a bit beyond a simple "ConfigFormat" based on the experience
with Multiconf in a very large Cloud environment.
What was used there aside from obvious (JSON) data exchange or output one
might consider "format" is more towards "ConfigReport" or whatever you
might call that.
We used Asciidoc and with several Asciidoc and Asciidoctor affine members
here I guess that could also work for Tamya;-)
Werner
On Wed, Dec 3, 2014 at 1:08 PM, Tresch, Anatole <
anatole.tresch@credit-suisse.com> wrote:
> @Romain
>
> The concept is - as I said - that you can describe, from which source a
> configuration should be read. This descriptions goes first to a reader,
> which knows how to resolve the location and resolves to a number of
> URIs/input streams.
> These input streams can come in multiple formats (even mixed).
> Configuration Format and reader are the abstraction so you can write
> basically something like
>
> PropertyProvider prov = PropertyProviders.fromPath("reader:whatever");
>
> In the example above you can declaratively define a PropertyProvider, fast
> and easy, and you (by default) do not have to care on the format (BTW it is
> possible that multiple formats register for the same file ending).
> Removing ConfigFormat means, that you
> - only support a limited set of formats, or
> - must implement format parsing logic yourself also for the most common
> cases, and
> - create additional implementation dependencies on the format parsing code
> - and probably you have to duplicate the logic that converts an
> InputStream into a Map<String,String>/ProeprtyProvider.
>
> Finally: the project is internally split up into an API part and an
> implementation part. ConfigFormat is not part of the API (you typically
> will not code against it). If you have really want to write all your
> providers yourself, you can do that. Nobody prevents you doing so, but
> please allow other maybe less sophisticated users to benefit from provided
> features, so they do not have to write them themselves.
> And once more, this feature was a great help for supporting muiltiple
> formats such as .properties, .xml (xml-properties), .ini (ini-Files). I do
> not see any reason we should remove something that has proven to work so
> nicely.
>
> Cheers,
> Anatole
>
>
>
> -----Original Message-----
> From: Romain Manni-Bucau [mailto:rmannibucau@gmail.com]
> Sent: Mittwoch, 3. Dezember 2014 12:18
> To: dev@tamaya.incubator.apache.org
> Subject: Re: Use Case 1: Read simple properties and get values.
>
> I don't fully agree. Where is passed through PropertyProviders so
> basically we don't need this format abstraction. Providers should just
> check it can read it or not. having such an indirection already makes
> the framework "apparently" complex enough to not be used from my point
> of view.
>
> Implementing a custom provider to read what you want is generally
> trivial enough to be where the extenisbility is.
>
>
> Romain Manni-Bucau
> @rmannibucau
> http://www.tomitribe.com
> http://rmannibucau.wordpress.com
> https://github.com/rmannibucau
>
>
> 2014-12-03 12:13 GMT+01:00 Anatole Tresch <at...@gmail.com>:
> > Far this is not the same. A provider defines where configuration is read.
> > The format defines how. Even properties files may lay at multiple
> > locations, could be locally , classpath, blobs, remotedly, ... I want to
> > support users that they are able to read configuration with minimal
> coding
> > required.
> >
> > This model is flexible and is the reason we reading in uc1 is so simple
> and
> > will be similar easy also for enterprise specific custom formats.
> Companies
> > will never change their existing formats just to use Tamaya...
> > Romain Manni-Bucau <rm...@gmail.com> schrieb am Mi., 3. Dez. 2014
> um
> > 11:45:
> >
> >> +1, ConfigFormat or PropertyProvider shouldn't be there.
> >>
> >>
> >> Romain Manni-Bucau
> >> @rmannibucau
> >> http://www.tomitribe.com
> >> http://rmannibucau.wordpress.com
> >> https://github.com/rmannibucau
> >>
> >>
> >> 2014-12-03 8:37 GMT+01:00 Oliver B. Fischer <o....@swe-blog.net>:
> >> > So if a new ConfigFormat is required for reading a different data
> source:
> >> > What is the difference between ConfigFormat and PropertyProvider?
> Isn't
> >> it
> >> > the same?
> >> >
> >> > IMHO we have to discuss the overall architecture a least a little bit
> to
> >> see
> >> > which parts exist, how they interact and who is responsible for what.
> >> >
> >> > Oliver
> >> >
> >> > Am 03.12.14 01:15, schrieb Anatole Tresch:
> >> >>
> >> >> BTW, supporting a new ConfigFormat is trivial: implementing
> >> >> ConfigurationFormat
> >> >> and register it with as component, by default using the
> ServiceLoader.
> >> >> Then you only to read the file and you are done ;)
> >> >>
> >> >> 2014-12-01 19:48 GMT+01:00 Gerhard Petracek <
> gerhard.petracek@gmail.com
> >> >:
> >> >>
> >> >>
> >> >
> >> > --
> >> > N Oliver B. Fischer
> >> > A Schönhauser Allee 64, 10437 Berlin, Deutschland/Germany
> >> > P +49 30 44793251
> >> > M +49 178 7903538
> >> > E o.b.fischer@swe-blog.net
> >> > S oliver.b.fischer
> >> > J oliver.b.fischer@jabber.org
> >> > X http://xing.to/obf
> >> >
> >>
>
RE: Use Case 1: Read simple properties and get values.
Posted by "Tresch, Anatole " <an...@credit-suisse.com>.
@Romain
The concept is - as I said - that you can describe, from which source a configuration should be read. This descriptions goes first to a reader, which knows how to resolve the location and resolves to a number of URIs/input streams.
These input streams can come in multiple formats (even mixed). Configuration Format and reader are the abstraction so you can write basically something like
PropertyProvider prov = PropertyProviders.fromPath("reader:whatever");
In the example above you can declaratively define a PropertyProvider, fast and easy, and you (by default) do not have to care on the format (BTW it is possible that multiple formats register for the same file ending).
Removing ConfigFormat means, that you
- only support a limited set of formats, or
- must implement format parsing logic yourself also for the most common cases, and
- create additional implementation dependencies on the format parsing code
- and probably you have to duplicate the logic that converts an InputStream into a Map<String,String>/ProeprtyProvider.
Finally: the project is internally split up into an API part and an implementation part. ConfigFormat is not part of the API (you typically will not code against it). If you have really want to write all your providers yourself, you can do that. Nobody prevents you doing so, but please allow other maybe less sophisticated users to benefit from provided features, so they do not have to write them themselves.
And once more, this feature was a great help for supporting muiltiple formats such as .properties, .xml (xml-properties), .ini (ini-Files). I do not see any reason we should remove something that has proven to work so nicely.
Cheers,
Anatole
-----Original Message-----
From: Romain Manni-Bucau [mailto:rmannibucau@gmail.com]
Sent: Mittwoch, 3. Dezember 2014 12:18
To: dev@tamaya.incubator.apache.org
Subject: Re: Use Case 1: Read simple properties and get values.
I don't fully agree. Where is passed through PropertyProviders so
basically we don't need this format abstraction. Providers should just
check it can read it or not. having such an indirection already makes
the framework "apparently" complex enough to not be used from my point
of view.
Implementing a custom provider to read what you want is generally
trivial enough to be where the extenisbility is.
Romain Manni-Bucau
@rmannibucau
http://www.tomitribe.com
http://rmannibucau.wordpress.com
https://github.com/rmannibucau
2014-12-03 12:13 GMT+01:00 Anatole Tresch <at...@gmail.com>:
> Far this is not the same. A provider defines where configuration is read.
> The format defines how. Even properties files may lay at multiple
> locations, could be locally , classpath, blobs, remotedly, ... I want to
> support users that they are able to read configuration with minimal coding
> required.
>
> This model is flexible and is the reason we reading in uc1 is so simple and
> will be similar easy also for enterprise specific custom formats. Companies
> will never change their existing formats just to use Tamaya...
> Romain Manni-Bucau <rm...@gmail.com> schrieb am Mi., 3. Dez. 2014 um
> 11:45:
>
>> +1, ConfigFormat or PropertyProvider shouldn't be there.
>>
>>
>> Romain Manni-Bucau
>> @rmannibucau
>> http://www.tomitribe.com
>> http://rmannibucau.wordpress.com
>> https://github.com/rmannibucau
>>
>>
>> 2014-12-03 8:37 GMT+01:00 Oliver B. Fischer <o....@swe-blog.net>:
>> > So if a new ConfigFormat is required for reading a different data source:
>> > What is the difference between ConfigFormat and PropertyProvider? Isn't
>> it
>> > the same?
>> >
>> > IMHO we have to discuss the overall architecture a least a little bit to
>> see
>> > which parts exist, how they interact and who is responsible for what.
>> >
>> > Oliver
>> >
>> > Am 03.12.14 01:15, schrieb Anatole Tresch:
>> >>
>> >> BTW, supporting a new ConfigFormat is trivial: implementing
>> >> ConfigurationFormat
>> >> and register it with as component, by default using the ServiceLoader.
>> >> Then you only to read the file and you are done ;)
>> >>
>> >> 2014-12-01 19:48 GMT+01:00 Gerhard Petracek <gerhard.petracek@gmail.com
>> >:
>> >>
>> >>
>> >
>> > --
>> > N Oliver B. Fischer
>> > A Schönhauser Allee 64, 10437 Berlin, Deutschland/Germany
>> > P +49 30 44793251
>> > M +49 178 7903538
>> > E o.b.fischer@swe-blog.net
>> > S oliver.b.fischer
>> > J oliver.b.fischer@jabber.org
>> > X http://xing.to/obf
>> >
>>
Re: Use Case 1: Read simple properties and get values.
Posted by Romain Manni-Bucau <rm...@gmail.com>.
I don't fully agree. Where is passed through PropertyProviders so
basically we don't need this format abstraction. Providers should just
check it can read it or not. having such an indirection already makes
the framework "apparently" complex enough to not be used from my point
of view.
Implementing a custom provider to read what you want is generally
trivial enough to be where the extenisbility is.
Romain Manni-Bucau
@rmannibucau
http://www.tomitribe.com
http://rmannibucau.wordpress.com
https://github.com/rmannibucau
2014-12-03 12:13 GMT+01:00 Anatole Tresch <at...@gmail.com>:
> Far this is not the same. A provider defines where configuration is read.
> The format defines how. Even properties files may lay at multiple
> locations, could be locally , classpath, blobs, remotedly, ... I want to
> support users that they are able to read configuration with minimal coding
> required.
>
> This model is flexible and is the reason we reading in uc1 is so simple and
> will be similar easy also for enterprise specific custom formats. Companies
> will never change their existing formats just to use Tamaya...
> Romain Manni-Bucau <rm...@gmail.com> schrieb am Mi., 3. Dez. 2014 um
> 11:45:
>
>> +1, ConfigFormat or PropertyProvider shouldn't be there.
>>
>>
>> Romain Manni-Bucau
>> @rmannibucau
>> http://www.tomitribe.com
>> http://rmannibucau.wordpress.com
>> https://github.com/rmannibucau
>>
>>
>> 2014-12-03 8:37 GMT+01:00 Oliver B. Fischer <o....@swe-blog.net>:
>> > So if a new ConfigFormat is required for reading a different data source:
>> > What is the difference between ConfigFormat and PropertyProvider? Isn't
>> it
>> > the same?
>> >
>> > IMHO we have to discuss the overall architecture a least a little bit to
>> see
>> > which parts exist, how they interact and who is responsible for what.
>> >
>> > Oliver
>> >
>> > Am 03.12.14 01:15, schrieb Anatole Tresch:
>> >>
>> >> BTW, supporting a new ConfigFormat is trivial: implementing
>> >> ConfigurationFormat
>> >> and register it with as component, by default using the ServiceLoader.
>> >> Then you only to read the file and you are done ;)
>> >>
>> >> 2014-12-01 19:48 GMT+01:00 Gerhard Petracek <gerhard.petracek@gmail.com
>> >:
>> >>
>> >>
>> >
>> > --
>> > N Oliver B. Fischer
>> > A Schönhauser Allee 64, 10437 Berlin, Deutschland/Germany
>> > P +49 30 44793251
>> > M +49 178 7903538
>> > E o.b.fischer@swe-blog.net
>> > S oliver.b.fischer
>> > J oliver.b.fischer@jabber.org
>> > X http://xing.to/obf
>> >
>>
Re: Use Case 1: Read simple properties and get values.
Posted by Anatole Tresch <at...@gmail.com>.
Far this is not the same. A provider defines where configuration is read.
The format defines how. Even properties files may lay at multiple
locations, could be locally , classpath, blobs, remotedly, ... I want to
support users that they are able to read configuration with minimal coding
required.
This model is flexible and is the reason we reading in uc1 is so simple and
will be similar easy also for enterprise specific custom formats. Companies
will never change their existing formats just to use Tamaya...
Romain Manni-Bucau <rm...@gmail.com> schrieb am Mi., 3. Dez. 2014 um
11:45:
> +1, ConfigFormat or PropertyProvider shouldn't be there.
>
>
> Romain Manni-Bucau
> @rmannibucau
> http://www.tomitribe.com
> http://rmannibucau.wordpress.com
> https://github.com/rmannibucau
>
>
> 2014-12-03 8:37 GMT+01:00 Oliver B. Fischer <o....@swe-blog.net>:
> > So if a new ConfigFormat is required for reading a different data source:
> > What is the difference between ConfigFormat and PropertyProvider? Isn't
> it
> > the same?
> >
> > IMHO we have to discuss the overall architecture a least a little bit to
> see
> > which parts exist, how they interact and who is responsible for what.
> >
> > Oliver
> >
> > Am 03.12.14 01:15, schrieb Anatole Tresch:
> >>
> >> BTW, supporting a new ConfigFormat is trivial: implementing
> >> ConfigurationFormat
> >> and register it with as component, by default using the ServiceLoader.
> >> Then you only to read the file and you are done ;)
> >>
> >> 2014-12-01 19:48 GMT+01:00 Gerhard Petracek <gerhard.petracek@gmail.com
> >:
> >>
> >>
> >
> > --
> > N Oliver B. Fischer
> > A Schönhauser Allee 64, 10437 Berlin, Deutschland/Germany
> > P +49 30 44793251
> > M +49 178 7903538
> > E o.b.fischer@swe-blog.net
> > S oliver.b.fischer
> > J oliver.b.fischer@jabber.org
> > X http://xing.to/obf
> >
>
Re: Use Case 1: Read simple properties and get values.
Posted by Anatole Tresch <at...@gmail.com>.
-100 these are core concepts (see mail before).
Romain Manni-Bucau <rm...@gmail.com> schrieb am Mi., 3. Dez. 2014 um
11:45:
> +1, ConfigFormat or PropertyProvider shouldn't be there.
>
>
> Romain Manni-Bucau
> @rmannibucau
> http://www.tomitribe.com
> http://rmannibucau.wordpress.com
> https://github.com/rmannibucau
>
>
> 2014-12-03 8:37 GMT+01:00 Oliver B. Fischer <o....@swe-blog.net>:
> > So if a new ConfigFormat is required for reading a different data source:
> > What is the difference between ConfigFormat and PropertyProvider? Isn't
> it
> > the same?
> >
> > IMHO we have to discuss the overall architecture a least a little bit to
> see
> > which parts exist, how they interact and who is responsible for what.
> >
> > Oliver
> >
> > Am 03.12.14 01:15, schrieb Anatole Tresch:
> >>
> >> BTW, supporting a new ConfigFormat is trivial: implementing
> >> ConfigurationFormat
> >> and register it with as component, by default using the ServiceLoader.
> >> Then you only to read the file and you are done ;)
> >>
> >> 2014-12-01 19:48 GMT+01:00 Gerhard Petracek <gerhard.petracek@gmail.com
> >:
> >>
> >>
> >
> > --
> > N Oliver B. Fischer
> > A Schönhauser Allee 64, 10437 Berlin, Deutschland/Germany
> > P +49 30 44793251
> > M +49 178 7903538
> > E o.b.fischer@swe-blog.net
> > S oliver.b.fischer
> > J oliver.b.fischer@jabber.org
> > X http://xing.to/obf
> >
>
Re: Use Case 1: Read simple properties and get values.
Posted by Romain Manni-Bucau <rm...@gmail.com>.
+1, ConfigFormat or PropertyProvider shouldn't be there.
Romain Manni-Bucau
@rmannibucau
http://www.tomitribe.com
http://rmannibucau.wordpress.com
https://github.com/rmannibucau
2014-12-03 8:37 GMT+01:00 Oliver B. Fischer <o....@swe-blog.net>:
> So if a new ConfigFormat is required for reading a different data source:
> What is the difference between ConfigFormat and PropertyProvider? Isn't it
> the same?
>
> IMHO we have to discuss the overall architecture a least a little bit to see
> which parts exist, how they interact and who is responsible for what.
>
> Oliver
>
> Am 03.12.14 01:15, schrieb Anatole Tresch:
>>
>> BTW, supporting a new ConfigFormat is trivial: implementing
>> ConfigurationFormat
>> and register it with as component, by default using the ServiceLoader.
>> Then you only to read the file and you are done ;)
>>
>> 2014-12-01 19:48 GMT+01:00 Gerhard Petracek <ge...@gmail.com>:
>>
>>
>
> --
> N Oliver B. Fischer
> A Schönhauser Allee 64, 10437 Berlin, Deutschland/Germany
> P +49 30 44793251
> M +49 178 7903538
> E o.b.fischer@swe-blog.net
> S oliver.b.fischer
> J oliver.b.fischer@jabber.org
> X http://xing.to/obf
>
Re: Use Case 1: Read simple properties and get values.
Posted by "Oliver B. Fischer" <o....@swe-blog.net>.
So if a new ConfigFormat is required for reading a different data
source: What is the difference between ConfigFormat and
PropertyProvider? Isn't it the same?
IMHO we have to discuss the overall architecture a least a little bit to
see which parts exist, how they interact and who is responsible for what.
Oliver
Am 03.12.14 01:15, schrieb Anatole Tresch:
> BTW, supporting a new ConfigFormat is trivial: implementing ConfigurationFormat
> and register it with as component, by default using the ServiceLoader.
> Then you only to read the file and you are done ;)
>
> 2014-12-01 19:48 GMT+01:00 Gerhard Petracek <ge...@gmail.com>:
>
>
--
N Oliver B. Fischer
A Schönhauser Allee 64, 10437 Berlin, Deutschland/Germany
P +49 30 44793251
M +49 178 7903538
E o.b.fischer@swe-blog.net
S oliver.b.fischer
J oliver.b.fischer@jabber.org
X http://xing.to/obf
Re: Use Case 1: Read simple properties and get values.
Posted by Gerhard Petracek <ge...@gmail.com>.
@anatole:
as i see such an interface is in place already -> we will get to it anyway.
regards,
gerhard
2014-12-01 21:11 GMT+01:00 Anatole Tresch <at...@gmail.com>:
> Hi Gerhard
>
> the idea is that we have a extensive Environment API. We can even model it
> as a separate module, so if someone likes it, it can be used even without
> the config part.
> There are providers, different environment types and concrete environment
> context ids. From a usage perspective it is simple:
>
> Environment env = Environment.current();
>
> I have some ideas and also got various input on this topic, nevertheless
> this is an area, were I think, things are worth looking at it in deep ;) As
> of now, I would simply ignore it (or take it as given...) until we focu
> again on the runtime assembly part.
> Tamaya here could come with related modules, so users only have to add the
> modules to their classpath to have the corresponding environment modelling
> features in place. Basic root env I assume will be added as part of the
> environment core part...
>
> Was that your ide as well...?
>
>
>
> 2014-12-01 20:03 GMT+01:00 Gerhard Petracek <ge...@gmail.com>:
>
> > @anatole:
> > Environment.* would work (for me), if you control the whole environment
> > with an api.
> > then you could use Environment.config() and other parts like
> > Environment.validation()
> > ...
> > however, we don't have that and therefore the term should be closer to
> > "config" imo.
> >
> > regards,
> > gerhard
> >
> >
> >
> > 2014-12-01 19:54 GMT+01:00 Anatole Tresch <at...@gmail.com>:
> >
> > > YES! As I said this would be a topic for later IMO. Looking at the
> > > discussions so far I would call it* Environment.current() *(instead of
> > of()
> > > ). For getting configuration right you must have an environment model
> in
> > > place that is very flexible (basically I tend to say modelling and
> > > implementing the environment provider is more complex, than assembling
> > the
> > > configuration that is relevant to that environment)...
> > >
> > >
> > > 2014-12-01 19:20 GMT+01:00 Werner Keil <we...@gmail.com>:
> > >
> > > > If you get one by app, is there any form of "context" you'd pass to
> > such
> > > > factory method?
> > > >
> > > > Currency.getInstance() returns exactly one singleton instance of a
> > > Currency
> > > > class (otherwise has no constructor either) for a given currency
> code.
> > > > While Money.of() in JSR 354 RI returns totally different instances
> > > > depending on the combination of (nearly unlimited) different numbers
> > and
> > > > currency codes. 354 tries to broaden the definition of Currency, but
> if
> > > you
> > > > get exactly one distinct instance per VM/app that's a singleton IMHO
> > even
> > > > if you may call the same application multiple times.
> > > >
> > > > On Mon, Dec 1, 2014 at 7:12 PM, Romain Manni-Bucau <
> > > rmannibucau@gmail.com>
> > > > wrote:
> > > >
> > > > > Hmm,
> > > > >
> > > > > for me getInstance() = singleton in term of instance where
> > > > > Configuration will be all but a singleton IMO (you'll get at least
> > one
> > > > > by app and surely a new instance each time you call it) no?
> > > > >
> > > > >
> > > > > Romain Manni-Bucau
> > > > > @rmannibucau
> > > > > http://www.tomitribe.com
> > > > > http://rmannibucau.wordpress.com
> > > > > https://github.com/rmannibucau
> > > > >
> > > > >
> > > > > 2014-12-01 18:56 GMT+01:00 Werner Keil <we...@gmail.com>:
> > > > > > Hi,
> > > > > >
> > > > > > Adding to the question of convenience factories, there is no such
> > > thing
> > > > > as
> > > > > > "naming convention" by Stephen Colebourne or JSR 310. In fact, it
> > > > > violates
> > > > > > or bends almost every one of them in itself, so a suggestion like
> > > > > > Configuration.current() would sound very similar to the
> > > > > LocalDateTime.now()
> > > > > > ones in 310.
> > > > > > For several other cases of() or longer variations (like ofMilli()
> > > > > ofNanos()
> > > > > > etc.;-O) are used, while static factories from strings similar to
> > > what
> > > > > JSR
> > > > > > 354 adopted are called parse(String).
> > > > > >
> > > > > > Josh Bloch defined a clear distinction between what he then in
> most
> > > > cases
> > > > > > (except EnumSet, that's where he started using of() so Josh also
> > > > > "invented"
> > > > > > that while it violated some of his earlier naming conventions;-D)
> > > > called
> > > > > > valueOf() and getInstance(), see
> > > > > >
> > > > >
> > > >
> > >
> >
> http://blog.codefront.net/2003/06/21/java-tip-2-static-factory-methods-vs-constructors/
> > > > > > getInstance() returns a singleton, either the only instance for
> > this
> > > > type
> > > > > > of object or the only instance for a distinct code or enum (see
> > > > > > java.util.Currency)
> > > > > >
> > > > > > Very recent APIs and JSRs like MEEP 8 make a clear distinction,
> and
> > > > > classes
> > > > > > like
> > > > > >
> > > > >
> > > >
> > >
> >
> https://docs.oracle.com/javame/8.0/api/meep/api/javax/microedition/event/EventManager.html
> > > > > > clearly explain that, too. In other places ME 8 uses of() where
> > > > > appropriate.
> > > > > > So at least getInstance() is neither outdated nor wrong, it just
> > > > depends
> > > > > on
> > > > > > what you return.
> > > > > >
> > > > > > If Configuration returns just a default instance then
> > > > > > Configuration.getInstance() seems appropriate.
> > > > > >
> > > > > >
> > > > > > Werner Keil | JCP Executive Committee Member, JSR 363 Co Spec
> > Lead |
> > > > > > Eclipse UOMo Lead, Babel Language Champion | Apache Committer
> > > > > >
> > > > > > Twitter @wernerkeil | @UnitAPI | @JSR354 | @DeviceMap |
> > #EclipseUOMo
> > > |
> > > > > > #Java_Social
> > > > > > | #DevOps
> > > > > > Skype werner.keil | Google+ gplus.to/wernerkeil
> > > > > >
> > > > > > On Mon, Dec 1, 2014 at 6:31 PM, Oliver B. Fischer <
> > > > > o.b.fischer@swe-blog.net>
> > > > > > wrote:
> > > > > >
> > > > > >> Hi,
> > > > > >>
> > > > > >> for me the most simple use case is
> > > > > >>
> > > > > >> Configuration conf = new Configuration();
> > > > > >> String value = conf.get("key")
> > > > > >>
> > > > > >> And this use case is already very complex under the hood.
> > > > > >>
> > > > > >> Before discussing other details we have to decide how
> > > > PropertyProviders
> > > > > >> are activated.
> > > > > >>
> > > > > >> I would like to have the following possibilites:
> > > > > >>
> > > > > >> 1. Tamaya activates all PropertyProviders found in the classpath
> > and
> > > > > >> activated via SPI.
> > > > > >> 2. Tamaya activates only a explicitly named list of Property
> > > providers
> > > > > >> 3. I have the ability to control the order in which the property
> > > > > solution
> > > > > >> will be performed
> > > > > >>
> > > > > >> Bye,
> > > > > >>
> > > > > >> Oliver
> > > > > >>
> > > > > >>
> > > > > >> Am 01.12.14 17:54, schrieb Romain Manni-Bucau:
> > > > > >>
> > > > > >>> Configuration.current() sounds easier to understand first time
> > you
> > > > see
> > > > > >>> it. I like Configuration.newInstance() if that's really what it
> > > does
> > > > > >>> (ie no caching by classloader or anything else).
> > > > > >>>
> > > > > >>>
> > > > > >>> Romain Manni-Bucau
> > > > > >>> @rmannibucau
> > > > > >>> http://www.tomitribe.com
> > > > > >>> http://rmannibucau.wordpress.com
> > > > > >>> https://github.com/rmannibucau
> > > > > >>>
> > > > > >>>
> > > > > >>> 2014-12-01 17:42 GMT+01:00 Anatole Tresch <atsticks@gmail.com
> >:
> > > > > >>>
> > > > > >>>> There is a naming concept from Stephen Colebourne when to use
> > of,
> > > > > from,
> > > > > >>>> with. I try to lookup the link later, see also jsr 310 and
> 354.
> > > > > >>>> getInstance, valueOf are considered to be outdated for modern
> > api
> > > > > design.
> > > > > >>>>
> > > > > >>>> Adding a helper, why? Another artifact a user must know, makes
> > > > sense,
> > > > > >>>> where
> > > > > >>>> you have a huge acces api IMO (see PropertyProviders where the
> > > > factory
> > > > > >>>> methods are not part of the PropertyProvider interface. For
> > > > > >>>> Configuration I
> > > > > >>>> prefer having sn intuitive simple/single access...
> > > > > >>>>
> > > > > >>>> Nevertheless I would like to encourage you to make a concrete
> > > > proposal
> > > > > >>>> how
> > > > > >>>> would name things, so we can compare what your idea of fluent
> is
> > > ;)
> > > > > >>>>
> > > > > >>>> -anatole
> > > > > >>>> Gerhard Petracek <ge...@gmail.com> schrieb am Mo.,
> > 1.
> > > > Dez.
> > > > > >>>> 2014
> > > > > >>>> um 17:24:
> > > > > >>>>
> > > > > >>>> 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
> > > > > >>>>> <anatole.tresch@credit-suisse.
> > > > > >>>>> com
> > > > > >>>>>
> > > > > >>>>>> :
> > > > > >>>>>> 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:gerhard.petracek@gmail.com]
> > > > > >>>>>> Sent: Montag, 1. Dezember 2014 14:30
> > > > > >>>>>> To: dev@tamaya.incubator.apache.org
> > > > > >>>>>> 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 <
> anatole@apache.org
> > >:
> > > > > >>>>>>
> > > > > >>>>>> 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 <ge...@gmail.com> 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 <
> > > > > rmannibucau@gmail.com
> > > > > >>>>>>>>
> > > > > >>>>>>> :
> > > > > >>>>>>
> > > > > >>>>>>> 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 <
> > > anatole@apache.org
> > > > >:
> > > > > >>>>>>>>>
> > > > > >>>>>>>>>> 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
> > > > > >>>>>>>>>>
> > > > > >>>>>>>>>>
> > > > > >> --
> > > > > >> N Oliver B. Fischer
> > > > > >> A Schönhauser Allee 64, 10437 Berlin, Deutschland/Germany
> > > > > >> P +49 30 44793251
> > > > > >> M +49 178 7903538
> > > > > >> E o.b.fischer@swe-blog.net
> > > > > >> S oliver.b.fischer
> > > > > >> J oliver.b.fischer@jabber.org
> > > > > >> X http://xing.to/obf
> > > > > >>
> > > > > >>
> > > > >
> > > >
> > >
> > >
> > >
> > > --
> > > *Anatole Tresch*
> > > Java Engineer & Architect, JSR Spec Lead
> > > Glärnischweg 10
> > > CH - 8620 Wetzikon
> > >
> > > *Switzerland, Europe Zurich, GMT+1*
> > > *Twitter: @atsticks*
> > > *Blogs: **http://javaremarkables.blogspot.ch/
> > > <http://javaremarkables.blogspot.ch/>*
> > >
> > > *Google: atsticksMobile +41-76 344 62 79*
> > >
> >
>
>
>
> --
> *Anatole Tresch*
> Java Engineer & Architect, JSR Spec Lead
> Glärnischweg 10
> CH - 8620 Wetzikon
>
> *Switzerland, Europe Zurich, GMT+1*
> *Twitter: @atsticks*
> *Blogs: **http://javaremarkables.blogspot.ch/
> <http://javaremarkables.blogspot.ch/>*
>
> *Google: atsticksMobile +41-76 344 62 79*
>
Re: Use Case 1: Read simple properties and get values.
Posted by Anatole Tresch <at...@gmail.com>.
Hi Gerhard
the idea is that we have a extensive Environment API. We can even model it
as a separate module, so if someone likes it, it can be used even without
the config part.
There are providers, different environment types and concrete environment
context ids. From a usage perspective it is simple:
Environment env = Environment.current();
I have some ideas and also got various input on this topic, nevertheless
this is an area, were I think, things are worth looking at it in deep ;) As
of now, I would simply ignore it (or take it as given...) until we focu
again on the runtime assembly part.
Tamaya here could come with related modules, so users only have to add the
modules to their classpath to have the corresponding environment modelling
features in place. Basic root env I assume will be added as part of the
environment core part...
Was that your ide as well...?
2014-12-01 20:03 GMT+01:00 Gerhard Petracek <ge...@gmail.com>:
> @anatole:
> Environment.* would work (for me), if you control the whole environment
> with an api.
> then you could use Environment.config() and other parts like
> Environment.validation()
> ...
> however, we don't have that and therefore the term should be closer to
> "config" imo.
>
> regards,
> gerhard
>
>
>
> 2014-12-01 19:54 GMT+01:00 Anatole Tresch <at...@gmail.com>:
>
> > YES! As I said this would be a topic for later IMO. Looking at the
> > discussions so far I would call it* Environment.current() *(instead of
> of()
> > ). For getting configuration right you must have an environment model in
> > place that is very flexible (basically I tend to say modelling and
> > implementing the environment provider is more complex, than assembling
> the
> > configuration that is relevant to that environment)...
> >
> >
> > 2014-12-01 19:20 GMT+01:00 Werner Keil <we...@gmail.com>:
> >
> > > If you get one by app, is there any form of "context" you'd pass to
> such
> > > factory method?
> > >
> > > Currency.getInstance() returns exactly one singleton instance of a
> > Currency
> > > class (otherwise has no constructor either) for a given currency code.
> > > While Money.of() in JSR 354 RI returns totally different instances
> > > depending on the combination of (nearly unlimited) different numbers
> and
> > > currency codes. 354 tries to broaden the definition of Currency, but if
> > you
> > > get exactly one distinct instance per VM/app that's a singleton IMHO
> even
> > > if you may call the same application multiple times.
> > >
> > > On Mon, Dec 1, 2014 at 7:12 PM, Romain Manni-Bucau <
> > rmannibucau@gmail.com>
> > > wrote:
> > >
> > > > Hmm,
> > > >
> > > > for me getInstance() = singleton in term of instance where
> > > > Configuration will be all but a singleton IMO (you'll get at least
> one
> > > > by app and surely a new instance each time you call it) no?
> > > >
> > > >
> > > > Romain Manni-Bucau
> > > > @rmannibucau
> > > > http://www.tomitribe.com
> > > > http://rmannibucau.wordpress.com
> > > > https://github.com/rmannibucau
> > > >
> > > >
> > > > 2014-12-01 18:56 GMT+01:00 Werner Keil <we...@gmail.com>:
> > > > > Hi,
> > > > >
> > > > > Adding to the question of convenience factories, there is no such
> > thing
> > > > as
> > > > > "naming convention" by Stephen Colebourne or JSR 310. In fact, it
> > > > violates
> > > > > or bends almost every one of them in itself, so a suggestion like
> > > > > Configuration.current() would sound very similar to the
> > > > LocalDateTime.now()
> > > > > ones in 310.
> > > > > For several other cases of() or longer variations (like ofMilli()
> > > > ofNanos()
> > > > > etc.;-O) are used, while static factories from strings similar to
> > what
> > > > JSR
> > > > > 354 adopted are called parse(String).
> > > > >
> > > > > Josh Bloch defined a clear distinction between what he then in most
> > > cases
> > > > > (except EnumSet, that's where he started using of() so Josh also
> > > > "invented"
> > > > > that while it violated some of his earlier naming conventions;-D)
> > > called
> > > > > valueOf() and getInstance(), see
> > > > >
> > > >
> > >
> >
> http://blog.codefront.net/2003/06/21/java-tip-2-static-factory-methods-vs-constructors/
> > > > > getInstance() returns a singleton, either the only instance for
> this
> > > type
> > > > > of object or the only instance for a distinct code or enum (see
> > > > > java.util.Currency)
> > > > >
> > > > > Very recent APIs and JSRs like MEEP 8 make a clear distinction, and
> > > > classes
> > > > > like
> > > > >
> > > >
> > >
> >
> https://docs.oracle.com/javame/8.0/api/meep/api/javax/microedition/event/EventManager.html
> > > > > clearly explain that, too. In other places ME 8 uses of() where
> > > > appropriate.
> > > > > So at least getInstance() is neither outdated nor wrong, it just
> > > depends
> > > > on
> > > > > what you return.
> > > > >
> > > > > If Configuration returns just a default instance then
> > > > > Configuration.getInstance() seems appropriate.
> > > > >
> > > > >
> > > > > Werner Keil | JCP Executive Committee Member, JSR 363 Co Spec
> Lead |
> > > > > Eclipse UOMo Lead, Babel Language Champion | Apache Committer
> > > > >
> > > > > Twitter @wernerkeil | @UnitAPI | @JSR354 | @DeviceMap |
> #EclipseUOMo
> > |
> > > > > #Java_Social
> > > > > | #DevOps
> > > > > Skype werner.keil | Google+ gplus.to/wernerkeil
> > > > >
> > > > > On Mon, Dec 1, 2014 at 6:31 PM, Oliver B. Fischer <
> > > > o.b.fischer@swe-blog.net>
> > > > > wrote:
> > > > >
> > > > >> Hi,
> > > > >>
> > > > >> for me the most simple use case is
> > > > >>
> > > > >> Configuration conf = new Configuration();
> > > > >> String value = conf.get("key")
> > > > >>
> > > > >> And this use case is already very complex under the hood.
> > > > >>
> > > > >> Before discussing other details we have to decide how
> > > PropertyProviders
> > > > >> are activated.
> > > > >>
> > > > >> I would like to have the following possibilites:
> > > > >>
> > > > >> 1. Tamaya activates all PropertyProviders found in the classpath
> and
> > > > >> activated via SPI.
> > > > >> 2. Tamaya activates only a explicitly named list of Property
> > providers
> > > > >> 3. I have the ability to control the order in which the property
> > > > solution
> > > > >> will be performed
> > > > >>
> > > > >> Bye,
> > > > >>
> > > > >> Oliver
> > > > >>
> > > > >>
> > > > >> Am 01.12.14 17:54, schrieb Romain Manni-Bucau:
> > > > >>
> > > > >>> Configuration.current() sounds easier to understand first time
> you
> > > see
> > > > >>> it. I like Configuration.newInstance() if that's really what it
> > does
> > > > >>> (ie no caching by classloader or anything else).
> > > > >>>
> > > > >>>
> > > > >>> Romain Manni-Bucau
> > > > >>> @rmannibucau
> > > > >>> http://www.tomitribe.com
> > > > >>> http://rmannibucau.wordpress.com
> > > > >>> https://github.com/rmannibucau
> > > > >>>
> > > > >>>
> > > > >>> 2014-12-01 17:42 GMT+01:00 Anatole Tresch <at...@gmail.com>:
> > > > >>>
> > > > >>>> There is a naming concept from Stephen Colebourne when to use
> of,
> > > > from,
> > > > >>>> with. I try to lookup the link later, see also jsr 310 and 354.
> > > > >>>> getInstance, valueOf are considered to be outdated for modern
> api
> > > > design.
> > > > >>>>
> > > > >>>> Adding a helper, why? Another artifact a user must know, makes
> > > sense,
> > > > >>>> where
> > > > >>>> you have a huge acces api IMO (see PropertyProviders where the
> > > factory
> > > > >>>> methods are not part of the PropertyProvider interface. For
> > > > >>>> Configuration I
> > > > >>>> prefer having sn intuitive simple/single access...
> > > > >>>>
> > > > >>>> Nevertheless I would like to encourage you to make a concrete
> > > proposal
> > > > >>>> how
> > > > >>>> would name things, so we can compare what your idea of fluent is
> > ;)
> > > > >>>>
> > > > >>>> -anatole
> > > > >>>> Gerhard Petracek <ge...@gmail.com> schrieb am Mo.,
> 1.
> > > Dez.
> > > > >>>> 2014
> > > > >>>> um 17:24:
> > > > >>>>
> > > > >>>> 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
> > > > >>>>> <anatole.tresch@credit-suisse.
> > > > >>>>> com
> > > > >>>>>
> > > > >>>>>> :
> > > > >>>>>> 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:gerhard.petracek@gmail.com]
> > > > >>>>>> Sent: Montag, 1. Dezember 2014 14:30
> > > > >>>>>> To: dev@tamaya.incubator.apache.org
> > > > >>>>>> 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 <anatole@apache.org
> >:
> > > > >>>>>>
> > > > >>>>>> 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 <ge...@gmail.com> 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 <
> > > > rmannibucau@gmail.com
> > > > >>>>>>>>
> > > > >>>>>>> :
> > > > >>>>>>
> > > > >>>>>>> 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 <
> > anatole@apache.org
> > > >:
> > > > >>>>>>>>>
> > > > >>>>>>>>>> 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
> > > > >>>>>>>>>>
> > > > >>>>>>>>>>
> > > > >> --
> > > > >> N Oliver B. Fischer
> > > > >> A Schönhauser Allee 64, 10437 Berlin, Deutschland/Germany
> > > > >> P +49 30 44793251
> > > > >> M +49 178 7903538
> > > > >> E o.b.fischer@swe-blog.net
> > > > >> S oliver.b.fischer
> > > > >> J oliver.b.fischer@jabber.org
> > > > >> X http://xing.to/obf
> > > > >>
> > > > >>
> > > >
> > >
> >
> >
> >
> > --
> > *Anatole Tresch*
> > Java Engineer & Architect, JSR Spec Lead
> > Glärnischweg 10
> > CH - 8620 Wetzikon
> >
> > *Switzerland, Europe Zurich, GMT+1*
> > *Twitter: @atsticks*
> > *Blogs: **http://javaremarkables.blogspot.ch/
> > <http://javaremarkables.blogspot.ch/>*
> >
> > *Google: atsticksMobile +41-76 344 62 79*
> >
>
--
*Anatole Tresch*
Java Engineer & Architect, JSR Spec Lead
Glärnischweg 10
CH - 8620 Wetzikon
*Switzerland, Europe Zurich, GMT+1*
*Twitter: @atsticks*
*Blogs: **http://javaremarkables.blogspot.ch/
<http://javaremarkables.blogspot.ch/>*
*Google: atsticksMobile +41-76 344 62 79*
Re: Use Case 1: Read simple properties and get values.
Posted by Gerhard Petracek <ge...@gmail.com>.
@anatole:
Environment.* would work (for me), if you control the whole environment
with an api.
then you could use Environment.config() and other parts like
Environment.validation()
...
however, we don't have that and therefore the term should be closer to
"config" imo.
regards,
gerhard
2014-12-01 19:54 GMT+01:00 Anatole Tresch <at...@gmail.com>:
> YES! As I said this would be a topic for later IMO. Looking at the
> discussions so far I would call it* Environment.current() *(instead of of()
> ). For getting configuration right you must have an environment model in
> place that is very flexible (basically I tend to say modelling and
> implementing the environment provider is more complex, than assembling the
> configuration that is relevant to that environment)...
>
>
> 2014-12-01 19:20 GMT+01:00 Werner Keil <we...@gmail.com>:
>
> > If you get one by app, is there any form of "context" you'd pass to such
> > factory method?
> >
> > Currency.getInstance() returns exactly one singleton instance of a
> Currency
> > class (otherwise has no constructor either) for a given currency code.
> > While Money.of() in JSR 354 RI returns totally different instances
> > depending on the combination of (nearly unlimited) different numbers and
> > currency codes. 354 tries to broaden the definition of Currency, but if
> you
> > get exactly one distinct instance per VM/app that's a singleton IMHO even
> > if you may call the same application multiple times.
> >
> > On Mon, Dec 1, 2014 at 7:12 PM, Romain Manni-Bucau <
> rmannibucau@gmail.com>
> > wrote:
> >
> > > Hmm,
> > >
> > > for me getInstance() = singleton in term of instance where
> > > Configuration will be all but a singleton IMO (you'll get at least one
> > > by app and surely a new instance each time you call it) no?
> > >
> > >
> > > Romain Manni-Bucau
> > > @rmannibucau
> > > http://www.tomitribe.com
> > > http://rmannibucau.wordpress.com
> > > https://github.com/rmannibucau
> > >
> > >
> > > 2014-12-01 18:56 GMT+01:00 Werner Keil <we...@gmail.com>:
> > > > Hi,
> > > >
> > > > Adding to the question of convenience factories, there is no such
> thing
> > > as
> > > > "naming convention" by Stephen Colebourne or JSR 310. In fact, it
> > > violates
> > > > or bends almost every one of them in itself, so a suggestion like
> > > > Configuration.current() would sound very similar to the
> > > LocalDateTime.now()
> > > > ones in 310.
> > > > For several other cases of() or longer variations (like ofMilli()
> > > ofNanos()
> > > > etc.;-O) are used, while static factories from strings similar to
> what
> > > JSR
> > > > 354 adopted are called parse(String).
> > > >
> > > > Josh Bloch defined a clear distinction between what he then in most
> > cases
> > > > (except EnumSet, that's where he started using of() so Josh also
> > > "invented"
> > > > that while it violated some of his earlier naming conventions;-D)
> > called
> > > > valueOf() and getInstance(), see
> > > >
> > >
> >
> http://blog.codefront.net/2003/06/21/java-tip-2-static-factory-methods-vs-constructors/
> > > > getInstance() returns a singleton, either the only instance for this
> > type
> > > > of object or the only instance for a distinct code or enum (see
> > > > java.util.Currency)
> > > >
> > > > Very recent APIs and JSRs like MEEP 8 make a clear distinction, and
> > > classes
> > > > like
> > > >
> > >
> >
> https://docs.oracle.com/javame/8.0/api/meep/api/javax/microedition/event/EventManager.html
> > > > clearly explain that, too. In other places ME 8 uses of() where
> > > appropriate.
> > > > So at least getInstance() is neither outdated nor wrong, it just
> > depends
> > > on
> > > > what you return.
> > > >
> > > > If Configuration returns just a default instance then
> > > > Configuration.getInstance() seems appropriate.
> > > >
> > > >
> > > > Werner Keil | JCP Executive Committee Member, JSR 363 Co Spec Lead |
> > > > Eclipse UOMo Lead, Babel Language Champion | Apache Committer
> > > >
> > > > Twitter @wernerkeil | @UnitAPI | @JSR354 | @DeviceMap | #EclipseUOMo
> |
> > > > #Java_Social
> > > > | #DevOps
> > > > Skype werner.keil | Google+ gplus.to/wernerkeil
> > > >
> > > > On Mon, Dec 1, 2014 at 6:31 PM, Oliver B. Fischer <
> > > o.b.fischer@swe-blog.net>
> > > > wrote:
> > > >
> > > >> Hi,
> > > >>
> > > >> for me the most simple use case is
> > > >>
> > > >> Configuration conf = new Configuration();
> > > >> String value = conf.get("key")
> > > >>
> > > >> And this use case is already very complex under the hood.
> > > >>
> > > >> Before discussing other details we have to decide how
> > PropertyProviders
> > > >> are activated.
> > > >>
> > > >> I would like to have the following possibilites:
> > > >>
> > > >> 1. Tamaya activates all PropertyProviders found in the classpath and
> > > >> activated via SPI.
> > > >> 2. Tamaya activates only a explicitly named list of Property
> providers
> > > >> 3. I have the ability to control the order in which the property
> > > solution
> > > >> will be performed
> > > >>
> > > >> Bye,
> > > >>
> > > >> Oliver
> > > >>
> > > >>
> > > >> Am 01.12.14 17:54, schrieb Romain Manni-Bucau:
> > > >>
> > > >>> Configuration.current() sounds easier to understand first time you
> > see
> > > >>> it. I like Configuration.newInstance() if that's really what it
> does
> > > >>> (ie no caching by classloader or anything else).
> > > >>>
> > > >>>
> > > >>> Romain Manni-Bucau
> > > >>> @rmannibucau
> > > >>> http://www.tomitribe.com
> > > >>> http://rmannibucau.wordpress.com
> > > >>> https://github.com/rmannibucau
> > > >>>
> > > >>>
> > > >>> 2014-12-01 17:42 GMT+01:00 Anatole Tresch <at...@gmail.com>:
> > > >>>
> > > >>>> There is a naming concept from Stephen Colebourne when to use of,
> > > from,
> > > >>>> with. I try to lookup the link later, see also jsr 310 and 354.
> > > >>>> getInstance, valueOf are considered to be outdated for modern api
> > > design.
> > > >>>>
> > > >>>> Adding a helper, why? Another artifact a user must know, makes
> > sense,
> > > >>>> where
> > > >>>> you have a huge acces api IMO (see PropertyProviders where the
> > factory
> > > >>>> methods are not part of the PropertyProvider interface. For
> > > >>>> Configuration I
> > > >>>> prefer having sn intuitive simple/single access...
> > > >>>>
> > > >>>> Nevertheless I would like to encourage you to make a concrete
> > proposal
> > > >>>> how
> > > >>>> would name things, so we can compare what your idea of fluent is
> ;)
> > > >>>>
> > > >>>> -anatole
> > > >>>> Gerhard Petracek <ge...@gmail.com> schrieb am Mo., 1.
> > Dez.
> > > >>>> 2014
> > > >>>> um 17:24:
> > > >>>>
> > > >>>> 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
> > > >>>>> <anatole.tresch@credit-suisse.
> > > >>>>> com
> > > >>>>>
> > > >>>>>> :
> > > >>>>>> 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:gerhard.petracek@gmail.com]
> > > >>>>>> Sent: Montag, 1. Dezember 2014 14:30
> > > >>>>>> To: dev@tamaya.incubator.apache.org
> > > >>>>>> 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 <an...@apache.org>:
> > > >>>>>>
> > > >>>>>> 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 <ge...@gmail.com> 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 <
> > > rmannibucau@gmail.com
> > > >>>>>>>>
> > > >>>>>>> :
> > > >>>>>>
> > > >>>>>>> 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 <
> anatole@apache.org
> > >:
> > > >>>>>>>>>
> > > >>>>>>>>>> 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
> > > >>>>>>>>>>
> > > >>>>>>>>>>
> > > >> --
> > > >> N Oliver B. Fischer
> > > >> A Schönhauser Allee 64, 10437 Berlin, Deutschland/Germany
> > > >> P +49 30 44793251
> > > >> M +49 178 7903538
> > > >> E o.b.fischer@swe-blog.net
> > > >> S oliver.b.fischer
> > > >> J oliver.b.fischer@jabber.org
> > > >> X http://xing.to/obf
> > > >>
> > > >>
> > >
> >
>
>
>
> --
> *Anatole Tresch*
> Java Engineer & Architect, JSR Spec Lead
> Glärnischweg 10
> CH - 8620 Wetzikon
>
> *Switzerland, Europe Zurich, GMT+1*
> *Twitter: @atsticks*
> *Blogs: **http://javaremarkables.blogspot.ch/
> <http://javaremarkables.blogspot.ch/>*
>
> *Google: atsticksMobile +41-76 344 62 79*
>
Re: Use Case 1: Read simple properties and get values.
Posted by Anatole Tresch <at...@gmail.com>.
YES! As I said this would be a topic for later IMO. Looking at the
discussions so far I would call it* Environment.current() *(instead of of()
). For getting configuration right you must have an environment model in
place that is very flexible (basically I tend to say modelling and
implementing the environment provider is more complex, than assembling the
configuration that is relevant to that environment)...
2014-12-01 19:20 GMT+01:00 Werner Keil <we...@gmail.com>:
> If you get one by app, is there any form of "context" you'd pass to such
> factory method?
>
> Currency.getInstance() returns exactly one singleton instance of a Currency
> class (otherwise has no constructor either) for a given currency code.
> While Money.of() in JSR 354 RI returns totally different instances
> depending on the combination of (nearly unlimited) different numbers and
> currency codes. 354 tries to broaden the definition of Currency, but if you
> get exactly one distinct instance per VM/app that's a singleton IMHO even
> if you may call the same application multiple times.
>
> On Mon, Dec 1, 2014 at 7:12 PM, Romain Manni-Bucau <rm...@gmail.com>
> wrote:
>
> > Hmm,
> >
> > for me getInstance() = singleton in term of instance where
> > Configuration will be all but a singleton IMO (you'll get at least one
> > by app and surely a new instance each time you call it) no?
> >
> >
> > Romain Manni-Bucau
> > @rmannibucau
> > http://www.tomitribe.com
> > http://rmannibucau.wordpress.com
> > https://github.com/rmannibucau
> >
> >
> > 2014-12-01 18:56 GMT+01:00 Werner Keil <we...@gmail.com>:
> > > Hi,
> > >
> > > Adding to the question of convenience factories, there is no such thing
> > as
> > > "naming convention" by Stephen Colebourne or JSR 310. In fact, it
> > violates
> > > or bends almost every one of them in itself, so a suggestion like
> > > Configuration.current() would sound very similar to the
> > LocalDateTime.now()
> > > ones in 310.
> > > For several other cases of() or longer variations (like ofMilli()
> > ofNanos()
> > > etc.;-O) are used, while static factories from strings similar to what
> > JSR
> > > 354 adopted are called parse(String).
> > >
> > > Josh Bloch defined a clear distinction between what he then in most
> cases
> > > (except EnumSet, that's where he started using of() so Josh also
> > "invented"
> > > that while it violated some of his earlier naming conventions;-D)
> called
> > > valueOf() and getInstance(), see
> > >
> >
> http://blog.codefront.net/2003/06/21/java-tip-2-static-factory-methods-vs-constructors/
> > > getInstance() returns a singleton, either the only instance for this
> type
> > > of object or the only instance for a distinct code or enum (see
> > > java.util.Currency)
> > >
> > > Very recent APIs and JSRs like MEEP 8 make a clear distinction, and
> > classes
> > > like
> > >
> >
> https://docs.oracle.com/javame/8.0/api/meep/api/javax/microedition/event/EventManager.html
> > > clearly explain that, too. In other places ME 8 uses of() where
> > appropriate.
> > > So at least getInstance() is neither outdated nor wrong, it just
> depends
> > on
> > > what you return.
> > >
> > > If Configuration returns just a default instance then
> > > Configuration.getInstance() seems appropriate.
> > >
> > >
> > > Werner Keil | JCP Executive Committee Member, JSR 363 Co Spec Lead |
> > > Eclipse UOMo Lead, Babel Language Champion | Apache Committer
> > >
> > > Twitter @wernerkeil | @UnitAPI | @JSR354 | @DeviceMap | #EclipseUOMo |
> > > #Java_Social
> > > | #DevOps
> > > Skype werner.keil | Google+ gplus.to/wernerkeil
> > >
> > > On Mon, Dec 1, 2014 at 6:31 PM, Oliver B. Fischer <
> > o.b.fischer@swe-blog.net>
> > > wrote:
> > >
> > >> Hi,
> > >>
> > >> for me the most simple use case is
> > >>
> > >> Configuration conf = new Configuration();
> > >> String value = conf.get("key")
> > >>
> > >> And this use case is already very complex under the hood.
> > >>
> > >> Before discussing other details we have to decide how
> PropertyProviders
> > >> are activated.
> > >>
> > >> I would like to have the following possibilites:
> > >>
> > >> 1. Tamaya activates all PropertyProviders found in the classpath and
> > >> activated via SPI.
> > >> 2. Tamaya activates only a explicitly named list of Property providers
> > >> 3. I have the ability to control the order in which the property
> > solution
> > >> will be performed
> > >>
> > >> Bye,
> > >>
> > >> Oliver
> > >>
> > >>
> > >> Am 01.12.14 17:54, schrieb Romain Manni-Bucau:
> > >>
> > >>> Configuration.current() sounds easier to understand first time you
> see
> > >>> it. I like Configuration.newInstance() if that's really what it does
> > >>> (ie no caching by classloader or anything else).
> > >>>
> > >>>
> > >>> Romain Manni-Bucau
> > >>> @rmannibucau
> > >>> http://www.tomitribe.com
> > >>> http://rmannibucau.wordpress.com
> > >>> https://github.com/rmannibucau
> > >>>
> > >>>
> > >>> 2014-12-01 17:42 GMT+01:00 Anatole Tresch <at...@gmail.com>:
> > >>>
> > >>>> There is a naming concept from Stephen Colebourne when to use of,
> > from,
> > >>>> with. I try to lookup the link later, see also jsr 310 and 354.
> > >>>> getInstance, valueOf are considered to be outdated for modern api
> > design.
> > >>>>
> > >>>> Adding a helper, why? Another artifact a user must know, makes
> sense,
> > >>>> where
> > >>>> you have a huge acces api IMO (see PropertyProviders where the
> factory
> > >>>> methods are not part of the PropertyProvider interface. For
> > >>>> Configuration I
> > >>>> prefer having sn intuitive simple/single access...
> > >>>>
> > >>>> Nevertheless I would like to encourage you to make a concrete
> proposal
> > >>>> how
> > >>>> would name things, so we can compare what your idea of fluent is ;)
> > >>>>
> > >>>> -anatole
> > >>>> Gerhard Petracek <ge...@gmail.com> schrieb am Mo., 1.
> Dez.
> > >>>> 2014
> > >>>> um 17:24:
> > >>>>
> > >>>> 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
> > >>>>> <anatole.tresch@credit-suisse.
> > >>>>> com
> > >>>>>
> > >>>>>> :
> > >>>>>> 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:gerhard.petracek@gmail.com]
> > >>>>>> Sent: Montag, 1. Dezember 2014 14:30
> > >>>>>> To: dev@tamaya.incubator.apache.org
> > >>>>>> 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 <an...@apache.org>:
> > >>>>>>
> > >>>>>> 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 <ge...@gmail.com> 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 <
> > rmannibucau@gmail.com
> > >>>>>>>>
> > >>>>>>> :
> > >>>>>>
> > >>>>>>> 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 <anatole@apache.org
> >:
> > >>>>>>>>>
> > >>>>>>>>>> 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
> > >>>>>>>>>>
> > >>>>>>>>>>
> > >> --
> > >> N Oliver B. Fischer
> > >> A Schönhauser Allee 64, 10437 Berlin, Deutschland/Germany
> > >> P +49 30 44793251
> > >> M +49 178 7903538
> > >> E o.b.fischer@swe-blog.net
> > >> S oliver.b.fischer
> > >> J oliver.b.fischer@jabber.org
> > >> X http://xing.to/obf
> > >>
> > >>
> >
>
--
*Anatole Tresch*
Java Engineer & Architect, JSR Spec Lead
Glärnischweg 10
CH - 8620 Wetzikon
*Switzerland, Europe Zurich, GMT+1*
*Twitter: @atsticks*
*Blogs: **http://javaremarkables.blogspot.ch/
<http://javaremarkables.blogspot.ch/>*
*Google: atsticksMobile +41-76 344 62 79*
Re: Use Case 1: Read simple properties and get values.
Posted by Anatole Tresch <at...@gmail.com>.
Hey Guys
perhaps I missed to mention: you are awesome!!! We might have different
opinions sometimes, but I wanted to mention, that I really enjoy discuss
things with you! I will do a break and going online later again ;)
-Anatole
2014-12-01 20:00 GMT+01:00 Anatole Tresch <at...@gmail.com>:
> I think: Configuration.current() is the best solution. Says exactly what
> it is, no more. For a complete SE API we need an accessor for the
> Configuration...
>
> 2014-12-01 19:24 GMT+01:00 Romain Manni-Bucau <rm...@gmail.com>:
>
>> if you have tamaya in server/lib and call it from webapps for
>> instance, each webapp can use different providers so you need
>> different instances. That is no more a singleton. If it is still one
>> cause we consider it as a factory/builder then the "instance" is
>> useless no?
>>
>>
>> Romain Manni-Bucau
>> @rmannibucau
>> http://www.tomitribe.com
>> http://rmannibucau.wordpress.com
>> https://github.com/rmannibucau
>>
>>
>> 2014-12-01 19:20 GMT+01:00 Werner Keil <we...@gmail.com>:
>> > If you get one by app, is there any form of "context" you'd pass to such
>> > factory method?
>> >
>> > Currency.getInstance() returns exactly one singleton instance of a
>> Currency
>> > class (otherwise has no constructor either) for a given currency code.
>> > While Money.of() in JSR 354 RI returns totally different instances
>> > depending on the combination of (nearly unlimited) different numbers and
>> > currency codes. 354 tries to broaden the definition of Currency, but if
>> you
>> > get exactly one distinct instance per VM/app that's a singleton IMHO
>> even
>> > if you may call the same application multiple times.
>> >
>> > On Mon, Dec 1, 2014 at 7:12 PM, Romain Manni-Bucau <
>> rmannibucau@gmail.com>
>> > wrote:
>> >
>> >> Hmm,
>> >>
>> >> for me getInstance() = singleton in term of instance where
>> >> Configuration will be all but a singleton IMO (you'll get at least one
>> >> by app and surely a new instance each time you call it) no?
>> >>
>> >>
>> >> Romain Manni-Bucau
>> >> @rmannibucau
>> >> http://www.tomitribe.com
>> >> http://rmannibucau.wordpress.com
>> >> https://github.com/rmannibucau
>> >>
>> >>
>> >> 2014-12-01 18:56 GMT+01:00 Werner Keil <we...@gmail.com>:
>> >> > Hi,
>> >> >
>> >> > Adding to the question of convenience factories, there is no such
>> thing
>> >> as
>> >> > "naming convention" by Stephen Colebourne or JSR 310. In fact, it
>> >> violates
>> >> > or bends almost every one of them in itself, so a suggestion like
>> >> > Configuration.current() would sound very similar to the
>> >> LocalDateTime.now()
>> >> > ones in 310.
>> >> > For several other cases of() or longer variations (like ofMilli()
>> >> ofNanos()
>> >> > etc.;-O) are used, while static factories from strings similar to
>> what
>> >> JSR
>> >> > 354 adopted are called parse(String).
>> >> >
>> >> > Josh Bloch defined a clear distinction between what he then in most
>> cases
>> >> > (except EnumSet, that's where he started using of() so Josh also
>> >> "invented"
>> >> > that while it violated some of his earlier naming conventions;-D)
>> called
>> >> > valueOf() and getInstance(), see
>> >> >
>> >>
>> http://blog.codefront.net/2003/06/21/java-tip-2-static-factory-methods-vs-constructors/
>> >> > getInstance() returns a singleton, either the only instance for this
>> type
>> >> > of object or the only instance for a distinct code or enum (see
>> >> > java.util.Currency)
>> >> >
>> >> > Very recent APIs and JSRs like MEEP 8 make a clear distinction, and
>> >> classes
>> >> > like
>> >> >
>> >>
>> https://docs.oracle.com/javame/8.0/api/meep/api/javax/microedition/event/EventManager.html
>> >> > clearly explain that, too. In other places ME 8 uses of() where
>> >> appropriate.
>> >> > So at least getInstance() is neither outdated nor wrong, it just
>> depends
>> >> on
>> >> > what you return.
>> >> >
>> >> > If Configuration returns just a default instance then
>> >> > Configuration.getInstance() seems appropriate.
>> >> >
>> >> >
>> >> > Werner Keil | JCP Executive Committee Member, JSR 363 Co Spec Lead |
>> >> > Eclipse UOMo Lead, Babel Language Champion | Apache Committer
>> >> >
>> >> > Twitter @wernerkeil | @UnitAPI | @JSR354 | @DeviceMap | #EclipseUOMo
>> |
>> >> > #Java_Social
>> >> > | #DevOps
>> >> > Skype werner.keil | Google+ gplus.to/wernerkeil
>> >> >
>> >> > On Mon, Dec 1, 2014 at 6:31 PM, Oliver B. Fischer <
>> >> o.b.fischer@swe-blog.net>
>> >> > wrote:
>> >> >
>> >> >> Hi,
>> >> >>
>> >> >> for me the most simple use case is
>> >> >>
>> >> >> Configuration conf = new Configuration();
>> >> >> String value = conf.get("key")
>> >> >>
>> >> >> And this use case is already very complex under the hood.
>> >> >>
>> >> >> Before discussing other details we have to decide how
>> PropertyProviders
>> >> >> are activated.
>> >> >>
>> >> >> I would like to have the following possibilites:
>> >> >>
>> >> >> 1. Tamaya activates all PropertyProviders found in the classpath and
>> >> >> activated via SPI.
>> >> >> 2. Tamaya activates only a explicitly named list of Property
>> providers
>> >> >> 3. I have the ability to control the order in which the property
>> >> solution
>> >> >> will be performed
>> >> >>
>> >> >> Bye,
>> >> >>
>> >> >> Oliver
>> >> >>
>> >> >>
>> >> >> Am 01.12.14 17:54, schrieb Romain Manni-Bucau:
>> >> >>
>> >> >>> Configuration.current() sounds easier to understand first time you
>> see
>> >> >>> it. I like Configuration.newInstance() if that's really what it
>> does
>> >> >>> (ie no caching by classloader or anything else).
>> >> >>>
>> >> >>>
>> >> >>> Romain Manni-Bucau
>> >> >>> @rmannibucau
>> >> >>> http://www.tomitribe.com
>> >> >>> http://rmannibucau.wordpress.com
>> >> >>> https://github.com/rmannibucau
>> >> >>>
>> >> >>>
>> >> >>> 2014-12-01 17:42 GMT+01:00 Anatole Tresch <at...@gmail.com>:
>> >> >>>
>> >> >>>> There is a naming concept from Stephen Colebourne when to use of,
>> >> from,
>> >> >>>> with. I try to lookup the link later, see also jsr 310 and 354.
>> >> >>>> getInstance, valueOf are considered to be outdated for modern api
>> >> design.
>> >> >>>>
>> >> >>>> Adding a helper, why? Another artifact a user must know, makes
>> sense,
>> >> >>>> where
>> >> >>>> you have a huge acces api IMO (see PropertyProviders where the
>> factory
>> >> >>>> methods are not part of the PropertyProvider interface. For
>> >> >>>> Configuration I
>> >> >>>> prefer having sn intuitive simple/single access...
>> >> >>>>
>> >> >>>> Nevertheless I would like to encourage you to make a concrete
>> proposal
>> >> >>>> how
>> >> >>>> would name things, so we can compare what your idea of fluent is
>> ;)
>> >> >>>>
>> >> >>>> -anatole
>> >> >>>> Gerhard Petracek <ge...@gmail.com> schrieb am Mo., 1.
>> Dez.
>> >> >>>> 2014
>> >> >>>> um 17:24:
>> >> >>>>
>> >> >>>> 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
>> >> >>>>> <anatole.tresch@credit-suisse.
>> >> >>>>> com
>> >> >>>>>
>> >> >>>>>> :
>> >> >>>>>> 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:gerhard.petracek@gmail.com]
>> >> >>>>>> Sent: Montag, 1. Dezember 2014 14:30
>> >> >>>>>> To: dev@tamaya.incubator.apache.org
>> >> >>>>>> 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 <an...@apache.org>:
>> >> >>>>>>
>> >> >>>>>> 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 <ge...@gmail.com> 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 <
>> >> rmannibucau@gmail.com
>> >> >>>>>>>>
>> >> >>>>>>> :
>> >> >>>>>>
>> >> >>>>>>> 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 <
>> anatole@apache.org>:
>> >> >>>>>>>>>
>> >> >>>>>>>>>> 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
>> >> >>>>>>>>>>
>> >> >>>>>>>>>>
>> >> >> --
>> >> >> N Oliver B. Fischer
>> >> >> A Schönhauser Allee 64, 10437 Berlin, Deutschland/Germany
>> >> >> P +49 30 44793251
>> >> >> M +49 178 7903538
>> >> >> E o.b.fischer@swe-blog.net
>> >> >> S oliver.b.fischer
>> >> >> J oliver.b.fischer@jabber.org
>> >> >> X http://xing.to/obf
>> >> >>
>> >> >>
>> >>
>>
>
>
>
> --
> *Anatole Tresch*
> Java Engineer & Architect, JSR Spec Lead
> Glärnischweg 10
> CH - 8620 Wetzikon
>
> *Switzerland, Europe Zurich, GMT+1*
> *Twitter: @atsticks*
> *Blogs: **http://javaremarkables.blogspot.ch/
> <http://javaremarkables.blogspot.ch/>*
>
> *Google: atsticksMobile +41-76 344 62 79 <%2B41-76%20344%2062%2079>*
>
--
*Anatole Tresch*
Java Engineer & Architect, JSR Spec Lead
Glärnischweg 10
CH - 8620 Wetzikon
*Switzerland, Europe Zurich, GMT+1*
*Twitter: @atsticks*
*Blogs: **http://javaremarkables.blogspot.ch/
<http://javaremarkables.blogspot.ch/>*
*Google: atsticksMobile +41-76 344 62 79*
Re: Use Case 1: Read simple properties and get values.
Posted by Gerhard Petracek <ge...@gmail.com>.
+1 for Configuration.current()
regards,
gerhard
2014-12-01 20:00 GMT+01:00 Anatole Tresch <at...@gmail.com>:
> I think: Configuration.current() is the best solution. Says exactly what it
> is, no more. For a complete SE API we need an accessor for the
> Configuration...
>
> 2014-12-01 19:24 GMT+01:00 Romain Manni-Bucau <rm...@gmail.com>:
>
> > if you have tamaya in server/lib and call it from webapps for
> > instance, each webapp can use different providers so you need
> > different instances. That is no more a singleton. If it is still one
> > cause we consider it as a factory/builder then the "instance" is
> > useless no?
> >
> >
> > Romain Manni-Bucau
> > @rmannibucau
> > http://www.tomitribe.com
> > http://rmannibucau.wordpress.com
> > https://github.com/rmannibucau
> >
> >
> > 2014-12-01 19:20 GMT+01:00 Werner Keil <we...@gmail.com>:
> > > If you get one by app, is there any form of "context" you'd pass to
> such
> > > factory method?
> > >
> > > Currency.getInstance() returns exactly one singleton instance of a
> > Currency
> > > class (otherwise has no constructor either) for a given currency code.
> > > While Money.of() in JSR 354 RI returns totally different instances
> > > depending on the combination of (nearly unlimited) different numbers
> and
> > > currency codes. 354 tries to broaden the definition of Currency, but if
> > you
> > > get exactly one distinct instance per VM/app that's a singleton IMHO
> even
> > > if you may call the same application multiple times.
> > >
> > > On Mon, Dec 1, 2014 at 7:12 PM, Romain Manni-Bucau <
> > rmannibucau@gmail.com>
> > > wrote:
> > >
> > >> Hmm,
> > >>
> > >> for me getInstance() = singleton in term of instance where
> > >> Configuration will be all but a singleton IMO (you'll get at least one
> > >> by app and surely a new instance each time you call it) no?
> > >>
> > >>
> > >> Romain Manni-Bucau
> > >> @rmannibucau
> > >> http://www.tomitribe.com
> > >> http://rmannibucau.wordpress.com
> > >> https://github.com/rmannibucau
> > >>
> > >>
> > >> 2014-12-01 18:56 GMT+01:00 Werner Keil <we...@gmail.com>:
> > >> > Hi,
> > >> >
> > >> > Adding to the question of convenience factories, there is no such
> > thing
> > >> as
> > >> > "naming convention" by Stephen Colebourne or JSR 310. In fact, it
> > >> violates
> > >> > or bends almost every one of them in itself, so a suggestion like
> > >> > Configuration.current() would sound very similar to the
> > >> LocalDateTime.now()
> > >> > ones in 310.
> > >> > For several other cases of() or longer variations (like ofMilli()
> > >> ofNanos()
> > >> > etc.;-O) are used, while static factories from strings similar to
> what
> > >> JSR
> > >> > 354 adopted are called parse(String).
> > >> >
> > >> > Josh Bloch defined a clear distinction between what he then in most
> > cases
> > >> > (except EnumSet, that's where he started using of() so Josh also
> > >> "invented"
> > >> > that while it violated some of his earlier naming conventions;-D)
> > called
> > >> > valueOf() and getInstance(), see
> > >> >
> > >>
> >
> http://blog.codefront.net/2003/06/21/java-tip-2-static-factory-methods-vs-constructors/
> > >> > getInstance() returns a singleton, either the only instance for this
> > type
> > >> > of object or the only instance for a distinct code or enum (see
> > >> > java.util.Currency)
> > >> >
> > >> > Very recent APIs and JSRs like MEEP 8 make a clear distinction, and
> > >> classes
> > >> > like
> > >> >
> > >>
> >
> https://docs.oracle.com/javame/8.0/api/meep/api/javax/microedition/event/EventManager.html
> > >> > clearly explain that, too. In other places ME 8 uses of() where
> > >> appropriate.
> > >> > So at least getInstance() is neither outdated nor wrong, it just
> > depends
> > >> on
> > >> > what you return.
> > >> >
> > >> > If Configuration returns just a default instance then
> > >> > Configuration.getInstance() seems appropriate.
> > >> >
> > >> >
> > >> > Werner Keil | JCP Executive Committee Member, JSR 363 Co Spec Lead
> |
> > >> > Eclipse UOMo Lead, Babel Language Champion | Apache Committer
> > >> >
> > >> > Twitter @wernerkeil | @UnitAPI | @JSR354 | @DeviceMap |
> #EclipseUOMo |
> > >> > #Java_Social
> > >> > | #DevOps
> > >> > Skype werner.keil | Google+ gplus.to/wernerkeil
> > >> >
> > >> > On Mon, Dec 1, 2014 at 6:31 PM, Oliver B. Fischer <
> > >> o.b.fischer@swe-blog.net>
> > >> > wrote:
> > >> >
> > >> >> Hi,
> > >> >>
> > >> >> for me the most simple use case is
> > >> >>
> > >> >> Configuration conf = new Configuration();
> > >> >> String value = conf.get("key")
> > >> >>
> > >> >> And this use case is already very complex under the hood.
> > >> >>
> > >> >> Before discussing other details we have to decide how
> > PropertyProviders
> > >> >> are activated.
> > >> >>
> > >> >> I would like to have the following possibilites:
> > >> >>
> > >> >> 1. Tamaya activates all PropertyProviders found in the classpath
> and
> > >> >> activated via SPI.
> > >> >> 2. Tamaya activates only a explicitly named list of Property
> > providers
> > >> >> 3. I have the ability to control the order in which the property
> > >> solution
> > >> >> will be performed
> > >> >>
> > >> >> Bye,
> > >> >>
> > >> >> Oliver
> > >> >>
> > >> >>
> > >> >> Am 01.12.14 17:54, schrieb Romain Manni-Bucau:
> > >> >>
> > >> >>> Configuration.current() sounds easier to understand first time you
> > see
> > >> >>> it. I like Configuration.newInstance() if that's really what it
> does
> > >> >>> (ie no caching by classloader or anything else).
> > >> >>>
> > >> >>>
> > >> >>> Romain Manni-Bucau
> > >> >>> @rmannibucau
> > >> >>> http://www.tomitribe.com
> > >> >>> http://rmannibucau.wordpress.com
> > >> >>> https://github.com/rmannibucau
> > >> >>>
> > >> >>>
> > >> >>> 2014-12-01 17:42 GMT+01:00 Anatole Tresch <at...@gmail.com>:
> > >> >>>
> > >> >>>> There is a naming concept from Stephen Colebourne when to use of,
> > >> from,
> > >> >>>> with. I try to lookup the link later, see also jsr 310 and 354.
> > >> >>>> getInstance, valueOf are considered to be outdated for modern api
> > >> design.
> > >> >>>>
> > >> >>>> Adding a helper, why? Another artifact a user must know, makes
> > sense,
> > >> >>>> where
> > >> >>>> you have a huge acces api IMO (see PropertyProviders where the
> > factory
> > >> >>>> methods are not part of the PropertyProvider interface. For
> > >> >>>> Configuration I
> > >> >>>> prefer having sn intuitive simple/single access...
> > >> >>>>
> > >> >>>> Nevertheless I would like to encourage you to make a concrete
> > proposal
> > >> >>>> how
> > >> >>>> would name things, so we can compare what your idea of fluent is
> ;)
> > >> >>>>
> > >> >>>> -anatole
> > >> >>>> Gerhard Petracek <ge...@gmail.com> schrieb am Mo., 1.
> > Dez.
> > >> >>>> 2014
> > >> >>>> um 17:24:
> > >> >>>>
> > >> >>>> 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
> > >> >>>>> <anatole.tresch@credit-suisse.
> > >> >>>>> com
> > >> >>>>>
> > >> >>>>>> :
> > >> >>>>>> 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:gerhard.petracek@gmail.com]
> > >> >>>>>> Sent: Montag, 1. Dezember 2014 14:30
> > >> >>>>>> To: dev@tamaya.incubator.apache.org
> > >> >>>>>> 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 <anatole@apache.org
> >:
> > >> >>>>>>
> > >> >>>>>> 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 <ge...@gmail.com> 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 <
> > >> rmannibucau@gmail.com
> > >> >>>>>>>>
> > >> >>>>>>> :
> > >> >>>>>>
> > >> >>>>>>> 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 <
> anatole@apache.org
> > >:
> > >> >>>>>>>>>
> > >> >>>>>>>>>> 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
> > >> >>>>>>>>>>
> > >> >>>>>>>>>>
> > >> >> --
> > >> >> N Oliver B. Fischer
> > >> >> A Schönhauser Allee 64, 10437 Berlin, Deutschland/Germany
> > >> >> P +49 30 44793251
> > >> >> M +49 178 7903538
> > >> >> E o.b.fischer@swe-blog.net
> > >> >> S oliver.b.fischer
> > >> >> J oliver.b.fischer@jabber.org
> > >> >> X http://xing.to/obf
> > >> >>
> > >> >>
> > >>
> >
>
>
>
> --
> *Anatole Tresch*
> Java Engineer & Architect, JSR Spec Lead
> Glärnischweg 10
> CH - 8620 Wetzikon
>
> *Switzerland, Europe Zurich, GMT+1*
> *Twitter: @atsticks*
> *Blogs: **http://javaremarkables.blogspot.ch/
> <http://javaremarkables.blogspot.ch/>*
>
> *Google: atsticksMobile +41-76 344 62 79*
>
Re: Use Case 1: Read simple properties and get values.
Posted by Anatole Tresch <at...@gmail.com>.
I think: Configuration.current() is the best solution. Says exactly what it
is, no more. For a complete SE API we need an accessor for the
Configuration...
2014-12-01 19:24 GMT+01:00 Romain Manni-Bucau <rm...@gmail.com>:
> if you have tamaya in server/lib and call it from webapps for
> instance, each webapp can use different providers so you need
> different instances. That is no more a singleton. If it is still one
> cause we consider it as a factory/builder then the "instance" is
> useless no?
>
>
> Romain Manni-Bucau
> @rmannibucau
> http://www.tomitribe.com
> http://rmannibucau.wordpress.com
> https://github.com/rmannibucau
>
>
> 2014-12-01 19:20 GMT+01:00 Werner Keil <we...@gmail.com>:
> > If you get one by app, is there any form of "context" you'd pass to such
> > factory method?
> >
> > Currency.getInstance() returns exactly one singleton instance of a
> Currency
> > class (otherwise has no constructor either) for a given currency code.
> > While Money.of() in JSR 354 RI returns totally different instances
> > depending on the combination of (nearly unlimited) different numbers and
> > currency codes. 354 tries to broaden the definition of Currency, but if
> you
> > get exactly one distinct instance per VM/app that's a singleton IMHO even
> > if you may call the same application multiple times.
> >
> > On Mon, Dec 1, 2014 at 7:12 PM, Romain Manni-Bucau <
> rmannibucau@gmail.com>
> > wrote:
> >
> >> Hmm,
> >>
> >> for me getInstance() = singleton in term of instance where
> >> Configuration will be all but a singleton IMO (you'll get at least one
> >> by app and surely a new instance each time you call it) no?
> >>
> >>
> >> Romain Manni-Bucau
> >> @rmannibucau
> >> http://www.tomitribe.com
> >> http://rmannibucau.wordpress.com
> >> https://github.com/rmannibucau
> >>
> >>
> >> 2014-12-01 18:56 GMT+01:00 Werner Keil <we...@gmail.com>:
> >> > Hi,
> >> >
> >> > Adding to the question of convenience factories, there is no such
> thing
> >> as
> >> > "naming convention" by Stephen Colebourne or JSR 310. In fact, it
> >> violates
> >> > or bends almost every one of them in itself, so a suggestion like
> >> > Configuration.current() would sound very similar to the
> >> LocalDateTime.now()
> >> > ones in 310.
> >> > For several other cases of() or longer variations (like ofMilli()
> >> ofNanos()
> >> > etc.;-O) are used, while static factories from strings similar to what
> >> JSR
> >> > 354 adopted are called parse(String).
> >> >
> >> > Josh Bloch defined a clear distinction between what he then in most
> cases
> >> > (except EnumSet, that's where he started using of() so Josh also
> >> "invented"
> >> > that while it violated some of his earlier naming conventions;-D)
> called
> >> > valueOf() and getInstance(), see
> >> >
> >>
> http://blog.codefront.net/2003/06/21/java-tip-2-static-factory-methods-vs-constructors/
> >> > getInstance() returns a singleton, either the only instance for this
> type
> >> > of object or the only instance for a distinct code or enum (see
> >> > java.util.Currency)
> >> >
> >> > Very recent APIs and JSRs like MEEP 8 make a clear distinction, and
> >> classes
> >> > like
> >> >
> >>
> https://docs.oracle.com/javame/8.0/api/meep/api/javax/microedition/event/EventManager.html
> >> > clearly explain that, too. In other places ME 8 uses of() where
> >> appropriate.
> >> > So at least getInstance() is neither outdated nor wrong, it just
> depends
> >> on
> >> > what you return.
> >> >
> >> > If Configuration returns just a default instance then
> >> > Configuration.getInstance() seems appropriate.
> >> >
> >> >
> >> > Werner Keil | JCP Executive Committee Member, JSR 363 Co Spec Lead |
> >> > Eclipse UOMo Lead, Babel Language Champion | Apache Committer
> >> >
> >> > Twitter @wernerkeil | @UnitAPI | @JSR354 | @DeviceMap | #EclipseUOMo |
> >> > #Java_Social
> >> > | #DevOps
> >> > Skype werner.keil | Google+ gplus.to/wernerkeil
> >> >
> >> > On Mon, Dec 1, 2014 at 6:31 PM, Oliver B. Fischer <
> >> o.b.fischer@swe-blog.net>
> >> > wrote:
> >> >
> >> >> Hi,
> >> >>
> >> >> for me the most simple use case is
> >> >>
> >> >> Configuration conf = new Configuration();
> >> >> String value = conf.get("key")
> >> >>
> >> >> And this use case is already very complex under the hood.
> >> >>
> >> >> Before discussing other details we have to decide how
> PropertyProviders
> >> >> are activated.
> >> >>
> >> >> I would like to have the following possibilites:
> >> >>
> >> >> 1. Tamaya activates all PropertyProviders found in the classpath and
> >> >> activated via SPI.
> >> >> 2. Tamaya activates only a explicitly named list of Property
> providers
> >> >> 3. I have the ability to control the order in which the property
> >> solution
> >> >> will be performed
> >> >>
> >> >> Bye,
> >> >>
> >> >> Oliver
> >> >>
> >> >>
> >> >> Am 01.12.14 17:54, schrieb Romain Manni-Bucau:
> >> >>
> >> >>> Configuration.current() sounds easier to understand first time you
> see
> >> >>> it. I like Configuration.newInstance() if that's really what it does
> >> >>> (ie no caching by classloader or anything else).
> >> >>>
> >> >>>
> >> >>> Romain Manni-Bucau
> >> >>> @rmannibucau
> >> >>> http://www.tomitribe.com
> >> >>> http://rmannibucau.wordpress.com
> >> >>> https://github.com/rmannibucau
> >> >>>
> >> >>>
> >> >>> 2014-12-01 17:42 GMT+01:00 Anatole Tresch <at...@gmail.com>:
> >> >>>
> >> >>>> There is a naming concept from Stephen Colebourne when to use of,
> >> from,
> >> >>>> with. I try to lookup the link later, see also jsr 310 and 354.
> >> >>>> getInstance, valueOf are considered to be outdated for modern api
> >> design.
> >> >>>>
> >> >>>> Adding a helper, why? Another artifact a user must know, makes
> sense,
> >> >>>> where
> >> >>>> you have a huge acces api IMO (see PropertyProviders where the
> factory
> >> >>>> methods are not part of the PropertyProvider interface. For
> >> >>>> Configuration I
> >> >>>> prefer having sn intuitive simple/single access...
> >> >>>>
> >> >>>> Nevertheless I would like to encourage you to make a concrete
> proposal
> >> >>>> how
> >> >>>> would name things, so we can compare what your idea of fluent is ;)
> >> >>>>
> >> >>>> -anatole
> >> >>>> Gerhard Petracek <ge...@gmail.com> schrieb am Mo., 1.
> Dez.
> >> >>>> 2014
> >> >>>> um 17:24:
> >> >>>>
> >> >>>> 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
> >> >>>>> <anatole.tresch@credit-suisse.
> >> >>>>> com
> >> >>>>>
> >> >>>>>> :
> >> >>>>>> 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:gerhard.petracek@gmail.com]
> >> >>>>>> Sent: Montag, 1. Dezember 2014 14:30
> >> >>>>>> To: dev@tamaya.incubator.apache.org
> >> >>>>>> 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 <an...@apache.org>:
> >> >>>>>>
> >> >>>>>> 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 <ge...@gmail.com> 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 <
> >> rmannibucau@gmail.com
> >> >>>>>>>>
> >> >>>>>>> :
> >> >>>>>>
> >> >>>>>>> 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 <anatole@apache.org
> >:
> >> >>>>>>>>>
> >> >>>>>>>>>> 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
> >> >>>>>>>>>>
> >> >>>>>>>>>>
> >> >> --
> >> >> N Oliver B. Fischer
> >> >> A Schönhauser Allee 64, 10437 Berlin, Deutschland/Germany
> >> >> P +49 30 44793251
> >> >> M +49 178 7903538
> >> >> E o.b.fischer@swe-blog.net
> >> >> S oliver.b.fischer
> >> >> J oliver.b.fischer@jabber.org
> >> >> X http://xing.to/obf
> >> >>
> >> >>
> >>
>
--
*Anatole Tresch*
Java Engineer & Architect, JSR Spec Lead
Glärnischweg 10
CH - 8620 Wetzikon
*Switzerland, Europe Zurich, GMT+1*
*Twitter: @atsticks*
*Blogs: **http://javaremarkables.blogspot.ch/
<http://javaremarkables.blogspot.ch/>*
*Google: atsticksMobile +41-76 344 62 79*
Re: Use Case 1: Read simple properties and get values.
Posted by Anatole Tresch <at...@gmail.com>.
BTW, supporting a new ConfigFormat is trivial: implementing ConfigurationFormat
and register it with as component, by default using the ServiceLoader.
Then you only to read the file and you are done ;)
2014-12-01 19:48 GMT+01:00 Gerhard Petracek <ge...@gmail.com>:
> @romain:
> i just mentioned it (as one possibility), because oliver asked about
> multiple config-sources which provide values for the same key.
> independent of the final approach we will agree on (for that use-case), it
> shouldn't affect the use-case we discuss right now.
> (that's the reason for discussing it step by step and if a more complex
> case really impacts a simple(r) case later on, we can re-visit the
> corresponding api + tests at any time).
>
> regards,
> gerhard
>
>
>
> 2014-12-01 19:34 GMT+01:00 Werner Keil <we...@gmail.com>:
>
> > That's where some sort of "scope" is clearly necessary, see the different
> > CDI scopes.
> > It might make sense to inject a configuration via @Inject too btw. CDI
> (and
> > AFAIK DeltaSpike) rarely uses singletons or public factories along the
> > lines of JSR 354.
> > A single class and public accessor can be found in BeanValidation:
> > Validation.
> > That has a default factory but also offers other providers. If we needed
> > something similar for Configuration then maybe something like
> > getDefault...() could be more appropriate than simply calling it
> > getInstance() ;-)
> >
> > On Mon, Dec 1, 2014 at 7:24 PM, Romain Manni-Bucau <
> rmannibucau@gmail.com>
> > wrote:
> >
> > > if you have tamaya in server/lib and call it from webapps for
> > > instance, each webapp can use different providers so you need
> > > different instances. That is no more a singleton. If it is still one
> > > cause we consider it as a factory/builder then the "instance" is
> > > useless no?
> > >
> > >
> > > Romain Manni-Bucau
> > > @rmannibucau
> > > http://www.tomitribe.com
> > > http://rmannibucau.wordpress.com
> > > https://github.com/rmannibucau
> > >
> > >
> > > 2014-12-01 19:20 GMT+01:00 Werner Keil <we...@gmail.com>:
> > > > If you get one by app, is there any form of "context" you'd pass to
> > such
> > > > factory method?
> > > >
> > > > Currency.getInstance() returns exactly one singleton instance of a
> > > Currency
> > > > class (otherwise has no constructor either) for a given currency
> code.
> > > > While Money.of() in JSR 354 RI returns totally different instances
> > > > depending on the combination of (nearly unlimited) different numbers
> > and
> > > > currency codes. 354 tries to broaden the definition of Currency, but
> if
> > > you
> > > > get exactly one distinct instance per VM/app that's a singleton IMHO
> > even
> > > > if you may call the same application multiple times.
> > > >
> > > > On Mon, Dec 1, 2014 at 7:12 PM, Romain Manni-Bucau <
> > > rmannibucau@gmail.com>
> > > > wrote:
> > > >
> > > >> Hmm,
> > > >>
> > > >> for me getInstance() = singleton in term of instance where
> > > >> Configuration will be all but a singleton IMO (you'll get at least
> one
> > > >> by app and surely a new instance each time you call it) no?
> > > >>
> > > >>
> > > >> Romain Manni-Bucau
> > > >> @rmannibucau
> > > >> http://www.tomitribe.com
> > > >> http://rmannibucau.wordpress.com
> > > >> https://github.com/rmannibucau
> > > >>
> > > >>
> > > >> 2014-12-01 18:56 GMT+01:00 Werner Keil <we...@gmail.com>:
> > > >> > Hi,
> > > >> >
> > > >> > Adding to the question of convenience factories, there is no such
> > > thing
> > > >> as
> > > >> > "naming convention" by Stephen Colebourne or JSR 310. In fact, it
> > > >> violates
> > > >> > or bends almost every one of them in itself, so a suggestion like
> > > >> > Configuration.current() would sound very similar to the
> > > >> LocalDateTime.now()
> > > >> > ones in 310.
> > > >> > For several other cases of() or longer variations (like ofMilli()
> > > >> ofNanos()
> > > >> > etc.;-O) are used, while static factories from strings similar to
> > what
> > > >> JSR
> > > >> > 354 adopted are called parse(String).
> > > >> >
> > > >> > Josh Bloch defined a clear distinction between what he then in
> most
> > > cases
> > > >> > (except EnumSet, that's where he started using of() so Josh also
> > > >> "invented"
> > > >> > that while it violated some of his earlier naming conventions;-D)
> > > called
> > > >> > valueOf() and getInstance(), see
> > > >> >
> > > >>
> > >
> >
> http://blog.codefront.net/2003/06/21/java-tip-2-static-factory-methods-vs-constructors/
> > > >> > getInstance() returns a singleton, either the only instance for
> this
> > > type
> > > >> > of object or the only instance for a distinct code or enum (see
> > > >> > java.util.Currency)
> > > >> >
> > > >> > Very recent APIs and JSRs like MEEP 8 make a clear distinction,
> and
> > > >> classes
> > > >> > like
> > > >> >
> > > >>
> > >
> >
> https://docs.oracle.com/javame/8.0/api/meep/api/javax/microedition/event/EventManager.html
> > > >> > clearly explain that, too. In other places ME 8 uses of() where
> > > >> appropriate.
> > > >> > So at least getInstance() is neither outdated nor wrong, it just
> > > depends
> > > >> on
> > > >> > what you return.
> > > >> >
> > > >> > If Configuration returns just a default instance then
> > > >> > Configuration.getInstance() seems appropriate.
> > > >> >
> > > >> >
> > > >> > Werner Keil | JCP Executive Committee Member, JSR 363 Co Spec
> Lead
> > |
> > > >> > Eclipse UOMo Lead, Babel Language Champion | Apache Committer
> > > >> >
> > > >> > Twitter @wernerkeil | @UnitAPI | @JSR354 | @DeviceMap |
> > #EclipseUOMo |
> > > >> > #Java_Social
> > > >> > | #DevOps
> > > >> > Skype werner.keil | Google+ gplus.to/wernerkeil
> > > >> >
> > > >> > On Mon, Dec 1, 2014 at 6:31 PM, Oliver B. Fischer <
> > > >> o.b.fischer@swe-blog.net>
> > > >> > wrote:
> > > >> >
> > > >> >> Hi,
> > > >> >>
> > > >> >> for me the most simple use case is
> > > >> >>
> > > >> >> Configuration conf = new Configuration();
> > > >> >> String value = conf.get("key")
> > > >> >>
> > > >> >> And this use case is already very complex under the hood.
> > > >> >>
> > > >> >> Before discussing other details we have to decide how
> > > PropertyProviders
> > > >> >> are activated.
> > > >> >>
> > > >> >> I would like to have the following possibilites:
> > > >> >>
> > > >> >> 1. Tamaya activates all PropertyProviders found in the classpath
> > and
> > > >> >> activated via SPI.
> > > >> >> 2. Tamaya activates only a explicitly named list of Property
> > > providers
> > > >> >> 3. I have the ability to control the order in which the property
> > > >> solution
> > > >> >> will be performed
> > > >> >>
> > > >> >> Bye,
> > > >> >>
> > > >> >> Oliver
> > > >> >>
> > > >> >>
> > > >> >> Am 01.12.14 17:54, schrieb Romain Manni-Bucau:
> > > >> >>
> > > >> >>> Configuration.current() sounds easier to understand first time
> you
> > > see
> > > >> >>> it. I like Configuration.newInstance() if that's really what it
> > does
> > > >> >>> (ie no caching by classloader or anything else).
> > > >> >>>
> > > >> >>>
> > > >> >>> Romain Manni-Bucau
> > > >> >>> @rmannibucau
> > > >> >>> http://www.tomitribe.com
> > > >> >>> http://rmannibucau.wordpress.com
> > > >> >>> https://github.com/rmannibucau
> > > >> >>>
> > > >> >>>
> > > >> >>> 2014-12-01 17:42 GMT+01:00 Anatole Tresch <at...@gmail.com>:
> > > >> >>>
> > > >> >>>> There is a naming concept from Stephen Colebourne when to use
> of,
> > > >> from,
> > > >> >>>> with. I try to lookup the link later, see also jsr 310 and 354.
> > > >> >>>> getInstance, valueOf are considered to be outdated for modern
> api
> > > >> design.
> > > >> >>>>
> > > >> >>>> Adding a helper, why? Another artifact a user must know, makes
> > > sense,
> > > >> >>>> where
> > > >> >>>> you have a huge acces api IMO (see PropertyProviders where the
> > > factory
> > > >> >>>> methods are not part of the PropertyProvider interface. For
> > > >> >>>> Configuration I
> > > >> >>>> prefer having sn intuitive simple/single access...
> > > >> >>>>
> > > >> >>>> Nevertheless I would like to encourage you to make a concrete
> > > proposal
> > > >> >>>> how
> > > >> >>>> would name things, so we can compare what your idea of fluent
> is
> > ;)
> > > >> >>>>
> > > >> >>>> -anatole
> > > >> >>>> Gerhard Petracek <ge...@gmail.com> schrieb am Mo.,
> 1.
> > > Dez.
> > > >> >>>> 2014
> > > >> >>>> um 17:24:
> > > >> >>>>
> > > >> >>>> 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
> > > >> >>>>> <anatole.tresch@credit-suisse.
> > > >> >>>>> com
> > > >> >>>>>
> > > >> >>>>>> :
> > > >> >>>>>> 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:gerhard.petracek@gmail.com]
> > > >> >>>>>> Sent: Montag, 1. Dezember 2014 14:30
> > > >> >>>>>> To: dev@tamaya.incubator.apache.org
> > > >> >>>>>> 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 <
> anatole@apache.org
> > >:
> > > >> >>>>>>
> > > >> >>>>>> 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 <ge...@gmail.com> 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 <
> > > >> rmannibucau@gmail.com
> > > >> >>>>>>>>
> > > >> >>>>>>> :
> > > >> >>>>>>
> > > >> >>>>>>> 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 <
> > anatole@apache.org
> > > >:
> > > >> >>>>>>>>>
> > > >> >>>>>>>>>> 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
> > > >> >>>>>>>>>>
> > > >> >>>>>>>>>>
> > > >> >> --
> > > >> >> N Oliver B. Fischer
> > > >> >> A Schönhauser Allee 64, 10437 Berlin, Deutschland/Germany
> > > >> >> P +49 30 44793251
> > > >> >> M +49 178 7903538
> > > >> >> E o.b.fischer@swe-blog.net
> > > >> >> S oliver.b.fischer
> > > >> >> J oliver.b.fischer@jabber.org
> > > >> >> X http://xing.to/obf
> > > >> >>
> > > >> >>
> > > >>
> > >
> >
>
--
*Anatole Tresch*
Java Engineer & Architect, JSR Spec Lead
Glärnischweg 10
CH - 8620 Wetzikon
*Switzerland, Europe Zurich, GMT+1*
*Twitter: @atsticks*
*Blogs: **http://javaremarkables.blogspot.ch/
<http://javaremarkables.blogspot.ch/>*
*Google: atsticksMobile +41-76 344 62 79*
Re: Use Case 1: Read simple properties and get values.
Posted by Anatole Tresch <at...@gmail.com>.
Also in the documentation module there is already an asciidoc document
describing the design. My original idea was that we adapt this document, so
we have a comprehensive design guide always ready/current ;) Basically
all the things discussed so far should end up in this document as well. For
discussions Wiki might useful in addition to it.
Other opinions?
2014-12-01 21:02 GMT+01:00 Werner Keil <we...@gmail.com>:
> +1
>
> I know some groups including DeviceMap prefer the mailing list, but for
> some more graphic and descriptive design decisions I personally prefer
> either JIRA (if it's already in place?) or Wiki, too.
>
> On Mon, Dec 1, 2014 at 8:52 PM, Romain Manni-Bucau <rm...@gmail.com>
> wrote:
>
> ...
>
> > >
> > > --
> > > *Anatole Tresch*
> > > Java Engineer & Architect, JSR Spec Lead
> > > Glärnischweg 10
> > > CH - 8620 Wetzikon
> > >
> > > *Switzerland, Europe Zurich, GMT+1*
> > > *Twitter: @atsticks*
> > > *Blogs: **http://javaremarkables.blogspot.ch/
> > > <http://javaremarkables.blogspot.ch/>*
> > >
> > > *Google: atsticksMobile +41-76 344 62 79*
> >
>
--
*Anatole Tresch*
Java Engineer & Architect, JSR Spec Lead
Glärnischweg 10
CH - 8620 Wetzikon
*Switzerland, Europe Zurich, GMT+1*
*Twitter: @atsticks*
*Blogs: **http://javaremarkables.blogspot.ch/
<http://javaremarkables.blogspot.ch/>*
*Google: atsticksMobile +41-76 344 62 79 <%2B41-76%20344%2062%2079>*
Re: Use Case 1: Read simple properties and get values.
Posted by Werner Keil <we...@gmail.com>.
+1
I know some groups including DeviceMap prefer the mailing list, but for
some more graphic and descriptive design decisions I personally prefer
either JIRA (if it's already in place?) or Wiki, too.
On Mon, Dec 1, 2014 at 8:52 PM, Romain Manni-Bucau <rm...@gmail.com>
wrote:
> a bt off topic but wouldn't a wiki - confluence - be more efficient
> for such discussion. When something is under discussion we put a kind
> of poll/table with possibilities and when done we have more or less
> some spec/doc.
>
> issue with mails is we switch easily of topic and we need to summarize
> regularly.
>
> wdyt?
>
>
> Romain Manni-Bucau
> @rmannibucau
> http://www.tomitribe.com
> http://rmannibucau.wordpress.com
> https://github.com/rmannibucau
>
>
> 2014-12-01 20:12 GMT+01:00 Anatole Tresch <at...@gmail.com>:
> > That is also the reason, why I suggested to postpone the
> assembly/providing
> > discussion until we have at least a basic idea of
> >
> > - PropertyProviders (building blocks)
> > - default combination mechanism that help defining new
> config/providers
> > for doing filtering, aggregation, overriding, security, views, ...
> > - Configuration (representation and SE access)
> > - Environment (basic environment model and access
> > - Basic Services (still SE): injection, configuration templates,
> dynamic
> > expressions
> > - implementing config changes (events)
> >
> > Then we are able to really talk about how to best support power users
> (the
> > ones that setup the configuration meta-model) for
> >
> > - implementing the configuration providers in a system
> > - dynamically loading property providers in the right context
> > - combining all that stuff with CDI (and Java EE)
> > - ...
> >
> > It is not that I want to prevent any discussions, I just want to add some
> > minimal structure to it, so we are more effective ;)
> >
> > -Anatole
> >
> >
> > 2014-12-01 19:48 GMT+01:00 Gerhard Petracek <gerhard.petracek@gmail.com
> >:
> >
> >> @romain:
> >> i just mentioned it (as one possibility), because oliver asked about
> >> multiple config-sources which provide values for the same key.
> >> independent of the final approach we will agree on (for that use-case),
> it
> >> shouldn't affect the use-case we discuss right now.
> >> (that's the reason for discussing it step by step and if a more complex
> >> case really impacts a simple(r) case later on, we can re-visit the
> >> corresponding api + tests at any time).
> >>
> >> regards,
> >> gerhard
> >>
> >>
> >>
> >> 2014-12-01 19:34 GMT+01:00 Werner Keil <we...@gmail.com>:
> >>
> >> > That's where some sort of "scope" is clearly necessary, see the
> different
> >> > CDI scopes.
> >> > It might make sense to inject a configuration via @Inject too btw. CDI
> >> (and
> >> > AFAIK DeltaSpike) rarely uses singletons or public factories along the
> >> > lines of JSR 354.
> >> > A single class and public accessor can be found in BeanValidation:
> >> > Validation.
> >> > That has a default factory but also offers other providers. If we
> needed
> >> > something similar for Configuration then maybe something like
> >> > getDefault...() could be more appropriate than simply calling it
> >> > getInstance() ;-)
> >> >
> >> > On Mon, Dec 1, 2014 at 7:24 PM, Romain Manni-Bucau <
> >> rmannibucau@gmail.com>
> >> > wrote:
> >> >
> >> > > if you have tamaya in server/lib and call it from webapps for
> >> > > instance, each webapp can use different providers so you need
> >> > > different instances. That is no more a singleton. If it is still one
> >> > > cause we consider it as a factory/builder then the "instance" is
> >> > > useless no?
> >> > >
> >> > >
> >> > > Romain Manni-Bucau
> >> > > @rmannibucau
> >> > > http://www.tomitribe.com
> >> > > http://rmannibucau.wordpress.com
> >> > > https://github.com/rmannibucau
> >> > >
> >> > >
> >> > > 2014-12-01 19:20 GMT+01:00 Werner Keil <we...@gmail.com>:
> >> > > > If you get one by app, is there any form of "context" you'd pass
> to
> >> > such
> >> > > > factory method?
> >> > > >
> >> > > > Currency.getInstance() returns exactly one singleton instance of a
> >> > > Currency
> >> > > > class (otherwise has no constructor either) for a given currency
> >> code.
> >> > > > While Money.of() in JSR 354 RI returns totally different instances
> >> > > > depending on the combination of (nearly unlimited) different
> numbers
> >> > and
> >> > > > currency codes. 354 tries to broaden the definition of Currency,
> but
> >> if
> >> > > you
> >> > > > get exactly one distinct instance per VM/app that's a singleton
> IMHO
> >> > even
> >> > > > if you may call the same application multiple times.
> >> > > >
> >> > > > On Mon, Dec 1, 2014 at 7:12 PM, Romain Manni-Bucau <
> >> > > rmannibucau@gmail.com>
> >> > > > wrote:
> >> > > >
> >> > > >> Hmm,
> >> > > >>
> >> > > >> for me getInstance() = singleton in term of instance where
> >> > > >> Configuration will be all but a singleton IMO (you'll get at
> least
> >> one
> >> > > >> by app and surely a new instance each time you call it) no?
> >> > > >>
> >> > > >>
> >> > > >> Romain Manni-Bucau
> >> > > >> @rmannibucau
> >> > > >> http://www.tomitribe.com
> >> > > >> http://rmannibucau.wordpress.com
> >> > > >> https://github.com/rmannibucau
> >> > > >>
> >> > > >>
> >> > > >> 2014-12-01 18:56 GMT+01:00 Werner Keil <we...@gmail.com>:
> >> > > >> > Hi,
> >> > > >> >
> >> > > >> > Adding to the question of convenience factories, there is no
> such
> >> > > thing
> >> > > >> as
> >> > > >> > "naming convention" by Stephen Colebourne or JSR 310. In fact,
> it
> >> > > >> violates
> >> > > >> > or bends almost every one of them in itself, so a suggestion
> like
> >> > > >> > Configuration.current() would sound very similar to the
> >> > > >> LocalDateTime.now()
> >> > > >> > ones in 310.
> >> > > >> > For several other cases of() or longer variations (like
> ofMilli()
> >> > > >> ofNanos()
> >> > > >> > etc.;-O) are used, while static factories from strings similar
> to
> >> > what
> >> > > >> JSR
> >> > > >> > 354 adopted are called parse(String).
> >> > > >> >
> >> > > >> > Josh Bloch defined a clear distinction between what he then in
> >> most
> >> > > cases
> >> > > >> > (except EnumSet, that's where he started using of() so Josh
> also
> >> > > >> "invented"
> >> > > >> > that while it violated some of his earlier naming
> conventions;-D)
> >> > > called
> >> > > >> > valueOf() and getInstance(), see
> >> > > >> >
> >> > > >>
> >> > >
> >> >
> >>
> http://blog.codefront.net/2003/06/21/java-tip-2-static-factory-methods-vs-constructors/
> >> > > >> > getInstance() returns a singleton, either the only instance for
> >> this
> >> > > type
> >> > > >> > of object or the only instance for a distinct code or enum (see
> >> > > >> > java.util.Currency)
> >> > > >> >
> >> > > >> > Very recent APIs and JSRs like MEEP 8 make a clear distinction,
> >> and
> >> > > >> classes
> >> > > >> > like
> >> > > >> >
> >> > > >>
> >> > >
> >> >
> >>
> https://docs.oracle.com/javame/8.0/api/meep/api/javax/microedition/event/EventManager.html
> >> > > >> > clearly explain that, too. In other places ME 8 uses of() where
> >> > > >> appropriate.
> >> > > >> > So at least getInstance() is neither outdated nor wrong, it
> just
> >> > > depends
> >> > > >> on
> >> > > >> > what you return.
> >> > > >> >
> >> > > >> > If Configuration returns just a default instance then
> >> > > >> > Configuration.getInstance() seems appropriate.
> >> > > >> >
> >> > > >> >
> >> > > >> > Werner Keil | JCP Executive Committee Member, JSR 363 Co Spec
> >> Lead
> >> > |
> >> > > >> > Eclipse UOMo Lead, Babel Language Champion | Apache Committer
> >> > > >> >
> >> > > >> > Twitter @wernerkeil | @UnitAPI | @JSR354 | @DeviceMap |
> >> > #EclipseUOMo |
> >> > > >> > #Java_Social
> >> > > >> > | #DevOps
> >> > > >> > Skype werner.keil | Google+ gplus.to/wernerkeil
> >> > > >> >
> >> > > >> > On Mon, Dec 1, 2014 at 6:31 PM, Oliver B. Fischer <
> >> > > >> o.b.fischer@swe-blog.net>
> >> > > >> > wrote:
> >> > > >> >
> >> > > >> >> Hi,
> >> > > >> >>
> >> > > >> >> for me the most simple use case is
> >> > > >> >>
> >> > > >> >> Configuration conf = new Configuration();
> >> > > >> >> String value = conf.get("key")
> >> > > >> >>
> >> > > >> >> And this use case is already very complex under the hood.
> >> > > >> >>
> >> > > >> >> Before discussing other details we have to decide how
> >> > > PropertyProviders
> >> > > >> >> are activated.
> >> > > >> >>
> >> > > >> >> I would like to have the following possibilites:
> >> > > >> >>
> >> > > >> >> 1. Tamaya activates all PropertyProviders found in the
> classpath
> >> > and
> >> > > >> >> activated via SPI.
> >> > > >> >> 2. Tamaya activates only a explicitly named list of Property
> >> > > providers
> >> > > >> >> 3. I have the ability to control the order in which the
> property
> >> > > >> solution
> >> > > >> >> will be performed
> >> > > >> >>
> >> > > >> >> Bye,
> >> > > >> >>
> >> > > >> >> Oliver
> >> > > >> >>
> >> > > >> >>
> >> > > >> >> Am 01.12.14 17:54, schrieb Romain Manni-Bucau:
> >> > > >> >>
> >> > > >> >>> Configuration.current() sounds easier to understand first
> time
> >> you
> >> > > see
> >> > > >> >>> it. I like Configuration.newInstance() if that's really what
> it
> >> > does
> >> > > >> >>> (ie no caching by classloader or anything else).
> >> > > >> >>>
> >> > > >> >>>
> >> > > >> >>> Romain Manni-Bucau
> >> > > >> >>> @rmannibucau
> >> > > >> >>> http://www.tomitribe.com
> >> > > >> >>> http://rmannibucau.wordpress.com
> >> > > >> >>> https://github.com/rmannibucau
> >> > > >> >>>
> >> > > >> >>>
> >> > > >> >>> 2014-12-01 17:42 GMT+01:00 Anatole Tresch <
> atsticks@gmail.com>:
> >> > > >> >>>
> >> > > >> >>>> There is a naming concept from Stephen Colebourne when to
> use
> >> of,
> >> > > >> from,
> >> > > >> >>>> with. I try to lookup the link later, see also jsr 310 and
> 354.
> >> > > >> >>>> getInstance, valueOf are considered to be outdated for
> modern
> >> api
> >> > > >> design.
> >> > > >> >>>>
> >> > > >> >>>> Adding a helper, why? Another artifact a user must know,
> makes
> >> > > sense,
> >> > > >> >>>> where
> >> > > >> >>>> you have a huge acces api IMO (see PropertyProviders where
> the
> >> > > factory
> >> > > >> >>>> methods are not part of the PropertyProvider interface. For
> >> > > >> >>>> Configuration I
> >> > > >> >>>> prefer having sn intuitive simple/single access...
> >> > > >> >>>>
> >> > > >> >>>> Nevertheless I would like to encourage you to make a
> concrete
> >> > > proposal
> >> > > >> >>>> how
> >> > > >> >>>> would name things, so we can compare what your idea of
> fluent
> >> is
> >> > ;)
> >> > > >> >>>>
> >> > > >> >>>> -anatole
> >> > > >> >>>> Gerhard Petracek <ge...@gmail.com> schrieb am
> Mo.,
> >> 1.
> >> > > Dez.
> >> > > >> >>>> 2014
> >> > > >> >>>> um 17:24:
> >> > > >> >>>>
> >> > > >> >>>> 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
> >> > > >> >>>>> <anatole.tresch@credit-suisse.
> >> > > >> >>>>> com
> >> > > >> >>>>>
> >> > > >> >>>>>> :
> >> > > >> >>>>>> 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:gerhard.petracek@gmail.com
> ]
> >> > > >> >>>>>> Sent: Montag, 1. Dezember 2014 14:30
> >> > > >> >>>>>> To: dev@tamaya.incubator.apache.org
> >> > > >> >>>>>> 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 <
> >> anatole@apache.org
> >> > >:
> >> > > >> >>>>>>
> >> > > >> >>>>>> 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 <ge...@gmail.com> 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 <
> >> > > >> rmannibucau@gmail.com
> >> > > >> >>>>>>>>
> >> > > >> >>>>>>> :
> >> > > >> >>>>>>
> >> > > >> >>>>>>> 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 <
> >> > anatole@apache.org
> >> > > >:
> >> > > >> >>>>>>>>>
> >> > > >> >>>>>>>>>> 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
> >> > > >> >>>>>>>>>>
> >> > > >> >>>>>>>>>>
> >> > > >> >> --
> >> > > >> >> N Oliver B. Fischer
> >> > > >> >> A Schönhauser Allee 64, 10437 Berlin, Deutschland/Germany
> >> > > >> >> P +49 30 44793251
> >> > > >> >> M +49 178 7903538
> >> > > >> >> E o.b.fischer@swe-blog.net
> >> > > >> >> S oliver.b.fischer
> >> > > >> >> J oliver.b.fischer@jabber.org
> >> > > >> >> X http://xing.to/obf
> >> > > >> >>
> >> > > >> >>
> >> > > >>
> >> > >
> >> >
> >>
> >
> >
> >
> > --
> > *Anatole Tresch*
> > Java Engineer & Architect, JSR Spec Lead
> > Glärnischweg 10
> > CH - 8620 Wetzikon
> >
> > *Switzerland, Europe Zurich, GMT+1*
> > *Twitter: @atsticks*
> > *Blogs: **http://javaremarkables.blogspot.ch/
> > <http://javaremarkables.blogspot.ch/>*
> >
> > *Google: atsticksMobile +41-76 344 62 79*
>
Re: Use Case 1: Read simple properties and get values.
Posted by Romain Manni-Bucau <rm...@gmail.com>.
a bt off topic but wouldn't a wiki - confluence - be more efficient
for such discussion. When something is under discussion we put a kind
of poll/table with possibilities and when done we have more or less
some spec/doc.
issue with mails is we switch easily of topic and we need to summarize
regularly.
wdyt?
Romain Manni-Bucau
@rmannibucau
http://www.tomitribe.com
http://rmannibucau.wordpress.com
https://github.com/rmannibucau
2014-12-01 20:12 GMT+01:00 Anatole Tresch <at...@gmail.com>:
> That is also the reason, why I suggested to postpone the assembly/providing
> discussion until we have at least a basic idea of
>
> - PropertyProviders (building blocks)
> - default combination mechanism that help defining new config/providers
> for doing filtering, aggregation, overriding, security, views, ...
> - Configuration (representation and SE access)
> - Environment (basic environment model and access
> - Basic Services (still SE): injection, configuration templates, dynamic
> expressions
> - implementing config changes (events)
>
> Then we are able to really talk about how to best support power users (the
> ones that setup the configuration meta-model) for
>
> - implementing the configuration providers in a system
> - dynamically loading property providers in the right context
> - combining all that stuff with CDI (and Java EE)
> - ...
>
> It is not that I want to prevent any discussions, I just want to add some
> minimal structure to it, so we are more effective ;)
>
> -Anatole
>
>
> 2014-12-01 19:48 GMT+01:00 Gerhard Petracek <ge...@gmail.com>:
>
>> @romain:
>> i just mentioned it (as one possibility), because oliver asked about
>> multiple config-sources which provide values for the same key.
>> independent of the final approach we will agree on (for that use-case), it
>> shouldn't affect the use-case we discuss right now.
>> (that's the reason for discussing it step by step and if a more complex
>> case really impacts a simple(r) case later on, we can re-visit the
>> corresponding api + tests at any time).
>>
>> regards,
>> gerhard
>>
>>
>>
>> 2014-12-01 19:34 GMT+01:00 Werner Keil <we...@gmail.com>:
>>
>> > That's where some sort of "scope" is clearly necessary, see the different
>> > CDI scopes.
>> > It might make sense to inject a configuration via @Inject too btw. CDI
>> (and
>> > AFAIK DeltaSpike) rarely uses singletons or public factories along the
>> > lines of JSR 354.
>> > A single class and public accessor can be found in BeanValidation:
>> > Validation.
>> > That has a default factory but also offers other providers. If we needed
>> > something similar for Configuration then maybe something like
>> > getDefault...() could be more appropriate than simply calling it
>> > getInstance() ;-)
>> >
>> > On Mon, Dec 1, 2014 at 7:24 PM, Romain Manni-Bucau <
>> rmannibucau@gmail.com>
>> > wrote:
>> >
>> > > if you have tamaya in server/lib and call it from webapps for
>> > > instance, each webapp can use different providers so you need
>> > > different instances. That is no more a singleton. If it is still one
>> > > cause we consider it as a factory/builder then the "instance" is
>> > > useless no?
>> > >
>> > >
>> > > Romain Manni-Bucau
>> > > @rmannibucau
>> > > http://www.tomitribe.com
>> > > http://rmannibucau.wordpress.com
>> > > https://github.com/rmannibucau
>> > >
>> > >
>> > > 2014-12-01 19:20 GMT+01:00 Werner Keil <we...@gmail.com>:
>> > > > If you get one by app, is there any form of "context" you'd pass to
>> > such
>> > > > factory method?
>> > > >
>> > > > Currency.getInstance() returns exactly one singleton instance of a
>> > > Currency
>> > > > class (otherwise has no constructor either) for a given currency
>> code.
>> > > > While Money.of() in JSR 354 RI returns totally different instances
>> > > > depending on the combination of (nearly unlimited) different numbers
>> > and
>> > > > currency codes. 354 tries to broaden the definition of Currency, but
>> if
>> > > you
>> > > > get exactly one distinct instance per VM/app that's a singleton IMHO
>> > even
>> > > > if you may call the same application multiple times.
>> > > >
>> > > > On Mon, Dec 1, 2014 at 7:12 PM, Romain Manni-Bucau <
>> > > rmannibucau@gmail.com>
>> > > > wrote:
>> > > >
>> > > >> Hmm,
>> > > >>
>> > > >> for me getInstance() = singleton in term of instance where
>> > > >> Configuration will be all but a singleton IMO (you'll get at least
>> one
>> > > >> by app and surely a new instance each time you call it) no?
>> > > >>
>> > > >>
>> > > >> Romain Manni-Bucau
>> > > >> @rmannibucau
>> > > >> http://www.tomitribe.com
>> > > >> http://rmannibucau.wordpress.com
>> > > >> https://github.com/rmannibucau
>> > > >>
>> > > >>
>> > > >> 2014-12-01 18:56 GMT+01:00 Werner Keil <we...@gmail.com>:
>> > > >> > Hi,
>> > > >> >
>> > > >> > Adding to the question of convenience factories, there is no such
>> > > thing
>> > > >> as
>> > > >> > "naming convention" by Stephen Colebourne or JSR 310. In fact, it
>> > > >> violates
>> > > >> > or bends almost every one of them in itself, so a suggestion like
>> > > >> > Configuration.current() would sound very similar to the
>> > > >> LocalDateTime.now()
>> > > >> > ones in 310.
>> > > >> > For several other cases of() or longer variations (like ofMilli()
>> > > >> ofNanos()
>> > > >> > etc.;-O) are used, while static factories from strings similar to
>> > what
>> > > >> JSR
>> > > >> > 354 adopted are called parse(String).
>> > > >> >
>> > > >> > Josh Bloch defined a clear distinction between what he then in
>> most
>> > > cases
>> > > >> > (except EnumSet, that's where he started using of() so Josh also
>> > > >> "invented"
>> > > >> > that while it violated some of his earlier naming conventions;-D)
>> > > called
>> > > >> > valueOf() and getInstance(), see
>> > > >> >
>> > > >>
>> > >
>> >
>> http://blog.codefront.net/2003/06/21/java-tip-2-static-factory-methods-vs-constructors/
>> > > >> > getInstance() returns a singleton, either the only instance for
>> this
>> > > type
>> > > >> > of object or the only instance for a distinct code or enum (see
>> > > >> > java.util.Currency)
>> > > >> >
>> > > >> > Very recent APIs and JSRs like MEEP 8 make a clear distinction,
>> and
>> > > >> classes
>> > > >> > like
>> > > >> >
>> > > >>
>> > >
>> >
>> https://docs.oracle.com/javame/8.0/api/meep/api/javax/microedition/event/EventManager.html
>> > > >> > clearly explain that, too. In other places ME 8 uses of() where
>> > > >> appropriate.
>> > > >> > So at least getInstance() is neither outdated nor wrong, it just
>> > > depends
>> > > >> on
>> > > >> > what you return.
>> > > >> >
>> > > >> > If Configuration returns just a default instance then
>> > > >> > Configuration.getInstance() seems appropriate.
>> > > >> >
>> > > >> >
>> > > >> > Werner Keil | JCP Executive Committee Member, JSR 363 Co Spec
>> Lead
>> > |
>> > > >> > Eclipse UOMo Lead, Babel Language Champion | Apache Committer
>> > > >> >
>> > > >> > Twitter @wernerkeil | @UnitAPI | @JSR354 | @DeviceMap |
>> > #EclipseUOMo |
>> > > >> > #Java_Social
>> > > >> > | #DevOps
>> > > >> > Skype werner.keil | Google+ gplus.to/wernerkeil
>> > > >> >
>> > > >> > On Mon, Dec 1, 2014 at 6:31 PM, Oliver B. Fischer <
>> > > >> o.b.fischer@swe-blog.net>
>> > > >> > wrote:
>> > > >> >
>> > > >> >> Hi,
>> > > >> >>
>> > > >> >> for me the most simple use case is
>> > > >> >>
>> > > >> >> Configuration conf = new Configuration();
>> > > >> >> String value = conf.get("key")
>> > > >> >>
>> > > >> >> And this use case is already very complex under the hood.
>> > > >> >>
>> > > >> >> Before discussing other details we have to decide how
>> > > PropertyProviders
>> > > >> >> are activated.
>> > > >> >>
>> > > >> >> I would like to have the following possibilites:
>> > > >> >>
>> > > >> >> 1. Tamaya activates all PropertyProviders found in the classpath
>> > and
>> > > >> >> activated via SPI.
>> > > >> >> 2. Tamaya activates only a explicitly named list of Property
>> > > providers
>> > > >> >> 3. I have the ability to control the order in which the property
>> > > >> solution
>> > > >> >> will be performed
>> > > >> >>
>> > > >> >> Bye,
>> > > >> >>
>> > > >> >> Oliver
>> > > >> >>
>> > > >> >>
>> > > >> >> Am 01.12.14 17:54, schrieb Romain Manni-Bucau:
>> > > >> >>
>> > > >> >>> Configuration.current() sounds easier to understand first time
>> you
>> > > see
>> > > >> >>> it. I like Configuration.newInstance() if that's really what it
>> > does
>> > > >> >>> (ie no caching by classloader or anything else).
>> > > >> >>>
>> > > >> >>>
>> > > >> >>> Romain Manni-Bucau
>> > > >> >>> @rmannibucau
>> > > >> >>> http://www.tomitribe.com
>> > > >> >>> http://rmannibucau.wordpress.com
>> > > >> >>> https://github.com/rmannibucau
>> > > >> >>>
>> > > >> >>>
>> > > >> >>> 2014-12-01 17:42 GMT+01:00 Anatole Tresch <at...@gmail.com>:
>> > > >> >>>
>> > > >> >>>> There is a naming concept from Stephen Colebourne when to use
>> of,
>> > > >> from,
>> > > >> >>>> with. I try to lookup the link later, see also jsr 310 and 354.
>> > > >> >>>> getInstance, valueOf are considered to be outdated for modern
>> api
>> > > >> design.
>> > > >> >>>>
>> > > >> >>>> Adding a helper, why? Another artifact a user must know, makes
>> > > sense,
>> > > >> >>>> where
>> > > >> >>>> you have a huge acces api IMO (see PropertyProviders where the
>> > > factory
>> > > >> >>>> methods are not part of the PropertyProvider interface. For
>> > > >> >>>> Configuration I
>> > > >> >>>> prefer having sn intuitive simple/single access...
>> > > >> >>>>
>> > > >> >>>> Nevertheless I would like to encourage you to make a concrete
>> > > proposal
>> > > >> >>>> how
>> > > >> >>>> would name things, so we can compare what your idea of fluent
>> is
>> > ;)
>> > > >> >>>>
>> > > >> >>>> -anatole
>> > > >> >>>> Gerhard Petracek <ge...@gmail.com> schrieb am Mo.,
>> 1.
>> > > Dez.
>> > > >> >>>> 2014
>> > > >> >>>> um 17:24:
>> > > >> >>>>
>> > > >> >>>> 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
>> > > >> >>>>> <anatole.tresch@credit-suisse.
>> > > >> >>>>> com
>> > > >> >>>>>
>> > > >> >>>>>> :
>> > > >> >>>>>> 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:gerhard.petracek@gmail.com]
>> > > >> >>>>>> Sent: Montag, 1. Dezember 2014 14:30
>> > > >> >>>>>> To: dev@tamaya.incubator.apache.org
>> > > >> >>>>>> 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 <
>> anatole@apache.org
>> > >:
>> > > >> >>>>>>
>> > > >> >>>>>> 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 <ge...@gmail.com> 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 <
>> > > >> rmannibucau@gmail.com
>> > > >> >>>>>>>>
>> > > >> >>>>>>> :
>> > > >> >>>>>>
>> > > >> >>>>>>> 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 <
>> > anatole@apache.org
>> > > >:
>> > > >> >>>>>>>>>
>> > > >> >>>>>>>>>> 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
>> > > >> >>>>>>>>>>
>> > > >> >>>>>>>>>>
>> > > >> >> --
>> > > >> >> N Oliver B. Fischer
>> > > >> >> A Schönhauser Allee 64, 10437 Berlin, Deutschland/Germany
>> > > >> >> P +49 30 44793251
>> > > >> >> M +49 178 7903538
>> > > >> >> E o.b.fischer@swe-blog.net
>> > > >> >> S oliver.b.fischer
>> > > >> >> J oliver.b.fischer@jabber.org
>> > > >> >> X http://xing.to/obf
>> > > >> >>
>> > > >> >>
>> > > >>
>> > >
>> >
>>
>
>
>
> --
> *Anatole Tresch*
> Java Engineer & Architect, JSR Spec Lead
> Glärnischweg 10
> CH - 8620 Wetzikon
>
> *Switzerland, Europe Zurich, GMT+1*
> *Twitter: @atsticks*
> *Blogs: **http://javaremarkables.blogspot.ch/
> <http://javaremarkables.blogspot.ch/>*
>
> *Google: atsticksMobile +41-76 344 62 79*
Re: Use Case 1: Read simple properties and get values.
Posted by Anatole Tresch <at...@gmail.com>.
That is also the reason, why I suggested to postpone the assembly/providing
discussion until we have at least a basic idea of
- PropertyProviders (building blocks)
- default combination mechanism that help defining new config/providers
for doing filtering, aggregation, overriding, security, views, ...
- Configuration (representation and SE access)
- Environment (basic environment model and access
- Basic Services (still SE): injection, configuration templates, dynamic
expressions
- implementing config changes (events)
Then we are able to really talk about how to best support power users (the
ones that setup the configuration meta-model) for
- implementing the configuration providers in a system
- dynamically loading property providers in the right context
- combining all that stuff with CDI (and Java EE)
- ...
It is not that I want to prevent any discussions, I just want to add some
minimal structure to it, so we are more effective ;)
-Anatole
2014-12-01 19:48 GMT+01:00 Gerhard Petracek <ge...@gmail.com>:
> @romain:
> i just mentioned it (as one possibility), because oliver asked about
> multiple config-sources which provide values for the same key.
> independent of the final approach we will agree on (for that use-case), it
> shouldn't affect the use-case we discuss right now.
> (that's the reason for discussing it step by step and if a more complex
> case really impacts a simple(r) case later on, we can re-visit the
> corresponding api + tests at any time).
>
> regards,
> gerhard
>
>
>
> 2014-12-01 19:34 GMT+01:00 Werner Keil <we...@gmail.com>:
>
> > That's where some sort of "scope" is clearly necessary, see the different
> > CDI scopes.
> > It might make sense to inject a configuration via @Inject too btw. CDI
> (and
> > AFAIK DeltaSpike) rarely uses singletons or public factories along the
> > lines of JSR 354.
> > A single class and public accessor can be found in BeanValidation:
> > Validation.
> > That has a default factory but also offers other providers. If we needed
> > something similar for Configuration then maybe something like
> > getDefault...() could be more appropriate than simply calling it
> > getInstance() ;-)
> >
> > On Mon, Dec 1, 2014 at 7:24 PM, Romain Manni-Bucau <
> rmannibucau@gmail.com>
> > wrote:
> >
> > > if you have tamaya in server/lib and call it from webapps for
> > > instance, each webapp can use different providers so you need
> > > different instances. That is no more a singleton. If it is still one
> > > cause we consider it as a factory/builder then the "instance" is
> > > useless no?
> > >
> > >
> > > Romain Manni-Bucau
> > > @rmannibucau
> > > http://www.tomitribe.com
> > > http://rmannibucau.wordpress.com
> > > https://github.com/rmannibucau
> > >
> > >
> > > 2014-12-01 19:20 GMT+01:00 Werner Keil <we...@gmail.com>:
> > > > If you get one by app, is there any form of "context" you'd pass to
> > such
> > > > factory method?
> > > >
> > > > Currency.getInstance() returns exactly one singleton instance of a
> > > Currency
> > > > class (otherwise has no constructor either) for a given currency
> code.
> > > > While Money.of() in JSR 354 RI returns totally different instances
> > > > depending on the combination of (nearly unlimited) different numbers
> > and
> > > > currency codes. 354 tries to broaden the definition of Currency, but
> if
> > > you
> > > > get exactly one distinct instance per VM/app that's a singleton IMHO
> > even
> > > > if you may call the same application multiple times.
> > > >
> > > > On Mon, Dec 1, 2014 at 7:12 PM, Romain Manni-Bucau <
> > > rmannibucau@gmail.com>
> > > > wrote:
> > > >
> > > >> Hmm,
> > > >>
> > > >> for me getInstance() = singleton in term of instance where
> > > >> Configuration will be all but a singleton IMO (you'll get at least
> one
> > > >> by app and surely a new instance each time you call it) no?
> > > >>
> > > >>
> > > >> Romain Manni-Bucau
> > > >> @rmannibucau
> > > >> http://www.tomitribe.com
> > > >> http://rmannibucau.wordpress.com
> > > >> https://github.com/rmannibucau
> > > >>
> > > >>
> > > >> 2014-12-01 18:56 GMT+01:00 Werner Keil <we...@gmail.com>:
> > > >> > Hi,
> > > >> >
> > > >> > Adding to the question of convenience factories, there is no such
> > > thing
> > > >> as
> > > >> > "naming convention" by Stephen Colebourne or JSR 310. In fact, it
> > > >> violates
> > > >> > or bends almost every one of them in itself, so a suggestion like
> > > >> > Configuration.current() would sound very similar to the
> > > >> LocalDateTime.now()
> > > >> > ones in 310.
> > > >> > For several other cases of() or longer variations (like ofMilli()
> > > >> ofNanos()
> > > >> > etc.;-O) are used, while static factories from strings similar to
> > what
> > > >> JSR
> > > >> > 354 adopted are called parse(String).
> > > >> >
> > > >> > Josh Bloch defined a clear distinction between what he then in
> most
> > > cases
> > > >> > (except EnumSet, that's where he started using of() so Josh also
> > > >> "invented"
> > > >> > that while it violated some of his earlier naming conventions;-D)
> > > called
> > > >> > valueOf() and getInstance(), see
> > > >> >
> > > >>
> > >
> >
> http://blog.codefront.net/2003/06/21/java-tip-2-static-factory-methods-vs-constructors/
> > > >> > getInstance() returns a singleton, either the only instance for
> this
> > > type
> > > >> > of object or the only instance for a distinct code or enum (see
> > > >> > java.util.Currency)
> > > >> >
> > > >> > Very recent APIs and JSRs like MEEP 8 make a clear distinction,
> and
> > > >> classes
> > > >> > like
> > > >> >
> > > >>
> > >
> >
> https://docs.oracle.com/javame/8.0/api/meep/api/javax/microedition/event/EventManager.html
> > > >> > clearly explain that, too. In other places ME 8 uses of() where
> > > >> appropriate.
> > > >> > So at least getInstance() is neither outdated nor wrong, it just
> > > depends
> > > >> on
> > > >> > what you return.
> > > >> >
> > > >> > If Configuration returns just a default instance then
> > > >> > Configuration.getInstance() seems appropriate.
> > > >> >
> > > >> >
> > > >> > Werner Keil | JCP Executive Committee Member, JSR 363 Co Spec
> Lead
> > |
> > > >> > Eclipse UOMo Lead, Babel Language Champion | Apache Committer
> > > >> >
> > > >> > Twitter @wernerkeil | @UnitAPI | @JSR354 | @DeviceMap |
> > #EclipseUOMo |
> > > >> > #Java_Social
> > > >> > | #DevOps
> > > >> > Skype werner.keil | Google+ gplus.to/wernerkeil
> > > >> >
> > > >> > On Mon, Dec 1, 2014 at 6:31 PM, Oliver B. Fischer <
> > > >> o.b.fischer@swe-blog.net>
> > > >> > wrote:
> > > >> >
> > > >> >> Hi,
> > > >> >>
> > > >> >> for me the most simple use case is
> > > >> >>
> > > >> >> Configuration conf = new Configuration();
> > > >> >> String value = conf.get("key")
> > > >> >>
> > > >> >> And this use case is already very complex under the hood.
> > > >> >>
> > > >> >> Before discussing other details we have to decide how
> > > PropertyProviders
> > > >> >> are activated.
> > > >> >>
> > > >> >> I would like to have the following possibilites:
> > > >> >>
> > > >> >> 1. Tamaya activates all PropertyProviders found in the classpath
> > and
> > > >> >> activated via SPI.
> > > >> >> 2. Tamaya activates only a explicitly named list of Property
> > > providers
> > > >> >> 3. I have the ability to control the order in which the property
> > > >> solution
> > > >> >> will be performed
> > > >> >>
> > > >> >> Bye,
> > > >> >>
> > > >> >> Oliver
> > > >> >>
> > > >> >>
> > > >> >> Am 01.12.14 17:54, schrieb Romain Manni-Bucau:
> > > >> >>
> > > >> >>> Configuration.current() sounds easier to understand first time
> you
> > > see
> > > >> >>> it. I like Configuration.newInstance() if that's really what it
> > does
> > > >> >>> (ie no caching by classloader or anything else).
> > > >> >>>
> > > >> >>>
> > > >> >>> Romain Manni-Bucau
> > > >> >>> @rmannibucau
> > > >> >>> http://www.tomitribe.com
> > > >> >>> http://rmannibucau.wordpress.com
> > > >> >>> https://github.com/rmannibucau
> > > >> >>>
> > > >> >>>
> > > >> >>> 2014-12-01 17:42 GMT+01:00 Anatole Tresch <at...@gmail.com>:
> > > >> >>>
> > > >> >>>> There is a naming concept from Stephen Colebourne when to use
> of,
> > > >> from,
> > > >> >>>> with. I try to lookup the link later, see also jsr 310 and 354.
> > > >> >>>> getInstance, valueOf are considered to be outdated for modern
> api
> > > >> design.
> > > >> >>>>
> > > >> >>>> Adding a helper, why? Another artifact a user must know, makes
> > > sense,
> > > >> >>>> where
> > > >> >>>> you have a huge acces api IMO (see PropertyProviders where the
> > > factory
> > > >> >>>> methods are not part of the PropertyProvider interface. For
> > > >> >>>> Configuration I
> > > >> >>>> prefer having sn intuitive simple/single access...
> > > >> >>>>
> > > >> >>>> Nevertheless I would like to encourage you to make a concrete
> > > proposal
> > > >> >>>> how
> > > >> >>>> would name things, so we can compare what your idea of fluent
> is
> > ;)
> > > >> >>>>
> > > >> >>>> -anatole
> > > >> >>>> Gerhard Petracek <ge...@gmail.com> schrieb am Mo.,
> 1.
> > > Dez.
> > > >> >>>> 2014
> > > >> >>>> um 17:24:
> > > >> >>>>
> > > >> >>>> 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
> > > >> >>>>> <anatole.tresch@credit-suisse.
> > > >> >>>>> com
> > > >> >>>>>
> > > >> >>>>>> :
> > > >> >>>>>> 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:gerhard.petracek@gmail.com]
> > > >> >>>>>> Sent: Montag, 1. Dezember 2014 14:30
> > > >> >>>>>> To: dev@tamaya.incubator.apache.org
> > > >> >>>>>> 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 <
> anatole@apache.org
> > >:
> > > >> >>>>>>
> > > >> >>>>>> 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 <ge...@gmail.com> 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 <
> > > >> rmannibucau@gmail.com
> > > >> >>>>>>>>
> > > >> >>>>>>> :
> > > >> >>>>>>
> > > >> >>>>>>> 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 <
> > anatole@apache.org
> > > >:
> > > >> >>>>>>>>>
> > > >> >>>>>>>>>> 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
> > > >> >>>>>>>>>>
> > > >> >>>>>>>>>>
> > > >> >> --
> > > >> >> N Oliver B. Fischer
> > > >> >> A Schönhauser Allee 64, 10437 Berlin, Deutschland/Germany
> > > >> >> P +49 30 44793251
> > > >> >> M +49 178 7903538
> > > >> >> E o.b.fischer@swe-blog.net
> > > >> >> S oliver.b.fischer
> > > >> >> J oliver.b.fischer@jabber.org
> > > >> >> X http://xing.to/obf
> > > >> >>
> > > >> >>
> > > >>
> > >
> >
>
--
*Anatole Tresch*
Java Engineer & Architect, JSR Spec Lead
Glärnischweg 10
CH - 8620 Wetzikon
*Switzerland, Europe Zurich, GMT+1*
*Twitter: @atsticks*
*Blogs: **http://javaremarkables.blogspot.ch/
<http://javaremarkables.blogspot.ch/>*
*Google: atsticksMobile +41-76 344 62 79*
Re: Use Case 1: Read simple properties and get values.
Posted by Gerhard Petracek <ge...@gmail.com>.
@romain:
i just mentioned it (as one possibility), because oliver asked about
multiple config-sources which provide values for the same key.
independent of the final approach we will agree on (for that use-case), it
shouldn't affect the use-case we discuss right now.
(that's the reason for discussing it step by step and if a more complex
case really impacts a simple(r) case later on, we can re-visit the
corresponding api + tests at any time).
regards,
gerhard
2014-12-01 19:34 GMT+01:00 Werner Keil <we...@gmail.com>:
> That's where some sort of "scope" is clearly necessary, see the different
> CDI scopes.
> It might make sense to inject a configuration via @Inject too btw. CDI (and
> AFAIK DeltaSpike) rarely uses singletons or public factories along the
> lines of JSR 354.
> A single class and public accessor can be found in BeanValidation:
> Validation.
> That has a default factory but also offers other providers. If we needed
> something similar for Configuration then maybe something like
> getDefault...() could be more appropriate than simply calling it
> getInstance() ;-)
>
> On Mon, Dec 1, 2014 at 7:24 PM, Romain Manni-Bucau <rm...@gmail.com>
> wrote:
>
> > if you have tamaya in server/lib and call it from webapps for
> > instance, each webapp can use different providers so you need
> > different instances. That is no more a singleton. If it is still one
> > cause we consider it as a factory/builder then the "instance" is
> > useless no?
> >
> >
> > Romain Manni-Bucau
> > @rmannibucau
> > http://www.tomitribe.com
> > http://rmannibucau.wordpress.com
> > https://github.com/rmannibucau
> >
> >
> > 2014-12-01 19:20 GMT+01:00 Werner Keil <we...@gmail.com>:
> > > If you get one by app, is there any form of "context" you'd pass to
> such
> > > factory method?
> > >
> > > Currency.getInstance() returns exactly one singleton instance of a
> > Currency
> > > class (otherwise has no constructor either) for a given currency code.
> > > While Money.of() in JSR 354 RI returns totally different instances
> > > depending on the combination of (nearly unlimited) different numbers
> and
> > > currency codes. 354 tries to broaden the definition of Currency, but if
> > you
> > > get exactly one distinct instance per VM/app that's a singleton IMHO
> even
> > > if you may call the same application multiple times.
> > >
> > > On Mon, Dec 1, 2014 at 7:12 PM, Romain Manni-Bucau <
> > rmannibucau@gmail.com>
> > > wrote:
> > >
> > >> Hmm,
> > >>
> > >> for me getInstance() = singleton in term of instance where
> > >> Configuration will be all but a singleton IMO (you'll get at least one
> > >> by app and surely a new instance each time you call it) no?
> > >>
> > >>
> > >> Romain Manni-Bucau
> > >> @rmannibucau
> > >> http://www.tomitribe.com
> > >> http://rmannibucau.wordpress.com
> > >> https://github.com/rmannibucau
> > >>
> > >>
> > >> 2014-12-01 18:56 GMT+01:00 Werner Keil <we...@gmail.com>:
> > >> > Hi,
> > >> >
> > >> > Adding to the question of convenience factories, there is no such
> > thing
> > >> as
> > >> > "naming convention" by Stephen Colebourne or JSR 310. In fact, it
> > >> violates
> > >> > or bends almost every one of them in itself, so a suggestion like
> > >> > Configuration.current() would sound very similar to the
> > >> LocalDateTime.now()
> > >> > ones in 310.
> > >> > For several other cases of() or longer variations (like ofMilli()
> > >> ofNanos()
> > >> > etc.;-O) are used, while static factories from strings similar to
> what
> > >> JSR
> > >> > 354 adopted are called parse(String).
> > >> >
> > >> > Josh Bloch defined a clear distinction between what he then in most
> > cases
> > >> > (except EnumSet, that's where he started using of() so Josh also
> > >> "invented"
> > >> > that while it violated some of his earlier naming conventions;-D)
> > called
> > >> > valueOf() and getInstance(), see
> > >> >
> > >>
> >
> http://blog.codefront.net/2003/06/21/java-tip-2-static-factory-methods-vs-constructors/
> > >> > getInstance() returns a singleton, either the only instance for this
> > type
> > >> > of object or the only instance for a distinct code or enum (see
> > >> > java.util.Currency)
> > >> >
> > >> > Very recent APIs and JSRs like MEEP 8 make a clear distinction, and
> > >> classes
> > >> > like
> > >> >
> > >>
> >
> https://docs.oracle.com/javame/8.0/api/meep/api/javax/microedition/event/EventManager.html
> > >> > clearly explain that, too. In other places ME 8 uses of() where
> > >> appropriate.
> > >> > So at least getInstance() is neither outdated nor wrong, it just
> > depends
> > >> on
> > >> > what you return.
> > >> >
> > >> > If Configuration returns just a default instance then
> > >> > Configuration.getInstance() seems appropriate.
> > >> >
> > >> >
> > >> > Werner Keil | JCP Executive Committee Member, JSR 363 Co Spec Lead
> |
> > >> > Eclipse UOMo Lead, Babel Language Champion | Apache Committer
> > >> >
> > >> > Twitter @wernerkeil | @UnitAPI | @JSR354 | @DeviceMap |
> #EclipseUOMo |
> > >> > #Java_Social
> > >> > | #DevOps
> > >> > Skype werner.keil | Google+ gplus.to/wernerkeil
> > >> >
> > >> > On Mon, Dec 1, 2014 at 6:31 PM, Oliver B. Fischer <
> > >> o.b.fischer@swe-blog.net>
> > >> > wrote:
> > >> >
> > >> >> Hi,
> > >> >>
> > >> >> for me the most simple use case is
> > >> >>
> > >> >> Configuration conf = new Configuration();
> > >> >> String value = conf.get("key")
> > >> >>
> > >> >> And this use case is already very complex under the hood.
> > >> >>
> > >> >> Before discussing other details we have to decide how
> > PropertyProviders
> > >> >> are activated.
> > >> >>
> > >> >> I would like to have the following possibilites:
> > >> >>
> > >> >> 1. Tamaya activates all PropertyProviders found in the classpath
> and
> > >> >> activated via SPI.
> > >> >> 2. Tamaya activates only a explicitly named list of Property
> > providers
> > >> >> 3. I have the ability to control the order in which the property
> > >> solution
> > >> >> will be performed
> > >> >>
> > >> >> Bye,
> > >> >>
> > >> >> Oliver
> > >> >>
> > >> >>
> > >> >> Am 01.12.14 17:54, schrieb Romain Manni-Bucau:
> > >> >>
> > >> >>> Configuration.current() sounds easier to understand first time you
> > see
> > >> >>> it. I like Configuration.newInstance() if that's really what it
> does
> > >> >>> (ie no caching by classloader or anything else).
> > >> >>>
> > >> >>>
> > >> >>> Romain Manni-Bucau
> > >> >>> @rmannibucau
> > >> >>> http://www.tomitribe.com
> > >> >>> http://rmannibucau.wordpress.com
> > >> >>> https://github.com/rmannibucau
> > >> >>>
> > >> >>>
> > >> >>> 2014-12-01 17:42 GMT+01:00 Anatole Tresch <at...@gmail.com>:
> > >> >>>
> > >> >>>> There is a naming concept from Stephen Colebourne when to use of,
> > >> from,
> > >> >>>> with. I try to lookup the link later, see also jsr 310 and 354.
> > >> >>>> getInstance, valueOf are considered to be outdated for modern api
> > >> design.
> > >> >>>>
> > >> >>>> Adding a helper, why? Another artifact a user must know, makes
> > sense,
> > >> >>>> where
> > >> >>>> you have a huge acces api IMO (see PropertyProviders where the
> > factory
> > >> >>>> methods are not part of the PropertyProvider interface. For
> > >> >>>> Configuration I
> > >> >>>> prefer having sn intuitive simple/single access...
> > >> >>>>
> > >> >>>> Nevertheless I would like to encourage you to make a concrete
> > proposal
> > >> >>>> how
> > >> >>>> would name things, so we can compare what your idea of fluent is
> ;)
> > >> >>>>
> > >> >>>> -anatole
> > >> >>>> Gerhard Petracek <ge...@gmail.com> schrieb am Mo., 1.
> > Dez.
> > >> >>>> 2014
> > >> >>>> um 17:24:
> > >> >>>>
> > >> >>>> 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
> > >> >>>>> <anatole.tresch@credit-suisse.
> > >> >>>>> com
> > >> >>>>>
> > >> >>>>>> :
> > >> >>>>>> 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:gerhard.petracek@gmail.com]
> > >> >>>>>> Sent: Montag, 1. Dezember 2014 14:30
> > >> >>>>>> To: dev@tamaya.incubator.apache.org
> > >> >>>>>> 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 <anatole@apache.org
> >:
> > >> >>>>>>
> > >> >>>>>> 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 <ge...@gmail.com> 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 <
> > >> rmannibucau@gmail.com
> > >> >>>>>>>>
> > >> >>>>>>> :
> > >> >>>>>>
> > >> >>>>>>> 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 <
> anatole@apache.org
> > >:
> > >> >>>>>>>>>
> > >> >>>>>>>>>> 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
> > >> >>>>>>>>>>
> > >> >>>>>>>>>>
> > >> >> --
> > >> >> N Oliver B. Fischer
> > >> >> A Schönhauser Allee 64, 10437 Berlin, Deutschland/Germany
> > >> >> P +49 30 44793251
> > >> >> M +49 178 7903538
> > >> >> E o.b.fischer@swe-blog.net
> > >> >> S oliver.b.fischer
> > >> >> J oliver.b.fischer@jabber.org
> > >> >> X http://xing.to/obf
> > >> >>
> > >> >>
> > >>
> >
>
Re: Use Case 1: Read simple properties and get values.
Posted by Anatole Tresch <at...@gmail.com>.
Yep. The "scope" in configuration is typically the Environment. That is the
reason, why we need an environment model...
2014-12-01 19:34 GMT+01:00 Werner Keil <we...@gmail.com>:
> That's where some sort of "scope" is clearly necessary, see the different
> CDI scopes.
> It might make sense to inject a configuration via @Inject too btw. CDI (and
> AFAIK DeltaSpike) rarely uses singletons or public factories along the
> lines of JSR 354.
> A single class and public accessor can be found in BeanValidation:
> Validation.
> That has a default factory but also offers other providers. If we needed
> something similar for Configuration then maybe something like
> getDefault...() could be more appropriate than simply calling it
> getInstance() ;-)
>
> On Mon, Dec 1, 2014 at 7:24 PM, Romain Manni-Bucau <rm...@gmail.com>
> wrote:
>
> > if you have tamaya in server/lib and call it from webapps for
> > instance, each webapp can use different providers so you need
> > different instances. That is no more a singleton. If it is still one
> > cause we consider it as a factory/builder then the "instance" is
> > useless no?
> >
> >
> > Romain Manni-Bucau
> > @rmannibucau
> > http://www.tomitribe.com
> > http://rmannibucau.wordpress.com
> > https://github.com/rmannibucau
> >
> >
> > 2014-12-01 19:20 GMT+01:00 Werner Keil <we...@gmail.com>:
> > > If you get one by app, is there any form of "context" you'd pass to
> such
> > > factory method?
> > >
> > > Currency.getInstance() returns exactly one singleton instance of a
> > Currency
> > > class (otherwise has no constructor either) for a given currency code.
> > > While Money.of() in JSR 354 RI returns totally different instances
> > > depending on the combination of (nearly unlimited) different numbers
> and
> > > currency codes. 354 tries to broaden the definition of Currency, but if
> > you
> > > get exactly one distinct instance per VM/app that's a singleton IMHO
> even
> > > if you may call the same application multiple times.
> > >
> > > On Mon, Dec 1, 2014 at 7:12 PM, Romain Manni-Bucau <
> > rmannibucau@gmail.com>
> > > wrote:
> > >
> > >> Hmm,
> > >>
> > >> for me getInstance() = singleton in term of instance where
> > >> Configuration will be all but a singleton IMO (you'll get at least one
> > >> by app and surely a new instance each time you call it) no?
> > >>
> > >>
> > >> Romain Manni-Bucau
> > >> @rmannibucau
> > >> http://www.tomitribe.com
> > >> http://rmannibucau.wordpress.com
> > >> https://github.com/rmannibucau
> > >>
> > >>
> > >> 2014-12-01 18:56 GMT+01:00 Werner Keil <we...@gmail.com>:
> > >> > Hi,
> > >> >
> > >> > Adding to the question of convenience factories, there is no such
> > thing
> > >> as
> > >> > "naming convention" by Stephen Colebourne or JSR 310. In fact, it
> > >> violates
> > >> > or bends almost every one of them in itself, so a suggestion like
> > >> > Configuration.current() would sound very similar to the
> > >> LocalDateTime.now()
> > >> > ones in 310.
> > >> > For several other cases of() or longer variations (like ofMilli()
> > >> ofNanos()
> > >> > etc.;-O) are used, while static factories from strings similar to
> what
> > >> JSR
> > >> > 354 adopted are called parse(String).
> > >> >
> > >> > Josh Bloch defined a clear distinction between what he then in most
> > cases
> > >> > (except EnumSet, that's where he started using of() so Josh also
> > >> "invented"
> > >> > that while it violated some of his earlier naming conventions;-D)
> > called
> > >> > valueOf() and getInstance(), see
> > >> >
> > >>
> >
> http://blog.codefront.net/2003/06/21/java-tip-2-static-factory-methods-vs-constructors/
> > >> > getInstance() returns a singleton, either the only instance for this
> > type
> > >> > of object or the only instance for a distinct code or enum (see
> > >> > java.util.Currency)
> > >> >
> > >> > Very recent APIs and JSRs like MEEP 8 make a clear distinction, and
> > >> classes
> > >> > like
> > >> >
> > >>
> >
> https://docs.oracle.com/javame/8.0/api/meep/api/javax/microedition/event/EventManager.html
> > >> > clearly explain that, too. In other places ME 8 uses of() where
> > >> appropriate.
> > >> > So at least getInstance() is neither outdated nor wrong, it just
> > depends
> > >> on
> > >> > what you return.
> > >> >
> > >> > If Configuration returns just a default instance then
> > >> > Configuration.getInstance() seems appropriate.
> > >> >
> > >> >
> > >> > Werner Keil | JCP Executive Committee Member, JSR 363 Co Spec Lead
> |
> > >> > Eclipse UOMo Lead, Babel Language Champion | Apache Committer
> > >> >
> > >> > Twitter @wernerkeil | @UnitAPI | @JSR354 | @DeviceMap |
> #EclipseUOMo |
> > >> > #Java_Social
> > >> > | #DevOps
> > >> > Skype werner.keil | Google+ gplus.to/wernerkeil
> > >> >
> > >> > On Mon, Dec 1, 2014 at 6:31 PM, Oliver B. Fischer <
> > >> o.b.fischer@swe-blog.net>
> > >> > wrote:
> > >> >
> > >> >> Hi,
> > >> >>
> > >> >> for me the most simple use case is
> > >> >>
> > >> >> Configuration conf = new Configuration();
> > >> >> String value = conf.get("key")
> > >> >>
> > >> >> And this use case is already very complex under the hood.
> > >> >>
> > >> >> Before discussing other details we have to decide how
> > PropertyProviders
> > >> >> are activated.
> > >> >>
> > >> >> I would like to have the following possibilites:
> > >> >>
> > >> >> 1. Tamaya activates all PropertyProviders found in the classpath
> and
> > >> >> activated via SPI.
> > >> >> 2. Tamaya activates only a explicitly named list of Property
> > providers
> > >> >> 3. I have the ability to control the order in which the property
> > >> solution
> > >> >> will be performed
> > >> >>
> > >> >> Bye,
> > >> >>
> > >> >> Oliver
> > >> >>
> > >> >>
> > >> >> Am 01.12.14 17:54, schrieb Romain Manni-Bucau:
> > >> >>
> > >> >>> Configuration.current() sounds easier to understand first time you
> > see
> > >> >>> it. I like Configuration.newInstance() if that's really what it
> does
> > >> >>> (ie no caching by classloader or anything else).
> > >> >>>
> > >> >>>
> > >> >>> Romain Manni-Bucau
> > >> >>> @rmannibucau
> > >> >>> http://www.tomitribe.com
> > >> >>> http://rmannibucau.wordpress.com
> > >> >>> https://github.com/rmannibucau
> > >> >>>
> > >> >>>
> > >> >>> 2014-12-01 17:42 GMT+01:00 Anatole Tresch <at...@gmail.com>:
> > >> >>>
> > >> >>>> There is a naming concept from Stephen Colebourne when to use of,
> > >> from,
> > >> >>>> with. I try to lookup the link later, see also jsr 310 and 354.
> > >> >>>> getInstance, valueOf are considered to be outdated for modern api
> > >> design.
> > >> >>>>
> > >> >>>> Adding a helper, why? Another artifact a user must know, makes
> > sense,
> > >> >>>> where
> > >> >>>> you have a huge acces api IMO (see PropertyProviders where the
> > factory
> > >> >>>> methods are not part of the PropertyProvider interface. For
> > >> >>>> Configuration I
> > >> >>>> prefer having sn intuitive simple/single access...
> > >> >>>>
> > >> >>>> Nevertheless I would like to encourage you to make a concrete
> > proposal
> > >> >>>> how
> > >> >>>> would name things, so we can compare what your idea of fluent is
> ;)
> > >> >>>>
> > >> >>>> -anatole
> > >> >>>> Gerhard Petracek <ge...@gmail.com> schrieb am Mo., 1.
> > Dez.
> > >> >>>> 2014
> > >> >>>> um 17:24:
> > >> >>>>
> > >> >>>> 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
> > >> >>>>> <anatole.tresch@credit-suisse.
> > >> >>>>> com
> > >> >>>>>
> > >> >>>>>> :
> > >> >>>>>> 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:gerhard.petracek@gmail.com]
> > >> >>>>>> Sent: Montag, 1. Dezember 2014 14:30
> > >> >>>>>> To: dev@tamaya.incubator.apache.org
> > >> >>>>>> 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 <anatole@apache.org
> >:
> > >> >>>>>>
> > >> >>>>>> 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 <ge...@gmail.com> 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 <
> > >> rmannibucau@gmail.com
> > >> >>>>>>>>
> > >> >>>>>>> :
> > >> >>>>>>
> > >> >>>>>>> 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 <
> anatole@apache.org
> > >:
> > >> >>>>>>>>>
> > >> >>>>>>>>>> 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
> > >> >>>>>>>>>>
> > >> >>>>>>>>>>
> > >> >> --
> > >> >> N Oliver B. Fischer
> > >> >> A Schönhauser Allee 64, 10437 Berlin, Deutschland/Germany
> > >> >> P +49 30 44793251
> > >> >> M +49 178 7903538
> > >> >> E o.b.fischer@swe-blog.net
> > >> >> S oliver.b.fischer
> > >> >> J oliver.b.fischer@jabber.org
> > >> >> X http://xing.to/obf
> > >> >>
> > >> >>
> > >>
> >
>
--
*Anatole Tresch*
Java Engineer & Architect, JSR Spec Lead
Glärnischweg 10
CH - 8620 Wetzikon
*Switzerland, Europe Zurich, GMT+1*
*Twitter: @atsticks*
*Blogs: **http://javaremarkables.blogspot.ch/
<http://javaremarkables.blogspot.ch/>*
*Google: atsticksMobile +41-76 344 62 79*
Re: Use Case 1: Read simple properties and get values.
Posted by Anatole Tresch <at...@gmail.com>.
I think current() is still better because it is not a default, it may
differ depending the runtime context, even within the same web
application...
2014-12-01 19:34 GMT+01:00 Werner Keil <we...@gmail.com>:
> That's where some sort of "scope" is clearly necessary, see the different
> CDI scopes.
> It might make sense to inject a configuration via @Inject too btw. CDI (and
> AFAIK DeltaSpike) rarely uses singletons or public factories along the
> lines of JSR 354.
> A single class and public accessor can be found in BeanValidation:
> Validation.
> That has a default factory but also offers other providers. If we needed
> something similar for Configuration then maybe something like
> getDefault...() could be more appropriate than simply calling it
> getInstance() ;-)
>
> On Mon, Dec 1, 2014 at 7:24 PM, Romain Manni-Bucau <rm...@gmail.com>
> wrote:
>
> > if you have tamaya in server/lib and call it from webapps for
> > instance, each webapp can use different providers so you need
> > different instances. That is no more a singleton. If it is still one
> > cause we consider it as a factory/builder then the "instance" is
> > useless no?
> >
> >
> > Romain Manni-Bucau
> > @rmannibucau
> > http://www.tomitribe.com
> > http://rmannibucau.wordpress.com
> > https://github.com/rmannibucau
> >
> >
> > 2014-12-01 19:20 GMT+01:00 Werner Keil <we...@gmail.com>:
> > > If you get one by app, is there any form of "context" you'd pass to
> such
> > > factory method?
> > >
> > > Currency.getInstance() returns exactly one singleton instance of a
> > Currency
> > > class (otherwise has no constructor either) for a given currency code.
> > > While Money.of() in JSR 354 RI returns totally different instances
> > > depending on the combination of (nearly unlimited) different numbers
> and
> > > currency codes. 354 tries to broaden the definition of Currency, but if
> > you
> > > get exactly one distinct instance per VM/app that's a singleton IMHO
> even
> > > if you may call the same application multiple times.
> > >
> > > On Mon, Dec 1, 2014 at 7:12 PM, Romain Manni-Bucau <
> > rmannibucau@gmail.com>
> > > wrote:
> > >
> > >> Hmm,
> > >>
> > >> for me getInstance() = singleton in term of instance where
> > >> Configuration will be all but a singleton IMO (you'll get at least one
> > >> by app and surely a new instance each time you call it) no?
> > >>
> > >>
> > >> Romain Manni-Bucau
> > >> @rmannibucau
> > >> http://www.tomitribe.com
> > >> http://rmannibucau.wordpress.com
> > >> https://github.com/rmannibucau
> > >>
> > >>
> > >> 2014-12-01 18:56 GMT+01:00 Werner Keil <we...@gmail.com>:
> > >> > Hi,
> > >> >
> > >> > Adding to the question of convenience factories, there is no such
> > thing
> > >> as
> > >> > "naming convention" by Stephen Colebourne or JSR 310. In fact, it
> > >> violates
> > >> > or bends almost every one of them in itself, so a suggestion like
> > >> > Configuration.current() would sound very similar to the
> > >> LocalDateTime.now()
> > >> > ones in 310.
> > >> > For several other cases of() or longer variations (like ofMilli()
> > >> ofNanos()
> > >> > etc.;-O) are used, while static factories from strings similar to
> what
> > >> JSR
> > >> > 354 adopted are called parse(String).
> > >> >
> > >> > Josh Bloch defined a clear distinction between what he then in most
> > cases
> > >> > (except EnumSet, that's where he started using of() so Josh also
> > >> "invented"
> > >> > that while it violated some of his earlier naming conventions;-D)
> > called
> > >> > valueOf() and getInstance(), see
> > >> >
> > >>
> >
> http://blog.codefront.net/2003/06/21/java-tip-2-static-factory-methods-vs-constructors/
> > >> > getInstance() returns a singleton, either the only instance for this
> > type
> > >> > of object or the only instance for a distinct code or enum (see
> > >> > java.util.Currency)
> > >> >
> > >> > Very recent APIs and JSRs like MEEP 8 make a clear distinction, and
> > >> classes
> > >> > like
> > >> >
> > >>
> >
> https://docs.oracle.com/javame/8.0/api/meep/api/javax/microedition/event/EventManager.html
> > >> > clearly explain that, too. In other places ME 8 uses of() where
> > >> appropriate.
> > >> > So at least getInstance() is neither outdated nor wrong, it just
> > depends
> > >> on
> > >> > what you return.
> > >> >
> > >> > If Configuration returns just a default instance then
> > >> > Configuration.getInstance() seems appropriate.
> > >> >
> > >> >
> > >> > Werner Keil | JCP Executive Committee Member, JSR 363 Co Spec Lead
> |
> > >> > Eclipse UOMo Lead, Babel Language Champion | Apache Committer
> > >> >
> > >> > Twitter @wernerkeil | @UnitAPI | @JSR354 | @DeviceMap |
> #EclipseUOMo |
> > >> > #Java_Social
> > >> > | #DevOps
> > >> > Skype werner.keil | Google+ gplus.to/wernerkeil
> > >> >
> > >> > On Mon, Dec 1, 2014 at 6:31 PM, Oliver B. Fischer <
> > >> o.b.fischer@swe-blog.net>
> > >> > wrote:
> > >> >
> > >> >> Hi,
> > >> >>
> > >> >> for me the most simple use case is
> > >> >>
> > >> >> Configuration conf = new Configuration();
> > >> >> String value = conf.get("key")
> > >> >>
> > >> >> And this use case is already very complex under the hood.
> > >> >>
> > >> >> Before discussing other details we have to decide how
> > PropertyProviders
> > >> >> are activated.
> > >> >>
> > >> >> I would like to have the following possibilites:
> > >> >>
> > >> >> 1. Tamaya activates all PropertyProviders found in the classpath
> and
> > >> >> activated via SPI.
> > >> >> 2. Tamaya activates only a explicitly named list of Property
> > providers
> > >> >> 3. I have the ability to control the order in which the property
> > >> solution
> > >> >> will be performed
> > >> >>
> > >> >> Bye,
> > >> >>
> > >> >> Oliver
> > >> >>
> > >> >>
> > >> >> Am 01.12.14 17:54, schrieb Romain Manni-Bucau:
> > >> >>
> > >> >>> Configuration.current() sounds easier to understand first time you
> > see
> > >> >>> it. I like Configuration.newInstance() if that's really what it
> does
> > >> >>> (ie no caching by classloader or anything else).
> > >> >>>
> > >> >>>
> > >> >>> Romain Manni-Bucau
> > >> >>> @rmannibucau
> > >> >>> http://www.tomitribe.com
> > >> >>> http://rmannibucau.wordpress.com
> > >> >>> https://github.com/rmannibucau
> > >> >>>
> > >> >>>
> > >> >>> 2014-12-01 17:42 GMT+01:00 Anatole Tresch <at...@gmail.com>:
> > >> >>>
> > >> >>>> There is a naming concept from Stephen Colebourne when to use of,
> > >> from,
> > >> >>>> with. I try to lookup the link later, see also jsr 310 and 354.
> > >> >>>> getInstance, valueOf are considered to be outdated for modern api
> > >> design.
> > >> >>>>
> > >> >>>> Adding a helper, why? Another artifact a user must know, makes
> > sense,
> > >> >>>> where
> > >> >>>> you have a huge acces api IMO (see PropertyProviders where the
> > factory
> > >> >>>> methods are not part of the PropertyProvider interface. For
> > >> >>>> Configuration I
> > >> >>>> prefer having sn intuitive simple/single access...
> > >> >>>>
> > >> >>>> Nevertheless I would like to encourage you to make a concrete
> > proposal
> > >> >>>> how
> > >> >>>> would name things, so we can compare what your idea of fluent is
> ;)
> > >> >>>>
> > >> >>>> -anatole
> > >> >>>> Gerhard Petracek <ge...@gmail.com> schrieb am Mo., 1.
> > Dez.
> > >> >>>> 2014
> > >> >>>> um 17:24:
> > >> >>>>
> > >> >>>> 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
> > >> >>>>> <anatole.tresch@credit-suisse.
> > >> >>>>> com
> > >> >>>>>
> > >> >>>>>> :
> > >> >>>>>> 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:gerhard.petracek@gmail.com]
> > >> >>>>>> Sent: Montag, 1. Dezember 2014 14:30
> > >> >>>>>> To: dev@tamaya.incubator.apache.org
> > >> >>>>>> 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 <anatole@apache.org
> >:
> > >> >>>>>>
> > >> >>>>>> 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 <ge...@gmail.com> 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 <
> > >> rmannibucau@gmail.com
> > >> >>>>>>>>
> > >> >>>>>>> :
> > >> >>>>>>
> > >> >>>>>>> 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 <
> anatole@apache.org
> > >:
> > >> >>>>>>>>>
> > >> >>>>>>>>>> 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
> > >> >>>>>>>>>>
> > >> >>>>>>>>>>
> > >> >> --
> > >> >> N Oliver B. Fischer
> > >> >> A Schönhauser Allee 64, 10437 Berlin, Deutschland/Germany
> > >> >> P +49 30 44793251
> > >> >> M +49 178 7903538
> > >> >> E o.b.fischer@swe-blog.net
> > >> >> S oliver.b.fischer
> > >> >> J oliver.b.fischer@jabber.org
> > >> >> X http://xing.to/obf
> > >> >>
> > >> >>
> > >>
> >
>
--
*Anatole Tresch*
Java Engineer & Architect, JSR Spec Lead
Glärnischweg 10
CH - 8620 Wetzikon
*Switzerland, Europe Zurich, GMT+1*
*Twitter: @atsticks*
*Blogs: **http://javaremarkables.blogspot.ch/
<http://javaremarkables.blogspot.ch/>*
*Google: atsticksMobile +41-76 344 62 79*
Re: Use Case 1: Read simple properties and get values.
Posted by Werner Keil <we...@gmail.com>.
That's where some sort of "scope" is clearly necessary, see the different
CDI scopes.
It might make sense to inject a configuration via @Inject too btw. CDI (and
AFAIK DeltaSpike) rarely uses singletons or public factories along the
lines of JSR 354.
A single class and public accessor can be found in BeanValidation:
Validation.
That has a default factory but also offers other providers. If we needed
something similar for Configuration then maybe something like
getDefault...() could be more appropriate than simply calling it
getInstance() ;-)
On Mon, Dec 1, 2014 at 7:24 PM, Romain Manni-Bucau <rm...@gmail.com>
wrote:
> if you have tamaya in server/lib and call it from webapps for
> instance, each webapp can use different providers so you need
> different instances. That is no more a singleton. If it is still one
> cause we consider it as a factory/builder then the "instance" is
> useless no?
>
>
> Romain Manni-Bucau
> @rmannibucau
> http://www.tomitribe.com
> http://rmannibucau.wordpress.com
> https://github.com/rmannibucau
>
>
> 2014-12-01 19:20 GMT+01:00 Werner Keil <we...@gmail.com>:
> > If you get one by app, is there any form of "context" you'd pass to such
> > factory method?
> >
> > Currency.getInstance() returns exactly one singleton instance of a
> Currency
> > class (otherwise has no constructor either) for a given currency code.
> > While Money.of() in JSR 354 RI returns totally different instances
> > depending on the combination of (nearly unlimited) different numbers and
> > currency codes. 354 tries to broaden the definition of Currency, but if
> you
> > get exactly one distinct instance per VM/app that's a singleton IMHO even
> > if you may call the same application multiple times.
> >
> > On Mon, Dec 1, 2014 at 7:12 PM, Romain Manni-Bucau <
> rmannibucau@gmail.com>
> > wrote:
> >
> >> Hmm,
> >>
> >> for me getInstance() = singleton in term of instance where
> >> Configuration will be all but a singleton IMO (you'll get at least one
> >> by app and surely a new instance each time you call it) no?
> >>
> >>
> >> Romain Manni-Bucau
> >> @rmannibucau
> >> http://www.tomitribe.com
> >> http://rmannibucau.wordpress.com
> >> https://github.com/rmannibucau
> >>
> >>
> >> 2014-12-01 18:56 GMT+01:00 Werner Keil <we...@gmail.com>:
> >> > Hi,
> >> >
> >> > Adding to the question of convenience factories, there is no such
> thing
> >> as
> >> > "naming convention" by Stephen Colebourne or JSR 310. In fact, it
> >> violates
> >> > or bends almost every one of them in itself, so a suggestion like
> >> > Configuration.current() would sound very similar to the
> >> LocalDateTime.now()
> >> > ones in 310.
> >> > For several other cases of() or longer variations (like ofMilli()
> >> ofNanos()
> >> > etc.;-O) are used, while static factories from strings similar to what
> >> JSR
> >> > 354 adopted are called parse(String).
> >> >
> >> > Josh Bloch defined a clear distinction between what he then in most
> cases
> >> > (except EnumSet, that's where he started using of() so Josh also
> >> "invented"
> >> > that while it violated some of his earlier naming conventions;-D)
> called
> >> > valueOf() and getInstance(), see
> >> >
> >>
> http://blog.codefront.net/2003/06/21/java-tip-2-static-factory-methods-vs-constructors/
> >> > getInstance() returns a singleton, either the only instance for this
> type
> >> > of object or the only instance for a distinct code or enum (see
> >> > java.util.Currency)
> >> >
> >> > Very recent APIs and JSRs like MEEP 8 make a clear distinction, and
> >> classes
> >> > like
> >> >
> >>
> https://docs.oracle.com/javame/8.0/api/meep/api/javax/microedition/event/EventManager.html
> >> > clearly explain that, too. In other places ME 8 uses of() where
> >> appropriate.
> >> > So at least getInstance() is neither outdated nor wrong, it just
> depends
> >> on
> >> > what you return.
> >> >
> >> > If Configuration returns just a default instance then
> >> > Configuration.getInstance() seems appropriate.
> >> >
> >> >
> >> > Werner Keil | JCP Executive Committee Member, JSR 363 Co Spec Lead |
> >> > Eclipse UOMo Lead, Babel Language Champion | Apache Committer
> >> >
> >> > Twitter @wernerkeil | @UnitAPI | @JSR354 | @DeviceMap | #EclipseUOMo |
> >> > #Java_Social
> >> > | #DevOps
> >> > Skype werner.keil | Google+ gplus.to/wernerkeil
> >> >
> >> > On Mon, Dec 1, 2014 at 6:31 PM, Oliver B. Fischer <
> >> o.b.fischer@swe-blog.net>
> >> > wrote:
> >> >
> >> >> Hi,
> >> >>
> >> >> for me the most simple use case is
> >> >>
> >> >> Configuration conf = new Configuration();
> >> >> String value = conf.get("key")
> >> >>
> >> >> And this use case is already very complex under the hood.
> >> >>
> >> >> Before discussing other details we have to decide how
> PropertyProviders
> >> >> are activated.
> >> >>
> >> >> I would like to have the following possibilites:
> >> >>
> >> >> 1. Tamaya activates all PropertyProviders found in the classpath and
> >> >> activated via SPI.
> >> >> 2. Tamaya activates only a explicitly named list of Property
> providers
> >> >> 3. I have the ability to control the order in which the property
> >> solution
> >> >> will be performed
> >> >>
> >> >> Bye,
> >> >>
> >> >> Oliver
> >> >>
> >> >>
> >> >> Am 01.12.14 17:54, schrieb Romain Manni-Bucau:
> >> >>
> >> >>> Configuration.current() sounds easier to understand first time you
> see
> >> >>> it. I like Configuration.newInstance() if that's really what it does
> >> >>> (ie no caching by classloader or anything else).
> >> >>>
> >> >>>
> >> >>> Romain Manni-Bucau
> >> >>> @rmannibucau
> >> >>> http://www.tomitribe.com
> >> >>> http://rmannibucau.wordpress.com
> >> >>> https://github.com/rmannibucau
> >> >>>
> >> >>>
> >> >>> 2014-12-01 17:42 GMT+01:00 Anatole Tresch <at...@gmail.com>:
> >> >>>
> >> >>>> There is a naming concept from Stephen Colebourne when to use of,
> >> from,
> >> >>>> with. I try to lookup the link later, see also jsr 310 and 354.
> >> >>>> getInstance, valueOf are considered to be outdated for modern api
> >> design.
> >> >>>>
> >> >>>> Adding a helper, why? Another artifact a user must know, makes
> sense,
> >> >>>> where
> >> >>>> you have a huge acces api IMO (see PropertyProviders where the
> factory
> >> >>>> methods are not part of the PropertyProvider interface. For
> >> >>>> Configuration I
> >> >>>> prefer having sn intuitive simple/single access...
> >> >>>>
> >> >>>> Nevertheless I would like to encourage you to make a concrete
> proposal
> >> >>>> how
> >> >>>> would name things, so we can compare what your idea of fluent is ;)
> >> >>>>
> >> >>>> -anatole
> >> >>>> Gerhard Petracek <ge...@gmail.com> schrieb am Mo., 1.
> Dez.
> >> >>>> 2014
> >> >>>> um 17:24:
> >> >>>>
> >> >>>> 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
> >> >>>>> <anatole.tresch@credit-suisse.
> >> >>>>> com
> >> >>>>>
> >> >>>>>> :
> >> >>>>>> 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:gerhard.petracek@gmail.com]
> >> >>>>>> Sent: Montag, 1. Dezember 2014 14:30
> >> >>>>>> To: dev@tamaya.incubator.apache.org
> >> >>>>>> 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 <an...@apache.org>:
> >> >>>>>>
> >> >>>>>> 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 <ge...@gmail.com> 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 <
> >> rmannibucau@gmail.com
> >> >>>>>>>>
> >> >>>>>>> :
> >> >>>>>>
> >> >>>>>>> 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 <anatole@apache.org
> >:
> >> >>>>>>>>>
> >> >>>>>>>>>> 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
> >> >>>>>>>>>>
> >> >>>>>>>>>>
> >> >> --
> >> >> N Oliver B. Fischer
> >> >> A Schönhauser Allee 64, 10437 Berlin, Deutschland/Germany
> >> >> P +49 30 44793251
> >> >> M +49 178 7903538
> >> >> E o.b.fischer@swe-blog.net
> >> >> S oliver.b.fischer
> >> >> J oliver.b.fischer@jabber.org
> >> >> X http://xing.to/obf
> >> >>
> >> >>
> >>
>
Re: Use Case 1: Read simple properties and get values.
Posted by Romain Manni-Bucau <rm...@gmail.com>.
if you have tamaya in server/lib and call it from webapps for
instance, each webapp can use different providers so you need
different instances. That is no more a singleton. If it is still one
cause we consider it as a factory/builder then the "instance" is
useless no?
Romain Manni-Bucau
@rmannibucau
http://www.tomitribe.com
http://rmannibucau.wordpress.com
https://github.com/rmannibucau
2014-12-01 19:20 GMT+01:00 Werner Keil <we...@gmail.com>:
> If you get one by app, is there any form of "context" you'd pass to such
> factory method?
>
> Currency.getInstance() returns exactly one singleton instance of a Currency
> class (otherwise has no constructor either) for a given currency code.
> While Money.of() in JSR 354 RI returns totally different instances
> depending on the combination of (nearly unlimited) different numbers and
> currency codes. 354 tries to broaden the definition of Currency, but if you
> get exactly one distinct instance per VM/app that's a singleton IMHO even
> if you may call the same application multiple times.
>
> On Mon, Dec 1, 2014 at 7:12 PM, Romain Manni-Bucau <rm...@gmail.com>
> wrote:
>
>> Hmm,
>>
>> for me getInstance() = singleton in term of instance where
>> Configuration will be all but a singleton IMO (you'll get at least one
>> by app and surely a new instance each time you call it) no?
>>
>>
>> Romain Manni-Bucau
>> @rmannibucau
>> http://www.tomitribe.com
>> http://rmannibucau.wordpress.com
>> https://github.com/rmannibucau
>>
>>
>> 2014-12-01 18:56 GMT+01:00 Werner Keil <we...@gmail.com>:
>> > Hi,
>> >
>> > Adding to the question of convenience factories, there is no such thing
>> as
>> > "naming convention" by Stephen Colebourne or JSR 310. In fact, it
>> violates
>> > or bends almost every one of them in itself, so a suggestion like
>> > Configuration.current() would sound very similar to the
>> LocalDateTime.now()
>> > ones in 310.
>> > For several other cases of() or longer variations (like ofMilli()
>> ofNanos()
>> > etc.;-O) are used, while static factories from strings similar to what
>> JSR
>> > 354 adopted are called parse(String).
>> >
>> > Josh Bloch defined a clear distinction between what he then in most cases
>> > (except EnumSet, that's where he started using of() so Josh also
>> "invented"
>> > that while it violated some of his earlier naming conventions;-D) called
>> > valueOf() and getInstance(), see
>> >
>> http://blog.codefront.net/2003/06/21/java-tip-2-static-factory-methods-vs-constructors/
>> > getInstance() returns a singleton, either the only instance for this type
>> > of object or the only instance for a distinct code or enum (see
>> > java.util.Currency)
>> >
>> > Very recent APIs and JSRs like MEEP 8 make a clear distinction, and
>> classes
>> > like
>> >
>> https://docs.oracle.com/javame/8.0/api/meep/api/javax/microedition/event/EventManager.html
>> > clearly explain that, too. In other places ME 8 uses of() where
>> appropriate.
>> > So at least getInstance() is neither outdated nor wrong, it just depends
>> on
>> > what you return.
>> >
>> > If Configuration returns just a default instance then
>> > Configuration.getInstance() seems appropriate.
>> >
>> >
>> > Werner Keil | JCP Executive Committee Member, JSR 363 Co Spec Lead |
>> > Eclipse UOMo Lead, Babel Language Champion | Apache Committer
>> >
>> > Twitter @wernerkeil | @UnitAPI | @JSR354 | @DeviceMap | #EclipseUOMo |
>> > #Java_Social
>> > | #DevOps
>> > Skype werner.keil | Google+ gplus.to/wernerkeil
>> >
>> > On Mon, Dec 1, 2014 at 6:31 PM, Oliver B. Fischer <
>> o.b.fischer@swe-blog.net>
>> > wrote:
>> >
>> >> Hi,
>> >>
>> >> for me the most simple use case is
>> >>
>> >> Configuration conf = new Configuration();
>> >> String value = conf.get("key")
>> >>
>> >> And this use case is already very complex under the hood.
>> >>
>> >> Before discussing other details we have to decide how PropertyProviders
>> >> are activated.
>> >>
>> >> I would like to have the following possibilites:
>> >>
>> >> 1. Tamaya activates all PropertyProviders found in the classpath and
>> >> activated via SPI.
>> >> 2. Tamaya activates only a explicitly named list of Property providers
>> >> 3. I have the ability to control the order in which the property
>> solution
>> >> will be performed
>> >>
>> >> Bye,
>> >>
>> >> Oliver
>> >>
>> >>
>> >> Am 01.12.14 17:54, schrieb Romain Manni-Bucau:
>> >>
>> >>> Configuration.current() sounds easier to understand first time you see
>> >>> it. I like Configuration.newInstance() if that's really what it does
>> >>> (ie no caching by classloader or anything else).
>> >>>
>> >>>
>> >>> Romain Manni-Bucau
>> >>> @rmannibucau
>> >>> http://www.tomitribe.com
>> >>> http://rmannibucau.wordpress.com
>> >>> https://github.com/rmannibucau
>> >>>
>> >>>
>> >>> 2014-12-01 17:42 GMT+01:00 Anatole Tresch <at...@gmail.com>:
>> >>>
>> >>>> There is a naming concept from Stephen Colebourne when to use of,
>> from,
>> >>>> with. I try to lookup the link later, see also jsr 310 and 354.
>> >>>> getInstance, valueOf are considered to be outdated for modern api
>> design.
>> >>>>
>> >>>> Adding a helper, why? Another artifact a user must know, makes sense,
>> >>>> where
>> >>>> you have a huge acces api IMO (see PropertyProviders where the factory
>> >>>> methods are not part of the PropertyProvider interface. For
>> >>>> Configuration I
>> >>>> prefer having sn intuitive simple/single access...
>> >>>>
>> >>>> Nevertheless I would like to encourage you to make a concrete proposal
>> >>>> how
>> >>>> would name things, so we can compare what your idea of fluent is ;)
>> >>>>
>> >>>> -anatole
>> >>>> Gerhard Petracek <ge...@gmail.com> schrieb am Mo., 1. Dez.
>> >>>> 2014
>> >>>> um 17:24:
>> >>>>
>> >>>> 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
>> >>>>> <anatole.tresch@credit-suisse.
>> >>>>> com
>> >>>>>
>> >>>>>> :
>> >>>>>> 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:gerhard.petracek@gmail.com]
>> >>>>>> Sent: Montag, 1. Dezember 2014 14:30
>> >>>>>> To: dev@tamaya.incubator.apache.org
>> >>>>>> 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 <an...@apache.org>:
>> >>>>>>
>> >>>>>> 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 <ge...@gmail.com> 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 <
>> rmannibucau@gmail.com
>> >>>>>>>>
>> >>>>>>> :
>> >>>>>>
>> >>>>>>> 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 <an...@apache.org>:
>> >>>>>>>>>
>> >>>>>>>>>> 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
>> >>>>>>>>>>
>> >>>>>>>>>>
>> >> --
>> >> N Oliver B. Fischer
>> >> A Schönhauser Allee 64, 10437 Berlin, Deutschland/Germany
>> >> P +49 30 44793251
>> >> M +49 178 7903538
>> >> E o.b.fischer@swe-blog.net
>> >> S oliver.b.fischer
>> >> J oliver.b.fischer@jabber.org
>> >> X http://xing.to/obf
>> >>
>> >>
>>
Re: Use Case 1: Read simple properties and get values.
Posted by Werner Keil <we...@gmail.com>.
If you get one by app, is there any form of "context" you'd pass to such
factory method?
Currency.getInstance() returns exactly one singleton instance of a Currency
class (otherwise has no constructor either) for a given currency code.
While Money.of() in JSR 354 RI returns totally different instances
depending on the combination of (nearly unlimited) different numbers and
currency codes. 354 tries to broaden the definition of Currency, but if you
get exactly one distinct instance per VM/app that's a singleton IMHO even
if you may call the same application multiple times.
On Mon, Dec 1, 2014 at 7:12 PM, Romain Manni-Bucau <rm...@gmail.com>
wrote:
> Hmm,
>
> for me getInstance() = singleton in term of instance where
> Configuration will be all but a singleton IMO (you'll get at least one
> by app and surely a new instance each time you call it) no?
>
>
> Romain Manni-Bucau
> @rmannibucau
> http://www.tomitribe.com
> http://rmannibucau.wordpress.com
> https://github.com/rmannibucau
>
>
> 2014-12-01 18:56 GMT+01:00 Werner Keil <we...@gmail.com>:
> > Hi,
> >
> > Adding to the question of convenience factories, there is no such thing
> as
> > "naming convention" by Stephen Colebourne or JSR 310. In fact, it
> violates
> > or bends almost every one of them in itself, so a suggestion like
> > Configuration.current() would sound very similar to the
> LocalDateTime.now()
> > ones in 310.
> > For several other cases of() or longer variations (like ofMilli()
> ofNanos()
> > etc.;-O) are used, while static factories from strings similar to what
> JSR
> > 354 adopted are called parse(String).
> >
> > Josh Bloch defined a clear distinction between what he then in most cases
> > (except EnumSet, that's where he started using of() so Josh also
> "invented"
> > that while it violated some of his earlier naming conventions;-D) called
> > valueOf() and getInstance(), see
> >
> http://blog.codefront.net/2003/06/21/java-tip-2-static-factory-methods-vs-constructors/
> > getInstance() returns a singleton, either the only instance for this type
> > of object or the only instance for a distinct code or enum (see
> > java.util.Currency)
> >
> > Very recent APIs and JSRs like MEEP 8 make a clear distinction, and
> classes
> > like
> >
> https://docs.oracle.com/javame/8.0/api/meep/api/javax/microedition/event/EventManager.html
> > clearly explain that, too. In other places ME 8 uses of() where
> appropriate.
> > So at least getInstance() is neither outdated nor wrong, it just depends
> on
> > what you return.
> >
> > If Configuration returns just a default instance then
> > Configuration.getInstance() seems appropriate.
> >
> >
> > Werner Keil | JCP Executive Committee Member, JSR 363 Co Spec Lead |
> > Eclipse UOMo Lead, Babel Language Champion | Apache Committer
> >
> > Twitter @wernerkeil | @UnitAPI | @JSR354 | @DeviceMap | #EclipseUOMo |
> > #Java_Social
> > | #DevOps
> > Skype werner.keil | Google+ gplus.to/wernerkeil
> >
> > On Mon, Dec 1, 2014 at 6:31 PM, Oliver B. Fischer <
> o.b.fischer@swe-blog.net>
> > wrote:
> >
> >> Hi,
> >>
> >> for me the most simple use case is
> >>
> >> Configuration conf = new Configuration();
> >> String value = conf.get("key")
> >>
> >> And this use case is already very complex under the hood.
> >>
> >> Before discussing other details we have to decide how PropertyProviders
> >> are activated.
> >>
> >> I would like to have the following possibilites:
> >>
> >> 1. Tamaya activates all PropertyProviders found in the classpath and
> >> activated via SPI.
> >> 2. Tamaya activates only a explicitly named list of Property providers
> >> 3. I have the ability to control the order in which the property
> solution
> >> will be performed
> >>
> >> Bye,
> >>
> >> Oliver
> >>
> >>
> >> Am 01.12.14 17:54, schrieb Romain Manni-Bucau:
> >>
> >>> Configuration.current() sounds easier to understand first time you see
> >>> it. I like Configuration.newInstance() if that's really what it does
> >>> (ie no caching by classloader or anything else).
> >>>
> >>>
> >>> Romain Manni-Bucau
> >>> @rmannibucau
> >>> http://www.tomitribe.com
> >>> http://rmannibucau.wordpress.com
> >>> https://github.com/rmannibucau
> >>>
> >>>
> >>> 2014-12-01 17:42 GMT+01:00 Anatole Tresch <at...@gmail.com>:
> >>>
> >>>> There is a naming concept from Stephen Colebourne when to use of,
> from,
> >>>> with. I try to lookup the link later, see also jsr 310 and 354.
> >>>> getInstance, valueOf are considered to be outdated for modern api
> design.
> >>>>
> >>>> Adding a helper, why? Another artifact a user must know, makes sense,
> >>>> where
> >>>> you have a huge acces api IMO (see PropertyProviders where the factory
> >>>> methods are not part of the PropertyProvider interface. For
> >>>> Configuration I
> >>>> prefer having sn intuitive simple/single access...
> >>>>
> >>>> Nevertheless I would like to encourage you to make a concrete proposal
> >>>> how
> >>>> would name things, so we can compare what your idea of fluent is ;)
> >>>>
> >>>> -anatole
> >>>> Gerhard Petracek <ge...@gmail.com> schrieb am Mo., 1. Dez.
> >>>> 2014
> >>>> um 17:24:
> >>>>
> >>>> 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
> >>>>> <anatole.tresch@credit-suisse.
> >>>>> com
> >>>>>
> >>>>>> :
> >>>>>> 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:gerhard.petracek@gmail.com]
> >>>>>> Sent: Montag, 1. Dezember 2014 14:30
> >>>>>> To: dev@tamaya.incubator.apache.org
> >>>>>> 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 <an...@apache.org>:
> >>>>>>
> >>>>>> 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 <ge...@gmail.com> 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 <
> rmannibucau@gmail.com
> >>>>>>>>
> >>>>>>> :
> >>>>>>
> >>>>>>> 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 <an...@apache.org>:
> >>>>>>>>>
> >>>>>>>>>> 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
> >>>>>>>>>>
> >>>>>>>>>>
> >> --
> >> N Oliver B. Fischer
> >> A Schönhauser Allee 64, 10437 Berlin, Deutschland/Germany
> >> P +49 30 44793251
> >> M +49 178 7903538
> >> E o.b.fischer@swe-blog.net
> >> S oliver.b.fischer
> >> J oliver.b.fischer@jabber.org
> >> X http://xing.to/obf
> >>
> >>
>
Re: Use Case 1: Read simple properties and get values.
Posted by Romain Manni-Bucau <rm...@gmail.com>.
Hmm,
for me getInstance() = singleton in term of instance where
Configuration will be all but a singleton IMO (you'll get at least one
by app and surely a new instance each time you call it) no?
Romain Manni-Bucau
@rmannibucau
http://www.tomitribe.com
http://rmannibucau.wordpress.com
https://github.com/rmannibucau
2014-12-01 18:56 GMT+01:00 Werner Keil <we...@gmail.com>:
> Hi,
>
> Adding to the question of convenience factories, there is no such thing as
> "naming convention" by Stephen Colebourne or JSR 310. In fact, it violates
> or bends almost every one of them in itself, so a suggestion like
> Configuration.current() would sound very similar to the LocalDateTime.now()
> ones in 310.
> For several other cases of() or longer variations (like ofMilli() ofNanos()
> etc.;-O) are used, while static factories from strings similar to what JSR
> 354 adopted are called parse(String).
>
> Josh Bloch defined a clear distinction between what he then in most cases
> (except EnumSet, that's where he started using of() so Josh also "invented"
> that while it violated some of his earlier naming conventions;-D) called
> valueOf() and getInstance(), see
> http://blog.codefront.net/2003/06/21/java-tip-2-static-factory-methods-vs-constructors/
> getInstance() returns a singleton, either the only instance for this type
> of object or the only instance for a distinct code or enum (see
> java.util.Currency)
>
> Very recent APIs and JSRs like MEEP 8 make a clear distinction, and classes
> like
> https://docs.oracle.com/javame/8.0/api/meep/api/javax/microedition/event/EventManager.html
> clearly explain that, too. In other places ME 8 uses of() where appropriate.
> So at least getInstance() is neither outdated nor wrong, it just depends on
> what you return.
>
> If Configuration returns just a default instance then
> Configuration.getInstance() seems appropriate.
>
>
> Werner Keil | JCP Executive Committee Member, JSR 363 Co Spec Lead |
> Eclipse UOMo Lead, Babel Language Champion | Apache Committer
>
> Twitter @wernerkeil | @UnitAPI | @JSR354 | @DeviceMap | #EclipseUOMo |
> #Java_Social
> | #DevOps
> Skype werner.keil | Google+ gplus.to/wernerkeil
>
> On Mon, Dec 1, 2014 at 6:31 PM, Oliver B. Fischer <o....@swe-blog.net>
> wrote:
>
>> Hi,
>>
>> for me the most simple use case is
>>
>> Configuration conf = new Configuration();
>> String value = conf.get("key")
>>
>> And this use case is already very complex under the hood.
>>
>> Before discussing other details we have to decide how PropertyProviders
>> are activated.
>>
>> I would like to have the following possibilites:
>>
>> 1. Tamaya activates all PropertyProviders found in the classpath and
>> activated via SPI.
>> 2. Tamaya activates only a explicitly named list of Property providers
>> 3. I have the ability to control the order in which the property solution
>> will be performed
>>
>> Bye,
>>
>> Oliver
>>
>>
>> Am 01.12.14 17:54, schrieb Romain Manni-Bucau:
>>
>>> Configuration.current() sounds easier to understand first time you see
>>> it. I like Configuration.newInstance() if that's really what it does
>>> (ie no caching by classloader or anything else).
>>>
>>>
>>> Romain Manni-Bucau
>>> @rmannibucau
>>> http://www.tomitribe.com
>>> http://rmannibucau.wordpress.com
>>> https://github.com/rmannibucau
>>>
>>>
>>> 2014-12-01 17:42 GMT+01:00 Anatole Tresch <at...@gmail.com>:
>>>
>>>> There is a naming concept from Stephen Colebourne when to use of, from,
>>>> with. I try to lookup the link later, see also jsr 310 and 354.
>>>> getInstance, valueOf are considered to be outdated for modern api design.
>>>>
>>>> Adding a helper, why? Another artifact a user must know, makes sense,
>>>> where
>>>> you have a huge acces api IMO (see PropertyProviders where the factory
>>>> methods are not part of the PropertyProvider interface. For
>>>> Configuration I
>>>> prefer having sn intuitive simple/single access...
>>>>
>>>> Nevertheless I would like to encourage you to make a concrete proposal
>>>> how
>>>> would name things, so we can compare what your idea of fluent is ;)
>>>>
>>>> -anatole
>>>> Gerhard Petracek <ge...@gmail.com> schrieb am Mo., 1. Dez.
>>>> 2014
>>>> um 17:24:
>>>>
>>>> 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
>>>>> <anatole.tresch@credit-suisse.
>>>>> com
>>>>>
>>>>>> :
>>>>>> 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:gerhard.petracek@gmail.com]
>>>>>> Sent: Montag, 1. Dezember 2014 14:30
>>>>>> To: dev@tamaya.incubator.apache.org
>>>>>> 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 <an...@apache.org>:
>>>>>>
>>>>>> 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 <ge...@gmail.com> 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 <rmannibucau@gmail.com
>>>>>>>>
>>>>>>> :
>>>>>>
>>>>>>> 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 <an...@apache.org>:
>>>>>>>>>
>>>>>>>>>> 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
>>>>>>>>>>
>>>>>>>>>>
>> --
>> N Oliver B. Fischer
>> A Schönhauser Allee 64, 10437 Berlin, Deutschland/Germany
>> P +49 30 44793251
>> M +49 178 7903538
>> E o.b.fischer@swe-blog.net
>> S oliver.b.fischer
>> J oliver.b.fischer@jabber.org
>> X http://xing.to/obf
>>
>>
Re: Use Case 1: Read simple properties and get values.
Posted by Werner Keil <we...@gmail.com>.
Hi,
Adding to the question of convenience factories, there is no such thing as
"naming convention" by Stephen Colebourne or JSR 310. In fact, it violates
or bends almost every one of them in itself, so a suggestion like
Configuration.current() would sound very similar to the LocalDateTime.now()
ones in 310.
For several other cases of() or longer variations (like ofMilli() ofNanos()
etc.;-O) are used, while static factories from strings similar to what JSR
354 adopted are called parse(String).
Josh Bloch defined a clear distinction between what he then in most cases
(except EnumSet, that's where he started using of() so Josh also "invented"
that while it violated some of his earlier naming conventions;-D) called
valueOf() and getInstance(), see
http://blog.codefront.net/2003/06/21/java-tip-2-static-factory-methods-vs-constructors/
getInstance() returns a singleton, either the only instance for this type
of object or the only instance for a distinct code or enum (see
java.util.Currency)
Very recent APIs and JSRs like MEEP 8 make a clear distinction, and classes
like
https://docs.oracle.com/javame/8.0/api/meep/api/javax/microedition/event/EventManager.html
clearly explain that, too. In other places ME 8 uses of() where appropriate.
So at least getInstance() is neither outdated nor wrong, it just depends on
what you return.
If Configuration returns just a default instance then
Configuration.getInstance() seems appropriate.
Werner Keil | JCP Executive Committee Member, JSR 363 Co Spec Lead |
Eclipse UOMo Lead, Babel Language Champion | Apache Committer
Twitter @wernerkeil | @UnitAPI | @JSR354 | @DeviceMap | #EclipseUOMo |
#Java_Social
| #DevOps
Skype werner.keil | Google+ gplus.to/wernerkeil
On Mon, Dec 1, 2014 at 6:31 PM, Oliver B. Fischer <o....@swe-blog.net>
wrote:
> Hi,
>
> for me the most simple use case is
>
> Configuration conf = new Configuration();
> String value = conf.get("key")
>
> And this use case is already very complex under the hood.
>
> Before discussing other details we have to decide how PropertyProviders
> are activated.
>
> I would like to have the following possibilites:
>
> 1. Tamaya activates all PropertyProviders found in the classpath and
> activated via SPI.
> 2. Tamaya activates only a explicitly named list of Property providers
> 3. I have the ability to control the order in which the property solution
> will be performed
>
> Bye,
>
> Oliver
>
>
> Am 01.12.14 17:54, schrieb Romain Manni-Bucau:
>
>> Configuration.current() sounds easier to understand first time you see
>> it. I like Configuration.newInstance() if that's really what it does
>> (ie no caching by classloader or anything else).
>>
>>
>> Romain Manni-Bucau
>> @rmannibucau
>> http://www.tomitribe.com
>> http://rmannibucau.wordpress.com
>> https://github.com/rmannibucau
>>
>>
>> 2014-12-01 17:42 GMT+01:00 Anatole Tresch <at...@gmail.com>:
>>
>>> There is a naming concept from Stephen Colebourne when to use of, from,
>>> with. I try to lookup the link later, see also jsr 310 and 354.
>>> getInstance, valueOf are considered to be outdated for modern api design.
>>>
>>> Adding a helper, why? Another artifact a user must know, makes sense,
>>> where
>>> you have a huge acces api IMO (see PropertyProviders where the factory
>>> methods are not part of the PropertyProvider interface. For
>>> Configuration I
>>> prefer having sn intuitive simple/single access...
>>>
>>> Nevertheless I would like to encourage you to make a concrete proposal
>>> how
>>> would name things, so we can compare what your idea of fluent is ;)
>>>
>>> -anatole
>>> Gerhard Petracek <ge...@gmail.com> schrieb am Mo., 1. Dez.
>>> 2014
>>> um 17:24:
>>>
>>> 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
>>>> <anatole.tresch@credit-suisse.
>>>> com
>>>>
>>>>> :
>>>>> 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:gerhard.petracek@gmail.com]
>>>>> Sent: Montag, 1. Dezember 2014 14:30
>>>>> To: dev@tamaya.incubator.apache.org
>>>>> 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 <an...@apache.org>:
>>>>>
>>>>> 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 <ge...@gmail.com> 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 <rmannibucau@gmail.com
>>>>>>>
>>>>>> :
>>>>>
>>>>>> 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 <an...@apache.org>:
>>>>>>>>
>>>>>>>>> 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
>>>>>>>>>
>>>>>>>>>
> --
> N Oliver B. Fischer
> A Schönhauser Allee 64, 10437 Berlin, Deutschland/Germany
> P +49 30 44793251
> M +49 178 7903538
> E o.b.fischer@swe-blog.net
> S oliver.b.fischer
> J oliver.b.fischer@jabber.org
> X http://xing.to/obf
>
>
Re: Use Case 1: Read simple properties and get values.
Posted by "Oliver B. Fischer" <o....@swe-blog.net>.
Hi Anatole,
you are right, we need to define what a PropertyProvider and a
Configuration is.
Am 01.12.14 19:37, schrieb Anatole Tresch:
> 2. Tamaya activates only a explicitly named list of Property providers
> See above. To static for complex and dynamic use cases...
I think it depends on the definitions. Even if it is to static for
complex and dynamic use cases we have also to support such simple use
cases. This use case is my personal requirement if I would have to
replace our current solution at work with Tamaya
> 3. I have the ability to control the order in which the property solution
> will be performed
> Yep, but there are simple and more complicated mechanisms and each company
> does it differently...
>
Right, and we should be able to handle both kinds of mechanisms. A good
framework gives me the freedom to build a solution fitting my requirements.
Bye,
Oliver
--
N Oliver B. Fischer
A Schönhauser Allee 64, 10437 Berlin, Deutschland/Germany
P +49 30 44793251
M +49 178 7903538
E o.b.fischer@swe-blog.net
S oliver.b.fischer
J oliver.b.fischer@jabber.org
X http://xing.to/obf
Re: Use Case 1: Read simple properties and get values.
Posted by Anatole Tresch <at...@gmail.com>.
Hi Oliver
before we do not even know what a PropertyProvider and a Configuration is,
and how it is accessed, I think it is a bit early. Activation or said the
mechanism how you get
to a certain configuration is a very complex issue, your proposal may work
for simpler cases, but definitively not in more complex ones. In more
details some feedback to your points:
1. Tamaya activates all PropertyProviders found in the classpath and
activated via SPI.
-> Depending if you are running in SE, OSGI or Java EE this may work rather
different. How about providers that are loading entries from different
classloaders, how about overriding, or partial overriding, securing and
protecting of entries? SaaS environments, multi-tenancy...? Believe there
is incredible complexity in this area, we will definitively to cover. I
assume these aspects are the
key differentiators from Tamaya to all the other configuration solutions
out there...
2. Tamaya activates only a explicitly named list of Property providers
See above. To static for complex and dynamic use cases...
3. I have the ability to control the order in which the property solution
will be performed
Yep, but there are simple and more complicated mechanisms and each company
does it differently...
-Anatole
2014-12-01 18:31 GMT+01:00 Oliver B. Fischer <o....@swe-blog.net>:
> Hi,
>
> for me the most simple use case is
>
> Configuration conf = new Configuration();
> String value = conf.get("key")
>
> And this use case is already very complex under the hood.
>
> Before discussing other details we have to decide how PropertyProviders
> are activated.
>
> I would like to have the following possibilites:
>
>
> 1. Tamaya activates all PropertyProviders found in the classpath and
> activated via SPI.
> 2. Tamaya activates only a explicitly named list of Property providers
> 3. I have the ability to control the order in which the property solution
> will be performed
>
> Bye,
>
> Oliver
>
>
> Am 01.12.14 17:54, schrieb Romain Manni-Bucau:
>
> Configuration.current() sounds easier to understand first time you see
>> it. I like Configuration.newInstance() if that's really what it does
>> (ie no caching by classloader or anything else).
>>
>>
>> Romain Manni-Bucau
>> @rmannibucau
>> http://www.tomitribe.com
>> http://rmannibucau.wordpress.com
>> https://github.com/rmannibucau
>>
>>
>> 2014-12-01 17:42 GMT+01:00 Anatole Tresch <at...@gmail.com>:
>>
>>> There is a naming concept from Stephen Colebourne when to use of, from,
>>> with. I try to lookup the link later, see also jsr 310 and 354.
>>> getInstance, valueOf are considered to be outdated for modern api design.
>>>
>>> Adding a helper, why? Another artifact a user must know, makes sense,
>>> where
>>> you have a huge acces api IMO (see PropertyProviders where the factory
>>> methods are not part of the PropertyProvider interface. For
>>> Configuration I
>>> prefer having sn intuitive simple/single access...
>>>
>>> Nevertheless I would like to encourage you to make a concrete proposal
>>> how
>>> would name things, so we can compare what your idea of fluent is ;)
>>>
>>> -anatole
>>> Gerhard Petracek <ge...@gmail.com> schrieb am Mo., 1. Dez.
>>> 2014
>>> um 17:24:
>>>
>>> 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
>>>> <anatole.tresch@credit-suisse.
>>>> com
>>>>
>>>>> :
>>>>> 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:gerhard.petracek@gmail.com]
>>>>> Sent: Montag, 1. Dezember 2014 14:30
>>>>> To: dev@tamaya.incubator.apache.org
>>>>> 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 <an...@apache.org>:
>>>>>
>>>>> 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 <ge...@gmail.com> 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 <rmannibucau@gmail.com
>>>>>>>
>>>>>> :
>>>>>
>>>>>> 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 <an...@apache.org>:
>>>>>>>>
>>>>>>>>> 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
>>>>>>>>>
>>>>>>>>>
> --
> N Oliver B. Fischer
> A Schönhauser Allee 64, 10437 Berlin, Deutschland/Germany
> P +49 30 44793251
> M +49 178 7903538
> E o.b.fischer@swe-blog.net
> S oliver.b.fischer
> J oliver.b.fischer@jabber.org
> X http://xing.to/obf
>
>
--
*Anatole Tresch*
Java Engineer & Architect, JSR Spec Lead
Glärnischweg 10
CH - 8620 Wetzikon
*Switzerland, Europe Zurich, GMT+1*
*Twitter: @atsticks*
*Blogs: **http://javaremarkables.blogspot.ch/
<http://javaremarkables.blogspot.ch/>*
*Google: atsticksMobile +41-76 344 62 79*
Re: Use Case 1: Read simple properties and get values.
Posted by Anatole Tresch <at...@gmail.com>.
See inline...
2014-12-01 19:22 GMT+01:00 Romain Manni-Bucau <rm...@gmail.com>:
> JCache use ServiceLoader to get a Provider then you get a Manager and
> finally a Cache. It is mainly to ensure you can "bulk" close what you
> created I think. I'm not convinced we need it - maybe 1 level but no
> more since we'll just kill "watcher" threads at the end of the
> Configuration usage (AutoCloseable?).
>
If I got you right this is similar, what we have as of now:
1) Singleton Accessor
2) Singleton is backed up by a SPI loaded from the Bootstrap
3) Bootstrap loading mechanism is configured by a ServiceLoader config, if
no config is there it uses the ServiceLoader by default.
Has proven to be easy and flexible but not too much levels (similar to
Bean validation...).
> About key conflict I saw isSameKey() or something like that in the API
> but I really guess all this logic should be extracted in its own
> interface (why I though starting with default methods were not a good
> idea), maybe MergePolicy (with a good default doing nothing or
> failing, not yet sure ;)).
>
Good point, I agree. There is a comparison on the PropertyProvider for
comparing 2 providers, if I recall it correctly...
>
>
>
>
> Romain Manni-Bucau
> @rmannibucau
> http://www.tomitribe.com
> http://rmannibucau.wordpress.com
> https://github.com/rmannibucau
>
>
> 2014-12-01 19:15 GMT+01:00 Werner Keil <we...@gmail.com>:
> > Haven't looked into it in so much detail, but what I saw from the JCache
> > JSR it also defines just a single service interface in SPI which then
> gets
> > applied via the usual Java Service Provider mechanism.
> >
> > JSR 363 leaves it a bit more flexible (as ME 8 knows a slight variation
> of
> > that via LIBlets and some implementations may prefer OSGi over JDK
> Service
> > Loaders;-) but in essence the SPI package defines some similar
> interfaces.
> >
> > Werner
> >
> > On Mon, Dec 1, 2014 at 7:09 PM, Oliver B. Fischer <
> o.b.fischer@swe-blog.net>
> > wrote:
> >
> >> I like the idea of builders.
> >>
> >> If we have default providers via SPI how do we handle the a case there
> two
> >> providers offer a value for the same key?
> >>
> >> Furthermore I would like to have the posibillty to decide which
> providers
> >> are automatically choosen by providing a -Dproviders=org.apache.tamaya.
> >> ProviderA,org.apache.tamaya.ProviderB
> >>
> >> Oliver
> >>
> >> Am 01.12.14 18:53, schrieb Romain Manni-Bucau:
> >>
> >> Markdown4j has something pretty nice (specific but I guess the idea is
> >>> reusable for us):
> >>>
> >>> Configuration.builder().forceExtentedProfile().registerPlugins(new
> >>> YumlPlugin(), new WebSequencePlugin(), new
> >>> IncludePlugin()).convertNewline2Br().setDecorator(decorator).
> >>> setCodeBlockEmitter(new
> >>> CodeBlockEmitter()).build().
> >>>
> >>> What I like:
> >>> 1) builder (so can be read-only once built + API is auto-documented
> >>> and here it is fluent)
> >>> 2) manual registration of plugins (loaders for us)
> >>>
> >>> So we could get:
> >>>
> >>> Configuration c = new Configuration.Builder().propertyProviders(new
> >>> MyProviders1(), new MyProviders2()).build()
> >>>
> >>> Not that we can easily write a PropertyProviders using a SPI and I
> >>> would wire it as a default one if propertyProviders is not called (ie
> >>> set of providers is empty.
> >>>
> >>> This would also allow us to add other features later like property
> >>> post processors (to change properties loaded from providers etc...)
> >>> pretty easily and clean-ly.
> >>>
> >>> wdyt?
> >>>
> >>>
> >>>
> >>> Romain Manni-Bucau
> >>> @rmannibucau
> >>> http://www.tomitribe.com
> >>> http://rmannibucau.wordpress.com
> >>> https://github.com/rmannibucau
> >>>
> >>>
> >>> 2014-12-01 18:31 GMT+01:00 Oliver B. Fischer <o.b.fischer@swe-blog.net
> >:
> >>>
> >>>> Hi,
> >>>>
> >>>> for me the most simple use case is
> >>>>
> >>>> Configuration conf = new Configuration();
> >>>> String value = conf.get("key")
> >>>>
> >>>> And this use case is already very complex under the hood.
> >>>>
> >>>> Before discussing other details we have to decide how
> PropertyProviders
> >>>> are
> >>>> activated.
> >>>>
> >>>> I would like to have the following possibilites:
> >>>>
> >>>> 1. Tamaya activates all PropertyProviders found in the classpath and
> >>>> activated via SPI.
> >>>> 2. Tamaya activates only a explicitly named list of Property providers
> >>>> 3. I have the ability to control the order in which the property
> solution
> >>>> will be performed
> >>>>
> >>>> Bye,
> >>>>
> >>>> Oliver
> >>>>
> >>>>
> >>>> Am 01.12.14 17:54, schrieb Romain Manni-Bucau:
> >>>>
> >>>> Configuration.current() sounds easier to understand first time you
> see
> >>>>> it. I like Configuration.newInstance() if that's really what it does
> >>>>> (ie no caching by classloader or anything else).
> >>>>>
> >>>>>
> >>>>> Romain Manni-Bucau
> >>>>> @rmannibucau
> >>>>> http://www.tomitribe.com
> >>>>> http://rmannibucau.wordpress.com
> >>>>> https://github.com/rmannibucau
> >>>>>
> >>>>>
> >>>>> 2014-12-01 17:42 GMT+01:00 Anatole Tresch <at...@gmail.com>:
> >>>>>
> >>>>>> There is a naming concept from Stephen Colebourne when to use of,
> from,
> >>>>>> with. I try to lookup the link later, see also jsr 310 and 354.
> >>>>>> getInstance, valueOf are considered to be outdated for modern api
> >>>>>> design.
> >>>>>>
> >>>>>> Adding a helper, why? Another artifact a user must know, makes
> sense,
> >>>>>> where
> >>>>>> you have a huge acces api IMO (see PropertyProviders where the
> factory
> >>>>>> methods are not part of the PropertyProvider interface. For
> >>>>>> Configuration
> >>>>>> I
> >>>>>> prefer having sn intuitive simple/single access...
> >>>>>>
> >>>>>> Nevertheless I would like to encourage you to make a concrete
> proposal
> >>>>>> how
> >>>>>> would name things, so we can compare what your idea of fluent is ;)
> >>>>>>
> >>>>>> -anatole
> >>>>>> Gerhard Petracek <ge...@gmail.com> schrieb am Mo., 1.
> Dez.
> >>>>>> 2014
> >>>>>> um 17:24:
> >>>>>>
> >>>>>> 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
> >>>>>>> <anatole.tresch@credit-suisse.
> >>>>>>> com
> >>>>>>>
> >>>>>>>> :
> >>>>>>>> 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:gerhard.petracek@gmail.com]
> >>>>>>>> Sent: Montag, 1. Dezember 2014 14:30
> >>>>>>>> To: dev@tamaya.incubator.apache.org
> >>>>>>>> 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 <an...@apache.org>:
> >>>>>>>>
> >>>>>>>> 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 <ge...@gmail.com> 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 <
> >>>>>>>>>> rmannibucau@gmail.com
> >>>>>>>>>>
> >>>>>>>>> :
> >>>>>>>>
> >>>>>>>>> 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 <anatole@apache.org
> >:
> >>>>>>>>>>>
> >>>>>>>>>>>> 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
> >>>>>>>>>>>>
> >>>>>>>>>>>> --
> >>>> N Oliver B. Fischer
> >>>> A Schönhauser Allee 64, 10437 Berlin, Deutschland/Germany
> >>>> P +49 30 44793251
> >>>> M +49 178 7903538
> >>>> E o.b.fischer@swe-blog.net
> >>>> S oliver.b.fischer
> >>>> J oliver.b.fischer@jabber.org
> >>>> X http://xing.to/obf
> >>>>
> >>>>
> >> --
> >> N Oliver B. Fischer
> >> A Schönhauser Allee 64, 10437 Berlin, Deutschland/Germany
> >> P +49 30 44793251
> >> M +49 178 7903538
> >> E o.b.fischer@swe-blog.net
> >> S oliver.b.fischer
> >> J oliver.b.fischer@jabber.org
> >> X http://xing.to/obf
> >>
> >>
>
--
*Anatole Tresch*
Java Engineer & Architect, JSR Spec Lead
Glärnischweg 10
CH - 8620 Wetzikon
*Switzerland, Europe Zurich, GMT+1*
*Twitter: @atsticks*
*Blogs: **http://javaremarkables.blogspot.ch/
<http://javaremarkables.blogspot.ch/>*
*Google: atsticksMobile +41-76 344 62 79*
Re: Use Case 1: Read simple properties and get values.
Posted by Romain Manni-Bucau <rm...@gmail.com>.
JCache use ServiceLoader to get a Provider then you get a Manager and
finally a Cache. It is mainly to ensure you can "bulk" close what you
created I think. I'm not convinced we need it - maybe 1 level but no
more since we'll just kill "watcher" threads at the end of the
Configuration usage (AutoCloseable?).
About key conflict I saw isSameKey() or something like that in the API
but I really guess all this logic should be extracted in its own
interface (why I though starting with default methods were not a good
idea), maybe MergePolicy (with a good default doing nothing or
failing, not yet sure ;)).
Romain Manni-Bucau
@rmannibucau
http://www.tomitribe.com
http://rmannibucau.wordpress.com
https://github.com/rmannibucau
2014-12-01 19:15 GMT+01:00 Werner Keil <we...@gmail.com>:
> Haven't looked into it in so much detail, but what I saw from the JCache
> JSR it also defines just a single service interface in SPI which then gets
> applied via the usual Java Service Provider mechanism.
>
> JSR 363 leaves it a bit more flexible (as ME 8 knows a slight variation of
> that via LIBlets and some implementations may prefer OSGi over JDK Service
> Loaders;-) but in essence the SPI package defines some similar interfaces.
>
> Werner
>
> On Mon, Dec 1, 2014 at 7:09 PM, Oliver B. Fischer <o....@swe-blog.net>
> wrote:
>
>> I like the idea of builders.
>>
>> If we have default providers via SPI how do we handle the a case there two
>> providers offer a value for the same key?
>>
>> Furthermore I would like to have the posibillty to decide which providers
>> are automatically choosen by providing a -Dproviders=org.apache.tamaya.
>> ProviderA,org.apache.tamaya.ProviderB
>>
>> Oliver
>>
>> Am 01.12.14 18:53, schrieb Romain Manni-Bucau:
>>
>> Markdown4j has something pretty nice (specific but I guess the idea is
>>> reusable for us):
>>>
>>> Configuration.builder().forceExtentedProfile().registerPlugins(new
>>> YumlPlugin(), new WebSequencePlugin(), new
>>> IncludePlugin()).convertNewline2Br().setDecorator(decorator).
>>> setCodeBlockEmitter(new
>>> CodeBlockEmitter()).build().
>>>
>>> What I like:
>>> 1) builder (so can be read-only once built + API is auto-documented
>>> and here it is fluent)
>>> 2) manual registration of plugins (loaders for us)
>>>
>>> So we could get:
>>>
>>> Configuration c = new Configuration.Builder().propertyProviders(new
>>> MyProviders1(), new MyProviders2()).build()
>>>
>>> Not that we can easily write a PropertyProviders using a SPI and I
>>> would wire it as a default one if propertyProviders is not called (ie
>>> set of providers is empty.
>>>
>>> This would also allow us to add other features later like property
>>> post processors (to change properties loaded from providers etc...)
>>> pretty easily and clean-ly.
>>>
>>> wdyt?
>>>
>>>
>>>
>>> Romain Manni-Bucau
>>> @rmannibucau
>>> http://www.tomitribe.com
>>> http://rmannibucau.wordpress.com
>>> https://github.com/rmannibucau
>>>
>>>
>>> 2014-12-01 18:31 GMT+01:00 Oliver B. Fischer <o....@swe-blog.net>:
>>>
>>>> Hi,
>>>>
>>>> for me the most simple use case is
>>>>
>>>> Configuration conf = new Configuration();
>>>> String value = conf.get("key")
>>>>
>>>> And this use case is already very complex under the hood.
>>>>
>>>> Before discussing other details we have to decide how PropertyProviders
>>>> are
>>>> activated.
>>>>
>>>> I would like to have the following possibilites:
>>>>
>>>> 1. Tamaya activates all PropertyProviders found in the classpath and
>>>> activated via SPI.
>>>> 2. Tamaya activates only a explicitly named list of Property providers
>>>> 3. I have the ability to control the order in which the property solution
>>>> will be performed
>>>>
>>>> Bye,
>>>>
>>>> Oliver
>>>>
>>>>
>>>> Am 01.12.14 17:54, schrieb Romain Manni-Bucau:
>>>>
>>>> Configuration.current() sounds easier to understand first time you see
>>>>> it. I like Configuration.newInstance() if that's really what it does
>>>>> (ie no caching by classloader or anything else).
>>>>>
>>>>>
>>>>> Romain Manni-Bucau
>>>>> @rmannibucau
>>>>> http://www.tomitribe.com
>>>>> http://rmannibucau.wordpress.com
>>>>> https://github.com/rmannibucau
>>>>>
>>>>>
>>>>> 2014-12-01 17:42 GMT+01:00 Anatole Tresch <at...@gmail.com>:
>>>>>
>>>>>> There is a naming concept from Stephen Colebourne when to use of, from,
>>>>>> with. I try to lookup the link later, see also jsr 310 and 354.
>>>>>> getInstance, valueOf are considered to be outdated for modern api
>>>>>> design.
>>>>>>
>>>>>> Adding a helper, why? Another artifact a user must know, makes sense,
>>>>>> where
>>>>>> you have a huge acces api IMO (see PropertyProviders where the factory
>>>>>> methods are not part of the PropertyProvider interface. For
>>>>>> Configuration
>>>>>> I
>>>>>> prefer having sn intuitive simple/single access...
>>>>>>
>>>>>> Nevertheless I would like to encourage you to make a concrete proposal
>>>>>> how
>>>>>> would name things, so we can compare what your idea of fluent is ;)
>>>>>>
>>>>>> -anatole
>>>>>> Gerhard Petracek <ge...@gmail.com> schrieb am Mo., 1. Dez.
>>>>>> 2014
>>>>>> um 17:24:
>>>>>>
>>>>>> 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
>>>>>>> <anatole.tresch@credit-suisse.
>>>>>>> com
>>>>>>>
>>>>>>>> :
>>>>>>>> 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:gerhard.petracek@gmail.com]
>>>>>>>> Sent: Montag, 1. Dezember 2014 14:30
>>>>>>>> To: dev@tamaya.incubator.apache.org
>>>>>>>> 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 <an...@apache.org>:
>>>>>>>>
>>>>>>>> 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 <ge...@gmail.com> 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 <
>>>>>>>>>> rmannibucau@gmail.com
>>>>>>>>>>
>>>>>>>>> :
>>>>>>>>
>>>>>>>>> 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 <an...@apache.org>:
>>>>>>>>>>>
>>>>>>>>>>>> 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
>>>>>>>>>>>>
>>>>>>>>>>>> --
>>>> N Oliver B. Fischer
>>>> A Schönhauser Allee 64, 10437 Berlin, Deutschland/Germany
>>>> P +49 30 44793251
>>>> M +49 178 7903538
>>>> E o.b.fischer@swe-blog.net
>>>> S oliver.b.fischer
>>>> J oliver.b.fischer@jabber.org
>>>> X http://xing.to/obf
>>>>
>>>>
>> --
>> N Oliver B. Fischer
>> A Schönhauser Allee 64, 10437 Berlin, Deutschland/Germany
>> P +49 30 44793251
>> M +49 178 7903538
>> E o.b.fischer@swe-blog.net
>> S oliver.b.fischer
>> J oliver.b.fischer@jabber.org
>> X http://xing.to/obf
>>
>>
Re: Use Case 1: Read simple properties and get values.
Posted by Werner Keil <we...@gmail.com>.
Haven't looked into it in so much detail, but what I saw from the JCache
JSR it also defines just a single service interface in SPI which then gets
applied via the usual Java Service Provider mechanism.
JSR 363 leaves it a bit more flexible (as ME 8 knows a slight variation of
that via LIBlets and some implementations may prefer OSGi over JDK Service
Loaders;-) but in essence the SPI package defines some similar interfaces.
Werner
On Mon, Dec 1, 2014 at 7:09 PM, Oliver B. Fischer <o....@swe-blog.net>
wrote:
> I like the idea of builders.
>
> If we have default providers via SPI how do we handle the a case there two
> providers offer a value for the same key?
>
> Furthermore I would like to have the posibillty to decide which providers
> are automatically choosen by providing a -Dproviders=org.apache.tamaya.
> ProviderA,org.apache.tamaya.ProviderB
>
> Oliver
>
> Am 01.12.14 18:53, schrieb Romain Manni-Bucau:
>
> Markdown4j has something pretty nice (specific but I guess the idea is
>> reusable for us):
>>
>> Configuration.builder().forceExtentedProfile().registerPlugins(new
>> YumlPlugin(), new WebSequencePlugin(), new
>> IncludePlugin()).convertNewline2Br().setDecorator(decorator).
>> setCodeBlockEmitter(new
>> CodeBlockEmitter()).build().
>>
>> What I like:
>> 1) builder (so can be read-only once built + API is auto-documented
>> and here it is fluent)
>> 2) manual registration of plugins (loaders for us)
>>
>> So we could get:
>>
>> Configuration c = new Configuration.Builder().propertyProviders(new
>> MyProviders1(), new MyProviders2()).build()
>>
>> Not that we can easily write a PropertyProviders using a SPI and I
>> would wire it as a default one if propertyProviders is not called (ie
>> set of providers is empty.
>>
>> This would also allow us to add other features later like property
>> post processors (to change properties loaded from providers etc...)
>> pretty easily and clean-ly.
>>
>> wdyt?
>>
>>
>>
>> Romain Manni-Bucau
>> @rmannibucau
>> http://www.tomitribe.com
>> http://rmannibucau.wordpress.com
>> https://github.com/rmannibucau
>>
>>
>> 2014-12-01 18:31 GMT+01:00 Oliver B. Fischer <o....@swe-blog.net>:
>>
>>> Hi,
>>>
>>> for me the most simple use case is
>>>
>>> Configuration conf = new Configuration();
>>> String value = conf.get("key")
>>>
>>> And this use case is already very complex under the hood.
>>>
>>> Before discussing other details we have to decide how PropertyProviders
>>> are
>>> activated.
>>>
>>> I would like to have the following possibilites:
>>>
>>> 1. Tamaya activates all PropertyProviders found in the classpath and
>>> activated via SPI.
>>> 2. Tamaya activates only a explicitly named list of Property providers
>>> 3. I have the ability to control the order in which the property solution
>>> will be performed
>>>
>>> Bye,
>>>
>>> Oliver
>>>
>>>
>>> Am 01.12.14 17:54, schrieb Romain Manni-Bucau:
>>>
>>> Configuration.current() sounds easier to understand first time you see
>>>> it. I like Configuration.newInstance() if that's really what it does
>>>> (ie no caching by classloader or anything else).
>>>>
>>>>
>>>> Romain Manni-Bucau
>>>> @rmannibucau
>>>> http://www.tomitribe.com
>>>> http://rmannibucau.wordpress.com
>>>> https://github.com/rmannibucau
>>>>
>>>>
>>>> 2014-12-01 17:42 GMT+01:00 Anatole Tresch <at...@gmail.com>:
>>>>
>>>>> There is a naming concept from Stephen Colebourne when to use of, from,
>>>>> with. I try to lookup the link later, see also jsr 310 and 354.
>>>>> getInstance, valueOf are considered to be outdated for modern api
>>>>> design.
>>>>>
>>>>> Adding a helper, why? Another artifact a user must know, makes sense,
>>>>> where
>>>>> you have a huge acces api IMO (see PropertyProviders where the factory
>>>>> methods are not part of the PropertyProvider interface. For
>>>>> Configuration
>>>>> I
>>>>> prefer having sn intuitive simple/single access...
>>>>>
>>>>> Nevertheless I would like to encourage you to make a concrete proposal
>>>>> how
>>>>> would name things, so we can compare what your idea of fluent is ;)
>>>>>
>>>>> -anatole
>>>>> Gerhard Petracek <ge...@gmail.com> schrieb am Mo., 1. Dez.
>>>>> 2014
>>>>> um 17:24:
>>>>>
>>>>> 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
>>>>>> <anatole.tresch@credit-suisse.
>>>>>> com
>>>>>>
>>>>>>> :
>>>>>>> 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:gerhard.petracek@gmail.com]
>>>>>>> Sent: Montag, 1. Dezember 2014 14:30
>>>>>>> To: dev@tamaya.incubator.apache.org
>>>>>>> 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 <an...@apache.org>:
>>>>>>>
>>>>>>> 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 <ge...@gmail.com> 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 <
>>>>>>>>> rmannibucau@gmail.com
>>>>>>>>>
>>>>>>>> :
>>>>>>>
>>>>>>>> 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 <an...@apache.org>:
>>>>>>>>>>
>>>>>>>>>>> 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
>>>>>>>>>>>
>>>>>>>>>>> --
>>> N Oliver B. Fischer
>>> A Schönhauser Allee 64, 10437 Berlin, Deutschland/Germany
>>> P +49 30 44793251
>>> M +49 178 7903538
>>> E o.b.fischer@swe-blog.net
>>> S oliver.b.fischer
>>> J oliver.b.fischer@jabber.org
>>> X http://xing.to/obf
>>>
>>>
> --
> N Oliver B. Fischer
> A Schönhauser Allee 64, 10437 Berlin, Deutschland/Germany
> P +49 30 44793251
> M +49 178 7903538
> E o.b.fischer@swe-blog.net
> S oliver.b.fischer
> J oliver.b.fischer@jabber.org
> X http://xing.to/obf
>
>
Re: Use Case 1: Read simple properties and get values.
Posted by "Oliver B. Fischer" <o....@swe-blog.net>.
I like the idea of builders.
If we have default providers via SPI how do we handle the a case there
two providers offer a value for the same key?
Furthermore I would like to have the posibillty to decide which
providers are automatically choosen by providing a
-Dproviders=org.apache.tamaya.ProviderA,org.apache.tamaya.ProviderB
Oliver
Am 01.12.14 18:53, schrieb Romain Manni-Bucau:
> Markdown4j has something pretty nice (specific but I guess the idea is
> reusable for us):
>
> Configuration.builder().forceExtentedProfile().registerPlugins(new
> YumlPlugin(), new WebSequencePlugin(), new
> IncludePlugin()).convertNewline2Br().setDecorator(decorator).setCodeBlockEmitter(new
> CodeBlockEmitter()).build().
>
> What I like:
> 1) builder (so can be read-only once built + API is auto-documented
> and here it is fluent)
> 2) manual registration of plugins (loaders for us)
>
> So we could get:
>
> Configuration c = new Configuration.Builder().propertyProviders(new
> MyProviders1(), new MyProviders2()).build()
>
> Not that we can easily write a PropertyProviders using a SPI and I
> would wire it as a default one if propertyProviders is not called (ie
> set of providers is empty.
>
> This would also allow us to add other features later like property
> post processors (to change properties loaded from providers etc...)
> pretty easily and clean-ly.
>
> wdyt?
>
>
>
> Romain Manni-Bucau
> @rmannibucau
> http://www.tomitribe.com
> http://rmannibucau.wordpress.com
> https://github.com/rmannibucau
>
>
> 2014-12-01 18:31 GMT+01:00 Oliver B. Fischer <o....@swe-blog.net>:
>> Hi,
>>
>> for me the most simple use case is
>>
>> Configuration conf = new Configuration();
>> String value = conf.get("key")
>>
>> And this use case is already very complex under the hood.
>>
>> Before discussing other details we have to decide how PropertyProviders are
>> activated.
>>
>> I would like to have the following possibilites:
>>
>> 1. Tamaya activates all PropertyProviders found in the classpath and
>> activated via SPI.
>> 2. Tamaya activates only a explicitly named list of Property providers
>> 3. I have the ability to control the order in which the property solution
>> will be performed
>>
>> Bye,
>>
>> Oliver
>>
>>
>> Am 01.12.14 17:54, schrieb Romain Manni-Bucau:
>>
>>> Configuration.current() sounds easier to understand first time you see
>>> it. I like Configuration.newInstance() if that's really what it does
>>> (ie no caching by classloader or anything else).
>>>
>>>
>>> Romain Manni-Bucau
>>> @rmannibucau
>>> http://www.tomitribe.com
>>> http://rmannibucau.wordpress.com
>>> https://github.com/rmannibucau
>>>
>>>
>>> 2014-12-01 17:42 GMT+01:00 Anatole Tresch <at...@gmail.com>:
>>>> There is a naming concept from Stephen Colebourne when to use of, from,
>>>> with. I try to lookup the link later, see also jsr 310 and 354.
>>>> getInstance, valueOf are considered to be outdated for modern api design.
>>>>
>>>> Adding a helper, why? Another artifact a user must know, makes sense,
>>>> where
>>>> you have a huge acces api IMO (see PropertyProviders where the factory
>>>> methods are not part of the PropertyProvider interface. For Configuration
>>>> I
>>>> prefer having sn intuitive simple/single access...
>>>>
>>>> Nevertheless I would like to encourage you to make a concrete proposal
>>>> how
>>>> would name things, so we can compare what your idea of fluent is ;)
>>>>
>>>> -anatole
>>>> Gerhard Petracek <ge...@gmail.com> schrieb am Mo., 1. Dez.
>>>> 2014
>>>> um 17:24:
>>>>
>>>>> 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
>>>>> <anatole.tresch@credit-suisse.
>>>>> com
>>>>>> :
>>>>>> 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:gerhard.petracek@gmail.com]
>>>>>> Sent: Montag, 1. Dezember 2014 14:30
>>>>>> To: dev@tamaya.incubator.apache.org
>>>>>> 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 <an...@apache.org>:
>>>>>>
>>>>>>> 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 <ge...@gmail.com> 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 <rmannibucau@gmail.com
>>>>>> :
>>>>>>>>> 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 <an...@apache.org>:
>>>>>>>>>> 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
>>>>>>>>>>
>> --
>> N Oliver B. Fischer
>> A Schönhauser Allee 64, 10437 Berlin, Deutschland/Germany
>> P +49 30 44793251
>> M +49 178 7903538
>> E o.b.fischer@swe-blog.net
>> S oliver.b.fischer
>> J oliver.b.fischer@jabber.org
>> X http://xing.to/obf
>>
--
N Oliver B. Fischer
A Schönhauser Allee 64, 10437 Berlin, Deutschland/Germany
P +49 30 44793251
M +49 178 7903538
E o.b.fischer@swe-blog.net
S oliver.b.fischer
J oliver.b.fischer@jabber.org
X http://xing.to/obf
Re: Use Case 1: Read simple properties and get values.
Posted by Anatole Tresch <at...@gmail.com>.
Hi all
basically this is a variant, but currently there is also the concept of a
PropertyProvider. I created this interface, because I wanted to make live
as easy as possible for the ones that implement a property source (aka
PropertyProvider). The functionality is very similar to what Spring has
(despite the fact that Spring uses abstract classes!). Property Providers
can very easily combined since there are only String keys/values to be
merged, compared etc. Once you have a new provider you can decorate it
again as a Configuration (by calling toConfiguration()).
I even also added a ConfigurationBuilder and I think having one is a good
thing. Basically for PropertyProviders I recommend to reduce the APIs
footprint for the common use cases. This is way the PropertyProviders
singleton exists: it reduces the implementation artifacts you have to
depend on for the most common uses cases as they are:
- reading config from resources(files, uris/urls, classpath, ...)
- creating a provider based on a map
- combining providers (aggregation, intersection, subtraction etc.)
For all other use cases you typically will implement your own provider, or
we may provide prebuilt ones, e.g. for reading from a datasource, JSON
etc...
Summarizing
- *Configuration *is the interface and the *representation *of a
Configuration and the *accessor *for the current Configuration. It can
be accessed directly, used as a base for injection, or as input to a
template engine (the ladder two not yet covered).
- *PropertyProvider *is the low *level building blocks *for getting
*configuration
data *into the system. With a minimal API (or SPI) and a minimal
footprint.
- *PropertyProviders *is the singleton factory to access the most *common
operations to build and combine of property providers*.
- *ConfigurationBuilder *can be used to create a concrete configuration
tree. But be aware for complex cases it might not work. E.g. think of a
complex combined configuration tree with two or more subtrees and different
combination strategies (not uncommon in complex scenarios). The builder
gets very complex with different child builders. Similarly there are parts
of config (providers) that may be instantiated and existing once, whereas
other are even runtime dependent (e.g. on the current user logged
authenticated)...
But overall I think Romain's idea go in the right direction ;)
Anatole
2014-12-01 18:53 GMT+01:00 Romain Manni-Bucau <rm...@gmail.com>:
> Markdown4j has something pretty nice (specific but I guess the idea is
> reusable for us):
>
> Configuration.builder().forceExtentedProfile().registerPlugins(new
> YumlPlugin(), new WebSequencePlugin(), new
>
> IncludePlugin()).convertNewline2Br().setDecorator(decorator).setCodeBlockEmitter(new
> CodeBlockEmitter()).build().
>
> What I like:
> 1) builder (so can be read-only once built + API is auto-documented
> and here it is fluent)
> 2) manual registration of plugins (loaders for us)
>
> So we could get:
>
> Configuration c = new Configuration.Builder().propertyProviders(new
> MyProviders1(), new MyProviders2()).build()
>
> Not that we can easily write a PropertyProviders using a SPI and I
> would wire it as a default one if propertyProviders is not called (ie
> set of providers is empty.
>
> This would also allow us to add other features later like property
> post processors (to change properties loaded from providers etc...)
> pretty easily and clean-ly.
>
> wdyt?
>
>
>
> Romain Manni-Bucau
> @rmannibucau
> http://www.tomitribe.com
> http://rmannibucau.wordpress.com
> https://github.com/rmannibucau
>
>
> 2014-12-01 18:31 GMT+01:00 Oliver B. Fischer <o....@swe-blog.net>:
> > Hi,
> >
> > for me the most simple use case is
> >
> > Configuration conf = new Configuration();
> > String value = conf.get("key")
> >
> > And this use case is already very complex under the hood.
> >
> > Before discussing other details we have to decide how PropertyProviders
> are
> > activated.
> >
> > I would like to have the following possibilites:
> >
> > 1. Tamaya activates all PropertyProviders found in the classpath and
> > activated via SPI.
> > 2. Tamaya activates only a explicitly named list of Property providers
> > 3. I have the ability to control the order in which the property solution
> > will be performed
> >
> > Bye,
> >
> > Oliver
> >
> >
> > Am 01.12.14 17:54, schrieb Romain Manni-Bucau:
> >
> >> Configuration.current() sounds easier to understand first time you see
> >> it. I like Configuration.newInstance() if that's really what it does
> >> (ie no caching by classloader or anything else).
> >>
> >>
> >> Romain Manni-Bucau
> >> @rmannibucau
> >> http://www.tomitribe.com
> >> http://rmannibucau.wordpress.com
> >> https://github.com/rmannibucau
> >>
> >>
> >> 2014-12-01 17:42 GMT+01:00 Anatole Tresch <at...@gmail.com>:
> >>>
> >>> There is a naming concept from Stephen Colebourne when to use of, from,
> >>> with. I try to lookup the link later, see also jsr 310 and 354.
> >>> getInstance, valueOf are considered to be outdated for modern api
> design.
> >>>
> >>> Adding a helper, why? Another artifact a user must know, makes sense,
> >>> where
> >>> you have a huge acces api IMO (see PropertyProviders where the factory
> >>> methods are not part of the PropertyProvider interface. For
> Configuration
> >>> I
> >>> prefer having sn intuitive simple/single access...
> >>>
> >>> Nevertheless I would like to encourage you to make a concrete proposal
> >>> how
> >>> would name things, so we can compare what your idea of fluent is ;)
> >>>
> >>> -anatole
> >>> Gerhard Petracek <ge...@gmail.com> schrieb am Mo., 1. Dez.
> >>> 2014
> >>> um 17:24:
> >>>
> >>>> 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
> >>>> <anatole.tresch@credit-suisse.
> >>>> com
> >>>>>
> >>>>> :
> >>>>> 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:gerhard.petracek@gmail.com]
> >>>>> Sent: Montag, 1. Dezember 2014 14:30
> >>>>> To: dev@tamaya.incubator.apache.org
> >>>>> 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 <an...@apache.org>:
> >>>>>
> >>>>>> 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 <ge...@gmail.com> 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 <
> rmannibucau@gmail.com
> >>>>>
> >>>>> :
> >>>>>>>>
> >>>>>>>> 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 <an...@apache.org>:
> >>>>>>>>>
> >>>>>>>>> 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
> >>>>>>>>>
> >
> > --
> > N Oliver B. Fischer
> > A Schönhauser Allee 64, 10437 Berlin, Deutschland/Germany
> > P +49 30 44793251
> > M +49 178 7903538
> > E o.b.fischer@swe-blog.net
> > S oliver.b.fischer
> > J oliver.b.fischer@jabber.org
> > X http://xing.to/obf
> >
>
--
*Anatole Tresch*
Java Engineer & Architect, JSR Spec Lead
Glärnischweg 10
CH - 8620 Wetzikon
*Switzerland, Europe Zurich, GMT+1*
*Twitter: @atsticks*
*Blogs: **http://javaremarkables.blogspot.ch/
<http://javaremarkables.blogspot.ch/>*
*Google: atsticksMobile +41-76 344 62 79*
Re: Use Case 1: Read simple properties and get values.
Posted by Romain Manni-Bucau <rm...@gmail.com>.
Markdown4j has something pretty nice (specific but I guess the idea is
reusable for us):
Configuration.builder().forceExtentedProfile().registerPlugins(new
YumlPlugin(), new WebSequencePlugin(), new
IncludePlugin()).convertNewline2Br().setDecorator(decorator).setCodeBlockEmitter(new
CodeBlockEmitter()).build().
What I like:
1) builder (so can be read-only once built + API is auto-documented
and here it is fluent)
2) manual registration of plugins (loaders for us)
So we could get:
Configuration c = new Configuration.Builder().propertyProviders(new
MyProviders1(), new MyProviders2()).build()
Not that we can easily write a PropertyProviders using a SPI and I
would wire it as a default one if propertyProviders is not called (ie
set of providers is empty.
This would also allow us to add other features later like property
post processors (to change properties loaded from providers etc...)
pretty easily and clean-ly.
wdyt?
Romain Manni-Bucau
@rmannibucau
http://www.tomitribe.com
http://rmannibucau.wordpress.com
https://github.com/rmannibucau
2014-12-01 18:31 GMT+01:00 Oliver B. Fischer <o....@swe-blog.net>:
> Hi,
>
> for me the most simple use case is
>
> Configuration conf = new Configuration();
> String value = conf.get("key")
>
> And this use case is already very complex under the hood.
>
> Before discussing other details we have to decide how PropertyProviders are
> activated.
>
> I would like to have the following possibilites:
>
> 1. Tamaya activates all PropertyProviders found in the classpath and
> activated via SPI.
> 2. Tamaya activates only a explicitly named list of Property providers
> 3. I have the ability to control the order in which the property solution
> will be performed
>
> Bye,
>
> Oliver
>
>
> Am 01.12.14 17:54, schrieb Romain Manni-Bucau:
>
>> Configuration.current() sounds easier to understand first time you see
>> it. I like Configuration.newInstance() if that's really what it does
>> (ie no caching by classloader or anything else).
>>
>>
>> Romain Manni-Bucau
>> @rmannibucau
>> http://www.tomitribe.com
>> http://rmannibucau.wordpress.com
>> https://github.com/rmannibucau
>>
>>
>> 2014-12-01 17:42 GMT+01:00 Anatole Tresch <at...@gmail.com>:
>>>
>>> There is a naming concept from Stephen Colebourne when to use of, from,
>>> with. I try to lookup the link later, see also jsr 310 and 354.
>>> getInstance, valueOf are considered to be outdated for modern api design.
>>>
>>> Adding a helper, why? Another artifact a user must know, makes sense,
>>> where
>>> you have a huge acces api IMO (see PropertyProviders where the factory
>>> methods are not part of the PropertyProvider interface. For Configuration
>>> I
>>> prefer having sn intuitive simple/single access...
>>>
>>> Nevertheless I would like to encourage you to make a concrete proposal
>>> how
>>> would name things, so we can compare what your idea of fluent is ;)
>>>
>>> -anatole
>>> Gerhard Petracek <ge...@gmail.com> schrieb am Mo., 1. Dez.
>>> 2014
>>> um 17:24:
>>>
>>>> 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
>>>> <anatole.tresch@credit-suisse.
>>>> com
>>>>>
>>>>> :
>>>>> 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:gerhard.petracek@gmail.com]
>>>>> Sent: Montag, 1. Dezember 2014 14:30
>>>>> To: dev@tamaya.incubator.apache.org
>>>>> 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 <an...@apache.org>:
>>>>>
>>>>>> 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 <ge...@gmail.com> 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 <rmannibucau@gmail.com
>>>>>
>>>>> :
>>>>>>>>
>>>>>>>> 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 <an...@apache.org>:
>>>>>>>>>
>>>>>>>>> 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
>>>>>>>>>
>
> --
> N Oliver B. Fischer
> A Schönhauser Allee 64, 10437 Berlin, Deutschland/Germany
> P +49 30 44793251
> M +49 178 7903538
> E o.b.fischer@swe-blog.net
> S oliver.b.fischer
> J oliver.b.fischer@jabber.org
> X http://xing.to/obf
>
Re: Use Case 1: Read simple properties and get values.
Posted by "Oliver B. Fischer" <o....@swe-blog.net>.
Hi,
for me the most simple use case is
Configuration conf = new Configuration();
String value = conf.get("key")
And this use case is already very complex under the hood.
Before discussing other details we have to decide how PropertyProviders
are activated.
I would like to have the following possibilites:
1. Tamaya activates all PropertyProviders found in the classpath and
activated via SPI.
2. Tamaya activates only a explicitly named list of Property providers
3. I have the ability to control the order in which the property
solution will be performed
Bye,
Oliver
Am 01.12.14 17:54, schrieb Romain Manni-Bucau:
> Configuration.current() sounds easier to understand first time you see
> it. I like Configuration.newInstance() if that's really what it does
> (ie no caching by classloader or anything else).
>
>
> Romain Manni-Bucau
> @rmannibucau
> http://www.tomitribe.com
> http://rmannibucau.wordpress.com
> https://github.com/rmannibucau
>
>
> 2014-12-01 17:42 GMT+01:00 Anatole Tresch <at...@gmail.com>:
>> There is a naming concept from Stephen Colebourne when to use of, from,
>> with. I try to lookup the link later, see also jsr 310 and 354.
>> getInstance, valueOf are considered to be outdated for modern api design.
>>
>> Adding a helper, why? Another artifact a user must know, makes sense, where
>> you have a huge acces api IMO (see PropertyProviders where the factory
>> methods are not part of the PropertyProvider interface. For Configuration I
>> prefer having sn intuitive simple/single access...
>>
>> Nevertheless I would like to encourage you to make a concrete proposal how
>> would name things, so we can compare what your idea of fluent is ;)
>>
>> -anatole
>> Gerhard Petracek <ge...@gmail.com> schrieb am Mo., 1. Dez. 2014
>> um 17:24:
>>
>>> 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 <anatole.tresch@credit-suisse.
>>> com
>>>> :
>>>> 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:gerhard.petracek@gmail.com]
>>>> Sent: Montag, 1. Dezember 2014 14:30
>>>> To: dev@tamaya.incubator.apache.org
>>>> 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 <an...@apache.org>:
>>>>
>>>>> 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 <ge...@gmail.com> 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 <rmannibucau@gmail.com
>>>> :
>>>>>>> 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 <an...@apache.org>:
>>>>>>>> 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
>>>>>>>>
--
N Oliver B. Fischer
A Schönhauser Allee 64, 10437 Berlin, Deutschland/Germany
P +49 30 44793251
M +49 178 7903538
E o.b.fischer@swe-blog.net
S oliver.b.fischer
J oliver.b.fischer@jabber.org
X http://xing.to/obf
Re: Use Case 1: Read simple properties and get values.
Posted by Romain Manni-Bucau <rm...@gmail.com>.
Configuration.current() sounds easier to understand first time you see
it. I like Configuration.newInstance() if that's really what it does
(ie no caching by classloader or anything else).
Romain Manni-Bucau
@rmannibucau
http://www.tomitribe.com
http://rmannibucau.wordpress.com
https://github.com/rmannibucau
2014-12-01 17:42 GMT+01:00 Anatole Tresch <at...@gmail.com>:
> There is a naming concept from Stephen Colebourne when to use of, from,
> with. I try to lookup the link later, see also jsr 310 and 354.
> getInstance, valueOf are considered to be outdated for modern api design.
>
> Adding a helper, why? Another artifact a user must know, makes sense, where
> you have a huge acces api IMO (see PropertyProviders where the factory
> methods are not part of the PropertyProvider interface. For Configuration I
> prefer having sn intuitive simple/single access...
>
> Nevertheless I would like to encourage you to make a concrete proposal how
> would name things, so we can compare what your idea of fluent is ;)
>
> -anatole
> Gerhard Petracek <ge...@gmail.com> schrieb am Mo., 1. Dez. 2014
> um 17:24:
>
>> 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 <anatole.tresch@credit-suisse.
>> com
>> >:
>>
>> > 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:gerhard.petracek@gmail.com]
>> > Sent: Montag, 1. Dezember 2014 14:30
>> > To: dev@tamaya.incubator.apache.org
>> > 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 <an...@apache.org>:
>> >
>> > > 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 <ge...@gmail.com> 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 <rmannibucau@gmail.com
>> >:
>> > > >
>> > > > > 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 <an...@apache.org>:
>> > > > > > 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
>> > > > > >
>> > > > >
>> > > >
>> > >
>> >
>>
Re: Use Case 1: Read simple properties and get values.
Posted by Anatole Tresch <at...@gmail.com>.
There is a naming concept from Stephen Colebourne when to use of, from,
with. I try to lookup the link later, see also jsr 310 and 354.
getInstance, valueOf are considered to be outdated for modern api design.
Adding a helper, why? Another artifact a user must know, makes sense, where
you have a huge acces api IMO (see PropertyProviders where the factory
methods are not part of the PropertyProvider interface. For Configuration I
prefer having sn intuitive simple/single access...
Nevertheless I would like to encourage you to make a concrete proposal how
would name things, so we can compare what your idea of fluent is ;)
-anatole
Gerhard Petracek <ge...@gmail.com> schrieb am Mo., 1. Dez. 2014
um 17:24:
> 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 <anatole.tresch@credit-suisse.
> com
> >:
>
> > 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:gerhard.petracek@gmail.com]
> > Sent: Montag, 1. Dezember 2014 14:30
> > To: dev@tamaya.incubator.apache.org
> > 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 <an...@apache.org>:
> >
> > > 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 <ge...@gmail.com> 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 <rmannibucau@gmail.com
> >:
> > > >
> > > > > 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 <an...@apache.org>:
> > > > > > 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
> > > > > >
> > > > >
> > > >
> > >
> >
>
Re: Use Case 1: Read simple properties and get values.
Posted by Gerhard Petracek <ge...@gmail.com>.
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 <anatole.tresch@credit-suisse.com
>:
> 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:gerhard.petracek@gmail.com]
> Sent: Montag, 1. Dezember 2014 14:30
> To: dev@tamaya.incubator.apache.org
> 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 <an...@apache.org>:
>
> > 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 <ge...@gmail.com> 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 <rm...@gmail.com>:
> > >
> > > > 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 <an...@apache.org>:
> > > > > 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
> > > > >
> > > >
> > >
> >
>
RE: Use Case 1: Read simple properties and get values.
Posted by "Tresch, Anatole " <an...@credit-suisse.com>.
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:gerhard.petracek@gmail.com]
Sent: Montag, 1. Dezember 2014 14:30
To: dev@tamaya.incubator.apache.org
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 <an...@apache.org>:
> 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 <ge...@gmail.com> 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 <rm...@gmail.com>:
> >
> > > 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 <an...@apache.org>:
> > > > 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
> > > >
> > >
> >
>
Re: Use Case 1: Read simple properties and get values.
Posted by Gerhard Petracek <ge...@gmail.com>.
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 <an...@apache.org>:
> 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 <ge...@gmail.com> 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 <rm...@gmail.com>:
> >
> > > 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 <an...@apache.org>:
> > > > 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
> > > >
> > >
> >
>
Re: Use Case 1: Read simple properties and get values.
Posted by Anatole Tresch <an...@apache.org>.
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 <an...@apache.org> 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 <ge...@gmail.com> 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 <rm...@gmail.com>:
>>
>> > 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 <an...@apache.org>:
>> > > 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
>> > >
>> >
>>
>
Re: Use Case 1: Read simple properties and get values.
Posted by Anatole Tresch <an...@apache.org>.
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 <ge...@gmail.com> 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 <rm...@gmail.com>:
>
> > 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 <an...@apache.org>:
> > > 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
> > >
> >
>
Re: Use Case 1: Read simple properties and get values.
Posted by Gerhard Petracek <ge...@gmail.com>.
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 <rm...@gmail.com>:
> 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 <an...@apache.org>:
> > 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
> >
>
Re: Use Case 1: Read simple properties and get values.
Posted by Romain Manni-Bucau <rm...@gmail.com>.
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 <an...@apache.org>:
> 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
>