You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cxf.apache.org by xuhb <xu...@tongtech.com> on 2012/01/09 07:46:41 UTC
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.getName(), Phase.UNMARSHAL);
addAfter(URIMappingInterceptor.class.getName());
addBefore(WrappedInInterceptor.class.getName());
docLiteralInterceptor = new DocLiteralInInterceptor();
}
public void handleMessage(Message msg){
...
docLiteralInterceptor .handleMessage(msg);
...
}
}
Re: Could CXF Interceptor export a internal interface to change Id?
Posted by xuhb <xu...@tongtech.com>.
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: <de...@cxf.apache.org>
Cc: "xuhb" <xu...@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" <xu...@tongtech.com>
>> To: <de...@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
>
Re: Could CXF Interceptor export a internal interface to change Id?
Posted by Daniel Kulp <dk...@apache.org>.
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" <xu...@tongtech.com>
> To: <de...@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
Re: Could CXF Interceptor export a internal interface to change Id?
Posted by xuhb <xu...@tongtech.com>.
etc: Could CXF declare AbstractPhaseInterceptor.getId() as not final?
----- Original Message -----
From: "xuhb" <xu...@tongtech.com>
To: <de...@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.getName(), Phase.UNMARSHAL);
> addAfter(URIMappingInterceptor.class.getName());
> addBefore(WrappedInInterceptor.class.getName());
>
> docLiteralInterceptor = new DocLiteralInInterceptor();
>
> }
> public void handleMessage(Message msg){
> ...
> docLiteralInterceptor .handleMessage(msg);
> ...
> }
> }