You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@deltaspike.apache.org by "John D. Ament" <jo...@gmail.com> on 2013/06/01 13:35:31 UTC
DISCUSS DeltaSpike-332
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
Re: DISCUSS DeltaSpike-332
Posted by Gerhard Petracek <ge...@gmail.com>.
hi john,
i don't agree with everything you wrote, but that isn't important for now.
you should test all your applications in any case (esp. with the approach
used by the bv-module of seam3).
furthermore, it isn't the only alternative you have.
once you show users the possible alternatives, a lot of them prefer e.g.
BeanProvider.injectFields(this) in ConstraintValidator#initialize, because
it's simple enough and they just have 1-3 constraint-validators which need
it at all (and you don't need an additional dependency for it).
anyway, imo it doesn't make sense to continue the discussion without an
agreed deprecation-strategy.
regards,
gerhard
2013/6/2 John D. Ament <jo...@gmail.com>
> Gerhard,
>
> It's not feasible to test a server upgrade ourselves. It's not about
> checking whether or not the server accepts it, but that all of the
> applications on the server accept it. Let's say you're running a weblogic
> instance that has 4 different apps on it. Each of those 4 apps needs to be
> regression tested to ensure that the upgrade of the library doesn't impact
> any functionality.
>
> This is easy to do if you have automated testing, but not many people
> actually have this setup in a way to run to cover high enough to verify
> there are no issues.
>
> John
>
>
> On Sun, Jun 2, 2013 at 8:07 AM, Gerhard Petracek <
> gerhard.petracek@gmail.com
> > wrote:
>
> > @ mark:
> > you aren't allowed to replace such libs manually (in the server itself),
> > but e.g. in wls you have an own config-mechanism to do exactly that (per
> > application).
> > before we just add a whole module for it, we should test such upgrades
> with
> > the servers in question.
> > upgrading other libs like jsf is done frequently (without issues).
> >
> > @ john:
> > i've talked with a lot of people about this topic (since 2011 -> way
> before
> > bv 1.1).
> > (most) conservative teams wouldn't even add an additional dependency to
> get
> > rid of 3-4 lines (per application).
> > others will keep codi or whatever they have until ee7, since there is no
> > issue with doing that.
> >
> > i would also question our ViewScopedContext (not only due to jsf 2.2).
> > however, we don't have a whole module for it and there aren't that many
> > alternatives (like with bv) -> i'm fine with keeping it (for now).
> >
> > regards,
> > gerhard
> >
> >
> >
> > 2013/6/2 Romain Manni-Bucau <rm...@gmail.com>
> >
> > > Hmm, thinking of it we should consider how hard it is to dev and
> maintain
> > > and if it is the same code as the new version of the lib. If so thats
> not
> > > relevant IMO, if easy and small enough it could be added IMHO
> > > Le 2 juin 2013 13:08, "John D. Ament" <jo...@gmail.com> a
> écrit :
> > >
> > > > Definitely. When you're a consultant, you typically don't tell what
> > > 3PL's
> > > > you're using (just dealt with this recently, found some GPL in our
> > > > product... not fun). Adding in a 3PL that is apache licensed is
> > > typically
> > > > ok. Upgrading a core app server lib without real reason for it is a
> > > pain.
> > > > Right now, I think JBoss ans TomEE do it quite easily but the big
> boys
> > > > (WebLogic & WebSphere) it's still a bit of a pain. Sometimes your
> app
> > is
> > > > running on shared binaries, so then both apps need to be updated and
> > you
> > > > can't embed the library update for whatever class loading problem
> comes
> > > up.
> > > >
> > > > Anyways, thanks Mark & Jason for support on this.
> > > >
> > > > I agree w/ Gerhard, we need a general strategy for introducing stuff
> > > added
> > > > by later EE specs. It seems like we're inconsistent WRT this topic;
> > e.g.
> > > > JSF features were added, Servlet features are getting added, but JMS
> > and
> > > > BeanVal seemed to cause disdain in the group (not sure if it's who
> > > proposed
> > > > it or the lack of use of these specs).
> > > >
> > > > John
> > > >
> > > >
> > > > On Sun, Jun 2, 2013 at 5:03 AM, Romain Manni-Bucau <
> > > rmannibucau@gmail.com
> > > > >wrote:
> > > >
> > > > > 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" <st...@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 <rm...@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" <li...@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
> > > > > > >> <ge...@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 <an...@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 <st...@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 <ge...@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.thomas@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.petracek@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 <ha...@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 <
> > rmannibucau@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.petracek@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
> > > > > > >> >> > > <jo...@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
> > > > > > >> >> > >> > >
> > > > > > >> >> > >> >
> > > > > > >> >> > >>
> > > > > > >> >> > >
> > > > > > >> >> >
> > > > > > >> >>
> > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
>
Re: DISCUSS DeltaSpike-332
Posted by "John D. Ament" <jo...@gmail.com>.
Gerhard,
It's not feasible to test a server upgrade ourselves. It's not about
checking whether or not the server accepts it, but that all of the
applications on the server accept it. Let's say you're running a weblogic
instance that has 4 different apps on it. Each of those 4 apps needs to be
regression tested to ensure that the upgrade of the library doesn't impact
any functionality.
This is easy to do if you have automated testing, but not many people
actually have this setup in a way to run to cover high enough to verify
there are no issues.
John
On Sun, Jun 2, 2013 at 8:07 AM, Gerhard Petracek <gerhard.petracek@gmail.com
> wrote:
> @ mark:
> you aren't allowed to replace such libs manually (in the server itself),
> but e.g. in wls you have an own config-mechanism to do exactly that (per
> application).
> before we just add a whole module for it, we should test such upgrades with
> the servers in question.
> upgrading other libs like jsf is done frequently (without issues).
>
> @ john:
> i've talked with a lot of people about this topic (since 2011 -> way before
> bv 1.1).
> (most) conservative teams wouldn't even add an additional dependency to get
> rid of 3-4 lines (per application).
> others will keep codi or whatever they have until ee7, since there is no
> issue with doing that.
>
> i would also question our ViewScopedContext (not only due to jsf 2.2).
> however, we don't have a whole module for it and there aren't that many
> alternatives (like with bv) -> i'm fine with keeping it (for now).
>
> regards,
> gerhard
>
>
>
> 2013/6/2 Romain Manni-Bucau <rm...@gmail.com>
>
> > Hmm, thinking of it we should consider how hard it is to dev and maintain
> > and if it is the same code as the new version of the lib. If so thats not
> > relevant IMO, if easy and small enough it could be added IMHO
> > Le 2 juin 2013 13:08, "John D. Ament" <jo...@gmail.com> a écrit :
> >
> > > Definitely. When you're a consultant, you typically don't tell what
> > 3PL's
> > > you're using (just dealt with this recently, found some GPL in our
> > > product... not fun). Adding in a 3PL that is apache licensed is
> > typically
> > > ok. Upgrading a core app server lib without real reason for it is a
> > pain.
> > > Right now, I think JBoss ans TomEE do it quite easily but the big boys
> > > (WebLogic & WebSphere) it's still a bit of a pain. Sometimes your app
> is
> > > running on shared binaries, so then both apps need to be updated and
> you
> > > can't embed the library update for whatever class loading problem comes
> > up.
> > >
> > > Anyways, thanks Mark & Jason for support on this.
> > >
> > > I agree w/ Gerhard, we need a general strategy for introducing stuff
> > added
> > > by later EE specs. It seems like we're inconsistent WRT this topic;
> e.g.
> > > JSF features were added, Servlet features are getting added, but JMS
> and
> > > BeanVal seemed to cause disdain in the group (not sure if it's who
> > proposed
> > > it or the lack of use of these specs).
> > >
> > > John
> > >
> > >
> > > On Sun, Jun 2, 2013 at 5:03 AM, Romain Manni-Bucau <
> > rmannibucau@gmail.com
> > > >wrote:
> > >
> > > > 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" <st...@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 <rm...@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" <li...@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
> > > > > >> <ge...@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 <an...@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 <st...@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 <ge...@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 <an...@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 <ge...@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 <ha...@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 <
> rmannibucau@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.petracek@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
> > > > > >> >> > > <jo...@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
> > > > > >> >> > >> > >
> > > > > >> >> > >> >
> > > > > >> >> > >>
> > > > > >> >> > >
> > > > > >> >> >
> > > > > >> >>
> > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
>
Re: DISCUSS DeltaSpike-332
Posted by Gerhard Petracek <ge...@gmail.com>.
@ mark:
you aren't allowed to replace such libs manually (in the server itself),
but e.g. in wls you have an own config-mechanism to do exactly that (per
application).
before we just add a whole module for it, we should test such upgrades with
the servers in question.
upgrading other libs like jsf is done frequently (without issues).
@ john:
i've talked with a lot of people about this topic (since 2011 -> way before
bv 1.1).
(most) conservative teams wouldn't even add an additional dependency to get
rid of 3-4 lines (per application).
others will keep codi or whatever they have until ee7, since there is no
issue with doing that.
i would also question our ViewScopedContext (not only due to jsf 2.2).
however, we don't have a whole module for it and there aren't that many
alternatives (like with bv) -> i'm fine with keeping it (for now).
regards,
gerhard
2013/6/2 Romain Manni-Bucau <rm...@gmail.com>
> Hmm, thinking of it we should consider how hard it is to dev and maintain
> and if it is the same code as the new version of the lib. If so thats not
> relevant IMO, if easy and small enough it could be added IMHO
> Le 2 juin 2013 13:08, "John D. Ament" <jo...@gmail.com> a écrit :
>
> > Definitely. When you're a consultant, you typically don't tell what
> 3PL's
> > you're using (just dealt with this recently, found some GPL in our
> > product... not fun). Adding in a 3PL that is apache licensed is
> typically
> > ok. Upgrading a core app server lib without real reason for it is a
> pain.
> > Right now, I think JBoss ans TomEE do it quite easily but the big boys
> > (WebLogic & WebSphere) it's still a bit of a pain. Sometimes your app is
> > running on shared binaries, so then both apps need to be updated and you
> > can't embed the library update for whatever class loading problem comes
> up.
> >
> > Anyways, thanks Mark & Jason for support on this.
> >
> > I agree w/ Gerhard, we need a general strategy for introducing stuff
> added
> > by later EE specs. It seems like we're inconsistent WRT this topic; e.g.
> > JSF features were added, Servlet features are getting added, but JMS and
> > BeanVal seemed to cause disdain in the group (not sure if it's who
> proposed
> > it or the lack of use of these specs).
> >
> > John
> >
> >
> > On Sun, Jun 2, 2013 at 5:03 AM, Romain Manni-Bucau <
> rmannibucau@gmail.com
> > >wrote:
> >
> > > 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" <st...@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 <rm...@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" <li...@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
> > > > >> <ge...@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 <an...@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 <st...@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 <ge...@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 <an...@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 <ge...@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 <ha...@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 <rmannibucau@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.petracek@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
> > > > >> >> > > <jo...@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
> > > > >> >> > >> > >
> > > > >> >> > >> >
> > > > >> >> > >>
> > > > >> >> > >
> > > > >> >> >
> > > > >> >>
> > > > >
> > > > >
> > > >
> > >
> >
>
Re: DISCUSS DeltaSpike-332
Posted by Romain Manni-Bucau <rm...@gmail.com>.
Hmm, thinking of it we should consider how hard it is to dev and maintain
and if it is the same code as the new version of the lib. If so thats not
relevant IMO, if easy and small enough it could be added IMHO
Le 2 juin 2013 13:08, "John D. Ament" <jo...@gmail.com> a écrit :
> Definitely. When you're a consultant, you typically don't tell what 3PL's
> you're using (just dealt with this recently, found some GPL in our
> product... not fun). Adding in a 3PL that is apache licensed is typically
> ok. Upgrading a core app server lib without real reason for it is a pain.
> Right now, I think JBoss ans TomEE do it quite easily but the big boys
> (WebLogic & WebSphere) it's still a bit of a pain. Sometimes your app is
> running on shared binaries, so then both apps need to be updated and you
> can't embed the library update for whatever class loading problem comes up.
>
> Anyways, thanks Mark & Jason for support on this.
>
> I agree w/ Gerhard, we need a general strategy for introducing stuff added
> by later EE specs. It seems like we're inconsistent WRT this topic; e.g.
> JSF features were added, Servlet features are getting added, but JMS and
> BeanVal seemed to cause disdain in the group (not sure if it's who proposed
> it or the lack of use of these specs).
>
> John
>
>
> On Sun, Jun 2, 2013 at 5:03 AM, Romain Manni-Bucau <rmannibucau@gmail.com
> >wrote:
>
> > 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" <st...@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 <rm...@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" <li...@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
> > > >> <ge...@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 <an...@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 <st...@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 <ge...@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 <an...@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 <ge...@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 <ha...@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 <rm...@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.petracek@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
> > > >> >> > > <jo...@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
> > > >> >> > >> > >
> > > >> >> > >> >
> > > >> >> > >>
> > > >> >> > >
> > > >> >> >
> > > >> >>
> > > >
> > > >
> > >
> >
>
Re: DISCUSS DeltaSpike-332
Posted by "John D. Ament" <jo...@gmail.com>.
Definitely. When you're a consultant, you typically don't tell what 3PL's
you're using (just dealt with this recently, found some GPL in our
product... not fun). Adding in a 3PL that is apache licensed is typically
ok. Upgrading a core app server lib without real reason for it is a pain.
Right now, I think JBoss ans TomEE do it quite easily but the big boys
(WebLogic & WebSphere) it's still a bit of a pain. Sometimes your app is
running on shared binaries, so then both apps need to be updated and you
can't embed the library update for whatever class loading problem comes up.
Anyways, thanks Mark & Jason for support on this.
I agree w/ Gerhard, we need a general strategy for introducing stuff added
by later EE specs. It seems like we're inconsistent WRT this topic; e.g.
JSF features were added, Servlet features are getting added, but JMS and
BeanVal seemed to cause disdain in the group (not sure if it's who proposed
it or the lack of use of these specs).
John
On Sun, Jun 2, 2013 at 5:03 AM, Romain Manni-Bucau <rm...@gmail.com>wrote:
> 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" <st...@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 <rm...@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" <li...@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
> > >> <ge...@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 <an...@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 <st...@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 <ge...@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 <an...@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 <ge...@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 <ha...@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 <rm...@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.petracek@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
> > >> >> > > <jo...@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
> > >> >> > >> > >
> > >> >> > >> >
> > >> >> > >>
> > >> >> > >
> > >> >> >
> > >> >>
> > >
> > >
> >
>
Re: DISCUSS DeltaSpike-332
Posted by Romain Manni-Bucau <rm...@gmail.com>.
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" <st...@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 <rm...@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" <li...@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
> >> <ge...@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 <an...@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 <st...@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 <ge...@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 <an...@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 <ge...@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 <ha...@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 <rm...@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.petracek@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
> >> >> > > <jo...@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
> >> >> > >> > >
> >> >> > >> >
> >> >> > >>
> >> >> > >
> >> >> >
> >> >>
> >
> >
>
Re: DISCUSS DeltaSpike-332
Posted by Mark Struberg <st...@yahoo.de>.
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 <rm...@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" <li...@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
>> <ge...@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 <an...@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 <st...@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 <ge...@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 <an...@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 <ge...@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 <ha...@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 <rm...@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.petracek@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
>> >> > > <jo...@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
>> >> > >> > >
>> >> > >> >
>> >> > >>
>> >> > >
>> >> >
>> >>
>
>
Re: DISCUSS DeltaSpike-332
Posted by Romain Manni-Bucau <rm...@gmail.com>.
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" <li...@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
> <ge...@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 <an...@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 <st...@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 <ge...@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 <an...@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 <ge...@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 <ha...@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 <rm...@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.petracek@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
> >> > > <jo...@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
> >> > >> > >
> >> > >> >
> >> > >>
> >> > >
> >> >
> >>
Re: DISCUSS DeltaSpike-332
Posted by Jason Porter <li...@gmail.com>.
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
<ge...@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 <an...@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 <st...@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 <ge...@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 <an...@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 <ge...@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 <ha...@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 <rm...@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.petracek@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
>> > > <jo...@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
>> > >> > >
>> > >> >
>> > >>
>> > >
>> >
>>
Re: DISCUSS DeltaSpike-332
Posted by Gerhard Petracek <ge...@gmail.com>.
maybe our next step should be an agreed deprecation-strategy (before we
continue with such topics).
regards,
gerhard
2013/6/1 Gerhard Petracek <ge...@gmail.com>
> 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 <an...@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 <st...@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 <ge...@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 <an...@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 <ge...@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 <ha...@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 <rm...@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.petracek@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
>> > > <jo...@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
>> > >> > >
>> > >> >
>> > >>
>> > >
>> >
>>
>
>
Re: DISCUSS DeltaSpike-332
Posted by Gerhard Petracek <ge...@gmail.com>.
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 <an...@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 <st...@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 <ge...@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 <an...@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 <ge...@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 <ha...@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 <rm...@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.petracek@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
> > > <jo...@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
> > >> > >
> > >> >
> > >>
> > >
> >
>
Re: DISCUSS DeltaSpike-332
Posted by Thomas Andraschko <an...@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 <st...@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 <ge...@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 <an...@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 <ge...@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 <ha...@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 <rm...@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.petracek@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
> > <jo...@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
> >> > >
> >> >
> >>
> >
>
Re: DISCUSS DeltaSpike-332
Posted by Mark Struberg <st...@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 <ge...@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 <an...@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 <ge...@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 <ha...@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 <rm...@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.petracek@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
> <jo...@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
>> > >
>> >
>>
>
Re: DISCUSS DeltaSpike-332
Posted by Gerhard Petracek <ge...@gmail.com>.
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 <an...@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 <ge...@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 <ha...@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 <rm...@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.petracek@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 <jo...@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
> > >
> >
>
Re: DISCUSS DeltaSpike-332
Posted by Thomas Andraschko <an...@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 <ge...@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 <ha...@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 <rm...@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" <ge...@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 <jo...@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
> >
>
Re: DISCUSS DeltaSpike-332
Posted by Gerhard Petracek <ge...@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 <ha...@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 <rm...@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" <ge...@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 <jo...@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
>
Re: DISCUSS DeltaSpike-332
Posted by hantsy <ha...@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 <rm...@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" <ge...@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 <jo...@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
Re: DISCUSS DeltaSpike-332
Posted by Thomas Andraschko <an...@gmail.com>.
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 <rm...@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" <ge...@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 <jo...@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
> > >
> >
>
Re: DISCUSS DeltaSpike-332
Posted by Romain Manni-Bucau <rm...@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" <ge...@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 <jo...@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
> >
>
Re: DISCUSS DeltaSpike-332
Posted by Gerhard Petracek <ge...@gmail.com>.
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 <jo...@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
>
Re: DISCUSS DeltaSpike-332
Posted by Mark Struberg <st...@yahoo.de>.
Sounds ok.
As far as I've understood the bval spec no reusable library must add any validation.xml because this file must only exists once for the whole app. There is no way of 'overloading' or preconfiguration for it as far as I'm aware.
LieGrue,
strub
----- Original Message -----
> From: John D. Ament <jo...@gmail.com>
> 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 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 ahead and implement this as the following:
>
> 1. Create a new beanval module.
> 2. Create a runtime only dependency that adds a class
> "CDIAwareConstraintValidatorFactory" to the JAR. (e.g. there's no
> API,
> nothing to program against, only impl).
> 3. Add instructions on how to configure in validation.xml
>
> Note that the configuration of validation.xml will be the optional
> component, e.g. if you don't do this then the default implementation will
> continue.
>
> John
>
>
> On Sat, Jun 1, 2013 at 7:35 AM, John D. Ament
> <jo...@gmail.com>wrote:
>
>> 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
>>
>
Re: DISCUSS DeltaSpike-332
Posted by "John D. Ament" <jo...@gmail.com>.
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 ahead and implement this as the following:
1. Create a new beanval module.
2. Create a runtime only dependency that adds a class
"CDIAwareConstraintValidatorFactory" to the JAR. (e.g. there's no API,
nothing to program against, only impl).
3. Add instructions on how to configure in validation.xml
Note that the configuration of validation.xml will be the optional
component, e.g. if you don't do this then the default implementation will
continue.
John
On Sat, Jun 1, 2013 at 7:35 AM, John D. Ament <jo...@gmail.com>wrote:
> 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
>