version 2.4 of the Java Servlet specification, and a Java 6 runtime\r
environment. We recommend using an official Oracle Java 6 runtime\r
environment, and <a\r
-href="http://tomcat.apache.org/download-70.cgi">Apache-Tomcat</a> web application server version 7, but older Tomcat versions above 5.5 would work too.<br/>\r
+href="http://tomcat.apache.org/download-70.cgi">Apache-Tomcat</a> web application server version 7, but older Tomcat versions above 5.5 will work too.<br/>\r
<span class="attention">Please Note:</span> The JABAWS WAR is not generally compatible with older Mac systems based on the PowerPC architecture, since Java 1.6 is not available to run JABAWS.</p>\r
\r
<p>JABAWS Web Application aRchive can run on any host operating system that supports Java 1.6. However JABAWS depends on a number of third party programs which are not available for all operating systems. In particular, not all web services are currently available for MS Windows platform.\r
<p>JABAWS is distributed as a web application archive (WAR). To\r
deploy JABAWS in Apache-Tomcat - simply drop the war file into the\r
<span class="highlight">webapps</span> directory of a running\r
-Tomcat, and it will do the rest. If you used this deployment procedure, <span class="attention">do not remove</span> the jabaws WAR file, otherwise Tomcat will undeploy your application! The context path for your deployed application will be the same as the name of the war file. For example, assuming the Tomcat server is running on the <span class="hightlight">localhost:8080</span> and <strong>jaba.war</strong> file is put into the <span class="hightlight"><tomcat server root>/webapps</span> directory, the deployed application from the jaba.war file then can be accessed by this URL http://localhost:8080/<strong>jaba</strong>. </p>\r
+Tomcat, and it will do the rest. If you used this deployment procedure, <span class="attention">do not remove</span> the Jabaws WAR file, otherwise Tomcat will undeploy your application! The context path for your deployed application will be the same as the name of the war file. For example, assuming the Tomcat server is running on the <span class="hightlight">localhost:8080</span> and <strong>jaba.war</strong> file is put into the <span class="hightlight"><tomcat server root>/webapps</span> directory, the deployed application from the jaba.war file then can be accessed by this URL http://localhost:8080/<strong>jaba</strong>. </p>\r
<p>For any other web application\r
server, please follow your server's specific deployment procedure\r
for 'WAR' files. If you install JABAWS on a MS Windows machine, then\r
<h3><a name="haveexec" id="haveexec">Reuse the binaries that are\r
already in your system</a></h3>\r
\r
-<p>If you would like to use the binaries you already have then you\r
-just need to let JABAWS know there they are. To do this, edit:\r
+<p>If you would like to use the binaries you already have, then you\r
+just need to let JABAWS know where they are. To do this, edit:\r
<span class="code">conf/Executable.properties</span></p>\r
<p>When specifying paths to executables that already exist on your system, make sure you provide an absolute path, or one relative to the JABAWS directory inside <span class="highlight">webapps</span>. For example, the default path for clustalw is defined\r
as<span class=\r
"hightlight">executable.properties</span> as described above. Below are some suggestions on where you may be able to get the binaries for your system. </p>\r
<ul>\r
<li><a href="http://www.clustal.org/omega/#Download">Clustal Omega </a></li>\r
- <li><a href="ftp://ftp.ebi.ac.uk/pub/software/clustalw2/2.52/">ClustalW</a></li>\r
+ <li><a href="http://www.clustal.org/clustal2/#Download">ClustalW </a></li>\r
<li><a href="http://mafft.cbrc.jp/alignment/software/">Mafft</a></li>\r
- <li><a href="http://www.drive5.com/muscle/download3.6.html">Muscle</a></li>\r
- <li><a href="http://www.tcoffee.org/Packages/Binaries/">Tcoffee</a></li>\r
+ <li><a href="http://www.drive5.com/muscle/downloads.htm">Muscle</a></li>\r
+ <li><a href="http://www.tcoffee.org/Projects/tcoffee/#DOWNLOAD">Tcoffee</a></li>\r
</ul>\r
<h3><a name="usingWsTester" id="usingWsTester"></a>Testing JABAWS Server </h3>\r
<p>First of all make sure that Tomcat server is started successfully. If this was the case, then you should see JABAWS home page when you navigate to your Tomcat JABAWS context path e.g. <span class="code">http://myhost.compbio.ac.uk:8080/jabaws</span></p>\r
<p><strong>Using JABAWS service status checker</strong></p>\r
-<p>If you see it, then it is time to make sure that web services are working too. The easiest way to do so is to access Services Status page available from the main JABAWS web page menu. </p>\r
+<p>If you see it, then it is time to make sure that web services are working too. The easiest way to do this is to access Services Status page available from the main JABAWS web page menu. </p>\r
<p>If you need to monitor web service health automatically when the best option is to use service checker that responds with the standard HTTP status code. To access this checker use the following URL: <span class="code"><jabaws_server>/HttpCodeResponseServiceStatus</span> This page returns code 200, and no page context if all services are operational, 503 if one of the services have problems. You can also check each web service individually by providing the name of the web service to check at the end of the service checker URL like this: <span class="code"><jabaws_server>/HttpCodeResponseServiceStatus/ClustalWS</span></p>\r
<p>Upon request, the service status checker will examine the health of the ClustalWS web service only. If the service name is not valid, then the service checker will return code 400. </p>\r
<p><strong>Using command line client</strong> </p>\r
<h3><a name="diffcontexts" id="diffcontexts"/>Running many JABAWS instances on the same server</h3>\r
<p> JABAWS is supplied as a Web Application aRchive which can be dealt with as any other web applications. So it is perfectly possible to run two JABAWS instances from the same server. Just make two different contexts on your application server and unpack JABAWS in both of them. For example if your server name is http://www.align.ac.uk, and the context names are public and private. Than one group of users could be given a URL http://www.align.ac.uk/public and another http://www.align.ac.uk/private. These contexts will be served by two independent JABAWS instances, and could be configured differently. If you keep local engine enabled, make sure you reduce the number of threads local engine is allowed to use to avoid overloading the server. Alternatively two completely separate web application server instances (e.g. Apache-Tomcat) could be used. This will give you a better resilience and more flexibility in memory settings. </p>\r
<h3><a name="nocluster" id="nocluster"></a>JABAWS on a single server</h3>\r
-<p>You can run JABAWS on a single server. Obviously the capacity will be limited, but may be sufficient for a small lab. Installed on a single server, JABAWS executes tasks in parallel, so the more cores the server has the more requests it will be able to handle. </p>\r
+<p>You can run JABAWS on a single server. Obviously the capacity will be limited, but it may be sufficient for a small lab. Installed on a single server, JABAWS executes tasks in parallel, so the more cores the server has the more requests it will be able to handle. </p>\r
<h3><a name="clustsubsys" id="clustsubsys"></a>JABAWS supported cluster batch management systems </h3>\r
<p>JABAWS uses <a href="http://drmaa.org/">DRMAA</a> v. 1.0 library to send and manage jobs on the cluster. DRMAA supports many different cluster job management systems. Namely Sun Grid Engine, Condor, PBS, GridWay, Globus 2/4, PBSPro, LSF. For up to date information please consult DRMAA web site. We found that DRMAA implementation differ from platform to platform and were trying to use only the basic functions. We have only tested JABAWS on Sun Grid Engine v 6.2. Please let use know if you have any experience of running JABAWS on other platforms.</p>\r
<h3><a name="tomstopundeploy" id="tomstopundeploy"></a>Manually deploying JABAWS application on Apache-Tomcat </h3>\r
-<p>To stop Tomcat from automatically undeploying your application if the war file is removed use an explicit application descriptor. It could come in different flavors, the one I prefer if to drop a context descriptor file into <span class="hightlight"><tomcatRoot>conf/Catalina/localhost</span> directory. Name your context file the same as your application folder e.g. if you JABAWS resides in webappl/jabaws folder, then call the context file jabaws.xml. Below is an example of content this file might have.</p>\r
+<p>To stop Tomcat from automatically undeploying your application if the war file is removed use an explicit application descriptor. It could come in different flavors, the one I prefer is to drop a context descriptor file into <span class="hightlight"><tomcatRoot>conf/Catalina/localhost</span> directory. Name your context file the same as your application folder e.g. if your JABAWS resides in webappl/jabaws folder, then call the context file jabaws.xml. Below is an example of content this file might have.</p>\r
<p class="code"><?xml version="1.0" encoding="UTF-8"?><br />\r
<Context antiResourceLocking="false" privileged="true" /></p>\r
<p>This should be sufficient to prevent Tomcat from removing your JABAWS from WEBAPPS. For more information about the Tomcat deployer <a href="http://tomcat.apache.org/tomcat-6.0-doc/deployer-howto.html">read this documentation on the Apache-Tomcat web site</a>.</p>\r
<h3><a name="tomdeploy" id="tomdeploy"></a>Apache-Tomcat fails to deploy jabaws.war file </h3>\r
<ul>\r
- <li>Make sure Tomcat have sufficient access rights to read your war file. </li>\r
- <li>Restart the Tomcat, sometimes it will not since that the new war file is added without restart</li>\r
+ <li>Make sure Tomcat has sufficient access rights to read your war file. </li>\r
+ <li>Restart the Tomcat, sometimes it will not restart after the new war file is added without restart</li>\r
<li>If Tomcat still refuses to unpack the war file, unpack it manually into web application folder (the war file is just a zip archive). Restart the Tomcat.</li>\r
</ul>\r
</div><!-- content end-->\r
git://source.jalview.org / jabaws.git / commitdiff