You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@deltaspike.apache.org by Adrian Gonzalez <ad...@yahoo.fr> on 2012/03/20 22:51:41 UTC
Tr : Instantiating Beans specified in XML
Hi,
JBatch spec lead opened this topic about jbatch integration with a DI container (Spring / CDI / whatever).
Donno if someone here is on jbatch list.
If not, it's a good time to register and to participate I think.
If yes, then throw this mail away - sorry ;)
----- Mail transféré -----
De : Christopher Vignola <cv...@us.ibm.com>
À : public@jbatch.java.net
Cc :
Envoyé le : Mardi 20 mars 2012 21h11
Objet : Instantiating Beans specified in XML
We've said from the start, that JSR 352 will deliver a batch runtime,
which we have named "batch container", that will work in both Java SE and
EE environments. We have said it will not require a DI container, but
that it will be DI friendly, meaning you can use DI to instantiate the
batch beans. Batch beans are readers, writers, processors, listeners,
etc.. They are all POJO implementations. They are specified in the job
XML and then need to be instantiated at runtime. So how do we do this in
a way that does not require DI but allows you to optionally use it? What
has Spring Batch and WebSphere Batch done about this?
Spring Batch relies on Spring DI:
In the job XML, you identify the beans by name:
<step id="Step1">
<tasklet>
<chunk reader="MyReader" processor="MyProcessor"
writer="MyWriter">
</tasklet>
</step>
In beans.xml you map names to classes:
<bean id="MyReader" class="com...MyReader" />
<bean id="MyProcessor" class="com...MyProcessor" />
<bean id="MyWriter" class="com...MyWriter" />
And Spring Batch probably works just fine with Spring annotations instead
of static XML bean definitions - e.g. @Service annotation.
Original WebSphere Batch leaves no room for DI by requiring class names:
<job-step name="Step1">
<classname>com...MyProcessor</classname>
<batch-data-streams>
<bds>
<logical-name>MyReader</logical-name>
<impl-class>com...MyReader</impl-class>
</bds>
<bds>
<logical-name>MyWriter</logical-name>
<impl-class>com...MyWriter</impl-class>
</bds>
</batch-data-streams>
</job-step>
We can forget about the original WebSphere Batch approach. We do not want
class names in the job XML.
The latest WebSphere Batch does support the OSGi Blueprint DI container by
treating classnames as "service names' and looking them up in a
blueprint.xml:
<job-step name="Step1">
<classname>MyProcessor</classname>
<batch-data-streams>
<bds>
<logical-name>MyReader</logical-name>
<impl-class>MyReader</impl-class>
</bds>
<bds>
<logical-name>MyWriter</logical-name>
<impl-class>MyWriter</impl-class>
</bds>
</batch-data-streams>
</job-step>
Then in blueprint.xml:
<bean id="MyProcessor" class="com..MyProcessor" scope="prototype"/>
<service ref="MyProcessor" interface="com.ibm.websphere.batch.BatchJobStep"
id="MyProc1">
<service-properties>
<entry key="xjcl:classname" value="MyProcessor"/>
</service-properties>
</service>
<bean id="MyReader" class="com..MyReader" scope="prototype"/>
<service ref="MyReader" interface="com.ibm.websphere.batch.BatchDataStream"
id="MyRdr1">
<service-properties>
<entry key="xjcl:impl-class" value="MyReader"/>
</service-properties>
</service>
<bean id="MyWriter" class="com..MyWriter" scope="prototype"/>
<service ref="MyWriter" interface="com.ibm.websphere.batch.BatchDataStream"
id="MyWtr1">
<service-properties>
<entry key="xjcl:impl-class" value="MyWriter"/>
</service-properties>
</service>
A developer should be able to use Spring DI, Blueprint, or CDI to
instantiate batch beans. And we have said JSR 352 shall not require DI.
So how do we make the following job XML work with or without DI:
<step id="Step1">
<tasklet>
<chunk reader="MyReader" processor="MyProcessor"
writer="MyWriter">
</tasklet>
</step>
???
Well, it should be easy enough to support any of the DI containers by using
the BeanManager interface to instantiate named beans (or services)
With Spring DI, the developer would define:
@Service
public class com...MyReader
With Blueprint:
@Bean(id="MyReader")
@Service
public class com...MyReader
With CDI:
@Named("MyReader")
public class com...MyReader
When processing a named batch bean, such as MyReader, MyProcessor, etc,
the Batch Container would need to call out to an extension that would
implement the container-specific logic for instantiating a named service.
All the DI containers are similar, but the bootstrap and bean factory
details are slightly different.
The remaining question, then, is what does the Batch Container do when no
DI extension is in use? The Batch Container still would need a way to
create a batch bean from a logical name. Here's a way:
1) add an appropriate batch annotation to each implementation class that
assigns a logical name to the class
2) use an annotation processor to write a batch.xml file that maps logical
name to class name
3) have the Batch Container use batch.xml to create batch beans as the
default factory mechanism
E.g.
@BatchProcessor("MyProcessor")
public class com...MyProcessor
@BatchReader("MyReader")
public class com...MyReader
@BatchWriter("MyWriter")
public class com...MyWriter
batch.xml:
<batch-bean id="MyProcessor" class="com..MyProcessor"/>
<batch-bean id="MyReader" class="com..MyReader"/>
<batch-bean id="MyWriter" class="com..MyWriter"/>
It's partial re-invention of the wheel. Maybe JSR 352 should co-req JSR
299 afterall? Thoughts?
Chris Vignola, STSM, IBM
JSR 352 Spec Lead
WebSphere Batch Architect
WebSphere Resiliency Architect
phone: 1+(720) 396-7501
email: cvignola@us.ibm.com
http://chris.vignola.googlepages.com
Re: Re : Tr : Instantiating Beans specified in XML
Posted by Jason Porter <li...@gmail.com>.
I know the Drools guys are interested in this sort of thing as well.
On Tue, Mar 20, 2012 at 17:08, Adrian Gonzalez <ad...@yahoo.fr>wrote:
> jbatch will also provide some annotations [1]
>
> Quote from jbatch mailing list [2] :
>
> We will move away from an annotation-only approach and use insteada hybrid approach that uses JCL to describe jobs and annotations to implement batch logic.
>
> regards,
>
> [1]
> http://java.net/projects/jbatch/lists/public/archive/2012-03/message/32
> [2]
> http://java.net/projects/jbatch/lists/public/archive/2012-03/message/29
>
>
> ----- Mail original -----
> De : Mark Struberg <st...@yahoo.de>
> À : "deltaspike-dev@incubator.apache.org" <
> deltaspike-dev@incubator.apache.org>
> Cc :
> Envoyé le : Mardi 20 mars 2012 23h52
> Objet : Re: Tr : Instantiating Beans specified in XML
>
> job xml sounds so ancient to me ;)
>
> But thanks for the info, guess this is easily doable.
>
>
> LieGrue,
> strub
>
>
>
> ----- Original Message -----
> > From: Adrian Gonzalez <ad...@yahoo.fr>
> > To: "deltaspike-dev@incubator.apache.org" <
> deltaspike-dev@incubator.apache.org>
> > Cc:
> > Sent: Tuesday, March 20, 2012 10:51 PM
> > Subject: Tr : Instantiating Beans specified in XML
> >
> > Hi,
> >
> > JBatch spec lead opened this topic about jbatch integration with a DI
> container
> > (Spring / CDI / whatever).
> >
> > Donno if someone here is on jbatch list.
> > If not, it's a good time to register and to participate I think.
> >
> > If yes, then throw this mail away - sorry ;)
> >
> > ----- Mail transféré -----
> > De : Christopher Vignola <cv...@us.ibm.com>
> > À : public@jbatch.java.net
> > Cc :
> > Envoyé le : Mardi 20 mars 2012 21h11
> > Objet : Instantiating Beans specified in XML
> >
> >
> > We've said from the start, that JSR 352 will deliver a batch runtime,
> > which we have named "batch container", that will work in both Java SE
> > and
> > EE environments. We have said it will not require a DI container, but
> > that it will be DI friendly, meaning you can use DI to instantiate the
> > batch beans. Batch beans are readers, writers, processors, listeners,
> > etc.. They are all POJO implementations. They are specified in the
> job
> > XML and then need to be instantiated at runtime. So how do we do this
> in
> > a way that does not require DI but allows you to optionally use it?
> What
> > has Spring Batch and WebSphere Batch done about this?
> >
> > Spring Batch relies on Spring DI:
> >
> > In the job XML, you identify the beans by name:
> >
> > <step id="Step1">
> > <tasklet>
> > <chunk reader="MyReader"
> > processor="MyProcessor"
> > writer="MyWriter">
> > </tasklet>
> > </step>
> >
> > In beans.xml you map names to classes:
> >
> > <bean id="MyReader" class="com...MyReader" />
> > <bean id="MyProcessor" class="com...MyProcessor" />
> > <bean id="MyWriter" class="com...MyWriter" />
> >
> > And Spring Batch probably works just fine with Spring annotations instead
> > of static XML bean definitions - e.g. @Service annotation.
> >
> > Original WebSphere Batch leaves no room for DI by requiring class names:
> >
> > <job-step name="Step1">
> > <classname>com...MyProcessor</classname>
> > <batch-data-streams>
> > <bds>
> > <logical-name>MyReader</logical-name>
> > <impl-class>com...MyReader</impl-class>
> > </bds>
> > <bds>
> > <logical-name>MyWriter</logical-name>
> > <impl-class>com...MyWriter</impl-class>
> > </bds>
> > </batch-data-streams>
> > </job-step>
> >
> > We can forget about the original WebSphere Batch approach. We do not
> want
> > class names in the job XML.
> >
> > The latest WebSphere Batch does support the OSGi Blueprint DI container
> by
> > treating classnames as "service names' and looking them up in a
> > blueprint.xml:
> >
> > <job-step name="Step1">
> > <classname>MyProcessor</classname>
> > <batch-data-streams>
> > <bds>
> > <logical-name>MyReader</logical-name>
> > <impl-class>MyReader</impl-class>
> > </bds>
> > <bds>
> > <logical-name>MyWriter</logical-name>
> > <impl-class>MyWriter</impl-class>
> > </bds>
> > </batch-data-streams>
> > </job-step>
> >
> > Then in blueprint.xml:
> >
> > <bean id="MyProcessor" class="com..MyProcessor"
> > scope="prototype"/>
> > <service ref="MyProcessor"
> > interface="com.ibm.websphere.batch.BatchJobStep"
> > id="MyProc1">
> > <service-properties>
> > <entry key="xjcl:classname"
> > value="MyProcessor"/>
> > </service-properties>
> > </service>
> >
> > <bean id="MyReader" class="com..MyReader"
> > scope="prototype"/>
> > <service ref="MyReader"
> > interface="com.ibm.websphere.batch.BatchDataStream"
> > id="MyRdr1">
> > <service-properties>
> > <entry key="xjcl:impl-class"
> > value="MyReader"/>
> > </service-properties>
> > </service>
> >
> > <bean id="MyWriter" class="com..MyWriter"
> > scope="prototype"/>
> > <service ref="MyWriter"
> > interface="com.ibm.websphere.batch.BatchDataStream"
> > id="MyWtr1">
> > <service-properties>
> > <entry key="xjcl:impl-class"
> > value="MyWriter"/>
> > </service-properties>
> > </service>
> >
> > A developer should be able to use Spring DI, Blueprint, or CDI to
> > instantiate batch beans. And we have said JSR 352 shall not require DI.
> > So how do we make the following job XML work with or without DI:
> >
> > <step id="Step1">
> > <tasklet>
> > <chunk reader="MyReader"
> > processor="MyProcessor"
> > writer="MyWriter">
> > </tasklet>
> > </step>
> >
> > ???
> >
> > Well, it should be easy enough to support any of the DI containers by
> using
> > the BeanManager interface to instantiate named beans (or services)
> >
> > With Spring DI, the developer would define:
> >
> > @Service
> > public class com...MyReader
> >
> > With Blueprint:
> >
> > @Bean(id="MyReader")
> > @Service
> > public class com...MyReader
> >
> > With CDI:
> >
> > @Named("MyReader")
> > public class com...MyReader
> >
> > When processing a named batch bean, such as MyReader, MyProcessor, etc,
> > the Batch Container would need to call out to an extension that would
> > implement the container-specific logic for instantiating a named service.
> > All the DI containers are similar, but the bootstrap and bean factory
> > details are slightly different.
> >
> > The remaining question, then, is what does the Batch Container do when no
> > DI extension is in use? The Batch Container still would need a way to
> > create a batch bean from a logical name. Here's a way:
> >
> > 1) add an appropriate batch annotation to each implementation class that
> > assigns a logical name to the class
> > 2) use an annotation processor to write a batch.xml file that maps
> logical
> > name to class name
> > 3) have the Batch Container use batch.xml to create batch beans as the
> > default factory mechanism
> >
> > E.g.
> >
> > @BatchProcessor("MyProcessor")
> > public class com...MyProcessor
> >
> > @BatchReader("MyReader")
> > public class com...MyReader
> >
> > @BatchWriter("MyWriter")
> > public class com...MyWriter
> >
> > batch.xml:
> >
> > <batch-bean id="MyProcessor"
> > class="com..MyProcessor"/>
> > <batch-bean id="MyReader" class="com..MyReader"/>
> > <batch-bean id="MyWriter" class="com..MyWriter"/>
> >
> >
> > It's partial re-invention of the wheel. Maybe JSR 352 should co-req JSR
> > 299 afterall? Thoughts?
> >
> > Chris Vignola, STSM, IBM
> > JSR 352 Spec Lead
> > WebSphere Batch Architect
> > WebSphere Resiliency Architect
> > phone: 1+(720) 396-7501
> > email: cvignola@us.ibm.com
> >
> > http://chris.vignola.googlepages.com
> >
>
>
--
Jason Porter
http://lightguard-jp.blogspot.com
http://twitter.com/lightguardjp
Software Engineer
Open Source Advocate
Author of Seam Catch - Next Generation Java Exception Handling
PGP key id: 926CCFF5
PGP key available at: keyserver.net, pgp.mit.edu
Re : Tr : Instantiating Beans specified in XML
Posted by Adrian Gonzalez <ad...@yahoo.fr>.
jbatch will also provide some annotations [1]
Quote from jbatch mailing list [2] :
We will move away from an annotation-only approach and use insteada hybrid approach that uses JCL to describe jobs and annotations to implement batch logic.
regards,
[1] http://java.net/projects/jbatch/lists/public/archive/2012-03/message/32
[2] http://java.net/projects/jbatch/lists/public/archive/2012-03/message/29
----- Mail original -----
De : Mark Struberg <st...@yahoo.de>
À : "deltaspike-dev@incubator.apache.org" <de...@incubator.apache.org>
Cc :
Envoyé le : Mardi 20 mars 2012 23h52
Objet : Re: Tr : Instantiating Beans specified in XML
job xml sounds so ancient to me ;)
But thanks for the info, guess this is easily doable.
LieGrue,
strub
----- Original Message -----
> From: Adrian Gonzalez <ad...@yahoo.fr>
> To: "deltaspike-dev@incubator.apache.org" <de...@incubator.apache.org>
> Cc:
> Sent: Tuesday, March 20, 2012 10:51 PM
> Subject: Tr : Instantiating Beans specified in XML
>
> Hi,
>
> JBatch spec lead opened this topic about jbatch integration with a DI container
> (Spring / CDI / whatever).
>
> Donno if someone here is on jbatch list.
> If not, it's a good time to register and to participate I think.
>
> If yes, then throw this mail away - sorry ;)
>
> ----- Mail transféré -----
> De : Christopher Vignola <cv...@us.ibm.com>
> À : public@jbatch.java.net
> Cc :
> Envoyé le : Mardi 20 mars 2012 21h11
> Objet : Instantiating Beans specified in XML
>
>
> We've said from the start, that JSR 352 will deliver a batch runtime,
> which we have named "batch container", that will work in both Java SE
> and
> EE environments. We have said it will not require a DI container, but
> that it will be DI friendly, meaning you can use DI to instantiate the
> batch beans. Batch beans are readers, writers, processors, listeners,
> etc.. They are all POJO implementations. They are specified in the job
> XML and then need to be instantiated at runtime. So how do we do this in
> a way that does not require DI but allows you to optionally use it? What
> has Spring Batch and WebSphere Batch done about this?
>
> Spring Batch relies on Spring DI:
>
> In the job XML, you identify the beans by name:
>
> <step id="Step1">
> <tasklet>
> <chunk reader="MyReader"
> processor="MyProcessor"
> writer="MyWriter">
> </tasklet>
> </step>
>
> In beans.xml you map names to classes:
>
> <bean id="MyReader" class="com...MyReader" />
> <bean id="MyProcessor" class="com...MyProcessor" />
> <bean id="MyWriter" class="com...MyWriter" />
>
> And Spring Batch probably works just fine with Spring annotations instead
> of static XML bean definitions - e.g. @Service annotation.
>
> Original WebSphere Batch leaves no room for DI by requiring class names:
>
> <job-step name="Step1">
> <classname>com...MyProcessor</classname>
> <batch-data-streams>
> <bds>
> <logical-name>MyReader</logical-name>
> <impl-class>com...MyReader</impl-class>
> </bds>
> <bds>
> <logical-name>MyWriter</logical-name>
> <impl-class>com...MyWriter</impl-class>
> </bds>
> </batch-data-streams>
> </job-step>
>
> We can forget about the original WebSphere Batch approach. We do not want
> class names in the job XML.
>
> The latest WebSphere Batch does support the OSGi Blueprint DI container by
> treating classnames as "service names' and looking them up in a
> blueprint.xml:
>
> <job-step name="Step1">
> <classname>MyProcessor</classname>
> <batch-data-streams>
> <bds>
> <logical-name>MyReader</logical-name>
> <impl-class>MyReader</impl-class>
> </bds>
> <bds>
> <logical-name>MyWriter</logical-name>
> <impl-class>MyWriter</impl-class>
> </bds>
> </batch-data-streams>
> </job-step>
>
> Then in blueprint.xml:
>
> <bean id="MyProcessor" class="com..MyProcessor"
> scope="prototype"/>
> <service ref="MyProcessor"
> interface="com.ibm.websphere.batch.BatchJobStep"
> id="MyProc1">
> <service-properties>
> <entry key="xjcl:classname"
> value="MyProcessor"/>
> </service-properties>
> </service>
>
> <bean id="MyReader" class="com..MyReader"
> scope="prototype"/>
> <service ref="MyReader"
> interface="com.ibm.websphere.batch.BatchDataStream"
> id="MyRdr1">
> <service-properties>
> <entry key="xjcl:impl-class"
> value="MyReader"/>
> </service-properties>
> </service>
>
> <bean id="MyWriter" class="com..MyWriter"
> scope="prototype"/>
> <service ref="MyWriter"
> interface="com.ibm.websphere.batch.BatchDataStream"
> id="MyWtr1">
> <service-properties>
> <entry key="xjcl:impl-class"
> value="MyWriter"/>
> </service-properties>
> </service>
>
> A developer should be able to use Spring DI, Blueprint, or CDI to
> instantiate batch beans. And we have said JSR 352 shall not require DI.
> So how do we make the following job XML work with or without DI:
>
> <step id="Step1">
> <tasklet>
> <chunk reader="MyReader"
> processor="MyProcessor"
> writer="MyWriter">
> </tasklet>
> </step>
>
> ???
>
> Well, it should be easy enough to support any of the DI containers by using
> the BeanManager interface to instantiate named beans (or services)
>
> With Spring DI, the developer would define:
>
> @Service
> public class com...MyReader
>
> With Blueprint:
>
> @Bean(id="MyReader")
> @Service
> public class com...MyReader
>
> With CDI:
>
> @Named("MyReader")
> public class com...MyReader
>
> When processing a named batch bean, such as MyReader, MyProcessor, etc,
> the Batch Container would need to call out to an extension that would
> implement the container-specific logic for instantiating a named service.
> All the DI containers are similar, but the bootstrap and bean factory
> details are slightly different.
>
> The remaining question, then, is what does the Batch Container do when no
> DI extension is in use? The Batch Container still would need a way to
> create a batch bean from a logical name. Here's a way:
>
> 1) add an appropriate batch annotation to each implementation class that
> assigns a logical name to the class
> 2) use an annotation processor to write a batch.xml file that maps logical
> name to class name
> 3) have the Batch Container use batch.xml to create batch beans as the
> default factory mechanism
>
> E.g.
>
> @BatchProcessor("MyProcessor")
> public class com...MyProcessor
>
> @BatchReader("MyReader")
> public class com...MyReader
>
> @BatchWriter("MyWriter")
> public class com...MyWriter
>
> batch.xml:
>
> <batch-bean id="MyProcessor"
> class="com..MyProcessor"/>
> <batch-bean id="MyReader" class="com..MyReader"/>
> <batch-bean id="MyWriter" class="com..MyWriter"/>
>
>
> It's partial re-invention of the wheel. Maybe JSR 352 should co-req JSR
> 299 afterall? Thoughts?
>
> Chris Vignola, STSM, IBM
> JSR 352 Spec Lead
> WebSphere Batch Architect
> WebSphere Resiliency Architect
> phone: 1+(720) 396-7501
> email: cvignola@us.ibm.com
>
> http://chris.vignola.googlepages.com
>
Re: Tr : Instantiating Beans specified in XML
Posted by Mark Struberg <st...@yahoo.de>.
job xml sounds so ancient to me ;)
But thanks for the info, guess this is easily doable.
LieGrue,
strub
----- Original Message -----
> From: Adrian Gonzalez <ad...@yahoo.fr>
> To: "deltaspike-dev@incubator.apache.org" <de...@incubator.apache.org>
> Cc:
> Sent: Tuesday, March 20, 2012 10:51 PM
> Subject: Tr : Instantiating Beans specified in XML
>
> Hi,
>
> JBatch spec lead opened this topic about jbatch integration with a DI container
> (Spring / CDI / whatever).
>
> Donno if someone here is on jbatch list.
> If not, it's a good time to register and to participate I think.
>
> If yes, then throw this mail away - sorry ;)
>
> ----- Mail transféré -----
> De : Christopher Vignola <cv...@us.ibm.com>
> À : public@jbatch.java.net
> Cc :
> Envoyé le : Mardi 20 mars 2012 21h11
> Objet : Instantiating Beans specified in XML
>
>
> We've said from the start, that JSR 352 will deliver a batch runtime,
> which we have named "batch container", that will work in both Java SE
> and
> EE environments. We have said it will not require a DI container, but
> that it will be DI friendly, meaning you can use DI to instantiate the
> batch beans. Batch beans are readers, writers, processors, listeners,
> etc.. They are all POJO implementations. They are specified in the job
> XML and then need to be instantiated at runtime. So how do we do this in
> a way that does not require DI but allows you to optionally use it? What
> has Spring Batch and WebSphere Batch done about this?
>
> Spring Batch relies on Spring DI:
>
> In the job XML, you identify the beans by name:
>
> <step id="Step1">
> <tasklet>
> <chunk reader="MyReader"
> processor="MyProcessor"
> writer="MyWriter">
> </tasklet>
> </step>
>
> In beans.xml you map names to classes:
>
> <bean id="MyReader" class="com...MyReader" />
> <bean id="MyProcessor" class="com...MyProcessor" />
> <bean id="MyWriter" class="com...MyWriter" />
>
> And Spring Batch probably works just fine with Spring annotations instead
> of static XML bean definitions - e.g. @Service annotation.
>
> Original WebSphere Batch leaves no room for DI by requiring class names:
>
> <job-step name="Step1">
> <classname>com...MyProcessor</classname>
> <batch-data-streams>
> <bds>
> <logical-name>MyReader</logical-name>
> <impl-class>com...MyReader</impl-class>
> </bds>
> <bds>
> <logical-name>MyWriter</logical-name>
> <impl-class>com...MyWriter</impl-class>
> </bds>
> </batch-data-streams>
> </job-step>
>
> We can forget about the original WebSphere Batch approach. We do not want
> class names in the job XML.
>
> The latest WebSphere Batch does support the OSGi Blueprint DI container by
> treating classnames as "service names' and looking them up in a
> blueprint.xml:
>
> <job-step name="Step1">
> <classname>MyProcessor</classname>
> <batch-data-streams>
> <bds>
> <logical-name>MyReader</logical-name>
> <impl-class>MyReader</impl-class>
> </bds>
> <bds>
> <logical-name>MyWriter</logical-name>
> <impl-class>MyWriter</impl-class>
> </bds>
> </batch-data-streams>
> </job-step>
>
> Then in blueprint.xml:
>
> <bean id="MyProcessor" class="com..MyProcessor"
> scope="prototype"/>
> <service ref="MyProcessor"
> interface="com.ibm.websphere.batch.BatchJobStep"
> id="MyProc1">
> <service-properties>
> <entry key="xjcl:classname"
> value="MyProcessor"/>
> </service-properties>
> </service>
>
> <bean id="MyReader" class="com..MyReader"
> scope="prototype"/>
> <service ref="MyReader"
> interface="com.ibm.websphere.batch.BatchDataStream"
> id="MyRdr1">
> <service-properties>
> <entry key="xjcl:impl-class"
> value="MyReader"/>
> </service-properties>
> </service>
>
> <bean id="MyWriter" class="com..MyWriter"
> scope="prototype"/>
> <service ref="MyWriter"
> interface="com.ibm.websphere.batch.BatchDataStream"
> id="MyWtr1">
> <service-properties>
> <entry key="xjcl:impl-class"
> value="MyWriter"/>
> </service-properties>
> </service>
>
> A developer should be able to use Spring DI, Blueprint, or CDI to
> instantiate batch beans. And we have said JSR 352 shall not require DI.
> So how do we make the following job XML work with or without DI:
>
> <step id="Step1">
> <tasklet>
> <chunk reader="MyReader"
> processor="MyProcessor"
> writer="MyWriter">
> </tasklet>
> </step>
>
> ???
>
> Well, it should be easy enough to support any of the DI containers by using
> the BeanManager interface to instantiate named beans (or services)
>
> With Spring DI, the developer would define:
>
> @Service
> public class com...MyReader
>
> With Blueprint:
>
> @Bean(id="MyReader")
> @Service
> public class com...MyReader
>
> With CDI:
>
> @Named("MyReader")
> public class com...MyReader
>
> When processing a named batch bean, such as MyReader, MyProcessor, etc,
> the Batch Container would need to call out to an extension that would
> implement the container-specific logic for instantiating a named service.
> All the DI containers are similar, but the bootstrap and bean factory
> details are slightly different.
>
> The remaining question, then, is what does the Batch Container do when no
> DI extension is in use? The Batch Container still would need a way to
> create a batch bean from a logical name. Here's a way:
>
> 1) add an appropriate batch annotation to each implementation class that
> assigns a logical name to the class
> 2) use an annotation processor to write a batch.xml file that maps logical
> name to class name
> 3) have the Batch Container use batch.xml to create batch beans as the
> default factory mechanism
>
> E.g.
>
> @BatchProcessor("MyProcessor")
> public class com...MyProcessor
>
> @BatchReader("MyReader")
> public class com...MyReader
>
> @BatchWriter("MyWriter")
> public class com...MyWriter
>
> batch.xml:
>
> <batch-bean id="MyProcessor"
> class="com..MyProcessor"/>
> <batch-bean id="MyReader" class="com..MyReader"/>
> <batch-bean id="MyWriter" class="com..MyWriter"/>
>
>
> It's partial re-invention of the wheel. Maybe JSR 352 should co-req JSR
> 299 afterall? Thoughts?
>
> Chris Vignola, STSM, IBM
> JSR 352 Spec Lead
> WebSphere Batch Architect
> WebSphere Resiliency Architect
> phone: 1+(720) 396-7501
> email: cvignola@us.ibm.com
>
> http://chris.vignola.googlepages.com
>