Bug 5075

Summary: Injecting JobOperator
Product: jbatch Reporter: arungupta
Component: SPECAssignee: ScottKurz
Status: NEW ---    
Severity: enhancement CC: atsticks, issues, mminella, reza_rahman
Priority: P5    
Version: 1   
Target Milestone: ---   
Hardware: PC   
OS: Mac OS   
Whiteboard:

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.