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