Mailing-List: contact user-help@ant.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Ant Users List" <user@ant.apache.org>
Received-SPF: pass (asf.osuosl.org: domain of hoju@visi.com designates
 208.42.156.9 as permitted sender)
Message-ID: <1161030247.4533ea6796959@my.visi.com>
Date: Mon, 16 Oct 2006 15:24:07 -0500
From: Jacob Kjome <hoju@visi.com>
To: Ant Users List <user@ant.apache.org>
Subject: Re: ant and classloading
References: <7.0.1.0.0.20061015221533.0485b050@syntegra.com>
 <dffc72020610160220l3bb9d554u196a70e72e888bd0@mail.gmail.com>
In-Reply-To: <dffc72020610160220l3bb9d554u196a70e72e888bd0@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
User-Agent: Internet Messaging Program (IMP) 3.2.5

Quoting Peter Reilly <peter.kitt.reilly@gmail.com>:

> On 10/16/06, Jacob Kjome <hoju@visi.com> wrote:
> >
> > I'm not sure this is 100% an Ant question, but it is within the context of
> Ant.
> >
> > In my Ant task, I'm loading up a class using Class.forName() and pass
> > in a classloader that I would have expected to be assigned as the
> > classloader for the class.  That doesn't seem to be the case.  Here's
> > what I'm doing..
> >
> >
> > AntClassLoader customLoader = new
> > AntClassLoader(getClass().getClassLoader(), true);
> > customLoader.setClassPath(getResourcePath());
> >
> > Class clazz = Class.forName(clazzName, true, customLoader);
> >
> >
>
System.out.println(customLoader.getResource("org/myorganization/resources/my.dtd"));
> >
>
System.out.println(clazz.getClassLoader().getResource("org/myorganization/resources/my.dtd"));
> >
> >
> > The DTD resource is found in the first case using the custom
> > classloader where the user configured the resourcePath attribute of
> > the task, but in the second case when I use the classloader of the
> > class that I just loaded by passing in the custom classloader I just
> > get "null".  The point of this is that the class I am loading needs
> > to look up user-defined resources on the classpath.  With the
> > System.out lines, I am just testing what my loaded class needs to do
> > further down the line.
> >
> > Shouldn't the classloader of the class I just loaded be a reference
> > to that which I passed into Class.forName()?
>
> No, Java uses a delegated classloader model. Normally, classloaders
> search up the hierarchy, starting at the base classloader to load
> a  class. The reason for this is that classes are not the same unless
> they are loaded from the same classloader. To take a simple case
> one would want java.lang.Object to be the same no matter how
> it is loaded.
>

So, is there a way to add some more classpath information to the base
classloader that loaded the task?  I have no ability to pass a classloader to
the code that attempts to load configured resources.  The classloader that
loads the class needs to make this user-defined classpath available.

Come to think of it, can I just cast the classloader to an AntClassLoader and
add the path to it using addPathElement(String)?  I guess I didn't try that
yesterday, but I'll try it tonight.

Of course, it seems like that might cause side effects for later calls to the
same task where an added path element from one task use would be available for
another.

What other way is there?  Would I need to fork a new process and define the
classpath from the get-go for each call?  I'd like to use something less
heavyweight, but not have side effects.

Jake

>
> > This is probably more
> > of a general classloading question than an Ant question, but I'm
> > guessing others have had to deal with that here.  I must be making a
> > bad assumption, but it seems like something like this should be possible.
> >
> > My only workaround right now is to add the extra classpath
> > information to the Task definition classpath.  However, that is not
> > intuitive for task users and a pretty ugly hack.  Is there any way to
> > do this?  I've run into and solved many classloading issues in the
> > past, but I've never had to deal with this specifically.  I have to
> > imagine someone has solved this problem already.  Care to share the
> solution?
> >
> >
> > Jake
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: user-unsubscribe@ant.apache.org
> > For additional commands, e-mail: user-help@ant.apache.org
> >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: user-unsubscribe@ant.apache.org
> For additional commands, e-mail: user-help@ant.apache.org
>


---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@ant.apache.org
For additional commands, e-mail: user-help@ant.apache.org