Redstream Blog » OpenEJB http://blog.redstream.nl Pragmatic Integrators Mon, 26 Jul 2010 06:09:45 +0000 en hourly 1 http://wordpress.org/?v=15 EJB3 with JBoss5 and Maven2 (part 3) http://blog.redstream.nl/2009/05/18/ejb3-with-jboss5-and-maven2-part-3/ http://blog.redstream.nl/2009/05/18/ejb3-with-jboss5-and-maven2-part-3/#comments Mon, 18 May 2009 18:38:05 +0000 Pascal Alma http://www.pascalalma.net/?p=814 As I promised here this is the last part about using Maven2 to build, test and deploy an EJB3 application to JBoss5. In part 2 I showed how you can build and deploy your EJB3 application in JBoss. In this step I want to show you how you can (unit)test your EJB3 module before you deploy it to JBoss. In part 2 we had to deploy the bean first, before we could test it, but that is not the most optimal way. It would be nicer if the code is tested before it is deployed to the JBoss server. To do this, I make use of OpenEJB. This is a lightweight container that is very easy to use with Maven. Another advantage of this approach is that the EJB component is tested/used in two different EJB containers and reduces the possiblity that container-specific code is used in the application.
Although I have described a similar situation before in this post I will show the steps to get to this setup but now based on the situation of the last post. These are the steps to perform:

  • 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.

]]> http://blog.redstream.nl/2009/05/18/ejb3-with-jboss5-and-maven2-part-3/feed/ 0 JAXB2 Transformers in Mule2 http://blog.redstream.nl/2009/04/21/jaxb2-transformers-in-mule2/ http://blog.redstream.nl/2009/04/21/jaxb2-transformers-in-mule2/#comments Tue, 21 Apr 2009 18:33:45 +0000 Pascal Alma http://www.pascalalma.net/?p=729 Currently I am looking into the possiblities Mule has to offer for our project. One of the things that must be done is to transform a message on our (Tibco) queue to a JAXB object so we can use the object as parameter in our call to an EJB3 bean. How to call a EJB3 bean from Mule I have explained here. In this post I want to show how we setup our JAXB transformer. This transformer isn't standard available in Mule but, as you will see, it is pretty easy to create your own transformer.
I created my transformer based on this article. In my situation I have my JAXB classes generated in the package 'net.pascalalma.types' (I take this post as an example for my JAXB module).
The first step is to create a Maven project. You can choose a specific Mule archetype but in this case I chose the default archetype for a Maven project.
I added the following classes to the project that together make up the Jaxb Transformer:
The base class is formed by the AbstractJaxbTransformer class:

PLAIN TEXT
JAVA:
  1. package net.pascalalma.mule.transformer;
  2.  
  3. import javax.xml.bind.JAXBContext;
  4. import org.mule.api.lifecycle.InitialisationException;
  5. import org.mule.transformer.AbstractTransformer;
  6.  
  7. /**
  8. * Abstract transformer when using JAXB.
  9. */
  10. public abstract class AbstractJaxbTransformer extends AbstractTransformer {
  11.  
  12.     private JAXBContext jaxbContext;
  13.     private String jaxbContextPackage;
  14.  
  15.     @Override
  16.     public void initialise() throws InitialisationException {
  17.         try {
  18.             jaxbContext = JAXBContext.newInstance(getJaxbContextPackage());
  19.         } catch (Exception e) {
  20.             throw new InitialisationException(e, this);
  21.         }
  22.     }
  23.  
  24.     public JAXBContext getJaxbContext() {
  25.         return jaxbContext;
  26.     }
  27.  
  28.     public void setJaxbContext(JAXBContext jaxbContext) {
  29.         this.jaxbContext = jaxbContext;
  30.     }
  31.  
  32.     public String getJaxbContextPackage() {
  33.         return jaxbContextPackage;
  34.     }
  35.  
  36.     public void setJaxbContextPackage(String jaxbContextPackage) {
  37.         this.jaxbContextPackage = jaxbContextPackage;
  38.     }
  39. }

As we will see in the Mule configuration we will pass the package with which the JAXB Context must be initialized in this class. Now lets look at the classes that will do the actual work. One is the JaxbObjectToXml class:

PLAIN TEXT
JAVA:
  1. package net.pascalalma.mule.transformer;
  2.  
  3. import java.io.StringReader;
  4. import javax.xml.bind.JAXBElement;
  5. import javax.xml.bind.JAXBException;
  6. import javax.xml.bind.Unmarshaller;
  7. import org.mule.api.transformer.TransformerException;
  8.  
  9. /**
  10. * Transforms JAXB XML to named JAXB Object
  11. */
  12. public class JaxbXmlToObject extends AbstractJaxbTransformer {
  13.  
  14.     public JaxbXmlToObject() {
  15.         registerSourceType(String.class);
  16.         setReturnClass(Object.class);
  17.     }
  18.  
  19.     protected Object doTransform(Object payload, String encodingType) throws TransformerException {
  20.         Object element;
  21.  
  22.         try {
  23.             Unmarshaller unmarshaller = getJaxbContext().createUnmarshaller();
  24.             element = unmarshaller.unmarshal(new StringReader((String) payload));
  25.         } catch (JAXBException e) {
  26.             throw new TransformerException(this, e);
  27.         }
  28.         return element;
  29.     }
  30. }

The other one is the JaxbObjectToXml class:

PLAIN TEXT
JAVA:
  1. package net.pascalalma.mule.transformer;
  2.  
  3. import java.io.StringWriter;
  4. import java.io.Writer;
  5. import javax.xml.bind.JAXBException;
  6. import javax.xml.bind.Marshaller;
  7. import org.mule.api.transformer.TransformerException;
  8.  
  9. public class JaxbObjectToXml extends AbstractJaxbTransformer {
  10.  
  11.     public JaxbObjectToXml() {
  12.         registerSourceType(Object.class);
  13.         setReturnClass(String.class);
  14.     }
  15.     protected Object doTransform(Object payload, String arg1) throws TransformerException {
  16.         try {
  17.             Marshaller marshaller = getJaxbContext().createMarshaller();
  18.  
  19.             Writer out = new StringWriter();
  20.             marshaller.marshal(payload, out);
  21.  
  22.             return out.toString();
  23.  
  24.         } catch (JAXBException e) {
  25.             throw new TransformerException(this, e);
  26.         }
  27.     }
  28. }

That's it! After compiling these classes we can use them in Mule to transform an incoming JMS TextMessage to a JAXB object. To test this transformer I make use of a VM queue in Mule. Here is my Mule configuration (muleproject-functional-test-config.xml) for the test class:

PLAIN TEXT
XML:
  1. <?xml version="1.0" encoding="UTF-8"?>
  2. <mule xmlns="http://www.mulesource.org/schema/mule/core/2.2"
  3.        xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
  4.        xmlns:spring="http://www.springframework.org/schema/beans"
  5.        xmlns:test="http://www.mulesource.org/schema/mule/test/2.2"
  6.        xmlns:jms="http://www.mulesource.org/schema/mule/jms/2.2"
  7.        xmlns:stdio="http://www.mulesource.org/schema/mule/stdio/2.2"
  8.        xmlns:vm="http://www.mulesource.org/schema/mule/vm/2.2"
  9.        xmlns:jee="http://www.springframework.org/schema/jee"
  10.        xsi:schemaLocation="
  11.        http://www.mulesource.org/schema/mule/core/2.2 http://www.mulesource.org/schema/mule/core/2.2/mule.xsd
  12.        http://www.mulesource.org/schema/mule/test/2.2 http://www.mulesource.org/schema/mule/test/2.2/mule-test.xsd
  13.        http://www.mulesource.org/schema/mule/jms/2.2 http://www.mulesource.org/schema/mule/jms/2.2/mule-jms.xsd
  14.        http://www.mulesource.org/schema/mule/stdio/2.2 http://www.mulesource.org/schema/mule/stdio/2.2/mule-stdio.xsd
  15.        http://www.mulesource.org/schema/mule/vm/2.2 http://www.mulesource.org/schema/mule/vm/2.2/mule-vm.xsd
  16.        http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans-2.5.xsd
  17.        http://www.springframework.org/schema/jee http://www.springframework.org/schema/jee/spring-jee-2.5.xsd">
  18.  
  19.     <spring:beans>
  20.         <jee:remote-slsb id="testEJB" jndi-name="CustomerLoggerRemote"
  21.                          business-interface="net.pascalalma.services.CustomerLoggerRemote"
  22.                         >
  23.             <jee:environment>
  24.                 java.naming.factory.initial=org.apache.openejb.client.LocalInitialContextFactory
  25.             </jee:environment>
  26.         </jee:remote-slsb>
  27.     </spring:beans>
  28.  
  29.     <jms:jmsmessage-to-object-transformer name="JmsToObject"/>
  30.  
  31.     <custom-transformer name="JaxbXmlToObject" class="net.pascalalma.mule.transformer.JaxbXmlToObject"
  32.       returnClass="net.pascalalma.schema.customer.Customer">
  33.         <spring:property name="jaxbContextPackage" value="net.pascalalma.schema.customer"/>
  34.     </custom-transformer>
  35.  
  36.     <model name="main">
  37.         <service name="testService">
  38.             <inbound>
  39.                 <vm:inbound-endpoint path="myqueue" synchronous="true">
  40.                     <!--<transformer ref="JmsToObject"/>-->
  41.                     <transformer ref="JaxbXmlToObject"/>
  42.                 </vm:inbound-endpoint>
  43.             </inbound>
  44.             <component>
  45.                 <spring-object bean="testEJB" />
  46.             </component>
  47.             <default-service-exception-strategy>
  48.                 <vm:outbound-endpoint path="error" />
  49.             </default-service-exception-strategy>
  50.         </service>
  51.     </model>
  52. </mule>

As you can see I have defined a JmsToObject translator but I am not needing this in this test case since I use a vm queue as input. But when you are using a real JMS queue as input you must uncomment the transformer so it is used before the custom transformer.
Here is the code of my test class:

PLAIN TEXT
JAVA:
  1. package net.pascalalma.mule.transformer;
  2.  
  3. import java.util.Properties;
  4. import javax.naming.Context;
  5. import javax.naming.InitialContext;
  6. import javax.naming.NamingException;
  7.  
  8. import org.mule.api.MuleMessage;
  9. import org.mule.module.client.MuleClient;
  10. import org.mule.tck.FunctionalTestCase;
  11.  
  12. public class TransformerTestCase extends FunctionalTestCase {
  13.  
  14.     private Context context = null;
  15.  
  16.     protected String getConfigResources() {
  17.         return "muleproject-functional-test-config.xml";
  18.     }
  19.  
  20.     public TransformerTestCase() throws NamingException {
  21.         super();
  22.  
  23.         Properties props = new Properties();
  24.         props.setProperty(Context.INITIAL_CONTEXT_FACTORY,
  25.                 "org.apache.openejb.client.LocalInitialContextFactory");
  26.         context = new InitialContext(props);
  27.     }
  28.  
  29.     public void testRequestReplyJms() throws Exception {
  30.  
  31.         MuleClient client = new MuleClient();
  32.  
  33.         MuleMessage msg = client.send("vm://myqueue", getTestCustomerXml(), null);
  34.  
  35.     }
  36.  
  37.     private String getTestCustomerXml() {
  38.         return "<customer xmlns=\"http://www.pascalalma.net/schema/customer\">\n" +
  39.                 "\t<id>1</id>\n" +
  40.                 "\t<name>Palma IT</name>\n" +
  41.                 "\t<address>Papendrecht, Holland</address>\n" +
  42.                 "</customer>\n";
  43.     }
  44. }

To complete this example here is the pom file and here is an overview of the complete project in Netbeans:

]]> http://blog.redstream.nl/2009/04/21/jaxb2-transformers-in-mule2/feed/ 2 Calling EJB3 with Mule and test it with OpenEJB http://blog.redstream.nl/2009/04/01/calling-ejb3-with-mule-and-test-it-with-openejb/ http://blog.redstream.nl/2009/04/01/calling-ejb3-with-mule-and-test-it-with-openejb/#comments Wed, 01 Apr 2009 07:11:19 +0000 Pascal Alma http://www.pascalalma.net/?p=703 Like I said here we are evaluating Mule to see if we can use it in our situation. One of the things we must do with Mule is to call our business services that are implemented by EJB3 classes based on a message that was put on a JMS topic. To my surprise this isn't a standard thing in Mule (the creators of Mule want to be JDK1.4 compliant, so there is no room for standard support EJB3, as far as I understand it).
After some searching I came up with several possible solutions of which I think the next one is the best (at least in our situation):

  • Create the EJB3 bean

    • Of course, you have to build the EJB3 beans that implement your business services. I have the following interface:

    PLAIN TEXT
    JAVA:
    1. package net.pascalalma.mule.ejb;
    2.  
    3. import javax.ejb.Remote;
    4.  
    6. public interface SquareRemote
    7. {
    8.     public Integer calculate(Integer number);
    9. }

    and this implementating class:

    PLAIN TEXT
    JAVA:
    1. package net.pascalalma.mule.ejb;
    2.  
    3. import javax.ejb.Stateless;
    4.  
    5. @Stateless
    6. public class SquareBean implements SquareRemote
    7. {
    8.    public Integer calculate(Integer number)
    9.     {
    10.         return number * number;
    11.     }
    12. }

  • Create Mule Config

    • In a separate Maven module I defined my Mule config file. To create this module I make use of a specific Maven archetype for Mule projects as I described here.
    This is my Mule Config file:

    PLAIN TEXT
    XML:
    1. <?xml version="1.0" encoding="UTF-8"?>
    2. <mule xmlns="http://www.mulesource.org/schema/mule/core/2.2"
    3.     xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
    4.     xmlns:spring="http://www.springframework.org/schema/beans"
    5.     xmlns:jee="http://www.springframework.org/schema/jee"
    6.     xmlns:vm="http://www.mulesource.org/schema/mule/vm/2.2"
    7.     xsi:schemaLocation="
    8.        http://www.mulesource.org/schema/mule/core/2.2 http://www.mulesource.org/schema/mule/core/2.2/mule.xsd
    9.        http://www.mulesource.org/schema/mule/vm/2.2 http://www.mulesource.org/schema/mule/vm/2.2/mule-vm.xsd
    10.        http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans-2.5.xsd
    11.        http://www.springframework.org/schema/jee http://www.springframework.org/schema/jee/spring-jee-2.5.xsd">
    12.  
    13.     <spring:beans>
    14.         <jee:remote-slsb id="squareEJB" jndi-name="net.pascalalma.mule.ejb.SquareRemote"
    15.                          business-interface="net.pascalalma.mule.ejb.SquareRemote">
    16.             <jee:environment>
    17.                 java.naming.factory.initial=org.apache.openejb.client.LocalInitialContextFactory
    18.                 java.naming.provider.url=rmi://localhost:1099
    19.                 openejb.jndiname.format={interfaceClass}
    20.             </jee:environment>
    21.         </jee:remote-slsb>
    22.     </spring:beans>
    23.  
    24.     <model name="main">
    25.         <service name="EjbCall">
    26.             <inbound>
    27.                 <vm:inbound-endpoint path="square" synchronous="true" />
    28.             </inbound>
    29.              <component>
    30.                 <spring-object bean="squareEJB"/>
    31.             </component>
    32.         </service>
    33.     </model>
    34. </mule>

    As you see I added a spring-bean definition. With this, I create a 'Spring' wrapper around my EJB3 class and that wrapper is used lateron in the config to inject the component in Mule.
    In the configuration of the Spring bean I set up my initial context for OpenEJB in this case, because that is where this set up will be tested with. I also set the jndiname format property, so it matches the format that is used in Glassfish which is our application server in the 'real' world.

  • Create test class

    • In the test class we will run Mule as a standalone process by using the MuleClient object. And we will put a value on the inbound endpoint of our defined service, like this:

    PLAIN TEXT
    JAVA:
    1. package net.pascalalma.mule.mathservice;
    2.  
    3. import org.mule.api.MuleMessage;
    4. import org.mule.module.client.MuleClient;
    5. import org.mule.tck.FunctionalTestCase;
    6.  
    7. public class MathServiceTestCase extends FunctionalTestCase {
    8.  
    9.     protected String getConfigResources() {
    10.         return "mule-config.xml";
    11.     }
    12.  
    13.     public void testMathService() throws Exception {
    14.         MuleClient client = new MuleClient();
    15.  
    16.         MuleMessage result = client.send("vm://square", new Integer(5), null);
    17.  
    18.         assertNotNull(result.getPayloadAsString());
    19.         assertEquals("25",result.getPayloadAsString());
    20.     }
    21. }

  • Add OpenEJB3.1 to pom

    • We will deploy the EJB in OpenEJB at runtime so we need the OpenEJB depencies with the 'test' scope. Here is the snippet of the pom.xml:

    PLAIN TEXT
    XML:
    1. <dependency>
    2.             <groupId>org.apache.openejb</groupId>
    3.             <artifactId>openejb-core</artifactId>
    4.             <version>3.1</version>
    5.             <scope>test</scope>
    6.             <exclusions>
    7.                 <exclusion>
    8.                     <groupId>commons-lang</groupId>
    9.                     <artifactId>commons-lang</artifactId>
    10.                 </exclusion>
    11.             </exclusions>
    12.         </dependency>

    As you can see I make use of OpenEJB3.1 instead of OpenEJB1.0 that is used with the supplied examples in Mule (to use the 3.1 version you must exclude the commons-lang dependency to avoid a NoSuchMethodError).
    The complete pom can be found here.

  • Add ejb-jar.xml
    To have our EJB3 classes deployed in OpenEJB I added an empty ejb-jar.xml to the classpath by adding the file to the /test/resources/META-INF directory. Here is a snippet of my project in Netbeans:
  • Test the project

    • Now you can perform a mvn clean install to test your Mule configuration. You will get a result like this:

    -------------------------------------------------------
    T E S T S
    -------------------------------------------------------
    Running net.pascalalma.mule.mathservice.MathServiceTestCase

    ========================================================================
    = Testing: math service (net.pascalalma.mule.mathservice.MathServiceTestCase) =
    ========================================================================
    Apache OpenEJB 3.1 build: 20081009-03:31

    http://openejb.apache.org/

    Result: 25

    Results :

    [jar:jar]
    Building jar: /Users/pascal/projects/mathService/target/mathservice-1.0-SNAPSHOT.jar
    [install:install]
    Installing /Users/pascal/projects/mathService/target/mathservice-1.0-SNAPSHOT.jar to /Users/pascal/.m2/repository/net/pascalalma/mule/mathservice/1.0-SNAPSHOT/mathservice-1.0-SNAPSHOT.jar
    ------------------------------------------------------------------------
    BUILD SUCCESSFUL
    ------------------------------------------------------------------------
    Total time: 19 seconds
    Finished at: Sat Mar 28 15:30:13 CET 2009
    Final Memory: 27M/48M
    ------------------------------------------------------------------------

]]> http://blog.redstream.nl/2009/04/01/calling-ejb3-with-mule-and-test-it-with-openejb/feed/ 2 Using OpenEJB for EJB3 testing with Maven2 http://blog.redstream.nl/2009/02/20/using-openejb-for-ejb3-testing-with-maven2/ http://blog.redstream.nl/2009/02/20/using-openejb-for-ejb3-testing-with-maven2/#comments Fri, 20 Feb 2009 18:14:06 +0000 Pascal Alma http://www.pascalalma.net/?p=530 Like I promised here I will show my project setup in which I test my EJB3 beans with OpenEJB. Although there are a lot of examples provided with OpenEJB I ran into some minor issues that I will explain here. I assume the Maven2 basics are known so I won't go into much detail about that.

This is my stack:

  • JDK1.5
  • Maven2
  • EJB3 project
  • Glassfish EJB Container


I have the following project structure:

  • my-project (parent pom)
  • my-core (jar)
  • my-entities (jar)
  • my-services (ejb)
  • my-business-services (ejb)
  • my-business-services-ear (ear)

The used Maven2 'settings.xml' can be viewed here (use view source if your browser messes up the xml content). The use of the 'develop' and 'test' profile will be clarified later. The 'repos' profile makes all necessary repositories available for downloading.

Next I will go through each module and explain the important parts of it in relation with the unit testing of the code. Please notice that the Java examples are just examples, they are not written with the idea to be used in a real application.

  • The parent project

    • Contains nothing but the parent pom. The parent pom looks like this.

  • The 'my-core' module

    • This is just a simple jar-module that will contain all constants and utility classes that are used throughout the application. The pom looks like
    this.
    There is no special configuration here.

  • The 'my-model' module

    • This one contains the model of the application which are in this case the EJB Entity objects reflecting the underlying database model. The content of the project:

    $ find . -type f
    ./pom.xml
    ./src/main/java/net/pascalalma/model/Customer.java
    ./src/main/resources/META-INF/ejb-jar.xml
    ./src/main/resources/META-INF/MANIFEST.MF
    ./src/main/resources/META-INF/persistence.xml

    The Customer.java is just a simple Entity bean.
    The pom of the project looks like this (complete file is here).

    PLAIN TEXT
    XML:
    1. ...
    2.     <dependencies>
    3.         <!-- Libraries necessary for compiling -->
    4.         <dependency>
    5.             <groupId>glassfish</groupId>
    6.             <artifactId>appserv-rt.jar</artifactId>
    7.             <version>LATEST</version>
    8.             <scope>system</scope>
    9.             <systemPath>${glassfish.home}/lib/appserv-rt.jar</systemPath>
    10.         </dependency>
    11.         <dependency>
    12.             <groupId>glassfish</groupId>
    13.             <artifactId>javaee.jar</artifactId>
    14.             <version>LATEST</version>
    15.             <scope>system</scope>
    16.             <systemPath>${glassfish.home}/lib/javaee.jar</systemPath>
    17.         </dependency>
    18.     </dependencies>
    19.     <build>
    20.         <resources>
    21.             <resource>
    22.                 <!-- Use filtering so the property values are written to persistnece.xml
    23.                      based on the selected profile (develop or test) -->
    24.                 <directory>src/main/resources</directory>
    25.                 <filtering>true</filtering>
    26.             </resource>
    27.         </resources>
    28.     </build>
    29. ...

    As you can see I refer to the Glassfish jars to compile my bean. You can pick your own JEE implementation here. Another thing I do is filtering the persistence.xml. This file looks like:

    PLAIN TEXT
    XML:
    1. <persistence version="1.0" xmlns="http://java.sun.com/xml/ns/persistence">
    2.   <persistence-unit name="MyPersistenceUnit" transaction-type="JTA">
    3.     <provider>org.hibernate.ejb.HibernatePersistence</provider>
    4.     <jta-data-source>jdbc/MyDS</jta-data-source>
    5.     <properties>
    6.       <property name="hibernate.cache.provider_class" value="org.hibernate.cache.NoCacheProvider"/>
    7.       <property name="hibernate.transaction.manager_lookup_class" value="org.apache.openejb.hibernate.TransactionManagerLookup"/>
    8.       <property name="hibernate.show_sql" value="${hibernate.show_sql}"/>
    9.       <property name="hibernate.hbm2ddl.auto" value="${hibernate.hbm2ddl.auto}"/>
    10.     </properties>
    11.   </persistence-unit>
    12. </persistence>

    Some Hibernate values are depending on the profile I chose when building the project (see the settings.xml I showed at the beginning of this post). I have two profiles: 'develop' and 'test'. In 'develop' mode Hibernate will drop and recreate all tables in my entity objects. And that is good because this is necessary for my unit tests to succeed. But when I am deploying this ear on my test server and the datasource is referring to my test database I don't want this 'dropping and recreating' to happen. That's why I created this 'switch'. When creating an ear to be deployed on our test server I have to choose the 'test' profile so no dropping of the scheme occurs and this will also result in skipping the tests when building the ear file, since these would fail anyway. Although this is not fail safe at all, it's something I can live with at the moment.
    Finally there is the 'ejb-jar.xml' file in the project. This one is empty and only there because OpenEJB needs it to recognize the EJBs.

  • The 'my-services' module

    • Now the real work begins. This module contains the fine grained services that are based at one entity.
    The module contains:

    $ find . -type f
    ./pom.xml
    ./src/main/java/net/pascalalma/myservices/CustomerServiceBean.java
    ./src/main/java/net/pascalalma/myservices/CustomerServiceLocal.java
    ./src/main/resources/META-INF/ejb-jar.xml
    ./src/main/resources/META-INF/MANIFEST.MF
    ./src/test/java/net/pascalalma/myservices/EJBTestBase.java
    ./src/test/java/net/pascalalma/myservices/TestCustomerService.java
    ./src/test/resources/import.sql
    ./src/test/resources/log4j.properties
    ./src/test/resources/META-INF/ejb-jar.xml

    First let's look at the pom (complete version here):

    PLAIN TEXT
    XML:
    1. ...
    2.     <dependencies>
    3.         ...
    4.         <!-- libraries necessary for testing -->
    5.         <dependency>
    6.             <groupId>org.apache.openejb</groupId>
    7.             <artifactId>openejb-core</artifactId>
    8.             <version>3.1</version>
    9.             <scope>test</scope>
    10.         </dependency>
    11.         <dependency>
    12.             <groupId>org.hibernate</groupId>
    13.             <artifactId>hibernate-entitymanager</artifactId>
    14.             <version>3.4.0.GA</version>
    15.             <scope>test</scope>
    16.         </dependency>
    17.         <dependency>
    18.     ...
    19.     </dependencies>
    20.     <build>
    21.         <plugins>
    22.             <plugin>
    23.                 <groupId>org.apache.maven.plugins</groupId>
    24.                 <artifactId>maven-ejb-plugin</artifactId>
    25.                 <configuration>
    26.                     <generateClient>false</generateClient>
    27.                     <ejbVersion>3.0</ejbVersion>
    28.                 </configuration>
    29.             </plugin>
    30.         </plugins>
    31.         <finalName>my-services</finalName>
    32.     </build>
    33. ...

    I have added some new depencies for testing the module: the OpenEJB dependency and some hibernate libraries. And I have configured the ejb-plugin to create an EJB3 jar of the module, notice that the packaging of the project is set to 'ejb'.
    The bean files themselves contain nothing special.
    The interface here and the implementation here.

    Then the test files. The first I want to mention is the 'import.sql'import. This is used by a feature of Hibernate. It executes the 'import.sql' file as it is found on the classpath after creating the database. For now this is sufficient but I am not sure about the future.
    Then there is the 'EJBTestBase.java'. Actually this code is based on the examples that are provided with OpenEJB. There is one 'hack' to make it possible to test your methods inside an existing transaction but this is also described in the examples. This 'hack' is also the reason for the ejb-jar.xml in the test resources. A new 'TransactionBean' is instantiated in this context so an ejb-jar.xml is necessary.
    And finally there is the 'TestCustomerService.java' where the testing of the session bean is done. In this file the JNDI lookup is essential:

    PLAIN TEXT
    JAVA:
    1. csb = (CustomerServiceLocal)context.lookup("CustomerServiceBeanLocal");

    The JNDI name is configurable in OpenEJB and by default differs from the used syntax in Glassfish. But since this test class won't be used in Glassfish that's no problem here, but something to keep in mind if you need JNDI look ups in your production code.

  • the module 'my-business-services'

    • This module contains the following files:

    $ find . -type f./pom.xml
    ./src/main/java/net/pascalalma/mybusinessservices/CustomerBusinessServiceBean.java
    ./src/main/java/net/pascalalma/mybusinessservices/CustomerBusinessServiceRemote.java
    ./src/main/resources/log4j.properties
    ./src/main/resources/META-INF/ejb-jar.xml
    ./src/test/java/net/pascalalma/mybusinessservices/TestCustomerbusinessService.java
    ./src/test/resources/import.sql

    The pom of this project contains nothing new. We have seen all used dependencies and plugins in other modules already.
    The EJB is made up of a remote interface 'CustomerBusinessServiceRemote' and its implementation 'CustomerBusinessServiceBean'. The most important thing here is the injection of a session bean into this bean:

    PLAIN TEXT
    JAVA:
    1. ...
    2.  @EJB
    3.  private CustomerServiceLocal cs;
    4.  ...

    The bean in this module is tested with the class 'TestCustomerbusinessService'.
    This test class looks similar to the one in the 'my-service' module. We also use a JNDI lookup in the local EJb container to get a pointer to the 'business service' bean and then call the methods on it.

    PLAIN TEXT
    JAVA:
    1. ...
    2.   ots = (CustomerBusinessServiceRemote) context.lookup("CustomerBusinessServiceRemote");
    3.   assert ots != null;
    4.   ots.validateCustomer("1");
    5.   ..

  • The 'my-business-services-ear' module

    • This project only contains a 'pom.xml' that contains the necessary configuration to create an ear file for the whole project and a plugin to deploy it to GlassFish.

To test the final deployment in Glassfish I turned my remote interface into a webservice by adding this to the interface:

PLAIN TEXT
JAVA:
  1. @WebService
  2. @SOAPBinding(style = javax.jws.soap.SOAPBinding.Style.DOCUMENT
  3.             ,use = javax.jws.soap.SOAPBinding.Use.LITERAL
  4.             ,parameterStyle = javax.jws.soap.SOAPBinding.ParameterStyle.WRAPPED)

and this to the class:

PLAIN TEXT
JAVA:
  1. @WebService( endpointInterface = "net.pascalalma.mybusinessservices.CustomerBusinessServiceRemote"
  2.            , serviceName = "CustomerBusinessService")

If I try to build this, however, the remote interface dissapears in the JNDI tree of OpenEJB?!?! So the unit test for this EJB will fail. I worked around this to just build the ear by skipping the tests and deploy it (see this post for more info about deploying to Glassfish with Maven).
A nicer solution would be to add a local interface for the EJB and use that one in the test class. This way the implementation stays the same and that is what is supposed to be tested.

]]> http://blog.redstream.nl/2009/02/20/using-openejb-for-ejb3-testing-with-maven2/feed/ 6 Testing EJB3 with Maven2 http://blog.redstream.nl/2009/02/19/testing-ejb3-with-maven2/ http://blog.redstream.nl/2009/02/19/testing-ejb3-with-maven2/#comments Thu, 19 Feb 2009 14:30:31 +0000 Pascal Alma http://www.pascalalma.net/?p=508 I am setting up a new JEE project. In this project we will use EJB3 as framework for the business layer. And of course we are using Maven to build, test and deploy the application. One important issue I have to deal with is how to (unit)test this business layer.
I had a look at the following options:


I started with EJB3Unit. I had looked into this one before and based on the name it should do the trick. However, I can't recall the reason but at that time I decided it didn't work out for me. This most probably had to do with my limited knowledge of EJB3Unit and is no disqualifier for the product in general!
So the next attempt I took was the one described at this page. This approach was quite easy to understand and I had it running in no time. But after a few days when the project sources were growing I noticed this way of setting up tests needs code duplication and more important: you can only test the JPA part of the simple EJBs. Not something like dependency injection of EJBs into another one and then test that bean. Maybe this isn't considered as a unit test anymore but it is definitely something I want to test when building my project!
So I looked further and came across OpenEJB. This lead to another approach of testing my sources. Instead of setting up two data-sources like in step 2 (one data-source for testing and one for real) I now use 2 EJB containers, each with the same data-source definition, but with actually different database implementations. Although this means I am no longer testing outside the container, it is what I wanted. I can now test all my EJBs, both simple and complex ones. There are a lot of examples about how to use openEJB on their site and it is nicely integrated with Maven2. The only disadvantage that might become a problem is the time a complete compile-test cycling will take if the project become larger. But for now I will go this way.
In a next post I will show the setup of my project to get the whole thing running because there are some small things to be aware of.

]]> http://blog.redstream.nl/2009/02/19/testing-ejb3-with-maven2/feed/ 1