NoRegisteredCallbackException check

[Simon Nash <na...@hursley.ibm.com>]

I am working on adding the check required by the second paragraph of
section 1.6.7.5 in the Java Common Annotations and APIs spec (to
throw NoRegisteredCallbackException on a client outbound call if a
callback is possible, the client service does not implement the
callback interface, and there is no registered callback object).

I see two possible approaches for doing this:

1. Put this check in the core invocation logic.  The code needed to
    perform the check is specific to the Java component implementation,
    so putting this checking code in the core would require the core to
    have a dependency on the implementation-java module, which is not
    desirable.  To avoid this we would add need a new SPI to perform
    the check.  This SPI can optionally be implemented by any component
    implementation type that wants to support callbacks and enforce
    this check.

2. Put this check in an outbound interceptor.  The is currently an
    interceptor in the trunk for doing this (CallbackInterfaceInterceptor),
    but it is not used anywhere and it doesn't currently contain the
    checking code.  This interceptor would need to have checking code
    specific to the component implementation type that is making the
    outbound implementation.  This means we would need a new SPI to give
    implementation providers the opportunity to add an interceptor to the
    invocation chain for their outbound calls.  (They can currently only
    do this for their inbound calls.)

So both approaches require a new SPI.  I have currently implemented and
tested approach 1, using a new assembly SPI interface CallbackImplementation
for component implementations to optionally implement, containing a single
method
   boolean supportsCallbackInterface(Interface callbackInterface);
which is invoked by the core to perform the implementation-specific test
whether or not this componext implementation type implements the passed
callback interface.  I have added an implementation of this method
to JavaImplementationImpl.

I could submit this as a patch, but I'm beginning to lean more towards
approach 2, mostly because I don't feel very comfortable adding this test
to an assembly SPI when its purpose is to perform a runtime check.  Also,
the existence of CallbackInterfaceInterceptor in the trunk seems to be
an indication that someone has thought about this previously and decided
on the interceptor approach.  So I have been thinking about how to do this
using approach 2.

My thoughts on approach 2 are a bit more sketchy because I haven't
implemented it yet.  It would need a new core SPI interface, perhaps
ImplementationProvider2 extending ImplementationProvider, which could
be optionally implemented by implementation providers.  This interface
would contain a single method, perhaps
   void interceptOutboundCall(InvocationChain chain);
An implementation provider that wanted to perform this callback check
would implement this method and create an implementation-specific
subclass of CallbackInterfaceInterceptor that performs the check for
its component implementation type, and add this interceptor to the
invocation chain.

This has the following advantages over approach 1:
  1. The new SPI is part of the runtime SPI rather than the assembly SPI.
  2. The new SPI could be used for other purposes, not just for this
     callback check.
  3. It seems more in line with with the original design intention
     that led to the creation of CallbackInterfaceInterceptor.

I'll try prototyping this to see how I get on with it.  Any opinions
on the merits of these approaches (or other suggestions) would be
much appreciated.

   Simon



---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org

Re: NoRegisteredCallbackException check

[Simon Nash <na...@hursley.ibm.com>]

I have now completed the implementation of approach 2.  Another major
advantage of approach 2 over approach 1 that I did not include in my
previous list is that it is far more efficient.  The interceptor only
needs to be added to the chains if the client service does not implement
the callback interface.  This test could be quite expensive in some
cases and it is much better to keep it off the runtime invocation path.
If the interceptor is present, then it just needs to check that there
is a callback object and throw NoRegisteredCallbackException if not.
This is a very cheap operation.

The new SPI method added for this change is in a new interface
ImplementationProvider2 that does not extend ImplementationProvider.
This is because JavaImplementationProvider extends
ScopedImplementationProvider, which extends ImplementationProvider.
I didn't think it was appropriate to change the inheritance of
ScopedImplementationProvider as this would have affected any other
subclasses of ScopedImplementationProvider in addition to
JavaImplementationProvider.  ImplementationProvider2 contains a
single method
   void processReferenceWire(RuntimeWire wire);
which allows for any kind of postprocessing of the reference wire by
the implementation provider.

I'm now creating a patch for this implementation that I will attach
to TUSCANY-1500.

   Simon

Simon Nash wrote:

> I am working on adding the check required by the second paragraph of
> section 1.6.7.5 in the Java Common Annotations and APIs spec (to
> throw NoRegisteredCallbackException on a client outbound call if a
> callback is possible, the client service does not implement the
> callback interface, and there is no registered callback object).
> 
> I see two possible approaches for doing this:
> 
> 1. Put this check in the core invocation logic.  The code needed to
>    perform the check is specific to the Java component implementation,
>    so putting this checking code in the core would require the core to
>    have a dependency on the implementation-java module, which is not
>    desirable.  To avoid this we would add need a new SPI to perform
>    the check.  This SPI can optionally be implemented by any component
>    implementation type that wants to support callbacks and enforce
>    this check.
> 
> 2. Put this check in an outbound interceptor.  The is currently an
>    interceptor in the trunk for doing this (CallbackInterfaceInterceptor),
>    but it is not used anywhere and it doesn't currently contain the
>    checking code.  This interceptor would need to have checking code
>    specific to the component implementation type that is making the
>    outbound implementation.  This means we would need a new SPI to give
>    implementation providers the opportunity to add an interceptor to the
>    invocation chain for their outbound calls.  (They can currently only
>    do this for their inbound calls.)
> 
> So both approaches require a new SPI.  I have currently implemented and
> tested approach 1, using a new assembly SPI interface 
> CallbackImplementation
> for component implementations to optionally implement, containing a single
> method
>   boolean supportsCallbackInterface(Interface callbackInterface);
> which is invoked by the core to perform the implementation-specific test
> whether or not this componext implementation type implements the passed
> callback interface.  I have added an implementation of this method
> to JavaImplementationImpl.
> 
> I could submit this as a patch, but I'm beginning to lean more towards
> approach 2, mostly because I don't feel very comfortable adding this test
> to an assembly SPI when its purpose is to perform a runtime check.  Also,
> the existence of CallbackInterfaceInterceptor in the trunk seems to be
> an indication that someone has thought about this previously and decided
> on the interceptor approach.  So I have been thinking about how to do this
> using approach 2.
> 
> My thoughts on approach 2 are a bit more sketchy because I haven't
> implemented it yet.  It would need a new core SPI interface, perhaps
> ImplementationProvider2 extending ImplementationProvider, which could
> be optionally implemented by implementation providers.  This interface
> would contain a single method, perhaps
>   void interceptOutboundCall(InvocationChain chain);
> An implementation provider that wanted to perform this callback check
> would implement this method and create an implementation-specific
> subclass of CallbackInterfaceInterceptor that performs the check for
> its component implementation type, and add this interceptor to the
> invocation chain.
> 
> This has the following advantages over approach 1:
>  1. The new SPI is part of the runtime SPI rather than the assembly SPI.
>  2. The new SPI could be used for other purposes, not just for this
>     callback check.
>  3. It seems more in line with with the original design intention
>     that led to the creation of CallbackInterfaceInterceptor.
> 
> I'll try prototyping this to see how I get on with it.  Any opinions
> on the merits of these approaches (or other suggestions) would be
> much appreciated.
> 
>   Simon
> 
> 
> 



---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org