Do I need to rebuild?
Bedework comes with a full set of demonstration web applications. If you wish to create a pruned version of the system - or add more calendar suites - you will need to rebuild with your own configuration. Note that the build configuration only affects what is built. The run-time configuration of the system is all set by the files described in Configuring Bedework
Copy the
...
Bedework uses a configuration directory to store multiple configurations. The quickstart copy of this directory is at <quickstartDirectory>/bedework/config/bwbuild.
Copy the entire directory structure – bwbuild on down – into your home directory (/home/userid on many Unix systems and C:\Users\userid on a typical Windows system). So, for example, the bwbuild directory in windows would live here: C:\Users\userid\bwbuild or here: /home/userid/bwbuild
Inside bwbuild you will find a number of example configurations in subdirectories, for example default and jboss-mysql. default is configured to use HSQL.
| Note | ||
|---|---|---|
| ||
Yes. There are hidden directories – .platform and .defaults – that must be present in your configuration directory. After you copy the bwbuild tree, you can remove any configurations you aren't using. |
| Info | ||
|---|---|---|
| ||
Yes. You may choose to copy the bwbuild directory structure to another directory. Some prefer to keep the configuration files in the vicinity of their Bedework files. If you do so, add -bwchome <config-directory> to your Bedework build commands. This will become clearer as you read on. |
Copy one of the configurations to create your own
Choose the sample configuration that is the best fit – bwbuild/default, for example, – and make a copy of the entire directory tree. You might name your copy for your organization: bwbuild/mycompany or bwbuild/myuniversity.
...
| title | bwbuild/myconfig |
|---|
...
deployment configurations properties file
The final configuration of deployed applications is set by the deployment properties file bedework/config/deploy.properties. Copy the file to some other location.
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=/EventregDSTransport 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
org.bedework.global.virtual-hosts=host1.example.com,host2.example.comor change them for one ear only e.g. for ear "bwcal"
org.bedework.app.bwcal.virtual-hosts=host1.example.com,host2.example.comor per application: e.g. for application "ucal" in ear "bwcal"
org.bedework.app.bwcal.ucal.virtual-hosts=calendars.example.comAdding Calendar Suites
For 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=SoEDeptYou must rebuild to generate the calendar suites. To configure them, see Add and Configure Additional Calendar Suites