Okapi Framework - Developer's Guide
When coding a component of the framework, try to respect the following guidelines:
Generally use the Java classic conventions described at: http://java.sun.com/docs/codeconv/
Checked exceptions are often not well suited for a component-based system like the Okapi Framework. Avoid them when possible.
When throwing exceptions, if possible use the appropriate common exception
defined in the
If you have a need for a new type of exception and use it in different packages, add it to the set of common exceptions. If that exception is specific to a package, declare it within that package.
All Okapi components use SLF4J for logging. This allows server side users to bind to the prefered logger, even implementing their own.
import org.slf4j.Logger; import org.slf4j.LoggerFactory; private final Logger LOGGER = LoggerFactory.getLogger(getClass());
For the decision to use non-static loggers see this discution.
What level to use when logging:
||Very severe error events that will lead the application to abort. Since Okapi is used server side we should probably never do this.|
||Errors the end user should see.|
||Important alert messages the end user should see.|
||Additional log information, progress, etc. These messages are also shown to the user.|
||Extra, less important information. The end user may choose to see them.|
||Debug information. For developers.|
Most classes of the framework should have a corresponding JUnit test class that exercise most of its methods.
All Classes, public and protected methods should have
comprehensive JavaDoc comments. Java packages may optionally have JavaDoc by including a