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.
thanks 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
