river-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Michał Kłeczek (XPro Sp. z o. o.)" <michal.klec...@xpro.biz>
Subject Re: Changing TCCL during deserialization
Date Mon, 06 Feb 2017 17:28:40 GMT
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.


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.kleczek@xpro.biz>
>> 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
>> 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

  • Unnamed multipart/mixed (inline, None, 0 bytes)
View raw message