Bug 5382 - Support common java types in @BatchProperty injection
Support common java types in @BatchProperty injection
Status: NEW
Product: jbatch
Classification: Unclassified
Component: SPEC
All All
: P5 enhancement
: ---
Assigned To: ScottKurz
Depends on:
  Show dependency treegraph
Reported: 2013-09-11 14:56 UTC by cf126330
Modified: 2015-10-08 13:54 UTC (History)
3 users (show)

See Also:


Note You need to log in before you can comment on or make changes to this bug.
Description cf126330 2013-09-11 14:56:48 UTC
Currently only java.lang.String is supported in @BatchProperty field injection.  For other types of data, applications have to convert from String.  I propose we support all common java types for @BatchProperty field injections, to make batch api easier to use.  A related bug was Bug 4353.

We don't need to change the job xml schema, where properties are still declared as string values.  The batch container is responsible for data conversion behind the scene.  For example,

private int count;

A list of common java types pertaining to batch API:

all primitive types (int, short, byte, long, double, float, boolean, char)
array of all primitive types
wrapper type of all primitive types
array of all wrapper types of primitive types
Map<String, String>
Comment 1 ScottKurz 2015-09-10 17:44:34 UTC
Getting back to this.  

I like the idea.. just wondering 
A) precisely which ones to include/exclude
B) How to reference the specifics of each type of conversion (without having to define it in the batch spec itself).   Not that it would be that hard to do so in our spec..just wondering if this was already defined.

E.g. it seems BatchEE accomplishes this using



I wonder where that would leave JSONObject ?   Not as easy as I'm naively assuming for some reason or just didn't happen to be in that list?
Comment 2 rmannibucau 2015-09-24 21:51:11 UTC
Most probably something like github.com/tomitribe/sabot mecanism (same idea as JAXRS with its fromString or constructor handling) would match very well, I agree.
Comment 3 jrperkinsjr 2015-09-29 20:53:30 UTC
I think the spec should only guarantee that primitives (and their Object types), String, BigDecimal and BigInteger the allowed injection types. Maybe primitive arrays too. Implementations can implement more providers for other types if they'd like.
Comment 4 ScottKurz 2015-10-08 13:54:02 UTC
Seems kind of arbitrary to pick the set beyond the primitives, I agree...

I guess another direction to take this in is to model after JSF Converter, and define some built-in converters and the opportunity for custom converters.

Since JSF and JPA each have a bit different converters, seems like the precedent would be set for batch to define its own.

Would need to be clear if this is part of CDI integration or DI-neutral.