Stefan Bodewig wrote:
On Wed, 15 Oct 2003, Upayavira <[EMAIL PROTECTED]> wrote:
as Cocoon requires a different version of Avalon logging from that
in the Ant Velocity jar.
Hmm, there is no velocity.jar in Ant ...
A stock Ant distribution bundles Xerces and xml-apis and nothing else.
Maybe y
On Wed, 15 Oct 2003, Upayavira <[EMAIL PROTECTED]> wrote:
> as Cocoon requires a different version of Avalon logging from that
> in the Ant Velocity jar.
Hmm, there is no velocity.jar in Ant ...
A stock Ant distribution bundles Xerces and xml-apis and nothing else.
Maybe your Ant installation ha
Conor MacNeill wrote:
From: Dominique Devienne [mailto:[EMAIL PROTECTED]
Note that it's often dangerous to break the delegation model of class
loaders... Works sometimes, but be aware we're breaking the rules. --DD
Absolutely. I would caution against violating the requirement to delegate
to p
> From: Dominique Devienne [mailto:[EMAIL PROTECTED]
>
> Note that it's often dangerous to break the delegation model of class
> loaders... Works sometimes, but be aware we're breaking the rules. --DD
>
Absolutely. I would caution against violating the requirement to delegate
to parent loaders.
Dominique Devienne wrote:
-Original Message-
From: Upayavira [mailto:[EMAIL PROTECTED]
Dominique Devienne wrote:
Here's something that might work. The code you sketched below, which only
depends on Cocoon classes, could be make part of Cocoon itself in an
existing or new JAR from Cocoo
> -Original Message-
> From: Upayavira [mailto:[EMAIL PROTECTED]
> Samuel Gabriel wrote:
> >We ran into this problem in one of our projects. The solution we found is
> to
> >override the loadClass method so that it looks into the classloader
> classes
> >before it looks into the parent clas
Upayavira wrote:
Samuel Gabriel wrote:
We ran into this problem in one of our projects. The solution we
found is to
override the loadClass method so that it looks into the classloader
classes
before it looks into the parent classes. This way if there are
classes that
are conflicting our classes
Developers List'
Subject: RE: Preventing Parent Classloading
-Original Message-
From: Upayavira [mailto:[EMAIL PROTECTED]
Dominique Devienne wrote:
Here's something that might work. The code you sketched below, which only
depends on Cocoon classes, could be make part of
-Original Message-
From: Dominique Devienne [mailto:[EMAIL PROTECTED]
Sent: Friday, October 10, 2003 11:00 AM
To: 'Ant Developers List'
Subject: RE: Preventing Parent Classloading
> -Original Message-
> From: Upayavira [mailto:[EMAIL PROTECTED]
>
> Dominique Dev
> -Original Message-
> From: Upayavira [mailto:[EMAIL PROTECTED]
>
> Dominique Devienne wrote:
> >Here's something that might work. The code you sketched below, which only
> >depends on Cocoon classes, could be make part of Cocoon itself in an
> >existing or new JAR from Cocoon/WEB-INF/lib
get(parent.getOwningTarget());
// Initialize (and return) the helper
helper.init();
return helper;
}
...
}
-Original Message-
From: Upayavira [mailto:[EMAIL PROTECTED]
Sent: Thursday, October 09, 2003 6:00 PM
To: Ant Developers List
Subject: Re: Preventing Parent Class
> To: Ant Developers List
> Subject: Re: Preventing Parent Classloading
>
> Dominique Devienne wrote:
>
> >Sounds like the CL you create delegates to the Ant CL, thus your problem.
> >Create your own CL by making it delegate to the Root/Bootstrap CL (by
> >setting the par
Dominique Devienne wrote:
Sounds like the CL you create delegates to the Ant CL, thus your problem.
Create your own CL by making it delegate to the Root/Bootstrap CL (by
setting the parent loader to null), and the classes will always be loaded
from your classes (may duplicate-load the some classes
Sounds like the CL you create delegates to the Ant CL, thus your problem.
Create your own CL by making it delegate to the Root/Bootstrap CL (by
setting the parent loader to null), and the classes will always be loaded
from your classes (may duplicate-load the some classes Ant loaded in its CL,
but
14 matches
Mail list logo
