cxf-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sergey Beryozkin <>
Subject Re: Improvement proposal for CXF Transformation Feature
Date Tue, 23 Oct 2012 12:19:09 GMT
Hi Andrei
On 23/10/12 13:06, Andrei Shakirin wrote:
> Hi Sergei,
> I see that StaxTransformerFeature and interceptors in org.apache.interceptor.transform
package were promoted to API component.
> As I understand it was done to avoid exporting the same packages from different CXF modules.
> Question: is API component also the right place for XSLTFeature and it's interceptors?
I think it makes sense to keep StaxTransformerFeature and XSLTFeature in the same package.

I guess they should both live in rt/core but as you mentioned api module 
is the home for the STAX transformer feature for now, though perhaps we 
should have had it moved to "feature.transform" subpackage in rt/core to 
avoid OSGI-level issues (guess this can be done in CXF 2.8.0 for example).

IMHO it may make sense to consider allocating 
"org.apache.cxf.feature.xslt" to XSLTFeature, and consider placing it in 
rt/core or in api with the idea of moving transform and xslt features 
out later on. If we do allocate "org.apache.cxf.feature" for it then I 
guess it will be difficult to move it out of API at the later stage

Cheers, Sergey

> Regards,
> Andrei.
> -----Original Message-----
> From: Sergey Beryozkin []
> Sent: Donnerstag, 18. Oktober 2012 17:21
> To:
> Cc: Andrei Shakirin
> Subject: Re: Improvement proposal for CXF Transformation Feature
> 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,
>> 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
( ).
> 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.
> Cheers, Sergey
>> Regards,
>> Andrei.
> --
> Sergey Beryozkin
> Talend Community Coders
> Blog:

View raw message