Skip to content
This repository has been archived by the owner on Jul 12, 2024. It is now read-only.

WildFly Integration

Thomas Diesler edited this page Oct 11, 2013 · 7 revisions

Preparing WildFly

Gravia provides a patch for for WildFly as a Maven artefact

<dependency>
	<groupId>org.jboss.gravia</groupId>
	<artifactId>gravia-container-wildfly</artifactId>
	<classifier>patch</classifier>
	<type>zip</type>
</dependency>

It contains the Gravia subsystem and a number of other jars that get copied to the modules directory.

You can start WildFly with the Gravia integration like this

[tdiesler@localhost wildfly-8.0.0.Beta1]$ bin/standalone.sh -c standalone-gravia.xml
=========================================================================

  JBoss Bootstrap Environment

  JBOSS_HOME: .../wildfly-8.0.0.Beta1

  JAVA: .../jdk1.7.0_25.jdk/Contents/Home/bin/java

  JAVA_OPTS:  -server ...

=========================================================================

10:24:53,179 INFO  [org.jboss.modules] (main) JBoss Modules version 1.3.0.Final
10:24:53,434 INFO  [org.jboss.msc] (main) JBoss MSC version 1.2.0.Beta2
10:24:53,506 INFO  [org.jboss.as] (MSC service thread 1-6) JBAS015899: WildFly 8.0.0.Beta1 "WildFly" starting
...
10:24:54,538 INFO  [org.wildfly.gravia] (MSC service thread 1-7) JBAS020000: Activating Gravia Subsystem
...
10:24:54,736 INFO  [org.jboss.gravia.runtime] (MSC service thread 1-6) Installed: Module[org.apache.felix.scr:1.6.2]
10:24:54,740 INFO  [org.jboss.gravia.runtime] (MSC service thread 1-6) Installed: Module[org.apache.felix.configadmin:1.6.0]
...
10:24:55,697 INFO  [org.jboss.as] (Controller Boot Thread) JBAS015874: WildFly 8.0.0.Beta1 "WildFly" started in 2803ms

Preparing a Deployment

Gravia works with already resolved Modules that have a valid ClassLoader. In this case with the ClassLoader provided by WildFly.

Installing/Starting a Module

Before the Module becomes operational the WildFly has to do the following

  1. Create the global Runtime instance
  2. Install the deployment as a Module in the Runtime
  3. Start the Module

This is done by intercepting the deployment and doing the necessary work in so called Deployment Unit Processors (DUP). It also means that any (JavaEE) deployment type supported by WildFly can also be a Gravia Module and hence use Gravia services.

You can use Declarative Services and Configuration Admin in your JavaEE components.

Stopping Stopping/Uninstalling a Module

When a deployment gets undeployed WildFly has to do the following

  1. Stop the Gravia Module
  2. Uninstall the Gravia Module from the Runtime

The Gravia subsystem does this automatically in its Deployment Unit Processors.

Defining the Module

Have a look at Defining a Module

Activating the Module

Have a look at Activating a Module

Clone this wiki locally