Return-Path: Mailing-List: contact user-help@ant.apache.org; run by ezmlm Delivered-To: mailing list user@ant.apache.org Received: (qmail 82438 invoked by uid 500); 11 Feb 2003 06:17:30 -0000 Received: (qmail 82383 invoked from network); 11 Feb 2003 06:17:30 -0000 Received: from unknown (HELO lago.versata.com.au) (192.207.36.98) by daedalus.apache.org with SMTP; 11 Feb 2003 06:17:30 -0000 Received: from retro.xedoc.com.au ([192.207.36.2]) by lago.versata.com.au (8.12.2/8.12.2) with ESMTP id h1B6gKYs006972 for ; Tue, 11 Feb 2003 17:42:21 +1100 (EST) Received: from Lucifer (dhcp60.xedoc.com.au [192.207.36.170]) by retro.xedoc.com.au (8.9.1/8.9.1) with SMTP id RAA08383 for ; Tue, 11 Feb 2003 17:15:42 +1100 (EST) From: "William Ferguson" To: Subject: RE: Classloader problem with rpelaceregexp Date: Tue, 11 Feb 2003 17:15:41 +1100 Message-ID: <012301c2d195$01a55560$aa24cfc0@Lucifer> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4910.0300 Importance: Normal In-Reply-To: X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N Thanks for the confirmation Stefan. I guess we'll just have to run dirty :-) William -----Original Message----- From: Stefan Bodewig [mailto:bodewig@apache.org] Sent: Monday, February 10, 2003 11:58 PM To: ant-user@jakarta.apache.org Subject: Re: Classloader problem with rpelaceregexp On Mon, 10 Feb 2003, William Ferguson wrote: > OK, I'll try again with a different subject line. At least for me it hasn't been a problem of the subject line 8-) You obviously have all your facts together, you know why things happen and you know how to fix it in an ugly way. And no, I don't know of any easier way (I don't think there is one). > but it seems that classloading has become a bit of an issue. It always becomes an issue if you try really advanced things in Ant. The only real solution would be a cleaner class loader hierarchy, where no Ant classes end up on thy system classloader. Part of it could be done today by not using Class.forName in so many places as we do (but rather set context classloaders and use them where appropriate - and only in JDK 1.2+ of course). But this wouldn't solve the problem completely, which probably explains why nobody has invested too much time into it yet. Switching to something clean is impossible without seriously breaking backwards compatibility for a lot of task writers who rely on Ant's current classloader mechanics. Stefan --------------------------------------------------------------------- To unsubscribe, e-mail: user-unsubscribe@ant.apache.org For additional commands, e-mail: user-help@ant.apache.org