Override default properties in cal.properties
Inside the .defaults directory, next to your configuration directory, you'll find a file named cal.properties. cal.properties is referenced during the Bedework build and during deployment. You can override any of those properties by creating a cal.properties in your configuration directory and editing in the overrides. cal.properties is divided into sections with different property prefixes.
Prune the org.bedework.install property in the Install section of the file
org.bedework.install defines which applications are built and deployed to jboss. For each name on the list, there should be a corresponding section prefixed with “org.bedework.app.<name>” and also a corresponding section in the options file.
Remove any items from org.bedework.install that you don't need. For example, if you're using Bedework for public events (and not for personal calendars), you can remove UserCal from the list. You may want to remove "test and SoEDept", too. When you remove an application from the list, you can also remove the corresponding stanza further down the file, but it isn't necessary. Those lines won't be referenced.
Review the Global Section of the file
The section prefixed “org.bedework.global” defines properties global to the whole deployment process. This is the section where jboss's datasource (database) is defined. If you based your configuration on the sample configuration that corresponds to your database system, then you may not have to alter any settings in this section.
Review the Application Section of the file
The section with properties prefixed “org.bedework.app.<name>” are the application deployment properties, one section per named application.
Two properties define the project and type of application. The value of the property “org.bedework.app.<name>.project” defines which project the application is a part of. Currently these can be
- “caldav” - a caldav server
- “caldavTest” - a caldav test package
- “webapps” - a web client
- “dumprestore” - a dump/restore application
- “freebusy” - the freebusy aggregator
The value of the property “org.bedework.app.<name>.type” corresponds to the name of a subdirectory in bedework/deployment, e.g. webpublic, webadmin, etc. So to define the administrative client named CalAdmin of type webadmin we have the fragments:
org.bedework.install.app.names=...,CalAdmin,...
...
org.bedework.app.CalAdmin.project=webapps
org.bedework.app.CalAdmin.type=webadmin
Multiple versions of each application type may be deployed, each configured differently. This is of importance for calendar suites (departmental calendars).
Edit cal.options.xml
cal.options.xml contains run time properties and is divided into sections much like the properties file. Most of the options are used to set field values in named classes so that the application will load the settings only once with a single call.
It is important to set the “system” properties for a new Bedework installation. These are found in the “syspars” section of the cal.options.xml file. A number of options can be left with the default values and some are not yet implemented. The three values it is particularly important to set (and their default settings) are:
Set the default timezone: tzid property
Look for:
<tzid>America/New_York</tzid>
The tzid is the default timezone to be used for times and dates.
Set the system ID: the systemid property
Look for:
<systemid>demobedework@cal.mysite.edu</systemid>
systemid is used when generating uids for calendar entities. This name should relate to your organization for ease of identification. If you run multiple Bedework systems, use a different value for each. In addition, the systemid takes part in the creation and interpretation of calendar user addresses which appear in attendees. The part following “@” will probably be the domain to which imip messages are addressed (in some as yet undefined manner).
Calendar user addresses take the form of a “mailto:” uri so that user “testuser01” on a system configured as above would have a calendar user address of