cxf-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sergey Beryozkin <sberyoz...@gmail.com>
Subject Re: Improvement proposal for CXF Transformation Feature
Date Wed, 24 Oct 2012 09:33:55 GMT
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:sberyozkin@gmail.com]
> Sent: Mittwoch, 24. Oktober 2012 11:05
> To: Andrei Shakirin
> Cc: users@cxf.apache.org
> 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:sberyozkin@gmail.com]
>>> Sent: Donnerstag, 18. Oktober 2012 17:21
>>> To: users@cxf.apache.org
>>> 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

Mime
View raw message