I'm not 100% sure about that. The Converter stuff as is was only intended/usable for the ConfigProperty. This has nothing to do with CDI at all. The used getBeans() approach for picking it up is not guaranteed to work (@Alternative issue).
Doing a Converter framework properly is a big task! And there was no feature request for it. And I fear we will also not be able to do this properly in a forseeable future. JSF already provides a conversion framework, DS itself doesn't need one so far. What are your further plans with it? LieGrue, strub ----- Original Message ----- > From: Gerhard Petracek <[email protected]> > To: [email protected] > Cc: > Sent: Wednesday, June 13, 2012 8:13 PM > Subject: Re: refactoring of @ConfigProperty handling > > you dropped a bit too much (the whole >prototype< for a > converter infrastructure). > we are just discussing the usage of converters (vs. producers) > for @ConfigProperty. > it wasn't intended to use converters only for @ConfigProperty. > > regards, > gerhard > > > > 2012/6/13 Mark Struberg <[email protected]> > >> Here we go: >> >> https://github.com/struberg/incubator-deltaspike/tree/config >> >> Instead of providing a custom converter you now just write a custom >> producermethod. >> >> Also we now use the @ConfigProperty annotations really as @Qualifier. >> Makes the impls much easier. >> >> This version is also able to fulfil all requirements as listed by Adrian >> in the original mail thread. >> >> >> LieGrue, >> strub >> >> >> >> ----- Original Message ----- >> > From: Gerhard Petracek <[email protected]> >> > To: [email protected] >> > Cc: >> > Sent: Wednesday, June 13, 2012 2:42 PM >> > Subject: Re: refactoring of @ConfigProperty handling >> > >> > +1 >> > the current prototype showed that converters get pretty hard easily. >> > >> > regards, >> > gerhard >> > >> > >> > >> > 2012/6/13 Mark Struberg <[email protected]> >> > >> >> Hi! >> >> >> >> Please don't touch the ConfigPropertyExtension and Converter > stuff for >> > now >> >> as I'm currently refactoring it. >> >> >> >> My current approach is to do the same with simple producer > methods >> instad >> >> of the ProcessInjectionTarget + Bean handling. >> >> This should be much easier. >> >> >> >> >> >> Also this doesn't require all the complex Converter handling. > If a user >> >> needs an own config value class, he can simply write a producer > for it >> >> himself. This is much easier and also much more CDI-like than > having to >> >> register an own Converter<T> in a ConverterFactory, etc >> >> >> >> Just to keep this clear: the @ConfigProperty annotation and > features >> will >> >> remain intact, I only gonna change the implementation behind. >> >> >> >> The only thing which might change is: >> >> >> >> * to move the meta-annotation stuff to proper CDI @Stereotype > handling. >> >> >> >> >> >> * to move all the Converter + registering + annotation parsing + >> >> InjectionTarget + bean handing (wtf is this complex!) to a simple >> >> @Qualifier + producer method a user can write himself >> >> >> >> >> >> >> >> I'll keep you updated ... >> >> >> >> LieGrue, >> >> strub >> >> >> >> >> > >> >
