Last week I optimized the deployment process of a number of Mavenized projects. I noticed that the way I automated the project was not yet (fully) known by the developers. This is why I decided to write this blogpost.

It appeared to be a true eyeopener for the developers.

This example assumes that you have a local instance of Apache Tomcat 7.x running.

First, create a new project using Maven:

mvn archetype:create -DgroupId=nl.redstream.demo
                     -DartifactId=simplewebapp
                     -DarchetypeArtifactId=maven-archetype-webapp

Add the Cargo plugin to the pom.xml (inside the <build> tag)

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27

<plugins>
    <plugin>
        <groupId>org.codehaus.cargo</groupId>
        <artifactId>cargo-maven2-plugin</artifactId>
        <version>1.1.2</version>
        <executions>
            <execution>
                <phase>deploy</phase>
                <goals>
                    <goal>deployer-redeploy</goal>
                </goals>
            </execution>
        </executions>
        <configuration>
            <container>
                <containerId>${mule.deploy.containerId}</containerId>
                <type>remote</type>
            </container>
            <configuration>
                <type>runtime</type>
                <properties>
                    <cargo.server.settings>${mule.deploy.serverId}</cargo.server.settings>
                </properties>
            </configuration>
        </configuration>
    </plugin>
</plugins>

The Cargo plugin is attached to the deploy lifecycle phase of Maven. Which means that the deployer-redeploy goal will be executed whenever you type: mvn deploy. The plugin uses the defined configuration at runtime. I used the depoyer-redeploy goal, because this goal will deploy your app if it is not yet deployed, and undeploy first when it is already deployed. More info on the Cargo plugin here.

The properties will be resolved from your settings.xml in which we have defined several profiles: one for each target environment (i.e. develop, test, qa).

Here’s an example for a development environment (you can add the profiles for the other target environment yourself):

Add the following (inside the <profiles> tag) to your ~/.m2/settings.xml:

1
2
3
4
5
6
7
8
9
10
11
12
13
14

<profile>
    <id>develop</id>
    <properties>
        <mule.deploy.containerId>tomcat7x</mule.deploy.containerId>                
        <mule.deploy.serverId>develop</mule.deploy.serverId>
    </properties>
    <activation>
        <activeByDefault>false</activeByDefault>
            <property>
            <name>env</name>
            <value>dev</value>
            </property>
    </activation>
</profile>

Also, add a definition with id=develop (inside the <servers> tag):

1
2
3
4
5
6
7
8

<server>
    <id>develop</id>
    <configuration>
        <cargo.remote.uri>http://localhost:8080/manager/text</cargo.remote.uri>
        <cargo.remote.username>deploy</cargo.remote.username>
        <cargo.remote.password>deploy</cargo.remote.password>
    </configuration>
</server>

The trick here is to add the Cargo configuration to the server definition. The defined properties are used by Maven to automagically deploy your webapp. In this demo I used localhost, but it could also be a remote host.

Note that I used a username and password for the deployment process. Add these in your $CATALINA_HOME/conf/tomcat-users.xml:

1

<user username="deploy" password="deploy" roles="manager-script"/>

Note: user _must_ have the manager-script role!

Now, all that’s left is deploying your application by executing mvn clean deploy -Denv=dev. The property env=dev will activate the correct profile in your settings.xml and resolve the earlier mentioned properties. BUT, the deploy phase requires a distributionManagement tag in your pom.xml. Mine looks like this (PS: I use JFrog Artifactory):

1
2
3
4
5
6
7
8
9
10

<distributionManagement>
    <repository>
        <id>artifactory</id>
        <url>http://dev.foobar.local:8080/artifactory/libs-release-local/</url>
    </repository>
    <snapshotRepository>
        <id>artifactory</id>
        <url>http://dev.foobar.local:8080/artifactory/libs-snapshot-local</url>
    </snapshotRepository>
</distributionManagement>

After you’ve added this to your pom, you’re ready to deploy your application.

Result:

...
[INFO]
[INFO] --- cargo-maven2-plugin:1.1.2:deployer-redeploy (default) @ simplewebapp ---
[INFO] [mcat7xRemoteDeployer] [/Users/pprins/projects/sandbox/simplewebapp/target/simplewebapp.war] is not deployed. Doing a fresh deployment.
[INFO] [mcat7xRemoteDeployer] Deploying [/Users/pprins/projects/sandbox/simplewebapp/target/simplewebapp.war]
[INFO] ------------------------------------------------------------------------
[INFO] BUILD SUCCESS
[INFO] ------------------------------------------------------------------------
[INFO] Total time: 5.569s
[INFO] Finished at: Fri Oct 07 13:20:24 CEST 2011
[INFO] Final Memory: 7M/554M
[INFO] ------------------------------------------------------------------------

Goto: http://localhost:8080/simplewebapp et voila: your web app!

A redeploy would look something like this:

...
[INFO] --- cargo-maven2-plugin:1.1.2:deployer-redeploy (default) @ simplewebapp ---
[INFO] [mcat7xRemoteDeployer] Redeploying [/Users/pprins/projects/sandbox/simplewebapp/target/simplewebapp.war]
[INFO] [mcat7xRemoteDeployer] Undeploying [/Users/pprins/projects/sandbox/simplewebapp/target/simplewebapp.war]
[INFO] [mcat7xRemoteDeployer] Deploying [/Users/pprins/projects/sandbox/simplewebapp/target/simplewebapp.war]

Earlier, we blogged about generating JAXB classes based on XSD files. However, sometimes we need multiple configurations with multiple XSD files. Previous blog posts did not cover this topic, so I thought I’d cover it in a seperate post.

The solution is to add multiple executions for the maven-jaxb2-plugin plugin. Each execution is bound to the generate-resources phase of the Maven build process. Now, each time the project is build, the executions kick in and the JAXB classes are generated.

Behold the following configuration:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52

<plugin>
	<groupId>org.jvnet.jaxb2.maven2</groupId>
	<artifactId>maven-jaxb2-plugin</artifactId>
	<version>0.7.0</version>
	<executions>
		<execution>
			<id>One</id>
			<phase>generate-resources</phase>
			<goals>
				<goal>generate</goal>
			</goals>
			<configuration>
				<schemaDirectory>${xsd.path}</schemaDirectory>
				<schemaIncludes>
					<include>schema-1.xsd</include>
					<include>schema-2.xsd</include>
				</schemaIncludes>
				<readOnly>true</readOnly>
				<removeOldOutput>true</removeOldOutput>
				<verbose>true</verbose>
				<extension>true</extension>
				<bindingDirectory>${jaxb.path}/</bindingDirectory>
				<bindingIncludes>
					<bindingInclude>jaxb-bindings-one.xml</bindingInclude>
				</bindingIncludes>
			</configuration>
		</execution>
		<execution>
			<id>Two</id>
			<phase>generate-resources</phase>
			<goals>
				<goal>generate</goal>
			</goals>
			<configuration>
				<schemaDirectory>${xsd.path}</schemaDirectory>
				<schemaExcludes>
					<exclude>schema-1.xsd</exclude>
					<exclude>schema-2.xsd</exclude>
				</schemaExcludes>
				<readOnly>true</readOnly>
				<removeOldOutput>false</removeOldOutput>
				<forceRegenerate>true</forceRegenerate>
				<verbose>true</verbose>
				<extension>true</extension>
				<bindingDirectory>${jaxb.path}/</bindingDirectory>
				<bindingIncludes>
					<bindingInclude>jaxb-bindings-two.xml</bindingInclude>
				</bindingIncludes>
			</configuration>
		</execution>
	</executions>
</plugin>

Execution “One” will generate the JAXB classed for schema-1.xsd and schema-2.xsd (all other schema’s in path ${xsd.path} will not be processed) and uses jaxb-bindings-one.xml as bindingfile. Execution “Two” uses all other XSD’s in directory ${xsd.path} and uses jaxb-bindings-two.xml.

The trick is to use removeOldOutput properly. By default, this has the value true and will cause the generateDirectory to be deleted before the XJC binding compiler recompiles the source files. So, by default, the second execution will delete the result of the first execution before recompiling. Setting this to value false in the second execution solves our problem. Now, both configurations are executed successfully, each with its own binding file.

Today I created a Maven module which holds our integration tests. The disadvantage when holding these tests in your ‘normal’ Maven modules is that the tests are fired every time the module is built (by you or your continuous integration server like Hudson). Since these tests take rather long to execute, developers tend to use the ‘skipTests=true‘ option when they build the code, which is taking away a great part of one the main reasons why you should use Maven. See also this article for more info about this subject.
So when creating this test module I ran into the situation where I wanted to test the code I had put in a Maven WAR module. The first thing I tried was adding the WAR module as a dependency to the integration test project and make use classes that are defined in the WAR module. The configuration looks like this:

1
2
3
4
5
6
7

<dependency>
  <groupId>nl.redstream.adapters</groupId>
  <artifactId>my-adapter</artifactId>
  <version>1.0-SNAPSHOT</version>
  <type>war</type>
  <scope>test</scope>
</dependency>

However, this doesn’t work and this was where I started my search for a solution. One option to get it to work was to move the Java sources from the WAR module to a separate JAR module and include that in the WAR module. But that is a last resort because it ment quite some rework since I have to use multiple WAR modules as a dependency in this integration test module. The first option I tried out was to make use of the WarPath plugin. Although it might be useful in some cases it didn’t work for me.
The second option I tried was to make use of the war-overlay as described here. I added the following to my project pom:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23

<build>
  <plugins>
    <plugin>
      <groupId>org.apache.maven.plugins</groupId>
      <artifactId>maven-war-plugin</artifactId>
      <configuration>
        <webResources>
          <resource>
            <directory>${basedir}/src/main/java</directory>
            <filtering>true</filtering>
          </resource>
        </webResources>
        <overlays>
          <overlay/>
          <overlay>
            <groupId>nl.redstream.adapters</groupId>
            <artifactId>my-adapter</artifactId>
          </overlay>
        </overlays>
      </configuration>
    </plugin>
  </plugins>
</build>

Although the result was a little better (I could see the classes in the WEB-INF of my WAR module were added to the integration test module) I still wasn’t able to refer to the classes in my integration tests…
Then I ended up at this page (I then realized I have been using this solution before but forgotten about it. So I hope by blogging it now I will remember it from now on). As described on the page I added to the pom of the WAR project the following:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15

<build>
...
  <plugins>
  ...
     <plugin>
      <artifactId>maven-war-plugin</artifactId>
      <version>2.1-beta-1</version>
      <configuration>
        <attachClasses>true</attachClasses>
      </configuration>
    </plugin>
  ...
  </plugins>
...
</build>

And now I can refer to the classes of my WAR module in the integration test module by adding the following dependency:

1
2
3
4
5
6
7

 <dependency>
  <groupId>nl.redstream.adapters</groupId>
  <artifactId>my-adapter</artifactId>
  <version>1.0-SNAPSHOT</version>
  <classifier>classes</classifier>
  <scope>test</scope>
</dependency>

After attending to Jason van Zyl’s session about Maven3 we decided to start using Maven 3 instead of the 2.2 we were using. Since it is fully backward compatible we made it run without making a change to our pom’s. However, what this version does add is generate warnings for all kinds of ‘misconfigurations’ in the poms. This does not lead to problems in this version but it might do so in future version, so it is better to solve this issues.
One warning we got was:

[WARNING]
[WARNING] Some problems were encountered while building the effective model for nl.redstream.framework:rs-core:jar:2.0-SNAPSHOT
[WARNING] ‘build.plugins.plugin.version’ for org.apache.maven.plugins:maven-clean-plugin is missing. @
[WARNING]
[WARNING] It is highly recommended to fix these problems because they threaten the stability of your build.
[WARNING]
[WARNING] For this reason, future Maven versions might no longer support building such malformed projects.
[WARNING]

So it appeared we forgot to mention the verion for the clean plugin, so I added the (latest) version to the pom like shown here and went on:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19

<plugin>
  <groupId>org.apache.maven.plugins</groupId>
  <artifactId>maven-clean-plugin</artifactId>
  <version>2.4</version>
  <configuration>
    <filesets>
      <fileset>
        <directory>${basedir}</directory>
        <includes>
          <include>derby.log</include>
          <include>activemq-data</include>
          <include>.mule</include>
          <include>muleEmbeddedDB</include>
          <include>out</include>
        </includes>
      </fileset>
    </filesets>
  </configuration>
</plugin>

However, after some time we noticed that some of our unit tests started to fail while they were valid and we hadn’t touched the code. After some investigation it appeared the problem was caused by the maven-clean-plugin. The version I chose (2.4) is not able to remove complete directories (or at least not with the configuration as we shown above). For some reason, until adding the version, the plugin was using version 2.2. and that does know how to handle my configuration. So I changed the version of the clean-plugin to 2.2 and my tests work like a charm without warnings of Maven.

So although Maven3 does work without a change it does not mean you won’t run into issues. But it must be said that we would run into this issue sooner or later without Maven3. So we would suggest to start using Maven3 (or at least give it a try) as it will only improve the quality of your builds (and runs much faster ;-).

For a new interface that we have to implement we have to transfrom a file with ‘character separated values’ to a XML message. One way to obtain this transformation is by using Smooks. Smooks is an extensible framework for building applications for processing XML and non XML
data (CSV, EDI, Java etc) using Java. Although Smooks can run standalone, we want to combine it with our integration platform that is based on Mule CE.
After a short search we found a mavenized Smooks module here. I made some little changes to the module so the dependencies are referring to Mule2.2.2-SNAPSHOT and Smooks1.3.1. After this I deployed the module to our company repository so it is ready for use. An example how to use the module will be posted next, so stay tuned.

As I said before we were asked to check out the new Management Console of Mule. In this post I will show the steps I took to get the console up and running and the first results of the evaluation.

• The first thing I had to fix was the fact that the Management Console only works with the Enterprise Edition. Luckily there is a 30 days trial available of the Enterprise Edition here, so I started by downloading that one.
• Next issue was that I wanted to deploy my Mule application as a WAR on a Tomcat instance. To build this WAR I use Maven (of course) so I had to made the Enterprise Edition jars available as dependencies in my repository. Luckily this issue is foreseen by MuleSoft as the Enterprise Edition comes with a script called ‘populate_m2_repo’ that adds all jars to the local repository. After running this script I was able to build my WAR file packed with the Mule EE jars.
• Next I had to add the Mule Agent to my war. To make this possible I added the agent.jar also to my local Maven repository by running the command:
  

  mvn install:install-file -DgroupId=org.mule.console -DartifactId=mmc-agent -Dversion=2.2.5 -Dpackaging=jar -Dfile=mmc-agent-2.2.5-ea.jar

• With the agent in my repository I just had to add the following dependencies to the pom of my WAR:

  1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21

  <dependency> <groupId>org.mule.console</groupId> <artifactId>mmc-agent</artifactId> <version>${mule.version}</version> </dependency> <dependency> <groupId>com.mulesource.muleesb</groupId> <artifactId>mule-core-ee</artifactId> <version>${mule.version}</version> </dependency> <!-- 3rd party libs --> <dependency> <groupId>quartz</groupId> <artifactId>quartz</artifactId> <version>1.5.2</version> </dependency> <dependency> <groupId>org.springframework</groupId> <artifactId>spring-webmvc</artifactId> <version>${spring.version}</version> </dependency>

  By adding these dependencies my WAR will also contain the Mule Agent that is necessary for the console to monitor my Mule application.

• The next step was deploying the Management Console to the Tomcat server. This is as simple as uploading the WAR to the ‘webapps’ directory. And after Tomcat has unpacked it and started it you can access it with the following address in your browser ‘http://localhost:8080/mmc-server-2.2.5-ea/’ (of course only if you didn’t change any defaults) and you get the login screen:

After login in with ‘admin/admin’ you can add your Mule application as a server:

This gives you a lot of information about the machine/processes running that application:

and

Although all this (technical) information is nice to have I think one of the main benefits is found on the ‘Services’ tab where you can audit, pause, start, etc. your individual service:

For each service you can enable the ‘audit’ option so each incoming and outgoing message is logged:

Although it is an Early Access release, I haven’t found any issue with it, but maybe that’s because I only have done some basic routines :-) We will certainly look further into this and I expect the next build of the EA (with more functionality like ‘alerts’) to become available next week. I’ll keep you informed!

I knew I solved this problem earlier: I just didn’t know how I solved it. That’s just why wiki’s and blogs are invented.

The problem? One of the developers we’re currently coaching was getting started with the Mule ESB using the book Mule in Action .

When trying to run the Maven-based samples that came with the book, Maven wasn’t able to find the com.sun.jmx:jmxri:1.2.1 and com.sun.jdmk:jmxtools:jar:1.2.1 dependency. Looking at our internal repository, only the related pom.xml appeared to be there (and not the jar).

Investigating the dependencies of the samples, there was no direct dependency. So, it had to be an indirect dependency. Then it struck me: log4j ! The latest version (1.2.15) depends on these com.sun.jmx packages and you won’t be needing them for average logging scenario’s.

The solution is kinda pragmatic, but hey … it works! Look at your pom.xml, find the log4j dependency. Now, you have two options:

1. If you depend on the latest version you have to exclude the following dependencies:

   1 2 3 4 5 6 7 8 9 10 11 12 13 14 15

   <dependency> <groupId>log4j</groupId> <artifactId>log4j</artifactId> <version>1.2.15</version> <exclusions> <exclusion> <groupId>com.sun.jmx</groupId> <artifactId>jmxri</artifactId> </exclusion> <exclusion> <groupId>com.sun.jdmk</groupId> <artifactId>jmxtools</artifactId> </exclusion> </exclusions> </dependency>

2. If no version is mentioned, add the version number:

   1 2 3 4 5

   <dependency> <groupId>log4j</groupId> <artifactId>log4j</artifactId> <version>1.2.14</version> </dependency>

Note: If you do need the com.sun.jmx dependencies. Download the libraries from the Sun Oracle website and upload them to your Maven repository.
Disclaimer: you already noticed, but this solution only works if you have a direct dependency to log4j. Generic advice would be to find out if any indirect dependency exists and exlude it in your pom.xml.

I needed Mule to determine the outbound endpoint based on the content of properties in my custom XML message. Although this might look as common functionality I couldn’t find a complete example for this on the net. This one was close, but didn’t match completely with my situation:
I receive an XML message that is conform my own custom format. Based on the content of several fields in this XML message I determine what the next endpoint must be to process the message. Then my message is forwarded to that endpoint.
The ‘mule-config’ for this looks like:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69

<?xml version="1.0" encoding="UTF-8"?>
<mule xmlns="http://www.mulesource.org/schema/mule/core/2.2"
      xmlns:jms="http://www.mulesource.org/schema/mule/jms/2.2"
      xmlns:spring="http://www.springframework.org/schema/beans"
      xmlns:stdio="http://www.mulesource.org/schema/mule/stdio/2.2"
      xmlns:test="http://www.mulesource.org/schema/mule/test/2.2"
      xmlns:vm="http://www.mulesource.org/schema/mule/vm/2.2"
      xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
      xsi:schemaLocation="
      http://www.mulesource.org/schema/mule/core/2.2 http://www.mulesource.org/schema/mule/core/2.2/mule.xsd
      http://www.mulesource.org/schema/mule/test/2.2 http://www.mulesource.org/schema/mule/test/2.2/mule-test.xsd
      http://www.mulesource.org/schema/mule/jms/2.2 http://www.mulesource.org/schema/mule/jms/2.2/mule-jms.xsd
      http://www.mulesource.org/schema/mule/stdio/2.2 http://www.mulesource.org/schema/mule/stdio/2.2/mule-stdio.xsd
      http://www.mulesource.org/schema/mule/vm/2.2 http://www.mulesource.org/schema/mule/vm/2.2/mule-vm.xsd
      http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans-2.5.xsd">
 
    <spring:bean id="routingComponent" class="nl.redstream.components.RoutingComponent" />
 
    <custom-transformer name="JaxbXmlToCdmObject" class="nl.redstream.transformers.XmlToObjectJaxbTransformer">
        <spring:property name="jaxbContextPackage" value="nl.redstream.message.v01_0"/>
    </custom-transformer>
    <custom-transformer name="JaxbObjectToCdmXml" class="nl.redstream.transformers.ObjectToXmlJaxbTransformer">
        <spring:property name="jaxbContextPackage" value="nl.redstream.message.v01_0"/>
    </custom-transformer>
 
    <jms:activemq-connector name="JMSConnector" specification="1.1" dynamicNotification="true"
                brokerURL="failover:(vm://localhost?broker.persistent=true&amp;broker.useJmx=false)"
                acknowledgementMode="AUTO_ACKNOWLEDGE"
                maxRedelivery="3"
                disableTemporaryReplyToDestinations="true"
                persistentDelivery="true"
                username="user"
                password="password" />
 
    <vm:endpoint name="test_vm" path="test-path" synchronous="true" />
    <jms:endpoint name="test_queue" queue="test-queue" connector-ref="JMSConnector" synchronous="false" />
 
    <model name="mule-event-processing" inherit="false">
        <service name="start-event-processor">
            <inbound>
                <vm:inbound-endpoint address="vm://event-processor" synchronous="false" transformer-refs="JaxbXmlToCdmObject" />
            </inbound>
 
            <component>
                <spring-object bean="routingComponent" />
            </component>
 
            <outbound>
                <custom-outbound-router class="nl.redstream.router.DynamicRouter" transformer-refs="JaxbObjectToCdmXml">
                    <spring:property name="evaluator" value="custom" />
                    <spring:property name="customEvaluator" value="cdm-msg-property" />
                    <spring:property name="expression" value="ADDRESS_LIST" />
                </custom-outbound-router>
            </outbound>
        </service>
 
        <service name="TEST">
            <inbound>
                <vm:inbound-endpoint ref="test_vm" />
            </inbound>
            <echo-component/>
            <outbound>
                <pass-through-router>
                    <jms:outbound-endpoint ref="test_queue" />
                </pass-through-router>
            </outbound>
        </service>
    </model>
</mule>

This is what happens with this configuration: the message is received on the inbound endpoint of the ‘start-event-processor’ service. The endpoint forwards the mesage to the component ‘RoutingComponent’. In this component the next inbound endpoint is determined and added as a property to the XML message. The code for the component looks like:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47

package nl.redstream.components;
 
import java.util.ArrayList;
import java.util.List;
import nl.redstream.message.v01_0.Message;
import nl.redstream.message.v01_0.PropertySetType;
import nl.redstream.message.v01_0.PropertyType;
import org.apache.log4j.Logger;
import org.mule.api.transformer.TransformerException;
 
/**
 * Routes a Message to the correct Business Process by using message metadata
 *
 * @author pascal
 */
public class RoutingComponent
{
    protected static Logger logger = Logger.getLogger(RoutingComponent.class);
 
    public Message routeMessage(Message cdmMessage) throws TransformerException {
        logger.debug("routeMessage(Message cdmMessage)");
 
        // Determin next inbound endpoint
        String nextEndpoint = getBusinessProcess(cdmMessage.getMessageHeader().
                getPropertySet());
 
        // Set next endpoint
        setAddressList(nextEndpoint, cdmMessage);
 
        // Return message
        return cdmMessage;
    }
 
    private void setAddressList(String nextEndpoint, Message msg) {
        List<string> addressList = new ArrayList<string>();
        addressList.add(nextEndpoint);
        PropertyType prop = new PropertyType();
        prop.setKey("ADDRESS_LIST");
        prop.setValue(nextEndpoint);
        msg.getMessageHeader().getPropertySet().getProperties().add(prop);
    }
 
    private String getBusinessProcess(PropertySetType propertySet) {
        // Access some logic to determine next matching BusinessProcess
        return "test_vm";
    }
}

In the component the method ‘routeMessage’ is called. In this method I determine what the next step is that has to be performed (in this example “test_vm” is hardcoded as next endpoint but this can easily be made more dynamically). Then the name of that endpoint is added as a property to the message header.
Then the message is passed to my custom-outbound-router. It is a subclass of the ‘expression-recipient-list-router’ and I made the method ‘isMatch’ always returning true so no filter has to be used. The code for the router is very simple:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17

package nl.redstream.router;
 
import org.mule.api.MuleMessage;
import org.mule.api.routing.RoutingException;
import org.mule.routing.outbound.ExpressionRecipientList;
 
/**
 *
 * @author pascal
 */
public class DynamicRouter extends ExpressionRecipientList {
 
    @Override
    public boolean isMatch(MuleMessage message) throws RoutingException {
        return true;
    }
}

The actual inbound endpoint to which the message is transfered next is determined by making use of my custom evaluator (The creation and use of the custom evaluator is described here. It also explains more about the used xml schema for my message). With this configuration in place it will use the property ‘ADDRESS_LIST’ in the MessageHeader to obtain the endpoint. Since the dynamic-router in this example always return ‘test_vm’ the message will be forwarded to that endpoint and be picked up by the ‘TEST’ service. Here is a test class to test this example:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37

package nl.redstream.components;
 
import nl.redstream.utils.FileUtils;
import org.mule.api.MuleMessage;
import org.mule.module.client.MuleClient;
import org.mule.tck.FunctionalTestCase;
 
/**
 * Checks the dynamic routing
 *
 * @author pascal
 */
public class RoutingComponentTest extends FunctionalTestCase {
 
    protected final String getConfigResources() {
        return "config/test-dynamic-router-config.xml";
    }
 
    /**
     * Tests the correct handling of an exception.
     *
     * @throws Exception
     */
    public void testReceivingEvent() throws Exception {
        MuleMessage msg = null;
        MuleClient client = new MuleClient();
 
        client.dispatch("vm://event-processor",
                FileUtils.getFileAsString("xml/example-msg.xml"), null);
 
        Thread.sleep(1500);
 
        msg = client.request("test_queue", 500);
 
        assertNotNull(msg);
    }
}

This class sends an example message to the event-processor. The message will be enriched with a property ‘ADDRESS_LIST’ in the header that has the value ‘vm_test’. So I expect a message on the queue ‘test_queue’. If it is not there the test fails, otherwise the router is working correctly.

In my current project we are going to need a BPEL engine besides our Mule CE implementation. Actually, we will use Mule for our stateless communication between systems and use BPEL for the stateful processes. One of the possible frameworks to use as a BPEL engine is Apache ODE. In this post I will show you how you can start a BPEL process in Apache ODE with Mule. As you will see, it is merely a combination of posts I made earlier, but I think it is nice to have the complete thing in one post.

Step 0: Assumptionss
Assumed is:

• an Apache ODE instance (preferably deployed in Tomcat)
• Maven 2.2.0
• JDK 1.6
• Netbeans 6.8,
• Mule CE 2.2.2-SNAPSHOT

Of course, it might work with other version but these are the versions I used.

Step 1: Create a running BPEL process

The first step is to create a running BPEL example. I use the latest version of Netbeans for that and
this post. To make use of the SOA wizards in the new Netbeans you have to enable this as an extension as described here.
To create the BPEL example perform the following steps:

1. Creating a new BPEL module named ‘TextModule’
   
2. Add a WSDL to the project

Add a WSDL that describes the web service (remark: I wasn’t able to create a document-literal web service with the wizard in Netbeans so I edited the source by hand afterwards). Here is my WSDL.

3. Add a BPEL process to the module, name it ‘txtLengthProcess’
   

   This created process is empty so add functionality to it by following the guidelines as in this post. I ended up with the following process diagram:
   
   The mapping in the assignment step looks like this:
   
   I created the necessary variables to assign the values to in the ‘receive’ and ‘reply’ step.

4. Create a file ‘deploy.xml’
   My file has the following content:

   1 2 3 4 5 6 7 8 9 10 11 12

   <?xml version="1.0" encoding="UTF-8"?> <deploy xmlns="http://www.apache.org/ode/schemas/dd/2007/03" xmlns:pns="http://www.redstream.nl/TxtLengthProcess" xmlns:wns="http://www.redstream.nl/TxtLengthService">   <process name="pns:TxtLengthProcess"> <active>true</active> <provide partnerLink="TxtLengthPartnerLink"> <service name="wns:TxtLengthServiceService" port="TxtLengthServicePort"/> </provide> </process> </deploy>

5. Deploy it to the Tomcat instance that is running Apache ODE
   To deploy the process create a directory named ‘TxtLengthService’ under ‘/webapps/ode/WEB-INF/processes’. Copy the three files (deploy.xml, TxtLengthProcess.bpel and TxtLengthService.wsdl) to this directory. When your deployment was successful you’ll see the ‘TxtLengthService.wsdl’ at http://localhost:8080/ode/services/listServices:
   
6. (Optional) you can test the service with SoapUI
   With a successful request-response you will get the following result:
   

If you want more details on how to set up a Apache ODE service have look here. It goes into more detail then I am in this post.

Step 2: Generate Java client for web service to start ODE process

We use Metro for this because we had some bad experiences when using CXF for this. It is described here how to do this in combination with Maven.
I created a new Maven project with this ‘pom.xml’.
When the client is generated you can test it with a test class like this:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21

package nl.redstream.ws.test;   import nl.redstream.txtlengthservice.TxtLengthService; import org.junit.Test;   /** * * @author pascal */ public class TestService {   @Test public void testIt() { TxtLengthService service = new TxtLengthService();   String value = service.getTxtLengthServiceSOAP11PortHttp().txtLengthOperation("RedStream");   System.out.println("result = " + value); } }

Step 3: Create the Mule project

To let Mule call the BPEL process I created a new Maven project that is able to test the call with a Mule client. The project is based on this ‘pom.xml’.
The used ‘ode-test-config.xml’ looks like:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21

<?xml version="1.0" encoding="UTF-8"?> <mule xmlns="http://www.mulesource.org/schema/mule/core/2.2" xmlns:spring="http://www.springframework.org/schema/beans" xmlns:test="http://www.mulesource.org/schema/mule/test/2.2" xmlns:vm="http://www.mulesource.org/schema/mule/vm/2.2" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation=" http://www.mulesource.org/schema/mule/core/2.2 http://www.mulesource.org/schema/mule/core/2.2/mule.xsd http://www.mulesource.org/schema/mule/test/2.2 http://www.mulesource.org/schema/mule/test/2.2/mule-test.xsd http://www.mulesource.org/schema/mule/vm/2.2 http://www.mulesource.org/schema/mule/vm/2.2/mule-vm.xsd http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans-2.5.xsd">   <model name="mule-ode"> <service name="start"> <inbound> <vm:inbound-endpoint path="msg-in" synchronous="true"/> </inbound> <component class="nl.redstream.mule.BpelProcessClient" /> </service> </model> </mule>

The created component class that handles the call to the SOAP client looks like:

1 2 3 4 5 6 7 8 9 10 11 12 13 14

package nl.redstream.mule;   import nl.redstream.txtlengthservice.TxtLengthService;   /** * * @author pascal */ public class BpelProcessClient {   public String callProcess(String request) { return new TxtLengthService().getTxtLengthServiceSOAP11PortHttp().txtLengthOperation(request); } }

And the used test class looks like:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34

package nl.redstream.mule;   import org.junit.Test; import org.mule.api.MuleException; import org.mule.api.MuleMessage; import org.mule.module.client.MuleClient; import org.mule.tck.FunctionalTestCase;   public class BpelProcessClientTest extends FunctionalTestCase {   private MuleClient client = null;   protected MuleClient getClient() { try { if (client == null) { client = new MuleClient(); } } catch (MuleException e) { throw new RuntimeException(e); } return client; }   protected final String getConfigResources() { return "config/ode-test-config.xml "; }   @Test public void testBpelTest() throws MuleException { MuleMessage msg = getClient().send("vm://msg-in", "123456789012345", null); System.out.println("payload = " + msg.getPayload()); } }

When the test class is executed this results in the following output:

**********************************************************************
* Mule ESB and Integration Platform *
* Version: 2.2.2-SNAPSHOT Build: 15252 *
* MuleSource, Inc. *
* For more information go to http://mule.mulesource.org *
* *
* Server started: 12/17/09 8:34 PM *
* Server ID: 3d3eb71b-eb43-11de-bca6-7b92b51f04e0 *
* JDK: 1.6.0_17 (mixed mode) *
* OS encoding: MacRoman, Mule encoding: UTF-8 *
* OS: Mac OS X (10.6.2, x86_64) *
* Host: macbook-van-pascal-alma.local (192.168.1.204) *
* *
* Agents Running: None *
**********************************************************************
INFO 2009-12-17 20:34:50,730 [main] org.mule.module.client.MuleClient: Using existing MuleContext: org.mule.DefaultMuleContext@1d6b6c55
INFO 2009-12-17 20:34:50,756 [main] org.mule.transport.vm.VMMessageDispatcher: Connected: endpoint.outbound.vm://msg-in
payload = 15
INFO 2009-12-17 20:34:51,784 [main] org.mule.transport.vm.VMConnector: Removing listener on endpointUri: vm://msg-in
INFO 2009-12-17 20:34:51,784 [main] org.mule.transport.vm.VMMessageReceiver: Disconnected: VMMessageReceiver{this=5a56182f, receiverKey=msg-in, endpoint=vm://msg-in}
INFO 2009-12-17 20:34:51,785 [main] org.mule.component.DefaultJavaComponent: Stopping: org.mule.component.DefaultJavaComponent component for: SedaService{start}
INFO 2009-12-17 20:34:51,785 [main] org.mule.model.seda.SedaService: Mule Service start has been stopped successfully
INFO 2009-12-17 20:34:51,787 [main] org.mule.transport.vm.VMConnector: Stopping: VMConnector{this=75d709a5, started=true, initialised=true, name=’connector.VM.0′, disposed=false, numberOfConcurrentTransactedReceivers=4, createMultipleTransactedReceivers=true, connected=true, supportedProtocols=[vm], serviceOverrides=null}
INFO 2009-12-17 20:34:51,787 [main] org.mule.transport.vm.VMConnector: Disconnected: VMConnector{this=75d709a5, started=false, initialised=true, name=’connector.VM.0′, disposed=false, numberOfConcurrentTransactedReceivers=4, createMultipleTransactedReceivers=true, connected=false, supportedProtocols=[vm], serviceOverrides=null}
INFO 2009-12-17 20:34:51,787 [main] org.mule.transport.vm.VMConnector: Stopped: VMConnector{this=75d709a5, started=false, initialised=true, name=’connector.VM.0′, disposed=false, numberOfConcurrentTransactedReceivers=4, createMultipleTransactedReceivers=true, connected=false, supportedProtocols=[vm], serviceOverrides=null}
INFO 2009-12-17 20:34:51,788 [main] org.mule.util.queue.TransactionalQueueManager: Stopping ResourceManager
INFO 2009-12-17 20:34:51,788 [main] org.mule.util.queue.TransactionalQueueManager: Stopped ResourceManager
INFO 2009-12-17 20:34:51,788 [main] org.mule.transport.vm.VMConnector: Disposing: VMConnector{this=75d709a5, started=false, initialised=true, name=’connector.VM.0′, disposed=false, numberOfConcurrentTransactedReceivers=4, createMultipleTransactedReceivers=true, connected=false, supportedProtocols=[vm], serviceOverrides=null}
INFO 2009-12-17 20:34:51,788 [main] org.mule.transport.vm.VMMessageDispatcher: Disconnected: VMMessageDispatcher{this=1915470e, endpoint=vm://msg-in, disposed=false}
INFO 2009-12-17 20:34:51,788 [main] org.mule.transport.vm.VMConnector: Disposed: VMConnector{this=75d709a5, started=false, initialised=false, name=’connector.VM.0′, disposed=true, numberOfConcurrentTransactedReceivers=4, createMultipleTransactedReceivers=true, connected=false, supportedProtocols=[vm], serviceOverrides=null}
INFO 2009-12-17 20:34:51,789 [main] org.mule.config.spring.MuleApplicationContext: Closing org.mule.config.spring.MuleApplicationContext@356f144c: display name [org.mule.config.spring.MuleApplicationContext@356f144c]; startup date [Thu Dec 17 20:34:49 CET 2009]; root of context hierarchy
INFO 2009-12-17 20:34:51,789 [main] org.springframework.beans.factory.support.DefaultListableBeanFactory: Destroying singletons in org.springframework.beans.factory.support.DefaultListableBeanFactory@29abc69: defining beans [customEditorConfigurer,_muleObjectNameProcessor,_mulePropertyPlaceholderProcessor, _muleSimpleRegistryBootstrap,_muleNotificationManager,_muleConfiguration,._muleNotificationManager: notification.1,._muleNotificationManager:notification.2,._muleNotificationManager:notification.3, ._muleNotificationManager:notification.4,._muleNotificationManager:notification.5,._muleNotificationManager: notification.6,._muleNotificationManager:notification.7,._muleNotificationManager:notification.8, ._muleNotificationManager:notification.9,._muleNotificationManager:notification.10,_muleSystemModel, _muleQueueManager,_muleSecurityManager,_muleProperties,_muleEndpointFactory,_muleStreamCloserService, _defaultThreadingProfile,_defaultMessageDispatcherThreadingProfile,_defaultMessageRequesterThreadingProfile, _defaultMessageReceiverThreadingProfile,_defaultServiceThreadingProfile,_defaultRetryPolicyTemplate, mule-ode,start,.start:inbound.11,.start:inbound.11:inbound-endpoint.12,.start:component.13]; root of factory hierarchy
INFO 2009-12-17 20:34:51,995 [main] org.mule.DefaultMuleContext:
**********************************************************************
* Mule shut down normally on: 12/17/09 8:34 PM *
* Server was up for: 0 days, 0 hours, 0 mins, 1.318 sec *
**********************************************************************
Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 3.103 sec

So by finishing this post you should be able to execute a (simple) BPEL process in Apache ODE by using Mule. However, it is not certain we will use Apache ODE like this. I think we would like Intalio|server more because of the handy features/tooling they have added to Apache ODE.

]]> http://www.redstream.nl/2009/12/18/combining-mule-with-a-bpel-engine/feed/ 0 http://www.redstream.nl/2009/12/06/deploying-with-maven2-to-a-remote-jboss-instance/ http://www.redstream.nl/2009/12/06/deploying-with-maven2-to-a-remote-jboss-instance/#comments Sun, 06 Dec 2009 10:07:09 +0000 Pascal Alma http://www.pascalalma.net/?p=962 Continue reading →]]>



Some time ago I already explained how you could use Maven and the jboss-plugin to deploy your war or ear to your JBoss server. Now this works fine as long as your JBoss is a local installation running on the same machine as the one that is running Maven.
Of course there is a big chance that this is not the case in your development environment. In that case you can do the following in Maven to deploy your ear to the JBoss instance:

1. Transfer the war or ear file to the remote machine
2. Run a script on the remote machine

Actually it isn’t doing anything JBoss specific, so you could use it for other application servers too (like Tomcat, at least when they are using hot deployment).
To perform step 1 you have to add the following plugin in your ‘pom.xml’:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26

<build> <plugins> <plugin> <groupId>org.codehaus.mojo</groupId> <artifactId>wagon-maven-plugin</artifactId> <version>1.0-beta-1</version> <executions> <execution> <id>upload-artifact</id> <phase>deploy</phase> <goals> <goal>upload</goal> </goals> <configuration> <serverId>${project.deploy.serverId}</serverId> <fromDir>target</fromDir> <includes>*.war</includes> <url>${project.deploy.url}</url> <toDir>${project.deploy.toDir}</toDir> </configuration> </execution> </executions> </plugin> ... </plugin> </build>

And this plugin needs the ‘distributionManagement’ section to be filled like this:

1 2 3 4 5 6 7 8 9 10

<distributionManagement> <repository> <id>m2-internal-repo</id> <url>http://local.redstream.nl:8888/artifactory/libs-releases-local/</url> </repository> <snapshotRepository> <id>m2-internal-repo</id> <url>http://local.redstream.nl:8888/artifactory/libs-snapshots-local</url> </snapshotRepository> </distributionManagement>

The second step is a bit more complicated. I want to execute a script on the remote server using SSH. This can rather easily be done by using an Ant target, so to get this working in Maven we have to use the plugin to run an Ant target. It will ook like this:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35

<plugin> <groupId>org.apache.maven.plugins</groupId> <artifactId>maven-antrun-plugin</artifactId> <version>1.3</version> <dependencies> <dependency> <groupId>org.apache.ant</groupId> <artifactId>ant-jsch</artifactId> <version>1.7.1</version> </dependency> <dependency> <groupId>com.jcraft</groupId> <artifactId>jsch</artifactId> <version>0.1.41</version> </dependency> </dependencies> <executions> <execution> <id>deploy-artifact</id> <phase>deploy</phase> <goals> <goal>run</goal> </goals> <configuration> <tasks> <sshexec host="${project.deploy.host}" username="${projecte.deploy.username}" password="${project.deploy.password}" trust="true" command="bin/deploy_web.sh"/> </tasks> </configuration> </execution> </executions> </plugin>

Thta’s it. These two plugins together do the job. For completeness I show the used properties that I have setup in my ‘settings.xml’:

1 2 3 4 5 6 7 8 9 10 11 12 13 14

<profiles> <profile> <id>develop</id> <properties> <project.deploy.serverId>mule-server</mule.deploy.serverId> <project.deploy.url>scp://mule-server</mule.deploy.url> <project.deploy.toDir>/home/pascal</mule.deploy.toDir> <project.deploy.host>mule-server</mule.deploy.host> <project.deploy.username>pascal</mule.deploy.username> <project.deploy.password>pascal</mule.deploy.password> </properties> </profile> ... </profiles>

And the script that is executed at the remote server ‘deploy_web.sh’:
[code]
#
# Deploy Mule applications
#
#
source /etc/profile

echo "Start deploying"

for archive in ~/deploy/*.war; do
echo "Copying to tomcat: web-archive \"$archive\""
cp $archive /$TOMCAT_HOME/webapps/
done

echo "Deploying finished"

echo "Clean up ~/deploy directory"
rm -rf ~/deploy/*.war
[/code]
If all this is in place you can deploy the ear/war file by using the command:
mvn clean deploy
Like I said before there is nothing JBoss specific to this and actually I am using the script to deploy my Mule applications to our Tomcat server.

]]> http://www.redstream.nl/2009/12/06/deploying-with-maven2-to-a-remote-jboss-instance/feed/ 16