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: <tuscany-dev@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" <[EMAIL PROTECTED]>
> >>> To: <tuscany-dev@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: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
