Bugzilla – Full Text Bug Listing
|Severity:||enhancement||CC:||atsticks, issues, mminella, reza_rahman|
Description arungupta 2013-06-08 00:31:21 UTC
JobOperator jo = BatchRuntime.getJobOperator(); does not align very well with the CDI-way of doing things in Java EE 7. A better way would be: @Inject JobOperator jo; This request has been asked multiple times at different conferences around the world.
Comment 1 atsticks 2013-06-08 17:03:05 UTC
I also think batch must integrate with cdi asap.
Comment 2 reza_rahman 2013-06-08 17:15:23 UTC
+1 for me.
Comment 3 mminella 2013-10-29 14:58:19 UTC
In Spring this would be handled with a FactoryBean. Couldn't this just be handled with a Producer without the need to add CDI specific language to the spec?
Comment 4 ScottKurz 2013-10-29 15:03:59 UTC
So say we were to take the same approach as we did with injecting the properties and contexts, and say that the API was: @Inject JobOperator jobOp without specifying whether it's CDI, or some other DI. How would that then fit with the Spring approach?
Comment 5 mminella 2013-10-29 15:24:13 UTC
With Spring Batch's implementation of the JSR, we have a FactoryBean that creates the Job/Step contexts to handle the @Inject scenario. I understand how @Inject for the JobOperator looks in the EE world. How does this proposal work in the SE world? Right now, all of the @Inject requirements still work in the SE world. This one is a bit different since the JobOperator is the entrance point for a batch application and probably provides/needs some bootstrapping.