Context Toolkit Installation Guide
This document contains the installation guide for the Context
Toolkit. This is just one piece of the user's guide. There are two
other pieces, including a tutorial
code documentation. The installation guide contains information on
how to install the Context
Toolkit and get a simple application up and running.
Installation (updated 09/11/00)
Download and install the Java Development
Kit into a directory <JDK>. I recommend using JDK 1.2.2 or higher,
although I have used JDK 1.1 in the past. I am currently using JDK 1.3.
When/if asked if you want to install the Java Runtime Environment, select
Download the context.zip file. For now, to get the location of this file,
you must contact email@example.com.
Unzip the context.zip file into a directory <DIRECTORY>.
Add the <DIRECTORY> directory to your CLASSPATH
Move the jar files in <DIRECTORY>/context/jars to <JDK>/jre/lib/ext.
The jar files are 3rd party jar files. gwe.jar is from GWE
Technologies and provides the JDBC access to the MySQL
database. aelfred.jar is from Microstar
Software and provides XML decoding. sax.jar is from Megginson
Technologies and provides support for multiple XML decoders. ntp.jar
is from Limburgs
Universitair Centrum and provides support for talking to a Network
Time Protocol server. To retrieve ntp.jar, unzip the Ntp.zip file. All
of the jar files are free to use and redistribute.
Add these jar files to your CLASSPATH explicitly. Not sure why this step
is needed - jar files in <JDK>/jre/lib/ext are supposed to be placed
automatically in your classpath, but it doesn't seem to work anymore.
Modify the name of the Network Time Protocol server used in context.arch.widget.OffsetThread
to a local NTP server. Currently, the server is set to ntp1.gatech.edu.
You'll get a faster response, if you use an NTP server that is fewer network
hops from your installation location.
Running a Simple Application (updated 09/12/00)
To run this application, you don't need to have a networked machine. A
network is only required if you want to run the components on different
machines, or if you set the widget to use database storage (change false
to true in the widget invocation below)
In one window, run the widget:
To see the widget's parameter list: java context.arch.widget.WPersonNamePresence2
Run the widget: java context.arch.widget.WPersonNamePresence2 test
The widget should load a GUI (6 buttons)
In another window, run the application:
SimpleApp.class is missing from the distribution. You can download it here
and put it in context/apps/PersonPresenceApp or compile SimpleApp.java
To see the application's parameter list: java context.apps.PersonPresenceApp.SimpleApp
Run the application: java context.apps.PersonPresenceApp.SimpleApp
test 5001 127.0.0.1 5000
The application will subscribe to the widget
Now interact with the widget's GUI, pressing buttons to simulate the coming
and going of various people. On the application window, you should see
print statements showing the results of the subscription callbacks.
Now, I suggest looking at the other applications in the context.apps.PersonPresenceApp
package. These applications demonstrate how to use various features
of the Context Toolkit.
You probably can't actually run these applications directly, because the
widgets they communicate with, require a Java
iButton as the sensor. They can be modifed quite easily to run with
widget that uses a GUI as a sensor, but this hasn't been done yet. You
would just have to modify the widget id that the applications are currently
using to match that of WPersonNamePresence2. Here are some features of
the other applications:
Finally, take a look at the context.apps.InOutBoard
package. This contains the In Out Board application. It is actually
much less complex than PersonPresenceApp, in terms of the communication
it has with a widget, but it is a more realistic application. We have been
running a version of this application for over 2 years. It, too, should
be easy to modify to work with the WPersonNamePresence2 widget class.
PersonPresenceApp demonstrates almost every feature in BaseObject that
can be used when communicating with a widget.
TestApp adds to PersonPresenceApp by also demonstrating BaseObject feature
that can be used when communicating with an interpreter.
ContactPresenceApp demonstrates how you can interact with a widget that
uses nested context attributes.
UserApp demonstrates how to use BaseObject to communicate with a server.
iButton installation (updated 09/11/00)
If you want to run the other applications, you need to either modify them
to work with the WPersonNamePresence2 widget (it uses a GUI as a sensor,
rather than an iButton) or buy some iButton hardware and install the iButton
software. Here are some instructions to do the latter:
Buy a Java-Powered iButton and a Serial (or Parallel) Connectivity Pack
from Dallas Semiconductor's iButton site
Download and install the IDE
for the Java-Powered iButton. I had a non-obvious problem when I installed
this new IDE, whose solution I later found in the FAQ. If you're using
JDK 1.2.2 or higher (anything that automatically uses HotSpot), and you
want to use HotSpot, you need to edit your opencard.properties file. This
file should be in your <JDK>/jre/lib directory. Remove the "_LEGACY"
from each uncommented line in the file. If you'd prefer not to use HotSpot,
leave the file as is, but you need to run java with the "-classic" flag.
See the iB-IDE
FAQ for more information on this.
Run the test program we provide: java context.arch.generator.TestIButton
As you dock and remove your iButton, the test program will print out the
id of the iButton
The widgets and applications that make use of the iButton should all work
If you want to build any kind of complex application, you almost for sure
require context storage. Unfortunately, the only storage mechanism we provide
makes use of the MySQL database. You can either provide your own implementation
of context storage (as it was made to be easily pluggable into the Widget
architecture) or you can set up your own MySQL installation. To do the
Download and install the MySQL database.
It is free for almost all uses. It is available for many operating systems.
Follow the installation directions, and create a user account and database
You will then need to modify and recompile the context.arch.storage.StorageObject
class. You will need to redefine the following constants:
SERVER to be the name of the machine you are running MySQL on
PORT to be the port number you are running the MySQL daemon on
USER to be the user account you are using for your context work
PASSWORD to be the password for this user account (Yes, this is not a secure
method for sending your password!)
The widgets and applications that make use of context storage should all
To run a widget so that it uses storage, don't pass in a value for the
parameter, or pass in true. This will tell the widget to use the
default storage mechanism.
Currently, the default storage mechanism is set to write to the database
every time it receives 2 pieces of information from its sensor. To modify
this flushing condition, edit context.arch.storage.VectorStorage
(the default storage mechanism implementation):
To change the number of pieces of information to be received between flushing,
change the value of DEFAULT_FLUSH_CONDITION
To change the flushing condition to be time based, rather than data-based
(i.e. flush every x milliseconds), change the value of DEFAULT_FLUSH_TYPE
from DATA to TIME, and change the value of DEFAULT_FLUSH_CONDITION to be
the number of milliseconds desired between flushes
Back to the User
Last Modified: February 29, 2000
Comments to: firstname.lastname@example.org