Bug in available Task?

[Carsten Ziegeler <cz...@sundn.de>]

Hi,

we recently had the problem with Cocoon 2 that the
"available" task always searches not only in the 
given classpath for a class but also in the parent
classloader (= jdk classpath). The documentation 
for the "available" task is not very clear about this.
Is this a bug or a feature? I personally would call
this a bug, because if I specify:
    <available classpathref="classpath" 
               property="naming.present" 
               classname="javax.naming.Context"/>
I assume that the class is only used in the classpath
defined by classpathref. 

Looking at the source I saw that the AntClassLoader
theoretically supports the "isolated" feature
which prevents searching in parent class loaders.
Is it planned to add an optional attribute to
the available task to specify the behaviour of
this search? 
(Cocoon 2 really needs this, I wrote a much
simpler task myself which only checks the given
path for the class - but does not try to load it).

However just patching the Available class to
support setting the isolated flag on the classloader
is not enough as the isolated flag seems not to 
be evaluated correctly. For example the loadClass()
method always calls isParentFirst(), but in insolated
mode the parent should never be queried.


Carsten 

Open Source Group                        sunShine - b:Integrated
================================================================
Carsten Ziegeler, S&N AG, Klingenderstrasse 5, D-33100 Paderborn
www.sundn.de                          mailto: cziegeler@sundn.de 
================================================================

Re: Bug in available Task?

[Stefan Bodewig <bo...@apache.org>]

On Thu, 4 Oct 2001, Carsten Ziegeler <cz...@sundn.de> wrote:

> we recently had the problem with Cocoon 2 that the
> "available" task always searches not only in the 
> given classpath for a class but also in the parent
> classloader (= jdk classpath). The documentation 
> for the "available" task is not very clear about this.
> Is this a bug or a feature?

A feature.

This is how Java expects a classloader to behave - actually if you
write a Classloader you are expected to search the the parent
classloader first, Ant can be tricked to use the user-supplied
classpath first, but this is not what a well behaved Classloader
should do.

> Is it planned to add an optional attribute to the available task to
> specify the behaviour of this search?

Don't know - currently it simply checks whether you could find the
class in an AntClassLoader.  I guess you have a different need, could
you explain what you are trying to do?

> However just patching the Available class to
> support setting the isolated flag on the classloader
> is not enough as the isolated flag seems not to 
> be evaluated correctly.

You may want to use a constructor that also sets useParentFirst to
false - maybe AntClassLoader.setIsolated should also set
useParentFirst if its argument is true.  Conor?

Stefan