-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: <[email protected]> > 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: <[email protected]> > >> 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: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > >
