geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dain Sundstrom <dsundst...@gluecode.com>
Subject Re: Connector Work ClassLoader
Date Sun, 03 Oct 2004 16:32:34 GMT
Aaron it problem is setting the thread context classloader is a very 
very expensive operation, so tend not to do it unless required by the 
spec.  For example, a gbean no longer operates in a TCCL since setting 
it was taking 80% of our execution time.

-dain

--
Dain Sundstrom
Chief Architect
Gluecode Software
310.536.8355, ext. 26

On Oct 3, 2004, at 9:17 AM, Aaron Mulder wrote:

> 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