--- robert burrell donkin <[EMAIL PROTECTED]> 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
