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 21:55:19 GMT

On Sunday, November 2, 2003, at 03:39 PM, Adam R. B. Jack wrote:

>
>> 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.

And something I've done time after time, I'll admit. :)  It only wasn't 
until recently that someone made me think about it..

>
> 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.

Indeed.  I was joking a bit about the Logging.getLogger() pattern.  The 
stuff that makes it happen underneath is smart.

>
> 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.

Yah, maybe.

>
>> 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...
>

indeed

> 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