A Java style checker, checkStyle, is part of the build process. This should aid in the development of readable code. Jetspeed currently works with version 2.4 of the checkStyle. For more information see http://checkstyle.sourceforge.net. @@ -82,7 +83,7 @@

Please use spaces within method parameter lists:

-Use of brackets. Some developers have personal a preference to -how they place brackets within their source code: +

+Use of brackets. Some developers have personal a preference +to how they place brackets within their source code:

Please choose whatever style you want for new files but you should maintain the existing style of source you wish to modify.

If you have a method with multiple parameters, separate them across multiple lines.

@@ -148,40 +149,42 @@

Testing is a great way to detect and prevent bug. By automating the - testing process, the test are easy to run and identify failures. + testing process, the tests are easy to run and identify failures. Jetspeed uses the testing facilities built into Ant, primarily Cactus and JUnit.

- The name of test class should start with Test and be + The name of test class should start with Test and be
located in the package it test.
- All new functionality should include appropriate testing. This can + All new functionality should include appropriate testing. This can
be JUnit tests, Cactus tests, or both.
- Fixes should also include the appropriate testing additions - and/or changes to detect what is being fixed, i.e. modify the test to - detect the problem then fix the problem. The updated test(s) - should confirm you fixed the problem. + Fixes should also include the appropriate testing additions
+ and/or changes to detect what is being fixed, i.e. modify the
+ test to detect the problem then fix the problem. The updated
+ test(s) should confirm you fixed the problem.
Run the Required Tests after a cvs checkout, after a - cvs update, and before a cvs commit. +
Run the Required Tests after a cvs checkout, after a cvs update,
+ and before a cvs commit.
Run the appropriate tests the early and often.

+
Required Tests -

The required tests are made up of Cactus and JUnit test used to insure working, and hopefully bug free, code.

@@ -206,13 +209,13 @@
Unit Test Groups -

These are unit tests grouped logically. In some case their is a testing hierarchy. In the case of unittest-security. It is composed of the security implementation test, i.e. unittest-security-registry and unittest-security-turbine.

Below is just a sample of Unit Test Groups available

@@ -237,38 +240,38 @@ -

Cactus testing is used when rundata is required. The test usually involve generating a URL in beginTestName(). The URL is passed to a test, named testTestName(), running on a web server started by Cactus.

- The execution of Cactus test are dependent on the version of the - servlet engine. Currently their are two place in build.xml to add +

+ The execution of Cactus tests are dependent on the version of the + servlet engine. Currently there are two place in build.xml to add Cactus test.

Example of Cactus test can be found in org.apache.jetspeed.test.BasicSecurityTest and org.apache.jetspeed.template.TestJetspeedLink.

Documentation for Cactus can be found at http://jakarta.apache.org/cactus

JUnit testing is simpler the Cactus testing, in part because the do not require a web server. These test generally test small functional units, like reading a file into a data structure. Turbine services also be tested with JUnit test, see org.apache.jetspeed.services.registry.TestMarshallRegistry.

Example of JUnit test can be found in org.apache.jetspeed.services.registry.TestMarshallRegistry and org.apache.jetspeed.template.TestJetspeedLinkFactory.

Documentation for JUnit can be found at http://junit.org

@@ -277,7 +280,7 @@

Enter the property in the language propery file, org.apache.jetspeed.modules.localization.JetspeedProperty_ language.properties. All properties should be @@ -293,7 +296,7 @@ ]]> -

The following code will place the localized, based on the user's language, value into the variable title.

@@ -304,7 +307,7 @@ ]]> -

The following code will center the localized, based on the user's language, value on the resulting portlet.

@@ -315,7 +318,7 @@

Logging is very useful for diagnosing and resolving problems. As a general rule, all exceptions should be logged, and done so in the following fashion:
logger.error("What went wrong", ex);
@@ -324,17 +327,17 @@ Do not log exceptions like this: logger.error(ex); Whenever you want to log a Throwable, it should be the second parameter of your fatal/error/warn/info/debug call.

Since the new logging scheme uses Log4J, the penalty of log statements that are not actually activated, such as debug, - is negligable. However, if your log message uses String concatenation ("+"), avoid loads of objects to be garbage collected by always + is negligible. However, if your log message uses String concatenation ("+"), avoid loads of objects to be garbage collected by always checking if the particular level you are logging is enabled, by calling eg. logger.isDebugEnabled(). This is not necessary for logging simple Strings. Also, if you are building your message by concatenation, use StringBuffer and .append() instead of String and "+". Your code will be more efficient and produce less garbage.

Debug logging is intended for development and problem determination. It is not intended for use in a "normal" production environment. Therefore do not depend on important - information to be logged using debug. Do, however, add a reasonable about of debug logging in your code, expecially where + information to be logged using debug. Do, however, add a reasonable about of debug logging in your code, especially where robustness checks fail and "strange" things happen. This makes bug hunting a lot easier!
Do NOT use levels above debug, such as info, for debug messages!

@@ -348,7 +351,7 @@ logger.debug(msg.toString()); } ]]> -

The following code snippet shows how to use the new logging features.

- File structuring. Try to keep everything organized according to the - current directory structure. For example do no put documentation + File structuring. Try to keep everything organized according to the
+ current directory structure. For example do no put documentation
within the ./src/java directory.
- Try not throw a basic java.lang.Exception. All Exceptions thrown within - Jetspeed which describe an internal problem should extend + Try not throw a basic java.lang.Exception. All Exceptions thrown
+ within Jetspeed which describe an internal problem should extend
org.apache.jetspeed.util.JetspeedException (see PortletException.java)

+ +

All changes posted by non-committers should be submitted (and accepted) in form of patches. Patches can be created from root of the project using the this command:

cvs diff -u [file to be patched]

For example:

cvs diff -u cvs diff -u src/java/org/apache/jetspeed/services/registry/CastorRegistryService.java

- Cumulative patches are preferred if many files are being patched. And don't forget to - run the unit tests before submitting a patch. + + Cumulative patches are preferred if many files are being patched.
+ And don't forget to run the unit tests before submitting a patch. +

A properly structured patch can be applied using the cvs patch utility from the project's root as follows:

patch -i [patch file name] -p0

Below is an example of properly structured patch: