[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:

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 ;-).

• 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:
  PLAIN TEXT
  XML:

  1. <dependency>
  2.     <groupId>org.mule.console</groupId>
  3.     <artifactId>mmc-agent</artifactId>
  4.     <version>${mule.version}</version>
  5. </dependency>
  6. <dependency>
  7.     <groupId>com.mulesource.muleesb</groupId>
  8.     <artifactId>mule-core-ee</artifactId>
  9.     <version>${mule.version}</version>
  10. </dependency>
  11. <!-- 3rd party libs -->
  12. <dependency>
  13.     <groupId>quartz</groupId>
  14.     <artifactId>quartz</artifactId>
  15.     <version>1.5.2</version>
  16. </dependency>
  17. <dependency>
  18.     <groupId>org.springframework</groupId>
  19.     <artifactId>spring-webmvc</artifactId>
  20.     <version>${spring.version}</version>
  21. </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!

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:
   PLAIN TEXT
   XML:

   1. <dependency>
   2.     <groupId>log4j</groupId>
   3.     <artifactId>log4j</artifactId>
   4.     <version>1.2.15</version>
   5.     <exclusions>
   6.         <exclusion>
   7.             <groupId>com.sun.jmx</groupId>
   8.             <artifactId>jmxri</artifactId>
   9.         </exclusion>
   10.         <exclusion>
   11.             <groupId>com.sun.jdmk</groupId>
   12.             <artifactId>jmxtools</artifactId>
   13.         </exclusion>
   14.     </exclusions>
   15. </dependency>

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

   1. <dependency>
   2.     <groupId>log4j</groupId>
   3.     <artifactId>log4j</artifactId>
   4.     <version>1.2.14</version>
   5. </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.

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':

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

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:

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':

And the script that is executed at the remote server 'deploy_web.sh':

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.

In our project we are working with Artifactory as repository manager, so the next step is to add the archetype catalog to this repository so the rest of the team can use it too. Unfortunately this isn't a standard feature (yet) in Artifactory so you will need to perform the following steps to achieve this:

• Go to the directory in which the local archetype catalog can be found (something like /Users/name/.m2/ on the Mac)
• Perform the command
  

  curl -u username:password -f -d @archetype-catalog.xml -X PUT "http://artifactory-server:8888/artifactory/libs-releases-local/archetype-catalog.xml"

  Here username and password are the credentials you use to login to your Artifactory instance

Now the archetype is ready to be used. To make use of it you can either:

• Add the catalog to use as parameter in the command:
  mvn archetype:generate -DarchetypeCatalog=http://artifactory-server:8888/artifactory/libs-releases-local/

or

• Define it in the plugin of the parent pom:
  PLAIN TEXT
  XML:

  1. <plugin>
  2.   <groupId>org.apache.maven.plugins</groupId>
  3.   <artifactId>maven-archetype-plugin</artifactId>
  4.   <version>2.0-alpha-4</version>
  5.   <configuration>
  6.     <archetypeCatalog>http://artifactory-server:8888/artifactory/libs-releases-local/</archetypeCatalog>
  7.   </configuration>
  8. </plugin>

  and then simply use:
  mvn archetype:generate

As you can see I only have XML files in this project. I have grouped the following files together in directories in the resources folder:

• xml

Contains xml file that respects the xsd that is generated. This file is used to validate it against the generated xsd to make sure it is valid. In this example 'customer-msg.xml' it will look like:

PLAIN TEXT
XML:
1. <?xml version="1.0" encoding="UTF-8"?>
2.  
3. <ns0:customer xmlns:ns0="htpp://www.redstream.nl/customer">
4.     <ns0:firstName>Pascal</ns0:firstName>
5.     <ns0:lastName>Alma</ns0:lastName>
6.     <ns0:address>
7.         <ns0:street>sesamestreet</ns0:street>
8.         <ns0:nr>13</ns0:nr>
9.         <ns0:postalCode>
10.             <ns0:firstPart>1234</ns0:firstPart>
11.             <ns0:secondPart>AB</ns0:secondPart>
12.         </ns0:postalCode>
13.     </ns0:address>
14. </ns0:customer>
• xsd

Contains the xsd's, both the 'concept' one as well as the generated 'final' one.

• concept

As said earlier this one contains the 'concept' xsd. In this example 'customer_concept.xsd' it looks like:

PLAIN TEXT
XML:
1. <?xml version="1.0" encoding="UTF-8"?>
2. <xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema">
3.     <xs:complexType name="Address">
4.         <xs:sequence>
5.             <xs:element name="street" type="xs:string"/>
6.             <xs:element name="nr" type="xs:integer"/>
7.             <xs:element name="postalCode" type="myPostalCode"/>
8.         </xs:sequence>
9.     </xs:complexType>
10.     <xs:complexType name="Customer">
11.         <xs:sequence>
12.             <xs:element name="firstName" type="xs:string" minOccurs="0"/>
13.             <xs:element name="lastName" type="xs:string"/>
14.             <xs:element name="address" type="Address"/>
15.         </xs:sequence>
16.     </xs:complexType>
17. </xs:schema>
• final

Here is the output put. In this example 'customer.xsd' it looks like:

PLAIN TEXT
XML:
1. <?xml version="1.0" encoding="UTF-8"?>
2. <xs:schema xmlns:tns="htpp://www.redstream.nl/customer"
3.            xmlns:xs="http://www.w3.org/2001/XMLSchema"
4.            targetNamespace="htpp://www.redstream.nl/customer"
5.            elementFormDefault="qualified">
6.    <xs:element name="customer" type="tns:CustomerType"/>
7.     <xs:complexType name="AddressType">
8.         <xs:sequence>
9.             <xs:element name="street" type="xs:string"/>
10.             <xs:element name="nr" type="xs:integer"/>
11.             <xs:element name="postalCode" type="tns:myPostalCodeType"/>
12.         </xs:sequence>
13.     </xs:complexType>
14.     <xs:complexType name="CustomerType">
15.         <xs:sequence>
16.             <xs:element name="firstName" type="xs:string" minOccurs="0"/>
17.             <xs:element name="lastName" type="xs:string"/>
18.             <xs:element name="address" type="tns:AddressType"/>
19.         </xs:sequence>
20.     </xs:complexType>
21.    <xs:complexType name="myPostalCodeType">
22.       <xs:sequence>
23.          <xs:element name="firstPart">
24.             <xs:simpleType>
25.                <xs:restriction base="xs:string">
26.                   <xs:length value="4"/>
27.                </xs:restriction>
28.             </xs:simpleType>
29.          </xs:element>
30.          <xs:element name="secondPart">
31.             <xs:simpleType>
32.                <xs:restriction base="xs:string">
33.                   <xs:length value="2"/>
34.                </xs:restriction>
35.             </xs:simpleType>
36.          </xs:element>
37.       </xs:sequence>
38.    </xs:complexType>
39. </xs:schema>

• xslt

And finally the one that does all the work. In this example 'transform_customer.xslt' it looks like:

PLAIN TEXT
XML:
1. <?xml version="1.0" encoding="UTF-8"?>
2. <xsl:stylesheet version="2.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform" xmlns:xs="http://www.w3.org/2001/XMLSchema">
3.     <xsl:output method="xml" version="1.0" encoding="UTF-8" indent="yes"/>
4.     <!-- first copy the root and apply templates-->
5.     <xsl:template match="/">
6.         <xsl:copy>
7.             <!-- copy the attributes (if any) of the root element -->
8.             <xsl:copy-of select="@*"/>
9.             <xsl:apply-templates/>
10.         </xsl:copy>
11.     </xsl:template>
12.     <!-- match any other element and copy it with the attributes -->
13.     <xsl:template match="*">
14.         <xsl:copy>
15.             <xsl:copy-of select="@*"/>
16.             <xsl:apply-templates/>
17.         </xsl:copy>
18.     </xsl:template>
19.     <!-- Add the necessary namespaces to the root of the schema -->
20.     <xsl:template match="xs:schema">
21.         <!-- Recreate the xs:schema element-->
22.         <xsl:element name="xs:schema">
23.             <!-- Copy the existing attributes in the original xs:schema element to this one -->
24.             <xsl:copy-of select="@*"/>
25.             <!-- add Namespace -->
26.             <xsl:attribute name="targetNamespace">htpp://www.redstream.nl/customer</xsl:attribute>
27.             <xsl:attribute name="elementFormDefault">qualified</xsl:attribute>
28.             <xsl:namespace name="tns">htpp://www.redstream.nl/customer</xsl:namespace>
29.  
30.             <!-- add toplevel element -->
31.             <xsl:element name="xs:element">
32.                 <xsl:attribute name="name">customer</xsl:attribute>
33.                 <xsl:attribute name="type">tns:CustomerType</xsl:attribute>
34.             </xsl:element>
35.             <!-- continue with matching al child elements of the xs:schema element-->
36.             <xsl:apply-templates/>
37.             <!-- call a custom template to add an extra complexType to the schema that couldn't be generated by the modelling tool-->
38.             <xsl:call-template name="addPostalCodeType"/>
39.         </xsl:element>
40.     </xsl:template>
41.     <!-- suffix all complexType names with 'Type' -->
42.     <xsl:template match="xs:complexType">
43.         <xsl:choose>
44.             <!-- Check if the type already has the suffix 'Type' -->
45.             <xsl:when test="substring(@name, (string-length(@name)-3)) = 'Type'">
46.                 <!-- if so, just copy the existing attributes -->
47.                 <xsl:copy>
48.                     <xsl:copy-of select="@*"/>
49.                     <xsl:apply-templates/>
50.                 </xsl:copy>
51.             </xsl:when>
52.             <xsl:otherwise>
53.                 <!-- if not, copy all attribute and overwrite the attribute 'name' so the suffix 'Type' is added-->
54.                 <xsl:copy>
55.                     <xsl:copy-of select="@*"/>
56.                     <xsl:attribute name="name"><xsl:value-of select="@name"/>Type</xsl:attribute>
57.                     <xsl:apply-templates/>
58.                 </xsl:copy>
59.             </xsl:otherwise>
60.         </xsl:choose>
61.     </xsl:template>
62.     <!-- Prefix all types with 'tns:'. All default xs: types are untouched.    -->
63.     <xsl:template match="xs:element">
64.         <!-- Create a variable with the name of the type of the element in it. It appears this 'type' attribute
65.             can be of different types so take this into account -->
66.         <xsl:variable name="elementType">
67.             <xsl:choose>
68.                 <xsl:when test="@type instance of xs:string or @type instance of xs:untypedAtomic">
69.                     <xsl:choose>
70.                         <xsl:when test="contains(@type,':')">
71.                             <xsl:value-of select="substring-after(@type,':')"/>
72.                         </xsl:when>
73.                         <xsl:otherwise>
74.                             <xsl:value-of select="@type"/>
75.                         </xsl:otherwise>
76.                     </xsl:choose>
77.                 </xsl:when>
78.                 <xsl:otherwise>
79.                     <xsl:value-of select="@type"/>
80.                 </xsl:otherwise>
81.             </xsl:choose>-->
82.         </xsl:variable>
83.         <!-- Create a variable with the namespace prefix of the attribute if any. -->
84.         <xsl:variable name="elementTypePrefix">
85.             <xsl:choose>
86.                 <xsl:when test="@type instance of xs:QName">
87.                     <xsl:value-of select="prefix-from-QName(@type)"/>
88.                 </xsl:when>
89.                 <xsl:otherwise>
90.                     <xsl:value-of select="substring-before(@type,':')"/>
91.                 </xsl:otherwise>
92.  
93.             </xsl:choose>
94.         </xsl:variable>
95.         <!-- Now the variables are filled we can use it to determine if we need to add a prefix -->
96.         <xsl:choose>
97.  
98.             <!-- if type starts with xs: the prefix must not be changed -->
99.             <xsl:when test="$elementTypePrefix = 'xs'">
100.                 <xsl:copy>
101.                     <xsl:copy-of select="@*"/>
102.                     <xsl:apply-templates/>
103.                 </xsl:copy>
104.             </xsl:when>
105.             <xsl:otherwise>
106.                 <xsl:copy>
107.                     <xsl:copy-of select="@*"/>
108.                     <!-- A few steps back we renamed complextypes so they ended with 'Type'. Now we have to suffix the places
109.               where the types are reffered also with 'Type' -->
110.                     <xsl:if test="substring($elementType, (string-length($elementType)-3)) != 'Type'">
111.                         <xsl:attribute name="type">tns:<xsl:value-of select="@type"/>Type</xsl:attribute>
112.                     </xsl:if>
113.                     <xsl:if test="substring($elementType, (string-length($elementType)-3)) = 'Type'">
114.                         <xsl:attribute name="type">tns:<xsl:value-of select="@type"/></xsl:attribute>
115.                     </xsl:if>
116.                     <xsl:apply-templates/>
117.                 </xsl:copy>
118.             </xsl:otherwise>
119.         </xsl:choose>
120.     </xsl:template>
121.     <!-- The next template generates the complexType 'myPostalCodeType' when the template is called -->
122.     <xsl:template name="addPostalCodeType">
123.         <xsl:element name="xs:complexType">
124.             <xsl:attribute name="name">myPostalCodeType</xsl:attribute>
125.             <xsl:element name="xs:sequence">
126.                 <xsl:element name="xs:element">
127.                     <xsl:attribute name="name">firstPart</xsl:attribute>
128.                     <xsl:element name="xs:simpleType">
129.                         <xsl:element name="xs:restriction">
130.                             <xsl:attribute name="base">xs:string</xsl:attribute>
131.                             <xsl:element name="xs:length">
132.                                 <xsl:attribute name="value">4</xsl:attribute>
133.                             </xsl:element>
134.                         </xsl:element>
135.                     </xsl:element>
136.                 </xsl:element>
137.                 <xsl:element name="xs:element">
138.                     <xsl:attribute name="name">secondPart</xsl:attribute>
139.                     <xsl:element name="xs:simpleType">
140.                         <xsl:element name="xs:restriction">
141.                             <xsl:attribute name="base">xs:string</xsl:attribute>
142.                             <xsl:element name="xs:length">
143.                                 <xsl:attribute name="value">2</xsl:attribute>
144.                             </xsl:element>
145.                         </xsl:element>
146.                     </xsl:element>
147.                 </xsl:element>
148.             </xsl:element>
149.         </xsl:element>
150.     </xsl:template>
151. </xsl:stylesheet>

And of course the pom file. This one looks like this:

This completes the example of how you can perform xslt transformations within the Maven build cycle.

• Modify the pom

Because we are not testing against JBoss anymore we don't need all the dependencies in the pom anymore, only the dependency for OpenEJB and the ones to use Hibernate. This makes the pom of the ejb module look like:

PLAIN TEXT
XML:
1. <project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
2.   xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/maven-v4_0_0.xsd">
3.     <modelVersion>4.0.0</modelVersion>
4.     <groupId>net.pascalalma.jboss</groupId>
5.     <artifactId>ch4</artifactId>
6.     <packaging>ejb</packaging>
7.     <version>1.0-SNAPSHOT</version>
8.     <name>ch4</name>
9.     <url>http://maven.apache.org</url>
10.     <dependencies>
11.         <dependency>
12.             <groupId>junit</groupId>
13.             <artifactId>junit</artifactId>
14.             <version>4.4</version>
15.             <scope>test</scope>
16.         </dependency>
17.  
18.         <!-- To test against OpenEJB -->
19.         <dependency>
20.             <groupId>org.apache.openejb</groupId>
21.             <artifactId>openejb-core</artifactId>
22.             <version>3.1</version>
23.             <scope>provided</scope>
24.         </dependency>
25.         <dependency>
26.             <groupId>org.hibernate</groupId>
27.             <artifactId>hibernate-entitymanager</artifactId>
28.             <version>3.4.0.GA</version>
29.             <scope>test</scope>
30.         </dependency>
31.         <dependency>
32.             <groupId>org.hibernate</groupId>
33.             <artifactId>hibernate</artifactId>
34.             <version>3.2.6.ga</version>
35.             <scope>test</scope>
36.         </dependency>
37.         <dependency>
38.             <groupId>commons-collections</groupId>
39.             <artifactId>commons-collections</artifactId>
40.             <version>3.2.1</version>
41.             <scope>test</scope>
42.             <!-- necessary in combination with Hibernate -->
43.         </dependency>
44.         <dependency>
45.             <groupId>org.slf4j</groupId>
46.             <artifactId>slf4j-log4j12</artifactId>
47.             <version>1.5.2</version>
48.             <scope>test</scope>
49.             <!-- necessary in combination with Hibernate-->
50.         </dependency>
51.     </dependencies>
52.     <build>
53.         <plugins>
54.             <plugin>
55.                 <artifactId>maven-compiler-plugin</artifactId>
56.                 <version>2.0.2</version>
57.                 <configuration>
58.                     <source>1.5</source>
59.                     <target>1.5</target>
60.                     <encoding>UTF-8</encoding>
61.                 </configuration>
62.             </plugin>
63.             <plugin>
64.                 <groupId>org.apache.maven.plugins</groupId>
65.                 <artifactId>maven-ejb-plugin</artifactId>
66.                 <configuration>
67.                     <generateClient>true</generateClient>
68.                     <ejbVersion>3.0</ejbVersion>
69.                 </configuration>
70.             </plugin>
71.         </plugins>
72.         <finalName>${artifactId}</finalName>
73.     </build>
74. </project>
• Add the ejb-jar.xml
  To have OpenEJB recognize our module as EJB3 module we have to add an (empty) ejb-jar.xml to our project. Here is the project layout:
  
• Rename the test class

Because I didn't want the test class to be picked up by the Maven I didn't put the phrase 'Test' in it. Now we want the test class now to be picked up, so we have to rename the class so the name contains the phrase 'Test'. I renamed the test class to 'ClientTest'.

• Tune the test class

Besides renaming the test class we also have to make some minor changes in it. We have to modify the intial context that is returned, to have it use the OpenEJB context. And OpenEJB uses another JNDI name construction by default so I changed the used name too in the class. Here is the new version:

PLAIN TEXT
JAVA:
1. package com.titan.clients;
2.  
3. import com.titan.travelagent.TravelAgentRemote;
4. import com.titan.domain.Cabin;
5.  
6. import java.util.Properties;
7. import javax.naming.Context;
8.  
9. import javax.naming.InitialContext;
10. import org.junit.Test;
11.  
12. public class ClientTest {
13.  
14.     private static Context jndiContext = null;
15.  
16.     @Test
17.     public void main() {
18.         try {
19.             jndiContext = getInitialContext();
20.  
21.             //  String jndiName = "TravelAgentBean/remote";
22.             String jndiName = "TravelAgentBeanRemote";
23.             Object ref = jndiContext.lookup(jndiName);
24.  
25.             TravelAgentRemote dao = (TravelAgentRemote) ref;
26.  
27.             Cabin cabin_1 = new Cabin();
28.             cabin_1.setId(1);
29.             cabin_1.setName("Master Suite");
30.             cabin_1.setDeckLevel(1);
31.             cabin_1.setShipId(1);
32.             cabin_1.setBedCount(3);
33.  
34.             dao.createCabin(cabin_1);
35.  
36.             Cabin cabin_2 = dao.findCabin(1);
37.             System.out.println(cabin_2.getName());
38.             System.out.println(cabin_2.getDeckLevel());
39.             System.out.println(cabin_2.getShipId());
40.             System.out.println(cabin_2.getBedCount());
41.  
42.         } catch (javax.naming.NamingException ne) {
43.             ne.printStackTrace();
44.         }
45.     }
46.  
47.     public static Context getInitialContext()
48.             throws javax.naming.NamingException {
49.         InitialContext context = null;
50.         Properties props = new Properties();
51.         props.setProperty(Context.INITIAL_CONTEXT_FACTORY,
52.                 "org.apache.openejb.client.LocalInitialContextFactory");
53.         context = new InitialContext(props);
54.  
55.         return context;
56.     }
57. }
• Run it!

When all this is in place you can build the module and the unit test is executed in OpenEJB before it is deployed to JBoss

Now this concludes this serie of posts about testing and deploying EJB3 modules with Maven against JBoss5. I hope it may help you in some way.

With this in place you can do the following to deploy the ear file:
mvn package jboss:harddeploy
The result in JBoss will be something like:

15:47:43,340 INFO [SessionSpecContainer] Stopping jboss.j2ee:ear=jboss-ear.ear,jar=ch4-1.0-SNAPSHOT.jar,name=TravelAgentBean,service=EJB3
15:47:43,365 INFO [EJBContainer] STOPPED EJB: com.titan.travelagent.TravelAgentBean ejbName: TravelAgentBean
15:47:43,414 INFO [PersistenceUnitDeployment] Stopping persistence unit persistence.unit:unitName=jboss-ear.ear/ch4-1.0-SNAPSHOT.jar#titan
15:47:43,414 INFO [SessionFactoryImpl] closing
15:47:43,414 INFO [SchemaExport] Running hbm2ddl schema export
15:47:43,415 INFO [SchemaExport] exporting generated schema to database
15:47:43,416 INFO [SchemaExport] schema export complete
15:47:43,416 INFO [SessionFactoryObjectFactory] Unbinding factory from JNDI name: persistence.unit:unitName=jboss-ear.ear/ch4-1.0-SNAPSHOT.jar#titan
15:47:43,416 INFO [NamingHelper] JNDI InitialContext properties:{java.naming.factory.initial=org.jnp.interfaces.NamingContextFactory, java.naming.factory.url.pkgs=org.jboss.naming:org.jnp.interfaces}
15:47:43,416 INFO [SessionFactoryObjectFactory] Unbound factory from JNDI name: persistence.unit:unitName=jboss-ear.ear/ch4-1.0-SNAPSHOT.jar#titan

Now to test this EJB bean with a client running in Netbeans I had some more trouble. It appears you can not have a 'static void main(String[] args)' method to be executed if you have put your client class in a Maven project. In a Maven project the 'run file' command from Netbeans will always lead to a 'mvn test' command for the corresponding file. The way I work around this, is by making the test client, provided by the book, a jUnit test class, but without the phrase 'test' in the classname. By doing it this way, the client class is not picked up when building the project with Maven (which is good because it would be too early to test it because the class has to be deployed first on our JBoss instance). However, the test is executed when performing a 'run file' in Netbeans! Here is my code for the Client:

Please note that I had to modify the jndi name for looking up my EJB component. This is caused by the fact that JBoss adds the name of the ear file with which the EJB component is deployed.
Anyway, here is the produced output of the test class:

-------------------------------------------------------
T E S T S
-------------------------------------------------------
Running com.titan.clients.Client
Master Suite
1
1
3

Results :
------------------------------------------------------------------------
BUILD SUCCESSFUL
------------------------------------------------------------------------
Total time: 3 seconds
Finished at: Sun May 03 16:22:03 CEST 2009
Final Memory: 7M/13M
------------------------------------------------------------------------

By the way, the added ear-module can be reused for the EJB3 modules of the other chapters. Just modify the dependencies in the ear file and redeploy the constructed ear-file.

1. Minimal use of Maven

In this option I only use Maven to create the ejb-jar. The deployment and the execution of the client to test the EJB is done manually.

2. Medium use of Maven

I use Maven to create the ejb-jar file, a separate ear file and I deploy it with Maven at a running JBoss container. Running the client is still done 'manually'. Ear project can be reused to deploy ejb jars of other chapters.

3. Optimal use of Maven

I extend the setup by performing the unit test in Maven by making use of OpenEJB before it is deployed to JBoss. This way I am sure the bean is working correctly when it is deployed on JBoss.

In this post I describe the steps for option 1.

Steps to make this work:

• create a Maven project

This steps is obvious. Just create a standard Maven project with the command mvn archetype:generate like described in detail here.

• copy code to maven code dir
  Next step is to copy the (re)sources to the place where Maven2 expects it (also a good point to remove the default generated classes App.java and AppTest.java. You will get a setup like this:
  
• modify pom

Next step is to enrich the pom with all dependencies necessary to compile the code. And these are a lot of dependencies when using JBoss to compile against. The complete pom can be found
here. I have added this property to my settings.xml as it is used in the pom:

PLAIN TEXT
XML:
1. <jboss.home>/usr/local/jboss</jboss.home>
• modify the 'persistence.xml'

By using the new JBoss version it appears that the original persisitence.xml isn't working anymore. I had to add the following to it:

PLAIN TEXT
XML:
1. xmlns="http://java.sun.com/xml/ns/persistence"
2.     xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
3.     xsi:schemaLocation="http://java.sun.com/xml/ns/persistence http://java.sun.com/xml/ns/persistence/persistence_1_0.xsd"
4.     version="1.0"

If you don't add this I got the error:

DEPLOYMENTS IN ERROR:
Deployment "vfszip:/usr/local/jboss-5.0.1.GA/server/default/deploy/ch4.jar/" is in error due to the following reason(s): org.jboss.xb.binding.JBossXBRuntimeException: Failed to resolve schema nsURI= location=persistence

That's it. You can now build an ejb-jar file and copy it to the JBoss instance by hand. And you can run a client program to call your bean.
In the next post I will show you how you can use Maven to perform the deployment for you and how you can use a 'standalone' client to test your ejb deployment in Netbeans.

]]> http://blog.redstream.nl/2009/05/03/ejb3-with-jboss5-and-maven2/feed/ 11