<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<html>
<body link="#355491" alink="#4262a1" vlink="#355491" style="background: #e2e2e2; margin: 0; padding: 20px;">
<div>
<table cellpadding="0" bgcolor="#FFFFFF" border="0" cellspacing="0" style="border: 1px solid #dadada; margin-bottom: 30px; width: 100%; -moz-border-radius: 6px; -webkit-border-radius: 6px;">
<tbody>
<tr>
<td>
<table border="0" cellpadding="0" cellspacing="0" bgcolor="#FFFFFF" style="border: solid 2px #ccc; background: #dadada; width: 100%; -moz-border-radius: 6px; -webkit-border-radius: 6px;">
<tbody>
<tr>
<td bgcolor="#000000" valign="middle" height="58px" style="border-bottom: 1px solid #ccc; padding: 20px; -moz-border-radius-topleft: 3px; -moz-border-radius-topright: 3px; -webkit-border-top-right-radius: 5px; -webkit-border-top-left-radius: 5px;">
<h1 style="color: #333333; font: bold 22px Arial, Helvetica, sans-serif; margin: 0; display: block !important;">
<!-- To have a header image/logo replace the name below with your img tag -->
<!-- Email clients will render the images when the message is read so any image -->
<!-- must be made available on a public server, so that all recipients can load the image. -->
<a href="http://community.jboss.org/index.jspa" style="text-decoration: none; color: #E1E1E1">Community</a></h1>
</td>
</tr>
<tr>
<td bgcolor="#FFFFFF" style="font: normal 12px Arial, Helvetica, sans-serif; color:#333333; padding: 20px; -moz-border-radius-bottomleft: 4px; -moz-border-radius-bottomright: 4px; -webkit-border-bottom-right-radius: 5px; -webkit-border-bottom-left-radius: 5px;"><h3 style="margin: 10px 0 5px; font-size: 17px; font-weight: normal;">
Annotation based Action classes
</h3>
<span style="margin-bottom: 10px;">
created by <a href="http://community.jboss.org/people/tfennelly">Tom Fennelly</a> in <i>JBoss ESB Development</i> - <a href="http://community.jboss.org/message/538803#538803">View the full discussion</a>
</span>
<hr style="margin: 20px 0; border: none; background-color: #dadada; height: 1px;">
<div class="jive-rendered-content"><p>With subversion lockdown at the moment, I decided to have a look at how we could improve the Action class API... make it a bit easier to use.</p><p style="min-height: 8pt; height: 8pt; padding: 0px;"> </p><p>So at the moment, to implement an Action you need to implement the ActionLifecycle interface (or one of it's derived interfaces/classes).  Configuration is done through the universally hated ConfigTree, which must be supplied via constructor.  In all... implementing an Action is quite ugly (imo).</p><p style="min-height: 8pt; height: 8pt; padding: 0px;"> </p><p>After a few hours playing, I have the following working.  You can implement an action that looks like the following:</p><p style="min-height: 8pt; height: 8pt; padding: 0px;"> </p><pre class="jive-pre"><code class="jive-code jive-java"><font color="navy"><b>public</b></font> <font color="navy"><b>class</b></font> Action1234 <font color="navy">{</font>
 
    @ConfigProperty
    <font color="navy"><b>private</b></font> File pickupFile;
   
    @ProcessMethod
    <font color="navy"><b>public</b></font> <font color="navy"><b>void</b></font> processMethod(Message m) <font color="navy">{</font>
        FileWriter writer = <font color="navy"><b>new</b></font> FileWriter(pickupFile);
 
        <font color="darkgreen">// etc....</font>
    <font color="navy">}</font>       
<font color="navy">}</font>
</code></pre><p style="min-height: 8pt; height: 8pt; padding: 0px;"> </p><p>No need to implement interfaces... no ConfigTree... configuration is reflectively injected via the @ConfigProperty annotation on the bean fields/setters.</p><p style="min-height: 8pt; height: 8pt; padding: 0px;"> </p><p>The esb config for this looks just like any other action:</p><p style="min-height: 8pt; height: 8pt; padding: 0px;"> </p><pre class="jive-pre"><code class="jive-code jive-xml"><span class="jive-xml-tag"><action name="action" class="com.acme.Action1234"></span>
    <span class="jive-xml-tag"><property name="pickupFile" value="./pickupFile.xml" /></span>
<span class="jive-xml-tag"></action></span>
</code></pre><p style="min-height: 8pt; height: 8pt; padding: 0px;"> </p><p>It also supports @ProcessMethod implementations that take non ESB Message parameters e.g.</p><p style="min-height: 8pt; height: 8pt; padding: 0px;"> </p><pre class="jive-pre"><code class="jive-code jive-java"><font color="navy"><b>public</b></font> <font color="navy"><b>class</b></font> Action1234 <font color="navy">{</font>
   
    @ProcessMethod
    <font color="navy"><b>public</b></font> OrderAcknowledgment processOrder(Order purchaseOrder) <font color="navy">{</font>
        <font color="darkgreen">// Do your thing with the order...</font>
 
        <font color="navy"><b>return</b></font> <font color="navy"><b>new</b></font> OrderAcknowledgment(....);
    <font color="navy">}</font>       
<font color="navy">}</font>
 
</code></pre><p style="min-height: 8pt; height: 8pt; padding: 0px;"> </p><p>In the above case, the Order instance needs to be set as the ESB Message payload i.e. the action configured before this action needs to create the Order (via transformation etc) and set it as the payload on the Message instance it returns.  This Order will then get extracted from the ESB Message and passed into the processOrder method.   Likewise with the OrderAcknowledgement return val... set on the ESB Message instance forwarded to the next action in the pipeline.  All this is done using the standard MessagePayloadProxy get/set mechanism.  Would be easy enough (I think) to add marshal/unmarshal support here, for marshaling e.g. an XML message payload into java objects that can then be used as args to the @ProcessMethod - opposite on the way out.</p><p style="min-height: 8pt; height: 8pt; padding: 0px;"> </p><p>Lifecycle... initialize and destroy... add public no-arg methods and annotate them with @Initialize or @Destory.</p><p style="min-height: 8pt; height: 8pt; padding: 0px;"> </p><p>The @ConfigProperty annotation for injecting the config params was lifeted from Smooks (called @ConfigParam in Smooks).  It handles extraction of the config parameter (form the ConfigTree) and injection into the bean. Also handles all the decoding e.g. in the case above, decoding the string value into a java.io.File instance.  Handles REQUIRED and OPTIONAL config params... "choices" etc.  This removes a lot of noise from the code!!</p><p style="min-height: 8pt; height: 8pt; padding: 0px;"> </p><p>All of this was done within the confines of the current Actions, ConfigTree etc APIs.  The bean action is wrapped in a normal ConfigTree/ActionLifecycle action implementation (I currently call it BeanContainerAction).  It did require a relatively small addition to the ActionProcessingPipeline to hook in this new type of action, wrapping it in the BeanContainerAction.</p><p style="min-height: 8pt; height: 8pt; padding: 0px;"> </p><p>The @ConfigParam an lifecycle annotations could also be used on the listeners etc... thereby hiding our beloved ConfigTree from most users <span> :) </span></p></div>
<div style="background-color: #f4f4f4; padding: 10px; margin-top: 20px;">
<p style="margin: 0;">Reply to this message by <a href="http://community.jboss.org/message/538803#538803">going to Community</a></p>
<p style="margin: 0;">Start a new discussion in JBoss ESB Development at <a href="http://community.jboss.org/choose-container!input.jspa?contentType=1&containerType=14&container=2032">Community</a></p>
</div></td>
</tr>
</tbody>
</table>
</td>
</tr>
</tbody>
</table>
</div>
</body>
</html>