Frequently Asked & Anticipated Questions

  1. I don't have a database - how do I get started?

    I have personally tested iGroupCal with Microsoft® Access®, Microsoft SQL Server®, MySQL®, PostgreSQL, and Hypersonic SQL/HSQLDB. As far as I know, GroupCalendar™ for Outlook® from OpusFlow only works with Access and MS SQL, so if you want to integrate with Outlook, I'd suggest you download and install Group Calendar first and then point iGroupCal at your Group Calendar database.

    If you're not using Group Calendar, you can download one of the following:

    • An Access Database (courtesy of OpusFlow)

      Extract the .mdb file and place is somewhere accessible by the Tomcat server (local drive or a network share).

    • An MS SQL script (courtesy of OpusFlow).

      Start up the Query Analyzer. Create a new database called iGroupCal, connect to it, load the script, and hit F9.

    • A MySQL script

      This script can be used with the mysql command-line tool. See the utilities page for an example of how to use the two together.

    • A PostgreSQL script

      This script can be used with the psql command-line tool. See the utilities page for an example of how to use the two together.

    The general configuration options in the iGroupCal web.xml file are essentially the same for all databases. You will find a more in-depth discussion under point 6 of the installation instructions on setting up the appropriate access. For MySQL and PostgreSQL, please refer to the database documentation for setting up database user access, creating the database, and reading the SQL script to create the tables.

    [up] Top...

  2. I downloaded the JDBC driver for my database, but what do I do with it? iGroupCal still doesn't work...

    Copy the driver jar file(s) above to the lib directory under the iGroupCal webapp folder. If you installed iGroupCal using the manager servlet deployment function, this will be ${CATALINA_BASE}/webapps/igroupcal/WEB-INF/lib. If you want to use the drivers with other servlets, you can copy the jars to ${CATALINA_BASE}/shared/lib instead.

    [up] Top...

  3. I'd like to use Oracle® or Sybase® or SQLite or <insert favourite DB here>.

    If you can find a JDBC driver for it, by all means go ahead and try it out. You may have to adapt the MySQL or PostgreSQL schema provided above for your target DB, and if you're actually using GroupCalendar, I'd advise you to check with OpusFlow as to whether your DB is supported (probably not...). If you want to share your experience (or DB schema) I'd be happy to put the information here.

    When trying out a new DB with iGroupCal, you should be aware that different DBs use different characters for distinguishing between their particular reserved words and all other words. For example, SELECT is a reserved word for all SQL databases, so you'd have trouble if you wanted to call one of your fields "Select" without indicating in some way that it was not the SQL command.

    This will almost definitely be a problem with using iGroupCal with a novel database, as some of the field names (such as "End") are reserved words for many databases.

    The way to get around this is to indicate which words are field names as opposed to DB reserved words. iGroupCal uses field markers to identify the database fields it needs. By default, it uses [] for MS SQL, `` for MySQL, and "" for PostgreSQL. If iGroupCal does not know about your DB, it does not use any field markers.

    You can override this by using an init parameter in the web.xml file called fieldMarkers. For example, if you wanted to use { and } to enclose field names, you would add

    <init-param>
	<param-name>fieldMarkers</param-name>
	<param-value>{}</param-name>
</init-param>

    to your web.xml file. Instead of {} though, your most likely candidates will be '' (a pair of single quotes) or "" (a pair of double quotes). If you are getting strange SQL exceptions referring to field names, you might want to play with this parameter.

    [up] Top...

  4. Can't I just change the field names in gcfields-mssql.xml so they don't conflict with my DB reserved words?

    Absolutely not! For the time being, the names of the fields in the database must be kept exactly as they are specified in this file and in the sample DB creation scripts.

    This file does however give you the ability to assign a different Java data type to the field. So for example you could use a BigInteger instead of an Integer, or a special String class instead of the normal String. For the most part though, you will not need to adjust this file at all.

    A future version of iGroupCal will allow you to map the field names to any DB name you like, but right now that's a low-priority fix.

    [up] Top...

  5. How do I use iGroupCal with JBoss?

    Using is JBoss is quite simple, in some ways simpler than Tomcat alone. Essentially, all you need to do is expand the igroupcal.war file into the deploy directory, and create the users and roles files.

    1. Create an igroupcal.war directory in your deploy directory. If you are running on MacOS X, this will be something like

      /Library/JBoss/3.2/server/default/deploy

      where you would replace default with the setting chosen for "Configuration Type" in the "Application Server" preference pane of the Server Manager. If you are running on Linux or another Unix you might be using something like

      /usr/local/jboss/jboss-4.0.2/server/default/deploy

      Expand the .war file you downloaded into the igroupcal.war directory you just created. The following example shows how to create the directory and expand the .war file on MacOS X, assuming you have downloaed the .war file to your Desktop (if not, replace ~/Desktop with the correct path). 

      % cd /Library/JBoss/3.2/server/default/deploy
% mkdir igroupcal.war
% cd igroupcal.war
% jar xvf ~/Desktop/igroupcal.war

    2. In the directory igroupcal.war/WEB-INF/classes you will need to create two files, users.properties and roles.properties, with the following contents:

      users.properties:
      <Username>=<Password>

      roles.properties:
      <Username>=user

      For <Username>, choose the username you want and for <Password> choose a password. Use the same username in both the users.properties and roles.properties files, but don't replace the word user that is at the end of the line in the roles.properties file - it's supposed to be there!

      You can add as many users as you like to the users.properties file but make sure you also assign them a role in the role.properties file as well. Possible roles are user, read-only, and manager. At the moment, the manager role does nothing special so it is equivalent to the user role.

      Of course, if you already have a working authentication mechanism, you can create a jboss-web.xml file in the igroupcal.war/WEB-INF directory to associate the igroupcal servlet with your authentication mechanism. Just make sure you have a user in a user/manager/read-only role.

    3. That's all you need to take care of to get the JBoss part of the installation working. Now you'll need to adjust the various parameters in the igroupcal.war/WEB-INF/web.xml file, as discussed in the steps 6 and 7 of the installation instructions.

    n.b. - both JBoss and iGroupCal use log4j for logging, but JBoss expects an XML log4j properties file, while iGroupCal uses a plain-text properties file. This will create a big long exception when iGroupCal is first started which may look bad but is quite harmless. I will fix this in a future release.

    [up] Top...

  6. Can't I use any old servlet server?

    You probably could. I just haven't tested it on anything other than Tomcat. If you'd like to share your experiences with me, I'd be happy to publish the information here. If you're having trouble with a particular container, drop me a line and I'll see if I can help out.

    Probably the trickiest thing will be to work out the authentication settings for your server of choice. If you want to publish calendars, you will have to have at least one user in a "user" or "manager" role (there's no difference between the two at the moment). To simply read the calendar, you'll need a user in the "read-only" role.

    [up] Top...

  7. I'm running Tomcat (or other servlet container) on <not Windows®> but I need to connect to an Access database!

    You will need a PC running Windows no matter what, because as far as I know there are no non-Windows JDBC drivers (i.e pure Java, or Type 4) for Access files. The Windows machine must act as an end-point for a remote JDBC connection. To set up the remote connection, you'll need to get a remote-access JDBC driver like Nogginware's RemoteDB (shareware). ObjectWeb provides a free solution based on Java RMI with their RmiJdbc driver. They even have a dedicated page for Access connections. Set up the ODBC driver on the PC, the JDBC remote connection on your non-Windows box, and use the native java drivers on your non-Windows Tomcat server. Should work like a charm...

    [up] Top...

  8. I'm running Debian and I'm getting some strange file and/or permission exceptions. What's wrong?

    The Debian Tomcat package ships with extremely restrictive security settings. This means that iGroupCal often doesn't have access to the resources it needs, including permission to write the log file in the logs directory. You will need to create a new policy file in /etc/tomcat5/policy.d and add something along the following lines. 

    grant codeBase "file:${catalina.home}/webapps/igroupcal/WEB-INF/classes/-" {
  permission java.security.AllPermission;
};

grant codeBase "file:${catalina.home}/webapps/igroupcal/WEB-INF/lib/-" {
  permission java.security.AllPermission;  
};

    The Debian Tomcat startup script concatenates all the files in the policy.d directory to create the ${CATALINA_BASE}/conf/catalina.policy file. The order of the files in the directory is important. I've created a sample iGroupCal policy file for your enjoyment.

    If you're not using Debian or a system with a similar policy setup, you can try adding the lines at the end of the catalina.policy file. You'll need to restart Tomcat.

    [up] Top...

  9. I have more than one calendar I want to keep private. Can iGroupCal do this?

    You can make any calendar you like private by using private as the last part of the base URL in the publish dialog. For example, say your calendar is "Birthdays" - for normal publication from iCal you'd use the calendar name

    Birthdays

    and the base URL

    http://server:8080/igroupcal

    and iCal would put it all together and give you the URL (which you never actually see...)

    http://server:8080/igroupcal/Birthdays.ics

    If you were using some other publishing tool, you might have to enter that full URL yourself - in iCal it's not necessary. But if you wanted to publish the calendar privately, you would use the following base URL:

    http://server:8080/igroupcal/private

    giving the full URL

    http://server:8080/igroupcal/private/Birthdays.ics

    This would make the calendar be published privately, the same as with the default "Personal" calendar.

    [up] Top...

  10. Why am I seeing every event, even my own, even though I subscribed to someone else's specific calendar?

    The whole idea of iGroupCal is to let you see everything in one single calendar. It therefore doesn't matter what calendar you subscribe to - you'll always see every appointment published.

    For example, say your colleague published a calendar as

    http://server:8080/igroupcal/funstuff.ics

    The appointments in the funstuff calendar will be integrated into the whole group calendar, so it will not be possible to subscribe to just the funstuff calendar (n.b. if you are looking for this kind of functionality, you might be better off just using a simple WebDAV server).

    When you publish a calendar in iCal, it gives you a URL to which you can subscribe to retrieve the calendar. This URL is intended for WebDAV or .Mac style servers, but will also work with iGroupCal. You just need to bear in mind that you will always get back the entire group calendar, no matter what URL you use for subscribing.

    In the future, I might extend iGroupCal to support specific calendar groups, such as "Accounting" or "Development", which will provide some aggregation functions.

    [up] Top...