I am not sure about “locked”. In my example about ServiceUI, imagine that there is a common behavior that you ServiceUI hosting environment provides to all ServiceUI Components. It can be that there is a button press or something else where an AWTEvent thread is going to take action. It’s that specific thread whose TCCL must be changed, each time, to the codebase of the service you are interacting with. If it calls out the service proxy and that is a smart proxy, imagine that the smart proxy might use a different service each time, and thats where the TCCL must be set appropriately so that any newly created classes are parented by the correct environment in your ServiceUI hosting platform.
Gregg > On Feb 6, 2017, at 11:28 AM, Michał Kłeczek (XPro Sp. z o. o.) > <michal.klec...@xpro.biz> wrote: > > 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> <mailto: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 >> >
