Re: Thread context classloader: Serializing CallableReference

[Rajini Sivaram <ra...@googlemail.com>]

Hello,

HELP!!!

The current implementation of CallableReference relies on finding the
contribution containing the interface associated with the reference on the
thread context classloader. By default, Tuscany does not add contributions
to TCCL, and hence TCCL is set to the application classloader based on
CLASSPATH. Hence CallableReference can only be reliably passed around if the
contribution containing the reference interface is on the CLASSPATH. For
OSGi contributions, adding contributions to the CLASSPATH is not an option
since the the application classloader is different from the bundle
classloader, and using an OSGi-based TCCL classloader wont always work since
there could be multiple versions of interfaces.

There are two use cases of CallableReference which fail when the reference
interface is not visible to TCCL:

The first one (from one of the Tuscany itests):

    *objectOutStream.writeObject(aReference);
    CallableReference<AComponent> callableReference =
(CallableReference<AComponent>) objectInputStream.readObject();*

At the moment, the deserialized callableReference is usable only if
AComponent.class is visible from TCCL. This can potentially be made to work
without TCCL by converting CallableReferenceImpl to Serializable rather than
Externalizable, and using default Java serialization/deserialization (with a
performance penalty).

The second one, which is a more likely scenario in real applications is when
a CallableReference is a parameter to a method in a Remotable class.

    *@Remotable
    public interface DComponent {
        String foo(CallableReference<AComponent> aReference);
    }*

Regardless of whether this is a remote service, the CallableReference will
be unusable unless AComponent.class is visible from TCCL. Since the
deserialization is done through the Tuscany runtime, even using default Java
deserialization will not be sufficient, since the classloader used will be
the Tuscany runtime classloader which cannot see AComponent.class from a
contribution.

Any suggestions on removing the use of TCCL from CallableReferenceImpl is
appreciated.

Thank you...

Regards,

Rajini



On 10/30/07, Rajini Sivaram <ra...@googlemail.com> wrote:
>
> Hello,
>
> Implementations of CallableReference (and hence its subclass
> ServiceReference) are declared as Externalizable. At the moment, the
> writeExternal/readExternal methods of CallableReferenceImpl serialize to
> an SCDL and deserialize from the SCDL. The reference interface of a
> CallableReference created using readExternal gets resolved using the thread
> context classloader. Since contributions dont necessarily have to be visible
> from the thread context classloader, should the interface be resolved
> against the caller's classloader instead?
>
>
>
> Thank you...
>
> Regards,
>
> Rajini
>