Raymond Feng wrote:
Hi, Simon.
Are you proposing to have the following?
1) Define a InvokerPropertySet class such as:
public class InvokerPropertySet {
public boolean getAllowsPassByReference() {
...
}
public void setAllowsPassByReference(boolean flag) {
...
}
}
2) Pass it into the Invoker constructors so that invokers can set the
properties. What class is going to keep the property set?
Invokers are created by the createInvoker() methods of ImplementationProvider
and ReferenceBindingProvider. The InvokerPropertySet could be passed in as
an extra parameter on these calls.
You raise a good point about who will keep the property set information.
Needing the runtime keep hold of a separate InvokerPropertySet instance
for each Invoker instance that it has created seems like a large overhead.
I don't have a good solution for this.
I personally don't like the constructor approach too much because it
creates an implicit contract between the runtime and the Invoker
implementation class (not the Invoker interface).
+1. Passing it on createInvoker() solves this problem.
If we decide to go with the generic property, I would prefer to have the
following:
public interface Configurable {
<T> T getProperty(String name);
}
Can you say a bit more about how this would work? Is the Configurable
interface implemented by the invoker? How would this approach support
multiple different properties?
Simon
Thanks,
Raymond
----- Original Message ----- From: "Simon Nash" <[EMAIL PROTECTED]>
To: <[email protected]>
Sent: Saturday, February 16, 2008 8:23 AM
Subject: Re: svn commit: r628163 - in /incubator/tuscany/java/sca:
itest/interfaces/src/main/java/org/apache/tuscany/sca/itest/interfaces/
itest/interfaces/src/test/java/org/apache/tuscany/sca/itest/interfaces/
modules/binding-ejb/src/main/java/org/apache/tus
ant elder wrote:
On Feb 15, 2008 11:01 PM, Jean-Sebastien Delfino <[EMAIL PROTECTED]>
wrote:
Raymond Feng wrote:
My preference is to keep PassByValue as the prefix for the following
reasons.
1) The invokers implement this interface only for the cases to
enforece
pass-by-value for remotable interfaces. Invocations over local
interfaces (pass-by-reference) don't even care about this flag.
2) The allowsPassByReference() method basically tells if it's safe to
pass data as-is without violating the pass-by-value semantics.
Having a SomethingPassByValue interface provide an
allowsPassByReference
method is really confusing IMHO.
I think we should use a consistent terminology with either passByValue
or passByReference but not a mix of both.
+1 just to add agreement that its quite confusing like this.
...ant
I can provide lots of suggestions about naming :-) but I'd like to
question whether we even need this new interface. Creating a new
optional SPI to set a single boolean seems quite heavyweight. There
are other examples in the SPIs of this kind of pattern and I think
there's a better approach that's lighter-weight and more flexible.
This boolean is effectively an optional property of the invoker.
As part of creating an invoker, a "property sheet" object could be
passed to the invoker's constructor for it to fill in with the
optional properties that it supports. This allows invokers to
add support for more properties in future without the need to create
a new SPI interface every time we need a new property. All that
is needed is to add new setter/getter methods to the property sheet.
The same approach could be used to add new properties for other
SPI objects such as binding providers and implementation providers.
In terms of naming (I can't resist), I think this boolean is saying
"I (the invoker) will handle PassByValue semantics". So my naming
suggestion for the method or property is "handlesPassByValue".
Simon
---------------------------------------------------------------------
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]
