See inline.
Simon
Raymond Feng wrote:
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.
I'm not very keen on this modification to my proposal. See [1] for
the reason why.
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.
Please add my proposal as described in [2] (using interfaces not classes,
and adding a parameter to the createInvoker() method).
Simon
[1] http://www.mail-archive.com/[email protected]/msg28293.html
[2] http://www.mail-archive.com/[email protected]/msg28086.html
Thanks,
Raymond
----- Original Message ----- From: "Jean-Sebastien Delfino"
<[EMAIL PROTECTED]>
To: <[email protected]>
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]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
