Weird if that s true but in such a case app will be constrained too i think Le 2 juin 2013 10:25, "Mark Struberg" <strub...@yahoo.de> a écrit :
> > > 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 > >> >> > >> > > > >> >> > >> > > >> >> > >> > >> >> > > > >> >> > > >> >> > > > > >
