Bugzilla – Full Text Bug Listing
|Summary:||Support common java types in @BatchProperty injection|
|Severity:||enhancement||CC:||issues, jrperkinsjr, rmannibucau|
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, @BatchProperty 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 List<String> Map<String, String> Set<String> BigInteger BitDecimal java.util.Date java.io.File java.util.jar.JarFile java.util.regex.Pattern URL URI Inet4Address Inet6Address java.util.logging.Logger java.lang.Class
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 org.apache.xbean.propertyeditor.PropertyEditors http://geronimo.apache.org/maven/xbean/3.6/xbean-reflect/apidocs/org/apache/xbean/propertyeditor/package-tree.html --- 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.