redstream » GlassFish http://www.redstream.nl Pragmatic Integrators Fri, 27 Jan 2012 19:31:59 +0000 en hourly 1 ‘Hello World’ with Glassfish, Metro and Maven http://www.redstream.nl/2009/03/09/hello-world-with-glassfish-metro-and-maven/ http://www.redstream.nl/2009/03/09/hello-world-with-glassfish-metro-and-maven/#comments Mon, 09 Mar 2009 11:47:44 +0000 Pascal Alma http://www.pascalalma.net/?p=576 Continue reading →]]>

As might be clear by my latest posts I am currently working on a project where we use Glassfish and EJB3 as platform for our JEE application. One thing that we had to decide upon was the WebService framework we were going to use. There are quite some options available but I decided to have a look at Metro, the JAX-WS reference implementation. Also due to the fact that it is integrated with EJB3 and Glassfish.
To create my ‘HelloWorld’ service with Metro and Maven2 I used this post as a guideline. I am also going to work top-down (WSDL -> Java approach) so I will be starting with an existing WSDL and then generate/create the web service interface for that. Although the post I used as a guideline is very detailed I ran into some issues, mostly the result of using different versions of dependencies and plugins. In this post I show the steps I made to get it working. I am using Glassfish-v2ur2 (comes with Netbeans 6.5) , JDK1.5 and Maven 2.0.9.

  1. Create the Maven2 project

    2. Issue the command: mvn archetype:create -DgroupId=net.pascalalma.ws -DartifactId=echo-service
    This results in a standard Maven project. I removed the generated java files since we don’t need them.

  2. Setup the pom

    3. The default pom that was created in the first step has to be modified. I added several things which I explain next:

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

    <dependencies>
        ...
        <dependency>
            <groupId>com.sun.xml.ws</groupId>
            <artifactId>jaxws-rt</artifactId>
            <version>2.1.4</version>
        </dependency>
        <dependency>
            <groupId>javax.jws</groupId>
            <artifactId>jsr181-api</artifactId>
            <version>1.0-MR1</version>
        </dependency>
    ...
    </dependencies>

    These are dependencies that are used by the JAXWS plugin, which is used to generate the Webservice interface based on the supplied WSDL.

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

       <dependencies>
   ...
        <dependency>
            <groupId>glassfish</groupId>
            <artifactId>appserv-rt.jar</artifactId>
            <version>LATEST</version>
            <scope>system</scope>
            <systemPath>${glassfish.home}/lib/appserv-rt.jar</systemPath>
        </dependency>
        <dependency>
            <groupId>glassfish</groupId>
            <artifactId>javaee.jar</artifactId>
            <version>LATEST</version>
            <scope>system</scope>
            <systemPath>${glassfish.home}/lib/javaee.jar</systemPath>
        </dependency>
   ...
   </dependencies>

    These dependencies are used to compile the generated code and the WebService implementation class.

    Next there are some plugins to be configured:

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

        <build>
        <plugins>
        ...
            <!-- Plugin to generate JAXB classes and webservice interface -->
            <plugin>
                <groupId>org.codehaus.mojo</groupId>
                <artifactId>jaxws-maven-plugin</artifactId>
                <version>1.10</version>
                <executions>
                    <execution>
                        <goals>
                            <goal>wsimport</goal>
                        </goals>
                    </execution>
                </executions>
                <configuration>
                    <wsdlDirectory>
                        src/main/resources/wsdl
                    </wsdlDirectory>
                    <sourceDestDir>
                        ${basedir}/generated/src/main/java
                    </sourceDestDir>
                </configuration>
                <dependencies>
                    <dependency>
                        <groupId>javax.jws</groupId>
                        <artifactId>jsr181-api</artifactId>
                        <version>1.0-MR1</version>
                    </dependency>
                </dependencies>
            </plugin>
            ...
        </plugins>
    </build>

    This plugin is used for the actual generation of the Java code. It will put the code in the ‘generated’ folder.
    The next two plugins are used for compiling and cleaning the code. I have described the use of these plugins here.

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

     <build>
        <plugins>
        ...
            <!-- Plugin to add delete path to build cycle -->
            <plugin>
                <artifactId>maven-clean-plugin</artifactId>
                <version>2.2</version>
                <configuration>
                    <filesets>
                        <fileset>
                            <directory>generated/src/main/java</directory>
                            <includes>
                                <include>**/*.java</include>
                            </includes>
                        </fileset>
                    </filesets>
                </configuration>
            </plugin>
        </plugins>
    </build>
    ...
  </plugins>
</build>

    And finally I add the necessary code to tell the compiler JDK 1.5 has to be used:

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

     <build>
        <plugins>
        ...
             <!-- plugin to compile Java1.5 code -->
             <plugin>
                <groupId>org.apache.maven.plugins</groupId>
                <artifactId>maven-compiler-plugin</artifactId>
                <version>2.0.2</version>
                <configuration>
                    <source>1.5</source>
                    <target>1.5</target>
                </configuration>
            </plugin>
        ...
       </plugins>
  </build>

    The complete pom.xml can be found here.

  3. Create the WSDL

    4. As shown in the plugin configuration I have added a WSDL file to a ‘wsdl’ folder in the ‘resource’ folder. The WSDL looks like this:

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

    <?xml version="1.0" encoding="UTF-8"?>
<wsdl:definitions name="DoubleIt"
   xmlns:xsd="http://www.w3.org/2001/XMLSchema"
   xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/"
   xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/"
   xmlns:tns="http://www.redstream.nl/EchoIt"
   xmlns:types="http://www.redstream.nl/EchoIt/types"
   targetNamespace="http://www.redstream.nl/EchoIt">
    <wsdl:types>
        <xsd:schema targetNamespace="http://www.redstream.nl/EchoIt/types">
            <xsd:element name="EchoIt">
                <xsd:complexType>
                    <xsd:sequence>
                        <xsd:element name="textToEcho" type="xsd:string"/>
                    </xsd:sequence>
                </xsd:complexType>
            </xsd:element>
            <xsd:element name="EchoItResponse">
                <xsd:complexType>
                    <xsd:sequence>
                        <xsd:element name="echoedText" type="xsd:string" />
                    </xsd:sequence>
                </xsd:complexType>
            </xsd:element>
        </xsd:schema>
    </wsdl:types>
    <wsdl:message name="EchoItRequest">
        <wsdl:part element="types:EchoIt" name="parameters" />
    </wsdl:message>
    <wsdl:message name="EchoItResponse">
        <wsdl:part element="types:EchoItResponse" name="parameters" />
    </wsdl:message>
    <wsdl:portType name="EchoItPortType">
        <wsdl:operation name="EchoIt">
            <wsdl:input message="tns:EchoItRequest" />
            <wsdl:output message="tns:EchoItResponse" />
        </wsdl:operation>
    </wsdl:portType>
    <wsdl:binding name="EchoItBinding" type="tns:EchoItPortType">
        <soap:binding style="document"
         transport="http://schemas.xmlsoap.org/soap/http" />
        <wsdl:operation name="EchoIt">
            <soap:operation soapAction=""/>
            <wsdl:input>
                <soap:body use="literal"/>
            </wsdl:input>
            <wsdl:output>
                <soap:body use="literal"/>
            </wsdl:output>
        </wsdl:operation>
    </wsdl:binding>
    <wsdl:service name="EchoItService">
        <wsdl:port name="EchoItPort" binding="tns:EchoItBinding">
            <soap:address
            location="http://localhost:8080/echoit/echoit"/>
        </wsdl:port>
    </wsdl:service>
</wsdl:definitions>
  4. Generate the code

    5. When all this is in place we can generate the Java code by simply issue the command:
    mvn clean install
    In Netbeans we can see the generated code in our project browser:

  5. Create Web Service implementation

    6. Next step is to create the implementation class for the web service. Please note that I will create a EJB Web Service endpoint. This way I don’t need a web container nor any web deployment descriptor.
    Here is the web service implementation:

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

    package net.pascalalma.ws;
 
import javax.ejb.Stateless;
import javax.jws.WebService;
 
/**
 * Hello world!
 *
 */
@WebService(targetNamespace = "http://www.redstream.nl/EchoIt",
            portName="EchoItPort",
            serviceName="EchoItService",
            endpointInterface="nl.redstream.echoit.EchoItPortType")
@Stateless
public class EchoServiceImpl
{
    public String echoIt(String it)
    {
        return "Echo " + it +"!";
    }
}
  6. Deploy it to Glassfish

    7. With the implementation in place rebuild the project so a ejb-jar is created. Again issue the command:
    mvn clean install
    The created jar file in the ‘target’ directory can then be deployed to Glassfish. This can be done by using a Maven plugin as described here or by using the Glassfish Admin Console. I used the last one in this case. It should look similar to this after successful deployment:

  7. Test the service

    8. The easiest way to test it is, if you already have the Glassfish Admin Console open, to click the ‘test’ button and fill in a text as input parameter. As result you should get something like:

Well, if you did the things as I described you have a big chance it will work in one time, but in my case there were some problems when trying to get this to work. Some of the Issues I ran into while building the projects:

  1. Missing dependencies

    2. Missing:
    ———-
    1) com.sun.xml.ws:jaxws-tools:jar:2.1.5

    I had to use another plugin version then the one that is recommended at the plugin homepage:

    1
2
3
4
5
6

     <plugin>
                <groupId>org.codehaus.mojo</groupId>
                <artifactId>jaxws-maven-plugin</artifactId>
                <version>1.10</version>
     ...
   </plugin>
  2. More missing libraries

    3. I then ran into this one:

    org.apache.maven.lifecycle.LifecycleExecutionException: Error executing: wsimport [-s, /Users/pascal/projects/metro-service/echo-service/target/generated, -d, /Users/pascal/projects/metro-service/echo-service/target/classes, /Users/pascal/projects/metro-service/echo-service/src/main/webapp/WEB-INF/wsdl/echo-it.wsdl]
    …

    See also this thread.

    It appears it has something to do with JDK1.5 instead of JDK1.6. I solved it by adding the dependencies for the JSR181.

I hope that this posts avoids the exceptions which I encountered and make the use of JAXWS with Maven more smoothly because in the end it is a very nice solution!

]]> http://www.redstream.nl/2009/03/09/hello-world-with-glassfish-metro-and-maven/feed/ 4 Using OpenEJB for EJB3 testing with Maven2 http://www.redstream.nl/2009/02/20/using-openejb-for-ejb3-testing-with-maven2/ http://www.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 Continue reading →]]>

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

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

    ...
    <dependencies>
        <!-- Libraries necessary for compiling -->
        <dependency>
            <groupId>glassfish</groupId>
            <artifactId>appserv-rt.jar</artifactId>
            <version>LATEST</version>
            <scope>system</scope>
            <systemPath>${glassfish.home}/lib/appserv-rt.jar</systemPath>
        </dependency>
        <dependency>
            <groupId>glassfish</groupId>
            <artifactId>javaee.jar</artifactId>
            <version>LATEST</version>
            <scope>system</scope>
            <systemPath>${glassfish.home}/lib/javaee.jar</systemPath>
        </dependency>
    </dependencies>
    <build>
        <resources>
            <resource>
                <!-- Use filtering so the property values are written to persistnece.xml
                     based on the selected profile (develop or test) -->
                <directory>src/main/resources</directory>
                <filtering>true</filtering>
            </resource>
        </resources>
    </build>
...

    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:

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

    <persistence version="1.0" xmlns="http://java.sun.com/xml/ns/persistence">
  <persistence-unit name="MyPersistenceUnit" transaction-type="JTA">
    <provider>org.hibernate.ejb.HibernatePersistence</provider>
    <jta-data-source>jdbc/MyDS</jta-data-source>
    <properties>
      <property name="hibernate.cache.provider_class" value="org.hibernate.cache.NoCacheProvider"/>
      <property name="hibernate.transaction.manager_lookup_class" value="org.apache.openejb.hibernate.TransactionManagerLookup"/>
      <property name="hibernate.show_sql" value="${hibernate.show_sql}"/>
      <property name="hibernate.hbm2ddl.auto" value="${hibernate.hbm2ddl.auto}"/>
    </properties>
  </persistence-unit>
</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):

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

    ...
    <dependencies>
        ...
        <!-- libraries necessary for testing -->
        <dependency>
            <groupId>org.apache.openejb</groupId>
            <artifactId>openejb-core</artifactId>
            <version>3.1</version>
            <scope>test</scope>
        </dependency>
        <dependency>
            <groupId>org.hibernate</groupId>
            <artifactId>hibernate-entitymanager</artifactId>
            <version>3.4.0.GA</version>
            <scope>test</scope>
        </dependency>
        <dependency>
    ...
    </dependencies>
    <build>
        <plugins>
            <plugin>
                <groupId>org.apache.maven.plugins</groupId>
                <artifactId>maven-ejb-plugin</artifactId>
                <configuration>
                    <generateClient>false</generateClient>
                    <ejbVersion>3.0</ejbVersion>
                </configuration>
            </plugin>
        </plugins>
        <finalName>my-services</finalName>
    </build>
...

    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:

    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:

    1
2
3
4

     ...
 @EJB
 private CustomerServiceLocal cs;
 ...

    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.

    1
2
3
4
5

      ...
  ots = (CustomerBusinessServiceRemote) context.lookup("CustomerBusinessServiceRemote");
  assert ots != null;
  ots.validateCustomer("1");
  ..
  • 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:

1
2
3
4

@WebService
@SOAPBinding(style = javax.jws.soap.SOAPBinding.Style.DOCUMENT
            ,use = javax.jws.soap.SOAPBinding.Use.LITERAL
            ,parameterStyle = javax.jws.soap.SOAPBinding.ParameterStyle.WRAPPED)

and this to the class:

1
2

@WebService( endpointInterface = "net.pascalalma.mybusinessservices.CustomerBusinessServiceRemote"
           , 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://www.redstream.nl/2009/02/20/using-openejb-for-ejb3-testing-with-maven2/feed/ 12 Create a EJB3 WebService with Maven2 running on Glassfish http://www.redstream.nl/2009/02/11/create-a-ejb3-webservice-with-maven2-running-on-glassfish/ http://www.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 Continue reading →]]>

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:

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

<settings>
<profiles>
  <profile>
      <id>develop</id>
      <properties>
        <glassfish.home>/Applications/NetBeans/glassfish-v2ur2</glassfish.home>
         <hibernate.show_sql>true</hibernate.show_sql>
      </properties>
      <pluginRepositories>
        <pluginRepository>
            <id>maven.java.net</id>
            <name>Java.net Maven2 Repository</name>
            <url>http://download.java.net/maven/2</url>
        </pluginRepository>
      </pluginRepositories>
  </profile>
  </profiles>
  <activeProfiles>
    <activeProfile>develop</activeProfile>
  </activeProfiles>
</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:

1
2
3
4
5
6
7
8
9

package net.pascalalma.services;
 
import javax.ejb.Remote;
 
@Remote
public interface EchoService {
 
    public String sayHello(String subject);
}

and its implementation:

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

package net.pascalalma.services.impl;
 
import javax.ejb.Stateless;
import net.pascalalma.services.EchoService;
 
@Stateless
public class EchoServiceBean implements EchoService {
 
    public String sayHello(String name) {
        return "Hi " + name + "!";
    }
}

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

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

<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">
    <modelVersion>4.0.0</modelVersion>
    <groupId>net.pascalalma</groupId>
    <artifactId>my-ejb-project</artifactId>
    <packaging>ejb</packaging>
    <version>1.0-SNAPSHOT</version>
    <name>my-ejb-project</name>
    <url>http://www.redstream.nl</url>
    <dependencies>
        <dependency>
            <groupId>glassfish</groupId>
            <artifactId>appserv-rt.jar</artifactId>
            <version>LATEST</version>
            <scope>system</scope>
            <systemPath>${glassfish.home}/lib/appserv-rt.jar</systemPath>
        </dependency>
        <dependency>
            <groupId>glassfish</groupId>
            <artifactId>javaee.jar</artifactId>
            <version>LATEST</version>
            <scope>system</scope>
            <systemPath>${glassfish.home}/lib/javaee.jar</systemPath>
        </dependency>
        <dependency>
            <groupId>junit</groupId>
            <artifactId>junit</artifactId>
            <version>4.1</version>
            <scope>test</scope>
        </dependency>
    </dependencies>
    <build>
        <sourceDirectory>src/main/java</sourceDirectory>
        <finalName>my-ejb-project</finalName>
        <plugins>
            <plugin>
                <groupId>org.apache.maven.plugins</groupId>
                <artifactId>maven-compiler-plugin</artifactId>
                <configuration>
                    <source>1.5</source>
                    <target>1.5</target>
                </configuration>
            </plugin>
            <plugin>
                <groupId>org.apache.maven.plugins</groupId>
                <artifactId>maven-ejb-plugin</artifactId>
                <configuration>
                    <ejbVersion>3.0</ejbVersion>
                </configuration>
            </plugin>
        </plugins>
    </build>
</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):

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

<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">
  <modelVersion>4.0.0</modelVersion>
  <groupId>net.pascalalma</groupId>
  <artifactId>my-ear-project</artifactId>
  <packaging>ear</packaging>
  <version>1.0-SNAPSHOT</version>
  <name>my-ear-project</name>
  <url>http://maven.apache.org</url>
    <dependencies>
        <dependency>
            <groupId>net.pascalalma</groupId>
            <artifactId>my-ejb-project</artifactId>
            <version>1.0-SNAPSHOT</version>
            <type>ejb</type>
        </dependency>
    </dependencies>
    <build>
        <plugins>
            <plugin>
                <artifactId>maven-ear-plugin</artifactId>
                <configuration>
                    <displayName>My Service</displayName>
                    <description>My EJB Component for Echo Service</description>
                    <version>1.4</version>
                    <modules>
                        <ejbModule>
                            <groupId>net.pascalalma</groupId>
                            <artifactId>my-ejb-project</artifactId>
                        </ejbModule>
                    </modules>
                </configuration>
            </plugin>
            <plugin>
                <groupId>org.glassfish.maven.plugin</groupId>
                <artifactId>maven-glassfish-plugin</artifactId>
                <version>2.1</version>
 
                <configuration>
                    <glassfishDirectory>${glassfish.home}</glassfishDirectory>
                    <user>admin</user>
                    <passwordFile>${glassfish.home}/domains/domain1/config/domain-passwords</passwordFile>
                    <autoCreate>false</autoCreate>
                    <debug>true</debug>
                    <echo>true</echo>
                    <terse>false</terse>
                    <domain>
                        <name>domain1</name>
                        <httpPort>8080</httpPort>
                        <adminPort>4848</adminPort>
                        <reuse>true</reuse>
                    </domain>
                    <components>
                        <component>
                            <name>${project.artifactId}</name>
                            <artifact>${project.build.directory}/${project.build.finalName}.ear</artifact>
                        </component>
                    </components>
                </configuration>
            </plugin>
        </plugins>
    </build>
</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:

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

package net.pascalalma.services;
 
import javax.ejb.Remote;
import javax.jws.WebService;
import javax.jws.soap.SOAPBinding;
 
@Remote
@WebService
@SOAPBinding(style = javax.jws.soap.SOAPBinding.Style.DOCUMENT
            ,use = javax.jws.soap.SOAPBinding.Use.LITERAL
            ,parameterStyle = javax.jws.soap.SOAPBinding.ParameterStyle.WRAPPED)
public interface EchoService {
 
    public String sayHello(String subject);
}

and the implementation class:

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

package net.pascalalma.services.impl;
 
import javax.ejb.Stateless;
import javax.jws.WebService;
import net.pascalalma.services.EchoService;
 
@Stateless
@WebService(endpointInterface = "net.pascalalma.services.EchoService",serviceName="EchoService")
public class EchoServiceBean implements EchoService {
 
    public String sayHello(String name) {
        return "Hi " + name + "!";
    }
}

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://www.redstream.nl/2009/02/11/create-a-ejb3-webservice-with-maven2-running-on-glassfish/feed/ 6