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*
>
