Changes for page Deployment-Book

Summary

• Page properties (1 modified, 0 added, 0 removed)

Details

Page properties

Content

...	...	@@ -5,17 +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		-For a deployment-like environment on your deployment box, JavaMonitor is not needed, but you do need wotaskd, the Web server and the module. (link to apache setup in the wiki)
	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	+ [[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]]
13	13
14	14	== Why Deployment at the Beginning? ==
15	15
16	16	You might wondering: why bother with deployment so early one? So of the reasons are:
17	17
18		-* 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.
19	19	* 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.
20	20	* You can use static content or scripts (PHP, etc.) that are not bundled in your applications.
21	21
...	...	@@ -22,7 +22,6 @@
22	22	== Structure of .framework and .woa Build Products ==
23	23
24	24	{{code}}
25		-
26	26	.framework
27	27	-> Resources
28	28	-> English.lproj, ...
...	...	@@ -37,9 +37,8 @@
37	37	-> English.lproj, ...
38	38	-> .css/.png
39	39	-> .css/.png
	41	+{{/code}}
40	40
41		-{{/code}}
42		-
43	43	{{code}}
44	44
45	45	.woa
...	...	@@ -81,61 +81,14 @@
81	81
82	82	== SSL Configuration ==
83	83
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, do the following:
	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"]].
85	85
86	86	{{code}}
87	87
88		-# sudo openssl genrsa -out /etc/apache2/localhost.key 2048
	88	+Deployment Components: JavaMonitor, Wotaskd and javawoservice
89	89
90		-# sudo openssl req -new -key /etc/apache2/localhost.key -out /etc/apache2/localhost.csr
91		-Country Name (2 letter code) [AU]: <your country code, eg: CA, US, etc.>
92		-State or Province Name (full name) [Some-State]: <full name of province or state>
93		-Locality Name (eg, city) []: <full city name>
94		-Organization Name (eg, company) [Internet Widgits Pty Ltd]: <your name>
95		-Organizational Unit Name (eg, section) []:
96		-Common Name (eg, YOUR name) []:localhost
97		-Email Address []: <your email address>
98		-
99		-# sudo openssl x509 -req -days 365 -in /etc/apache2/localhost.csr -signkey /etc/apache2/localhost.key -out /etc/apache2/localhost.crt
100		-
101		-# sudo chmod 600 /etc/apache2/localhost.key
102		-
103	103	{{/code}}
104	104
105		-You know have a self-signed certificate that will be valid for 365 days. When your certificate expires, you only need to run the last command to generate a new one, no need to recreate a key or certificate request.
106		-
107		-Now, let's add that certificate to Apache configuration. Edit /etc/apache2/httpd.conf, and at the end, add:
108		-
109		-{{code}}
110		-
111		-Listen 127.0.0.1:443
112		-NameVirtualHost 127.0.0.1
113		-<VirtualHost 127.0.0.1:443>
114		-DocumentRoot "/Library/WebServer/Documents/"
115		-ServerName localhost
116		-<Directory "/Library/WebServer/Documents/">
117		-allow from all
118		-Options +Indexes
119		-</Directory>
120		-SSLEngine on
121		-SSLProtocol +SSLv3 +TLSv1
122		-SSLCertificateFile /private/etc/apache2/localhost.crt
123		-SSLCertificateKeyFile /private/etc/apache2/localhost.key
124		-</VirtualHost>
125		-
126		-{{/code}}
127		-
128		-And restart Apache:
129		-
130		-{{code}}
131		-
132		-apachectl configtest
133		-apachectl restart
134		-
135		-{{/code}}
136		-
137		-== Deployment Components: JavaMonitor, Wotaskd and javawoservice ==
138		-
139	139	== Setting up JavaMonitor ==
140	140
141	141	== Editing spawnofwotaskd.sh ==
...	...	@@ -155,7 +155,7 @@
155	155
156	156	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:
157	157
158		-* sudo s
	111	+* sudo -s
159	159	* su - appserver
160	160	* cd /Library/WebObjects/Applications/MyApp.woa
161	161	* ./MyApp
...	...	@@ -162,7 +162,7 @@
162	162
163	163	99% of the time, that procedure will show the problems, in particular permissions and classpath problems.
164	164
165		-== Deployment alternatives (servlet, mod//proxy)// ==
	118	+== Deployment alternatives (servlet, mod_proxy) ==
166	166
167	167	== Handling Transitions between http and https ==
168	168
...	...	@@ -174,4 +174,4 @@
174	174
175	175	== Using a staging server ==
176	176
177		-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.