*WARNING - LONG EXPLANATION*
After many hours spent wrestling with <ejbjar>, I think I've got a
pretty good handle on how those
nexted elements need to be set up. Here's what I've found:
The various classpath attributes within <ejbjar> and its nested
vendor-specific tags can be quite
confusing. Setting these improperly can cause a multitude of errors,
including the "Can not load super
class..." message or a failure to generate the EJB's client-jar. All of
these issues are inter-related, so I'll
address them in one answer
Since our current application server vendor is Weblogic, I'll limit the
scope of this answer to addressing
the <ejbjar> task with the nested tag. We'll start at the beginning of
creating an EJB - the generic EJB
jar. This jar contains all of the classes necessary to generate the
vendor-specific EJB, but without any
of the generated stubs produced by the vendor's EJB compiler. The
<ejbjar> task handles the creation
of this jar automatically, determining which classes are needed from
the deployment descriptor.
In Ant 1.4 and earlier *, the task did this through reflection - the
local, home, and remote interfaces were
loaded into the classpath and reflection was used to determine what
additional classes these interfaces
depended on. Thus, all of those additional classes needed to be loaded
into the classpath in order to
be located. This classpath was determined by the classpath attribute of
<ejbjar> (which could also be
set as a nested element). Thus, that classpath attribute needs to have
all of the classes in it, including
the weblogic classes. Typically this means putting the weblogic.jar
file and the directory containing all of
your compiled classes into <ejbjar>'s classpath attribute. Not having
this classpath properly set will
cause the "Can not load xxx for super class check..." errors. These
errors are not fatal, and everything
will still be generated without failure, but your EJB may be missing
some class files it needs to operate.
Now the generic jar will compile correctly - this leads us to the
vendor-specific jar. Creation of this is
controlled by the nested tag. This tag invokes BEA's weblogic.ejbc
tool, passing in the newly-created
generic jar. As of Weblogic 6, the ejbc tool throws a non-fatal error
if the EJB interfaces are in the
classpath; however, if the EJB interfaces aren't loaded by a
classloader SOMEWHERE, compilation of
the vendor-specific stubs will fail. Faced with this, the authors of
the <ejbjar> task added another
classpath attribute, called "wlclasspath". This attribute, at minimum,
should contain the weblogic
classes (ie, weblogic.jar). If support/helper classes are not included
in the generic jar, this classpath
should also include those classes. Essentially, you can put anything in
this classpath BUT the EJB's
interfaces. The standard "classpath" attribute should contain the EJB's
interfaces and any classes that
they depend on directly (superclasses, classes passed in as parameters,
or specified as the return types
of methods, etc.). If these two attributes are not set correctly, your
<ejbjar> task may fail, or your EJB's
client-jar may not get generated.
Recap time - here's a concise set of rules for setting up these
classpaths:
1) The <ejbjar> classpath needs the full classpath, including super
classes of the EJB's interfaces and
weblogic classes.
2) The wlclasspath needs weblogic classes and helper classes (ie, those
classes not explicitly declared
in the interfaces or explicitly included in the generic jar via the
element)
3) The classpath should have the interfaces, at minimum. For example,
it's safe to simply place the
entire directory of compiled classes in this classpath.
And finally, an example:
<ejbjar descriptordir="META-INF" srcdir="${stage.dir}"
classpath="${classes.dir}:${weblogic.jar}">
<include name="ejb-jar.xml"/>
<exclude name="weblogic*.xml"/>
<weblogic newCMP="true" destdir="${deploy.dir}"
wlclasspath="${weblogic.jar}" classpath="${classes.dir}"/>
</ejbjar>
Hope that helps!
Kyle Adams
Java Developer
Gordon Food Service
-----Original Message-----
From: Donal Quinlan [mailto:[EMAIL PROTECTED]]
Sent: Friday, August 30, 2002 12:08 PM
To: Ant Users List
Subject: <weblogic>, <classpath>, and <wlclasspath>
Hi,
I'm using Ant 1.4.1 and attempting to use the weblogic task. I get
warnings
about the home and remote interfaces of a bean on the system
classpath.
According to the 1.4.1 javadoc I simply need to use <wlclasspath> to
set the
standard weblogic classes. But whenever I do this and run ant -verbose
I get
NoClassDefFound exceptions. I only see jar's in the <wlclasspath> in
the log
output. Anything in <classpath> gets ignored as soon as I start using
<wlclasspath>. So what eventually happens is I put all the jars in
<wlclasspath> and end up back at square one.
Has anybody experienced this before or better yet, know of a solution?
Perhaps this is why our buildfile is using the java task to fork
weblogic.ejbc.
Thanks
Donal
--
To unsubscribe, e-mail:
<mailto:[EMAIL PROTECTED]>
For additional commands, e-mail:
<mailto:[EMAIL PROTECTED]>
--
To unsubscribe, e-mail:
<mailto:[EMAIL PROTECTED]>
For additional commands, e-mail:
<mailto:[EMAIL PROTECTED]>
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
