Changes for page Deployment-Book

Summary

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

Details

Page properties

Parent

...	...	@@ -1,1 +1,0 @@
1		-The WebObjects Beginner Book

Tags

...	...	@@ -1,1 +1,0 @@
1		-deployment

Content

...	...	@@ -5,19 +5,17 @@
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.
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]]
	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)
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.
	18	+* 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,6 +24,7 @@
24	24	== Structure of .framework and .woa Build Products ==
25	25
26	26	{{code}}
	25	+
27	27	.framework
28	28	-> Resources
29	29	-> English.lproj, ...
...	...	@@ -38,8 +38,9 @@
38	38	-> English.lproj, ...
39	39	-> .css/.png
40	40	-> .css/.png
41		-{{/code}}
42	42
	41	+{{/code}}
	42	+
43	43	{{code}}
44	44
45	45	.woa
...	...	@@ -81,14 +81,61 @@
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, check [[this page>>url:http://wiki.wocommunity.org/display/WO/Development-SSL+requests+via+https+protocol||shape="rect"]].
	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:
85	85
86	86	{{code}}
87	87
88		-Deployment Components: JavaMonitor, Wotaskd and javawoservice
	88	+# sudo openssl genrsa -out /etc/apache2/localhost.key 2048
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	+
90	90	{{/code}}
91	91
	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	+
92	92	== Setting up JavaMonitor ==
93	93
94	94	== Editing spawnofwotaskd.sh ==
...	...	@@ -108,7 +108,7 @@
108	108
109	109	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:
110	110
111		-* sudo -s
	158	+* sudo s
112	112	* su - appserver
113	113	* cd /Library/WebObjects/Applications/MyApp.woa
114	114	* ./MyApp
...	...	@@ -115,7 +115,7 @@
115	115
116	116	99% of the time, that procedure will show the problems, in particular permissions and classpath problems.
117	117
118		-== Deployment alternatives (servlet, mod_proxy) ==
	165	+== Deployment alternatives (servlet, mod//proxy)// ==
119	119
120	120	== Handling Transitions between http and https ==
121	121
...	...	@@ -127,4 +127,4 @@
127	127
128	128	== Using a staging server ==
129	129
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.
	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.//