• 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 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.  
5. @Remote
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 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 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:
• Use EJB3Unit
• Make my own base test classes
• Use OpenEJB container


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 http://blog.redstream.nl/2009/02/11/create-a-ejb3-webservice-with-maven2-running-on-glassfish/ http://blog.redstream.nl/2009/02/11/create-a-ejb3-webservice-with-maven2-running-on-glassfish/#comments Wed, 11 Feb 2009 12:04:03 +0000 Pascal Alma http://www.pascalalma.net/?p=476 A year ago I posted how you could create a EJB3 webservice and deploy it on JBoss with Maven. Currently I am doing a similar thing at my project, but this time I deploy it to Glassfish. The creation of the web serive is similar but for the deployment you will need another plugin (if you want Maven to deploy the webservice, of course).
The 'settings.xml' file for Maven2 looks like:
PLAIN TEXT
XML:
1. <settings>
2. <profiles>
3.   <profile>
4.       <id>develop</id>
5.       <properties>
6.         <glassfish.home>/Applications/NetBeans/glassfish-v2ur2</glassfish.home>
7.          <hibernate.show_sql>true</hibernate.show_sql>
8.       </properties>
9.       <pluginRepositories>
10.         <pluginRepository>
11.             <id>maven.java.net</id>
12.             <name>Java.net Maven2 Repository</name>
13.             <url>http://download.java.net/maven/2</url>
14.         </pluginRepository>
15.       </pluginRepositories>
16.   </profile>
17.   </profiles>
18.   <activeProfiles>
19.     <activeProfile>develop</activeProfile>
20.   </activeProfiles>
21. </settings>

Lateron we'll see that Maven uses the Glassfish plugin and the property for the deployment of our application.
I have created a project 'my-ejb-project' with a simple EJB session bean. The bean (and it's interface) looks like this:

PLAIN TEXT
JAVA:
1. package net.pascalalma.services;
2.  
3. import javax.ejb.Remote;
4.  
5. @Remote
6. public interface EchoService {
7.  
8.     public String sayHello(String subject);
9. }

and its implementation:

PLAIN TEXT
JAVA:
1. package net.pascalalma.services.impl;
2.  
3. import javax.ejb.Stateless;
4. import net.pascalalma.services.EchoService;
5.  
6. @Stateless
7. public class EchoServiceBean implements EchoService {
8.  
9.     public String sayHello(String name) {
10.         return "Hi " + name + "!";
11.     }
12. }

To build this project I have this in the project's pom.xml file:

PLAIN TEXT
XML:
1. <project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/maven-v4_0_0.xsd">
2.     <modelVersion>4.0.0</modelVersion>
3.     <groupId>net.pascalalma</groupId>
4.     <artifactId>my-ejb-project</artifactId>
5.     <packaging>ejb</packaging>
6.     <version>1.0-SNAPSHOT</version>
7.     <name>my-ejb-project</name>
8.     <url>http://www.pascalalma.net</url>
9.     <dependencies>
10.         <dependency>
11.             <groupId>glassfish</groupId>
12.             <artifactId>appserv-rt.jar</artifactId>
13.             <version>LATEST</version>
14.             <scope>system</scope>
15.             <systemPath>${glassfish.home}/lib/appserv-rt.jar</systemPath>
16.         </dependency>
17.         <dependency>
18.             <groupId>glassfish</groupId>
19.             <artifactId>javaee.jar</artifactId>
20.             <version>LATEST</version>
21.             <scope>system</scope>
22.             <systemPath>${glassfish.home}/lib/javaee.jar</systemPath>
23.         </dependency>
24.         <dependency>
25.             <groupId>junit</groupId>
26.             <artifactId>junit</artifactId>
27.             <version>4.1</version>
28.             <scope>test</scope>
29.         </dependency>
30.     </dependencies>
31.     <build>
32.         <sourceDirectory>src/main/java</sourceDirectory>
33.         <finalName>my-ejb-project</finalName>
34.         <plugins>
35.             <plugin>
36.                 <groupId>org.apache.maven.plugins</groupId>
37.                 <artifactId>maven-compiler-plugin</artifactId>
38.                 <configuration>
39.                     <source>1.5</source>
40.                     <target>1.5</target>
41.                 </configuration>
42.             </plugin>
43.             <plugin>
44.                 <groupId>org.apache.maven.plugins</groupId>
45.                 <artifactId>maven-ejb-plugin</artifactId>
46.                 <configuration>
47.                     <ejbVersion>3.0</ejbVersion>
48.                 </configuration>
49.             </plugin>
50.         </plugins>
51.     </build>
52. </project>

As you can see I am referring to the libraries of Glassfish of my local installation. It appears that the libraries you get from the global Maven repositories only contain the interfaces and no implementation so these can not be used when you want (unit) test your beans outside the container.

Besides this ejb-project I have also created a ear-project that is used to create an ear file containing the EJB's jar file (and optionally other deliverables like war-file etc). The pom file of this project looks like (the project doesn't contain anything else):

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</groupId>
5.   <artifactId>my-ear-project</artifactId>
6.   <packaging>ear</packaging>
7.   <version>1.0-SNAPSHOT</version>
8.   <name>my-ear-project</name>
9.   <url>http://maven.apache.org</url>
10.     <dependencies>
11.         <dependency>
12.             <groupId>net.pascalalma</groupId>
13.             <artifactId>my-ejb-project</artifactId>
14.             <version>1.0-SNAPSHOT</version>
15.             <type>ejb</type>
16.         </dependency>
17.     </dependencies>
18.     <build>
19.         <plugins>
20.             <plugin>
21.                 <artifactId>maven-ear-plugin</artifactId>
22.                 <configuration>
23.                     <displayName>My Service</displayName>
24.                     <description>My EJB Component for Echo Service</description>
25.                     <version>1.4</version>
26.                     <modules>
27.                         <ejbModule>
28.                             <groupId>net.pascalalma</groupId>
29.                             <artifactId>my-ejb-project</artifactId>
30.                         </ejbModule>
31.                     </modules>
32.                 </configuration>
33.             </plugin>
34.             <plugin>
35.                 <groupId>org.glassfish.maven.plugin</groupId>
36.                 <artifactId>maven-glassfish-plugin</artifactId>
37.                 <version>2.1</version>
38.  
39.                 <configuration>
40.                     <glassfishDirectory>${glassfish.home}</glassfishDirectory>
41.                     <user>admin</user>
42.                     <passwordFile>${glassfish.home}/domains/domain1/config/domain-passwords</passwordFile>
43.                     <autoCreate>false</autoCreate>
44.                     <debug>true</debug>
45.                     <echo>true</echo>
46.                     <terse>false</terse>
47.                     <domain>
48.                         <name>domain1</name>
49.                         <httpPort>8080</httpPort>
50.                         <adminPort>4848</adminPort>
51.                         <reuse>true</reuse>
52.                     </domain>
53.                     <components>
54.                         <component>
55.                             <name>${project.artifactId}</name>
56.                             <artifact>${project.build.directory}/${project.build.finalName}.ear</artifact>
57.                         </component>
58.                     </components>
59.                 </configuration>
60.             </plugin>
61.         </plugins>
62.     </build>
63. </project>

With all this in place we are able to build the EJB3 project with the command:
mvn clean install
and to package and deploy the EAR project with:
mvn clean package glassfish:deploy
In the Admin Console of Glasfish you will see the deployed project if everything went well:


To make our EJB3 bean available as a webservice, we have to add some annotations to the source, so the code of the interface and the bean will become something like this:

PLAIN TEXT
JAVA:
1. package net.pascalalma.services;
2.  
3. import javax.ejb.Remote;
4. import javax.jws.WebService;
5. import javax.jws.soap.SOAPBinding;
6.  
7. @Remote
8. @WebService
9. @SOAPBinding(style = javax.jws.soap.SOAPBinding.Style.DOCUMENT
10.             ,use = javax.jws.soap.SOAPBinding.Use.LITERAL
11.             ,parameterStyle = javax.jws.soap.SOAPBinding.ParameterStyle.WRAPPED)
12. public interface EchoService {
13.  
14.     public String sayHello(String subject);
15. }

and the implementation class:

PLAIN TEXT
JAVA:
1. package net.pascalalma.services.impl;
2.  
3. import javax.ejb.Stateless;
4. import javax.jws.WebService;
5. import net.pascalalma.services.EchoService;
6.  
7. @Stateless
8. @WebService(endpointInterface = "net.pascalalma.services.EchoService",serviceName="EchoService")
9. public class EchoServiceBean implements EchoService {
10.  
11.     public String sayHello(String name) {
12.         return "Hi " + name + "!";
13.     }
14. }

That's it! Now rebuild and redeploy the packages and it is done!
To test the webservice I 'll use the Admin Console of Glassfish again. You will see under the heading 'Web Services' that there is added a web service:


Now select that web service and you will get a screen where you can enter the Test page for this service:


After clicking the button we can enter a value as input parameter for our service:


And the Admin Console will show the result of our call by showing the soap messages (request+ response):


Of course, this test functionality is much more limited then we have in SoapUI but to quickly check if the service is running it will do just fine.

]]> http://blog.redstream.nl/2009/02/11/create-a-ejb3-webservice-with-maven2-running-on-glassfish/feed/ 3 http://blog.redstream.nl/2008/02/03/creating-an-ejb3-webservice-with-maven2-running-on-jboss-421/ http://blog.redstream.nl/2008/02/03/creating-an-ejb3-webservice-with-maven2-running-on-jboss-421/#comments Sun, 03 Feb 2008 09:48:40 +0000 Pascal Alma http://www.pascalalma.net/2008/02/03/creating-an-ejb3-webservice-with-maven2-running-on-jboss-421/ In this blog I'll show you how you can create a WebService of your EJB3 objects by using anotations. I will also show you how to build and deploy the package with Maven2. Let's start with the initial situation.
I have installed JBoss 4.2.1 and Maven2. In my settings.xml of Maven2 I have set a property pointing to my JBoss installation and I have defined a JBoss/Maven2 repository.

The settings.xml file looks like this:
PLAIN TEXT
XML:
1. <settings>
2.   <localRepository>d:/maven2/repo/</localRepository>
3.   <profiles>
4.     <profile>
5.       <id>default-repositories</id>
6.       <repositories>
7.         <repository>
8.           <id>global</id>
9.           <name>External Mirror of Central Repository</name>
10.           <url>http://repo1.maven.org/maven2</url>
11.         </repository>
12.         <repository>
13.           <id>repo.maven</id>
14.           <url>http://repo1.maven.org/maven2-repoclean-java.net</url>
15.         </repository>
16.         <repository>
17.           <id>jboss.maven</id>
18.           <url>http://repository.jboss.com/maven2/</url>
19.         </repository>
20.       </repositories>
21.       <pluginRepositories>
22.         <pluginRepository>
23.           <id>repo1org</id>
24.           <name>External Plugin Repository</name>
25.           <url>http://repo1.maven.org/maven2/</url>
26.         </pluginRepository>
27.       </pluginRepositories>
28.     </profile>
29.     <profile>
30.       <id>property-overrides</id>
31.       <properties>
32.         <jboss.home>C:\java\jboss-4.2.1.GA</jboss.home>
33.       </properties>
34.     </profile>
35.   </profiles>
36.   <activeProfiles>
37.     <activeProfile>property-overrides</activeProfile>
38.     <activeProfile>default-repositories</activeProfile>
39.   </activeProfiles>
40. </settings>

Lateron we'll see that Maven uses the JBoss plugin and the property for the deployment of our application.

I have created a project 'my-ejb-project' with a simple EJB session bean. The bean (and it's interface) looks like this:

PLAIN TEXT
JAVA:
1. package net.pascalalma.services;
2.  
3. import javax.ejb.Remote;
4.  
5. @Remote
6. public interface EchoService {
7.  
8.     public String sayHello(String subject);
9. }

and the implementation:

PLAIN TEXT
JAVA:
1. package net.pascalalma.services.impl;
2.  
3. import javax.ejb.Stateless;
4.  
5. import net.pascalalma.services.EchoService;
6.  
7. @Stateless
8. public class EchoServiceBean implements EchoService {
9.  
10.     public String sayHello(String name)
11.     {
12.         return "Hi " + name + "!";
13.     }
14. }

To build this project I have this in the project's pom.xml file:

PLAIN TEXT
XML:
1. <?xml version="1.0" encoding="UTF-8"?>
2. <project xmlns="http://maven.apache.org/POM/4.0.0"
3.     xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
4.     xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/maven-v4_0_0.xsd">
5.     <modelVersion>4.0.0</modelVersion>
6.     <groupId>net.pascalalma</groupId>
7.     <artifactId>my-ejb-project</artifactId>
8.     <version>1.0</version>
9.     <packaging>ejb</packaging>
10.  
11.     <build>
12.         <sourceDirectory>src/main/java</sourceDirectory>
13.         <finalName>my-ejb-project</finalName>
14.         <plugins>
15.             <plugin>
16.                 <artifactId>maven-compiler-plugin</artifactId>
17.                 <configuration>
18.                     <source>1.5</source>
19.                     <target>1.5</target>
20.                 </configuration>
21.             </plugin>
22.             <plugin>
23.                 <groupId>org.apache.maven.plugins</groupId>
24.                 <artifactId>maven-javadoc-plugin</artifactId>
25.                 <configuration>
26.                     <classpath>/src/main/java</classpath>
27.                 </configuration>
28.             </plugin>
29.             <plugin>
30.                 <artifactId>maven-ejb-plugin</artifactId>
31.                 <configuration>
32.                     <ejbVersion>3.0</ejbVersion>
33.                     <archive>
34.                         <manifest>
35.                             <addClasspath>true</addClasspath>
36.                         </manifest>
37.                     </archive>
38.                 </configuration>
39.             </plugin>
40.         </plugins>
41.     </build>
42.     <dependencies>
43.         <dependency>
44.             <groupId>org.apache.geronimo.specs</groupId>
45.             <artifactId>geronimo-jpa_3.0_spec</artifactId>
46.             <version>1.1</version>
47.             <scope>provided</scope>
48.         </dependency>
49.         <dependency>
50.             <groupId>org.apache.geronimo.specs</groupId>
51.             <artifactId>geronimo-ejb_3.0_spec</artifactId>
52.             <version>1.0</version>
53.             <scope>provided</scope>
54.         </dependency>
55.         <dependency>
56.             <groupId>junit</groupId>
57.             <artifactId>junit</artifactId>
58.             <version>4.1</version>
59.             <scope>test</scope>
60.         </dependency>
61.     </dependencies>
62.     <reporting>
63.         <plugins>
64.             <plugin>
65.                 <groupId>org.apache.maven.plugins</groupId>
66.                 <artifactId>maven-surefire-report-plugin</artifactId>
67.             </plugin>
68.             <plugin>
69.                 <groupId>org.apache.maven.plugins</groupId>
70.                 <artifactId>maven-jxr-plugin</artifactId>
71.             </plugin>
72.         </plugins>
73.     </reporting>
74. </project>

Besides this ejb-project I have also created a ear-project that is used to create an ear file containing the EJB's jar file (and optionally other deliverables like war-file etc). The pom file of this project looks like (the project doesn't contain anything else):

PLAIN TEXT
XML:
1. <?xml version="1.0" encoding="UTF-8"?>
2. <project xmlns="http://maven.apache.org/POM/4.0.0"
3.     xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
4.     xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/maven-v4_0_0.xsd">
5.     <modelVersion>4.0.0</modelVersion>
6.     <groupId>net.pascalalma</groupId>
7.     <artifactId>my-ear-project</artifactId>
8.     <packaging>ear</packaging>
9.     <version>1.0</version>
10.     <name>my-ear-project</name>
11.     <dependencies>
12.         <dependency>
13.             <groupId>net.pascalalma</groupId>
14.             <artifactId>my-ejb-project</artifactId>
15.             <version>1.0</version>
16.             <type>ejb</type>
17.         </dependency>
18.     </dependencies>
19.     <build>
20.         <plugins>
21.             <plugin>
22.                 <groupId>org.codehaus.mojo</groupId>
23.                 <artifactId>jboss-maven-plugin</artifactId>
24.                 <configuration>
25.                     <jbossHome>${jboss.home}</jbossHome>
26.                     <serverName>default</serverName>
27.                     <port>8080</port>
28.                 </configuration>
29.             </plugin>
30.             <plugin>
31.                 <artifactId>maven-ear-plugin</artifactId>
32.                 <configuration>
33.                     <displayName>My EJB Component</displayName>
34.                     <description>My EJB Component</description>
35.                     <version>1.4</version>
36.                     <modules>
37.                         <ejbModule>
38.                             <groupId>net.pascalalma</groupId>
39.                             <artifactId>my-ejb-project</artifactId>
40.                         </ejbModule>
41.                     </modules>
42.                 </configuration>
43.             </plugin>
44.         </plugins>
45.     </build>
46. </project>

With all this in place we are able to build the EJB3 project with the command:
c:\workspace\my-ejb-project\mvn clean install
and to package and deploy the EAR project with:
c:\workspace\my-ear-project\mvn clean package jboss:harddeploy

To make our EJB3 bean available as a webservice, we have to add some annotations to the source, so the code of the interface and the bean will become something like this:

PLAIN TEXT
JAVA:
1. package net.pascalalma.services;
2.  
3. import javax.ejb.Remote;
4. import javax.jws.WebService;
5.  
6. @Remote
7. @WebService()
8. public interface EchoService {
9.  
10.     public String sayHello(String subject);
11. }

and the implementation class:

PLAIN TEXT
JAVA:
1. package net.pascalalma.services.impl;
2.  
3. import javax.ejb.Stateless;
4. import javax.jws.WebService;
5. import javax.jws.soap.SOAPBinding;
6.  
7. import net.pascalalma.services.EchoService;
8.  
9. @Stateless
10. @WebService(endpointInterface = "net.pascalalma.services.EchoService",serviceName="EchoService")
11. @SOAPBinding(style = javax.jws.soap.SOAPBinding.Style.DOCUMENT)
12. public class EchoServiceBean implements EchoService {
13.     @javax.jws.WebMethod()
14.     public String sayHello(String name)
15.     {
16.         return "Hi " + name + "!";
17.     }
18. }

That's it! The only thing left is that we have to add a new dependency to the pom (for the javax.jws.*). The dependency looks like:

PLAIN TEXT
XML:
1. <dependency>
2.       <groupId>xfire</groupId>
3.       <artifactId>xfire-jsr181-api</artifactId>
4.       <version>1.0-M1</version>
5.       <scope>provided</scope>
6.     </dependency>

As you can see the dependency has the scope 'provided' because the library is already available in JBoss, so we don't want to package it in our jar file.

Now rebuild and redeploy the packages and it is done!

To test the webservice I use my favorite tool 'Soap UI'. We can generate the necessary WSDL at runtime by going to the url: 'http://127.0.0.1:8080/EchoServiceBeanService/EchoServiceBean?wsdl'. The result in SOAP UI looks like this:


After sending the request we will get this respone:


I hope this post makes clear that is easy to make your EJB3 session beans available as a webservice, by simply adding some annotations to your code.

]]> http://blog.redstream.nl/2008/02/03/creating-an-ejb3-webservice-with-maven2-running-on-jboss-421/feed/ 17 http://blog.redstream.nl/2007/12/10/combining-enum-with-ejb3/ http://blog.redstream.nl/2007/12/10/combining-enum-with-ejb3/#comments Mon, 10 Dec 2007 07:20:19 +0000 Pascal Alma http://www.pascalalma.net/2007/12/10/combining-enum-with-ejb3/ Do you recognize this: Although you are using a tool to develop your applications for some time, you are suddenly surprised by a certain error message you haven't seen before? And you didn't do anything different compared to the last time you used it.
Well, my experience is that in 100 times out of a 100, you did do something different. My last time in this situation was when I wanted to use a Java 1.5 enum type as a field in my EJB3 entity bean. I had done this before and at first sight everything looked well. Here was what I did:
Since I deploy my EJB3 application on JBoss 4.2.1 I supplied JBoss with the following Hibernate configuration file:
PLAIN TEXT
XML:
1. <?xml version="1.0" encoding="UTF-8"?>
2.  
3. <persistence xmlns="http://java.sun.com/xml/ns/persistence"
4.     xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
5.     xsi:schemaLocation="http://java.sun.com/xml/ns/persistence http://java.sun.com/xml/ns/persistence/persistence_1_0.xsd"
6.     version="1.0">
7.     <persistence-unit name="kpn-jf" transaction-type="JTA">
8.         <jta-data-source>java:/jdbc/my-datasource</jta-data-source>
9.         <properties>
10.             <property name="hibernate.dialect" value="org.hibernate.dialect.MySQLDialect"/>
11.             <property name="hibernate.max_fetch_depth" value="3" />
12.             <property name="hibernate.hbm2ddl.auto" value="create" />
13.             <property name="hibernate.show_sql" value="true" />
14.         </properties>
15.     </persistence-unit>
16. </persistence>

With this file the EJB container creates all database objects when I deploy my application (although this goes against everything I have learned as former 'database' developer I now just enjoy the simplicity of it).
The enum type I was using was defined as:

PLAIN TEXT
JAVA:
1. package net.pascalalma.domains;
2.  
3. public enum Gender {
4.         U, // Unknown
5.         M, // Male
6.         F  // Female
7. }

And the Entity Bean I was using:

PLAIN TEXT
JAVA:
1. @Entity
2. @Table(name = "CUSTOMERS")
3. @NamedQueries(value = { @NamedQuery(name = "findCustomerByCode", query = "SELECT o FROM Customers o WHERE code = :code") })
4. public class Customer
5. {
6.     private long id;
7.     private String code;
8.     private String initials;
9.     private String lastName;
10.     private Gender gender;
11.  
12.         ......
13.  
14.         @Column(name = "GENDER")
15.     public Gender getGender() {
16.         return gender;
17.     }
18.     ......

Now, like I said before, at first there seemed nothing wrong with my application. I could run it and when I persisted Customers to the database I noticed rows were created in the database, so far so good. However, it went wrong as soon as I started to select an existing row and tried to make an Entity object of it. It was at this point I got the following stacktrace:

Caused by: java.lang.IllegalArgumentException: Unknown name value for enum class net.pascalalma.domains.Gender: 2
at org.hibernate.type.EnumType.nullSafeGet(EnumType.java:104)
at org.hibernate.type.CustomType.nullSafeGet(CustomType.java:105)
at org.hibernate.type.AbstractType.hydrate(AbstractType.java:81)
at org.hibernate.persister.entity.AbstractEntityPersister.hydrate(AbstractEntityPersister.java:2096)
at org.hibernate.loader.Loader.loadFromResultSet(Loader.java:1380)
at org.hibernate.loader.Loader.instanceNotYetLoaded(Loader.java:1308)
at org.hibernate.loader.Loader.getRow(Loader.java:1206)
at org.hibernate.loader.Loader.getRowFromResultSet(Loader.java:580)
at org.hibernate.loader.Loader.doQuery(Loader.java:701)
at org.hibernate.loader.Loader.doQueryAndInitializeNonLazyCollections(Loader.java:236)
at org.hibernate.loader.Loader.doList(Loader.java:2220)
at org.hibernate.loader.Loader.listIgnoreQueryCache(Loader.java:2104)
at org.hibernate.loader.Loader.list(Loader.java:2099)
at org.hibernate.loader.hql.QueryLoader.list(QueryLoader.java:378)
at org.hibernate.hql.ast.QueryTranslatorImpl.list(QueryTranslatorImpl.java:338)
at org.hibernate.engine.query.HQLQueryPlan.performList(HQLQueryPlan.java:172)
at org.hibernate.impl.SessionImpl.list(SessionImpl.java:1121)
at org.hibernate.impl.QueryImpl.list(QueryImpl.java:79)
at org.hibernate.ejb.QueryImpl.getSingleResult(QueryImpl.java:80)
at net.pascalalma.entities.Customer.findCustomerByCode(Customer.java:124)
at net.pascalalma.services.CustomerServiceBean.validateCustomer(CustomerServiceBean.java:114)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:585)
at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:112)
at org.jboss.ejb3.interceptor.InvocationContextImpl.proceed(InvocationContextImpl.java:166)
at org.jboss.ejb3.interceptor.EJB3InterceptorsInterceptor.invoke(EJB3InterceptorsInterceptor.java:63)
at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101)
at org.jboss.ejb3.entity.TransactionScopedEntityManagerInterceptor.invoke(TransactionScopedEntityManagerIntercep
tor.java:54)
at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101)
at org.jboss.ejb3.AllowedOperationsInterceptor.invoke(AllowedOperationsInterceptor.java:47)
at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101)
at org.jboss.aspects.tx.TxPolicy.invokeInOurTx(TxPolicy.java:79)
... 55 more
Caused by: java.lang.IllegalArgumentException: No enum const class net.pascalalma.domains.Gender.2
at java.lang.Enum.valueOf(Enum.java:192)
at org.hibernate.type.EnumType.nullSafeGet(EnumType.java:101)
... 88 more

Of course, my first reaction was WTF!?!?! This worked before and why doesn't it work right now??
Well, as an experienced developer I knew there had to be something different with the last time I did this (the chance it was the computer thinking, hey, let's do something else today seemed not so big ;-) ).
So after a short investigation I found out that I had forgotten an annotation in my Entity bean when defining the Gender field as enum. After adding this:

@Enumerated(EnumType.STRING)

the value of the enum was stored as String, and could be used succesfully when constructing the Entity object.
So this gives 'my mistake' vs. 'computer mistake' 101 to 0.....

]]> http://blog.redstream.nl/2007/12/10/combining-enum-with-ejb3/feed/ 2