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"? 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
