cxf-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sergey Beryozkin <>
Subject Re: Problem with new transform feature
Date Mon, 25 Jul 2011 16:08:10 GMT
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 <>:
>>>> 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 <>
>>>> wrote:
>>>>> Hi Andi
>>>>> On Sat, Jul 23, 2011 at 8:15 AM, akuhtz <>
>>>>> wrote:
>>>>>> Hi Sergey,
>>>>>> I've created a patch for this problem and opened
>>>>>> 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:
>>>>>> Sent from the cxf-user mailing list archive at
>>>>> --
>>>>> Sergey Beryozkin
>>>>> Talend -

View raw message