as i said: it was just a prototype and i don't disagree with you. it's just not bound to @ConfigProperty and therefore a separated topic.
yes - we have to do such reviews on a regular basis -> in general +1 for dropping parts again (if we find a better approach). (that's also one of our official statements for versions < v1) regards, gerhard 2012/6/14 Mark Struberg <[email protected]> > 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 > >> >> >> > >> >> >> > >> >> > > >> >> > >> > > >> > > >
