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 Thu, 21 Mar 2002 10:00:32 GMT
Jose Alberto Fernandez wrote:

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

I don't think 1.1 support will inhibit 2.0 support. You asked for the situation
and I gave you the history of how it comes to be that way. Besides, there are
still many users in production using EJB 1.1 and they need to be supported.

 > 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 
 > 1.1 beter than 2.0.

Again, I was trying to convey to you how we arrive where we are today. EJB2.0
achieved final release status on 24-Sep-01, which was after Ant 1.4 had
commenced its release cycle. So, in the larger scheme of things there was not
much call for EJB2.0 features at the time of Ant 1.4. Ant 1.5 release will
support 2.0, of course.

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

<support> adds files, not classes specifically, so you can add resources in as

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

<ejbjar> does not enforce Class-Path relationships. The issue is where to add
the classes and files an EJB uses. Should they be in the EJB jar or in a
separate support jar. In Ant 1.4 the super classes and <support> files get added
to the jar. It may be more appropriate to add them to another jar. Many people
would prefer that they are not added to the jar.

 > You just need to be able to say "resolve any additional classes for this 
 > 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 Ant 1.5, ejbjar does not use reflection and therefore does not need to
"resolve" classes if that is what you mean by resolve. It analyzes the classes
in the srcdir directory and does not need the classpath. This is why it seems

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

I was trying to explain the shift from putting everything into the jar to
putting just the bean classes in the jar and everything else into a support jar
within the ear.

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

That is what "full" means.

 > I think you are over designing a bit. I would argue that you are already 90% 
 > 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.

This is what already happens. The question is which classes from here to put
into the jar. Some users want to add in everything. Some are concerned about
duplicating classes in separate jars and only want the bean classes in the jar.
This is the choice I am trying to support.

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

BCEL does not need the classpath. This was only needed for reflection based
analysis which is being replaced.

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

These are just files and are not analyzed for dependencies. BTW, In Ant 1.4,
some people are using <support> to add the non-super class dependencies. It is
not a great solution, when building multiple jars at once.

Anyway, I need to continue to support such usage which is why <ejbjar>'s default
behaviour of only adding super classes and super interfaces will be restored.

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

Yes. Already there.

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

I'm looking at this.

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

Not sure.

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

Can you tell me the actual problems you currently encounter.

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

I, too, have this problem :-)


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

View raw message