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 <at...@gmail.com> on 2014/12/18 00:05:11 UTC
UC: Configuration Injection (SE)
Hi all
I would like to present another use case: injection of configuration in SE
(EE should be almost similar):
Automatic Configuration (Configuration Injection)
Tamaya must provide a feature for automatic configuration, where properties
of a class or methods can be annotated:
-
Hereby the lifecycle of the instances configured should not be managed
by Tamaya.
-
String as well as other types should be supported.
-
It must be possible to define default values to be used, if no valid
value is present.
-
It must be possible to define dynamic expressions, at least for default
values.
-
The values configured can be reinjected, if the underlying configuration
changes. This should also be the case fir final classes, such as Strings.
-
Reinjection should be controllable by an loading policy.
-
It should be possible to evaluate multiple keys, e.g. current keys, and
as a backup deprecated keys from former application releases.
-
It should be possible to evaluate multiple configurations.
-
The type conversion of the properties injected should be configurable.
-
The value evaluated for a property (before type conversion) may be
adaptable as well.
-
It should be possible to observe configuration changes.
To illustrate the points above imagine the following POJO:
Configured POJO Example
*public* *class* *MyPojo* {
@ConfigProperty("myCurrency")
@DefaultValue("CHF") // use as default
@WithLoadingPolicy(LoadingPolicy.INITIAL) // load the value only
once (no reinjection)
*private* *String* currency;
@ConfigProperty("myCurrencyRate")
*private* *Long* currencyRate;
@ConfigProperty // evaluates to
key=<fieldName>="fullRate"
@ConfigProperty("fallback.property")
@WithConfig("default")
@WithConfig("moduleConfig");
*private* *BigDecimal* fullRate;
// Configuration method
*void* setStartup(@ConfigProperty *boolean* startup,
@ConfigProperty("componentName") @WithConfig("module1")
@DefaultValue("N/A") *String* compName){
...
}
// Configuration method
@ConfigProperty("componentName")
@WithConfig("module1")
@DefaultValue("N/A")
*private* *void* setComponentName(*String* compName){
...
}
// Configuration listener method, defining which properties to listen for
@ConfigChanges
@ConfigProperty("componentName")
*private* *void* setComponentName(ConfigChange change){
...
}
}
The instance then can be passed for being configured:
Configuring a POJO
MyPojo instance = *new* MyPojo();*Configuration*.configure(instance);
This will configure all values according to the load policies (by default
LoadPolicy.INITIAL). Depending on the listeners present and the properties
injected Tamaya will keep weak references to the bean and the current
environment, so it can be determined, when configuration changes must be
published into the bean.
Feel free to comment or ask questions ;)
Best,
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: UC: Configuration Injection (SE)
Posted by Anatole Tresch <at...@gmail.com>.
Yeah, indeed that makes sense!
Romain Manni-Bucau <rm...@gmail.com> schrieb am Do., 18. Dez. 2014 um
14:52:
> I wouldnt put it in Configuration.of - would collide with formats no? I see
> codec closer to values otherwise we laybe need to merge codec and formats.
> But globally agree.
> Le 18 déc. 2014 13:13, "Tresch, Anatole" <anatole.tresch@credit-suisse.com
> >
> a écrit :
>
> > See inline...
> >
> >
> >
> > -----Original Message-----
> > From: Romain Manni-Bucau [mailto:rmannibucau@gmail.com]
> > Sent: Donnerstag, 18. Dezember 2014 09:21
> > To: dev@tamaya.incubator.apache.org
> > Subject: Re: UC: Configuration Injection (SE)
> >
> >
> >
> > using pseudo code to make it shorter:
> >
> >
> >
> > public class MyConfig {
> >
> > @Config(...)
> >
> > @Codec(deserializer = JSonDeserializer.class, serializer =
> >
> > JSonSerializer.class)
> >
> > MySubConfig sub;
> >
> > }
> >
> >
> >
> > config could then be foo = {"a":"b",...} and MySubConfig = { String b;...
> > }.
> >
> >
> >
> > Until now nothing needing all this stuff but now suppose I modify sub
> >
> > during app lifecycle, how do I store modifications?
> >
> >
> >
> > What I would avoid is to 100% rely on impls (ie I cast my Source and
> >
> > use its store method for instance).
> >
> >
> >
> > -> +1 if we want this feature to be offered, it should be supported by
> the
> > API...
> >
> >
> >
> > Would be great to be symmetric :)
> >
> > -> I would also start think about how to include this feature as part of
> > the API. My ideas currently are as follows
> >
> >
> >
> > 0) a Codec implements two functional interfaces: ConfigSerializer,
> > ConfigDeserializer (or encoder/decoder? )
> >
> >
> >
> > 1) Offer creation of a Configuration using a Codec, e.g.
> >
> >
> >
> > String jsonOrWhatever = ...;
> >
> > Codec codec = ...;
> >
> > Configuration config = Configuration.of(jsonOrWhatEver, codec); //
> takes
> > a deserializer
> >
> >
> >
> > and with templates:
> >
> >
> >
> > String jsonOrWhatever = ...;
> >
> > Codec codec = ...;
> >
> > Configuration config = codec.decode(jsonOrWhatEver); // takes a
> > deserializer
> >
> > MyConfig config = Configuration.of(MyConfig.class, config); //
> signature
> > public static <T> T of(Class<T> template, Configuration... configs);
> >
> >
> >
> > and
> >
> >
> >
> > Codec codec = ...;
> >
> > Configuration config = ...;
> >
> > String jsonOrWhatever = codec.encode(config); // a serializer
> >
> > // or in addition, when serializer extends ConfigQuery<String>
> >
> > String jsonOrWhatever = config.query(encoder);
> >
> >
> >
> >
> >
> > and
> >
> >
> >
> > Codec codec = ...;
> >
> > MyConfig config = ...;
> >
> > String jsonOrWhatever = codec.encode(config);
> >
> >
> >
> > WDYT?
> >
> >
> >
> > Anatole
> >
> >
> >
> >
> >
>
RE: UC: Configuration Injection (SE)
Posted by Romain Manni-Bucau <rm...@gmail.com>.
I wouldnt put it in Configuration.of - would collide with formats no? I see
codec closer to values otherwise we laybe need to merge codec and formats.
But globally agree.
Le 18 déc. 2014 13:13, "Tresch, Anatole" <an...@credit-suisse.com>
a écrit :
> See inline...
>
>
>
> -----Original Message-----
> From: Romain Manni-Bucau [mailto:rmannibucau@gmail.com]
> Sent: Donnerstag, 18. Dezember 2014 09:21
> To: dev@tamaya.incubator.apache.org
> Subject: Re: UC: Configuration Injection (SE)
>
>
>
> using pseudo code to make it shorter:
>
>
>
> public class MyConfig {
>
> @Config(...)
>
> @Codec(deserializer = JSonDeserializer.class, serializer =
>
> JSonSerializer.class)
>
> MySubConfig sub;
>
> }
>
>
>
> config could then be foo = {"a":"b",...} and MySubConfig = { String b;...
> }.
>
>
>
> Until now nothing needing all this stuff but now suppose I modify sub
>
> during app lifecycle, how do I store modifications?
>
>
>
> What I would avoid is to 100% rely on impls (ie I cast my Source and
>
> use its store method for instance).
>
>
>
> -> +1 if we want this feature to be offered, it should be supported by the
> API...
>
>
>
> Would be great to be symmetric :)
>
> -> I would also start think about how to include this feature as part of
> the API. My ideas currently are as follows
>
>
>
> 0) a Codec implements two functional interfaces: ConfigSerializer,
> ConfigDeserializer (or encoder/decoder? )
>
>
>
> 1) Offer creation of a Configuration using a Codec, e.g.
>
>
>
> String jsonOrWhatever = ...;
>
> Codec codec = ...;
>
> Configuration config = Configuration.of(jsonOrWhatEver, codec); // takes
> a deserializer
>
>
>
> and with templates:
>
>
>
> String jsonOrWhatever = ...;
>
> Codec codec = ...;
>
> Configuration config = codec.decode(jsonOrWhatEver); // takes a
> deserializer
>
> MyConfig config = Configuration.of(MyConfig.class, config); // signature
> public static <T> T of(Class<T> template, Configuration... configs);
>
>
>
> and
>
>
>
> Codec codec = ...;
>
> Configuration config = ...;
>
> String jsonOrWhatever = codec.encode(config); // a serializer
>
> // or in addition, when serializer extends ConfigQuery<String>
>
> String jsonOrWhatever = config.query(encoder);
>
>
>
>
>
> and
>
>
>
> Codec codec = ...;
>
> MyConfig config = ...;
>
> String jsonOrWhatever = codec.encode(config);
>
>
>
> WDYT?
>
>
>
> Anatole
>
>
>
>
>
RE: UC: Configuration Injection (SE)
Posted by "Tresch, Anatole " <an...@credit-suisse.com>.
See inline...
-----Original Message-----
From: Romain Manni-Bucau [mailto:rmannibucau@gmail.com]
Sent: Donnerstag, 18. Dezember 2014 09:21
To: dev@tamaya.incubator.apache.org
Subject: Re: UC: Configuration Injection (SE)
using pseudo code to make it shorter:
public class MyConfig {
@Config(...)
@Codec(deserializer = JSonDeserializer.class, serializer =
JSonSerializer.class)
MySubConfig sub;
}
config could then be foo = {"a":"b",...} and MySubConfig = { String b;... }.
Until now nothing needing all this stuff but now suppose I modify sub
during app lifecycle, how do I store modifications?
What I would avoid is to 100% rely on impls (ie I cast my Source and
use its store method for instance).
-> +1 if we want this feature to be offered, it should be supported by the API...
Would be great to be symmetric :)
-> I would also start think about how to include this feature as part of the API. My ideas currently are as follows
0) a Codec implements two functional interfaces: ConfigSerializer, ConfigDeserializer (or encoder/decoder? )
1) Offer creation of a Configuration using a Codec, e.g.
String jsonOrWhatever = ...;
Codec codec = ...;
Configuration config = Configuration.of(jsonOrWhatEver, codec); // takes a deserializer
and with templates:
String jsonOrWhatever = ...;
Codec codec = ...;
Configuration config = codec.decode(jsonOrWhatEver); // takes a deserializer
MyConfig config = Configuration.of(MyConfig.class, config); // signature public static <T> T of(Class<T> template, Configuration... configs);
and
Codec codec = ...;
Configuration config = ...;
String jsonOrWhatever = codec.encode(config); // a serializer
// or in addition, when serializer extends ConfigQuery<String>
String jsonOrWhatever = config.query(encoder);
and
Codec codec = ...;
MyConfig config = ...;
String jsonOrWhatever = codec.encode(config);
WDYT?
Anatole
Re: UC: Configuration Injection (SE)
Posted by Romain Manni-Bucau <rm...@gmail.com>.
yes, we did it with a colleague in my previous job. JSon is not super
great to maintain but lists and maps are (we implemented it using
XBean).
Romain Manni-Bucau
@rmannibucau
http://www.tomitribe.com
http://rmannibucau.wordpress.com
https://github.com/rmannibucau
2014-12-18 10:37 GMT+01:00 Tresch, Anatole <an...@credit-suisse.com>:
> So your idea is to add more complex configuration structures, e.g. JSON into a value and therefore have the possibility to serialize back changes, done to the config...
> We will have to add that use case. It would also simplify supporting complex datastructures like collections, etc.
>
>
>
> -----Original Message-----
> From: Romain Manni-Bucau [mailto:rmannibucau@gmail.com]
> Sent: Donnerstag, 18. Dezember 2014 09:21
> To: dev@tamaya.incubator.apache.org
> Subject: Re: UC: Configuration Injection (SE)
>
> using pseudo code to make it shorter:
>
> public class MyConfig {
> @Config(...)
> @Codec(deserializer = JSonDeserializer.class, serializer =
> JSonSerializer.class)
> MySubConfig sub;
> }
>
> config could then be foo = {"a":"b",...} and MySubConfig = { String b;... }.
>
> Until now nothing needing all this stuff but now suppose I modify sub
> during app lifecycle, how do I store modifications?
>
> What I would avoid is to 100% rely on impls (ie I cast my Source and
> use its store method for instance).
>
> Would be great to be symmetric :)
>
>
>
> Romain Manni-Bucau
> @rmannibucau
> http://www.tomitribe.com
> http://rmannibucau.wordpress.com
> https://github.com/rmannibucau
>
>
> 2014-12-18 9:15 GMT+01:00 Anatole Tresch <at...@gmail.com>:
>> I dont see the uc for backserialization. For serialization normally only
>> Map<String,String> are serialized/deserislized as internal representation.
>> this the usecase for 'freezing' configs.
>>
>> What was your isea?
>>
>> Romain Manni-Bucau <rm...@gmail.com> schrieb am Do., 18. Dez. 2014 um
>> 08:36:
>>
>>> Great. So we dont propose the opposite yet? T -> String. Idea would be to
>>> be able to serialze back the config somewhere.
>>> Le 18 déc. 2014 04:45, "Anatole Tresch" <at...@gmail.com> a écrit :
>>>
>>> > Its
>>> >
>>> > @FunctionalInterface
>>> > Public interface PropertyAdapter<T>{
>>> > Public T adapt(String value);
>>> > }
>>> >
>>> > So extremly simple but powerful...
>>> > Romain Manni-Bucau <rm...@gmail.com> schrieb am Do., 18. Dez. 2014
>>> > um
>>> > 01:46:
>>> >
>>> > > PropertyAdapter from the JVM? If so clearly -1, it is slow and not
>>> > > usable @runtime (only valuable during bootstrap IMO).
>>> > >
>>> > > In Johnzon I wanted to do it as well, found it super sexy, then I
>>> > > benched...totally not usable if the config can be used "often" like it
>>> > > will for sure with CDI and potentially for each request (typical
>>> > > @RequestScoped). Only solution would be to cache computed values which
>>> > > can then be wrong if computation depends on the context which is
>>> > > totally valuable (depending the logged user for some cases for
>>> > > instance).
>>> > >
>>> > > In term of API having Serializer, Deserilizer, Codec (= Serializer +
>>> > > Deserializer) interfaces can make sense since in some cases you'll
>>> > > just want to deserilize, no?
>>> > >
>>> > >
>>> > >
>>> > >
>>> > > Romain Manni-Bucau
>>> > > @rmannibucau
>>> > > http://www.tomitribe.com
>>> > > http://rmannibucau.wordpress.com
>>> > > https://github.com/rmannibucau
>>> > >
>>> > >
>>> > > 2014-12-18 1:30 GMT+01:00 Anatole Tresch <at...@gmail.com>:
>>> > > > *Hi Romain*
>>> > > >
>>> > > > *short inline (before I take some sleep..)...*
>>> > > >
>>> > > > *Anatole*
>>> > > >
>>> > > >
>>> > > > 2014-12-18 0:13 GMT+01:00 Romain Manni-Bucau <rmannibucau@gmail.com
>>> >:
>>> > > >>
>>> > > >> 2014-12-18 0:05 GMT+01:00 Anatole Tresch <at...@gmail.com>:
>>> > > >> > Hi all
>>> > > >> > I would like to present another use case: injection of
>>> configuration
>>> > > in
>>> > > >> SE
>>> > > >> > (EE should be almost similar):
>>> > > >> >
>>> > > >> > Automatic Configuration (Configuration Injection)
>>> > > >> >
>>> > > >> > Tamaya must provide a feature for automatic configuration, where
>>> > > >> properties
>>> > > >> > of a class or methods can be annotated:
>>> > > >> >
>>> > > >> > -
>>> > > >> >
>>> > > >> > Hereby the lifecycle of the instances configured should not be
>>> > > managed
>>> > > >> > by Tamaya.
>>> > > >> > -
>>> > > >> >
>>> > > >> > String as well as other types should be supported.
>>> > > >> > -
>>> > > >> >
>>> > > >>
>>> > > >> We should limit to types we can handle to start I think (until we
>>> > > >> finished other IoC integration to keep it aligned to start)
>>> > > >>
>>> > > >> So file, string, primitive wrappers, uri, inetaddress...
>>> > > >
>>> > > >
>>> > > > *Disagree. The mechanism is already in place and working well.
>>> > > > PropertyAdapter is a generic functional interface.*
>>> > > > *I would not want to throw it away. The only thing, I see is really
>>> > worth
>>> > > > discussing are other aspects, like meta-information, and
>>> > > > multi-values/collection support. *
>>> > > >
>>> > > >
>>> > > >> > It must be possible to define default values to be used, if no
>>> > > valid
>>> > > >> > value is present.
>>> > > >> > -
>>> > > >> >
>>> > > >> > It must be possible to define dynamic expressions, at least for
>>> > > >> default
>>> > > >> > values.
>>> > > >> > -
>>> > > >> >
>>> > > >> > The values configured can be reinjected, if the underlying
>>> > > >> configuration
>>> > > >> > changes. This should also be the case fir final classes, such
>>> as
>>> > > >> Strings.
>>> > > >> > -
>>> > > >> >
>>> > > >>
>>> > > >> -1, I would introduce DynamicValue<String> (or any generic) for it
>>> > > >>
>>> > > >
>>> > > > *Other opinions? *
>>> > > >
>>> > > >>
>>> > > >> > Reinjection should be controllable by an loading policy.
>>> > > >> > -
>>> > > >> >
>>> > > >> > It should be possible to evaluate multiple keys, e.g. current
>>> > keys,
>>> > > >> and
>>> > > >> > as a backup deprecated keys from former application releases.
>>> > > >> > -
>>> > > >> >
>>> > > >> > It should be possible to evaluate multiple configurations.
>>> > > >> > -
>>> > > >> >
>>> > > >> > The type conversion of the properties injected should be
>>> > > configurable.
>>> > > >> > -
>>> > > >> >
>>> > > >> > The value evaluated for a property (before type conversion) may
>>> > be
>>> > > >> > adaptable as well.
>>> > > >> > -
>>> > > >> >
>>> > > >> > It should be possible to observe configuration changes.
>>> > > >> >
>>> > > >> > To illustrate the points above imagine the following POJO:
>>> > > >> > Configured POJO Example
>>> > > >> >
>>> > > >> > *public* *class* *MyPojo* {
>>> > > >> > @ConfigProperty("myCurrency")
>>> > > >> > @DefaultValue("CHF") // use as default
>>> > > >> > @WithLoadingPolicy(LoadingPolicy.INITIAL) // load the value
>>> only
>>> > > >> > once (no reinjection)
>>> > > >> > *private* *String* currency;
>>> > > >> >
>>> > > >> > @ConfigProperty("myCurrencyRate")
>>> > > >> > *private* *Long* currencyRate;
>>> > > >> >
>>> > > >> > @ConfigProperty // evaluates to
>>> > > >> > key=<fieldName>="fullRate"
>>> > > >> > @ConfigProperty("fallback.property")
>>> > > >> > @WithConfig("default")
>>> > > >> > @WithConfig("moduleConfig");
>>> > > >> > *private* *BigDecimal* fullRate;
>>> > > >> >
>>> > > >> > // Configuration method
>>> > > >> > *void* setStartup(@ConfigProperty *boolean* startup,
>>> > > >> > @ConfigProperty("componentName") @WithConfig("module1")
>>> > > >> > @DefaultValue("N/A") *String* compName){
>>> > > >> > ...
>>> > > >> > }
>>> > > >> >
>>> > > >>
>>> > > >> I would put default value in @ConfigProperty to avoid
>>> > > >> TooMuchAnnotationsException
>>> > > >> @WithConfig({}) for the same reason or even in
>>> > @ConfigProperty(configs =
>>> > > >> {})?
>>> > > >>
>>> > > >
>>> > > > *For configs, we can add them to the property annotation. Adding the
>>> > > > default values IMO makes less sense, because you want to define the
>>> > > default
>>> > > > value only once, whereas you can lookup multiple properties...*
>>> > > >
>>> > > >
>>> > > >
>>> > > >> > // Configuration method
>>> > > >> > @ConfigProperty("componentName")
>>> > > >> > @WithConfig("module1")
>>> > > >> > @DefaultValue("N/A")
>>> > > >> > *private* *void* setComponentName(*String* compName){
>>> > > >> > ...
>>> > > >> > }
>>> > > >> >
>>> > > >> > // Configuration listener method, defining which properties to
>>> > > listen
>>> > > >> for
>>> > > >> > @ConfigChanges
>>> > > >> > @ConfigProperty("componentName")
>>> > > >> > *private* *void* setComponentName(ConfigChange change){
>>> > > >> > ...
>>> > > >> > }
>>> > > >> >
>>> > > >> > }
>>> > > >> >
>>> > > >> > The instance then can be passed for being configured:
>>> > > >> > Configuring a POJO
>>> > > >> >
>>> > > >> > MyPojo instance = *new*
>>> > MyPojo();*Configuration*.configure(instance);
>>> > > >> >
>>> > > >>
>>> > > >> I'd use "bind" keyword since you don't configure the instance, just
>>> > > >> you map the config on it no?
>>> > > >>
>>> > > >
>>> > > > *IMO users get more confused with bind. Lets see, what others
>>> think...
>>> > > ;)*
>>> > > >
>>> > > >
>>> > > >
>>> > > >> > This will configure all values according to the load policies
>>> (by
>>> > > >> default
>>> > > >> > LoadPolicy.INITIAL). Depending on the listeners present and the
>>> > > >> properties
>>> > > >> > injected Tamaya will keep weak references to the bean and the
>>> > current
>>> > > >> > environment, so it can be determined, when configuration changes
>>> > must
>>> > > be
>>> > > >> > published into the bean.
>>> > > >>
>>> > > >> Would hide it behind DynamicValue cause in some case you'll not be
>>> > > >> able to do it very well, would also allow to add some useful methods
>>> > > >> like hasChanged().
>>> > > >>
>>> > > >
>>> > > > *Hmm, I start to feel some sympathies for the DynamicValue ... *
>>> > > >
>>> > > >>
>>> > > >> > Feel free to comment or ask questions ;)
>>> > > >> >
>>> > > >> > Best,
>>> > > >> > 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*
>>> > > >>
>>> > > >
>>> > > >
>>> > > > --
>>> > > > *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: UC: Configuration Injection (SE)
Posted by "Tresch, Anatole " <an...@credit-suisse.com>.
So your idea is to add more complex configuration structures, e.g. JSON into a value and therefore have the possibility to serialize back changes, done to the config...
We will have to add that use case. It would also simplify supporting complex datastructures like collections, etc.
-----Original Message-----
From: Romain Manni-Bucau [mailto:rmannibucau@gmail.com]
Sent: Donnerstag, 18. Dezember 2014 09:21
To: dev@tamaya.incubator.apache.org
Subject: Re: UC: Configuration Injection (SE)
using pseudo code to make it shorter:
public class MyConfig {
@Config(...)
@Codec(deserializer = JSonDeserializer.class, serializer =
JSonSerializer.class)
MySubConfig sub;
}
config could then be foo = {"a":"b",...} and MySubConfig = { String b;... }.
Until now nothing needing all this stuff but now suppose I modify sub
during app lifecycle, how do I store modifications?
What I would avoid is to 100% rely on impls (ie I cast my Source and
use its store method for instance).
Would be great to be symmetric :)
Romain Manni-Bucau
@rmannibucau
http://www.tomitribe.com
http://rmannibucau.wordpress.com
https://github.com/rmannibucau
2014-12-18 9:15 GMT+01:00 Anatole Tresch <at...@gmail.com>:
> I dont see the uc for backserialization. For serialization normally only
> Map<String,String> are serialized/deserislized as internal representation.
> this the usecase for 'freezing' configs.
>
> What was your isea?
>
> Romain Manni-Bucau <rm...@gmail.com> schrieb am Do., 18. Dez. 2014 um
> 08:36:
>
>> Great. So we dont propose the opposite yet? T -> String. Idea would be to
>> be able to serialze back the config somewhere.
>> Le 18 déc. 2014 04:45, "Anatole Tresch" <at...@gmail.com> a écrit :
>>
>> > Its
>> >
>> > @FunctionalInterface
>> > Public interface PropertyAdapter<T>{
>> > Public T adapt(String value);
>> > }
>> >
>> > So extremly simple but powerful...
>> > Romain Manni-Bucau <rm...@gmail.com> schrieb am Do., 18. Dez. 2014
>> > um
>> > 01:46:
>> >
>> > > PropertyAdapter from the JVM? If so clearly -1, it is slow and not
>> > > usable @runtime (only valuable during bootstrap IMO).
>> > >
>> > > In Johnzon I wanted to do it as well, found it super sexy, then I
>> > > benched...totally not usable if the config can be used "often" like it
>> > > will for sure with CDI and potentially for each request (typical
>> > > @RequestScoped). Only solution would be to cache computed values which
>> > > can then be wrong if computation depends on the context which is
>> > > totally valuable (depending the logged user for some cases for
>> > > instance).
>> > >
>> > > In term of API having Serializer, Deserilizer, Codec (= Serializer +
>> > > Deserializer) interfaces can make sense since in some cases you'll
>> > > just want to deserilize, no?
>> > >
>> > >
>> > >
>> > >
>> > > Romain Manni-Bucau
>> > > @rmannibucau
>> > > http://www.tomitribe.com
>> > > http://rmannibucau.wordpress.com
>> > > https://github.com/rmannibucau
>> > >
>> > >
>> > > 2014-12-18 1:30 GMT+01:00 Anatole Tresch <at...@gmail.com>:
>> > > > *Hi Romain*
>> > > >
>> > > > *short inline (before I take some sleep..)...*
>> > > >
>> > > > *Anatole*
>> > > >
>> > > >
>> > > > 2014-12-18 0:13 GMT+01:00 Romain Manni-Bucau <rmannibucau@gmail.com
>> >:
>> > > >>
>> > > >> 2014-12-18 0:05 GMT+01:00 Anatole Tresch <at...@gmail.com>:
>> > > >> > Hi all
>> > > >> > I would like to present another use case: injection of
>> configuration
>> > > in
>> > > >> SE
>> > > >> > (EE should be almost similar):
>> > > >> >
>> > > >> > Automatic Configuration (Configuration Injection)
>> > > >> >
>> > > >> > Tamaya must provide a feature for automatic configuration, where
>> > > >> properties
>> > > >> > of a class or methods can be annotated:
>> > > >> >
>> > > >> > -
>> > > >> >
>> > > >> > Hereby the lifecycle of the instances configured should not be
>> > > managed
>> > > >> > by Tamaya.
>> > > >> > -
>> > > >> >
>> > > >> > String as well as other types should be supported.
>> > > >> > -
>> > > >> >
>> > > >>
>> > > >> We should limit to types we can handle to start I think (until we
>> > > >> finished other IoC integration to keep it aligned to start)
>> > > >>
>> > > >> So file, string, primitive wrappers, uri, inetaddress...
>> > > >
>> > > >
>> > > > *Disagree. The mechanism is already in place and working well.
>> > > > PropertyAdapter is a generic functional interface.*
>> > > > *I would not want to throw it away. The only thing, I see is really
>> > worth
>> > > > discussing are other aspects, like meta-information, and
>> > > > multi-values/collection support. *
>> > > >
>> > > >
>> > > >> > It must be possible to define default values to be used, if no
>> > > valid
>> > > >> > value is present.
>> > > >> > -
>> > > >> >
>> > > >> > It must be possible to define dynamic expressions, at least for
>> > > >> default
>> > > >> > values.
>> > > >> > -
>> > > >> >
>> > > >> > The values configured can be reinjected, if the underlying
>> > > >> configuration
>> > > >> > changes. This should also be the case fir final classes, such
>> as
>> > > >> Strings.
>> > > >> > -
>> > > >> >
>> > > >>
>> > > >> -1, I would introduce DynamicValue<String> (or any generic) for it
>> > > >>
>> > > >
>> > > > *Other opinions? *
>> > > >
>> > > >>
>> > > >> > Reinjection should be controllable by an loading policy.
>> > > >> > -
>> > > >> >
>> > > >> > It should be possible to evaluate multiple keys, e.g. current
>> > keys,
>> > > >> and
>> > > >> > as a backup deprecated keys from former application releases.
>> > > >> > -
>> > > >> >
>> > > >> > It should be possible to evaluate multiple configurations.
>> > > >> > -
>> > > >> >
>> > > >> > The type conversion of the properties injected should be
>> > > configurable.
>> > > >> > -
>> > > >> >
>> > > >> > The value evaluated for a property (before type conversion) may
>> > be
>> > > >> > adaptable as well.
>> > > >> > -
>> > > >> >
>> > > >> > It should be possible to observe configuration changes.
>> > > >> >
>> > > >> > To illustrate the points above imagine the following POJO:
>> > > >> > Configured POJO Example
>> > > >> >
>> > > >> > *public* *class* *MyPojo* {
>> > > >> > @ConfigProperty("myCurrency")
>> > > >> > @DefaultValue("CHF") // use as default
>> > > >> > @WithLoadingPolicy(LoadingPolicy.INITIAL) // load the value
>> only
>> > > >> > once (no reinjection)
>> > > >> > *private* *String* currency;
>> > > >> >
>> > > >> > @ConfigProperty("myCurrencyRate")
>> > > >> > *private* *Long* currencyRate;
>> > > >> >
>> > > >> > @ConfigProperty // evaluates to
>> > > >> > key=<fieldName>="fullRate"
>> > > >> > @ConfigProperty("fallback.property")
>> > > >> > @WithConfig("default")
>> > > >> > @WithConfig("moduleConfig");
>> > > >> > *private* *BigDecimal* fullRate;
>> > > >> >
>> > > >> > // Configuration method
>> > > >> > *void* setStartup(@ConfigProperty *boolean* startup,
>> > > >> > @ConfigProperty("componentName") @WithConfig("module1")
>> > > >> > @DefaultValue("N/A") *String* compName){
>> > > >> > ...
>> > > >> > }
>> > > >> >
>> > > >>
>> > > >> I would put default value in @ConfigProperty to avoid
>> > > >> TooMuchAnnotationsException
>> > > >> @WithConfig({}) for the same reason or even in
>> > @ConfigProperty(configs =
>> > > >> {})?
>> > > >>
>> > > >
>> > > > *For configs, we can add them to the property annotation. Adding the
>> > > > default values IMO makes less sense, because you want to define the
>> > > default
>> > > > value only once, whereas you can lookup multiple properties...*
>> > > >
>> > > >
>> > > >
>> > > >> > // Configuration method
>> > > >> > @ConfigProperty("componentName")
>> > > >> > @WithConfig("module1")
>> > > >> > @DefaultValue("N/A")
>> > > >> > *private* *void* setComponentName(*String* compName){
>> > > >> > ...
>> > > >> > }
>> > > >> >
>> > > >> > // Configuration listener method, defining which properties to
>> > > listen
>> > > >> for
>> > > >> > @ConfigChanges
>> > > >> > @ConfigProperty("componentName")
>> > > >> > *private* *void* setComponentName(ConfigChange change){
>> > > >> > ...
>> > > >> > }
>> > > >> >
>> > > >> > }
>> > > >> >
>> > > >> > The instance then can be passed for being configured:
>> > > >> > Configuring a POJO
>> > > >> >
>> > > >> > MyPojo instance = *new*
>> > MyPojo();*Configuration*.configure(instance);
>> > > >> >
>> > > >>
>> > > >> I'd use "bind" keyword since you don't configure the instance, just
>> > > >> you map the config on it no?
>> > > >>
>> > > >
>> > > > *IMO users get more confused with bind. Lets see, what others
>> think...
>> > > ;)*
>> > > >
>> > > >
>> > > >
>> > > >> > This will configure all values according to the load policies
>> (by
>> > > >> default
>> > > >> > LoadPolicy.INITIAL). Depending on the listeners present and the
>> > > >> properties
>> > > >> > injected Tamaya will keep weak references to the bean and the
>> > current
>> > > >> > environment, so it can be determined, when configuration changes
>> > must
>> > > be
>> > > >> > published into the bean.
>> > > >>
>> > > >> Would hide it behind DynamicValue cause in some case you'll not be
>> > > >> able to do it very well, would also allow to add some useful methods
>> > > >> like hasChanged().
>> > > >>
>> > > >
>> > > > *Hmm, I start to feel some sympathies for the DynamicValue ... *
>> > > >
>> > > >>
>> > > >> > Feel free to comment or ask questions ;)
>> > > >> >
>> > > >> > Best,
>> > > >> > 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*
>> > > >>
>> > > >
>> > > >
>> > > > --
>> > > > *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: UC: Configuration Injection (SE)
Posted by Romain Manni-Bucau <rm...@gmail.com>.
using pseudo code to make it shorter:
public class MyConfig {
@Config(...)
@Codec(deserializer = JSonDeserializer.class, serializer =
JSonSerializer.class)
MySubConfig sub;
}
config could then be foo = {"a":"b",...} and MySubConfig = { String b;... }.
Until now nothing needing all this stuff but now suppose I modify sub
during app lifecycle, how do I store modifications?
What I would avoid is to 100% rely on impls (ie I cast my Source and
use its store method for instance).
Would be great to be symmetric :)
Romain Manni-Bucau
@rmannibucau
http://www.tomitribe.com
http://rmannibucau.wordpress.com
https://github.com/rmannibucau
2014-12-18 9:15 GMT+01:00 Anatole Tresch <at...@gmail.com>:
> I dont see the uc for backserialization. For serialization normally only
> Map<String,String> are serialized/deserislized as internal representation.
> this the usecase for 'freezing' configs.
>
> What was your isea?
>
> Romain Manni-Bucau <rm...@gmail.com> schrieb am Do., 18. Dez. 2014 um
> 08:36:
>
>> Great. So we dont propose the opposite yet? T -> String. Idea would be to
>> be able to serialze back the config somewhere.
>> Le 18 déc. 2014 04:45, "Anatole Tresch" <at...@gmail.com> a écrit :
>>
>> > Its
>> >
>> > @FunctionalInterface
>> > Public interface PropertyAdapter<T>{
>> > Public T adapt(String value);
>> > }
>> >
>> > So extremly simple but powerful...
>> > Romain Manni-Bucau <rm...@gmail.com> schrieb am Do., 18. Dez. 2014
>> > um
>> > 01:46:
>> >
>> > > PropertyAdapter from the JVM? If so clearly -1, it is slow and not
>> > > usable @runtime (only valuable during bootstrap IMO).
>> > >
>> > > In Johnzon I wanted to do it as well, found it super sexy, then I
>> > > benched...totally not usable if the config can be used "often" like it
>> > > will for sure with CDI and potentially for each request (typical
>> > > @RequestScoped). Only solution would be to cache computed values which
>> > > can then be wrong if computation depends on the context which is
>> > > totally valuable (depending the logged user for some cases for
>> > > instance).
>> > >
>> > > In term of API having Serializer, Deserilizer, Codec (= Serializer +
>> > > Deserializer) interfaces can make sense since in some cases you'll
>> > > just want to deserilize, no?
>> > >
>> > >
>> > >
>> > >
>> > > Romain Manni-Bucau
>> > > @rmannibucau
>> > > http://www.tomitribe.com
>> > > http://rmannibucau.wordpress.com
>> > > https://github.com/rmannibucau
>> > >
>> > >
>> > > 2014-12-18 1:30 GMT+01:00 Anatole Tresch <at...@gmail.com>:
>> > > > *Hi Romain*
>> > > >
>> > > > *short inline (before I take some sleep..)...*
>> > > >
>> > > > *Anatole*
>> > > >
>> > > >
>> > > > 2014-12-18 0:13 GMT+01:00 Romain Manni-Bucau <rmannibucau@gmail.com
>> >:
>> > > >>
>> > > >> 2014-12-18 0:05 GMT+01:00 Anatole Tresch <at...@gmail.com>:
>> > > >> > Hi all
>> > > >> > I would like to present another use case: injection of
>> configuration
>> > > in
>> > > >> SE
>> > > >> > (EE should be almost similar):
>> > > >> >
>> > > >> > Automatic Configuration (Configuration Injection)
>> > > >> >
>> > > >> > Tamaya must provide a feature for automatic configuration, where
>> > > >> properties
>> > > >> > of a class or methods can be annotated:
>> > > >> >
>> > > >> > -
>> > > >> >
>> > > >> > Hereby the lifecycle of the instances configured should not be
>> > > managed
>> > > >> > by Tamaya.
>> > > >> > -
>> > > >> >
>> > > >> > String as well as other types should be supported.
>> > > >> > -
>> > > >> >
>> > > >>
>> > > >> We should limit to types we can handle to start I think (until we
>> > > >> finished other IoC integration to keep it aligned to start)
>> > > >>
>> > > >> So file, string, primitive wrappers, uri, inetaddress...
>> > > >
>> > > >
>> > > > *Disagree. The mechanism is already in place and working well.
>> > > > PropertyAdapter is a generic functional interface.*
>> > > > *I would not want to throw it away. The only thing, I see is really
>> > worth
>> > > > discussing are other aspects, like meta-information, and
>> > > > multi-values/collection support. *
>> > > >
>> > > >
>> > > >> > It must be possible to define default values to be used, if no
>> > > valid
>> > > >> > value is present.
>> > > >> > -
>> > > >> >
>> > > >> > It must be possible to define dynamic expressions, at least for
>> > > >> default
>> > > >> > values.
>> > > >> > -
>> > > >> >
>> > > >> > The values configured can be reinjected, if the underlying
>> > > >> configuration
>> > > >> > changes. This should also be the case fir final classes, such
>> as
>> > > >> Strings.
>> > > >> > -
>> > > >> >
>> > > >>
>> > > >> -1, I would introduce DynamicValue<String> (or any generic) for it
>> > > >>
>> > > >
>> > > > *Other opinions? *
>> > > >
>> > > >>
>> > > >> > Reinjection should be controllable by an loading policy.
>> > > >> > -
>> > > >> >
>> > > >> > It should be possible to evaluate multiple keys, e.g. current
>> > keys,
>> > > >> and
>> > > >> > as a backup deprecated keys from former application releases.
>> > > >> > -
>> > > >> >
>> > > >> > It should be possible to evaluate multiple configurations.
>> > > >> > -
>> > > >> >
>> > > >> > The type conversion of the properties injected should be
>> > > configurable.
>> > > >> > -
>> > > >> >
>> > > >> > The value evaluated for a property (before type conversion) may
>> > be
>> > > >> > adaptable as well.
>> > > >> > -
>> > > >> >
>> > > >> > It should be possible to observe configuration changes.
>> > > >> >
>> > > >> > To illustrate the points above imagine the following POJO:
>> > > >> > Configured POJO Example
>> > > >> >
>> > > >> > *public* *class* *MyPojo* {
>> > > >> > @ConfigProperty("myCurrency")
>> > > >> > @DefaultValue("CHF") // use as default
>> > > >> > @WithLoadingPolicy(LoadingPolicy.INITIAL) // load the value
>> only
>> > > >> > once (no reinjection)
>> > > >> > *private* *String* currency;
>> > > >> >
>> > > >> > @ConfigProperty("myCurrencyRate")
>> > > >> > *private* *Long* currencyRate;
>> > > >> >
>> > > >> > @ConfigProperty // evaluates to
>> > > >> > key=<fieldName>="fullRate"
>> > > >> > @ConfigProperty("fallback.property")
>> > > >> > @WithConfig("default")
>> > > >> > @WithConfig("moduleConfig");
>> > > >> > *private* *BigDecimal* fullRate;
>> > > >> >
>> > > >> > // Configuration method
>> > > >> > *void* setStartup(@ConfigProperty *boolean* startup,
>> > > >> > @ConfigProperty("componentName") @WithConfig("module1")
>> > > >> > @DefaultValue("N/A") *String* compName){
>> > > >> > ...
>> > > >> > }
>> > > >> >
>> > > >>
>> > > >> I would put default value in @ConfigProperty to avoid
>> > > >> TooMuchAnnotationsException
>> > > >> @WithConfig({}) for the same reason or even in
>> > @ConfigProperty(configs =
>> > > >> {})?
>> > > >>
>> > > >
>> > > > *For configs, we can add them to the property annotation. Adding the
>> > > > default values IMO makes less sense, because you want to define the
>> > > default
>> > > > value only once, whereas you can lookup multiple properties...*
>> > > >
>> > > >
>> > > >
>> > > >> > // Configuration method
>> > > >> > @ConfigProperty("componentName")
>> > > >> > @WithConfig("module1")
>> > > >> > @DefaultValue("N/A")
>> > > >> > *private* *void* setComponentName(*String* compName){
>> > > >> > ...
>> > > >> > }
>> > > >> >
>> > > >> > // Configuration listener method, defining which properties to
>> > > listen
>> > > >> for
>> > > >> > @ConfigChanges
>> > > >> > @ConfigProperty("componentName")
>> > > >> > *private* *void* setComponentName(ConfigChange change){
>> > > >> > ...
>> > > >> > }
>> > > >> >
>> > > >> > }
>> > > >> >
>> > > >> > The instance then can be passed for being configured:
>> > > >> > Configuring a POJO
>> > > >> >
>> > > >> > MyPojo instance = *new*
>> > MyPojo();*Configuration*.configure(instance);
>> > > >> >
>> > > >>
>> > > >> I'd use "bind" keyword since you don't configure the instance, just
>> > > >> you map the config on it no?
>> > > >>
>> > > >
>> > > > *IMO users get more confused with bind. Lets see, what others
>> think...
>> > > ;)*
>> > > >
>> > > >
>> > > >
>> > > >> > This will configure all values according to the load policies
>> (by
>> > > >> default
>> > > >> > LoadPolicy.INITIAL). Depending on the listeners present and the
>> > > >> properties
>> > > >> > injected Tamaya will keep weak references to the bean and the
>> > current
>> > > >> > environment, so it can be determined, when configuration changes
>> > must
>> > > be
>> > > >> > published into the bean.
>> > > >>
>> > > >> Would hide it behind DynamicValue cause in some case you'll not be
>> > > >> able to do it very well, would also allow to add some useful methods
>> > > >> like hasChanged().
>> > > >>
>> > > >
>> > > > *Hmm, I start to feel some sympathies for the DynamicValue ... *
>> > > >
>> > > >>
>> > > >> > Feel free to comment or ask questions ;)
>> > > >> >
>> > > >> > Best,
>> > > >> > 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*
>> > > >>
>> > > >
>> > > >
>> > > > --
>> > > > *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: UC: Configuration Injection (SE)
Posted by Anatole Tresch <at...@gmail.com>.
I dont see the uc for backserialization. For serialization normally only
Map<String,String> are serialized/deserislized as internal representation.
this the usecase for 'freezing' configs.
What was your isea?
Romain Manni-Bucau <rm...@gmail.com> schrieb am Do., 18. Dez. 2014 um
08:36:
> Great. So we dont propose the opposite yet? T -> String. Idea would be to
> be able to serialze back the config somewhere.
> Le 18 déc. 2014 04:45, "Anatole Tresch" <at...@gmail.com> a écrit :
>
> > Its
> >
> > @FunctionalInterface
> > Public interface PropertyAdapter<T>{
> > Public T adapt(String value);
> > }
> >
> > So extremly simple but powerful...
> > Romain Manni-Bucau <rm...@gmail.com> schrieb am Do., 18. Dez. 2014
> > um
> > 01:46:
> >
> > > PropertyAdapter from the JVM? If so clearly -1, it is slow and not
> > > usable @runtime (only valuable during bootstrap IMO).
> > >
> > > In Johnzon I wanted to do it as well, found it super sexy, then I
> > > benched...totally not usable if the config can be used "often" like it
> > > will for sure with CDI and potentially for each request (typical
> > > @RequestScoped). Only solution would be to cache computed values which
> > > can then be wrong if computation depends on the context which is
> > > totally valuable (depending the logged user for some cases for
> > > instance).
> > >
> > > In term of API having Serializer, Deserilizer, Codec (= Serializer +
> > > Deserializer) interfaces can make sense since in some cases you'll
> > > just want to deserilize, no?
> > >
> > >
> > >
> > >
> > > Romain Manni-Bucau
> > > @rmannibucau
> > > http://www.tomitribe.com
> > > http://rmannibucau.wordpress.com
> > > https://github.com/rmannibucau
> > >
> > >
> > > 2014-12-18 1:30 GMT+01:00 Anatole Tresch <at...@gmail.com>:
> > > > *Hi Romain*
> > > >
> > > > *short inline (before I take some sleep..)...*
> > > >
> > > > *Anatole*
> > > >
> > > >
> > > > 2014-12-18 0:13 GMT+01:00 Romain Manni-Bucau <rmannibucau@gmail.com
> >:
> > > >>
> > > >> 2014-12-18 0:05 GMT+01:00 Anatole Tresch <at...@gmail.com>:
> > > >> > Hi all
> > > >> > I would like to present another use case: injection of
> configuration
> > > in
> > > >> SE
> > > >> > (EE should be almost similar):
> > > >> >
> > > >> > Automatic Configuration (Configuration Injection)
> > > >> >
> > > >> > Tamaya must provide a feature for automatic configuration, where
> > > >> properties
> > > >> > of a class or methods can be annotated:
> > > >> >
> > > >> > -
> > > >> >
> > > >> > Hereby the lifecycle of the instances configured should not be
> > > managed
> > > >> > by Tamaya.
> > > >> > -
> > > >> >
> > > >> > String as well as other types should be supported.
> > > >> > -
> > > >> >
> > > >>
> > > >> We should limit to types we can handle to start I think (until we
> > > >> finished other IoC integration to keep it aligned to start)
> > > >>
> > > >> So file, string, primitive wrappers, uri, inetaddress...
> > > >
> > > >
> > > > *Disagree. The mechanism is already in place and working well.
> > > > PropertyAdapter is a generic functional interface.*
> > > > *I would not want to throw it away. The only thing, I see is really
> > worth
> > > > discussing are other aspects, like meta-information, and
> > > > multi-values/collection support. *
> > > >
> > > >
> > > >> > It must be possible to define default values to be used, if no
> > > valid
> > > >> > value is present.
> > > >> > -
> > > >> >
> > > >> > It must be possible to define dynamic expressions, at least for
> > > >> default
> > > >> > values.
> > > >> > -
> > > >> >
> > > >> > The values configured can be reinjected, if the underlying
> > > >> configuration
> > > >> > changes. This should also be the case fir final classes, such
> as
> > > >> Strings.
> > > >> > -
> > > >> >
> > > >>
> > > >> -1, I would introduce DynamicValue<String> (or any generic) for it
> > > >>
> > > >
> > > > *Other opinions? *
> > > >
> > > >>
> > > >> > Reinjection should be controllable by an loading policy.
> > > >> > -
> > > >> >
> > > >> > It should be possible to evaluate multiple keys, e.g. current
> > keys,
> > > >> and
> > > >> > as a backup deprecated keys from former application releases.
> > > >> > -
> > > >> >
> > > >> > It should be possible to evaluate multiple configurations.
> > > >> > -
> > > >> >
> > > >> > The type conversion of the properties injected should be
> > > configurable.
> > > >> > -
> > > >> >
> > > >> > The value evaluated for a property (before type conversion) may
> > be
> > > >> > adaptable as well.
> > > >> > -
> > > >> >
> > > >> > It should be possible to observe configuration changes.
> > > >> >
> > > >> > To illustrate the points above imagine the following POJO:
> > > >> > Configured POJO Example
> > > >> >
> > > >> > *public* *class* *MyPojo* {
> > > >> > @ConfigProperty("myCurrency")
> > > >> > @DefaultValue("CHF") // use as default
> > > >> > @WithLoadingPolicy(LoadingPolicy.INITIAL) // load the value
> only
> > > >> > once (no reinjection)
> > > >> > *private* *String* currency;
> > > >> >
> > > >> > @ConfigProperty("myCurrencyRate")
> > > >> > *private* *Long* currencyRate;
> > > >> >
> > > >> > @ConfigProperty // evaluates to
> > > >> > key=<fieldName>="fullRate"
> > > >> > @ConfigProperty("fallback.property")
> > > >> > @WithConfig("default")
> > > >> > @WithConfig("moduleConfig");
> > > >> > *private* *BigDecimal* fullRate;
> > > >> >
> > > >> > // Configuration method
> > > >> > *void* setStartup(@ConfigProperty *boolean* startup,
> > > >> > @ConfigProperty("componentName") @WithConfig("module1")
> > > >> > @DefaultValue("N/A") *String* compName){
> > > >> > ...
> > > >> > }
> > > >> >
> > > >>
> > > >> I would put default value in @ConfigProperty to avoid
> > > >> TooMuchAnnotationsException
> > > >> @WithConfig({}) for the same reason or even in
> > @ConfigProperty(configs =
> > > >> {})?
> > > >>
> > > >
> > > > *For configs, we can add them to the property annotation. Adding the
> > > > default values IMO makes less sense, because you want to define the
> > > default
> > > > value only once, whereas you can lookup multiple properties...*
> > > >
> > > >
> > > >
> > > >> > // Configuration method
> > > >> > @ConfigProperty("componentName")
> > > >> > @WithConfig("module1")
> > > >> > @DefaultValue("N/A")
> > > >> > *private* *void* setComponentName(*String* compName){
> > > >> > ...
> > > >> > }
> > > >> >
> > > >> > // Configuration listener method, defining which properties to
> > > listen
> > > >> for
> > > >> > @ConfigChanges
> > > >> > @ConfigProperty("componentName")
> > > >> > *private* *void* setComponentName(ConfigChange change){
> > > >> > ...
> > > >> > }
> > > >> >
> > > >> > }
> > > >> >
> > > >> > The instance then can be passed for being configured:
> > > >> > Configuring a POJO
> > > >> >
> > > >> > MyPojo instance = *new*
> > MyPojo();*Configuration*.configure(instance);
> > > >> >
> > > >>
> > > >> I'd use "bind" keyword since you don't configure the instance, just
> > > >> you map the config on it no?
> > > >>
> > > >
> > > > *IMO users get more confused with bind. Lets see, what others
> think...
> > > ;)*
> > > >
> > > >
> > > >
> > > >> > This will configure all values according to the load policies
> (by
> > > >> default
> > > >> > LoadPolicy.INITIAL). Depending on the listeners present and the
> > > >> properties
> > > >> > injected Tamaya will keep weak references to the bean and the
> > current
> > > >> > environment, so it can be determined, when configuration changes
> > must
> > > be
> > > >> > published into the bean.
> > > >>
> > > >> Would hide it behind DynamicValue cause in some case you'll not be
> > > >> able to do it very well, would also allow to add some useful methods
> > > >> like hasChanged().
> > > >>
> > > >
> > > > *Hmm, I start to feel some sympathies for the DynamicValue ... *
> > > >
> > > >>
> > > >> > Feel free to comment or ask questions ;)
> > > >> >
> > > >> > Best,
> > > >> > 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*
> > > >>
> > > >
> > > >
> > > > --
> > > > *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: UC: Configuration Injection (SE)
Posted by Romain Manni-Bucau <rm...@gmail.com>.
Great. So we dont propose the opposite yet? T -> String. Idea would be to
be able to serialze back the config somewhere.
Le 18 déc. 2014 04:45, "Anatole Tresch" <at...@gmail.com> a écrit :
> Its
>
> @FunctionalInterface
> Public interface PropertyAdapter<T>{
> Public T adapt(String value);
> }
>
> So extremly simple but powerful...
> Romain Manni-Bucau <rm...@gmail.com> schrieb am Do., 18. Dez. 2014
> um
> 01:46:
>
> > PropertyAdapter from the JVM? If so clearly -1, it is slow and not
> > usable @runtime (only valuable during bootstrap IMO).
> >
> > In Johnzon I wanted to do it as well, found it super sexy, then I
> > benched...totally not usable if the config can be used "often" like it
> > will for sure with CDI and potentially for each request (typical
> > @RequestScoped). Only solution would be to cache computed values which
> > can then be wrong if computation depends on the context which is
> > totally valuable (depending the logged user for some cases for
> > instance).
> >
> > In term of API having Serializer, Deserilizer, Codec (= Serializer +
> > Deserializer) interfaces can make sense since in some cases you'll
> > just want to deserilize, no?
> >
> >
> >
> >
> > Romain Manni-Bucau
> > @rmannibucau
> > http://www.tomitribe.com
> > http://rmannibucau.wordpress.com
> > https://github.com/rmannibucau
> >
> >
> > 2014-12-18 1:30 GMT+01:00 Anatole Tresch <at...@gmail.com>:
> > > *Hi Romain*
> > >
> > > *short inline (before I take some sleep..)...*
> > >
> > > *Anatole*
> > >
> > >
> > > 2014-12-18 0:13 GMT+01:00 Romain Manni-Bucau <rm...@gmail.com>:
> > >>
> > >> 2014-12-18 0:05 GMT+01:00 Anatole Tresch <at...@gmail.com>:
> > >> > Hi all
> > >> > I would like to present another use case: injection of configuration
> > in
> > >> SE
> > >> > (EE should be almost similar):
> > >> >
> > >> > Automatic Configuration (Configuration Injection)
> > >> >
> > >> > Tamaya must provide a feature for automatic configuration, where
> > >> properties
> > >> > of a class or methods can be annotated:
> > >> >
> > >> > -
> > >> >
> > >> > Hereby the lifecycle of the instances configured should not be
> > managed
> > >> > by Tamaya.
> > >> > -
> > >> >
> > >> > String as well as other types should be supported.
> > >> > -
> > >> >
> > >>
> > >> We should limit to types we can handle to start I think (until we
> > >> finished other IoC integration to keep it aligned to start)
> > >>
> > >> So file, string, primitive wrappers, uri, inetaddress...
> > >
> > >
> > > *Disagree. The mechanism is already in place and working well.
> > > PropertyAdapter is a generic functional interface.*
> > > *I would not want to throw it away. The only thing, I see is really
> worth
> > > discussing are other aspects, like meta-information, and
> > > multi-values/collection support. *
> > >
> > >
> > >> > It must be possible to define default values to be used, if no
> > valid
> > >> > value is present.
> > >> > -
> > >> >
> > >> > It must be possible to define dynamic expressions, at least for
> > >> default
> > >> > values.
> > >> > -
> > >> >
> > >> > The values configured can be reinjected, if the underlying
> > >> configuration
> > >> > changes. This should also be the case fir final classes, such as
> > >> Strings.
> > >> > -
> > >> >
> > >>
> > >> -1, I would introduce DynamicValue<String> (or any generic) for it
> > >>
> > >
> > > *Other opinions? *
> > >
> > >>
> > >> > Reinjection should be controllable by an loading policy.
> > >> > -
> > >> >
> > >> > It should be possible to evaluate multiple keys, e.g. current
> keys,
> > >> and
> > >> > as a backup deprecated keys from former application releases.
> > >> > -
> > >> >
> > >> > It should be possible to evaluate multiple configurations.
> > >> > -
> > >> >
> > >> > The type conversion of the properties injected should be
> > configurable.
> > >> > -
> > >> >
> > >> > The value evaluated for a property (before type conversion) may
> be
> > >> > adaptable as well.
> > >> > -
> > >> >
> > >> > It should be possible to observe configuration changes.
> > >> >
> > >> > To illustrate the points above imagine the following POJO:
> > >> > Configured POJO Example
> > >> >
> > >> > *public* *class* *MyPojo* {
> > >> > @ConfigProperty("myCurrency")
> > >> > @DefaultValue("CHF") // use as default
> > >> > @WithLoadingPolicy(LoadingPolicy.INITIAL) // load the value only
> > >> > once (no reinjection)
> > >> > *private* *String* currency;
> > >> >
> > >> > @ConfigProperty("myCurrencyRate")
> > >> > *private* *Long* currencyRate;
> > >> >
> > >> > @ConfigProperty // evaluates to
> > >> > key=<fieldName>="fullRate"
> > >> > @ConfigProperty("fallback.property")
> > >> > @WithConfig("default")
> > >> > @WithConfig("moduleConfig");
> > >> > *private* *BigDecimal* fullRate;
> > >> >
> > >> > // Configuration method
> > >> > *void* setStartup(@ConfigProperty *boolean* startup,
> > >> > @ConfigProperty("componentName") @WithConfig("module1")
> > >> > @DefaultValue("N/A") *String* compName){
> > >> > ...
> > >> > }
> > >> >
> > >>
> > >> I would put default value in @ConfigProperty to avoid
> > >> TooMuchAnnotationsException
> > >> @WithConfig({}) for the same reason or even in
> @ConfigProperty(configs =
> > >> {})?
> > >>
> > >
> > > *For configs, we can add them to the property annotation. Adding the
> > > default values IMO makes less sense, because you want to define the
> > default
> > > value only once, whereas you can lookup multiple properties...*
> > >
> > >
> > >
> > >> > // Configuration method
> > >> > @ConfigProperty("componentName")
> > >> > @WithConfig("module1")
> > >> > @DefaultValue("N/A")
> > >> > *private* *void* setComponentName(*String* compName){
> > >> > ...
> > >> > }
> > >> >
> > >> > // Configuration listener method, defining which properties to
> > listen
> > >> for
> > >> > @ConfigChanges
> > >> > @ConfigProperty("componentName")
> > >> > *private* *void* setComponentName(ConfigChange change){
> > >> > ...
> > >> > }
> > >> >
> > >> > }
> > >> >
> > >> > The instance then can be passed for being configured:
> > >> > Configuring a POJO
> > >> >
> > >> > MyPojo instance = *new*
> MyPojo();*Configuration*.configure(instance);
> > >> >
> > >>
> > >> I'd use "bind" keyword since you don't configure the instance, just
> > >> you map the config on it no?
> > >>
> > >
> > > *IMO users get more confused with bind. Lets see, what others think...
> > ;)*
> > >
> > >
> > >
> > >> > This will configure all values according to the load policies (by
> > >> default
> > >> > LoadPolicy.INITIAL). Depending on the listeners present and the
> > >> properties
> > >> > injected Tamaya will keep weak references to the bean and the
> current
> > >> > environment, so it can be determined, when configuration changes
> must
> > be
> > >> > published into the bean.
> > >>
> > >> Would hide it behind DynamicValue cause in some case you'll not be
> > >> able to do it very well, would also allow to add some useful methods
> > >> like hasChanged().
> > >>
> > >
> > > *Hmm, I start to feel some sympathies for the DynamicValue ... *
> > >
> > >>
> > >> > Feel free to comment or ask questions ;)
> > >> >
> > >> > Best,
> > >> > 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*
> > >>
> > >
> > >
> > > --
> > > *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: UC: Configuration Injection (SE)
Posted by Anatole Tresch <at...@gmail.com>.
Its
@FunctionalInterface
Public interface PropertyAdapter<T>{
Public T adapt(String value);
}
So extremly simple but powerful...
Romain Manni-Bucau <rm...@gmail.com> schrieb am Do., 18. Dez. 2014 um
01:46:
> PropertyAdapter from the JVM? If so clearly -1, it is slow and not
> usable @runtime (only valuable during bootstrap IMO).
>
> In Johnzon I wanted to do it as well, found it super sexy, then I
> benched...totally not usable if the config can be used "often" like it
> will for sure with CDI and potentially for each request (typical
> @RequestScoped). Only solution would be to cache computed values which
> can then be wrong if computation depends on the context which is
> totally valuable (depending the logged user for some cases for
> instance).
>
> In term of API having Serializer, Deserilizer, Codec (= Serializer +
> Deserializer) interfaces can make sense since in some cases you'll
> just want to deserilize, no?
>
>
>
>
> Romain Manni-Bucau
> @rmannibucau
> http://www.tomitribe.com
> http://rmannibucau.wordpress.com
> https://github.com/rmannibucau
>
>
> 2014-12-18 1:30 GMT+01:00 Anatole Tresch <at...@gmail.com>:
> > *Hi Romain*
> >
> > *short inline (before I take some sleep..)...*
> >
> > *Anatole*
> >
> >
> > 2014-12-18 0:13 GMT+01:00 Romain Manni-Bucau <rm...@gmail.com>:
> >>
> >> 2014-12-18 0:05 GMT+01:00 Anatole Tresch <at...@gmail.com>:
> >> > Hi all
> >> > I would like to present another use case: injection of configuration
> in
> >> SE
> >> > (EE should be almost similar):
> >> >
> >> > Automatic Configuration (Configuration Injection)
> >> >
> >> > Tamaya must provide a feature for automatic configuration, where
> >> properties
> >> > of a class or methods can be annotated:
> >> >
> >> > -
> >> >
> >> > Hereby the lifecycle of the instances configured should not be
> managed
> >> > by Tamaya.
> >> > -
> >> >
> >> > String as well as other types should be supported.
> >> > -
> >> >
> >>
> >> We should limit to types we can handle to start I think (until we
> >> finished other IoC integration to keep it aligned to start)
> >>
> >> So file, string, primitive wrappers, uri, inetaddress...
> >
> >
> > *Disagree. The mechanism is already in place and working well.
> > PropertyAdapter is a generic functional interface.*
> > *I would not want to throw it away. The only thing, I see is really worth
> > discussing are other aspects, like meta-information, and
> > multi-values/collection support. *
> >
> >
> >> > It must be possible to define default values to be used, if no
> valid
> >> > value is present.
> >> > -
> >> >
> >> > It must be possible to define dynamic expressions, at least for
> >> default
> >> > values.
> >> > -
> >> >
> >> > The values configured can be reinjected, if the underlying
> >> configuration
> >> > changes. This should also be the case fir final classes, such as
> >> Strings.
> >> > -
> >> >
> >>
> >> -1, I would introduce DynamicValue<String> (or any generic) for it
> >>
> >
> > *Other opinions? *
> >
> >>
> >> > Reinjection should be controllable by an loading policy.
> >> > -
> >> >
> >> > It should be possible to evaluate multiple keys, e.g. current keys,
> >> and
> >> > as a backup deprecated keys from former application releases.
> >> > -
> >> >
> >> > It should be possible to evaluate multiple configurations.
> >> > -
> >> >
> >> > The type conversion of the properties injected should be
> configurable.
> >> > -
> >> >
> >> > The value evaluated for a property (before type conversion) may be
> >> > adaptable as well.
> >> > -
> >> >
> >> > It should be possible to observe configuration changes.
> >> >
> >> > To illustrate the points above imagine the following POJO:
> >> > Configured POJO Example
> >> >
> >> > *public* *class* *MyPojo* {
> >> > @ConfigProperty("myCurrency")
> >> > @DefaultValue("CHF") // use as default
> >> > @WithLoadingPolicy(LoadingPolicy.INITIAL) // load the value only
> >> > once (no reinjection)
> >> > *private* *String* currency;
> >> >
> >> > @ConfigProperty("myCurrencyRate")
> >> > *private* *Long* currencyRate;
> >> >
> >> > @ConfigProperty // evaluates to
> >> > key=<fieldName>="fullRate"
> >> > @ConfigProperty("fallback.property")
> >> > @WithConfig("default")
> >> > @WithConfig("moduleConfig");
> >> > *private* *BigDecimal* fullRate;
> >> >
> >> > // Configuration method
> >> > *void* setStartup(@ConfigProperty *boolean* startup,
> >> > @ConfigProperty("componentName") @WithConfig("module1")
> >> > @DefaultValue("N/A") *String* compName){
> >> > ...
> >> > }
> >> >
> >>
> >> I would put default value in @ConfigProperty to avoid
> >> TooMuchAnnotationsException
> >> @WithConfig({}) for the same reason or even in @ConfigProperty(configs =
> >> {})?
> >>
> >
> > *For configs, we can add them to the property annotation. Adding the
> > default values IMO makes less sense, because you want to define the
> default
> > value only once, whereas you can lookup multiple properties...*
> >
> >
> >
> >> > // Configuration method
> >> > @ConfigProperty("componentName")
> >> > @WithConfig("module1")
> >> > @DefaultValue("N/A")
> >> > *private* *void* setComponentName(*String* compName){
> >> > ...
> >> > }
> >> >
> >> > // Configuration listener method, defining which properties to
> listen
> >> for
> >> > @ConfigChanges
> >> > @ConfigProperty("componentName")
> >> > *private* *void* setComponentName(ConfigChange change){
> >> > ...
> >> > }
> >> >
> >> > }
> >> >
> >> > The instance then can be passed for being configured:
> >> > Configuring a POJO
> >> >
> >> > MyPojo instance = *new* MyPojo();*Configuration*.configure(instance);
> >> >
> >>
> >> I'd use "bind" keyword since you don't configure the instance, just
> >> you map the config on it no?
> >>
> >
> > *IMO users get more confused with bind. Lets see, what others think...
> ;)*
> >
> >
> >
> >> > This will configure all values according to the load policies (by
> >> default
> >> > LoadPolicy.INITIAL). Depending on the listeners present and the
> >> properties
> >> > injected Tamaya will keep weak references to the bean and the current
> >> > environment, so it can be determined, when configuration changes must
> be
> >> > published into the bean.
> >>
> >> Would hide it behind DynamicValue cause in some case you'll not be
> >> able to do it very well, would also allow to add some useful methods
> >> like hasChanged().
> >>
> >
> > *Hmm, I start to feel some sympathies for the DynamicValue ... *
> >
> >>
> >> > Feel free to comment or ask questions ;)
> >> >
> >> > Best,
> >> > 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*
> >>
> >
> >
> > --
> > *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: UC: Configuration Injection (SE)
Posted by Romain Manni-Bucau <rm...@gmail.com>.
PropertyAdapter from the JVM? If so clearly -1, it is slow and not
usable @runtime (only valuable during bootstrap IMO).
In Johnzon I wanted to do it as well, found it super sexy, then I
benched...totally not usable if the config can be used "often" like it
will for sure with CDI and potentially for each request (typical
@RequestScoped). Only solution would be to cache computed values which
can then be wrong if computation depends on the context which is
totally valuable (depending the logged user for some cases for
instance).
In term of API having Serializer, Deserilizer, Codec (= Serializer +
Deserializer) interfaces can make sense since in some cases you'll
just want to deserilize, no?
Romain Manni-Bucau
@rmannibucau
http://www.tomitribe.com
http://rmannibucau.wordpress.com
https://github.com/rmannibucau
2014-12-18 1:30 GMT+01:00 Anatole Tresch <at...@gmail.com>:
> *Hi Romain*
>
> *short inline (before I take some sleep..)...*
>
> *Anatole*
>
>
> 2014-12-18 0:13 GMT+01:00 Romain Manni-Bucau <rm...@gmail.com>:
>>
>> 2014-12-18 0:05 GMT+01:00 Anatole Tresch <at...@gmail.com>:
>> > Hi all
>> > I would like to present another use case: injection of configuration in
>> SE
>> > (EE should be almost similar):
>> >
>> > Automatic Configuration (Configuration Injection)
>> >
>> > Tamaya must provide a feature for automatic configuration, where
>> properties
>> > of a class or methods can be annotated:
>> >
>> > -
>> >
>> > Hereby the lifecycle of the instances configured should not be managed
>> > by Tamaya.
>> > -
>> >
>> > String as well as other types should be supported.
>> > -
>> >
>>
>> We should limit to types we can handle to start I think (until we
>> finished other IoC integration to keep it aligned to start)
>>
>> So file, string, primitive wrappers, uri, inetaddress...
>
>
> *Disagree. The mechanism is already in place and working well.
> PropertyAdapter is a generic functional interface.*
> *I would not want to throw it away. The only thing, I see is really worth
> discussing are other aspects, like meta-information, and
> multi-values/collection support. *
>
>
>> > It must be possible to define default values to be used, if no valid
>> > value is present.
>> > -
>> >
>> > It must be possible to define dynamic expressions, at least for
>> default
>> > values.
>> > -
>> >
>> > The values configured can be reinjected, if the underlying
>> configuration
>> > changes. This should also be the case fir final classes, such as
>> Strings.
>> > -
>> >
>>
>> -1, I would introduce DynamicValue<String> (or any generic) for it
>>
>
> *Other opinions? *
>
>>
>> > Reinjection should be controllable by an loading policy.
>> > -
>> >
>> > It should be possible to evaluate multiple keys, e.g. current keys,
>> and
>> > as a backup deprecated keys from former application releases.
>> > -
>> >
>> > It should be possible to evaluate multiple configurations.
>> > -
>> >
>> > The type conversion of the properties injected should be configurable.
>> > -
>> >
>> > The value evaluated for a property (before type conversion) may be
>> > adaptable as well.
>> > -
>> >
>> > It should be possible to observe configuration changes.
>> >
>> > To illustrate the points above imagine the following POJO:
>> > Configured POJO Example
>> >
>> > *public* *class* *MyPojo* {
>> > @ConfigProperty("myCurrency")
>> > @DefaultValue("CHF") // use as default
>> > @WithLoadingPolicy(LoadingPolicy.INITIAL) // load the value only
>> > once (no reinjection)
>> > *private* *String* currency;
>> >
>> > @ConfigProperty("myCurrencyRate")
>> > *private* *Long* currencyRate;
>> >
>> > @ConfigProperty // evaluates to
>> > key=<fieldName>="fullRate"
>> > @ConfigProperty("fallback.property")
>> > @WithConfig("default")
>> > @WithConfig("moduleConfig");
>> > *private* *BigDecimal* fullRate;
>> >
>> > // Configuration method
>> > *void* setStartup(@ConfigProperty *boolean* startup,
>> > @ConfigProperty("componentName") @WithConfig("module1")
>> > @DefaultValue("N/A") *String* compName){
>> > ...
>> > }
>> >
>>
>> I would put default value in @ConfigProperty to avoid
>> TooMuchAnnotationsException
>> @WithConfig({}) for the same reason or even in @ConfigProperty(configs =
>> {})?
>>
>
> *For configs, we can add them to the property annotation. Adding the
> default values IMO makes less sense, because you want to define the default
> value only once, whereas you can lookup multiple properties...*
>
>
>
>> > // Configuration method
>> > @ConfigProperty("componentName")
>> > @WithConfig("module1")
>> > @DefaultValue("N/A")
>> > *private* *void* setComponentName(*String* compName){
>> > ...
>> > }
>> >
>> > // Configuration listener method, defining which properties to listen
>> for
>> > @ConfigChanges
>> > @ConfigProperty("componentName")
>> > *private* *void* setComponentName(ConfigChange change){
>> > ...
>> > }
>> >
>> > }
>> >
>> > The instance then can be passed for being configured:
>> > Configuring a POJO
>> >
>> > MyPojo instance = *new* MyPojo();*Configuration*.configure(instance);
>> >
>>
>> I'd use "bind" keyword since you don't configure the instance, just
>> you map the config on it no?
>>
>
> *IMO users get more confused with bind. Lets see, what others think... ;)*
>
>
>
>> > This will configure all values according to the load policies (by
>> default
>> > LoadPolicy.INITIAL). Depending on the listeners present and the
>> properties
>> > injected Tamaya will keep weak references to the bean and the current
>> > environment, so it can be determined, when configuration changes must be
>> > published into the bean.
>>
>> Would hide it behind DynamicValue cause in some case you'll not be
>> able to do it very well, would also allow to add some useful methods
>> like hasChanged().
>>
>
> *Hmm, I start to feel some sympathies for the DynamicValue ... *
>
>>
>> > Feel free to comment or ask questions ;)
>> >
>> > Best,
>> > 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*
>>
>
>
> --
> *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: UC: Configuration Injection (SE)
Posted by Anatole Tresch <at...@gmail.com>.
*Hi Romain*
*short inline (before I take some sleep..)...*
*Anatole*
2014-12-18 0:13 GMT+01:00 Romain Manni-Bucau <rm...@gmail.com>:
>
> 2014-12-18 0:05 GMT+01:00 Anatole Tresch <at...@gmail.com>:
> > Hi all
> > I would like to present another use case: injection of configuration in
> SE
> > (EE should be almost similar):
> >
> > Automatic Configuration (Configuration Injection)
> >
> > Tamaya must provide a feature for automatic configuration, where
> properties
> > of a class or methods can be annotated:
> >
> > -
> >
> > Hereby the lifecycle of the instances configured should not be managed
> > by Tamaya.
> > -
> >
> > String as well as other types should be supported.
> > -
> >
>
> We should limit to types we can handle to start I think (until we
> finished other IoC integration to keep it aligned to start)
>
> So file, string, primitive wrappers, uri, inetaddress...
*Disagree. The mechanism is already in place and working well.
PropertyAdapter is a generic functional interface.*
*I would not want to throw it away. The only thing, I see is really worth
discussing are other aspects, like meta-information, and
multi-values/collection support. *
> > It must be possible to define default values to be used, if no valid
> > value is present.
> > -
> >
> > It must be possible to define dynamic expressions, at least for
> default
> > values.
> > -
> >
> > The values configured can be reinjected, if the underlying
> configuration
> > changes. This should also be the case fir final classes, such as
> Strings.
> > -
> >
>
> -1, I would introduce DynamicValue<String> (or any generic) for it
>
*Other opinions? *
>
> > Reinjection should be controllable by an loading policy.
> > -
> >
> > It should be possible to evaluate multiple keys, e.g. current keys,
> and
> > as a backup deprecated keys from former application releases.
> > -
> >
> > It should be possible to evaluate multiple configurations.
> > -
> >
> > The type conversion of the properties injected should be configurable.
> > -
> >
> > The value evaluated for a property (before type conversion) may be
> > adaptable as well.
> > -
> >
> > It should be possible to observe configuration changes.
> >
> > To illustrate the points above imagine the following POJO:
> > Configured POJO Example
> >
> > *public* *class* *MyPojo* {
> > @ConfigProperty("myCurrency")
> > @DefaultValue("CHF") // use as default
> > @WithLoadingPolicy(LoadingPolicy.INITIAL) // load the value only
> > once (no reinjection)
> > *private* *String* currency;
> >
> > @ConfigProperty("myCurrencyRate")
> > *private* *Long* currencyRate;
> >
> > @ConfigProperty // evaluates to
> > key=<fieldName>="fullRate"
> > @ConfigProperty("fallback.property")
> > @WithConfig("default")
> > @WithConfig("moduleConfig");
> > *private* *BigDecimal* fullRate;
> >
> > // Configuration method
> > *void* setStartup(@ConfigProperty *boolean* startup,
> > @ConfigProperty("componentName") @WithConfig("module1")
> > @DefaultValue("N/A") *String* compName){
> > ...
> > }
> >
>
> I would put default value in @ConfigProperty to avoid
> TooMuchAnnotationsException
> @WithConfig({}) for the same reason or even in @ConfigProperty(configs =
> {})?
>
*For configs, we can add them to the property annotation. Adding the
default values IMO makes less sense, because you want to define the default
value only once, whereas you can lookup multiple properties...*
> > // Configuration method
> > @ConfigProperty("componentName")
> > @WithConfig("module1")
> > @DefaultValue("N/A")
> > *private* *void* setComponentName(*String* compName){
> > ...
> > }
> >
> > // Configuration listener method, defining which properties to listen
> for
> > @ConfigChanges
> > @ConfigProperty("componentName")
> > *private* *void* setComponentName(ConfigChange change){
> > ...
> > }
> >
> > }
> >
> > The instance then can be passed for being configured:
> > Configuring a POJO
> >
> > MyPojo instance = *new* MyPojo();*Configuration*.configure(instance);
> >
>
> I'd use "bind" keyword since you don't configure the instance, just
> you map the config on it no?
>
*IMO users get more confused with bind. Lets see, what others think... ;)*
> > This will configure all values according to the load policies (by
> default
> > LoadPolicy.INITIAL). Depending on the listeners present and the
> properties
> > injected Tamaya will keep weak references to the bean and the current
> > environment, so it can be determined, when configuration changes must be
> > published into the bean.
>
> Would hide it behind DynamicValue cause in some case you'll not be
> able to do it very well, would also allow to add some useful methods
> like hasChanged().
>
*Hmm, I start to feel some sympathies for the DynamicValue ... *
>
> > Feel free to comment or ask questions ;)
> >
> > Best,
> > 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*
>
--
*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: UC: Configuration Injection (SE)
Posted by Romain Manni-Bucau <rm...@gmail.com>.
And fromString(String) like jaxrs I think.
Can work even if it will need work for cdi
Le 21 déc. 2014 12:11, "Oliver B. Fischer" <o....@swe-blog.net> a
écrit :
> See below for my comments...
>
> Am 18.12.14 um 00:13 schrieb Romain Manni-Bucau:
>
>> 2014-12-18 0:05 GMT+01:00 Anatole Tresch <at...@gmail.com>:
>>
>>> -
>>>
>>> String as well as other types should be supported.
>>> -
>>>
>>> We should limit to types we can handle to start I think (until we
>> finished other IoC integration to keep it aligned to start)
>>
>> So file, string, primitive wrappers, uri, inetaddress...
>>
> I proposed already a way to handle that:
>
> If the target type has a valueOf(String ...) method or
> if the target type has a of(String ....) method or
> if the target type has a ctor(String ...)
>
> use this method to convert from string to an instance of the target type
>
> Otherwise scan the classpath for a matching property adatper.
>
> // Configuration method
>> *void* setStartup(@ConfigProperty *boolean* startup,
>> @ConfigProperty("componentName") @WithConfig("module1")
>> @DefaultValue("N/A") *String* compName){
>> ...
>> }
>>
>> I would put default value in @ConfigProperty to avoid
>> TooMuchAnnotationsException
>> @WithConfig({}) for the same reason or even in @ConfigProperty(configs =
>> {})?
>>
>> +1
>
>
> --
> 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: UC: Configuration Injection (SE)
Posted by "Oliver B. Fischer" <o....@swe-blog.net>.
See below for my comments...
Am 18.12.14 um 00:13 schrieb Romain Manni-Bucau:
> 2014-12-18 0:05 GMT+01:00 Anatole Tresch <at...@gmail.com>:
>> -
>>
>> String as well as other types should be supported.
>> -
>>
> We should limit to types we can handle to start I think (until we
> finished other IoC integration to keep it aligned to start)
>
> So file, string, primitive wrappers, uri, inetaddress...
I proposed already a way to handle that:
If the target type has a valueOf(String ...) method or
if the target type has a of(String ....) method or
if the target type has a ctor(String ...)
use this method to convert from string to an instance of the target type
Otherwise scan the classpath for a matching property adatper.
> // Configuration method
> *void* setStartup(@ConfigProperty *boolean* startup,
> @ConfigProperty("componentName") @WithConfig("module1")
> @DefaultValue("N/A") *String* compName){
> ...
> }
>
> I would put default value in @ConfigProperty to avoid
> TooMuchAnnotationsException
> @WithConfig({}) for the same reason or even in @ConfigProperty(configs = {})?
>
+1
--
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: UC: Configuration Injection (SE)
Posted by Romain Manni-Bucau <rm...@gmail.com>.
2014-12-18 0:05 GMT+01:00 Anatole Tresch <at...@gmail.com>:
> Hi all
> I would like to present another use case: injection of configuration in SE
> (EE should be almost similar):
>
> Automatic Configuration (Configuration Injection)
>
> Tamaya must provide a feature for automatic configuration, where properties
> of a class or methods can be annotated:
>
> -
>
> Hereby the lifecycle of the instances configured should not be managed
> by Tamaya.
> -
>
> String as well as other types should be supported.
> -
>
We should limit to types we can handle to start I think (until we
finished other IoC integration to keep it aligned to start)
So file, string, primitive wrappers, uri, inetaddress...
> It must be possible to define default values to be used, if no valid
> value is present.
> -
>
> It must be possible to define dynamic expressions, at least for default
> values.
> -
>
> The values configured can be reinjected, if the underlying configuration
> changes. This should also be the case fir final classes, such as Strings.
> -
>
-1, I would introduce DynamicValue<String> (or any generic) for it
> Reinjection should be controllable by an loading policy.
> -
>
> It should be possible to evaluate multiple keys, e.g. current keys, and
> as a backup deprecated keys from former application releases.
> -
>
> It should be possible to evaluate multiple configurations.
> -
>
> The type conversion of the properties injected should be configurable.
> -
>
> The value evaluated for a property (before type conversion) may be
> adaptable as well.
> -
>
> It should be possible to observe configuration changes.
>
> To illustrate the points above imagine the following POJO:
> Configured POJO Example
>
> *public* *class* *MyPojo* {
> @ConfigProperty("myCurrency")
> @DefaultValue("CHF") // use as default
> @WithLoadingPolicy(LoadingPolicy.INITIAL) // load the value only
> once (no reinjection)
> *private* *String* currency;
>
> @ConfigProperty("myCurrencyRate")
> *private* *Long* currencyRate;
>
> @ConfigProperty // evaluates to
> key=<fieldName>="fullRate"
> @ConfigProperty("fallback.property")
> @WithConfig("default")
> @WithConfig("moduleConfig");
> *private* *BigDecimal* fullRate;
>
> // Configuration method
> *void* setStartup(@ConfigProperty *boolean* startup,
> @ConfigProperty("componentName") @WithConfig("module1")
> @DefaultValue("N/A") *String* compName){
> ...
> }
>
I would put default value in @ConfigProperty to avoid
TooMuchAnnotationsException
@WithConfig({}) for the same reason or even in @ConfigProperty(configs = {})?
> // Configuration method
> @ConfigProperty("componentName")
> @WithConfig("module1")
> @DefaultValue("N/A")
> *private* *void* setComponentName(*String* compName){
> ...
> }
>
> // Configuration listener method, defining which properties to listen for
> @ConfigChanges
> @ConfigProperty("componentName")
> *private* *void* setComponentName(ConfigChange change){
> ...
> }
>
> }
>
> The instance then can be passed for being configured:
> Configuring a POJO
>
> MyPojo instance = *new* MyPojo();*Configuration*.configure(instance);
>
I'd use "bind" keyword since you don't configure the instance, just
you map the config on it no?
> This will configure all values according to the load policies (by default
> LoadPolicy.INITIAL). Depending on the listeners present and the properties
> injected Tamaya will keep weak references to the bean and the current
> environment, so it can be determined, when configuration changes must be
> published into the bean.
Would hide it behind DynamicValue cause in some case you'll not be
able to do it very well, would also allow to add some useful methods
like hasChanged().
> Feel free to comment or ask questions ;)
>
> Best,
> 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: UC: Configuration Injection (SE)
Posted by Anatole Tresch <at...@gmail.com>.
For derializong to String by default, yes. Of course, with explicit codecs
things can be changed...
Romain Manni-Bucau <rm...@gmail.com> schrieb am So., 21. Dez. 2014 um
14:18:
> Do we/will use toString to serialize as well?
> Le 21 déc. 2014 13:27, "Anatole Tresch" <at...@gmail.com> a écrit :
>
> > Hi,
> >
> > this is basically already the case, despite that we have to align the
> > possible factory method names.
> > Currently it
> > 0) it tries to lookup an explicit codec
> > 1) it tries of, valueOf, instanceOf, getInstance. from, parse
> > 2) it looks for a constructor taking a String argument
> > 3) it throws a config exception
> >
> > it uses toString for the opposite.
> >
> > That way with registering an explicit codec for a type you get full
> > control, without the defaults apply as outlined....
> >
> > Best, A
> >
> >
> > Anatole Tresch <at...@gmail.com> schrieb am So., 21. Dez. 2014 um
> > 13:15:
> >
> > > +1 yes, makes sense!
> > > Oliver B. Fischer <o....@swe-blog.net> schrieb am So., 21. Dez.
> > > 2014 um 12:21:
> > >
> > > I like the way the Jackson JSON processor uses annotations. You don’t
> > >> need them, but if you need them you have a bunch of annoations to take
> > >> over control.
> > >>
> > >> Am 21.12.14 um 12:09 schrieb Romain Manni-Bucau:
> > >>
> > >> > +1, that is what we did in Johnzon and it makes usage smooth IMO.
> > >> > Le 21 déc. 2014 12:08, "Oliver B. Fischer" <
> > o.b.fischer@swe-blog.net>
> > >> a
> > >> > écrit :
> > >> >
> > >> >> @Anatole: I would like to see this working even without any
> > annotation
> > >> by
> > >> >> matching the bean property by its name with a configuration value.
> > >> >> Annotations should be only needed if the default annotation free
> way
> > >> is not
> > >> >> working/is not flexible enough.
> > >> >>
> > >> >> WDYT?
> > >> >>
> > >> >> Bye,
> > >> >>
> > >> >> Oliver
> > >> >>
> > >> >>
> > >> >> Am 18.12.14 um 00:05 schrieb Anatole Tresch:
> > >> >>
> > >> >> --
> > >> >> 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: UC: Configuration Injection (SE)
Posted by Romain Manni-Bucau <rm...@gmail.com>.
Do we/will use toString to serialize as well?
Le 21 déc. 2014 13:27, "Anatole Tresch" <at...@gmail.com> a écrit :
> Hi,
>
> this is basically already the case, despite that we have to align the
> possible factory method names.
> Currently it
> 0) it tries to lookup an explicit codec
> 1) it tries of, valueOf, instanceOf, getInstance. from, parse
> 2) it looks for a constructor taking a String argument
> 3) it throws a config exception
>
> it uses toString for the opposite.
>
> That way with registering an explicit codec for a type you get full
> control, without the defaults apply as outlined....
>
> Best, A
>
>
> Anatole Tresch <at...@gmail.com> schrieb am So., 21. Dez. 2014 um
> 13:15:
>
> > +1 yes, makes sense!
> > Oliver B. Fischer <o....@swe-blog.net> schrieb am So., 21. Dez.
> > 2014 um 12:21:
> >
> > I like the way the Jackson JSON processor uses annotations. You don’t
> >> need them, but if you need them you have a bunch of annoations to take
> >> over control.
> >>
> >> Am 21.12.14 um 12:09 schrieb Romain Manni-Bucau:
> >>
> >> > +1, that is what we did in Johnzon and it makes usage smooth IMO.
> >> > Le 21 déc. 2014 12:08, "Oliver B. Fischer" <
> o.b.fischer@swe-blog.net>
> >> a
> >> > écrit :
> >> >
> >> >> @Anatole: I would like to see this working even without any
> annotation
> >> by
> >> >> matching the bean property by its name with a configuration value.
> >> >> Annotations should be only needed if the default annotation free way
> >> is not
> >> >> working/is not flexible enough.
> >> >>
> >> >> WDYT?
> >> >>
> >> >> Bye,
> >> >>
> >> >> Oliver
> >> >>
> >> >>
> >> >> Am 18.12.14 um 00:05 schrieb Anatole Tresch:
> >> >>
> >> >> --
> >> >> 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: UC: Configuration Injection (SE)
Posted by Anatole Tresch <at...@gmail.com>.
Hi,
this is basically already the case, despite that we have to align the
possible factory method names.
Currently it
0) it tries to lookup an explicit codec
1) it tries of, valueOf, instanceOf, getInstance. from, parse
2) it looks for a constructor taking a String argument
3) it throws a config exception
it uses toString for the opposite.
That way with registering an explicit codec for a type you get full
control, without the defaults apply as outlined....
Best, A
Anatole Tresch <at...@gmail.com> schrieb am So., 21. Dez. 2014 um 13:15:
> +1 yes, makes sense!
> Oliver B. Fischer <o....@swe-blog.net> schrieb am So., 21. Dez.
> 2014 um 12:21:
>
> I like the way the Jackson JSON processor uses annotations. You don’t
>> need them, but if you need them you have a bunch of annoations to take
>> over control.
>>
>> Am 21.12.14 um 12:09 schrieb Romain Manni-Bucau:
>>
>> > +1, that is what we did in Johnzon and it makes usage smooth IMO.
>> > Le 21 déc. 2014 12:08, "Oliver B. Fischer" <o....@swe-blog.net>
>> a
>> > écrit :
>> >
>> >> @Anatole: I would like to see this working even without any annotation
>> by
>> >> matching the bean property by its name with a configuration value.
>> >> Annotations should be only needed if the default annotation free way
>> is not
>> >> working/is not flexible enough.
>> >>
>> >> WDYT?
>> >>
>> >> Bye,
>> >>
>> >> Oliver
>> >>
>> >>
>> >> Am 18.12.14 um 00:05 schrieb Anatole Tresch:
>> >>
>> >> --
>> >> 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: UC: Configuration Injection (SE)
Posted by Anatole Tresch <at...@gmail.com>.
+1 yes, makes sense!
Oliver B. Fischer <o....@swe-blog.net> schrieb am So., 21. Dez. 2014
um 12:21:
> I like the way the Jackson JSON processor uses annotations. You don’t
> need them, but if you need them you have a bunch of annoations to take
> over control.
>
> Am 21.12.14 um 12:09 schrieb Romain Manni-Bucau:
>
> > +1, that is what we did in Johnzon and it makes usage smooth IMO.
> > Le 21 déc. 2014 12:08, "Oliver B. Fischer" <o....@swe-blog.net>
> a
> > écrit :
> >
> >> @Anatole: I would like to see this working even without any annotation
> by
> >> matching the bean property by its name with a configuration value.
> >> Annotations should be only needed if the default annotation free way is
> not
> >> working/is not flexible enough.
> >>
> >> WDYT?
> >>
> >> Bye,
> >>
> >> Oliver
> >>
> >>
> >> Am 18.12.14 um 00:05 schrieb Anatole Tresch:
> >>
> >> --
> >> 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: UC: Configuration Injection (SE)
Posted by "Oliver B. Fischer" <o....@swe-blog.net>.
I like the way the Jackson JSON processor uses annotations. You don’t
need them, but if you need them you have a bunch of annoations to take
over control.
Am 21.12.14 um 12:09 schrieb Romain Manni-Bucau:
> +1, that is what we did in Johnzon and it makes usage smooth IMO.
> Le 21 déc. 2014 12:08, "Oliver B. Fischer" <o....@swe-blog.net> a
> écrit :
>
>> @Anatole: I would like to see this working even without any annotation by
>> matching the bean property by its name with a configuration value.
>> Annotations should be only needed if the default annotation free way is not
>> working/is not flexible enough.
>>
>> WDYT?
>>
>> Bye,
>>
>> Oliver
>>
>>
>> Am 18.12.14 um 00:05 schrieb Anatole Tresch:
>>
>> --
>> 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: UC: Configuration Injection (SE)
Posted by Romain Manni-Bucau <rm...@gmail.com>.
+1, that is what we did in Johnzon and it makes usage smooth IMO.
Le 21 déc. 2014 12:08, "Oliver B. Fischer" <o....@swe-blog.net> a
écrit :
> @Anatole: I would like to see this working even without any annotation by
> matching the bean property by its name with a configuration value.
> Annotations should be only needed if the default annotation free way is not
> working/is not flexible enough.
>
> WDYT?
>
> Bye,
>
> Oliver
>
>
> Am 18.12.14 um 00:05 schrieb Anatole Tresch:
>
>> Hi all
>> I would like to present another use case: injection of configuration in SE
>> (EE should be almost similar):
>>
>> Automatic Configuration (Configuration Injection)
>>
>> Tamaya must provide a feature for automatic configuration, where
>> properties
>> of a class or methods can be annotated:
>>
>> -
>>
>> Hereby the lifecycle of the instances configured should not be managed
>> by Tamaya.
>> -
>>
>> String as well as other types should be supported.
>> -
>>
>> It must be possible to define default values to be used, if no valid
>> value is present.
>> -
>>
>> It must be possible to define dynamic expressions, at least for
>> default
>> values.
>> -
>>
>> The values configured can be reinjected, if the underlying
>> configuration
>> changes. This should also be the case fir final classes, such as
>> Strings.
>> -
>>
>> Reinjection should be controllable by an loading policy.
>> -
>>
>> It should be possible to evaluate multiple keys, e.g. current keys,
>> and
>> as a backup deprecated keys from former application releases.
>> -
>>
>> It should be possible to evaluate multiple configurations.
>> -
>>
>> The type conversion of the properties injected should be configurable.
>> -
>>
>> The value evaluated for a property (before type conversion) may be
>> adaptable as well.
>> -
>>
>> It should be possible to observe configuration changes.
>>
>> To illustrate the points above imagine the following POJO:
>> Configured POJO Example
>>
>> *public* *class* *MyPojo* {
>> @ConfigProperty("myCurrency")
>> @DefaultValue("CHF") // use as default
>> @WithLoadingPolicy(LoadingPolicy.INITIAL) // load the value only
>> once (no reinjection)
>> *private* *String* currency;
>>
>> @ConfigProperty("myCurrencyRate")
>> *private* *Long* currencyRate;
>>
>> @ConfigProperty // evaluates to
>> key=<fieldName>="fullRate"
>> @ConfigProperty("fallback.property")
>> @WithConfig("default")
>> @WithConfig("moduleConfig");
>> *private* *BigDecimal* fullRate;
>>
>> // Configuration method
>> *void* setStartup(@ConfigProperty *boolean* startup,
>> @ConfigProperty("componentName") @WithConfig("module1")
>> @DefaultValue("N/A") *String* compName){
>> ...
>> }
>>
>> // Configuration method
>> @ConfigProperty("componentName")
>> @WithConfig("module1")
>> @DefaultValue("N/A")
>> *private* *void* setComponentName(*String* compName){
>> ...
>> }
>>
>> // Configuration listener method, defining which properties to listen
>> for
>> @ConfigChanges
>> @ConfigProperty("componentName")
>> *private* *void* setComponentName(ConfigChange change){
>> ...
>> }
>>
>> }
>>
>> The instance then can be passed for being configured:
>> Configuring a POJO
>>
>> MyPojo instance = *new* MyPojo();*Configuration*.configure(instance);
>>
>> This will configure all values according to the load policies (by
>> default
>> LoadPolicy.INITIAL). Depending on the listeners present and the properties
>> injected Tamaya will keep weak references to the bean and the current
>> environment, so it can be determined, when configuration changes must be
>> published into the bean.
>> Feel free to comment or ask questions ;)
>>
>> Best,
>> 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: UC: Configuration Injection (SE)
Posted by "Oliver B. Fischer" <o....@swe-blog.net>.
@Anatole: I would like to see this working even without any annotation
by matching the bean property by its name with a configuration value.
Annotations should be only needed if the default annotation free way is
not working/is not flexible enough.
WDYT?
Bye,
Oliver
Am 18.12.14 um 00:05 schrieb Anatole Tresch:
> Hi all
> I would like to present another use case: injection of configuration in SE
> (EE should be almost similar):
>
> Automatic Configuration (Configuration Injection)
>
> Tamaya must provide a feature for automatic configuration, where properties
> of a class or methods can be annotated:
>
> -
>
> Hereby the lifecycle of the instances configured should not be managed
> by Tamaya.
> -
>
> String as well as other types should be supported.
> -
>
> It must be possible to define default values to be used, if no valid
> value is present.
> -
>
> It must be possible to define dynamic expressions, at least for default
> values.
> -
>
> The values configured can be reinjected, if the underlying configuration
> changes. This should also be the case fir final classes, such as Strings.
> -
>
> Reinjection should be controllable by an loading policy.
> -
>
> It should be possible to evaluate multiple keys, e.g. current keys, and
> as a backup deprecated keys from former application releases.
> -
>
> It should be possible to evaluate multiple configurations.
> -
>
> The type conversion of the properties injected should be configurable.
> -
>
> The value evaluated for a property (before type conversion) may be
> adaptable as well.
> -
>
> It should be possible to observe configuration changes.
>
> To illustrate the points above imagine the following POJO:
> Configured POJO Example
>
> *public* *class* *MyPojo* {
> @ConfigProperty("myCurrency")
> @DefaultValue("CHF") // use as default
> @WithLoadingPolicy(LoadingPolicy.INITIAL) // load the value only
> once (no reinjection)
> *private* *String* currency;
>
> @ConfigProperty("myCurrencyRate")
> *private* *Long* currencyRate;
>
> @ConfigProperty // evaluates to
> key=<fieldName>="fullRate"
> @ConfigProperty("fallback.property")
> @WithConfig("default")
> @WithConfig("moduleConfig");
> *private* *BigDecimal* fullRate;
>
> // Configuration method
> *void* setStartup(@ConfigProperty *boolean* startup,
> @ConfigProperty("componentName") @WithConfig("module1")
> @DefaultValue("N/A") *String* compName){
> ...
> }
>
> // Configuration method
> @ConfigProperty("componentName")
> @WithConfig("module1")
> @DefaultValue("N/A")
> *private* *void* setComponentName(*String* compName){
> ...
> }
>
> // Configuration listener method, defining which properties to listen for
> @ConfigChanges
> @ConfigProperty("componentName")
> *private* *void* setComponentName(ConfigChange change){
> ...
> }
>
> }
>
> The instance then can be passed for being configured:
> Configuring a POJO
>
> MyPojo instance = *new* MyPojo();*Configuration*.configure(instance);
>
> This will configure all values according to the load policies (by default
> LoadPolicy.INITIAL). Depending on the listeners present and the properties
> injected Tamaya will keep weak references to the bean and the current
> environment, so it can be determined, when configuration changes must be
> published into the bean.
> Feel free to comment or ask questions ;)
>
> Best,
> 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