ant-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Kyle Adams" <kad...@gfs.com>
Subject RE: <weblogic>, <classpath>, and <wlclasspath>
Date Fri, 30 Aug 2002 19:43:06 GMT
One correction - the "recap" rules should read as follows:

1) The <ejbjar> classpath needs the full classpath, including super
classes of the EJB's interfaces and weblogic classes. 
2) The <weblogic> 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 <support> element) 
3) The <weblogic> classpath should have the interfaces, at minimum. For

example, it's safe to simply place the entire directory of compiled
classes in 
this classpath. 

I left out "<weblogic>" & "<support>" in rule #2 and "<weblogic>" in
rule 
#3.

Kyle Adams
Java Developer
Gordon Food Service

>>> kadams@gfs.com 08/30/02 03:38PM >>>
*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:donal@savvion.com] 
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:ant-user-unsubscribe@jakarta.apache.org>
For additional commands, e-mail:
<mailto:ant-user-help@jakarta.apache.org>

--
To unsubscribe, e-mail:  
<mailto:ant-user-unsubscribe@jakarta.apache.org>
For additional commands, e-mail:
<mailto:ant-user-help@jakarta.apache.org>


--
To unsubscribe, e-mail:  
<mailto:ant-user-unsubscribe@jakarta.apache.org>
For additional commands, e-mail:
<mailto:ant-user-help@jakarta.apache.org>


--
To unsubscribe, e-mail:   <mailto:ant-user-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:ant-user-help@jakarta.apache.org>


Mime
View raw message