In eXo Platform, the configuration is performed in a folder whose location is controlled by a system property named exo.conf.dir. By default, the gatein.sh startup script sets this property as follows:

So the main entry point for the eXo Platform configuration is /gatein/conf/. This directory contains the following files :

This section will explain some parts of the eXo internals in so that you will understand the roles of these configuration files.

eXo Platform kernel groups runtime components in portal containers. A portal container holds all components to run a portal instance. It serves portal pages under the servlet context for its name.

The default portal container in eXo Platform is simply called "portal". This explains why the default url for the samples is http://localhost:800/*portal*.

The default portal container can be configured directly inside exo.conf.dir.

But eXo Platform is capable of running several portal instances simultaneously on the same server. Each instance can be configured and customized independently via files located at : /gatein/conf/portal/$PORTAL_NAME, where $PORTAL_NAME is the name of the portal container.

Note

The exact name of the configuration file can be altered. Please refer to the section dedicated to PortalContainerDefinition in the Kernel reference for more details on portal containers and other options to modify the location of the properties.

Services that run inside a portal container are declared via xml configuration files like configuration.xml. Such files exists in jars, wars and below exo.conf.dir.

XML configuration files also serve as the main way to customize the portal via the multiple plugins offered by eXo components.

Additionally, xml files may contain variables that are populated via properties defined in configuration.properties. Hence, the configuration.properties serves as exposing some chosen variables that are necessary to configure eXo Platform in a server environment.

eXo Platform relies on the application server for its database access, so the database must be configured as a datasource at the AS level. That datasource is obtained by accessing the enterprise naming context (ENC) through the Java Naming and Directory Interface (JNDI) service.

If you intend to bring your eXo to production, the embedded hsql database will not be appropriate and you will need to configure your app server to use another one. You will learn how to configure eXo datasources and in your appserver. If you need to change the datasources name, read Changing the datasources names below.

Now that the database is ready, you need to configure eXo to be able to connect to it. The steps depend on the application server. We provide instructions for Tomcat and JBoss

Configuring a datasource for eXo under Tomcat involves two steps:

By default, eXo Platform defines two datasources:

You may want to give them a different name. To do this, do as follows :

Now, you need to change the name under which the datasources are bound in the JNDI tree by the app server. This is application sever dependent.

Some RDBMS, like MySQL, close idle connections after a while (8h by default on MySQL). Thus, a connection from the pool will be invalid and of course any application SQL command will fail, resulting in errors like:

To avoid this, a solution is to use DBCP to monitor idle connections and drop them when they are invalid, with the parameters testWhileIdle, timeBetweenEvictionRunsMillis and validationQuery.

The validation query is specific to your RDBMS, for example on MySQL you would use:

You can add these parameters in the datasource configuration file of your application server (i.e. conf/server.xml on Tomcat).

For more details about the configuration, or some examples on other RDBMS and applications servers, please refer to:

eXo Platform requires an SMTP server in order to send emails such as notifications or password reminders.

gatein.email.smtp.host SMTP hostname
gatein.email.smtp.port SMTP port
gatein.email.smtp.starttls.enable true to enable secure (TLS) SMTP. See RFC 3207
gatein.email.smtp.auth true to enable SMTP authentication
gatein.email.smtp.username username to send for authentication
gatein.email.smtp.password password to send for authentication
gatein.email.smtp.socketFactory.port Specifies the port to connect to when using the specified socket factory
gatein.email.smtp.socketFactory.class his class will be used to create SMTP sockets.

More details can be found in the JavaMail API documentation.

For KS, you have to add one of the following properties to the configuration file (/gatein/conf/configuration.properties) to make sure that this mail service works with authenticated SMTP systems:

mail.from= gatein.email.smtp.from=

The value must be the exact email-address of the account configured above.

The standalone Chat server is configured in the file $CHATSERVER/conf/openfire.xml.

Configuration is based on properties expressed in an XML syntax. For example, to set property prop.name.is.blah=value, you would write this xml snippet :

Openfire has an extensive list of configuration properties. Please read the list of all properties in Openfire documentation

The chat server is an openfire server bundled with plugins and configurations that allow connectivity to eXo Platform. The following properties are used to configure it.

Property Description Default value
env
serverbaseURL base url for all URLs below http://localhost:8080/
restContextName name of the rest context rest
provider
authorizedUser.name username to authenticate against the HTTP REST service root
authorizedUser.password password matching with provider.authorizeduser.name password
eXoAuthProvider
authenticationURL URL to authenticate users /organization/authenticate/
authenticationMethod HTTP method used to pass parameters POST
eXoUserProvider
findUsersURL URL to find all users /organization/xml/user/find-all/
findUsersMethod HTTP method for user/find-all GET
getUsersURL URL to retrieve a range of users /organization/xml/user/view-range/
getUsersMethod HTTP method for user/view-range GET
usersCountURL URL to count users /organization/xml/user/count/
usersCountMethod HTTP method for user/count GET
userInfoURL URL to get user info /organization/xml/user/info/
userInfoMethod HTTP method for user/info GET
eXoGroupProvider
groupInfoURL URL to get group info /organization/xml/group/info/
groupInfoMethod HTTP method for info GET
getGroupsAllURL URL to view all groups /organization/xml/group/view-all/
getGroupsAllMethod HTTP method for group/view-all GET
getGroupsRangeURL URL to view a group range /organization/xml/group/view-from-to/
getGroupsRangeMethod HTTP method for group/view-from-to GET
getGroupsForUserURL URL to get groups for a user /organization/xml/group/groups-for-user/
getGroupsForUserMethod HTTP method for groups-for-user GET
groupsCountURL URL to count groups organization/xml/group/count
groupsCountMethod HTTP method for group/count GET

In order to run properly the chat server needs several ports to be opened in the firewall.

Port Type Description
5222 (1) client to server (xmpp) The standard port for clients is to connect to the server. Connections may or may not be encrypted. You can update the security settings for this port with exo.chat.port property.
9090 && 9091 Admin Console (http) The port used for respectively the unsecured and secured Openfire Admin Console access.
3478 & 3479 STUN service The port used for the service that ensures connectivity between entities when behind a NAT.

eXo Platform allows users to view various types of documents directly in the Content Explorer through the office server. To do so, the office application must be available in your local device first.

Then, JODConverter will use the default values below to start the office server.

Default values are customized by adding paremeters below in the configuration.properties file:

# JODConverter 3.0
#wcm.jodconverter.portnumbers=8100, 8101, 8102, 8103, 8104
#wcm.jodconverter.officehome=/usr/lib/libreoffice
#wcm.jodconverter.taskqueuetimeout=30000
#wcm.jodconverter.taskexecutiontimeout=120000
#wcm.jodconverter.maxtasksperprocess=200
#wcm.jodconverter.retrytimeout=120000

Key Default values Description
wcm.jodconverter.portnumbers 2002List of ports, separated by commas, those used by each JODConverter processing thread. Number of office instances is equal to number of ports.
wcm.jodconverter.officehomeSee here Absolute path of office home on the current local device. It means that office needs to be installed in the local device before using it.
wcm.jodconverter.taskqueuetimeout 30000 Maximum living time of tasks in the conversation queue. Task will be removed from this queue if waiting time is longer than taskQueueTimeout.
wcm.jodconverter.taskexecutiontimeout 120000 If a task has been executing within an soffice process for longer than this period, soffice process will be terminated and restarted.
wcm.jodconverter.maxtasksperprocess 200 To ensure that potential memory leaks do not accumulate and affect performance, the JodConverter will restart an soffice process after a given number of tasks have been performed.
wcm.jodconverter.retrytimeout120000 Interval time to try to restart the office services after an unexpected crash.

The default office home

Logging in eXo Platform is controlled by the Java Logging API.

By default, logging is configured to:

  • log errors and warnings on the console

  • log info level statements in /gatein/logs/gatein-YYYY-MM-DD.log

In Tomcat, the logging is configured via the conf/logging.properties file. Please refer to Tomcat's Logging Documentation for more information on how to adjust this file to your needs.