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 [mailto:[email protected]]
Sent: Donnerstag, 18. Oktober 2012 17:21
To: [email protected]
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, 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 ).
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
http://coders.talend.com/
Blog: http://sberyozkin.blogspot.com
