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:[email protected]] Sent: Donnerstag, 28. Juli 2011 13:21 To: Kuhtz, Andreas Cc: Sergey Beryozkin; [email protected] 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 <[email protected]>: > 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:[email protected]] > Sent: Dienstag, 26. Juli 2011 19:39 > To: Kuhtz, Andreas; Sergey Beryozkin > Cc: [email protected] > 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 <[email protected]>: >> 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. >> >> >
