Return-Path: Delivered-To: apmail-jakarta-ant-dev-archive@apache.org Received: (qmail 45165 invoked from network); 20 Mar 2002 11:39:28 -0000 Received: from unknown (HELO nagoya.betaversion.org) (192.18.49.131) by daedalus.apache.org with SMTP; 20 Mar 2002 11:39:28 -0000 Received: (qmail 14289 invoked by uid 97); 20 Mar 2002 11:39:24 -0000 Delivered-To: qmlist-jakarta-archive-ant-dev@jakarta.apache.org Received: (qmail 14273 invoked by uid 97); 20 Mar 2002 11:39:23 -0000 Mailing-List: contact ant-dev-help@jakarta.apache.org; run by ezmlm Precedence: bulk List-Unsubscribe: List-Subscribe: List-Help: List-Post: List-Id: "Ant Developers List" Reply-To: "Ant Developers List" Delivered-To: mailing list ant-dev@jakarta.apache.org Received: (qmail 14262 invoked from network); 20 Mar 2002 11:39:23 -0000 Message-ID: <3C987609.3080305@cortexebusiness.com.au> Date: Wed, 20 Mar 2002 22:44:09 +1100 From: Conor MacNeill User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.7) Gecko/20011226 X-Accept-Language: en-us, en-au MIME-Version: 1.0 To: Ant Developers List Subject: Re: question about / References: <20020320102358.58994.qmail@web10806.mail.yahoo.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N Jose Alberto Fernandez wrote: > Hi, > > I really cannot understand the current behavior of > within when also defining > . 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 > I get errors from EJBC about classes not > found. If I put them in 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. went halfway toward this by adding in super interfaces and super classes. 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 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: For additional commands, e-mail: