Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 29 Next »

This page documents the steps taken to deploy in Wildfly 9.0.2-Final. This is not complete and, so far, bedework is not running on that platform.

This is a set of notes which should turn into instructions for configuration.

Startup

Download and unzip wildfly within the quickstart. Execute startwildfly and then create a user.

cd into the bin directory
./add-user.sh

Answer the questions - NOT in any groups, NOT being used to connect to AS server

Once created, head over to localhost:8080 and log in to the admin console.

Which configuration?

Wildfly comes with a bunch of configurations. We run a stripped down jboss 5. We probably want a stripped down wildfly. Do we use the mimimalist version? Do we strip it down ourselves?

For the moment using the full standalone version and adding stuff to standalone.xml

Replace log level in standalone.xml with properties:
	<level name="${org.bedework.log.level:INFO}"/>

Startup shell script can set runtime properties to configure the system - as it does with jboss 5.

Datasources

People are currently running bedework on postgresql, mysql, oracle and possibly sqlserver. How do we provide example configurations for these. Provide entire config files or ask them to modify their own?

Using the console seems to be reasonably easy if repetitive. The following datasources are required:

  1. java:CardDS - for CardDAV address books (use the hsql service if you don't use them)
  2. java:CalendarDS - for the main calendar engine
  3. java:EventregDS - for the event registration system
  4. java:NotifyDS - for the notification engine
  5. java:selfregDS - for the self-registration system
  6. java:SynchDS - for the synchronization engine

Add a datasource for selfreg - even if it's not being used. We may need that to handle roles - see below

  <datasource jta="true" jndi-name="java:/CalendarDS" pool-name="CalendarDS" enabled="true" use-ccm="true">
      <connection-url>jdbc:h2:tcp://localhost/CalDb</connection-url>
      <driver-class>org.postgresql.Driver</driver-class>
    <driver>h2</driver>
    <security>
      <user-name>sa</user-name>
      <password>sa</password>
    </security>
  </datasource>
<datasource jndi-name="java:/EventregDS" pool-name="EventregDS" enabled="true" use-java-context="true">
  <connection-url>jdbc:h2:tcp://localhost/EventRegDb;DB_CLOSE_DELAY=-1;DB_CLOSE_ON_EXIT=FALSE</connection-url>
  <driver>h2</driver>
  <security>
    <user-name>sa</user-name>
    <password>sa</password>
  </security>
</datasource>
<datasource jndi-name="java:/NotifyDS" pool-name="NotifyDS" enabled="true" use-java-context="true">
  <connection-url>jdbc:h2:tcp://localhost/NotifyDb;DB_CLOSE_DELAY=-1;DB_CLOSE_ON_EXIT=FALSE</connection-url>
  <driver>h2</driver>
  <security>
    <user-name>sa</user-name>
    <password>sa</password>
  </security>
</datasource>
  <datasource jndi-name="java:/selfregDS" pool-name="selfregDS" enabled="true" use-java-context="true">
    <connection-url>jdbc:h2:tcp://localhost/SelfregDb;DB_CLOSE_DELAY=-1;DB_CLOSE_ON_EXIT=FALSE</connection-url>
    <driver>h2</driver>
    <security>
      <user-name>sa</user-name>
      <password>sa</password>
    </security>
  </datasource>
<datasource jndi-name="java:/SynchDS" pool-name="SynchDS" enabled="true" use-java-context="true">
  <connection-url>jdbc:h2:tcp://localhost/SynchDb;DB_CLOSE_DELAY=-1;DB_CLOSE_ON_EXIT=FALSE</connection-url>
  <driver>h2</driver>
  <security>
    <user-name>sa</user-name>
    <password>sa</password>
  </security>
</datasource>

Then build and deploy the selfreg module

./bw -dc bedework/config/wildfly.deploy.properties -wildfly -selfreg
Hawtio

Download and deploy the hawtio war. This provides us with a jmx console. Rename downloaded file as hawtio.zip.

Remove the log4j config:

zip -d hawtio.war WEB-INF/classes/log4j.properties

 

JDBC Drivers.

It's quite possible a site will need to deploy their own to match the version of their database. We can probably add some popular ones to the quickstart but there may be version issues. Current driver jars are probably all compliant - we'll find out I guess.

The documentation DataSource+configuration provides information and links on deploying the drivers and editing the config.

Deploying the driver - an example:
Start wildfly
cd into the bin directory
./jboss-cli.sh 
You are disconnected at the moment. Type 'connect' to connect to the server or 'help' for the list of supported commands.
[disconnected /] connect
[standalone@localhost:9990 /] deploy ~/bedework/files/postgresql-9.4-1204.jdbc42.jar --name=postgresql
[standalone@localhost:9990 /]

When loaded wildfly claims the postgresql-9.3 driver to be non-JDBC-compliant. It does, however, contain the file described in the documentation and it does recognize the driver class.

The jboss documentation has this to say:

Note on MySQL driver and JDBC Type 4 compliance: while the MySQL driver (at least up to 5.1.18) is designed to be a Type 4 driver, its jdbcCompliant() method always return false. The reason is that the driver does not pass SQL 92 full compliance tests, says MySQL. Thus, you will need to install the MySQL JDBC driver as a module (see below).

Presumably the same is true of the postgresql driver.

It appears that if the exampleds is removed from the configuration deployment of the postgresql driver and datasources fails.

(Wildfly 8 note) Also the above method seems unreliable in that intermittently wildfly refuses to start because of a damaged deployment. Other deployment approaches might be more reliable.

Changes to sysevents

Because of issues with naming conventions the sysevents module optionally uses jmx to get its configuration. If that fails it falls back on sysevents.properties. That option will be removed from 4.0. It is there to preserve compatability with the jboss5 version.

Change the value of the system property:

For jboss 5
    <syseventsProperty>org.bedework.connection.factory.name=java:jms/BedeworkConnectionFactory</syseventsProperty>
For wildfly
    <syseventsProperty>org.bedework.connection.factory.name=java:/jms/BedeworkConnectionFactory</syseventsProperty>

 

JMX issues

There is a system property org.bedework.jmx.isJboss5 which is set in the jboss 5 startup and used by the JMX utility classes in the ManagementContext.registerMBean method. It's unclear if this is needed for wildfly or if it was to address a jboss5 specific issue.

Activemq

The eventual aim is to remove the dependency on activemq. While there are no code dependencies the system does use some features of activemq not present in other JMS subsystems.

Following the instructions at https://developer.jboss.org/wiki/HowToUseOutOfProcessActiveMQWithWildFly

Replaced the line:

<subsystem xmlns="urn:jboss:domain:resource-adapters:3.0"/>

with

<subsystem xmlns="urn:jboss:domain:resource-adapters:2.0">
  <resource-adapters>
    <resource-adapter id="activemq-rar.rar">
      <archive>
        activemq-rar-5.12.1.rar
      </archive>
      <transaction-support>XATransaction</transaction-support>
      <config-property name="ServerUrl">failover:(${org.bedework.activemq.uri})?timeout=3000</config-property>
      <connection-definitions>
        <connection-definition class-name="org.apache.activemq.ra.ActiveMQManagedConnectionFactory"
                               jndi-name="java:/jms/BedeworkConnectionFactory"
                               enabled="true" pool-name="ConnectionFactory">
          <xa-pool>
            <min-pool-size>1</min-pool-size>
            <max-pool-size>200</max-pool-size>
            <prefill>false</prefill>
            <is-same-rm-override>false</is-same-rm-override>
          </xa-pool>
          <timeout>
            <blocking-timeout-millis>30000</blocking-timeout-millis>
            <idle-timeout-minutes>3</idle-timeout-minutes>
          </timeout>
        </connection-definition>
      </connection-definitions>
      <admin-objects>
        <admin-object class-name="org.apache.activemq.command.ActiveMQQueue" jndi-name="java:/activemq/queue/sysevents" use-java-context="true" pool-name="syseventsQueue">
          <config-property name="PhysicalName">
            bedework.sysevents
          </config-property>
        </admin-object>
        <admin-object class-name="org.apache.activemq.command.ActiveMQQueue" jndi-name="java:/activemq/queue/syseventslog" use-java-context="true" pool-name="syseventsLoggerQueue">
          <config-property name="PhysicalName">
            bedework.sysevents.logger
          </config-property>
        </admin-object>
        <admin-object class-name="org.apache.activemq.command.ActiveMQQueue"
                      jndi-name="java:/activemq/queue/monitor" use-java-context="true"
                      pool-name="syseventsMonitorQueue">
          <config-property name="PhysicalName">
            bedework.sysevents.monitor
          </config-property>
        </admin-object>
        <admin-object class-name="org.apache.activemq.command.ActiveMQQueue"
                      jndi-name="java:/activemq/queue/crawler" use-java-context="true"
                      pool-name="syseventsCrawlerQueue">
          <config-property name="PhysicalName">
            bedework.sysevents.crawler
          </config-property>
        </admin-object>
        <admin-object class-name="org.apache.activemq.command.ActiveMQQueue"
                      jndi-name="java:/activemq/queue/changes" use-java-context="true"
                      pool-name="syseventsChangesQueue">
          <config-property name="PhysicalName">
            bedework.sysevents.changes
          </config-property>
        </admin-object>
        <admin-object class-name="org.apache.activemq.command.ActiveMQQueue"
                      jndi-name="java:/activemq/queue/schedulerIn" use-java-context="true"
                      pool-name="scheduleInQueue">
          <config-property name="PhysicalName">
            bedework.scheduleIn
          </config-property>
        </admin-object>
        <admin-object class-name="org.apache.activemq.command.ActiveMQQueue"
                      jndi-name="java:/activemq/queue/schedulerOut" use-java-context="true"
                      pool-name="scheduleOutQueue">
          <config-property name="PhysicalName">
            bedework.scheduleOut
          </config-property>
        </admin-object>
      </admin-objects>
    </resource-adapter>
  </resource-adapters>
</subsystem>

No idea what the significance of the trailing number is in the URN.

Downloaded activemq RA 5.12.1 and unzip it into a directory named activemq-rar-5.12.1.rar in standalone/deployments. This approach is based on that at https://wildflyext.gitbooks.io/wildfly-camel/content/components/camel-activemq.html

On restart force deployment by creating the empty .dodeploy file.

Access logging

Particularly useful for debugging. Go to the cli tool and enter the following:

/subsystem=undertow/server=default-server/host=default-host/setting=access-log:add
/subsystem=undertow/server=default-server/host=default-host/setting=access-log:write-attribute(name=pattern, value="%h %l %u [%t] \"%r\" %s %b \"%{i,Referer}\" \"%{i,User-Agent}\"")

Provided by http://www.nailedtothex.org/roller/kyle/entry/configuring-wildfly-as-a-standalone

Build timezone server

Needed before the calendar engine can be built

./bw -dc bedework/config/wildfly.deploy.properties -wildfly -tzsvr
Building bedework

Build bedework and specify the wildfly properties file

./bw -dc bedework/config/wildfly.deploy.properties -wildfly deploy

The post build deployer will remove the jboss-service.xml file from the ear as that is no longer appropriate.

Deploy

Copy or deploy the exploded ear into the deployment directory and create a .dodeply:

cd <wildfly>
cp -rp <quickstart-3.10>/jboss-5.1.0.GA/server/default/bwdeploy/bwcal-3.10.0.13.ear standalone/deployments/
touch standalone/deployments/bwcal-3.10.0.13.ear.dodeploy
Static content

Does this make sense?

I would recommend you to bypass redeployment if you are working lots on static content and just configure file handler to serve your custom path directly from disk.
 
just add handler like this in undertow subsystem

<file name="static-content" path="/path/on/disk/for/static/content" />
and then under host you can just add it like this:

  <location name="/static" handler="static-content" />
Authorization and roles

Needs the following in web.xml - don't know at the moemnt if it works in jboss 5

<security-role>
  <role-name>*</role-name>
</security-role>

without this we get forbidden

It's running

At that point it seems to deploy correctly and we can log in.

 

  • No labels

Bedework Enterprise Calendar Server, version 3.10