On Nov 30, 2006, at 1:06 PM, scabooz wrote:
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.
How about between two local services where the target requires a
transaction to be active? By "propagation" I don't mean remote
boundaries.
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.
Yes that is correct.
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.
That was what I was getting at and I think overloading locateService
(it behaves differently if it is done from a ComponentContext that is
obtained through injection with @Context or getCurrentContext()) is
going to be confusing.
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.
It doesn't. It has more to do with the overloading issue above.
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.
If this is the case, then we have different behavior in the following
case, which is equally confusing:
public class ComponentImpl {
@Context
protected CurrentCompositeContext context;
@Reference // wired to "FooService" in the scdl
protected Foo foo;
public someOperation() {
context.locateService(Foo.class "FooService").invoke();
CurrentCompositeContext.getContext().locateService(Foo.class
"FooService").invoke(); // is different from above
}
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.
Whether locateService() should return a proxy or not is a separate
issue (it really has to). I was questioning:
1. The utility of even having the option of locateService from within
a component. I don't think it is needed. The only case I can see for
this is dynamic service lookups but I believe that can be solved by
multiplicity as the service contract is known upfront by the client
(just wire a multiplicity at assembly/deployment).
2. Whether it is possible to eliminate the concept of unmanaged code
altogether. I think we could do this from JSPs by modeling a war file
as a composite type (use bean tags could create the component type),
and having references injected into servlets and jsps. I believe the
Servlet spec group has at some point considered using commons
annotations to allow injection and I think that may be a thing we
could leverage. The one case I think we may not be able to eliminate
the concept of unmanaged code is a J2SE client that cannot be a "mini-
SCA container". In this case, say a desktop application, it wants to
invoke a service. One way around this would be to say that it may be
better to just use a lower-level API like JAX-WS or JMS for that.
Jim
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.createOperation
Cl 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]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
