Re: Binding extension example
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 [EMAIL PROTECTED] 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 [EMAIL PROTECTED] 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Binding extension example
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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Binding extension example
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 [EMAIL PROTECTED] 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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Binding extension example
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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Binding extension example
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 [EMAIL PROTECTED] 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Binding extension example
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 [EMAIL PROTECTED] 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Binding extension example
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 [EMAIL PROTECTED] 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Binding extension example
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 [EMAIL PROTECTED] 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
