Home | News | FAQ | Download | Lists | Issues | ||||||||||||||||||||||||||
NAMEopenejb validate - OpenEJB Validation Tool SYNOPSISopenejb validate options jarfiles NOTEThe 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
In UNIX, Linux, or Mac OS X, the deploy tool can be executed as follows: [user@host openejb]# ./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]# 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 DESCRIPTIONThe validation tool currently checks for the following things:
More checks will be added in the future. OPTIONS
COMMON ISSUESMisslocated class or NoClassDefFoundErrorThe 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. |
||||||||||||||||||||||||||
|