batchee-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Scott Kurz <sku...@gmail.com>
Subject Re: Looking for help on how to add bean validation to BatchProperty injection
Date Tue, 17 Nov 2015 16:56:46 GMT
This is interesting, though I'm not following much of the pros and cons of
validating the instance as a whole vs. validating one property at a time.

So say we added the ability to annotate a setter with @BatchProperty.

When would the already-existing builtin BeanValidation+CDI validation kick
in?   At the moment when the setter is called?

If so, that might be enough for batch especially if the field-based options
require various spec updates (sounds like CDI and EJB were mentioned).
Though I'm not following that point either, e.g. not following Mark's
comment about "It would not work if your e.g. ItemReader is e.g. a
@Stateless."

Anyway, I'm sure this is enough to start prototyping when I get a chance,
but appreciate all the enlightenment in the meantime.

Thanks,
Scott





On Wed, Nov 11, 2015 at 4:34 PM, Romain Manni-Bucau <rmannibucau@gmail.com>
wrote:

> yep, a side note is even if we just validate the properties it would be
> better to have the instance to build proper ValidationException and not
> cheap ones without (validateProperty vs validateValue). Also doesnt limit
> the validation (validateValue prevents validating cross fields since you
> dont have the instance which is allowed with validateProperty, a common
> sample is writing a validation constraint using EL)
>
>
> Romain Manni-Bucau
> @rmannibucau <https://twitter.com/rmannibucau> |  Blog
> <http://rmannibucau.wordpress.com> | Github <
> https://github.com/rmannibucau> |
> LinkedIn <https://www.linkedin.com/in/rmannibucau> | Tomitriber
> <http://www.tomitribe.com>
>
> 2015-11-11 12:44 GMT-08:00 Mark Struberg <struberg@yahoo.de>:
>
> > Oh I c. You were talking about invoking the validation on the whole
> jbatch
> > artifact (which might be a proxy).
> >
> > Perfectly possible if we get the unwrap() AND the Contextual Instance
> > doesn’t change.
> > It would not work if your e.g. ItemReader is e.g. a @Stateless.
> >
> > This would require that the producer itself invokes Bean Validation
> > _after_ it got fully created and _before_ it got put ‚into context‘.
> > We could certainly add this to the CDI spec as new feature. And EJB could
> > do the same…
> >
> > LieGrue,
> > strub
> >
> >
> > > Am 11.11.2015 um 21:17 schrieb Romain Manni-Bucau <
> rmannibucau@gmail.com
> > >:
> > >
> > > FYI I pinged CDI list about https://issues.jboss.org/browse/CDI-10
> > >
> > >
> > > Romain Manni-Bucau
> > > @rmannibucau <https://twitter.com/rmannibucau> |  Blog
> > > <http://rmannibucau.wordpress.com> | Github <
> > https://github.com/rmannibucau> |
> > > LinkedIn <https://www.linkedin.com/in/rmannibucau> | Tomitriber
> > > <http://www.tomitribe.com>
> > >
> > > 2015-11-11 11:52 GMT-08:00 Romain Manni-Bucau <rmannibucau@gmail.com>:
> > >
> > >>
> > >> 2015-11-11 11:40 GMT-08:00 Mark Struberg <struberg@yahoo.de>:
> > >>
> > >>> Inside the producer you do have the native Type. So proxying should
> not
> > >>> be an issue.
> > >>>
> > >>> Also, @Dependent scoped beans don’t get any NormalScoping proxy.
And
> > >>> final classes like String, Integer etc cannot get proxied at all ;)
> > >>>
> > >>>
> > >> Dont get these 2 statements since I spoke about the component
> instance -
> > >> think you speak about the property itself.
> > >>
> > >>
> > >> public class SuperI5Processor {
> > >>  @BatchProperty @Inject private int cores;
> > >> }
> > >>
> > >> I'd do validateProperty(i5,"cores",
> > >> extractGroupsOrDefaultFromProperty(...something to decide....));
> > >>
> > >>
> > >>> I’d also not use validateProperty but validateValue.
> > >>>
> > >>>
> > >> Then it changes a bit the violations and restricts the validation but
> > can
> > >> work.
> > >>
> > >>
> > >>>
> > >>> LieGrue,
> > >>> strub
> > >>>
> > >>>> Am 11.11.2015 um 19:36 schrieb Romain Manni-Bucau <
> > >>> rmannibucau@gmail.com>:
> > >>>>
> > >>>> 2015-11-11 10:32 GMT-08:00 Mark Struberg <struberg@yahoo.de>:
> > >>>>
> > >>>>> Just to get me on the right track.
> > >>>>>
> > >>>>> What’s missing now is something like
> > >>>>>
> > >>>>> @BatchProperty(„number.open.ports“)
> > >>>>> @javax.validation.constraints.NotNull
> > >>>>> @javax.validation.constraints.Min(1000)
> > >>>>> private String openPort;
> > >>>>>
> > >>>>> to make sure that the param is really set and is >= 1000
?
> > >>>>>
> > >>>>> In that case we could do this inside the
> > >>>>> BatchProducerBean#produceProperty, right?
> > >>>>> An injected BatchProperty is ALWAYS @Dependent scoped, thus
we get
> > the
> > >>>>> InjectionPoint for it.
> > >>>>> And thus we also get the actual Field in question and we also
have
> > it’s
> > >>>>> value…
> > >>>>> Means we can call BVal at this point, right?
> > >>>>>
> > >>>>>
> > >>>> well you dont have first parameter of
> > >>>>
> > >>>
> >
> https://docs.oracle.com/javaee/7/api/javax/validation/Validator.html#validateProperty-T-java.lang.String-java.lang.Class...-
> > >>>> in a reliable way cause of proxying AFAIK. That is why I wouldnt
go
> > this
> > >>>> way if CDI spec doesnt add the unwrapped instance part of the
> contract
> > >>> of
> > >>>> InjectionPoint which is not the case today.
> > >>>>
> > >>>>
> > >>>>> LieGrue,
> > >>>>> strub
> > >>>>>
> > >>>>>
> > >>>>>
> > >>>>>> Am 11.11.2015 um 18:18 schrieb Romain Manni-Bucau <
> > >>> rmannibucau@gmail.com
> > >>>>>> :
> > >>>>>>
> > >>>>>> Hi Scott,
> > >>>>>>
> > >>>>>> here are the few points I have in mind and which I think
we should
> > >>>>> consider
> > >>>>>> before just doing a validate(jbatchComponent):
> > >>>>>>
> > >>>>>> - [potential JBatch API enhancement]  CDI has method validation
> for
> > >>> CDI
> > >>>>>> beans already, JBatch is not super friendly with that yet
but
> > nothing
> > >>>>>> prevents us to become - I'd love jbatch to be JAXRS like
in term
> of
> > >>> API
> > >>>>> and
> > >>>>>> no more coupled to a type/interface we dont really need
in term of
> > >>>>> runtime
> > >>>>>> (@Processor TheOutput myProcess(ThePayload instanceToProcess,
> > >>>>>> @BatchProperty("myConfig") String file, ....) to make a
single
> > >>> sample).
> > >>>>>> This would mean free integration with all frameworks on
most of
> > >>> features
> > >>>>>> including validation and much more since most of transversal
> > features
> > >>> are
> > >>>>>> done through interception.
> > >>>>>>
> > >>>>>> - [technical perspective] validating @JBatchProperty values
can be
> > >>> done
> > >>>>>> through CDI/BVal integration using the setters or the constructor
> > >>> instead
> > >>>>>> of the fieds injection. Open point is: do we want to validate
> fields
> > >>>>>> directly in jbatch backbone? The question here is then:
do we
> > validate
> > >>>>>> fields or the jbatch component/instance as a whole? If
we validate
> > >>> only
> > >>>>>> fields it sounds weird to me cause  we have to use
> > >>>>>> Validator#validateProperty but the only place we have the
property
> > >>> would
> > >>>>> be
> > >>>>>> the jbatch property bean/producer cause CDI instance can
be
> proxied
> > >>> and
> > >>>>>> then we wouldnt have the instance itself (said otherwise
we are
> not
> > >>> 100%
> > >>>>>> sure to be able to call it properly). If we validate the
whole
> > >>> instance
> > >>>>> the
> > >>>>>> question is then how to define a lifecycle since the user
can
> expect
> > >>> to
> > >>>>> get
> > >>>>>> validation done between iterations or only initially depending
if
> he
> > >>>>>> modifies or not values - which strictly speaking if probably
a bad
> > >>>>> practise
> > >>>>>> but not forbidden by the spec and can even be required
scoping a
> > >>>>> component.
> > >>>>>> To summarize this thought, I would push to CDI the field
> validation
> > >>>>>> question being said other validations are already built-in
AFAIK.
> > >>>>>>
> > >>>>>>
> > >>>>>> Does it make sense - sorry for the big paragraph ;)?
> > >>>>>>
> > >>>>>>
> > >>>>>>
> > >>>>>> Romain Manni-Bucau
> > >>>>>> @rmannibucau <https://twitter.com/rmannibucau> |
 Blog
> > >>>>>> <http://rmannibucau.wordpress.com> | Github <
> > >>>>> https://github.com/rmannibucau> |
> > >>>>>> LinkedIn <https://www.linkedin.com/in/rmannibucau>
| Tomitriber
> > >>>>>> <http://www.tomitribe.com>
> > >>>>>>
> > >>>>>> 2015-11-11 8:34 GMT-08:00 Scott Kurz <skurz3@gmail.com>:
> > >>>>>>
> > >>>>>>> Hi,
> > >>>>>>>
> > >>>>>>> As you know if you've been watching the 1.1 spec mailing
list,
> I've
> > >>> been
> > >>>>>>> thinking of adding the ability to do bean validation
upon
> > >>> BatchProperty
> > >>>>>>> injection (spec Bug 7291).
> > >>>>>>>
> > >>>>>>> I would like to code something out but figured I'd
stop and ask
> > >>> because
> > >>>>>>> Romain, I know you have a lot of knowledge here...
> > >>>>>>>
> > >>>>>>> So I believe there's already integration between bval
& CDI in
> EE,
> > >>> and
> > >>>>> of
> > >>>>>>> course we can use CDI to inject these batch properties
today.
> > >>>>>>>
> > >>>>>>> Do you know what's missing then?  What's the next step?
> > >>>>>>>
> > >>>>>>> Any suggestions appreciated..thanks,
> > >>>>>>> Scott
> > >>>
> > >>>
> > >>
> >
> >
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message