Page Comparison

...

Edit the file to set the values needed for your deployment. You may find you don't need to change much. At the start of the file are properties defining the input, and intermediate directory and the deployment directory. you may want to change the final property if you want to deploy the resulting ears yourself.

The property values may themselves contain property references of the form "${" followed by property name followed by "}" - the usual property replacement form. Any property within the properties file may be named. Some additional properties are added at startup - these are:

• org.bedework.global.propertiesFile - the path of the properties file

•  org.bedework.global.propertiesDir - the path of directory containing the properties file 

The following are the kind of change you may need to make.

Datasource names

You probably shouldn't change these but if necessary they are specified with the following

    org.bedework.global.jboss.db.datasource.jndiname=/CalendarDS

    org.bedework.global.jboss.carddb.datasource.jndiname=/CardDS

    org.bedework.global.jboss.synch.datasource.jndiname=/SynchDS

    org.bedework.global.jboss.eventreg.datasource.jndiname=/EventregDS

Transport Guarantees

These are what determine if connections are made over SSL or in plain-text. The two allowable values are NONE and CONFIDENTIAL. If you run jboss behind a web server such as apache - and if that web server handles ssl for you - then you don't need to modify this setting. The global default of NONE is fine. Otherwise you need to set it to CONFIDENTIAL for those applications that require SSL. You will also need to install certificates in jboss.

CAS authentication

To enable CAS authentication follow the commented out examples in the deploy.properties. There are 4 files that are required, examples are in bedework/config/examples/cas/. These files define filters, filter mappings listeners and replacement security constraints.

The post deploy process can insert these in the appropriate places. You will need to take a copy of these files and place them in an accessible location for the post-deploy. You will also need to configure the filters to refer to your application server and the cas server.

Virtual hosts

If you need to set the virtual hosts for the applications you can set them all to the same value(s) with the property

...

 Adding Calendar Suites

For example to duplicate information about Calendar Suites, see Add and Configure Additional Calendar Suites.

Each public calendar context is called a "calendar suite".  It provides full calendar navigation, control over what public events are exposed, and access control to topical areas.  Many sites may have only the one MainCampus suite.  If you want to roll out departmental public calendar suites, follow these steps.

• Duplicate the "cal" webapp

...

• .  For example, to create "soedept" in the ear "bwcal" add the property

    org.bedework.app.bwcal.copy.soedept=cal

• You then need to add any specific configuration options for that calendar suite, e.g.

    org.bedework.app.bwcal.soedept.virtual-hosts=calendars.example.com

• For each suite, you must add a configuration file named ConfigName.xml. 

...

...

• You can manually copy and edit the SoEDept.xml file found at

     jboss-5.1.0.GA/server/default/conf/bedework/client-configs/SoEDept.xml

• You must then specify the name of the configuration file for the calendar suite in the deploy configuration, e.g.

    org.bedework.app.bwcal.soedept.config.name=SoEDept

You must rebuild to generate the calendar suites.  To configure them, see Add and Configure Additional Calendar Suites