Configuring SPADE to Confirm Transfers Using Email

This article explains how to configure a SPADE deployment so that it's transfer confirmations are sent and received over email.


It is assumed that the nest-spade-war project has been install and running as outlined here, and that the log output of the JBoss server can be seen in a second terminal.

As this scenario uses an email account to communicate confirmation information, you will need to have exclusive access to such an account. Hopefully you will either create, or have created for you, such an account as setting up a email server for testing is beyond the scope of this documentation at present.

It is also helpful if you have at least read the Local Warehouse scenario in order to familiarize yourself with the concepts discussed there as they will be re-used here. Moreover, as this scenario builds upon the SCP Transfers scenario to provide data, you should work through that one first.

Also, as in that scenario, the following environmental variables need to be set. They are show here being set to their standard values.

export JBOSS_HOME=${HOME}/server/jboss-as-7.1.1.Final
export SPADE_VERSION=2.2.0
export SPADE_WAR_HOME=${HOME}/nest-spade-war-${SPADE_VERSION}


In previous scenarios SPADE has confirmed its transfers to itself by use of a URL. However when dealing with transfers to other hosts, exposing this URL safely is not trivial. (It can be done and the desciption of one possible technique will be added when time permits.) A simpler way to confirm transfers from one deployment to another is to use email. This is easier to set up and has a built-in store-forward mechanism to deal with those times when the other deployment is not reachable.

For a SPADE deployment to use email you need to provide it with a JavaMail properties file. Full details of the contents of such as file can be found elsewhere, but the following commands will place an example file in the correct place with suitable privileges (as it will contain a password!).

cp ${SPADE_WAR_HOME}/src/main/extras/examples/ ~/spade/
chmod 600 ~/spade/

You will need to edit this file and provide the appropriate information for all values enclosed by angle brackets.

This example file is set up to use secure sockets to access the incoming and outgoing email servers. This means thet you will need to make sure that JBoss has access to those server's certificates. Information on how to set this up for JBoss can be found here, while management of the certificates is covered here. You need to remember at this point that if you have modified the file in order to handle certificates then you will need to stop and re-start the server before proceding.

In order for SPADE to send its confirmations via email you need to remove the verifyUrl element specified in the spade.xml file, otherwise SPADE will continue to send confirmations to that URL rather than via emai. Also, while editing the spade.xml file, you should take this opportunity to make sure the deployment's identity in its spade.xml file (specified in the neighbor elements in that file) matches that specified by the "mail.from" property in the file. If it does not, now is the time to fix that oversight.


Execution of this scenario is almost the same as the scenario upon which it is built, namely the SCP Transfers scenario. The difference being the additional use of the readEmail command to force the deployment to read its email. (This is normally done every 15 minutes.) The following commands show how to run the whole scenario.

${JBOSS_HOME}/bin/ --connect --command="deploy \
    --name=spade.war ${SPADE_WAR_HOME}/target/spade-${SPADE_VERSION}.war"
mkdir -p ~/spade/dropbox/mock
cat > ~/spade/dropbox/mock/ << EOF
put some junk in here
touch ~/spade/dropbox/mock/mock.4.lem
# Wait for the "finisher" for this file to stop, e.g. 5 seconds
sleep 5
# Wait for the "finisher" for this file to stop, e.g. 5 seconds
sleep 5
# Wait for the email system to handle the email, e.g. 5 seconds
sleep 5
find ~/spade/warehouse -name "mock.4.*"


Having successfully completed this scenario you should now undeploy the application using the following command.

${JBOSS_HOME}/bin/ --connect --command="undeploy spade.war"