1.3.2. Parameters


There is a value-param example:

            <description>groups with memberships that have the right to access the User Control Workspace</description>

The UserACL class accesses to the value-param in its constructor.

package org.exoplatform.portal.config;

public class UserACL {
  public UserACL(InitParams params) {
    UserACLMetaData md = new UserACLMetaData();
    ValueParam accessControlWorkspaceParam = params.getValueParam("access.control.workspace");
    if(accessControlWorkspaceParam != null) md.setAccessControlWorkspace(accessControlWorkspaceParam.getValue());


Properties are name-value pairs. Both the name and the value are Java Strings.

Here you see the hibernate configuration example:

            <description>Default Hibernate Service</description>
            <property name="hibernate.show_sql" value="false"/>
            <property name="hibernate.cglib.use_reflection_optimizer" value="true"/>
            <property name="hibernate.connection.url" value="jdbc:hsqldb:file:../temp/data/exodb"/>
            <property name="hibernate.connection.driver_class" value="org.hsqldb.jdbcDriver"/>

In the org.exoplatform.services.database.impl.HibernateServiceImpl you will find that the name "hibernate.properties" of the properties-param is used to access the properties.

package org.exoplatform.services.database.impl;

public class HibernateServiceImpl implements HibernateService, ComponentRequestLifecycle {
  public HibernateServiceImpl(InitParams initParams, CacheService cacheService) {
    PropertiesParam param = initParams.getPropertiesParam("hibernate.properties");


Let's have a look at the configuration of the LDAPService. It's not important to know LDAP, we only discuss the parameters.

            <description>Default ldap config</description>
            <object type="org.exoplatform.services.ldap.impl.LDAPConnectionConfig">
                <field  name="providerURL"><string>ldaps://</string></field>
                <field  name="rootdn"><string>CN=Administrator,CN=Users,DC=exoplatform,DC=org</string></field>
                <field  name="password"><string>exo</string></field>
                <field  name="version"><string>3</string></field>
                <field  name="minConnection"><int>5</int></field>
                <field  name="maxConnection"><int>10</int></field>
                <field  name="referralMode"><string>ignore</string></field>
                <field  name="serverName"><string>active.directory</string></field>

You see here an object-param is being used to pass the parameters inside an object (actually a java bean). It consists of a name, a description and exactly one object. The object defines the type and a number of fields.

Here you see how the service accesses the object:

package org.exoplatform.services.ldap.impl;

public class LDAPServiceImpl implements LDAPService {
  public LDAPServiceImpl(InitParams params) {
    LDAPConnectionConfig config = (LDAPConnectionConfig) params.getObjectParam("ldap.config")

The passed object is LDAPConnectionConfig which is a classic java bean. It contains all fields and also the appropriate getters and setters (not listed here). You also can provide default values. The container creates a new instance of your bean and calls all setters whose values are configured in the configuration file.

package org.exoplatform.services.ldap.impl;

public class LDAPConnectionConfig {
  private String providerURL        = "ldap://";
  private String rootdn;
  private String password;                                  
  private String version;                                   
  private String authenticationType = "simple";
  private String serverName         = "default";
  private int    minConnection;
  private int    maxConnection;
  private String referralMode       = "follow";

You see that the types (String, int) of the fields in the configuration correspond with the bean. A short glance in the kernel_1_0.xsd file let us discover more simple types:

  • string, int, long, boolean, date, double

Have a look on a test resource of the types: object.xml.


You also can use java collections to configure your service. In order to see an example, let's open this file. This file defines a default user organization (users, groups, memberships/roles) of your portal. They use component-plugins which are explained later. You will see that object-param is used again.

There are two collections: The first collection is an ArrayList. This ArrayList contains only one value, but there could be more. The only value is an object which defines the field of the NewUserConfig$JoinGroup bean.

The second collection is a HashSet that is a set of strings.

      <description>this listener assign group and membership to a new created user</description>
          <object type="org.exoplatform.services.organization.impl.NewUserConfig">
            <field  name="group">
              <collection type="java.util.ArrayList">
                  <object type="org.exoplatform.services.organization.impl.NewUserConfig$JoinGroup">
                    <field  name="groupId"><string>/platform/users</string></field>
                    <field  name="membership"><string>member</string></field>
            <field  name="ignoredUser">
              <collection type="java.util.HashSet">

Let's look at the org.exoplatform.services.organization.impl.NewUserConfig bean:

public class NewUserConfig {

  private List    role;
  private List    group;
  private HashSet ignoredUser;
  public void setIgnoredUser(String user) {
  static public class JoinGroup {
    public String  groupId;
    public String  membership;

You see the values of the HashSet are set one by one by the container, and it's the responsibility of the bean to add these values to its HashSet.

The JoinGroup object is just an inner class and implements a bean of its own. It can be accessed like any other inner class using NewUserConfig.JoinGroup.

Copyright ©. All rights reserved. eXo Platform SAS
blog comments powered byDisqus