You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tuscany.apache.org by Jim Marino <jm...@myromatours.com> on 2007/03/07 20:55:04 UTC
JavaComponent and PhysicalOperationDefinition changes, r515719
I've been working on getting the Physical marshalling and build
infrastructure integrated with the connector. In order to do this, I
changed the way types are being tracked on
PhysicalOperationDefinition. Instead of directly referencing the
type's class, I changed it to track the fully qualified name as a
String. When the TargetInvoker is created on JavaComponent, it will
load the types using the classloader that loaded the implementation
class and map to the appropriate method using getMethods(). This will
allow us to integrate with the classloading infrastructure Jeremy has
been working on since the implementation class will be loaded by the
multi-parent classloader for the Component (which is held in the
ClassLoaderRegistry by uri).
I've also started to convert over to using
PhysicalOperationDefinition - when we get full federation enabled,
Operation can go away.
Jim
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: JavaComponent and PhysicalOperationDefinition changes, r515719
Posted by Jeremy Boynes <jb...@apache.org>.
On Mar 7, 2007, at 6:24 PM, Jim Marino wrote:
> It should be the Multiparent CL from the ClassLoaderRegistry. It
> looks like Jeremy got the multi-parent loading merged with the
> composite classloader in r515464. This classloader will load the
> impl class and we can use those to in turn load the param types.
I merged the multi-parent functionality into the CompositeClassLoader
but it is not yet used. I plan to revamp the loaders to use the
ClassLoaderRegistry rather than rely on the classloader in the
DeploymentContext.
The ClassLoader definition will be sent to the target runtime as part
of the PCS as one of the local resources. That should be there (in
the CLR) ready for you to use during physical build.
--
Jeremy
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: JavaComponent and PhysicalOperationDefinition changes, r515719
Posted by Jim Marino <jm...@myromatours.com>.
On Mar 7, 2007, at 1:50 PM, Meeraj Kunnumpurath wrote:
> Jim,
>
> Is the MPL available in the registry. Or is it going to be the app
> CL looked up from the registry and the MPCL created from the looked
> up app CL and the system CL?
>
> Ta
> Meeraj
>
It should be the Multiparent CL from the ClassLoaderRegistry. It
looks like Jeremy got the multi-parent loading merged with the
composite classloader in r515464. This classloader will load the impl
class and we can use those to in turn load the param types.
Jim
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: JavaComponent and PhysicalOperationDefinition changes, r515719
Posted by Meeraj Kunnumpurath <m....@hotmail.co.uk>.
Jim,
Is the MPL available in the registry. Or is it going to be the app CL looked
up from the registry and the MPCL created from the looked up app CL and the
system CL?
Ta
Meeraj
>From: Jim Marino <jm...@myromatours.com>
>Reply-To: tuscany-dev@ws.apache.org
>To: tuscany-dev@ws.apache.org
>Subject: Re: JavaComponent and PhysicalOperationDefinition changes, r515719
>Date: Wed, 7 Mar 2007 12:10:11 -0800
>
>Type below...
>
>On Mar 7, 2007, at 11:55 AM, Jim Marino wrote:
>
>>I've been working on getting the Physical marshalling and build
>>infrastructure integrated with the connector. In order to do this, I
>>changed the way types are being tracked on PhysicalOperationDefinition.
>>Instead of directly referencing the type's class, I changed it to track
>>the fully qualified name as a String. When the TargetInvoker is created
>>on JavaComponent, it will load the types using the classloader that
>>loaded the implementation class and map to the appropriate method using
>>getMethods().
>
>Should be "getMethod(..)"
>
>
>>
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
>For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>
_________________________________________________________________
MSN Hotmail is evolving check out the new Windows Live Mail
http://ideas.live.com
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: JavaComponent and PhysicalOperationDefinition changes, r515719
Posted by Jim Marino <jm...@myromatours.com>.
Type below...
On Mar 7, 2007, at 11:55 AM, Jim Marino wrote:
> I've been working on getting the Physical marshalling and build
> infrastructure integrated with the connector. In order to do this,
> I changed the way types are being tracked on
> PhysicalOperationDefinition. Instead of directly referencing the
> type's class, I changed it to track the fully qualified name as a
> String. When the TargetInvoker is created on JavaComponent, it will
> load the types using the classloader that loaded the implementation
> class and map to the appropriate method using getMethods().
Should be "getMethod(..)"
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org