cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "xuhb" <x...@tongtech.com>
Subject Re: Could CXF Interceptor export a internal interface to change Id?
Date Tue, 10 Jan 2012 03:20:54 GMT
Thanks Dan:

I am using CXF & Camel CXF(Payload) model for webservice proxy usage  of a very special
case:

A proxy service can receive any xml data from client even when it isnot same as WSDL's message
definition and route it to a existing service. 
And the proxy service will response a Http Accept signal or a SOAP Response by the existing
service's response; 
(I have asked some questions about such usage in CXF's community previously. also JAXB Dispatch
& Provide is not applicable for MEP reason);

To implements such a feature, not only DocLiteralInInterceptor but also RPCInInterceptor,
RPCOutInterceptor, OutgoingChainInterceptor & HttpTransport(providing InOptionalOut like
MEP feature)  need some change;
 
So I think it's hard to illustrate why I need additional constructors for a single Interceptor
in a JIRA. 
Also I am not sure if the feature is suitable for CXF as it doesn't obey rules of  webservice
specification at all;

Anyway,I am refactoring my implementation to avoid change CXF source code directly too much
. 
If anyone has interest, I will post a JIRA to illustrate it clearly.

Thanks a lot;



----- Original Message ----- 
From: "Daniel Kulp" <dkulp@apache.org>
To: <dev@cxf.apache.org>
Cc: "xuhb" <xuhb@tongtech.com>
Sent: Tuesday, January 10, 2012 5:42 AM
Subject: Re: Could CXF Interceptor export a internal interface to change Id?


> On Monday, January 09, 2012 3:25:55 PM xuhb wrote:
>> etc: Could CXF declare AbstractPhaseInterceptor.getId()   as not final?
> 
> Likely not.   For a variety of reasons, we need to make sure that the id is 
> set at construction time and is never changed.   That's pretty much why the 
> field is a "final" as well.  Also, this is a call on the critical path and a 
> ton of work was put into optimizing and profiling these areas and allowing the 
> method to be overridden would disable the jit's ability to inline it.  
> 
> HOWEVER, I would definitely be open to adding additional constructors to areas 
> where it would be useful.   If DocLiteralInInterceptor needs some additional 
> constructors to make it useful for you, please file a jira with ideas.  :-)
> 
> Dan
> 
> 
> 
> 
> 
> 
> 
> 
>> ----- Original Message ----- 
>> From: "xuhb" <xuhb@tongtech.com>
>> To: <dev@cxf.apache.org>
>> Sent: Monday, January 09, 2012 2:46 PM
>> Subject: Could CXF Interceptor export a internal interface to change Id?
>> 
>> 
>> 
>> > Hi:
>> > 
>> >    I am extending some interceptors which will provide extending
>> >    functions and they will replace some built-in interceptors of
>> >    CXF.
>> 
>> > 
>> > 
>> >   for example: I have wrote a ExtDocLiteralInInterceptor which will
>> >   replace the build in DocLiteralInInterceptor, but providing some
>> >   operation uncheck features; (Use in Camel-CXF, which enable PayLoad
>> >   model will works even when the XML in soap is not same as WSDL's
>> >   declaration)
> 
>> >   The extended interceptor will also inherite the CXF build-in
>> >   interceptor's ability; But I found I cannot wrote my interceptor
>> >   which just inherit CXF's build-in interceptor as following:
> Etc:
>> >   
>> >        ExtDocLiteralInInterceptor extends
>> >        DocLiteralInInterceptor{
>> >        
>> >            public ExtDocLiteralInInterceptor (){
>> >            
>> >                super();
>> >                .....
>> >            
>> >            }
>> >            
>> >        
>> >        }
>> > 
>> > 
>> > Because if so, the ExtDocLiteralInInterceptor 's id isn't same as 
>> > DocLiteralInInterceptor; 
> 
>> > At starting up time, if I replace the built-in DocLiteralInInterceptor
>> > with ExtDocLiteralInInterceptor , then the sort of other interceptors
>> > in PhaseChain will not correct, because they may repy on the original 
>> > interceptor's id;
> 
>> > Now I could only copy the DocLiteralIntercept's initialize code in the
>> > extended interceptor, and wrap the original DocLiteralInterceptor for
>> > reuse; But  if CXF fixed some issume which changed the
>> > DocLiteralInInterceptor's constructor's code which I am not  aware,
>> > bugs will raised;
> 
>> > So I am wondering if CXF could expose a interal interface which enable
>> > us to change the id of interceptor?
> 
>> > Etc:
>> > 
>> > 
>> >        ExtDocLiteralInInterceptor extends
>> >        AbstractInDatabindingInterceptor{
>> 
>> > 
>> > 
>> >            public ExtDocLiteralInInterceptor (){
>> >            
>> >                 //these is copyed from
>> >                 DocLiteralInInterceptor; but id still
>> >                 keep same to DocLiteralInInterceptor
>>                
>> >                //but this's not safely, when CXF changed
>> >                the AbstractInDatabindingInterceptor's
>> >                constructor for some reason which we are
>> >                aware;
>>                
>> >                 super(DocLiteralInInterceptor.class.getN
>> >                 ame(), Phase.UNMARSHAL);
>> >                 addAfter(URIMappingInterceptor.class.ge
>> >                 tName());
>> >                 addBefore(WrappedInInterceptor.class.ge
>> >                 tName());> 
>> > 
>> > 
>> >                 docLiteralInterceptor = new
>> >                 DocLiteralInInterceptor();
>> > 
>> > 
>> > 
>> >            }
>> >           
>> >           public void handleMessage(Message msg){
>> >           
>> >                ...
>> >                docLiteralInterceptor
>> >                .handleMessage(msg);
>> >                ...
>> >            
>> >            }
>> >        
>> >        }
> -- 
> Daniel Kulp
> dkulp@apache.org - http://dankulp.com/blog
> Talend Community Coder - http://coders.talend.com
>
Mime
View raw message