commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Brian Stansberry <bes_commons_...@yahoo.com>
Subject Re: [logging] demonstration code
Date Thu, 24 Mar 2005 06:17:39 GMT
--- robert burrell donkin
<robertburrelldonkin@blueyonder.co.uk> wrote:
<snip>
>
> the link between the concept of application
> boundaries, threads and
> containers is missing and should really be spelt
> out. 
> 
> from a narrative perspective, it's probably
> important to give the
> specification and then explain that creator (in the
> sense of the thread
> context classloader documentation) in the case of a
> container (or any
> other thread pooled application) encompasses the
> concept of owner.

Ah, "owner".  That's the word I wanted.  I was
thinking about wording when I posted last night and
kept thinking about the thread's "manager" but didn't
like that.

> so, the owner of the thread should ensure that a 
> thread has an appropriate
> classloader set for the application currently
> executing in that thread.
> this can then link into the (missing) subject of
> application boundaries.
> 
> in addition, it's probably worth including something
> of craig's
> explanation about the evolution of class-first
> classloading in the J2EE
> section. JCL needs to run on older containers and so
> people need to be
> aware of this. 
> 
> i takes me a lot of energy to write documentation
> and the context
> hierarchical section didn't get as much as the
> preceding section. it
> could probably do with revisiting but i'm not sure
> when i'll find the
> time. so, i'd be grateful for patches.  
> 

I'd be happy to try to come up with something.  I know
what you mean about the energy to write docs -- I
wanted to suggest some wording with my last message,
but had no creative energy at the time.

> i think that the consensus is that ensuring that
> applications release
> logging (and other resources) correctly is something
> that applications
> should definitely be taking seriously. it's worth
> explaining this in the
> user guide. again, i'd be grateful for patches. 
>
+1

Every now and then I think about puttin up a web page
devoted to known memory leaks in Java libraries and
how to prevent them.  Kind of doubt I'll find the
time, though.

Brian

__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 

---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org


Mime
View raw message