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
