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" <[email protected]> > To: <[email protected]> > 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 [email protected] - http://dankulp.com/blog Talend Community Coder - http://coders.talend.com
