Skip to Content

Changes for page Your First Deployment

Last modified by Pascal Robert on 2013/04/21 13:53
From version 15.1
edited by Bastian Triller
on 2013/04/21 13:05
Change comment: There is no comment for this version
To version 14.1
edited by Philippe Rabier
on 2012/12/05 12:01
Change comment: grammar

Summary

Details

Page properties
Author
... ... @@ -1,1 +1,1 @@
1 -XWiki.btriller
1 +XWiki.prabier
Content
... ... @@ -12,11 +12,11 @@
12 12  
13 13  We will focus on the classic tools since this is the method that the majority of the community use. The classic deployment tools consists of:
14 14  
15 -* wotaskd. A daemon that acts as a watchdog to send lifebeat to the applications its manage + launching and stopping applications. Source code is available and it's actually a Project Wonder application
15 +* wotaskd. A daemon that act as a watchdog to send lifeboat to the applications its manage + launching and stopping applications. Source code is available and it's actually a Project Wonder application
16 16  
17 -* Module for your Web server software (Apache or IIS). If a module doesn't exist for your preferred Web server, you can use a CGI.
17 +* Module for your Web server software (Apache or IIS). If a module don't exist for your preferred Web server, you can use a CGI.
18 18  
19 -* JavaMonitor. A Web GUI to manage wotaskd configuration (which is a XML file). It's optional, and you can manage multiple instances of wotaskd with a single JavaMonitor installation. JavaMonitor also has REST APIs so that you can manage the configuration by command-line or by a JavaScript app.
19 +* JavaMonitor. A Web GUI to manage wotaskd configuration (which is a XML file). It's optional, and you can manage multiple instances of wotaskd with a single JavaMonitor installation. JavaMonitor also have REST APIs so that you can manage the configuration by command-line or by a JavaScript app.
20 20  
21 21  But first, we need to actually make our projects ready for deployment.
22 22  
... ... @@ -52,7 +52,7 @@
52 52  Before adding the application into JavaMonitor, you have to copy the applications on the deployment server. You can use any tools that you usually use to copy files on the remote server (scp, rsync, CyberDuck, etc.). Usually you need to copy the application to the following remote directory:
53 53  
54 54  * /Library/WebObjects/Applications (on OS X)
55 -* /opt/Local/Library/WebObjects/Applications (on UNIX systems other than OS X, like Linux, BSD or Solaris)
55 +* /opt/Local/Library/WebObjects/Applications (on other UNIX systems than OS X, like Linux, BSD or Solaris)
56 56  
57 57  Copy the **BlogRest-Application.tar.gz** archive into the correct directory from the above list and uncompressed it (//tar zxf BlogRest-Application.tar.gz//). This will create a new directory named **BlogRest.woa**.
58 58  
... ... @@ -67,7 +67,7 @@
67 67  Usually, the Web server resources goes to:
68 68  
69 69  * /Library/WebServer/Documents/WebObjects (on OS X)
70 -* /opt/Local/Library/WebServer/Documents/WebObjects (on UNIX systems other than OS X, like Linux, BSD or Solaris)
70 +* /opt/Local/Library/WebServer/Documents/WebObjects (on other UNIX systems than OS X, like Linux, BSD or Solaris)
71 71  
72 72  Copy the **BlogRest-WebServerResources.tar.gz** archive into the correct directory from the above list and uncompressed it (//tar zxf BlogRest-WebServerResources.tar.gz//). Doing this command will result in a new directory called **BlogRest.woa**.
73 73