ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Conor MacNeill <>
Subject Re: <ejbjar> question about <weblogic>/<classpath>
Date Wed, 20 Mar 2002 11:44:09 GMT
Jose Alberto Fernandez wrote:

> Hi,
> I really cannot understand the current behavior of
> <classpath> within <weblogic> when also defining
> <wlclasspath>. Can someone please explain to me how it
> is supposed to work?

Ok. It is in some respects a function of backward compatability and evolution.

Prior to 1.4, there was just the classpath. It was used both when loading 
classes for super class checking and also when running weblogic.ejbc.

In 1.4, with weblogic 6, weblogic started to complain about classes being in the 
jars and also being in the classpath. The classpath was still needed for the 
superclass check, but it was desirable to use a separate classpath when running 
weblogic.ejbc. Backwar compatability required the standard classpath be used if 
the weblogic classpath was not set.

Classes which are in the generated jars should not appear in the weblogic 
classpath but may be required for the superclass check.

In Ant 1.5, this is still undergoing development. The superclass check which 
previously was performed by reflection, will now be preformed by BCEL. This does 
not require a complete classpath to examine the classes. The classpath attribute 
will have become redundant.

For weblogic, the wlclasspath is used to invoke weblogic.ejbc unless it is not 
provided, in which case classpath is used.

> It seems to be ignored, which would be a bug, but
> maybe I am misunderstanding its use. This is the
> behavior I am experiencing at the moment.

Using 1.5 alpha?

> If the EJB has dependencies on things in the
> <classpath> I get errors from EJBC about classes not
> found. If I put them in <wlclasspath> they work
> but I may get warnings about things in the CLASSPATH
> that should not be there. 

Early versions of the 1.1 EJB spec stated that all dependent classes must be 
contained in the jar. Indeed, Weblogic hot deploy did not work if there were 
dependencies outside the EJB jar. <ejbjar> went halfway toward this by adding in 
super interfaces and super classes. <support> was added for other cases. It 
wasn't perfect.

The current 2.0 spec says the jar must include all classes used by the bean 
unless the jar provides those classes by class-path references in its manifest.

In some respects this is a transition in J2EE from beans to ears as the unit of 

> If I put them in "srcdir"
> then it works as expected but it puts this classes as
> part of the EJBjar whch I do not want (they are
> supposed to be picked up from the jar Class-Path.

You may have noticed a recent bit of refactoring in the ejbjar code. The goal of 
this was to do a few things

1. Decouple ejbjar from BCEL. If you don't want to add in additional classes, 
you won't need BCEL.

2. Specify which additional classes are to be added to the jar. "None" will be 
an option, as will "super" and "full". The latter two require BCEL.

3. Specify where you want the additional classes to end up. The options being in 
the ejbjar itself or added to some support jar, which you would then reference 
in the Class-Path. This would include any <support> files added.

I've done step 1, Step 2 should be easy. Step 3 require a bit more work.

If you want to help test it out, that would be cool.


To unsubscribe, e-mail:   <>
For additional commands, e-mail: <>

View raw message