ejb-throws-exception: Handle Exceptions across JARs in an EAR

The ejb-throws-exception quickstart demonstrates how to throw and handle exceptions across JARs in an EAR.

What is it?

The ejb-throws-exception quickstart demonstrates how to handle exceptions across JARs in an EAR deployed to WildFly Application Server. In this quickstart, an EJB in the EJB JAR throws a custom exception. The web application in the client JAR catches the exception and displays it in a nicely formatted message. The EAR contains: JSF WAR, an EJB JAR and a client library JAR containg classes that both the WAR and EJB JAR use.

This example consists of the following Maven projects, each with a shared parent.

Project Description

Project	Description
`ejb`	This project contains the EJB code and can be built independently to produce the JAR archive. The EJB has a single method `sayHello` which will take in a String `name`. If the `name` is not null or an empty String, it returns `Hello <name>`. If the `name` is null or an empty String, it throws a custom `GreeterException` exception back to the client.
`web`	This project contains the JSF pages and the CDI managed bean. The CDI Managed Bean, `GreeterBean`, is bound to the JSF page, `index.xhtml`. It invokes the `GreeterEJB` and displays the response back from the EJB. The `GreeterBean` catches the custom `GreeterException` exception thrown by `GreeterEJB` and displays the exception message in the response text on the JSF page.
`ear`	This project builds the EAR artifact and pulls in the ejb, web, and client artifacts.
`ejb-api`	This project builds the ejb-api library artifact which is used by the ejb, web, as well as remote client artifacts. This directory contains the EJB interfaces, custom exceptions the EJB throws and any other transfer objects which the EJB may receive or send back to the client. The EJB interfaces, custom exceptions, and other transfer objects are split into a separate JAR, which is packaged in the ear/lib. This allows all sub deployments of the EAR to see the classes of the ejb-api JAR in the classpath. This is also useful for remote clients. The ejb-api JAR can be distributed to a remote client and give the remote clients the classes that are needed to interact with the EJB.

ejb

This project contains the EJB code and can be built independently to produce the JAR archive.

The EJB has a single method sayHello which will take in a String name.
If the name is not null or an empty String, it returns Hello <name>.
If the name is null or an empty String, it throws a custom GreeterException exception back to the client.

web

This project contains the JSF pages and the CDI managed bean.

The CDI Managed Bean, GreeterBean, is bound to the JSF page, index.xhtml.
It invokes the GreeterEJB and displays the response back from the EJB.
The GreeterBean catches the custom GreeterException exception thrown by GreeterEJB and displays the exception message in the response text on the JSF page.

ear

This project builds the EAR artifact and pulls in the ejb, web, and client artifacts.

ejb-api

This project builds the ejb-api library artifact which is used by the ejb, web, as well as remote client artifacts.

This directory contains the EJB interfaces, custom exceptions the EJB throws and any other transfer objects which the EJB may receive or send back to the client.
The EJB interfaces, custom exceptions, and other transfer objects are split into a separate JAR, which is packaged in the ear/lib. This allows all sub deployments of the EAR to see the classes of the ejb-api JAR in the classpath. This is also useful for remote clients.
The ejb-api JAR can be distributed to a remote client and give the remote clients the classes that are needed to interact with the EJB.

The root pom.xml builds each of the subprojects in the above order and deploys the EAR archive to the server.

The example follows the common "Hello World" pattern, using the following workflow.

A JSF page asks for a user name.
On clicking Say Hello, the value of the Name input text is sent to a managed bean named GreeterBean.
On setting the name, the Greeter invokes the GreeterEJB, which was injected to the managed bean. Notice that the field is annotated with @EJB.
The EJB responds with Hello <name> or throws an exception if the name is empty or null.
The response or exception’s message from invoking the GreeterEJB is stored in a field (response) of the managed bean.
The managed bean is annotated as @RequestScoped, so the same managed bean instance is used only for the request/response.

Browse the source

System Requirements

The application this project produces is designed to be run on WildFly Application Server 33 or later.

All you need to build this project is Java 11.0 (Java SDK 11) or later and Maven 3.6.0 or later. See Configure Maven to Build and Deploy the Quickstarts to make sure you are configured correctly for testing the quickstarts.

Use of the WILDFLY_HOME and QUICKSTART_HOME Variables

In the following instructions, replace WILDFLY_HOME with the actual path to your WildFly installation. The installation path is described in detail here: Use of WILDFLY_HOME and JBOSS_HOME Variables.

When you see the replaceable variable QUICKSTART_HOME, replace it with the path to the root directory of all of the quickstarts.

Start the WildFly Standalone Server

Open a terminal and navigate to the root of the WildFly directory.
Start the WildFly server with the default profile by typing the following command.
```
$ WILDFLY_HOME/bin/standalone.sh 
```
Note
For Windows, use the WILDFLY_HOME\bin\standalone.bat script.

Build and Deploy the Quickstart

Make sure WildFly server is started.
Open a terminal and navigate to the root directory of this quickstart.
Type the following command to build the quickstart.
```
$ mvn clean install
```
Type the following command to deploy the quickstart.
```
$ mvn wildfly:deploy
```

This deploys the ejb-throws-exception/ear/target/ejb-throws-exception.ear to the running instance of the server.

You should see a message in the server log indicating that the archive deployed successfully.

Access the Application

The application will be running at the following URL http://localhost:8080/ejb-throws-exception-web.

Enter a name in the input field Name and click the Say Hello button to see the response.

The Response output text will display the response from the EJB. If the Name input text box is not empty, then the Response output text will display Hello <name> If the Name input text box is empty, then the Response output text will display the message of the exception throw back from the EJB.

Run the Integration Tests

This quickstart includes integration tests, which are located under the src/test/ directory. The integration tests verify that the quickstart runs correctly when deployed on the server.

Follow these steps to run the integration tests.

Make sure WildFly server is started.
Make sure the quickstart is deployed.
Type the following command to run the verify goal with the integration-testing profile activated.
```
$ mvn verify -Pintegration-testing 
```

Undeploy the Quickstart

When you are finished testing the quickstart, follow these steps to undeploy the archive.

Make sure WildFly server is started.
Open a terminal and navigate to the root directory of this quickstart.
Type this command to undeploy the archive:
```
$ mvn wildfly:undeploy
```

Building and running the quickstart application with provisioned WildFly server

Instead of using a standard WildFly server distribution, you can alternatively provision a WildFly server to deploy and run the quickstart, by activating the Maven profile named provisioned-server when building the quickstart:

$ mvn clean install -Pprovisioned-server

The provisioned WildFly server, with the quickstart deployed, can then be found in the ear/target/server directory, and its usage is similar to a standard server distribution, with the simplification that there is never the need to specify the server configuration to be started.

The server provisioning functionality is provided by the WildFly Maven Plugin, and you may find its configuration in the quickstart pom.xml:

        <profile>
            <id>provisioned-server</id>
            <build>
                <plugins>
                    <plugin>
                        <groupId>org.wildfly.plugins</groupId>
                        <artifactId>wildfly-maven-plugin</artifactId>
                        <configuration>
                            <discover-provisioning-info>
                                <version>${version.server}</version>
                            </discover-provisioning-info>
                            <!--
                                Rename the output war to ROOT.war before adding it to the server, so that the
                                application is deployed in the root web context.
                            -->
                            <name>ROOT.war</name>
                            <add-ons>...</add-ons>
                        </configuration>
                        <executions>
                            <execution>
                                <goals>
                                    <goal>package</goal>
                                </goals>
                            </execution>
                        </executions>
                    </plugin>
                    ...
                </plugins>
            </build>
        </profile>

The plugin uses WildFly Glow to discover the feature packs and layers required to run the application, and provisions a server containing those layers.

If you get an error or the server is missing some functionality which cannot be auto-discovered, you can download the WildFly Glow CLI and run the following command to see more information about what add-ons are available:

wildfly-glow show-add-ons

Note	Since the plugin configuration above deploys quickstart on root web context of the provisioned server, the URL to access the application should not have the `/ejb-throws-exception` path segment after `HOST:PORT`.

Run the Integration Tests with a provisioned server

The integration tests included with this quickstart, which verify that the quickstart runs correctly, may also be run with a provisioned server.

Follow these steps to run the integration tests.

Make sure the server is provisioned.

$ mvn clean install -Pprovisioned-server

Start the WildFly provisioned server, this time using the WildFly Maven Plugin, which is recommended for testing due to simpler automation. The path to the provisioned server should be specified using the jbossHome system property.
```
$ mvn -f ear/pom.xml wildfly:start -DjbossHome=ear/target/server 
```
Type the following command to run the verify goal with the integration-testing profile activated, and specifying the quickstart’s URL using the server.host system property, which for a provisioned server by default is http://localhost:8080.
```
$ mvn verify -Pintegration-testing -Dserver.host=http://localhost:8080 
```
Shutdown the WildFly provisioned server, this time using the WildFly Maven Plugin too.
```
$ mvn -f ear/pom.xml wildfly:shutdown
```

WildFly for OpenShift Incompatibility

This quickstart is not compatible with WildFly for OpenShift.