Title: Validation Tool

<a name="ValidationTool-NAME"></a>
# NAME

openejb validate - OpenEJB Validation Tool

<a name="ValidationTool-SYNOPSIS"></a>
# SYNOPSIS


openejb validate [options](options.html)
 jarfiles

<a name="ValidationTool-NOTE"></a>
# NOTE


The OpenEJB Validation tool must be executed from the OPENEJB_HOME
directory. This is the directory where OpenEJB was installed or unpacked.
For for the remainder of this document we will assume you unpacked OpenEJB
into the directory C:\openejb.

In Windows, the validation tool can be executed as follows:

*C:\openejb> openejb validate -help*


{warning}
There is a bug in the openejb.bat script of OpenEJB 0.9.0 that doesn't
allow you to execute the validate command as above. For that release,
Windows users can execute the following command:
*C:\openejb> bin\validate.bat -help*

{warning}


In UNIX, Linux, or Mac OS X, the deploy tool can be executed as follows:

{{[user@host openejb](user@host-openejb.html)
# ./openejb.sh validate -help}}


Depending on your OpenEJB version, you may need to change execution bits to
make the scripts executable. You can do this with the following command.

{{[user@host openejb](user@host-openejb.html)
# chmod 755 openejb.sh bin/*.sh}}


From here on out, it will be assumed that you know how to execute the right
openejb script for your operating system and commands will appear in
shorthand as show below.

*openejb validate -help*


<a name="ValidationTool-DESCRIPTION"></a>
# DESCRIPTION


The validation tool currently checks for the following things:
* Does the Jar have all the ejb-class class files
* Does the Jar have all the home class files
* Does the Jar have all the remote class files
* Is the ejb-class a sub-interface of SessionBean or EntityBean
* Is the home a sub-interface of EJBHome
* Is the remote a sub-interface of EJBObject
* Are all the methods in the remote interface implemented in the ejb-class
* Are there create methods in the home interface
* Are the create methods in the home interface implemented in the ejb-class
* Are the required post create methods in the ejb-class of EntityBeans
* Are there any create methods in the ejb-class, but not in the home
interface

More checks will be added in the future.

<a name="ValidationTool-OPTIONS"></a>
# OPTIONS


<table>
<tr><td>-v</td><td>Sets the output level to 1. This will output just the minumum details
on each failure.</td></tr>
<tr><td>-vv</td><td>Default. Sets the output level to 2. Outputs one line summaries of
each failure. This is the default output level.</td></tr>
<tr><td>-vvv</td><td>Sets the output level to 3. Outputs verbose details on each failure,
usually with details on how to correct the failures.</td></tr>
<tr><td>-xml</td><td>Outputs information in well-formed XML.</td></tr>
<tr><td>-nowarn</td><td>Suppresses warnings.</td></tr>
<tr><td>-version</td><td>Print the version.</td></tr>
<tr><td>-help</td><td>Print this help message.</td></tr>
<tr><td>-examples</td><td>Show examples of how to use the options.</td></tr>
</table>

<a name="ValidationTool-COMMONISSUES"></a>
# COMMON ISSUES

<a name="ValidationTool-MisslocatedclassorNoClassDefFoundError"></a>
## Misslocated class or NoClassDefFoundError

The short explanation is that the parent doesn't have all the classes it
needs as some of them are only in the child classloader, where the parent
can't see them.

This would occur, for example, if a class was loaded by the parent
classloader, but that class' superclass wasn't visible to the parent
classloader, perhaps because it is only in the child classloader.

Here is a more concrete example:

    public interface Person extends EJBObject {
    }
    
    public interface Employee extends Person {
    }


Ok, so when we build our ejb jar, we put both the Person and Employee
interfaces in the jar, so everything should be good (so we think). But now
let's say that for some reason the Employee interface is also in another
jar and that jar was loaded into the system classpath.

When a new classloader is create for my ejb-jar at runtime and the system
attempts to load the Employee interface, the call goes right through that
classloader and down to the system classloader. The Employee interface is
found, because it was accidentally added to that extra jar in the system
classpath. So now the system classloader goes looking for Employee's
superinterface, Person, where it immediatly blows up and throws a
NoClassDefFoundError: Person.

Most people will look at their ejb-jar and think, "But all my classes are
there!?", which is true. It really doesn't matter though, because one of
those classes is also in the parent classloader. The first call to load
that class will bypass your classloader completely and go to the parent.
Once there, it is the parent's job to find *all* the dependent classes. If
it can't ... NoClassDefFoundError.