batchee-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Romain Manni-Bucau <rmannibu...@gmail.com>
Subject Re: Looking for help on how to add bean validation to BatchProperty injection
Date Wed, 11 Nov 2015 21:34:28 GMT
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