Comments inline.
Simon
Raymond Feng wrote:
+1 on Option 1) which is something I'm scared to propose these days as
we want to keep the SPIs binary compatible :-). I prefer to have an
explict, clean and strongly-typed contract.
Thanks,
Raymond
----- Original Message ----- From: "Jean-Sebastien Delfino"
<[EMAIL PROTECTED]>
To: <tuscany-dev@ws.apache.org>
Sent: Monday, February 18, 2008 6:50 PM
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
Raymond Feng wrote:
We could simply use Object as the return value and then cast it to
the type of the property.
The caller code could perform the test as follows:
if(invoker instanceof Configurable) {
boolean allowsPBR = ((Configurable)
invoker).getProperty("AllowsPassByReference");
if(allowsPBR) {
// do something here
}
}
Thanks,
Raymond
----- Original Message ----- From: "Simon Nash" <[EMAIL PROTECTED]>
To: <tuscany-dev@ws.apache.org>
Sent: Monday, February 18, 2008 3:15 PM
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
Raymond Feng wrote:
The Configurable interface can be optionally implemented by the
Invoker implementation classes. To support multiple properties, the
invoker can simply do this:
public class MyInvokerImpl implements Invoker, Configurable {
...
<T> public T getProperty(String name) {
if("AllowsPassByReference".equals(name) {
return true;
} else if("AnotherProperty".equals(name) {
return "StringValue";
} else {
return null;
}
}
}
This way, the property set is kept at the invoker instances.
I didn't know that generics could do this, with multiple return
types from a single method. (Seems like I need to go back to
Java school!) What does the code invoking the magical getProperty()
method look like?
Simon
Sorry, but after looking at this again I think that it's getting way
too complicated. Can we please keep this SPI simple?
I agree that the fully dynamic approach with generic multi-typed
returns and casting from Object looks too complicated. However,
I think there are ways to keep the other approach with statically
defined properties simple.
I'd like to propose two options:
1) Add methods to Invoker, mirroring what's described in the spec.
interface Invoker {
boolean allowsPassByReference();
// and another similar method which we'll need to handle
// non-blocking calls
boolean isOneWay();
This is a property of an interface definition, not a property of
the implementation like allowsPassByReference. It's already available
on the Operation interface (though rather confusingly spelt
"isNonBlocking"). Why would we need this on Invoker as well as
on Operation?
}
2) or if we want to preserve binary compatibility for now, create
interface Invoker2 extends Invoker {
boolean allowsPassByReference();
boolean isOneWay();
}
IMHO it's OK to ask Invoker implementors to add two empty methods when
they port their code to the next release, so I'll prefer option (1) as
it's simpler.
>>
I think it's a problem having to either break compatibility or introduce
a new sub-interface every time we add a new optional property. When
adding a functional method containing executable code, we can't avoid
this, but simple properties can be handled in a different way.
The one-time hit to add new methods everywhere can be managed (though I
was surprised to find as many as 28 classes in Tuscany that implement
Invoker, plus whatever code users have added for extensions). It's the
ongoing need to go through this exercise every time we need a new
optional property that is bothering me.
Here's a proposal for how to do this that's simple, strongly typed,
and doesn't have compatibility issues.
1. Introduce a new interface InvokerProperties with strongly typed
methods for all optional invoker properties (as Raymond proposed
earlier in this thread).
2. Pass an instance of this interface on the createInvoker() method.
The invoker sets the properties that it needs and retains a
reference to the object that was passed in.
3. Add a new method getProperties() to the Invoker interface. This
method returns the InvokerProperties object that was passed on
createInvoker().
4. Properties are queried by code like the following:
anInvoker.getProperties().allowPassByReference()
anInvoker.getProperties().getSomeNewXXXProperty()
There is a one-time incompatible change to the SPIs to add the new
properties parameter to createInvoker() and the new getProperties()
method to the Invoker interface. After this, new optional properties
can be added at any time without any source or binary compatibility
impact to invokers that doesn't want to use them.
Simon
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
