Hi, 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 possible.
Cheers, Matt -----Original Message----- From: Conor MacNeill [mailto:[EMAIL PROTECTED]] Sent: Wednesday, October 24, 2001 9:33 AM To: [EMAIL PROTECTED] 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 from > my classes that say something similar to: > > [ejbjar] Could not fully load class someClassName for super class check > > I see in the source for ejbjar (the GenericDeploymentTool.java file) that > 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 about > 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 entire > 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 classpath? 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. Conor
