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" <[email protected]> a écrit :
> Its
>
> @FunctionalInterface
> Public interface PropertyAdapter<T>{
> Public T adapt(String value);
> }
>
> So extremly simple but powerful...
> Romain Manni-Bucau <[email protected]> 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 <[email protected]>:
> > > *Hi Romain*
> > >
> > > *short inline (before I take some sleep..)...*
> > >
> > > *Anatole*
> > >
> > >
> > > 2014-12-18 0:13 GMT+01:00 Romain Manni-Bucau <[email protected]>:
> > >>
> > >> 2014-12-18 0:05 GMT+01:00 Anatole Tresch <[email protected]>:
> > >> > 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*
> >
>
