Mailing-List: contact dev-help@batchee.incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@batchee.incubator.apache.org
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 9.1 \(3096.5\))
Subject: Re: Looking for help on how to add bean validation to BatchProperty
 injection
From: Mark Struberg <struberg@yahoo.de>
In-Reply-To: 
 <CACLE=7NNhO3USyTqpy1FR5wUJquBBOXwQqiZBVQABtErmTOmBA@mail.gmail.com>
Date: Wed, 11 Nov 2015 21:44:44 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: <6923E5D6-9399-42F3-9626-1AAEDC29F994@yahoo.de>
References: 
 <CAJFLTdwyxv+mZ43xjsFv779tJGrXjF6dDvCP82-WN9irTs2kjw@mail.gmail.com>
 <CACLE=7OSDVtATMOHP-RzxJRdYsyPfuMwN8uzxQs8LWuMC6SmPA@mail.gmail.com>
 <B3E0FC53-8BBA-4FCF-9BB6-7E2BD5957D03@yahoo.de>
 <CACLE=7P8tCes9LdDPu0zNQEC0q6LsyskUeDVMsT4-CXb6AjC4g@mail.gmail.com>
 <B52968B3-BF01-4E34-BB9C-15CA47BE2E4C@yahoo.de>
 <CACLE=7O5gDVsG-24wUAzdGkw22kF6uScnqdhfoRCs8rWJuNuhQ@mail.gmail.com>
 <CACLE=7NNhO3USyTqpy1FR5wUJquBBOXwQqiZBVQABtErmTOmBA@mail.gmail.com>
To: BatchEE Dev BatchEE Dev <dev@batchee.incubator.apache.org>

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=E2=80=99t change.=20
It would not work if your e.g. ItemReader is e.g. a @Stateless.=20

This would require that the producer itself invokes Bean Validation =
_after_ it got fully created and _before_ it got put =E2=80=9Ainto =
context=E2=80=98.
We could certainly add this to the CDI spec as new feature. And EJB =
could do the same=E2=80=A6

LieGrue,
strub


> Am 11.11.2015 um 21:17 schrieb Romain Manni-Bucau =
<rmannibucau@gmail.com>:
>=20
> FYI I pinged CDI list about https://issues.jboss.org/browse/CDI-10
>=20
>=20
> 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>
>=20
> 2015-11-11 11:52 GMT-08:00 Romain Manni-Bucau <rmannibucau@gmail.com>:
>=20
>>=20
>> 2015-11-11 11:40 GMT-08:00 Mark Struberg <struberg@yahoo.de>:
>>=20
>>> Inside the producer you do have the native Type. So proxying should =
not
>>> be an issue.
>>>=20
>>> Also, @Dependent scoped beans don=E2=80=99t get any NormalScoping =
proxy. And
>>> final classes like String, Integer etc cannot get proxied at all ;)
>>>=20
>>>=20
>> Dont get these 2 statements since I spoke about the component =
instance -
>> think you speak about the property itself.
>>=20
>>=20
>> public class SuperI5Processor {
>>  @BatchProperty @Inject private int cores;
>> }
>>=20
>> I'd do validateProperty(i5,"cores",
>> extractGroupsOrDefaultFromProperty(...something to decide....));
>>=20
>>=20
>>> I=E2=80=99d also not use validateProperty but validateValue.
>>>=20
>>>=20
>> Then it changes a bit the violations and restricts the validation but =
can
>> work.
>>=20
>>=20
>>>=20
>>> LieGrue,
>>> strub
>>>=20
>>>> Am 11.11.2015 um 19:36 schrieb Romain Manni-Bucau <
>>> rmannibucau@gmail.com>:
>>>>=20
>>>> 2015-11-11 10:32 GMT-08:00 Mark Struberg <struberg@yahoo.de>:
>>>>=20
>>>>> Just to get me on the right track.
>>>>>=20
>>>>> What=E2=80=99s missing now is something like
>>>>>=20
>>>>> @BatchProperty(=E2=80=9Enumber.open.ports=E2=80=9C)
>>>>> @javax.validation.constraints.NotNull
>>>>> @javax.validation.constraints.Min(1000)
>>>>> private String openPort;
>>>>>=20
>>>>> to make sure that the param is really set and is >=3D 1000 ?
>>>>>=20
>>>>> 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=E2=80=99s
>>>>> value=E2=80=A6
>>>>> Means we can call BVal at this point, right?
>>>>>=20
>>>>>=20
>>>> well you dont have first parameter of
>>>>=20
>>> =
https://docs.oracle.com/javaee/7/api/javax/validation/Validator.html#valid=
ateProperty-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.
>>>>=20
>>>>=20
>>>>> LieGrue,
>>>>> strub
>>>>>=20
>>>>>=20
>>>>>=20
>>>>>> Am 11.11.2015 um 18:18 schrieb Romain Manni-Bucau <
>>> rmannibucau@gmail.com
>>>>>> :
>>>>>>=20
>>>>>> Hi Scott,
>>>>>>=20
>>>>>> here are the few points I have in mind and which I think we =
should
>>>>> consider
>>>>>> before just doing a validate(jbatchComponent):
>>>>>>=20
>>>>>> - [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.
>>>>>>=20
>>>>>> - [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.
>>>>>>=20
>>>>>>=20
>>>>>> Does it make sense - sorry for the big paragraph ;)?
>>>>>>=20
>>>>>>=20
>>>>>>=20
>>>>>> 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>
>>>>>>=20
>>>>>> 2015-11-11 8:34 GMT-08:00 Scott Kurz <skurz3@gmail.com>:
>>>>>>=20
>>>>>>> Hi,
>>>>>>>=20
>>>>>>> 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).
>>>>>>>=20
>>>>>>> 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...
>>>>>>>=20
>>>>>>> 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.
>>>>>>>=20
>>>>>>> Do you know what's missing then?  What's the next step?
>>>>>>>=20
>>>>>>> Any suggestions appreciated..thanks,
>>>>>>> Scott
>>>=20
>>>=20
>>=20