Changes for page Your First Deployment
Last modified by Pascal Robert on 2013/04/21 13:53
From version 9.1
edited by Pascal Robert
on 2012/01/08 16:28
on 2012/01/08 16:28
Change comment:
There is no comment for this version
Summary
-
Page properties (2 modified, 0 added, 0 removed)
Details
- Page properties
-
- Author
-
... ... @@ -1,1 +1,1 @@ 1 -XWiki.pr obert1 +XWiki.prabier - Content
-
... ... @@ -2,6 +2,8 @@ 2 2 Work in progress\! 3 3 {{/warning}} 4 4 5 +\\ 6 + 5 5 {{toc}}{{/toc}} 6 6 7 7 = Introduction = ... ... @@ -20,7 +20,7 @@ 20 20 21 21 = Building the "products" = 22 22 23 -When you run your projects inside Eclipse, t heyuse the incremental builder and the "internal builds" are not ready for deployment (e.g. don't use the build from the "build" folder of the project, it's not a complete build). You need to use Ant or Maven to actually build a full "product". Let's focus on Ant because, again, this is what the majority use. You can also use Jenkins, but Jenkins will need to call Maven or Ant to build the projects anyway.25 +When you run your projects inside Eclipse, it uses the incremental builder and the "internal builds" are not ready for deployment (e.g. don't use the build from the "build" folder of the project, it's not a complete build). You need to use Ant or Maven to actually build a full "product". Let's focus on Ant because, again, this is what the majority use. You can also use Jenkins, but Jenkins will need to call Maven or Ant to build the projects anyway. 24 24 25 25 One important thing to remember is that you need to build and install the frameworks before your build your applications. Building your applications will NOT add the frameworks to the product if you didn't build the frameworks first. So let's build and install the **BlogCommon** framework first. 26 26 ... ... @@ -40,19 +40,19 @@ 40 40 41 41 We are now ready to install the deployment tools. The wiki have installation instructions for many platforms, so jump over to the instructions for your deployment platform. Running the deployment tools (at least wotaskd and the Apache module) is also useful on your development machine. 42 42 43 -* [[Installing on Mac OS X>> WO:Deploying on Mac OS X Server]]44 -* [[Installing on Linux>> WO:InstallingWebObjects 5.4on Linux]]45 -* [[Installing on Windows>> WO:Deploying on Windows]]46 -* [[Installing on FreeBSD>> WO:Deploying on FreeBSD 8.2 and WebObjects 5.4.3]]45 +* [[Installing on Mac OS X>>Deploying on Mac OS X 10.6 (Snow Leopard)]] 46 +* [[Installing on Linux>>Deploying on Linux]] 47 +* [[Installing on Windows>>Deploying on Windows]] 48 +* [[Installing on FreeBSD>>Deploying on FreeBSD 8.2 and WebObjects 5.4.3]] 47 47 48 48 = Configuring the applications with JavaMonitor = 49 49 50 -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 inthe following remote directory: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: 51 51 52 52 * /Library/WebObjects/Applications (on OS X) 53 53 * /opt/Local/Library/WebObjects/Applications (on other UNIX systems than OS X, like Linux, BSD or Solaris) 54 54 55 -Copy the **BlogRest-Application.tar.gz** archive into the correct directory from the above list and uncompressed it (//tar zxf BlogRest-Application.tar.gz//). Doing thiscommandwill resultina new directorycalled **BlogRest.woa**.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**. 56 56 57 57 One last step to do for the application. Usually, the application will run with the //appserver// user and the //appserveradm// group. You need to make sure that either the group or the user can run the application. The best way to do this is to change the group of the files to be //appserveradm//. Your user on the deployment server should also be part of that group. To change the group: 58 58 ... ... @@ -69,9 +69,9 @@ 69 69 70 70 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**. 71 71 72 -Everything on the file system is ok, the next step is to add the application to JavaMonitor. If the development tools have been installed correctly, JavaMonitor will run on port 56789 on your deployment server. For example, if the DNS name of your deployment server is my.host.com, the URL will be http: ~/~/my.host.com:5678974 +Everything on the file system is ok, the next step is to add the application to JavaMonitor. If the development tools have been installed correctly, JavaMonitor will run on port 56789 on your deployment server. For example, if the DNS name of your deployment server is my.host.com, the URL will be [[http://my.host.com:56789]] 73 73 74 -After the **Add Application Named** label, enter **BlogRest** into the text field and click **Add Application**. 76 +After the **Add Application Named** label, enter **BlogRest** into the text field and click **Add Application**. 75 75 76 76 You will get to a page where you need to specific the path to the launch script inside the application bundle. If the development server is on OS X, the path will be: 77 77 ... ... @@ -89,17 +89,17 @@ 89 89 90 90 Put that path in the text field next to the **Unix** label. 91 91 92 -It would also be useful to log problems to a log file. For now, we will put the log into ///tmp//. That means that the log will be lost when you reboot the server or if you have tools like WebMinthat cleans///tmp// every day, but for now it would do the job.94 +It would also be useful to log problems to a log file. For now, we will put the log into ///tmp//. That means that the log will be lost when you reboot the server or if you have tools that clean the ///tmp// directory every day, but for now it would do the job. 93 93 94 -To specif icthe path to the log file, go to the **Output Path** section and enter ///tmp// in the text field next to **MacOSX** (if your deployment box is on OS X) or next to **Unix** (if your development is UNIX but not OS X).96 +To specify the path to the log file, go to the **Output Path** section and enter ///tmp// in the text field next to **MacOSX** (if your deployment box is on OS X) or next to **Unix** (if your development is UNIX but not OS X). 95 95 96 -The next step is to click on the **Push All** button. Now, we can add instances of the application. To do so, click on the **Detail View** link. 98 +The next step is to click on the **Push All** button, which saves the application configuration. Now, we can add instances of the application. To do so, click on the **Detail View** link. 97 97 98 -You will see a section saying //Add: 1 instance(s) on host://. Click the **Add** button. That will add one instance of the application. It's possible to run multiple instances of an application, mainly to load balance requests and also to have other working instances in case an instance is going AWOL. But for now, running one instance is enough.100 +You will see a section saying Add: 1 instance(s) on host: . Click the **Add** button. That will add one instance of the application. It's possible to run multiple instances of an application, mainly to load balance requests and also to have other working instances in case an instance is going AWOL. But for now, running one instance is enough. 99 99 100 -If the application was started, a link on the application name will appear after 30 seconds in JavaMonitor. If a link don't appear after a minute and the status is still **STOP**, something is wrong. Check the log that was created in /tmp (the log should be /tmp/WOCommunity-1) to check for any errors.102 +If the application launches successfully, a link on the application name will appear after 30 seconds in JavaMonitor. If a link does not appear after a minute and the status is still **STOP**, something is wrong. Check the log that was created in /tmp (the log should be /tmp/WOCommunity-1) to check for any errors. 101 101 102 -If the log don 't even exist, 99% of the time, the problem is file permissions. Make sure that the launch script for the application (BlogRest.woa/BlogRest) is accessible for the **appserver** user. If the file permissions are ok, you can launch the script manually with the **appserver** user by doing:104 +If the log file does not exist, 99% of the time, the problem is file permissions. Make sure that the launch script for the application (BlogRest.woa/BlogRest) is accessible for the **appserver** user. If the file permissions are ok, you can launch the script manually with the **appserver** user by doing: 103 103 104 104 On OS X: 105 105 ... ... @@ -121,4 +121,4 @@ 121 121 122 122 {{/code}} 123 123 124 -If the application can start from the command line, it should start by the development tools too. If you see errors when launching the application by command line, fix them and try to launch it by command line again. 126 +If the application can start from the command line, it should start by the development tools too. If you see errors when launching the application by command line, fix them and try to launch it by command line again.