Mailing-List: contact dev-help@geronimo.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@geronimo.apache.org
Received-SPF: pass (hermes.apache.org: local policy)
Mime-Version: 1.0 (Apple Message framework v619)
In-Reply-To: <Pine.LNX.4.58.0410031207060.4765@saturn.opentools.org>
References: <Pine.LNX.4.58.0410022350470.4765@saturn.opentools.org>
 <CBBB2368-1554-11D9-B7E9-000D93361CAA@gluecode.com>
 <Pine.LNX.4.58.0410031207060.4765@saturn.opentools.org>
Content-Type: text/plain; charset=US-ASCII; format=flowed
Message-Id: <D44C2D0B-1559-11D9-B927-000D93C5B79C@gluecode.com>
Content-Transfer-Encoding: 7bit
From: Dain Sundstrom <dsundstrom@gluecode.com>
Subject: Re: Connector Work ClassLoader
Date: Sun, 3 Oct 2004 09:32:34 -0700
To: dev@geronimo.apache.org

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