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:36:58 GMT
I think I'm still missing something and not appreciating the full set of
ideas here.

One thing, though, is that it might be best to discuss on the spec ML to
get other input, especially since this is such a big change proposed to the
API.

In the meantime, my quick thoughts:

1) I'm not following the difficulty with the threadlocal in the "advanced
custom scope" case.    The batch spec itself scopes the batch artifacts,
one per step or job (mostly).    Were you thinking the issue was scoping
the batch artifacts themselves with a custom scope?  Or was this a case
where we were trying to inject some other CDI bean with batch properties in
the scope of the batch artifact?

2) Why can't you dynamically update maxValueForColumnC already today?   No,
the batch container doesn't help you, but it doesn't in your proposal
either, right?   What integration are you getting that I'm not seeing?

3)  For your MyProcessors example, not sure if the point is just a strongly
typed interface (as in https://java.net/bugzilla/show_bug.cgi?id=7295) or
the ability to have >1 process method.

NO







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

> Ok let try to rephrase it with more code samples :)
>
> I'll take the processor case to explain it but please keep it in mind it
> can be extended to all jbatch components technically.
>
> 1. Starting point: current API is typed: ItemProcessor.
> 2. Observations:
> - it is not stringly typed (:( forces users to cast)
> - type is not really used (a user never calls process or need to type it)
> 3. Going.next: 2) makes me think we can enhance a lot the API making a
> command oriented API getting rid of all JBatch interfaces (= making them
> optional).
>
> A processor would then be:
>
> public class MyProcessors {
>     @Processor("processorForDbRecords")
>     public MyEntity process(final DbRecordReturnedByTheReader db) {
>         // do something super clever to convert one object to another one
> ;)
>     }
>
>     @Processor("processorForFileRecords")
>     public MyEntity process(final CsvRecord record) {
>         // do something super clever to convert one object to another one
> ;)
>     }
>
>     // ... and much more if desired in term of user app design
> }
>
> Previous sample is just 1-1 with current interface so doesnt bring much but
> if you add property injection (like @PathParam in JAXRS) you get:
>
>
> public class MyProcessor {
>     @Processor("processorForDbRecords")
>     public MyEntity process(final DbRecordReturnedByTheReader in,
> @BatchProperty("maxValueForColumnC") int max /*, other properties with ~
> JAXRS conversion rules? */) {
>         if (in.getC() > max) { /* exception/skip the record */ }
>         // convert in to MyEntity
>     }
> }
>
> Once we have that, whatever IoC we use we integrate smoothly with it cause
> most of validation/security/enriching/... is done through interceptors in
> today's frameworks. means JBatch doesnt need to worry about integrations at
> all and only care to build parameters properly which is not that
> complicated. It also ensures the properties are setup when needed (when
> JBatch calls the method) and not potentially unset - currently with CDI
> scopes the property producer can not have set the threadlocal holding
> properties if the user use an advanced custom scope and we can't really
> help it.
>
> To give a sample of free integration we get with it which is not bval
> related: if I write a CDI interceptor I can change maxValueForColumnC
> depending business rules (value configured through JMX or any admin
> solution) dynamically at runtime, even during batch execution using
>
> http://docs.oracle.com/javaee/7/api/javax/interceptor/InvocationContext.html#setParameters-java.lang.Object:A-
> .
>
> Drawback: changes a bit the main API
> Advantages:
> - in term of implementation we can still wire this to the old API so I dont
> see the code being very complicated cause of that
> - integrate really smoothly with IoC/containers
> - better JBatch values/properties lifecycle handling
> - typed API
> - [very subjective?] more modern API
>
>
> Hope it is clearer :)
>
> @batchee dev: since we are on batchee list (;)): do we want to try such
> API? today we can provide wrappers with a light integration with our
> injection references to achieve it?
>
>
>
> 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 9:40 GMT-08:00 Scott Kurz <skurz3@gmail.com>:
>
> > Romain,
> >
> > Thanks for the suggestions!
> >
> > I hadn't realized the CDI validation only kicks in out of the box with
> > setter and ctor injection ( I want to add the setter/ctor options as
> > annotation targets for 1.1 as well).     Sorry if that was a dumb
> > question... I was just confused why the bean validation wasn't already
> > happening today in the field injection case, and knew I was missing
> > something .  But I'll try calling Validator from the jbatch Producer.
> >
> > I'd only been thinking in terms of validating one property at a time.
> > Not seeing that the spec should go out of the way to assist you in
> changing
> > the state.
> >
> > Sorry, but I don't think I followed your first paragraph at all ;)    I
> > think I'd need you to spell that out to me in more detail, though it
> sounds
> > like it's a big enough change that would need to be discussed on the spec
> > mailing list.
> >
> > Thanks,
> > Scott
> >
> > On Wed, Nov 11, 2015 at 12:18 PM, Romain Manni-Bucau <
> > rmannibucau@gmail.com>
> > wrote:
> >
> > > 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