Bug 5075 - Injecting JobOperator
Injecting JobOperator
Status: NEW
Product: jbatch
Classification: Unclassified
Component: SPEC
1
PC Mac OS
: P5 enhancement
: ---
Assigned To: ScottKurz
future
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2013-06-08 00:31 UTC by arungupta
Modified: 2013-11-08 00:33 UTC (History)
4 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
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.