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 2006/08/10 04:33:25 UTC
Binding extension example
I've checked in an example of a simple binding (r430211) that
demonstrates creating services and references. For references, the
binding just echoes a single param back to the client.
Related to this, I've also completed a series of commits that move
application wiring from the responsibility of the builders to
initiate up into the builder registry which delegates to the system
wire service. Once a Service, Reference, or Component is created and
returned from a builder, the builder registry will invoke the wire
service to create the appropriate inbound and outbound wires. These
wires will then be injected into the Service, Reference or Component.
At a later point, the connector will bridge outbound (source) to
inbound (target) wires.
Services and References will generally not need to do anything other
than hold onto the wires (implemented as a convenience by the
extension base classes), but components are responsible for
implementing a strategy for injecting them onto implementation
instances as the latter are requested. In the case of Java, this
involves delegating back to the wire service to create a proxy
fronting the wire and implementing the appropriate reference
interface. This proxy will be injected onto an implementation
instance as it is created. BPEL or an other implementation type may
do something entirely different and maybe not even use proxies.
Certain types of composite components may need to manually bridge
Services to targets. For example, a Spring composite is opaque to the
SCA wiring fabric in that its beans are not visible as components.
The Spring builder is responsible for delegating to the builder
registry to create a service which it then must provide with a target
invoker capable of dispatching into the Spring application context
and to a target bean. This can be viewed as the SCA wiring mechanism
delegating to Spring for internal wiring.
Jim
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: Binding extension example
Posted by Jeremy Boynes <jb...@apache.org>.
What I am saying is that the documentation on clone() is quite
explicit about what it does and answers the questions that you raised.
"this method creates a new instance of the class of this object and
initializes all its fields with exactly the contents of the
corresponding fields of this object, as if by assignment; the
contents of the fields are not themselves cloned"
In other words, the object itself is duplicated at a low level by the
VM (allowing it to do things like clone final fields). This has the
effect of copying all primitives and object references. This is a
"shallow" copy because only the references to objects are copied and
not their nested contents.
This is ok if "a class contains only primitive fields or references
to immutable objects" and means that "no fields in the object
returned by super.clone need to be modified." So in this case where
the only field "cacheable" is a primitive it does not need to be set
on the clone.
Because Object.clone() applies to the entire object this behaviour
also applies to all subclasses. Only when a field contains a
reference to a mutable object does the subclass need to worry about
doing a deep copy of that referenced object.
As for RMIInvoker, the remoteMethod field is of type Method which is
effectively immutable and so does not need to be deep copied.
--
Jeremy
On Aug 11, 2006, at 7:53 AM, ant elder wrote:
> I'm not sure I understand what you're trying to say? The JavaDoc for
> TargetInvoker.clone says "Implementations must support deep cloning".
>
> ...ant
>
> On 8/11/06, Jeremy Boynes <jb...@apache.org> wrote:
>>
>> On Aug 11, 2006, at 7:36 AM, ant elder wrote:
>>
>> > I did wonder about this, doesn't it need to be a deep copy? I don't
>> > really
>> > understand the purpose of cacheable, but if its set on the one
>> > instance
>> > shouldn't it be also set on the clone? And do subclasses need to
>> > copy their
>> > fields? Say the RMI binding was using this abstract class should it
>> > setting
>> > the remoteMethod field on the clone?
>>
>> http://java.sun.com/j2se/1.5.0/docs/api/java/lang/Object.html#clone()
>>
>> And remember deep copy only applies to mutable objects
>> --
>> Jeremy
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
>> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>>
>>
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: Binding extension example
Posted by ant elder <an...@gmail.com>.
I'm not sure I understand what you're trying to say? The JavaDoc for
TargetInvoker.clone says "Implementations must support deep cloning".
...ant
On 8/11/06, Jeremy Boynes <jb...@apache.org> wrote:
>
> On Aug 11, 2006, at 7:36 AM, ant elder wrote:
>
> > I did wonder about this, doesn't it need to be a deep copy? I don't
> > really
> > understand the purpose of cacheable, but if its set on the one
> > instance
> > shouldn't it be also set on the clone? And do subclasses need to
> > copy their
> > fields? Say the RMI binding was using this abstract class should it
> > setting
> > the remoteMethod field on the clone?
>
> http://java.sun.com/j2se/1.5.0/docs/api/java/lang/Object.html#clone()
>
> And remember deep copy only applies to mutable objects
> --
> Jeremy
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>
>
Re: Binding extension example
Posted by Jeremy Boynes <jb...@apache.org>.
On Aug 11, 2006, at 7:36 AM, ant elder wrote:
> I did wonder about this, doesn't it need to be a deep copy? I don't
> really
> understand the purpose of cacheable, but if its set on the one
> instance
> shouldn't it be also set on the clone? And do subclasses need to
> copy their
> fields? Say the RMI binding was using this abstract class should it
> setting
> the remoteMethod field on the clone?
http://java.sun.com/j2se/1.5.0/docs/api/java/lang/Object.html#clone()
And remember deep copy only applies to mutable objects
--
Jeremy
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: Binding extension example
Posted by ant elder <an...@gmail.com>.
I did wonder about this, doesn't it need to be a deep copy? I don't really
understand the purpose of cacheable, but if its set on the one instance
shouldn't it be also set on the clone? And do subclasses need to copy their
fields? Say the RMI binding was using this abstract class should it setting
the remoteMethod field on the clone?
...ant
On 8/11/06, Jeremy Boynes <jb...@apache.org> wrote:
>
> On Aug 11, 2006, at 2:04 AM, ant elder wrote:
>
> > Ok I've added a TargetInvokerExtension. The clone method doesn't seem
> > perfect yet as subclasses now aren't forced to implement clone by the
> > compiler.
>
> I've not had coffee yet but AIUI you don't need to override clone in
> subclasses uouldnless you need a deep copy. The way it is implemented at
> the moment does an unnecessary copy of the cacheable field (as that
> member will be cloned by the implementation in Object.clone()).
>
> Something like this should work:
> Index: spi/src/main/java/org/apache/tuscany/spi/extension/
> TargetInvokerExtension.java
> ===================================================================
> --- spi/src/main/java/org/apache/tuscany/spi/extension/
> TargetInvokerExtension.java (revision 430795)
> +++ spi/src/main/java/org/apache/tuscany/spi/extension/
> TargetInvokerExtension.java (working copy)
> @@ -54,10 +54,13 @@
> return isCacheable();
> }
>
> - public Object clone() throws CloneNotSupportedException {
> - TargetInvokerExtension clonedInvoker =
> (TargetInvokerExtension) super.clone();
> - clonedInvoker.cacheable = this.cacheable;
> - return clonedInvoker;
> + public Object clone() {
> + try {
> + return super.clone();
> + } catch (CloneNotSupportedException e) {
> + // TargetInvoker extends Cloneable so this should not
> have been thrown
> + throw new AssertionError(e);
> + }
> }
> }
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>
>
Re: Binding extension example
Posted by Jeremy Boynes <jb...@apache.org>.
On Aug 11, 2006, at 2:04 AM, ant elder wrote:
> Ok I've added a TargetInvokerExtension. The clone method doesn't seem
> perfect yet as subclasses now aren't forced to implement clone by the
> compiler.
I've not had coffee yet but AIUI you don't need to override clone in
subclasses unless you need a deep copy. The way it is implemented at
the moment does an unnecessary copy of the cacheable field (as that
member will be cloned by the implementation in Object.clone()).
Something like this should work:
Index: spi/src/main/java/org/apache/tuscany/spi/extension/
TargetInvokerExtension.java
===================================================================
--- spi/src/main/java/org/apache/tuscany/spi/extension/
TargetInvokerExtension.java (revision 430795)
+++ spi/src/main/java/org/apache/tuscany/spi/extension/
TargetInvokerExtension.java (working copy)
@@ -54,10 +54,13 @@
return isCacheable();
}
- public Object clone() throws CloneNotSupportedException {
- TargetInvokerExtension clonedInvoker =
(TargetInvokerExtension) super.clone();
- clonedInvoker.cacheable = this.cacheable;
- return clonedInvoker;
+ public Object clone() {
+ try {
+ return super.clone();
+ } catch (CloneNotSupportedException e) {
+ // TargetInvoker extends Cloneable so this should not
have been thrown
+ throw new AssertionError(e);
+ }
}
}
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: Binding extension example
Posted by ant elder <an...@gmail.com>.
Ok I've added a TargetInvokerExtension. The clone method doesn't seem
perfect yet as subclasses now aren't forced to implement clone by the
compiler.
...ant
On 8/10/06, Jim Marino <jm...@myromatours.com> wrote:
>
> Yea we could do that. Probably the one invoke method that takes the
> payload from the message could be abstracted and if there is a
> special target type that needs access to message headers or something
> it could just override it. Do you want to create one as I'm out later
> today?
>
> Jim
>
> On Aug 10, 2006, at 5:35 AM, ant elder wrote:
>
> > Great stuff Jim, these changes look really good to me. Makes
> > implementing a
> > binding way easier.
> >
> > What do you think about having an abstract SPI class for the
> > TargetInvoker
> > which includes all the cachable, optimizable and invoke methods?
> >
> > ...ant
> >
> > On 8/10/06, Jim Marino <jm...@myromatours.com> wrote:
> >>
> >> I've checked in an example of a simple binding (r430211) that
> >> demonstrates creating services and references. For references, the
> >> binding just echoes a single param back to the client.
> >>
> >> Related to this, I've also completed a series of commits that move
> >> application wiring from the responsibility of the builders to
> >> initiate up into the builder registry which delegates to the system
> >> wire service. Once a Service, Reference, or Component is created and
> >> returned from a builder, the builder registry will invoke the wire
> >> service to create the appropriate inbound and outbound wires. These
> >> wires will then be injected into the Service, Reference or Component.
> >> At a later point, the connector will bridge outbound (source) to
> >> inbound (target) wires.
> >>
> >> Services and References will generally not need to do anything other
> >> than hold onto the wires (implemented as a convenience by the
> >> extension base classes), but components are responsible for
> >> implementing a strategy for injecting them onto implementation
> >> instances as the latter are requested. In the case of Java, this
> >> involves delegating back to the wire service to create a proxy
> >> fronting the wire and implementing the appropriate reference
> >> interface. This proxy will be injected onto an implementation
> >> instance as it is created. BPEL or an other implementation type may
> >> do something entirely different and maybe not even use proxies.
> >>
> >> Certain types of composite components may need to manually bridge
> >> Services to targets. For example, a Spring composite is opaque to the
> >> SCA wiring fabric in that its beans are not visible as components.
> >> The Spring builder is responsible for delegating to the builder
> >> registry to create a service which it then must provide with a target
> >> invoker capable of dispatching into the Spring application context
> >> and to a target bean. This can be viewed as the SCA wiring mechanism
> >> delegating to Spring for internal wiring.
> >>
> >> Jim
> >>
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> >> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
> >>
> >>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>
>
Re: Binding extension example
Posted by Jim Marino <jm...@myromatours.com>.
Yea we could do that. Probably the one invoke method that takes the
payload from the message could be abstracted and if there is a
special target type that needs access to message headers or something
it could just override it. Do you want to create one as I'm out later
today?
Jim
On Aug 10, 2006, at 5:35 AM, ant elder wrote:
> Great stuff Jim, these changes look really good to me. Makes
> implementing a
> binding way easier.
>
> What do you think about having an abstract SPI class for the
> TargetInvoker
> which includes all the cachable, optimizable and invoke methods?
>
> ...ant
>
> On 8/10/06, Jim Marino <jm...@myromatours.com> wrote:
>>
>> I've checked in an example of a simple binding (r430211) that
>> demonstrates creating services and references. For references, the
>> binding just echoes a single param back to the client.
>>
>> Related to this, I've also completed a series of commits that move
>> application wiring from the responsibility of the builders to
>> initiate up into the builder registry which delegates to the system
>> wire service. Once a Service, Reference, or Component is created and
>> returned from a builder, the builder registry will invoke the wire
>> service to create the appropriate inbound and outbound wires. These
>> wires will then be injected into the Service, Reference or Component.
>> At a later point, the connector will bridge outbound (source) to
>> inbound (target) wires.
>>
>> Services and References will generally not need to do anything other
>> than hold onto the wires (implemented as a convenience by the
>> extension base classes), but components are responsible for
>> implementing a strategy for injecting them onto implementation
>> instances as the latter are requested. In the case of Java, this
>> involves delegating back to the wire service to create a proxy
>> fronting the wire and implementing the appropriate reference
>> interface. This proxy will be injected onto an implementation
>> instance as it is created. BPEL or an other implementation type may
>> do something entirely different and maybe not even use proxies.
>>
>> Certain types of composite components may need to manually bridge
>> Services to targets. For example, a Spring composite is opaque to the
>> SCA wiring fabric in that its beans are not visible as components.
>> The Spring builder is responsible for delegating to the builder
>> registry to create a service which it then must provide with a target
>> invoker capable of dispatching into the Spring application context
>> and to a target bean. This can be viewed as the SCA wiring mechanism
>> delegating to Spring for internal wiring.
>>
>> Jim
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
>> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>>
>>
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: Binding extension example
Posted by ant elder <an...@gmail.com>.
Great stuff Jim, these changes look really good to me. Makes implementing a
binding way easier.
What do you think about having an abstract SPI class for the TargetInvoker
which includes all the cachable, optimizable and invoke methods?
...ant
On 8/10/06, Jim Marino <jm...@myromatours.com> wrote:
>
> I've checked in an example of a simple binding (r430211) that
> demonstrates creating services and references. For references, the
> binding just echoes a single param back to the client.
>
> Related to this, I've also completed a series of commits that move
> application wiring from the responsibility of the builders to
> initiate up into the builder registry which delegates to the system
> wire service. Once a Service, Reference, or Component is created and
> returned from a builder, the builder registry will invoke the wire
> service to create the appropriate inbound and outbound wires. These
> wires will then be injected into the Service, Reference or Component.
> At a later point, the connector will bridge outbound (source) to
> inbound (target) wires.
>
> Services and References will generally not need to do anything other
> than hold onto the wires (implemented as a convenience by the
> extension base classes), but components are responsible for
> implementing a strategy for injecting them onto implementation
> instances as the latter are requested. In the case of Java, this
> involves delegating back to the wire service to create a proxy
> fronting the wire and implementing the appropriate reference
> interface. This proxy will be injected onto an implementation
> instance as it is created. BPEL or an other implementation type may
> do something entirely different and maybe not even use proxies.
>
> Certain types of composite components may need to manually bridge
> Services to targets. For example, a Spring composite is opaque to the
> SCA wiring fabric in that its beans are not visible as components.
> The Spring builder is responsible for delegating to the builder
> registry to create a service which it then must provide with a target
> invoker capable of dispatching into the Spring application context
> and to a target bean. This can be viewed as the SCA wiring mechanism
> delegating to Spring for internal wiring.
>
> Jim
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>
>