| Red Hat Web Application Framework 6.0: WAF Installation Guide | ||
|---|---|---|
| Prev | Chapter 7. Installing WAF for Development | Next |
This section of the document does not explain how to write code; rather, it will show where to put classes, stylesheets, JSPs, and other files you create, and the ant commands used to compile and deploy them.
In /var/ccm-devel/dev/username/project-name, there is a subdirectory also called project-name that looks roughly like the following:
-r--r--r-- 1 auser ccm-deve 605 Jul 3 09:13 application.xml drwxr-xr-x 8 auser ccm-deve 4096 Jul 8 14:24 doc drwxrwxr-x 3 auser ccm-deve 4096 Jul 8 14:24 etc drwxr-xr-x 3 auser ccm-deve 4096 Jul 8 14:27 pdl drwxr-xr-x 3 auser ccm-deve 4096 Jul 8 14:27 sql drwxrwxr-x 3 auser ccm-deve 4096 Jul 8 14:32 src drwxr-xr-x 5 auser ccm-deve 4096 Jul 8 14:32 test drwxr-xr-x 8 auser ccm-deve 4096 Jul 8 14:34 web |
This directory is organized as follows:
doc holds any additional (non-javadoc) documentation you write for your application.
etc holds enterprise.init.in, the initializer file template for your application.
pdl holds WAF Persistence Definition Language (.pdl) files for your application, organized by package name.
sql holds SQL create, drop, and upgrade scripts for your application, organized by package name.
src holds the Java classes for your application, organized by package name.
test holds junit tests for your application. Writing and running junit tests is outside the scope of this document.
web holds files that are to be deployed directly to the webapp root. Examples: graphics files, CSS files, XSL stylesheets, and JSP pages. Note that the entire directory structure under web/ will be copied wholesale to the webapp, overwriting any existing project files that get in its way.
When writing code using this structure, you may import classes and pdl "models" from the prebuilt projects or applications you referenced in your project.xml file, above. Note that the structure also gives you complete freedom to overwrite code in precompiled packages or add code to precompiled packages, simply by adding a Java class in the appropriate location under src. Also note that overwriting the precompiled Java code is generally not recommended, since it will make upgrading to a new precompiled project much more difficult.
To add a Java class to your project, place it in a directory under src that mirrors its package hierarchy, following standard Java practice. For example, the com.arsdigita.kernel.ACSObject class will go in src/com/arsdigita/kernel/. To add a PDL file to your product, follow the same pattern. For SQL files, add a database-name directory under sql for each database you want your application to run on (currently "oracle-se" and "postgres" are the only options). Then put the SQL create and drop scripts for each package in a package directory under each database name. For web/, see the deployed webapp for file placement, since everything under that directory is copied directly to the webapp root.
To test the code you have written, type the ant build command while inside of your main development directory. Ant will attempt to compile your code, and will tell you if it succeeds or where it encounters problems.
Since JSPs and XSL stylesheets are processed at runtime, the "build" step has no effect on them. If you are in active development on a JSP or an XSL stylesheet, it may be more efficient to work directly in the webapp root, since a page reload will show your changes instantly. If you follow this practice, however, make sure to keep careful track of the files you have modified and transfer them to the development area when you are done (where they can be put under source control).
Once your code compiles, if you want to see it in action, you will need to deploy it to the webapp root. To do this, from your main development directory, type ant deploy. This will compile any uncompiled PDL or Java code and deploy it to the webapp root. It will also copy into place any new files in your sql/, etc/, and web/ directories.
For development, you may want to enable automatic class reloading in your resin.conf file (you can find this in /var/ccm-devel/web/username/project-name/conf). Otherwise, when you deploy new java classes to the webapp, you will need to type ccm-stop, then ccm-start to get Resin to load your new class files.
If you have unexpected problems once you have loaded your new classes, you may need to "clean" the webapp ( delete the webapp and build directories and compile everything from scratch). This is often a problem when you are moving classes from one package to another. To clean the webapp, type ant clean.
Once your code has deployed and you have tested it, you should check in (commit) your changes to the source code (under dev/username/project-name), either to the local CVS repository or to whatever external version control system you are using.
The aliases listed below are automatically created when you do ccm-profile <project-name>. If you need to work on a different project from the same shell, simply do ccm-profile <project-name> for the different project, and these aliases will change appropriately.
ccm-inst changes to your main development directory and does an ant clean and an ant deploy.
ccm-restart does a server stop, followed by a server start. Warning: using this alias may sometimes result in abandoned Oracle processes, in cases when the new server instance starts up before the old one has had a chance to finish. If you find yourself encountering this problem frequently, use the ccm-stop and ccm-start aliases listed below instead.
ccm-start sets the correct CLASSPATH for your server and starts it.
ccm-stop stops your server.
taillogs tails all the log files in your log directory. (Very handy.)
cddev changes the current directory to your main development directory.
cdweb changes the current directory to your main deployment directory.