Jim,
See below please.
-Dave
----- Original Message -----
From: "Jim Marino" <[EMAIL PROTECTED]>
To: <[email protected]>
Sent: Thursday, November 30, 2006 12:44 PM
Subject: Re: Creating proxies (fix for TUSCANY-862)
On Nov 30, 2006, at 9:21 AM, Greg Dritschler wrote:
I've been using a JSP to test this. At this point I'm not sure how much
restricting the client to an SCA component helps because the
locateService
is still dynamic. Anyway the spec says locateService is available to
non-SCA clients.
Yes but the semantics are different and that's one of the reasons I don't
like it much (it is going to confuse end-users). A locateService from
non-mamanged code will not return a chain with source-side policy (which
would be expected, since it is not a component). The problem really shows
up in the following situation:
1. A client component has a transactional policy associated with it that
propagates
2. The target requires a client call it with the transactional policy
3. The client does this:
public class Foo {
@Context CurrentCompositeContext context;
public void operation() {
context.locateService(Foo.class, "Foo").doSomething();
}
}
It works.
4. The client instead does this and they get some kind of trx context
error because now it is behaving as unmanaged code:
public class Foo {
public void operation() {
CurrentCompositeContext.getContext().locateService(Foo.class,
"Foo").doSomething();
}
}
WRT transactions, the specs will never support a case where a service
provider requires that a client propogate a transaction. Perhaps it's just
that your example is bad.
The spec doesn't talk about source side chains, so this is clearly an
implementation issue. If a composite reference contains decorations for
policy (intents or policySets), then it is the reference binding's
responsibility to act on those policy decorations. If it cannot do so, it
must throw an error. Managed vs. un-managed environments can certainly
create differences in policy behavior. I still don't see what that has to
do with the ability of the locateService API to provide a proxy for a
configured composite reference. Having source side policy configured on a
composite reference is related to the presence of source side policy on the
reference, and has nothing to do with an particular component.
In the spec group, we played around with the notion of a "default"
context which would get around this problem. A better solution may be to
eliminate locate service for components (e.g. @Context) altogether and
only relying on dependency injection (this would involve making a war or
jsp a component impl type). The only case where I see a problem with this
is in a completely dynamic situation where the component name is passed
in (in which case only the interface is known). This may be something we
can do through autowire or through multiplicity references. Can you
describe the use-case a little more?
The use case is very simple. A composite level reference with a WSDL
interface type. The locateService() API should be able to return a proxy to
that reference. The locateService API might be invoked from with an SCA
component implementation, or not. As I recall, this is a use case that you
pushed into the spec.
Jim
On 11/30/06, Jim Marino <[EMAIL PROTECTED]> wrote:
This I think highlights a problem with the spec around using
CurrentCompositeContext from unmamanged code in general...a locate
service only returns "half" of an invocation chain since the source
is not a component and is "unmamanged" code". Can you describe you
client code, is it a JSP or is it from a component?
Jim
On Nov 30, 2006, at 6:51 AM, Greg Dritschler wrote:
> I've tried out the suggested fixes and I have run into a big
problem.
> By proxying the inbound wire of the composite reference, there
is no
> databinding interceptor in the invocation chain. This causes
> Axis2TargetInvoker to choke.
>
> Exception "java.lang.IllegalArgumentException" Exception
> message: "Can't
> handle mixed payloads betweem OMElements and other types."
>
> java.lang.IllegalArgumentException: Can't handle mixed payloads
> betweem
> OMElements and other types.
> at
>
org.apache.tuscany.binding.axis2.Axis2TargetInvoker.createOperationCl i
> ent
> (Axis2TargetInvoker.java)
> at
org.apache.tuscany.binding.axis2.Axis2TargetInvoker.invokeTarget(
> Axis2TargetInvoker.java:70)
> at org.apache.tuscany.binding.axis2.Axis2TargetInvoker.invoke(
> Axis2TargetInvoker.java:107)
> at org.apache.tuscany.core.wire.InvokerInterceptor.invoke(
> InvokerInterceptor.java:44)
> at
org.apache.tuscany.core.wire.SynchronousBridgingInterceptor.invoke(
> SynchronousBridgingInterceptor.java:41)
> at
>
org.apache.tuscany.spi.wire.AbstractInboundInvocationHandler.invoke(
> AbstractInboundInvocationHandler.java:60)
> at
>
org.apache.tuscany.core.wire.jdk.JDKInboundInvocationHandler.invoke(
> JDKInboundInvocationHandler.java:108)
>
> How do we get the databinding transformation into this flow? The
> DatabindingInterceptor currently requires an outbound wire from the
> client.
> Dynamically creating an outbound wire for a non-SCA client and
> connecting it
> to the composite reference sounds like a major piece of work. Is
> there a
> simpler solution?
---------------------------------------------------------------------
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]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
