Each component of the Java EE application will be developed as as a separate Maven module. Each module will be placed in a flat structure under a common parent project. This parent project will be used to coordinate goals involved of the entire application. The order in which it builds things can be influenced by the configuration you supply, however, maven will analyze dependencies at build time and either honor the actual dependency ordering or fail if you have expressed a circular dependency.
Create a root directory for the exercise. This will host the root project and sub-projects for the Impl, EJB, WAR, EAR, and RMI Test modules.
$ mkdir ejb-basichotel
Create a root project pom.xml file. This project will will not have an associated artifact and is termed a "parent" (simple term) or "reactor" (techy term) project. It uses a special packaging type called "pom".
This project will also be used as a parent project of all implementation modules so we can define re-usable definitions. Note that the definitions within this project are passive. They will not actively add any dependencies or plugins to inheriting child modules unless the child specifically references the defined artifact. Details for the potentially used artifact can be placed here (and consistently reused) and briefly referenced in the child poms or inherently referenced by the child modules packaging type (i.e., packaging=jar projects automatically bring in the maven-compiler-plugin)
<?xml version="1.0" encoding="UTF-8"?>
<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>myorg.basicejb</groupId>
<artifactId>basicejbEx</artifactId>
<packaging>pom</packaging>
<name>Basic EJB Exercise</name>
<version>1.0-SNAPSHOT</version>
<description>
This project is the root project for the example Java EE
Application.
</description>
<modules>
</modules>
<properties>
<project.build.sourceEncoding>UTF-8</project.build.sourceEncoding>
</properties>
<repositories>
</repositories>
<pluginRepositories>
</pluginRepositories>
<dependencyManagement>
<dependencies>
</dependencies>
</dependencyManagement>
<build>
<pluginManagement>
<plugins>
</plugins>
</pluginManagement>
</build>
<profiles>
</profiles>
</project>
Note
It is very important that you make the packaging type is "pom" in this case. If you leave out this specification, Maven will default to packaging=jar type and attempt to build a Java-based artifact and ignore its responsibility in this project to be the root project to delegate to the child projects that build artifacts.
Add in the maven-compiler-plugin specification to the parent pom to make sure JDK 1.7 or above is used and we use an up to date version of the plugin.
<properties>
<project.build.sourceEncoding>UTF-8</project.build.sourceEncoding>
<java.source.version>1.8</java.source.version>
<java.target.version>1.8</java.target.version>
<maven-compiler-plugin.version>3.1</maven-compiler-plugin.version>
</properties>
...
<pluginManagement>
<plugins>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-compiler-plugin</artifactId>
<version>${maven-compiler-plugin.version}</version>
<configuration>
<source>${java.source.version}</source>
<target>${java.target.version}</target>
</configuration>
</plugin>
Test your root project by building it at this time.
$mvn clean install ... [INFO] Scanning for projects... [INFO] [INFO] ------------------------------------------------------------------------ [INFO] Building Basic EJB Exercise 1.0-SNAPSHOT [INFO] ------------------------------------------------------------------------ [INFO] [INFO] --- maven-clean-plugin:2.5:clean (default-clean) @ basicejbEx --- [INFO] [INFO] --- maven-install-plugin:2.4:install (default-install) @ basicejbEx --- [INFO] Installing /home/jcstaff/proj/basicejbEx/pom.xml to /home/jcstaff/.m2/repository2/myorg/basicejb/basicejbEx/1.0-SNAPSHOT/basicejbEx-1.0-SNAPSHOT.pom [INFO] ------------------------------------------------------------------------ [INFO] BUILD SUCCESS [INFO] ------------------------------------------------------------------------ [INFO] Total time: 0.682 s [INFO] Finished at: 2014-10-04T17:45:26-04:00 [INFO] Final Memory: 7M/105M [INFO] ------------------------------------------------------------------------
The EJB module will be used to develop one of the EJB components. The term "EJB" gets a little overloaded at times. There are EJB classes, EJB components, and an EJB tier. EJB classes break out into the business-remote (aka @Remote) and business-local (aka @Local) interfaces, the EJB implementation class (either @Stateless, @Stateful, @Singleton, or @MessageDriven), and support classes. It is common to think of each cohesive pairing of @Remote, @Local, and implementation class as "an EJB". You can have many EJBs (the sets of classes) within an EJB component. An EJB component is a materialized as a .jar and there can be many EJB components within your EJB tier. For this exercise we will have only one EJB component and start out with only one EJB. A second EJB will be added to the single EJB component in a later excercise to help support testing. A single Maven project can build a single EJB component.
Add an EJB module directory to your project tree.
$ mkdir basicejb-ejb
Add the outer shell of the EJB module's pom.xml.
<?xml version="1.0" encoding="UTF-8"?>
<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">
<parent>
<artifactId>basicejbEx</artifactId>
<groupId>myorg.basicejb</groupId>
<version>1.0-SNAPSHOT</version>
</parent>
<modelVersion>4.0.0</modelVersion>
<artifactId>basicejb-ejb</artifactId>
<packaging>ejb</packaging>
<name>Basic EJB Exercise::EJB</name>
<description>
This project provides example usages of an EJB tier.
</description>
<dependencies>
</dependencies>
<build>
<plugins>
</plugins>
</build>
</project>
Note
It is important to note that the packaging type is "ejb" in this case. If you leave out the packaging type, Maven will default to "jar" and not handle your module appropriately within the context of a Java EE application.
Add in the maven-ejb-plugin definition to the *parent* pom.xml with all properties and constructs that would be common across all EJB modules.
Tell maven explicitly to use EJB 3.x. Anything 3.0 and above should be fine. The plugin defaults to EJB 2.1 which requires a descriptor in META-INF/ejb-jar.xml. We won't be using a descriptor until later.
Tell maven to add all dependencies that have scope=compile to the Class-Path in the META-INF/MANIFEST.MF. This is a pure Java construct that JavaEE takes advantage of in order to resolve dependencies on the server.
# basicejbEx/pom.xml
<properties>
...
<maven-ejb-plugin.version>3.0.1</maven-ejb-plugin.version>
</properties>
<pluginManagement>
...
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-ejb-plugin</artifactId>
<version>${maven-ejb-plugin.version}</version>
<configuration>
<ejbVersion>3.2</ejbVersion>
<archive>
<manifest>
<addClasspath>true</addClasspath>
</manifest>
</archive>
</configuration>
</plugin>
Add in the maven-ejb-plugin declaration to the EJB/pom.xml. This will contain portions of the plugin definition that could be unique per EJB module.
Tell the plugin to create a ejb-client.jar file for remote clients. This will be populated using a set of include and exclude paths. In this case, we are telling it not to include any of our deployment descriptors in the META-INF directory as well as leaving out our EJB implemenation class. This will produce an extra jar in the target directory called ${project.artifactId}-${project.version}-client.jar and can be brought in with a dependency on the EJB module using a type element set to "ejb-client". We will do this in the RMI Test module.
<!-- tell the EJB plugin to build a client-jar -->
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-ejb-plugin</artifactId>
<configuration>
<generateClient>true</generateClient>
<clientExcludes>
<clientExclude>**/META-INF/*.xml</clientExclude>
<clientExclude>**/ejb/*EJB.class</clientExclude>
</clientExcludes>
</configuration>
</plugin>
</plugins>
</build>
Note
Since the packaging type is "ejb" for this module, the maven-ejb-plugin is brought in (according to our pluginManagement definition) automatically. We are just extending the definition to include the ejb-client. If the plugin was not automatically brought in because of the packaging type -- the above specification in the build.plugins section of the EJB/pom.xml would have been enough to activate the plugin.
Add several dependencies to the EJB/pom.xml account for use of logging, annotations, and EJB constructs. Since we will be instantiating this code only on the server and not in a 2-tier approach, the pure JavaEE API from Sun/Oracle will do fine. Otherwise we should use the dependencies from Hibernate/JBoss.
# basicejbEx/basicejb-ejb/pom.xml
<dependencies>
<!-- core implementation dependencies -->
<dependency>
<groupId>org.slf4j</groupId>
<artifactId>slf4j-api</artifactId>
<scope>provided</scope>
</dependency>
<dependency>
<groupId>javax.ejb</groupId>
<artifactId>javax.ejb-api</artifactId>
<scope>provided</scope>
</dependency>
<!-- test dependencies -->
<dependency>
<groupId>junit</groupId>
<artifactId>junit</artifactId>
<scope>test</scope>
</dependency>
<dependency>
<groupId>org.slf4j</groupId>
<artifactId>slf4j-log4j12</artifactId>
<scope>test</scope>
</dependency>
<dependency>
<groupId>log4j</groupId>
<artifactId>log4j</artifactId>
<scope>test</scope>
</dependency>
</dependencies>
Note
You should always declare a scope=provided dependency on the JavaEE API artifacts so that downstream clients of the module are free to supply their own version/provider of the API.
Attempt to validate the EJB module at the child level without futher specification. This will fail because we are missing version information for the two dependency artifacts we just added.
$ mvn validate [ERROR] The project myorg.basicejb:basicejb-ejb:1.0-SNAPSHOT (/home/jcstaff/proj/basicejbEx/basicejb-ejb/pom.xml) has 5 errors [ERROR] 'dependencies.dependency.version' for org.slf4j:slf4j-api:jar is missing. @ myorg.basicejb:basicejb-ejb:[unknown-version], .../basicejbEx/basicejb-ejb/pom.xml, line 22, column 21 [ERROR] 'dependencies.dependency.version' for javax.ejb:javax.ejb-api:jar is missing. @ myorg.basicejb:basicejb-ejb:[unknown-version], .../basicejbEx/basicejb-ejb/pom.xml, line 27, column 21 [ERROR] 'dependencies.dependency.version' for junit:junit:jar is missing. @ myorg.basicejb:basicejb-ejb:[unknown-version], .../basicejbEx/basicejb-ejb/pom.xml, line 34, column 21 [ERROR] 'dependencies.dependency.version' for org.slf4j:slf4j-log4j12:jar is missing. @ myorg.basicejb:basicejb-ejb:[unknown-version], .../basicejbEx/basicejb-ejb/pom.xml, line 39, column 21 [ERROR] 'dependencies.dependency.version' for log4j:log4j:jar is missing. @ myorg.basicejb:basicejb-ejb:[unknown-version], .../basicejbEx/basicejb-ejb/pom.xml, line 44, column 21
Update the parent pom.xml with the version specifications for these artifacts.
# basicejbEx/pom.xml
<properties>
...
<javax.ejb-api.version>3.2.2</javax.ejb-api.version>
<junit.version>4.12</junit.version>
<slf4j.version>1.7.25</slf4j.version>
<log4j.version>1.2.17</log4j.version>
...
<dependencyManagement>
<dependencies>
<dependency>
<groupId>org.slf4j</groupId>
<artifactId>slf4j-api</artifactId>
<version>${slf4j.version}</version>
</dependency>
<dependency>
<groupId>javax.ejb</groupId>
<artifactId>javax.ejb-api</artifactId>
<version>${javax.ejb-api.version}</version>
</dependency>
<dependency>
<groupId>junit</groupId>
<artifactId>junit</artifactId>
<version>${junit.version}</version>
</dependency>
<dependency>
<groupId>org.slf4j</groupId>
<artifactId>slf4j-log4j12</artifactId>
<version>${slf4j.version}</version>
</dependency>
<dependency>
<groupId>log4j</groupId>
<artifactId>log4j</artifactId>
<version>${log4j.version}</version>
</dependency>
</dependencies>
</dependencyManagement>
Validate that maven can now resolve the new dependencies.
$ mvn validate [INFO] BUILD SUCCESS
Note
We are using only the maven validate phase at this point because we only want to validate whether maven can resolve all artifacts and not fully build an EJB component. The build will fail if you use a more advanced maven phase prior to adding the EJB source code in the following steps.
Tip
If you have not yet done so, you can now import your multi-module project into the IDE as an existing set of Maven projects. Since we have not yet linked the two -- you will need to import them in separate steps. Although the instructions are written using file system commands it is assumed that you can translate them into IDE actions and work at the level you desire.
Create the src tree for the EJB.
$ mkdir mkdir -p basicejb-ejb/src/main/java/org/myorg/basicejb/ejb
Add @Remote and @Local interfaces for the EJB. Place a simple ping() method in the @Remote interface for use as an end-to-end sanity check at the end of this exercise.
$ cat basicejb-ejb/src/main/java/org/myorg/basicejb/ejb/ReservationRemote.java
package org.myorg.basicejb.ejb;
import javax.ejb.Remote;
@Remote
public interface ReservationRemote {
void ping();
}$ cat basicejb-ejb/src/main/java/org/myorg/basicejb/ejb/ReservationLocal.java
package org.myorg.basicejb.ejb;
import javax.ejb.Local;
@Local
public interface ReservationLocal {
}Add a @Stateless EJB that will implement the provided @Remote and @Local interfaces. Implement @PostConstruct and @Destroy callbacks to intercept EJB lifecycle events. Add a logger and log statements to the methods so we can observe activity within the EJB during the test at the end of this exercise.
$ cat basicejb-ejb/src/main/java/org/myorg/basicejb/ejb/ReservationEJB.java
package org.myorg.basicejb.ejb;
import javax.annotation.PostConstruct;
import javax.annotation.PreDestroy;
import javax.ejb.Stateless;
import org.slf4j.Logger;
import org.slf4j.LoggerFactory;
@Stateless
public class ReservationEJB implements ReservationLocal, ReservationRemote {
private static Logger logger = LoggerFactory.getLogger(ReservationEJB.class);
@PostConstruct
public void init() {
logger.debug("*** ReservationEJB.init() ***");
}
@PreDestroy
public void destroy() {
logger.debug("*** ReservationEJB.destroy() ***");
}
@Override
public void ping() {
logger.debug("ping called");
}
}The EJB can be built at this time. You will notice the following in the output.
Our 3 Java files (@Remote, @Local, and @Stateless) were compiled
EJB 3 processing was performed on the target. This largely consisted only of MANIFEST Class-Path processing and the construction of an ejb-client.jar file at this point.
$ mvn package [INFO] ------------------------------------------------------------------------ [INFO] Building Basic EJB Exercise::EJB 1.0-SNAPSHOT [INFO] ------------------------------------------------------------------------ ... [INFO] --- maven-resources-plugin:2.6:resources (default-resources) @ basicejb-ejb --- ... [INFO] --- maven-compiler-plugin:3.1:compile (default-compile) @ basicejb-ejb --- [INFO] Changes detected - recompiling the module! [INFO] Compiling 3 source files to /home/jcstaff/proj/basicejbEx/basicejb-ejb/target/classes ... [INFO] --- maven-resources-plugin:2.6:testResources (default-testResources) @ basicejb-ejb --- ... [INFO] --- maven-compiler-plugin:3.1:testCompile (default-testCompile) @ basicejb-ejb --- ... [INFO] --- maven-surefire-plugin:2.12.4:test (default-test) @ basicejb-ejb --- ... [INFO] --- maven-ejb-plugin:2.4:ejb (default-ejb) @ basicejb-ejb --- [INFO] Building EJB basicejb-ejb-1.0-SNAPSHOT with EJB version 3.2 [INFO] Building jar: .../basicejbEx/basicejb-ejb/target/basicejb-ejb-1.0-SNAPSHOT.jar [INFO] Building EJB client basicejb-ejb-1.0-SNAPSHOT-client [INFO] Building jar: .../basicejbEx/basicejb-ejb/target/basicejb-ejb-1.0-SNAPSHOT-client.jar [INFO] ------------------------------------------------------------------------ [INFO] BUILD SUCCESS
Module structure looks very similar to a POJO/JAR module
. |-- basicejb-ejb | |-- pom.xml | |-- src | | `-- main | | `-- java | | `-- org | | `-- myorg | | `-- basicejb | | `-- ejb | | |-- ReservationEJB.java | | |-- ReservationLocal.java | | `-- ReservationRemote.java | `-- target | |-- basicejb-ejb-1.0-SNAPSHOT-client.jar | |-- basicejb-ejb-1.0-SNAPSHOT.jar ... `-- pom.xml
The EJB.jar contains the full set of EJB classes/interfaces
$ jar tf target/basicejb-ejb-1.0-SNAPSHOT.jar ... org/myorg/basicejb/ejb/ReservationLocal.class org/myorg/basicejb/ejb/ReservationRemote.class org/myorg/basicejb/ejb/ReservationEJB.class ...
The EJB-client.jar contains classes/interfaces required by remote clients
$ jar tf target/basicejb-ejb-1.0-SNAPSHOT-client.jar ... org/myorg/basicejb/ejb/ReservationLocal.class org/myorg/basicejb/ejb/ReservationRemote.class ...
Note
Technically, Local interfaces should not be needed by remote clients. However, there was a time when remote clients of JBoss Stateful Session EJBs required access to all interface types and old assembly habits die hard when it does not hurt to include the extra interface if not needed.
Add the EJB module to the root pom.xml.
<modules>
<module>basicejb-ejb</module>
</modules>
Retest the build from the root.
[INFO] Scanning for projects... ... [INFO] ------------------------------------------------------------------------ [INFO] Reactor Summary: [INFO] [INFO] Basic EJB Exercise ................................. SUCCESS [ 0.503 s] [INFO] Basic EJB Exercise::EJB ............................ SUCCESS [ 2.457 s] [INFO] ------------------------------------------------------------------------ [INFO] BUILD SUCCESS
Add a unit test to the EJB module to show that you can unit test functionality that does not require the container. This class will go into the src/test tree and will not be a part of the EJB.jar
$ mkdir -p basicejb-ejb/src/test/java/org/myorg/basicejb/ejb
$ cat basicejb-ejb/src/test/java/org/myorg/basicejb/ejb/ReservationTest.java
package org.myorg.basicejb.ejb;
import org.junit.Before;
import org.junit.Test;
import org.slf4j.Logger;
import org.slf4j.LoggerFactory;
public class ReservationTest {
private static final Logger logger = LoggerFactory.getLogger(ReservationTest.class);
ReservationRemote reservatist;
@Before
public void setUp() {
reservatist=new ReservationEJB();
}
@Test
public void testPing() {
logger.info("*** testPing ***");
reservatist.ping();
}
}Add a log4j.xml file to support logging unit test functionality that does not require the container.
$ mkdir -p basicejb-ejb/src/test/resources
$ cat basicejb-ejb/src/test/resources/log4j.xml
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE log4j:configuration PUBLIC
"-//APACHE//DTD LOG4J 1.2//EN" "http://logging.apache.org/log4j/1.2/apidocs/org/apache/log4j/xml/doc-files/log4j.dtd">
<log4j:configuration
xmlns:log4j="http://jakarta.apache.org/log4j/"
debug="false">
<appender name="CONSOLE" class="org.apache.log4j.ConsoleAppender">
<param name="Target" value="System.out"/>
<layout class="org.apache.log4j.PatternLayout">
<param name="ConversionPattern" value="%d{HH:mm:ss,SSS} %-5p (%F:%L) -%m%n"/>
</layout>
</appender>
<appender name="logfile" class="org.apache.log4j.RollingFileAppender">
<param name="File" value="target/log4j-out.txt"/>
<param name="Append" value="false"/>
<param name="MaxFileSize" value="100KB"/>
<param name="MaxBackupIndex" value="1"/>
<layout class="org.apache.log4j.PatternLayout">
<param name="ConversionPattern"
value="%-5p %d{dd-MM HH:mm:ss,SSS} [%c] (%F:%M:%L) -%m%n"/>
</layout>
</appender>
<logger name="org.myorg">
<level value="debug"/>
<appender-ref ref="logfile"/>
</logger>
<root>
<priority value="info"/>
<appender-ref ref="CONSOLE"/>
</root>
</log4j:configuration>
Rebuild the EJB and/or entire application. You will notice the unit tests executed during the build.
$ mvn clean install ... [INFO] --- maven-surefire-plugin:2.12.4:test (default-test) @ basicejb-ejb --- [INFO] Surefire report directory: /home/jcstaff/proj/basicejbEx/basicejb-ejb/target/surefire-reports ------------------------------------------------------- T E S T S ------------------------------------------------------- Running org.myorg.basicejb.ejb.ReservationTest 21:50:10,382 INFO (ReservationTest.java:20) -*** testPing *** 21:50:10,390 DEBUG (ReservationEJB.java:26) -ping called Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.218 sec Results : Tests run: 1, Failures: 0, Errors: 0, Skipped: 0 ... [INFO] BUILD SUCCESS
Note
Notice the we are automatically getting a surefire execution and our JUnit test run. We get this because surefire is automatically brought in by the pom's packaging type *and* we ended the Java class name with Test. Looking at the plugin page, the other default name patterns include.
**/Test*.java
**/*Test.java
**/*TestCase.java
As discussed on that same web page -- you can expand or shrink that list with the use of includes and excludes. This is commonly done to focus your testing around a specific unit test or to temporarily exclude all unit tests from the build to focus on a specific IT test (discussed later).
Verify this is what you have so far.
. |-- basicejb-ejb | |-- pom.xml | `-- src | |-- main | | `-- java | | `-- org | | `-- myorg | | `-- basicejb | | `-- ejb | | |-- ReservationEJB.java | | |-- ReservationLocal.java | | `-- ReservationRemote.java | `-- test | |-- java | | `-- org | | `-- myorg | | `-- basicejb | | `-- ejb | | `-- ReservationTest.java | `-- resources | `-- log4j.xml `-- pom.xml
This set of steps is in preparation for the next chapter where you will be asked to deploy the EJB built above to the server. In this section you will be shown how to start/stop a standalone server and how to setup, start/stop an embedded server.
Depending on the origin of your server setup, either verify or put in place the following in the JBoss/Wildfly application server configuration file to address logging.
# wildfly-13.0.0.Final/standalone/configuration/standalone.xml <logger category="org.myorg"> <level name="DEBUG"/> </logger> ... <root-logger> <level name="INFO"/> <handlers> <handler name="CONSOLE"/> <handler name="FILE"/> </handlers> </root-logger>The default configuration will permit all log entries INFO and above to be written to the CONSOLE and FILE appenders. The extra lines added for org.myorg defined a new logger that will have messages DEBUG and above logged. The CONSOLE appender is normally throttled to only log INFO and above so you should not see any impact of the changes above in the server's console output. The extra debug will be placed in the standalone/log/server.log file.
$ tail -f standalone/log/server.log ... 06:57:32,031 INFO [info.ejava.examples.ejb.basic.ejb.GreeterEJB] (default task-1) *** GreeterEJB:init(1127977520) *** 06:57:32,031 DEBUG [info.ejava.examples.ejb.basic.ejb.GreeterEJB] (default task-1) sayHello() 06:57:32,113 DEBUG [info.ejava.examples.ejb.basic.ejb.GreeterEJB] (default task-3) sayHello(cat inhat) ...
The standalone application server runs as a separate process either in the same machine as or remote machine from the development machine. This approach more closely resembles the target server setup and can help test certain production-like configurations. This is normally managed through scripts.
Start the JBoss/Wildfly application server. In the command shown below
-Djboss.server.base.dir - used to point to the root of the profile. If you create other profiles (by copying the standalone directory) you can point the script to that directory using this java property flag. This flag is not needed if you use the default standalone directory.
-c standalone.xml - used to point to a specific profile configuration file within the ${jboss.server.base.dir}/configuration directory. If you create alternate configurations (by copying the standalone.xml file) you can point the script to that configuration using this argument. This is useful to switch between alternate configurations but not required if you use the default standalone.xml configuration file.
wildfly-13.0.0.Final$ ./bin/standalone.sh ========================================================================= JBoss Bootstrap Environment JBOSS_HOME: /Users/jim/apps/wildfly-13.0.0.Final JAVA: java JAVA_OPTS: -server -Xms64m -Xmx512m -XX:MetaspaceSize=96M -XX:MaxMetaspaceSize=256m -Djava.net.preferIPv4Stack=true -Djboss.modules.system.pkgs=org.jboss.byteman -Djava.awt.headless=true ========================================================================= 10:14:01,139 INFO [org.jboss.modules] (main) JBoss Modules version 1.8.5.Final 10:14:01,372 INFO [org.jboss.msc] (main) JBoss MSC version 1.4.2.Final 10:14:01,379 INFO [org.jboss.threads] (main) JBoss Threads version 2.3.2.Final 10:14:01,474 INFO [org.jboss.as] (MSC service thread 1-2) WFLYSRV0049: WildFly Full 13.0.0.Final (WildFly Core 5.0.0.Final) starting ... 10:14:03,969 INFO [org.jboss.as] (Controller Boot Thread) WFLYSRV0025: WildFly Full 13.0.0.Final (WildFly Core 5.0.0.Final) started in 3104ms - Started 358 of 581 services (356 services are lazy, passive or on-demand)Shutdown the server using the command line interface (CLI)
wildfly-13.0.0.Final$ ./bin/jboss-cli.sh --connect command=:shutdown { "outcome" => "success", "result" => undefined }Restart the server.
wildfly-13.0.0.Final]$ ./bin/standalone.sh ...
Shutdown the server by pressing Control-C keys
^C10:17:19,557 INFO [org.jboss.as.server] (Thread-2) WFLYSRV0236: Suspending server with no timeout. 10:17:19,558 INFO [org.jboss.as.ejb3] (Thread-2) WFLYEJB0493: EJB subsystem suspension complete 10:17:19,559 INFO [org.jboss.as.server] (Thread-2) WFLYSRV0220: Server shutdown has been requested via an OS signal ... 10:17:19,616 INFO [org.jboss.as] (MSC service thread 1-1) WFLYSRV0050: WildFly Full 13.0.0.Final (WildFly Core 5.0.0.Final) stopped in 53ms
Note
There is no negative impact from stopping the application server using Control-C key sequence.
The embedded application server places the server in the same JVM as the IDE. This allows for easy start, stop, and debug options for managing the server. Since the server is running inside the IDE, it can differ greatly from what is used in production.
Note
The following steps assumes JBoss AS Tools have been installed. If the server setup does not list a Wildfly 13.x server option please make install that option. Use the latest version if Wildfly 13.x is not yet available.
Add a new Wildfly (latest).x Server off the Servers tab of the JavaEE IDE profile. Accept all defaults.
Figure 47.1. Choose New Server
Locate Server tab in the Eclipse JavaEE Profile
Right-Click in panel and select New Server
Choose most recent Wildfly configuration closest to current
Start the server by right-clicking on the server and selecting Start.
Stop the server by right-clicking on the server and selecting Stop.
Created parent module
Houses re-usable property, dependency and plugin definitions
Delegates build to implementation modules
Has no technical artifacts of its own
Created EJB module
EJB modules have one or more EJBs
an "EJB" is made up of an EJB class and optional @Remote and @Local interfaces
Functional unit tests can be included in the EJB module
Server management
Control logging verbosity
Start/Stop standalone server
Create and Start/Stop embedded server