You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tuscany.apache.org by Jean-Sebastien Delfino <js...@apache.org> on 2008/01/08 19:58:11 UTC
Incorrect JAXB2Node transformer usage
While debugging the store tutorial I'm seeing many calls to the
JAXB2Node transformer unnecessarily creating DOM nodes where I was
expecting to see the JAXB2Reader or JAXB2String transformers instead.
Could somebody please help me fix this? Thanks
P.S. I'm not sure if we want the fix for 1.1, it might bring a
significant performance improvement.
--
Jean-Sebastien
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: Incorrect JAXB2Node transformer usage
Posted by Jean-Sebastien Delfino <js...@apache.org>.
Raymond Feng wrote:
[snip]
> It's a bit tricky here. What the path does is to convert a simple-type
> java parameter to an AXIOM element to be consumed by the WS stack. The
> simple java types are now treated as JAXB objects.
I thought we were only using JAXB for complex java types / java beans :)
I'm trying to understand, can you point me to the code that:
- selects the databinding
- transforms the simple type to a node?
Thanks.
> So the path would be
> JAXB-->AXIOM. At this moment, we don't have JAXB to XMLStreamer
> transformer, so it goes through JAXB --> DOM --> XMLStreamReader -->
> AXIOM. Sure, the path might be optimzed. With the current capability, we
> could try other alternatives such as JAXB --> XMLString -->
> XMLStreamReader --> AXIOM, but I'm not sure if it helps.
[snip]
--
Jean-Sebastien
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: Incorrect JAXB2Node transformer usage
Posted by Raymond Feng <en...@gmail.com>.
Hi,
It's a bit tricky here. What the path does is to convert a simple-type java
parameter to an AXIOM element to be consumed by the WS stack. The simple
java types are now treated as JAXB objects. So the path would be
JAXB-->AXIOM. At this moment, we don't have JAXB to XMLStreamer transformer,
so it goes through JAXB --> DOM --> XMLStreamReader --> AXIOM. Sure, the
path might be optimzed. With the current capability, we could try other
alternatives such as JAXB --> XMLString --> XMLStreamReader --> AXIOM, but
I'm not sure if it helps.
Thanks,
Raymond
----- Original Message -----
From: "Jean-Sebastien Delfino" <js...@apache.org>
To: <tu...@ws.apache.org>
Sent: Tuesday, January 08, 2008 11:16 AM
Subject: Re: Incorrect JAXB2Node transformer usage
> Raymond Feng wrote:
>> What path did you see (source, target)? Do you expect String as
>> intermediate formats instead of Node? You can adjust the weighta of
>> transformers to make them more favorable.
>>
> [snip]
>
> This happens as part of the domain/node exchanges when I start a node the
> tutorial's LaunchClound program.
>
> Here's the stack:
> Thread [main] (Suspended (breakpoint at line 40 in JAXB2Node))
> JAXB2Node.transform(Object, TransformationContext) line: 40
> JAXB2Node.transform(Object, TransformationContext) line: 33
> DefaultTransformerExtensionPoint$LazyPullTransformer.transform(Object,
> TransformationContext) line: 199 MediatorImpl.mediate(Object, DataType,
> DataType, Map<String,Object>) line: 73
> Input2InputTransformer.transform(Object[], TransformationContext) line:
> 148 Input2InputTransformer.transform(Object, TransformationContext) line:
> 43 MediatorImpl.mediate(Object, DataType, DataType, Map<String,Object>)
> line: 73 DataTransformationInterceptor.transform(Object, DataType,
> DataType, boolean) line: 175 DataTransformationInterceptor.invoke(Message)
> line: 72 JDKInvocationHandler.invoke(InvocationChain, Object[],
> RuntimeWire) line: 249 JDKInvocationHandler.invoke(Object, Method,
> Object[]) line: 146 $Proxy11.registerNode(String, String, Externalizable)
> line: not available SCADomainEventServiceProxyImpl.registerNode(String,
> String, Externalizable) line: 59 NativeMethodAccessorImpl.invoke0(Method,
> Object, Object[]) line: not available [native method]
> NativeMethodAccessorImpl.invoke(Object, Object[]) line: 64
> DelegatingMethodAccessorImpl.invoke(Object, Object[]) line: 43
> Method.invoke(Object, Object...) line: 615
> JavaImplementationInvoker.invoke(Message) line: 105
> PassByValueInterceptor.invoke(Message) line: 88
> JDKInvocationHandler.invoke(InvocationChain, Object[], RuntimeWire) line:
> 249 JDKInvocationHandler.invoke(Object, Method, Object[]) line: 146
> $Proxy11.registerNode(String, String, Externalizable) line: not available
> SCADomainProxyImpl.addNode() line: 376 SCADomainProxyImpl.createRuntime()
> line: 283 SCADomainProxyImpl.addNode(SCANode) line: 350 SCANodeImpl.init()
> line: 225 SCANodeImpl.<init>(String, String, String) line: 136
> SCANodeFactoryImpl.createSCANode(String, String) line: 54
> LaunchCloud.main(String[]) line: 48
> The source and target data types are:
> class java.lang.String java:simpleType Element:
> {http://domain.sca.tuscany.apache.org/}arg0 Type:
> {http://www.w3.org/2001/XMLSchema}string
> class java.lang.Object org.w3c.dom.Node Element:
> {http://domain.sca.tuscany.apache.org}param0 Type:
> {http://www.w3.org/2001/XMLSchema}string
>
> It's surprising is to see dom.Node here as there is no reason to go
> through a Node at all as the invocation is a Web Service call to the
> DomainEventService... We are still using Axiom, right? :)
>
> Thanks.
> --
> Jean-Sebastien
>
> ---------------------------------------------------------------------
> 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: Incorrect JAXB2Node transformer usage
Posted by Jean-Sebastien Delfino <js...@apache.org>.
Raymond Feng wrote:
> What path did you see (source, target)? Do you expect String as
> intermediate formats instead of Node? You can adjust the weighta of
> transformers to make them more favorable.
>
[snip]
This happens as part of the domain/node exchanges when I start a node
the tutorial's LaunchClound program.
Here's the stack:
Thread [main] (Suspended (breakpoint at line 40 in JAXB2Node))
JAXB2Node.transform(Object, TransformationContext) line: 40
JAXB2Node.transform(Object, TransformationContext) line: 33
DefaultTransformerExtensionPoint$LazyPullTransformer.transform(Object,
TransformationContext) line: 199
MediatorImpl.mediate(Object, DataType, DataType, Map<String,Object>)
line: 73
Input2InputTransformer.transform(Object[], TransformationContext)
line: 148
Input2InputTransformer.transform(Object, TransformationContext) line: 43
MediatorImpl.mediate(Object, DataType, DataType, Map<String,Object>)
line: 73
DataTransformationInterceptor.transform(Object, DataType, DataType,
boolean) line: 175
DataTransformationInterceptor.invoke(Message) line: 72
JDKInvocationHandler.invoke(InvocationChain, Object[], RuntimeWire)
line: 249
JDKInvocationHandler.invoke(Object, Method, Object[]) line: 146
$Proxy11.registerNode(String, String, Externalizable) line: not available
SCADomainEventServiceProxyImpl.registerNode(String, String,
Externalizable) line: 59
NativeMethodAccessorImpl.invoke0(Method, Object, Object[]) line: not
available [native method]
NativeMethodAccessorImpl.invoke(Object, Object[]) line: 64
DelegatingMethodAccessorImpl.invoke(Object, Object[]) line: 43
Method.invoke(Object, Object...) line: 615
JavaImplementationInvoker.invoke(Message) line: 105
PassByValueInterceptor.invoke(Message) line: 88
JDKInvocationHandler.invoke(InvocationChain, Object[], RuntimeWire)
line: 249
JDKInvocationHandler.invoke(Object, Method, Object[]) line: 146
$Proxy11.registerNode(String, String, Externalizable) line: not available
SCADomainProxyImpl.addNode() line: 376
SCADomainProxyImpl.createRuntime() line: 283
SCADomainProxyImpl.addNode(SCANode) line: 350
SCANodeImpl.init() line: 225
SCANodeImpl.<init>(String, String, String) line: 136
SCANodeFactoryImpl.createSCANode(String, String) line: 54
LaunchCloud.main(String[]) line: 48
The source and target data types are:
class java.lang.String java:simpleType Element:
{http://domain.sca.tuscany.apache.org/}arg0 Type:
{http://www.w3.org/2001/XMLSchema}string
class java.lang.Object org.w3c.dom.Node Element:
{http://domain.sca.tuscany.apache.org}param0 Type:
{http://www.w3.org/2001/XMLSchema}string
It's surprising is to see dom.Node here as there is no reason to go
through a Node at all as the invocation is a Web Service call to the
DomainEventService... We are still using Axiom, right? :)
Thanks.
--
Jean-Sebastien
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: Incorrect JAXB2Node transformer usage
Posted by Raymond Feng <en...@gmail.com>.
What path did you see (source, target)? Do you expect String as intermediate
formats instead of Node? You can adjust the weighta of transformers to make
them more favorable.
Thanks,
Raymond
----- Original Message -----
From: "Jean-Sebastien Delfino" <js...@apache.org>
To: <tu...@ws.apache.org>
Sent: Tuesday, January 08, 2008 10:58 AM
Subject: Incorrect JAXB2Node transformer usage
> While debugging the store tutorial I'm seeing many calls to the JAXB2Node
> transformer unnecessarily creating DOM nodes where I was expecting to see
> the JAXB2Reader or JAXB2String transformers instead.
>
> Could somebody please help me fix this? Thanks
>
> P.S. I'm not sure if we want the fix for 1.1, it might bring a significant
> performance improvement.
> --
> Jean-Sebastien
>
> ---------------------------------------------------------------------
> 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