Message -
> From: John D. Ament
> To: dev@deltaspike.apache.org
> Cc:
> Sent: Monday, 10 June 2013, 1:17
> Subject: Re: DISCUSS DeltaSpike-332
>
> Hi all
>
> So discussion on this died down after 2 days. I think there's kind of two
> camps on this on
Hi all
So discussion on this died down after 2 days. I think there's kind of two
camps on this one.
1. Don't add because it's easy enough to DIY/no enough use cases/BVAL 1.1
is out.
2. Do add because users can't upgrade to BeanVal 1.1/Easier to configure in
validation.xml
So I'm going to go ahe
gt; > >> > 2013/6/1 Thomas Andraschko
> > > > > > >> >> Jep, there will be many EE6 users out there the next 1-3
> > years.
> > > > > > >> >>
> > > > > > >> >> there are also other possi
>
> > > > 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" a écrit :
> > > >
> > > > >
> > > > >
> > > > > Pretty often you are not even a
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,
> > >
t; 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
> > >
&g
company reasons.
> >
> > Thus I'm +1 for adding it as _optional_ feature.
> >
> > LieGrue,
> > strub
> >
> >
> > >____________
> > > From: Romain Manni-Bucau
> > >To: dev@deltaspike.apache.org
> > >Sent: Sun
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
> >To: dev@deltaspike.apache.org
>
strub
>
> From: Romain Manni-Bucau
>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 bv
ork 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,
>
ork 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 ad
;s mostly a question about what else we like to add into this
>> module.
>> >
>> > LieGrue,
>> > strub
>> >
>> >
>> >
>> > - Original Message -
>> > > From: Gerhard Petracek
>> > > To: dev@d
> > strub
> >
> >
> >
> > - Original Message -
> > > From: Gerhard Petracek
> > > To: dev@deltaspike.apache.org
> > > Cc:
> > > Sent: Saturday, 1 June 2013, 20:25
> > > Subject: Re: DISCUSS DeltaSpike-332
> >
essage -
> > From: Gerhard Petracek
> > 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.
>
aturday, 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 usual
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 sho
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.
Sur
@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
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
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
> Idem, not blocking IMO and bval 1.1 is coming so would be useless soon
> Le 1 juin 2013 15
Idem, not blocking IMO and bval 1.1 is coming so would be useless soon
Le 1 juin 2013 15:56, "Gerhard Petracek" 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
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 thos
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
determi
23 matches
Mail list logo
