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 deployment.
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.
Conor
-- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
