Developer Documentation
This documentation is currently work in progress. For support or if you have specific questions, please email Tony Burdett (tburdett@ebi.ac.uk).
The general architecture of Conan is shown in the diagram below.
Conan2 is a very typical enterprise application: there are MVC "controllers" that act as servlets, service classes behind this, and a DAO layer behind that. The controllers talk to the services to query the conan system, and create or adjust running tasks. Each service fulfils an important role in the Conan functionality, whether this is to create new tasks, adjust or querying existing submissions, start or stop daemon mode, create new users, and so on. To support persistence in the services, there are also several DAO classes which talk to a Conan database, which stores task, process and user metadata. All connections to external resources are set up by tomcat, and can be accessed by JNDI.
Conan2 makes use of spring to wire up the architecture, and uses spring-webmvc for the servlet layer. All the underlying architecture will function independently of spring, included all the mvc controllers, but the servlets are constructed using spring's annotation support. This also provides a REST-compliant API for interacting with Conan programmatically, if required.
###Tomcat Admin Conan can be deployed into a Tomcat instance, and the best way to do this is by adding a Tomcat context.xml file into the relevant directory (for Tomcat 5.5.*, this is conf/Catalina/localhost/{webappName}.xml). This context file must declare any required resources: you must have a connection to the Conan DB, a mail session to send responses, and a file resource pointing to the conan.properties file for the given environment. Your installation may need other resources too.
Conan global properties are loaded from the conan.properties file in the specified location (in context.xml). You can adjust these to match various other environment properties (for example, where processes require environment specific changes).
This all means that you should not need to change or recompile and code in order to tailor Conan to different environments. The same webapp should work for all environments with tweaks to the context xml file and different properties files.
###Conan Database Installation Conan uses an SQL database to track the progress of it's jobs. There is an SQL script in the resources/ directory of the Conan sourcecode - run this in an available database. This script has been tested on oracle but should work in other SQL databases.
###Building and Deploying Conan To build Conan from source, see the instructions for building Conan.
Deploy the Conan2 war file to Tomcat - you should be able to use the Tomcat manager page to do this, or else copy it manually. If you have a previous installation of Conan running, you may need to undeploy this instance first, and depending on whether the shutdown was clean or not, restart your tomcat Conan2 should now be up and running! If not, first check each of the steps above, then check for errors in the logs - {catalina.base}/logs/conan.log. If this doesn't help, check the setup of your Conan database.
###Administration If you are logged into Conan as an administrator, you'll see the "setup" link after the normal breadcrumbs in the top left of the page. Clicking this takes you through to the admin interface for Conan. This interface currently allows you to toggle daemon mode on and off, and change the email address where notifications are sent for any submissions created through daemon mode.