Changes for page Deployment-Book

Last modified by Aaron Rosenzweig on 2012/01/23 04:38

From version 18.1
edited by Pascal Robert
on 2012/01/23 04:38
Change comment: There is no comment for this version
To version 19.1
edited by Pascal Robert
on 2012/01/23 04:38
Change comment: There is no comment for this version

Summary

Details

Page properties
Content
... ... @@ -5,19 +5,19 @@
5 5  Deployment typically need the following tools:
6 6  
7 7  * A Web server (Apache httpd)
8 -* A Web server module (mod//webobjects for Apache)//
8 +* A Web server module (mod_webobjects for Apache)
9 9  * wotaskd
10 10  * JavaMonitor
11 11  
12 12  For a deployment-like environment on your deployment box, JavaMonitor is not needed, but you do need wotaskd, the Web server and the module.
13 -[[WO:WO 5.4 Getting Started]]
14 -[[Running Through Apache - Leopard & Snow Leopard Client - Summary>>Running Through Apache - Leopard & Snow Leopard Client - Summary]]
13 + [[doc:WO.WO 5\.4 Getting Started]]
14 + [[Running Through Apache - Leopard & Snow Leopard Client - Summary>>doc:documentation.Running Through Apache - Leopard & Snow Leopard Client - Summary]]
15 15  
16 16  == Why Deployment at the Beginning? ==
17 17  
18 18  You might wondering: why bother with deployment so early one? So of the reasons are:
19 19  
20 -* You can use features like mod//rewrite, which are not available when using DirectConnect.//
20 +* You can use features like mod_rewrite, which are not available when using DirectConnect.
21 21  * You can detect deployment problems early on. Nothing is worst than finding deployment problems when you deploy it and found out that you forgot a lot of things.
22 22  * You can use static content or scripts (PHP, etc.) that are not bundled in your applications.
23 23  
... ... @@ -24,7 +24,6 @@
24 24  == Structure of .framework and .woa Build Products ==
25 25  
26 26  {{code}}
27 -
28 28  .framework
29 29   -> Resources
30 30   -> English.lproj, ...
... ... @@ -39,9 +39,8 @@
39 39   -> English.lproj, ...
40 40   -> .css/.png
41 41   -> .css/.png
41 +{{/code}}
42 42  
43 -{{/code}}
44 -
45 45  {{code}}
46 46  
47 47  .woa
... ... @@ -83,7 +83,7 @@
83 83  
84 84  == SSL Configuration ==
85 85  
86 -It's useful to create a https configuration on your deployment-like setup. By doing that, you can try out switching between SSL and non-SSL and make sure that switching is working well. On your development box, no need to purchase a SSL certificate, you can create a self-signed certificate for free. To create a self-signed certificate on OS X, check [[this page>>http://wiki.wocommunity.org/display/WO/Development-SSL+requests+via+https+protocol]].
84 +It's useful to create a https configuration on your deployment-like setup. By doing that, you can try out switching between SSL and non-SSL and make sure that switching is working well. On your development box, no need to purchase a SSL certificate, you can create a self-signed certificate for free. To create a self-signed certificate on OS X, check [[this page>>url:http://wiki.wocommunity.org/display/WO/Development-SSL+requests+via+https+protocol||shape="rect"]].
87 87  
88 88  {{code}}
89 89  
... ... @@ -110,7 +110,7 @@
110 110  
111 111  The first thing to do when an application doesn't launch by JavaMonitor/wotaskd is to launch it by command line. To do so, open a command line shell, logging as the "appserver" and start the launch script manually. For example, if you have an application named "MyApp.woa" in /Library/WebObjects/Applications, do the following commands:
112 112  
113 -* sudo s
111 +* sudo -s
114 114  * su - appserver
115 115  * cd /Library/WebObjects/Applications/MyApp.woa
116 116  * ./MyApp
... ... @@ -117,7 +117,7 @@
117 117  
118 118  99% of the time, that procedure will show the problems, in particular permissions and classpath problems.
119 119  
120 -== Deployment alternatives (servlet, mod//proxy)// ==
118 +== Deployment alternatives (servlet, mod_proxy) ==
121 121  
122 122  == Handling Transitions between http and https ==
123 123  
... ... @@ -129,4 +129,4 @@
129 129  
130 130  == Using a staging server ==
131 131  
132 -It's not a requirement early on, but if your development and development environments are not alike (for example: development on OS X, deployment on Linux), you should create a staging environment that is setup exactly like your production environment. By "exactly", we means that for instance if your production environment is using CentOS 5 64bits (x86//64), your staging environment should use the same OS, and the same version of Apache, etc. A staging environment will allow your customers to try new versions of your apps without putting them on your production server, and you can detect environment-specific problems.//
130 +It's not a requirement early on, but if your development and development environments are not alike (for example: development on OS X, deployment on Linux), you should create a staging environment that is setup exactly like your production environment. By "exactly", we means that for instance if your production environment is using CentOS 5 64bits (x86_64), your staging environment should use the same OS, and the same version of Apache, etc. A staging environment will allow your customers to try new versions of your apps without putting them on your production server, and you can detect environment-specific problems.