Re: Changing TCCL during deserialization

[Gregg Wonderly]

There are lots of places like this, that I have done exactly this to make sure 
that the visibility of the current class loader is available for a thread which 
I don’t now the history of.  There is nothing that controls how the calling 
thread might decide (via code, or some other magic) what class loader to use 
for the parent of any newly created class loader.

In my serviceUI work, I’ve used readObject in smart proxies and data classes 
referenced by such classes.  Ultimately, I would usually have already set the 
TCCL via some other mechanism related to AWT/Swing events.   But, in some 
cases, you might be on a platform where the TCCL is not set correctly, and thus 
you might find that you had to add this for your software to work on that 
platform.

Gregg

> On Feb 7, 2017, at 1:20 AM, Michał Kłeczek (XPro Sp. z o. o.) 
>  wrote:
> 
> I am not sure how OSGI relates to this question. But I can imagine the 
> situation like this:
> 
> class MySmartAssWrappingObject implements Serializable {
> 
>  Object myMember;
> ...
> 
> private void readObject(ObjectInputStream ois) {
>  Thread.currentThread().setContextClassLoader(getClass().getClassLoader());
>  myMember = ois.readObject();
> }
> 
> }
> 
> That would allow you to do something similar to what you wanted to do with 
> class resolution by remembering the stack of class loaders.
> 
> So my question is:
> is it something that people do?
> 
> Thanks,
> Michal
> 
> Peter wrote:
>>  In PreferredClassProvider, no the callers ClassLoader (context) is the 
>> parent ClassLoader of the codebase loader.
>> 
>> It depends on the ClassLoader hierarchy and chosen strategy used to resolve 
>> annotations.
>> 
>> But the index key for PreferrefClassProvider is  URI[] and parent loader 
>> (callers loader).
>> 
>> This strategy allows codebases to be duplicated for different calling 
>> context.
>> 
>> OSGi however, only loads one Bundle per URL, but as Bharath has 
>> demonstrated, the codebase loader doesn't have to be a BundleReference.
>> 
>> There are some caveats if the proxy codebase loader isn't a BundleReference, 
>> one is your dependencies aren't version managed for you, and you can only 
>> see public classes imported by the parent BundleReference.
>> 
>> The strategy of switching context wouldn't work with PreferredClassProvider.
>> 
>> Regards,
>> 
>> Peter.
>> 
>> Sent from my Samsung device.
>> Include original message
>>  Original message 
>> From: "Michał Kłeczek (XPro Sp. z o. o.)"
>> Sent: 07/02/2017 07:20:59 am
>> To: dev@river.apache.org
>> Subject: Re: Changing TCCL during deserialization
>> 
>> This still does not answer my question - maybe I am not clear enough.
>> Do you have a need to set a TCCL DURING a remote call that is in progress?
>> Ie. you execute a remote call and DURING deserialization of the return value 
>> you change the TCCL (so one class is resolved using one context loader and 
>> another using a different one when reading THE SAME stream)
>> 
>> Thanks,
>> Michal
>> 
>> Gregg Wonderly wrote:
>> Anytime that a thread might end up being the one to download code, you need 
>> that threads CCL to be set.   The AWTEvent thread(s) in particular are a 
>> sticking point.  I have a class which I use for managing threading in 
>> AWT/Swing.  It’s called ComponentUpdateThread.  It works as follows.
>> 
>> new ComponentUpdateThread>( itemList, actionButton1, 
>> actionButton2, checkbox1 ) {
>>  public void setup() {
>>  // In event thread
>>  setBusyCursorOn( itemList );
>>  }
>>  public Listconstruct() {
>>  try {
>>  return service.getListOfItems( filterParm1 );
>>  } catch( Exception ex ) {
>>  reportException(ex);
>>  }
>>  return null;
>>  }
>>  public void finished() {
>>  List  let;
>>  if( (lst = get()) != null ) {
>>  itemList.getModel().setContents( lst );
>>  }
>>  }
>> }.start();
>> 
>> This class will make the passed components disabled to keep them from being 
>> clicked on again, setup for processing use a non AWTEvent thread for getting 
>> data with other components of the UI still working, and finally mark the 
>> disabled components back to enabled, and load the list with the returned 
>> items, if there where any returned.
>> 
>> There

Re: Changing TCCL during deserialization

[Michał Kłeczek (XPro Sp. z o. o.)]

This is fine for me. I am asking not about one interaction where 
multiple instances of MarshalledInputStreams are used (each with its own 
TCCL)
I am asking about the situation described in another email - that during 
a deserialization using a single instance of the stream the TCCL is changed.


Thanks,
Michal

Gregg Wonderly wrote:

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

Re: Changing TCCL during deserialization

[Gregg Wonderly]

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

Re: Changing TCCL during deserialization

[Michał Kłeczek (XPro Sp. z o. o.)]

I am not sure how OSGI relates to this question. But I can imagine the 
situation like this:


class MySmartAssWrappingObject implements Serializable {

  Object myMember;
...

private void readObject(ObjectInputStream ois) {
  
Thread.currentThread().setContextClassLoader(getClass().getClassLoader());

  myMember = ois.readObject();
}

}

That would allow you to do something similar to what you wanted to do 
with class resolution by remembering the stack of class loaders.


So my question is:
is it something that people do?

Thanks,
Michal

Peter wrote:
  
In PreferredClassProvider, no the callers ClassLoader (context) is the parent ClassLoader of the codebase loader.


It depends on the ClassLoader hierarchy and chosen strategy used to resolve 
annotations.

But the index key for PreferrefClassProvider is  URI[] and parent loader 
(callers loader).

This strategy allows codebases to be duplicated for different calling context.

OSGi however, only loads one Bundle per URL, but as Bharath has demonstrated, 
the codebase loader doesn't have to be a BundleReference.

There are some caveats if the proxy codebase loader isn't a BundleReference, 
one is your dependencies aren't version managed for you, and you can only see 
public classes imported by the parent BundleReference.

The strategy of switching context wouldn't work with PreferredClassProvider.

Regards,

Peter.

Sent from my Samsung device.
  
   Include original message

 Original message 
From: "Michał Kłeczek (XPro Sp. z o. o.)"
Sent: 07/02/2017 07:20:59 am
To: dev@river.apache.org
Subject: Re: Changing TCCL during deserialization

This still does not answer my question - maybe I am not clear enough.
Do you have a need to set a TCCL DURING a remote call that is in progress?
Ie. you execute a remote call and DURING deserialization of the return value 
you change the TCCL (so one class is resolved using one context loader and 
another using a different one when reading THE SAME stream)

Thanks,
Michal

Gregg Wonderly wrote:
Anytime that a thread might end up being the one to download code, you need 
that threads CCL to be set.   The AWTEvent thread(s) in particular are a 
sticking point.  I have a class which I use for managing threading in 
AWT/Swing.  It’s called ComponentUpdateThread.  It works as follows.

new ComponentUpdateThread>( itemList, actionButton1, actionButton2, 
checkbox1 ) {
public void setup() {
// In event thread
setBusyCursorOn( itemList );
}
public Listconstruct() {
try {
return service.getListOfItems( filterParm1 );
} catch( Exception ex ) {
reportException(ex);
}
return null;
}
public void finished() {
List  let;
if( (lst = get()) != null ) {
itemList.getModel().setContents( lst );
}
}
}.start();

This class will make the passed components disabled to keep them from being 
clicked on again, setup for processing use a non AWTEvent thread for getting 
data with other components of the UI still working, and finally mark the 
disabled components back to enabled, and load the list with the returned items, 
if there where any returned.

There is the opportunity for 3 or more threads to be involved here.  First, 
there is the calling thread.  It doesn’t do anything but start the work.  Next, 
there is an AWTEvent thread which will invoke setup().  Next there is a worker 
thread which will invoke construct().   Finally, there is (possible another) 
AWTEventThread which will invoke finished().

In total there could be up to four different threads involved, all of which 
must have TCCL set to the correct class loader.  My convention in the 
implementation, is that that will be this.getClass()getClassLoader().

This is all managed inside of the implementation of ComponentUpdateThread so 
that I don’t have to worry about it, any more.  But it’s important to 
understand that if you don’t do that, then the classes that the calling thread 
can resolve, and Item in this specific case in particular, and you would thus 
potentially see Item come from another class loader than you intended (the 
services class loader with “null” as the parent), and this will result in 
either a CNFE or CCE.

Gregg

On Feb 6, 2017, at 11:28 AM, Michał Kłeczek (XPro Sp. z o. 
o.)  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 

Re: Changing TCCL during deserialization

[Peter]

 
In PreferredClassProvider, no the callers ClassLoader (context) is the parent 
ClassLoader of the codebase loader.

It depends on the ClassLoader hierarchy and chosen strategy used to resolve 
annotations.

But the index key for PreferrefClassProvider is  URI[] and parent loader 
(callers loader).

This strategy allows codebases to be duplicated for different calling context.

OSGi however, only loads one Bundle per URL, but as Bharath has demonstrated, 
the codebase loader doesn't have to be a BundleReference.

There are some caveats if the proxy codebase loader isn't a BundleReference, 
one is your dependencies aren't version managed for you, and you can only see 
public classes imported by the parent BundleReference.

The strategy of switching context wouldn't work with PreferredClassProvider.

Regards,

Peter.

Sent from my Samsung device.
 
  Include original message
 Original message 
From: "Michał Kłeczek (XPro Sp. z o. o.)" 
Sent: 07/02/2017 07:20:59 am
To: dev@river.apache.org
Subject: Re: Changing TCCL during deserialization

This still does not answer my question - maybe I am not clear enough.
Do you have a need to set a TCCL DURING a remote call that is in progress?
Ie. you execute a remote call and DURING deserialization of the return value 
you change the TCCL (so one class is resolved using one context loader and 
another using a different one when reading THE SAME stream)

Thanks,
Michal

Gregg Wonderly wrote:
Anytime that a thread might end up being the one to download code, you need 
that threads CCL to be set.   The AWTEvent thread(s) in particular are a 
sticking point.  I have a class which I use for managing threading in 
AWT/Swing.  It’s called ComponentUpdateThread.  It works as follows.

new ComponentUpdateThread>( itemList, actionButton1, actionButton2, 
checkbox1 ) {
public void setup() {
// In event thread
setBusyCursorOn( itemList );
}
public Listconstruct() {
try {
return service.getListOfItems( filterParm1 );
} catch( Exception ex ) {
reportException(ex);
}
return null;
}
public void finished() {
List let;
if( (lst = get()) != null ) {
itemList.getModel().setContents( lst );
}
}
}.start();

This class will make the passed components disabled to keep them from being 
clicked on again, setup for processing use a non AWTEvent thread for getting 
data with other components of the UI still working, and finally mark the 
disabled components back to enabled, and load the list with the returned items, 
if there where any returned.

There is the opportunity for 3 or more threads to be involved here.  First, 
there is the calling thread.  It doesn’t do anything but start the work.  Next, 
there is an AWTEvent thread which will invoke setup().  Next there is a worker 
thread which will invoke construct().   Finally, there is (possible another) 
AWTEventThread which will invoke finished().

In total there could be up to four different threads involved, all of which 
must have TCCL set to the correct class loader.  My convention in the 
implementation, is that that will be this.getClass()getClassLoader().

This is all managed inside of the implementation of ComponentUpdateThread so 
that I don’t have to worry about it, any more.  But it’s important to 
understand that if you don’t do that, then the classes that the calling thread 
can resolve, and Item in this specific case in particular, and you would thus 
potentially see Item come from another class loader than you intended (the 
services class loader with “null” as the parent), and this will result in 
either a CNFE or CCE.

Gregg

On Feb 6, 2017, at 11:28 AM, Michał Kłeczek (XPro Sp. z o. o.) 
 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łecze

Re: Changing TCCL during deserialization

[Michał Kłeczek (XPro Sp. z o. o.)]

This still does not answer my question - maybe I am not clear enough.
Do you have a need to set a TCCL DURING a remote call that is in progress?
Ie. you execute a remote call and DURING deserialization of the return 
value you change the TCCL (so one class is resolved using one context 
loader and another using a different one when reading THE SAME stream)


Thanks,
Michal

Gregg Wonderly wrote:

Anytime that a thread might end up being the one to download code, you need 
that threads CCL to be set.   The AWTEvent thread(s) in particular are a 
sticking point.  I have a class which I use for managing threading in 
AWT/Swing.  It’s called ComponentUpdateThread.  It works as follows.

new ComponentUpdateThread>( itemList, actionButton1, actionButton2, 
checkbox1 ) {
public void setup() {
// In event thread
setBusyCursorOn( itemList );
}
public Listconstruct() {
try {
return service.getListOfItems( filterParm1 );
} catch( Exception ex ) {
reportException(ex);
}
return null;
}
public void finished() {
List  let;
if( (lst = get()) != null ) {
itemList.getModel().setContents( lst );
}
}
}.start();

This class will make the passed components disabled to keep them from being 
clicked on again, setup for processing use a non AWTEvent thread for getting 
data with other components of the UI still working, and finally mark the 
disabled components back to enabled, and load the list with the returned items, 
if there where any returned.

There is the opportunity for 3 or more threads to be involved here.  First, 
there is the calling thread.  It doesn’t do anything but start the work.  Next, 
there is an AWTEvent thread which will invoke setup().  Next there is a worker 
thread which will invoke construct().   Finally, there is (possible another) 
AWTEventThread which will invoke finished().

In total there could be up to four different threads involved, all of which 
must have TCCL set to the correct class loader.  My convention in the 
implementation, is that that will be this.getClass().getClassLoader().

This is all managed inside of the implementation of ComponentUpdateThread so 
that I don’t have to worry about it, any more.  But it’s important to 
understand that if you don’t do that, then the classes that the calling thread 
can resolve, and Item in this specific case in particular, and you would thus 
potentially see Item come from another class loader than you intended (the 
services class loader with “null” as the parent), and this will result in 
either a CNFE or CCE.

Gregg


On Feb 6, 2017, at 11:28 AM, Michał Kłeczek (XPro Sp. z o. 
o.)  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.)    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

Re: Changing TCCL during deserialization

[Gregg Wonderly]

Anytime that a thread might end up being the one to download code, you need 
that threads CCL to be set.   The AWTEvent thread(s) in particular are a 
sticking point.  I have a class which I use for managing threading in 
AWT/Swing.  It’s called ComponentUpdateThread.  It works as follows.

new ComponentUpdateThread>( itemList, actionButton1, actionButton2, 
checkbox1 ) {
public void setup() {
// In event thread
setBusyCursorOn( itemList );
}
public Listconstruct() {
try {
return service.getListOfItems( filterParm1 );
} catch( Exception ex ) {
reportException(ex);
}
return null;
}
public void finished() {
List let;
if( (lst = get()) != null ) {
itemList.getModel().setContents( lst );
}
}
}.start();

This class will make the passed components disabled to keep them from being 
clicked on again, setup for processing use a non AWTEvent thread for getting 
data with other components of the UI still working, and finally mark the 
disabled components back to enabled, and load the list with the returned items, 
if there where any returned.

There is the opportunity for 3 or more threads to be involved here.  First, 
there is the calling thread.  It doesn’t do anything but start the work.  Next, 
there is an AWTEvent thread which will invoke setup().  Next there is a worker 
thread which will invoke construct().   Finally, there is (possible another) 
AWTEventThread which will invoke finished().

In total there could be up to four different threads involved, all of which 
must have TCCL set to the correct class loader.  My convention in the 
implementation, is that that will be this.getClass().getClassLoader().

This is all managed inside of the implementation of ComponentUpdateThread so 
that I don’t have to worry about it, any more.  But it’s important to 
understand that if you don’t do that, then the classes that the calling thread 
can resolve, and Item in this specific case in particular, and you would thus 
potentially see Item come from another class loader than you intended (the 
services class loader with “null” as the parent), and this will result in 
either a CNFE or CCE.

Gregg

> On Feb 6, 2017, at 11:28 AM, Michał Kłeczek (XPro Sp. z o. o.) 
>  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.) 
>>>   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
>> 
> 

Re: Changing TCCL during deserialization

[Michał Kłeczek (XPro Sp. z o. o.)]

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

Re: Changing TCCL during deserialization

[Gregg Wonderly]

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

Changing TCCL during deserialization

[Michał Kłeczek (XPro Sp. z o. o.)]

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