geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Aaron Mulder <ammul...@alumni.princeton.edu>
Subject Re: Connector Work ClassLoader
Date Sun, 03 Oct 2004 16:17:11 GMT
On Sun, 3 Oct 2004, David Jencks wrote:
> I've spent some time looking at the j2eeca 1.5 spec again and can't 
> fine any mention of which thread context classloader a Work submission 
> is supposed to operate under.  Therefore I think if you want your 
> adapter to be portable you should not make any assumptions about it and 
> we have no need to set the thread context classloader ourselves.  So, 
> while I'm open to discussion, so far I'm -1 on this.

	I don't understand.  If the spec is unclear (and I didn't even 
look so it may well be), why don't we take the option that is friendly to 
developers, instead of the option that will likely break things?  It may 
be nice in practice to point out to people when their code is not 
perfectly portable, but it would be even nicer if their code just ran.  I 
can understand being -1 on my non-portable Work code, but I can't agree 
with being -1 on providing a more forgiving Connector implementation.

	FYI, when I encountered this, it was because I tried to read a
SOAP message in my Work, and the SAAJ API implementation apparently uses
the TCCL to load its implementation.  So I wasn't doing anything 
particularly offensive here, and it wasn't even clear why a ClassLoader 
should be involved (after all, if i can instantiate SAAJ classes, doesn't 
that automatically mean that they're accessible to me?  Well, in this 
case, the API was but the implementation wasn't because it doesn't use 
Class.forName).

Aaron

Mime
View raw message