Back to Home


Downloads    FAQ

Portal Packages
CVS Repository
Aglets SDK
Mailing Lists

Can I run Aglets on Java 2 (JDK1.2 +)?

Yes. However, getting Aglets working with Java 2 is somewhat tricky. Your best bet is to download the Aglets 1.2 Dev file release from the SourceForge project and follow these instructions.

Are there any archives of the Aglet Mailing list?

The current Aglet mailing lists are archived on SourceForge. An archive of an earlier aglet list exists at

I need some help! What should I do?

Just a quick note about asking for help with Aglets. If you do have a problem, try to include as much information as possible so that those of us who might know the answer can get straight to the root of the problem.

You first recourse is read this FAQ and the FAQ at the Aglet site.

If you do not find your answer there and decide to post to one of the mailing lists, please make sure you include as much information as possible. For example:

OS: Win98
JDK version: IBM 1.1.7
ASDK version: 1.0.3
AP: E:\Aglets1.0.3\public
AEP: E:\Aglets1.0.3\public
CP: E:\jdk1.1\lib\;E:\Aglets1.0.3\lib\aglets.jar

Also, if you have an error, try to cut and paste the relevant part, and any code snippets that you think might help. We're not mind readers ;) Also, an explanation of what you are trying to achieve might be useful too.

Are there any public aglet servers I can send my aglets to?

No. However, there is work underway to establish a network of public aglet servers using software available here. If you have a publicly-addressable server free, you are a candidate for starting the network!

What's this 'HOME' variable all about?

HOME is where the ASDK stores its properties files, logs and the like. This is usually a hidden directory called .aglets. When you try to launch Tahiti you may get a message saying:

Please set HOME environment variable!

You should set this variable in the same place as you set the rest of your environment variables, ie. the same place you set AGLET_PATH. On a UNIX system this is probably already set by default and should correspond to the location of your home directory. However, if you wish to launch Tahiti from a script then you could set the variable with:

setenv HOME /path/to/where/you/want/home

On a Windows system the HOME variable might not be set by default. Once again, set this where you usually set your environment variables, usually the file called autoexec.bat. For example:

set HOME=C:\

OK, I've got Aglets working, now where can I find out some more information?

Well, Aglets comes with several useful documents which are worth a read. They are found in the AGLET_HOME/doc directory. Worth a read is the specification doc, which although is not complete has some useful information.

If you are just starting out with Aglets then why not take advantage of this tutorial from Jerry Pearson. It shows you how to get the HelloAglet running, and will take you from start to finish with good advice.

However, if you want some in-depth information then you obtain a copy of Danny and Mitsuru's book, "Programming and Deploying Java Mobile Agents with Aglets." This is the essential guide to developing mobile agents in java, and contains masses of code examples and snippet

When I try to create Writer-Aglet I get a Security Exception?

If you get the following sort of error then it is related to aglet privileges:

Writer needs to access resources that are normally blocked. You can fix this problem by altering the privileges assigned to your Aglets. Add the following line to your 'trusted' file which can be found in $HOME/.aglets/security.

You should add this to the 'untrusted' file also. For more detail, read the "Security" section in the aglet specification which can be found in the doc %AGLET_HOME%/doc/spec10.html#Security

When I try to access a local file with my aglet the server throws java.jang.SecurityException although all the necessary permissions are set?

There is a little known feature of Tahiti (OK, call it a bug ;) that when Tahiti is installed, it creates a security domain "file:///*/" and all permissions are given to this domain. It should mean that any aglet having its codebase on this machine can access any file. But it's not true. You have to create another security domain describing exactely the path to the codebase of the aglet, grant necessary permissions and then it works.

When I try to get my Aglet to access the file 'test.txt' I get a FileNotFound exception?

When attempting to open a file, any path to a file is relative to the directory from which the Aglet was created. Therefore, the solution is that you should specify the filename's ABSOLUTE path (full pathname) like this:

FileInputStream inputStream = new FileInputStream("c:/"); (UNIX)
FileInputStream inputStream = new FileInputStream("c:\\"); (PC)

Can I run Tahiti with no net connection on Win95?

Normally YES, but if you run into troubles with a standalone Win95-PC then follow this procedure:

  1. Locate the file 'hosts.sam' in the "WINDOWS" directory and rename it to 'hosts' (it is an editable ASCII-textfile).
  2. Open this file with an editor and change the line with the loopback-address '' to your desired hostname.

It can either be a single name, e.g. "fossy", or a Fully Qualified Name (FQN) like ''. Names are case-insensitive, columns are separated with tabs. The 'hosts' file is used for local resolving of IP-hostnames(IP-addresses) and the first corresponding line will be used.

In the example below '' will be the result. The other two lines are just additional examples. # fossy (this is comment!!) fossy # fossy localhost # fossy

  1. Save the file in the "WINDOWS" directory.
  2. Start Tahiti with "-resolve" option -> local 'hosts' file is used for name-resolution. (TIP: With the correctly configured 'hosts' file on your standalone Win95-System also the JDK-Debugger works well.)

I want one of my Aglets to connect to a database but when I do I get an error?
Illegal File Access: Write JdbcOdbcSecurityCheck (etc)

You need to enable JDBC as a valid action for your aglets. In Tahiti, choose the following menu option: Tools->Security Prefs. Then select Trusted in the left hand list. Select the drop down list on the right, (probably showing File System). Choose Others. Toggle on Enable JDBC.

This will allow you to use JDBC for trusted aglets. You should look into what this really means. You can find out more from the security documentation. If you don't care, enable it for Untrusted aglets too.

I want to send my aglet around to lots of different hosts and to pop up a window at each host, but when I try nothing happens, or I get an exception

A permission to create top level window (java.awt.AWTPermission("showWindowWithoutWarningBanner")) is given to any aglet in default aglets security policy. If you want to modify security preferences, do the following instructions on every host where your aglet will visit.

In the Tahiti GUI

  1. Choose Options
  2. Choose Security Preferences
  3. Select Code Base (generally, "atp://*:*/", or all if required)
  4. Select "Window" in pull-down menu
  5. Write "showWindowWithoutWarningBanner" in Name field
  6. Push "add" button
  7. Push "OK" button
  8. Select "Reboot" or "Shutdown"

Add the following lines into files "aglets.policy".

// window
permission java.awt.AWTPermission "showWindowWithoutWarningBanner";

Why would not my stand-alone server take my environment variables into account?

This is a feature of the stand-alone servers, which is they do not take the Aglets related environment variables into account by default. So one must not forget to explicitly put the AGLET_PATH and AGLET_EXPORT_PATH on the java command-line when launching a stand-alone server (as far as I know, at least).

For example under unix, if your server is called StandAloneServer:

java -Daglets.class.path=$AGLET_PATH \
-Daglets.export.path=$AGLET_EXPORT_PATH StandaloneServer

Another solution is to include it in the code of the server, with calls to the java.lang.System.setProperty() method. In the server code you should then have:

{ ...server main... }
Properties props = System.getProperties();
props.put( "aglets.class.path", );
props.put( "aglets.export.path", );
System.setProperties( props );
{ ... }

Can an Aglet perform SNMP operations?

Yes - an aglet can perform SNMP operations by using a Java class that provides SNMP operations and that can be serialized. A good package to look at is jmgmt - it is small, straightforward, and has all source included. It is available from

Good overviews of various packages can be found at:

There are a few things to watch out for with the various packages. Some of the packages are sensitive to the version of the JDK you are using - not just major revisions like 1.0 to 1.1 but minor ones like 1.1.5 to 1.1.7. Some only work with Java2 - so you can't currently use them from an aglet. Some of the packages use threading- and you have to be careful when you serialize agents that use threads.

The other big restriction on some of the packages are that they have a commercial license- even if you are doing research. You are sometimes limited in the number of active connections, distribution of the code, etc...

How can an Aglet be used as a HTTP Server?

There are at least a few options. A quick and easy way is to look at the http example shipped with the AWB. The path to the sample is: (AGLETS DIR)/public/examples/http/ There are a few restrictions to watch for with this method: you can only have one aglet "listening" at the address associated with the context- for example if Tahiti was running at atp://aglet.server:434 - you can have one aglet receive the messages from the HTTP address http://aglet.server:434/aglets/default/test/index.html

You must also set the options in Tahiti as specified in the comments. If you are coding/adapting the sample - make sure to include the line:

getAgletContext().setProperty("name.test", getAgletID());

As this is how Tahiti identifies the aglet to forward the HTTP request to.

Another option is to look at using Fiji. The disadvantage is that the status of Fiji is uncertain right now. Another option is to look at finding/coding Java classes to listen for incoming HTTP requests. There are quite a few HTTP servers written in Java out on the web. Depending on the requirements for the web server - ie response time/threading/etc , there are a few different servers to use.

A couple of things to watch out for are threading (can cause problems when you dispatch aglets) and non-serializable code. If a class used by an aglet has non-serializable code - then your aglet will throw an exception on may of the aglet operations. There is a good discussion of some of these issues in Chapter Nine of the aglets book.

Can an Aglet work with other Servers (HTTP, FTP,etc)?

There are a few aspects to communicating with other servers. For illustation- assume a simple client/server type model. A connection can be a done as a server or a client. Often the requests follow a specific protocol or API. A server responds to requests from a remote connection, and a client connects to a remote server with a request. An aglet can act as a HTTP server at a specific address by using the WebServerAglet exampe shipped with the AWB.

An aglet can really implement almost any server protocol provided that it has classes available and they are compatible with Aglet features. (ie like serialization) If you want to connect to a remote server as a client- you can code an aglet to send the specific client requests according to the specific protocol. The classes must again be compatible with Aglet features (ie serializable) So - if you wanted to use an aglet as a HTTP client, you would use a class that provides HTTP commands or connection capabilities. A good starting point would be the URL classes in the JDK. They can be used by adding:

import; import;

to your user aglet. A good JDK reference will have some examples. There are also other issues with using Aglets for more advanced operations - like setting the security policies, verifying the DNS, etc.

How does the AWB determine the hostname?

The hostname is determined by using the system name services or DNS. The AWB uses the default services and naming provided by the specific system to resolve hostnames... There are usually two main forms of a hostname. The long name is fully qualified with the domain while the short name is just the hostname.

If the aglet is only receiving a short name from the DNS - then this is the address that it will use. When the AWB queries the DNS (done internally - you never see this from a user aglet) - it uses what has been returned. Depending on the environment, some DNS setups return the fully qualified name ( or just the plain hostname (host and no

There are at least of couple of factors to start with:

  1. version of the AWB
  2. operating system running the AWB
  3. DNS resolution order

For the version of the AWB when you use the -resolve and -domain with AWB1.1beta you have to set these in a properties file as outlined in the documentation. The operating system is a key factor. The local files and DNS server setup is completely different on Windows than an Unix setup. Even between Unix systems the setup varies.

The DNS resolution order is also important. I will give an example with AWB1.1beta on Linux which will be different if you are using another platform/version in /etc/hosts I have: machine1
in /etc/nsswitch.conf I have: hosts: files dns nis

I do not have -resolve or -domain in my aglets startup script or properties.

If I run a test aglet that uses:


I will get the simple name. (machine1)

If update my /etc/hosts file to: machine1

and restart the AWB. I will get the Fully Qualified name (

If I switch my lookup order in the nsswich.conf to:

hosts: dns nis files

And restart the AWB - I will get the fully qualified name - since I have my DNS setup to give me the full name first.

So what you may be able to do is code a very small test aglet that just prints out the results of getAgletContext().getHostingURL() and then test changes on your system DNS files. (ie update the properities file, then test the hosts, then test the resolution, etc) The specific files and order will vary on the OS used so the files may not be exactly the same as my example on Linux.

Can an aglet use SSL?

For some good background information on the security model check the aglets book in Chapter 10.

For AWB1.1b1 - there is some further information in the documentation shipped with the code. The file (AGLET HOME)/doc/relnotes11b1.html has some updates about the security model. Using SSL along with the SDK and your agents seems to be straightforward - just find an open source SSL java implementation and use the classes.

On further research it looks like it is a more complicated issue that it first seems. It turns out there are several issues - licensing SSL technology, open source java classes for SSL, and Aglets SDK integration.I did a quick search on the web for some related web sites:

It looks like there was no openly available SSL implementation in Java (ExpresSSL aims to do this - but they had no code available) Although Sun includes SSL in the Java Web Server- the classes are not available for standalone use. For some of the other resources- they are targeted at JDK1.2 (java2) which is not supported with the AWB.

The other kits seem to be commerical- so you are subject to licensing costs/distribution/ other issues. For other implementations- they are currently coded in C/C++ - so it could be possible to call them but there would be some tricky technical issues.And finally - even when an open source SSL java toolkit is available- there may be problems using it along with the AWB. Many of the low-level classes used to implement the AWB are not available as source code - so you may not be able to extend the base classes to include SSL.

You may be limited to coding your own aglets to use SSL explicitly and handle the encryption/decryption in the user aglet code.

How is memory used when a message is sent between two Aglets?

For the basic case -where you are not using threads or the parallel message handling- Aglet B should block and queue the incoming messages from Aglet A, and then delivery them sequentially. A good diagram of this scenario is on pages 104-105 of the aglets book. You may have to experiment with the exact mechanics of the replies - if you know that Aglet B will send the responses sequentially you can match the replies to the requests.

For the resource questions- you can get a basic picture of the memory used at each server by using the Tahiti option "View" and then "Memory Usage". Some basic information is also available from the Virtual machine, but you will have to check for the exact API calls.

What are the internal operations involved with an Aglet?

For the transport mechanism- the high level description is in the API documents on the Aglets Web site. The low level implementationof these mechanisms may or may not be available in source format. Most of the Aglet code can be browsed if you unzip the file, but not all of the source is included. You may be able to get some idea of the low-level operations if some of the transport code has been included in the source.

A good overview of Aglet internals is presented in Chapter 9 of the Aglets book- "Inside Aglets" However, in most cases you should not need to know about how the low level implementation has been done, unless there are specific issues, or you are redefining the basic transport, or if the aglet implementation does not match the specifications....

What services does Tahiti Provide?

Tahiti is really a combination viewer/server environment (context). When you run Tahiti - you get a graphic or text interface that provides a picture of the running context. The actual low-level operations are based on the various Aglet API documents. So when you use Tahiti you are using the context provided in the background. The Aglets you see with Tahiti could not run if Tahiti did not provide a context all Aglets need a context to exist/execute in.

A sample server/context is provided with the examples shipped with the AWB. The files are usually found under:

(AGLETS DIRECTORY)/public/examples/server

The basic source files for Tahiti are also provided. You can unzip the file in (AGLETS DIRECTORY) and browse the directories:

src/com/ibm/awb/launcher src/com/ibm/aglets/tahiti

There are also other options like running Tahiti with a commandline (text gui) or detached with no gui at all. These options can be customiz ed when you call Tahiti. The actual flags and steps used differ in between AWB1.0.3 and Beta1.1. You can check the specific options in the documentation.

How can the sleep operation be used in an Aglet?

The exact behaviour will depend on where the sleep call is invoked there are at least a few different cases. It could be called from a message handling routine, from an event handler like onDisposing(), or from the main run routine in the aglet.The interesting feature to watch out for is that the sleep operation works on a thread level- while threads are usually hidden from most aglet operations. (for example the run entry point in the aglet is usually the main thread of the agent, and message handlers are done on other threads - but this implementation is hidden when the user aglet code runs)

From a few of my test aglets I found that if I called the sleep on the main run routine- all messages would block until the sleep finished. I could use a call to:


to process messages in parallel while the main run thread sleeps. The behaviour may vary depending on where the sleep call is made. You may want to build a couple of test aglets and check the exact behaviour when the sleep call is placed where you want it.

How can local and remote Aglets discover each other and communicate?

There are a few options available to attempt to discover remote contexts, depending on what you need to do:

  • Atempt to create an agent in the local (known) context and dispatch it to a context that may exist. If it does actually exist you can have this aglet return the proxies in that context. If the context does not exist, an exception will be thrown.
  • Same as the first, but use multicasting (page 110) in the aglets book to have the agents respond with their proxies
  • In Aglets1.1beta there is a new feature called the MAFFinder - this contains information about active contexts and AgletIds. The information about active contexts is available from the finder - you can see it visually with the finder viewer. The disadvantage to this approach is that I haven't seen the actual API calls to the finder documented yet, so it may be difficult to use from your own aglets
  • Build an aglet to maintain information about current proxies and contexts. I have used this approach in my research - since I started with Aglets1.0.3 when the finder was not available, and I also needed to store additional fields.

The key point to the differing approaches is that you need a way to retrieve a valid AgletID or proxy in order for any aglet to communicate with any other aglet, local or remote.