You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tuscany.apache.org by Jeremy Boynes <jb...@apache.org> on 2006/11/28 23:13:31 UTC
Creating proxies (fix for TUSCANY-862)
TUSCANY-862 illustrates a problem where we try to generate the proxy
to back an interface on the target side. When the target service is
not defined using a Java interface then there is no Class for the
proxy associated with the wire and we get an NPE.
In 0.95 there was a spec change to the CompositeContext.locateService
() call that required the caller to pass in the type of interface
that they wanted to use. Although this provides the fabric with the
needed information we don't propagate that down to the target - and
nor should we as this is a source side issue i.e. different clients
(e.g. Java vs. Groovy vs. BPEL for example) may want different proxy
implementations.
We chatted about this on IRC this morning and came up with the
following plan to fix this:
1) Move the generation of the proxy to the point where it is needed
i.e in CompositeContextImpl
2) Allow the target component to return the InboundWire for a service
3) Deprecate and then clean up the internal, now obsolete
locateService methods
I'm going to start work on this in trunk to fix this issue.
--
Jeremy
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: Creating proxies (fix for TUSCANY-862)
Posted by Jim Marino <jm...@myromatours.com>.
On Nov 30, 2006, at 9:17 AM, Jim Marino wrote:
> O.K that's why I asked about what the source side looked like. A
> degenerate outbound wire seems right. One thing on this is can we
> cache the degenerate wire so the wire only need to be constructed
> once while the runtime is in operation?
>
> We have the problem I outlined, e.g. if the target is expecting to
> be in a transactional context and the source never "manually" sets
> one up...
Should have said "We /still/ have the problem"...it's still too early
in the morning.
Jim
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: Creating proxies (fix for TUSCANY-862)
Posted by Jim Marino <jm...@myromatours.com>.
O.K that's why I asked about what the source side looked like. A
degenerate outbound wire seems right. One thing on this is can we
cache the degenerate wire so the wire only need to be constructed
once while the runtime is in operation?
We have the problem I outlined, e.g. if the target is expecting to be
in a transactional context and the source never "manually" sets one
up...
Jim
On Nov 30, 2006, at 9:10 AM, Jeremy Boynes wrote:
> On 11/30/06, Jim Marino <jm...@myromatours.com> 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?
>>
>
> That shouldn't matter should it? I think Greg's problem is that there
> is a data incompatibility between the source side (the supplied Java
> interface) and the target side (the WS reference). Normally the
> connector fixes this by adding a transform interceptor to convert from
> the Object on the source side to the OMElement on the target
> side.However, locateService bypasses the connector so this does not
> get done.
>
> I think Greg's proposal is right - create a degenerate outbound wire
> and then connect it to the target's inbound one. We know we needed to
> do that for policy at some point but it looks like we'll have to do it
> sooner due to this transform issue.
>
> --
> Jeremy
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: Creating proxies (fix for TUSCANY-862)
Posted by Raymond Feng <en...@gmail.com>.
----- Original Message -----
From: "Jeremy Boynes" <jb...@apache.org>
To: <tu...@ws.apache.org>
Sent: Thursday, November 30, 2006 9:10 AM
Subject: Re: Creating proxies (fix for TUSCANY-862)
> On 11/30/06, Jim Marino <jm...@myromatours.com> 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?
>>
>
> That shouldn't matter should it? I think Greg's problem is that there
> is a data incompatibility between the source side (the supplied Java
> interface) and the target side (the WS reference). Normally the
> connector fixes this by adding a transform interceptor to convert from
> the Object on the source side to the OMElement on the target
> side.However, locateService bypasses the connector so this does not
> get done.
>
> I think Greg's proposal is right - create a degenerate outbound wire
> and then connect it to the target's inbound one. We know we needed to
> do that for policy at some point but it looks like we'll have to do it
> sooner due to this transform issue.
>
So when the degenerate outbound wire is created and connected, we need to
trigger PostWireProcessor to deal with this newly-created dynamic wire.
Right? The databinding framework needs to be notified so that it can add the
corresponding interceptor to deal with the transformation.
> --
> Jeremy
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: Creating proxies (fix for TUSCANY-862)
Posted by Jeremy Boynes <jb...@apache.org>.
On 11/30/06, Jim Marino <jm...@myromatours.com> 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?
>
That shouldn't matter should it? I think Greg's problem is that there
is a data incompatibility between the source side (the supplied Java
interface) and the target side (the WS reference). Normally the
connector fixes this by adding a transform interceptor to convert from
the Object on the source side to the OMElement on the target
side.However, locateService bypasses the connector so this does not
get done.
I think Greg's proposal is right - create a degenerate outbound wire
and then connect it to the target's inbound one. We know we needed to
do that for policy at some point but it looks like we'll have to do it
sooner due to this transform issue.
--
Jeremy
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: Creating proxies (fix for TUSCANY-862)
Posted by Jim Marino <jm...@myromatours.com>.
On Nov 30, 2006, at 1:06 PM, scabooz wrote:
> Jim,
>
> See below please.
>
> -Dave
>
> ----- Original Message ----- From: "Jim Marino"
> <jm...@myromatours.com>
> To: <tu...@ws.apache.org>
> 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 <jm...@myromatours.com> 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: tuscany-dev-unsubscribe@ws.apache.org
>>>> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>>>>
>>>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
>> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: Creating proxies (fix for TUSCANY-862)
Posted by scabooz <sc...@gmail.com>.
Jim,
See below please.
-Dave
----- Original Message -----
From: "Jim Marino" <jm...@myromatours.com>
To: <tu...@ws.apache.org>
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 <jm...@myromatours.com> 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: tuscany-dev-unsubscribe@ws.apache.org
>>> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>>>
>>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: Creating proxies (fix for TUSCANY-862)
Posted by Jim Marino <jm...@myromatours.com>.
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();
}
}
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?
Jim
> On 11/30/06, Jim Marino <jm...@myromatours.com> 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: tuscany-dev-unsubscribe@ws.apache.org
>> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>>
>>
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: Creating proxies (fix for TUSCANY-862)
Posted by Greg Dritschler <gr...@gmail.com>.
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.
On 11/30/06, Jim Marino <jm...@myromatours.com> 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.createOperationCli
> > 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: tuscany-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>
>
Re: Creating proxies (fix for TUSCANY-862)
Posted by Jim Marino <jm...@myromatours.com>.
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.createOperationCli
> 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: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: Creating proxies (fix for TUSCANY-862)
Posted by Greg Dritschler <gr...@gmail.com>.
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.createOperationClient
(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?
Re: Creating proxies (fix for TUSCANY-862)
Posted by Jim Marino <jm...@myromatours.com>.
On Nov 29, 2006, at 1:20 PM, Jeremy Boynes wrote:
> This became a little bigger than a breadbox :(
I think we're looking at a bread freighter ;-)
Ignacio, you may want to sync with Jeremy if you haven't as this may
impact you as well. I would like JDKInboundInvocationHandler to go
away, and possibly JDKCallbackInvocationHandler as well. One way to
potentially do this is to move some of the code related to callbacks
or attributes of a wire (e.g. message id creation) to be placed in
interceptors attached to the wire. This will keep the handler code
simple and may make deserialization of passivated conversational
instances much easier to deal with as wires (and hence interceptors)
never need to be serialized.
Jim
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: Creating proxies (fix for TUSCANY-862)
Posted by Jeremy Boynes <jb...@apache.org>.
This became a little bigger than a breadbox :( There are still many
places where we did not complete the transition from Java class-based
IDL to using the abstract ServiceContract so some things will not
work without a Java representation (e.g. the
JDKOutboundInvocationHandler). I'll extend this work to finishing
that up as well.
--
Jeremy
On Nov 28, 2006, at 2:13 PM, Jeremy Boynes wrote:
> TUSCANY-862 illustrates a problem where we try to generate the
> proxy to back an interface on the target side. When the target
> service is not defined using a Java interface then there is no
> Class for the proxy associated with the wire and we get an NPE.
>
> In 0.95 there was a spec change to the
> CompositeContext.locateService() call that required the caller to
> pass in the type of interface that they wanted to use. Although
> this provides the fabric with the needed information we don't
> propagate that down to the target - and nor should we as this is a
> source side issue i.e. different clients (e.g. Java vs. Groovy vs.
> BPEL for example) may want different proxy implementations.
>
> We chatted about this on IRC this morning and came up with the
> following plan to fix this:
>
> 1) Move the generation of the proxy to the point where it is needed
> i.e in CompositeContextImpl
> 2) Allow the target component to return the InboundWire for a service
> 3) Deprecate and then clean up the internal, now obsolete
> locateService methods
>
> I'm going to start work on this in trunk to fix this issue.
> --
> Jeremy
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org