ant elder wrote:
Looking at the binding and implementation extensions we have now there's
still a bit of messy code in the way proxys and invokers for
RuntimeComponentServices and RuntimeComponentReferences are done. Eg,
RMIBindingProvider.invokeTarget,
Axis2ServiceBindingProvider.invokeTarget or
ScriptImplementationProvider.createReferenceProxy. There's a lot of
boilerplate code in those methods and also a lot of opportunity to do it
wrong, eg wireList.get(0). Venkat and I were wondering if there's
anything
we could do to make this easier for extension writers?
How about adding something like createProxy(Binding) and
createInvoker(Binding) methods to RuntimeComponentService and
RuntimeComponentReference?
...ant
+1 for createInvoker() on RuntimeComponentReference. Or should it be a
getInvoker() as I don't think we'll create a new one, right?
I'm not sure about the createProxy()... a proxy seems interesting to me
in a Java component, where the business logic expects a (proxy) object
presenting the business interface. In a binding, I don't really
understand why we would use a Java proxy (which requires a Java business
interface, expects individual arguments, and comes with some overhead),
instead of just using Invoker.invoke(Message message).
I'd suggest to leave Java Proxies to the Java component (or other
component implementation types where a Java proxy would really really
help). But in general, our invocation mechanism is
Invoker.invoke(Message message). If people think that invoke(Message
message) is not good, then let's switch everything to an
invoke(Object[]) :) but I'd like to avoid having 2 different invocation
mechanisms all over the place, one is probably enough :)
How about RuntimeComponentService.getInvoker()?
--
Jean-Sebastien
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
