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" <dk...@apache.org>
To: <dev@cxf.apache.org>
Cc: "xuhb" <x...@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" <x...@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
> dk...@apache.org - http://dankulp.com/blog
> Talend Community Coder - http://coders.talend.com
>
