Gerhard, the whole complexity of ConfigProperty stuff was _never_ really discussed on the list. It was mentioned once in the @ConfigProperty Qualifier disussion. Back then I explained that it is easily possible to implement this with a simple producer method. I have really no idea why we added 15 files for this functionality.
Really, I will review all features and drop parts which are unnecessarily complex. Sometimes it doesn't work out with an easy solution, but IF it does then we should take the easy route. DeltaSpike will become complex enough anyway... LieGrue, strub ----- Original Message ----- > From: Gerhard Petracek <[email protected]> > To: [email protected] > Cc: > Sent: Thursday, June 14, 2012 12:13 AM > Subject: Re: refactoring of @ConfigProperty handling > > #1 i haven't disagreed > #2 using #getBeans is an implementation detail of the first version of > the prototype (we might end up with a completely different implementation > which does it differently) > #3 jsf also provides validators, but at the same time there are > alternatives (also before/besides bean-validation) independent of jsf > > -> as mentioned earlier: > right now we just discuss @ConfigProperty -> using producers for it > doesn't mean that we drop a package which is independent of @ConfigProperty. > a refactoring to producers just means to drop the integration with the > converter package. > keeping or dropping the converter package is a second topic (i haven't said > that we should keep the current prototype and you still have my +1 in case > of @ConfigProperty). > > in general: > please wait until the end of an ongoing discussion (esp. if it was started > few hours earlier) > > regards, > gerhard > > > > 2012/6/13 Mark Struberg <[email protected]> > >> 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 >> >> >> >> >> >> >> >> > >> >> >> > >> >
