You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tuscany.apache.org by ant elder <an...@gmail.com> on 2008/02/16 10:49:38 UTC
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
On Feb 15, 2008 11:01 PM, Jean-Sebastien Delfino <js...@apache.org>
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
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
Posted by Simon Nash <na...@apache.org>.
See responses inline below.
Simon
Jean-Sebastien Delfino wrote:
> 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.
>
There is a one-time breakage that prevents the need to ever break
compatibility to add more properties in the future. If we ever need
to add more properties beyond the current one that we are discussing
(very likely!), this is a win compared to other approaches that break
with every new property.
> - 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.
>
There is no increase in the total "surface area" of the SPI in terms
of methods. This approach simply separates properties from functional
methods by putting them on different 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.
>
Ownership of the InvokerProperties object transfers to the invoker object
when the invoker object is created. (This is why the invoker object
returns the InvokerProperties object.) When the invoker object is
destroyed, the InvokerProperties dies with it (by normal Java GC).
This all seems straightforward and clear to me.
> - 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.
>
As discussed above, there is a one-time breaking change to introduce
the new approach. InvokerProperties is an interface, so there is no
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.
>
VERY IMPORTANT... SPIs are of two different kinds, those that extensions
implement (like xxxProvider) and those that extensions use (like Message).
For the "extensions implement" kind, new methods cannot be added without
breakage. For the "extensions use" kind, new methods can be added without
breakage. This is a fundamental difference in terms of the ability to
support compatible evolution. However, it is not a difference that we
have highlighted in our current SPI design or documentation.
The reason we have the current problem is that invoker and provider
properties have been placed on "extensions implement" SPIs. For compatible
evolution, they should be placed on "extensions use" SPIs instead.
My proposal moves these properties from "extensions implement" SPIs to
"extensions use" SPIs. InvokerProperties would be an "extensions use" SPI
that should not be implemented by extension developers.
> - The InvokerProperties pattern does not address the bigger issue of all
> changes to other extension methods (createInvoker, or just the invoke
> method itself).
>
Neither do any of the other proposals that have been put forward.
> 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.
>
I think we should take reasonable steps to avoid the need to do this
where possible. The approach I have proposed does this.
> - 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.
>
There will be some (hopefully rare) cases where changes to extensions
can't be avoided, and the xxxSPI2 approach could be used for those
changes. Alternatively, such changes could be made as part of a
major release (see below).
> - 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 agree that from time to time some larger SPI refactoring will be
needed, and we should have the concept of a "major release" in which
such changes would be made. Between these major releases, I think
there should be no incompatible SPI changes. I think 9 months or so
would generally be a reasonable time interval between major releases.
Simon
> I'll be happy to vote on proposals though.
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: [DISCUSSION] PassByValue SPI, was: Re: svn commit: r628163
Posted by Simon Nash <na...@apache.org>.
Jean-Sebastien Delfino wrote:
> Simon Nash wrote:
> ...
>>> This is going in circles :) If you add a parameter to createInvoker
>>> to pass an InvokerProperties... then I have two questions:
>>> - who actually creates the InvokerProperties?
>> >
>> The Tuscany core runtime code that calls createInvoker().
>>
>>> - can it still be an interface implemented by the extension?
>>>
>> No. It's used by the extension but not implemented by it.
>
> I don't understand why. If my extension must implement InvokerProperties
> getInvokerProperties(); and InvokerProperties is an interface, I should
> be able to provide my own implementation of InvokerProperties.
>
I tried to explain the reason in [1]. Apologies if that wasn't clear.
I'll try again here.
SPI interfaces divide into two categories: those that are intended for
extensions to implement, and those that are intended for extensions
to use.
This is a very important distinction because it affects what changes
can be made to the interface without breaking compatibility with
existing extensions.
For interfaces that are intended for extensions to implement, adding
a new method breaks compatibility. Removing a method does not break
compatibility.
For interfaces that are intended for extensions to use, adding a new
method does not break compatibility. Removing a method breaks
compatibility.
My InvokerProperties proposal is designed to allow new methods to be
added to the InvokerProperties interface without breaking compatibility
with existing extensions. This requires InvokerProperties to be an
interface that is intended for extensions to use, and not an interface
that is intended for extensions to implement. If it were intended for
extensions to implement, it would not be possible to add new methods
to it without breaking compatibility.
Simon
[1] http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg28292.html
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: [DISCUSSION] PassByValue SPI, was: Re: svn commit: r628163
Posted by Jean-Sebastien Delfino <js...@apache.org>.
Simon Nash wrote:
...
>> This is going in circles :) If you add a parameter to createInvoker to
>> pass an InvokerProperties... then I have two questions:
>> - who actually creates the InvokerProperties?
> >
> The Tuscany core runtime code that calls createInvoker().
>
>> - can it still be an interface implemented by the extension?
>>
> No. It's used by the extension but not implemented by it.
I don't understand why. If my extension must implement InvokerProperties
getInvokerProperties(); and InvokerProperties is an interface, I should
be able to provide my own implementation of InvokerProperties.
--
Jean-Sebastien
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: [DISCUSSION] PassByValue SPI, was: Re: svn commit: r628163
Posted by Simon Nash <na...@apache.org>.
Answers inline.
Simon
Jean-Sebastien Delfino wrote:
> Simon Nash wrote:
>> 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).
>>
>
> This is going in circles :) If you add a parameter to createInvoker to
> pass an InvokerProperties... then I have two questions:
> - who actually creates the InvokerProperties?
>
The Tuscany core runtime code that calls createInvoker().
> - can it still be an interface implemented by the extension?
>
No. It's used by the extension but not implemented by it.
See [1] for a more detailed explanation.
Simon
[1] http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg28292.html
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: [DISCUSSION] PassByValue SPI, was: Re: svn commit: r628163
Posted by Jean-Sebastien Delfino <js...@apache.org>.
Simon Nash wrote:
> 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).
>
This is going in circles :) If you add a parameter to createInvoker to
pass an InvokerProperties... then I have two questions:
- who actually creates the InvokerProperties?
- can it still be an interface implemented by the extension?
--
Jean-Sebastien
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: [DISCUSSION] PassByValue SPI, was: Re: svn commit: r628163
Posted by Simon Nash <na...@apache.org>.
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/tuscany-dev@ws.apache.org/msg28293.html
[2] http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg28086.html
> Thanks,
> Raymond
>
> ----- Original Message ----- From: "Jean-Sebastien Delfino"
> <js...@apache.org>
> To: <tu...@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: tuscany-dev-unsubscribe@ws.apache.org
>> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: [DISCUSSION] PassByValue SPI, was: Re: svn commit: r628163
Posted by Simon Nash <na...@apache.org>.
Jean-Sebastien Delfino wrote:
> Raymond Feng wrote:
>> 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) {
>> ...
>> }
>> }
>>
>
> I'm going to repeat what I said earlier in this thread, but in context
> now with your code example: This makes extensions depend on a Tuscany
> implementation class, InvokerProperties.
>
> The getProperties() method will look like {
> return new InvokerProperties();
> }
>
> A very slippery slope IMHO.
>
I agree that this is not desirable. I think the original version that
I proposed has a cleaner separation between Tuscany code and extension code,
even though it has a slightly larger set of changes. See [1] for an
explanation of te design rationale behind my proposal.
Simon
[1] http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg28292.html
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: [DISCUSSION] PassByValue SPI, was: Re: svn commit: r628163
Posted by Jean-Sebastien Delfino <js...@apache.org>.
Raymond Feng wrote:
> 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) {
> ...
> }
> }
>
I'm going to repeat what I said earlier in this thread, but in context
now with your code example: This makes extensions depend on a Tuscany
implementation class, InvokerProperties.
The getProperties() method will look like {
return new InvokerProperties();
}
A very slippery slope IMHO.
--
Jean-Sebastien
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
[DISCUSSION] PassByValue SPI, was: Re: svn commit: r628163
Posted by Raymond Feng <en...@gmail.com>.
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" <js...@apache.org>
To: <tu...@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: tuscany-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
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
Posted by Jean-Sebastien Delfino <js...@apache.org>.
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: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
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
Posted by Simon Nash <na...@apache.org>.
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.
Simon
Jean-Sebastien Delfino wrote:
>>> Raymond Feng wrote:
>>> I agree stability/compatibility is important. But we need to have a
>>> good balance here. If we always sacrifice the architectural cleaness
>>> to stability, we may end up with messy SPIs which will confuse our
>>> new users. Especially for SPIs, they are used by extension developers
>>> and embedders and (IMO) these types of users are more willing to use
>>> the latest code base.
>
>> Simon Nash wrote:
>> I thought my proposal (see [1]) was a reasonable compromise that provided
>> stability without making too much of an architectural mess. There is a
>> one-time compatibilty hit to introduce the new approach, though. I'd be
>> interested to know what others think of this.
>
> [1]
> http://mail-archives.apache.org/mod_mbox/ws-tuscany-dev/200802.mbox/%3c47BABF84.5080905@apache.org%3e
>
>
> >>>> > Jean-Sebastien Delfino wrote:
>>>>> > 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();
>>>>> >
>>>>> > }
>>>>> >
>>>>> > 2) or if we want to preserve binary compatibility for now, create
>>>>> > interface Invoker2 extends Invoker {
>>>>> >
>>>>> > boolean allowsPassByReference();
>>>>> >
>>>>> > boolean isOneWay();
>>>>> >
>>>>> > }
>>>>> >
>
> 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.
>
By the "next major release" do you mean the 1.2 release that we recently
started discussing, or something else?
Simon
> 3. Simon's proposal [1], which introduces too much complexity IMHO.
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
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
Posted by Jean-Sebastien Delfino <js...@apache.org>.
>> Raymond Feng wrote:
>> I agree stability/compatibility is important. But we need to have a
>> good balance here. If we always sacrifice the architectural cleaness
>> to stability, we may end up with messy SPIs which will confuse our new
>> users. Especially for SPIs, they are used by extension developers and
>> embedders and (IMO) these types of users are more willing to use the
>> latest code base.
> Simon Nash wrote:
> I thought my proposal (see [1]) was a reasonable compromise that provided
> stability without making too much of an architectural mess. There is a
> one-time compatibilty hit to introduce the new approach, though. I'd be
> interested to know what others think of this.
[1]
http://mail-archives.apache.org/mod_mbox/ws-tuscany-dev/200802.mbox/%3c47BABF84.5080905@apache.org%3e
>>>> > Jean-Sebastien Delfino wrote:
>>>> > 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();
>>>> >
>>>> > }
>>>> >
>>>> > 2) or if we want to preserve binary compatibility for now, create
>>>> > interface Invoker2 extends Invoker {
>>>> >
>>>> > boolean allowsPassByReference();
>>>> >
>>>> > boolean isOneWay();
>>>> >
>>>> > }
>>>> >
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.
3. Simon's proposal [1], which introduces too much complexity IMHO.
--
Jean-Sebastien
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
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
Posted by Simon Nash <na...@apache.org>.
See inline.
Simon
Raymond Feng wrote:
> I agree stability/compatibility is important. But we need to have a good
> balance here. If we always sacrifice the architectural cleaness to
> stability, we may end up with messy SPIs which will confuse our new
> users. Especially for SPIs, they are used by extension developers and
> embedders and (IMO) these types of users are more willing to use the
> latest code base.
>
I thought my proposal (see [1]) was a reasonable compromise that provided
stability without making too much of an architectural mess. There is a
one-time compatibilty hit to introduce the new approach, though. I'd be
interested to know what others think of this.
Simon
[1] http://mail-archives.apache.org/mod_mbox/ws-tuscany-dev/200802.mbox/%3c47BABF84.5080905@apache.org%3e
> Thanks,
> Raymond
>
> ----- Original Message ----- From: "ant elder" <an...@gmail.com>
> To: <tu...@ws.apache.org>
> Sent: Thursday, February 21, 2008 1:26 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
>
>
>> -1 on option (1) for now as i think backward compatibility is important.
>>
>> It doesn't matter how trivial the fix is if a release upgrade breaks
>> someones code then we may loose them as Tuscany user. We did loose users
>> back in the Mx release days as we kept changing the SPIs, we made all the
>> fuss about having stable SPIs for the 1.0 release and I think we should
>> honour that.
>>
>> Note this -1 isn't a veto, just expressing an opinion.
>>
>> ...ant
>>
>> On Tue, Feb 19, 2008 at 4:53 AM, Raymond Feng <en...@gmail.com>
>> 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" <js...@apache.org>
>>> To: <tu...@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" <na...@apache.org>
>>> >> To: <tu...@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'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();
>>> >
>>> > }
>>> >
>>> > 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.
>>> > --
>>> > Jean-Sebastien
>>> >
>>> > ---------------------------------------------------------------------
>>> > To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
>>> > For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>>> >
>>>
>>>
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
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
Posted by Raymond Feng <en...@gmail.com>.
I agree stability/compatibility is important. But we need to have a good
balance here. If we always sacrifice the architectural cleaness to
stability, we may end up with messy SPIs which will confuse our new users.
Especially for SPIs, they are used by extension developers and embedders and
(IMO) these types of users are more willing to use the latest code base.
Thanks,
Raymond
----- Original Message -----
From: "ant elder" <an...@gmail.com>
To: <tu...@ws.apache.org>
Sent: Thursday, February 21, 2008 1:26 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
> -1 on option (1) for now as i think backward compatibility is important.
>
> It doesn't matter how trivial the fix is if a release upgrade breaks
> someones code then we may loose them as Tuscany user. We did loose users
> back in the Mx release days as we kept changing the SPIs, we made all the
> fuss about having stable SPIs for the 1.0 release and I think we should
> honour that.
>
> Note this -1 isn't a veto, just expressing an opinion.
>
> ...ant
>
> On Tue, Feb 19, 2008 at 4:53 AM, Raymond Feng <en...@gmail.com> 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" <js...@apache.org>
>> To: <tu...@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" <na...@apache.org>
>> >> To: <tu...@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'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();
>> >
>> > }
>> >
>> > 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.
>> > --
>> > Jean-Sebastien
>> >
>> > ---------------------------------------------------------------------
>> > To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
>> > For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>> >
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
>> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>>
>>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
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
Posted by ant elder <an...@gmail.com>.
-1 on option (1) for now as i think backward compatibility is important.
It doesn't matter how trivial the fix is if a release upgrade breaks
someones code then we may loose them as Tuscany user. We did loose users
back in the Mx release days as we kept changing the SPIs, we made all the
fuss about having stable SPIs for the 1.0 release and I think we should
honour that.
Note this -1 isn't a veto, just expressing an opinion.
...ant
On Tue, Feb 19, 2008 at 4:53 AM, Raymond Feng <en...@gmail.com> 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" <js...@apache.org>
> To: <tu...@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" <na...@apache.org>
> >> To: <tu...@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'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();
> >
> > }
> >
> > 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.
> > --
> > Jean-Sebastien
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> > For additional commands, e-mail: tuscany-dev-help@ws.apache.org
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>
>
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
Posted by Venkata Krishnan <fo...@gmail.com>.
Hi,
I seem to liking Raymond's suggestion of 'Configurable' interface which will
have methods for setting and getting properties by name. Seems simple and
helps in keeping up binary compatibility. There is something similar we
have done to bring in support for policies where any implementation or
binding that supports policies simply implements the attach point
interfaces. This has let us keep bindings and impls that don't support
policies without any change.
- Venkat
On Feb 19, 2008 5:07 PM, Simon Nash <na...@apache.org> wrote:
> 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"
> > <js...@apache.org>
> > To: <tu...@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" <na...@apache.org>
> >>> To: <tu...@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: tuscany-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>
>
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
Posted by Simon Nash <na...@apache.org>.
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"
> <js...@apache.org>
> To: <tu...@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" <na...@apache.org>
>>> To: <tu...@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: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
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
Posted by Raymond Feng <en...@gmail.com>.
+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" <js...@apache.org>
To: <tu...@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" <na...@apache.org>
>> To: <tu...@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'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();
>
> }
>
> 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.
> --
> Jean-Sebastien
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
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
Posted by Jean-Sebastien Delfino <js...@apache.org>.
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" <na...@apache.org>
> To: <tu...@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'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();
}
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.
--
Jean-Sebastien
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
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
Posted by Raymond Feng <en...@gmail.com>.
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" <na...@apache.org>
To: <tu...@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
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
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
Posted by Simon Nash <na...@apache.org>.
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
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
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
Posted by Raymond Feng <en...@gmail.com>.
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.
Thanks,
Raymond
----- Original Message -----
From: "Simon Nash" <na...@apache.org>
To: <tu...@ws.apache.org>
Sent: Monday, February 18, 2008 12:41 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:
>> 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" <na...@apache.org>
>> To: <tu...@ws.apache.org>
>> 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 <js...@apache.org>
>>>> 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: tuscany-dev-unsubscribe@ws.apache.org
>>> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>>>
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
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
Posted by Simon Nash <na...@apache.org>.
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" <na...@apache.org>
> To: <tu...@ws.apache.org>
> 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 <js...@apache.org>
>>> 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: tuscany-dev-unsubscribe@ws.apache.org
>> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
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
Posted by Raymond Feng <en...@gmail.com>.
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?
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).
If we decide to go with the generic property, I would prefer to have the
following:
public interface Configurable {
<T> T getProperty(String name);
}
Thanks,
Raymond
----- Original Message -----
From: "Simon Nash" <na...@apache.org>
To: <tu...@ws.apache.org>
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 <js...@apache.org>
>> 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: tuscany-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
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
Posted by Simon Nash <na...@apache.org>.
ant elder wrote:
> On Feb 15, 2008 11:01 PM, Jean-Sebastien Delfino <js...@apache.org>
> 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: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org