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

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

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

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

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

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

If all this is in place you can deploy the ear/war file by using the command:
mvn clean deploy
Like I said before there is nothing JBoss specific to this and actually I am using the script to deploy my Mule applications to our Tomcat server.

• 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/2008/06/18/using-stax-parsing-with-jboss405ga/ http://blog.redstream.nl/2008/06/18/using-stax-parsing-with-jboss405ga/#comments Wed, 18 Jun 2008 12:45:12 +0000 Pascal Alma http://www.pascalalma.net/?p=137 In my former post (here) I described how to combine Spring WS with StAX parsing the SOAP messages. I ended with generating the WSDL as a test and said you could use Soap UI for testing the web service.
Well, I did. And I was running into the following error when I had deployed my web service at JBoss4.0.5.GA:
PLAIN TEXT
XML:
1. <env:Envelope xmlns:env="http://schemas.xmlsoap.org/soap/envelope/">
2.    <env:Header/>
3.    <env:Body>
4.       <env:Fault>
5.          <faultcode>env:Server</faultcode>
6.          <faultstring>Operation only supported for javax.xml.soap.Node, this is a [#comment: Test comment]</faultstring>
7.       </env:Fault>
8.    </env:Body>
9. </env:Envelope>


I fixed the issue by adding the following dependencies to the project's pom.xml:

PLAIN TEXT
XML:
1. <dependency>
2.     <groupId>com.sun.xml.messaging.saaj</groupId>
3.     <artifactId>saaj-impl</artifactId>
4.     <version>1.3</version>
5. </dependency>
6. <dependency>
7.     <groupId>javax.activation</groupId>
8.     <artifactId>activation</artifactId>
9.     <version>1.1</version>
10.     <scope>provided</scope>
11. </dependency>

If I don't add this dependencies, apparently Spring WS is using the JBossWS libraries as default, and these libraries can't handle the StAX parsing/writing abilities of Spring WS.
So, after adding the necessary dependencies and redeploying the web service I got the expected response:

PLAIN TEXT
XML:
1. <soap-ENV:Envelope xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/">
2.    <soap-ENV:Header/>
3.    <soap-ENV:Body>
4.       <hr:HolidayResponse xmlns:hr="http://www.pascalalma.net/hr/schemas">
5.          <!--Test comment-->
6.          <hr:Status>APPROVED</hr:Status>
7.       </hr:HolidayResponse>
8.    </soap-ENV:Body>
9. </soap-ENV:Envelope>

I don't know about other J(2)EE Servers but for this JBoss version you need these dependencies to get it working.

]]> http://blog.redstream.nl/2008/06/18/using-stax-parsing-with-jboss405ga/feed/ 0 http://blog.redstream.nl/2008/06/14/using-stax-with-spring-ws/ http://blog.redstream.nl/2008/06/14/using-stax-with-spring-ws/#comments Sat, 14 Jun 2008 06:35:12 +0000 Pascal Alma http://www.pascalalma.net/?p=130 As I have posted before we are using XFire to implement our web service. Unfortunately, we are running into some serious issues with the framework, so we decided to look after another implementation. Since XFire is no longer supported by the community (or at least at a very low profile) and 'replaced' by CXF, we decided to have a look at Spring WS. We also have used the Spring Framework throughout our application elsewhere, so this would be a logical choice. After a quick look at the framework it convinced us that this would be the framework to use for our web services. It was easy to set up and well documented.
In this post I will show you how to use StAX to parse and write the SOAP request and response in combination with Spring WS, Maven2 and JBoss.
1. Setup maven

First thing to do is to setup Maven2. I assume this won't be a problem, so I only show the settings.xml which I use for my Maven2 installation (you can also check out this post and this one):

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>dev-environment</id>
31.         <activation>
32.         <activeByDefault>true</activeByDefault>
33.           <property>
34.             <name>env</name>
35.             <value>dev</value>
36.           </property>
37.         </activation>
38.         <properties>
39.           <appserver.home>d:/java/jboss-4.0.5</appserver.home>
40.           <server.name>default</server.name>
41.         </properties>
42.     </profile>
43.   </profiles>
44.   <activeProfiles>
45.     <activeProfile>dev-environment</activeProfile>
46.     <activeProfile>default-repositories</activeProfile>
47.   </activeProfiles>
48. </settings>
2. Create a Maven2 web project

You can do this with this command (as described in more detail here):
mvn archetype:create -DgroupId=net.pascalalma -DartifactId=spring-ws-test
-DarchetypeArtifactId=maven-archetype-webapp

3. Create the XML Schema's (XSD) for the request and response SOAP messages

As an example I take the schema of the Spring WS reference documentation. The request is described there and I have added a response myself. Here is the xsd:

PLAIN TEXT
XML:
1. <xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema"
2.         xmlns:hr="http://www.pascalalma.net/hr/schemas"
3.         elementFormDefault="qualified"
4.         targetNamespace="http://www.pascalalma.net/hr/schemas">
5.     <xs:element name="HolidayRequest">
6.         <xs:complexType>
7.             <xs:all>
8.                 <xs:element name="Holiday" type="hr:HolidayType"/>
9.                 <xs:element name="Employee" type="hr:EmployeeType"/>
10.             </xs:all>
11.         </xs:complexType>
12.     </xs:element>
13.     <xs:complexType name="HolidayType">
14.         <xs:sequence>
15.             <xs:element name="StartDate" type="xs:date"/>
16.             <xs:element name="EndDate" type="xs:date"/>
17.         </xs:sequence>
18.     </xs:complexType>
19.     <xs:complexType name="EmployeeType">
20.         <xs:sequence>
21.             <xs:element name="Number" type="xs:integer"/>
22.             <xs:element name="FirstName" type="xs:string"/>
23.             <xs:element name="LastName" type="xs:string"/>
24.         </xs:sequence>
25.     </xs:complexType>
26.     <xs:element name="HolidayResponse" type="hr:Status" />
27.     <xs:simpleType name="Status">
28.       <xs:restriction base="xs:string">
29.         <xs:enumeration value="DENIED"/>
30.         <xs:enumeration value="PENDING"/>
31.         <xs:enumeration value="APPROVED"/>
32.       </xs:restriction>
33.     </xs:simpleType>
34. </xs:schema>

I have stored this schema as 'hr.xsd' in the directory '$PROJECT_HOME$/WEB-INF/schema'.

4. Configure the web application

We have to reroot the incoming HTTP request to the Spring WS servlet. TO do this we define the Spring WS servlet in the web.xml, like this:

PLAIN TEXT
XML:
1. <?xml version="1.0" encoding="UTF-8"?>
2. <!DOCTYPE web-app PUBLIC "-//Sun Microsystems, Inc.//DTD Web Application 2.3//EN"
3.   "http://java.sun.com/dtd/web-app_2_3.dtd">
4. <web-app>
5.     <!-- === Servlets === -->
6.     <servlet>
7.         <servlet-name>spring-ws</servlet-name>
8.         <display-name>Spring-WS Servlet</display-name>
9.         <servlet-class>
10.             org.springframework.ws.transport.http.MessageDispatcherServlet
11.         </servlet-class>
12.         <init-param>
13.             <param-name>transformWsdlLocations</param-name>
14.             <param-value>true</param-value>
15.         </init-param>
16.     </servlet>
17.     <servlet-mapping>
18.         <servlet-name>spring-ws</servlet-name>
19.         <url-pattern>/services/*</url-pattern>
20.     </servlet-mapping>
21.     <welcome-file-list id="WelcomeFileList">
22.         <welcome-file>index.html</welcome-file>
23.     </welcome-file-list>
24. </web-app>
5. Create model classes

Now it's time to start some Java coding. First I create the model classes that will represent the Objects as described by the xsd. We will have the following classes:
The Employee.java
The Holiday.java
And the HolidayRequest.java

6. Create the StAX parser and writer classes

To get from the incoming XML to our Java model classes we make use of StAX parsing and writing. Here are the two classes that do the XML-Object translation and back:
HolidayRequestReader.java
HolidayResponseWriter.java

7. Implement endpoint/webservice

The last Java class we have to make is the Webservice implementation itself. Since we want to use StAX parsing, I simply extend the Spring class 'AbstractStaxStreamPayloadEndpoint':

PLAIN TEXT
JAVA:
1. package net.pascalalma.ws;
2.  
3. import javax.xml.stream.XMLStreamReader;
4. import javax.xml.stream.XMLStreamWriter;
5.  
6. import net.pascalalma.model.HolidayRequest;
7. import net.pascalalma.xml.HolidayRequestReader;
8. import net.pascalalma.xml.HolidayResponseWriter;
9.  
10. import org.apache.commons.logging.Log;
11. import org.apache.commons.logging.LogFactory;
12. import org.springframework.ws.server.endpoint.AbstractStaxStreamPayloadEndpoint;
13.  
14. public class HolidayRequestService extends AbstractStaxStreamPayloadEndpoint
15. {
16.  
17.   private static final Log LOG = LogFactory.getLog(HolidayRequestService.class);
18.  
19.   @Override
20.   protected void invokeInternal(XMLStreamReader streamreader,
21.       XMLStreamWriter streamwriter) throws Exception
22.   {
23.     try
24.     {
25.       HolidayRequest hr = HolidayRequestReader.parseMessage(streamreader);
26.  
27.       LOG.info("Result = " + hr);
28.  
29.       HolidayResponseWriter.writeResponse(hr, streamwriter);
30.     } catch (Throwable t)
31.     {
32.       LOG.error("Catched exception", t);
33.     }
34.   }
35. }
8. Setup the SpringWS context

Now that we have all the Java classes in place we have to configure the Spring context that is used by our webservice implementation. In our case it looks like the following XML file that is stored under the name 'spring-ws-servlet' in the '$PROJECT_HOME$/webapp/WEB-INF' directory:

PLAIN TEXT
XML:
1. <?xml version="1.0" encoding="UTF-8"?>
2. <beans xmlns="http://www.springframework.org/schema/beans"
3.     xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
4.     xsi:schemaLocation="http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans-2.0.xsd">
5.     <bean
6.         class="org.springframework.ws.server.endpoint.mapping.PayloadRootQNameEndpointMapping">
7.         <property name="mappings">
8.             <props>
9.                 <prop
10.                     key="{http://www.pascalalma.net/hr/schemas}HolidayRequest">
11.                     myEndPoint
12.                 </prop>
13.             </props>
14.         </property>
15.     </bean>
16.     <bean id="myEndPoint"
17.         class="net.pascalalma.ws.HolidayRequestService">
18.     </bean>
19.     <bean id="holiday"
20.         class="org.springframework.ws.wsdl.wsdl11.DefaultWsdl11Definition">
21.         <property name="schema" ref="schema" />
22.         <property name="portTypeName" value="HumanResource" />
23.         <property name="locationUri"
24.             value="http://localhost:8080/spring-ws-test/services/holidayService/" />
25.         <property name="targetNamespace"
26.             value="http://www.pascalalma.net/hr/definitions" />
27.     </bean>
28.     <bean id="schema"
29.         class="org.springframework.xml.xsd.SimpleXsdSchema">
30.         <property name="xsd" value="/WEB-INF/schemas/hr.xsd" />
31.     </bean>
32. </beans>
9. Build and deploy to jboss

With this file as the project's POM file we can simply build, package and deploy our webservice to JBoss with the command in the command prompt:
mvn clean package jboss:harddeploy

10. Access wsdl in browser to test

If everything went well and JBoss is started, you can access the dynamically generated WSDL with the following url:
http://localhost:8080/spring-ws-test/services/holiday.wsdl
This should give the following WSDL in your browser:

PLAIN TEXT
XML:
1. <wsdl:definitions targetNamespace="http://www.pascalalma.net/hr/definitions">
2.   <wsdl:types>
3.     <xs:schema elementFormDefault="qualified" targetNamespace="http://www.pascalalma.net/hr/schemas">
4.       <xs:element name="HolidayRequest">
5.         <xs:complexType>
6.           <xs:all>
7.             <xs:element name="Holiday" type="hr:HolidayType"/>
8.             <xs:element name="Employee" type="hr:EmployeeType"/>
9.           </xs:all>
10.         </xs:complexType>
11.       </xs:element>
12.       <xs:complexType name="HolidayType">
13.         <xs:sequence>
14.           <xs:element name="StartDate" type="xs:date"/>
15.           <xs:element name="EndDate" type="xs:date"/>
16.         </xs:sequence>
17.       </xs:complexType>
18.       <xs:complexType name="EmployeeType">
19.         <xs:sequence>
20.           <xs:element name="Number" type="xs:integer"/>
21.           <xs:element name="FirstName" type="xs:string"/>
22.           <xs:element name="LastName" type="xs:string"/>
23.         </xs:sequence>
24.       </xs:complexType>
25.       <xs:element name="HolidayResponse" type="hr:Status"/>
26.       <xs:simpleType name="Status">
27.         <xs:restriction base="xs:string">
28.           <xs:enumeration value="DENIED"/>
29.           <xs:enumeration value="PENDING"/>
30.           <xs:enumeration value="APPROVED"/>
31.         </xs:restriction>
32.       </xs:simpleType>
33.     </xs:schema>
34.   </wsdl:types>
35.   <wsdl:message name="HolidayResponse">
36.     <wsdl:part element="sch:HolidayResponse" name="HolidayResponse">
37.     </wsdl:part>
38.   </wsdl:message>
39.   <wsdl:message name="HolidayRequest">
40.     <wsdl:part element="sch:HolidayRequest" name="HolidayRequest">
41.     </wsdl:part>
42.   </wsdl:message>
43.   <wsdl:portType name="HumanResource">
44.     <wsdl:operation name="Holiday">
45.       <wsdl:input message="tns:HolidayRequest" name="HolidayRequest">
46.       </wsdl:input>
47.       <wsdl:output message="tns:HolidayResponse" name="HolidayResponse">
48.       </wsdl:output>
49.     </wsdl:operation>
50.   </wsdl:portType>
51.   <wsdl:binding name="HumanResourceSoap11" type="tns:HumanResource">
52.     <soap:binding style="document" transport="http://schemas.xmlsoap.org/soap/http"/>
53.     <wsdl:operation name="Holiday">
54.       <soap:operation soapAction=""/>
55.       <wsdl:input name="HolidayRequest">
56.         <soap:body use="literal"/>
57.       </wsdl:input>
58.       <wsdl:output name="HolidayResponse">
59.         <soap:body use="literal"/>
60.       </wsdl:output>
61.     </wsdl:operation>
62.   </wsdl:binding>
63.   <wsdl:service name="HumanResourceService">
64.     <wsdl:port binding="tns:HumanResourceSoap11" name="HumanResourceSoap11">
65.       <soap:address location="http://localhost:8080/spring-ws-test/services/holidayService/"/>
66.     </wsdl:port>
67.   </wsdl:service>
68. </wsdl:definitions>

That's it. You can test your web service with a tool like SoapUI and create test cases based on the generated WSDL like I described here.

]]> http://blog.redstream.nl/2008/06/14/using-stax-with-spring-ws/feed/ 6 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/2008/01/29/classloader-issue-with-jboss-405ga/ http://blog.redstream.nl/2008/01/29/classloader-issue-with-jboss-405ga/#comments Tue, 29 Jan 2008 19:07:13 +0000 Pascal Alma http://www.pascalalma.net/2008/01/29/classloader-issue-with-jboss-405ga/ Today I was asked to help solving an issue with an application that was deployed on JBoss 4.0.5.GA. It had been running for some months without a problem, until a new application had to be deployed. This new application demanded that the isolation level in the 'ear-deployer.xml' config file had to be set to its default value 'false'. However, the setting was set to 'true' for some reason.

Here is the content of the file:
PLAIN TEXT
XML:
1. <?xml version="1.0" encoding="UTF-8"?>
2. <!-- The JBoss service configuration file for the EAR deployer service.
3. $Id: ear-deployer.xml 60679 2007-02-19 21:35:39Z scott.stark@jboss.org $
4. -->
5. <server>
6.    <!-- EAR deployer, remove if you are not using ear deployments -->
7.    <mbean code="org.jboss.deployment.EARDeployer"
8.       name="jboss.j2ee:service=EARDeployer">
9.       <!-- A flag indicating if ear deployments should have their own scoped
10.       class loader to isolate their classes from other deployments.
11.       -->
12.       <attribute name="Isolated">false</attribute>
13.       <!-- A flag indicating if the ear components should have in VM call
14.       optimization disabled.
15.       -->
16.       <attribute name="CallByValue">false</attribute>
17.       <!-- A flag the enables the default behavior of the ee5 library-directory. If true,
18.       the lib contents of an ear are assumed to be the default value for library-directory
19.       in the absence of an explicit library-directory. If false, there must be an
20.       explicit library-directory.
21.       -->
22.       <attribute name="EnablelibDirectoryByDefault">true</attribute>
23.    </mbean>
24. </server>

By setting the parameter back to 'false' and test the applications that were deployed on the JBoss instance, it was quickly found which application went wrong. One of the applications was giving the following exception:

Caused by: java.lang.NoSuchMethodError: org.apache.commons.httpclient.methods.PostMethod.getParams()Lorg/apache/commons/httpclient/params/HttpMethodParams;
at net.pascalalma.components.sms.SmsServiceBean.postSmsRequest(SmsServiceBean.java:220)
at net.pascalalma.components.sms.SmsServiceBean.sendSms(SmsServiceBean.java:127)
at net.pascalalma.components.sms.SmsServiceBean.sendSms(SmsServiceBean.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)

After some further investigation I found out that the problem was caused by the commons-httpclient.jar. The application needs to use tthe version 3.0.1 while the JBoss is supplied with version 2.0 (it's in the JBOSS_HOME/lib/ directory). So instead of setting the isolation level at JBoss instance level I tried to set this 'property' at application level by supplying a 'jboss-app.xml' with the .ear file of the application. The content of the 'jboss-app.xml' is:

PLAIN TEXT
XML:
1. <jboss-app>
2.   <loader-repository>
3.   net.pascalalma.appl:archive=my-app.ear
4.      <loader-repository-config>
5.      java2ParentDelegation=false
6.      </loader-repository-config>
7.   </loader-repository>
8. </jboss-app>

After testing this configuration the application worked fine, but I ran into another issue....
We are building and packaging our application with Maven2. To generate the ear-file, we use this maven-ear plugin. I found out that the plugin offers the possibility to generate the necessary 'jboss-app.xml' file by configuring the plugin in the corresponding pom file like this:

PLAIN TEXT
XML:
1. <project>
2.   ...
3.   ...
4.   <build>
5.     <plugins>
6.        <plugin>
7.           <groupId>org.codehaus.mojo</groupId>
8.           <artifactId>jboss-maven-plugin</artifactId>
9.           <configuration>
10.                   <jbossHome>${jboss.home}</jbossHome>
11.                   <serverName>default</serverName>
12.                   <port>8080</port>
13.           </configuration>
14.        </plugin>
15.        <plugin>
16.           <artifactId>maven-ear-plugin</artifactId>
17.           <configuration>
18.              <displayName>My Application</displayName>
19.              <description>My apliation using HttpClient3.0.1</description>
20.              <version>2.3.1</version>
21.              <modules>
22.                 <ejbModule>
23.                    <groupId>net.pascalalma</groupId>
24.                    <artifactId>
25.                       my-ejb-app
26.                    </artifactId>
27.                 </ejbModule>
28.                 <webModule>
29.                    <groupId>net.pascalalma</groupId>
30.                    <artifactId>
31.                       my-web-app
32.                    </artifactId>
33.                    <contextRoot>/my-app</contextRoot>
34.                 </webModule>
35.              </modules>
36.              <jboss>
37.                 <version>4</version>
38.                 <loader-repository>
39.                   net.pascalalma.appl:archive=my-app.ear
40.                 </loader-repository>
41.                 <loader-repository-config>java2ParentDelegation=false</loader-repository-config>
42.              </jboss>
43.              <archive>
44.                 <manifest>
45.                    <addClasspath>true</addClasspath>
46.                 </manifest>
47.              </archive>
48.           </configuration>
49.        </plugin>
50.     </plugins>
51.   </build>
52. </project>

Unfortunately, the plugin ignores the tag 'loader-repository-config' in the pom file. So this setting is not added to the 'jboss-app.xml' while this is the most important setting in our case! So for now I add the correct file by hand, but if someone knows a nice way to do this, I am very eager to hear it.

]]> http://blog.redstream.nl/2008/01/29/classloader-issue-with-jboss-405ga/feed/ 0 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 http://blog.redstream.nl/2007/11/24/a-time-consuming-annoyance-with-maven/ http://blog.redstream.nl/2007/11/24/a-time-consuming-annoyance-with-maven/#comments Sat, 24 Nov 2007 18:43:08 +0000 Pascal Alma http://www.pascalalma.net/2007/11/24/a-time-consuming-annoyance-with-maven/ As you might have noticed in my earlier posts I am currently using Maven2 for building and deploying our applications. And although I am a big fan of it and I see a lot of advantages in using it, I sometimes would like to throw my PC out of the window because it is driving me crazy. Of course, at the end, it appears to be my own fault that causes the problem but anyway :-)
Last issue that drove me mad was when I packaged my application in an ear file, consisting of one ejb3 module and one web module. I had done it several times before and this was just another one, so I thought. But after deploying my ear file in JBoss it started to complain that the EJB module couldn't find some classes in the supplied jars.
Here is (a part of) the pom for the ejb module:
PLAIN TEXT
XML:
1. <?xml version="1.0" encoding="UTF-8"?>
2. <project>
3.     <parent>
4.          <artifactId>my-application-ejb</artifactId>
5.          <groupId>net.pascalalma</groupId>
6.          <version>1.0.0</version>
7.     </parent>
8.     <modelVersion>4.0.0</modelVersion>
9.     <groupId>net.pascalalma</groupId>
10.     <artifactId>my-application-ejb</artifactId>
11.     <version>1.0.0</version>
12.     <build>
13.          <sourceDirectory>src/main</sourceDirectory>
14.          <finalName>my-application-ejb</finalName>
15.          <plugins>
16.               <plugin>
17.                    <artifactId>maven-compiler-plugin</artifactId>
18.                    <configuration>
19.                         <source>1.5</source>
20.                         <target>1.5</target>
21.                    </configuration>
22.               </plugin>
23.               <plugin>
24.                    <artifactId>maven-ejb-plugin</artifactId>
25.                    <configuration>
26.                         <ejbVersion>3.0</ejbVersion>
27.                         <archive>
28.                              <manifest>
29.                                   <addClasspath>true</addClasspath>
30.                              </manifest>
31.                         </archive>
32.                    </configuration>
33.               </plugin>
34.               <plugin>
35.                    <artifactId>maven-javadoc-plugin</artifactId>
36.                    <configuration>
37.                         <classpath>/src/main/java</classpath>
38.                    </configuration>
39.               </plugin>
40.          </plugins>
41.     </build>
42.     <dependencies>
43.          <dependency>
44.               <groupId>javax.persistence</groupId>
45.               <artifactId>persistence-api</artifactId>
46.               <scope>provided</scope>
47.               <version>1.0</version>
48.          </dependency>
49.          <dependency>
50.               <groupId>javax.ejb</groupId>
51.               <artifactId>ejb-api</artifactId>
52.               <scope>provided</scope>
53.               <version>3.0</version>
54.          </dependency>
55.          ...
56.  
57.          ...
58.          <dependency>
59.               <groupId>net.pascalalma.components</groupId>
60.               <artifactId>net.pascalalma-components-sms-ejb</artifactId>
61.               <version>1.0.0</version>
62.          </dependency>
63.          ...
64.          ...
65.     </dependencies>
66. </project>

And this is what I had in the pom for the ear module:

PLAIN TEXT
XML:
1. <project>
2.     <parent>
3.          <artifactId>my-application</artifactId>
4.          <groupId>net.pascalalma</groupId>
5.          <version>1.0.0</version>
6.     </parent>
7.     <modelVersion>4.0.0</modelVersion>
8.     <groupId>net.pascalalma</groupId>
9.     <artifactId>my-application-ear</artifactId>
10.     <packaging>ear</packaging>
11.     <version>1.0.0</version>
12.     <dependencies>
13.          <dependency>
14.               <groupId>net.pascalalma</groupId>
15.               <artifactId>my-application-ejb</artifactId>
16.               <version>1.0.0</version>
17.               <type>ejb</type>
18.          </dependency>
19.          ...
20.  
21.          ...
22.          <dependency>
23.               <groupId>commons-lang</groupId>
24.               <artifactId>commons-lang</artifactId>
25.               <version>2.3</version>
26.          </dependency>
27.     </dependencies>
28.     <build>
29.          <plugins>
30.               <plugin>
31.                    <groupId>org.codehaus.mojo</groupId>
32.                    <artifactId>jboss-maven-plugin</artifactId>
33.                    <configuration>
34.                         <jbossHome>${jboss.home}</jbossHome>
35.                         <serverName>default</serverName>
36.                         <port>8080</port>
37.                    </configuration>
38.               </plugin>
39.               <plugin>
40.                    <artifactId>maven-ear-plugin</artifactId>
41.                    <configuration>
42.                         <displayName>My Application</displayName>
43.                         <description>My Application</description>
44.                         <version>1.4</version>
45.                         <modules>
46.                              <ejbModule>
47.                                   <groupId>net.pascalalma</groupId>
48.                                   <artifactId>
49.                                        my-application-ejb
50.                                   </artifactId>
51.                              </ejbModule>
52.                              ...
53.                         </modules>
54.                         <archive>
55.                              <manifest>
56.                                   <addClasspath>true</addClasspath>
57.                              </manifest>
58.                         </archive>
59.                    </configuration>
60.               </plugin>
61.          </plugins>
62.     </build>
63. </project>

When running 'mvn clean package' this configuration built the ear file with the following content:

-----------------
commons-lang-2.3.jar
my-application-ejb-1.0.0.jar
my-application-web-1.0.0.war
META-INF

And the META-INF contains a MANIFEST.MF that reads:

Manifest-Version: 1.0
Archiver-Version: Plexus Archiver
Created-By: Apache Maven
Built-By: pascalalma
Build-Jdk: 1.5.0_09
Class-Path: commons-lang-2.3.jar my-application-ejb-1.0.0.jar

But still got several ClassNotFound exception when I deployed the ear-file to JBoss.

Well, it took some hours (!) looking at the ejb-plugin and the construction of 'MANIFEST.MF' and all kind of other possibilities that could go wrong before I noticed a slight difference in the pom of former EJB modules and this one. I had forgotten to set the packaging of the module to EJB. So I added

<packaging>ejb</packaging>

to the EJB module pom.
After building and deploying this new ear file it worked like a charm. While I was checking what made the difference I realized I had been looking to the MANIFEST.MF of the 'ear' file instead of the manifest of the EJB jar file..... And this manifest file only gets filled in case the packaging is set to EJB and not to the default 'jar'.
So you see, it was my mistake but I just wish I realized it a little bit quicker :-)

]]> http://blog.redstream.nl/2007/11/24/a-time-consuming-annoyance-with-maven/feed/ 0