On Sep 30, 2006, at 6:10 AM, Ignacio Silva-Lepe wrote:

Ok, I took a look. Fixing CompositeReference to not be interface/ method centric is not a big deal. However CompositeReferenceTargetInvoker and CompositeReferenceCallbackTargetInvoker are defined in terms of PojoTargetInvoker which itself is interface/method centric. Given the current architecture, and the fact that CompositeReference and CompositeService are intended for local use, it seems fair to assume a dependency on PojoTargetInvoker.

If this is the case, then the fix will not work because WSDLServiceContract for instance, even though it extends ServiceContract, does not set its interfaceClass or callbackClass, hence the NPE. So, under this assumption, either WSDLServiceContract would need to set its interfaceClass and callbackClass (which seems hard to do), or CompositeReference and CompositeService, which represent bindless reference and service respectively, should not use WSDLServiceContract, i.e., bindless references and services should not use <interface.wsdl>.

If this is not the case, for which would it be interesting to see the justification, then a different way of invoking CompositeReferences and CompositeServices would need to be used, one that does not rely on java reflection.

Thoughts?

One of the fundamental concepts in SCA is the ability to specify service contracts in a variety of IDLs. It absolutely must be possible to express services and references in WSDL (or Java or CORBA IDL or ...) - basically the user should be free to use the IDL that is easiest for them and not be constrained by the infrastructure.

I can see why PojoTargetInvoker would use reflection as it is responsible for dispatching an invocation into a POJO and the only way to do that is through some form of reflective invoke.

I don't see why that would apply to a CompositeReferenceTargetInvoker - it's job AIUI is not to invoke a Java component but to flow the invocation onward to what it is wired to. That is not something that it needs an (expensive) reflective call to do - it can just forward the invocation.

--
Jeremy


---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to