You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@cxf.apache.org by akuhtz <an...@siemens.com> on 2011/07/18 14:03:38 UTC
Problem with new transform feature
Hi,
I was trying to use the new transform feature for CXF
(http://cxf.apache.org/docs/transformationfeature.html) but limited luck
until now.
It works fine if you try to replace a namespace for a soap body element,
that's the good news. But if a namespace is replaced in a soap header
element the processing of an incoming requests loops somewhere but I cannot
find where exactly this happens (might be somewhere in StaxUtils ... but not
sure).
I tried to replace a namespace in the soap header element but even if I use
the same value as replacement it hangs ...
I've created a small sample project that can be used to reproduce the
problem.
Regards,
Andi http://cxf.547215.n5.nabble.com/file/n4599185/cxf-sample.zip
cxf-sample.zip
--
View this message in context: http://cxf.547215.n5.nabble.com/Problem-with-new-transform-feature-tp4599185p4599185.html
Sent from the cxf-user mailing list archive at Nabble.com.
Re: Problem with new transform feature
Posted by Aki Yoshida <el...@googlemail.com>.
Hi Andi,
good to hear that it worked.
Sergey and I are planning to add a few more features so that some
common simple transformation can be performed in this way. If you have
some features in your mind that you would like to have, let us know.
Thanks.
regards, aki
2011/8/7 Kuhtz, Andreas <an...@atos.net>:
> Hi Aki,
>
> I was off for some days. I tested with the current 2.4.2-SNAPSHOT and my
> tests passed. So I'm happy with 2.4.2 ;-)
> Thanks for your help!
>
> Regards,
> Andi
>
> -----Original Message-----
> From: Aki Yoshida [mailto:elakito@googlemail.com]
> Sent: Samstag, 30. Juli 2011 00:10
> To: Kuhtz, Andreas
> Cc: users@cxf.apache.org
> Subject: Re: Problem with new transform feature
>
> Hi Andi,
> Dan already merged the patch into 2.4.x.
> Let me know if everything works for you this time.
> Thanks.
> regards, aki
>
> 2011/7/29 Aki Yoshida <el...@googlemail.com>:
>> Hi Andi,
>> yes. Sorry for my delay. I will be merging it into 2.4.x today.
>>
>> Yesterday, I was doing a few things in between and got mixed up with a
>> few things.
>> So, I wanted to be more careful this time.
>>
>> regards, aki
>>
>> 2011/7/29 akuhtz <an...@siemens.com>:
>>> Hi Aki,
>>>
>>> Thanks for the fixes. Is it possible to merge the fix back into the
>>> 2.4-fixes branch?
>>>
>>> Regards
>>> Andi
>>>
>>> --
>>> View this message in context:
> http://cxf.547215.n5.nabble.com/Problem-with-new-transform-feature-tp459
> 9185p4646441.html
>>> Sent from the cxf-user mailing list archive at Nabble.com.
>>>
>>
>
RE: Problem with new transform feature
Posted by "Kuhtz, Andreas" <an...@atos.net>.
Hi Aki,
I was off for some days. I tested with the current 2.4.2-SNAPSHOT and my
tests passed. So I'm happy with 2.4.2 ;-)
Thanks for your help!
Regards,
Andi
-----Original Message-----
From: Aki Yoshida [mailto:elakito@googlemail.com]
Sent: Samstag, 30. Juli 2011 00:10
To: Kuhtz, Andreas
Cc: users@cxf.apache.org
Subject: Re: Problem with new transform feature
Hi Andi,
Dan already merged the patch into 2.4.x.
Let me know if everything works for you this time.
Thanks.
regards, aki
2011/7/29 Aki Yoshida <el...@googlemail.com>:
> Hi Andi,
> yes. Sorry for my delay. I will be merging it into 2.4.x today.
>
> Yesterday, I was doing a few things in between and got mixed up with a
> few things.
> So, I wanted to be more careful this time.
>
> regards, aki
>
> 2011/7/29 akuhtz <an...@siemens.com>:
>> Hi Aki,
>>
>> Thanks for the fixes. Is it possible to merge the fix back into the
>> 2.4-fixes branch?
>>
>> Regards
>> Andi
>>
>> --
>> View this message in context:
http://cxf.547215.n5.nabble.com/Problem-with-new-transform-feature-tp459
9185p4646441.html
>> Sent from the cxf-user mailing list archive at Nabble.com.
>>
>
Re: Problem with new transform feature
Posted by Sergey Beryozkin <sb...@gmail.com>.
Hi Aki
Many thanks for enhancing InStreamReader. TransformFeature is getting
close to becoming a light-weight analog of XSLT processor :-).
Cheers, Sergey
On 29/07/11 23:09, Aki Yoshida wrote:
> Hi Andi,
> Dan already merged the patch into 2.4.x.
> Let me know if everything works for you this time.
> Thanks.
> regards, aki
>
> 2011/7/29 Aki Yoshida<el...@googlemail.com>:
>> Hi Andi,
>> yes. Sorry for my delay. I will be merging it into 2.4.x today.
>>
>> Yesterday, I was doing a few things in between and got mixed up with a
>> few things.
>> So, I wanted to be more careful this time.
>>
>> regards, aki
>>
>> 2011/7/29 akuhtz<an...@siemens.com>:
>>> Hi Aki,
>>>
>>> Thanks for the fixes. Is it possible to merge the fix back into the
>>> 2.4-fixes branch?
>>>
>>> Regards
>>> Andi
>>>
>>> --
>>> View this message in context: http://cxf.547215.n5.nabble.com/Problem-with-new-transform-feature-tp4599185p4646441.html
>>> Sent from the cxf-user mailing list archive at Nabble.com.
>>>
>>
Re: Problem with new transform feature
Posted by Aki Yoshida <el...@googlemail.com>.
Hi Andi,
Dan already merged the patch into 2.4.x.
Let me know if everything works for you this time.
Thanks.
regards, aki
2011/7/29 Aki Yoshida <el...@googlemail.com>:
> Hi Andi,
> yes. Sorry for my delay. I will be merging it into 2.4.x today.
>
> Yesterday, I was doing a few things in between and got mixed up with a
> few things.
> So, I wanted to be more careful this time.
>
> regards, aki
>
> 2011/7/29 akuhtz <an...@siemens.com>:
>> Hi Aki,
>>
>> Thanks for the fixes. Is it possible to merge the fix back into the
>> 2.4-fixes branch?
>>
>> Regards
>> Andi
>>
>> --
>> View this message in context: http://cxf.547215.n5.nabble.com/Problem-with-new-transform-feature-tp4599185p4646441.html
>> Sent from the cxf-user mailing list archive at Nabble.com.
>>
>
Re: Problem with new transform feature
Posted by Aki Yoshida <el...@googlemail.com>.
Hi Andi,
yes. Sorry for my delay. I will be merging it into 2.4.x today.
Yesterday, I was doing a few things in between and got mixed up with a
few things.
So, I wanted to be more careful this time.
regards, aki
2011/7/29 akuhtz <an...@siemens.com>:
> Hi Aki,
>
> Thanks for the fixes. Is it possible to merge the fix back into the
> 2.4-fixes branch?
>
> Regards
> Andi
>
> --
> View this message in context: http://cxf.547215.n5.nabble.com/Problem-with-new-transform-feature-tp4599185p4646441.html
> Sent from the cxf-user mailing list archive at Nabble.com.
>
RE: Problem with new transform feature
Posted by akuhtz <an...@siemens.com>.
Hi Aki,
Thanks for the fixes. Is it possible to merge the fix back into the
2.4-fixes branch?
Regards
Andi
--
View this message in context: http://cxf.547215.n5.nabble.com/Problem-with-new-transform-feature-tp4599185p4646441.html
Sent from the cxf-user mailing list archive at Nabble.com.
Re: Problem with new transform feature
Posted by Sergey Beryozkin <sb...@gmail.com>.
Hi Aki
On Tue, Jul 26, 2011 at 6:38 PM, Aki Yoshida <el...@googlemail.com> wrote:
> Hi Andi, Sergey,
>
> If Andi can attach this new test case to his jira ticket, that would be good.
> I can then check if it is taken care in my implementation.
>
> by the way, Sergery, in our discussion, we assumed for the append mode
> that the key parameter indicated the new element value and the value
> parameter indicated the position, as the cxf documentaiton says:
>
>> "outAppendElements" map property: can be used to append new simple or qualified elements to the output; keys are the new elements, values are the elements the new ones will be appended before.
>>"inAppendElements" map property : can be used to append new simple or qualified elements to the input; see the "outAppendElements" property description for an example
>
> But I just noticed that the current implementaiton uses the key
> parameter for indicating the position and the value parameter for
> describing the new element. So, it's wrongly implemented. But I think
> this is a more intuitive convention that is actually aligned with the
> other paramter usage. For instance for the transform feature, the key
> parameter indicates the old name and the value parameter indicates the
> new name. In short, the value parameter describes the new element. So,
> I think we can keep this convention and update the documentation
> accordingly. Is this okay?
>
thanks for spotting it. Yes, I can see the existing tests do assume
the values contain new elements :-), I just fixed the documentation,
and we can enhance it once the more advanced append functionality is supported
Thanks, Sergey
> thanks.
> regards, aki
>
> 2011/7/26 Sergey Beryozkin <sb...@gmail.com>:
>> Hi Andi
>>
>> Thanks for continuing stressing InTransformReader :-).
>> It was mainly used for basic transformations, and having it dealing with
>> more involved transformations will help to make it more robust.
>> I'm on vacation starting from tomorrow, so I'm not sure if I get a chance to
>> fix it today. I will back online in early August.
>> Aki may get a chance to contribute his own patch and that can help with
>> resolving this issue too if I won't get it resolved before then, we'll see
>> :-)
>>
>> Cheers, Sergey
>>
>>> Hi Sergey,
>>>
>>> I've started the test of my sample project with 2.4.2-SNAPSHOT but now it
>>> fails in the DocLiteralInInterceptor. I'll try to create a unit test for
>>> this problem.
>>>
>>>
>>> 11:22:54.675 WARN [org.apache.cxf.phase.PhaseInterceptorChain]
>>> Interceptor
>>> for {http://cxf.apache.org/transform}TransformTestService has thrown
>>> exception, unwinding now
>>> java.lang.IllegalStateException: Current event not START_ELEMENT or
>>> END_ELEMENT
>>> at
>>>
>>> com.ctc.wstx.sr.BasicStreamReader.getNamespaceURI(BasicStreamReader.java:775)
>>> at
>>>
>>> org.apache.cxf.staxutils.DepthXMLStreamReader.getNamespaceURI(DepthXMLStreamReader.java:130)
>>> at
>>>
>>> org.apache.cxf.staxutils.transform.InTransformReader.readCurrentElement(InTransformReader.java:163)
>>> at
>>>
>>> org.apache.cxf.staxutils.transform.InTransformReader.getNamespaceURI(InTransformReader.java:142)
>>> at
>>>
>>> org.apache.cxf.staxutils.transform.InTransformReader.getName(InTransformReader.java:170)
>>> at
>>>
>>> org.apache.cxf.interceptor.DocLiteralInInterceptor.handleMessage(DocLiteralInInterceptor.java:90)
>>> at
>>>
>>> org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:263)
>>> at
>>>
>>> org.apache.cxf.transport.ChainInitiationObserver.onMessage(ChainInitiationObserver.java:118)
>>> at
>>>
>>> org.apache.cxf.transport.http_jetty.JettyHTTPDestination.serviceRequest(JettyHTTPDestination.java:318)
>>>
>>>
>>> Cheers
>>> Andi
>>>
>>> --
>>> View this message in context:
>>> http://cxf.547215.n5.nabble.com/Problem-with-new-transform-feature-tp4599185p4634209.html
>>> Sent from the cxf-user mailing list archive at Nabble.com.
>>
>>
>
--
Sergey Beryozkin
http://sberyozkin.blogspot.com
Talend - http://www.talend.com
RE: Problem with new transform feature
Posted by "Kuhtz, Andreas" <an...@atos.net>.
Hi Aki,
Yes, it is the same. The PartialXMLStreamReader must only return the complete header and en empty Body element because the end tag is set to Body.
If you look at the expected response the Body tag is empty in both patch versions.
Thank you very much for your help! I'll try to verify if my tests work with your changes.
Cheers
Andi
-----Original Message-----
From: Aki Yoshida [mailto:elakito@googlemail.com]
Sent: Donnerstag, 28. Juli 2011 13:21
To: Kuhtz, Andreas
Cc: Sergey Beryozkin; users@cxf.apache.org
Subject: Re: Problem with new transform feature
Hi Andi,
I verified it against all your test cases (including the last one
patch6) to work fine. But is this test case equivalent to your
original testReaderPartialWithComplexRequestSameNamespace test case
from patch2?
While integrating all your test cases by extracting the input and
output XML into seprate files for comparison, I noticed the similarity
of these two test cases. Let me know if I am missing something here.
I have also added the four append-element variants that Sergey and I
discussed along with their test cases..
I will integrate my change in the repos shortly.
regards, aki
2011/7/26 Kuhtz, Andreas <an...@atos.net>:
> Hi Aki,
>
> It's already attached, just use the last attachment. Currently I thinks the problem is somewhere in the getName() of InTransformReader that is called by next() of PartialXMLStreamReader and does not find the endTag ....
>
> Cheers,
> Andi
>
> -----Original Message-----
> From: Aki Yoshida [mailto:elakito@googlemail.com]
> Sent: Dienstag, 26. Juli 2011 19:39
> To: Kuhtz, Andreas; Sergey Beryozkin
> Cc: users@cxf.apache.org
> Subject: Re: Problem with new transform feature
>
> Hi Andi, Sergey,
>
> If Andi can attach this new test case to his jira ticket, that would be good.
> I can then check if it is taken care in my implementation.
>
> by the way, Sergery, in our discussion, we assumed for the append mode
> that the key parameter indicated the new element value and the value
> parameter indicated the position, as the cxf documentaiton says:
>
>> "outAppendElements" map property: can be used to append new simple or qualified elements to the output; keys are the new elements, values are the elements the new ones will be appended before.
>>"inAppendElements" map property : can be used to append new simple or qualified elements to the input; see the "outAppendElements" property description for an example
>
> But I just noticed that the current implementaiton uses the key
> parameter for indicating the position and the value parameter for
> describing the new element. So, it's wrongly implemented. But I think
> this is a more intuitive convention that is actually aligned with the
> other paramter usage. For instance for the transform feature, the key
> parameter indicates the old name and the value parameter indicates the
> new name. In short, the value parameter describes the new element. So,
> I think we can keep this convention and update the documentation
> accordingly. Is this okay?
>
> thanks.
> regards, aki
>
> 2011/7/26 Sergey Beryozkin <sb...@gmail.com>:
>> Hi Andi
>>
>> Thanks for continuing stressing InTransformReader :-).
>> It was mainly used for basic transformations, and having it dealing with
>> more involved transformations will help to make it more robust.
>> I'm on vacation starting from tomorrow, so I'm not sure if I get a chance to
>> fix it today. I will back online in early August.
>> Aki may get a chance to contribute his own patch and that can help with
>> resolving this issue too if I won't get it resolved before then, we'll see
>> :-)
>>
>> Cheers, Sergey
>>
>>> Hi Sergey,
>>>
>>> I've started the test of my sample project with 2.4.2-SNAPSHOT but now it
>>> fails in the DocLiteralInInterceptor. I'll try to create a unit test for
>>> this problem.
>>>
>>>
>>> 11:22:54.675 WARN [org.apache.cxf.phase.PhaseInterceptorChain]
>>> Interceptor
>>> for {http://cxf.apache.org/transform}TransformTestService has thrown
>>> exception, unwinding now
>>> java.lang.IllegalStateException: Current event not START_ELEMENT or
>>> END_ELEMENT
>>> at
>>>
>>> com.ctc.wstx.sr.BasicStreamReader.getNamespaceURI(BasicStreamReader.java:775)
>>> at
>>>
>>> org.apache.cxf.staxutils.DepthXMLStreamReader.getNamespaceURI(DepthXMLStreamReader.java:130)
>>> at
>>>
>>> org.apache.cxf.staxutils.transform.InTransformReader.readCurrentElement(InTransformReader.java:163)
>>> at
>>>
>>> org.apache.cxf.staxutils.transform.InTransformReader.getNamespaceURI(InTransformReader.java:142)
>>> at
>>>
>>> org.apache.cxf.staxutils.transform.InTransformReader.getName(InTransformReader.java:170)
>>> at
>>>
>>> org.apache.cxf.interceptor.DocLiteralInInterceptor.handleMessage(DocLiteralInInterceptor.java:90)
>>> at
>>>
>>> org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:263)
>>> at
>>>
>>> org.apache.cxf.transport.ChainInitiationObserver.onMessage(ChainInitiationObserver.java:118)
>>> at
>>>
>>> org.apache.cxf.transport.http_jetty.JettyHTTPDestination.serviceRequest(JettyHTTPDestination.java:318)
>>>
>>>
>>> Cheers
>>> Andi
>>>
>>> --
>>> View this message in context:
>>> http://cxf.547215.n5.nabble.com/Problem-with-new-transform-feature-tp4599185p4634209.html
>>> Sent from the cxf-user mailing list archive at Nabble.com.
>>
>>
>
Re: Problem with new transform feature
Posted by Aki Yoshida <el...@googlemail.com>.
Hi Andi,
I verified it against all your test cases (including the last one
patch6) to work fine. But is this test case equivalent to your
original testReaderPartialWithComplexRequestSameNamespace test case
from patch2?
While integrating all your test cases by extracting the input and
output XML into seprate files for comparison, I noticed the similarity
of these two test cases. Let me know if I am missing something here.
I have also added the four append-element variants that Sergey and I
discussed along with their test cases..
I will integrate my change in the repos shortly.
regards, aki
2011/7/26 Kuhtz, Andreas <an...@atos.net>:
> Hi Aki,
>
> It's already attached, just use the last attachment. Currently I thinks the problem is somewhere in the getName() of InTransformReader that is called by next() of PartialXMLStreamReader and does not find the endTag ....
>
> Cheers,
> Andi
>
> -----Original Message-----
> From: Aki Yoshida [mailto:elakito@googlemail.com]
> Sent: Dienstag, 26. Juli 2011 19:39
> To: Kuhtz, Andreas; Sergey Beryozkin
> Cc: users@cxf.apache.org
> Subject: Re: Problem with new transform feature
>
> Hi Andi, Sergey,
>
> If Andi can attach this new test case to his jira ticket, that would be good.
> I can then check if it is taken care in my implementation.
>
> by the way, Sergery, in our discussion, we assumed for the append mode
> that the key parameter indicated the new element value and the value
> parameter indicated the position, as the cxf documentaiton says:
>
>> "outAppendElements" map property: can be used to append new simple or qualified elements to the output; keys are the new elements, values are the elements the new ones will be appended before.
>>"inAppendElements" map property : can be used to append new simple or qualified elements to the input; see the "outAppendElements" property description for an example
>
> But I just noticed that the current implementaiton uses the key
> parameter for indicating the position and the value parameter for
> describing the new element. So, it's wrongly implemented. But I think
> this is a more intuitive convention that is actually aligned with the
> other paramter usage. For instance for the transform feature, the key
> parameter indicates the old name and the value parameter indicates the
> new name. In short, the value parameter describes the new element. So,
> I think we can keep this convention and update the documentation
> accordingly. Is this okay?
>
> thanks.
> regards, aki
>
> 2011/7/26 Sergey Beryozkin <sb...@gmail.com>:
>> Hi Andi
>>
>> Thanks for continuing stressing InTransformReader :-).
>> It was mainly used for basic transformations, and having it dealing with
>> more involved transformations will help to make it more robust.
>> I'm on vacation starting from tomorrow, so I'm not sure if I get a chance to
>> fix it today. I will back online in early August.
>> Aki may get a chance to contribute his own patch and that can help with
>> resolving this issue too if I won't get it resolved before then, we'll see
>> :-)
>>
>> Cheers, Sergey
>>
>>> Hi Sergey,
>>>
>>> I've started the test of my sample project with 2.4.2-SNAPSHOT but now it
>>> fails in the DocLiteralInInterceptor. I'll try to create a unit test for
>>> this problem.
>>>
>>>
>>> 11:22:54.675 WARN [org.apache.cxf.phase.PhaseInterceptorChain]
>>> Interceptor
>>> for {http://cxf.apache.org/transform}TransformTestService has thrown
>>> exception, unwinding now
>>> java.lang.IllegalStateException: Current event not START_ELEMENT or
>>> END_ELEMENT
>>> at
>>>
>>> com.ctc.wstx.sr.BasicStreamReader.getNamespaceURI(BasicStreamReader.java:775)
>>> at
>>>
>>> org.apache.cxf.staxutils.DepthXMLStreamReader.getNamespaceURI(DepthXMLStreamReader.java:130)
>>> at
>>>
>>> org.apache.cxf.staxutils.transform.InTransformReader.readCurrentElement(InTransformReader.java:163)
>>> at
>>>
>>> org.apache.cxf.staxutils.transform.InTransformReader.getNamespaceURI(InTransformReader.java:142)
>>> at
>>>
>>> org.apache.cxf.staxutils.transform.InTransformReader.getName(InTransformReader.java:170)
>>> at
>>>
>>> org.apache.cxf.interceptor.DocLiteralInInterceptor.handleMessage(DocLiteralInInterceptor.java:90)
>>> at
>>>
>>> org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:263)
>>> at
>>>
>>> org.apache.cxf.transport.ChainInitiationObserver.onMessage(ChainInitiationObserver.java:118)
>>> at
>>>
>>> org.apache.cxf.transport.http_jetty.JettyHTTPDestination.serviceRequest(JettyHTTPDestination.java:318)
>>>
>>>
>>> Cheers
>>> Andi
>>>
>>> --
>>> View this message in context:
>>> http://cxf.547215.n5.nabble.com/Problem-with-new-transform-feature-tp4599185p4634209.html
>>> Sent from the cxf-user mailing list archive at Nabble.com.
>>
>>
>
RE: Problem with new transform feature
Posted by "Kuhtz, Andreas" <an...@atos.net>.
Hi Aki,
It's already attached, just use the last attachment. Currently I thinks the problem is somewhere in the getName() of InTransformReader that is called by next() of PartialXMLStreamReader and does not find the endTag ....
Cheers,
Andi
-----Original Message-----
From: Aki Yoshida [mailto:elakito@googlemail.com]
Sent: Dienstag, 26. Juli 2011 19:39
To: Kuhtz, Andreas; Sergey Beryozkin
Cc: users@cxf.apache.org
Subject: Re: Problem with new transform feature
Hi Andi, Sergey,
If Andi can attach this new test case to his jira ticket, that would be good.
I can then check if it is taken care in my implementation.
by the way, Sergery, in our discussion, we assumed for the append mode
that the key parameter indicated the new element value and the value
parameter indicated the position, as the cxf documentaiton says:
> "outAppendElements" map property: can be used to append new simple or qualified elements to the output; keys are the new elements, values are the elements the new ones will be appended before.
>"inAppendElements" map property : can be used to append new simple or qualified elements to the input; see the "outAppendElements" property description for an example
But I just noticed that the current implementaiton uses the key
parameter for indicating the position and the value parameter for
describing the new element. So, it's wrongly implemented. But I think
this is a more intuitive convention that is actually aligned with the
other paramter usage. For instance for the transform feature, the key
parameter indicates the old name and the value parameter indicates the
new name. In short, the value parameter describes the new element. So,
I think we can keep this convention and update the documentation
accordingly. Is this okay?
thanks.
regards, aki
2011/7/26 Sergey Beryozkin <sb...@gmail.com>:
> Hi Andi
>
> Thanks for continuing stressing InTransformReader :-).
> It was mainly used for basic transformations, and having it dealing with
> more involved transformations will help to make it more robust.
> I'm on vacation starting from tomorrow, so I'm not sure if I get a chance to
> fix it today. I will back online in early August.
> Aki may get a chance to contribute his own patch and that can help with
> resolving this issue too if I won't get it resolved before then, we'll see
> :-)
>
> Cheers, Sergey
>
>> Hi Sergey,
>>
>> I've started the test of my sample project with 2.4.2-SNAPSHOT but now it
>> fails in the DocLiteralInInterceptor. I'll try to create a unit test for
>> this problem.
>>
>>
>> 11:22:54.675 WARN [org.apache.cxf.phase.PhaseInterceptorChain]
>> Interceptor
>> for {http://cxf.apache.org/transform}TransformTestService has thrown
>> exception, unwinding now
>> java.lang.IllegalStateException: Current event not START_ELEMENT or
>> END_ELEMENT
>> at
>>
>> com.ctc.wstx.sr.BasicStreamReader.getNamespaceURI(BasicStreamReader.java:775)
>> at
>>
>> org.apache.cxf.staxutils.DepthXMLStreamReader.getNamespaceURI(DepthXMLStreamReader.java:130)
>> at
>>
>> org.apache.cxf.staxutils.transform.InTransformReader.readCurrentElement(InTransformReader.java:163)
>> at
>>
>> org.apache.cxf.staxutils.transform.InTransformReader.getNamespaceURI(InTransformReader.java:142)
>> at
>>
>> org.apache.cxf.staxutils.transform.InTransformReader.getName(InTransformReader.java:170)
>> at
>>
>> org.apache.cxf.interceptor.DocLiteralInInterceptor.handleMessage(DocLiteralInInterceptor.java:90)
>> at
>>
>> org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:263)
>> at
>>
>> org.apache.cxf.transport.ChainInitiationObserver.onMessage(ChainInitiationObserver.java:118)
>> at
>>
>> org.apache.cxf.transport.http_jetty.JettyHTTPDestination.serviceRequest(JettyHTTPDestination.java:318)
>>
>>
>> Cheers
>> Andi
>>
>> --
>> View this message in context:
>> http://cxf.547215.n5.nabble.com/Problem-with-new-transform-feature-tp4599185p4634209.html
>> Sent from the cxf-user mailing list archive at Nabble.com.
>
>
Re: Problem with new transform feature
Posted by Aki Yoshida <el...@googlemail.com>.
Hi Andi, Sergey,
If Andi can attach this new test case to his jira ticket, that would be good.
I can then check if it is taken care in my implementation.
by the way, Sergery, in our discussion, we assumed for the append mode
that the key parameter indicated the new element value and the value
parameter indicated the position, as the cxf documentaiton says:
> "outAppendElements" map property: can be used to append new simple or qualified elements to the output; keys are the new elements, values are the elements the new ones will be appended before.
>"inAppendElements" map property : can be used to append new simple or qualified elements to the input; see the "outAppendElements" property description for an example
But I just noticed that the current implementaiton uses the key
parameter for indicating the position and the value parameter for
describing the new element. So, it's wrongly implemented. But I think
this is a more intuitive convention that is actually aligned with the
other paramter usage. For instance for the transform feature, the key
parameter indicates the old name and the value parameter indicates the
new name. In short, the value parameter describes the new element. So,
I think we can keep this convention and update the documentation
accordingly. Is this okay?
thanks.
regards, aki
2011/7/26 Sergey Beryozkin <sb...@gmail.com>:
> Hi Andi
>
> Thanks for continuing stressing InTransformReader :-).
> It was mainly used for basic transformations, and having it dealing with
> more involved transformations will help to make it more robust.
> I'm on vacation starting from tomorrow, so I'm not sure if I get a chance to
> fix it today. I will back online in early August.
> Aki may get a chance to contribute his own patch and that can help with
> resolving this issue too if I won't get it resolved before then, we'll see
> :-)
>
> Cheers, Sergey
>
>> Hi Sergey,
>>
>> I've started the test of my sample project with 2.4.2-SNAPSHOT but now it
>> fails in the DocLiteralInInterceptor. I'll try to create a unit test for
>> this problem.
>>
>>
>> 11:22:54.675 WARN [org.apache.cxf.phase.PhaseInterceptorChain]
>> Interceptor
>> for {http://cxf.apache.org/transform}TransformTestService has thrown
>> exception, unwinding now
>> java.lang.IllegalStateException: Current event not START_ELEMENT or
>> END_ELEMENT
>> at
>>
>> com.ctc.wstx.sr.BasicStreamReader.getNamespaceURI(BasicStreamReader.java:775)
>> at
>>
>> org.apache.cxf.staxutils.DepthXMLStreamReader.getNamespaceURI(DepthXMLStreamReader.java:130)
>> at
>>
>> org.apache.cxf.staxutils.transform.InTransformReader.readCurrentElement(InTransformReader.java:163)
>> at
>>
>> org.apache.cxf.staxutils.transform.InTransformReader.getNamespaceURI(InTransformReader.java:142)
>> at
>>
>> org.apache.cxf.staxutils.transform.InTransformReader.getName(InTransformReader.java:170)
>> at
>>
>> org.apache.cxf.interceptor.DocLiteralInInterceptor.handleMessage(DocLiteralInInterceptor.java:90)
>> at
>>
>> org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:263)
>> at
>>
>> org.apache.cxf.transport.ChainInitiationObserver.onMessage(ChainInitiationObserver.java:118)
>> at
>>
>> org.apache.cxf.transport.http_jetty.JettyHTTPDestination.serviceRequest(JettyHTTPDestination.java:318)
>>
>>
>> Cheers
>> Andi
>>
>> --
>> View this message in context:
>> http://cxf.547215.n5.nabble.com/Problem-with-new-transform-feature-tp4599185p4634209.html
>> Sent from the cxf-user mailing list archive at Nabble.com.
>
>
Re: Problem with new transform feature
Posted by Sergey Beryozkin <sb...@gmail.com>.
Hi Andi
Thanks for continuing stressing InTransformReader :-).
It was mainly used for basic transformations, and having it dealing with
more involved transformations will help to make it more robust.
I'm on vacation starting from tomorrow, so I'm not sure if I get a
chance to fix it today. I will back online in early August.
Aki may get a chance to contribute his own patch and that can help with
resolving this issue too if I won't get it resolved before then, we'll
see :-)
Cheers, Sergey
> Hi Sergey,
>
> I've started the test of my sample project with 2.4.2-SNAPSHOT but now it
> fails in the DocLiteralInInterceptor. I'll try to create a unit test for
> this problem.
>
>
> 11:22:54.675 WARN [org.apache.cxf.phase.PhaseInterceptorChain] Interceptor
> for {http://cxf.apache.org/transform}TransformTestService has thrown
> exception, unwinding now
> java.lang.IllegalStateException: Current event not START_ELEMENT or
> END_ELEMENT
> at
> com.ctc.wstx.sr.BasicStreamReader.getNamespaceURI(BasicStreamReader.java:775)
> at
> org.apache.cxf.staxutils.DepthXMLStreamReader.getNamespaceURI(DepthXMLStreamReader.java:130)
> at
> org.apache.cxf.staxutils.transform.InTransformReader.readCurrentElement(InTransformReader.java:163)
> at
> org.apache.cxf.staxutils.transform.InTransformReader.getNamespaceURI(InTransformReader.java:142)
> at
> org.apache.cxf.staxutils.transform.InTransformReader.getName(InTransformReader.java:170)
> at
> org.apache.cxf.interceptor.DocLiteralInInterceptor.handleMessage(DocLiteralInInterceptor.java:90)
> at
> org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:263)
> at
> org.apache.cxf.transport.ChainInitiationObserver.onMessage(ChainInitiationObserver.java:118)
> at
> org.apache.cxf.transport.http_jetty.JettyHTTPDestination.serviceRequest(JettyHTTPDestination.java:318)
>
>
> Cheers
> Andi
>
> --
> View this message in context: http://cxf.547215.n5.nabble.com/Problem-with-new-transform-feature-tp4599185p4634209.html
> Sent from the cxf-user mailing list archive at Nabble.com.
Re: Problem with new transform feature
Posted by akuhtz <an...@siemens.com>.
Hi Sergey,
I've started the test of my sample project with 2.4.2-SNAPSHOT but now it
fails in the DocLiteralInInterceptor. I'll try to create a unit test for
this problem.
11:22:54.675 WARN [org.apache.cxf.phase.PhaseInterceptorChain] Interceptor
for {http://cxf.apache.org/transform}TransformTestService has thrown
exception, unwinding now
java.lang.IllegalStateException: Current event not START_ELEMENT or
END_ELEMENT
at
com.ctc.wstx.sr.BasicStreamReader.getNamespaceURI(BasicStreamReader.java:775)
at
org.apache.cxf.staxutils.DepthXMLStreamReader.getNamespaceURI(DepthXMLStreamReader.java:130)
at
org.apache.cxf.staxutils.transform.InTransformReader.readCurrentElement(InTransformReader.java:163)
at
org.apache.cxf.staxutils.transform.InTransformReader.getNamespaceURI(InTransformReader.java:142)
at
org.apache.cxf.staxutils.transform.InTransformReader.getName(InTransformReader.java:170)
at
org.apache.cxf.interceptor.DocLiteralInInterceptor.handleMessage(DocLiteralInInterceptor.java:90)
at
org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:263)
at
org.apache.cxf.transport.ChainInitiationObserver.onMessage(ChainInitiationObserver.java:118)
at
org.apache.cxf.transport.http_jetty.JettyHTTPDestination.serviceRequest(JettyHTTPDestination.java:318)
Cheers
Andi
--
View this message in context: http://cxf.547215.n5.nabble.com/Problem-with-new-transform-feature-tp4599185p4634209.html
Sent from the cxf-user mailing list archive at Nabble.com.
Re: Problem with new transform feature
Posted by Sergey Beryozkin <sb...@gmail.com>.
Hi Aki,
sorry for a delay,
> Hi Sergey,
>
> 2011/7/25 Sergey Beryozkin<sb...@gmail.com>:
>> Hi Aki,
>>> key="{http:books}order" value="{http:books}dvd"
>>> will wrap the<ns:dvd> element with<ns:order> element.
>>>
>>> key="{http:books}book:cxf" value="{http:books}dvd"
>>> will add<ns:book>cxf</ns:book> after<ns:dvd> element.
>>>
>>> key="{http:books}book:cxf" value="{http:books}oder/"
>>> will add<ns:book>cxf</ns:book> as the first child of<ns:order>.
>>>
>> How will we differentiate in the last 2 examples whether it's before or
>> after case ?
>
> For the last two (the simple content mode), Using the position
> identifier "{http:books}dvd" to indicate the insertion of the book
> element after the dvd element in the same level (as there is no
> trailing "/"). In contrast, using "{http:books}order/" to indicate the
> insertion of the book element in the next level below the order
> element (as the trailing "/" is present here). In this way, we can
> distinguish the two variants: inserting after the specified element in
> the same level or inserting after the element in the next level.
>
OK, I understand the idea
> In any case, we need this "append-afer-in-the-next-level" rather than
> "append-before" in order to be able to append an element within an
> empty element.
>
> eg. suppose we have
> <orders></orders>
>
> and we want to add<order>orange</order> in the order's empty content,
> which means to produce
> <orders><order>orange</order></orders>
>
> we can use
> key="order:orange" value="orders/"
>
> if we provide only append-after and append-before in the same level,
> we cannot achieve this operation (as there is no element after or
> before to mark the postion of the insertion). The benefit of assuming
> the append-after intead of append-before is that this intuitive
> trailing slash notation can be used to denote this particular
> insertion operation.
>
> Technically, we might also want to have two wrapping operations: the
> normal wrap and the wrap-the-next-level, where the normal wrap being
> the current append's wrapping operation.
> eg suppose we have
> <orders>
> <book>cxf</book>
> <dvd>camel</dvd>
> </orders>
>
> and we want to produce
> <orders>
> <order>
> <book>cxf</book>
> <dvd>camel</dvd>
> </order>
> </orders>
>
> It would be easier to have this wrap-the-next-level notation. This can
> be probably written as
> key="order" value="orders/"
>
> with having the trailing "/" to indicate the wrapping to take place
> for the children on the orders element instead of the element itself.
>
> How do you think?
>
That actually looks cool, because it seems we can even avoid adding a
dedicated configuration elements with the append-after semantics, as the
trailing "/" slash will cover that for all the cases, including
appending simple content elements and wrappers, before/after a given
element.
Thanks, Sergey
> regards, aki
>>
>> I'm seeing it a bit differently as I'm assuming at the moment that existing
>> inAppendMap and outAppendMap are still used only for the append-before mode,
>> where key is the element to append, but with some enhancements:
>>
>> key="{http:books}order" value="{http:books}dvd"
>> will wrap dvd with order, same as in your example
>>
>> key="{http:books}book:cxf" value="{http:books}dvd"
>> will add<ns:book>cxf</ns:book> before<ns:dvd> element.
>>
>> key="{http:books}book:cxf" value="{http:books}oder/"
>> will add<ns:book>cxf</ns:book> before<ns:order>.
>>
>> and we'd need a dedicated configuration element for the append-after case.
>> So given
>> <orders><order><id/></order></orders>
>>
>> we can have all<orders> or all<order> or<id> wrapped with say "wrapper",
>> using the append-before mode.
>> Next, we can have say "a:b" (<a>b</a>) before order, or id only. Attempting
>> to add it before orders will lead to malformed xml.
>> Next we can get c:d after id or after order.
>>
>> That should cover all the variations, but may be I'm not seeing all the
>> details :-). The only thing I don't like is that saying "insert after id" is
>> not terribly safe because we may multiple ids in the doc with some ids being
>> in a diff context - but I would not worry about it for now :-), we can
>> assume we can have only orders containing ids and such...
>>
>> Cheers, Sergey
>>
>>> regards, aki
>>>>
>>
Re: Problem with new transform feature
Posted by Aki Yoshida <el...@googlemail.com>.
Hi Sergey,
2011/7/25 Sergey Beryozkin <sb...@gmail.com>:
> Hi Aki,
>> key="{http:books}order" value="{http:books}dvd"
>> will wrap the<ns:dvd> element with<ns:order> element.
>>
>> key="{http:books}book:cxf" value="{http:books}dvd"
>> will add<ns:book>cxf</ns:book> after<ns:dvd> element.
>>
>> key="{http:books}book:cxf" value="{http:books}oder/"
>> will add<ns:book>cxf</ns:book> as the first child of<ns:order>.
>>
> How will we differentiate in the last 2 examples whether it's before or
> after case ?
For the last two (the simple content mode), Using the position
identifier "{http:books}dvd" to indicate the insertion of the book
element after the dvd element in the same level (as there is no
trailing "/"). In contrast, using "{http:books}order/" to indicate the
insertion of the book element in the next level below the order
element (as the trailing "/" is present here). In this way, we can
distinguish the two variants: inserting after the specified element in
the same level or inserting after the element in the next level.
In any case, we need this "append-afer-in-the-next-level" rather than
"append-before" in order to be able to append an element within an
empty element.
eg. suppose we have
<orders></orders>
and we want to add <order>orange</order> in the order's empty content,
which means to produce
<orders><order>orange</order></orders>
we can use
key="order:orange" value="orders/"
if we provide only append-after and append-before in the same level,
we cannot achieve this operation (as there is no element after or
before to mark the postion of the insertion). The benefit of assuming
the append-after intead of append-before is that this intuitive
trailing slash notation can be used to denote this particular
insertion operation.
Technically, we might also want to have two wrapping operations: the
normal wrap and the wrap-the-next-level, where the normal wrap being
the current append's wrapping operation.
eg suppose we have
<orders>
<book>cxf</book>
<dvd>camel</dvd>
</orders>
and we want to produce
<orders>
<order>
<book>cxf</book>
<dvd>camel</dvd>
</order>
</orders>
It would be easier to have this wrap-the-next-level notation. This can
be probably written as
key="order" value="orders/"
with having the trailing "/" to indicate the wrapping to take place
for the children on the orders element instead of the element itself.
How do you think?
regards, aki
>
> I'm seeing it a bit differently as I'm assuming at the moment that existing
> inAppendMap and outAppendMap are still used only for the append-before mode,
> where key is the element to append, but with some enhancements:
>
> key="{http:books}order" value="{http:books}dvd"
> will wrap dvd with order, same as in your example
>
> key="{http:books}book:cxf" value="{http:books}dvd"
> will add<ns:book>cxf</ns:book> before <ns:dvd> element.
>
> key="{http:books}book:cxf" value="{http:books}oder/"
> will add <ns:book>cxf</ns:book> before <ns:order>.
>
> and we'd need a dedicated configuration element for the append-after case.
> So given
> <orders><order><id/></order></orders>
>
> we can have all <orders> or all <order> or <id> wrapped with say "wrapper",
> using the append-before mode.
> Next, we can have say "a:b" (<a>b</a>) before order, or id only. Attempting
> to add it before orders will lead to malformed xml.
> Next we can get c:d after id or after order.
>
> That should cover all the variations, but may be I'm not seeing all the
> details :-). The only thing I don't like is that saying "insert after id" is
> not terribly safe because we may multiple ids in the doc with some ids being
> in a diff context - but I would not worry about it for now :-), we can
> assume we can have only orders containing ids and such...
>
> Cheers, Sergey
>
>> regards, aki
>>>
>
Re: Problem with new transform feature
Posted by Sergey Beryozkin <sb...@gmail.com>.
Hi Aki,
>>>
>>> 2011/7/25 Sergey Beryozkin<sb...@gmail.com>:
>>>>>
>>>>> Not necessarily, as those namespaces are first referenced in the child
>>>>> element where they are declared, their declarations need not be move
>>>>> up to its parent, which is the appended element.
>>>>>
>>>> I saw StaxUtils doing reader.getNamespaceCount() and I was not sure how
>>>> to
>>>> correctly report that in case of appended element the count is 1 :-)
>>>
>>> Okay. I missed this one. I need to overwrite this method to report the
>>> correct value.
>>>
>>>>>> By the way, there's one more limitation there which I haven't got to
>>>>>> addressing yet - to do with being able append simple elements -
>>>>>> currently
>>>>>> it
>>>>>> is possible to add wrappers but it's not possible to add a simple
>>>>>> element
>>>>>> say to the end of the given element's content
>>>>>
>>>>> We could add this feature, but is it interesting to add an empty
>>>>> content element this way? I think we will probably need to provide a
>>>>> way to set its content for this option, preferably filling some
>>>>> content template using some runtime context values. This will likely
>>>>> to require another configuraiton object.
>>>>>
>>>> Agreed - I meant a simple element with a text content only...
>>>>
>>>> inAppendElements/outAppendElements say which elements need to be wrapped
>>>> ,
>>>> or rather, they say "append this element before this one".
>>>> So may be we can have
>>>>
>>>> in/outAppendSimpleElements with the "append this element after this one"
>>>> message ? Say, "{http://books}id:1":"{http://books}book:title", "add a
>>>> book
>>>> ns qualified<id>1</id> after<title>...</title>"
>>>>
>>>> Looks a bit btittle :-) but something along those lines
>>>
>>> In this case, we might need to rename the current append to "wrap" and
>>> the current drop to "unwrap" ;-)
>>>
>>> But I think the append within a sequence is difficult to configure. If
>>> you fix the append-logic to "append-after", you can't append/insert an
>>> element at the very begining. So, that means we will need two
>>> variants: append-before and append-after. Then, the notation will get
>>> even more complicated.
>>>
>>> We'll see if there is some simpler way.
>>>
>>
>> Perhaps we cam always assume the "after" approach always means after the end
>> of a given element.
>> And we can enhance/fix a bit the existing append "wrap" approach (sorry, the
>> property is a bit misnamed :-))), if we have {http:books}book - then it
>> means wrap, and if we have {http:books}book:value then it means just append
>> a simple element
>>
>> So may be that would cover all the append cases?
>
> That looks like a cute idea. Along this line, we could even provide
> the way to insert an element at the very beginning so that there is no
> need for the append-before mode.
>
> key="{http:books}order" value="{http:books}dvd"
> will wrap the<ns:dvd> element with<ns:order> element.
>
> key="{http:books}book:cxf" value="{http:books}dvd"
> will add<ns:book>cxf</ns:book> after<ns:dvd> element.
>
> key="{http:books}book:cxf" value="{http:books}oder/"
> will add<ns:book>cxf</ns:book> as the first child of<ns:order>.
>
How will we differentiate in the last 2 examples whether it's before or
after case ?
I'm seeing it a bit differently as I'm assuming at the moment that
existing inAppendMap and outAppendMap are still used only for the
append-before mode, where key is the element to append, but with some
enhancements:
key="{http:books}order" value="{http:books}dvd"
will wrap dvd with order, same as in your example
key="{http:books}book:cxf" value="{http:books}dvd"
will add<ns:book>cxf</ns:book> before <ns:dvd> element.
key="{http:books}book:cxf" value="{http:books}oder/"
will add <ns:book>cxf</ns:book> before <ns:order>.
and we'd need a dedicated configuration element for the append-after case.
So given
<orders><order><id/></order></orders>
we can have all <orders> or all <order> or <id> wrapped with say
"wrapper", using the append-before mode.
Next, we can have say "a:b" (<a>b</a>) before order, or id only.
Attempting to add it before orders will lead to malformed xml.
Next we can get c:d after id or after order.
That should cover all the variations, but may be I'm not seeing all the
details :-). The only thing I don't like is that saying "insert after
id" is not terribly safe because we may multiple ids in the doc with
some ids being in a diff context - but I would not worry about it for
now :-), we can assume we can have only orders containing ids and such...
Cheers, Sergey
> regards, aki
>>
Re: Problem with new transform feature
Posted by Aki Yoshida <el...@googlemail.com>.
2011/7/25 Sergey Beryozkin <sb...@gmail.com>:
> Hi,
>>
>> Hi Sergey,
>>
>> 2011/7/25 Sergey Beryozkin <sb...@gmail.com>:
>>>>
>>>> Not necessarily, as those namespaces are first referenced in the child
>>>> element where they are declared, their declarations need not be move
>>>> up to its parent, which is the appended element.
>>>>
>>> I saw StaxUtils doing reader.getNamespaceCount() and I was not sure how
>>> to
>>> correctly report that in case of appended element the count is 1 :-)
>>
>> Okay. I missed this one. I need to overwrite this method to report the
>> correct value.
>>
>>>>> By the way, there's one more limitation there which I haven't got to
>>>>> addressing yet - to do with being able append simple elements -
>>>>> currently
>>>>> it
>>>>> is possible to add wrappers but it's not possible to add a simple
>>>>> element
>>>>> say to the end of the given element's content
>>>>
>>>> We could add this feature, but is it interesting to add an empty
>>>> content element this way? I think we will probably need to provide a
>>>> way to set its content for this option, preferably filling some
>>>> content template using some runtime context values. This will likely
>>>> to require another configuraiton object.
>>>>
>>> Agreed - I meant a simple element with a text content only...
>>>
>>> inAppendElements/outAppendElements say which elements need to be wrapped
>>> ,
>>> or rather, they say "append this element before this one".
>>> So may be we can have
>>>
>>> in/outAppendSimpleElements with the "append this element after this one"
>>> message ? Say, "{http://books}id:1":"{http://books}book:title", "add a
>>> book
>>> ns qualified <id>1</id> after <title>...</title>"
>>>
>>> Looks a bit btittle :-) but something along those lines
>>
>> In this case, we might need to rename the current append to "wrap" and
>> the current drop to "unwrap" ;-)
>>
>> But I think the append within a sequence is difficult to configure. If
>> you fix the append-logic to "append-after", you can't append/insert an
>> element at the very begining. So, that means we will need two
>> variants: append-before and append-after. Then, the notation will get
>> even more complicated.
>>
>> We'll see if there is some simpler way.
>>
>
> Perhaps we cam always assume the "after" approach always means after the end
> of a given element.
> And we can enhance/fix a bit the existing append "wrap" approach (sorry, the
> property is a bit misnamed :-))), if we have {http:books}book - then it
> means wrap, and if we have {http:books}book:value then it means just append
> a simple element
>
> So may be that would cover all the append cases?
That looks like a cute idea. Along this line, we could even provide
the way to insert an element at the very beginning so that there is no
need for the append-before mode.
key="{http:books}order" value="{http:books}dvd"
will wrap the <ns:dvd> element with <ns:order> element.
key="{http:books}book:cxf" value="{http:books}dvd"
will add <ns:book>cxf</ns:book> after <ns:dvd> element.
key="{http:books}book:cxf" value="{http:books}oder/"
will add <ns:book>cxf</ns:book> as the first child of <ns:order>.
regards, aki
>
> Cheers, Sergey
>
>> regards, aki
>>
>>> Cheers, Sergey
>>>
>>>> regards, aki
>>>>>
>>>>> thanks, Sergey
>>>>>
>>>>>> thanks.
>>>>>> regards, aki
>
>
Re: Problem with new transform feature
Posted by Sergey Beryozkin <sb...@gmail.com>.
Hi,
> Hi Sergey,
>
> 2011/7/25 Sergey Beryozkin <sb...@gmail.com>:
>>> Not necessarily, as those namespaces are first referenced in the child
>>> element where they are declared, their declarations need not be move
>>> up to its parent, which is the appended element.
>>>
>> I saw StaxUtils doing reader.getNamespaceCount() and I was not sure how to
>> correctly report that in case of appended element the count is 1 :-)
>
> Okay. I missed this one. I need to overwrite this method to report the
> correct value.
>
>>>> By the way, there's one more limitation there which I haven't got to
>>>> addressing yet - to do with being able append simple elements - currently
>>>> it
>>>> is possible to add wrappers but it's not possible to add a simple element
>>>> say to the end of the given element's content
>>> We could add this feature, but is it interesting to add an empty
>>> content element this way? I think we will probably need to provide a
>>> way to set its content for this option, preferably filling some
>>> content template using some runtime context values. This will likely
>>> to require another configuraiton object.
>>>
>> Agreed - I meant a simple element with a text content only...
>>
>> inAppendElements/outAppendElements say which elements need to be wrapped ,
>> or rather, they say "append this element before this one".
>> So may be we can have
>>
>> in/outAppendSimpleElements with the "append this element after this one"
>> message ? Say, "{http://books}id:1":"{http://books}book:title", "add a book
>> ns qualified <id>1</id> after <title>...</title>"
>>
>> Looks a bit btittle :-) but something along those lines
>
> In this case, we might need to rename the current append to "wrap" and
> the current drop to "unwrap" ;-)
>
> But I think the append within a sequence is difficult to configure. If
> you fix the append-logic to "append-after", you can't append/insert an
> element at the very begining. So, that means we will need two
> variants: append-before and append-after. Then, the notation will get
> even more complicated.
>
> We'll see if there is some simpler way.
>
Perhaps we cam always assume the "after" approach always means after the
end of a given element.
And we can enhance/fix a bit the existing append "wrap" approach (sorry,
the property is a bit misnamed :-))), if we have {http:books}book - then
it means wrap, and if we have {http:books}book:value then it means just
append a simple element
So may be that would cover all the append cases?
Cheers, Sergey
> regards, aki
>
>> Cheers, Sergey
>>
>>> regards, aki
>>>> thanks, Sergey
>>>>
>>>>> thanks.
>>>>> regards, aki
Re: Problem with new transform feature
Posted by Aki Yoshida <el...@googlemail.com>.
Hi Sergey,
2011/7/25 Sergey Beryozkin <sb...@gmail.com>:
>> Not necessarily, as those namespaces are first referenced in the child
>> element where they are declared, their declarations need not be move
>> up to its parent, which is the appended element.
>>
> I saw StaxUtils doing reader.getNamespaceCount() and I was not sure how to
> correctly report that in case of appended element the count is 1 :-)
Okay. I missed this one. I need to overwrite this method to report the
correct value.
>>> By the way, there's one more limitation there which I haven't got to
>>> addressing yet - to do with being able append simple elements - currently
>>> it
>>> is possible to add wrappers but it's not possible to add a simple element
>>> say to the end of the given element's content
>>
>> We could add this feature, but is it interesting to add an empty
>> content element this way? I think we will probably need to provide a
>> way to set its content for this option, preferably filling some
>> content template using some runtime context values. This will likely
>> to require another configuraiton object.
>>
> Agreed - I meant a simple element with a text content only...
>
> inAppendElements/outAppendElements say which elements need to be wrapped ,
> or rather, they say "append this element before this one".
> So may be we can have
>
> in/outAppendSimpleElements with the "append this element after this one"
> message ? Say, "{http://books}id:1":"{http://books}book:title", "add a book
> ns qualified <id>1</id> after <title>...</title>"
>
> Looks a bit btittle :-) but something along those lines
In this case, we might need to rename the current append to "wrap" and
the current drop to "unwrap" ;-)
But I think the append within a sequence is difficult to configure. If
you fix the append-logic to "append-after", you can't append/insert an
element at the very begining. So, that means we will need two
variants: append-before and append-after. Then, the notation will get
even more complicated.
We'll see if there is some simpler way.
regards, aki
> Cheers, Sergey
>
>> regards, aki
>>>
>>> thanks, Sergey
>>>
>>>> thanks.
>>>> regards, aki
Re: Problem with new transform feature
Posted by Sergey Beryozkin <sb...@gmail.com>.
Hi Aki
>>
>>> Hi Sergey,
>>> i saw this mail now. I did some experiment with inTransformReader
>>> sometime ago to do some slightly complex transformation and noticed
>>> several things that I expected differently.
>>>
>>> - the advancing the cursor is not done in next() but done implicitly
>>> during the namespace lookup. Because of this, the reader can only be
>>> used/consumed in a specific manor.
>>> - there is no option to remove attributes
>> Yes
>>
>>> - there is no option to remove an element completely (i.e., including
>>> its children)
>> One has to specify all the children of the top level element being removed,
>> it won't scale if the content is arbitrary/large but should work for simpler
>> cases.
>> I wanted to extend it the following way, if a given drop element value is
>> say {http://books}book - then drop this element only and let descendants to
>> stay, if {http://books}book* - drop {http://books}book and all of its
>> descendants.
>
> i didn't use the stax filter to drop the elements but simply added
> this deep drop logic in inTransformReader by interpreting the element
> map configuraiton with an empty value to perform this deep drop.
> e.g. inMap.add("{ns}value", ""} to drop the {ns}value element. I also
> added the original shallow-drop logic directly in inTransformReader. I
> think it's simpler to do both in one reader than layering one on the
> other.
sorry, I got confused, InTransformReader (on the trunk) does support the
shallow drop of the elements via StaxStreamFilter, so supporting a deep
drop with something like inMap.add("{ns}value", ""} makes sense on the
in side. Having inReader dealing with all the drop-related code itself
can make it all a bit simpler I guess...
OutTransformReader does handle the shallow drop internally. And it can
handle the deep one using the same approach you chose for your version
of InTransformReader.
My only concern would be that the config info to do with dropping
elements will be spread across two configuration elements
(inDropElements/inTransformElements and
outDropElements/outTransformElements for shallow/deep drops) but on the
other hand no wildcards will be needed...
>
> <
>>
>>> - the append option duplicates the attributes from the new child element
>>>
>> I see it with namespaces, yes
>
> Not necessarily, as those namespaces are first referenced in the child
> element where they are declared, their declarations need not be move
> up to its parent, which is the appended element.
>
I saw StaxUtils doing reader.getNamespaceCount() and I was not sure how
to correctly report that in case of appended element the count is 1 :-)
>>> So I wrote a different inTransformReader that resolve these issues. I
>>> am wondering if I suggest it to this ticket or put it in another
>>> ticket.
>>>
>> Please, open another ticket - more enhancements will be appreciated a lot.
>> I'm hoping to do a merge to address Andi's issue shortly and may be you can
>> create a patch from the trunk ?
>
> okay.
>
>> By the way, there's one more limitation there which I haven't got to
>> addressing yet - to do with being able append simple elements - currently it
>> is possible to add wrappers but it's not possible to add a simple element
>> say to the end of the given element's content
>
> We could add this feature, but is it interesting to add an empty
> content element this way? I think we will probably need to provide a
> way to set its content for this option, preferably filling some
> content template using some runtime context values. This will likely
> to require another configuraiton object.
>
Agreed - I meant a simple element with a text content only...
inAppendElements/outAppendElements say which elements need to be wrapped
, or rather, they say "append this element before this one".
So may be we can have
in/outAppendSimpleElements with the "append this element after this one"
message ? Say, "{http://books}id:1":"{http://books}book:title", "add a
book ns qualified <id>1</id> after <title>...</title>"
Looks a bit btittle :-) but something along those lines
Cheers, Sergey
> regards, aki
>> thanks, Sergey
>>
>>> thanks.
>>> regards, aki
>>>
>>> 2011/7/25 Sergey Beryozkin <sb...@gmail.com>:
>>>> Sorry, forgot to mention I updated transform interceptors to accept
>>>> phase parameters, just to minimize the number of commits,
>>>> thanks, Sergey
>>>>
>>>> On Sun, Jul 24, 2011 at 11:27 PM, Sergey Beryozkin <sb...@gmail.com>
>>>> wrote:
>>>>> Hi Andi
>>>>>
>>>>> On Sat, Jul 23, 2011 at 8:15 AM, akuhtz <an...@siemens.com>
>>>>> wrote:
>>>>>> Hi Sergey,
>>>>>>
>>>>>> I've created a patch for this problem and opened
>>>>>> https://issues.apache.org/jira/browse/CXF-3681 CXF-3681 .
>>>>>>
>>>>> This is a good contribution, thanks.
>>>>> I've applied most of the patch (DelegatingNamespaceContext fix plus
>>>>> all the new tests) but I had to omit the actual fix for
>>>>> InTransformReader
>>>>> given that the tests in rt/frontend/jaxrs started failing
>>>>> (JAXBElementProvider tests which do rely on the same transform
>>>>> feature).
>>>>> InTransformReader can also handle appending or rather wrapping certain
>>>>> in elements, example,
>>>>>
>>>>> <book><name>CXF</name></book>
>>>>>
>>>>> can be wrapped with say a 'books' element
>>>>>
>>>>> <books><book><name>CXF</name></book></books>
>>>>>
>>>>> At the moment, calling resetCurrentQName in next() 'upsets' some of
>>>>> the tests. Perhaps a simpler reset can be done for your case to start
>>>>> working but it's difficult for me to investigate without a failing
>>>>> test - all of the new tests still pass without this update.
>>>>> I think the complete fix is nearly there :-). For example, configure
>>>>> InTransformReader with appendMap too and then you can reproduce the
>>>>> failure.
>>>>>
>>>>> Thanks, Sergey
>>>>>
>>>>>> Cheers,
>>>>>> Andi
>>>>>>
>>>>>> --
>>>>>> View this message in context:
>>>>>> http://cxf.547215.n5.nabble.com/Problem-with-new-transform-feature-tp4599185p4625533.html
>>>>>> Sent from the cxf-user mailing list archive at Nabble.com.
>>>>>>
>>>>>
>>>>> --
>>>>> Sergey Beryozkin
>>>>>
>>>>> http://sberyozkin.blogspot.com
>>>>> Talend - http://www.talend.com
>>>>>
>>
Re: Problem with new transform feature
Posted by Aki Yoshida <el...@googlemail.com>.
Hi Sergey,
2011/7/25 Sergey Beryozkin <sb...@gmail.com>:
> Hi Aki
>
>> Hi Sergey,
>> i saw this mail now. I did some experiment with inTransformReader
>> sometime ago to do some slightly complex transformation and noticed
>> several things that I expected differently.
>>
>> - the advancing the cursor is not done in next() but done implicitly
>> during the namespace lookup. Because of this, the reader can only be
>> used/consumed in a specific manor.
>> - there is no option to remove attributes
>
> Yes
>
>> - there is no option to remove an element completely (i.e., including
>> its children)
>
> One has to specify all the children of the top level element being removed,
> it won't scale if the content is arbitrary/large but should work for simpler
> cases.
> I wanted to extend it the following way, if a given drop element value is
> say {http://books}book - then drop this element only and let descendants to
> stay, if {http://books}book* - drop {http://books}book and all of its
> descendants.
i didn't use the stax filter to drop the elements but simply added
this deep drop logic in inTransformReader by interpreting the element
map configuraiton with an empty value to perform this deep drop.
e.g. inMap.add("{ns}value", ""} to drop the {ns}value element. I also
added the original shallow-drop logic directly in inTransformReader. I
think it's simpler to do both in one reader than layering one on the
other.
<
>
>
>> - the append option duplicates the attributes from the new child element
>>
> I see it with namespaces, yes
Not necessarily, as those namespaces are first referenced in the child
element where they are declared, their declarations need not be move
up to its parent, which is the appended element.
>
>> So I wrote a different inTransformReader that resolve these issues. I
>> am wondering if I suggest it to this ticket or put it in another
>> ticket.
>>
> Please, open another ticket - more enhancements will be appreciated a lot.
> I'm hoping to do a merge to address Andi's issue shortly and may be you can
> create a patch from the trunk ?
okay.
>
> By the way, there's one more limitation there which I haven't got to
> addressing yet - to do with being able append simple elements - currently it
> is possible to add wrappers but it's not possible to add a simple element
> say to the end of the given element's content
We could add this feature, but is it interesting to add an empty
content element this way? I think we will probably need to provide a
way to set its content for this option, preferably filling some
content template using some runtime context values. This will likely
to require another configuraiton object.
regards, aki
>
> thanks, Sergey
>
>> thanks.
>> regards, aki
>>
>> 2011/7/25 Sergey Beryozkin <sb...@gmail.com>:
>>>
>>> Sorry, forgot to mention I updated transform interceptors to accept
>>> phase parameters, just to minimize the number of commits,
>>> thanks, Sergey
>>>
>>> On Sun, Jul 24, 2011 at 11:27 PM, Sergey Beryozkin <sb...@gmail.com>
>>> wrote:
>>>>
>>>> Hi Andi
>>>>
>>>> On Sat, Jul 23, 2011 at 8:15 AM, akuhtz <an...@siemens.com>
>>>> wrote:
>>>>>
>>>>> Hi Sergey,
>>>>>
>>>>> I've created a patch for this problem and opened
>>>>> https://issues.apache.org/jira/browse/CXF-3681 CXF-3681 .
>>>>>
>>>> This is a good contribution, thanks.
>>>> I've applied most of the patch (DelegatingNamespaceContext fix plus
>>>> all the new tests) but I had to omit the actual fix for
>>>> InTransformReader
>>>> given that the tests in rt/frontend/jaxrs started failing
>>>> (JAXBElementProvider tests which do rely on the same transform
>>>> feature).
>>>> InTransformReader can also handle appending or rather wrapping certain
>>>> in elements, example,
>>>>
>>>> <book><name>CXF</name></book>
>>>>
>>>> can be wrapped with say a 'books' element
>>>>
>>>> <books><book><name>CXF</name></book></books>
>>>>
>>>> At the moment, calling resetCurrentQName in next() 'upsets' some of
>>>> the tests. Perhaps a simpler reset can be done for your case to start
>>>> working but it's difficult for me to investigate without a failing
>>>> test - all of the new tests still pass without this update.
>>>> I think the complete fix is nearly there :-). For example, configure
>>>> InTransformReader with appendMap too and then you can reproduce the
>>>> failure.
>>>>
>>>> Thanks, Sergey
>>>>
>>>>> Cheers,
>>>>> Andi
>>>>>
>>>>> --
>>>>> View this message in context:
>>>>> http://cxf.547215.n5.nabble.com/Problem-with-new-transform-feature-tp4599185p4625533.html
>>>>> Sent from the cxf-user mailing list archive at Nabble.com.
>>>>>
>>>>
>>>>
>>>> --
>>>> Sergey Beryozkin
>>>>
>>>> http://sberyozkin.blogspot.com
>>>> Talend - http://www.talend.com
>>>>
>
>
Re: Problem with new transform feature
Posted by Sergey Beryozkin <sb...@gmail.com>.
Hi Aki
> Hi Sergey,
> i saw this mail now. I did some experiment with inTransformReader
> sometime ago to do some slightly complex transformation and noticed
> several things that I expected differently.
>
> - the advancing the cursor is not done in next() but done implicitly
> during the namespace lookup. Because of this, the reader can only be
> used/consumed in a specific manor.
> - there is no option to remove attributes
Yes
> - there is no option to remove an element completely (i.e., including
> its children)
One has to specify all the children of the top level element being
removed, it won't scale if the content is arbitrary/large but should
work for simpler cases.
I wanted to extend it the following way, if a given drop element value
is say {http://books}book - then drop this element only and let
descendants to stay, if {http://books}book* - drop {http://books}book
and all of its descendants.
> - the append option duplicates the attributes from the new child element
>
I see it with namespaces, yes
> So I wrote a different inTransformReader that resolve these issues. I
> am wondering if I suggest it to this ticket or put it in another
> ticket.
>
Please, open another ticket - more enhancements will be appreciated a
lot. I'm hoping to do a merge to address Andi's issue shortly and may be
you can create a patch from the trunk ?
By the way, there's one more limitation there which I haven't got to
addressing yet - to do with being able append simple elements -
currently it is possible to add wrappers but it's not possible to add a
simple element say to the end of the given element's content
thanks, Sergey
> thanks.
> regards, aki
>
> 2011/7/25 Sergey Beryozkin <sb...@gmail.com>:
>> Sorry, forgot to mention I updated transform interceptors to accept
>> phase parameters, just to minimize the number of commits,
>> thanks, Sergey
>>
>> On Sun, Jul 24, 2011 at 11:27 PM, Sergey Beryozkin <sb...@gmail.com> wrote:
>>> Hi Andi
>>>
>>> On Sat, Jul 23, 2011 at 8:15 AM, akuhtz <an...@siemens.com> wrote:
>>>> Hi Sergey,
>>>>
>>>> I've created a patch for this problem and opened
>>>> https://issues.apache.org/jira/browse/CXF-3681 CXF-3681 .
>>>>
>>> This is a good contribution, thanks.
>>> I've applied most of the patch (DelegatingNamespaceContext fix plus
>>> all the new tests) but I had to omit the actual fix for
>>> InTransformReader
>>> given that the tests in rt/frontend/jaxrs started failing
>>> (JAXBElementProvider tests which do rely on the same transform
>>> feature).
>>> InTransformReader can also handle appending or rather wrapping certain
>>> in elements, example,
>>>
>>> <book><name>CXF</name></book>
>>>
>>> can be wrapped with say a 'books' element
>>>
>>> <books><book><name>CXF</name></book></books>
>>>
>>> At the moment, calling resetCurrentQName in next() 'upsets' some of
>>> the tests. Perhaps a simpler reset can be done for your case to start
>>> working but it's difficult for me to investigate without a failing
>>> test - all of the new tests still pass without this update.
>>> I think the complete fix is nearly there :-). For example, configure
>>> InTransformReader with appendMap too and then you can reproduce the
>>> failure.
>>>
>>> Thanks, Sergey
>>>
>>>> Cheers,
>>>> Andi
>>>>
>>>> --
>>>> View this message in context: http://cxf.547215.n5.nabble.com/Problem-with-new-transform-feature-tp4599185p4625533.html
>>>> Sent from the cxf-user mailing list archive at Nabble.com.
>>>>
>>>
>>>
>>> --
>>> Sergey Beryozkin
>>>
>>> http://sberyozkin.blogspot.com
>>> Talend - http://www.talend.com
>>>
Re: Problem with new transform feature
Posted by Aki Yoshida <el...@googlemail.com>.
Hi Sergey,
i saw this mail now. I did some experiment with inTransformReader
sometime ago to do some slightly complex transformation and noticed
several things that I expected differently.
- the advancing the cursor is not done in next() but done implicitly
during the namespace lookup. Because of this, the reader can only be
used/consumed in a specific manor.
- there is no option to remove attributes
- there is no option to remove an element completely (i.e., including
its children)
- the append option duplicates the attributes from the new child element
So I wrote a different inTransformReader that resolve these issues. I
am wondering if I suggest it to this ticket or put it in another
ticket.
thanks.
regards, aki
2011/7/25 Sergey Beryozkin <sb...@gmail.com>:
> Sorry, forgot to mention I updated transform interceptors to accept
> phase parameters, just to minimize the number of commits,
> thanks, Sergey
>
> On Sun, Jul 24, 2011 at 11:27 PM, Sergey Beryozkin <sb...@gmail.com> wrote:
>> Hi Andi
>>
>> On Sat, Jul 23, 2011 at 8:15 AM, akuhtz <an...@siemens.com> wrote:
>>> Hi Sergey,
>>>
>>> I've created a patch for this problem and opened
>>> https://issues.apache.org/jira/browse/CXF-3681 CXF-3681 .
>>>
>> This is a good contribution, thanks.
>> I've applied most of the patch (DelegatingNamespaceContext fix plus
>> all the new tests) but I had to omit the actual fix for
>> InTransformReader
>> given that the tests in rt/frontend/jaxrs started failing
>> (JAXBElementProvider tests which do rely on the same transform
>> feature).
>> InTransformReader can also handle appending or rather wrapping certain
>> in elements, example,
>>
>> <book><name>CXF</name></book>
>>
>> can be wrapped with say a 'books' element
>>
>> <books><book><name>CXF</name></book></books>
>>
>> At the moment, calling resetCurrentQName in next() 'upsets' some of
>> the tests. Perhaps a simpler reset can be done for your case to start
>> working but it's difficult for me to investigate without a failing
>> test - all of the new tests still pass without this update.
>> I think the complete fix is nearly there :-). For example, configure
>> InTransformReader with appendMap too and then you can reproduce the
>> failure.
>>
>> Thanks, Sergey
>>
>>> Cheers,
>>> Andi
>>>
>>> --
>>> View this message in context: http://cxf.547215.n5.nabble.com/Problem-with-new-transform-feature-tp4599185p4625533.html
>>> Sent from the cxf-user mailing list archive at Nabble.com.
>>>
>>
>>
>>
>> --
>> Sergey Beryozkin
>>
>> http://sberyozkin.blogspot.com
>> Talend - http://www.talend.com
>>
>
Re: Problem with new transform feature
Posted by Sergey Beryozkin <sb...@gmail.com>.
Hi Andi
> Hi Sergey,
>
> I've attached some new tests to the JIRA issue that can be used to reproduce
> the problem.
>
The fix is on the trunk/2.4.x - so please give a try when you get a
chance, thanks for providing all the tests - they helped. I also used
DOM to validate the final result as it appeared that namespace
declarations were produced in the random order.
> And I'll try to have a look at the appending and wrapping theme ... ;-)
>
Please do, appending simple elements is not supported right now. That
would probably be a more useful feature than wrapping, as the closed
context models often differ from the prev version by only the single
(and the last) child element
thanks, Sergey
> Cheers
> Andi
>
> --
> View this message in context: http://cxf.547215.n5.nabble.com/Problem-with-new-transform-feature-tp4599185p4630161.html
> Sent from the cxf-user mailing list archive at Nabble.com.
Re: Problem with new transform feature
Posted by akuhtz <an...@siemens.com>.
Hi Sergey,
I've attached some new tests to the JIRA issue that can be used to reproduce
the problem.
And I'll try to have a look at the appending and wrapping theme ... ;-)
Cheers
Andi
--
View this message in context: http://cxf.547215.n5.nabble.com/Problem-with-new-transform-feature-tp4599185p4630161.html
Sent from the cxf-user mailing list archive at Nabble.com.
Re: Problem with new transform feature
Posted by Sergey Beryozkin <sb...@gmail.com>.
Sorry, forgot to mention I updated transform interceptors to accept
phase parameters, just to minimize the number of commits,
thanks, Sergey
On Sun, Jul 24, 2011 at 11:27 PM, Sergey Beryozkin <sb...@gmail.com> wrote:
> Hi Andi
>
> On Sat, Jul 23, 2011 at 8:15 AM, akuhtz <an...@siemens.com> wrote:
>> Hi Sergey,
>>
>> I've created a patch for this problem and opened
>> https://issues.apache.org/jira/browse/CXF-3681 CXF-3681 .
>>
> This is a good contribution, thanks.
> I've applied most of the patch (DelegatingNamespaceContext fix plus
> all the new tests) but I had to omit the actual fix for
> InTransformReader
> given that the tests in rt/frontend/jaxrs started failing
> (JAXBElementProvider tests which do rely on the same transform
> feature).
> InTransformReader can also handle appending or rather wrapping certain
> in elements, example,
>
> <book><name>CXF</name></book>
>
> can be wrapped with say a 'books' element
>
> <books><book><name>CXF</name></book></books>
>
> At the moment, calling resetCurrentQName in next() 'upsets' some of
> the tests. Perhaps a simpler reset can be done for your case to start
> working but it's difficult for me to investigate without a failing
> test - all of the new tests still pass without this update.
> I think the complete fix is nearly there :-). For example, configure
> InTransformReader with appendMap too and then you can reproduce the
> failure.
>
> Thanks, Sergey
>
>> Cheers,
>> Andi
>>
>> --
>> View this message in context: http://cxf.547215.n5.nabble.com/Problem-with-new-transform-feature-tp4599185p4625533.html
>> Sent from the cxf-user mailing list archive at Nabble.com.
>>
>
>
>
> --
> Sergey Beryozkin
>
> http://sberyozkin.blogspot.com
> Talend - http://www.talend.com
>
Re: Problem with new transform feature
Posted by Sergey Beryozkin <sb...@gmail.com>.
Hi Andi
On Sat, Jul 23, 2011 at 8:15 AM, akuhtz <an...@siemens.com> wrote:
> Hi Sergey,
>
> I've created a patch for this problem and opened
> https://issues.apache.org/jira/browse/CXF-3681 CXF-3681 .
>
This is a good contribution, thanks.
I've applied most of the patch (DelegatingNamespaceContext fix plus
all the new tests) but I had to omit the actual fix for
InTransformReader
given that the tests in rt/frontend/jaxrs started failing
(JAXBElementProvider tests which do rely on the same transform
feature).
InTransformReader can also handle appending or rather wrapping certain
in elements, example,
<book><name>CXF</name></book>
can be wrapped with say a 'books' element
<books><book><name>CXF</name></book></books>
At the moment, calling resetCurrentQName in next() 'upsets' some of
the tests. Perhaps a simpler reset can be done for your case to start
working but it's difficult for me to investigate without a failing
test - all of the new tests still pass without this update.
I think the complete fix is nearly there :-). For example, configure
InTransformReader with appendMap too and then you can reproduce the
failure.
Thanks, Sergey
> Cheers,
> Andi
>
> --
> View this message in context: http://cxf.547215.n5.nabble.com/Problem-with-new-transform-feature-tp4599185p4625533.html
> Sent from the cxf-user mailing list archive at Nabble.com.
>
--
Sergey Beryozkin
http://sberyozkin.blogspot.com
Talend - http://www.talend.com
Re: Problem with new transform feature
Posted by akuhtz <an...@siemens.com>.
Hi Sergey,
I've created a patch for this problem and opened
https://issues.apache.org/jira/browse/CXF-3681 CXF-3681 .
Cheers,
Andi
--
View this message in context: http://cxf.547215.n5.nabble.com/Problem-with-new-transform-feature-tp4599185p4625533.html
Sent from the cxf-user mailing list archive at Nabble.com.
Re: Problem with new transform feature
Posted by Sergey Beryozkin <sb...@gmail.com>.
Hi Andi
Sorry, I actually missed your previous email, so thanks for trying to
figure out where the problem is.
Have a look please, if you get a chance at
org.apache.cxf.staxutils.transform.InTransformReader and the way
StaxUtils.read(filteredReader)) interacts with it. What may be
happening is that StaxUtils calls some XMLStreamReader method which
InTransformReader does not override or perhaps there's some problem
with the way InTransformReader manages NamespaceContext -
Please create a JIRA if you won;t have time or get stuck
thanks, Sergey
On Wed, Jul 20, 2011 at 9:53 PM, akuhtz <an...@siemens.com> wrote:
> Hi Sergey,
>
> I've done some more debugging on this problem and found that the loop
> appears in the processing of ReadHeadersInterceptor.handleMessage() when CXF
> try to get the header element from the message (line 159: doc =
> StaxUtils.read(filteredReader)). In StaxUtils around line 966 a new element
> is created and in the next line the prefix of the reader is set on the
> element but this is the wrong namespace (the original and not the
> converted). I'm not sure 100% if this is the reason that the while-loop
> around is not left ....
>
> Currently I'm stuck and I don't know where to start looking for a fix for
> this situation ...
>
> Attached is the updated sample project. Shall I create a JIRA issue?
>
> http://cxf.547215.n5.nabble.com/file/n4617249/cxf-transform-sample.zip
> cxf-transform-sample.zip
>
> Cheers
> Andi
>
> --
> View this message in context: http://cxf.547215.n5.nabble.com/Problem-with-new-transform-feature-tp4599185p4617249.html
> Sent from the cxf-user mailing list archive at Nabble.com.
>
--
Sergey Beryozkin
http://sberyozkin.blogspot.com
Talend - http://www.talend.com
Re: Problem with new transform feature
Posted by akuhtz <an...@siemens.com>.
Hi Sergey,
I've done some more debugging on this problem and found that the loop
appears in the processing of ReadHeadersInterceptor.handleMessage() when CXF
try to get the header element from the message (line 159: doc =
StaxUtils.read(filteredReader)). In StaxUtils around line 966 a new element
is created and in the next line the prefix of the reader is set on the
element but this is the wrong namespace (the original and not the
converted). I'm not sure 100% if this is the reason that the while-loop
around is not left ....
Currently I'm stuck and I don't know where to start looking for a fix for
this situation ...
Attached is the updated sample project. Shall I create a JIRA issue?
http://cxf.547215.n5.nabble.com/file/n4617249/cxf-transform-sample.zip
cxf-transform-sample.zip
Cheers
Andi
--
View this message in context: http://cxf.547215.n5.nabble.com/Problem-with-new-transform-feature-tp4599185p4617249.html
Sent from the cxf-user mailing list archive at Nabble.com.
Re: Problem with new transform feature
Posted by akuhtz <an...@siemens.com>.
Hi Sergey
Thanks for your reply! Yes I guess one problem is indeed that the headers
are handled separately. Please let me know if I can help you in any way ....
because I'm more a beginner with CXF I think I can't really help you on
details but I'll test your changes ;-)
Cheers
Andi
--
View this message in context: http://cxf.547215.n5.nabble.com/Problem-with-new-transform-feature-tp4599185p4600916.html
Sent from the cxf-user mailing list archive at Nabble.com.
Re: Problem with new transform feature
Posted by Sergey Beryozkin <sb...@gmail.com>.
Hi
On Mon, Jul 18, 2011 at 1:03 PM, akuhtz <an...@siemens.com> wrote:
> Hi,
>
> I was trying to use the new transform feature for CXF
> (http://cxf.apache.org/docs/transformationfeature.html) but limited luck
> until now.
>
> It works fine if you try to replace a namespace for a soap body element,
> that's the good news. But if a namespace is replaced in a soap header
> element the processing of an incoming requests loops somewhere but I cannot
> find where exactly this happens (might be somewhere in StaxUtils ... but not
> sure).
>
> I tried to replace a namespace in the soap header element but even if I use
> the same value as replacement it hangs ...
I think the problem could be to do with the fact SOAP headers and body
are produced as different documents,
thus having this feature managing multiple outputs is causing a
problem, even though it may not be dealing with the soap:Body. Perhaps
we'd need to introduce a 'scope' property, ex,
scope="soap:Envelope/soap:Header" or scope="soap:Envelope/soap:Body",
or just "soapHeaders"/"soapBody" ? Not sure yet how to handle it, but
may be SOAP interceptors dealing with headers/body can set the scope
message property. Next we will have two features configured, once
handling headers and one - body.
Cheers. Sergey
>
> I've created a small sample project that can be used to reproduce the
> problem.
>
> Regards,
> Andi http://cxf.547215.n5.nabble.com/file/n4599185/cxf-sample.zip
> cxf-sample.zip
>
> --
> View this message in context: http://cxf.547215.n5.nabble.com/Problem-with-new-transform-feature-tp4599185p4599185.html
> Sent from the cxf-user mailing list archive at Nabble.com.
>
--
Sergey Beryozkin
http://sberyozkin.blogspot.com
Talend - http://www.talend.com