![\"01-diagram-ex-domain-deployement\"](\"\/blog\/wp-content\/uploads\/2014\/06\/01-diagram-ex-domain-deployement.png\")
<\/a><\/p>\nA domain mode architecture will contain:<\/p>\n
- \n
- A domain controller: This is a light JVM JBoss server that will distribute the configuration and deployments to inject into each JBoss server instance. An application cannot be deployed\/started on this JVM; it exposes a Web management interface to see\/modify configurations and assign applications (EAR, WAR, modules) into each JBoss Server.<\/li>\n<\/ul>\n
- \n
- A host controller per OS instance (VM or physical machine): This is a light JVM that will be deployed on each host (OS+Hardware) and acts like a bridge to allow the domain controller to manage JBoss servers instantiated in the local machine. The configuration of this JVM takes place in a local file named host.xml<\/span>. The domain controller address and the JBoss server(s) to start locally are defined in this configuration file.<\/li>\n<\/ul>\n
- \n
- A JBoss Server instance: Each host\/machine can have one or more JBoss Servers, which need to be associated to the local host controller. The JBoss server instance cannot contain locally deployed applications or a configuration file. Everything has to be controlled using the domain controller UI, JBoss Cli, or XML files. Some “default configurations” can be provided for the domain.xml<\/span> configuration file, but the evolution\/improvements on this configuration file have to be performed using the “Web management interface” or JBoss Cli, similar to IBM Websphere (which also provides both methods; the xml manual modifications are not supported by IBM. RedHat has copied this feature from IBM Websphere).<\/li>\n<\/ul>\n
In fact, the standalone configuration file standalone.xml<\/span> and list of applications deployed are managed and modified in a local folder inside the JBoss. In domain mode, the configuration (connectors, datasources, security-domain, ejb, system variables, etc.) is added in one file named domain.xml<\/span>. This file will be used to describe the configuration profiles and deployments added to each server group (Attention: The server group notion is a logical way of denoting that N<\/i> servers have the same configuration entries and deployments. It is not the same as servers controlled by one host controller).<\/p>\n
A complete explanation can be found in this documentation.<\/p>\n
eXo Context<\/h2>\n
What the Standalone package contains:<\/i><\/b><\/p>\n
- \n
- platform.ear<\/span> (folder with applications and modules)<\/li>\n
- standalone.sh<\/span> & co (standalone-customize.sample.conf<\/span> & standalone.conf<\/span>): For some JVM essential variables, such as profiles, xmx, xms, etc.<\/li>\n
- standalone.xml<\/span>: to configure JCR & IDM Datasources and<\/li>\n
- GateIn external configuration folder gatein\/conf<\/span><\/li>\n
- extensions folder: acme, cmis, etc.<\/li>\n<\/ul>\n
What is the difference with Domain mode packaging:<\/i><\/b><\/p>\n
- \n
- platform.ear<\/span>: Has to be an archive not a folder<\/li>\n
- standalone.sh<\/span> & co: All system variables have to be added in domain.xml<\/span><\/li>\n
- GateIn external configuration folder: No change (This folder has to be copied in each host controller configuration folder)<\/li>\n
- extensions folder: Provides a script that repackages the platform.ear<\/span> to add one or more extensions.<\/li>\n<\/ul>\n
eXo in domain mode<\/h2>\n
Deployment to implementation<\/h3>\n
![\"02-deployment-to-implement\"](\"\/blog\/wp-content\/uploads\/2014\/06\/02-deployment-to-implement.png\")
<\/a><\/p>\nFollow these steps to get eXo Platform running in domain mode:<\/p>\n
1 \u2013 Install eXo in Jboss EAP:<\/h3>\n
- \n
- Extract platform-4.0.x-jboss.zip<\/span><\/li>\n
- Merge the content with Jboss EAP: This will add files in JBOSS_HOME\/bin<\/span> and JBOSS_HOME\/standalone<\/span> and create an extension folder in the root<\/li>\n
- Extensions are installable with extension.[sh|bat]copy eXo_domain folder in JBOSS_HOME.<\/li>\n<\/ul>\n
2 \u2013 Copy eXo-domain.xml<\/span> & eXo-host.xml<\/span> in JBOSS_HOME\/domain<\/span><\/h3>\n
![\"03\"](\"\/blog\/wp-content\/uploads\/2014\/06\/03.png\")
<\/a><\/p>\nArchive (download<\/a>) contains a shell script to start\/stop an eXo cluster in domain mode.<\/p>\n
Edit the script to match your settings:<\/p>\n
JBOSS_USER=\nSTARTUP_WAIT=5\nSHUTDOWN_WAIT=5\nJBOSS_HOME=\nJBOSS_CONSOLE_LOG=$JBOSS_HOME\/eXo_domain\/log\/console-stdout.log\nJAVA_HOME=\/usr\/java\/default\nJBOSS_PIDFILE=$JBOSS_HOME\/eXo_domain\/tmp\/jboss_dc.pid\nJBOSS_CONFIG=eXo-domain.xml\nHOST_CONFIG=eXo-host.xml\nNOPAUSE=true\nIP_ADDR=\nJBOSS_SCRIPT=\"$JBOSS_HOME\/bin\/domain.sh -b $IP_ADDR -bmanagement $IP_ADDR host-config=$HOST_CONFIG -Djboss.domain.base.dir=$JBOSS_HOME\/eXo_domain -Djboss.domain.master.address=$IP_ADDR\"<\/pre>\n
3 \u2013 Edit JBOSS_HOME\/eXo_domain\/configuration\/eXo-domain.xml<\/span><\/h3>\n
- \n
- Update the data sources section to meet your environment settings<\/li>\n
- Update the system properties to match your needs<\/li>\n
- Update any path you may need to customize and choose exo.profiles.<\/li>\n<\/ul>\n
4 \u2013 Under JBOSS_HOME\/eXo_domain\/servers\/<\/span><\/h3>\n
Create a directory named “autonomous-eXo-instance-1” to match the name used in eXo_host.xml<\/span>.<\/p>\n
This directory contains per instance configuration files (gatein configuration folder), instance log files, tmp and data folders.<\/p>\n
5 \u2013 Add database driver as jboss module:<\/h3>\n
create a jboss module referencing your database driver. The following example is for Mysql.<\/p>\n
JBOSS_HOME\/modules\/system\/layers\/base\/com\/mysql\/main\/module.xml<\/span><\/p>\n
<?xml version=\"1.0\" encoding=\"UTF-8\"?>\n<module name=\"com.mysql\">\n<\/properties>\n<resources>\n<resource-root path=\"mysql-connector-java-5.1.26-bin.jar\"\/>\n<\/resources>\n<dependencies><module name=\"javax.api\"\/><module name=\"javax.transaction.api\"\/>\n<\/dependencies>\n<\/module>\n<\/pre>\n
6 \u2013 Start jboss:<\/h3>\n
JBOSS_HOME\/eXo_domain\/eXo_dc.sh start<\/span><\/p>\n
7 \u2013 Access to Jboss Web console:<\/h3>\n
(default port is 9990)
\n(user and password are stored in mgmt-users.properties<\/span> and created by JBOSS_HOME\/bin\/add-user.sh<\/span>)<\/p>\n8 \u2013 Deploy platform.ear<\/span>:<\/h3>\n
platform.ear<\/span> is the main EAR delivered by eXo. It may contain a custom extension.
\nIt contains all WAR, JAR and descriptors.
\nTo deploy an EAR, two methods can be used:<\/p>\nmethod 1: Deploy platform.ear<\/span> using the WebConsole<\/i><\/b><\/p>\n
Click on manage deployments and select your platform.ear<\/span> archive<\/p>\n
![\"04-ear\"](\"\/blog\/wp-content\/uploads\/2014\/06\/04-ear.png\")
<\/a><\/p>\nClick on next then save.<\/p>\n
![\"05-key\"](\"\/blog\/wp-content\/uploads\/2014\/06\/05-key.png\")
<\/a><\/p>\n![\"06-success\"](\"\/blog\/wp-content\/uploads\/2014\/06\/06-success.png\")
<\/a><\/p>\nThis results in a deployment called platform.ear<\/span>.<\/p>\n
This needs to be associated with a server group:<\/p>\n
platform.ear<\/span> is now associated to the server group eXo-cluster-group<\/span> (as a consequence it is associated to all its child servers).<\/p>\n
Because auto-start=”true”<\/span> is enabled for the server eXo-cluster-node1<\/span> (look in eXo-host.xml<\/span>), the platform is automatically deployed.<\/p>\n
These are the last lines of JBOSS_HOME\/eXo_domain\/log\/console-stdout.log<\/span>:<\/p>\n
[Server:autonomous-eXo-instance-1] 00:26:11,979 INFO [exo.kernel.container.RootContainer] (ServerService Thread Pool -- 42) The portal container 'portal' has been created successfully\n[Server:autonomous-eXo-instance-1] 00:26:12,036 INFO [org.jboss.as.server] (Controller Boot Thread) JBAS018559: D\u00e9ploiement de \"platform-4.0.6.ear\" (runtime-name: \"platform-4.0.6.ear\")\n[Server:autonomous-eXo-instance-1] 00:26:12,041 INFO [org.jboss.as] (Controller Boot Thread) JBAS015874: JBoss EAP 6.1.1.GA (AS 7.2.1.Final-redhat-10) booted in 101717ms \n<\/pre>\n
To access the platform: use port 8080<\/p>\n
method 2: Deploy platform.ear using the CLI<\/i><\/b><\/p>\n
Jboss-cli.sh<\/span> offers the same capabilities as the web console and is scriptable.<\/p>\n
To deploy platform.ear<\/span> run the following command:<\/p>\n
JBOSS_HOME\/bin\/jboss-cli.sh --connect --command=\u201ddeploy $PATH_TO_EAR --name=$NEW_DEPL_NAME --server-groups=$SERVER_GROUP_NAME\u201d<\/pre>\n
where<\/p>\n
$PATH_TO_EAR<\/span>: Path to the ear.
\n$NEW_DEPL_NAME<\/span>: Not mandatory; if not specified, the deployment name will match the ear filename.
\n$SERVER_GROUP_NAME<\/span>: Target server group: eXo-cluster-Group in our example.<\/p>\nNext you can start<\/b> and stop<\/b> a given server (eXo-cluster-node1<\/span> and eXo-cluster-node1<\/span>: Look in eXo-host.xml<\/span>).<\/p>\n
BOSS_HOME\/bin\/jboss-cli.sh --connect --command=\u201d\/host=$JBOSS_HOSTNAME\/server-config=$SERVER_NAME:start(blocking=true)\u201d<\/pre>\n
where<\/p>\n
$JBOSS_HOSTNAME<\/span>: Defined in eXo-host.xml (<host name=”NAME” xmlns=”urn:jboss:domain:1.4″>) master in our example.
\n$SERVER_NAME<\/span>: Defined in eXo-host.xml (<server name=”NAME” \u2026>)<\/p>\nblocking=true<\/span>: Means that the command will not exit until full completion of the task.<\/p>\n
This procedure can be used to create the required instances by declaring and associating server groups with profiles, and hosts with servers.<\/p>\n
Some modifications are required to run an eXo cluster in domain mode. These are mainly related to system properties.<\/p>\n
A future post will describe how to perform a two nodes cluster installation in Jboss domain mode, and how to integrate modcluster for loadblancing.<\/p>\n
<\/p>\n
- Merge the content with Jboss EAP: This will add files in JBOSS_HOME\/bin<\/span> and JBOSS_HOME\/standalone<\/span> and create an extension folder in the root<\/li>\n
- standalone.sh<\/span> & co: All system variables have to be added in domain.xml<\/span><\/li>\n
- standalone.sh<\/span> & co (standalone-customize.sample.conf<\/span> & standalone.conf<\/span>): For some JVM essential variables, such as profiles, xmx, xms, etc.<\/li>\n
- platform.ear<\/span> (folder with applications and modules)<\/li>\n
- A JBoss Server instance: Each host\/machine can have one or more JBoss Servers, which need to be associated to the local host controller. The JBoss server instance cannot contain locally deployed applications or a configuration file. Everything has to be controlled using the domain controller UI, JBoss Cli, or XML files. Some “default configurations” can be provided for the domain.xml<\/span> configuration file, but the evolution\/improvements on this configuration file have to be performed using the “Web management interface” or JBoss Cli, similar to IBM Websphere (which also provides both methods; the xml manual modifications are not supported by IBM. RedHat has copied this feature from IBM Websphere).<\/li>\n<\/ul>\n
- A host controller per OS instance (VM or physical machine): This is a light JVM that will be deployed on each host (OS+Hardware) and acts like a bridge to allow the domain controller to manage JBoss servers instantiated in the local machine. The configuration of this JVM takes place in a local file named host.xml<\/span>. The domain controller address and the JBoss server(s) to start locally are defined in this configuration file.<\/li>\n<\/ul>\n