ant-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Adam R. B. Jack" <>
Subject Re: Baffled in classloader land
Date Sun, 02 Nov 2003 20:39:34 GMT

> No - I think because the JDK doco's are less then emphatic about what
> is required or suggested.  It's a great model - that your environment
> can easily control your classloader and nicely OO - I mean, I didn't
> stop to think about it until recently but
>   Class.forName().getClassloader()
> is an abomination. :)

It is crude, perhaps naive, certainly.

I (recently) go with some flavour of this.getClassLoader() and *hope* that
the original loading of "my" code ought match the loading of my resources.
Hopefully that matches getContextClassLoader is smart environments, and is
less bad is less well controlled environments. I'm sure there are cases
(installations in webapp containers) where this is flawed, but I'm getting
better mileage right now.

> Wait, isn't that like the commons-logging  pattern?  :D

Commons-logging uses getContextClassLoader (on JVM versions that have it).
They code looks pretty smart, so I leveraged it.

I've seen some discussion on the commons list where folks were questioning
CLs approach, having problems how they installed it, but I don't have the
"outcome" of that discussion to mind. I think it was decided, for it, to be
the lesser evil.

> Oh god, I really hope not.  That's the last thing the world needs is
> another commons-* dependency when this really is a simple fix - they
> fixed it in ant 1.6.  I think that this really comes down to education.

I hear ya, I was mainly joking. The reason I wasn't completely joking was
that this is a pretty tough *because* most of the code out there probably
doesn't set this in the container. What if I rely upon it, and the folks
running my ant tasks aren't using Ant 1.6? What if Ant is running inside
Eclipse, who sets it -- Ant or Eclipse? I hate making an assumption that is
so error prone in user environments. Maybe I can try brute force, try one
and then the other, but that seems ugly also [especially when I am
optionally loading classes, not just resources]. As I said, I don't think
there is a safe solution with these two.

I still beleive that there is room for getClassLoader methods at various
context sensetive places inside Ant. As different tasks set different
classpaths, or get called from macros or whatever, does Ant 1.6 continually
modify the current threads context classloader? I suspect that there is some
sort of need there. I've not thought it through, but I could see this
container having a better chance at solving the problem than users.

I agree that there is elegance in classloader hierarchies -- but also, there
be dragons...



To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message