Pardon my ignorance, but as we also face this issue, I was wondering
what the best resolution is for the time being under Ant 1.4? Is the
best workaround to simply put /bea/wlserver6.0/lib/weblogic.jar on the
system CLASSPATH, or to reference all classfiles with the <support>
element and all weblogic.jar files with the classpath parameter? Putting
weblogic.jar on the system CLASSPATH certainly makes the errors go away,
but I would prefer to handle the errors within the buildfile if



-----Original Message-----
From: Conor MacNeill [mailto:[EMAIL PROTECTED]]
Sent: Wednesday, October 24, 2001 9:33 AM
Subject: Re: ejbjar and issues with class loading?

McVeigh, Ryan wrote:

> Background info:  Ant 1.4.1, WL 6.0 SP2.
> I've got an <ejbjar ... /> tag built and I'm seeing a lot of warnings
> my classes that say something similar to:
>    [ejbjar] Could not fully load class someClassName for super class
> I see in the source for ejbjar (the GenericDeploymentTool.java file)
> this is a NoClassDefFoundError being thrown, which doesn't make sense
to me.

Let me try to explain this a little. The EJB spec says that all classes 
necessary for the EJB should be contained in the EJB jar. <ejbjar> has 
tried overtime to collect more of the necessary classes into the jar as 
per the spec. The way it achieves this at the moment is to load the bean

classes as java classes with a classloader. It then determines the 
superclasses and adds them to the jar. The NoClassDefFoundError occurs 
when the classpath given to ejbjar does not contain all of the classes 
necessary to instantiate the bean classes. This is what the "Could not 
fully load class blah" means. <ejbjar> will still beign a jar which will

probably work but it will not necessarily contain the super classes.

The <support> element provides a mechanism to add in other classes which

are necessary for the bean but which are not super classes.

Ant 1.5 will change this mechanism under the covers to actually analyse 
the bean classes at a bytecode level to determine all of the classes 
required automatically, without using reflection. This should give 
better results.

> Second issue, same email - I'm also getting the complaint from ejbc
> home and remote interfaces from a bean being in the system classpath.

Yes, this was introduced into WLS 6.0. Since <ejbjar>'s classpath 
predated this, I added a separate attribute wlclasspath which is the 
classpath to use when running the weblogic.ejbc tool. <ejbjar> still 
needs the full classpath since it is doing its bean check thing, 
described above.

> Clearly that has something to do with the classpath and wlclasspath
> attributes to the weblogic element.  My build.destdir property is the
> output of all of my built classes.  How might I specify these things
so that
> ejbc doesn't complain about seeing the generated classes in the

You should be able to take the build.destdir out of the wlclasspath and 
the complainst should stop. Let me know if that causes you issues.

> I'd really like to be able to make an ejbjar work without warnings.

Josh Lannin provided a patch which will allow you to silence ejbc for 
these warnings. It isn't documented yet, though.


Reply via email to