deltaspike-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Adrian Gonzalez <adr_gonza...@yahoo.fr>
Subject Re : Tr : Instantiating Beans specified in XML
Date Tue, 20 Mar 2012 23:08:56 GMT
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 <struberg@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 <adr_gonzalez@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 <cvignola@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
>


Mime
View raw message