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
Given that this interface allows an Invoker to implement an allowsPassByReference method, could we rename PassByValueAware to PassByReferenceInvoker? [EMAIL PROTECTED] wrote: Author: rfeng Date: Fri Feb 15 12:26:39 2008 New Revision: 628163 URL: http://svn.apache.org/viewvc?rev=628163&view=rev Log: Add the PassByValueAware as an optional SPI for Invoker/Intercetors to support Pass-by-value -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
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
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. Initially, I was thinking about PassByValueInvoker but I found it a bit misleading as it doesn't extend from the Invoker interface. Just my 2c. Thanks, Raymond - Original Message - From: "Jean-Sebastien Delfino" <[EMAIL PROTECTED]> To: Sent: Friday, February 15, 2008 12:38 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/tuscany/s... Given that this interface allows an Invoker to implement an allowsPassByReference method, could we rename PassByValueAware to PassByReferenceInvoker? [EMAIL PROTECTED] wrote: Author: rfeng Date: Fri Feb 15 12:26:39 2008 New Revision: 628163 URL: http://svn.apache.org/viewvc?rev=628163&view=rev Log: Add the PassByValueAware as an optional SPI for Invoker/Intercetors to support Pass-by-value -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
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
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. Initially, I was thinking about PassByValueInvoker but I found it a bit misleading as it doesn't extend from the Invoker interface. OK, let's scratch Invoker. I'm OK with xyzAware instead of xyzInvoker. Just my 2c. -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
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
How about something like DataPassingStyle or DataPassingStrategy? Thanks, Raymond - Original Message - From: "Jean-Sebastien Delfino" <[EMAIL PROTECTED]> To: Sent: Friday, February 15, 2008 3:01 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/tuscany/s 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. Initially, I was thinking about PassByValueInvoker but I found it a bit misleading as it doesn't extend from the Invoker interface. OK, let's scratch Invoker. I'm OK with xyzAware instead of xyzInvoker. Just my 2c. -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
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
Raymond Feng wrote: How about something like DataPassingStyle or DataPassingStrategy? This is not a big issue and I would not seriously -1 any name even if you just called it the XyzStyle but I'd like to understand why we'd use a different term from the term used in the spec, and if we did, how we would explain to our users: (a) why we used a different term for the same concept or (b) if it's actually a different concept, how different it is from what's described in the spec, why we needed that new concept, and how it maps to the concept from the spec. -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
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
It's not a big deal and I'm not good at naming :-). I agree with you that we should be able to explain it to extension developers for the name we pick (maybe a good javadoc will help:-). My understanding is that the SCA spec uses "allowsPassByReference" to customize the data exchange sementics for remotable interfaces which is the default to Pass-By-Value. Line 707, 725, 737 of the Assembly Spec consitently uses the term "data exchange semantics". So we could use a name like "DataExchangeSemantics". Thanks, Raymond - Original Message - From: "Jean-Sebastien Delfino" <[EMAIL PROTECTED]> To: Sent: Friday, February 15, 2008 4:25 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/tuscany/s Raymond Feng wrote: How about something like DataPassingStyle or DataPassingStrategy? This is not a big issue and I would not seriously -1 any name even if you just called it the XyzStyle but I'd like to understand why we'd use a different term from the term used in the spec, and if we did, how we would explain to our users: (a) why we used a different term for the same concept or (b) if it's actually a different concept, how different it is from what's described in the spec, why we needed that new concept, and how it maps to the concept from the spec. -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
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
On Feb 15, 2008 11:01 PM, Jean-Sebastien Delfino <[EMAIL PROTECTED]> wrote: > Raymond Feng wrote: > > My preference is to keep PassByValue as the prefix for the following > > reasons. > > > > 1) The invokers implement this interface only for the cases to enforece > > pass-by-value for remotable interfaces. Invocations over local > > interfaces (pass-by-reference) don't even care about this flag. > > > > 2) The allowsPassByReference() method basically tells if it's safe to > > pass data as-is without violating the pass-by-value semantics. > > Having a SomethingPassByValue interface provide an allowsPassByReference > method is really confusing IMHO. > > I think we should use a consistent terminology with either passByValue > or passByReference but not a mix of both. > +1 just to add agreement that its quite confusing like this. ...ant
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
ant elder wrote: On Feb 15, 2008 11:01 PM, Jean-Sebastien Delfino <[EMAIL PROTECTED]> wrote: Raymond Feng wrote: My preference is to keep PassByValue as the prefix for the following reasons. 1) The invokers implement this interface only for the cases to enforece pass-by-value for remotable interfaces. Invocations over local interfaces (pass-by-reference) don't even care about this flag. 2) The allowsPassByReference() method basically tells if it's safe to pass data as-is without violating the pass-by-value semantics. Having a SomethingPassByValue interface provide an allowsPassByReference method is really confusing IMHO. I think we should use a consistent terminology with either passByValue or passByReference but not a mix of both. +1 just to add agreement that its quite confusing like this. ...ant I can provide lots of suggestions about naming :-) but I'd like to question whether we even need this new interface. Creating a new optional SPI to set a single boolean seems quite heavyweight. There are other examples in the SPIs of this kind of pattern and I think there's a better approach that's lighter-weight and more flexible. This boolean is effectively an optional property of the invoker. As part of creating an invoker, a "property sheet" object could be passed to the invoker's constructor for it to fill in with the optional properties that it supports. This allows invokers to add support for more properties in future without the need to create a new SPI interface every time we need a new property. All that is needed is to add new setter/getter methods to the property sheet. The same approach could be used to add new properties for other SPI objects such as binding providers and implementation providers. In terms of naming (I can't resist), I think this boolean is saying "I (the invoker) will handle PassByValue semantics". So my naming suggestion for the method or property is "handlesPassByValue". Simon - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
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
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 getProperty(String name);
}
Thanks,
Raymond
- Original Message -
From: "Simon Nash" <[EMAIL PROTECTED]>
To:
Sent: Saturday, February 16, 2008 8:23 AM
Subject: Re: svn commit: r628163 - in /incubator/tuscany/java/sca:
itest/interfaces/src/main/java/org/apache/tuscany/sca/itest/interfaces/
itest/interfaces/src/test/java/org/apache/tuscany/sca/itest/interfaces/
modules/binding-ejb/src/main/java/org/apache/tus
ant elder wrote:
On Feb 15, 2008 11:01 PM, Jean-Sebastien Delfino <[EMAIL PROTECTED]>
wrote:
Raymond Feng wrote:
My preference is to keep PassByValue as the prefix for the following
reasons.
1) The invokers implement this interface only for the cases to enforece
pass-by-value for remotable interfaces. Invocations over local
interfaces (pass-by-reference) don't even care about this flag.
2) The allowsPassByReference() method basically tells if it's safe to
pass data as-is without violating the pass-by-value semantics.
Having a SomethingPassByValue interface provide an allowsPassByReference
method is really confusing IMHO.
I think we should use a consistent terminology with either passByValue
or passByReference but not a mix of both.
+1 just to add agreement that its quite confusing like this.
...ant
I can provide lots of suggestions about naming :-) but I'd like to
question whether we even need this new interface. Creating a new
optional SPI to set a single boolean seems quite heavyweight. There
are other examples in the SPIs of this kind of pattern and I think
there's a better approach that's lighter-weight and more flexible.
This boolean is effectively an optional property of the invoker.
As part of creating an invoker, a "property sheet" object could be
passed to the invoker's constructor for it to fill in with the
optional properties that it supports. This allows invokers to
add support for more properties in future without the need to create
a new SPI interface every time we need a new property. All that
is needed is to add new setter/getter methods to the property sheet.
The same approach could be used to add new properties for other
SPI objects such as binding providers and implementation providers.
In terms of naming (I can't resist), I think this boolean is saying
"I (the invoker) will handle PassByValue semantics". So my naming
suggestion for the method or property is "handlesPassByValue".
Simon
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
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
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 getProperty(String name);
}
Can you say a bit more about how this would work? Is the Configurable
interface implemented by the invoker? How would this approach support
multiple different properties?
Simon
Thanks,
Raymond
- Original Message - From: "Simon Nash" <[EMAIL PROTECTED]>
To:
Sent: Saturday, February 16, 2008 8:23 AM
Subject: Re: svn commit: r628163 - in /incubator/tuscany/java/sca:
itest/interfaces/src/main/java/org/apache/tuscany/sca/itest/interfaces/
itest/interfaces/src/test/java/org/apache/tuscany/sca/itest/interfaces/
modules/binding-ejb/src/main/java/org/apache/tus
ant elder wrote:
On Feb 15, 2008 11:01 PM, Jean-Sebastien Delfino <[EMAIL PROTECTED]>
wrote:
Raymond Feng wrote:
My preference is to keep PassByValue as the prefix for the following
reasons.
1) The invokers implement this interface only for the cases to
enforece
pass-by-value for remotable interfaces. Invocations over local
interfaces (pass-by-reference) don't even care about this flag.
2) The allowsPassByReference() method basically tells if it's safe to
pass data as-is without violating the pass-by-value semantics.
Having a SomethingPassByValue interface provide an
allowsPassByReference
method is really confusing IMHO.
I think we should use a consistent terminology with either passByValue
or passByReference but not a mix of both.
+1 just to add agreement that its quite confusing like this.
...ant
I can provide lots of suggestions about naming :-) but I'd like to
question whether we even need this new interface. Creating a new
optional SPI to set a single boolean seems quite heavyweight. There
are other examples in the SPIs of this kind of pattern and I think
there's a better approach that's lighter-weight and more flexible.
This boolean is effectively an optional property of the invoker.
As part of creating an invoker, a "property sheet" object could be
passed to the invoker's constructor for it to fill in with the
optional properties that it supports. This allows invokers to
add support for more properties in future without the need to create
a new SPI interface every time we need a new property. All that
is needed is to add new setter/getter methods to the property sheet.
The same approach could be used to add new properties for other
SPI objects such as binding providers and implementation providers.
In terms of naming (I can't resist), I think this boolean is saying
"I (the invoker) will handle PassByValue semantics". So my naming
suggestion for the method or property is "handlesPassByValue".
Simon
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
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
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 {
...
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" <[EMAIL PROTECTED]>
To:
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 getProperty(String name);
}
Can you say a bit more about how this would work? Is the Configurable
interface implemented by the invoker? How would this approach support
multiple different properties?
Simon
Thanks,
Raymond
- Original Message - From: "Simon Nash" <[EMAIL PROTECTED]>
To:
Sent: Saturday, February 16, 2008 8:23 AM
Subject: Re: svn commit: r628163 - in /incubator/tuscany/java/sca:
itest/interfaces/src/main/java/org/apache/tuscany/sca/itest/interfaces/
itest/interfaces/src/test/java/org/apache/tuscany/sca/itest/interfaces/
modules/binding-ejb/src/main/java/org/apache/tus
ant elder wrote:
On Feb 15, 2008 11:01 PM, Jean-Sebastien Delfino <[EMAIL PROTECTED]>
wrote:
Raymond Feng wrote:
My preference is to keep PassByValue as the prefix for the following
reasons.
1) The invokers implement this interface only for the cases to
enforece
pass-by-value for remotable interfaces. Invocations over local
interfaces (pass-by-reference) don't even care about this flag.
2) The allowsPassByReference() method basically tells if it's safe to
pass data as-is without violating the pass-by-value semantics.
Having a SomethingPassByValue interface provide an
allowsPassByReference
method is really confusing IMHO.
I think we should use a consistent terminology with either passByValue
or passByReference but not a mix of both.
+1 just to add agreement that its quite confusing like this.
...ant
I can provide lots of suggestions about naming :-) but I'd like to
question whether we even need this new interface. Creating a new
optional SPI to set a single boolean seems quite heavyweight. There
are other examples in the SPIs of this kind of pattern and I think
there's a better approach that's lighter-weight and more flexible.
This boolean is effectively an optional property of the invoker.
As part of creating an invoker, a "property sheet" object could be
passed to the invoker's constructor for it to fill in with the
optional properties that it supports. This allows invokers to
add support for more properties in future without the need to create
a new SPI interface every time we need a new property. All that
is needed is to add new setter/getter methods to the property sheet.
The same approach could be used to add new properties for other
SPI objects such as binding providers and implementation providers.
In terms of naming (I can't resist), I think this boolean is saying
"I (the invoker) will handle PassByValue semantics". So my naming
suggestion for the method or property is "handlesPassByValue".
Simon
--
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
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 {
...
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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
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
We could simply use Object as the return value and then cast it to the type
of the property.
The caller code could perform the test as follows:
if(invoker instanceof Configurable) {
boolean allowsPBR = ((Configurable)
invoker).getProperty("AllowsPassByReference");
if(allowsPBR) {
// do something here
}
}
Thanks,
Raymond
- Original Message -
From: "Simon Nash" <[EMAIL PROTECTED]>
To:
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 {
...
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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
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
Raymond Feng wrote:
We could simply use Object as the return value and then cast it to the
type of the property.
The caller code could perform the test as follows:
if(invoker instanceof Configurable) {
boolean allowsPBR = ((Configurable)
invoker).getProperty("AllowsPassByReference");
if(allowsPBR) {
// do something here
}
}
Thanks,
Raymond
- Original Message - From: "Simon Nash" <[EMAIL PROTECTED]>
To:
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 {
...
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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
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
+1 on Option 1) which is something I'm scared to propose these days as we
want to keep the SPIs binary compatible :-). I prefer to have an explict,
clean and strongly-typed contract.
Thanks,
Raymond
- Original Message -
From: "Jean-Sebastien Delfino" <[EMAIL PROTECTED]>
To:
Sent: Monday, February 18, 2008 6:50 PM
Subject: Re: svn commit: r628163 - in /incubator/tuscany/java/sca:
itest/interfaces/src/main/java/org/apache/tuscany/sca/itest/interfaces/
itest/interfaces/src/test/java/org/apache/tuscany/sca/itest/interfaces/
modules/binding-ejb/src/main/java/org/apache/tus
Raymond Feng wrote:
We could simply use Object as the return value and then cast it to the
type of the property.
The caller code could perform the test as follows:
if(invoker instanceof Configurable) {
boolean allowsPBR = ((Configurable)
invoker).getProperty("AllowsPassByReference");
if(allowsPBR) {
// do something here
}
}
Thanks,
Raymond
- Original Message - From: "Simon Nash" <[EMAIL PROTECTED]>
To:
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 {
...
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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
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
Comments inline.
Simon
Raymond Feng wrote:
+1 on Option 1) which is something I'm scared to propose these days as
we want to keep the SPIs binary compatible :-). I prefer to have an
explict, clean and strongly-typed contract.
Thanks,
Raymond
- Original Message - From: "Jean-Sebastien Delfino"
<[EMAIL PROTECTED]>
To:
Sent: Monday, February 18, 2008 6:50 PM
Subject: Re: svn commit: r628163 - in /incubator/tuscany/java/sca:
itest/interfaces/src/main/java/org/apache/tuscany/sca/itest/interfaces/
itest/interfaces/src/test/java/org/apache/tuscany/sca/itest/interfaces/
modules/binding-ejb/src/main/java/org/apache/tus
Raymond Feng wrote:
We could simply use Object as the return value and then cast it to
the type of the property.
The caller code could perform the test as follows:
if(invoker instanceof Configurable) {
boolean allowsPBR = ((Configurable)
invoker).getProperty("AllowsPassByReference");
if(allowsPBR) {
// do something here
}
}
Thanks,
Raymond
- Original Message - From: "Simon Nash" <[EMAIL PROTECTED]>
To:
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 {
...
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
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
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 <[EMAIL PROTECTED]> 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"
> > <[EMAIL PROTECTED]>
> > To:
> > Sent: Monday, February 18, 2008 6:50 PM
> > Subject: Re: svn commit: r628163 - in /incubator/tuscany/java/sca:
> > itest/interfaces/src/main/java/org/apache/tuscany/sca/itest/interfaces/
> > itest/interfaces/src/test/java/org/apache/tuscany/sca/itest/interfaces/
> > modules/binding-ejb/src/main/java/org/apache/tus
> >
> >
> >> Raymond Feng wrote:
> >>> We could simply use Object as the return value and then cast it to
> >>> the type of the property.
> >>>
> >>> The caller code could perform the test as follows:
> >>>
> >>> if(invoker instanceof Configurable) {
> >>>boolean allowsPBR = ((Configurable)
> >>> invoker).getProperty("AllowsPassByReference");
> >>>if(allowsPBR) {
> >>> // do something here
> >>> }
> >>> }
> >>>
> >>> Thanks,
> >>> Raymond
> >>>
> >>> - Original Message - From: "Simon Nash" <[EMAIL PROTECTED]>
> >>> To:
> >>> 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 {
> >>>>>...
> >>>>> 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();
> >>
> Thi
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
-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 <[EMAIL PROTECTED]> wrote:
> +1 on Option 1) which is something I'm scared to propose these days as we
> want to keep the SPIs binary compatible :-). I prefer to have an explict,
> clean and strongly-typed contract.
>
> Thanks,
> Raymond
>
> - Original Message -
> From: "Jean-Sebastien Delfino" <[EMAIL PROTECTED]>
> To:
> Sent: Monday, February 18, 2008 6:50 PM
> Subject: Re: svn commit: r628163 - in /incubator/tuscany/java/sca:
> itest/interfaces/src/main/java/org/apache/tuscany/sca/itest/interfaces/
> itest/interfaces/src/test/java/org/apache/tuscany/sca/itest/interfaces/
> modules/binding-ejb/src/main/java/org/apache/tus
>
>
> > Raymond Feng wrote:
> >> We could simply use Object as the return value and then cast it to the
> >> type of the property.
> >>
> >> The caller code could perform the test as follows:
> >>
> >> if(invoker instanceof Configurable) {
> >>boolean allowsPBR = ((Configurable)
> >> invoker).getProperty("AllowsPassByReference");
> >>if(allowsPBR) {
> >>// do something here
> >> }
> >> }
> >>
> >> Thanks,
> >> Raymond
> >>
> >> ----- Original Message ----- From: "Simon Nash" <[EMAIL PROTECTED]>
> >> To:
> >> 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 {
> >>>>...
> >>>> 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: [EMAIL PROTECTED]
> > For additional commands, e-mail: [EMAIL PROTECTED]
> >
>
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
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
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" <[EMAIL PROTECTED]>
To:
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 <[EMAIL PROTECTED]> wrote:
+1 on Option 1) which is something I'm scared to propose these days as we
want to keep the SPIs binary compatible :-). I prefer to have an explict,
clean and strongly-typed contract.
Thanks,
Raymond
- Original Message -
From: "Jean-Sebastien Delfino" <[EMAIL PROTECTED]>
To:
Sent: Monday, February 18, 2008 6:50 PM
Subject: Re: svn commit: r628163 - in /incubator/tuscany/java/sca:
itest/interfaces/src/main/java/org/apache/tuscany/sca/itest/interfaces/
itest/interfaces/src/test/java/org/apache/tuscany/sca/itest/interfaces/
modules/binding-ejb/src/main/java/org/apache/tus
> Raymond Feng wrote:
>> We could simply use Object as the return value and then cast it to the
>> type of the property.
>>
>> The caller code could perform the test as follows:
>>
>> if(invoker instanceof Configurable) {
>>boolean allowsPBR = ((Configurable)
>> invoker).getProperty("AllowsPassByReference");
>>if(allowsPBR) {
>>// do something here
>>}
>> }
>>
>> Thanks,
>> Raymond
>>
>> ----- Original Message - From: "Simon Nash" <[EMAIL PROTECTED]>
>> To:
>> 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 {
>>>>...
>>>> 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: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
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
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/[EMAIL
PROTECTED]
Thanks,
Raymond
- Original Message - From: "ant elder" <[EMAIL PROTECTED]>
To:
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 <[EMAIL PROTECTED]>
wrote:
+1 on Option 1) which is something I'm scared to propose these days
as we
want to keep the SPIs binary compatible :-). I prefer to have an
explict,
clean and strongly-typed contract.
Thanks,
Raymond
- Original Message -
From: "Jean-Sebastien Delfino" <[EMAIL PROTECTED]>
To:
Sent: Monday, February 18, 2008 6:50 PM
Subject: Re: svn commit: r628163 - in /incubator/tuscany/java/sca:
itest/interfaces/src/main/java/org/apache/tuscany/sca/itest/interfaces/
itest/interfaces/src/test/java/org/apache/tuscany/sca/itest/interfaces/
modules/binding-ejb/src/main/java/org/apache/tus
> Raymond Feng wrote:
>> We could simply use Object as the return value and then cast it to
the
>> type of the property.
>>
>> The caller code could perform the test as follows:
>>
>> if(invoker instanceof Configurable) {
>>boolean allowsPBR = ((Configurable)
>> invoker).getProperty("AllowsPassByReference");
>>if(allowsPBR) {
>>// do something here
>>}
>> }
>>
>> Thanks,
>> Raymond
>>
>> - Original Message ----- From: "Simon Nash" <[EMAIL PROTECTED]>
>> To:
>> 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 {
>>>>...
>>>> 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 metho
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
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/[EMAIL PROTECTED]
> 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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
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
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/[EMAIL PROTECTED]
> 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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
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
Simon Nash wrote: I'm wondering whether it would be good to have a vote about this. Of the five people who have expressed a view on this so far, four of them have had a different first preference. In the interests of making progress, I think it might be good to put forward a set of options and vote to choose between them. One question of clarification inline below. ... >> Jean-Sebastien Delfino wrote: My preference: 1. (1) above add a method to Invoker, and ask people on our dev and user mailing lists if they have any issues with it. 2. (2) above and a plan to merge all these Xyz2 interfaces into the main interfaces in the next major release. > Simon Nash wrote: By the "next major release" do you mean the 1.2 release that we recently started discussing, or something else? Difficult to say until more discussion shapes 1.2 :) I mean major enough to introduce significant SPI changes. 3. Simon's proposal [1], which introduces too much complexity IMHO. A few more concerns with that proposal: - It introduces a breaking change as well. - An extension developer will have to work with two objects instead of one. The same technique applied to other extension points (provider, artifactprocessor, resolver) will double the number of interfaces. - Ownership and lifecycle of InvokerProperties are unclear. I don't see why an Invoker should return InvokerProperties if it's already passed to it. I don't understand when an Invoker should initialize that properties object. - Unless I'm missing something, it will require a breaking change to Provider.createInvoker() to pass an InvokerProperties, or a dependency on a Tuscany InvokerProperties implementation class. - If InvokerProperties is an interface then an extension developer can implement it, and will be broken again as soon as a new property is added. - The InvokerProperties pattern does not address the bigger issue of all changes to other extension methods (createInvoker, or just the invoke method itself). The fundamental question remains: Can we add methods to an interface implemented by an extension? and my opinion is: - Yes, if the change is straightforward and publicly communicated. - No, if it requires significant changes to extensions. We then need another version of the interface (like Invoker2) and support both versions until the two interfaces get merged. - It should be possible to introduce in a release SPI cleanup, merging, refactoring and evolutions, at a reasonable pace. I am not saying that we should do this in the upcoming 1.2 release, but I'd like to see some SPI cleanup happen in a reasonable timeframe. They have been close to frozen for 9 months now. I'll be happy to vote on proposals though. -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
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
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 th
