cxf-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gary Gregory <garydgreg...@gmail.com>
Subject Re: Improvement proposal for CXF Transformation Feature
Date Thu, 18 Oct 2012 15:25:09 GMT
On Thu, Oct 18, 2012 at 11:21 AM, Sergey Beryozkin <sberyozkin@gmail.com>wrote:

> Hi Andrei
> On 18/10/12 16:05, Andrei Shakirin wrote:
>
>> Hi,
>>
>> Actually CXF Transformation feature covers 99% of user needs:
>> 1) changing input and output element names and namespaces
>> 2) appending new input and output elements
>> 3) replacing text content
>> 4) dropping output and input elements
>> 5) converting attributes to elements
>>
>> Anyway I see some advanced use cases not supported by CXF Transformation
>> feature, like:
>> 1) replace/rename attributes;
>> 2) replace/remove attributes values
>> 3) replace text on the base of regular expressions
>> 4) process lists
>> etc.
>>
>> My proposal is to add property for Transformation feature that specified
>> XSLT transformation script to support such advanced use cases.
>> It will look like:
>> <bean id="transformFeature" class="org.apache.cxf.feature.**
>> StaxTransformFeature">
>>    <property name="inXSLT" value="/org/test/my-in.xslt"/>
>>    <property name="outXSLT" value="/org/test/my-out.xslt"/**>
>> </bean>
>>
>> XSLT engine Xalan will probably break the streaming (AFAIK is still load
>> tree into memory, incremental transformation just do it in optimized
>> parallel way). But for small messages is still an option and looking
>> forward - probably clean stream oriented XSLT will be supported in the
>> future.
>>
>> I have basic implementation and will provide a patch, if the improvement
>> makes sense (https://issues.apache.org/**jira/browse/CXF-4582<https://issues.apache.org/jira/browse/CXF-4582>).
>>
>>  I think it would sense to come up with a standalone XSLTFeature which
> would be much simpler, implementation wise, compared to
> StaxTransformFeature, which is really a light-weight alternative to XSLT
> itself.
>

Yes, please!

I would like to be able express this, which I currently do with funky hard
to maintain interceptors:

validate input vs. XSD 1
apply XSLT 1
validate transformed input vs. XSD 2

validate output vs. XSD 3
apply XSLT 2
validate transformed output vs. XSD 4

Gary

> Cheers, Sergey
>
>  Regards,
>> Andrei.
>>
>>
>
> --
> Sergey Beryozkin
>
> Talend Community Coders
> http://coders.talend.com/
>
> Blog: http://sberyozkin.blogspot.com
>



-- 
E-Mail: garydgregory@gmail.com | ggregory@apache.org
JUnit in Action, 2nd Ed: <http://goog_1249600977>http://bit.ly/ECvg0
Spring Batch in Action: <http://s.apache.org/HOq>http://bit.ly/bqpbCK
Blog: http://garygregory.wordpress.com
Home: http://garygregory.com/
Tweet! http://twitter.com/GaryGregory

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message