geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Jencks <>
Subject Re: Connector Work ClassLoader
Date Sun, 03 Oct 2004 16:51:44 GMT
Aside from the extreme slowness Dain mentioned, I don't see how to 
implement this proposal without a major rewriting of the WorkManager.  
Nothing else in connector-land executes with the TCCL set to the 
connector's classloader, so I'm not really seeing why the Work 
submissions should.

At the moment, the only way I see to implement this would be to supply 
a separate WorkManager instance to each ResourceAdapter that could 
associate the RA classloader with the work request.

david jencks

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

View raw message