ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jose Alberto Fernandez" <>
Subject Re: <ejbjar> question about <weblogic>/<classpath>
Date Thu, 21 Mar 2002 08:12:56 GMT
From: "Conor MacNeill" <>

> 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?

Yes, since this is the only one supporting EJB 2.0.
BTW, is there any vendor still supporting EJB1.1 only? 
I think ejbjar should move on to support EJB2.0 which is the
current standard and let EJB1.1 be supported as much as possible
as long as it does not mess up 2.0 support.

> > 
> > 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.

I really do not care about EJB 1.1, the current standard is 2.0 and in the case of
Weblogic it has been out for quite a while. I see no reason for us trying to support 
1.1 beter than 2.0. 

Still with that in mind, I still need <support> because not all classes needed
in my jars can be found by reflection. Some parts of my application need
to be loaded based on configuration and therefore use loadClass(String).
So I still need <support> to specify those. How do I make sure that
resources get packaged correctly? Maybe we need a <resources> element as well.

> 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.

This is fine in the spec and I am using it (I even pass that info in the "manifest"
provided for <ejbjar>). I am nor sure <ejbjar> needs to enforce such things
because there may be issues with respect to the order in which jars are build.
You just need to be able to say "resolve any additional classes for this classpath
but do not package them". <ejbjar> I think is doin this correctly today, at least
I see less classes in the jars when I set thigs properly.

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

EARs are my unit of deployment. But I still need to build the EJB jars.

> > 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.

How about classes used as parameters and such, you need to be able to say that.

> 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.

I think you are over designing a bit. I would argue that you are already 90% there
and this options just complicate instead of help. Let me tell you how I see it
since I am now using your stuff regularly.

"srcdir": while constructing the jar only put classes found here.

ejbjar/classpath: used by BCEL for any classes not in "srcdir" but
do not add classes from here.

ejbjar/support: try to put things in here on the jar (and use BCEL
with the same rules as for classpath). Is this smart enough as to
understand the difference between .class files and other resources
one may want added in the jar?

ejbjar/weblogic/wlclasspath: the CLASSPATH for the JVM running weblogic.

ejbjar/weblogic/classpath: path for EJBC -classpath option. Which I hope
it makes available correctly so that EJBC is happy while inspecting the jar.

Additionally, what would be nice is a way to ask <ejbjar> to create a clientjar
with all the classes needed by clients. Maybe this should be a separate <task>.

In any case, if you look at the list above, the current <ejbjar> does most of it,
it is just a little extra that is needed.

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

Sure, with as much time as I can manage (that is my problem these days).

Jose Alberto

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

View raw message