Please see more comments below.
Thanks,
Raymond
--------------------------------------------------
From: "Rajini Sivaram" <[EMAIL PROTECTED]>
Sent: Monday, May 12, 2008 9:43 AM
To: <tuscany-dev@ws.apache.org>
Subject: Re: SDO Databinding and classloaders
On 5/12/08, Raymond Feng <[EMAIL PROTECTED]> wrote:
Hi,
I think there are two different perspectives here:
1) The pass-by-value semantics copies the SDO to make sure it cannot be
mutated.
My understanding (which is probably wrong) was that @Remotable ensured
that
the semantics of the call remained the same regardless of whether the
caller
and the callee were in the same VM or on two different machines. This was
part of the reason why I asked the question. If my component A and
component
B are on the same VM with different classloaders, they dont work, but if I
moved component B to another process it works fine. That sounds wrong, but
I
can understand that it is an unlikely scenario in Tuscany when OSGi is not
used.
There is one more player: binding. The remote interaction is controlled by
the binding protocol. When the source and target components are running
under different context (such as classloader), the binding provider should
be responsible to make sure the data are correctly marshalled/unmarshalled.
If the binding decides to optimize for the co-located cases (in same VM), it
needs to take care of the cross-context data mapping. It is similar that
RMI/IIOP copies the data for the co-located services.
2) Different classloaders are used for different bundles.
We probably shouldn't mix these two. Let's put SCA on the side for now
and
think in OSGi. Assuming we have two OSGi bundles (B1 & B2) and Class C1
from
B1 is calling Class C2 from B2 to exchange SDO. How would you handle the
classloading issue? Would you make sure B1 and B2 have the same
dependency
on a 3rd bundle which contains the SDO classes? Or do you package the SDO
classes in both B1 and B2 and have the user code take care of the
cross-classloader data passing? Once we have clear answers for these
questions, we'll figure out which part of the code should be responsible
for
the cross-classloader data mapping.
In pure-OSGi land, there is no concept of remotable services. If B1
invokes
a method in B2, the classloaders of the arguments have to match (as in
standard Java). So the classes for the arguments should come from the same
bundle. If they dont, it is the responsibility of the application code to
copy data.
implementation.osgi in Tuscany attempts to bring SCA concepts like
remotable
services to OSGi, and also enables access to non-OSGi services in Tuscany
from OSGi. At the moment, we can provide interoperability between OSGi and
non-OSGi components using SDOs only if the non-OSGi component is defined
in
an OSGi contribution (ie, they use the same classloaders). If
cross-classloader data mapping is specific to OSGi and unlikely to occur
in
other scenarios in Tuscany, maybe this should be done in
implementation.osgi
- what do you think?
Maybe the binding should handle the cross-classloader data mapping instead
of the implementation.osgi.
Thanks,
Raymond
--------------------------------------------------
From: "Rajini Sivaram" <[EMAIL PROTECTED]>
Sent: Sunday, May 11, 2008 1:44 PM
To: <tuscany-dev@ws.apache.org>
Subject: SDO Databinding and classloaders
Hello,
>
> I was looking at a JIRA related to SDO parameters to OSGi services (
> https://issues.apache.org/jira/browse/TUSCANY-2307), and was not sure
> whether the following scenario is valid for standard Java services in
> Tuscany.
>
> Component A and Component B are implemented using
> <implementation.java/>
> and
> use default SCA binding.
> Component A invokes a remotable service from component B. One of the
> arguments to the service is an SDO object. But Component A and
> Component
> B
> use different classloaders for the SDO object. Will the copying of the
> SDO
> object done by databinding-sdo handle copying across multiple
> classloaders?
>
> I couldn't find any code which handles SDO classes loaded by different
> classloaders, so I was wondering whether we expect only one set of SDO
> classes to exist in a VM, or if I am just looking in the wrong place.
>
>
> Thank you...
>
> Regards,
>
> Rajini
>
>
--
Thank you...
Regards,
Rajini
