Bug 5382

Summary: Support common java types in @BatchProperty injection
Product: jbatch Reporter: cf126330
Component: SPECAssignee: ScottKurz
Status: NEW ---    
Severity: enhancement CC: issues, jrperkinsjr, rmannibucau
Priority: P5    
Version: 1   
Target Milestone: ---   
Hardware: All   
OS: All   

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.