Pretty often you are not even allowed to change those libs for production. Sometimes because of legal constructs (ever looked at the Oracle license for WebLogic?) and sometimes because of company reasons.
Thus I'm +1 for adding it as _optional_ feature. LieGrue, strub >________________________________ > From: Romain Manni-Bucau <rmannibu...@gmail.com> >To: dev@deltaspike.apache.org >Sent: Sunday, 2 June 2013, 8:57 >Subject: Re: DISCUSS DeltaSpike-332 > > >As said before, if using the javaee7 lib is easy in javaee6 no need of any >glue. That should be the case for bval, jpa... >Le 2 juin 2013 03:26, "Jason Porter" <lightguard...@gmail.com> a écrit : > >> 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 >> >> > >> > > >> >> > >> > >> >> > >> >> >> > > >> >> > >> >> > >
