Wiki Navigation

Start Page > DeployDocs > JbossConfig

Configuring jboss for bedework

The downloaded server comes with a number of pre-built configurationss, "all", "default", "minimal". These are the names of the directories found inside the server directory. default is probably fine. You may want to copy it and call it "prod" for example.

A problem with the current jboss 4.2.2-GA that I'm seeing is intermittent errors on restart. These take the form of sql errors with complaints about the statement "SELECT * FROM INFORMATION_SCHEMA.SYSTEM_TABLES" failing. A number of services then fail to start. A restart always seems to work. This may be a timing issue and is possibly related to using hypersonic as the test database for bedework.

Not working/done yet

update the following in 3.4.1.1 - buildsh.xml, config/bwbuild, many build files, BwAbstractAction? (annoying messages)
Not copying ear into deploy directory

General configuration

This is non-bedework specific. Stuff we've found worth doing.

Set java home and other options

In bin/run.conf you set all your local settings for jboss.

Set the java home.

Add something like this

#
# Specify options to pass to the Java VM.
#

case "$2" in
    'prod')
  # JAVA_OPTS="$JAVA_OPTS -Djava.io.tmpdir=$DATA_HOME/$2/tmp"
  JAVA_OPTS="$JAVA_OPTS -server"
  JAVA_OPTS="$JAVA_OPTS -Xms512m -Xmx512m"
#	JAVA_OPTS="$JAVA_OPTS -XX:NewSize=512m -XX:MaxNewSize=512m -XX:SurvivorRatio=2"
#	JAVA_OPTS="$JAVA_OPTS -XX:PermSize=128m -XX:MaxPermSize=128m"
#	JAVA_OPTS="$JAVA_OPTS -XX:+UseParallelGC -XX:+UseAdaptiveSizePolicy -XX:+AggressiveHeap"
#	JAVA_OPTS="$JAVA_OPTS -Xrunhprof:file=/tmp/prod2.hprof,interval=3600000,doe=n,format=b"
        ;;

     *)
    #    JAVA_OPTS="$JAVA_OPTS -Djava.io.tmpdir=$DATA_HOME/other/tmp"
        JAVA_OPTS="$JAVA_OPTS -Xms1280m -Xmx1280m"
        ;;
esac

The commented out bits are probably what you'd want for a production configuration. $2 is the name of the configuration you started.

Setting the temp directory may be required if you use lots of temp spoace and partition jboss is runing in is too small.

Add a server/default/webapps directory.

This can be configured in as a deployment directory and allows you to keep all local applications separate from jboss system deployments.

In server/prod/conf/jboss-service.xml add the new directory as a deploy url

      <attribute name="URLs">
         deploy/,webapps/
      </attribute>

Enable/disable hot-deployment

In common with all application servers (I believe) redeployments chew up your jvm until you get memory allocation errors. You might get away with a few but a restart after hot-deployment is generally a good idea. If you want you can disable hot-deployment by setting the value below to false.

      <!-- A flag to disable the scans -->
      <attribute name="ScanEnabled">true</attribute>

On the other hand if you do so and copy something into your deploy directory you won't find it's broken until the restart at 4am.

Make it a j2ee compliant server

In server/prod/deploy/ear-deployer.xml set Isolated to true and CallByValue? to true. CallByValue? only affects ejbs. Isolated means that each ear deployment uses it's own classloader. Different versions of libraries loaded in different ears will not conflict, unlike the case when they are all loaded with th eunified classloader.

      <!-- A flag indicating if ear deployments should have their own scoped
      class loader to isolate their classes from other deployments.
      -->
      <attribute name="Isolated">true</attribute>
      <!-- A flag indicating if the ear components should have in VM call
      optimization disabled.
      -->
      <attribute name="CallByValue">true</attribute>

Login configuration

Jboss allows many forms of authentication - the source is available for most where necessary. You configure an authentication domain in server/prod/config/login-config.xml.

You can configure ldap or db authentication. It seems there is a Yale CAS module available but filters probably work fine.

After making changes to the login-config.xml file you'll probably need to restart jboss.

Running it

cd bin
./run.sh -c prod

This specifies the prod configuration.

Bedework related configuration

Define a datasource

You define a datasource by placing files in server/prod/deploy or server/prod/webapps.

Jboss uses hsql for internal processes so it is deployed as part of the system deployment. The file hsqldb-ds.xml defines a datasource for use by the system. You could define a datasource here for use by the calendar. If you want a separate file you could call it something like cal-ds.xml and it should contain something that looks like:

<?xml version="1.0" encoding="UTF-8"?>

<!-- $Id: mysql-ds.xml,v 1.1 2002/07/22 22:57:24 d_jencks Exp $ -->
<!-- ==================================================================== -->
<!--  Datasource config for MySQL using 2.0.11 driver                     -->
<!-- ==================================================================== -->

<datasources>
  <no-tx-datasource>
    <jndi-name>CalendarDS</jndi-name>
    <connection-url>jdbc:mysql://127.0.0.1:3306/eventsdb</connection-url>
    <driver-class>com.mysql.jdbc.Driver</driver-class>
    <user-name>whatever</user-name>
    <password>whatever</password>
    <idle-timeout-minutes>15</idle-timeout-minutes>
    <metadata>
      <type-mapping>mySQL</type-mapping>
    </metadata>
  </no-tx-datasource>
</datasources>

Note this MUST be defined as a no-tx-datasource. Doing so disables auto-commits and allows rollbacks on error. Not doing so will lead to inconsistent databases.

The jndi-name should be as above unless you want to reconfigure part of the build process.

Add drivers

Put jdbc drivers into server/prod/lib

Set authentication domain in bedwork build confiuration

For a production bedework you'll want to use the production authentication domain you defined above.

The configuration domain bedework uses is set in the bedework properties file - and can be different for each application. Typically you'll use the same domain. The default is "demo" and is set with properties like

org.bedework.app.CalAdmin.security.domain=demo

For production you'll want to change that.

Using jboss for the quickstart

All these steps have been carried out in the delivered quickstart. They are here for reference.

For the quickstart we configure jboss to use the hsql configuration shown below. The configuration for bedework should reflect the port and we need to use the hsql drivers that come with jboss. To use hsqldb as a test database (not a prod db) uncomment the mbean definition in server/prod/deploy/hsqldb-ds.xml and change the db name and port if desired.

   <!-- hsqldb in server mode -->
   <mbean code="org.jboss.jdbc.HypersonicDatabase" 
     name="jboss:service=Hypersonic">
     <attribute name="Port">1701</attribute>
     <attribute name="BindAddress">${jboss.bind.address}</attribute>     
     <attribute name="Silent">true</attribute>
     <attribute name="Database">default</attribute>
     <attribute name="Trace">false</attribute>
     <attribute name="No_system_exit">true</attribute>
   </mbean>

Then above this add a datasource

   <no-tx-datasource>
      <jndi-name>CalendarDS</jndi-name>

      <connection-url>jdbc:hsqldb:hsql://${jboss.bind.address}:1701</connection-url>
      <driver-class>org.hsqldb.jdbcDriver</driver-class>
      <user-name>sa</user-name>
      <password></password>
      <min-pool-size>5</min-pool-size>
      <max-pool-size>20</max-pool-size>

      <!-- The time before an unused connection is destroyed -->
      <!-- NOTE: This is the check period. It will be destroyed somewhere between 1x and 2x this timeout after last use -->
      <!-- TEMPORARY FIX! - Disable idle connection removal, HSQLDB has a problem with not reaping threads on closed connections -->
      <idle-timeout-minutes>0</idle-timeout-minutes>

      <!-- Use the security domain defined in conf/login-config.xml -->
      <security-domain>HsqlDbRealm</security-domain>

      <!-- HSQL DB benefits from prepared statement caching -->
      <prepared-statement-cache-size>32</prepared-statement-cache-size>

      <!-- corresponding type-mapping in the standardjbosscmp-jdbc.xml -->
      <metadata>
         <type-mapping>Hypersonic SQL</type-mapping>
      </metadata>
      <depends>jboss:service=Hypersonic</depends>
   </no-tx-datasource>

The data files for hsql live inside server/prod/data/hypersonic. With the above configuration they are all named default* so, if you want to rebuild from scratch, stop jboss, remove those files and restart jboss.

As mentioned above we use the configuration domain "demo". Add that domain to server/prod/conf/login-cinfig.xml

    <application-policy name="demo">
      <authentication>
        <login-module code="org.jboss.security.auth.spi.UsersRolesLoginModule"
          flag="required">
          <module-option name="usersProperties">props/bedework-users.properties</module-option>
          <module-option name="rolesProperties">props/bedework-roles.properties</module-option>
          <module-option name="unauthenticatedIdentity">anonymous</module-option>
        </login-module>
      </authentication>
    </application-policy>

In server/prod/conf/props/ add two files bedework-users.proeprties and bedework-roles.proeprties. In the users file it contains id=password. For the roles it's id=role-list. For example, users

# users file for demo bedework calendar
douglm=bedework

and roles

(Note we don't use roles.)

# roles file for demo bedework calendar
admin=admin

Building bedework for jboss

This requires a different configuration so we should make use of the (modified) bw script. Run it as follows

./bw -bwchome "./bedework/config/bwbuild/" -bwc jboss deploy.debug

This requires that we also have the config/bwbuild directory in place.

Download in other formats:

Plain Text