Hi,
I think Simon's proposal should work as follows instead of passing the
properties to the createInvoker() call.
public interface Invoker {
InvokerProperties getProperties(); // Contribute properties
}
public class InvokerProperties {
public void setAllowsPassByReference(boolean allowsPBR) {
....
}
public boolean allowsPassByReference() {
....
}
// Add more properties without impacting the Invoker interface
public AnotherPropertyType getAnotherProperty() {
...
}
public void setAnotherProperty(AnotherPropertyType anotherProp) {
...
}
}
So the difference is whether having simple properties on the Invoker
interface or defining a complex property as a collection of properties.
Anyway, since we have different opinions, I'm OK to have a vote to get it
decided.
So far we have the following options on the table:
1) Add "allowsPassByReference()" to the Invoker interface directly
2) Add "getInvokerProperties()" to the Invoker interface directly and the
InvokerProperties will encapasulate known properties including
"allowsPassByReference".
3) Add "allowsPassByReference()" to an optional SPI (either a separate
interface or a sub-interface of Invoker)
4) Add "getInvokerProperties()" to an optional SPI (either a separate
interface or a sub-interface of Invoker)
Please add your options if I miss them before we call a vote.
Thanks,
Raymond
----- Original Message -----
From: "Jean-Sebastien Delfino" <[EMAIL PROTECTED]>
To: <tuscany-dev@ws.apache.org>
Sent: Friday, February 22, 2008 12:14 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
Simon Nash wrote:
I'm wondering whether it would be good to have a vote about this.
Of the five people who have expressed a view on this so far, four
of them have had a different first preference. In the interests
of making progress, I think it might be good to put forward a set
of options and vote to choose between them.
One question of clarification inline below.
...
>> Jean-Sebastien Delfino wrote:
My preference:
1. (1) above add a method to Invoker, and ask people on our dev and user
mailing lists if they have any issues with it.
2. (2) above and a plan to merge all these Xyz2 interfaces into the main
interfaces in the next major release.
> Simon Nash wrote:
By the "next major release" do you mean the 1.2 release that we recently
started discussing, or something else?
Difficult to say until more discussion shapes 1.2 :) I mean major enough
to introduce significant SPI changes.
3. Simon's proposal [1], which introduces too much complexity IMHO.
A few more concerns with that proposal:
- It introduces a breaking change as well.
- An extension developer will have to work with two objects instead of
one. The same technique applied to other extension points (provider,
artifactprocessor, resolver) will double the number of interfaces.
- Ownership and lifecycle of InvokerProperties are unclear. I don't see
why an Invoker should return InvokerProperties if it's already passed to
it. I don't understand when an Invoker should initialize that properties
object.
- Unless I'm missing something, it will require a breaking change to
Provider.createInvoker() to pass an InvokerProperties, or a dependency on
a Tuscany InvokerProperties implementation class.
- If InvokerProperties is an interface then an extension developer can
implement it, and will be broken again as soon as a new property is added.
- The InvokerProperties pattern does not address the bigger issue of all
changes to other extension methods (createInvoker, or just the invoke
method itself).
The fundamental question remains: Can we add methods to an interface
implemented by an extension? and my opinion is:
- Yes, if the change is straightforward and publicly communicated.
- No, if it requires significant changes to extensions. We then need
another version of the interface (like Invoker2) and support both versions
until the two interfaces get merged.
- It should be possible to introduce in a release SPI cleanup, merging,
refactoring and evolutions, at a reasonable pace. I am not saying that we
should do this in the upcoming 1.2 release, but I'd like to see some SPI
cleanup happen in a reasonable timeframe. They have been close to frozen
for 9 months now.
I'll be happy to vote on proposals though.
--
Jean-Sebastien
---------------------------------------------------------------------
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]
