Wiki source code of Deployment-Book
Last modified by Aaron Rosenzweig on 2012/01/23 04:38
Hide last authors
| author | version | line-number | content |
|---|---|---|---|
 |
6.1 | 1 | == Using Apache: Develop Like you Deploy == |
| 2 | |||
| |
16.1 | 3 | Most of the WebObjects deployments are done in a UNIX (Mac OS X, Linux, BSD) environments, and most of the time deployment also involve Apache httpd. Since you are probably developing your applications on a Mac OS X box and Apache httpd come bundled with it, it's really easy to setup a deployment-like setup on your development box. You can also get a small deployment environment by renting a VM on services like Amazon EC2 or Linode. |
| 4 | |||
| 5 | Deployment typically need the following tools: | ||
| 6 | |||
| 7 | * A Web server (Apache httpd) | ||
| |
19.1 | 8 | * A Web server module (mod_webobjects for Apache) |
| |
16.1 | 9 | * wotaskd |
| 10 | * JavaMonitor | ||
| 11 | |||
| |
18.1 | 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. |
| |
21.1 | 13 | [[doc:WO.Home.Deprecated.WO 5\.4 Getting Started.WebHome]] |
| |
22.1 | 14 | [[Running Through Apache - Leopard & Snow Leopard Client - Summary>>doc:documentation.Home.How-tos.Development Tools-Running Through Apache.Running Through Apache - Leopard & Snow Leopard Client - Summary.WebHome]] |
| |
16.1 | 15 | |
| |
6.1 | 16 | == Why Deployment at the Beginning? == |
| 17 | |||
| |
16.1 | 18 | You might wondering: why bother with deployment so early one? So of the reasons are: |
| 19 | |||
| |
19.1 | 20 | * You can use features like mod_rewrite, which are not available when using DirectConnect. |
| |
16.1 | 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 | * You can use static content or scripts (PHP, etc.) that are not bundled in your applications. | ||
| 23 | |||
| |
6.1 | 24 | == Structure of .framework and .woa Build Products == |
| 25 | |||
| |
21.1 | 26 | {{code}}.framework |
| |
16.1 | 27 | -> Resources |
| 28 | -> English.lproj, ... | ||
| 29 | -> ValidationTemplate.strings, Localizable.strings | ||
| 30 | -> .wo, .api | ||
| 31 | -> CustomInfo.plist | ||
| 32 | -> Info.plist | ||
| 33 | -> Java | ||
| 34 | -> Properties | ||
| 35 | -> *.eomodeld | ||
| 36 | -> WebServerResources | ||
| 37 | -> English.lproj, ... | ||
| 38 | -> .css/.png | ||
| |
21.1 | 39 | -> .css/.png{{/code}} |
| |
16.1 | 40 | |
| 41 | {{code}} | ||
| 42 | |||
| 43 | .woa | ||
| 44 | -> AppName | ||
| 45 | -> AppName.cmd | ||
| 46 | -> WOBootstrap.jar | ||
| 47 | -> Content | ||
| 48 | -> Frameworks | ||
| 49 | -> Info.plist | ||
| 50 | -> MacOS | ||
| 51 | -> MacOSClassPath.txt | ||
| 52 | -> MacOSXServerClassPath.txt | ||
| 53 | -> Resources | ||
| 54 | -> English.lproj, ... | ||
| 55 | -> ValidationTemplate.strings, Localizable.strings | ||
| 56 | -> .wo, .api | ||
| 57 | -> CustomInfo.plist | ||
| 58 | -> Java | ||
| 59 | -> *.eomodeld | ||
| 60 | -> Properties | ||
| 61 | -> UNIX | ||
| 62 | -> UNIXClassPath.txt | ||
| 63 | -> WebServerResources | ||
| 64 | -> English.lproj, ... | ||
| 65 | -> .css/.png | ||
| 66 | -> Windows | ||
| 67 | -> CLSSPATH.TXT | ||
| 68 | -> SUBPATHS.TXT | ||
| 69 | |||
| 70 | {{/code}} | ||
| 71 | |||
| |
6.1 | 72 | == WebObjects and Classpaths == |
| 73 | |||
| |
16.1 | 74 | The classpath that your applications use can be different in development and deployment, and that's one of the reasons why you should create a deployment environment early on. The WebObjects runtime includes the following directories when you deploy your applications: |
| 75 | |||
| |
6.1 | 76 | == Organizing Deployments == |
| 77 | |||
| 78 | == Apache Configuration == | ||
| 79 | |||
| 80 | == SSL Configuration == | ||
| 81 | |||
| |
19.1 | 82 | 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"]]. |
| |
16.1 | 83 | |
| 84 | {{code}} | ||
| 85 | |||
| |
18.1 | 86 | Deployment Components: JavaMonitor, Wotaskd and javawoservice |
| |
16.1 | 87 | |
| 88 | {{/code}} | ||
| 89 | |||
| |
6.1 | 90 | == Setting up JavaMonitor == |
| 91 | |||
| 92 | == Editing spawnofwotaskd.sh == | ||
| 93 | |||
| 94 | == Configuring an Application == | ||
| 95 | |||
| |
16.1 | 96 | * By using JavaMonitor's GUI |
| 97 | * By using JavaMonitor's REST services | ||
| 98 | |||
| |
6.1 | 99 | == Logging and Permissions == |
| 100 | |||
| |
16.1 | 101 | Permissions are a typical deployment problem that arise from time to time in the mailing lists. By default, on deployment boxes, applications are running under the "appserver" user, but when you upload your application to your deployment server, the script that launch your application will be owned by the user who uploaded the application and "appserver" might not be able to launch the application. If your application doesn't launch and you don't get any logging going on, good chance that the problem is related to permissions on the launch script. |
| 102 | |||
| |
6.1 | 103 | == Optimization: Adjusting Timeouts, Memory Usage, and Number of Instances == |
| 104 | |||
| 105 | == Trouble Shooting: Where to look when things go wrong == | ||
| 106 | |||
| |
16.1 | 107 | 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: |
| 108 | |||
| |
19.1 | 109 | * sudo -s |
| |
16.1 | 110 | * su - appserver |
| 111 | * cd /Library/WebObjects/Applications/MyApp.woa | ||
| 112 | * ./MyApp | ||
| 113 | |||
| 114 | 99% of the time, that procedure will show the problems, in particular permissions and classpath problems. | ||
| 115 | |||
| |
19.1 | 116 | == Deployment alternatives (servlet, mod_proxy) == |
| |
10.1 | 117 | |
| |
16.1 | 118 | == Handling Transitions between http and https == |
| |
10.1 | 119 | |
| |
16.1 | 120 | == Using Jenkins for builds == |
| 121 | |||
| 122 | Using a continuous build system is useful. Many people in the community don't even build their applications on their development boxes anymore, they use a continuous build system to build projects from a source control repository. This is even more useful if you have more than one developer working on your projects, by centralizing builds, you can detect source merge problems, etc. You can even run unit tests and do deployments from a build system. | ||
| 123 | |||
| 124 | The most popular continuous build system is Jenkins. It's an open source project build in Java, with many useful plugins. | ||
| 125 | |||
| 126 | == Using a staging server == | ||
| 127 | |||
| |
19.1 | 128 | 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. |