Hi Andrei
On 24/10/12 10:24, Andrei Shakirin wrote:
Hi Sergey,
Or may be allocate to it "feature.transform" subpackge with the idea of moving
the stax feature to it too at the later stage - if you'd like to keep both features
in the same package. As I said even "org.apache.cxf.feature" would work :-) but
it immediately add one more migration issue if, at some point of time, we
decide to find a new home module for the features
Yep, absolutely agree. Will allocate "feature.transform" subpackage in core,
your option (2). I think both features (XSLTFeature and StaxTransformFeature) are
semantically very close, so it makes sense potentially to keep them in the same package.
Do you think it also OK to put interceptors in the same package with feature? Actually is designed
differently, for example GZIPFeature located in the same package with interceptors, Logging and
StaxTransform - in different. If yes, probably makes sense to name the package just
"transform" instead "feature.transform"?
I don't mind - either works for me :-) - unless someone else has
something to add. I guess what you've effectively pointed out is that at
some stage it will make sense to regroup few things (to do with the
features and their interceptors)
Thanks, Sergey
Regards,
Andrei.
-----Original Message-----
From: Sergey Beryozkin [mailto:[email protected]]
Sent: Mittwoch, 24. Oktober 2012 11:05
To: Andrei Shakirin
Cc: [email protected]
Subject: Re: Improvement proposal for CXF Transformation Feature
Hi
On 23/10/12 13:19, Sergey Beryozkin wrote:
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
Or may be allocate to it "feature.transform" subpackge with the idea of moving the stax
feature to it too at the later stage - if you'd like to keep both features in the same package. As
I said even "org.apache.cxf.feature" would work :-) but it immediately add one more
migration issue if, at some point of time, we decide to find a new home module for the features
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
--
Sergey Beryozkin
Talend Community Coders
http://coders.talend.com/
Blog: http://sberyozkin.blogspot.com
--
Sergey Beryozkin
Talend Community Coders
http://coders.talend.com/
Blog: http://sberyozkin.blogspot.com
