What I was specifically asking for is whether this is needed during
deserialization or after deserialization.
In other words - if I can lock the TCCL to an instance of
MarshalInputStream existing for the duration of a single remote call.
Thanks,
Michal
Gregg Wonderly wrote:
The predominant place where it is needed is when you download a serviceUI
component from a proxy service which just advertises some kind of “browsing”
interface to find specific services and interact with them, and that serviceUI
is embedded in another application with it’s own codebase
appl->serviceUI-for-browsing->Service-to-use->That-Services-ServiceUI
In this case, TCCL must be set to the serviceui classes classloader so that the
“serviceui-for-browsing” will have a proper parent class pointer.
Anytime that downloaded code might download more code, it should always set
TCCL to its own class loader so that the classes it downloads reflect against
the existing class definitions.
Gregg
On Feb 6, 2017, at 12:03 AM, Michał Kłeczek (XPro Sp. z o.
o.)<michal.klec...@xpro.biz> wrote:
Hi,
During my work on object based annotations I realized it would be more efficient not to
look for TCCL upon every call to "load class" (when default loader does not
match the annotation).
It might be more effective to look it up upon stream creation and using it
subsequently for class loader selection.
But this might change semantics of deserialization a little bit - it would not
be possible to change the context loader during deserialization.
My question is - are there any scenarios that require that?
I cannot think of any but...
Thanks,
Michal
