cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Glynn, Eoghan" <>
Subject RE: Pre-requisite for WS_RM: WS_Addressing etc
Date Fri, 08 Sep 2006 17:54:06 GMT
> >One final issue we probably want to address also is that all the 
> >interceptor chain participation is currently API-driven - i.e.
> >inpterceptors are added to the relevant chains programmatically via
> >InterceptorProvider.get{In|Out|Fault}Interceptors().add() as 
> opposed to 
> >a configuration-driven mechanism. The latter will be increasingly 
> >called for in order to engage the RM interceptors, as one of 
> the goals 
> >of Celtix RM support was to allow reliability to be 
> introduced without 
> >any changes to application code. So maybe a config mechanism for 
> >interceptor chains would be a good initial task for you?
> >
> Can you explain a bit more what you're thinking? I can't say 
> I've thought about this too much, but would people need to 
> specific interceptors? Or would it be a more - here is the 
> WsRmBean which acts on my service and enables rm with the 
> policy I created?

Well I haven't delved into this in great detail, but initially my
thinking was that the least we'd need is some analogue to the old Celtix
systemHandlers config (which allowed intra-handler ordering dependencies
to be specified).

However these ordering constraints already fall in place naturally from
the new interceptor phase mechanism. For example the WS-A SOAP
interceptor naturally preceeds the JAX-WS SoapHandlers in the chain by
virture of the PRE_PROTOCOL phase preceeding the USER_PROTOCOL one.
Similarly the getBefore/getAfter lists can be used to ensure that say
the WS-A SOAP interceptor comes before the WS-RM one, assuming they're
both in the same phase.

So assuming most of the ordering issues are subsumed by the phase
mechanism, we're left just with the question of participation in the
chain. Now the old systemHandler config required that the system
handlers to participate in the dispatch were explicitly specified. If
would be a lot neater and less error-prone if this could be inferred by
the runtime where possible, for example the presence of the
<wsaw:UsingAddressing> extension element in the WSDL or an RM policy
assertion causing the WS-A and WS-RM interceptors respectively to be
added to the appropriate chains. So then the config would boil down to
associating the interceptor class names with the appropriate extension
elements or whatever. I'm not sure how convenient this would be to do in


View raw message