FWIW I'm +1 for the BeanVal stuff and keeping it disabled by default. Just because Java EE 7 is soon to be released doesn't mean that people will migrate to it over night, as has already been said. I'm sure there are quite a few large corporations still on Java EE 5 and probably will be for a while.
If the coding is minimal to bring some Java EE 7 features to Java EE 6 via DeltaSpike, I don't see a reason not to do this. — Sent from Mailbox for iPhone On Sat, Jun 1, 2013 at 1:55 PM, Gerhard Petracek <gerhard.petra...@gmail.com> wrote: > hi thomas, > no - we don't have @Advanced. > (-1 for adding it and therefore -1 for adding parts which would need such a > qualifier.) > regards, > gerhard > 2013/6/1 Thomas Andraschko <andraschko.tho...@gmail.com> >> Jep, there will be many EE6 users out there the next 1-3 years. >> >> there are also other possible features: >> - injection in other BV artifacts - e.g. MessageInterpolator >> - method validation (if possible with 1.0 specs) >> >> AFAIK all this features will be available in BV 1.1, so it would be enough >> to create a BV1.0 module. >> >> Is there already something available like @Advanded in DS? >> I personally don't like it. Do we really save performance? >> Probably the best solution is to just activate injection if the module is >> included. >> >> >> Thats the same with JSF 2.2 ViewScoped. >> How will it be handled in DS? >> >> >> 2013/6/1 Mark Struberg <strub...@yahoo.de> >> >> > As others said, in an EE-6 container you cannot just exchange the bean >> > validation provider easily. >> > >> > >> > Yes, it's already possible to use the BeanProvider to achieve this goal. >> > But it's also nice if that would work out of the box. >> > An important criteria is of course that it must also work when bean >> > validation-1.1 is available which will do the injection itself. >> > >> > >> > Imo it's mostly a question about what else we like to add into this >> module. >> > >> > LieGrue, >> > strub >> > >> > >> > >> > ----- Original Message ----- >> > > From: Gerhard Petracek <gerhard.petra...@gmail.com> >> > > To: dev@deltaspike.apache.org >> > > Cc: >> > > Sent: Saturday, 1 June 2013, 20:25 >> > > Subject: Re: DISCUSS DeltaSpike-332 >> > > >> > > hi thomas, >> > > >> > > yes, because we based everything on the jsf 1.2 api. >> > > (~nothing from the jsf2+ api was needed to provide what you get with >> > codi.) >> > > >> > > @ "...in each validator...": >> > > projects usually don't have that many constraint-validators which need >> > > other services (and if so they might overuse it). >> > > >> > > we should encourage users to move to bv 1.1 asap. >> > > (in case of apache bval we could even provide it for bv 1.0, since we >> > have >> > > to do it for 1.1+ anyway). >> > > >> > > regards, >> > > gerhard >> > > >> > > >> > > >> > > 2013/6/1 Thomas Andraschko <andraschko.tho...@gmail.com> >> > > >> > >> i know what you mean gerhard :) >> > >> but IMO using manual injection or getting the bean via BeanManager >> > etc. is >> > >> just a "stupid" workaround in each validator. >> > >> >> > >> It would be just user friendly to provide a small module which >> > provides BV >> > >> injection. Also the effort to create this module is very very low. >> > >> Sure it's not based on the newest technology versions but there is >> also >> > > a >> > >> JSF 1.2 module in CODI. >> > >> >> > >> >> > >> 2013/6/1 Gerhard Petracek <gerhard.petra...@gmail.com> >> > >> >> > >> > @thomas: >> > >> > if you are allowed to use bv 1.1, it should be possible (via >> > >> > default-provider + the corresponding classloading-config for the >> > > server >> > >> you >> > >> > are using). >> > >> > if you are not allowed to use it, have a look at my initial >> comments. >> > >> > >> > >> > @hantsy: >> > >> > imo that's exotic anyway and you could still use BeanProvider. >> > >> > >> > >> > regards, >> > >> > gerhard >> > >> > >> > >> > >> > >> > >> > >> > 2013/6/1 hantsy <han...@yahoo.com.cn> >> > >> > >> > >> > > I noticed JSF 2.2 canceled the DI in JSF components in final >> > > Specs, >> > >> only >> > >> > > support in JSF backend beans. >> > >> > > >> > >> > > MyFaces CODI provides @Advanced for DI in non contextual >> > > object...it is >> > >> > > still useful for JSF 2.2...but I do not want to add this to >> > > enable >> > >> > > injection on JSF validator, converter, etc. >> > >> > > >> > >> > > Hantsy >> > >> > > On 6/1/2013 22:11, Thomas Andraschko wrote: >> > >> > > > Also if BV 1.1 is coming soon, many customers can't >> > > upgrade to BV 1.1 >> > >> > or >> > >> > > > JavaEE 7 the next 1-2 years. >> > >> > > > So IMO it would be a great feature which shoudl be disabled >> > > per >> > >> > default. >> > >> > > > >> > >> > > > >> > >> > > > 2013/6/1 Romain Manni-Bucau <rmannibu...@gmail.com> >> > >> > > > >> > >> > > >> Idem, not blocking IMO and bval 1.1 is coming so would >> > > be useless >> > >> soon >> > >> > > >> Le 1 juin 2013 15:56, "Gerhard Petracek" < >> > >> gerhard.petra...@gmail.com> >> > >> > a >> > >> > > >> écrit : >> > >> > > >> >> > >> > > >>> hi john, >> > >> > > >>> >> > >> > > >>> codi doesn't do auto registration. you need >> > > @Advanced to enable it. >> > >> > > >>> >> > >> > > >>> if you aren't allowed to use bv 1.1 right know, >> > > you can just use >> > >> > > >>> BeanProvider manually (usually there are just few >> > >> > constraint-validators >> > >> > > >>> which need it at all) >> > >> > > >>> or keep what your are using now in parallel or just >> > > copy those few >> > >> > > >> classes >> > >> > > >>> to your ee6 (only) project. at least in case of codi >> > > they are quite >> > >> > > >>> independent (and in most cases just simple >> > > wrappers). -> -1 for >> > >> > adding >> > >> > > >> it. >> > >> > > >>> regards, >> > >> > > >>> gerhard >> > >> > > >>> >> > >> > > >>> >> > >> > > >>> >> > >> > > >>> 2013/6/1 John D. Ament >> > > <john.d.am...@gmail.com> >> > >> > > >>> >> > >> > > >>>> Hi All >> > >> > > >>>> >> > >> > > >>>> I wanted to begin introducing some level of >> > > BeanValidation >> > >> Support. >> > >> > > >> The >> > >> > > >>>> main goal that I have is to be able to create >> > > CDI aware constraint >> > >> > > >>>> validators, let's say you want to validate >> > > @NonExistentEmail then >> > >> > you >> > >> > > >>>> should be able to run a query against your DB >> > > using your CDI >> > >> > services >> > >> > > >> and >> > >> > > >>>> determine if the given email is already present >> > > or not. >> > >> > > >>>> >> > >> > > >>>> To do this, both Seam3 and CODI introduced a CDI >> > > aware >> > >> > > >> ConstraintFactory. >> > >> > > >>>> When it creates an instance the instance is a >> > > CDI object, so it >> > >> has >> > >> > > >> full >> > >> > > >>>> access to @Inject fields. I'd like to bring >> > > this type of >> > >> > > functionality >> > >> > > >>>> over to DS. >> > >> > > >>>> >> > >> > > >>>> The point where the two diverge is that CODI >> > > does an auto >> > >> > registration >> > >> > > >>>> whereas Seam3 does a registration via >> > > validation.xml. As far as I >> > >> > > >> know, >> > >> > > >>>> CDI already allows the injection of Validator >> > > and ValidatorFactory >> > >> > > >>> (though >> > >> > > >>>> the OWB guys can tell me if they disagree). >> > >> > > >>>> >> > >> > > >>>> Please let me know if anyone has concerns with >> > > adding this. Yes, >> > >> I >> > >> > > >>> realize >> > >> > > >>>> that this functionality is in bean val 1.1, but >> > > not everyone can >> > >> > > >> upgrade >> > >> > > >>> to >> > >> > > >>>> bean val 1.1 yet. >> > >> > > >>>> >> > >> > > >>>> John >> > >> > > >>>> >> > >> > > >> > >> > > -- >> > >> > > Hantsy Bai >> > >> > > Blog:http://hantsy.blogspot.com >> > >> > > LinkedIN:http://www.linkedin.com/in/hantsy >> > >> > > >> > >> > >> > >> >> > > >> > >>
