ant-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Geir Magnusson Jr. <ge...@optonline.net>
Subject Re: Baffled in classloader land
Date Sun, 02 Nov 2003 19:52:57 GMT

On Sunday, November 2, 2003, at 11:37 AM, Adam R. B. Jack wrote:

>> I've just had a short look into commons-discovery.  They search the
>> thread context classloader and getClass().getClassloader().  At least
>> that's my understanding of ServiceDiscoveryTask.  So maybe you should
>> fall back to your class's classloader if a resource cannot be loaded
>> via the context classloader.
>
> Sorry to be joining this late, but this is something that has been 
> biting me
> recently. I write code that uses classloading (for resources, for 
> optional
> class loading, for whatever) and I want it to run inside Ant, inside
> Eclipse, and inside other environments. I "borrowed" the code that
> CommonsLogging was using, thinking it was likely "correct" -- and it 
> was
> using getContextClassloader also.Sadly, I was failing miserably in
> Eclipse-land although not noticing too much of a problem in ant land. 
> Maybe
> I was lucky and in my tests, my ant classpath was pretty much the same 
> as my
> JVM one. I suspect it is this.

 From my tests, that would be my conclusion.

>
> Sadly I've come to the conclusion that using getContextClassLoader is
> seriously flawed. Maybe it works ok for webapps, but many other tooling
> environments just don't have that simple a time. Within eclipse (for
> example) the calling thread may not be with the 'context' (say a Java
> project) that one wants. As a corrolary, I have no idea how Ant within
> Eclipse will cope!
>
> Sadly this is a mess, and one I don't have a real answer to -- I just 
> wanted
> to add my level of misery to the pile. ;-) I've taken to loading 
> resources
> with a classloader from the class related to the resources, and that 
> helps,
> but is imperfect. I am trying to get more "hand on" over my classloader
> usage in my code, in the hope I can do the right things in the right
> environments, but for certain -- getContextClassLoader is not it.

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. :)  Wait, isn't that like the commons-logging 
pattern?  :D

>
> Maybe ant tasks need a getClassloader() method, maybe all project 
> entities
> need one also. I wish there was a simple answer to this, and I've tried
> reading information on the web [and all they tell you is how to write a
> classloader, not how to survive classloader hell.] Maybe there is a
> commons-classloader out of all this. ;-)

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.

The approach we are going to take in Velocity-land is throw our hands 
up and make a new kind of resource loader, one that does from the 
thread-context classloader.  That way, people who know they are working 
in an environment where that's important will use that, and the rest 
can continue with our current impl, the one that uses 
this.getClassloader().

Thanks for the support of my misery.

geir

>
> regards,
>
> Adam
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: user-unsubscribe@ant.apache.org
> For additional commands, e-mail: user-help@ant.apache.org
>
>
-- 
Geir Magnusson Jr                                   203-247-1713(m)
geirm@optonline.net


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


Mime
View raw message