[
https://issues.apache.org/jira/browse/CXF-100?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Daniel Kulp closed CXF-100.
---------------------------
Resolution: Fixed
Fix Version/s: 2.0-RC
Long since done.
> Config-driven mechanism for specifying native Interceptor and JAX-WS Handler
> chains
> -----------------------------------------------------------------------------------
>
> Key: CXF-100
> URL: https://issues.apache.org/jira/browse/CXF-100
> Project: CXF
> Issue Type: New Feature
> Components: Configuration
> Reporter: Eoghan Glynn
> Assignee: Andrea Smyth
> Fix For: 2.0-RC
>
>
> All the interceptor chain participation is currently API-driven - i.e.
> interceptors 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.
> Similarly the JAX-WS Handler chains must currently be built up
> programmatically via {BindingProvider|Endpoint}.getHandlerChain(). It would
> be convenient if a similar config syntax could be used specify both
> interceptor and handler chains.
> In terms of engaging interceptors responsible for implementing some QoS (e.g.
> WS-A or RM), the slickest option would be for the presence of the
> <wsaw:UsingAddressing> extension element in the WSDL or an RM policy
> assertion to cause the WS-A and RM interceptors respectively to be added to
> the appropriate chains. So then the config would just boil down to
> associating the interceptor class names with the appropriate extension
> elements or policies.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
