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 17:58:02 GMT
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