Bugzilla – Bug 5075
Last modified: 2013-11-08 00:33:02 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.
I also think batch must integrate with cdi asap.
+1 for me.
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?
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?
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.